WCAG 2.5.1 : Gestes du pointeur

Ce que signifie cette règle

WCAG 2.5.1 Gestes du pointeur exige que toute fonctionnalité d’une page web qui repose sur des gestes multipoints (gestes utilisant deux points de contact simultanés ou plus, comme un pincement à deux doigts pour zoomer ou un balayage à trois doigts) ou sur des gestes basés sur un tracé (gestes où le chemin parcouru par le pointeur est important, comme un balayage, un glissement le long d’un trajet spécifique ou une forme dessinée) soit également opérable à l’aide d’un seul pointeur, d’une manière qui ne nécessite pas de geste basé sur un tracé. Un seul pointeur est toute entrée qui agit en un seul point — cela inclut un toucher avec un seul doigt, un clic de souris, un appui avec un stylet et des entrées similaires.

En pratique, si votre carrousel fait avancer les diapositives lorsque l’utilisateur balaie horizontalement, vous devez également fournir des boutons suivant et précédent qui peuvent être activés avec un simple toucher ou clic. Si votre composant de carte personnalisé répond à un pincement à deux doigts pour zoomer ou dézoomer, vous devez également fournir des contrôles de zoom avant et zoom arrière qui ne nécessitent qu’un seul toucher. Le critère n’interdit pas les gestes multipoints ou basés sur un tracé — il exige simplement qu’une alternative équivalente à un seul pointeur existe toujours.

L’exception officielle de WCAG précise : l’exigence ne s’applique pas lorsque le geste multipoint ou basé sur un tracé est essentiel. Un geste essentiel est un geste dont la suppression modifierait fondamentalement l’information ou la fonctionnalité, et pour lequel du texte ou une autre alternative ne peut pas atteindre le même objectif. Un composant de signature manuscrite libre ou une application de dessin où le tracé dessiné lui-même constitue le résultat seraient considérés comme essentiels. Cependant, la grande majorité des interactions de navigation, de carrousel, de carte et de curseur ne relèvent pas de cette exception, car elles peuvent être reproduites avec de simples alternatives par toucher/clic sans aucune perte d’information.

Ce critère s’applique à toute entrée de type pointeur : écrans tactiles, souris, stylet, pointeurs de suivi oculaire et tout autre dispositif de pointage. Il s’agit d’une exigence de niveau A dans WCAG 2.2, ce qui signifie qu’elle est considérée comme une exigence d’accessibilité de base qui doit être respectée pour une conformité minimale.

Une implémentation conforme fournit au moins un mécanisme permettant d’accomplir chaque fonction dépendante d’un geste à l’aide d’une activation à un seul point, non basée sur un tracé — généralement un bouton visible, un lien ou un autre contrôle focalisable. Une implémentation non conforme repose exclusivement sur un geste de balayage, pincement, écartement, rotation ou tracé dessiné pour exécuter une fonction, sans fournir d’alternative équivalente à un seul pointeur.

Pourquoi c’est important

Les déficiences motrices touchent une part significative de la population mondiale. Des affections telles que la maladie de Parkinson, le tremblement essentiel, la paralysie cérébrale, l’hémiplégie post-AVC, les différences de membres et les troubles musculo-squelettiques liés aux mouvements répétitifs peuvent rendre difficile, voire impossible, l’exécution fiable de gestes multipoints ou basés sur un tracé. Selon l’Organisation mondiale de la Santé, environ 1,3 milliard de personnes dans le monde vivent avec une forme de handicap significatif, et les déficiences motrices et de mobilité comptent parmi les catégories les plus courantes. Lorsque les interfaces web reposent exclusivement sur des gestes complexes, ces utilisateurs sont totalement exclus de fonctionnalités que les utilisateurs voyants et non handicapés considèrent comme allant de soi.

Considérez un scénario concret : une personne ayant un tremblement essentiel navigue sur un site de e-commerce turc sur une tablette. La galerie d’images du produit utilise uniquement un geste de balayage pour passer d’une photo à l’autre. Cette personne ne peut pas exécuter de manière fiable un balayage horizontal net — son tremblement provoque des touchers accidentels, des mouvements diagonaux ou des contacts involontaires avec plusieurs doigts. Sans boutons précédent/suivant, elle ne peut pas voir d’autres photos du produit et peut abandonner l’achat. Ajouter deux simples boutons fléchés coûte quelques minutes à l’équipe de développement mais supprime une barrière complète pour cette personne.

