Designing palettes for deuteranopia: a practical guide

I should declare an interest: I'm deuteranomalous. My green-sensitive cones are shifted toward red, which means that a lot of the traffic-light UI in the world is, for me, a set of slightly different browns. I've learned to live with it. I've also learned that most of the problems it causes are entirely preventable at the palette stage.

What deuteranopia actually does

Human color vision relies on three cone types, roughly tuned to long (L, 'red'), medium (M, 'green') and short (S, 'blue') wavelengths. In deuteranopia the M cones are missing; in the far more common deuteranomaly they are present but shifted. Either way, the brain loses much of its ability to separate colors along the red–green axis. The blue–yellow axis remains intact.

That single fact is the foundation of every practical strategy: if you need two colors to be distinguishable by people with red–green deficiency, make them differ along blue–yellow, or in lightness, or both.

The palette above is Palettos' deuteranopia-safe preset. Primary and accent sit on opposite ends of the blue–orange axis, and they also differ by more than 20 units of CIELAB lightness. Run it through any deficiency simulation and the roles stay distinct.

The three rules I actually use

• Never let hue be the only difference. WCAG 1.4.1 requires that color is not the sole means of conveying information. In practice: pair status colors with icons, labels or patterns. A red 'X' and a green '✓' work for everyone; a red dot and a green dot do not.
• Separate important pairs in lightness. A difference of roughly 20–25 L* units survives every form of color deficiency, including total achromatopsia. This is also why grayscale checks remain one of the fastest audits you can do.
• Prefer blue/orange over green/red for binary states. Many data-visualization libraries now default to this pairing for good reason.

Charts are where palettes fail

Interfaces usually have enough text and structure to survive a palette that isn't color-blind safe. Charts don't. A line chart with a red series and a green series, same lightness, same thickness, is unreadable to about 4% of your audience. Fixes, in order of effectiveness: label the lines directly instead of using a legend; vary line style (solid, dashed); choose hues from a vetted categorical scheme; and vary lightness across series.

The best color-blind accommodation is the one nobody notices, because the design never depended on the thing they can't see.

How to test honestly

Simulation is useful but imperfect. The model Palettos uses — Machado et al., 2009 — is well-regarded and physiologically grounded, but it simulates full-severity deficiency, and most people have milder anomalous trichromacy. Treat simulation as a stress test: if your palette survives full deuteranopia, it will survive deuteranomaly. Where possible, also test with real people. Color vision deficiency is common enough that someone on most teams of twenty has it; ask.

Don't over-correct

I sometimes see teams, having learned about color deficiency, strip all red and green from their palette. That's unnecessary. Red still means 'stop' to me through context and convention — I just need a second cue. Keep your semantic colors; add redundancy. The goal is not a palette that looks identical to everyone, but a product that communicates identically to everyone.

In the Accessibility module you can switch between simulations with a single click and watch the full website mockup update. If two elements merge, you've found your problem before your users did.