Designing for Color Blindness

Color vision deficiency (CVD) is common enough that it should be a default design constraint, not an edge case handled after launch. Roughly 8% of men and 0.5% of women of Northern European descent have some form of red-green CVD — the most common by a wide margin — with lower but non-trivial prevalence across other populations. That's a large enough share of most user bases that shipping a UI where hue alone carries critical meaning is a genuine functional bug for a meaningful slice of users, not a hypothetical.

The three main types, and what each actually does

CVD isn't one condition — it's a family of conditions tied to which of the eye's three cone types (long, medium, short wavelength — roughly red-, green-, and blue-sensing) is affected, and how severely:

• Protanopia/protanomaly — reduced or absent function in long-wavelength (red-sensing) cones. Reds appear darker and can shift toward looking similar to certain greens and browns; the red end of the spectrum is generally compressed.
• Deuteranopia/deuteranomaly — reduced or absent function in medium-wavelength (green-sensing) cones. This is the single most common form of CVD. Greens and reds both shift toward a similar yellowish-brown range, which is exactly why red/green status indicators are the most frequently cited accessibility failure in UI design.
• Tritanopia/tritanomaly — reduced or absent function in short-wavelength (blue-sensing) cones. Much rarer than the red-green forms (well under 1% of the population). Blues and yellows become hard to distinguish, and blue can shift toward green.

"-opia" suffixes (protanopia, deuteranopia, tritanopia) refer to complete absence of that cone type's function; "-anomaly" suffixes (protanomaly, deuteranomaly, tritanomaly) refer to a cone type that functions but with a shifted sensitivity peak, producing a milder version of the same distortion. Full dichromacy (the "-opia" forms) is less common than the corresponding anomalous trichromacy, but both produce the same category of confusion, just at different severities.

How the simulation actually works

This site's color blindness simulator implements the Machado, Oliveira & Fernandes (2009) dichromacy model — a widely-used, empirically-derived set of full-severity (100%) transform matrices applied directly to gamma-encoded sRGB values. Each CVD type gets its own fixed 3×3 matrix; simulating deuteranopia on a given RGB triple looks like this:

const DEUTERANOPIA = [
  0.367322, 0.860646, -0.227968,
  0.280085, 0.672501,  0.047413,
 -0.01182,  0.04294,   0.968881,
];

function simulate(rgb, m) {
  return {
    r: m[0]*rgb.r + m[1]*rgb.g + m[2]*rgb.b,
    g: m[3]*rgb.r + m[4]*rgb.g + m[5]*rgb.b,
    b: m[6]*rgb.r + m[7]*rgb.g + m[8]*rgb.b,
  };
}

Each row's coefficients project the original RGB triple into the reduced gamut a person with that specific CVD type actually perceives — notice the negative coefficients, which model how one channel's contribution gets partially cancelled by another once the corresponding cone signal is missing. This is a simplified, sRGB-space approximation of a more complex physiological process (real CVD simulation research also works in cone-response and LMS space), but it's accurate enough to be the standard reference most browser-based simulators — including this one — build on.

Concrete design patterns that hold up under all three types

Never encode meaning in hue alone. Pair every color-coded status, category, or action with at least one non-color signal: an icon (checkmark vs. X), a text label, a distinct shape, or a border-style difference (solid vs. dashed). A red "error" badge and a green "success" badge that differ *only* in hue at similar lightness collapse toward the same muddy color under deuteranopia simulation — add a checkmark or warning icon and the distinction survives regardless of color perception.

Favor lightness/darkness differences over hue differences when hue is your only tool. If a chart or map genuinely needs to encode more categories than can reasonably get icons, prioritize keeping adjacent categories far apart in lightness, not just hue — a large lightness gap remains visible even when hue discrimination is impaired, because lightness perception is largely independent of the cone-type deficiencies that cause CVD.

Test the specific pairings that carry meaning, not just the palette in the abstract. Run your actual error/success/warning color set — not a generic palette — through the color blindness simulator for all three types. A palette can look fine in isolation and still produce two specific same-role colors (say, "warning" and "error") that become indistinguishable once simulated, because the failure is about the relationship between specific pairs, not any single color's inherent legibility.

Blue-orange and blue-red pairings are generally safer than red-green for status coding, precisely because they don't collapse under the two most common CVD types. This isn't a universal fix — tritanopia exists — but given that red-green CVD is dramatically more prevalent than blue-yellow CVD, a status system built on blue/orange contrast will serve more color-vision-deficient users correctly than one built on red/green, all else equal.

This is a distinct problem from contrast checking

It's worth being explicit that color blindness and WCAG contrast are two separate axes of accessibility, not one problem measured two ways. A pairing can pass every WCAG luminance-contrast threshold — see WCAG contrast explained for that formula — and still fail for a color-blind user, because contrast is about the luminance (brightness) difference between two colors while CVD is about hue discrimination, which the standard contrast formula doesn't model at all. A complete accessible-palette workflow checks both independently; see choosing an accessible color palette for combining the two checks into one process, and accessible data visualization color for how this plays out specifically in charts, where the category count is often higher and the stakes for confusion are correspondingly higher too.

Anecdotal versus measured: don't rely on "it looks fine to me"

A specific trap worth naming: a designer or reviewer without CVD looking at a palette and pronouncing it "obviously fine" is not a meaningful check, precisely because the entire failure mode is invisible to someone with typical color vision — that's what makes it a real accessibility gap rather than a subjective taste disagreement. Simulation tools exist because self-assessment by non-affected reviewers systematically misses this category of problem; treat a CVD simulation pass as a mandatory step in the same category as a contrast check, not an optional nice-to-have that gets skipped when a deadline is tight. Genuinely colorblind team members or user testers, where available, remain the gold-standard check beyond any simulator — a simulation matrix is a well-validated approximation, not a perfect substitute for lived experience with a real visual system.