Amazing though it may seem, we each experience the world differently. That's one reality with over 6 billion interpretations. Many of us use computers to broaden our experience of the world, but a computer is part of reality and so if you experience reality without, for instance, vision or sound, then you also experience a computer without vision or sound (or whatever your unique experience might be.) As humans, we don't quite have the power to experience the world the way somebody does. We can mimic some of the surface-level things (I can close my eyes to mimic blindness, for example) but it's only an imitation, without history, context, or urgency. As a result of this complexity, we humans design things primarily for ourselves, based on the way we experience the world. That can be frustrating, from an engineering and design viewpoint, because even when you intend to be inclusive, you end up forgetting something "obvious" and essential, or the solution to one problem introduces a problem for someone else, and so on. What's an open source enthusiast, or programmer, or architect, or teacher, or just everyday hacker, supposed to do to make software, communities, and processes accessible?
Don't miss the opportunities
A friend of mine, who lives with hearing loss, recently signed up for a webinar and contacted the host to request captioning or, failing that, a transcript of the lessons. It was a great disappointment when the host, who had specifically emailed all participants with an invitation for feedback, never even responded to the request. In the end, some mutual friends attended the webinar and took notes.
[ Also read My open source journey with C from a neurodiverse perspective ]
The webinar was a small event run by an individual, so it's possible that emails all around were going unanswered until the end of the multi-week event. However, this incident can serve as a valuable lesson: Accessibility starts with communication.
You can't know the unique needs of every single person interacting with the thing (website, software, podcast, article, and so on) you produce. You can't predict what small arbitrary choice you make might lead to the accidental exclusion of someone who would otherwise have engaged with you. What you can do, though, is look for opportunities to learn about them. When someone sends an email about how the 8-point, thin, 45% gray font on a white background makes your website hard to read, don't ignore it, and don't chalk it up to a difference in opinion. When someone files a bug that Orca or NVDA can't navigate your application, don't close it until it's fixed.
What to do when you can't help
Nobody knows everything, and that's true for each of us participating in open source. It's very likely that you'll get a comment from somebody with an issue in something you've designed, and you won't know how to fix it. Or you might know how to fix it, but you just won't have the time to implement the fix. That doesn't make you a bad person, it just reveals the one thing that's true for all of us: You have limited resources. But through open collaboration, there's more than likely an answer.
Open source is all about sharing, and this is as true for code as it is for community resources. Identifying a bug at the very least demonstrates what your project needs from potential future contributors. Possibly, the person making the request or filing the bug can help you find someone who knows how to fix the issue. Or maybe they have friends who help them find a work-around, and could at the very least document the round-about way they deal with the issue, which could be exactly the stop-gap you need while you upskill enough to find the "right" fix for the problem.
[ Related read A practical guide to light and dark mode in Jekyll ]
Answers to usability and accessibility aren't always as direct as you think they need to be. Sometimes, a simple work-around or accommodation is all that's needed. I contribute to a fairly technical podcast, and I was once asked whether I could release transcripts. It's beyond my means to produce those for every episode, but as a concession I have, ever since, included either existing reference documentation, or I write new documentation on the podcast's website, so that even if a potential listener can't process what I say in the podcast, at least the information I impart isn't lost. It's not the best solution (although admittedly my podcasts aren't always as focused as they could be, so actually reference documentation is probably the better option) but the "answer" to the problem is really easy for me to do, but something I hadn't thought to do until someone asked.
Sometimes the "right" answer is "no." I've gotten requests for visuals to accompany audio-only content before. While it was possible to do that, it would have required a completely different production and hosting infrastructure, and so the answer truly was "no." However, I was able to respond to the request with a list of resources that were providing similar content along with video. You can't be everything to all people. Knowing your project's, and your own, limitations is important, and it's equally important to respect them.
Open communication
Communication is the starting point for usability and accessibility. When someone reaches out to you because something you're doing isn't accessible to them, that is, strange though it may seem, a marketing success. Somebody wants to engage with your content or your project. That's exciting! Don't pass up those opportunities.
1 Comment