implementation
Construis Case à cocher sans casser son comportement
# Implémenter Case à cocher dans ton agent ## Objectif Implémente Case à cocher pour ce comportement vérifié : Un choix binaire indépendant qui peut être coché, décoché ou parfois indéterminé. ## 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 Case à cocher répond au besoin avant de coder. ## Comportement requis - L’activation change l’état binaire ; le moment où cette valeur est enregistrée relève d’une décision produit distincte. - Un choix parent peut exposer un état indéterminé lorsque seuls certains éléments enfants sont sélectionnés. ## États à couvrir - Case décochée - Case cochée ## Accessibilité - Rôle ARIA : input[type=checkbox] - Le contrôle principal ou la région nommée pour Case à cocher 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. - Chaque case native possède un focus visible et son libellé agrandit la cible au pointeur. - Sans objet : la case persiste jusqu’à ce que l’utilisateur la bascule ou réinitialise le formulaire. - Le nom accessible, l’état coché ou mixte, l’état obligatoire et l’erreur sont exposés. - Tab focalise chaque case - Espace bascule la case focalisée ## Quand ne pas utiliser - Une seule option doit être sélectionnée - La valeur s’exprime mieux comme un réglage marche ou arrêt ## Critères d’acceptation - Chaque case possède un libellé visible associé - Les options indépendantes se basculent séparément - L’état mixte est programmatique et visuel - Espace et pointeur produisent le même état ## 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 Case à cocher sur un parcours réel
# Vérifier Case à cocher après l’implémentation ## Objectif Audite l’implémentation de Case à cocher 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:b16cd2afc76aa8ee626a9eeed9bf6160cb5c39885ef86b5d51eb246ca93b9633