Screen Reader Testing: How to Test Your Website with NVDA and VoiceOver

Screen reader testing means using your website the way a blind or low-vision visitor does: with the screen reader announcing each element and the keyboard (or touch gestures) doing the navigating. It's the most direct way to check whether your headings, links, images, forms and custom controls make sense when they're heard instead of seen.

To start, you need one free screen reader and one browser. On Windows, install NVDA and use it with Chrome or Firefox. On a Mac or iPhone, VoiceOver is built in; use it with Safari. Learn about ten commands, then work through a page with a short script: page title, headings, landmarks, images, links, forms, error messages and anything that opens or updates. This guide gives you all three: the pairings, the commands and the script.

Screen reader testing finds problems automated tools can't, because a scanner never hears the page. Our article on automated vs manual accessibility testing explains where that line falls.

Which screen readers and browsers to test with

The best data on what people actually use comes from WebAIM's Screen Reader User Survey #11, conducted in July and August 2026 with 1,780 valid responses. Among respondents:

• Primary desktop or laptop screen reader: JAWS 55.0%, NVDA 32.9%, VoiceOver 6.5%.
• Most common screen reader and browser combinations: JAWS with Chrome 31.2%, NVDA with Chrome 17.3%, JAWS with Edge 17.0%, NVDA with Firefox 9.1%.
• Mobile screen readers commonly used: VoiceOver 72.2%, TalkBack 29.5%.

WebAIM notes the sample was not controlled and may not represent all screen reader users, and 54.1% of respondents were in North America. Shares also move between surveys: in Survey #10 (December 2023 to January 2024), JAWS was at 40.5% and NVDA at 37.7%. Use the numbers to choose pairings, not to predict your own audience.

For most teams, this gives a practical test matrix:

If you can only do one, NVDA with Chrome on Windows covers a large share of desktop use at no cost. If you can do two, add VoiceOver on an iPhone. Different screen readers interpret the same code differently, so testing more than one helps you separate a bug in your site from a quirk in one product.

Before you start

• Learn how to stop it talking first. On NVDA and VoiceOver for Mac, press Control. On iPhone, tap with two fingers.
• Set an exit route on iPhone. Before turning VoiceOver on, go to Settings > Accessibility > Accessibility Shortcut and choose VoiceOver. Then a triple-click of the side button (or Home button) turns it on and off. Otherwise the gestures change, and new testers get stuck.
• Use a visual transcript. NVDA's Speech Viewer (NVDA menu, then Tools) shows everything NVDA says as text, which makes notes and screenshots much easier.
• Know the two modes. Screen readers read web pages in a browse or reading mode, where single letters jump between elements, and switch to a focus or forms mode for typing into fields. Most confusion in early testing comes from not knowing which mode you're in.
• Don't look at the screen for the first pass. Or at least don't trust it. The point is to hear what the code says, not what the layout shows.

NVDA testing on Windows: the commands you need

Download NVDA free from NV Access. The NVDA key is Insert by default. These commands come from the NVDA command quick reference; in browse mode, add Shift to any single-letter key to move backwards.

VoiceOver testing on macOS and iOS

VoiceOver on a Mac

The VoiceOver modifier, written "VO," is Control + Option, or Caps Lock. Commands below are from Apple's VoiceOver User Guide. To test keyboard access in Safari without VoiceOver, also turn on "Press Tab to highlight each item on a webpage" in Safari's Advanced settings.

VoiceOver on iPhone and iPad

Turn it on in Settings > Accessibility > VoiceOver, or with the Accessibility Shortcut set up above. Apple's guide to VoiceOver gestures on iPhone lists them all; these are enough for a first test.

A screen reader testing checklist for any page

Run this script on each page template and on the key journeys (contact form, booking, checkout). For each step, note what you heard, what you expected, and the WCAG criterion involved.

1. Page title. On load, does the announced title identify the page and the site? (2.4.2 Page Titled)
2. Language. Is the content read in the right voice and pronunciation? A French page read with English pronunciation points to a missing or wrong lang attribute. (3.1.1)
3. Headings. Open the elements list or rotor. Is there one H1 that names the page? Do the headings outline the content, at levels that reflect the structure? (1.3.1, 2.4.6)
4. Landmarks. Can you jump to the header, navigation, main content and footer? (1.3.1)
5. Skip link. Press Tab once from the top. Is there a "skip to main content" link, and does it move you there? (2.4.1 Bypass Blocks)
6. Reading order. Use say all from the top. Does the content come out in an order that makes sense? Is anything hidden on screen still being read, or anything visible being skipped? (1.3.2)
7. Images. Do informative images announce useful alt text, and do decorative images stay silent? Do you hear any file names? (1.1.1)
8. Links. Open the links list. Would each link make sense with only its text, or at least with its surrounding sentence? (2.4.4)
9. Buttons and custom controls. Does every button have a name? Do menus, accordions and tabs announce their state, such as "expanded" or "collapsed," and update when you activate them? (4.1.2)
10. Form fields. Tab through each form. Is every field's label read, along with whether it's required and any instructions? (1.3.1, 3.3.2)
11. Form errors. Submit the form empty or with a mistake. Is the error announced or easy to find, and does it say which field and how to fix it? (3.3.1, 3.3.3)
12. Dialogs and pop-ups. When a modal opens, does focus move into it, stay in it, and return to the trigger when it closes? Can you close it with Escape? (2.4.3, 2.1.2)
13. Dynamic updates. When something changes without a page load, such as search results, an "added to cart" message or a loading spinner, is it announced? (4.1.3, a WCAG 2.1 criterion)
14. Data tables. When moving between cells, are the column and row headers read? (1.3.1)
15. Mobile pass. Repeat the key steps with VoiceOver on an iPhone, swiping through the whole page. Is anything unreachable, or reached in a confusing order?

Many of these overlap with keyboard checks, so it's worth running our keyboard accessibility tests first. Problems with forms are common enough to have their own guide: form field accessibility.

Common screen reader findings and what they mean

Several of these come from ARIA used incorrectly, or not at all where custom components need it. Our guide to ARIA best practices covers when to use it and when native HTML does the job better.

The limits of testing it yourself

Sighted testers using a screen reader for the first time navigate differently from someone who uses one every day. Experienced users rely on shortcuts, quick lists and their own settings, and they have workarounds you won't think of. That cuts both ways: you'll trip over things that wouldn't bother them, and miss things that would.

Not every difference between screen readers is your bug, either. If something works in NVDA but not in VoiceOver, check whether your code follows the standard before rewriting it for one product. WCAG doesn't require testing with any particular screen reader; it requires outcomes, and screen reader testing is how you check several of them in practice. For evidence you can rely on, such as for an AODA compliance question or a procurement requirement, combine your own testing with an expert audit and, where you can, testing by people who use assistive technology every day.

Frequently asked questions