WCAG 1.4.11 Non-text Contrast requires that the visual information needed to identify interface controls and their states — and the meaningful parts of graphics — keep a contrast ratio of at least 3:1 against adjacent colors. Unlike the text-contrast rule, it governs buttons, input borders, icons, toggle states, and focus rings.
What 1.4.11 actually requires
The official W3C wording names two categories that must hit 3:1 against adjacent color(s):
- User-interface components — the visual information required to identify a control and its states, except inactive components or appearance supplied by the browser and not changed by the author.
- Graphical objects — the parts of a graphic required to understand the content, except where a particular presentation is essential.
Two things make this criterion easy to misread. First, it is not about text. Text contrast is 1.4.3 Contrast (Minimum) at 4.5:1; 1.4.11 is the 3:1 rule for everything that isn’t text. Second, the threshold is hard — W3C says values “should not be rounded,” so a measured 2.99:1 fails.
Who it affects
This criterion exists for people with moderately low vision who do not use a screen reader and may not use magnification or custom colors. Faint input borders, ghost buttons, and pale focus rings can vanish for them entirely. It also helps people with color vision deficiency, older users with age-related contrast loss, and anyone on a glare-washed phone screen outdoors. Because these users perceive the page visually rather than through assistive technology like screen readers, the only fix is making the pixels themselves distinguishable.
Concrete failures and the fix
These are the patterns that fail 1.4.11 most often, and how we correct them during remediation.
1. Invisible text-input borders
A login form with a #e0e0e0 1px border on a white background measures roughly 1.3:1 — the field is invisible until you click it. If the border is the only thing identifying the input, it must reach 3:1.
/* Fails 1.4.11: ~1.3:1 against white */
.field { border: 1px solid #e0e0e0; }
/* Passes: #767676 on white is ~4.5:1, well over the 3:1 floor */
.field { border: 1px solid #767676; }2. Pale keyboard focus rings
A custom focus style at 2.3:1 fails. Worse, a reset like outline: none with no replacement is failure F78 and also breaks 2.4.7 Focus Visible.
/* Fails: removes the indicator entirely (F78) */
:focus { outline: none; }
/* Passes: a 3:1+ ring (G195) that survives keyboard nav */
:focus-visible { outline: 2px solid #1a73e8; outline-offset: 2px; }W3C accepts a focus ring placed inside, outside, or straddling the component, as long as it reaches 3:1 against whatever color sits next to it. See technique G195 (author-supplied visible focus indicator).
3. Ghost / outline buttons and toggle states
A “secondary” button drawn as a thin pastel outline often lands near 2:1. The boundary that tells a user “this is a control” must meet 3:1 — or give the button a contrasting fill or a contrasting icon instead. The same applies to checkbox borders, the checkmark itself, and the on/off backgrounds of a toggle switch: W3C’s own failing example is a checkbox border at 2.7:1.
Note the nuance: per the understanding doc, if a control already has visible content such as a label or a sufficiently contrasting icon that identifies it as a control, a separate border is not required. A solid-fill button with a clear text label doesn’t also need an outline — but the moment you rely on a faint border to communicate “clickable,” that border is in scope (technique G209, contrast at the boundary between adjoining colors).
4. Meaningful icons and chart parts
A standalone search magnifier or hamburger icon used as a control needs 3:1 (technique G207). In data visualization, the parts a user must distinguish — line-chart strokes against gridlines, adjacent pie slices, plotted points — need 3:1 unless an equivalent value is also given in text or a table. A heat map or a country flag is exempt, because its exact color is the information (“essential”).
How to test for 1.4.11
- Sample the right pixels. Use a color picker (browser DevTools eyedropper, or the WebAIM Contrast Checker) on the boundary color and the adjacent color — for an input, that’s the border vs. the page background, not the text vs. the field.
- Exercise every state. Tab through the page and check the focus ring on each control; hover, check, and press components; inspect selected, expanded, and error states. State indicators are explicitly in scope.
- Apply the 3:1 floor strictly. Anything that rounds up to 3 (like 2.95:1) is a fail.
- Skip the exempt items. Don’t flag disabled controls, browser-default widgets you haven’t restyled, logos, or purely decorative art.
- Judge graphics by meaning. Ask whether a user needs to see a graphic’s detail to understand the content. If yes, it needs 3:1; if the same data is in adjacent text, it’s exempt.
Automated scanners reliably catch text contrast but are weak on 1.4.11 — they can’t always tell a meaningful icon from decoration, or confirm a focus ring is visible. That’s why this checkpoint needs a human pass. A free Curbcut scan surfaces the obvious failures, and our team verifies the judgment calls by hand. For the broader contrast picture, see our color contrast guide.
Why this matters legally
Digital accessibility litigation runs at scale: UsableNet tracked over 4,000 ADA-related digital lawsuits in 2024, with e-commerce the top target (UsableNet 2024 year-end report). The U.S. Department of Justice’s web accessibility guidance states it “does not have a regulation setting out detailed standards,” but points to WCAG as helpful guidance for meeting the ADA’s effective-communication duty — which is why testers and plaintiffs’ experts cite specific success criteria like 1.4.11.
Non-text contrast shows up in demand letters because it is trivial to document: a tester screenshots an invisible focus ring or an unreadable form border and attaches the measured ratio. It’s also among the cheapest issues to fix in code. Notably, the UsableNet report found more than a quarter of sued businesses had an accessibility widget installed — overlay toggles don’t make a default 2:1 button conformant. We are deliberately anti-overlay: instead of bolting on a “high contrast” button users must find, we fix the real CSS so the page passes by default, and we can document it in a VPAT.
This is general information, not legal advice. For your specific exposure, consult a qualified attorney experienced in ADA Title III.
Where 1.4.11 fits
Non-text contrast is one Level AA checkpoint among many in WCAG 2.1 AA. It pairs naturally with 1.4.3 Contrast (Minimum) for text and 2.4.7 Focus Visible for keyboard users, and you can browse the full set in our success-criteria index. When you’d rather not measure every border and focus ring yourself, start with a free scan or have our team handle remediation end to end.