Screen Reader Testing

Screen reader testing evaluates how interfaces work with assistive technology that reads content aloud. Testing with actual screen readers reveals issues that automated tools and visual inspection cannot identify.

What Is Screen Reader Testing

Screen reader testing involves navigating interfaces using screen reader software to verify content is accessible, announced correctly, and usable without visual perception.

Screen readers used for testing include:

• VoiceOver (built into macOS and iOS)
• NVDA (free, Windows)
• JAWS (commercial, Windows)
• TalkBack (Android)
• Narrator (Windows)

Each screen reader has different behaviors and capabilities. Testing with multiple screen readers ensures broader compatibility.

How Screen Reader Testing Works

Basic navigation testing explores content structure:

• Navigate by headings (H key in many screen readers)
• Navigate by landmarks (D key for NVDA)
• Read through content sequentially
• Navigate form controls
• Navigate links and buttons

Task completion testing verifies functionality:

• Complete key user flows
• Fill out forms
• Navigate between pages
• Use interactive components
• Handle error states

Evaluation criteria include:

• Is all content announced?
• Are announcements meaningful and complete?
• Is navigation efficient?
• Can all tasks be completed?
• Are dynamic updates announced appropriately?

Documentation records findings:

• What was tested (page, component, flow)
• Screen reader and browser used
• Issues found with specific elements
• Expected versus actual behavior
• Severity assessment

VoiceOver testing on Mac uses:

• Command+F5 to enable VoiceOver
• VO (Control+Option) + arrow keys to navigate
• VO + Space to activate
• VO + U for rotor navigation

NVDA testing on Windows uses:

• Insert or Caps Lock as NVDA modifier key
• Arrow keys to navigate
• Enter to activate
• NVDA + F7 for elements list

Key Considerations

• Test with multiple screen readers for browser coverage
• Learn basic screen reader commands before testing
• Complete actual user tasks, not just navigation
• Listen for confusing or missing announcements
• Test dynamic content (modals, errors, updates)
• Document specific issues for remediation
• Consider screen reader users in design decisions

Common Questions

Which screen reader should be used for testing?

For comprehensive testing, use at least two screen readers:

• VoiceOver + Safari on Mac (most common Mac combination)
• NVDA + Firefox or Chrome on Windows (most common free Windows combination)
• JAWS + Chrome on Windows (most common commercial combination)

Mobile testing adds VoiceOver on iOS and TalkBack on Android.

How do screen reader users actually navigate?

Experienced screen reader users rarely read pages linearly. They:

• Navigate by headings to scan page structure
• Jump to landmarks (navigation, main content)
• Tab through interactive elements
• Search for specific text
• Use element lists (links, headings, forms)

Testing should include these efficient navigation patterns, not just linear reading.

What level of screen reader proficiency is needed?

Basic proficiency suffices for routine testing:

• Know how to start/stop the screen reader
• Navigate by headings and landmarks
• Read content sequentially
• Interact with forms and controls

Deeper proficiency helps for comprehensive audits. Consider pairing with experienced screen reader users for critical testing.

Summary

Screen reader testing evaluates interfaces with assistive technology to verify content is accessible, announcements are meaningful, and tasks are completable. Testing with multiple screen readers like VoiceOver, NVDA, and JAWS ensures compatibility across the range of assistive technologies users employ.