A template for accessible data visualizations

Lauren Jong
San Francisco Digital & Data Services
8 min readMay 13, 2022


How we designed and built a system and standards for making COVID-19 data accessible

by Emily Vontsolos, Blake Valenta, and Lauren Jong
This project was done in collaboration with San Francisco’s COVID Command Center, DataSF, the Controller’s Office, and SF Digital Services.

If data isn’t accessible and understandable, it isn’t helpful. We shifted our bar for success beyond providing high quality data, to making it accessible to all our users.

Data in uncertain times

During the COVID-19 pandemic, accessing trusted data and dashboards was critical. In a time full of uncertainty, data offered insights and clarity. People began looking at COVID-19 data and dashboards every day, and from anywhere they could find them. All of a sudden, people were planning their lives around this data.

Publishing our first dashboards

In San Francisco, we knew that making our City’s COVID-19 data and dashboards public was critical. Amidst the urgency of the pandemic, a team of analysts with the City’s COVID Command Center built over 40 public dashboards. Publishing all the dashboards in only a few months was a huge feat. We were proud of ourselves!

Screenshot of a website titled COVID-19 Data and Reports
A screenshot of San Francisco’s first COVID-19 Data and Reports website.

User testing the dashboards

We hoped that the dashboards conveyed the complicated nature of COVID data in a way that was easy-to-interpret. But we were aware that there were areas to improve, such as mobile responsiveness and information organization.

To find out the severity and identify what was hardest about accessing our data, we tested the dashboards with website users. During the user testing we asked how participants typically used the dashboards and did a few tasks to find information or interpret dashboards. We leaned on several great online resources for templates and tips when doing user testing.

Rapid development left out accessibility and design considerations

User testing uncovered serious gaps:

  • Some of our visuals were so complicated that users felt overwhelmed or frustrated.
  • Dashboards were poorly sized when accessed on mobile phones.
  • Pages included lengthy content that users skipped over or struggled to understand.
  • There were accessibility gaps for anyone using a screen reader or a keyboard to navigate the pages.

All of this meant pain for our users, in an already incredibly painful and scary time.

Redefining success to mean accessibility

We dedicated ourselves to usability and accessibility; engaging with external experts and researching data visualization accessibility best practices. If the data isn’t accessible and understandable to all our users, it isn’t helpful.

Accessibility to us means more than meeting minimum web standards. When we think of accessibility, we think about language translations, devices, digital literacy, cognitive needs — anything that could impact someone’s ability to use and comprehend our site. This meant our pages need to be translated, accessible on mobile devices, screen reader friendly, easy to use, and as simple and clear as possible.

What we did

We brought together a team from across DataSF, the Controller’s Office, and SF Digital Services to relaunch the City’s COVID data tracker on SF.gov. As the City’s most accessible website and centralized place for City information, moving to SF.gov was a natural fit. Together we rewrote and reorganized the pages, and rebuilt dozens of dashboards.

Here are some of the key improvements that made our data and reports more accessible and easy to use:

1. Consistent dashboard layouts

2. Focused, simple data visualizations

3. Accessible text to support the data

4. Mobile responsive dashboards

5. Special care to accessibility for screen readers

6. Templates and guidance to streamline adoption

1. Consistent dashboard layouts

How dashboards are laid out (and if that is consistent) is an important factor in how users perceive the website and understand the visuals. Without standards, it was easy to continue adding dashboard elements without realizing that too many visuals or filters can clutter a dashboard and overwhelm users.

Screenshots of four different data dashboards with different colors and layouts
Our original dashboard had a variety of complicated layouts

Consistent standards can improve usability while also building trust in the quality of the underlying data. Some standards we set are:

  • Only have 1 to 3 main visuals per dashboard
  • Consistent text styling and spacing between visuals
  • Make sure the most important data point or finding is in the top left
  • Put certain dashboard elements (buttons/filters) in the same place so users always know where to go for what
  • Link to the source data below every dashboard
Screenshots of three data dashboards
Our dashboards layouts are standardized, with consistent font styling, order of elements, and spacing between dashboard elements.

2. Focused, simple data visualizations

Within each dashboard, the data visualizations themselves need to be easy to understand and read. It can be tempting to include more information in a visual, but this ultimately makes it harder for someone to interpret.

Some of the things we do now are:

  • Avoid complicated chart types such as dual-axis charts
  • Avoid requiring interactivity to reveal important information
  • Use small multiples instead of having too many lines on a single graph
  • Use data labels only on key points to avoid cluttering your chart
  • Use a color palette designed specifically for data visualization, and be aware that colors have meaning
Screenshots of a chart with multiple lines, and a dashboard with separate smaller charts for each line
On the left is the original chart, which had 9 lines. The new dashboard on the right has small multiples, which are easier to read, clearly labeled, and no longer rely on color to distinguish groups.

Our goal is to focus users on a key trend or measure, as opposed to showing multiple visuals and measures in one chart. It takes more work to pair with epidemiologists and content experts to identify the most critical issues or takeaways, but has a big payout for user experience. Instead of making people wade through the data or click around to identify “findings”, the goal is to do the work for them and highlight what they should be looking at.

This simplification is super important for accessibility as well. Screen readers don’t have to navigate overly complicated dashboards, and it lowers cognitive load for all readers.

3. Accessible text to support the data

Designing data visuals and the surrounding webpage go hand-in-hand. The simplicity and clarity of the supporting content is crucial to enable users to interpret the data. Analysts and editors rewrote all the pages in plain English. Using simpler language not only helps English readers of all levels, it also allows us to translate the text into other languages.

Screenshot of a dashboard with lots of small text and a dashboard with a simpler layout
On the left is an original dashboard and on the right is a new page. It has a simpler layout, and the dashboard is supported by easy-to-read introductory text.

Originally, paragraphs of important information and links were crammed into each embedded dashboard. As part of the update, we moved nearly all of it out and onto the webpage.

By doing this, we can create a better, standardized, page hierarchy with skimmable titles. And it’s huge for accessibility — the text is available in Spanish, Chinese and Filipino. Unlike embedded text, it could be highlighted, copied, read by screen readers, and searched. Clear, accessible supporting text is critical for helping people interpret and understand the data.

4. Mobile responsive dashboards

With half of our web traffic coming from mobile devices, it was important to support both larger and smaller devices.

Unfortunately there is not a simple way to make dashboards mobile-friendly or automatically scale to screen size in Microsoft PowerBI, the tool we are using. As a workaround, we created separate mobile versions of each dashboard, built with a mobile-optimized template. Then when a user visits the page, we detect their screen size to display the right dashboard.

Screenshots of a phone with a tiny, unreadable data visualizations, and 2 phones with clearer data.
On the left is our original dashboard which was too small to read on mobile. Users had to click a link to a separate page to see a mobile version. The dashboards on the right show our new simplified templates in a mobile layout.

5. Accessibility for screen readers

This is how someone using a screen reader experienced our original dashboards: the visual elements on the dashboard were highlighted in a random order, with unhelpful text read aloud for each out.

A video of a screen reader using one of the original dashboards

After much research and discussion with experts, we implemented changes that resulted in simpler, more accessible dashboards — for those with and without screen readers. Here is the same dashboard with the results of our changes.

A video of a screen reader using one of the new dashboards

Two of the key changes we made were defining the “tab order” and adding alt text. Throughout the development process, it’s important to test with a screen reader to make adjustments.

Screenshot of a list of instructions labeled Navigated dashboards with a keyboard
Instructions list out key combinations for navigating dashboards using a keyboard.

We also knew that PowerBI has some non-standard interactions that people who navigate using a keyboard might be unaccustomed to. To help with this, we added keyboard instructions that are presented if you navigate using a keyboard, just when you need them. (See them by viewing any dashboard page and pressing tab until you enter a dashboard.)

6. Templates and guidance to streamline adoption

We published everything we learned in the Public Data Visualization Guide to make it easy for analysts and dashboard creators to replicate. Details about our best practices, PowerBI tips, and specific recommendations are in the guide.

We also created a Power BI report template so that analysts from across the City have a starting point for creating future dashboards. We hope this is helpful to others who want to make their public dashboards more accessible, both within and beyond our City.

Screenshot of Microsoft PowerBI editing software, annotated with instructions for how to use it.
The PowerBI template provides tips and a starting point for analysts creating a new accessible dashboard.

Challenges with PowerBI

‌Even after these improvements, there are still known gaps and opportunities related to limitations in Microsoft PowerBI:

  • Accessibility features for maps in PowerBI are still very much lagging compared to other types of visuals and charts
  • Keyboard navigation in PowerBI uses non-standard accessibility key combinations and does not cover all the ways to interact with the visualization
  • While other text on the page is translated to San Francisco’s threshold languages, the dashboards themselves are still only available in English
  • Limited styling and formatting options in Power BI (no texture options or shape borders to help with contrast, limited choices of fonts and weights)

The work ahead

We still have a lot of work to do. The tools and best practices, both for us and our users, are constantly evolving.

To further the City’s commitment to open data, we are also working to ensure new data visualizations continue to be transparent, as well as accessible. This means underlying data that is available to the public and clear explanations for how numbers in the visualization are calculated so that they can be replicated.

At its core, data visualizations and dashboards are tools to help people consume datasets that can be large and complex. There is no one way to do this. It’s possible to create experiences that technically can be accessed, but fail to make the information useful and understandable. In our approach to accessible data visualizations, we wondered things like “what is a true equivalent experience for unsighted users, and not just technically readable by a screen reader?” There’s so much more to explore in this space, and we’re inspired by all the great people who we learned from.

Thank you to everyone who helped us

We were thankful to learn from experts, researchers, and advocates who have already done a lot of research and writing on this. Our volunteer expert team — Jaime Tanner, Frank Elavsky, and Chris Demartini — taught us about design and accessibility standards. They also pointed us to groups like the DataViz Accessibility Advocacy and Advisory Group, who offer even more resources and information.

We were also able to utilize the great functionality that already existed in Microsoft Power BI (the software we use). There are many experts in the Power BI community, like Meagan Longoria, who have already done a lot to educate developers on accessibility.



Lauren Jong
San Francisco Digital & Data Services

Previously at City and County of San Francisco Digital Services, Google.