What Makes a Good UI Color Palette for Accessibility
Learn what separates an accessible UI color palette from a pretty one — contrast ratios, color blindness, and practical testing habits explained.
Contrast Ratio Is the Non-Negotiable Starting Point
WCAG 2.1 (and 2.2, which keeps the same contrast rules) defines the floor: normal body text needs a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) gets a slightly more relaxed 3:1. These numbers are not arbitrary style preferences. The W3C derived 4.5:1 from a 3:1 baseline for normal vision, raised to cover the contrast sensitivity lost with moderately low acuity (about 20/40), color vision deficiencies, and aging.
The quick way to fail this is to lean on mid-range grays. A light gray label on a white card looks elegant in a mockup with a high-brightness monitor in a dim studio. It fails completely on a phone in sunlight. Run every text-on-background combination through a contrast checker, or paste your tokens into a UI color contrast grid, before you finalize anything. If it barely passes at 4.6:1, consider whether you actually want the minimum.
WCAG 2.1 AA is the technical standard behind many accessibility rules, including the US ADA Title II rule of 2024 and Europe's EN 301 549. WCAG AAA (7:1 for body text) is harder to hit everywhere but worth targeting for your main reading flows: long paragraphs, error messages, and any instructional copy.
Color Alone Cannot Carry Meaning
Using red to mean error and green to mean success is fine — as long as you also use an icon, a label, or a border to communicate the same thing. Up to about 8% of men and 0.5% of women of Northern European descent have red-green color vision deficiency. The most common type, deuteranomaly, makes certain greens look redder, and stronger forms make red and green hard or impossible to tell apart. If your form validation relies solely on a red outline to signal a problem, those users can easily miss it.
The fix is not complicated: pair color with shape or text. An error state gets a warning icon plus the word 'Error' plus a red border. A success state gets a checkmark plus 'Saved' plus a green border. The icon and the word each work without color; together with the border, the state is hard to miss.
This principle extends beyond status colors. Don't use color alone to distinguish chart segments, required fields, or active navigation items. Always provide a secondary cue.
Build a Palette with Predictable Roles
An accessible palette is not just a set of colors that pass contrast; it is a system where every color has a defined role, the same idea behind any good web design palette. Primary, secondary, accent, background, surface, and text colors each need a spec that covers both light and dark mode contexts. Ad-hoc color decisions lead to combinations no one checked.
Assign at least two shades of each functional color: one for backgrounds and one for text or icons that sit on top of it. For example, a brand blue might be too dark to use as text on a dark surface but fine as a button fill with white text on top. Document both use cases. Design tokens in your codebase make this explicit and enforceable.
Status colors (success, warning, error, info) deserve particular care. They often appear in small contexts like badges or inline messages where the contrast requirement (4.5:1 for small text) is easy to miss, and icons or borders that carry meaning need at least 3:1 against their surroundings. Pick them early and lock them down before the rest of the palette is built around them.
Test on Real Devices, Not Just Design Tools
Design tools show you colors at their best. A Figma canvas on a calibrated display in dark mode is not where your users live. Test your palette on a mid-range Android phone at full brightness outdoors, on an old laptop with a washed-out screen, and on a TV-sized monitor across the room. Colors that looked fine in the tool often fail in at least one of those contexts.
Simulate color blindness in your browser using accessibility plugins or the Emulate vision deficiencies setting in Chrome DevTools. Run through your key screens in deuteranopia, protanopia, and tritanopia modes. The goal is not that everything looks identical; it is that nothing critical becomes invisible or ambiguous.
Frequently asked questions
- What contrast ratio do I need for accessible UI text?
- WCAG AA requires 4.5:1 for normal text and 3:1 for large text (18pt regular or 14pt bold). WCAG AAA raises those to 7:1 and 4.5:1. Aim for AA as your minimum and AAA on primary reading content.
- Can I use light gray text on a white background?
- Only if the contrast ratio reaches 4.5:1. Most light grays on white fail badly. For a safe starting point, an accessible color pair generator only returns pairs at 4.5:1 or higher. Use a contrast checker before finalizing any gray-on-white or gray-on-light-color combination — what looks fine at 100% zoom often fails for users with low vision.
- How do I make a color palette that works for color blind users?
- Use the Okabe-Ito palette as a starting point for categorical colors; it was designed to stay distinguishable with common color vision deficiencies, and a colorblind-safe palette generator gives you up to eight of its colors. More importantly, never rely on color alone to convey meaning. Add labels, icons, or patterns as secondary signals.
- Does dark mode need different contrast testing?
- Yes. The same 4.5:1 ratio applies, but the direction reverses: you're checking light text on dark backgrounds. Mid-brightness colors that pass on white may fail on dark surfaces, and vice versa. Test both modes independently.
Sources
- Understanding SC 1.4.3: Contrast (Minimum) (Level AA) — W3C Web Accessibility Initiative
- Understanding the New ADA Web Accessibility Requirements for State and Local Governments by Kristi Nickodem — UNC School of Government
- Types of Color Vision Deficiency — National Eye Institute
- Color blindness — Wikipedia