At a basic level, the core question we get about overlays and widgets is, roughly, will they actually make a web site compliant. Our decided view is no, and I’ll run you through the core logic on that in the next few posts.
A big reason for that is the difference between theory and practice. In theory this class of technology—specifically overlays—could be used to provide accessibility and meet ADA compliance. The issue is that in practice, 99% of the time it doesn’t. That gap is made significantly worse by the unqualified, wildly broad, and I’d go so far as to say irresponsible claims of many of the vendors in the space. With that in mind, let’s take a look at the requirements to better understand why that is the case.
Since the question here is ADA compliance, in the next few posts we’ll look at three key concepts under the ADA and show where these solutions are deficient:
- Do overlays or widgets provide full and equal access as required under the General Rule (42 U.S.C. § 12182 (a)) of the ADA?
- Should overlays and widgets be viewed as “separate but equal” solutions that violate the Separate Benefit (Ibid. (1)(A)(iii)) prohibition and related requirement for Integrated Settings (Ibid. (1)(B))?
- How does an overlay or widget do if we think of it as an auxiliary aid or service? Would it meet the definition of effective communication (28 CFR § 36.303 (c)(1)(ii))?
The General Rule
At the absolute highest level, pretty much the top of Title III of the ADA, is the General Rule (42 U.S.C. § 12182 (a)). It’s pretty simple:
“No individual shall be discriminated against on the basis of disability in the full and equal enjoyment of the goods, services, facilities, privileges, advantages, or accommodations of any place of public accommodation by any person who owns, leases (or leases to), or operates a place of public accommodation.”
At the absolute simplest level: that’s it. That’s the requirement. That’s what we need to be able to show. Slightly rephrasing, you can’t prevent people with disabilities from enjoying full and equal use of the stuff that you do or provide at the place of public accommodation. It’s also worth noting that this requirement is basically passed directly through to the regulation with essentially no modification or expansion (28 CFR § 36.201 (a)).
It’s open to discussion what the heck that actually means. The Preamble to the original Title III Regulations released by the Department of Justice includes a Section-by-Section Analysis (“1991 Preamble“). This includes this expansion of the definition which I found useful:
“Full and equal enjoyment means the right to participate and to have an equal opportunity to obtain the same results as others to the extent possible with such accommodations as may be required by the Act and these regulations. It does not mean that an individual with a disability must achieve an identical result or level of achievement as persons without a disability. For example, an exercise class cannot exclude a person who uses a wheelchair because he or she cannot do all of the exercises and derive the same result from the class as persons without a disability.”
Drastically simplifying our test for this part: is the access full and equal?
How do we do on the ‘full’ part?
As noted in my previous post—Lies, Damned Lies, Overlays and Widgets—overlay and widget technology broadly works on heuristic or “rules-based” engines or limited AI that apply fixes into the page directly. Think of the average overlay as a bunch of if/then rules. If you see this on a page do this. If you see this other thing do this other thing. You can write some pretty savvy rules there but, end of the day, it’s just a bunch of rules. That makes these solutions brittle in that they can pretty much only fix narrow problems they have seen in the past. They can’t fix new and novel problems they haven’t seen before.
Modern websites are dynamic, complex pages with variations for different screen sizes and often contain multiple states. Addressing accessibility dynamically for all of these across mobile devices and browsers with a bolt-on solution does not provide effective results.
The big limitation is simply that there are a lot of problems in digital accessibility that can’t be fixed using a rules-based approach. The problems require human judgement about a feature, the context of the feature, or the implementation of an approach. Here’s a few really easy examples of things that you simply can’t write rules for:
- We have an image on the page that is decorative and should be ignored
- We need to ensure that the keyboard order of this form makes logical sense to a person filling it out
- We need to ensure that the error states of this form are clear and can be recovered from
- We need to ensure that the heading structure of the site, as a whole, makes sense
- We need to ensure that the link text makes sense
- We need to ensure that the frames and inline frames make sense and are readily navigable
- We have a piece of text that should have some structural markup (like a header) this needs to be converted and placed in the proper order
And so on. The issue is that the list of these issues is significantly longer than the set of issues that the machines can actually detect and fix. So, the majority of issues can’t be fixed with rules-based approaches—they require a human to be involved and remediate the code. You can do some of these fixes in the overlay layer but then they only exist at that layer. If you switch out this overlay for another, you’ll lose all the fixes. If the underlying code updates—because you upgrade the site, a third-party library changes or any of the other thousand ways sites change—you will break the configured fixes. So, you end up having to maintain a lot of fixes manually, you just do it in an overlay versus directly in the site.
- “the compliance of files type as: FLEX, FLASH, Silverlight, Applets, PDF, Microsoft Office, media players, the creation of film or audio captions, and the support for tags which do not reveal the source of the file, such as: <canvas>, dynamically loaded SVG or in CAPTCHA files”
- “<Frameset> tags”
- “components which can be functionally understood only by virtue of their content which is based on location, size, or color”
- “accessibility of texts, pictures, attached PPT, EXCEL, WORD, PDF, audio, video, VIMEO, or YouTube files, nor files of any other video provider”
And so on. So, it’s not just us saying, “these don’t fix the problem.” The vendors, themselves, are at pains to say, “we don’t fix the problem.”
How about the ‘equal’ part?
As part of writing this I got a few questions in the vein of, “Well do they positively impact the user experience? If they are good for users should we still use them in a limited fashion?” Steve Faulkner has done a far better analysis of this than I could ever do so I’ll just point you to his blog post on the topic. The summary conclusion from that is, upon deploying an overlay you can often make the user experience worse for people with disabilities. The thing that purports to make the user experience better does the exact opposite.
At first review, widgets might sound like a good idea. They provide a method for users that may not be familiar with assistive technology to access a set of alternative solutions. The issue we have with them is that the virtually all of these features are either (i) directly accessible in the operating system or browser or (ii) the assistive technology that the user already has installed. The standard best practice in accessibility is to ensure support for the underlying operating system or browser accessibility enhancements.
A common use example of this would be the zoom feature in a browser. Modern browsers all provide zoom functions that allow content to be expanded for view natively via the browser. Ensuring that this view functionality works would align with the intent and spirit of accessibility standards and how the vast majority of users that need that accessibility feature would use it. A widget approach doesn’t do that. Instead it provides a proprietary solution that is specific to the combination of the site itself, the user interface the widget provider has and the heuristic the rule provider has written up for that website.
The first issue is that such a proprietary approach means the user has to learn an entirely new approach to magnify the text on this particular site. The second issue is that the user has to identify themselves to the site and widget provider as needing that magnified approach. The third issue is that the solution is brittle and breaks easily—it doesn’t work as robustly as the browser native function.
In the more specific case of people that are using assistive technology—either operating system provided or add-on—the widget provides secondary or “add-on” assistive technology. This puts the burden on the user to both shut down their current assistive technology and use a separate, AT specific to the site and widget provider. Learning an entirely new assistive technology for each widget is much, much harder than using their own configured assistive technology. In turn that puts more rather than less burden on people with disabilities to use the site.
The irony is that some functions in widgets could be good for people who just acquired disabilities. They’re not in and of themselves bad and in many cases could have a positive impact on people with disabilities. As an example, some features like a contrast switcher or tool to increase font size are cited by WCAG as acceptable solutions. The problem is they aren’t integrated into the overall engineering of the site or tested for use by people with disabilities. They are quickly added on and left to run.
Lest you think this is just our view—we should be clear—this is also the view of plaintiffs. Here’s a quick excerpt from a recent lawsuit in the space:
“Although Defendant’s Website contains an accessibility widget, there are still many errors present. This widget requires disabled users to activate and learn how to use the widget by going to a third-party website to access the FAQs, dictionary, and user guide. This takes a lot of time and effort to give up the tools the users are accustomed to, and have customized over the years, in order to learn a new tool.”
So, it’s not just a matter of inconvenience—it’s actually cited as a barrier to access and a point supporting the claim of inaccessibility in a live lawsuit.
Content originally posted on Linkedin.