Skip to main content
User Stories

Why I Test with NVDA First, and You Should Too: A Field Report

Screen reader testing is broken. I walk through a real dev scenario and argue why NVDA, not JAWS, is the best first screen reader for most teams.

Imagine You're a Developer

It's 3 p.m. on a Wednesday. You've just pushed a new checkout flow to staging, and the QA lead pings you: 'Accessibility check?' You sigh, open a browser, and think, 'Where do I even start?' If you're like most developers I know, you've never once opened a screen reader. You've heard the names—JAWS, NVDA, VoiceOver—but they feel like relics from a different era, tools for someone else. Here's the thing: they're tools for your users, and if you don't test with them, you're shipping a product that excludes a huge chunk of humanity. I'm not neutral on this. I have a strong opinion: test with NVDA first. Not JAWS. Not VoiceOver. NVDA. Here's why.

The Scale of the Problem

Let's start with the numbers that keep me up at night. The World Health Organization estimates that over 2.5 billion people currently need assistive technology, a figure projected to rise to 3.5 billion by 2050 (World Health Organization). That's more than three times the population of the United States. And what's the reality? About 90% of people who need assistive technology do not have access to it, and in some settings, access can be as low as 3% (World Health Organization). When we talk about web accessibility, we're not talking about a fringe concern. We're talking about billions of people. And yet, the WebAIM Million 2026 analysis found that 95.9% of home pages have detectable WCAG 2 failures, with an average of 56.1 errors per page (WebAIM Million). That's not a small bug; that's a systemic failure.

The Screen Reader Landscape

Screen readers are the assistive software that converts on-screen text into synthesized speech or braille for users who are blind or have low vision (WebAIM). The major players are JAWS (Windows, commercial), NVDA (Windows, free), VoiceOver (Apple, built-in), TalkBack (Android), Narrator (Windows), and Orca (Linux) (WebAIM). For years, the conventional wisdom was that JAWS was the gold standard—the one you had to test with because it's the most popular. But look at the data from WebAIM's 2024 Screen Reader User Survey: JAWS holds 40.5% of primary desktop screen reader use, while NVDA is right behind at 37.7% (WebAIM). And when you ask which screen readers they actually use, NVDA is the most commonly used at 65.6%, outpacing JAWS at 60.5% (WebAIM). That's a shift. NVDA isn't just a free alternative; it's the tool that actual users are choosing.

Why NVDA Should Be Your First Test

Here's my point of view: if you're going to test with one screen reader, make it NVDA. Not because it's free (though that helps), but because it's the most representative of real-world usage. When you test with NVDA, you're testing with the tool that the largest number of actual screen reader users are using on a daily basis. And it's not just about popularity. NVDA is open source, developed by the non-profit NV Access, first released in April 2006, and it's been translated by volunteers into more than 55 languages and used in more than 175 countries (NV Access). That's a global tool, not a niche product. So when I sit down to test a web app, I open NVDA first. If it works in NVDA, I'm confident it works for a large portion of the screen reader community. If it doesn't, I've found a bug that matters.

A Concrete Scenario: The Checkout Flow

Let's walk through a realistic scenario. Imagine you're a developer on an e-commerce site. You've just added a new multi-step checkout form. You're about to test it with NVDA. You press NVDA+Down Arrow to start reading the page. The first thing you hear is the heading: 'Checkout Step 1 of 3.' Good. Then you tab to the first input: 'First name, edit text.' Fine. But then you tab to the second input, and you hear: 'Edit text.' No label. That's a problem. The WebAIM Million found that missing form input labels are among the most common WCAG failures, appearing on 51% of home pages (WebAIM Million). You've just reproduced a real-world error that affects millions of users. And it's not just about labels. Low contrast text affects 83.9% of home pages (WebAIM Million). When you test with NVDA, you're not just checking if the screen reader can read the text; you're checking if the user can actually see it. And if they can't, you've failed them.

The Business Case: Lawsuits and Productivity

Now, I'm not just an idealist; I'm a pragmatist. Accessibility has a business case. In 2025, US federal website accessibility lawsuits reached 3,117, a 27% increase from 2,452 in 2024 (WebAIM). That's a lot of legal risk. The U.S. Department of Justice has made it clear that inaccessible web content denies people with disabilities equal access, and that the ADA requires state and local governments and businesses open to the public to make their websites accessible (ADA.gov). The European Accessibility Act applies from 28 June 2025 (European Accessibility Act). So if you're not testing, you're exposing your company to legal action. But beyond the legal risk, there's the human cost. Labor force participation for working-age adults with vision difficulty is 47%, versus 75% for those without (WebAIM). That's a 28-percentage-point gap. When you make your site accessible, you're helping to close that gap. And the productivity cost of vision impairment alone is estimated at US$ 411 billion annually (World Health Organization). That's not a rounding error.

What I'd Actually Do

So here's my recommendation, and I'm not shy about it: make NVDA the default screen reader for your team's accessibility testing. Download it, install it, and run it against every new feature before you merge. It's free, it's open source, and it's what most real users are using. If you have time, add VoiceOver for iOS and TalkBack for Android, because mobile usage is huge—91.3% of screen reader users use a mobile device (WebAIM). But start with NVDA. And don't just test once; make it part of your definition of done. Run a quick NVDA smoke test on every page that has forms, buttons, or dynamic content. If you find a bug, fix it before you ship. It's that simple. And if you're worried about the learning curve, start small: just tab through your page and listen. You'll be amazed at what you hear.

Sources

  • World Health Organization - https://www.who.int/news-room/fact-sheets/detail/assistive-technology
  • 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/
  • ADA.gov - https://www.ada.gov/resources/web-guidance/
  • European Accessibility Act - https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L0882

Share this article:

Comments (0)

No comments yet. Be the first to comment!