Color contrast accessibility: the WCAG ratios and how to test them

Color contrast is the difference in brightness between a foreground color, usually text, and the color behind it. WCAG measures it as a ratio from 1:1 (no difference) to 21:1 (black on white). Outside the US the same topic is searched as "colour contrast"; the standard and the numbers are identical.

It is the failure scanners find most often. The WebAIM Million report of February 2026 found low contrast text on 83.9% of home pages, more than any of the other five error categories that together make up 96% of the errors it detects. Our guide to the most common accessibility errors covers the other five.

The contrast ratios at a glance

Three WCAG success criteria set contrast minimums. Level AA is the level most laws and policies point to, including EN 301 549 (version 3.2.1 is aligned to WCAG 2.1 Level AA) and the ADA Title II web rule (WCAG 2.1 Level AA). All three criteria are part of WCAG 2.2; see which WCAG version to use.

Our WCAG criteria reference lists each one in context: 1.4.3, 1.4.6 and 1.4.11. For a closer read of the most cited one, see WCAG 1.4.3 Contrast (Minimum). The checklist version is in the WCAG 2.2 checklist.

The ratios are thresholds, not targets to round toward. W3C says computed values should not be rounded, so 4.499:1 does not meet 4.5:1 and 2.999:1 does not meet 3:1.

What counts as large text

The lower thresholds (3:1 at AA, 4.5:1 at AAA) apply to large-scale text. The WCAG definition is at least 18 point, or 14 point bold, or a font size that would yield an equivalent size. It refers to the size the content is delivered at, not to text a visitor has enlarged with browser zoom.

WCAG is written in points; CSS is written in pixels. In CSS, 1 inch is 96 pixels and 1 point is 1/72 of an inch, so 18 point is 24 CSS pixels and 14 point is about 18.7 CSS pixels. The glossary entry does not specify a font weight for bold, so when in doubt, treat the text as normal size.

How the ratio is computed

The contrast ratio compares the relative luminance of the lighter color (L1) with that of the darker color (L2). Relative luminance is the brightness of a color normalized from 0 (darkest black) to 1 (lightest white). The WCAG 2.2 definitions give the formulas for an sRGB color:

c = channel value / 255
c <= 0.04045: lin = c / 12.92
otherwise: lin = ((c + 0.055) / 1.055) ^ 2.4
L = 0.2126 R + 0.7152 G + 0.0722 B
ratio = (L1 + 0.05) / (L2 + 0.05)

Red, green and blue carry different weights in the formula. The ratio runs from 1 (identical colors) to 21 (black on white). WCAG 2.x used 0.03928 for the threshold before May 2021; the glossary now reads 0.04045, which makes no practical difference for 8-bit colors.

A worked example

Take mid-gray #767676 text on a white background. Each channel is 118, and 118 / 255 is 0.463, which linearizes to 0.181. A gray has equal channels and the weights sum to 1, so L is 0.181. White has L of 1. The ratio is (1 + 0.05) / (0.181 + 0.05), about 4.54:1, which meets 4.5:1. The next step down, #777777, computes to 4.48:1 and fails. That is why a color that looks the same to you can pass or fail.

You do not need to do this arithmetic yourself. Our color contrast checker takes two colors, shows the exact ratio against every threshold above, and suggests the nearest color that passes while keeping the hue.

Non-text contrast: borders, icons and focus indicators

Success criterion 1.4.11 extends the 3:1 minimum beyond text. It applies to two groups, measured against the colors next to them:

• User interface components. The visual cues needed to tell that a control exists and how to use it, such as the border of a text field when there is no other cue, plus the cues that show a state such as a checkmark or a selected tab.
• Meaningful graphics. The parts of a graphic needed to understand it: the lines in a chart, or an icon that stands alone with no text label.

Several things are exempt: disabled controls, controls the browser draws and the author has not restyled, decorative graphics, graphics whose information is also available as text, and graphics where the exact presentation is essential. A text label or an icon that identifies a control can make a visible border unnecessary.

Focus indicators are the case teams miss. If you style the focus indicator yourself, it needs 3:1 against the adjacent colors. The browser default is exempt from the contrast requirement as long as you have not changed it, but it still has to be visible. Hover effects do not need 3:1. Our checklist pairs this with the related focus criteria.

Text over images and gradients

Contrast requirements apply to images of text as well as live text, and W3C lists using background images that do not give foreground text enough contrast as a failure (F83). The difficulty is that a photo or gradient does not have one background color. The text can be readable over a dark corner and unreadable over a bright sky in the same line.

Two practical rules follow. Measure at the worst spot behind the text, not at one clicked pixel, and if the worst spot fails, change the design rather than the measurement: put the text on a solid or semi-opaque panel, darken the image under it with an overlay, or move the text to a calmer area. Our image contrast checker does the first part: you draw a box around the text on a photo, screenshot or gradient and it reports the contrast across the background, including where it fails. It runs in your browser and the image is not uploaded.

How WCAG applies to a varying background is a judgment call, so treat the numbers as evidence for that call rather than a verdict. The image contrast checker lists its own limits on its page.

Common color contrast mistakes

