Designing for color blindness

About 1 in 12 men have color vision deficiency, according to the US National Eye Institute (NEI), which adds that men have a much higher risk than women. Color vision deficiency, also called color blindness, means a person sees colors differently from most people. It usually makes certain colors hard to tell apart, and the most common type affects red and green. Anything a design says only through color, such as an error, a status, a chart line or a link, can be missed by some visitors. The fix is seldom to give up color. It is to make sure color is never working alone.

The rule that covers this is success criterion 1.4.1 Use of Color, a Level A requirement in WCAG 2.2 (see what the conformance levels mean). Below we cover what it asks for, where designs break it, why lightness helps when hues merge and how to test. Where a point goes beyond W3C's text, we say it is our reading. Contrast ratios are a separate requirement, covered in our color contrast guide.

What color blindness means for a design

The NEI describes red-green types, blue-yellow types and complete color vision deficiency, and calls deuteranomaly and protanomaly mild. The table summarizes the NEI's types of color vision deficiency and adds the design problem each points to.

Treat the table as a guide to what might merge, not as a description of any individual. The NEI says everyone sees color a little differently, and that most people with a deficiency are born with it while injury, other health problems, some medicines and aging can cause it later. A design cannot predict which visitors are affected. Color blindness is also not the only reason color fails: W3C's Understanding page for 1.4.1 also names people with partial sight, some older users and people on limited-color or monochrome displays.

The rule: color cannot be the only signal

