Does an Accessibility Overlay Make Your Website AODA Compliant?

The FTC just fined the overlay industry’s biggest name a million dollars for claiming exactly that — and Ontario’s own accessibility law was never satisfied by a script.

What is an accessibility overlay or widget, exactly?

An accessibility overlay is a snippet of JavaScript you paste into your site’s header, usually from a vendor like accessiBe, UserWay, or AudioEye. Install it, and a little accessibility icon appears in the corner of every page. Visitors can bump up font size, adjust contrast, pause animations, maybe flip on a screen-reader mode. It looks like compliance. It ships in an afternoon.

Here’s what the sales page doesn’t say. The overlay sits on top of your site. It doesn’t touch your code. Your alt text is still missing. Your contrast is still failing. Your custom dropdown is still a keyboard trap. The overlay just wraps a script around the outside and tries to patch the symptoms at runtime. Think of it as makeup over a structural crack — it might look better from ten feet away. The crack is still there.

That distinction, bolt-on script versus an actual code fix, is the whole article. Everything below follows from it.

Does an accessibility overlay make my website AODA compliant?

No. Not partially, not “mostly,” not “good enough for now.” An overlay does not make an Ontario website compliant with the Accessibility for Ontarians with Disabilities Act. Under the Integrated Accessibility Standards Regulation (IASR, O. Reg. 191/11, s.14), a large organization’s public website has to conform to WCAG 2.0 Level AA — not “have a widget installed that says it helps.”

Conformance is measured against the actual code and content a person interacts with: does this image have alt text, does this button have a name a screen reader can announce, can this menu be operated with a keyboard alone. Running a script on top of the page doesn’t change any of those underlying answers. If the code fails a success criterion before the overlay loads, it still fails after. The overlay just adds a floating menu next to the failure.

I’ll be blunt, because a lot of Ontario business owners have been sold the opposite. If you were told a $50-a-month widget gets you to AODA compliance, you were told something that isn’t true.

What did the FTC do to accessiBe, and why does it matter here?

In January 2025 the FTC filed a complaint against accessiBe, and by April 2025 a final order was in place: accessiBe agreed to pay $1,000,000 over claims that its accessWidget product, powered by AI, could make any website compliant with WCAG. The FTC also found the company had disguised paid customer reviews as independent opinions. Full detail is in the FTC’s press release.

Read that claim again. “Make any website compliant.” That’s the exact pitch overlay vendors have used for years, and a U.S. federal regulator just put a million-dollar price tag on it being false advertising. accessiBe isn’t a fringe player either — it’s one of the largest names in the space. If the market leader’s flagship claim didn’t survive regulatory scrutiny, the identical claim from a smaller vendor isn’t more true just because it’s cheaper.

This is a U.S. enforcement action, not a ruling under Ontario law. But the fact it establishes — an automated overlay cannot make a website WCAG-compliant — is the same fact the IASR is built on. It’s about as official a confirmation as you’ll get that the promise on the sales page doesn’t hold up.

Are businesses with an overlay installed still getting sued?

Yes. UsableNet’s 2025 year-end report counted 5,000-plus digital accessibility lawsuits filed in 2025, with e-commerce sites making up roughly 70% of them. That number alone should give any Ontario business pause. But the detail worth sitting with is this: a growing share of those suits targeted sites that had already installed an overlay or widget.

These weren’t businesses that ignored accessibility. They paid for a product marketed specifically to solve the problem, installed it, and got sued or complained about anyway — because the widget sits on top of the same broken code a screen-reader user, or a plaintiff’s expert, still runs straight into. An overlay can’t make a keyboard-trap modal operable. It can’t add alt text a developer never wrote. It can annoy visitors with an unwanted popup, and in a fair number of documented cases, it’s made things worse.

Ontario doesn’t run on U.S.-style ADA litigation, but AODA enforcement is real, and it’s about to get more attention — the reporting deadline lands December 31, 2026. An overlay that didn’t stop U.S. lawsuits isn’t going to satisfy an Ontario director’s compliance review either.

