Every few months a client sends me a screenshot of a popup on a competitor site. A circular icon in the corner, often blue, sometimes a wheelchair symbol. Click it and a panel slides out offering bigger text, more contrast, a reading mode, a screen reader toggle. The pitch on the vendor site usually promises WCAG compliance for the price of a Netflix subscription and a one-line script tag.
These are accessibility overlays. UserWay, accessiBe, EqualWeb, AudioEye and a handful of smaller vendors all sell variations of the same idea. They are everywhere on UK SME websites because they look like a solved problem. The honest position from people who do accessibility work is that they are not a solved problem at all. In several ways they make things worse for the users they claim to help.
I have covered the UK legal position in a separate post. This piece is about the technical and ethical case. Why the overlay model does not work, why screen reader users tend to disable them on sight and what to do instead.
What overlays actually do
An overlay is a JavaScript widget that loads after your page renders. It scans the DOM, makes guesses about what each element is and offers the user a panel of accessibility controls. Some of the controls change the rendered page directly, like font size or contrast. Others sit on top of assistive technology that the user already has, like adding ARIA attributes the developer did not write.
The premise is that a script can detect and remediate accessibility issues automatically. That premise breaks down quickly once you look at the WCAG criteria the overlay is supposed to satisfy.
Where WCAG sets the bar
WCAG 2.2 organises success criteria under four principles. Perceivable, operable, understandable, robust. Each one demands something of the underlying page that a script bolted on at runtime cannot reliably provide.
Perceivable requires meaningful alt text on images, captions on video and adequate colour contrast in your design. An overlay can invert colours, which sometimes helps a low-vision user, but it cannot write meaningful alt text. It can only guess. A photo of a smiling woman holding a clipboard is captioned by an overlay as "woman holding clipboard". That is not the alt text the page needs and it does not satisfy WCAG 1.1.1.
Operable requires that everything works with a keyboard, that focus is managed sensibly and that timing is generous enough. Keyboard handling is part of how your components are built. A modal that traps focus correctly, a menu that opens on Enter, a form that announces errors when validation fails. None of that is fixable by an overlay. The overlay itself often introduces new focus traps on top of the page.
Understandable requires consistent navigation, labelled form fields, clear language, predictable behaviour. An overlay cannot rename your form fields in a way that matches the underlying labels your screen reader user has already heard. It cannot rewrite content that uses jargon. It can sometimes offer a reading mode that strips the page back, but the WCAG criterion is about the source not the simplified copy.
Robust requires that the page works with current and future assistive technology. A page is robust when its HTML is valid, semantic and uses ARIA only where it is needed and used correctly. Overlays bolt on ARIA attributes at runtime and frequently override existing ones, which is the opposite of robust. The first ARIA rule is that you do not use ARIA where native HTML would do the job. Overlays violate that rule by design.
Why screen reader users mostly turn them off
The clearest signal that overlays do not work is what screen reader users do when they encounter them. Surveys of NVDA, JAWS and VoiceOver users have consistently found that the majority either disable the overlay outright when they recognise it or leave the site. The reasons are practical.
A screen reader user has spent years configuring their software. Their preferred voice, speech rate, verbosity level. When an overlay injects a competing screen reader inside the browser, those settings stop applying. The user is forced to use the overlay vendor choices instead.
Overlays change the accessible name and role of elements without warning. A button that was correctly labelled in the source might be re-announced by the overlay with a guessed label. The user does not know what is happening because the announcement comes from the overlay rather than from the page itself.
Focus order gets rewritten when the overlay panel opens. Many overlays trap focus inside their own UI without a clear escape route, which is the exact failure they were sold to fix.
Some overlays attempt to detect that a screen reader is running and adapt their behaviour. The detection methods involve fingerprinting the user, which raises a separate set of issues around privacy and is unreliable enough that users have to fight it.
The legal cover that is not there
In the United States, ADA Title III lawsuits against overlay-equipped sites have been rising steadily, with public tracking by accessibility law firms showing hundreds of cases involving sites that use accessiBe or UserWay across recent years. A small business that bought UserWay specifically because it believed the widget would prevent litigation was later sued by a blind user, and as of February 2026 a magistrate has recommended that its consumer fraud claim against UserWay can proceed. The Federal Trade Commission also finalised a settlement order against accessiBe in 2025 over claims that its widget could make any website WCAG compliant. The order required one million dollars in monetary relief and restricted future advertising language.
The UK legal position has not been tested in the same way. There is no high-profile English court ruling on overlays that I am aware of. What we have are two solid principles. Section 20 of the Equality Act 2010 requires reasonable adjustments and a court considering reasonableness is going to ask whether the site itself was usable, not whether a widget was installed on top. The Public Sector Bodies Accessibility Regulations require WCAG 2.1 AA conformance in the underlying site and the published audit reports show that overlays are treated as out of scope rather than as a compliance measure.
In practice, no UK accessibility auditor I have spoken to treats an overlay as evidence of conformance. The auditors test the page as a screen reader user actually encounters it, with the overlay either off, ignored or disabled. If your defence in a complaint is the overlay, your defence is thin.
Where overlays have a narrow legitimate use
Some of the surface features overlays sell are genuinely useful and most of them are built into the browser or the operating system anyway. Text resizing, high contrast modes, link highlighting, dyslexia-friendly fonts. If you want to surface those options in a panel for users who do not know they exist, build the panel yourself with about a day of front-end work. You keep control of how it behaves and you do not introduce a third-party script that reshapes your DOM.
There is also a smaller category of overlay use that I have seen work. Sites with a large historical content archive that will never be remediated, where the overlay is positioned honestly as a partial aid for some users alongside a clear accessibility statement and a contact route for help. It still does not satisfy WCAG and the owner knows that. The overlay is a comfort feature for sighted low-vision users, not a compliance claim.
What works instead
Accessibility is a property of the page, not a property of a widget added to it. The work that actually moves the needle is unglamorous.
Use semantic HTML. A button is a button, a heading is a heading. ARIA only when no native element fits. Write meaningful alt text at the point of upload, with a default of empty string for decorative images. Label every form field with a real label rather than a placeholder. Make sure every interaction works with the keyboard alone and that focus is visible. Keep colour contrast above the WCAG threshold in your design system, not as a remediation.
On a WordPress site, that work happens in the theme and in editorial discipline. Pick a theme that has a clean accessibility record. Configure Gutenberg blocks that enforce heading structure. Train whoever loads content to write alt text and to use heading levels correctly. Audit the live site against WCAG 2.2 AA at intervals.
It is slower than installing a widget. It also actually works.
If you already have an overlay installed
You do not need to rip it out in a panic. You need to stop relying on it as your compliance answer. A reasonable order of work is to audit the underlying site against WCAG 2.2 AA, fix the issues the overlay was supposed to be masking, then decide whether to keep the widget as a comfort tool or remove it. Many clients choose to remove it once they realise the cost of keeping it includes the licence fee, the third-party script tag and the false sense of security.
If you want a read on where your current site sits, take a look at WordPress development and accessibility work or get in touch and I will tell you what I would change first.
Frequently asked questions
Do accessibility overlays make my site WCAG compliant?
No. WCAG conformance is a property of the underlying HTML, content and interactions. An overlay script cannot write meaningful alt text, fix focus order, or replace semantic HTML at runtime in a way that satisfies the WCAG 2.2 AA criteria. Auditors test the underlying page, not the widget.
Are overlays legal cover under the UK Equality Act?
In practice, no. There is no UK case law that has tested overlays directly, but the Equality Act asks whether reasonable adjustments were made to the service. A widget that screen reader users routinely disable is unlikely to count as a reasonable adjustment. If you are a public body, PSBAR requires WCAG 2.1 AA conformance in the underlying site and audits ignore overlays.
Why do blind users dislike overlay widgets?
A screen reader user has already configured their preferred assistive technology. An overlay injects competing announcements, overrides ARIA labels and often traps keyboard focus inside its own panel. It does not help them. It interferes with the setup they already use to navigate the web.
What should I do if my WordPress site already has UserWay or accessiBe installed?
Stop treating it as your compliance answer. Audit the underlying site against WCAG 2.2 AA, fix the structural issues the overlay was supposed to mask, then decide whether to keep the widget as a comfort tool or remove it. Most clients remove it once the audit is done because the licence fee and third-party script no longer feel worth it.
Not sure where your WordPress site sits on WCAG?
If you have inherited an overlay and want a straight answer on whether the underlying site holds up, send me the URL and I will give you a read.
Get in touch
