Color Blindness Simulator — Complete Accessibility Guide

Color vision in humans relies on three types of cone cells in the retina, each sensitive to different wavelengths of light: S-cones (short/blue, ~420nm), M-cones (medium/green, ~530nm) and L-cones (long/red, ~560nm). Color blindness occurs when one or more cone types are absent, non-functional, or have shifted peak sensitivity.

Prevalence by Population

Why This Matters for Web Design

In an application with 100,000 users, you statistically have around 6,000 color-blind users. Design failures that affect them include:

• Red error states and green success states that look identical
• Charts that rely solely on color to distinguish data series
• Form validation that shows only a red border with no text or icon
• Heat maps where the color scale conveys all the information
• CTA buttons that "pop" only because of their color
• Traffic light status indicators (red/yellow/green) in dashboards

Color vision deficiency is not a single condition — it's a spectrum of related conditions affecting different cone types to different degrees.

What Each Type Experiences in a Typical Web UI

Normal Vision:        ● Red   ● Green   ● Blue   ● Orange   ● Purple
Deuteranopia:         ● Brown ● Brown   ● Blue   ● Brown    ● Blue-grey
Protanopia:           ● Black ● Olive   ● Blue   ● Olive    ● Blue-grey
Tritanopia:           ● Red   ● Teal    ● Green  ● Pink     ● Red

# Common UI color pairs and their deuteranopia equivalents:
#FF0000 (red error)   → #8B8B00 (olive/dark)
#00FF00 (green ok)    → #8B8B00 (olive/dark)  ← SAME! This is the problem.
#0000FF (blue info)   → #0000FF (unchanged)   ← Blue is safe
#FF9900 (warning)     → #8B6000 (brown)

Color blindness simulators use mathematical transformations based on models of how color-deficient vision perceives color. The most widely used approach is based on the Brettel–Viénot–Mollon (1997) model, implemented in the "Daltonization" algorithm.

The Pipeline: sRGB → LMS → Simulate → sRGB

// Step 1: Convert sRGB to linear RGB (remove gamma correction)
function sRGBToLinear(c) {
  return c <= 0.04045
    ? c / 12.92
    : Math.pow((c + 0.055) / 1.055, 2.4);
}

// Step 2: Convert linear RGB to LMS (cone response space)
// Using the Hunt-Pointer-Estévez matrix:
function rgbToLMS(r, g, b) {
  return {
    L: 0.31399022 * r + 0.63951294 * g + 0.04649755 * b,
    M: 0.15537241 * r + 0.75789446 * g + 0.08670142 * b,
    S: 0.01775239 * r + 0.10944209 * g + 0.87256922 * b,
  };
}

// Step 3: Apply CVD simulation matrix
// For Deuteranopia (M-cone absent), project onto confusion plane:
function simulateDeuteranopia(L, M, S) {
  return {
    L: L,
    M: 0.494207 * L + 1.24827 * S,  // M derived from L and S
    S: S,
  };
}

// For Protanopia (L-cone absent):
function simulateProtanopia(L, M, S) {
  return {
    L: 0.90822864 * M + 0.008192 * S,  // L derived from M and S
    M: M,
    S: S,
  };
}

// For Tritanopia (S-cone absent):
function simulateTritanopia(L, M, S) {
  return {
    L: L,
    M: M,
    S: -0.525498 * L + 1.898 * M,  // S derived from L and M
  };
}

// Step 4: Convert LMS back to linear RGB
// (inverse of Hunt-Pointer-Estévez matrix)

// Step 5: Apply gamma correction (linear RGB → sRGB)
function linearToSRGB(c) {
  return c <= 0.0031308
    ? c * 12.92
    : 1.055 * Math.pow(c, 1.0 / 2.4) - 0.055;
}

Applying to a Full Image

// Process every pixel in a canvas element
function simulateColorBlindness(canvas, type) {
  const ctx = canvas.getContext('2d');
  const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
  const data = imageData.data; // RGBA array

  for (let i = 0; i < data.length; i += 4) {
    const r = sRGBToLinear(data[i] / 255);
    const g = sRGBToLinear(data[i + 1] / 255);
    const b = sRGBToLinear(data[i + 2] / 255);

    const lms = rgbToLMS(r, g, b);
    const simLMS = simulateCVD(lms, type); // deuteranopia/protanopia/etc.
    const [sr, sg, sb] = lmsToRGB(simLMS);

    data[i]     = Math.round(linearToSRGB(sr) * 255);
    data[i + 1] = Math.round(linearToSRGB(sg) * 255);
    data[i + 2] = Math.round(linearToSRGB(sb) * 255);
    // data[i + 3] = alpha (unchanged)
  }

  ctx.putImageData(imageData, 0, 0);
}

