Have you heard the claim that designing for accessibility leads to a better outcome for everyone? Here’s a story about how an accessibility-first approach led to an overall better visual design for a chart.
In 2018, Kent was a founding member of Google Cloud’s first dedicated data visualization team. Kai joined shortly after the team was formed. Early on, we created several prominently featured visualizations in many Google products. Our team, a passionate group of designers, researchers and engineers, also wrote Material Design’s data visualization guidelines. However, as we continued to fulfill our mission, we realized our work wasn’t as inclusive as we had hoped, and as we started embracing new accessibility standards, we realized we had more work to do. We felt strongly that accessibility transcends compliance and that we had an opportunity to create something that is truly useful.
The Need For Accessible Data Experiences #
DATA VISUALIZATIONS ARE ABLEIST #
Visualizations only work well for those who can fully see. According to the National Federation of the Blind, 7.6M people in the United States have a vision disability. We also know that color blindness affects 1 in 12 men worldwide. These people are typically not relying on assistive technology, like screen readers, to consume web content, and they will be the focus of our case study. For most of these people, the value and insights provided by a chart get lost, and in some cases, the chart provides little-to-no information. As part of our mission of organizing the world’s information and making it universally accessible, it’s our responsibility to be good citizens of the web by making data accessible to everyone.
An Accessibility-First Approach Led To A Better Visual Design #
Similar to mobile-first, the accessibility first approach considers accessibility requirements and constraints at the very beginning of the design process. To do this right, we typically validate our ideas with an accessibility testing team, and we codesign our solutions with people who have disabilities. Through this process, we’ve learned a lot, and it has completely changed the way we think about representing data.
There are many ways to make data accessible, but for now, let’s focus on our accessibility-first approach to visual design. Over the past two years, our team has fielded a lot of questions on data accessibility. Believe it or not, the majority of these questions focus on accessible chart colors, encodings, and visual design. This is why we’d like to focus on visual design for now. Our accessibility-first approach ensures that accessibility is a core to the chart’s visual design without compromising focus, sacrificing readability, or adding unnecessary chartjunk.
Let’s compare this approach to a famous piece of architecture, the Guggenheim museum in New York City. In this museum, all of the exhibits and artworks are arranged around a large, accessible ramp that spirals down through the various levels of the building, as depicted in the image below.
This ramp is a core part of how everyone experiences artwork in the building, and it’s inherently accessible. This is light-years better than the experience in buildings with hidden ramps, lifts, and retrofitted equipment for people with limited-to-no mobility.
Now, let’s look at how we can apply this thinking to visual chart design.
THE CHALLENGE #
Recently we were tasked with the challenge of helping developers understand the overall latency and performance of their apps, websites, and digital experiences. An app’s underlying codebase is often made up of a series of functions that execute in order for its features to work. The more efficiently the code is structured, the faster the functions execute, and the better the overall app performs.
Reducing latency is an essential part of any good app experience. After all, who wants to stare at loading screens all day long? It became obvious that a visualization would provide a glanceable diagnostic view of the app’s underlying code, and it could be used to help developers spot inefficiencies in the app’s code.
CHOOSING A CHART #
To visualize app performance and latency, we considered several chart types. To do this, we wanted to represent each function in the code base as its own chart. For each function, we’d plot the time it took to execute every time it was run.
There are several charts that are meant to show the distribution of a variable. The early exploration in the image below shows all recorded execution times for the same function in the codebase