A Real Screen Reader Pass, Not Just an Automated One

Automated accessibility scanning is genuinely valuable and genuinely limited in a specific way: it can tell you an image is missing alt text, but it can't tell you the alt text you did write doesn't make sense in context, or that a form's error message never gets announced when it appears, or that the reading order jumps around in a way that's technically valid HTML but practically confusing. Those require actually listening to a page the way a screen reader user experiences it — which is a genuinely different activity from reading it visually.

You don't need to be an expert user to learn something real

Turning on a screen reader for the first time — VoiceOver on Mac (Cmd+F5), Narrator on Windows (Win+Ctrl+Enter), or a browser extension like a screen reader simulator — and navigating your own site for ten minutes will surface real, specific problems almost every time, even without deep fluency in how expert users actually navigate (which relies heavily on jumping by heading, landmark, and form control rather than reading linearly, a skill that takes longer to build).

What tends to surface immediately

Reading order that doesn't match visual order. A page that looks correctly laid out visually can have a completely different order in the underlying HTML — content positioned with CSS to appear in one place while existing earlier or later in the actual document. A screen reader reads the document order, not the visual position, so this mismatch is invisible until you listen to it — and it's much less likely when the page is built from semantic elements in a sensible order.

Interactive elements with no accessible name. A screen reader announces a button's or link's "accessible name" — usually its visible text, but sometimes nothing at all if it's an icon-only button with no aria-label. Hearing "button" with no other information, repeated for every icon-only action on a toolbar, makes the immediate problem obvious in a way that reading the HTML source doesn't — though the fix is a real label, not more ARIA than you need.

Dynamic content that changes silently. A form validation error that appears visually but was never wrapped in anything that announces itself (an aria-live region, or focus moved to the error) is invisible to a screen reader user — the page changed, but nothing told them so. This is one of the most common real-world accessibility failures and one automated scanning genuinely cannot catch, since detecting "did this get announced" requires observing behavior, not just static markup.

Treat it as a habit, not a one-time audit

A single pass won't catch everything, and that's fine — the value is in making it a recurring five-or-ten-minute check on new features before they ship, not a comprehensive annual audit. It pairs with a keyboard-only pass, which catches an overlapping but different set of problems. Automated scanning stays useful for catching the mechanical, always-present issues at scale; a real screen reader pass is what catches the things that only show up in actual use.