Une animation peut rendre un changement d’état plus compréhensible, mais elle n’est pas indispensable à chaque interaction. Avant d’ajouter du mouvement, vérifiez que le contenu, les commandes et les messages restent utilisables sans cet effet.
Ce guide aide à cadrer une intervention sur un composant existant : choisir son rôle, préserver les informations, prévoir une version sans mouvement et contrôler le comportement obtenu. Il ne promet ni davantage de ventes ni un gain automatique de vitesse.
Choisir un mouvement qui explique une action
Commencez par une question précise : qu’est-ce que la personne doit comprendre ? L’ouverture d’un panneau, le changement d’un état ou l’attente d’une réponse sont des situations différentes. Une animation décorative répétée ne remplace pas un intitulé clair.
Exemple illustratif : la flèche d’un accordéon change d’orientation lorsque son contenu est ouvert. Le texte doit rester accessible si la flèche change instantanément. Cette proposition décrit un comportement à réaliser et à tester, pas un résultat observé chez un client.
Si le problème concerne plutôt l’organisation du parcours, le guide sur l’expérience utilisateur d’un site de services permet de reprendre les questions de contenu et d’orientation avant de travailler les effets.
Conserver le contenu et les commandes sans animation
Ne masquez pas un texte indispensable en attendant qu’un script déclenche son apparition. Une erreur de chargement ou un effet désactivé ne doit pas laisser une page vide. Définissez un état de départ utilisable et un état final explicite pour chaque composant.
Une transparence visuelle n’établit pas, à elle seule, qu’un élément est retiré du parcours clavier. Vérifiez les commandes des panneaux fermés, l’ordre du focus et le retour à la commande d’ouverture. Conservez un repère de focus visible ; le mouvement ne doit pas être le seul signal.
Sur un formulaire, distinguez clic, traitement en cours, erreur et réponse acceptée. Une coche animée ne prouve pas la réception d’une demande. Le message de réussite doit correspondre à la réponse du serveur, et le parcours doit rester compréhensible lorsqu’aucun mouvement n’est affiché.
Prévoir une version avec moins de mouvement
La préférence système peut être détectée avec la caractéristique média prefers-reduced-motion, documentée par MDN. Le réglage reduce demande de limiter les mouvements non essentiels ; son absence ne démontre pas que tous les effets conviennent à la personne.
Pour un panneau, prévoyez une ouverture directe sans déplacement décoratif. Conservez le contenu, l’état ouvert ou fermé et les commandes. Vérifiez aussi les mouvements lancés par JavaScript : réduire une transition CSS ne neutralise pas automatiquement toutes les animations d’une page.
Le critère WAI Animation from Interactions, de niveau AAA, concerne la possibilité de désactiver les mouvements non essentiels déclenchés par une interaction. Il ne faut pas le présenter comme une exigence AA ni confondre ce seul contrôle avec une conformité complète.
Donner le contrôle sur les mouvements automatiques
Un bandeau qui défile ou un carrousel qui avance seul demande une vérification distincte. Le critère WAI Pause, Stop, Hide, de niveau A, prévoit un moyen de pause, d’arrêt ou de masquage pour les informations en mouvement qui démarrent automatiquement, durent plus de cinq secondes et accompagnent d’autres contenus, sauf exception essentielle.
Les informations mises à jour automatiquement ont une condition distincte, sans cette exception de durée. Un arrêt qui exige de garder le focus ou la souris sur le composant ne permet pas nécessairement de continuer à utiliser le reste de la page.
Rejouez le contrôle avec le clavier et sur écran tactile. Arrêter un défilement ne suffit pas à vérifier les clignotements, les contrastes ou tous les autres critères d’accessibilité. Une animation courte n’est donc pas automatiquement acceptable.
Examiner le coût réel plutôt que promettre la fluidité
Le guide web.dev sur les animations CSS recommande notamment transform et opacity pour limiter les étapes de rendu, puis de contrôler le comportement dans les outils du navigateur. Il déconseille d’ajouter will-change préventivement partout : cette préparation peut avoir un coût.
Ces choix ne garantissent pas une animation fluide sur tous les appareils. Le nombre d’éléments, leur taille, les effets visuels et le travail effectué pendant l’interaction comptent aussi. Le choix entre CSS et JavaScript doit répondre au composant, pas à une supériorité universelle supposée.
Comparez le même parcours avec et sans effet, sur les appareils retenus. Consignez les ralentissements et les déplacements inattendus, puis examinez leur cause. Une observation locale n’est pas une mesure des visiteurs réels ni la preuve d’une hausse des conversions.
Recevoir une correction limitée et vérifiable
Préparez une liste de réception : état initial, activation au clavier et au toucher, fermeture, focus, préférence de mouvement réduit, interruption rapide et absence de contenu perdu. Pour un exemple de code, exécutez réellement les sélecteurs et les transitions dans le composant avant de le proposer comme réutilisable.
Le guide sur l’audit UX et les obstacles reproductibles aide à conserver les étapes et les réserves. Notez les navigateurs testés et ceux qui ne le sont pas, sans transformer quelques essais en certification générale.
Une intervention sur un site vitrine peut porter sur un menu ou un composant précis, en conservant la charte approuvée. Pour la cadrer, décrivez l’interaction qui pose problème. La correction livrée et ses contrôles doivent rester distincts d’une promesse de performance ou de résultat commercial.
