Designing for Color Blindness: How to Build Accessible Color Palettes

Pick a logo color, build a chart, or design a settings screen, and at some point you decide what something means by what color it is. Green means good, red means bad, blue is a link, gray is disabled. For most people that shorthand works without a second thought. But for the roughly 300 million people worldwide with some form of color vision deficiency, those same color cues can disappear entirely, blend into the background, or end up looking identical to their opposite. A red error message that looks the same as a green success message is not a rare edge case. It is one of the most common accessibility failures in digital design, and it is almost always fixable with a few deliberate choices made early, before a palette gets locked in across an entire site or document.

What Color Blindness Actually Is

Color blindness is not usually the all-or-nothing condition the name suggests. The vast majority of people with a color vision deficiency see plenty of color, just not the same range or separation that someone with typical vision sees. The most common forms affect the red-green axis. Deuteranomaly, a reduced sensitivity to green light, and protanomaly, a reduced sensitivity to red light, together account for the large majority of cases. Their more severe counterparts, deuteranopia and protanopia, remove the ability to distinguish red and green almost entirely, so colors that should look clearly different, like a ripe and an unripe tomato, can appear as nearly the same shade of brownish-yellow.

Blue-yellow deficiencies, tritanomaly and tritanopia, are far rarer and affect the ability to distinguish blue from green and yellow from violet. Total color blindness, or achromatopsia, where the world appears only in shades of gray, is rare enough that it affects a tiny fraction of a percent of the population.

What makes this a design problem rather than a niche concern is the prevalence. Roughly 1 in 12 men, and about 1 in 200 women, of Northern European descent have some form of red-green color vision deficiency. On a team of any size, or a website with any meaningful traffic, some of your users are seeing your color choices differently than you do, whether or not anyone has ever mentioned it.

Why Color Alone Breaks Interfaces and Documents

The clearest accessibility failures happen when color is the only signal carrying information. A form field outlined in red to flag an error looks identical to a normal field if red and the surrounding gray render as nearly the same value to someone with deuteranopia. A line chart with five series distinguished only by hue becomes five overlapping gray smudges. A status dashboard using green for "operational" and red for "down," with no text label and no icon, can leave a colorblind user unable to tell which state they are looking at without hovering over every item or opening a tooltip.

The fix is rarely to abandon color. It is to stop relying on color as the only channel. Pair a red error state with an icon and the word "Error." Pair a green success state with a checkmark and the word "Success." In a chart, give each series a different pattern, marker shape, or direct label in addition to its color, and put that information in the legend rather than only in a tooltip. None of this requires giving up a colorful design. It just means color becomes a reinforcement of the message rather than the entire message, which also happens to make the design clearer for everyone, including someone glancing at a screen in bright sunlight or on a low-quality projector.

The Contrast Ratio Rules That Actually Matter

Beyond using more than color alone, the next layer is contrast. The Web Content Accessibility Guidelines, or WCAG, define minimum contrast ratios between text and its background: 4.5:1 for normal-sized text at the AA level, 3:1 for large text such as headings, and a stricter 7:1 and 4.5:1 respectively at the higher AAA level.

Contrast ratio is calculated from the relative luminance, or perceived brightness, of two colors, not from how different their hues look to someone with typical color vision. That detail matters more than it sounds. Two colors can have very different hues, say a medium red and a medium green, while sitting at almost the same luminance level. To someone with typical vision they look obviously different. To someone with a red-green deficiency, they can look like nearly the same shade, and the contrast ratio between each of them and a shared background can be nearly identical too, meaning the two colors fail to separate from each other even though each one individually passes a contrast check against that background.

The practical takeaway is that passing a contrast check against a background is necessary but not sufficient. When two colors need to be distinguishable from each other, not just readable against a background, they need a meaningful difference in lightness, not just a difference in hue. This is the gap that trips up a lot of otherwise well-intentioned designs: every individual color passes its contrast check, but pairs of colors that are supposed to mean different things do not separate from each other for a meaningful share of users.

Building a Palette That Doesn't Rely on Hue Alone

