implementation
Construis Bouton sans casser son comportement
# Implémenter Bouton dans ton agent ## Objectif Implémente Bouton pour ce comportement vérifié : Un contrôle nommé qui exécute une action dans l’interface actuelle lorsqu’il est activé. ## 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 que Bouton répond au besoin avant de coder. ## Comportement requis - L’activation au pointeur, avec Entrée ou Espace, exécute une action nommée une seule fois. - La région de contenu expose son état occupé tandis que l’indicateur visuel reste redondant. ## États à couvrir - Enregistrement au repos - Enregistrement en cours - Erreur d’enregistrement - Enregistrement réussi ## Accessibilité - Rôle ARIA : button - Le contrôle principal ou la région nommée pour Bouton 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. - Un indicateur de focus contrasté reste visible dans chaque variante active et pendant l’attente. - Sans objet : un bouton d’action n’ouvre pas de surface sauf si cette relation distincte est définie. - Le nom accessible, l’état désactivé ou pressé si pertinent et le résultat en attente sont exposés sans ambiguïté de libellé. - Tab focalise le bouton - Entrée et Espace l’activent - L’envoi suit son type explicite ## Quand ne pas utiliser - L’activation navigue surtout vers une autre URL - Le contrôle n’a pas de nom d’action clair ## Critères d’acceptation - Le bouton exécute une action et non une navigation - Son libellé visible nomme l’action - Entrée, Espace, focus, désactivation et attente fonctionnent - Contraste et taille de cible respectent la barre qualité ## 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 Bouton sur un parcours réel
# Vérifier Bouton après l’implémentation ## Objectif Audite l’implémentation de Bouton 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:f0d08c31e6bb33a8a4704af3e1b3adbbc95eb58beeec3963db19cc4808bf8980