Acessibilidade web e European Accessibility Act: o que testar

Se vende online a consumidores na UE, os requisitos de acessibilidade web do European Accessibility Act aplicam-se à sua loja desde 28 de junho de 2025, a menos que a sua empresa seja uma microempresa. Muitos dos problemas graves pode encontrá-los sozinho: faça uma encomenda de teste usando apenas o teclado, amplie a página e experimente cada formulário. O que uma verificação feita por si não consegue é provar que todo o site cumpre a norma.

Talvez um programador lhe tenha falado da lei, ou um email lhe tenha oferecido um widget que torna qualquer site «conforme» com uma linha de código. Um cliente que não consegue concluir o checkout com o teclado ou com um leitor de ecrã (software que lê a página em voz alta) pode ir para outra loja sem se queixar.

O European Accessibility Act aplica-se ao seu site?

O European Accessibility Act aplica-se se o seu site vende a consumidores, pessoas que compram para si, e a sua empresa não é uma microempresa. A Diretiva (UE) 2019/882 inclui os serviços de comércio eletrónico entre os serviços que abrange: serviços prestados através de um sítio web ou de uma aplicação «com vista à celebração de um contrato com um consumidor». Os Estados-Membros tinham de aplicar as suas regras a partir de 28 de junho de 2025. Esta é a nossa leitura da diretiva; para um parecer jurídico sobre o seu caso, consulte um advogado.

• As microempresas que prestam serviços estão isentas. É o artigo 4.º, n.º 5. A diretiva define microempresa como uma empresa que emprega menos de 10 pessoas e cujo volume de negócios anual ou balanço total anual não excede 2 milhões de EUR. Contam o número de pessoas e um dos dois critérios financeiros: uma equipa de dez pessoas fica fora da isenção, por mais pequeno que seja o volume de negócios.
• Vender apenas a empresas. A definição refere-se a contratos com consumidores. Se particulares podem encomendar através do seu checkout, considere que o site está abrangido.
• Um site que não vende nada. Um site institucional sem encomendas, reservas ou pagamentos geralmente não é um serviço de comércio eletrónico tal como a diretiva o define. Reservas e pagamentos mudam isso.
• A data de 2030 é para produtos e contratos antigos. O período de transição até 28 de junho de 2030, previsto no artigo 32.º, abrange os produtos usados para prestar um serviço e os contratos assinados antes de junho de 2025.

Cada país da UE aplica o Act através da sua própria lei e define as suas próprias sanções; na Alemanha, essa lei é o BFSG. Se a sua empresa está na Suíça ou no Reino Unido e vende a consumidores na UE, pergunte a um advogado como as regras desses países se aplicam a si.

Porque é que os sites das lojas falham nas verificações de acessibilidade?

As falhas abaixo vêm normalmente de decisões de design e de formulários tomadas uma vez no tema e repetidas em todas as páginas. A Diretiva (UE) 2019/882 pede sítios web «percetíveis, operáveis, compreensíveis e robustos». A norma europeia que transforma isto em testes, a EN 301 549, segue as WCAG, as Diretrizes de Acessibilidade para o Conteúdo da Web publicadas pelo W3C. As WCAG organizam os critérios em três níveis: A (o mínimo), AA e AAA. O nível AA é o objetivo que a norma usa.

O contorno de foco foi removido por estética. Quando alguém percorre uma página com a tecla Tab, o navegador desenha uma moldura à volta da ligação ou do botão ativo. Alguns temas escondem-na porque parece desarrumada, embora as WCAG exijam um indicador de foco visível. Um critério acrescentado nas WCAG 2.2 diz também que o elemento com foco não pode ficar totalmente escondido por conteúdo do próprio site, como um cabeçalho fixo ou um banner de cookies.

O texto é demasiado claro. As WCAG pedem uma relação de contraste, ou seja, quanto o texto é mais escuro ou mais claro do que o fundo, de pelo menos 4,5:1 para texto normal e 3:1 para texto grande. A análise de 2026 da WebAIM a um milhão de páginas iniciais encontrou texto com pouco contraste em 83,9% delas. Cinzento claro sobre branco e branco sobre um botão em tom pastel são os casos habituais.