Why can’t a bolted-on script fix accessibility?

Because most accessibility failures live in the underlying markup and interaction logic — the exact layer an overlay never touches. And when an overlay does try to rewrite ARIA (the code labels that tell screen readers what an element is) on the fly, it frequently makes the page worse. Practitioners have a name for the daily grind of contrast checks, keyboard passes, and ARIA cleanup that a script can’t shortcut: a11y. An overlay claiming to automate all of that in one snippet is really claiming to automate a discipline the term itself was built to describe as ongoing, hands-on work — not a checkbox.

Picture what a screen reader actually reads: the HTML. The heading tags, the labels, the roles, the DOM order. An overlay runs a separate script alongside that HTML and tries to guess-patch it at runtime — injecting ARIA attributes, reordering focus, rewriting alt text with automated image recognition. Every one of those guesses can be wrong, and when it’s wrong on a page a blind user is actively navigating, “wrong” isn’t cosmetic. It’s a barrier.

The W3C’s Web Accessibility Initiative, alongside the community-authored Overlay Fact Sheet signed by more than 900 accessibility practitioners and testers (many of them disabled themselves), is blunt about this: automated overlays and widgets cannot achieve full WCAG conformance, because automated tools only catch a minority of accessibility issues in the first place. The rest need a human tester, often using the same assistive technology a real user relies on.

There’s a rule accessibility engineers live by, and it’s baked right into the W3C’s own ARIA Authoring Practices: no ARIA is better than bad ARIA. An unlabeled button is a known, predictable gap. A button with an incorrect ARIA label is actively misleading — the screen reader announces something false with total confidence. That’s the mechanism behind the “overlay made it worse” pattern in the complaint and lawsuit data. Automated relabeling at runtime is exactly the kind of thing that produces bad ARIA at scale.

What’s the AODA-specific risk of relying on an overlay in Ontario?

If your organization has 50 or more employees in Ontario, an overlay leaves your legally required website obligation unmet — and AODA penalties run to $50,000 a day for an individual and $100,000 a day for a corporation.

Walk through the actual law. Under IASR s.14, a large private-sector organization (50+ employees in Ontario) must make its public websites conform to WCAG 2.0 Level AA, full stop, since January 1, 2021. Not “make a good-faith effort.” Not “install something that addresses it.” Conform.

If an inspector, a complaint, or your own compliance-report review turns up an overlay standing in for actual remediation, you haven’t met that obligation. You’ve just deferred discovering that you haven’t. And AODA’s penalties (S.O. 2005, c.11, s.37) aren’t symbolic: an individual can be fined up to $50,000 per day, a corporation up to $100,000 per day, and directors or officers personally up to $50,000 per day, since they carry a duty to take reasonable care to prevent the organization from committing an offence. Offences also cover filing false or misleading information in a compliance report — precisely the position an overlay can quietly put you in if you report your website as accessible because a vendor told you it was.

The compliance report every large organization files by December 31, 2026 is the trigger for enforcement: director follow-up, then orders, then prosecution if it comes to that. It’s a self-reporting system built to catch exactly this kind of gap.

What does real accessibility remediation actually look like?

It’s a code-level audit and fix — a developer going through your actual markup, contrast values, forms, and interactive components and correcting each failure at the source, not a script running on top of them.

Real remediation starts with testing against the WCAG 2.0 AA success criteria your site is legally on the hook for, using both automated scanning and manual testing with a keyboard and a screen reader. Automated tools are a useful first pass, catching a minority of issues, the low-hanging stuff like missing alt attributes or contrast ratios. Everything else — can you tab through this menu, does this form field announce its label, does this modal trap focus correctly when it opens — needs a person actually operating the page the way a disabled visitor would.

Then someone fixes it. Not “adds a workaround.” Fixes it. Missing alt text gets written properly, per image, by someone who looked at the image. Contrast failures get corrected in the actual CSS. Keyboard traps get resolved in the actual component code. Vague “click here” links get real, descriptive text. Broken heading hierarchies get restructured. That’s development work. It isn’t a subscription.

