Perceptually Uniform Color Spaces and Token Systems for Scalable, Accessible UIs

In web interface design, the quality of a color system is often determined by one property: perceptual uniformity. For decades, the models available to designers and developers—RGB, HEX, HSL—were convenient for computers but poorly aligned with human vision. The practical result was palettes that required constant manual correction, shades that behaved inconsistently across hues, and accessibility problems that appeared only after implementation.

The addition of OKLCH (and its parent space Oklab) to CSS changed the situation. These spaces, standardized in CSS Color Module Level 4 and now supported in all major browsers, let teams author color at a level where numerical changes correspond more closely to perceived differences in lightness, chroma, and hue. When combined with modern design token systems, they make scalable, maintainable, and more accessible color systems practical.

Educational diagram illustrating the difference in perceptual uniformity between traditional HSL and OKLCH.

Related Educational Video:
Why everyone is talking about OKLCH (Coding in Public) — Clear introduction to the space and its implications for design systems.

The Legacy of Non-Uniform Models

Early color models in computing were driven by hardware constraints and additive mixing. RGB and HEX are device-oriented and give no reliable indication of how a change in numbers will look to a viewer. HSL gained popularity because its cylindrical coordinates (hue, saturation, lightness) map to familiar language. However, its “lightness” value does not track perceived lightness. A fully saturated yellow at 50 % lightness appears dramatically brighter than a fully saturated blue at the same numerical value. The distortion affects every derived shade and tint.

In design systems this became a recurring source of friction. A primary blue would be defined, then ten shades generated by stepping HSL lightness. The resulting scale would feel uneven—some steps too close, others too abrupt. Contrast calculations became unreliable. Dark mode variants frequently required extensive hand-tuning. Teams spent disproportionate effort compensating for the model rather than focusing on the actual design goals.

Oklab and OKLCH

In 2020 Björn Ottosson published Oklab, a uniform color space developed specifically for digital image processing and interface work. It improves on CIELAB in hue linearity, lightness uniformity across hues, and chroma consistency while remaining computationally efficient. Its cylindrical form, OKLCH, uses coordinates (lightness, chroma, hue) that feel familiar to anyone who has used HSL.

By 2022–2023, OKLCH was incorporated into the CSS Color Module Level 4 specification. Browser support followed quickly. As of 2025–2026, oklch() and oklab() are stable in Chrome, Safari, Firefox, and Edge, with additional features such as relative color syntax and improved gamut mapping also available.

The key practical improvement is that equal steps in the model produce more nearly equal perceptual steps. This makes automatic generation of shades, tints, and semantic variants far more predictable.

Benefits for UI Systems

When color authoring moves to a perceptually uniform space, several long-standing problems become easier to solve:

Shades and tints generated from a base color maintain more consistent visual spacing.

Contrast calculations become more reliable because lightness differences track perception more closely.

Dark mode and high-contrast adaptations can be derived with fewer manual overrides.

Gamut handling improves. Colors can be authored in a wide space and gracefully mapped to the capabilities of the user’s display.

Token systems become simpler. A single base value plus consistent transformation rules can generate entire scales without the ad-hoc adjustments previously required.

These benefits compound in large design systems used across many products and teams.

Implementation Patterns

Modern practice typically involves:

Authoring core brand and functional colors in OKLCH (or OKLab).

Defining semantic tokens (e.g., --color-text-primary, --color-background, --color-feedback-error) that are expressed as OKLCH values or as relative adjustments of base colors.

Using CSS features such as color-mix(), relative color syntax, and light-dark() to handle modes cleanly.

Providing fallbacks or gamut mapping for older browsers or limited displays.

Testing scales for contrast and distinguishability under color vision deficiency and in grayscale.

The shift does not eliminate the need for judgment and testing, but it removes a major source of systematic distortion that previously consumed significant design and engineering effort.

Limitations and Remaining Work

