Learning from accessibility work

JupyterLab Accessibility Journey Part 7

You are here.

That’s the spot on the map, the tidy star with clear-cut edges and labeling that orients you in a world of the unfamiliar. Lost? Never. Unknowns aren’t a problem with a map like this. Unknowns barely exist before they can be handled with an addition to the map. This is a place of order, clarity, and immediate success.

This is the utopia project managers and accountants and well-meaning people pushing for change and perhaps Odysseus dream of. This is not the journey that most people take, and it is certainly not the journey of accessibility work in the scientific Python ecosystem.

Jupyter Accessibility Journey blog posts started alongside my efforts to improve JupyterLab and related Jupyter projects for disabled people, especially those using assistive technology that was about as incompatible as can be with the software. These efforts gathered a team and eventually grant support which became the topic for other blog posts in this series. It only feels right to, after some time away, reflect on exactly what this was like now that the major push of the project is over. At the very least, I might as well share the thoughts I had on many sleepless nights about this topic so others don’t have to stay awake about them. (Or at least can have a less fraught journey than Odysseus.)

I’ve wrangled years of work, emotion, and project outcomes into a few landmarks on the metaphorical map: patience and progress; tough pills to swallow; journey pitfalls; and, ultimately, that people do care.

On patience and progress

Like any wide-ranging change, changing accessibility habits in a whole project and its community is not often a quick process. But what does the difference between slow change and no change look like when you are doing the work? It’s hard to tell.

Approaching the process with goals that you can measure (i.e., not as vague as “the software is accessible,” more “all existing images have alt text and it is a part of contribution review that contributed images have alt text to be accepted”). Knowing, and sticking with, what you set out to do is one of the better ways I have found to defend oneself and a team from the sunk cost fallacy, or the idea that because you have already been working on something that the right thing to do is to put everything you have into it without reflecting on how the work has gone so far. This clarity can provide a measure for progress, however slow or small, that allows a team to talk about the ultimately abstract umbrella of accessibility they’ve set out towards in a grounded way.

I have also found it important to document, even personally, good things you’ve noticed changing whether or not you expected them. For example, for a long time in Jupyter meetings I felt like I was repeating the same calls for why it would matter for Jupyter software to follow accessibility standards; I truly felt like the broken record cliche. So when I started noticing that on PR reviews that sometimes people other than me had asked accessibility questions on work I hadn’t even seen, I made a note. That meant that even when it felt like I was on repeat, that it was helpful enough for other people to start feeling confident to approach accessibility questions on their own -- genuinely a big win I didn’t anticipate at all.

One more thing began to stand out to me the longer I spent time around Jupyter accessibility work: accessibility efforts share a staggering amount with security efforts. I learned to look at progress similarly to more established security efforts such as prioritizing consistent commitment over a one-off push for change. They also have good examples for cycles of review and fixes, how to sustain work over time, and how to communicate for efforts like accessibility that are never fully done.

Tough pills to swallow

When I see people deciding they want to work on accessibility, they are motivated primarily by caring for other people. It makes sense, caring that disabled and abled people have a chance at the same opportunities feels like a clear “right answer” kind of priority to many people. And when you are taking on a task you feel has so much ethically in its favor, it can be hard to imagine that a concept that can be summarized in a single sentence could have so many nuances attached.

Of these nuances, I’ve seen the realization that there is not a singular, magically one-size-fits-all, “most accessible” answer be a challenge to reconcile. I can’t count the number of times I’ve been asked to tell someone “the most accessible user interface library” or “the one way to use an ARIA label in every situation” or “the right way to use a screen reader.” These are questions you only get from someone who cares and wants to take action, so I find it all the more painful to have to answer that what works for one person, one assistive technology set up, one context is likely the same thing that will be inaccessible for another. For example, adjusting a data visualization’s colors to rely on less colors may be more accessible for someone who is colorblind, but will give no support to someone who is blind. But the text or table version of the visualization that might work for a blind person and a colorblind person would likely be a major obstacle for someone who is dyslexic and may benefit from the color coding that causes trouble for colorblindness. This doesn’t even cover what someone who can’t use a mouse might need. Or that disabilities often overlap and impact individuals differently even if they would use the same word to describe that disability. Asking one action to support the wide range of humanity’s experience just isn’t going to happen. But realizing that your accessibility goal is not one single change, rather the culmination of many changes flexible enough to respond to what different people need, is often daunting if not outright overwhelming.

