Level A

Color-only signals (red error borders, color-coded required fields, color-only chart series) collapse to a single undifferentiated state for users who cannot perceive the color difference -- the information is literally not in their rendering of the page.

1.4.1 Use of Color

In Plain Language

1.4.1 Use of Color (Level A) says color must not be the sole means of conveying information, indicating an action, prompting a response, or distinguishing a visual element[1]. Color as a redundant cue is fine -- the rule is that color cannot be the only cue. If a red border is the only thing marking a field as invalid, a user who does not perceive the red sees an unmarked field.

The fix is to pair every color signal with a non-color signal: a glyph, a shape, a text label, a border-style change, a pattern, a position. Remove the color mentally and ask whether the information still reaches the reader. If it does not, the page fails 1.4.1.

Why It Matters

  • About 1 in 12 men have some form of color vision deficiency; the condition is far less common in women because the genes for the red and green cone photopigments are carried on the X chromosome[2]. For these users, red-on-gray error text and green-on-gray success text can render as the same neutral mid-tone.
  • 1.4.1 is distinct from 1.4.3 Contrast (Minimum). 1.4.3 is about the contrast ratio between foreground and background. 1.4.1 is about whether color is the only thing carrying a specific piece of information. A page can pass 1.4.3 and still fail 1.4.1 -- a chart with four high-contrast but colour-only series fails 1.4.1 even though every series meets contrast.
  • Monochrome displays, high-contrast Windows themes, forced-colors mode, printed output, and projector color shifts all strip or distort hue. A signal that relies on hue alone does not survive any of these rendering paths.
  • The canonical link case: Understanding 1.4.1 calls out that links in running text must be distinguishable from surrounding body text by something other than color -- typically an underline[1]. Removing the underline and relying on a color shift is the textbook failure.

Examples

Do: Required fields with text label and color

Fields marked * (required) must be completed.

<label>
  Full name <span class="required">* (required)</span>
</label>
<input type="text" aria-required="true">

<p class="note">
  Fields marked * (required) must be completed.
</p>
<!-- Color PLUS text label and asterisk -->
Don't: Required fields indicated only by color

Red labels are required.

<!-- FAILS: only red color indicates required -->
<label class="red-label">Full name</label>
<input type="text">

<p class="note">Red labels are required.</p>
<!-- A user who cannot see red has no way
     to know which fields are required -->
Do: Links with underline and color

Read our accessibility statement for details on how we meet WCAG requirements.

<!-- Link is underlined AND a different color -->
<a href="/accessibility">accessibility statement</a>
<!-- Both cues help distinguish links from text -->
Don't: Links distinguished by color alone

Read our accessibility statement for details on how we meet WCAG requirements.

<!-- FAILS: link has no underline, only color -->
<a href="/accessibility"
   style="text-decoration: none;">
  accessibility statement
</a>
<!-- Users who cannot see the green color
     cannot identify this as a link -->

How to Fix It

  1. Inventory every color-carried signal. Required-field markers, error and success states, status badges, chart series, link styling, selected-tab indicators, diff highlighting, calendar availability. For each one, ask: if the hue were replaced with mid-gray, would the user still know which state this is?
  2. Pair error states with a glyph and text. A red border alone fails. A red border plus an inline ✘ glyph and an error message referenced by aria-describedby passes -- the glyph and text survive grayscale, forced-colors, and color vision deficiency.
  3. Mark required fields with a non-color token. An asterisk in the label, or the literal string "(required)", paired with aria-required="true". Coloring the label red on its own fails because a user who does not perceive the red sees an ordinary label.
  4. Keep underlines on in-text links. Understanding 1.4.1 treats underline (or an equivalent non-color distinction) as the default method for making body-text links identifiable without color[1]. text-decoration: none on an <a> inside running prose is the classic 1.4.1 failure.
  5. Give charts a second channel. Direct data labels, patterns (hatching, dots, dashes), distinct marker shapes, or dashed vs solid line styles, so that a grayscale render of the chart still lets the reader match each series to its legend entry.
  6. Verify with a grayscale render. DevTools has a grayscale filter; macOS and Windows expose a system-level grayscale mode. If any piece of information disappears when hue is removed, that piece is currently color-only and fails 1.4.1.

References

  1. [1] W3C (2023). Understanding Success Criterion 1.4.1: Use of Color. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html ↩ ↩ ↩
  2. [2] National Eye Institute (2023). Color Blindness. National Institutes of Health, Accessed 2026-04-07. https://www.nei.nih.gov/learn-about-eye-health/eye-conditions-and-diseases/color-blindness ↩