Skip to main content

1.4.1 Use of Color: what it requires and how to test it

Color can't be the only way you show something: which fields have errors, which link is a link, which line on a chart is which.

Level A · Added in WCAG 2.0 · Last reviewed October 18, 2026

What 1.4.1 requires

Color must not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. If red means "error" or blue means "link", something else has to say so too: text, an icon, an underline, a pattern or a shape. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 1.4.1 (opens in a new tab) [1][2].

Exceptions and scope:

  • It's about color perception specifically. The criterion's note says programmatic access to color coding is covered by 1.3 (Info and Relationships), not here.
  • Lightness can count. W3C's Understanding document notes that if two colors also differ in lightness with a contrast ratio of 3:1 or more, that difference counts as an additional visual distinction. For links in text, W3C's technique G183 uses a contrast ratio of at least 3:1 between the link text and the surrounding text.

Why it matters

People with color vision deficiencies may not be able to tell red from green. People with low vision, monochrome displays or high-contrast modes also lose color cues. A form that marks errors only with a red border, a chart whose legend is only colored dots, or links that are only a slightly different blue all leave some people guessing.

Common failures

Links in a paragraph are dark blue next to near-black text, with no underline.

/* Fails */
p a { color: #1f3a93; text-decoration: none; }  /* body text #222 */

/* Better */
p a { color: #1f3a93; text-decoration: underline; }

Required or invalid fields shown only in red

<!-- Fails -->
<input class="red-border">

<!-- Better -->
<label for="em">Email (required)</label> <input id="em" required aria-describedby="em-err"> <p id="em-err">Enter your email</p>

Chart series identified only by color

A line chart with a colored-dot legend and no labels or patterns.

<!-- Fails -->
<span class="dot green"></span> Revenue

<!-- Better -->
<!-- Label lines directly, vary line style (solid/dashed), or provide a data table -->

Status shown by a colored dot

A green or red dot is the only sign of "online" or "failed".

<!-- Fails -->
<span class="dot red"></span>

<!-- Better -->
<span class="dot red" aria-hidden="true"></span> Failed

Can automated testing check 1.4.1?

Partly. axe-core checks one common case, links in text distinguished only by color. Every other use of color needs a person to spot it.

axe-core 4.13.0 ruleWhat it checks
link-in-text-blocklinks are distinguished from surrounding text in a way that doesn't rely on color (some results need review)

What automation can't decide: Whether color is the only cue for errors, required fields, states, chart series, status indicators or instructions such as "click the green button". Those depend on meaning, not markup.

A clean automated result is never proof that 1.4.1 is met. See why sites pass axe-core but fail real screen reader users.

How to test it by hand

  1. Look at the page in grayscale (an OS filter or a browser devtools emulation of color vision deficiencies works).
  2. Is anything now ambiguous: links, errors, required fields, selected tabs, chart series, status indicators?
  3. Read your instructions for references to color alone ("fields in red", "press the green button").
  4. Check links in body text: underlined (or another non-color cue), or at least 3:1 contrast against the surrounding text, per W3C's technique G183. The link and body colors each still need to meet 1.4.3 against the background.

New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.

How Accessible helps (and where it stops)

Scanning runs link-in-text-block on every URL on a paid plan, and the free page check covers it on one page. Where color carries meaning in forms, it often also means the information isn't in the code, which journeys do notice: an error shown only by a red border is announced as nothing at all (form accessibility).

Where it stops: Accessible can't see your design. Whether color is the only visual cue for charts, states and instructions is a visual review, and a grayscale check takes a few minutes. No automated tool, ours included, can certify that a criterion is met.

Sources

  1. Understanding Success Criterion 1.4.1: Use of Color (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
  2. Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 1.4.1 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
  3. axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
  4. G183: Using a contrast ratio of at least 3:1 to distinguish inline text links from surrounding text (opens in a new tab). W3C Technique. Accessed October 18, 2026.

Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.

Frequently asked questions

Do all links need underlines?

Not under 1.4.1 alone. Links in body text need a non-color cue, such as an underline, or, per W3C's technique G183, a contrast ratio of at least 3:1 with the surrounding text. Links whose position makes them obvious, like navigation menus, don't need underlines.

Is color in charts a failure?

Color is fine; color alone isn't. Add direct labels, patterns, different line styles or a data table so the chart works without color.

Does 1.4.1 cover red error text that also says "Error"?

No. If the text itself says what's wrong, color is an extra cue, not the only one.

Find the links people can't tell are links.

Check a page free, then do a two-minute grayscale review with the steps above.