Navigation au clavier : le test qui révèle le plus de défauts

Dix minutes, beaucoup de réponses

Ranger la souris et parcourir une page uniquement à la touche Tab est le test d'accessibilité le plus rentable qui soit. Il ne demande aucun outil, et met au jour des défauts structurels que les scans automatiques manquent presque tous.

Ce qu'il faut observer

• Le focus est-il visible ? À chaque tabulation, on doit voir où l'on est. Un outline: none sans remplacement est une non-conformité directe ;
• L'ordre est-il logique ? Il doit suivre l'ordre de lecture. Un ordre incohérent trahit souvent une mise en page CSS qui réordonne visuellement le DOM ;
• Peut-on tout atteindre ? Menus déroulants, carrousels, onglets, modales : tout élément actionnable à la souris doit l'être au clavier ;
• Peut-on toujours ressortir ? Une modale ou un lecteur vidéo qui capture le focus est un piège à clavier — critère bloquant ;
• Le lien d'évitement fonctionne-t-il ? « Aller au contenu » doit être le premier élément focusable et déplacer réellement le focus.

> Le symptôme du div cliquable — Un élément interactif construit en div avec un gestionnaire de clic est invisible au clavier. C'est la cause première des parcours impossibles à terminer — et elle se corrige en utilisant button ou a.

Pourquoi les scanners passent à côté

Un scanner analyse le DOM à un instant donné. Le clavier teste une séquence : l'ordre, la persistance du focus après une interaction, le retour en arrière. C'est du comportement, pas de la structure — d'où la part irréductible de test humain dans tout audit sérieux.

En faire une habitude d'équipe

Intégré à la recette avant chaque mise en production, ce test de dix minutes évite l'essentiel des régressions d'accessibilité. Il coûte moins cher que n'importe quelle correction après coup.

---

À lire aussi

• 106 critères RGAA : lesquels s'automatisent ?
• Audit d'accessibilité automatisé : scanner ou audit complet ?
• Contraste des couleurs RGAA : les ratios et les pièges