coastdigitalgroup/coastai-skills

Système de Toasts et Snackbars

Objectif

Le système de Toasts et Snackbars fournit une méthodologie pour concevoir des couches de notification temporaires et non perturbatrices. Ce sont des composants d'interface brefs, qui se ferment automatiquement ou manuellement, situés dans une couche d'écran dédiée au-dessus de l'interface principale. Contrairement aux superpositions modales, ils ne détournent pas le focus et n'interrompent pas le flux de l'utilisateur ; ils servent plutôt de « boucle d'accusé de réception » passive et très visible, confirmant qu'une tâche en arrière-plan ou immédiate a réussi, a échoué ou nécessite une attention mineure. Ce système garantit que les toasts sont visuellement unifiés, positionnés pour ne pas bloquer les contrôles vitaux, et pleinement accessibles aux utilisateurs de souris, tactile et technologies d'assistance.

Cas d'utilisation

• Actions asynchrones : Confirmation qu'un fichier a été téléchargé, qu'un brouillon a été sauvegardé ou qu'un enregistrement a été supprimé en arrière-plan.
• Confirmation de micro-engagement : Accuser réception d'actions comme l'ajout d'un produit au panier, la copie d'un lien dans le presse-papiers ou le basculement d'une préférence système localisée.
• Opérations destructrices réversibles : Notifier un utilisateur qu'un élément a été archivé ou supprimé, associé à une action « Annuler » immédiate dans la snackbar.
• Mises à jour de statut transitoires : Afficher de brèves alertes système automatisées, comme le passage à un état « Hors ligne » ou « En ligne ».

Quand NE PAS utiliser

• Blocages système à haute gravité : Si une erreur critique nécessite une intervention immédiate ou bloque la progression de l'utilisateur (par exemple, session expirée, échec de paiement) ; utiliser overlay-and-dialog-system (Modal).
• Avertissements persistants de section : Si un avertissement ou une erreur concerne spécifiquement une section, une page ou un contexte de formulaire entier et doit rester visible jusqu'à sa résolution ; utiliser banner-and-alert-system (Alerte en ligne).
• Messages de validation de formulaire : Si un utilisateur commet une erreur dans un champ de saisie spécifique ; utiliser form-design-system (validation au niveau du champ).
• Découverte de contenu principal : Ne jamais utiliser les toasts pour présenter du contenu principal, des annonces marketing ou des options de navigation.

Entrées

