A friend of mine recently asked me about my opinion on “Custom” overlay products such as Deque’s Amaze or Alchemy by Level Access. Those are products that use JavaScript to make targeted fixes on a customer’s website. Those products do not offer the widgeted pseudo-assistive technology that you’d see in something like EqualWeb or AccessiBe. Below is a lightly-edited version of my response:
The cool thing about solutions like these is that they’re completely custom, for the most part. Basically, the underlying technology for something like this is that it is really just a library of JavaScript that makes it easier to apply repairs to the customer’s site. In that regard, there’s nothing amazing about it. The provider’s developers assess the customer’s site and write some custom code that uses the library to fix the customer’s problems. This is far better than the products one typically thinks of when discussing “overlays”.
The use of JavaScript to fix accessibility problems on websites isn’t something unique to these products. Lots of people have been doing it for years. In fact, it is a tactic I employ on the Mother Effing Tool Confuser. The purpose for that site is to demonstrate that automated tools must test the final browser DOM, but the way I accomplish that is by taking inaccessible code and fixing it with JavaScript.
So in principle, at least, fixing problems using JavaScript is a great approach so long as the customer understands that it needs to be temporary.
Consider the following scenario: You get a nasty demand letter from someone threatening to sue you because your site is inaccessible. So you run to someone who markets a custom overlay, have them do the work to fix stuff, and hope you can get the aggrieved party to go away or hope that the judge will toss the case because it is now moot. Awesome.
I will concede that this is (should be) a very quick solution to the problem. There are two major problems with this approach: 1) Maintenance of the site makes the overlay brittle 2) If a site uses React/ Angular/ Vue, etc. all bets are off.
The first situation is the easiest to describe: If customer maintains their site, they may wind up doing inadvertent damage to the repairs. For instance, the JavaScript selector to act upon the button on the top-right of the Tenon homepage is: document.querySelector("#___gatsby > div > header > div > div > div > div > a") (note: this selector could probably be made much simpler, but I’m using this as an example to show how brittle things could be)
Using that selector, I can now make changes to that button. What if I change where that’s located in the code by removing one of those div elements? What if I change the tag from an a to a span? Any repair tied to it is now broken. In other words, I’ve traded my long-term quality for short-term pain mitigation by buying the overlay.
This is only one example. According to statistics on GitHub, there have been 1,455 additions and 472 deletions to code on Tenon.io’s front-end UI in the last month.
These custom overlays, by the way, aren’t cheap! Customers would be well-served to do extensive research into the actual cost to implement the overlay vs. the cost to fix the site correctly. There’s a lot to consider here, especially when it comes to the urgency aspect. The custom overlay is likely to be much quicker to implement, which certainly has value. At the same time, the cost to finally repair the site directly should be understood as essentially being the cost of both rounds of repair: The custom overlay plus the final repairs.
The second situation I mentioned is more difficult to describe. That is what happens when a customer’s site uses ReactJS, Angular, Vue, Polymer, or any front-end JavaScript framework that operates as components.
In a component-based architecture, one of the most powerful features is that each component fully encapsulates all of its appearance and behavior. For instance, on the Tenon.io homepage, the form that you use to do the free check is a component called “Test Now”. The file that constructs that feature is literally “testNow.jsx” and literally everythingabout that component is in that file including its appearance and behavior.
Because these components are fully encapsulated, an overlay cannot touch it. The after-the-fact fixes from the custom overlay might be able to fix the initial state of the component, but it cannot do anything when it comes to any of the other appearance or functionality that the component might do as a user interacts with it. As the user clicks around the component and uses it, the custom overlay would need to be able to have the ability to recognize and react to all of those behaviors and state changes. It is a near impossible task that is like running through a minefield with size 13 boots while drunk. Some minor success might be found but ultimately it is impossible. Fixing that component’s issues directly would be far more fruitful in both the short and long term than trying to do it with a custom overlay.
Adding a custom overlay to your site make sense only if it can be implemented quickly, cheaply, and with an understanding that it is a temporary measure to be put into place while the permanent fixes are put into place. Customers should carefully research these solutions carefully and weigh their options. Ultimately, the end goal should always be permanent and lasting improvement of the site, and in my opinion, Rapid Discovery & Remediation is just as likely to result in permanent improvements and risk mitigation just as quickly as a temporary fix.