Mensagens de erro em formulários

Mensagens de erro em formulários devem identificar o campo, explicar o problema e indicar como corrigi-lo sem apagar os dados. Esse padrão combina clareza, acessibilidade e recuperação eficiente após uma falha.

Wireframe de formulário com feedback de erro próximo ao campo afetado
Nível de impácto
Alto
Status
Recomendado
Nível de evidênica
Forte evidência

Contexto

Durante o preenchimento ou após o envio de um formulário, a pessoa pode inserir dados ausentes, inválidos ou incompatíveis com as regras do serviço. Ela precisa identificar o problema, entender como corrigi-lo e retomar a tarefa sem perder o que já digitou.

Apresente a mensagem junto ao campo que precisa de correção e, quando houver vários problemas, repita a mesma informação em um resumo no início do formulário. Nomeie o campo usando o mesmo texto do rótulo, descreva o que foi aceito ou rejeitado e indique uma ação concreta para corrigir o valor.

Explique antecipadamente formatos, limites e requisitos previsíveis. Escolha o momento de validação de acordo com a tarefa: a validação durante o preenchimento pode orientar quando a regra é clara e o feedback é útil, enquanto a validação após o envio pode ser mais adequada quando o usuário ainda está explorando o formulário. Depois de uma falha, preserve os valores digitados, mantenha a mensagem disponível e permita que a pessoa retome a tarefa pelo campo relevante.

Dois campos de formulário em erro com borda vermelha, ícone de alerta e mensagem textual de correção
Exemplo real — Adobe Spectrum: campos em erro combinam borda, ícone e mensagem textual que orienta a correção. Fonte: Adobe Spectrum — Writing for errors: https://spectrum.adobe.com/page/writing-for-errors/

Porque isso importa?

Uma mensagem específica reduz a incerteza entre o que a pessoa fez e o que o sistema espera. “Ocorreu um erro” obriga o usuário a investigar; já uma mensagem que identifica o campo, explica o problema e aponta a correção transforma a falha em uma próxima ação compreensível.

Isso reduz retrabalho, evita que dados sejam digitados novamente e ajuda pessoas com limitações visuais, cognitivas, de linguagem ou de aprendizagem a entenderem por que o envio não foi concluído. Em formulários com vários erros, a combinação de resumo e mensagens próximas aos campos diminui a necessidade de procurar a origem do problema.

Use esse padrão quando o sistema conseguir detectar que uma entrada está ausente, fora do formato esperado ou fora dos valores permitidos.

  • Quando um campo obrigatório não foi preenchido.
  • Quando um valor está em formato incorreto, como um e-mail ou uma data.
  • Quando um número está fora de um intervalo ou uma opção não é permitida.
  • Quando o envio falha por uma combinação de valores que o sistema consegue explicar.
  • Quando vários campos apresentam problemas e o usuário precisa localizar cada um deles.

Não use uma mensagem de erro de campo para problemas que a pessoa não consegue resolver alterando a própria entrada. Indisponibilidade do serviço, falta de permissão e inelegibilidade exigem uma comunicação de serviço própria, com contexto e próximos passos.

  • Evite acusar erro antes de a pessoa ter tido oportunidade razoável de preencher o campo.
  • Evite usar apenas um alerta temporário quando a correção exige consulta ou edição.
  • Evite transformar uma escolha de interface em requisito universal: mensagem inline, resumo, foco e momento de validação dependem do fluxo.
Exemplo do CMS Design System com resumo de erros no topo e mensagens junto aos campos
Exemplo real — CMS Design System: o padrão reúne resumo de erros no topo e mensagens junto aos campos para ajudar a localizar e corrigir problemas. Fonte: CMS Design System — Error validation: https://design.cms.gov/patterns/Forms/error-validation/?theme=core&view=page

Recomendações

Faça

Práticas recomendadas
  • Explique as regras antes.
  • Identifique o campo pelo rótulo.
  • Descreva o problema.
  • Indique como corrigir.
  • Associe a mensagem ao campo.
  • Preserve os dados digitados.
  • Resuma vários erros.
  • Teste teclado, zoom e leitor de tela.
Wireframe de formulário com mensagem de erro associada ao campo inválido
A mensagem permanece associada ao campo afetado e orienta a correção, enquanto os demais valores continuam preservados.

Evite

Práticas a evitar
  • Não use mensagens vagas.
  • Não dependa só de cor.
  • Não valide cedo demais.
  • Não apague os dados.
  • Não confunda erro com falha do serviço.
  • Não faça a mensagem desaparecer.
Wireframe de formulário com alerta de erro distante do campo afetado
Um alerta genérico fica distante do campo afetado e não indica claramente como corrigir.
Campo de senha com mensagem contextual de alerta acompanhada de ícone e texto
Exemplo real — Padrão Digital GOV.BR: mensagem contextual próxima ao campo, com texto e ícone, sem depender apenas da cor. Fonte: Gov.br Design System — Message: https://www.gov.br/ds/components/message

Acessibilidade

