Why accessibility overlay widgets don't make a website compliant

Accessibility overlay widgets are often sold as a quick way to make a website compliant: add one line of code and a toolbar appears. The appeal is understandable, especially for a small business facing a legal requirement. This article explains what overlays actually do, why they cannot meet many WCAG 2.1 Level AA criteria, and what a reliable alternative looks like.

What an overlay is

An overlay is a script added to a website, usually from a third party. It typically does two things.

• Adds a toolbar or menu where visitors can change text size, contrast, spacing, fonts or animations.
• Attempts automatic repairs by scanning the page as it loads and changing the code in the browser: adding guessed alt text, inserting labels, or altering attributes that assistive technology reads.

The underlying website stays the same. The overlay tries to patch it each time a page is viewed.

Why automated fixes fall short

WCAG 2.1 Level AA has 50 success criteria. Some can be checked by software. Many cannot, because they depend on meaning, purpose and intent, which only the people who run the business know. A script can detect that something is missing. It usually cannot know what the right answer is.

Alt text needs to carry meaning

Success criterion 1.1.1 requires a text alternative that serves the same purpose as the image. A script can generate a description of what an image appears to show, such as "a person smiling at a desk". It cannot know that the image is a photo of your lead hygienist, that it is purely decorative, or that it is a button that opens your booking form. The correct alt text in each of those cases is different, and in the decorative case it should be empty.

Keyboard logic is built into the code

Criteria such as 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.3 Focus Order and 2.4.7 Focus Visible depend on how menus, dialogs, sliders and forms are built. If a drop-down menu only opens on mouse hover, or a pop-up does not return focus when it closes, the fix is in the component's code and behaviour. A script layered on top often cannot reliably rebuild that behaviour, and attempts to do so can introduce new problems.

Labels and instructions need human judgement

Criteria 1.3.1 Info and Relationships, 2.4.6 Headings and Labels and 3.3.2 Labels or Instructions require that form fields have clear, accurate labels and that headings describe the content beneath them. A script might attach the nearest visible text to a field as its label. Sometimes that is right. Sometimes it labels the "Postal code" field as "Required" or picks up the wrong word entirely. Error messages under 3.3.1 and 3.3.3 need to explain what went wrong and how to fix it, in words that make sense for your form.

Captions, documents and structure

Overlays generally do not caption your videos accurately, do not tag your PDFs, and do not fix a page where the reading order makes no sense. These are content problems, not display settings.

Conflicts with assistive technology

People who rely on assistive technology have already set up their own tools. Screen readers such as NVDA and VoiceOver, screen magnifiers, browser zoom and operating system contrast settings are configured to suit the individual. An overlay can get in the way of that.

• Duplicate or conflicting controls. A screen reader user may land on an extra toolbar before reaching the page content, and may hear controls that duplicate what their own software already does.
• Changed announcements. When a script rewrites roles, names or attributes on the fly, a screen reader may announce elements differently from what is visible, or announce them twice.
• Timing problems. Repairs that run after the page loads can mean the first version a screen reader encounters is different from the version a moment later.
• Interference with user settings. Forced font, colour or spacing changes can override the settings a person already relies on.

The result can be a site that is harder to use for exactly the people the widget was meant to help.

The compliance question

Manitoba's Accessible Information and Communication Standard Regulation, Man. Reg. 47/2022, requires web content to meet WCAG 2.1 Level AA (s. 7(1) (opens in a new tab)). The test is whether the content meets the criteria, not whether a tool has been installed. If an inspection finds that pages do not meet the criteria, an overlay on the page does not change that finding. For a summary of the regulation, see the Manitoba standard.

There is also a cost consideration. Overlays are usually an ongoing subscription. Fixing the underlying code is generally a one-time piece of work, followed by routine care as content changes.

What to do instead

The reliable route is to fix the website itself.

1. Audit the site against WCAG 2.1 AA using a combination of automated scans and manual testing: keyboard only, screen readers, 200% zoom and reflow at 320 CSS pixels. Our method page describes this in detail.
2. Repair the source code and content. Write real alt text, correct labels, fix keyboard behaviour, adjust colours where contrast falls short. This can usually be done with little or no visible change to the design.
3. Document what was done so you have a record of testing and remediation.
4. Keep it accessible as pages, menus and documents are added, through training and periodic checks.

If an overlay is already installed, removing it is normally part of the remediation, so that it does not interfere with the fixes. We never use overlay widgets in our own work; our services page explains our approach, and the FAQ covers common questions about it.

Talk to us

If you have an overlay installed, or have been offered one, we can review your site and tell you what it would take to meet the standard properly. Book a consultation and we will provide a fixed written quote after the audit.

Last reviewed October 2026. General information, not legal advice.