WCAG 2.5.6 : Mécanismes d’entrée simultanés

Ce que signifie cette règle

\n

WCAG 2.5.6 — Mécanismes d’entrée simultanés est un critère de succès de niveau AAA dans WCAG 2.2. Son exigence centrale est simple : le contenu web ne doit pas restreindre ni interférer avec la capacité de l’utilisateur à utiliser plusieurs mécanismes d’entrée simultanément ou de manière interchangeable. En pratique, cela signifie qu’une page web ou une application ne peut pas détecter de manière programmatique quel dispositif d’entrée l’utilisateur utilise actuellement, puis l’enfermer dans cette seule modalité en lui refusant l’accès aux autres méthodes d’entrée disponibles.

\n

Les appareils modernes prennent en charge une grande variété de mécanismes d’entrée : claviers physiques, souris et pavés tactiles, écrans tactiles, stylets, commandes par contacteur, saisie vocale, suivi oculaire, et plus encore. De nombreux utilisateurs s’appuient sur plus d’un de ces mécanismes en même temps — par exemple, un utilisateur d’ordinateur portable avec écran tactile peut passer de manière fluide du pavé tactile à l’interface tactile au doigt. Un utilisateur avancé peut naviguer dans un formulaire au clavier tout en utilisant une souris pour faire défiler la page. Une personne ayant une déficience motrice peut utiliser une combinaison de pointeur de tête et de dispositif à contacteur. Le critère protège tous ces flux de travail.

\n

Un échec se produit lorsqu’un site web utilise JavaScript pour détecter le type d’entrée utilisé, puis supprime ou désactive des fonctionnalités pour d’autres types d’entrée. Par exemple, si un site détecte un événement tactile et supprime ensuite les indicateurs de focus clavier ou désactive la navigation au clavier, il s’agit d’une violation directe. De même, le blocage de l’entrée par pointeur après détection de l’utilisation du clavier, ou l’utilisation d’API de plateforme pour limiter artificiellement l’entrée à une seule modalité, constituent tous des échecs.

\n

Une conformité est atteinte lorsque les utilisateurs peuvent utiliser n’importe lequel ou l’ensemble des mécanismes d’entrée disponibles à tout moment pendant leur interaction. Le contenu doit répondre correctement à tout mécanisme d’entrée que l’utilisateur choisit d’employer à un moment donné, sans exiger un rechargement de page, un changement de mode ou une action supplémentaire de l’utilisateur pour réactiver un type d’entrée.

\n

Le critère contient une exception officielle définie dans WCAG : la restriction est autorisée lorsqu’elle est essentielle — c’est-à-dire lorsqu’une modalité d’entrée spécifique est intrinsèquement requise. Un exemple classique est une application de reconnaissance d’écriture manuscrite où l’entrée tactile ou au stylet est précisément l’objet de la fonctionnalité. Un autre exemple pourrait être un champ de capture de signature numérique qui nécessite une entrée par pointeur spécifique. Même dans ces cas, l’exception doit être interprétée de manière restrictive et l’auteur doit fournir des moyens alternatifs d’accomplir la tâche chaque fois que possible.

\n

Il est important de noter que ce critère n’exige pas des auteurs qu’ils ajoutent la prise en charge de mécanismes d’entrée que l’appareil ne possède pas. Il régit les restrictions imposées aux mécanismes déjà pris en charge par l’appareil et la plateforme. Si un appareil n’a pas d’écran tactile, il n’y a rien à restreindre.

\n\n

Pourquoi c’est important

\n

La liberté d’utiliser des mécanismes d’entrée simultanés ou interchangeables n’est pas une fonctionnalité de confort — c’est une exigence d’accessibilité critique qui affecte directement plusieurs groupes d’utilisateurs distincts.

\n

