Using Color Alone: What WCAG 1.4.1 Requires and How to Fix It
Color is a great way to reinforce meaning, but it cannot be the only way you convey it. If the only thing telling a user that a word is a link, that a field has an error, or that an order shipped is its color, then anyone who cannot distinguish that color is left out. WCAG Success Criterion 1.4.1 Use of Color (Level A) forbids relying on color alone. The fix is always a second cue alongside the color - an underline, a label, an icon, a pattern. Automated tools catch one slice of this directly: links set apart from body text by color only, which we found on 15 of the 299 home pages we scanned. The rest - error states, required fields, charts - need a human eye.
Color vision varies widely. A meaningful share of people, men especially, cannot reliably tell certain colors apart, and many more are reading in bright sun, on a dimmed screen, or through a cheap display that flattens the palette. For all of them, a difference you can only see in color is no difference at all. This page covers what 1.4.1 asks, the everyday places sites break it, and how to fix each.
What "use of color" means
WCAG Success Criterion 1.4.1, at Level A, states that "color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element." It does not ask you to stop using color. It asks that color always have a backup - a second cue that carries the same meaning for someone who does not perceive the color.
The most common place this breaks is links inside text. When a link is the same except for its color, a reader who cannot see that color difference cannot find the link. WCAG addresses this directly: a 3:1 contrast difference between the link and the surrounding text helps, but "if content relies on the user's ability to accurately perceive or differentiate a particular color an additional visual indicator will be required regardless of the contrast ratio." The reliable answer is an underline.
Where sites rely on color alone
- Links in body text distinguished from the words around them only by color, with no underline. This is the case an automated tool can flag.
- Form errors shown only as a red border or red text, with no message or icon saying what is wrong.
- Required fields marked only by a colored label, with no asterisk or "required" text.
- Status and results conveyed only by color - a green or red dot, a colored row - with no label.
- Charts, graphs, and maps that tell series or regions apart by color only, with no labels, patterns, or direct text.
- Instructions that say "click the green button" or "fields in red are required", which mean nothing to someone who cannot pick out the color.
Who this shuts out
- People with color vision deficiency, who may not distinguish the specific colors a design leans on - red from green most famously, but many combinations.
- People in poor viewing conditions - glare, a dimmed or low-quality screen - where color differences wash out for anyone.
- Screen reader users, when the color is the only signal and there is no text alternative for it to read at all.
How common is it?
The slice we can measure automatically is color-only links in a block of text, and it showed up on 15 of the 299 large US home pages in our State of Web Accessibility 2026 study. That is a floor, not the whole picture: the other uses of color - error states, required-field markers, chart legends, status indicators - are judgments a tool cannot make, so the real rate of color-only meaning across a full site is higher. This is one of the criteria where the manual review matters most.
How to fix it
- Underline links in running text. Inside paragraphs, give links an underline or another clear non-color cue. (A clearly-styled navigation bar is a different context.)
- Pair error and status colors with text or an icon. A red border plus a message and an icon, not a red border alone.
- Mark required fields with more than color - an asterisk with a key, or the word "required".
- Label color-coded charts and maps with text, patterns, or direct labels.
- Rewrite color-only instructions - "click Submit", not "click the green button".
- Review by removing color. View the page in grayscale and check that every link, state, and instruction still reads. Re-scan to catch the automated cases.
What a scan can and cannot tell you
This is the criterion where automated testing helps least, and it is worth being honest about. A tool can flag a link in a block of text that is set apart by color alone, when it can measure the colors. It cannot tell that your form errors are red-only, that your required fields rely on a colored label, or that your chart legend is unreadable in grayscale - because it cannot know what meaning a color is carrying. Use of color is mostly a manual-review criterion. We report the automated slice and say so; the grayscale review is part of a full audit.
Common questions
What does 1.4.1 require? Color must not be the only way you convey meaning - always add a second, non-color cue.
Do links need underlines? Links in running text distinguished only by color do; an underline is the reliable cue.
Why is color-only a problem? People with color vision deficiency, or in poor viewing conditions, miss meaning carried only by color.
Does it fail WCAG? Relying on color alone fails 1.4.1 (Level A).
Check your own site
Run a free check on your home page to catch the color-only links a scanner can see, in about a minute - and remember that error states, required fields, and charts need the grayscale review a full audit includes. See how monitoring keeps these from creeping back in as the design changes. For the data behind this page, read the State of Web Accessibility 2026; its companion is low color contrast, the other half of getting color right.