Forem: Isabela Presedo-Floyd

Putting Out the Fire: Where Do We Start With Accessibility in JupyterLab?

Isabela Presedo-Floyd — Thu, 27 May 2021 22:11:18 +0000

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.

Spot the differences: what is new in Spyder 5?

Isabela Presedo-Floyd — Sat, 17 Apr 2021 15:11:46 +0000

In case you missed it, Spyder 5 was released at the beginning of April! This blog post is a conversation attempting to document the long and complex process of improving Spyder's UI with this release. Portions lead by Juanita Gomez (@juanis2112 ) are marked as Juanita, and those lead by Isabela Presedo-Floyd are marked as Isabela.

What did we do?

[Juanita] Spyder was created more than 10 years ago and it has had the contributions of a great number of developers who have written code, proposed ideas, opened issues and tested PRs in order to build a piece of Spyder on their own. We (the Spyder team) have been lucky to have such a great community of people contributing throughout the years, but this is the first time that we decided to ask for help from an UX/UI expert! Why? You might wonder. Having the contributions of this great amount of people has resulted in inconsistencies around Spyder’s interface which we didn’t stop to analyze until now.

When Isabela joined Quansight, we realized that we had an opportunity of improving Spyder’s interface with her help. We thought her skill set was everything we needed to make Spyder’s UI better. So we started by reviewing the results of a community survey from a few months ago and realized that some of the most common feedback from users is related to its interface (very crowded, not consistent, many colors). This is why we decided to start a joint project with Isabela, (who we consider now part of the Spyder team) called Spyder 5!!!

This version was in development for over a year and was finally released on April 2nd. It has some nice new features that we hope will benefit our users greatly. Most of these are focused on improving Spyder’s interface and usability, which we did thanks to Isabela’s help. The 3 main UX features implemented in this release were:

A brand new color palette designed to bring greater consistency to the UI and to make it easier to use.
The redesign of our toolbars by adjusting the margins and sizes of all the buttons to meet accessibility recommendations.
A new set of icons to ensure a consistent style.

How did we do it?

1. First impressions

[Isabela] I find collaboration usually starts with three things: discovering and stating a problem, asking why, and figuring out the best ways to communicate with each other. For me, this is a design problem on it’s own, especially when starting to work with a new team like I was with Spyder. For this project, I was asked to audit Spyder for any UX/UI issues and report back. Because I have a habit of pushing every button in an interface, I ended up having a lot (maybe too much) feedback to pass on. One of the things I remember most about opening Spyder for the first time was having three dialogs pop up immediately. That’s really not the first impression you want to give, and I remember talking to Juanita about that right away. Figuring out how to state problems as simply and clearly to a group of people I didn’t know yet was intimidating and went through several phases.

2. From the “nightmare document” to the issue tracker

[Juanita] The first phase was discussing all the problems that Isabela found in weekly meetings with Carlos, the Spyder maintainer, and Stephanie, another Spyder core developer. I created a Google drive document (which we ended up calling “The Nightmare document”) in which I collected most of the feedback that Isabela gave us. Then, I grouped this information into categories depending on whether the comments were about the interface, in general, or if they were about a specific pane. Once we agreed on a relevant problem that we wanted to address, I opened an issue on a new repo that we created in the Spyder’s organization called “ux-improvements.”

[Isabela] In fact, that wasn’t even the first set of documents we were working with; I had a whole table, numbering system, and document I was trying to handle before. But it was Juanita that turned them into Github issues.

3. Sorting out the nightmare

[Juanita] Since we ended up with more than 30 issues, we had to start a “triaging phase.” We had to label, triage, organize, and prioritize issues according to “urgency” and importance. This issue tracker became our main tool to keep up with all the plans for the future!

[Isabela] Juanita did wonderful work tracking our progress through issues and keeping us all accountable, but we were still left with a long list of issues to triage—long enough that it wasn’t all getting in Spyder 5. To have the greatest impact on Spyder, we started with the issues that had influence on Spyder as a whole. Toolbars, icons, and colors are something you will always encounter from the first impression to the most recent, so it made sense to start thinking about those big picture issues first.

4. Digging deeper into the dark hole

[Isabela] When prioritizing the audit feedback for Spyder 5, each pass seemed to get to a deeper layer of the problem. For example, what started as issues to make tooltips more legible and improve the variable explorer’s color coding soon became the realization that we weren’t sure exactly what blue was already being used for much of Spyder’s interface. It got more complicated when we found out how many colors were hard coded across multiple files or defined by an external project. Eventually, the problem changed from the color contrast of tool tips to an unsustainable approach for managing color across the two default Spyder themes rooted in a non-Spyder repo. Work at each step did build up into a larger solution, but it’s worth noting that it isn’t what we set out to do in the first place.

5. What witchcraft does Isabela do in the background?

