NVDA First, Not JAWS: Why Your Software Team Should Test with the Free Screen Reader

Forget everything you've been told about testing your software with JAWS. If you're a developer, a QA engineer, or a product manager, you're probably wasting time and money on the wrong screen reader. The data is clear: NVDA is the tool your users actually have, and it's the one you should be testing with first.

The Case for NVDA

Let's start with the numbers. In WebAIM's 2024 Screen Reader User Survey, 65.6% of respondents reported using NVDA, compared to 60.5% for JAWS. And among primary desktop screen readers, NVDA holds 37.7% versus JAWS's 40.5% (WebAIM). That's a razor-thin margin, but NVDA is free and open source, while JAWS costs hundreds of dollars. For a small team, that cost difference alone should decide your testing strategy.

But it's not just about price. NVDA is developed by a non-profit, NV Access, and has been translated into over 55 languages, used in more than 175 countries (NV Access). It's the screen reader that most users on a budget can actually get. If you're building for the real world, you test where the real users are.

Imagine You're a QA Engineer at a Mid-Sized SaaS Company

You've just been asked to make your web app accessible. Your boss, remembering a blog post from 2015, says, "We need to test with JAWS." You nod, but you know better. You've seen the WebAIM data. You decide to run a practical field test: you'll install NVDA on your Windows machine, and you'll walk through your app's most critical user flows—login, dashboard, and checkout.

You start with the login page. NVDA reads the page, and you immediately notice something: the form labels are missing. The screen reader just says "Edit" with no context. You check the code, and sure enough, the label elements aren't associated with the inputs. That's a WCAG failure, and it's one of the most common errors on the web. In fact, the WebAIM Million found that 51% of home pages have missing form labels (WebAIM Million). You fix it, and move on.

Next, the dashboard. You tab through the navigation, and NVDA announces every link. You notice that some links say "Click here"—empty or vague text. That's another common issue: 46.3% of home pages have empty links (WebAIM Million). You make the link text descriptive. Good.

Finally, the checkout. You reach the payment form and hit a wall: the page has low contrast text, and NVDA struggles to make it out. You check the contrast ratio, and it fails WCAG. Low contrast is the single most common failure, affecting 83.9% of home pages (WebAIM Million). You adjust the colors, and you're done.

In one afternoon, you've caught three critical accessibility issues that would have blocked a real screen reader user. And you did it with a free tool that anyone can download.

Why NVDA Catches What Matters

Some argue that JAWS is more sophisticated, or that it's the "industry standard" for accessibility audits. But that's a myth. The truth is, the underlying accessibility APIs—the ones that expose your app's structure to screen readers—are the same for both. If your code is clean, both NVDA and JAWS will work. If your code is broken, both will fail.

What matters is that you catch the failures. And NVDA does that, plus it's free, which means you have no excuse not to test. You can install it on every developer's machine, run it in CI, and even have non-technical team members try it out. That's a culture of accessibility, not a once-a-year audit.

Consider the broader picture: the World Health Organization estimates that over 2.5 billion people need assistive technology, yet about 90% don't have access (WHO). Screen readers are a part of that. By testing with NVDA, you're aligning with the tool that's most accessible to the people who need it most.

Don't Ignore the Other Screen Readers

I'm not saying you should never test with JAWS. But it shouldn't be your first stop. The WebAIM survey shows that 71.6% of screen reader users use more than one (WebAIM). So if you have the budget, test with JAWS too—after NVDA. And don't forget mobile: 91.3% of users report using a screen reader on a mobile device, with VoiceOver at 70.6% and TalkBack at 34.7% (WebAIM). So if you have a mobile app, you need to test with those as well.

Here's a practical approach:

• Start with NVDA on desktop (Windows) because it's free and most used.
• Then test with VoiceOver on iOS if you have an iPhone.
• Then, if you have a Windows machine with JAWS or a budget for it, run a secondary check.

This way, you cover the majority of your users without breaking the bank.

Bottom Line

Stop treating JAWS as the gold standard. Start with NVDA. It's free, it's what your users actually have, and it will catch the same WCAG errors. You'll save money, time, and—most importantly—you'll build software that more people can use. That's the real goal.

Sources

• WebAIM Screen Reader User Survey - https://webaim.org/projects/screenreadersurvey10/
• WebAIM Million - https://webaim.org/projects/million/
• NV Access - https://www.nvaccess.org/about-nv-access/
• World Health Organization - https://www.who.int/news-room/fact-sheets/detail/assistive-technology