Dans chaque page web, la navigation ne doit pas contenir de piège au clavier. Cette règle est-elle respectée ?
Un utilisateur navigue au clavier et entre dans une zone d’édition de texte enrichi. Il appuie sur Tab pour atteindre le bouton suivant. Rien ne se passe. Maj+Tab : toujours rien. Sans souris, il ne peut plus avancer ni reculer dans la page. C’est un piège au clavier.
Un piège au clavier, c’est exactement ça : le focus entre dans un composant et ne peut plus en sortir par le clavier seul. Pour les personnes qui naviguent exclusivement au clavier — handicap moteur, utilisateurs de lecteurs d’écran, développeurs qui testent en tabulant — c’est une exclusion totale de tout ce qui suit le composant bloquant. La seule issue est de fermer l’onglet ou de relancer le navigateur.
Le critère vérifie que chaque élément recevant le focus permet d’en sortir : soit par Tab ou Maj+Tab, soit par un autre mécanisme clavier explicitement communiqué à l’utilisateur. « Susceptible de recevoir le focus » signifie les éléments qui reçoivent effectivement le focus, qu’ils soient atteints par tabulation ou par script.
Ne confondez pas piège et inaccessibilité. Si un composant n’est jamais atteint par Tab, ce n’est pas le 12.9 qui s’applique — c’est le 7.3. Deux problèmes distincts, deux corrections distinctes.
Un test pour détecter un éventuel piège au clavier
Absence de piège au clavier dans les éléments focusables
- Débranchez la souris. Parcourez toute la page avec Tab en notant chaque élément qui reçoit le focus.
- Repérez aussi les éléments qui reçoivent le focus via un script (widgets ARIA, composants interactifs).
- Pour chaque élément focusé, vérifiez qu’il est possible d’en sortir :
- Avec Tab (élément suivant) ou Maj+Tab (élément précédent), OU
- Avec un autre raccourci clavier, à condition que l’utilisateur en soit informé dans la page (texte visible, label, instruction).
- Pour les composants complexes (groupes de boutons radio, onglets ARIA, listbox) : vérifiez uniquement que Tab entre dans le composant et que Tab ou Maj+Tab en ressort vers la page. La navigation interne aux flèches de direction n’est pas concernée par ce test.
Résultat : si chaque élément focusable permet de poursuivre la navigation clavier, le test est validé. Si un seul composant bloque définitivement le focus sans issue clavier, le test est non validé.
Exemples
❌ Non conforme : Éditeur de texte enrichi qui capture Tab sans offrir de sortie
<label for="description">Description du produit</label>
<div
id="description"
contenteditable="true"
tabindex="0"
onkeydown="handleEditorKeys(event)">
Rédigez votre description ici
</div>
<button type="submit">Publier</button>La fonction handleEditorKeys intercepte tous les événements clavier pour gérer la mise en forme (indentation, listes, raccourcis de formatage). Si Tab est capturé pour insérer une tabulation dans le texte et que ni Maj+Tab ni Échap ne sont gérés pour sortir du composant, l’utilisateur est piégé : le bouton Publier est totalement inaccessible au clavier. La seule issue est de fermer l’onglet.
✅ Conforme : Boîte de dialogue modale avec sortie clavier documentée
<button type="button" id="open-modal">Filtrer les résultats</button>
<div
role="dialog"
aria-modal="true"
aria-labelledby="modal-title"
id="filters-modal"
tabindex="-1">
<h2 id="modal-title">Filtres de recherche</h2>
<label for="category">Catégorie</label>
<select id="category">
<option>Tous</option>
<option value="vetements">Vêtements</option>
</select>
<button type="button" id="close-modal">Fermer (Échap)</button>
</div>
<script>
document.addEventListener('keydown', function(e) {
if (e.key === 'Escape') { closeModal(); }
});
</script>La modale confine intentionnellement le focus à l’intérieur tant qu’elle est ouverte — c’est le comportement attendu pour role="dialog". Mais l’utilisateur peut en sortir à tout moment via Échap ou le bouton Fermer. La mention « Échap » dans le label du bouton informe explicitement du mécanisme disponible, ce que le critère exige lorsque la sortie ne passe pas par Tab. Pas de piège.
Astuces et pièges
⚠️ Élément inaccessible au clavier ≠ piège au clavier
Un composant jamais atteint par Tab n’est pas un piège. C’est une non-conformité au critère 7.3 (script contrôlable au clavier et au pointeur). Le 12.9 sanctionne uniquement les éléments qui reçoivent le focus et dont on ne peut plus sortir. Cocher 12.9 au lieu de 7.3 dans un rapport d’audit, c’est indiquer la mauvaise correction à l’équipe de développement.
⚠️ Composants ARIA complexes : Tab en entrée et en sortie suffit
Un groupe de boutons radio, une listbox ou un système d’onglets ARIA utilisent les flèches de direction pour naviguer entre leurs options internes. Ce n’est pas un piège. Le test 12.9.1 se limite à vérifier que Tab entre dans le composant et que Tab ou Maj+Tab en ressort vers le reste de la page. La navigation interne aux flèches est hors scope de ce critère.
💡 Testez en priorité les plugins embarqués et les iframes
Les éditeurs WYSIWYG, les lecteurs vidéo tiers, les cartes interactives et les visionneuses PDF sont les composants les plus fréquemment piégeants en audit réel. Ils capturent les événements clavier pour leurs propres raccourcis et oublient de gérer la sortie. Entrez dans chaque iframe ou plugin, puis testez immédiatement Tab, Maj+Tab et Échap.
⚠️ La modale est un piège intentionnel — sous conditions
Confiner le focus dans une boîte de dialogue modale est le comportement correct selon les spécifications ARIA. Ce n’est pas une violation du critère 12.9 si un mécanisme de sortie existe : touche Échap, bouton Fermer, ou toute combinaison clavier communiquée à l’utilisateur. Sans aucun moyen de fermer la modale au clavier, là c’est un piège avéré.
⚠️ Le quasi-piège : sortie possible mais introuvable
Certains composants permettent techniquement d’en sortir, mais le mécanisme est si peu visible que l’utilisateur se croit bloqué — une modale fermable par Maj+Tab sur le premier élément, sans bouton ni indication. Techniquement pas un piège au sens du 12.9, mais une expérience profondément frustrante. À signaler en remarque d’audit, avec référence au critère 12.8 si l’ordre de tabulation est incohérent.
Questions fréquentes
Comment auditer un piège au clavier concrètement selon le RGAA ?
Débranchez la souris et parcourez toute la page avec Tab. Quand le focus entre dans un composant interactif, testez Tab, Maj+Tab, Échap et les flèches directionnelles. Si aucune touche ne permet de continuer la navigation, documentez le composant : type de composant, position dans la page, touches testées, résultat. Les éditeurs WYSIWYG, les iframes tiers et les plugins multimédias sont les zones à tester en priorité.
Quels mécanismes de sortie sont valides pour satisfaire le critère RGAA 12.9 ?
Oui, à condition que l’utilisateur soit informé de ce mécanisme. Le critère accepte « une autre interaction clavier dont l’utilisateur est informé ». Si Échap fonctionne mais n’est mentionné nulle part dans la page, ce n’est pas suffisant. L’information peut figurer dans le label du bouton Fermer, dans les instructions visibles du composant, ou dans un texte d’aide associé.
Comment distinguer un contenteditable capturant Tab légitimement d'un piège au clavier RGAA ?
Non, pas forcément. Si le composant affiche une instruction visible comme « Appuyez sur Échap pour quitter l’éditeur » et que cette touche fonctionne, le critère 12.9 est respecté. Le problème survient quand Tab est capturé ET qu’aucune autre sortie clavier n’est prévue ni communiquée. C’est la combinaison des deux qui crée le piège.
Quelle est la différence entre le critère RGAA 12.9 et le critère 7.3 ?
Le critère 12.9 s’applique aux éléments qui reçoivent le focus mais dont on ne peut plus sortir au clavier. Le critère 7.3 s’applique aux scripts qui ne fonctionnent qu’à la souris, sans équivalent clavier. Un composant jamais atteint par Tab relève de 7.3. Un composant atteignable mais bloquant relève de 12.9. Les deux peuvent échouer sur la même page pour des raisons différentes et nécessitent des corrections distinctes.