Design Tokens 2.0: Introducing Semantic, Conditional, and Disability-First Tokens

Design · 6 min read

The next wave of token design emphasizes semantics: tokens named for intent (e.g., focus-ring, emphasis-text) rather than raw values. More importantly, token files are beginning to include conditions — small rule sets that adjust values based on user preferences, environment, or device capabilities. For example, motion-duration.base becomes motion-duration.base@prefers-reduced-motion, and typography.scale.small@dyslexia-friendly maps to a different font-family and spacing.

This approach allows design systems to ship disability-first defaults. Teams can opt into tokens that change not only values but structure — increasing line height, adjusting timing curves, or swapping to more readable fonts for specific audiences. Tokens can be consumed by CSS custom properties, JSON token systems, or runtime token engines that observe system preferences and apply the right variant.

Challenges remain: tooling must support conditional resolution and provide clear debugging output so designers and engineers know which token variant is active. There are also governance questions — who decides the default disability-first variants, and how to test them at scale. Early adopters urge involving accessibility practitioners and representative users in token creation to avoid assumptions about diverse needs.