Engineer and researcher looking at the intersection of accessibility and complex, data-driven interfaces and systems.

What is "No Use of Color Alone" in Data Visualization? (with examples)

Before embarking on the adventure that is this notebook, you might want to check out my Introduction to Contrast and Color notebook if you haven't already. The intro covers a few things that we won't go over here, mostly why this specific topic matters and what this series hopes to focus on.

One of the single-most challenging things that a data visualization designer must overcome is not designing in a way that uses only color to communicate a certain dimension of information. The accessibility community calls this requirement "No use of color alone".

Color in data visualization is heavily discussed as a channel used to encode information by both researchers and practitioners. We talk about color a lot. But color must be redundantly encoded in order to be considered accessible.

Accessibility Options

Animations: By default, using the toggles for categories (before each chart) or changing the chart's props will cause the charts to animate. You have the option to turn that off for all these charts.

Use Animations

Chart Textures, Shapes, and Patterns: Each of the charts below employ textures, shapes, and patterns ("redundant encoding") for the sake of this article. For demonstration purposes, we are allowing you the option to turn these off or on at your preference.

Redundantly Encode Colors

What is commonly done isn't always best

Often when working to meet compliance, attempting to make the visualization work is seen as too much, so practitioners will provide a data table as a fallback and ignore the inaccessibility of the chart itself. Tables are great in the sense that (if structured correctly) they are screen-reader accessible and also technically offer access to the same data that the chart uses to plot.

While every chart should have a table provided (or downloadable csv), I've spoken at length about how the information arranged by a visualization is not the same as the data that it is built to represent. The data and a visualization is not a 1 to 1 relationship. A subject's experience of a chart can produce new insights that simply looking at a table of data may not have produced. If a table really was sufficient, then why do we visualize at all?

Examples

The bar chart below has 3 different categories (West, Northeast, and South), each with a different fill color assigned to them. This chart definitely has some issues.

So in order to pass WCAG's 1.4.1 requirement for "No use of color alone," we are going to add textures to the chart. In addition to these textures, the initial fill colors passed in are too light (and would fail 1.4.11's contrast requirements, see our other notebook on minimal contrast treatment to learn more). So we added strokes around the bars too, to make them easier to see. The final change we made was just adjusting the green to a teal, since a lot of users with CVD may not want textures, so we should at least avoid a problematic green-red combination.

The following use of textures is an example of what a user may wish to have available to them as an option (such as in user preferences, like "Redundantly Encode Colors" under "Accessibility Options" earlier in this notebook).

Note: Before each chart now until the end of the notebook is a toggle option to view a max of five categories, instead of the default 3. Use this to see how redundant encoding can be handled up to a reasonable limit of 5 different categories.

Distinct "Nameability" and Effective, Accessible Categorical Schemes

An under-discussed consideration when crafting a good color scheme is to pick colors that have distinct names, based on your primary audience's language (consider English, in our examples). In Viz Palette, there is a way to ensure that the colors you have chosen can still be distinctly described across your color scheme, even when considering different color vision deficiency filters.

Karen B. Schloss et al, in what I have long considered one of my favorite papers in visualization, Semantic Discriminability for Visual Communication, demonstrated that colors chosen based on semantic similarity to the concepts they represent can improve the discriminability of a graphic.

The names, ideas, and words we use when representing categories based on data is still a largely unexplored frontier in our field. But it should come as no surprise to hear advice based on what we do know already: work to improve your audience's ability to discriminate between the categories you are representing in your visualization.

The advantage of a nameable, distinct color in a scheme arises when a chart or graph is used in a conversation, discussion, or explanation. You don't want everything in your scheme to be a close variation on "dark green" or else you may confuse people. Having "Grey" and "Dark Green" and "Purple" as distinct colors can help people in a conversation.

Going further with this, in order to make your approach more inclusive (since people with CVD may not be able to accurately describe hue differences at times), you must ensure that your alternative, redundant encodings can all be described in a distinct way from one another as well.

For example in the bar chart (previously): There are textures with diagonal lines, a cross hatch, and dots.

In the scatter-plot (next): There are symbols with circles, squares, and triangles.

In the line chart (at the bottom): There are dash patterns that are solid, long-long, and long-short-long.

If every texture in the bar chart was a variation on diagonal lines (some thicker, further apart, etc), it might be hard to meaningfully tell them apart. It would be even harder to consistently describe them in ways that helps others identify the categories you are referring to. Using distinct patterns makes the discussion potential for your charts more inclusive.

Limiting the Number of Categories

Categorical color palettes in data visualization should not have more than 5 colors (this is a fairly well-discussed "rule" of the field). In addition to this, redundant encodings should follow the same rules.

When crafting your own color schemes, think about the distinct nameability of not only your colors, but also whatever else you use to redundantly encode that color. Design for an upper limit between 3 and 5, but ideally stay under 6 total categories. This will help reduce cognitive load for your audience and you may even discover that distinct nameability gets quite hard after 5 categories anyway.

Chart title: Line chart that uses dash patterns along the stroke in conjunction with color

Line charts can be tricky: you could use symbols for the dots and/or dash patterns for the lines, to create categories alongside each color. In this case, I opted for dash patterns (because I prefer them). I find symbols along a line to be too distracting (I lose a bit of the gestalt continuity when symbols are involved).

Executive Summary

December had the Highest Value, January had the Lowest.

Long Description

This is an example line chart, made with the Visa Chart Component Library.

Structure

Statistical Information

Chart trends upwards, almost exponentially.

Chart Layout Description

This is a line-chart with 3 lines containing a total 36 points.

The chart has a horizontal X Axis with a range that starts with Jan and ends with Dec.

The chart has a vertical Y axis with a range that starts with 50 and ends with 400.

Resources, thanks, and further reading

Check out other notebooks in this series on color and contrast in data visualizations:

This notebook uses Visa Chart Components for its examples.

This series is part of a larger collection related to Chartability, supported by our primary sponsor Fizz Studio and my Patreon page.