Tester un dialogue d’adresse au clavier
Un exemple détaillé couvre l’ordre du focus, l’annulation et l’enregistrement d’une adresse pour rendre les défauts clavier reproductibles.
Une boîte de dialogue d’adresse de livraison doit être entièrement utilisable au clavier. Testez tout le parcours, de son ouverture au retour sur la page. Atteindre le bouton d’enregistrement ne suffit pas.
L’exemple est fictif : l’adresse D-17 du portail client est « Hafenweg 8 ». La personne souhaite remplacer le numéro par 10. Le dialogue contient les champs rue et numéro, puis « Annuler » et « Enregistrer l’adresse ». Il s’agit d’un test fonctionnel manuel, pas d’une évaluation complète de l’accessibilité.
Décrire le défaut comme un parcours
Dans l’état initial supposé, le dialogue s’ouvre mais le focus reste sur « Modifier l’adresse de livraison », derrière la zone assombrie. Tab atteint ensuite les liens du pied de page. Les champs d’adresse visibles sont sautés. Un test à la souris aurait facilement manqué ce défaut.
Consignez la page de départ, le déclencheur, les touches utilisées et l’élément réellement focalisé. L’équipe de développement pourra reproduire le problème. Utilisez un environnement sûr avec des données de test ; ne modifiez pas une véritable adresse client pour essayer.
Définir le comportement attendu
Pour ce dialogue court, le champ Rue est un premier emplacement de focus pertinent. Un dialogue long ou aux conséquences importantes peut demander un autre choix. Le modèle WAI explique ces différences.
Action | Résultat attendu dans l’exemple |
|---|---|
Atteindre le déclencheur avec Tab, puis Entrée | Le dialogue s’ouvre ; le focus est visible dans Rue. |
Avancer avec Tab | Rue, numéro, Annuler, Enregistrer l’adresse ; puis Rue à nouveau. |
Reculer avec Shift+Tab | Les mêmes commandes en sens inverse ; aucun passage derrière le dialogue. |
Saisir 10 puis utiliser Escape avant d’enregistrer | Le dialogue se ferme ; le focus revient au déclencheur ; D-17 reste Hafenweg 8. |
Rouvrir et enregistrer 10 | Le succès apparaît après confirmation de l’enregistrement ; D-17 affiche Hafenweg 10. |
Enregistrement refusé par les règles métier | Erreur compréhensible ; saisies conservées ; zone concernée accessible. |
Cet ordre de tabulation correspond à cet exemple précis. Votre interface peut contenir d’autres commandes.
Corriger la cause au bon endroit
Utilisez de vrais boutons pour les actions et des champs correctement nommés. Un dialogue personnalisé exige un nom accessible et une gestion correcte du focus. role="dialog" ou aria-modal="true" ne bloque pas à lui seul l’arrière-plan et n’ajoute pas l’interaction clavier.
Ouverture, maintien du focus dans le dialogue modal actif et fermeture doivent être traités ensemble. Ici, le déclencheur existe encore à la fermeture. Si un autre parcours le supprime, un autre point de retour logique est nécessaire. Les styles ne doivent pas supprimer l’indicateur de focus visible.
Tester la fermeture pendant l’enregistrement
Escape ne rappelle pas automatiquement une requête déjà envoyée au serveur. Dans cet exemple, la fenêtre peut aussi se fermer pendant le traitement. La page continue d’afficher « Modification de l’adresse en cours » pour D-17. Une réponse confirmée met l’adresse à jour ; un résultat incertain reste à clarifier. « Modification abandonnée » serait alors incorrect.
Répétez le test corrigé dans les navigateurs pris en charge et avec une configuration de lecteur d’écran adaptée. Consignez observations et défauts ouverts. Le parcours clavier corrigé ne démontre encore rien sur toutes les autres pages, les contrastes ou les contenus.
Sources
Écrit par
- Julia HoffmannRédactrice design et UXJulia Hoffmann est responsable chez ASES des contenus éditoriaux consacrés au design et à l’expérience utilisateur. Ses articles portent sur l’utilisation des sites web et des applications, la conception d’interfaces utilisateur et l’accessibilité numérique.
À lire aussi
Tous les articles
Design & UX avec ASES
Expérience utilisateur, interfaces et image de marque