Screen Reader Testing for Developers: Getting Started

Automated accessibility testing tools are valuable, but they can only catch approximately 30% of accessibility issues. They're good at flagging missing alt text, low color contrast, and missing form labels. But they can't tell you what a screen reader actually announces — or whether the experience makes sense to someone who can't see the screen.

Screen reader testing catches issues that automated tools miss entirely:

• Reading order — content read in an illogical sequence that doesn't match the visual layout
• Missing accessible names — interactive elements that announce as just "button" or "edit" with no purpose
• Incorrect ARIA roles — custom components that don't announce what they are
• Broken live regions — dynamic content updates that are never announced
• Focus management problems — focus getting lost after closing a modal, or not moving to newly loaded content

You don't need to be a screen reader power user. Even spending five minutes tabbing through your page with a screen reader running will surface issues you'd never catch any other way.

There are four major screen readers, each tied to a specific platform. Here's what you need to know about each:

VoiceOver (macOS / iOS)

Built into every Mac and iPhone. Free, no installation needed — just turn it on. VoiceOver is a good starting point for developers on macOS. Use it with Safari, which is the best-supported browser for VoiceOver on Mac. Chrome and Firefox have inconsistent VoiceOver support.

NVDA (Windows)

Free and open source. NVDA holds roughly 30% market share among screen reader users. It's the best free option on Windows and is actively developed. Use it with Firefox or Chrome. Download from nvaccess.org.

JAWS (Windows)

The most established commercial screen reader, with roughly 50% market share among screen reader users. JAWS is a paid product, but it offers a 40-minute demo mode that restarts. Use it with Chrome or Edge. Available from Freedom Scientific.

TalkBack (Android)

Built into Android devices. Use TalkBack for mobile web testing on Android. It pairs with Chrome on Android.

You don't need to memorize every command. These are the basics that cover most testing scenarios.

VoiceOver (macOS)

The VoiceOver modifier key (referred to as VO) is Ctrl+Option. All VoiceOver commands use this modifier.

NVDA (Windows)

The NVDA modifier key is Insert (or CapsLock if configured). NVDA uses two modes: Browse mode for reading content and Focus mode for interacting with form controls.

JAWS (Windows)

The JAWS modifier key is Insert. Like NVDA, JAWS uses a virtual cursor for reading and a forms mode for interaction.

When testing with a screen reader, focus on these key areas:

Accessible Names

Every interactive element should announce its purpose. A submit button should say "Submit, button" — not just "button." An email input should say "Email, edit text" — not just "edit." If a screen reader announces an element without a clear name, that element is missing an accessible name and needs a <label>, aria-label, or aria-labelledby attribute.

Role Announcements

Elements should announce what they are. Buttons should say "button." Links should say "link." Checkboxes should say "checkbox." Tabs should say "tab." If you've built a custom component that doesn't announce its role, you likely need to add the correct ARIA role or use the native HTML element instead.

State Changes

Dynamic states must update when they change. Expanded and collapsed sections, checked and unchecked checkboxes, selected tabs, and pressed toggle buttons should all announce their current state. If you toggle a Switch and the screen reader doesn't announce "on" or "off," or you expand an Accordion and it doesn't announce "expanded," the state is not being communicated.

Live Region Announcements

Toast notifications, form validation errors, and dynamic content updates should be announced without requiring focus to move. If you trigger a toast notification and the screen reader stays silent, the live region is missing or broken. These rely on role="status", role="alert", or aria-live attributes being present before the content updates.

Reading Order

Content should be read in a logical sequence that matches the visual layout. If the screen reader reads a sidebar before the main content, or reads a modal's background content instead of the modal itself, the DOM order or focus management needs to be fixed.

Rather than testing randomly, follow a systematic approach that covers the most important areas:

1. Open the page and listen to the page title — the screen reader should announce a descriptive page title. If it says "Untitled" or something generic, the <title> element needs attention.
2. Navigate by landmarks — use the Rotor (VoiceOver), D key (NVDA), or R key (JAWS) to jump between landmarks. Are all major sections identified? You should hear navigation, main, and contentinfo (footer) at minimum.
3. Navigate by headings — use VO+Cmd+H (VoiceOver) or H (NVDA/JAWS) to jump through headings. Is the heading hierarchy logical? Does it skip levels (h1 to h3 with no h2)?
4. Tab through interactive elements — press Tab to move through all focusable elements. Does every button, link, and form control announce its name and role?
5. Test specific components — open and close modals, switch between tabs, toggle switches, and use the combobox. Do they announce state changes? Can you operate them with the keyboard alone?
6. Check dynamic content — trigger a toast notification, submit a form with errors. Are these updates announced without moving focus?
7. Verify focus management — after closing a modal or dismissing a menu, does focus return to the element that triggered it? Or does it jump to the top of the page?

These are the most frequent problems developers discover during screen reader testing, along with how to fix them.