Originally published at AccessGuard.
Color contrast is the most common accessibility failure
If there's one accessibility issue that appears on nearly every website, it's insufficient color contrast. The WebAIM Million study found low contrast text on 83.9% of the home pages it tested in 2026, which makes it the single most widespread WCAG failure on the web.
The reason is straightforward: designers choose colors that look good on their own high-resolution monitors in well-lit offices. For anyone with low vision, a color vision deficiency or age-related sight changes, those subtle grays and trendy pastels can render text unreadable.
This guide explains the WCAG contrast requirements, identifies the most common problem areas, and shows you how to maintain beautiful design while meeting accessibility standards.
Understanding contrast ratios
WCAG measures color contrast as a ratio between the luminance (perceived brightness) of the foreground color and the background color. The scale runs from 1:1 (no contrast - same color on same color) to 21:1 (maximum contrast - black on white).
The standard defines three threshold levels:
WCAG AA - The practical minimum
- Normal text (under 18pt / 24px, or under 14pt / 18.5px bold): minimum 4.5:1
- Large text (18pt+ / 24px+, or 14pt+ / 18.5px+ bold): minimum 3:1
- UI components and graphical objects (icons, form borders, focus indicators): minimum 3:1
Level AA is the standard most laws require and the level you should target for compliance.
WCAG AAA - The gold standard
- Normal text: minimum 7:1
- Large text: minimum 4.5:1
Level AAA isn't required by most regulations, but meeting it where feasible improves readability for everyone - not just users with disabilities.
What counts as "large text"?
WCAG defines large text as 18pt (24px) or larger at regular weight, or 14pt (18.5px) or larger at bold weight. Large text gets a lower contrast threshold because its size makes it inherently easier to read. But be careful - 18px, a common body font size in modern design, is not large text by WCAG standards. You need 24px or larger.
Common contrast problem areas
Certain design patterns consistently fail contrast requirements. Knowing where to look saves time during audits.
Light gray text on white
This is the most common offender. Designers use light gray for "secondary" text - timestamps, captions, metadata - to create visual hierarchy. But the result often fails contrast standards.
The lightest gray that passes 4.5:1 against pure white (#FFFFFF) is #767676, at 4.54:1. Anything lighter fails. That popular #999999 many designers reach for? It only achieves 2.85:1, well below the minimum.
Placeholder text in forms
Browser default placeholder colors typically fail contrast requirements. Chrome's default placeholder color on a white input is approximately #757575, which barely passes at 4.61:1. But if your input has a light gray background, even that might fail. Custom-styled placeholders in lighter shades almost always fail.
Remember that placeholder text should never replace labels, but when you do use it, it still needs to be readable.
Text overlaid on images
Hero banners and cards with text over photographs are a contrast minefield. The contrast varies depending on the image content beneath the text - it might pass in one area and fail in another.
Solutions include:
- Adding a semi-transparent overlay between the image and text
- Using a solid background behind the text area
- Adding a text shadow for additional separation (though this alone may not be sufficient)
- Choosing images with consistent dark or light areas where text is placed
Colored buttons and links
Brand-colored buttons often fail when light brand colors are used with white text, or dark brand colors with dark text. A medium blue button with white text might look fine but fail the 4.5:1 threshold.
Links that rely solely on color to distinguish them from surrounding text have an additional requirement: the color difference between the link and the surrounding text must be at least 3:1 (or the link must have a non-color indicator like an underline).
Disabled and inactive states
WCAG technically exempts "inactive" UI components from contrast requirements, so disabled buttons and inputs don't need to meet the 4.5:1 threshold. However, users still need to perceive that a control exists and is disabled. Using extremely low contrast for disabled states can make them invisible, confusing users about what options are available.
Maintaining your brand while meeting standards
A common concern from design teams is that accessibility requirements will force them to abandon their brand colors. In practice, this is rarely the case. Here are strategies that work:
Darken, don't replace
Most brand colors that fail contrast can be adjusted by darkening the shade slightly. If your brand blue is #4A90D9 (3.34:1 against white), shifting to #2A6AB5 (5.49:1) keeps the same hue while passing AA. Most users will not notice the difference. Users with low vision will notice the improvement.
Use color strategically
You can still use your lighter brand colors in places where contrast requirements are less strict: large headings (3:1 threshold), decorative elements (no contrast requirement), backgrounds, and borders. Reserve your darkened accessible variants for body text, buttons, and form elements.
Test early in the design process
Checking contrast after the design is "done" leads to frustrating last-minute changes. Build contrast checking into your design workflow from the start. Many design tools have built-in or plugin-based contrast checkers that give you real-time feedback as you choose colors.
Tools for checking contrast
You don't need to calculate contrast ratios by hand. These tools make checking quick and easy:
- Browser DevTools - Chrome, Firefox, and Edge all show contrast ratios when you inspect text elements. Chrome's color picker also suggests colors that would meet AA and AAA thresholds.
- WebAIM Contrast Checker - A simple web tool where you enter foreground and background hex codes and see the resulting ratio.
- Stark - A popular plugin for Figma, Sketch, and Adobe XD that checks contrast within your design tool.
- Operating system tools - macOS includes a Digital Color Meter and accessibility inspector. Windows has the Accessibility Insights tool from Microsoft.
How AccessGuard helps with color contrast
Checking individual color pairs works well during design, but a live site may have hundreds of text elements across dozens of pages. AccessGuard runs automated WCAG 2.2 AA checks in a real browser and flags every text element that falls below the threshold for its size.
Each contrast issue comes with the two colors found, the calculated ratio, the ratio required at that text size, and the WCAG criterion it fails, so your design team gets the exact pair to change rather than a page to go hunting through. Reports can go out as white-label PDFs under your agency's name.
Contrast is one of the failures automated checks are genuinely good at, because the ratio is arithmetic. Text over photographs is the exception: a tool can only measure against the pixels it samples, so hero images still need a human eye. Automated checks find many problems but cannot confirm conformance.
Next steps for your team
- Set the accessible variants of your brand colors as design tokens, so nobody has to remember which blue passes.
- Check every new color pair at design time, not at QA.
- Give focus indicators and form borders their own 3:1 check. They are the ones teams forget.
- Scan the live templates after each release, because a CSS change can undo a fix quietly.
- Review text over images by hand on the breakpoints you support.
See what a scan reports for one of your pages with the color contrast checker, or run a free scan on a client page. For the wider audit, read how to audit a website for accessibility and the most common accessibility issues and how to fix them.
Top comments (0)