A public-sector organisation runs 40 services on a shared component library and must meet WCAG 2.2 AA. An automated scan in each service's pipeline reports no violations, and an external audit finds 60 issues, most of them keyboard traps and focus-order problems in shared components. Where should the verification effort be placed?

The deciding property

The defects are in shared components, so the verification belongs where the components are built, not where they are used. Forty services consuming one library means one keyboard trap becomes 40 findings, fixed 40 times, or fixed once. The arithmetic decides this before any argument about method.

The second fact that decides it: automated tooling can only decide a minority of the success criteria in WCAG 2.2, which became a W3C Recommendation in 2023 — published estimates generally sit in the 30-40% range, and rule engines such as axe-core are explicit that they detect a subset. Keyboard traps and focus order are exactly the class that needs a person driving a screen reader and a keyboard, because the criterion is whether a task can be completed, and no static check can decide that. Running a tool that cannot see the defect, in 40 places instead of one, multiplies the cost of the reassurance without changing the outcome.

What the component contract has to contain

For each component: the keyboard interaction model (which keys move focus, what Escape does), the roles and names it emits, its focus-visible behaviour, and the states it announces. Written as tests, not as documentation — unit tests asserting the accessible name and role, and a recorded manual verification per release with the assistive technology and version named. Consuming teams then test what they compose, not what they consume.

What it costs

A component library becomes a gating dependency. An accessible-by-construction date picker takes weeks rather than days, and a team that needs one sooner will build its own, which is the failure mode to watch for. The counter is that composition still breaks things: a correct component can be placed in an incorrect heading order or given a label that makes no sense out of context, so per-service testing does not go to zero, it goes down to what composition can break.

Why the other options fail

• Stricter automated scans in every pipeline. This is the option that feels like progress and moves nothing: the defects found by the audit are in the portion of the standard the tool cannot decide. It also produces the worst secondary effect, a green check that leadership reads as compliance.
• External audit of each service every release. Correct findings, wrong economics. At 40 services on a fortnightly cycle this is roughly a thousand audits a year, with a feedback loop measured in weeks, and it does not stop the same defect being reintroduced.
• Manual screen-reader pass per team per deployment. Spreads a scarce skill across 40 teams who each use it rarely, so quality varies and the practice decays. Concentrating it in the library is how that skill stays sharp.

When this is the wrong answer

If the services do not share components — different stacks, different vendors, acquired products — there is no library to fix, and the honest answer is per-service auditing with a remediation budget. Choose the component contract only when a real majority of the interface is composed from shared parts, because everything this approach saves comes from the sharing. The rule flips at roughly the point where less than half of a typical page is library components: below that, a defect found in the library fails to fix most of the estate anyway.