How to Design Color-Blind-Friendly Palettes

The first time I really understood color blindness wasn't from a spec — it was from a code review. I'd built a status dashboard where green dots meant "healthy" and red dots meant "down," and a backend engineer on the team mentioned, almost apologetically, that he couldn't tell which servers were on fire. He's one of roughly one in twelve men with red-green color vision deficiency. My beautiful traffic-light system was, to him, a grid of identical brownish-grey circles. Nothing was broken in the code. Everything was broken in the design.

That's the thing about designing a color blind friendly palette: the failures are invisible to the person who shipped them. You can't feel the bug. So you have to build the habit of designing as if color is information you might lose at any moment — because for a meaningful slice of your users, it already is.

How common is it, and what actually goes wrong

Color vision deficiency (CVD) affects about 8% of men and 0.5% of women of Northern European descent — roughly 1 in 12 men and 1 in 200 women. On a product with any real audience, that's not an edge case. That's a column in your analytics.

The deficiency isn't "seeing in black and white" — true monochromacy is vanishingly rare. What happens is that one type of cone in the eye is shifted or missing, which collapses certain colors toward each other. The main types, by how common they are:

• Deuteranomaly and deuteranopia — reduced or absent green-cone response. This is the big one: deuteranomaly alone affects around 5% of men, making it the single most common form. Reds, greens, browns, and oranges blur together.
• Protanomaly and protanopia — reduced or absent red-cone response, around 1% of men for the full form. Similar red-green confusion, but reds also look darker and can vanish against black.
• Tritanopia and tritanomaly — blue-yellow deficiency. Genuinely rare (on the order of 0.01% and not sex-linked, so it affects men and women about equally), but worth a glance because it breaks the blue-green and yellow-pink distinctions that the other types leave alone.

The practical headline: about 99% of CVD is red-green. If your palette survives a red-green simulation, you've covered the overwhelming majority of affected users. That's where to spend your attention first.

This is a different problem from contrast

Here's the distinction that trips up even careful teams. Luminance contrast (the WCAG kind) is about light versus dark — can you read the text. Color vision deficiency is about hue confusion — can you tell two colors apart when they happen to be similar in lightness. They are independent problems, and you can fail one while acing the other.

The classic example: pure red #FF0000 text on pure green #008000 has a luminance contrast of roughly 1.3:1, which fails WCAG badly — but even if you "fixed" the contrast, a deuteranope would still struggle because the two hues themselves collapse together. Conversely, two colors can have lovely contrast and still be a CVD trap if you're using their hue, and only their hue, to carry meaning.

So a color-blind-friendly palette and a WCAG-compliant palette are overlapping circles, not the same circle. You need both. If you haven't already, it's worth reading WCAG Contrast Ratios Explained alongside this — luminance contrast is the foundation, and CVD-safe design is the layer on top.

The one rule that fixes most of it: never rely on color alone

If you take a single principle from this article, take this: do not rely on color alone to convey information. The W3C makes this an explicit requirement — WCAG Success Criterion 1.4.1, Use of Color — and it's the highest-leverage habit you can build.

The fix is almost always redundancy. Whenever color carries meaning, pair it with a second, non-color signal:

• Text or labels. My server dashboard got better the instant each dot also said "Up" or "Down." Boring, bulletproof.
• Icons and shapes. A check, an X, a warning triangle. Error states get a different icon, not just a different color. This is why a good form shows a red border and an error icon and a message.
• Patterns and textures. In charts, fill bars or regions with hatching, dots, or dashes so categories differ even in greyscale.
• Position and order. A legend that follows the same top-to-bottom order as the stacked areas it describes lets people match by position, not hue.

The quick test I run on any screen: imagine it printed on a black-and-white laser printer. If you can still understand it, you're not relying on color alone. If two states become identical, you've found your bug.

Choosing hues that survive CVD

Redundancy handles meaning. But you still want the colors themselves to stay distinguishable wherever possible — especially in data visualization, where you can't put a text label on every one of 200 data points.

