How to Build an Accessible Color Palette
A practical, checklist-based method for palettes that hold up under WCAG — including the parts most tutorials skip.
5 min read · updated 2026
Start from contrast, not from color
Choose your background and text pair first and verify it at 4.5:1+ for body text. If the brand color cannot reach 4.5:1 as text on your surface, do not force it — keep it for large headings (3:1), icons and decoration, and pick a darker/lighter variant for body text. The closest-passing-shade tool in the contrast checker does this adjustment in OKLCH while keeping the hue.
Build ramps, not single colors
A usable palette needs at least 5 steps per key hue (roughly: wash, light, base, deep, darkest). Build them in OKLCH so lightness is evenly perceived, then verify each intended text/background combination with the palette matrix. This is also what makes dark mode possible later: deep steps become surfaces, light steps become text.
Check for color-vision deficiency
Simulate protanopia, deuteranopia and tritanopia. The failure mode is not "the palette looks ugly" — it is two colors collapsing into the same perceived color, which breaks charts, status badges and maps. Tintiva's simulator flags pairs whose ΔE00 falls below 3 after simulation.
Do not encode meaning in hue alone
Always pair color-coded information with a second channel: an icon, a label, a pattern. Google's red and green are indistinguishable to some deuteranopes, but "✗ Failed" and "✓ Passed" never are. This is a WCAG requirement (1.4.1), not a nicety.