Also available in: Français

Color contrast is not a detail you can skip. If you design interfaces, it is part of the job. And if you are used to low contrast ratios, yes, you are probably afraid of losing some of the beauty of the interface you just crafted. That fear is legitimate. But accessibility is a constraint like any other, no heavier than the ones UX design already puts on you.

Definitions

Let me start with my own definitions of accessibility and user experience. Both are complex, and experts don’t always agree on them, so: sorry not sorry, here is my attempt.

User Experience

User experience is what a person feels and does with a product or a service: the expectations, the hopes, the actions, the failures, the successes, the frustration, the memory of it. Depending on your goal, that experience can be good or bad. A bad one can even be intentional on the designer’s part. Most of the time, though, you are trying to build something memorable in a good way, so people understand the product, use it, and end up loving it. Making an interface usable means understanding a specific group of people well enough to help them complete a precise task with efficiency, effectiveness and satisfaction.

Accessibility

In our field, accessibility is the practice of making websites and applications usable by as many people as possible. We tend to think it only concerns people with disabilities, which it does, by definition, but it benefits plenty of other people too, depending on the context.

So: user experience aims to satisfy a precise group of people, and accessibility aims to include as many people as possible in a shared, decent experience. The two are not mutually exclusive.

 

The Myths of Color Contrast Accessibility

This blog post is a reply to the eponymous article.

First, thanks to Anthony for surfacing beliefs that really do circulate in the design community. I discovered a few of them by reading him.

My problem is less with what he says than with how he says it. The framing pushes you to distrust one of the best known accessibility guidelines — WCAG — on the grounds that it doesn’t match what users need.

The article walks you through visual examples, each with an “accessible” option and an “inaccessible” one, and argues that people with disabilities prefer the inaccessible one. The conclusion you are led towards is risky and false: that the inaccessible solution might be the better one.

I’d rather take a different route. Let’s analyse each example and look for a genuinely better answer. Along the way you’ll get a clearer picture of how color works, which tools exist, and how to actually test your hypotheses.

Myth 1: WCAG requirements are always optimal

They aren’t. The name says it: WCAG are guidelines, meant to help designers and developers build better interfaces. As soon as you start working with color, both personal taste and real user needs will collide with your sense of beauty.

But designing is not about your preferences or your taste. It’s about usability and about meeting user needs. Most of the time, color isn’t essential to usability at all. Start with fifty shades of grey.

Some people I know go much further than I do and design in black and white. (Wink wink, Inclusive-Components.design by Heydon.)

The colors under test

Back to the colorful stuff. When you design an accessible interface with color, two things don’t matter:

  • your ego:
    though we will still need your taste and your expertise to make the whole thing hold together;
  • the brand color definition:
    if the brand colors aren’t accessible, change them. Not the brand itself: pick a neighbouring, more contrasted shade for the interface. That’s where your taste earns its keep 😀
    I know it isn’t always possible. An alternative stylesheet is another option, but for me it’s the last resort to keep both users and brand people happy.

Let’s take Anthony’s own example.

Two buttons side by side: one with white text on a light blue background, one with dark text on the same light blue, shown on a dark and a light background.

I’ve kept both the light and the dark background here, because Anthony ran his poll on the dark image and then argued about contrast on a white page. Worth knowing: context changes how you perceive and read color. That’s a topic of its own, and I come back to it later in this post. From here on I’ll study the buttons on a light background only, one example is enough to make the point.

Here is the contrast data. Tests use a 16px font size and a medium font weight, because both matter to the analysis:

  • White on blue
    White #FFF, blue #57ACF9
    Contrast ratio: 2.5:1 (minimum 4.5:1)
  • Dark on blue
    Dark #2D2D2D, blue #57ACF9.
    Contrast ratio: 5.6:1 (minimum 4.5:1)

According to the source of the survey, respondents preferred the white text.

And that’s where I have a problem. Roughly 5% of the world’s population is colorblind, far more if you include other visual impairments, and 29% of the people who answered the poll picked the accessible version. I won’t pretend those two numbers map onto each other. But some of the respondents may well be colorblind, and even those who aren’t chose the accessible version in fairly large numbers.

