Testing & Tools

Screen Readers Overview: NVDA, JAWS, and VoiceOver

A screen reader converts on-screen content into synthesized speech or braille output, letting blind and low-vision users navigate and understand a page without seeing it visually. The three most widely used screen readers behave differently enough — in keyboard shortcuts, in how they interpret ARIA, in default settings — that manual accessibility testing ideally covers more than just one.

NVDA (NonVisual Desktop Access)

Free and open-source, Windows-only, and the most widely used screen reader for both real users and accessibility testing specifically — its free price point and active development make it a natural default for teams doing their own manual testing. Pairs most commonly with Firefox or Chrome on Windows.

JAWS (Job Access With Speech)

A commercial, paid screen reader for Windows, historically the market leader in enterprise and government contexts, with a long track record and deep feature set. Because it's commercial and requires a paid license, it's less commonly used for casual or ad-hoc testing than NVDA, but remains important to test against specifically for products serving enterprise, government, or other JAWS-heavy user bases.

VoiceOver

Apple's built-in screen reader, included free on macOS and iOS — the default (and for many users, the only) screen reader in the Apple ecosystem. Testing on VoiceOver matters especially for any product with meaningful iOS/Safari usage, since VoiceOver's interaction model (particularly its touch gestures on iOS) differs substantially from the desktop-keyboard-driven model of NVDA and JAWS.

Why testing with just one screen reader isn't sufficient

Each screen reader has its own quirks in how it interprets ARIA attributes, announces dynamic content changes (like live regions), and handles edge cases in custom widgets — a component that works flawlessly in NVDA can behave differently, or even break, in VoiceOver, and vice versa. This is a large part of why WCAG conformance can't be fully verified by automated scanning alone: a scanner checks markup correctness against the specification, but real screen reader behavior sometimes diverges from spec in ways only actual manual testing surfaces.

A practical minimum testing approach

For most teams without dedicated accessibility specialists, a reasonable baseline: test primary user flows in NVDA + Chrome or Firefox (covering the most common free/Windows combination), and in VoiceOver + Safari if the product has meaningful Mac/iOS usage. This isn't exhaustive screen-reader coverage, but it catches the majority of real-world screen-reader-specific issues that automated scanning and keyboard-only testing alone would miss.

Common questions

What is a screen reader?

Software that converts on-screen content into synthesized speech or braille, letting blind and low-vision users navigate and understand a page without seeing it visually.

What are the main screen readers to test with?

NVDA (free, open-source, Windows — the most common for testing), JAWS (commercial Windows leader in enterprise and government), and VoiceOver (built into macOS and iOS).

Why test with more than one screen reader?

Each interprets ARIA, announces dynamic content, and handles custom widgets differently. A component that works in NVDA can break in VoiceOver, so testing only one misses real screen-reader-specific issues.