WCAG 2.5.7 : Mouvements de glissement

Ce que signifie cette règle

WCAG 2.5.7 — Mouvements de glissement (niveau AA, introduit dans WCAG 2.2) stipule que toute fonctionnalité qui utilise un mouvement de glissement pour fonctionner doit pouvoir être réalisée au moyen d’une action à pointeur unique sans glissement, sauf lorsque le mouvement de glissement est essentiel à la fonctionnalité et qu’aucun mécanisme alternatif n’existe.

Un mouvement de glissement est défini comme une interaction où le pointeur est pressé, maintenu, puis déplacé vers une nouvelle position avant d’être relâché. Des exemples courants incluent : trier des éléments de liste par glisser-déposer, redimensionner des panneaux en faisant glisser une poignée de séparation, utiliser un curseur en saisissant et tirant le pouce, dessiner sur un canevas, et réorganiser des cartes kanban. Tous ces modèles doivent disposer d’une alternative équivalente à pointeur unique — un mécanisme que l’utilisateur peut activer sans avoir besoin de maintenir le bouton du pointeur enfoncé pendant le déplacement.

La contrainte de pointeur unique est importante. L’alternative n’a pas besoin d’être un raccourci clavier ; elle peut être un clic de souris, un tapotement, ou toute autre action qui implique un seul point de contact et ne nécessite pas de mouvement prolongé pendant l’appui. Par exemple, un curseur qui permet aux utilisateurs de cliquer directement sur la piste pour passer à une valeur donnée satisfait au critère, car cliquer sur la piste est une action à pointeur unique sans glissement.

Ce qui est considéré comme conforme : Une liste pouvant être réorganisée par glisser-déposer qui propose également des boutons flèche haut/bas ou une boîte de dialogue « déplacer vers la position » ; un curseur de plage qui accepte les clics n’importe où sur la piste ; un panneau redimensionnable qui dispose aussi d’un champ de saisie numérique ou d’une fonctionnalité de double-clic pour réduire ; une carte qui peut être déplacée en cliquant sur des flèches de navigation ainsi qu’en la faisant glisser.

Ce qui est considéré comme non conforme : Une liste triable où le seul moyen de réorganiser les éléments est de les faire glisser ; un redimensionneur de panneau divisé sans autre possibilité d’interaction ; un téléversement de fichier qui n’accepte que le glisser-déposer sans bouton de secours ; un sélecteur de couleur où le seul moyen de choisir une teinte est de faire glisser sur une bande de dégradé sans alternative de saisie numérique ou textuelle.

Exception officielle : Le critère autorise explicitement les interfaces basées uniquement sur le glissement lorsque le glissement est essentiel — c’est-à-dire que le supprimer modifierait fondamentalement ou invaliderait l’activité. Une application de dessin gestuel ou un composant de capture de signature en sont des exemples classiques. Cependant, cette exception est volontairement étroite ; la plupart des modèles d’interface courants (curseurs, listes triables, colonnes redimensionnables) ne sont pas considérés comme des scénarios de glissement essentiel.

Pourquoi c’est important

Les déficiences motrices touchent une part significative de la population mondiale. Selon l’Organisation mondiale de la Santé, plus de 1,3 milliard de personnes dans le monde — soit environ 16 % de la population mondiale — vivent avec une forme de handicap, et les déficiences motrices ou physiques comptent parmi les catégories les plus courantes. Des affections telles que le tremblement essentiel, la maladie de Parkinson, les troubles musculo-squelettiques liés aux mouvements répétitifs, l’hémiplégie, les lésions de la moelle épinière et les différences de membres rendent difficile, voire impossible, le maintien d’un bouton de pointeur enfoncé tout en déplaçant simultanément le pointeur avec précision.

Pour un utilisateur ayant des tremblements des mains, faire glisser le pouce d’un curseur d’une extrémité de la piste à l’autre n’est pas seulement peu pratique — cela peut être totalement peu fiable. Le pointeur peut glisser, le glissement peut être annulé en cours d’opération, ou la précision requise peut simplement dépasser ce que des mains affectées par des tremblements peuvent fournir. Ces utilisateurs s’appuient souvent sur des alternatives basées sur le clic, la navigation au clavier ou des dispositifs d’accès par contacteur. Si le seul moyen d’accéder à une fonctionnalité est un geste de glissement, l’ensemble de la fonctionnalité leur est de fait inaccessible.

