The numbers most people cite are technically correct but they miss the part that matters for anyone doing actual design or development work
Roughly 8 percent of men of Northern European descent are red-green colorblind. That number shifts depending on ancestry. It drops to about 4-5 percent in Hispanic males, around 3 percent in African males, and is quite rare in Asian populations. For comparison, female red-green colorblindness lands at roughly 0.5 percent because the genes sit on the X chromosome. Women need two copies. Men only need one. That biological asymmetry is why the disparity is so large. When people ask this question, they usually want a single clean number. The real answer depends on how you define colorblind and which population you're measuring. The standard clinical figure used in most textbooks and ophthalmology references is approximately 8 percent of Caucasian males. If you include all male populations worldwide, the weighted average comes down to somewhere around 4-5 percent of all men on Earth. That is still meaningfully larger than the female rate. It is not a negligible portion of any audience. The thing nobody tells you until they have already pushed a product into production is that the 8 percent figure is dominated by one specific subtype. Deuteranomaly, the reduced sensitivity to green light, accounts for about 6 percent of all male color vision deficiency. Protanomaly, the reduced sensitivity to red, makes up roughly 1 percent. Then you have the complete forms of each condition, deutan and protan blindness, at about 1 percent combined. Tritan defects, the blue-yellow types, are extremely rare in men, around 0.01 percent. Most accessibility guidance treats all of this as one lump sum. It is more useful to understand the distribution because the workarounds differ.
I ran into this head-on when I was managing a dashboard project for a logistics company. We had built an entire status reporting system using a red-to-green gradient to indicate vehicle availability. Green meant operational, red meant broken down. The product manager confirmed the design looked fine on her screen. I shipped it. Three weeks later we pulled bug reports from field technicians who could not reliably distinguish the two states. The problem was not that they saw everything as gray. Deuteranomaly patients see color. They just cannot separate certain wavelengths properly. The red and green we picked sat too close on their perceptual map. I rebuilt the encoding system to use hue plus shape plus label, which added maybe six hours of work to the sprint but eliminated the ambiguity entirely. Single-encoding strategies for status are almost always a bad idea if your user base includes colorblind operators. There is a common misconception that colorblindness means seeing in black and white. That is almost never true. Complete achromatopsia exists but it is vanishingly rare. The vast majority of colorblind people have normal vision in one eye or possess at least partial trichromatic function. They navigate the world fine. What breaks down is when color is doing heavy lifting as the only signal carrying information. Charts, traffic lights, wiring diagrams, error states in software, these are the places where the deficit shows up. Another thing beginners miss is that standard desktop monitors render colorblindness poorly. A colorblind simulation filter on Photoshop or Figma gives you a rough approximation, but it is not the same as the actual perceptual experience. These tools apply simplified transformation matrices based on laboratory data. They do not account for individual variation in cone sensitivity or screen calibration differences. If you need accurate proof that a palette works, use a physical test chart or run a proper diagnostic tool on the actual display. A calibrated monitor with a color blindness simulator plugin like Color Oracle is better than nothing but treat it as a directional guide rather than ground truth.
The accessible approach is straightforward once you stop treating it as a special case and start treating it as a basic signal design principle. Never encode meaning with color alone. Pair hue with pattern, texture, position, or explicit labels. Keep saturation high enough that the contrast survives even after spectral filtering. Avoid red-green pairings at similar luminance values. Pick palettes where the colors differ in brightness, not just in hue. Tools like OKLCH color spaces and the Viridis or Cividis perceptual palettes were designed with this constraint built in. They are not trendy choices. They are engineering choices. There are legitimate downsides to overcorrecting here. When you layer patterns and labels onto every visual element, designs get noisy. Some stakeholders push back hard on anything that is not a solid color fill. That is a real constraint you have to navigate. The workaround is usually to restrict the non-color encoding to areas where it matters most. Status indicators, data points on charts, form validation states. Keep decorative elements simple. Focus the extra encoding where the information is critical. For web and app development, the WCAG 2.1 AA standard requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. That is a floor, not a ceiling. Color contrast checkers like the ones built into axe or Lighthouse will flag insufficient contrast. They do not fully model colorblind perception though. They measure luminance contrast, not chromatic confusion. You should run your palette through a dedicated simulator after passing the basic contrast checks. I use a combination of a11y.css for quick visual checks in-browser and separate conversion tools for final verification before launch.
Get the Full Details
If you need a practical download or reference asset, most accessibility organizations provide open colorblind-safe palettes. The Material Design color system includes built-in colorblind variant previews. The Royal National Institute of Blind People publishes printable test cards. For developers, the color-blindness CSS filter library on GitHub provides runtime simulation if you want to build testing directly into your environment. None of these are perfect. They are starting points. The actual validation always comes from real users with real vision defects, not from a filter on a sRGB display. The bottom line is that the 8 percent figure is accurate for the relevant demographic but it is only the entry point. The meaningful work starts after you accept that a substantial minority of your users cannot rely on color as a standalone signal. Fix the encoding strategy and the numbers stop mattering as much. Bad encoding makes 8 percent look like 100 percent of your users are broken. Good encoding makes the difference irrelevant.
