Comment gérer correctement le focus dans une fenêtre modale ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre le problème

Une fenêtre modale interrompt temporairement le contexte principal. À son ouverture, le focus doit être placé dans la boîte de dialogue de manière utile ; pendant l’interaction, la navigation clavier doit rester cohérente avec la modale ; à la fermeture, le focus doit généralement revenir vers un emplacement logique, souvent le déclencheur.

Inspecter le comportement réellement servi

Testez l’ouverture par clavier depuis plusieurs déclencheurs et relevez l’élément qui reçoit le focus. Parcourez tous les contrôles de la modale avec Tab et Maj+Tab, essayez la fermeture au clavier et observez le retour du focus. Inspectez également l’arbre d’accessibilité pour confirmer le rôle et le nom de la boîte de dialogue.

Distinguer les mécanismes proches

Ne confondez pas une modale avec un simple panneau visuel. Le caractère modal implique que le contenu extérieur n’est pas l’espace d’interaction actif tant que la boîte reste ouverte. Le focus initial n’est pas forcément le premier bouton : il peut viser un titre ou un contenu descriptif lorsque cela aide à comprendre une boîte complexe avant d’atteindre les actions.

Identifier les causes probables

Les régressions viennent de composants qui ouvrent la boîte sans déplacer le focus, de scripts qui le placent sur le body, de portails DOM mal intégrés ou d’éléments d’arrière-plan encore tabulables. Le retour peut échouer si le déclencheur a été supprimé ou si plusieurs modales sont empilées sans mémoriser leur origine.

Corriger à la bonne couche

À l’ouverture, choisissez une cible initiale pertinente et assurez-vous que la boîte possède une sémantique dialog adaptée. Gérez la navigation interne selon le modèle du composant, empêchez l’interaction accidentelle avec l’arrière-plan et fournissez une méthode de fermeture accessible. À la fermeture, restaurez le focus vers le déclencheur ou une cible logique si ce dernier n’existe plus.

Traiter les cas limites sans automatisme

Une boîte contenant beaucoup de texte peut demander de focaliser un élément statique au début plutôt qu’un bouton éloigné. Une action qui supprime le déclencheur peut nécessiter un autre point de retour. Vérifiez aussi les confirmations imbriquées, les popovers non modaux et les panneaux latéraux : leur comportement de focus ne doit pas être copié mécaniquement depuis une modale.

Valider sur des cas réels

Répétez le scénario avec clavier seul et plusieurs tailles d’écran. Le focus doit rester visible, aucun contrôle d’arrière-plan ne doit apparaître dans la séquence active, et la fermeture doit ramener l’utilisateur dans un contexte prévisible. Testez Escape uniquement si le composant et le besoin fonctionnel l’autorisent, sans en faire une règle universelle pour toute interface.

Conserver une preuve reproductible

Consignez le déclencheur, la cible initiale, la séquence de Tab, la méthode de fermeture et la cible de restitution. Ajoutez les rôles et attributs pertinents observés dans le DOM. Une preuve avant/après doit montrer la différence de comportement, pas seulement l’existence d’un attribut aria-modal ou d’une classe CSS.

Prévenir la régression

Centralisez le comportement dans un composant modale partagé et testez-le automatiquement pour les cas simples. Ajoutez des tests manuels pour les variantes complexes, l’empilement et la suppression du déclencheur. Un nouveau design ne doit pas pouvoir changer la position visuelle des actions sans vérifier la stratégie de focus associée.

Clôturer le diagnostic

La qualité d’une modale se juge par le parcours complet : entrée, navigation, action, fermeture et retour. Un attribut ARIA isolé ne suffit pas. Conservez une stratégie documentée et vérifiez le rendu réel avec les technologies d’assistance afin d’éviter qu’une boîte visuellement correcte ne coupe la continuité de navigation.

Construire une matrice de contrôle

Pour gestion du focus dans une modale, construisez une matrice qui sépare constat, intention, couche propriétaire et preuve finale. Le périmètre documentaire de cette page est volontairement borné : Présenter le déplacement du focus à l’ouverture, la navigation dans la modale et le retour du focus à la fermeture comme un comportement à vérifier. Ajoutez au minimum le contexte de test, la valeur observée, le résultat attendu, l'origine technique supposée puis confirmée, et la méthode de revalidation. Quand plusieurs gabarits partagent le même composant, échantillonnez des cas représentatifs plutôt que de multiplier des constats identiques. Une anomalie ambiguë doit rester en revue jusqu'à ce qu'une preuve distingue clairement configuration, contenu et comportement réellement servi. Cette matrice permet aussi de vérifier qu'une correction locale ne masque pas un problème global et qu'un changement d'infrastructure n'est pas confondu avec une décision éditoriale.

Relier ce contrôle au reste du diagnostic

Ce sujet ne doit pas être traité isolément. Vérifiez les pages et contrôles liés /site/accessibilite, /site/verifier-navigation-clavier, /site/focus-visible-accessibilite, puis comparez leurs conclusions avec l'intention « modale focus clavier accessibilite ». Les sources officielles associées à cette page sont w3c_dialog; elles bornent les affirmations externes et doivent être revalidées si leur documentation évolue. Ne transformez pas une recommandation Limpi en règle universelle : distinguez ce qui est imposé par une spécification, ce qui dépend d'un moteur ou navigateur et ce qui relève d'un choix d'implémentation. Terminez par un contrôle de cohérence entre title, H1, contenu visible, canonical, maillage et données structurées. Si deux signaux se contredisent, conservez le cas en revue au lieu de conclure sur la base d'un seul outil. Consignez enfin la date du contrôle, le gabarit concerné et le propriétaire de la correction afin de pouvoir rejouer exactement le même scénario après une évolution du site.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• w3c dialog