What counts as good contrast? WCAG 2.2, AA, AAA, and why light grey on white isn't enough

Designers love elegant light grey on white. Users with low vision, older people, or anyone reading their phone in summer sunshine hate it. The Web Content Accessibility Guidelines (WCAG) have provided concrete numbers for years on when text is actually readable — and in the EU, the Accessibility Act has made contrast a legal requirement for many providers, not a nice-to-have.

Why contrast actually matters

About 8 percent of men and 0.5 percent of women have some form of color vision deficiency. Add people with cataracts, macular degeneration, or simply age-related vision loss — the WHO counts over 2.2 billion people worldwide with some visual impairment. Poor contrast systematically excludes this group, often without anyone in the design process noticing.

Even unimpaired users read low-contrast text noticeably slower and tire faster. Reading-speed studies show measurable degradation in word processing below 4:1 contrast. Anyone who thinks contrast is just an accessibility niche misses the point: better readability improves conversion rates, because users stay longer and stay focused.

The WCAG levels at a glance

WCAG defines three conformance levels: A (minimal), AA (the standard most sites aim for), and AAA (the highest level, rarely achieved across an entire site). For text contrast, the concrete minimum ratios between foreground and background color are:

• Level AA, normal text: at least 4.5:1 — this is the benchmark you should aim for.
• Level AA, large text (18 pt regular or 14 pt bold and up): at least 3:1 — headings and large buttons may be lighter.
• Level AAA, normal text: at least 7:1 — recommended for long-form reading, government portals, banking.
• Level AAA, large text: at least 4.5:1 — i.e. exactly what AA requires for normal text.
• Non-text elements (icons, controls, graphics, charts): at least 3:1 against the immediate surroundings (WCAG 1.4.11).

How the contrast ratio is calculated

