DO NO HARM GUIDE
CENTERING ACCESSIBILITY
IN DATA VISUALIZATION
EDITED BY JONATHAN SCHWABISH, SUE POPKIN, AND ALICE FENG
DECEMBER 2022
2 DO NO HARM GUIDE
03
PART ONE
Introducon
Chapter One
Centering Accessibility
in Data Visualizaon
JONATHAN SCHWABISH
SUE POPKIN
ALICE FENG
11
PART TWO
A Framing of Why
Accessibility is Important
Chapter Two
The Right Tools for the Job: Learning and
Building for Data Visualizaon and Accessibility
FRANK ELAVSKY
Chapter Three
Designing Data for Cognive Load
DOUG SCHEPERS
31
PART THREE
Alternave (alt) Text and
Screen Readers
Chapter Four
Wring Alt Text to Communicate the
Meaning in Data Visualizaons
ELIZABETH HARE
Chapter Five
Coding Accessible Data Visualisaons
LÉONIE WATSON
Chapter Six
Creang Beer Screen Reader Experiences
SARAH FOSSHEIM
59
PART FOUR
Accessibility Tesng and Remediaon
Chapter Seven
Praccal Accessibility Tesng for Data Visualizaons
LARENE LE GASSICK
Chapter Eight
Infographic Equity in PDF Documents:
Designing with Accessibility in Mind
DAX CASTRO
84
PART FIVE
Accessibility in Teams
and Organizaons
Chapter Nine
Building Accessibility Best Pracces Into Your
Organizaon’s Data Visualizaon Style Guidelines
AMY CESAL
Chapter Ten
Nontechnical Barriers to Data Visualizaon
Accessibility in Government
MELANIE MAZANEC
TABLE OF
CONTENTS
PART ONE
Introducon
4 DO NO HARM GUIDE
Every day we are inundated with tables, graphs,
charts, and maps explaining everything, including
the unemployment rate, COVID-19 vaccinaon
rates, baseball home run launch velocies, and
our investment porolios. When made well,
data visualizaons can help readers and users
nd insights and make discoveries. When made
poorly, they obfuscate, mislead, or make it
dicult for people to use them eecvely.
At the signing of the Americans with Disabilies Act 32 years
ago, President George H. W. Bush remarked that the law would
enable “every man, woman, and child with a disability [to] now
pass through once-closed doors into a bright new era of equality,
independence, and freedom.” That promise remains unrealized.
Disabled people sll ght for full inclusion and equality when it
comes to employment, health care, access to transportaon, and
more. And in today’s digized era, people with disabilies do not
have full access to many documents, reports, newspapers, data,
and data visualizaons. This report is a guide to help close those
gaps and work toward a more inclusive and equitable world for the
more than the esmated 61 million people
[1]
with disabilies in the
United States today.
For years, the data visualizaon eld has been largely inaccessible
to people who cannot process visual content the same way as
others. And when researchers and praconers have focused their
eorts on creang accessible content, they have almost exclusively
addressed issues around color. Color vision deciencies—or “color
blindness” in the common parlance—have been the primary focus
(and oen the only focus) when data visualizaon developers and
communicators consider the needs of people who have visual
impairments. Creators focused their aenon on avoiding red-
green color palees because an esmated 4 percent of people
cannot disnguish similar shades of those colors. Less aenon—
perhaps even no aenon—is paid to people with other forms of
vision impairments, including blurriness, contrast sensivity,
and blindness.
But disabilies extend far beyond sight impairments. Some people
cannot use a keyboard or mouse; some have aenon management
dicules; some have disabilies aecng balance or moon; and
some have learning disabilies such as sensory processing disorder
CHAPTER ONE
Centering
Accessibility
in Data
Visualizaon
JONATHAN SCHWABISH
SUE POPKIN
ALICE FENG
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 5
or dyslexia. And combinaons of these disabilies can
aect dierent systems simultaneously. Moreover,
probably all of us have at some point had a temporary
disability such as a broken arm, a migraine headache,
or a concussion.
The creaon and display of digital informaon usually
do not include accessibility pracces for people with
a wide variety of disabilies. As content creators, we
need to be mindful of new tools and guidance for
making our work available equitably. By doing so, we
can ensure that everyone has equal access to accurate
informaon and data. And when more people can
access and process our informaon, the more likely it
is that our ideas, our data, and our analysis will actually
be used.
This third volume in the Do No Harm Guide series
from the Urban Instute seeks to provide in-depth
lessons on how to create visualizaon products that
are more accessible to disabled people. As with the
other volumes in this series, one of the central themes
in creang beer, more equitable, and more inclusive
content is to center the work around empathy. By
thinking carefully about the needs of all people
and communies—especially those who have been
historically underrepresented and marginalized—we
can create beer and more accessible content.
As in the second volume, Do No Harm Guide: Addional
Perspecves on Data Equity, we solicited the input of
experts to help build a praccal, aconable guide.
We idened several authors who have experience
creang accessible content, many of whom also
have lived experience with disabilies. We solicited
proposals from a select group of scholars and
praconers, then narrowed those proposals down
to nine essays that would provide a comprehensive
(though by no means complete) guide to creang
accessible data and data visualizaon products. We
also had an advisory board, consisng of four experts
in data, data visualizaon, and accessibility, who
reviewed the essays to ensure we did not omit any
major issues or challenges.
As we reviewed and edited the various essays, ve
clear themes emerged:
Design with accessibility in mind from the beginning.
•
From creang stac reports and graphs
(Castro, Chapter 8), to building tools and
plaorms (Elavsky, Chapter 2), to procuring and
implemenng those tools (Mazanec, Chapter
10), data praconers will create beer products
by starng the process with accessibility in
mind rather than adding accessibility in as a
remediaon step retroed at the end. Taking an
accessibility perspecve from the outset requires
teams and individuals to crically consider what
the expected user experience will be; who will use
the tool or data; and how visual elements like text,
colors, and online navigaon will be consumed by
the broadest audience possible.
•
Accessibility should not be a specialty. Anyone
working with data or creang digital content
should understand and strive to produce
accessible products. Although some of the
aspects of creang accessible online content
clearly require technical experience, the work
should not be le to a single person or some
subset of the team. Mazanec (Chapter 10)
discusses how people at dierent levels in a
management hierarchy have their own roles to
play, and Cesal (Chapter 9) lays out strategies for
creang data visualizaon styles and style guides
that incorporate accessibility. Elavsky (Chapter 2)
calls for more resources to address the knowledge
gaps many web developers have.
•
There is no established denion for what
makes a data visualizaon accessible. Although
Web Content Accessibility Guidelines lay out
requirements for making accessible websites, no
standards have yet been agreed upon for how to
make data visualizaons accessible. Our authors
oer several ideas and approaches, including
linking to the underlying dataset and adding
screen reader interacon to web-based
charts. Le Gassick (Chapter 7) walks through
6 DO NO HARM GUIDE
the specic issues to look for when conducng
accessibility tests.
•
People with disabilies should be involved in
the design of data visualizaon products and
usability tesng. Many of our authors urge data
praconers to involve people with disabilies in
the design and development of data visualizaons
and data-driven products to ensure their needs
are met. Charts, graphs, and other content should
also be tested by users with disabilies to idenfy
any usability or accessibility issues.
•
There is not a single right answer for wring
alternave (alt) text. The phrase alt text shows up
a lot in this volume. Three chapters are devoted
exclusively to helping you write beer alt text in
your graphs and documents. But there is no single
right answer or right strategy for wring eecve
alt text. The nal visual product, the plaorm on
which that product is being published, the target
audience, and the technology being used all
inuence the best approach. The guiding principle
is to write alt text that gives disabled readers
as close to the same experience as nondisabled
readers as possible.
As comprehensive as we believe this volume is, we are
sll missing key elements of creang truly accessible
data and data visualizaon products and an accessible
web more broadly. First, this report omits how people
with certain physical disabilies use online content.
How do and should data visualizaon tools, plaorms,
and websites enable people who cannot use a mouse
or keyboard? Are there new technologies, plaorms,
and best pracces that can help these users beer use
and experience the web?
Second, we do not invesgate the (slowly) growing
use of sonicaon to communicate data. Some
praconers and media outlets are now using sound
to communicate data, such as piano notes aligned
with changes in polical polling results in Germany
[2]
or enre scores of sounds based on data values.
[3]
Interesng joint work between the Sonicaon Lab
at Georgia Tech and the Highcharts data visualizaon
company to create a free, open-source tool to combine
data and sound is also very promising.
[4]
This area of
data sonicaon is sll in its early stages, but it holds
potenal for enabling people to interact with data in
new ways.
Third, we don’t provide “an answer.” Perhaps we
started this work with the hope of nding a concrete
answer on how to write alt text or how to approach
dierent technical challenges. But the actual
experience, as usual, is more complex than imagined.
When creang this volume, we tried to follow a
core principle of the Disability Jusce movement—
“nothing about us without us.” We worked with and
relied upon the involvement of people with disabilies
throughout the project, including contributors,
advisors, and reviewers.
Our editorial team is also unique. Jonathan
Schwabish is a researcher who focuses his data
visualizaon work on stac graphs or relavely
straighorward dashboards. Alice Feng is a data
visualizaon developer who creates unique and
bespoke visualizaons using JavaScript and other
object-oriented programming languages. Sue Popkin
is codirector of Urban’s new Disability Equity Policy
Iniave and the founder and coleader of Urban’s
Disability Anity Group, which seeks to make Urban a
more equitable and inclusive workplace for sta with
disabilies. Between the three of us, we bring together
technical experse and the experience of living
with disabilies. Popkin helped ensure the language
and concepts in this volume reect the needs and
perspecves of people with disabilies and ensured
our work avoids ableist language and assumpons.
As with much of the language that seeks to promote
equity, language about disability is constantly evolving
and changing, but we have done our best to follow
Urban’s comprehensive guidance.
We also strive to make this volume as accessible as
possible for a nontechnical audience. Much of the
technical language is unavoidable—aer all, creang
online content requires tools or programming
languages that not everyone knows or understands—
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 7
but our review process helped ensure these essays
include clear examples, clear language, and accessible
data visualizaons and images.
The essays in this volume do not need to be read
sequenally, though we have organized them with
that approach in mind. We have divided the volume
into four main parts. The two essays in Part 1—from
Frank Elvasky and Doug Schepers—provide a big-
picture view of creang accessible content. Elavsky
uses his work on the Chartability tool—a framework
for creang accessible data visualizaons—to make
the case for data tools that enable people to
build accessible content. Schepers explains the
foundaon of how our eyes and brains work to
process visual content (“cognive load”) and how
those processes work dierently for people with
dierent kinds of disabilies.
Part 2 of the volume focuses on creang alt text and
screen readers. Liz Hare provides some basics on
how to think about and write alt text. She explores
two dierent models to write eecve alt text and
shows how users might incorporate those approaches
into their work. Sarah Fossheim and Léonie Watson
explore best pracces around screen readers—tools
that are used by blind people, people with low vision,
and people with learning disabilies who consume
text in audio formats. Fossheim provides an in-depth
exploraon of how screen readers work and how
to write alt text and add it to data visualizaons.
Watson provides technical guidance on how data
visualizaon developers can use Accessible Rich
Internet Applicaons to create beer screen reader
experiences in their online work.
In Part 3 of the volume, we turn to tesng and
remediaon. Larene Le Gassick plays the role of
accessibility tester and demonstrates how to evaluate
a website or data visualizaon for accessibility. Dax
Castro dives into more detail, showing how to make
PDF reports and standalone graphics more accessible
by incorporang tags, alt text, and layers into your
documents.
Finally, Part 4 takes an organizaonal view of
incorporang accessibility into the data and data
visualizaon workow. Amy Cesal provides praccal
advice on how to create a data visualizaon style
guide with accessibility at the forefront. And Melanie
Mazanec describes how exisng rules and regulaons
in the US federal government are a good start for
creang accessible content, although those regulaons
have a long way to go before they’re ideal.
Together, we hope these nine essays provide a solid
foundaon for beginning to think about how to create
accessible content. You will nd specic, detailed
informaon on how to make single graphs, reports,
and websites more accessible by considering the
accessibility of colors, fonts, moon, and text. You will
also nd higher-level consideraons around teams and
organizaons, models for accessibility standards, and
ways to build more inclusive products.
This third volume of the Do No Harm Guide series
does not cover everything—there are more avenues
to explore, plaorms to evaluate, and soluons to
uncover. As with other reports in this series, the
lessons described here are not xed rules, but we hope
they provide a starng point at which you can begin
your journey to create beer and more inclusive work.
By doing so, you not only make it possible to hear
more voices, you also ensure your work is accessible
to everyone.
8 DO NO HARM GUIDE
Chapter One Notes
1
hps://www.cdc.gov/ncbddd/disabilityandhealth/infographic-disability-impacts-all.html
2
hps://interakv.morgenpost.de/spd-absturz-sound/
3
hps://www.loudnumbers.net/
4
hps://sonicaon.highcharts.com/#/
PART TWO
A Framing of Why
Accessibility is Important
10 DO NO HARM GUIDE
CHAPTER TWO
The Right Tools
for the Job:
Learning and
Building for Data
Visualizaon and
Accessibility
FRANK ELAVSKY
Since 2010, the number of websites in
existence has grown from less than a quarter
billion to nearly 2 billion,
[1]
and data visualizaon’s
explosive growth has followed across every
domain: personal, corporate, government,
policy, and research.
We collect far more data than in the past, and as a result, we have
started building faster and beer tools to make that data useful.
Now, we encounter charts and graphs for everything, such as sports,
local infecon rates, stock prices, and elecons.
But these empowering advancements have not been made
available to people with disabilies. Those who are not able to
access these data visualizaons are le with clunky, broken, and
ineecve systems.
Who do I mean by “people with disabilies?”
Well-meaning folks oen assume that accessibility in
visualizaon focuses on visual disabilies, such as color
vision deciency, blindness, and low vision. But interacve
data visualizaons in complex tools and in applicaons
can also produce barriers for people with cognive,
vesbular, and motor and dexterity disabilies. In fact,
this problem isn’t unique to visualizaon. One study found
that academic accessibility research disproporonately
focuses on visual disabilies.
[2]
When I write “people with
disabilies,” I refer to a broad spectrum of people. Not
everyone with disabilies will encounter barriers with data
visualizaons, but I want to encourage you to consider that
most people with disabilies might.
Although for decades we have had the tools and standards to build
an accessible internet, 97 percent of the top million website home
pages sll fail basic, automated accessibility tests, according to the
latest WebAIM Million report.
[3]
Further, automated tests leave
out anywhere between 57 to 80 percent of other accessibility
consideraons,
[4]
meaning the state of content on the web for people
with disabilies is likely worse than measured.
Even with this terribly small share of accessible home pages,
the state of data visualizaons is even worse—virtually all are
inaccessible in some way or another. In 2021, I created Chartability,
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 11
a set of heuriscs pulled together from designers,
developers, researchers, and praconers to evaluate
data visualizaons for visual, motor, vesbular,
neurological, and cognive accessibility.
[5]
In all of my
professional audits using Chartability—over 80,000
tests performed to date—not a single data visualizaon
scored 100 percent for accessibility, and most
consistently scored worse than every equivalent test
performed by the WebAIM Million report.
As the data visualizaon eld connues to expand and
grow, accessibility consideraons need to be central
to content creators’ analyses and communicaons.
If creators connue to use the same methods and
tools without interrogaon, the current state of
inaccessibility will only worsen. To make the future
more accessible, creators rst need to recognize what
tools and soluons aren’t a good t, become more
knowledgeable about accessibility, explore how we
can improve the tools we have, and build new tools
enrely.
Not Every Technical Soluon Is a Good
Fit for Accessibility
How can we intervene on human-built problems of
accessibility in data visualizaons and the usability of
the web more generally? Business-minded approaches
seek to reduce up-front cost by leaning on quick-
x soluons like web accessibility overlays, which
consist of third-party code, programs, or tools that are
layered on top of exisng websites to make them more
accessible.
[6]
Researcher-minded approaches strongly
incenvize “solving” inaccessibility by using arcial
intelligence or machine learning methods on things
that have already been built.
Both approaches try to x accessibility problems
using the same tools and systems that created
those problems. Although this goal is noble, the
results are not good. Overlays and machine-learning
soluons suer from many of the same fundamental
issues. They force people with disabilies to rely
on machine-generated accessibility, provide a poor
overall experience compared with human-authored
funconality, and fail to contextualize and provide
appropriate interpretaons of informaon.
Data visualizaon praconers connue to rely
on machine learning models that magnify exisng
inequalies. As an example, praconers have
tried build machine learning models that aempt to
automacally interpret chart descripons and insights
without any guidance from the author.
Wring alternave (alt) text to describe visual content
on the web takes some serious consideraon (see
Chapters 4, 5, and 6). In a 2020 blog post, disability
and accessibility expert Sheri Byrne-Haber argued that
no single answer exists to the queson of “what is
the right alt-text for an image?”
[7]
“Context is the most
crical aspect of alt text everyone seems to miss,”
she writes. As an example, she shows eight dierent
possible descripons of an image of a Jack Russell
Terrier wearing sunglasses. All of the descripons
could be valid depending on the author’s intent and
the context that surrounds the image. Here I provide
my own version of this test. Do you think a machine
learning algorithm could know which of the following
descripons of this line chart is the right t?
1. “Line chart.” If this image appeared in the
chart-picker interface of a tool like Excel or
Tableau, the chart type is the only piece of
informaon that maers.
2. “A line chart with ve lines, tled Product
Performance in 2021.” If the image appeared
instead in a mockup made by a designer whose
work is in progress, only the chart type and tle
would maer, because the data are made up and
the design is likely to change.
3. “Line chart. Product Performance in 2021.
Product A is outperforming all other products.”
In a presentaon to a decisionmaker who wants
to know which product is doing the best, both the
data and design maer.
12 DO NO HARM GUIDE
4. “Line chart. Product Performance in 2021.
All products trended down sharply from
January unl June and slowly stabilized back into
posive territory by November.” In a report to
analysts who want to know about larger
trends, the takeaways from the data are
what maer most.
5. “A minimalist, greyscale line chart with ve
lines tled Product Performance in 2021 using a
full-width, bold-weight, sans serif typeface.
Product A’s line is emphasized with a near-black
charcoal color, thickened stroke, and direct label
at its end. All other lines in the chart are shown
with reduced importance and are thinner,
unlabeled, and colored with a soened grey.
There are no data labels, grid lines, or y-axis on
the chart, but an x-axis shows abbreviated
months of the year from January to December in
a small, light, sans serif typeface.” In a design
porolio or arcle that explains minimalist chart
designs, the design details are what maers.
6. “(The alt text is set to NULL, and the image
is marked as decorave/presentaon-only).”
The graph is simply decorave and not intended
to convey content. It might be a background
image or meaningless ller. (It’s worth nong
that in pracce, you can’t just leave an alt text
box empty. The image must be purposely set as
decorave or “NULL”; see Chapter 5 for
more details.)
Just like Byrne-Haber’s example, any of these (or
none of these) descripons could be appropriate
depending on the context. Will a machine learning
algorithm know what other text, subtext, funconality,
and content surrounds the chart or what the chart is
intended to be used for? Only a human author really
understands why they’ve made something and what
they believe their audience should know. But as Louise
Hickman and Alexa Hagerty argue in a 2021 blog post,
soluons that t people’s needs are oen in tension
with soluons that scale, such as machine learning or
arcial intelligence.
[8]
Algorithmic soluons tend to
avoid nuance and focus on a one-size-ts-all design,
which can create problems for people with disabilies.
This nuance is why it’s imperave that the people
who create charts and graphs (with the assumpon
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 13
that they have some understanding and intent for that
visualizaon’s use) also understand how to make their
work accessible for people with disabilies.
Gaining Praccal Knowledge about Accessibility
Is the Prerequisite to Using Tools Eecvely
“The classroom remains the most radical space of
possibility in the academy,” wrote author and acvist
bell hooks.
[9]
She argues that teaching people how to
think about the problems in our world can culvate
the most radical opportunies to enact change.
If we educate designers, developers, researchers,
and authors about the importance of accessibility
and how to implement accessibility into their work,
perhaps they will be the ones to make their work
more accessible and imagine new futures. Before we
imagine what the right tools are for the job, we need
to have the collecve knowledge of what accessible
experiences should be. Many tools are capable of
being accessible, but praconers need to think about
accessibility and their design goals before they can use
those tools eecvely.
Providing a oor of praccal knowledge was my
goal for Chartability. In my collaboraon with
Dominik Moritz and Cynthia Bennet, we explained
that Chartability would take exisng accessibility
knowledge and synthesize it for the dicult domain
of data visualizaon.
[10]
I operated on the assumpon
that we need a level of self-suciency and capability
to recognize quality or challenges as we do our
work. Chartability exists as a design resource for
praconers to evaluate their own visualizaons. As
a eld, we need more resources like it. People need
paerns, guides, and reusable materials.
But a tool like Chartability doesn’t set a ceiling or push
the boundaries of what we already know. It serves as a
record of the bare minimum of what we should be
doing. Working alongside people with disabilies is the
single most important thing we can do to go beyond
the minimum and work toward accessibility. People
with disabilies are the actual experts who can tell us
what is or is not accessible to them. We need them as
coworkers, codesigners, leaders, and experts who help
build things with us. But this guidance must always
include a caveat: be wary of asking for free labor as
you embark on a path toward learning. Do everything
you can to nd what has already been documented in
standards, blogs, research, and arcles, and
compensate experts for their experse when you
work together.
Improving praccal knowledge also entails teaching
accessibility as a foundaonal skill. Although people
new to accessibility work oen nd it dicult, this
barrier largely arises from missing skills. Self-teaching
accessibility frequently leads to a mismatch of skills:
praconers are highly advanced in one area of
design or development by the me they recognize the
signicant gaps in their understanding. I’ve seen this
gap me and me again with web engineers who don’t
know how to properly use programming languages like
HTML and CSS. Unfortunately, these engineers get
so deep into bad pracces that the basic skills
necessary for accessibility become signicantly
expensive to relearn.
Knowledge alone can’t x everything. We need to be
able to use what we know. If our tools and materials
aren’t designed to make accessibility work easy, we will
connue to take the path of least resistance.
Builders Need Improved Tools
I’m a maker for makers: I build tools that others use
to create. And I rmly believe that improving the
tools we have or simply selecng the best tools
out there are two of the easiest ways we can stop
14 DO NO HARM GUIDE
building inaccessible data visualizaons. Think of this
process as slowing down or ghtening the ow on a
rehose. Right now, the overlays and machine learning
algorithms that eternally try to clean up the mess
we create are like Sun Yuan and Peng Yu’s haunng art
installaon of a robot forever mopping its own uid.
[11]
We are making messes with our tools faster than we
can clean things up.
In my previous work for Visa Chart Components—a
design system toolkit for Visa,—we wanted to
empower creators at Visa to easily make accessible
charts and graphs.
[12]
We wanted to be opinionated
about our design, which is the mission of any good
design system (Chapter 8).
This work revealed to me that there are four high-level
variables worth comparing when selecng visualizaon
tools for the job:
1. Ease of making a visualizaon from data
2. Expressiveness of the visuals
3. Out-of-the-box (ready-to-go) accessibility
4. Robust/exible potenal of the accessibility
Signicant me is spent considering the rst two
when selecng the right tools for the job. But have
we paid the same aenon to accessibility? To assess
that queson, I provide my opinions on various
visualizaon tools’ accessibility abilies based on my
experience auding and working with these tools.
(Keep in mind this assessment is not in any way legal
or compliance advice.)
Currently, most of our visualizaon tools aren’t
accessible out of the box, and nearly half don’t have
strong potenal, either. Most accessibility design and
development relies on the visual’s creator to know
about and nd a way to implement it. For example,
someone has to know that alt text is important and
gure out how to add it to a chart or graph. But some
tools help designers and developers do the right
thing while using the tool. In the same way that Excel
automacally sets defaults for spacing and color
schemes, some tools have defaults and out-of-the box
funconality for accessibility. Visa Chart Components,
for example, provides a warning and instrucons
to developers when they’ve forgoen to provide
expected inputs.
Installaon view: Tales of Our Time, November 4, 2016-March 10, 2017, Solomon R. Guggenheim Museum, New York. Photograph
by David Heald © Solomon R. Guggenheim Foundaon, New York.
Long description
There are four groupings in this chart.
1. Pushing the ceiling of accessibility:
Visa Chart Components, Highcharts, SAS.
These tools are in the middle of the upper-right quadrant of the chart, indicating high “Built-in Accessibility” and “Robust
Accessibility Potential.” Highcharts and SAS have more potential than Visa Chart Components, but Visa Chart Components
offers a little bit more out of the box.
2. Some great stuff but not comprehensive:
Datawrapper, PowerBI.
These tools are both a little below the x axis, straddling the y axis. Datawrapper is a bit more toward “Little Accessibility
Potential,” and PowerBI is closer to “Robust Accessibility Potential.”
3. A mix of good and not good but needs a lot of work
Tableau, Excel, Microstrategy, Chart.js, Plot, Altair/Vega-Lite.
All of these charts are most of the way down the x axis, with low built-in accessibility. Tableau and Microstrategy both have
lower accessibility potential; Excel, Chart.js, Plot, and Altair/Vega-Lite have a growing magnitude of potential.
4. Good luck
Figma/Sketch/Illustrator, Google Charts, ggplot2, ParaView, MATLAB, Matplotlib, P5.js, visx, D3.js, and Vanilla JS.
The majority of these have no built-in accessibility at all. Google Charts, P5.js, visx, D3.js and Vanilla JS all have an increasing
magnitude of accessibility potential; all others have little.
Tableau, Excel, Microstrategy, Chart.js, Plot, Altair/Vega-Lite.
All of these charts are most of the way down the x axis, with low built-in accessibility. Tableau and Microstrategy both have
lower accessibility potential; Excel, Chart.js, Plot, and Altair/Vega-Lite have a growing magnitude of potential.
4. Good luck
Figma/Sketch/Illustrator, Google Charts, ggplot2, ParaView, MATLAB, Matplotlib, P5.js, visx, D3.js, and Vanilla JS.
The majority of these have no built-in accessibility at all. Google Charts, P5.js, visx, D3.js and Vanilla JS all have an increasing
magnitude of accessibility potential; all others have little.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 15
At a high level, the accessibility capabilies of a tool
can be improved by ensuring the following:
•
The important details within the visualizaon can
be accessed by screen readers, keyboards, and
other assisve technologies. Most stac images,
like JPG or PNG les, can only be described by
alt text, meaning more complex features are
oen lost.
•
Users can download the data underlying the
chart to their own computer in an accessible
format (such as a CSV le).
•
The data in the chart can be represented with
sonicaon (as tones that can be heard) and in a
tacle format (that can be touched and felt).
•
Creators can annotate the visualizaon and guide
readers through it.
Tools can also oer the following funconality
out of the box:
•
Automac contrast adjustment
•
Redundant encodings
•
Text spacing
•
Interacve highlighng and dimming
•
Toolps
•
Semanc structure
•
Safe color palees
•
Accessible examples in core documentaon
Easy-to-follow core documentaon of accessible
pracce is vital as a rst step. Highcharts, a JavaScript
visualizaon library, provides a stellar example of
how tools can provide such documentaon.
[13]
Oen
when it comes to tools that make charts and graphs
16 DO NO HARM GUIDE
using code, praconers learn how to use the tools
from their documentaon. And the more that these
core documentaons can integrate accessibility
consideraons into every step of the tool’s use,
the more that community members will follow suit
and do the right thing. Datawrapper, another data
visualizaon tool, has guidance built in and
includes consideraons for alt text and color vision
deciency.
[14]
The tools themselves are the rst
place where correct, accessible best pracces
should be communicated.
However, when core documentaon is absent,
praconers oen learn how to use a tool from
community-contributed examples. Very few, if any,
community examples on blogs or websites include
consideraons for accessibility. This absence leads us
to a larger problem: when someone makes something
with an envious funconality, other praconers
copy it directly or otherwise emulate it. If the rst
product is inaccessible, that inaccessibility ends up
being reproduced every me it is copied. The Tableau
community is especially bad at this: expert users oen
“hack” Tableau to build extraordinary applicaon-
like interacvity or produce advanced visualizaon
types, but these examples almost always generate
nightmarish tangles of inaccessibility. Similarly, it is
dicult to intervene when inaccessible visualizaon
recipes are shared by creators on Observable,
company websites, or social media. If we don’t have
a community that can recognize inaccessibility
and catch these bad examples, we will connue to
reinforce bad pracces.
Another way to counter the lack of documentaon,
beyond catching bad pracces and building good
examples, is to highlight builders and makers doing
the best with the tools they have. The data team
for the City of San Francisco is a good example. Not
only did they carefully document how to make public
dashboards of COVID-19 case data accessible to
the public using PowerBI, they also created a set of
guidelines for others embarking on similar
work.
[15]
Chris DeMarni has documented his
accessibility journey with Tableau, including how he
went to great lengths to add keyboard interacvity
within charts, which is currently not something that
Tableau oers.
[16]
DeMarni used the hackability
of Tableau for accessibility rather than just for
extraordinary visual eects. These members of their
respecve communies are showing what their tools
are capable of, pushing limits, and inspiring others. It
is important that we look for and encourage this work
when we encounter it.
But tools shouldn’t rely on hacks to make accessible
data visualizaons, they should create accessible
products by default. Praconers can pressure
toolmakers to make changes to their tools. Pressure
works. Advocates in every major visualizaon
community already do this work: the teams developing
data visualizaon tools and plaorms like PowerBI,
Datawrapper, the Jupyter Project, Vega-Lite, Tableau,
and Observable’s Plot have all made strides for
accessibility following their inial releases because of
internal and volunteer eorts. PowerBI and Jupyter, in
parcular, have invested signicant eort in the past
few years. PowerBI has worked to ensure that tool
itself, not just the output from the tool, is accessible.
The community of praconers around Project Jupyter
have organized an accessibility working group to
improve their tools, including Jupyter Notebook, which
is one of the most common collaborave data science
notebooks used today.
[17]
They’ve built a coalion of funded and volunteer work
to shape the future of accessible data science but sll
have a long road in front of them.
Many of our tools are salvageable as long as we get
involved. If more praconers demand beer, more
accessible tools, companies might begin making
accessibility a priority.
It Isn’t Too Late for Visualizaon
Data visualizaon is in a hopeful place as a eld: we’ve
experienced explosive growth in tooling and pracce
in the past two decades, and nothing is so entrenched
that it cannot change. Two hundred years ago, we
had tacle maps and graphs made for people who are
blind or have low vision. Nothing is stopping us today
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 17
from also making informaon experiences broadly
accessible in old and new ways.
Our mission as a community is to surface insights out
of data. Our eld can grow beyond centering visuals
and remain true to this pracce. In the Nighngale
data visualizaon blog, Doug Schepers writes that
“accessibility is at the heart of data visualizaon.”
[17]
Making complex informaon understandable doesn’t
have to be limited to just visual representaons. I want
to inspire everyone reading this essay to imagine more
expansive data experiences, interacve stories told in
wrien form that can involve sound and touch as well.
Disabilies can have many dimensions that aect
every part of data representaon in design. In my talks,
I use the gure above to demonstrate how considering
the distribuons of disability among people living in
the US could aect every area of our pracce.
Everything on the right side of the gure we already
do. Considering people with disabilies encourages us
to become beer at each of these things.
Data visualizaon is at a watershed moment. We
have an opportunity to grow and mature in ways that
could inspire many other elds. We have a beauful
community of researchers, designers, engineers,
sciensts, analysts, reporters, and storytellers.
Accessibility is an opportunity for all of us to hone our
cra and become excellent at what we do.
We can’t rely on overlays and machine learning models
to solve access problems for us. We are the ones
designing and building data visualizaons, so the onus
falls to us. Although I wish my takeaway could be as
simple as telling you to begin learning accessibility
and working to improve your tools (which of course
you must do), I also want to stress that we have
structural and cultural priories to change as well.
Our employers need to make accessible workplaces
for our coworkers with disabilies. Our budgets need
to include accessibility as a top priority—and we
need to compensate disabled people for their advice
and experse in making our products beer. Our
immediate roadmaps need to include accessibility
as part of our core products. Our educaonal
programs need to teach about access and disability as
foundaonal topics. Every data visualizaon contest
or celebraon needs to include accessibility as a
measurement of excellence.
Unl we see changes like these, however, individuals
must do what we can, and it won’t be easy. So get
learning and building, and remember: pressure works.
Let’s take our relaonship with our tools to the next
level and never compromise on accessibility.
Considering Disability In Design Aects Every Area of Visualizaon
18 DO NO HARM GUIDE
Chapter Two Notes
1
“Total Number of Websites,” InternetLiveStats, accessed October 14, 2022, hps://www.internetlivestats.com/total-number-of-websites/.
2
Kelly Mack, Emma McDonnell, Dhruv Jain, Lucy Lu Wang, Jon E. Froelich, and Leah Findlater, “What Do We Mean by ‘Accessibility
Research’?” In Proceedings of the 2021 CHI Conference on Human Factors in Compung Systems, paper 371 (New York: Associaon for
Compung Machinery, 2021), hps://doi.org/10.1145/3411764.3445412.
3
“The WebAIM Million,” WebAIM, last updated March 31, 2022, hps://webaim.org/projects/million
4
“The Automated Accessibility Coverage Report,” Deque, accessed October 14, 2022, hps://www.deque.com/automated-accessibility-
tesng-coverage/.
5
Frank Elavsky, Cynthia Benne, and Dominik Moritz, “How Accessible Is My Visualizaon? Evaluang Visualizaon Accessibility with
Chartability,” Computer Graphics Forum 41, no. 3 (2022): 57–70.
6
See Overlay Fact Sheet at hps://overlayfactsheet.com/.
7
Sheri Byrne-Haber, “Context Is the Most Crical Aspect of Alt-Text Everyone Seems to Miss,” UX Collecve (Medium blog), October 10,
2020, hps://uxdesign.cc/context-is-the-most-crical-aspect-of-alt-text-everyone-seems-to-miss-e18803a79212.
8
Louise Hickman and Alexa Hagerty, “Standardised Access: The Tension between Scale and Fit,” Ada Lovelace Instute blog, May 24, 2021,
hps://www.adalovelaceinstute.org/blog/standardised-access-tension-scale-t/.
9
bell hooks, Teaching to Transgress Educaon as the Pracce of Freedom (London: Routledge, 2021).
10
Frank Elavsky, Cynthia Benne, and Dominik Moritz, “How Accessible Is My Visualizaon? Evaluang Visualizaon Accessibility with
Chartability,” Computer Graphics Forum 41, no. 3 (2022): 57–70.
11
See Sun Yuan and Peng Yu’s 2016 art installaon, “Can’t Help Myself,” at the Solomon R. Guggenheim Museum in New York, hps://www.
guggenheim.org/teaching-materials/teaching-modern-and-contemporary-asian-art/sun-yuan-%E5%AD%99-%E5%8E%9F-and-peng-yu-
%E5%BD%AD-%E7%A6%B9.
12
“Visa Chart Components,” Visa Developer Center, accessed October 19, 2022, hps://developer.visa.com/pages/chart-components.
13
“Highcharts for Accessibility,” Highcharts, accessed October 19, 2022, hps://www.highcharts.com/blog/accessibility/.
14
See Datawrapper’s website at hps://www.datawrapper.de/.
15
Lauren Jong, Emily Vontsolos, and Blake Valenta, “A Template for Accessible Data Visualizaons.” Medium, San Francisco Digital Services,
13 May 2022, hps://medium.com/san-francisco-digital-services/a-template-for-accessible-data-visualizaons-ca2ed52f945b.
16
Chris DeMarni, “A Tableau Accessibility Journey - Part IV - Keyboard Accessibility.” DataBlick blog, August 13, 2021, hps://www.
datablick.com/blog/2021/8/10/a-tableau-accessibility-journey-part-iv-keyboard-accessibility.
17
Jupyter Team, “Jupyter Accessibility,” Jupyter Accessibility Working Group, accessed October 19, 2022, hps://jupyter-accessibility.
readthedocs.io/en/restructure/README.html.
18
Doug Schepers, “Why Accessibility Is at the Heart of Data Visualizaon.” Nighngale Journal of the Data Visualizaon Society, May 21,
2020, hps://medium.com/nighngale/accessibility-is-at-the-heart-of-data-visualizaon-64a38d6c505b.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 19
CHAPTER THREE
Designing
Data for
Cognive Load
DOUG SCHEPERS
Today, we are inundated with so much
informaon—good and bad, true and false,
and everything in between—through the web,
social media, television, radio, and print. Data
visualizaons, such as charts, diagrams, and
infographics, can oer an oasis of simplicity,
dislling informaon to shapes, colors,
paerns, and words. That is data visualizaon
at its best.
But at its worst, data visualizaon confuses, decontextualizes,
obfuscates, deceives, or overwhelms. Worse yet, it oen blocks
access to the informaon enrely, such as a chart lacking
equivalent accessibility for readers with disabilies, including
blindness, low vision, or cognive disabilies.
[1]
We owe it to ourselves and to our readers to present informaon
in the clearest way possible. As with the plain language
movement, there are human rights and social jusce aspects of
clear, accessible data representaons. Decreasing the cognive
processing that it takes to understand a data visualizaon can not
only make our work beer but also lead to more inclusive, ethical
data visualizaon for people with disabilies.
[2]
Improving charts for people with disabilies normally improves
their usability for everyone. Cognive Load Theory (or CLT) is
one tool that helps us consider mental processing when creang
material. In this chapter, we’ll apply CLT to charts by looking at its
dierent aspects through the lens of specic disabilies; we’ll also
look at CLT in chart animaon.
[3]
Cognive Load Theory
CLT is a teaching methodology that originated in the 1980s to
examine how students learn. Researchers approached learning
from a neurological perspecve, considering how the brain’s
constraints could reduce eecve learning. In general, CLT does
not focus on data visualizaon or people with disabilies, but we
can apply many of its concepts.
CLT is based on the Atkinson–Shirin model of memory,
[4]
which
describes three types of memory: sensory registers, working
memory, and long-term memory. Whereas sensory registers are
the external inputs we observe, and long-term memory is the
fragments of those experiences we hold on to, working memory
20 DO NO HARM GUIDE
is the pathway and the boleneck between the two.
Tasks like learning new material or interpreng a
chart use up the limited capacity of working
memory. CLT seeks to understand our memory’s
capacity by categorizing a task into its intrinsic and
extraneous load.
[5]
Intrinsic load is the inherent nature of the informaon,
rened to its bare minimum.
Extraneous load is how the informaon is
structured and presented.
Both carry related elements that our working memory
must process and our long-term memory seeks to
store away. As content creators, our goal is to opmize
intrinsic load and reduce extraneous load so the
product ts the capacity of our working memory. This
process aligns with Edward Tue’s popular (though
oen cricized) contemporary advice in the data
visualizaon world to increase the data-to-ink rao
and reduce chart junk.
Informaon ows both ways between short-term
memory and long-term memory. Concepts familiar to
the reader (that is, already present in their long-term
memory) can decrease this load, as new informaon is
bundled into exisng mental models in a process called
chunking and automang.
[6]
Picture a bar chart, like this one showing the share of
American adults with a funconal disability. At some
point in your life, you didn’t know how to read a bar
chart, or even know that its dierent parts had
meaning. Later, you learned about the dierent axes,
how values were represented as the height of the bars,
and how to compare the bars to understand the
relaonships in the data. Each of these elements
occupied space in your working memory. As you
became more familiar with the bar chart, you no longer
needed to expend eort to read it. You had chunked
the dierent parts of the chart into their individual
roles, and now you automacally read and apply new
bar-chart data to this schema. The concept of the bar
chart no longer occupies your working memory, and
you can concentrate just on the novel data.
Now that we understand CLT, we can begin to
explore its many principles and applicaons. I
nd the following are parcularly relevant to
data visualizaons:
[7]
•
Mulmedia principle: Use words and pictures
because both are more eecve than words
alone. A reader is more likely to remember and
recognize data if they are presented as a bar chart
rather than as a dense table.
[8]
•
Conguity principle: Present words and pictures
simultaneously rather than successively. We
describe this strategy below in our discussion of
direct labeling.
•
Coherence principle: Exclude extraneous
words, sounds, or pictures. Adding elements to
a chart, including unnecessary labels or visual
distractors, reduces the speed with which
a reader comprehends and retains the core
informaon presented.
How intrinsic and extraneous loads t the capacity of our
working memory.
A bar chart. Because most of us are so familiar with this data
structure, the informaon it conveys is very apparent to us.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 21
•
Interacvity principle: Allow learners to control
the presentaon rate. This principle is especially
relevant in the discussion of animaon, which
we turn to later.
•
Signaling principle: Emphasize key steps in the
representaon. We describe this concept below in
our discussion on highlighng and annotaon.
Simplifying Is Too Simplied
It’s natural to conclude that opmizing intrinsic load
and reducing extraneous load is just a fancy way of
saying we should simplify our charts, diagrams, and
maps. That’s good advice, but it doesn’t always work
out that way. We need to consider our context, our
audience, and their aenon and engagement.
Simplifying works well for a reader who is unfamiliar
with the topic of a chart or who is under stress (such
as someone taking a med test). You can reduce
the amount of informaon or break it down into
manageable steps with addional context (extraneous
load). You can also use common chart types your
audience is familiar with.
But for a reader who has already developed a mental
model of our topic with me for exploraon, we
should make our chart dense with salient informaon.
A more informaon-dense chart might use familiar
symbols as shorthand, include more data, or use novel
chart types that highlight relaonships an expert user
can spot.
Both novices or experts have an upper limit to
eecve informaon density. Yoghourdjian and
colleagues explored brain acvity among 22 study
parcipants as they viewed complex node-edge graphs
(i.e., network diagrams) and found that cognive load
is readily apparent in their subjects when they’re
asked to complete basic comprehension tasks.
[9]
The
more complex the chart, the more mental eort was
recorded, up to a threshold where the mental strain
reduced because the reader gave up and disengaged
from the task. Yoghourdjian’s study demonstrates that
when creang our charts, we need to keep in mind the
audience’s capacity to engage with the material.
CLT and Disabilies
Cognive load aects everyone, but the challenge
can be amplied for people with disabilies. A small
distracon can derail a person with Aenon Decit
Hyperacvity Disorder (ADHD) or a disability aecng
memory. Too much unstructured textual detail can
bewilder a reader who is blind or has low vision.
Separang related visual elements, like a line and its
label, can disorient a person with low vision. Dense
informaon or large blocks of text can be dicult
to comprehend and absorb because of fague, a
complicaon of many neurological condions such as
traumac brain injuries and Mulple Sclerosis.
Understanding how CLT can aect people with
dierent disabilies allows us to make more accessible,
inclusive, and generally usable data visualizaons.
Although concepts can apply dierently depending on
a user’s specic disability, our goal is to provide a brief
tour of some of the more readily apparent instances.
As we examine dierent principles of CLT through the
lens of specic disabilies, we need to be mindful that
each principle may have broader relevance to other
condions. A person may have mulple impairments,
and disabilies are oen interseconal with other
social factors, such as low income or educaonal
disparies, which can increase overall cognive load.
Merely addressing one type of disability may not
produce an equivalent and equitable experience
for all users.
Low Vision
People with low vision can experience loss of central
vision, decreased peripheral vision, reduced contrast
sensivity, or decreased ability to see small details,
all of which can make reading text or nding paerns
in numeric tables much harder than recognizing
paerns in shapes, lines, or blocks of color. Compare
the amount of informaon available in a blurry
spreadsheet with a blurry line chart in the two images
on the next page. Ascertaining the basics of the
paerns is much easier for the line chart than for
the table, which requires detailed examinaon of the
numbers in the cells.
22 DO NO HARM GUIDE
For people with low vision, charts oen convey
informaon with less eort than tables or text, which
decreases cognive load. Reducing these elements
from several individual numbers in a column to a single
line enables a person who uses a screen magnier to
track value changes while zoomed in or to see the
whole trend while zoomed out. This data presentaon
signicantly benets readers with low vision. Tacle
graphics can benet blind readers and readers with
low vision because visually impaired people can
process many types of graphics much beer by
touching a texture than by listening to a series
of numbers.
Another technique that aids users with low vision
is directly labeling each line in a chart rather than
using a separate legend. With a legend, readers have
to locate it, zoom in, memorize the symbols and
labels, zoom out to nd those symbols, then idenfy
and recall them. With direct labels, they can zoom in
directly on the line of interest and pan to the end to
nd its label (or zoom in on the label and pan back
along the line). Direct labeling also enables magnier
users to know the nal relave values of each line
while reading the labels, which helps them construct
a mental model of the data. (For an example of direct
labeling, see the secon below on divided-aenon
tasks.)
Tacle Graphics
Tacle graphics use touch to convey
informaon. You may have experienced
these as 3D exhibits in a museum or as a
touch-screen device that vibrates when
you move a nger over a parcular spot.
They’re commonly used in educaon and
science for people with visual disabilies and
have proven very eecve.
[10]
A variety of
techniques are available for making tacle
graphics. Stac physical graphics can be
created as shapes with a 3D printer or as
raised symbols on paper with a specialized
embossing printer or special capsule paper
that swells when heated. Digital tacle
images can be created to use the vibraon
motors in mobile devices, or content can
be designed to work with assisve
technology like refreshable pin displays
or braille displays.
[11]
Low Contrast Vision
A common low-vision characterisc is decreased
contrast sensivity. Colors may appear muted, and the
borders between dierent blocks of color may appear
ambiguous. An easy way to help people dierenate
between items while reducing cognive load is to
use separaon. We can do this by breaking tasks into
bite-sized chunks conceptually and visually with a thin
border between the slices in a stacked bar chart (see
pair of charts on the next page). This approach works
best for discrete data rather than connuous data, but
with a lile creavity, the principle can be applied to
both.
Because these images are blurred, we can much more easily
see the overall trends and relaonships in the line chart than in
the table.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 23
Blindness
When visually impaired readers hear a data table
through a screen reader, each number in the row or
column is read to them sequenally. The reader not
only has to remember the previous number, they must
also use their working memory to perform calculaons
on the magnitude and direcon of change, repeang
the process for each new number.
A chart can also expose raw numbers in a structured
way (e.g., with ARIA markup to make it accessible to a
screen reader; see Chapter 5 on ARIA labels), but this
has the same problem as a data table: it’s a ood of
numbers. To address this problem, you should provide
meaningful alternave (alt) text that describes the
most salient informaon, preferably with a detailed
summary as the extended descripon. The raw
numbers are sll important, because a blind reader
may want to delve into details and examine specic
values, but you should let people decide whether they
want to spend the me walking through the data aer
rst hearing the summary. Respect your reader’s me
and aenon.
Dyslexia and Dyscalculia
People with dyslexia and dyscalculia can oen
understand data visualizaons more easily than
numeric data, such as tables or lists of numbers. But
with both condions, text labels may not be as useful
as for most people, and problems with direconality
and orientaon may arise.
Dyslexia is a reading disorder that oen includes
dicules with visually processing symbols and
somemes with reading or interpreng charts or
diagrams. For people with dyslexia, ow charts are
oen ideal for explaining procedures, and icons or
pictograms can help more than words alone.
Dyscalculia is a disability relang to numbers and
mathemacs. It may include diculty with symbols,
quanes, mathemacal reasoning, memory tasks, or
somemes visual-spaal interpretaon. For people
with dyscalculia who don’t have problems with visual-
spaal interpretaon, charts can be very helpful in
processing mathemacal or numeric concepts and
content, whereas data tables might prove more
challenging. Many people with dyscalculia can struggle
with graphical melines, so me-series data may be
more challenging than other types of data.
In general, if your chart is explanatory rather than
exploratory, you should consider wring a summary
that reinforces its conclusion, with explicit projecons
or recommended courses of acon based on the
data. Symbols in line charts, scaerplots, and maps
should be unique and not rely on orientaon alone
to disnguish between them. Where possible, avoid
close-packed graphical elements—space them out to
make them disnct and reduce visual confusion. Grid
lines and guiding lines are helpful, especially if they are
interacve, but don’t let them visually overwhelm the
core data representaon.
The chart on the right is much easier to process visually because of the thin breaks in the bars. Our brains need to work a bit harder
to nd the breaks in the le chart.
24 DO NO HARM GUIDE
Aenon Management Disabilies
ADHD, or Aenon Decit Hyperacvity Disorder,
is misleadingly named. Someone with ADHD does
not have a decrease in aenon itself (because they
commonly exhibit hyperfocus); rather, they have a
decreased ability to direct their aenon to the
most important task at hand.
People with ADHD are not the only readers aected
by aenon management disabilies—typical aging
introduces several decits in memory management as
well.
[12]
People with aenon management disabilies
constute a large demographic audience.
As you work with data and charts, consider your
reader’s capacity for selecve and sustained aenon,
and decrease tasks that require divided aenon.
These changes might include reducing the amount of
detailed informaon in a chart or diagram, reducing
the number of annotaons and labels, and lowering
the complexity of the visualizaon itself. To beer
understand how we can tailor our visualizaons for
readers aected by aenon management disabilies,
we need to understand the dierent types of aenon
that visualizaons require.
Divided Aenon
Divided-aenon tasks require the reader to process
more than one source of informaon or to perform
more than one task at the same me. Noce the
dierence in the two graphs at the top of this page—
one has a legend, separated from the content; the
other has labels directly on the chart next to the ends
of the lines. Spling the reader’s aenon between
the data representaon and the legend means extra
mental processing. They need to commit each symbol
and color to their working memory, then shi their
view over to the line to interpret the data while also
applying the memorized legend. This eort may seem
trivial, but it imposes an unnecessary memory tax
that has been demonstrated to decrease the speed
and accuracy of comprehension and retenon of
informaon.
[13]
The direct labeling is also signicantly easier for
readers with low vision to process, and it benets
people with color vision deciency (CVD, or “color
blindness”), who can use label proximity rather than
color to idenfy and disnguish the lines.
Selecve Aenon
Selecve aenon is the reader’s ability to focus on
smuli that are relevant to the task at hand while
disregarding irrelevant smuli. You can improve
selecve aenon with a few simple techniques, all
of which are demonstrated in the pair of images on
the next page:
1. Decrease, remove, or deemphasize unneeded
visual elements using lower contrast, muted
colors, or thinner line width.
On the le, a line chart with labels in a legend/key. On the right, a line chart with direct labeling near the lines.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 25
2. Make relevant data marks of dierent
categories more easily disnguishable.
3. Move labels from a dedicated legend to direct
labels on data points or clusters of points.
As with direct labeling, using data symbols with
dierent shapes and dierent colors benets people
with CVD as well.
In addion to reducing extraneous load, you can
opmize intrinsic load by direcng the reader’s
aenon to the most salient parts of the data,
especially to reect the intent of an explanatory chart.
You can do this with text descripons (like alt text) or
with highlighng and annotaon, which is also
parcularly useful for people with low vision. This
selecve emphasis draws on the signaling principle
of CLT.
Sustained Aenon
Sustained aenon is the reader’s ability to focus
their concentraon on a task over an extended period.
Charts that require the reader to perform mulple
steps oen necessitate sustained aenon.
If you’re making such a chart, consider what tasks
you expect the reader to perform and whether they
require all the data to be in a single chart or if the chart
could be split into mulple charts, each focusing on
a specic task. If the set of tasks cannot be broken
up eciently, you may also consider adding a layer
of interacvity to help the reader concentrate on
a subset of the tasks or oer staged states with
feedback on progress.
Meaningful animaon may also help the reader sustain
aenon during prolonged or tedious tasks, such
as monitoring a chart for status changes. Animaon
is especially eecve when it draws aenon to
signicant changes, dramac shis, or triggered
thresholds.
How Animaon Can Decrease
(or Increase) Cognive Load
Meaningful animaon—through the use of videos,
animated GIFs, or other means—can be a powerful aid
to cognive accessibility. Animaon is one of the most
literal representaons of change over me and can
help engage readers.
Neurologically, our brains process and interpret
movement dierently, priorizing it over other visual
smuli. Because movement captures the reader’s eye
so eecvely, animaon can be overused, which is
On the le, a scaerplot with bold black grid lines and several symbols of the same shape with only color dierences. On the right,
an improved scaerplot with thin gray gridlines and several symbols of dierent shapes and colors.
26 DO NO HARM GUIDE
why it should be considered carefully and thoughully.
The brain has two pathways for processing visual
informaon: the “what” and the “where” pathways.
The “what” pathway leads to idencaon and
recognion, and the “where” pathway processes the
object’s spaal locaon. The “where” pathway is faster
and more immediate, which animaon triggers by
grabbing and keeping the reader’s aenon. We need
to make sure the content we’re animang is worthy of
this special consideraon by the reader.
Eecve animaon aids focus rather than disrupng it.
Chart animaons should be funconal and brief.
Animaon can also engage the reader’s emoons,
either by creang fun or by imparng causality or
agency to the animated objects.
[14]
The advantages of
animaon come with a caveat, however: it can take
longer to interpret, which can cause the reader to
make mistakes in analysis of the data.
[15]
Good use cases for animaon in data visualizaons can
be grouped into three broad categories.
Demonstrang progression. In more literal diagrams,
where gures represent real objects like the water
cycle, animaon can show the changing relave
locaons of those objects over me. In more abstract
line charts, it can reveal the progression of a trend,
which can also create emoonal engagement. In some
cases, it can even illustrate the actual pace of change,
either in real me or scaled.
State changes. In interacve charts, visual elements
oen transion from one state to another, such as
when the data on a chart are changed, zoomed, or
ltered. Showing this transion as literal movement
helps the reader stay oriented and track trends.
Without animaon, the data changes can be hard to
recognize.
An example of how animaon can be used to show real
changes in locaon.
How informaon proceeds from the occipital lobe to the dorsal visual stream or ventral visual stream.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 27
Feedback. Somemes a reader needs to know
immediately that their acons have had an eect in
interacve charts. If the compung task takes longer
than a few milliseconds, such as with an asynchronous
data fetch or a processor-intensive operaon, the user
may try to trigger the acon again or think it’s not
working. Providing an animaon can assure the reader
their acon has registered.
Best Pracces for Using Animaon
in Visualizaons
Animaon is safest when the user has control over
it. Data praconers should respect the user’s
preferences for when to play animaons, the speed
of animaons, and the ability to manually trigger
animaons. I’ve highlighted four best pracces for
making animaons useful (and safe) for all users,
especially those who may have a condion that limits
their ability to use or perceive visual informaon.
1. Deacvate Animaons by User Preference
For readers with some cognive disabilies, animaon
can distract or even be dangerous to them, such as by
triggering seizures.
On the internet, you can detect and honor the reader’s
animaon preferences. Programming languages for
the web like CSS and JavaScript have the concept
of a “media query,” which allows a website to detect
features of the user’s browser, such as whether the
user is using a touchscreen rather than a mouse, the
wrien language the user has congured, and sengs
related to accessibility. One of these sengs is the
“prefers-reduced-moon” media query. If the user
has indicated they prefer reduced moon, you can
eliminate the animaon or signicantly reduce the
speed or range of moon. For users who have not set
their browser’s animaon preferences, you can also
provide a website-specic opon for users to turn o
the animaon.
2. Give Control of Animaon and Processing Speed
Readers with memory or aenon disabilies may
not process informaon at the same pace as your
animaon.
[16]
The same goes for people who are
distracted. Consider giving the reader control over the
playback speed or the ability to restart the animaon.
Allowing readers to interact directly with the animated
element can also be eecve.
An example of providing feedback to a user.
Three versions of a scaerplot, where some of the data points move from the start in the rst scaerplot to the end in the third
scaerplot, with a transion between the two states in the second scaerplot. The movement path of each point is represented
by an arrow.
28 DO NO HARM GUIDE
3. Reduce the Number of Animated Elements
Having more than a couple of animated elements
can overload working memory, leaving the reader no
capacity to process and remember the changes before
the animaon ends.
[17]
As a result, you should either
ensure the animang objects move in a similar paern
to one another or reduce the number of animated
objects.
4. Announce or Describe Animaons
for Blind Readers
If you do use animaons in a meaningful way, be
sure to provide a descripon or a live sequenal text
update for blind readers, such as with the “aria-live”
aribute (see Chapter 5 on ARIA labels). This addion
is especially important for users receiving feedback
aer interacng with a visualizaon.
Conclusion
As data professionals, we oen rely on quantave
measures of chart eecveness, through A-B tesng,
task assessment, or another means of using data;
we do this because we want to solve problems with
certainty. But the world has never been a hospitable
place for certainty. Embracing the ambiguity of how
people approach our data visualizaons will oen lead
us to create more expansive, accessible products.
A guiding rule is to be mindful of the dierent
audiences, expectaons, tasks, and provenance
for your chart, which can aect how you approach
accessibility.
[18]
Consider if your chart is for explanaon
or exploraon; if it’s stac, dynamic, or interacve; and
if there are alternave ways to oer
equivalent representaons.
Applying some of these guidelines will help many
people access and process data visualizaons more
eecvely, although it will help some people more
than others. As a data visualizaon praconer, you
can’t reach perfect accessibility, but you can and
should experiment with making your visualizaons as
useful as possible for as many people as possible. You’ll
be doing good, and doing good is oen good enough.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 29
Chapter Three Notes
[1]
W3C Cognive Accessibility Task Force, World Wide Web Consorum, dra from September 21, 2021, hps://w3c.github.io/coga/user-
research/.
[2]
Ashley M. St. John, Melissa Kibbe, and Amanda R. Tarullo, “A Systemac Assessment of Socioeconomic Status and Execuve Funconing in
Early Childhood,” Journal of Experimental Child Psychology 178 (2019): 352–368. hps://pubmed.ncbi.nlm.nih.gov/30292568/.
[3]
For readability, I’ll use the term “chart” generically to refer to data visualizaons, and I’ll explicitly call out advice diagrams, maps,
infographics, and so on.
[4]
Richard C. Atkinson and Richard M. Shirin, “Human Memory: A Proposed System and Its Control Processes,” in Psychology of Learning
and Movaon volume 2, ed. Kenneth Spence and Janet Taylor Spence (New York: Academic Press, 1968), 89–195.
[5]
John Sweller, “Cognive Load during Problem Solving: Eects on Learning,” Cognive Science 12, no. 2 (1988): 257–285; and John Sweller,
Jeroen J. G. Van Merrienboer, and Fred G. W. C. Paas, “Cognive Architecture and Instruconal Design,” Educaonal Psychology Review 10,
no. 3 (1998): 251–96.
[6]
John Sweller, “Cognive Load Theory, Learning Diculty, and Instruconal Design,” Learning and Instrucon 4, no. 4 (1994): 295–312.
[7]
Richard E Mayer, “Cognive Theory and the Design of Mulmedia Instrucon: An Example of the Two-Way Street between Cognion and
Instrucon,” New Direcons for Teaching and Learning 2002, no. 89 (2002): 55–71.
[8]
See also Joseph R. Jenkins, Daniel C. Neale, and Stanley L. Reno, “Dierenal Memory for Picture and Word Smuli,” Journal of Educaonal
Psychology 58, no. 5 (1967): 303–07.
[9]
Vahan Yoghourdjian, Yalong Yang, Tim Dwyer, Lee Lawrence, Michael Wybrow, and Kim Marrio. “Scalability of Network Visualisaon from
a Cognive Load Perspecve,” IEEE Transacons on Visualizaon and Computer Graphics 27, no. 2 (2020): 1677–87.
[10]
Jordan C. Koone, Chad M. Dashnaw, Emily A. Alonzo, Miguel A. Iglesias, Kelly-Shaye Patero, Juan J. Lopez, Ao Yun Zhang, et al., “Data for
all: Tacle Graphics That Light Up with Picture-Perfect Resoluon,” Science Advances 8, no. 33 (2022).
[11]
see Fizz Studio’s open-source SparkBraille as an example: hps://zzstudio.github.io/sparkbraille/.
[12]
Elizabeth L. Glisky, “Changes in Cognive Funcon in Human Aging,” in Brain Aging: Models, Methods, and Mechanisms, ed. David R.
Riddle (Boca Raton, FL: CRC Press/Taylor & Francis, 2007): 3–20.
[13]
K.N. Purnell, R.T. Sollman, and John Sweller, “The Eects of Technical Illustraons on Cognive Load,” Instruconal Science 20, no. 5–6
(1991): 443–62.
[14]
Brian J. Scholl and Patrice D. Tremoulet, “Perceptual Causality and Animacy,” Trends in Cognive Sciences 4, no. 8 (2000): 299–309.
[15]
George Robertson, Roland Fernandez, Danyel Fisher, Bongshin Lee, and John Stasko. “Eecveness of Animaon in Trend Visualizaon,”
IEEE Transacons on Visualizaon and Computer Graphics 14, no. 6 (2008): 1325–32.
[16]
Kevin S McGrew, “CHC Theory and the Human Cognive Abilies Project: Standing on the Shoulders of the Giants of Psychometric
Intelligence Research,” Intelligence 37, no. 1 (2009): 1–10.
[17]
Steven L. Franconeri, Lace M. Padilla, Pri Shah, Jerey M. Zacks, and Jessica Hullman, “The Science of Visual Data Communicaon: What
Works.” Psychological Science in the Public Interest 22, no. 3 (2021): 110–61.
[18]
See, for example, Jonathan Schwabish, “Beer Data Visualizaons: A Guide for Scholars, Researchers, and Wonks” (New York: Columbia
University Press, 2021).
PART THREE
Alternave (alt) Text
and Screen Readers
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 31
CHAPTER FOUR
Wring Alt Text to
Communicate the
Meaning in Data
Visualizaons
ELIZABETH HARE
Innovave data visualizaon methods are
increasingly found in many kinds of media,
including news websites, government informaon
portals, nancial statements, and scienc
communicaon, frequently with no descripon
for users of screen reading technology.
[1]
And even when alternave texts (alt text)—text descripons
that convey the content and meaning to blind and low-vision
readers—are available, they oen fail to convey the main
takeaways of the data.
[2]
For data visualizaons that are produced as graphic les (e.g., JPGs,
PDFs, and PNGs), alt text needs to be added. These les cannot
be navigated with screen reading soware, and although some
methods of creang data visualizaons can produce readable
elements for screen readers (for example, Visa Chart Components,
SAS Graphics Accelerator, and others reviewed by Elavsky and
colleagues),
[3]
most stascal soware does not produce accessible
charts and graphs. That responsibility falls to the author. Elavsky
and colleagues summarize the situaon well: “Accessibility is sll an
aerthought in data visualizaon.”
[4]
Graphs and charts follow convenons to orient the reader to the
displayed data, including coordinate axes, axis labels, number
labels, legends, and tles. These introduce the variables and their
characteriscs, allowing the reader to comprehend the data points,
trends, and dierences within the graph.
Several models have been proposed for thinking about geng the
informaon in graphs and charts into alt text. This arcle explains
two of those models: Canelón and Hare’s “four-ingredients model”
for wring complete alt texts and the MIT Visualizaon Group’s
“four-level model” for classifying types of informaon from
graphs.
[5]
I describe both models in the following secon and
demonstrate how they are related to one another across a pair of
examples—a simple line chart and a less familiar tree map.
The Four-Ingredients Model
In 2021, Silvia Canelón and I coauthored a study in which we
examined the frequency of alt text inclusion and the completeness
of alt texts for data visualizaons in an online learning community.
[6]
We idened four ingredient quesons necessary for
comprehension of a graph. We based this “ingredients model”
32 DO NO HARM GUIDE
on the verbal descripons of scienc graphs from
sighted colleagues and our personal experience
reading alt texts online. As a result of this work, we
developed four quesons for any data praconer to
ask when thinking about wring alt text.
1. What Kind of Graph or Chart Is It?
Beginning alt text with a descripon of the type of
chart or plot helps the reader ancipate the presented
informaon. Authors use common types of data
visualizaons such as bar charts, scaerplots, line
plots, and pie charts to show trends like the shape of
data, changes over me, a stascal distribuon, or a
comparison of two or more groups. Recent innovaons
in data visualizaon have led to more types of charts,
and these deviaons from more tradional types need
to be described in detail if they contribute to the
meaning of the graph.
[7]
A tree map, for example, is a
square or rectangular graph divided into groups to
illustrate hierarchical part-to-whole relaonships.
[8]
The
tree map below shows the share of people who are
unemployed, divided by two gender and six age
groups. Men are shown in the blue rectangles and
women in the yellow. New and specialized charts and
graphs like tree maps should be described more
extensively than simpler ones, and guidelines for the
descripon of each type should be developed.
In the overall descripon, alt text should also menon
whether the gure is just one plot or a set of mulple
graphs (also known as trellis plots, faceed plots, or
small mulples). Well-organized alt text for a graph
with small mulples would describe the common
aspects of all the graphs rst, then describe each
facet or subplot (with its variable name). When small
mulples are arranged in a grid, start at the upper
le and work across rows as you would when reading
regular text.
2. What Variables Are on the Axes?
When describing the variables in alt text, data analysts
need to keep a couple things in mind. It’s always best
pracce to use the actual variable names that are
present in the chart. Relying on descripons of colors
or textures for idencaon can lead to confusion
or distract from the meaning. Research shows some
people report that keeping track of colors from one
part of alt text to another leads to a dicult cognive
load (see Chapter 3 in this volume).
[9]
Others, however,
would like to form a mental image of the graph as
it appears and appreciate knowing the colors.
[10]
No
maer the preferences of the user, including the
actual variable name and units will lead to beer, more
coherent alt text.
3. What Are the Ranges of the Variables?
As with any chart, the variables present exist over a
limited range. Describing these ranges will provide
an overview of the measurements displayed and
context for understanding the relaonships between
variables. Including the ranges in the alt text also
gives an indicaon of the order of magnitude of the
observaons (e.g., whether they are numbers or
percentages).
4. What Does the Appearance Tell You About the
Relaonships Between the Variables?
To answer ingredient four, data analysts usually
need to answer two important quesons: “Why
am I including this visualizaon in the media I am
creang?”
[11]
and “What are these data saying?”
These answers can lead to a descripon of what the
graph shows about the data, which will vary by chart
type. In a line graph, for example, the descripon
would include whether the line is straight, curved, or
jagged; where maximum and minimum values occur
with respect to the x-axis; and the slope. To describe a
scaerplot, we would indicate whether the distribuon
of points seems even over the whole plot, if there are
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 33
clusters, or if the density of points diers in specic
areas of the plot. Plots of stascal distribuons can
oen be described with reference to the normal curve,
though that will depend on the ancipated knowledge
of the target reader. For graphs that represent
distribuons, we would include the relave size of the
tails, how steep the sides of the curve are, and the
symmetry of the distribuon.
In current pracce, many data visualizaons on the
internet, in social media, or in the scienc literature
do not contain all four ingredients and do not
adequately describe what the graph is showing. We
found that 3 percent of pracce data visualizaons
contained alt text and, of these, only 34 percent
included the answer to this fourth ingredient.
Four-Levels Model
The MIT Visualizaon Group, a team of researchers
working to beer understand how “computaon can
help amplify our cognion and creavity,” recently
analyzed feedback on alt text from blind users. Based
on reader responses, they categorized meaningful
alt text into four levels. These levels are useful for
considering what to include and what to leave out and
oer guidance on alt text automaon and ethics.
[12]
Level 1
The rst and lowest level contains sentences that
describe components “foundaonal to visualizaon
construcon—comprising the elemental properes of
the ‘language’ of graphics.” These components include
the tle, legend, axis names and scales, and chart type
(e.g., scaerplot, line graph, bar chart). At this lowest
level, there is no “synthesizing or interpretaon.”
[13]
The rst three items in the ingredient model described
above are all parts of Level 1.
Level 2
The second level includes stascal facts that are
available from the dataset (e.g., mean, median, range,
maximum, minimum) as well as quantave relaons
(greater than, less than, or equal), and individual data
points. Some of this informaon is available in the
graph, but the rest is obtained from the underlying
dataset.
[14]
The informaon at Level 2 that is available
in the graph is a subset of the fourth ingredient from
the ingredient model.
Level 3
The third level contains “perceptual and cognive
phenomena.” These components of graphs are
idened by inspecng the data and idenfying the
trends, outliers, or paerns. This level of informaon
relies on the cognion of the reader and may be more
complex than informaon at Levels 1 and 2. These
elements may not be readily observed by reading
raw data points, summary tables, stascs, or other
nonvisual data summaries. The essenal meaning of
the data visualizaon is found at this cognive and
perceptual level of descripon. Level 3, like Level 2, is
part of the fourth ingredient of the ingredient model.
Level 4
The fourth and highest level contains informaon
(or opinions) based on contextual or domain-specic
knowledge. The examples given rely on knowledge
from outside the graph and make assumpons about
causaon.
[15]
Level 4 content is not considered part
of the ingredient model, which priorizes objecve
reporng of the chart over subjecve interpretaons
of applicaon. This subjecve informaon from
outside the graph should not be included in alt text.
Blind readers want the informaon and trends but not
extra opinion or interpretaon.
[16]
For example, if you
think you know the reason for the change in slope of a
graph, don’t include it in the alt text. It should only be
included if it is a printed annotaon on the graph.
Comparing the Two Models
The two models I’ve described do not perfectly align,
but both oer useful ways to think about wring alt
text and graph descripons. On the next page, I’ve
mapped the four items (ingredients) from the Canelón
and Hare model onto the Lundgard and Satyanarayan
(levels) model. The rst three ingredients from Canelón
and Hare map to the rst level in the Lundgard and
Satyanarayan model, while the fourth ingredient maps
to the second and third levels.
34 DO NO HARM GUIDE
To show how the two models can dier, let’s dive into
two examples. First, we have a fairly basic line chart of
the monthly unemployment rate in the US from
January 1950 to June 2022. Most readers should
recognize a line chart, so we can use less alt text to
describe it. The table on the next page shows how
dierent versions of the alt text correlate to the
various pieces of the two models (in this report, the
graph itself uses all four cells as the alt text).
The second example also uses unemployment rate
data but uses the less familiar tree map format. Here,
we focus on the share of people who were
unemployed in June 2022 grouped into two gender
and six age groups. In this case, the rst stage of each
model includes a more detailed explanaon of the tree
map and how it is organized.
Length and Completeness of Alt Texts
Ideally, alt text should be just long enough to describe
what the graph is illustrang visually. Although many
guidelines priorize brevity,
[17]
most alt texts are
incomplete and leave users with quesons.
These brief alt texts provide inadequate insight into
what the data are communicang. Many guidelines
suggest using one or two sentences, but doing this
can lead to alt texts for data visualizaon containing
only one item from Level 1 (e.g., a tle or capon)
with no Level 2 or Level 3 informaon. Alt texts
should be long enough to include essenal Level 2
and Level 3 informaon.
To keep alt text succinct and comprehensible, avoid
including decoraons or “chartjunk”
[18]
such as
unnecessary gridlines, repeve display of data, visual
eects like shadows on bar graphs, or shimmering
elements. These details do not add to the meaning of
the data being displayed.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 35
Four
Ingredients
model
Four Levels
model Example alt text
Line Chart
1 1 This graph contains a blue line showing monthly unemployment rates in the
US and gray vercal bars showing recessions. The source of the data is the
Bureau of Labor Stascs and the Naonal Bureau of Economic Research.
2 and 3 1 The x-axis shows the month and year from January 1950 to June 2022.
The y-axis shows the unemployment rate with a range of 0 to 16 percent.
The bars extend along the enre vercal area and correspond to the 11
recessions since 1950. The unemployment rose from 4.4 percent in March
2020 to 14.7 percent in April 2020, a 10.3 percentage point change.
The second-highest change was a 1.3 percentage-point change between
September and October 1949.
4 2 and 3 The unemployment rate line typically slopes upward during recessions,
though not always, and it starts to move upward before recessions begin.
The longest gap between recessions was from July 2009 to January 2020, a
total of 120 months.
4 The largest month-over-month increase in the unemployment rate during
this period occurred during the most recent recession in spring 2020,
resulng from the COVID-19 pandemic.
Tree Map
1 1 A tree map, which is a series of squares and rectangles arranged inside a
larger rectangle, describing the share of people unemployed by gender
and age group in June 2022. Men are shown in a set of six blue boxes and
women in six yellow boxes.
2 and 3 2 There are 12 boxes for each combinaon of gender and age, where gender
is male or female and age is 16 to 19, 20 to 24, 25 to 34, 35 to 44, 45 to 54,
and 55 and older. The percentages range from 6 percent for 16- to 19-year-
old men to 11.5 percent for 25- to 34-year-old men.
4 3 Men account for a larger share of unemployed people than women, but
the dierence is barely percepble. In June 2022, men accounted for 53
percent of all unemployed workers, though women account for a slightly
larger share of the enre populaon.
4 Although men between the ages of 25 and 34 have the highest
unemployment rate at 11.5 percent, women ages 35 to 44 have the
second-highest unemployment rate at 10 percent, possibly reecng
dierenal changes in the labor market as it recovers from the
COVID-19 pandemic.
36 DO NO HARM GUIDE
The context of the graphic will also inuence the
length of the alt text. A busy graph tracking a lot of
variables will need more alt text than a simple line
graph of two variables, and a graph in a scienc
journal may need a more detailed descripon than
one meant for a general audience. Authors should
be aware of “the curse of knowledge,” which is the
tendency for experts to priorize elements of graphs
they nd important compared with nonexperts’
descripons.
[19]
In many contexts, such as educaon
and science publicaons, a reader needs to have
complete informaon in order to independently
priorize the displayed informaon.
Automac Alt Text
With the rise of machine learning and arcial
intelligence methods, automac tools to produce alt
text have also proliferated, but these methods always
produce inadequate alt text. Whether these alt texts
are generated by mining stascal code, by scanning a
graphics le, or through arcial intelligence methods,
informaon at Level 3 and the fourth ingredient will
not be included. Without this informaon, the reader
has to invest me building a mental framework for
understanding the graph, possibly with elements
from a tle or variable names, but the alt text doesn’t
provide the graph’s takeaway message. When the
reader starts to hear the tle and variable names, they
don’t realize the automac alt text won’t tell them
the point of the graphic. If automacally generated alt
text is used, it must be edited to include the Level 3
informaon about what the graph shows, otherwise it
will be ineecve and frustrang to the reader.
Lundgard and Satyanarayan examined whether
machine learning or arcial intelligence
methods can produce the four levels of graphic
informaon.
[20]
Although the Level 1 elements
such as chart type, tle, and axis labels are oen
readily extracted, only the visible poron of Level
2 informaon emerges from a machine learning
approach. Informaon about Level 3, which provides
the “‘overall gist’ of complex trends and paerns,” and
Level 4—which requires human percepon, cognion,
and interpretaon—cannot be provided automacally.
Because current automac methods cannot produce
alt text describing Level 3 informaon, they cannot
produce alt text that provides meaningful access to
blind readers.
For the foreseeable future, automac alt texts will be
incomplete. They can be used as a starng point if they
provide useful Level 1 and 2 informaon, but these
paral alt texts should be avoided altogether or edited
to add Level 2 and 3 informaon. Alt texts that provide
only the scaolding without informaon about the
building are frustrang and unhelpful. These paral alt
text snippets are not “beer than nothing” because the
reader has invested me to build a mental model to
understand the graph but never receives the
crical informaon.
Recommendaons
In addion to wring clear, informave alt text,
authors can improve accessibility in many ways,
including providing supplementary materials, such
as the data behind a visualizaon, separate from the
actual report or website. A new package for the R
programming language,
[21]
ggdatasaver, facilitates
saving the dataset associated with data visualizaons
created with the ggplot package.
[22]
Providing the raw
data and tabulated summaries allows screen reader
users to explore the data in a more accessible (though
possibly less useful) format (see Chapter 5). When
data are presented as maps, content producers
should consider including a table as well (one useful
example would be data on COVID-19 incidence by
zip code). Including the table will provide access to
the variables shown on the map but will not provide
informaon on the spaal relaonships between the
geographical units.
In other contexts, supplementary materials are crical
as the digital infrastructure to provide alt text is sll
missing. One study found that in an analysis of 300
open-science journals, there was nothing about alt
text in their guidelines for authors.
[23]
Most academic
publishing systems have no infrastructure to include
alt text along with images. One workaround opon is
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 37
to provide full informaon on the displayed variables,
trends, and paerns in the results and discussion
secons of papers; another is to provide alt text as
supplemental informaon that can be downloaded
from the journal website.
Many social media plaorms have infrastructure
for alt text. On some plaorms, alt text has a low
character limit. In these situaons, consider placing
alt text in comments or replies and including a
statement like “image descripon in comments” in
the main body of posts.
Recognizing that all observers have some inevitable
bias, alt text descripons of data visualizaons should
present data as objecvely as possible. Jung and
colleagues report that blind users prefer that alt texts
not use judgements of how large dierences are.
[24]
Readers do not want “subjecve interpretaons” or
contextual informaon, and they do not want the
author’s opinion.
[25]
If a graph shows uncertainty,
describe it. If numbers need to be esmated, state
that. Do not conate correlaon of two variables with
causaon. General consideraons around alt text,
including punctuaon and mathemacal symbols, are
explored in the box on the next page (and see Chapter
8 of this volume).
In their work on arcial intelligence for object
recognion for blind people, Benne and Keyes point
out that these descripons are likely to replicate the
biases of human observers and programmers.
[26]
But
informaon from computers is oen put on a
pedestal and assumed to be correct. Whether the
describer is human or arcial, a power dierenal
between the describer and reader exists, which
authors should consider.
Ulmately, wring eecve, complete alt text is
an important skill for authors to master in order to
communicate the meaning of their data. With current
limitaons inherent with screen readers, machine
learning, and arcial intelligence, this skill will
remain necessary for the near future. Good alt texts
should create a mental framework for the variables
and quanes shown, include informaon about the
paerns found in the data, and tell a user why you
chose to include the data visualizaon. Although many
guidelines emphasize brevity, completeness is crical
for equal access to informaon. If media infrastructure
does not support alt text, data praconers must nd
a way to provide it.
Strategies for Wring Good Alt Text
Alt text should provide meaningful
informaon to the user. Of course, what
is meaningful to one user may not be
meaningful to another user, so there is not a
single right answer to wring good alt text.
You may even noce that the alt text in this
report varies from chapter to chapter and
author to author.
Generally speaking, alt text should be wrien
with the same punctuaon and capitalizaon
as regular text, but again, that also will
depend on the user and how the user has set
up their screen reader.
Punctuaon marks like periods, commas,
and dashes inform the way the screen
reader uses intonaon and pauses to
simulate natural speech, which can improve
comprehension but can be problemac in
certain cases. Unlike with regular text, it’s not
possible to navigate by word or by character
to clarify what’s being said, so it’s important
to make sure the alt text can be read clearly.
There are some key aspects of alt text to
consider, especially when it applies to
data visualizaon:
•
Describe the meaningful aspects of the
graph, chart, or diagram. Tell the user the
most important feature of the image and
what they should take away from it. Provide
enough context about the type of graph,
variables, and quanes for the reader to
understand the takeaways.
38 DO NO HARM GUIDE
•
Contain some measure of quantave data
if the gure does as well. If there is a specic
data point or two you want to highlight,
include it in the alt text.
•
Remain brief and to the point. If you need
to describe every data point, then provide
an alternave format, such as a table or long
descripon, in the appendix or elsewhere.
•
Limit the amount of symbols, such as
vercal bars (or “pipes”), slashes, colons, and
semicolons, as well as em dashes and en
dashes. These symbols are voiced by screen
readers and add to the audio noise during the
voicing of the alt text. Commas are usually
voiced as short pauses and periods as long
pauses, and many screen readers will vocalize
dashes, colons, and semicolons. Wring “x
divided by y” will be clearer than wring “x/y”
because the slash also has a nonmathemacal
meaning.
•
Limit the use of URLs because they are not
acvatable in alt text. If you must use them,
spelling out “dot com” will help denote
the URL.
•
Capitalizing acronyms will usually force text
to be read leer by leer (unless they are
commonly known ones that are pronounced
as words), but wring them in lowercase will
usually lead to them being pronounced as
words. If the alt text includes “ui” instead of
“UI,” most screen readers will try to pronounce
the two vowels as a word, which will certainly
sound weird.
•
Avoid repeang chart tles. If the tle is
available somewhere else in the text that a
screen reader will read aloud, it shouldn’t be
repeated in the alt text. (This advice diers
for an image on social media, where the tle
is part of the image.) More generally, you
can just tell the reader what the chart tle
is. The alt text for a line chart showing the
unemployment rate might say, “A bar chart
that shows the unemployment rate over me
with the tle, Unemployment Rate in the
United States from 1950 to 2020.” In this
case, the phrase “with the tle” and the
exisng punctuaon makes the tle clear. If
you wanted to omit the words “with the tle”
to save characters, quotaon marks around
the actual chart tle might be useful. In this
way, the reader could check to see if the
phrase was the actual tle or a descripon
of the chart.
Ulmately, write alt text like you would write
normal text. Screen readers are opmized for
exisng text paerns and expect alt text to
be wrien in those forms. Users can control
how much punctuaon marks are spoken,
but the specics of that funconality will
vary by tool and plaorm. Other guidelines
for wring data visualizaon alt-texts are
the DIAGRAM Center Image Descripon
Guidelines and WGBH’s Guidelines for
Describing STEM Images.
[27]
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 39
Chapter Four Notes
[1]
Crescena Jung, Shubham Mehta, Atharva Kulkarni, Yuhang Zhao, and Yea-Seul Kim, “Communicang Visualizaons without Visuals:
Invesgaon of Visualizaon Alternave Text for People with Visual Impairments,” IEEE Transacons on Visualizaon and Computer Graphics
28, no. 1 (2021): 1095–105; and Jay Wickard, “Is Accessibility Part of “Open” Science?,” Praccal Data Management for Bug Counters
(WordPress blog), July 13, 2021, hps://praccaldatamanagement.wordpress.com/2021/07/13/is-accessibility-part-of-open-science/
[2]
Jung et al., “Communicang Visualizaons without Visuals”; Silvia Canelón and Liz Hare, “Revealing Room for Improvement in Accessibility
within a Social Media Data Visualizaon Learning Community,” presentaon given at csv,conf,v6 (virtual conference), May 4, 2021 hps://
github.com/spcanelon/csvConf2021.
[3]
Frank Elavsky, Cynthia Benne, and Dominik Moritz, “How Accessible Is My Visualizaon? Evaluang Visualizaon Accessibility
with Chartability,” EuroGraphics Conference on Visualizaon (EuroVis) 41, no. 3 (2022), hps://www.frank.computer/chartability/#ref-
USImproving.
[4]
Elavsky, Benne, and Moritz, “How Accessible Is My Visualizaon?”
[5]
Canelón and Hare, “Revealing Room for Improvement in Accessibility within a Social Media Data Visualizaon Learning Community”;
and Alan Lundgard and Arvind Satyanarayan, “Accessible Visualizaon via Natural Language Descripons: A Four-Level Model of Semanc
Content,” IEEE Transacons on Visualizaon and Computer Graphics 28, no. 1 (2021): 1073–83.
[6]
Canelón and Hare, “Revealing Room for Improvement in Accessibility within a Social Media Data Visualizaon Learning Community”
[7]
Jonathan Schwabish, Beer Data Visualizaons: A Guide for Scholars, Researchers, and Wonks (New York: Columbia University Press,
2021).
[8]
Ben Shneiderman, “Tree Visualizaon with Tree-Maps: 2-d Space-Filling Approach,” ACM Transacons on Graphics (TOG) 11, no. 1 (1992):
92–99.
[9]
See also Lundgard and Satyanarayan, “Accessible Visualizaon via Natural Language Descripons: A Four-Level Model of Semanc
Content.”
[10]
Jung et al., “Communicang Visualizaons without Visuals.”
[11]
Amy Cesal, “Wring Alt-Text for Data Visualizaon,” Nighngale Journal of the Data Visualizaon Society, July 23, 2020, hps://medium.
com/nighngale/wring-alt-text-for-data-visualizaon-2a218ef43f81.
[12]
Lundgard and Satyanarayan, “Accessible Visualizaon via Natural Language Descripons: A Four-Level Model of Semanc Content.”
[13]
Lundgard and Satyanarayan, “Accessible Visualizaon via Natural Language Descripons: A Four-Level Model of Semanc Content.”
[14]
Lundgard and Satyanarayan, “Accessible Visualizaon via Natural Language Descripons: A Four-Level Model of Semanc Content.”
[15]
Lundgard and Satyanarayan, “Accessible Visualizaon via Natural Language Descripons: A Four-Level Model of Semanc Content.”
[16]
Lundgard and Satyanarayan, “Accessible Visualizaon via Natural Language Descripons: A Four-Level Model of Semanc Content”; and
Jung et al., “Communicang Visualizaons without Visuals.”
[17]
See “General Guidelines,” Diagram Center, accessed October 21, 2022; “Guidelines for Describing STEM Images,” WGBH.org (Boston
radio), accessed October 21, 2022, hps://www.wgbh.org/foundaon/ncam/guidelines/guidelines-for-describing-stem-images; and Cesal,
“Wring Alt-Text for Data Visualizaon,”
[18]
Edward R. Tue, The Visual Display of Quantave Informaon (Cheshire, CT: Graphics Press, 2001).
[19]
Cindy Xiong, Lisanne Van Veelden, and Steven Franconeri, “The Curse of Knowledge in Visual Data Communicaon,” IEEE Transacons on
Visualizaons and Computer Graphics 26, no. 10 (2019): 2051–3062.
[20]
Lundgard and Satyanarayan, “Accessible Visualizaon via Natural Language Descripons: A Four-Level Model of Semanc Content.”
[21]
See hps://www.R-project.org/.
[22]
Elio Campitelli (eliocamp), “ggdatasaver: Automacally Save Data Associated with a ‘ggplot2’ Plot,” Github repository, last updated October
6, 2022, hps://github.com/eliocamp/ggdatasaver; see also Hadley Wickham, “ggplot2: Elegant Graphics for Data Analysis, Second Edion”
(Berlin: Springer Nature, 2016).
[22]
Wickard, “Is Accessibility Part of “Open” Science?”
[23]
Jung et al., “Communicang Visualizaons without Visuals.”
[24]
Lundgard and Satyanarayan, “Accessible Visualizaon via Natural Language Descripons: A Four-Level Model of Semanc Content.”
[25]
Cynthia L. Benne, and Os Keyes, “What Is the Point of Fairness? Disability, AI, and the Complexity of Jusce,” SIGAccess newsleer 125,
October 2019, hp://www.sigaccess.org/newsleer/2019-10/bennet.html
[26]
See hp://diagramcenter.org/ and “Guidelines for Describing STEM Images,” WGBH.org (Boston radio), accessed October 21, 2022,
hps://www.wgbh.org/foundaon/ncam/guidelines/guidelines-for-describing-stem-images.
40 DO NO HARM GUIDE
CHAPTER FIVE
Coding
Accessible Data
Visualisaons
LÉONIE WATSON
We visualize data because it is oen easier
to understand in the form of charts and graphs,
but what happens when someone who cannot
see encounters a data visualizaon? The secret
to making data visualizaons accessible
for blind people and people who use screen
readers is creang an alternave representaon
of the data.
We can do so by making a few addions to the code used
to create web pages, content, and web applicaons. This
supplementary code is known as Accessible Rich Internet
Applicaons, or ARIA—a set of roles and aributes that dene
ways to make the code more accessible to people who use
screen readers.
Unlike most chapters in this Do No Harm Guide, this chapter
will consist of several code snippets that demonstrate how
ARIA code can be added to exisng web page code to make it
more accessible. My goal is to demonstrate that like any coding
language or library, using ARIA requires understanding syntax and
implementaon and how to modify exisng code as well as wring
new code. Creang a more inclusive and accessible web should
not be a tremendous burden, especially for readers already familiar
with wring code.
Why Code Is Important
Imagine a door with a sign that says “kitchen.” The door is closed,
and it has a metal plate running down one side. You may not
realize it, but you already know a lot of informaon about this
door. You recognize it’s a door because you’ve seen one before,
you know its purpose is to let you move from one room into
another, and you recognize that despite the door being closed, you
can open it by pushing against it and end up in the kitchen, not
some other room. In other words, the visual characteriscs of the
door tell you what it is, what it’s for, if it’s the door you want, and
how to use it.
Let’s transfer this process to the web. This me, imagine a buon
with the word “Search” as its label. You recognize it is a buon
because you’ve seen buons before, you know it will execute a
search when you acvate it, and you know you can click on it with
your mouse, tap it with a nger, or use the Space or Enter keys to
make it work.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 41
But what happens if you can’t see the buon? In
that case, you need something else to give you the
informaon you need. This is where the code behind
a data visualizaon is important for data accessibility.
For the buon, you’ll need the browser and your
screen reader (see also Chapters 4 and 6) to interact
and present all that informaon in the code you use to
build a web page and its content.
HyperText Markup Language, or HTML, is the
programming language web developers use to
structure web pages and their content, and that
language has a lot of accessibility informaon built
in. We use the words “role,” “name,” and “state” to
describe these built-in features and to assign them
to elements on the web. Most HTML elements have
“roles” that describe their purpose: an <img> element—
which is used to embed an image on an HTML page—
has the role of “graphic.” Many HTML elements can
be given a “name” (somemes called an “accessible
name”). A buon on a webpage, for example, can be
dened by text inside the <buon> element. Some
HTML elements also have “aributes” that describe
their state, like the checked aribute that can be used
to indicate when a radio buon has been selected. If
the checked aribute is present, the radio buon will
be selected, and if it is not present, the radio buon
remains unselected.
When a document created with HTML is loaded
in the browser, the browser puts all the accessibility
informaon into a structure known as an “accessibility
tree.” When someone using a screen reader goes to
the HTML document in their browser, their screen
reader asks the browser for the available accessibility
informaon about what’s on screen and uses that
informaon to let the user know what they’re
dealing with.
Unfortunately, this does not work so well with what
are called scalable vector graphics, or SVGs. When it
comes to the web, SVG images are useful because the
images will maintain their resoluon no maer the size
of the screen, from a phone to a tablet to a
huge monitor.
Understanding SVG Images
Images on the computer can come in various
le formats, like PNG and JPEG. Those two
types are examples of raster les, which
are based on pixels or small squares. When
increasing the size of a picture saved as a
JPEG le, for example, the squares get bigger
and bigger. At some point, the image may
become grainy and blurry because there
aren’t enough squares in the picture to give
our eyes the illusion of smoothness. On the
other hand, SVG images are vector les,
which store images based on mathemacal
formulas and use points and lines on a
grid. As you make an SVG image larger, the
formula updates and the clarity of the image
is preserved.
Although SVG elements have built-in accessibility
informaon that is recognized by browsers,
screen readers generally do not ulize it. But data
visualizaons commonly use SVGs, so we have to take
maers into our own hands if we want our data to be
accessible to people who cannot see them.
To make SVG images accessible, we use ARIA to add
accessibility informaon ourselves. ARIA, which is
a web standard created by the World Wide Web
Consorum, can dene roles and other accessibility
properes to HTML or SVG elements on a web page.
Let’s see how ARIA works for SVG images. We start by
wring some SVG code to draw a buon. This code
creates a rectangle that will have the word “Play” as
the tle. This rectangle will be 75 pixels wide and 50
pixels tall, and it will have a purple ll and a green
border the width of one pixel.
42 DO NO HARM GUIDE
<svg version=“1.1”>
<rect width=“75” height=“50” rx=“20”
ry=“20” fill=“#AC4FC6” stroke=“#228b22”
stroke-fill=“1”>
<title>Play</title>
</rect>
</svg>
We can use the ARIA role aribute to explicitly give
this rectangle the role of a buon. The only change in
this code snippet from the original is the addion of
<role=”buon”>.
<svg version=“1.1”>
<rect role=“button” width=“75”
height=“50” rx=“20” ry=“20”
fill=“#AC4FC6” stroke=“#228b22”
stroke-fill=“1”>
<title>Play</title>
</rect>
</svg>
Since a buon is supposed to be interacve—clicked
with a mouse or tapped with a nger—we need to
make sure that keyboard users (including screen
reader users) who may not be able to use a mouse can
focus on it with the Tab key. To do this, we use the
<tabindex> aribute (<tabindex=”0”>), which allows
users to select the buon by pressing the Tab key.
<svg version=“1.1”>
<rect role=“button” tabindex=“0”
width=“75” height=“50” rx=“20” ry=“20”
fill=“#AC4FC6” stroke=“#228b22” stroke-
fill=“1”>
<title>Play</title>
</rect>
</svg>
If the purpose of the buon is to turn something on
or o or to start or stop something, we could also use
the <aria-pressed> aribute to show its state. To show
the user that the “Play” buon has been pressed, we
can add the <aria-pressed=”true”> code to the exisng
snippet. At rst the aribute would have a value of
“false” to indicate the buon is not pressed, then it
would update to “true” to indicate that the buon has
been pressed:
<svg version=“1.1”>
<rect role=“button” tabindex=“0” aria-
pressed=“true” width=“75” height=“50”
rx=“20” ry=“20” fill=“#AC4FC6”
stroke=“#228b22” stroke-fill=“1”>
<title>Play</title>
</rect>
</svg>
The changes we’ve made so far only apply to making
the visual aspect of the buon accessible to screen
readers. To make this SVG buon fully interacve, we
have to use JavaScript to provide support for mouse
and keyboard interacon so the buon can funcon as
expected.
Dening the Data Structure
Now let’s discuss how ARIA can be applied to data
visualizaons. When it comes to data structures, ARIA
is not equipped for anything more sophiscated than
bar charts, line graphs, or owcharts. In other
words, data that can be represented as simple
tables or list structures.
Consider this simple line graph showing the average
number of cups of tea had by people at dierent mes
of the day. The x-axis shows the dierent mes of day,
the y-axis shows a range of cups from 0 to 10 in
increments of 5, and there are two lines that show
how much tea Alice and Bob drank.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 43
Visually, you might scan along the x-axis to nd a me
of day, then look up to nd out how many cups of
tea Alice drank. To put it another way, you might look
along a row of data (i.e., the me of day), then up a
column (i.e., the person) to get the data you want.
Yes, you guessed it, a line graph can be represented
as a table.
For the data in the line graph to make sense as a
table—and readable for the screen reader as a result—
we have to rearrange it so the rows represent Alice
and Bob, the columns represent the dierent mes of
day, and the table cells contain the number of cups of
tea that each person drank. Visually, the table will look
like this:
Person
AernoonMorning
Alice 5 10
Bob 2 0
First, we use a <g> element in the HTML code to
represent the enre table.
<g></g>
Then we need to nest three more <g> elements inside
it to represent the rows, one for the column headers,
one for Alice, and one for Bob:
We need to explicitly dene the cells inside the table,
which we can do by adding more <g> elements. In this
case, we will end up with three rows and three
columns—thus, three cells in each row.
We can then use the ARIA role aribute with
dierent values to let browsers and screen readers
know the purpose of the dierent <g> elements.
Noce here that the ARIA role aributes dene the
overall table structure.
<g role=“table”>
<g role=“row”>
<g></g>
<g role=“columnheader”></g>
<g role=“columnheader”></g>
</g>
<g role=“row”>
<g role=“rowheader”></g>
<g role=“cell”></g>
<g role=“cell”></g>
</g>
<g role=“row”>
<g role=“rowheader”></g>
<g role=“cell”></g>
<g role=“cell”></g>
</g>
</g>
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 43
Visually, you might scan along the x-axis to nd a me
of day, then look up to nd out how many cups of
tea Alice drank. To put it another way, you might look
along a row of data (i.e., the me of day), then up a
column (i.e., the person) to get the data you want.
Yes, you guessed it, a line graph can be represented
as a table.
For the data in the line graph to make sense as a
table—and readable for the screen reader as a result—
we have to rearrange it so the rows represent Alice
and Bob, the columns represent the dierent mes of
day, and the table cells contain the number of cups of
tea that each person drank. Visually, the table will look
like this:
Morning Aernoon
Alice 5 10
Bob 2 0
First, we use a <g> element in the HTML code to
represent the enre table.
<g></g>
Then we need to nest three more <g> elements inside
it to represent the rows, one for the column headers,
one for Alice, and one for Bob:
<g>
<g></g>
<g></g>
<g></g>
</g>
We need to explicitly dene the cells inside the table,
which we can do by adding more <g> elements. In
this case, we will end up with three rows and three
columns—thus, three cells in each row.
<g>
<g>
<g></g>
<g></g>
<g></g>
</g>
<g>
<g></g>
<g></g>
<g></g>
</g>
<g>
<g></g>
<g></g>
<g></g>
</g>
</g>
We can then use the ARIA role aribute with
dierent values to let browsers and screen readers
know the purpose of the dierent <g> elements.
Noce here that the ARIA role aributes dene the
overall table structure.
<g role=“table”>
<g role=“row”>
<g></g>
<g role=“columnheader”></g>
<g role=“columnheader”></g>
</g>
<g role=“row”>
<g role=“rowheader”></g>
<g role=“cell”></g>
<g role=“cell”></g>
</g>
<g role=“row”>
<g role=“rowheader”></g>
<g role=“cell”></g>
<g role=“cell”></g>
</g>
</g>
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 43
Visually, you might scan along the x-axis to nd a me
of day, then look up to nd out how many cups of
tea Alice drank. To put it another way, you might look
along a row of data (i.e., the me of day), then up a
column (i.e., the person) to get the data you want.
Yes, you guessed it, a line graph can be represented
as a table.
For the data in the line graph to make sense as a
table—and readable for the screen reader as a result—
we have to rearrange it so the rows represent Alice
and Bob, the columns represent the dierent mes of
day, and the table cells contain the number of cups of
tea that each person drank. Visually, the table will look
like this:
Morning Aernoon
Alice 5 10
Bob 2 0
First, we use a <g> element in the HTML code to
represent the enre table.
<g></g>
Then we need to nest three more <g> elements inside
it to represent the rows, one for the column headers,
one for Alice, and one for Bob:
<g>
<g></g>
<g></g>
<g></g>
</g>
We need to explicitly dene the cells inside the table,
which we can do by adding more <g> elements. In
this case, we will end up with three rows and three
columns—thus, three cells in each row.
<g>
<g>
<g></g>
<g></g>
<g></g>
</g>
<g>
<g></g>
<g></g>
<g></g>
</g>
<g>
<g></g>
<g></g>
<g></g>
</g>
</g>
We can then use the ARIA role aribute with
dierent values to let browsers and screen readers
know the purpose of the dierent <g> elements.
Noce here that the ARIA role aributes dene the
overall table structure.
<g role=“table”>
<g role=“row”>
<g></g>
<g role=“columnheader”></g>
<g role=“columnheader”></g>
</g>
<g role=“row”>
<g role=“rowheader”></g>
<g role=“cell”></g>
<g role=“cell”></g>
</g>
<g role=“row”>
<g role=“rowheader”></g>
<g role=“cell”></g>
<g role=“cell”></g>
</g>
</g>
44 DO NO HARM GUIDE
Idenfying Parts of the Visualisaon
With the basic data structure in place with the
appropriate roles, we can turn our aenon to the
next piece of accessibility informaon—an element’s
name or accessible name. Here, we begin adding the
data to the structure.
We’ll start with the informaon on the x-axis, the
dierent mes of day. We want this informaon to
appear visually on the graph and to be accessible to
screen reader users, so the <text> element is a good
choice. We’ll add this to the rst row of the table.
<g role=“row”>
<g></g>
<g role=“columnheader”>
<text>Morning</text>
</g>
<g role=“columnheader”>
<text>Afternoon</text>
</g>
</g>
Think back to the door you imagined at the start of
this chapter. Perhaps you pictured it as a wooden door
with green paint and a sign in a bold font, or maybe
you saw a neutral-colored door with a discrete sign.
Whatever colour or sign type, it was sll a door and
that informaon let you make reasonable deducons
about what it was for and how to use it. It’s the same
with our line graph. To a blind person, it doesn’t
maer how the data look; it only maers that they can
idenfy what the data are and what the data’s purpose
is so they can make some reasonable deducons
about what to do with the data.
In other words, we’re pung in place an invisible
structure that will be meaningful to someone who
cannot see the line graph, then layering the visual
representaon of the data over the top.
The most likely SVG element for adding the lines to
the graph is the <path> element. For the purposes
of making our line graph accessible to screen reader
users, the <path> elements are going to do double
duty. They’re going to represent the visible lines on
the graph that everyone will see, and they’re going to
be the content of the le-most cell in each row of our
table structure for screen reader users.
Let’s start by adding a <path> element to the rst cell
in the next row of our table data structure:
<g role=“row”>
<g role=“rowheader”><path></path></g>
<g role=“cell”></g>
<g role=“cell”></g>
</g>
Next, we need to give the <path> element an
accessible name so screen reader users know what the
line represents. We can do so with the <tle> element.
(The highlighted text shows the new code we’ve added
to the inial code block.)
<g role=“row”>
<g role=“rowheader”>
<path>
<title>Alice</title>
</path>
</g>
<g role=“cell”></g>
<g role=“cell”></g>
</g>
Now, we need to make the screen reader think that
the <path> element is actually an image, so we add
<path role=”img”> to this bit of code.
<g role=“row”>
<g role=“rowheader”>
<path role=“img”>
<title>Alice</title>
</path>
</g>
<g role=“cell”></g>
<g role=“cell”></g>
</g>
Within our code, we want to plot some points along
each line so that screen reader users can know the
specic data points. By doing so, we create the
content for the cells in our table structure. Given that
in our chart, the data is just ploed as a line, and as
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 45
such, each point has the same visual appearance, we
need a common paern to dene the plot marker
only once. Then, we can duplicate it using the <use>
element. We use the same techniques as before
to give each <use> element the “img” role and an
accessible name using the <tle> element, so the
ploed points are accessible to screen reader users.
Again, we are just adding a few short lines of code
here, highlighted in yellow.
<g role=“row”>
<g role=“rowheader”>
<path role=“img”>
<title>Alice</title>
</path>
</g>
<g role=“cell”>
<use role=“img”>
<title>5 cups</title>
</use>
</g>
<g role=“cell”>
<use role=“img”>
<title>10 cups</title>
</use>
</g>
</g>
These code examples are intenonally simplied for
readability, but the <path> and <use> elements can
be made to give the lines on the graph the visual
representaon you want. By adding the role and name
informaon, we’ve created a table structure that a
screen reader user can navigate by moving up and
down through columns or le and right through rows,
allowing them to obtain the same data as someone
who is able to see the lines on the graph.
Hiding Unwanted Content
The invisible table structure we’ve put in place
has all the informaon a screen reader user needs
to make sense of the data, but there are other
elements we need for the line graph to make sense
visually. Although the y-axis isn’t needed in the table
representaon of the data, we do need it visually.
To avoid screen reader users hearing the same
informaon twice, we can use a lile bit more ARIA.
Suppose the y-axis will be represented using another
<g> element. To hide it and all its content from screen
reader users, we can use the <aria-hidden> aribute,
like this:
<g aria-hidden=“true”></g>
This same technique can be used to hide any other
visual aspects of the line graph that would otherwise
hinder screen reader users. Be careful with this
technique, though. When you use <aria-hidden>,
everything inside that element will be hidden from
screen readers, so make sure you apply it thoughully
to your code. You should never use <aria-hidden> to
hide an element that is intended to be interacve.
If we put all the addions to our SVG code together,
the basic code for our ARIA enhanced line graph looks
like this:
<g role=“table”>
<g role=“row”>
<g role=“columnheader”>
<text>Morning</text>
</g>
<g role=“columnheader”>
<text>Afternoon</text>
</g>
</g>
<g role=“row”>
<g role=“rowheader”>
<path role=“img”>
<title>Alice</title>
</path>
</g>
<g role=“cell”>
<use role=“img”>
<title>5 cups</title>
</use>
</g>
<g role=“cell”>
<use role=“img”>
<title>10 cups</title>
</use>
</g>
</g>
46 DO NO HARM GUIDE
<g role=“row”>
<g role=“rowheader”>
<path role=“img”>
<title>Bob</title>
</path>
</g>
<g role=“cell”>
<use role=“img”>
<title>2 cups</title>
</use>
</g>
<g role=“cell”>
<use role=“img”>
<title>0 cups</title>
</use>
</g>
</g>
Animang Informaon
You may want to make your line graph more
interesng by adding a bit of animaon. The graph
could inially appear to be empty, then at the press of
a buon, animated lines could plot themselves along
the x- and y-axes.
Visually this would most likely be done using
Cascading Style Sheets (CSS), which are used to
describe a webpage’s visual characteriscs, such as
colors, layouts, and fonts. To add animaon through
CSS and to make it accessible to screen reader users,
we just need a lile more ARIA. But rst, we need to
make sure the trigger for the animaon is accessible to
everyone. For that, we can reuse the SVG buon
from earlier.
<rect role=“button” tabindex=“0” aria
pressed=“false” width=“75” height=“50” rx=“20”
ry=“20” fill=“#AC4FC6” stroke=“#228b22”
stroke-fill=“1”>
<title>Animate graph</title>
</rect>
When the buon has not yet been pressed, the <aria-
pressed> aribute should have its value set to “false.”
For the animaon itself, we need to create something
known as a “live region”:
<g aria-live=“assertive”></g>
A live region is a bit like a push nocaon for screen
readers. As the content inside the live region is
updated, screen readers will automacally announce it
to the user. In this case, we want the announcement
to happen right away, so we set the aria-live aribute
to “asserve.”
When the buon is acvated and the animaon
starts, the <aria-pressed> aribute is set to “true” to
show that the buon has been pressed and a short
descripon of the animaon is read into the live
region. The descripon could be something like
the following:
<g aria-live=“assertive”>
Alice drinks five cups of tea in the morning,
and 10 cups in the afternoon. Bob drinks...
</g>
As the animaon plays out on the screen, the screen
reader automacally explains what the animaon is
doing. Noce that the <aria-pressed> aribute is set
to “false” in the code above. Once the animaon has
stopped, the buon shows that the animaon can be
triggered again by pressing the buon.
We could also use data sonicaon, or represenng
the data as sound, instead of a live region. That entails
creang an audio representaon that matches the
visual representaon of the lines on the graph and
triggering it to play at the same me as the visual
animaon. For simple paerns where the values
ploed on a graph rise and fall, sonicaon can be
a good technique. For example, the line on a graph
may rise from a low value to a high value, which can
be represented by a sound that increases in pitch or
volume from low to high. For anything much more
complicated though, sonicaon can become dicult
to interpret without learning the paerns rst.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 47
Wrapping Up
We’ve begun to explore the importance of role, name,
and state—collecvely known as semancs—for
making data visualizaons accessible to people who
cannot see them. By creang an underlying structure
that makes the data meaningful to screen reader users
and by using SVG images (possibly with a lile CSS
animaon) to layer the visualizaon on top of it, we
created a simple line graph that is accessible to screen
reader users.
You can apply these same techniques to make other
data visualizaons accessible, but sadly there is a
caveat: the technologies we have at our disposal,
namely SVGs and ARIA, and the technologies used by
consumers, namely browsers and screen readers, are
limited in their capabilies. As menoned, ARIA does
not have the roles to support data structures more
complex than tables or nested lists, and browser and
screen reader support for SVGs (even accessibility-
enhanced SVGs) is remarkably inconsistent. For these
reasons, you should remember two important things:
First, accept the creave challenge and experiment
with dierent ways to make your data visualizaons
accessible to screen reader users. And second, test
what you produce with as many dierent browser and
screen reader combinaons as you can.
48 DO NO HARM GUIDE
CHAPTER SIX
Creang Beer
Screen Reader
Experiences
SARAH FOSSHEIM
Data praconers have many tools to make
data accessible, and data visualizaons are one
parcularly powerful tool. Visualizaons can
summarize data into understandable points,
highlight outliers, or shed light on trends.
Interacve visualizaons enable people to
explore data dierently than with a table and
can be a great way of giving people access
to both the high-level trends and the
nuanced details.
As their name indicates, data visualizaons typically use a lot of
visual elements and properes to convey informaon. The color,
opacity, width, height, coordinates, and shape of an element can
all express meaning. And annotaons, labels, and other chart
elements can highlight certain properes of the data.
Take this bar chart for example. It shows two years of daily new
COVID-19 cases: each bar represents a date, sorted
chronologically; the bar height represents how many new cases
were registered that day; the horizontal axis label tells us the date;
and the vercal axis labels tell us the number of daily cases.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 49
Visually, we can spot the following relavely quickly:
•
When we experienced spikes or outbreaks and
approximately how long they lasted, which
is shown by viewing where consecuve bars
suddenly gain height.
•
How the outbreaks throughout the pandemic
compared with each other, which is shown by
comparing the approximate average height of
each of the spikes.
•
How COVID-19 spread is progressing currently,
which is shown by comparing the height of the
bars on the right edge of the graph (the latest few
days) with the bars before.
•
The exact number of cases for any given date,
which is shown by reading a toolp that appears
when hovering over any given bar.
With so much informaon primarily communicated
through visual elements, how can we make this chart
accessible to blind people? Many blind people use
screen readers, a type of assisve technology that
reads the page back to them (we’ll discuss them more
in the next secon; see also Chapters 4 and 5), so we
have to take a few extra steps when creang data
visualizaons to make sure the same informaon that’s
displayed visually can be read by screen readers.
In this essay, I provide guidance on what goes into
creang data visualizaons that are accessible
to screen readers. I will do so by starng with an
overview of what screen readers are and how they
work. Aerward, I will demonstrate three dierent
ways data visualizaons can be made accessible
for people using screen readers. Next, I argue why
it is important to keep the end user in mind during
the creaon process. I then reect upon how data
structures inuence which soluons we can use
to make our charts accessible and how the chart
structure plays into that.
How Screen Readers Work
First, let’s take a closer look at screen readers and
how they work. Screen readers are most commonly
used by blind people and people with low vision, but
consuming text in audio format can also benet people
with cognive impairments, neurological condions, or
learning disabilies.
On the web, screen readers use the content in a web
page’s framework (known as the Document Object
Model) or page structure to read the elements on the
screen back to the user. Praccally, only elements
containing text or specic properes are read
to the user.
Users can move the screen reader’s focus around
the page through keyboard shortcuts on a desktop
computer or touch gestures on mobile devices or
computers with touchscreens. When the screen reader
focuses on an element, its content gets announced.
It is possible to jump between all elements on the
page in the order they appear or to navigate between
headings, secons, and interacve elements. The
majority of screen reader users navigate web pages by
headings rst.
[1]
For this secon I will focus on VoiceOver, Mac’s
built-in screen reader, as an example (I provide a list
of others at the end of this chapter). Once VoiceOver
is open, users can use the Ctrl + Opon + U key
combinaon to open the rotor menu (shown on the
next page),
[2]
where we can nd a list with all extracted
heading elements. Other screen readers have similar
menus, which can be accessed through their own
shortcut.
This rotor menu lets users browse the contents of
the screen in a dierent way: it lists all the headings,
landmarks, links and form elements on the page. For
example, the following image shows VoiceOver’s
Headings menu. The number in front of the heading
tles is the heading level and is used to give further
context on the page structure.
By reading this list, people using screen readers can
get a beer understanding of the structure on the
page, similar to how a table of contents in a book or
paper might summarize a structure. It’s possible to
navigate this list using the arrow keys and select an
item to navigate to. All of this informaon is based
on the elements and properes the developers used
when building the web page.
50 DO NO HARM GUIDE
Web pages can be built with both semanc and
nonsemanc elements. Nonsemanc elements are
those that don’t tell the user anything about the
content on the web page—these are the code pieces
that dene a secon of the page or dene groups of
items on the page. Semanc elements, by contrast,
dene the content on the page—they are code pieces
that dene elements like tables, checkboxes, or submit
buons. When using semanc elements or equivalent
aria roles,
[3]
the screen reader can communicate extra
informaon to the users. In the following example, the
screen reader tells the user they are focused on a
buon, that the buon is not pressed, what will
happen if they press it, and which shortcut can be
used to do so.
When the user navigates to the pause buon on a music player,
VoiceOver will say, “Pause Music, selected, toggle buon.”
When the user navigates to the toggle buon on a web
When the user navigates to the toggle buon on a web page,
VoiceOver will say “You are currently on a toggle buon, inside
web content. To select or deselect this ck box, press Control-
Opon-Space. To exit this web area, press Control-Opon-Shi.”
The screen reader has access to all of the informaon
that the developer includes in their code, turning those
snippets into audible descripons. To ensure webpages
are accessible for people who use screen readers,
developers can include more specic informaon in
their code.
List of Screen Readers
We used the VoiceOver screen reader tool as an
example in this chapter. On computers running the
Windows operang system, the default screen reader
is called Narrator. It’s also possible to use third-party
soware, such as NVDA or JAWS. According to
WebAim’s 2021 Screen Reader Survey,
[4]
the most
commonly used screen readers are JAWS (70 percent
of respondents commonly use it, 53.7 percent use it
as their primary screen reader); NVDA (58.8 percent
of respondents commonly use it, 30.7 percent as their
primary screen reader); VoiceOver (41.3 percent of
respondents commonly use it, 6.5 percent as their
primary screen reader); and Narrator (36.8 percent
of respondents commonly use it, 0.5 percent as their
primary screen reader).
How Data Can Become Accessible
to Screen Readers
Data visualizaons contain a lot of graphical
informaon that is more dicult than simple text for
a screen reader to assess. Somemes even the visual
properes of text elements (e.g., their posioning) in
data visualizaons carry meaning, further complicang
maers. We can use a few common techniques to
communicate the insights visualized in charts to
screen readers. Each of those are navigated and read
dierently, so they have dierent implicaons for the
user experience.
Text Alternaves
When images or icons are used in applicaons or on
the web, developers commonly add something called
alternave text to them by using the “alt” aribute
(or as visible text next to the image, if adding an “alt”
aribute isn’t possible).
[5]
If a graph isn’t posted as a
stac image (e.g., a JPG or PNG le), it can be turned
into one programmacally by using the “img” role.
[6]
The screen reader will read out this alternave text
when focused on the image.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 51
When wring alternave text, experts recommend you
include in the descriponthe chart type,
•
the type of data visualized,
•
the main conclusion or reason for showing the
graph, and
•
a link to the data source.
[7]
Chapter 4 goes more in depth on how to cra
alternave text. In some situaons, we can hand-cra
the alternave text, write it once, and publish it with
the image. This approach does not work as well with
dynamic or frequently updated data because we would
have to automate the construcon of the alternave
text as well.
Further, not every graph can be fully summarized or
replaced with a few sentences of text. Let’s take this
scaerplot visualizing an ice cream shop’s average
order price (in Euros, visualized on the vercal axis)
compared with the outside temperature (in degrees
Celsius, on the horizontal axis).
Though we may be able to write or generate a high-
level summary of this graph’s insights, such alt text sll
may not be enough to provide the same insights to
both people who are using screen readers and sighted
people, who can see the individual points on the chart
and interact with them to reveal more data. (Noce
the alt text I’ve provided below the image describes
the basic plot, the ranges on both axes, and the
overarching point. Noce also that I have not assigned
alt text to the actual image in this document because
the alt text is included in the image capon. If both
existed, a person reading this report with a screen
reader would hear the descripon twice.)
As a result, sighted users can use all the informaon
available to draw their own conclusions about what
the data mean. If we want to give people using screen
readers the opportunity to dive into the data in a
similar way, we need to give them a way of navigang
the dataset beyond images and text alternatives.
Table Alternatives
Although text descripons are useful for summarizing
data, table alternaves shine when it comes to giving
access to detailed informaon. Tables can have innite
rows and columns, which can be structured through
headings, subheadings, and paginaon. Addionally,
we can add sorng, ltering, or search funconality to
let users explore the data in their own way.
When tables are built using the appropriate elements
[8]
(e.g., using HTML elements such as <table> on the
web), screen reader users get access to more context
around the table and special keyboard commands to
navigate it. Tables can be navigated horizontally and
vercally, and the connected column and row headings
are read out to the user.
[9]
Because nave tables come
with those established interacon paerns, users
don’t have to relearn how to navigate tables across
dierent products.
The familiarity of tables, along with their ability to
contain a lot of detailed informaon in a structured
way, oers a reliable and safe way of ensuring the data
are always available. With data visualizaons, I advise
always having a table alternave, even when using
other strategies such as alternave text. Where
52 DO NO HARM GUIDE
possible, table alternaves should be displayed
alongside or close to the graph. In this next example,
the data visualizaon has a table and chart view
available, which the user can toggle between using
tab navigaon.
Despite those strengths, tables are not a perfect
soluon. They are not great for summarizing data or
for communicang trends and paerns. Imagine more
than two years of daily COVID-19 case numbers in
tabular format. All the informaon about the peaks
and duraon of the outbreaks exists, just like in the bar
chart at the start of this chapter, but the user has to
interact much more to discover them.
Interacve Scalable Vector Graphics
As demonstrated in Chapter 5, when developing
graphs using Scalable Vector Graphics, we can add
more informaon for screen readers through
ARIA labels.
Adding screen reader interacon to SVGs leaves us
with a lot of control and choice over what informaon
we expose and how we expose it. In Chapter 5, Léonie
Watson shows us how a line chart can be turned into
a table structure. Similar methods can be used to
make screen readers announce elements such as lists,
buons, images, or other nave components. We can
also group elements and custom navigaon to provide
mulple levels of detail.
Recent research from Jonathan Zong and coauthors at
the MIT Visualizaon Group demonstrates how a user
can explore a scaerplot across three dierent design
dimensions.
[10]
•
Structural navigaon, where the user navigates
based on the accessibility structure and jumps
between nested elements.
•
Spaal navigaon, where the user navigates
based on the chart’s visual coordinate system,
using the down arrow key to jump to the element
that is visually below their current locaon,
for example.
•
Targeted navigaon, where the user navigates
based on landmarks and regions. The user could
open the rotor menu, which provides the full
structure of the page, and jump directly to the
relevant secon.
Understanding User Needs
Now that we have a beer understanding of how
screen readers work and what common accessibility
strategies are, we should take a step back before we
go further and reect on why we want to create data
visualizaons.
A tness tracking app, for example, may use a bar
chart to show how many steps someone took today
compared with this month’s average. Users might like
this chart because they can see if they’re on track to
meet their tness goals. By comparison, a bar chart
in a scienc report that shows daily new cases of
COVID-19 over the span of the pandemic may require
more funconality so users can look up values or
trends for specic dates and periods.
In the rst graph, the main point—how many steps
the user has taken today and whether they have taken
more or less than their average—can be summarized
in one sentence. The second graph, on the other
hand, provides a lot of data to an audience that wants
to explore the details. For this second graph, giving
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 53
people who use a screen reader just a one-sentence
summary would provide a less robust view of the data
and an insucient experience compared with the
experience given to sighted users.
Who Are We Building For?
If we want to create data visualizaons with a good
user experience, we need to understand who our users
are and include them in our processes. In other words,
we need to understand who we are building our
visualizaons for rather than creang the graph and
hoping it will match our users’ needs and expectaons.
We should ask ourselves the following:
•
Who are our users?
•
What are their accessibility needs?
•
What are their technology and data
literacy skills?
•
Under which circumstances are they
vising the graph?
•
How do they expect to interact with the graph?
•
What informaon are they aer?
•
What acons will they need to take based
on the data?
To nd some of this informaon, we can conduct
user interviews or user tesng. Other tools, such
as accessibility personas,
[11]
can help us get a beer
overview of dierent user needs.
Accessible Data Structures
All graphs, regardless of how they work or who their
users are, have one thing in common: they visualize
data. Because screen readers don’t have access to
the visual properes of a chart, it is useful to reect
on what type of data we’re working with before
building the structure. Being strategic with these
consideraons will improve the nal product and make
your workow beer and more ecient.
Is the Dataset Stac or Dynamic?
Whether a visualizaon is stac or dynamic—that is,
whether the data will update within the visualizaon—
and how frequently it updates, can limit or change our
soluons. If the visualizaon is stac or only updates
occasionally and with manual intervenon, we have
more opportunity for hand-craed capons or custom
interacons. But the less control we have over the
data, the more generic our soluon may have to be or
the more edge cases we will have to consider.
If the chart updates “live,” meaning without user
interacon, screen reader users will need to be
noed. On the web, we can add the `aria-live`
aribute on the region that will be updated to prompt
the screen reader to announce the updates, either by
interrupng the user (for me-sensive acons) or by
waing unl they are idle (in most cases).
[12]
How Large Is the Dataset?
A bar chart showing the number of visitors a website
had each day over the past week only has seven
data points, whereas a bar chart showing the daily
visitors over the enre lifespan of the website may
contain thousands. When a chart has only a handful
of data points, it is easier to remember specic data
or spot trends. But the larger the dataset, the harder
interpreng the data becomes. When exploring a table
or interacve chart with many data points, the user
will need to tab through a lot of informaon, which
means we may need to provide them with addional
labels or controls (e.g., paginaon or sort and lter
funconality).
What Type of Data Are Visualized?
The type of data we are visualizing oen inuences
how we display it. Let’s take the following chart
visualizing the share of ice cream orders that also
included a drink. For accessibility, it makes more sense
to focus on the underlying data, the percentages,
rather than the visuals of the chart. We don’t really
want screen reader users to have to tab through the
values of a hundred cells. In this case, the author
chose to add the percentages in text format next to
the graph.
54 DO NO HARM GUIDE
For the example visualizing COVID-19 cases over me
from earlier in the chapter, the data were shown in a
bar chart. Each bar represented a date, and the bars
were sorted chronologically, from the oldest date on
the le to the newest on the right. We read from le
to right visually, so the screen reader should have
access to the data in a similar way to give screen
reader users a good experience.
There are, of course, an unlimited number of graph
types, and graphs do not necessarily map to data types
one-to-one. In other words, one type of graph may be
used to show several kinds of data.
[13]
Are Any Trends or Paerns Idenable?
Graphs can be powerful at highlighng trends,
paerns, and outliers. Think of the graph with the daily
new COVID-19 cases we explored earlier. It didn’t just
give us access to all the numbers like a table would, it
also showed us how many large spikes we experienced
and when there were prolonged surges.
A user should be able to draw the same conclusions
when browsing the chart with a screen reader. We can
solve this problem in dierent ways, including
the following:
•
Describing the general trends
•
Grouping data points and oering
custom navigaon
•
Creang a dierent graph focusing only
on the trends
•
Adding sorng and ltering funconality
to table alternaves
•
Mapping dierent values to dierent sounds (a
process called sonicaon)
The best strategy will depend on the goals for the
visualizaon, the user’s needs, and the exisng
data properes.
Accessible Chart Structures
Besides data points, data visualizaons contain a lot
of perceivable informaon, including headings,
legends, axis labels, and annotaons. We should
thoughully design these other supporng chart
elements to provide contextual informaon for screen
readers as well.
Headings and Capons
Proper use of heading elements can make content
easier to nd, as demonstrated in Chapter 7. This
organizaon can also help users understand the page
structure, which provides a way of grouping the data.
Titles should set a clear expectaon about the purpose
of the graph. Addional descripons can explain how
to read the chart, interact with it, or interpret the data.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 55
We can also summarize the visualizaon in text as
part of the heading or descripon of a graph, which
everyone can read and understand.
Explanatory Chart Elements
Addional explanatory chart elements can be
instrumental for understanding the data. The cks
on the vercal axis of a line chart, for example, give
us an idea of the minimum and maximum values in
the dataset. The legend of a graph tells us which
categories of data are represented.
Without extra context, those elements might not make
much sense. We can choose to hide elements that only
serve a visual purpose, as demonstrated in Chapter
5, or we can extend their labeling and funconality to
provide more context to screen reader users. The label
of either axis can be extended to include informaon
about the range of numbers visualized on it, which
we can see demonstrated in the mockup below. The
scaerplot comparing the outside temperature to ice
cream sales has a summarizing label added to each axis
but visually hidden; this gets read instead of the cks.
Order of Elements
The coordinates and styling determine how data
points are sorted visually, while screen readers base
themselves on the order of the elements in the
accessibility tree.
[14]
For this chart, the screen reader experience diers
greatly from a visual experience depending on the
underlying organizaon.
Following this structure, a user can tab through all of
the elements in an order that matches how we expect
to browse the chart visually:
1. Title
2. Descripon
3. All the bars
¡ Sorted by date
¡ First the date is announced,
then the value
56 DO NO HARM GUIDE
A screen reader would read this chart like this:
Transcript of graph 1: “List, seven items. Monday:
100 visitors, 1 of 7. Tuesday: 174 visitors, 2 of 7.
Wednesday: 92 visitors, 3 of 7. Thursday: 193 visitors,
4 of 7. Friday: 103 visitors, 5 of 7. Saturday: 104
visitors, 6 of 7. Sunday: 294 visitors, 7 of 7.
End of list.”
[15]
Now let’s take a dierent chart that visually looks the
same but has the following structure (next page):
Transcript of graph 2: “List, 7 items. Friday: 103
visitors, 1 of 7. Monday: 100 visitors, 2 of 7.
Wednesday: 92 visitors, 3 of 7. Tuesday: 174 visitors,
4 of 7. Sunday: 294 visitors, 5 of 7. Thursday: 193
visitors, 6 of 7. Saturday: 104 visitors, 7 of 7. End of
list.”
[16]
In this second chart, the dates are not read in
chronological order. Here, the screen reader
announces Friday rst, then Monday, then Wednesday,
and so on. The reason this happens is because while
the styling determines the order elements are placed
visually, it’s the Scalable Vector Graphics structure that
generally determines the order for screen readers.
Therefore, you must be mindful of sorng your
datasets correctly before rendering them. Data should
be sorted in a way that makes sense and follows the
visual representaon. Similar to how the order of
the data points maers, think of how the other chart
elements t into this structure. For example, it might
make more sense to make the screen reader announce
the tle and range of each axis as a summary before
going through the actual data.
Interacon
If a data visualizaon has pointer acon available,
the same acons should be accessible for users who
only use a keyboard. A toolp that exposes more
informaon when hovered over should expose that
same informaon when it is focused on through
keyboard interacon.
Screen reader users should also clearly be shown
which elements are interacve and what state they
are in. As demonstrated in Chapter 5, we can use the
buon role, combined with the “aria-expanded” or
“aria-pressed” element, to do this.
[17]
Accessibility-Driven Visualizaons
How we design the screen reader experience
depends on what data are visualized, who the
visualizaons are for, which context they exist in, and
under which circumstances they are used. Designing
this experience ts right into other usability or
informaon architecture processes we may already be
following, because assistance technology bases itself
on the structure of the visualizaon and the elements
it contains.
Simplied code:
<h3>Daily visitors</h3>
<p>Average amount of visitors per day of the week
</p>
<g>
<text x=“0”>Monday: 100</text>
<text x=“20”>Tuesday: 174</text>
<text x=“40”>Wednesday: 92</text>
<text x=“60”>Thursday: 193</text>
<text x=“80”>Friday: 103</text>
<text x=“100”>Saturday: 104</text>
<text x=“120”>Sunday: 294</text>
</g>
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 57
Although a common workow may be to design a
visualizaon rst and later think of how or if that
visualizaon can be made accessible to screen
readers, we should instead start thinking about
accessibility as early as possible so we can make the
right decisions from the start. Integrang accessibility
into exisng processes or creang new ones that
account for accessibility can help us priorize
accessibility in data visualizaon. This includes the
tesng and quality control of our charts. User tests
with blind people are important to ensure we’re
providing a good and meaningful experience, and
audits or internal reviews can help us discover and
migate issues before they reach the user.
Although making data visualizaons accessible
to screen readers may seem like extra work,
data praconers can actually create a good and
meaningful experience for all audiences if they have
the foresight to consider accessibility from
the beginning.
Simplied code:
<h3>Daily visitors</h3>
<p>Average amount of visitors per day of the week
</p>
<g>
<text x=“80”>Friday: 103</text>
<text x=“0”>Monday: 100</text>
<text x=“40”>Wednesday: 92</text>
<text x=“20”>Tuesday: 174</text>
<text x=“120”>Sunday: 294</text>
<text x=“60”>Thursday: 193</text>
<text x=“100”>Saturday: 104</text>
</g>
58 DO NO HARM GUIDE
Chapter Six Notes
[1]
“Screen Reader User Survey #9 Results,” WebAIM, last updated June 30, 2021, hps://webaim.org/projects/screenreadersurvey9/.
[2]
“ARIA - Accessibility,” MDN Web Docs, last modied October 2, 2022, hps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA.
[3]
“Semancs,” MDN Web Docs, last modied September 20, 2022, hps://developer.mozilla.org/en-US/docs/Glossary/Semancs; “WAI-ARI
Roles,” MDN Web Docs, last modied September 16, 2022, hps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles.
[4]
See the Screen Readers Commonly Used secon of “Screen Reader User Survey #9 Results,” WebAIM, last updated June 30, 2021, hps://
webaim.org/projects/screenreadersurvey9/#used.
[5]
“Alternave Text,” WebAIM, last updated October 19, 2021, hps://webaim.org/techniques/alext/; hps://developer.mozilla.org/en-US/
docs/Web/HTML/Element/img#ar-alt
[6]
“<img>, the Image Embed Element,” MDN Web Docs, last modied October 10, 2022, hps://developer.mozilla.org/en-US/docs/Web/
Accessibility/ARIA/Roles/img_role.
[7]
Amy Cesal, “Wring Alt Text for Data Visualizaon,” Nighngale, the Journal of the Data Visualizaon Society, July 23, 2020, hps://
medium.com/nighngale/wring-alt-text-for-data-visualizaon-2a218ef43f81.
[8]
“Creang Accessible Tables,” WebAIM, last updated September 18, 2017, hps://webaim.org/techniques/tables/data.
[9]
Léonie Watson “How Screen Readers Navigate Data Tables,” Tink.uk, September 28, 2020, hps://nk.uk/how-screen-readers-navigate-
data-tables/.
[10]
Jonathan Zong, Crystal Lee, Alan Lundgard, JiWoong Jang, Daniel Hajas, and Arvind Satyanarayan, “Rich Screen Reader Experiences for
Accessible Data Visualizaon,” Computer Graphics Forum (Proc. EuroVis) 41 (2022): hp://vis.csail.mit.edu/pubs/rich-screen-reader-vis-
experiences/.
[11]
Accessibility Personas,” AlphaGov, accessed November 28, 2022, hps://alphagov.github.io/accessibility-personas/.
[12]
ARIA Live Regions,” Mozilla Developer Network, last modied October 26, 2022, hps://developer.mozilla.org/en-US/docs/Web/
Accessibility/ARIA/ARIA_Live_Regions.
[13]
See, for example, Jonathan Schwabish, “Beer Data Visualizaons: A Guide for Scholars, Researchers, and Wonks” (New York: Columbia
University Press, 2021).
[14]
“Accessibility Tree,” MDN Web Docs, last modied September 20, 2022, hps://developer.mozilla.org/en-US/docs/Glossary/Accessibility_
tree.
[15]
Sarah Fossheim, “Daily Visitors, Example #1,” CodePen, accessed October 19, 2022, hps://codepen.io/fossheim/pen/LYQKYxZ
[16]
“Sarah Fossheim, “Daily Visitors, Example #2,” CodePen, accessed October 19, 2022, hps://codepen.io/fossheim/full/dydByJv
[17]
“Aria-expanded,” MDN Web Docs, last modied September 13, 2022, hps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/
Aributes/aria-expanded; “Aria-pressed,” MDN Web Docs, last modied September 25, 2022, hps://developer.mozilla.org/en-US/docs/
Web/Accessibility/ARIA/Aributes/aria-pressed.
PART FOUR
Accessibility Tesng
and Remediaon
60 DO NO HARM GUIDE
CHAPTER SEVEN
Praccal
Accessibility
Tesng for Data
Visualizaons
LARENE LE GASSICK
My father has renis pigmentosa, a genec
disorder that gradually cost him his sight as I
was growing up. As a result, I was introduced
to soware screen magniers, high-contrast
themes, and screen readers at an early age. He
listened to audiobooks with a DAISY player—a
special hardware audio player invented for
people with low vision or blindness—and used a
white cane to navigate in public.
If my father didn’t have his disabilies, I would have not known very
much about assisve technologies. Many people who do not work
in spaces directly related to disability and accessibility have never
heard of a screen reader, a braille display, or a switch control, all of
which are known as “assisve devices” or “assisve technologies.”
Unfortunately, most of the web is built with sighted
or mouse-rst users in mind. But assisve technologies can help
people navigate their computer and smart device.
A screen reader uses a synthec voice to describe what is
happening on the screen. A refreshing braille display uses a
live-updang braille tacle display instead of a synthec voice.
Screen-magnifying soware enlarges the screen from 150 percent
to over 500 percent of the original display size to aid those with
low vision. Text readers read aloud content while visually
highlighng each word for those with cognive disabilies such
as dyslexia, and alternave input devices, such as voice control
soware, head pointers, eye trackers, and switch controls allow
people with some physical disabilies to navigate a website using
only their keyboard. Most screen reader users are also keyboard-
only users. Operang systems also come with personalizaon
opons, which allow a user to adjust text size, reduce animaon,
and turn on a high-contrast theme.
In this essay, I describe an easy-to-follow tesng process so people
who have never tested their data visualizaons for accessibility
can ensure their products work just as well for people who use any
of the above assisve technologies. Many exisng arcles about
accessibility tesng simply provide a checklist of tests and a list
of tools, but they do not go into details about the process. I have
also created a list of addional tools you can use in your own work,
available later in this volume.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 61
Digital Accessibility Standards
Creators of digital apps, content, and services should
be aware of how people with disabilies use these
technologies in their daily life. How would you build a
wheelchair ramp if you didn’t know how a wheelchair
worked or that wheelchairs even existed? More
importantly, what if you didn’t know who uses a
wheelchair and why?
[1]
With so many dierent types of assisve technology,
web browsers, and device operang systems, how
can we support all users? Luckily, there is some
standardizaon.
Just like the physical construcon industry has
building standards and guidelines for accessibility,
such as the angle and width for a wheelchair ramp,
[2]
the web also has standards and guidelines for digital
accessibility. The Web Content Accessibility Guidelines
(WCAG) working group,
[3]
which is part of the Web
Accessibility Iniave, an internaonal iniave to
develop standards to create a more accessible internet,
publishes guidelines and “success criteria” that can be
applied to a range of websites and applicaons and
serve as a foundaon for many countries’ compliance
and andiscriminaon laws. Unfortunately, the
technical nature of the guidelines has made them quite
inaccessible to someone new to web accessibility.
A deep understanding of WCAG is not needed to
create accessible content or conduct accessibility
tesng and the WCAG 2.1 At a Glance web page
succinctly summarizes the most important aspects
and requirements to creang more accessible online
content.
[4]
In 2021, Frank Elavsky created a set of guidelines
called the Chartability project to allow anyone in
the data eld to conduct accessibility tesng of data
experiences in any context, not just the web.
[5]
Elavsky worked closely with experts in the
cross-over of accessibility, disability, and data
visualizaon communies, and he has tested the
usability of the Chartability workbook with many
data visualizaon praconers.
[6]
The Tesng Process
We use accessibility tesng to idenfy and remediate
inaccessible web pracces.
[7]
Two types of accessibility tesng exist: personal
tesng, which all data praconers should learn to
ensure people with disabilies aren’t excluded from
their work, and professional “accessibility auding,”
which is conducted by someone trained to report a
list of issues for the client to x—a process known
as “remediaon.” In this essay, I will cover how data
praconers can begin to do personal accessibility
tesng, but companies should schedule regular
accessibility audits for their publicaons, websites,
or applicaons. Audits, at a bare minimum, test for
WCAG compliance, and in the best cases, will check
for usability issues and recommend soluons based on
inclusive design principles, user research, and tesng
with assisve technology users and people with
disabilies.
The tesng process I discuss here is my personal
process, but every accessibility tester’s techniques
and tools are tailored to their needs. Some methods
are shared and new and improved tools are released
regularly, but I have found these basic tasks and tests
to be sucient for general purposes.
I break up my tesng procedure into the following
four categories:
•
Content
•
Visual
•
Nonvisual
•
Interacon
For purposes of this essay, I assume that the
publicaon, website, or applicaon surrounding the
data visualizaon—whether a chart, graph, diagram, or
other piece of content—is accessible enough for the
chart to be reached by the reader or user.
Before we begin tesng, we need to have the right
tools at our disposal. Here I list common accessibility
issues and the tools or sengs that I currently use to
test charts and data visualizaons, but a longer list
62 DO NO HARM GUIDE
with addional resources and reference materials is
available at the end of this volume. If you are new to
accessibility tesng, start with these tools, but don’t be
afraid to try others based on your personal preference
and workow. For tesng with screen readers in
parcular, I recommend you watch the introductory
videos linked in endnote 1.
Color Contrast
For low-vision users, a data visualizaon must have
sucient contrast between text and background.
Contrast measures the dierence in luminance
between two colors. The contrast rao between black
(hex code #000000) and white (#FFFFFF) is 21:1. The
WCAG 2.1 AA standard denes an acceptable contrast
rao as at least 3:1 for large or bold text and icons and
4.5:1 for general reading text.
Dozens of contrast checking tools are available.
I use the TPGi Colour Contrast Analyser,
[8]
which
is a downloadable tool that enables you to test
the contrast of your color palee against
WCAG guidelines.
A user’s operang system might also include sengs,
such as high-contrast mode, that can test the color
contrast of a data visualizaon. In the Windows 10
operang system, you can acvate high-contrast mode
in Sengs > High Contrast > Turn On High Contrast.
The most commonly used high-contrast theme is white
text on a black background with bright yellow accents.
In the supplemental list of accessibility tools at the end
of this volume, I include a guide to changing color
contrast in Windows 11.
[9]
Mac operang systems don’t have a “high-contrast
mode” like Windows, but the Dark Background and
Light Text Firefox add-on for the Firefox browser oers
a comparable simulator.
[10]
Color Vision Deciency
The data visualizaon eld oen focuses on color
vision deciency (CVD), commonly known as “color
blindness.” But people with vision impairments can
struggle with dierent kinds of color issues, not just
disnguishing between, say, red and green (a condion
known as deuteranopia).
Many tools can test for dierent kinds of CVD, but
Color Oracle is my favorite.
[11]
Color Oracle is a free
simulator for Windows, Mac, and Linux that takes
the guesswork out of designing for color blindness by
showing you in real me what people with common
CVDs see.
Reduced Moon
People with vesbular disorders or who are easily
nauseated by animaon and movement oen turn
on their system’s “reduced moon” or “animaon o”
seng. Web developers can use “@media screen”
and “(prefers-reduced-moon: reduce)” in their CSS
animaons to provide a nonanimated alternave for
users who are aected by strong animaon. More
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 63
generally, when creang animaon or movement, it is
good pracce to turn o autoplay and give the user
control to start or stop an animaon.
For tesng, you can adjust these sengs on Windows
and Mac operang systems:
•
Windows: Sengs > Ease of Access > Display
> Simplify and Personalize Windows. Set Show
animaon in Windows to o.
•
Macs: System Preferences > Accessibility >
Display and check the box for Reduce Moon.
Screen Reader
Using screen readers to test your content will allow
you to catch many crical accessibility issues in your
data visualizaons and your content more generally.
The most common screen readers are VoiceOver for
Mac and NVDA, JAWS, or Narrator for Windows. I
use VoiceOver and NVDA because they are free and
most familiar to me. I work on Windows and Mac
computers, but you only need to test with one. I
recommend watching the introductory videos linked
in the list below and having on hand a quick reference
guide of screen reader keyboard commands (I usually
have mine printed out). I don’t use a screen reader
every day, so I oen forget the keyboard commands
between each tesng session.
•
Windows: NVDA is one of the most popular
screen readers for Windows users. It works with
all modern web browsers, email programs, music
players, and Microso Oce programs. NVDA
does not oer any introductory tutorial, so I
recommend you watch the following video:
¡ Screen Reader Basics: NVDA tutorial (9
minutes)
[12]
¡ Reference for NVDA Keyboard Shortcuts on
Windows
[13]
•
Mac: VoiceOver comes installed with MacOS.
When you rst open VoiceOver, you will be given
the opon to complete an interacve learning
tutorial, which I recommend you take the me to
complete; you should also watch the following
introductory video:
¡ Screen Reader Basics: VoiceOver tutorial
(12 minutes)
[14]
¡ Reference for VoiceOver Keyboard
Shortcuts on a Mac
[15]
Part 1: Tesng an Image of a Chart
A great starng point to learn accessibility tesng is
with a chart in an image format like JPG or PNG (rather
than one that is navely interacve on a website). If a
chart is an image, it is usually complementary to the
surrounding text and has a single clear takeaway.
To demonstrate, let’s begin with this default chart
image exported from Google Sheets. It’s a column
chart tled “Interstate Arrivals and Interstate
Departures,” with two data series, interstate arrivals
and interstate departures, denoted by blue and red
columns, respecvely. The x-axis is the categorical
Australian State (for readers who doesn’t know
Australia’s geography, the country has six states and
two territories), and the y-axis is the number of people
(not labeled).
Despite this chart being a default chart for one of the
most popular charng tools in the world, it has many
accessibility and usability issues.
As I menoned, accessibility tests are split into four
categories: content, visual, nonvisual, and
interacon.
[16]
Content Tesng
By making the content in the graph accessible, readers
are beer posioned to understand the graph and
your argument. So the checklist below applies to all
64 DO NO HARM GUIDE
good data visualizaons, not just those for people
with disabilies.
Content Tesng Checklist
•
Chart contains a descripve tle.
•
Chart contains a suitable summary either in the
chart or in the surrounding text.
•
Chart uses plain language.
•
Chart axes are labeled clearly.
•
Chart series are labeled clearly.
•
The numerical data is formaed clearly.
•
If the chart can be used for analysis or to
form one’s own insights and is not adequately
described by the chart summary, then a raw
data table or a CSV download of the raw data is
provided as an alternave.
Content Tesng Process
We start with the content review process because it
could necessitate quite drasc changes in the design
of the visualizaon. Accessible content is essenal for
people with cognive or intellectual disabilies, people
who have low data literacy, or in this case, people
who might not be familiar with Australian geography.
In this example, the tle was not descripve, and
the summary and y-axis label were missing. Also, the
number formang did not contain a comma, making
it hard for people to read. A good rule of thumb for
accessible text is to aim for a ninth-grade reading level;
I recommend the Hemingway Editor for assessing the
reading level of your wring.
[17]
Let’s look at what works and what doesn’t:
•
Passes
¡ Chart uses plain language. The chart
doesn’t use a lot of jargon or
technical verbiage.
•
Failures
¡ Chart contains a descripve tle. The tle
does not menon important details such as
the country and year.
¡ Chart contains a suitable summary, in the
chart, or in surrounding text. No summary
is present.
¡ Chart axes are labeled clearly. The y-axis is
not labeled.
¡ Chart series are labeled clearly. The
series labels contain too much text, and a
descripve tle makes them redundant.
•
Extra consideraon
¡ If the chart can be used for analysis
and is not adequately described by a
chart summary, a raw data table or a
CSV download of the raw data should
be provided as an alternave. This
consideraon would depend on the larger
context in which the chart is used.
No real science exists on how to x these issues, so it
takes pracce and tesng with users. If you’re not sure
what to write, consider these leading quesons:
•
What is the main takeaway for this chart?
Describe what you want people to take away
from this chart in a concise, acve sentence.
[18]
This descripon becomes the chart tle.
•
How would I describe this chart for a person who
cannot see it? Think about what is interesng
about this chart and what about this chart informs
the context in which a reader will see it. That
explanaon becomes the chart summary.
For this chart, I’d also provide the raw data, either as
an HTML table or as a downloadable CSV le (Note
that CSV is the most accessible format for table data—
not everyone has Microso Excel).
Content Tesng Results
By working through this checklist, we have made
several changes to the original chart. The chart tle
now reads “Interstate Migraon in Australia, Year
Ending June 2020” and we have a chart summary just
below: “Queensland had the highest net gain from
interstate migraon of 25,300 people.” We’ve also
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 65
added a y-axis label— “Persons (thousands)”—and
simplied the legend to “Arrivals” and “Departures.”
But we’ve also introduced a new accessibility issue: the
chart summary uses the default text color of light gray,
which will fail the contrast tests in the next step.
Visual Tesng
Visual tesng focuses on making the experience
inclusive for users with low vision or CVD. These tests
can also ensure that text is more readable for someone
with dyslexia and that animaons do not cause nausea
or epilepc seizures.
Visual Tesng Checklist
•
All text is at least 12 pixels (or 9 point) in size,
ideally 16 pixels (or 12 point).
•
Small text and its background colors meets a
minimum contrast rao of 4.5:1. “Small text” is
dened as text smaller than 24 pixels (or 18 point)
or as bold text smaller than 18.5 pixels (or 14
point).
•
The contrast rao of shapes, icons, and large
text relave to their background color meets a
minimum rao of 3:1.
•
Color alone does not denote meaning—that
is, contrast, markers, or paerns are used to
dierenate data and are labeled appropriately
(i.e., with a legend or nearby text).
•
Text font is sans serif (that is, the leerforms
in the font do not have decorave marks or
ourishes. Examples of sans-serif fonts include
Arial, Courier, and Helveca).
•
The chart can be zoomed or magnied.
•
If the chart has a transparent background, it
meets the above contrast requirements in high-
contrast (forced styles) mode.
•
If the chart is animated, it must not contain
ashing that could cause seizures.
•
If the chart is animated, it must be able to be
paused or stopped, and the animaon should not
automacally play.
Visual Tesng Process
The visual tesng process requires using a color
contrast checker and CVD simulator tools. I use the
two tools I demonstrate here in my own workow, but
there are many other tools that you might nd beer
t your style, operang system, and workow (see the
list at the end of this volume for more tools).
Let’s begin with tesng color contrast. First, open the
TPGi Colour Contrast Analyser and select the eye-
dropper tool in the “Foreground colour” secon of the
window, then sample the darkest color of the chart
tle text. If you know the hexadecimal color code or
have a tool you can use to obtain it, you can also enter
that code directly. Then, select the eye-dropper tool in
the “Background colour” secon of the window, and
sample the background behind the tle text.
Before content tesng Aer content tesng
66 DO NO HARM GUIDE
Once you have set the foreground and background
colours, the “Sample preview” secon will show you
how those colours look together on text and on an
icon. And the “WCAG 2.1 results” secon displays the
contrast rao in a box in the top-right corner. For our
example, the contrast rao is 4.6:1, which means
people with low vision can likely see this text color on
a white background. For general accessibility tesng,
you can ignore any failures in the middle row (1.4.6
Contrast Enhanced AAA)—most audits only check for
AA compliance. Repeat this process for all text
in the chart.
Next, we’ll test for issues that may aect those with
CVD.
Open the Color Oracle app (the icons will appear in
your computer’s taskbar). Click on the Color Oracle
icon (or right-click in Windows) and choose to
simulate Deuteranopia (commonly known as “red-
green colorblindness”) followed by Grayscale. For our
example chart, there is very lile dierence in the
shades of gray. This is a contrast issue: readers with
CVD may not be able to tell the dierence between
dierent data series on the chart (including the
legend).
We can also cross-check this contrast issue using
Colour Contrast Analyser. The results conrm a
contrast rao of 1.1:1, which explains the result from
the grayscale simulaon.
So where do we stand with our visual tesng?
•
Passes
¡ Font is sans-serif.
¡ All text is at least 12 pixels or 9 point in
size, ideally 16 pixels or 12 points.
¡ The contrast rao of shapes, icons, and
large text relave to their background
meets a minimum 3:1.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 67
•
Failures
¡ Small text meets a minimum contrast rao
of 4.5:1. “Small text” is text smaller than 24
pixels or 18 point, or bold text smaller than
18.5 pixels or 14 point. The chart summary
does not meet minimum contrast.
¡ Color alone is not used to denote meaning.
The chart uses color to dierenate
between Arrivals and Departures.
•
Extra consideraon
¡ The chart is able to be zoomed or
magnied. Check that the parent
webpage hasn’t disabled zoom.
¡ If the chart has a transparent background,
it meets the above contrast requirements
in high contrast (forced styles) mode.
Not applicable.
¡ If the chart is animated, it must not
contain ashing that could cause seizures.
Not applicable.
¡ If the chart is animated, it must be able to
be paused or stopped and the animaon
should not auto-play. Not applicable.
Visual Tesng Fixes
To resolve these issues, we can darken and enlarge
the tle and summary text slightly, and we can choose
new colors for the arrivals and departures data series
that have at least 3:1 contrast between each other, as
well as both having 3:1 contrast against the
white background.
Using Color
It is very dicult to nd a color set where
all colors have a contrast rao of 3:1, even
for a chart with only two categories or
series of data.
My recommendaon is to choose a
monochrome set with as much contrast
between colours as possible. Perhaps you
can nd a color set that accounts for CVD
and grayscale prinng (you could also
consider 3D prinng of tacle charts). This
contrast might be as low as 1.3:1. You might
use spacing, posion, labels, or interacve
styles and toolps as other ways to know
what data belongs to which category.
Although paerns are widely recommended
as a way to provide visual contrast, paerns
should be used with care because they can
actually make the chart less accessible, since
paerns can be visually confusing for some
readers. For more informaon, see “Paerns
and Contrast,” HighCharts, accessed October
24, 2022, hps://www.highcharts.com/docs/
accessibility/paerns-and-contrast.
68 DO NO HARM GUIDE
Nonvisual Tesng
For a stac image chart, a text descripon must be
provided (also known as alternave text or alt text).
For web developers, your <img> tag must include the
short descripon on an “alt” aribute. If the short
descripon does not adequately explain the chart, a
longer text descripon should be present in the arcle
content, ideally directly before or aer the chart.
You can learn more about alt text and strategies in
Chapters 4, 5, and 6 of this volume.
Nonvisual Tesng Checklist
•
There is an appropriate text descripon
of the chart.
Nonvisual Tesng Process
Usually, we can check a nonvisual descripon of an
image by tesng it with a screen reader. If you are a
screen reader user, you already know how to test for
alt text. Again, I recommend that everyone learn how
to use a screen reader to help test your own work
for accessibility.
But there is another way to test online images for alt
text without using a screen reader, using the built-in
debugging tools in the browser. Simply right-click on
the graph and select the Inspect opon at the boom
of the menu (I’m using Chrome here; your opons may
vary slightly). If you are reading the document version
of this arcle, you can try this yourself by vising this
chapter’s companion website. This companion website
provides the text of this chapter in HTML and includes
accessible, interacve charts.
For our chart, you will nd the following line of HTML
in the Elements tab of the Developer Tools panel:
<img src=“/images/chart-1-after-visual-fix.
png”>
This line of code conveys to a screen reader user that
an image is on the page, but it does not explain what
the image is, what it is showing, or what it represents.
Without the presence of an alt aribute, most screen
readers will read out the lename of the image (in
this case, “chart-1-aer-visual-x.png”), which is a
frustrang experience.
The correct HTML would include an alt aribute in the
<img> element, like so:
<img src=“/images/chart-1-after-visual-
fix.png” alt=“A column chart on interstate
migration in Australia, year ending June 2020,
where Queensland had the highest net gain from
interstate migration of 25,300 people. The
chart shows arrivals and departures for the
eight states and territories of Australia.”>
The screen reader will read this bit of text to the user
so they know what the graph is and what it represents.
The hardest part of this process is learning how to
write a good image description for a graph—Chapters 4
and 5 in this volume go into more detail on how to
write better alt text.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 69
Nonvisual Tesng Results
Where do we stand on our nonvisual tesng results?
•
Passes
¡ There is an appropriate text descripon of
the chart. Because this essay was built with
accessibility in mind, all chart images have
been given text descripons, except for the
test image above.
Interacon Tesng
Although we’ve been using a stac example chart so
far, what if we made it interacve by adding toolps
to each bar? To test the interacve version, we
would need to do some addional tests for the three
categories we’ve already covered. This takes us into
the second part of our accessibility tesng: What to do
if the chart is interacve.
Part 2: Tesng an Interacve Chart
If you are reading the document version of this arcle,
please visit this chapter’s companion website to
conduct the tests described in this secon.
Interacve charts are generally used for larger sets of
data and allow the user to explore and form insights
about the data. The charts also necessitate some
added complexity when creang equitable experiences
between sighted users and blind users or between
mouse users and keyboard-only users.
Based on the image-only chart from part one, I’ve
created an interacve chart using the popular chart
and data visualizaon framework Highcharts.
[19]
Thanks to the fantasc work of Ted Gies, Øystein
Moseng, and their team, Highcharts priorizes
accessibility in their charts.
Let’s connue our accessibility tesng. First, we’ll
test accessibility access with a keyboard, then
conduct addional tests for content, visual, and
nonvisual elements.
Interacon Tesng (Interacve Charts)
If you are a sighted mouse user, you will be able to
hover over the columns in the example chart and an
informaonal toolp will appear. Most interacve
charts on the web will have this feature, though they
tend to only show toolps when a user uses a mouse
to hover over the bar. The needs of keyboard-only and
touch users are generally neglected.
Interacon tesng ensures that anything that can be
accessed by mouse hover is also available to those
using a keyboard or touch device.
Interacon Tesng (Interacve Charts)
•
Keyboard tab to the chart focuses on the rst
interacve element.
•
The Tab key should navigate to dierent secons
of the chart—such as the data series, legend,
and menu—rather than between every single
interacve element.
¡ Arrow keys should navigate between data
points or toggle between data series,
legend items, and menu opons.
¡ Space/Enter should acvate buons
or toggles.
Before visual tesng Aer visual tesng
70 DO NO HARM GUIDE
•
Mouse hover, pressing Space or Enter, or touch
on a mobile device shows or hides annotaons
such as toolps.
•
The chart does not have “keyboard traps,”
something that occurs when a user can get into,
but not out of, a component or element of a web
page when using a keyboard.
•
The chart does not rely on custom
keyboard shortcuts.
This checklist does not cover accessibility tesng of
dropdown menus, select boxes, or other components
that the chart may contain, but they absolutely need to
also be tested with keyboards and screen readers.
Interacon Tesng Process
Using only the keyboard, use Tab key and arrow
keys to check whether you can reach all parts of the
chart. Make sure Tab isn’t used to navigate between
individual data points, because that creates a tedious
experience for keyboard-only users, parcularly when
the dataset is large.
Ensure that buons or toggles can be acvated by
pressing Space or Enter. All toolps that appear on
mouse hover should also appear on keyboard focus.
Check chart interacvity on a touchscreen device
to ensure that using tap input also toggles
toolps correctly.
If you get stuck in any part of the chart and cannot
use the Tab, Shi-Tab, or Esc keys to exit, you’re
in a keyboard trap. Such traps lead to frustrang
experiences for keyboard-only users, because the
users will not be able to reach the interacve items on
the rest of the page.
Lastly, if there are any custom keyboard shortcuts
that are essenal to the operaon of the chart, screen
readers probably cannot use them because the screen
reader takes precedence when it comes to keyboard
shortcuts (of which there are many), meaning many
keystrokes will not make it to the browser.
[20]
Content Tesng (Interacve Charts)
In addion to the content tests from Content Tesng
for image charts, interacve charts must also ensure
the following:
•
Toolps contain clear informaon
This process is similar to tesng a stac image chart;
x the content rst, because returning to the content
later could lead to drasc changes in the way the chart
is presented.
Our interacve chart only adds toolps. In the
toolp, we should include the data series label, the
x-value, and the y-value, because people who use
magnicaon may not be able to see the toolp and
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 71
the chart axes at the same me. Having all of the
informaon can also benet screen reader users as
they explore the chart.
Highcharts’ default toolp includes the x-value “Vic.”
(for Victoria), the data series label “Arrivals,” and the
y-value “77,197.”
Visual Tesng (Interacve Charts)
In addion to the visual tests for image charts, we
must also consider the following:
•
Acve elements have clear focus styles that meet
a contrast minimum of 3:1.
•
The chart can be understood in high-contrast
(forced styles) mode.
•
If the chart uses animaon, the chart respects
the user’s system animaon seng. For longer
animaons, the graph must contain a stop/start
buon and must not automacally play.
While tesng interacon with the keyboard, you can
check that focus outlines (or other suitable focus
styles) appear on the interacve element. In the
example below, the dark blue outline around the rst
light blue bar indicates the current locaon of
keyboard focus. The user should also be able to use
the Tab and arrow keys to navigate the chart.
To test the chart with forced styles, either turn on
High-Contrast Mode in Windows, or open Firefox (on
either Windows or Mac computers) and use the Dark
Background and Light Text add-on.
With High-Contrast Mode enabled, your system
overrides applicaon and website colors with a set of
chosen “high-contrast” colors, which helps people with
low vision who cannot easily dierenate between
colors. In our example, all chart colors have been
overridden with a bright yellow on a black background,
which can cause problems because we can no longer
dierenate between the arrivals and departure
columns (except to hope that the legend lists them in
the corresponding order). Luckily, the reader can sll
use toolps or toggle on/o of each data series in
order to know which data points are arrivals and which
are departures.
To test animaon, we need to acvate the Reduced
Moon seng and return to the chart to visually
check whether any animaon occurs. On page
refresh, the columns grow vercally from the x-axis
line in our example chart, and toggling the data on
and o prompts some animaon. Unfortunately, this
interacve chart fails to respect a user’s reduced
moon preferences.
Nonvisual Tesng (Interacve Charts)
Screen reader interacon with an interacve chart is a
complex test because the way a screen reader user will
navigate the chart depends on how it has been coded.
As menoned in Chapters 5 and 6, most complex or
dynamic charts are coded in an SVG format, but that is
not a universal rule.
[21]
72 DO NO HARM GUIDE
If built with screen reader users in mind, the individual
elements of the chart will be accessible by a screen
reader through appropriate ARIA roles and labels.
In this specic example, each column in the interacve
chart (we’re using the HighCharts JavaScript library)
has role=“img”, and an ARIA label with the datapoint
informaon. Screen readers will list each column as a
labelled image, allowing users to inspect each one.
HighCharts is one of the few chart libraries that
have this level of screen reader support—most
of the popular chart tools do not even include
keyboard navigaon. Apart from a lack of awareness
of accessibility in the soware industry, very few
resources exist on recommended techniques for
screen reader experience of charts (except for arcles
like those found in Chapters 4, 5, and 6).
Nonvisual Tesng Checklist
•
A chart heading is provided so screen reader users
can quickly skip to the chart.
•
The anatomy of the chart is provided, including
how many data points it contains.
•
If necessary, interacon instrucons are provided
(for example, toggling data series on or o).
•
Interacve elements on the chart have the
appropriate ARIA roles and labels.
•
Visual changes to the chart are announced
by an <aria-live> element or <role=“status”>,
for example whether a data series is toggled
on or o.
Nonvisual Tesng Process
Inspecng the Document Object Model
The Document Object Model denes the logical
structure of a document—for example, a web page—
and enables programmers to add, modify, or delete
elements and contents from the page. We can explore
the Document Object Model directly on a web page by
right-clicking and selecng the Inspect opon, which
will enable us to see whether the chart element is
using <svg> or <canvas>.
If you are familiar with the accessibility tree—a list of
the accessibility properties on a web page—you can
also see the semantic structure of the chart by
inspecting the accessibility properties of each element
in the chart or by enabling the full-page accessibility
tree in the Google Chrome browser.
[22]
I’ve provided
an example above.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 73
Tesng with a screen reader
Next, open up your screen reader and navigate
around.
[23]
For VoiceOver: Use Control + Opon + Right Arrow
and Control + Opon + Le Arrow to navigate the
chart by. You can jump to the chart heading rst, by
pressing Control + Opon + Command + H unl you
reach it, before using Control + Opon + Arrow Keys
to navigate between items.
For NVDA: Press Tab to navigate to the next
interacve element. Press H to jump to headings on
the page, and use the Down Arrow to navigate to the
next item. Press G (for “graphic”) to navigate to the
next image.
Our example chart is quite screen reader accessible
and passes all of our nonvisual tesng criteria.
Congratulaons!
If you’ve made it this far, thank you, and well
done! Especially if you are new to accessibility and
assisve technologies. My goal here is to make it
easy for data praconers to test their charts and
visualizaons. That being said, especially for someone
new to accessibility, conducng these tests could
take anywhere from a few minutes to several hours,
depending on the visualizaon. In the end, this
process will save you me and help you and your
team design visualizaons that are accessible for a
broader audience.
I cannot stress enough the importance of usability
tesng for accessibility, which should include a diverse
range of parcipants. Even the most experienced
auditors cannot predict the way assisve technology
users and users with various disabilies will interact
with a visualizaon. Two people with similar disabilies
and assisve devices can have dierent ways of using
their technology. You cannot make assumpons when
designing data visualizaons. Working with people
who have dierent kinds of disabilies will enable you
to determine how they are using your website, what
needs they have, and how you can ulmately create a
beer experience for everyone.
Happy tesng!
74 DO NO HARM GUIDE
Appendix
The source dataset used for interstate arrivals
and departures comes from “Migraon, Australia,
2019–20 Financial Year” Australian Bureau of
Stascs, accessed October 24, 2022, hps://www.
abs.gov.au/stascs/people/populaon/migraon-
australia/2019-20.
State Interstate arrivals Interstate departures
NSW 89,873 110,760
Vic. 77,197 74,954
Qld 101,789 76,441
SA 23,726 25,886
WA 29,211 31,621
Tas. 12,962 11,749
NT 13,517 16,214
ACT 20,394 21,044
Checklists: Praccal Accessibility Tesng for
Data Visualizaons
Content Tesng Checklist
¨
Chart contains a descripve tle.
¨
Chart contains a suitable summary in the chart or in
the surrounding text.
¨
Chart uses plain language.
¨
Chart axes are labeled clearly.
¨
Chart series are labeled clearly.
¨
The numerical data is formaed clearly.
¨
If the chart can be used for analysis or forming
one’s own insights and is not adequately described
by the chart summary, then a raw data table or a
CSV download of the raw data is provided as
an alternave.
If chart is interacve,
•
If present, toolps contain clear informaon.
Visual Tesng Checklist
¨
All text is at least 12px (or 9pt) in size, ideally 16px
(or 12pt).
¨
Small text and its background colors meets a
minimum contrast rao of 4.5:1 (see explanaon of
contrast raos in Color Contrast Checkers secon,
above). “Small text” is dened as text smaller than
24px (or 18pt) or as bold text smaller than 18.5px
(or 14pt).
¨
The contrast rao of shapes, icons, and large text
relave to their background color meets a minimum
of 3:1.
¨
Color alone is not used to denote meaning – that
is, contrast, markers, or paerns are also used to
dierenate data and are labeled appropriately (i.e.,
with a legend, or nearby text).
¨
Text font is sans-serif (that is, the leerforms in the
font do not have decorave marks or ourishes.
Examples of sans-serif fonts include Arial, Courier,
and Helveca).
¨
The chart is able to be zoomed or magnied.
¨
If the chart has a transparent background, it meets
the above contrast requirements in high-contrast
(forced styles) mode.
¨
If the chart is animated, it must not contain ashing
that could cause seizures.
¨
If the chart is animated, it must be able to be
paused/stopped, the animaon should not
automacally play.
If chart is interacve,
¨
Acve elements have clear focus styles that meet a
contrast minimum of 3:1.
¨
The chart is able to be understood in high-contrast
(forced styles) mode.
¨
If there is animaon, the chart respects the
user’s system animaon seng, and for longer
animaons, it must contain a stop/start buon and
not automacally play.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 75
Nonvisual Tesng Checklist
¨
There is an appropriate text descripon
of the chart.
If the chart is interacve,
¨
A chart heading is provided so that screen reader
users can quickly skip to the chart using the
heading shortcut.
¨
The anatomy of the chart is provided, including
how many data points it contains.
¨
If necessary, interacon instrucons are provided
(for example, toggling data series on or o).
¨
Interacve elements on the chart should have the
appropriate ARIA roles and labels.
¨
Visual changes to the chart are announced through
an <aria-live> element or <role=“status”>, for
example whether a data series is toggled on or o.
Interacon Tesng Checklist
If the chart is interacve,
¨
Keyboard tab to the chart focuses on the rst
interacve element.
¨
Tab key should navigate to dierent secons of
the chart, such as the data series, legend, and
menu, rather than between every single interacve
element.
¡ Arrow keys should navigate between data
points or toggle between data series,
legend items, or menu opons.
¡ Space/Enter should acvate buons or
toggles.
¨
Mouse hover, pressing Space or Enter, or touch on
a mobile device shows or hides annotaons such as
toolps, if present.
¨
The chart does not have keyboard traps.
¨
The chart does not rely on custom
keyboard shortcuts.
76 DO NO HARM GUIDE
Chapter Seven Notes
[1]
If you’re new to assisve technologies, please take a few minutes to watch these videos on browsing with assisve technology videos for
an introducon to how they are used to navigate the web. See Henny Swan, “Browsing with Assisve Technology Videos,” TetraLogical blog,
December 24, 2021, hps://tetralogical.com/blog/2021/12/24/browsing-with-assisve-technology-videos/.
[2]
See Chapter 4 (secon 405 in parcular) of “2010 ADA Standards for Accessible Design,” ADA.gov, accessed October 21, 2022, hps://
www.ada.gov/regs2010/2010ADAStandards/2010ADAstandards.htm#c4.
[3]
See the Web Content Accessibility Guidelines secon at “W3C Accessibility Standards Overview,” W3.org, last updated June 29, 2022,
hps://www.w3.org/WAI/standards-guidelines/#wcag2.
[4]
“WCAG 2.1 at a Glance,” W3.org, last updated June 5, 2018, hps://www.w3.org/WAI/standards-guidelines/wcag/glance/.
[5]
See Chapter 2 of this volume as well as Frank Elavsky, Cynthia Benne, and Dominik Moritz, “How Accessible Is My Visualizaon?
Evaluang Visualizaon Accessibility with Chartability,” Computer Graphics Forum 41, no. 3 (2022): 57–70.
[6]
See “The Chartability Workbook,” Github.io, accessed October 21, 2022, hps://chartability.github.io/POUR-CAF/.
[7]
As a disclaimer, I am not a professional accessibility auditor. I’ve learned accessibility tesng as a soware engineer and designer while
collaborang and learning with the accessibility community. The soware I’ve built using this tesng process has produced relavely few
issues in professional accessibility audits. Using this tesng process will not guarantee WCAG compliance, but it will produce more inclusive
data experiences.
[8]
See “Colour Contrast Analyser (CCA),” TPGi, accessed October 21, 2022, hps://www.tpgi.com/color-contrast-checker/.
[9]
See “Change Color Contrast in Windows,” Microso Support, accessed October 21, 2022, hps://support.microso.com/en-us/windows/
change-color-contrast-in-windows-fedc744c-90ac-69df-aed5-c8a90125e696#WindowsVersion=Windows_11
[10]
Mikhail Khvoinitsky, “Dark Background and Light Text,” FireFox Browser Add-Ons, last updated February 7, 2021, hps://addons.mozilla.
org/en-US/refox/addon/dark-background-light-text/.
[11]
See hps://colororacle.org/.
[12]
Google Chrome Developers, “Screen Reader Basics: NVDA – A11ycasts #09,” Youtube, December 2, 2016, hps://www.youtube.com/
watch?v=Jao3s_CwdRU.
[13]
“NVDA Keyboard Shortcuts,” Deque University, accessed October 24, 2021, hps://dequeuniversity.com/screenreaders/nvda-keyboard-
shortcuts.
[14]
Google Chrome Developers, “Screen Reader Basics: Voiceover – A11ycasts #07,” Youtube, October 14, 2016, hps://www.youtube.com/
watch?v=5R-6WvAihms.
[15]
“VoiceOver Keyboard Shortcuts on a Mac,” Deque University, accessed October 24, 2021, hps://dequeuniversity.com/screenreaders/
voiceover-keyboard-shortcuts.
[16]
Choosing the correct chart format is important for helping your reader understand your message. A column chart is probably not the
best choice for the data we’re using, but it is an easy format to test. Good accessibility begins with design, and I highly recommend reading
the following two resources: Cole Nussbaumer Knaic, Storytelling with Data (Hoboken, NJ: John Wiley & Sons, 2015), hps://www.
storytellingwithdata.com/books, and Jonathan Schwabish, Beer Data Visualizaons (New York: Columbia University Press, 2021), hps://
policyviz.com/books/ .
[17]
See hps://hemingwayapp.com/
[18]
See also Schwabish, Beer Data Visualizaons.
[19]
See hps://www.highcharts.com/
[20]
See Léonie Watson, “Time to Revisit Accesskey?” Tink.uk, April 29, 2015, hps://nk.uk/me-to-revisit-accesskey/.
[21]
There is also a popular graphic display element in HTML called <canvas>. The HTML canvas allows a programmer to build visuals using
geometric elements such as circles and rectangles along with x and y coordinates. It allows developers to build charts using programmable
graphic elements and interacons (<canvas> is oen used for web 3D graphics or web games). But the elements within a <canvas> are not
reachable by the screen reader, and it takes quite a lot of JavaScript knowledge to make it an equivalent experience. When I see a chart built
in <canvas>, I assume it is not accessible to screen reader users or keyboard-only users.
[22]
Accessibility Tree,” Mozilla Developer Network, last modied September 20, 2022, hps://developer.mozilla.org/en-US/docs/Glossary/
Accessibility_tree.
[23]
Navigang the chart by screen reader is not the same as navigang the chart using the keyboard. You will not see the focus outline
nor the toolps when navigang between data points. Screen readers use the “virtual cursor” to navigate the page. When screen reader
shortcuts are pressed, like the Down Arrow in NVDA, keyboard events are not sent to the browser (i.e., the browser doesn’t know you’ve
pressed the Down Arrow). This is a common misunderstanding for people who are new to using screen readers; see this comment by
Oysteinmoseng on “A11y: Highlight Problem When Using NVDA,” Highcharts Github repository, issue #15303, March 11, 2021, hps://
github.com/highcharts/highcharts/issues/15303#issuecomment-796670885.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 77
CHAPTER EIGHT
Infographic
Equity in PDF
Documents:
Designing with
Accessibility
in Mind
DAX CASTRO
Current data visualizaon trends rely heavily
on infographics to convey meaning, but
this method frequently creates unintended
accessibility barriers. In my work as a PDF
remediator (meaning I make PDF documents
accessible), I have seen countless infographics
that are unapproachable or that contain
meaningless descripons for people
who rely on assisve technology or keyboard-
only interacon.
In my experience, content creators usually take an “accessibility
at the end” approach to design. They design rst and then try to
gure out how to make that design accessible. This essay explores
dierent ideas for creang richer experiences for people who use
assisve technology such screen readers, text-to-speech soware,
or text-to-braille devices to interpret data visualizaons.
Not everyone perceives all inputs equally. We must take addional
steps to increase what I call infographic equity. Simply put,
infographic equity is the aempt to provide an equal experience
for all readers regardless of the methods they use to read or
interact with a visualizaon. Let’s start with a simple example.
Consider the alternave (alt) text in the sunburst diagram on the
following page.
We have an image of a complex sunburst diagram showing ve
dierent property types. Each one has a numeric value aached to
it. Technically, alt text version one (“Investment Property Sunburst
Diagram”) would pass any accessibility checker, but it contains
almost no meaningful data. Version two has a single value and
explains the main takeaway the author intended by including the
chart. Again, this is technically compliant, but is it an equitable
experience given the other four missing data values?
The third version of alt text contains the full meaning of the chart
with all values and associaons, including the author’s intent. But
what should you do when you have a bar chart with 50 data points
or a graphic with a complex story? There are several ways we can
create more accessible experiences.
This essay focuses on four main methods for presenng richer,
more meaningful visual content in PDF documents. In parcular, I
focus on infographics, a broad term that describes how we present
data in a visual way to make complex informaon easier to
78 DO NO HARM GUIDE
understand. Unlike singular data visualizaons, such as
standalone charts and graphs, infographics incorporate
text and images together to convey a complex idea in a
creave, easy-to-understand way.
[1]
Infographics may
take the form of printed, standalone, leave-behind
documents; downloadable PDFs; or large image les.
Some infographics tell stories, others present data in a
series of steps, and others simply present data for
users to explore and understand. Before we can learn
how to create more meaningful experiences, we must
understand that the point at which we consider
accessibility during the development phase is crical.
When You Start Maers Most
It is important to incorporate accessibility
consideraons at the earliest stage possible. The stage
at which we consider accessibility directly impacts
how long it will take to make the product accessible,
what approach we use to do so, and ulmately how
usable and informave the content is. If we start late,
our goal of a single, equitable, accessible experience
for everyone oen fails because “there’s not enough
me” or “this has already been approved and we can’t
change it.”
When teams start designing with accessibility in mind
from the beginning, there are more opons to present
a single, meaningful user experience. Depending on
what stage you begin incorporang accessibility, you
can increase or limit your ability to employ accessible
design by aecng your meline or your aachment to
current designs.
Starng at the Concept Stage
In addion to obvious consideraons like choosing
an accessible color palee (see Chapter 9), designing
an interacve experience for accessibility starts
with the most important queson of all: “What do I
want the user experience to be?” The answer to this
queson aects every aspect of your design and
implementaon. Without answering this queson,
most developers nd themselves at the end of the
project with several accessibility barriers they had not
considered. And listening to an image descripon is
an interacve experience that should be considered.
Mapping out the user experience will help idenfy
how the informaon is presented and possible
opons for the user to interact with it while absorbing
meaningful content.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 79
Other consideraons should include the following:
1. Am I using color alone as a way to
understand content or interacons?
2. Am I providing keyboard-based navigaon that
oers important informaon and context?
3. Does my presentaon method meet
minimum contrast requirements?
4. Am I providing text alternaves for
image-based data visualizaons?
Considering accessibility in the concept stage allows
the most freedom for change and has the least impact
on schedule and development.
Starng at the Dra Stage
If you are starng to consider accessibility once a
dra has already been developed, you sll have me
to make more accessible design and implementaon
choices. Color palees can be reviewed. Text
alternaves and presentaon methods can be
evaluated with assisve technology for barriers and
meaningful informaon. But any changes may be
harder to implement at this stage. Those who approve
the content may have already formed aachments to
the dra colors and methods. The best way to shi
senment at this stage is to provide soluons when
encountering barriers. In my career, I have experienced
overwhelmingly negave pushback when my
evaluaons only surfaced accessibility failures without
also providing soluons.
Starng at the Final Stage
Even if you are starng at the end, there is sll
hope for creang an accessible product. With many
visualizaons, you can slightly darken colors to meet
contrast thresholds, adjust alternate descripons
to be more meaningful, and modify tags or tag-only
content to present a beer user experience for those
using assisve technology. But taking these steps is
not always easy. Starng accessibility work aer the
project is fully developed is like baking an apple spice
cake for someone who doesn’t like apples and asking,
“can’t you just take them out?”
Now that we’ve established that the earlier we
consider accessibility in our designs, the beer
they’ll be, let’s walk through some approaches,
both basic and complex, for creang accessible
visualizaons and PDFs.
The Basics
Several essays in this volume have discussed strategies
and tools to write sucient alt text for graphs
and images. The Web Accessibility Iniave—an
internaonal public-interest nonprot organizaon
working to develop standards for the web—has
established a basic approach for providing text that
describes nontext content such as images, charts, and
graphs.
[2]
Although the Web Accessibility Iniave
technique suggests supplying short, meaningful
alternave descripons, that approach can leave a
substanal informaon gap between what a visual
reader can perceive and what is provided to people
who rely on alternave descripons or formats. Even
though the Web Accessibility Iniave does not
suggest a minimum or maximum length for alt text, the
most common approach is two to three meaningful
sentences about the key features or important data.
But how can we present a richer user experience?
How can we relay more than overviews and summaries
while providing an equitable user experience?
Again we must ask ourselves the driving queson
menoned earlier: What is the expected user
experience? This queson drives every decision we
make. Do we want to enable users to explore every
data point in a chart or graph? Do we want to explain
relaonships or tell stories?
The environment of the presentaon also maers.
In an HTML web page, we can use a variety of tools
to enable readers to interact with the visualizaon.
Image maps, JavaScript code, ARIA-described tags (see
Chapter 5), and long-descripon (“longdesc”) tags can
all be placed along an image on a webpage. In a PDF
document, we do not have access to the same HTML
tags, so we need to take dierent approaches.
80 DO NO HARM GUIDE
Accessibility Tools & Terms
Some of the benets of presenng complex
nontext content in a PDF document
include the ability to use layers, content key
metadata, alt text, actual text, and gure
tags. Another unique benet is the ability to
maintain visual presentaon while providing
an alternave experience through assisve
technology. Tesng your approach with a
screen reader or other assisve technology
is key when applying any of these methods
to verify the technique provides a good user
experience (see Chapters 6 and 7).
•
Figure tag: A structural marker given to a
nontext object that idenes it and holds
addional programmac informaon about
locaon, content type, and other properes.
•
Content key: A property of the gure tag that
holds descripve text in accordance with PDF/
UA (Portable Document Format/Universal
Accessibility) requirements. However, this value
is not currently being voiced by JAWS (Job
Access with Speech) or NVDA (NonVisual
Desktop Access), two of the major screen
reader tools currently available.
•
Alt text: Alternave descripon that describes
the meaningful elements of a photo or graphic.
This text cannot be paused when being read. It
should be two to three meaningful sentences
and avoid excessive punctuaon.
•
Actual text: A one-to-one replacement for
images of text (e.g., “Sale.” for a photo of a
banner that says ‘SALE’).
•
Expansion text: Descripon metadata for
dening acronyms or abbreviaons. (e.g.,
“IAAP: Internaonal Associaon of
Accessibility Professionals”).
•
JAWS: A commercial screen reader used mainly
in professional environments.
•
NVDA: A free screen reader used worldwide.
The Four Basic Approaches to
Richer Infographics
In addion to alt text, the following four
approaches push the envelope for richer infographic
presentaons. I won’t show all of the steps to add or
edit these features, but these techniques can be a great
starng point for you and your team to consider when
building more accessible content into your PDFs.
1. Repurposing text labels for charts and graphs:
Accessible bar charts, pie charts, and line graphs should
include clear labels and data points for each meaningful
element in the series. If we keep these objects as
selectable text, we can target these elements as
headings inside the tags tree (indicated with blue arrows
in the next image) and apply “actual text” to include the
repeang axis informaon along with the actual data
value as shown in the “actual text” eld. This approach
allows the user to step through each data point at their
own pace. Giving the user control over how they review
the data is far beer than presenng them with a
generalized alternave text descripon that cannot be
paused for data-point review.
Alternavely, you can tag each bar as a gure and add
alt text that includes the data point, axis labels, and any
trends or meaningful correlaons visually present. You
can use the Content Panel in the PDF document to nd
each element and create a gure tag from each group.
Any axis labels can be repurposed as headings. The
main dierence of this approach would be that a person
using a screen reader would hear “graphic” for each
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 81
gure element before the alt text is read. Again, your
approach is dictated by the queson “What do I want
the user experience to be?”
2. Breaking up the pieces: If you are a graphic
designer, you should be familiar with the idea of
slicing. This is an older method of presenng large
graphics in web pages by cung the image into
several pieces that load more quickly on the site. In
a PDF document, you can use alt text to employ a
similar approach by presenng a series of images that
tell a sequenal story. The basic approach is to start
the series by introducing the series of graphs to the
reader. In the image below, the rst piece of alt text
might say, “The following nine graphics illustrate the
lifecycle of water. First, water evaporates from the
ocean heated by the sun’s rays.” The number of slices
is dictated by the depicon of the graphic. Then we
apply appropriate alt text to each slice of the image to
describe the process or data values as needed.
As the content creator, you will need to gure out how
many separate thoughts are presented and ensure
that you have sliced your images into enough pieces
to tell the story. It is not crical that the visually
represented slices are perfectly limited to the elements
in the descripon. For screen reader users, the story
being presented needs to represent the correct
number of descripons to tell the visual story. But
there is a balance to consider for those using assisve
technology who also have sight. You should slice your
images in a way that considers the user might try to
draw correlaons between the slice and the associated
text. Be as close to logical as possible given the
complexity of your graphic.
82 DO NO HARM GUIDE
3. Accessing Taggable or Live Content: This approach
is similar to how we selected the bars in the rst
approach. If we keep our graphic vector based (e.g., in
Adobe Illustrator or Encapsulated PostScript le
formats) and taggable, we can tell stories through
these elements using a combinaon of imagery,
symbols, and text rather than using a single raster-
based graphic (e.g., JPEG and PNG). Keeping elements
separate and taggable allows us to create accessible
experiences in the source document when using
programs like Adobe InDesign or by tagging them
individually in the PDF. How you tell the story is
important so the user can step through the elements
in a logical and meaningful way. This order will also
determine the tag order.
4. Using layers: One of the easiest ways to present a
text-based alternave experience is by using Adobe
Acrobat’s ability to layer content. This feature is
especially useful when we need to show things like
organizaonal charts, process trees, or other text-
heavy infographics.
The process of placing images on top of background
text allows the visual reader to have the experience
that they are used to and allows assisve technology
users to access structured, meaningful, accessible
descripons. This layered approach is especially
useful for organizaonal charts that can be presented
with nested lists and headings to mimic the visual
presentaon. With ow charts, for example, the text
equivalent can follow the same format.
If we evaluate the world map graphic on the following
page, we can see there are pin points all over the map,
making it essenally one big list. We could use the
accessible tagging approach (approach number three)
to tag the live content if the graphic were placed in
an Adobe Illustrator le. But if the graphic was a PNG
or JPG image le, then using layers might be our best
approach. We place a text-based list under (behind)
the map that is accessible to people using assisve
technology. This method is most easily implemented
when we have access to les where we can control
the ow of text. It is also possible to add this list using
Acrobat, but that process is much longer and requires
individually creang a series of List Item (<LI>) tags
and placing the text in each one.
Again, designing with accessibility in mind saves me
and presents a more informave user experience.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 83
Conclusion
No maer which of the four soluons or combinaons
we use, the rst queson we must always ask of our
graphic is “What is the expected user experience?”
The answer will provide more clarity for the path
that is most appropriate for your situaon and your
content. The development of accessible infographics
hinges on the premise of designing with accessibility
in mind. The accessibility skill level of the remediator
must also be considered. Each approach has me and
skill consideraons that can aect your project. The
sooner you consider accessibility soluons, the beer
prepared you will be to implement your approach and
test the outcome against your desired experience.
“Accessibility at the end”—where accessibility features
are tacked on at the end of the project rather than
throughout the enre workow—limits our creavity
and our ability to reach more readers and users.
Meeng the basic guidelines of the Web Content
Accessibility Guidelines creates compliance, but
considering the user interacon pushes us closer to a
more equitable user experience for all. Our expected
outcome dictates our approach. Understanding what
we expect the user experience to be molds every
decision we make from that point forward. I am a
rm believer that infographic equity can be achieved.
Accessibility does not have to be ugly, and we can
create a good user experience with a lile planning.
First, we just need the answer to the ulmate
queson, “What do I want the user experience to be?”
84 DO NO HARM GUIDE
Chapter Eight Notes
[1]
Mahew Pritchard, “Data Visualizaon vs. Infographics,” Infographics, Killer Visual Strategies News & Updates, Visual Communicaon
(blog), December 1, 2016, hps://killervisualstrategies.com/blog/data-visualizaon-versus-infographics.html.
[2]
“Tips and Tricks,” World Wide Web Consorum Web Accessibility Iniave, last updated April 12, 2017, hps://www.w3.org/WAI/
tutorials/images/ps
PART FIVE
Accessibility in Teams
and Organizaons
86 DO NO HARM GUIDE
CHAPTER NINE
Building
Accessibility
Best Pracces
Into Your
Organizaon’s
Data Visualizaon
Style Guidelines
AMY CESAL
Data visualizaon style guides oer the
potenal to build accessibility best pracces
into organizaonal workows and culture.
Organizaons, their designers, and their
content teams oen rely on style guides to
maintain brand consistency in terms of color, font,
feel, and visual style, but style guides are more
than just guidelines. They can set organizaonal
standards and funcon as tools for organizaonal
process change.
Although design style guides have typically focused on the
tradional aspects of a brand’s visual style, I and others have
argued that these guides should be extended to include rules
for data visualizaon as well, with a parcular focus on
accessible visualizaons.
Because style guides can establish standards for the content an
organizaon produces, they provide a powerful opportunity to
incorporate accessibility standards from the ground up. Including
a topic within a style guide signals importance and organizaonal
commitment. Because data visualizaon style guides detail standards
and pracces for every aspect of a visualizaon, such as colors,
fonts, visual encodings, and branding, these standards can ensure
producon visuals meet the highest standards of accessibility.
In previous work,
[1]
I dened data visualizaon style guides
as “standards for formang and designing representaons of
informaon, like charts, graphs, tables, and diagrams. They include
what (e.g., types of charts) and why (e.g., reasons for using specic
colors).” Although style guides are disnct from templates, it is oen
common (and helpful) for organizaons to produce templates for the
tools they use to accompany the style guide (such as Excel, R, D3.js,
or Tableau). These templates can show how to create charts that
meet the standards set out in the guide and make it easy for people
to apply the standards.
Data visualizaon style guides should be designed to t within an
organizaon’s larger design system. Style guides maintain uniformity
across the dierent tools and soware that produce charts. An
organizaon’s charts should be consistent across tools and look
visually similar to the publicaons they are part of. Having a style
guide with principles and components that work across mulple
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 87
tools—rather than just one template for one tool—
helps achieve this consistency. Consistency builds
trust and ensures minimum quality standards are met.
From an accessibility standpoint, creang a data
visualizaon style guide allows an organizaon to
codify best pracces into their data visualizaon
design and producon workow. Accessible design
consideraons should be built into every aspect of
the style guide, including color selecon, typography,
line thickness, and the use of white space. It is also
appropriate for style guides to have a secon devoted
to addional accessibility measures beyond just visual
aspects. This secon can educate team members
about the importance of accessible design and the
ubiquity of users who benet from accessible design,
and it can provide tools such as alternave (alt) text
and Accessible Rich Internet Applicaon (ARIA) labels
to make designs work beer with screen readers and
other assisve devices.
Accessible Design Best Pracces
Data visualizaon style guides commonly include
secons devoted to dierent aesthecs, like color or
typography. In each of these, accessibility should be
considered and enumerated for team members as they
build and style their graphs, charts, and diagrams.
Color
Oen when we talk about accessibility and color, we
talk about color blindness, parcularly deuteranopia,
also known as red-green color blindness, a condion
experienced by about 8 percent of men and
about 5 percent of women of northern European
ancestry.
[2]
The focus on color blindness to the
exclusion of other color accessibility consideraons
mirrors our collecve tendency to pay the most
aenon to problems that aect (usually white) men.
Although designing to accommodate color blind users
is certainly important, we can do more.
About 6 percent of the US populaon has some sort of
vision impairment. Thus, we should also consider the
needs of users with low vision, and we can do so
by ensuring there is enough contrast between
foreground and highlight colors and the chart
background color. Colors within a palee should also
be visually disnguishable from each other; this is a
parcular challenge when an organizaon has a large
color palee.
The contrast rao between foreground chart colors
and the chart background should be measured
according to the Graphical Objects and User Interface
Components standard from the Web Content
Accessibility Guidelines and can be tested using a tool
such as WebAIM’s Contrast Checker tool. This tool
includes values for compliance based on guidelines
dened by the Web Content Accessibility Guidelines,
an internaonal group responsible for seng
guidelines for the web (see also the appendix to this
volume for a list of similar tools). Color blindness
checkers like the Coblis Color Blindness Simulator can
be used to test whether colors within a palee are too
similar for someone with color blindness. Larene Le
Gassick discusses a variety of other tools in Chapter 7,
and others are listed in the appendix at the end of
this volume.
Some colors have strongly associated social
meanings developed over repeated use. In US
polics, blue is strongly associated with Democrats,
and red with Republicans. Green means “go,”
yellow means “cauon,” and red means “stop” or
“warning.” Style guide color selecon should be
conscious of, and work with rather than against,
these associaons. Using colors in a manner
inconsistent with exisng associaons increases the
cognive load on the viewer.
Praconers should either not use color pairings
or palees that have parcularly strong preexisng
associaons or should use these colors in alignment
with users’ expectaons. At the same me, some
exisng color associaons (e.g., blue for boys and pink
for girls) may be problemac because they reinforce
exisng stereotypes, so praconers should be
cauous about their usage.
[6]
88 DO NO HARM GUIDE
On the next page is a brand-consistent color palee
I created for the Sunlight Foundaon that includes
consistent categorical colors for data we frequently
visualized (e.g., spending and polical party), which
played into exisng associaons.
When choosing brand-consistent palees for a
style guide, designers aempt to opmize for brand
recognion, visual disncveness, color vision
deciency friendliness, number of colors, contrast, and
any potenal implied or associated meanings of colors.
But one set of colors may not be capable of balancing
all those consideraons and achieving all those aims.
Instead, a set of palees within a style guide should
represent compromises across these consideraons
to meet the organizaon’s needs and the needs
of their users. Some palees might be beer than
others for achieving certain aims, and organizaons
can have several approved opons for designers to
choose from depending on the applicaon. A detailed
guide to colors in data visualizaon style guides by
Lisa Charloe Muth goes into further examples from
organizaons
.[6]
For some users, color will always pose a problem
even when we do our best to nd accessible palees.
Given the constraints that color presents, we should
consider how much we really want to ask colors to do
in our charts. Oen it can be helpful to “dual encode”
our data—that is, combine color and another shape
or texture to communicate the data. In a scaerplot,
points can be colored by a categorical variable and
have their shapes determined by that variable. Dual
encoding this way always increases accessibility and
makes a chart more readable to a wider audience. The
image on the following page, again from the Sunlight
Foundaon, provides an example of dual encoding in a
scaerplot.
In line charts, instead of dual encoding, we use
direct labeling. Whenever possible, directly label a
chart’s lines, points of interest, or bars. This feature
tends to be more accessible and requires less work
from a reader than a chart legend, which requires the
user to look back and forth between the legend and
the chart area.
Similarly, a chart with mulple abung colors,
such as a stacked bar chart, can be dicult for a
vision-impaired user to process (see top of page 90).
Separang each of these color secons with a white
stroke is an easy way to provide visual disncveness
between secons, increasing contrast and accessibility.
Labeling and Typography
When wring the text for a chart, we need to consider
what we say and how we say it. The style guide
species how headings, subheadings, axis labels,
and legends should look and be wrien. Using plain
language goes a long way toward ensuring that the
broadest possible audience can understand a chart—
the Plain Wring Act of 2010 denes plain language
as “wring that is clear, concise, well-organized, and
follows other best pracces appropriate to the subject
or eld and intended audience.”
[8]
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 89
Source: Sunlight Foundation, “Data Visualization Style Guidelines,” accessed October 13, 2022, https://github.com/
amycesal/dataviz-style-guide/blob/master/Sunlight-StyleGuide-DataViz.pdf
.
CMYK: 12, 24, 100, 0
RGB: 227, 186, 34
Hex: #E3BA22
CMYK: 27, 84, 96, 22
RGB: 154, 62, 37
Hex: #9A3E25
CMYK: 6, 9, 78, 0
RGB: 242, 218, 87
Hex: #F2DA57
RGB: 189, 143, 34
Hex: #BD8F22
CMYK: 25, 60, 69, 8
RGB: 179, 112, 85
Hex: #B37055
CMYK: 7, 57, 97, 1
RGB: 230, 132, 42
Hex: #E6842A
CMYK: 89, 52, 27, 6
RGB: 21, 107, 144
Hex: #E6842A
CMYK: 86, 35, 46, 10
RGB: 19, 123, 128
Hex: #137B80
CMYK: 58, 34, 73, 13
RGB: 112, 130, 89
Hex: #708259
CMYK: 48, 61, 28, 4
RGB: 142, 109, 138
Hex: #8E6C8A
CMYK: 18, 95, 98, 8
RGB: 189, 45, 40
Hex: #BD2D28
CMYK: 42, 38, 49, 4
RGB: 151, 143, 128
Hex: #978F80
CMYK: 84, 24, 60, 5
RGB: 15, 140, 121
Hex: #0F8C79
CMYK: 67, 30, 100, 13
RGB: 92, 129, 0
Hex: #5C8100
CMYK: 2, 31, 76, 0
RGB: 246, 182, 86
Hex: #F6B656
RGB: 186, 95, 6
Hex: #BA5F06
CMYK: 64, 38, 20, 1
RGB: 104, 139, 171
Hex: #688BAB
CMYK: 70, 17, 28, 0
RGB: 66, 165, 179
Hex: #42A5B3
RGB: 0, 93, 110
Hex: #005D6E
CMYK: 44, 27, 57, 2
RGB: 149, 161, 126
Hex: #95A17E
CMYK: 31, 42, 18, 0
RGB: 179, 150, 173
Hex: #B396AD
RGB: 104, 70, 100
Hex: #684664
CMYK: 6, 79, 80, 1
RGB: 226, 90, 66
Hex: #E25A42
CMYK: 25, 22, 32, 0
RGB: 193, 186, 169
Hex: #C1BAA9
RGB: 124, 113, 94
Hex: #7C715E
CMYK: 58, 5, 45, 0
RGB: 107, 187, 161
Hex: #6BBBA1
CMYK: 43, 12, 100, 0
RGB: 160, 183, 0
Hex: #A0B700
Main Colors
Specialty Colors
a thing
Republican
a subset of the thing
a subset of the thing
a subset of Republican
a different thing
Democrat
another different thing
Independent
another different thing
Con
neutral thing
Pro Money
a subset of the different thing
a subset of the different thing
a subset of Democrat
a subset of the other different thing
a subset of the other different thing
a subset of independent
a subset of the other different thing
a subset of the other different thing
a subset of Con
a subset of the neutral thing
a subset of the neutral thing
a subset of Pro a subset of Money
Data Colors
CMYK: 9, 8, 8, 0
RGB: 229, 226, 224
Hex: #E5E2E0
No Data
Source: Sunlight Foundation, “Data Visualization Style Guidelines,” accessed October 13, 2022, https://github.com/
amycesal/dataviz-style-guide/blob/master/Sunlight-StyleGuide-DataViz.pdf.
Title of the chart
For explanatory text that’s not very long.
Y Axis Title
6,000
5,000
4,000
0
Label 1 Label 2 Label 3
X Axis Title
Source: www.fruitsperbushel.com
EXAMPLE
When to use a Scatter Plot
» Shows the relationship between two continuous
variables for your set of observations
» Each point in the plot represents an object.
» You can change color or symbol to show groups.
» Sometimes it is nice to show a trend line
(regression).
Your data should look like:
variable 1 variable 2
7.560309668 48.87193277
8.569477057 57.70873996
5.178854559 35.50990599
5.044602676 31.94896911
7.629095533 49.76954493
6.631379 46.66529366
7.035723733 45.68632108
8.152163624 57.46279438
FirstName
LastName
FirstName LastName
FirstName
LastName
FirstName
LastName
Scatter Plot (multi variable)
Apples
Oranges
Pear
Papaya
Possible Key:
Fill: Background dark
Accent (#E5E2E0)
Line: Line Grey
(#C0C0BB)
Change both color
and shape if possible
(helps with sight
issues)
90 DO NO HARM GUIDE
A data visualizaon style guide should provide
guidance on how to use labels, tles, and legends
eecvely, and it should detail the most readable
fonts, sizes, and spacings. For maximum accessibility,
charts should include “takeaway tles”
[9]
that
succinctly communicate the main takeaway of the
visualizaon. By telling viewers what you want them
to get out of a chart, you prepare them to view the
chart with that in mind, decreasing the cognive load
required to understand the data presented. Titles
should be pitched to the level of the chart’s intended
audience, communicang ndings in terms familiar to
them. Subtles or footers can be used to provide more
technical details if necessary for accuracy.
In terms of visual design, typography needs to be
large enough and have high enough contrast relave
to the background to serve low-vision populaons.
For maximum legibility, the number of dierent fonts
used should be kept to a minimum—the chart should
be the focus rather than the fonts. Across charts, be
consistent with fonts as well as the sizing of tles,
labels, and legends; this will maintain brand identy
and ensure all charts produced by an organizaon
are readable.
Historically, sans-serif fonts (meaning leerforms
that do not have extending features at the ends) have
been considered easier to read on computer screens
because of low screen resoluons. Now that high-
quality screens are more common, that thinking is less
true. Current evidence on font readability is mixed
and suggests there is not a universally accessible font.
Rather, font readability depends on the individual
and the kind of disability they have. In this context,
I suggest choosing relavely simple and common
fonts and to use few font families in the same chart.
Condensed fonts are oen useful in data visualizaon
applicaons where space is limited, but their compact
nature can hinder vision-impaired users.
In general, the most important consideraons for
text on charts are maximally informave content and
appropriate spacing, size, and contrast. Rather than
leaving these selecons to ad-hoc decisions made for
each individual chart design process, data visualizaon
style guides set up rules for funconal and accessible
chart text.
Layout and Style
A style guide should include layout instrucons that
specify the spacing between chart area, legends,
tles, axis labels, footer, the organizaon’s logo,
and any other visual features that go on a typical
chart. Overcrowding can be a serious impediment to
readability because charts that are cluered are more
dicult for users with visual or cognive impairments.
Unnecessary cluer increases cognive load, and
insucient spacing between items may cause them
to bleed together when viewed by those with vision
impairments. By prespecifying the spacing of elements
in a chart, every chart will be more consistent,
readable, and accessible.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 91
Accessibility Secon
Although accessibility should be built into the design
choices throughout the style guide, an accessibility-
specic secon should also be included. Here, you
can provide specic instrucons on how to write alt
text for data visualizaons and how to include alt
text in whatever publicaon formats will be used for
distribuon (see Chapters 4 and 8 of this volume
for strategies).
This secon should also discuss the reasons that
accessibility is an important consideraon. When
charts are made with accessibility in mind, they are
beer and useful for everyone, not only for people
with disabilies.
Accessibility-Specic Addions
Thoughul visual design with accessibility in mind
is a good start, but it is not enough on its own.
Addions need to be made to improve accessibility
for screen readers. These addions also improve
general computer readability (including search engine
opmizaon, making your content more easily found
through web searches).
Alt Text
Alt text provides a descripon of stac-image charts
in digital mediums and is added as a tag on the image.
Organizaons should dene how to add this tag for
their content and what should be included in it to help
people understand the content of the chart.
WebAIM, a group housed at Utah State University,
explains that alt text allows the content and funcon
of the image to be accessible to those with visual or
certain cognive disabilies. They also add that alt
text provides a semanc meaning and descripon to
images that can be read by search engines or be used
to later determine the content of the image from the
page context alone.
[10]
As I have wrien for the Nighngale blog,
[11]
•
If an image contains meaningful informaon,
adding alt text is beer than not doing
anything at all.
•
If you can add HTML properes to the image,
add a long descripon
[12]
to more fully convey the
image’s meaning.
•
Supplement your image with a link to the raw
data so curious readers can access the data in
their preferred program.
•
Keep alt text short. Alt text is read linearly by
screen readers, which means that people can’t go
back a word if they miss something. For search
engine opmizaon purposes, Google cuts o its
crawl aer a certain number of characters.
Alt text for data visualizaon can follow the
following format:
ARIA Labels
ARIA labels can be applied to interacve visualizaons
to help users understand the data elements being
displayed.
WebAIM says, “WAI-ARIA (Accessible Rich Internet
Applicaons or ARIA) is a W3C [World Wide Web
Consorum] specicaon for enhancing accessibility
in ways that plain HTML cannot. When used properly,
ARIA can
•
enhance accessibility of interacve controls, such
as tree menus, sliders, pop-ups, etc.,
•
dene helpful landmarks for page structure,
•
dene dynamically-updated ‘live regions,’
•
improve keyboard accessibility and interacvity,
•
and much more.”
[13]
For more informaon on how to properly use ARIA
labels and apply them to data visualizaon, see
Chapter 5 of this volume.
Tesng
So far, I have menoned and linked to several useful
tesng tools, specically for colorblindness and
contrast tesng. When designing a style guide, all
92 DO NO HARM GUIDE
palees and templates should be pretested using
these tools so people don’t need to redo that work
every me they make a chart. But another type of
tesng, user tesng, is the best step an organizaon
can take to make more eecve and accessible charts.
The more inclusive that user tesng is, the beer: user
tesng with people with disabilies is a best pracce
for building accessible charts. However, ensure a basic
level of accessibility is in place before engaging in user
tesng—don’t present a product that is completely
nonfunconal on screen readers to your screen-
reader testers and expect them to provide meaningful
feedback.
By geng the charts in front of the intended users
before publicaon, you can see which aesthecs and
mappings are confusing, which labels are ineecve,
and which interacons are lost. More tesng is beer,
but incorporang people with disabilies into the
building and tesng process is best. Watching a user
with a screen reader try (and probably fail) to paginate
across elements in your online, interacve chart will
tell you a lot about what you need to be doing beer.
Working with designers who are colorblind, are vision
impaired, or use assisve technology will help ensure
that you build the most accessible products you can.
Many organizaons and consultancies, such as Fable
or Knowability,
[14]
are equipped to help with this work.
Unfortunately, not all projects have the scope and
budget to hire experts or pay user testers. But you
shouldn’t give up on user tesng. Doing some tesng
is beer than doing no tesng, and the former can
be as easy as asking a coworker or friend to give
your product a try. This process, having a handful of
users test something for a limited amount of me, is
somemes called “guerilla tesng.”
[15]
Adopon
A style guide is not useful if no one at the organizaon
uses it. People have to know about it and nd benet
from using it. If the style guide is seen as a burden and
its value isn’t clear, it will be ignored and forgoen.
Involving people from several parts of the organizaon
in the creaon of a style guide can increase its
adopon. If people are involved in building it, they
will feel some ownership over it and champion it to
their departments. You will also get a larger variety
of perspecves and users, which will make the guide
more robust and inclusive. I recommend beginning
the data visualizaon style guide process with a series
of informaonal interviews with chart creators and
consumers throughout the organizaon to idenfy the
organizaonal needs the style guide will serve and to
engage people across the organizaon in craing a
product that makes their jobs easier.
If the style guide is followed by much of the
organizaon, the charts and graphs created using it
should be more accessible. Templates based on the
best pracces from the guide and available for several
dierent applicaons the organizaon uses can help
improve eciency and adopon.
Training
Training can also increase style guide adopon, and it
involves a two-pronged approach that reaches both
new and exisng employees. When new employees
join the organizaon, they should be trained on
using the style guide and templates. If they learn to
use these resources when they start, they are much
more likely do so consistently. From the beginning, an
organizaon should emphasize accessibility and why it
is important.
However, onboarding is oen overwhelming, and
the company and style guide will evolve over me.
[16]
Oering ongoing advanced or refresher training on
best pracces allows people to stay current on the
style guide or catch informaon at mes when they
actually need it. Ongoing trainings also allow current
employees to stay in the know and to ask quesons
about how to apply the guide to specic use cases.
The guide needs to work for them and provide a
conversaon rather than a mandate.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 93
Persuade and Adapt
Some people will proacvely seek out ways to use a
data visualizaon style guide. These people should be
rewarded and highlighted as good examples.
It is also helpful to look at where charts are not
working or why creators are not using the templates
and style guide. Maybe they don’t know about them or
how to use them. Or maybe the guide doesn’t work for
them, which would suggest a need to tailor or adapt
its recommendaons to t their needs. Such cases
present an opportunity to expand the guide and dene
a new use case to increase adopon.
Culture of Data Viz and Accessibility
Creang a culture of talking about data visualizaon
and accessibility (together and separately) will increase
awareness and knowledge in the organizaon.
Creang conversaons about current accessibility
pracces will increase awareness and bring it to mind
as a relevant topic for content creators. Sharing good
examples from inside and outside the organizaon can
further these conversaons.
Both the accessibility and data visualizaon
communies are extremely acve, with speakers
on this topic at events and conferences. The Data
Visualizaon Society has an annual conference,
Outlier, which includes talks on accessibility. The
society also has a calendar of events that includes
discussions of accessibility. Deque, a soware
accessibility company, hosts an annual conference,
Axe-Con, which includes talks about data visualizaon.
Creang a culture where data visualizaon and
accessibility are topics discussed promotes connuous
learning and encourages people to keep up with
current standards.
Style guides are a crical rst step toward
maintaining this culture of connuous learning. As
data visualizaon professionals, it is imperave that
our work be accessible for all people, and having
consistent standards that include accessibility best
pracces can help us achieve those goals. Accessible
charts tend to be beer charts. They are easier to
read for everyone—they have colors that stand out,
communicate their meaning, and don’t confuse
readers. They are not too cluered, the text is easily
understood, and they don’t place undue cognive
burden on the readers. They can be read in mulple
ways, such as on a screen or with a screen reader.
When we design accessibly, we design for broad
impact, so as many people as possible can engage with
our work. An eecve style guide helps us front-load
the design work and lets us set standards for how we
want to manage the trade-os necessary to build the
best, most accessible visualizaons we can.
94 DO NO HARM GUIDE
Chapter Nine Notes
[1]
Amy Cesal, “What Are Data Visualizaon Style Guidelines?” Nighngale Journal of the Data Visualizaon Society (Medium blog), July 10,
2019, hps://medium.com/nighngale/style-guidelines-92ebe166addc.
[2]
Bang Wong, “Color Blindness,” Nature Methods 8, no. 6 (2011): 441. hps://www.nature.com/arcles/nmeth.1618.pdf.
[3]
“Web Content Accessibility Guidelines (WCAG) 2.1,” W3.org, accessed October 13, 2022, hps://www.w3.org/TR/WCAG21/. See also
“Understanding Success Criterion 1.4.11: Non-Text Contrast,” W3.org, accessed October 13, 2022, hps://www.w3.org/WAI/WCAG21/
Understanding/non-text-contrast.html.
[4]
“Contrast Checker,” WebAIM, accessed October 13, 2022, hps://webaim.org/resources/contrastchecker/.
[5]
“Coblis —Color Blindness Simulator,” Colblindor, accessed October 13, 2022, hps://www.color-blindness.com/coblis-color-blindness-
simulator/.
[6]
Lisa Charloe Muth, “An Alternave to Pink & Blue: Colors for Gender Data,” Datawrapper Blog, July 10, 2018, hps://blog.datawrapper.
de/gendercolor/.
[7]
Lisa Charloe Muth, “A Detailed Guide to Colors in Data Vis Style Guides,” Datawrapper Blog, March 30, 2022, hps://blog.datawrapper.
de/colors-for-data-vis-style-guides/.
[8]
Plain Wring Act of 2010, Pub. L. 111 – 274, 124 Stat. 2861–63 (2010). hps://www.govinfo.gov/app/details/PLAW-111publ274/
summary.
[9]
Cole Nussbaumer Knaic, “So What?” Storytelling with Data blog, March 23, 2017, hps://www.storytellingwithdata.com/
blog/2017/3/22/so-what.
[10]
“Alternave Text,” WebAIM, accessed October 13, 2022, hps://webaim.org/techniques/alext/.
[11]
Amy Cesal, “Wring Alt Text for Data Visualizaons” Nighngale Journal of the Data Visualizaon Society (Medium blog), July 23, 2020,
hps://medium.com/nighngale/wring-alt-text-for-data-visualizaon-2a218ef43f81.
[12]
“Complex Images — Long Descripons,” W3.org, accessed October 13, 2022, hps://www.w3.org/WAI/tutorials/images/complex/#long-
descripons.
[13]
“Introducon to ARIA – Accessible Rich Internet Applicaons,” WebAIM, last updated June 30, 2020, hps://webaim.org/techniques/
aria/.
[14]
“Accessibility Testers,” Fable, accessed October 13, 2022, hps://makeiable.com/testers/; “Usability Tesng with People with
Disabilies,” Knowability, accessed October 13, 2022, hps://knowbility.org/services/usability-tesng.
[15]
Guy Ligertwood, “Guerilla Tesng: Hallway Usability Tests for UX,” Adobe XD Ideas, April 15, 2020, hps://xd.adobe.com/ideas/process/
user-tesng/hallway-usability-test-guerrilla-tesng/.
[16]
Ben Charto, “Urban Instute’s Data Visualizaon Style Guide: A Living Document,” Data@Urban (Urban Instute Medium blog), March
19, 2018, hps://urban-instute.medium.com/urban-instutes-data-visualizaon-style-guide-a-living-document-b90710702a9f.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 95
CHAPTER TEN
Nontechnical
Barriers to Data
Visualizaon
Accessibility in
Government
MELANIE MAZANEC
As a new soware developer in city government,
I was tasked with making the city’s public-facing
dashboards accessible. Up to that point, all
the technical documentaon I had needed as
an engineer had been easily discoverable in a
web search. So I was ummoxed to nd almost
nothing about data visualizaon accessibility.
Aer weeks of reading blog posts, the “talk” secons of wikis, and
comments on coding forums, I hesitantly implemented automated
text labels and keyboard navigaon paerns. I was never able to
secure funding to conduct usability research, nor was I successful
in any eorts to partner with local disability advocacy groups to
formalize a government technology advisory council.
Although my work was experimental and incomplete, it helped
me connect with expert praconers from whom I have learned a
great deal. Knowing how hard it had been for me to nd resources,
I proacvely shared new accessible data visualizaon guidance
that I learned about and volunteered implementaon support
to colleagues in government technology. I assumed that people
drawn together by mission-driven work would be excited to make
democracy more inclusive and that the only thing holding them back
was a lack of informaon.
Unfortunately, I was wrong. Fellow tech workers consistently told me
that accessibility was an edge case that only aected a few people,
that it didn’t maer because dashboards weren’t public facing, that
the client hadn’t asked us to work on accessible data visualizaon,
or that we would address accessibility problems “aer we are done
building the product.” Even though I had the informaon readily
available, that wasn’t enough to make people value, understand, or
apply it.
In retrospect, I should have known beer. Despite the many web
accessibility resources and trainings available, most websites sll
have easily remedied problems.
[1]
And although large employers like
governments, banks, and universies have accessibility mandates,
computer science programs and coding bootcamps consistently
fail to teach accessibility. It’s no wonder that a developer fresh out
of college rolled their eyes when I pointed out basic accessibility
problems in a code review.
96 DO NO HARM GUIDE
Making informaon available about data visualizaon
accessibility is a crucial rst step. Connecng a
community of praconers to build on one another’s
ideas is the next. To get government agencies to adopt
new pracces, we need to also recognize and address
the nontechnical barriers that public servants and
vendors face in implementaon.
Why Work on Data Accessibility in Government?
Public infrastructure shapes our lives for beer or for
worse. The placement of an urban highway can cut o
a neighborhood from economic opportunity. A road
widened to facilitate the ow of trac may preclude
kids from walking safely to school. Conversely, a
reliable bus system allows people to drive less, leading
to less congeson and demand for parking. And a wide
enough sidewalk with adequate room for both people
and trees can alleviate urban heat while sll making
room for strollers and wheelchairs.
Public infrastructure is not an inevitable natural
landscape, but the result of design choices made by
people. Human beliefs and biases inuence whose
needs are priorized and what kind of infrastructure
receives funding or support. People in power design
processes determining who can provide input or
make decisions. Public meengs held during the
day may exclude people with day jobs from showing
support for city iniaves. Input processes that
happen only in person could exclude people who are
immunocompromised. And state laws that require
cies nofy homeowners, but not renters, of public
meengs for proposed large-scale developments might
amplify the voices of wealthier people.
Modern public infrastructure includes more than
roads and buildings. Soware has become an integral
part of the built environment and makes our lifestyles
possible. And just as urban designers shape wealth
inequality, public safety, climate change, and mobility,
soware designers can create access or inequality
in the digital world. Biases and power dynamics
inuence every aspect of technology, such as who
may be encouraged to pursue an engineering career,
which pitches receive funding, or which projects are
priorized within a company.
Design decisions that prevent people with disabilies
from having equal access are ubiquitous in technology.
The 2022 WebAIM Million report evaluated the
top million websites using an automated test for
compliance with the Web Content Accessibility
Guidelines, or WCAG. Errors were detected on 96.8
percent of pages, with an average of 50.8 errors per
page.
[2] -
And, as demonstrated in 2017 by the Gov.UK
web team,
[3]
automated tests can only ag the types
of issues that are easiest for engineers to nd and
remedy, so there were likely many more errors present
than those found. The prevalence of automacally
detectable WCAG compliance errors indicates a much
deeper problem with the usability of the web.
The visual representaon of informaon in charts,
graphs, and diagrams is one area where undetectable
issues oen arise: the use of red and green to
disnguish categories in a stacked bar chart; a toolp
that is shown on mouse hover but is not operable by
keyboard; design soware that requires hardware
keyboard commands to operate but is incompable
with on-screen keyboards; or maps that use images
and textures to convey informaon not otherwise
available to people who are visually impaired or blind.
All of these issues can create inequitable experiences.
Although government is mandated to serve all people
equitably, “the state is embedded in and enmeshed
with civil society, not apart from or above it.”
[4]
The
soware industry’s proliferaon of visual tools with
accessibility problems cannot be separated from its
impact on government. As bureaucracy is digized,
data are generated by each process and transacon.
Governments use tools built by private companies to
collect, analyze, and visualize data. In turn, government
data analysts help monitor service performance,
inform policy changes, and share informaon with the
public. Programmers and analysts generate reports and
build dashboards for elected ocials, agency leaders,
city managers, and the general public. People whose
access needs are not considered in data analysis and
communicaon are excluded from these bureaucrac
and democrac processes.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 97
Public administraon scholars coined the term
“administrave discreon” to describe the way
public workers unocially shape policy through
implementaon decisions, which can even be
weaponized to advance polical agendas.
[5]
Beyond
elected ocials and public workers, others who
wield power in government include nonprots that
deliver public services or receive grant funding, and
private companies contracted to work on behalf of
government. It is necessary, then, to ensure these
means of exercising polical power beyond elected
representaon are accessible too. Work toward
accessible data visualizaons in government should
not be limited to public-facing dashboards and reports;
rather, it should include all tools used in governments
and organizaons that work with governments.
For government to represent all the people it serves,
it must make the informaon and systems that
facilitate parcipaon in governance available to
everyone. And for a government to generate inclusive
public infrastructure, it must also use accessible
digital infrastructure to support its operaons and
decisionmaking processes.
Implementaon Barriers
Although ocial guidance is lacking, many
informaonal resources created by data visualizaon
accessibility praconers have begun to form a body
of knowledge that can support anyone looking for
technical advice. However, building for accessibility
necessitates resources in the form of not just
informaon but also support from colleagues, public
leaders, and private-sector partners.
Ambiguity and a Lack of Standards for Accessibility
The current version of WCAG covers some data
visualizaon topics, including color, keyboard
interacvity, animaon, and text alternaves to
images. But the applicaon of WCAG guidance is
ambiguous when it comes to even simple interacve
charts, let alone complex collaborave design
interfaces. In cases where the visual is a stac image
secondary to the rest of the content, a text alternave
might be enough to oer a comparable experience (see
Chapters 4 and 8 in this volume for some guidance).
However, the proliferaon of interacve dashboards,
maps, and other tools with visual interfaces make it
both necessary and possible to nd novel ways to
build inclusively.
Thanks to a robust community of thoughul
praconers, nding examples and advice is now
easier than ever. Individuals and organizaons are
publishing code snippets, essays, and documentaon
to help others build accessible data visualizaon. The
Data Visualizaon Society incorporated accessibility
as a category on which a visualizaon can be judged in
their design contests. But the lack of formal standards
sll holds back progress on data visualizaon
accessibility in government.
First, the ambiguity of WCAG’s applicability to data
visualizaon leaves room for interpretaon in an
environment where experimentaon is frowned
upon. At the federal level, where Secon 508 (see
the Secon 508 box on the next page) incorporates
WCAG by reference, should only keyboard-navigable
dashboard tools be used, or are text alternaves
acceptable? How should a topographical map, a
Sankey diagram, or a scaerplot be described in text?
In local government, where WCAG is not mandated
but the less-specic Americans with Disabilies Act
sll applies, to what standards should vendors be
held? In the context of government, where the quality
of technology is measured more by its track record
of stability than by its future potenal, workers and
vendors are likely to err on the conservave side and
follow precedent. For data visualizaon, this recence
may mean providing a text alternave rather than
trying to follow new, informal data visualizaon advice.
98 DO NO HARM GUIDE
Secon 508
Secon 508 of the Rehabilitaon Act of
1973 (later amended by addional laws) is
one of several federal disability laws. Secon
508 requires federal agencies to “develop,
procure, maintain, and use informaon
and communicaons technology (ICT) that
is accessible to people with disabilies—
regardless of whether or not they work for
the federal government.”
[6]
This requirement
extends to websites, user guides for soware
and tools, online training, webinars and
teleconferencing, PDF documents, and more.
The requirements of Secon 508 have
been updated several mes to beer align
with modern technology and internaonal
standards. Today, Secon 508 incorporates
WCAG 2.0 by reference. Although these
guidelines do not apply to private-sector
businesses, the federal government must
ensure that it procures only 508-compliant
soware from the private sector.
Second, it takes more resources to start from scratch
than it does to start with standards. Even when
starng from blog posts, research papers, and YouTube
videos about a topic, an individual visualizaon creator
must put in hours of eort just to learn enough to
discern which advice to follow. In the absence of clear
consensus, they may end up reinvenng the wheel and
creang their own accessibility paerns, even though
established paerns have already begun to emerge
across dierent visualizaon tools. Although following
rules is never a replacement for usability research,
building on the experience of others can allow
developers to focus government’s exceedingly scarce
resources where they can make a larger impact.
Lastly, standards allow governments to convey
accessibility expectaons to vendors. WCAG
compliance is a convenient shorthand to include in
agreements with soware companies. It is easy to
look for on a website, ask about by email, or write into
a contract. In the absence of standards to reference,
a government might ask for accessibility in such a
vague way that any agreement is unenforceable. Or
requesng accessibility without referencing standards
may require so much prior knowledge of technical
implementaon that doing so is not feasible for
nontechnical government workers.
Referencing WCAG standards in Secon 508 for the
federal government did not magically change culture,
funding, or entrenched legacy soware overnight. The
(gargantuan, unnished) project of improving federal
web accessibility has taken this mandate, as well as
a corps of digital services professionals movated
by a shared dream of high-quality public services,
and a generaon of disability rights acvists holding
government accountable. Neither can we expect data
visualizaon standards to accomplish any miracles.
But working a clearer mandate into exisng digital
accessibility guidelines, especially for simpler cases,
would give public employees a place to start.
Limited Resources Are Subject to Power
Dynamics and Diusion of Responsibility
Even if clear standards for data visualizaon existed
and were mandated by law, enforcing them would
sll be a separate maer. Whose responsibility is it
to ensure that government data visualizaons are
accessible, and what support might they have?
Analysts
An individual government worker who wants to
make their data visualizaon work accessible might
face limitaons. Analysts may not have the training
or funding to learn how to create accessible data
visualizaons. Most government soware users,
including creators of documents, presentaons, PDFs,
web content editors, and data visualizaons, are not
trained in accessibility.
Even those who are experts in data visualizaon
accessibility may sll be stymied by the limitaons
of the tools they are using. Most stascal soware
limits control over data presentaon to minor choices
like graph type, color, and axis labels (see, e.g., Chapter
5). If an analyst has the freedom to choose dierent
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 99
soware, they may not have the me or capability
to evaluate the comparave accessibility of dierent
tools. And many analysts, especially in government,
are restricted in their choice of tools to whatever their
predecessors chose (or whatever the organizaon
procured) long ago.
Analysts are also limited in their choice of tools by
what is available from the private sector. Custom
soware is so me consuming and expensive that it is
usually only jusable for a highly specialized product
that will serve many users, a product that will need
to be changed frequently, or small projects. For most
products that are commercially available, including
soware for word processing, email, spreadsheets,
and stascs, a government or agency could never
hire enough engineers to come close to Google or
Microso’s economy of scale. Instead, governments
use the soware products that technology companies
choose to make. If private-sector companies do not
make their products accessible, government workers
who use these tools in turn are restricted in their
accessibility eorts.
Engineers
Although most data visualizaons in government
are generated by stascal soware procured from
the private sector, some are custom made by front-
end soware engineers. Because engineers have a
greater degree of control over the appearance and
funconality of their visualizaons, they can more
easily implement accessibility recommendaons.
But having a greater degree of freedom in technical
choices does not always mean having more control
over one’s work environment.
Engineers whose tasks are set by a project manager
may have very lile say in priorizaon. An engineer
with autonomy in choosing day-to-day tasks may sll
be stuck in a “work order” paradigm within a siloed
IT department, where they receive full project plans
and deadlines from another department with no
opportunity to collaboravely plan for what kind of
work a project requires. Finding support to learn
about accessibility, write paerns, and conduct
usability research can be hard if the people in power
have lile understanding or paence for the behind-
the-scenes work necessary to maintain high-quality
technical products. These limitaons exist in and
outside of government.
Many soware companies employ user researchers
and designers to understand what end users need,
communicate these needs to engineers, and conduct
usability tesng. Design and research are crucial
for building soware that is not just compliant with
accessibility and business requirements but also
usable. Unfortunately, design and research roles are
sll uncommon on government teams. Instead, many
government systems are “designed” by an engineer
who interprets business requirements from an agency
director. The system may be evaluated by domain
experts in government but never tested with the
people who will have to use the system. An engineer
in such an environment might not have the skills
or permission to engage members of the public in
usability research on their own. The result is systems
that make sense only to the people who build them.
Managers
Individual public workers may not have the authority
to priorize data visualizaon accessibility or have
access to the tools or resources needed to create
more accessible work. In these cases, people who hold
posions of power may clear the path.
Because most soware is purchased and not built
in-house, the single most eecve way to work
on data visualizaon in government is to procure
accessible products. For o-the-shelf products that
are not specic to government, accessibility may be
a last priority, because private companies are not
held to any specic standard for digital accessibility.
For specialized needs where a company might only
serve government clients (e.g., a maker of perming
soware), governments can only choose from few
alternaves. The same can be said of domains
where a few large companies dominate, like cloud
infrastructure or spreadsheets. Finding an accessible
product can be challenging or impossible.
100 DO NO HARM GUIDE
One might assume that custom soware would be
beer because it is tailored to meet the client’s needs.
But building custom soware comes with the huge
risk of sinking large amounts of money, which cannot
be recovered, into projects that are either never
delivered or poorly delivered. And regardless of how
many opons exist or how bad a custom system is,
the cost and me commitment required to switch
soware systems is prohibively high. A government
may be stuck with a newly procured product riddled
with accessibility problems for years unl they can
aord to replace it. Vendors of o-the-shelf and
custom soware hold a lot of power because of
these transacon costs associated with soware
procurement.
Vendors also hold power in relaonships with
governments because of informaon asymmetry.
Many public managers do not have the knowledge or
experse to demand or enforce digital accessibility.
The silos and red tape of bureaucracy may keep
them from collaborang with engineers and
analysts to develop specic, aconable
requirements for contracts.
Governments can exercise the power they do have.
A well-intenoned vendor may worry that data
visualizaon accessibility or usability research for
accessibility are beyond the scope of a contract,
especially because data visualizaon accessibility
requirements are not spelled out in WCAG, Secon
508, or the Americans with Disabilies Act. To address
some of these barriers, governments can specify data
visualizaon accessibility requirements in requests
for proposals and contracts in addion to WCAG
compliance, allocate me and funding in custom
soware projects for accessibility usability research,
and ask vendors about how they work on accessibility
and whether internal tools and data visualizaon
are included.
Bias about Who Works, Holds Power,
and Makes Decisions
In spring 2022, I interviewed for a front-end
development job with the cofounder of a
cybersecurity startup. He told me that they had
many federal agencies as clients. Because I had
previously worked on dashboards for a cybersecurity
startup, I understood that most of the data
visualizaon work would be internally facing, to
be used primarily by IT workers in government and
managers to monitor and respond to cybersecurity
incidents. I was sll excited: using accessible internal
tools in government can make it easier to hire people
with disabilies into posions of power and thereby
build a representave bureaucracy.
When it came me for me to ask quesons, I asked
how they approach building accessible dashboards.
He said, “We don’t really worry about accessibility.
Secon 508 doesn’t apply to cybersecurity.” He
seemed shocked when I told him I would not connue
the interview process because I was disappointed
that they knowingly exclude people with disabilies
from federal employment. I was shocked that he was
shocked. What made him assume that no person with
a disability would ever hold a job in government and
need to use his product?
This cofounder is not alone in his beliefs that
accessibility is only relevant for public-facing
projects and does not extend to internal tools.
Most government technology companies do not
evaluate internal tools for accessibility, even if they
have a social impact mission and push for inclusivity
in the products they build for others. These companies
assume people with disabilies might be the recipients
of services, but not colleagues or decisionmakers
who will need to fully parcipate in design processes,
incident response, or project planning.
These beliefs indicate unexamined ableist assumpons
about who can or should hold power. When people
are separated into those “doing” and those “receiving,”
exisng disparies in representaon in government
create a feedback loop of exclusion. Workers in
environments with accessibility barriers believe
they have no colleagues with disabilies and choose
internal tools with accessibility problems. Internal tools
become crucial parts of jobs and public processes.
People with disabilies are prevented from working
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 101
or parcipang in government and advocang for
themselves from the inside.
Conclusion
Cultural and instuonal factors can make it hard to
implement accessible data visualizaon pracces in
government. But an individual can sll strive, within
the context of their role and skill set, to inuence their
organizaon for the beer.
It is no accident that tech industry tools and ways of
working are being imported into government. In the
past decade, several organizaons and fellowships
(e.g., US Digital Service, US Digital Response, Oce
18F in the General Services Administraon, the
Presidenal Innovaon Fellowship, Tech Congress,
Code for America, and the Tech Talent Project) have
sprung up to recruit tech workers from Silicon Valley to
bring their experience to bear on our most challenging
public problems. Amazon, Microso, Google, GitHub,
and other tech companies have eagerly onboarded
customers and launched iniaves to digize and
modernize public services. Universies are scrambling
to rework their master of public administraon
programs to include more digital governance skills.
Many of these eorts have created more reliable
digital services, cleaner interfaces, and smoother
interacons with governments. But technological
change, if not led by the public service values of
equity, democracy, parcipaon, representaon, and
transparency, can create a tangled knot of inaccessible
infrastructure that cannot be unbuilt. Unchecked
proliferaon of inaccessible external and internal visual
tools in government decisionmaking processes will
perpetuate a cycle of exclusion.
Public leaders, workers, and communies can
migate this potenally negave impact. For large
procurements, explicitly naming accessibility as
a requirement for not only public-facing projects
but also internal tools can go a long way. Vendors
building custom soware should also be required to
meet a standard of accessibility that goes beyond
mere compliance, toward usability and inclusion. To
handle smaller-value soware acquisions under the
procurement threshold where an individual public
servant might exercise discreon, governments should
evaluate and recommend accessible products in
advance for common needs.
But procuring accessible soware will not be
enough. Even tools built to be accessible can create
documents, dashboards, and other work products
with accessibility problems. Governments also need to
create accessibility policies and provide internal, job-
specic training. Accessibility is the responsibility of
everyone in an organizaon who uses digital tools.
The disability rights movement has been clear from the
start that people with disabilies should lead the way:
“nothing about us without us” has been a common
mantra since the 1990s. Building inclusive public
instuons that serve everyone equitably requires that
our technical tools support people with disabilies
not just as end users, but as polical leaders,
decisionmakers, parcipants in public discourse, and
public workers in a representave bureaucracy.
102 DO NO HARM GUIDE
Chapter Nine Notes
[1]
“The WebAIM Million Report,” WebAIM, last updated March 31, 2022, hps://webaim.org/projects/million/.
[2]
“The WebAIM Million Report,” WebAIM, last updated March 31, 2022, hps://webaim.org/projects/million/.
[3]
Mehmet Duran, “What We Found When We Tested Tools on the World’s Least-Accessible Webpage,” Accessibility in Government blog,
Gov.UK, February 24, 2017, hps://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-
accessible-webpage/.
[4]
Kelly Campbell Rawlings and Thomas Catlaw, “Democracy As a Way of Life,” in Government Is Us 2.0, ed. Cheryl Simrell King (New York:
Routledge, 2011), 31.
[5]
Pamela Herd and Donald P. Moynihan, Administrave Burden: Policymaking by Other Means (New York: Russell Sage Foundaon, 2019).
[6]
“What Is Secon 508?” EPA.gov, last updated January 18, 2022, hps://www.epa.gov/accessibility/what-secon-508.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 103
Appendix: Accessibility Tools and Resources
This technical appendix provides curated lists of screen readers, color tools, accessibility remediaon rms
and plaorms, and other resources for accessibility guidelines. These lists are not comprehensive, and they are
likely to change as more tools are developed and published. The lists do not constute an endorsement of any
parcular tool or service. We hope these lists can help readers explore the tools available that will enable them
to create beer, accessible data and data visualizaon products.
Accessibility Guidelines
Chartability. Developed by Frank Elavsky (see Chapter 2), Chartability is a set of testable quesons that seek
to ensure data visualizaons, systems, and interfaces are accessible. Chartability is organized into principles
with testable criteria and focused on creang an inclusive data experience for people with disabilies. hps://
chartability.zz.studio/
Secon508.gov. Commonly referred to as simply “508 compliance,” Secon 508 of the Rehabilitaon Act of
1973 (29 U.S.C. § 794d), and amended by the Workforce Investment Act of 1998 (P.L. 105-220), requires federal
agencies to develop, procure, maintain, and use informaon and communicaons technology that is accessible
to people with disabilies. The US General Services Administraon is the federal agency responsible for
providing technical assistance to other agencies to ensure Secon 508 compliance requirements are correctly
put in place. hps://www.secon508.gov/
US Environmental Protecon Agency. The EPA provides a succinct introducon to the guidelines and
requirements set forth under Secon 508. hps://www.epa.gov/accessibility/what-secon-508
Web Content Accessibility Guidelines (WCAG). The Web Accessibility Iniave hosts the WCAG guidelines,
which explain how to make web content more accessible for people with disabilies. hps://www.w3.org/WAI/
standards-guidelines/wcag/
Screen Readers
JAWS. The Job Access With Speech (JAWS) screen reader provides speech and Braille output for many major
computer programs including Microso Oce, Google Docs, Chrome, Firefox, Edge, and more. JAWS only
works on Windows computers. A single license for an individual user is currently $95 a year. hps://support.
freedomscienc.com/Products/Blindness/JAWS
Narrator. Narrator is a screen reader tool built into the Windows 11 operang system. It has some limitaons
with some browser tools and web applicaons. hps://support.microso.com/en-us/windows/complete-guide-
to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1
NVDA. NonVisual Desktop Access (NVDA) is a free and open-source screen reader that supports major soware
programs and is oen compared with JAWS. As with JAWS, NVDA works only on computers running the
Windows operang system. hps://www.nvaccess.org/download/
VoiceOver on iOS. This screen reader is built into the iOS operang system on iPhones and iPads. hps://
support.apple.com/guide/iphone/turn-on-and-pracce-voiceover-iph3e2e415f/ios
104 DO NO HARM GUIDE
VoiceOver on macOS. This screen reader is built into the Mac operang system. It has a steeper learning curve
than some of the other tools on this list, but it also has more than 30 languages available. hps://www.apple.
com/voiceover/info/guide/_1121.html
TalkBack. The internal accessibility tool for Android users, the TalkBack screen reader speaks text and
image content on the screen. hps://support.google.com/accessibility/android/topic/3529932?hl=en&ref_
topic=9078845
Emacspeak The Complete Audio Desktop. This is a free screen reader tool that works in the emacs editor on
Linux and OS X operang systems. Support is provided for interacng for many types of Internet media and is
used by programmers and researchers. hps://github.com/tvraman/emacspeak
Color Checkers
Accessibility Scanner. Accessibility Scanner is an Android app that suggests improvements such as enlarging
small touch targets, increasing contrast, and providing content descripons. hps://play.google.com/store/apps/
details?id=com.google.android.apps.accessibility.auditor&hl=en
Adobe Color Contrast Checker. Associated with Adobe’s Color tool (hps://color.adobe.com/create/color-wheel),
this contrast checker lets users input and adjust foreground and background colors and see contrast rao scores
per the Web Content Accessibility Guidelines. hps://color.adobe.com/create/color-contrast-analyzer
Color Contrast Analyzer. A downloadable tool (available for Windows PCs and Macs) that uses the Web Content
Accessibility Guidelines and a color vision deciency simulator to check color contrast.
Color Contrast App. A mobile accessibility checker designed for the iPad (iOS) that lets you test colors of
apps, websites, or screenshots using an eyedropper tool. hps://apps.apple.com/na/app/color-contrast/
id1095478187
Color Contrast Checker. Color Contrast Checker is a free tool that can be used to test the contrast on your
foreground and background colors. The user can type in hexadecimal color codes and the tool will generate a
color contrast “score.” hps://marijohannessen.github.io/color-contrast-checker/
Color Oracle. Color Oracle is a free color blindness simulator for Windows, Macs, and Linux operang systems.
It is a lightweight applicaon that can show the user, in real me, what people with common color vision
impairments will see. hp://colororacle.org/
Contraste. A downloadable program for Mac computers only that enables the user to know if a combinaon of
colors, for a text and a background, passes accessibility thresholds dened by the Web Content Accessibility
Guidelines. hps://contrasteapp.com/
Leonardo. A relavely new project from Adobe for creang, managing, and sharing accessible color systems for
user interface design and data visualizaon. Leonardo also has an open applicaon programming interface that
enables users to use colors in their development environment. hps://leonardocolor.io/#
Material.io. This tool lets users create, share, and apply color palees, as well as measure the accessibility level of
any color combinaon. hps://material.io/resources/color/
Monsido Contrast Checker. A basic contrast checking tool with mulple possible input methods and no
download necessary. hps://monsido.com/tools/contrast-checker
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 105
Sim Daltonism. Available through the iTunes store for Mac computers, this tool lets you visualize colors as
they are perceived with various types of color blindness. hps://itunes.apple.com/us/app/sim-daltonism/
id693112260
Tanaguru Contrast Finder. RGB and hexadecimal color input models with opons to adjust the contrast rao.
The tool doesn’t have a full interacve color wheel like some others, but it gives suggesons on how to create a
consistent palee. hps://contrast-nder.tanaguru.com/
Vischeck. Vischeck simulates colorblind vision and shows the user what things look like to someone with color
vision deciency. hp://www.vischeck.com/
WebAIM. A simple color contrast checker that requires the user to input hexadecimal colors for foreground and
background objects, then returns a pass/fail score based on WCAG guidelines. hps://webaim.org/resources/
contrastchecker/
Accessibility Tesng Tools and Companies
Chax Training & Consulng: hps://AccessibilityUnraveled.com
Deque: hps://www.deque.com/
Fable: hps://makeiable.com/
Intopia: hps://intopia.digital
Knowability: hps://knowbility.org/
Tetralogical: hps://tetralogical.com/
106 DO NO HARM GUIDE
DAX CASTRO
AMY CESAL
FRANK ELAVSKY
ALICE FENG
DAX CASTRO
Dax Castro is an Adobe-cered PDF accessibility trainer. He is also an
Accessible Document Specialist with more than 25 years of experience
creang presentaons for corporate communicaons. Castro was a
contribung author for the Accessible Document Specialist cercaon
through the Internaonal Associaon of Accessibility Professionals, he
cohosts an accessibility podcast, and runs a document accessibility
support group.
AMY CESAL
Amy Cesal is a data visualizaon designer and instructor and the senior
design director of data visualizaon at Morning Consult. She specializes
in working with subject maer experts to design accessible and legible
visualizaons of complex data across domains. She is also a leader in the
use of data visualizaon style guidelines, wring and speaking on the
topic. Cesal cofounded the Data Visualizaon Society, where she serves
as an advisory commiee member. Cesal’s innovave and unusual data
visualizaon work has garnered her three Informaon is Beauful awards.
She holds an MS in informaon visualizaon from the Maryland Instute
College of Art, where she is the subject maer expert for the Data Analycs
and Visualizaon program. Find her at hps://www.amycesal.com/.
FRANK ELAVSKY
Frank Elavsky is a design engineer turned researcher who is currently
pursuing a PhD studying the intersecon of data interacon and
accessibility at Carnegie Mellon University’s Human-Computer Interacon
Instute. He is also the author of Chartability, a set of heuriscs for
evaluang the accessibility of data experiences. Before pursuing his PhD,
Elavsky was a lead contributor to Visa Chart Components, a design system
component library of charts and graphs built with a focus on accessibility.
ALICE FENG
Alice Feng is a data visualizaon developer based in the Washington, DC,
area. She is passionate about using design to make data and informaon
more accessible to broader audiences and recently has explored ways to
bring more diversity, equity, and inclusion into how we visualize data. Her
work has appeared in the Parametric Press and the Pudding. Previously, Alice
worked as a data visualizaon developer at the Urban Instute, where she
built interacve and stac data-based features and tools to communicate
public policy research. Alice is currently embarking on a new adventure at
Natera. She is on Twier at @eecealeece.
MEET THE
AUTHORS
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 107
SARAH FOSSHEIM
ELIZABETH HARE
LARENE LE GASSICK
MELANIE MAZANEC
SARAH FOSSHEIM
Sarah Fossheim is a muldisciplinary developer, designer, and accessibility
specialist. They have a strong focus on data visualizaon accessibility and
usability, having worked as a product developer and designer on data-
heavy products in the cancer research and educaonal sector. Currently,
Sarah is an independent consultant, educator, and advisor who helps
companies create more accessible and inclusive soluons.
ELIZABETH HARE
Liz Hare is a quantave genecist researching working on dog behavior
and health. She works with breeding programs to implement data-driven
selecve breeding that can improve canine welfare, health, and work-
related behavior. As a blind member of the R stascal programming
community, she advocates for broadly inclusive conferences and training
as well as for accessible soware, documentaon, and reporng that
includes meaningful alt text for data visualizaon. She holds a PhD in
genecs from the George Washington University.
LARENE LE GASSICK
Larene Le Gassick is the head of technology at Intopia, a Microso MVP
in Developer Technologies focusing on accessibility, and community
manager of Tech Leading Ladies Australia. She specializes in building full-
stack applicaons with accessibility and inclusion at front of mind. She is
also an internaonal conference speaker and guest university lecturer on
digital accessibility and soware architecture. Le Gassick is one of the core
members of the DatavizA11y group, where she and other accessibility
advocates and experts come together to raise awareness of and provide
guidelines and soluons for a lack of resources in making data visualizaon
inclusive of people with various disabilies. When she’s not building
soware or talking about accessibility and inclusion, Le Gassick spends her
me cycling or scrolling through Twier.
MELANIE MAZANEC
Melanie Mazanec is a public interest technologist located in Philadelphia.
Most recently, she worked on knowledge management and best pracces
for Code for America as the associate director of Human-Centered
Government. Mazanec has also volunteered in the Code for America
network and worked as a soware engineer for public-interest tech
consultancy Bloom Works Digital; the City of Asheville, North Carolina;
and a cybersecurity startup. Mazanec is most proud of her work for many
projects to help make data and data visualizaons transparent and open
source. Mazanec worked in music and educaon before geng into tech.
When she’s not busy emailing government soware vendors to inquire
about their accessibility roadmaps, she takes thousand-mile bicycle
adventures and plays the trumpet.
108 DO NO HARM GUIDE
SUE POPKIN
DOUG SCHEPERS
SUE POPKIN
Susan J. Popkin is an instute fellow in the Metropolitan Housing and
Communies Policy Center at the Urban Instute and program director for
Urban’s Disability Equity Policy Iniave. A naonally recognized expert
on public and assisted housing programs and policy, Popkin also leads
Urban’s Future of Public Housing work and is currently the co–principal
invesgator for the evaluaon of the US Department of Housing and Urban
Development’s Rental Assistance Demonstraon. Popkin has led many
mixed-methods studies of the impact of housing programs on resident
outcomes, including Chicago’s Plan for Transformaon; HOPE VI; and
Urban’s Housing Opportunies and Services Together demonstraon,
which uses community engagement and community-based parcipatory
approaches to explore new strategies for improving outcomes for families
in public and assisted housing. Popkin is the author or coauthor of mulple
books, including No Simple Soluons: Transforming Public Housing in Chicago,
Moving to Opportunity: The Story of an American Experiment to Fight Gheo
Poverty, and The Hidden War: Crime and the Tragedy of Public Housing in
Chicago. Popkin holds a PhD in human development and social policy from
Northwestern University.
DOUG SCHEPERS
Doug Schepers is the founder and director of Fizz Studio, a startup focusing
on making data visualizaons accessible to people with disabilies. While
he was working as a project manager for the World Wide Web Consorum,
organizing and authoring web standards for over a decade, Schepers
recognized a need for accessible data visualizaon, so he dedicated his
me to consulng, soware development, and research to make access to
data universal and equitable. Schepers is widely acknowledged as a leader
in data visualizaon accessibility and is a popular speaker at conferences,
workshops, and seminars. He uses his adult-diagnosed ADHD as a tool
to help synthesize ideas from across dierent domains and as an intuive
gauge for cognive load.
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 109
JONATHAN
SCHWABISH
JONATHAN SCHWABISH
Jonathan Schwabish is a senior fellow in Income and Benets Policy
Center at the Urban Instute, where he studies disability insurance,
rerement security, and nutrion policy; he is also a member of Urban’s
communicaons team, where he specializes in data visualizaon and
presentaon design. Schwabish is a leading voice for clarity and accessibility
in research and has wrien on how to best visualize data, including
on technical aspects of creaon, best pracces in design, and how to
communicate social science research in more accessible ways. Through his
work, Schwabish helps nonprots, research instuons, and governments
at all levels improve how they communicate their research and ndings
to partners, constuents, and cizens. He teaches data visualizaon and
presentaon skills at Georgetown University and at American University,
and he founded PolicyViz, a consulng rm that helps clients improve how
they communicate data and analysis.
LÉONIE WATSON
Léonie Watson is the director of TetraLogical, a member of the World
Wide Web Consorum Advisory Board, co-chair of the World Wide Web
Consorum Web Applicaons Working Group, and a member of the BIMA
Inclusive Design Council. Watson also is co-organizer of the Inclusive
Design 24 conference, coauthor of the Inclusive Design Principles, and a
mentor to young people interested in the elds of accessibility and inclusive
design. Watson is oen found at conferences talking about web standards
or accessibility mechanics and pushing the boundaries of inclusive design.
She has also been published in Smashing magazine, SitePoint.com, and Net
magazine, as well as on her own site, nk.uk. In her spare me, Watson likes
reading, cooking, drinking tequila, and dancing (although not necessarily in
that order)!
LÉONIE WATSON
110 DO NO HARM GUIDE
AMANDA BOTTICELLO
TREVOR
DYSON-HUDSON
ADVISORY
BOARD
AMANDA BOTTICELLO
Amanda Bocello is the assistant director of the Center for Spinal Cord
Injury Research and the Center for Outcomes and Assessment Research at
the Kessler Foundaon in West Orange, New Jersey. Bocello has a faculty
appointment in the Department of Physical Medicine and Rehabilitaon
at Rutgers New Jersey Medical School, where she is research associate
professor and vice chair of research educaon. She conducts research on
the social determinants of health and disability, focusing on environmental
factors and addressing barriers to community reintegraon for adults
with spinal cord injury, children with special health care needs, and other
populaons with chronic health condions. Bocello trained in social
epidemiology at the Fielding School of Public Health at the University of
California, Los Angeles, where she received her MPH and PhD. She holds a
BA in psychology from Amherst College.
TREVOR DYSON-HUDSON
Trevor Dyson-Hudson is the director of the Center for Spinal Cord Injury
Research and the Center for Outcomes and Assessment Research at the
Kessler Foundaon in West Orange, New Jersey. Dyson-Hudson is also
a research associate professor in the Department of Physical Medicine
and Rehabilitaon at Rutgers New Jersey Medical School. His research
interests include the prevenon and treatment of common secondary
medical complicaons aecng people with spinal cord injuries. Dyson-
Hudson has beneted from his lived experiences with spinal cord injury
since 1992. He received his BA in physiology and cell biology from the
University of California, Santa Barbara, and his MD from the Albert Einstein
College of Medicine. Dyson-Hudson also completed a research fellowship
in rehabilitaon research and complementary and alternave medicine at
Rutgers New Jersey Medical School.
DOMINIK MORITZ
Dominik Moritz is on the faculty at Carnegie Mellon University and a
researcher at Apple. At Carnegie Mellon, he coleads the Data Interacon
Group at the Human-Computer Interacon Instute. His group develops
interacve systems that empower everyone to eecvely analyze and
communicate data. Moritz’s systems (Vega-Lite, Falcon, Draco, Voyager, and
others) have won awards and are widely used in industry and by the Python
and JavaScript data science communies. Moritz received his PhD from the
Paul G. Allen School at the University of Washington, where he was advised
by Je Heer and Bill Howe.
DOMINIK MORITZ
CENTERING ACCESSIBILITY IN DATA VISUALIZATION 111
SUSAN ROBINSON
Susan Robinson masterfully blends over 25 years of mulsector leadership
with her experiences being legally blind to shi thinking, elevate potenal,
and inspire action regarding accessibility. In her TED Talk, “How I Fail
at Being Disabled,” she flips generally accepted ideas upside down to
uncover, challenge, and redene preconceived obstacles. In her role as
an advisor and consultant, Robinson hosts leadership workshops as well
as business strategy and transformaon planning. She received her MPA
in health policy and management from New York University’s Robert F.
Wagner Graduate School of Public Service and her BS in health policy
and administraon from Pennsylvania State University. In her free me,
Robinson is a tango dancer, yoga praconer, tandem cyclist, and
world traveler.
SUSAN ROBINSON
