Assistive Technology Testing Template

Prioritize VoiceOver on macOS with Safari and NVDA on Windows with Chrome. These two combinations cover the majority of screen reader users. If your product has significant mobile traffic, add TalkBack on Android with Chrome. The WebAIM Screen Reader Survey (published annually) shows that NVDA and JAWS are the most popular desktop screen readers, with VoiceOver dominant on mobile. The [accessibility compliance template](/templates/accessibility-compliance-template) includes a device and browser matrix you can use to document your test coverage decisions.

Run a full assistive technology test cycle before each major release. Run targeted tests (specific flows only) when shipping new interactive components or making significant UI changes. Quarterly regression testing catches issues introduced by incremental changes that are not individually tested. Keyboard-only testing is fast enough to include in every sprint's QA process.

Teams should not rely solely on users with disabilities for testing, but user testing with assistive technology users provides insights that simulated testing cannot. A QA engineer using VoiceOver for the first time will catch broken ARIA and keyboard traps. A daily VoiceOver user will catch usability issues: confusing reading order, verbose announcements, and missing context. Plan for at least one round of user testing per quarter with 3-5 participants who use assistive technology daily. The [user research template](/templates) can be adapted for accessibility-focused research sessions.

Keyboard-only testing verifies that every interactive element can be reached and activated without a mouse. Screen reader testing verifies that the experience is understandable when the visual presentation is replaced by audio announcements. A component can be keyboard accessible (you can Tab to it and press Enter) but not screen reader accessible (it does not announce its role, state, or label). Both tests are required. Keyboard testing is faster and catches focus order, focus visibility, and focus trap issues. Screen reader testing catches labeling, role, state, and live region issues.

Use three severity levels. Critical: the user cannot complete the flow at all (keyboard trap, unlabeled form, missing submit button announcement). Major: the user can complete the flow but with significant difficulty or confusion (incorrect reading order, missing state announcements, confusing labels). Minor: the user can complete the flow with minor friction (verbose descriptions, inconsistent focus indicators, redundant announcements). Fix critical issues before the next release. Major issues go into the next sprint. Minor issues are backlogged and addressed in batch.