Mobilité réduite : concevoir au-delà de la souris et du clavier

Quand on conçoit pour l'accessibilité motrice, on pense au clavier. C'est un bon début et c'est très insuffisant.

Une partie des utilisateurs ne tape pas sur un clavier. Ils dictent des commandes à un logiciel de reconnaissance vocale, actionnent un contacteur unique qui parcourt la page élément par élément, ou pilotent un curseur du regard. Ces modes d'entrée ont chacun leurs exigences, et le référentiel français n'en couvre qu'une partie. Cet article fait le tri : ce que le RGAA 4.1.2 impose déjà, ce qu'il ne dit pas, et comment concevoir pour ces usages sans attendre la prochaine version du référentiel.

---

Avec quoi ces utilisateurs naviguent réellement

Quatre familles de dispositifs, qui n'ont pas les mêmes contraintes.

La reconnaissance vocale. L'utilisateur prononce des commandes : « tabulation », « défiler vers le bas », « cliquer sur Ajouter au panier ». Le logiciel s'appuie sur le texte visible des commandes pour les identifier.

Le contacteur. Un ou deux boutons physiques, actionnés par la main, la tête ou le souffle. Le système balaie les éléments interactifs les uns après les autres, et l'utilisateur valide quand le bon est atteint. Chaque élément focusable superflu allonge le balayage.

Le suivi oculaire. Le curseur suit le regard, la validation se fait par fixation prolongée ou par clignement. La précision est limitée : viser une cible de 16 pixels relève de l'exploit.

Les dispositifs adaptés et les réglages système. Souris ergonomiques, claviers surdimensionnés, touches rémanentes, touches filtres. Ils réduisent la difficulté sans la supprimer.

Ces quatre modes ont un point commun : chaque interaction coûte du temps et de l'effort. Une page qui demande trente tabulations pour atteindre le contenu principal n'est pas seulement pénible, elle est disqualifiante.

---

Ce que le RGAA 4.1.2 couvre déjà

Le référentiel français n'est pas muet sur le sujet. Cinq critères portent directement la charge.

Le critère 7.3 est le pivot, et sa formulation mérite d'être lue en entier : « Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage ? » Ce n'est pas un critère « clavier ». Il couvre explicitement les dispositifs de pointage alternatifs, donc le suivi oculaire et les pointeurs adaptés.

Le critère 6.1 est celui qu'on sous-estime le plus. Trois liens « En savoir plus » dans une page passent souvent en audit parce que le contexte les désambiguïse pour un lecteur d'écran. Pour un utilisateur de commande vocale, ils sont indistinguables : « cliquer sur En savoir plus » ne désigne rien. Notre article sur l'intitulé de lien accessible détaille où passe exactement la frontière du critère.

Deux autres critères comptent, moins évidents. Le 13.1 donne à l'utilisateur le contrôle des limites de temps : quand chaque saisie prend trois fois plus longtemps, une session qui expire est une porte fermée, sujet que nous traitons dans l'expiration de session comme barrière d'accessibilité. Le 11.12 impose que les données d'un formulaire à conséquence puissent être modifiées ou récupérées : c'est le filet de sécurité de ceux dont le taux d'erreur de saisie est structurellement plus élevé.

---

Les trois angles morts du référentiel français

Le RGAA 4.1.2 est adossé aux WCAG 2.1. Or les WCAG 2.2 ont ajouté trois exigences qui visent précisément la motricité. Aucune n'est donc opposable en audit RGAA aujourd'hui.

Taille de cible minimale (WCAG 2.5.8, niveau AA). Le critère demande 24 par 24 pixels CSS au minimum, sauf exceptions. C'est la contrainte numéro un du suivi oculaire et du pointeur adapté. Un bouton de 16 pixels est conforme au RGAA et difficilement atteignable au regard.

Alternative au glisser-déposer (WCAG 2.5.7, niveau AA). Toute fonction reposant sur un glissement doit avoir une alternative en simple pointage. Réordonner une liste par glisser-déposer, sans boutons « monter » et « descendre », exclut une part des utilisateurs. GitHub propose par exemple des commandes « déplacer en haut » et « déplacer en bas » en complément du glissement.

Aide cohérente (WCAG 3.2.6, niveau A). Les mécanismes d'aide doivent apparaître au même endroit d'une page à l'autre. Un utilisateur qui met vingt secondes à traverser une page ne peut pas se permettre de chercher le lien de contact ailleurs à chaque fois.

Ces trois exigences arriveront vraisemblablement avec le RGAA v5. Rien n'oblige à les attendre : elles sont documentées, stables depuis la recommandation W3C des WCAG 2.2 du 12 décembre 2024, et leur coût d'implémentation est faible comparé à leur effet.

---

Cinq décisions de conception qui changent tout

Ce sont les points où l'écart entre « conforme » et « utilisable » se joue vraiment.

1. Réduisez le nombre d'éléments focusables. Chaque élément supplémentaire allonge le balayage au contacteur. Un méga-menu de soixante liens dans l'en-tête coûte une minute à traverser. Regroupez, repliez, et posez un lien d'évitement.
2. Rendez chaque intitulé visible et unique. Pas pour le référencement, pour la commande vocale. « En savoir plus sur la garantie » plutôt que « En savoir plus ».
3. Doublez tout geste par un contrôle simple. Glisser, pincer, balayer : chacun de ces gestes doit avoir un équivalent bouton. Le critère RGAA 7.3 l'impose déjà pour les scripts, les WCAG 2.2 le généralisent.
4. Espacez et agrandissez les zones cliquables. Visez 24 pixels de côté au minimum, davantage sur mobile. Deux cibles collées provoquent des activations accidentelles, coûteuses quand l'annulation est difficile.
5. Rendez les erreurs réversibles. Confirmation avant une action destructrice, annulation après, sauvegarde intermédiaire des formulaires longs. Le critère 11.12 le demande pour les formulaires à conséquence ; étendez-le au reste par principe.

---

Comment tester sans matériel spécialisé

Trois vérifications réalisables sur un poste ordinaire.

Au clavier seul, traversez un parcours complet, de l'accueil à la validation. Comptez les tabulations nécessaires pour atteindre le contenu principal. Au-delà d'une dizaine, il manque un lien d'évitement. Vérifiez que le focus reste visible partout, ce que détaille notre article sur les indicateurs de focus, et qu'aucun composant ne retient le focus.

À la commande vocale, activez le contrôle vocal intégré (Dictée vocale sur Windows, Contrôle vocal sur macOS et iOS) et tentez d'activer cinq liens en prononçant leur intitulé. Chaque hésitation du logiciel signale un intitulé ambigu.

À la souris seule, sans clavier, essayez de tout faire au pointeur, puis inversez. Un site qui exige les deux à un moment quelconque du parcours a un problème que le critère 7.3 sanctionne.

---

Conclusion

L'accessibilité motrice ne se résume pas à « ça marche au clavier ». Le RGAA 4.1.2 pose de bonnes fondations avec les critères 7.3, 12.8, 12.9, 10.7 et 6.1, et laisse trois angles morts que les WCAG 2.2 ont comblés sans que le référentiel français les ait encore repris.

La conclusion pratique tient en une phrase : traitez la taille des cibles, l'alternative au glisser-déposer et la cohérence de l'aide comme des exigences, même si aucun audit ne vous les réclamera cette année.

Pour situer votre page sur les critères déjà opposables (focus, ordre de tabulation, intitulés de liens, contrôle par script), lancez une analyse : le scan remonte les anomalies structurelles et vous laisse la liste de ce qui demande un test humain.