WCAG 2.5.4 : Activation par le mouvement

Ce que signifie cette règle

WCAG 2.5.4 — Actionnement par le mouvement traite d’un scénario spécifique mais de plus en plus courant dans les applications web modernes : une fonctionnalité déclenchée par le mouvement physique de l’appareil, comme secouer un smartphone, incliner un appareil ou faire un geste devant une caméra. Ce critère établit deux exigences parallèles qui doivent toutes deux être respectées pour être conforme.

Premièrement, toute fonctionnalité qui peut être actionnée par le mouvement de l’appareil ou de l’utilisateur doit également pouvoir être actionnée via un composant d’interface utilisateur — c’est‑à‑dire un bouton, un lien, un contrôle de formulaire ou un élément interactif similaire qui ne repose pas sur le mouvement. Cela garantit que les personnes qui ne peuvent pas effectuer, ou ne peuvent pas effectuer de manière fiable, des gestes physiques ne sont pas exclues de l’accès à cette fonctionnalité.

Deuxièmement, les utilisateurs doivent pouvoir désactiver la réponse au mouvement afin que les mouvements accidentels ou involontaires ne déclenchent pas d’actions non souhaitées. Cela protège les utilisateurs qui ont des tremblements ou d’autres troubles moteurs provoquant des mouvements involontaires de l’appareil, contre des perturbations constantes dues à un comportement inattendu de l’application.

Le critère s’applique à deux types de mouvement distincts : le mouvement de l’appareil, détecté par des capteurs tels que les accéléromètres et gyroscopes intégrés aux smartphones et tablettes (accessibles via des API comme DeviceMotionEvent et DeviceOrientationEvent), et le mouvement de l’utilisateur, détecté par des caméras ou d’autres capteurs d’entrée qui suivent les mouvements du corps ou les gestes plutôt que l’appareil lui‑même.

Une implémentation conforme fournit toute fonctionnalité déclenchée par le mouvement via un contrôle d’interface standard (un bouton, un lien ou équivalent), ET permet à l’utilisateur de désactiver la détection de mouvement s’il le souhaite. Une implémentation non conforme fournit soit un accès uniquement par le mouvement à une fonctionnalité sans contrôle d’interface alternatif, soit un alternatif mais sans possibilité de désactiver le déclencheur par mouvement, de sorte que les mouvements involontaires continuent de poser problème.

WCAG 2.5.4 définit deux exceptions importantes. L’actionnement par le mouvement est exempté si le mouvement est essentiel à la fonction et que le désactiver modifierait fondamentalement l’activité — par exemple, une application de fitness qui compte les pas, où le suivi du mouvement est l’objectif principal, ou un jeu explicitement conçu autour de mécaniques d’inclinaison. La deuxième exception s’applique lorsque le mouvement est utilisé pour actionner une fonctionnalité via une interface d’accessibilité prise en charge, ce qui signifie que les fonctionnalités d’accessibilité de la plateforme gèrent l’interaction par mouvement d’une manière que l’utilisateur contrôle de façon indépendante.

Pourquoi c’est important

Les obstacles liés à l’actionnement par le mouvement affectent de manière disproportionnée les personnes ayant des déficiences motrices et de mobilité, mais l’impact est plus large que ce que beaucoup de développeurs supposent au départ. Comprendre qui est affecté — et comment — aide les équipes à hiérarchiser correctement ce critère.

Les personnes ayant des troubles du tremblement — y compris le tremblement essentiel, la maladie de Parkinson et la sclérose en plaques — peuvent éprouver des mouvements involontaires constants ou intermittents des mains et des bras. Lorsqu’elles tiennent un smartphone, leur tremblement naturel suffit à déclencher de manière répétée et inattendue des boîtes de dialogue « secouer pour annuler », des actions de rafraîchissement ou d’autres fonctionnalités activées par le mouvement. L’Organisation mondiale de la Santé estime qu’environ 1,3 milliard de personnes dans le monde vivent avec une forme de handicap significatif, et les affections touchant la motricité fine comptent parmi les plus répandues dans tous les groupes d’âge.

Les personnes ayant une paralysie ou des différences de membres peuvent utiliser leurs appareils montés sur des fauteuils roulants ou des supports, ou utiliser des pointeurs de tête, le suivi oculaire ou des contacteurs pour interagir avec leurs appareils. Ces utilisateurs ne peuvent souvent pas secouer ou incliner un appareil du tout, rendant les fonctionnalités accessibles uniquement par le mouvement totalement inaccessibles. Si la seule façon d’annuler une saisie de texte dans une application web mobile est de secouer l’appareil, un utilisateur de fauteuil roulant avec un téléphone monté ne peut tout simplement pas accéder à cette fonctionnalité.

