1.4.11 Non-text Contrast
- Level AA
- Perceivable
- Since WCAG 2.1
Summary
Text contrast gets most of the attention, but the parts of an interface you interact with are just as easy to lose: a pale input border, a faint focus ring, a checkbox tick you cannot make out, a chart whose segments blur into one another. This criterion, introduced in WCAG 2.1 at Level AA, requires a contrast ratio of at least 3:1 for two things: the visual information needed to identify a user interface component and its state, and the parts of a graphic needed to understand the content.
The subtle point, and the source of most disputes in an audit, is that only the identifying information needs the contrast, not the whole component. A button does not fail because its background is a soft grey; it fails if nothing about it (border, background, text, icon) lets you tell it is a control at 3:1 against what surrounds it. The comparison is always against adjacent colours: whatever sits immediately next to the pixel you are grading, which is usually the page or card background but can be another part of the same component. Inactive (disabled) components are exempt, as are components whose appearance comes entirely from the browser or operating system with no author styling.
Official wording
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.
EN 301 549 mapping
- Web pages
- Clause 9.1.4.11
- Software and native apps
- Clause 11.1.4.11
Clauses 9.1.4.11 (web) and 11.1.4.11 (software) apply this criterion unchanged, so user interface components and graphics in native apps need the same 3:1 contrast as on the web.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Start by asking what visually identifies each component. For a text input, that is usually the border, but it does not have to be: if the field has a visible label and its own contrasting text or a distinct background, the boundary may not be "required to identify" it. Grade the cue users actually rely on. Where the border is the only signal that a field exists (a minimalist form with placeholder text and no visible label), that border must reach 3:1 against the background.
States need the same treatment as identity. A checkbox must be distinguishable as a checkbox, and its checked state must be distinguishable from unchecked: grade the tick or fill against the colour it sits on. Focus indicators fall here too: whether an indicator exists is a different criterion, but the indicator you provide must reach 3:1 against the adjacent colours. Icons that are the only label for a control (a magnifying glass with no "Search" text, a hamburger menu) carry the whole identification burden, so the icon itself must hit 3:1. Graphics follow the same logic: chart segments, line strokes, and map markers that must be told apart to understand the data need 3:1 between each other or against their background, unless each is directly labelled with text.
Two exemptions do real work. Unstyled native controls (a default browser checkbox or select arrow) are the user agent's design, not yours. Disabled controls are exempt entirely. The moment you restyle a native control, its contrast becomes your responsibility.
For sampling, use AUDITSU's colour contrast checker: its eyedropper lets you pick the border, icon, or segment colour straight off the screen and read the ratio against the adjacent colour immediately.
iOS
The user agent exception applies to system-rendered controls only while they remain unmodified. A stock UISwitch or system button is Apple's design; the moment you apply a tint colour, custom background, or your own drawing, you are the author and the 3:1 requirement applies to what you produced. Tinting is the trap: a brand-coloured toggle whose "on" state does not reach 3:1 against its track or background is an author decision, not a system default.
Audit the recurring hotspots: toggle on and off states, tab bar icons in both selected and unselected tints, segmented controls, and text field borders in custom designs (many iOS apps draw their own hairline borders well below 3:1). Take screenshots on device and sample the actual rendered pixels rather than trusting the design file, since vibrancy and blur effects shift colours. Grade dark mode as a separate pass: a border that clears 3:1 on a white background routinely fails against a dark elevated surface, and every state needs checking in both appearances.
Android
Material components carry sensible contrast defaults, but custom theming overrides them, and a themed component is author-modified, so the exception is gone. Check outlined text field borders against the surface colour, the checked and unchecked states of checkboxes, radio buttons, and switches (the thumb and track in the "on" state against the surrounding surface), and selection indicators such as the active tab underline or navigation bar highlight.
Icon-only buttons deserve particular attention: toolbar actions, floating action button glyphs, and list row icons are frequently rendered in a mid-grey that sits well under 3:1 on light surfaces. Grade every theme users can actually get: light and dark at minimum, and where the app supports dynamic colour, spot-check the derived palettes too, since a wallpaper-driven scheme can pull a passing state colour below 3:1 without any code change. Layout Inspector and on-device screenshots give you real pixels to sample.
Pass and fail examples
Passes:
- A focus ring at 3:1 or better against both the component it wraps and the page background, so it stays visible along its whole length.
- An icon-only search button whose glyph measures 4.6:1 against the header background: the sole identifying cue clears the threshold comfortably.
- A text input with a visible label, dark entered text, and a light grey #cccccc border on white: the border alone is 1.6:1, but the W3C's understanding material states that where visible content already identifies the control's presence, "a border or other indication... is not required". The border is not the identifying information here, so it passes; note the reasoning in the finding.
- A pie chart whose slices are pale and close in colour but each carries a direct text label with a leader line: the colours are no longer required to understand the data.
- A greyed-out submit button at 1.4:1: inactive components are exempt.
Fails:
- The same #cccccc border on white (1.6:1) on a field with no visible label and only placeholder text: the border is the only thing identifying the field, and it does not reach 3:1.
- A hamburger menu icon at 2.3:1 against the header: the sole identifier of the control is below threshold.
- A custom checkbox whose checked state is a pale tick at 1.9:1 against its fill: the state cannot be perceived.
- A dotted focus indicator at 1.5:1 against the background: an indicator exists, but its contrast fails here.
- A line chart with three series distinguished only by colours below 3:1 against each other, with no direct labels or pattern differences.
Not a fail under this criterion:
- Body text or link text at low contrast: text is graded elsewhere, at a stricter ratio.
- A component that relies on colour alone to convey meaning but where every colour has strong contrast: that is a different criterion about colour as the sole carrier of information.
Commonly confused with
- 1.4.3 Contrast (Minimum). Text and images of text need 4.5:1 (3:1 for large text). Icons, borders, focus rings, and graphical parts are graded here at 3:1. Citing 4.5:1 against an icon is the most common misapplication; the two criteria cover different pixels at different thresholds.
- 2.4.7 Focus Visible. That criterion asks whether a focus indicator exists at all. Whether the indicator has enough contrast to be seen lands here. A page can pass 2.4.7 with an indicator that fails 1.4.11, and both findings belong in the report.
- 1.4.1 Use of Color. That criterion forbids colour being the only way information is conveyed, regardless of contrast. This one measures how strong the colours are. A red-versus-green status pair can pass 1.4.11 with excellent contrast and still fail 1.4.1 because nothing but hue distinguishes the states.
- 2.5.8 Target Size (Minimum). "I can barely see this control" is a contrast finding; "I can barely hit it" is a target size finding. Small, faint icon buttons often earn both, but they are separate criteria with separate evidence.
How AUDITSU tests this
AUDITSU's audit walkthrough includes non-text contrast in its visual checks for every screen you review. The walkthrough prompts you to identify what visually marks out each component and its states (borders, icons, focus indicators, checked and selected states) and to sample the suspect ones against their adjacent colours before grading, so you measure the identifying cue rather than the whole component. Each check records a pass, fail, or not applicable result per screen with the evidence attached, and dark mode variants are graded as their own screens.
For the full guided workflow, see the audit platform.