WCAG Contrast or APCA: Which Should You Design To?
Should you design to WCAG contrast ratios or APCA?
WCAG 2.2 for anything you have to stand behind, APCA as a sanity check on dark mode. WCAG is the standard your legal and procurement obligations point at. APCA is the candidate replacement being developed for WCAG 3.0, and it is better at the one case WCAG 2 handles worst.
Designers hear about APCA, see that it disagrees with the tool in their design software, and ask which one is right. The honest answer is that they are measuring different things, and only one of them is currently a standard.
Here is what each one says, where the numbers come from, and how we use both on real projects.
What does WCAG 2.2 actually require?
Two numbers. Success Criterion 1.4.3 requires that "the visual presentation of text and images of text has a contrast ratio of at least 4.5:1", and that "large-scale text and images of large-scale text have a contrast ratio of at least 3:1".
Large is defined precisely: text "with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts". That is a typographic threshold, not a vibe, and it is the line designers most often assume they are over when they are not.
There are two exceptions. Text that is part of an inactive component, pure decoration, invisible, or "part of a picture that contains significant other visual content" has no contrast requirement. And "text that is part of a logo or brand name has no contrast requirement". That second one is narrower than it sounds: it covers the logo, not your headings set in the brand colour.
Where does the 4.5 to 1 number come from?
It is derived, and knowing the derivation makes the standard much easier to argue about. W3C explains that "a contrast ratio of 3:1 is the minimum level recommended" for standard text and normal vision, then applies a compensation factor.
The factor comes from vision research. W3C cites "the empirical finding that in the population, visual acuity of 20/40 is associated with a contrast sensitivity loss of roughly 1.5", so "a user with 20/40 would thus require a contrast ratio of 3 * 1.5 = 4.5 to 1".
And the choice of 20/40 is explicit about who it is for: W3C notes that 20/40 "is commonly reported as typical visual acuity of elders at roughly age 80". That is worth saying out loud to a client who thinks contrast rules are pedantry. The number was chosen to keep your site readable by an eighty year old.
What is APCA measuring instead?
Perceived lightness difference, not a ratio. APCA's own documentation describes it as generating "a lightness/darkness contrast value based on a minimum font weight/size and color pair, and this value is perceptually based".
The output is an Lc value rather than a ratio, and the scale is designed to behave predictably. APCA states that its values are "perceptually uniform", meaning "halving or doubling the APCA value relates to a halving or doubling of the perceived contrast". A ratio does not work that way.
The other structural difference is that font size and weight are inputs, not a separate rule bolted on afterwards. WCAG handles size with one threshold at 18 point. APCA treats the required contrast as a function of how heavy the text is, which matches how legibility actually behaves.
What are the APCA thresholds?
Use-case specific rather than a single pass mark. APCA's documentation gives Lc 90 as the "preferred level for fluent text and columns of body text" and Lc 75 as "the minimum level for columns of body text".
Below that the levels get more permissive by intent: Lc 60 as a minimum for content text that needs to be readable, Lc 45 as a minimum for headlines, Lc 30 as an absolute minimum for non-body text, and Lc 15 as a minimum for non-text elements that merely need to be discernible.
That structure is the real change. WCAG asks whether a pair passes. APCA asks what the pair is good enough for. In practice that is a more useful question during design, and a much harder one to put in a contract.
What is APCA's case against the ratio maths?
Dark mode, mainly. APCA's documentation is direct: "WCAG 2.x contrast cannot be used for guidance designing 'dark mode'", and argues the maths "far overstates contrast for dark colors to the point that 4.5:1 can be functionally unreadable when a color is near black".
It also rejects the idea of a universal threshold, stating that "no single figure such as 4.5:1 or 3:1 can be used as a blanket target for contrast between two colors". That is a claim about the model, and it is APCA's argument rather than a settled finding, which is the right way to read it.
Our experience matches the dark mode complaint, if not the certainty around it. A dark palette that passes 4.5:1 on paper can still read badly, particularly in near-black pairs and particularly at light font weights. That mismatch is common enough that we now check dark themes twice.
So why not just switch to APCA?
Because it is not the standard yet. APCA describes itself as part of a larger colour appearance model and as the candidate replacement for WCAG 2 contrast in the forthcoming WCAG 3.0. Candidate is the operative word.
Everything that creates an obligation for a B2B company points at WCAG. Accessibility statements name a WCAG version and level. Procurement questionnaires ask for WCAG conformance. Audits are run against WCAG success criteria. An APCA score is not an answer to any of those questions.
There is also a practical problem. Most tooling in the design and QA pipeline computes WCAG ratios. Adopting APCA as your primary check means introducing a second set of tools and a second vocabulary for a standard that is still in development.
How do we use both, then?
WCAG as the gate, APCA as the tiebreaker. Every text and background pair has to clear 4.5:1, or 3:1 where the type is genuinely large by the WCAG definition. That is the requirement and it is not negotiable on a client project.
Then, for dark themes and for any pair that only just clears the threshold, we look at the APCA value as a second opinion. If WCAG says pass and APCA says the pair is only fit for headlines, we darken or lighten it. It costs nothing and it catches the cases where the ratio flatters a palette.
We never do the reverse. A pair that fails WCAG does not ship because APCA likes it. The gate is the gate. More on how we build the palette in the first place is in choosing a website colour palette.
What does this mean for a brand palette?
That the brand colour is usually not a text colour. Most B2B brand palettes have one saturated accent chosen to look good as a large shape, and it almost never clears 4.5:1 against white at body size.
The fix is boring and works: keep the brand colour for large type, buttons and graphic elements, and derive a darker variant for text. Nobody perceives that as a brand compromise, because the accent is still doing the work everyone notices.
Dark mode needs its own decisions rather than an inversion. The same accent that was too light on white is often too bright on near-black, and near-black is exactly where the ratio maths is least trustworthy. We set out our approach in designing dark mode properly.
Which will you be designing to in three years?
Probably both, with the balance shifting as WCAG 3.0 develops. Our expectation is that a perceptual model becomes the design-time tool and a ratio threshold stays as the compliance-time check for a long time, because contracts and audits move slower than design tooling.
Which means the useful move now is not picking a side. It is keeping your colour decisions in tokens so that a future change of measure is a values update rather than a redesign. The standard will move. Your palette should be able to move with it.
If you want your current palette checked against both, including the dark theme, that is a quick piece of work and we are happy to do it. Talk to us at phoenix.studio, and our broader WCAG walkthrough is at our guide to WCAG for B2B sites.
Want a site that performs like this?
Tell us about your project. We will come back with a clear next step, no pressure.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Have a project like this?
Tell us where you want to go. We'll tell you how we'd get you there.