September 16th, 2021
The WCAG contrast requirements are flawed. Here’s what a new approach could mean for data visualizations.
A few days ago on the internet, I stumbled upon a person who criticized what I took for granted: The W3C Accessibility Guidelines (WCAG) for color contrast.
If you’ve been choosing colors and you or your organization cares about accessibility, you’ve seen the infinite number of color contrast checkers — 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, etc. They all answer the question: “Which color should your text be to be readable on your background color?” And they all give your color pairs a red FAIL ❌ or a green PASS for AA (minimum contrast) or AAA (enhanced contrast) requirements. Sometimes, they also give you a ratio: 4.5:1 is good. 3:1 is still ok for large text. 2:1? FAIL. The higher the first number, the better.
WCAG is the gold standard. Organizations check with them to create style guides. Some governments make them a legal requirement.
But there’s one person who doesn’t approve: Andrew Somers, Hollywood-based filmmaker and vision-impaired himself. In April 2019, he opened issue #695 in the GitHub WCAG repo under his internet name Myndex. The WCAG contrast check was, according to Somers, “not meaningful.” The result is a “ton of apps that now incorrectly present colors as ‘accessible’ when in fact they are not.”
Somers had an easily provable point. If you play around with text and background color a bit, you can get some weird results: Color pairs that are better readable than other ones but get worse WCAG ratios:
You can find more examples here.
Somers wasn’t the first one who found issues with the WCAG guidelines (the “orange button problem” is a thing), but he was the first one who pressed on the issue, kept writing about it, and became part of the Accessibility Guidelines Working group. He’s now developing an “Advanced Perceptual Contrast Algorithm,” or APCA.
If the WCAG 3.0 guidelines include APCA — right now, the draft mentions it and the “significant updates” it would come with — this will have consequences for style guides, website designs, and, yes, data visualizations.
We’ll have a look at that in a minute. First, let’s understand the problem Somers complains about.
The current WCAG contrast is calculated as the luminance of the foreground color divided by the luminance of the background. It’s that simple. Too simple, says Somers.
The key lies in using luminance as the basis of the calculation. Luminance is “a linear measure of light, which is spectrally weighted for human vision, but not perceptually weighted in terms of lightness to darkness,” as Mozilla explains.
The “not perceptually weighted” part is important here. Our sense of how light a color is doesn’t track perfectly with its luminance value. If a color’s luminance is decreased by X%, we don’t perceive it as being X% darker. What we do perceive depends on:
The WCAG 2.0 contrast calculation doesn’t take these things into account. Somer’s new algorithm, APCA, is an attempt to do so more. Somers tested 500 randomly chosen color pairs. Of the 154 color pairs that the WCAG contrast calculation thought of as accessible, 50% were not. And of the other 346 color pairs that WCAG said are not accessible, 22% were. These are a lot of false FAILS and PASSES.
In data visualization, we use a lot of grays — not just for graphical elements like axis grids, ticks, and context data, but also for text like axis labels, descriptions, footnotes, source links, and annotations. Let’s see what WCAG 3.0 standards that include the APCA could mean for data visualization:
This overview shows how different grey text colors perform on white and black backgrounds in both WCAG 2.0 contrast checks and in the APCA contrast calculator. The differences are interesting. I’ve often felt that the current WCAG wanted me to go far darker with my grays on a white background than I deemed necessary to be readable. APCA allows data visualization designers to use lighter grays without feeling bad about accessibility:
We at Datawrapper, for example, use a #888888 gray on white in our visualization footers for information like source, byline, or the Datawrapper attribution. (Open any chart in the Datawrapper River to see for yourself.) This color pair gets a lousy 3.5:1 in WCAG color checkers. APCA gives it a 63%, which is “‘sort of’ like the old 4.5:1 in WCAG2,” according to Somers.
On the other hand, the WCAG are ok with darker grays on black than APCA is. Somers points out that the current WCAG “fails to predict contrast appropriately if the background is darker than about #aaa”.
If you’re designing visualizations with dark backgrounds, your text will need to be brighter in the future. The consequence will be better readable data visualizations.
You can try your own color contrasts with the APCA Contrast Calculator. Somers started building it himself in 2019:
It’s a crazy-looking tool and the algorithm is still a work in progress, but it’s usable. It took me some time to understand what was going on there, though. To get you started immediately, here’s an explanation:
This is the most important part of the tool. Insert your text color in 1 and your background color in 2. Different from the WCAG color check, APCA takes into account which of your colors is the text and which one is the background color. You can try it out yourself with 3 “Click To Swap”.
Inserting a text and background color will give you a number, the 4 “APCA contrast.” It doesn’t matter if the contrast is positive or negative; the absolute number is what’s important. You can think of these numbers as shares: 0% is no contrast, 100% is the highest contrast possible. The -61% in the screenshot means the contrast is fairly good.
Scroll down to “General guidelines on Levels” for a good explanation of the numbers. As a rule of thumb:
But how large is “large text” and “normal text”? The APCA calculator tells you. It shows you not just which color pairs are accessible and which ones are not, but also for which font sizes and weights that applies. That’s what the row below the actual contrast check is about:
What’s a “level 4,” you wonder? Well, in an early version of the tool, Somers came up with different “accessibility scores” you can meet. They might disappear from the tool eventually. For now, “level 4” is still a relic from that time. It will meet “readability best practices, and [is] intended to accommodate sighted users including those with impairments that do not otherwise need assistive technology” (source).
Thanks to the rest of the row, you can either check
In our example, we should use a bold font weight 700 when using 14px text — but if we show our text in the bigger 36px, the thinner font weight 300 is enough.
The WCAG 3.0 don’t have a release date yet. (WCAG 2.2 — which doesn’t include APCA — was supposed to be published in summer 2021, but is still only a draft with some to-do’s.) It might take one, two, or three more years until it’s out and organizations and governments will need to adapt. Until then, I recommend taking the current WCAG contrast calculations with a grain of salt. Comply with them if you must — but for ensured accessibility, test your color combinations with APCA, too.
As mentioned (and Somers would want me to emphasize that), the tool and the algorithm are still being developed. The contrast numbers you get with APCA might not be the ones you get in a year from now. I’ll update the numbers in this blog post as soon as I notice that they change.
I expect there will be many articles published about APCA in the following months and years to come. Here are a few starting points: