I want to be honest with you, I started asking accessibility questions in JupyterLab spaces while filled with anxiety. Anxiety that I was shouting into the void and no one else would work on accessibility with me. Anxiety that I didn’t have the skills or energy or knowledge to back up what I wanted to do. Anxiety that I was going to do it wrong and make JupyterLab even more inaccessible. Sometimes I still feel that way.
Here’s the thing. That anxiety, while real and worth acknowledging, doesn’t help the disabled people we constantly fail and exclude when we keep building things inaccessibly. So yes, I want you to know I felt that way and that you might too, but I also want you to remember who we are here for, especially if you are working to support a group you aren’t a part of (as is the case with me). Plus, many of these concerns didn’t end up happening. First, I didn’t end up being alone at all! Each of the people that have joined in have different skills that have helped us tackle issues that I don’t think any of us would’ve been able to on our own. Knowing we are working together also helps keep me accountable because I’d like to be able to show up to our meetings with something to share. As for worrying that I’m doing it all wrong, I suppose that’s still a possibility. Speaking for myself, I’d rather be making mistakes, learning, and iterating than continue to let JupyterLab stay inaccessible indefinitely.
In a space where considering the needs of disabled people isn’t the standard, accessibility might feel like an insurmountable challenge. For example, when I showed up to our first devoted accessibility meeting, JupyterLab’s accessibility status was like a hazy shape in the distance. I was pretty sure it wasn’t good, but I didn’t know for sure how or why. A few meetings later and a closer look made me realize that haze was actually smoke and I'd walked myself and others directly into a (metaphorical) burning building. But just because it felt like everything was chaos without a good place to start didn't mean that was the truth. In fact, it wasn't. Building software is more about people more than any tool, so let’s consider what our regular team of people on the user-contributor-maintainer spectrum said are the basics of what they care about in JupyterLab.
Users want to:
- Use JupyterLab to read or navigate documents.
- Use JupyterLab to edit and run documents. To edit a document, users need to be able to navigate where they want to edit, so the read-only experience is aprerequisite.
- Know what things they can do in JupyterLab and get help on how to do it.
Contributors want to:
- Gain enough understanding of a JupyterLab in order to work with it.
- Understand the expectations of their contributions and how to meet them. In this case, they would want to know that they need to think about accessibility and how to consider that.
Maintainers want to:
- Ensure that JupyterLab is both progressing and relatively stable.
- Promote sustainable growth for a project that doesn’t overwrite past efforts. Automation can be helpful because maintainers are usually strapped for time.
With the support of a team member with prior experience auditing for accessibility, we pinpointed specific ways in which JupyterLab lacked support for accessibility broken up by WCAG 2.1 standards.
From conversations with these more experienced community members, we found that issues generally broke up into four categories of work needed (not necessarily in this order):
1. Make JupyterLab accessible for a read-only type experience
This is something users need. For our purposes, we’re using read-only to describe what you need to navigate and consume all the content in JupyterLab from the interface to the documents and processes that live in it. Most of this also falls under WCAG standards, and are the first things users need to start working with JupyterLab since it’s difficult to interact with a space if you can’t get where you want to go.
2. Make JupyterLab accessible for an interacting/editing experience
This is something users need and is the other half of WCAG standards. Once you can navigate the space, people need to interact by writing, editing, running process, and so on. While WCAG standards do cover interactive web experiences and they are written generally enough to apply to many interface types, their roots in a more standard website experience means that we also have some grey areas to account for since JupyterLab can easily include complex and layered interactions than even other web apps. We are supporting this by looking into how other tools with similar uses (like coding) approach these types of accessibility and hope to test it in the future.
3. Accessibility documentation
This is something users and contributors need and has two parts. One part is making the documentation itself accessible through WCAG compliance in the docs theme, labeling relevant content, and providing content in different forms. Second is adding documentation specifically for accessibility such as how to use accessibility features and how accessibility fits in to our contribution process.
Accessibility and documentation both have reputations for falling to the wayside, and we almost got so caught up in applying WCAG standards to the software itself that we continued the pattern. But making an accessible experience is, like any UX problem, not limited to the time spent within that product. Think of it this way, if there is no accessible documentation on how to get started with JupyterLab and use relevant accessibility support, then all the work we’ve done in the software itself won’t be able to serve the very people it is there for.
4. Adding relevant accessibility tests to the JupyterLab contributing workflow
This is something contributors and maintainers need, though the results also benefit users. As grateful as I am to have a group of people who are taking action to make JupyterLab accessible, it isn’t enough on its own. We aren’t a group that can review every single PR and we may not all be able to devote time to this forever; tests ensure that accessibility remains a priority in the contributing workflow regardless of individual involvement. It also will help prevent current efforts from being overwritten by new contributions.
Automated accessibility testing has its limits because you are trying to quantify an experience without getting users involved, but I think a first pass and a reminder to the community—especially the contributing community—that accessibility is something we are all responsible for is critical. Since accessibility isn’t yet a regular standard for contributions in many projects, feedback from tests might also be an opportunity for people who haven’t worked with accessibility before to start learning more.
Where we are now
As I’m writing this post, our team is mostly focused on JupyterLab accessibility for WCAG compliance starting with the read-only type experience. Among many things, JupyterLab is currently missing of landmarks and labels that block manual accessibility testing to a degree since they prevent further navigation and interaction. Starting here means that we are a step closer to users being able to accessibly read content in the interface.
If you are going to take away one thing from my journey so far, I’d tell you to be consistently brave. Feeling anxious in the face of challenges and accepting areas where you don’t yet have knowledge is normal, but it isn’t reason to back down. Find the people that will collaborate with you and dive in. And when I get lost and don’t know what to do, I find it most helpful to put people first and remember who I am doing this for. Breaking the work into pieces by what users need can help you strategically start putting out fires.
Focusing on people just for strategy isn’t all though. Be on the look out for my next blog where I’ll talk about what the disconnect of what accessibility meant to different people in our community and how that impacted the time and way we’ve solved issues in JupyterLab so far.
Interested in getting involved? Join our community via the JupyterLab accessibility meetings listed every other week on the Jupyter community calendar.
Top comments (3)
Great to see that you have managed to put accessibility on the roadmap, and from the sounds of it quite high up the priority tree!
I am not familiar with JupyterLab (I literally just had a play with it now, interesting software I will have to explore some more!), but from your description here and the little bit I have seen it seems like there is a large part of this that falls under ATAG which is for "content creation" software (mainly CMS, but the principals apply to any documentation system where you are creating content).
This may help you with the queries / objections that the person who uses a screen reader raised in the discussion thread you linked, as WCAG compliance won't get you all the way there.
Also just from the wording used in the discussions, you all might need to just adjust the focus from "compliance" to "great experience"....that slight shift in thought process tends to make you learn to use a screen reader (it is quite easy I promise, takes maybe 30 minutes to get the basics down!), screen magnifier etc. and see where the major problems are rather than trying to follow a set of rules and guidance that are quite poorly written and confusing (but obviously essential)! It tends to focus your priorities a lot better!
I look forward to seeing more in the series and great work so far, you are already ahead of 95% of the competition just by putting accessibility on the table!
Oh and don't worry about feeling lost in the world of accessibility, I have been at it ages and I still get lost in it all!
Thanks for the kind words and advice! I'm surprised I haven't run into ATAG before, but it does look like it can help fill in some of the questions we are having while working on JupyterLab.
I totally agree that there is a huge difference in mindset and effort based on "compliance" to "great experience." I intentionally chose compliance to reflect the state I feel most of the community is currently in, but you make a point that setting the expectations higher may help us aim higher regardless of where we are now!
ATAG doesn't get spoken about often, mainly because building publishing platforms is hard in the first place, adding accessibility on top after you have built it is a nightmare most developers don't want to endure.
Hopefully though while you are reimagining your product it is the ideal time to look into it.
As for the compliance vs great experience bit, if anything it makes life easier and doesn't make the bar any more difficult to reach. It just means that you will focus on the problems that 100 people experience rather than the problem one person may experience but it "ticks another box".
Overall I find it actually makes the job of improving accessibility easier as instead of 100 small things to focus on you can pick 3 or 4 big things and work on them (plus as an added bonus you learn the answers to the 100 small things along the way).
I look forward to hearing more about your progress as I said and if you ever need a little help on something you are all stuck on / unsure about feel free to give me a shout, if I have the time to help I will!