This post by Maranda Provance, our Director of Engineering, accompanied her CodeMash talk on January 10, 2020.
The most amazing thing about the Internet is its ability to level the playing field—bringing virtually unlimited information to anyone with a connection—and the idea of accessibility has been baked into the Internet from its beginnings.
When we talk about accessibility for people with disabilities, we can split this into four groups.
Visual Impairments
The World Health Organization estimates that "285 million people are estimated to be visually impaired worldwide: 39 million are blind and 246 million have low vision.” This group uses a tool called a screenreader to literally read content off the page. It's our job not to get in the screenreader's way.
Hearing Impairments
For this group, we need to consider the user of transcripts and captions.
Mobility Impairments
Many causes might restrict a user's ability to navigate through a web page with a mouse. To assist these users, it's important to make controls accessible through the keyboard (e.g. in a web form).
Cognitive Impairments
This group of users may suffer from a range of mental health disorders that have effects like difficulty understanding a task or not being able to remember how a task was done before. This group has no easy fixes, but the most important thing to keep in mind is making sure layouts are consistent and logical. Basically, the foundations of good design will help this group the most.
Bonus — Accessible websites also help power users breeze through sites with a keyboard.
This part can't be reproduced exactly unless you can get your buddy to read it to you. Here's what I read to the audience:
Close your eyes.
You’re in your living room relaxing on your couch. You see darkness. Maybe a hint of light when you turn your head to the window, but otherwise, nothing.
But your other senses are intact. You hear the pitter-patter of your Corgi’s paws on the hardwood floor. Maybe some incessant whining if it’s anything like my Corgi…
You feel the soft, squishy fabric of the couch underneath you. You smell the potpourri your mom brought over yesterday. And you hear your stomach start to grumble.
So you decide to order some of your favorite food. You guessed it—a nice, greasy pizza.
So you do what any other normal American does when they’re in need of some ZA—you get on your computer to place an order.
As a blind person, you use the help of a screenreader to read content from the screen, and because you’re fancy AF, you get to hear the Domino’s menu read to you in a British voice.
So your British robot is reading your options to you, and in this ideal world, you can use your keyboard to make your selections, enter your payment information and get to that sweet, sweet Domino’s tracker all without being able to see a thing.
Twenty to thirty minutes pass and you have pizza all to yourself, without having to bother another soul. That's something that we all take for granted!
Alright everyone, you can open your eyes and join me back in the real world.
Domino’s was ruled against in a lawsuit because this very scenario that I’ve had you picture is not truly possible for people with visual impairments. I don’t want to get too into the weeds with the legal stuff, but I can tell you that real companies (large and small) are being sued under the ADA—the same laws that require all businesses to be wheelchair accessible.
We know what accessibility is. Now how do we know we hit the mark?
The three levels of the WCAG standards are basically a good, better, best approach. If I had to sum them up in just a few words each, here's what I would call out:
- A — The bulk of requirements are in this first level.
- AA — Adds rules for contrast (background vs foreground text) [4.5:1]
- AAA — Contrast ratio requirements are increased to 7:1
I encourage you to look at the full WCAG standards. They are written a bit like legalese, but that's why I'm encouraging you use a tool to help you along.
So we know what how to find our instructions in the WCAG standards, but how do we test our work in real life? We can use a screenreader.
On my Mac, I used the built in VoiceOver program by hitting Cmd + F5. There are others available as well.
Every effort should be made to build and fix websites so they're usable for people with disabilities to the greatest extent possible. But, will there be somebody at some time who has trouble using or reading something, despite adhering to best practices like those outlined in the Web Content Accessibility Guidelines (WCAG)? Yes, of course.
Every little bit helps. It’s not about perfection—it's about doing our best to help others.
Chrome’s accessibility audit is a simple automated testing tool that also gives you tips on how to take your work farther with manual testing. It’s not everything, but it’s a great way to get started.
In my talk, I walk the audience through an audit on The Geek Foundation's website. Chrome's article on how to use the accessibility features available in dev tools is a great way to learn more.
When you use the audit tool, make sure to take note of the manual testing tips they provide. Automated tests can only go so far.
Helpful Testing Tools
If you want to kick your testing up a notch, there are several other tools I recommend:
- Axe — Axe has tools for Web, Android, iOS, and Windows
- Accessibility Insights — Microsoft's excellent tool has options for Web and Windows applications; this is my new favorite
- Pa11y — Open-source software with a command-line interface (CLI), dashboard, JSON API, and continuous integration (CI) support