There is no “Myths of Color Contrast Accessibility”

Also available in: Français

When you need to work on interfaces, color contrast is a real thing you have to take into account to make it accessible. You have the right to be afraid of losing part of the aesthetics of your beautifully well designed interface, and you are right if you are used to poor contrast ratio. Accessibility comes with its constraint, but not much more than UX (User Experience) Design.

Definitions

I would like to start with my definitions of Accessibility and User Experience. I know the definition of both is quite complex and not always shared by the experts, so sorry not sorry, I’ll give it a try.

User Experience

The User Experience is the feeling, the attempts, the hope, the actions, the failure and success, the frustration, the memory, etc. a person has with a product or a service. Depending on the goal you want to reach, this experience can be bad or good. Even with the idea of reaching a bad experience, it could totally be on purpose by the designer of this experience. Oftentime as a designer you tend to provide a memorable experience in a good way to make your users understand, use and love the product/interface. Making interfaces usable comes with the need to understand a specific group of people so that you can help them achieve a precise task with efficiency, effectiveness and satisfaction.

Accessibility

In our domain, Accessibility is the practice of making websites or application usable by as many people as possible. We often think it’s applicable to only people with disabilities, which is by definition the case, but it definitely benefits other groups of people in some specific cases or context.

Where user experience tend to satisfy a precise group of people, accessibility tends to include as many people as possible in a common good experience, but both are not mutually exclusive.

The Myths of Color Contrast Accessibility

This blog post is an answer to this eponymous article.

I would like to thank Anthony for pointing out some of the things that seem to be myths around the designer community. I personally discovered some of them by reading the article.
The issue is perhaps not so much what Anthony says but the way in which he says it – it makes you think that you shouldn’t trust one of the most known Accessibility Guidelines (WCAG), because it is not what users need.

The article guide readers through several visual examples with one solution that is supposed to be accessible, and one that is supposed to be inaccessible, arguing that the inaccessible solution is preferred by people with disabilities. That leads you to a false risky conclusion: could the inaccessible solution be a better (the best?) solution?

I want to work and guide you on a better path: analyze the issue and find a better solution for each example demonstrated by Anthony. This guide should help you better understand some principles around color, available solutions, and tips to really test your hypothesis.

Myth 1: The WCAG requirements are always optimal

Indeed they are not. As the name said, WCAG are only guidelines to help designer and developers build better interfaces. When you start building your design with colors, both people’s tastes and user needs will bother your sense of beauty and your feelings about what is delightful or not.

Anyway, designing is neither about your preferences nor about your taste. It’s about usability and matching the user needs. Most of the time, color is not essential in terms of usability. Start with fifty shades of gray compositions.

Some people I know are going way further than me: they design with black and white. (wink wink Inclusive-Components.design by Heydon)

The colors tested

But let’s back to our colored stuffs.
When you need to design accessible interfaces with colors, 2 things are not important:

• your ego, even if we will need a bit of your taste and expertise to compose the interface and find harmony,
• the brand color definition: if those are not accessible, change them. I don’t mean you should change the original brand color, but pick one close but more contrasted for your interface. Here we could use your taste to pick the good one 😀
  I know that’s not always possible though. Another Idea could be alternative stylesheet, but to me it’s the last solution to keep both users and branding folks happy.

Let’s take the same example as Anthony.

I used white and dark background on this illustration because Anthony had the idea of making a poll using the dark image, but then argumenting on color contrast on his blog post with a white background.
Just for you to know: context changes the way you feel and read colored things. But that’s another topic (I take a quick shot at it later in this blog post). For the rest of the blog post, I’ll study those buttons with a light background. I won’t play with all the background colors, I’m pretty sure you get the idea with one example.

Here’s the data about the contrasts. Tests are made with a font size of 16px and a font weight of medium, because both of those text styles matter in the analysis:

• white on blue
  White: #FFF, Blue: #57ACF9
  Font-size: 16px – Font-Weight: medium.
  Contrast ratio: 2.5:1 (minimum 4.5:1)
• dark on blue
  Dark: #2D2D2D, Blue: #57ACF9
  Contrast ratio: 5.6:1 – (expected 4.5:1)

Looking to the “source” of a survey, the white text is preferred by the people who answered.

Well! I’ve got an issue with that. Considering the simple fact that almost 5% of the worldwide people are colorblind (consider a way bigger number if you include other visual impairment), and that 29% of the people who answered the poll prefer the accessible version… I don’t want to transpose or compare the numbers, but potentially the people who answered are colorblind, and even if they are not, some of them prefer the accessible version… a lot of them.

