WCAG.World
Free Audit Discuss a journey

← All articles

Screen Readers · Testing · NVDA

A Practical Screen Reader Testing Walkthrough: NVDA and VoiceOver Basics

WCAG.World Team · Aug 16, 2026 · 8 min read

  • Screen Readers
  • Testing
  • NVDA

The Clean Report That Wasn't

A QA engineer runs an automated accessibility scanner against the checkout flow before a release. Green across the board. No errors, no warnings, ship it.

Three weeks later, a support ticket comes in from a screen reader user who cannot complete checkout. Not "it's a little clunky" — cannot complete it. The payment field is announced only as "edit text." The error message that appears after a failed submission never gets read aloud; it just changes color on screen. The "continue" button, focus-trapped inside a promo modal that popped up on page load, is technically reachable by keyboard, but nothing tells a screen reader user the modal exists in the first place.

None of that showed up in the scan. It couldn't have. The scanner checks code patterns — does this input have a label element, does this image have an alt attribute — not what actually gets spoken out loud when a real person uses a real screen reader. Those are two different questions, and the gap between them is where a lot of expensive accessibility failures live.

This is not an argument against automated tools. It's an argument for adding the one thing they structurally cannot do: listening.

Why the Scanner Missed It — On Purpose, Sort Of

Automated accessibility scanners like axe, WAVE, and Lighthouse are fast, cheap, and genuinely useful. Run them constantly. But by design, they can only catch what's programmatically detectable in the code — an image with a missing alt attribute, a form field with no associated label, a contrast ratio that fails a math check.

Commonly-cited industry estimates put automated coverage at roughly 30-40% of WCAG success criteria. That's not a rounding error. That's the majority of the standard left untested by tooling alone.

Here's what falls into that uncovered 60-70%, every time, no exception:

  • Alt text that's present but meaningless. alt="image1234.jpg" passes every automated check. It fails every real user.
  • Focus order that's technically valid but confusing. Every element is reachable in some sequence — the scanner is satisfied. Whether that sequence makes any sense read aloud, in order, is a judgment call no linter can make.
  • ARIA labels that exist but don't communicate anything useful. aria-label="click here" on a button is present, valid ARIA, and completely uninformative.
  • Dynamic content updates that never get announced — a cart count that changes, a form error that appears — silently, with no aria-live region telling assistive tech that anything happened at all.

Catching these requires an actual human, ideally a screen reader user, actually listening to the page. That's the whole reason this walkthrough exists.

Meet the Screen Readers You're Actually Testing Against

Before touching a keyboard, know who you're testing for. Four screen readers cover the overwhelming majority of real-world use:

  • NVDA — free, open-source, Windows-only. Most commonly paired with Firefox or Chrome. The most accessible starting point for a team that doesn't already own screen reader software, because the price is zero.
  • JAWS — paid, Windows-only, historically the most common screen reader in enterprise and government use. If your audience skews toward institutional or public-sector users, JAWS behavior matters even if you test primarily with NVDA.
  • VoiceOver — free, built directly into every Mac and iOS device. Pairs with Safari. If your users are on iPhones, VoiceOver is not optional to consider — it's often the default assistive tech on that platform.
  • TalkBack — free, built into Android, the parallel to VoiceOver on Google's mobile ecosystem.

The practical takeaway: NVDA and VoiceOver are both free, both good, and between them cover the two major desktop/OS combinations most teams need to validate first. That's why this walkthrough centers on those two.

Getting Started With NVDA (Windows)

NVDA is a full application, but you only need a handful of commands to run a genuinely useful test.

Core commands:

  • Control — turn NVDA on/off (interrupts speech immediately, useful when you need silence fast).
  • Insert+S — toggle NVDA's speech on/off.
  • Down Arrow — read line by line, moving forward through content.
  • H — jump to the next heading. Shift+H — jump to the previous one.
  • D — jump between landmarks and regions (header, nav, main, footer).
  • Tab — move between focusable/interactive elements, same as any keyboard-only navigation.
  • NVDA+F7 — open the Elements List, a dialog showing every heading, link, or landmark on the page at once.

