Quand on parle d’accessibilité au clavier, l’image qui vient spontanément est celle d’un utilisateur aveugle naviguant avec un lecteur d’écran. C’est une réalité, mais c’est une fraction de la réalité. La navigation au clavier concerne bien plus de personnes, dans bien plus de situations.
Comprendre qui navigue au clavier, et pourquoi, change la façon dont on aborde les tests d’accessibilité. Ce n’est plus une checklist technique, c’est une question de praticabilité réelle pour des personnes réelles.
Les quatre profils qui naviguent au clavier
1. Les utilisateurs de lecteurs d’écran
Ce sont les utilisateurs les plus visibles dans les discussions sur l’accessibilité. Personnes aveugles ou malvoyantes sévères, elles naviguent exclusivement au clavier couplé à un lecteur d’écran (NVDA, JAWS, VoiceOver). Pour elles, la souris n’existe pas, le pointeur n’a aucune signification quand on ne voit pas l’écran.
Ce que ça implique concrètement : chaque action qui nécessite un clic de souris doit avoir un équivalent clavier. Un bouton activable uniquement au survol de la souris est invisible pour cet utilisateur.
2. Les utilisateurs avec des limitations motrices
C’est le groupe le plus large et le moins souvent évoqué. Il inclut :
Les personnes atteintes de tremblements (Parkinson, sclérose en plaques, séquelles d’AVC). La souris exige une précision motrice que le tremblement rend aléatoire. Cliquer sur un bouton de 24×24 pixels devient une épreuve. Le clavier, lui, ne demande pas de précision spatiale.
Les personnes avec une mobilité réduite d’un bras ou d’une main. Fracture, amputation, paralysie partielle, naviguer avec une seule main est beaucoup plus simple au clavier qu’avec une souris qui demande les deux mains sur un ordinateur portable.
Les utilisateurs de commutateurs et de dispositifs alternatifs. Personnes tétraplégiques ou avec une motricité très limitée, elles utilisent des dispositifs qui simulent des frappes clavier : commutateurs activés par le souffle, le menton, les yeux. Ces dispositifs naviguent dans la page exactement comme un clavier en passant d’élément focusable en élément focusable.
Les utilisateurs de navigation vocale (Dragon NaturallySpeaking). Ils donnent des commandes vocales qui génèrent des clics et des frappes clavier. Si un élément n’a pas de nom accessible, la commande “cliquer Envoyer” ne trouve pas sa cible.
3. Les utilisateurs temporairement limités
C’est la catégorie la plus souvent sous-estimée parce qu’elle est invisible dans les statistiques d’accessibilité permanente.
Un développeur avec un poignet cassé. Une personne qui se remet d’une opération à l’épaule. Quelqu’un qui a renversé du café sur son trackpad. Un utilisateur de laptop en mode tablette dont l’écran tactile est défaillant.
Ces situations sont temporaires (quelques semaines, quelques mois), mais elles représentent une part significative du temps de vie de n’importe quel utilisateur. Et pendant ce temps, la navigation au clavier devient leur seule option.
4. Les utilisateurs par préférence et par efficacité
Les développeurs ou les personnes habituées aux raccourcis clavier. Pour eux, la souris est plus lente. Tab, Entrée, les flèches, les raccourcis, c’est une façon de travailler plus efficace sur certaines tâches.
Ce groupe teste involontairement l’accessibilité clavier de chaque application qu’il utilise. Quand un formulaire les oblige à prendre la souris pour sélectionner une option dans un composant custom, c’est un problème de productivité autant qu’un problème d’accessibilité.
Ce que ressent un utilisateur clavier sur un site mal fait
Pour rendre l’enjeu concret, voici trois scénarios du quotidien.
Scénario 1 : La démarche administrative en ligne
Marie, 67 ans, a une arthrite sévère aux mains. La souris lui fait mal après quelques minutes. Elle utilise le clavier pour tout.
Elle arrive sur le site de sa commune pour renouveler sa carte de stationnement. Le formulaire démarre bien, elle tabule de champ en champ, remplit son nom, son adresse. Puis elle arrive sur la liste déroulante du type de document. Le composant est custom, pas un <select> natif. Elle appuie sur Tab : le focus saute par-dessus la liste. Elle ne peut pas sélectionner son document.
Elle cherche un numéro de téléphone, appelle la mairie, attend 20 minutes. La démarche prévue pour être dématérialisée vient de lui coûter une demi-heure et une douleur aux mains.
Scénario 2 : La modale sans sortie
Thomas, 34 ans, développeur, utilise le clavier par habitude. Il navigue sur un site de formation continue pour s’inscrire à un module. Il appuie sur “En savoir plus”, une modale s’ouvre. Il lit le contenu, décide que c’est intéressant, cherche le bouton “Fermer” ou la touche Échap. Rien ne se passe. Son focus est coincé derrière la modale, il tabule et se retrouve sur des liens du fond de la page, invisibles derrière l’overlay.
Il ferme l’onglet et repart de zéro. L’inscription n’a pas eu lieu.
Scénario 3 : Le focus fantôme
Léa, 28 ans, malvoyante légère, utilise le zoom navigateur à 200% et navigue au clavier pour garder un oeil sur où elle en est. Elle remplit un formulaire de contact. Elle ne voit pas l’indicateur de focus (le site a ajouté la propriété outline: none sur tous les éléments pour des raisons esthétiques). Elle tabule mais ne sait pas où elle est dans la page.
Elle soumet le formulaire en croyant avoir rempli tous les champs. Une erreur s’affiche, mais sans indicateur de focus, elle ne sait pas sur quel champ se replacer. Elle abandonne le formulaire, pensant que ça ne fonctionne pas.
Le clavier comme test de robustesse
Il y a une règle empirique dans l’accessibilité : si un site fonctionne entièrement au clavier, il est accessible à la majorité des utilisateurs de technologies d’assistance (AT).
C’est parce que la navigation au clavier est le substrat commun de la plupart des technologies d’assistance. Les lecteurs d’écran naviguent au clavier. Les commutateurs simulent des touches clavier. La navigation vocale génère des clics et des frappes clavier. Si le clavier fonctionne, la base est là.
L’inverse est aussi vrai : un site inaccessible au clavier est inaccessible à l’ensemble de ces populations, indépendamment de l’ARIA qu’il utilise.
Le test de la main dans le dos
Une façon simple de tester la navigabilité au clavier : poser une main dans le dos, utiliser uniquement la touche Tab, Maj+Tab, Entrée, Espace, et les flèches. Naviguer sur le site comme si c’était la première fois.
Questions à se poser :
- Sait-on toujours où on est dans la page ? (focus visible)
- Peut-on atteindre tous les éléments interactifs ? (éléments focusables)
- L’ordre de visite est-il logique ? (ordre de tabulation)
- Peut-on sortir de tous les composants ? (pas de pièges clavier)
- Peut-on activer tous les contrôles ? (Entrée et Espace sur les boutons)
Si une de ces questions trouve une réponse négative, il y a une non-conformité à corriger.
Ce que le RGAA exige
Deux critères RGAA adressent directement la navigation au clavier.
Critère 7.3 : Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage ?
Ce critère couvre tous les composants interactifs construits avec JavaScript : menus déroulants, accordéons, onglets, modales, carrousels, formulaires dynamiques. Chacun doit être utilisable avec le seul clavier, sans exception.
Il ne suffit pas que le composant soit atteignable au clavier, il faut qu’il soit utilisable. Atteindre une liste déroulante custom avec Tab mais ne pas pouvoir sélectionner une option est une non-conformité sur 7.3.
Critère 12.8 : Dans chaque page web, l’ordre de tabulation est-il cohérent ?
L’ordre dans lequel Tab parcourt les éléments doit suivre une logique qui correspond à l’ordre de lecture visuel. Un focus qui saute du header au footer avant d’atteindre le contenu principal, à cause d’un tabindex positif mal placé ou d’un DOM dans le désordre, est une non-conformité sur 12.8.
Ces deux critères sont les plus fréquemment en échec. Non pas parce que les prestataires ignorent leur existence, mais parce que la navigation au clavier est rarement testée pendant le développement, et que les problèmes n’apparaissent qu’à l’usage.
Pour retenir
La navigation au clavier n’est pas une fonctionnalité pour une minorité d’utilisateurs exceptionnels. C’est un mode d’interaction légitime, utilisé quotidiennement par des millions de personnes, certaines par nécessité permanente, d’autres par nécessité temporaire, d’autres encore par préférence.
Tester au clavier avant de livrer un site n’est pas un effort supplémentaire, c’est une vérification de base, comme tester sur mobile. Elle prend cinq minutes sur une page représentative et révèle les problèmes les plus bloquants.
Les articles suivants de cette série couvrent les mécanismes techniques : comment fonctionne l’ordre de tabulation, comment identifier et corriger les pièges clavier, et comment concevoir un indicateur de focus qui soit à la fois visible et esthétique.