Recently an article has been making the rounds: Should Accessibility Overlay Tools Be Used as a Strategic Part of your Accessibility Efforts. Some have asked me what my thoughts are on this topic and I feel compelled to share a few comments, because the article discusses a handful of emerging approaches. I’ve already shared my opinions on products like eSSENTIAL Accessibility and UsableNet. But “overlays” are a bit different.
Exactly what “Overlays” are at this point remain somewhat poorly defined. For instance, Debra’s article discusses a handful of products that are different from each other in important fundamental ways. Because I’ve already discussed all of those embedded assistive technologies like eSSENTIAL and ReadSpeaker, I’ll leave those out of the discussion and instead function on JavaScript-based products aimed at dynamically repairing websites’ accessibility issues.
The idea of being able to automagically fix accessibility issues without interfering with existing code is pretty compelling. In a situation where the accessibility issues are egregious and the organization is under considerable outside pressure (i.e. a visit by the DOJ or legal complaint) then something like an overlay can offer a quick fix.
It is important to keep in mind that an overlay is really just applying JavaScript to the current UI to fix the existing accessibility issues. In other words, any skilled JavaScript developer with good accessibility knowledge can do the same thing, without the need to pay for a third-party service. In fact, the Mother Effing Tool Confuser is an example of doing exactly that. Chances are, the overlay is backed by a good library of built-in utility functions but fundamentally what you’re dealing with is still just JavaScript. As a consequence, any inordinately high price for the product is probably unwarranted.
It is important that any overlay needs to be regarded as temporary, for one important reason: if the underlying UI code changes it will break the “fix”. Again, I suspect that the overlays have been developed to do the best they can to anticipate such a thing, but it seems scary to think that the more substantially you change the existing UI, the more likely that the “fix” will break. To my knowledge Simply Accessible does a lot of this type of custom overlay work and they’re at least ethical enough to state clearly to their customers that it is meant to be temporary.
Ultimately you must keep in mind that this fixes the symptom without treating the disease. In many cases this comes down to a business decision. Time spent fixing bugs costs money and also impacts the availability of resources that could otherwise be put onto other work. External pressures, such as deadlines for other projects or legally mandated deadlines may make something like this a good option. But the existing inaccessible interface code that this “fixes” will still be there. Worse still, the development practices and other libraries/ frameworks, etc. that caused the problem will still be there. So no matter what you choose regarding using an overlay, you should also come up with a plan to actually remediate the underlying issues and train your developers in accessibility so that they don’t continue creating the same type of inaccessible code that caused the problem(s) in the first place.
As I’ve said in other posts: The code is where accessibility happens and so long as companies’ budgets are being diverted to ineffective products, these budget dollars are not being used on things that matter.