1.4.1 Use of Color

WCAG 2.2 · 1.4.1 A Perceivable

What it requires

Color must never be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing one visual element from another. Whenever color carries meaning, that same meaning must also be available through another cue — text, a shape or icon, a pattern, an underline, or a label — so people who cannot perceive the color difference still get the message.

This is distinct from contrast (1.4.3 / 1.4.11): 1.4.1 is about color as the sole carrier of meaning, regardless of how strong the contrast is.

  • People with color-vision deficiencies (about 1 in 12 men) who cannot reliably distinguish red from green, or other hue pairs.
  • People with low vision who may perceive hue weakly or use high-contrast or inverted display modes that flatten color differences.
  • Screen-reader users, for whom a purely visual color cue is never announced at all.
  • Anyone on a monochrome display, in bright sunlight, or printing in grayscale.

How to detect it

Concrete checks for Use of Color
Check What to look for
Manual scan Required fields, errors, statuses, chart series, and links-in-text shown only by color (e.g. red text, a colored dot, "click the green button").
Grayscale test View the page in grayscale (DevTools rendering emulation or a CVD simulator). Any meaning that disappears fails.
Links in body text Confirm in-text links are distinguishable without color — an underline or other non-color cue, or 3:1 contrast against surrounding text plus a cue on hover/focus.
Screen reader Listen for whether status/validation meaning is announced, not just shown.
Automated tools Largely not reliably caught by axe and similar tools — color-as-meaning needs human judgement. Treat this as a manual criterion.

How to fix it

  1. Find every place color signals meaning (state, category, required, error, link).
  2. Add a redundant non-color cue: text label, icon/shape, pattern, or underline.
  3. For form errors, pair the color with an error message and a marker (e.g. "Required").
  4. For in-text links, keep an underline (or equivalent) so they read as links without color.
  5. Re-test in grayscale to confirm nothing is lost.

For example, mark a validation error with text and an icon, not color alone:

<label for="email">Email</label>
<input id="email" type="email" aria-invalid="true" aria-describedby="email-err">
<p id="email-err" class="field-error">
  <svg aria-hidden="true" focusable="false"><!-- warning icon --></svg>
  Error: enter a valid email address.
</p>

Copy-paste tests

Automated coverage

One axe-core rule maps here: link-in-text-block, which flags links distinguished from surrounding text by colour alone. Run it via the axe DevTools browser extension or axe-core in CI. Automated tools catch only SOME failures of this criterion.

Run this in the browser console

find-colour-only-links.js 
// Read-only: lists in-paragraph links that may rely on colour alone.
const suspects = [...document.querySelectorAll('p a, li a, td a')].filter(a => {
  const s = getComputedStyle(a);
  return s.textDecorationLine === 'none' && parseInt(s.fontWeight, 10) < 600;
});
suspects.forEach(a => a.style.outline = '2px solid red');
console.table(suspects.map(a => ({ text: a.textContent.trim(), href: a.href })));

What to check manually: confirm any colour-coded status (e.g. red "error", green "success") also carries text or an icon, and that outlined links are still distinguishable without colour (underline, bold, or a non-colour cue).