Au-delà des déficiences motrices, ce critère bénéficie également aux personnes utilisant des prothèses de membre supérieur ou des dispositifs d’accès à contact unique qui émulent un seul pointeur, aux personnes utilisant des appareils montés sur des fauteuils roulants pour lesquels la rotation ou le multi-touch est mécaniquement peu pratique, et aux personnes âgées qui trouvent les gestes tactiles complexes contre-intuitifs ou difficiles à apprendre. Les personnes utilisant un appareil avec une souris ou un stylet non tactile sont également directement concernées — ces méthodes d’entrée sont intrinsèquement à un seul pointeur et ne peuvent pas exécuter de gestes multipoints.

Du point de vue de l’ergonomie et des enjeux commerciaux, fournir des contrôles explicites à un seul pointeur (boutons, liens) améliore également la découvrabilité pour tous les utilisateurs, réduit la charge cognitive et peut contribuer positivement aux taux d’achèvement des tâches et aux indicateurs de conversion. Les moteurs de recherche peuvent également analyser et suivre plus fiablement une navigation pilotée par des boutons qu’une navigation pilotée par des gestes, offrant des avantages SEO secondaires pour les schémas de navigation explorables par les robots.

Règles axe-core associées

WCAG 2.5.1 nécessite des tests manuels, car les outils automatisés ne peuvent pas détecter de manière fiable si un comportement dépendant d’un geste dispose d’une alternative à un seul pointeur. Aucune règle axe-core automatisée ne correspond directement à ce critère. Les raisons pour lesquelles la détection automatisée est insuffisante sont les suivantes :

• Tests manuels requis — détection des gestes : Les analyseurs automatisés examinent la structure DOM statique et les styles calculés. Ils ne peuvent pas observer le comportement des écouteurs d’événements JavaScript à l’exécution d’une manière qui distingue si un gestionnaire touchstart/touchmove/touchend implémente un balayage dépendant d’un tracé ou simplement un toucher. Un analyseur voit que des événements tactiles sont présents mais ne peut pas déterminer si la fonctionnalité résultante est également disponible via une alternative à un seul pointeur. Cela nécessite qu’un testeur humain interagisse avec l’interface en utilisant à la fois des méthodes basées sur des gestes et des méthodes à un seul pointeur, puis compare les fonctionnalités disponibles.
• Tests manuels requis — vérification de l’équivalence : Même si un outil pouvait signaler l’existence d’un écouteur de geste multipoint, il ne pourrait pas évaluer si un bouton ou un lien fourni produit des résultats fonctionnellement équivalents. Vérifier l’équivalence — que l’alternative déclenche le même résultat, qu’elle est visible et accessible, et qu’elle n’est pas cachée derrière une étape supplémentaire — nécessite un jugement humain éclairé par l’intention du critère.
• Tests manuels requis — exception de geste essentiel : Déterminer si un geste relève de l’exception « essentiel » nécessite une compréhension contextuelle de l’objectif de l’application qu’aucune règle automatisée ne peut évaluer de manière fiable.

Les testeurs doivent utiliser les outils de développement du navigateur pour inspecter les écouteurs d’événements attachés (dans Chrome DevTools, faites un clic droit sur un élément, sélectionnez « Inspecter », puis consultez l’onglet « Event Listeners ») comme point de départ pour identifier les éléments qui possèdent des gestionnaires d’événements tactiles ou de pointeur, puis vérifier manuellement la présence et l’équivalence des alternatives à un seul pointeur.

Comment tester

