fixing-accessibility

Corriger les problèmes d'accessibilité.

Triggers

• accessibility
• a11y
• aria
• screen reader
• keyboard navigation
• focus
• contrast
• alt text
• semantic html
• tab order
• fix accessibility
• accessible

how to use

• /fixing-accessibility Appliquer ces contraintes à tout travail UI dans cette conversation.

• /fixing-accessibility <file> Examiner le fichier par rapport à toutes les règles ci-dessous et rapporter :

  • violations (citer la ligne ou l'extrait exact)
  • pourquoi c'est important (une courte phrase)
  • un correctif concret (suggestion au niveau du code)

Ne pas réécrire de grandes parties de l'UI. Préférer des correctifs minimes et ciblés.

when to apply

Référencer ces directives quand :

• ajouter ou modifier des boutons, liens, inputs, menus, dialogs, tabs, dropdowns
• construire des formulaires, validations, états d'erreur, textes d'aide
• implémenter des raccourcis clavier ou des interactions personnalisées
• travailler sur des états de focus, focus trapping, ou le comportement des modales
• rendre des contrôles sans icône
• ajouter des interactions au survol uniquement ou du contenu caché

rule categories by priority

quick reference

1. accessible names (critical)

• chaque contrôle interactif doit avoir un nom accessible
• les boutons sans icône doivent avoir aria-label ou aria-labelledby
• chaque input, select et textarea doivent être étiquetés
• les liens doivent avoir du texte significatif (pas de "click here")
• les icônes décoratives doivent être aria-hidden

2. keyboard access (critical)

• ne pas utiliser div ou span comme boutons sans support clavier complet
• tous les éléments interactifs doivent être accessibles par Tab
• le focus doit être visible pour les utilisateurs clavier
• ne pas utiliser tabindex supérieur à 0
• Escape doit fermer les dialogs ou overlays le cas échéant

3. focus and dialogs (critical)

• les modales doivent piéger le focus quand elles sont ouvertes
• restaurer le focus au déclencheur à la fermeture
• définir le focus initial à l'intérieur des dialogs
• l'ouverture d'une dialog ne doit pas faire défiler la page de manière inattendue

4. semantics (high)

• préférer les éléments natifs (button, a, input) aux hacks basés sur role
• si un role est utilisé, les attributs aria requis doivent être présents
• les listes doivent utiliser ul ou ol avec li
• ne pas sauter les niveaux de titre
• les tableaux doivent utiliser th pour les en-têtes le cas échéant

5. forms and errors (high)

• les erreurs doivent être liées aux champs avec aria-describedby
• les champs requis doivent être annoncés
• les champs invalides doivent définir aria-invalid
• le texte d'aide doit être associé aux inputs
• les actions de soumission désactivées doivent expliquer pourquoi

6. announcements (medium-high)

• les erreurs de formulaire critiques doivent utiliser aria-live
• les états de chargement doivent utiliser aria-busy ou un texte de statut
• les toasts ne doivent pas être le seul moyen de communiquer une information critique
• les contrôles extensibles doivent utiliser aria-expanded et aria-controls

7. contrast and states (medium)

• assurer un contraste suffisant pour le texte et les icônes
• les interactions au survol uniquement doivent avoir des équivalents clavier
• les états désactivés ne doivent pas dépendre uniquement de la couleur
• ne pas supprimer les focus outlines sans une alternative visible

8. media and motion (low-medium)

• les images doivent avoir un alt text correct (significatif ou vide)
• les vidéos avec de la parole doivent fournir des sous-titres le cas échéant
• respecter prefers-reduced-motion pour les mouvements non essentiels
• éviter les médias en lecture automatique avec son

9. tool boundaries (critical)

• préférer les changements minimes, ne pas refactoriser du code non lié
• ne pas ajouter aria quand la sémantique native résout déjà le problème
• ne pas migrer les libraries UI sauf si demandé

review guidance

• corriger en priorité les problèmes critiques (names, keyboard, focus, tool boundaries)
• préférer le HTML natif avant d'ajouter aria
• citer l'extrait exact, énoncer l'échec, proposer un petit correctif
• pour les widgets complexes (menu, dialog, combobox), préférer les primitives accessibles établies aux comportements personnalisés

Verify

• Un scanner d'accessibilité automatisé (axe, Lighthouse, pa11y, ou équivalent) a été réellement exécuté ; le rapport est attaché ou résumé avec des IDs de règle
• Chaque violation signalée porte une référence de critère de succès WCAG (par ex. 1.4.3, 2.4.7), pas un vague 'a11y issue'
• Un parcours complet au clavier uniquement du flux affecté a été effectué de bout en bout ; l'ordre de tabulation est documenté
• La sortie du lecteur d'écran (VoiceOver, NVDA, TalkBack) a été échantillonnée sur au moins un contrôle critique et le texte annoncé est enregistré
• Les ratios de contraste de couleur pour le nouveau texte/les nouvelles icônes sont rapportés sous forme de nombres (par ex. 4,7:1) par rapport au seuil WCAG AA
• Les correctifs ont été re-scannés après application ; le rapport de deuxième passage affiche zéro régressions sur les vérifications précédemment réussies