There’s a second problem: “do you prefer A or B?” cannot give you the right answer. Ask instead “how easily can you read A?” and then, as a separate question, “how easily can you read B?”. And rather than a binary “easy / not easy”, use a rating scale.

In Anthony’s case, I’d say neither option works. Why?

Partly because WCAG uses maths to measure something that is fundamentally about perception, which is a genuine problem. It’s even been logged as an issue on the WCAG repository.

On top of that, Anthony overlooks brightness difference and color difference, which matter enormously in any contrast analysis. They cover a different facet of perception, related to high contrast sensitivity, sometimes called Irlen syndrome. WCAG says “color contrast”, but what it actually measures is the luminance difference between two colors. Anyway.

Brightness is not contrast. It’s about the perception of light. Which is why analysing contrast alone, in situations where brightness does the work, doesn’t really make sense.

Back to our two color pairs:

  • White on blue
    Brightness difference: 107 (minimum 125)
    Color difference: 277 (minimum 500)
  • Dark on blue
    Brightness difference: 103 (minimum 125)
    Color difference: 353 (minimum 500)

Both fall short. That’s why dark on blue still doesn’t create a real, perceivable difference when you put it in front of people, so they answer with their taste instead.

So yes, WCAG measures the wrong thing. But the proposed alternative isn’t right either. Let’s improve those buttons.

How do you fix color contrast?

If people prefer white text, keep the white text and change the blue behind it. That’s how you improve both contrast and color differentiation.

I love playing with Color.review: it gives you the indicators you need to pick an accessible pair, and shows you what the result looks like.

Color Review Contrast Tool

After a bit of tuning, I landed on a blue that meets AA (the intermediate level of requirements) with far better brightness and color differences.

The new button, sitting between the two original proposals.

With that new background, the numbers land much closer to what WCAG asks for:

  • NOT accessible, white on blue
    White: #FFF, Blue: #57ACF9
    Contrast ratio: 2.5:1 (minimum 4.5:1)
    Brightness difference: 107 (minimum 125)
    Color difference: 277 (minimum 500)
  • Accessible, white on blue
    White: #FFF, Blue: #0B77D8
    Contrast ratio: 4.5:1 (minimum 4.5:1)
    Brightness difference: 158 (minimum 125)
    Color difference: 419 (minimum 500)

To check that this is a real improvement and not just my taste, I ran my own questionnaire (link is the result of the questionnaire instead of the Twitter post, since I left Twitter/X) on readability, and asked respondents whether they were colorblind. The numbers are below.

Comparing the results

No surprise: when you ask about each option separately, people answer about readability rather than taste. Here is what came out.

For every button I asked the same question: “Can you easily read the text on this button?”, with the same 1-to-5 scale. A rating of 1 means “no, not easily” and 5 means “yes, easily”. On the charts below, the horizontal axis is the rating and the vertical axis is the number of responses.

Proposal 1: Button with white text and blue light background

Bar chart of ratings for the first button, described in the text below.

People are reasonably comfortable with this one, though plenty still rate it below 4/5.

Proposal 2: Button with dark text and blue light background

Bar chart of ratings for the second button, described in the text below.

Very mixed feelings. This one doesn’t get us where we want to go.

Proposal 3: Button with white text and blue accessible background

Bar chart of ratings for the third button, described in the text below.

Almost no debate here. I think we did well.

Proposal 4: Button with white shadowed text and blue light background

Bar chart of ratings for the fourth button, described in the text below.

This one tried to solve the contrast problem with a text shadow while keeping the inaccessible colors. It didn’t work.

To compare the options, I arbitrarily treat “readable enough” as the share of people who rated a button 4 or 5.

  • Most readable overall
    1. Proposal 3 — my more contrasted button: 89.5%
    2. Proposal 1 — Anthony’s inaccessible light blue with white text: 68.8%
    3. Proposal 4 — the text-shadow version: 56.6%
    4. Proposal 2 — Anthony’s “accessible” version with dark text: 46.5%
  • Preferences among colorblind respondents
    1. Proposal 3 — my more contrasted button: 45 – 90%
    2. Proposal 1 — Anthony’s inaccessible light blue with white text: 40 – 80%
    3. Proposal 4 — the text-shadow version: 35 – 50%
    4. Proposal 2 — Anthony’s “accessible” version with dark text: 35 – 50%

