Quel élément a perdu le focus après ce commit ? C’est la question qui, la plupart du temps, ne se pose jamais lors d’une revue de code classique, centrée sur la logique métier, les performances ou la couverture de tests. Une régression d’accessibilité ne casse presque jamais un test automatisé existant : elle passe silencieusement, invisible tant que personne ne navigue au clavier ou avec un lecteur d’écran sur la fonctionnalité modifiée.
Cette checklist a été construite après plusieurs régressions découvertes tardivement sur un projet WordPress à composants React côté éditeur : un focus perdu après suppression d’un bloc, un bouton devenu <div> lors d’un refactoring, un message d’erreur ajouté sans lien avec son champ de formulaire. Aucune de ces régressions n’avait fait échouer la suite de tests existante.
Les douze points de la checklist
- Tout élément interactif reste un élément interactif natif. Un
<button>transformé en<div onClick>lors d’un refactoring perd son rôle, son focus clavier natif et son activation au clavier par défaut. - Chaque image ajoutée porte un attribut alt, vide pour une image décorative, descriptif sinon. Une pull request qui ajoute une image sans discussion sur son texte alternatif doit être bloquée jusqu’à clarification.
- Le focus est explicitement géré après toute suppression ou fermeture d’élément. Un composant qui disparaît du DOM doit toujours prévoir où le focus se déplace ensuite.
- Aucun gestionnaire de clic seul sur un élément non interactif. Un
onClickposé sur un<span>ou un<div>sans rôle ni gestion du clavier associée est un signal d’alerte systématique. - Les nouveaux champs de formulaire ont un
<label>associé, via l’attributforou par imbrication, jamais par un simple placeholder tenant lieu d’étiquette. - Les messages d’erreur sont liés au champ concerné, via
aria-describedby, et pas seulement affichés visuellement à proximité. - La hiérarchie des titres reste cohérente. Un composant ajouté dans une page ne doit pas introduire un
<h2>si le contexte attend un<h3>, ni sauter de niveau sans raison. - Les couleurs ajoutées respectent un contraste suffisant, vérifié avec un outil de mesure avant la fusion, pas après un signalement en production.
- Aucun contenu n’est masqué uniquement par la couleur. Un statut « erreur » signalé seulement en rouge, sans texte ni icône, échoue à ce point.
- Les régions
aria-liveexistent déjà dans le DOM avant toute mise à jour dynamique, jamais créées et remplies dans la même opération. - Les tests incluent un passage clavier manuel sur toute nouvelle fonctionnalité interactive : ouverture, fermeture, activation, sans jamais toucher la souris.
- Le composant est vérifié avec au moins un lecteur d’écran avant la fusion d’une fonctionnalité interactive majeure, pas systématiquement pour chaque correction mineure de style.
Comment intégrer cette liste sans ralentir l’équipe
Appliquer les douze points à chaque pull request, y compris les plus triviales, décourage rapidement une équipe et transforme la checklist en formalité cochée sans attention réelle. La distinction retenue par l’équipe repose sur la nature du changement : une modification purement visuelle de couleur ou d’espacement déclenche les points 8 et 9 uniquement, une modification touchant l’interactivité déclenche l’ensemble de la liste.
## Modèle de commentaire de revue, copié dans le gabarit de pull request
- [ ] Focus vérifié après fermeture/suppression (point 3)
- [ ] Labels et erreurs de formulaire liés correctement (points 5 et 6)
- [ ] Navigation clavier testée manuellement (point 11)
- [ ] Contraste vérifié si couleur modifiée (point 8)
Ce gabarit, inséré directement dans le modèle de description de pull request du dépôt, rend la checklist visible sans imposer un document externe que personne ne consulte réellement. Cocher une case demande un effort minime ; l’oublier devient visible pour le relecteur suivant.
Ce que cette checklist ne remplace pas
Un audit RGAA complet, mené par un professionnel formé, reste nécessaire à intervalles réguliers : la checklist de revue de code attrape les régressions du quotidien, pas les manquements structurels déjà présents avant sa mise en place. Les deux démarches se complètent, elles ne se substituent jamais l’une à l’autre.
Un repère de discipline d’équipe qui a fait ses preuves : traiter une régression d’accessibilité détectée en revue exactement comme une régression de test unitaire échouée, jamais comme une remarque optionnelle à traiter « plus tard ». Le « plus tard » d’une régression d’accessibilité se transforme presque toujours en un ticket jamais priorisé.
En résumé
Attraper une régression d’accessibilité en revue de code coûte quelques minutes d’attention supplémentaire. La corriger une fois signalée en production par un usager coûte, en moyenne sur ce projet, bien davantage : un ticket de support, une investigation, un correctif urgent, et parfois une perte de confiance de l’utilisateur concerné. Douze points, appliqués avec discernement selon la nature du changement, suffisent à réduire fortement ce risque sans alourdir excessivement le rythme de l’équipe.
