The technology landscape has shifted from the time of that proposal, particularly in Web technology. There has been a shift away from domain-specific XML formats toward markup attribute-based semantics decoration of HTML and SVG, such as author-defined Dataset attributes or the Accessible Rich Internet Applications (WAI-ARIA) attributes, enhanced by script-based interaction.
Scalable Vector Graphics (SVG) has emerged as the graphics format of choice for data visualizations on the Web, and its markup metadata capabilities make it suitable as the source for other non-visual representations, including haptics and sonification. The native capabilities of the Web have also increased, introducing APIs both for haptics (the Vibration API) and sonification (the Web Audio API).
These increased capabilities, as well as pressure from regulation, have led to a recent proliferation of accessible data visualizations in several major software packages. There is rapid iteration in the commercial and open-source product side of accessibility for charts, with many different approaches. In the coming years, this may culminate in shared common practices, and even in a universal standard for interaction and the interpretation of data visualizations within a standards body like W3C.
In addition, there is activity among W3C’s participants that may lead to more detailed guidelines for data visualizations, as distinct from the generic “complex image” guidelines, within the W3C Web Content Accessibility Guidelines (WCAG), which serve as the basis for regulation and legislation such as the US Section 508 directive. This has the potential to become a virtual cycle, where innovation in the market leads to standardization, which leads to widespread legal requirements, which in turn rewards technical and user experience innovation, all benefiting not just people with disabilities, but all consumers of data visualizations.
The DIAGRAM Center has fostered this progress in accessible data visualizations in three ways: by convening leading accessible charting developers, projects, and companies in discussions toward standards; by fostering community collarboration and development in our code sprints; and by disseminating this information to educators, parents, publishers, and software professionals through our reports, code repositories, and other publications. One recent success story from our code sprints was the creation of a new open-source software project called SparkBraille, which enables the easy creation of interactive tactile line and bar charts through a common refreshable braille display, right from the Web, with no special hardware or software required; this project was started and completed from scratch in the 3 days of our 2020 code sprint, and the developers continued to refine it after the event.
It is clear that the nature of digital accessibility of charts lies in the future of Web technology, Web standards, and Web applications. While not all the details are yet obvious, the renewed emphasis on digital content being “born accessible” has shifted, and will continue to shift, the market for data visualizations.
If you’re using SVG for more than just icons, such as structured content like a chart or diagram, especially an interactive one, then you need to take a few extra steps to make it accessible. But making an SVG accessible has been a bit of a moving target over the years, usually getting better, but sometimes getting temporarily obscured, because of changes in browser and screen reader support. We’ve specced out most of this behavior, but it doesn’t mean we caught everything, or that it’s implemented consistently or correctly across all screen readers or browsers. And some methods that worked (a bit accidentally) were unintuitive or caused validation errors.
What we want for accessibility are clear, consistent methods for making SVG accessible, that are both reliable and valid across the whole toolchain, from authoring tools to validators and checkers to browsers to screen readers.
I’m happy to report that now the mechanics of SVG accessibility have never been better. It’s more predictable, more consistent, more interoperable, more standards-conformant, and easier than ever before to make SVG elements accessible to a screen reader.
For each focusable or interactive SVG element, add a tabindex attribute, a role attribute, and an accessible name (via an aria-label attribute or a <title> element).
Don’t add a tabindex attribute without an accessible name
Don’t add a tabindex attribute to the SVG root unless you need to
Avoid the title attribute (not to be confused with the <title> element)
The long version, in which we figure out some things that don’t work, some things that used to be necessary but are no longer needed, and just how strangely screen readers can act
I was helping John Gardner from ViewPlus with a new prototype for a simpler interface to load, insert, modify, and save SVG files in an HTML file, in an accessible way. As an incidental part of this, I made a few rough SVG example files that could be loaded and modified; I didn’t pay much attention to the sample SVG files, and just reused some simple SVG accessibility techniques that had mostly worked (and been necessary) at one time. I tested it in VoiceOver on my Mac and it worked fine.
By “worked”, I mean I could use the keyboard to navigate from the HTML form controls to the inline SVG (that is, an SVG file that’s been embedded directly into the HTML code), move to each of the “activatable” shape elements (the ones that had event listeners on them, along with tabindex attributes), hear the title of that element, activate one or more of them with the space or enter keys (which added a stroke to the shape), and navigate back out to the HTML controls to save the modified files. The SVG files were not the relevant part of the prototype; they were just stand-ins for the kind of files users would be loading. They wouldn’t affect the prototype, right? Wrong.
When I was demoing it with John, who uses NVDA and JAWS, he couldn’t navigate to the SVG elements. I could hear his screen reader through the phone. It kept cycling back to the last form element, a button, and repeating the name of that button. Sometimes it would get stuck, and he couldn’t navigate back to the previous form elements. He wasn’t sharing his screen, so I had no idea what was going on, and neither did he. Once in a while, he’d stumble on one of the target elements, but he couldn’t activate it.
Time to step back and debug this very odd behavior.
Kevin messaged me, and I sent him the sample app. A couple minutes later, I got a phone call. He needed to know what the expected behavior was. I walked him through it, and could hear similar problems as those John had. But with a critical difference: Kevin could see that the focus was shifting to the SVG elements, but it was still saying the accessible name from the HTML form control! And he couldn’t activate the elements! What fiendish torture was this? Had the browsers and Windows screen readers reverted to broken SVG behavior? What had 2020 done?!
For a moment, I felt despair. SVG and accessibility are two of my favorite technologies! They should work well together. They had to! I’d helped write the SVG accessiblity specs, for crying out loud! If I was struggling with this, then lots of other people had to be struggling, too. With Kevin patiently agreeing to be my remote eyes and ears and screen reader operator, I went back to basics and started testing combinations of SVG accessibility features. A furious set of permutations of tabindex, <title>, title, aria-labelledby, aria-label, and role followed, with Kevin and I both hacking the source code over a couple of hours. Herein I’ll recount our most salient findings, with 3 problems and 4 best practices.
Context: SVG elements need a tabindex attribute to receive focus
In HTML, most content is wholly or partly text. You usually don’t need to do anything special to make sure the screen reader reads that text out, though you do need judicious use of tabindex on custom controls. By contrast, most SVG content is shapes, which are not keyboard focusable by default. The only elements that are focusable by default are links. If you want a shape element to be interactive or navigable, you need a tabindex attribute with a value of "0". (Historically, SVG used to have a different boolean attribute for making an element focusable, mysteriously called focusable, but we deprecated it for integration into HTML in favor of the legacy HTML tabindex. Alas, you should not use focusable, even if it seems more logical.)
Every focusable element also needs an accessible name, which you can add with the native <title> as a child of the shape element, or with an aria-label attribute.
It’s also worth noting that the alt attribute doesn’t work with inline or standalone SVG elements, not even with the <image> element (the SVG analog to the HTML <img> element). You need to use an aria-label attribute or <title> element to add an accessible name. You can (and should) use the alt attribute for SVG files included in HTML via the <img> element, of course.
Problem 1: tabindex on the SVG root
This was a case of overengineering. Last year, I found a bug in some Windows screen reader / browser combos that you couldn’t navigate to an SVG shape element, even one with a tabindex attribute, unless you also had a tabindex="0" on its <svg> root element. It was like there was a windowless wall, and the root tabindex was the key to the door that let the screen reader inside the room. An annoying bug, but easy to work around. But it turns out, this is no longer necessary in any screen reader and browser combination we tried (VoiceOver / NVDA / JAWS and Firefox / Safari / Chrome). It just adds an unnecessary and possibly disorienting step. Don’t do this anymore, if you ever did.
This might not have been so bad in isolation, but it was devastating in combination with…
Problem 2: no accessible name on the SVG root
An “accessible name” for an element is the text the screen reader reads out when it’s presenting that element to the end user. This the text of the heading or button, or the alt-text of the image. (This is also the text label that someone using voice control uses to active a UI widget.) Without a text description, most SVG elements don’t have an accessible name.
Normally, I always add a top-level <title> element to my SVG files. I skipped it for these throwaway sample files, and I’m glad I did. Because that gave me the chance to discover that not only was the root tabindex unnecessary, but it also revealed some truly weird screen reader behavior. When NVDA or JAWS encounter an SVG element with tabindex="0" and no accessible name, they get confused. Very, very confused. They start repeating the last accessible name they remember (in this case, the HTML form control). Even when they encounter a subsequent focusable SVG shape element with an accessible name, they just can’t get over the trauma of the missing accessible name, and endlessly repeat the last good accessible name they spoke, for any SVG element afterward, whether navigating forward or backwards in DOM order.
And here’s where it gets truly odd. This actually seems to affect the navigation behavior, at least in JAWS. You can no longer reliably navigate back out of the SVG root. (Disclaimer: I didn’t see this for myself, I only heard it, and we were testing behavior fast. It might be that the navigation itself wasn’t affected, but only what was read out. Either way, tricky behavior you want to avoid.)
I’m assuming this is some sort of missing stack reference issue in the screen readers. Don’t fall prey to this one, because it will screw up all your SVG navigation. If you add a tabindex attribute to any SVG element, make sure you give it an accessible name, too.
Problem 3: missing role attribute
A little tinkering revealed the problem. I hadn’t added a role attribute to the SVG shape elements. Again, this turned out to be a happy accident (normally, I do add a role and often a aria-roledescription), since it illustrated the necessity of using it.
The role attribute is a feature of of the ARIA specification, which adds or changes the semantics of the element it’s used on. With a role, you can tell screen readers that a <div> is actually a button, for example, and that it should have the same behaviors as a button, such as being focusable and activatable.
Without a role attribute on the SVG shape element, in this case with the value “button”, JAWS would not activate the element, even though it had an event listener on it.
I will be honest: I’m not sure if this is the correct behavior per the specs or not. Either way, I personally think it’s the wrong behavior. This isn’t required for VoiceOver or for NVDA, and I think JAWS should change its behavior here. Consistency between user agents is incredibly important. But this is a pretty easy workaround, and a role is typically useful and adds semantics, so to make sure your interactive SVG elements are activatable, add a role attribute.
As an aside, Kevin pointed out that a few years ago, the way to make SVGs consistently read by screen readers was to follow Léonie’s advice from the article below, which includes using role="img" on the SVG root. Some people leveraged this by removing the role for SVG icons they wanted to be ignored. Even if a <title> were available, if role="img" were not present, the title would not be read. Recently, however, at least some screen readers have changed this behavior, so this hide-the-SVG hack no longer works. Avoid it. Either provide a meaningful accessible name to make it visible to screen readers, or leave off the accessible name to hide it.
I haven’t yet tested if you need to add specific roles (like "button") to make the element activatable, so proceed with caution.
Having solved all the major problems, we next turned to some quick best practices, to distill the minimum of what is necessary, and what is unneeded.
Best Practice 1: no aria-labelledby attribute required
In Léonie Watson’s excellent 2014 article Tips for Creating Accessible SVG, she describes a belt-and-bracers technique that was often necessary at the time. Some screen readers would not recognize the content of the the native SVG <title> element (again, not to be confused with the title attribute inherited from HTML) as the accessible name. To overcome this, Léonie wisely recommended that you use the aria-labelledby attribute to point to the child title, like so:
<path aria-labelledby="button_1" d="…">
<title id="button_1">Shiny red button</title></path>
This is effective, but frankly, tedious and verbose to maintain. And luckily, no longer necessary! We found no difference in screen reader / browser behavior between that and the simpler form:
<title>Shiny red button</title>
It won’t hurt to continue using the belt-and-bracers technique, but in 2020, it’s doesn’t seem necessary. In fact, pointing aria-labelledby at the <title> element may simply not have any effect. When Frank did some later validation testing for me (more on that below), he found a typo in one of my aria-labelledby attribute values, so it didn’t point to an existing id. It didn’t make a difference in the accessible name generation for that element.
However, it may be better not to use the <title> element at all. Like the HTML title attribute, modern browsers treat the content of the <title> element as a tooltip, popping up a little infobox after a short delay when you hover over the element. This is often not desirable, and inconsistent since it doesn’t really work on mobiles.
Best Practice 2: use aria-label attribute instead of <title> element
When do you not want the tooltip provided by the <title> element? When you’re providing more complex custom tooltips, especially ones that show immediately rather than requiring a delay. When you don’t want the title of the parent element to be shown for a child element without a <title> element. When it causes visual clutter or distraction on the “empty” space of a chart (imagine having the HTML’s <title> content pop up every time you rest your cursor on the page background).
SVG 1.0 had some great aspirational accessibility features, including text that’s actually text (not just an image of text), and the <title> the <desc> (description) elements. Having <title> as an element, rather than as an attribute, provides a number of advantages, including structured markup content and providing multiple alternative-language versions. These features, their motivations, and some speculations are documented in the W3C Accessibility Features of SVG note by Chaals McCathieNevile (@chaals) and Marja-Riitta Koivunen. But when we conflated <title> with a tooltip, which seemed logical at the time, we muddied the waters. I think this is a decision that should be revisited, and that <title> popups should be removed from browsers, possibly replaced with a hint semantic that works better with keyboards, touchscreens, and assistive technology.
In our tests of screen reader and browser behavior, the title attribute on an SVG element acted no differently than the aria-label attribute. Unlike in HTML, the title attribute in SVG doesn’t even produce a popup (while the <title> element does). The title attribute worked perfectly well in all screen readers to generate an accessible name. For better or worse, we don’t have the same complaints in SVG against the title attribute as described in Scott’s article.
However, in Frank’s validation testing, the title attribute was flagged as invalid in the W3C Validator. For the record, I don’t think that’s correct. I see this as more of an oversight in standards or a mistake in the Validator than as a problem with the SVG file. The title attribute, being a global attribute in HTML, should be allowed on any SVG element, too. That said, I still recommend against using it. If it were the only thing that worked, to be blunt, I’d use it whether it validated or not, but luckily, it’s not the only thing that works. The behavior is inconsistent with HTML, it’s unnecessary since it’s no better than using the aria-label attribute, and most importantly, it fails validation rightly or wrongly. Validation errors are a red flag that will be thrown in any accessibility testing or audit, and it will cause hassles without providing value.
In short, don’t use the title attribute in SVG (except perhaps on links which don’t have text content, and even there, you should probably use another accessible name mechanism).
Best Practice 4: validate and test
After Kevin and I wrapped up debugging the problem two or three hours later, I checked my email and saw that both Léonie and Jason had also had similar experiences and come to similar conclusions. Some simple errors in my SVG files caused utter chaos in screen readers, easily corrected but a hassle for screen reader users (and SVG authors like yours truly).
Afterwards, I had a conversation with Frank, who’s done a lot of SVG accessibility testing, too. Both while working at Visa and outside of work, Frank needs to make certain he is following all the regulations and providing an accessible experience, so he has a rigorous testing regime, including using the W3C Validator, aXe, and the Accessibility Insights extension for Chrome. Visa also has open-sourced their accessibility requirements for the community to learn from their tests, procedures, and recommended tools. I’m not specifically endorsing any of these tools; there are loads of other great accessibility tools out there, including Compliance Sheriff and Tenon to name just a couple, but find the tools that work best for your workflow, and use them.
Frank generously validated my code, both in situ (the injected inline SVG) and as the raw SVG files. He found the errors mentioned before (the typo in the aria-labelledby value and the validity errors for the title attribute on SVG elements), and wrote me a concise report via email. His testing came after we’d already solved the problem. I can’t say for certain that it would have pointed me to the solution that Kevin and I arrived at (and which Léonie and Jason verified), but it would definitely have pointed out some of my errors.
Now it’s your turn!
And that’s the kicker. We suffered so you don’t have to. I got lazy, and it caused me stress and lost time, even if I talked with and met some great people through it. If I’d tested myself in NVDA and JAWS, as well as using validation and checking tools, I may not have introduced these problems in the first place. Because I built accessibility in my code from the start (even if it wasn’t perfect), it only took me a short time to recover from the problems we’d found; it would have taken much more time to fix retroactively if I’d been further on.
Please learn from my mistakes. Follow these simple up-to-date SVG accessibility best practices, avoid the nasty problems, don’t get lazy, and test and validate with accessibility tools and real-world screen readers and browsers. SVG accessibility can be easy!
Once again, I want to profoundly thank Kevin Ackley, Léonie Watson, Jason White, and Frank Elavsky for their generosity, friendliness, and technical expertise in helping me diagnose and solve these issues. Without them, it would have been much more frustrating and much less fun.
Charts, graphs, and other data visualizations are an increasingly common way to convey complex information quickly to your audience. They’re eye-catching, helpful to your users, and they generate lots of traffic to your site.
And they’re inaccessible.
They don’t have to be, but almost all data visualizations are hiding crucial information away from your users with visual impairments. You can fix that, and I’m writing this post to help you along.
My name is Doug Schepers. I worked for the World Wide Web Consortium (W3C), the web standards organization, for a decade writing technical specifications and running working groups. I saw first-hand the disconnect between standards and real-world implementations, and the pain that caused developers and their users. I started W3C’s developer relations activity, before leaving W3C to form a startup doing accessible data visualizations.
One of the projects I worked on at W3C was graphics accessibility, specifically SVG accessibility. I first realized how you could make accessible charts in 2009, and after trying to get something standardized for years, I spoke about it at OpenVis Conf and CSUN in 2013. That got a lot of people excited, and we formed a task force to lay the groundwork, building on ARIA. Standards are slow, but in 2018, W3C published the WAI-ARIA Graphics Module, mostly due to the efforts of Amelia Bellamy-Royds, a dedicated and brilliant SVG expert. Even if you know about ARIA, you probably haven’t heard of the WAI-ARIA Graphics Module, unless you’re especially geeky.
In fact, you might have heard of ARIA, but might not know much about it. Welcome to the club. ARIA is very useful, but widely misunderstood and misused, and it lacks great documentation. In future blog posts, we hope to help clear up ARIA for you, and make using it painless (well, mostly painless, once the numbness sets in).
At this point, you might be wondering why I’m talking about opera singing. That’s not the kind of aria we usually mean in accessibility circles. ARIA stands for Accessible Rich Internet Applications. It’s a web standard from W3C’s Web Accessibility Initiative (WAI). You’ll sometimes see it called WAI-ARIA.
ARIA is essentially a set of extensions to HTML that help make your web content and controls more usable to people with disabilities. ARIA defines attributes that apply additional semantics and behavior to elements.
The 'role' attribute defines the element’s assigned type of user interface component (e.g. a checkbox)
The various property attributes describe that component’s individual characteristics of (e.g. whether it’s required)
The different state attributes define that component’s current mode (e.g. if it’s checked or unchecked)
ARIA for graphics
So, what does this have to do with charts? Especially a static, non-interactive chart?
Some of those ARIA roles defines significant parts of a document, called landmarks. Landmarks are things like headers, footers, sidebars, navigation, and so on. People using a screen reader often move around these landmarks to build up a complete picture of a document or application, one component at a time.
A chart is just a special kind of document, and it has its own structure and landmarks. For a bar chart, that’s the title, the x-axis and y-axis, and each bar.
'graphics-document': a document that conveys its meaning through its visual appearance
'graphics-object': a section of a graphics-document that represents a distinct object or sub-component with semantic meaning. A graphical object may itself have nested sub-components
'graphics-symbol': a graphical object treated as a single image component, used to convey a simple meaning or category
Let’s drill into each of these a bit more.
This is the parent node of all other ARIA graphics elements. In the case of a bar chart, this is the bar chart itself.
Don’t confuse this with the root node of the document, like the <svg> element (though it might also be that). Each chart should have a single ‘graphics-document’ root, though one document might contain multiple 'graphics-document' elements, such as a dashboard file with several different charts in it.
This is an element that contains other parts. It’s a generic structural container element, like an <article> or <section> element in HTML.
This can be used for the x and y axis, for example. They are well-defined areas of the document, which contain other sub-components, like tick marks and scale labels. For this case, the best analogy might be the <thead> element in HTML: a table header, which contains one or more rows each with more or <th> (table header) elements.
This is an atomic bit of code, usually some mark, icon, shape, or line in a chart, which represents the data point value. In a bar chart, each bar would have a role=’graphics-symbol’ attribute, as would each slice in a pie or donut chart, each line in a line chart, each dot or symbol in a scatterplot.
This doesn’t mean that the data point representation has to be simple, or a single element. If you have a pseudo-3D bar chart, each bar might have elements for the front, top, sides, and shadow, but it should all be encapsulated in a single group (in SVG, a <g> element) with the 'graphics-symbol' role.
And that’s it! If you mark up an SVG chart with these three ARIA roles, it suddenly becomes accessible!
Just kidding, that’s just the beginning. By themselves, these roles don’t have any properties or states; in other words, they don’t have any inherent behavior. But what they do is to identify each part to the screen reader, so it knows how to categorize and characterize them to the end user.
Exposing elements to the user
Once you have the parts of the chart document marked up, it’s getting more accessible. I say “more accessible”, but that’s not true yet, because they are still invisible to screen readers. By default, most SVG elements are hidden from screen readers, the exceptions being links and textual elements. You can make them keyboard-navigable by adding tabindex='0' to each component.
What’s the best way to add value for a screen reader user? By literally adding the value of the data point to its representing element. If you have an element that draws a bar, with the height showing the value, then you simply include that value as text as well; think of it as really tiny alt-text. In SVG, there are four ways to do that: with a <text> element; with a <title> element; with an 'aria-label' attribute; or with an 'aria-labelledby' attribute pointing to an element that holds the value (such as a <text> or <title> element).
The <text> element (and its optional child element, the <tspan>) is how you render text to the screen in SVG. Like in HTML, this text can be selected, copied, and searched for. This is ideal if you want the value to always be shown, as a label on a bar or pie slice. To associate it with the data point element, group it in the same <g> element, or give it an 'id' attribute and point to it with the 'aria-labelledby' attribute.
The <title> element in SVG is like the ‘title’ attribute in HTML. It’s a hidden metadata value that only appears on hover (note that it doesn’t appear on focus, so it’s not as accessible as it should be). You can use this if you only want the value to be shown on hover. To associate it with the data point element, put the <title> as a child of the data point element or its parent <g> element, or give it an 'id’ attribute and point to it with the 'aria-labelledby' attribute. (Note that for legacy browser support, it might be best to use both of those techniques.)
This is pretty straightforward. Just put the value in the 'aria-label' attribute, like this:
<rect aria-label="4" … />
This is a tad more complicated, but there are reasons you might want to have this level of indirection, such as when you’re pointing to a value that appears elsewhere and don’t want to duplicate it. You give the referred element an ‘id’ attribute value, and use that as the value for the ‘aria-labelledby’ attribute, like so:
Any one of these techniques will cause the screen reader to read out the value. Voila! Now, the chart is well on its way to being about as accessible as a table. The user can use a keyboard to get to each component, and step through each bar in turn to hear the values.
These are the bare essentials for making an accessible SVG chart. It’s worth noting that that the WAI-ARIA Graphics Module isn’t SVG-specific; you could do the same with HTML+CSS charts. But SVG is the markup of choice for charts these days.
Once more, with meaning
Okay, so now the user can get at each data point, and get its value. Just like in a data table. But a chart isn’t a data table, and not each data point is the same. When a blind or low-vision person is talking to a fully-sighted person about a chart, they should be able to use the same terms to avoid confusion. They should know it’s a bar in a bar chart, a slice in a pie chart, a line in a line chart. They should know it’s the y-axis or the x-axis or the legend. They should know what kind of chart it is.
ARIA doesn’t have specific roles for different kinds of data points, or parts of a chart, or chart types. But what it does have, starting in ARIA 1.1 (finalized in December 2017), is the 'aria-roledescription' attribute.This attribute lets you provide a natural-language equivalent for an ARIA role.
As an example, the following element would be read by a screen reader as something like, “bar element”, instead of “graphics-symbol element”:
In SVG, this is a <rect> element, which draws a rectangle on the screen. But to a screen reader, it’s now a bar element, and that’s how it’s communicated to the user. With 'aria-roledescription', you can call a shovel a shovel.
Does this work in browsers and screen readers?
Standards are one thing, and implementations in “user agents” (browsers and screen readers) is another story. Fortunately, these features have pretty good support. That raises the question, what does “support” look like in the case of ARIA, and for these features specifically? Especially when they don’t have any defined behavior?
To answer that, we need to step back and look at how Assistive Technology (AT) like a screen reader works. In short, the browser downloads the document file, then creates a DOM (Document Object Model) tree, and visually renders the result of that DOM tree; that’s all commonly understood by web developers. But less commonly known is that from the DOM tree, the browser also creates an accessibility tree (also called the accessibility object model, or AOM), which is a subset of the DOM tree that is specifically relevant to AT. The browser then exposes that accessibility tree to its analog in the operating system, the platform-specific Accessibility API (each unique to that OS). The OS Accessibility API in turn shares that information with the AT, such as a screen reader, which is finally rendered (as speech, Braille, or some other form) to the end user.
So, this means that the question of user agent support becomes, “Does the browser translate this element correctly to its analog in the platform Accessibility API? And does the screen reader recognize and announce that role?” That’s something testable.
This translation is detailed in the Graphics Accessibility API Mappings, a companion spec to the WAI-ARIA Graphics Module. And that specification has a test suite, which tells us how well it’s supported. At the time of publication in October 2018, all browsers on all OSes supported these features, with the exception of the 'aria-roledescription' attribute in Chrome on MacOS. Since then, my testing shows that that also seems to have been implemented.
I have noticed glitches in browser and screen reader support. This is true of ARIA support in general. There is a legitimate question on how we best serve our readers: Do we take a conservative approach, and only publish content that is rock-solid? Or do we recognize that if we don’t create valid content that pushes those boundaries, browser and AT vendors don’t have enough incentive to improve their support? That’s a decision that each publisher needs to make. For my part, I favor the latter, to counter the chicken-or-egg debate. No progress happens without active effort.
When I tell people I make data visualizations for blind people, the response is almost inevitably a quick pause while the gears of their mind start spinning wildly, then “How does that work?”
I’m not going to tell you how I do it. (At least, not in this article.) But I will tell you how I think about it, and suggest how you can too. Many people love data visualization because it makes data and other complex information accessible. But there are many people for whom data viz doesn’t make things accessible, and it’s not because they don’t understand data.
For example, data viz has played a critical role in educating people about COVID-19. But have you wondered how blind people are getting detailed information about the pandemic, given that so much of it is in chart or infographic form? The answer, for the most part, is that people with visual impairments are simply not afforded access to that critical data. To understand how we can—and must—change that, we first need to understand assistive technology.
Assistive Technology, or AT, is pretty much what it sounds like: technology that helps people overcome a constraint in how they interact with the world. In the case of people with a visual disability, that often means using a screen reader. A screen reader is software that literally reads text from the screen, a bit like an interactive audio book where the user can change the pace, skip passages, find text, or jump to sections or links they’re interested in. It also describes the structure of the text, like headings or tables or lists. But the caveat is that it only reads text, so if there’s something on the screen that’s not text, it’s hidden from them. Some non-text things have built-in descriptions, like form fields or buttons or links, which are announced along with their text labels. So images need text descriptions, called alt text, and complex images like charts need effective text descriptions to be useful to a screen reader.
Or course, visual disabilities aren’t the only ones to consider, but for a primarily visual medium like data visualization, blindness is the obvious design constraint. Not everyone who has a visual disability uses a screen reader, and not everyone who uses a screen reader has a visual disability. And fortunately, text (which includes numbers) is a remarkably robust and transformable container for meaning, and works well with many types of AT. So providing a text equivalent is usually a great starting point.
The dirty little secret of accessibility is that there’s no single correct way to make your content accessible, and no one-size-fits-all solution … and this also applies to make your charts, graphs, and diagrams accessible. You need to consider your audience, and what you’re trying to convey, and decide how you want to convey the information to them.
The good news is that this is business as usual for someone skilled in data visualization. You don’t just take every dataset and render it as a bar chart, and call it a day. You think about the message you’re trying to send, and you pick the correct chart type, the right subset of the data, the correct framing, the clearest symbols, and the pithiest prose to craft your message. You adapt, remix, and innovate.
What I do, and what I’m asking you to do, is to bring the same craft of data design to accessibility as you do to visual representation. True accessibility means telling your data story to everyone.
When I work on making an accessible dataviz, here are some principles I focus on.
Value your reader’s time and attention
Use alt text to provide a one-sentence summary of the chart. One of the benefits of a dataviz is that it can convey a complex idea with a small investment of effort on behalf of the reader. If the fastest, best way to provide information were to use a data table, then you wouldn’t have used a chart. Please don’t make your readers walk through each cell of a table to get the gist of what you’re saying.
There’s enormous cognitive load in consuming large amounts of data. If at all possible, provide a textual summary of the chart in alt text, so the reader can decide if they want to drill in. Make it about the length of a text message, no longer. Write them a poem, not a novel.
Give all your reader access to all the data
While you don’t want to force users to slog through a data table, you don’t want to hide information from them. They may want to verify your conclusions, or might want to look at some relationship you don’t mention in your summary; for example, your article might specifically be about the COVID-19 infection rates in New York compared to other states, but they want to look at the numbers for their own state. If you’re showing it to some of your audience, don’t hide it from others.
A great way to do this is to include an alternative data table (often visually hidden but available to a screen reader) or a link to a CSV file that they can download and read in the app of their choice. As a side note, providing access to the raw data is generally a best practice so everyone can benefit from it.
Design equivalent experiences for all your readers
Even though blindness is an obvious constraint in data viz, it’s not the only disability to consider. We need to provide affordances for all of our users, on all of their devices. In general, don’t rely on only a single way to convey an idea. Add redundant representations for critical messages. Here are a few examples.
If you’re using color, think of how you can convey the same distinctions to people with colorblindness. Do you change the thickness of a line, or use patterns as well as color, or limit your palette to eliminate possible confusion? These are decisions you need to make on a case-by-case basis.
If you’re using metaphors and symbols, consider how people with cognitive disabilities will interpret your information.
If you’re using sound, such as sonification or spoken aspects, think of the deaf.
Don’t rely on a single signal for your most important message. Repetition is the key to mastery, and the easiest way to ensure that you’ve made your point.
Data Visualization IS Assistive Technology
You might be thinking that this isn’t relevant to what you do. Your talent is in representing complex ideas visually, and isn’t that incompatible with accessibility? The simple fact is that data visualization is assistive technology. It’s cognitive assistive technology. Our amped-up monkey brains aren’t good at seeing patterns in numbers, but they’re great at discerning patterns in topological space. So we map numbers to colors, location, size, and other visual symbols, and suddenly we can understand trends and relationships.
As an illustration, here’s the same data as a spreadsheet and as a line chart. Which one more clearly shows the fastest rate of population growth?
It just so happens that this visual mapping doesn’t work for people who can’t see. So, think of different mappings to make those trends and relationships explicit to people who need it, as another constraint in your user-centered design process.
If I could, I’d just hand you a set of instructions, and say, “Follow these steps, and your data visualizations will be accessible!”
But that list of instructions doesn’t exist. You are going to help write it.
There are numerous mechanical techniques that you can use, from structured markup to color-contrast checkers. And there are different media you can apply, from text to sonification to animation to tactile feedback. There are general authoring principles in the W3C’s Web Content Accessibility Guidelines (WCAG), though precious little specifically about dataviz, and there are good articles you can read on applying those standards to data visualizations. And there are legal reasons to make sure you check those boxes. These are tools, but they aren’t the solution.
You can follow all the rules, and still make data visualizations that aren’t accessible and that don’t inform your reader. As a craftsperson your goal should not be the worst content you can get away with, it should be the best experience you can build.
Don’t look at this as a requirement, an obligation, another checkbox to tick off. Look at accessibility as an opportunity to hone your skills, to move beyond the ordinary, and to provide an intentional experience for your users.
Some of the most effective, emotive, and affecting data visualizations I’ve experienced have blended two or more sensory techniques together to make a rich data representation that stays with me, that motivates me, that means something to me. That’s a high bar to aim for, but even if your experiment doesn’t reach that mark, you’ll be providing a better experience for a larger audience. Don’t be afraid to innovate.
We are at just the beginning of accessible data visualization. Join the conversation with me and others in the Data Visualization Society, and let’s aim for that high bar together.
About the author: Doug Schepers (@shepazu) is the founder and director of Fizz Studio, an accessible data visualization startup in Chapel Hill, NC, USA. Fizz Studio creates hand-crafted accessible diagrams and a next-generation accessible charting platform. Prior to founding Fizz Studio, Doug was a project manager at W3C, where he developed standards and prototypes and launched the developer relations program. He believes in positive social change through building communities and interoperable open technology.
How to create Accessible Single-Page Applications? Vue-Announcer announces useful information for screen reader users. Learn how to use this plugin to customize receive alerts and notifications as users navigate your application.
Maria Lamardo is a Front End Engineer at Pendo, who works with Vue.js and has a particular passion for web accessibility. She is a very active community organizer in the RTP area of North Carolina and beyond, serving as the founder of Devs@RTP, the Worldwide Event Manager and NC Chapter leader for Vue Vixens, and the Co-Founder of A11y Devs.
Are you curious to learn how Virtual and Augmented Reality (XR) technologies can be made accessible? This presentation will cover the findings of the recent W3C Workshop on applying Inclusive Design to the development of XR standards for the Web. The presentation will be full of examples and lessons learned from the conference.
What are XR Accessibility User Needs
Key principles of making XR experiences accessible
Lessons from existing Accessible XR products & prototypes
Conclusions from the W3C XR workshop
Thomas Logan has spent the past seventeen years assisting organizations to create technology solutions that work for people with disabilities. Over his career, Thomas has delivered projects for numerous federal, state and local government agencies as well as private sector organizations from startups to Fortune 500s. He is the owner of Equal Entry, whose mission is: “contributing to a more accessible world.” He is also co-organizer of Accessibility New York – a monthly Meetup for people interested in topics related to accessibility and people with disabilities. Thomas lives in Tokyo, Japan.
When: Thursday, January 16, 2020 at 6pm Where: Pendo, 150 Fayetteville, Raleigh
We are super excited to be hosting our annual Triangle Modern Web holiday party and to be co-hosting with Devs@RTP, Code Craftmanship Saturdays, TriangleJS, Triangle Node.js, GDG Triangle, RTP Angular.js, Triangle Serverless, Triangle Elixir, Triangle ReactJS, & Triangle Ruby for this awesome event!
Come and help us celebrate the end of the year & the holidays with a special meetup featuring a cookie exchange, white elephant and plenty of exciting lightning talks! You won’t want to miss out!
When: December 17, 2019 from 6:30PM – 9:00PM Where: Pendo (150 Fayetteville St #1400 Raleigh, NC)
Lightning talks by…
Rob Ocel Senior Software Engineer, This Dot Labs Talk: A quick introduction to state machines using XState
Wayne Hui Software Backend Engineer, Pentair Talk: Interacting with SQL Server
Lucas Spusta Student Talk: Top 5 VS code extensions
Charts, graphs, and other data visualizations are an increasingly common way to convey complex information quickly to your audience. They’re eye-catching, helpful to your users, and they generate lots of traffic to your site.
Join us for our next A11yDevs event, Monday, November 18, 2019 at 6pm in Durham!
Joel Crawford-Smith: Intro to ARIA
ARIA can be an intimidating and confusing topic. Even its name “Accessible Rich Internet Applications” is scary. But it does not need to be. There are some aspects of it that are safe for beginners, which can be beneficial to the people who rely on ARIA.
We need to rethink ARIA. ARIA is not writing code for a computer. ARIA is about improving human communication. Humans make content and interfaces for each other. The computer is just a translator. If we break ARIA down into nouns, verbs, and adjectives we can think about ARIA as short sentences. And most importantly, we will test what our sentences sound like on the other side of the screen reader.
Bio: Joel is a Duke Web Accessibility Administrator.
Maria Lamardo: Focus Management
Lets go over focus and how you can manage it in your application.
Bio: Maria Lamardo is a Front-End Engineer at Pendo