Ressources · 57
Dialogues et clavier : tester le parcours du focus
Vérifier ouverture, déplacement, fermeture et retour au contexte dans les interfaces qui interrompent une tâche.
· 3 min
Ce que ce guide permet
- Choisir le bon composant
- Placer un focus compréhensible
- Permettre la fermeture
- Restituer le contexte
Contrôle express
- Une modale est-elle nécessaire ?
- Où arrive le focus à l’ouverture ?
- Le fond est-il réellement inerte ?
- La fermeture fonctionne-t-elle au clavier ?
- Où revient le focus si le déclencheur disparaît ?
Méthode pas à pas
- 01
Choisir l’interruption
Déterminez si l’information exige vraiment une modale ou peut rester dans la page. Distinguez dialogue modal, panneau et menu. Préférez les éléments natifs adaptés et vérifiez leur comportement ; un rôle ARIA ne crée pas automatiquement les interactions.
Livrable : choix et raison d’usage.
- 02
Nommer et ouvrir
Donnez au dialogue un nom accessible relié à un titre visible. Placez le focus dans un élément approprié : début du contenu structuré, champ utile ou action sûre selon la tâche. Le début ne doit pas disparaître hors écran.
Livrable : ouverture testée.
- 03
Parcourir au clavier
Selon le modèle W3C de dialogue modal, Tab et Maj+Tab restent dans le dialogue, et le contenu extérieur n’est pas interactif. Vérifiez focus visible, ordre logique et absence de piège dans les contrôles imbriqués.
Livrable : parcours avant et arrière.
- 04
Fermer et restituer
Prévoyez une fermeture visible et le comportement Échap attendu. Renvoyez le focus vers le déclencheur ou une étape logique lorsque celui-ci n’existe plus. Après une validation, l’utilisateur doit retrouver ce qui a changé et la suite possible.
Livrable : retour de focus et contexte.
- 05
Tester erreurs et espace
Ajoutez messages longs, champs invalides, clavier mobile et zoom. Le dialogue doit défiler sans cacher définitivement action et titre. Une erreur doit être retrouvable et compréhensible sans que toutes les valeurs soient perdues.
Livrable : cas limites sur écrans étroits.
- 06
Vérifier dans la page
Testez le composant intégré avec clavier et technologie d’assistance, pas seulement dans une démonstration isolée. Vérifiez absence de double ouverture et retour de focus après fermeture répétée. Un protocole local ne constitue pas à lui seul une certification WCAG.
Livrable : recette et limites connues.
Fiche de travail à réutiliser
À compléter avec vos observations autorisées. Ces champs constituent une trame de travail, pas des résultats observés.
| Champ | Information à consigner |
|---|---|
| Ouverture | Déclencheur, titre et focus initial |
| Parcours | Tab, Maj+Tab, fond inerte et focus visible |
| Fermeture | Échap, bouton et retour logique |
| Limites | Zoom, contenu long, erreurs et assistance testés |
Exemple d’application
Situation illustrative
Exemple fictif : une modale confirme la suppression d’une ligne et le bouton qui l’a ouverte disparaît.
Décision et preuve attendue
Après confirmation, le focus revient vers l’élément logique suivant ou le titre de la liste, avec un résultat annoncé et une suite visible.
Distinguer les mécanismes
| Mécanisme | Utilité | Point de vigilance |
|---|---|---|
| Dialogue modal | Interrompre pour une tâche délimitée | Fond inerte et focus contenu |
| Panneau non modal | Garder le contexte disponible | Circulation de focus cohérente |
| Section de page | Présenter une information continue | Souvent plus simple à consulter |
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Parcours clavier aboutis | Tâches réalisées sans pointeur | Corriger les blocages |
| Retours de focus corrects | Fermetures restituant un contexte utile | Traiter déclencheurs disparus |
| États limites testés | Zoom, erreurs et contenus longs | Documenter les manques |
Erreurs fréquentes
- Ajouter aria-modal sans rendre le fond inerte
- Faire disparaître le focus après fermeture
- Bloquer Échap sans issue claire
- Tester uniquement l’ouverture à la souris
Questions fréquentes
Le dialogue natif suffit-il ?
Il fournit des comportements utiles, mais nom, focus initial, contenu, erreurs et intégration doivent être testés.
Faut-il focaliser le premier bouton ?
Pas toujours. Le meilleur point dépend du contenu et de la tâche, notamment si une décision est irréversible.
Un test automatique valide-t-il le parcours ?
Il repère certains défauts, mais compréhension, ordre utile et restitution de contexte demandent une recette manuelle.
Références officielles
Références consultées le 2 octobre 2026. La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
Pour aller plus loin
