TL;DR: Color contrast is the single most common accessibility failure on the web, and it is also one of the easiest to fix. Under WCAG 2.2, normal body text needs a contrast ratio of at least 4.5:1 against its background, large text needs 3:1, and key interface parts like buttons and form borders need 3:1. This guide explains what those numbers mean, how to check them, and how to build a palette that passes without looking dull.
Why contrast deserves a designer’s attention
Low-contrast text is hard to read for people with low vision or color vision deficiencies, but it also hurts everyone using a phone in bright sunlight, an aging laptop screen, or a cheap projector. WebAIM’s annual WebAIM Million analysis of top home pages has repeatedly found low-contrast text to be the most frequently detected accessibility error. In other words, this is not an edge case. It is the most common way websites shut readers out.
Contrast is also a legal and commercial issue. Many accessibility laws and procurement rules point to the Web Content Accessibility Guidelines (WCAG) as the technical standard, so failing contrast checks can show up in audits and complaints.
The rules, in plain English
WCAG measures contrast as a ratio between the relative luminance of two colors. The scale runs from 1:1 (no contrast, like white on white) to 21:1 (black on white). The W3C’s explanation of Success Criterion 1.4.3 sets out the thresholds.
| Element | Level AA (common target) | Level AAA (enhanced) |
|---|---|---|
| Normal text | 4.5:1 | 7:1 |
| Large text (about 18pt regular or 14pt bold and up) | 3:1 | 4.5:1 |
| UI components and meaningful graphics (SC 1.4.11) | 3:1 | No separate AAA level |
| Logos and purely decorative text | No requirement | No requirement |
Most organizations aim for Level AA. AAA is worth hitting for long-form reading, such as articles and documentation, where comfort matters most.
Non-text contrast is the rule people forget
Success Criterion 1.4.11 covers the visual edges people rely on to use an interface: input borders, checkbox outlines, focus rings, icons that carry meaning, and chart lines. A pale gray form field on a white page can pass every text check and still be nearly invisible to some users. Give those boundaries at least 3:1 against what surrounds them.

How to check contrast in your workflow
You do not need to compute luminance by hand. Several free tools do it instantly:
- WebAIM Contrast Checker: paste two hex codes and get a pass or fail for each WCAG level.
- Browser developer tools: Chrome and Edge show a contrast ratio when you inspect a text element’s color, and Firefox’s Accessibility Inspector can flag contrast issues across a page.
- Design tool plugins: Figma and similar tools have community plugins that check contrast on frames before anything reaches a developer.
- Automated testing: Open-source engines such as axe-core can catch many contrast failures in a build pipeline, though they can miss text over images and gradients.
Building a palette that passes and still looks good
The fear many designers have is that accessible color means a boring palette. It does not. It means being deliberate about which colors do which job.
1. Separate brand colors from text colors
A bright brand yellow or a light teal often fails as text on white. That is fine. Use it for large surfaces, illustrations and accents, and pick a darker shade from the same hue family for text and links.
2. Build tonal scales
For every core hue, create a scale from very light to very dark, often numbered from 50 to 900. Then record which pairings pass. For example, you might note that steps 700 and above pass on white for body text, while steps 100 and below work as backgrounds for dark text. This turns contrast from a recurring debate into a lookup.
3. Watch the “almost gray” traps
Placeholder text, disabled buttons, captions and timestamps are where contrast quietly slips. Disabled controls are exempt under WCAG, but placeholders and captions are not, so do not let them drop to a whisper-light gray.
4. Test text on images
Text over photos is hard to guarantee because the image changes beneath it. Add a solid or semi-opaque overlay behind the text, or use a text shadow, and check the worst-case spot on the image rather than the average.
5. Do not rely on color alone
Contrast is related to, but separate from, Success Criterion 1.4.1, Use of Color. Error states, links within paragraphs and chart series should be distinguishable with an icon, underline, label or pattern, not just a hue shift that some users cannot perceive.
Dark mode needs its own pass
Inverting a light theme rarely produces a good dark theme. Pure white text on pure black can feel harsh for long reading, so many design systems use an off-white text on a very dark gray. That is fine as long as it still meets the ratio. Also recheck brand accent colors: a blue that works as a link on white may be too dark on a near-black background.
What about WCAG 3 and APCA?
The W3C is developing WCAG 3, and early drafts have explored a different contrast method known as APCA that accounts for font weight and size more precisely. WCAG 3 is still a working draft, not a finished standard, so WCAG 2.2 remains the benchmark for audits and legal compliance today. It is worth following, but do not replace your 2.2 checks with it yet.
A quick contrast checklist
- Body text meets 4.5:1 against its background.
- Headings and large text meet at least 3:1.
- Links are distinguishable from surrounding text without relying on color alone.
- Input borders, focus indicators and meaningful icons meet 3:1.
- Placeholder and caption text has been checked, not assumed.
- Text over images has an overlay and passes at its weakest point.
- Dark mode has been checked separately.
The bottom line
Good contrast is a design decision, not a compliance chore bolted on at the end. Set up tonal scales, document which pairs pass, and check as you design. You will ship interfaces that more people can read, and in most cases, they will look sharper too.

