Introduction:
Hello, hello everyone, welcome to my talk: Why Designers are the Mediators of Accessibility.
Thank you for coming to little corner here, of FOSDEM 2022: Open Source Design Room.
First, an introduction of your speaker, Mars Lee. I’m a Front End Developer and Designer. I work at Quansight and contribute to NumPy. For my visually impaired folks at home, I’m as Asian woman with octagonal glasses , and in bright primary colors.
As you know, this talk is only 20 minutes long and there is a loot to cover. So we’ll go going quick. These slides and links will be attached around. You won’t be seeing me anymore, but if you want to see more of this mugshot, join me in the QnA afterwards! Alright, let’s get started!
Table of Contents
Like any good book, we got chapters. The first half is who, what, why, The theory.
The second half is the application. Hear how my partner in crime created an accessiblity workshop that spanned the globe- and across open-source projects. You’ll leave with actionable steps for creating a more accessible open-source space- perhaps with a workshop as well!
Part 1: What + Why Accessibility
Accessibility is making the world accessible to the full range of human experience, which includes disabilities. For example, to access school, a wheelchair user uses a ramp. To read books, a blind person uses Braille
I do emphasize the full range of human experience: Not just people with disabilities, I mean everyone. Curb cuts were originally made for wheelchair users. But they also help people with strollers, luggage bags, or doing sick skateboard tricks!
Translating books is allows more people to access new worlds and imagination. Accessibility benefits everyone
Accessible technology is very similar. For example, to access online school, a visual impaired person could use a screen-reader. To access news, you could read, yes, but you can also access news as data visualization. Data visualization is a form of accessibility too.
Accessibility is important because it lets use live creative, independent and fulfilling lives. For example, you can access a museum, and be inspired! But also, put your own spin to make it uniquely yours.
Hellen Keller could access book via Braille, and create her own book! The world heard her and listened. With access to the world, people with disabilities can shape it as well. The digital world and data is the future- and people with disabilities are also in that future.
Some may ask, why should open-source software in particular, be more accessible? Firstly, disabled developers already DO exist. Secondly, to not be accessible would be against the very ethos of open-source. OSS prides itself being free not behind a high price-tag! It is available to all. That’s radical, that’s so cool! And that ethos creates a beautiful culture of giving back and contributing.
But available does not necessarily mean accessible.
If we were to make open-source more accessible, then people with disabilities can join in!
Everyone can contribute back.
We are going to make open-source accessible, and if you agree, then get on my magic carpet, and let’s goooo! But wait… wait. Where do we start? Are there guidelines? Which ones? Oh no, we’re stuck.
Part 2: What are the Barrriers?
First barrier is that- well, where you do even start? People with disabilities are not the problem- we would like to have everyone be able to access open-source software.. But the just there are different people, there are different disabilities and different solutions.
A person with an auditory impairment or Deaf has different options if they want to access a news report. There may be a sign language interpreter. Or the video has closed captions. Or maybe they would prefer to read the transcript.
All are possible. Open source is decentralized- alas much like a Greek tradegy, its greatest strengths are also it’s weakness. Accessible technology is about creating a cohesive alternative experience, like running a parallel track. It’s a little different, but ultimately leads to the same place. However, different contributors contribute different things. That can make for patchy coverage. Like a running track with holes.
Another barrier is Current OSS developer needs and culture. I use the word ‘current’- because it can change. Developers have release cycles and workflows. This is good! It brings the decentralized things together. But that can make it hard to a new concept or project, such as accessibility, to gain foothold.
Primary platforms are not where the disabled community gathers. Github, for the most part, is for developers. And there are disabled developers. But open-source projects built upon, remixed and released to millions of users. Asking an ordinary disabled user to sign up for Github to make an issue about a product that can’t even fully use- that’s a lot.
There is still a perception that accessibility is ‘non-essential’, even though Accessibility benefits everyone. It’s like how design is often an afterthought.
All these barriers and walls… There’s walls are not malicious or intentional, but there are there. There’s tension in the air. Some people don’t feel heard! Some people don’t understand what’s the problem.
Hmmm, I wonder, who could help? Oh, I know, designers!
Designers, breaking down barriers like Kool-Aid man, the beloved drink mascot. Here, he gets a paintbrush, since he’s a designer now. And a little beret. Snazzy!
Part 3: Why Designers.
Why us? Whhhy us?
Well, design is already accessibility. Redesigning a news site to be more readable? That’s accessibility, especially cognitively. Increasing the contrast because it’s hard to read? Bam, you’re helping people with vision loss. Bad design can harm people. Good design helps.
Us designers? We already have the skills to be the mediators of accessibility. And these skills are from our visual arts training.
The ability to zoom out and see the big picture. Finding connections between disparate objects. Seeing it from another angle, try another composition. To create a pleasant user flow. To have someone’s eyes follow the connections, jumping from point of interest to interest. Zooming in and out as you did. Where the viewer is fully immersed in your art
Another reason why designers are the mediators- We are simultaneously both a insider and outsider. Used to advocating that design is important.
While we may feel like outsiders, we’re not the only ones. In comparison, we’re insiders. We have insider knowledge.
These may be the millions of users who use open-source everyday- but not even realize it. The ones who are not on Github, and the inaccessible parts still block them from using a product, enjoying their lives or independence.
We can mediate in the middle.
Expand the circle. And that first step, open the door to many more, that others feel comfortable too.
Similar situations happen all the time for disabled developers. But instead of time zones, it could be accessing images in documentation. The phrase ‘Read the docs, everything’s in there’ assumes everyone can access these things. If they can’t access it, it can be hard to even ask for change, such as creating a Github issue. And if someone tries and they cannot, then they may not try again.
It’s easy to end up thinking “There’s no problem.” Again, it’s not intentionally malicious. But it’s easy to assume.
Designers can mediate by standing in both spaces, hearing from both, to stop assuming and making space intentionally.
Part 4: Our Story+Impact
From theory to action- this is a case study! From messy beginning to running workshops
Our story begins like many others. Current open-source culture focuses on building some very good things. But as you see, no one was talking much about accessibility. It wasn’t a common topic.
So someone just asked the question. Accessibility? This person was Isabela Presedo-Floyd! She’s my workshop co-host. But back to the story. It started off small. It was a little scary too- what nobody think it’s any worth? But the conversation grew! And grew! That’s how I found out abou it and joined her.
Using your position: An insider asking an outsider question, representing those who are not here.
I joined her, but what now? Where do we start? As mentioned earlier, there’s many different disabilities and solutions.
We kept learning more and more and more! It got a little overwhelming. We asked ourselves “Could we really help anyone?”
It’s sort of like trying to find Waldo in a Where’s Waldo picture. Is he there? There? Or there?
You end up so caught up in one detail, another one, and another one, that you’re zoomed all the way in! But wait! Zoom back out.
Yes, there’s a lot, but you don’t need to solve everything all at once. And yes, Waldo is actually here. Right there. Riiight there.
We had to zoom out and Prioritize: Understand what our disabled users need most. We started with what was already there.
Then we moved out further. Beyond Github, such as social media. In the same way, Github isn’t the default platform to most designers. Some get past this barrier, others don’t.
Twitter is one place with a sizeable disabled community.
We learnt a lot too! There’s so many resources, such as a11y, the Diagram Center, Chartability. In fact, we‘re are writing a resource for cross-project collaboration, called the Scientific Python Ecosystem Coordination. A forum for this specific niche of ous. Check any of these out!
We learned, now we apply. One example was in the NumPy documentation. We created alt-text by following the resources cited earlier.
Alt-text is what screen-readers read out so that people with visual disabilities can also experience the image.
We were making progress, but in our own projects, individually. Is there a way to spread this? At a larger scale?
We wanted to spread it, but the barrier was decentralization and culture.
But we were approaching it the wrong way. We were not taking advantage of these barriers. To turn them into the strengths.
That’s our big lightbulb moment. Rather than work against open-source and feel left out, we work with it. We create our own space.
We created a workshop that introduces accessibility- and fits into existing developer workflows and platforms. We can use the same tools to create something different. And the familiarity makes it an easier introduction.
At last, our accessibility workshop! The alt-text workshop. We crowd-sourced’ adding alt-text to images. By hosting short 1-hour sprints where people make contributions. Using the Github Suggestion feature
Let’s break it down.
The Github Suggestion feature is traditionally used in code reviews. Small changes or discussion. But we saw potential for more.
There was a page in the NumPy documentation lacking alt-text.
So we created a fork, where people can modify the document using the Github Suggestion feature.
The whole workshop was accessible through a web browser-no terminal or git needed.
Git is great- but can be huge learning curve. Cloning branches, local, remote, origin, forking…what a fork-ing problem!
We already knew git, Github and branching. So we took care of it. From the master branch, we created our own branch, contributors made their Github Suggestions, and we mediated with the maintainers to merge these back into the master branch. Contributors get contribution recognition.
The end result was NumPy documentation that was more accessible.
We did the workshop with Jupyter, NumPy, scikit-learn, Dask, and even internally in our company’s blog.
We are proud of our impact.
- It is a large scale introduction to accessibility + take action immediately, all in 1 hour
- It reached new groups, especially first-time contributors
- It already made changes to the codebase
- We’re still doing this! We want to do more, perhaps with your project?
Part 5: Key Takeaways
Since we’re near the end, here’s a quick wrap up.
Accessibility benefits everyone, especially people with disabilities! You get a book, you get a book, everybody gets a book!
Designers are the Mediators because of their Skills and Position
Part 6: Actionable Steps
Connect with other OSS projects and learn together.
Communicate across projects to stop re-inventing the wheel and prevent burnout.
Talk to disabled users, see what they need. Try all the platforms!
Talk to developers. Just start asking. You’ll see who else will join you on your quest, this fellowship.
If you like what we did, click subscribe! OK, not subscribe, but reach out to us! We can host a workshop with your project. Or you can go rogue, and host one yourself. Community organizing is a such a valuable skill and we want to help you with that.
You can also see our workshop in action, in the video here.
As action-packed and informative this talk was, this is only the beginning. There’s so many other areas we could cover. But beginning is exactly that- the first step. The first in removing many more barriers, and creating a culture where people with disabilities feel welcomed and can contribute back
Thank you for Isabela Presedo-Floyd and Tony Fast for starting this journey. Thank you workshop partners, including Frank Evalsky for inspiring us in the Jupyter workshops. Thank you FOSDEM for organizing all this!
If you want reach me, you got options! Email, Github, Twitter or LinkedIn. Maybe you’ll be at my radical afterparty, which is my QnA. Either way, peace out, everyone.