# Notion : ce que change réellement l’attribut inert par rapport à aria-hidden

> aria-hidden masque un contenu aux lecteurs d'écran mais laisse le clavier passer à travers. L'attribut inert corrige ce trou de sécurité au clavier. Explications.

- Auteur : Clément Hadrot
- Publié le : 2026-03-12
- Mis à jour le : 2026-03-12
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/notion-inert-versus-aria-hidden/

## L’essentiel

- aria-hidden ne retire jamais un élément du parcours clavier
- inert bloque focus, clavier et sélection en une seule fois
- Utile pour un menu mobile fermé ou un contenu derrière une modale

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.

> L'essentiel à retenir : aria-hidden ne retire jamais un élément du parcours clavier ; inert bloque focus, clavier et sélection en une seule fois ; Utile pour un menu mobile fermé ou un contenu derrière une modale

## 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.