implementation
Construis Volet latéral sans casser son comportement
# Implémenter Volet latéral dans ton agent ## Objectif Implémente Volet latéral pour ce comportement vérifié : Un panneau temporaire qui glisse depuis un bord de la fenêtre, recouvre la page et se ferme lorsque sa tâche ciblée est terminée. ## 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 Volet latéral répond au besoin avant de coder. ## Comportement requis - Le panneau temporaire recouvre la page et arrive depuis un bord défini de la fenêtre. - Tant que la surface est modale, le focus clavier y reste jusqu’à sa fermeture. - Échap ferme la surface temporaire et renvoie le focus vers un contrôle pertinent. ## États à couvrir - Volet fermé - Volet ouvert ## Accessibilité - Rôle ARIA : dialog[aria-modal=true] - Le contrôle principal ou la région nommée pour Volet latéral 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. - L’ouverture place le focus sur le titre ou le premier champ utile, le contient, puis le rend au déclencheur. - Le contrôle fermer nommé et Échap fonctionnent toujours ; la fermeture par le voile est désactivée si elle peut perdre des changements. - Le titre accessible et la description facultative identifient la tâche du volet à l’entrée du focus. - Tab reste dans le volet pendant l’ouverture - Échap ferme sans appliquer de changement involontaire - Entrée active uniquement le contrôle focalisé ## Quand ne pas utiliser - La navigation doit rester visible entre les pages - La tâche nécessite toute la fenêtre ou plusieurs étapes ## Critères d’acceptation - Le panneau est temporaire et recouvre la page - Son bord et son comportement modal sont explicites - Le focus est contenu puis restauré - Dans la mise en page étroite, toutes les actions restent accessibles ## 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.
- @radix-ui/react-dialog
- 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 Volet latéral sur un parcours réel
# Vérifier Volet latéral après l’implémentation ## Objectif Audite l’implémentation de Volet latéral 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:1cc006148cb934e9e8765c01e455d573f3892bfb968603f53d50281b31992e77