Screen reader testing: a first test for site owners

What a checker cannot hear

An automated checker reads your page's code and reports what is missing: an image with no alt attribute, a field with no label. It cannot tell you that the alt text says "image1", that the headings make no sense in order, or that a booking error appears on screen and is never spoken. W3C says it plainly in its guide to choosing tools:

Tools cannot check all accessibility aspects automatically. Human judgement is required.

The Department of Justice's web guidance says the same about automated checkers: they need to be used carefully, a clean report does not mean everything is accessible, and they should be paired with a manual check. A screen reader is the most direct manual check there is, because it is what a blind visitor uses to hear your page. Our testing tools comparison lists it in the manual kit beside the checkers; this guide is the session itself, sized for an owner, not an auditor.

Before you start: one screen reader, one browser

Use the screen reader your own computer already supports. NVDA is a free, open-source screen reader for Windows from NV Access; it runs on 64-bit Windows 10 and 11. Download it from nvaccess.org and let the installer set up the Control+Alt+N shortcut that starts it. VoiceOver is the screen reader built into macOS; Command-F5 turns it on or off. On an iPhone it lives in Settings, Accessibility, VoiceOver, and Apple's VoiceOver Practice there lets you try every gesture before it does anything.

Pair it with one browser and stay with it for the whole session: NVDA's user guide lists Firefox, Chrome and Edge among the programs it reads in browse mode, and on a Mac, Safari is Apple's own. A problem that shows up in one pairing and not another is still a lead worth writing down.

Three habits that save the first ten minutes

• Read along. NVDA's Speech Viewer, ticked in the Tools menu, shows in a window every word it speaks. VoiceOver shows its words in a caption panel. You will miss half of what you hear at first; the text lets you check.
• Know the off switch. Control silences both. Command-F5 turns VoiceOver off; NVDA+Q, then Enter, quits NVDA.
• Read, do not just Tab. Tab moves only between links, buttons and fields, so a Tab-only test never hears a heading, a paragraph or a picture. Read with the arrow keys and the jump keys on the card above. When NVDA reaches a text field it switches to focus mode so your typing goes into the field, and Escape takes you back to reading.

What to listen for

You do not have to listen to a whole page from top to bottom. Both screen readers can pull a page apart into lists: NVDA's Elements list (NVDA+F7) shows the links, headings, form fields, buttons or landmarks, and VoiceOver's rotor (VO-U) does the same on a Mac. On an iPhone, turn the rotor to Headings and swipe down. A screen reader user skims a page this way, so the lists are also the fastest test you can run.

Two rows deserve a second listen. A list of links strips away the sentence around each link, and WCAG lets a link take its meaning from that sentence, so five "Learn more" links are a sign to check each in place rather than a fail on their own. And the last row is the one checkers miss most: whether a message that appears after you press something is spoken at all. Test it on purpose by sending a form with a mistake in it.

A 15-minute routine for one page

Start with the page that earns money: the booking form, the cart, the quote request. Fifteen minutes is enough for one page if you keep to the lists and write as you go. The sheet below holds the steps; mark each one as you finish it, and print or copy the result for whoever fixes the site.

Run it again on the home page and on one long article, and you have tested the three kinds of page most small sites are made of. Then repeat it after every theme update, because a new theme can change the headings and buttons on every page at once.

Where each problem gets fixed

Most of what you hear wrong is fixed in your own editor, without a developer. The rest lives in the theme or the plugin that drew the part, and goes to whoever maintains it.

• Title. The page title or SEO title field in your site builder. Name the page first, then the business.
• Headings. Use the editor's Heading 2 and Heading 3, never bold text at a bigger size. A heading the list cannot find is not a heading.
• Link names. Rewrite the link text to say where it goes. Our accessible website examples show the pattern on a working page.
• Alt text. Write it in the image's alt field, and leave it empty for decoration. The alt text examples cover product photos, logos and icons.
• Labels and errors. Usually the form plugin's settings; the guide to accessible forms has the label, hint and error pattern.
• Unnamed buttons and missing landmarks. These are in the theme's code. Send the theme maker or your developer what you heard and the criterion number.

The most common button fix is one attribute. An icon button with no text has no name to speak, so it is read as "button" and nothing else; an aria-label gives it one (4.1.2 Name, Role, Value):

<!-- Heard as "button" -->
<button><svg aria-hidden="true">…</svg></button>

<!-- Heard as "Search, button" -->
<button aria-label="Search"><svg aria-hidden="true">…</svg></button>

What a screen reader test cannot tell you

A screen reader hears the code, not the screen. Everything a sighted visitor with low vision, a keyboard user or a deaf visitor depends on can be broken while the page sounds perfect:

• Contrast and colour. Pale grey text is read out like any other. Measure it with the contrast check.
• Visible focus. The screen reader knows where focus is even when no ring shows it. Walk the page by keyboard with the screen reader off, using the focus order checklist.
• Captions. A video's sound track plays whether or not it is captioned; check against the caption requirements.
• Zoom and reflow. Whether text still fits at 200 percent (1.4.4) and the page reads at 320 CSS pixels wide without sideways scrolling (1.4.10).

Your own ear has limits too. You are a new user of a tool that people use for hours a day, and W3C's guide to involving users lists the user not knowing the assistive technology's keys as one of the causes of a problem, beside the page's code, the browser and the screen reader itself. So treat what you hear as leads, not verdicts, and do not read one clean session as proof that a page works for everyone. The same guide gives the warning that applies to any single test:

Avoid assuming that input from one person with a disability applies to all people with disabilities.