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. 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 specifically for color blindness. 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.

What Makes a Good UI Color Palette for Accessibility | Generator Collection

Contrast Ratio Is the Non-Negotiable Starting Point

WCAG 2.1 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 — they come from decades of research on how the eye distinguishes foreground from background under real conditions like glare, aging lenses, and low-quality screens.

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 before you finalize anything. If it barely passes at 4.6:1, consider whether you actually want the minimum.

WCAG AA is the legal baseline in many jurisdictions. 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. Roughly 8% of men and 0.5% of women have some form of color vision deficiency. The most common type, deuteranomaly, makes red and green nearly indistinguishable. If your form validation relies solely on a red outline to signal a problem, those users simply 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. Any one of those three signals could stand alone. Together they are bulletproof.

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. 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. 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 built-in DevTools emulation in Chrome. 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. 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 specifically for color blindness. 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.