Checklist pour une navigation au clavier accessible
1. Principes fondamentaux de la navigation au clavier
Testez les parcours de votre site sans souris : ouvrir un menu, compléter un formulaire et fermer une fenêtre. Elle permet aux personnes utilisant des technologies d'assistance, comme les lecteurs d’écran, les contacteurs ou les claviers alternatifs, d'interagir pleinement avec les services en ligne sans utiliser de souris.
Les fonctionnalités doivent pouvoir s’utiliser au clavier, sauf lorsque la fonction dépend du tracé d’un mouvement, comme le dessin à main levée. Les commandes de base suivent les conventions du guide ARIA Authoring Practices Guide (APG) du W3C: la touche Tab avance le focus dans la séquence de tabulation, Shift + Tab recule le focus, la touche Entrée active liens et boutons, et la Barre d’espace active les boutons et cases à cocher. Les composants regroupés, comme les onglets ou menus, utilisent aussi les flèches selon le modèle choisi.
L'utilisation d'éléments HTML natifs tels que <button> ou <a href="..."> est préférable. Ces éléments gèrent nativement le focus et les événements clavier. Pour un composant personnalisé en JavaScript (par exemple un bouton sur un <div>), le développeur doit ajouter l'attribut tabindex="0" pour l'insérer dans l'ordre naturel du document définir le rôle et le nom accessibles, puis reproduire l’activation avec Entrée et Espace sans provoquer un défilement involontaire.
2. Ordre du focus et visibilité de l'indicateur
L'ordre de navigation doit respecter le flux logique et visuel de la page, généralement de gauche à droite et de haut en bas. Cet ordre est défini par la structure HTML (DOM). L'utilisation de valeurs positives de tabindex (supérieures à 0) doit être évitée, car elle altère la séquence naturelle et crée un comportement imprévisible.
Pour l'indicateur visuel de focus, les critères WCAG 2.1 et WCAG 2.2 fixent des règles précises. Le critère 2.4.7 (Focus visible) de niveau AA exige que l'indicateur soit nettement perceptible, sans imposer une règle universelle de contraste de 4.5:1 pour tout indicateur en WCAG 2.1 (le critère 1.4.11 prévoit 3:1 pour les informations visuelles nécessaires à l’identification des composants et états, avec des exceptions, notamment pour les composants inactifs et les styles du navigateur non modifiés). En WCAG 2.2, le critère 2.4.13 (Focus Appearance) définit des exigences plus strictes de surface et de contraste, mais se situe au niveau AAA. Il ne faut donc pas confondre la visibilité minimale du niveau AA avec le critère avancé AAA.
De plus, WCAG 2.2 introduit le critère 2.4.11 Focus Not Obscured (Minimum) au niveau AA. Ce critère exige qu'un composant focalisé ne soit pas totalement masqué par du contenu créé par l'auteur, comme un en-tête fixe, un pied de page fixe ou une bannière de cookies. Des réglages comme scroll-padding peuvent aider ; vérifiez le résultat avec vos en-têtes fixes et aux différents niveaux de zoom.
3. Fenêtres modales et prévention des pièges clavier
Un piège clavier (critère WCAG 2.1.2) survient lorsqu'un utilisateur amène le focus sur un composant mais ne peut plus en sortir avec les commandes clavier habituelles. Ces blocages apparaissent souvent dans des widgets complexes ou des scripts tiers mal conçus.
Lors de l'ouverture d'une fenêtre modale, la gestion du focus s'adapte au contexte d'interaction:
À l’ouverture, placez le focus sur un élément pertinent à l’intérieur : un contrôle ou un titre rendu focalisable avec tabindex="-1" selon le contenu. Ne choisissez pas systématiquement le premier bouton.
Tant que la modale est ouverte, gardez la tabulation à l’intérieur et prévoyez sa fermeture avec Échap et un bouton accessible. Ce confinement n’est pas un piège si l’utilisateur peut fermer la fenêtre.
À la fermeture, rendez le focus au déclencheur ou à l’étape suivante logique du parcours si le déclencheur a disparu ou si l’action le justifie.
Le modèle de dialogue modal du W3C décrit ces choix.
4. Une checklist de test sur vos parcours
Préparer le test
Choisissez des tâches réelles : accéder à une information, sélectionner une option et envoyer une demande. Notez le navigateur, le système et les pages examinées. Faites d’abord un passage au clavier sans lecteur d’écran, puis un passage distinct avec le lecteur d’écran pour contrôler les noms et états annoncés.
Atteignez chaque commande utile avec Tab ou les touches prévues pour le composant.
Vérifiez le retour avec Maj + Tab et l’absence de déplacement incohérent du focus.
Ouvrez menus et dialogues, sélectionnez une option et fermez-les.
Déclenchez une erreur de formulaire : trouvez le message et corrigez le champ.
Recommencez avec un en-tête fixe, une bannière ouverte et une page agrandie.
Pour chaque obstacle, décrivez l’action, le résultat attendu et ce que vous observez. Une capture et des étapes de reproduction aident le développeur à corriger le bon composant.
Exemple fictif
Dans un formulaire de réservation, le visiteur ouvre un calendrier mais ne peut pas en sortir. Le test doit couvrir la sélection d’une date, la fermeture et le retour au champ. Après correction, vérifiez aussi les autres pages qui utilisent ce calendrier. Cet exemple décrit un problème à tester, sans prétendre mesurer un gain de conversion.
5. Utiliser les outils sans remplacer les essais manuels
Axe, Lighthouse ou WAVE peuvent signaler certaines erreurs. Un rapport sans alerte ne prouve pas que le parcours fonctionne au clavier. Vérifiez les interactions et les annonces du lecteur d’écran. Intégrez les contrôles utiles à vos mises à jour et faites retester les corrections.
Choisissez le référentiel et son périmètre selon votre organisation. Notre guide d’accessibilité en Suisse distingue WCAG, eCH-0059 et obligations applicables. Attribuez dès maintenant un responsable à ces contrôles et réutilisez la checklist lors des nouveaux composants.