Most accessibility problems in a color palette don't show up until someone actually goes looking for them — which is usually right before launch, or worse, right after. This is the list worth running through before either happens. It's not a deep dive into the reasoning behind each rule — that's covered elsewhere — this is the practical, check-it-and-move-on version for when you're actually shipping something.
If you only have five minutes
Run your primary text-on-background pairing through a contrast checker and confirm it clears 4.5:1. Check that no two semantically different states — error versus success, active versus inactive — rely on color as the only differentiator. Then glance at your interface in grayscale for ten seconds; if two things you need to tell apart become the same shade of gray, that's your biggest problem, fix that one first. Those three checks alone catch the majority of real-world failures.
Contrast
- Body text hits 4.5:1 against its background — this is the one people remember, but it's worth explicitly confirming rather than assuming.
- Large text hits at least 3:1 — 18pt regular or 14pt bold and up counts as large; if you're not sure a heading qualifies, check its actual computed size rather than guessing from how it looks.
- Button borders and form field outlines hit 3:1 against their surrounding color — this one gets missed constantly because it's easy to only think about text.
- Placeholder text and disabled states are checked separately — they're often deliberately muted, but "muted" and "fails contrast entirely" aren't the same thing, and it's easy to cross that line without noticing.
- Text over images or gradients is checked at its worst-case point, not its best — contrast against a gradient needs to hold up at the lightest part of that gradient, not just the average.
Beyond color alone
- Every error/success/warning state pairs color with an icon or label — not just a colored border or dot, actual text or iconography that survives if the color itself gets misread.
- Links are distinguishable by more than color — underline, weight change, or both, especially for links sitting inline inside body text.
- Charts and graphs don't rely purely on a color legend — direct labeling, pattern fills, or line-style variation should carry the same information the colors do.
- Red/green pairs have been tested for color-blind confusion specifically — run a simulator over any red/green pairing that's carrying real meaning, since it's the single most common failure pattern.
Dark mode, if you have it
- Contrast is re-checked independently for dark mode — a pairing that passes in light mode doesn't automatically pass once the background flips, and it needs its own separate check.
- Pure black backgrounds are avoided where possible — very dark gray tends to reduce eye strain and glare compared to true black, without sacrificing the contrast benefit.
- Brand colors are desaturated slightly for dark backgrounds — fully saturated colors tend to vibrate uncomfortably against dark backgrounds in a way they don't against light ones.
Actually testing it
- Run a contrast checker on every text/background pair that appears more than once in the interface, not just the obvious ones.
- Run a color-blindness simulator over your key screens — dashboards, forms, and anything with status indicators or charts get priority.
- View the design in grayscale as a quick sanity check — anything that becomes indistinguishable is worth a second look regardless of what the simulator says.
- Test on an actual low-end or older screen if you can — colors that look fine on a calibrated design monitor sometimes wash out noticeably on cheaper or older displays.
Why this list gets skipped even when everyone agrees it matters
Not because people don't care, usually just because it gets treated as a final QA step instead of part of picking the palette in the first place. By the time contrast gets checked, the colors are already locked into a hundred components, and fixing a failing pairing means touching all of them instead of adjusting one value before anything got built on top of it. Running through this list while a palette is still being decided, rather than after it's already shipped everywhere, is the actual difference between a five-minute fix and a multi-day one.
Questions people ask about running this
How long does a full accessibility pass on a palette actually take?
For a small palette (2-4 core colors plus neutrals), the full checklist below usually takes 20-30 minutes once you know what you're checking for. The five-minute version at the top catches most of the serious issues if that's all the time you have.
Do I need to redo this every time I add a new color?
Not the whole checklist, just the parts specific to that color: its contrast against the backgrounds and text it'll actually sit near, and a quick color-blind simulator pass if it's replacing or sitting next to an existing semantic color.
What if my brand colors just don't pass, and I can't change them?
You almost never need to change the brand color itself, just where and how it's used. Reserve it for large elements or accents that only need 3:1, and use a passing variant of it for anything that needs to hit the stricter text ratios.
Is this checklist enough, or do I need a full accessibility audit too?
This covers color specifically, which is one real slice of accessibility, not the whole picture. Screen reader support, keyboard navigation, and focus states are separate concerns this checklist doesn't touch, so treat it as one part of a broader accessibility pass, not a replacement for one.
Print this, or just bookmark it
None of these checks take long individually — the whole list together is maybe half an hour the first time you run through it properly, and closer to five minutes once it's a habit instead of a novelty. The cost of skipping it isn't paid by you, it's paid by whoever hits the broken pairing after launch, which is exactly why it's worth doing before shipping rather than after.