Scénario concret : Considérons une page produit de commerce électronique avec un filtre de fourchette de prix implémenté sous forme de curseur de plage à double poignée. Un utilisateur ayant une motricité fine limitée essaie de réduire la plage de prix mais ne parvient pas à faire glisser de manière fiable l’une ou l’autre des poignées jusqu’à la position cible — le pointeur dérive, la poignée se cale sur de mauvaises valeurs, et la frustration le conduit à abandonner la tâche. Si le même filtre proposait une paire de champs de texte numériques à côté du curseur, cet utilisateur pourrait simplement saisir les prix minimum et maximum souhaités et valider. Ce simple ajout transforme une fonctionnalité inaccessible en une fonctionnalité pleinement accessible pour un coût de développement minimal.

Au-delà des déficiences motrices, les utilisateurs sur écrans tactiles dans des environnements difficiles — tenant une rampe dans les transports en commun, portant des gants ou utilisant un stylet — bénéficient des alternatives à pointeur unique. L’accessibilité cognitive joue également un rôle : des interactions plus simples, basées sur le clic, réduisent la charge cognitive par rapport aux opérations de glisser-déposer qui exigent de comprendre une métaphore spatiale tout en maintenant une précision physique.

Du point de vue de l’ergonomie et du référencement, le fait de garantir que les contrôles interactifs sont accessibles via des actions simples du pointeur tend à produire une architecture de composants plus propre avec un balisage sémantique de meilleure qualité, ce qui améliore à la fois la découvrabilité par les technologies d’assistance et par les robots d’indexation des moteurs de recherche.

Règles axe-core associées

WCAG 2.5.7 est un critère de test manuel. Au moment de la rédaction, axe-core n’inclut pas de règle automatisée pouvant signaler de manière définitive les violations de ce critère. La raison tient au fonctionnement même du critère : les outils automatisés peuvent détecter qu’un écouteur d’événement de glissement est présent sur un élément, mais ils ne peuvent pas déterminer avec certitude si une alternative sans glissement est disponible, si cette alternative couvre la même fonctionnalité, ou si le glissement est essentiel. Ce jugement nécessite une évaluation humaine de la conception de l’interaction.

• Audit manuel — possibilités de glisser-déposer : Les testeurs doivent identifier chaque composant de la page qui répond aux séquences mousedown/mousemove/mouseup ou à leurs équivalents tactiles (touchstart/touchmove/touchend) et vérifier que chacun expose un mécanisme alternatif pouvant être actionné via un simple appui de pointeur sans glissement. Les testeurs doivent également vérifier la présence de l’attribut HTML5 draggable et des écouteurs d’événements associés dragstart/drop comme signaux de fonctionnalités dépendantes du glissement.
• Audit manuel — inspection des événements de pointeur : En utilisant l’inspection des écouteurs d’événements dans les DevTools du navigateur ou des outils d’audit d’accessibilité comme Accessibility Insights for Web (qui inclut une liste de contrôle manuelle pour 2.5.7), les testeurs doivent inspecter les composants pour repérer les gestionnaires d’événements de pointeur et confirmer que l’ensemble de la plage de valeurs du composant ou sa capacité de repositionnement est accessible sans mouvement prolongé du pointeur.
• Pourquoi l’automatisation ne peut pas détecter cela : Un analyseur automatisé peut signaler qu’un <div> possède un écouteur dragstart, mais il ne peut pas savoir si le clic sur un bouton voisin intitulé « Move up » fournit une alternative conforme. Cela nécessite de comprendre la relation entre les éléments d’interface et leur équivalence fonctionnelle — une tâche qui dépasse actuellement les capacités des outils d’analyse du DOM statique ou en temps réel.

Comment tester

