Overlays de acessibilidade: a correção de uma linha que pode acabar em tribunal
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 by | Automated coverage | What it misses |
|---|---|---|
| WCAG 2.1 success criteria testable by machine | Around 30 percent (15 to 16 of 50 AA criteria) | Whether meaning, not just markup, is correct |
| Real-world issue volume, first audit pass | 57.38 percent (Deque, 13,000+ pages) | The rest, closed only by manual review |
| Same dataset, with manual review added | 80.39 percent average | Full 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.
- 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.
- Make keyboard navigation a first-class path. A feature that only works with a mouse is not finished, regardless of its score.
- 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.
- Hold contrast and motion to the standard, not the eye test. WCAG 2.2
AA contrast ratios and
prefers-reduced-motionsupport are checked, not assumed. - 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.
Perguntas frequentes
Não. Os overlays executam scripts automáticos sobre o código já existente e só conseguem resolver uma minoria dos critérios de sucesso das WCAG. Não conseguem verificar significado, juízo ou intenção, que é a maior parte daquilo que a conformidade exige. Nenhuma autoridade credível, jurídica ou de acessibilidade, considera um overlay, por si só, suficiente.
A evidência aponta no sentido contrário. O acompanhamento de ações judiciais tem encontrado sites com overlays instalados nomeados numa parte substancial dos processos ao longo de vários anos, sendo o próprio widget por vezes apontado como uma barreira.
Que o accessWidget da accessiBe era comercializado como capaz de tornar qualquer site conforme com as WCAG através de IA, e que essa alegação era falsa: o produto falhava em componentes básicos como a navegação, os campos de formulário e as descrições de imagem. A accessiBe pagou 1 milhão de dólares e ficou proibida de repetir a alegação.
Depende do que se está a medir. Em termos de critérios de sucesso das WCAG, cerca de 30 por cento são testáveis apenas por máquina. Em termos do volume real de problemas, num grande estudo, as ferramentas automáticas detetaram cerca de 57 por cento numa primeira passagem, sendo necessária revisão manual para o restante.
Incorporar a acessibilidade nos componentes: HTML semântico correto, suporte total por teclado, contraste e movimento testados, e testes reais com tecnologia de apoio. Tratá-la como parte de como o site é construído, e não como uma funcionalidade acrescentada no fim.
Não. Resume estudos divulgados publicamente, tendências de ações judiciais e uma medida federal de fiscalização. Quem tiver uma questão jurídica em curso precisa de um advogado qualificado, não de um artigo genérico.
As WCAG 2.2 AA abrangem critérios percetíveis, operáveis, compreensíveis e robustos, muitos deles exigindo juízo humano. A verificação automática de um overlay cobre apenas um subconjunto estreito e técnico, razão pela qual obter uma boa pontuação nessa verificação não significa que o site cumpra o nível WCAG AA.
Porque o widget não corrige o código subjacente. Os testes dos autores da ação, muitas vezes manuais e com tecnologia de apoio, continuam a encontrar as mesmas barreiras que um scanner não detetou. O widget muda o que aparece numa captura de ecrã, não o que um leitor de ecrã encontra.