March 22, 2021 · reala11y team

Your first screen-reader test: a practical NVDA and VoiceOver workflow

A beginner's screen-reader testing workflow with NVDA on Windows and VoiceOver on Mac — the keys to learn, what to listen for, and the issues you'll find first.

You can run every automated scanner ever made and still ship a page that’s miserable to use with a screen reader. Scanners check the markup; they can’t tell you whether your page makes sense when it’s read aloud, one element at a time, with no visual layout to lean on. The only way to know that is to listen to it yourself.

That sounds intimidating. It isn’t. You don’t need to be a daily screen-reader user to catch the big problems — you need about five keyboard shortcuts and the willingness to close your eyes for a few minutes. This is a starting workflow, not a substitute for testing with people who actually rely on assistive tech, but it will surface real issues today.

Pick your tool — you already have one

• Windows: NVDA. Free and open source, the most widely used screen reader. Download it from NV Access, install, and it starts reading immediately. NVDA pairs with the Insert key as its modifier (the “NVDA key”).
• Mac: VoiceOver. Built into macOS. Turn it on with Cmd + F5. Its modifier is Control + Option, written “VO” — so “VO + A” means hold Control and Option, then press A.

Use whichever you have. Test in the browser the screen reader is happiest with: NVDA with Firefox or Chrome, VoiceOver with Safari.

The handful of keys to learn

You can do a meaningful first pass with just these.

NVDA (Windows):

• Insert + Down Arrow — start reading continuously from here (“Say all”).
• Down Arrow / Up Arrow — read the next / previous line.
• Tab — move to the next focusable control (links, buttons, inputs).
• H — jump to the next heading. 1–6 jump by heading level.
• D — cycle through landmark regions.
• K — next link. F — next form field. B — next button.
• Insert + F7 — open a list of all headings, links, and landmarks on the page.

VoiceOver (Mac):

• VO + A — read continuously from here.
• VO + Right Arrow / VO + Left Arrow — move to the next / previous item.
• Tab — next focusable control.
• VO + Cmd + H — next heading.
• VO + U — open the Rotor: a menu of headings, links, landmarks, and form controls. (You can also open the Rotor with VO + U and arrow between categories.)

Don’t try to memorise everything. Learn “read continuously,” “next heading,” “next link/control,” and “list everything.” That’s enough.

What to actually listen for

Run two passes over a representative page.

Pass 1 — read the whole thing top to bottom (Say All / VO + A). Close your eyes and listen for:

• Does the page have a sane heading outline? Open the headings list. You should hear one h1, then a logical descent (h2s for sections, h3s nested under them) with no skipped levels and no headings used purely for big text.
• Are images described? Informative images should read a meaningful alt; decorative ones should be silent. If you hear a filename like “IMG underscore 4821 dot jpg,” that image is missing real alt text.
• Does the reading order match the visual order? CSS can move things around visually while the DOM order stays put. If content reads in a jumbled sequence, your source order is wrong.

Pass 2 — tab through every interactive element. Listen for:

• Does every control announce a name? A button that says only “button,” or a field that says only “edit,” is unlabelled. (See our piece on accessible names for the fix.)
• Can you tell links apart? Open the links list. Several identical “read more” entries are a problem — the names should describe their destinations.
• Can you reach the main content quickly? Press D (NVDA) or open the Rotor (VoiceOver) and look for a main landmark and a working skip link.
• Do custom widgets work? Menus, accordions, modals, and sliders built from <div>s often can’t be operated by keyboard or announce no state. If you can’t open it or don’t hear “expanded/collapsed,” it’s broken for screen-reader users.

The findings you’ll hit first

In practice, a first screen-reader pass on a typical WordPress site turns up the same short list again and again: images with filename “alt” text, a heading outline that skips levels (an h1 jumping straight to h4 because someone liked the size), icon-only buttons with no name, generic “read more” links, and a custom slider or menu that the keyboard can’t reach. None of these are exotic. All of them are fixable.

How this fits with automated checks

Automated scanning and screen-reader testing cover different ground, and you need both. A scanner finds the things that are detectable in markup — a missing alt, a duplicate id, a skip link pointing nowhere — fast and at scale. reala11y, for example, flags those as part of a WCAG 2.2 AA pass and fixes some at the source. But automated tooling catches only about 30–40% of WCAG issues by criteria; the rest — reading order that reads sensibly, link text that’s actually descriptive, a widget that’s genuinely operable — needs a human ear. Run the scanner to clear the mechanical issues, then test by listening.

The honest takeaway

Your first screen-reader test will be slow and a little awkward, and you’ll discover things your eyes never flagged — which is exactly the point. Learn five keys, make two passes (read everything, then tab everything), and write down what sounds wrong. Pair that with an automated scan and you’ll move meaningfully toward WCAG 2.2 AA conformance. And when you can, get feedback from people who use screen readers daily: they catch what a sighted developer doing a five-minute pass never will. No tool, and no single tester, makes a site accessible on its own — but listening to your own page is one of the highest-value half-hours you can spend.