Acessibilidade Web em 2026: Guia de Conformidade

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.

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 alt descritivo, as decorativas têm alt vazio, e os vídeos têm legendas.
• Formulários: cada campo tem um label associado 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.