WCAG 2 vs APCA: What Changes
WCAG 2 and APCA measure the same thing — how strongly text separates from its background — with different models, and they disagree in four predictable places: the WCAG 2 ratio over-credits pairings on dark backgrounds, slightly under-credits some light ones, cannot see polarity, and cannot see fonts. Legally, nothing changes: WCAG 2.x remains the compliance standard, and APCA carries no regulatory weight today. What changes is judgment — a team that reads both numbers catches problems that each model misses on its own.
This article maps where the two models actually part ways, with every number computed, and what a team does when they do. It assumes you know roughly what each model outputs — the foundations live in our contrast guide. The one-line recap: WCAG 2 scores a pair of colors as a luminance ratio from 1:1 to 21:1; APCA scores it as a signed Lc value running to about +106 for dark-on-light and −108 for light-on-dark.
Where do the two models disagree?
For most ordinary pairings — dark text on light backgrounds, at reasonable sizes — the two models rank things much the same way, and that agreement is worth stating before the divergences. The disagreements cluster in four zones:
- Dark backgrounds, where the ratio hands out passing grades that eyes do not endorse.
- Light backgrounds, where the ratio runs mildly conservative — a smaller effect in the opposite direction.
- Polarity: the same two colors produce one ratio but two different Lc values depending on which is the text.
- Fonts: a pairing that carries a bold headline can fail a thin label, and the ratio cannot express the difference.
How do five real pairings rank under each model?
Each row computed — the WCAG ratio, the APCA Lc, and where the verdicts part ways:
| Pairing | WCAG ratio | APCA Lc | Where they part ways |
|---|---|---|---|
gray #777777 on black | ≈4.7:1 | ≈−31 | WCAG passes it for body text; APCA places it below even its headline band |
light gray #B0B0B0 on black | ≈9.7:1 | ≈−60 | WCAG clears the strict 7:1 tier; APCA reads it short of body-text comfort |
gray #888888 on white | ≈3.5:1 | ≈+63 | WCAG ranks it last of these three grays; APCA ranks it first |
white ↔ blue #2563eb | ≈5.2:1 both ways | +75 / −80 | one ratio, two Lc readings |
gray #6B7280 on white | ≈4.8:1 | ≈+74 | WCAG gives one verdict for every font; APCA’s guidance shifts with size and weight |
The third row is the gallery in miniature. By ratio, #888888 on white
(≈3.5:1) sits below both dark pairings; APCA reverses the order and puts it
on top (Lc +63 against −60 and −31). One model says the light pairing is the
weakest of the three; the other says it is the strongest. On dark
backgrounds the gap between the models is dramatic; on light backgrounds it
is mild and runs the other way — a pairing the ratio fails for body text can
still post an Lc that is solid large-text territory.
Open this divergence gallery in Scale Composer — the same pairings with the WCAG ratio and the APCA Lc side by side, agreements and disagreements in one panel.

Why does WCAG over-credit dark pairings?
Two reasons, one mathematical and one perceptual. Mathematically, the WCAG
formula pads both luminances with a constant of 0.05 before dividing, to
model ambient light. Near black, that constant dominates: pure black
contributes almost nothing of its own, so the denominator is essentially the
constant, and even a middling text color clears the bar. Gray #777777
earns ≈4.7:1 against black mostly from the arithmetic of that padding.
Perceptually, light text on a dark ground behaves differently than the mirror image: for many readers, light strokes on dark bloom — they scatter and thicken — and dark-adapted vision resolves fine contrast less well. APCA’s model is built to account for both effects; the ratio’s symmetric arithmetic cannot. This is also why a dark theme derived by mechanically inverting a light palette tends to disappoint: the ratios survive the inversion, the reading experience often does not, which is why dark mode is not inversion and dark palettes need their own checks rather than inherited verdicts.
Why do the same two colors get two Lc values but one ratio?
The WCAG formula sorts the two luminances — lighter over darker — so it has
no way of knowing which color is the text. Swap a blue button’s fill and
label and the ratio holds still. APCA keys its math to which color plays
which role: white text on #2563eb computes to ≈Lc −80, while #2563eb
text on white computes to ≈+75. For this pairing the light-on-dark direction
reads slightly stronger; for others the gap runs wider or reverses. The
practical consequence: a palette decision made in one polarity does not
automatically carry to the other, and a model that returns the same number
for both directions cannot tell you when it fails to carry.
Why does the font change APCA’s answer but not WCAG’s?
WCAG has exactly two size classes — normal and large — and inside each class
the verdict is font-blind: 4.5:1 passes a 300-weight 14px label and a
semibold 16px paragraph alike. APCA’s guidance ties the required Lc to size
and weight on a continuous scale. Take #6B7280 on white, ≈4.8:1 and ≈Lc
+74: for a sturdy 16px regular paragraph that sits near the body-text
boundary; for a light-weight 14px face it is thin; under a bold 24px
headline it is comfortable. Three different practical answers for one
pairing — and the ratio, by construction, can only ever give one. The thin
end matters most: ultra-light faces at small sizes are precisely where
pairings that pass the ratio stop being pleasant to read.
What actually changes for a team?
For compliance: nothing. WCAG 2.x is what current regulation cites, so the 4.5:1 and 3:1 floors decide what ships, and testing against APCA instead does not satisfy any current requirement. What changes is how you spend judgment. A workable division of labor:
- Pass WCAG for compliance. Non-negotiable, whatever the Lc says.
- Read Lc for quality. A pairing that passes the ratio but posts a weak Lc for its intended size and weight deserves a second look — the dark-background rows above are exactly that case.
- Investigate strong disagreement. When the two models diverge sharply, the pairing sits in a perceptual gray zone — usually a dark background, an extreme font, or a polarity edge — and deserves a human look on a real screen rather than a verdict from either number alone.
This is the reasoning behind showing both numbers everywhere: Scale Composer computes the APCA Lc alongside every WCAG ratio it derives, and attaches a verdict only to the ratio — Lc thresholds depend on the size and weight of the text, which a color panel cannot know.
Is WCAG 3 about to replace the ratios?
Not soon, and it is worth being precise about the status. APCA is the contrast method used in the drafts of WCAG 3, and that document is a working draft — its authors state plainly that its content may change, and no part of it is a requirement today. The standard is realistically years from becoming a recommendation, and APCA itself continues to evolve. So the migration question most teams ask — “when do we switch?” — has a deflating answer: nobody needs to switch. The models coexist, each doing the job it is good at, and a team that adopts the both-numbers habit now has nothing to migrate later — if something like APCA becomes normative, the quality signal you have been reading simply gains legal standing.
Read both numbers on your own palette
The divergences above are easiest to internalize on colors you actually use. Load a palette and read the two columns side by side — every role shows its WCAG ratio with its APCA Lc next to it, and the places where your own pairings land in the gray zone between the models surface on their own.