Internal Accessibility Engineering Process
Here at Instructure, we believe that accessibility isn't just a feature—it's a foundational part of how we build. Creating accessible experiences is a cross-functional effort that starts from the earliest design phases and continues through development, testing, and beyond.
Here’s a look into how we’ve structured our internal accessibility engineering process to ensure our products are usable by everyone.
Early Collaboration with Designers
Accessibility starts at the design phase. Our accessibility team works closely with Designers from the beginning of the process to provide input on accessible patterns, color contrast, and interaction behaviors. This collaboration happens in weekly check-ins where our designers share work that’s in progress so that we’re able to identify potential accessibility concerns early—before they become costly to fix.
When designs are approaching final hand-off to Engineering, we conduct an Accessibility Design Review. These reviews serve as checkpoints to ensure the designs meet accessibility standards and adhere to best practices for cognitive, keyboard and screen reader accessibility. In this review the designer will walk an accessibility engineer, software engineer and product manager through the design to ensure that all questions and concerns are answered prior to development. By integrating accessibility into the design lifecycle, we aim to reduce retroactive fixes and set the development teams up for success.
Development & Engineering Support
Once designs are handed off, our engineering teams build the features with accessibility in mind. Accessibility isn’t just a checklist for us—it’s built into our development standards. Engineers use semantic HTML, ARIA attributes when necessary, and follow established accessibility guidelines. Our teams also utilize an in-house component library that has been audited for accessibility to ensure that accessibility is baked into our toolkit as much as possible.
Our accessibility engineers remain available during development to provide guidance, review implementation, and answer questions that arise.
Internal Accessibility Audits
After a feature is code complete and ready for review, our accessibility engineers perform an internal accessibility audit. This audit includes:
- Automated Testing: Using accessibility scanning tools to catch common issues.
- Keyboard Navigation: Ensuring full operability without a mouse, including visible focus states and focus management.
- Screen Reader Navigation: Testing utilizing our supported screen reader and browser combinations.
- JAWS with Firefox/Chrome (Windows)
- NVDA with Firefox/Chrome (Windows)
- VoiceOver with Safari/Chrome (Macintosh / iOS mobile apps)
- Talkback (Android mobile apps)
- Manual Testing: Testing edge cases and user flows that automated tools can’t cover.
This thorough evaluation ensures our products are accessible to users with a wide range of abilities.
Third-Party Audits
We know that it’s critical to get an external perspective, too. That’s why we conduct third-party accessibility audits with trusted partners. These audits help validate our internal findings, uncover gaps we may have missed, and provide recommendations to improve even further.
By combining internal diligence with external expertise, we hold ourselves accountable to a high standard of accessibility.
Continuous Improvement
Accessibility is never “done.” It’s an ongoing commitment. We continue to invest in team education, update our components and design systems with inclusive practices, and listen to feedback from our users to evolve how we build.
Our goal is to make our digital products usable by everyone, regardless of ability.
