Do accessibility overlays and widgets work?
What accessibility overlays and widgets can and can't do, why disability advocates criticize them, and what actually makes a website accessible.
Accessibility widgets can do one useful thing well: give visitors controls to change how a site looks, such as bigger text, more spacing or stronger contrast. They can’t fix the code underneath, so problems like missing alt text, unlabeled form fields and keyboard traps stay where they are. No overlay or widget makes a website compliant on its own; fixing and testing your site does the real work.
What is an accessibility overlay?
An overlay is a script you add to your site that loads on top of every page. Most show a floating button that opens a panel of settings. People use “overlay”, “widget” and “toolbar” for the same products, but those products make two very different promises:
- Preference tools. Controls the visitor chooses: text size, line height, letter spacing, contrast, saturation, highlighted links, paused animations.
- Automatic repair. Software that claims to scan your pages and fix accessibility problems by itself, for example by guessing alt text or adding labels, often marketed with talk of artificial intelligence and compliance.
The first is a convenience. The second is where the trouble starts, because it promises a result that the code underneath doesn’t deliver.
What can an accessibility widget actually do?
A good widget lets a visitor adjust your site to suit them without digging through browser settings. That can genuinely help:
- Someone with low vision who wants larger text or higher contrast on one site.
- Someone with dyslexia who reads more easily with extra line height and letter spacing.
- Someone with a vestibular disorder or ADHD who wants animations to stop.
- Someone who finds links hard to spot and wants them highlighted.
Be honest about the limits, though. Many people who rely on these adjustments already have them set up on their own devices: browser zoom, larger system text, high-contrast modes, reduced motion. The European Disability Forum (EDF) and the International Association of Accessibility Professionals (IAAP) point out that “similar features are already available in today’s browsers and devices.” A widget is most useful to people who don’t know those settings exist, and it should never fight with the settings people already use.
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}
What can’t an overlay fix?
An overlay runs in the visitor’s browser after your page has loaded. It can restyle what’s there, but it can’t reliably understand or rewrite what your content means. These problems live in your theme code and your content, and they stay broken for anyone who doesn’t open the widget, including people using their own screen reader:
- Missing or unhelpful alt text. Software can guess that an image shows “a woman in a coat”. It can’t know the coat is the product, what color it is, or why the photo matters. That’s 1.1.1 Non-text Content, Level A.
- Form fields without labels. A newsletter box with only placeholder text needs a real label in the code (3.3.2 Labels or Instructions, Level A).
- Keyboard traps and mouse-only controls. If a menu or pop-up can’t be opened, used or closed with a keyboard, a widget button doesn’t change that (2.1.1 Keyboard, Level A and 2.1.2 No Keyboard Trap, Level A).
- Broken heading structure. Headings chosen for their size rather than their meaning confuse people who navigate by headings (1.3.1 Info and Relationships, Level A).
- Low contrast in your theme colors. A high-contrast toggle helps the people who switch it on. Everyone else still sees your default colors, which need a contrast ratio of at least 4.5:1 for normal text (1.4.3 Contrast (Minimum), Level AA).
Here’s the kind of fix that has to happen in the code. Before:
<input type="email" placeholder="Your email">
<button><svg>...</svg></button>
After:
<label for="newsletter-email">Email address</label>
<input type="email" id="newsletter-email" autocomplete="email">
<button type="submit">Subscribe</button>
The second version tells every visitor, and every screen reader, what the field is for and what the button does. No overlay setting produces that for you.
Why do disability advocates criticize overlays?
The strongest criticism comes from the people overlays claim to help. The Overlay Fact Sheet is an open statement signed by more than a thousand people, including contributors to the WCAG, ARIA and HTML specifications, screen reader developers, lawyers for people with disabilities, and disabled users themselves. It says plainly: “No overlay product on the market can cause a website to become fully compliant with any existing accessibility standard.”
Their main concerns:
- Automatic repair is unreliable. Guessed alt text, guessed labels and patched keyboard support often get things wrong, and the underlying code stays broken.
- Overlays can get in the way. The EDF and IAAP’s 2023 joint statement warns that “the overlay technology can interfere with the user’s assistive technology and override user settings.”
- Privacy. Some overlays try to detect whether a visitor uses a screen reader. As the fact sheet puts it, “disability is sensitive personal information.”
- Compliance claims. The same joint statement says “overlays do not make the website accessible or compliant with European accessibility legislation,” and that they are no substitute for fixing the website itself.
What did the FTC order against accessiBe say?
This is general information, not legal advice.
In January 2025 the US Federal Trade Commission (FTC) announced a proposed order against accessiBe, which sold an overlay called accessWidget. According to the FTC, the company said its automated tool “can make any website compliant with WCAG”, the Web Content Accessibility Guidelines. The FTC said the tool did not make all websites WCAG-compliant, so those claims were false, misleading or unsubstantiated. It also said accessiBe published articles formatted to look like impartial reviews without disclosing its connections to the reviewers.
On 22 April 2025, the Commission approved the final order. accessiBe must pay $1 million, and it is barred from claiming that its automated products can make any website WCAG-compliant, or keep it compliant over time, unless it has evidence to support the claim.
The case was about advertising, not about whether any particular website broke an accessibility law. The lesson for site owners is still simple: be skeptical of any product that promises compliance from one line of code, and ask what it actually changes on your pages.
Will an overlay protect my site from legal complaints?
Don’t count on it. Accessibility laws and standards are about whether people with disabilities can use your site, and an overlay doesn’t change your underlying code. The Overlay Fact Sheet concludes that overlays “cannot eliminate legal risk,” and its reading list includes reports of websites that had overlays installed and still ended up in court. If legal risk worries you, the answer is the same as for usability: fix the barriers, test, and keep a record of what you did.
What does a good approach look like?
- Fix the code and content. Start with the problems that block people: missing alt text, unlabeled fields, keyboard access, contrast and headings. On Shopify most of this lives in your theme settings, product content and apps; the Shopify accessibility checklist goes through it area by area.
- Test. Run an automated audit to catch the obvious failures, then test by hand: use your site with only a keyboard, zoom to 200% and try a screen reader. W3C is clear that evaluation tools “can not determine accessibility, they can only assist in doing so.” Our keyboard accessibility guide shows you how.
- Publish an accessibility statement. Say which standard you aim for, what you know doesn’t work yet and how people can reach you. Here’s how to write one.
- Optionally, offer preference tools. If you add a widget, describe it as what it is: extra controls for visitors who want them. Check that it works with a keyboard and changes nothing until someone asks it to.
Where does CodeInspire Accessibility Tool fit?
Accessibility Helper is published by CodeInspire, which makes a Shopify app called CodeInspire Accessibility Tool. So here’s exactly what it is, in the terms above. It has three parts:
- A shopper widget (free plan). Preference controls grouped by need: font size, contrast and saturation settings, a big cursor, line height, letter spacing, text alignment, highlighted links, muted sounds, stopped animations and hidden images. It remembers each shopper’s choices as they browse. The Pro plan adds a screen reader that reads page text aloud in a chosen voice, which is a convenience for shoppers who like to listen, not a replacement for the screen reader a blind shopper already uses. The widget doesn’t rewrite your theme.
- An audit (Pro plan). It runs Google Lighthouse accessibility checks on your home, product, collection or cart page, on mobile or desktop. Each failing check shows its impact, the WCAG criterion and level, the affected elements, and Shopify fix steps tagged Shopify admin, Theme editor or Theme code. You make the fixes, so they’re in your store for every visitor, whether they open the widget or not.
- An accessibility statement editor with a ready-made statement that shoppers can open from the widget.
The widget alone doesn’t make a store compliant, and neither does the app as a whole. The audit helps you find and fix the issues automated checks can detect; you still need the manual testing above. The app has no AI, and it asks for no Shopify data permissions.
For Shopify stores
Find and fix accessibility issues on your store
CodeInspire Accessibility Tool adds an accessibility widget for your shoppers, audits your pages against WCAG, and gives you step-by-step fixes for your Shopify admin, theme editor or theme code.
Related guides
- Shopify store accessibility checklist
- How to write an accessibility statement
- Keyboard accessibility guide
Frequently asked questions
Can an accessibility widget make my website compliant?
No. A widget adds controls that let visitors change how your site looks, such as text size or contrast. It doesn't change the code underneath, so missing alt text, unlabeled form fields, keyboard traps and similar problems stay in place. Those have to be fixed in the site itself.
Are accessibility overlays bad?
It depends on what they do and what they claim. Preference tools such as text size and spacing controls can help some visitors. Overlays sold as an automatic fix are widely criticized by disabled users and accessibility experts, because they don't fix the code and can interfere with assistive technology such as screen readers.
What was the FTC case against accessiBe about?
In April 2025 the US Federal Trade Commission approved a final order requiring accessiBe to pay $1 million. The FTC said the company's claims that its automated tool could make any website WCAG-compliant were false, misleading or unsubstantiated, and that it presented reviews as independent without disclosing its connections to the reviewers.
Should I remove the accessibility widget from my site?
Not necessarily. If it offers useful preferences, works with a keyboard, doesn't get in the way of screen reader users and isn't described as making your site compliant, it can stay as an extra. Just don't treat it as your accessibility plan. Fixing and testing your site comes first.
Sources
- Overlay Fact Sheet
- European Disability Forum and IAAP: joint statement on accessibility overlays (May 2023)
- FTC: FTC Order Requires Online Marketer to Pay $1 Million for Deceptive Claims that its AI Product Could Make Websites Compliant with Accessibility Guidelines (3 January 2025)
- FTC: FTC Approves Final Order Requiring accessiBe to pay $1 Million (22 April 2025)
- W3C WAI: Selecting Web Accessibility Evaluation Tools
- W3C Technique C39: Using the CSS prefers-reduced-motion query to prevent motion
- Understanding Success Criterion 1.1.1: Non-text Content
- Understanding Success Criterion 1.3.1: Info and Relationships
- Understanding Success Criterion 1.4.3: Contrast (Minimum)
- Understanding Success Criterion 2.1.1: Keyboard
- Understanding Success Criterion 2.1.2: No Keyboard Trap
- Understanding Success Criterion 3.3.2: Labels or Instructions