No color space is perfect for every use. OKLCH improves substantially on earlier models for most interface work, but certain specialized tasks (some forms of image processing or extremely high-precision color work) may still benefit from other representations. Browser support is excellent but not universal; graceful degradation strategies remain necessary for some projects.

The larger shift is cultural as much as technical. Teams must learn to think in the new coordinates and to trust the model enough to stop hand-correcting every generated shade. When that transition occurs, the result is color systems that are both more predictable and less labor-intensive to maintain.

Perceptual uniformity is not an academic nicety; it directly affects usability, accessibility, and development velocity.

When lightness is perceptually uniform, a designer can state “make this 15% lighter” with confidence that the result will appear consistently lighter across hues. Token systems can define semantic scales—--color-primary-50 through --color-primary-950—using fixed increments in the L channel. The resulting palette maintains visual rhythm whether the primary hue is a warm orange or a cool teal.

Chroma uniformity matters for vibrancy. In older models, increasing saturation could push some hues outside the displayable gamut while leaving others undersaturated. OKLCH’s chroma axis respects the actual capabilities of the color space, making it easier to produce vivid yet harmonious palettes and to fall back gracefully to sRGB when necessary.

For accessibility, the stakes are higher. WCAG contrast ratios are calculated in the sRGB space, but human contrast perception is closer to the models underlying OKLCH. When palette generation respects perceptual lightness, the lightest text on the darkest background is more likely to meet contrast targets without exhaustive manual testing. Color vision deficiency simulations also behave more predictably.

Psychologically, consistent color scales reduce cognitive load for both creators and users. Interfaces feel more “right” when elevation, emphasis, and state changes follow even visual steps. This is especially valuable in complex applications—dashboards, design tools, enterprise software—where dozens of interacting colors must coexist without visual noise.

Culturally, the shift represents a maturation of the web as a medium. Early web color was constrained by 8-bit displays and limited standards. Modern interfaces target high-dynamic-range, wide-gamut displays. OKLCH provides a single authoring model that can express both legacy sRGB content and the richer colors now available, while giving developers tools that match how they already think about design.

Token Systems and the Practical Architecture of Modern Color

Design tokens have become the connective tissue between design and engineering. A color token might be defined once and consumed across Figma, CSS, iOS, and Android. The quality of the underlying color space determines how much friction exists in that pipeline.

Traditional HSL-based token systems required extensive hand-authoring or complex scripts to generate variants. With OKLCH, a base color can be expressed as a single oklch() value. Light and dark variants are then derived by arithmetic on the L channel while holding C and H relatively constant (with careful handling near the achromatic axis). The same tokens can drive both sRGB fallbacks for older contexts and native wide-gamut output for modern ones.

Tailwind CSS v4 provides a prominent public example. The framework’s default palette was rebuilt using OKLCH, yielding more vibrant yet harmonious scales and smoother automatic generation of shades. Teams migrating reported that custom brand colors now produce more usable variant sets with less tweaking.

Evil Martians documented a similar migration in detail, moving internal projects from RGB/HSL to OKLCH. They highlighted the ability to define a few base colors and let formulas generate entire systems, improved readability of color values in code, and more reliable accessibility outcomes. Their public color picker and palette tools further demonstrate the ergonomic advantages.

Other adopters include component libraries such as shadcn/ui and design systems at companies like Linear and Stripe. These organizations treat the source-of-truth colors as OKLCH values, exporting HEX or RGB only where legacy constraints demand it.

The emerging Design Tokens specification is also evolving to accommodate modern color models, recognizing OKLCH alongside other formats. This convergence reduces the translation tax that has historically existed between design tools and production code.

Case Study: Building a Scalable Token System with OKLCH

Consider a design system that must support light and dark modes, semantic roles (primary, neutral, success, warning), and multiple accent hues while maintaining WCAG AA contrast.

In an older workflow, a designer might pick a base blue in Figma, then manually create ten tints and shades. The engineer would hard-code the resulting HEX values. Changing the brand color later would require touching dozens of tokens.

