Screen reader testing, a practical guide

Automated accessibility scans catch roughly thirty percent of real-world failures. The rest, including most failures that actually block users with disabilities from completing a task, require manual testing with a screen reader. This guide covers the four screen readers worth knowing, how to set each up, and how to structure a test session that produces useful evidence.

Which screen reader matters most

Per the WebAIM Screen Reader User Survey (2024), the desktop landscape is approximately 53 percent JAWS, 31 percent NVDA, and 12 percent VoiceOver on macOS. On mobile, VoiceOver represents around 70 percent and TalkBack 30 percent. For an Australian government or enterprise context, you should test on at least one of NVDA or JAWS (Windows is dominant in workplace settings) and VoiceOver on iOS (overwhelming mobile share among blind users).

If you can only test one combination, choose VoiceOver on iOS Safari. Mobile-first traffic profiles for most consumer services and the assistive technology share are concentrated.

VoiceOver on iOS and macOS

iOS: Settings, Accessibility, VoiceOver, toggle on. Set the activation shortcut: Settings, Accessibility, Accessibility Shortcut, VoiceOver. Triple-click the side button to toggle.

Core gestures: swipe right to move forward an element, swipe left to move back, double-tap to activate, two-finger swipe down to read continuously, three-finger swipe to scroll. The rotor (rotate two fingers on screen) lets you switch between navigation modes: headings, links, form controls, landmarks.

macOS: System Settings, Accessibility, VoiceOver. Default activation is Command-F5. The VoiceOver Utility lets you adjust verbosity. For testing, set verbosity to High initially so you hear all available semantic information; reduce later to match a typical user.

What to test with VoiceOver

• Navigate by headings only (rotor, Headings). The page structure should be coherent: H1, then H2 sections, then H3 subsections.
• Navigate by landmarks. You should hear banner, navigation, main, complementary, contentinfo. Missing landmarks suggest missing semantic structure.
• Tab through the page. Focus order should match visual order. Hidden content should not receive focus.
• Test forms: every field should announce its label, current value, type and any error state.

TalkBack on Android

Settings, Accessibility, TalkBack, toggle on. Initial setup walks through the gestures. The volume-up plus volume-down combination toggles TalkBack on and off if you have set the shortcut.

Core gestures mirror VoiceOver but are inverted in places: swipe right to move forward, double-tap to activate. The TalkBack menu (single-finger swipe down then right) gives access to verbosity, navigation granularity and reading controls.

TalkBack 14 (Android 13 and later) uses the same gesture model as VoiceOver. Earlier versions used a different model and you may encounter mixed feedback if testing across an older fleet.

NVDA on Windows

NVDA is free and open-source, distributed by NV Access. Download from nvaccess.org and install. The NVDA modifier key is Insert by default, or CapsLock if you enable laptop layout.

Useful commands for testing: Insert plus T reads the page title, Insert plus F7 opens the elements list (lets you jump by headings, links or landmarks), H jumps to next heading in browse mode, K jumps to next link, F jumps to next form control. Insert plus down arrow reads continuously.

Browse mode versus focus mode is the most important concept to internalise. Browse mode is for reading content; focus mode is automatically entered when you enter form controls. Press Insert plus Space to toggle manually.

JAWS on Windows

JAWS is the dominant commercial screen reader, made by Vispero. A 40-minute trial mode is available, after which it stops working until restart. For ongoing test work, an annual licence is required, or you can use JAWS Inspect (a tool that captures JAWS output for QA review without continuous JAWS use).

Most JAWS keyboard commands are identical to NVDA, which is intentional: NVDA followed JAWS conventions, and most test scripts run unchanged across both.

Writing a useful test script

A useful screen reader test script reads like a user task, not a list of WCAG criteria. Frame it around outcomes: "complete a booking, from search to confirmation, using only the keyboard and a screen reader." Inside that frame, note specific things to verify at each step.

An example script structure for a health service appointment booking:

1. Land on homepage. Verify page title is meaningful, H1 announces correctly, primary navigation has a landmark role.
2. Find the booking entry point. Verify the booking link is reachable by keyboard within 5 tab stops or via a heading jump.
3. Search for an appointment. Verify the search field is labelled, filters are properly grouped, and results are announced when they update.
4. Select a time. Verify the time picker is operable without drag, that selected state is announced, and that the choice persists if you navigate back.
5. Enter personal details. Verify every field has a label, autocomplete is set, errors are announced inline.
6. Confirm. Verify the confirmation page announces success and provides next-step information without requiring additional clicks.

For each step, write down: what you heard, whether it matched the visual experience, and where the experience broke down. This produces evidence that supports both bug reports and conformance documentation.