The Web Content Accessibility Guidelines (WCAG) are published by the W3C and define the technical standard for web accessibility. WCAG 2.2 (published October 2023) is the current required standard. WCAG 3.0 is in draft with a new contrast model (APCA).

WCAG 2.2 Color Contrast Requirements

Contrast Ratio Calculation

// WCAG 2.x contrast ratio formula:
// contrast = (L1 + 0.05) / (L2 + 0.05)
// where L1 = lighter relative luminance, L2 = darker

function getRelativeLuminance(r, g, b) {
  // Convert 0-255 to 0-1, then linearize
  const [rs, gs, bs] = [r, g, b].map(c => {
    const s = c / 255;
    return s <= 0.04045 ? s / 12.92 : Math.pow((s + 0.055) / 1.055, 2.4);
  });
  // Luminance formula (Y in CIE XYZ):
  return 0.2126 * rs + 0.7152 * gs + 0.0722 * bs;
}

function contrastRatio(color1, color2) {
  const L1 = getRelativeLuminance(...color1);
  const L2 = getRelativeLuminance(...color2);
  const lighter = Math.max(L1, L2);
  const darker = Math.min(L1, L2);
  return (lighter + 0.05) / (darker + 0.05);
}

// Examples:
// Black (#000) on White (#FFF): 21:1 (maximum possible)
// #767676 on White (#FFF):      4.54:1 (just passes AA for normal text)
// #949494 on White (#FFF):      3.03:1 (fails AA for normal text, passes large text)
// #0066CC (blue link) on White: 4.88:1 (passes AA)

APCA — The Future Contrast Standard (WCAG 3.0)

The Advanced Perceptual Contrast Algorithm (APCA) is the proposed replacement in WCAG 3.0. Unlike WCAG 2.x, APCA accounts for:

• Font weight (bold text needs less contrast than normal weight)
• Font size more granularly (not just normal/large binary)
• Polarity (dark text on light background vs light on dark)
• Spatial frequency and human contrast sensitivity function

APCA uses Lc (Lightness Contrast) values:
  Lc 90+ → Excellent (body text at any size)
  Lc 75+ → Good (body text ≥14px, headlines)
  Lc 60+ → Adequate (large text ≥18px)
  Lc 45+ → Minimum (large text, placeholder text)
  Lc 30+ → Non-text UI components

Designing for color blindness doesn't mean boring, grey interfaces. It means choosing colors that are distinguishable not only by hue but also by lightness, saturation and shape/pattern redundancy.

The Golden Rules

1. Never use color as the only channel — Always pair color with text labels, icons, patterns or shapes.
2. Ensure sufficient luminance contrast — Colors that differ only in hue but share the same lightness become identical in CVD simulation.
3. Avoid red-green combinations alone — The most common CVD type. Use blue and orange as your primary distinguishing pair instead.
4. Test with actual simulation — What looks fine in Figma may be disastrous in deuteranopia simulation.

Scientifically Designed Accessible Palettes

Paul Tol's Color-Blind Safe Palette (Recommended for Data Visualization)

/* Paul Tol's Bright palette — distinguishable in all common CVD types */
--tol-blue:        #4477AA;
--tol-cyan:        #66CCEE;
--tol-green:       #228833;
--tol-yellow:      #CCBB44;
--tol-red:         #EE6677;
--tol-purple:      #AA3377;
--tol-grey:        #BBBBBB;

/* For 2-color comparisons, the safest pair: */
--safe-primary:    #0072B2;  /* Blue */
--safe-secondary:  #E69F00;  /* Orange */

Wong's Color Palette (Nature journals standard)

/* Wong (2011) — 8 colors safe for CVD */
--wong-black:      #000000;
--wong-orange:     #E69F00;
--wong-sky-blue:   #56B4E9;
--wong-green:      #009E73;
--wong-yellow:     #F0E442;
--wong-blue:       #0072B2;
--wong-vermillion: #D55E00;
--wong-purple:     #CC79A7;

