Product designers, design-system maintainers and front-end engineers at AI and SaaS companies who need to test and fix colour contrast across a product's palette.
- Most colour systems are chosen by eye and never formally tested. Low-contrast text appears on 83.9% of the top million home pages (WebAIM, 2026).
- WCAG 2.1 AA requires 4.5:1 for normal text, 3:1 for large text and 3:1 for meaningful UI graphics. AAA raises text to 7:1.
- On a real AI brand project, an accent-on-white pairing already in use measured 2.37:1. After the rebuild, the primary dark-on-white pairing reached 17.26:1.
- The fix was structural: a four-layer colour system (foundation, structural, interactive, utility) where every approved pairing has a measured ratio.
- Test pairings, not colours. A colour is never "accessible" on its own - only in combination with a specific background at a specific size.
Ask most product teams whether their colour system passes WCAG contrast requirements and the honest answer is "we assume so". Colours get chosen for how they look together in a mockup, not measured against a formula. A palette can look polished and still fail the moment it is used for body text, placeholder text or an interactive state.
This walkthrough shows what contrast testing looked like on a real AI enterprise brand project, how to run the same test on your own palette, and how to rebuild a colour system so every future pairing is accessible by default.
Why contrast is the most common accessibility failure
WebAIM's 2026 analysis of the top one million home pages found low-contrast text on 83.9% of them - more common than any other detectable error. It is also one of the easiest failures to prevent, because contrast is a number you can calculate before anything ships.
For AI products the problem tends to be worse. Interfaces use many shades for secondary text, metadata, confidence scores, chart labels and disabled states - exactly the places where designers reach for light greys and brand tints.
The thresholds you need to know
WCAG 2.1 defines contrast as a ratio between two relative luminances, from 1:1 (no contrast) to 21:1 (black on white).
| Content | WCAG 2.1 AA | WCAG 2.1 AAA | Criterion |
|---|---|---|---|
| Normal text | 4.5:1 | 7:1 | 1.4.3 / 1.4.6 |
| Large text (18pt, or 14pt bold) | 3:1 | 4.5:1 | 1.4.3 / 1.4.6 |
| UI components and meaningful graphics (borders of inputs, icons, chart lines) | 3:1 | - | 1.4.11 |
| Disabled controls, pure decoration, logos | Exempt | Exempt | - |
The text thresholds and the large-text definition come directly from the W3C's guidance on SC 1.4.3. Note that "large" means roughly 24px regular or 18.66px bold on the web - most body copy and all small labels must meet 4.5:1.
The before: a pairing that failed by a wide margin
On the AI brand project, we audited every colour pairing in active use across the website and product. One accent-on-white pairing - used for links and small highlighted text - measured 2.37:1. That is barely half the 4.5:1 minimum, not a marginal miss.
Nobody chose it carelessly. Accent colours are picked for how much they "pop", and brightness that pops against white is often exactly what reduces text contrast. The pairing had simply never been measured.
Source: Project measurements; thresholds from W3C WCAG 2.1
View as table
| Pairing | Contrast ratio |
|---|---|
| Accent text on white (before rebuild) | 2.37:1 |
| Primary dark text on white (after rebuild) | 17.26:1 |
How to test your own palette in five steps
1. Inventory real pairings. List every foreground and background combination actually used: body text, secondary text, links, buttons (text and background), input borders, icons, badges, chart labels, disabled states. Screenshots of real screens are more reliable than the palette file.
2. Calculate the ratio for each. Use a contrast checker or the WCAG formula. For each colour, convert each sRGB channel to linear light (values up to 0.04045 are divided by 12.92; above that, apply ((c + 0.055) / 1.055)^2.4), then compute relative luminance as 0.2126 R + 0.7152 G + 0.0722 B. The contrast ratio is (L1 + 0.05) / (L2 + 0.05), with L1 the lighter colour.
3. Classify by use. Decide whether each pairing is normal text, large text, a meaningful graphic or decorative, and compare against the right threshold.
4. Record results in a matrix. A simple table - foreground, background, ratio, use, pass or fail - becomes part of the design-system documentation.
| Foreground | Background | Ratio | Used for | AA result |
|---|---|---|---|---|
| Primary dark | White | 17.26:1 | Body text, headings | Pass (also AAA) |
| Accent (original) | White | 2.37:1 | Links, small highlights | Fail |
| Accent (original) | White | 2.37:1 | Large decorative numerals only | Fail for text; allowed only if purely decorative |
5. Fix at the system level. Adjust or replace failing colours in the palette and tokens, not screen by screen.
The fix: a four-layer colour system
Rather than patch one failing pairing, the colour system was rebuilt with accessibility as a structural property. Each layer has a job, and each job has its own contrast rules:
| Layer | Job | Contrast rule |
|---|---|---|
| Foundation | Body text and dark surfaces - carries the most reading | Tested first; text pairings target AAA where possible |
| Secondary structural | UI structure: borders, dividers, secondary surfaces | Meaningful boundaries (inputs, cards that must be seen) at least 3:1 |
| Interactive | Primary actions and the core accent | Text on buttons at least 4.5:1; the accent is not used for small text on white unless it passes |
| Utility | Charts and data visualisation | Marks at least 3:1 against the chart surface, with labels so colour is never the only cue |
Every pairing across all four layers was re-tested against WCAG 2.1 before approval. The primary dark-on-white combination reached 17.26:1, well into AAA territory.
The utility layer deserves special mention for AI products. Charts need colours that are distinguishable from each other, including for people with colour-vision deficiency, and legible against the background - requirements that differ from brand accent choices. Keeping them in a separate, tested layer stops data visualisation from compromising the identity or vice versa. See UX patterns for data-heavy AI interfaces for more.
Making it stick in the design system
- Tokens with intent. Name tokens by role (
text.primary,text.secondary,action.primary) rather than by colour, and only create text tokens for pairings that pass. - Documented pairings. Publish the approved-pairings matrix alongside the tokens.
- Checks in the workflow. Use contrast plugins in design tools and automated accessibility checks in CI to flag regressions.
- States included. Test hover, focus, pressed, selected and error states - they often introduce new pairings nobody measured.
- Dark mode tested separately. A pairing that passes in light mode tells you nothing about its dark-mode equivalent.
Why it matters even without a mandate
Plenty of B2B AI products are not covered by a specific accessibility regulation, and teams sometimes deprioritise contrast as a result. Two reasons not to:
- Procurement asks. Enterprise buyers increasingly include accessibility in vendor reviews; a tested colour system gives you a straight answer.
- Everyone benefits. Low contrast degrades reading for many ordinary users - on laptops in bright offices, on phones outdoors, late in a long working day - not only people with diagnosed vision impairments.
The 2.37:1 number is what people remember from this project, but the more useful lesson sits upstream of it: almost no colour system gets contrast-tested unless someone makes it a required step, because the problem is invisible until you go looking.
Building a layered system where every approved pairing is tested by default - rather than tested when someone raises a flag - is the difference between accessibility as a one-off fire drill and accessibility as a property of the system. That is the version that holds up as the product keeps shipping new screens.
Frequently asked questions
Is 4.5:1 enough, or should we aim for 7:1?
4.5:1 meets WCAG AA for normal text and is the common baseline. Aim for 7:1 (AAA) for long-form reading and critical information where you can, but do not sacrifice other usability to reach it everywhere.
Do placeholder text and disabled buttons need to meet contrast?
Placeholder text is still text and should meet 4.5:1 if it carries information. Disabled controls are exempt under WCAG, but they should still be recognisable as disabled.
Can we keep a bright brand accent that fails contrast?
Yes, for large display elements, backgrounds with dark text, illustrations and decoration. Avoid using it for small text on light backgrounds, and create a darker, compliant variant for links and small highlights.
Does contrast apply to charts?
WCAG 1.4.11 asks for 3:1 contrast for graphical objects needed to understand content, such as chart lines and bars against their background. Add direct labels so meaning never depends on colour alone.
Which tools should we use to test contrast?
Any tool that implements the WCAG formula works - design-tool plugins, browser developer tools and automated accessibility checkers. What matters is testing real pairings and recording the results.
Not sure if your colour system passes WCAG?
Let's test your real pairings, not just assume they're fine.
Sources
Every statistic in this article links to its original publisher. Figures were checked against these sources on September 29, 2026.
