WCAG 1.4.11 Non-text Contrast: buttons, fields, icons

Input borders, icon buttons, focus rings, checkbox ticks and chart lines all fall under 1.4.11, and none of them is covered by the text rule in 1.4.3. This page covers what has to reach 3:1 and against which colors, the exceptions and where they get misread, what W3C says about hover, focus and checked states, real failing and passing CSS, a step-by-step test, and exactly what GotAlt's tools can and cannot measure.

What WCAG 1.4.11 requires

The criterion asks that "the visual presentation of the following" has "a contrast ratio of at least 3:1 against adjacent color(s)" (W3C, WCAG 2.2). Two things are listed:

• User interface components: the visual information required to identify a component and its states, except for inactive components and components whose appearance is set by the browser and not modified by the author.
• Graphical objects: the parts of graphics required to understand the content, except where a particular presentation is essential to the information being conveyed.

W3C's Understanding page defines a graphical object as a stand-alone icon, such as a print icon with no text, or an important part of a more complex diagram, such as each line in a graph. A simple single-color icon is one object; a chart is many.

It is Level AA and was added in WCAG 2.1, so WCAG 2.0 does not contain it. WCAG 2.2 keeps it unchanged. The bar is 3:1, lower than the 4.5:1 for normal text, and W3C says the requirements and rationale are "similar to those for large text" in 1.4.3.

That version history matters for law. WCAG 2.1 AA is the target of the ADA Title II web rule (ADA.gov) and, through EN 301 549 v3.2.1, of the European Accessibility Act, so 1.4.11 is in scope for both. Section 508 (U.S. Access Board) and Ontario's AODA (Ontario.ca) point at WCAG 2.0 AA, which has no non-text contrast rule. See which WCAG version the law requires and our laws hub. This page explains a technical standard and is not legal advice.

What the data says about 1.4.11

The 2026 WebAIM Million found low contrast text on 83.9% of the top million home pages, but that figure is for text, which is 1.4.3. The report has no equivalent number for borders, icons or charts. Automated tests cannot decide which parts of a graphic are "required to understand" it, so a reliable failure rate for 1.4.11 would need human judgment on every page. We know of no published measurement and give none. The practical consequence: a clean automated contrast result says nothing about the criterion on this page.

What is "required to understand"

Not every shape on a page needs 3:1. W3C's Understanding 1.4.11 says a graphic only needs sufficient contrast where a person needs to perceive it to understand the content, and lists four cases where that is not so:

• The graphic repeats what text says. "A graphic with text embedded or overlaid conveys the same information", such as labels and values on a chart. Text inside a graphic still has to meet 1.4.3.
• The graphic is for aesthetic purposes and nobody needs to see it to understand the content or use the page.
• The information is available in another form, such as a table that follows a graph.
• The presentation is essential to the information. W3C's examples are logos, flags, photographs of real scenes, screenshots, medical diagrams that use the colors found in biology, and heat maps.

For each remaining graphic, W3C's method is to work out which parts are needed to understand it and to imagine a viewer who could see only those parts. In W3C's magnet example those parts are the U shape (by its outline or its red fill) and the pale tips, each measured against its neighbors. In its phone icon example, a white icon sits inside an orange circle: the graphical object is the icon, measured against the circle, and the circle's own edge against the page does not matter because the icon can be understood alone.

Symbols typed as text characters count as graphics. W3C's example is a close button using an uppercase "X" and a button using a ">" character: they "count as non-text characters/symbols" and need 3:1, not 4.5:1.

The exceptions, and where they get misread

Inactive components

"An inactive user interface component is visible but not currently operable," in W3C's words, for example a submit button that cannot be activated until the required fields are complete. A button with the HTML disabled attribute qualifies. A button that is styled gray but still works is active, and so is one that only looks disabled because someone set opacity: 0.4 on it. Be strict: the exemption follows the behavior, not the look.

Controls the browser draws

Components are exempt where their appearance is "determined by the user agent and not modified by the author." An unstyled native checkbox, select or focus ring is the browser's responsibility. The moment you restyle it with a custom border, a background color or appearance: none, we read that as modified by the author: from then on it is yours to measure. W3C's own default-focus note says the browser's default focus style is exempt from contrast requirements "but must still be visible".

Logos and essential graphics

