Screen Reader Testing in 5 Minutes: A Developer's Quick Start Guide

Originally published at A11yFix.

I'll be honest: the first time I tried to test my website with a screen reader, I panicked. A robotic voice started reading everything on my page at top speed, I couldn't figure out how to stop it, and I ended up force-quitting the application. Sound familiar?

Here's what I wish someone had told me: screen reader testing doesn't have to be scary, and you can learn the basics in about five minutes. This guide will get you from zero to actually running a meaningful screen reader test on your website.

Why Bother Testing with a Screen Reader?

Automated accessibility tools catch roughly 30-40% of accessibility issues. The rest? You need manual testing. Screen readers reveal problems that no linter or CI check will find:

• Images with meaningless alt text ("image123.png")


• Form fields that have no programmatic label


• Custom components that look interactive but can't be reached with a keyboard


• Content that appears visually ordered but reads in a confusing sequence

You don't need to become an expert. You just need to catch the obvious problems.

VoiceOver on Mac (Built-in, Zero Setup)

VoiceOver is already on your Mac. No downloads, no installs.

Turn it on: Press Cmd + F5 (or touch the Touch ID button three times if you've set that up).

Essential shortcuts:

Your first test in 60 seconds:

1. Open your site in Safari (VoiceOver works best with Safari)


2. Turn on VoiceOver with Cmd + F5
   


3. Press VO + Right Arrow repeatedly to move through elements


4. Listen: does each element make sense on its own? Does a button say "Submit your application" or just "Click here"?


5. Press VO + U to open the Rotor, then arrow to "Headings" - is your heading structure logical?


6. Turn it off with Cmd + F5
   

NVDA on Windows (Free Download)

NVDA is a free, open-source screen reader. Download it from nvaccess.org.

Essential shortcuts:

Tip: NVDA defaults to "Browse mode" in web content, which means single-letter navigation works. Press H to jump to the next heading, F for the next form field, T for the next table.

What to Listen For: A 5-Point Check

Once you can navigate, here's a quick checklist. Run through these five checks and you'll catch the majority of screen reader issues:

1. Page Title

When the page loads, does the screen reader announce a meaningful title? "Dashboard - MyApp" is good. "React App" is not.

2. Heading Structure

Navigate through headings (Rotor on Mac, H key on NVDA). You should hear a logical hierarchy: H1 for the page title, H2 for sections, H3 for subsections. Skipped levels or missing headings mean users can't scan your page.

3. Link and Button Labels

Tab through interactive elements. Each one should announce what it does. "Read more about pricing plans" tells users where they're going. "Read more" repeated six times does not. "Button" with no label is a dealbreaker.

4. Form Labels

Navigate to a form and listen. Each input should announce its label when focused. If you hear "edit text" with no context, your input is missing a programmatic label. This is one of the most common accessibility failures, and one of the easiest to fix with a proper <label> element.

5. Image Alt Text

Navigate through images. Decorative images should be silent (empty alt=""). Informational images should describe their content. If you hear a filename or a generic "image," that's a problem.

Common Gotchas

The screen reader won't stop talking. Press Ctrl to silence it. This works in both VoiceOver and NVDA.

VoiceOver isn't reading my page correctly. Make sure you're using Safari. VoiceOver's best support is with Safari, not Chrome or Firefox.

NVDA isn't responding to single-key navigation. You might be in "Focus mode" instead of "Browse mode." Press Insert + Space to toggle.

Custom components aren't announced properly. If you built a dropdown or modal with <div> elements, add ARIA roles and states. But first, consider whether a native HTML element (like <select> or <dialog>) would work instead.

Make It a Habit

You don't need to run a full screen reader audit on every commit. But doing this 5-minute check on key pages, especially after building new features, will catch problems before your users do.

My recommendation: pick one page right now, turn on VoiceOver or NVDA, and run through the five checks above. You'll be surprised what you find.

If you're working on accessibility compliance, I put together a free 10-point EAA quick-check: Get the free checklist