How to test colour contrast: There's more to it than you think.

I have a quick question for you about the last website or app you visited. Could you actually read the text on it without squinting, tilting your screen, zooming in (if that was even possible), or did you silently curse whoever picked that particular shade of grey on slightly lighter grey? 

Chances are, at some point, you found a colour contrast failure and didn't even realise it. You just felt the annoyance of something more difficult than it should be. I want to talk about why that keeps happening, because honestly, it's bonkers that we're still getting this wrong. For me, it is a bugbear (persistent annoyance), which is so ironic because it is a bug we don't have to bear at all! 

To be clear. The problems with colour contrast are not a testing problem at all. In fact, the title of this piece could have been ‘Advocating for colour contrast’. Developers, testers, and other quality professionals usually don’t have a say in colours. Brand engineers and designers are the architects, and once the business has signed off, brand colours can be set in stone. Or orange and white, or another equally challenging combination. But as you will see, it isn’t as simple as ‘blaming’ a particular group. As the title says, there is more to it than you think. 

Context of how bad it really is out there  

The WebAIM Million report (an annual scan of the top million homepages, if you haven't come across it) found that colour contrast is the single most common accessibility issue out there, at a whopping 83.9%. In my opinion, that's not a niche problem tucked away in some dark corner of the web. That's nearly everyone's problem, nearly all of the time. And the trend for 2026 shows it climbing right alongside the rise in accessibility issues overall. I think that’s because of Artificial Intelligence (AI) coding. Others think it is AI coding, but I’m not here to talk about AI coding, so on we go. So, colour contrast isn't going away on its own. We have to go and meet it. 

Contrast matters in many ways and could be a whole article on its own. A few are covered in the text, but you only have to think of readability, low-vision or colour impairment users, light and dark modes, glare and reflection, cognitive load, and the ever-present ‘brand loyalty and trust’ that says, ‘we can’t change that’. Everyone has encountered something hard to read or see because of poor colour contrast, whether due to design or environment. But there are things we can do. 

Why do we keep getting something so simple so wrong? 

On paper, it really is simple. WCAG asks for a ratio of 4.5:1 (which simply put means 4.5 to 1) for normal text, or 3:1 (3 to 1) for large text. That's it. Two numbers. So why does it trip up so many teams, so often? 

I recently had the pleasure of hearing Danny Payne, Head of Accessibility at Companies House, give a talk called "The white and yellow elephants. The colour contrast challenge," and it gave me a new perspective on how I think about this. Danny's point is that, by the time contrast gets picked up in testing, it's usually far too late. The colours were decided long before a single line of code was written. They came from branding. And branding, more often than not, gets treated as sacred, or as a risk everyone's quietly agreed to accept. Raise it, and you can end up feeling frustrated as no one either listens or, on the surface, cares. But that’s not it. They probably do care. It's just that we are too far down the line from the decision to change it. 

Here's the bit that really got me, though. None of this was intentional sabotage. Print and signage media never needed contrast guidelines in the way digital does. A banner, poster or signage didn’t have a vast range of screen types, sizes or resolutions. A pastel logo on a glossy brochure magazine doesn't care about ratios. But put that same palette on a screen, though, and suddenly it's a different game entirely. The brand creators weren't being careless. They just never had the guidance that digital demands. 

Good and bad, side by side 

Think of dark navy text on white. It comfortably clears 4.5:1. It is easy to read in the majority of circumstances. Nobody notices it because it just works. Which, let's be honest, is the whole point of good accessibility. You shouldn't notice it. Now think of that light grey placeholder text sitting on a white input field, the kind that looks "clean" and "minimal" in a design mockup. Gorgeous on a big monitor in a bright office, or even a home office with good lighting. Practically invisible on a phone screen in daylight, or to anyone with low vision. Same font, same weight, wildly different experience. 

Working it through the lifecycle 

So where do we actually catch this? 

Requirements is where Danny's advice really lands for me. Do the website mockups first, in the same way mobile-first design flipped how we build for mobile. If contrast requirements are baked in at the mockup stage, there are no issues later. Gojko Adzic was telling us this in 2011 in his book and model, Specification by Example. While not specifically about accessibility, he posited a collaborative approach using real examples to bridge the gap (from his previous book “Bridging the Communications Gap” from 2009) between business stakeholders, designers, developers and testers. I can recommend his books highly. 

Design and branding are the trickiest phase, because a brand is emotional. It's decades of identity, not just a hex code. Nobody wants to hear their logo colours "failed a test." So don't lead with the ratio. Try a percentage instead. Telling a designer to move from a 14% to 17.5% ratio lands far better than quoting 4.5:1 at them, a lesson I'm taking straight into my own conversations, I'll admit. We can help the brand choices meet reality before it is everywhere. 

Development is where tools like colourcontrast.cc earn their keep, giving developers a quick, practical check as they go rather than a nasty surprise later. Before the brand choices become actual code, we can question and challenge if necessary. 

Testing is where we come in properly if we haven’t been involved earlier. There are many tools, such as WebAIM’s WAVE tool, that show and can show adjustments for colour contrast. Chrome's rendering simulator lets you experience what low vision or colour vision deficiency actually looks like on your own product, which is far more powerful than any ratio on a spreadsheet. And wherever you can, test with real users. No simulator replaces that.

A few seeds to plant 

1. Offer solutions, not problems. "This fails" lands very differently from "here's a shade that passes and still looks like us." 
2. Accept what you can't change today. Not every fight is winnable in one sprint. Plant the seed anyway. 
3. Show, don't just tell. Let a stakeholder experience the issue by showing them the product in a simulator. It sticks far better than a report ever will. 
4. Keep an eye on where this is heading. James Sullivan's work on accessibility in colour systems is well worth a read, and APCA (Accessible Perceptual Contrast Algorithm), the proposed replacement for contrast ratios under the next Web Content Accessibility Guidelines or WCAG 3.0, is more scientific, if a fair bit harder to get your head around. It is interesting though. 

To sum up 

Colour contrast looks like the easiest accessibility check in the book. Two numbers, one comparison, done. But as Danny Payne's talk reminded me, the real challenge starts long before testing, sitting quietly inside a brand guideline that nobody thought to question. Brand guidelines that may not have been designed for digital first, or have been around for longer than digital. 

So next time you're squinting at a screen wondering why the text is hard to read, don't just log the bug. Ask where in the lifecycle it really went wrong, and go plant a seed there instead.