GitHub não usa mais Toasts

 (primer.style)
16 pontos por GN⁺ 2025-12-12 | 1 comentários | Compartilhar no WhatsApp
  • A UI de notificações Toast não é mais recomendada no GitHub devido a problemas de acessibilidade
  • A estrutura de notificação temporária que desaparece automaticamente pode correr o risco de violar critérios de acessibilidade visuais e funcionais (WCAG)
  • O GitHub apresenta banners e diálogos como alternativas de feedback persistente e acessível
  • Toasts também incluem vários problemas de usabilidade, como telas grandes, multitarefa e o fenômeno de ignorar banners
  • Para acessibilidade e uma experiência de usuário consistente, o uso de Toasts foi descontinuado em todo o sistema de design Primer

Visão geral dos Toasts

  • Toasts são pequenas janelas de notificação retangulares que aparecem por pouco tempo no canto inferior da tela, acionadas por ações do usuário ou do sistema
  • Como desaparecem automaticamente após certo tempo, têm problemas inerentes de acessibilidade e usabilidade
  • Por esses motivos, o GitHub recomenda formas de comunicação mais estáveis e acessíveis

Alternativas aos Toasts

  • É necessário escolher a UI adequada conforme o objetivo de uso
    • Notificações simples de sucesso podem ser confirmadas pela própria tela de resultado, sem feedback adicional
    • Trabalhos mais complexos podem comunicar o estado de sucesso com banners ou exibição progressiva de conteúdo
    • Operações com falha devem fornecer informações de erro por meio de banners ou diálogos
  • No caso de envio de formulários, formulários simples não precisam de confirmação extra; formulários complexos podem usar uma página intermediária de confirmação ou um banner
  • Para validação de entrada, usar os componentes de validação de formulários já existentes no Primer
  • Tarefas de longa duração devem comunicar a conclusão por meio de banners ou outros canais, como e-mail e notificações push
  • Quando ocorrer dessincronização de sessão, usar diálogos ou banners para informar a necessidade de recarregar

Considerações de acessibilidade (Accessibility Considerations)

  • A UI de Toast pode violar vários critérios de sucesso da WCAG
    • 2.2.1 Timing Adjustable (A) : deve permanecer até que o usuário a feche manualmente
    • 1.3.2 Meaningful Sequence (A) : divergências entre a ordem no DOM e a ordem visual podem causar confusão para quem usa tecnologias assistivas
    • 2.1.1 Keyboard (A) : deve ser possível controlar interações dentro do toast com o teclado
    • 4.1.3 Status Messages (AA) : sua presença deve ser comunicada às tecnologias assistivas de forma não intrusiva
  • Critérios com possibilidade adicional de violação
    • 1.4.4 Resize text (AA) : ao ajustar o tamanho do texto, há risco de encobrir a tela ou causar overflow
    • 1.4.10 Reflow (AA) : é necessário garantir acessibilidade por teclado quando houver rolagem horizontal
    • 2.4.3 Focus Order (A) : pode haver confusão na ordem de foco
    • 3.2.4 Consistent Identification (AA) : é necessário manter consistência no código

Considerações de usabilidade (Usability Considerations)

  • Em telas grandes, o toast pode ficar fora do campo de visão e passar despercebido
  • Com o desaparecimento automático, há risco de o usuário perder a mensagem enquanto faz outra tarefa
  • Obstrução da UI: o toast pode cobrir elementos importantes, como botões na parte inferior
  • Usuários com zoom na tela podem não ver toasts fora da área ampliada
  • Problema de memória de trabalho: como desaparece automaticamente, não é possível revisar a informação depois
  • Fenômeno de ignorar banners: com uso excessivo, usuários tendem a ignorá-los
  • Inconsistência de posição: a distância física entre a UI que acionou a notificação e o toast pode gerar confusão sobre a relação entre ambos
  • Fechamento incorreto: a tecla Esc pode acabar fechando também outras UIs

Materiais de referência adicionais

Leituras relacionadas

