Screen readers: how they work and how to test with one

A screen reader turns the accessibility tree, the structured representation the browser builds from your markup, into speech or braille. It does not read the visual page. That distinction explains almost every surprise people have the first time they hear their own site.

If a heading is a styled div, the screen reader has no heading to announce. If a button is a div with a click handler, it is not in the tab order and not announced as a button. If a form field’s label is a paragraph positioned above it, the field is announced as unlabelled. The visual result looks identical in all three cases.

What users actually run

Screen reader use is concentrated in a few combinations, and testing follows usage rather than market share of the underlying platform.

Browser pairing matters. NVDA and JAWS are usually tested with Chrome or Firefox, VoiceOver with Safari. A combination outside those pairings can produce behaviour that neither the screen reader nor the browser considers a bug.

Your first twenty minutes

You do not need a licence or a lab. Start with what is already on the machine.

Turn it on. On macOS, Command plus F5. On Windows 11, Ctrl plus Windows plus Enter starts Narrator; NVDA is a free download and closer to what people use. On iOS, set the accessibility shortcut to VoiceOver and triple-click the side button.

Then do three things, with the screen still visible. Sighted testing with the screen on is not the real experience, but it teaches you the mapping between what you built and what is announced, which is what you need first.

1. Listen to the page load. Is the page title meaningful and unique? Is the language announced correctly, or is your German page being read with an English voice engine because lang is wrong?

2. Pull up the heading list. In NVDA that is the H key to move by heading, or Insert plus F7 for the element list. Does the heading order describe the page? Is there exactly one H1? Are there headings that exist only to make text big?

3. Tab through one complete task. Not the homepage: a real task, the one your users came for. Every stop should announce what it is, what it does, and its current state. Watch for focus disappearing into a hidden menu, for a modal that does not trap focus, and for focus landing behind a sticky header, which is the WCAG 2.2 criterion 2.4.11.

That third exercise finds more real barriers than any automated scan.

What to fix first

The findings sort themselves into a reliable order.

Unlabelled controls come first, because they make a task impossible rather than awkward. Then keyboard traps and unreachable controls, for the same reason. Then heading structure, because it is what people use to navigate rather than read. Then link text, where “read more” repeated fourteen times is the classic failure, since screen reader users routinely pull up a list of links out of context. Then alternative text quality, which matters but rarely blocks a task.

Contrast, spacing and target size are real criteria, but they belong to a different testing pass and different users. Do not mix the lists.

The limits of doing it yourself

Testing with a screen reader you have used for twenty minutes tells you whether your page is navigable. It does not tell you whether it is usable for someone who has used one for twenty years and moves at three hundred words per minute with the screen off.

For anything where the stakes are real, budget one session with actual users. Our testing walkthrough covers what to prepare so that session finds design problems rather than the things you could have caught yourself.