How Color-Blind Users See Your Palette: A Six-Type Self-Check and Safe Colors

About 8% of men and 0.5% of women have some form of color vision deficiency — for a developer that means 1 in 12 male visitors sees your palette differently than you do. The classic failure shapes: red errors and green success distinguished by color alone, red-green dual-line charts, dark-red buttons on dim-green backgrounds. This post is a self-check method; the fastest validation is running your key colors through all six types in the color blindness simulator.

The six types at a glance

The two anomalies together account for ~6% — the largest group you need to accommodate. They don't see no color; they see the two colors you carefully picked as "obviously different" converge.

The self-check: three pairs you must test

Skip the color science; memorize three high-risk pairs and test each at design sign-off:

1. Semantic pair: success green vs error red — the all-time classic. If the simulation converges them, switch to a dual channel: color plus icon/text (✓/✗ prefixes);
2. State pair: primary button vs disabled state, link color vs body text — if disabled states only drop saturation, several vision types will confuse them with active ones; add reduced opacity or graying;
3. Chart palette: the first 3-4 line colors must stay pairwise distinguishable across all six simulations. A red-green-blue palette fails by construction — use a luminance ladder plus widely-spaced hues (blue/orange/yellow/gray).

Paste each candidate color into the simulator and compare the six results side by side — when two columns land near the same output, that pairing is broken. Contrast itself is a separate hard line (4.5:1 for text); run it together with the WCAG contrast guide — two legs, both required.

How the simulation works (and where it stops)

Color-blindness simulation is not an arbitrary "turn red into green" mapping; it's a linear color transform grounded in cone-deficiency models: each type corresponds to a 3×3 matrix that projects normal-trichromatic RGB into the color space perceivable by that type. The protanopia matrix removes the independent long-wavelength cone channel, compressing red-green information onto one dimension — which is why red and green inputs land on nearby outputs.

Know its boundary too: the simulation answers "are these two colors distinguishable under this type", not "this is the subjective experience of a color-blind person" (individual variation and neural compensation exist). For engineering separability checks it's sufficient; as an experience replica it overclaims — a boundary every mainstream simulator shares, honestly stated.

Three principles for safe palettes

1. Luminance ladder first: a palette that survives full grayscale keeps hierarchy for all six types. Check levels in grayscale before adding color;
2. Multiple channels: color is never the sole carrier — icons, text labels, underlines, shapes; pick at least one backup;
3. Avoid pure red-green pairs: when red-green semantics are required, offset luminance (light green vs dark red) and add icons, then verify in simulation before signing off.

Tooling: run candidates through the blindness simulator, check contrast separately, and for ready references the neutral ladder in the Tailwind palette finder is a good grayscale starting point.

Implementer's note

The site's simulator is a textbook matrix transform: six types, one 3×3 matrix each; input color parses to RGB, matrix-multiplied, clamped to [0,255], and returned as Hex — a pure, stateless function that yields all six results in milliseconds. The interaction is deliberately "single color in, six-type grid out" rather than whole-image filter simulation: image filters can't recolor your CSS, while what a designer actually needs is "what does this exact hex become under each type" — click any result to copy the transformed hex and swap it into the design tool. The six matrices come from published vision-research parameters; protanopia/deuteranopia (dichromacy) and protanomaly/deuteranomaly (anomalous trichromacy) are four independent matrices — anomaly is not a scaled-down blindness but a different cone state, and conflating them falsifies design verification for the anomaly majority.

FAQ

Can a simulator represent every color-blind user?

No — it's a separability approximation: whether two colors converge under a type. Individual variation means real experience differs; use it for engineering self-checks, not as a substitute for user research.

Why separate matrices for protanopia and protanomaly?

Dichromacy (a cone class missing) and anomalous trichromacy (a cone class spectrally shifted) are different physiological states with different projections — anomaly is milder but not a scalar of blindness.

Does WCAG mandate anything about color vision?

WCAG 1.4.1 (Use of Color) requires color not be the only means of conveying information — the source of the multi-channel principle here. The contrast requirement (1.4.3) is a separate criterion; pass both.

Beyond red-green, what gets missed?

Tritanopia (blue-yellow) is rare, but blue links vs purple visited states and blue-on-yellow text expose it in simulation; achromatopsia is the standing reminder that any design must remain usable in full grayscale.

This self-check note comes from building the color blindness simulator at ToolVault; the six-matrix and anomaly-vs-dichromacy decisions are written into the tool's comments.

Field note

The first version covered only the three dichromacy types; adding the two anomalies came after reading prevalence data — anomalous trichromats (~6%) outnumber dichromats (~2%) by an order of magnitude, and testing only full blindness misses the largest affected group. The "single-color grid over whole-image filter" choice came from our own design loop: re-rendering full mockups per color tweak was too slow to survive a real workflow.