Les personnes ayant des déficiences motrices s’appuient fréquemment sur des technologies d’assistance qui combinent plusieurs mécanismes d’entrée. Une personne ayant une mobilité limitée des mains peut utiliser un dispositif à contacteur sip-and-puff avec un clavier virtuel à l’écran. Une personne ayant un tremblement peut commencer à naviguer sur une page au clavier mais passer à une interface à la souris ou tactile lorsqu’un raccourci clavier échoue. Si un site web détecte un type d’entrée et désactive les autres, ces utilisateurs peuvent être complètement exclus du contenu ou des fonctionnalités.

\n

Les personnes ayant des troubles cognitifs ou des troubles d’apprentissage bénéficient souvent de la possibilité de choisir la méthode d’entrée qui leur semble la plus confortable ou naturelle pour une tâche donnée. Imposer une seule modalité supprime ce choix et peut introduire une charge cognitive inutile, en particulier lorsqu’un utilisateur n’est pas à l’aise avec la méthode d’entrée principale de l’appareil.

\n

Les personnes âgées, qui peuvent avoir des difficultés motrices liées à l’âge, utilisent de plus en plus des appareils qui prennent en charge à la fois l’entrée tactile et l’entrée au clavier. La possibilité de passer d’un mécanisme à l’autre à mesure que la motricité fine fluctue au cours de la journée est importante pour une utilisation autonome et durable du web.

\n

Les utilisateurs avancés et les utilisateurs d’appareils multimodaux — comme les utilisateurs de Surface Pro ou d’iPad Pro — utilisent régulièrement un clavier, un stylet et une interface tactile sur le même appareil, dans la même session. Un site web qui détecte l’entrée tactile et supprime les raccourcis clavier, ou l’inverse, dégrade l’expérience d’une base d’utilisateurs immense qui ne s’identifie pas nécessairement comme ayant un handicap.

\n

Considérons ce scénario réel : le portail en ligne d’une banque turque détecte qu’un client utilise une tablette à écran tactile et bascule dans un « mode mobile » qui désactive la navigation au clavier. Un client ayant un handicap moteur qui utilise la tablette avec un clavier Bluetooth ne peut désormais plus se déplacer par tabulation dans les champs de formulaire, naviguer dans les menus avec les touches fléchées ou utiliser des raccourcis clavier. Il ne peut pas accomplir ses opérations bancaires de manière autonome. Il ne s’agit pas seulement d’un échec en matière d’accessibilité, mais aussi d’un risque juridique potentiel au regard de la réglementation turque sur l’accessibilité.

\n

Du point de vue de l’ergonomie et du SEO, le respect des mécanismes d’entrée simultanés est corrélé à de meilleurs scores Core Web Vitals, à des taux de rebond plus faibles et à une satisfaction utilisateur plus élevée sur des catégories d’appareils diverses — autant de signaux que les moteurs de recherche valorisent.

\n\n

Règles Axe-core associées

\n

WCAG 2.5.6 nécessite un test manuel — il n’existe aucune règle axe-core automatisée capable de détecter de manière fiable toutes les violations de ce critère. La raison est fondamentale : les outils automatisés peuvent inspecter le DOM statique et le CSS, et ils peuvent détecter certains schémas JavaScript, mais ils ne peuvent pas observer pleinement le comportement à l’exécution des écouteurs d’événements lorsqu’ils répondent à différentes modalités d’entrée pendant une session utilisateur réelle. La décision de restreindre un mécanisme d’entrée est souvent encodée dans une logique applicative qui ne s’exécute qu’en réponse à des événements spécifiques, ce qui rend l’analyse statique insuffisante.

\n