Similarly, realizing that accessibility work doesn’t just end can find even the most caring people disheartened. It’s like agreeing to help your friend move across town before you find out they are actually going to live in both places with things moving back and forth indefinitely. When does the work end? Have you pledged the rest of your life to this task? Will you stay here until your skeleton is frozen mid-task like a carnival diorama about accessibility? This, again, is another aspect of accessibility that benefits from referencing other work with indefinite needs such as security or long-term project planning. Knowing that this is maintenance and not a feature can help change the way people approach accessibility issues. Instead of planning to check keyboard navigation tests off a project roadmap once, make the goal to have the tests be a standard part of review or done at a consistent cadence. Instead of planning all your accessibility work for one quarter, plan scoped accessibility tasks every quarter alongside other areas. When considering how your team wants to solve an issue with screen reader compatibility, examine what the maintenance burden is for each proposed solution.

Pitfalls

I want to focus on two pitfalls, or common places I’ve seen myself and teams I’ve been on struggle when working on accessibility.

Jupyter tools are used by many people in many fields. Working to make Jupyter tools more accessible brought me in touch with many individuals and teams in institutions across the world. Every one of them had different backgrounds and current expertise. We’d eventually be working on a task and reviewing against the Web Content Accessibility Guidelines, an institution’s policy, or another verified best practice. More often than not, something along the lines of “these standards weren’t made for Jupyter software and don’t know what would work best for its unique interactions.” This implied that the current solution we were working on could do it better. On one hand, I agree; there are not any public accessibility standards that I am aware of at time of writing that were designed specifically for Jupyter projects or even broader interactive computing. On the other hand, all digital accessibility standards were written for Jupyter projects because Jupyter projects are digital. Many of these resources have also been tested for longer, by more people, and in more contexts than we could actually handle as a small team on one subset of software. It’s tempting to notice only the differences between standards and the work you want to do, but I do believe it is hubris to ultimately decide that one use case can totally override the usefulness of a set of standards. Especially in accessibility cases where these changes directly and immediately impact people using them. Yes, being creative and getting feedback from disabled people working with your accessibility solutions is important; it is just as important to not discard widely reproduced research that already exists because someone believes they can do it better on their own.

In accessibility efforts, advocacy refers to much of the most public and perhaps recognizable work for the uninitiated. Blog posts about why people should care about disabled people, the special interest conference track with one talk about accessibility, or the one-time meeting of your team with an accessibility effort, for example. Many people have written about what advocacy is and their feelings about it. It is frequently the first step in larger accessibility efforts or what’s needed to educate people. All the same, I’ve learned it’s far too easy to be relegated to only advocacy (intentionally or not) by the teams you work with. Advocacy is important for the momentum that it can generate towards actions that actually support disabled people. Advocacy without action can become a feel-good replacement for saying you are doing something while nothing changes. Over time, I’ve found advocacy without action to drain resources of the advocate’s and everyone else around them from time, to energy, to morale. This has been a personally difficult lesson for me, and one I’m not confident I’ve completely understood. All the same, it has impacted my work on Jupyter accessibility and other projects that it belongs in this reflection.

People do care

The most important fact that I’ve learned through my Jupyter accessibility journey is that, no matter how it feels in the moment, people do care. People do care about disabled people having access to the same things abled people do. People do care about improving situations for those they care about and for people they have never met. People do want the things they do and say and make to be better. I would go so far to say that a majority of people do care.

However idealistic that sounds, I’ve talked to a lot of people in a lot of different areas orbiting tech and science. This is true. Don’t let people tell you otherwise.

Yes, caring and making tangible changes are not the same thing. The same way that setting a goal to change your life with the new year doesn’t mean everyone changes, it also does not mean that no one cares. I would argue the opposite; if no one cared about accessibility, we would not have the many publicly available resources we do. We would not have people asking questions or proposing solutions, even if they don’t all work. Remembering that people do care is important to keep your hopes up, something I know I’ve struggled with time and time again while working on Jupyter accessibility. An important part of surviving accessibility efforts is to ask for help and offer it in return. We do care, and we are capable of more together.