Overlays & Alternatives

Why Accessibility Overlays Fail (and What Code-Level Remediation Actually Looks Like)

Last updated May 24, 2026

Accessibility overlays are third-party JavaScript widgets that load on top of an existing website and claim to detect and remediate accessibility barriers without changes to the underlying source code. The two-line elevator answer is that they do not work the way they are marketed, and regulators have started saying so on the record. On April 22, 2025, the FTC approved a final consent order requiring accessiBe to pay $1 million, barring accessiBe from representing that its automated products can make any website WCAG-compliant or can ensure continued compliance with WCAG over time, unless it has the evidence to support such claims (see the FTC press release announcing the final order and the FTC's companion business-guidance post). That sentence is the verbatim text every operator considering an overlay should read twice.

The litigation environment tells the same story. Per UsableNet's 2024 Year-End Report, 25% of 2024 ADA web-accessibility lawsuits cited an accessibility widget or overlay as a barrier rather than a solution; 67% of suits targeted companies with under $25M annual revenue (full report at UsableNet's research blog). In other words, plaintiffs are not just unimpressed by overlays; they are pointing to the overlay itself in pleadings as evidence that the defendant's site is inaccessible. Installing an overlay after a demand letter has become a recognized fact pattern, not a mitigating one.

Mechanically, the limit is simple. An overlay is a script that runs after the page has loaded. By the time it executes, screen readers, switch controls, voice-input drivers, and the browser's accessibility tree have already built a representation of the page from the original DOM. Patching attributes after the fact does not retroactively repair what assistive technology already announced, and on every subsequent navigation, route change, or interactive update the patches have to fire again, with the same race condition and the same risk of breaking the very behavior they tried to repair. There are 800+ signatories from the disability and accessibility community on the Overlay Fact Sheet who have documented this pattern in detail, and Adrian Roselli has maintained an extensive archive of specific failure modes for years.

The honest path is code-level remediation: fixes in source, in version control, in a tested release, plus a public accessibility statement and recurring monitoring. That is the model SweepHound is built around, and the rest of this page explains in detail what overlays mechanically can and cannot do, what the FTC order actually says, what the lawsuit data shows, and what good remediation looks like from a code review perspective.

What an “overlay” is, mechanically

When vendors talk about an “accessibility overlay,” “widget,” or “AI accessibility solution,” they are almost always describing the same architecture: a single line of third-party JavaScript that you paste into the head or footer of your pages. When the page loads, that script downloads additional code from the vendor's servers, attaches a visible toolbar to the corner of the viewport, and runs a set of automated checks against the DOM. Some products stop at the toolbar. Others attempt to mutate the DOM after the fact, adding ARIA attributes, rewriting role values, injecting alt-text guesses, and inserting landmark elements that they think were missing.

Three things follow from that architecture. First, the overlay is downstream of every other script on the page, so anything it tries to fix has already been observed by users of assistive technology and by automated crawlers. Second, the overlay's mutations are ephemeral. They live in the rendered DOM of one browser session; they are not committed to source. View source on the page after installing the widget and you still see the same missing labels and broken headings the engineering team checked into the repository. Third, the overlay is a single point of failure: if the vendor's CDN is slow, blocked by an ad blocker, or rate limited, the “fix” never loads and you are back to the original page, with the additional liability that you told customers the site was accessible.

What overlays can and cannot do

To be precise about the limit: overlays are not useless at everything. Some of the user-facing controls they expose are conceptually fine, just better implemented as native preferences in your own codebase. Where overlays consistently break down is in any claim involving the accessibility tree, the DOM contract, or assistive-technology compatibility — which is most of WCAG.

Things an overlay can plausibly do as a presentational layer for sighted users:

• Increase or decrease text size by scaling root font size, similar to a browser zoom control.
• Apply a high-contrast or inverted color scheme by injecting CSS variables.
• Swap the body font for a so-called dyslexia-friendly typeface, with the well-documented caveat that the research evidence for those typefaces being measurably better than a clean sans-serif is thin and contested.
• Add a cursor magnifier or reading guide rule that follows the mouse.
• Pause CSS animations and disable autoplaying video by removing the relevant attributes.

Things an overlay cannot reliably do, because the failure is rooted in the source DOM and the accessibility tree that was built from it:

