Skip to main content
ADA Fail

How to Test Your Website With a Screen Reader (VoiceOver & NVDA for Beginners)

Test your website with a screen reader in under an hour: a beginner's guide to VoiceOver and NVDA, the keys to know, and exactly what to listen for.

← Back to Blog
7 min read · by ADA Fail Team
How to Test Your Website With a Screen Reader (VoiceOver & NVDA for Beginners)

To test your website with a screen reader, turn on a reader you already have — VoiceOver on any Mac (press Command+F5) or the free NVDA on Windows — close your eyes or turn off the monitor, and navigate a real page using only the keyboard while listening to what it announces. Move heading by heading and link by link, try to complete one real task like submitting your contact form, and note every place where the reader says nothing, says the wrong thing, or leaves you lost. That listening pass takes about 30 to 60 minutes and reveals barriers that no visual review and no automated scan will ever catch.

Why test your website with a screen reader at all?

Over 1 in 4 U.S. adults live with a disability, and people who are blind or have low vision rely on screen readers to use the web. When your markup is wrong, the software has nothing to announce — an unlabeled button becomes "button," an image with no alt text becomes "image," a form field with no label becomes a silent guess.

This is also where the law lives. More than 5,000 digital-accessibility lawsuits were filed in 2025, and a plaintiff's expert almost always runs a screen reader against the site. WebAIM's 2025 analysis of the top one million homepages found detectable WCAG failures on 94.8% of them, led by low-contrast text, missing image alt text, and missing form labels — exactly the problems a screen reader surfaces out loud. Automated scanners catch only about a third of WCAG 2.2 success criteria; the rest, including how content actually sounds, require a human at the keyboard.

Which screen reader should a beginner use?

Use the one that's free and already on your machine. You do not need to buy anything to start.

VoiceOver on Mac

VoiceOver ships with every Mac. Turn it on with Command+F5 (or ask Siri to "turn on VoiceOver"). The first time, run the built-in Quick Start tutorial it offers — ten minutes well spent. VoiceOver pairs naturally with Safari, so test in that combination. The key you'll lean on is Control+Option, called "VO," which prefixes most commands.

NVDA on Windows

NVDA is a free, open-source screen reader and the most representative choice for Windows testing. Download it from the NV Access site, install it, and pair it with Firefox or Chrome — the combinations real users run. Its modifier key is Insert (or Caps Lock if you enable that during setup).

Whichever you pick, be patient: the voice is fast and robotic at first. Slow the speech rate down in the settings until you can follow every word.

How do I test my site with a screen reader, step by step?

Pick a page that matters — a product page, the checkout, or your contact form, not just the marketing splash. Turn the screen reader on, then either close your eyes or turn off the monitor so you're judging what you hear, not what you remember seeing.

  1. Listen to the page load. A well-built page announces its title and gives you a sense of structure. If you're dumped into a wall of undifferentiated text, that's a signal.
  2. Navigate by heading. Press H in NVDA, or VO+Command+H in VoiceOver, to jump heading to heading. The headings should form a logical outline — one main heading, then sections nested sensibly. If a visually bold line is skipped, it isn't a real heading in the code.
  3. Pull up the links and landmarks. NVDA's Insert+F7 opens an elements list; VoiceOver's rotor is VO+U. Every link should make sense on its own. A list full of "click here" and "read more" tells you nothing about where each one goes.
  4. Tab through every control. Move through links, buttons, and form fields. Each should announce a clear name and role — "Search, button," not just "button" or, worse, silence.
  5. Fill out a form by ear. Enter each field. The reader should announce the label, whether it's required, and any error message when you submit incomplete data. Silent fields and errors that never get spoken are among the most common — and most litigated — failures.
  6. Complete one real task. Submit the contact form, or add an item to the cart, using only the keyboard and your ears. If you can't finish it, neither can a blind customer.

What should you listen for?

