Screen reader testing means using your site with a real screen reader, by keyboard or touch, and listening for whether every part has a sensible name, role, state and order, which no automated checker can fully judge. It is the step that turns "the scan is clean" into "a blind customer can actually buy something".
You do not need to be an expert user. With a free screen reader, a handful of keys and a written script, a developer or tester can find the most damaging problems in an afternoon. This page gives you that script.
Quick facts
Free start on Windows
NVDA with Firefox or ChromeMac and iPhone
VoiceOver with Safari, built inAndroid
TalkBack with Chrome, built inPaid desktop option
JAWS with Chrome or Edge; a 40 minute demo mode runs without a licenseWhat you check
Page title, headings, landmarks, links, images, forms, buttons, live updates, dialogsWhy manual
Automated tools find only part of the issues, often put at around a third
Why screen reader testing matters
Automated checkers find missing alt attributes and unlabelled fields. They are blind to whether the alt text makes sense, whether a custom dropdown announces its options, or whether an error appears silently. Those problems only show up when you listen.
Treat screen reader checks as one layer of a full review, next to keyboard, zoom and contrast checks. Our accessibility testing guide shows how the layers fit, and WCAG checkers covers the automated part.
Which screen reader and browser to test with
Screen readers behave differently with different browsers, so test in the pairs that real users choose.
| Screen reader | Platform | Pair with | Cost | Turn on |
|---|---|---|---|---|
| NVDA | Windows | Firefox or Chrome | Free | Ctrl+Alt+N |
| JAWS | Windows | Chrome or Edge | Paid, demo mode | Start menu |
| Narrator | Windows | Edge | Built in | Win+Ctrl+Enter |
| VoiceOver | Mac | Safari | Built in | Command+F5 |
| VoiceOver | iPhone, iPad | Safari | Built in | Settings, Accessibility, VoiceOver |
| TalkBack | Android | Chrome | Built in | Settings, Accessibility, TalkBack |
If you can test only one desktop combination, NVDA with Firefox or Chrome is free and widely used. Note that the Chrome browser ships without a full screen reader on Windows or Mac; read aloud extensions only speak text. More choices are on our free screen readers page.
The keys you need for a first screen reader test
On Windows, NVDA and JAWS share most single-letter navigation keys while you are in browse mode (the reading mode for web pages):
- H next heading, 1 to 6 for a heading level
- D next landmark in NVDA, R in JAWS
- K next link in NVDA, Tab for the next focusable item in both
- F next form field, B next button, T next table
- Insert+F7 in NVDA lists headings, links and landmarks
- Ctrl stops speech; Insert+Q then Enter quits NVDA, Insert+F4 quits JAWS
On a Mac, the VoiceOver keys are Control+Option, called VO. VO+Right Arrow steps forward one item, while VO+U opens the rotor, a list of headings, links and landmarks. On phones, swipe right or left to move, and double tap to activate. Full guides: NVDA, JAWS and VoiceOver.
How to test screen reader accessibility page by page
- Load the page and listen to the title. It should say where you are.
- Open the headings list. Is there one main heading, and do the others outline the page?
- Move through landmarks. Can you jump straight to the main content and the navigation?
- Tab through every link and button. Does each one have a clear name and the right role, such as link, button, checkbox or tab?
- Read the images. Informative images should be described; decorative ones should be silent.
- Fill in each form. Are labels, required fields and instructions announced, and are errors read out when they appear?
- Open menus, accordions and dialogs. Do you hear expanded or collapsed, and does focus move into a dialog and back out when it closes?
- Trigger updates such as add to cart or search filters. Is the change announced without you hunting for it?
What good and bad output sounds like
| Element | Good announcement | Problem announcement | Criterion |
|---|---|---|---|
| Icon search button | "Search, button" | "Button" | 4.1.2 |
| Product photo | "Blue cotton backpack with two side pockets, image" | "IMG underscore 4471 dot jpg" | 1.1.1 |
| Custom checkbox | "Subscribe to updates, checkbox, not checked" | "Subscribe to updates, clickable" | 4.1.2 |
| Menu toggle | "Products, button, collapsed" | "Products" with no state | 4.1.2 |
| Cart update | "Added to cart" read automatically | Silence | 4.1.3 |
| Section title | "Delivery options, heading level 2" | Read as plain bold text | 1.3.1 |
Accessibility screen reader testing tools that help
- Browser accessibility inspectors in Chrome, Edge, Firefox and Safari show the computed name and role, so you can confirm what you heard.
- NVDA Speech Viewer, under NVDA menu, Tools, Speech Viewer, shows spoken output as text you can copy into a bug report.
- VoiceOver's caption panel shows what it says on screen, which helps when you demo to a team.
- Screen recordings with sound make a bug easy for a developer to reproduce.
- Real phones. Emulators do not run the real mobile screen readers, so keep at least one iPhone and one Android device for testing.
Download NVDA only from nvaccess.org. Apple documents VoiceOver in its VoiceOver user guide.
Writing up what you found
A good issue report lets a developer reproduce the problem without guessing. Include:
- the page and the steps to get there;
- the screen reader, browser and their versions;
- exactly what was announced, in quotes;
- what should have been announced;
- the WCAG criterion and how badly it blocks users.
Group issues by component, not by page. One broken date picker might appear on forty pages but need one fix. That is also how an accessibility audit report should be organised.
Limits of testing it yourself
You are not a daily screen reader user. Experienced users listen at high speed, use shortcuts you have not learned and have their own habits. A page that confuses you may be fine for them, and a page that seems fine to you may slow them down. When you can, include disabled users in testing.
Also resist fixing one screen reader's quirk with a hack that breaks others. Build to the HTML and ARIA standards, test in two or three pairs, and report genuine bugs to the screen reader or browser makers.
Questions people ask
How do I test my website with a screen reader?
Install a free screen reader such as NVDA, learn the keys for headings, landmarks, links and form fields, and work through your main tasks while listening. Log anything that is missing, unclear or silent.
Which screen reader is best for accessibility testing?
No one product wins for every case. NVDA with Firefox or Chrome is a strong free start on Windows; then add the built-in readers on iPhone (VoiceOver) and Android (TalkBack) to cover mobile users.
Can I run a screen reader test on a Mac?
Yes. VoiceOver is built into every Mac; press Command+F5 to turn it on and test in Safari. It is also on every iPhone and iPad.
Do I need to test with every screen reader?
No. Test with the most common combinations for your users, usually one Windows screen reader, VoiceOver on iOS and TalkBack on Android. Clean HTML and ARIA tend to work across the rest.
Can automated tools replace screen reader testing?
No. Automated tools report only some issues. They cannot judge whether names make sense, whether order is logical or whether updates are announced.
Can I test without buying a screen reader?
Yes. NVDA is free for Windows, and VoiceOver, TalkBack and Narrator come built into their systems at no extra cost.