Chapitre 14.3 — Le test clavier

⏱️ TL;DR — Le test le plus rentable de l’accessibilité tient en une phrase : lâche la souris et fais Tab. En quelques minutes, tu détectes une énorme part des problèmes réels — éléments inatteignables, focus invisible, ordre incohérent, pièges, actions non déclenchables. Aucun outil automatique ne remplace ce test, et il ne demande aucune installation. C’est le premier réflexe à ancrer.

🎯 Objectifs

Réaliser un test clavier complet sur une page.
Connaître la checklist des points à vérifier.
Interpréter ce que révèle (ou pas) un parcours au clavier.
Faire de ce test un réflexe systématique.

Pourquoi le clavier d’abord

La navigation clavier est le socle de l’accessibilité (Partie 4) : les utilisateurs de lecteurs d’écran, de contacteurs, de commande vocale ou simplement sans souris en dépendent. Et surtout, la plupart des bugs d’accessibilité se manifestent au clavier : un faux bouton n’est pas atteignable, une modale piège le focus, un menu ne s’ouvre pas. Un test clavier propre garantit déjà une grande partie de la conformité — bien plus qu’un score automatique.

Autre avantage : il est gratuit et immédiat. Pas d’outil, pas d’installation. Juste ton clavier.

Les touches à utiliser

Touche	Action attendue
Tab / Maj+Tab	Passer à l’élément interactif suivant / précédent
Entrée	Activer un lien, un bouton, soumettre un formulaire
Espace	Activer un bouton, cocher une case
Flèches	Se déplacer dans un composant (onglets, radios, menu, select)
Échap	Fermer une modale, un menu, un popover

La checklist du test clavier

Débranche (mentalement) la souris et parcours la page au clavier. Vérifie, dans l’ordre :

Tout est atteignable — chaque lien, bouton, champ, contrôle reçoit le focus via Tab. Rien d’interactif n’est sauté.
Le focus est visible — à chaque étape, tu vois où tu es (un contour net). Pas de focus invisible (2.4.7).
L’ordre est logique — la progression suit l’ordre visuel/lecture, sans sauts déroutants.
Rien ne piège — tu peux toujours sortir d’un composant au clavier (pas de piège, sauf modale volontaire dont Échap sort).
Tout est activable — les actions se déclenchent avec Entrée/Espace, pas seulement au clic souris.
Les composants répondent aux bonnes touches — flèches dans les onglets/menus, Échap ferme la modale, etc.
Pas de focusable caché — un élément hors écran ou masqué ne doit pas recevoir le focus (piège classique du menu fermé encore tabbable).

⚠️ Piège — Le focus invisible. Beaucoup de sites font outline: none pour l’esthétique et oublient de le remplacer : au clavier, on ne sait plus où on est, la page devient inutilisable. Si, en faisant Tab, tu perds la trace du focus ne serait-ce qu’une fois, c’est un bug bloquant à corriger.

Ce que le test clavier révèle (et pas)

Il révèle : les faux éléments interactifs, les focus invisibles, les ordres cassés, les pièges, les composants non pilotables au clavier. Il ne dit pas si les éléments sont correctement nommés/annoncés pour un lecteur d’écran (un bouton peut être focusable mais annoncé « bouton » sans libellé) — c’est le rôle du test au lecteur d’écran. Les deux tests sont complémentaires.

💡 Réflexe — Fais le test clavier avant de te réjouir d’un bon score automatique. Trente secondes de Tab en disent plus qu’un rapport de 40 lignes. Intègre-le à ta définition de « fini » : une feature n’est pas terminée tant qu’elle n’a pas été parcourue au clavier.

🧭 Sur A11yLearn — On déroule le parcours d’inscription d’A11yLearn au clavier : Tab dans chaque champ, focus visible partout, ordre logique, Entrée pour soumettre, et — pour la modale de confirmation — focus piégé dedans puis Échap qui la ferme et rend le focus au bouton déclencheur. Un bug apparaît : le lien « mot de passe oublié » est un <span> non focusable. On le passe en <a>, et le parcours devient net.

✏️ Exercices

Exercice 1 — Diagnostique au clavier. En faisant Tab sur une page, le focus « disparaît » quand il atteint le menu, puis réapparaît trois éléments plus loin. Que s’est-il probablement passé ?

✅ Solution

Deux hypothèses : soit les éléments du menu ont un focus invisible (outline: none sans remplacement) — le focus y est bien mais tu ne le vois pas ; soit ils ne sont pas focusables (faux boutons en <div>) et Tab les saute. On vérifie : si l’action se déclenche par Entrée quand on « ne voit rien », c’est un problème de focus visible ; si Tab ne s’y arrête jamais, c’est un problème d’élément non focusable. Les deux sont bloquants.

Exercice 2 — La modale piège. Une modale s’ouvre, mais Tab continue de parcourir la page derrière elle. Quel est le problème et le correctif attendu ?

✅ Solution

Le focus n’est pas piégé dans la modale : on peut tabuler vers le contenu de fond, ce qui n’a aucun sens et perd l’utilisateur. Correctif : piéger le focus dans la modale tant qu’elle est ouverte, rendre le reste inert, permettre Échap pour fermer, et rendre le focus au déclencheur à la fermeture (4.4 et le pattern modale en 10.2).

🧠 Quiz de révision

1. Quel est le geste de base du test clavier ?

Lâcher la souris et faire Tab (et Maj+Tab) pour parcourir toute la page, en activant avec Entrée/Espace et en fermant avec Échap. C’est gratuit, immédiat, et très révélateur.

2. Cite trois points de la checklist clavier.

Parmi : tout est atteignable, le focus est visible, l’ordre est logique, rien ne piège, tout est activable au clavier, les composants répondent aux bonnes touches, pas de focusable caché.

3. Que ne révèle PAS le test clavier ?

Il ne dit pas si les éléments sont correctement nommés/annoncés pour un lecteur d’écran (un bouton peut être focusable mais sans libellé accessible). C’est le rôle du test au lecteur d’écran, complémentaire.

4. Pourquoi le focus invisible est-il si grave ?

Parce qu’au clavier, si on ne voit pas où est le focus, on ne peut plus se repérer ni agir : la page devient inutilisable. C’est souvent causé par outline: none sans style de remplacement.

5. À quel moment faire ce test ?

Systématiquement, et avant de se fier à un score automatique — idéalement dans la définition de « fini » d’une feature. Trente secondes de Tab valent mieux qu’un long rapport automatique.

Chapitre suivant : Le test au lecteur d’écran — vérifier ce que le clavier ne dit pas : les noms, rôles et annonces.