Contrast-Generated Color Tokens

Large Theory

Color systems have two problems: whether scales meet contrast, and whether tokens express use. Tools such as Leonardo can start from contrast ratio, but agents still need to translate output into semantic roles such as text, muted, surface, border, focus, danger, and success.

Small Points

1. Generating light and dark scales from contrast targets reduces late patchwork color fixes.
2. Generated scales are not the final design system; they still need naming, compression, deduplication, and context checks.
3. State color should not rely on hue alone. Add icons, text, borders, pattern, or layout feedback.
4. If a brand color cannot meet text contrast, use it for background, border, or decoration instead of forcing it into body text.

Design Judgment

A token named only by hue, such as blue-500, does not tell components when to use it. A semantic token such as accent-bg, accent-text, or focus-ring travels better across themes.

Implementation Notes

Generate candidate scales first, then create a semantic mapping table for background, body text, muted text, separator, primary action, danger, success, warning, focus, and selected. Each mapping records light value, dark value, minimum contrast target, and disallowed contexts.

Counterexamples/Risks

Exposing all 12 generated blue steps to components, making dark mode by simply inverting brightness, putting small white text on brand orange, and distinguishing data charts only through red and green.

Case Study

Adobe Leonardo describes desired contrast ratio as the basis for color generation and frames its goal as helping designers and engineers start from contrast ratios to meet WCAG minimum contrast standards. The reusable lesson is that contrast belongs inside token production, not only in a pre-launch checklist.

Source Links

Leonardo: https://leonardocolor.io/ Adobe Leonardo GitHub: https://github.com/adobe/leonardo WCAG 2.2: https://www.w3.org/TR/WCAG22/