Put the guarantee in the foundation, not the review

Where the guarantee lives

For any property you want a system to have, it lives in one of two places: in the thing, or in the process around the thing.

Accessibility usually lives in the process. Someone builds a component, someone else checks it, and correctness depends on whoever is looking that day knowing what to look for and having time to look.

That works exactly as well as the attention available. Which means it works during the sprint where somebody cares, and degrades after. Every new component is a fresh chance to get focus order wrong, and every reviewer is a single point of failure.

Properties that live in the process decay at the rate attention decays, which over a long enough period is entirely.

Why this category is worse than most

Incorrect keyboard and focus behavior is invisible to the person building it and obvious to the people it excludes.

That asymmetry is the whole problem. In most defect categories, being ninety percent right feels like being ninety percent right. Here it feels like being finished, because the author navigates with a mouse and everything works.

So the review process is being asked to catch a class of error its participants cannot see by using the thing normally. That is a lot to ask of attention.

The split that makes it movable

A headless behavioral library gives you keyboard handling, focus management, and semantics as primitives, with no visual opinion attached. You apply your own design language on top.

The split matters because it lands exactly where the difficulty is. Accessible interaction behavior is expensive and easy to get subtly wrong. Visual language is the part you have opinions about and want control over. Adopting a styled library that advertises accessibility gets you both halves, and then overriding its visual opinions is how you quietly break the behavior you adopted it for.

What you buy: an engineer who has never thought about focus order gets correct focus order, because they had no option to get it wrong.

Same argument as preferring a type system to a test suite. Both catch the error. Only one catches it without someone remembering to look.

What it does not buy

Behavior is not compliance.

Contrast, colour as the sole carrier of meaning, form error messaging, reduced motion, and whether the content makes sense read aloud are all still yours. No library touches them.

The foundation removes a category of error. It does not remove the category of judgment, and a system described as accessible because of its dependency is being oversold.

Review does not go away

The foundation moves the floor. Review is what keeps people from working around the floor.

Both are needed, and they do different jobs: the foundation makes the default correct, review catches the cases where somebody had a reason to leave the default. Reviewing for accessibility alongside API shape, composability, and whether a component belongs in the shared system at all is still the work.

What changes is that review is no longer the only thing standing between the product and a keyboard trap.

The cost

Headless primitives are more verbose to compose than styled components, and the team has to learn the model. It is also a dependency on somebody else's maintenance of behavior that would be expensive to replace.

Worth it when the system is shared, when it will outlive the attention of the people building it now, or when the property is one whose failures are invisible to the people responsible for catching them.