implementation
Construis Barre latérale sans casser son comportement
# Implémenter Barre latérale dans ton agent ## Objectif Implémente Barre latérale pour ce comportement vérifié : Une région persistante à côté du contenu principal, intégrée à la mise en page et généralement dédiée à la navigation ou à des outils complémentaires. ## 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 Barre latérale répond au besoin avant de coder. ## Comportement requis - La région occupe une place dans la mise en page au lieu de recouvrir temporairement le contenu principal. - Si le produit remplace la région persistante quand l’espace manque, ce remplacement est un contrôle de navigation temporaire nommé séparément. ## États à couvrir - Barre latérale développée - Barre latérale compacte ## Accessibilité - Rôle ARIA : aside > nav[aria-label] - Le contrôle principal ou la région nommée pour Barre latérale 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 focus circule normalement entre la barre et le contenu principal ; le repli conserve un contrôle logique focalisé. - Une barre persistante se replie, elle ne se ferme pas ; son équivalent mobile temporaire suit son propre contrat Drawer. - La région de navigation possède un nom unique et la destination actuelle utilise aria-current lorsque pertinent. - Tab suit l’ordre normal du document - Entrée active liens et contrôle de repli - Aucun piège de focus n’est créé ## Quand ne pas utiliser - La surface n’est utile que brièvement - Le contenu restant devient trop étroit ou défile horizontalement ## Critères d’acceptation - La barre occupe de l’espace au lieu de recouvrir le contenu - Sa région de navigation possède un nom unique - La position actuelle et l’état replié sont exposés - Le remplacement sur petit écran est un pattern distinct explicite ## 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 Barre latérale sur un parcours réel
# Vérifier Barre latérale après l’implémentation ## Objectif Audite l’implémentation de Barre latérale 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:cdd9e3dd8f49c09ccd42808561f4e7927f1dcca3300ac446119675fb3397b138