Screen reader testing in 20 minutes

Most developers have never used a screen reader on their own site.

This is the single most common gap in accessibility practice. Automated tools catch roughly half of WCAG issues. A human with a screen reader catches the other half, plus the ones that do not map to WCAG at all.

Twenty minutes of real use finds more than most three-day audits. This is the practical version: how to set up, what shortcuts to learn, how to run the test, what to listen for, how to interpret what you hear, and how to make the whole thing a habit.

Setup

You already have a screen reader on your machine. Nothing to install, with one exception.

macOS: VoiceOver

Built in. Toggle with Cmd+F5. Same shortcut to turn off.

On first launch, VoiceOver runs a tutorial. Skip it the first time. Come back in a week; it is useful once you have some context.

One setting worth changing before you start: System Settings → Accessibility → VoiceOver → VoiceOver Utility → Verbosity. Set it to "High" when learning, "Medium" for regular use. Default is a middle ground that skips some information useful to a beginner.

Windows: NVDA

Free, open source, about 30 MB. Download from nvaccess.org. Installer takes 90 seconds.

NVDA is the de-facto standard on Windows. More than 60% of Windows screen reader users run it, according to the annual WebAIM survey. If you test with one screen reader on Windows, it is NVDA.

Narrator, the built-in alternative, is fine to know about. It behaves differently than NVDA, and real users are mostly on NVDA, so start with NVDA.

Linux: Orca

Usually pre-installed on Ubuntu and Fedora. Enable in accessibility settings.

Orca is less common in user data than NVDA or VoiceOver, but it is how screen reader users on Linux work. If your audience is developers, a fraction of them use it.

Mobile

Mobile screen readers behave differently enough that desktop testing does not cover them. If your product has a meaningful mobile web experience, set aside a separate twenty minutes for VoiceOver on iOS or TalkBack on Android.

The commands you need

Learn these first. Everything else can wait.

VoiceOver (macOS)

The VoiceOver key (abbreviated VO) is Ctrl+Option. Hold them, then press another key.

1. Read the next element. VO+Right Arrow.
2. Read the previous element. VO+Left Arrow.
3. Read everything from here. VO+A.
4. Stop reading. Ctrl.
5. Open the rotor. VO+U. The rotor lists headings, links, form controls, landmarks. Left/Right Arrow switch category, Up/Down Arrow navigate within, Enter to jump.
6. Next heading. VO+Cmd+H.
7. Next link. VO+Cmd+L.
8. Interact with a control. VO+Shift+Down Arrow. Needed for complex widgets like date pickers. VO+Shift+Up Arrow to exit interaction.
9. Focus web content. VO+U, then arrow to "Web Areas" and Enter.

Ten commands. All you need for 90% of real testing.

NVDA (Windows)

NVDA has two modes: browse mode for reading pages, focus mode for interacting with forms and widgets. It switches automatically most of the time.

The NVDA key is Insert by default, or Caps Lock if you chose the laptop layout during install.

1. Read next line. Down Arrow in browse mode.
2. Read entire page from here. NVDA+Down Arrow.
3. Stop reading. Ctrl.
4. Next heading. H. Previous: Shift+H. Specific level: 1 through 6.
5. Next link. K. Previous: Shift+K.
6. Next form field. F. Next button: B. Next landmark: D.
7. Elements list. NVDA+F7. Browse headings, links, landmarks from a single dialog.
8. Toggle browse / focus mode. NVDA+Space.
9. Exit focus mode back to browse. Escape.
10. Activate link or button. Enter in browse mode.

The test procedure

Open your site with the screen reader running. Close your eyes, cover the screen, or commit to not looking. The not-looking is the point. You are approximating, imperfectly, the audio-only experience.

Run through the core task of the site. Sign up. Buy something. Submit the main form. Whatever the site exists to do, do it with keyboard and screen reader.

Take notes as you go. A text document on a second screen is fine. Write down what you heard, what you expected to hear, and what confused you.

The test structure:

1. Land on the homepage. Listen to the initial announcement. Is the page title sensible? Does the screen reader immediately read something useful, or noise?
2. Use the skip link. Tab once and listen. Skip links visible only on focus are fine. Press Enter and verify the target is focusable and announced.
3. Navigate the main nav. Tab through. Are the items labeled? Does the order make sense? Can you tell which item is active?
4. Read the page through. Use VO+A or NVDA+Down. Let it go. Note what gets read twice, read in the wrong order, or skipped.
5. Jump by heading. Cycle through headings only. Is the structure coherent? Do you land in main content quickly, or bounce around nav and sidebars?
6. Interact with the primary control. Open the modal, fill the form, start the flow.
7. Complete the core task. Whatever that is.
8. Observe errors. Force a form error if applicable. Is it announced? Is the error message reachable by keyboard from where focus currently is?
9. Navigate back out. Close modals, return to home, log out. Errors often happen on exits.

Aim for the whole thing in under fifteen minutes on the first site you test. It will be slow. The next one is faster.

What to listen for

Specific things common in 2026 sites:

