Accessibility belongs at the token layer

The standard accessibility workflow is retrospective. Build the components, run the audit, log the contrast failures, fix them, run it again. It works, in the sense that the failures do eventually get fixed. It is also structurally guaranteed to keep producing them.

The reason is simple. If the palette contains a text colour and a surface colour that fail together, then that pairing is available. It will be used — not through carelessness, but because the two values look reasonable side by side in a design tool, and nothing in the system says otherwise until an audit six weeks later.

Move the gate upstream

The alternative is to make the accessible pairing the only one the system can express. Concretely: semantic tokens are issued in pairs, and a pair is not issued until it passes WCAG 2.2 AA at the sizes it is intended for.

• text.default on surface.default — checked at issue.
• text.muted on surface.raised — checked at issue.
• A component that wants a combination the semantics do not offer has found either a gap in the system or a bug in its own design. Both are worth a conversation.

Why OKLCH helps

Authoring ramps in OKLCH rather than hex or HSL means the lightness axis is perceptual. Steps that are numerically even are also visually even, so contrast behaves predictably as you move along a ramp instead of collapsing unexpectedly in the mid-tones. It does not make contrast automatic — it makes it tractable.

What is left for the audit

Plenty, and better things. Focus order. Keyboard traps. Form labelling and error association. Content structure. Screen-reader announcement of dynamic changes. Target sizes. The audit stops spending its budget on a hundred instances of one palette decision and starts spending it on the problems that genuinely require a human to sit with the product.

A contrast failure found in a system with a token-layer gate is a bug in the pipeline. That is one bug, not a hundred.