Imaginez un visiteur qui ouvre le site d’un studio et passe de l’accueil aux services, puis aux coordonnées, sans toucher à la souris. Sait-il où il se trouve ? Peut-il ouvrir la rubrique dont il a besoin ? Ce petit parcours révèle si la navigation fonctionne comme un outil utilisable, au-delà de son apparence sur une maquette. Le principe central des recommandations du W3C WAI sur le clavier est simple : les fonctionnalités de l’interface doivent être disponibles au clavier.
Commencez par une structure claire
Pour une navigation ordinaire, utilisez des liens regroupés en listes dans un élément nav, comme le décrit le tutoriel WAI sur la structure des menus. Un lien mène à une page ; un bouton ouvre ou ferme un sous-menu. Si « Services » possède à la fois une page de présentation et des sous-rubriques, séparez ces actions. Le composant devient facile à expliquer avant le développement : le libellé ouvre la présentation, tandis qu’un bouton voisin révèle d’autres choix.
Planifiez l’ordre de navigation
La touche Tab doit suivre un parcours compréhensible, et Maj + Tab revenir en arrière. Les recommandations WAI sur l’ordre du focus insistent sur la préservation du sens et de l’utilisation. Tracez ce parcours sur la maquette : logo, liens principaux, bouton de demande, puis commande suivante de la page. Si le focus saute de façon inattendue entre des zones éloignées, examinez l’ordre des éléments dans le code, pas seulement leur disposition visuelle. Convenez de l’ordre souhaité avant d’ajouter des animations.
Rendez le focus facile à voir
Le focus identifie l’élément qui recevra la prochaine action au clavier. Les recommandations sur la visibilité du focus expliquent que l’indicateur doit rester visible pendant son affichage. Ne supprimez pas le contour par défaut sans remplacement clair. Le tutoriel WAI sur le style des menus traite le focus et la page courante comme deux états différents. Concevez-les ensemble : un soulignement peut identifier la rubrique actuelle, tandis qu’un contour distinct marque la position au clavier.
Ouvrez les sous-menus de manière délibérée
Le survol ne doit pas être le seul moyen de révéler les liens imbriqués. Les recommandations WAI sur les menus déroulants abordent l’utilisation au clavier et la communication de l’état ouvert avec aria-expanded. Une navigation ordinaire n’exige pas automatiquement le rôle menu. Dans l’exemple WAI de navigation à sections dépliables, Entrée et Espace activent les boutons ; Échap ferme une liste déroulante et rend le focus à son bouton. Testez ce modèle d’interaction dans votre réalisation plutôt que de considérer l’exemple comme du code prêt pour la production.
Parcourez une situation réelle
- Ouvrez l’accueil et mettez la souris de côté. Utilisez Tab pour trouver le premier élément de navigation.
- Atteignez « Services », ouvrez son sous-menu et choisissez une page. Refaites le parcours en sens inverse.
- Fermez et rouvrez le sous-menu. Vérifiez où le focus apparaît après chaque action.
- Recommencez dans une fenêtre étroite et avec le zoom de page. Laissez visibles les notifications et panneaux fixes existants.
Vérifiez séparément les superpositions de contenu : WAI met en garde contre le masquage complet du composant ayant le focus par le contenu de la page. Les utilisateurs doivent aussi pouvoir quitter un composant au clavier. Un menu ordinaire ne doit pas les retenir dans une boucle interne.
Consignez le comportement, pas les impressions
Un signalement utile comprend l’URL de la page, le navigateur, la largeur de fenêtre, les touches utilisées et le résultat attendu. Au lieu de « le menu est peu pratique », écrivez : « La fermeture du sous-menu fait perdre le focus visible ; la prochaine pression sur Tab recommence le parcours. » Cette précision facilite un nouveau test. Ce bref exercice peut révéler des problèmes de navigation, mais ne remplace pas une évaluation complète de l’accessibilité et ne démontre pas la conformité WCAG.