Read in: Français
What if the web got better over six weeks?
The WebAIM Million report for 2022 identifies the six most common accessibility defects WebAIM found on the million most popular homepages:
- Low-contrast text (you are here!)
- Missing alternative text for images
- Empty links
- Missing form input labels
- Empty buttons
- Missing document language
In his blogpost What if… one day everything got better?, Dave Rupert proposes tackling spending some time tackling each of these issues, one per week, over the next six weeks until Global Accessibility Awareness Day. Once those six weeks are done, you’ll have cleared away some of the web’s most prominent barriers to access on your own sites.
I promised Dave he had my sword, and so this is Part 1 of six resources geared towards helping you make sense of the most common accessibility defects and what you can do about them.
The Web Content Accessibility Guidelines’ first principle of accessible content is that content must be perceivable. After all, you can’t access information or functionality if you can’t make out that it’s there! The most surefire way, it seems, to ensure users can’t make out your content is to set it in a color that doesn’t stand out from its background — in other words, to have a low color contrast.
People can struggle with low contrast for a variety of reasons — maybe there’s a glare from the sun reflecting off of their screen — but low-contrast text has an outsized impact on visually disabled users such as those with low vision or who are colorblind. On top of that, low-contrast text is everywhere. The WebAIM Million report for 2022 found that nearly 84% of the 1 million most popular homepages had at least one low-contrast violation, with an average of 31.6 distinct instances of low-contrast text per homepage. A 2021 report from Deque Systems (PDF) found that low-contrast text made up 30% of automatically detectable accessibility defects, making it the most common accessibility defect by far.
Remediating low-contrast text could go a long way towards making the web more usable. Let’s dive into how we can measure contrast, remediate low contrast easily, and build sufficient contrast into our sites going forward.
The easiest way to get started is with a color contrast checker. Tools such as the WebAIM Contrast Checker will take a pair of colors you give it and spit out a contrast ratio. Meanwhile, if you’ve already deployed your site and colors live for the world, you can use full-page accessibility scanning tools such as the axe DevTools extension, and they’ll perform color contrast operations for every bit of text and background on your page and identify specific elements on your page with insufficient contrast. Either way, you’ll get a color contrast ratio as a result.
These ratios take the format
This ratio isn’t really a score of how different the two colors are, per se, but rather a score of how discernible one color would be on top of the other. For instance, as someone who is not colorblind, the CSS colors tomato (#ff6347) and cornflowerblue (#6495ed) strike me as very different colors:
However, tomato and cornflowerblue have a very poor color contrast ratio together: only about 1.009:1. That’s barely better than comparing any color to itself! If we stack those colors on top of each other (apologies in advance!), we can see that this pair of colors is difficult, if not outright painful, to read together:
You don’t want to read this.
The current color contrast algorithms we use to get these ratios aren’t trying to give us the pure, mathematical difference between two colors, but rather describe a more subjective difference between the two colors based on human perception. Namely, the algorithms compare the two colors’ relative luminance — which essentially boils down to whether one color is lighter or brighter than the other. Here, tomato and cornflowerblue are pretty much equally bright, which is why they’re difficult to read together.
Making Use of the Ratios
Now that we’ve got a sense of how we’re measuring the contrast between two colors, how do we know when the contrast is sufficient?
In Success Criterion 1.4.3 of the Web Content Accessibility Guidelines, the World Wide Web Consortium sets forth two key benchmarks you’ll need to remember:
Most text needs a ratio of at least 4.5:1 against its background.
The rules for larger text are a little more lax — large text only needs to meet a ratio of 3:1 against its background.
How to Improve Your Score
So you’ve measured your text and determined that it doesn’t meet color contrast requirements. What can you do about this without overhauling your design?
Typically, I approach color contrast remediation one of two different ways on a case by case basis:
- Picking lighter and darker colors
- Embiggening the text
Come to the Light/Dark Sides
Your main approach to remediating color contrast issues will be changing the underlying colors themselves.
Typically, however, you’ll find yourself limited in what you can do if you approach this by changing the colors’ hues. For one thing, brands usually have fairly strict color palettes, and changing hues will often create colors that can’t be found in the brand’s design systems. For another, as the tomato-and-cornflowerblue example from earlier showed, the colors’ hues often have a very minimal impact on the ratio between those two colors, especially if those colors have very similar brightnesses.
Instead, I tend to find that making one color lighter and/or the other color darker has a more profound impact on the contrast, all while feeling more consistent with the rest of the site’s design sensibilities.
Embiggening Is Perfectly Cromulent
Larger, thicker text tends to be far easier to read, even against low-contrast backgrounds, than smaller, thinner text. For instance, in the following example, both lines of text are the same color, but if you can discern the text at all, it’ll be easier to make out the top line of text, which is bigger and bolder:
I’m somewhat easier to read! I’m much harder to read
This difference is why WCAG is a little more lenient for large text, which it defines as text that is at least 18pt or, alternatively, bold and at least 14pt. Remember that pt is a font size unit that’s defined by the user’s browser (much like rem) — in most browsers’ default settings, this means that the threshold is approximately 24px or both bold and about 19px. Text that meets this sizing criterion only needs to have a ratio of 3:1 against its background, according to WCAG.
In some cases, you can use this more lenient threshold to your advantage, as instead of needing to pick different colors, you might be able to bump up your font size or weight. If you’re purely using this approach to meet your minimum thresholds, this fix tends to be highly contextual and will likely only apply to things like headings. However, accessibility isn’t just about meeting thresholds. WCAG is the minimum bar to clear, but once you’ve cleared those minimum thresholds, you can use tactics like upping the font size, increasing the font weight, or picking a thicker typeface to provide a more readable experience, even though they won’t improve your contrast ratio score.
Build Systemic Approaches for Ensuring Color Contrast
These approaches work fine for adding one-off colors to a page or for remediating low-contrast text surfaced by an audit, but it’s not very sustainable for large sites or organizations.
Many organizations are turning towards design systems to communicate their UI and UX practices, including their color palettes, as well as their institutional knowledge about when and how each color in said palettes should be used. These design systems are an excellent place to encode knowledge about acceptable color pairings. For instance, a design system might determine acceptable background colors and text colors for buttons, and these colors might have been chosen based on acceptable contrast ratios. Designers and developers can leverage these decisions without even really needing the full background context of how those colors were chosen — there’s a wide and easy pit of success.
I’ve also heard of design systems that get even more explicit in how they communicate accessible color pairings. One trick I learned from Mike Aparicio comes in how he names shades of a design system’s colorway. In his design systems, every shade of a color is given a number from 100 to 900, where 100 is the lightest shade, 600 is the “base” shade, 900 is the darkest shade, and the other colors are filled out in between as needed. His color scales are calculated such that the “200” and lighter colors are always light enough to contrast against the “600” base shade. This rule is easy enough for designers and developers to remember, ensuring they’re far more likely to pick acceptable pairings. You can hear him talk about this approach on Frontend Horse and on my own show Some Antics.
A Few More Things to Keep in Mind About Contrast
The current contrast ratio systems are pretty thoroughly vetted, but there are a few limitations, such as:
- Current algorithms don’t account for which color is the foreground and which is the background, even though in some color pairs such as brown and pink, one color is definitely more suitable as the foreground and not the background.
- Some typefaces’ bold fonts aren’t very bold, meaning you can meet the letter of the large text requirement without meeting the spirit of it.
A future version of the Web Content Accessibility Guidelines may use a different color contrast algorithm that uses more factors such as these, but it still requires more vetting. If you run into some of these limitations in your design and you feel like your design is just technically conformant, I encourage you to do some user testing if possible, preferably with visually disabled users, to verify whether your contents are or are not readable for real people.
Also, color can be a tricky thing to balance! If you’re finding it difficult to distinguish different content with colors, consider pulling different levers, and using tools such as icons or different font sizes to get your point across! This ensures you aren’t relying on color alone to convey meaning, and building redundant means of getting information into your design will almost always lead to a more accessible experience.
Color contrast issues are everywhere, and clearing them away would significantly reduce access barriers on the web. On a case-by-case basis, I find it simplest to remediate low contrast by adjusting the colors’ lightness or darkness, rather than their hue or saturation. In some cases (namely prominent text such as headings), you might be able to leverage font size and weight. Going forward, contrast should be addressed systemically, typically through codified design systems and ideally vetted with user testing.