A practical guide to WCAG color contrast

WCAG contrast compares the relative luminance of two sRGB colors using (L1 + 0.05) ÷ (L2 + 0.05), where L1 is the lighter value. Identical colors produce 1:1; black and white produce 21:1. The calculation is directional only in appearance—swapping foreground and background does not change the ratio.

A checker converts sRGB channels to linear-light values, combines them with the WCAG luminance coefficients, and compares the results. Because the threshold is exact, do not round a failing value such as 4.49 up to 4.5 when deciding conformance.

For WCAG 2.2 level AA, normal text needs at least 4.5:1 and large text needs 3:1. Level AAA uses 7:1 and 4.5:1. Large text is not simply whatever looks prominent: WCAG defines it using a combination of rendered size and boldness.

Logotypes and incidental inactive text have exceptions, but exceptions should not become design defaults. Body copy, labels, instructions, validation messages, and essential control text should be tested in the actual interface.

WCAG’s non-text contrast criterion applies a 3:1 threshold to visual information needed to identify user-interface components and their states, and to parts of graphics needed to understand content. Examples include a focus indicator, an unchecked control boundary, or a line in a chart that carries meaning.

Not every decorative border needs to pass. The question is whether a low-contrast element is necessary to perceive the component, state, or information. Testing should follow the user task, not just scan a palette in isolation.

A two-color checker assumes opaque colors. Semi-transparent text is composited with its background before the final color exists. Gradients and images can produce many different local backgrounds under one label. Test the lowest-contrast point that a user can encounter, including responsive crops and dark-mode variants.

Text shadows and outlines may help perception but do not automatically fix the foreground-to-background ratio. If a background varies unpredictably, use a solid scrim, container, or adaptive treatment that establishes a reliable contrast surface.

Check default, hover, active, focus, selected, disabled, error, and visited states. A button that passes by default can fail when its background changes on hover. A subtle focus ring may be the only visible keyboard cue. Placeholder text is not a replacement for a persistent label and still needs to be readable when used.

Color must not be the only way to communicate meaning. Pair red error styling with text or an icon, and distinguish chart series with labels, patterns, or shapes where needed. Contrast and redundant cues solve different accessibility problems.

Start with design tokens and test intended foreground/background pairs. Then inspect rendered components in the browser, including themes and interaction states. Use automated scanning to catch obvious failures, keyboard navigation to inspect focus, zoom and high-contrast settings, and manual review for meaning and exceptions.

A passing checker result is evidence for one criterion at one state. It is not a certificate for the whole page. Record the colors, ratio, text size, weight, component state, and WCAG level so another reviewer can reproduce the decision.