1.4.1 Use of Color
- Level A
- Perceivable
- Since WCAG 2.0
Summary
Roughly one in twelve men and a much smaller share of women have some form of colour vision deficiency, and many more people view screens in bright sunlight, on low-quality displays, or with age-related changes to colour perception. For all of them, a red dot next to "unavailable" and a green dot next to "available" look like the same dot. This criterion, at Level A since WCAG 2.0, requires that colour is never the only visual cue: anything colour communicates (a state, an error, a category, a link) must also be communicated some other visual way, such as an icon, a text label, a pattern, a shape, or an underline.
The auditor's mental model is a greyscale thought experiment: mentally (or literally, see below) drain all hue from the screen and ask whether any information just disappeared. If two things that meant something different now look identical, or a prompt you were supposed to notice no longer stands out, colour was carrying the meaning alone and the screen fails. Note what the criterion does not say: it does not ban colour, and it does not measure how strong a colour is. Colour used redundantly, on top of a second cue, is exactly what the criterion wants.
Official wording
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
EN 301 549 mapping
- Web pages
- Clause 9.1.4.1
- Software and native apps
- Clause 11.1.4.1
Clauses 9.1.4.1 (web) and 11.1.4.1 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.
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
The fastest check is a real greyscale pass. In Chrome DevTools, open the Rendering panel and set "Emulate vision deficiencies" to achromatopsia, or use the operating system's greyscale filter. Walk the page and look for meaning that evaporates: status indicators, chart series, highlighted rows, validation states, and anything the copy describes by colour.
Links deserve their own pass because the W3C position is more nuanced than "underline everything". A link inside body text that differs from the surrounding prose by colour alone is the classic failure. The W3C accepts two routes to a pass: give the link a second visual cue that is always present (an underline is the usual one), or ensure the link colour has at least a 3:1 contrast ratio against the surrounding body text AND add a non-colour cue (such as an underline) that appears on both hover and focus. That second route is technically sufficient under W3C guidance, but be honest in your report about its weakness: it forces users to sweep the page with a pointer or tab through it to discover where the links are, so treat it as a minimal pass and recommend persistent underlines. A link below 3:1 against the body text with no other cue fails outright. Navigation menus and other contexts where links are obviously links from their position are not the concern; prose is.
Then work through the recurring failure spots: required fields marked only by a red label or red asterisk colour (the asterisk character itself is a non-colour cue; a label that merely turns red is not), form errors indicated only by a red border, charts whose series are distinguishable only by hue against a colour-keyed legend (fix with direct labels, distinct markers, dashed or patterned lines, or textured fills), calendar or seat-map cells where booked and free differ only in fill colour, and diff or spreadsheet views where added and removed rows differ only by background tint.
iOS
The criterion applies to native apps exactly as it does to web pages, and it applies unchanged to software under the European standard, so grade iOS screens to the same bar. The quick check is the built-in greyscale mode: Settings, Accessibility, Display and Text Size, Colour Filters, Greyscale (add it to the Accessibility Shortcut so you can triple-click the side button while walking the app).
With greyscale on, review each screen for: form validation that only tints the field or label red, status badges and dots in lists, charts (the default hue-based series palettes fail on their own; look for symbols, direct labels, or patterned styles), segmented controls and tab bars whose selected item differs only by tint, and text that has been colour-coded to carry meaning (amounts in red versus green, for example). Native controls mostly help you: a UISwitch conveys its state by thumb position as well as colour, so it passes; a custom toggle that only changes fill colour does not. iOS also exposes a user setting to "Differentiate Without Colour", which well-built apps respond to by adding shapes and symbols. Responding to that setting is good practice worth crediting, but the default presentation must already satisfy the criterion; a redundant cue that only appears behind a user setting is not a pass.
Android
The same requirement, unchanged for software under the European standard. For the quick check, use the system greyscale: on most devices it is available under Settings, Accessibility, Colour and Motion (or Colour Correction), Greyscale, and on any device via Developer Options, Simulate Colour Space, Monochromacy. Bedtime or Wind Down modes that grey the screen work in a pinch.
Then sweep the usual suspects: text field error states (a Material text field that shows error supporting text and an error icon passes; a custom field that only recolours its outline fails), selected chips or filter states indicated only by tint, availability and status colours in list rows, charts with hue-only series, and any red/green colour coding of values. Watch for meaning delivered purely through theme colour roles: tinting a row's background with an "error" container colour communicates nothing once hue is gone unless an icon or label repeats the message. As on iOS, the standard switch component signals state by thumb position and passes; custom drawables that only swap colour do not.
Pass and fail examples
Passes:
- A status column showing a green circle with a tick for "online" and a red circle with a cross for "offline": the icon shapes carry the meaning without the colour.
- Required form fields marked with an asterisk and a "required" hint in the label text; the asterisk may also be red, since the colour is redundant.
- Links in body text that are underlined as well as blue.
- Links in body text with no resting underline, but at least 3:1 contrast against the surrounding text and an underline that appears on hover and on keyboard focus: sufficient under W3C guidance, though worth a recommendation to make the underline persistent.
- A line chart where each series has a distinct marker shape and a direct label at the line's end, in addition to its colour.
- An error summary that names the failed fields in text, with each field also showing an error icon and message, all additionally styled red.
Fails:
- Red and green dots as the only difference between "unavailable" and "available".
- A pie or line chart whose series are distinguished only by hue, keyed to a colour-swatch legend.
- "Required fields are shown in red" with nothing but label colour marking them.
- Links styled identically to body text except for colour, with no underline and no qualifying contrast-plus-hover/focus cue.
- A calendar where booked and free dates differ only in cell background colour.
- Form validation that turns the field border red with no icon, no message, and no other change.
- A custom toggle or selected tab indicated only by a tint change.
Not a fail under this criterion:
- Red error text that is hard to read against the background: that is a contrast strength problem, file it under SC 1.4.3 Contrast (Minimum).
- A status icon or input border too faint to make out: file under SC 1.4.11 Non-text Contrast. A red-only error state can satisfy both contrast criteria and still fail 1.4.1; the reverse is also true.
- An instruction that says "press the green button to continue": instructions that reference colour belong to SC 1.3.3 Sensory Characteristics, not here.
- Decorative colour that carries no information: brand accents, illustration palettes, and backgrounds with no meaning attached are out of scope.
- An error state whose icon and message are visible but not exposed to assistive technology: the visual side passes 1.4.1; the programmatic gap is a different finding (SC 1.3.1 Info and Relationships or SC 4.1.2 Name, Role, Value).
Commonly confused with
- SC 1.4.3 Contrast (Minimum). 1.4.3 measures how strong text colours are against their background; 1.4.1 asks whether colour is carrying meaning alone. They are independent: a vivid, high-contrast red label can fail 1.4.1, and a pale but redundant colour cue can pass it. Never close a colour-only finding because "the contrast is fine".
- SC 1.4.11 Non-text Contrast. The same distinction for components and graphics. "I cannot see the indicator" is 1.4.11; "the indicator means nothing without its hue" is 1.4.1. Dense dashboards often earn both findings on the same widget, with separate evidence.
- SC 1.3.3 Sensory Characteristics. When the interface itself relies on colour, that is 1.4.1. When the words rely on colour ("click the green button", "fields in red are mandatory"), that is 1.3.3. A screen can fail both: red-only required fields plus an instruction describing them by colour.
- SC 1.3.1 Info and Relationships. 1.4.1 is satisfied by any visible non-colour cue, but visible is not the same as programmatic. An error icon fixes the 1.4.1 finding while the field may still lack a programmatically exposed error state; grade the two separately rather than folding them into one.
How AUDITSU tests this
AUDITSU's audit walkthrough puts use of colour into the visual checks for every screen you review. The walkthrough prompts you to run the screen in greyscale (or apply the greyscale thought experiment), then asks the specific questions where this criterion actually fails in the field: are links in prose distinguishable without colour, do form errors and required markers survive without hue, are chart series, statuses, and selected states carried by more than tint. Each question records a pass, fail, or not applicable result per screen, with your evidence (typically a greyscale screenshot) attached, so the finding lands in the report tied to the exact screen and element.
Because the criterion applies unchanged to web content and software under the European standard, the walkthrough grades websites, iOS apps, and Android apps against the same bar, and the criterion appears in EAA-scoped audits without modification.
For the full guided workflow, see the audit platform.