# eslint-plugin-jsx-a11y contre une revue manuelle pour un bloc Gutenberg

> Attraper une erreur d'accessibilité avant même le commit change la donne pour une équipe qui développe des blocs personnalisés. Comparatif entre lint automatisé et revue de code manuelle.

- Auteur : WordPress Développement
- Publié le : 2026-07-20
- Mis à jour le : 2026-07-20
- Catégorie : Accessibilité
- URL : https://www.wpmoderne.fr/accessibilite/eslint-plugin-jsx-a11y-revue-manuelle-bloc-gutenberg/

## L’essentiel

- Le lint automatisé détecte des motifs syntaxiques en quelques secondes, avant tout commit
- La revue manuelle capte des problèmes de sens que le lint ne peut pas évaluer
- Les deux approches se complètent plutôt qu'elles ne se substituent l'une à l'autre

Deux minutes contre deux jours : c'est l'écart de délai entre la détection d'une image sans texte alternatif par un lint automatisé au moment du commit, et sa détection par une revue de code manuelle qui n'intervient qu'après l'ouverture de la pull request, parfois plusieurs jours plus tard selon la disponibilité des relecteurs. Pour une équipe qui développe des blocs Gutenberg personnalisés à un rythme soutenu, cet écart de délai a un impact direct sur le coût de correction : plus une erreur est détectée tôt, moins son contexte a été oublié par le développeur qui l'a introduite.

`eslint-plugin-jsx-a11y` est un plugin ESLint qui analyse le JSX utilisé dans le développement de blocs pour l'éditeur, et signale un ensemble de motifs syntaxiques connus pour poser des problèmes d'accessibilité : attribut `alt` manquant, gestionnaire `onClick` posé sur un élément non interactif sans rôle ni gestion clavier associée, libellé de formulaire absent. Sa configuration recommandée active 27 règles par défaut, exécutables en quelques secondes sur l'ensemble d'un projet.

## Ce que le lint automatisé détecte bien

Le lint excelle sur les motifs syntaxiques stricts, indépendants du sens réel du contenu : un `<img>` sans attribut `alt`, un `<div onClick={...}>` sans `role` ni gestionnaire clavier, un champ de formulaire sans `htmlFor` associé à un `<label>`. Ces règles s'appliquent de façon identique quel que soit le contexte métier du bloc développé, et ne nécessitent aucune connaissance du contenu réel qui sera affiché une fois le bloc publié.

L'exécution s'intègre naturellement dans un hook de pré-commit via `husky` et `lint-staged`, ce qui bloque littéralement la création du commit tant que la violation n'est pas corrigée — un niveau de rigueur qu'aucune revue manuelle, dépendante de la disponibilité humaine, ne peut égaler en termes de délai.

## Ce que la revue manuelle capte que le lint ignore

Le lint ne peut évaluer aucune question de pertinence sémantique. Un attribut `alt="image"` passe la totalité des règles automatisées sans déclencher la moindre alerte, alors qu'il constitue une description parfaitement inutile pour un utilisateur de lecteur d'écran. De même, un ordre de tabulation illogique entre plusieurs champs positionnés côte à côte par CSS Grid échappe totalement à l'analyse statique du JSX, puisque l'ordre visuel et l'ordre du DOM peuvent diverger sans qu'aucune règle syntaxique ne soit techniquement violée.

> L'essentiel à retenir : Le lint automatisé détecte des motifs syntaxiques en quelques secondes, avant tout commit ; La revue manuelle capte des problèmes de sens que le lint ne peut pas évaluer ; Les deux approches se complètent plutôt qu'elles ne se substituent l'une à l'autre

## Comparatif synthétique

| Aspect | eslint-plugin-jsx-a11y | Revue manuelle |
| --- | --- | --- |
| Délai de détection | Avant le commit | Après ouverture de la pull request |
| Pertinence sémantique du contenu | Non évaluée | Évaluée par le relecteur |
| Ordre de tabulation logique | Non détecté | Détectable à l'usage |
| Coût humain récurrent | Négligeable | Temps de relecteur à chaque PR |
| Reproductibilité | Totale | Dépend du relecteur assigné |

### Un exemple qui illustre la complémentarité

Sur un projet de bloc de témoignages clients pour une plateforme de formation en ligne, le lint automatisé a bloqué à lui seul quarante-trois commits en six mois pour des attributs `alt` manquants sur les photos de profil — un travail répétitif que personne ne souhaitait continuer à faire manuellement. La revue humaine, elle, a identifié un problème que le lint ne pouvait pas voir : l'ordre de lecture au clavier des étoiles de notation ne correspondait pas à l'ordre visuel affiché, un défaut invisible dans le code JSX pris isolément mais flagrant lors d'un test clavier réel.

## Configurer le plugin sans excès

L'écueil à éviter consiste à activer d'emblée l'intégralité des règles disponibles sans phase d'adaptation, au risque de bloquer des commits sur des règles trop strictes pour le contexte réel du projet. Une progression raisonnable consiste à démarrer avec la configuration recommandée du plugin, puis à ajuster au cas par cas les règles qui génèrent des faux positifs répétés, en documentant chaque exception dans le fichier de configuration plutôt que dans des commentaires disséminés dans le code.

- Démarrer avec la configuration recommandée officielle du plugin.
- Intégrer le lint dans un hook de pré-commit, pas seulement dans la CI, pour un retour immédiat au développeur.
- Conserver une étape de revue humaine ciblée sur les questions de sens et d'usage réel au clavier.

## Notre verdict

Opposer les deux approches n'a pas de sens : le lint automatisé élimine la charge répétitive des erreurs syntaxiques évidentes, libérant le temps de relecture humaine pour les questions de pertinence et d'usage réel que ni ESLint ni aucun outil statique ne pourra jamais évaluer à la place d'une personne.