Les personnes âgées constituent un autre groupe fortement concerné. Les affections liées à l’âge, notamment la diminution de la force de préhension, l’arthrite et le tremblement essentiel, deviennent de plus en plus courantes avec l’âge, ce qui signifie qu’un segment croissant de la population — qui est également de plus en plus actif numériquement — peut avoir des difficultés avec des gestes de mouvement précis ou intentionnels.

Considérons un scénario concret du monde réel : un site de e‑commerce turc ajoute une fonctionnalité « secouer pour mélanger » qui affiche aux utilisateurs une recommandation de produit aléatoire lorsqu’ils secouent leur téléphone, rendant la navigation plus engageante. La fonctionnalité est amusante et originale, mais il n’existe aucun bouton équivalent pour déclencher le mélange, et aucun moyen de désactiver la détection de secousses. Un utilisateur atteint de la maladie de Parkinson qui visite ce site subit des activations de mélange constantes et incontrôlées, son tremblement naturel déclenchant le geste. Il ne peut pas naviguer calmement car la page ne cesse de passer à des produits aléatoires. Cet utilisateur est de fait exclu d’une expérience d’achat normale — et, au regard de la réglementation turque en matière d’accessibilité, il ne s’agit pas seulement d’un problème d’UX mais d’un manquement à la conformité légale.

Au‑delà de l’accès pour les personnes handicapées, la désactivation ou la fourniture d’alternatives aux fonctionnalités basées sur le mouvement améliore également l’expérience des utilisateurs dans des environnements où le mouvement de l’appareil est peu fiable — dans les transports publics, au bureau ou dans tout contexte où l’utilisateur ne peut pas déplacer librement son appareil.

Règles axe-core associées

WCAG 2.5.4 nécessite des tests manuels car les outils automatisés ne peuvent pas détecter de manière fiable la présence ou l’absence de fonctionnalités basées sur le mouvement en analysant uniquement le HTML et le CSS statiques. L’actionnement par le mouvement dépend des écouteurs d’événements JavaScript et du comportement à l’exécution, que les analyseurs automatisés ne peuvent pas introspecter complètement. Ce qui suit explique pourquoi l’automatisation est insuffisante et ce que l’évaluation manuelle doit couvrir.

• Il n’existe aucune règle automatisée axe-core directe pour 2.5.4. Axe-core et des moteurs automatisés similaires fonctionnent en inspectant le DOM, les attributs ARIA et les styles calculés. Ils ne peuvent pas observer si une page a enregistré un écouteur d’événement devicemotion ou deviceorientation, ni déterminer si un contrôle d’interface équivalent existe pour une fonctionnalité déclenchée par le mouvement. Une page peut avoir une interactivité étendue basée sur le mouvement sans aucun indicateur visible dans le DOM, rendant la détection automatisée fondamentalement peu fiable. Axe-core signale donc ce critère comme nécessitant un examen manuel plutôt que de tenter une détection automatisée qui produirait des taux élevés de faux négatifs.
• Une inspection manuelle des écouteurs d’événements JavaScript est nécessaire. Les testeurs doivent utiliser les outils de développement du navigateur pour rechercher les enregistrements de DeviceMotionEvent, DeviceOrientationEvent et des API de caméra/vision telles que l’API Shape Detection. Le panneau Event Listeners dans les DevTools du navigateur peut révéler si ces événements sont attachés à l’objet window ou document.
• L’équivalence fonctionnelle ne peut pas être automatisée. Même si un outil pouvait détecter un écouteur de mouvement, il ne pourrait pas déterminer si un bouton ou un lien ailleurs dans l’interface fournit la même fonctionnalité. L’évaluation de l’équivalence fonctionnelle nécessite un testeur humain qui comprend les fonctionnalités de l’application et peut vérifier que chaque action déclenchée par le mouvement dispose d’une alternative d’interface utilisateur atteignable et actionnable.
• La possibilité de désactiver ne peut pas être automatisée. Déterminer si un utilisateur peut désactiver les réponses au mouvement nécessite d’interagir avec les paramètres ou préférences de l’application — un test comportemental que les outils automatisés ne sont pas conçus pour effectuer de manière exhaustive.

Comment tester

