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 ?
Un utilisateur qui navigue au clavier n’a pas de pointeur. Si votre tooltip ou votre sous-menu n’apparaît qu’au survol CSS (:hover), il reste invisible pour toute personne qui n’utilise pas de souris. C’est l’erreur la plus silencieuse des interfaces modernes : visuellement tout fonctionne, mais au clavier, le contenu disparaît.
Ce critère couvre tous les contenus additionnels déclenchés exclusivement par les pseudo-classes CSS :hover ou :focus. Tooltips, menus déroulants, panneaux contextuels, bulles d’aide : dès qu’un contenu devient visible uniquement grâce à un sélecteur CSS, il doit aussi être accessible au clavier (via :focus) et à tout autre dispositif de pointage.
Concrètement, deux directions : si vous utilisez :hover, ajoutez :focus et :focus-within sur le même élément pour que les utilisateurs clavier voient le même contenu. Si vous utilisez :focus, vérifiez que le contenu s’affiche aussi au survol. Les deux pseudo-classes doivent toujours aller ensemble.
Le test pratique : tabulation uniquement, sans souris. Tout contenu qui apparaît au survol doit apparaître à la prise de focus.
2 tests pour vérifier que les contenus générés par CSS sont accessibles
Contenu CSS :hover accessible au focus
- Identifiez tous les contenus qui apparaissent uniquement via
:hoversur un composant d’interface (tooltip, sous-menu, panneau contextuel, etc.). - Pour chacun, vérifiez que le même contenu additionnel est visible dans au moins une de ces situations :
- Activation du composant au clavier (touche Entrée ou Espace) ou via un autre dispositif de pointage.
- Prise de focus sur le composant (Tab ou Shift+Tab).
- Activation ou prise de focus sur un autre composant déclencheur.
- Testez en branchant uniquement le clavier et en naviguant à la tabulation.
- Si le contenu additionnel reste accessible dans au moins un de ces scénarios pour chaque instance, le test est validé. Si un seul contenu reste invisible au clavier, le test échoue.
Contenu CSS :focus accessible au survol
- Identifiez tous les contenus qui apparaissent uniquement via
:focussur un composant d’interface. - Pour chacun, vérifiez que le même contenu additionnel est visible dans au moins une de ces situations :
- Activation du composant au clavier ou via un autre dispositif de pointage.
- Survol du composant à la souris (
:hover). - Activation ou survol d’un autre composant déclencheur.
- Testez en naviguant uniquement à la souris pour confirmer que le contenu reste accessible sans clavier.
- Si le contenu additionnel est accessible dans au moins un de ces scénarios pour chaque instance, le test est validé. Dans le cas contraire, le test échoue.
Exemples
❌ Non conforme : Tooltip visible uniquement au survol CSS
<style>
.tooltip-text {
display: none;
}
.tooltip:hover .tooltip-text {
display: block;
}
</style>
<span class="tooltip">
En savoir plus
<span class="tooltip-text">Ce champ accepte uniquement les adresses e-mail professionnelles.</span>
</span>Le contenu .tooltip-text n’est révélé qu’au survol CSS. Un utilisateur clavier qui atteint cet élément par tabulation ne verra jamais l’information sur les adresses e-mail professionnelles. Le critère 10.14.1 échoue.
✅ Conforme : Tooltip accessible au survol et au focus
<style>
.tooltip-text {
display: none;
}
.tooltip:hover .tooltip-text,
.tooltip:focus .tooltip-text,
.tooltip:focus-within .tooltip-text {
display: block;
}
</style>
<span class="tooltip" tabindex="0">
En savoir plus
<span class="tooltip-text">Ce champ accepte uniquement les adresses e-mail professionnelles.</span>
</span>En ajoutant :focus et :focus-within aux mêmes règles CSS, le tooltip s’affiche aussi lors de la navigation clavier. L’attribut tabindex="0" rend l’élément focusable. Un utilisateur clavier reçoit exactement la même information qu’un utilisateur souris.
✅ Conforme : Sous-menu déroulant accessible au clavier
<style>
.submenu {
display: none;
}
.nav-item:hover .submenu,
.nav-item:focus-within .submenu {
display: block;
}
</style>
<nav>
<ul>
<li class="nav-item">
<a href="/produits">Produits</a>
<ul class="submenu">
<li><a href="/produits/logiciels">Logiciels</a></li>
<li><a href="/produits/services">Services</a></li>
</ul>
</li>
</ul>
</nav>:focus-within sur le conteneur parent est la clé : quand n’importe quel enfant (le lien parent ou un lien du sous-menu) reçoit le focus, le sous-menu reste ouvert. Sans :focus-within, le sous-menu se ferme dès que le focus passe du déclencheur aux liens enfants.
Astuces et pièges
⚠️ Oublier :focus-within sur les menus déroulants
Ajouter :focus sur le déclencheur ne suffit pas pour les menus à plusieurs niveaux. Dès que le focus passe au premier lien enfant, l’élément déclencheur perd son focus et le menu se referme. C’est l’erreur numéro un en audit : le menu semble accessible car il s’ouvre au focus, puis se ferme immédiatement. Utilisez :focus-within sur le conteneur parent.
⚠️ Le contenu CSS additionnel généré par ::before ou ::after
Ce critère ne couvre que les contenus porteurs d’information. Un pseudo-élément ::before qui affiche une icône décorative au survol n’est pas concerné. En revanche, si ::after affiche un texte informatif (une étiquette, un statut, un compteur), il doit aussi être visible au clavier. En pratique, les contenus ::before/::after sont rarement focusables — préférez un <span> masqué visuellement avec la technique .sr-only pour ce type de contenu.
💡 Préférer les combinaisons de sélecteurs plutôt que JavaScript
Pour la majorité des cas (tooltips, menus simples), la solution purement CSS avec :hover, :focus, :focus-within est suffisante et plus robuste qu’un script JavaScript. Elle fonctionne sans JS activé et ne génère aucun événement à gérer. Réservez JavaScript pour les interactions complexes qui nécessitent une gestion de l’état (aria-expanded, aria-hidden).
⚠️ Dispositifs de pointage autres que la souris
Le critère mentionne « tout dispositif de pointage » : stylet, écran tactile, trackpad. Sur mobile, il n’y a pas de survol natif. Un contenu conditionné uniquement à :hover sera donc invisible sur tablette et smartphone. Les pseudo-classes :focus et :focus-within couvrent ces dispositifs lors d’une interaction directe.
⚠️ Ce critère ne s’applique pas aux contenus décoratifs
Un fond coloré, une ombre portée ou un changement d’opacité déclenchés par :hover ne sont pas des « contenus additionnels porteurs d’information ». Le critère 10.14 cible les éléments qui apportent une information nouvelle à l’utilisateur : texte, image, panneau, sous-menu. Un simple effet visuel de style n’est pas concerné.
Questions fréquentes
Comment auditer rapidement le critère RGAA 10.14 sur les contenus CSS additionnels ?
Débranchez la souris. Naviguez à la tabulation et vérifiez que chaque contenu qui apparaît normalement au survol est aussi visible à la prise de focus. Ensuite, naviguez uniquement à la souris pour vérifier l’inverse (test 10.14.2). Un outil comme la DevTools « Force element state » permet aussi de simuler :hover et :focus simultanément pour comparer les états CSS.
Quand la combinaison :hover, :focus en CSS satisfait-elle le critère RGAA 10.14 ?
Pour les tooltips simples sur un seul élément focusable, oui. Pour les menus déroulants avec plusieurs liens enfants, non. Il faut ajouter :focus-within sur le conteneur parent, sinon le menu se ferme dès que le focus quitte le déclencheur pour passer aux liens internes. C’est le scénario le plus fréquemment raté en production.
Comment le critère RGAA 10.14 s'applique-t-il aux menus JavaScript avec aria-expanded ?
Non, ce critère vise spécifiquement les contenus rendus visibles « via les styles CSS uniquement ». Si la visibilité est contrôlée par JavaScript (changement de classe, modification de aria-hidden, etc.), le critère 10.14 ne s’applique pas. C’est alors le critère 2.1.1 WCAG et les critères RGAA sur les composants interactifs (thème 7) qui entrent en jeu.
Dans quels cas un élément non focusable satisfait-il le test RGAA 10.14.1 ?
Non. Si le déclencheur n’est pas dans l’ordre de tabulation (pas de tabindex, pas un élément interactif natif), il ne peut pas recevoir le focus et le contenu additionnel reste inaccessible au clavier. Il faut soit rendre l’élément focusable avec tabindex="0", soit trouver un autre composant dans la page qui déclenche l’affichage à son activation ou à son focus.
Comment distinguer les critères RGAA 10.13 et 10.14 sur les contenus CSS additionnels ?
Le critère 10.13 vérifie que les contenus additionnels sont contrôlables par l’utilisateur (possibilité de les fermer, de les déplacer, de les maintenir visibles). Le critère 10.14 vérifie uniquement qu’ils apparaissent bien au clavier et aux dispositifs de pointage. Les deux se cumulent : un tooltip peut satisfaire 10.14 (il s’affiche au focus) mais échouer 10.13 s’il disparaît dès que l’utilisateur déplace le pointeur pour le lire.