As WCAG 2.2 exigem que um erro de entrada detectado automaticamente seja identificado e descrito em texto (Critério 3.3.1). Quando houver uma correção conhecida, ela deve ser sugerida, salvo quando isso comprometer a segurança ou a finalidade do conteúdo (Critério 3.3.3). A cor pode reforçar o estado, mas não pode ser a única forma visual de comunicar o erro (Critério 1.4.1).

Use rótulos associados aos controles, relações programáticas e mensagens que possam ser encontradas por teclado e tecnologias assistivas. Em implementação, associe a mensagem ao controle com HTML semântico e, conforme o caso, aria-describedby ou aria-errormessage; use aria-invalid="true" quando o valor tiver sido considerado inválido, não apenas porque um campo obrigatório ainda está vazio antes de uma tentativa de envio. Uma mensagem inserida dinamicamente pode usar uma região ao vivo ou role="alert", mas alertas assertivos devem ser reservados para informação importante e não devem roubar o foco.

O resumo de erros deve permitir navegar até cada campo relacionado. Valide a implementação com teclado, leitor de tela, zoom e diferentes configurações de contraste. Essas são exigências e técnicas de acessibilidade; a escolha entre validação inline, resumo, foco automático e momento de disparo continua dependente do contexto e deve ser testada com usuários.

Checklist

  • O texto identifica o campo?
  • A mensagem explica o problema?
  • A mensagem indica como corrigir?
  • O erro não depende de cor ou ícone?
  • A mensagem está associada ao campo?
  • Os dados são preservados?
  • O resumo aponta para os campos?
  • O erro não aparece cedo demais?
  • A solução foi testada com teclado, zoom e leitor de tela?

Referências

  • W3C — WCAG 2.2, Critério 3.3.1: Identificação de erros. Sustenta a exigência de identificar em texto o campo com erro e descrever o problema quando a entrada inválida é detectada automaticamente. Consultar o critério 3.3.1.
  • W3C — WCAG 2.2, Critério 3.3.3: Sugestão de correção. Sustenta a apresentação de uma correção conhecida, exceto quando ela comprometer a segurança ou a finalidade do conteúdo. Consultar o critério 3.3.3.
  • W3C — WCAG 2.2, Critério 1.4.1: Uso de cor. Sustenta que cor não deve ser o único meio visual para comunicar o estado de erro. Consultar o critério 1.4.1.
  • W3C — WCAG 2.2, Critério 1.3.1: Informações e relações. Sustenta que relações apresentadas visualmente, como a associação entre campo e mensagem, devem estar disponíveis de forma programática ou em texto. Consultar o critério 1.3.1.
  • W3C — WAI-ARIA 1.2, aria-invalid e aria-errormessage. Sustenta a exposição programática do estado inválido e da mensagem pertinente; a especificação orienta não marcar como inválido um campo obrigatório apenas porque ainda não foi preenchido antes da tentativa de envio. Consultar a especificação WAI-ARIA.
  • W3C — WAI-ARIA Authoring Practices Guide, padrão Alert. Sustenta o uso cuidadoso de alertas dinâmicos: eles não devem alterar o foco e não devem desaparecer rapidamente nem interromper a tarefa com frequência excessiva. Consultar o padrão Alert.
  • GOV.UK Design System — Error message. Sustenta mensagens próximas ao campo, alinhadas ao rótulo, claras e orientadas à correção; também recomenda não apagar os valores após a falha. É uma referência de implementação governamental, não uma regra universal para todo produto. Consultar o componente Error message.
  • GOV.UK Design System — Error summary. Sustenta resumir vários erros e vincular cada item do resumo à resposta correspondente para facilitar a localização. É uma referência de implementação governamental, não uma prova de que esse arranjo sirva a todos os fluxos. Consultar o componente Error summary.
  • Nielsen Norman Group — Error-Message Guidelines. Sustenta proximidade entre erro e origem, comunicação em linguagem humana, descrição precisa e cuidado com o momento de exibição para não punir a exploração da interface. Consultar as diretrizes de mensagens de erro.
  • Jakob Nielsen, Nielsen Norman Group — 10 Usability Heuristics, heurística 9. Sustenta que mensagens devem ajudar a reconhecer, diagnosticar e recuperar de erros, com linguagem simples, problema preciso e sugestão construtiva. Consultar as 10 heurísticas.
  • Padrão Digital de Governo (Gov.br) — componentes Message e Input. A documentação orienta usar a mensagem para comunicar feedback do sistema, inclusive erros, próxima ao elemento relacionado; o componente Input prevê feedback de erro associado ao campo. A cor deve ser acompanhada de informação textual. Design System; componente Message; componente Input.
  • AMAWeb — Manual e checklist de acessibilidade (UNIFESP). O manual orienta identificar o erro em texto, indicar o campo afetado e sugerir correção quando conhecida; a checklist traduz esses pontos em verificações sobre rótulos, mensagens descritivas, sugestões de correção e prevenção de erros. AMAWeb; Manual; Checklist de formulários.
Veja também

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