Color Blindness and Web Design: What to Know

More common than most designers realize

Color vision deficiency — commonly called color blindness — affects roughly 8% of men and 0.5% of women. That’s about 1 in 12 men and 1 in 200 women, making it more prevalent than most other disabilities that web accessibility standards address.

Yet it’s routinely overlooked in design. Teams test with screen readers and keyboard navigation, run an automated WCAG scan, and consider the accessibility work done — without ever checking whether their color palette is legible to color-blind users.

Understanding color blindness, and what it actually does to the web interfaces you design, is the first step to fixing it.

The types and what they do

Color vision deficiency comes in several forms, and they don’t all produce the same experience.

Red-green deficiencies (most common)

Protanopia — complete absence of red cone photoreceptors. Red appears dark or black. Red-green distinctions are lost.

Protanomaly — reduced red sensitivity. Red, orange, and yellow shift toward green, and the overall experience is duller, as if the red channel has been turned down.

Deuteranopia — complete absence of green cone receptors. The most common form of color blindness. Green and red are confused; the world looks like it’s filtered through a yellow-brown lens.

Deuteranomaly — reduced green sensitivity. Similar to deuteranopia but milder. The most prevalent type overall, affecting about 5% of men.

Blue-yellow deficiencies (rarer)

Tritanopia — absence of blue cone receptors. Blue appears green, and yellow appears pale or invisible. Rare.

Tritanomaly — reduced blue sensitivity. Blue-green and red-purple are confused.

Monochromacy (very rare)

Achromatopsia — absence of all color cone receptors. Only brightness is perceived; the world appears in shades of grey. Often accompanied by light sensitivity and reduced visual acuity.

How color blindness breaks common web patterns

Knowing the types in the abstract is less useful than knowing which specific design decisions cause problems. These are the most common ones.

Error states indicated only by red

Turning a form field border red to show a validation error is one of the most widespread patterns in web design. For users with red-green deficiency, red on white or red on grey can be nearly invisible, or indistinguishable from a normal unfocused state.

This is covered directly by WCAG 2.2 1.4.1 Use of Color (Level A): color must not be the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

The fix is straightforward: pair color with a second visual indicator — an icon, a text label, a change in border weight, or any other non-color signal.

<!-- Relying on color alone: fails 1.4.1 -->
<input type="email" class="field--error">

<!-- Color plus icon plus text: passes -->
<div class="field-wrapper">
  <input type="email" class="field--error" aria-describedby="email-err">
  <p id="email-err">
    <span aria-hidden="true">⚠</span> Enter a valid email address.
  </p>
</div>

Insufficient contrast

Low contrast is a separate issue from color blindness, but they intersect. Many color palettes that appear readable to typical color vision become even harder to read under color vision deficiency, because the perceived difference between foreground and background shrinks further.

WCAG 1.4.3 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Testing contrast with a tool like the browser’s DevTools color picker or a dedicated checker is non-negotiable — don’t rely on visual inspection.

Data visualization that encodes only in color

A pie chart with six segments differentiated only by color. A map with a red-to-green gradient. A line chart where four datasets are distinguished by hue alone.

For deuteranopia users, red and green become indistinguishable. The chart’s meaning collapses entirely. For more on this, see our guide on accessible data visualization.

Links that rely only on color to stand out from body text

By default, browsers underline links. Many designers remove this underline and rely on color alone to distinguish links from surrounding text. Users with color vision deficiency — and especially those using low-contrast themes — can fail to identify links at all.

WCAG 1.4.1 applies here too. If link color is the only visual indicator (no underline, no bold, no other differentiator), the link is not accessible for color-blind users.

The simplest fix: restore the underline. Alternatively, ensure link color has sufficient contrast against both the body text color and the background.

Designing with color blindness in mind

Use redundant encoding

Add a second visual channel alongside color. In charts: add patterns, textures, or data labels. In status indicators: add icons. In form states: add text. The goal is that someone who strips color from the design entirely can still understand everything.

Test with simulation tools

Chrome DevTools has a built-in color blindness simulation. Open DevTools > Rendering panel > “Emulate vision deficiencies.” You can simulate protanopia, deuteranopia, tritanopia, and achromatopsia.

Figma and other design tools have similar plugins. Running a simulation takes seconds and often reveals problems that weren’t visible in standard preview.

Check your palette as a whole

Don’t just test individual element pairs. Look at the full palette together: primary, secondary, error, success, warning, and informational colors. Under deuteranopia simulation, do error red and success green look similar? If so, you have a problem regardless of whether your contrast ratios technically pass.

Avoid problematic combinations

Particularly unreliable for color vision deficiency:

• Red and green
• Green and brown
• Blue and purple
• Green and grey
• Green and black

When these pairs need to appear in the same context, differentiate them through lightness or pattern rather than hue.

What WCAG does and doesn’t cover

WCAG covers color contrast (1.4.3, 1.4.11) and the prohibition on using color as the sole means of conveying information (1.4.1). It does not specify which colors you can or cannot use, or require that your entire palette be perceivable under every type of color vision deficiency.

What it requires is that no meaning is lost when color is removed. That’s the practical test. Remove the color from your design. Does every piece of information remain accessible through other means?

If the answer is yes, you’ve met the requirement. If error states disappear, if chart data becomes ambiguous, if links become invisible — you have work to do.

Our accessibility audits include color accessibility as a standard part of review. If you want to know where your current design stands, run a free automated scan to catch the automatable issues as a starting point.