BLOG · MÉTHODE
Navigation clavier RGAA : lien d’évitement, menus, modales et focus
Par Théodis Guyon · Publié le · Lecture : 7 min

L’essentielUn site doit pouvoir se parcourir entièrement au clavier : avec un lien d’évitement vers le contenu, un ordre de tabulation logique, un focus toujours visible et aucun piège. Le RGAA le vérifie par la thématique 12, Navigation, et par des critères des thématiques Scripts, Présentation et Consultation. Un premier test prend cinq minutes, sans outil.
Quels critères du RGAA portent sur la navigation au clavier ?
Une dizaine de critères, répartis dans quatre thématiques. Voici les principaux, avec leur libellé officiel.
| Critère | Libellé officiel |
|---|---|
| 12.6 | Les zones de regroupement de contenus présentes dans plusieurs pages web (zones d’en-tête, de navigation principale, de contenu principal, de pied de page et de moteur de recherche) peuvent-elles être atteintes ou évitées ? |
| 12.7 | Dans chaque page web, un lien d’évitement ou d’accès rapide à la zone de contenu principal est-il présent (hors cas particuliers) ? |
| 12.8 | Dans chaque page web, l’ordre de tabulation est-il cohérent ? |
| 12.9 | Dans chaque page web, la navigation ne doit pas contenir de piège au clavier. Cette règle est-elle respectée ? |
| 12.11 | Dans chaque page web, les contenus additionnels apparaissant au survol, à la prise de focus ou à l’activation d’un composant d’interface sont-ils si nécessaire atteignables au clavier ? |
| 7.1 | Chaque script est-il, si nécessaire, compatible avec les technologies d’assistance ? |
| 7.3 | Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage (hors cas particuliers) ? |
| 10.7 | Dans chaque page web, pour chaque élément recevant le focus, la prise de focus est-elle visible ? |
| 10.14 | Dans chaque page web, les contenus additionnels apparaissant via les styles CSS uniquement peuvent-ils être rendus visibles au clavier et par tout dispositif de pointage ? |
| 13.8 | Dans chaque page web, chaque contenu en mouvement ou clignotant est-il contrôlable par l’utilisateur ? |
La liste complète des thématiques est dans l’article sur les 106 critères du RGAA.
Qu’est-ce qu’un lien d’évitement ?
C’est un lien placé en haut de page qui permet de sauter le menu et d’arriver directement au contenu. Le glossaire du RGAA distingue deux formes : le lien d’évitement, qui saute une zone, et le lien d’accès rapide, qui mène à une zone, comme le contenu, le menu ou la recherche.
Le test 12.7.2 fixe quatre conditions :
- le lien est situé à la même place dans la présentation ;
- il se présente toujours dans le même ordre relatif dans le code source ;
- il est visible ou, à défaut, visible à la prise de focus ;
- il est fonctionnel.
Fonctionnel a un sens précis. Selon le glossaire, l’activation du lien doit permettre de reprendre la lecture et la navigation au clavier à partir de la cible. Un lien qui fait défiler la page sans déplacer le focus ne suffit pas.
Le glossaire ajoute une note sur les zones balisées pour les lecteurs d’écran. Les navigateurs n’offrent pas encore de navigation dédiée entre ces zones pour les personnes qui n’utilisent pas la souris. Le lien d’évitement reste donc à privilégier.
Comment tester son site au clavier en cinq minutes ?
En posant la souris et en parcourant une page avec quelques touches. Le glossaire du RGAA définit la prise de focus par la touche Tab ou Maj+Tab, et l’activation d’un lien ou d’un bouton par la touche Entrée.
- Tab, dès le chargement. Un lien « Aller au contenu » doit apparaître au début du parcours. Appuyer sur Entrée. La tabulation suivante doit partir du contenu principal, pas du menu.
- Tab, encore et encore. À chaque pression, l’élément atteint doit se voir clairement. L’ordre doit suivre celui de la lecture.
- Le menu. Atteindre une rubrique qui a un sous-menu. L’ouvrir au clavier, puis atteindre chacun de ses liens.
- Une fenêtre qui s’ouvre. Ouvrir une modale, par exemple la recherche. Le focus doit y entrer. Tab doit rester dans la fenêtre. Échap doit la fermer et ramener le focus sur le bouton d’origine.
- Maj+Tab pour revenir. Remonter la page. Si le focus reste bloqué quelque part, c’est un piège au clavier.
Ce test repère des défauts. Il ne mesure pas la conformité, qui demande un audit sur un échantillon de pages. Nous en expliquons les limites dans l’article sur l’audit automatique.
Pourquoi les menus déroulants bloquent-ils souvent ?
Parce qu’ils sont souvent conçus pour la souris. Trois critères s’appliquent.
- Le sous-menu s’ouvre seulement au survol. Le critère 10.14 demande qu’un contenu qui apparaît au survol par les styles CSS apparaisse aussi au clavier. Le critère 7.3 demande qu’un script soit contrôlable au clavier.
- L’état n’est pas annoncé. Le critère 7.1 demande que le nom, le rôle, la valeur et les changements d’état d’un composant soient accessibles aux technologies d’assistance. Un lecteur d’écran doit savoir si le sous-menu est ouvert ou fermé.
- Les liens du sous-menu sont hors d’atteinte. Le critère 12.11 demande que ces contenus soient atteignables au clavier.
Que doit faire une fenêtre modale au clavier ?
Elle doit prendre le focus à l’ouverture, le garder tant qu’elle est ouverte, et le rendre à la fermeture. Le RGAA ne consacre pas de critère aux modales. Une modale est un composant créé par un script : elle relève des critères 7.1 et 7.3. Le test 12.8.2 vérifie aussi que l’ordre de tabulation reste cohérent quand un script insère un contenu.
Le RGAA renvoie lui-même au motif de conception WAI-ARIA « dialog », dans les cas particuliers du critère 10.13. Ce motif, publié par le W3C, décrit le comportement attendu :
- à l’ouverture, le focus se place sur un élément de la fenêtre ;
- Tab et Maj+Tab circulent entre les éléments de la fenêtre, en boucle ;
- Échap ferme la fenêtre ;
- à la fermeture, le focus revient sur l’élément qui l’a ouverte.
Le défaut courant : la modale s’affiche, mais le focus reste derrière, dans la page. La personne tabule dans un contenu qu’elle ne voit plus.
Focus invisible et carrousels : quels défauts fréquents ?
Le focus invisible. Le test 10.7.1 accepte deux cas : le style de focus du navigateur n’est ni supprimé ni dégradé, ou un style défini par l’auteur est visible. Le glossaire précise que ce style doit être suffisamment contrasté au regard du critère 3.3. Un contour retiré par la feuille de style, sans remplacement, fait échouer le critère. Le contraste est détaillé dans l’article sur le contraste des couleurs.
Le carrousel. Un bandeau d’actualités qui défile seul relève du critère 13.8. Si le mouvement dure plus de 5 secondes, l’utilisateur doit pouvoir l’arrêter et le relancer, ou le masquer, ou afficher toute l’information sans mouvement. Les boutons du carrousel doivent aussi fonctionner au clavier (critère 7.3) et montrer leur focus.
Chaque défaut relevé en audit devient une fiche de correction que le prestataire du site peut traiter. Les formulaires ont leurs propres pièges, décrits dans trois défauts fréquents des formulaires. Le détail de notre offre est sur la page Prestations.
Questions fréquentes
Le lien d’évitement doit-il être visible en permanence ?
Non. Le test 12.7.2 accepte un lien visible, ou à défaut visible à la prise de focus. Il peut donc n’apparaître qu’à la première tabulation.
Un site d’une seule page a-t-il besoin d’un lien d’évitement ?
Pas toujours. Le critère 12.7 prévoit ce cas particulier. Le lien dépend alors du contexte de la page, et le critère peut être non applicable s’il est avéré que le lien est inutile.
Les zones balisées dispensent-elles du lien d’évitement ?
Non. Le glossaire du RGAA indique que les navigateurs ne proposent pas encore de navigation dédiée entre ces zones au clavier. Le lien d’évitement reste à privilégier.
Garder le focus dans une modale, est-ce un piège au clavier ?
La modale doit pouvoir se fermer au clavier. Le motif « dialog » du W3C prévoit la touche Échap. Une fenêtre dont on ne peut pas sortir au clavier pose le problème que vise le critère 12.9.
Ce test de cinq minutes remplace-t-il un audit ?
Non. Il repère des défauts visibles. Un audit RGAA vérifie aussi la restitution par les technologies d’assistance, sur un échantillon de pages défini.
Sources
- DINUM, RGAA 4.1.2, critères et tests, thématiques Navigation, Scripts, Présentation de l’information et Consultation, consulté le 27/09/2026.
- DINUM, RGAA 4.1.2, glossaire : liens d’évitement ou d’accès rapide, prise de focus, landmarks, consulté le 27/09/2026.
- W3C, ARIA Authoring Practices Guide, motif Dialog (Modal), en anglais, consulté le 27/09/2026.
À lire ensuite : Étiquette, contraste, clavier : trois défauts fréquents des formulaires.