WCAG Color Contrast 2026: Every Threshold, and the 3:1 Rule Teams Keep Missing
Five contrast thresholds, not two — and the one that catches most teams is not about text at all. Plus what changed on 28 June 2025, when contrast stopped being a design preference in the EU.
By David Pham, founder of Pickrack
Most articles on this topic give you two numbers and stop. There are five, and the one teams miss most often is not about text at all.
Something else changed too. Contrast used to be a design argument you could lose to a brand guideline. In the EU it is now a compliance requirement with a number attached to it.
The five thresholds
| What you are looking at | AA | AAA |
|---|---|---|
| Body text | 4.5:1 | 7:1 |
| Large text — 18pt regular or 14pt bold and up | 3:1 | 4.5:1 |
| Non-text UI: buttons, input borders, focus rings, meaningful icons | 3:1 | — |
Ratios run from 1:1, two identical colours, to 21:1, pure black on pure white.
That third row is the one that gets skipped. It is not about text, so it never comes up in a conversation about "is this font dark enough". A pale grey button on a white background fails at 3:1 with no text involved at all. So does a form input whose border you softened to look modern, and so does a focus ring — the thing a keyboard user needs most and the thing designers most often turn down to near-invisible.
What changed on 28 June 2025
The European Accessibility Act (Directive (EU) 2019/882) became applicable in member states on that date. It does not name WCAG itself. It says products and services are presumed to comply when they follow the harmonised European standards, and in practice that means EN 301 549, which adopts WCAG 2.1 Level AA in full for web content.
Four things about it that catch people out:
It follows the market, not your address. An e-commerce site anywhere in the world that accepts orders from consumers in an EU member state is in scope. Being incorporated in Vietnam or Delaware changes nothing.
New builds got no transition period. Contracts signed before 28 June 2025 can run to expiry, capped at June 2030. Self-service terminals get their remaining economic life, capped at 20 years. A website launched after that date got neither.
The microenterprise exemption is narrower than people assume. Fewer than 10 employees and turnover or balance sheet no greater than 2 million euro. Eight employees with 5 million in turnover does not qualify. It covers services, not products, and there is no grace period when you grow past it.
Enforcement has already started. Sweden's Post and Telecom Agency began market surveillance of e-commerce sites in 2025 and has continued through 2026, leading with a check on whether the mandatory accessibility statement exists. That is the cheapest thing for a regulator to verify and the fastest gap to close.
Penalties are set per member state. Reported ranges run from roughly 5,000 to 500,000 euro; Germany provides for up to 100,000 euro per violation, France 5,000 to 250,000 plus annual penalties for a missing statement. Those figures move, and none of this is legal advice — the point is that a number now exists where previously there was only a guideline.
One version note worth having: EN 301 549 v3.2.1 is the current benchmark and carries WCAG 2.1 AA. Version 4.1.1, which moves to WCAG 2.2, is in progress with publication expected during 2026. The contrast numbers are identical in 2.1 and 2.2, so nothing in the table above changes when it lands.
This is the most common failure on the web
The 2026 WebAIM Million report found low-contrast text on 83.9% of the top one million home pages. Not a niche defect — close to a default.
It is also the cheapest serious accessibility problem to fix. Keyboard traps and broken focus order need engineering. Contrast needs a hex value changed.
The failures that actually happen
Four patterns account for most of it:
#999999 on #ffffff → 2.85:1 fails AA body text
#595959 on #ffffff → 7.00:1 passes AA and AAA
Mid-grey body text. #999999 is the colour secondary text drifts to when nobody measures it. It sits at 2.85:1, well under the 4.5:1 floor. #595959 reaches 7:1 and still reads as grey rather than black.
Default placeholder text. The browser default is around #A9A9A9, which is 2.32:1 — worse than the grey above. #767676 gets you to 4.54:1, just over the line.
White text on a saturated brand colour. Bright, high-chroma brand colours are the usual trap. A saturated mid-tone rarely reaches 4.5:1 against white text. Dark text on that same background often passes comfortably, which feels wrong to designers and measures right.
The focus ring. Turned down until it stops interrupting the design, then failing 3:1 for the exact users who depend on it.
Fixing it without redesigning
The instinct is to reach for a different colour. You usually do not need one.
Convert the failing colour to HSL and change only the L. Hue and saturation are what make a colour recognisably yours; lightness is what carries contrast. Step L by 5 percent, re-measure, repeat. In most cases the pair passes two or three steps in and nobody in the brand review notices.
A color converter that shows HEX, RGB and HSL side by side with a live contrast reading against white and black makes this a matter of seconds rather than a round trip through a design tool.
Dark mode does not get a pass
The thresholds are defined as contrast between two colours. Nothing in the wording says which one is lighter. If the product offers a dark theme, it needs to clear 4.5:1 for body text and 3:1 for large text and UI components on its own.
Worth testing deliberately, because the two themes pull in opposite directions: nudging a foreground darker to fix light mode often makes the dark-mode pair worse. Both need a measurement, not an assumption.
Passing contrast is not the same as being accessible
Two things worth stating plainly.
Colour cannot be the only signal. Success criterion 1.4.1 is separate from contrast. An error state that is red and nothing else fails it regardless of how strong the red is — it needs an icon or a text label too. Links inside a paragraph need underlining or some other non-colour cue.
Contrast is one criterion out of dozens. Keyboard operability, focus order, form labels, heading structure, alt text and screen reader behaviour are all untouched by anything in this article. Contrast is worth doing first because it is the most common failure and the easiest to close, not because clearing it means you are done.
Should you chase AAA?
Mostly no. AAA asks 7:1 for body text, which eliminates most brand palettes and a great deal of reasonable design. Every accessibility law and enforcement action in practice references AA.
Reserve AAA for content where a misreading has real consequences — dosage instructions, financial disclosures, legal terms — and hold AA everywhere else.
Checking it
Browser DevTools will give you a ratio for one element: right-click, Inspect, click the colour swatch in the Styles panel. Good for a single check, useless for a sweep.
For a whole page, axe-core and WAVE scan and report. For an individual pair while you are still choosing colours, a checker is faster.
Pickrack's WCAG Contrast Checker reads the ratio and rates it against all five thresholds at once — AA and AAA for normal and large text, plus the 3:1 UI component rule that most checkers leave out — with a live text preview at the pair you have entered. It runs entirely in the browser, so nothing about an unreleased palette leaves your machine.
Bottom line
Learn five numbers, not two: 4.5:1 body text, 3:1 large text, 3:1 anything non-text you can interact with, and 7:1 / 4.5:1 if you have a specific reason to reach for AAA.
Audit the third one first. It is the one nobody checked, it covers your buttons and your focus rings, and it is where the failures are hiding.
Then fix with lightness rather than a new palette, test both themes, and remember that clearing contrast means you have fixed the most common accessibility failure — not that you have finished.
Check a pair now: Pickrack WCAG Contrast Checker.
Related Articles
Base64 Is Not Encryption — And Four Places That Assumption Costs You
Base64 has no key, so it protects nothing. But the interesting part is not the slogan — it is what goes wrong in Basic Auth, in your logs, in btoa() with Vietnamese text, and when a standard decoder meets a JWT.
Is It Safe to Paste a JWT Into an Online Decoder? (2026)
Decoding a JWT needs no key, so decoding itself is harmless. The risk is that a signed token is a live credential — and 'we process client-side' is a claim you cannot see. Here is the 20-second test that settles it.