WCAG 2.1 AA vs APCA Contrast: What the New Algorithm Actually Measures

For years, the WCAG 2.1 AA contrast ratio ruled accessible color decisions. The rule felt simple: a 4.5:1 ratio for normal text, 3:1 for large text (18 pt or 14 pt bold), checked against a formula based on relative luminance. Pass that ratio, ship the color. Fail it, pick something else.

APCA — the Advanced Perceptual Contrast Algorithm, developed by Andrew Somers at Myndex Research — is designed to replace that formula in WCAG 3.0. It doesn't just reshuffle the numbers. It measures a different thing entirely. Understanding what changed helps you make better accessible color decisions right now, even before WCAG 3.0 ships.

Why WCAG 2.1's Ratio Has Known Gaps

The WCAG 2.1 contrast ratio computes the relative luminance of two colors and divides the lighter by the darker, producing values from 1:1 (identical) to 21:1 (black on white). The math is symmetric: #0000FF on #FFFFFF and #FFFFFF on #0000FF both return the same ratio.

That symmetry is one of the problems. Human vision doesn't treat dark-on-light and light-on-dark as equivalent. Research from the APCA working group shows that polarity asymmetry can produce up to a 40% difference in perceived contrast between the two arrangements at the same nominal ratio. Dark text on a white background is generally more legible at lower contrast values than white text on a colored background, but WCAG's formula can't express this.

A second gap: WCAG's ratio ignores text size and font weight entirely. A ratio of 4.5:1 is the same requirement for 12px Regular body copy as it is for 36px Bold display text — even though the latter is far easier to read at lower contrast. APCA instead ties Lc (Lightness Contrast) values to a lookup table of font sizes and weights, allowing larger or heavier text to pass at lower Lc values.

A third practical gap is what designers sometimes call the "blue on black" failure. Pure #0000FF on #000000 produces a WCAG ratio of 2.42:1 — a clear fail. But switch to #0000FF on #0A0A0A and the ratio climbs to 2.44:1, still failing. Now try #0000FF on #111111: 2.60:1, still failing. These comparisons correctly flag poor combinations. Where the ratio misfires is in mid-range blues and greens: some combinations in those hue families pass 4.5:1 while appearing perceptually muddy on real screens due to chromatic aberration and the eye's reduced acuity for short-wavelength light.

How APCA Calculates Lightness Contrast

APCA outputs a signed Lc value rather than a ratio. The sign encodes polarity: a positive Lc means dark text on a light background, negative Lc means light text on a dark background. The absolute value gives you the contrast level.

The calculation uses a non-linear sRGB-to-linearized conversion — similar to WCAG but with a different exponent (0.56 for darker colors, 0.38 for lighter ones) — then applies a gamma correction tuned to typical LCD displays at ~200 cd/m². The result is divided by a normalization factor to land in a roughly 0–106 range (with Lc 106 being pure black text on pure white).

A concrete example I tested manually:

Foreground: #595959 (a common gray used in body copy)
Background: #FFFFFF
WCAG 2.1 ratio: 7.0:1 → passes AA and AAA for all text sizes
APCA Lc: ~Lc 60

Per APCA's lookup table, Lc 60 is sufficient for 16px Regular text. It also passes for 14px Bold. But the same gray at 12px Regular would require Lc 75, which #595959 on white doesn't reach. WCAG would give you an undifferentiated "pass" at every size; APCA tells you the smaller the text, the more contrast you actually need.

For a lighter gray — #767676 on #FFFFFF — WCAG gives 4.54:1 (barely passes AA), while APCA returns approximately Lc 47, which falls below the Lc 60 threshold for 16px body text. In other words, APCA would flag this combination as borderline even though WCAG calls it compliant.

What Lc Values Mean in Practice

APCA publishes a Bronze-level "Simple Offset" reference set as an interim standard while WCAG 3.0 is finalized. The most important thresholds:

Lc 90 — large, bold display text can drop this low; headlines are still highly readable
Lc 75 — recommended minimum for body text at 16px Regular; matches typical WCAG AA intent
Lc 60 — 24px text or 14px Bold; subheadings and UI labels at reasonable sizes
Lc 45 — 18px text or 16px Bold; for incidental text like captions or placeholder copy
Lc 30 — large decorative or non-essential text only

These thresholds account for the polarity direction. An Lc of −75 (white text on dark background) is not the same visual experience as +75 (dark text on light background) even though both absolute values are 75.

Checking Contrast Today

WCAG 2.1 AA remains the legal standard in most jurisdictions — Section 508, EN 301 549, and most WCAG 2.1 references in accessibility legislation don't yet reference WCAG 3.0 or APCA. So you need to satisfy WCAG 2.1 AA first.

You can check both standards side by side. The Color Contrast Checker on Toolora evaluates your foreground and background pair against WCAG 2.1 AA and AAA levels for normal and large text in real time. I use it during design reviews to catch failing pairs before a component lands in production — paste the hex values and it immediately shows the ratio and which text size tiers pass.

If a color pair fails WCAG and you need to find a compliant adjusted shade, the WCAG Color Contrast Fixer will suggest nearby colors that bring the pair into compliance without requiring a full brand-color change. It's useful for situations where a design system color like #7C3AED on #F3F0FF needs only a small nudge on one value to hit 4.5:1.

For teams already building with modern color spaces, APCA was designed alongside the perceptual model used in OKLCH. The algorithm's lightness axis closely mirrors the L axis in OKLCH, which means OKLCH-defined palettes tend to produce more predictable Lc values when you adjust lightness incrementally. If your team is making the transition to OKLCH, the OKLCH Color Converter lets you explore the L (lightness) channel in steps and understand how palette stops translate before you run a contrast check.

Should You Switch to APCA Now?

The short answer: use APCA as a second opinion, not as a replacement, while WCAG 3.0 is still a draft.

The practical workflow that I've settled on:

Check every color pair with a WCAG 2.1 AA checker and confirm the ratio passes.
Run the same pair through an APCA estimator (the APCA open-source JavaScript package is available on npm as apca-w3) and note the Lc value.
If the pair passes WCAG but returns Lc below 60 for body-text usage, flag it for a visual review with actual users — especially older users or those with low-contrast sensitivity.
If the pair passes WCAG and returns Lc ≥ 75, it's well covered by both standards.

The failure mode to avoid: colors that pass WCAG 2.1 but return Lc values in the 40s. These often show up as muted grays on colored backgrounds, or light-on-dark combinations with insufficient perceived weight. WCAG misses them; APCA catches them.

WCAG 3.0 has no confirmed publication date as of mid-2026, and the APCA algorithm itself has gone through several revisions (the current stable version is 0.0.98G-4g as of early 2026). The Lc thresholds may shift slightly before the final standard arrives. Build your accessible color decisions on WCAG 2.1 AA compliance today, and treat APCA values as the early-warning system for combinations that will fail the next standard.

Made by Toolora · Updated 2026-06-28