O Ato Europeu da Acessibilidade já morde: o que o seu site precisa

O Ato Europeu da Acessibilidade (European Accessibility Act) passou a ser aplicável a 28 de junho de 2025. Durante o primeiro ano, a maioria das empresas ficou a observar para ver se alguém o iria de facto fazer cumprir. A pergunta já tem resposta.

Um tribunal francês ordenou ao Carrefour que alcançasse a conformidade total, sob pena de uma sanção de 500 € por dia. Ao longo de 2026, as autoridades de fiscalização do mercado de vários Estados-Membros passaram dos pedidos de informação às auditorias dirigidas. Há mecanismos de reclamação em todos os Estados-Membros, e as organizações de pessoas com deficiência têm-nos usado.

Se vende a consumidores na UE e o seu site não é acessível, isto já não é uma questão de reputação. É uma questão sujeita a fiscalização.

O que o Ato abrange de facto

A Diretiva (UE) 2019/882 aplica-se a uma lista definida de produtos e serviços, não à web inteira. Os serviços abrangidos incluem:

• Comércio eletrónico, definido de forma ampla como qualquer serviço que permita a um consumidor celebrar um contrato à distância. Se alguém pode navegar, escolher e comprar no seu site, está abrangido.
• Serviços bancários para consumidores, incluindo o homebanking e as interfaces de pagamento.
• Serviços de transporte de passageiros, incluindo sites, aplicações e bilhética.
• Serviços de comunicações eletrónicas.
• Acesso a serviços de comunicação social audiovisual.
• Livros eletrónicos e o software específico para os ler.

Os produtos abrangidos incluem terminais self-service, terminais de pagamento, leitores de livros eletrónicos e equipamento informático para consumidores.

Na prática, há duas fronteiras que importam. Primeiro, a diretiva aplica-se aos serviços prestados a consumidores. As plataformas puramente B2B, as ferramentas internas e os serviços que não são oferecidos ao público ficam de fora. Segundo, existe uma isenção para microempresas no caso dos serviços: menos de dez trabalhadores e volume de negócios anual ou balanço total que não exceda dois milhões de euros. Essa isenção aplica-se só aos serviços, não aos produtos, e não se pede: ou a empresa fica abaixo do limiar, ou não fica.

A isenção é mais estreita do que se costuma esperar. Uma loja online com doze pessoas está abrangida. E também está uma empresa com oito trabalhadores que vende um produto físico incluído no anexo de produtos.

A norma técnica

O Ato fixa requisitos funcionais. A referência técnica é a norma europeia harmonizada EN 301 549, onde estão os critérios que se podem efetivamente testar.

A versão de referência atual, a V3.2.1 de março de 2021, incorpora as WCAG 2.1 de nível AA. O ETSI publicou a versão seguinte, a V4.1.1, a 2 de setembro de 2026. Esta passa a referência para as WCAG 2.2, que acrescentam um pequeno número de critérios de sucesso sobre a aparência do foco, os movimentos de arrastamento, o tamanho do alvo, a ajuda consistente e a introdução redundante de dados. A V4.1.1 ainda não está citada no Jornal Oficial, por isso, por enquanto, é a V3.2.1 que confere presunção de conformidade. Nenhum dos novos critérios é dramático, mas, se está a corrigir agora, construir para as WCAG 2.2 em vez das 2.1 evita fazer o trabalho duas vezes.

A conformidade com a norma harmonizada dá-lhe presunção de conformidade com a diretiva. Esse é o objetivo prático: WCAG 2.1 AA hoje, WCAG 2.2 AA se quiser ter margem.

O que isto significa no código

As orientações sobre acessibilidade costumam ficar ao nível dos princípios. Eis o aspeto que têm enquanto trabalho concreto, com base no que encontramos em quase todas as auditorias.

Semântica e estrutura

A maior parte das falhas de acessibilidade é estrutural. Uma página feita de divs encaixados uns nos outros com handlers de clique não dá a um leitor de ecrã nada com que trabalhar.

