What overlays are and how they are marketed

An accessibility overlay is a third-party JavaScript file you add to your website. Once loaded, it typically displays a floating widget — a small icon, often a person in a wheelchair — that users can click to open a panel of visual preferences: larger text, higher contrast, simplified layout, a reading ruler, and so on.

Beyond the user-facing widget, overlays claim to work automatically in the background, using AI to detect and repair accessibility issues without changes to the underlying code. The marketing language is consistent across vendors: "instant compliance," "achieve WCAG 2.1 AA in 48 hours," "reduce your legal risk," "no developer needed." Prices typically run from $50 to $500 per month depending on the site and vendor.

For a small business owner who has received a demand letter from an accessibility law firm or who has just learned that their province has accessibility legislation, the pitch is understandably tempting. There is an apparent quick fix available, sold by companies with professional-looking websites and testimonials from satisfied clients.

What the evidence actually shows

In 2020, accessibility consultant Karl Groves and a team of researchers published an analysis of accessiBe's claims, testing the overlay against WCAG 2.1 success criteria. They found that automated overlay technology could not detect or fix the majority of WCAG failures — and in some cases introduced new problems. The overlay scored well on issues that are easy to detect automatically (missing alt text on simple images, form labels where the connection is structurally obvious) but failed on the broader and more complex set of criteria.

The Web Accessibility Initiative (WAI) at the W3C — the organisation that authors the WCAG standards overlays claim to satisfy — has stated that no overlay currently available can automatically repair all the issues required for WCAG conformance. Their guidance specifically notes that automated tools can reliably detect only about 30–40 percent of WCAG success criteria; the remainder require human judgment.

A 2021 study by WebAIM tested the top million websites for accessibility failures and found that pages using overlay products had more detectable accessibility errors on average than pages without them — suggesting that overlays do not reliably improve measurable accessibility outcomes and may correlate with a general inattention to the underlying code.

In 2023 and into 2024, major screen reader software publishers — including Freedom Scientific (JAWS) and NV Access (NVDA) — warned their users that certain overlays were interfering with screen reader operation, sometimes making pages less navigable than they would have been without the overlay at all.

Why overlays cannot fix accessibility problems

Accessibility problems are structural. They exist in the HTML, the JavaScript behaviour, the design decisions, and the content hierarchy — not in a layer sitting on top of those things. An overlay cannot retroactively make a form accessible if the form's inputs are not properly labelled in the markup. It cannot make a modal dialog keyboard-accessible if the JavaScript managing focus trapping and the escape key behaviour does not exist. It cannot create meaningful alt text for complex images because it has no way to know what those images contain or what role they play in context.

The automated detection component of overlays uses heuristics — pattern-matching rules that work well on common simple cases and fail on everything else. A button with no visible text and no aria-label is an obvious target; the overlay can add a label. But whether that label is meaningful and accurate requires understanding the button's purpose in context. The overlay cannot do that.

The user-facing preference panel does provide some genuine utility. Being able to increase font size, adjust contrast, or add a reading cursor is useful. But these are features that modern operating systems and browsers already provide to users who need them, and offering them through your website does not substitute for having a site that works correctly with the assistive technology the user already has.

The interference problem. Many screen reader users report that accessibility overlays actively break their experience. The overlay intercepts keystrokes and DOM events that the screen reader relies on, producing unpredictable results. Some overlays intercept the spacebar, Enter, and arrow key behaviours that screen readers use for navigation. Users with screen magnification software have reported overlay widgets appearing at positions that interfere with their magnified view.

A significant part of the overlay marketing proposition is legal risk reduction. The claim is that having an overlay in place demonstrates a good-faith effort at accessibility compliance, reducing your exposure to complaints and litigation.

In the United States, where web accessibility litigation under the ADA is common, this claim has been tested and found wanting. Companies using accessiBe and similar products have been defendants in accessibility lawsuits. Having an overlay installed did not prevent complaints, did not result in case dismissals based on the overlay's presence, and in some cases was specifically cited as insufficient by plaintiffs' counsel because it failed to make the site usable.

In Canada, the legal landscape is different but the principle is the same. The BC Accessibility Act, AODA in Ontario, and the broader human rights obligations under federal and provincial human rights codes require actual access — not the appearance of an access effort. A product that fails to make your site usable by disabled users does not satisfy those obligations regardless of what its marketing says.

What disabled users say

The clearest evidence against overlays comes from the people they are supposed to help. In 2021, over 700 accessibility professionals and disabled users signed the Overlay Fact Sheet, a document summarising the problems with overlay products and calling on website owners not to use them. The signatories included blind screen reader users, mobility-impaired keyboard-only users, accessibility researchers, and people with cognitive disabilities who found overlay widgets confusing and disorienting.

The feedback from screen reader users is particularly consistent. Many report that sites with overlays are harder to use than sites without them. The overlay widget itself is often difficult to navigate by keyboard, the preference options do not persist reliably, and the background automation introduces unexpected DOM changes that confuse screen reader navigation.

When the people an accessibility product is supposed to help are actively asking you not to use it, that is meaningful evidence about its effectiveness.

What actually works

Genuine accessibility requires addressing the underlying code and content. The good news is that most websites have a limited set of recurring problems, and fixing them properly is not the enormous undertaking overlay vendors imply it is.

The highest-impact starting points are: meaningful alt text on images (written by a human who understands the image's purpose), properly labelled form inputs (using <label> elements with for attributes or aria-label), sufficient colour contrast between text and background (4.5:1 for normal text, 3:1 for large), keyboard navigability for all interactive elements (links, buttons, form controls, modals), and a logical heading structure (one H1, then H2s for major sections, H3s for subsections).

Automated testing tools — axe-core (free, available as a browser extension), Lighthouse in Chrome DevTools, and WAVE — can reliably find around 30–40 percent of WCAG failures and are an appropriate starting point for an audit. The remaining issues require manual testing, including keyboard-only navigation testing and ideally testing with at least one screen reader.

If your site was built in a CMS or on a platform, accessibility improvements often mean choosing accessible themes and plugins, configuring them correctly, and ensuring your content is structured properly — not necessarily rewriting code from scratch.

For new builds, building with accessibility from the start is meaningfully cheaper than retrofitting. Semantic HTML — using <button> for buttons, <nav> for navigation, <main> for main content — handles a large portion of accessibility requirements before any CSS or JavaScript is written.

The Canadian regulatory context

Canadian web accessibility obligations come from multiple directions. Federally regulated organisations are subject to the Accessible Canada Act. Ontario-based businesses have AODA timelines. BC's Accessibility Act is expanding to cover private-sector organisations on a phased schedule. Quebec's Charter of Human Rights and Freedoms has been interpreted to include digital accessibility in certain contexts.

Across all of these frameworks, the standard being referenced is WCAG 2.1 Level AA — the same standard overlays claim to deliver. The difference is that the legal and regulatory context requires actual conformance, which means the site must work with assistive technology used by real people. An overlay that makes the site nominally pass an automated check while breaking it for screen reader users does not satisfy that requirement.

The most defensible position — both legally and ethically — is a site that has been built and tested for genuine accessibility, with documentation of that process. That is not something an overlay can provide, because it requires intentional design and development decisions, not a JavaScript patch applied after the fact.

I am low vision. I use screen magnification daily, including when building and testing this site. My experience with overlay widgets has been consistently negative — they tend to conflict with magnification software in ways that are disorienting, and the preference panels rarely offer controls I do not already have through my operating system. The people designing overlay products are not, by and large, the people who need accessibility features.