Screen Reader Testing Guide for Accessibility Audits
Practical guide to testing with screen readers for WCAG 2.1 compliance. Covers VoiceOver, NVDA, and JAWS testing procedures, common commands, and what to listen for.
Detailed Explanation
Screen Reader Testing for Accessibility
Screen reader testing is the most effective way to verify that your website works for blind and visually impaired users. While automated tools catch many issues, only screen reader testing reveals how the experience actually sounds and feels.
Which Screen Readers to Test
| Screen Reader | Platform | Usage Share |
|---|---|---|
| NVDA | Windows | ~40% |
| JAWS | Windows | ~30% |
| VoiceOver | macOS/iOS | ~25% |
| TalkBack | Android | ~5% |
For most teams, testing with VoiceOver + Safari (macOS) and NVDA + Firefox (Windows) covers the majority of screen reader users.
Essential VoiceOver Commands (macOS)
- VO key: Ctrl + Option (held together)
- Start/stop VoiceOver: Cmd + F5
- Navigate next element: VO + Right Arrow
- Navigate previous element: VO + Left Arrow
- Activate element: VO + Space
- Read all content: VO + A
- Open rotor: VO + U (browse headings, links, landmarks)
What to Test
Page structure — Navigate by headings (H key in NVDA). Verify heading hierarchy makes sense.
Links and buttons — Navigate by links (K key in NVDA). Verify link text is descriptive.
Images — Verify alt text is read for informative images and decorative images are skipped.
Forms — Navigate to each field. Verify labels are announced, required status is indicated, errors are announced.
Dynamic content — Trigger AJAX updates, notifications, error messages. Verify they are announced via live regions.
Landmarks — Navigate by landmarks (D key in NVDA). Verify main, nav, banner, contentinfo regions exist.
Tables — Navigate table cells. Verify column and row headers are announced correctly.
Common Issues Found Only by Screen Reader Testing
- Focus visually on an element but screen reader announces wrong content
- ARIA labels that override meaningful visible text
- Live regions that announce too frequently or not at all
- Custom widgets that sound confusing when navigated linearly
Use Case
Screen reader testing should be performed at least once per major release. Accessibility specialists use screen readers as their primary testing tool. For teams new to screen reader testing, start with VoiceOver on macOS (it is built in and requires no installation) and test the most critical user flows.
Try It — Accessibility Audit Checklist
Perceivable
Operable
Understandable
Robust
50 criteria shown · Click the status badge to cycle through Pass / Fail / N/A / Untested