About eight percent of men and half a percent of women have some form of colour vision deficiency. Designing only for the colour-vision-typical means excluding a meaningful chunk of your audience. This article is a practical checklist: the colour combinations to avoid, the patterns that work for everyone, and the testing tools that catch the most common mistakes.

What colour blindness actually is

The most common forms are red-green deficiencies (deuteranopia and protanopia), which make it hard to distinguish red and green. Blue-yellow deficiencies (tritanopia) are rarer. Monochromacy (total colour blindness) is very rare. Most colour-blind users are not totally colour-blind; they see a shifted palette where some pairs that look distinct to you look identical to them.

The practical consequence: never use colour as the only way to convey information. A red error message on a red background is invisible. A green "valid" indicator and a red "invalid" indicator may look identical to some users. Always pair colour with another visual cue — an icon, a label, a position, a pattern.

The accessibility checklist

Run through this checklist on every interface you ship:

  • Contrast. Body text against its background should have at least 4.5:1 contrast. Large text (18pt or 14pt bold) needs 3:1. UI controls and graphical objects need 3:1. Use the WebAIM Contrast Checker for verification.
  • Not colour-only. Every state conveyed by colour should also be conveyed by shape, text, or position. Error: red icon + "Error" text + red border. Success: green icon + "Success" text.
  • Charts. Use colour-blind-safe palettes (below). Add labels directly on lines, not just in a legend.
  • Form validation. Pair the red error colour with an icon, a message, and a focus ring.
  • Links. Underline links, or use a combination of colour and weight. Colour-only links are invisible to many users.

Colour-blind-safe palettes

The palettes below are designed to be distinguishable across the most common forms of colour vision deficiency. The classic choices are ColorBrewer and the Wong palette:

/* Wong palette (colour-blind safe) */
--cb-blue:    #0072B2;
--cb-orange:  #E69F00;
--cb-green:   #009E73;
--cb-yellow:  #F0E442;
--cb-purple:  #CC79A7;
--cb-red:     #D55E00;
--cb-grey:    #999999;

For sequential data, the viridis, magma, and inferno colormaps are perceptually uniform and colour-blind-safe. For categorical data, stick to the seven colours above.

Tools for testing

Several tools let you preview your design as a colour-blind user would see it:

  • Chrome DevTools has built-in vision deficiency emulation. Open the Rendering tab and choose Protanopia, Deuteranopia, or Tritanopia.
  • Sim Daltonism (macOS) and Color Oracle (cross-platform) simulate colour vision deficiencies on your entire screen.
  • Stark is a Figma and Sketch plugin for contrast and colour-blind checking during design.

Run every design through these tools before shipping. The discipline takes minutes and prevents a real class of usability bugs.

Patterns that work

Beyond the colour itself, several patterns help everyone:

  • Icons + colour. A red error icon, a green success icon, a yellow warning icon. Even without colour, the shape conveys meaning.
  • Patterns in charts. Add dashed lines for one series, dotted for another. Visible to all.
  • Position and hierarchy. Important information should be visually distinct by size, weight, and position, not just colour.
  • Direct labelling. Instead of a tiny legend that says "red line = revenue", put the label next to the line itself.

Common mistakes

  • Red and green for error/success. The single most common colour-blindness issue. Use red/blue, or red/green with patterns.
  • Low-contrast grey text. Light grey on white may look elegant but fails accessibility. Use a minimum of 4.5:1.
  • Hover states that only change colour. Combine colour changes with underline, weight, or background fill.
  • Form fields that turn red without explanation. Always show an error message in addition to the colour change.
  • Charts that rely on a rainbow palette. Use a colour-blind-safe palette and add patterns or direct labels.

A more advanced thing: dark mode considerations

Dark mode adds another layer of complexity. Saturated colours look more vibrant on dark backgrounds, which can amplify contrast issues. Test your dark-mode palette in colour-blindness simulators — what looks balanced in light mode can be jarring in dark mode.

For data visualisation in dark mode, consider using pastel or muted versions of your brand colours. They are easier on the eyes and produce better contrast against dark backgrounds.

The different types of colour vision deficiency

Understanding the specific deficiencies helps you design better.

  • Protanopia / Protanomaly — reduced sensitivity to red light. Reds appear darker; red and orange may look the same. Most common form.
  • Deuteranopia / Deuteranomaly — reduced sensitivity to green light. The most common form. Greens appear more beige; reds and greens may be confused.
  • Tritanopia / Tritanomaly — reduced sensitivity to blue light. Rare. Blues appear greenish; yellows may appear pinkish.
  • Achromatopsia — total colour blindness. Very rare. The world appears in greyscale.

Most colour-blind users have one of the red-green deficiencies. Designing for deuteranopia (the most common) covers the bulk of cases.

