WCAG Color Contrast — What Designers Need to Know

Grey text on a slightly lighter grey button looks modern until someone in bright sunlight—or with low vision—cannot read it. Web Content Accessibility Guidelines (WCAG) encode minimum contrast between text and background so content stays legible across devices, lighting, and vision differences.

Contrast rules apply to user interface components and graphical objects too, not only paragraphs. Treat them as design constraints that improve usability for everyone, not a checkbox for compliance audits alone.

What contrast ratio measures

Contrast ratio compares relative luminance of two colours on a scale from 1:1 (identical) to 21:1 (black on white). WCAG formulas account for human perception—green does not behave like red at the same hex brightness.

You test a foreground (usually text) against its background. Partial transparency compositing matters: light text on a dark overlay over a photo uses the resulting blended colour, not the photo average or the overlay alone.

Tools compute ratio automatically. Manual math is tedious; the Wivrix color contrast checker accepts hex or RGB pairs and reports pass/fail against WCAG thresholds.

WCAG levels: AA vs AAA

Level AA is the common legal and organizational target:

• Normal text (below 18 pt regular, or below 14 pt bold): 4.5:1 minimum
• Large text (18 pt+ regular, or 14 pt+ bold): 3:1 minimum
• UI components and graphical objects (icons, button borders essential to function): 3:1 against adjacent colours

Level AAA stricter:

• Normal text: 7:1
• Large text: 4.5:1

AAA is aspirational for body copy on marketing sites; AA is the practical bar for most products. Regulations and procurement policies often cite AA explicitly.

Disabled states, logos, and incidental decoration have exceptions—but if users must read it or click it, assume rules apply.

Common failures in real designs

Light grey on white for secondary labels—often lands near 2.5:1.

Coloured text on coloured backgrounds without checking both light and dark themes.

Text over photography without scrim—busy backgrounds slash effective contrast.

Focus rings removed for aesthetics—keyboard users lose 3:1 component visibility.

Placeholder text too faint—treated as readable by some users though not officially "text" in all audits; still bad UX.

Dark mode swaps pitfalls: #777 on #222 may pass mentally yet fail ratio. Test both themes.

Worked example: button label pass and fail

Body font 16 px regular (~12 pt)—counts as normal text, needs 4.5:1 for AA.

Fail pair: text #767676 on background #FFFFFF

Computed ratio ≈ 4.48:1—borderline fail at AA for normal text (needs 4.5:1).

Fix option A: darken text to #757575 → ratio ≈ 4.54:1 — passes AA narrowly.

Fix option B: use #595959 → ratio ≈ 7.0:1 — passes AA comfortably and approaches AAA for normal text.

Large text case: headline 24 px bold (~18 pt bold) on #1a1a1a background with white #FFFFFF text:

Ratio 21:1 — passes AA and AAA for large and normal classifications.

UI component: icon-only button border #0066CC on white fill for shape recognition—icon interior vs border must hit 3:1 against adjacent white; border vs white often passes if blue is saturated enough. Verify with the checker, not eyeballing.

Document chosen pairs in design tokens so engineers do not substitute "close enough" hex values during implementation.

Process: test early, test in context

Pick primary text/background pairs at brand definition time. Run contrast before stakeholders approve palettes.

In Figma or code, re-test after opacity, blur, and gradient layers stack—flatten logically to what users see.

For data visualization, distinguish series with more than hue—patterns and labels help when colour contrast between adjacent slices cannot all hit text rules.

Automated scanners (axe, Lighthouse) catch many issues; manual check still needed for images and gradients.

State tokens help engineering: define --text-primary and --surface-default with verified pairs rather than ad hoc hex in components. When brand refreshes, update tokens once and re-run the color contrast checker across the matrix—primary on primary-muted, secondary on surface-elevated, danger on danger-subtle—before QA begins.

Print stylesheets often lightened greys for toner savings; if users print invoices or tickets, verify contrast in @media print blocks too. PDF exports from web apps inherit CSS colours unless flattened—run spot checks on generated PDFs, not only live HTML.

Motion and contrast interact for some users; high-contrast mode OS settings may override your palette. Semantic HTML and visible focus still matter when system colours substitute brand hues. Video captions over moving footage need their own background box or outline—WCAG includes contrast requirements for caption text against video frames, not only static pages.

This is not legal advice on accessibility compliance. Laws vary by region and sector; WCAG informs many but not all standards. Consult policy experts for mandated levels.

Frequently asked questions

Does underline or bold fix low contrast?

No. WCAG contrast applies to perceived text colour against background. Decoration does not substitute for ratio.

What about text on gradients?

Test the worst segment—or add a uniform scrim so effective background is stable. Animated gradients need frame-by-frame minima if text sits directly on them.

Are brand colours exempt?

Logos often exempt; marketing text using brand colours is not. Adjust tints for body copy while keeping brand primaries for large headlines where ratios ease.

How do opacity layers affect ratio?

Multiply foreground alpha over background to get composite RGB, then test composite vs surrounding area. Checkers with alpha support save manual blending.

Is 4.5:1 enough for dyslexia-friendly design?

Contrast helps many users; dyslexia-friendly typography also benefits from spacing, font choice, and avoiding justified blocks. Aim AA minimum, AAA when feasible for long reading.