Data Visualization Accessibility: Where Are We Now, and What’s Next?
Note: throughout this piece I have chosen to echo the language of disability rights activists whose work I follow and use identity-first language (i.e. “disabled people”) rather than person-first language (i.e. “people with disabilities”).
On a dedicated channel, #dvs-topics-in-data-viz, in the Data Visualization Society Slack, our members discuss questions and issues pertinent to the field of data visualization. Discussion topics rotate every two weeks, and while subjects vary, each one challenges our members to think deeply and holistically about questions that affect the field of data visualization. At the end of each discussion, the moderator recaps some of the insights and observations in a post on Nightingale. You can find all of the other discussions here.
What is web accessibility?
When I mention web accessibility to someone who has not heard this term before, they usually think I am talking about physical infrastructure like broadband connectivity in rural areas, or computer labs in public libraries. If the person works in tech, they might realize that I mean digital infrastructure, like internet speed, payload size, mobile friendliness, and compatibility with older browsers. Access, in a broad digital equity and inclusion sense, can encompass all of these things.
Web accessibility is part of digital inclusion. It specifically refers to how browsers, websites, apps, and other digital infrastructure can be used by people with auditory, cognitive, neurological, physical, speech, and visual disabilities. The World Wide Web Consortium’s (W3C) Web Content Accessibility Guidelines (WCAG) are detailed standards that help developers build applications so all users can perceive information and functionality, operate interface controls, understand content, and use the devices of their choice to interact with the application.
If you hadn’t heard the term “web accessibility” before and are feeling daunted by learning about a new topic, never fear! There are so many web accessibility resources out there that I’m not even going to try to cover them all here. I have compiled a few of my favorites in a GitHub repo.
Building to meet WCAG standards is a great start, but depending on compliance to make your application usable for everyone is like relying on a spell checker to tell if you’ve written a good article. Similarly, an automated tool like axe can tell whether you’ve included alt tags for images, but it can’t tell you if they make sense in context. Only usability testing and believing people about their lived experiences will tell you if what you are building makes sense to disabled users.
The standards for accessibility in data vis
The Web Content Accessibility Guidelines are limited in scope and do not explicitly address data visualization, other than using charts as an example of something for which you need to provide a text alternative. W3C’s tutorials recommend a short text alternative and a long description, which in their example is a table.
Even though the standards say so little about this topic, we in the data visualization community often fail to meet this low bar— especially when it comes to dashboards. While charts in the context of reports or articles come wrapped in a long description, business intelligence tools make it frictionless to throw together a few visualizations without any captions or tables. By not considering all users when we create dashboards, which are usually internally-facing, we risk creating workflows that require the use of inaccessible tools and precluding organizations from hiring disabled employees.
While the standards aren’t clear on the implementation details of charts or maps, they do discuss some of the techniques we use to convey meaning with data:
- Color (1.4.1, 1.4.3, 1.4.11): Use colors with a high contrast ratio and consider what additional visual cues (like patterns) could differentiate variables. Automated tools can be helpful to detect color contrast. Consider using a browser extension like Colorblinding to check your work.
- Interaction (2.1, 1.4.13, 2.4.3): Users should be able to do anything with a keyboard that they can do with a mouse. For data vis, that might include a tooltip that shows on hover, or a filter that is triggered by a click. If a user navigates through your data visualization with a keyboard, they should be able to do so in an order that makes sense. Users should be able to exit this interaction and not get stuck in a loop.
- Animation (1.2, 2.2, 2.3): Provide alternatives for time-based media. Do not use flashing images. Users should have control over the timing of animations.
My experience working as a front end developer, and my love of all things d3, tells me we are technically capable of much more than a simple text alternative.
The attempts to go farther
Interactive charts made with scalable vector graphics (SVG) can support features like keyboard navigability and labels for screenreaders. A few individuals (like Léonie Watson) and libraries (like Semiotic and Highcharts) have begun to extrapolate from the standards to experiment with keyboard interaction and aria labels. Members of the W3C community have begun to draft recommendations and standards for SVG accessibility.
Other developers have worked with another mode of perception: sound. Sound offers the possibility for blind or visually impaired users to “instantly identify the trend and general information” of a data visualization. Two great examples are a browser extension by SAS developers that sonifies SAS graphs, and TwoTone.io, which is a sonification platform created by Datavized.
The unknown
Bar charts, pie charts, and line charts are easily re-created in tables that can accompany them as a text alternative. Keyboard navigation, too, can reasonably be extrapolated to follow the same left-to-right or right-to-left order that is presented on the page. It is easy to translate numerical values to frequencies (though slightly more challenging to make decisions about tonality and range!).
Hierarchical and network diagrams break these patterns. In something like a force directed graph, there is often no obvious starting node. Even if there were, what is the correct order of traversal between nodes? How can we build these charts so a blind user can perceive — in the same snap-judgment way as a sighted user looking at a noisy chart — which area of the chart contains the most interest? What is the correct order in which to traverse a hierarchy with a keyboard?
What’s next?
When I co-facilitated a discussion in the Data Visualization Society Slack about web accessibility in 2019, I found that many people were willing to make sure everyone could engage with their work, but were stymied by the lack of official guidance. A set of standards, or at least some publicly shared usability research findings, would help the data visualization community practice digital inclusion, and in turn make communications about elections, the economy, cybersecurity, science (including novel coronaviruses!), education, and anything else humans try to measure more equitable.
COVID-19 has forced more of our lives than ever before online. Now that work, grocery shopping, public education, city council meetings, supreme court oral arguments, funerals, weddings, and birthdays all take place via the internet, I hope we can all finally admit that internet access has become a prerequisite for participating fully and equally in democracy, the economy, and society.
As we increasingly shift from in-person spaces to digital ones, let’s make sure the world we’re creating online is one where everyone has equal access.