• Page has no heading structure. The screen reader cannot orient. Users cannot jump to content. Fix: real HTML headings in the right hierarchy. An h1 on the page, h2 for sections, no skipped levels.
• Buttons with no label. Screen reader reads "button," "button," "button." Users have no idea what each does. Fix: visible text content on the button, or aria-label if the button has only an icon.
• Images with AI-generated alt text. Long descriptions that do not say what the image is for in the page. Fix: write short, context-specific alt text. Decorative images get alt="".
• Decorative SVGs getting read. Icons announced as "path, path, path, path." Fix: aria-hidden="true" on decorative SVGs, or wrap them with proper semantics if they carry meaning.
• Form fields with placeholders but no labels. Placeholder is read once and gone. Screen reader users navigating back through the form cannot tell which field is which. Fix: always associate a <label> with each input.
• Form errors not announced. User submits, form fails, screen reader says nothing. Fix: errors in an aria-live="assertive" region or programmatically focus the first error message.
• Modal dialogs that do not trap focus. Tab continues into the page behind. The user is reading wrong content and does not know the modal is still open. Fix: focus trap on open, restore focus on close.
• Live updates not announced. The "added to cart" toast that appears silently. Fix: wrap transient status messages in aria-live="polite".
• Route changes in SPAs with no announcement. User activated a link, content changed, screen reader said nothing. Fix: update document.title and move focus to the new page's h1 with tabindex="-1".
• Links that all say "click here." No way to distinguish them out of context. The rotor shows a useless list. Fix: rewrite link text to describe the destination.
• ARIA that lies. Roles and labels that do not match behavior. role="button" on something that does not behave like a button. Real assistive tech treats ARIA as authoritative. Wrong ARIA is worse than no ARIA. Fix: remove ARIA that does not reflect actual behavior, or make the element actually behave correctly.

Interpreting what you hear

A useful rule: if you could not, from the screen reader's output alone, complete the core task, the site is failing at task level. Most audits check component behavior. The screen reader check you just did was task-level. Task-level is the bar that matters.

Symptoms and what they usually mean:

• "button, button, button" while tabbing. Missing accessible name on each button. Look for SVG-only buttons or icon-only buttons with no aria-label.
• Very long output on small images. AI-generated or auto-generated alt, usually from a CMS or an accessibility overlay. Fix the source, not the output.
• Silence when you activate something. Missing aria-live on the updated region, or the change happened somewhere the screen reader was not watching.
• Reading the same thing twice. Duplicated content, usually a hidden text label plus a visible text label both being read, or aria-labelledby pointing to content that is also read directly.
• Reading in the wrong order. DOM order does not match visual order. CSS positioning rearranged the page without changing the source. Screen reader follows DOM.
• "Tab, tab, tab, tab" with no announcement. Focus is landing on elements that are focusable but have no accessible name. Usually <div> or <span> with tabindex="0" and no label.
• "Link, link, link" in rapid succession. Multiple identical or unlabeled links, often icon buttons styled as links.

What not to do

Some missteps that make the test less useful.

• Do not use a screen reader only with your eyes open. You will unconsciously use visual feedback to compensate. The point is to experience audio-only.
• Do not test only the happy path. Error states, empty states, loading states are often where the worst issues hide.
• Do not rely on "it works in Chrome with VoiceOver." Test at least one other combination before shipping anything major. The real-world matrix is NVDA+Firefox, NVDA+Chrome, JAWS+Chrome, VoiceOver+Safari. Pick at least two.
• Do not assume you understand what a real user wants. You are testing whether the site is usable in principle. Usability with experience is a separate question, answered by testing with actual screen reader users.
• Do not treat a passing test as "done." The twenty minutes catch the obvious. A professional audit catches more. Testing with real users catches the rest. The twenty minutes are the floor, not the ceiling.

Making this a habit

Once the initial twenty minutes has surprised you, the challenge is keeping the practice alive.

A few patterns that work:

1. Add a screen reader check to the PR review checklist. Not "did you run an audit tool." "Did you actually navigate this with a screen reader." Five minutes per PR catches most regressions.
2. Set up a keyboard shortcut to toggle VoiceOver or NVDA. Reducing the friction of turning it on is half the battle.
3. Keep a small test suite of core flows. The same five flows, re-run every week. Recurring tests are where regressions show up.
4. Pair with a real screen reader user once a quarter. Nothing substitutes for watching someone who depends on a screen reader use your product. It will reorder your priorities.
5. Log issues as bugs, not as "accessibility improvements." An inaccessible primary flow is a functional bug. Classifying it that way changes how it gets prioritized.

The payoff

Two things change after the first twenty minutes.

First, the experience is uncomfortable. Most developers describe it as disorienting. That is the experience many disabled users have all day, on the sites they rely on for banking, medicine, and government services. You will build different products after having the experience.

Second, you start noticing issues in code review. You push back on PRs that add buttons without labels, images without alt, forms without proper field structure. Not from policy. From muscle memory. That is the more valuable change, and it is the one the twenty minutes buys.

What does not work

Reading about screen readers. Watching videos of screen readers. Knowing the WCAG criteria for screen reader support.

None of those produce the muscle memory. The twenty minutes do.

Do the twenty minutes. If you have read this and not done them, you have not done the work. That sentence sounds harsh. It is also the most important thing in this post.