Dans chaque page web, l’ordre de tabulation est-il cohérent ?
Un utilisateur naviguant au clavier suit l'ordre de tabulation comme une ligne de métro : s'il saute des stations ou revient en arrière sans raison, il se perd. Un ordre incohérent, c'est l'exclusion pure et simple pour les personnes qui ne peuvent pas utiliser une souris. Elles n'ont aucun moyen de rattraper un focus qui s'envole.
Ce critère vérifie que la touche Tab déplace le focus dans un ordre logique et prévisible. « Logique » ne signifie pas forcément de gauche à droite et de haut en bas : un ordre colonne par colonne peut être parfaitement cohérent dans un tableau de formulaire. Ce qui compte, c'est que l'utilisateur comprenne où il va et pourquoi. Un focus qui saute du formulaire au pied de page puis revient au menu principal, lui, n'est jamais défendable.
Le deuxième volet concerne les contenus insérés dynamiquement : modales, menus déroulants, panneaux AJAX. Quand un bouton déclenche l'affichage d'une fenêtre modale, le focus doit entrer dans cette modale. Quand la modale se ferme, le focus doit revenir sur l'élément déclencheur. Si le focus reste derrière la modale pendant qu'elle est ouverte, l'utilisateur au clavier se retrouve à interagir avec du contenu qu'il ne voit pas.
L'attribut tabindex positif (valeur > 0) est la cause principale des échecs sur ce critère en audit. Dès qu'un développeur pose un tabindex="1" quelque part, il crée une file de priorité qui court-circuite l'ordre naturel du DOM.
2 tests pour s'assurer que l'ordre de tabulation est logique
Ordre de tabulation cohérent dans la page
- Depuis le début de la page, appuyez sur Tab pour parcourir tous les éléments interactifs dans l'ordre.
- Appuyez sur Maj+Tab pour naviguer en sens inverse.
- Vérifiez que la séquence de focus est cohérente avec la structure du contenu : un focus qui traverse un formulaire, puis un menu, puis revient au formulaire est incohérent.
- Si la page contient une fenêtre modale ouverte, vérifiez que la tabulation reste confinée aux éléments de cette modale (pas d'accès aux éléments derrière elle).
- L'ordre n'a pas à suivre la lecture visuelle gauche-droite / haut-bas, mais il doit rester compréhensible et prévisible.
- Si l'ordre est cohérent : test validé. Si le focus saute sans logique entre des zones sans rapport : test échoué.
Repositionnement correct du focus après insertion de contenu
- Identifiez tous les éléments qui déclenchent l'insertion ou l'affichage de contenu par script : boutons d'ouverture de modale, accordéons, chargement AJAX, menus déroulants.
- Placez le focus clavier sur l'élément déclencheur (avec Tab).
- Activez-le (Entrée ou Espace).
- Vérifiez que le focus se déplace vers le contenu nouvellement affiché (ex. : premier élément interactif de la modale, titre de la zone chargée).
- Fermez le contenu inséré (si applicable) et vérifiez que le focus revient sur l'élément déclencheur d'origine.
- Si le focus reste cohérent à chaque étape : test validé. Si le focus se perd, reste sur le déclencheur pendant que la modale est ouverte, ou atterrit dans une zone sans rapport : test échoué.
Exemples
❌ Non conforme : tabindex positifs qui brisent l'ordre naturel
<nav>
<a href="/accueil" tabindex="3">Accueil</a>
<a href="/services" tabindex="1">Services</a>
<a href="/contact" tabindex="2">Contact</a>
</nav>
<main>
<h1>Bienvenue</h1>
<a href="/decouvrir">Découvrir nos offres</a>
</main>L'ordre de tabulation réel sera : Services → Contact → Accueil → Découvrir nos offres. L'utilisateur au clavier navigue dans un ordre qui ne correspond ni à l'ordre visuel ni à l'ordre du DOM. Si un développeur ajoute un quatrième lien sans tabindex, il passera en dernier, après « Découvrir nos offres », même s'il est au milieu du menu. C'est le scénario F44 des WCAG.
❌ Non conforme : Modale sans gestion du focus
<button id="open-modal">Ouvrir les conditions</button>
<div id="modal" role="dialog" aria-modal="true" aria-labelledby="modal-title">
<h2 id="modal-title">Conditions d'utilisation</h2>
<p>Texte des conditions...</p>
<button id="accept">Accepter</button>
<button id="close-modal">Fermer</button>
</div>
<script>
document.getElementById('open-modal').addEventListener('click', function() {
document.getElementById('modal').style.display = 'block';
// focus non déplacé vers la modale
});
</script>La modale s'affiche mais le focus reste sur le bouton « Ouvrir les conditions » derrière elle. L'utilisateur au clavier continue de naviguer dans le contenu de la page principale, invisible derrière la modale. Il ne peut pas atteindre « Accepter » ou « Fermer » sans utiliser une souris.
✅ Conforme : Ordre naturel du DOM sans tabindex perturbateur
<nav>
<a href="/accueil">Accueil</a>
<a href="/services">Services</a>
<a href="/contact">Contact</a>
</nav>
<main>
<h1>Bienvenue</h1>
<a href="/decouvrir">Découvrir nos offres</a>
</main>Sans tabindex, la tabulation suit l'ordre du DOM : Accueil → Services → Contact → Découvrir nos offres. Cet ordre correspond à l'ordre visuel et à la logique de la page. Ajouter un cinquième lien dans le menu le placera automatiquement au bon endroit dans l'ordre de tabulation, sans aucune maintenance.
✅ Conforme : Modale avec gestion correcte du focus
<button id="open-modal">Ouvrir les conditions</button>
<div id="modal" role="dialog" aria-modal="true" aria-labelledby="modal-title" style="display:none">
<h2 id="modal-title" tabindex="-1">Conditions d'utilisation</h2>
<p>Texte des conditions...</p>
<button id="accept">Accepter</button>
<button id="close-modal">Fermer</button>
</div>
<script>
const modal = document.getElementById('modal');
const openBtn = document.getElementById('open-modal');
openBtn.addEventListener('click', function() {
modal.style.display = 'block';
modal.querySelector('h2').focus(); // focus déplacé dans la modale
});
document.getElementById('close-modal').addEventListener('click', function() {
modal.style.display = 'none';
openBtn.focus(); // focus retourné sur le déclencheur
});
</script>À l'ouverture, le focus entre immédiatement dans la modale (sur le titre, rendu focalisable via tabindex="-1"). L'utilisateur au clavier navigue uniquement dans la modale. À la fermeture, le focus revient sur le bouton déclencheur : l'utilisateur reprend sa navigation là où il l'avait laissée.
Astuces et pièges
⚠️ Un seul tabindex positif suffit à tout casser
Poser tabindex="1" sur un seul élément le place en tête de tous les éléments sans tabindex positif, et devant tous ceux avec tabindex="0". En audit, il suffit d'inspecter le DOM avec les outils de développement et de filtrer sur l'attribut tabindex pour débusquer ces bombes à retardement. La règle de base : n'utilisez tabindex qu'avec les valeurs 0 (ajouter à l'ordre naturel) ou -1 (retirer de l'ordre mais garder focalisable par script).
⚠️ L'ordre CSS n'affecte pas l'ordre de tabulation
flexbox avec order, grid avec placement explicite, position: absolute : changer l'ordre visuel via CSS ne change pas l'ordre de tabulation, qui suit le DOM. Un menu affiché visuellement avant le contenu principal mais placé après dans le HTML sera atteint en dernier par la tabulation. C'est l'objet de la technique C27 des WCAG : s'assurer que l'ordre DOM et l'ordre visuel sont cohérents.
⚠️ Les composants riches avec focus interne (roving tabindex)
Un carrousel, un arbre de navigation, ou un groupe de boutons radio accessibles utilisent parfois le pattern dit « roving tabindex » : un seul élément du composant est dans l'ordre de tabulation (tabindex="0"), les autres sont à -1, et les touches directionnelles gèrent la navigation interne. Ce pattern est correct et cohérent : le test 12.8.1 est validé car l'utilisateur entre dans le composant d'un seul Tab, puis navigue avec les flèches.
💡 Tester avec le clavier, pas seulement en lisant le code
L'ordre de tabulation réel peut différer de ce que le code laisse supposer, notamment à cause d'injections JavaScript dynamiques ou de frameworks qui réorganisent le DOM au rendu. La seule méthode fiable : ouvrir la page, enlever les mains de la souris, et appuyer sur Tab en observant le déplacement du focus. Activez outline dans les styles si nécessaire (* { outline: 2px solid red !important } en CSS de débogage).
⚠️ Note RGAA : l'ordre n'a pas à être linéaire
Le RGAA précise explicitement qu'un ordre de tabulation colonne par colonne dans un tableau est valide, même s'il ne suit pas l'ordre de lecture ligne par ligne. Le critère n'impose pas un ordre particulier, mais un ordre cohérent avec la logique du contenu. Un formulaire organisé en deux colonnes peut très bien être tabulé colonne par colonne si c'est la logique métier (comme l'exemple du registre de mariages dans la technique H4 des WCAG).
💡 Piège des SPA et navigations côté client
Dans les applications monopage (React, Vue, Angular), chaque changement de route est un nouveau rendu sans rechargement de page. Si le focus n'est pas explicitement repositionné après la navigation (en général sur le titre <h1> de la nouvelle vue ou sur un élément de notification de changement de page), l'utilisateur perd le fil. Ce n'est pas un bug de tabulation au sens strict, mais un échec du test 12.8.2 car le contenu est inséré par script.
Questions fréquentes
Pourquoi tabindex="0" peut-il créer un ordre de tabulation non conforme au RGAA ?
Non, tabindex="0" est sûr. Il place l'élément dans l'ordre de tabulation naturel, à sa position dans le DOM, sans le faire sauter devant d'autres éléments. C'est la valeur correcte pour rendre focalisable un élément non interactif par défaut (comme un <div> avec role="button"). Ce sont les valeurs positives (tabindex="1", tabindex="2", etc.) qui créent une file de priorité et cassent l'ordre naturel.
Comment auditer l'ordre de tabulation sur une page complexe avec des dizaines d'éléments interactifs ?
Deux approches complémentaires. D'abord, l'inspection du DOM : recherchez tous les attributs tabindex avec une valeur positive (DevTools → onglet Elements → Ctrl+F → tabindex). Ensuite, le test clavier direct : naviguez Tab par Tab et notez si le focus traverse des zones sans logique apparente. Pour les modales et composants dynamiques, activez chaque déclencheur et vérifiez que le focus entre bien dans la zone affichée. Un outil comme taba11y (extension Chrome) visualise l'ordre de tabulation en superposition.
Comment gérer l'ordre de tabulation quand une modale est ouverte en RGAA ?
Oui. Quand une modale est ouverte, le focus doit rester piégé à l'intérieur (focus trap). L'utilisateur ne doit pas pouvoir atteindre les éléments de la page principale avec Tab : ils sont visuellement masqués, ils doivent l'être aussi pour le clavier. La technique SCR26 des WCAG décrit l'implémentation. En pratique, un focus trap se gère avec un gestionnaire d'événements sur keydown qui intercepte Tab et Maj+Tab pour les maintenir dans la modale. Des bibliothèques comme focus-trap-react ou @zag-js/focus-trap gèrent ce mécanisme.
Quelle relation RGAA impose entre l'ordre de tabulation et l'ordre de lecture visuel ?
Non, et c'est une nuance importante du RGAA 12.8. L'ordre doit être cohérent avec la logique du contenu, pas nécessairement identique à l'ordre de lecture visuel de gauche à droite et de haut en bas. Un menu de navigation placé visuellement à droite du logo mais en premier dans le DOM est acceptable si cet ordre est compréhensible. Le problème survient quand l'ordre DOM et l'ordre visuel divergent au point de désorienter l'utilisateur : c'est le cas décrit par la technique C27.
Comment corriger l'ordre de tabulation quand un framework JavaScript réorganise le DOM ?
Testez en conditions réelles, pas en lisant le JSX ou le template source. Les frameworks comme React peuvent réordonner les nœuds DOM lors du reconciliation ou via des portails (React Portals), qui téléportent des éléments hors de leur position logique dans l'arbre. Si une modale est rendue dans un portail attaché à document.body, son ordre de tabulation dépend de sa position dans le DOM réel, pas dans le JSX. Vérifiez l'ordre via les DevTools sur le DOM rendu, puis testez au clavier.