Quando pedir confirmação antes de uma ação

Saiba quando pedir confirmação antes de uma ação, quando oferecer desfazer e como comunicar consequências sem criar atrito ou cliques automáticos.

Diálogo de confirmação sobre uma lista de itens, com alerta e opções para cancelar ou continuar.
Nível de impácto
Crítico
Status
Usar com atenção
Nível de evidênica
Forte evidência

Contexto

Saber quando pedir confirmação exige equilibrar prevenção de erros e fluidez. Uma confirmação adiciona uma pausa entre a intenção e o resultado. Essa pausa pode prevenir um erro grave, mas também interrompe a tarefa e ensina as pessoas a confirmar sem ler quando aparece em excesso.

A decisão não depende apenas de a ação ser chamada de “excluir”, “enviar” ou “alterar”. É preciso avaliar a reversibilidade, o alcance, a previsibilidade e o custo do engano. Uma ação rotineira que pode ser desfeita pede menos atrito; uma ação permanente, financeira, legal ou que afeta muitas pessoas pode exigir revisão ou confirmação explícita.

Antes de adicionar uma confirmação, avalie quatro fatores: o resultado pode ser desfeito, o dano potencial é alto, a consequência é esperada e quantas pessoas ou dados serão afetados. Quanto maior o custo do erro e menor a reversibilidade, maior a justificativa para interromper a tarefa.

Para ações rotineiras e recuperáveis, execute e ofereça “Desfazer” por tempo suficiente. Para decisões simples, imediatas e de alto risco, use um diálogo curto. Para compras, contratos, transferências ou envios com vários dados importantes, prefira uma etapa de revisão que permita conferir e corrigir antes da conclusão.

No diálogo, nomeie a ação e o objeto afetado: “Excluir projeto?” é mais útil que “Tem certeza?”. Explique a consequência, informe se há recuperação e mostre quantidade, destino ou alcance quando isso mudar a decisão. O botão de confirmação deve repetir o verbo específico, como “Excluir projeto”, “Remover acesso” ou “Enviar pagamento”; use “Cancelar” para a saída segura.

Reserve confirmações reforçadas — como digitar o nome do recurso — para ações irreversíveis com impacto amplo. O esforço adicional deve acompanhar o risco, não virar um ritual aplicado a toda exclusão.

Modal do Atlassian que informa a exclusão permanente de uma página e lista consequências antes de oferecer Cancelar e Excluir.
Exemplo real: o Atlassian Design System identifica a exclusão, explica impactos concretos — links quebrados e páginas dependentes — e oferece “Cancelar” e “Excluir”. Fonte: https://atlassian.design/components/modal-dialog/examples

Porque isso importa?

A prevenção de erros não significa bloquear toda ação. A heurística de prevenção de erros da Nielsen Norman Group recomenda eliminar condições propensas a enganos ou apresentar confirmação antes do comprometimento, priorizando erros de alto custo. A heurística de controle e liberdade também favorece saídas claras e recursos de desfazer.

A WCAG 2.2 exige proteção para compromissos legais, transações financeiras e alterações ou exclusões de dados controláveis pela pessoa. Essa proteção pode ser reversão, verificação ou revisão e confirmação; portanto, um modal não é a única solução nem deve aparecer em cada salvamento.

Confirmações repetitivas geram habituação: a pessoa aprende que o segundo clique é parte do fluxo e deixa de examinar a mensagem. Ajustar o atrito à gravidade preserva a atenção para os momentos em que a decisão realmente importa.

  • Antes de uma ação irreversível.
  • Quando o erro pode causar perda significativa.
  • Em compromissos legais ou financeiros.
  • Ao excluir muitos itens ou usuários.
  • Ao remover acesso, propriedade ou permissões.
  • Quando a consequência não é evidente pelo contexto.
  • Antes de publicar ou enviar para muitas pessoas.
  • Em ações rotineiras e reversíveis.
  • Quando “Desfazer” resolve o risco.
  • Após todo salvamento ou pequena edição.
  • Para repetir uma decisão já revisada.
  • Como aviso meramente informativo.
  • Quando a consequência já é óbvia e recuperável.
  • Para compensar rótulos de ação ambíguos.
Comparação do PatternFly entre uma confirmação destrutiva genérica e outra que identifica o registro e os dados que serão perdidos.
Exemplo real: o PatternFly compara uma confirmação genérica com outra que nomeia o registro e comunica quais dados serão perdidos antes da ação destrutiva. Fonte: https://www.patternfly.org/components/modal/design-guidelines/

Recomendações

Faça

Práticas recomendadas
  • Avalie o custo do erro.
  • Prefira ações reversíveis.
  • Nomeie o objeto afetado.
  • Explique a consequência.
  • Informe o alcance.
  • Use verbos específicos.
  • Ofereça “Cancelar”.
  • Preserve o contexto.
  • Confirme o resultado.
Diálogo que identifica o objeto afetado, explica a consequência e oferece uma saída segura antes da ação destrutiva.
Exemplo correto: a confirmação identifica a ação e o objeto, explica a consequência e oferece opções específicas para cancelar ou prosseguir.