• Use os elementos verdadeiros. Um botão é um <button>, não um div com onClick. Um link que navega é um <a href>. Esta única mudança resolve de uma vez a operabilidade por teclado, o comportamento do foco e o anúncio pelo leitor de ecrã.
• Landmarks: header, nav, main, footer. Um único main por página.
• Títulos por ordem, a descrever a estrutura e não escolhidos pelo tamanho da letra.
• Listas como listas, tabelas como tabelas, com células de cabeçalho e scope corretos.
• Idioma declarado no elemento html, e alterado inline onde o conteúdo muda de idioma. Num site multilingue, isto importa mais do que se pensa, porque, de outro modo, um leitor de ecrã lê francês com uma voz inglesa.

Formulários

É nos formulários que as transações falham, por isso são escrutinados.

• Cada campo tem uma etiqueta associada programaticamente. O texto de placeholder não é uma etiqueta.
• Os erros são identificados por texto, associados ao campo e anunciados. Uma moldura vermelha, por si só, não comunica nada a um utilizador cego.
• Os campos obrigatórios são assinalados de forma visível para as tecnologias de apoio.
• Atributos autocomplete nos campos de dados pessoais, o que é um critério explícito das WCAG e também melhora a conversão.
• Os controlos agrupados usam fieldset e legend.

Teclado e foco

• Tudo o que é interativo pode ser alcançado e operado pelo teclado, numa ordem que corresponde à disposição visual.
• O foco está sempre visível. Retirar os contornos sem os substituir é uma falha pura e simples.
• Sem armadilhas de teclado. Os modais prendem o foco de propósito, devolvem-no ao fechar e fecham com Escape.
• Link para saltar para o conteúdo principal.

Design visual

• Contraste de texto de pelo menos 4,5 para 1 no texto normal e de 3 para 1 no texto grande.
• Contraste não textual de 3 para 1 nos componentes de interface e nos gráficos com significado, o que apanha muitas molduras de baixo contraste em campos de formulário.
• O conteúdo reorganiza-se a 320 píxeis CSS de largura sem deslocação horizontal.
• O texto pode ser ampliado até 200 % sem perda de conteúdo.
• A cor nunca transmite significado sozinha.

Conteúdo dinâmico

• As regiões live anunciam as alterações que acontecem sem carregar a página, como as atualizações do carrinho ou os resumos de validação.
• Os componentes personalizados têm as funções, os estados e as propriedades corretos. Se estiver a construir uma combobox à mão, siga as ARIA Authoring Practices em vez de improvisar.
• Respeite a preferência de movimento reduzido.
• Nada que reproduza áudio automaticamente, e nenhum carrossel que avance sozinho sem um controlo de pausa.

Documentos e multimédia

• Os PDF abrangidos têm de estar etiquetados e ser legíveis. Uma fatura ou um documento de termos entregue como imagem digitalizada falha.
• Os vídeos precisam de legendas. O áudio pré-gravado precisa de uma transcrição.
• As imagens precisam de texto alternativo que transmita a sua finalidade. As imagens decorativas levam um atributo alt vazio.

A declaração de acessibilidade

Os prestadores de serviços têm de publicar informação sobre a forma como o serviço cumpre os requisitos. As declarações de acessibilidade em falta ou incompletas estão entre as constatações mais frequentes, e é estranho falhar nisto, porque custa uma tarde.

Uma declaração que sirva para alguma coisa inclui o objetivo de conformidade, a data da última avaliação, o método usado, uma lista franca das limitações conhecidas com um calendário, um canal de contacto acompanhado por uma pessoa real e os dados da entidade nacional de fiscalização a quem se podem dirigir reclamações.

Não exagere. Declarar conformidade total quando existe uma lacuna conhecida é pior do que declarar conformidade parcial com um plano de correção, tanto do ponto de vista jurídico como prático.

Sanções

