Screen reader testing

A screen reader tells you what your markup actually communicates, which is regularly not what you meant it to. It is the only way to verify names, roles, states, structure and announcements — the substance of 1.3.1, 2.4.4, 4.1.2 and 4.1.3.

You are not simulating a blind user

You are inspecting your markup through the same interface a blind user has. A daily screen reader user runs at speech rates you would find unintelligible, knows dozens of shortcuts, and will navigate your page in ways you never try. Use the tool to find defects; do not use your experience of it to judge whether the page is usable. That judgement needs actual users.

Which one to test with

Screen readers, platforms and cost
Screen reader	Platform	Cost	Pair it with
NVDA	Windows	Free	Firefox or Chrome
JAWS	Windows	Commercial	Chrome
VoiceOver	macOS, iOS	Built in	Safari
TalkBack	Android	Built in	Chrome
Narrator	Windows	Built in	Edge

If you test with one, make it NVDA with Firefox on Windows or VoiceOver with Safari on macOS. Screen reader and browser behave as a pair — a bug in one combination may not appear in another, which is why real audits sample more than one.

NVDA (Windows)

The NVDA key is Insert (or Caps Lock in laptop layout). Start and stop with Ctrl+Alt+N. Silence it instantly with Ctrl.

NVDA commands you will use constantly
Keys	What it does
`Ctrl`	Stop speaking. Learn this first.
`NVDA`+`↓`	Read continuously from here
`H` / `Shift`+`H`	Next / previous heading
`1`–`6`	Next heading at that level
`D`	Next landmark
`F`	Next form field
`T`	Next table
`G`	Next graphic
`K`	Next link
`NVDA`+`F7`	Elements list — every link, heading and landmark. The single most useful command for auditing.
`NVDA`+`Tab`	Announce the currently focused control
`NVDA`+`T`	Read the page title

VoiceOver (macOS)

Toggle with Cmd+F5. The VO keys are Ctrl+Option. Turn on keyboard navigation in System Settings first, or Tab will skip links.

VoiceOver commands
Keys	What it does
`Ctrl`	Stop speaking
`VO`+`A`	Read from here
`VO`+`→` / `←`	Next / previous item
`VO`+`U`	Rotor — lists headings, links, landmarks, form controls. The equivalent of NVDA's elements list.
`VO`+`Cmd`+`H`	Next heading
`VO`+`Cmd`+`L`	Next link
`VO`+`Space`	Activate the current item
`VO`+`Shift`+`↓`	Interact with a group (tables, custom widgets)

Mobile: VoiceOver on iOS and TalkBack on Android

Swipe right / left — next / previous element
Double tap — activate the current element
Two-finger swipe down — read from the top
Rotor (iOS): twist two fingers on the screen. Reading controls (Android): swipe up then right.
Explore by touch — drag a finger across the screen to hear what is under it

Test mobile separately. Touch targets (2.5.8), gestures (2.5.1), dragging (2.5.7) and orientation (1.3.4) can only be judged on a real device.

The test script

Load the page and listen to the first thing announced. It should be a descriptive page title. 2.4.2
Open the elements list or rotor and read the HEADINGS alone. They should work as a table of contents. 1.3.1 2.4.6
Read the LINKS alone. Every entry should make sense out of context. Look for repeated "Read more" and bare URLs. 2.4.4 2.4.9
Read the LANDMARKS. There should be a main, and the page should be navigable by region. 1.3.1 2.4.1
Read the whole page top to bottom. Does the order make sense? Are images described usefully, or is a file name read out? 1.1.1 1.3.2
Tab through every control and listen to name, role and state. "Marketing emails, toggle button, pressed" is right; "button" is not. 4.1.2
Operate every custom widget. Does the announced state change when the visual state does? 4.1.2
Trigger every status message — search results, add to basket, save confirmations, loading states. If you hear nothing, there is no live region. 4.1.3
Submit a form with errors and listen. The error must be announced and tied to its field. 3.3.1
Read a data table. Each cell should be announced with its row and column headers. 1.3.1

Mistakes sighted testers make

Looking at the screen. Turn the monitor off, or close your eyes, for at least part of the pass. You cannot hear the gaps while your eyes are filling them in.
Only using Tab. Screen reader users navigate by heading, landmark and link list far more than by Tab. Test the way they browse.
Testing only the happy path. Errors, empty states, loading states and dialogs are where the failures are.
Assuming one screen reader speaks for all. Behaviour differs between NVDA, JAWS and VoiceOver, especially around ARIA.
Reporting verbosity as a bug. What sounds excessive to you is often normal at the speeds real users run.