How Do You Test a Site With a Screen Reader?

How do you test a site with a screen reader?

Turn one on, close your eyes for the first page, and try to complete the main task using only the keyboard. Twenty minutes of that finds more real problems than an afternoon of automated scans. You do not need to be an expert user, and you do not need permission from anyone.

Most teams never do it. They run a scanner, fix what it flags, and ship a site that technically passes while being miserable to use with a screen reader.

This is the routine we run before launch, written so a developer or a designer can follow it today.

Why is automated testing not enough?

Because scanners only see a slice. WebAIM's February 2026 Million report analysed one million home pages and found detected WCAG 2 failures on 95.9 percent of them, averaging 56.1 errors per page. Those are the machine-detectable ones, and they are only the start.

The same report notes that six categories account for 96 percent of all detected errors: low contrast text at 83.9 percent of pages, missing image alternative text at 53.1 percent, missing form input labels at 51 percent, empty links at 46.3 percent, empty buttons at 30.6 percent, and missing document language at 13.5 percent.

Every one of those is a code-level defect a tool can find. What a tool cannot tell you is whether the reading order makes sense, whether the modal traps focus sensibly, or whether the labels mean anything to a human. Our notes on automated accessibility testing cover what to automate and why it is still worth doing.

Which screen reader should you test with?

Whichever you can start with in the next ten minutes, then the market leaders. WebAIM's tenth Screen Reader User Survey, run in December 2023 and January 2024 with 1,539 valid responses, put JAWS at 40.5 percent of primary desktop use and NVDA at 37.7 percent, with VoiceOver at 9.7 percent.

Pair it with the right browser, because the combination changes behaviour. The survey's top pairings were JAWS with Chrome at 24.7 percent, NVDA with Chrome at 21.3 percent, and JAWS with Edge at 11.4 percent. Chrome led browser use overall at 52.3 percent.

The practical answer for a small team: test with whatever is on your machine, then get one person set up with NVDA and Chrome for the real pass. Perfect coverage is not the goal. Finding the top three defects is.

What are the first keystrokes to learn?

Five will carry you a long way. Tab to move through interactive elements. Arrow keys to read line by line. The heading shortcut to jump between headings. The landmark shortcut to move between regions. And the elements list, which opens a list of every heading or link on the page.

The heading and elements shortcuts are the ones that tell you the most, because they show how the page is structured rather than how it looks. A page whose heading list reads like a table of contents is usually a well-built page.

Learn the stop key too. Every screen reader has a way to silence speech immediately, and knowing it removes most of the anxiety people feel the first time they try this.

How do you run a twenty minute smoke test?

Four passes, five minutes each. First, listen to the page load and note what is announced before you touch anything. Second, tab through every interactive element in order and check that focus is visible and the order is sane. Third, jump by headings. Fourth, complete the main task.

Write down every moment you were confused, not just the broken things. Confusion is the finding. If you cannot tell whether a button submitted the form, neither can anyone else.

Do it on the real page in a browser, not in a component library. Most failures live in the seams between components, which is exactly what a storybook hides.

What does a good heading pass sound like?

Like an outline someone wrote on purpose. One H1 naming the page, H2s for each major section in the order they appear, and no jumps from H2 to H4 to look right visually. If the headings do not make sense read aloud in sequence, the page has a structure problem, not a styling problem.

Two smells come up constantly. Headings used for emphasis on short lines of marketing copy, and whole sections with no heading at all because the design used a big paragraph instead.

Fixing these usually improves search performance at the same time, which is a nice argument to have available. Our piece on why semantic HTML matters covers the overlap.

How do you test forms?

Tab into every field with your eyes shut and see whether you know what to type. Each field should announce its label, its type, whether it is required, and any format requirement. Placeholder text alone is not a label, and it disappears exactly when someone needs it.

Then break it on purpose. Submit empty, submit with a bad email, and listen. The error should be announced, focus should move somewhere useful, and the message should say what to do rather than what went wrong.

Given that WebAIM found missing input labels on 51 percent of home pages, assume your forms have a problem until you have heard them yourself.

What about mobile?

Test it, because that is where a large share of real usage sits. WebAIM's survey found VoiceOver used by 70.6 percent of respondents on mobile and TalkBack by 34.7 percent, with iOS devices dominating the mobile screen reader market. Both ship on the phone already, so there is nothing to install.

Mobile testing catches different bugs: swipe order that skips content, custom menus that cannot be dismissed, sticky headers that swallow focus, and tap targets announced as generic buttons.

Fifteen minutes on a phone with the built-in screen reader is one of the cheapest quality checks available, and almost nobody on a marketing team has ever done it.

What do automated tools still catch best?

The boring, high-volume defects, which are most of them by count. Contrast ratios, missing alternative text, unlabelled inputs, empty links, empty buttons and a missing language attribute are all better found by a machine that checks every page and never gets tired or bored.

So run both. Scanners in the pipeline to stop regressions, a human pass before launch and after any significant redesign. The WebAIM data is a good argument for the pipeline half: average errors per page rose 10.1 percent in a year, from 51 to 56.1, while page elements grew 22.5 percent.

More complexity, more defects. That relationship is not going to reverse on its own. Our WCAG guide sets out which criteria to prioritise when the list feels endless.

How do you make this a habit?

Put it in the definition of done and give it a time box. Twenty minutes of screen reader testing on any new template, fifteen on mobile, before it goes live. Short enough that nobody negotiates it away, long enough to find the things that matter.

Record the findings in the same tracker as everything else. Accessibility work that lives in a separate document gets treated as a separate project, which is how it ends up deferred forever.

If you want us to run this pass on your site and show you what we hear, we are happy to help. You can see how we build for accessibility at phoenix.studio.