Every time I give a talk about making accessible websites, I get the following question:
“What checklist do you use to make sure a site is accessible?”
My response always surprises them:
“I don’t use a list.”
Why not? There are so many lists out there that I could be using! Practically every US government agency has a checklist published on their site, and several non-government sites offer checklists of their own. With so many free resources, why do I ignore checklists?
The easiest answer is to turn the question around, and ask the same of designers, developers, or UX experts.
“What checklist do you use to make sure a site is beautiful?”
“What checklist do you use to make sure your codebase is maintainable and efficient?”
“What checklist do you use to make sure a site is easy to use?”
There aren’t any checklists like that. Trust me, I’ve looked.
It’s about usability
Accessibility is really usability for a subset of users who some additional requirements. While a checklist can be a great place to start a discussion about accessibility, it’s not the endpoint. A checklist only tells part of the story.
A truly accessible website is both accessible and usable. There’s often very little in these checklists that can be used to measure the annoyance level of a disabled user. What is usually measured is binary: Can the user access the function / information or not? No one asks if the user must go through a half-dozen page loads, or tab through an entire page of links to get to the one that they need.
Someone following a list exactly will also often over do their efforts. For example, nearly every checklist will have a line about all images requiring alt text. Consider the following screenshot:
There’s some text, a picture of a book, and some stars. What images in this snippet should have alt text?
The correct answer? None of them.
Most people, following a checklist, will insist that all the images need some sort of alt text, and that all text in the images should be duplicated. If we do that, this is what this snippet might sound like to someone using a screen reader (ignoring links):
Image: Book cover. Fitness for Geeks. Fitness for Geeks by Bruce W. Perry April 2012. Image: Star. Image: Star. Image: Star. Image: Half-star. Image: Grey star. Three point five. Ebook: 27.99 Print and ebook: 38.49 Print: 34.99
The title is repeated twice, and the stars themselves actually obfuscate the book’s rating. By adding alt text to the images, we have actually detracted from the experience of someone using a screen reader. Skipping alt text, we would have a block that reads like this:
Fitness for Geeks by Bruce W. Perry April 2012. Three point five. Ebook: 27.99 Print and ebook: 38.49 Print: 34.99
This is already much cleaner than the example with alt text, but it’s one we’d never get if we doggedly followed a list. There are just too many judgement calls. Just like usability, there are no hard and fast rules that will guarantee an accessible site.
It’s a complicated crowd
When you talk about accessibility to most people outside of the field, they assume you’re talking about the blind. The fastest way to blow their minds? Tell them that accessibility includes:
- The physically disabled or limited
- Those with low vision
- The color blind
- The Deaf
- People with hearing loss
- The cognitively disabled
These groups also change over time. A few years ago, the cognitively disabled were rarely mentioned when discussing the accessibility of a site. Over time, advocacy groups have brought more attention to their needs. Checklists often don’t update to include these changes.
And the field is still changing. As the Boomer generation ages, many find themselves in more than one category at once. Lists often focus on how a particular disability will affect a particular feature, but don’t think about how these different disabilities might interact. My father-in-law is losing his hearing as well as his vision. Does your video player have keys that are easy to see as well as subtitling? Is the subtitling easy for him to see?
It’s treated as an end point
When I do accessibility work, that checklist is often treated as the end deliverable. Once every box is checked off, we’re done. But it’s not.
All a checklist tells you is that you’ve scraped by on some general recommendations. Sure, you have subtitles. Are they legible? Do they go too fast? You can tab to all the interface elements. Can the user do so without jumping around random parts of the page?
When I mark down that an item has failed, there is usually a narrow-minded rush to fix that item as quickly as possible. Does a drop-down menu not work with keyboard control? Add a link to a page without dropdowns. Does an inline-definition function interfere with screen-readers? Add the definitions to another page and rip them out with JavaScript.
Technically, you might say that the websites are now accessible, but really, the solutions were not thought about deeply. Why not fix the underlying functionality so they work better for everyone? There are libraries of accessible navigation menus available, and there are ways to make text not interfere with a screen reader.
What would I want to see instead?
I would prefer it if checklists were only used as a place to start a conversation, and were more nuanced than ‘pass’ or ‘fail’. After all, for most things in our life, we succeed in increments. The paper was okay, so it got a C. The paper was fabulous, so it got an A. The teacher writes in comments, praising and critiquing by turns.
If someone is doing something right, even by accident, they should be told about it. If they’re doing something wrong, they should get something more clear than a fail. Often, a solution can’t fully be offered in the small box of a form. If anything, offering a small text area (even in a Word doc, where you could make it bigger!) encourages short, pat answers. No one is served well by these, most of all the users.
So, if you’re looking at making your site usable, be careful not to stop at a checklist. It will only encourage the quick, easy solution, might guide you to make your site less accessible, and can badly hurt your usability.