Is it an evil overlay? How can you tell?

I’m approaching this story from the starting assumption that accessibility overlays are a problem. So I’m not going to spend time on arguments for or against the technology. I’m also making the assumption that we all agree that the tool itself must be accessible, and won’t discuss that question here.

I am interested in one key question: where do we draw the line between a potentially useful tool and an evil overlay? What are the characteristics that make an overlay a problem?

I’ve been thinking about this for quite a while, for a couple of reasons. First, I’m the creator and maintainer of the WP Accessibility plugin. This plugin unquestionably smells like an overlay: it has all the characteristics that I’m going to talk about: it has a toolbar, and it automatically changes the code on your website, intending to improve your accessibility.

Is it different from other tools like that? If so, how is it different?

The second reason is for the non-profit I helped found: WP Accessibility Day. We have a standing philosophy statement that opposes overlays, and our sponsor policy specifically rejects overlays (with some qualifications.) In our 2025 event, we allowed sponsorship from Elementor’s A11y plugin, which also looks a lot like an overlay. We did take some flack from that, and as a result we recognize that we need to become more explicit and detailed. We need to specifically define how we characterize overlays.

This is not the WP Accessibility Day official statement; it is my own thoughts on the topic.

Overlay Characteristics

In my mind, there are three characteristics that make something look and smell like an overlay.

1. A toolbar. The existence of a toolbar with accessibility characteristics can be a warning signal.
2. Automated accessibility remediation. Using scripting to look at the code of the site and manipulate it. This also looks fishy.
3. Unethical Marketing. This is not a technical concern, but equally important. What are the claims made about the tool?

Neither of the two technical issues are inherently bad. So let’s try and be explicit in distinguishing what is “good” and “bad” in either case.

Toolbars

My first concern about toolbars is about targeting. How do the tools present themselves? This is something I’ve written about before, in my article Overlays Misunderstand Accessibility. In that article, I talk about the important distinction between a tool that targets a disability rather than offering a feature, among other topics.

If a toolbar simply offers a feature, without implying that it supports any specific disability or is needed by any specific population, then I that seems acceptable to me. I may feel that the features offered aren’t useful, but that simply means that they aren’t targeting me; if somebody benefits from it, then great for them.

But if a vendor presents their feature as a solution for a particular impairment, then I have a problem with that. What users need to know is what a tool will do; not whether somebody has decided that they have the solution to your disability.

How does WP Accessibility do?

WP Accessibility only offers two tools: Increase Font Size and High Contrast. These simply inform the user what they will do, and, in my opinion, pass this test.

Elementor’s A11y plugin also passes this test. They have many more features available, but they are all described in simple terms illustrating what they do: Pause animations, Hide images, Outline focus, etc. There’s no implication that these solve a particular disability.

While I still believe that overlays are the wrong place for the majority of these tools – because assistive technology should travel with a user, not belong to each individual site, I think that measuring whether a toolbar is creating problems is a question about how it is presented than about whether it exists.

Automated Accessibility Fixes

This is where we get into some very murky ground. My starting differentiator is between purpose-built scripted remediation and generalized remediation.

Purpose-built is where a developer has created a solution that is specifically targeted at a problem on your site. There is a known problem, identified by an accessibility specialist, and a targeted fix that resolves it, with follow-up testing that confirms the validity of the fix.

Generalized remediation is where the script is authored to find accessibility issues and remediate them without any external validation.

Any of the purpose-built are essentially fine. They exist for a reason: there is a known problem, and a way to fix it. This is done when it’s not an option to fix the source. In principle, a necessary evil in the way problems get resolved.

Generalized remediation, however, can cover a vast array of possibilities, with wide ranging degrees of risk. This is essentially an extension of the coverage problems that automated accessibility testing has, with a few additional challenges thrown in for good measure.

Automated accessibility testing is limited because some issues just aren’t deterministic, and that same thing is true for accessibility remediation. Somebody needs to make a decision to identify the problem and how it gets fixed.

For example, you could write a script that identifies all links with role="button" and adds a spacebar handler to their event stack. This sounds good at first, until you actually try to do it – and quickly find all the cases where you’re now triggering a repeat event, or overriding somebody else’s event. Doing this is risky, and opens up the potential that you create worse problems than you fix.

