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 ?
Un utilisateur qui navigue au clavier active un bouton et voit apparaître un panneau contenant un lien. S’il ne peut pas atteindre ce lien avec Tab, ce contenu n’existe pas pour lui. C’est exactement ce que vérifie le critère 12.11.
Le critère s’applique à tous les contenus additionnels — infobulles, menus déroulants, panneaux, popovers — qui apparaissent au survol, à la prise de focus ou à l’activation d’un composant. Mais il ne s’applique que si ce contenu additionnel contient des composants interactifs : liens, boutons, champs de formulaire. Un contenu purement informatif ne donne lieu à aucune obligation d’atteignabilité au sens de ce critère.
Deux situations provoquent systématiquement la non-conformité. Première situation : le contenu additionnel apparaît, mais le focus reste bloqué sur le déclencheur sans jamais entrer dans le panneau. Seconde situation : la séquence de tabulation saute par-dessus le contenu additionnel, invisible dans l’ordre de lecture du clavier.
Deux approches corrigent le problème. Soit déplacer le focus programmatiquement vers le premier élément interactif du panneau à l’ouverture, via .focus(). Soit insérer le contenu additionnel dans le DOM immédiatement après l’élément déclencheur, afin que Tab l’atteigne naturellement sans gestion JavaScript supplémentaire.
Un test pour s'assurer que les contenus additionnels restent atteignables au clavier
Atteignabilité clavier des composants dans les contenus additionnels
- Recensez tous les contenus additionnels de la page : infobulles, menus déroulants, panneaux, popovers, tooltips personnalisés — tout ce qui apparaît au survol, au focus ou à l’activation d’un composant d’interface.
- Pour chaque contenu additionnel, vérifiez s’il contient des éléments interactifs (liens, boutons, champs de saisie, etc.). Si le contenu est purement textuel, passez au suivant — ce test ne s’y applique pas.
- Pour chaque contenu additionnel contenant des éléments interactifs : naviguez exclusivement au clavier (Tab et Shift+Tab, sans souris) et tentez d’atteindre ces éléments interactifs.
- Résultat : le test est validé si chaque élément interactif de chaque contenu additionnel est atteignable au clavier. Il échoue dès qu’un seul élément interactif reste inaccessible.
Exemples
❌ Non conforme : Infobulle avec lien inaccessible au clavier
<div class="tooltip-wrapper">
<button aria-describedby="tip1">En savoir plus</button>
<div id="tip1" role="tooltip" class="tooltip">
Consultez notre <a href="/aide">guide complet</a> pour plus de détails.
</div>
</div>
<style>
.tooltip { display: none; }
.tooltip-wrapper:hover .tooltip,
.tooltip-wrapper:focus-within .tooltip {
display: block;
}
</style>Le tooltip s’affiche au focus du bouton grâce à :focus-within, mais role="tooltip" indique au navigateur qu’il s’agit d’une description passive. Le focus ne peut pas entrer dans ce contenu via Tab. L’utilisateur clavier voit le tooltip apparaître, mais le lien « guide complet » est inatteignable. La non-conformité est invisible à l’inspection visuelle.
✅ Conforme : Panneau interactif avec gestion correcte du focus
<div class="popover-wrapper">
<button
id="trigger-btn"
aria-expanded="false"
aria-controls="popover1"
onclick="openPopover()"
>En savoir plus</button>
<div
id="popover1"
role="dialog"
aria-labelledby="popover-title"
hidden
>
<h3 id="popover-title">Ressources complémentaires</h3>
<a href="/aide">Consulter le guide complet</a>
<button onclick="closePopover()">Fermer</button>
</div>
</div>
<script>
function openPopover() {
const popover = document.getElementById('popover1');
const btn = document.getElementById('trigger-btn');
popover.hidden = false;
btn.setAttribute('aria-expanded', 'true');
popover.querySelector('a, button').focus();
}
function closePopover() {
const popover = document.getElementById('popover1');
const btn = document.getElementById('trigger-btn');
popover.hidden = true;
btn.setAttribute('aria-expanded', 'false');
btn.focus();
}
</script>À l’activation du bouton, le focus est déplacé automatiquement dans le panneau via .focus(). L’utilisateur clavier peut atteindre le lien et le bouton « Fermer ». role="dialog" est approprié car le contenu est interactif. Le retour du focus vers le bouton déclencheur à la fermeture complète l’expérience clavier.
Astuces et pièges
⚠️ role="tooltip" bloque l’accès clavier aux éléments interactifs
C’est le piège le plus fréquent en audit sur ce critère. Quand un développeur utilise role="tooltip" sur un contenu additionnel qui contient un lien, les navigateurs excluent ce contenu de l’ordre de tabulation — c’est le comportement prévu pour un tooltip purement descriptif. Si votre « tooltip » contient des éléments interactifs, il ne doit pas avoir role="tooltip". Utilisez role="dialog" ou laissez le conteneur sans rôle ARIA spécifique.
⚠️ Contenu additionnel sans élément interactif : critère non applicable
Une infobulle qui affiche uniquement du texte descriptif (une définition, une explication contextuelle) n’est pas concernée par le critère 12.11. La mention « si nécessaire » dans l’intitulé du critère renvoie précisément à cette condition. En revanche, le critère 10.13 reste applicable : ce même contenu doit être contrôlable (dismissable, hoverable, persistent) même s’il ne contient aucun élément interactif.
💡 Insérer le contenu additionnel juste après le déclencheur dans le DOM
Si le contenu additionnel est inséré dans le DOM immédiatement après le bouton déclencheur, l’ordre naturel de tabulation permet de l’atteindre sans gestion du focus par JavaScript. C’est souvent la solution la plus simple et la plus robuste. Les problèmes apparaissent quand le contenu est injecté en fin de <body> ou dans un portail React ou Vue découplé de l’arbre DOM logique.
⚠️ Menu déroulant déclenché uniquement au survol souris
Un menu qui s’affiche exclusivement au mouseover — sans équivalent au focus clavier — cumule deux non-conformités : le critère 12.11 (les liens du menu sont inatteignables) et potentiellement le critère 12.9 si le focus se retrouve piégé lors de la navigation. La correction passe par :focus-within en CSS ou par un gestionnaire keydown en JavaScript pour déclencher l’ouverture également au clavier.
⚠️ Composants natifs HTML : conformes par défaut
Les éléments natifs comme <select> ou <details>/<summary> gèrent la navigation clavier nativement et satisfont le critère sans intervention. Le critère 12.11 cible principalement les composants JavaScript personnalisés : custom dropdowns, popovers, menus déroulants construits avec des <div> et du JavaScript.
Questions fréquentes
Comment auditer le critère RGAA 12.11 sur les contenus additionnels sans dispositif de pointage ?
Naviguez avec Tab uniquement. Quand un contenu additionnel apparaît suite au focus sur un déclencheur, continuez à appuyer sur Tab et observez si le focus entre dans ce contenu. Si Tab saute par-dessus pour atteindre l’élément suivant dans la page, le critère est non conforme. Pour les contenus qui n’apparaissent qu’au survol souris, activez d’abord le déclencheur au clavier (Entrée ou Espace) et vérifiez si le contenu s’affiche et devient atteignable.
Quelle est la différence entre le critère 12.11 et le critère 10.13 ?
12.11 vérifie que les éléments interactifs à l’intérieur d’un contenu additionnel sont atteignables au clavier. 10.13 vérifie que l’utilisateur peut contrôler l’affichage du contenu additionnel lui-même (le fermer sans déplacer le pointeur, maintenir le contenu visible au survol, etc.). Les deux critères peuvent s’appliquer simultanément au même composant. 10.13 correspond à WCAG 1.4.13 (niveau AA) ; 12.11 correspond à WCAG 2.1.1 (niveau A).
Quelles touches clavier permettent d'atteindre un dropdown de navigation conforme au critère RGAA 12.11 ?
Les deux approches sont valides selon le pattern ARIA implémenté. Pour un menu avec role="menu" et role="menuitem", le pattern ARIA recommande les touches directionnelles (flèches haut/bas) pour naviguer entre les items, et Tab pour sortir du menu — c’est le pattern « composite widget ». Pour des liens simples dans un panneau sans role="menu", Tab est la méthode naturelle. L’essentiel : chaque élément interactif doit être atteignable d’une façon ou d’une autre au clavier.
Comment un portail React ou Vue injectant du contenu en fin de <body> peut-il respecter le critère 12.11 ?
Pas automatiquement. Quand le contenu est injecté loin dans le DOM par rapport au déclencheur, l’ordre de tabulation naturel ne permet pas de l’atteindre. Il faut alors déplacer le focus programmatiquement à l’ouverture avec .focus() et le ramener au déclencheur à la fermeture. Les modales et panneaux gérés via portails exigent cette gestion explicite du focus pour satisfaire ce critère.
Quand un contenu additionnel visible uniquement au survol souris devient-il non conforme selon le critère 12.11 ?
Oui pour le critère 12.11, si le contenu ne s’affiche pas également lors de la navigation clavier. Un utilisateur clavier ne peut pas déclencher un survol souris. Si le contenu n’apparaît jamais à la prise de focus ou à l’activation au clavier, ses éléments interactifs sont inaccessibles par définition. La correction : déclencher l’affichage aussi sur :focus ou :focus-within en CSS, ou via un écouteur focusin en JavaScript.