Which screen readers should we test with?

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.

How often should we run assistive technology testing?

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.

Do we need users with disabilities to test?

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.

What is the difference between keyboard testing and screen reader testing?

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.

How do we prioritize findings from assistive technology testing?

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.

Assistive Technology Testing Template

What This Template Is For

Automated accessibility scanners catch roughly 30-40% of accessibility issues. The remaining 60-70% are only detectable by testing with actual assistive technology. A color contrast failure shows up in a scan. A confusing reading order, a focus trap in a modal, or an unlabeled dynamic update does not.

This template provides structured testing protocols for five categories of assistive technology: screen readers (VoiceOver, NVDA, TalkBack), screen magnifiers (ZoomText, browser zoom), voice control (Dragon NaturallySpeaking, Voice Control on macOS), switch devices, and keyboard-only navigation. Each protocol includes setup steps, test scenarios, pass/fail criteria, and a findings log.

Use this template after completing the automated scans described in the accessibility audit template. The automated audit catches the low-hanging issues. This template catches everything else. For tracking remediation work after testing, the a11y roadmap template helps prioritize and phase fixes. The Technical PM Handbook covers how PMs can interpret technical testing results and communicate findings to engineering teams.

How to Use This Template

Select the assistive technologies to test. At minimum, test with VoiceOver (macOS/iOS), NVDA (Windows), and keyboard-only. Add TalkBack (Android), Dragon, and ZoomText if your user base includes those populations.
Define the user flows to test. Use the same critical flows from your test strategy template. Prioritize flows by traffic and business impact.
Assign testers. Testers do not need to be assistive technology experts, but they should spend 30 minutes learning basic commands before testing. The command reference tables below cover the essentials.
Run each protocol independently. A VoiceOver test and an NVDA test should be separate sessions because the assistive technologies behave differently.
Log findings with specific details: the assistive technology used, the exact step where the issue occurred, what the user heard or experienced, and the WCAG criterion that was violated.
Prioritize findings by user impact and frequency, then feed them into your accessibility remediation backlog.

The Template

Test Configuration

Field	Details
Product / Feature	[Name]
Test Lead	[Name]
Test Date	[Date]
Build / Version	[Version or URL]
User Flows Tested	[List the flows covered in this session]

Setup:

Enable VoiceOver: System Settings > Accessibility > VoiceOver, or press Cmd+F5
Use Safari (VoiceOver's best-supported browser on macOS)
Set speech rate to a comfortable speed (VO+Cmd+arrow keys)

Essential commands:

Action	Command
Turn VoiceOver on/off	Cmd+F5
Move to next element	VO+Right Arrow (VO = Ctrl+Option)
Move to previous element	VO+Left Arrow
Activate (click)	VO+Space
Read page from current position	VO+A
Navigate by headings	VO+Cmd+H
Navigate by links	VO+Cmd+L
Navigate by form elements	VO+Cmd+J
Open rotor (navigation hub)	VO+U
Go to next landmark	VO+Cmd+} (right curly brace)

Test scenarios:

#	Scenario	Pass Criteria	Result
1	Page load announcement	VoiceOver announces the page title and primary landmark	☐ Pass / ☐ Fail
2	Heading structure navigation	All headings are announced in correct order using VO+Cmd+H. No skipped levels.	☐ Pass / ☐ Fail
3	Landmark navigation	Main, navigation, banner, and contentinfo landmarks are present and labeled	☐ Pass / ☐ Fail
4	Link purpose	Every link announces its destination or purpose. No "click here" or "read more" without context.	☐ Pass / ☐ Fail
5	Form labels	Every form field announces its label when focused. Required fields are indicated.	☐ Pass / ☐ Fail
6	Error handling	Form errors are announced when they appear. Error messages identify which field failed and why.	☐ Pass / ☐ Fail
7	Image alt text	Informative images announce meaningful descriptions. Decorative images are skipped.	☐ Pass / ☐ Fail
8	Dynamic content	Content updates (toasts, loading states, live search results) are announced via live regions	☐ Pass / ☐ Fail
9	Modal dialog	Focus moves into modal on open. Focus is trapped. Escape closes. Focus returns to trigger.	☐ Pass / ☐ Fail
10	Custom widgets	Tabs, accordions, menus, and comboboxes announce their role, state, and available actions	☐ Pass / ☐ Fail
11	Complete user flow	[Primary user flow] can be completed entirely with VoiceOver without sighted assistance	☐ Pass / ☐ Fail

Setup:

Download NVDA from nvaccess.org (free)
Use Chrome or Firefox (NVDA's best-supported browsers on Windows)
Enable speech viewer (NVDA+N > Tools > Speech Viewer) to see what NVDA announces in text form

Essential commands:

Action	Command
Turn NVDA on/off	Ctrl+Alt+N / NVDA+Q
Move to next element	Down Arrow (in browse mode)
Move to previous element	Up Arrow
Activate (click)	Enter or Space
Toggle browse/focus mode	NVDA+Space
Navigate by headings	H (in browse mode)
Navigate by links	K (unvisited) / V (visited)
Navigate by form elements	F (form field) / B (button)
Elements list (navigation hub)	NVDA+F7
Navigate by landmarks	D

Test scenarios:

#	Scenario	Pass Criteria	Result
1	Page load announcement	NVDA announces the page title on load	☐ Pass / ☐ Fail
2	Browse mode navigation	User can navigate the full page using arrow keys in browse mode	☐ Pass / ☐ Fail
3	Focus mode for forms	NVDA switches to focus mode in form fields. Fields announce labels.	☐ Pass / ☐ Fail
4	Heading hierarchy	H key cycles through all headings in document order. No missing levels.	☐ Pass / ☐ Fail
5	Table reading	Data tables announce row/column headers when navigating cells (Ctrl+Alt+arrows)	☐ Pass / ☐ Fail
6	ARIA widgets	Custom widgets (tabs, menus, trees) announce roles and states correctly	☐ Pass / ☐ Fail
7	Dynamic content	Live region updates are announced at appropriate priority (polite/assertive)	☐ Pass / ☐ Fail
8	Complete user flow	[Primary user flow] can be completed entirely with NVDA	☐ Pass / ☐ Fail

Setup:

Enable TalkBack: Settings > Accessibility > TalkBack
Use Chrome (TalkBack's primary browser)
Connect device to computer for easier note-taking during testing

Essential gestures:

Action	Gesture
Move to next element	Swipe right
Move to previous element	Swipe left
Activate (tap)	Double-tap
Scroll	Two-finger swipe
Read from current position	Swipe down then right
Change navigation granularity	Swipe up or down
Open TalkBack menu	Swipe down then right with three fingers
Go to first/last element	Swipe up then down / down then up

Test scenarios:

#	Scenario	Pass Criteria	Result
1	Touch target size	All interactive elements have a minimum touch target of 48x48dp	☐ Pass / ☐ Fail
2	Swipe navigation	All content is reachable by swiping through elements sequentially	☐ Pass / ☐ Fail
3	Form interaction	Form fields are labeled. Keyboards appear appropriately (email keyboard for email, number pad for phone).	☐ Pass / ☐ Fail
4	Gesture alternatives	Any gesture-only interaction has an alternative (e.g., swipe-to-delete has a delete button)	☐ Pass / ☐ Fail
5	Complete user flow	[Primary mobile flow] can be completed with TalkBack	☐ Pass / ☐ Fail

Protocol 4: Screen Magnification Testing

Setup (ZoomText or browser zoom):

Test at 200%, 300%, and 400% magnification
Use both browser zoom (Cmd/Ctrl+) and OS-level magnification
Test in a viewport of 1280x1024 at 100% (becomes 640x512 at 200%)

Test scenarios:

#	Scenario	Pass Criteria	Result
1	Content reflow at 200%	All content reflows into a single column. No horizontal scrolling for text content.	☐ Pass / ☐ Fail
2	Content reflow at 400%	Content remains readable. No text overlap, truncation, or hidden content.	☐ Pass / ☐ Fail
3	Text spacing override	With letter-spacing 0.12em, word-spacing 0.16em, line-height 1.5, and paragraph-spacing 2em, no content is clipped or overlaps	☐ Pass / ☐ Fail
4	Sticky/fixed elements	Fixed headers, footers, and floating buttons do not obscure content at high zoom levels	☐ Pass / ☐ Fail
5	Tooltips and popovers	Tooltips remain visible when magnified and do not overflow the viewport	☐ Pass / ☐ Fail
6	Data tables	Tables scroll horizontally or reflow. Column headers remain associated with data cells.	☐ Pass / ☐ Fail

Setup:

Unplug or disable the mouse/trackpad
Use Tab, Shift+Tab, Enter, Space, Arrow keys, and Escape only
Test in Chrome and Firefox

Test scenarios:

#	Scenario	Pass Criteria	Result
1	Focus visibility	Every focused element has a visible focus indicator (outline, ring, or highlight)	☐ Pass / ☐ Fail
2	Tab order	Tab order follows the visual reading order. No unexpected jumps.	☐ Pass / ☐ Fail
3	No focus traps	Focus never gets stuck in a component with no way to Tab out (except intentional traps like modals)	☐ Pass / ☐ Fail
4	Skip navigation	A "skip to main content" link is the first focusable element on every page	☐ Pass / ☐ Fail
5	Interactive elements reachable	Every button, link, form field, and custom widget can be reached and activated by keyboard	☐ Pass / ☐ Fail
6	Dropdown and menu navigation	Arrow keys navigate within menus. Escape closes menus and returns focus.	☐ Pass / ☐ Fail
7	Complete user flow	[Primary user flow] can be completed entirely with keyboard	☐ Pass / ☐ Fail

Protocol 6: Voice Control Testing (Optional)

Setup (macOS Voice Control or Dragon):

Enable Voice Control: System Settings > Accessibility > Voice Control
Or install Dragon NaturallySpeaking on Windows

Test scenarios:

#	Scenario	Pass Criteria	Result
1	Visible labels match accessible names	Saying "Click [visible text]" activates the correct element	☐ Pass / ☐ Fail
2	Grid overlay navigation	All interactive elements have a number overlay and can be activated by number	☐ Pass / ☐ Fail
3	Form filling	"Type [text] in [field name]" enters text in the correct field	☐ Pass / ☐ Fail

Findings Log

ID	AT Used	Page/Flow	Issue Description	WCAG Criterion	Severity	Screenshot/Recording	Status
AT-001	[VoiceOver/NVDA/etc.]	[Page URL or flow]	[What happened vs. what should happen]	[e.g., 4.1.2 Name, Role, Value]	[Critical/Major/Minor]	[Link]	[Open/Fixed/Won't Fix]
AT-002
AT-003
AT-004
AT-005

Test Summary

Assistive Technology	Scenarios Run	Passed	Failed	Pass Rate	Notes
VoiceOver (macOS/Safari)
NVDA (Windows/Chrome)
TalkBack (Android/Chrome)
Screen magnification (400%)
Keyboard-only
Voice Control
Total

Assistive Technology Testing Template