This is going to be an unusual blog because most of it will be in a footnote of sorts. The legal part of the blog is easy. If your business wants to avoid getting sued under the ADA because of an inaccessible website an accessibility overlay or widget isn’t going to help you. I can say this with some certainty because in the last two weeks alone five lawsuits have been filed against businesses that use an accessibility widget or overlay on their websites.* I also know why this is the case. The law firms who file website accessibility lawsuits and their pet clients start the process of finding a target using automated tools that scan for compliance with the technical requirements of the Web Content Accessibility Guidelines 2.0 or 2.1. I have used those tools on websites using an overlay or widget and they almost always flag errors of some kind. There is a lot a dispute about the effectiveness of these scanning tools, but effective or not getting flagged by one of them is an invitation to a lawsuit. If a widget doesn’t fix the errors plaintiff’s lawyers can find using automated tools it won’t prevent a lawsuit. The conclusion is simple. If avoiding litigation is your goal an overlay or widget won’t do the trick.
Now for the footnote, which looks a little more deeply into why widgets and overlays have these limitations.** Almost all lawsuits brought against websites under the ADA are brought by blind individuals using screen reader technology. The name “screen reader” comes from the old days when websites were almost all text that was displayed on a computer screen. The screen reader read that text. Today the name is out of date because most of what makes up a website is not text, but rather computer code that tells a web browser what to display where, what menus exist and what triggers their display, what pop-up boxes exist and when they are and how you get out of them and similar matters. This blog site probably looks like it is heavily text oriented, but it takes almost 10,000 lines of code to describe the page, and many of those 10,000 lines include references to other resources that may take thousands of lines of code.
Because websites are more sophisticated most of what a screen reader does is not read text, but recognize commands and links and other structural items and tell the user what to do with those links and commands. A sighted person sees a menu item. A screen reader user hears, or should hear, that a menu item is present and what it is for.† A sighted person sees a picture, a screen reader user should hear a description of the picture.
Of course for every kind of command, link, or picture there is the possibility that the code which is hidden from sighted persons will not tell the screen reader what it does. For example, my last blog had a picture of a bust of Caesar. The command that tells a browser to display that picture looks like this:
<img class=”alignleft wp-image-5358″ src=”http://accessdefense.com/wp-content/uploads/2020/03/caesar-bust-150×150.jpg” alt=”bust of Julius Caesar” width=”150″ height=”271″ srcset=”http://accessdefense.com/wp-content/uploads/2020/03/caesar-bust-166×300.jpg 166w, http://accessdefense.com/wp-content/uploads/2020/03/caesar-bust.jpg 220w” sizes=”(max-width: 150px) 100vw, 150px”/>
A screen reader would recognize the text that I have put in bold red type as a description of the picture. It would tell a user both that there was a picture and that it was a picture of a bust of Caesar. Where did that description come from? It came from me and it was tied to the rest of the blog and its title. If I hadn’t put it in a blind user would never know what the picture was.
A really good overlay or widget may recognize picture display commands that don’t include a description of the picture and use artificial intelligence to figure out what it is a picture of. But there are limits. When I used a typical AI program for picture recognition it identified the bust of Caesar as a “person looking at the camera.” That’s pretty clever, but not the same thing as a bust of Caesar, especially since the whole point of the picture is that it goes with the title “Great Caesar’s Ghost” and the fact the blog was on the Ides of March, the day Caesar was assassinated. An accessible website has descriptions of pictures that explain their purpose, and AI just isn’t up to that task yet.
This is the least of the problems widgets can’t solve. Far more difficult are fundamental problems with the structure of a web page that make navigation without a mouse difficult or impossible. For that and many other reasons every consultant I’ve ever talked to agrees that no widget or overlay can make a website accessible. Some of the widget and overlay makers seem to admit this themselves. One, for example, one widget maker claims on one page of its website that its widget will ensure a digital experience meeting strict governmental regulations‡ but on another page offers audit and remediation services. If the widget really did its job you wouldn’t ever need those services. Then there is the evidence of the five new lawsuits that prompted me to write this blog. The lawyers who file website lawsuits will often file based on the most trivial problems with accessibility, but they don’t generally file when there are no problems at all.
What role do widgets or overlays play? For a business concerned with accessibility they are certainly the easiest and least expensive first step. At the same time there is evidence they can create new problems because of conflicts with screen reader technology. At the end of the day website accessibility for disabled users can only be tested by disabled users carefully trying to navigate all the features of the website to see if they can do so, and website accessibility can be perfected only by individuals fixing the problems found by testers. I’m too cautious to predict that software will never replace people, but when it comes to website accessibility that day is somewhere in the future.
* Thanks to Jason Taylor of UsableNet for this information. UsableNet is a website accessibility consulting and remediation firm with whom I’ve worked in the past. Jason’s blog on this subject can be found at 3-reasons-why-accessibility-overlays-fall-short. The cases, for those who are interested are:
Fredericka Nellon v. Agri Beef Co., Case 1:20-cv-10595-RGS in the United States District Court for Massachusetts.
Ariza v. Carmen Sol FL, LLC, Case 1:20-cv-21262-KMW in the United States District Court for the Southern District of Florida.
Walters v. Venum Training World, Inc., Case 6:20-cv-00324 in the United States District Court for the Northern District of New York.
Williams v. VaporDNA, Case 1:20-cv-02294-JGK in the United States District Court for the Southern District of New York
Cruz v. Rockwell Time, Inc., Case 1:20-cv-01902-LJL in the United States District Court for the Southern District of New York
** Here are a couple of blogs with additional information on overlays from experts whose views are typical of the consultants I have talked to. Overlays are not the solution to your accessibility problem. Overlays and Plugins Aren’t the Answer to Accessibility
Another consultant has posted a video demonstrating some of the shortcomings of overlays at “https://www.youtube.com/watch?v=ICAu6vDemnw&feature=youtu.be”
† See Screen Reader demo for a demonstration of a screen reader in action.
‡ The federal government regulations concerning website accessibility in the U.S. are consistent with the private industry standard WCAG. 2.0.