Owners avoid this test because it sounds technical. It is not. You need to start the software, learn about six commands, and listen. Most people find something on their own site inside five minutes.
What you are doing is not the same as what a daily user does, and we will be straight about that at the end. It is still the most educational half hour you can spend on your own site.
Which Screen Reader to Use
| Name | Platform | Cost | Use it when |
|---|---|---|---|
| NVDA | Windows | Free | You are on Windows. It is the pragmatic default for testing. |
| JAWS | Windows | Paid, with a demo mode | You want the one most people reach for first, at 40.5% of primary use in WebAIM's survey. |
| VoiceOver | macOS and iOS | Built in | You are on a Mac. Nothing to install. |
| TalkBack | Android | Built in | You are testing on Android. |
| Narrator | Windows | Built in | You need something already there, though NVDA is better for testing. |
Pair them sensibly with browsers, because these pairings are not taste. They are what people actually use. JAWS with Chrome is the commonest combination in the field at nearly a quarter of respondents, NVDA with Chrome is next, and JAWS with Edge comes third, ahead of NVDA with Firefox. VoiceOver goes with Safari. Mismatched pairings produce odd behaviour that is not your site's fault, and chasing it wastes an afternoon.
There is a real reason for that rather than superstition. A screen reader does not read your HTML. It reads what the browser hands to the operating system's accessibility layer, and there are four such layers across the platforms, each with its own mapping from HTML to what assistive technology receives. Browsers do not always resolve those mappings identically, which is exactly where the odd behaviour comes from.
If you are testing once to understand your own site, use whatever is on the machine in front of you. VoiceOver on a Mac needs no download at all.
And test on your phone, which is the part desktop-focused advice keeps missing. More than nine in ten survey respondents use a screen reader on a mobile device, and seven in ten of those are on iOS. So the VoiceOver you already have is a minority choice on the desktop and the dominant one on mobile. Our mobile accessibility guide covers what changes there.
The Commands Worth Learning
Six, and you can ignore the rest for a first pass.
| What you want | NVDA (Windows) | VoiceOver (Mac) |
|---|---|---|
| Start and stop | Ctrl+Alt+N to start, Insert+Q then Enter to quit | Command+F5 toggles |
| Stop it talking | Ctrl | Ctrl |
| Read next item | Down arrow | Ctrl+Option+Right |
| List all headings | Insert+F7, then Headings | Ctrl+Option+U, then Headings |
| Jump to next heading | H | Ctrl+Option+Command+H |
| List all links | Insert+F7, then Links | Ctrl+Option+U, then Links |
Quitting NVDA opens a confirmation dialog, which is why Enter is part of that first row. Press Insert+Q on its own and nothing appears to happen, and a first-time tester will assume the software has crashed.
The two list commands are the ones that teach you most. Pull up the list of headings on your home page and you see your page structure exactly as a screen reader user does. Pull up the list of links and you find out how many of them say "read more".
Turn your monitor off
Not down. Off, or close your eyes properly. The moment you can see the screen you subconsciously use it, and you will conclude your site is fine. The test only works blind.
What to Listen For
You are not judging your own competence with the software. You are listening for nine specific things, all of which are obvious to a beginner:
- "Button" with no name after it. The control has no accessible name.
- "Edit text, blank" on a form field. It has no label.
- "Link" followed by a URL, or by "click here", or by "read more" for the eleventh time.
- A filename read out where an image description should be.
- "Image" repeated for decorative graphics that should have been skipped.
- Silence after you press something. The page changed and nothing was announced.
- Content read in an order that does not match the screen.
- "Clickable" on things that are not buttons or links, which usually means a div with a click handler.
- A CAPTCHA you cannot get through. Screen reader users report this as the single most problematic thing on the web, ahead of everything else on this list. No scanner will ever raise it, because that criterion has no automated rule.
The one you will not hear
A form field labelled only by placeholder text does not announce as "edit text, blank". The specification that computes accessible names falls back to the placeholder when nothing else supplies a name, so the field reads out perfectly and sounds fine. Then the label vanishes the moment somebody starts typing, and there is no way to get it back. You are listening for silence and this failure is not silent, which is why it survives almost every self-test. Go and look at your forms with your eyes for this one.
A Thirty-Minute Test Plan
- Open your home page and list the headings. Does the outline describe your page, or does it stop making sense partway down?
- List the links. How many are meaningless out of context?
- Tab through the navigation. Is each item named? Do you know which one is current?
- Go to a product or service page and read from the top. Do the images tell you anything?
- Try your main task: buy, book, or send. All the way through.
- Submit a form with errors on purpose. Is anything announced? Do you know which field?
Write down what you hear rather than trusting memory. It goes by faster than you expect.
Why Your Test Is not the Same as Theirs
This is the part most guides leave out, and it changes what your results mean.
A daily screen reader user runs speech several times faster than you can follow. They navigate by heading, landmark and form field rather than reading top to bottom. And they carry years of workarounds for badly built sites, so they get through things you would call broken. Which cuts both ways. They find problems you will miss, and they route around problems you would have noticed.
So your test answers one question. Is this obviously broken? It does not answer the other one. Is this usable in practice? Those are different questions, and only the second decides whether somebody buys from you.
W3C puts the same caution in stronger terms, and it applies to hiring one participant as much as to testing yourself. Results from one or two disabled people cannot be generalised to everyone with a similar disability, let alone to people with different ones. Which is the argument for combining a real user's session with conformance testing rather than treating either as the whole answer.
One honest limit
This is why every audit we run includes a professional blind screen-reader user on your key journeys rather than a developer imitating one. Your own test is worth doing, and it finds the obvious failures cheaply. It does not replace somebody who depends on the technology trying to actually get something done. Our method page explains where each pass fits.