The contrast ratio is (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter and L2 the darker relative luminance. Luminance itself is weighted from the sRGB components — green has the biggest impact, red is middling, blue contributes the least. That's why pure blue on black often looks worse than its mathematically respectable ratio would suggest.

Values theoretically range from 1:1 (same color) up to 21:1 (black on white). 4.5:1 corresponds roughly to dark grey (#595959) on white — many designs land below that, especially for placeholder text, disabled buttons, or grey subtitles. A second in a contrast checker often saves hours in a later audit.

APCA — the successor for WCAG 3.0

The WCAG 2 formula has a known issue: with very light or very dark combinations it produces misleading values. Black text on bright yellow scores almost 20:1, but in dark mode comparisons often looks worse than a milder contrast. APCA (Advanced Perceptual Contrast Algorithm) models perception more accurately, accounts for font size and weight directly, and produces a value in perceptual lightness difference (Lc).

APCA is a candidate for WCAG 3.0 but not yet officially adopted. In practice: for legally binding conformance today, use WCAG 2.2; for dark mode design and fine-grained tuning, consult APCA as a second opinion. A good contrast tool can show both values side by side.

Legal framework in 2026

Across the EU, the European Accessibility Act took effect on 28 June 2025. It forces many providers — online shops, banking apps, travel and transport services, e-readers, many B2C services — to comply with the EN 301 549 standard, which requires WCAG 2.1/2.2 AA. Violations can be fined and, in extreme cases, lead to products being withdrawn from the market.

In the US, Section 508 has applied to federal agencies for decades, and the Americans with Disabilities Act has increasingly been applied to websites by the courts. If you serve an international audience, accessibility is no longer optional — and contrast is the low-hanging fruit that shows up first in any audit.

Common pitfalls

The following elements are missed in 90 percent of designs — check them specifically:

• Placeholder text in forms: often far too light grey by default (e.g. #999) — once it carries information, 4.5:1 applies.
• Focus indicators: the browser default outline often gets removed in CSS — its replacement must have at least 3:1 against the background (WCAG 2.4.11, new in 2.2).
• Disabled buttons: WCAG formally exempts them, but if users can't tell something is disabled, that's a usability bug. Pragmatically: at least 3:1.
• Brand colors on brand colors: logo colors love to migrate to buttons or text on colored backgrounds — almost always a contrast trap.

What a brand redesign taught me about contrast

In 2023 I supported a brand redesign on a client project. The new corporate teal was beautiful — and had a 2.1:1 contrast ratio against white. WCAG AA requires 4.5:1 for normal text. Marketing argued: 'our teal is the brand, that's non-negotiable'. We landed at a compromise: the brand teal only for large headlines (≥18 pt / ≥24 px), with a 22 % darker variant for body text. From the client's perspective both are 'the same teal', and the A11y check is green.

What I took away: WCAG compliance is rarely a technical problem, almost always a political one. Designers and marketers want the 'pure' brand element. Developers want fast code. Nobody wants to be the killjoy saying 'we can't do this'. The solution is rarely 'change the brand colour' — it's 'think of the brand colour in context-specific variants'. A brand can have two or three teal tones, all recognisably the same family but with different contrast properties.

Practically since 2024 I use a three-part brand token system: --brand-primary (the brand colour for large elements), --brand-text (darker variant for body text on white), --brand-text-inverse (lighter variant for body text on dark). All three are derived from the 'hero value', so the brand image stays coherent — but every use case has its contrast-safe token.

WCAG 2.2: what changed in 2024

WCAG 2.2 became a W3C Recommendation in October 2023 and has been the prevailing version since 2024. On contrast specifically little changed structurally — the 4.5:1 / 3:1 / 7:1 thresholds remain. But 2.2 adds 9 new success criteria focused on other accessibility areas: Focus Visibility, Target Size, Drag Movements, Consistent Help, Redundant Entry, Accessible Authentication.

Particularly relevant for UI designers: 2.5.8 Target Size (Minimum) — interactive elements must be at least 24×24 CSS pixels. 2.4.11 Focus Not Obscured — during tab navigation the focused element must not be hidden by other UI. 3.3.7 Redundant Entry — the same data must not be requested multiple times in the same process (e.g. billing and shipping address must be copyable).

Important for German providers: the BFSG (German Accessibility Strengthening Act) since 28 June 2025 obliges practically every B2C online provider (shops, banks, travel services) to WCAG 2.2 AA. Fines up to EUR 100,000 are possible. Public bodies were already on the hook via BITV 2.0 — now private sector is also in mandatory mode. Anyone running a website in 2026 not yet WCAG 2.2 compliant should prioritise.

My audit workflow for accessibility compliance

A mix of automated tools and manual checks I run through for every project:

• Browser devtools. Chrome and Edge ship a solid accessibility audit in Lighthouse, catching the most common issues (missing ARIA labels, contrast issues, wrong heading hierarchy) automatically. F12 → Lighthouse → Accessibility. Time: 60 seconds per page.
• axe DevTools browser extension. More detailed than Lighthouse with concrete code recommendations per finding. The free tier suffices for most projects. For larger audits the Pro tier (USD 399/year) pays off.
• CI integration via axe-core. Anyone treating accessibility as more than a maintenance item builds axe-core into CI. On every commit pages are automatically checked against WCAG criteria, issues appear as PR comments. Setup: about 2 hours, then it runs in the background.
• Real screen reader tests. NVDA (Windows, free), VoiceOver (Mac, built-in), TalkBack (Android, built-in). At least once per quarter, walk through the key flows with a real screen reader. Automated tools miss subtler problems like confusing order or pointless decorations.
• Grayscale test. Render the page in greyscale (browser: devtools → Rendering → Emulate Vision Deficiencies → Achromatopsia). What remains comprehensible, what collapses? If buttons without colour are no longer recognisable as buttons, you need additional visual differentiation (border, icon, label).

My standard cadence for ongoing projects: monthly Lighthouse run, quarterly full axe audit, twice-yearly screen reader test with a real user (or at least one self-run). Plus CI integration for automatic regression detection. Not trivial to set up, but once running it's nearly maintenance-free.

Colour blindness: what you should know

About 8 % of men and 0.5 % of women have some form of colour vision deficiency. The most common is red-green deficiency (deuteranopia/protanopia), where red and green look similar. The second most common is tritanopia (blue-yellow deficiency). Full colour blindness (achromatopsia) is very rare (1 in 30,000) but exists.

Practical UI consequence: never use colour ALONE as information. A red 'invalid' box needs an icon (X) or text ('Error') as well. A green 'OK' box needs a check mark. Status indicators with 'red/green traffic light' logic are useless for red-green blind users — add shape (circle/triangle/square) or symbol. WCAG 1.4.1 ('Use of Color') is exactly about this. Browser simulations (see above) give you a feel in seconds of how your UI looks to affected users.

Frequently asked questions

Is it enough to hit AA everywhere?

For most commercial websites, yes. AA is the legally required standard under the European Accessibility Act, ADA, and EN 301 549. AAA is something you target voluntarily when long-form reading (magazines, blogs, knowledge bases) or safety-critical audiences (banking, health) are involved.

What if the brand color blows the ratio?

Then the brand color becomes a decorative accent and is not used for text. Practical example: bright orange as a button background with white text works; as a text color on white it doesn't. Many brand guides therefore define a second, darker variant explicitly for text — that should live in your design system by default.

How do dark mode and image backgrounds factor in?

Dark mode changes the game: light text on very dark backgrounds can appear blurry with thin fonts (halation). A slightly heavier font weight or a marginally lighter dark grey helps. Image backgrounds need a text shadow or a semi-transparent overlay box — measure contrast against the darkest spot behind the text.

What's the difference between WCAG AA and AAA?

WCAG has three levels: A (minimum), AA (standard for most legal requirements), AAA (premium). Practically over 95 % of sites target AA — that's the legal threshold for the German BFSG, US ADA lawsuits and the EU Web Directive. AAA makes sense for highly specialised applications (disability organisations, vision-impaired training platforms), but for most commercial use it's overkill and partly visually restrictive (7:1 contrast effectively means black on white).

How do you measure contrast on animated or transparent elements?

For animations the worst frame counts — if an element spends 200 ms in a low-contrast phase, that phase counts. Practically that means: hover transitions should be tested at the end state (default and hover states must both be WCAG-compliant). For transparent elements (e.g. semi-transparent overlay boxes) you measure the final rendered colour value — what the browser actually displays. Browser devtools show the 'computed colour' value to check against.

Are there tools that continuously monitor my WCAG compliance?

Yes, several: Deque axe Monitor (enterprise, expensive), Pa11y (open source, free, CI-ready), WAVE API (free for occasional scans, paid for API volume), Tenon.io (freemium). For 90 % of smaller projects Pa11y in CI is enough. For enterprise projects with compliance requirements the enterprise stack pays off — it delivers dashboards, trend analyses, and legally usable reports.