1. Exécuter une analyse automatisée comme base : Utilisez axe DevTools, Lighthouse ou l’audit intégré du widget Accsible pour analyser la page. Bien qu’aucune règle ne corresponde directement à 2.5.1, les résultats de l’analyse peuvent signaler des problèmes connexes (tels que l’absence de contrôles focalisables) qui fournissent un contexte pour l’examen manuel. Notez tout élément interactif signalé pour absence de support clavier ou pointeur.
2. Identifier les fonctionnalités dépendantes des gestes : Explorez manuellement la page sur un appareil tactile (ou en utilisant l’émulation d’appareil du navigateur dans Chrome DevTools — activez la barre d’outils d’appareil et interagissez en utilisant le toucher simulé). Recherchez des carrousels, curseurs, cartes, accordéons, galeries d’images, panneaux défilants, interfaces de glisser-déposer, outils de dessin et tout autre composant qui répond aux gestes tactiles. Documentez chaque fonction que vous découvrez et qui est déclenchée par un balayage, un pincement, une rotation ou tout autre geste basé sur un tracé ou multipoint.
3. Essayer des équivalents à un seul pointeur : Pour chaque fonction dépendante d’un geste identifiée, essayez d’accomplir la même fonction en utilisant uniquement des touchers simples (ou des clics de souris sur un ordinateur de bureau). Vérifiez si des contrôles visibles tels que des boutons, flèches ou liens existent et déclenchent le même résultat. Essayez d’actionner ces contrôles à l’aide d’une souris, d’un clavier (Tab pour focaliser, Entrée/Espace pour activer) et d’un lecteur d’écran.
4. Vérification avec lecteur d’écran (NVDA + Firefox) : Ouvrez NVDA et Firefox. Naviguez dans les composants interactifs à l’aide de la touche Tab et des flèches. Vérifiez que les contrôles à un seul pointeur (boutons, liens) pour les fonctions basées sur des gestes sont annoncés par le lecteur d’écran, accessibles au clavier et produisent le résultat attendu lorsqu’ils sont activés.
5. Vérification avec lecteur d’écran (VoiceOver + Safari sur iOS) : Activez VoiceOver sur un iPhone ou un iPad. Balayez vers la droite avec un doigt pour naviguer entre les éléments. Vérifiez que tous les contrôles fournissant des alternatives à un seul pointeur aux gestes sont accessibles et activables via le geste de toucher de VoiceOver, et qu’ils produisent le bon résultat.
6. Vérification avec lecteur d’écran (JAWS + Chrome) : Utilisez JAWS avec Chrome sous Windows. Parcourez les composants interactifs avec Tab et vérifiez que les contrôles alternatifs aux gestes sont focalisables, correctement étiquetés et fonctionnels.
7. Évaluer l’exception d’essentiel : Pour toute fonction dépendante d’un geste dépourvue d’alternative à un seul pointeur, déterminez si le geste est réellement essentiel au contenu ou à la fonctionnalité. Si vous ne pouvez pas justifier l’exception, consignez-la comme un échec. Documentez vos conclusions avec des captures d’écran et des étapes de reproduction.

Comment corriger

Carrousel d’images avec navigation uniquement par balayage — Incorrect

<!-- Carousel that only listens for touch swipe events, no button controls -->
<div id='carousel' class='carousel'>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
</div>
<!-- JavaScript only adds touchstart/touchend swipe detection -->
<script>
  // Only gesture-based: no keyboard or click alternative
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
</script>

Carrousel d’images avec navigation uniquement par balayage — Correct

<!-- Carousel with both swipe gesture support AND visible single-pointer button controls -->
<div id='carousel' class='carousel' role='region' aria-label='Product images'>
  <button id='prev-btn' aria-label='Previous image' onclick='prevSlide()'>
    &lsaquo; Previous
  </button>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
  <button id='next-btn' aria-label='Next image' onclick='nextSlide()'>
    Next &rsaquo;
  </button>
</div>
<!-- Swipe is retained as an enhancement; buttons provide the single-pointer alternative -->
<script>
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
  function prevSlide() { /* move to previous slide */ }
  function nextSlide() { /* move to next slide */ }
</script>

Carte avec zoom uniquement par pincement — Incorrect

<!-- Map widget that only responds to two-finger pinch gestures for zoom -->
<div id='map' class='map-widget'></div>
<script>
  // Only multipoint pinch gesture is wired up; no zoom buttons provided
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
</script>

