Accessibility Overlay Widgets Do Not Make Your Website Compliant

Every accessibility overlay widget sold to Irish businesses over the past couple of years has made the same promise: paste one line of JavaScript into your site, and you are compliant with the European Accessibility Act. It is exactly the fix a business owner with no development budget wants to hear. I have already come across customers who installed one of these ahead of last June's deadline, satisfied the job was done, only to find their booking form still could not be operated by keyboard alone. It was not done. The US Federal Trade Commission has since fined the largest vendor in this industry a million dollars for making that precise claim.

What the European Accessibility Act Actually Asks For

The European Accessibility Act came into force on 28 June 2025. According to the European Commission's own AccessibleEU centre, it requires accessibility across a broad range of products and services, including websites and mobile apps, not just physical products ^[1]. E-commerce, banking, transport booking and digital content services sit squarely in scope, and Ireland's transposing rules carry real financial penalties for non-compliance, not a stern letter and nothing more.

Some obligations narrow for microenterprises, businesses under 10 staff and under €2 million turnover, but that exemption is limited and does not apply across the board. "Microenterprise" is a legal threshold, not a synonym for "small business." A five-person consultancy that takes online bookings and a two-person shop selling physical goods online can land on different sides of that line depending on turnover and exactly which service is being assessed.

So what does compliance actually mean day to day? Not abstract legal wording. It means a customer using a screen reader can navigate your menu, read your product descriptions, and get through your checkout or booking form without getting stuck partway. That is the real bar. Everything else is detail sitting underneath it.

The One-Line Fix Every Widget Vendor Promises

The pitch is consistent across the whole overlay category. Add a script tag, and an AI-powered layer scans your page, injects a floating accessibility menu with font size and contrast toggles, and quietly patches whatever it finds broken behind the scenes. No developer, no rebuild, no waiting. For a business staring down a June deadline with a website nobody on staff can actually edit, that pitch is close to irresistible.

We see this pattern repeat with service businesses that take bookings online, and it usually plays out the same way. Picture a physiotherapy clinic in Mullingar whose online booking form went live years before anyone thought about accessibility. A prospective patient using a screen reader emails to say she cannot find out which time slots are free. The practice manager, working from a list of quick fixes a supplier recommended, installs an overlay widget that afternoon and considers the matter closed. Months later, a solicitor's letter arrives. The booking form itself never changed. Neither did the outcome for the next screen reader user who tries it.

Why the Fix Sits on Top of the Problem, Not Underneath It

The technical reason that story keeps repeating comes down to how these tools are built. An overlay widget runs as JavaScript that executes after your page has already loaded in the browser. It reads the rendered page, guesses at fixes, and applies them as a layer sitting above your actual markup. If a form field was never associated with its label in the underlying code, the overlay might attempt to guess the association at runtime. It does not always guess correctly, and plenty of screen readers and assistive technologies do not process the overlay's patches the way a sighted user's browser does.

That single design choice is the whole problem. The production environment a customer actually lands on is still built from the same broken HTML it always was. Turn off JavaScript, block the script with an ad blocker, or use assistive technology that reads the DOM directly rather than the rendered visual layer, and the barrier the widget claimed to fix is exactly where it started. A booking form that was never keyboard-navigable does not become keyboard-navigable because a floating menu now sits in the corner of the screen.

It is the same shape of false confidence we see elsewhere in WordPress operations, where proper security and backup practice means changing what actually runs on the server rather than adding a layer that looks reassuring on the surface. A backup plugin nobody has tested restoring from gives the same hollow comfort as a widget nobody has tested with an actual screen reader.

The FTC Fined the Biggest Vendor in the Industry Over This Exact Claim

This is not a minority opinion inside the accessibility profession anymore. In April 2025 the FTC approved a final order against accessiBe, one of the largest overlay vendors, requiring the company to pay $1 million over claims that its widget made websites WCAG-compliant ^[2]. The regulator's own finding was blunt: the tool did not make the basic components of a page, menus, headings, tables, images, accessible, and the marketing claims that it did were false, misleading or unsubstantiated.

That finding lines up with what the accessibility profession itself has been saying for years. The Overlay Fact Sheet, a public statement now signed by more than 800 accessibility practitioners, including contributors to the WCAG and ARIA specifications and internal accessibility staff at companies like Microsoft and Google, states plainly that overlays permit only temporary, cosmetic changes and do not repair the underlying accessibility problems in a site's source code ^[3]. Courts examining these tools in litigation have, on the whole, not treated their presence as evidence of compliance.

None of that is proof of what will happen in an Irish or EU court under the EAA specifically, the case law there is still developing, but the technical objection is identical regardless of which country's regulator is asking the question. It follows a similar shape to the EU's newer vulnerability disclosure rules for WordPress businesses: a legal obligation that lands on the business itself and cannot be handed off to a single bolt-on tool.

What "Accessibility Ready" Does Not Mean Either