Evite

Práticas a evitar
  • Não confirme toda ação.
  • Não pergunte “Tem certeza?”.
  • Não use “Sim” ou “OK”.
  • Não esconda consequências.
  • Não dependa só do vermelho.
  • Não destaque o risco errado.
  • Não force digitação sem necessidade.
  • Não empilhe diálogos.
  • Não remova a saída segura.
Diálogo genérico com duas ações iguais e sem informação sobre a consequência ou o objeto afetado.
Exemplo incorreto: uma pergunta genérica com botões “Sim” e “Não” não revela o que acontecerá, o alcance da decisão nem se a ação pode ser desfeita.
Exemplo do Carbon que identifica um dispositivo e apresenta informações e dependências relacionadas antes da exclusão.
Exemplo real: o IBM Carbon apresenta uma confirmação de alto impacto que identifica o recurso e reúne informações e dependências afetadas antes da ação final. Fonte: https://v10.carbondesignsystem.com/components/modal/usage/#danger-modal

Acessibilidade

Implemente a confirmação como diálogo modal com nome e descrição programáticos. Ao abrir, mova o foco para dentro do diálogo, torne o conteúdo ao fundo inerte e mantenha a navegação por teclado no modal. Ao fechar, devolva o foco ao controle que iniciou a ação ou a outro ponto lógico se esse controle deixou de existir.

Em ações perigosas, prefira o foco inicial na opção segura, sem tornar o botão destrutivo a ação padrão da tecla Enter. A tecla Escape deve equivaler a cancelar quando isso não contrariar um requisito essencial. Os rótulos precisam fazer sentido quando anunciados isoladamente; “Excluir projeto” e “Cancelar” são mais claros que “Sim” e “Não”.

Não use cor, ícone ou posição como únicos sinais de risco. Associe título, consequência e controles com aria-labelledby e aria-describedby, preserve ampliação e leitura sem rolagem horizontal e teste teclado, leitor de tela, zoom, contraste e diferentes tamanhos de texto.

Checklist

  • A ação pode ser desfeita?
  • O dano potencial justifica a interrupção?
  • A consequência é inesperada?
  • O alcance está claro?
  • Uma opção “Desfazer” seria suficiente?
  • Uma etapa de revisão seria mais adequada?
  • O título nomeia a ação e o objeto?
  • A mensagem explica a consequência?
  • Está claro se existe recuperação?
  • O botão repete o verbo da ação?
  • A saída segura está visível?
  • O botão perigoso não depende apenas de cor?
  • O foco inicial evita confirmação acidental?
  • Escape e “Cancelar” têm comportamento coerente?
  • O foco retorna a um ponto lógico?
  • A solução foi testada com teclado, leitor de tela e zoom?

Referências

  • Nielsen Norman Group — Error Prevention. Recomenda eliminar condições propensas a erros ou verificar a intenção antes do comprometimento, priorizando a prevenção de consequências de alto custo. Consultar a heurística.
  • Nielsen Norman Group — User Control and Freedom. Sustenta saídas claras, cancelamento e recursos de desfazer para que as pessoas possam abandonar ou reverter ações iniciadas por engano. Consultar a heurística.
  • W3C WAI — Error Prevention: Legal, Financial, Data. Define que transações e alterações importantes devem ser reversíveis, verificadas ou passíveis de revisão e confirmação; também esclarece que o critério não exige confirmação para todo salvamento ou edição simples. Consultar o critério.
  • W3C WAI — Technique G168. Orienta pedir confirmação quando uma ação não pode ser desfeita e comunicar tanto a ação selecionada quanto as consequências de continuar. Consultar a técnica.
  • Apple Human Interface Guidelines — Alerts. Recomenda alertas apenas para informações críticas e ações importantes ou irreversíveis; para ações comuns e recuperáveis, orienta evitar a interrupção. Também favorece títulos e botões específicos em vez de “OK”, “Sim” e “Não”. Consultar a orientação.
  • GitHub Primer — Delete pattern. Propõe ajustar o atrito ao custo do erro, preferir desfazer para ações reversíveis e reservar digitação de confirmação para exclusões irreversíveis de grande alcance. Consultar o padrão.
  • GitHub Primer — ConfirmationDialog accessibility. Detalha títulos e botões orientados à ação, foco inicial seguro, retorno do foco, navegação por teclado e nomes acessíveis para diálogos de confirmação. Consultar a acessibilidade.
  • IBM Carbon — Modal. Diferencia o modal transacional do modal de perigo e recomenda este último para decisões destrutivas ou irreversíveis com risco de perda significativa de dados. Consultar o componente.
  • Atlassian Design System — Modal dialog: Danger. Demonstra uma confirmação destrutiva que nomeia a exclusão, informa efeitos concretos sobre links e páginas dependentes e apresenta uma saída segura antes de continuar. Consultar o exemplo.
  • PatternFly — Modal design guidelines. Compara uma confirmação genérica com outra que identifica o registro e descreve os dados que serão perdidos, além de recomendar confirmação reforçada quando a consequência é grave. Consultar a orientação.
Veja também

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