What Is Screen Reader Testing?
Screen reader accessibility testing evaluates how digital content is experienced by users who rely on assistive technologies. Screen readers convert visual content into speech or braille output, enabling blind and low-vision users, and many people with other disabilities, to use websites and applications.
Testing uses screen readers such as NVDA, JAWS, VoiceOver and TalkBack to confirm that structure, navigation, forms and interactive components are communicated properly, and that users can actually complete the tasks the site exists for.
It is one part of a wider evaluation approach. The W3C’s evaluating web accessibility overview explains how tool checks, manual review and testing with assistive technology fit together.
Screen Reader Use In 2026 At A Glance
- 55.0%: Name JAWS as their primary desktop screen reader (NVDA 32.9%, VoiceOver 6.5%) (Source: WebAIM Screen Reader Survey #11 (2026) (opens in a new tab))
- 31.2%: Use JAWS with Chrome, the most common screen reader and browser pair (Source: WebAIM Screen Reader Survey #11 (2026) (opens in a new tab))
- 67.8%: Navigate by headings first to find information on a long page (Source: WebAIM Screen Reader Survey #11 (2026) (opens in a new tab))
- 70.3%: Use more than one desktop screen reader, so one test pass is not enough (Source: WebAIM Screen Reader Survey #11 (2026) (opens in a new tab))
Choose Your Next Step
Want a quick first look? Run a free one-page scan on AccessibilityScore.in (opens in a new tab); it is a starting point that complements manual screen reader testing, not a replacement. For a full manual WCAG 2.2 AA audit of up to 25 templates, see the $2,000 Complete Audit on our pricing page or our accessibility audit services.
Free 30-Minute Call
Best for: first conversations, scoping and quotes
Tell us which journeys matter most and who your users are. We suggest the screen reader and browser combinations to cover and what the testing will cost. No technical prep needed.
Book a free 30-minute call (opens in a new tab)
$500 Quick Audit
Best for: small sites or a first manual check
Founder-led manual testing of up to 5 templates with a keyboard and screen readers, with a top-10 issues report that names what was announced and how to fix it.
$100 Technical Consultation
Best for: developers stuck on a screen reader bug or audit findings
A one-hour working session to walk through audit findings, talk with your developer or review announcements and focus issues live.
Why Screen Reader Testing Matters
Automated scans cannot fully evaluate how content is announced or understood by screen reader users. A scanner can tell you a button has a name; it cannot tell you the name makes sense, that focus moves to a dialog when it opens, or that an error message is announced when a form fails.
Verifies Semantic Structure
Testing confirms that headings, landmarks, lists and regions provide meaningful navigation. In WebAIM’s Screen Reader User Survey #11 (2026), 67.8% of respondents said navigating by headings is the first thing they do to find information on a long page, and 88.3% find heading levels very or somewhat useful.
Evaluates Form Accessibility
Users should receive clear instructions, labels, validation messages and error notifications, at the moment they need them.
Ensures Accessible Dynamic Content
Interactive components such as accordions, menus, alerts and dialogs must communicate their names, roles and state changes, as required by WCAG 4.1.2 Name, Role, Value. Updates that appear without moving focus, such as “Item added to cart”, must be announced too, which is covered by WCAG 4.1.3 Status Messages.
Which Screen Readers and Browsers to Test With
Screen readers behave differently, and each works best with particular browsers. A practical test matrix covers the combinations people really use:
| Screen reader | Platform | Browser to pair it with | Cost |
|---|---|---|---|
| NVDA | Windows | Chrome or Firefox | Free, open source |
| JAWS | Windows | Chrome or Edge | Paid licence (a time-limited demo mode is available) |
| VoiceOver (macOS) | Mac | Safari | Built in |
| VoiceOver (iOS) | iPhone, iPad | Safari | Built in |
| TalkBack | Android | Chrome | Built in |
WebAIM’s Screen Reader User Survey #11 (1,780 responses, July to August 2026) is the best public guide to what people actually use. JAWS (55.0%) and NVDA (32.9%) were the most common primary desktop screen readers, followed by VoiceOver (6.5%). The most common combinations were JAWS with Chrome (31.2%), NVDA with Chrome (17.3%) and JAWS with Edge (17.0%). 70.3% of respondents use more than one desktop screen reader, and on phones and tablets 72.2% commonly use VoiceOver and 29.5% TalkBack. The sample was not controlled, so treat these as a guide rather than market share. NVDA with Chrome is free and a sensible default during development, but JAWS with Chrome is now the most common combination by a wide margin, so cover it, VoiceOver and TalkBack before release.
Screen Reader Compatibility Testing
Screen reader compatibility testing checks that a page or app works with each screen reader and browser combination your users rely on, not just the one your team happens to use. The same code can be announced differently. A hint added with aria-describedby may be read straight away, after a pause or only on request, depending on the screen reader and its settings. A live region added to the page at the wrong moment may be spoken by one combination and missed by another. Custom widgets can also behave differently in NVDA’s browse and focus modes than they do with the VoiceOver rotor.
A practical compatibility test works like this:
- Choose the combinations. Pick three to five pairs from the table above, based on your analytics and audience. JAWS with Chrome, NVDA with Chrome, VoiceOver with Safari on iOS and TalkBack with Chrome on Android cover most users.
- Script the tasks. Write the same task list for every combination: sign up, search, fill in a form, check out.
- Record a result per combination. Mark each task as pass, partial or fail, and note the exact announcement for anything that is not a pass.
- Fix the code, not the screen reader. Repair issues against WCAG and the patterns in the WAI-ARIA Authoring Practices Guide instead of adding workarounds that only suit one screen reader, then re-test every combination.
Example: What a Screen Reader Announces
The table shows roughly what a user should hear when they reach common elements, and the failures screen reader testing catches. Exact wording varies between screen readers and their verbosity settings.
| Element | What the user should hear | Common failure |
|---|---|---|
| Icon-only search button | “Search, button” | “Button” with no name (WCAG 4.1.2) |
| Email field | “Email address, edit, required” | “Edit, blank” with no label (WCAG 1.3.1 and 3.3.2) |
| Menu toggle | “Menu, button, collapsed”, then “expanded” once opened | No state, so users cannot tell the menu opened (WCAG 4.1.2) |
| Newsletter checkbox | “Subscribe to updates, check box, not checked” | “Check box, not checked” with no label |
| Add to cart | “Added to cart” spoken as a status message | Silence, because the update is not announced (WCAG 4.1.3) |
| Main heading | “Screen reader testing, heading, level 1” | Read as plain text, so heading navigation skips it (WCAG 1.3.1) |
| Decorative image | Nothing at all | “Image, divider-line.png” (WCAG 1.1.1) |
How to Run Screen Reader Accessibility Testing
- Learn the basics first. Spend time with a screen reader on a site you know works well before testing your own. WebAIM’s guide to testing with screen readers is a good starting point, and its JAWS article covers that reader’s controls.
- Pick real tasks. Test journeys, not just pages: find a product, add it to the cart, check out, log in, submit a contact form.
- Listen to the whole page once. Read from the top with the reading command to check reading order and whether anything is missing or announced twice. Leave the punctuation level at its default for this pass. Screen readers handle symbols differently: NVDA skips the em dash at its default level, while JAWS tends to announce it. Our guide to em dashes in AI writing and screen readers explains why.
- Navigate the way users do. Jump by headings, landmarks, links and form fields, and use the elements list or rotor.
- Operate every control. Use Tab and the screen reader’s own commands, open and close menus and dialogs, and trigger errors.
- Record what you hear. Note the exact announcement, the expected announcement and the WCAG criterion, so developers can reproduce and fix the issue.
Starter Commands
The keys you need for a first pass with each screen reader:
| Screen reader | Start and move around | Lists, modes and stopping speech |
|---|---|---|
| NVDA | The NVDA key is Insert (or Caps Lock in laptop layout). H next heading, D landmark, K link, F form field, B button, T table | NVDA+F7 opens the elements list, NVDA+Space switches browse and focus mode, Ctrl stops speech |
| JAWS | Insert is the JAWS key. H next heading, R region, F form field | Insert+F6 lists headings, Insert+F7 links, Insert+F5 form fields |
| VoiceOver on Mac | Cmd+F5 turns it on and off; the VO keys are Control+Option. VO+Right Arrow next item, VO+Space activates | VO+U opens the rotor to browse headings, links, landmarks and form controls (see Deque’s VoiceOver shortcut list) |
| VoiceOver on iOS and TalkBack on Android | Turn on in the Accessibility settings. Swipe right or left to move between items, double-tap to activate | On iOS, twist two fingers to use the rotor; on TalkBack, use the reading controls to move by headings or links |
Screen Reader Testing on Mobile With VoiceOver and TalkBack
Mobile screen readers are controlled by touch, so testing a phone or tablet is a different job from testing a desktop. On iPhone and iPad, go to Settings, then Accessibility, then VoiceOver to turn it on; the VoiceOver Tutorial on the same screen lets you practise the gestures first. On Android, turn on TalkBack in the Accessibility settings. On both, swipe right or left to move to the next or previous item, double-tap to activate the selected item, and drag a finger across the screen to hear what is under it. In TalkBack 9.1 and later, swiping up then down changes the reading control so you can move by headings, links or controls; on iOS the rotor does the same.
On mobile, check that:
- every button, link and field in the app or mobile site announces a clear name, role and state;
- the swipe order follows the visual order, including in carousels, tabs and bottom sheets;
- custom gestures such as swipe to delete have a simple tap alternative (WCAG 2.5.1 Pointer Gestures);
- touch targets are at least 24 by 24 CSS pixels or have enough space around them, as WCAG 2.2 Target Size (Minimum) requires;
- content works in portrait and landscape (WCAG 1.3.4 Orientation), and text still reads correctly when the user enlarges it;
- dialogs and bottom sheets keep focus inside them while open and return it when they close.
Our mobile accessibility testing guide covers the rest of a mobile test plan, and native iOS and Android apps can be included in an accessibility audit.
What to Test
Check each of these on every key template and journey. The right column is what a pass sounds like.
| Check | What a pass looks and sounds like |
|---|---|
| Page title and language | The title is announced on load and describes the page; the language is set so the voice pronounces content correctly. |
| Headings | A logical outline with one main heading, no skipped levels used for styling, and no visual headings missing heading markup. |
| Landmarks | Header, navigation, main and footer are present, and multiple navigation regions have distinct labels. |
| Names, roles and states | Every link, button and control announces a meaningful name, the right role, and states such as expanded, selected, checked or pressed. Our ARIA attributes guide explains how they are set. |
| Images | Informative images have useful alternatives; decorative images are silent. |
| Forms and errors | Every field announces its label, required state and instructions; errors are announced and linked to their fields. |
| Live regions | Status messages such as search results counts, cart updates and “saved” confirmations are announced without stealing focus. |
| Modals and focus return | Focus moves into a dialog when it opens, stays there while it is open, and returns to the triggering control when it closes. The WAI-ARIA Authoring Practices Guide documents the expected behaviour for dialogs and other widgets. |
| Reading order | The order content is read matches the visual and logical order, including on responsive layouts. |
| Tables | Data tables announce their headers as you move between cells. |
Common Accessibility Issues Found During Screen Reader Testing
Missing or Incorrect Labels
Buttons and form controls may not provide meaningful information when announced, for example an icon button read as just “button”, or several links all called “Read more”.
Poor Reading Order
Content may be presented in an illogical sequence, making it difficult to understand. This often comes from CSS that reorders content visually while the DOM order stays the same.
Improper ARIA Implementation
Incorrect ARIA attributes can create confusion and harm accessibility: roles that promise keyboard behaviour that is not there, aria-hidden on focusable content, or states that never update. Our WCAG 4.1.2 Name, Role, Value guide shows failing and fixed code for buttons, toggles, tabs and sliders.
Focus Lost or Trapped
After closing a dialog or deleting an item, focus jumps to the top of the page, and users have to find their place again. These issues overlap with manual keyboard testing, so it is efficient to run both together.
Silent Updates
Search filters, cart counts and inline validation change on screen with no announcement, so users do not know anything happened.
On phones and tablets, gestures, touch targets and orientation add more checks; see our guide to mobile accessibility testing.
Screen Reader Testing vs Automated Testing
The two approaches answer different questions. Automated accessibility testing quickly finds code-level failures across many pages: missing alt attributes, unlabeled fields, invalid ARIA. Screen reader testing tells you whether the experience works: whether names are meaningful, announcements are timely and tasks can be completed. Run automated checks first to clear the obvious issues, then spend screen reader time on key journeys and custom components.
Screen Reader Simulators vs Real Screen Readers
Screen reader simulator extensions and the accessibility tree view in browser developer tools show roughly what a screen reader will get from a page: names, roles, states and reading order. They are handy for a quick check while you build. They do not reproduce how a real screen reader behaves, such as browse and focus modes, verbosity settings, how and when live regions are spoken, or touch gestures on a phone. Use them to catch problems early, then confirm with NVDA, JAWS, VoiceOver and TalkBack before you call a component accessible.
Screen Reader Testing Checklist
- Page title announced and meaningful.
- Heading outline makes sense from the headings list alone.
- Main landmark present; navigation regions labelled.
- Every control has a clear name, correct role and current state.
- Images described or silent, as appropriate.
- Form labels, instructions and errors announced.
- Status messages announced without moving focus.
- Dialogs take focus, keep it and return it.
- Reading order matches visual order.
- Key journeys completed with NVDA, JAWS, VoiceOver and TalkBack.
Screen Reader Testing in a Professional Accessibility Audit
Screen reader testing is the part of accessibility testing that automated tools cannot do for you, and it is where most of the barriers that block real users are found. HalfAccessible audits are founder-led by Mohammad Shadab Saifi (IAAP (opens in a new tab) CPACC, WAS and CPWA). We test your key user journeys with NVDA, JAWS, VoiceOver and TalkBack alongside keyboard-only and automated checks, and map every finding to WCAG 2.2 AA.
- What you get: each issue with the exact announcement heard, the expected behaviour, the WCAG success criterion, its severity and a code-level fix. See a sample audit report.
- Quick Audit, $500: up to 5 templates with a top-10 issues report, a good fit for small sites or a first check. Start a $500 Quick Audit.
- Complete Audit, $2,000: a full manual WCAG 2.2 AA audit of up to 25 templates, including screen reader testing and a re-test after you fix. Compare plans on our pricing page.
- Not sure yet? Book a free 30-minute call (opens in a new tab) to talk through your site, scope the testing and get a quote.
- Need technical answers now? The $100 one-hour technical consultation is a working session to walk through audit findings, talk with your developer or review screen reader issues live.
HalfAccessible has 10+ years of accessibility experience. Before testing starts, we agree the screen reader and browser combinations that match your audience, and each finding notes where it was found, so your developers can see whether a barrier affects one screen reader or all of them. Shopify stores can choose the Shopify Accessibility Audit ($2,000), and agencies can resell our screen reader testing under their own brand through white label accessibility services.
If we find barriers, our accessibility remediation developers can fix them and re-test with the same screen readers.
Work With Us
Curious how your own site actually sounds to a screen reader user? Our accessibility audit services include manual testing with JAWS, NVDA, VoiceOver and TalkBack.
Start with a free 30-minute call (opens in a new tab) if you want to talk it through first, get a free accessibility needs assessment (four short questions, no commitment), or start a $500 Quick Audit today.
