Guide

Color Blindness Friendly Design Tips for Graphic Designers (2026)

Zakaria Amzdak

Aug 8, 2025 · Updated Jul 18, 2026 · 9 min read

You picked a red and a green that look nothing alike on your calibrated monitor. To roughly 1 in 12 of the men who see your work, they're close to the same muddy tone. That gap — between the colors you chose and the colors a color blind viewer receives — is the whole problem, and it's fixable at the design stage without watering down your style.

About 300 million people have some form of color vision deficiency: around 1 in 12 men and 1 in 200 women. This is a practical guide for graphic and visual designers — the concrete moves you make in Figma, Illustrator, or a chart, so meaning survives when hue doesn't. It's less about theory and more about the habits that keep your files accessible by default.

What color blindness changes for a designer

Color vision deficiency shifts which hues a person can tell apart. Most of it is inherited through an X-linked recessive gene, which is why it shows up far more often in men, and there's no cure — so the design carries the load, not a device on the viewer's end. The types you'll actually design around:

Deuteranomaly and deuteranopia (green-weak or green-blind): the red-green family, and deuteranomaly is the single most common type of all. Reds and greens of similar lightness blur together.
Protanomaly and protanopia (red-weak or red-blind): also red-green, but reds additionally look darker and can drop out against a dark background.
Tritanomaly and tritanopia (blue-yellow): genuinely rare; blues and greens, or yellows and pinks, get confused.
Monochromacy (no color at all): very rare, but it's the reason a grayscale check is worth doing — if a layout works in pure gray, it works for almost everyone.

Red-green deficiency covers the large majority of cases, so if your design holds up under deuteranopia and protanopia, you've handled most of your audience. When color is the only carrier of meaning — “errors are red, success is green” — those users are guessing. The fix is redundancy, not a blander palette.

Where designs usually break

A handful of patterns cause most of the trouble. If you learn to spot these in a mockup, you'll catch problems before they reach a simulator:

Color-only status: a green dot for “online” and a red dot for “offline” that are identical once hue is removed.
Red and green at matching lightness: the classic loss/gain chart where both lines have the same weight and brightness.
Risky pairings: red/green, green/brown, blue/purple, and gray/teal — all of which can merge when their luminance is close.
Subtle interactive states: a hover or selected state signaled by a small hue shift with no change in lightness, border, or shape.
Legend-dependent charts: visuals that force a viewer to bounce between a color key and the data because nothing on the chart itself is labeled.

Six tips you can apply today

1. Add a redundant cue to anything that means something

Pair every color-coded state with a second signal: an icon (✓, !, ✕), a text label, a shape, or a pattern. Color becomes the accent, not the message.
For form errors, show an icon and a written message, not just a red outline. For a legend, put the label on or beside the data, not only in a key.
One extra cue per element is enough. Stacking three redundancies makes a design noisy for everyone.

2. Lead with luminance, not hue

Two colors that differ mainly in lightness stay distinct for nearly every type of color blindness; two that differ only in hue may not. When you place two swatches side by side, ask whether they'd still separate in grayscale.
In your tool, a fast test is to add a temporary Black & White or Hue/Saturation adjustment over the artboard and drop saturation to zero. If categories vanish, your palette is leaning on hue alone.

3. Start from a color-blind-safe palette

The Okabe-Ito set was designed to stay distinguishable across common deficiencies: black #000000, orange #E69F00, sky blue #56B4E9, bluish green #009E73, yellow #F0E442, blue #0072B2, vermillion #D55E00, and reddish purple #CC79A7. Eight categories, all separable.
For maps and data, ColorBrewer has a “colorblind safe” filter that only shows schemes that pass. Adobe's Color Accessibility tool flags conflicting pairs as you build.
These are tested starting points, not guarantees for every layout. Backgrounds, sizes, and adjacency still change how a color reads, so simulate the finished piece.

4. Label charts directly

Put the series name at the end of each line or on top of each bar instead of shipping the meaning off to a color legend. It removes the color-matching step entirely.
Give each line its own stroke style (solid, dashed, dotted) and each series its own marker (circle, square, triangle). Now the chart survives grayscale, a bad projector, and a black-and-white printout.

5. Use texture and shape in infographics

Fill regions of a pie, map, or stacked bar with distinct hatches or dot densities in addition to color. Keep the patterns coarse so they hold up when the graphic is scaled down or compressed for the web.
Where categories are icons or pins, vary the shape, not just the color — a triangle and a circle read apart even in full monochromacy.

6. Test with a simulator before handoff

Flip your export through deuteranopia, protanopia, tritanopia, and grayscale. Deuteranopia and protanopia catch the most, so start there.
Run our color blindness simulator on a flat PNG of the layout, or check a live page with the website checker. Make it a step in QA, not a last-minute favor.

Tools to check your work

Stark (Figma, Sketch, Adobe XD): contrast checks, color blindness simulation, and annotations without leaving the design file — the quickest option if you live in Figma.
Color Oracle (Windows, Mac, Linux): a free full-screen filter that recolors everything on your display, handy for spot-checking a composition in any app.
Sim Daltonism (Mac): a floating window that simulates whatever your cursor hovers over in real time.
Our image simulator and palette checker: the image simulator for flat exports and the palette checker to confirm a swatch set stays distinct across types.