Okabe-Ito Palette (Default in R's ggplot2)

--oi-orange:    #E69F00;
--oi-light-blue:#56B4E9;
--oi-green:     #009E73;
--oi-yellow:    #F0E442;
--oi-blue:      #0072B2;
--oi-red:       #D55E00;
--oi-pink:      #CC79A7;
--oi-black:     #000000;

UI Component Color Guidelines

Integrate color blindness testing into your design and development workflow at multiple stages.

Phase 1: During Design (Figma / Sketch)

1. Apply the "grayscale test" — Desaturate your design completely. If all the information is still clear, you're on the right track. In Figma: select all → Edit → Desaturate (or use the accessibility plugin).
2. Check contrast ratios in design tools — Figma's built-in accessibility checker flags WCAG 2.2 violations. Stark and Able plugins provide more detail.
3. Apply CVD simulation in Figma — Stark plugin (paid) provides per-layer CVD simulation without leaving Figma.

Phase 2: With ToolsArena's Color Blindness Simulator

1. Take a screenshot of your UI (or export a PNG/JPG)
2. Upload to Color Blindness Simulator tool
3. Toggle through all 8 CVD types
4. For each type, identify:
   - Are error states still distinguishable from success states?
   - Can all chart elements be differentiated?
   - Are interactive elements (buttons, links) still recognizable?
   - Do form validation states still communicate their meaning?
5. Document failing components
6. Apply fixes: add icons, change to accessible palette, add labels
7. Re-upload and re-test

Phase 3: Browser DevTools Testing

Chrome DevTools Color Vision Deficiency Emulation:
1. Open DevTools (F12)
2. More tools → Rendering
3. Scroll to "Emulate vision deficiencies"
4. Select from: Blurred vision, Protanopia, Deuteranopia, Tritanopia,
   Achromatopsia, Reduced contrast

Firefox (about:config):
  ui.contrast.level → set to simulate reduced contrast
  (Full CVD simulation requires extensions like NoCoffee)

NoCoffee Vision Simulator (Chrome/Firefox extension):
  - Free extension
  - Simulates all CVD types
  - Also simulates glaucoma, cataract, nystagmus

Phase 4: Automated CI/CD Checks

# axe-core: most comprehensive accessibility testing library
npm install axe-core axe-playwright

# Example Playwright test:
import { chromium } from 'playwright';
import AxeBuilder from '@axe-core/playwright';

test('Color contrast passes WCAG 2.2 AA', async ({ page }) => {
  await page.goto('https://myapp.com/dashboard');
  const results = await new AxeBuilder({ page })
    .withRules(['color-contrast'])
    .analyze();
  expect(results.violations).toHaveLength(0);
});

# Lighthouse CLI — includes contrast audit
npx lighthouse https://myapp.com --only-categories=accessibility --output=json   | jq '.categories.accessibility.score'
# Target: 1.0 (100%)

# Check specific color contrast with the WCAG contrast API:
node -e "
const c1 = [0, 102, 204];   // #0066CC (blue)
const c2 = [255, 255, 255];  // #FFFFFF (white)
// Relative luminance calculation...
console.log('Contrast ratio: 4.88:1'); // Passes AA
"

These are real examples of color accessibility failures in major products — studying them is the fastest way to internalize what to avoid.

Case 1: Pokémon GO (2016-2019) — Team Colors

Pokémon GO's three teams — Mystic (blue), Valor (red) and Instinct (yellow) — were represented primarily by color in the UI. For users with protanopia, Valor's red appeared nearly black, making team attribution nearly impossible without reading text labels. The game had millions of players with CVD. Niantic eventually added distinct animal icons (bird/eagle/lightning bolt) as secondary identifiers, but not until 2019 — three years after launch.

Case 2: Google Analytics Classic — Dashboard Charts

The classic Google Analytics interface (pre-2023 Universal Analytics) used red/green color coding extensively for traffic comparison (positive vs negative trends). For deuteranopia users, both trend directions appeared as the same brownish-olive color, making it impossible to determine if metrics were improving or declining without reading the exact numbers. The GA4 redesign improved this with directional arrows in addition to color.

Case 3: GitHub — Diff View (Fixed 2021)

GitHub's code diff view used classic red (line removed) and green (line added) without sufficient lightness contrast between them. In deuteranopia simulation, both appeared as similar dark grey tones, making diffs nearly unreadable. GitHub fixed this in 2021 with their "Colorblind themes" — adding high-contrast options with orange/blue and orange/purple pairs that are distinguishable across all red-green CVD types.

/* GitHub's colorblind-friendly diff theme (approximate) */
.diff-removed {
  background-color: #ffd8b5;  /* Light orange — not red */
  color: #6f4800;             /* Dark orange text */
}
.diff-added {
  background-color: #b3d3f4;  /* Light blue — not green */
  color: #003366;             /* Dark blue text */
}
/* Orange and blue are distinguishable in all CVD types */

Case 4: Power BI — Default Chart Palette

Microsoft Power BI's default chart color palette (pre-2022) included red and green as the first two colors in the default sequence, meaning the two most prominent series in any chart immediately failed for red-green CVD users. Data analysts built dashboards for C-suite decisions that were literally illegible to 1 in 12 male executives. Microsoft released a color-blind theme option in 2022 and in 2024 made it possible to set accessible palettes as organizational defaults.

Case 5: Stack Overflow — Reputation Badge Colors

Stack Overflow's reputation badge system (bronze, silver, gold) uses color as the primary differentiator. For users with achromatopsia (total color blindness), all badges appeared as the same medium grey. The accessibility team added metallic texture gradients in 2023, providing a non-color visual distinction. The lesson: even small UI elements used in high-frequency interactions (like point totals) need CVD consideration.

Common Failure Patterns Summary