Don't rely on color alone

Short answer

If color carries information in an interface, the same information must also be carried by at least one other means: a shape, an icon, a piece of text, a pattern, or a position. An erroneous form field is shown not just with a red border, but with a sentence right below the field that describes the problem, a warning icon, and a cue the screen reader will announce. The same principle requires an underline for links, direct labels for charts, and an icon and a word for status indicators; color stays alongside these cues as a supporting voice.

Color is a channel, not the only one

BI-12 covered the fact that red–green color vision deficiency occurs in about eight percent of men of European descent. That means a color-coded interface gives incomplete information to a significant number of users every day. But the problem isn't only color vision differences. A phone screen glaring in the sun, a grayscale printer, a screen with its colors dimmed in night mode, or a screen reader that works by voice alone also loses color.

UX-02 built individual examples of this principle for status colors, and UX-04 built them for photo selection. This lesson takes up the principle itself and shows how it's applied in four common places: form errors, links, legends, and status indicators.

The essence of the 1.4.1 criterion mentioned in UX-02 fits in one sentence: using color is fine; leaving color as the only means is not.

The erroneous form field

The question on the lesson card: how do you mark an erroneous field in a form without using color?

It helps to look first at what the criterion requires. Success criterion 3.3.1, "Error Identification," asks that if an input error is automatically detected, the erroneous item be identified and the error be described to the user in text. The key word is "text": an error is a readable description, not a change in color.

A well-marked erroneous field is built from layers. Right below the field sits a sentence that states the problem and the fix: "The email address is missing the @ sign." A generic sentence like "Invalid input" isn't enough, because it doesn't tell the user what to do. Next to the sentence sits a warning icon; even if color isn't seen, the icon's shape says something is wrong. The field's border doesn't just change color, it also gets thicker, so an eye that mixes up hues still notices that the border has changed. The label is kept, and the error sentence doesn't take its place: the user reads what the field asks for and what went wrong at the same time.

There's one more layer that isn't visible. Someone using a screen reader never sees the red border; the fact that the field is erroneous, and that the error sentence belongs to that field, has to be marked in the code. On the web, this is done by marking the field as invalid and linking the error text to the field programmatically. When there's more than one error, a summary at the top of the form that lists the errors and links each one to its field also lets the user see at a glance what needs fixing.

A simple check starts with the grayscale test: open the form in grayscale and in a red–green color vision deficiency simulation, then listen to it with a screen reader. If all three cases make clear which field is erroneous and why, the error doesn't depend on color.

The underline on a link

Distinguishing a link inside body text by color alone is one of the most common color dependencies. The default appearance recommended by the HTML standard solves this problem from the start: unvisited links are shown in #0000EE blue and underlined.

The math shows why the underline matters. The default #0000EE blue gives only about 2.2:1 against black body text, below the 3:1 that G183 requires. The default design closes this gap with the underline. A designer who removes the underline, though, gets squeezed into a narrow range. If the body text is nearly black, like #1A1A1A, the link color must give 4.5:1 against the white background and 3:1 against the body text at the same time. Together, these two requirements trap the link's relative luminance in a narrow window of roughly 0.13 to 0.18. #0066CC falls inside this window: it gives about 5.6:1 against white and about 3.1:1 against the body text. #005A9C reads better against white, but it's separated from the body text by only 2.4:1, and without an underline, it's not clear that it's a link.

G183 itself adds a note: meeting the technique is sufficient, but authors may still want to consider an additional cue such as an underline or bold text. The default colors for visited and unvisited links, meanwhile, are separated from each other by a ratio as small as 1.17 to one; this distinction already rests almost entirely on a difference in hue, and if it's critical information for the user, it should be reinforced with an icon or text.

Legends and status indicators

The most familiar form of color dependency in charts is a layout where lines are distinguished by color alone and their meanings are given in a legend tucked in the corner of the chart. The reader has to match each line's color to a small square in the legend; if two colors are close, this matching turns into guesswork.

Direct labeling, patterns, and distinct marker shapes are the main solutions to this problem in charts; how to apply them and how to test them with simulation is the subject of VG-07. What matters for an interface is that the small charts inside a dashboard are subject to the same rule: if two lines showing a user's own data are distinguished by color alone, that user may not be able to read their own data.

Status indicators are a condensed version of the same problem. A small dot at the start of each row in a list might mean "active" if it's green, "pending" if it's yellow, "stopped" if it's red. If the three dots are the same size and the same shape, they're all the same thing to a reader who confuses red and green, and to a grayscale printout.

