A little help goes a long way. Find a tool/

Design FIELD NOTES · 3 MIN READ

How Color Blindness Simulation Works

The matrices behind CVD simulation: the eight conditions, why red goes dark under protanopia, and what a simulator can and cannot tell you.

Roughly 1 in 12 men and 1 in 200 women have some form of color vision deficiency, which means any palette you publish will be read differently by part of your audience. A color blindness simulator estimates how a color survives that translation — by passing its red, green and blue channels through a small matrix of numbers, one matrix per condition.

Eight simulations from three cone errors

Color vision depends on three cone cells tuned to long (red), medium (green) and short (blue) wavelengths. Deficiencies are named after the cone that misbehaves: protan defects weaken red perception, deutan defects weaken green, and tritan defects weaken blue. Each comes in a complete form — the -opia suffix, where the cone's contribution is essentially absent — and a partial form, the -omaly suffix, where it is merely muted. That 3 × 2 grid gives six simulations, and two further conditions complete the picture: achromatopsia (no color vision at all) and achromatomaly (severely faded color). Deutan defects are the most common overall, which is why red-green confusion is the case everyone tests first.

The math is one matrix multiply

Each simulation applies a 3×3 matrix to your color's normalized RGB values and clamps the results back into the visible range. The matrices used here are the published values from Machado, Oliveira and Fernandes (2009), the standard reference for both dichromat (-opia) and anomalous trichromat (-omaly) simulation — the complete forms use the full-severity matrices, the partial forms the severity-0.5 ones. In practice the matrix does not simply delete a channel: it redistributes the missing cone's contribution across the other two, which is why warm colors drift toward yellow-brown rather than disappearing entirely. Achromatopsia is computed instead as greyscale using BT.709 luminance weights (0.2126, 0.7152, 0.0722), and achromatomaly as a half-way blend between the original color and that grey, so partial conditions genuinely sit between normal vision and the complete form.

The red-green collapse, in real numbers

Take a typical error-red, #e74c3c. Under deuteranopia the simulator returns #89773b — an olive brown — and under protanopia #675c3b, a darker olive. Now take a typical success-green, #2ecc71: deuteranopia gives #a79b76, protanopia #c7b16d. All four results land in a narrow band of yellowish browns, which is precisely the danger: two colors that look like an unambiguous red/green pair to a trichromat converge to near-twins for a deutan or protan viewer. Notice also that the protan results are darker than their deutan counterparts — the red cone contributes to perceived brightness, so losing it dims warm colors rather than merely shifting their hue.

What a simulator can and cannot tell you

A simulation answers one question: do these colors remain distinguishable? It does not answer whether text on a background is readable, because readability is a luminance-contrast measurement, not a hue question — a color can shift dramatically under a matrix and still carry perfectly adequate contrast, or look unchanged and still fail badly. The two checks are complementary: simulate to catch hue confusions (status dots, chart series, badge pairs), and measure the contrast ratio for text decisions. For what that ratio is made of, see How Color Contrast Works. And remember the practical caveat of every model: individual vision varies, so treat the output as a well-informed estimate, not a literal view through anyone's eyes.

Try it yourself

The Color Blindness Simulator runs all eight conditions on any hex value — shorthand and alpha included — and copies each simulated hex with one click. Pair it with the Color Contrast Checker for the text-readability half of the audit, and use the Color Palette Generator to rebuild a scheme that survives both checks.

Frequently asked questions

How is this different from a color contrast checker?
A contrast checker measures the luminance ratio between two colors to answer whether text is readable. A CVD simulator transforms colors to estimate whether they remain distinguishable from each other. They catch different failures — a pairing can pass the ratio test while its hues collapse into twins for a deutan viewer, and vice versa — so accessibility work usually needs both.
Which model does the simulation use, and how accurate is it?
It applies the peer-reviewed Machado, Oliveira and Fernandes (2009) matrices — full severity for the -opia forms, severity 0.5 for the -omaly forms — to sRGB values as an approximation for screen work. Individual perception varies, so treat the output as a well-informed estimate rather than anyone's literal view.
Why did my red turn dark brown instead of just changing hue?
The red cone contributes to perceived brightness as well as hue, so under protanopia a red like #e74c3c does not merely shift — it loses luminance and becomes a dark olive (#675c3b). This is why red text and red status dots fail for protan viewers even when some hue difference would survive.
How do I test a whole palette?
Simulate each palette color one at a time and compare the outputs pairwise: if two entries produce nearly identical hex values under deuteranomaly, those are the ones that will be confused. Then re-check any text-bearing pairs with a contrast ratio measurement.
Does the simulation handle shorthand hex and transparency?
Yes. Three-digit shorthand like #f60 is expanded to full RGB before the math runs, and four- or eight-digit hex with alpha keeps its transparency — the alpha byte passes through unchanged to every simulated result.