• Fix missing form labels for screen-reader users in a stable way. Guessing a label from nearby text is unreliable, and the inferred label can change between visits, breaking the user's memory of how the form is announced.
• Repair heading structure. The visual order of headings, their level, and their relationship to landmarks is a structural property of the document. Overlays that try to insert h1/h2 elements or rewrite role values routinely produce duplicate landmarks and announce nonsense to screen readers.
• Fix keyboard traps that originate in source. If a modal's focus management is broken because it does not return focus to the trigger element, an overlay cannot reach into that component's state machine and rewrite it.
• Repair focus order. tabindexvalues, DOM ordering, and dynamically inserted regions interact in ways an overlay cannot model without knowing the component's intent.
• Announce dynamic content correctly. Live regions, status messages, and ARIA aria-live semantics depend on the content existing in the right container at the right time. By the time an overlay notices, the moment to announce has passed.
• Provide meaningful alt text. Image-classification models can guess that a picture contains a dog; they cannot tell you that this specific dog is the brand's mascot or that the photo is decorative and should be empty-alt. See writing accessible alt text for why intent matters more than recognition.
• Fix color contrast without breaking brand and design intent across the entire site. A blanket recolor that boosts contrast on one button is likely to wreck contrast somewhere else.

For a deeper look at this gap between what tools can detect and what they can repair, see what automated scanners miss. The same logic applies in reverse to overlays: their detection surface is bounded, and the actions they can take on what they do detect are even more bounded.

The FTC v. accessiBe case, in plain English

The FTC's complaint against accessiBe alleged that the company made unsubstantiated representations to merchants and the public: that its automated product could make any website WCAG-compliant, that customers could rely on it for ongoing compliance, and that favorable third-party reviews were independent opinions when in fact the company had material connections to the reviewers. That last piece — the deceptive endorsement angle — is a separate count, but the part of the order with the longest half-life for the entire overlay category is the substantiation requirement on the underlying accessibility claim.

Read the operative line again, slowly: on April 22, 2025, the FTC approved a final consent order requiring accessiBe to pay $1 million, barring accessiBe from representing that its automated products can make any website WCAG-compliant or can ensure continued compliance with WCAG over time, unless it has the evidence to support such claims. The structure is important. The FTC did not declare that overlays are illegal. It declared that an overlay vendor cannot keep advertising automated WCAG compliance without producing the evidence to back the advertising up — and the Commission's acceptance of the consent package means the agency was not satisfied with the evidence accessiBe had on file.

The implications for similar vendors are not hard to extrapolate. If your marketing copy promises automated WCAG compliance, the template for an FTC inquiry has now been written. Adrian Roselli's post FTC Catches up to #accessiBe walks through the proposed-order period in early 2025 and is worth reading for context on how long the underlying claims had been challenged before the agency stepped in.

The lawsuit data

The number that matters most to operators is UsableNet's finding from its 2024 Year-End Report: 25% of 2024 ADA web-accessibility lawsuits cited an accessibility widget or overlay as a barrier rather than a solution; 67% of suits targeted companies with under $25M annual revenue. Those are not separate phenomena. Smaller companies are disproportionately the audience for “one line of code” pitches, and they are disproportionately the defendants when those pitches do not hold up in court.

There is a pattern operators report repeatedly to counsel and to accessibility consultants: a company receives a demand letter, panics, and installs an overlay within days, believing it has neutralized the legal exposure. The subsequent complaint then quotes the overlay's presence on the page as itself evidence of an inaccessible site — either because plaintiffs argue the overlay's own controls are inaccessible, or because the underlying barriers cited in the original demand letter remain unfixed in source. Installing the widget did not remediate the barriers; it added a second product whose accessibility now also has to be defended.

For the procedural side — what an actual demand letter looks like, who tends to send them, and how to triage one without panic-installing third-party JavaScript — see the ADA website demand letter playbook. The companion page on the AccessiBe alternative covers what a code-led remediation workflow looks like in concrete terms.

What code-level remediation looks like

Code-level remediation is what it sounds like: fixes that live in your repository, are reviewed in pull requests, are tested in CI, and ship through the same release process as every other change to your site. There is no script tag that has to load. The fix survives whether or not the user has JavaScript enabled, whether or not an ad blocker is filtering third-party domains, and whether or not the vendor's CDN is reachable from a particular assistive-technology user's network.

A defensible remediation program has four moving parts:

• Source-code commits. Each remediation lives in version control with a description that ties the change to a specific WCAG success criterion. When counsel needs to demonstrate good-faith remediation, the commit history is the artifact.
• A written accessibility statement. A real page on the site that says which standard you target (typically WCAG 2.2 AA), known limitations, the date it was last reviewed, and a contact channel for users to report issues.
• Recurring automated monitoring. Regressions creep in with every new content publish, every new third-party widget, and every theme update. A scan that runs on a schedule catches the easy regressions before they become litigation surface.
• Manual testing on a cadence. Keyboard-only walkthroughs of your primary user flows, screen reader spot-checks, and review of any newly shipped components against the accessibility testing checklist.