Success criterion 1.4.1 says "Color is not used as the only visual means of conveying information", and it goes on to cover indicating an action, prompting a response and distinguishing a visual element (W3C's Understanding page). In plain terms: if a color tells someone something, a second visual cue has to tell them the same thing. It is listed with the other criteria in our WCAG criteria reference. W3C's page adds three points.

• Color is still allowed. The criterion should not discourage color, or even color coding, as long as another visual indication goes with it.
• The second cue must be visible. Information that reaches a screen reader through markup does not necessarily meet this criterion. Other criteria cover assistive technology, and the page names 1.1.1, 1.3.1 and 4.1.2 among them.
• Images count. Where an image uses color to carry meaning, such as a chart, the meaning has to survive without the color. W3C lists a failure, F13, for a text alternative that leaves out what the colors convey.

Where color alone hides in a design

Most failures come from a short list of patterns. Where a row cites W3C, the claim is W3C's; where it says "our reading", it is ours. W3C's Understanding page says the criterion requires a visible alternative to color. Our reading is that the second cue should be there without hovering or clicking, so a hover-only tooltip does not count.

Charts, maps and diagrams

In charts and maps, color often carries the data, so the second cue takes more thought than a text label. W3C's technique G111, "Using color and pattern", shows bars with a pattern as well as a color and a legend that matches both, a transit map whose stops have different shapes, and a flow chart that uses dashed and dotted arrows. WebAIM's color-blindness article suggests annotating images, adding text with the same information and giving each map line a different style. A chart that holds up without color usually does most of this:

• Labels the data directly. A name or value printed on the line, bar or slice saves matching colors to a legend. W3C's pie chart examples in its non-text contrast guidance note that visible labels and values can carry the same information as the slices.
• Varies more than hue. Dash patterns for lines, marker shapes for points, fill patterns for areas.
• Uses lightness for ordered data. A scale from light to dark should stay readable for most people with color vision deficiency, because lightness is the difference they can generally still perceive (see the next section). This is our reading.
• Keeps marks distinct from what is next to them. Success criterion 1.4.11 asks for 3:1 between the parts of a graphic needed to understand it and the adjacent colors. In W3C's 1.4.11 examples a pie chart with low-contrast slices fails, and a darker border around a yellow slice fixes it.

For example, take a line chart of a store's sales by region with four lines that differ only in hue. Label each line at its end, give the lines different dash styles or end markers, and put the figures in a table under the chart. None of this means changing the palette. Note that 1.4.11 does not tell the lines apart for you: in W3C's line graph example each line needs 3:1 against its background, but the lines need not contrast with each other because there is little overlap between them. In our reading, telling them apart is 1.4.1's job.

Lightness as well as hue

W3C's explanation of 1.4.3 says that for people with color vision deficiency who cannot distinguish certain shades, hue and saturation have minimal or no effect on legibility, and that WCAG therefore calculates contrast so that hue is not a key factor. Our reading is that two colors that differ strongly in lightness should stay separable for most people with color vision deficiency even when their hues merge.

The 1.4.1 page uses the same idea. Colors that differ in both hue and lightness count as an additional visual distinction when the contrast ratio between them is 3:1 or greater, and its example is a light green with a dark red. WebAIM makes the same point: a dark red and a light green stay easy to tell apart because their luminance differs. In our reading, that is why a red and a green of equal lightness are the dangerous pair, and why a design that holds up in grayscale is a good sign.

There is a limit. Where understanding depends on telling one specific color from another, such as a green outline for valid and a red one for invalid, W3C says an additional visual indicator is still needed whatever the ratio. Our reading is to treat lightness as the backup and a text label or icon as the main signal for anything important. Two cautions about contrast itself:

• Red on dark. W3C's rationale for 1.4.3 says luminance contrast can generally be computed without regard to a specific color deficiency, with one exception: predominantly long-wavelength colors, such as red, against darker colors for people with protanopia. Our reading is that red text and icons deserve a check in dark themes (see our dark mode guide).
• Passing does not make two colors distinct. Contrast under 1.4.3 is measured between text and its background, and 1.4.11 asks for 3:1 only between a graphic part and the colors next to it. Where nothing requires two colors to contrast with each other, as with the lines in W3C's line graph example, both can pass and still look alike. Check the pair as well as each color.

If you are choosing a whole palette, our guide to building an accessible brand color palette goes from brand colors to usable shades.

A review you can repeat

1. List where color carries meaning: statuses, errors, required fields, links, chart series, map regions, selected states and instructions.
2. Add a second cue to each: a word, icon, pattern, shape, underline or direct label.
3. Separate colors by lightness as well as hue, so each pair still differs in grayscale.
4. Check contrast: 4.5:1 for text (3:1 for large text, under 1.4.3) and 3:1 for graphics and interface parts (under 1.4.11).
5. Simulate protan, deutan, tritan and grayscale, and note anything that merges or disappears.
6. Read the words. Look in instructions and alt text for references that rely on color alone, such as "the red items".

Run it on each template and component rather than every page. Passing it does not show that a page meets WCAG or any law, and our guide to testing website accessibility covers the other checks.

Check it yourself

A simulation shows which colors may merge. It cannot say what a color means on your page, so use it to find candidates and your own judgment to decide.

• Color blindness simulator. Load a screenshot, or enter two colors that must mean different things, and see them as protan, deutan and tritan color vision plus a lightness-only view for achromatopsia. It runs in your browser, so nothing is uploaded. Its "hard to tell apart" label is a GotAlt rule of thumb, not a WCAG rule.
• Accessible color palette generator. Builds a shade scale for up to five brand colors and measures the WCAG contrast of every pair, so you can pick steps that differ strongly in lightness. It does not simulate color vision, so run the simulator on the result.
• Contrast checker. Gives the WCAG ratio for any two colors, for text against its background or for the 3:1 link-to-text check above.
• Browser developer tools. For a live page, Chrome's Rendering tab has an "Emulate vision deficiencies" menu (Chrome DevTools documentation), and Firefox's Accessibility Inspector has a Simulate menu (Firefox documentation). Both list protanopia, deuteranopia, tritanopia and achromatopsia. Mozilla's page notes that the Firefox feature depends on WebRender, which it says is not enabled by default on all platforms.
• The free scan. Scan my site for free reads the HTML your server sends and has no CSS or layout engine, so it cannot see color. What we check sets out its limits.

No automated check can decide what a color means to your visitors. That judgment stays with the person reviewing the design.