Que se passe-t-il exactement, pour un lecteur d’écran, entre le moment où l’utilisateur clique sur un lien de filtrage dans une liste d’articles WordPress et celui où le nouveau contenu apparaît à l’écran, animé par un fondu enchaîné ? Rien, si personne n’a pris soin de gérer explicitement le focus et l’annonce. La View Transitions API répond à une préoccupation purement visuelle : elle capture l’état avant et après une mise à jour du DOM, puis anime le passage de l’un à l’autre grâce à des pseudo-éléments dédiés comme ::view-transition-old et ::view-transition-new. Elle ne touche à rien d’autre.
Chrome 111 a introduit cette API pour les transitions internes à un document (« same-document »), c’est-à-dire les mises à jour effectuées en JavaScript sans rechargement de page, typiquement dans une interface d’administration ou un filtre AJAX. C’est ce périmètre, disponible dès à présent, qui intéresse un développeur de thème ou de plugin WordPress aujourd’hui : les transitions entre deux documents distincts, elles, restent expérimentales derrière un indicateur de fonctionnalité et ne doivent pas être présentées comme utilisables en production.
Ce que l’API modifie réellement
La méthode document.startViewTransition() prend en paramètre une fonction de rappel qui effectue la mise à jour du DOM. Le navigateur s’occupe de photographier l’ancien état, d’exécuter la mise à jour, puis d’animer la différence :
document.startViewTransition(() => {
liste.innerHTML = nouveauContenuFiltre;
});
Ce code remplace le contenu d’une liste et laisse le navigateur produire un fondu par défaut. Aucune ligne ici ne modifie le focus clavier, n’appelle une zone aria-live, ni ne change le titre du document. L’API a été conçue comme une couche purement esthétique, volontairement indépendante de la sémantique du contenu.
Ce que perd un lecteur d’écran
Un lecteur d’écran restitue le contenu à partir de l’arbre d’accessibilité, pas à partir du rendu visuel animé. Si le focus clavier reste positionné sur le lien de filtre après le clic, l’utilisateur de NVDA ou de VoiceOver continue d’entendre l’environnement du lien qu’il vient d’activer, sans savoir que la liste en dessous a été remplacée. L’animation, aussi soignée soit-elle, ne produit aucune annonce : elle est invisible pour l’API d’accessibilité du système d’exploitation, qui ne s’intéresse pas aux pseudo-éléments CSS de transition.
Le risque grandit avec les transitions entre documents, où l’attrait visuel (un site qui « ressemble à une application ») peut faire oublier que le changement d’URL implique normalement un rafraîchissement complet du contexte pour les technologies d’assistance : nouveau titre de document, nouvel arbre d’accessibilité, focus replacé en haut de page par le navigateur. Une transition animée mal outillée peut donner l’illusion d’une continuité alors que le contexte réel a changé du tout au tout.
Reprendre la main sur le focus et l’annonce
La solution ne vient pas de la View Transitions API elle-même, mais des mécanismes classiques qu’il faut continuer d’appeler explicitement autour d’elle :
- Déplacer le focus vers le titre du nouveau contenu après la mise à jour, avec
tabindex="-1"et un appel à.focus() - Mettre à jour
document.titlepour refléter le nouveau contexte, même en navigation interne au document - Prévoir une région
aria-live="polite"qui annonce le nombre de résultats ou le nom de la nouvelle vue - Ne jamais supposer qu’une transition animée dispense de la gestion habituelle du focus après mise à jour du DOM
Un exemple concret dans un thème
Sur un thème de blog qui filtre ses articles par catégorie en AJAX, la bonne séquence associe transition visuelle et gestion explicite du contexte :
function afficherCategorie(nom) {
document.startViewTransition(() => {
liste.innerHTML = construireListe(nom);
titre.textContent = "Articles : " + nom;
titre.focus();
});
regionLive.textContent = construireListe(nom).length + " articles trouvés";
}
Le focus posé sur le titre de section donne un point d’ancrage clair au lecteur d’écran, indépendamment de ce que fait visuellement la transition. C’est cette ligne, et non l’animation, qui restaure le repère perdu.
Nous traitons systématiquement la View Transitions API comme une couche de style : elle s’ajoute par-dessus une gestion de focus déjà correcte, elle ne la remplace jamais.
Pour aller plus loin
La View Transitions API rend les interfaces plus agréables sans rien garantir sur le plan de l’accessibilité : elle est muette pour les technologies d’assistance. Tant que la spécification ne prévoit pas de mécanisme d’annonce dédié, la responsabilité du contexte reste entièrement entre les mains du développeur, exactement comme pour n’importe quelle mise à jour dynamique de contenu. La documentation du Window object sur developer.mozilla.org détaille le comportement précis de startViewTransition() et mérite une lecture attentive avant toute intégration dans un thème WordPress interactif.