A logo is exempt, with two limits W3C spells out. If the logo is also the only visible content of a link or button, the control keeps its other obligations, such as a focus indicator. And if you choose to show logos faded until hover, that is an author's choice and not "essential": W3C's examples treat it as a failure.

What is not an exception

• A control with no border and no fill is fine if its visible text identifies it. W3C says the criterion does not require "a visual boundary indicating the hit area". A boundary is required only "when there is no other visual way to identify the presence of the control".
• Text itself is never 1.4.11. Placeholder text, button labels and chart labels are 1.4.3 (4.5:1, or 3:1 for large text).
• A visible label does not clearly excuse a faint input border. W3C's failing example for a faint input border (#AAA, 2.32:1) is an input with no label, but W3C does not say a label makes a faint border acceptable. A label says what a field is for, not where the field starts, so we recommend 3:1 on every bordered input.

States: focus, hover, checked, visited

Every state of a component is in scope, but the rule is narrower than many people assume. W3C's Understanding page says the criterion "does not directly compare the focused and unfocused states of a control", and that changes in color between states of one component do not need 3:1 against each other when they do not appear next to each other: its own examples are that visited links need not contrast with the default link color and mouse hover indicators need not contrast with the default state. What the criterion does require in each state:

• The component must not lose contrast with adjacent colors. A hover style that fades a 3.5:1 border to 2:1 fails.
• State indicators need 3:1 against what is next to them: the tick in a checked box, the dot in a radio button, the arrow showing a menu is open, the thumb of a slider.
• Hover treatments need nothing extra. W3C: because the pointer itself shows where it is, extra author-supplied hover effects "do not themselves need to contrast 3:1 against the background", and its example is a pale gray circle behind a checkbox on hover.
• Hue alone is a different failure. W3C's example is a five-star rating with black outlines where the chosen stars differ from the rest only by a yellow fill instead of white. That fails 1.4.1 Use of Color. A version using only pale yellow stars on white (1.2:1) fails 1.4.11.
• Error state: W3C's page does not discuss error states, so this is our reading. When a red border or icon is the only sign that a field is invalid, it is the visual information that identifies the state and needs 3:1 against the page. Red alone, with no text or icon, also raises 1.4.1. An error message in text avoids both questions for the state, but the field's own boundary still has to be visible.

Focus indicators

For custom focus styles, W3C ties 1.4.11 to 2.4.7 Focus Visible: the indicator "must have sufficient contrast against the adjacent background when the component is focused". Where the ring is drawn matters. A ring outside the control is measured against the page color; a ring inside it, against the control's fill; a border that changes color has to contrast with both sides. W3C adds that a thin outside ring can pass 3:1 and still be a poor indicator, and points to the AAA criterion 2.4.13 Focus Appearance, which sets a minimum size.

W3C names the main failure as failure F78, styling outlines and borders so the focus indicator disappears. Two techniques it lists as sufficient for focus are G195, an author-supplied visible focus indicator, and C40, a two-color focus indicator that holds up on any background. One implementation detail is outside WCAG but common: MDN documents that box-shadow is forced to none in forced colors mode, so a focus ring made only from a shadow vanishes for people using a Windows high contrast theme. Draw rings with outline.

W3C's sufficient techniques for the other situations are G207, a 3:1 ratio for icons, G209, sufficient contrast at the boundaries between adjoining colors, and G174, a control that lets users switch to a presentation with sufficient contrast. In our view, fixing the colors directly is usually simpler than adding a switch.

Adjacent colors: what you measure against

"Adjacent colors" is where most measuring mistakes happen. W3C's rules, in plain terms:

• For a control, it means the colors next to the control, not the colors inside it. A white field with a dark border on a white page is measured, border to page.
• Parts that do not interfere are ignored. A drop shadow, or a dark border sitting between a light fill and a dark surround, is "subsumed into the color closest in brightness". In W3C's example an input with a white interior sits on a dark blue surround, and the measurement is white against that blue, not against the silver border.
• For a state indicator inside a component, such as a checkmark, the adjacent color is the component's own fill.
• Fill-only fields are measured by the fill. A white field on a light gray panel with no border is white against the gray. #FFFFFF on #F3F4F6 is 1.10:1, a failure.
• Gradients and images: test the least contrasting area. If it falls under 3:1, ask whether the graphic is still understandable with that area treated as invisible. If it is, it passes. W3C's separate note on gradients also mentions taking the central color of the area; we apply the stricter least-contrasting test from its testing principles.

