Your Color Tokens Pass the Contrast Check and Still Fail 300 Million Users

Your design system has a token called color-semantic-error. It is #D32F2F. You check it against the white background it sits on: contrast ratio 5.1:1. You check the companion color-semantic-success: #388E3C on white, 4.7:1. Both pass WCAG AA. Your CI pipeline is green.

For roughly 8% of the men using your product — around 300 million people globally with red-green color vision deficiency — those two tokens are almost identical.

The audit tool never lied to you. It measured exactly what it said it would measure. The problem is you asked it one question and assumed it answered three.

What WCAG 2.x Actually Measures (and What It Doesn't)

WCAG 2.x contrast is a ratio of relative luminance values: how much light a color reflects, computed from a linearized sRGB formula. A 4.5:1 ratio for normal text, 3:1 for large text. That is the whole model.

Luminance is one axis of color perception. It tells you whether text is readable against its background for users with standard vision, in standard conditions, at a single adaptation state. It does not tell you:

• Whether two colors are distinguishable from each other by someone with deuteranopia or protanopia
• Whether a saturated red on a near-black background causes halation — the blurring and glow effect that affects users with astigmatism (estimated at 33% of the population, per the American Academy of Ophthalmology)
• Whether the contrast that passes in light mode still holds perceptually in dark mode, where eye adaptation state changes how much contrast users actually experience

Andrew Somers, the researcher who created the Accessible Perceptual Contrast Algorithm (APCA) at Myndex Research, found during WCAG 3.0 development that 47% of color pairs deemed acceptable under WCAG 2.x were actually unreadable in real reading conditions. The formula was not wrong; it was incomplete. It was measuring luminance difference in isolation, ignoring the spatial frequency of the text, the adaptation state of the viewer, and the font weight — all of which shift perceived contrast significantly.

APCA outputs an Lc value (Lightness contrast, ranging roughly from −108 to +108) that maps to perceived readability rather than a raw photometric ratio. For body copy at 16px regular, you want Lc 60–75. For microcopy at 12px, Lc 75–90. For a large heading at 24px bold, Lc 45–60 is defensible. Those numbers mean something different for dark-on-light versus light-on-dark — APCA is not symmetric, because perception is not symmetric.

WCAG 3.0 is not finalized. WCAG 2.2 remains the enforcement standard. But APCA is available now, tools support it, and its model surfaces failures that the old formula structurally cannot see.

The Semantic Token Trap

Design token systems are architecturally sound. The practice of naming tokens by intent (error, success, warning, primary, surface-accent) rather than by value (red-600, green-700) is correct and important — it decouples design decisions from implementation details and makes system-wide changes coherent. The problems in token implementation are usually structural: teams generate flat primitive lists and skip the semantic layer.

But the semantic layer creates its own trap when it comes to color accessibility.

When you name a token color-semantic-error, you are encoding a meaning. Error. Something went wrong. Stop. Change input. The name implies that the color alone carries that signal — that the hue is the meaning. And for users with deuteranopia or protanopia, the red-green hue channel is precisely what is not available.

The WebAIM Million 2026 audit scanned one million home pages and found low-contrast text on 83.9% of them — up from 79.1% in 2025. Each page averaged 34 distinct contrast failures. That is the luminance problem alone. The color blindness problem sits in a different layer, invisible to the same audit.

Here is what that looks like concretely. A form validation state: success badge in #388E3C, error badge in #D32F2F. Both pass 4.5:1 on white. A deuteranope sees two badges that are roughly the same brownish neutral. Without an icon, without a label beyond color, without a textual indicator — the semantic token did its job in the token system and failed the user entirely.

WCAG 1.4.1 ("Use of Color") explicitly requires that color is not the only visual means of conveying information. It has been in the spec since WCAG 2.0, published in 2008. Eighteen years later, it remains one of the most commonly violated criteria — because token systems make it easy to assign meaning to a hue and never revisit whether that hue is the only carrier of that meaning.

The Dark Mode Adaptation Blind Spot

There is a third failure mode that sits between the luminance problem and the hue problem: mode-switching and adaptation state.

When you test a color pair in light mode and it passes, you are testing against one adaptation state. Users who switch to dark mode are in a different adaptation state — their pupils are wider, their visual system has adjusted, and colors that appeared fine in light mode can produce different perceptual contrast in dark mode.

This is especially sharp for halation. Bright saturated text on a near-black background creates a glow effect where the color appears to bleed into surrounding pixels. This is not a rendering artifact. It is a physiological response in eyes with astigmatism. Dark mode has its own specific failures that the standard contrast ratio does not capture, and your semantic tokens live in both modes.

The European Accessibility Act enforcement deadline passed on June 28, 2025. Since that date, EU member states have been actively enforcing accessibility requirements against digital products and services in scope. Penalties reach up to three million euros. The technical standard being enforced is EN 301 549, which maps to WCAG 2.1 AA — including 1.4.1 on use of color. Enforcement intensity is increasing through 2026 as national monitoring authorities scale their auditing programs.

The EAA does not make WCAG smarter. It makes the existing gaps expensive.

An Audit Framework for Semantic Token Sets

Running the standard contrast check on your token library is the start. It is not the audit.

Step 1: Luminance baseline. Run every semantic token pair through a WCAG 2.x contrast checker for your known text/background combinations. Fix failures. This is the prerequisite, not the goal.

Step 2: APCA calibration. Run the same pairs through an APCA contrast checker. Flag any token pairs where the Lc value falls outside the appropriate range for the intended use case — body, micro, heading, interactive. Pay special attention to pairs that pass WCAG 2.x but score low on APCA, which Somers found was true for 47% of passing pairs.

Step 3: Hue channel audit. For every semantic token pair that encodes distinct meaning (error/success, active/inactive, selected/unselected), simulate deuteranopia and protanopia. Tools like Figma's built-in accessibility simulators, Stark, or browser-based simulators make this one-click. The question is not whether the colors look similar to you; it is whether they are distinguishable without relying on hue.

Step 4: Non-color redundancy check. For every case where a semantic color token carries meaning, document the redundant non-color signal: icon, label, pattern, shape, position. If a token pair fails the hue audit and the only differentiator is hue, you have a real failure regardless of contrast ratios.

Step 5: Mode-pair testing. Run steps 1–4 in both light and dark mode separately. Token values often differ between modes. Failures in one mode do not imply failures in the other.

The aufaitux.com 2026 research on accessible color tokens for enterprise design systems found that most teams audit at the primitive layer — the raw hex values — rather than the semantic layer where meaning is encoded. The semantic token audit is the one that catches the actual user impact.

So Actually, the Problem Is in the Question

The design token system asked: does this color have enough luminance contrast against its background? The answer was yes.

The question it did not ask: is this the only visual channel carrying this meaning, and is that channel available to everyone?

WCAG compliance and accessibility are not the same thing. The audit measures what it can measure. The standard encodes what was agreed on in 2008, updated cautiously in 2018 and 2023. The people your system misses — the 300 million with color vision deficiency, the third of your users with astigmatism who experience halation, the users switching adaptation states between modes — none of them are in the pass/fail column of your contrast checker.

The token system gave the failure a good name. color-semantic-error. Semantic. Meaningful. Invisible.

If your token library has a documented redundancy plan for every semantic color pair — the icon that backs up the hue, the label that backs up the badge — you have done the work. If it doesn't, your audit is a floor, not a ceiling.

Which tokens in your system right now carry meaning that only the color can see?