\n
• Aucune règle axe-core automatisée dédiée n’existe pour 2.5.6. Axe-core ne fournit pas de règle qui vérifie spécifiquement les restrictions sur les mécanismes d’entrée simultanés, car la violation se manifeste sous forme de comportement JavaScript dynamique plutôt que de problème structurel HTML ou ARIA. Une page peut réussir tous les contrôles automatisés axe et tout de même violer 2.5.6 si ses gestionnaires d’événements suppriment ou désactivent de manière programmatique des modalités d’entrée à l’exécution.
\n
• Événements de pointeur et détection d’événements tactiles : Bien qu’axe-core ne puisse pas détecter la restriction elle-même, les auditeurs manuels doivent rechercher du JavaScript qui écoute les événements touchstart ou pointerdown puis modifie le DOM, supprime la gestion du focus ou définit des indicateurs qui modifient le comportement du clavier. De même, les écouteurs keydown qui déclenchent des changements de classes CSS masquant les cibles tactiles sont des signaux d’alerte à inspecter manuellement.
\n
• Pourquoi l’automatisation est insuffisante : Les analyseurs automatisés examinent le document à un instant donné. Les restrictions de mécanismes d’entrée sont conditionnelles — elles ne s’activent qu’après le déclenchement d’un événement d’entrée spécifique. Un analyseur exécuté avant l’interaction utilisateur ne peut pas voir qu’un gestionnaire touchstart appellera plus tard document.querySelectorAll('[tabindex]').forEach(el => el.setAttribute('tabindex', '-1')) et détruira effectivement la navigation au clavier. Seul un testeur humain qui exerce les deux modalités d’entrée en séquence peut découvrir cet échec.
\n

\n\n

Comment tester

\n

\n
1. Analyse automatisée de base : Exécutez axe DevTools ou Lighthouse sur la page pour établir une base de référence et détecter tout problème concomitant. Bien qu’aucun de ces outils ne dispose d’une règle dédiée à 2.5.6, les vérifications de bonnes pratiques d’axe DevTools peuvent signaler des pièges au clavier ou des problèmes de gestion du focus qui sont symptomatiques d’une restriction d’entrée. Notez tout échec à corriger parallèlement aux vérifications manuelles ci-dessous.
\n
2. Inspection du code source JavaScript et des écouteurs d’événements : Ouvrez Chrome DevTools, allez dans l’onglet Elements et utilisez le panneau Event Listeners pour vérifier si des écouteurs touchstart, pointerdown, pointermove ou MSPointerDown sont attachés au document ou au body. Dans la Console, recherchez dans le code source JavaScript de la page des schémas comme ontouchstart in window, navigator.maxTouchPoints ou 'pointer' in navigator combinés à des modifications du DOM. Ce sont des techniques courantes utilisées pour détecter la modalité d’entrée et conditionner des fonctionnalités.
\n
3. Test d’interaction multimodale (clavier + tactile) : Sur un appareil qui prend en charge à la fois l’entrée tactile et l’entrée au clavier (par exemple, une Surface, un iPad avec clavier ou un ordinateur portable à écran tactile), commencez à naviguer sur la page exclusivement au clavier (Tab, Maj+Tab, Entrée, Espace, touches fléchées). Notez quels éléments interactifs sont atteignables et fonctionnels. Ensuite, sans recharger la page, passez à la navigation tactile — touchez les liens, boutons et contrôles de formulaire. Vérifiez que toutes les fonctionnalités disponibles via le clavier restent accessibles via le tactile et inversement. Documentez tout élément qui devient inatteignable ou non fonctionnel après le changement.
\n
4. Test d’entrée combinée avec lecteur d’écran : Avec NVDA et Firefox, naviguez sur la page au clavier pour activer le mode lecteur d’écran. Utilisez ensuite l’écran tactile (si disponible) pour tenter d’interagir avec les mêmes éléments. Confirmez que le lecteur d’écran et la page répondent correctement aux deux types d’entrée. Répétez avec VoiceOver sur Safari sur un iPad, en utilisant à la fois les gestes tactiles et un clavier Bluetooth appairé. Avec JAWS sur Chrome, vérifiez que le passage du clavier à la souris ne casse pas la gestion du focus et ne rend pas les éléments interactifs inopérants.
\n
5. Revue de code à la recherche de schémas de verrouillage de modalité : Passez en revue manuellement les bibliothèques ou frameworks JavaScript utilisés sur la page pour détecter une éventuelle détection intégrée de modalité. Certaines bibliothèques d’interface utilisateur, en particulier les anciens frameworks mobile-first, incluent du code qui désactive les événements de souris ou de clavier sur les appareils où un contact tactile est détecté. Vérifiez la documentation et le code source de la bibliothèque pour ce type de comportement et assurez-vous qu’il a été neutralisé ou désactivé.
\n
6. Re-tester après des interactions dynamiques : Effectuez des actions qui déclenchent des modifications significatives du DOM — ouverture de modales, navigation dans les routes d’une application monopage, soumission de formulaires — et relancez le test multimodal après chaque transition. Des restrictions sont parfois introduites uniquement dans certains états de l’application.
\n

