Pourquoi un menu mobile masqué visuellement reste-t-il accessible au clavier alors qu’on lui a posé un aria-hidden="true" ? C’est la question qu’on nous pose le plus souvent sur ce sujet, et la réponse tient en une phrase : aria-hidden ne parle qu’aux technologies d’assistance, jamais au navigateur lui-même.
Concrètement, un lien ou un bouton caché avec aria-hidden disparaît de l’arbre d’accessibilité exposé à un lecteur d’écran, mais reste parfaitement focusable à la tabulation et cliquable au clic. Sur un menu off-canvas fermé, cela produit un focus fantôme : l’utilisateur au clavier tabule et atterrit sur un lien invisible à l’écran, sans aucun repère visuel de sa position.
Le fonctionnement de aria-hidden en détail
aria-hidden="true" est un attribut ARIA : il modifie la représentation sémantique d’un nœud pour l’arbre d’accessibilité, un objet parallèle au DOM que consultent les lecteurs d’écran. Il n’a aucun effet sur le rendu visuel ni sur le comportement du navigateur en matière de focus. Poser aria-hidden sur un conteneur qui contient des liens ou des champs de formulaire focusables crée donc une incohérence : invisible pour un lecteur d’écran, mais toujours atteignable au clavier ou au pavé tactile.
C’est précisément pour cette raison que les référentiels recommandent de combiner aria-hidden avec un retrait effectif du focus, historiquement via tabindex="-1" posé sur chaque élément focusable interne, une opération fastidieuse et source d’oublis dès que la structure du contenu change.
Ce qu’inert fait de plus
L’attribut inert, désormais supporté par les navigateurs modernes, résout ce problème en une seule déclaration. Posé sur un conteneur, il rend l’intégralité de son contenu non interactif : plus de focus possible, plus de clic actif, plus de sélection de texte, et l’élément est automatiquement retiré de l’arbre d’accessibilité, comme s’il portait un aria-hidden implicite.
<nav id="menu-mobile" inert>
<a href="/accueil">Accueil</a>
<a href="/contact">Contact</a>
</nav>
<script>
function ouvrirMenu() {
document.getElementById('menu-mobile').removeAttribute('inert');
}
function fermerMenu() {
document.getElementById('menu-mobile').setAttribute('inert', '');
}
</script>Un seul attribut à basculer en JavaScript, plutôt qu’une boucle sur tous les éléments focusables du menu pour leur poser et retirer un tabindex. C’est aussi plus robuste : si un rédacteur ajoute un nouveau lien dans le menu sans repasser par le composant JavaScript, celui-ci hérite automatiquement du comportement inert du parent.
Les différences de comportement au clavier et au focus
- aria-hidden seul : le contenu reste focusable, la tabulation continue de s’y arrêter, seul un lecteur d’écran l’ignore
- inert seul : le contenu devient totalement non interactif pour tout le monde, y compris à la souris et au clavier, et il est aussi masqué des technologies d’assistance
- inert + display: none ou visibility: hidden : redondant en pratique, mais sans danger ; beaucoup de projets gardent les deux par prudence pendant la période de transition des navigateurs plus anciens
Un autre effet notable d’inert : la recherche dans la page avec Ctrl+F ignore aussi le contenu concerné, ce qui n’est pas le cas avec aria-hidden seul. Pour un contenu situé derrière une fenêtre modale ouverte, c’est exactement le comportement attendu : rien en dehors de la modale ne devrait être trouvable ni atteignable tant qu’elle est ouverte.
Cas d’usage concrets sur un projet WordPress
Sur un thème personnalisé, on applique typiquement inert à trois endroits : le contenu principal de la page pendant qu’une fenêtre modale de type <dialog> est ouverte (le natif s’en charge en partie, mais pas toujours dans les zones hors du <dialog> lui-même), le panneau d’un menu off-canvas fermé, et les diapositives non actives d’un carrousel construit sans bibliothèque tierce.
Pour ce dernier cas, poser inert sur les diapositives masquées évite qu’un utilisateur au clavier ne tabule vers un lien « en savoir plus » appartenant à une diapositive qui n’est pas affichée à l’écran, un défaut qu’on retrouve encore régulièrement sur des carrousels maison.
Notion pour aller plus loin
Retenez la distinction essentielle : aria-hidden parle aux technologies d’assistance, inert parle au navigateur et, par ricochet, retire aussi l’élément de l’arbre d’accessibilité. Pour tout contenu qui doit être totalement neutralisé — fermé, masqué, derrière une superposition — préférez inert seul. Réservez aria-hidden aux cas où le contenu reste volontairement interactif visuellement mais ne doit pas être annoncé, comme une icône décorative cliquable dont le texte est porté ailleurs.