Beyond colour: typography for accessibility

Typography choices have accessibility implications beyond colour:

  • Body text size. Minimum 16px for body text on the web. Smaller sizes are hard to read for many users.
  • Line height. 1.5 to 1.7 is the accessible sweet spot. Tighter line heights make text harder to follow.
  • Line length. Aim for 50 to 75 characters per line for body text. Longer lines tire the eye.
  • Font choice. Use fonts designed for screen reading, with open apertures and clear letter shapes. Avoid display fonts for body text.
  • Justification. Left-aligned text is more accessible than justified text, which can produce large gaps between words.

These choices affect everyone, not just colour-blind users. Designing for accessibility usually results in better experiences for all.

Designing for low vision

Many users with low vision use screen magnification, high-contrast modes, or zoom the entire page. Design for that:

  • Avoid fixed pixel sizes that prevent the page from being zoomed correctly.
  • Test your layouts at 200% browser zoom. Anything that breaks is broken.
  • Provide high-contrast themes via CSS custom properties.
  • Avoid relying on hover for essential information — many low-vision users have trouble with small cursor targets.

Designing for low vision often catches issues that affect users on small displays too. The discipline of "would this work for someone zooming at 200%?" is a useful filter.

Real-world examples: getting it right

A few patterns we have seen work well in production:

  • GitHub's status checks. A green check or red X icon, with text labels ("3 passed", "1 failed"). Colour is supplementary, not primary.
  • Stripe's error states. Red borders on invalid fields, plus inline error messages with icons. The colour says "something is wrong"; the text says what.
  • Datawrapper's chart palettes. Colour-blind-safe palettes are the default, with patterns available for charts that need extra distinction.

Look at the apps you use every day. Which ones communicate clearly without colour? Those are the models to study.

Testing with real users

No amount of automated testing replaces watching a real colour-blind user try to use your interface. If you can, recruit one or two people with colour vision deficiencies and ask them to complete key tasks. Watch where they hesitate, where they ask "what does this mean", where they need to lean in close. Those are your design bugs.

Many design teams have a standing relationship with accessibility consultants or a community of disabled users who provide feedback. It is the most expensive kind of testing but also the most reliable.

The business case

Colour-blindness is not a niche concern. Eight percent of men is a substantial chunk of any audience. For a B2C app with a million users, that is 80,000 people who may be struggling with your interface right now. For a B2B app, accessibility is often a procurement requirement — large organisations will not buy software that fails WCAG.

Designing for colour blindness is also just good design. Interfaces that work for everyone tend to be cleaner, more legible, and easier to use for all users. The investment pays off in ways beyond the obvious accessibility wins.

Further reading

Color accessibility is small but high-impact. These are the tools and references we use on every interface project.

FAQ

What is the WCAG contrast formula?

A formula that compares the relative luminance of two colours and returns a ratio. 4.5:1 means the foreground is 4.5 times brighter than the background, perceived. Tools like the WebAIM Contrast Checker do the math for you.

Are gradients colour-blind-safe?

Generally yes, because they vary continuously rather than in discrete steps. But ensure the start and end colours have enough contrast and that key information is not encoded only at the colour extremes.

What about icons-only buttons?

Provide an accessible name via aria-label. The icon may be unrecognisable to a colour-blind user (or anyone unfamiliar with the iconography), but the screen reader will read the label. Visible tooltips on hover help too.

How do I tell if a colour is too similar to another?

Convert both to greyscale. If they look the same in greyscale, they will look the same to monochromats and similar to many colour-blind users. Several tools automate this check.

What about brand colours that fail contrast?

Use them for accents and large text, where lower contrast is more forgiving. For body text, choose a colour from the same brand family that meets the contrast requirement. Most brand palettes can accommodate this.

Take it slow and verify each fix in the simulators before shipping.

Take a methodical approach, run the simulators, and iterate on the design.

Take it slowly and use the simulators throughout the process to verify your work.

The discipline of designing for colour blindness is the discipline of designing for everyone. The patterns that work for the colour-blind tend to work for users on small screens, in bright sunlight, with temporary disabilities, with assistive technology. The investment compounds across every user you have.

Take it methodically.

Homework

Audit an existing interface using the tools and patterns in this article:

  • Run every page through Chrome's vision-deficiency emulation. Note any places that become unreadable.
  • Check every text/background pair with the WebAIM Contrast Checker.
  • Replace any colour-only indicators with icon-plus-colour combinations.
  • Update your charts (if you have any) to a colour-blind-safe palette.
  • Test dark mode (if you have it) in the same simulators.

The exercises above will catch the vast majority of colour-related accessibility issues. For the broader accessibility context, see our Web Accessibility for Beginners article.