APCA Contrast vs WCAG 2: The Complete Guide

Published July 20, 2026 · Updated August 17, 2026 · 12 min read · by the CSS DNA team

TL;DR: WCAG 2 measures contrast as a fixed luminance ratio (4.5:1 for AA body text) regardless of how the text looks. APCA — the perceptual model in the WCAG 3 draft — scores contrast on a Lightness contrast (Lc) scale and adjusts for text size, font weight and polarity (dark-on-light vs light-on-dark). WCAG 2 is what the law recognizes today; APCA better predicts what people can actually read. Audit against both.

What is APCA contrast?

APCA — the Accessible Perceptual Contrast Algorithm — is a method for measuring text contrast that reports a single Lc ("lightness contrast") value instead of a ratio. Unlike WCAG 2's ratio, an Lc score is directional: it accounts for whether the text is dark-on-light or light-on-dark, and the score you need to pass depends on the font's size and weight. It was developed by Myndex Research and is the candidate contrast method in the WCAG 3 draft.

The practical difference in one line: WCAG 2 asks "is the luminance gap big enough?"; APCA asks "can this specific text, at this size and weight, be read on this background?"

How WCAG 2 contrast works

WCAG 2 computes the relative luminance of the text color and the background color and divides them, producing a ratio from 1:1 to 21:1. Thresholds are fixed:

Its strengths are simplicity and legal standing — accessibility regulations reference WCAG 2 today. Its weakness is that a single ratio ignores how vision actually works: 14px thin text and 32px bold text with the same ratio read very differently, and the formula is known to over-approve some dark-mode pairs while over-rejecting some light-mode ones.

How APCA works

APCA (Accessible Perceptual Contrast Algorithm) is the candidate contrast method for the WCAG 3 draft. Instead of a ratio, it produces an Lc value from roughly 0 to ±106, where higher magnitude means more contrast. Three things make it "perceptual":

• Polarity matters. Light text on dark backgrounds is scored differently (negative Lc) from dark-on-light, matching how our eyes perceive each.
• Size and weight matter. The Lc value you need depends on the font's size and weight — small thin text needs far more contrast than large bold text.
• Non-linear luminance. Its curve tracks perceived lightness more accurately than WCAG 2's formula, especially near black and near white.

Common working guidelines: Lc 90 for small body text, Lc 75 for regular body text, Lc 60 for large or bold text, and Lc 45 for very large headlines or non-text UI.

How the APCA algorithm actually computes Lc

APCA is not a ratio with extra rules bolted on — it is a different calculation. These are the steps the reference implementation (APCA-W3, constants set 0.98G-4g) runs for a pair of sRGB colors:

1. Linearize each channel with an exponent of 2.4: (channel / 255) ^ 2.4. WCAG 2 uses a piecewise sRGB curve here; APCA uses a simple power function.
2. Weight and sum to a luminance Y: 0.2126729·R + 0.7151522·G + 0.0721750·B.
3. Soft-clamp near black. If Y < 0.022, add (0.022 − Y) ^ 1.414. This models screen flare in the deep shadows. WCAG 2 approximates the same thing far more crudely with its flat + 0.05 constant, which is why it misbehaves on very dark pairs.
4. Apply polarity-specific exponents. This is the step that has no WCAG 2 equivalent:
   • Dark text on a light background: S = Ybg^0.56 − Ytxt^0.57
   • Light text on a dark background: S = Ybg^0.65 − Ytxt^0.62
5. Scale, offset and clip. Multiply by 1.14, subtract 0.027 for dark-on-light (or add it for light-on-dark), then multiply by 100. Results below Lc 0.1 clamp to zero.

The APCA Lc threshold table

WCAG 2 has two numbers to remember. APCA has a lookup, because the score you need depends on how big and how heavy the text is. These are the working levels from the APCA readability criterion:

Note the direction of travel: 14px text needs a higher score than 24px text, which is the relationship WCAG 2 inverts by giving large text a lower bar on a scale that never measured size in the first place.

When the two models disagree

The interesting cases are where the verdicts flip:

• WCAG 2 passes, APCA fails. Mid-gray text on colored backgrounds and many light-on-dark pairs squeak past 4.5:1 but score a low Lc — text real users squint at.
• WCAG 2 fails, APCA passes. Large, heavy display text (say, 48px bold) can fall short of 4.5:1 yet be perfectly readable, which APCA's size/weight lookup recognizes.

A worked case. #767676 on #FFFFFF is the canonical "minimum accessible gray" — it computes to about 4.54:1, so it clears WCAG 2 AA for body text by a hair, and it appears in a great many design systems for exactly that reason. Its APCA score is Lc 71.6 — under the Lc 75 the table asks for body text, so the same grey that passes the audit is a grey real users squint at. Darkening it to #6e6e6e reaches 5.10:1 and Lc 75, and both models agree. You can check the pair yourself in our contrast checker — it loads with exactly this case.

The reverse case is a 48px bold hero headline in a mid-tone brand color on a tinted background. It can miss 4.5:1 and still be entirely comfortable to read, because APCA's size-and-weight lookup recognises what WCAG 2's flat ratio cannot.

This is why auditing with only one model gives a false sense of safety — and why CSS DNA reports both a WCAG ratio with AA/AAA badges and an APCA Lc score for every text/background pair it inspects.

Which should you use in 2026?

Where APCA stands in WCAG 3 right now

If you are trying to work out whether APCA is "official" yet, the short answer is no — and that has not changed for a while. As of August 2026:

• WCAG 2.2 is the current W3C Recommendation (published October 2023) and it does not include APCA. Its contrast success criteria are still the fixed ratios above.
• WCAG 3.0 is a Working Draft, not a standard. It is expected to take years more, and its visual-contrast guidance has been through several restructurings.
• APCA is a candidate method inside that draft, contributed by Myndex Research. Its inclusion is not final, and the thresholds have been revised between constant sets — which is why implementations should record the version they use (0.98G-4g is the one most tools ship).
• Nothing legally references APCA. The ADA's web rule, Section 508, EN 301 549 and the European Accessibility Act all point at WCAG 2.x. An APCA-only audit will not satisfy any of them.
• The reference implementation has its own licence terms. If you are shipping APCA in a commercial product, read the current terms on the APCA-W3 repository rather than assuming an open licence.

How to check APCA and WCAG contrast on your own HTML

Three practical routes, in increasing order of coverage:

1. One pair at a time. Paste the two hex values into an APCA calculator alongside a standard WCAG ratio checker. Fine for a decision, useless for an audit.
2. Live page, element by element. Chrome DevTools shows the WCAG ratio in the color picker; a contrast extension adds the APCA Lc. This catches real rendered colors, including the ones that come from CSS variables and inherited backgrounds.
3. Whole palette at once. Extract the site's color tokens and test every foreground/background pair as a grid. This is the only method that finds the combination nobody designed but the UI produces anyway — a disabled state on a hover background, say.

Whichever you use, test the rendered colors rather than the values in your stylesheet. Opacity, color-mix(), backdrop filters and overlaid gradients all change what actually reaches the eye, and none of them are visible in the source. Our walkthrough of checking contrast on any live website covers the failures automated checkers miss entirely.

Auditing a whole palette at once

Checking pairs one at a time doesn't scale to a real design system. CSS DNA's audit builds a palette-vs-palette contrast grid from the tokens it extracts from any page, so you can see every failing combination under both models at a glance — and its contrast auto-fix suggests the nearest passing shade so your Tailwind theme ships accessible by default.