Hi, I’m Nolan, a totally blind software developer working on accessibility at Fly.io. I’ve worked on website remediation, I’ve written screen readers from scratch, and I also create 2-D audio-only arcade games. Here’s a screenshot of my latest game:
Like every developer, I rely on a number of products and services to manage and promote my many side projects. But I’ve had more than one neat idea go down in flames because I simply couldn’t use the amazing, must-have service that would have made that project feasible to complete.
A few weeks back, Chris McCord launched LiveBeats, a real-time collaborative MP3 player, inspired by turntable.fm. LiveBeats is cool on its own merits (check it out), but, just as importantly, it’s designed to be a model real-time Phoenix LiveView application, a blueprint other people can start with for their own apps. And, well, the model real-time Phoenix LiveView application needs to be more accessible. Today, I’m going to get you into the right mindset by talking about what that means, and why it matters.
Reading about accessibility is good, but engaging is better. For obvious reasons, I’m serious about this stuff. If you’ve got questions, or accessibility thoughts of your own, hit me up here. I’m more than willing to chat about this stuff.
Doing accessibility well isn’t difficult, especially if you plan ahead. So I’d like to talk a bit about what accessibility is, why you should care, and a few common missteps teams make on their journey.
What Is Accessibility, Really?
Broadly speaking, accessibility refers to whether someone can use your product or service regardless of how they interact with it.
As a blind developer, I naturally focus on screen reader accessibility. Now, it’s important not to fall into the trap of assuming that accessibility is one-size-fits-all. But improvement in one area generally helps across the board. It’s OK to start somewhere and branch out.
Accessibility is not a destination, but a process. It’s meeting your users where they are, and working to improve their experiences. As your product evolves, it gets faster. More reliable. More featureful. You should expect it to get more accessible too.
Why Should I Care?
First, you care because it makes your app better. Accessibility isn’t just about whether your software or service is usable by the 15% of the world’s population that identify as having a disability.
Services with fewer interaction limitations are almost certainly easier and more pleasant to use for everybody. Common sense, right? Take mobile accessibility. For me, labeled controls and clearly-defined focus areas are essential. But those same “accessibility features” could just as easily serve you with reliable voice operation while driving, or just with your phone safely tucked away. And if you’re already investing in good UX, many of those same practices transfer to building solid accessibility.
Next, you care because any of us might acquire a disability at any time. One day, I stepped off a curb, twisted my ankle, and had a hard time supporting myself on that foot for several months. I don’t normally need physical supports, so my home wasn’t built with them. I had a lot of trouble doing things myself.
My partner has a mobility-related disability, however, and her apartment has a number of grab rails and transfer bars. My life was so much easier while I was there. Most of the time for me, accessibility is primarily about whether and to what extent I can achieve something non-visually. But for those few months when I had a new temporary disability, every painful struggle in my home was a moment when I desperately wished we designed more universally, not waiting for someone to need accessibility before haphazardly slapping it on.
Eventually age will likely impair your hearing, eyesight, mobility, or cognition. But even if age treats you well, injury or illness may temporarily render you unable to use products and services on which you’ve come to rely. If you’d like to keep doing the things you enjoy, then you owe it to yourself and others to care about accessibility before it becomes something you depend on.
Build Accessibility in From the Start
Accessibility is an ongoing conversation, not a single step. Putting off an important chat until the last minute is usually a recipe for disaster. So is deferring accessibility planning until your customers squawk about it.
Deque University’s accessibility courses are a thorough foundation for any team wanting to learn lots about web accessibility.
Imagine planning an industry event that you’d like to be accessible. You’ll need to select a venue, line up presenters, and arrange printed material for distribution to attendees. Treating accessibility as something you can retrofit might work out, if you’re lucky. More likely, you’ll miss the fact that the venue is atop a flight of stairs. Deaf participants won’t be able to participate in presentations. You’ll dump a pile of paper on people who can’t even read it. And inevitably someone will write an angry blog post about it. I’ve been there. Trust me, the person writing the angry blog post wishes they didn’t have to write it.
All of these missteps are significantly more difficult to fix at the last minute. Incidentally, they’re also mistakes I see people in our industry make, over and over again, when they host events – even events they describe as “accessible”.
Compared to an accessibility checklist, an accessibility-focused process asks what barriers each choice might impose, then works to either address or eliminate those before they’re set in stone. Doing this requires knowing which questions to ask, and asking them before they become costly mistakes that are hard to fix.
Gather Your Tools
Modern tools can identify many of the most common access pitfalls. Though imperfect, automated testing can usually catch enough issues to make an inaccessible app at least usable. A minimally-usable app can then be audited “live”, which provides far more effective feedback.
Deque’s Axe DevTools extension runs a number of automated in-browser accessibility checks. They’re no replacement for live testing, but the extension can catch a number of issues that you can fix before bringing in outside help.
On the web, lots of useful checks are baked directly into modern browsers’ development tools. Even more advanced tests can be installed via extensions. Mobile apps have similar tooling, either run directly on-device or included in your IDE.
Test With Real Users
If you’re serious about a product, you test it for usability. In the same way, you should test your product and its overall design to see how it works for users with specific access needs.
Knowbility is an excellent provider of accessibility consulting, training, and testing.
Some teams learn the basics of the most popular screen readers and magnifiers. That’s a great way to build empathy. But unless you use these tools daily, you’re not using them the way people who rely on them do, and so you’re probably not using them correctly or effectively. This is a solvable problem! Accessibility testing services help you identify specific access needs, scope tests to address them, and recruit testers to provide actionable feedback.
Hire Lived Experience
One of the best ways to be better at accessibility is to recruit and hire people with disabilities. You don’t need someone with every disability. A decent dose of empathy goes a long way! But we’re usually (by necessity) the experts on our access needs, or are better equipped to ask the right questions and identify the most important next steps. Having people with disabilities on your team is one of the easiest ways to sort out the “must haves” from the accessibility “nice to haves”.
And there’s a large pool of experts out there. The unemployment rate among disabled folks is staggering—around 60% in the US blind population, for example. That’s sixty. A six, followed by a zero. And the numbers are similarly high across other disabilities.
A word of caution, though: if your group goes this route, please don’t make the disabled person your company’s “accessibility czar”. Hiring lived experience should be a part of your accessibility strategy, but not the whole thing. We’re already expending extra energy advocating for our access needs alone outside of work. Making accessibility entirely our responsibility at work is a sure path to burn-out.
Back to LiveBeats, For A Moment
A big part of what I’m doing at Fly.io over the coming weeks is taking LiveBeats, the model Phoenix LiveView application, and making it accessible. I want people to learn not just the right way to stand up a Phoenix application, but also some of the most important tools to make all their applications accessible.
So, LiveBeats lets you play and listen to music with friends. All web apps have a bunch of generic accessibility problems. But LiveView posed a few additional unique challenges:
- New routes are loaded dynamically, with no indication to screen reader users that a page transition occurred.
- Live updates to specific regions of the page should be made accessible in ways that make sense, and don’t negatively impact user experience.
- Dropdown menus and modals are not keyboard-accessible by default, and require some clever tricks to make the accessible experience seamless.
These are all fixable issues, and I’ll post articles about solving them in turn. But I’m interested in hearing from you as well. If you have questions about what I’ve shared, or are curious about other aspects of making a real-time web app accessible, please let me know! I’ll be reading and responding to comments in the Fly.io community forum.