« Région principale, région principale. » NVDA répète deux fois la même annonce en arrivant sur la page d’archive d’un site vitrine construit avec un thème enfant classique et une extension de blocs personnalisés. Un seul élément de contenu principal devrait exister par page ; ici, l’inspecteur d’accessibilité de Firefox en révèle deux, avec des rôles role="main" concurrents.
Ce genre de doublon passe totalement inaperçu à l’œil : visuellement, la page est parfaitement normale. Il ne se révèle qu’au clavier, via un lecteur d’écran, ou à l’audit avec un outil comme axe DevTools. Voici comment il s’est introduit sur ce projet, et comment le repérer avant qu’il ne devienne une anomalie RGAA remontée en production.
Symptôme observé
Sur la page archive.php personnalisée d’un CPT « Formations », la navigation par landmarks de NVDA (touche D) affiche deux entrées « région principale » identiques. Un utilisateur de lecteur d’écran qui tente de sauter directement au contenu principal se retrouve à choisir entre deux options sans distinction, ce qui casse l’intérêt même du raccourci.
Diagnostic : où se cache le doublon
Le thème parent définit sa structure de page dans archive.php avec un élément <main id="main" role="main"> classique, hérité du thème sous-jacent. Mais le bloc personnalisé inséré dans le contenu de l’archive, développé pour afficher une grille de fiches formation, encapsule lui-même son rendu dans un <div role="main">, ajouté par un développeur qui pensait, à tort, que ce rôle renforçait la sémantique de son composant.
// Extrait du render.php du bloc fautif
echo '<div role="main" class="grille-formations">';
foreach ( $formations as $formation ) {
// ...
}
echo '</div>';
Pourquoi deux balises main posent problème
La spécification MDN sur le rôle main est explicite : une page ne doit contenir qu’un seul landmark principal. Au-delà du rôle explicite, l’élément HTML natif <main> porte lui-même un rôle implicite équivalent ; en ajouter un second, qu’il soit natif ou via l’attribut ARIA, crée une ambiguïté que les technologies d’assistance ne savent pas résoudre proprement.
- Vérifiez systématiquement les blocs personnalisés qui manipulent des rôles ARIA « pour faire propre ».
- Un rôle ARIA redondant avec la sémantique HTML native n’apporte rien et peut nuire.
- L’inspecteur d’accessibilité des DevTools Firefox affiche l’arbre des landmarks en un clic.
Le correctif appliqué
La correction consiste simplement à retirer l’attribut role="main" du bloc, en remplaçant le conteneur <div> par une balise neutre sans rôle explicite : <div class="grille-formations"> suffit, la sémantique de page principale restant portée par le <main> du thème. Le composant a été retesté sur trois gabarits différents avant mise en production.
Prévenir la récidive
Le vrai enseignement de ce cas tient dans la méthode de prévention plus que dans le correctif lui-même. Une checklist de revue de code pour les blocs personnalisés a été ajoutée au dépôt du thème, avec un test automatisé simple : compter les occurrences de role="main" et de balises <main> sur chaque gabarit rendu, et faire échouer la build si le total dépasse un.
Ce qu’il faut retenir
Un doublon de landmark ne casse jamais l’apparence visuelle d’une page : c’est précisément ce qui le rend dangereux, car il ne sera jamais signalé par la recette visuelle classique. Seul un test au clavier et au lecteur d’écran, ou un outil d’audit automatisé correctement configuré, le révèle. Sur un thème avec des blocs personnalisés multiples, une vérification systématique de l’unicité des landmarks principaux mérite sa place dans la routine de recette avant chaque mise en production.