1 comentários

 
GN⁺ 2025-12-12
Comentários do Hacker News
  • Ao dar uma palestra sobre acessibilidade, alguém passou por uma situação em que havia um atraso de 3 segundos após o clique, dando a sensação de que não havia reação nenhuma
    • Ao clicar no banner, a pessoa ficava esperando sem qualquer indicação e, depois, acabava sendo levada para uma página sem relação, o que foi frustrante
    • A pessoa acha que o problema é a falta de feedback informando que algo está carregando
    • Alguém disse que aquilo era apenas um link `` e que o atraso era só consequência de a página estar desnecessariamente pesada
    • Outra pessoa levantou a possibilidade de ser um problema do navegador ou da rede, dizendo que mesmo em 4G lento a reação é imediata
  • A pessoa achou interessante ler a documentação do GitHub Primer
    • Mesmo sem concordar com tudo, há coisas a aprender, e parece muito melhor do que fazer no feeling
    • Como referência, Apple e Android também fornecem suas próprias diretrizes de design
  • Espera-se que essa tendência finalmente se espalhe
    • Muitas mensagens já foram perdidas por causa de notificações em toast
    • Outro usuário concorda totalmente com a frase “toasts não são recomendados por questões de acessibilidade” e enfatiza que, com uma central de notificações, ainda seria menos ruim, mas continuaria sendo uma abordagem ruim
  • Eu gosto de toast como confirmação não intrusiva, mas acho inadequado para transmitir informações importantes
    • Outra pessoa explicou em detalhes os contextos de uso de toast
      • Reação imediata ao clicar em botão → é melhor dar feedback no próprio botão
      • Reação a atalho de teclado → tudo bem
      • Notificação de conclusão de tarefa demorada → tudo bem, mas precisa de uma caixa de notificações persistente
      • Exibir alerta ao entrar na página → se for importante, deveria aparecer como um aviso permanente dentro da página
    • Em React, como é fácil chamar toast() globalmente, há tendência de abuso, mas foi sugerido que uma estrutura como useAlerts() é muito melhor
  • Para mim, toast é como um torniquete
    • É útil para conter temporariamente um problema urgente, mas não deve ser mantido no longo prazo
    • Em projetos novos, pode ser colocado provisoriamente quando falta feedback e depois removido aos poucos à medida que a UI melhora
    • Uma organização grande como o GitHub pode não precisar desse tipo de solução temporária, mas times pequenos podem ser diferentes
  • Gostei da parte da documentação do GitHub que diz que “é necessário feedback adicional ao criar muitos Issues em lote”
    • Seria bom ter esse tipo de feedback também no GitHub Actions, porque demora demais até o resultado aparecer depois da execução
  • Gostei da ideia de usar toast como log de ações em toda a UI
    • Em vez de um feedback que some a cada clique, há exemplos bem implementados, como o Sonner
  • Parece que já está na hora de considerar suporte nativo a toast no navegador
    • Isso poderia melhorar a acessibilidade com controle de tempo, central de notificações, integração com leitores de tela etc.
    • Visualmente ele pode funcionar bem, mas muitas vezes desaparece rápido demais e acaba passando despercebido
    • É difícil entender diretamente os problemas vividos por pessoas com deficiência visual, mas gostaria de ouvir formas de melhorar a acessibilidade para elas
  • A vantagem do toast é que ele é fácil de implementar e exige pouco esforço de design
    • A desvantagem é que é fácil perder a mensagem e há risco de ela ficar sobreposta a outras informações
    • Se houver folga, parece melhor eliminar todos os toasts
    • Outra pessoa apontou que “como é fácil de fazer, ele acaba sendo abusado como um remendo que finge resolver o problema”
    • Outra pessoa disse que usava toast apenas como um feedback de tranquilização
    • Em contrapartida, houve quem defendesse que “toast é uma ferramenta útil para dar feedback imediato sobre eventos de baixa importância”, sendo mais eficiente do que modais ou áreas fixas
    • Também houve crítica à visão preto no branco de excluir totalmente uma ferramenta só porque ela é usada em excesso
  • Vi um texto dizendo que “a remoção dos toasts pelo GitHub é uma má notícia para a acessibilidade”
    • Alguém achou esse argumento estranho
      • Parece um salto lógico dizer que, em vez de remover os toasts, o GitHub deveria ter criado um padrão de navegador por meio do W3C
      • A pessoa considera que o simples fato de o item criado aparecer na lista já é feedback suficiente
    • Outra pessoa disse que “afirmar que toast faz mal para acessibilidade e UX, mas criticar o GitHub por não tê-lo padronizado no navegador, é contraditório”