Uma boa mensagem de erro identifica o problema, mostra onde ele aconteceu e orienta a correção. Ela não deve apenas informar que algo falhou: precisa ajudar a pessoa a recuperar o controle da tarefa, preservar o que já foi preenchido e continuar sem interpretações desnecessárias.
Esse trabalho combina UX Writing, design de interação, acessibilidade e engenharia. O texto pode estar correto e, ainda assim, a experiência continuar ruim se o campo não for identificado, o foco desaparecer, o erro depender apenas de cor ou a validação do servidor rejeitar a informação sem explicar o que fazer.
O que uma mensagem de erro precisa responder
Na maioria dos casos, uma mensagem útil responde a três perguntas: o que aconteceu, onde está o problema e o que posso fazer agora?
Compare: “Algo deu errado.” com “O e-mail não está em um formato válido. Use um endereço como [email protected].” A segunda versão identifica a causa conhecida e oferece uma instrução objetiva. Ela não promete que o sistema sabe mais do que realmente sabe e não transforma a pessoa em culpada pelo problema.
A heurística de usabilidade de Jakob Nielsen sobre recuperação de erros resume bem esse princípio: mensagens devem usar linguagem simples, indicar precisamente o problema e sugerir uma solução construtiva. Nielsen Norman Group — Help Users Recognize, Diagnose, and Recover from Errors
A fórmula problema, contexto e próximo passo
Uma estrutura prática para escrever mensagens de erro é elemento ou estado + problema + próximo passo. Ela serve para verificar se o texto contém informação suficiente para orientar a ação.
Por exemplo: “O arquivo não foi enviado porque excede o limite de 10 MB. Escolha um arquivo menor e tente novamente.”
Nem sempre será possível informar a causa exata. Se a causa não é conhecida, é melhor dizer que a operação falhou e oferecer uma ação plausível do que inventar uma explicação técnica.
Exemplos por situação
- Campo obrigatório: Informe seu nome.
- Formato inválido: Informe uma data no formato dd/mm/aaaa.
- Valor fora do limite: Digite uma quantidade entre 1 e 10.
- Arquivo incompatível: Este formato de arquivo não é aceito. Envie um arquivo PDF ou DOCX.
- Falha temporária: Não foi possível carregar os dados agora. Tente novamente em alguns instantes.
Evite culpar a pessoa
A interface deve descrever o estado do sistema ou da tarefa, não julgar quem está usando o produto.
Evite: “Você digitou o e-mail errado.” Prefira: “O formato do e-mail não é válido. Use um endereço como [email protected].”
Evite: “Você enviou o arquivo errado.” Prefira: “Não foi possível enviar este arquivo. Verifique o formato aceito e tente novamente.”
O sistema sabe que o valor não foi aceito; nem sempre sabe por que a pessoa o digitou daquela maneira. O tom pode ser humano, mas não deve ocupar o espaço da informação.
Mensagens de erro em formulários
Formulários combinam instruções, campos, validação, navegação, dados pessoais e feedback. A WAI observa que formulários acessíveis ajudam pessoas com deficiência visual, cognitiva, motora e usuários de entrada por voz, além de melhorar a compreensão para o público em geral. WAI — Forms Tutorial
Quando vários campos apresentam problemas, um resumo no início pode informar a situação geral: “Encontramos 2 erros no formulário. Revise os campos indicados abaixo.”
Cada item do resumo deve referenciar o label correspondente, explicar o erro e, quando possível, oferecer um link até o campo. A WAI recomenda esse padrão porque ele reduz a necessidade de procurar visualmente pela página. WAI — User Notification
O resumo não substitui a mensagem próxima ao campo. O campo “E-mail” ainda precisa manter sua própria mensagem, porque a pessoa pode chegar diretamente até ele, navegar pela página com teclado ou receber o conteúdo por tecnologia assistiva.
O que a WCAG exige sobre erros de entrada
O critério 3.3.1 da WCAG 2.2, classificado como nível A, estabelece que, quando um erro de entrada é detectado automaticamente, o item com problema deve ser identificado e o erro deve ser descrito em texto. O objetivo é garantir que a pessoa saiba que houve um erro e consiga entender o que está errado. W3C — Error Identification
Isso significa que não basta pintar a borda do campo de vermelho, exibir apenas um ícone, rolar a página para uma área distante ou mostrar novamente o formulário sem explicar o que falhou. A cor e o ícone podem reforçar o estado, mas não substituem a descrição textual.
O critério 3.3.3, de nível AA, acrescenta que, quando uma sugestão de correção é conhecida, ela deve ser fornecida, salvo quando isso comprometer a segurança ou o propósito do conteúdo. W3C — Error Suggestion
Esses critérios não determinam uma única apresentação visual. O erro pode aparecer inline, em um resumo antes do formulário, em um alerta ou em uma combinação desses recursos. A solução deve ser escolhida conforme a tarefa e validada no contexto real.
Foco, associação e anúncio
Depois do envio de um formulário com erros, a pessoa precisa perceber que a operação não foi concluída e conseguir chegar ao primeiro problema. Um fluxo possível é informar que existem erros, exibir um resumo antes do formulário, permitir acesso direto ao campo correspondente, manter a mensagem junto ao campo, posicionar o foco de forma previsível e preservar os dados já preenchidos.
A WAI apresenta como exemplo a associação entre o campo e sua mensagem por meio de aria-describedby, além do uso de uma região de alerta para anunciar atualizações importantes. Porém, esses recursos não devem ser aplicados mecanicamente: a implementação precisa considerar o comportamento da interface, a ordem do foco e os testes com leitores de tela. WAI — User Notification
Durante a digitação, mensagens a cada tecla podem interromper a tarefa e produzir ruído. Em alguns campos, pode ser melhor informar o formato antes da entrada e validar depois que a pessoa sair do campo. Em outros, o retorno imediato pode evitar uma sequência maior de erros.
Prevenir o erro é melhor do que apenas anunciá-lo
Uma mensagem de erro é uma forma de recuperação, não uma solução para todo problema de interação. Se muitas pessoas cometem o mesmo erro, a causa pode estar no design do campo, na instrução, no formato exigido ou na própria tarefa.
A WAI destaca que erros sucessivos podem aumentar a fadiga cognitiva e fazer algumas pessoas abandonarem o fluxo. Prevenir, corrigir automaticamente ou sugerir formatos válidos pode ser mais eficiente do que esperar a falha para depois exibir uma mensagem. WAI — Supportive Forms
Considere uma data. Se o produto exige 01/03/1996, mas não explica o formato e rejeita 1/3/1996, a mensagem precisa orientar a correção. Melhor ainda seria aceitar formatos equivalentes quando isso não criar ambiguidade ou conduzir a entrada de maneira mais clara.
Validação no navegador e no servidor
A validação client-side pode fornecer retorno rápido e evitar uma submissão desnecessária. Ela ajuda a pessoa a corrigir um campo enquanto ainda está no contexto da tarefa.
Ela não substitui a validação server-side. A WAI explica que a validação no navegador pode ser desativada ou contornada e que os dados precisam ser verificados no servidor para preservar segurança e integridade. WAI — Validating Input
Um erro técnico interno pode ser registrado para a equipe, enquanto a interface apresenta uma orientação segura: “Não foi possível concluir o envio agora. Verifique os campos indicados e tente novamente.”
Quando não revelar a causa completa
Transparência não significa mostrar todo o diagnóstico técnico. Em autenticação, permissões, pagamentos e dados pessoais, uma mensagem detalhada pode confirmar informações que deveriam permanecer protegidas.
A decisão precisa envolver produto, engenharia e segurança. O UX Writer não deve inventar a causa nem prometer uma correção que o sistema não oferece.
Checklist para revisar mensagens de erro
Como testar na prática
Um teste básico pode combinar preenchimento com campos obrigatórios vazios, entrada em formato inválido, valor fora do intervalo permitido, envio com vários erros ao mesmo tempo, navegação somente por teclado, zoom, leitor de tela, confirmação de que os dados não desaparecem e verificação da mensagem retornada pelo servidor.
A WAI recomenda tentar deliberadamente deixar campos obrigatórios vazios ou inserir formatos inválidos durante uma revisão preliminar de acessibilidade. O objetivo é verificar se a orientação é específica, encontrável e suficiente para corrigir o problema. WAI — Easy Checks
Perguntas frequentes
Conclusão
Mensagens de erro são parte do sistema de recuperação de uma interface. Elas precisam ajudar a pessoa a reconhecer o problema, entender o que aconteceu e decidir o próximo passo, mas não devem ser usadas para compensar campos confusos, instruções insuficientes ou fluxos que poderiam prevenir o erro.
A melhor mensagem não é necessariamente a mais simpática ou a mais curta. É aquela que apresenta informação proporcional ao problema, respeita a pessoa, funciona com diferentes formas de interação e oferece uma recuperação possível.
