Accessibility overlay vs fixing your code (and what the FTC said)

Updated 2026-10-24 · Altlark guides

An accessibility overlay is a script you add to your site, usually with one line of code, that loads a toolbar or widget and tries to change the page in the visitor's browser: adding labels, adjusting contrast, offering text resizing and similar features. They're often sold as a quick way to handle accessibility without touching your site's code.

Fixing your code means changing the HTML, CSS and JavaScript your site actually sends, so the page works with the assistive technology people already use. This guide compares the two, summarizes what the U.S. Federal Trade Commission said in its 2025 action against one overlay vendor, and gives a checklist for evaluating any tool's claims, including ours.

What the FTC said about accessiBe

In January 2025 the FTC announced a proposed order (see the case page) requiring accessiBe to pay $1 million to settle allegations about its AI-powered tool, accessWidget. On April 22, 2025 the Commission approved the final order. According to the FTC's press release:

• accessiBe had claimed accessWidget could make any website meet the Web Content Accessibility Guidelines (WCAG).
• The FTC's complaint alleged that accessWidget did not make all user websites meet WCAG, and that these claims were false, misleading or unsubstantiated.
• The complaint also alleged that accessiBe formatted third-party articles and reviews to look like independent opinions, and didn't disclose its material connections to supposedly objective reviewers.
• The final order bars accessiBe from representing that its automated products can make any website meet WCAG, or can keep a site meeting WCAG over time, unless it has evidence to support such claims. It also bars misrepresenting reviews and endorsements as independent.
• The Commission voted 3-0 to approve the final order.

The order is about one company's marketing claims. It doesn't rule on overlays as a category. But it's a clear signal that "install this script and you're done" is a claim regulators will ask companies to back up. More detail is on the FTC's case page.

What an overlay can and can't change

An overlay runs in the browser after your page loads. It can modify the page it finds, but it has to guess at intent:

• It can guess, not know. To name an icon-only button, a script has to infer what the button does. It might get "Search" right and "Open the loyalty drawer" wrong.
• It doesn't change your source. The underlying HTML is the same, so any tool or crawler that reads the page without running the overlay sees the original issues. Altlark, for example, reads server HTML and will still report them.
• It adds its own interface. A toolbar is more content for keyboard and screen-reader users to navigate, and it needs to be accessible itself.
• It may conflict with assistive technology. Screen readers, magnifiers and voice control already provide many features overlays offer (text size, reading aloud, contrast). Two layers trying to do the same thing can clash.

Some personalization features, like a reading-font toggle, can be genuinely helpful as an extra. The question is whether they're used as a supplement to an accessible site or as a substitute for one.

What fixing the code looks like

Most issues automated tools find are small, specific changes in templates:

<a href="/cart"><i class="icon-cart"></i></a>
<input type="email" placeholder="Email">
<html>

<a href="/cart" aria-label="Cart"><i class="icon-cart" aria-hidden="true"></i></a>
<label for="email">Email</label> <input type="email" id="email">
<html lang="en">

These fixes are permanent, work in every browser and with every assistive technology, don't depend on a third-party script loading, and don't add page weight. Because they're usually in shared templates (header, footer, product card, form partials), a handful of edits can clear hundreds of instances across a site.

The harder parts, like keyboard navigation in custom menus, focus management in modals, color contrast in a brand palette and captions, also need changes to your code and content. No script can write your captions.

Side by side

• Where the fix lives: overlay, in a third-party script at runtime; code fix, in your own source.
• Who decides what an element means: overlay, an algorithm guessing; code fix, the people who built the page.
• Effect on other tools and crawlers: overlay, usually none; code fix, everyone sees the fixed HTML.
• Ongoing cost: overlay, a subscription for as long as you use it; code fix, the initial work plus keeping new content and features accessible.
• What you can verify: overlay, depends on the vendor's evidence; code fix, you can test the HTML directly, with automated checks and by hand.

How to evaluate any accessibility tool's claims

Whatever you're considering, overlays, scanners (including Altlark) or audit services, ask:

1. What exactly does it check or change? A list of specific checks or specific changes is a good sign.
2. What doesn't it cover? An honest tool says. Automated testing covers only part of WCAG.
3. Does it promise an outcome? Be wary of any tool that promises your site will meet a law or standard automatically, or that it will protect you legally. No automated tool can make that promise honestly.
4. Are the reviews independent? The FTC's accessiBe complaint involved reviews that weren't.
5. Can you verify it yourself? Try a screen reader and the keyboard on your own key tasks before and after.

What Altlark is (and isn't)

Altlark is a scanner, not an overlay. It doesn't change your site. It reads your pages' HTML, lists specific issues with the element and the WCAG criterion, and suggests the code fix. The free scan is one page; monitoring rescans daily and alerts you when new issues appear. Like every automated tool, it finds some, not all, issues, and its reports aren't legal advice or a certification.