Conformité de la navigation avec le RGAA
Accessibilité des menus, plans du site, moteurs de recherche internes et liens d'évitement
Thématique 12 du RGAA 4.1.2, la navigation est un élément central de l’accessibilité, fait l’objet de 11 critères dédiés. Mais les exigences des auditeurs en accessibilité web sont différentes des optimisations attendues pour maximiser votre visibilité sur les moteurs de recherche conventionnels (Google, Bing, etc.) ou les ou génératifs (ChatGPT, Gemini, Claude, etc.).
Je vous propose de faire le point sur les trois systèmes de navigation conformes, et je vous partage ma double expertise SEO et accessibilité web pour offrir une expérience de navigation accessible et optimisée pour votre référencement naturel. J’aborde également les enjeux autour des liens d’évitement, des composants d’interface, de l’ordre de tabulation et des pièges au clavier.
Introduction : les 3 systèmes de navigation conformes RGAA
Le Référentiel général de l’accessibilité d’amélioration de l’accessibilité distingue trois solutions pour naviguer au sein d’un site web.
Le menu de navigation
Le menu de navigation est la solution la plus répandue. C’est également la meilleure solution – et de loin – si vous désirez positionner votre site web sur des requêtes concurrentielles, car les moteurs de recherche s’appuient sur les liens entre vos pages web pour comprendre l’arborescence de votre site web, le rôle sémantique et l’importance relative de chaque URL.
Différents types de menus de navigation peuvent coexister au sein d’une même page web :
- Menu de navigation principal ;
- Menu de sous-rubrique ;
- Menu contextuel ;
- Table des matières.
Le plan du site
Le plan du site est une page dédiée à l’arborescence de votre site, qui se présente sous la forme de listes de liens organisés en rubriques et sous-rubriques.
Cette page web n’a pas vocation à être exhaustive, à condition que les liens listés donnent accès à toutes les pages du site de manière directe ou indirecte. Si mon plan du site contient par exemple un lien vers ma page Accessibilité, je n’ai pas besoin de liste toutes les URL associées à cette rubrique car elles sont maillées depuis cette page.
Vous ne devez pas confondre le plan du site avec le fichier Sitemap. Ce dernier, généré au format XML, propose une liste des URL indexables pour faciliter l’exploration et l’indexation de votre site web par les moteurs de recherche.
Le moteur de recherche
La navigation au sein d’un site peut également s’effectuer par l’intermédiaire d’un moteur de recherche interne. Ce dernier doit donner accès à l’ensemble des pages du site, y compris et entre autres exemples les mentions légales, la déclaration d’accessibilité, le plan du site, et pas uniquement à certains types de contenus spécifiques. Il peut se présenter sous la forme d’un moteur de recherche libre ou d’un formulaire.
Si vous proposez un moteur de recherche limité à certains types de pages, vous devez le préciser par un intitulé explicite :
- Recherche d’un produit sur un site e-commerce : “Rechercher un produit par référence ou par nom” ;
- Recherche d’une actualité sur un blog : “Rechercher une actualité” ;
- Etc.
Vous devrez alors proposer les deux autres systèmes de navigation, à savoir un menu et un plan du site, pour répondre aux exigences de conformité du RGAA.
Chaque ensemble de pages dispose de deux systèmes de navigation différents
Des pages web partageant une cohérence sémantique, thématique ou fonctionnelle forment ce que le RGAA définit comme un ensemble de pages. C’est le cas, par exemple, des articles d’un blog, d’une catégorie e-commerce ou d’un guide thématique. Ainsi, l’ensemble des contenus de ma rubrique consacrée à l’accessibilité constitue un ensemble de pages à part entière.
Pour que votre site puisse être conforme au RGGA, chaque ensemble de pages doit offrir au moins 2 des 3 solutions de navigation suivantes :
- Un menu de navigation et un plan du site ;
- Un menu de navigation et un moteur de recherche ;
- Un moteur de recherche et un plan du site.
Critères RGAA : 12.1
Existe-t-il des cas particuliers où il n'est pas nécessaire d'avoir deux systèmes de navigation ?
Le RGAA prévoit des cas particuliers où il est inutile de proposer deux systèmes de navigation :
- Le site se compose d’une seule page ;
- Le site compte un nombre très limité de pages, toutes atteignables depuis la page d’accueil ;
- La page concernée fait partie d’un ensemble de pages permettant la réalisation d’une action (finaliser une commande, compléter un formulaire en plusieurs parties, etc.).
Quel est le meilleur système de navigation pour le SEO ?
Le menu de navigation est de loin la meilleure solution pour votre référencement naturel. Il facilite l’exploration, l’indexation et le positionnement de votre site web sur les moteurs de recherche, permettant d’accorder à chaque URL la popularité qu’elle mérite tout en renforçant sa légitimité grâce aux liens provenant de contenus à la sémantique affinitaire. En tant que professionnel du SEO, je ne peux que vous recommander d’implémenter un menu de navigation.
Le plan du site peut faciliter l’exploration de votre site web, en aidant Google ou n’importe quel autre moteur de recherche à mieux comprendre l’arborescence de votre site. Il peut également lisser un peu le niveau de profondeur de certaines pages. Mais il ne remplacera jamais pour votre SEO un menu en bonne et due forme.
Le moteur de recherche présente surtout des bénéfices pour l’utilisateur. Il est intéressant d’en ajouter un à votre site web, à condition que ce dernier possède un vrai menu.
Peut-on implémenter un menu, un plan du site et un moteur de recherche ?
Oui, les trois systèmes se complètent parfaitement :
- Le menu pour une navigation exhaustive et un meilleur SEO ;
- Le plan du site pour embrasser en un regard les pages stratégiques ;
- Le moteur de recherche pour trouver facilement et rapidement le contenu adéquat.
Comment créer une page « plan du site » pertinente ?
Vous devez remplir trois conditions pour que votre page « plan du site » réponde aux critères d’accessibilité du RGAA :
- La page reflète l’architecture générale du site ;
- Les liens sont fonctionnels ;
- Les intitulés des liens sont pertinents par rapport aux pages de destination.
Imaginez par exemple que vous avez un site web sur les vélos, avec l’architecture suivante :
- Accueil
- Boutique
- Vélos de ville
- VTC
- VTT
- Vélos électriques
- Fat Bikes
- Services
- Forfait entretien
- Réparation
- Conseils
- Guide d’achat
- Guide d’entretien
- Boutique
Le plan du site ne serait pas (du tout) conforme RGAA s’il reprenait les liens suivants :
- Accueil
- VTT
- Vélos de ville
- Fat Bikes
- Conseils
- Réparation
Pourquoi ? Car rien ne va : pas de hiérarchisation des pages, pages de 1er niveau manquant (Boutique, Services), pages de 2nd niveau avant dans la liste (VTT), liste parcellaire, etc.
Les liens intext sont-ils audités dans la partie Navigation du RGAA ?
Les liens présents dans le contenu, également appelés liens intext ou liens contextuels, font partie de la stratégie de maillage interne de votre site web. Mais ils ne sont pas considérés comme des systèmes de navigation par le RGAA, et ne sont donc pas audités dans la thématique 12 (Navigation). Les liens intext sont audités dans la thématique 6 du référentiel général d’amélioration de l’accessibilité.
Les éléments de navigation sont à la même place sur chaque ensemble de pages
Le menu et les barres de navigation doivent être toujours situés au même endroit afin de rendre la navigation plus naturelle et plus accessible. Une personne souffrant par exemple de TDAH pourra compter sur les mêmes repères pour se situer et changer plus facilement d’URL. Cette prévisibilité simplifie également la navigation au clavier ou à le recours à un lecteur d’écran. Il en va de même pour la page « plan du site », qui doit être accessible pour chaque ensemble de pages à partir d’une fonctionnalité et d’un emplacement identiques.
Mais attention, le RGAA va plus loin que la position des systèmes de navigation à l’écran. Le menu et les barres de navigation doivent également se présenter dans le même ordre dans le code source.
Pourquoi l'ordre de la présentation dans le code source est-il important ?
Vous pouvez très bien forcer l’affichage d’un menu relégué en bas du code source pour qu’il s’affiche en haut de l’écran, ou vice-versa. Certains SEO utilisent cette technique pour modifier l’ordre du DOM (Document Object Model) et mettre en haut du code HTML les informations importantes pour Google, mais descendent son affichage dans la page web pour l’expérience utilisateur : ça peut être le cas pour un sous-menu thématique dans une page listing e-commerce, qui a de l’importance pour les moteurs de recherche tout en important peu aux utilisateurs qui ont déjà accès à des filtres.
Or, les technologies d’assistance, dont les lecteurs d’écran utilisés par les personnes avec une déficience visuelle, s’appuient sur le code source pour permettre à leurs utilisateurs de naviguer. Cela compliquerait l’accessibilité si ce forçage était présent sur certaines pages et pas sur d’autres.
C’est pourquoi le RGAA explicite ce critère d’ordre dans le code source, et pas uniquement en terme de rendu à l’écran.
Astuces et tutoriels sur l'accessibilité Web
Les zones de regroupement de contenus sont évitables
Les zones de regroupement de contenus désignent des sections d’une page qui contiennent des informations connexes ou remplissent une fonction donnée. L’en-tête, la zone de navigation principale, le contenu principal ou le pied de page sont des exemples de zones de regroupement. Ces zones de regroupement peuvent ralentir ou compliquer l’accès aux sections pertinentes pour les internautes en situation de handicap qui utilisent une technologie d’assistance. Pouvoir les éviter ou les atteindre facilement est un critère de pertinence RGAA.
Vous devez utiliser des landmarks pour définir les grandes régions nommées navigables, et permettre une navigation rapide entre celles-ci :
- L’utilisation d’un WAI-ARIA de type landmark ou d’une spécification HTML5 correspondant à sa nature ;
- La présence d’un nom accessible dont le contenu permet de comprendre la nature du contenu de la zone ;
- La possibilité de masquer la zone par le biais d’un bouton qui précède directement la zone dans l’ordre du code source ;
- Un lien d’évitement situé juste avant la zone dans l’ordre du code source ;
- Un lien d’accès rapide visible à l’affichage de la page ou, à défaut, visible lors de la prise de focus.
Critères 12.6 et 12.7
Comment fonctionnent les Landmarks ?
role="main": contenu principal de la page ;role="banner": en-tête du site ;role="contentinfo": pied de page ;role="navigation": Menu de navigation ;role="search": Moteur de recherche sur le site ;role="complementary": informations complémentaires (ex: articles connexes, publicité).
<header>: correspond au landmarkrole="banner", à condition de ne pas être imbriquée dans un élément sectionnant (<article>,<aside>,<main>,;<nav>, ou<section>)<nav>: correspond au landmarkrole="navigation", et doit avoir un nom accessible unique pour chaque<nav>si la page en comporte plusieurs ;<main>: correspond au landmarkrole="main";<footer>: correspond au landmarkrole="contentinfo", en l’absence d’imbrication dans un élément sectionnant (<article>, <aside>, <main>, <nav>, ou <section>)
Comment donner un nom accessible à une balise <nav> ?
Lorsque votre page web comporte plusieurs balises <nav>, il est important de leur donner un nom accessible pour que l’utilisateur d’un lecteur d’écran comme NVDA, VoiceOver ou Jaws les différencie plus facilement.
Vous pouvez utiliser un aria-label ou un aria-labelledby :
aria-labelporte directement le texte du nom accessible, à utiliser lorsqu’aucun titre visible n’existe déjà dans la zone ;aria-labelledbyréférence l’identifiant (id) d’un texte déjà présent dans la page (un titre<h2>, par exemple).
Quel est le rôle de l'attribut tabindex ?
L’attribut tabindex était à l’origine destiné à changer l’ordre de tabulation naturel des liens et des contrôles de formulaire en utilisant des valeurs positives (par exemple, tabindex=”1″, tabindex=”2″).
Mais cet usage est fortement déconseillé, car il perturbe l’ordre de lecture logique de la page (et il est inutile s’il respecte l’ordre naturel).
WAI-ARIA a étendu l’utilisation de cet attribut, en se concentrant sur les valeurs 0 et -1, pour gérer le focus sans altérer l’ordre naturel :
- tabindex=”0″ : C’est la contribution majeure d’ARIA. Elle permet de rendre n’importe quel élément non interactif (comme un
<div>ou un<span>) atteignable au clavier, en l’insérant dans l’ordre de tabulation naturel. C’est fondamental pour rendre accessibles les composants d’interface personnalisés (widgets, boutons qui n’utilisent pas la balise<button>, etc.). - tabindex=”-1″ : Utilisé pour retirer un élément du flux de tabulation. Il est essentiel pour gérer le focus via JavaScript, notamment lors de l’ouverture d’une fenêtre modale.
Qu'est-ce que le piège au clavier ?
Même avec ces navigations optimisées, il est essentiel que la touche Tab permette toujours :
- d’atteindre le composant complexe dans son ensemble ;
- De sortir du composant (passer à l’élément suivant ou précédent dans la page) après l’interaction interne.
Pour être conforme aux critères d’accessibilité du RGAA, vous devez vous assurer que l’utilisateur n’est jamais bloqué (piégé) à l’intérieur d’un élément d’interface.
4. La navigation offre une expérience utilisateur préservée au clavier
Les critères RGAA tiennent également compte de l’accessibilité de vos contenus pour une navigation au clavier. Tous les internautes ne sont en effet pas en capacité de naviguer avec une souris : certains utilisent uniquement le clavier, d’autres un contacteur au souffle, un lecteur d’écran avec commande vocale ou encore une plage braille.
Chaque élément interactif doit pouvoir recevoir le focus et être atteint via la touche de tabulation, sans créer de piège au clavier : l’utilisateur doit toujours pouvoir passer à l’élément focusable suivant ou précédent. Lorsque la navigation interne d’un composant repose sur un autre mécanisme (les flèches directionnelles pour un slider ou une liste d’onglets, par exemple), ce mécanisme doit être fonctionnel, cohérent avec les pratiques de conception WAI-ARIA (Design Patterns), et compréhensible par l’utilisateur.
L’ordre de tabulation doit demeurer cohérent. Il ne faut pas que la navigation au clavier fasse passer par exemple l’utilisateur du début à la fin de la page avant de le faire revenir au milieu.
Cette exigence de navigation au clavier s’étend également aux contenus additionnels qui apparaissent au survol, à la prise de focus ou à l’activation d’un composant d’interface (infobulle, menu déroulant, popover…). Dès lors que ce contenu comporte lui-même un élément interactif, comme un lien dans une infobulle, il doit pouvoir être atteint et manipulé au clavier, au même titre qu’à la souris.
Critères 12.8, 12.9, 12.10, 12.11
Vous avez certainement l’habitude de naviguer avec un dispositif de pointage, qu’il s’agisse de la souris ou du pavé tactile. Mais certains utilisateurs, confrontés par exemple à une paralysie ou à des tremblements involontaires sont obligés de naviguer au clavier.
La navigation au clavier repose sur deux mécanismes principaux :
- La tabulation : en pressant la touche Tab, l’utilisateur atteint l’élément d’interface interactif suivant (bouton, lien, champ de formulaire, etc.). La navigation inverse est possible avec la combinaison Majuscule + Tab.
- Les autres interactions : des raccourcis claviers optimisés peuvent être utilisées à la place de la tabulation, notamment en cas d’éléments d’interface complexe. Par exemple, au sein d’un groupe de boutons radio ou d’un système d’onglets, les flèches de direction peuvent se substituer à la touche Tab. Dans ce cas, l’internaute doit en être informé.
L’attribut tabindex était à l’origine destiné à changer l’ordre de tabulation naturel des liens et des contrôles de formulaire en utilisant des valeurs positives (par exemple, tabindex="1", tabindex="2").
Le recours à l’attribut tabindex pour changer l’ordre de tabulation est fortement déconseillé, car il perturbe l’ordre de lecture logique de la page (critère 12.8).
WAI-ARIA a étendu l’utilisation de cet attribut, en se concentrant sur les valeurs 0 et -1, pour gérer le focus sans altérer l’ordre naturel :
- tabindex=”0″ : C’est la contribution majeure d’ARIA. Elle permet de rendre n’importe quel élément non interactif (comme un
<div>ou un<span>) atteignable au clavier, en l’insérant dans l’ordre de tabulation naturel. C’est fondamental pour rendre accessibles les composants personnalisés (widgets). - tabindex=”-1″ : Utilisé pour retirer un élément du flux de tabulation. Il est essentiel pour gérer le focus via JavaScript, notamment lors de l’ouverture d’une fenêtre modale.
La touche de tabulation Tab doit toujours permette :
- D’atteindre le composant complexe dans son ensemble ;
- De sortir du composant (passer à l’élément suivant ou précédent dans la page) après l’interaction interne.
Pour être conforme aux critères d’accessibilité du RGAA, vous devez vous assurer que l’utilisateur n’est jamais bloqué (piégé) à l’intérieur d’un élément d’interface.
Certains sites ou applications web intègrent des raccourcis clavier qui reposent sur une seule touche. Mais cela peut poser problème pour les personnes en situation de handicap qui utilisent une technologie d’assistance, car il peut y avoir des conflits entre le raccourci clavier configuré par l’éditeur du site ou de l’application et la technologie d’assistance.
Le RGAA prévoit trois solutions possibles pour contourner ce problème :
- Désactiver le raccourci clavier
- Configurer la touche de raccourci au moyen de touches de modification (Ctrl, Alt, Maj, etc.).
- Activer le raccourci uniquement quand le focus est sur le composant qui utilise le raccourci à une touche.
Certains contenus additionnels apparaissent au survol, à la prise de focus ou à l’activation d’un composant d’interface (bouton, lien, etc.). C’est par exemple le cas d’une infobulle qui apparaît au passage du curseur de la souris.
Vous devez vous assurer que ces contenus additionnels sont bien accessibles avec une navigation au clavier, afin que les personnes qui utilisent ces technologies bénéficient d’une équivalence d’accès à l’information
Les 13 thématiques du référentiel RGAA
Répondez à vos obligations légales et offrez à tous vos prospects et clients un site web accessible : auditeur certifié en accessibilité, je réalise votre audit RGAA SEO et GEO-friendly.