24
Making Accessibility Accessible
I'll be honest: I've never been very accessibility-minded. I deal with mild colorblindness, so I get the need for strong color contrast, but besides that, I've always felt like accessibility was beyond me. I thought it was just something for accessibility experts, not a real problem that I needed to consider in my daily development.
That is, until I interviewed some of those experts. I'm very grateful that they took some time to sit down with me, and boy, did I learn a lot. Here's a recap of three main lessons that I learned from my interviews with Tessa Mero, developer advocate from Cloudinary and Henri Helvetica, king of web performance and accessibility.
A site is either accessible or non-accessible. It's actually quite binary, since a partially-accessible site is still non-accessible. If you can't access all the features as a limited user (that includes human disabilities as well as those on devices with limited ability), then your site isn't accessible. As a way of testing our websites for potential hiccups, Henri proposed asking ourselves this question:
Can you achieve digitally, with some accessibility-related limitation, what you would have been reasonably able to do in person?
For example, imagine a banking website where you can do anything you would be able to do at a typical bank in person (within reason, of course). All of those features can be used by someone with accessibility challenges except for one: cashing a check. That's fairly simple to do at a bank (you can just hand the teller your check), but on the website, that might require the user to line up the check perfectly in their phone's camera view, which is nearly impossible if the user is blind. That's not accessible! The user could not achieve digitally, with their limitation, what they would have been able to do in person. Fixing this is quite a large task, as it would probably require rethinking the use of the camera in the first place, but asking the above question and identifying this as a potential problem area is the first step towards making their site usable by all.
Do you remember the time a blind man sued Domino's Pizza because he couldn't order online? Or the time a blind woman from New York sued Beyonce because she couldn't keep up with the singer's latest news and products as easily as someone who could see?
The American Disabilities Act (and there are roughly equivalent laws in other countries, though details vary) requires that businesses that meet certain criteria for size and purpose must then keep their websites accessible to the blind, the deaf, those who must navigate by voice (for example, the paralyzed), and those with other limiting disabilities. While the law (at least in the United States) doesn't explicitly state any rules on deciding whether a website is accessible or not, it's commonly accepted that accessible websites follow the Web Content Accessibility Guidelines as established by the World Wide Web Consortium (who also set the HTML, CSS, DOM, and WASM standards). While the actual guidelines are pretty obtuse, the best practices they advocate for are found in simpler form by reputable sources all over the Internet.
You might've noticed earlier that when I defined "limited users", I included those on devices with limited ability. That's because, while we often think of accessibility as making your site friendly for the blind, it actually means making your website friendly for anyone with any limitation, including but not limited to:
- Users on mobile devices
- Users with bad internet
- Users who simply prefer having a site read to them by a screen reader
- Users with browser extensions that mess with the page
- Users with a slow computer
- Users on old browsers that don't support the newest features
- Users that have set their browsers to minimize the amount of motion on the screen
- Users with a broken peripheral device
Those are just the technological impairments that many of our users could potentially be dealing with. And that's in addition to the potential human disabilities they may face:
- Users who have vision impairments, who might not see a button if it doesn't contrast enough with the background or if it can't be focused with a screen reader
- Users who cannot hear well, who might not understand instructions if they only come in non-captioned video form
- Users who must navigate the Internet by voice, who may not be able to click a link if a non-semantic tag is used instead of
<a> - Users who don't intuit the things we might expect the user to know, who may not understand, for example, what a Share button looks like
- Users with short-term memory impairments, who might not remember where they're supposed to click in your complex navigation
- Users with perceptual disabilities like dyslexia, who may not be able to read our site if the font is too small or too thin
- Users with tremors, dystrophy, arthritis, or some form of reduced dexterity, who may not be able to accurately move the mouse to keep hover-operated tooltips open
Truly, accessibility and user experience are one and the same, since the experience of such a wide swath of our users — over half are on mobile, for example — depends on us paying attention to their limitations, technological or human.
I really enjoyed my chats with Tessa and Henri over on my Twitch channel. They taught me ways to expand my checklist for site-building to include considerations for the limited experiences I previously hadn't thought to test. The biggest lesson I got from these conversations was that accessibility and user experience require a lot of thought and care, even more than I had realized. Unfortunately, that makes it hard to also focus on your site's performance and underlying architecture, which is where TakeShape comes in. TakeShape's API Mesh enables front-end developers to harness the power of the Jamstack to reduce site complexity and ship faster, so your time is freed up to hone what matters the most: your user experience.
I actually learn a lot about a wide variety of subjects from these interviews, like the lessons Mark Lane discovered as he built several successful SaSS tools or that time I found that data and content modeling is actually a fascinating subject when Jeff Eaton is talking about it. If you're interested in catching the interviews live, keep an eye on my Twitter (@jadenguitarman) and Twitch (jadenbaptista).
Recordings of the interviews can be found on YouTube: