Skip to content
Toolew.com
Design

Colour contrast and accessibility: a WCAG guide for designers

What contrast ratios mean, how WCAG 2.x calculates them, the AA and AAA thresholds, common pitfalls with brand colours, and how to build an accessible palette.

By Toolew Team ·· 4 min read

Table of contents
  1. What a contrast ratio is
  2. The thresholds that matter
  3. Common pitfalls
  4. Building an accessible palette
  5. Beyond WCAG 2: APCA
  6. A quick checklist

Roughly one in twelve men and one in two hundred women have some form of colour vision deficiency, and many more people read screens in bright sunlight, on low-quality displays or with age-related changes in vision. Text that looks elegant on a designer’s calibrated monitor can be unreadable for a large share of real users. The Web Content Accessibility Guidelines (WCAG) give a measurable standard for contrast, and meeting it is also a legal requirement for many public-sector and commercial websites.

What a contrast ratio is

WCAG 2.x defines contrast as a ratio between the relative luminance of two colours, ranging from 1:1 (identical colours) to 21:1 (black on white). Relative luminance is a measure of perceived brightness. To compute it, each sRGB channel is converted from its 0–255 value to a linear value, then weighted to reflect how sensitive the eye is to each colour:

L = 0.2126 × R + 0.7152 × G + 0.0722 × B

Green dominates because human eyes are most sensitive to it, and blue contributes very little. The contrast ratio is then (L₁ + 0.05) ÷ (L₂ + 0.05), where L₁ is the lighter colour. The 0.05 term accounts for ambient light reflecting off the screen.

You do not need to calculate it by hand: the Contrast Checker shows the ratio for any pair and tells you which levels it passes.

The thresholds that matter

Content Level AA Level AAA
Normal text 4.5:1 7:1
Large text (24 px regular, or about 18.7 px bold, and larger) 3:1 4.5:1
UI components and meaningful graphics (borders of inputs, icons, focus indicators) 3:1 —

AA is the level most laws and policies reference, including the European Accessibility Act and many government standards. AAA is a stricter target that is worth meeting for long-form reading such as articles and documentation.

Some things are exempt: purely decorative elements, logos and text that is part of an inactive (disabled) control. But placeholder text inside an input, which people often style very lightly, is not exempt if it conveys information.

Common pitfalls

Brand colours as text. Many brand colours, particularly bright blues, oranges and greens, fail 4.5:1 on white. Orange #FF8A00 on white is only about 2.4:1. The fix is not to abandon the brand colour but to use it for large elements and backgrounds, and to create a darker shade of it for text and links.

Grey on grey. Light grey secondary text (#999999 on white is about 2.8:1) is one of the most frequent accessibility failures on the web. #6B6B6B or darker passes AA on white.

Text over images. Contrast varies across a photo, so a heading that is readable over a dark sky disappears over a white cloud. Add a solid or gradient overlay behind the text, and check contrast against the lightest area it might cover.

Dark mode is not just inverted. Pure white text on pure black (21:1) can cause halation, a blurring effect for people with astigmatism. Slightly off-white text on a dark grey background is more comfortable while still exceeding 12:1. Saturated colours also tend to “vibrate” on dark backgrounds, so desaturate accent colours for dark themes.

Colour as the only signal. Red and green are indistinguishable for many people with deuteranopia or protanopia. An error state should combine colour with an icon or text label, and charts should use patterns, labels or shapes in addition to colour. The Color Blindness Simulator shows how a design appears with the most common types of colour vision deficiency.

Building an accessible palette

A practical approach is to generate a full scale of shades for each colour, from very light (50) to very dark (950), and then decide which steps are allowed for which use:

  1. Start from your brand colour and generate a shade scale with the Tailwind Shade Generator or the Color Palette Generator.
  2. Check each shade against white and against your darkest background.
  3. Document rules such as “text uses 700 or darker on light backgrounds; 300 or lighter on dark backgrounds”.
  4. Reserve the original brand colour for buttons with white text only if that pair passes; otherwise darken the button or use dark text.

Perceptual colour spaces such as OKLCH make this easier. In OKLCH, changing the lightness value changes perceived brightness consistently across hues, so a yellow and a blue with the same lightness look equally bright, which is not true of HSL. The Color Converter converts between HEX, RGB, HSL and OKLCH so you can adjust lightness predictably.

Beyond WCAG 2: APCA

The next generation of WCAG is exploring a new contrast method called the Advanced Perceptual Contrast Algorithm (APCA). It accounts for font size and weight and for the fact that dark text on light backgrounds is perceived differently from light text on dark backgrounds. APCA is not yet a formal requirement, so legal compliance still depends on WCAG 2.x ratios, but it is a useful second opinion, especially for dark themes and thin fonts.

A quick checklist

  • Body text at least 4.5:1, ideally 7:1 for long reading
  • Large headings at least 3:1
  • Input borders, icons and focus rings at least 3:1 against their background
  • Never rely on colour alone to convey meaning
  • Check text over images at its worst point
  • Test the design in a colour-blindness simulator
  • Define which shade steps are allowed for text, not just which colours

Accessible contrast rarely limits good design. It mostly means choosing one step darker for text, and the result is easier to read for everyone, not only for people with low vision.

Tools mentioned in this article

T
Toolew Team

Editorial team

The Toolew team builds and maintains the tools on this site and writes practical guides on using them well. Every workflow we describe is tested with the tools it mentions.

Necessary
Required for security, language and theme preferences. Always on.