Testing with a screen reader.

Screen reader testing means auditing a page by listening to it through assistive technology — the one method no automated tool can replace.

There is a threshold in accessibility auditing: the point where automated tools end. A tool can say whether an alternative text exists; it cannot say whether that text describes the image correctly. It can say a heading is an h2; it cannot say whether that heading really describes the section beneath it. The answers to these questions are found only by listening.

Screen reader testing is skipped by most teams, and the reason is psychological, not technical: on the first try the experience is foreign and overwhelming. The voice is fast, the shortcuts unknown, the page unrecognizable. That feeling is normal and passes within a few hours. Once it passes, you are left with an auditing ability no other tool can provide.

Which screen reader

The choice of screen reader depends on the platform being audited and the audience. Installing all of them is unnecessary; learning one well is worth more than knowing all of them superficially.

1. NVDA — Windows, free and open source. One of the most used on desktop and the easiest start for testing.
2. JAWS — Windows, commercial. Common in corporate environments; small teams tend to avoid it for the license cost.
3. VoiceOver — built into macOS and iOS. No installation needed; anyone with an Apple device can try it immediately.
4. TalkBack — built into Android. The counterpart for mobile web testing.
5. Narrator — built into Windows. The easiest to reach, but not as widely used as the others.

The practical advice: start with what you have. On a Mac, VoiceOver is already installed and opens with a single shortcut; on Windows, NVDA is free. What matters for testing is not which software you use but that you have walked the page by listening.

A warning: screen readers behave differently from one another, and the same page can sound different in different readers. Working in one reader therefore does not mean “works everywhere.” But BREAKING in one reader is almost always a real defect — that is where the test’s value comes from.

What to listen for: four tours

Following a structured tour instead of listening at random is both faster and catches more defects. Four tours expose the bulk of a page’s accessibility state.

1. The heading tour — open the heading list and listen. Does the list tell the page? Does it read like a table of contents, or is it scrambled? Any missing or empty headings?
2. The landmark tour — move between landmarks. Are the menu, main content and footer recognized separately? Any unnamed or duplicated regions?
3. The link tour — open the link list. Do the link texts make sense out of context? With five “Read more” entries, which goes where is unknowable.
4. The form tour — fill the form end to end and submit. Is every field’s label heard? Is the error message announced? Is the success message announced?

The link tour is especially instructive because it surfaces a problem a sighted user never notices. “Read more” links make sense in visual context — you can see which article they sit under. In the link list there is no context, and five identical rows remain. The fix is making the link text meaningful on its own.

The form tour yields the most defects. Unlabeled fields, unannounced errors, silent success messages and lost focus — they all surface here. And these are the site’s most expensive defects, because the form is usually the single conversion path.

The automated tool says the alternative text EXISTS; the screen reader says whether it WORKS.

Using it for the first time

A few practical points ease the first attempt, and knowing them prevents the give-up most people reach in the first five minutes.

1. Lower the speech rate — the default speed is tuned for experienced users and is incomprehensibly fast for a beginner.
2. Use headphones — on open speakers the page audio and the reader’s voice blend.
3. Try turning the screen off — closing your eyes or darkening the screen stops you from assuming what you see. The test becomes much more honest this way.
4. Note the shortcuts — write your reader’s basic navigation shortcuts on paper. They change between versions, so keep your own list instead of memorizing.
5. Learn how to turn it off beforehand — this is what panics people most on the first try.
6. Try a known-good site first — listen to a well-built site, learn what the experience should sound like, then test your own.

The last item helps the most. Without a reference point you cannot tell whether the chaos you hear is your site’s defect or the screen reader’s normal behavior. Listening to a well-built page once teaches that distinction instantly.

Frequency and scope

Screen reader testing cannot run on every deployment — it takes time and cannot be automated. The right question is therefore not “how often” but “what”: which screens must be listened to.

The practical answer is the conversion paths. The contact form, search, sign-in, checkout — the screens where the user DOES something. These are both the most critical and the most often broken. A flawed information page annoys; a flawed form ends the business.

Once the scope is set, the frequency follows: whenever those screens change. When a new component lands, when the form flow is reworked, when the layer system changes. In the deployments between, automated tests and a manual keyboard tour suffice.

And for every defect found, one question must be asked: can I bind this defect to a test? The answer is usually yes — an unannounced message can be caught by a test checking the live region’s presence. The screen reader test FINDS the defect; the guard keeps it from returning.

Typical defects caught while listening

There is a list of defects that surface again and again in screen reader tours, and none of them shows up in automated audits. Knowing the list in advance means knowing what to hunt on the first tour, and it makes the test markedly more efficient.

1. The silent button — a button carrying an icon but no accessible name. The screen reader says “button” and stops; what it does is unknown.
2. The talking decoration — a decorative image read out by its file name. Happens when the alternative attribute is forgotten.
3. The lost focus — focus dropping to the top of the page when a layer closes. The user loses their place and starts over.
4. The unannounced change — the form was submitted, the message appeared on screen, the screen reader said nothing.
5. The repeated content — the same information in both the alternative text and the heading beside it; the user hears the same sentence twice.
6. The senseless order — two pieces of information sitting side by side visually, read disconnected from each other when listening.
7. The unhidden hidden content — menus visually hidden but not removed from the accessibility tree; the user wanders among invisible links.

The last item is especially insidious because the defect appears only in one state: while the menu is closed. Nobody testing with a mouse sees it, automated tools usually miss it, and the user navigates among elements that do not exist on the page. It is a good example of why listening cannot be replaced by any other method.

What these defects share is that all of them pass the “does it exist” question and fail at “is it right.” The button has a text but a meaningless one; the message is on the page but unannounced; the menu is hidden but in the accessibility tree. Automated auditing measures the first half; listening measures the second.