Comment vérifier les landmarks ARIA et les régions principales d’une page ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre landmarks ARIA

Les landmarks découpent une page en grandes régions comme l’en-tête, la navigation, le contenu principal ou le pied de page. Ils peuvent accélérer la navigation assistée lorsque la structure est cohérente, mais une multiplication de régions mal nommées peut produire l’effet inverse.

Inspecter le comportement réellement servi

Examinez les éléments sémantiques HTML et les rôles ARIA exposés dans l’arbre d’accessibilité. Vérifiez la présence d’un contenu principal identifiable, les navigations distinctes et les régions répétées. Comptez aussi les rôles ajoutés à des éléments qui possèdent déjà une sémantique native équivalente.

Distinguer les notions qui se ressemblent

Un landmark n’est pas un titre de section et ne remplace pas la hiérarchie H1-H6. Les titres organisent le contenu ; les régions offrent des points de navigation structurels. Les deux mécanismes peuvent se compléter sans être rendus identiques.

Identifier les causes les plus probables

Les problèmes apparaissent avec des div dotées de rôles ajoutés systématiquement, plusieurs navigation sans nom distinct, plusieurs main, ou des composants réutilisés qui créent des régions imbriquées sans logique. Certains frameworks rendent aussi des landmarks dupliqués dans des états responsive.

Décider ce qui mérite d’être corrigé en premier

Commencez par la structure globale : un main correspondant au contenu principal, des navigations compréhensibles et des régions complémentaires réellement utiles. N’ajoutez pas un rôle uniquement pour augmenter le nombre de landmarks. Chaque région doit répondre à un besoin de navigation identifiable.

Corriger à la bonne couche

Préférez header, nav, main, aside et footer lorsqu’ils correspondent à la fonction réelle. Ajoutez un nom aux régions similaires quand il faut les distinguer. Retirez les rôles redondants ou incorrects plutôt que de superposer ARIA à une structure HTML déjà claire.

Traiter les cas limites sans automatisme

Un site peut légitimement comporter plusieurs nav ou complementary. Le problème n’est donc pas le nombre brut mais la capacité à les distinguer. Les composants embarqués et widgets peuvent aussi introduire leurs propres régions ; inspectez le rendu final, pas seulement le template.

Valider la correction sur des cas réels

Parcourez la liste des landmarks avec un outil d’accessibilité et vérifiez que leur ordre suit la page. Les noms doivent rester compréhensibles hors contexte. Contrôlez différents gabarits pour éviter une structure correcte sur la home mais incohérente sur les pages internes.

Prévenir la régression dans le temps

Documentez les régions autorisées dans le layout principal et les composants qui peuvent en créer. Une revue de design system doit éviter les rôles ARIA ajoutés par habitude et préserver une structure simple à mesure que le site grandit.

Clôturer le contrôle sur landmarks ARIA

Pour clôturer le contrôle « Comment vérifier les landmarks ARIA et les régions principales d’une page ? », conservez une preuve avant/après : URL ou composant testé, constat initial, origine technique, correction appliquée et résultat de la vérification. Contrôlez aussi les pages liées /site/accessibilite, /site/ordre-titres-accessibilite, /site/verifier-navigation-clavier afin de vérifier que la correction reste cohérente avec le reste du corpus. Le périmètre documentaire reste volontairement borné : Présenter les landmarks comme des régions de navigation structurantes. Favoriser les éléments HTML sémantiques quand ils portent déjà la bonne sémantique et éviter les rôles ARIA redondants. Si le comportement dépend d’un gabarit, d’un CDN, d’un navigateur ou d’un outil tiers, testez au moins un second cas représentatif. Une anomalie ambiguë doit rester en revue plutôt que d’être fermée sur une hypothèse. Attribuez enfin la règle à une source précise — composant, template, serveur, CMS ou configuration — pour pouvoir la retester après une refonte.

Conserver une preuve exploitable dans l’audit

Un contrôle sur landmarks ARIA est utile seulement si une autre personne peut reproduire le constat. Enregistrez la réponse ou l’état observé, l’outil utilisé, le contexte de test et l’élément exact qui justifie la conclusion. Évitez les captures isolées sans URL, statut ou propriété mesurée. Pour les anomalies répétées, comptez les occurrences par gabarit avant et après correction. Cette trace permet de distinguer une résolution globale d’un exemple corrigé manuellement et évite de rouvrir le même diagnostic sans information nouvelle. Lorsque la documentation officielle est la borne du contrôle, notez également la source utilisée afin de pouvoir réévaluer la règle si elle évolue.

Tester un scénario représentatif

Sur une page éditoriale, dressez la carte des régions dans l’ordre où elles sont exposées : bannière, navigation principale, recherche éventuelle, main, complementary puis contentinfo. Si deux nav existent, par exemple menu principal et fil d’Ariane, vérifiez qu’elles peuvent être distinguées sans regarder l’écran. Comparez ensuite avec une page de tableau de bord qui contient un menu latéral et plusieurs widgets. Une série de div role=region non nommées peut rendre la liste plus longue sans aider la navigation. Inspectez aussi les éléments HTML sémantiques auxquels un rôle ARIA identique a été ajouté inutilement. Le test doit montrer quelles régions sont structurelles, lesquelles sont de simples sections de contenu et comment le nom accessible d’une région répétée est obtenu. Conservez cette cartographie comme référence du layout principal. Consignez les éléments header, nav, main, aside, footer, search et region, leur rôle calculé et leur nom accessible. Pour deux navigations, indiquez par exemple « Navigation principale » et « Fil d’Ariane » plutôt que deux entrées identiques. Vérifiez aussi les iframes et widgets embarqués qui peuvent ajouter leurs propres régions. Une carte des landmarks par gabarit permet de repérer les doublons apparus lors d’un changement de layout responsive. Sur un résultat de recherche, distinguez la région de recherche elle-même, la navigation de pagination et le contenu principal. Si un aside publicitaire ou une table des matières crée aussi complementary, son nom doit permettre de comprendre sa fonction au milieu de la liste des régions. Relevez banner, navigation, main, complementary, contentinfo, form, search et region tels qu’ils apparaissent réellement dans l’accessibility tree. Un header placé dans un article n’a pas forcément le même rôle qu’un header global. Cette nuance permet d’éviter des hypothèses fondées uniquement sur le nom de la balise HTML sans regarder son contexte structurel.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• w3c landmarks