Accessibility Checklists — Just say No
Checklist with Yes and No Options, red pencil, X in “no” checkbox
I am an 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 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.
An entire book has been written on the checklist used by Atul Gawande, Rhodes Scholar, MacArthur Fellow, Harvard educated surgeon who is now the head of the new Amazon / Berkshire / Chase health partnership. His opinion — Checklists might be thought of as handy but are abused and frequently misused. If you don’t believe me, believe him :-)
I firmly believe that general checklists are the lazy/ignorant person’s approach to accessibility, and they should be avoided unless there are NO other alternatives. They are probably better than providing no instructions, but not by much.
Generally, general accessibility checklists do far more harm than good in establishing a good accessibility program. There is even a good argument that a culture that relies on checklists for dealing with disability-related issues is probably not inclusive regardless of what fluffy “we value everyone” language they have on their diversity and inclusion microsite. Here is why general checklists are a pox on accessibility programs everywhere.
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 first). From this perspective, there is zero difference between accessibility defects and other types of software defects.
For an accessibility program to be successful, it needs to be proactive, designing accessibility into a system, making people care about accessibility, and taking the opinions of people with disabilities into account by conducting inclusive user research.
Now, I will substitute the word “quality” for accessibility in the above sentence.
For a quality program to be successful, it needs to be proactive, designing quality into a system, making people care about quality, and (blah blah blah) conducting inclusive user research.
Any arguments about the second paragraph? I hope not because this is the basis of Six Sigma.
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” should be included in a checklist. It is short, concise, and not open to interpretation by people with non-technical backgrounds. See my conclusion on the 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.
You CANNOT put “use meaningful text” in an alt-text checklist without defining meaningful text, which takes pages of explanation and examples. And then you no longer have a checklist; you have a style guide.
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.
No one wants to wade their way through checklists at home or work. They are primarily perceived as nothing more than a set of tasks that must be slogged through, blocking you from stating you have accomplished something. There is nothing positive about that statement.
Checklists are a crutch
People who don’t care about understanding people with disabilities and aren’t interested in investing time in learning about accessibility are frequently the people relying on checklists. They want to feel that they have accomplished something good, where chances are they’ve missed opportunities to comply with WCAG with1, or better yet, go above and beyond to make whatever they are working on not only compliant but usable. There is no substitute for putting in the time and effort necessary to grow accessibility.
Checklists put blinders on users
By its very existence, a checklist 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 are 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 promoting 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. However, accessibility is not the same as usability. You can meet that keyboard access accessibility requirement, but it fails to be usable if it takes 58 tabs or 27 swipes to get to the footer after page load.
Take a look at Safeway or any other 90 % of the top 1,000,000 websites that don’t have a skip-to-content link and try to use it without a mouse and touch if you don’t believe me. Good luck with that, and then imagine keyboard-only users (like me) and switch-only users who live this frustration 24/7.
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 participated in answering questions in the operating room from checklists. So, they aren’t always evil.
I think general accessibility checklists containing all WCAG 2.1 Level AA guidelines should not be used and should never be used in an organization trying to achieve accessibility maturity. Accessibility checklists can work for very narrow topics such as content management and social media.
Content updates are frequently made in real-time and come from third parties. One example might include Coca-Cola providing content for the McDonald.com website. Content managers tend to be less technical contributors and need specific instructions about what is OK and not OK to post since once they hit the “done” key, it will be available globally in seconds. You can take a perfectly accessible infrastructure and break it by updating accessible content with inaccessible content. Giving a third-party vendor a checklist to follow when updating content that you might get sued over is not bad.
Social media posts are a lot like content management from the accessibility perspective. They are frequently real-time, involve partners, and tend to be handled by less technical contributors. Having checklists for color, closed captioning, and descriptive audio is limited enough that it will work positively.
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.
It is vastly more important for people participating in accessibility to understand what constitutes an accessible form than to know that 2.4.6 is the label requirement. Baking an understanding of accessibility and empathy for people with disabilities into your organizational DNA is the road to avoid getting sued.
Note: Thanks to Mike Gifford from OpenConcept, whom I met at #A11YBayCamp, who encouraged me to pull this article out of my “pending topics” list and finish it while I was on the plane to #CSUN2019.