Why Your Accessibility Guide Must Start with NVDA, Not JAWS

Imagine you're a developer staring at a bug report: "Button not announced." The user is on NVDA, the free screen reader, and you've never even opened it—you tested your app with JAWS because that's what your boss insisted on. You fire up JAWS, reproduce the issue, fix it, and move on. But the user is still stuck. Why? Because NVDA and JAWS behave differently, and if your accessibility guide doesn't account for that, you're leaving a huge chunk of your audience behind.

Here's the question we need to answer: Which screen reader should your accessibility guide prioritize for testing and documentation? The knee-jerk answer for many teams is JAWS, the long-standing commercial giant. But the data says otherwise. In WebAIM's 2024 Screen Reader User Survey, NVDA is the most commonly used screen reader among respondents at 65.6%, outpacing JAWS at 60.5% (WebAIM). When asked which they use as their primary screen reader, JAWS edges out NVDA 40.5% to 37.7%, but that's a slim margin—and it doesn't reflect the reality of who's actually using your product. The survey also found that 71.6% of users use more than one screen reader, meaning your user might be on NVDA at work and VoiceOver at home. If your guide only covers JAWS, you're guessing at a fraction of the user base.

So, our recommendation is clear: Build your accessibility guide around NVDA first, then verify with JAWS and VoiceOver. This isn't an anti-JAWS stance; it's a pragmatic one. NVDA is free, open source, and runs on Windows—the dominant OS in many workplaces. It's also the screen reader that most users on a budget will encounter. And because it's free, you can install it on any test machine without licensing headaches, making it the perfect baseline for your team's testing workflow.

Why NVDA Should Be Your Baseline

Let's look at the numbers. NVDA was first developed in April 2006 by NV Access, a non-profit, and it's been translated into more than 55 languages, used in over 175 countries (NV Access). That's not a niche tool—that's a global standard. Meanwhile, JAWS is commercial, expensive, and often seen as the "enterprise" choice, but its market share is shrinking. In the 2024 survey, 38% of respondents use braille output with their screen reader, and NVDA's support for braille is robust and frequently updated (WebAIM). If your guide only tests with JAWS, you might miss issues that only appear in NVDA's rendering engine—like how it handles certain ARIA attributes or dynamic content updates.

Consider also the mobile reality: 91.3% of screen reader users report using one on a mobile device, with VoiceOver (70.6%) and TalkBack (34.7%) leading (WebAIM). But desktop still matters for productivity, and NVDA is the most common desktop screen reader in the survey. So if you're writing a guide for web developers, starting with NVDA ensures you're covering the tool that most users actually have in front of them.

The Cost of Ignoring NVDA

There's a real human cost to neglecting NVDA. The WebAIM Million analysis found that 95.9% of home pages have detectable WCAG 2 failures, averaging 56.1 errors per page (WebAIM). Those errors are often things that screen readers like NVDA will stumble over—missing labels, empty buttons, low contrast. If your guide doesn't include NVDA-specific checks, you're likely shipping those errors. And the legal landscape is tightening: US federal website accessibility lawsuits reached 3,117 in 2025, a 27% increase from the previous year (WebAIM). Ignoring a free, widely used screen reader is a liability.

Moreover, the DOJ's final rule under ADA Title II, published April 24, 2024, explicitly adopts WCAG 2.1 Level AA for state and local government web content (ADA.gov). While that's specifically for public entities, it sets a precedent: accessibility is not optional. Your guide should reflect the tools that help you meet those standards, and NVDA is a key part of that.

How to Structure Your Guide Around NVDA

So, how do you build a guide that puts NVDA first? Start with a quick start section that assumes zero knowledge. Explain how to install NVDA (it's a simple download from nvaccess.org), how to turn it on, and how to navigate a page using basic keystrokes. Then, cover the core testing scenarios: reading headings, navigating forms, checking for alt text, and ensuring focus visibility. Use NVDA as your primary test environment, but add a section for JAWS and VoiceOver as "secondary checks"—because 71.6% of users use more than one screen reader (WebAIM), so you need to ensure cross-compatibility.

A concrete example: Suppose you have a button that opens a modal dialog. In NVDA, you might hear "Open dialog" when the modal fires, but in JAWS, it might not announce it until you press a certain key. If you only tested in JAWS, you'd think it's fine; but your NVDA user is stuck. That's why your guide should include a "NVDA-first" checklist that forces you to test every interactive element with NVDA before moving on.

Quick tip: When you document keyboard shortcuts, list the NVDA modifier key first (Insert or Caps Lock), then provide the JAWS equivalent (usually Insert). This makes your guide immediately usable for NVDA users.

Beyond the Screen Reader: The Bigger Picture

But the screen reader choice is just one piece of the puzzle. The WebAIM Million data shows that low contrast text is the most common failure, affecting 83.9% of home pages (WebAIM). That's not a screen reader issue—that's a visual design issue. Your guide should include a section on visual accessibility, not just screen reader testing. After all, 2.2 billion people worldwide have a near or distance vision impairment (WHO), and many of them don't use a screen reader—they just need better contrast. So while NVDA is your baseline, your guide must also address contrast, resize, and other visual checks.

And don't forget hearing accessibility: 1.5 billion people globally have hearing loss (WHO), and over 1 billion young adults are at risk of avoidable hearing loss from unsafe listening (WHO). Your guide should include captions and transcripts for media, even if you're not testing with a screen reader.

The Only Way to Know Is to Test

Ultimately, the best accessibility guide is one that gets your team actually testing with real assistive technology. That means installing NVDA on every developer's machine, making it part of the definition of done, and using it as the primary check before release. Don't rely on automated tools alone—WebAIM Million found that automated checks only catch a fraction of issues, and even those fail on 95.9% of pages (WebAIM). You need manual testing with a real screen reader, and NVDA is the most accessible (free) choice.

So, when you're writing your next accessibility guide, start with NVDA. Make it the star of the show, and treat JAWS and VoiceOver as supporting actors. Your users—and your legal team—will thank you.

The single most important thing to remember: Your accessibility guide should be built around the screen reader your users actually use, and that's NVDA—so test with it first, not JAWS.

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
• ADA.gov - https://www.ada.gov/resources/web-guidance/