Skip to main content

Color Blindness Simulator: Designing Charts and UI That Don't Rely on Color Alone

A practical guide to testing your designs for protanopia, deuteranopia, and tritanopia, and fixing red-green charts that fail for the ~8% of men with color vision deficiency.

Published By Li Lei
#accessibility #color blindness #design #wcag #data visualization

Color Blindness Simulator: Designing Charts and UI That Don't Rely on Color Alone

About 1 in 12 men sees color differently than you do. That is not a rounding error. If your product has a hundred thousand male users, roughly eight thousand of them will struggle with a red-green status indicator that looks perfectly obvious to you. Most designers never notice because the deficiency is invisible from the outside, and the affected users have spent a lifetime working around interfaces that were never built with them in mind.

A color blindness simulator closes that gap. It takes a hex code, a palette, or a full screenshot and shows you the same view through the eyes of someone with a color vision deficiency. You stop guessing whether your chart works and start seeing exactly where it breaks.

The three deficiencies you actually need to test

Color vision deficiency comes in several flavors, but three dichromacies cover the cases that matter most for design work.

  • Protanopia is the absence of the L-cone, the one tuned to long-wavelength red light. Reds darken dramatically and shift toward muddy browns.
  • Deuteranopia is the absence of the M-cone, tuned to green. This is the most common form by a wide margin, and it is the reason red-green confusion is the headline problem in accessibility work.
  • Tritanopia is the absence of the S-cone, tuned to blue. It is far rarer, around 0.01% of people, and it collapses blue-yellow and purple-blue distinctions rather than red-green ones.

The headline number to remember: deuteranopia and its milder cousin deuteranomaly are the most common, and red-green confusion as a whole affects roughly 8% of men (and well under 1% of women, because the genes sit on the X chromosome). Around three quarters of those cases are anomalous trichromacy, where the cone exists but is shifted, and a quarter are full dichromacy. A robust design has to survive both ends of that spectrum, which is why testing against eight panels at once beats spot-checking a single condition.

A red-green status chart that fails

Here is the worked example I show every new designer. Imagine a service health dashboard with six lines: API latency, error rate, throughput, queue depth, cache hits, and CPU. The original palette uses #E63946 red for the failing series and #2A9D8F green for the healthy one, because red-means-bad and green-means-good is the most obvious convention on earth.

Paste both hex codes into the color blindness simulator and switch to the deuteranopia panel. The red and the green both drift toward a near-identical muddy tan. A deuteranopic engineer staring at an incident at 2am literally cannot tell the failing line from the healthy one. The single most important signal in your dashboard has just disappeared for one in twelve of your male users.

The fix is not "pick a different green." Any two hues can collapse under some deficiency. The fix is to stop encoding meaning in hue alone:

  1. Add a shape or icon. A solid check on the healthy series and an outlined cross on the failing one carry meaning with zero color dependency.
  2. Add a direct label. Writing "Errors" and "Healthy" next to the lines means the color becomes redundant reinforcement rather than the sole channel.
  3. Open a luminance gap. Swap the green for a darker teal so the two lines differ in lightness, not just hue. Two colors that contrast in lightness stay distinguishable even under full achromatopsia, where the entire image becomes grayscale.

Re-run all eight panels after the fix. When the failing line stays readable in the protanopia, deuteranopia, tritanopia, and achromatopsia panels alike, you are done. That last grayscale panel is the brutal honest one: if a distinction survives there, it survives everywhere.

Why hue contrast and luminance contrast are not the same thing

This is the trap that catches people who think they already understand the problem. Red and green sit at opposite ends of the spectrum, so they feel maximally different. But "opposite hue" and "different brightness" are independent properties. Two colors can be hue-opposites while having nearly identical luminance, and the moment you remove the cone that distinguishes their hue, they become twins.

The practical rule that comes out of this: maximize luminance contrast between adjacent categories, not just hue contrast. A bright red against a dark green survives every deficiency because the brightness gap does the work that hue cannot. Run each foreground and background pair through a color contrast checker and you will see the numbers behind the intuition. Luminance contrast is also exactly what WCAG 1.4.3 measures, so you get accessibility-compliance and color-blind safety from the same discipline.

How I actually use this in a real audit

I run accessibility audits for client design systems, and the color blindness simulator is the first tool I open, not the last. When a client insists their palette is "already accessible because we used the brand colors," I do not argue. I drop their live pricing-page screenshot into the image mode, screenshot the deuteranopia and achromatopsia panels, and paste them side by side into the report. The "Recommended" badge that relied on a thin green outline simply vanishes into the background. That single image ends the debate faster than any explanation, because the client is now looking at their own product through their own users' eyes. I have never had a stakeholder push back on a finding once they have seen the grayscale panel.

A checklist for color-blind-safe design

Pull these together and you have a repeatable process:

  • Never encode meaning in hue alone. Pair every color with an icon, label, pattern, or position. This is the literal text of WCAG 1.4.1, and it is the single rule that protects you against every deficiency at once.
  • Avoid the three classic confusion pairs. Red and green collapse for protan and deutan viewers, blue and yellow for tritans, purple and blue for tritans. If two adjacent categories use a confusion pair, expect trouble.
  • Test at the real size. A distinction that holds in a 200px swatch can vanish in a 12px chart legend or a 1px border. Check colors at the size they actually appear in your interface.
  • Scan all eight panels, not two. A blue-yellow chart can sail through red-green checks and still fail tritans. A purely hue-based legend dies under full achromatopsia. The deficiency you forget to test is the one that ships broken.

Color blindness is not an edge case you can defer to a future sprint. It is a permanent property of roughly 8% of your male audience, and designing for it costs almost nothing once it becomes a habit. Build the simulator check into your design review the same way you build in a spell check, and your charts will work for everyone before they ever reach a user who needs them to.


Made by Toolora · Updated 2026-06-13