Accessibility Widgets Don't Make Your Site Accessible

You've seen the button. A small floating icon in the corner of a website — usually a figure in a wheelchair, sometimes two overlapping circles. Click it and a panel slides out: contrast modes, font size controls, dyslexia-friendly fonts, animation toggles.

It looks like accessibility. It is not accessibility.

What Overlay Widgets Actually Are

Companies like accessiBe, UserWay, AudioEye, and EqualWeb sell JavaScript overlays that sit on top of a website and promise to make it WCAG 2.1 AA and ADA compliant — automatically, without changing the underlying code. Monthly subscriptions run from $49 to several hundred dollars per site. The pitch is efficient: one script tag, no developer required, legal exposure solved.

The problem is structural. The underlying code is still broken. The overlay attempts to patch accessibility problems in real time, in the browser, on top of HTML that was never written to be accessible. For sighted users clicking around a page, this can look convincing. For the people these tools are supposed to serve, it regularly makes things worse.

What Disabled Users Say

The disability community has been consistent on this point for years.

Screen reader users — people who navigate websites using software that reads content aloud — report that overlays frequently interfere with their tools. The overlay JavaScript and the screen reader compete for the same elements. Keyboard navigation breaks. Focus jumps unexpectedly. Content that was usable before the overlay becomes unusable after it.

In 2021, more than 400 accessibility professionals and disabled users signed an open letter calling for overlay widgets to be removed from websites entirely. The letter, published at overlayfactsheet.com, states plainly that overlays "must be abandoned."

That same year, the National Federation of the Blind — the largest organization of blind people in the United States — passed a formal resolution condemning accessiBe's product and calling it harmful to blind people.

A tool sold as an accessibility solution, formally opposed by the people it claims to help. That is the situation.

What the Legal Record Shows

Overlay vendors lead with legal protection as their primary sales argument. The legal record does not support it.

ADA Title III lawsuits involving websites have increased steadily for years. Having an overlay widget installed has not reliably protected businesses from these suits. Plaintiffs have successfully demonstrated in court that overlays leave specific, concrete barriers in place — barriers that a disabled user encountered, that the overlay did not fix, and that the defendant was still liable for.

The overlay vendors themselves are careful about this in their own terms of service. Read the fine print and you will find they do not guarantee compliance. They cannot. Compliance is a property of the underlying code, not of a script tag added on top of it.

The Department of Justice clarified the standard in April 2024, publishing its final rule establishing WCAG 2.1 AA as the compliance benchmark for state and local government websites. The rule makes no mention of overlay widgets as a path to compliance — because they are not one.

For Canadian businesses, the trajectory is the same. The Accessible Canada Act and provincial accessibility legislation treat web accessibility as a legal obligation. An overlay widget is not a documented compliance path under any of these frameworks.

Why Overlays Cannot Work Technically

WCAG 2.1 AA compliance requires meeting 50 specific success criteria across four principles: perceivable, operable, understandable, and robust. The criteria that determine whether a site is actually usable by disabled people — logical heading structure, properly labelled form fields, descriptive image alt text, keyboard-navigable interactions, correct landmark regions — are properties of the HTML itself.

A screen reader reads the HTML as written. An overlay can change what a sighted user sees on screen. It cannot reliably change what a screen reader processes, because the DOM — the underlying document structure — is what the screen reader uses. You cannot fix inaccessible markup from the outside. The fix has to happen in the markup.

The things overlays can genuinely assist with are surface-level adjustments: colour contrast for sighted users, increased font sizes. These are useful for some people. They are not compliance, and they do not address the structural problems that determine whether a site is navigable for someone using assistive technology.

What Genuine Compliance Looks Like

A site that is actually accessible is built that way from the start.

Every image has a real text alternative — not a filename, not "image001," but a description of what the image shows and why it's there. Every form field has a properly associated label that screen readers can read. The heading structure is logical — one top-level heading, a clear hierarchy beneath it, no levels skipped. The page has landmarks: a defined header, navigation, main content area, and footer. A skip link lets keyboard users jump past navigation directly to content. Keyboard focus is always visible. Animations stop for users who have requested reduced motion in their system settings. Text contrast meets the 4.5:1 ratio required for body copy.

These are not optional enhancements. They are the difference between a site that works for everyone and a site that only works for some people.

This is also, incidentally, why the sites we build start from a clean semantic HTML foundation rather than a plugin-laden CMS. When the markup is correct from the beginning, there is nothing for an overlay to patch and nothing for a screen reader to fight with.

How to Audit Your Current Site

If you're unsure where your site stands, free automated tools give a starting point. The WAVE Web Accessibility Evaluation Tool runs a check on any public URL and flags errors with explanations. Google Lighthouse, built into Chrome's developer tools, includes an accessibility audit. Neither is a substitute for manual testing with actual assistive technology, but both will surface the most common structural problems quickly.

Automated tools catch approximately 30 to 40 percent of WCAG failures. The rest require a human to find — ideally a qualified accessibility specialist, or at minimum, someone testing the site with a screen reader and keyboard only.

The relevant question before any site goes live is not "do we have the widget installed" but: can a keyboard user complete every action on this site without a mouse? Can a screen reader user understand the structure and purpose of every page? Are our forms actually labelled? Are our images actually described?

If the answers are yes, you have an accessible site. If the answers are no, an overlay widget does not change that. The fix is in the code — and it has to be.

If you're looking at rebuilding your site entirely and want to start from accessible, semantic HTML rather than retrofitting compliance onto a CMS that was never designed for it, that's exactly what PressFixer builds.