Why We Test with NVDA First: A Practitioner's Walkthrough

About 95.9% of home pages have detectable WCAG 2 failures, according to the WebAIM Million analysis (WebAIM Million). That’s almost every site, and it’s not because developers are sloppy. It’s because we’re testing blind — pun intended. We run automated checks, maybe squint at contrast ratios, but we rarely open an actual screen reader and listen to what our users hear. That changes today.

This guide is for web developers, designers, and QA folks who want to stop guessing and start testing with the tool that 65.6% of screen reader users actually prefer: NVDA (WebAIM). We’re not just advocating for NVDA because it’s free — we’re advocating for it because it’s the most commonly used screen reader among real users, and it’s the one you can install and start using in minutes. Here’s how we do it, step by step, with the gotchas we’ve hit along the way.

Who This Walkthrough Is For

If you’ve never touched a screen reader, this is for you. If you’ve tried VoiceOver on a Mac and gave up because the gestures felt alien, this is for you. If you’re a developer who thinks “accessibility is a checklist,” this is for you. We’re writing as practitioners who test with NVDA on Windows because that’s where the majority of desktop users are, and because NVDA is free, open source, and backed by a non-profit (NV Access). You don’t need a license or a special setup — just a Windows machine and a few minutes.

Step 1: Install NVDA and Learn the Basics

Head to nvaccess.org, download NVDA, and install it. It takes two minutes. When you launch it, you’ll hear a synthetic voice read whatever is on screen. Don’t panic. The learning curve is real, but you only need four commands to start: Insert+F5 to list links, Insert+F7 to list headings, the Tab key to move between focusable elements, and the arrow keys to read line by line. If you’re on a laptop, the modifier key is Caps Lock instead of Insert. Write these on a sticky note. You’ll use them constantly.

One thing that surprises people: NVDA isn’t just for blind users. It’s a tool for anyone who wants to understand how their content sounds. And with 76.6% of screen reader users reporting blindness (WebAIM), you’re testing for the majority of your assistive tech audience.

Step 2: Set Up a Test Page That Mirrors Your Real Content

Don’t test on a bare HTML skeleton. Use a live page from your site, or a staging page with realistic text, images, forms, and navigation. Why? Because accessibility issues often appear in context. For example, a form without labels is a problem, but a form with labels that aren’t associated properly is worse — and you’ll only catch that when you tab through the field and hear “Edit, blank” instead of “Your name, Edit, text.”

Of the 96% of errors on home pages, the top six are low contrast, missing alt text, missing labels, empty links, empty buttons, and missing language. You’ll hit all of these in a single page test. So grab a page that has a hero image, a nav menu, a form (even a search box), and a few buttons. That’s your test bed.

Step 3: Do a Heading and Link Audit

Press Insert+F7 to open the elements list. This shows you all the headings and links on the page. Close your eyes — figuratively — and ask: Does the heading order make sense? Does a blind user know where they are? Headings are how screen reader users navigate, and if your CSS uses divs with bold text instead of real heading tags, you’re invisible.

Then check the links list. Do the link names make sense out of context? “Click here” is worthless. “Read the 2024 annual report” is useful. If you see a link that says “Learn more” with no other text, that’s a fail. And remember: 53.1% of home pages have missing alt text (WebAIM Million). When you encounter an image, NVDA will say “Graphic” — that’s your cue to check if it has alt text. If it’s decorative, it should be empty alt, but if it’s informative, you need descriptive text.

Step 4: Tab Through the Page Like a Keyboard User

Now the real fun. Start at the top of the page and press Tab repeatedly. You’ll hear focus move through links, buttons, and form fields. What you’re listening for is logical order. Does tab order match the visual layout? Or does it jump around? If your CSS uses floats or grid with a weird DOM order, you’ll confuse your users.

Also listen for focus indicators. If you can’t see where the focus is, neither can a sighted keyboard user. WCAG 2.2 requires visible focus indicators (W3C). When you tab to a link, NVDA should say something like “About us, link” and the browser should draw a visible outline. If you’ve set outline: none, you’re failing.

What can go wrong: You might feel lost in a maze of unlabeled buttons. That’s expected. But if you tab through and hear “Button” with no name, that’s a real issue. The WebAIM Million found 30.6% of home pages have empty buttons. Those are the ones that say “Button” with no accessible name — a nightmare for screen reader users.

Step 5: Test Forms and Errors

Forms are where accessibility goes to die. Find a form on your page — even a simple search box. Tab into the field. NVDA should announce the label. If you hear “Edit, blank” and you don’t know what it’s for, that’s a missing label, which 51% of home pages have (WebAIM Million). Add a element with a for attribute, or use aria-label. Then test error messages: submit the form empty. Does NVDA announce the error? If the error is just a red border, you’ve failed. The error needs a text description, often via aria-describedby.

We once had a form where the error message was off-screen, visually hidden. NVDA didn’t read it because it wasn’t in the accessibility tree. We had to use aria-live to announce it. That’s the kind of thing you only catch by actually testing.

Step 6: Don’t Forget Mobile and Braille

Screen reader use isn’t just on desktop. 91.3% of screen reader users use them on mobile devices (WebAIM). So after you’ve tested on desktop with NVDA, open your site on a phone and try VoiceOver (iPhone) or TalkBack (Android). They behave differently — mobile swipes vs. desktop keys. You don’t have to become an expert, but you should at least know that your mobile menu works with a screen reader.

And if you’re feeling brave, try a braille display. 38% of screen reader users use braille output (WebAIM). NVDA works with braille displays, but it’s a niche skill. We’re not saying you need to master braille, but knowing it exists helps you design with semantics in mind — braille users can’t perceive color, so your text must stand on its own.

The Single Most Important Thing to Remember

Automated testing won’t save you. The WebAIM Million found that the most common errors are detectable by automated tools, yet 95.9% of pages still fail. The only way to catch the real issues is to listen. So install NVDA, spend 15 minutes on your own site, and you’ll be ahead of 95% of the web.

Sources

• WebAIM Million - https://webaim.org/projects/million/
• WebAIM Screen Reader User Survey - https://webaim.org/projects/screenreadersurvey10/
• NV Access - https://www.nvaccess.org/about-nv-access/
• W3C Web Accessibility Initiative (WCAG) - https://www.w3.org/WAI/standards-guidelines/wcag/