Accessible Charts with ARIA

Originally published on the blog, on November 25, 2019, in modified form.

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).

ARIA basics

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.

Basic accessible SVG chart

The WAI-ARIA Graphics Module defines 3 new roles:

  • '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.

Adding value

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).

<text> 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.

<title> element

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.)

'aria-label' attribute

This is pretty straightforward. Just put the value in the 'aria-label' attribute, like this:

<rect aria-label="4" … />

'aria-labelledby' attribute

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:

<text id="bar-1-value"></text>
<rect aria-labelledby="bar-1-value" … />

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”:

<rect role="graphics-symbol" aria-roledescription="bar" 
  x="70" y="20" width="25" height="40"></rect>

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.

Full disclosure

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.

Why Accessibility is at the Heart of Data Visualization

To make data viz more accessible, we first need to understand assistive technology

Originally published by invitation on Nightingale, the Journal of the Data Visualization Society, on May 21, 2020, for Global Accessibility Awareness Day.

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

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.

Blind person using a screen reader
A blind screen reader user at work (photo credit: U.S. Air Force photo/Nan Wylie)

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 visual media, consider how blind people can consume your content. That might be structuring your SVG markup to allow users to tab through each data point, or it might be providing an alternative data table. Or it might be using sonification. Sonification is the representation of data as nonverbal sounds, like a Geiger counter or EKG; you can see and hear an example of sonification on the Accessible Pandemic Data Bulletin, one of the few sources that blind users can find partial data about the spread of COVID-19.

If you’re offering only data tables as a fallback, think of how people with low vision, like fully sighted people, benefit more from clear, high-contrast, low-noise visualizations.

If you’re using animation, factor in people with epilepsy, ADHD, or cognitive disabilities, and give the user control of the animation.

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?

Spreadsheet of population numbers for 4 most populous countries, with lots of numbers
Line chart of population numbers for 4 most populous countries, with the highest point for China but steepest line for India

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.

Uncharted Territory

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.

Dataviz Fireside Chat

Later today, at 1pm ET, I’ll be joining some dataviz accessibility luminaries as a panelist on the Data Visualization Society’s fireside chat webinar, moderated by Amy Cesal. Join us for a chat about accessibility and data visualization on Global Accessibility Awareness Day

Sign up for the webinar

Doug Schepers – Director at Fizz Studio
Melanie Mazanec – Engineer at Bloom government digital services
Dr. John Gardner – Founder of ViewPlus
Sarah Higley – Software Developer at Microsoft


The communal notes are now available.

Accessible Charts with ARIA

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.

But they don’t have to be, if you use ARIA. Find out how on the blog, where I consult on accessible data visualizations and developer relations.

Accessible Dataviz Talk at A11yNYC Meetup

If you’re in the New York City area, I hope you’ll come see my presentation on accessible data visualization at the @A11yNYC meetup on Thursday, June 13! This is a refinement of the talk I gave at CSUN 2019 and #a11yTo Conf 2018.

A11yNYC (Accessibility New York City) is an excellent meetup group. I’m very pleased to be speaking there, joining the ranks of other past presenters who I greatly admire. I met one of the organizers, Thomas Logan of Equal Entry, when we both spoke at a11yTo Conf, and he was gracious enough to give me a chance to speak at their meetup.

The show starts at 7pm, and it will be live captioned for the hearing impaired… if the captioner can keep up with me!

Register now! It’s free!


Data visualization doesn’t have to be visual! Don’t assume that a chart or diagram can’t be made accessible. In this talk, you’ll learn how the brain processes data visualizations, how we can leverage this to work with other senses, and tips and best practices for making complex graphical content available to all. We’ll also offer a direct comparison on different tools and software that make it easy to ‘accessibilify’ your diagrams.

Update: Video Recording

The video for my Data Verbalization presentation is now available for streaming, with captions.

CSUN 2019

I’m excited to be speaking at the CSUN Conference on Disabilities this year!

My presentation, Data Verbalization: Accessible Charts and Diagrams, is scheduled for Friday, March 15, 2019 at 1:20 PM. It’s one of the last talks of the conference, but I promise you it will be worth sticking around for.

I have a whole new slide deck, with all new material on the cognitive aspects of why data visualizations work for sighted people, and considerations for making equivalent affordances for non-sighted people. If you liked my Invisible Visualizations talk, you’ll love my Data Verbalization presentation!

And I’ll also have a guest star, the inimitable Mark Sadecki, an old friend from W3C, and a sales engineer at my client, Compliance Sheriff.

I’ll be there for the whole conference, so if you see or hear me in the halls, come say hi! I’d love to talk with you. And I look forward to seeing you at my presentation, and joining you for discussions afterward.

A11yTo Conf 2018

I’m nervous and excited to be traveling north to Canada, to speak at the prestigious A11yTo Conf. I’ve spoken at many larger conferences, but A11yTo Conf (Accessibility Toronto Conference) is a more selective event, with all the best accessibility speakers.

I admit to some imposter syndrome. In reality, I’m pretty highly specialized within accessibility, in the tiny niche of accessible data visualizations. Most of the speakers, and many of the attendees, have been practicing accessibility in the trenches for many years, and they have skills way beyond my own in many ways.

But accessible data visualization is a useful specialty, so I feel I have something to offer. My talk this year is a brand-new deck, addressing the cognitive processes that make data visualizations work for sighted people, with lessons learned about how to make some of the same things work for non-sighted people, in a different medium.

When it comes down to it, data visualization is about solving tasks with data, answering questions about facts. And that can be accomplished efficiently in many different ways.

I’m also a bit nervous about my new deck, Data Verbalization. My previous presentation, Invisible Visualization, was refined and revised and remixed over the years, and I was comfortable with how to deliver it. But sometimes we need to get out of our comfort zone and explore new ways to reach new people. I learned a lot while researching this new presentation, and I’d like to think I’m getting more scientific about the material, while still presenting it in a clear, common-sense way that’s pragmatic and relatable… or so I hope!

I hope to see some of you in Toronto at #a11yTOConf, October 15 and 16, 2018. I go on at 11:20am on the first day, so I’ll have the rest of the conference to learn from the other speakers.

Wish me luck, and come talk to me if you’re there!

Talk Summary

Data Verbalization: Data visualization doesn’t have to be visual! Don’t assume that a chart or diagram can’t be made accessible. In this talk, you’ll learn tips and best practices for making complex graphical content available to all, and hear about tools and software that make it easy to accessibilify your diagrams.