WCAG is, by design, a conformance standard, not a usability standard. Every one of its success criteria is written to be objectively testable: does an image have alt text, yes or no; does interactive text meet a 4.5:1 contrast ratio, yes or no; can a function be operated by keyboard, yes or no. That binary testability is exactly what makes WCAG useful as a legal and procurement benchmark. It is also exactly why passing every single criterion does not guarantee, on its own, that a real disabled person can actually use the site without frustration.
This is not a criticism of WCAG. The standard was never designed to measure the harder, more subjective question of whether an experience is genuinely pleasant or efficient to use, and W3C's own documentation is explicit that conformance is a floor, not a guarantee of usability. But the gap between "technically conformant" and "actually usable" is where a meaningful number of real accessibility complaints originate, from users interacting with sites their own development teams can, correctly, point to a clean audit report for.
The Distinction, From the Source: W3C's own guidance on accessibility, usability, and inclusion states directly that meeting WCAG success criteria "will not automatically make websites usable, particularly for people with cognitive disabilities or learning disabilities," describing conformance as necessary but not sufficient for a genuinely accessible experience.
Where This Gap Shows Up Most Often
The clearest recurring example is a multi-step process, a checkout, an onboarding wizard, a benefits enrollment flow, where every individual screen conforms perfectly. Every field is labeled, every button has an accessible name, every image has alt text, every color pair passes contrast. Taken screen by screen, an automated scan and a manual criterion-by-criterion review both come back clean. What that screen-by-screen review does not measure is whether the overall sequence, the order information is requested in, the number of steps required, the way errors compound across steps, or the cognitive load of the whole flow taken together, is actually reasonable for someone navigating it non-visually or with a cognitive disability, taking substantially longer per screen than a sighted mouse user would.
Another common shape is a page with technically correct heading structure and landmark regions, exactly what WCAG requires for navigation, that is nonetheless organized in a way that makes no logical sense to someone building a mental model of the page by listening to it linearly rather than scanning it visually. WCAG requires headings to be structured correctly. It does not, and structurally cannot, require that the information architecture behind those headings makes intuitive sense, because that is a design and content judgment, not a binary technical check.
Why Automated and Even Manual Criterion Testing Both Miss This
An automated scanner checks individual elements against individual rules and, by its nature, cannot evaluate a flow holistically. A manual audit that goes criterion by criterion, while far more thorough, has a similar structural limitation if it is organized the same way: checking each success criterion in isolation rather than actually attempting to complete the site's core tasks the way a real user would, start to finish, with a screen reader or keyboard only, and noticing where the experience becomes exhausting or confusing even when no individual criterion is technically violated. This is the same distinction covered in our piece on why a perfect Lighthouse score still fails real users, applied here specifically to manual audits and not just automated tools, because the gap exists in both testing methods when they are organized around individual rules rather than end-to-end task completion.
What Closes the Gap
The fix is not a different or stricter standard than WCAG. It is a different testing method layered on top of standard conformance testing: task-based usability testing with actual assistive technology users attempting real, representative goals on the site, not isolated criterion checks. A team that has only ever tested "does this page pass WCAG" has tested something real and necessary, but has not tested "can someone actually get their taxes filed, their order placed, their claim submitted" using the site the way an actual user would attempt it, start to finish, without a tester who already knows exactly where every button is.
This is also why WCAG's own conformance documentation explicitly frames AA conformance as a floor rather than a finish line, a point covered in more depth in our companion piece on why WCAG AA is the legal minimum, not the finish line. A site that treats a clean audit as the end of the accessibility work, rather than a necessary baseline that still needs real-user validation, is exactly the site most likely to discover this gap the hard way, through a support complaint or a review, rather than proactively.
If your organization has completed a WCAG audit and passed, that is genuinely valuable and worth doing. The next useful step is testing your site's actual core tasks, not just its individual elements, with real assistive technology and real users where possible. Our team runs both kinds of testing. Reach us at experts@wcag.world, or review W3C's own guidance on accessibility, usability, and inclusion and the WCAG 2.2 conformance requirements directly for how the standard itself frames this distinction.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: wcag level a aa aaa explained.
For the next review, use these related resources: request the relevant WCAG review.
A short written test plan also makes handoffs safer. Name the user goal, the starting focus, the success announcement, and the exact fallback when the preferred path is unavailable. Review that plan with someone who uses the interface differently from its author, then record the result alongside the release notes. This is a small habit, but it catches regressions that a green automated result cannot describe.