Screen reader testing without pretending to be an expert

Screen reader testing is where most QA accessibility efforts stop before they start, because of a reasonable fear: "I'm not a screen reader user, I'll do it wrong." That fear keeps a whole class of obvious bugs untested. The honest position is this: you won't test like a daily screen-reader user, and you shouldn't pretend to — real assistive-tech users should be involved for serious validation. But you can catch the blatant failures, and catching the blatant ones is a huge improvement over catching none. This goes a level deeper than the keyboard pass and the accessibility smoke test.

You already have one installed

No purchase, no setup: VoiceOver on macOS/iOS (Cmd+F5), Narrator on Windows (Ctrl+Win+Enter), TalkBack on Android, or the free NVDA on Windows. Pick the one on the platform you're testing. Learn three commands and you can start: turn it on, move to the next element, and activate. That's enough for a first pass.

Test with your eyes closed (briefly)

The point of a screen reader is that the user can't see the screen. So for a short burst, don't look — or look away — and navigate by what's announced. If you can't tell where you are, what a control does, or whether an action succeeded, neither can a blind user. This is uncomfortable and exactly why it's effective: it surfaces the gap between what's on screen and what's actually communicated.

The four things to listen for

You don't need deep expertise to judge these:

1. Does every element announce something meaningful? Tab/swipe through. A button should say its name and that it's a button ("Submit, button"). The failure: silence, or "button" with no name — an icon-only control with no accessible label is invisible.
2. Do images and icons make sense? Meaningful images should be described; decorative ones should be silent (not "image, image, image"). A logo announced as "image 4f3b9c.png" is a bug.
3. Are form fields labelled? Move to each input — is it announced with its label and its state ("Email, edit text, required")? An input that announces only "edit text" leaves the user guessing what to type.
4. Are changes announced? Submit a form with an error, open a dialog, trigger a loading state. Does the screen reader say anything, or does the change happen silently? Errors and dynamic updates that aren't announced are a top real-world failure — a sighted user sees the red text; a blind user gets nothing.

What you're NOT doing

Be clear about the limits so you don't over-claim:

• You're not judging the fluency of the experience or fine ARIA semantics — that needs a real user.
• You're not certifying WCAG conformance.
• You're catching the obvious, blatant breakages: unlabelled controls, silent errors, meaningless announcements, traps.

"I ran a basic VoiceOver pass and the error messages aren't announced and the menu button has no name" is a genuinely useful finding — file it.

Where this fits

This is the next step after the keyboard pass, within the broader accessibility smoke test. For what automation catches and misses, the accessibility checklist and glossary (accessible name, ARIA, live regions) fill in the vocabulary.

Basic screen-reader pass

• Turn on the built-in reader for the platform (VoiceOver / Narrator / TalkBack / NVDA)
• Navigate a burst without looking — can you tell where you are and what's there?
• Every interactive element announces a meaningful name AND its role
• Images/icons are described if meaningful, silent if decorative (no filename noise)
• Form fields announce their label, state, and required-ness
• Errors, dialogs, and loading changes are announced, not silent
• File the blatant breakages; flag serious validation for a real AT user