What does a WCAG conformance claim require beyond passing checks on a single screen?

## Conformance is a property of pages, not of parts The single most useful sentence here: **WCAG conformance attaches to a page, and to a whole page.** The standard's defined sense of a page includes a single-screen application, which is what makes this readable on a phone screen or a kiosk as much as in a document. That one rule kills a very common organisational claim. An 83-component shared library cannot be 'certified at AA'. Components can be built so that conforming screens are easy to assemble, and that is worth doing, but the claim belongs to the assembled screen, where content, ordering, configuration and the surrounding page finally exist. ## The five conformance requirements 1. **Conformance level.** Every criterion at the claimed level, and all levels below it, is satisfied — or a conforming alternate version is reachable that does satisfy them. 2. **Full pages.** The claim covers entire pages. You cannot exclude the region that fails and claim the remainder. 3. **Complete processes.** Where a page is a step in a series that accomplishes an activity, every page in the series must conform at the claimed level or higher, otherwise the process does not conform. 4. **Only accessibility-supported ways of using technologies are relied upon.** Anything you rely on to satisfy a criterion must actually work with the assistive technologies and user agents your users have. 5. **Non-interference.** Content that is not relied upon must not block access to the rest of the page. Specifically, the page as a whole must still satisfy 1.4.2 Audio Control, 2.1.2 No Keyboard Trap, 2.2.2 Pause, Stop, Hide and 2.3.1 Three Flashes or Below Threshold, even for the parts outside the claim. Requirement five is the one people find counter-intuitive. A decorative animation you never claimed anything about can still sink the page, because a user who cannot stop it cannot use anything behind it. ## A worked example A national library catalogue runs a public search app on phones, kiosks in branches and a desk client for staff — 212 screens in all, assembled from an 83-component shared library. The reservation path has four steps: search, choose a copy, place the hold, choose a pickup branch. An audit finds three failing criteria, all concentrated in step three. What follows: - **The reservation process does not conform** at the claimed level, even though 209 of the 212 screens pass. There is no partial credit for a process. - **Fixing the shared component behind step three fixes the process**, but the claim is still written about the screens, not about the component. The evidence you keep must be per screen and per process. - **A kiosk screen and a phone screen are separate pages** in the standard's sense, so verifying one does not verify the other even when they share every component. - **If step three relies on a mechanism assistive technology does not genuinely support**, the process fails on requirement four even if no criterion is technically violated in the markup. ## Accessibility support is the requirement teams forget 'Accessibility supported' means the way you use a technology actually works in practice with what users have, not that a specification says it should. The standard deliberately publishes no list of what is supported, which pushes the judgement — and the evidence for it — onto whoever makes the claim. The practical rule is simple: if you rely on a mechanism whose support you cannot demonstrate, either stop relying on it or provide a route to the same outcome that does not depend on it. ## What teams get wrong - **'The design system is AA, so the product is AA.'** It is not, and it cannot be. Ask which screens and which processes were verified. - **'That region is out of scope.'** The full-pages requirement forecloses this. The available moves are to fix it, to offer a conforming alternate version that provides the same function, or — where the content genuinely is not yours — to publish a statement of partial conformance identifying it. - **'Only three screens fail, so we are at 98 per cent.'** Percentages are a project-management view, not a conformance view. A claim is true or false over the scope it names. - **'The failing step is optional.'** If a user can arrive there, it is part of the process for that user. The scoping lesson that falls out of all this is to **audit processes end to end rather than sampling screens at random**. Checkout, registration, booking and search-to-outcome flows carry the conformance risk, because a single weak step defeats every other screen in the chain.