Naviguer au clavier : tester et corriger

Il existe un test d’accessibilité qui ne demande ni outil, ni formation spécialisée, ni budget : poser la souris, et essayer d’accomplir une démarche avec le seul clavier. En quelques minutes, il révèle des défauts que les outils automatiques ne voient pas. La navigation au clavier est la condition d’accès pour de nombreux utilisateurs, et c’est aussi un excellent indicateur de la qualité générale d’un site.

Pourquoi le clavier compte

Les personnes qui ne peuvent pas manipuler une souris, en raison d’un tremblement, d’une paralysie ou d’une amputation, utilisent le clavier ou des dispositifs qui l’émulent : contacteurs, commande à la tête, logiciels de commande vocale. Les personnes aveugles qui utilisent un lecteur d’écran naviguent elles aussi au clavier. Un site qui ne fonctionne pas au clavier leur est simplement fermé.

Les WCAG, référence internationale de l’accessibilité du web, consacrent plusieurs critères à ce sujet. Les principaux, au niveau A et AA :

En France, le RGAA reprend ces exigences dans sa thématique consacrée à la navigation ; la norme européenne EN 301 549 les rend applicables aux services soumis aux directives sur l’accessibilité.

Le test en dix minutes

Choisir un parcours réel, complet et important : une prise de rendez-vous, une demande d’acte, un achat, un formulaire de contact. Puis le suivre du début à la fin avec les seules touches suivantes : Tab pour avancer, Maj + Tab pour reculer, Entrée pour activer un lien ou un bouton, Espace pour cocher une case ou activer un bouton, les flèches pour se déplacer dans un groupe de boutons radio, une liste ou un menu, Échap pour fermer une fenêtre ou un menu.

1. Au chargement, appuyer sur Tab. Le premier élément atteint devrait être un lien d’évitement (« Aller au contenu ») qui permet de sauter le menu. Il peut n’apparaître qu’au focus.
2. Suivre le focus. À chaque pression, savoir exactement quel élément est sélectionné. Si le focus disparaît, même brièvement, c’est un défaut.
3. Vérifier l’ordre. Le focus doit suivre l’ordre logique de lecture : de haut en bas, de gauche à droite dans les langues qui se lisent ainsi. Un saut du pied de page vers le haut du formulaire signale un problème.
4. Ouvrir et fermer les menus. Les sous-menus doivent s’ouvrir au clavier, se parcourir et se fermer avec Échap, sans renvoyer le focus au début de la page.
5. Utiliser chaque contrôle du formulaire. Champs, listes déroulantes, cases, boutons radio, sélecteurs de date, téléversement de fichier.
6. Ouvrir une fenêtre modale. Le focus doit y entrer, y rester tant qu’elle est ouverte, et revenir sur l’élément qui l’a ouverte à sa fermeture.
7. Provoquer une erreur. Soumettre le formulaire incomplet : le message d’erreur doit être atteignable et, idéalement, le focus doit se placer sur le premier champ en erreur ou sur le résumé des erreurs.
8. Aller jusqu’au bout. Valider, payer, confirmer. Un parcours qui fonctionne à 90 % au clavier ne fonctionne pas.

Noter chaque difficulté avec l’endroit précis où elle survient. Refaire le test sur mobile avec un clavier externe permet de repérer des défauts propres aux versions mobiles.

Les défauts les plus fréquents, et leur correction

Le focus invisible. Le défaut le plus courant vient d’une règle de style qui supprime le contour de focus du navigateur pour des raisons esthétiques, souvent outline: none, sans le remplacer. La correction consiste à définir un indicateur de focus visible et contrasté sur tous les éléments interactifs, par exemple avec la pseudo-classe :focus-visible, qui l’affiche lors de la navigation au clavier sans le montrer à chaque clic. L’indicateur doit rester visible sur tous les fonds du site.

