implementation
Construis Alerte dans le contexte sans casser son comportement
# Implémenter Alerte dans le contexte dans ton agent ## Objectif Implémente Alerte dans le contexte pour ce comportement vérifié : Un message persistant placé près du contenu ou de la tâche qu’il explique, avec une urgence adaptée à la mise à jour réelle. ## Prérequis - Inspecte d’abord le dépôt, le design system et les tests existants. - Préserve les changements sans rapport et borne les fichiers modifiés. - Confirme qu’Alerte dans le contexte répond au besoin avant de coder. ## Comportement requis - Le message reste dans son contexte jusqu’à ce que la situation change ou que l’utilisateur le ferme volontairement. - Une région live annonce un nouvel état seulement si la mise à jour est importante et n’a pas déjà le focus. ## États à couvrir - Envoi prêt - Erreur de taille d’envoi ## Accessibilité - Rôle ARIA : status | alert | none - Le contrôle principal ou la région nommée pour Alerte dans le contexte possède un nom accessible stable issu d’un texte visible ou d’un libellé programmatique explicite ; le placeholder et l’infobulle ne servent pas de nom. - Le message ne vole pas le focus pour les mises à jour courantes ; un échec d’envoi peut focaliser volontairement un résumé ou le premier contrôle invalide. - Il reste jusqu’à résolution ; un contrôle fermer existe seulement si masquer le message ne cache pas un risque non résolu. - Les nouvelles erreurs urgentes utilisent alert, les états courants un status poli, et le texte explicatif statique aucun rôle live. - Tab atteint les actions de correction dans l’ordre du document - Entrée active l’action de correction nommée ## Quand ne pas utiliser - Une courte confirmation sans risque n’a pas besoin de persister - La condition s’applique à toute la page ou au site ## Critères d’acceptation - Le message se trouve près de la tâche affectée - Le texte expose le problème et sa correction - L’urgence détermine le rôle live - Le message persiste tant que la condition existe ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
- Web platform
- Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
- Le besoin est relié au comportement canonique avant toute décision technique.
- Les états, l’accessibilité et les non-objectifs empêchent une implémentation seulement visuelle.
- Les critères d’acceptation et le format de sortie rendent la vérification observable.
À essayer ensuite
Vérifie Alerte dans le contexte sur un parcours réel
# Vérifier Alerte dans le contexte après l’implémentation ## Objectif Audite l’implémentation d’Alerte dans le contexte au regard de son comportement, de ses états et de ses exigences d’accessibilité sans la modifier automatiquement. ## Contrôles - Rejoue le plus petit parcours représentatif. - Contrôle le clavier, le focus, le nom accessible et les annonces. - Relie chaque écart à un critère d’acceptation précis. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
sha256:70d94cda38fd2fe3fce289937cd71f434ac21b983640f329a9c40fddabde6ada