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.
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 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.