The result is entirely about accessibility: counting only the 4 and 5 ratings, we produced a button that 89.5% of respondents find readable, and 90% of the colorblind ones. (With more voters the two figures would probably have converged.)

Pie chart of respondents: 91.1% not colorblind, 5.1% colorblind, 3.4% don't know, 0.4% prefer not to say.

N.B. These are most likely people who don’t use a screen reader to read content. There are many degrees of visual impairment, and my survey deliberately stayed focused on color rather than asking for more detail.

You will never find a solution that works for 100% of people. Your job as a designer is to include as many as you can, and when you’re not sure, hand control of the interface back to them.

Going further with color contrast

When people think about color accessibility, they assume the design will end up ugly. I still don’t know where that idea comes from, and I’d genuinely like to.

As a designer, you already work inside constraints all the time:

  • a budget, more or less precise;
  • a given material;
  • a limited space: a phone, a tablet, a small room if you’re doing home staging;
  • and so on.

Accessibility is just another constraint. Like the others, it should be a trigger for creativity, not a blocker.

Daryl Koopersmith and Wilson Miner wrote a good post on designing accessible color systems. It’s a solid example of how to build an accessible color system and then make efficient components out of it.

PS. I’ve heard that Stripe isn’t great for screen reader users. Different topic. And baby steps beat no steps.

On context: dark interface VS light interface

I said earlier that I tested the buttons on white, but showed you two backgrounds on purpose.

Context is what reveals how perceptual color really is, and how much your eyes and brain do the interpreting. The whole thing sits under the abbreviation HVS — human visual system model.

The same two buttons again, shown on a dark background and on a light background.

Short version: on a light interface, with a blue button and white text, your eye barely has to adjust. Dark text on that same button forces a bigger adjustment, so it feels harder to read. Supposedly. It’s a little like walking from a bright room into a dark one, your eyes need a moment before the shapes appear. Perception and the brain are complicated.

Myth 2: Text must meet AAA, or it isn’t accessible

I had never come across this one before, but for the record: most European public sector websites are required to meet AA.

[…] in the EU Member States are obliged by law to ensure that the information they publish is subject to accessibility standards, in particular the Web Content Accessibility Guidelines (WCAG) AA standards.
—Source

Patrick H. Lauke — self-described WCAG trash panda, and an expert in web standards and accessibility — explained it to me in deliberately simplified terms.

A, AA and AAA are separate levels of compliance, ordered by how many people a failure affects and how critical that failure is. Level A criteria affect a lot of people and are seriously detrimental when they fail. AAA affects a smaller share of the population, is usually less of a show-stopper and more of a surmountable but disproportionately annoying problem, and it generally demands more fundamental changes to design and layout. As he put it:

“AA is generally accepted as the baseline. AAA goes above and beyond, to help people with more severe visual conditions.”

So the myth is only right in a narrow sense: you need AAA if you want to claim AAA conformance and reach the widest possible audience.

The point of a minimum is to push people to make an effort for those who need better readability. If WCAG has three levels, it’s to encourage you to keep going and discover what accessibility buys you. Cover all the level A criteria and you’ve already done well. Next stop: AA 😊

And if someone tells you AAA is only for old people, because they’re “mostly” the ones with 20/80 vision, and for people who don’t use a screen reader, purely to excuse skipping it, then you’re not building anything inclusive.

Besides, my source puts the number of people with impaired vision in the US in the millions. In 2017: 3,894,406 people with vision below 20/40, 1,483,703 below 20/60, and 1,082,790 at 20/200 or worse. Those figures cover people aged 45 and over.

Table of US statistics on visual impairment and blindness by degree of vision loss in 2017.

There are two good reasons to aim for AA or AAA:

  • your user research told you to;
  • you want to be accessible and inclusive by default.