• Light gray placeholder text. Success criterion 1.4.3 applies to placeholder text. A common placeholder gray such as #a9a9a9 on white is 2.35:1. Placeholders also disappear when someone types, so they are not a substitute for a visible label. The bookmarklet skips placeholders, so check the placeholder color and the field background in the contrast checker.
• Text that only appears on hover or focus. The same W3C page says the criterion covers text shown when a pointer hovers over an object.
• White text on a brand color. White on a bright orange such as #ff6a00 is 2.87:1, a fail at every text size. White on #2563eb blue is 5.17:1. Check the pair, not the palette.
• Secondary text. Captions, footers, timestamps and helper text are usually set in the lightest gray on the page and are the first to fail.
• Checking only the default state. Hover, focus, active, selected and error states each have their own colors.
• Semi-transparent text. Text at 60% opacity is blended with its background before it is perceived, so measure the blended color, not the one in the style sheet.
• Treating zoom as size. Text a visitor enlarges does not become large text under the definition.

What is exempt

Under 1.4.3, W3C lists these exceptions: text in an inactive user interface component (a disabled control), pure decoration, text not visible to anyone, text in a picture that has significant other visual content, and text that is part of a logo or brand name. The logotype exemption has limits. W3C notes that where a logo acts as a control, authors should consider a variant with sufficient contrast, and that low contrast chosen by the author rather than required by brand guidelines is not exempt. W3C defines an inactive component as visible but not currently operable, so a control that still works is not exempt just because it looks faded (our reading of that definition).

How to test color contrast

1. Check design colors early. Before the colors reach code, run each text and background pair through the color contrast checker. It handles semi-transparent text and takes values by hex, color picker or, in browsers that support it, an eyedropper.
2. Measure the rendered page. The accessibility bookmarklet runs in your own browser on the page you have open, including a staging site or a page behind a login, and measures the color actually painted behind each piece of text against 1.4.3. Text over a background image, gradient or video is listed for a manual check rather than guessed at, and the bookmarklet examines up to 3,000 text elements per run. It does not measure placeholder text, text added by CSS ::before or ::after, or text shadows, so check those pairs with the color contrast checker.
3. Use your browser's developer tools. Chrome shows the contrast ratio in the element inspection tooltip and in the color picker, and its CSS Overview lists contrast issues for a page. Firefox's Accessibility Inspector has a Contrast option under "Check for issues", and shows a range of values for text over a gradient. Treat these readouts as a fast first pass and confirm the pairs that matter in the checker.
4. Measure text on photos. Use the image contrast checker for hero banners, cards with photos and screenshots.
5. Walk through the states manually. Tab through the page and check focus indicators, open menus and dialogs, trigger error messages, and re-run the bookmarklet after each one. Automated checks see the state the page is in when they run.
6. Re-check after design changes. A new theme, a campaign banner or a dark-mode variant brings new color pairs.

Contrast cannot be computed from HTML alone, because the painted color depends on style sheets, layers, opacity and images. Our site scanner reads HTML and does not compute rendered contrast; what we check explains why, and why rule-based scanners miss issues covers the wider limit. For a fuller testing routine, see how to test website accessibility and, for fixes by platform, Shopify accessibility.

Fixing a failing pair

W3C's sufficient technique for 1.4.3, G18, is simply to ensure a ratio of at least 4.5:1 between text, including images of text, and the background behind it. A workflow that gets a failing pair there:

1. Change one color, and keep its hue. Darken the text, or lighten the background, one step at a time until the exact ratio reaches the minimum. The color contrast checker suggests the nearest passing color with the hue kept.
2. Prefer the color you can change safely. Moving body text a few steps darker rarely disturbs a design. Changing a brand color changes everything that uses it, so decide whether to keep it for large text and logos and use a darker variant for small text.
3. Test the whole palette as pairs. List every text color against every background it appears on, including buttons, banners and footers, and check each pair once rather than finding them one page at a time.
4. Fix it where the color is defined. If your styles use shared color variables or design tokens, change the value there so every use of the pair is fixed together.
5. Re-test the rendered page with the bookmarklet, then walk through hover, focus and error states.

Color alone is not enough: WCAG 1.4.1

Contrast is a separate question from whether color is the only way information is conveyed. Success criterion 1.4.1 Use of Color requires that color is not used as the only visual means of conveying information, so an error shown only by turning a field's border red fails even if the red has plenty of contrast. For links inside a block of text, W3C lists a sufficient technique, G183: for links set apart from nearby text only by color and lightness, a contrast ratio of at least 3:1 between the link and the surrounding text. The link text must still meet 1.4.3 against the background. An underline is the simplest alternative cue, and the technique notes authors may add one even when the 3:1 ratio is met. Add a second cue, such as an icon, text or an underline, wherever color carries meaning.

APCA and WCAG 3: where things stand

You will see the Advanced Perceptual Contrast Algorithm (APCA) mentioned as a replacement for the WCAG ratio. It is a different calculation that gives different numbers, and our contrast checker does not include it.

WCAG 3.0 is a W3C Working Draft (latest seen: 10 September 2026). Its contrast requirement is marked as developing, and an editor's note in the draft says the contrast algorithm to be used is yet to be determined. The draft text does not name APCA. W3C says WCAG 3 will not supersede WCAG 2, that WCAG 2 will not be deprecated until several years after WCAG 3 is finished, and recommends meeting WCAG 2.2 success criteria now. No law references WCAG 3, and the laws covered on our laws pages cite WCAG 2.x or standards built on it, none of which names APCA.

In practice: meet the WCAG 2.2 ratios for any legal or contractual purpose, and treat anything beyond them as extra evidence for design decisions. Choosing more contrast than the minimum for body text is a design decision you can make, and Level AAA's 7:1 is a ready target for it.