Even custom overlays have questionable value
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.
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.
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.