WCAG Contrast Checker

What WCAG contrast is, and how to fix a failing pair

Color contrast is the difference in perceived brightness between text and the background behind it. WCAG (Web Content Accessibility Guidelines) expresses it as a ratio from 1:1 (identical colors) to 21:1 (black on white). It is the single most common accessibility failure on the web, and also one of the easiest to fix once you can measure it.

The thresholds

WCAG 2.1 defines three levels for text:

• AA (minimum) — 4.5:1 for normal text, 3:1 for large text.
• AA Large — 3:1, which applies to text of 18pt or more, or 14pt or more when bold.
• AAA (enhanced) — 7:1 for normal text, 4.5:1 for large text.

AA is the level most organisations treat as the compliance target, and it is also what EN 301 549 and the European Accessibility Act reference. Non-text elements matter too: icons, input borders and focus indicators that carry meaning should reach 3:1 against their surroundings.

How the ratio is computed

Each color is converted to relative luminance — a weighted sum of the red, green and blue channels that approximates human brightness perception (green contributes most, blue least), after gamma correction. The ratio is then (L_lighter + 0.05) / (L_darker + 0.05). Note that this measures luminance only: a red-on-green pair can produce a technically passing ratio while remaining unreadable for someone with a red-green color vision deficiency, so contrast is necessary but not sufficient.

Who this affects

Roughly 1 in 12 men and 1 in 200 women have some form of color vision deficiency, contrast sensitivity declines with age, and everyone reads at reduced effective contrast on a phone in bright sunlight or a laptop at a low brightness setting. Low contrast is not a niche problem.

How to fix a failing pair

Move lightness, not hue. Darkening the text (or lightening the background) raises the ratio while keeping the color identity intact — this is what the “Suggest an AA / AAA color” buttons do automatically: they keep hue and saturation and shift only lightness until the target is met.

Watch the mid-tones. Saturated mid-tones such as orange, yellow and mid-green sit at high luminance, so white text on them almost always fails. Either darken the background substantially or switch to near-black text.

Do not rely on opacity. Setting text to 60% opacity over a background produces an effective color you did not choose; compute the composited value and check that instead.

Check gradients and images at their worst point. If text sits over a gradient or photograph, test against the lightest and darkest areas, or add a solid scrim behind the text.

Building it into the workflow

Decide text pairs while you design the palette rather than after launch — generate your scale with the palette generator, then run each intended pair through this checker and record the passing combinations as tokens. Once they are tokens, regressions become visible in review instead of in production.

The relative luminance formula, step by step

For each of the red, green and blue channels: divide by 255; if the result is at most 0.04045, divide it by 12.92, otherwise apply ((c + 0.055) / 1.055) ^ 2.4. That exponent undoes the gamma encoding of sRGB so the numbers describe physical light. Then combine the linear channels as 0.2126 R + 0.7152 G + 0.0722 B — the weights mirror human sensitivity, so green dominates and blue barely counts. Finally the ratio is (L1 + 0.05) / (L2 + 0.05) with the lighter luminance on top; the 0.05 term represents ambient reflection, which is why the theoretical maximum is 21:1 rather than infinity.

A worked example

White text on the blue #2457D6 used across this site: linearising the channels and applying the weights gives a relative luminance of about 0.12 for the blue and 1.0 for white, so the ratio is (1.0 + 0.05) / (0.12 + 0.05) ≈ 6.2:1. The verdict: comfortably above the 4.5:1 needed for AA normal text, but below the 7:1 of AAA — fine for a button label, worth darkening for long-form body copy. Running the pair through the checker above confirms the arithmetic without any of the rounding.

Contrast is not only for text

Success criterion 1.4.11 extends WCAG contrast to UI components and graphical objects: input borders that define where a field is, focus outlines, icons that carry meaning, and chart lines that are the only way to tell series apart all need 3:1 against the colors adjacent to them. Placeholder text, disabled controls and decorative images are exempt. A useful test: if a user could complete — or fail to complete — a form because of the color, that part needs contrast.

Fixing a failing pair, in order of least damage

First, move the text lightness. Darkening or lightening the glyphs preserves both the background and the brand hue, and the suggestion buttons do exactly this: keep hue and saturation, shift lightness until the target passes. Second, adjust the background when the text color is fixed by policy. Third, change the typography: promoting text to large-text status (18pt, or 14pt bold) drops the requirement from 4.5:1 to 3:1 — that is legitimate engineering, since the thresholds are defined by rendered size, not by class names. Last resort, restyle: add a scrim, a card surface or an outline so the text stops competing with the background directly. Never fix contrast by making body text grey or lowering its opacity; that moves the ratio in the wrong direction.

APCA and the future of contrast math

The WCAG 3 draft experiments with APCA (Accessible Perceptual Contrast Algorithm), which models how perceived contrast shifts with font weight and size instead of applying one ratio to everything. It scores some dark-on-light pairs more generously than today’s formula and small light text more strictly. It is not a legal requirement yet — current audits, EN 301 549 and the European Accessibility Act all reference WCAG 2.x ratios — but when you are choosing between two passing pairs, checking both against a perceptual model is the more modern instinct.

Automating the check

Manual checking covers design-time decisions; keeping them covered needs automation. Lint the token file (assert that every foreground/background pair recorded in your system still passes 4.5:1) and add an axe-core pass in CI on key pages. That combination catches the most common regression: someone edits one hex value and silently drops body copy below AA on a single template.

Frequently asked questions

What are the WCAG contrast thresholds?

AAA requires a ratio of at least 7:1 for normal text, AA requires at least 4.5:1, and AA Large requires at least 3:1 for large text. Below 3:1 the combination fails.

How is the contrast ratio calculated?

WCAG 2.1 defines it through relative luminance: compute the luminance of each color, then take (L1 + 0.05) / (L2 + 0.05) using the lighter and darker of the two. The result ranges from 1:1 to 21:1.

Is the rule different for large text?

Yes. Large text — 18pt or larger, or 14pt or larger when bold — only needs 3:1 to reach AA, while normal body text needs 4.5:1.