Os formulários dependem de placeholders e da cor. Uma dica cinzenta dentro de um campo desaparece assim que começa a escrever, e uma margem vermelha sozinha não diz o que está errado. As WCAG exigem etiquetas ou instruções sempre que é preciso introduzir dados, e erros descritos em texto.

O checkout foi feito para o rato. Menus pendentes personalizados, CAPTCHAs de puzzle e inícios de sessão que pedem para memorizar ou voltar a escrever um código travam quem usa o teclado ou um leitor de ecrã. A diretiva refere à parte a identificação, a segurança e o pagamento no comércio eletrónico. Em março de 2026, a autoridade neerlandesa do consumidor, ACM, informou que em 61% das grandes lojas online neerlandesas e de outros grandes sites para consumidores que verificou não era possível fazer uma encomenda com tecnologias de apoio, como um leitor de ecrã.

Um widget ou uma pontuação ocupa o lugar da correção. Os widgets de sobreposição (overlays) acrescentam uma barra de acessibilidade por cima do site. A Comissão Europeia afirma que as sobreposições e ferramentas semelhantes que não fazem o próprio site cumprir a norma «não são uma solução adequada». Um teste automático ajuda, mas, nas palavras do W3C, «nenhuma ferramenta, por si só, consegue determinar se um site cumpre as normas de acessibilidade».

Acessibilidade web: como fazer sozinho a verificação do European Accessibility Act

Pode fazer uma primeira revisão com um navegador e um teclado, sem ferramentas pagas. O W3C, a entidade responsável pelas WCAG, publica um conjunto de Easy Checks assente nesta ideia. Escolha três páginas: a página inicial, uma página de produto ou serviço e o checkout ou o formulário de contacto. Siga por ordem e anote cada ponto em que fica bloqueado.

1. Afaste o rato. Percorra cada página com Tab e Shift+Tab, e use Enter, a barra de espaço e as setas. Deve conseguir chegar ao menu, aos filtros, ao botão de adicionar ao carrinho, a todos os campos dos formulários e ao botão de pagar. Em cada momento deve ver onde está. Anote onde a moldura desaparece atrás de um cabeçalho fixo ou de um banner de cookies, e se consegue sair de um menu ou de uma janela de chat.
2. Amplie. Ponha o navegador a 200%. As WCAG esperam que o texto continue legível sem conteúdo cortado ou sobreposto. Depois deixe a janela com cerca de 1280 píxeis de largura e amplie para 400%: o conteúdo deve caber na largura sem deslocamento horizontal, exceto elementos como mapas e tabelas de dados.
3. Verifique o texto claro. As ferramentas de programador do Chrome, do Edge e do Firefox mostram a relação de contraste da cor de um texto selecionado. Verifique o texto corrido, os preços, os botões e o texto cinzento pequeno por baixo dos campos dos formulários.
4. Experimente cada formulário vazio e depois mal preenchido. Cada campo precisa de uma etiqueta visível que se mantenha enquanto escreve. Envie o formulário vazio: o erro deve dizer em palavras o que falta, junto ao campo, e manter o que já escreveu. Um novo critério das WCAG 2.2 pede também que a informação já introduzida no mesmo processo, como uma morada, seja preenchida automaticamente ou proposta para seleção. Outras formas de um formulário lhe custar encomendas estão no nosso artigo sobre um site com tráfego mas sem pedidos de contacto.
5. Inicie sessão e passe a verificação anti-spam. As WCAG 2.2 dizem que iniciar sessão não pode depender de um teste de função cognitiva, como memorizar uma palavra-passe ou resolver um puzzle, a menos que exista uma alternativa ou ajuda, como um gestor de palavras-passe ou a possibilidade de colar. Um CAPTCHA de puzzle sem outra opção falha aqui.
6. Veja as imagens dos produtos. Clique com o botão direito numa imagem e escolha Inspecionar. O texto alternativo, a descrição curta que um leitor de ecrã lê em voz alta, deve dizer o que é o produto; imagens puramente decorativas podem tê-lo vazio.
7. Repita os passos principais num telemóvel. Ícones pequenos e próximos uns dos outros são difíceis de tocar. As WCAG 2.2 definem uma área de toque mínima de 24 por 24 píxeis CSS (uma unidade de medida da própria página web), com exceções, como espaço suficiente à volta do alvo.

O W3C observa que uma página «pode parecer passar nestas verificações e, ainda assim, ter barreiras de acessibilidade significativas». O passo seguinte é um teste feito por alguém que usa um leitor de ecrã todos os dias.