[Juanita] One of the most important parts of the process was designing the mock ups for the new ideas that we came up with for the interface which is definitely not our expertise. So... how did the designs magically appear
on our Github issues?

[Isabela] First things first, it isn’t actually witchcraft even if it looks magical from the outside. How I work depends somewhat on what problem we are trying to solve, so let’s use the design of custom icons for Spyder 5 as an example. Once I had a defined list of icons to work on, I needed to spend time making progress on my own. Research on best practices for the relevant area of design is where I started; in this case, I knew we were going to be working with Material Design Icons’ specifications. After that, I did a combination of pen-and-paper sketching and working digitally based on the existing icons in Spyder and Material Design Icons while I kept note of the pros and cons for different directions. I also collected design elements as I built them so that I could make more consistent, accurate designs faster as I worked. For the icons, this included things like letters, rounded corners, and templates for the size and spacing of elements. Finally, I compared options side by side and tried them out in the interface to evaluate what designs were strong enough to bring them to the rest of the team. Then we discussed the options together.

6. Mock ups Vs Reality

[Juanita] After many discussions, mock ups, and meetings, decisions weremade and we were ready to move onto the implementation phase. A big part of the improvements were made in QDarkStyleSheet where we did the new palette and color system for both the dark and light themes of Spyder. In my opinion, this was the hardest part of the process since it involved getting familiar with the code first and then, trying and trying again changing lines of code to change the color or style of buttons, tabs, toolbars, borders, etc…

The other problem that I ran into, was trying to meet the designs’ specifications. Specially, when working with the toolbars, figuring the right number for the pixels of margins and sizes was a challenge. I tried several values before finding one that closely matched the proposed mock up only to realize later that “pixels” was not the best unit for the specifications. I ended up using “em” since it was more consistent across operating systems. Isabela, Stephanie and Carlos were part of this process as well. Between the four of us we managed to implement all the changes that we had planned for Spyder 5, the new color palette, the complete redesign of toolbars and the new set of icons. It was an arduous task, more than we all expected, but at the end we were all very happy with the results and thankful to Isabela for helping us to give a new face to Spyder.

What's the final result?

[Isabela] Individually, the colors, toolbars, and icons may feel like small adjustments, but those are some of the elements that make up most of Spyder. When they are together, those small adjustments set the mood in the interface; they are more noticeable, and rooted in the Spyder UI many people are already familiar with. While the changes may feel obvious when they are new, they are also chosen to create consistent patterns across interactions that can become more comfortable over time. Spyder’s default dark and light modes, for example, used to use a different set of UI elements between modes. Now they both use the same elements and it is only the colors that change. This makes it easier for users to jump into a familiar interface and take what they know from working in one space to another. For contributors, it gives a more clear UI pattern for them to follow in their own work.

Before and after (Dark theme)

Before and after (Light theme)

What did we learn :)?

[Isabela] From developing new skills to working as a team for the first time, I think we both took a lot from this process. Here are some lessons that stood out to us.

[Juanita]

Sometimes it is better to try some of the ideas during the process, than having long discussions about an idea and implementing at the end. In some cases you end up realizing that things don’t look as good as you thought they would, or that some are not even possible.
One of the most important parts of the design process is to get yourself in the users’ shoes. At the end, they are the reason why we work to improve things constantly.
Occasionally, less is more. Simple and consistent is better than crowded and complicated.

[Isabela]

Don’t be afraid of asking questions even when you think you understand the problem because every bit of information can be useful to better grasping what hurts or helps users.
Always take the time to review what you might think is obvious with the rest of the team. It’s easy to forget about what you know when you are working with people who have different skills than you.

Accessibility: Who's Responsible?

Isabela Presedo-Floyd — Sat, 27 Mar 2021 02:56:37 +0000

For the past few months, I've been part of a group of people in the JupyterLab community who've committed to start chipping away at the many accessibility failings of JupyterLab. I find this work is critical, fascinating, and a learning experience for everyone involved. So I'm going to document my personal experience and lessons I've learned in a series of blog posts. Welcome!

Because this is the first of a series, I want to make sure we start with a good foundation. Let me answer some questions you might be having.

Q: Who are you?

A: I'm Isabela, a UX/UI designer at Quansight Labs, who cares about accessibility and is fortunate to work somewhere where that is a respected concern. I also spend time in the Jupyter ecosystem—especially around JupyterLab —though that is not the only open-source community you can find me in. I like to collect gargoyles, my hair is pink, and I love the sunflower emoji 🌻. It's nice to meet you!

Q: What is the Jupyter ecosystem and JupyterLab?

A: Project Jupyter is an organization that produces open-source software and open standards. The Jupyter ecosystem is a term used to describe projects that are directly a part of or support Project Jupyter. JupyterLab is one of its primary projects and a staple for the day-to-day work of many students, professionals, researchers, and more.

Q: What is accessibility?

A: Accessibility is a term used to describe the practice of creating things in a way that makes them usable for people with disabilities. I’m going to be talking mostly about web accessibility since JupyterLab is a web app. If you're asking why you should care about accessibility, please take a moment to read why it matters (hint: there are ethical, legal, and business reasons to care). Inaccessible experiences can have consequences, from people not being able to get information they need to being unable to pursue whole careers that rigidly require the use of inaccessible software (such as JupyterLab).

How did we get here?

The Jupyter ecosystem is full of people who care about accessibility. I know this because I've heard people ask about accessibility in community meetings. I know this because I've read discussions about accessibility on Github issues and PRs. I know this because the project has a repository devoted to organizing community accessibility efforts. If this is the case, then why hasn't JupyterLab already been made more accessible in the past three years it's been deemed "ready for users?" (I'm intentionally not mentioning other Jupyter projects to limit this post's scope.)

Because for every time accessibility is brought up, I've also experienced a hesitance around taking action. Even though I’ve never heard it explicitly said, the way I’ve seen these efforts get lost time and time again has come to mean this in my head: “accessibility is someone else’s problem.” But it can’t always be someone else’s problem; at some point there is a person taking ownership of the work.

So who is responsible for making something accessible? Probably not the users, though feedback can be a helpful step in making change. Certainly not the people that already can’t use the tool because it isn’t accessible. But I, personally, think anyone who is part of making that tool is responsible for building and maintaining its accessibility. Just as any user experience encompasses the whole of a product, an accessible experience does the same. This should be a consideration from within the product, to its support/documentation, to any other interaction. A comprehensive team who thinks to ask questions like, “how would I use this if I could only use my keyboard?” or “would I be able to get the same information if I were colorblind?” are starting to hold themselves and their team accountable. Taking responsibility is key to starting and sustaining change.

Misconceptions

Here are a few common concerns I’ve heard when people tell me why they can’t or haven’t worked on accessibility. I’m going to paraphrase some replies I've heard when asking about accessibility in many different environments (not only JupyterLab) over the years.

I don’t know anything! And that’s fine. You don’t have to be an expert! Fortunately, there are already a lot of resources out on the wide open internet, some even focused on beginners (some of my personal favorites are at The A11y Project and MDN). Of course, it’s important to remember that learning will mean that you are likely to make mistakes and need to keep iterating. This isn’t a one-and-done deal. If you do have access to an expert, spending time to build a foundation means they can help you tackle greater obstacles instead of just giving you the basics.

I don’t have time for another project! Accessibility doesn’t have to be your only focus. JupyterLab sure isn’t the only project I am working on, and it won’t be in the near future. Any progress is better than no progress, and several people doing even a little work can add up faster than you might think. Besides, there’s a good chance you won’t even have to go out of your way to start improving accessibility. Start by asking questions about a project you are already working on. Is there a recommended way to design and build a component? Is information represented in more than one way? Is everything labeled? It’s good practice and more sustainable to consider accessibility as a regular part of your process instead of a special side project.

It’s not a good use of my energy to work on something that only affects a few people! It’s not just a few people. Read what WHO and the CDC have to say about the number of people with disabilities.

I don’t want to make abled people’s experience different than it already is! Depending on what you are doing, the changes might not be active or noticeable unless assistive technologies or accessibility features are being actively used. And in many cases, accessibility features improve the experience for all users and not just those they were designed for (sometimes called the curb cut effect). Even if you aren’t convinced, I’d encourage you to ask yourself why creating the user experience you want and making that experience accessible are mutually exclusive. What are people missing out on if they can’t use your product? What are you missing out on if they can’t use your product?

What could responsibility be like?

With JupyterLab, it was just a matter of a few people who were willing to say they were tired of waiting and able to spend time both learning what needed to be done as well as doing it. Speaking for myself, I did not come in as an expert or with undivided obligations or even someone with all the skills to make changes that are needed. I think this is important to note because it seems to me that it could have just as easily been other members of the community in my position given similar circumstances.

Our first step in taking responsibility was setting up a regular time to meet so we could check-in and help one another. Then we set reasonable goals and scoped the work: we decided to focus on JupyterLab rather than multiple projects at once, address WCAG 2.1 standards in parts of JupyterLab we were already working on, and follow up on past work that other community members began. This is just the beginning, but I hope it was a helpful peek into the process we are trying out.

But wait, there's more!

Deciding to make accessibility a priority in Jupyter spaces isn't where this work ends. Join me for the next post in this series where I'll talk about my not-so-subtle panic at the amount of problems to be solved, how to move forwards in spite of panic, and the four experience types in JupyterLab that we must address to be truly accessible.

Interested in getting involved? Join our community via the JupyterLab accessibility meetings listed every other week on the Jupyter community calendar.