WCAG 1.4.11: Non-text Contrast
Text is not the only thing on a page that has to be visible. The borders, states, focus rings, and meaningful graphics that make an interface usable must reach at least 3:1 contrast against their surroundings. A field nobody can see the edge of, a toggle whose on and off states look identical, or a chart whose bars blur together all fail this Level AA criterion.
The success criterion, in full
The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s): User Interface Components — visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author; Graphical Objects — parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
Why non-text contrast matters
People with low vision, age-related sight loss, or color vision deficiencies rely on contrast to perceive structure. When the boundary of a control fades into the background, a user cannot tell where a button ends, whether a field is empty or filled, or which option in a group is selected. The information is on the screen, but it is invisible to a large share of users — and to anyone on a dim laptop screen in bright sunlight.
The trend toward minimal, "flat" interfaces made this worse: hairline borders, ghost buttons with no fill, light-grey placeholder-only fields, and pastel chart palettes all look clean in a designer's high-end monitor and disappear everywhere else. 1.4.11 is the floor that keeps an interface perceivable, and it is consistently one of the most commonly failed Level AA criteria in real audits.
What 1.4.11 actually requires
The criterion has three testable ideas. Meet them and your interface chrome stays perceivable.
1. User interface components need 3:1 contrast
The visual cues that identify a control and its state must stand out.
Any visual information required to identify a user interface component, and the different states of that component, must have a contrast ratio of at least 3:1 against adjacent colors. That includes the border of a text input, the outline of a button, the checked vs unchecked state of a checkbox, the on/off position of a toggle, and the focus indicator. If the only thing telling the user 'this is a field' is a 1.5:1 grey hairline, it fails.
2. Graphical objects need 3:1 contrast
The parts of a graphic you actually need to understand it must be perceivable.
Parts of graphics required to understand the content must also reach 3:1 against adjacent colors. Think of the line in a line chart, the slices of a pie chart, a meaningful icon (a magnifying glass that is the only label on a search button), or a required arrow in a diagram. Purely decorative graphics that carry no information are exempt.
3. Contrast is measured against what sits next to it
Adjacent colors, not just the page background.
The 3:1 ratio is calculated between the non-text element and the colors immediately adjacent to it. A button border is measured against both the button fill on one side and the page background on the other; it must hit 3:1 on at least one of those edges so the boundary is perceivable. A white icon on a mid-blue button is measured against that blue, not against the white page behind the button.
The number to remember: 3:1. Unlike text, which needs 4.5:1 for normal sizes under 1.4.3 Contrast (Minimum), every non-text element this criterion covers shares the same single threshold of 3:1 against adjacent colors.
User interface components and states
This is the half of 1.4.11 that catches most teams out. You do not have to outline everything — but where a visual cue is the only thing identifying a control or its state, that cue must reach 3:1.
Field & button boundaries
If the only thing telling the user 'this is an input' is its border, that border needs 3:1 against the page. A button identified only by its fill needs that fill to reach 3:1 against the background.
Selected vs unselected states
The checked state of a checkbox, the on position of a toggle, the active tab, or the selected radio button must differ from the unselected state by at least 3:1 — color alone at low contrast is not enough.
Focus indicators
A focus ring is visual information identifying which element has focus, so it falls under 1.4.11 at 3:1. This dovetails with 2.4.7 Focus Visible and the WCAG 2.2 focus criteria.
Required graphical controls
An icon-only button (a hamburger menu, a search magnifier, a close ✕) relies on its glyph to be identified. That glyph must reach 3:1 against its background.
Important nuance: if a control has more than one cue, only the cue you depend on has to pass. A button with a clear 4.5:1 text label and a faint border can still pass, because the text already identifies it. But a ghost button whose only boundary is a 1.5:1 outline fails — there is no other cue to fall back on.
Graphical objects
The second half covers the parts of a graphic you genuinely need in order to understand it. The test question is always: if this part were not perceivable, would the user miss information? If yes, it needs 3:1.
- Data visualisation: the line in a line chart, the bars in a bar chart, and the slices of a pie chart must each reach 3:1 against the background and, where they meet, against each other.
- Meaningful icons: an icon that conveys information (a warning triangle, a status dot, a required-field asterisk) needs 3:1; a purely decorative flourish does not.
- Diagram parts: arrows, connectors, and labelled regions that carry meaning in a flow chart or wiring diagram must be perceivable at 3:1.
- Map and infographic keys: any colored element a legend refers to has to be distinguishable, which in practice means 3:1 plus a non-color cue for color-blind users.
Contrast alone is not the whole story for charts: because some users cannot distinguish hues, combine 3:1 contrast with a second channel — patterns, direct labels, or distinct shapes — to also satisfy 1.4.1 Use of Color.
The exceptions
1.4.11 has a clear set of carve-outs. Knowing them stops you from over-engineering — and from wrongly flagging conformant designs.
- Inactive (disabled) components — a greyed-out button or field that cannot be used is exempt, because its low contrast also signals that it is unavailable.
- Appearance determined by the browser — if you have not styled a control and it relies on the user agent's default rendering, the author is not responsible for its contrast.
- Logos and brand names — a logo's contrast is whatever the brand uses; it is not held to 3:1.
- Essential presentation — when a specific color or low-contrast presentation is essential to the information (for example, a screenshot showing exactly what a low-contrast UI looks like, or a heatmap where the gradient is the data).
- Decorative graphics — images and graphic parts that convey no information and are not needed to understand the content.
Code examples
A text input with a perceivable boundary
The most common 1.4.11 failure is an input whose border is too faint. Pick a border color that reaches 3:1 against the field background — and never identify a field by placeholder text alone.
/* #767676 on white is ~4.5:1 — comfortably past the
3:1 floor for a UI boundary. #d1d5db (~1.5:1) would fail. */
.field {
border: 1px solid #767676; /* perceivable edge */
border-radius: 6px;
padding: 0.5rem 0.75rem;
}
/* State change must also clear 3:1 against the resting state */
.field:focus-visible {
outline: 2px solid #1d4ed8; /* >= 3:1 against the page */
outline-offset: 2px;
}A toggle whose states are distinguishable
Off and on must differ by at least 3:1, and the difference should not be carried by color alone — here the knob also moves position.
/* Off: light track. On: a track color that is >= 3:1
different from the off state AND >= 3:1 vs the page. */
.toggle { background: #6b7280; } /* off */
.toggle[aria-checked="true"] { background: #1d4ed8; } /* on */
/* Position is a second, non-color cue (helps 1.4.1 too) */
.toggle .knob { transform: translateX(0); }
.toggle[aria-checked="true"] .knob { transform: translateX(100%); }An icon-only button
The glyph must reach 3:1 against the button background, and the button still needs an accessible name for screen readers (4.1.2 Name, Role, Value).
<button type="button" aria-label="Search" class="icon-btn">
<svg aria-hidden="true" focusable="false" width="20" height="20">
<!-- stroke/fill must be >= 3:1 against the button bg -->
<use href="#icon-search" />
</svg>
</button>
/* white glyph on #1d4ed8 = ~8.6:1 — passes easily */
.icon-btn { background: #1d4ed8; color: #ffffff; }Common mistakes
- Hairline form fields outlined with a 1px light-grey (#e5e7eb / #d1d5db) border that sits well below 3:1 against white.
- Placeholder-only inputs with no visible boundary, so the user cannot tell a field is even there.
- Ghost / outline buttons whose only identifying cue is a faint border that fails 3:1.
- Toggles and checkboxes where the on and off states differ by a subtle pastel that does not reach 3:1.
- Focus indicators that are present but too low-contrast — visible to 2.4.7 in theory, failing 1.4.11 in practice.
- Chart palettes of soft pastels where neighbouring bars or lines blur into each other and into the background.
- Disabled-looking but actually-active controls — relying on the disabled exemption while the control is still operable.
- Measuring contrast against the page background when the element actually sits on a colored card or button, giving a misleading pass or fail.
How to test for 1.4.11
- 1
Inventory the non-text elements
List every control boundary, state cue, focus indicator, icon, and meaningful graphic on the screen. These are the things 1.4.11 applies to — text is handled separately by 1.4.3.
- 2
Eyedropper each element and its neighbour
Sample the element color and the color immediately adjacent to it (the fill on one side, the background on the other). A border on a card is measured against the card, not the page behind it.
- 3
Confirm 3:1 with a contrast checker
Drop both colors into a contrast checker and verify the ratio is at least 3:1. Borders need to clear it on at least one adjacent edge so the boundary is perceivable.
- 4
Check every state, not just the default
Toggle checkboxes, switches, tabs, and radios. The selected state must differ from the unselected state by 3:1, and each must be perceivable against the background.
- 5
Apply the exceptions deliberately
Skip disabled controls, unmodified browser-default rendering, logos, and decorative graphics. Everything else has to pass.
Non-text contrast is mostly a manual, eyedropper-driven check — automated scanners rarely judge UI-component and graphic contrast reliably. Build accessible color pairs up front with the Accessible Palette Studio, verify text and UI pairs in the Color Contrast Checker, and scan a live page with the URL Accessibility Auditor.
Related success criteria
1.4.3 Contrast (Minimum) — AA
The sibling criterion for text: 4.5:1 for normal text, 3:1 for large text. 1.4.11 covers everything that is not text, at 3:1.
1.4.1 Use of Color — A
Color must not be the only way information is conveyed. Pair 3:1 contrast with a non-color cue so color-blind users are covered too.
2.4.7 Focus Visible — AA
Requires a visible focus indicator. 1.4.11 adds the contrast bar: that indicator should also reach 3:1 to be genuinely perceivable.
4.1.2 Name, Role, Value — A
Icon-only controls that pass 1.4.11 visually still need an accessible name so screen reader users know what they do.
Browse every criterion in the WCAG Success Criteria hub or work through the full WCAG 2.2 checklist. For deeper color theory, see the Accessible Color Palettes guide and OKLCH & APCA color systems.
Frequently asked questions
What does WCAG 1.4.11 Non-text Contrast require?
WCAG 1.4.11 requires a contrast ratio of at least 3:1 against adjacent colors for two things: (1) the visual information needed to identify user interface components and their states — button and input borders, focus indicators, the checked state of a checkbox, the position of a toggle — and (2) the parts of graphical objects that are required to understand the content, such as the bars in a chart or a meaningful icon. It is a Level AA criterion introduced in WCAG 2.1 and carried into WCAG 2.2, so it applies to most legal and contractual accessibility requirements including the ADA and Section 508.
How is 1.4.11 different from 1.4.3 Contrast (Minimum)?
1.4.3 covers the contrast of text and images of text, requiring 4.5:1 for normal text and 3:1 for large text. 1.4.11 covers everything that is not text: the visual boundaries of controls, their states, focus indicators, and meaningful graphics — all at 3:1. Together they make sure both the words and the interface chrome that surrounds them are perceivable. A page can pass 1.4.3 with perfectly readable text and still fail 1.4.11 because its input fields are outlined with a near-invisible grey border.
Do placeholder-only text fields fail 1.4.11?
They often do — but for two different reasons. If a field has no visible border or background change and is identified only by faint placeholder text, the boundary of the field is not perceivable, which fails 1.4.11 (and the placeholder text itself usually fails 1.4.3). The fix is to give the field a visible boundary at 3:1 against the background, plus a persistent visible label. Never rely on placeholder text alone to identify or label a field.
Does the focus indicator have to meet 3:1 under 1.4.11?
Yes. A focus indicator is visual information required to identify the state of a component (which element currently has keyboard focus), so it falls under 1.4.11 and should reach 3:1 against adjacent colors. This works alongside 2.4.7 Focus Visible (the indicator must exist) and WCAG 2.2's 2.4.11 Focus Not Obscured and 2.4.13 Focus Appearance. Designing a focus ring that is roughly 2px thick at 3:1 contrast satisfies all of them.
Do disabled buttons need to meet 1.4.11?
No. Inactive (disabled) components are explicitly exempt. A greyed-out button that cannot be activated does not have to reach 3:1, and its low contrast actually helps communicate that it is unavailable. Be careful, though: a control that looks disabled but is still operable is a usability and accessibility problem regardless of the exemption.
How do I check non-text contrast?
Use an eyedropper-based contrast checker. Sample the color of the non-text element (a border, an icon, a chart bar) and the color immediately adjacent to it, then confirm the ratio is at least 3:1. Browser DevTools, the WebAIM/TPGi color contrast analyzers, and design-tool plugins all do this. Automated scanners can catch some text contrast issues but rarely judge UI-component and graphic contrast reliably, so non-text contrast is largely a manual, eyedropper-driven check.