Screen Reader Testing: A Practical Guide for Developers
Screen reader testing means using a screen reader the way a visually impaired user would — navigating by keyboard, listening to element announcements, and verifying that your application makes sense without seeing it. This guide covers the major screen readers, essential commands, and a practical testing checklist for developers.
Key Takeaways
Test with the most common screen reader / browser combinations. NVDA + Chrome is the most common on Windows. VoiceOver + Safari is standard on Mac/iOS. JAWS + Chrome or IE is enterprise Windows. Don't pick just one.
Screen readers navigate by landmarks, headings, and links — not visual layout. A developer reads a page top to bottom. A screen reader user jumps between landmarks, scans headings, and reads link lists. Test using these navigation modes.
"Accessible name" is what screen readers announce for an element. If a button has no accessible name (no text, no aria-label, no aria-labelledby), screen readers say "button" — and users don't know what it does. Test every interactive element's announcement.
Focus management in dynamic content is the most common failure. When a modal opens, focus must move into it. When it closes, focus must return to the trigger. Automated tools can't catch this; you must test it manually.
Turn off the monitor. The best screen reader test is one where you can't see the screen. You'll immediately discover what's confusing.
Why Manual Screen Reader Testing
Automated accessibility tools catch structural violations: missing alt text, unlabeled inputs, insufficient contrast. What they can't catch is whether the screen reader experience makes sense.
A page can have valid ARIA, correct heading structure, and labeled inputs — and still be nearly unusable for a screen reader user because:
- Modal focus isn't managed correctly
- Dynamic content changes aren't announced
- Custom interactive widgets don't respond to expected keyboard commands
- Element announcements are technically correct but contextually confusing
Manual screen reader testing catches these issues. It requires a developer to actually use the screen reader — listen to how elements are announced, try to navigate the application by keyboard, and verify that the experience is coherent.
The Major Screen Readers
NVDA (Windows) — Free
NVDA (NonVisual Desktop Access) is the most widely used free screen reader for Windows. It works with Chrome, Firefox, and Edge.
Installation: Download from nvaccess.org. Works immediately after installation.
Recommended pairing: NVDA + Chrome.
Enable: Launch NVDA → it starts speaking immediately. Press NVDA+Q to quit.
VoiceOver (Mac/iOS) — Built-in
VoiceOver is built into macOS and iOS. On Mac, it works best with Safari.
Enable on Mac: Cmd + F5 or System Settings → Accessibility → VoiceOver.
Recommended pairing: VoiceOver + Safari (Mac), VoiceOver + Safari (iOS).
JAWS (Windows) — Commercial
JAWS (Job Access With Speech) is the most popular commercial screen reader, dominant in enterprise environments. License required.
Recommended pairing: JAWS + Chrome.
Narrator (Windows) — Built-in
Windows' built-in screen reader. Less capable than NVDA or JAWS, but useful for quick checks without installing anything.
Enable: Win + Ctrl + Enter.
Essential Screen Reader Commands
NVDA + Chrome
| Action | Command |
|---|---|
| Start reading from cursor | NVDA + Down Arrow |
| Stop reading | Ctrl |
| Next heading | H |
| Previous heading | Shift + H |
| Next link | K |
| Next landmark/region | D |
| Next form element | F |
| Open links list | NVDA + F7 |
| Open headings list | NVDA + F7 (then select Headings) |
| Next button | B |
| Read current element | NVDA + Tab |
| Click/activate | Enter or Space |
VoiceOver + Safari (Mac)
VoiceOver uses VO to mean Ctrl + Option.
| Action | Command |
|---|---|
| Start/stop reading | VO + A |
| Next element | VO + Right Arrow |
| Open rotor | VO + U |
| Navigate rotor items | Left/Right Arrow in rotor |
| Interact with element | VO + Shift + Down Arrow |
| Click | VO + Space |
The VoiceOver Rotor (VO + U) is essential — it lets you navigate by headings, links, form controls, landmarks, and more. This is how real users navigate.
What to Test
1. Page Structure
Navigate by headings (H in NVDA):
- Is there an
<h1>that describes the page? - Do headings form a logical outline (H1 → H2 → H3, no jumps)?
- Are headings meaningful or just styled large text?
Navigate by landmarks (D in NVDA):
- Is there a
<main>landmark? - Is there a
<nav>for navigation? - Are there
<header>and<footer>landmarks? - Can you skip to the main content without traversing the navigation?
2. Interactive Elements
Tab through every interactive element and listen to the announcement:
Buttons — Should announce: button purpose. "Submit form, button." Not: "Button."
<!-- Wrong — announces "button" -->
<button><svg>...</svg></button>
<!-- Correct — announces "Close dialog, button" -->
<button aria-label="Close dialog"><svg>...</svg></button>Links — Should announce destination or purpose. "Privacy Policy, link." Not: "Click here, link."
Form inputs — Should announce label, input type, and current value. "Email address, edit text." Not: "Edit text."
Custom interactive components — A custom dropdown built with divs should announce like a native select. A custom toggle should announce state ("On" or "Off"). Test that ARIA roles and properties convey the right information.
3. Forms
- Navigate to each form field using
F(next form element) - Verify the field label is announced when focus lands
- Fill in the field
- Submit with
Enter - Verify error messages are announced — either automatically (via
aria-live) or on focus of the error
Common failures:
- Placeholder text used as label (disappears on entry; not announced as label)
- Error messages not associated with their input (
aria-describedby) - Required fields not announced as required (
aria-required="true"orrequiredattribute)
4. Modals and Dialogs
- Trigger a modal (click a button)
- Verify focus moves into the modal automatically
- Navigate within the modal — verify background content is not accessible
- Close the modal
- Verify focus returns to the element that opened the modal
// Focus management for modal
function openModal() {
modal.removeAttribute('hidden');
firstFocusableElement.focus(); // Move focus in
}
function closeModal() {
modal.setAttribute('hidden', '');
triggerButton.focus(); // Return focus to trigger
}5. Dynamic Content
When content changes on the page (search results, status updates, live feeds), the change must be announced.
aria-live regions:
<!-- Polite: announced after current speech finishes -->
<div aria-live="polite" id="search-status">
Showing 42 results
</div>
<!-- Assertive: interrupts current speech -->
<div aria-live="assertive" id="error-message">
Payment failed: Invalid card number
</div>Test: trigger the content change, wait, listen for the announcement. If nothing is announced, add an aria-live region.
6. Images and Media
- Navigate to each image using the images list (NVDA:
NVDA + F7→ Images) - Verify meaningful images have descriptive alt text
- Verify decorative images are not announced (empty alt or
role="presentation") - Verify complex images (charts, diagrams) have longer descriptions
Screen Reader Testing Checklist
Before marking an accessibility testing session complete:
- Navigated page by headings — structure is logical
- Navigated by landmarks — main, nav, header, footer present
- Tabbed through all interactive elements — all announce correctly
- Tested every form field — labels announced on focus
- Submitted forms with intentional errors — errors announced
- Opened and closed every modal — focus managed correctly
- Triggered dynamic content changes — changes announced via aria-live
- Checked images — alt text descriptive for meaningful images
- Tested with monitor off for 5 minutes — experience makes sense
Browser / Screen Reader Combinations to Test
Don't test with just one combination. Screen readers behave differently across browsers:
| Priority | Screen Reader | Browser | Platform |
|---|---|---|---|
| High | NVDA | Chrome | Windows |
| High | VoiceOver | Safari | macOS |
| High | VoiceOver | Safari | iOS |
| Medium | JAWS | Chrome | Windows |
| Medium | TalkBack | Chrome | Android |
| Low | Narrator | Edge | Windows |
Start with NVDA + Chrome and VoiceOver + Safari. These cover the majority of real-world screen reader users.
The Turn-Off-the-Monitor Test
The single most effective screen reader testing technique: after setting up your screen reader, turn off or dim your monitor to where you can't read it. Try to complete a user flow — log in, find a product, complete a purchase, submit a form.
The friction you experience is the friction your visually impaired users experience. The moments where you're stuck, confused, or can't find what you need — those are your accessibility bugs.
This is uncomfortable. It's supposed to be. That discomfort is what drives real accessibility improvements.
