One in twelve men can't distinguish red from green. Your error states, charts, and status indicators may be invisible to them — not because of contrast, but because color is the only signal.
You ship a form. Validation fires. Fields with errors turn red, fields that passed turn green. A user writes in: "your form is broken, I can't tell which fields I need to fix." You check your contrast ratios — they pass WCAG AA. The hex values look fine on your screen. The problem isn't contrast. The problem is that color is the only signal, and for roughly one in twelve men, red and green are nearly indistinguishable. The fix takes about twenty minutes. You just have to know it's needed.
1. Who's actually affected — and how
Color vision deficiency is more common than most designers realize. Roughly 8% of men and 0.5% of women of Northern European descent have some form of it — a figure that's been consistent in ophthalmology research since the 1960s. It's X-linked, which is why it skews heavily male. On a team of twelve male engineers, odds are one of them has it and has just learned to work around the world as it is.
The most common variants are deuteranomaly and deuteranopia — both affect the green-sensitive cones, making red-green distinction difficult to impossible. Protanopia does the same from the red-cone side. Together these account for around 6% of men. Tritanopia (blue-yellow confusion) is far rarer, under 0.01%. Monochromacy — seeing no color at all — is rarer still, roughly 1 in 30,000.
The practical implication: red-green is where almost all real-world problems occur. Blue-yellow and full monochromacy are edge cases worth keeping in mind, but if you test nothing else, test your UI against a deuteranopia simulation and you'll catch the majority of failures.
2. The red/green trap
Form validation is the most common offender. Red border = error, green border = success — and that's the entire signal. A deuteranope sees two shades of brownish-yellow and has no idea which is which.
It's not just forms. Stock tickers that show gains in green and losses in red. Dashboard status lights with green = healthy, red = down. Map legends where land and water use similar luminance but different hues. Calendar heatmaps where frequency is communicated entirely through a red-to-green gradient. Git diff tools where additions are green and deletions are red with no other visual distinction.
The interesting thing is that most of these failures aren't lazy — the designers clearly thought about it. They just thought about the wrong thing. They checked whether the red was "accessible" in terms of contrast against the background. That's a different question from whether red and green are distinguishable from each other.
3. Contrast ratios don't protect you here
WCAG contrast requirements measure luminance difference between text and its background. A red #cc0000 on white gives you a ratio around 5.9:1 — comfortably above the 4.5:1 AA minimum. A green #228B22 on white gives you roughly 5.7:1. Both pass. Neither tells you anything about whether those two colors look different to someone with deuteranopia.
This is the gap between WCAG's "Use of Color" criterion (1.4.1) and its "Contrast" criterion (1.4.3). They're checking different things. Passing 1.4.3 doesn't mean you pass 1.4.1, and vice versa. Most accessibility audits catch contrast failures because they're automatable. The color-as-sole-signal failures require knowing what you're looking for — they don't light up in automated scans.
The quick manual test: convert your screenshot to grayscale. If the two states you're communicating look identical in grayscale, color-blind users are probably in trouble. Grayscale is a rough proxy for luminance, which is closer to what a protanope perceives than the full hue range.
4. Charts and data visualization
Data viz is where this bites hardest, because the problem compounds. A line chart with four colored lines and a legend — where the legend uses the same colors as the lines — can become completely unreadable when two of those lines are red and green. A pie chart with five slices distinguished only by fill color. A scatter plot where two groups are encoded as red dots and green dots with no other visual attribute.
The canonical fix is redundant encoding: use both color and at least one other visual attribute. Line style (solid, dashed, dotted). Marker shape (circle, square, triangle). Pattern fill in bar charts. Direct labels on the chart instead of a separate legend. These work for everyone — including users on monochrome printers, which nobody ever designs for but the redundant-encoding fix covers anyway.
For heat maps and continuous color scales, the solution is to pick a palette that works in simulation. The Viridis scale (blue-to-yellow) and the CIELAB-based ColorBrewer diverging palettes were specifically designed to be perceptually uniform across color vision types. The red-green traffic-light palette wasn't designed for anything — it just got adopted because traffic lights use it.
"Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element."
— WCAG 2.1, Success Criterion 1.4.1: Use of Color (W3C, royalty-free use permitted)
That criterion is the entire rule. It doesn't say "don't use color." It says don't use color as the only signal. An error state that's red and has an error icon and has inline error text satisfies it. An error state that's just red doesn't.
5. The fixes that actually work
For form validation: add an icon (✓ and ✗ work fine), and put the error message inline beneath the field — not just a color change on the border. The border color can stay; it just can't be the only thing.
For status indicators: add a text label or an icon alongside the dot. "● Online" vs "● Offline" with shapes that differ (filled circle vs hollow circle, or triangle vs circle) beats any color-only approach.
For charts: test in simulation before shipping. The Chrome DevTools "Rendering" panel has a built-in color vision deficiency emulator — open it, select "Deuteranopia," and look at your chart. Figma has a plugin called "Color Blind" that does the same in the design tool. Our color blindness simulator can run images through all the major deficiency types directly in your browser without uploading anything.
For palette selection: run your foreground and background colors through a contrast checker before settling on a combination. Passing luminance contrast doesn't mean you've solved the color-only-signal problem, but failing it means you have two problems. The WCAG contrast checker gives you the exact ratio against each WCAG level, and the image contrast checker is useful when you want to analyze an existing screenshot or design export rather than isolated hex values.
The part designers skip
Most accessibility work on color blindness stops at "use a different palette." That's necessary but not sufficient. The real question is structural: does your UI communicate anything using color as the sole distinguishing attribute? If yes, add a second signal. It doesn't have to be ugly — the best-designed interfaces already have redundant encoding baked in, because it makes the UI clearer for everyone, not just users with atypical color vision. A label, an icon, a shape change. Twenty minutes to fix, eight percent of your male users to benefit.
← All articles