Review this setup at a ticketing platform in the mould of Ticketmaster. Every design-system component carries unit tests plus an automated accessibility check and all of them pass. The queue page announces "you are number 12000 in line" through a polite live region updated every two seconds. An external audit fails the checkout flow on focus order and on announcements. What would you change, and what would you leave alone?

What is actually required

Conformance is a property of pages and flows, not of components. A component can satisfy every criterion it is capable of satisfying and still assemble into a page that fails, because several of the criteria are about relationships that only exist once things are put together: focus order, announcement of changes, heading structure, landmark uniqueness. A green component suite is an input metric; the audit tests the output.

What I would leave alone

The component library and its per-component checks. They eliminate the highest-volume defect classes - missing names, contrast, roles, keyboard operability of individual controls - at the lowest price, once, for every product that consumes them. Removing them would multiply the audit findings. They are doing exactly what they are good at and the mistake is expecting them to do more.

The one change that matters

Test the assembled flow, not more components. A small set of keyboard-only and screen-reader-driven journeys through search, queue, seat selection and checkout, run once per release. Five to ten journeys is enough to find this class, because composition defects are not rare and scattered - they cluster at route changes and at asynchronous updates.

Add one assertion in the router rather than in the tests: on every route change, focus moves to the new view's heading. That is a single change covering every page in the application, and its absence is the usual cause of a focus-order audit finding - the keyboard user activates a link, the view swaps, and focus is still sitting where the old page's DOM used to be, so the next Tab starts from the top of a page that no longer exists.

The live region is a design defect, not a test gap

This one deserves naming because it passes every automated check. Assistive technology serialises announcements: each must finish being spoken before the next begins. A polite region updated every two seconds enqueues faster than speech drains it, so the user hears an ever-lengthening backlog of stale positions and cannot hear anything else on the page, including the seat timer. The automated checker sees a correctly marked-up live region and reports success.

The fix is to announce on threshold crossings rather than on every update: position halved, position under 100, under 10, it is your turn. The continuously changing number stays in an ordinary element the user can read on demand. General rule: a live region is for events, and a counter is not an event.

How to argue this in the review

Two numbers. First, the proportion of the standard that automation can decide at all is a minority of the criteria - the rest require a person or a structural review, and a fully green pipeline is silent about them. Second, the audit's finding count is the only measurement of the assembled product anyone has, so it is the metric to move, and the component pass rate is the metric being managed instead.

When not to add the journey suite

A single-page product with one form and no routing does not need a router assertion or a journey suite; the component checks plus one manual keyboard pass cover it. This structure pays for itself when there are many products on one library, which is also exactly when the component pass rate becomes most persuasive and most misleading.