That last one — NVDA+F7 — is the fastest single move in this entire guide. Instead of tabbing through a page one element at a time, you get the whole structural skeleton in a list. Open it, switch the view to "Headings," and you'll immediately see whether the page has one clear H1, a logical H2/H3 hierarchy, or a mess of headings picked for font size rather than structure. Switch to "Links" and you'll instantly spot every link labeled "click here" or "read more" with no distinguishing context — technically present, functionally useless when read out of context in a list.

Getting Started With VoiceOver (Mac)

VoiceOver ships on every Mac, no install required, and pairs naturally with Safari.

Core commands:

  • Command+F5 — turn VoiceOver on/off.
  • Control+Option — the VoiceOver modifier, referred to as "VO" in every VoiceOver reference. Nearly every VoiceOver command starts with holding this combination.
  • VO+Right Arrow / VO+Left Arrow — move forward/backward through content, item by item.
  • VO+Command+H — jump between headings.
  • VO+U — open the Rotor, a menu for jumping directly to headings, links, form controls, or landmarks.

The Rotor is VoiceOver's answer to NVDA's Elements List, and it does the same job: give you a structural overview instead of forcing you to arrow through everything sequentially. Open it on any page you're testing, flip to headings, and ask whether reading just that list — nothing else — tells you what's on the page and how it's organized.

The Protocol: Same Test, Either Tool

Here's a simple, repeatable test you can run with NVDA or VoiceOver, no special setup, in under thirty minutes:

  1. Turn off your monitor, or just close your eyes. This isn't theatrical — it forces you to rely entirely on what's spoken, which is exactly the constraint your screen reader users live with.
  2. Navigate the homepage using only heading navigation (H in NVDA, VO+Command+H in VoiceOver). Can you understand the page's structure — what it is, what the main sections are — from the headings alone, without seeing anything?
  3. Tab through your primary conversion flow — signup, checkout, contact form, whatever converts a visitor into a customer. Is every field's purpose announced clearly? Are validation errors announced when they appear, not just displayed visually? Can you complete the entire flow start to finish without ever touching the mouse?

If you want a running checklist for that session, this is it:

  • Open the Elements List (NVDA+F7) or Rotor (VO+U) and review the heading hierarchy — is there one clear structure, or a jumble?
  • Skim the links list — does every link make sense read in isolation, without surrounding text?
  • Tab through the primary conversion form field by field — is every input's purpose announced?
  • Submit the form with an intentional error — does the screen reader announce the error, or only show it visually?
  • Trigger any dynamic UI (modal, cart update, live search results) — does anything get spoken when it appears?

Run this on your three most important user flows — usually homepage, signup/checkout, and one core feature — and budget 20-30 minutes with just one of these tools. That's usually enough to surface issues an automated scan missed entirely.

What This Kind of Testing Actually Catches

To bring it back to the opening story: none of the checkout failures described there — the unlabeled payment field, the silent error message, the modal that swallowed focus without announcing itself — would have shown up in an axe or Lighthouse report. They're not code-pattern failures. They're experience failures, and experience failures only show up when something reads the page out loud and a human judges whether it made sense.

That's the specific, structural gap screen reader testing closes: illogical heading hierarchies that pass every automated check, ARIA labels that are technically present but say nothing useful, dynamic content that updates on screen and never reaches assistive tech, and modals that trap or lose focus in ways no linter flags but every real user notices immediately.

Where to Go From Here

NVDA and VoiceOver are both free. The commands above are enough to run a real test today, on your own site, with nothing to install beyond what's already built into Windows or your Mac. Thirty minutes with one of these tools, run against your top three flows, will tell you more about your site's real-world accessibility than another clean scanner report ever will.

If you'd rather have that testing done properly — across NVDA, JAWS, and VoiceOver, on your actual conversion flows, by people who do this for a living — see how a full screen reader audit works.