1. Base de référence par analyse automatisée : Exécutez axe DevTools ou Lighthouse sur la page pour faire apparaître les problèmes liés au pointeur ou aux modalités d’entrée. Bien qu’aucune règle axe ne corresponde directement à 2.5.7, l’examen des problèmes signalés au titre des règles 2.5.x fournit un contexte utile. Notez tout composant que axe signale comme ayant un support clavier insuffisant, car ceux-ci se recoupent souvent avec des modèles basés uniquement sur le glissement.
2. Identifier tous les composants glissables : Ouvrez Chrome DevTools, accédez au panneau Elements, et utilisez l’onglet Event Listeners pour rechercher les gestionnaires dragstart, drag, drop, pointermove, mousemove et touchmove. Vous pouvez aussi rechercher dans le code source de la page l’attribut draggable et des motifs JavaScript comme .addEventListener('dragstart'. Dressez la liste de chaque composant qui nécessite un glissement.
3. Tester chaque composant glissable pour des alternatives : Pour chaque composant identifié, tentez d’obtenir le même résultat en utilisant uniquement des clics ou tapotements à pointeur unique — sans glissement. Pour un curseur, cliquez directement sur la piste à la position souhaitée. Pour une liste triable, recherchez des boutons de déplacement ou des options de menu contextuel. Pour un panneau redimensionnable, recherchez des contrôles basés sur le double-clic ou le clic. Si aucune alternative n’existe, le critère n’est pas respecté.
4. Vérification de la navigation au clavier (signal secondaire) : Testez tous les composants glissables uniquement au clavier (Tab pour le focus, flèches, Entrée/Espace). Bien que le support clavier soit couvert par WCAG 2.1.1, la présence d’un support clavier robuste est souvent corrélée à l’existence d’alternatives sans glissement, ce qui en fait une étape de confirmation utile. Utilisez NVDA + Firefox, VoiceOver + Safari (macOS/iOS) ou JAWS + Chrome et vérifiez que l’ensemble des fonctionnalités du composant est exploitable sans dispositif de pointage.
5. Vérification sur appareil tactile : Sur un appareil mobile ou en utilisant l’émulation d’appareil en mode tactile dans Chrome DevTools, tentez d’accomplir les mêmes tâches en utilisant des gestes de tapotement (sans glisser-maintenir). Confirmez que des tapotements simples ou des interactions de type « tapoter sur la cible » suffisent pour l’ensemble des fonctionnalités.
6. Documenter les résultats : Pour chaque composant testé, consignez si une alternative conforme à pointeur unique existe, si elle couvre l’ensemble des fonctionnalités, et si l’opération de glissement peut être considérée comme essentielle. Utilisez la liste de contrôle de test manuel pour WCAG 2.5.7 d’Accessibility Insights for Web comme guide structuré.

Comment corriger

Curseur de plage sans support de clic sur la piste — Incorrect

<!-- Slider that only responds to drag on the thumb;
     clicking the track does nothing -->
<div class='slider-container'>
  <div class='slider-track'>
    <div class='slider-thumb'
         id='priceSlider'
         onmousedown='startDrag(event)'>
    </div>
  </div>
</div>

Curseur de plage avec clic sur la piste et saisie numérique — Correct

<!-- Native <input type='range'> provides drag, click-on-track,
     and keyboard support natively. A numeric input offers an
     additional single-pointer alternative. -->
<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'
       oninput='document.getElementById("priceValue").textContent = this.value;
                document.getElementById("priceNumber").value = this.value;'>
<label for='priceNumber'>Or enter a value:</label>
<input type='number'
       id='priceNumber'
       name='priceNumber'
       min='0'
       max='1000'
       value='500'>

Liste triable par glisser-déposer sans alternative — Incorrect

<!-- Items can only be reordered by dragging.
     No move buttons or keyboard reordering exist. -->
<ul id='taskList'>
  <li draggable='true' ondragstart='handleDrag(event)' id='item1'>Task One</li>
  <li draggable='true' ondragstart='handleDrag(event)' id='item2'>Task Two</li>
  <li draggable='true' ondragstart='handleDrag(event)' id='item3'>Task Three</li>
</ul>

Liste triable par glisser-déposer avec boutons de déplacement — Correct

<!-- Drag-and-drop is preserved for users who can use it.
     Move Up / Move Down buttons provide a single-pointer
     (and keyboard-accessible) alternative for every item. -->
<ul id='taskList' aria-label='Sortable task list'>
  <li draggable='true'
      ondragstart='handleDrag(event)'
      id='item1'>
    <span>Task One</span>
    <button type='button'
            onclick='moveItem("item1", -1)'
            aria-label='Move Task One up'>
      &uarr; Move Up
    </button>
    <button type='button'
            onclick='moveItem("item1", 1)'
            aria-label='Move Task One down'>
      &darr; Move Down
    </button>
  </li>
  <li draggable='true'
      ondragstart='handleDrag(event)'
      id='item2'>
    <span>Task Two</span>
    <button type='button'
            onclick='moveItem("item2", -1)'
            aria-label='Move Task Two up'>
      &uarr; Move Up
    </button>
    <button type='button'
            onclick='moveItem("item2", 1)'
            aria-label='Move Task Two down'>
      &darr; Move Down
    </button>
  </li>
</ul>

Panneau divisé redimensionnable sans alternative — Incorrect

<!-- The divider can only be repositioned by dragging.
     No percentage input or preset-size buttons exist. -->
<div class='split-pane'>
  <div class='pane pane-left' id='leftPane'>Content A</div>
  <div class='divider'
       onmousedown='startResize(event)'
       aria-hidden='true'></div>
  <div class='pane pane-right' id='rightPane'>Content B</div>
</div>

Panneau divisé redimensionnable avec boutons de tailles prédéfinies — Correct

<!-- The divider still supports dragging, but preset-layout
     buttons allow single-pointer repositioning. The divider
     is also keyboard-focusable with arrow-key support. -->
<div class='split-pane-wrapper'>
  <div class='split-controls' role='group' aria-label='Panel size presets'>
    <button type='button' onclick='setSplit(25)'>25 / 75</button>
    <button type='button' onclick='setsplit(50)'>50 / 50</button>
    <button type='button' onclick='setSplit(75)'>75 / 25</button>
  </div>
  <div class='split-pane'>
    <div class='pane pane-left' id='leftPane'>Content A</div>
    <div class='divider'
         role='separator'
         tabindex='0'
         aria-label='Resize panels'
         aria-valuenow='50'
         aria-valuemin='10'
         aria-valuemax='90'
         onmousedown='startResize(event)'
         onkeydown='resizeWithKeys(event)'>
    </div>
    <div class='pane pane-right' id='rightPane'>Content B</div>
  </div>
</div>

Erreurs courantes

• Implémenter des curseurs comme composants personnalisés basés sur des <div> sans support de clic sur la piste, en s’appuyant entièrement sur le glissement de l’élément pouce et sans gérer les événements click sur l’élément de piste lui-même pour faire sauter la valeur à la position cliquée.
• Supposer que le téléversement de fichiers par glisser-déposer est le seul mécanisme de téléversement nécessaire, sans fournir un bouton de sélection de fichier visible et cliquable (<input type='file'>) comme solution de secours obligatoire à côté de la zone de dépôt.
• Appliquer l’exception d’essentialité de manière trop large — par exemple, considérer une liste de tâches triable ou un tableau kanban comme un « glissement essentiel » alors que des boutons Monter/Descendre satisferaient pleinement les besoins des utilisateurs sans aucune perte de fonctionnalité.
• Fournir des alternatives clavier mais pas d’alternatives à pointeur unique, en interprétant à tort WCAG 2.5.7 comme satisfait par le seul support clavier. Le critère exige spécifiquement un parcours à pointeur unique ; les solutions uniquement clavier répondent à 2.1.1, pas à 2.5.7.
• Masquer les boutons de déplacement ou les champs numériques derrière des états de survol ou des menus secondaires qui eux-mêmes nécessitent des interactions de glissement ou des séquences de pointeur complexes pour être révélés, ce qui annule de fait l’accessibilité de l’alternative.
• Négliger les appareils tactiles en testant les alternatives au glissement uniquement avec une souris de bureau, puis en déployant pour des utilisateurs sur écrans tactiles où le comportement du geste de glissement et de ses alternatives peut différer significativement de l’implémentation sur ordinateur de bureau.
• Utiliser pointer-events: none sur la piste du curseur en CSS pour éviter les clics accidentels pendant le glissement, ce qui bloque involontairement l’alternative de clic sur la piste exigée par 2.5.7.
• Ne pas fournir d’alternative pour les interactions de déplacement/glissement sur les cartes dans les cartes intégrées ou les visualisations personnalisées basées sur un canevas, alors que le clic sur des boutons fléchés directionnels ou la saisie de coordonnées constituerait une alternative à pointeur unique suffisante.
• Implémenter l’alternative à pointeur unique comme une cible de glisser-déposer elle-même — par exemple, créer une zone « déposer ici » qui nécessite toujours un glissement pour être utilisée — plutôt qu’un modèle d’interaction réellement différent, comme un bouton ou un champ de texte.
• Oublier de tester les alternatives sur l’ensemble de la plage de valeurs d’un composant glissable. Un curseur qui permet aux utilisateurs de cliquer uniquement sur quelques positions prédéfinies sur la piste, mais pas sur n’importe quelle position arbitraire, ne fournit pas une alternative complète si la version avec glissement prend en charge des valeurs continues.

Lien avec la réglementation d’accessibilité de la Turquie

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit un cadre national complet d’accessibilité pour les services numériques. La circulaire exige que les entités concernées se conforment aux Web Content Accessibility Guidelines et fait spécifiquement référence à la conformité de niveau AA comme norme pour obtenir le Erişilebilirlik Logosu (Logo d’accessibilité), la marque de certification officielle délivrée par le ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.5.7, en tant que critère de niveau AA introduit dans WCAG 2.2, entre dans le champ des exigences nécessaires pour obtenir et maintenir le Logo d’accessibilité. Pour les organisations qui s’appuient sur des interactions de glisser-déposer — telles que les plateformes de commerce électronique avec des curseurs de filtrage de produits ou des listes de souhaits triables, les applications bancaires avec des tableaux de bord de gestion de portefeuille, ou les outils de réservation d’agences de voyage avec des sélecteurs de plages de dates — le non-respect de 2.5.7 constituerait un obstacle direct à la certification.

Les entités couvertes par la Circulaire présidentielle 2025/10 incluent un large pan de l’économie numérique turque : les institutions publiques et organismes gouvernementaux aux niveaux central et local ; les banques et prestataires de services financiers réglementés par l’Agence de régulation et de supervision bancaire (BDDK) ; les plateformes de commerce électronique opérant en Turquie ; les hôpitaux et prestataires privés de services de santé ; les opérateurs de télécommunications comptant 200,000 abonnés ou plus ; les agences de voyage et entreprises de transport privé ; et les écoles privées autorisées par le ministère de l’Éducation nationale (Milli Eğitim Bakanlığı — MoNE).

Pour ces organisations, ne pas fournir d’alternatives à pointeur unique aux interactions de glissement n’est pas seulement une lacune technique — c’est un écart de conformité qui peut empêcher la certification, exposer l’organisation à un examen réglementaire et exclure un segment significatif d’utilisateurs ayant des déficiences motrices. Les statistiques sur le handicap en Turquie reflètent les tendances mondiales : des millions de résidents vivent avec des affections affectant la motricité fine, et les services numériques qui reposent exclusivement sur des gestes de glissement érigent des barrières inutiles pour cette population.

Concrètement, les organisations qui visent l’Erişilebilirlik Logosu devraient inclure WCAG 2.5.7 dans leurs listes de contrôle d’audit d’accessibilité, s’assurer que tous les composants interactifs construits avec des fonctionnalités de glissement sont examinés pour vérifier l’existence d’alternatives conformes, et documenter leurs décisions de conformité — y compris toute invocation de l’exception d’essentialité — dans le cadre de leur Déclaration d’accessibilité (Erişilebilirlik Beyanı), que la circulaire exige des entités concernées qu’elles publient et maintiennent à jour.