Commit to Change: How to Increase Accessibility in Your Favorite Open Source Projects - posit::conf
Presented by Rose Franzen Explore accessibility for data scientists by uncovering some common barriers in open source tools with simple fixes that anyone can implement. Dive into the often-overlooked world of accessibility for developers and data scientists! Uncover common accessibility barriers in open source tools, and learn simple steps to address them. Whether you’re a seasoned maintainer or a total novice, you’ll walk away with clear action items to implement right away. Join the movement of individuals championing the next frontier of disability inclusion in technology, shaping a more equitable future for all! Materials: https://github.com/franzenr/commit-to-change Presented at Posit Conference, between Sept 19-20 2023, Learn more at posit.co/conference. -------------------------- Talk Track: Package development. Session Code: TALK-1134
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
In 1983, NASA sent Sally Ride into space as the first American woman to ever enter into orbit. In the lead-up to her launch, the engineering team at NASA was very hard at work to ensure that everything would go off without a hitch. So at some point before the big day, the all-male team came to Ride to ask her if a sufficient number of tampons for a week-long mission was 100 tampons.
Ride simply responded, no, that would not be the correct number. When pressed for more information, she told them that they could cut that number in half and it would still be way too many.
I love this story for a variety of reasons. One of them is that I just find it fun to imagine what led up to the moment where they finally landed on the number 100. Were they all sitting around a round table? How long were they talking? These are engineers. Did they do research on the absorbency per tampon and do back-of-the-envelope calculations?
Another reason I love this story is I think it's really well-suited to communicate this idea that even the most well-intentioned group of people will often do a laughable job of trying to meet the needs of another group that they are not part of. I think about how much smoother that process would have gone if there was just one menstruating person on that engineering team. This really drives home for me the idea that to truly make something that meets someone's needs, someone who has those needs themselves must be part of the development process.
This really drives home for me the idea that to truly make something that meets someone's needs, someone who has those needs themselves must be part of the development process.
The case for upstream accessibility
And as you may have guessed from the title of my talk, I'm not here to talk about tampons. So in recent years, there's been a growing awareness, understanding, and acceptance of the importance of technology accessibility. And as we all know, technology doesn't just create itself. Data doesn't analyze itself, or at least not yet.
So we have this process of an initial developer, contributor, maintainer, who supports the creation of a tool or who is doing the data science themselves. So they then produce an output, whether that's an app or a dashboard, a piece of software, and then that subsequently ends in the hands of a stakeholder or end user. And in most of this dialogue so far, we tend to focus at the end on that end user. And we generally do this by focusing in on the output stage.
We do this by asking ourselves questions like, can someone who is colorblind distinguish the features of this graph? Or have I included sufficient alt text for someone who requires nonvisual access to this information? But I'm here to insist that this is the wrong place for us to be focusing if our goal is to avoid being like that all-male engineering team at NASA.
Instead of focusing primarily on the experience of the end user, we need to look further upstream and divert our attention toward the experience of the programmer or data scientist. We need to work to reduce unnecessary barriers for disabled coders and continue to support their ability to continue to use and contribute to open source projects.
And so to do this, we need to think about the tools, packages, languages, programs, et cetera, that data scientists and developers depend on in their daily work. We need to figure out how we can improve the accessibility of these tools so that we can ensure fewer structural barriers to the continued participation and flourishing of disabled members of the open source community.
In the remainder of my talk, I'm going to discuss some simple steps that can be taken to begin improving the accessibility of open source projects. Importantly, these are steps that can be taken by absolutely anyone and don't require having any depth of knowledge in accessibility or web accessibility. As a result of that, I'm not going to get into any of the particularly technical aspects of technology accessibility.
In the link to my slides, which I'll bring up again at the end, I also have a collection of resources that I am also continuing to add to. So if you come back in the following weeks, there's going to be more and more resources.
The power tool metaphor
So imagine that you are renovating your kitchen and everything's going perfectly until you come across some issue. So you do some Googling, you try to figure out what's going on, and eventually you think you figured it out and it seems like you can solve it yourself if you just get your hands on a specific power tool. So you go online and spend some significant effort researching and selecting the right tool, making sure it has specific set of features and capabilities that you need.
You order it, and unfortunately, once it arrives, it has plug type F, which is used commonly throughout much of Europe, but you're located in the U.S., and therefore your outlets only accommodate type A or B plugs. It would have been great if this information was included in the product description, but it wasn't. In fact, it's not present in the description of almost any tool that you can find online. So your best bet is to just keep buying new ones and trying them to see if they work.
If you're thinking that this sounds like it would be an incredibly frustrating way to get something done, you're right, and it's also the reality for many disabled data scientists and programmers when it comes to trying out open source tools in order to solve their programming problems. In this metaphor, we should be thinking of the power tool as a package or IDE or tool, and the plug outlet compatibility is accessibility, right? So it's the IDE that someone wants to work in, and the outlet is their screen reader. And if you don't in a lot of instances, they have no way of knowing whether or not the two will work together until after they've downloaded it and tried it. And unlike an incompatible plug, you can't just go on Amazon and buy a travel adapter and just circumvent the whole thing with accessibility.
Creating accessibility docs
So this brings me to the first thing we can do, which is create accessibility docs. What I mean when I say this is creating documentation that helps individuals quickly assess whether something meets not only their technical requirements, but crucially also their accessibility requirements. This can look like a lot of different things, like just a high-level status of the accessibility of the tool.
Importantly, you can just say that you don't know, even it is unknown how compatible this is with screen readers or we haven't done any research into the accessibility of this is significantly more informative than saying nothing at all. You can also create start curating a list of known accessibility problems. And you can highlight accessibility features. Some of these might be things that are specific to accessibility, but there are probably some that already exist, like keyboard shortcuts or various options for error handling.
Creating a forum for feedback
So once you establish what you do already know or not know about accessibility, you're going to want to set up a way to get further information. So you're going to create a forum for feedback. One of the easiest ways to do this is to create an accessibility issue template or label. And this serves a variety of purposes. One is it serves a really valuable signal.
Under status quo, when already facing a lot of other barriers for their participation, a disabled programmer has to then try to assess whether or not it's actually worth it to put the time and effort to create a valuable reproducible example. Because it's not clear whether or not the maintainers of that project actually care and want to fix this. I would hope that everybody that's in this room is in the group of people that would want to, but there is still a lot of ableism within tech. And there are a lot of people who think it's really just not that important to focus on.
So this gets you information. Because now people know, okay, it's worth it to try to put in, you know, this information. It also elevates the importance of accessibility and helps us with culture change. So we can start thinking of problems with accessibility as bugs and not as add-on features that we think of after the initial development of the product is complete. And it's crucial for identifying issues that are specific to the particular tool. Some issues with accessibility are going to come up again and again and again. But some are just going to be really niche and you're not going to know unless you're told about your specific project.
Improving technical documentation
Now, if you're thinking that these examples are, like, cool, but they're mostly just setting the stage for improving accessibility and you want to start doing something to actually improve things, or maybe you're not a maintainer of a project and you want to be a contributor, but you don't really feel like you have as much leeway to do some of these earlier steps, then I suggest that you work on improving technical documentation.
And okay. I know writing documentation isn't exactly most people's favorite parts of the job. You know? Maybe there would be fewer people in the room if I had highlighted that this talk was mostly going to be about documentation in the abstract. But I'm hoping that we can manufacture some excitement by displaying just how huge of a barrier poorly accessible documentation can be.
So let's say you're trying to get an overview of some sort of complex process in order to better understand something you're building or trying to debug. So you bring up documentation for, say, the conceptual architecture of this tool. I've done that for an actual technical documentation page. And I'd like for us to take a moment to hear what the experience would be like with a screen reader. It's an important note that the captions here are mine, which I added for accessibility for everyone in the room. This wouldn't actually be part of the screen reader experience.
Oh, I forgot to turn mute off. One second. I have to pull out of that, because...
Link found an error. Link download. The manual. Link found an error. Main landmark. The following diagram shows the relationships. Link graphic open stack conceptual architecture.
You might think if this is all the information you have, maybe this documentation stuff under construction? I mean, all it really said is that, you know, this is a representation, and it's a graphic of conceptual architecture. You don't know if it's an icon or a logo or something actually important. Now, I'm sighted, so I can go see what the page actually looks like, and for those of us in the room and online who are sighted, I can go see what the page actually looks like.
Taking action
So, a few ideas. And with issues, you can make it for something specifically you'd like to fix or just for auditing. So make an issue for yourself to look at the alt text if you don't know right away if any of it is good or not. I suggest you set a reminder for yourself to do this. Put it in your phone, add something to your calendar to do tomorrow while later tonight while waiting for your flight.
And I assure you, you're not gonna want to forget to do this. And that's because as an extra piece of motivation, I have designed a custom hex sticker associated with my talk. But the only way to get one is to tag me in the comments of a pull request or an issue or email me a screenshot, something like that. So I have a limited number of them. If you're here in person, you can try to come find me once you're done to get your sticker. I also know the conference ends in a few hours and there's a lot of people watching online. So if you can't find me in person, I'll make my best effort to coordinate mailing these out to as many people as I can until I run out.
So thank you so much for your attention, and I look forward to getting to see the first steps you all take to starting to commit to change.
Q&A
Thank you so much, Rose. I'll also say, if you want to do a dplyr or tidyr technical documentation improvement, I will happily merge that. Then you can get your sticker.
We have one question in the Slido. What would you recommend to incorporate into visualization packages to make them more accessible? And maybe is there anything beyond just alt text?
Yeah. So one thing... Another thing I didn't touch on is accessibility for people who are colorblind. So one thing that could be really great for visualization packages is to change default color settings so that they are... You want to make accessibility the easy thing to do, not the hard thing to do. So everywhere we should be making it, you know, easy to make sure, you know, if you're not thinking about it, you shouldn't have to think about it.
You want to make accessibility the easy thing to do, not the hard thing to do.
There should also be easy ways to add, like, figure text, which is true of most. And on my external resources, I will be adding some more resources about how to actually write good alt text for visualizations, because that's a tricky skill to master.
Hadley, do you remember what Mine uses to, like, overlays over the image to make sure that it's, like, colorblind-friendly? Do you remember what that thing is called? There's some cool technology. There's some cool technology to make sure that your pictures are colorblind-friendly out there. They, like, overlay on top of the images themselves.
I don't know much about, like, colorblind-related, but since you mentioned overlays, one thing I will mention is... Because I think everybody in the disability community would be mad if I didn't. Is that if you're creating a website or something like that where you're gonna host your documentation, anything like that, if you see a product, there's ones called, like, AccessiBe or things like that that are overlays that say they'll fix your documentation or, I'm sorry, fix your web accessibility, you shouldn't use them. They're under a lot of lawsuits right now, because they actually make accessibility worse for a lot of people. So people have developed plugins to disable them, because using them actually makes websites more inaccessible. So if it sounds too good to be true, like, a quick fix like that, it probably is.
Are there any existing, like, any kind of templates that you can use for creating good accessible documentation that you know of? Yes. So I have... In the external resources, I have there a couple different style guides, examples, and yeah. Things of that nature. Great. Thank you so much.