In the most literal sense, accessible visualizations aim to give readers access to the information that is represented visually. Most often, Accessibility concerns come up in reference to colorblindness or blindness. In reality, though, accessibility extends beyond specific permanent disabilities to encompass the full gamut of usability optimizations – for everyone.
It’s useful to remember that disability is not a fixed status occupied by a few individuals. Rather, disability is a spectrum of experiences, both permanent and temporary. You might develop cataracts, for example, or break your arm. A migraine could leave you cowering in a dark room, or a sleepless night could fog your comprehension.
To be blunt, making visualization universally accessible is difficult. Many visualization tools don’t support accessible design, and those that do can be confusing to learn. Even with the best tool imaginable, accessibility skews art over science, and a design that is perfect for one person may be unusable to another.
The guide below is therefore guaranteed to be incomplete. I’ve undoubtedly missed or oversimplified important things. It’s possible that I’ve been clumsily offensive. But, if perfection is out of reach, I hope that this guide at least provides a few attainable ideas of how to be better.
Text, titles, and captions
We can’t talk about accessing information without emphasizing the importance of the textual elements of a visualization. Without text, there are only shapes. So take note, and make sure that the text you employ is purposeful.
The title should tell you what question you can answer with the graphic, but should not necessarily be phrased as questions. For example, "Number of Units Sold by Vendor in 2020" answers the question How many units did each vendor sell last year?
The legend should clearly identify visual mappings and graphical elements, with meaningful landmarks in continuous data called out directly. Try to use the actual words for things instead of the variable names.
Axis labels should be plain-language, horizontal (if possible) and descriptive. For example "Time (2004–2009)" is more useful than "x".
The caption should give context about anything that could affect the interpretation of the graph. Help the reader understand what they are seeing. For example, "These data were collected via web survey administered using the customers’ addresses on file. Read this graph as, ‘Users who spent less time on the app tended to spend less money on extensions and accessories, with a notable outlier who spent $2.4k in under five seconds.’ "
Colorblind friendliness
There are 3 main types of color vision deficiency. Red-green color vision deficiency includes deuteranomaly or deuteranopia which makes green appear more red; and protanomaly or protanopia which makes red appear more green.
Blue-yellow color vision deficiency includes tritanomaly which makes blue appear green, and yellow appear red; and tritanopia which makes blue appear green, purple appear red, and yellow appear pink.
Finally, complete color vision deficiency includes achromatopsia, achromatomaly, or monochromacy. These is quite rare and often accompanied by other visual impairments.
If for whatever reason you are only using color to distinguish between elements in your visualization, there are plenty of simulators available to help you pick colors that are differentiable. I personally use the coolors tool shown in the image above to check my palettes.
There’s sometimes a misunderstanding that you shouldn’t use red or green at all in your visualizations; that doing so immediately disqualifies them from usability. That’s not entirely true, and neglecting two of the most culturally-relevant, high-association colors is unnecessarily severe.
Instead, try making the red slightly orange, and the green slightly blue. To someone with normal color vision, this small change won’t make much difference. To someone who has trouble distinguishing red and green, however, these small tweaks can make greatly improve differentiability.
You can also check that the colors in your palette are distinguishable in black and white. This will come in handy if you need to print a visualization without color, as well as aid users who have low color vision overall.
Luminance contrast
Luminance contrast is the ratio between the luminance (or brightness) of two colors. This ratio affects how well objects can be told apart. Luminance contrast is most often discussed with respect to text and backgrounds, but the same principles apply to graphical elements. You can use the WebAim contrast checker to verify that you’re using sufficiently high-contrast colors.
Miscellaneous design tips and tricks
Even for users who can see, there are a few design tricks that can make graphics even easier on the eyes. One simple technique is to add a thin white border around stacked bars and points. This makes it easier to tell the shapes apart and reduces unintentional visual effects at the intersections.
You can also align the legend so that it matches the structure and order of the visual elements to which it is closest. This ensures that the reader knows exactly which element goes with what value, and minimizes time glancing back and forth.
Using direct labels can be a nice way to avoid using a legend at all. There’s nothing wrong with using a legend per se, but direct labels may make it easier for your reader to associate a visual element with a value. You might opt to use both a legend and direct labels in situations where some visual elements are far away from the legend.
Finally, you can vary the texture lines and shape of points. This acts to offload color as the sole carrier of information. In visualization we call this redundant encoding or double encoding, meaning that the data are represented with multiple visual attributes. I recommend connecting dashed lines with a much lighter version of the same color so that the line remains connected. Similarly, make sure to pick shapes that are noticeably different.
Data Exports
One of the most straightforward tools for making data accessible is a simple data export. An export can allow a screen reader user to scan through the data even if the visual is not screen reader-compatible.
When doing data exports, however, it’s important to remember that you are providing the values from the visualization. That means providing the pre-processed values that one could reasonably deduce from the visual, not the raw, uncleaned, unaggregated data set.
Keyboard navigation and screen readers
There are a variety of reasons that someone might use keyboard navigation. Blind users, for example, or those with motor limitations might prefer using a keyboard to navigate instead of a mouse. Other users might like the efficiency of keyboard navigation. Either way, this is all possible thanks to the HTML structure of a webpage that indicates the type of content selected and where it is on the page.
When you’re making visualizations for the web, make sure to use a standard HTML structure with keyboard-friendly landmarks. You can read more about how to do that on the WebAIM site, here.
Screen readers take the information that is embedded into the HTML of the webpage and read it aloud. With respect to visualization, this will come up most often with the text elements we covered above. Unfortunately, not all visualization tools and platforms work well with screen readers; this page, for example, doesn’t support interactive media. In cases like this, you’ll want to use alt-text to describe a static visualization.
<button aria-label= "publish article">Publish</button>
<img src="graph.png" alt="Bar chart of ice cream preferences by nationality. 70% of Americans preferred sourdough ice cream.">
Data sonification
Moving into the newer frontiers of accessible visualization, there’s some fascinating work happening in the sphere of data sonification. The charting library HighCharts is a forerunner in this space. __ Like it sounds, sonification maps data to sounds instead of visual elements. Listening to a visualization can tell the user about trends and outliers. Perhaps imprecise as a standalone tool, sonification is a nice addition to a screen reader experience. It’s fun, too!
Data physicalization
And finally, data physicalization is the practice of representing data with physical media. That means texture, temperature, weight and size are all available as tactile encodings in addition to visual attributes like color. This is an area that is still undergoing research but is as old as piles of rocks. There’s a wiki dedicated to data physicalization that you can find here.
There’s no way around it: making Data Visualization accessible takes extra work. There are tool constraints, knowledge constraints, and individual preferences to boot. But, that doesn’t mean that we can’t all be a little bit better about making visualizations that are easier to access. To fill in the gaps of what I may have missed above, I’m including a few articles by other folks in the community. Feel free to share other resources in the comments as well!
Data Visualization Accessibility: Where Are We Now, and What’s Next?