My grandfather used a wheelchair after suffering a spinal injury in his forties. His house had a long ramp and a tiny elevator, his pepper grinder was electric, and he slept on a waterbed (it was AWESOME). If he were using the modern Internet, he'd be using accessibility tech. He had mobility in his hands, and I think a mouse with the sensitivity dialed way up would've been manageable, but I think he would've found speech-to-text software really useful.
We all live different lives and experience different kinds of constraints. It's a basic premise of our existence. Internet resources aren't any different, and humans (taken as a whole) are great at using tools and tricks to access what they need. We can adapt, and that's amazing. But making sites that everybody can use with a minimum of adaptation requires care and attention from developers to implement accessibility. If we write inaccessible code, the site won't be accessible, and we'll have excluded groups of people from being able to use and enjoy the experience our application provides.
Why Accessibility Matters
"Accessibility" generally indicates "the ability to access," which means that it'll always depend on conditions and capabilities that are unique to a given user. It's necessarily broad because humans vary widely. In coding, it's somewhat close to "implementing and maintaining compliance with a web standard aimed at making the Internet more inclusive and easier to access."
In a perfect world, this wouldn't need to be explained. Access to information and resources should not be gated behind possessing a mythical, perfect level of ability. Nobody exists without experiencing the world in their own way, so we shouldn't be building tech that fails to take the wide range of human experience into account. There are a lot of great resources out there making this point from smarter folks than me. Here are some.
Let's take vision as a limited example because the Internet is largely a visual medium. There are a LOT of people on the Internet. Like, 4.66 billion people (says Google). Effectively, it's a number so large that we can't imagine it. A recent WHO fact sheet on vision impairment states that 2.2 billion people worldwide experience some form of vision impairment. This covers a wide range of disabilities, but this other article suggests that something like 3% of the global population experiences moderate-to-total vision impairment.
Or, put another way, 1 in 30 people across the entire species. This is part of why we have screen-readers. And that's only one axis of human experience that can be complicated by a failure to account for differing degrees of ability. Screen readers allow users with limited mobility like my grandfather to use speech-to-text software to access and create content. Reading text aloud can help neurodivergent people process information more effectively. That's why we talk about accessibility; this is one aspect of human life that can be made vastly easier if we just write better code.
And it's better, more thorough code that makes the most difference to end-users. The rest of this post will try to stop yelling about moral principles and actually talk about coding. I may or may not succeed at that, given the track record so far.
Accessibility matters AND it's good for your code
Luckily, writing accessible code is often the same thing as writing simple, effective front-end code. Browsers are intended for general use and offer a lot of functionality intended to make sure that it's possible for developers to write accessible code. For instance, this is what the Lighthouse tab in Chrome does. Translating stored information into a visual medium that a non-technical user can manipulate is kind of the whole point of a web browser, and the companies and organizations that create and maintain them have a clear interest in making sure that their user base is as large as possible. It's a crucial part of how they make money.
But the existence of browser-supported tools means that it's up to us as developers to write code that can be accessed by people. We can cite some specific examples:
- Complicated
tabindexranks are a trap. You can add whatever you like (I've definitely done it), but anything greater than 1, 0 or -1 likely means that hittingTABwhile on a webpage will be about as predictable and reliable as hucking rocks over your shoulder. It also makes it impossible to navigate a site via keyboard, which is hugely important for users with mobility issues (and developers that just flat-out refuse to touch a mouse :|). - Form elements should almost always be labeled. It's way too easy to write a clever UI element that skips adding a label and then discover that what you've written just cannot be effectively navigated when something needs to be responsive. Screen readers agree; they don't like guessing what a form does, and shouldn't have to. Writing well-structured forms with labeled fields is clearly a best practice, and implementing it is the same thing as making your code more accessible.
- Browser media elements are fun! Sound effects can be really satisfying, YouTube should be a public service at this point, and I'm writing this while listening to Spotify (which is based on Chromium). But they can cause problems. Autoplaying videos can really screw up screen-reading, because screen-reader users frequently need to, y'know, hear what the software is saying to them. Also, videos that play automatically can consume system resources that you'd otherwise have available for other tasks, and nobody likes them.
- Failing to implement good captioning can create huge problems for deaf and hard-of-hearing users. If they're out of sync, incorrect, or there's no structured summary for the content, then it increases the friction experienced by users attempting to engage with that content. This is why Zoom recently added automatic captioning. A lot of the fixes for transcription involve paying for a service, which isn't what we're going to cover here. But writing semantic, structured HTML that includes summaries for videos and alt-text for visual elements means that you've made it much simpler to receive and parse the information you're trying to communicate, and that can go a long way toward making a site more accessible.
- Deuteranopia (the inability of your eyes to receive green light) and protanopia (the same thing, but for red) are really, really common. The linked article cites a common statistic: about 8% of people with XY chromosomes experience some form of color blindness (the number is significantly lower for people with XX chromosomes, around 1 in 200 people). If the text color in a given element is too close to the background color of the element, it can be really hard to read. Don't do that.
Etcetera, etcetera, etcetera. By writing consistent, simple, accessible front-end code wherever feasible, it becomes easier to make sure that your users can access and navigate your site's content.
That's the main argument: human diversity needs to be represented in the code you write because browsers are built to be used by a wide range of people and excluding your users is counter-intuitive. Above, I cited some examples, which are by no means exhaustive. This is a huge, complex world, and my goal here is to demonstrate how writing better code makes your users' lives better. Which, phrased that way, seems somewhat obvious, but that's okay.
Next Steps
In Part Two, we'll turn to talking about a basic framework for adding some automated accessibility checking to your application. In Part Three, we'll apply that framework to an existing Rails application, which is more complicated and involves RSpec wizardry.
Top comments (1)
This is great content and I hope I can get to read the whole series 👏
I've studied CS and worked with visually impaired people (and got defeated playing street fighter against a guy with zero vision 😂) and until just a few years ago there was little buzz around a11y. Now I'm glad to see that it's gaining notoriety along with i18n 💪