Do I need an accessibility overlay?

Injects a script that runs after the page loads and alters the rendered document.

Offers a widget with presentational controls: larger text, higher contrast, increased spacing, a reading guide, sometimes a simplified layout.

Attempts automated remediation — guessing alternative text, adding ARIA attributes, adjusting focus order — based on what it can infer from the page.

Everything it does happens in the browser, after the fact, and only for visitors who load and keep the script.

Whether alternative text is accurate. A guess about what an image depicts is not a description of what it contributes in context.

Whether a custom control behaves correctly. Adding `role="button"` to a `div` changes how it is announced and not whether Enter and Space activate it.

Reading order and focus order, which depend on the meaning of the content.

Anything a visitor's own assistive technology already handles better, and which the overlay can interfere with.

Server-rendered problems for consumers that do not run scripts at all.

Browsers and operating systems already provide text scaling, contrast adjustment and zoom, configured once and applied everywhere. A per-site toolbar duplicates that worse.

Screen reader users already have their software configured to their preferences, and an overlay that changes announcements can actively degrade it.

Incorrect ARIA added automatically is worse than no ARIA, because assistive technology trusts it and reports the wrong thing confidently.

Large numbers of disabled people and accessibility practitioners have publicly opposed overlays, which is the part worth weighing most heavily.

An overlay also adds a third-party script with full access to the page, which is a separate cost entirely.

Instant conformance. No script can produce conformance, because most success criteria depend on content and behaviour rather than on runtime markup.

Legal protection. Accessibility obligations are about whether people can use the site, and litigation involving overlay-equipped sites has continued.

One line of code. That part is true, and it is the reason the approach is attractive rather than a reason it works.

Where an overlay is already installed, the honest position is that it neither fixes nor prevents the underlying problems, and the underlying problems are still yours.

Fix the markup: semantic elements, real labels, accessible names, correct headings and landmarks. This benefits every visitor and every consumer.

Run the mechanical checks and fix what they find — `accessibility.image_alt`, `accessibility.contrast`, `accessibility.aria_validity` and the rest are cheap to clear.

Do a keyboard pass and a screen reader pass on the journeys that matter, which is where the criteria no tool can assess actually live.

Respect the visitor's own settings: honour text scaling, do not disable zoom, support reduced-motion preferences.

Budget the overlay's subscription into real remediation instead, which is usually the same order of cost and permanent.