How to Test Your Website With a Screen Reader (30-Minute Owner's Protocol)

You can test your website with a screen reader today, for free, in about 30 minutes. On a Mac, press Command-F5 and VoiceOver starts talking. On Windows, download NVDA free from nvaccess.org. Learn five keystrokes, then try three tasks on your own site: find your phone number, submit your contact form, and buy one product — by listening, not looking.

Almost every guide on this topic is written for developers and QA teams. This one isn’t. It’s for the owner who wants to hear what a blind customer hears before deciding what to fix. You already ran the 10-minute keyboard test? Good — this is the audio layer on top of it.

Which screen reader should you use?

Use the free one that matches the computer you already own. VoiceOver ships with every Mac — Apple’s own documentation says to “press Command-F5” to turn it on or off. NVDA is a free download for Windows 10 and later; NV Access states plainly that “the NVDA screen reader can be downloaded free of charge by anyone” (nvaccess.org). It runs on donations, so throw a few dollars in if the test proves useful.

These aren’t toy substitutes. In WebAIM’s Screen Reader User Survey #10 — 1,539 screen reader users surveyed in December 2023 and January 2024 — 37.7% named NVDA their primary desktop screen reader, just behind the paid JAWS at 40.5%, with VoiceOver at 9.7%. Testing with NVDA or VoiceOver means testing with tools real customers actually use. (For how these tools work under the hood, see our screen reader guide.)

One honest note before you start: expect the first five minutes to feel overwhelming. The voice is fast and it announces everything. That’s normal. Slow the speech rate in settings if you need to, and remember — your customers do this fluently every day.

The 5 keystrokes for VoiceOver (Mac)

Turn VoiceOver on with Command-F5 (on some laptops you may need to hold the Fn key too, per WebAIM’s VoiceOver guide). On Macs with Touch ID, Apple’s documentation says to hold the Command key and quickly press Touch ID three times. VoiceOver commands use the “VO keys” — Control+Option, held together. Open Safari, load your homepage, and you only need these five:

The rotor (keystroke 5) is the revealing one. It shows your page the way a blind visitor scans it: as a bare list of headings and links, stripped of all design. If that list reads like gibberish — “click here, click here, learn more, image1234.jpg” — you’ve already found a problem.

The 5 keystrokes for NVDA (Windows)

Install NVDA from nvaccess.org, and during setup let it use Caps Lock as the “NVDA key” — WebAIM’s NVDA guide recommends this so you don’t hunt for the Insert key. Open Chrome or Edge, load your homepage, and use these five:

Notice both tools have the same shape: read, stop, jump by heading, Tab, and a page-outline view. That’s not a coincidence. In WebAIM’s survey, 71.6% of screen reader users said they navigate long pages by jumping through headings — it’s the single most common strategy (WebAIM Survey #10). If your heading structure is decorative instead of meaningful, you’ve broken most users’ primary way of moving around.

Test 1 — Find your phone number (5 minutes)

Load your homepage, put your hands on the keyboard, and find your business phone number using only keystrokes 3, 4, and 5 — no scrolling, no looking for the pretty header. Press H (or VO+Command+H) to walk the headings. Open the elements list. Tab if you have to.

Pass: you reach the number in under a minute, and the screen reader speaks it as a phone number or a “call” link.

Fail looks like: the number only exists inside an image banner with no alt text, so it’s never spoken. Or it’s in the footer behind ninety Tab stops. Or the headings list is empty because your theme used styled bold text instead of real heading tags. Failing this test means a blind customer literally cannot call you — the cheapest possible sale, lost at step zero.

Test 2 — Submit your contact form (10 minutes)

Go to your contact page and complete the form by ear. Tab into each field and listen to what’s announced before you type. Then submit it once with a deliberate error — a bad email address — and listen to what happens.

Pass: every field announces a meaningful label (“Name, edit text”, “Email, edit text”), and after the bad submit, the screen reader tells you what went wrong and where.

Fail looks like: Tab lands on a field and the screen reader says only “edit text” — no label, so the user is typing into a mystery box. Or you submit and hear silence while a red error message appears visually, announced to no one. Both are classic failures we cover in accessible forms and accessible form error messages. A silent form is a dead lead-generation channel for every screen reader user who tries it.

Test 3 — Buy one product or book one appointment (15 minutes)

Now the money path. Pick your cheapest product, or your booking/quote flow, and go as far as you can by ear: find the product, choose any option (size, date, quantity), add to cart, and open checkout. You don’t need to complete payment — reaching a checkout form with labeled fields counts.

Pass: every step announces itself. Buttons say what they do (“Add to cart, button”), options confirm when selected, and the cart tells you what’s in it.

Fail looks like: an unlabeled icon button announced only as “button.” A size picker that never confirms your choice. A cart total that updates visually but is never spoken. Any one of these ends the purchase. This is also where lawsuits concentrate — plaintiffs’ testers document exactly these checkout failures, which we break down in our screen reader checkout post. If you sell online, this fifteen minutes tells you whether an entire customer segment can pay you.

What failing each test actually means

Score yourself honestly. Here’s the translation from “that felt broken” to what’s wrong underneath:

Two things matter about that list. First, none of it is exotic — labels, headings, alt text, and announced updates are among the most common failures on the web, and every one has a well-understood code fix. Second, none of it can be patched by an overlay widget, because the screen reader reads your actual HTML. We proved that point by testing widgets with a screen reader directly.

What this test can’t tell you

Passing all three tasks is genuinely good news, but keep it in proportion. You tested one screen reader, one browser, three paths, as a beginner. You did not test color contrast, caption quality, zoom and reflow, or the dozens of WCAG 2.1 AA criteria that need code review — and a beginner’s pass can miss problems an experienced screen reader user would hit in seconds. Automated tools have the mirror-image blind spots, which is why automated scans miss so many real issues and why professional testing combines both.

So treat your 30 minutes as triage, not certification. Write down every point where you got lost, heard silence, or heard nonsense — page, element, what you expected to hear. That list is exactly what a developer or a remediation team needs to start fixing the real code.

If you want the machine-readable half of the picture to go with your listening test, run our free accessibility scan — it takes about a minute and flags the code-level issues your ears can’t catch. And if the three tasks went badly, a full accessibility audit does what you just did professionally: real assistive technology, every critical path, mapped to the exact code fixes.