I’m very lucky to have excellent color vision and a laughably mild glasses prescription. However, even as a visualization professional with premium eyeballs, I struggle to read an alarming number of the visualizations that I encounter in the media and online. I find myself squinting, zooming, highlighting and hovering entirely too frequently — all to access the information that someone intended to share in a visual way.
What I’m describing is definitionally an issue of accessibility, and I’m living proof that poor accessibility affects people with great vision as well as those who aren’t so optically endowed.
I have reason to believe that the prevalence of difficult-to-read visualizations stems from one primary source: the prevailing belief that it is too hard, too unappealing or too complicated to bother making visualizations accessible. Thus, because well-meaning authors are uneducated about how to make their work the most legible, they default to designing for aesthetics or speed instead of usability and consider a visualization to be done when they know what it says. The part of the design process where the reader is rigorously and empathetically considered falls to the wayside, largely because the author has no structured way to address problems of accessibility even if they were to be identified.
Ultimately, we have on our hands a prime case of “perfect” standing in the way of very significant “good”. Is it trivial to make a visualization 100% accessible to someone with absolutely no vision? No, of course not. This, however, is a terrible excuse not to make a visualization that is 100% accessible to someone with moderate to great vision — including those with colorblindness—and significantly more accessible to those with less vision than that.
It’s also worth noting that “accessibility” isn’t an obtuse academic phenomenon for other people who are anomalous and irreparably deficient. Someone—like me and perhaps like you—might be able to see perfectly well today, but cataracts, conjunctivitis, allergies, pupil dilation, an accident, laser surgery, forgotten sunglasses, lost glasses or just plain aging could change that. Designing a visualization to barely succeed in ideal circumstances is literally short sighted.
The good news is that the accessibility issues I encounter on a regular basis are fairly easy to solve. You don’t need any special tools or magic powers, and the result will be a visualization that is more easily enjoyed by a wide range of vision levels. And, if you’d like to go even further to include readers with a broader variety of disabilities and sensory experiences, resources like Chartability can point you in the right direction. Yes, you can make your visualizations more accessible.
With that said, I offer you a few simple solutions to some of the most grievous reoccurring concerns that I notice as a high-vision reader.
The first genre of issues I encounter regularly is problems with text. In one way or another the text elements of a visualization are very often hard to read, making the work in its entirety less accessible and frustrating to use.
One of the most common complaints I have about text in visualizations is that it’s barely large enough to qualify as text at all. At a point, small text becomes “fine print” and starts to feel optional or like it was placed under duress. Take a look at the image below and be honest with yourself. Is every row actually pleasant to read?
If something is intended to be read—like axis labels, titles or annotations—it should be in a font size that people (not ants) can read very comfortably. As a simple rule of thumb, if your user needs to magnify the page to easily see the main text then it’s too small. Try starting with 12pt—it’s standard for a reason—and shift up or down by a point or two to make things fit and to draw the appropriate emphasis. You might choose to make text that is important but supplemental to the main message (like a reference or asterisk) of the figure smaller but make no mistake: if it’s hard to read, you should assume it will be skipped or cause some kind of strain for your reader. Keep this in mind while you decide what to include and at which size.
In addition to text being too small, it’s very stylish to use text that is too light or too dark against a similarly light or dark background color. Designers would call this “low contrast” but you can also think of it as “fashionably hard to see”. Alas, beauty is pain—and often impractical.
In general, if a user needs to highlight a row of text to read it then your text is likely too low contrast. If you think to yourself, “Wow! This text is so haute couture that I can barely see it!” then you’ve likely gone a little too far. This contrast checker is a fantastic resource for validating your text color choices, but your intuition is also an excellent tool if you listen to it. Readable text takes priority.
A vertical y-axis title is one thing, but text that is totally upside-down is a bridge too far. This mostly comes up with round graphs like pie charts, chord diagrams, or radar charts, but it can happen even in the best-intentioned infographic or word cloud.
Suffice to say, it’s worth it to spend the extra few minutes orienting your text to be right-side-up, or as horizontal as you can possibly make it. If there are space constraints that absolutely require you to tilt some text, use the slightest tilt that you can and have a hard-stop at 90 degrees. Readers of all visual abilities will appreciate it.
After issues with text, the majority of accessibility problems I come across are related to color usage. Most people associate the words “color” and “accessibility” with colorblindness alone, but that’s just the tip of the iceberg. Accessible color usage comprehensively approaches color in a way that is useful for as many people as possible, colorblind or not.
Fortunately, most color issues in visualization—including problems with colorblind friendliness—can be detected and eliminated with a technique that I call “black and white testing”. It’s simple: print (or imagine that you’re printing) your visualization in black and white. Can you read it? If not, you probably have a color problem to contend with.
The beauty of black and white testing is that it’s a powerful and easy way of ensuring that a visualization does not depend on color alone to communicate information. This ensures that the addition of color is a net positive (or neutral) addition to your visualization instead of a compromise, and that people who perceive color differently than you do still have a way to read your work. What’s more, a visualization that passes black and white testing can safely be viewed in any medium—projector screens, printouts or high-fidelity renderings—regardless of how well your colors are preserved. Black and white testing is simpler and more reliable than using a colorblindness simulator, and it catches issues that a colorblindness simulator won’t.
Perhaps the most common color-related issue I see in visualization is that colorful elements are packed too tightly together with no separation. Just because the elements in your visualization are different colors, it doesn’t mean that they’re easy to distinguish when they’re in close quarters. Overlapping or abutting shapes have a tendency to blur together into a single blob, and there are weird visual artifacts at the intersection of two colors that can be dizzying and unpleasant. If the point is to use color to distinguish elements, squishing them together with no reprieve is contrary to your purpose even if you’re technically able to tell the colors apart. For those who aren’t nimble with colors, squished shapes will leave them even worse off.
The easiest solution to the issue of squished and undifferentiated shapes is to put a thin border around each element, whether it’s a stack in a stacked bar chart or a point in a scatterplot. A black and white test will reveal the improvement that this simple change offers. Instantly, the border will increase the differentiation between elements, and readers will actually be able to see the individual data points you’re displaying. For colorblind users, shapes that would otherwise be indistinguishable will read as separate entities. And, in visualizations that have large areas of color beside each other—like bar charts, pie charts and area charts—even one pixel of separation will provide relief from some of the eye strain and visual effects of directly juxtaposed colors.
Funfetti cake, a lavish garden and summer wardrobes all benefit from an abundance of bold, provocative colors. Unfortunately, it’s not quite the same for data visualization, where color is asked to faithfully communicate information. Unless there is literally no other option — because of the tool you’re using, you ran out of time, your boss is in the circus — try your best to use at most five or six colors in a single visualization. After that, it becomes very difficult to see patterns in the data or scan for a single color.
If you’re not convinced, try a black and white test: you’ll quickly see that using too many colors isn’t robust to people with poor color vision and that your visualization won’t stand up in environments where saturation or richness might be dampened. “But I have twelve categories!” you say, hands wrung. Don’t fret: You have several options.
The first option is to split your visualization into multiple panels so that you can recycle colors or space them out over more real estate. This method is called faceting, and it’s generally a fantastic way to deal with crowded visualizations. Note that this only helps if you also offer your reader clear labels or separate legends so that they can read each panel separately. This might also be a good time to think about tooltips if you’re designing for digital; there are no laws against writing down a value in addition to displaying it abstractly.
The next option is to adjust your palette to use fewer colors and use those as highlights only. For example, you may use shades of gray for the lower priority categories, and then a few brighter, bolder colors to emphasize what’s actually interesting. This technique will reduce the color palette down to something more manageable for everyone to look at and understand. Whether or not you actually combine the other categories is up to you and your data.
The last option is to redesign your visualization such that something other than color bears or shares the responsibility of communicating groups or categories. This lets the reader see each element clearly on its own and saves color for highlighting or pure aesthetics.
In some cases, it won’t make sense to combine categories, facet or redesign your visualization. If that’s the case, you’ll need to make sure that you’re not asking color to do more than it can robustly do by double encoding color with something like shade, shape, pattern, or size. Double (or any multiple) encoding means that the same values are visualized in two or more entirely separate ways at the same time.
Black and white testing is a great sidekick for determining if you need to double encode, and how well the additional encoding(s) perform. For example, a scatterplot that only uses color to show categories will likely perform terribly in black and white, but varying the shape and shade of each point along with the color will make it more robust. Line charts, too, are vulnerable to being overly exigent on color, but a little bit of line texture can offload that demand. Larger areas of color can be double encoded with patterns, even if you only use a light pattern in one element to differentiate two tricky colors.
If you can’t vary the shapes and patterns—which is unfortunately the norm in visualization tools—try to make sure there’s still another way to get to the information in the visual. Tooltips are one way to do that, and offering the tabular version of the data set is another.
With text and color taken care of, the final genre of easy-to-solve accessibility issues involves legends. Remember, the purpose of a legend is to explain the meaning of your visualization’s visual encodings—the things like colors or shapes that represent specific values of data. A legend is not an arbitrary or abstract exhibit of the encodings that you used. To this end, a legend should help the reader expend the least possible effort to understand your visualization.
The easiest way to make a legend useful is to match its orientation and order to whichever elements it is closest. For example, the legend for the colors in a stacked bar chart should be stacked, not horizontal, and fall in the same order as they are seen in the visual. Black and white testing will once again show you where you might have a confusing or fragile legend.
For visualizations where there isn’t a strong order in the graph itself—like a scatterplot—try to sort the legend in an order that is easy for your reader to remember as they peruse the graphic.
In many cases, even the best legend can be eschewed entirely in favor of directly labeling the elements themselves. The usual requirements for readable text still apply, and black and white testing is still useful for ensuring that your visualization is properly encoded and readable. That said, putting the information where it’s needed is a great way to give your readers direct access to what you want them to know. In my experience, direct labels are particularly useful for line charts and pie charts.
The visualization community is due for a recalibration of how we talk about accessibility. Predominantly, we need to talk about it at all, and we need to talk about it in terms that are more constructive than punitive. As a practice, the intention of visualization is to give readers access to information, yet our tendency to avoid or ignore issues of accessibility—out of sheepishness, fear of imperfection or general lack of education—is hurting everyone. We don’t talk about it, so our tools don’t support it, so we don’t do it. The result is an abundance of visualizations that are difficult to read for users with even the best vision and inscrutable for those with less vision than that.
Fortunately, there’s an easy starting point to remedy the conundrum in which we’ve found ourselves. It starts with education on the ways that non-expert authors can easily make their work more accessible, thereby raising the bar of acceptable legibility and turning the collective attention to a topic that tends to feel (ironically) alienating and confusing. In my experience, people are eager to make their work more accessible, but are so frustrated by criteria that they’re unable meet that they don’t try at all. By making accessibility more accessible, we can pragmatically include more readers in our creations and bring a more welcoming focus overall to a subject that affects all of us.