Color and Non-Color Information

The plain-language idea

This lesson is not about contrast ratios — that's a separate WCAG success criterion, covered elsewhere in this platform. This one is about a different, equally common failure: conveying meaning through color difference alone, with no second signal backing it up.

A meaningful share of users — commonly cited as affecting a notable percentage of men in particular — have some form of color vision deficiency (most often difficulty distinguishing red from green). For these users, two colors that look obviously different to most people can render as nearly identical. If a status dot is "red means down, green means up" and nothing else distinguishes them, that status is genuinely unreadable to part of your audience — not "harder to read," unreadable.

And color vision deficiency isn't even the only case. Bright sunlight washing out a phone screen, a cheap monitor with poor color reproduction, a grayscale print of a page — all of these degrade color differences for users with completely typical vision. Relying on color alone is a single point of failure that a surprising number of ordinary, everyday conditions can trip.

The fix is one consistent pattern: pair color with a second, non-color signal. An icon, a text label, a pattern, a shape, an underline, a position. Something that survives even when color perception or color rendering is impaired.

See it in a real thing: a form field's error state

// Before — color is the ONLY signal something is wrong
<input
  className="border-2 border-red-500"
  aria-invalid={hasError}
/>

// After — color, icon, and text all agree
<div>
  <input
    className="border-2 border-red-500"
    aria-invalid={hasError}
    aria-describedby="email-error"
  />
  {hasError && (
    <p id="email-error" className="text-red-600 flex items-center gap-1">
      <ErrorIcon aria-hidden="true" />
      Enter a valid email address
    </p>
  )}
</div>

The "before" version tells a color-typical user, glancing quickly, that something's wrong — a red border reads as an error convention almost everyone has learned. But a user who can't distinguish that red from the field's normal border sees nothing different at all. There's no icon to notice, no text to read, no shape change — just a border that may or may not look different depending on exactly how their color vision works. The "after" version adds an icon and explicit error text tied to the input via aria-describedby, so the same information — this field failed validation, here's why — reaches a user regardless of whether the red border itself registers.

The same principle scales up. A required-field asterisk that's just a slightly different shade of red next to black label text is a weak signal for the same reason a status dot is — pair it with (required) in the label, or a distinct icon, not color alone. A multi-line chart distinguishing series only by similarly-toned colored lines has the identical problem at a larger scale — the fix is the same: different dash patterns, distinct markers, or direct labels on each line, not just different hues.

What people usually miss

Watch out

• This is a distinct WCAG success criterion from contrast, not the same rule restated. Contrast (1.4.3) asks "is this color legible against its background?" Use of color (1.4.1) asks "is color the only way this information is conveyed?" A design can pass one and completely fail the other.
• A design that "looks fine" to the person who built it is not evidence it's fine. Most engineers and designers have typical color vision, so a color-only signal reads perfectly clearly to the person shipping it — which is exactly why it's easy to miss without deliberately checking.
• The fix is never "pick better colors." No color pair fully solves this — some color vision deficiencies collapse a wide range of hues, not just one specific red/green pairing. The fix is always adding a non-color signal, not tuning the color itself.
• Icons alone aren't automatically the fix if the icon itself is color-coded with no shape difference — a red circle versus a green circle is still a color-only signal wearing an icon costume. The icon needs a distinct shape, not just a distinct color fill.

Why this matters in interviews

"How would you show an error state without relying on color?" is a common practical accessibility question, and it separates candidates who've internalized "add redundant, non-color signals" as a default habit from those who've only memorized "red means bad" as a design convention.