SweepHound is built around this model. The scanner runs a deterministic-first remediation engine: for mechanical fixes such as a missing alt attribute on a known logo, a duplicated id reference, or a button rendered as a div, the engine generates the corrected snippet directly. For ambiguous cases — where the correct fix depends on intent, context, or content the page cannot infer — the engine falls back to an explanation rather than inventing a fix it cannot defend. That is the honest version of “AI-assisted accessibility”: deterministic where the answer is mechanical, explanatory where it is not, and never a script tag that pretends the problem is solved.

Find out what is in your site's DOM today. Try SweepHound's free scan to run an automated WCAG scan with code-level remediation guidance, then ship the fixes through your normal release process.

When (if ever) is an overlay-like feature acceptable?

The category of “user preference toggles, built natively into your own application” is a different category from third-party overlays. There is nothing wrong with shipping a text-size control, a high-contrast theme, a reduced-motion toggle (which the platform already exposes through the prefers-reduced-motionmedia query), or a plain-language summary mode. These features can live in your own codebase, be tested in CI, and respect the platform's own accessibility settings. They are not what the Overlay Fact Sheet and the FTC are warning about.

The distinction worth keeping in mind is whether the feature is your code, applied to your DOM, on your release cadence, with your test coverage. If yes, it is a product feature. If the feature is a third-party script that mutates your DOM at runtime based on heuristics you cannot inspect, it is an overlay, and the failure modes documented on the Overlay Fact Sheet apply.

How to evaluate any overlay vendor honestly

If a vendor is in front of you with an overlay pitch, the following questions are diagnostic. None are gotchas; they are things the vendor should be able to answer in writing.

• What specific WCAG success criteria do you claim to remediate automatically, and what is your evidence base? Per the FTC order, “our AI handles WCAG” is no longer a sufficient answer for a vendor in this category.
• What do your automated fixes look like in the DOM after the overlay runs? Ask for a before/after diff of the accessibility tree, not a marketing screenshot of your toolbar.
• What happens to your fixes when the overlay's script fails to load — ad blocker, network failure, CSP violation, slow CDN region? Does the page degrade to its original (unremediated) DOM, and if so, what is your customer's disclosed obligation?
• What is your published response to the Overlay Fact Sheet, and do you have public, named accessibility practitioners (preferably IAAP-certified) on staff who will go on record defending your approach?
• Has your product been cited as a barrier in any active accessibility lawsuit? Can you provide a list?
• Will you contractually indemnify your customer if your product is cited as a barrier in a future ADA suit, given the FTC order?

The point of those questions is not to embarrass anyone. The point is that an overlay vendor that can answer them in writing has actually done the engineering and legal work to defend the product. A vendor that deflects has not, and after April 2025 the regulatory cost of deflection has gone up.

How SweepHound's dual-engine scan and code-level remediation works

The honest version of the SweepHound pitch: we run two open accessibility engines against your pages, axe-core and IBM Equal Access (both available on every paid plan), to get better coverage than either engine alone. We group the findings by rule and surface them as triageable issues rather than a flat list of violations. For each issue, the remediation engine tries to produce a deterministic code-level fix where the answer is mechanical, and falls back to an explanation when it is not.

We do not claim the scan is exhaustive. Per Deque's Automated Accessibility Coverage Report, Deque reported automated tests identified 57.38% of issue instances by volume in its dataset — based on 2,000+ audits across 13,000+ pages and ~300K issues (see Deque's coverage report). That is a real ceiling and we do not pretend the other 42% does not exist. What SweepHound automates is the part that can be honestly automated: detection of mechanical violations, code-level fix suggestions for the subset of those that are unambiguous, and a queue of explained findings that need human judgment. The rest of the work — intent on alt text, keyboard flow review, screen reader spot-checks — is human work, and we say so.

What that looks like in your release process: you run a scan, get a report, file the deterministic fixes as commits, get explanations for the ambiguous ones, ship them through CI, and re-scan. There is no third-party script tag in your production HTML. There is no overlay toolbar in the corner of your customers' screens. There is a remediation history in version control that you can hand to counsel if you ever need to. That is the entire model.

If you want to see what code-level remediation looks like applied to your own site, the free scan will produce a report you can read in ten minutes, and pricing covers what you get at each plan level — including when the dual-engine scan and recurring monitoring are available.