1. Analyse automatisée comme point de départ : Exécutez axe DevTools, Lighthouse ou le vérificateur d’accessibilité Accsible sur la page. Ces outils ne signaleront pas automatiquement les violations de 2.5.4, mais ils peuvent faire apparaître des problèmes connexes. Notez tous les éléments signalés, puis passez aux étapes manuelles. L’absence de signalement automatisé ne signifie pas que la page respecte 2.5.4.
2. Identifier les fonctionnalités déclenchées par le mouvement : Ouvrez Chrome DevTools et accédez au panneau Elements. Recherchez dans les fichiers source JavaScript de la page (en utilisant l’onglet Sources et la recherche globale avec Ctrl+Maj+F) les chaînes devicemotion, deviceorientation, accelerat, gyro et shake. Documentez chaque occurrence trouvée et la fonctionnalité associée.
3. Vérifier l’existence d’alternatives d’interface : Pour chaque fonctionnalité déclenchée par le mouvement découverte à l’étape précédente, tentez d’accomplir la même action en utilisant uniquement la navigation au clavier et les clics de souris — sans mouvement de l’appareil. Naviguez dans l’interface à l’aide de Tab, Entrée, Espace et des touches fléchées. Si vous ne trouvez pas de contrôle d’interface actionnable qui produise le même résultat, le critère n’est pas respecté.
4. Vérifier que le mouvement peut être désactivé : Recherchez un menu de paramètres, un panneau de préférences, des paramètres d’accessibilité ou un interrupteur spécifique pour les fonctionnalités basées sur le mouvement. Essayez de désactiver l’actionnement par le mouvement. Si aucun contrôle de ce type n’existe, ou si la désactivation du mouvement désactive également l’alternative d’interface, le critère n’est pas respecté.
5. Tests sur appareil physique : Chargez la page sur un smartphone ou une tablette réelle. Déplacez délibérément l’appareil doucement (en simulant un tremblement involontaire — petits mouvements continus) et observez si des fonctionnalités sont déclenchées involontairement. Puis effectuez le même test après avoir désactivé le mouvement via les paramètres disponibles.
6. Tests avec lecteur d’écran et clavier : En utilisant NVDA avec Firefox, VoiceOver avec Safari sur iOS ou JAWS avec Chrome, naviguez dans la page en utilisant uniquement le clavier et les commandes du lecteur d’écran. Confirmez que toute fonctionnalité accessible par le mouvement l’est également via la navigation du lecteur d’écran, et que le contrôle de désactivation du mouvement (s’il existe) est lui‑même accessible au clavier et correctement étiqueté.
7. Simulation d’appareil dans les DevTools du navigateur : Dans Chrome DevTools, ouvrez le panneau Sensors (More Tools > Sensors) et utilisez les contrôles de simulation d’orientation de l’appareil et d’accéléromètre pour déclencher des événements de mouvement de manière programmatique. Cela permet de tester sur ordinateur de bureau le comportement déclenché par le mouvement sans appareil physique.

Comment corriger

Secouer pour rafraîchir sans alternative — Incorrect

