Tutorials Accessibility

Testing With a Screen Reader: A Practical First Session

Intermediate · ~18 min

Overview

Automated accessibility checkers find objective failures and cannot tell you whether a page is actually usable. The only way to know that is to use it the way someone else does, and every operating system already includes a screen reader at no cost. The first session is disorienting, which is exactly why it is valuable. This guide covers how to start one safely, the few commands you need, what to listen for, and how to interpret what you hear without over-generalising from a single test.

What You Need

A computer: macOS, Windows, and Linux all include a screen reader
Headphones, so you are not broadcasting to the room
One of your own pages to test
Knowledge of how to turn the screen reader off again, before you turn it on
Twenty minutes and tolerance for feeling incompetent
A notepad for what you find

Steps

Learn the off switch before the on switch

A screen reader takes over keyboard behaviour and speaks continuously, which is disorienting the first time. Find and memorise the shortcut to turn it off before you turn it on, macOS uses Command-F5 for VoiceOver, Windows uses Control-Windows-Enter for Narrator. Knowing you can stop it removes most of the anxiety.

Learn four commands, not forty

You need: move to the next item, read the current item, list the headings on the page, and list the links. Those four cover the majority of a basic test. The exact keys differ between readers and are in each one's help, but the concepts are identical everywhere. Do not try to learn a full command set before starting.

Listen to the page structure first

Bring up the headings list. It should read like a sensible outline of the page. That is how many screen reader users navigate, rather than reading top to bottom. If the headings are missing, out of order, or used for visual sizing rather than structure, the page is hard to navigate regardless of how it looks.

Then listen to the links

Bring up the links list. Screen reader users frequently navigate this way, out of context. Links that read "click here", "read more", or a bare URL are useless in that list. Link text should describe its destination on its own.

Now move through the page in order

Go item by item from the top. Listen for images announcing filenames instead of descriptions, buttons announcing as "button" with no name, form fields with no label, and anything that is skipped entirely. Note what you hear rather than trying to fix it immediately.

Interpret carefully and fix the clear failures

You are a beginner with this tool, so some of what feels wrong is your unfamiliarity rather than a defect. But some findings are unambiguous: an unlabelled control, an image read as "D S C zero four four seven", a heading structure that makes no sense. Fix those. Treat the rest as questions rather than conclusions.

Pro Tips

Use headphones. Screen reader speech at speed in an open office is disruptive and you will turn it off too soon.
Slow the speech rate down at first. Experienced users run it very fast. You cannot follow that yet.
Test a page you wrote. Testing an unfamiliar site teaches you the tool. Testing your own teaches you your work.
Close your eyes for part of the test. It stops you compensating with what you can see on screen.
One session is enough to change how you build. You do not need to become proficient.

Knowledge Base

What You'll Learn

This is the accessibility skill with the best ratio of effort to insight, twenty minutes changes how you write markup permanently. Below: what a screen reader actually does, and how to avoid the two ways this test gets misused.

What a Screen Reader Is Actually Doing

A screen reader is not simply reading the visible text aloud. It builds a model of the page from the underlying structure and lets the user navigate that model, which is why semantics matter so much more than appearance.

When it encounters a heading, it announces it as a heading at a particular level, and the user can jump between headings to skim. When it encounters a button, it announces the control type and its state. When it encounters an image, it reads the alt text, or the filename if there is none.

This is why a styled container that looks like a button is invisible: there is nothing in the structure saying it is interactive. And it is why using a heading element purely to make text large corrupts navigation, since it inserts a false entry into the outline people use to move around.

The practical takeaway is that a screen reader test is really a test of whether your markup says what your design means.

Two Ways This Test Gets Misused

Treating your own confusion as a defect. A first session is genuinely disorienting: the speech is fast, the navigation model is unfamiliar, and everything feels difficult. Some of that is the interface being new to you, not the page being broken. Daily users are extremely fluent with tools that feel impossible on day one. Report the unambiguous failures and hold the rest lightly.

Treating one test as sufficient. Screen readers differ from each other and behave differently across browsers, and real users have configurations and habits you do not. Passing your own test with one reader is a good signal, not a guarantee, and it is not a substitute for testing with people who actually use assistive technology where that is possible.

Held with those two caveats, the test remains the single most useful accessibility exercise available, because it converts an abstract obligation into a concrete experience.

Where This Fits

This guide covers one specific part of accessibility. The wider picture, conformance levels, the difference between captions, subtitles, and audio description, and building access into the workflow rather than retrofitting it, is in Publishing Accessible Video: A Practical Compliance-Era Checklist, which frames the discipline as a whole and links out to the detailed guides underneath it, including this one. If you are starting from scratch rather than solving a specific problem, read that first and come back here.

FAQ

Q: Which screen reader should I test with?
A: Start with whatever is already on your computer. VoiceOver on macOS, Narrator on Windows, Orca on many Linux distributions. NVDA on Windows is free and very widely used if you want a second. The goal of a first session is insight into your own markup, not coverage across every combination.

Q: I found it impossible to use. Does that mean my site is broken?
A: Not necessarily. A first session is disorienting for everyone, and experienced users are fluent with tools that feel unusable on day one. Separate the unambiguous findings (unlabelled buttons, images read as filenames, nonsensical heading order) from your own unfamiliarity, and act on the former.

Q: Is a screen reader test enough on its own?
A: No. It complements automated checking rather than replacing it, and neither substitutes for testing with people who actually use assistive technology daily. Automated tools catch objective failures at scale. Your own session catches usability problems tools cannot see. Real users catch what neither finds.

Q: How long does a useful first session take?
A: About twenty minutes. Learn the off switch, four navigation commands, then listen to the headings list, the links list, and one pass through a page you wrote. That is enough to change how you write markup permanently, which is the actual point.