Designing for color blindness: why red and green are never enough

Accessibility failures are design decisions. Here is the proof. told the story of a backend developer who compensated silently for years before anyone on the team realized he was colorblind. It came out by accident, during a conversation about a football shirt, not during a design review. That piece covered the shape of the problem in a few paragraphs. This one covers the rest: the actual taxonomy of color vision deficiency, why red and green specifically collapse before any other pair, the fix that works regardless of which type someone has, and how to audit an existing design system for color-only failures.

1.1 Trichromacy, anomalous trichromacy, dichromacy

Typical human color vision is trichromatic: three types of cone cells in the retina, each sensitive to a different range of wavelengths (roughly red, green, and blue), combine their signals to produce the full range of perceived color. Color vision deficiency is not a single condition. It is a spectrum of ways that system can differ.

Anomalous trichromacy is the mildest and most common form: all three cone types are present, but one has a shifted sensitivity, so colors that should be distinct compress toward each other. Dichromacy is more severe: one cone type is missing entirely, and the affected part of the color spectrum collapses much further. "Colorblind" as a catch-all term flattens a real difference in severity that matters for how a design fails for different people.

1.2 The four names that actually matter

Protanomaly (anomalous) and protanopia (dichromatic) affect the red-sensing cone. Reds appear darker and shift toward green.

Deuteranomaly and deuteranopia affect the green-sensing cone. This is the most common category by far, and it produces the classic red-green confusion most people associate with the word "colorblind."

Tritanomaly and tritanopia affect the blue-sensing cone. Far rarer than the red-green types, and it confuses blue with green and yellow with violet: a different failure mode that a red/green-only fix does not cover.

Achromatopsia, total color blindness, is the rarest form: no functioning cone-based color vision at all, only shades of gray. Genuinely rare, but it is the useful worst case to test against, because an interface that survives achromatopsia simulation has, by definition, no color-only failures left.

Same three chips (error, success, warning) under four vision types. Red and green converge first and hardest.

1.3 Who this actually affects

Red-green color vision deficiency, taken together, affects approximately 8% of men and 0.5% of women of Northern European descent, the most commonly cited figures from the National Eye Institute. The prevalence varies somewhat by ancestry, but the order of magnitude does not: in a team of twelve, statistically about one person has some degree of it. In a product with any meaningful user base, the number of affected users is never rounding-error small.

2.1 The physiology, in one paragraph

The red-sensing (L) and green-sensing (M) cones have absorption curves that already overlap heavily in people with typical color vision: they sit close together on the visible spectrum. Anomalous trichromacy shifts one curve slightly closer to the other; dichromacy removes one entirely. Either way, the gap between red and green is the smallest gap in the whole system to begin with, which is exactly why it is the first one to disappear. Blue sits far enough from both that tritan-type deficiencies are rarer and behave differently, which is also why a fix built only around "avoid red and green" does not fully cover blue-yellow confusion.

2.2 Where this shows up in real interfaces

Error and success states in red and green, side by side, are the single most common instance: a form field, a status badge, a build pipeline result. Heatmaps that run from green (good) to red (bad) fail the same way a traffic-light legend does. Line charts distinguishing series by hue alone, with no marker shape or direct labeling, become unreadable the moment two of the lines are a red and a green. None of these are exotic edge cases. They are default choices in most component libraries.

3.1 The second-channel rule

The fix does not depend on knowing which type of color vision deficiency a given user has, because it does not try to pick "safer" colors. It adds a channel that does not depend on color perception at all: an icon, a text label, a position, a pattern. Error states get a red border and an error icon and a written message. Success states get the green confirmation and an explicit checkmark and a confirmation sentence. The color can stay exactly as designed. It just stops being the only thing carrying the meaning.

Same two states. Run both columns through the deuteranopia filter above: only one column still tells you which field has a problem.

3.2 Data visualization needs its own version of the rule

Charts and dashboards fail this in a way that plain UI states usually do not: there is often no room for an icon next to a data point, and a written label next to every line defeats the purpose of a chart. The equivalent fixes are direct labeling at the end of each line instead of a color-coded legend, distinct marker shapes or dash patterns per series in addition to color, and choosing palettes built for this. Color Brewer's qualitative and diverging sets, or Okabe-Ito, are standard, tested references, not hues picked by eye.

Same two series. Solid vs. dashed plus a direct label survives a colorblind reader; a colored dot next to a word does not.

4.1 What is already on your machine

No purchase or install required for the first check. Chrome DevTools has a built-in vision deficiency emulator: open DevTools, Command/Ctrl+Shift+P, run "Show Rendering," and use "Emulate vision deficiencies" to view the live page as protanopia, deuteranopia, tritanopia, or achromatopsia. macOS ships a similar simulator inside Accessibility settings (Display → Color Filters). Neither requires the design file to be finished. Both work on a live, running product.

Pick one. The point is running it before handoff, not which one.

4.2 The two-minute check

Turn on a simulator. Walk every state your interface communicates through color alone: form errors, success confirmations, warning banners, chart legends, status dots, availability indicators. If any of them become ambiguous or indistinguishable, that state fails, regardless of what the contrast ratio between the colors measures. Color vision deficiency and low contrast are different axes of the same underlying problem, covered in AA vs AAA: what these levels actually mean and why your disabled button is failing both: a color pair can pass contrast math and still be indistinguishable to a colorblind user.

5.1 The checklist

Go through the component library state by state, not screen by screen. A color-only failure in a shared button or badge component repeats everywhere that component is used, so fixing it once at the source fixes every instance.

For every component that communicates a state: error, success, warning, info, disabled, selected, active. For each state, confirm there is a non-color signal present (an icon, a label, a position change, an underline, a border style) and that the signal is visible when the color is removed entirely (run the achromatopsia filter as the strictest test; if a state still reads correctly in grayscale, every less severe form of color vision deficiency reads it correctly too).

Do the same pass for data visualization components separately. Charts, graphs, and heatmaps almost always live outside the core component library and get missed by a UI-only audit, even when the UI components themselves are already fixed.

5.2 Document the fix once, not per instance

Once a state's non-color signal is decided at the token or component level (this error state always gets this icon, this pattern), every team building on top of that system inherits the fix automatically. Leaving it to individual screens to remember means the fix has to be rediscovered, and re-forgotten, every time someone builds a new screen.

Sources

• National Eye Institute. Color Blindness. nei.nih.gov/learn-about-eye-health/eye-conditions-and-diseases/color-blindness
• National Library of Medicine, MedlinePlus. Color vision deficiency. medlineplus.gov/genetics/condition/color-vision-deficiency
• W3C Web Accessibility Initiative. Understanding SC 1.4.1: Use of Color. w3.org/WAI/WCAG22/Understanding/use-of-color
• Okabe, M. and Ito, K. Color Universal Design (CUD): How to make figures and presentations that are friendly to Colorblind people. jfly.uni-koeln.de/color
• Colblindor. Coblis: Color Blindness Simulator. color-blindness.com/coblis-color-blindness-simulator
• WebAIM. Screen Reader User Survey #10 Results. webaim.org/projects/screenreadersurvey10