Formulários de contacto acessíveis e o Ato Europeu da Acessibilidade

Um formulário de contacto é muitas vezes a única porta entre um visitante e a sua empresa. Se essa porta só puder ser aberta com um rato, boa visão e paciência para resolver um quebra-cabeças com uma imagem desfocada, algumas pessoas ficam simplesmente do lado de fora. Desde meados de 2025, isto já não é apenas uma questão de usabilidade: para muitas empresas que vendem a consumidores na UE, tornou-se uma questão jurídica.

O que abrange o Ato Europeu da Acessibilidade

O Ato Europeu da Acessibilidade (Diretiva (UE) 2019/882) é aplicável desde 28 de junho de 2025. Estabelece requisitos de acessibilidade para determinados produtos e serviços oferecidos aos consumidores – entre eles o comércio eletrónico, os serviços bancários para consumidores, os livros eletrónicos, as comunicações eletrónicas e partes do transporte de passageiros. Para um sítio Web, isso significa a loja online ou o serviço bancário no seu todo, incluindo os formulários que os clientes utilizam para o contactar, fazer perguntas ou reclamar. As microempresas que prestam serviços estão isentas: empresas com menos de dez trabalhadores e um volume de negócios anual ou um balanço total anual não superior a 2 milhões de EUR. As ofertas destinadas exclusivamente a outras empresas ficam, em regra, fora do seu âmbito.

Cada Estado-Membro transpôs a diretiva para o direito nacional. Na Alemanha, trata-se da Barrierefreiheitsstärkungsgesetz (BFSG); na Polónia, de uma lei de 2024 relativa à garantia do cumprimento dos requisitos de acessibilidade por determinados produtos e serviços. As autoridades de fiscalização e as sanções variam de país para país, mas o padrão técnico é, em termos gerais, o mesmo: na prática, a norma europeia EN 301 549, que por sua vez se baseia nas Diretrizes de Acessibilidade para o Conteúdo da Web (WCAG).

Porque compensa mesmo sem obrigação legal

Talvez a sua empresa esteja isenta, ou sirva apenas outras empresas. Ainda assim, os formulários acessíveis compensam, por uma razão simples: cada pessoa que desiste a meio é um pedido de contacto que nunca recebe. As correções que ajudam um utilizador de leitor de ecrã ajudam também quem preenche o formulário num telemóvel num comboio, sob sol intenso, com um pulso partido ou numa segunda língua. Etiquetas claras e mensagens de erro úteis significam menos formulários abandonados para todos – e nenhuma delas enfraquece a sua proteção antispam.

Uma lista de verificação prática com referências às WCAG 2.2

• Etiquetas visíveis associadas aos respetivos campos (1.3.1, 3.3.2): cada campo tem uma etiqueta visível ligada a ele através de for/id. Um placeholder, sozinho, não é uma etiqueta – desaparece logo que alguém começa a escrever.
• Mensagens de erro que explicam a correção (3.3.1, 3.3.3): indique o campo, diga o que está errado e como corrigir – em texto, e não apenas com um contorno vermelho. «Introduza um endereço de e-mail como nome@example.com» é melhor do que «Introdução inválida».
• Utilização completa por teclado (2.1.1, 2.1.2): todos os campos, caixas de verificação, o CAPTCHA e o botão de envio podem ser alcançados e utilizados com Tab, Espaço e Enter, sem armadilhas de teclado.
• Foco visível (2.4.7): vê-se sempre qual o campo ativo. Remover o contorno de foco do navegador sem o substituir não cumpre este critério.
• Contraste suficiente (1.4.3): o texto, as etiquetas e as mensagens de erro têm uma relação de contraste de, pelo menos, 4,5:1 em relação ao fundo (3:1 para texto grande).
• Tamanho do alvo (2.5.8): os botões, as caixas de verificação e as ligações têm, pelo menos, 24 × 24 píxeis CSS, ou espaço suficiente à sua volta.
• Alternativas ao CAPTCHA (1.1.1) e autenticação acessível (3.3.8): o 1.1.1 exige uma alternativa em texto e o CAPTCHA em mais do que uma forma sensorial; o 3.3.8 abrange, em rigor, os passos de início de sessão, mas a sua ideia aplica-se também aqui – um quebra-cabeças, como voltar a escrever letras distorcidas ou resolver uma soma, não deve ser a única forma de passar. Ofereça uma alternativa ou utilize um método que não precise de qualquer quebra-cabeças.
• Honeypots ocultos às tecnologias de apoio: o campo-armadilha recebe aria-hidden="true" no seu contentor e tabindex="-1", para que os utilizadores de leitores de ecrã e de teclado nunca lá cheguem.

CAPTCHAs e honeypots: onde a proteção antispam se cruza com a acessibilidade

Em rigor, o critério 3.3.8 diz respeito aos passos de início de sessão e de autenticação, não aos formulários de contacto. A ideia subjacente, no entanto, transpõe-se bem: escrever letras distorcidas, resolver uma soma ou escolher semáforos numa grelha de imagens exclui completamente algumas pessoas. Opções que normalmente funcionam sem qualquer quebra-cabeças – como Cloudflare Turnstile, Friendly Captcha, um honeypot combinado com uma verificação de tempo, ou filtragem do lado do servidor como o Akismet – mantêm o spam afastado sem pedir aos visitantes que provem o que quer que seja. Um honeypot só é amigável se for verdadeiramente invisível, também para os leitores de ecrã e para os utilizadores de teclado:

<div class="hp" aria-hidden="true">
  <label for="hp-website">Deixe este campo vazio</label>
  <input type="text" id="hp-website" name="website"
         tabindex="-1" autocomplete="off">
</div>
<!-- CSS: .hp { position: absolute; left: -10000px; } -->

Teste o seu próprio formulário em quinze minutos

1. 1Ponha o rato de lado e preencha todo o formulário apenas com o teclado. Consegue alcançar todos os campos e o botão de envio, e vê sempre onde está?
2. 2Submeta o formulário vazio e depois com um endereço de e-mail errado. Os erros aparecem como texto junto ao campo certo, e é claro o que fazer?
3. 3Abra a página num telemóvel ou aplique um zoom de 200% no navegador. Está tudo legível, os botões são fáceis de tocar e algum banner de cookies ou widget de chat tapa o botão de envio?
4. 4Ative um leitor de ecrã (VoiceOver, NVDA ou TalkBack) e ouça: cada campo é anunciado com a respetiva etiqueta, e o honeypot mantém-se em silêncio?
5. 5Execute uma verificação automática como o axe-core. Encontra rapidamente etiquetas em falta e problemas de contraste, mas não tudo – os passos manuais acima continuam a ser necessários.

Se preferir começar por uma visão geral, a formexposed analisa os seus formulários públicos a partir do exterior, sem submeter nada. As suas verificações de acessibilidade executam o axe-core em cada formulário, assinalam CAPTCHAs sem alternativa acessível e honeypots anunciados pelos leitores de ecrã e analisam o formulário num telemóvel – áreas de toque, sobreposições que tapam o botão de envio, deslocamento horizontal. A verificação gratuita mostra o nível global; estes pormenores constam do relatório completo. É um bom ponto de partida para a lista acima, não um substituto de testes com pessoas reais.