Screen Reader Testing Workflow

The plain-language idea

You cannot reliably know whether a component is accessible by reading its markup and reasoning about it. You can know it by turning on a real screen reader, closing your eyes, and trying to use the thing. Automated tools (the next lesson's subject) catch a real, useful subset of issues, but they cannot tell you whether the experience actually makes sense out loud — whether a modal's purpose is clear the instant it opens, whether a form error is announced at the moment it appears, whether a custom dropdown reads as a dropdown at all. That's a judgment only listening can make.

Three screen readers cover the vast majority of real usage, and they are not interchangeable:

• VoiceOver — built into macOS and iOS, free, the natural first choice if you're on a Mac.
• NVDA — free, Windows, widely used, often the default choice for Windows-based testing.
• JAWS — paid, Windows, still common in enterprise and government contexts where procurement has standardized on it for years.

Different screen readers can genuinely behave differently on the same markup — a component that announces cleanly in VoiceOver is not guaranteed to announce cleanly in NVDA. "Works in VoiceOver" and "works everywhere" are different claims, and treating them as the same one is a common, avoidable mistake.

See it in a real thing: testing a "load more" button

Here's a minimal, repeatable workflow for testing one specific flow — say, a "load more" button that fetches and appends results to a list:

1. Turn on the screen reader (VoiceOver: Cmd+F5 on Mac; NVDA: install and launch it on Windows).
2. Turn off the monitor, or close your eyes. This isn't theater — it forces you to rely entirely on audio, which is exactly what a blind user does, and it catches visual-only assumptions immediately (a loading spinner with no text equivalent, a success state conveyed only by a color change).
3. Navigate the flow using only the screen reader's normal commands — arrow keys and its element-cycling shortcuts, not the mouse, not sighted scanning. If you can't find the button this way, a screen reader user can't either.
4. Listen at each step: does activating the button announce that something happened (new results loading, then new results present)? Does the button's accessible name make sense on its own ("Load more results," not just "Button")? Is any state change — loading, done, error — actually spoken, or does it only show up visually?

What people usually miss

Watch out

• Passing a visual review tells you almost nothing about the audio experience. A component can look perfect and still announce as "clickable, clickable, clickable" with no distinguishing names — you only catch this by listening.
• "I tested it in VoiceOver" is not the same claim as "I tested it." Real behavioral differences between screen readers mean a serious accessibility practice tests in more than one when the stakes justify it, especially for enterprise-facing products where JAWS usage is still common.
• Full screen-reader fluency takes real, sustained practice — power users navigate far faster than a first-time tester ever will. That's not a reason to skip testing; even a basic "can I get through this flow start to finish" pass, done slowly and clumsily, catches a large fraction of the most serious real bugs.
• Silence is itself a bug signal. If you expect an announcement at some step and hear nothing, that's not you missing something — that's very often a missing aria-live region, a missing accessible name, or a state change that never reached assistive technology at all.

Why this matters in interviews

"How do you verify a component is actually accessible, not just markup-correct?" is a real question, and naming a concrete screen-reader workflow — not just "I run axe" — is what separates a candidate who has actually done this from one who's only read about it.