How to Test With a Screen Reader: A 20 Minute Website Pass

An automated scan tells you which images have no alt attribute and which inputs have no label. It cannot tell you what a person hears when they use your site with a screen reader: whether the button they land on makes sense, whether the error after a failed form submit is ever spoken, or whether the page reads in an order that matches what everyone else sees. For that you have to listen.

The good news is that you do not need to become a screen reader expert. This guide is the smallest routine that finds real bugs: one reader, about a dozen keys, and a pass of roughly 20 minutes per page template. It is for anyone responsible for a website, whether you built it, bought the theme or look after it for a client.

Which screen reader to test with

Pick one that matches what you have on your desk, and get good at it before you add a second.

• On Windows: NVDA with Chrome or Firefox. NVDA is free and open source from NV Access. In the WebAIM Screen Reader User Survey #10 (1,539 responses, December 2023 to January 2024), 65.6% of respondents said they commonly use NVDA and 37.7% named it as their primary desktop reader, second only to JAWS at 40.5%. NVDA with Chrome was 21.3% of reported combinations and NVDA with Firefox 10.0%.
• On a Mac: VoiceOver with Safari. It is built in, so there is nothing to install. Press Command-F5 to turn it on and off (Apple's VoiceOver general commands).
• On a phone: VoiceOver on iPhone. The same survey found 91.3% of respondents use a screen reader on a mobile device, and 70.6% of mobile users use VoiceOver, against 34.7% for TalkBack on Android. If your traffic is mostly mobile, do the pass on a phone too.

JAWS is the other big desktop reader, but it is a paid product. If a client's audience leans on it, such as a government or corporate intranet, add it later. One reader done properly finds far more than three done badly.

The keys that do most of the work

Screen reader users rarely listen to a page from top to bottom. They jump. In the WebAIM survey, 71.6% of respondents said they find information on a long page by navigating through its headings. Your test should move the same way. These are the keys, from the NVDA user guide and Apple's VoiceOver search commands.

Plus Tab and Shift+Tab, which move between interactive controls whatever reader you use. One tip for NVDA: open Speech Viewer from the NVDA menu (NVDA+N, then Tools). It shows every spoken phrase as text, which makes it much easier to copy exactly what you heard into a bug report.

The 20 minute pass

Do this once per page template, not once per page: the home page, a content page, a listing page, a product or detail page, and anything with a form. Turn the screen reader on, put the browser in the middle of your screen and go.

1. Headings list (3 minutes)

Open the Elements list (NVDA+F7, then Headings) or the rotor (VO-U). Read the list on its own, as a table of contents. Is there one heading that names the page? Do the levels describe the structure, or are they chosen for font size? Is a visible section title missing from the list because it is styled text, not a heading? Our headings and landmarks checker catches skipped levels and a missing h1 automatically; this step is for whether the outline makes sense.

2. Landmarks (2 minutes)

Press D repeatedly in NVDA, or open the Landmarks menu in the rotor. You should hear a banner, navigation, main and content information (the footer). If there is more than one navigation, each should have a name, such as "Main" and "Footer", so they can be told apart.

3. Tab through every control (7 minutes)

Go back to the top and press Tab until you reach the bottom. For each stop, listen for three things: its name, its role (link, button, checkbox) and its state (expanded, selected, checked). "Button" on its own, "link, image" or "clickable" are bugs. So is a control you can see but never reach, and a stop where you hear nothing because focus went somewhere invisible. If you have not tested keyboard access yet, our guide on how to test keyboard accessibility by hand covers that part in detail.

4. Submit a form with a mistake in it (5 minutes)

Find the most important form: checkout, sign up or contact. Move through it with F or VO-Command-J and check that each field announces its label, not just its placeholder. Then leave a required field empty, enter an invalid email address and submit. Listen. You should hear that something went wrong, and when you move to the field you should hear what is wrong with it.

5. Open and close the one dialog (3 minutes)

Most sites have one: a cart drawer, a cookie banner, a newsletter popup, a mobile menu. Open it with the keyboard. Focus should move into it and you should hear its name. Tab should stay inside it. Escape should close it, and focus should go back to the button that opened it. Our guide to accessible modal dialogs has the markup when it does not.

Five bugs this pass finds that a scan does not

A wrong accessible name

A scan checks that a button has a name. It cannot check that the name is right. A carousel arrow called "Next slide" in the markup but visually a "Shop now" link, or three "Learn more" links that all go to different places, pass automated checks and fail people (4.1.2 Name, Role, Value, 2.5.3 Label in Name and 2.4.4 Link Purpose).

<!-- Broken: the visible text says one thing, the name says another -->
<a href="/sale" aria-label="Click here">Shop the summer sale</a>

<!-- Fixed: let the visible text be the name -->
<a href="/sale">Shop the summer sale</a>

A silent update

You add an item to the cart, the counter changes from 2 to 3, and the screen reader says nothing. Messages that appear without moving focus, such as "Added to cart", "3 results" or "Saved", need to be announced (4.1.3 Status Messages).

<!-- Broken: the text changes, nobody is told -->
<p class="cart-message"></p>

<!-- Fixed: a live region that exists before the message is added -->
<p class="cart-message" role="status"></p>

Focus that goes nowhere

You press a button that opens a panel or loads a new view, and the next Tab goes back to the top of the page, or into something hidden. On single page apps this often happens after a route change: the URL and content change, focus stays on a link that no longer exists, and nothing is spoken. Focus should move in an order that preserves meaning (2.4.3 Focus Order).

Reading order that does not match the screen

Read a section with NVDA+Down Arrow or VO-A. If the price is read before the product name, or a sidebar lands in the middle of an article, the source order is wrong, usually because CSS moved things visually (1.3.2 Meaningful Sequence).

An error nobody hears

The form turns a border red and shows a message under the field, but the message is not connected to the field and focus does not move. A sighted user sees it; a screen reader user submits again and wonders why nothing happens (3.3.1 Error Identification).

<!-- Broken: the message is near the field, not part of it -->
<input id="email" type="email">
<span class="error">Enter a valid email address</span>

<!-- Fixed: the field is marked invalid and points at its message -->
<input id="email" type="email" aria-invalid="true" aria-describedby="email-error">
<span id="email-error" class="error">Enter a valid email address</span>

How to write up what you found

"The site does not work with screen readers" gets ignored. A report a developer can fix and a manager or client can prioritise has the same five parts for every issue:

• Where: the page URL and the element, in words a sighted person can find ("the Add to cart button under the price").
• Steps: the reader and browser, and the keys you pressed.
• What you heard: copied from Speech Viewer, in quotes.
• What you expected: what a user needed to hear instead.
• Criterion and fix: the WCAG success criterion and one line on the fix.

Sort by impact on a task, not by count: one checkout error nobody hears matters more than ten decorative images with redundant alt. And be honest about scope. A screen reader pass on five templates is a sample, not a certification, and neither it nor any scan can show that a whole site conforms to WCAG. Our accessibility audit checklist shows where this pass fits in a full audit.

Let the scan do the counting first

Listening is slow, so do not spend it on things a machine finds. Run a free accessibility scan first, fix the missing labels, alt text and contrast it reports, then do the screen reader pass for the things only a person can judge. AccessGuard runs automated WCAG 2.2 AA checks in a real browser, including the keyboard and focus checker, so the pass starts from a cleaner page. Our guide to keyboard navigation covers the fixes for most of what step 3 turns up.

Your screen reader checklist

• Install NVDA on Windows, or use VoiceOver on a Mac. Learn the keys in the table above and open Speech Viewer.
• List the page templates: home, content, listing, detail, and every form.
• For each one: headings list, landmarks, Tab through every control, submit a form with mistakes, open and close the dialog.
• Listen for wrong names, silent updates, lost focus, odd reading order and unheard errors.
• Write each issue with where, steps, what you heard, what you expected, criterion and fix.
• Repeat on an iPhone with VoiceOver if most of your visitors are on mobile.
• Rerun the pass after the fixes ship, and after any theme or template change.