Real color pairs around the 3:1 line

W3C is as strict here as for text: "computed values should not be rounded (e.g. 2.999:1 would not meet the 3:1 threshold)" (Understanding 1.4.11). It also warns that anti-aliasing can render "particularly thin lines and shapes" in a much fainter color than the CSS says, and that "best practice would be for authors to avoid particularly thin lines and shapes", or to use colors that exceed the requirement. In practice: measure the CSS color, not a screenshot, and prefer a 2px edge to a 1px one when the color is close to the line. The pairs below were computed with the formula and code on our 1.4.3 page.

Our color contrast checker has a "UI components & graphics" target of 3:1 and, when a pair fails, suggests the nearest passing color with the same hue.

Charts, graphs and infographics

Charts are where 1.4.11 produces the most arguments, because "required to understand" depends on how the chart is built. W3C's pie chart examples show the three outcomes:

• Fail: slices carry labels (so the chart is fine for 1.4.1), but to read the proportions you must see the slice edges, and the slices are not 3:1 against each other.
• Not applicable: the slices carry visible labels and values that convey the same information, so the slices are not needed for understanding.
• Pass: sufficient contrast around and between the slices. W3C's fix for a yellow slice was a darker border around it.

For line charts, W3C says the lines need 3:1 against their background but, with little overlap, "they do not need to contrast with each other". Gridlines count too when people need them to read values. In an infographic, each icon and circle is a separate graphical object. Whether labels "convey the same information" is a judgment about your specific chart, which is why no scanner can answer it.

The sturdiest design is also the simplest: label the lines or slices directly, give the values as text, and put the data in a table. Then the colors are decoration for people who can see them, and the criterion has little left to measure. Any of those labels is text and needs 4.5:1 under 1.4.3. Images used for charts also need a text alternative; see WCAG 1.1.1 and our alt text guide.

Failing and passing CSS

An input border

Failing. A 1px hairline at 1.61:1 on a white page, with no label or other cue to where the field is:

input {
  border: 1px solid #cccccc;
}

Passing. A mid-gray border at 4.54:1. A pair as light as #8A8A8A (3.45:1) also passes, and 2px is easier to see than 1px:

input {
  border: 2px solid #767676;
}

A fill-only field on a panel

Failing. White fields on a light gray panel with no border are 1.10:1 against what is around them:

.panel { background: #f3f4f6; }
.panel input {
  background: #ffffff;
  border: 0;
}

Passing. Give the field an edge that reaches 3:1 against the panel. #767676 on #F3F4F6 is 4.13:1, and the white fill stays:

.panel input {
  background: #ffffff;
  border: 2px solid #767676;
}

A custom checkbox

Failing. The border is the only thing that shows the box, at 2.71:1:

.check-box {
  width: 20px;
  height: 20px;
  border: 2px solid #9d9d9d;
}

Passing. A darker border, and a checked state that fills the box with a color that contrasts with the page (5.17:1) and a tick that contrasts with that fill (white on that blue is also 5.17:1):

.check-box {
  width: 20px;
  height: 20px;
  border: 2px solid #767676;
}
.check-input:checked + .check-box {
  background: #2563eb;
  border-color: #2563eb;
  color: #ffffff; /* the tick */
}

A focus ring

Failing, and named by W3C as failure F78. The default indicator is removed and nothing replaces it:

button:focus {
  outline: none;
}

Passing. An author-supplied outline at 6.18:1 against a white page, offset so it sits on the page color and not on the button's fill:

button:focus-visible {
  outline: 2px solid #1a56db;
  outline-offset: 2px;
}

If the same button appears on a dark section, that blue is now measured against the dark color around it. Check each background a component can sit on, or use the two-color approach in C40.

An icon-only button

Failing. A light gray icon at 2.54:1 on white. The accessible name (aria-label) is a separate criterion, 1.1.1 and 4.1.2, and does not rescue the contrast:

.icon {
  color: #9ca3af;
}
/* svg uses fill="currentColor" */

Passing. The same icon at 4.83:1:

.icon {
  color: #6b7280;
}

A toggle switch

Failing. With no border, the off track is 1.47:1 against white, so the control nearly disappears:

.switch-track {
  background: #d1d5db;
}

Passing. A mid-gray track at 4.83:1, with a white thumb that is also 4.83:1 against the track. The on state must hold up too: blue (#2563EB) is 5.17:1 against white:

.switch-track { background: #6b7280; }
.switch-thumb { background: #ffffff; }
input:checked + .switch-track {
  background: #2563eb;
}

A chart line

Failing. A yellow line at 1.32:1 on a white plot area, and an amber one at 2.94:1 that looks acceptable but is under the line:

<polyline stroke="#fde047"
  stroke-width="3" points="..."/>

Passing. A darker amber at 4.92:1, plus a text label on the line itself so color is not the only way to tell series apart:

<polyline stroke="#a16207"
  stroke-width="3" points="..."/>
<text x="210" y="40" fill="#4b5563">
  Returns</text>

The label color #4B5563 is 7.56:1 on white, which satisfies 1.4.3.

How to test WCAG 1.4.11, step by step

This follows the "testing principles" in W3C's Understanding 1.4.11, with the practical details filled in.

1. List every type of component and every graphic that carries information: each input type, button style, checkbox and radio style, toggle, tab, menu arrow, icon button, status icon, chart and infographic. Each distinct style is one test, however many times it repeats.
2. For each, decide what identifies it. A button with a text label is identified by the label, so there is no boundary to measure. A field with only a border is identified by the border. A tick in a checkbox identifies the checked state.
3. Read the specified colors, not screenshot pixels. W3C says to use the colors from the user agent, "or the underlying markup and stylesheets", rather than the non-text elements as they appear on screen. Select the element in your browser's developer tools and run this in the console, where $0 is the selected element:

const s = getComputedStyle($0);
console.log(s.borderTopColor,
  s.borderTopWidth, s.backgroundColor);
console.log(s.outlineColor,
  s.outlineStyle, s.outlineWidth);
console.log(s.boxShadow);

4. Identify the adjacent color. For a control, select its parent and repeat until you reach an opaque background color. For a tick, it is the box's fill. A background of rgba(0, 0, 0, 0) means transparent: keep walking up.
5. Blend transparency first. A border of rgba(0, 0, 0, 0.3) on a tinted panel is not black. Enter it as the "text color" with its opacity in the contrast checker, which blends it over a solid background before measuring.
6. Compute the ratio without rounding and compare it with 3:1. The contrast checker shows the ratio rounded down but decides pass or fail on the exact value.
7. Test every state. In Chrome, open the Styles tab, click :hov and tick :hover, :focus or :active to force a state without the pointer. Then tab through the page with the keyboard and look at each focus indicator. Test checked, selected, expanded and error states by actually setting them.
8. Check graphics and gradients at their weakest point. For charts, measure each series against the background and, where you must tell neighbors apart, against each other. For a gradient, take the least contrasting area and ask whether the graphic is still understandable without it.
9. Repeat for each theme and background. A dark mode, a colored section, a card on a gray panel and a sticky bar are each a different adjacent color.

When something fails, the usual fixes are to darken the border, icon or line; add a border to a fill-only field; add direct labels and a data table to a chart; or add a visible text label so the control does not depend on a faint shape. Our guide to testing website accessibility fits this into a full pass.

Common false positives and false negatives

What GotAlt's tools measure, and what they cannot see

Border, icon and focus colors exist only in rendered CSS, which our site scanner and deep audit do not see: they read the HTML a server sends, and our methodology lists computed contrast and focus visibility among the things they cannot detect. For 1.4.11 that leaves one tool that measures the color pairs you give it, and two that measure text only.

Related criteria and further reading

• 1.4.3 Contrast (Minimum) (AA): 4.5:1 for text, including the labels inside buttons and charts.
• 1.4.1 Use of Color (A): color alone must not carry meaning, which affects status icons, chart series and required-field markers.
• 2.4.7 Focus Visible (AA): a keyboard focus indicator must be visible. 1.4.11 sets how visible a custom one has to be.
• 2.4.13 Focus Appearance (AAA, new in WCAG 2.2): size and contrast requirements for the focus indicator.
• 1.4.6 Contrast (Enhanced) (AAA): the 7:1 text level. There is no higher level for non-text.

Our color contrast guide covers choosing an accessible palette that works for text and non-text together. For every criterion in one place, see WCAG 2.2 criteria explained and the WCAG 2.2 checklist. For the Level A and AA picture on each platform, see our guides for Shopify, WordPress, Wix, Squarespace and Webflow.