How to test for screen reader

Testing for screen readers is something you've got to do if you care about web accessibility (a11y). It's how you make sure people who are blind or have low vision can actually use your site. Screen readers like JAWS, NVDA, and VoiceOver turn digital text into speech or braille. And here's the thing—automated tools alone won't cut it. You need manual testing to catch stuff like missing alt text, messed up heading hierarchy, or a confusing focus order. This guide walks you through a practical way to test for screen readers, covering tools, techniques, and what to watch out for.

What are the best screen readers to use for testing?

Picking the right screen reader matters because each one behaves a bit differently. The go-to combo for thorough testing is NVDA on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. JAWS is still big in corporate settings, though. Testing with at least two different ones helps you catch browser-specific quirks and ensures things work for more people.

How do you manually test a website with a screen reader?

Manual testing means turning off your monitor and navigating the site using only your keyboard and the screen reader's feedback. Start by turning on the screen reader, then use the Tab key to move through links, buttons, and form fields. Listen for a logical reading order, clear announcements (like "button," "link," "heading level 2"), and labels that actually make sense. Pay attention to dynamic content—screen readers should announce changes without losing focus. Common issues? Missing alt text on images, unlabeled form fields, and modal dialogs that trap focus.

Key manual testing steps

• Navigation via headings: Use the H key (NVDA/VoiceOver) to jump between headings. Make sure the hierarchy is logical—H1 to H2 to H3—and not skipping levels.
• Tab through interactive elements: Confirm all links, buttons, and controls are reachable and have clear focus indicators.
• Test forms: Fill out forms and listen for error messages, required field announcements, and auto-fill suggestions.
• Check dynamic content: Use live regions (aria-live) to announce updates like search results or chat messages.
• Verify images: Ensure informative images have descriptive alt text and decorative ones are marked with alt="" (empty).

What are common screen reader testing mistakes to avoid?

A big one is relying solely on automated accessibility checkers. Tools like Axe or WAVE catch a lot, but they can't tell you if the screen reader output actually makes sense. Another mistake? Testing with just one screen reader (like only NVDA) and assuming it's fine for everyone. JAWS and VoiceOver handle ARIA attributes differently, and that can break things. Also, testers often forget to use a real keyboard instead of a mouse—screen reader users rely on keyboard navigation, so you need to simulate that.

Checklist for avoiding testing pitfalls

• Test with at least two different screen readers (e.g., NVDA + VoiceOver).
• Always test with the monitor turned off or eyes closed to simulate real user experience.
• Use a keyboard-only workflow—no mouse clicks allowed.
• Do not skip mobile testing (VoiceOver on iOS, TalkBack on Android).
• Verify ARIA roles and properties are used correctly and not overused.
• Test on multiple browsers (Chrome, Firefox, Safari) as screen reader behavior varies.

How can automated tools complement screen reader testing?

Automated tools like Axe, Lighthouse, and WAVE are great for quickly finding technical violations—missing alt text, low color contrast, or incorrect ARIA attributes. They give you a baseline audit, but they can't replace manual testing. They can't assess logical reading order, user experience, or whether an announcement makes sense. For example, an automated tool might flag a missing label on a button, but only a human can tell if the label is meaningful in context. Use automated checks first to fix obvious errors, then do manual screen reader tests for the nuanced stuff.

Recommended automated tools

• Axe DevTools: Browser extension that highlights accessibility issues and provides code-level fixes.
• Lighthouse: Built into Chrome DevTools; offers an accessibility score and detailed report.
• Visual overlay that shows errors, warnings, and ARIA usage on the page.
• Accessibility Insights: Microsoft tool that combines automated checks with guided manual testing.

Frequently Asked Questions