Accessibility overlay alternatives: what to use instead

If you are weighing an accessibility overlay, or already run one and want to know what else to do, this page sets out the alternative: what actually fixes accessibility problems, how to judge any vendor's claims, and where GotAlt fits. The case itself and the objections disability advocates raise are covered on our page about accessibility overlays and what the FTC found, so this page keeps to the practical side.

What an accessibility overlay is

An accessibility overlay, also called a widget or toolbar, is third-party code, typically JavaScript, added to a site to change how it behaves for visitors. The Overlay Fact Sheet, a statement by accessibility practitioners, says its repairs are "applied when the page loads in the user's browser."

The appeal is speed: one script tag instead of changes to the site. This page covers what that trade gives up and what to do instead. What an overlay can and cannot change is set out on accessibility overlays and what the FTC found, and the vocabulary is in the glossary entry for accessibility overlay.

What the FTC order says

The Federal Trade Commission issued its Decision and Order against accessiBe Inc. and accessiBe Ltd. in Docket C-4817 on April 21, 2025; the FTC press release is dated April 22, 2025. It is a consent order: the respondents neither admitted nor denied the allegations in the complaint, and admitted only the facts needed to establish jurisdiction. The Decision and Order requires accessiBe to:

• Avoid unsupported WCAG claims. It must not represent that its product can make any website compliant with WCAG, or can ensure continued automatic compliance with WCAG over time as website content changes, unless it possesses and relies on "competent and reliable evidence" sufficient to substantiate the claim (Part I).
• Be accurate about reviews. It must not misrepresent third-party reviews or endorsements as independent, and must disclose unexpected material connections to endorsers (Parts III and IV).
• Disclose a limit before payment. When it says its product can correct accessibility barriers on a website, it must first disclose, before a customer incurs any financial obligation, that the product will not correct barriers on third-party domains or subdomains that may be part of the overall user experience, unless those domains also use the product (Part V).
• Pay $1,000,000 to the Commission (Part VI).

The order binds one named vendor's claims. It does not ban overlays. It is a clear public example of a regulator asking what evidence sits behind a claim that a product makes a site compliant. This page is general information, not legal advice; a lawyer who handles accessibility law can advise on a specific dispute or deadline.

What the Overlay Fact Sheet argues

By its own account, the fact sheet's signatories include contributors and editors for the WCAG, ARIA and HTML specifications, consultants in many countries, in-house accessibility experts at companies and universities, lawyers for the disabled, contributors to assistive technology software and many end users with disabilities. It also says some overlay vendors have tried to frame it as an effort by their competitors to discredit them. Its arguments, in summary:

• Widgets. It argues that overlay widgets are unnecessary and poorly placed in the technology stack, because visitors who need larger text or different colors already have those features on their own devices.
• Automated repair. It says customers "should be discouraged from using an overlay as a long-term solution." It describes automated repair of image text alternatives, form labels, error handling, focus control and keyboard access as not reliable, says component-based interfaces can change the page independently of the overlay, and says repairs can slow page loads or cause unexpected changes for assistive technology users. It adds that overlays do not repair PDF, canvas, SVG or media files.
• Compliance and legal risk. It states that "full compliance cannot be achieved with an overlay." Its conclusion is that no overlay product on the market "can cause a website to become fully compliant with any existing accessibility standard" and therefore "cannot eliminate legal risk."
• Privacy. It argues that overlays which detect assistive technology can reveal that a visitor has a disability, and that overlays which store visitors' settings across sites with a cookie create GDPR and CCPA risk for the site owner.

Read it as what it is: a position statement from people who work in this field, not a controlled test of every product. Practitioner opinion points the same way. In WebAIM's third Survey of Web Accessibility Practitioners, published March 24, 2021 with 758 valid responses, 67% of respondents rated web accessibility overlays, plugins or widgets as not at all or not very effective, and respondents with disabilities were less favorable still at 72%. That is opinion, and it dates from 2021; it measures what practitioners think, not how a given product performs.

What actually fixes accessibility

Four kinds of work fix accessibility problems and keep them fixed. W3C's planning guidance describes the aim as integrating accessibility throughout the web production process, on individual projects and across an organization. None of the four is a product you switch on.

1. Fix the source

Source means the HTML, CSS, scripts, templates, design system and content your server sends. A fix there is part of the page every visitor, browser and assistive technology receives. The table maps the six most common errors found by WebAIM's analysis of one million home pages to the place where the permanent fix lives.

