Overlays are automated, third-party, temporary and permanent solutions to fixing accessibility issues that a website or app may present. They come in the form of plugins, widgets, apps or some sort of toolbar with an icon, usually located in the bottom corner of a website. They offer features such as reading the website aloud to the user, changing color contrast and font size, zoom and many more.
The problem with these overlays is that they do not factor in the subjective aspect of manual accessibility testing and therefore may miss larger needs that users have. They also don’t fix the underlying source code. Assistive technology uses source code to navigate websites. If users with disabilities rely on technology and manual techniques to navigate a website, it definitely doesn’t make sense to only use automated “solutions” to address all possible accessibility violations a website may present.
These “band-aids” don’t meet ADA and WCAG standards and can cause more problems. Here’s why:
Mobile accessibility is not supported
Blind users depend on mobile devices today more than ever. WCAG rules require websites to address mobile accessibility. Overlays are not mobile-friendly and therefore neglect a very large percentage of website users with accessible needs.
An example of a mobile accessibility requirement that automated overlays cannot address is positioning important page elements before the page scroll. This is key for mobile users because the screen is much smaller and therefore less content is displayed than on desktop. Proper mobile accessibility requires thoughtful implementation by content editors and web designers; it’s not something a code overlay can address.
Assistive technology is overridden
The very technology that users with disabilities leverage to navigate websites and apps is overridden by overlays. Oftentimes, overlays can’t even be found by screen readers, assistive technologies or keyboard-only users. Typically, users have spent time and sometimes money learning and customizing these assistive technologies for their specific needs, and rely on them every day.
It does not benefit users to override technology that they’re most comfortable with, forcing them to use something they are not familiar with that does not meet their needs. If users with accessibility needs don’t find overlays helpful, who does?
Automated checks and third-party code “solutions” don’t address manual needs
Manual WCAG accessibility requirements can’t be addressed by automated code overlays. Things like image alt text, missing field labels, keyboard functionality, error handling and so much more cannot and should not be an automated fix.
For example, just because image alt text exists for an image, doesn’t mean it is detailed enough to make sense to a screen reader user. That is something only a human with knowledge of the purpose of the image can determine and create.
Page load and site performance is affected
Overlays add scripts such as Javascript or third-party scripts to websites which in turn cause slow page loading speeds. This causes poor user experience, and since Google uses website performance to rank search results, it can also negatively affect SEO. If a website is slowed down by overlay code, it can diminish performance for all users.
You can still be sued
There have been thousands of lawsuits filed against companies using these overlays on their websites. So-called “accessibility saviors” have gotten several companies sued because they promised a “one line of code solution” that only fixed a handful of issues or actually made websites more inaccessible.
If it sounds too good to be true, it probably is. Accessibility fixes can be expensive, but why take the chance of being sued for thousands or millions of dollars? In the end, brands still need to properly invest in getting accessibility issues resolved correctly.
The underlying code is still inaccessible
Using an overlay does not automatically make code accessible, and deprives website designers and developers from the opportunity to fix these issues and learn from them in order to achieve and maintain long-term accessibility standards. The best way to provide an accessible web experience is to consider and plan for it throughout the lifecycle of website design and development, not slap on a quick solution after the fact.
Accessibility standards cannot be achieved without significant thought and effort. There’s no way around it. Automated and manual testing is necessary to ensure the needs of users with disabilities are met.
Accessibility should be monitored throughout the lifetime of a website. That means during planning, design, development, content entry and maintenance. Existing sites with accessibility violations should use proper automated and manual audits and remediation of the legacy code with verification that violations have been corrected. Users with accessibility needs deserve the same genuine website experience as those users without.