I’ll be straight about where I’m coming from. The Scattergood Foundation migration is the one that sticks with me most here — the accessibility-adjacent work was rebuilding the taxonomy and redirects across a large archive of legacy research publications, where a wrong call would have made real research unfindable, not just ugly. That project, plus the Sportsnet.ca migration and Postmedia’s network of 13-plus newspaper blogs on WordPress VIP, all shared one trait: nobody involved would have accepted “we installed a widget” as the answer to a failed contrast check, because accessibility was checked and signed off before launch, not assumed after the fact. That’s the bar I bring to a Guelph dental clinic’s site too. The scale is different. The standard isn’t.

If you’d rather not decode WCAG success criteria yourself, that’s exactly the kind of remediation work I do — a free scan is one message away: get in touch.

Overlay widget vs real remediation: side by side

Line these up next to each other and the difference stops being abstract. One is a script. The other is engineering.

None of this makes automated tools useless. They’re a fine first pass for triaging where the worst problems sit. The mistake is stopping there and calling it done.

What should you actually do about AODA and your website?

Get an honest audit against WCAG 2.0 AA, fix what it finds at the code level, and treat whatever you’d have spent on an overlay subscription as a down payment on that work instead.

Start by figuring out where you actually stand. If you employ 50 or more people in Ontario, your public website legally has to conform to WCAG 2.0 AA — not optional, and not satisfied by a widget. The complete AODA website accessibility guide ties the whole picture together; the full breakdown of who’s on the hook is in the employee threshold guide; the filing mechanics are in the deadline explainer.

From there, get a real audit: automated scan plus manual keyboard and screen-reader testing, against the failure categories that show up constantly — missing alt text, low color contrast, keyboard traps, unlabeled form fields, vague link text, broken heading structure, ARIA misuse, uncaptioned media. The WCAG 2.0 AA guide walks through each one in plain English with fix examples.

Then fix it in the code. If you’re already planning a redesign, or a move off a platform like Wix or Squarespace, that’s the cheapest possible time to do it — remediation folded into a rebuild costs a fraction of doing it twice, and if that’s your situation the AODA + WordPress guide is worth a read next. That’s exactly the work behind jbe.works web design. Curious where your current site actually stands? The free scan is an automated pass plus a manual keyboard-and-screen-reader spot check of your key pages, back to you within a few days as a plain-English punch list — and real remediation typically costs less than a couple of years of an overlay subscription. A free scan is one message away — get in touch, no widget in the quote.

Frequently asked questions

Quick answers to what Ontario business owners ask most about overlays and AODA.

Does an accessibility overlay make my website AODA compliant?

No. The IASR requires large Ontario organizations to conform their websites to WCAG 2.0 AA at the code level. An overlay runs on top of the code without fixing it, so it doesn’t satisfy that requirement.

What is an accessibility overlay?

A JavaScript snippet from a vendor like accessiBe, UserWay, or AudioEye that adds an on-page menu for font size, contrast, and similar settings. It sits on top of your site and doesn’t change the underlying markup.

Did the FTC really fine an accessibility widget company?

Yes. The FTC ordered accessiBe to pay $1,000,000 in 2025 for falsely claiming its accessWidget product could make any website WCAG-compliant, and for disguising paid reviews as independent.

Can a business still get sued or cited if it has an overlay installed?

Yes. UsableNet’s 2025 report counted 5,000+ digital accessibility lawsuits, and a growing share targeted sites that already had an overlay installed — because the underlying code was still broken.

What’s the difference between an overlay and real accessibility remediation?

An overlay is a script layered on top of your site. Real remediation is a developer testing your actual code against WCAG 2.0 AA and fixing each failure — alt text, contrast, keyboard access, labels, headings — at the source.

Does my Ontario business need to comply with WCAG 2.0 AA?

If you have 50 or more employees in Ontario, yes — your public website must conform to WCAG 2.0 AA under the IASR. Organizations with 20-49 employees file a compliance report but aren’t required to make the site WCAG-conformant; under 20, neither applies.