Anatomy of an Accessibility Program

A lot of Tenon’s customers have come to us specifically because they’re getting sued. In many cases, accessibility is entirely new to them. So, if you’ve never done any research into the prior litigation history of web accessibility then some of the stuff you’ve seen might be based on a demand letter you received or lawsuit filing and, depending on the plaintiff law firm, the details will vary.

When I heard about the lawsuit filed against Winn-Dixie (Beckman v. Winn-Dixie), I had a friend with PACER access pull up the filing. I must admit I was pretty impressed with the filing. I’m not a lawyer and won’t pretend to be, but the filing sets up a case that, if true, outlines a number of factors that substantiates a claim that Winn-Dixie discriminates against people with disabilities.

The primary reasons for the claim are:

1.    Functional performance issues impacting users with assistive technologies

2.    Features users interact with lack contextual help

3.    The site is missing an Accessibility Notice

4.    The company has no Accessibility Policy

5.    The company has no Web Accessibility Committee

6.    The company has no Web Accessibility Coordinator

7.    The company has no Web Accessibility User Testing Group

8.    The company has no Bug Fix Priority Policy

9.    The company has no Automated Web Accessibility Testing Program

10. The company has no Specialized Customer Assistance line for people with disabilities

11. The company has no Accessibility Point of Contact

12. Non-Conformance to Technical Standards (WCAG)

13. The company makes no public disclosures of existing/ past efforts in accessibility

The veracity of these statements not withstanding, this is a great list to use in making a roadmap for an Accessibility Program. In fact, I touched on many of these points on my personal blog 5 years ago.

You can think of Dinin’s 13 claims as being “What to do to avoid being sued”. It is no mistake that the first thing on that list is functional performance. Clearly the best way to prevent being sued is to avoid issues in the first place. It sounds almost too obvious to mention: fixing your accessibility issues now is far better than waiting until lawyers come by. 

The first thing in the list is functional performance, while the last is technical conformance to WCAG. I don’t think this is a mistake. While many people seek to be “compliant”, they miss the overall point: While it is true that WCAG compliance will, by its very nature, lead to a more usable system for users with disabilities, it remains true that the real measure of accessibility is whether or not a user can actually accomplish what they came to accomplish. In short, focusing solely on “compliance” is a poor strategy. Conforming to WCAG is a means to a goal, but not the goal itself.

No system is perfect and I don’t think it is reasonable to expect perfection. However, there are steps that one can take to help users who have problems on your site. Two of the items in Dinin’s list are aimed at facilitating this by providing contextual help and by providing a specialized customer assistance line for customers having problems with the site. On this latter point I don’t really agree. I think that all customer service persons should be trained to help customers with disabilities, but barring that, a special customer assistance line would surely help.

The rest of the items in Dinin’s list can be considered core requirements, at an organization level, for a mature accessibility program.

• Having an accessibility point of contact for customers
• Having an Accessibility Notice on the site, describing the state of accessibility support, possible workarounds, and how to contact the organization with accessibility concerns
• Having an internal accessibility policy
• Making public disclosures of existing/ past efforts in accessibility

An internal group charged with ensuring accessibility would create the above items. Dinin calls it a “Web Accessibility Committee” and also calls for a “Web Accessibility Coordinator”. Whether that’s what you call it or not, the point is that there should – in Dinin’s view – be a group within the organization responsible for accessibility.

While the above seems sensible, we believe it is inadvisable to make accessibility the responsibility of a sole group within the organization. In his PhD Thesis, titled “Responding to accessibility issues in business”, Chris Law highlights this approach as one of the factors that prevent an organization from truly succeeding with accessibility. Placing accessibility in the hands of a small, dedicated group doesn’t scale and means that a massive amount of work, which should be distributed across the rest of the organization, is placed on the shoulders of only a few people. This also sets up a situation where everyone else can say, “that’s not my job”. Instead, accessibility should be seen as everyone’s job.

Facilitating this approach is exactly why Tenon exists. Instead of providing a tool that is only used by a small group of people responsible for accessibility, the best approach is to have a tool that can be used by everyone involved in design, development, testing, and content management of a site. This allows the responsibility – and workload – for accessibility to be shared. Finally, this approach is also the most cost effective.

Regardless of the details, the most important thing to take away from these lawsuits is that the plaintiffs will expect far more than just monetary damages. Being proactive now by setting up a robust program is your best approach.