Como escrever mensagens de erro úteis

Escreva mensagens de erro claras, específicas e acionáveis para ajudar a pessoa a entender o problema e corrigi-lo sem perder o que já preencheu.

Wireframe minimalista de um formulário com erro associado ao campo e orientação de correção.
Nível de impácto
Alto
Status
Recomendado
Nível de evidênica
Forte evidência

Contexto

Uma mensagem como “Ocorreu um erro” não explica o que aconteceu nem como continuar. Mensagens de erro úteis transformam uma falha em orientação: identificam o campo, descrevem o problema e indicam a correção.

Explique o que aconteceu e como corrigir. Identifique o campo ou dado afetado, descreva a regra de forma simples e indique o formato, limite ou valor esperado. Use linguagem neutra, preserve o preenchimento e mantenha a mesma mensagem no campo e no resumo de erros quando ambos existirem.

Mensagem de erro do Gov.br: “Erro. Desculpe, nenhum resultado encontrado.”
Exemplo real: o componente Message do Gov.br usa uma mensagem curta, identifica a falha e mantém o feedback associado ao estado de erro. Isso exemplifica como escrever uma mensagem objetiva sem depender apenas do ícone. Fonte: Gov.br Design System — Message: https://www.gov.br/ds/components/message

Porque isso importa?

Mensagens vagas aumentam a incerteza e fazem a pessoa tentar soluções por tentativa e erro. A WCAG exige que erros de entrada sejam identificados e descritos em texto; quando houver uma correção conhecida, recomenda também informar como resolvê-los.

Uma mensagem específica reduz o esforço de recuperação e ajuda a pessoa a corrigir o dado sem abandonar o formulário ou repetir todo o preenchimento.

  • Campo obrigatório não preenchido.
  • Formato ou valor incorreto.
  • Texto acima ou abaixo do limite.
  • Dado incompatível com outra informação.
  • Erro detectado após o envio do formulário.
  • Falha que a pessoa pode corrigir.
  • Quando o problema for exclusivamente do serviço.
  • Quando a mensagem não indicar o próximo passo.
  • Quando bastar repetir o texto “inválido”.
  • Quando o texto culpar a pessoa.
  • Quando códigos técnicos não ajudarem na correção.
  • Quando a mensagem repetir sem necessidade uma instrução já visível.
Alerta de erro do Adobe Spectrum: “Unable to process payment” orienta verificar os dados do cartão e tentar novamente.
Exemplo real: o Adobe Spectrum combina o problema (“Unable to process payment”) com uma orientação de correção — verificar os dados do cartão e tentar novamente. Isso exemplifica como tornar a mensagem específica e acionável. Fonte: Adobe Spectrum — Writing for errors: https://spectrum.adobe.com/page/writing-for-errors/

Recomendações

Faça

Práticas recomendadas
  • Identifique o campo.
  • Descreva o problema.
  • Indique a correção.
  • Use linguagem simples.
  • Preserve os dados.
  • Mantenha consistência.
Wireframe minimalista de mensagem de erro associada ao campo, com dado preservado e orientação de correção.
A mensagem identifica o campo, descreve o problema e orienta a correção; o dado preenchido permanece disponível para edição.

Evite

Práticas a evitar
  • Não escreva “Ocorreu um erro”.
  • Não use “Campo inválido”.
  • Não culpe a pessoa.
  • Não exiba códigos técnicos.
  • Não dê instruções vagas.
  • Não repita o texto sem necessidade.
Wireframe minimalista de alerta genérico distante do campo, sem explicação nem orientação de correção.
O alerta é genérico e distante do campo; não informa o que aconteceu nem como corrigir.

Acessibilidade

A WCAG 2.2, no Critério de Sucesso 3.3.1 (Nível A), exige que um erro de entrada detectado automaticamente identifique o item afetado e descreva o problema em texto. No Critério 3.3.3 (Nível AA), orienta fornecer sugestões de correção quando elas forem conhecidas, salvo quando isso comprometer a segurança ou a finalidade do conteúdo.

Associe a mensagem ao campo por meios programáticos compatíveis com a tecnologia usada, preserve os valores já preenchidos e ofereça um resumo navegável quando houver vários erros. Não dependa apenas de cor, ícone ou posição para comunicar o problema.

Teste a mensagem com teclado, zoom e leitor de tela. Confirme se o campo, o erro e a orientação são anunciados em uma ordem compreensível.

Checklist

  • A mensagem identifica o campo?
  • O problema está descrito com clareza?
  • A mensagem indica como corrigir?
  • O texto usa linguagem simples?
  • A mensagem evita culpar a pessoa?
  • Os dados preenchidos são preservados?
  • A mensagem está associada ao campo?
  • O texto é consistente no campo e no resumo?
  • A solução foi testada com teclado e leitor de tela?

Referências

  • W3C — WCAG 2.2, Critério de Sucesso 3.3.1: Error Identification. Exige identificar o item com erro e descrever o problema em texto, apoiando mensagens que nomeiam o campo e explicam o que ocorreu. Consultar o critério 3.3.1.
  • W3C — WCAG 2.2, Critério de Sucesso 3.3.3: Error Suggestion. Recomenda fornecer sugestões de correção quando forem conhecidas, reduzindo o esforço para recuperar o formulário. Consultar o critério 3.3.3.
  • Nielsen Norman Group — Error-Message Guidelines. Apoia mensagens próximas ao erro, específicas, construtivas, sem jargão, sem culpa e que preservem o esforço da pessoa. Consultar o artigo.
  • GOV.UK Design System — Error message. Orienta explicar o que ocorreu e como corrigir, combinar a mensagem com o rótulo do campo, usar linguagem clara e preservar os dados preenchidos. Consultar o componente.
  • Padrão Digital de Governo (Gov.br) — componente Message. Apoia o uso de linguagem clara, mensagens objetivas e feedback acessível para erros de sistema e formulários. Consultar o componente Message.
  • AMAWeb — Manual de acessibilidade digital. Complementa as orientações sobre comunicação acessível de erros e formulários. Consultar o Manual.
  • Adobe Spectrum — Writing for errors. Orienta escrever mensagens específicas, explicar o problema quando possível e indicar a ação seguinte; também mostra padrões de alertas e mensagens de erro em contexto. Consultar as orientações.
Veja também

Esta recomendação foi útil para você?