Carte avec zoom uniquement par pincement — Correct

<!-- Map widget with pinch-to-zoom PLUS visible zoom controls for single-pointer access -->
<div class='map-container' role='application' aria-label='Interactive map'>
  <div id='map' class='map-widget'></div>
  <div class='map-controls'>
    <!-- Single-pointer alternatives for zoom in and out -->
    <button type='button' aria-label='Zoom in' onclick='mapZoomIn()'>+</button>
    <button type='button' aria-label='Zoom out' onclick='mapZoomOut()'>&minus;</button>
  </div>
</div>
<script>
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
  function mapZoomIn() { /* increase zoom level by one step */ }
  function mapZoomOut() { /* decrease zoom level by one step */ }
</script>

Curseur de plage avec geste de glissement uniquement — Incorrect

<!-- Custom price range slider that only works by dragging a thumb along a track -->
<div class='price-slider' id='priceSlider'>
  <div class='track'>
    <div class='thumb' id='sliderThumb'></div>
  </div>
</div>
<!-- No keyboard support, no input field, no increment/decrement buttons -->

Curseur de plage avec geste de glissement uniquement — Correct

<!-- Use the native <input type='range'> which provides built-in keyboard and single-pointer support -->
<label for='priceRange'>Maximum price: <span id='priceValue'>500</span> TL</label>
<input
  type='range'
  id='priceRange'
  name='priceRange'
  min='0'
  max='1000'
  value='500'
  step='10'
  aria-valuemin='0'
  aria-valuemax='1000'
  aria-valuenow='500'
  aria-label='Maximum price in Turkish lira'
  oninput='document.getElementById("priceValue").textContent = this.value'
>
<!-- Native range input supports click, tap, keyboard arrow keys, and touch drag --
     covering all single-pointer and path-based interaction needs natively -->

Erreurs courantes

• Fournir des carrousels contrôlés uniquement par balayage sans aucun bouton précédent/suivant : De nombreuses bibliothèques de carrousel sont livrées avec un support de gestes uniquement ; les développeurs doivent configurer et afficher explicitement des boutons de navigation pour fournir une alternative à un seul pointeur.
• Masquer les boutons de navigation sur les appareils tactiles via des media queries CSS : Un schéma courant masque les boutons fléchés sur les écrans supposés être tactiles (par exemple, @media (pointer: coarse)), supprimant l’alternative à un seul pointeur pour les personnes ayant une déficience motrice qui en dépendent même sur les écrans tactiles.
• Se reposer uniquement sur un geste de pincement à deux doigts pour le zoom de la carte sans proposer de boutons de zoom : Les intégrations de cartes tierces (implémentations personnalisées) omettent fréquemment les contrôles de zoom, laissant le pincement comme seul mécanisme de zoom.
• Utiliser des schémas de balayage pour supprimer ou révéler sans bouton d’action alternatif : Les éléments de liste dans les applications web qui révèlent des options de suppression ou d’action uniquement via un balayage horizontal n’ont aucun mécanisme équivalent basé sur un toucher pour les personnes qui ne peuvent pas balayer de manière fiable.
• Interfaces de glisser-déposer personnalisées sans alternative de réorganisation au clavier ou par clic : Les interactions de glisser-déposer sont par nature basées sur un tracé ; ne pas fournir de mécanisme alternatif (comme des boutons haut/bas ou un modèle couper-coller) enfreint ce critère.
• Composants de dessin ou de signature supposant que le tracé dessiné lui-même n’est pas le résultat : Les développeurs invoquent parfois à tort l’exception « essentiel » pour des composants qui sont en réalité de simples contrôles d’interface (par exemple, un schéma de déverrouillage par geste pour révéler du contenu) plutôt que de véritables outils d’entrée manuscrite libre.
• Placer les contrôles alternatifs à un seul pointeur en dehors de la zone visible ou dans un état replié par défaut : Si les boutons équivalents existent dans le DOM mais sont visuellement masqués ou nécessitent une interaction supplémentaire pour être révélés, ils ne satisfont pas pleinement à l’exigence d’une alternative à un seul pointeur perceptible et opérable.
• Implémenter des bibliothèques de gestes qui interceptent les événements de pointeur et empêchent le comportement par défaut : Les bibliothèques qui appellent event.preventDefault() sur les événements tactiles peuvent bloquer involontairement les interactions à un seul pointeur et le défilement du navigateur, créant des échecs involontaires au-delà du critère lié aux gestes lui-même.
• Supposer que l’ajout d’un aria-label à une zone contrôlée par gestes est suffisant : Étiqueter une zone de balayage ne fournit pas d’alternative à un seul pointeur — cela ne fait que la décrire aux utilisateurs de lecteurs d’écran qui ne peuvent toujours pas l’actionner sans support de gestes.
• Ne pas tester sur de vrais appareils ou avec la simulation tactile : Les développeurs qui testent uniquement sur ordinateur de bureau avec une souris peuvent ne jamais découvrir qu’une fonctionnalité est exclusivement contrôlée par gestes sur mobile, car le repli par clic de souris fonctionne sur ordinateur de bureau mais le chemin de code spécifique au tactile ne dispose pas d’équivalent par clic.

