Color contrast: how to meet WCAG criteria 1.4.3 and 1.4.11

In WCAG 2.2, level AA, normal text needs a contrast of at least 4.5:1 with its background (criterion 1.4.3). Large text, meaning 18 points and up, or 14 points bold, needs 3:1. User interface components, such as field borders and focus indicators, and parts of graphics needed to understand the content need 3:1 against adjacent colors (criterion 1.4.11). Level AAA (criterion 1.4.6) raises text to 7:1 and large text to 4.5:1. The values are not rounded: 4.48:1 does not meet 4.5:1.

This article follows WCAG 2.2 in the December 2024 edition and the W3C "Understanding" documents that explain each criterion. What is new in version 2.2 is covered in the WCAG 2.2 level AA guide.

The three contrast criteria

The numbers come from vision research. According to Understanding 1.4.3, 3:1 is the minimum recommended by ISO and ANSI standards for readers with normal vision. WCAG multiplies it by 1.5 to compensate for the loss of contrast sensitivity associated with 20/40 visual acuity, which gives 4.5:1.

1.4.6 is AAA, and WCAG does not recommend requiring AAA as a rule for entire sites. It makes sense as a target for long reading text, but it is not the level that laws and standards usually ask for.

What counts as large text

WCAG defines large-scale text as text of at least 18 points, or 14 points bold (WCAG 2.2, glossary). Brazil's NBR 17225 uses the same definition. Since the web measures in CSS pixels, the conversion is 1 pt = 1.333 px, according to Understanding 1.4.3:

Three details of the definition are often missed:

• The size that counts is the size at which the content is delivered. Zoom the user applies afterward does not count.

• With relative units (rem, em, %), the real size is what the browser computes. Check the final value under "Computed" in DevTools, not the value written in the CSS.

• WCAG warns that fonts with very thin strokes or unusual shapes are harder to read at low contrast. A thin 24 px font passes on the number but may still be hard to read.

How the contrast ratio is calculated

The contrast ratio compares the relative luminance of the two colors, which is a color's brightness on a scale from 0 (black) to 1 (white). The formulas are in the WCAG 2.2 glossary (relative luminance and contrast ratio), which in turn takes luminance from the sRGB standard (IEC 61966-2-1).

1. Divide each color channel (R, G and B, from 0 to 255) by 255.

2. Convert each channel to a linear value: if it is less than or equal to 0.04045, divide by 12.92; if it is greater, calculate ((value + 0.055) / 1.055) raised to the power of 2.4.

3. Calculate the luminance: L = 0.2126 × R + 0.7152 × G + 0.0722 × B, using the linear values.

4. Calculate the ratio: (L1 + 0.05) / (L2 + 0.05), where L1 is the luminance of the lighter color and L2 that of the darker one.

Example: text #767676 on background #FFFFFF

#767676 → 118/255 = 0.4627 → ((0.4627 + 0.055) / 1.055)^2.4 = 0.1812
Since R = G = B, L = 0.1812
White: L = 1

Ratio = (1 + 0.05) / (0.1812 + 0.05) = 4.54 → meets 4.5:1

Text #777777 on white: 4.48 → does not meet it (no rounding)

The result ranges from 1:1 (same color) to 21:1 (black on white). Until May 2021, the threshold in the WCAG formula was 0.03928; today it is 0.04045. The W3C says the change has no practical effect on the calculations.

Two glossary rules affect audits. If the CSS sets the text color but not the background color, or the other way around, that is already a failure, because the user's default color is unknown. And if no background color is set, white is assumed.

Contrast for things that are not text (1.4.11)

Criterion 1.4.11 asks for 3:1 against adjacent colors for two things (WCAG 2.2, 1.4.11):

• User interface components: what you need to see to identify a control (button, field, checkbox) and its state (focused, checked, selected, expanded).

• Graphical objects: the parts of a chart or icon needed to understand the content, such as the lines of a chart or a status icon without text.

Understanding 1.4.11 clarifies points that cause confusion:

• A text field does not need a border. But if the border is the only visual cue that a field is there, it needs 3:1 against the background. This also applies to fields with only a bottom line.

• "Adjacent colors" are the colors around the component. For a field, what counts is the page background around it, not its inner fill.

• In a chart, lines and slices need contrast, unless text labels and values already convey the same information.

• A hover style the site adds is supplementary and does not need 3:1. It must not, however, make the component or the focus indicator lose contrast.

Exceptions

Common pitfalls

Placeholder

The sample text inside a field, the placeholder, is text and needs 4.5:1, as Understanding 1.4.3 says. The same goes for text that appears on hover or focus, such as tooltips. Using a placeholder instead of a label is a separate problem, covered in the accessible forms guide.

Text over an image or gradient

Using a background image that does not provide enough contrast with the text is a failure documented by the W3C (F83). On an image or gradient, contrast changes from point to point. Our recommendation: measure where the background comes closest to the text color, not an average. The simplest fixes are a semi-transparent dark or light layer between the image and the text, or a solid background box behind the text. Keep in mind that the image crop changes between phone and desktop, and each variation must conform.

Focus indicator

Criterion 2.4.7 (AA) asks for keyboard focus to be visible. Understanding 1.4.11 adds that if the site changes the focus style, the indicator needs 3:1 against the adjacent background. A light blue outline on a white background, or outline: none replaced by a nearly invisible shadow, usually fails. Brazil's NBR 17225 is more explicit: item 5.11.6, a requirement, asks for a contrast of at least 3:1 between the focus indicator and the background and between the focused and unfocused states.

States that rely on color alone

A toggle button that turns from gray to green when on, or a selected tab that only changes shade, needs that difference in state to reach 3:1. If it does not, add another cue, such as an icon, an underline or text.

The "elegant" gray

Secondary text in light gray (dates, captions, footers, old prices) is where insufficient contrast shows up most. Use the calculation above: on white, #767676 is the lightest gray that still passes for normal text.

How to test

1. Run an automated tool to find the obvious cases. In Chrome, the CSS Overview panel lists contrast issues in its colors section, and the Lighthouse accessibility report also checks contrast (Chrome DevTools).

2. Inspect suspicious text: in the DevTools color picker, the "Contrast ratio" section shows the ratio and whether it reaches AA or AAA.

3. For text over an image, use the eyedropper on the background point closest to the text color and calculate the ratio with those two colors.

4. Test the states: hover, focus with Tab, check boxes, open menus. Check the text that appears and the contrast of each state's indicator.

5. Check 1.4.11 by hand: field borders, icons without text, charts and the focus indicator.

6. Repeat on a phone and, if the site has one, in dark mode.

Automated tools help, but the W3C warns that they cannot determine on their own whether a site is accessible (Selecting Web Accessibility Evaluation Tools). Contrast in states, over images and in non-text elements needs human review. The contrast fix belongs in the site's CSS; a widget installed on top does not change the code (see do accessibility overlays meet the law?).

Contrast in Brazil's NBR 17225

ABNT NBR 17225:2025, Brazil's web accessibility standard, covers contrast in section 5.11, "Use of color" (ABNT NBR 17225:2025). Item names are our translations from Portuguese:

To find out who is bound by Brazil's Inclusion Law (LBI) and what role the standard plays, see the guide LBI and NBR 17225: what Brazilian law requires of a website. This article explains the technical standard; it is not legal advice.

How to check your site

The WebVyze free check analyzes the home page, with no sign-up, and points out accessibility risks under the law, including contrast problems that can be detected automatically. The cases that need a human eye, such as text over images, hover and focus states, icons and charts, still require the manual tests described above.