Accessibility Checklists — Just say No

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 W3Cand 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.

There has been an entire book written on checklist use 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 used inappropriately. If you don’t believe me, believe him 🙂

In general, I strongly 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 at all, but not by much.

In the long run, 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 I think 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 in the first place). There is zero difference between accessibility defects and other types of software defects from this perspective.

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’m going to 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” 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.

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 either at home or at work. They are largely perceived as nothing more than a set of tasks that must be slogged through, that are blocking you from being able to state 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 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.

Take a look at Safeway or any other of the 90 % of the top 1,000,000 websites that don’t have skip to content links and try to use it without a mouse and without 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 actually 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 specifically to very narrow topics such as content management and social media can work.

Content updates are frequently 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 they are updating content that you might get sued over is not a bad thing.

Social media posts are a lot like content management from the perspective of accessibility. 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 it is for them to know that 2.4.6 is the label requirement. Baking an understanding of accessibility and an empathy for people with disabilities into your organizational DNA is the road to avoid getting sued.

Note: Thanks to Mike Gifford from OpenConcept who 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.