Tutte le note

Sfatare i miti

Overlay di accessibilità: la soluzione di una riga di codice che porta dritti in tribunale

Short answer: no. An accessibility overlay, the script that drops a widget on an existing site, does not make it compliant. Independent testing finds overlays catch only a fraction of WCAG issues, a rising share of accessibility lawsuits name sites that have one installed, and the FTC has already fined a major overlay vendor for claiming otherwise. Real compliance is built into the components, not bolted on top.

What is an accessibility overlay, and why does it get sold as a fix?

An overlay is a single <script> tag a vendor sells as a shortcut to compliance. Once installed, it adds a floating widget with controls for font size, contrast, and a "pause animations" toggle, and it runs automated scripts that try to patch the page on the fly: guessing at alt text, adjusting color values, rewriting ARIA attributes it did not write.

The pitch is genuinely appealing: no code review, no designer time, and a badge that says the site is protected. What it leaves out is the part that matters: the widget is guessing at a site it did not build, on top of a page it cannot fully see.

How much of WCAG can an overlay actually detect?

Not most of it. Automated tools, including the scanners inside overlay widgets, can meaningfully test only a minority of WCAG success criteria on their own.

Measured byAutomated coverageWhat it misses
WCAG 2.1 success criteria testable by machineAround 30 percent (15 to 16 of 50 AA criteria)Whether meaning, not just markup, is correct
Real-world issue volume, first audit pass57.38 percent (Deque, 13,000+ pages)The rest, closed only by manual review
Same dataset, with manual review added80.39 percent averageFull assistive-technology testing by a person

(Deque, Deque coverage report, to re-verify.)

The gap is structural, not a bug the next update fixes. A script can confirm an image has an alt attribute. It cannot tell whether that text describes the image, whether a custom widget responds to a keyboard, or whether reading order makes sense to a screen reader. Those are judgment calls, and judgment is what an overlay lacks. The WebAIM Million, an annual scan of one million home pages, still found detectable WCAG 2 failures on 95.9 percent of them in 2026, up from 94.8 percent the year before (WebAIM, to re-verify). Automated detection alone is not closing that gap. It is widening.

30%

of WCAG criteria are automatable

57%

of real issues caught on first automated pass

95.9%

of home pages still fail WCAG checks

Are overlays actually named in accessibility lawsuits?

Yes, and the trend does not favor the widget. UsableNet's 2024 lawsuit report found that roughly a quarter of all digital accessibility lawsuits filed that year targeted websites with an overlay already installed, the overlay itself cited as a barrier rather than a fix (reported via secondary coverage of UsableNet's data, Accessibility.Works, to re-verify). UsableNet's own 2025 monitoring shows the pattern holding, with lawsuits mentioning accessibility widgets recorded every month: 85 in January, climbing to 132 in February, then settling between 99 and 119 a month through June (UsableNet, to re-verify).

A widget being present does not prove it caused the suit, or that sites without one are safer. Across two years of tracking, an overlay has not been a credible substitute for fixing the underlying code. Plaintiffs' firms test past it, and courts have not treated it as a shield.

What happened with the FTC and accessiBe?

This is the case that turned "overlays don't really work" from a community complaint into federal law. In January 2025, the Federal Trade Commission announced a complaint and proposed settlement against accessiBe, one of the best-known overlay vendors, finalized as an order on April 21, 2025. The claim: accessiBe's accessWidget was marketed as able to make any website WCAG compliant using AI, and that was false, failing to fix basic components like navigation menus, form fields, and image descriptions. The complaint further alleged accessiBe dressed up third-party endorsements to look independent without disclosing its own involvement. The company paid $1 million and is barred from claiming its product can make a site WCAG compliant, or keep it compliant over time, without evidence (FTC, to re-verify).

That is one of the category's largest vendors, found by a regulator to have oversold what the category can do. Treat that as the ceiling of what any overlay can honestly promise, not the floor.

So what actually works instead?

There is no shortcut. The fix is the same discipline that makes a site good in every other respect.

  1. Start at the component, not the page. Every button, form field, menu, and modal gets built with correct semantic HTML and ARIA from the first pass, not patched afterward.
  2. Make keyboard navigation a first-class path. A feature that only works with a mouse is not finished, regardless of its score.
  3. Test with real assistive technology. A screen reader, a keyboard-only pass, and a person who relies on that technology daily catch what a scanner cannot.
  4. Hold contrast and motion to the standard, not the eye test. WCAG 2.2 AA contrast ratios and prefers-reduced-motion support are checked, not assumed.
  5. Re-test after every change. Compliance is a property of the current build, not a certificate earned once.

This is why Thabrew Effect treats accessibility as part of the same system as visibility and conversion, never a line item handed to a plugin. A component built accessibly the first time serves every visitor and every audit at once. A widget bolted on afterward serves a screenshot.

A plain note before the FAQ: none of this is legal advice. It summarizes publicly reported research and one federal enforcement action. Anyone facing an active accessibility complaint needs a lawyer, not a blog post.

Domande frequenti

No. Gli overlay eseguono script automatizzati sul codice esistente e possono affrontare solo una minoranza dei criteri di successo WCAG. Non possono verificare il significato, il giudizio o l'intento, che rappresentano gran parte di ciò che la conformità richiede. Nessuna autorità legale o dell'accessibilità credibile considera un overlay da solo sufficiente.

Le prove indicano il contrario. Il monitoraggio delle cause legali ha rilevato che i siti con un overlay installato compaiono in una quota consistente delle azioni legali su più anni, con il widget stesso talvolta citato come una barriera.

Che l'accessWidget di accessiBe veniva pubblicizzato come in grado di rendere qualsiasi sito conforme al WCAG grazie all'IA, e che quell'affermazione era falsa: il prodotto falliva su componenti di base come la navigazione, i campi dei moduli e le descrizioni delle immagini. accessiBe ha pagato 1 milione di dollari e le è stato vietato di ripetere l'affermazione.

Dipende da cosa si misura. In base ai criteri di successo WCAG, circa il 30 per cento è verificabile dalla sola macchina. In base al volume reale di problemi rilevato in un ampio studio, gli strumenti automatizzati ne hanno individuati circa il 57 per cento in una prima analisi, con una revisione manuale necessaria per il resto.

Integrare l'accessibilità nei componenti: HTML semantico corretto, pieno supporto da tastiera, contrasto e movimento testati, e test reali con tecnologie assistive. Va trattata come il modo in cui il sito viene costruito, non come una funzionalità aggiunta alla fine.

No. Riassume ricerche pubblicamente riportate, tendenze delle cause legali e un'azione esecutiva federale. Chiunque abbia una questione legale in corso ha bisogno di un avvocato qualificato, non di un articolo generico.

Il WCAG 2.2 AA copre criteri di percepibilità, utilizzabilità, comprensibilità e robustezza, molti dei quali richiedono un giudizio umano. La scansione automatizzata di un overlay copre un sottoinsieme ristretto e tecnico, motivo per cui superare il proprio punteggio interno non significa che un sito soddisfi il WCAG AA.

Perché il widget non corregge il codice sottostante. I test condotti da chi intenta causa, spesso manuali e con tecnologie assistive, continuano a trovare le stesse barriere che uno scanner non aveva rilevato. Il widget cambia ciò che mostra uno screenshot, non ciò che incontra uno screen reader.