Symptôme. Sur un site e-commerce, une popup d’inscription à la newsletter s’affiche après quelques secondes de navigation. Un utilisateur clavier, surpris par son apparition, appuie sur Tab pour tenter de comprendre ce qui vient de se passer. Le focus, au lieu de rester dans la popup, continue de circuler dans les liens du contenu situé en arrière-plan, invisible sous l’overlay semi-transparent. L’utilisateur clique alors, à l’aveugle, sur des liens qu’il ne voit plus, sans jamais parvenir à fermer la fenêtre qui recouvre l’écran.
Diagnostic. Ce défaut, extrêmement courant sur les popups générées par des plugins marketing, porte un nom précis dans le vocabulaire de l’accessibilité : l’absence de focus trap, ou piège à focus. Une fenêtre modale, par définition, doit interrompre l’interaction avec le reste de la page tant qu’elle est ouverte, aussi bien visuellement qu’au niveau du focus clavier. Sans ce mécanisme, l’overlay visuel ment sur l’état réel de la page : il semble bloquer l’accès au contenu, mais le clavier continue d’y naviguer librement.
Les trois règles d’une modale correctement piégée
Le pattern ARIA Authoring Practices Guide pour les fenêtres modales (dialog) fixe un comportement précis, indépendant du framework utilisé pour la générer :
- À l’ouverture, le focus se déplace immédiatement à l’intérieur de la modale, généralement sur son premier élément interactif ou sur son titre
- Tant que la modale est ouverte, la touche Tab ne doit jamais faire sortir le focus vers un élément situé en dehors d’elle ; en bout de liste, le focus revient au premier élément de la modale
- La touche Échap ferme systématiquement la modale, et le focus revient sur l’élément qui l’a ouverte
Correctif : une implémentation minimale avec l’élément dialog
Depuis son adoption large par les navigateurs modernes, l’élément HTML natif <dialog> gère nativement une grande partie de ce comportement, y compris le piège de focus, à condition d’être ouvert via sa méthode JavaScript showModal() plutôt que par un simple changement de classe CSS.
const modale = document.querySelector('#modale-newsletter');
const bouton = document.querySelector('#ouvrir-modale');
bouton.addEventListener('click', function () {
modale.showModal();
});
modale.addEventListener('close', function () {
bouton.focus();
});
Utiliser showModal() plutôt que l’attribut open seul déclenche automatiquement la gestion du focus trap par le navigateur, ainsi que la fermeture au clavier via Échap, sans code supplémentaire. C’est une différence essentielle : de nombreuses implémentations de popups se contentent d’afficher une <div> avec un display: block, ce qui ne déclenche aucun de ces comportements natifs et oblige à tout reconstruire manuellement.
Quand une bibliothèque JavaScript reste nécessaire
Pour des cas plus complexes, notamment le support de navigateurs plus anciens ou une modale imbriquée dans un plugin existant qui ne peut pas être réécrit autour de <dialog>, une petite bibliothèque dédiée au piège de focus (le terme anglais couramment employé est focus trap) reste la solution la plus fiable. Réimplémenter ce comportement à la main, en recalculant à chaque changement de contenu la liste des éléments focusables de la modale, est une source d’erreurs fréquente à éviter si une bibliothèque éprouvée est disponible.
Prévention pour les prochains projets
La meilleure prévention consiste à traiter toute demande de popup, quelle que soit sa finalité marketing ou fonctionnelle, comme un composant à part entière nécessitant une recette dédiée au clavier, et pas seulement un test visuel. Avant d’intégrer un plugin de popup tiers, un test rapide au clavier sur sa démonstration officielle permet souvent de repérer ce défaut avant même de l’installer sur le projet.
Une popup marketing reste, du point de vue de l’accessibilité, un composant aussi exigeant qu’un formulaire de paiement. Le fait qu’elle serve un objectif commercial plutôt que fonctionnel ne réduit en rien les règles à respecter pour qu’elle reste utilisable.
En résumé
Un focus trap correctement implémenté transforme une modale d’un obstacle potentiellement bloquant en un composant parfaitement navigable au clavier. L’élément natif <dialog>, associé à sa méthode showModal(), couvre désormais l’essentiel de ce besoin sans bibliothèque tierce, ce qui devrait devenir le premier réflexe pour toute nouvelle popup développée sur un projet WordPress.