Another thing is that you can’t find the right solution by asking “do you prefer A or B”. You should ask: “How many people easily read A?” then on another separate question “How many people easily read B?”. And ideally, instead of a binary “easily read” question, you should probably even use a rating scale.

In Anthony’s case,  I would say both of the solutions are not ok here, but why?

Maybe because the WCAG are using Maths for calculating things that are all about perception, and it’s a real issue. It has even been recorded as an issue on the WCAG Repository.

To go further, Anthony totally forgot the Brightness and Color differences, which is very important in color “contrast” analysis. It covers another aspect of color perception, also known as Irlen Syndrome: this syndrome is about high contrast sensitivity. I’d say that WCAG is talking about “color contrast”, but it’s not really about contrast and more about luminance difference between 2 colors. Anyway.

Brightness is not related to the contrast, it’s related to the perception of light. That’s why analyzing contrast where brightness act is kind of a non-sense.

Let’s go back to our set of colors.

• 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 have a lack of differences. That’s why dark on blue is still not enough to create a real difference when you ask people. They will be more likely to answer with taste preferences.

So yes, WCAG uses the wrong measure, but the proposed solutions are not correct at all. Let’s find out together how to improve a little bit the readability of our buttons.

How to fix color contrast?

If the preferred color seems to be white on blue, you would rather keep the white as text color and change for a better blue background to improve your contrast and color differentiation.

I love to play with Color.review, a useful tool that gives you indicators to help you pick the right accessible set of colors, with a projection of the rendering.

By playing a little bit with the blue, I finally find something respecting the AA requirements (intermediate level of accessibility requirements), and way better color and brightness differences.

With this new blue background, we get some new data that are way close to the expected WCAG requirements:

• 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)

And to confirm this is a real solution and not a matter of taste, I asked on a questionnaire about people’s preferences on readability, and I also asked I also asked the respondents if they were colorblind. See the next section for more detail on the numbers.

Comparative metrics

No surprise here: when you ask separately what is the more readable, people will be more likely to give you the “readability” answer and not only their taste in term of color. Anyway, here is some extracted data.

For each visual proposition of a button, I asked the same question: “Can you easily read the text on this button?”. For each, the same answer where available as a rating between 1 and 5, where 1 is “Not easily [readable]“, and 5 is “Yes I read it easily”

On the next graphs, you will see numbers between 1 and 5 on the horizontal axis, those are the rating of the visual proposition. On the vertical axis you will find the number of responses.

Proposal 1: Button with white text and blue light background

People are pretty at ease with this contrast, even if a lot are still rating less than 4/5 this visual.

Proposal 2: Button with dark text and blue light background

A big amount of mixed feelings here. This solution is not good at all if we want to reach our goal.

Proposal 3: Button with white text and blue accessible background

There is almost no debate on this solution. I think we did good.

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

This last test wanted to solve the contrast problem by using a drop shadow under the text while keeping the set of non-accessible colors. This did not have the desired effect.

Arbitrarily, I’ll take for “readable enough” the percentage of people included in the upper range (4 and 5 points) to be able to compare our solutions.

• The more readable button
  1. Proposal 3 – Proposed more contrasted button.
     Rating: 89.5%
  2. Proposal 1 – Anthony’s inaccessible light blue with white text.
     Rating: 68.8%
  3. Proposal 4 – The text shadowed version.
     Rating: 56,6%
  4. Proposal 2 – Anthony’s accessible version with dark text.
     Rating: 46,5%
• Colorblind Preferences
  1. Proposal 3 – The proposition I made in term for contrast with the white text.
     Rating: 45 – 90%
  2. Proposal 1 – Anthony’s inaccessible light blue with white text.
     Rating: 40 – 80%
  3. Proposal 4 – The text shadowed version.
     Rating: 35 – 50%
  4. Proposal 2 – Anthony’s accessible version with dark text.
     Rating: 35 – 50%

The result is all about accessibility here: we succeed at proposing a solution which makes the button readable by 89.5% of the population if we keep only the 4 and 5 ratings, and 90% of the people with colorblindness. (the ratings would probably have been closer with more voters.)

N.B: it’s probably a percentage of the population that do not use a screen-reader to read the content. Keep in mind that there are many different degrees of visual impairment, my survey did not ask for more information to focus on color.

While you’ll likely never find a solution that works for 100%, your job as a designer is to include as many people as you can – and if you’re not sure, give them control over your interface.