Conversão
Seu formulário de contato é acessível a quem tenta preencher?
Antes de pagar por mais visitas, vale conferir se quem chega consegue concluir o contato. Um teste manual de teclado e leitor de tela ajuda a decidir o que corrigir primeiro.
Se ninguém da sua equipe preencheu o formulário só com o teclado, ou com um leitor de tela, você ainda não sabe se ele funciona para todos. O teste responde a uma pergunta anterior à compra de mídia: quem chega ao site consegue, de fato, concluir a tentativa de contato? Se alguém não consegue concluir o contato, existe uma barreira para corrigir antes de levar mais visitantes à página. Isso não permite prever quantos contatos a correção vai gerar.
O que a auditoria precisa verificar
A web.dev lembra que as pessoas usam mouse, toque, teclado, leitor de tela ou ampliação de texto, e que todo campo deve ter um rótulo associado. Também mostra que elementos nativos de formulário trazem recursos que uma div imitando um campo não tem: um leitor de tela pode ouvir apenas “Name”, sem saber que ali se digita. O W3C WAI trata das mensagens de erro e da validação: elas devem ser claras e indicar como corrigir, e uma das formas que o tutorial descreve é listar os erros no topo, antes do formulário, com links para cada campo. O Nielsen Norman Group alerta que placeholder não substitui rótulo, pois some ao digitar e dificulta conferir o que foi escrito.
A partir disso, uma forma de organizar a revisão é transformar cada ponto em um teste com resultado passa ou falha.
| Verificação | Como testar | Passa quando | Falha quando |
|---|---|---|---|
| Rótulo visível | Olhe o formulário com os campos preenchidos | Cada campo mostra seu nome fora do campo, mesmo após digitar | O nome só aparece como placeholder |
| Rótulo associado | Use o leitor de tela (NVDA ou VoiceOver) e navegue campo a campo | Ele anuncia o nome e o tipo de cada campo | Anuncia só um texto solto, sem indicar que é um campo |
| Teclado | Percorra tudo com Tab e envie com Enter | Todos os campos e o botão são alcançados, na ordem visual | Algum item é pulado, a ordem confunde ou o foco fica preso |
| Foco visível | Observe ao tabular | Você sempre vê qual campo está ativo | O contorno some ou quase não se distingue |
| Erro | Envie vazio e com e-mail inválido | O erro é dito em texto (não só por cor), indica qual campo e como corrigir, o leitor de tela o anuncia e dá para chegar ao campo com o teclado, seja por mensagem junto ao campo ou por resumo no topo com links | O erro só muda a cor da borda, o leitor de tela não o anuncia, ou não dá para saber qual campo corrigir nem chegar a ele |
| Ampliação | Aumente a página para 200% | Dá para preencher e enviar sem perder campos | Campos ou botão ficam cortados ou inacessíveis |
Esse roteiro é manual e parcial. Passar nele não comprova conformidade com nenhuma norma, apenas indica se há barreiras evidentes. Um resultado sem falhas também não prova que o formulário funciona para todos, só que essas verificações não encontraram problema.
Como priorizar o que corrigir
Nem toda falha pesa igual. Uma proposta de priorização é classificar cada falha pela pergunta “a pessoa consegue enviar a mensagem?”. Falhas que impedem o envio ficam no topo. Falhas que obrigam a pessoa a adivinhar ou refazer vêm depois. Falhas de acabamento ficam por último.
- Bloqueia o envio: campo que o leitor de tela não reconhece, botão fora do alcance do teclado, erro que ninguém percebe ou que não indica onde corrigir.
- Aumenta a chance de abandono ou de erro: placeholder no lugar do rótulo, mensagem genérica, foco invisível.
- Atrapalha, mas não impede: ordem de tabulação estranha, formato esperado não explicado.
Isso é um critério de decisão, não uma medição. Ele ajuda a definir o que entra primeiro na fila do time de desenvolvimento, sem presumir quanto cada correção vai render. A classificação de uma falha também pode mudar conforme o contexto: um foco invisível, por exemplo, pode bloquear quem só usa teclado, e nesse caso sobe para a primeira categoria.
Limites do teste e quando ir além
Quem faz a auditoria costuma conhecer o formulário de cor, e isso esconde problemas. A própria web.dev sugere testar em dispositivos e configurações que você não usa no dia a dia e, sempre que possível, pedir a alguém que usa leitor de tela ou ampliação de texto que preencha o formulário. Segundo a fonte, revisões de acessibilidade são úteis, mas o teste com pessoas reais é ainda melhor. Se isso já for viável, o artigo sobre teste de usabilidade ajuda a decidir como estruturá-lo.
Este roteiro avalia se o formulário funciona, não quais perguntas ele faz. Para essa segunda discussão, há o texto sobre perguntas no primeiro contato.
Teste o caminho até o envio
Reserve meia hora, abra o formulário em uma janela nova, desconecte o mouse e tente enviar uma mensagem de teste apenas com o teclado. Repita com um leitor de tela e, depois, provocando dois erros de propósito. Anote cada falha em uma das três categorias acima. Se houver qualquer item na primeira categoria, a correção pode vir antes da próxima verba de mídia. Se não houver nenhum, você terá um registro simples de que o formulário passou no que foi testado, e pode decidir o investimento seguinte sabendo que ainda restam limites a considerar, como o teste com pessoas que usam essas tecnologias.
