Accessibility Checklists — Just say No

Sheri Byrne-Haber
Mar 11 · 6 min read
Checklist with Yes and No Options, red pencil, X in “no” checkbox

I am a Accessibility Manager with 15 years of experience. No more general A11Y Checklists, PLEASE !!!

There are so many articles touting themselves as general “accessibility checklists” that I’ve literally lost track. Even respected organizations like W3C and WebAIM have published them. WCAG 2.1 triggered the authoring of a slew of new checklists. Consultancies post checklists partially to try and prove that they are subject matter experts, and partially to scare companies into thinking “wow, this is complicated, I need to hire a consultant.” There is one author who appears to be in the process of posting a general accessibility checklist for every…single … US state.

Checklists are part of a reactive, not proactive accessibility practice

Checklists typically come into play long after the digital property is designed. The time to fix accessibility problems is BEFORE they are introduced (i.e. prevent them from happening in the first place). There is zero difference between accessibility defects and other types of software defects from this perspective.

Checklists are a black and white solution in a sea of gray

Checklists are inherently black and white. Accessibility is 10,000 shades of gray. An instruction like “make sure there is closed captioning and use the BBC guidelines” is appropriate to be included in a checklist. It is short, succinct, and not open to interpretation by people with non-technical backgrounds. See my conclusion on the very narrow conditions when checklists are OK at the bottom of this article. You can even say “make sure you test for color blindness” or “make sure you test visited text link color ratios” in a color checklist.

Checklists do not motivate people to think neutrally or positively about people with disabilities

It is well known that requiring accessibility or guilting or punishing people for failing to provide accessibility is at the bottom half of the accessibility motivation hierarchy.

WebAIM’s Hierarchy for motivating accessibility change. In order of effectiveness from strongest to weakest they are inspire, enlighten reward, require, punish, guilt

Checklists are a crutch

People who don’t care about understanding people with disabilities and aren’t interested in investing time actually learning about accessibility are frequently the people relying checklists. They want to feel that they have in fact accomplished something good, where chances are they’ve missed opportunities to really comply to WCAG 2.1, or better yet, go above and beyond and make whatever they are working on not only compliant but usable. There is no substitute for putting in the time and effort necessary to grok accessibility.

Checklists put blinders on users

A checklist by its very existence implies that it contains the entire universe of things that checklist users need to care about. Users wear “checklist blinders”. When they find an accessibility issue outside of the checklist it will likely be flagged as a “feature request” even if it is a legitimate WCAG 2.1 Level AA defect because. . . repeat it with me . . . “it’s not on the checklist”.

Checklist items open to interpretation create more problems than they solve

You can’t create a general accessibility checklist comprehensive enough to cover the entire universe of accessibility guidelines that is not open to multiple interpretations by different users. Since consistency is a guideline in two different locations under WCAG, boom, you are possibly out of compliance before you even begin.

Checklists don’t lead to an inclusive culture

Checklists highlight the differences that people with disabilities experience. They subtly reinforce a culture that excludes people with disabilities by separating them, rather than promote an inclusive culture. #Diversish, anyone?

Accessibility and usability are NOT equivalent.

One requirement for a digital property to claim that it is accessible is that every activatable component must be reachable from a keyboard. But accessibility is not the same as usability. You can meet that keyboard access accessibility requirement, but absolutely fail to be usable if it takes you 58 tabs or 27 swipes to get to the footer after page load.

When are checklists OK?

Atul Gawande’s book promotes thoughtful checklist use under some circumstances. Surgical checklists are usually the last thing I remember before I get knocked out by anesthesia, and I’ve actually participated in answering questions in the operating room from checklists. So they aren’t always evil.

Conclusion

NO MORE general accessibility checklists!!!!! Invest the time to create a positive, effective accessibility program. Design for accessibility, train everyone who touches the content and infrastructure, and include people with disabilities in every step of the path including research and testing.

Sheri Byrne-Haber

Written by

CPACC Certified Accessibility professional with degrees in CS, law, business. Wheelchair user w/ a deaf daughter. AccessibilityMarketplace.com