How to approach accessibility in academic data science
23 September 2021
By Ciera Martinez
Introduction
Accessibility is about designing with usability for all people in mind. When we think about accessibility in data science most data scientists are familiar with using color-blind friendly colors in their data visualizations, but for many, thinking of examples and discussion beyond this is hard. We as data scientists need to design for more diverse populations to make a real impact on the world. This post goes a bit deeper into understanding how data science can be more accessible to a broader audience, especially those with disabilities, based on a discussion which occurred this year at The Best Practices of Data Science Working Group at Berkeley Institute for Data Science (BIDS) guided by Accessibility and Data Experience Engineer Frank Elavsky.
At BIDS, we have been running the Best Practices of Data Science Working Group for the last three years. This is a cross domain group of individuals spanning researchers and practitioners of data science in both industry and academia. We discuss a broad range of topics from the “soft skills” like career navigation to data science methodology, for example archiving modelling parameters. The many perspectives offer a wide spectrum of ideas on each topic, and after writing detailed notes, we try to form teams to write on these topics. See a list of our products here.
All of us felt passionate about, but know embarrassingly little about accessibility in data science. Sowe invited Frank Elvasky to help us learn more. Frank has an interesting background that prepared him for the accessibility work and research he pursues. He began work by doing data visualization as an undergraduate in a NSF Research Experience for Undergraduate (REU). He then continued on as a federal contractor for the Department for Justice (DOJ) - Federal Bureau of Investigation (FBI) for a while and eventually worked as staff at Northwestern University, focusing on data visualization. His teaching and work led him to expand more into accessibility. He eventually found himself finally at a “proper” industry job at Visa. He will soon be starting a PhD at the Human Computer Interaction Institute at the School of Computer Science at Carnegie Mellon University.
Below is a summary of the conversation we had with Frank. We highlighted specific questions that were asked and summarized what was discussed by Frank and others within the group.
Coming from zero, how do you get started with accessibility in data visualization?
It begins with representation: Many of the people in our working group had a deep desire to learn more but just did not know where to start. Frank said this is the norm, and the norm of not knowing is only reinforced as most people who make it to the larger research institutes are not surrounded by people with disabilities. One of the root problems of doing accessible work within academia is that academia doesn’t support disabled people in these spaces. “Nothing about us, without us” rings true. We cannot, as researchers, build a truly accessible space without including people with disabilities in our design and research groups. Therefore, the first step is to make academia more accessible and support a larger population of people with disabilities in our departments and graduate programs.
This does not mean to invite people to work on our teams solely for accessibility advocacy roles, rather, just the act of including diversity in our research programs can greatly improve how accessible our research and data science is, regardless of their role. People with disabilities have less tolerance for design errors - which improves all processes just through their inclusion. Part of the process of building a good team is ensuring that you recruit a diverse team from all angles. ~20% of the US population have accessibility challenges (https://www.pewresearch.org/fact-tank/2017/04/07/disabled-americans-are-less-likely-to-use-technology/). Therefore if 1 in 5 people in your team does not reflect this you have not acquired the best team. Some questions we must ask ourselves and our departments: How do you support diversity without burdening the disabled by forcing them into an “auditing” role? How do the guidelines address the continuum?
How do you change culture to value work in accessibility?
We need to change academic campus culture.We discussed a few ways to convince people to take the time to invest in communicating data with accessibility in mind.
Plan A: Cater to people’s sense of empathy. Creating good data science requires empathy for every person regardless of disability status. To understand data and communicate our results requires a self dialog with data, which should always be expanded to your research audience. This is how bias creeps in. When we think of the audience, we tend to ignore the people we don’t see, which is why the act of having full representation in our research groups reduces these biases. We must require a broader view of who our audience is, and include those with disabilities. However, you cannot convince everyone to be empathetic.
Plan B: Reinforce that good data science is inclusive and accessible - Inclusive design is really just better design. Although “good science” is what all data scientists strive for, there is no one infallible truth in our work. We as researchers bring all our biases, preferences, and worldview to all of our work. We build stories about our results and make many design decisions to our workflows and data visualizations. If we are building our work around our (or our small community’s) worldviews, we are obscuring truths and patterns within our work, and further, performing bad science. Further to remedy bias, consider the context of our own worldview and the entire data workflow pipeline through which the data was filtered, as suggested by D’lgnazio and Klein in Data Feminism.
The bottom line for numbers is that they cannot speak for themselves. In fact, those of us who work with data must actively prevent numbers from speaking form themselves because when those numbers derive from a data setting influenced by differentials of power, or by misaligned collection inceptives (read: pretty much all data settings), and especially when the numbers being arrogantly grandiose and empirically wrong, but also of doing real harm in their reinforcement of an unjust quo
- DATA FEMINISM, CHAPTER 6
Plan C: Start putting tools, guard rails, and community enforcement in place to enforce inclusivity. Like creating journal requirements, rules for departmental seminars, recruitment protocols, and even laws. Depending on the context of how we display our work, especially federally funded work, civil rights law prohibits discrimination against individuals with disabilities. Section 508 of the Rehabilitation Act requires that all electronic and information technologies developed and used by any Federal government agency must be accessible to people with disabilities. This includes websites, video and audio tapes, electronic books, televised programs, and other such media. Legal, physical, and structural interventions do a much better model of tearing down barriers than just cultural alone.
What tools do we have and what can be made in the future?
Unfortunately, the landscape of tools for data scientists to make their work more accessible are few, but there are some exciting emerging strategies and standards being built and foundations established from accessibility work in other domains, especially web development, which can be leveraged to data centric work. For example, Frank has begun to work on such tools called Chartability, which aims to make the charts we as data scientists make to communicate our work more easily accessible to a wider range of people.
Not surprisingly we started the discussion of creating standards as a community and documenting these stands - a theme that emerges in many of our topics in the Best Practices of Data Science Working Group. For example it would be great if there was a ggplot theme that incorporated accessibility guard rails as a base. The group got excited about the possibility of Rstudio (we all love!) creating guardrails in the products they create, as their community is already built so well around inclusivity. We also talked about developing programmatic accessibility tests for our code and visualizations. Then, as often happens in our group, we nerded out about what we could build.We are already so good at building together, for example hackathons and open source software, we just need to prioritize the topic of accessibility!
Or, sometimes you don’t have to build for everyone, but maybe your team can build more bespoke tracks for your smaller team to build off when designing your data products, which, when made open, can act as working examples for others (yay open source / open science). Frank had a great example of a documentation project he worked on when he was at VISA.
Closing: Curb Effect and Temporal Disability
In terms of motivating and changing culture we began to ask: Can you also make the arguments to help users without disabilities?
There is a fine line between accessibility and accommodation.. Accommodation is reactive making tweaks in design for people after they are present. While accessibility is proactive - we shouldn’t have to have people with disabilities “out” themselves to make design decisions. We should always be ready to define and mark this distinction. Frank mentioned “Design for one and extend to all”, which truly reiterates the belief of good design, again, you will have a better product and end result if you design for people with disabilities. And he also introduced us to the Curb-Cut Effect which creates excellence in design. Being proactive on accessibility turns out to aid in accessibility beyond what was designed for.
In the end, disability is personal. There are functional disabilities, there are situational temporary disabilities, and some are permanent. We can motivate change by encouraging an “aha moment”. We have all been disabled to some degree at some point in our lives and it is within these experiences that we can begin to build empathy. That said, empathy building exercises can be harmful - sometimes people try to mimic disability and end up exaggerating the disability. For example, imagine someone closing their eyes to mimic blindness, it is impossible to also incorporate the built up practices and experiences of those who are blind and may design a product under the wrong expectations. Instead, one can employ paths to accessibility and solutioning - trying to substitute for what’s missing vs. working around it. Every few years someone will come up with a glove to translate sign language, even though no one asked for this. It doesn't deconstruct barriers people encounter every day. We should practice preference-driven accessibility -- one strategy won’t work for everything.
There is not one right way forward, but it is important for the academic data science community to not let this be an excuse. It is okay to make wrong moves, but we need to make time and space, and further reward our research teams, both internally and culturally, for making the effort to design our data science work for everyone. Data science is built with biases and limitations in place when performing our work, and these extend to how we work and communicate our data to the world around us. Good data science takes all this into account and has accessibility built into it.
Acknowledgments
We would like to thank the Best Practices for Data Science Group for their thoughtful discussion including those present at the discussion in which this post is based off of: Scott Peterson, Cody Markelz, Haley Hunter-Zinck, Frank Elavsky, Diya Das, Richard Barnes, Ben Lacar, Rob Crystal-Ornelas, Marsha Fenner, Rebecca Barter.
If you would like to be involved on more conversations that led to the writing of this post, please join the Best Practices of Data Science Working Group Mailing List. We are a group at the Berkeley Institute for Data Science at UC Berkeley committed to discussing and writing about how data science is performed and conducted in academia and beyond. See other writing products from this group here.
Looking for Other Blog Posts?
Looking for other ADSA Community Blog Posts? Check the full history of the ADSA Community Blog!