As sanções são fixadas a nível nacional e variam muito. Os valores publicados incluem até 90 000 € nos Países Baixos, intervalos de 10 000 € a 100 000 € por infração na Alemanha, escalões de 75 000 € a 300 000 € por infração em França e até 60 000 € na Irlanda. Alguns Estados-Membros permitem cálculos com base no volume de negócios em casos reincidentes ou graves.

A exposição financeira muitas vezes não é o maior custo. Ser obrigado a corrigir sob uma sanção diária significa fazer o trabalho sob pressão de prazos, com um auditor, o que sai muito mais caro do que fazê-lo de forma ponderada.

As ferramentas de overlay não funcionam

Os overlays de acessibilidade, os widgets de JavaScript que prometem conformidade instantânea, não a entregam. Não conseguem corrigir a semântica em falta, não conseguem escrever texto alternativo com significado e interferem muitas vezes com a tecnologia de apoio que o utilizador já tem configurada. As organizações de defesa das pessoas com deficiência têm sido coerentes neste ponto, e os litígios noutras jurisdições envolveram repetidamente sites que usavam um overlay.

Trate-os como um imposto, não como uma solução.

Um caminho de correção realista

Esta é a sequência que usamos, e que costuma eliminar a maior parte do risco nas duas primeiras fases.

Fase 1: análise automática e auditoria manual. As ferramentas automáticas detetam cerca de um terço dos problemas, o que é útil mas está longe de ser suficiente. Junte à análise testes manuais com teclado e com leitor de ecrã nos percursos críticos: página inicial, categoria, produto, carrinho, checkout, conta, contacto.

Fase 2: corrigir os percursos de transação. Checkout, registo, início de sessão, pesquisa. É aqui que um site inacessível deixa de ser um incómodo e passa a ser exclusão, e é sobre isto que vai incidir uma reclamação.

Fase 3: corrigir a biblioteca de componentes. A maioria dos sites é construída com um conjunto limitado de componentes repetidos por todo o lado. Corrigir uma vez os componentes de botão, campo, modal, menu pendente, separador e tabela corrige centenas de páginas de uma só vez. É aqui que está o efeito multiplicador.

Fase 4: conteúdos e documentos. Texto alternativo, títulos, PDF, legendas. Lento, mas não tecnicamente difícil.

Fase 5: evitar regressões. Verificações automáticas de acessibilidade na CI, regras de linting para JSX ou modelos e critérios de acessibilidade na definition of done. Sem isto, vai pagar a auditoria outra vez daqui a dezoito meses.

O benefício colateral

Tudo o que ficou acima melhora também a visibilidade na pesquisa, as Core Web Vitals e a conversão. Uma estrutura de títulos correta, markup semântico, etiquetas verdadeiras e contraste suficiente são as mesmas coisas que ajudam os crawlers a interpretar uma página e ajudam qualquer utilizador a concluir uma compra no telemóvel com pouca luz.

Há também uma sobreposição com obrigações mais recentes. As regras de transparência do Regulamento da Inteligência Artificial exigem que a informação seja prestada de forma clara e distinguível, em conformidade com os requisitos de acessibilidade aplicáveis, o que significa que um aviso sobre IA escondido numa tooltip inacessível falha duas vezes. Tratámos disso no artigo sobre a transparência no Regulamento da Inteligência Artificial.

Por onde começar

Se o seu site ainda não foi auditado, comece pelo teclado. Desligue o rato e tente concluir uma compra no seu próprio site. A maioria das equipas encontra os três primeiros problemas em cinco minutos, e é uma demonstração mais convincente para a administração do que qualquer relatório.

Fazemos auditorias de acessibilidade e programas de correção para empresas que operam na UE, incluindo o trabalho na biblioteca de componentes e a integração na CI, para que a correção se aguente. Há mais pormenores na página do nosso serviço de correção de acessibilidade, e o enquadramento regulamentar mais amplo está no nosso mapa de conformidade digital na UE para 2026.

Contacte-nos em office@c9group.dev se quiser uma avaliação honesta de onde está.