Séparer l’arrivée à destination et l’effet visuel
Pour vérifier une transition entre deux pages, séparez deux questions : la navigation fonctionne-t-elle, et l’animation respecte-t-elle le scénario prévu ? Exécutez le même parcours avec puis sans préférence de mouvement réduit, au clavier et avec le retour arrière. Notez les résultats sans injecter de code ni modifier le site de production.
Trois repères à garder en tête
- MDN définit la View Transition API comme un mécanisme d’animation des changements de vue, dans une page ou entre plusieurs documents. Ici, retenez seulement la navigation entre documents.
- Le critère WCAG 2.3.3, de niveau AAA, vise la désactivation des animations de mouvement non essentielles déclenchées par une interaction.
- La technique C39 décrit une implémentation CSS possible pour satisfaire ce critère. Les techniques WCAG restent facultatives.
Ces repères ne remplacent pas une évaluation complète de l’accessibilité. La recette ci-dessous sert uniquement à examiner un parcours précis sur un site existant.
Préparer un scénario vérifiable
Choisissez une page de départ, une action et une destination attendue. Le focus est le repère de l’élément actif au clavier. Définissez avant le test :
- l’URL ou le contenu qui doit être atteint ;
- l’intitulé de l’action utilisée ;
- l’élément qui devrait recevoir le focus après l’arrivée, si cette attente est documentée ;
- le comportement attendu du bouton Retour ;
- la présence attendue, réduite ou absente de l’effet visuel.
Conservez appareil, navigateur, fenêtre et zoom pendant une série. Relevez leurs versions et réglages ; chaque autre configuration ouvre une nouvelle ligne du journal.
Exécuter la recette
- Ouvrez directement la page de départ dans une session propre et relevez son URL, son titre visible et l’action à tester.
- Sans demander de réduction du mouvement, activez le lien ou le bouton. Vérifiez d’abord la destination : URL, contenu principal et possibilité de poursuivre le parcours. Observez ensuite seulement la transition.
- Essayez Retour, puis Avancer. Relevez les pages atteintes et comparez leur état aux attentes du scénario. L’action initiale doit rester accessible selon le parcours prévu.
- Recommencez entièrement au clavier. Utilisez au besoin le protocole détaillé pour tester la navigation au clavier. Notez l’ordre de tabulation, la visibilité du focus et l’activation effective.
- Activez la préférence de réduction du mouvement dans l’environnement de test, puis relancez le même parcours depuis son début. Ne changez aucun autre paramètre.
- Comparez les deux passages. Une animation raccourcie, remplacée ou absente n’est pas automatiquement une anomalie : la navigation doit rester votre premier critère.
- Répétez le retour arrière au clavier. Si le parcours concerne une interface étroite, ouvrez une série distincte fondée sur le guide de navigation mobile accessible.
Exemple fictif
Exemple fictif : « Voir la fiche » mène du catalogue à une fiche produit. Le scénario prévoit un fondu ordinaire et aucun effet avec mouvement réduit ; Retour ramène au catalogue. Ce sont des attentes illustratives, aucun résultat observé.
Distinguer panne de navigation et animation absente
Traitez d’abord les indices fonctionnels. Si l’action ne répond pas, ouvre le mauvais contenu, empêche de poursuivre ou rend le retour incohérent, classez l’écart comme défaut de navigation potentiel. Vérifiez-le une seconde fois sans vous fier à l’effet visuel.
Si la bonne destination apparaît et reste utilisable, mais sans mouvement visible, classez d’abord le constat comme « animation absente ou non perceptible ». Comparez alors les deux préférences et les attentes du scénario. Ne concluez pas à une panne uniquement parce qu’aucun effet ne s’affiche.
Isoler une navigation sans effet
Le mouvement réduit ne démontre pas, à lui seul, l’absence de tout effet. Pour isoler cette condition, demandez une préversion dont les transitions visuelles du parcours sont désactivées. Rejouez les mêmes actions et comparez les destinations et la suite de la tâche. Sans cette préversion, inscrivez « repli sans effet non testé ».
Ne confondez pas cette condition avec un essai sans JavaScript. Si vous réalisez aussi ce dernier, consignez son résultat séparément.
Journal vierge
| Scénario | Environnement | Préférence | Action | Résultat attendu | Résultat observé à remplir | Décision |
|---|---|---|---|---|---|---|
Prendre une décision
Choisissez : conforme au scénario, écart à analyser ou non concluant. Retenez ce dernier état si des paramètres ont changé ou si vos attentes étaient indéfinies.
Documentez séparément tout nouvel environnement. Cette recette ne démontre ni la compatibilité générale entre navigateurs, ni les performances, ni la conformité complète aux WCAG.
Questions fréquentes
Une transition absente signifie-t-elle que la navigation est cassée ?
Non. Vérifiez d’abord que l’action mène à la bonne destination, que le contenu reste utilisable et que le retour fonctionne. L’absence d’animation doit être consignée séparément.
Faut-il modifier le CSS du site pour effectuer ce test ?
Les contrôles publics utilisent les préférences, le clavier et les commandes du navigateur. Pour isoler le repli sans effet, demandez une préversion dédiée ; ne modifiez pas la production.
Ce protocole suffit-il pour déclarer le site accessible ?
Non. Il examine un scénario limité de navigation et de mouvement. Une conclusion globale exige d’autres contrôles, notamment sur la structure, les contenus, les formulaires et les technologies d’assistance.
Sources
Documentation consultée lors de la relecture du 15 octobre 2026.