Screen Reader Accessibility Testing

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 typically involves tools such as NVDA, JAWS, VoiceOver and TalkBack. The goal is to make sure that content structure, navigation, forms and interactive components are properly communicated to assistive technology users, and that those 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.

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:

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.

How to Run Screen Reader Accessibility Testing

1. 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.
2. Pick real tasks. Test journeys, not just pages: find a product, add it to the cart, check out, log in, submit a contact form.
3. 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.
4. Navigate the way users do. Jump by headings, landmarks, links and form fields, and use the elements list or rotor.
5. Operate every control. Use Tab and the screen reader’s own commands, open and close menus and dialogs, and trigger errors.
6. 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

• NVDA: the NVDA key is Insert (or Caps Lock in laptop layout). H moves to the next heading, D to the next landmark, K to the next link, F to the next form field, B to the next button and T to the next table. NVDA+F7 opens the elements list, NVDA+Space switches between browse and focus mode, and Ctrl stops speech.
• JAWS: H, R and F move to the next heading, region and form field. Insert+F6 lists headings, Insert+F7 lists links and Insert+F5 lists form fields.
• VoiceOver on Mac: Cmd+F5 turns it on and off. The VO keys are Control+Option. VO+Right Arrow moves to the next item, VO+Space activates, and VO+U opens the rotor to browse headings, links, landmarks and form controls. Deque’s VoiceOver shortcut list is a handy reference.
• VoiceOver on iOS and TalkBack on Android: swipe right or left to move between items and 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.

What to Test

• 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 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 provides valuable insight into the real-world accessibility of digital experiences.

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. In a HalfAccessible audit, certified specialists (CPACC, WAS and CPWA, plus a DHS Section 508 Trusted Tester) 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? A one-hour consultation with a certified specialist is a flat $100: book a $100 consultation.

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.

Get a free accessibility needs assessment (four short questions, no commitment), or start a $500 Quick Audit today.