Accessibility Lies, Damned Lies, Overlays and Widgets

Basic Definitions

There’s been a fair amount written about digital accessibility overlays and widgets, including some pretty extensive dissections of a few prominent vendors. In this series of posts, I’ll explain why these solutions are insufficient and examine their various shortcomings. But first, let’s start off with some basic definitions.

Accessibility Overlays are add-on solutions that inject accessibility fixes directly into a web page rather than updating the existing code. Typically, they are deployed directly into the site via JavaScript or as part of an alternative site that provides another means of accessing the underlying site’s content. The technology broadly works on heuristic or “rules based” engines that apply fixes into the page directly. For example, when you see an image that has this location, apply this alternative text to it. This heuristic-based approach makes these solutions only as good as the set of rules and associated fixes currently written for them. As the underlying content changes the coding of the rules typically needs to change to fix the issues of the site directly.

There are some claims of “AI” decision making in this process. There’s no real AI in these tools—just some integrations with commonly used web enabled services. Basically, “if you detect something on a page I don’t have a rule for look up an answer using the Internet.” The common—and honestly, pretty much only—example of this is alternative text for images. Amazon and Microsoft both run web services that provide text for images. So, if the overlays finds an image without alt text it calls up Amazon, asks it to look at the image, and inserts the stock text back from that as the alternative text. The effect of that is about like what you get from automated captions—not very good, and certainly not up to a legal standard of equivalence or the requirements of most accessibility standards.

Accessibility Widgets provide some sort of user facing menus that present accessibility options and settings for people as they visit your site. They typically provide some form of add-on accessibility features that duplicate features provided in assistive technology, in the browser, or as part of the operating systems directly. A common example is the ability to provide text “magnification” or zoom in on the page via an add-on function instead of the native browser zoom feature. A widget provides this as hover link or button on the page that typically resembles in color palette the international sign of accessibility. Once that button is active, a menu pops open allowing the user to select a magnification level in terms of percent. Upon selection of this magnification level the CSS of the page is updated to directly change the size of the text. This approach is intended to replicate the native browser zoom functionality.

In practice most solutions contain both a widget component and an overlay component with the combination deployed in a single group. So, you should assume that solutions don’t neatly fall into either the widget or overlay category exclusively. In practice, they tend to deploy functions of both in a single product.

The Bottom Line

There is no software solution—overlay or widget—that will automatically make a website compliant with the American’s with Disabilities Act (ADA) or similar accessibility laws or regulations. At best, vendors that claim the ability to automate ADA compliance are making misleading and poorly informed claims. At worst they are actively deceiving prospective buyers. I’d lean more towards the latter given the radical disparity between the headline claims of many vendors and the fine print of their terms and conditions.

Specific to the claim of ADA compliance, site overlays and accessibility widgets (i) provide neither full or equal access to people with disabilities and (ii) fail to meet the definition of “effective communication” as reasonably applied to a web site. A knowledgeable person with a basic level of due diligence can easily demonstrate these requirements have not been met by examining the site. This leads to the worst-case view of this technology: deploying them can be—and as we have seen in recent lawsuits, is—alleged as evidence for ongoing discrimination on the part of the deploying organization.

An Analogy

I’m well aware that’s a divisive point of view. Bear with me: I’ll explain in more detail over the course of the next few posts. If you don’t want to read all that, though, here’s a more intuitive analogy.

A small software company—ten or twenty employees—comes to you with the following claim: “We have a fully automated solution that will make you 100% compliant with all privacy requirements. For a few thousand bucks a year, and ten minutes of your time, we’ll take care of everything related to your privacy requirements.” Would you believe that vendor? Why not?

You would probably view that with a healthy dose of skepticism, as something that sounds too good to be true. If you have that basic doubt when it comes to privacy, why should digital accessibility—a subject matter domain space as deep as user privacy—be any different?

Digital accessibility is difficult. That’s inconvenient but true. Most people logically believe claims of 100% automation and cheap ADA compliance are too good to be true. That’s because they are.

Common Questions and Key Points

Here are some of the common questions we get at Level Access about this kind of technology and summary notes on our position. I’ll develop all of these in more depth over the next few posts.

Will deploying an overlay or widget allow a site to achieve ADA compliance?

No, for three key reasons:

  • They fail to meet the requirements of the General Rule (42 U.S.C. § 12182 (a)) to provide full and equal access to the covered portions of a web site.
  • They are fundamentally “separate but equal” solutions that violate the Separate Benefit (Ibid. (1)(A)(iii)) prohibition and related requirement for Integrated Settings (Ibid. (1)(B)).
  • If you take the view that the web site—combined with the widget or overlay—is an auxiliary aid or service, they fail the test for effective communication (28 CFR § 36.303 (c)(1)(ii))

