One of the big arguments or justifications for using overlay solutions is that they can be a band-aid or temporary solution for digital accessibility. Typically, the justification goes something like this:
- The current site is inaccessible.
- Fixing that site directly would require expensive retrofitting. That’s unappealing.
- Instead, we’ll use an overlay, patch the production site, and then fix the issues when we redesign the site.
- That will keep us from doing an expensive retrofitting project on something we’re going to replace in a little bit anyway.
So, the idea is we’ll use the overlay for some short, finite amount of time to patch the current site. We’ll then ensure that accessibility is fully implemented when we do a major redesign of the site in a year or two. This post is about whether that approach is okay.
It’s not. In theory, that approach can technically work. In practice, it does not.
Why? A variety of reasons:
- The overlay doesn’t fix all the issues
- The issues don’t stay fixed
- During the time patch is in place the site is actively deploying a separate but equal approach for accessibility
In Theory That Approach Can Technically Work
What can get lost here is that in narrow circumstances overlay technology can work effectively to address a limited set of accessibility issues. On the set of issues it does work on, it works just fine if set up and configured properly. Credible vendors will qualify the solutions accordingly and deploy more substantive fixes when needed. So, as part of an overall solution overlays can actually work fairly well and do provide a cost-effective and scalable solution for a subset of accessibility issues. That’s not the problem.
In Practice It Doesn’t
The problem is, in practice the widget and overlay solutions are neither sold nor used as band-aids or temporary fixes. They are sold and used as panaceas, as cure-alls for accessibility. That’s the issue. They aren’t, in practice, used as temporary fixes for a limited set of issues. They are sold and used as permanent fixes for all accessibility issues. As such, they tend to perpetuate rather than eliminate discrimination.
In line with that, here are the three reasons they don’t work in practice:
- The overlay doesn’t fix all accessibility issues. Therefore, they fail to provide full and equal access. I discussed these constraints in my post on full and equal access. The summary version, noted above, is that overlays only fix a small subset of accessibility issues. And within that subset, they don’t always fix issues in an effective fashion (one that provides equal access). So, they fail to provide both full and equal access.
- The issues don’t stay fixed. The technology broadly works on heuristic or “rules-based” engines 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 at the 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 based on what they have seen in the past. They can’t fix new and novel problems they haven’t seen before.
- During the time the overlay (patch) is in place, things haven’t been fixed natively and the site is actively deploying a separate but equal approach for ADA compliance. A critical goal of the ADA is to ensure the integration of people with disabilities into society. To the fullest extent possible, the support for the equal access needs for people with disabilities is meant to be provided as part of the core experience of a website. It is not meant to be provided as a separate, add-on program. In fact, providing it as a separate program is defined as discrimination under the ADA. That’s the core concept of “separate but equal” that the framers of the ADA were at pains to ensure was barred as a route for providing “accessible” solutions unless necessary to provide that accessibility.
That’s the critical point here with overlays, widgets, and other add-on solutions to websites, apart from their technical shortcomings. They fundamentally are separate from, and not integrated with, the experience of the site. They provide a separate and unequal experience for people with disabilities. They do not provide an integrated, accessible experience. An integrated, accessible experience is provided by making the primary site and code base accessible, and that also happens to be a key and fundamental requirement of the ADA.
They Rarely Are Temporary
Let’s put aside all the points above for a moment. “To hell with it, Springer, we’re going to use this overlay widget anyway! We’ve got a redesign starting in six months. We can wait until then.” Here’s what’s likely going to happen:
- The redesign will slip from six to twelve months
- The redesign scope will narrow and not include the entire site
- When the redesign is actually executed, testing for accessibility won’t occur
- The vendor leading the redesign will have warranted that they’ll make it accessible, but nobody will have tested that they actually did
- The final, redesigned site, might be a little better in terms of accessibility but it’s (i) late, and (ii) still not close to fully accessible
- You keep using the patch you applied before and aim to fix things more substantively the next time around
This is the pattern we have seen play out countless times. A well-intentioned organization aims to use an overlay as a temporary solution until a redesign. When the redesign finally happens—always later than expected—it doesn’t quite get accessibility right and the overlay continues to be used.
The issue is that during this entire time period the site experience—the thing that is subject to the ADA—isn’t accessible. Maybe it gets a little better, but, fundamentally, it has been made neither full nor equal. There is also now documented evidence of the organization failing to fix something and further evidence of their failure to change policies, practices and procedures in order to provide full and equal access.
Content originally posted on Linkedin.