Les faux boutons. Un élément div ou span rendu cliquable par un script n’est ni atteignable au clavier ni annoncé comme un bouton par les lecteurs d’écran. La meilleure correction est d’utiliser l’élément natif : button pour une action, a avec une adresse pour une navigation. Les éléments natifs gèrent gratuitement le focus, l’activation au clavier et l’annonce aux technologies d’assistance.

L’ordre incohérent. Il vient souvent d’un ordre visuel obtenu par la mise en page (positionnement, grilles réordonnées) qui ne correspond pas à l’ordre du code, ou de l’usage d’attributs tabindex positifs. La correction consiste à aligner l’ordre du code source sur l’ordre visuel et à proscrire les valeurs positives de tabindex.

Les pièges. Un lecteur vidéo, une carte interactive ou un composant tiers qui capture le focus et ne le rend pas. La correction dépend du composant ; s’il s’agit d’un composant tiers, l’exigence doit être portée auprès du fournisseur, et à défaut le composant remplacé.

Les fenêtres modales mal gérées. Le focus reste derrière la fenêtre, ou s’en échappe vers la page en arrière-plan. L’élément HTML dialog, désormais pris en charge par les navigateurs courants, gère une bonne partie de ce comportement lorsqu’il est ouvert en mode modal ; à défaut, les modèles documentés par le W3C dans son guide des pratiques ARIA décrivent le comportement attendu.

Les menus au survol. Des sous-menus qui ne s’ouvrent qu’au passage de la souris. Il faut un bouton qui les ouvre et les ferme, avec un état annoncé (ouvert ou fermé).

Le focus masqué par un bandeau fixe. Un en-tête ou un bandeau de cookies fixé en bas de l’écran recouvre l’élément qui a le focus. Le critère 2.4.11 des WCAG 2.2 vise précisément ce cas ; une marge de défilement adaptée (scroll-padding) règle souvent le problème.

Prévenir plutôt que corriger

La plupart de ces défauts naissent au moment de la conception des composants. Trois habitudes les évitent à la source.

• Utiliser les éléments HTML natifs chaque fois qu’ils existent, et ne recourir à des composants personnalisés que lorsqu’aucun élément natif ne convient
• Définir l’indicateur de focus dans la charte graphique, au même titre que les couleurs et les typographies
• Faire passer le test clavier à chaque nouveau composant de la bibliothèque, et à chaque nouveau parcours avant sa mise en ligne
• Exiger ce test dans la recette des développements confiés à des prestataires
• Pour les composants tiers (cartes, lecteurs, outils de prise de rendez-vous), vérifier le comportement au clavier avant de les choisir

Le test clavier ne remplace pas un audit complet : il ne dit rien des contrastes, des alternatives aux images ou de la compréhension des contenus. Mais il est rapide, reproductible et parlant, ce qui en fait un excellent rituel d’équipe. Notre dossier sur l’accessibilité numérique replace ce test dans une démarche d’ensemble, et notre expertise web accessible accompagne les équipes qui veulent l’installer dans leur cycle de développement.

Questions fréquentes

Qui navigue au clavier ?

Des personnes qui ne peuvent pas utiliser une souris en raison d'un handicap moteur, des personnes aveugles qui utilisent un lecteur d'écran, des utilisateurs de dispositifs de commande alternatifs qui émulent le clavier, et beaucoup d'utilisateurs expérimentés qui vont plus vite ainsi. Un site utilisable au clavier sert tout ce public.

Peut-on supprimer le contour de focus pour des raisons esthétiques ?

Non, sauf à le remplacer par un indicateur au moins aussi visible. Supprimer le contour sans alternative rend le site inutilisable pour les personnes qui naviguent au clavier. Les WCAG 2.2 ont d'ailleurs renforcé les exigences sur la visibilité du focus.

Les outils automatiques détectent-ils les problèmes de clavier ?

Très partiellement. Ils peuvent repérer certains éléments interactifs mal codés, mais pas un ordre de navigation incohérent, un piège dans une fenêtre modale ou un focus invisible sur un fond particulier. Le test manuel reste indispensable.