WCAG Contrast Ratios Explained

“Your contrast ratio is 3.2:1 and needs to be 4.5:1.” Accessibility reports often present the result without explaining which colors were measured, why that threshold applies, or what a responsible repair looks like. The ratio itself is simple, but using it well requires more than testing one brand color against white. Text size, font weight, opacity, backgrounds, component boundaries, interaction states, and images all change what must be checked.

This guide explains the WCAG 2.x contrast thresholds designers and developers use in everyday interface work. It is not a substitute for a full accessibility review: contrast is one set of requirements within a much larger standard. It is, however, a high-value place to work because the result is measurable and many failures can be corrected without changing a product’s visual identity.

What a contrast ratio measures

A contrast ratio compares the relative luminance of two displayed colors. Relative luminance is a calculated estimate of perceived brightness that accounts for the eye’s unequal sensitivity to red, green, and blue light. The ratio ranges from 1:1, where two colors have the same luminance, to 21:1, the maximum represented by black and white in the WCAG calculation.

The key word is luminance, not hue. Two colors can sit opposite one another on a color wheel and still have nearly the same brightness. Saturated red and green are easy for some people to name but can be a poor text and background pair. Conversely, two blues can have excellent contrast when one is very light and the other very dark. Contrast tools convert sRGB channel values to linear light, calculate each color’s luminance, then compare the lighter value with the darker one. You do not need to perform the formula by hand; you do need to test the actual pair.

Green contributes most strongly to calculated luminance, while blue contributes much less. That is why bright yellow on white is hard to read despite looking vivid, while a deep blue can have strong contrast on white. Vividness and readability are different properties. The Contrast Checker reports the ratio and the applicable AA and AAA text verdicts so you can make the decision from the rendered colors rather than from intuition.

The WCAG thresholds in one view

• 4.5:1 for normal text at AA. This covers body copy, captions, field labels, button labels, and most other text that does not qualify as large.
• 3:1 for large text at AA. WCAG defines large text as at least 18 point, commonly treated as 24 CSS pixels, at normal weight; or at least 14 point, about 18.67 CSS pixels, when bold.
• 7:1 for normal text at AAA. This enhanced target can be valuable for reading-heavy experiences and users with low vision.
• 4.5:1 for large text at AAA. Large text receives the same reduced threshold relationship at the enhanced level.
• 3:1 for essential non-text information at AA. Boundaries and states needed to identify or operate controls, focus indicators, and meaningful parts of graphics need contrast against adjacent colors under WCAG 2.1’s non-text contrast requirement.

The text threshold compares the text to its background. The non-text requirement is more contextual: a focus outline may need contrast against both the control and the page around it, and an input boundary needs enough contrast only when that boundary is necessary to identify the field. Decorative graphics and visual treatments that do not convey information are not made meaningful merely by giving them stronger contrast.

Decide whether text truly qualifies as large

Do not label text “large” based on how prominent it feels. Check the computed font size and weight. A 20-pixel semibold heading does not automatically qualify for the 3:1 AA threshold. Font rendering, a thin typeface, all capitals, or generous letter spacing may make text feel substantial, but the standard’s size and weight definitions still apply. When there is doubt, designing the pair to 4.5:1 is the safer and often simpler choice.

Also test responsive states. A desktop headline may qualify as large at 32 pixels and then shrink to 20 pixels on a narrow screen. If its color remains unchanged, the mobile version may require the normal-text threshold. Design tokens named “large-text color” can conceal this problem when components change size without changing color.

AA and AAA are targets, not aesthetic categories

AA is the common conformance target for public-facing products. AAA is an enhanced level and is not expected for every piece of content across an entire site. That does not make AAA irrelevant. A reading application, health service, public instructions, or long-form documentation may benefit from 7:1 body text even when the broader product targets AA. Choose stronger contrast where sustained reading or high consequence makes it valuable.

Higher numerical contrast is not permission to ignore typography. A passing pair can still be difficult to read when the font is extremely thin, tiny, crowded, blurred, or placed in a moving area. Likewise, pure black on pure white reaches 21:1 but can feel harsh for some readers. A dark charcoal on a restrained off-white can remain comfortably above AA or AAA. Measure the pair, then judge the complete reading experience.

Measure the colors people actually see

A source token is not always the displayed color. Opacity blends the foreground with whatever sits behind it. A text token of black at 50 percent opacity on white renders as gray, so testing black against white reports the wrong result. Resolve alpha against the real background or sample the final rendered color. The same issue affects disabled controls, placeholder text, overlays, and translucent borders.

