Website accessibility overlays and plugins aren’t the answer to accessibility and compliance, despite being touted as an easy, automated solution for web designers and developers and their clients. They present a plethora of problems.
- Design Domination episode 53, Design With Accessibility in Mind
- Foundations of Website Accessibility course
- Karl Groves’ findings about sites with accessibility overlays
- 5 Mistakes Developers Make When Building Accessible Websites (free guide)
- Understanding and Selling Accessible Websites (free guide)
- Should I Use an Accessibility Overlay?
- Overlay terms of service
- Overlays are not the solution to your accessibility problem
- Website accessibility lawsuits with the use of overlays
- AccessiBe Will Get You Sued by Adrian Roselli
- Review: Does AccessiBe Overlay Make Your Website Accessible/ADA Compliant? by Kris Rivenburgh
If website accessibility is new to you, you can get an overview about it and find out why you should care, who it affects, how many it affects and additional information in episode 53, Design With Accessibility in Mind.
I wanted to do an episode about accessibility overlays and plugins because I feel it’s my duty, based on my accessibility background, to educate you on this topic. I have been in the accessibility space since 2016, designing and remediating (meaning “fixing”) accessible InDesign files that get published as PDFs, providing accessibility training at the U.S. Department of the Interior, designing and developing accessible websites, and, most recently, launching a website accessibility course.
The reason for bringing this up is because I see a lot of web designers and developers asking for help in Facebook groups after they’ve gotten a request from a client to make their website accessible, whether that’s to ADA laws in the United States, in which case the client usually refers to it as “ADA compliance,” or to Section 508 or another law. Those are just a couple U.S. laws, but accessibility is a worldwide effort.
The problem is that a lot of people respond to these posters in these groups with links to accessibility overlays or plugins that purport to be—or are perceived to be—quick fixes to accessibility.
But these are not the answer to achieving compliance, and I am going to get into why.
What Is an Accessibility Overlay
The site gets analyzed and—poof!—the site is now magically fully accessible and compliant within a day or two, and it performs regular checks and fixes to ensure ongoing compliance. Sounds great, right?
Claims Made by Accessibility Overlay Vendors
Many of the claims made by the vendors of these accessibility overlays sound way too good to be true. Let’s take a look at some of them:
- “Just insert this code, and your site will be accessible.”
- Scanning and fixing your site will be done every 24 hours (or other timeframe).
- Overlays have a higher success rate than accessibility services.
- They provide compliance to many laws, including ADA, Section 508, EN 301549 and WCAG 2.1 AA guidelines. I noticed some touting “100% compliance,” and others said “up to 50% compliance” for x price, then “up to 95% compliance” for higher rates. What if the site ends up being in 25% compliance? Sounds like it would still be what they are promising, so your client will get screwed.
And just a side note… Ironically, a lot of these overlay vendors have accessibility issues on their own sites that are using their own overlays!
Problems With Accessibility Overlays
Now, there are some things an automated tool can check for and fix. Industry experts estimate that about 25% to 30% of accessibility issues can be detected. Those are the more cut-and-dry issues. Some other issues may be able to be found but not fixed properly or at all.
About 70% to 75% need to be dealt with manually, reviewed by a person, not an automated tool.
So let’s get into some of the specific problems with accessibility overlays.
False Sense of Security
Overlays provide a false sense of security. I did some checking of several sites that use an accessibility overlay and found them to have a plethora of compliance issues.
Karl Groves of Tenon, the company who did the accessibility audit of WordPress Gutenberg, made a video talking about his testing of sites with accessibility overlays with his tool. I highly recommend watching it.
In looking at these vendors’ terms of service, I saw that one of them said that use of the product means the client waives any right to make a claim against them. On the home page, they tout “full compliance” but their terms say otherwise, and their pricing says otherwise because the pricing is saying “up to” whatever percentage of compliance.
Redundant or Separate Functionality
The overlay adds functionality to the site that should already inherently be there—either from using the proper code in the first place or from the operating system or the browser. The user may be required to use the overlay to get around the site instead of what they are used to using, which could be a keyboard or a screen reader.
When I was on a site with one vendor’s overlay, I couldn’t use the tab key to go through the page via the keyboard. I had to use the overlay’s keyboard functionality, which kept looping me in and out of that option.
This is frustrating and makes for a poor user experience because it changes the way someone is used to getting around a site. Not only that, it’s requiring them to take an additional step to do so.
It’s kind of like saying, “Hey, our website is best viewed in such-and-such browser, so switch.” But it’s worse than that.
Interestingly enough, after using the overlay keyboard navigation feature on the one vendor’s site, I was not able to go back and use the site properly! I wasn’t able to search for text on the page or to open developer tools, and that’s even after clearing the cache.
When I tried another browser, I was unable to quit out of the browser!
If you have to figure out—or explain to users—how to get around a website, that’s a huge fail.
Unclear Link Text
Accessibility overlays don’t fix unclear link text. Checking one of the sites using an overlay, I noticed social media icons. I then went to them using a screen reader. I didn’t hear “Facebook,” “Twitter” and whatever the other one was, as I should have. Instead, I heard “Link. New window” for each of them.
I can tell what these icons are for because I am a sighted user, but those who have low vision or are blind won’t be able to tell what those icons are for, where the link is taking them.
On another site using an overlay, a shopping site, I saw several products on a page, each with “Buy now” links under them. Again, I can tell what they are for as a sighted user, but someone using a screen reader won’t know if they are multiple links for the same product, that go to the same page, or if some or all of them are different.
On another site with an overlay, I found several color contrast errors that hadn’t been addressed by the tool. So that means that anyone with low vision may not be able to make out what that text says. It was just too light against the background.
If an overlay can address this, what color will it choose for that element? It may just lighten or darken the existing color, which may alter the site’s design. But if you as the designer or developer are in control of this, you can determine if that color is OK or if you should choose a different, more suitable, color from the client’s brand color palette instead.
Incorrect Heading Order
Visiting yet another site using an overlay, I checked the heading order and saw that that had not been resolved either. Heading order is important because it creates a structure for the content on the page. It helps sighted users and those with low or no vision understand the page hierarchy.
Now, what about paragraph text that should be a heading, or headings that should be body text? A tool isn’t going to be able to make that call.
There could be paragraph text, tables or even a set of images that should be styled as a list. If an overlay were to detect multiple lines of text in a row that end with a <br> tag instead of an end paragraph tag, it cannot tell if those should be in a list or if they should be inside their own paragraph tags. In other words, are they supposed to be list items or are they just short paragraphs?
Improper or Inadequate Alt-text
Accessibility overlays cannot tell if an image has improper or inadequate Alt-text. Take, for instance, an image of a pie chart. The Alt-text could potentially say, “Image of a pie chart. The blue pie piece represents 25%, the orange piece 50% and the green piece 25%.”
Someone who has been blind since birth won’t know or care which color is which. They need to know what the data means, not what it looks like. Plus, information cannot be conveyed with color alone. So, an automated tool may detect that the image has Alt-text and leave it alone.
On the other side, there are situations where images that are considered decorative have Alt-text but should not.
What about images that contain text that aren’t crisp—say, they get pixelated—when the page content is magnified? The overlay cannot produce a better-resolution image out of thin air.
It may also be able to detect what the text says but that will rely on factors such as the clarity of the image, its resolution, how easy to read that particular typeface is and if the text is placed over a background pattern or other text, making it harder to make out.
Lack of or Unclear Form Labels
I also found cases of form fields that did not have labels associated with them. That means that anyone who can’t see the text near the form fields cannot tell what to do with each form field. There may be placeholder text in the fields, but those with low vision may not be able to read the placeholder text because placeholder text is usually very light.
If the overlay can add labels, are they going to be correct? If they aren’t, then the user could fill out information in the wrong field. In that case, they may get alerts to errors in fields that they don’t understand how to fix because, for example, they’ve just typed their e-mail address in the First Name field and get alerted that those characters are not allowed in that field.
If they cannot determine which field they are in and the error message isn’t specific, that compounds the problem.
Improper Use of ARIA
There are also cases of improper use of ARIA with accessibility overlays. ARIA can be added to HTML tags to enhance accessibility, so when someone is using assistive technology. But it can really screw things up when it’s not done properly.
Decreased Site Performance
Accessibility overlays affect the performance—the speed—of the site. Some of the functions of the overlay may be more taxing than others. How much will the site slow down?
Keep in mind that Google uses speed as a factor to give sites a boost in search engine rank, so how much of a hit to the performance is going to affect that site’s rankings?
Not only that, but if the site is slow, then visitors will leave. So there’s a lot of potential for getting less traffic and frustrating those who are coming to the site.
Less Control Over Branding
Accessibility overlays can affect branding, the first aspect being the design, and I’ve gone into some of those issues already. A client likely invested a good bit of money into the design, only to now have it changed, out of their control, by the overlay.
But where overlays don’t address accessibility issues, there is another aspect of branding to consider, which can definitely affect the bottom line. The business could be perceived as having a negative reputation on diversity for having an inaccessible website.
People with a disability are 3 times as likely to avoid a business with an inaccessible website and twice as likely to dissuade others from doing business with it, according to the Australian Human Rights Commission.
There’s also custom overlays. Custom overlays aren’t robust. They can break as changes in the code are made to the site or when the site is maintained.
Some overlays can actually exacerbate accessibility issues.
If you change your theme, you open up a whole new can of worms.
Potential Security Issues
In terms of financial costs with an overlay—and custom ones cost even more—the client continually throws money at something that doesn’t address the underlying issues.
Let’s think about that. If you have a leaky pipe, are you going to continually put down towels and a bucket to catch the water, or are you going to have the darn pipe repaired before the water does more damage and then you have to replace flooring and drywall?
So it’s not a long-term solution. It’s like putting lipstick on a pig.
Companies and organizations end up throwing money at the wrong solution when they could invest in fixing the site and getting training.
Potential legal fees that could arise from not having an accessible site include fines, settlement fees, lawyer fees for both sides plus eventual remediation costs. Plus, even if the client gets sued, it doesn’t mean they can’t get sued again. A court could order them to fix the site within a certain period of time, and someone else could come along and go after them within that same timeframe.
I’ve heard of these fees ranging anywhere from $4,000 to $100,000. Will the vendors of these overlays pay these fees on yours and your client’s behalf if the worst happens?
And, yes, I said “yours,” because I’ve heard stories where a client has sued their developers after they’ve been sued. They go back to them to recoup the fees that they’ve just had to pay.
Not only that… There was a case with the Wet Willie’s bar chain where the plaintiff sued both the bar chain and the web developers and the host, claiming they were both responsible for the accessibility of the site.
Some of the issues I mention about overlays also apply to plugins. Installing an accessibility plugin doesn’t suddenly make your site accessible. Many of them can detect certain issues, and some may fix some of the found issues as well.
But the use of them doesn’t negate the need for manual checking, and they’re not going to fix your site’s code. Accessibility is much more than that, so slapping a plugin on a site doesn’t make it accessible.
A lot of plugins add controls to the front end of the site to allow the user to adjust the text size, contrast and so forth. But they really don’t add anything for people who are already using some form of assistive technology or features inherently built into their operating system.
An Accessible Solution
Accessibility starts with the proper foundation. It starts with the code.
Overlays and plugins (when those plugins are used without taking the proper additional measures) provide a false sense of security and just delay the inevitable—remediation and educating and training those who add or modify content on the site in how to properly format their content.
Remediation means fixing the site—modifying the site’s code and page content—and making it compliant with accessibility guidelines.
So remediation and training are part of a much more robust, long-term solution.
When you understand and design and code for accessibility, instead of dismissing it by the way side with an automated tool (that doesn’t fix things anyway), it provides for a much better user experience and a better, more robust, properly built website. And the functionality and look of the site are in your and the client’s control.
Website Accessibility Course
If you want to learn more about creating and remediating accessible websites, I invite you to check out my website accessibility course. I’ll help you understand accessibility and I will teach you my process for designing and building accessible websites, how to talk to a client or prospect about accessibility, some ways I protect myself in my contracts, how to earn recurring revenue and help your client with accessibility, and more.
I’ve said it before and I’ll say it again. Accessibility is also a great way to stand out from other web designers and developers, which can give you a competitive edge, especially when you’re the one bringing it up and others aren’t.
Don’t think that ignoring accessibility relieves you of the responsibility. You’ve just got to know about this stuff as a web designer or developer.