How to test a website with a screen reader

Choose a screen reader and browser

Three screen readers cover most desktop users. In WebAIM's 2024 survey of screen reader users, the primary desktop screen reader was JAWS for 40.5% of respondents, NVDA for 37.7% and VoiceOver for 9.7%; the most common combinations were JAWS with Chrome (24.7%), NVDA with Chrome (21.3%) and JAWS with Edge (11.4%) (WebAIM, 2024).

• NVDA is “a free and open source screen reader for the Microsoft Windows operating system” (NV Access, 2026). With Chrome, it is the cheapest way to test a combination many real users have.
• VoiceOver is built into macOS and turns on with Command-F5 (Apple, 2026).
• JAWS is the most common primary screen reader in the survey. Its commands are documented in Freedom Scientific's keystroke reference (opens in a new tab).

If you can only test one, start with NVDA and Chrome. Add VoiceOver when your audience includes Mac users, and use a second screen reader whenever something sounds wrong — screen readers interpret the same markup differently, and a problem in only one of them is still a problem for its users.

The commands that matter

You need far fewer commands than the manuals list. These cover reading, moving by structure, forms and tables. In NVDA, the NVDA key is Insert or Numpad 0 by default (NV Access, 2026). In VoiceOver, VO means Control and Option pressed together, or Caps Lock (Apple, 2026).

On web pages NVDA works in two modes. In browse mode, single letters move between kinds of content, such as H for headings. In focus mode, keystrokes go to the control you are in, so you can type into a field. NVDA+Space switches between them.

Commands were checked against NV Access's and Apple's documentation on the date this guide was last updated. Screen readers change their defaults between versions, so if a key does nothing, check the current reference for your version.

A step-by-step screen reader test

Run these steps on the pages that matter most — your home page, a key landing page, and every page in your most important task. Keep notes of what was announced, not just what went wrong.

1. 1Load the page and listen to how it starts

   Open the page fresh with the screen reader running and let it announce. The page title should say what the page is, and the content should be read in the right language.

   Listen for: A title that names this page rather than the whole site, and speech in the correct language.

   WCAG 2.4.2 · 3.1.1

2. 2Move through the page by headings

   Press the next-heading key repeatedly, or open the elements list or rotor to see every heading at once. Most screen-reader users find information this way, so the outline has to make sense on its own.

   Listen for: Headings that describe their sections, in a logical order, with no visual headings missing from the list.

   WCAG 1.3.1 · 2.4.6

3. 3Move through the page by landmarks

   Jump between landmarks and check that the banner, navigation, main content and footer are all there, and that a skip link or landmark lets you bypass repeated navigation.

   Listen for: A main landmark that holds the page’s content, and a way past the navigation.

   WCAG 1.3.1 · 2.4.1

4. 4Tab through every interactive element

   Press Tab from the top of the page to the bottom. At every stop, note what is announced and whether the order follows the visual layout.

   Listen for: A name, a role and any state for every control — “Menu, button, collapsed” rather than “button” or nothing.

   WCAG 2.4.3 · 4.1.2

5. 5Check images, icons and links

   Move through graphics and links. Informative images need text alternatives, and an icon-only button or link still needs a name.

   Listen for: Alternatives that describe what the image conveys rather than a file name, and names on icon-only buttons and links.

   WCAG 1.1.1

6. 6Fill in and submit a form

   Complete a real form. Leave a required field empty and submit, then check how the error is conveyed and where focus goes.

   Listen for: A label and required state for every field, and errors that are announced and identify the field in text.

   WCAG 3.3.1 · 3.3.2 · 4.1.2

7. 7Trigger updates that do not reload the page

   Add to cart, apply a filter, open a dialog, save a setting. After each action, stop and listen before moving on.

   Listen for: Status messages announced without focus moving to them, and focus moving into a dialog when it opens.

   WCAG 4.1.3 · 2.4.3

8. 8Complete the whole task

   Finish the job the page exists for — checkout, sign-up, booking — using the screen reader alone. A page can pass every check above and still leave the task impossible.

   Listen for: The moment you would give up. Write down the step and what was announced there.

   WCAG Several, in sequence

Step 2 comes before Tab for a reason: in the same survey, 71.6% of respondents said navigating through headings is how they first try to find information on a lengthy page (WebAIM, 2024). Success criteria referenced are from WCAG 2.2 (W3C, 2023).

Common mistakes manual testers make

• Only pressing Tab. Tab reaches interactive elements, not content. A page can tab perfectly and still have no usable headings.
• Watching the screen. Sight fills in what speech leaves out. A button that looks obvious may be announced as just “button”.
• Using the mouse to recover. The moment you click to get unstuck, you have found the barrier — write it down instead of working around it.
• Testing pages, not tasks. Every page of a checkout can pass on its own while the path between them fails.
• Stopping speech too fast. Status messages and errors arrive after an action. Wait and listen before pressing the next key.
• Blaming the screen reader. Some quirks are the screen reader's, but check the markup before dismissing one — most turn out to be the page.

Keyboard behaviour deserves its own pass; see how to test keyboard-only navigation. For the two failures screen reader tests find most often after an action, read ARIA live region testing and focus management after a modal.

Where automation fits

Manual screen reader testing is slow, so it tends to happen once before a launch and not again. The risk is the release after that. Automation cannot replace a person listening, but it can repeat the parts of this test that do not need judgment on every release.

Accessible's journey testing runs a simulated screen-reader user through a task in a real browser, keyboard only, moving by heading, landmark, role and tab order, and reports the step it could not get past with what was announced there. It does not drive NVDA, JAWS or VoiceOver: the announcements are computed from the roles and accessible names the browser exposes. That makes a run repeatable, and it is also why the occasional test by a real screen-reader user still matters.