Gradients and images create more than one background. For text over a photograph, the weakest covered region matters, not the image’s average color. Test bright and dark areas behind every line, including states created when the viewport crops the image differently. A dependable repair is a solid text panel or an adequately opaque scrim that guarantees a known background. Text shadows and outlines can help visual separation, but they are difficult to evaluate as a substitute for a stable, passing pair.

Anti-aliasing creates edge pixels that are lighter or darker than the declared text color. WCAG calculations use the specified foreground and background colors rather than individual smoothed edge pixels, but very thin type can still look weaker in practice. Do not select a barely passing color and then combine it with the lightest available font weight. Leave reasonable margin above the threshold, especially in a token shared across platforms and displays.

Test components as a matrix of pairs

A button is not one contrast test. It can include label against fill, fill or border against the surrounding surface, focus indicator against adjacent colors, and icon against fill. Then it changes through hover, focus, active, selected, and disabled states. A form field similarly includes its label, entered text, placeholder, boundary, required marker, error message, and focus state. Inventory these pairs before checking them so a passing default state does not hide a failing keyboard state.

For data visualization, separate text contrast from graphical contrast. Axis labels follow the text requirement. Meaningful lines, bars, points, and boundaries generally need 3:1 against adjacent colors when their visual distinction is required to understand the chart. Direct labels and patterns also reduce dependence on color. A passing luminance contrast does not guarantee that two hues remain distinguishable for people with color vision deficiency, so follow contrast checks with the Colorblind Simulator.

Common failures and specific repairs

1. Light gray body copy. Move the text token darker while leaving the page surface alone. Reserve the lighter gray for decoration, not required content.
2. White text on a mid-tone brand color. Test a dark label on the existing fill before changing the brand. If the button must use white text, create a darker action step and document it as the accessible fill.
3. A quiet placeholder that disappears. Increase its contrast and keep a persistent field label. Placeholder text should be an example or hint, not the only identification of the input.
4. A borderless control on a similar surface. Add a passing boundary, change the control fill, or use another clearly perceivable shape. Ensure hover alone is not the only moment when the control becomes identifiable.
5. A focus ring that matches the button. Choose a ring that contrasts with both the component and its surroundings, or use a two-color focus treatment designed for varied backgrounds.
6. Text placed directly on a photograph. Add a stable backdrop or scrim and test the resulting worst-case pair at each responsive crop.
7. A light-mode token reused in dark mode. Test every dark surface separately. A blue that passes on white can fail on near-black because the relevant luminance distance changed. The dark-mode palette guide explains how to build role-specific steps instead of inverting blindly.

Repair by moving one controlled dimension

When a pair fails, identify which color has fewer constraints. Background surfaces are often shared across many components, so adjusting the foreground may create less disruption. Keep hue and general character, then move lightness until the pair has useful margin above the threshold. If saturation must change because the color leaves the displayable gamut, compare the new value to the rest of the system rather than insisting on a mathematically fixed hue.

Generate candidates with the Shades & Tints Generator, but verify each candidate in the Contrast Checker. A visual scale is not a list of guaranteed contrast levels, and equal-looking steps do not correspond to equal ratio changes. Record the approved pair, not merely the individual color: “link blue on surface white” is an actionable decision, while “accessible blue” is incomplete.

A repeatable contrast review

1. Inventory required content and controls. Include default and interaction states, both themes, responsive text sizes, charts, and text over media.
2. Capture computed foreground and background colors. Resolve opacity and identify gradients, images, or stacked surfaces that change the result.
3. Classify the requirement. Decide whether the item is normal text, genuinely large text, or essential non-text information.
4. Measure the actual pair. Record its ratio and result. Do not round a near miss upward; a value below the threshold fails.
5. Repair the least constrained token. Move lightness, reconsider foreground choice, or provide a stable background, then check all other places that reuse the token.
6. Review beyond the number. Zoom the interface, use keyboard focus, inspect responsive states, and simulate color-vision differences. Confirm that labels, icons, and structure still communicate meaning.

The most efficient time to do this work is when roles and components are being defined. Establish approved text-on-surface, action-label, border, and focus pairs in the design system, then prevent unreviewed combinations from proliferating. Contrast is not a final polish applied after development. It is a relationship between tokens that should be designed, documented, and preserved.

Try it yourself

Check the real foreground and background in the free Contrast Checker, then create controlled alternatives in the Shades & Tints Generator. Nothing is uploaded, and more practical reads are available in the guides section.