Colour and Contrast Accessibility

What a contrast ratio measures

Contrast ratio compares the relative luminance of two colours — how much light each reflects, weighted for how sensitive the human eye is to red, green and blue.

ratio = (L1 + 0.05) / (L2 + 0.05)

where L is relative luminance:
L = 0.2126 R + 0.7152 G + 0.0722 B  (after gamma correction)

The green coefficient dominates because human vision is most sensitive to green wavelengths. This is why pure yellow (full red plus full green) looks so bright and pure blue looks so dark despite both being “full intensity”.

Ratios run from 1:1 (identical colours) to 21:1 (pure black on pure white). The 0.05 constant models ambient screen reflection, which is why no real pair ever reaches infinity.

The WCAG requirements

Level AA is the practical standard. It is what the European Accessibility Act, the US Section 508 rules, the UK public sector regulations and most corporate policies require. AAA is aspirational and not achievable for all content — the WCAG authors say so explicitly.

The 3:1 requirement for UI components is the one most often missed. Form field borders, focus indicators, toggle states, icon buttons and chart elements all need to be distinguishable from their surroundings. A 1px light grey border on white is a common failure.

Check any pair in the colour converter, which includes a WCAG contrast checker.

Designing for colour vision deficiency

About 8% of men and 0.5% of women of Northern European descent have some form of colour vision deficiency — roughly 300 million people worldwide.

Redundant encoding solves it every time:

• Form errors: red border plus an icon plus text describing the problem.
• Charts: different line styles or direct labels, not just different hues.
• Maps: patterns and textures in addition to fill colour.
• Links in body text: underlined, not merely coloured.
• Status: an icon or word alongside the colour.

Building an accessible palette

Design the palette around contrast from the start. Retrofitting accessibility onto a finished brand palette is far harder than building it in.

1. Start with text colours. Establish body text and background first, and confirm 4.5:1 before choosing anything else.
2. Build a lightness scale. Nine or ten steps from near-white to near-black for each hue. Use OKLCH so equal lightness steps look equal.
3. Test every pairing you intend to ship. A brand colour that fails on white may pass on a dark background, or need a darkened variant for text.
4. Never rely on hue difference alone. Two colours can be wildly different in hue and nearly identical in luminance, which means near-zero contrast.
5. Check the dark theme separately. Inverting a light palette rarely produces good contrast; pure white on pure black is uncomfortably harsh and often needs softening to around #E6E6E6 on #121212.

A practical starting point that works: text at least #595959 on white (7:1), secondary text no lighter than #767676 (4.54:1), borders and dividers at least 3:1 against their background.

Build and test colour ramps in the colour converter and browse named colours with contrast ratings.

Accessibility beyond contrast

Contrast is the most measurable requirement, not the only one.

• Focus indicators. WCAG 2.2 added specific requirements: the focus indicator must have at least 3:1 contrast and cover a minimum area. Never write outline: none without providing a visible replacement.
• Text over images. Contrast varies across the image. Use a gradient scrim or a semi-opaque overlay to guarantee a floor.
• Placeholder text. Browser defaults are typically far below 4.5:1. Placeholders are also not a substitute for labels.
• Disabled controls. Exempt from contrast rules, but if users cannot see that a control exists, they cannot work out how to enable it.
• Motion and flashing. Nothing may flash more than three times per second, and prefers-reduced-motion should be honoured.
• Font size and weight. A thin 300-weight face at 14px is hard to read even at technically passing contrast. Contrast requirements assume normal weights.

Testing your work

Automated

axe DevTools, Lighthouse and WAVE catch contrast failures, missing labels and structural problems in seconds. They find perhaps 30–40% of real accessibility issues — a useful floor, not a certificate.

Manual

• Navigate the entire page with only the keyboard. Every interactive element must be reachable and visibly focused.
• Zoom to 200% and confirm nothing is lost or clipped — WCAG 1.4.4.
• Use a colour blindness simulator on your key screens.
• Turn on the operating system high contrast mode.
• Read the page with a screen reader: VoiceOver, NVDA or JAWS.

In your build

Run axe-core in CI against key pages so regressions fail the build. Contrast failures reappear constantly during redesigns; an automated check is the only thing that holds the line.

Frequently Asked Questions