The fix is to also change each status's shape: a filled circle and a checkmark for active, a hollow circle or a clock icon for pending, a square or an X for stopped. If a short word is added next to it, the icon no longer stands alone either. This is a problem traffic lights solve too: alongside the colors, the lamps' order also carries the information.

Example — the foundation shade picker

A cosmetics store's app shows its foundation shades in a grid made up of nothing but colored squares. The shades are ordered by lightness, and at each lightness level, a warm-undertone square and a cool-undertone square sit side by side. There's no text at all under the squares.

The math shows who this layout strains. #C68863 and #D2807C, its hue shifted thirty degrees toward red, have nearly the same lightness in CIELAB; the WCAG contrast ratio between them is 1.0:1. The same math gives the same result for a darker pair, #8D5524 and #9E483F. In other words, the difference between the warm and cool undertone lives in hue alone: the two squares are identical in grayscale, and the distinction can also become difficult for someone who has trouble telling hue apart on the red–yellow axis. On top of that, screen settings and ambient light shift this small hue difference from phone to phone.

The team rebuilds the grid with redundant coding. A lightness number and an undertone word are written under each square: "24 · warm," "24 · cool." The undertones are also marked with a small shape: a circle for warm, a square for neutral, a triangle for cool. The selected shade is shown not just by darkening, as in UX-04, but with a checkmark and a frame. This layout works the same way for every shade from very light to very dark. The result is tested against the text-free grid, with users of different skin tones and different color vision conditions.

Common misconception

Summary

1. If color carries information, the same information is also given through at least one other channel; WCAG 1.4.1 doesn't prohibit using color, it prohibits color being the only means.
2. An erroneous form field is marked with a sentence below it that states the problem and the fix, an icon, a border that gets thicker, and an error text linked to the field programmatically; links are reinforced with an underline, charts with direct labels, and status indicators with shape and a word.
3. Grayscale, color vision simulation, and screen reader tests expose color dependency; skin-tone-dependent choices like foundation undertones that are distinguished by hue alone are coded with a number, a word, and a shape.

Test yourself

1. (Easy) In the default style recommended by the HTML standard, what color and form are unvisited links shown in?
2. (Easy) What does success criterion 3.3.1, "Error Identification," require for an input error?
3. (Medium) How do you mark an erroneous field in a form without using color?
4. (Medium) Why does direct labeling, used instead of a legend, reduce color dependency in a chart?
5. (Hard) When the body text is #1A1A1A, why is an underline-free link's color forced to stay within a narrow range?
6. (Hard) Why can't the warm- and cool-undertone squares in the foundation shade picker be distinguished by color alone, and how should they be coded?

Answers

1. In #0000EE blue and underlined ("The underline on a link").
2. That the erroneous item be identified and the error be described to the user in text ("The erroneous form field").
3. A sentence stating the problem and the fix is written right below the field, a warning icon is placed next to it, the border doesn't just change color but also gets thicker, and the label is kept. The field is marked invalid in the code and the error text is linked to the field programmatically; if there's more than one error, a linked summary is given at the top of the form ("The erroneous form field").
4. The reader doesn't have to match each line's color to a small square in the corner; the series' name sits right next to the series and can be read even if color isn't seen ("Legends and status indicators").
5. The link must give 4.5:1 against the white background and 3:1 against the body text at the same time; together, the two requirements squeeze the link's relative luminance into roughly the 0.13 to 0.18 range. #0066CC falls within that range; #005A9C and the default #0000EE do not ("The underline on a link").
6. Pairs like #C68863 and #D2807C have nearly the same lightness in CIELAB, and the contrast between them is 1.0:1; the difference lives in hue alone and disappears in grayscale. A lightness number and an undertone word are written under each square, and the undertones are also marked with shapes such as a circle, a square, and a triangle ("Example — the foundation shade picker").

Sources

• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2," success criteria 3.3.1 and 1.4.1.
• W3C, "Technique G183: Using a contrast ratio of at least 3:1 to distinguish inline text links from surrounding text."
• W3C, "Technique F73: Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision."
• WHATWG, "HTML Living Standard," Rendering section.

Next step

UX-08 turns this lesson's habit of grayscale and simulation testing into a testing process: it asks why tools that automatically measure contrast ratio can't tell whether an error is described in text, how high-contrast modes can break a design, and what sitting down and watching low-vision or older users shows. UX-09, in turn, moves on to how colors are written: it covers building a tonal scale with CSS's oklch() and color-mix() functions, relative color syntax, and wide-gamut P3 colors.