GitHub n’utilise plus les toasts

• L’interface de notification toast n’est plus recommandée chez GitHub en raison de problèmes d’accessibilité
• Une structure de notification temporaire qui disparaît automatiquement risque d’enfreindre les critères d’accessibilité visuelle et fonctionnelle (WCAG)
• GitHub propose comme alternatives des méthodes de retour persistantes et accessibles, comme les bannières (banner) et les boîtes de dialogue (dialog)
• Les toasts présentent aussi de nombreux problèmes d’utilisabilité, notamment sur les grands écrans, en multitâche et avec le phénomène d’ignorance des bannières
• Pour l’accessibilité et une expérience utilisateur cohérente, l’usage des toasts est abandonné dans l’ensemble du design system Primer

---

Présentation des toasts

• Un toast est une petite fenêtre de notification rectangulaire qui apparaît brièvement dans un coin inférieur de l’écran, déclenchée par l’utilisateur ou par une action du système
• Comme il disparaît automatiquement après un certain temps, ce modèle comporte des problèmes d’accessibilité et d’utilisabilité intrinsèques
• Pour cette raison, GitHub recommande des modes de communication plus stables et plus accessibles

Alternatives aux toasts

• Il faut choisir l’interface adaptée selon l’objectif d’usage
  • Pour une simple notification de succès, l’écran de résultat lui-même peut suffire sans retour séparé
  • Pour les opérations complexes, l’état de réussite peut être communiqué via une bannière ou un affichage progressif du contenu
  • En cas d’échec, fournir les informations d’erreur via une bannière ou une boîte de dialogue
• Pour la soumission de formulaire, une confirmation séparée n’est pas nécessaire pour un formulaire simple ; pour un formulaire complexe, utiliser une page de confirmation intermédiaire ou une bannière
• Pour la validation des saisies, utiliser les composants existants de validation de formulaire de Primer
• Pour les tâches de longue durée, communiquer l’état d’achèvement via une bannière ou via d’autres canaux comme l’e-mail ou les notifications push
• En cas de désynchronisation de session, indiquer la nécessité d’actualiser au moyen d’une boîte de dialogue ou d’une bannière

Considérations d’accessibilité (Accessibility Considerations)

• L’interface toast peut enfreindre plusieurs critères de succès WCAG
  • 2.2.1 Timing Adjustable (A) : elle doit rester affichée jusqu’à ce que l’utilisateur la ferme lui-même
  • 1.3.2 Meaningful Sequence (A) : une divergence entre l’ordre du DOM et l’ordre visuel peut créer de la confusion avec les technologies d’assistance
  • 2.1.1 Keyboard (A) : les interactions dans le toast doivent pouvoir être contrôlées au clavier
  • 4.1.3 Status Messages (AA) : sa présence doit être annoncée aux technologies d’assistance sans perturber l’utilisateur
• Autres critères susceptibles d’être enfreints
  • 1.4.4 Resize text (AA) : le redimensionnement du texte peut masquer l’écran ou provoquer un débordement
  • 1.4.10 Reflow (AA) : l’accessibilité au clavier doit être assurée en cas de défilement horizontal
  • 2.4.3 Focus Order (A) : l’ordre de focus peut devenir confus
  • 3.2.4 Consistent Identification (AA) : il faut préserver la cohérence du code

Considérations d’utilisabilité (Usability Considerations)

• Sur les grands écrans, les toasts peuvent se trouver hors du champ de vision et passer inaperçus
• Avec la disparition automatique, l’utilisateur risque de manquer le message s’il est occupé à autre chose
• Masquage de l’interface : le toast peut recouvrir des éléments importants comme les boutons du bas
• Les utilisateurs qui agrandissent l’écran peuvent ne pas voir les toasts situés hors de la zone agrandie
• Problème de mémoire de travail : la disparition automatique empêche de revérifier l’information
• Ignorance des bannières : un usage excessif pousse les utilisateurs à les ignorer
• Incohérence de position : la distance physique entre l’élément déclencheur et le toast peut brouiller leur relation
• Mauvais comportement de fermeture : la touche Esc peut fermer en même temps d’autres éléments de l’interface

Ressources complémentaires

• Notification messaging - Primer
• A toast to an accessible toast… - Scott O’Hara
• Defining ‘Toast’ Messages - Adrian Roselli
• The problem with toast messages and what to do instead - Adam Silver

[GN⁺]

Réactions sur Hacker News

• En donnant une conférence sur l’accessibilité, quelqu’un a subi un délai de 3 secondes après un clic, donnant l’impression qu’il ne se passait rien
  • En cliquant sur la bannière, il fallait attendre sans aucune indication, puis on finissait plus tard sur une page sans rapport, ce qui était frustrant
  • Il estime que le problème vient de l’absence de feedback indiquant qu’un chargement est en cours
  • Quelqu’un d’autre répond qu’il ne s’agit que d’un simple lien `` et que le délai vient seulement d’une page inutilement lourde
  • Une autre personne avance qu’en 4G lente, la réaction est immédiate, ce qui suggère plutôt un problème de navigateur ou de réseau