We’ll use references here to Title III of the ADA and the related implementing regulations and technical manuals as that’s where many of these solutions claim to be targeted.

Is deploying an overlay or widget better than doing nothing?

No, and in our view, many times it’s worse. In deploying a widget or overlay as your solution for accessibility you are deploying something you should reasonably know does not provide full or equal access. In that failure you are, by definition, continuing to act in a discriminatory fashion. The point of the law is to remove discrimination – that’s what a valid solution here must do.

Think about it this way: would you ever say something like, “Well, ending discrimination is too hard. Let’s just discriminate a little less than we used to, and we’ll be good?” More likely, you’d ask, “How do we get a clear path to ending any discrimination and conforming to the law?”

Is it okay to use them as a temporary or band-aid solution while we really fix this?

In theory, sure and in some narrow cases this approach may have some value. What can get lost here is that chunks of this technology—notably overlays—can effectively address a lot of accessibility issues. We’re actually very familiar with implementation of overlays at Level Access and they work well in specific contexts. That’s not the problem. The problem is that in practice the widget and overlay solutions are neither sold as, nor used as, band-aids or temporary fixes. They are sold and used as panaceas – cure-alls for accessibility. That’s the real issue. They aren’t used as temporary and targeted fixes but as permanent solutions. As such, they tend to perpetuate rather than eliminate discrimination.

Will deploying an overlay or widget reduce the risk of a lawsuit?

No. In fact, it might increase it. Two big reasons for that:

  • Most plaintiff firms use accessibility scanning tools to look at the websites of potential defendants. Those scanning tools won’t reliably pick up the solutions provided by widgets and overlays. As such, your site will “scan” in exactly the same way with and without a widget. Some overlays may try to create mechanisms to pass automated testing tools to address this check, however, they still fail to address the fundamental functional issues impacting real users on the site.
  • The majority of lawsuits these days don’t actually cite issues of WCAG compliance. They cite issues of functional use – things that impact an individual’s ability to use a site. The widgets won’t impact that as the functionality and core paths of use are based on the underlying site itself.

Don’t take our word for it. Let us run you through recent lawsuits that cited websites that deployed widgets as continuing to be non-compliant. The fact those widgets were deployed – and they failed to provide access (see the first point)—was cited as evidence of ongoing discrimination. That gets you back to the point above—slapping a fix on this you reasonably should know doesn’t result in full and equal access can make things worse.

The overlay and widget makers say they’ll certify or indemnify me. Is that real?

No. Many of the widget vendors are presenting their solutions like an insurance policy. Verbally, and in the bold print on the website, they’re telling organizations they’ll cover all liability if they are ever sued. If you look at the terms and conditions and actual contracts, however, such liability is wholly and completely disclaimed and waived. The vendor is taking on zero actual legal or financial risk due to a lawsuit. The litigation and remediation cost—both website and procedures—are the core costs in these situations. Without explicit protection from those a certification or indemnification has little value.

Moreover, mechanically, it’s very difficult to “indemnify away” your ADA obligations. Most of the lawsuits in this space are seeking injunctive relief to force the defendant to change their business operations (policies, practices and procedures) to ensure compliance. Unless the website is fully maintained and operated by a third party—an exceptional and profoundly expensive situation—there is likely to be some requirements for the core entity that can’t be indemnified away.

If overlays and widgets don’t work, why are they getting deployed at all?

This one is actually straightforward: they are a cheap and easy to understand solution for an expensive and complicated problem. Digital accessibility is difficult—that’s a tough sell—and a solution that makes it cheap and easy is profoundly compelling. This is particularly an issue in the small business segment where the cost of digital accessibility can be significant relative to an entire website budget. In this space, websites are generally created by rapid visual design tools that generate content without allowing the user to modify the code. While this allows for quick and inexpensive website creation—the frameworks and templates are often inaccessible. It is far more appealing to believe I can fix this by deploying a line of code rather than by materially changing how I do business or change the platform my website was created on. Overlay solutions appear to address the issue without having to update any of my policies, practices, and procedures while obtaining the promise of access for people with disabilities.

Given that, lots of organizations do seem to shrug and say something like, “Let’s take the cheaper route and take our chances.” The problem with that approach is it accepts that ongoing discrimination is okay.

Content originally posted on Linkedin.

Accessibility Toolbar