Lien avec la réglementation turque en matière d’accessibilité

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des obligations obligatoires en matière d’accessibilité web et mobile pour un large éventail d’entités publiques et privées opérant en Turquie. La circulaire adopte WCAG 2.2 comme norme technique normative, rendant tous les critères de succès de niveau A — y compris WCAG 2.5.1 Gestes du pointeur — légalement obligatoires comme exigences de base.

Le calendrier de conformité prévu par la circulaire est échelonné : les institutions et organismes publics doivent atteindre la conformité dans l’année suivant l’entrée en vigueur de la circulaire, tandis que les entités du secteur privé couvertes par la réglementation disposent d’un délai de deux ans pour atteindre la conformité complète. Le non-respect expose les entités concernées à un contrôle réglementaire et à des mesures d’exécution de la part des autorités de supervision compétentes.

Les entités couvertes par la circulaire incluent un large éventail de fournisseurs turcs de services numériques. Les institutions publiques à tous les niveaux de gouvernement et leurs organismes affiliés sont concernées. Dans le secteur privé, la circulaire s’applique aux plateformes et places de marché de e-commerce, aux banques et institutions financières, aux hôpitaux privés et prestataires de soins de santé, aux entreprises de télécommunications comptant 200,000 abonnés ou plus, aux agences de voyage, aux entreprises privées de transport de passagers et aux écoles privées opérant sous autorisation du ministère de l’Éducation nationale (MoNE).

Pour ces organisations, WCAG 2.5.1 a des implications directes et pratiques. Les sites de e-commerce turcs utilisent fréquemment des galeries d’images de produits contrôlées par gestes, une navigation par catégories basée sur le balayage et des visionneuses de produits avec zoom par pincement — qui doivent désormais toutes disposer d’alternatives à un seul pointeur. Les applications bancaires et financières qui utilisent des schémas d’authentification basés sur des gestes ou des interfaces de transaction basées sur le glisser-déposer doivent être auditées et corrigées. Les portails de santé avec des localisateurs de cliniques basés sur des cartes utilisant le zoom par pincement doivent fournir des boutons de zoom. Les portails en libre-service des télécoms avec des sélecteurs de forfaits contrôlés par balayage doivent ajouter des contrôles basés sur le toucher.

Les organisations opérant en Turquie sont fortement encouragées à inclure WCAG 2.5.1 dans leurs listes de contrôle d’audit d’accessibilité immédiatement, car les schémas d’interaction par gestes concernés par ce critère sont omniprésents dans la conception web responsive moderne et le développement mobile-first — mais sont fréquemment négligés parce qu’ils semblent fonctionner correctement pour la majorité des utilisateurs. Traiter ce critère de manière proactive dans le cadre d’un programme de conformité WCAG 2.2 de niveau A est à la fois une obligation légale en vertu de la circulaire présidentielle 2025/10 et une amélioration significative de l’inclusion numérique pour les personnes ayant des déficiences motrices en Turquie.