Figures are from the WebAIM Million, which reports that 96% of all errors it detected fall into these six categories. Our guide to the most common accessibility errors explains each fix.

A small example shows the difference. An icon-only close button has no accessible name. The permanent fix is one attribute in the component:

<!-- Before: no accessible name -->
<button class="close">
  <svg aria-hidden="true">...</svg>
</button>

<!-- After: fixed once, in the component -->
<button class="close" aria-label="Close dialog">
  <svg aria-hidden="true">...</svg>
</button>

A script that guesses a name from an icon or nearby text can guess wrong. The Overlay Fact Sheet lists automated application of image text alternatives and automated repair of form field labels as not reliable. The fix in the component is exact, and it applies on every page that uses the component. If you build on a platform, the guides for Shopify and WordPress show where these fixes live in each.

2. Test with tools and with people

W3C says that "no tool alone can determine if a site meets accessibility standards" and that knowledgeable human evaluation is required (W3C, Evaluating Web Accessibility). Use tools for what machines can find, then test the rest yourself:

• Scan. The free scan runs 16 rule-based checks on the HTML your server sends, on up to three pages. The accessibility bookmarklet checks the page open in your own browser.
• Use the page with a keyboard, zoom and a screen reader. The 5-minute keyboard test is the quickest start, and the guide to testing website accessibility covers the rest.
• Know what tools miss. See what automated testing can and cannot check and why rule-based scanners miss issues.

3. Monitor every release

Accessibility regresses when someone uploads an image with no alt text or ships a template change. W3C's guidance tells organizations to "continue to review and report on content, processes, and resources." Monitoring means re-checking on a schedule or on each release, with an alert when something that passed starts to fail. GotAlt's paid plans check every monitored page weekly, re-run the image audit when a page's images or their alt text change, and send regression alerts when a deploy breaks something that used to pass. See pricing.

4. Train the people who publish

Some failures start in content rather than code: a photo uploaded with no description, a PDF attached without tags, a button labeled with an icon alone. W3C's guidance says to "ensure personnel are trained, tools are available, and accessibility is included throughout." A short publishing checklist and a shared understanding of what web accessibility is keep the same errors from returning.

Who does the work: your options

Fixing the source still needs someone to do it. These are the usual routes, and most sites combine several of them.

Moving off an overlay: a sensible order

1. Record where you stand. Run the free scan, which reads the HTML your server sends before any script runs, and the bookmarklet, which checks the page as your browser renders it. Keep both reports.
2. Fix the source. Work through the findings in the HTML, templates and content, starting with the highest severity.
3. Test the key journeys yourself. Navigate with only a keyboard, zoom the page and try a screen reader on your main pages and checkout or contact forms.
4. Turn the overlay off on a staging copy, if your vendor allows it, and repeat steps 1 and 3. This shows whether the source holds up without the script.
5. Check the contract. Look at the cancellation terms, then remove the script from production once the source holds up.
6. Publish an accurate accessibility statement. Describe what you tested and what is still open. Do not describe the site as compliant.
7. Monitor. Re-check after releases so fixes do not quietly regress.

If you received a demand letter, talk to a lawyer first; our guide to the ADA website demand letter sets out a calm order of work and explains why fixing the code beats adding a widget.

Questions to ask any accessibility vendor

These questions work for an overlay, a scanner, a consultancy or GotAlt. The right-hand column shows where each one comes from.

Where GotAlt fits

GotAlt is not an overlay. It adds no widget and no script to your site and does not change your live pages. It reads your site and reports what is wrong, and where it cannot see, it says so.

• Free scan. 16 rule-based checks on the HTML your server sends, on up to three pages, each mapped to a WCAG success criterion. The methodology page lists every check.
• Deep audit. It downloads the image files and compares each with its alt text using a vision model, to check whether the description is true. It opens up to six images per page; the rule checks still cover every image. The free tier allows one deep audit a day. See the deep audit and a sample report on a deliberately broken page.
• Free tools. The alt text checker (free with an email address, one check a day), contrast checker, image contrast checker, heading checker, link text checker, PDF accessibility checker and statement generator.
• Monitoring. Paid plans check monitored pages weekly and alert on regressions, priced by the number of pages monitored and starting from $69/mo. See pricing.

The limits are stated, too. Automated checks cover part of WCAG. Our methodology page lists what we cannot see, including keyboard traps, focus order, screen reader behavior, reading order, rendered color contrast and content added by JavaScript after load. No score from GotAlt or from anyone else means a site meets WCAG, the EAA, the ADA or any other law.