Design systems adopt 'accessibility tokens' as a new primitive

Design · 5 min read

A growing number of design systems have started introducing what practitioners are calling 'accessibility tokens' — discrete, versioned variables that encode accessibility decisions (contrast thresholds, motion intensity, focus ring size, text scaling multipliers) alongside visual tokens. Unlike traditional design tokens that focus on color, spacing, and typography, accessibility tokens are intended to be evaluated at runtime and audited as part of CI pipelines.

Early adopters report that accessibility tokens reduce ambiguity between design and engineering teams. When a token named a11y:contrast-strong is attached to a component, both Figma prototypes and production CSS can reference the same semantic rule rather than separate color swatches. That alignment has uncovered dozens of edge cases where components previously fell below contrast expectations when combined with user-selected themes or system settings.

The next step for many orgs is to embed token checks in their release pipelines. Teams are pairing tokens with automated visual tests and accessibility linters so a pull request can fail if a token assignment results in a contrast ratio below the agreed threshold. The practice also simplifies personalization: user preferences (like dyslexia-friendly fonts or reduced motion) can toggle the underlying accessibility token set, keeping the component API stable while changing behavior.

Design leaders caution that tokens aren't a silver bullet — governance, documentation, and cross-functional review remain essential. But by treating accessibility rules as first-class, versioned artifacts in design systems, organizations are turning a historically ad-hoc set of fixes into a repeatable engineering discipline.