Once you know lightness separation matters as much as hue, the easiest starting point is to build your palette around a structure rather than picking individual colors at random. Start with a single brand or base color, then generate a coordinated set of complementary, analogous, and neutral tones with the Color Palette Generator. Generating a full palette from one starting point keeps the colors related to each other, which makes it much easier to adjust lightness deliberately across the set afterward.

From there, group your palette by role rather than by hue: a darkest shade for primary text, a mid-range shade for secondary text and borders, and lighter shades for backgrounds and disabled states. Within any group of colors that need to be told apart at a glance, such as chart series or status badges, aim for visible steps in lightness between each one, not just a different hue at the same brightness. A palette built this way tends to hold together visually while also surviving the jump from full color to grayscale, which is the simplest test for whether it will work for colorblind users.

Converting Colors to Compare Lightness Side by Side

Hex codes are convenient for storing colors, but they hide the information you actually need for an accessibility check. A hex code like #2E7D32 does not tell you, at a glance, how light or dark that green is compared to a red like #C62828. Converting both colors to HSL format, which separates hue, saturation, and lightness into three numbers, makes that comparison direct: the lightness value, usually shown as a percentage, is the one to compare.

Run each color in your palette through the Color Converter and write down the lightness percentage for each one. If two colors that need to be distinguishable from each other land within a few percentage points of the same lightness value, regardless of how different their hues look to you, that pairing is a candidate for confusion under a red-green or blue-yellow deficiency. Adjusting one of the two colors a little darker or lighter, while keeping its hue roughly the same, usually resolves the conflict without changing the overall feel of the palette. It is also worth checking saturation at the same time: two colors with similar lightness and similar saturation but different hues are the riskiest combination of all, since neither lightness nor intensity gives a colorblind viewer anything extra to go on.

Simulating Color Blindness With a Grayscale Preview

A genuinely useful, low-effort test is to convert a screenshot of your design to grayscale and look at it the way someone with achromatopsia would, or close to how someone with a severe red-green deficiency would experience the loss of hue information. If two elements that need to be told apart become the same shade of gray, they are relying entirely on hue to do that job, and that is the pairing to fix first.

The Photo Editor includes a grayscale adjustment alongside brightness, contrast, and saturation controls, so you can drop in a screenshot of a chart, dashboard, or color-coded document, strip the color, and immediately see which elements collapse into each other. This will not catch every case, since some color vision deficiencies preserve more brightness distinction than full grayscale removes, but as a five-minute sanity check before shipping a design, it catches the most severe failures reliably and costs nothing to run on every major layout change.

Stress-Testing With Random Color Combinations

It is easy to design a palette that works for the three or four colors you had in mind, then run into trouble the moment a fifth category, a new status, or a new chart series gets added later. One way to find these gaps before they happen in production is to generate sets of random colors with the Random Color Generator and run them through the same lightness and grayscale checks described above.

If your design relies on icons, labels, and patterns in addition to color, as covered earlier, then almost any new color you add later should still be distinguishable, because the color itself was never the only signal. If a randomly generated color breaks your layout or becomes indistinguishable from an existing one, that is a sign the design is leaning on hue more than it should, and it is much better to find that out with a random test color in a design file than with a real status that a real user needs to understand correctly. This is also a useful habit if your site supports both a light and a dark theme, since a pairing that separates cleanly in one theme can collapse together in the other, and each theme is worth checking on its own.

A Quick Accessible Color Checklist

Designing for color blindness does not mean avoiding color, and it does not require redesigning everything from scratch. It means treating color as one signal among several, checking lightness alongside hue, and testing the result in grayscale before calling it finished.

In practice, that comes down to a short routine: build palettes from a single base color so related shades stay coordinated, pair any color-coded meaning with an icon, label, or pattern, compare lightness values for colors that need to be told apart, and run a grayscale check on the final result. Revisit that check whenever a new color gets added to an existing palette, since that is where most accessibility regressions creep in. None of these steps take long individually, and together they cover the large majority of color accessibility problems that show up in real interfaces and documents. The result is a design that looks just as intentional and colorful as before, but actually communicates the same information to everyone looking at it.