Pair a contrast checker with the simulator. They catch different faults: a contrast checker measures light-versus-dark, while a simulator shows whether two colors that pass contrast still merge under a deficiency. A medium red and a medium green can clear the contrast bar and still look identical to a deuteranope.

Typography & layout

Color blindness doesn't only touch color choices — layout decisions decide whether contrast holds and whether hierarchy reads without hue.

Meet the contrast ratios: WCAG 1.4.3 asks 4.5:1 for body text and 3:1 for large text (18pt regular or 14pt bold and up). WCAG 1.4.11 wants 3:1 for the meaningful parts of icons and controls.
Build hierarchy from size, weight, and spacing — not color alone. A heading should still read as a heading in grayscale.
Pick clear typefaces with a generous x-height and letterforms you can tell apart (an uppercase I, lowercase l, and digit 1 that don't collapse into one shape).
Give links and buttons a non-color signal: an underline, a border, or a clear focus outline, so they don't vanish for someone who can't see the accent hue.
Protect text over photos with a scrim or gradient overlay, and confirm the ratio on the darkest and lightest parts of the image.

Before and after

Dashboard line chart. Before: red “loss” and green “gain” lines at the same weight and brightness. After: widen the luminance gap, make one solid and one dashed, add circle and triangle markers, and label each line's end point (“Q4 gain”).
Marketing banner. Before: thin white headline over a busy photo. After: add a dark gradient scrim, bump the weight and size, and confirm 4.5:1 against the busiest patch behind the text.
Form validation. Before: errors shown only by a red border. After: keep the border, add an error icon and a written message in high-contrast text next to the field.
Category map. Before: five regions separated by hue alone. After: swap in a ColorBrewer colorblind-safe scheme and add a light hatch pattern so adjacent regions never rely only on color.

Designer checklist

Contrast: body text ≥ 4.5:1, large text ≥ 3:1, icons and controls ≥ 3:1.
No color-only meaning: every coded element also has an icon, label, shape, or pattern.
Luminance first: categories stay distinct with saturation dropped to zero.
Safe palette: start from Okabe-Ito or a ColorBrewer colorblind-safe scheme.
Charts: direct labels, distinct line styles and markers, minimal legend dependence.
Simulate: checked in deuteranopia, protanopia, tritanopia, and grayscale before handoff.
Type & layout: hierarchy from size and weight, non-color link cues, scrims over photos.
Design system: accessible color tokens and usage rules documented so it doesn't regress.

Frequently asked questions

Do I have to avoid red and green completely?

No. The problem isn't red and green as colors — it's red and green with the same lightness sitting next to each other, since that's the pair that collapses under deuteranomaly and protanomaly. Push a strong luminance gap between them (a dark red against a light green, for example), or keep the hues and add a second cue like a shape or label. A quick simulator pass tells you whether a given pair holds up.

What's the fastest way to test a design for color blindness?

Run two checks. First a contrast checker on your text and UI colors to confirm they meet WCAG ratios; then a color blind simulator on the whole layout to catch anything that reads by hue alone. In Figma, Stark does both inside the file. For a flat export, drop it into an image simulator and flip through deuteranopia, protanopia, tritanopia, and a grayscale view.

Is there a color palette that's guaranteed safe for color blind users?

There's no palette that's perfect in every context, but two are widely used because they were built for this: the Okabe-Ito eight-color set and the color-blind-safe schemes in ColorBrewer. They work because the colors differ in lightness and warmth, not just hue. Treat them as a tested starting point and still simulate your final layout, since backgrounds and sizes change how colors read.

How much contrast do I actually need?

WCAG 1.4.3 asks for 4.5:1 between body text and its background, and 3:1 for large text — 18pt regular or 14pt bold and up. WCAG 1.4.11 adds a 3:1 minimum for the parts of icons, form fields, and chart elements that carry meaning. Those ratios help color blind and low-vision users at the same time.

Do patterns and textures really help, or do they just add clutter?

They help when color can't be trusted on its own. A line chart with solid, dashed, and dotted strokes stays readable in grayscale; a bar chart with a hatch fill survives a bad projector. The trick is restraint — one redundant cue per series, not three. Keep patterns coarse enough to survive scaling and compression.

Does designing for color blindness limit my creativity?

It mostly moves the constraint earlier. You still choose any hues you like; you just make sure meaning survives without them, using lightness, shape, position, and labels. Plenty of strong brand systems lean on high contrast and clear type, and they read cleanly on a cheap phone in sunlight — which is the same condition color blind users design around anyway.

Who is affected, and can it be corrected?

Around 300 million people worldwide have some color vision deficiency — roughly 1 in 12 men and 1 in 200 women. Most cases are inherited through an X-linked recessive gene, which is why it's far more common in men. There's no cure; so-called color-correction glasses can boost some contrast for certain types but don't restore normal color vision. Design is the reliable fix, not a device on the user's end.

Putting it into practice

None of this asks you to give up a color you love. It asks you to make sure the meaning behind that color has a backup — a label, a shape, a lightness gap, a pattern — so the design reads the same whether the viewer sees every hue or none. The habits are cheap once they're routine: reach for a tested palette, label your charts, keep contrast honest, and run a simulator before you hand off.

Next steps: push your current project through a simulator and a contrast checker, tune the palette for luminance differences, and write the rules into your design system so the next file starts accessible. More to read:

Back to all articles