Use global studies to get a sense of direction, but don’t stop there: do your own research, with your own users.

Myth 3: grey text and buttons are inaccessible and look disabled.

It depends.

In user tests I ran at Foyer, the largest insurance company in Luxembourg, 100% of our testers behaved the same way: they read grey buttons as disabled, despite adequate contrast. I can’t share the recordings or the raw numbers, but I can give you the takeaway, affordance depends on a lot of contextual parameters.

Grey buttons are often used for secondary or cancel actions, deliberately made less eye-catching so people focus on what you want them to do.

You can get the same effect with a different combination of styles:

Propositions for secondary actions with less eye-catching contrast but still accessible

Your boundaries, a border, for instance, don’t need to meet a contrast ratio, as long as the text does.

If a button with text also has a colored border, since the border does not provide the only indication there is no contrast requirement beyond the text contrast.
—WCAG 1.4.3 – Contrast (Minimum)

Again: do your own research, and remember you’ll make mistakes. That’s fine. Learn from them.

Myth 4: color alone isn’t enough to conver information

That’s not a myth. It’s accessibility 101, arguably usability 101 too. This section leans on Use of Color, but also takes cognitive disabilities into account.

You can’t treat color in isolation from the rest of accessibility and usability. Color accessibility is one small piece of the field, and it has to work alongside cognitive, motor and auditory considerations.

The requirement says:

“color should not be used as the only visual means to convey information, indicate an action, or distinguish an element.”

It applies wherever different colors carry specific meaning for the user. In other words, if color differences carry information, you need a second cue. That’s for visual impairment, and for cognitive impairment too.

Anthony writes that if you use lightness and darkness to convey information, you don’t need an extra cue as long as the contrast difference is high enough. What does that actually mean?

I tried several times to rephrase it and I can’t make it work: using color differentiation to carry meaning isn’t enough, full stop. Lightness and darkness are still color differences, and they still mean nothing on their own.

So yes, on a strict reading of WCAG, Anthony is technically right. Technically isn’t enough. It still leaves users confused.

Two toggle tokens, one blue and one grey, with no other indication of state.

Take the toggle tokens. With only a couple of items, you can’t tell what the initial state is, whether anything is activated at all. Same problem if every item starts grey: you have no idea what’s checked and what isn’t.

Three toggle tokens, two blue and one grey, forming a visible pattern.

Add one more item and your brain starts building a pattern. Items that look alike share a state, so you can begin to guess. But why guess? Use the visual cues people already know, the ones that literally mean “this one is selected”. Cognitive disabilities are part of accessibility too, and making people guess your intent goes badly often enough. More so for those users.

Toggle tokens with a check icon on the selected ones.

And voilà. I mean — what does it cost?

Color is for decoration, mood, theming. It should support your message, not carry it alone. Color has no inherent meaning, whatever the many purely cultural interpretations you’ll find online say. Of course you’ll use red for errors, but the meaning lives in the words you write and in the indicator next to them, an icon, an image.

And even then, whether an icon is easy to interpret is another accessibility and usability question entirely.

To get a complete solution here, the code should also carry this meaning, but that’s another technical aspect I won’t dive in.

Color contrast takeaways

That was a lot of information, some of it contradicting what other experts say loudly and clearly. Here’s what to keep:

  • Always run your own tests with your own users.
  • Don’t let your ego kill user feedback.
  • WCAG isn’t always right. They’re actively working on improving contrast calculation, which is admittedly basic today.
  • If you’re thinking about accessibility at all, you’re already ahead of a lot of designers. Now practise, and stay open to feedback.
  • If you feel lost, ask the experts — there’s a community for that.
  • There’s always something more you could do. Know when to stop.

I’m around: comments, Bluesky, LinkedIn or WSocial are there for that 🙂
Thanks to Patrick H. Lauke for his advice.

Resources and external links

I learned from these, along with the other resources linked throughout the post.

Share the post "There is no “Myths of Color Contrast Accessibility”"

  • LinkedIn
  • WhatsApp
  • Reddit
  • Shares

Related Posts