Home · Blog · Accessible palettes

Building colour palettes everyone can read

30 Sep 2026 · Colour · 6 min read

Most palettes are designed on a good monitor, in a quiet room, by someone with typical colour vision — and then released into a world of phone screens at low brightness, bright sunlight, ageing eyes and colour-blindness. A palette that only works under ideal conditions doesn't really work. Accessible palette design isn't a separate discipline bolted onto the side of colour theory; it's what colour theory looks like when you take the audience seriously.

The good news is that it mostly comes down to three checks, each of which you can run in under a minute: contrast ratios for text, lightness separation for everything else, and a colour-blindness pass over your critical pairs. Do those three and your palette will survive the overwhelming majority of real-world conditions. This article walks through each one, explains why it matters in plain terms, and shows how to build the checks into your palette workflow rather than treating them as a final exam.

Check one: contrast ratios for text

The WCAG standard draws two lines in the sand: normal text needs a contrast ratio of at least 4.5:1 against its background (AA), and large text — roughly 18pt and up, or 14pt bold — needs 3:1. The stricter AAA tier asks 7:1 and 4.5:1 respectively. These numbers come from legibility research: 4.5:1 is roughly what someone with 20/40 vision needs to read comfortably.

In palette terms, this means every text colour you ship must have at least one background in your palette that clears the bar — and you should know which pairs those are, explicitly. A common failure: a palette with a beautiful mid-tone brand colour that gets used for body text on white at 2.8:1, failing AA while looking "fine" to the designer. The fix is structural, not cosmetic. Build your palette with dedicated text colours (near-blacks, near-whites) and treat brand colours as accents, not as text, unless you've verified the specific pair. A contrast checker makes this mechanical: enter the foreground and background, read the ratio, move on. There's no judgement involved and no excuse for guessing.

One subtlety people miss: contrast is a property of the pair, not of either colour alone. There is no such thing as an "accessible colour" — only accessible combinations. Your palette documentation should list approved pairs ("Slate-900 on White: 15.2:1, AAA"), not just approved colours. When someone inevitably asks "can I put the brand orange on the light grey?", the answer should be a number, not an opinion.

Check two: lightness steps for non-text meaning

Contrast ratios only govern text. But colour carries meaning everywhere else too: chart series, status indicators, map regions, form validation states. Here the rule is simpler and more robust: make sure colours that must be told apart differ clearly in lightness, not just in hue.

Why lightness? Because almost every form of colour-vision deficiency preserves lightness perception while scrambling hue. A red/green pair that a deuteranope literally cannot distinguish becomes perfectly separable if one is dark red and the other is light green. Lightness differences also survive the other great levellers: greyscale printing, cheap projectors, and bright sunlight washing out a phone screen. Hue is fragile information; lightness is sturdy.

Practically, this means building palettes as ramps with real separation. If your data-visualisation palette has five categorical colours, don't pick five vivid hues at the same lightness — pick hues spread across the wheel and spread across lightness, or better yet, verify the set in simulated greyscale. A quick test that catches most problems: screenshot your design, convert to greyscale, and check that every colour-coded element is still distinguishable. If two series merge into one grey, they were only ever distinguished by hue, and a significant slice of your audience was only ever seeing one series.

Check three: the colour-blindness pass

About 1 in 12 men and 1 in 200 women have colour-vision deficiency, the vast majority red-green (deuteranopia/protanopia) with blue-yellow (tritanopia) far behind. These aren't rare edge cases — in any audience of consequence, colour-blind users are present. The classic casualties are exactly the pairs designers love: red/green for bad/good, red/green for stop/go, and the fashionable red-teal complementary schemes.

The check itself is easy: run your critical colour pairs through a simulator (many are built into browser dev tools now) and look at the result. But the deeper fix is a design principle: never encode meaning in hue alone. Status indicators get icons or labels alongside their colour. Chart series get distinct lightness or patterns as well as distinct hues. Error states get text, not just a red border. This principle — redundant encoding — is the single most powerful accessibility habit in colour design, because it makes every other check less critical. If the meaning survives with colour removed entirely, then colour-vision differences can't break it.

Building it into the palette

Checks are most useful when they're part of construction, not inspection. Here's a workflow that bakes accessibility into palette generation:

1. Start from lightness ramps, not hues. For each hue family, generate 8–10 lightness steps (say 5% to 95%). Ramps give you text/background pairs for free: dark steps on light steps clear AA almost automatically.
2. Nominate roles before choosing colours. Decide which ramp supplies body text, which supplies backgrounds, which supplies accents — then verify the cross-ramp pairs. A palette of "pretty colours" with no roles assigned is where inaccessible combinations are born.
3. Verify every text pair numerically. No eyeballing. 4.5:1 for body, 3:1 for large. Write the approved pairs down.
4. Greyscale-test your categorical sets. Charts, statuses, map legends — if it merges in grey, fix the lightness separation.
5. Simulate the three common deficiencies on your final palette and confirm nothing critical disappears.
6. Add redundant encoding wherever colour alone carries meaning: labels, icons, patterns, text.

The honest limitations

Two caveats, because accessibility deserves honesty more than most topics. First, a passing ratio is a floor, not a guarantee. The contrast formula computes from hex values; it knows nothing about your user's screen brightness, ambient light, font rendering or vision. 4.5:1 on a dim phone in sunlight can still be unreadable. The numbers keep you honest, but they don't replace looking at your design in hostile conditions — the worst screen you can find is a better test than the best.

Second, accessibility is bigger than colour. A palette can pass every check here and still fail users through tiny touch targets, missing focus states, motion sensitivity or keyboard traps. Colour is one channel of an accessible design, and this article covers that channel. Don't let a perfect contrast score become an excuse to stop thinking about the rest.

None of which diminishes the core point: the three checks are cheap, the failures they prevent are real, and "we'll fix it later" is how inaccessible palettes ship. Build the checks into the palette from the first hue, and accessibility stops being a constraint and starts being what it should be — just part of choosing colours well.

Try the Palette Generator Try the Contrast Checker