Gestion du focus dans les interactions de page unique : boîtes de dialogue, changements de route et éléments supprimés

Objectif

Garder le focus clavier sur quelque chose de pertinent à chaque changement de page sans chargement complet : ouverture et fermeture de boîtes de dialogue, navigation côté client, suppression de l'élément focalisé, et remplacement d'une vue après une action. Un chargement complet de page réinitialise le focus pour tout le monde ; une transition de page unique doit effectuer ce travail elle-même.

Prérequis

L'élément natif <dialog> lorsque c'est possible ; un routeur qui expose un hook après le rendu de la nouvelle vue ; et la technique tabindex="-1", que MDN décrit comme rendant un élément focalisable par script sans l'ajouter à la séquence de tabulation.

Étapes

1. Boîtes de dialogue : ouvrir avec showModal(). MDN indique qu'une boîte de dialogue modale rend le reste de la page inerte et peut être fermée avec la touche Échap, ce qui rend inutile un piège à focus écrit à la main. Avant l'ouverture, conserver une référence vers l'élément déclencheur.
2. À l'ouverture, déplacer le focus dans la boîte de dialogue. Le motif « dialog » de l'APG indique que le focus se déplace vers un élément contenu dans la boîte de dialogue, généralement le premier élément focalisable ; pour une boîte de dialogue qui commence par un long texte, donner tabindex="-1" au titre et y placer le focus, afin que la personne lise avant d'agir.
3. À la fermeture, rendre le focus au déclencheur mémorisé. Le motif de l'APG note l'exception : si le déclencheur n'existe plus, le focus va vers un autre élément qui poursuit le flux de travail.
4. Changements de route : une fois la nouvelle vue rendue, définir document.title et déplacer le focus vers le titre principal de la vue (tabindex="-1") ou vers le repère main. Si le nœud précédemment focalisé a été remplacé pendant le rendu, le focus est déjà retombé sur body.
5. Éléments supprimés : quand un contrôle « supprimer » retire la ligne dans laquelle il se trouve, décider à l'avance où va le focus : le même contrôle sur la ligne suivante, la ligne précédente, ou le titre de la liste avec un message de statut.
6. Contenu révélé : pour les éléments repliables et les accordéons, garder le focus sur le déclencheur ; pour les flux étape par étape qui remplacent toute la vue, traiter la nouvelle étape comme un changement de route.
7. Garder l'anneau de focus visible : ne jamais retirer outline sans équivalent ; styler :focus-visible afin que les personnes utilisant le clavier voient où elles se trouvent.
8. Tester chaque flux au clavier seul, puis avec un lecteur d'écran, et noter ce qui est annoncé après chaque transition.

Résultat attendu

Après toute interaction, Tab atteint le contrôle suivant pertinent ; un lecteur d'écran annonce le nouveau contexte (titre de la boîte de dialogue, titre de la vue, ligne de statut) au lieu de « document ».

Limites et base de vérification

Les recommandations suivent le motif de l'APG et la documentation MDN cités ; aucune étude utilisateur n'est avancée. Les boîtes de dialogue personnalisées construites à partir d'éléments div ont besoin de leur propre gestion de l'inertie et d'Échap, que <dialog> fournit. L'endroit exact où le focus doit atterrir après un changement de route fait débat (titre contre repère contre simple annonce) ; choisir une convention et l'appliquer de façon cohérente.