With OKLCH:

1. The designer selects a base hue and chroma in an OKLCH-aware picker (or plugin).
2. The system defines the base as --primary: oklch(0.65 0.18 250);.
3. Lightness steps are generated programmatically or via relative color syntax:

   --primary-50: oklch(from var(--primary) calc(l + 0.30) c h);
   --primary-900: oklch(from var(--primary) calc(l - 0.40) c h);

4. Semantic tokens inherit and adjust as needed:

   --color-success: oklch(0.62 0.15 145);

5. Dark mode overrides adjust the L channel globally or per-token while preserving hue and chroma relationships.

The result is a system in which altering the base primary instantly updates every derived variant with predictable visual effect. Contrast can be audited more reliably because lightness steps are even. The same tokens feed documentation, Storybook, and native apps (with conversion layers where necessary).

This approach has been validated in production by teams that previously fought constant visual drift between design files and shipped interfaces.

Challenges, Limitations, and Best Practices

No technology is without trade-offs. OKLCH’s primary limitations today are ecosystem maturity and gamut awareness.

Not every design tool offers first-class OKLCH editing. Figma users often work in Display P3 or rely on community plugins. Conversion to legacy formats remains necessary for some export targets.

Certain combinations of high chroma and extreme lightness or darkness fall outside the gamut of typical displays. Browsers perform gamut mapping, but results can vary. Responsible implementations include @supports checks or explicit sRGB fallbacks for critical UI elements.

Best practices emerging from early adopters include:

• Author in OKLCH; export to HEX only for compatibility layers.
• Prefer relative color syntax (oklch(from ... )) over manual calculation when possible.
• Test contrast both mathematically and perceptually; do not assume uniformity solves every accessibility problem.
• Document the source model clearly so future maintainers understand why certain values appear “off” in older tools.
• Use tools such as Huetone or dedicated OKLCH pickers for palette exploration.

For teams still supporting very old browsers, progressive enhancement via feature queries keeps the system maintainable without sacrificing modernity.

Current Trends and the Future Outlook

By mid-2026, OKLCH has moved from experimental to recommended practice for new web projects. Tailwind’s adoption accelerated visibility. Component libraries and design system documentation increasingly default to it or present it as the forward-looking choice.

CSS Color Level 5 continues to expand capabilities with color-mix(), relative colors, and improved gamut mapping. These features amplify the value of perceptually uniform authoring spaces.

Looking ahead, wider native support in design tools, game engines, and mobile frameworks will reduce friction further. High-dynamic-range and ultra-wide-gamut displays will make the ability to author beyond sRGB increasingly relevant. Machine-learning-assisted palette generation will likely operate natively in OKLCH because the space’s properties make interpolation and optimization more reliable.

The cultural shift is equally important. A generation of designers and developers is learning color through models that match human perception rather than hardware constraints. This will raise baseline expectations for visual quality and accessibility across digital products.

Actionable Insights and Reflection

For teams beginning the transition:

• Audit your current palette for visible lightness inconsistencies by converting samples to OKLCH and inspecting the L values.
• Choose a small pilot component or new feature and rebuild its color tokens using OKLCH.
• Pair the change with updated documentation that explains the model to both designers and engineers.
• Measure before-and-after: time spent tweaking shades, number of contrast issues filed, and subjective “polish” feedback.

Reflection questions:

• Where in your current interfaces do color relationships feel “off” despite mathematically even steps?
• How much of your design system maintenance is spent correcting for the shortcomings of HSL or RGB?
• What would it mean for your accessibility process if lightness adjustments produced more predictable results?
• How might expressing color intent (rather than device values) change collaboration between design and development?

The shift to perceptually uniform spaces is not merely a technical upgrade. It is an invitation to treat color as a first-class, human-centered material in interface design—one that rewards precision with consistency, accessibility, and expressive power.