Worth a caveat here, because WordPress has its own version of a shortcut that gets oversold. The WordPress.org theme directory carries an "Accessibility Ready" tag for themes that pass a manual review by the Theme Review team against a set of WCAG-derived requirements ^[4]. It is a genuinely useful filter when choosing a theme. It is also explicitly not the same thing as WCAG AA compliance. WordPress.org's own documentation is clear that the tag means a theme clears the review team's minimum bar, not that it satisfies the full WCAG 2.1 AA standard on its own. An accessible theme is a strong starting point. It is not a finish line, any more than an overlay widget is.

What Actually Closes the Gap

Real accessibility work is less exciting than a one-line script tag, and it is also the only approach that survives contact with an actual screen reader user. It comes down to three things: an accessible theme as your foundation, correct markup and content on the pages that matter most, and someone actually checking the result on your highest-risk flows, typically your booking form, checkout, or contact form.

Approach	Fixes underlying markup?	Verified by real assistive tech?	Ongoing cost
Overlay widget	No	No	Monthly subscription
Accessibility-ready theme + manual fixes	Yes, on pages you correct	Partially, without a dedicated check	One-time or occasional
Accessible theme + manual fixes + screen reader audit	Yes	Yes	One-time, repeated after major changes

Because Web60's WordPress hosting gives every customer full access to the platform's entire plugin and theme ecosystem from day one, none of this work is locked behind a developer relationship or a walled-garden builder that only lets you tweak colours. You can install an accessibility-ready theme, correct heading structure and alt text yourself in the dashboard, and deploy the changes to a staging environment first to verify nothing else broke before it goes live. That last step matters more than it sounds. A rushed accessibility fix that quietly breaks your checkout is not a win.

Start with your highest-traffic, highest-risk pages rather than trying to fix the whole site at once: your booking or contact form, your product or service pages, and anywhere a customer hands over payment details. Those are the pages an assistive technology user is most likely to need and most likely to abandon your site over if they cannot get through.

The Honest Limit of Doing This Yourself

One thing worth being straight about: an accessible theme and a careful pass through your own content will not catch everything a trained auditor would. A form error message that displays visually but is never announced to a screen reader, or a pop-up that traps keyboard focus so a user cannot tab back out, are the kind of conflict that a DIY pass regularly misses.

If your business handles bookings, payments, or account log-ins, it is worth budgeting for a proper screen reader walkthrough of those specific flows, not just running an automated scanner and calling the job finished. Automated scanners catch somewhere between a third and a little over half of WCAG issues depending on the tool and how strictly it counts, and the gap is exactly the kind of thing that needs a person to actually try using the page the way a real customer would.

To be fair to the overlay vendors, an automated widget is not always pure theatre. For a business with a genuinely enormous back-catalogue of static pages and no realistic budget this month, it can function as a stop-gap that improves things marginally for some users, provided the owner understands it buys time rather than closing the case. The mistake is treating it as the finish line rather than a placeholder.

Conclusion

The European Accessibility Act does not care what is bolted onto your page after it loads. It cares whether a real customer using a screen reader, a keyboard, or a switch device can actually book, buy, or get in touch. That bar gets met in the code and content of your site, not in a floating widget menu, and it gets met by working through your highest-risk pages first rather than chasing a single subscription that promises to handle everything at once. Start with the form your customers actually rely on.

Frequently Asked Questions

Does installing an accessibility overlay widget satisfy the European Accessibility Act?

No. An overlay widget changes what a page looks like after it loads in the browser, not the underlying HTML. The European Accessibility Act is measured against how a real assistive technology user experiences your site, and the Overlay Fact Sheet, signed by hundreds of accessibility professionals, is explicit that overlays cannot repair broken markup. Several widget vendors have faced legal action over compliance claims that did not hold up.

What accessibility standard does the European Accessibility Act actually reference?

The EAA points to the WCAG 2.1 Level AA guidelines as its working benchmark. That covers things like keyboard navigation, sufficient colour contrast, properly labelled form fields, and alt text on meaningful images. It is a code-level and content-level standard, not a JavaScript layer bolted on top of a page.

Is my small business exempt from the EAA?

Some obligations narrow for microenterprises, businesses with fewer than 10 staff and under 2 million euro turnover, but the exemption is limited and does not apply across the board. Plenty of businesses that think of themselves as small do not meet the legal definition. Do not assume exemption without checking your specific situation against the regulation, ideally with a solicitor if your business sells online or takes bookings.

Can WordPress plugins alone make my website accessible?

They get you most of the way. An accessibility-focused WordPress theme combined with sensible use of alt text, heading structure, and form labelling closes the majority of common issues. But WordPress.org's own accessibility-ready tag is explicit that passing that review does not mean a theme meets WCAG AA on its own. Plugins reduce the manual work; they do not remove the need for someone to check the result.

What happens if I do nothing about website accessibility?

You risk two separate problems. Legally, you carry exposure under the EAA if your business and services are in scope, with penalties that vary by member state. Commercially, you lose customers who use assistive technology and simply cannot complete a booking or a purchase on your site, often without ever telling you why they left.

How much does it cost to fix accessibility properly compared to an overlay widget?

An overlay subscription is often cheaper month to month than a proper fix, which is exactly why it is tempting. But a genuine remediation, an accessible theme, corrected markup on your key pages, and a manual check of your booking or checkout flow, is a one-time or occasional cost rather than an ongoing subscription for a layer that a court has not recognised as compliance.

Sources