Faire le test sans toucher à la souris
Rechargez la page, posez la souris et utilisez uniquement le clavier. Commencez avec Tab pour avancer entre les éléments interactifs et Shift + Tab pour revenir en arrière.
Essayez ensuite d’activer les liens et boutons avec Entrée ou Espace lorsque cela correspond au composant. Testez les menus, listes déroulantes, formulaires, fenêtres modales et autres composants importants du site.
Le but n’est pas simplement de constater que le focus bouge. Il faut vérifier que toutes les fonctions importantes restent réellement accessibles.
Vérifier que le focus est visible
À chaque pression sur Tab, vous devez pouvoir identifier clairement quel élément possède le focus. Si le focus disparaît visuellement, l’utilisateur peut perdre sa position dans la page.
Le style de focus peut être une bordure, un contour, un changement de fond ou un autre signal suffisamment clair. Supprimer le contour par défaut sans fournir d’alternative visible est une erreur fréquente.
Testez aussi les contrastes du focus sur différents arrière-plans : un contour visible sur fond blanc peut devenir invisible dans un menu sombre.
Vérifier l’ordre de tabulation
L’ordre du focus doit rester logique. Quand vous appuyez sur Tab, le parcours devrait suivre une séquence compréhensible et préserver le sens de la page.
Si le focus saute du haut de la page directement au pied de page, revient ensuite au menu ou traverse des éléments invisibles, l’expérience devient difficile. Le problème est particulièrement visible lorsque l’ordre visuel a été fortement modifié en CSS sans tenir compte de l’ordre du DOM.
Notez chaque saut étrange et l’élément précédent. Cela facilite ensuite la correction.
Tester les menus de navigation
Ouvrez le menu principal uniquement au clavier. Vérifiez que chaque entrée peut être atteinte, que les sous-menus peuvent être ouverts et fermés et qu’il existe un moyen clair de continuer la navigation.
Sur mobile ou tablette, certains menus utilisent des boutons qui ne réagissent qu’au clic souris ou au toucher. Testez aussi ces boutons avec Entrée et Espace.
Si un menu disparaît lorsque le focus change, vérifiez qu’il reste utilisable sans imposer une précision impossible au clavier.
Tester les formulaires
Passez dans chaque champ avec Tab. Le focus doit suivre l’ordre attendu, et chaque champ doit avoir un nom ou label compréhensible.
Essayez les cases à cocher, boutons radio, listes et boutons d’envoi. Vérifiez que les messages d’erreur ne nécessitent pas de revenir à la souris pour comprendre ou corriger le problème.
Un formulaire peut être techniquement atteignable au clavier tout en restant pénible à utiliser si les labels sont absents ou si le focus repart au début après une erreur.
Tester les fenêtres modales
Ouvrez une modale, une bannière ou une fenêtre de consentement au clavier. Le focus doit arriver dans le composant au bon moment et l’utilisateur doit pouvoir atteindre les actions nécessaires.
Vérifiez surtout qu’il existe un moyen clavier de fermer la fenêtre lorsque cette fermeture est proposée. Une modale qui capture le focus sans sortie constitue un problème majeur.
Après fermeture, regardez où revient le focus. Dans beaucoup de cas, il doit revenir à l’élément qui a ouvert la modale ou à un endroit logique du parcours.
Rechercher les pièges clavier
Un piège clavier apparaît lorsque le focus entre dans une zone et qu’il devient impossible d’en sortir avec le clavier.
Testez les widgets complexes : carrousels, lecteurs vidéo, cartes interactives, éditeurs, calendriers, sélecteurs personnalisés ou intégrations tierces. Si une combinaison spéciale est nécessaire pour sortir, cette information doit être disponible pour l’utilisateur.
Ne considérez pas le test comme terminé dès que les pages simples fonctionnent. Les problèmes apparaissent souvent dans les composants les plus interactifs.
Vérifier les liens d’évitement
Sur les pages avec un en-tête ou menu très long, un lien permettant d’aller directement au contenu principal peut améliorer fortement la navigation.
Appuyez sur Tab immédiatement après le chargement de la page et vérifiez si un lien d’évitement existe lorsqu’il est pertinent. S’il apparaît uniquement au focus, assurez-vous qu’il est visible et utilisable.
Tester plusieurs pages et gabarits
Ne testez pas uniquement la page d’accueil. Choisissez plusieurs gabarits : article, fiche produit, formulaire, page de contact, résultats de recherche, compte utilisateur ou tunnel de conversion.
Les composants réutilisés peuvent partager les mêmes défauts, mais certaines pages introduisent des widgets spécifiques qui créent leurs propres problèmes.
Documenter les anomalies
Pour chaque problème, notez l’URL, l’élément concerné, l’action clavier effectuée, le résultat obtenu et le résultat attendu.
Une capture vidéo courte peut être utile pour montrer un focus invisible ou un piège clavier. Le développeur peut ainsi reproduire précisément le comportement.
Corriger sans casser les comportements natifs
Lorsque cela est possible, privilégiez les éléments HTML natifs adaptés à la fonction : bouton pour une action, lien pour une navigation, champ de formulaire pour une saisie.
Les composants personnalisés demandent souvent davantage de gestion clavier. Si vous utilisez des rôles ARIA, ils ne remplacent pas automatiquement les interactions que l’élément doit offrir.
Ce que ce test ne prouve pas
Un site utilisable au clavier peut encore présenter de nombreux autres problèmes d’accessibilité : contrastes, alternatives textuelles, structure des headings, labels, erreurs de formulaire, contenus dynamiques ou compatibilité avec les lecteurs d’écran.
Ce contrôle n’est donc ni une certification ni un audit WCAG exhaustif. Il répond à une question précise : peut-on parcourir et utiliser les fonctions essentielles du site sans souris, avec un focus logique et sans piège clavier ?
Sources officielles
Continuer à comprendre votre visibilité
Pour approfondir ce sujet avec des contrôles directement liés :
Accessibilité du site Audit SEO SEO on-page Performance technique