Screen Reader Comparison

Overview Table

The screen reader landscape is dominated by four products, each tied to specific platforms and browsers. Understanding their market positions, cost models, and default verbosity helps you prioritize testing and set expectations for what users will experience. The table below summarizes the key differences at a glance. Market share numbers come from the WebAIM Screen Reader User Survey and other accessibility community surveys. They shift year over year and vary significantly depending on whether you measure desktop-only or include mobile users.

NVDA (NonVisual Desktop Access) is the most popular free screen reader on Windows. It's open source, actively developed by NV Access, and pairs best with Firefox, though Chrome support has improved significantly in recent years. Its verbosity is highly configurable, which means experienced users often reduce announcement detail to speed up navigation. For testing purposes, use NVDA's default settings to establish a baseline.

JAWS (Job Access With Speech) by Freedom Scientific is the oldest commercial screen reader still in active use. It dominated the market for decades before NVDA gained traction as a free alternative. JAWS is verbose by default: it announces more context about elements, uses slightly different terminology, and has deep customization options through its scripting language. Many enterprise accessibility teams still test primarily with JAWS because their user base includes long-time JAWS customers in corporate environments.

VoiceOver is Apple's built-in screen reader, available on macOS and iOS. On desktop, it pairs exclusively with Safari for web content. Using VoiceOver with Chrome on macOS produces inconsistent results. On iOS, VoiceOver is the dominant screen reader by a massive margin since there are no third-party alternatives. VoiceOver uses comma-separated announcements and tends to announce the name before the role, separated by a pause.

Narrator is Microsoft's built-in screen reader for Windows. It's seen major improvements in recent years and works best with Microsoft Edge. While its market share is small among experienced screen reader users, it's often the first screen reader that casual users encounter because it comes pre-installed. Narrator tends toward concise announcements, using fewer words than JAWS or VoiceOver for the same elements.

How Each Reader Announces Common Patterns

The most practical way to understand screen reader differences is to see exactly what each one says for the same HTML element. The table below shows the default announcement for common patterns. These are based on default verbosity settings with no user customizations applied. In practice, experienced users often reduce verbosity, change punctuation settings, or use custom dictionaries, but these defaults represent what a typical user hears out of the box.

Pay attention to the ordering patterns. NVDA and JAWS typically announce the accessible name followed by the role as a continuous phrase. VoiceOver and Narrator separate them with commas, creating a more punctuated rhythm. Neither approach is better; they're just different conventions that users adapt to over time. The important thing is that the semantic information is complete and correct, regardless of presentation order.

Notice that VoiceOver doesn't announce "alert" as a separate word for the alert role. It relies on the distinct audio cue (a sound effect) to signal the alert, then reads only the message content. This is a common pattern with VoiceOver: it uses audio cues more aggressively than other readers, reducing spoken verbosity while still conveying role information through non-speech sounds. Narrator and NVDA prefer to speak the role explicitly, which makes them slightly more verbose but also more predictable for users who aren't familiar with all the audio cues.

The heading announcements show another interesting divergence. NVDA announces the role and level first ("heading level 2"), then the content. JAWS puts the content first, then the role metadata. VoiceOver and Narrator both lead with content but differ in how they break up the level information. These ordering differences are purely presentational. All four readers convey the same semantic information (name, role, level), just in different sequences.

Key Behavioral Differences

Beyond the element-level announcement patterns shown above, screen readers differ in several systematic ways. These behavioral differences affect how users perceive your interface and can influence design decisions around labeling, state communication, and landmark structure. Understanding these patterns helps you write markup that works well everywhere rather than optimizing for a single reader.

How Speakable Models These Differences

Speakable includes dedicated rendering engines for each of the four major screen readers. Rather than producing a single generic output, it applies the specific announcement patterns, vocabulary choices, and ordering conventions documented above. When you run Speakable against a piece of HTML, you get four distinct outputs that approximate what each reader would say.

Each renderer is built around the default verbosity settings for its target screen reader. NVDA's renderer uses concatenated name-role patterns and the "graphic"/"unavailable"/"not checked" vocabulary. JAWS's renderer applies "region" for landmarks and "type in text" for form fields. VoiceOver's renderer uses comma separation, "dimmed" for disabled state, and "ticked"/"unticked" for checkboxes. Narrator's renderer uses comma separation with the "disabled" vocabulary and concise phrasing.

It's important to note that each real screen reader has extensive verbosity configuration. Users can increase or decrease how much information gets spoken, change punctuation behavior, and even create custom pronunciation dictionaries. Speakable models the default experience: what a user hears on a fresh installation with no customization. This represents the most common baseline and is the appropriate target for development-time testing.

The renderers are deterministic. The same HTML always produces the same output for a given screen reader target. This makes them suitable for snapshot testing, CI/CD assertions, and regression detection. If your HTML changes in a way that alters the predicted screen reader output, Speakable will flag it.

Practical Implications for Developers

Now that you understand how screen readers differ, the natural question is: what should you actually do about it? The answer is simpler than you might expect. The differences documented above are presentation-layer concerns. They affect how information is spoken, not what information is available. Your job as a developer is to provide correct semantic structure; each screen reader handles the presentation according to its own conventions.

CLI Commands

Use the -s flag to target specific screen readers or view all outputs at once:

# Show all four screen reader outputs
speakable analyze index.html -s all

# Check individual readers
speakable analyze index.html -s nvda
speakable analyze index.html -s jaws
speakable analyze index.html -s voiceover
speakable analyze index.html -s narrator

The -s all output groups results by screen reader with clear headers, making it easy to scan for inconsistencies. When running in CI, you can assert against individual reader outputs to catch regressions specific to one reader's rendering path.

For programmatic use, the renderer functions are available individually through the JavaScript API. Each renderer takes the same parsed accessibility tree and applies its own formatting rules, so you can integrate cross-reader testing directly into your test suite without spawning CLI processes.