It’s pretty labor intensive to identify exactly what any given accessibility tool is doing automatically, and even more work to figure out how safe those changes are.

How does WP Accessibility do?

I know exactly what WP Accessibility does, and that does raise some questions for me. I’ve tried to be pretty conservative about addressing only issues where I have a lot of confidence, but…am I right? How can I really tell?

At a certain level, I think that the assessment might need to be about having the ability to disable or customize individual remediation pathways. As long as all generalized remediation paths can be disabled by the site owner or customized by a developer, there is at least a pathway to prevent that script from causing problems.

If that’s the assessment I’m going to use, then at the moment, WP Accessibility fails my own test. Many of the remediations it does cannot be controlled by the site owner or by a developer. I’ll be updating the settings shortly to address this. I’ll ensure that all overlay-like features are clearly indicated and can be disabled.

I haven’t done the work to identify what Elementor’s A11y plugin does here, and I don’t have access to install it and experiment, so I’m not able to judge this question at this time.

Marketing

Ultimately, one of the biggest red flags is in the marketing for the tool. Even if all of the criteria above are met, if the marketing for the tool says “install SupremoA11y and you’ll be invulnerable to accessibility lawsuits and fully compliant with all global accessibility legislation!”, then it’s just scamming vulnerable site owners. (At the time of writing, no tool called SupremoA11y exists. But give it 10 minutes.)

I think we all know that sites get very sneaky about how they distinguish between marketing talk and their actual terms of use. Always read the fine print!

To me, this judgement is not just about what the vendor says. It’s also about how obvious it is. A user shouldn’t have to read the fine print to learn that a tool won’t make their site accessible.

If the vendor gives the impression that their tool is a substitute for real accessibility testing and remediation, I think that’s enough to disqualify them.

How does WP Accessibility do?

WP Accessibility actively avoids making any claims that you’ll meet any requirements. The second paragraph on the plugin’s home page is pretty clear. “WP Accessibility is not intended to make your site compatible with any accessibility guidelines.” I should probably also mention legislation, but that’s a minor point.

Elementor’s A11y doesn’t seem to make any questionable claims, at least in their written text. The WordPress.org plugin page has a paragraph that specifically says that the plugin is “NOT intended to completely make your website legally compliant”, and their FAQ (Frequently Asked Questions) goes into more detail, clearly stating that “no automated tool can promise full accessibility.” They also encourage you to employ accessibility professionals to meet full compliance. That feels like a fair and reasonable presentation of the product’s real capabilities.

What about some negative examples?

For example, the accessiBe plugin page at WordPress.org currently has a prominent heading with the text “Meet legal requirements under the ADA and win more business”. There is no mention anywhere on the page that this has limitations. There is no statement that the tool alone will not make you meet legal requirements.

In their Frequently Asked Questions section, they offer the question “How do accessiBe and accessWidget help your website reach ADA compliance?“. The answer? “Once installed on your website, accessWidget will audit its code and identify accessibility problems. Then, it will perform session-based remediations of many of the issues so that your website is accessible based on the Web Content Accessibility Guidelines (WCAG (Web Content Accessibility Guidelines)).“

Technically, that FAQ answer only says that it remediates some of the issues. By extension, you could conclude that it won’t be making your site fully compliant. But it then continues on to say that your site will be accessible, so it’s pretty understandable if you come away with a different impression.

To me, this is exactly the kind of marketing that makes an overlay into a problem. No matter what the rest of the technology might be doing, this language targets people who don’t understand accessibility and takes advantage of their lack of prior knowledge.

Summary

The “accessibility overlay” we talk about and condemn is a combination of three possible problems:

1. Tools that make presumptions about how a user’s disability impacts them.
2. Accessibility remediations that are untargeted and potentially risky.
3. Marketing that states or implies meeting standards or legal requirements.

For me, these are the three measures to use to determine whether an overlay is a problem. I want to be clear that passing these measures does not make something a tool that I would recommend or use; but it is not something I would condemn as an accessibility overlay.

Each condition is a different type of flaw. The first may still represent perfectly useful tooling, but with an ableist presentation. The second may actually introduce new accessibility errors. The last actively deceives potential customers.