O que deve corrigir primeiro?

Comece pelas correções no tema e nos componentes de formulário, da mais barata para a mais cara. Uma alteração num modelo corrige todas as páginas construídas sobre ele. Deixe a informação de acessibilidade publicada para quando souber o que o site faz e não faz.

1. Não instale uma sobreposição. O conselho da Comissão Europeia é corrigir os problemas de acessibilidade «na origem», o que numa loja significa o tema, os formulários e o checkout.
2. Reponha a moldura de foco e escureça o texto. Ambos estão normalmente nas definições de cores e estilos do tema. Começamos por definir o contraste uma vez na paleta de design e por verificá-lo nas versões clara e escura do site, para que cada página nova parta de cores que já passam.
3. Refaça os formulários. Etiquetas visíveis, erros em palavras junto ao campo, dados escritos mantidos após um erro, foco levado para o primeiro campo a corrigir e preenchimento automático do navegador para nome, email e morada. Nos nossos projetos de sites começamos pelo próprio componente de formulário, para que cada formulário novo já nasça com estas correções.
4. Acrescente texto alternativo e o idioma da página. Descreva as imagens de produtos e de conteúdo e garanta que cada página declara o seu idioma, para que um leitor de ecrã a pronuncie corretamente. Os motores de busca leem o mesmo texto alternativo e o mesmo atributo de idioma, e é por isso que também fazem parte do trabalho de SEO técnico.
5. Corrija o checkout, o início de sessão e os widgets de terceiros. Substitua os CAPTCHAs de puzzle por verificações que não peçam ao cliente para resolver nada e ofereça uma forma de iniciar sessão que não dependa da memória. Os widgets de pagamento e de chat vêm de fornecedores: peça a cada fornecedor a sua informação de acessibilidade e substitua os que não se alcançam com o teclado.
6. Publique a sua informação de acessibilidade. O anexo V da diretiva pede aos prestadores de serviços que descrevam como o serviço cumpre os requisitos, nas condições gerais ou num documento equivalente. A lei do seu país define os pormenores.
7. Trabalhe para as WCAG 2.2 de nível AA. A versão 4.1.1 da EN 301 549, publicada em setembro de 2026, acrescenta seis requisitos das WCAG 2.2, segundo a AccessibleEU. Até a Comissão a citar no Jornal Oficial da União Europeia, nota a mesma fonte, a referência continua a ser a versão 3.2.1, baseada nas WCAG 2.1 de nível AA. A National Disability Authority da Irlanda prevê a citação a 16 de dezembro de 2026. Corrigir agora para as WCAG 2.2 significa que os novos requisitos já estão cobertos quando isso acontecer.

A diretiva admite uma exceção quando o cumprimento representaria um encargo desproporcionado, mas exige uma avaliação, e os seus considerandos afirmam que a «falta de prioridade, de tempo ou de conhecimentos» não é uma razão legítima.

O que medir depois das correções?

Meça se uma pessoa consegue concluir as tarefas principais com o teclado e com a página ampliada. Repita a mesma verificação do European Accessibility Act nas mesmas três páginas e compare onde ficou bloqueado antes e depois das alterações. Volte a verificar sempre que mudar o tema, um plugin ou o prestador de pagamentos.

1. Uma encomenda de teste só com o teclado, da página de produto à confirmação, sem tocar no rato.
2. A lista de resultados de um teste automático gratuito, como o Lighthouse no Chrome, feito nos mesmos três tipos de página. Reveja os resultados e verifique quais se mantêm.
3. Formulários enviados com erros, para confirmar que cada erro é descrito em palavras e que nada do que foi escrito se perde.
4. A sua informação de acessibilidade publicada, atualizada depois de cada alteração que afete a forma como os clientes encomendam.

Onde entramos nós

Quando analisamos o checkout de uma loja, seguimos o caminho do cliente: a página de produto, o carrinho, os formulários e o passo de pagamento, primeiro com o teclado, depois num telemóvel. Os problemas que estão no tema ou nos componentes de formulário são mais baratos de corrigir aí; o que uma verificação feita por si não consegue esclarecer fica para um teste com leitor de ecrã. Se quiser uma segunda opinião sobre o seu checkout, fale-nos do seu site.

← Todos os artigos