In the next installment of her “Accessibility pitfalls for developers” series, Julie takes a look at the second most common accessibility problem we see: colour contrast. Colour is most often a designer’s domain, so why a post about colour for developers? Well, the answer is as complex as the projects themselves.

Recently, I wrote about my review of our 2015 work, and the third most common problem we found, text alternatives. This week I want to take a look at the second most common problem we see: sites that don’t have enough colour contrast.

In the same way that we expect to see images all over the web, we also like to see plenty of colour. What kind of boring internet would it be if everything was black and white? So, I’m not surprised that colour problems are also frequent on the sites we work with. We just need to make sure we’re not stopping people with low-vision or colour blindness from getting a usable and attractive experience, too.

Honestly, my eyesight isn’t as good as it used to be. We’re all getting older, and I find that low contrast layouts are harder to read the longer I spend working with computer screens. A high contrast website goes a long way to creating a high-impact (and readable) online experience.

Your mum and I will take it as a personal favour if you make some easy-to-read body text with nice contrasting headings for emphasis.

Running the numbers

Out of the hundreds of contrast issues we found last year, a whopping 38% were in the headings and text. Links and general navigation menus had 23% of the problems, with forms and buttons close behind at 22%. Icons and notifications (ie., error messages, confirmation alerts, etc.) caused 14% of the problems. And the last 1% of the problems were with text over the top of background images and gradients.

A pie chart showing the percentages of the contrast problems as described above

This is a bit of a worry if you want people to actually read any of the content on your site! Or browse your product menu, sign up for updates, or buy something. If people are trying to give you money, notifications or error messages can be the difference between someone completing a transaction or going to a competitor. Colour contrast might seem like it’s just a matter of making things pretty, but it’s really about the basic functionality of your site. And if there’s some part of your site that you don’t mind being missed or overlooked…does it even belong on the page?

But, isn’t colour a design issue?

If you haven’t worked with contrast before, Elle wrote up a great introduction and overview to colour contrast that’s a great place to start. I’ve also included a few more tools in a list below.

The general rule for Level AA contrast is that normal text needs a ratio of 4.5:1 between the foreground and background colours, while really large text (at least 18 point) can have a 3:1 ratio.

Just like alt text, contrast is not a new technique or earth-shattering discovery. But web design aesthetics change fast, and keeping contrast top of mind is challenging—especially when colour is usually the visual designer’s domain.

So, why a post about colour for developers?

Well, the answer is as complex as the projects themselves. Since developers build the sites and apps, bringing design and UX to life, we often end up “responsible” for areas we’re not in charge of, and some we had no input into. Colour contrast (and even accessibility in general) is often one of those things.

A team-based approach to contrast

So, what do you do if you’re a developer (or the lone accessibility champion in your workplace) and your design team doesn’t know much about colour accessibility? Is it possible to single-handedly change a design to give it enough contrast?

Probably not!

As a developer, I can make a neat, tidy-looking, user-friendly site, which conforms to developer standards. I can test for colour contrast, and if I find low-contrast elements, I can change them to higher contrast in the CSS, or edit the images. But, even those small adjustments can undermine the design decisions of the very skilled visual designers I work with. Design issues usually need approval from multiple people, and sometimes it seems like everyone and their dog feels qualified to have an opinion about cornflower blue versus periwinkle blue. Your design team is working with a lot of other constraints besides contrast.

But you have more opportunity for input than you realize.

Talk early, talk often

Have a chat with your designers before they begin work on your next project. Let them know that your product will be tested for contrast, either by you or as part of your standard quality assurance process—and make sure they’re clear on how to pass. That proactive support will go a long way.

Communication between designers and developers is the best colour contrast tool there is.

A few designers I’ve worked with worry that being restricted in their choice of colours ruins their design. We all like to have free reign in creative tasks, but I believe a constraint like contrast can actually spur more innovative thinking. If your design team isn’t sure about it, invite them to take a look at our own Simply Accessible site. It’s Level AA compliant for colour contrast, and I think it’s gorgeous.

Our site was designed by Geri Coady, whose article Integrating Contrast Checks In Your Web Workflow is a must-read for any designer. She describes her process of working with Simply Accessible’s existing brand colours to create something fresh, original, and accessible. Geri literally wrote the book on colour accessibility, so you know she’ll put you on the right path.

Fitting accessible colour selection and testing into the design team’s workflow is critical. It’s not fair to wait until the end of the project, and then ask designers to change everything they worked so hard on. Give them a heads-up early, and invite them to ask you questions if they’re not sure about it.

Colour all the bases

Make sure you’re addressing all the permutations of your product, because web sites and applications are moving, fluid things.

You’ll probably get a design with good contrast on the body content area, but it might be a bit off on navigation or forms. This is a good time to chat with the designers again about how to make things work. Maybe suggest a few similar colours that pass the contrast standard. They might be happy with your suggestions, or have better ideas.

Hover effects, focus effects, popups, and alerts on forms also need adequate contrast. I have a standard red I use for form error colours: #990000. It’s AAA accessible on a white background, and comes in handy if the design doesn’t specify a style for error messages. And if the navigation has enough contrast in its standard mode but has no hover effect shown, I just reverse the colours for both hover and focus.

For example, check the difference between these two small forms. The one on the left does not meet the Level AA standard for contrast, and the one on the right does.

Two small forms, one with pale grey text and an orange button, the other with dark grey text and a blue button

Which one do you think will be easier for people with low vision or colour blindness to use without making a mistake? And which one do you think will make it easier for them to correct mistakes?

The same forms as above, with error messages added. The first uses medium red text to explain the error, the second uses dark red text.

Don’t forget empty states

Empty states, times when there’s no data, or an error, or a task has just been completed, are where we find a lot of contrast problems in sites which are otherwise very accessible. When I create these states, they’re functional—but, they’re often missed design opportunities to create a good impression or prompt a user to keep using the site. Here’s a great article on designing for empty states to refer your design team to.

If you take the time to let your designers know about where and when these states happen, it gives them a chance to make these moments beautiful as well as functional. And you can test your colours while you’re at it!

Test thoroughly

Checking for colour contrast doesn’t take much time. If you do it early and thoroughly in the design phases, you won’t need to change anything during the build stages. There are plenty of tools that will help you test the contrast of your designs and images without having to get into the specifics of luminosity and optical science. Here’s a few I have bookmarked:

Unfortunately, these tools aren’t always going to find all of the problems with colour contrast. When there’s text over a background image, browser tools aren’t much help because they can only check the CSS colour values. You’ll need to manually get the colours using an eyedropper-style tool and enter them into one of the tools which calculates the values for you.

To make testing your colour contrast easier, I recommend using more than one type of tool so you can be sure you’ve covered all the different ways colour is used on your site. I also recommend getting your visual or interface designer involved with testing, too. The more proactive the design team is about making contrast a priority, the fewer contrast issues you’ll have.

If you’ve made a site that passes AA colour contrast guidelines, I’d love you to drop a link in the comments. Or why not submit it to the A11yWins site so everyone can see a good example of beautiful accessible design? A bit of inspiration and colour make working on the web more fun.

One thought on “Three common accessibility pitfalls for developers: colour contrast”

Read comments

Hi there! We've closed the comments after a week of spirited discussion on this post. If there's something we've missed, please reach out and let us know.