WCAG 1.4.1: Use of Color
A red border says “error”, a green dot says “online”, a blue word says “link” — until you cannot tell red from green, or the page is printed in grayscale. This criterion asks that color is never the only way information, state, or interactivity is signalled. Keep the color, but always add a second cue: text, an icon, a shape, or a pattern.
The success criterion, in full
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Note the single word that does all the work: only. The criterion does not forbid color — color is one of the most useful tools in an interface. It forbids color being the sole visual channel for meaning. And note what it is not about: this is not a contrast requirement (that is 1.4.3 Contrast (Minimum)), it is about color as the only differentiator.
Who this helps
Color perception varies enormously across the population and across viewing conditions. A second, non-color cue reaches everyone that color alone leaves out:
People with color vision deficiency
Around 1 in 12 men and 1 in 200 women cannot reliably distinguish certain colors — red/green being the most common collision. Color-coded states and legends simply merge together for them.
Low vision users
Reduced sensitivity to color and contrast means subtle hue differences that designers rely on may be invisible. A shape or label difference is far easier to perceive.
Users in bright or poor lighting
Sunlight on a phone screen, a washed-out projector, or a failing monitor can flatten colors for anyone. Non-color cues stay legible when hues wash out.
People on monochrome or e-ink displays
E-readers, some kiosks, and grayscale print reproduce everything in shades of gray, erasing any information that lived only in color.
Screen reader users
Color is not announced at all. If 'required' is only communicated by a red label, or an error only by red text, that meaning is completely absent from the audio output.
Situational cases
Night-mode filters, blue-light reducers, and 'reader' views alter or remove color. A cue that also uses text or an icon survives all of these transformations.
What the requirement covers
The criterion names four distinct situations where color must not stand alone. It helps to check each one deliberately, because a page can handle one well and fail another:
- Conveying information. Any status, category, or value signalled by color — 'sold out' items greyed only by hue, a color-coded calendar, a red/green profit-and-loss column. Add text, an icon, or a label.
- Indicating an action. Signalling that something is clickable or actionable purely by color, most commonly links inside body text distinguished only by being blue. Underline them, or add another cue.
- Prompting a response. Asking the user to act using color alone — 'fields in red are required', 'press the green button to continue'. Name the field as required; label the button by what it does.
- Distinguishing a visual element. Telling elements apart by color only — series in a chart, segments of a diagram, the selected tab shown by a colored highlight with no other marker. Add patterns, shapes, borders, or labels.
What 1.4.1 does not require
It does not tell you to stop using color, and it does not set a contrast ratio — that is the job of 1.4.3 Contrast (Minimum). A useful shortcut is the grayscale test: imagine the interface with all color removed. Every state, every link, every data series, and every required field should still be identifiable from what remains. If something disappears, that is exactly where 1.4.1 is failing.
Pass and fail examples
✓ Passes 1.4.1
- In-text links that are underlined as well as colored.
- Form errors shown with a red border plus an icon and a text message.
- Required fields marked with an asterisk and the word “required”, not just red.
- A chart whose series use distinct patterns or direct labels as well as color.
- A status pill that reads “Active” with a check icon, not just a green dot.
✗ Fails 1.4.1
- Links in a paragraph distinguished from body text by color only, no underline.
- A form field turning red on error with no icon or message.
- “Required fields are shown in red” as the only marker of required state.
- A pie chart with a red/green legend and no patterns or labels.
- A green dot vs. a red dot as the only indicator of online/offline status.
Code examples
Links in body text
The safest fix is simply to keep in-text links underlined. If you remove the underline, the link needs a 3:1 contrast against the surrounding text and a non-color cue on hover and focus.
<!-- ✗ Distinguished from body text by color alone -->
<p>Read our <a href="/refunds" style="color:#2563eb;
text-decoration:none">refund policy</a> before buying.</p>
<!-- ✓ Underlined: obvious without relying on color -->
<p>Read our <a href="/refunds">refund policy</a> before buying.</p>
/* ✓ Or keep it underline-free but add a non-color cue on
both hover and focus (and ensure 3:1 vs body text) */
a.inline { color: #1d4ed8; text-decoration: none; }
a.inline:hover,
a.inline:focus { text-decoration: underline; }Form errors and required fields
Pair the red styling with an icon and a real text message, and mark required fields with more than color.
<!-- ✗ Error and required state signalled by color only -->
<label style="color:#dc2626">Email</label>
<input class="border-red" value="invalid-email">
<!-- ✓ Color + icon + text message + explicit required marker -->
<label for="email">
Email <span aria-hidden="true">*</span>
<span class="sr-only">(required)</span>
</label>
<input id="email" type="email" required aria-invalid="true"
aria-describedby="email-error" class="border-red">
<p id="email-error" role="alert">
<svg aria-hidden="true" focusable="false"><!-- ✗ icon --></svg>
Error: Please enter a valid email address
</p>Charts, legends, and status
Give each series a second channel — a pattern, a shape, or a direct label — and describe status in text, not just a colored dot.
<!-- ✗ Status conveyed only by the color of a dot -->
<span class="dot" style="background:#16a34a"></span>
<!-- ✓ Color + icon + text: understandable in grayscale -->
<span class="status">
<svg aria-hidden="true" focusable="false"><!-- ✓ check --></svg>
Active
</span>
<!-- ✓ Legend entries carry a pattern name + label, not hue alone -->
<ul class="legend">
<li><span class="swatch striped"></span> Product A (striped)</li>
<li><span class="swatch solid"></span> Product B (solid)</li>
<li><span class="swatch dotted"></span> Product C (dotted)</li>
</ul>Interactive Demo
Each pair below shows the same information twice — once relying on color alone, once with an added non-color cue. Toggle the grayscale simulation to strip out color the way a color-blind or monochrome viewer experiences it, and watch the left-hand examples become ambiguous while the right-hand ones stay clear.
Toggle a grayscale filter to strip away color and see which examples survive without it.
Links in body text
Color only
Review our refund policy before you buy.
Color + underline
Review our refund policy before you buy.
Form validation
Color only
Please enter a valid email address
Color + icon + text
Error: Please enter a valid email address
Required fields
Color only
Required fields are shown in red.
Color + asterisk + text
Chart legend and status
Color only
Color + patterns + labels
Common failures
- In-text links distinguished from surrounding text by color alone, with the underline removed and no other cue on hover or focus.
- Form validation that turns a field red (or green) with no icon and no text message explaining the error or success.
- Marking required fields only by coloring their label red, with no asterisk, 'required' text, or other indicator.
- Charts, graphs, and pie segments identified only by a color-coded legend — especially red/green combinations that collide for color-blind users.
- Status and state shown by color alone: a green vs. red dot, a highlighted-only selected tab, a colored calendar with no labels.
- 'Click the green button' or 'entries in red are overdue' style instructions that reference color as the only identifier.
- Confusing 1.4.1 with contrast: adding a second cue but assuming it also satisfies 1.4.3, or fixing contrast and thinking color-only meaning is now acceptable.
- Selected or active states in a UI (toggles, segmented controls, map pins) shown only by a color change with no icon, border, or label difference.
How to test for 1.4.1
- 1
Run the grayscale test
View the page in grayscale — via your OS color filters, a browser extension, or a print-to-grayscale preview. Anything whose meaning vanishes when color is removed (links, states, chart series, required markers) is a 1.4.1 failure you can see instantly.
- 2
Simulate color vision deficiency
Use a color-blindness simulator (Chrome DevTools Rendering panel, the Stark or Colorblindly extensions, or Firefox's accessibility tools) to view the page as deuteranopia, protanopia, and tritanopia. Watch specifically for red/green pairs in charts, status, and validation collapsing into one shade.
- 3
Inspect every link, control, and state
For each in-text link, form field, status indicator, tab, and chart series, ask: is there any cue besides color? An underline, icon, shape, pattern, border, or text label. If color is the only differentiator, it fails.
- 4
Check instructions and legends for color words
Search the content for phrases like 'in red', 'the green button', 'shown in blue'. Each is a sign that color is being used as the sole reference; confirm the same item is also identifiable another way.
- 5
Verify hover and focus cues on underline-free links
If you have chosen to remove link underlines, confirm the non-color cue appears on BOTH mouse hover and keyboard focus, and that the link contrasts at least 3:1 with the surrounding body text.
- 6
Remember automated tools only go so far
Scanners like axe and WAVE flag some color-only risks but cannot judge whether a second cue actually conveys the meaning — this criterion needs human review of each color-coded element in context.
For a structured audit, work through the full WCAG 2.2 checklist.
Related Success Criteria
Audio that plays automatically can be paused, stopped, or controlled.
Text has a contrast ratio of at least 4.5:1 (3:1 for large text).
Text can be resized up to 200% without loss of content or functionality.
Text is used instead of images of text, except for customizable or essential images.
Text has a contrast ratio of at least 7:1 (4.5:1 for large text).
Frequently asked questions
What does WCAG 1.4.1 Use of Color require?
It requires that color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. In plain terms: you can use color freely, but any meaning carried by color must also be available through some other visual cue — text, an icon, a shape, a pattern, underlining, or position. It is a Level A success criterion under the Perceivable principle (guideline 1.4 Distinguishable) and has been part of WCAG since version 2.0.
Is 1.4.1 about color contrast?
No — this is the most common misunderstanding. 1.4.1 is about color as the sole differentiator of meaning, not about how light or dark two colors are. Contrast ratios are governed by a separate criterion, 1.4.3 Contrast (Minimum) at Level AA. You can pass 1.4.1 with low-contrast colors and fail 1.4.3, or vice versa. A quick mental test for 1.4.1: if the whole page were printed in black and white, would every piece of information, every state, and every control still be understandable? If yes, you pass 1.4.1.
Why do links in body text often fail 1.4.1?
A link that sits inside a paragraph and is distinguished from the surrounding text only by its color relies on color alone to signal that it is clickable — a color-blind or low-vision reader may not notice it at all. The most robust fix is to underline in-text links. If you must remove the underline, WCAG's guidance is that the link text needs at least a 3:1 contrast ratio against the surrounding body text AND an additional non-color cue (such as an underline) that appears on both hover and keyboard focus. Underlining by default is far simpler and more reliable.
How do I make form validation pass 1.4.1?
Do not signal errors or success with color alone. A red border or red text is fine as one cue, but pair it with an icon (an X or warning triangle for errors, a check for success) and, most importantly, a clear text message such as 'Error: Please enter a valid email address'. The text is what carries the meaning for screen reader users and for anyone who cannot distinguish the color. Mark required fields with an asterisk plus the word 'required' or a visible note, not just red coloring.
How do I make charts and graphs accessible under 1.4.1?
Charts frequently rely on a color-coded legend, which fails for color-blind users when several series share similar hues (red and green are a classic collision). Add a second channel: distinct patterns or textures for each series, direct labels placed on or next to the data, different marker shapes for line charts, or a data table that states the underlying values in text. The goal is that a reader who cannot tell the colors apart can still map each data point to its series.
Who benefits from meeting 1.4.1?
Roughly 1 in 12 men and 1 in 200 women have some form of color vision deficiency, so color-only cues exclude millions of people. But the benefit is broader: users with low vision, people using monochrome or e-ink displays, anyone viewing a screen in bright sunlight or through a failing projector, and users of print-to-grayscale all rely on non-color cues. Providing a second visual channel makes interfaces clearer and more robust for everyone, not only people with a diagnosed deficiency.