Originally written on July 18, 2019. Content was updated in September 2023.
In the last couple of years a range of new vendors have started promoting solutions that claim to provide a silver bullet to web accessibility challenges. They are almost all implemented as buttons or overlays that claim to bring the site into conformance with WCAG 2.0 or 2.1 AA. The truth is they fail in four fundamental areas.
There are many new vendors offering similar overlay solutions because they are technically easy-to-do and cheap-to-provide but they fail to deliver true web accessibility to all. They are feeding off the surge of ADA-based Web accessibility lawsuits that many companies searching for quick solutions to the very complex issue of accessibility.
The truth is that for companies with existing complex websites, retail, restaurants, travel, banking and healthcare, web accessibility is hard work. These solutions fail in three fundamental areas which I dive into below. If you did not include accessibility at the start of a website build and want a solution that is usable by all and fully conforms to WCAG, someone will have to do the hard work of updating all your code (HTML, JavaScript and CSS) and design.
I want to be clear that these vendors do some of the work. But what they fix is easy stuff to spot and the easy stuff to fix (and maybe your own team should be doing it anyway). After these fixes, they promise that their overlay technology can address and fix the rest of the accessibility issues.
Overlay-based solutions can work for simple, informational websites. But for businesses with visitor interactions like pop-ups for product size and color selection, pop-ups to selecting seats or rooms; calendars for delivery dates or times, account management, etc; these solutions cannot deliver accessibility for all users.
Below I have highlighted the three biggest flaws in these solutions for modern websites. I also want to explain what they do and how they do it, so you can compare approaches.
Here is how they generally work: you add a line of code to your website that calls the vendors' server to load a set of fixes they have prepared. It also includes an icon on your page which opens an overlay (typically they will use a little blue man which is the symbol for accessibility). The fixes loaded are only for attributes and tags on elements. This means they do not address the design of the page or the functionality. The visual display of the web page does not change.
Element attributes such as alt tags, labels, header etc. are important for accessibility. They are also the items that most automated accessibility testing tools, such as WAVE will find. This makes it easy for an overlay vendor to quickly demonstrate with automated tools that some of the accessibility issues have been resolved.
Sounds good so far, right? There is a catch. The fixes added in this process represent only 20% of the accessibility areas that need to be reviewed and fixed.
Updating attributes cannot address more significant barriers. Some vendors may claim, "but we can use ARIA tags to fix complex interactions". That can only be true if that interaction was built with ARIA in mind. However, most existing scripting on sites did not consider accessibility when coded and how ARIA could be used. Practically speaking, those interactions need to be re-coded. That's the hard stuff.
How do overlay vendors solve for the 80% of accessibility challenges they can’t fix by updating attributes? By pointing to their overlay technology to solve these bigger issues. They will have cool sounding features such as; text-to-speech, texted based navigation, color contrast tools, and text resizing, that look great in a demo and seem to add value. So, what is the problem? In reality, these features offer little or no value to current assistive technology users because. . .
This is the biggest weakness. People with disabilities who require assistive technology to use and navigate websites already have preferred assistive technology that they use every day. They have invested their time to learn how to use it and are likely most comfortable using their own devices to navigate the web. Their devices are set up to do the things they need such as, text-to-speech, zoom, color contrast, etc. An overlay attempts to replace the functionality of these devices.
To use the "text-to-speech" feature in an overlay, the person requiring the assistive technology must turn off their own, preferred screen-reader and rely solely on the overlay.
Joe DiNero who heads the UsableNet's User Testing group is a long-time screen reader user and a teacher at the Helen Keller Institute in New York. He explains,
"Using the overlay screen reader instead of my regular screen reader locks me into a small set of features such as arrow, tab and maybe heading navigation. When I use my screen reader on a regular site that has been properly coded or fixed for accessibility, I can access any form control on the screen (buttons, edit fields, aria controls, etc.) and I have the ability to pull up a list of links on the page. Moving to the overlay removes all powerful and useful features from me."
So, if an overlay-solution promises to fix 80% of the accessibility items that could not be fixed when the vendor updated attributes, then this value is likely lost for the average screen-reader user, the same customer you are trying to serve with your accessibility updates.
All major accessibility laws and policies around the world, as well as past DOJ settlements, ADA lawsuits and resulting settlements reference the WCAG 2.0 AA as the prevailing minimal standard. That could extend to the new WCAG 2.1 soon, but will take time for laws and policies to catch up.
The WCAG is clear on conformance. Every page’s code of a web site has to pass a set of Success Criteria. There are 37 in WCAG 2.0 AA and WCAG 2.1 adds even more.
The WCAG does not reference accessibility overlays as a means of conforming because the only true way a person using a screen reader or other assistive technology can have full and equal access to your website is by providing them an experience where the design and code has been developed to WCAG standards. This ensures that they can continue to use their chosen technology.
The final item and really a huge blow to blind or other users that rely on mobile devices now more than desktop is the lack of support for mobile wed.
The mobile device is now the most important device in a blind users life, using it for all aspects of digital connection. When web sites use overlays they remove any benefit they may have for the most important channel in digital today.
The ADA does not define a standard for website accessibility, which is one of the main reasons there are so many lawsuits. Some companies may hope that adding an overlay is enough to avoid a lawsuit. But it may not be, and more importantly is it enough for you to not offer a fully inclusive digital experience?”
If you want to ensure access to all and avoid lawsuits, you need to ensure all your code is updated to WCAG standards.
You can do that hard work yourself and UsableNet has technology and services to support your efforts. If you prefer, UsableNet can do all the work for you through dynamic remediation and UsableNet Assistive. UsableNet Assistive is the only solution that can handle the hard fixes (80% of issues) as well as the easy, automated ones, in order to provide a fully compliant WCAG solution. UsableNet Assistive and our team continuously monitor and remediate any new content or code you introduce as part of your regular website update and improvements.
There are no shortcuts to making and keeping your website and apps accessible, but UsableNet experts are here to help. If you're ready, contact us we offer a free, 30 minute consultation to get you started—or read our free web and app accessibility guide to start building your own roadmap.