Are these colors constrasting enough? (probably not)

📢 Quick announcement!

I want to make sure these issues are super high quality and want to incorporate more feedback into my writing process so I’m announcing a new Beta Readers program.

As a Beta Reader, you’ll get a first look at all my issues via Google Doc with the humble request that you provide feedback within 24 hrs.

Besides getting a preview of the Not A Designer drops, I’ll also send you swag as a thank you. So if you like mugs, t-shirts, stickers, and want to help make this newsletter even better, reply telling me a bit about yourself and let me know you’re interested!

Back to the show…

As someone without web accessibility needs, I must admit that accessibility isn’t something that’s top of mind during my design process. I do a gut check that things look contrasting enough and I try to use alt-text when I remember (yikes), but I haven’t done a good job of making sure my work is accessible to everyone.

I know it’s something I should do, I know it’s the right thing to do, but for reasons I can’t explain, it’s never been a priority. I want to change that.

I’m going to do a better job of educating myself on accessibility issues and try to incorporate them into the Not A Designer newsletter so we can all be a little more inclusive.

Let’s make a better Internet for everyone, together.

Today’s topic is color contrast.

It’s something I hear a lot about in accessibility conversations, and, since picking colors is a big part of design, it felt like a great topic to start with.

On a high level, I know that contrast is important for people with low vision, but I never knew exactly how to define contrast that’s good enough. I use my own uninformed opinion to eyeball how contrasting two colors seem to me, which is a terrible way of approaching the topic and, after learning more about it for this issue, is something I do not recommend.

But before we talk about the solution, let’s take a moment to understand the problem.

What is “low vision”?

Having low vision means that a person experiences a loss of sight that’s not correctable by glasses, medicine, or surgery. It’s more common as we get older but can happen at any age.

Low vision isn’t tied to one particular visual impairment and isn’t experienced the same way. Visual impairments that can result in low vision include, but are not limited to, diabetic retinopathy, age-related macular degeneration (AMD), and glaucoma. Having low vision can impact your sight in a number of ways, and one of them is having a harder time telling the difference between low contrast elements.

While that information is helpful, I still find it hard to wrap my head around what that means for my design process. What I really want to know is: how hard is it really for people with low vision to experience my designs? What does my product look like to them?

How do low contrast elements look?

To better appreciate this problem, I tried to find a simulator that would help me see first-hand what poor design choices look like for people with low vision.

There are a number of tools that work in different ways, including downloadable apps, Figma plugins, and browser extensions. Some of them are unfortunately defunct, but, with the help of amazing people on Twitter, I was able to find two ways to simulate low contrast vision that are built right into my dev tools!

Firefox Devtools: The first is in Firefox. Shoutout to Konnor Rogers and Todd Libby for sharing this with me.

All you do is:

1. Open dev tools

2. Click “Accessibility”

3. Select “Contrast loss” from the “Simulate” drop down

Here’s an example of what a landing page looks like using this simulator.

Chrome DevTools: You can also use Chrome’s built-in visual simulator for the same thing.

1. Open Chrome Dev Tools

2. Press Ctrl + Shift + P

3. Search for "rendering"

4. Click on "show rendering"

5. Scroll down until you see an “emulate vision deficiencies” section

6. Select “Reduced contrast.”

Here’s what my landing page looks like according to this simulator:

You’ll notice these two simulators gave me very different results.

Firefox makes everything darker, which is the kind of low contrast often experienced by people with something like cataracts, which can reduce the amount of light that enters the eye, making everything look a little darker.

Chrome simulates the experience that people with conditions like glaucoma would have, which makes them more sensitive to light and hard to distinguish elements on brighter backgrounds.

Low contrast looks different for different people, and using both of these built-in tools gives us an appreciation for how our designs can look depending on the type of low contrast the user is experiencing.

Big green button

The contrast on our example landing page isn’t great (it actually fails our accessibility requirement, more on the requirement later!), but it’s not the worst. To illustrate this problem better, let’s look at a button we’ve probably seen a lot in the wild, a “Get started” button.

If I were designing a “get started” button from scratch, a color I would intuitively reach for is green. Green means “go!” and feels active, but it can be a tricky color to work with. For those of us who don’t experience low vision, a bright green color like the one below can feel like a great choice!

It’s eye-catching, it’s fun, it screams “action!” But what does this look like to our low vision users?

Neither of those is great, but the bright one is particularly bad. I can barely make out those letters!

The dev tool simulators are a great way to help us understand the problem and empathize with our users with low vision.

But how do we quantify this problem? How do we know what our contrast should be?

What are the requirements?

To answer this question, we turn to the WCAG, which stands for Web Content Accessibility Guidelines. It’s the go-to source for web accessibility. It has helpful, straightforward guidelines for tons of stuff, including contrast. You can read the contrast guidelines here and here.

There are two levels of guidelines, the minimum, called Level AA, and the enhanced, Level AAA. The enhanced level tends to have more stringent requirements.

The contrast guidelines specify a particular contrast ratio that our text and our background should meet for both small and large text.

Here they are:

Wait, what’s a contrast ratio?

For a guideline to be usable, it’s best if it’s measurable, and luckily, contrast is!

