Why not an overlay
A widget paints over the page. We change the page.
This is an argument about mechanism, not about vendors. No product is named here, because the problem is not who sells the widget — it is what a widget can and cannot do.
The mechanism
Where the fix lives decides everything
An accessibility overlay is a script tag. You add one line to your store, and a JavaScript bundle loads in each visitor's browser, inspects the page, and modifies it — adding ARIA attributes, guessing at alternative text, adjusting contrast, offering a panel of user preferences.
Everything it does happens after your server has finished. The HTML your server sends is unchanged. If you view source, the missing label is still missing. If the script fails to load, or a corporate proxy blocks it, or a content-security policy rejects it, or the visitor has JavaScript disabled, or you stop paying the subscription, the page is exactly as it was before you installed anything.
That matters for three separate reasons, and they compound.
1. Assistive technology reads the page, not the patch
Screen readers build their model from the accessibility tree the browser exposes. A well-behaved script can influence that tree — but it is racing the reader's own initialisation, working from guesses about intent, and layering attributes onto markup whose structure it cannot change. The results are inconsistent in a way that is hard to test and harder to support. Meanwhile the actual defect, the one a developer could fix in a line, is still in your template.
2. Litigation looks at your markup
A demand letter or a claim is generally built from an inspection of the site as delivered. The presence of a widget is not a defence, and the data suggests it is not much of a deterrent either: a mid-2025 analysis of US digital-accessibility lawsuits found that 22.6% of the cases filed in the first half of the year — roughly 456 of them — named sites that already had an accessibility widget installed UsableNet, 2025 mid-year report . A widget is not a shield.
3. Regulators have acted on the claims
In January 2025 the US Federal Trade Commission announced a complaint and proposed order against an overlay vendor over representations that its automated product could make any website conform to WCAG, requiring a $1m payment; the Commission approved the order as final in April 2025 FTC, final order . The order bars the company from representing that its automated products can make any website WCAG-compliant, or keep it compliant over time, unless it has evidence for the claim FTC, complaint and proposed order .
The useful way to read that is not as a scandal about one company. It is a standard: if you sell automation, you must be able to substantiate what you say it achieves. We take it as binding on ourselves — which is why this site says what our automation did and where the evidence is, and never says it produced conformance.
The alternative
Fix it where the page is made
The Klarvo Access plugin runs on your server. When a page is rendered, it rewrites the specific tags that failed — identified by a hash of their exact served bytes — before the HTML leaves your host. What a visitor receives, what a screen reader parses and what an inspector sees are all the same corrected markup.
Three consequences follow, and they are the whole argument:
- No JavaScript dependency. With the fix applied, the page is simply correct. Nothing has to run in the visitor's browser for the label to exist.
- It can be verified. The engine re-fetches your live page, through your cache, and checks that the fix is there. A claim you can check is a different category of thing from a claim you cannot.
- It is yours. Deactivate the plugin and every change reverts, because nothing was ever written into your theme, your posts or your database. There is no lock-in, because there is nothing held hostage.
Being fair about it
When a widget is still useful
A user-preference panel is a genuinely good idea. Letting a visitor increase text size, raise contrast, stop animation or switch to a simpler layout is real help, and some visitors will use it. If that is what you want, you can have it — and you can have it without a subscription, because the browser and the operating system already offer most of it, and the rest is a small amount of your own code that you control.
What you should not do is buy a preference panel believing you have bought a repair. Those are two different purchases. If a vendor's material moves between them without noticing, that is the thing to look at hardest.
And if you already have a widget installed: you do not need to rip it out to start. Run the free scan and look at what your served HTML actually contains. The findings are about your store, not about the widget.
FAQ
The fair questions
Are overlays useless?
No, and claiming that would be as sloppy as the claims they get criticised for. A widget genuinely can help some visitors — a good font-size or contrast toggle is a real convenience, and some overlays ship perfectly decent user-preference tooling. What a widget cannot do is repair the underlying markup, which is what assistive technology reads and what a legal claim examines.
Is an overlay worse than nothing?
Sometimes, yes. A widget that changes roles, injects ARIA or rearranges focus can make a page harder to use than it was, particularly for people with well-tuned screen-reader setups. It can also create a false sense of completion that stops the real work from being scheduled. The honest position is that it is a different kind of thing from a fix, sold in the same aisle.
What did the FTC actually decide?
In January 2025 the US Federal Trade Commission announced a complaint and a proposed order against an overlay vendor, requiring a $1m payment over claims that its automated product could make any website conform to WCAG; the order was approved as final that April. The order bars representing that the automated product can make any website WCAG-compliant, or keep it compliant over time, without evidence. That is a ruling about substantiating claims, and it applies to us exactly as much as to anyone else — which is why nothing on this site claims conformance from automation.
So how is what you do different from a widget?
The fix is written into the HTML your server sends, by a plugin running on your server, before the page leaves the building. There is no client-side script rewriting the page after the fact, nothing to fail or be blocked, and nothing to stop working when you stop paying — deactivate the plugin and your markup simply returns to what it was. Then the engine re-fetches the live page and checks that the fix is really there.
See what your served HTML really says.
The scan reads the page your server sends — the same thing a screen reader and a claim would look at. Free, no signup.