Hot Pink Passes WCAG. That's the Problem.

Updated 2026-06-09.^[1]

The Gap

#ff69b4 on #1a1a1a scores 6.6:1 under WCAG 2.x, a comfortable AA pass. Anyone who has run a real audit will tell you it isn't readable for users with moderate contrast sensitivity loss. The math passes; the experience doesn't.

The gap isn't a bug. The formula is doing exactly what it was specified to do. The problem is that it was never designed to predict legibility. It was designed for display calibration in 1999, and twenty-five years later it underwrites nearly every accessibility ratio reported on the web.

I built OKCA to close the gap.

I've spent over a decade building accessibility tooling inside a special corner of the federal government. Contrast Chaser, a browser tool I built, picked up grassroots adoption there. OKCA comes from the same problem space: designers and accessibility engineers running into pairs that pass WCAG but don't work in production. The difference is that OKCA attacks it at the algorithm layer rather than the tooling layer.

What WCAG Is Computing

WCAG's contrast formula is a luminance ratio:

$$\text{ratio} = \frac{Y_1 + 0.05}{Y_2 + 0.05}$$

The luminance values $Y$ come from linearised sRGB per IEC 61966-2-1, the 1999 display-calibration spec. Two consequences fall out, and both are well documented.

The formula is achromatic. Any two foreground colors at the same $Y$ produce identical ratios regardless of hue or saturation. The neutral grey that matches hot pink's luminance is #9f9f9f ($Y \approx 0.347$); on #1a1a1a it scores the same 6.6:1. Practitioners don't treat the two pairs the same way. The formula can't tell them apart.

It's also symmetric. ratio(A on B) = ratio(B on A), so light-on-dark and dark-on-light score identically. But designers treat polarity as a meaningful input. Light mode and dark mode are different decisions, not interchangeable, and the formula discards that distinction.

One failure produces false passes for chromatic text. The other hides asymmetry that practitioners end up encoding by hand.

What OKCA Does Instead

OKCA changes the math underneath and leaves WCAG's interface intact: same scale ([1, 21]), same AA threshold (4.5), same AAA threshold (7.0). Designers don't have to relearn the numbers.

OKLCH L as the luminance input. OKCA reads the L channel from OKLCH, the perceptually uniform lightness from the Oklab color space. For neutral greys, $L^3 \approx Y_{\text{WCAG}}$ holds to floating-point precision; the cube root inverts the perceptual transform back to linear luminance. So on the achromatic axis, OKCA and WCAG are reading the same numbers, just in a representation a designer can see directly in any modern color picker.

Chroma compression on the lighter element. This is where the false-pass problem gets fixed. The lighter element's lightness is penalised by a chroma-weighted power exponent: more saturation, larger penalty.^[2] The exponent runs from 1.0 at fully achromatic up to 1.5 at fully saturated. Hot pink has Oklab chroma around 0.197, saturated enough to receive the full penalty. Its effective luminance proxy drops, the raw ratio falls with it, and OKCA scores hot pink on near-black at 3.7. Below AA. The same-luminance grey scores 5.4 and passes. The math now distinguishes what practitioners always could.

Polarity-aware scaling. OKCA's final step applies a power curve that differs by polarity: light-on-dark caps at 21, dark-on-light at 20. Same shape, different ceiling. White on black scores 21.0; black on white scores 20.0. White on #767676, the canonical WCAG AA boundary grey, scores 3.5 light-on-dark and 3.3 dark-on-light. Both fail AA. That matches how the pair gets treated in practice.

The FP = 0 Invariant

A contrast algorithm intended for accessibility decisions has one hard constraint: it must never approve a pair that WCAG would reject. The reason is asymmetry. A false pass ships inaccessible text to production. A false failure just nudges a designer toward a safer choice.

OKCA holds FP = 0: it never scores a pair above its WCAG ratio. On the grey axis this is exact by construction — the OKLCH proxy equals WCAG luminance, chroma compression only lowers the lighter element, and polarity scaling only lowers the ratio. Off the grey axis it's subtler: the proxy isn't WCAG luminance (greens, for instance, undershoot it), so for some chromatic pairs the raw ratio can edge above WCAG — and the polarity step is what pulls every score back under, with room to spare. Across the full sRGB gamut (the grey grid plus ~1.2M random and structured pairs, both polarities) OKCA never lands above WCAG. So FP = 0 is proven on the grey axis and verified across the gamut — a property I hold the algorithm to, not a closed-form theorem for literally every input. The analysis is in the design doc.

In practice: across the sRGB gamut, a designer who trusts the OKCA number won't accidentally ship text that WCAG would reject.

What the Probe Data Shows

The FP = 0 property rules out unsafe outputs. It doesn't show OKCA's numbers are calibrated — an algorithm that scored every pair at 1.0 would also satisfy FP = 0. The probe work tests calibration: does OKCA agree with WCAG where WCAG is right, and disagree only where practitioners would?

Three test batteries, 1,249 pairs total:

The design systems battery pulls documented foreground/background pairs from Tailwind CSS v3.4 (46 disagreements), the GOV.UK Design System (15), and USWDS v3.x (50). These are production palettes maintained by teams that take accessibility seriously.

All 111 disagreements sit in the marginal zone, where OKCA scores below 4.5 and WCAG scores at or above it. They're intentional. WCAG's 4.5 boundary is widely treated as too permissive in production; white on #767676 clears the bar by definition, but in practice most teams avoid it. OKCA encodes that judgment into the math rather than leaving it to the designer's gut. Full enumeration with hex values is in WCAG_DISAGREEMENTS.md in the repo.

Zero false passes across 1,249 pairs. The 111 disagreements come with the math.

What OKCA Does Not Do

OKCA is just a contrast algorithm. It deliberately doesn't:

• Model font size or weight. OKCA outputs a single ratio per pair. Size-dependent thresholds (WCAG AA's 3 for large text, 4.5 for normal) are the caller's responsibility.
• Patch WCAG's green-channel weighting. Chroma compression is rotationally symmetric in a/b space. Hue-varying outcomes come from different hues reaching different chroma values at similar lightness, not from OKCA targeting specific hues.
• Replace perceptual judgment. A pair that scores 4.5 clears the threshold but may still be harsh, too low-contrast in context, or wrong for the brand. The number is a floor, not a recommendation.

What's Next

OKCA is on npm as @pawn002/okca, MIT-licensed. The repo is pawn002/okca. The design document, including the FP = 0 analysis (by-construction on the grey axis plus gamut verification), is at docs/OKCA_DESIGN.md.

Try it in one line. No install required — npx klar-cli contrast "#ff69b4" "#1a1a1a" prints Contrast (OKCA): 3.7, the same hot-pink-on-near-black pair from the opening. klar is an MIT CLI that uses OKCA for its contrast engine.

OKCA is one independent attempt to close WCAG 2.x's contrast gaps. It is clean-room work, derived from public specifications, and accepts hex codes and CSS oklch()/oklab() natively.

If you maintain a design system, run your palette through it. If you find an sRGB pair OKCA scores higher than WCAG, that's a false pass. Open an issue. It would be a bug, and I'd want to know about it — it's a property I verify, not a theorem I assume, so the edge cases are exactly what I want.