Four problems account for most of what you'll hear go wrong. Images announced as "image" or read as a raw filename mean missing or useless alt text — our guide on how to write alt text covers the fix. Buttons and links announced with no name mean empty controls. Form fields with no spoken label mean broken associations, which our roundup of common accessible-form mistakes unpacks. And a jumbled or skipped heading order means your structure doesn't match what people see.

Also confirm you can always tell where you are and that no popup, modal, or menu traps you with no spoken way out. A screen-reader pass and a keyboard navigation test overlap here, and running both gives a fuller picture than either alone. If your pass surfaced silent buttons or unlabeled fields, a free accessibility audit from ADA Fail will map every instance and rank them by severity.

Do accessibility widgets or overlays replace screen-reader testing?

No — and the distinction here matters, because two very different things get lumped together.

A surface-layer compliance overlay is a third-party script sold on the promise that it makes a broken site accessible automatically. It doesn't. WebAIM found sites running overlays averaged roughly as many detectable errors as sites without them. In January 2025 the FTC ordered overlay vendor accessiBe to pay $1 million over deceptive claims that its product could make any website WCAG-compliant, and the National Federation of the Blind — the people who use screen readers daily — formally opposes overlays as "not only ineffective but harmful." Run a screen reader on an overlay-equipped site and you'll hear the barriers persist, which we detail in why overlay widgets fail.

A user-facing preference widget is a different animal: a button that lets visitors adjust contrast or text size on a site that is already accessible in its code, making no compliance claims. ADA Fail runs one on this very site. Attack the false compliance claim, never the honest preference button — but don't expect either to substitute for the real markup a screen reader depends on.

What can't a screen-reader test tell you?

A DIY screen-reader pass is one of the highest-value hours you can spend, but it's a spot check, not a verdict. As a beginner you'll miss subtleties an experienced tester catches — how a custom dropdown behaves, whether an ARIA live region announces at the right moment, how dynamic updates are voiced. Fluency comes with repetition.

It also can't certify conformance. A page can sound fine on your run and pass automated scans while still failing WCAG 2.2 AA criteria that only expert human testing catches. That gap — between passing automated scans and genuine, human-verified conformance — is exactly where demand letters and lawsuits live.

Frequently asked questions

How long does it take to learn a screen reader well enough to test?

You can run a useful first pass within an hour: budget ten minutes for the built-in tutorial, then work through one real page slowly. Genuine fluency — recognizing subtle failures and knowing the shortcut keys by heart — takes several sessions. Start with the core workflow of navigating by heading, listing links, and completing one task, and your ear sharpens fast.

Should I test with VoiceOver, NVDA, or both?

If you only have time for one, use NVDA on Windows with Firefox or Chrome, because it's free and closest to what most screen-reader users run. Testing with both is better, since announcements differ between screen reader and browser pairings, and a barrier that's silent in one can be audible in another. For a serious audit, expert testers routinely check multiple combinations.

My site sounds fine in a screen reader. Does that mean it's ADA compliant?

Not on its own. There's no federal regulation spelling out a specific web standard for private businesses under ADA Title III, but courts and settlements treat WCAG 2.2 AA as the de facto benchmark, and roughly two-thirds of its criteria need human testing no single tool covers. A clean screen-reader pass is strong evidence for one dimension — real usability — but color contrast, captions, and target sizes all need their own checks before you can claim conformance. Treat a good listening test as encouraging, then verify the rest.

Ready to go past a DIY listen-through? A free ADA Fail accessibility audit tests your site against WCAG 2.2 AA — screen-reader usability included — and hands you a prioritized, plain-English list of what to fix before a demand letter does it for you.

Share this article
Next Step

Find out where your site stands
ADA Fail

Get a free WCAG 2.2 audit — no widgets, no snake oil, just a real report you can hand to any developer.

Disclaimer

The information on this site is provided for general educational purposes and does not constitute legal advice. WCAG and ADA conformance depend on your specific website, content, and jurisdiction, and no audit or service can guarantee immunity from litigation. Reading this site does not create an attorney–client or consultant relationship. For advice about your legal obligations, consult a qualified attorney. Request a free audit.