1. Gravité / Type du message : Succès (confirmation), Information (mises à jour neutres), Avertissement (préoccupation non bloquante) ou Erreur (échec de l'opération).
2. Exigences d'action : Le retour est-il passif (lecture seule) ou inclut-il une micro-action unique (par exemple, « Annuler », « Voir », « Réessayer ») ?
3. Espace à l'écran et classe d'appareil : Zones d'affichage cibles (desktop, tablette, mobile) et méthodes de saisie prédominantes (survol de souris vs. portée du pouce).
4. Stratégie d'index Z et de superposition : Règles de contexte d'empilement pour éviter le chevauchement avec la navigation d'en-tête, les pieds de page fixes ou les superpositions actives.

Sorties

1. Spécification de l'anatomie : Plan basé sur une grille du conteneur, de l'emplacement de l'icône, de la chaîne de message, du CTA d'action et du bouton de fermeture manuelle.
2. Règles d'alignement spatial et de placement : Coordonnées adaptatives pour desktop (par exemple, pile en haut à droite ou en bas à droite) et mobile (par exemple, glissement vers le haut en pleine largeur en bas).
3. Logique de file d'attente et d'empilement : Règles système pour gérer les alertes simultanées, les limites maximales visibles et le séquencement d'expiration.
4. Chronologie interactive et spécification d'expiration : Règles régissant les délais d'auto-suppression, les comportements de pause au survol et les gestes de balayage.
5. Plan d'accessibilité / ARIA : Mappage sémantique des régions live, gestion du focus pour les toasts interactifs et annonces pour les lecteurs d'écran.

Flux de travail

1. Structurer l'anatomie du composant

Définir une grille d'espacement et de disposition précise pour le conteneur de toast en utilisant des jetons spatiaux standard :

• Emplacement de l'icône : Largeur fixe (par exemple, 20px ou 24px) positionnée à l'extrême gauche. Utiliser des icônes de statut sémantiques à contraste élevé (coche pour Succès, triangle d'exclamation pour Avertissement/Erreur, cercle d'information pour Info).
• Zone de texte : Typographie alignée à gauche, avec retour à la ligne, composée d'un titre bref (gras, facultatif) et d'une description. Ne jamais tronquer le texte avec des points de suspension ; le faire passer à la ligne jusqu'à un maximum de 3 lignes.
• Emplacement d'action (facultatif) : Un seul bouton texte très visible (par exemple, « Annuler ») placé à droite du message. Pour un texte long sur mobile, passer l'action à une nouvelle ligne alignée à droite.
• Déclencheur de fermeture : Un bouton de fermeture clair 'X' placé à l'extrême droite. Doit avoir une zone de clic minimale de 24x24px (44x44px de préférence pour les cibles tactiles).

2. Déterminer le placement spatial par zone d'affichage

• Placement desktop : Positionner la pile de conteneurs de toasts dans le coin Haut-droit ou Bas-droit de l'écran. Maintenir un décalage constant de 24px par rapport aux bords de la zone d'affichage.
  • Pile en haut à droite : Meilleur lorsque le flux d'actions principal se produit dans les parties inférieures de la page.
  • Pile en bas à droite : Meilleur lorsque les barres de navigation ou d'utilitaires montées en haut occupent la marge supérieure, empêchant le chevauchement.
• Placement mobile : Transformer la pile desktop en une Snackbar ancrée en bas et pleine largeur (marges de 12px à 16px par rapport aux bords gauche, droit et inférieur). Cela maintient l'interaction dans la « zone de portée optimale du pouce ».
• Règle d'index Z : Toujours attribuer un jeton d'index Z dédié (par exemple, z-index: 5000 ou plus) qui place les toasts au-dessus des en-têtes fixes standard (z-index: 1000) mais en dessous des superpositions plein écran actives (z-index: 10000).

3. Établir la logique d'empilement et de file d'attente

Gérer les environnements à volume de déclenchement élevé sans induire de remaniement de mise en page ni de surcharge cognitive :

• Limite maximale visible : Limiter la file d'attente active à un maximum de 3 toasts visibles empilés verticalement.
• Direction d'empilement :
  • Si placé en haut de l'écran, les nouveaux toasts glissent depuis le haut, poussant les toasts plus anciens vers le bas.
  • Si placé en bas de l'écran, les nouveaux toasts glissent depuis le bas, poussant les toasts plus anciens vers le haut.
• Tampon de file d'attente : Si un 4ème toast est déclenché alors que 3 sont actifs, mettre en mémoire tampon le nouveau toast. Le rendre immédiatement dès que le toast le plus ancien expire naturellement et disparaît.

4. Coder la chronologie d'expiration et de pause au survol

Les toasts doivent exister assez longtemps pour être lus mais se dissoudre rapidement pour libérer l'écran :

• Durée de vie dynamique (TTL) : Calculer l'expiration en fonction de la longueur du contenu :
  • Toasts passifs courts (< 40 caractères) : Se fermer après 5 secondes.
  • Toasts plus longs ou avec action : Se fermer après 7 à 10 secondes pour garantir que les lecteurs d'écran puissent les annoncer complètement et que les utilisateurs aient le temps de lire et d'agir.
  • Toasts d'erreur/échec : Ne pas se fermer automatiquement. Les garder visibles jusqu'à ce que l'utilisateur clique manuellement sur le bouton 'X', garantissant que les retours critiques ne soient pas perdus.
• L'interaction « Pause au survol » :
  • Si un utilisateur de souris survole une partie de la file d'attente de toasts, geler tous les décomptes TTL actifs. Réinitialiser et reprendre les minuteries uniquement après que la souris quitte les limites du toast.
  • Si un utilisateur de clavier se concentre sur un élément à l'intérieur d'un toast, geler la minuterie indéfiniment. Reprendre les décomptes uniquement lorsque le focus revient au document principal.

5. Définir les comportements de fermeture et de gestes

• Balayage tactile : Sur les appareils mobiles, permettre aux utilisateurs de fermer immédiatement les snackbars individuelles en les balayant horizontalement hors de l'écran (gauche ou droite). Maintenir le seuil de glissement à 30% de la largeur de la zone d'affichage.
• Animation : Utiliser des transitions fluides et accélérées par le matériel (par exemple, transform et opacity) avec une durée de 200ms à 300ms et cubic-bezier(0.16, 1, 0.3, 1) (ease-out-expo) pour l'entrée, et une simple disparition en opacity pour la sortie.

---

Règles de décision

Matrice d'alignement d'empilement

Zone d'affichage	Disposition de navigation principale	Placement de toast recommandé	Direction d'animation
Desktop	Barre latérale gauche / Tableau de bord	Bas-droit (maintient le travail principal dégagé)	Glissement depuis la gauche hors écran
Desktop	En-tête supérieur fixe	Bas-droit (empêche l'occlusion de la navigation)	Glissement vers la gauche ou vers le haut
Desktop	Minimaliste / Pied de page lourd	Haut-droit	Glissement vers la gauche ou vers le bas
Mobile	Quelconque	Centré en bas / Pleine largeur	Glissement vers le haut depuis le bord inférieur

Matrice de logique d'expiration

Gravité / Type de toast	Contient un bouton d'action ?	Expiration recommandée	Type de fermeture
Succès / Info	Non	5 secondes (Fixé)	Fermeture automatique + Fermeture manuelle
Succès / Info	Oui (« Annuler » / « Voir »)	8 - 10 secondes	Fermeture automatique + Fermeture manuelle
Avertissement	Non	7 secondes	Fermeture automatique + Fermeture manuelle
Erreur / Échec	Oui ou Non	Infini (Reste persistant)	Fermeture manuelle UNIQUEMENT

---

Contraintes

• Accessibilité (Conformité WCAG 2.2) :
  • Régions live ARIA : Mapper les toasts passifs à role="status" (qui par défaut est aria-live="polite" et aria-atomic="true"). Éviter d'utiliser role="alert" (assertif) sauf pour communiquer une défaillance système (par exemple, « Connexion Internet perdue »), car les alertes assertives interrompent immédiatement les lecteurs d'écran au milieu d'une phrase.
  • Navigation au clavier (WCAG 2.2 SC 2.1.1) : Lorsqu'un toast contient une action interactive (par exemple, « Annuler » ou « Voir »), il doit être accessible au clavier. Étant donné que les boucles de tabulation au clavier peuvent être lentes, fournir un raccourci de contournement global (par exemple, Escape ferme le toast actif, ou F6 déplace le focus directement vers le conteneur de la file d'attente des toasts) ou placer le conteneur de toast juste après le déclencheur actif dans l'ordre de tabulation du DOM.
  • Pas de pièges de focus : Ne jamais piéger le focus clavier dans une file d'attente de toasts. L'utilisateur doit pouvoir librement tabuler hors du toast pour revenir au contenu de la page.
• Contraste (WCAG 2.2 SC 1.4.3) :
  • Tout texte, icônes de statut et boutons doivent respecter les minimums de contraste par rapport à l'arrière-plan du toast :
    • Texte normal : Contraste minimum 4,5:1.
    • Icônes et bordures de contrôle actifs : Contraste minimum 3:1.
• Réactivité :
  • Sur les zones d'affichage < 600px, le conteneur de toast doit s'étendre sur toute la largeur (width: calc(100% - 32px)) avec un alignement horizontal centré pour éviter des colonnes de marge maladroites.

---

Schémas d'échec courants

• Le piège de « l'action occultée » : Placer la file d'attente de toasts desktop directement au-dessus d'éléments interactifs à haute fréquence, tels que le bouton d'en-tête du panier d'achat ou un menu déroulant de filtrage de tableau, incitant les utilisateurs à cliquer par erreur.
• Le flash « Maintenant tu le vois, maintenant tu ne le vois plus » : Fermer automatiquement une erreur ou un avertissement complexe et en plusieurs mots en 2 à 3 secondes. Cela viole les seuils de base de lecture d'accessibilité et panique les utilisateurs qui ont manqué le contexte.
• Silence du lecteur d'écran : Ajouter des toasts dynamiquement au DOM sans un wrapper de région live ARIA, les rendant complètement invisibles pour les utilisateurs malvoyants.
• Remaniement de mise en page saccadé : Animer la hauteur de la file d'attente de toasts brusquement à l'entrée, provoquant un déplacement du contenu principal de la page vers le haut et vers le bas.
• Ignorance de l'expiration au survol/focus : Laisser un toast se fermer automatiquement pendant qu'un utilisateur lit un message texte dense en survolant ou survole un CTA « Annuler », l'incitant à cliquer sur « un espace mort » et à déclencher des actions indésirables.

---

Critères de validation

• Les toasts sont stylisés avec des indicateurs sémantiques distincts à contraste élevé (couleur + icône unique).
• Sur desktop, les toasts ne chevauchent pas les éléments de navigation principaux ou les zones d'action globales.
• Sur mobile, les toasts se transforment en composants ancrés en bas et pleine largeur, facilement accessibles par le pouce.
• Les minuteries actives se mettent en pause instantanément lorsqu'elles sont survolées par une souris ou ciblées via le clavier.
• Les toasts avec action restent visibles pendant un minimum de 8 à 10 secondes ; les toasts d'erreur ne se ferment jamais automatiquement.
• Le balisage sémantique pour lecteur d'écran (role="status" ou role="alert") est correctement spécifié.
• Les utilisateurs de clavier peuvent naviguer vers les boutons d'action des toasts et les déclencher sans barrières de piège de focus.
• Tous les éléments interactifs (bouton de fermeture, CTA) respectent la cible tactile minimale WCAG 2.2 de 24x24px (44x44px de préférence).