A few rules of thumb from the trenches:

• Avoid red-green as your only contrast. The "good/bad," "before/after," "team A/team B" pairing that defaults to red and green is the single most common CVD failure. If you need two opposed colors, blue and orange is the safest pair on the planet — it stays distinct across every type of CVD. Blue and red is a solid second choice.
• Lean on lightness differences, not just hue. If two categories also differ in luminance, CVD viewers can tell them apart even when the hues collapse. A light blue against a dark blue reads as two things to everyone.
• Be careful with the in-between hues. Teal, olive, brown, and muddy oranges sit right in the danger zone for red-green deficiency. Pure, separated hues fare better than murky ones.

Rather than reinvent this, stand on the shoulders of people who solved it rigorously. The Okabe-Ito palette (also called the Wong palette after Bang Wong's 2011 Nature Methods article) is an eight-color set engineered to stay distinguishable across all common CVD types. The hex codes are worth bookmarking: orange #E69F00, sky blue #56B4E9, bluish green #009E73, yellow #F0E442, blue #0072B2, vermillion #D55E00, reddish purple #CC79A7, and black #000000. I've used it as the categorical palette for more dashboards than I can count, and it has never failed a simulation.

When you're building a brand or UI palette rather than a chart, you usually don't need eight CVD-distinct colors — you need a couple of accents that don't collide. That's where the color palette generator earns its place: build your harmony (a split-complementary or triadic scheme), read off the HSL values, and then deliberately push your two most semantically important colors apart in lightness as well as hue. The HSL readout makes that easy — drop the lightness on one, raise it on the other, and you've bought yourself separation that survives CVD. If you want to understand why certain wheel relationships clash more than others, Split-Complementary vs Triadic Palettes gets into the geometry.

Test it — don't trust your own eyes

You cannot eyeball this, because (statistically) you probably have normal color vision and the whole point is that the failure is invisible to you. You simulate.

• Coblis (the Color Blindness Simulator on Colblindor) lets you upload a screenshot and view it through eight different deficiency types. Everything runs locally in your browser, so you can throw full-resolution exports at it. This is my go-to for checking a finished screen.
• Browser DevTools. Chrome's Rendering panel has an "Emulate vision deficiencies" dropdown — protanopia, deuteranopia, tritanopia, and blurred vision — applied live to the real page. Brilliant for catching problems while you're still in the markup.
• Figma and Sketch plugins like Stark or the built-in vision simulators let you check designs before they're ever built.

My actual workflow: design normally, then run the key screens — dashboards, charts, form errors, anything where color means something — through deuteranopia first (most common), then protanopia, then a quick tritanopia pass. Ninety percent of the problems I find are in that first deuteranopia view. Fix those and you've helped the most people for the least effort.

The mistakes I keep seeing

• Red/green validation states with no icon. The most common one. A red border and a green border are the same border to millions of users. Add an icon and a message, always.
• Heatmaps and charts that only vary hue. A green-to-red heatmap is a CVD minefield. Use a sequential scale that also ramps lightness (light yellow to dark blue, say), or add value labels.
• Color-coded legends matched only by color. If the only way to map a line to its label is "find the green one," CVD users are stuck. Order the legend to match the data, or label directly on the line.
• Assuming "it passed WCAG" means "it's accessible." Contrast and CVD are different axes. A palette can clear 4.5:1 everywhere and still collapse into mush in deuteranopia. Test both.
• Designing only on your own perfect monitor. The same blind spot that hides contrast problems hides CVD ones. Simulate, every time.

None of this asks you to design ugly interfaces or to abandon color. Color is wonderful and you should use it freely. The discipline is just this: let color be the delightful layer, never the only layer. Pair every meaningful hue with a label, an icon, or a shape; pick pairings that survive red-green collapse; lean on lightness as much as hue; and run the simulator before you call it done. Do that, and the next engineer who can't see your green dots will still know exactly which servers are on fire.