WCAG & Accessibility·4 min read

Designing for Color Blindness: A Practical Guide

About 8 percent of men and 0.5 percent of women perceive color differently from what your monitor's palette assumes. Designing for color blindness isn't about avoiding color; it's about never letting color carry a message alone. This guide walks through the four main types of color vision deficiency, shows a real red and green pair collapsing into two near-identical khakis under simulation, and lays out concrete rules for status indicators, charts, and palettes that survive every vision type you can test.

Open the tool All insights

Where color blindness breaks real interfaces

It's usually the status colors.

A deployment dashboard shows a grid of dots: green means healthy, red means failing. For roughly one in twelve male users, that grid is a field of nearly identical brownish dots, and the only way to find the outage is to hover every node. The team that built it never noticed, because nobody on the team happened to be colorblind.

The same failure shows up in form validation that only turns a border red, diff views that rely on red and green fills, and map legends where six categories differ only by hue. None of these are exotic designs. They're defaults, which is exactly why simulating them is worth ten minutes before every release.

The four types of color vision deficiency

Protanopia is the absence of long-wavelength cones: reds go dark and muddy, and red versus green becomes guesswork. It affects around 1 percent of men. Deuteranopia, missing the medium-wavelength cones, is about as common and also collapses red and green, though reds keep more of their brightness.

Tritanopia, the loss of short-wavelength cones, is much rarer and confuses blues with greens and yellows with violets. Achromatopsia removes color perception entirely, leaving pure lightness. A color blindness simulator renders all four so you can check your design against each one, and the achromatopsia view doubles as the ultimate stress test: if information survives in grayscale, it survives everything.

A worked deuteranopia simulation: #E63946 vs #7CB342

Take a warm red, #E63946, and a healthy green, #7CB342, the kind of pair a thousand dashboards use for fail and pass. Push them through the deuteranopia matrix and the red becomes #A5B242 while the green becomes #918D64. Both are khaki. Set them side by side and the once-obvious opposition is reduced to a mild difference in brightness that no one should have to squint at.

This is the pattern behind most color pairs that fail: similar lightness plus opposed hues. The hues get flattened by the deficiency, the lightness was never different to begin with, and nothing remains. Paste those two hex codes into the simulator's palette test and you'll see the collision flagged under deuteranopia within seconds.

Designing for color blindness: lightness does the heavy lifting

The single most effective fix is to separate meaningful colors by lightness, not just hue. A dark red against a light green stays distinguishable under every deficiency, because lightness passes through all of them intact. If you fix nothing else, fix this.

The second rule comes straight from WCAG criterion 1.4.1: color must never be the only signal. Add an icon to the error state, a label to the chart series, a pattern to the map fill. This isn't a consolation prize for colorblind users; redundant encoding helps everyone scanning a busy screen, which is why airline departure boards and traffic lights use position and shape as well as color.

Colorblind design mistakes teams keep shipping

Watch for these patterns in your next review:

Red and green as the only difference between success and failure states, the classic collision under both protanopia and deuteranopia.
Rainbow chart palettes where adjacent series share lightness, guaranteeing at least one indistinguishable pair per vision type.
Legends that identify categories purely by swatch color, with no labels, patterns, or direct annotation on the data.
Testing with a generic safe palette from a blog post instead of simulating the exact hex values your product ships.
Checking the marketing site but not the emails, PDFs, and charts exported by the product, which reuse the same risky pairs.

Two colorblind testing habits worth keeping

Make the grayscale pass part of your definition of done. Simulate achromatopsia, or simply desaturate a screenshot, and ask whether every state, series, and alert is still identifiable. It's a thirty-second check that catches the majority of hue-only encoding.

Test the palette, not just the picture. An uploaded screenshot tells you how one screen fares, but running your brand hex list through the palette test tells you which combinations are structurally unsafe, so you can retire a bad pairing everywhere at once instead of patching screens one by one.

When the simulator points you to another tool

The Color Blindness Simulator shows you what different eyes see; it doesn't fix the colors for you. When a pair collides, the Color Contrast Checker helps you rebuild it with a proper lightness gap, and its suggested shades keep your hue while moving brightness. When you need a whole set of chart colors that stay distinct and readable, generate them with the Accessible Color Palette Generator and then re-run the simulation to confirm the set survives.

For a broader sweep that includes use-of-color issues alongside everything else, point the WCAG Accessibility Scanner at your site and work through its report.