The case for W3C standards in your component contracts

Accessibility as an afterthought

The pattern is familiar: a component is designed, built, shipped, and then — at some point — someone runs an accessibility audit. The audit finds violations. Tickets are created. The component is fixed. Then the cycle repeats with the next component, or the next release.

This is expensive. Retrofitting accessibility into a shipped component is significantly harder than building it in from the start. And it creates a perverse incentive: teams learn to treat accessibility as something that happens after the work, not during it.

What changes when standards are in the contract

Consider a Button component. In most component contracts or specifications, the accessibility requirements might be a comment or annotation: 'Ensure this is accessible.' That is not a specification. That is a reminder to do the right thing — with no definition of what the right thing is.

A component contract with W3C standards built in looks different. The Button contract specifies: WCAG 2.2 Level AA compliance required. Minimum contrast ratio 4.5:1 for default text, 3:1 for large text. WAI-ARIA role: button. Required keyboard interactions: Enter and Space to activate. Focus visible at all times. Minimum touch target 44×44 pixels.

These are not guidelines. They are requirements — defined in the contract, checkable automatically, and therefore non-negotiable.

A concrete example

Here is what a standards-aware contract for a Link component might look like:

• WCAG 2.2 Success Criterion 1.4.3: Colour contrast ratio ≥ 4.5:1 for normal text
• WCAG 2.2 Success Criterion 2.1.1: All functionality available via keyboard
• WCAG 2.2 Success Criterion 2.4.7: Focus visible — link must have visible focus indicator
• WAI-ARIA 1.2: role='link' implicit in <a> elements; do not add explicitly
• WCAG 2.2 Success Criterion 2.4.4: Link purpose clear from link text alone

These requirements travel with the contract through the entire lifecycle. The Figma plugin checks them at design time. The VS Code extension surfaces them at development time. The browser extension validates the live DOM against them in production.

The difference in practice

When accessibility requirements are in the contract, they become a design decision. The designer cannot choose a foreground colour that fails contrast — the contract will flag it. The developer cannot ship a focus state that is invisible — the contract requires one.

Compare this to the alternative: accessibility requirements that live in a separate audit checklist, disconnected from the component specification, validated only after the fact. The same violations appear release after release, because nothing in the workflow prevents them.

Accessibility is not a feature to be added later. It is a constraint to be designed around from the start. The contract is the mechanism that enforces this.

Where WCAG 2.2 changes things

WCAG 2.2 introduced new requirements that have direct implications for component design. Success Criterion 2.4.11 requires that focus indicators have a minimum area and contrast ratio. Success Criterion 2.5.8 sets minimum target sizes for pointer inputs. These are not abstract guidelines — they are specific, measurable requirements.

When these requirements are embedded in your component contracts, your design system becomes WCAG 2.2-aware by default. Not because every designer has memorised the specification, but because the contract enforces it automatically.