5 min read

The WCAG color contrast checklist every designer should bookmark

AA vs AAA, the math behind the ratios, why gray-on-gray fails on retina screens, and the two-line HTML that makes a color contrast test run in seconds.

By
Software Engineer · M.Sc. Mechanical Engineering · Ontario, Canada

The numbers that matter

WCAG 2.1 sets four thresholds for text contrast against background:

  • AA normal text - 4.5:1 minimum
  • AA large text - 3:1 minimum (18pt+ regular or 14pt+ bold)
  • AAA normal text - 7:1 minimum
  • AAA large text - 4.5:1 minimum

"Large" is defined as ≥ 24px regular or ≥ 18.66px bold. Everything smaller has to hit the normal-text threshold.

Most public sites target AA. Government sites and services regulated by accessibility laws (ADA in the US, EAA in the EU, AODA in Ontario) require AA at minimum, and many aim for AAA on critical text.

Where the ratio comes from

The math: convert both colors to linear-light space (undoing the gamma correction), compute the WCAG "relative luminance" of each, then divide (lighter + 0.05) by (darker + 0.05).

Pure black on pure white gives 21:1 - the maximum possible ratio. Two shades of the same gray give 1:1. Everything else is somewhere in between.

Color Contrast Checker does this math live as you tweak either color, and shows pass/fail badges for all four AA/AAA thresholds simultaneously.

Where designers usually fail

Six patterns that reliably ship with failing contrast:

1. Gray text on gray backgrounds. The most common Slack/Notion-inspired aesthetic. #666 on #f5f5f5 is 5.7:1 - AA passes. #999 on #f5f5f5 is 2.8:1 - fails AA. If you can't tell them apart at a glance, run the ratio.

2. Brand-color CTAs on white. A pastel primary button (#7dd3fc, #f472b6) usually fails when the button label is white. Darken the button until the label passes, or switch label to black.

3. Placeholder text. The default placeholder color in most browsers is #a9a9a9 - around 2.8:1 on white. That's not text you can read on a phone in bright sunlight. Bump placeholder color to at least #666.

4. Disabled states. Convention is to gray out disabled buttons. If a disabled button is unreadable, users can't tell what capability would be available. Failing contrast on disabled text is technically WCAG-compliant (disabled elements are excluded from contrast requirements), but users hate it. Aim for 3:1 anyway.

5. Icons and iconography. WCAG 2.1 added SC 1.4.11 (non-text contrast) - icons and UI controls need 3:1 against their background. A light-gray checkbox border on a white form fails.

6. Text over images / gradients. The contrast checker measures one foreground color against one background color. Text over an image varies - a "3:1 on average" measurement is worthless if the letter o happens to sit over a bright spot. Solutions: dark scrim overlay, text shadow, or a solid color band behind the text.

When lower contrast is fine

Two categories are explicitly exempt from WCAG contrast requirements:

  • Text that's part of a logo. Your logo is a brand asset; it doesn't have to pass contrast.
  • Incidental text. Decorative text, watermarks, text that's part of a photograph. If removing it wouldn't affect user comprehension, it's incidental.

Anything a user needs to read must pass.

Alpha and blending

Colors with transparency have to be evaluated against what's behind them, not against pure transparent. A translucent card over a busy background can have wildly different effective contrast in different spots.

The reliable fix: for critical text, make sure the effective background under the letter is a solid, predictable color. Add an opaque backing layer if needed.

Color Contrast Checker handles alpha blending - you can enter #000000aa (66% opaque black) as the foreground and it blends against the background before computing the ratio.

Dark mode has its own trap

Dark backgrounds with pure-white text produce eye strain - the brightness delta is too high. Modern dark themes use #e0e0e0 or #dedede on #111 rather than pure white on pure black. That's still 15+:1 - well past AAA.

The opposite mistake: dark themes with barely-lighter dark gray for secondary text. #666 on #111 is only 3.5:1 - fails AA. Secondary text in dark themes should still be above 4.5:1 against the dark background.

The glassmorphism problem

Frosted-glass panels (blurred background, semi-transparent overlay) are visually gorgeous and a contrast nightmare - the effective background under the text changes with every scroll. Two mitigations:

  • Increase the background opacity of the glass. Pretty glass with unreadable text isn't shipping-quality.
  • Test contrast against the darkest and lightest spots the background can produce. If both pass, you're safe.

Glassmorphism Generator shows text on top of the glass panel - you can eyeball whether the text is still readable across a mixed background, and the CSS output includes an alpha slider you can push higher if it fails.

The APCA note

APCA (Advanced Perceptual Contrast Algorithm) is the proposed contrast algorithm for WCAG 3, and it produces different numbers than WCAG 2.1. APCA is arguably more accurate - it accounts for font weight, dark-vs-light mode differences, and the perceptual non-linearities that WCAG 2.1 ignores.

But WCAG 3 is still in draft. Accessibility audits, lawsuits, and government compliance rules all cite WCAG 2.1 in 2026. Design against 2.1; treat APCA as a bonus.

The workflow

Every design review should include a two-minute contrast pass:

  1. Screenshot the design.
  2. For every text element, pick the foreground and background colors.
  3. Color Contrast Checker - verify ≥ 4.5:1 (or 3:1 for large).
  4. Adjust the color if it fails. Small nudges usually work - a shade or two darker on text, a shade lighter on the background.

If your design system defines colors as tokens, run every token pair through the checker once and record the pass/fail matrix. Then you never re-derive.

Related tools

Tools mentioned in this post

Written by Shan

Shan builds 712 Tools. He holds a Master's degree in Mechanical Engineering and now works as a Software Engineer, shipping browser-based developer utilities out of Ontario, Canada. Learn more · 712studiogames@gmail.com