\n\n

Comment corriger

\n

Détecter le tactile pour désactiver la navigation au clavier — Incorrect

\n

<!-- JavaScript détecte le tactile et supprime toutes les valeurs tabindex,\n     cassant la navigation au clavier pour les utilisateurs qui changent de mode d’entrée -->\n<script>\n  window.addEventListener('touchstart', function() {\n    document.querySelectorAll('a, button, input, [tabindex]').forEach(function(el) {\n      el.setAttribute('tabindex', '-1');\n    });\n  }, { once: true });\n</script>

\n

Détecter le tactile pour désactiver la navigation au clavier — Correct

\n

<!-- Ne restreignez pas l’accessibilité clavier en fonction de la détection du tactile.\n     Autorisez le fonctionnement simultané des deux modalités d’entrée.\n     Si vous devez gérer les styles de focus pour des raisons esthétiques, utilisez\n     la pseudo-classe CSS :focus-visible au lieu de supprimer tabindex. -->\n<style>\n  /* Afficher les anneaux de focus uniquement pour la navigation au clavier, pas pour les clics souris,\n     sans supprimer l’accès clavier entièrement */\n  :focus:not(:focus-visible) {\n    outline: none;\n  }\n  :focus-visible {\n    outline: 3px solid #005fcc;\n    outline-offset: 2px;\n  }\n</style>\n<!-- Aucune détection de modalité en JavaScript n’est nécessaire -->

\n\n

Événement de pointeur utilisé pour supprimer les événements clavier — Incorrect

\n

<!-- Un curseur personnalisé qui, après avoir reçu une entrée par pointeur, cesse\n     de répondre aux flèches du clavier, enfermant l’utilisateur dans\n     une interaction uniquement au pointeur -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var pointerUsed = false;\n  slider.addEventListener('pointerdown', function() {\n    pointerUsed = true;\n  });\n  slider.addEventListener('keydown', function(e) {\n    if (pointerUsed) return; // clavier désactivé après interaction au pointeur\n    if (e.key === 'ArrowRight') { /* incrémenter */ }\n    if (e.key === 'ArrowLeft') { /* décrémenter */ }\n  });\n</script>

\n

Événement de pointeur utilisé pour supprimer les événements clavier — Correct

\n

<!-- Les interactions au pointeur et au clavier sont toutes deux gérées indépendamment.\n     Aucun indicateur n’est défini pour empêcher une modalité de fonctionner après\n     l’utilisation de l’autre. -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var value = 50;\n\n  function updateSlider(newValue) {\n    value = Math.max(0, Math.min(100, newValue));\n    slider.setAttribute('aria-valuenow', value);\n  }\n\n  // Gestionnaire de pointeur — toujours actif\n  slider.addEventListener('pointermove', function(e) {\n    if (e.buttons === 1) {\n      // calculer la nouvelle valeur à partir de la position du pointeur\n    }\n  });\n\n  // Gestionnaire clavier — toujours actif, non désactivé par l’utilisation du pointeur\n  slider.addEventListener('keydown', function(e) {\n    if (e.key === 'ArrowRight') updateSlider(value + 1);\n    if (e.key === 'ArrowLeft') updateSlider(value - 1);\n  });\n</script>

\n\n

Framework mobile désactivant automatiquement les événements souris — Incorrect

\n\n

(Content truncated due to token limit — please retry this article.)