Color Blindness Explained: The 4 Types Designers Should Know
Color vision deficiency changes how some colors can be distinguished; it does not simply turn the world black and white. Red and green may converge, a saturated red may become unexpectedly dark, or blue and green may become difficult to separate. Those changes matter whenever an interface uses hue to announce an error, distinguish chart series, show availability, mark a route, or identify a selected state.
Commonly cited population estimates suggest that inherited red-green color vision deficiency affects roughly 1 in 12 men and 1 in 200 women of Northern European ancestry, with prevalence varying across populations. The practical lesson is not the exact global total. It is that a large audience will encounter controls, diagrams, and messages whose meaning cannot safely depend on the color distinctions assumed by their creators. The four categories below provide a useful design vocabulary, followed by a workflow for making information survive them.
How color vision produces distinctions
Most human color vision uses comparisons among three kinds of cone photoreceptors. L cones are most sensitive to longer wavelengths, M cones to medium wavelengths, and S cones to shorter wavelengths. Calling them red, green, and blue cones is a convenient shortcut, but each responds across a band of wavelengths. The brain interprets differences among their responses as color.
In a dichromatic color vision deficiency, one cone class is absent, so some colors that create different three-cone responses for most observers produce much more similar signals. In an anomalous trichromacy, all three classes are present but one response is shifted, typically creating a milder range of confusion. The suffixes help: -anopia refers to the absence of a cone class, while -anomaly refers to an altered response. A simulator can approximate likely confusions, but it cannot reproduce every individual’s perception or diagnose a viewer.
The four types designers should recognize
1. Protanopia: long-wavelength signal absent
Protanopia is a red-green deficiency associated with absent L-cone function. Reds can become darker as well as less distinguishable from greens and browns. That darkening is especially important in interface work: a vivid red chosen for visibility may appear much less prominent. Red versus black, red versus brown, purple versus blue, and orange versus green can all become problematic, depending on the exact values.
Protanomaly is the related anomalous form, in which the long-wavelength response is shifted rather than absent. Its effect varies by person. Do not assume that choosing a “slightly different red” will solve the problem. Give warning and error information a label, icon, or structural treatment, and make its lightness relationship clear.
2. Deuteranopia: medium-wavelength signal absent
Deuteranopia is the other commonly discussed red-green dichromacy and is associated with absent M-cone function. Reds and greens may converge toward similar yellows, browns, or muted tones, but the protan-related darkening of reds is not the same. Deuteranomaly, the altered-response form, is more common than complete deuteranopia and is often what population statistics about color vision deficiency largely represent.
Product interfaces are particularly exposed because green commonly means success or available while red means error or unavailable. A pair of identical status dots that differs only in red and green can collapse into nearly the same cue. Writing “Payment received” and “Payment failed,” adding distinct icons, and positioning the messages consistently solves the communication problem without banning either brand color.
3. Tritanopia: short-wavelength signal absent
Tritanopia is a much rarer blue-yellow deficiency associated with absent S-cone function. Blue can become difficult to separate from green, while yellow may converge with light gray or pinkish tones; violet distinctions can also shift. It is not inherited through the same common X-linked pattern as most red-green deficiencies, so its demographic pattern is different.
A blue-to-green map, a cyan versus gray status scheme, or a blue-to-yellow diverging chart can therefore fail even if it performed well under a red-green simulation. This is why testing only deuteranopia is an incomplete release check. Tritanopia also demonstrates a broader principle: there is no universal pair of named hues that eliminates the need for labels and contrast.
4. Achromatopsia: severely limited or absent cone function
Achromatopsia is a rare condition involving little or no functional cone vision. Color discrimination is absent or severely limited, and the condition is also associated with reduced visual acuity and light sensitivity. A grayscale simulation represents the lost color information, but it does not reproduce those other experiences.
For designers, grayscale is a valuable structural test: it reveals where meaning disappears when hue is removed. It is not correct to conclude that a grayscale design automatically works for every person. Text still needs adequate contrast, controls need perceivable boundaries and focus, small details need sufficient size, and layouts must support zoom. Use grayscale to find hue-only information, then continue with the rest of the accessibility review.
Simulation is a detector, not a certification
The Colorblind Simulator creates side-by-side approximations for protanopia, deuteranopia, tritanopia, and achromatopsia in the browser. Use it to locate likely collisions: two chart series becoming alike, a selected tab losing its emphasis, an error border merging with a neutral border, or a heat map losing its ordering. It is much more informative to simulate a complete screen than a detached palette, because size, adjacency, text, and position contribute to recognition.
Do not use a simulator to decide what a particular person sees, and do not claim that a screenshot “passes color blindness.” There is no single pass ratio for hue distinction, and individual vision varies. Instead, record the communication issue the simulation exposes and repair it with redundant cues. Then verify contrast separately with the Contrast Checker, because a color-vision simulation does not test WCAG contrast requirements.
Design information with more than hue
The most reliable rule is simple: color may reinforce meaning but should not be its only carrier. Red can still support an error if the interface also says “Card number is incomplete,” places an error icon beside the field, and connects the message to the input. Green can still support success if a checkmark and the words “Saved” are present. These redundant cues help everyone, including people using monochrome displays, people in bright sunlight, and people who do not know the product’s color conventions.
Practical rules by component
Forms and validation
Keep a persistent label for each input. When validation fails, provide a specific message near the field and an icon or other non-color signal. Do not rely on a red border, especially when its only difference from the default border is hue. Make sure the message and icon meet contrast requirements, and programmatically associate the message with the input so the visual repair is matched by accessible structure.
Links and interactive states
A link that differs from surrounding body text only by blue can be missed when the hues converge or when low saturation makes the difference subtle. Use an underline or another non-color style for links in prose. Selected tabs and toggles should have text, shape, position, or an indicator that survives grayscale. Hover cannot be the only extra cue because touch and keyboard users may never see it. Focus indicators need their own visible treatment.
Charts and dashboards
Direct-label lines and bars when space permits. For dense categorical charts, combine color with line styles, point shapes, patterns, or grouping. A legend that shows differently colored identical squares still asks the viewer to perform a color match across distance. Put the series name next to the relevant mark, preserve clear contrast with the plot background, and consider allowing users to isolate a series.
Sequential data should have a clear light-to-dark order so magnitude remains visible without hue. Diverging data needs an obvious midpoint and distinguishable directions; test both arms under all simulations. For categorical data, lightness variation helps, but avoid making a low-priority category so pale that it disappears. A palette can be color-vision-aware and still fail basic contrast.
Maps, schedules, and status boards
Maps should pair route colors with line patterns, route numbers, or direct labels. Calendars should not encode event type solely with tiny colored dots. Availability grids need words or symbols for open, limited, and unavailable. In every case, inspect the smallest rendered marks: differences that are obvious in a large palette strip can vanish at six pixels.
Choose palettes for roles, not diagnostic labels
There is no short list of universally “colorblind-safe” hex codes that works in every arrangement. The same blue and orange might be distinguishable as large adjacent blocks but ambiguous as thin lines on a gray chart. Start with a concise palette from the Palette Extractor, assign each color a role, and make key categories differ in lightness as well as hue. If a pair converges in a simulation, first add a non-color cue, then adjust the colors if greater separation also improves the design.
Be especially cautious with rainbow scales. Their changes in hue and lightness are uneven, so apparent boundaries may not match data boundaries, and several regions may collapse under simulation. A perceptually ordered single-hue or carefully designed multi-hue scale is usually easier to interpret. For an image treatment where structure should come from tone, a two-color mapping can be effective; the guide to duotone images explains how shadows and highlights preserve form.
A release-ready review workflow
- Inventory every place where color communicates. Include errors, success, selection, chart categories, map routes, links, focus, disabled states, and instructional legends.
- Remove color mentally. Ask what words, shapes, positions, patterns, or icons still communicate each meaning. Add a genuine second cue where the answer is “nothing.”
- Simulate the complete screen. Check protanopia, deuteranopia, tritanopia, and achromatopsia at the real display size. Note collisions rather than judging the image as a whole.
- Measure contrast separately. Test text against its background and meaningful component boundaries against adjacent colors. Check both light and dark themes.
- Exercise interaction states. Use keyboard focus, trigger errors, select tabs, hover controls, and inspect disabled treatments. Static screenshots miss many color-only changes.
- Test with people when consequences are high. Simulation is useful during design, while usability work with people who have color vision deficiency can reveal interpretation and workflow problems the model cannot predict.
Document the result in component guidance. Instead of writing “red equals error,” specify that an error uses an icon, concise message, and optional red emphasis; instead of “green dot equals online,” specify a labeled status with a distinguishable mark. This prevents later screens from reintroducing hue-only meaning even when they reuse approved colors.
Color vision deficiency does not require removing color from a product. Color adds atmosphere, grouping, emphasis, and brand recognition. The responsible approach is to make the underlying information durable: establish lightness and contrast, attach meaning to words and shapes, and use simulation to discover where hue is doing too much work.
Try it yourself
Inspect a real design with the free Colorblind Simulator, then verify its text and component pairs in the Contrast Checker. Both run locally in the browser, and more practical reads are available in the guides section.