Automated accessibility scanners are essential — but they have hard structural limits, and screen-reader users live inside those limits every day. A WordPress site can pass axe, WAVE, and Lighthouse cleanly and still be miserable to navigate with NVDA, JAWS, VoiceOver, or ChromeVox. Real screen-reader testing isn't a redundancy on top of scanners; it's the second half of the same job. Here's why it matters, where the regulatory and business pressure is coming from, and what the testing landscape actually looks like.
Run any WordPress site that’s passed automated accessibility tests through a real screen reader for ten minutes. Within that window you’ll almost always find at least one issue that no scanner could have flagged: an announcement that’s confusing, a navigation order that doesn’t make sense, a control that’s labeled differently than what it visually appears to be. The bug exists. The scanner can’t see it. The screen-reader user does.
This is the gap that real screen-reader testing closes. It’s not a duplicate of automation; it’s the layer that catches the categories of bug automation fundamentally can’t. What automated WCAG scans catch — and the categories they fundamentally can’t breaks down those limits in detail. This piece is about the case for the layer that fills them.
Scanners check syntax. Screen readers check experience.
An automated scanner reads the rendered HTML and answers questions a static analyzer can answer. Does this image have an alt attribute. Is the contrast ratio above 4.5:1. Are the form labels properly associated. These are real questions and real bugs and they really get caught. They are also, by definition, structural questions — checks on whether the page conforms to a spec.
The questions a screen-reader user actually asks while using a site are different. Did I understand what just happened. Where am I in this page. What does this button do. Did the form actually submit. Was that error message announced or did it appear silently. These aren’t conformance questions. They’re experience questions, and they only get answered by listening to the page with the tool the user uses.
The two layers do different work. Scanners are necessary; they are not sufficient. The category of bug that breaks the experience is exactly the category scanners cannot detect.
The user base is larger than most teams assume.
The global population of people who use screen readers regularly is in the millions. The broader population of people who benefit from accessible markup — including people with low vision who use system zoom or browser reader mode, people with motor disabilities who navigate by keyboard, people with cognitive disabilities who depend on clear structure, and people in temporary or situational disability contexts (a broken arm, a noisy environment, a glare-bright screen) — is much larger again. The WHO estimates around 16% of the world’s population lives with some form of disability.
Those users are part of any non-trivial site’s audience. They’re hitting marketing pages, signing up for services, buying products, reading documentation, applying for jobs. When the site doesn’t work for them, they usually leave — and most of the time, no one ever knows. They don’t file bug reports. They don’t email support. They just go somewhere else.
The business case is straightforward.
The economic argument for screen-reader testing is the same argument as for any other usability work: people who can’t accomplish the task leave, and acquired traffic that leaves is wasted acquisition spend. On a content site, screen-reader failures show up as bounces. On an ecommerce site, as abandoned carts. On a lead-gen site, as form-submit drop-off the analytics chart up at the “form started” step.
The work also has positive spillover. Markup that’s structured well for screen readers tends to be structured well for search engines — semantic headings, proper landmarks, descriptive link text are all things both audiences benefit from. Pages that work with keyboard navigation tend to work well in mobile reader modes and in the increasingly common assistive features baked into operating systems. Improving the accessibility experience improves the site’s overall structural quality, not as a side effect but because the underlying discipline is the same discipline.
The legal exposure is increasing, not decreasing.
The regulatory environment around web accessibility has tightened in every major market over the past five years:
- ADA Title III — the U.S. accessibility law that courts have consistently interpreted as covering websites. ADA-based web accessibility lawsuits have been in the thousands per year for the last several years, with a meaningful share resulting in settlements.
- The European Accessibility Act (EAA) — came into force in June 2025, requiring private-sector websites in scope (ecommerce, banking, transport, more) to meet specific accessibility requirements.
- Section 508 — the federal accessibility requirement in the U.S. Applies to federal agencies and any vendor whose products are used by federal agencies.
- State-level laws in the U.S. and equivalents in other countries continue to expand the surface.
The defensible compliance posture under all of these isn’t “we ran a scanner.” It’s evidence of a serious testing practice that includes real assistive technology use: the scanner run, the screen-reader test results, the remediation log, the periodic re-test cadence. The auditable record matters as much as the work itself.
The team-discipline case.
Something often missing from the “why bother” conversation: a developer who has heard their own site read aloud by a screen reader writes different markup from one who hasn’t. The instinct to reach for a <div> when a <button> would do, the temptation to skip the aria-label on the icon-only control, the habit of dropping a decorative SVG in without thinking about how it announces — all of these get harder to do once you’ve sat with the consequences. The cost of doing real screen-reader testing is partially repaid in the markup quality of everything that comes after.
The testing landscape.
A few categories of tool, each with a place in a serious practice.
Software screen readers — the major options for self-testing during development:
- NVDA — free, Windows. A significant share of real users.
- JAWS — paid, Windows. The most-used screen reader in workplace and government settings; higher learning curve but high real-user relevance.
- VoiceOver — built into macOS and iOS. The standard on Apple platforms and the dominant screen reader on mobile.
- ChromeVox — built into ChromeOS. The standard on Chromebooks, particularly in education contexts.
The major screen readers differ in small ways — how they announce certain ARIA patterns, how they handle dynamic content, how they treat some edge cases — but they share an underlying view of the page (the accessibility tree the browser exposes), so a site that works well in one usually works in the others. Testing in at least one is meaningful coverage. Testing in two or three on critical templates is a stronger position.
Cloud testing services — for accessing screen readers without the local operating system. Services like AssistivLabs, BrowserStack, and Sauce Labs provide browser-based access to real screen readers running in real cloud environments. Useful for a Mac-only team that wants to spot-check NVDA, or a Windows-only team that wants to spot-check VoiceOver. Lower friction than maintaining a parallel OS install; sufficient for periodic cross-checks.
Real user testing services — the gold standard. Services like Fable, AccessWorks, and others connect the team with actual disabled users — blind, low-vision, motor-impaired, cognitively disabled — who test the site using their own assistive technology setups and their own workflows. This is the closest the testing process gets to “did this actually work for the people it’s meant to serve.” The cost is higher than self-testing; the signal quality is also higher. The right call for a redesign, a major launch, a regulated industry, or any site where accessibility is mission-critical rather than “ought to.”
How often.
A reasonable cadence: at minimum, on every significant template change and every new interactive component, with a quarterly check on the top-traffic pages. More often is fine; less often means the bugs that ship sit in production for months before anyone notices. For sites in regulated contexts, build the cadence into the release process so the auditable record exists.
Automated scans plus real screen-reader testing on a regular cadence catches both the bugs scanners are good at and the bugs only real assistive technology use surfaces. Neither alone is enough. See accessibility that holds up for what this looks like as part of a broader practice.