Acessibilidade Web em 2026: Guia de Conformidade
O EAA já está em vigor e o ADA Title II chega em 2026. O que a lei de acessibilidade exige mesmo, porque os overlays falham e como construir tudo bem de raiz.
A acessibilidade web deixou de ser opcional. O European Accessibility Act (EAA) está em vigor desde 28 de junho de 2025 e abrange qualquer empresa que venda produtos ou serviços a clientes da União Europeia, independentemente do país onde está sediada. Nos Estados Unidos, a regra ADA Title II obriga os organismos públicos a cumprir o WCAG 2.1 nível AA até abril de 2026, e os processos no setor privado aumentam todos os anos.
Para quem lança um site ou uma aplicação, isto significa um prazo real e uma exposição financeira real. As coimas do EAA podem chegar a 5% do volume de negócios anual das grandes empresas, e uma única queixa ao abrigo do ADA pode custar dezenas de milhares de euros a resolver antes sequer de o problema estar corrigido.
A boa notícia: a norma que todos referem, o WCAG 2.1 AA, está bem definida e é alcançável. A má notícia é que o atalho mais publicitado, o widget de overlay de acessibilidade, não o leva lá e pode até piorar a sua posição legal. Este guia explica o que a lei exige mesmo, porque é que a solução rápida sai o tiro pela culatra, e como construímos a acessibilidade desde o início em vez de a colar no fim.
O que a lei exige na prática
Há três siglas que surgem sempre, e encaixam de forma simples. O WCAG 2.1 nível AA é a norma técnica. O EAA e o ADA são as leis que, na prática, remetem para ela. Na Europa, cumprir o WCAG 2.1 AA satisfaz os requisitos digitais da norma harmonizada EN 301 549, que é a forma de demonstrar conformidade com o EAA.
O WCAG organiza-se em torno de quatro princípios, conhecidos pela sigla POUR: o conteúdo tem de ser percetível, operável, compreensível e robusto. Em concreto, isto significa alternativas em texto para imagens, contraste de cor suficiente, operação total por teclado, estados de foco visíveis, campos de formulário identificados e marcação que os leitores de ecrã consigam interpretar. O nível exigido é o AA, não o AAA, e é a referência de quase toda a regulação. O EAA isenta as microempresas (menos de 10 trabalhadores e menos de dois milhões de euros de volume de negócios), mas essa exceção é mais estreita do que a maioria dos fundadores assume.
Porque os overlays de acessibilidade pioram tudo
Os widgets de overlay prometem conformidade a partir de uma linha de JavaScript. Não a entregam. As ferramentas automáticas só detetam e corrigem cerca de 30% dos problemas de acessibilidade, e um overlay que reescreve a página depois do carregamento chega muitas vezes tarde, já depois de o leitor de ecrã ter processado o conteúdo, chegando a estragar a experiência precisamente a quem diz ajudar.
O historial legal é claro. Em 2024, um quarto de todos os processos de acessibilidade digital apontou diretamente os overlays como o problema, e os acordos exigem com frequência a sua remoção. Os tribunais têm recusado repetidamente aceitar um widget instalado como prova de conformidade. Em abril de 2025, a FTC aplicou uma coima de um milhão de dólares a um fornecedor de overlays de referência por alegações de marketing que considerou não sustentadas por provas competentes e fiáveis. Pagar por um overlay pode deixá-lo sem conformidade e sem dinheiro.
O overlay não é uma defesa
Um widget instalado não conta como prova de conformidade em tribunal. Se a acessibilidade não está no código, não está no site.
Construir a acessibilidade de raiz: checklist do programador
A acessibilidade é, na maior parte, o resultado de escrever o front-end corretamente, não um projeto à parte. Comece com HTML semântico: elementos button e a verdadeiros, títulos por ordem, e marcos como nav e main. Grande parte do suporte a teclado e a leitores de ecrã vem de graça quando a marcação está certa.
A partir daí, os itens de maior impacto são consistentes:
- Teclado: todos os elementos interativos são alcançáveis e operáveis só com o teclado, com indicador de foco visível e sem armadilhas.
- Contraste: o texto corrente cumpre um rácio de 4,5:1 e o texto grande 3:1.
- Imagens e media: as imagens com significado têm
altdescritivo, as decorativas têm alt vazio, e os vídeos têm legendas. - Formulários: cada campo tem um
labelassociado de forma programática, e os erros são anunciados, não apenas mostrados a vermelho. - ARIA, com moderação: prefira sempre os elementos nativos; use ARIA apenas para preencher lacunas reais, porque ARIA mal aplicado é pior do que nenhum.
Feito durante o desenvolvimento, isto acrescenta pouco custo. Remendado mais tarde, transforma-se num ciclo caro de auditoria e retrabalho.
Testar com ferramentas reais e pessoas reais
Os verificadores automáticos como o axe, o Lighthouse e o WAVE são uma primeira passagem rápida, e pode integrá-los na CI para que as regressões façam falhar o build. Mas lembre-se de que apanham apenas uma fração dos problemas, por isso não fique por aqui.
O teste manual é onde os defeitos reais aparecem. Desligue o rato e navegue o site inteiro pelo teclado. Experimente-o com um leitor de ecrã como o VoiceOver ou o NVDA. Quando o risco é elevado, teste com pessoas que dependem mesmo de tecnologia de apoio, porque a experiência real encontra problemas que nenhum scanner deteta.
Quanto vale a conformidade
O enquadramento que ajuda os clientes não é a coima, é o ganho. Os sites acessíveis chegam a cerca de uma em cada seis pessoas que vivem com uma deficiência, funcionam de forma mais fiável em diferentes dispositivos e tecnologias de apoio, e tendem a posicionar-se melhor porque a marcação semântica limpa é exatamente o que os motores de busca preferem. O mesmo trabalho que cumpre o EAA e o ADA também torna o produto melhor para todos.
Se quer perceber onde o seu site está hoje, fale connosco: tratamos a acessibilidade como qualidade de engenharia com um prazo legal, não como um imposto a pagar no fim.
