The a11y Monthly: Keep your colors under control

According to the World Health Organization, 246 million people have low vision worldwide. Approximately 1 in 12 men (8%) and 1 in 200 women in the world have some form of altered perception of colors. At Yoast, we’ve decided to review the colors used in all our projects to improve text contrast and readability. Better colors can help people with vision or color perception impairments.

What the rules say

The Web Content Accessibility Guidelines establish a minimum level for contrast between text and its background. The contrast ratio must be at least 4.5:1 for normal text and 3:1 for large text. Without entering into technical details, it’s important to know that the contrast ratio is calculated in such a way that hues are not a key factor.

Instead, the rule is based on the concept of luminance contrast. Requiring contrast that is independent of color perception accommodates the needs of both people with low vision and people who have a color vision deficit.

Know your colors

The first question we had to answer was: which, and how many colors are we actually using? We have a color palette of course. Some colors are part of the brand too. By the way, over the years it’s easy to lose control over the details of a project with a vast codebase.

To get a grasp of the current situation in our projects, we decided to scan our codebase and extract all the colors actually used. There are tools to help extract colors from a stylesheet. By the way, colors can be hardcoded in other files too. For example, inline styles mixed in your markup or defined in JavaScript files. We were quite surprised to find 105 colors in total. Way too many colors!

First steps

Once we got our list of colors, we needed a visual representation. It’s not so easy to understand what color #191b1e is by its hex code! There are professional tools for this and also free online services, for example: CSS Stats.

Having the chance to actually see our list of colors made things clear. Way too many shades of grey. Lots of slightly different blues, greens, and reds. On a personal note, this is something I’ve seen happening on other projects too. It’s understandable, especially after years and years of development. Introducing a new hue or a new shade of grey for a specific new feature may look like a good idea at first. In the long run can be hard to keep your projects sane. Can you tell the difference between two shades of grey like, for example, #dfdfdf and #dddddd? Is that difference even perceivable by your users? You’ll end up wondering why you’re even using those colors.

Making a new color palette

Simplifying everything was our first, obvious, choice. Going down from 105 to 24 colors was fun. In our experience, you only need something like two or three variations for each color. Except for the shades of grey that we use as background colors. If you use colors for text or background, they must have a contrast ratio of at least 4.5:1 against the background or the text.

Thus, it’s a matter of color combinations. Red, for example: once you’ve established your main, accessible, shade of red then you will only need a lighter and darker one.

Make the color palette available to all your projects

I must confess: I’m old-school and skeptical about Sass. It’s a great tool of course, yet I’m arguing about its educational value. It’s perfect for developers with a solid CSS knowledge, but dangerous for beginners. That said, none of our work with colors would have been possible without Sass.

At Yoast, we work on different projects and split development in several components. The new color palette is one of these components. Sass gives us the ability to define the colors in the palette with variables. Mapping the main variables to other variables “aliases” allows us to re-use the palette on all our projects with minimal impact. The existing colors variables in the codebase can be re-mapped in one, centralized, location.

We can use Sass functions like, for example, darken(), lighten(), and rgba() in the rare cases where we need colors variations, but want to avoid introducing new colors in the palette.

We also need to export the color palette to make it available to JavaScript components. We use grunt-scss-to-json because it’s simple enough to generate what we need: a color.json file that we can import in all our JavaScript modules with minimal effort.

This is what Sass is giving us, and it’s priceless! When you know how to use it…

Next steps

There’s still work to do of course. We’ve built our tools. We are using them in all our projects, bringing colors back under our control. Establishing guidelines for the team is also an essential aspect for future improvements. Technical solutions are the base to build a better accessibility expertise on. When accessibility becomes part of everyday’s development practice, the result is a product that we hope is better accessible and enjoyable for everyone.

Want to help?

Accessibility is a process based on continuous improvements, testing, iteration, and development. You can help. We’re always open to feedback and contributions. Please do not hesitate to let us hear your voice. Do report any issues or potential improvements you notice in our products.

Read more: The a11y Monthly: web content accessibility at Yoast »