If you walk along just about any sidewalk in America you’ll see something called a curb cut (they go by different names in other countries). These are where the sidewalk slopes down and meets the road at an intersection. Today we don’t think much about them because it just seems obvious that they would be there, but that wasn’t always the case. It was in the 1960s that disability rights activists first started demanding curb cuts be installed at intersections. At the time, it was nearly impossible to get around most places in a wheelchair without someone to help you over curbs. The activists waged a campaign that slowly got curb cuts installed in more and more places until finally, in 1990, the Americans with Disabilities Act mandated them nationwide.
This was a triumphant moment for the small minority of Americans who used wheelchairs; but the truth is it helped everyone. Even though curb cuts weren’t intended for them anyone pushing a stroller, shopping cart, or rolling suitcase benefited as well. So did elderly people using walkers, or anyone riding something like a bike or scooter. This is what’s known as the curb cut effect: when a feature meant to help minority or vulnerable groups end up benefiting everyone.
There are countless examples of the curb cut effect in action. Assistive technologies like captions are meant for the deaf, but are also used by people watching something in a noisy environment like a bar or one where they can’t play sound like when someone else is sleeping nearby. A button to open a door meant for wheelchair users can also be used by someone who’s hands are full carrying things. There are also many inventions, such as the typewriter invented by Pellegrino Turri to help his blind friend write. And then there’s email, which Vint Cerf, known as one of “the fathers of the Internet”, helped to invent in part because he is hard-of-hearing and his wife is deaf and he wanted a way to easily communicate via text.
That brings us to the Internet. Making websites accessible is treated as a nice thing to have for a few people, but not a priority. As a result it tends to just get tacked on at the end or not at all. According to one study by WebAIM, 97.8% of websites have accessibility issues that can be detected with an automated test. That’s insane, and it doesn’t just hurt those with severe disabilities, it hurts everyone.
Just like in the physical world, examples of accessible design on the web helping everyone are easy to find. Alt text on images don’t just provide descriptions to blind users, they also do so for users with a poor internet connection. And who hasn’t run into that problem from time to time? Insufficient contrast for text (the most common issue found in the WebAIM study) is meant for users with poor vision. Even if your vision is fine however, have you ever found yourself squinting at your phone on a sunny day? Better contrast can help with that. In many cases it can also help users with the various forms of color blindness; a condition which affects 1 in 12 men (less for women). Captions or transcriptions for video and audio on the web help all users for much the same reasons they do in other contexts.
And then there’s the issue I personally run into the most: keyboard navigation. Now, unlike the people keyboard navigation is really meant for I have no problem navigating a webpage with a mouse. However, I generally find it just faster to use my keyboard to tab between elements or “click” things using the return key. I even use an extension to port some Vim keybindings to Firefox which speeds up my browsing even more; but that extension, and normal keyboard navigation, rely on proper semantic markup. Often I will try to do something using my keyboard only to have the browser not respond because the developer of the website used an endless series of divs with click events instead of semantic markup. This is annoying to me but to some users it renders the site literally unusable. Anecdotally I feel like this trend is actually getting worse. I don’t want to completely blame frameworks like React for this because it absolutely is possible to make React applications accessible; but the increase I’ve seen certainly has corresponded with the rise of frameworks like React. The problem is that even though React apps can be accessible many developers clearly just don’t bother. Back when I was learning React I saw countless tutorials with glaring accessibility issues in them, so is it any surprise that people who learn React from those tutorials go on to make the same mistakes in production apps? To make matters worse accessibility is almost never asked about during interviews, so developers often feel no incentive to learn.
Hopefully by now you see that poor accessibility is a problem. However you may also think that getting it right is hard. Maybe that even though accessibility is a good idea it’s still not a priority because, well, there’s a ton of other things you need to do and you’re on a deadline. You can get to it later but first you need to ship that MVP. In reality this is exactly why you need to work accessible best practices in at the beginning and every step along the way, because if you do that then accessibility will become incredibly easy. Accessibility is only hard when you’re trying to replace a mountain of divs with appropriate semantic elements after the fact. When you get semantics right from the start it adds no time at all to your development and can even speed things up because your code will be more readable as you’re still reasoning through it. The same goes for other accessible best practices. Accessibility only has a reputation of being hard because it’s such a pain in the ass to tack on later; so do it right the first time and you’ll skip that pain. Your users, all of them, will thank you for it.