Un clic sur le web moderne dissimule une hypothèse : que la personne qui clique dispose d’une main, d’un poignet et d’un dispositif de pointage se déplaçant sur deux axes avec une précision sous-pixel et d’un bouton séparé et fiable pour l’appui. Supprimez l’un de ces éléments et l’interaction change. Pour quelqu’un qui pilote la page avec un eye-tracker, le « curseur » est un cône de regard d’un degré d’arc qui dérive et tremble. Pour quelqu’un utilisant un pointeur de tête, le curseur est le bout du nez suivi par une webcam, avec un pointage par maintien lent. Pour quelqu’un utilisant une interface de commutation par balayage simple, il n’y a pas de curseur du tout — seulement une surbrillance qui se déplace et se pose sur l’élément ayant le focus lorsque l’utilisateur appuie sur le commutateur. Chacune de ces modalités est utilisée aujourd’hui, en 2026, par une population assez large pour que « le web moderne » devrait la connaître. La majeure partie du web moderne ne la connaît pas.
Cet article est un primer conceptuel sur les trois modalités de saisie alternatives dont les utilisateurs handicapés moteurs dépendent le plus souvent — le suivi oculaire, le pointeur de tête et la commutation — et sur la façon dont la couche de standards (les critères de succès WCAG 2.2, la spécification W3C Pointer Events) s’articule avec les patterns d’interface utilisateur qui apparaissent effectivement en production. Le cadre rédactionnel est éditorial plutôt que judiciaire : il s’agit d’examiner ce qui fonctionne, ce qui ne fonctionne pas, et ce que les concepteurs peuvent cesser de faire dès demain.
Qui utilise ces saisies, et pourquoi
La population qui dépend de modalités de saisie alternatives n’est pas négligeable. Les estimations du Rapport mondial sur l’équité en santé pour les personnes handicapées de l’OMS (2022, avec la mise à jour de surveillance de 2024) et du Disability and Health Data System du CDC américain situent la part des adultes souffrant d’une déficience motrice significative des membres supérieurs à environ 8 % de la population adulte dans les pays à revenu élevé, et la part des adultes ne pouvant pas utiliser de manière fiable une souris ou un trackpad standard à environ 3-4 %. Dans ces 3-4 %, plusieurs groupes d’utilisateurs distincts préfèrent une modalité de saisie déterminée par leur physiologie plus que par leur préférence.
Le groupe le plus clair est celui des personnes atteintes de sclérose latérale amyotrophique (SLA), qui perdent progressivement le contrôle volontaire de leurs membres et, finalement, de leur musculature faciale. Le suivi du regard est, pour de nombreuses personnes à un stade avancé de SLA, le seul canal restant pour l’utilisation autonome d’un ordinateur. L’ALS Association estime qu’environ 30 000 personnes vivent avec la SLA aux États-Unis à un moment donné ; le registre européen de la SLA suggère une prévalence similaire ajustée à l’âge dans l’UE. Le deuxième groupe est celui des personnes souffrant d’une lésion médullaire de haut niveau — en particulier la tétraplégie C1-C4 — pour qui les mains et les bras sont indisponibles mais le mouvement oculaire et de la tête est préservé. Le troisième est celui des enfants et adultes atteints d’une infirmité motrice cérébrale, où la stratégie de saisie est très individuelle : certains utilisateurs disposent d’un contrôle digital suffisant pour une interface de commutation, d’autres utilisent un pointeur de tête, d’autres encore un joystick actionné au menton. Le quatrième est celui des personnes souffrant de maladies neuromusculaires progressives — dystrophie musculaire, sclérose en plaques aux stades avancés — qui passent souvent par plusieurs modalités de saisie au fil du temps.
Dans ces groupes, deux principes traversent la variabilité. Premièrement, presque tous ceux qui utilisent une saisie alternative le font parce que la combinaison souris-clavier standard est devenue physiquement impossible, non pas parce qu’ils préfèrent une modalité novatrice. Deuxièmement, la saisie est généralement à axe unique dans un sens fondamental : une fixation du regard unique, une direction de pointage de tête unique, un appui de commutateur unique. Les conceptions supposant deux canaux coordonnés — un pointeur plus une touche modificatrice, un mouvement de glissement plus une cible de dépose précise — s’effondrent le plus durement pour ce public.
Le matériel en 2026
Le paysage matériel a sensiblement évolué au cours des trois dernières années. Ce qui suit est une cartographie approximative de ce que les utilisateurs utilisent réellement, plutôt qu’un catalogue complet.
Eye-trackers
Tobii Dynavox reste le principal fournisseur clinique de suivi oculaire. La génération actuelle — le PCEye et la gamme I-Series — utilise une barre de capteurs infrarouges montée sous un moniteur ou intégrée dans une tablette dédiée, et communique la position du regard au système d’exploitation hôte comme un pointeur système. L’étalonnage prend environ 30 secondes ; la précision dans de bonnes conditions se situe autour de 0,5 à 1,0 degré d’arc visuel, ce qui correspond à un cône de regard d’environ 30 à 60 pixels à une distance de vision typique. EyeGaze Edge (LC Technologies) et EyeTech VT3 sont des alternatives cliniques. Du côté grand public, le Tobii Eye Tracker 5 est vendu principalement aux joueurs mais est largement utilisé comme dispositif d’accessibilité à faible coût.
2024 a vu apparaître le premier suivi oculaire grand public intégré à un appareil informatique de usage général : l’Apple Vision Pro est livré avec le suivi oculaire comme modalité de navigation principale, combiné à un geste de pincement pour la sélection. visionOS expose la position du regard aux fonctions d’accessibilité de sélection par maintien au niveau du système, et du point de vue du développeur, une fixation oculaire suivie d’un pincement est signalée comme un événement de clic standard. La population en situation de handicap a, de manière prévisible, adopté visionOS pour la même raison qu’elle avait adopté l’iPhone en 2008 : une modalité intégrée conçue pour un usage grand public qui se trouve également à servir le cas d’usage du handicap. Le prix de l’Apple Vision Pro le place hors de portée de nombreux utilisateurs, mais le précédent — le suivi oculaire comme saisie principale sur un ordinateur non médical — est celui qui compte.
Pointeurs de tête
Les logiciels de pointeur de tête utilisent généralement la webcam intégrée de l’appareil pour suivre un point fiduciel — souvent le bout du nez ou un petit autocollant réfléchissant placé sur le front de l’utilisateur — et traduisent la rotation de la tête en mouvement du curseur. Camera Mouse (Boston College, gratuit) est la mise en œuvre la plus ancienne et reste en usage actif. Glassouse propose un contrôleur gyroscopique portable monté sur la tête qui se couple au système d’exploitation comme une souris Bluetooth. macOS inclut Head Pointer comme fonction d’accessibilité intégrée ; Windows 11 dispose d’une fonctionnalité équivalente via Eye Control lorsqu’il est associé à du matériel compatible. La sélection sur un pointeur de tête est presque toujours basée sur le maintien : le curseur reste immobile sur une cible pendant un intervalle configurable — généralement 0,5 à 2,5 secondes — et un événement de clic se déclenche.
Commutation
La commutation est la plus simple et la plus variable des trois. Le matériel est un bouton unique — un grand commutateur mécanique rond, un tube sip-and-puff, un levier actionné au menton, une pédale de pied, une interface cerveau-ordinateur en phase de recherche avancée — câblé à une interface de commutation standardisée (une AbleNet Hook+, un Pretorian J-Pad, un bouclier Tecla) qui se présente au système d’exploitation comme une frappe USB ou Bluetooth. Le logiciel exécute alors une interface de balayage : un indicateur de focus se déplace automatiquement à travers les cibles disponibles sur l’écran, et l’utilisateur appuie sur le commutateur lorsque le focus se pose sur la cible souhaitée. La commutation simple utilise un seul bouton pour tout piloter ; la commutation double associe généralement un bouton à « avancer » et l’autre à « sélectionner ». iOS inclut Switch Control comme fonction d’accessibilité intégrée ; Android 14+ propose Switch Access ; macOS et Windows proposent tous deux une fonctionnalité comparable. La commutation est fondamentalement séquentielle — l’utilisateur ne peut pas pointer sur une cible ; il ne peut qu’attendre que le balayage l’atteigne — et ce fait détermine chacun des patterns de conception ci-dessous.
Comment ils rencontrent le web : la couche de standards
Du point de vue du navigateur, un eye-tracker et un pointeur de tête ressemblent tous deux à des dispositifs de pointage standard : ils émettent des événements pointermove, pointerdown et pointerup via la spécification W3C Pointer Events, la même API qu’utilise une souris ou un écran tactile. La commutation, en revanche, ressemble au navigateur comme une saisie clavier : le focus parcourt les éléments tabblables, et l’appui du commutateur déclenche un événement keydown pour Entrée ou Espace. Cette divergence est la première chose qu’un concepteur doit intégrer — les utilisateurs de suivi oculaire atteignent vos états :hover et vos gestionnaires d’événements de pointeur ; les utilisateurs de commutation ne rencontrent que vos éléments focalisables au clavier et l’ordre de focus que vous avez défini.
WCAG 2.2 contient plusieurs critères de succès écrits spécifiquement pour maintenir ces modalités de saisie fonctionnelles. Trois d’entre eux supportent l’essentiel de la charge.
SC 2.1.1 Clavier (Niveau A) est l’exigence fondamentale : chaque élément fonctionnel de la page doit être actionnable via une interface clavier seule. Les utilisateurs de commutation en dépendent absolument. Un élément qui ne répond qu’à un clic de souris — un div personnalisé avec un gestionnaire click sans tabindex, sans role, sans gestionnaire keydown — est invisible pour un utilisateur de commutation. Il est également invisible pour de nombreux utilisateurs de pointeur de tête qui reviennent à la navigation au clavier pour les sections de la page où le clic par maintien est trop lent.
SC 2.5.1 Gestes du pointeur (Niveau A) exige que toute fonction actionnée par un geste multi-points ou basé sur un chemin soit également actionnable par une action à pointeur unique. Ce critère existe parce que le suivi oculaire, le pointeur de tête et de nombreuses saisies alternatives ne peuvent pas effectuer de manière fiable des gestes multi-doigts ou des trajectoires de glissement précises. Un zoom par pincement sans bouton alternatif. Un glissement-pour-supprimer sans contrôle de suppression à l’écran. Une liste de réorganisation par glissement sans équivalent clavier. Chacun de ces éléments constitue un échec 2.5.1, et chacun prive l’utilisateur de la modalité qu’il possède réellement.
SC 2.5.2 Annulation du pointeur (Niveau A) exige que pour toute activation à pointeur unique, l’action ne s’exécute pas sur l’événement descendant (elle s’exécute sur l’événement montant à la place), ou s’exécute sur l’événement descendant mais permet à l’utilisateur d’annuler l’action en s’éloignant avant l’événement montant. Ce critère est écrit pour les utilisateurs qui atteignent une mauvaise cible avec un tremblement ou une dérive, et il est crucial pour les interfaces de maintien sur pointeur de tête et de suivi oculaire : un clic qui se déclenche au moment où le curseur se pose ne laisse à l’utilisateur aucune chance de récupérer d’une dérive du regard. Les boutons qui lient leur gestionnaire à mousedown plutôt qu’à click échouent à ce critère.
SC 2.5.7 Mouvements de glissement (ajouté dans WCAG 2.2) étend la protection des gestes au glissement-déposer spécifiquement : tout élément déplaçable doit être accessible via une alternative à pointeur unique, généralement un contrôle bouton déplacer-vers-le-haut/déplacer-vers-le-bas. SC 2.5.4 Actionnement par mouvement (Niveau A) protège les utilisateurs qui ne peuvent pas secouer ou incliner leur appareil de manière fiable. Et SC 2.2.1 Réglable dans le temps (Niveau A) et SC 2.2.2 Pause, Arrêt, Masquer (Niveau A) protègent tout le monde contre les interfaces dont le délai expire avant qu’une interface de balayage puisse atteindre le contrôle concerné.
Ces critères sont écrits comme un cadre unique et intégré : l’utilisateur ne dispose que d’un axe de saisie, la saisie est lente, et la conception ne doit pas supposer le contraire.
Défaillances courantes sur les sites en production
En comparant ces critères à ce que les sites en production livrent réellement, un ensemble récurrent de patterns d’échec émerge. Aucun n’est exotique. Tous apparaissent lors des tests utilisateurs de routine avec des eye-trackers, des pointeurs de tête et des utilisateurs de commutation.
Glissement-déposer sans alternative clavier. Pattern courant dans les outils de gestion de projet, les gestionnaires de fichiers et les interfaces de listes classées : déplacer une carte d’une colonne à une autre. Pour les utilisateurs de commutation, l’action est impossible — il n’y a pas de glissement dans le balayage. Pour les utilisateurs de pointeur de tête et de suivi oculaire, le glissement lui-même est environ 4 à 5 fois plus lent qu’une action déplacée par bouton et est généralement impossible à terminer sans lâcher l’élément en plein mouvement. La correction est directe : associer chaque glissement-déposer à une action de déplacement par bouton, exposée dans l’ordre de tabulation. Le pattern « déplacer la carte vers le haut / vers le bas / vers une autre liste » à la Trello est la mise en œuvre de référence.
Navigation sur survol uniquement. Menus déroulants, infobulles et contrôles de divulgation qui n’apparaissent qu’au :hover et disparaissent lorsque le curseur s’éloigne. Pour un utilisateur de suivi oculaire, le cône de regard dérive hors du déclencheur du menu dès qu’il essaie de regarder un sous-élément, et le menu se ferme avant qu’il ne l’atteigne. Le critère WCAG 2.2 qui gère cela est 1.4.13 Contenu au survol ou au focus (Niveau AA) : le contenu déclenché par survol doit être fermable, survolable (l’utilisateur peut y entrer sans le faire disparaître) et persistant. De nombreux menus en production échouent aux trois.
Petites cibles de clic. SC 2.5.8 Taille de la cible (Minimum) (Niveau AA, nouveau dans WCAG 2.2) exige que les cibles interactives mesurent au moins 24 × 24 pixels CSS, avec exceptions. Ce critère a été écrit pour les interfaces tactiles et pour les utilisateurs avec une précision de pointage réduite — suivi oculaire, pointeur de tête, tremblement des mains. Une icône de fermeture de 16 pixels dans le coin d’une fenêtre modale est, en pratique, quasi impossible à atteindre de manière fiable avec un eye-tracker. La correction est mécanique : agrandir les cibles, ou exposer la même action via un contrôle plus grand ailleurs dans l’interface.
Clics limités dans le temps. Carrousels qui avancent automatiquement toutes les 5 secondes, dialogues « vous avez 30 secondes pour confirmer », délais de session qui se déclenchent en pleine tâche. Pour un utilisateur de commutation naviguant dans une interface de balayage à un rythme de 1,5 seconde par cible, un délai de 30 secondes représente environ 20 cibles d’espace réel accessible — souvent insuffisant pour atteindre le bouton de confirmation. SC 2.2.1 Réglable dans le temps exige que tout délai soit extensible, ajustable ou fermable. La plupart des délais en production ne sont aucun de ces trois.
Confirmation par geste uniquement. Glisseurs de confirmation par balayage, confirmations sur tablette à signature, captchas exigeant de tracer un chemin. Chacun constitue un échec 2.5.1 s’il n’est pas associé à une alternative par bouton.
Action sur mousedown. Un bouton qui déclenche son gestionnaire sur mousedown plutôt que sur l’événement click standard ne laisse à l’utilisateur aucun moyen d’annuler un tir erroné. SC 2.5.2 Annulation du pointeur est le critère applicable ; la correction consiste à lier à click, ou à pointerup avec une vérification d’annulation explicite.
Contrôles personnalisés sans ARIA. Un <div> qui ressemble visuellement à un bouton mais qui manque de role=“button”, tabindex=“0”, et d’un gestionnaire keydown pour Entrée et Espace. Le contrôle est inaccessible par commutation et par recours au clavier. SC 4.1.2 Nom, Rôle, Valeur (Niveau A) est le critère applicable. La correction est l’élément natif <button> chaque fois que possible, et un pattern ARIA complet chaque fois que ce n’est pas le cas.
Patterns de conception qui fonctionnent
Les patterns qui résistent à un eye-tracker, un pointeur de tête et un balayage de commutation partagent un petit nombre de propriétés structurelles. Chacun est bien documenté dans le Guide des pratiques d’édition ARIA et dans les documents de compréhension WCAG 2.2, et chacun est utilisé en production de manière routinière sur des sites qui servent un public grand public sans que personne ne le remarque.
Éléments HTML natifs chaque fois que possible. La mesure d’accessibilité la plus fiable est d’utiliser <button>, <a>, <input>, <select> et <textarea> à leurs fins sémantiques. Les éléments natifs offrent la gestion clavier correcte, les rôles ARIA corrects, le comportement de focus correct, et la sémantique d’annulation du pointeur correcte, intégrés. La complexité de reconstruire l’un de ces éléments correctement avec un <div> personnalisé représente environ 10 fois le travail d’ingénierie pour un résultat presque toujours moins bon.
Indicateurs de focus visibles avec un contraste adéquat. Pour les utilisateurs de commutation, l’anneau de focus est le curseur. Un anneau bleu de 2 pixels avec un contraste de 4:1 par rapport à l’arrière-plan environnant est le minimum procédural (SC 2.4.7 Focus visible, Niveau AA, et SC 2.4.11 Focus non obscurci, nouveau dans WCAG 2.2). Les sites qui suppriment l’anneau de focus du navigateur par défaut sans le remplacer abandonnent les utilisateurs de commutation à la dérive.
Ordre de focus prévisible. Un balayage de commutation se déplace dans le DOM dans l’ordre source par défaut, modifié par tabindex. Un ordre de balayage qui saute à travers la page rend l’interface inutilisable. SC 2.4.3 Ordre du focus (Niveau A) est le critère ; l’implication pratique est que l’ordre visuel et l’ordre DOM doivent correspondre chaque fois que l’utilisateur effectue une séquence d’actions.
Zones d’activation généreuses. Le minimum de 24 pixels de SC 2.5.8 est le plancher, pas la cible. Bon nombre des systèmes de conception qui ont publié des patterns testés en accessibilité depuis 2022 — Adobe Spectrum, IBM Carbon, GOV.UK Design System, US Web Design System — utilisent par défaut des cibles tactiles de 44 pixels, ce qui fonctionne bien pour les utilisateurs à précision de pointage réduite sans empiéter sur la mise en page visuelle.
Flux de confirmation avec boutons explicites. Toute action destructive ou irréversible doit nécessiter un bouton de confirmation explicite — pas un balayage, pas un appui long, pas un « cliquer n’importe où pour fermer ». Le pattern fonctionne pour tout le monde et résiste à chaque saisie alternative.
Délais généreux, ou aucun du tout. Si un délai est requis pour des raisons de sécurité (banque, santé), l’utilisateur doit pouvoir l’étendre via une action à pointeur unique bien avant qu’il ne s’écoule. Le pattern consiste à afficher une invite « êtes-vous encore là ? » à 75 % du délai, avec un seul bouton large pour l’étendre.
Liens de navigation rapide et navigation par points de repère. Une interface de balayage qui doit traverser l’intégralité du menu de navigation, de la section héros et du bloc publicitaire avant d’atteindre le corps de l’article est inutilisable. Un lien « Aller au contenu » comme premier élément focalisable de la page est le minimum ; les régions de points de repère (<main>, <nav>, <aside>) permettent aux utilisateurs de commutation de naviguer structurellement plutôt que linéairement.
Respecter le paramètre prefers-reduced-motion de l’utilisateur. Les carrousels à avancement automatique et les arrière-plans constamment animés rendent impossible pour un eye-tracker de se stabiliser sur une cible stable. Les media queries CSS (@media (prefers-reduced-motion: reduce)) permettent à la même interface de servir l’utilisateur ayant besoin que le mouvement soit supprimé.
Ce que cela signifie pour les concepteurs, les ingénieurs et les équipes produit
L’ensemble des connaissances sur les modalités de saisie alternatives aboutit à un endroit qui devrait sembler familier à quiconque a lu les autres primers d’accessibilité de ce site. La technologie a mûri. Les standards ont mûri. Les populations d’utilisateurs sont bien caractérisées. Le travail restant concerne l’approvisionnement, la formation et l’habitude quotidienne de construire des interfaces qui ne supposent pas tacitement une saisie à deux axes, deux mains, avec une latence inférieure à la seconde.
Pour les concepteurs : prototyper avec le clavier. Si votre conception fonctionne sous une navigation par tabulation uniquement avec un anneau de focus visible, elle fonctionne pour un utilisateur de commutation ; si ce n’est pas le cas, le design visuel a dépassé le modèle d’interaction. Le précédent du regard-plus-pincement de l’Apple Vision Pro recadre la saisie alternative comme la base de conception plutôt que comme une correction. Les conceptions qui résistent au Vision Pro tendent à résister à Tobii.
Pour les ingénieurs : lier à click plutôt qu’à mousedown. Utiliser des éléments HTML natifs. Tester l’ordre de tabulation. Faire passer la page par un audit clavier seul avant de la mettre en production. La majorité des défaillances ci-dessus relève de la convention d’ingénierie plutôt que de la difficulté d’ingénierie.
Pour les équipes produit : inclure des utilisateurs de modalités de saisie alternatives dans les tests utilisateurs de routine. Les obstacles ci-dessus ne sont pas des cas limites ; ce sont des échecs routiniers qui apparaissent en 30 minutes de tests avec une barre Tobii ou un appareil iOS avec Switch Control activé. Le coût de l’inclusion de la modalité dans le plan de test est faible. Le coût de son exclusion se manifeste sous la forme des défaillances ci-dessus, déployées à l’échelle, pour une population dont les options sont déjà limitées.
Le web fonctionne lorsqu’il accepte que le clic ne soit pas le verbe universel. L’utilisatrice avec une barre Tobii montée sous son moniteur, l’utilisateur dont une webcam suit le bout du nez, l’utilisateur avec un seul commutateur mécanique câblé dans le coin d’un bureau — chacun d’eux effectue la même action qu’un utilisateur avec un trackpad. La couche de standards le reconnaît. Les patterns de conception ci-dessus l’honorent. Le travail consiste à continuer à construire comme si c’était vrai.
Pour en lire davantage sur Disability World, consultez les critères de succès WCAG 2.2, le bilan 2026 plus large, et notre couverture continue des technologies d’assistance.