Color contrast for accessibility: what WCAG actually requires and why it matters

WCAG contrast ratios are often treated as a compliance checkbox. Understanding what the numbers actually measure — and where they fall short — makes you a better designer, not just a more compliant one.

Accessibility WCAG UI/UX

Highlights

WCAG 2.1 measures contrast as a luminance ratio, not as perceived color difference — which means two colors can pass 4.5:1 while still being difficult to distinguish for users with certain color vision deficiencies.

The 3:1 threshold for large text (18pt+ or 14pt bold) is significantly more lenient, but 'large text' is measured by rendered pixel size, not by font-size values in your CSS.

WCAG 3.0 is introducing APCA (Advanced Perceptual Contrast Algorithm), which accounts for font weight, text size, and background luminance together — a much more accurate model than the binary pass/fail of 2.1.

What the contrast ratio number actually measures

The WCAG contrast ratio is calculated from the relative luminance of two colors — how much light they reflect relative to white. The formula uses linearized sRGB values and weights the three color channels by their contribution to perceived brightness (red: 21%, green: 72%, blue: 7%). The result is a ratio from 1:1 (identical) to 21:1 (black on white). What the ratio does not measure: perceptual color difference, hue contrast, saturation, or font characteristics. Two colors can produce a passing 4.5:1 ratio while sharing a hue and still being difficult to distinguish for red-green color blind users. The ratio is a luminance measure only — a necessary but not sufficient condition for accessible color use.

Where WCAG contrast rules apply and where designers get it wrong

The 4.5:1 threshold applies to text at normal weight and size. The 3:1 threshold applies to large text (18pt or 14pt bold at rendered size, not CSS font-size), UI components, and graphical elements that convey meaning. The most common errors: applying 4.5:1 to UI components (not required), assuming font-size CSS values equal rendered pt sizes (they depend on device resolution and scaling), and confusing brand color contrast with text-background contrast. Placeholder text, decorative text, and text in inactive UI components are exempt from contrast requirements. Understanding where the rules apply prevents both over-engineering compliant systems and under-designing accessible ones.

Designing for contrast from the start rather than fixing it at the end

Contrast fixes are expensive when made late. A brand color that fails contrast requirements against its intended backgrounds requires either changing the brand color, changing the background, or restricting the color to non-text uses — each of which has ripple effects through the design system. The practical solution is to define surface and text token pairs with their contrast relationship built in at the token level, not resolved at the component level. The Dark Mode UI Kit is structured this way: each theme exports surface-text pairs that are pre-validated at 4.5:1, so components built on those pairs inherit contrast compliance by default. This prevents the situation where a component looks right in isolation but fails when placed on an unexpected background.

Newer issue

How to document a color palette so the next designer can use it

2026-12-03

Older issue

Print vs. screen: why your colors look different and how to manage the gap

2026-12-17