What is an accessibility overlay?

An accessibility overlay is a software layer added to a website that is already finished. It usually arrives as a line of JavaScript pasted into the page code, or as a plugin activated from the content management system. When the page loads, that script inserts a floating button, almost always in a corner, which opens a menu of visual settings: font size, contrast, cursor type, pausing animations, sometimes text-to-speech.

The difference from real accessibility work lies in where the change happens. A genuine accessibility implementation works in the source code: correct HTML markup, ARIA attributes on interactive components, keyboard navigation tested with real users, contrast calculated at the design stage. The overlay, instead, acts afterward, from the outside, on a page that can keep the same structural problems underneath the settings menu.

This article does not assess whether overlays are legal or illegal, because no standard names them explicitly. What does exist is a technical basis and a documented position from accessibility organizations against treating them as a complete solution. That basis follows in the next section.

The mechanism is almost always the same. A JavaScript snippet runs in the visitor's browser, scans the page's DOM, and applies changes on the fly: enlarges text, raises contrast, adds or edits missing ARIA attributes, tries to describe images without alt text through automatic recognition.

The problem shows up in what that script cannot do. WCAG 2.2, the W3C's reference technical standard for accessible web content, requires for example that all functionality be operable through a keyboard (criterion 2.1.1) and that every interface component communicate its name, role, and state to assistive technologies (criterion 4.1.2). A dropdown menu coded without keyboard event handling does not gain that handling because an overlay adds a visible focus outline. The missing event is still missing. And a custom component that never defined its role does not reliably get one because an external script tries to guess it by pattern matching: it may work on simple buttons and fail on a carousel or a form with its own validation.

Automatic image recognition has the same limit. It can label a generic photo with a plausible word, but it does not know what specific information that image needed to convey within the content: a chart with data, a button disguised as an icon, a screenshot with embedded text. WCAG 2.2 requires alt text that fulfills the image's function (criterion 1.1.1), not an approximate, context-free description.

That is why the technical critique does not say overlays do nothing. It says they act on the visible layer and leave untouched the behavior layer that a screen reader or a keyboard user needs. In some cases they add a new problem: if the overlay rewrites attributes the user had already configured in their own screen reader or browser, the two layers can clash, leaving the page less accessible than before it was installed.

The overlay is often sold as a one-line fix to meet accessibility law such as the European Accessibility Act or the ADA. That promise is the problem: it turns a technical decision into a quick purchase and diverts the budget that should go toward fixing the source code into a monthly subscription that never reaches the root cause.

The American Foundation for the Blind, in a piece published on September 15, 2022, put it this way: overlays "often miss more than 70% of WCAG guidelines which can only be assessed through manual testing," and "these accessibility overlays often override the settings of users' existing assistive technology software, which makes things more difficult and complicated for the user." That is the assessment of a recognized disability advocacy organization, not a court ruling: no standard names overlays specifically.

The expensive part of the mistake comes later. If a company relies on the overlay to close the issue and later faces a complaint or an inspection, it cannot claim the problem is already solved. The underlying code still fails to meet the requirements, and the money spent on the overlay adds to the cost of the real fix that eventually has to happen anyway.

There is also a basic difference between the two types of spending. The overlay subscription is paid month after month for as long as the website exists, without the code improving because of it. Fixing the source code is a one-time cost that stays built into the website and does not depend on continued payment to avoid losing it.

• Before installing anything, commission a real audit against WCAG 2.2, done by a person; an automated scanner alone is not enough.
• Test the site with keyboard only, no mouse: tab through every link, button, and form, and check that focus is visible and nothing gets trapped.
• Test with a real screen reader (NVDA, VoiceOver): the homepage alone is not enough, the highest-traffic pages need it too.
• Fix what is missing in the source code: alt text, ARIA roles, color contrast, heading order, forms with properly associated labels.
• Document each fix with a date, so the work can be proven if a complaint arrives.
• If an overlay is used, treat it as a complementary visual aid for end users, never as a substitute for the work above.

• Installing the overlay and treating the accessibility project as closed without touching the code.
• Mistaking the absence of a standard that bans overlays for proof that they meet accessibility requirements.
• Not testing the site with a keyboard or screen reader after installing the overlay, and assuming it works because the visual menu appears.
• Letting the overlay be the only measure against accessibility laws with real deadlines and penalties.
• Not checking whether the overlay conflicts with the assistive technology the user already has configured on their own device, and only finding out after a complaint arrives.