<!-- Motion listener attached, but no UI button provided to refresh -->
<script>
  window.addEventListener('devicemotion', function(event) {
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
</script>
<div id='content'>...page content...</div>

Secouer pour rafraîchir sans alternative — Correct

<!-- Motion alternative: a visible button provides the same refresh action.
     A settings toggle lets users disable the motion trigger entirely. -->
<div id='motion-controls'>
  <button type='button' id='refresh-btn' onclick='refreshContent()'>
    Refresh Content
  </button>
  <label>
    <input type='checkbox' id='disable-motion' onchange='toggleMotion(this.checked)' />
    Disable shake-to-refresh
  </label>
</div>
<div id='content'>...page content...</div>
<script>
  var motionEnabled = true;
  function toggleMotion(disabled) {
    motionEnabled = !disabled;
  }
  window.addEventListener('devicemotion', function(event) {
    if (!motionEnabled) return;
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
  function refreshContent() {
    // fetch and update content
  }
</script>

Carrousel à défilement par inclinaison sans option de désactivation — Incorrect

<!-- Carousel advances on device tilt; no way to turn this off -->
<div id='carousel'>
  <div class='slide'>Slide 1</div>
  <div class='slide'>Slide 2</div>
  <div class='slide'>Slide 3</div>
</div>
<script>
  window.addEventListener('deviceorientation', function(event) {
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Carrousel à défilement par inclinaison sans option de désactivation — Correct

<!-- Previous/Next buttons provide UI alternatives.
     A settings checkbox lets users opt out of tilt control.
     The carousel is also keyboard accessible via arrow keys. -->
<div id='carousel-wrapper'>
  <button type='button' aria-label='Previous slide' onclick='retreatCarousel()'>&laquo;</button>
  <div id='carousel' role='region' aria-label='Image carousel' aria-live='polite'>
    <div class='slide' aria-hidden='false'>Slide 1</div>
    <div class='slide' aria-hidden='true'>Slide 2</div>
    <div class='slide' aria-hidden='true'>Slide 3</div>
  </div>
  <button type='button' aria-label='Next slide' onclick='advanceCarousel()'>&raquo;</button>
</div>
<label>
  <input type='checkbox' id='disable-tilt' onchange='tiltEnabled = !this.checked' />
  Disable tilt navigation
</label>
<script>
  var tiltEnabled = true;
  window.addEventListener('deviceorientation', function(event) {
    if (!tiltEnabled) return;
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Fonctionnalité de geste devant la caméra sans alternative — Incorrect

<!-- User waves hand in front of camera to dismiss a modal;
     no button or keyboard method exists to dismiss it otherwise -->
<div id='modal' role='dialog' aria-modal='true' aria-label='Notification'>
  <p>Wave your hand to dismiss this message.</p>
</div>
<script>
  startCameraGestureDetection(function onWave() {
    document.getElementById('modal').hidden = true;
  });
</script>

Fonctionnalité de geste devant la caméra sans alternative — Correct

<!-- A clearly labeled close button provides the UI alternative.
     The modal is fully keyboard operable and focus is managed correctly. -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Notification</h2>
  <p>Wave your hand or press the button below to dismiss this message.</p>
  <button type='button' id='dismiss-btn' onclick='dismissModal()'>Dismiss</button>
</div>
<script>
  function dismissModal() {
    document.getElementById('modal').hidden = true;
    // return focus to triggering element
  }
  startCameraGestureDetection(dismissModal);
  // Allow Escape key to also dismiss
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') dismissModal();
  });
</script>

Erreurs courantes

• Fournir un bouton alternatif d’interface mais oublier l’interrupteur de désactivation du mouvement : De nombreux développeurs ajoutent un bouton équivalent mais n’implémentent jamais de moyen de désactiver l’écouteur de mouvement, laissant les utilisateurs affectés par des tremblements subir encore des activations non souhaitées, même si la fonctionnalité est techniquement actionnable par d’autres moyens.
• Cacher l’option de désactivation du mouvement dans un menu hamburger ou un sous‑menu de paramètres : Le contrôle permettant de désactiver le mouvement doit lui‑même être facilement atteignable. Si un utilisateur ayant un tremblement déclenche « secouer pour rafraîchir » à répétition avant de pouvoir naviguer cinq niveaux de menu pour le désactiver, l’option de désactivation n’est pas pratiquement accessible.
• Supposer que la préférence système « réduire les mouvements » satisfait à 2.5.4 : La media query prefers-reduced-motion et les paramètres d’accessibilité du système d’exploitation traitent des animations et des problèmes vestibulaires, mais ils ne désactivent pas automatiquement les écouteurs d’événements de mouvement de l’appareil dans les applications web. Vous devez gérer cela dans votre propre code.
• Définir des seuils de mouvement trop bas : Utiliser des seuils très sensibles pour les valeurs d’accélération de DeviceMotionEvent signifie que de légers tremblements involontaires peuvent dépasser le seuil. Les seuils doivent exiger un mouvement délibéré et de forte amplitude, et même dans ce cas une option de désactivation reste obligatoire.
• Enregistrer des écouteurs de mouvement globalement sur window sans jamais les supprimer : Attacher un écouteur et ne jamais prévoir de chemin de code pour le supprimer avec removeEventListener signifie que l’interrupteur de désactivation ne peut que supprimer le comportement de manière conditionnelle — si l’interrupteur lui‑même échoue ou se réinitialise au rechargement de la page, le mouvement reste actif.
• Rendre la case à cocher de désactivation du mouvement inaccessible : Implémenter l’interrupteur de désactivation sous forme de <div> ou de <span> stylé avec un écouteur de clic au lieu d’un véritable <input type='checkbox'> ou d’un contrôle amélioré par ARIA signifie que les utilisateurs de clavier et de lecteur d’écran ne peuvent pas atteindre ou actionner le contrôle même censé les aider.
• Ne pas conserver les préférences de mouvement de l’utilisateur entre les sessions : Si un utilisateur désactive l’actionnement par le mouvement mais que la préférence n’est pas enregistrée (par exemple via localStorage ou un paramètre de compte utilisateur), il doit la redésactiver à chaque visite, créant une charge répétée pour les utilisateurs les plus concernés.
• Appliquer trop largement l’exception de fonction essentielle : L’exception « essentielle » est étroite. Une galerie de produits qui utilise « secouer pour mélanger » n’est pas essentielle — la fonctionnalité de mélange n’est pas la fonction principale d’un site d’achat. Les équipes appliquent parfois mal cette exception pour éviter de faire le travail d’implémentation.
• Ne pas tester sur un véritable appareil physique avec un mouvement réel : Se fier uniquement aux outils de simulation sur ordinateur ou aux analyses automatisées signifie que les problèmes de sensibilité au mouvement dans le monde réel — y compris la façon dont la fonctionnalité se comporte lorsqu’un utilisateur a un tremblement naturel — ne sont jamais découverts avant que les utilisateurs ne les signalent.
• Oublier que les fonctionnalités de mouvement ajoutées par des SDK tiers ou des bibliothèques d’analytique doivent également être conformes : Les écouteurs de mouvement intégrés dans des widgets de chat tiers, des SDK de gamification ou des outils d’A/B testing font toujours partie de la responsabilité de conformité de la page. Si un script tiers enregistre un écouteur devicemotion sans fournir d’alternative, la page ne respecte pas 2.5.4.

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

La Circulaire présidentielle n° 2025/10 de la Turquie, publiée au Journal officiel (n° 32933) le 21 juin 2025, établit des exigences obligatoires en matière d’accessibilité web alignées sur WCAG 2.2. WCAG 2.5.4 Actionnement par le mouvement est un critère de niveau A, ce qui signifie qu’il se situe au niveau de priorité le plus élevé de la conformité obligatoire en vertu de cette circulaire.

La circulaire couvre un large éventail d’entités du secteur public et privé. Les institutions publiques — y compris tous les organismes gouvernementaux centraux et locaux, les ministères et les agences publiques — doivent atteindre une conformité complète de niveau A dans un délai de un an à compter de la publication de la circulaire. Les entités du secteur privé dans les catégories couvertes doivent atteindre la même norme dans un délai de deux ans. Les catégories du secteur privé couvertes comprennent les plateformes et places de marché de e‑commerce, les banques et institutions financières, les hôpitaux et prestataires de soins de santé privés, les entreprises de télécommunications comptant 200 000 abonnés ou plus, les agences de voyage agréées, les entreprises de transport privées et les écoles privées opérant sous autorisation du ministère de l’Éducation nationale (MoNE).

L’actionnement par le mouvement est particulièrement pertinent pour les services numériques turcs car l’utilisation d’Internet mobile en Turquie est très élevée, la majorité du trafic web provenant des smartphones. Les applications web mobile‑first et mobile‑only sont donc extrêmement courantes dans tous les secteurs couverts. Tout site de e‑commerce turc, application bancaire ou portail gouvernemental qui a implémenté des fonctionnalités de type secouer pour rafraîchir, navigation par inclinaison, interactions basées sur les gestes ou fonctionnalités similaires basées sur le mouvement sans fournir d’alternatives d’interface et de contrôles de désactivation est en violation directe d’une exigence obligatoire de niveau A en vertu de la Circulaire présidentielle 2025/10.

Pour les entités couvertes qui préparent des feuilles de route de conformité, l’actionnement par le mouvement doit être évalué dans le cadre d’un audit plus large de l’accessibilité mobile. Étant donné que les outils automatisés ne peuvent pas détecter les violations de 2.5.4, les organisations doivent inclure des tests manuels par des spécialistes de l’accessibilité qualifiés dans leur processus de vérification de la conformité. Étant donné que la circulaire n’inclut pas de période de grâce pour les fonctionnalités implémentées avant sa publication — seulement un calendrier pour atteindre la conformité — toute fonctionnalité basée sur le mouvement actuellement déployée sur les sites couverts doit être corrigée dans le délai applicable.

Les entités qui ne respectent pas les exigences de la circulaire peuvent faire l’objet de sanctions administratives et sont soumises à l’application par les autorités de supervision compétentes pour leur secteur. Au‑delà du risque réglementaire, la non‑conformité à 2.5.4 sur un site mobile turc à fort trafic représente un véritable échec d’utilisabilité pour des millions d’utilisateurs susceptibles de présenter des déficiences motrices, des tremblements ou d’utiliser des technologies d’assistance — une population dont les besoins sont explicitement reconnus et protégés par l’adoption, par la circulaire, de WCAG 2.2 niveau A comme norme de base.