• La documentation de GitHub Primer lui a semblé intéressante
  • Même sans être d’accord avec tout, il y a des choses à en tirer, et c’est bien mieux que de faire les choses à l’instinct
  • À noter qu’Apple et Android proposent eux aussi leurs propres guidelines de design
• Certains espèrent enfin voir cette tendance se diffuser
  • Ils ont raté beaucoup trop de messages à cause des notifications toast
  • Un autre utilisateur dit être totalement d’accord avec la phrase « les toasts ne sont pas recommandés en raison de problèmes d’accessibilité » et souligne que même avec un centre de notifications, cela resterait une mauvaise approche, même si ce serait un peu mieux
• Pour l’un d’eux, les toasts sont utiles comme confirmation non intrusive, mais inadaptés pour transmettre des informations importantes
  • Une autre personne détaille plus précisément les contextes d’usage des toasts
    • Réaction immédiate à un clic sur un bouton → mieux vaut donner le feedback sur le bouton lui-même
    • Réaction à un raccourci clavier → acceptable
    • Notification de fin d’une tâche longue → acceptable, mais il faut un historique de notifications persistant
    • Avertissement affiché à l’entrée sur une page → si c’est important, cela doit apparaître dans la page comme une notification permanente
  • Dans React, l’appel global à toast() étant facile, il a tendance à être abusé, mais il est suggéré qu’une structure comme useAlerts() serait bien meilleure
• Les toasts sont pour lui une sorte de garrot
  • Pratiques pour contenir temporairement un problème urgent, mais à ne pas conserver sur le long terme
  • Dans un nouveau projet, on peut les ajouter provisoirement quand le feedback manque, puis les retirer un par un à mesure qu’on améliore l’UI
  • Une grande organisation comme GitHub n’a pas besoin de ce genre de solution de fortune, mais pour une petite équipe, la situation peut être différente
• Il a aimé le passage de la documentation GitHub disant qu’« en cas de création massive d’Issues, un feedback supplémentaire est nécessaire »
  • Il aimerait aussi ce type de feedback dans GitHub Actions, car le délai entre l’exécution et l’apparition du résultat est trop long
• L’idée d’utiliser les toasts comme journal d’activité de l’UI dans son ensemble lui plaît
  • Plutôt qu’un feedback qui disparaît à chaque clic, il existe des exemples bien réalisés comme Sonner
• Certains pensent qu’il est peut-être temps d’envisager une prise en charge native des toasts au niveau du navigateur
  • Cela permettrait sans doute d’améliorer l’accessibilité avec le réglage du timing, un centre de notifications, l’intégration avec les lecteurs d’écran, etc.
  • Visuellement, cela fonctionne, mais ils disparaissent trop souvent trop vite et passent inaperçus
  • Il est difficile de comprendre directement les problèmes rencontrés par les personnes malvoyantes ou aveugles, mais ils aimeraient savoir comment mieux améliorer leur accessibilité
• L’avantage des toasts, c’est qu’ils sont faciles à implémenter et demandent peu d’effort de design
  • Leur inconvénient, c’est qu’on les rate facilement et qu’ils risquent de se superposer à d’autres informations
  • S’il y a suffisamment de marge, mieux vaut selon eux supprimer tous les toasts
  • Une autre personne fait remarquer qu’« comme c’est facile à créer, ils sont souvent abusés comme rustine qui se fait passer pour une solution »
  • Une autre encore dit avoir utilisé les toasts comme simple feedback de réassurance
  • À l’inverse, quelqu’un soutient que « les toasts sont un outil utile pour fournir un feedback immédiat sur des événements peu importants », plus efficace qu’une fenêtre modale ou qu’une zone fixe
  • Il critique la vision binaire consistant à les exclure totalement au prétexte qu’un outil peut être mal utilisé
• Certains ont vu un article affirmant que « la suppression des toasts par GitHub est une mauvaise nouvelle pour l’accessibilité »
  • L’un d’eux trouve cette affirmation étrange
    • Il pense que dire que GitHub aurait dû, au lieu de supprimer les toasts, créer un standard de navigateur via le W3C est un raccourci exagéré
    • Pour lui, le simple fait de voir l’élément créé apparaître dans la liste constitue déjà un feedback suffisant
  • Une autre personne ajoute que « dire que les toasts sont mauvais pour l’accessibilité et l’UX, tout en reprochant à GitHub de ne pas les avoir standardisés dans le navigateur, est contradictoire »