Contrast is quantified by our contrast ratio, which tells us how bright and dark two colors look on a screen. The ratio comes from comparing the luminance of the two colors. There’s a whole scientific formula on how to do this, which takes into account what the RGB values are, but all we need to know for our purposes is that we want that first number to be high – the higher it is, the bigger our contrast.

The range of contrast isn’t that big – we’re talking under 21. But a single point can make a big difference.

That bright green that was fun but inaccessible? It had a contrast ratio of 2.01:1. Ouch, not good.

Let’s see if we can increase that ratio and make it accessible by using a darker green.

Here are the before and after:

As a non-low-vision-experiencing-person, that definitely looks more contrasting!

I used Figma to make these buttons and Figma has a bunch of plugins to incorporate accessibility into our design. I tried a few and the one that I really liked is called Able created by Sondre Kvam.

You pick two layers and it will:

1. tell you the color ratio

2. state whether it passes WCAG level AA and level AAA

3. simulate how it looks for different vision impairments.

It’s a free plugin that’s super easy to use.

Let’s run the Able plugin on my new button and see how well we did. Here are the results:

Failed on all fronts!

Let’s see how this button looks with our dev tools simulators.

Oof, that’s tough.

What’s amazing to me is how high contrast this felt as a person who doesn’t experience low vision, but how completely wrong my instincts were. This taught me how important it is to rely on easy-to-use tools instead of my gut to make sure I build accessible products.

When it comes to contrast, my gut is not very reliable.

Let’s pick a darker green and see if we can get that contrast up to code.

Let’s check with our Able plugin. 

Much better! Let’s see what this looks like with our simulators.

More readable for sure. From looking at my simulator, I feel like we could still go a little darker and improve what that Chrome output looks like, but we made a lot of progress.

Let’s compare all three buttons and their contrast ratios side by side.

Let’s look at another example.

Another button I see a lot in products is a big red “Delete” button. The question is, what color red do we pick?

Without checking my contrast ratio, here’s one that I might start with.

If I use my gut to assess this, it looks great! Nice, bold red, I’m sure this will pass … won’t it?

Let’s run Able and see.

Womp, womp, we were wrong. It passes on large text, but fails on small, and, since this is a button, I want it to pass that small text guideline.

So how much darker do we need to go to pass?

Luckily, not much! Here’s a red that passes the contrast guideline.

Let’s put them side by side to compare.

There’s definitely a difference, but not one that would change a design dramatically. I’m still within my range and likely within my color scheme, but to our users with low-vision, we’ve made a big difference.

Fixing contrast issues IRL

Having accessible colors is important for every product, regardless of size, and the more popular the product, the more low-vision users you’re likely to have.

Unfortunately, not all products get this right the first time, but it’s great when they learn and fix their mistakes.

My favorite example of this comes from a blog post by Rachele Detullio about YNAB updating their UI elements to increase the contrast and make it more accessible. Her post is full of goodies you should definitely check out, but in the meantime, here are the before and after of YNAB’s elements.

What I love about this is, not only is the “after” more accessible, it’s also prettier to look at. Double win!

How to incorporate contrast into your design process

There are a lot of tools to help make your product more accessible, but without an easy way to incorporate them into your workflow, you just won’t do it.

So here are three ways you can incorporate accessible colors into your workflow.

1. Start with an accessible palette
   There are accessible palette generators you can use to help you pick colors with great contrast ratios. Check out this one by Venngage. You can start with one color you like and it’ll build palettes for you based on that color. That way, you know every color you use is safe.
   

   

2. “Pick and check” with a plug-in 
   The easiest way to include accessibility as you design is to do a “pick and check” throughout the process. Use Able in Figma to check elements as you build them. Even if you have an accessible palette to get you started, there might be a random color you need to add to make your design work. Use this plugin to do a quick check as you work before committing to the color.
   

3. Do a browser check
   As a final check, use the simulators in your dev tools to see how your page comes together and appreciate what your low-vision users experience. Make sure to do it in both Firefox and Chrome so you can get the range of low-contrast experience.

Hopefully, this issue gave you a solid introduction on how to think about contrast.

Key takeaway

For me, the biggest takeaway was that eyeballing what looks good to me as someone without low vision is not a reliable way of making my designs accessible. There are lots of tools that do a much better job. Let’s use those tools to create a better web for us all.

In the meantime, there are wonderful people on the internet who do great work on accessibility that I want to shout out. Make sure to give them a follow and check out their work!

• Africa Kenya: She calls herself the A11y Baddie, and she is! To learn from her, check out her accessibility study group and her web accessibility trainings on YouTube.

• Todd Libby: Todd is a breath of fresh air on social and always willing to lend a hand, especially on accessibility topics. You can check him out on his site here and listen to his Front End Nerdery podcast.
  

• GrahamTheDev: Graham was so helpful in tipping me off to accessibility tools for this issue and he’s turned this passion into a great service that helps SaaS businesses become more accessible, called Toa11y (clever!).
  

• Sara Souiden: A huge name in web dev and accessibility, Sara has a great course teaching application accessibility to the rest of us, called Practical Accessibility.
  

• Rachele DiTullio: Besides writing that excellent YNAB post, she’s written tons about accessibility. For a solid intro to accessibility testing, check out her resources here.

My goal with this issue is to make it easy to incorporate more accessible color choices in your product. How did we do?

Happy designing!

Saron