accesspatched

Research

NVDA, JAWS or VoiceOver: which screen reader your customers actually use

Published 11 July 2026

If you are going to test your site with a screen reader, test with NVDA and JAWS first, both on Windows. That is where your customers are. WebAIM's most recent survey of actual screen reader users puts NVDA at 65.6% and JAWS at 60.5%, with Apple's VoiceOver a distant 9.7% (WebAIM Screen Reader User Survey #10, 2024). The tool most developers reach for is the one hardly anyone relies on, and that mismatch is how sites pass a test and still fail the customer.

This matters more than people expect, because screen readers do not all behave the same way. A control that announces itself cleanly in one can be silent in another. Test with the wrong one and you can walk away confident about a page that is still broken for most of the people who need it.

What do screen reader users actually run?

WebAIM asks screen reader users directly, and has done so for years, which makes its survey the closest thing this field has to a census. The tenth edition gives a clear picture: NVDA leads at 65.6%, JAWS is close behind at 60.5%, and VoiceOver sits at 9.7% (WebAIM, 2024).

Those numbers add up to well over 100, and that is not a mistake. A striking 71.6% of respondents use more than one screen reader (WebAIM, 2024). People switch depending on the device, the browser, and the task in front of them. So the figures describe overlapping usage, not a tidy market split where every user belongs to one camp. The practical takeaway is that NVDA and JAWS together dominate, and they both run on Windows.

Why the convenient default is the wrong one

Here is where teams quietly go wrong. VoiceOver ships free on every Mac and iPhone, so for a lot of developers and designers it is the path of least resistance. Open the site, switch on VoiceOver, have a listen, call it tested. It feels responsible. But VoiceOver accounts for under a tenth of surveyed users, and the two tools that actually dominate live on a different operating system entirely.

Testing only in the browser and screen reader that happen to be in front of you is a bit like proofreading in a font nobody else can see. You will catch the obvious errors, but you will miss the exact combination most of your customers depend on. NVDA paired with Firefox or Chrome, and JAWS paired with Chrome, are the pairings that carry the most real traffic. If your checkout has never been driven by one of those, it has not really been tested.

This is not an argument for buying every tool and owning a Windows lab. NVDA is free and open source, which removes the usual excuse. It is an argument for testing with what people actually use, on the platform they use it on, rather than the one that came pre-installed on the machine you build with.

Does the screen reader you test with really change the result?

Yes, and the reasons are baked into how these tools handle imperfect code. Screen readers interpret your markup, and where the markup is ambiguous or the ARIA is sloppy, they each guess differently. One may expose a custom dropdown as a usable listbox while another announces nothing. One may read an error summary automatically while another leaves it silent until the user hunts for it. When your HTML is clean and semantic, the differences shrink. When it is not, the differences are the difference between a completed order and an abandoned one.

This connects to a broader truth about testing. The classic study by Lazar and colleagues of 100 blind users found that their top frustrations were confusing page layouts, conflicts between the screen reader and the application, poorly designed or unlabelled forms, missing alt text, and misleading links (Lazar et al., 2007). Notice how many of those are about the interaction between the page and the specific tool. "Conflicts between the screen reader and the application" is not a problem you can find without running the application in a real screen reader, and ideally more than one.

What to actually do in a test session

Knowing which screen reader to use is only half of it. The other half is knowing what to try, because the barriers that cost you money cluster in a few places. In our experience the most revealing test is not "can I read the homepage," it is "can I complete a purchase without touching the mouse." Turn the screen reader on, put the mouse away, and try to buy something.

A few things are worth driving deliberately. Tab through the whole checkout and listen to what each field announces: does the address input say what it is, or just "edit text"? Trigger a validation error on purpose and see whether the screen reader is told what went wrong and where. Open any custom control, a quantity stepper, a date picker, a delivery-option selector, and check whether it announces its state, not just its label. Then follow the reading order from top to bottom and ask whether it tells a coherent story or jumps around. These are the exact spots where NVDA and JAWS can diverge, which is why running the same journey twice, once in each, is not paranoia. It is the cheapest way to find the failure that only shows up in the tool half your customers happen to be using.

Why a scanner cannot stand in for a real screen reader

An automated accessibility engine does not listen to anything. It checks your markup against a set of rules and reports what it finds. That is genuinely useful, and it is where we start, but it can only tell you whether the code looks right, not whether the page sounds right. Whether your add-to-cart button announces something a person can act on, and whether the announcements arrive in a sensible order, is something you learn only by driving the page with the real software. Automated checks catch only about a third of the issues that matter, and the rest surface in the human passes.

That is also why the stakes are commercial, not just technical. The customers behind these numbers are a large market, and they behave in a way that punishes broken experiences, as we covered in the piece on the market most shops quietly exclude. A clean report from a scanner and a checkout a screen reader user can actually complete are two different claims, and only one of them is what a regulator tests.

Common questions

Which single screen reader should I test with if I only have time for one?

NVDA. It is the most-used at 65.6%, it is free and open source, and it runs on Windows where the majority of users are (WebAIM, 2024). If you can add a second, make it JAWS at 60.5%. VoiceOver matters too, but at 9.7% it should not be your only test.

Is VoiceOver a waste of time then?

No. It is essential for testing the mobile Safari and iOS experience, and it is used by nearly one in ten people. The point is that it should complement Windows testing, not replace it, because on the desktop it under-represents your audience by a wide margin.

Do I really need to test in more than one screen reader?

For anything transactional, yes. With 71.6% of users running more than one tool (WebAIM, 2024), and with screen readers interpreting imperfect markup differently, a checkout that works in one and breaks in another is a real and common failure mode.

This is exactly the work our audits are built around. We start with an automated scan to clear the machine-detectable problems, then a human drives your real journeys to WCAG-EM methodology using the screen readers your customers actually run, ships the fixes as pull requests your team can review and merge, and issues an EN 301 549 conformance statement at the end. You can see how that is scoped under our services.

See where your own shop stands. Our free scan runs the same automated checks a regulator's tester starts with, then a human goes through your site with a screen reader and emails you the findings, in plain language. If your shop passes, we say so.

Get a free scan

Sources

Back to all research