Red means stop. Green means go. Red means error. Green means success. Red means overdue. Green means paid. If your website relies on this shorthand, roughly 1 in 12 of your male visitors can't tell the difference.
Colour vision deficiency affects approximately 8% of men and 0.5% of women worldwide, with rates as high as 8% of males of Northern European descent. In a country like Canada, that's well over a million men who experience some form of it. And yet we keep building websites that treat red and green as universal signals, as if the entire population perceives colour the same way. They don't, and the fixes are neither difficult nor expensive.
What Colour Blindness Actually Looks Like
Most people picture colour blindness as seeing in greyscale. That's almost never the case. Over 99% of colour blind individuals have some form of red-green deficiency, not a total absence of colour perception. The condition comes in specific, well-documented types, each affecting how the brain interprets light from different parts of the spectrum.
Deuteranopia is the most common form. The green-sensitive cones in the retina are missing or non-functional. Greens shift toward brownish tones, and reds lose their intensity. Protanopia affects the red-sensitive cones instead. Reds appear darker, sometimes nearly black, and are easily confused with greens and browns. These two types account for the vast majority of cases.
Tritanopia is rare, affecting the blue-sensitive cones. Blues and greens become difficult to distinguish, and yellows can appear pinkish. It affects men and women at roughly equal rates because it isn't carried on the X chromosome like the red-green types.
Here's why this matters for web design: the most common default colour pairings we use for status, feedback, and data visualization land directly in the problem zone. A red error message next to a green success message. A traffic-light progress indicator. A chart with red and green data series. For someone with deuteranopia, those colours can appear nearly identical.
We've seen contact forms where the only indication of a validation error was a red border on the input field. No icon, no text, no change in shape. Just a thin red line that a colour blind user literally cannot distinguish from a green "all good" state. That's not a minor usability issue. That's a form that doesn't work for 8% of men.
What WCAG Requires (and What It Doesn't)
The Web Content Accessibility Guidelines address colour usage directly in three success criteria that every web developer should know by heart.
WCAG 2.1 Success Criterion 1.4.1: Use of Color (Level A) is the most relevant. It states that colour must not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. This is a Level A requirement, meaning it's the bare minimum for accessibility conformance. Not aspirational. Mandatory.
The rule is straightforward. If you've used colour to communicate something, you need at least one additional visual cue doing the same job. An icon. A text label. A pattern. A shape. Underlining on links. A border change paired with a symbol. The colour can stay, but it can't be the sole carrier of meaning.
WCAG 2.1 Success Criterion 1.4.3: Contrast (Minimum) (Level AA) requires a minimum contrast ratio of 4.5:1 for normal text against its background, and 3:1 for large text (18px and above, or 14px bold). This isn't specifically about colour blindness, but it matters because colour vision deficiency reduces perceived contrast. A colour pair that barely passes 4.5:1 for someone with typical vision may fall below readable contrast for someone with protanopia.
WCAG 2.1 Success Criterion 1.4.11: Non-text Contrast (Level AA) extends the contrast requirement to user interface components and graphical elements. Icons, form field borders, focus indicators, and chart elements all need a 3:1 contrast ratio against their adjacent colours. That green checkmark icon on a white background? Check the ratio. That subtle grey border on your input fields? Check it again.
If colour is doing work on your website, something else should be doing the same work alongside it. Every single time.
What WCAG doesn't require is avoiding red and green entirely. You can still use them. But you can't use them alone to carry meaning. The distinction matters because some design teams overcorrect and strip all colour from their interfaces, producing something technically compliant but visually flat. Good accessible design keeps colour. It just doesn't rely on it.
Tools That Show You What Your Users See
Testing for colour blindness accessibility used to mean squinting at colour wheels and guessing. Not anymore. Three tools belong in every web team's workflow, and they're all either free or built into software you already have.
Chrome DevTools Vision Simulation
This is the fastest option and requires zero installation beyond having Chrome. Open DevTools, press Ctrl+Shift+P (or Cmd+Shift+P on Mac), and type "rendering." In the Rendering panel, scroll to "Emulate vision deficiencies." The dropdown gives you protanopia, deuteranopia, tritanopia, achromatopsia (total colour blindness), and blurred vision.
Your entire live page renders through the simulation in real time. You can interact with it, fill out forms, hover over elements, and see exactly what a colour blind user experiences. We run this on every site we build before it ships, and we've caught problems in the final review stage that nobody on the team spotted by eye.
This feature has been available since Chrome 83. If you're a web developer and you haven't used it yet, open it today and look at your own site through the deuteranopia filter. The results are often sobering.
Coblis (Colour Blindness Simulator)
Coblis, maintained by Colblindor, takes a different approach. Upload a screenshot or mockup and the tool renders it through each type of colour blindness. All processing happens locally in your browser, so you're not uploading client work to a third-party server.
This is particularly useful early in the design process, before anything is built. Take a screenshot of a Figma mockup, run it through Coblis for deuteranopia and protanopia, and you'll know immediately whether your colour choices hold up. We use it when reviewing design proposals and data visualization concepts. It takes 30 seconds and has saved us from shipping colour-dependent charts more than once.
Stark (Figma and Sketch Plugin)
If your design team works in Figma, Stark runs colour blindness simulations directly inside the design tool. It checks eight types of colour vision deficiency, tests contrast ratios against WCAG standards, and flags problems before a single line of code is written. The free tier covers the basics. The paid version adds batch testing and suggested fixes.
Stark's value is catching problems at the source. Retrofitting colour accessibility into a finished site costs more and takes longer than getting it right in the design file. Designers who run Stark checks as part of their standard process produce work that passes accessibility testing on the first round, not the third.
WebAIM Contrast Checker
Not a colour blindness simulator specifically, but it belongs in this list because contrast failures hit colour blind users hardest. Enter your foreground and background hex values and the tool reports the contrast ratio against WCAG AA and AAA thresholds. Simple, fast, and definitive. No guessing whether that light grey on white "looks fine." The number tells you.
Design Patterns That Work for Everyone
The good news is that designing for colour blindness doesn't mean designing around severe constraints. It means adding redundancy. Colour still works as a visual cue for the majority of your users. You're just making sure it's never the only cue.
Status and Feedback
The red/green problem shows up most often in form validation, alerts, and status indicators. The fix is consistent: pair colour with a symbol and a text label.
An error state shouldn't just be a red border. It should be a red border, a warning triangle icon, and the word "Error" or a description of what went wrong. A success state shouldn't just be a green checkmark. It should be a green background, a checkmark, and the text "Submitted successfully" or equivalent.
This pattern has a secondary benefit. It makes your interface clearer for everyone, not just colour blind users. A sighted user scanning quickly through a form benefits from clear text labels on errors just as much.
Links Within Text
WCAG 1.4.1 has a specific provision for links. If a link's only visual distinction from surrounding text is colour, there must be a 3:1 contrast ratio between the link colour and the non-link text, and an additional non-colour cue (like an underline) must appear on hover and focus at minimum. The safest approach, and our recommendation, is to underline all links in body text all the time. Not just on hover.
The argument against persistent underlines is usually aesthetic. "It looks cluttered." We disagree. Underlined links are a 30-year-old web convention that users still expect. Removing underlines to make body text "cleaner" sacrifices usability for appearance, and colour blind users pay the price.
Data Visualization
Charts and graphs are where colour blindness causes the most damage, because data visualization relies heavily on colour coding to distinguish between series. A line chart with a red line and a green line is useless to someone with deuteranopia.
Solutions vary by chart type, but the principles are consistent. Use colour and shape together. Make line charts with different dash patterns (solid, dashed, dotted) in addition to different colours. Use distinct marker shapes (circles, squares, triangles) on data points. Add direct labels to data series instead of relying on a colour-coded legend. For bar charts, add texture patterns (hatching, dots, crosshatch) alongside colour fills.
Choose your palette carefully. Blue and orange have strong contrast for nearly all types of colour blindness. Blue is perceived consistently across all common forms of CVD, and orange separates cleanly from it. Purple and yellow work well together. Avoid pairing red with green, pink with grey, or colours that differ only in hue without a meaningful difference in lightness.
Colour Palettes
Build your palette around colours that maintain distinction across all common deficiency types. A few tested combinations that hold up:
Blue (#0077B6) and orange (#E07A00) separate cleanly for protanopia, deuteranopia, and tritanopia. Blue (#2563EB) and red (#DC2626) work if the red is dark enough to maintain contrast. Purple (#7C3AED) and yellow (#CA8A04) hold across all types. Black, white, and blue are always safe as a foundation.
Run every palette through Coblis or Chrome DevTools before committing to it. The five minutes this takes prevents weeks of rework after an accessibility audit flags your colour scheme.
Colour Blindness Design Checklist
- Audit every use of colour on your site. Anywhere colour conveys meaning (status indicators, links, form states, charts, badges), confirm that a second visual indicator carries the same message.
- Test with Chrome DevTools. Open the Rendering panel, enable deuteranopia simulation, and tab through your entire site. Can you still understand everything?
- Check all text contrast. Use WebAIM's Contrast Checker on every text/background pair. Normal text needs 4.5:1 minimum. Large text needs 3:1.
- Underline body text links. Don't rely on colour alone to distinguish links from surrounding text. Persistent underlines are the safest solution.
- Add icons and labels to status messages. Error, warning, success, and info states all need a symbol and text, not just a colour change.
- Choose colour-blind-safe palettes. Blue/orange, blue/red (dark), purple/yellow. Avoid red/green pairings for any functional purpose.
- Label data visualizations directly. Don't force users to match a colour legend to a chart line. Label the lines. Add patterns. Use distinct shapes.
- Run designs through Coblis or Stark before development starts. Catching colour problems in Figma costs nothing. Catching them in production costs time and credibility.
The Business Case Beyond Compliance
WCAG 1.4.1 is a Level A success criterion. If your site fails it, you fail the most basic level of WCAG conformance. For businesses subject to the Accessible Canada Act, Ontario's AODA, or municipal procurement requirements in Alberta, this isn't optional. But compliance alone isn't the strongest argument.
The strongest argument is that your site doesn't work properly for a large group of users and the fix is straightforward. We're talking about 8% of your male visitors. If your site has 10,000 monthly visitors and half are male, roughly 400 of them experience some form of colour vision deficiency every month. Those are real people trying to fill out your contact form, read your pricing page, and understand your data. If your interface communicates through colour alone, some of them are getting incomplete or wrong information.
We cover the broader business impact of accessibility in our article on why accessibility matters, and we put together a hands-on checklist for business owners that includes colour contrast testing. If you've been told that an accessibility overlay widget solves this problem, it doesn't. Overlays can't add icons to your error states, redesign your charts, or fix the underlying reliance on colour in your UI logic. The fixes have to go into the design and the code.
If you're unsure where your site stands, we offer accessibility audits that include colour blindness testing as a standard part of the review. It's one of the first things we check because it's one of the easiest things to fix and one of the most commonly overlooked.
Don't treat colour as a language your entire audience speaks. Nearly 350 million people worldwide don't speak it fluently, and your website should work for them without translation.
Sources
- Understanding Success Criterion 1.4.1: Use of Color — W3C Web Accessibility Initiative. The definitive reference for WCAG's requirement that colour not be the sole means of conveying information.
- Understanding Success Criterion 1.4.3: Contrast (Minimum) — W3C WAI. Explains the 4.5:1 and 3:1 contrast ratio requirements for text and large text.
- Understanding Success Criterion 1.4.11: Non-text Contrast — W3C WAI. Covers the 3:1 contrast ratio requirement for UI components and graphical elements.
- WebAIM: Contrast and Color Accessibility — WebAIM's guide to evaluating contrast and colour use, including practical testing methods.
- WebAIM Contrast Checker — Free tool for checking foreground/background colour contrast ratios against WCAG AA and AAA standards.
- About Colour Blindness — Colour Blind Awareness (UK). Prevalence data, types of colour blindness, and impact statistics.
- Types of Color Blindness — Colblindor. Detailed explanations of protanopia, deuteranopia, tritanopia, and their visual effects.
- Coblis — Color Blindness Simulator — Colblindor's browser-based tool for simulating how images appear under different types of colour blindness. All processing runs locally.
- Simulating Color Vision Deficiencies in the Blink Renderer — Chrome for Developers. Technical documentation on the vision deficiency simulation feature in Chrome DevTools.
- Stark — Contrast & Accessibility Checker for Figma — Stark's accessibility plugin for Figma, including colour blindness simulation and contrast testing.