Que sont les troubles déclenchés par le mouvement dans les logiciels ?

Que sont les troubles déclenchés par le mouvement dans les logiciels ?

« Troubles déclenchés par le mouvement » n'est pas un terme des WCAG. L'expression désigne des personnes chez qui le mouvement provoque des symptômes ou des erreurs : troubles vestibulaires (vertiges, nausées, maux de tête dus aux animations), crises photosensibles dues aux flashs et troubles moteurs comme le tremblement, où secouer ou incliner l'appareil déclenche une action par inadvertance. Une bonne conception limite le mouvement, permet de le désactiver et n'en fait jamais l'unique moyen d'agir.

Trois groupes, trois risques différents

• Troubles vestibulaires. Selon le W3C, les réactions comprennent vertiges, nausées et maux de tête, et peuvent être sévères. MDN cite la mise à l'échelle ou le défilement de grands objets comme déclencheurs typiques. Parallaxe, zooms animés et défilement automatique sont les coupables habituels.
• Crises photosensibles. Le déclencheur est le clignotement rapide, pas le mouvement en soi. Le critère WCAG 2.3.1 (niveau A) interdit qu'une page clignote plus de trois fois par seconde, sauf si les flashs restent sous les seuils de flash général et de flash rouge.
• Troubles moteurs. Les personnes ayant un tremblement peuvent déclencher sans le vouloir des fonctions de secousse ou d'inclinaison, et certaines ne peuvent pas faire le geste. Les gestes à trajectoire ou à plusieurs doigts et les cibles tactiles minuscules posent des problèmes voisins.

Ce qu'exigent les WCAG 2.2

• 2.3.1 Pas plus de trois flashs ou sous le seuil (A) : aucun contenu ne clignote plus de trois fois par seconde au-dessus des seuils.
• 2.2.2 Mettre en pause, arrêter, masquer (A) : un contenu en mouvement, clignotant ou défilant qui démarre seul, dure plus de cinq secondes et côtoie d'autres contenus doit pouvoir être mis en pause, arrêté ou masqué.
• 2.3.3 Animation découlant des interactions (AAA) : l'animation de mouvement déclenchée par une interaction peut être désactivée, sauf si elle est essentielle. C'est l'exigence la plus stricte, que beaucoup d'équipes prennent comme objectif.
• 2.5.4 Activation par le mouvement (A) : ce qui se fait en secouant ou en inclinant doit aussi se faire avec une commande classique, et la réaction au mouvement peut être désactivée. Exception si le mouvement est essentiel, comme pour un podomètre.
• 2.5.1 Gestes du pointeur (A) : les gestes multipoints ou à trajectoire demandent une alternative à un seul pointeur, sauf si le geste est essentiel, comme une signature.
• 2.5.8 Taille de la cible, minimum (AA) : les cibles du pointeur font au moins 24 sur 24 pixels CSS, avec des exceptions comme l'espacement et les liens dans un texte.

Le cadre général est présenté dans WCAG ; pour la vidéo et l'audio, voir les types de médias accessibles.

Comment le mettre en œuvre

Respectez le réglage du système avec la media query prefers-reduced-motion. MDN la décrit comme le moyen d'indiquer au navigateur que l'utilisateur préfère une interface qui supprime, réduit ou remplace les animations fondées sur le mouvement :

.hero { animation: slide-in 600ms ease-out; }
@media (prefers-reduced-motion: reduce) {
  .hero { animation: none; }
}

Ajoutez aussi un interrupteur dans l'application pour ceux qui n'accèdent pas au réglage du système, ne lancez pas de vidéo en boucle sans bouton de pause, donnez un bouton visible à chaque geste de secousse ou d'inclinaison et remplacez le mouvement par un fondu plutôt que de supprimer tout retour visuel.

Erreurs fréquentes

• Respecter « réduire les animations » en CSS mais oublier les animations en JavaScript, les carrousels et les vidéos à lecture automatique.
• Supprimer tout retour visuel au lieu de remplacer un grand mouvement par un mouvement doux.
• « Secouer pour annuler » sans bouton Annuler.
• Croire qu'un scan automatique réussi prouve que la page est sûre. Un outil ne peut pas juger si une animation donne le vertige.

Tester et surveiller

Activez « réduire les animations » dans le système ou les outils de développement du navigateur et parcourez les parcours clés à la main, par exemple dans vos tests manuels d'accessibilité. Les tests d'accessibilité automatisés ne montrent qu'une partie du tableau : gardez-les comme alarme de régression. Les animations lourdes coûtent aussi en performance : la surveillance de la vitesse des pages de LoadFocus lance des audits Lighthouse planifiés, vous voyez donc quand un nouvel effet ralentit la page. Ce que les contrôles automatiques peuvent et ne peuvent pas dire est détaillé dans cet article sur les tests de performance et l'accessibilité.

Questions fréquentes : troubles déclenchés par le mouvement

« Trouble déclenché par le mouvement » est-il un terme officiel d'accessibilité ?

Non. Les WCAG parlent de critères précis comme les flashs, l'animation découlant des interactions et l'activation par le mouvement. L'expression est un terme pratique pour les troubles que ces critères protègent.

Qu'est-ce que prefers-reduced-motion ?

Une fonctionnalité média CSS qui indique si l'utilisateur a demandé à son appareil de réduire les animations. On l'utilise pour supprimer ou adoucir les animations pour ces personnes.

Un flash, est-ce la même chose qu'une animation ?

Non. Un flash est un changement rapide de luminosité et peut déclencher des crises, c'est pourquoi le critère 2.3.1 le limite dès le niveau A. L'animation découlant des interactions est un autre sujet, surtout pour les troubles vestibulaires.

Dois-je éviter toute animation ?

Non. Les petites transitions utiles conviennent. Évitez les grands zooms, défilements et effets de parallaxe pour ceux qui demandent moins de mouvement, et proposez une pause pour les contenus qui se lancent seuls.

Un outil automatique peut-il détecter ces problèmes ?

En partie seulement, et pas le fait qu'une animation soit inconfortable. Vérifiez à la main avec la réduction des animations activée.