Alertas
Resumo
Um componente de Alerta é um elemento UI usado para comunicar informações importantes ou urgentes aos usuários.
O Alert geralmente é exibido em uma forma de janela pop-up ou banners que chamam a atenção dos usuários, exibindo uma ação ou informando sobre eventos ou problemas relevantes.
Esses componentes podem ser utilizados para diversos propósitos, como erros, avisos, confirmações, ou sucesso em uma ação realizada. Eles são muito versáteis e podem ser personalizados em relação à cor, ícone, tamanho, e conteúdo de acordo com a mensagem que se deseja transmitir.
Nota de terminologia
"Alert" é frequentemente usado como nome base para uma família de componentes com necessidades parecidas mas comportamentos distintos:
Toast, Banner, Notification, Inline alert e Confirmation (modal)
Tratar todos como um único componente costuma gerar um componente inchado, com dezenas de propriedades conflitantes.
A recomendação de design system é separar por comportamento (onde aparece, se bloqueia a tela, se some sozinho, se exige ação) e reservar "Alert" para o nome do grupo. As variações abaixo refletem essa separação.
Anatomia
Ícone (opcional): Indica visualmente o tipo de mensagem (opcional).
Título: Informa de forma direta o assunto.
Botão de Fechar: Essencial para notificações não intrusivas.
Mensagem/Conteúdo: O texto explicativo (opcional).
Grupo de Botões (Ações) (opcional): Inclui ação primária e secundária se houver necessidade de interação.
Contêiner: A “caixa” que abriga os elementos, onde se define padding, largura e altura
Estados de resposta
Sucesso: Confirma que algo deu certo. Geralmente representado por um ícone de “check”.
Erro: Para falhas críticas ou bloqueios. Cor de maior urgência (vermelho), normalmente não auto-dispensável.
Alerta (atenção/warning): Para avisos que requerem cautela mas não bloqueiam.
Neutro/Informativo: Mensagens do sistema sem caráter de urgência.
Loading: Indica que o sistema está processando uma resposta à ação do usuário (estado transitório, normalmente seguido por sucesso ou erro).
Estados de interação
O contêiner do alerta em si geralmente não é interativo, então estados como hover e pressed não se aplicam a ele. Esses estados pertencem aos subcomponentes internos.
Empilhamento (stack)
Quando o sistema gera muitas notificações simultâneas (geralmente mais de três), usa-se agrupamento ou stack (empilhamento) para evitar a poluição visual. O padrão é empilhar com leve sobreposição e um contador (“+3”), permitindo expandir.
Empilhar também ajuda a não disparar várias regiões de anúncio ao mesmo tempo para leitores de tela (ver Acessibilidade).
Variações
Notificações (Alertas informativos)
As notificações informam sobre eventos e atualizações relevantes, como a confirmação de uma transação ou o recebimento de uma mensagem (estilo push notification).
Comportamento: Podem ser persistentes ou temporárias. Diferente do toast, normalmente “vivem” num menu/central de notificações, podendo ser consultadas depois.
Localização: Geralmente nos cantos da tela (superior ou inferior), fora do fluxo principal.
Questionamentos antes de usar:
A mensagem foi disparada por um evento assíncrono?
O usuário pode querer consultar essa mensagem mais tarde, e não só no instante em que ela aparece?
A tarefa atual do usuário continua sem ser bloqueada?
É um erro que impede o usuário de prosseguir? (deve ser não — nesse caso use inline ou banner)
Mensagens
Breve e conciso. Uma frase ou poucas palavras. Aparece para indicar o status de uma ação que acabou de ser realizada (salvou, alterou, adicionou, excluiu) ou um status temporário do sistema.
Útil para confirmar ações de uma parte da interface que não está mais visível.
Comportamento: Flutua sobre a interface sem bloquear. Pode ser dispensável (opcional) e a ação pode ser desfeita (opcional).
Localização: Sobre a interface, posicionada de modo a não obscurecer as ações principais.
Questionamentos antes de usar:
A mensagem confirma o status de uma ação que o usuário acabou de realizar?
O texto cabe em uma frase curta?
O usuário consegue continuar a tarefa mesmo se ignorar a mensagem?
A mensagem precisa obscurecer ou substituir o conteúdo principal para ser entendida? (deve ser não)
Mensagem vs Tooltip
As tooltips são normalmente usadas para fornecer informações mais detalhadas sobre um elemento ou instruções sobre como usar.
Em vez disso, as notificações são normalmente usadas para fornecer um breve feedback sobre uma ação realizada pelo usuário.
Toast
Um toast é um alerta contextual com mensagem não crítica, normalmente em resposta a uma ação. Some após alguns segundos e não deve interromper a tarefa atual.
Costuma oferecer a opção de desfazer (undo) a ação recém-executada.
Comportamento: Aparece e some sozinho após alguns segundos, sem exigir ação. Não deve interromper a tarefa atual.
Localização: Geralmente na parte inferior da tela (também pode ser num canto), flutuando sobre a interface.
Questionamentos antes de usar:
A mensagem não é crítica?
É aceitável que a mensagem desapareça sozinha em poucos segundos?
A única ação oferecida é opcional?
É uma mensagem de erro crítico ou algo que o usuário precisa obrigatoriamente resolver? (deve ser não — use inline, banner ou modal)
Notification Banner
Os banners podem ser usados para mensagens de erro ou alertas. Isso pode ser mais eficaz se o banner for estilizado com as cores de aviso vermelho ou amarelo da marca.
Comportamento: Permanece visível até a condição mudar ou o usuário dispensá-lo (quando não for crítico). Não some sozinho.
Localização: Ocupa uma faixa no topo da página ou de uma seção, dentro do fluxo (empurra o conteúdo) ou fixo no topo.
Questionamentos antes de usar:
A mensagem reflete um status global ou da página que afeta a experiência?
A informação precisa ficar visível por um período prolongado, e não apenas alguns segundos?
A mensagem se aplica à tela/seção inteira, e não a um único campo ou elemento?
Inline alert (contextual)
Mensagem posicionada junto ao elemento a que se refere (por exemplo, abaixo de um campo de formulário com erro de validação). É a melhor opção para erros de formulário, porque coloca a mensagem exatamente onde a correção precisa acontecer.
Comportamento: Persistente e contextual. Não flutua nem bloqueia; vive no conteúdo da página, aparecendo e desaparecendo conforme o estado do elemento associado.
Localização: Diretamente adjacente ao elemento que descreve (abaixo do campo, ao lado da seção), dentro do fluxo da página.
Questionamentos antes de usar:
A mensagem se refere a um elemento específico da tela, e não à página inteira?
A correção ou o contexto da mensagem acontece naquele mesmo lugar da interface?
É um erro de validação de formulário?
A mensagem precisa interromper o usuário ou flutuar sobre o conteúdo? (deve ser não)
Confirmation modal
Pede que o usuário verifique uma ação antes de prosseguir. Usado para ações destrutivas ou ações de criação consequentes (ex.: publicar um artigo). Deve declarar explicitamente o resultado e as consequências. É o único caso dessa família em que duas ou mais ações de peso (confirmar/cancelar) são apropriadas.
Comportamento: Impede outras interações até o usuário tomar uma decisão. Não some sozinho.
Localização: Centralizado sobre a tela, geralmente com um overlay escurecendo o fundo para focar a atenção.
Questionamentos antes de usar:
A ação é destrutiva ou irreversível?
A consequência justifica interromper completamente o usuário e bloquear a tela?
O usuário precisa escolher entre duas ou mais ações de peso?
A ação é comum e facilmente reversível (ex.: excluir um e-mail com undo)? (deve ser não — nesse caso evite o modal e use toast com desfazer
Resumo
Situação | Componente recomendado | Bloqueia a tela? | Some sozinho? |
|---|---|---|---|
Confirmar ação leve recém-feita (salvar, curtir, enviar) | Toast/Mensagem | Não | Sim |
Erro de validação em um campo | Inline Alert | Não | Não |
Status global da página (manutenção, pagamento pendente, offline) | Banner | Não | Não |
Evento assíncrono (novo comentário, mensagem recebida) | Notification | Não | Opcional |
Ação destrutiva ou irreversível (excluir, publicar) | Modal | Sim | Não |
Informação passiva e dispensável (cookies, promoção de evento) | Banner/Inline | Não | Não |
Boas práticas
Use alertas com moderação
Alertas fornecem informação importante, mas interrompem a tarefa em andamento. A própria infrequência é o que faz as pessoas levarem os alertas a sério. Garanta que cada um ofereça apenas informação essencial e ação útil. Evite, por exemplo, mostrar alertas logo na abertura do app.
Evite usar alertas só para informar
As pessoas não gostam de ser interrompidas por um alerta que não permite nenhuma ação. Se precisa apenas informar, prefira comunicar dentro do contexto relevante (texto na própria tela, estado vazio, inline) em vez de interromper.
Apoie apenas uma ação principal por vez
Se o usuário precisa escolher entre duas ou mais ações de peso, use um modal. Use botão para iniciar uma ação/fluxo e link para navegar a uma página informativa; não use botão como navegação disfarçada.
Considere níveis de severidade
Um bom componente responde a toda a gama — de neutro/informativo até urgente. Modele isso de forma consistente combinando os três sinais juntos: cor + ícone + texto. Nunca dependa só da cor.
Não permita dispensar mensagens críticas
Reserve o botão de fechar para mensagens que não terão consequências dramáticas se forem dispensadas. Mensagens críticas devem permanecer até serem resolvidas.
Não combine alertas diferentes ao mesmo tempo
Evite exibir mais de um alerta simultâneo ou misturar severidades diferentes na mesma tela. Se há muita coisa a comunicar, prefira texto na tela, agrupar (stack) ou repensar a hierarquia.
Escreva copy curta e acionável
Mensagem com 1 a 2 frases. Se precisar de mais, linke para outra tela em vez de alongar. Não coloque links no meio do corpo do texto (o usuário pode não saber onde clicar ou perder informação) — concentre o link/ação depois da mensagem principal. O texto da ação deve ter verbo e ser sucinto (1 a 2 palavras): “Desfazer”, “Tentar de novo”, “Ver fatura”.
Acessibilidade
A
O tipo do alerta (sucesso, erro, aviso, info) não pode ser comunicado só por cor (WCAG 1.4.1).
Quando um alerta some sozinho por tempo (toast), o usuário precisa poder desligar, ajustar ou estender esse tempo — a menos que a mesma informação esteja disponível de outra forma (WCAG 2.2.1).
Ícones de tipo e o "x" de fechar precisam de nome textual equivalente (WCAG 1.1.1).
A mensagem e a instrução de uso não podem depender só de característica sensorial — posição ou cor (WCAG 1.3.3).
Quando a mensagem indica um erro, ela precisa descrever o erro em texto, não só por cor ou ícone (WCAG 3.3.1).
AA
O texto do título e do corpo do alerta precisa de contraste de pelo menos 4.5:1 contra o fundo do contêiner (WCAG 1.4.3).
O ícone de tipo, a borda do contêiner e o "x" de fechar precisam de pelo menos 3:1 contra a cor adjacente (WCAG 1.4.11).
Os controles do alerta — botões de ação, "x" de fechar — precisam de área de toque de no mínimo 24×24px (WCAG 2.5.8).
O indicador de foco precisa estar visível nos controles do alerta alcançados por teclado (WCAG 2.4.7).
Ao receber foco, o controle não pode ficar escondido, e o alerta não pode cobrir o conteúdo ou o controle que tem foco atrás dele (WCAG 2.4.11).
AAA
O texto do alerta com contraste de 7:1 contra o fundo do contêiner (WCAG 1.4.6).
Os controles do alerta com área de toque de no mínimo 44×44px (WCAG 2.5.5).
O indicador de foco com espessura equivalente a um perímetro de 2px ao redor do controle e contraste de 3:1 entre focado e não-focado (WCAG 2.4.13).
As interrupções podem ser adiadas ou suprimidas pelo usuário, exceto em emergências (WCAG 2.2.4).
Referências
https://componentes.design/aulas/alerta
https://coyleandrew.medium.com/design-better-alerts-2e2ee238afde
https://uxdesign.cc/a-taxonomy-for-alerts-and-notifications-3bffb051b5d5
https://goodpractices.design/components/alerts
https://developer.apple.com/design/human-interface-guidelines/alerts