WCAG requires a contrast ratio of at least 4.5:1 between normal text and its background (success criterion 1.4.3, Level AA). Large text — 18pt and up, or 14pt bold and up — needs only 3:1. A separate criterion, 1.4.11, requires 3:1 for user-interface components and meaningful graphics, so buttons, form-field borders, and icons count too. Those three numbers are the whole of the WCAG color contrast requirements most sites need to worry about.
Low-contrast text is not a fringe problem. It is the single most common accessibility failure on the web: the 2025 WebAIM Million report found detectable WCAG failures on 94.8% of the top one million homepages, with low-contrast text the number-one offender. It is also one of the easiest failures to fix once you know what you are measuring.
What color contrast ratio does WCAG require, exactly?
Contrast ratio is a measurement of how different two colors are in relative luminance — roughly, brightness. It runs from 1:1 (identical colors, invisible text) to 21:1 (pure black on pure white). WCAG 2.2 at Level AA sets three thresholds:
- 4.5:1 — normal body text against its background (1.4.3).
- 3:1 — large text: 18pt (about 24px) regular, or 14pt (about 18.66px) bold and larger (1.4.3).
- 3:1 — UI components and graphics you need to see to operate or understand the page: button backgrounds, input borders, focus indicators, chart segments, informative icons (1.4.11).
Level AA is the benchmark that matters. It is the level the DOJ's Title II rule, the EU, and effectively every court-referenced settlement point to, and it is the level ADA Fail audits against. Level AAA raises the text-contrast bar higher still, but AAA is aspirational — you are not expected to hit it site-wide.
What counts as "large text"?
Size is measured at the rendered weight, not the CSS you wish you had used. Regular-weight text qualifies for the 3:1 threshold at 18pt (24px) and above. Bold text qualifies at 14pt (roughly 18.66px) and above. Everything below those cutoffs — which is most of your paragraph copy, captions, form labels, and fine print — must clear 4.5:1. When in doubt, treat it as normal text and aim for 4.5:1.
How do you test your site's color contrast?
You do not eyeball this. Contrast ratio is a precise calculation, and colors that "look fine" routinely fail. Use a tool that gives you the number:
- Grab the two hex values. Use your browser's DevTools color picker or an eyedropper to read the exact foreground and background colors as they actually render.
- Run them through a contrast checker. The WebAIM Contrast Checker takes two hex codes and tells you the ratio plus a pass/fail for AA and AAA at both text sizes.
- Scan the whole page. A browser extension such as an automated accessibility scanner will flag every low-contrast node at once, which beats checking colors one at a time.
- Check the tricky states. Hover, focus, disabled, placeholder text, and text sitting on top of a background image or gradient are the usual culprits. Test each state, not just the default.
One caution: automated scanning is excellent at contrast because it is a pure math check, but it is not a full audit. Automated tools reliably catch only about a third of WCAG success criteria; the rest — logical reading order, meaningful link text, whether an icon's 3:1 color is actually conveying the right information — need human testing. Passing an automated contrast scan means you have cleared one important, measurable hurdle, not that the whole site conforms.
How do you fix low-contrast text?
Fixing contrast is a code change to your CSS, not a plugin. The workflow is straightforward:
Darken (or lighten) until the number passes
Take the failing pair into a contrast checker and nudge the foreground color's lightness until the ratio clears 4.5:1 (or 3:1 for large text and UI). Small shifts move the number a lot. Pale gray body text on white — the classic "#999 on #fff" — sits around 2.85:1 and fails; dropping it to about #767676 clears 4.5:1 while still reading as gray.
Fix it at the token level
If your site uses CSS custom properties or a design system, correct the color token once and every instance updates. This is faster and more durable than hunting down individual elements, and it stops the same failure from reappearing the next time someone reuses the token.
Don't forget non-text elements
Button fills against the page, input borders that mark a field's edge, focus outlines, and icons all need 3:1. Faint placeholder text and ghost/disabled buttons are frequent misses — if a control looks interactive and conveys information, it needs to clear the threshold.
Because contrast is a genuine code fix, the right tool is a proper accessibility checklist and remediation, not a surface-layer script. This is worth being precise about. A user-facing preference widget — a small button that lets a visitor bump up text size or switch to a higher-contrast theme on a site whose code is already accessible — is a legitimate convenience. ADA Fail runs one on its own site, and it makes no compliance claims. A third-party compliance overlay — a script sold on the promise of making a broken site conformant automatically — is a different animal entirely. Overlays do not fix your underlying CSS, and WebAIM's analysis found sites using them averaged roughly as many detectable errors as sites without them. The FTC's January 2025 action against accessiBe, which ended in a $1 million order barring unsubstantiated compliance claims, is the cautionary tale. If you want the full breakdown, see why overlay widgets fail.
Why does color contrast matter beyond passing a scan?
Contrast is a usability issue before it is a legal one. Over one in four U.S. adults live with a disability, and low vision, color-vision deficiency, and age-related sight changes all make thin, pale text hard or impossible to read. Fixing contrast makes your copy readable for everyone, including sighted users on a phone in bright sunlight.
It is also a litigation reality. More than 5,000 digital-accessibility lawsuits were filed in 2025, up roughly 20% over 2024, and low-contrast text is one of the specific, easily-documented failures plaintiffs' testers point to. It is measurable, it is common, and it is cheap to fix — which makes it low-hanging fruit for a demand letter. Clearing your contrast failures removes one of the most-cited items from the table.
Want to know where your site stands? A free accessibility audit from ADA Fail will surface your contrast failures alongside the missing alt text, unlabeled forms, and empty links that tend to travel with them.
Frequently asked questions
Is 4.5:1 or 3:1 the pass? How do I know which applies?
It depends on what the color pair is. Normal body text must clear 4.5:1. Large text (18pt regular or 14pt bold and up) and non-text UI elements — button fills, borders, focus rings, informative icons — only need 3:1. When you are unsure whether text is "large," default to the stricter 4.5:1 and you cannot be wrong.
Does pure white text on a colored button need to pass contrast?
Yes. The text on a button is still text, so white lettering on a colored button must clear 4.5:1 (or 3:1 if the label is large). Separately, the button's fill color against the surrounding page needs 3:1 under 1.4.11 so users can find the control. A light-blue button with white text is a common double failure — both the label and the button edge come up short.
Do logos and disabled controls have to meet contrast requirements?
No. WCAG 1.4.3 exempts text that is part of a logo or brand name, and both 1.4.3 and 1.4.11 exempt inactive/disabled UI components. That said, do not use "disabled" as a loophole for genuinely important text — if users need to read it to complete a task, treat it as active content and make it pass.