« La fonction wp_interactivity_state() permet de définir ou de récupérer l’état initial d’un magasin d’interactivité, disponible côté serveur comme côté client. » Cette phrase, tirée de la documentation officielle du Bloc Editor Handbook publiée au moment de la stabilisation de l’Interactivity API dans WordPress 6.5, résume une fonction en apparence technique mais dont les conséquences sur l’accessibilité méritent d’être détaillées, indépendamment des directives data-wp-* qui l’exploitent ensuite dans le DOM.
Avant l’Interactivity API, un bloc dynamique côté front reposait presque toujours sur un script qui interrogeait une API REST après le chargement de la page, puis injectait du contenu dans le DOM. Cette approche pose un problème d’accessibilité classique : le contenu initial rendu par PHP est souvent un état de chargement vide, et l’utilisateur de lecteur d’écran perçoit une page incomplète pendant une fraction de seconde, parfois plus longue sur une connexion lente.
Ce que change réellement wp_interactivity_state()
Avec cette fonction, l’état initial du composant est calculé côté serveur, au moment du rendu PHP du bloc, puis sérialisé dans une balise de script JSON associée au magasin d’interactivité. Le client JavaScript n’a donc plus besoin de recalculer cet état au chargement : il le lit directement depuis le HTML déjà présent.
<?php
wp_interactivity_state('mon-bloc/compteur-avis', array(
'nombreAvis' => get_field('nombre_avis'),
'moyenneAvis' => get_field('moyenne_avis'),
));
?>
<div data-wp-interactive="mon-bloc/compteur-avis">
<p><?php echo esc_html( get_field('moyenne_avis') ); ?> / 5</p>
</div>
Concrètement, le paragraphe affichant la moyenne des avis est déjà correct dans le HTML envoyé par le serveur, avant même que le JavaScript ne s’exécute. Un utilisateur qui coupe le JavaScript, ou dont le script met du temps à se charger, voit malgré tout une information juste et complète dès le premier rendu.
Ce que cette fonction ne fait pas
Il faut être précis sur un point : wp_interactivity_state() ne gère pas la mise à jour du contenu après une interaction utilisateur. Si un visiteur clique sur un bouton « Filtrer les avis 5 étoiles », c’est le magasin d’interactivité côté client qui recalcule un nouvel état et met à jour le DOM, via les directives associées au bloc. La fonction PHP ne concerne que l’amorçage initial, pas les mises à jour ultérieures.
Cette distinction a une conséquence directe pour l’accessibilité : le contenu affiché à l’ouverture de la page est fiable par construction, mais chaque mise à jour dynamique déclenchée ensuite reste sous la responsabilité du développeur du bloc, qui doit veiller à ce que le changement de contenu soit annoncé correctement aux technologies d’assistance, par exemple via une région aria-live associée au conteneur mis à jour.
Un cas concret : un bloc d’avis clients
Sur un bloc affichant une moyenne d’avis clients pour un site de vente de matériel de randonnée, l’état initial (nombre d’avis, moyenne, répartition par étoile) est entièrement calculé côté serveur avec wp_interactivity_state(). Un visiteur qui arrive sur la page voit immédiatement « 4,6 sur 5, 128 avis », sans attendre un appel réseau supplémentaire. Seul le filtre par nombre d’étoiles, activé après clic, déclenche une mise à jour côté client du magasin d’interactivité.
- Le rendu initial ne dépend plus de la rapidité du réseau du visiteur pour être correct.
- Les moteurs de recherche et les technologies d’assistance qui ne déclenchent pas JavaScript voient un contenu déjà complet.
- Seule la logique de filtrage, plus rarement utilisée, reste entièrement dépendante du client.
Pourquoi cette distinction compte pour l’audit
Un audit d’accessibilité qui se limite à couper le JavaScript pour vérifier la robustesse d’un site gagne en pertinence avec l’Interactivity API : la présence de wp_interactivity_state() dans le code d’un bloc indique généralement que son contenu de base restera lisible sans script, contrairement à un bloc qui se contente d’un conteneur vide rempli entièrement côté client.
Un état initial calculé côté serveur n’est pas un détail de performance : c’est la garantie qu’un contenu reste lisible avant même que le navigateur ait fini de télécharger le moindre script.
Pour aller plus loin
La fonction wp_interactivity_state() déplace une partie de la logique d’un bloc interactif vers le rendu serveur, ce qui profite directement à l’accessibilité en garantissant un contenu initial correct sans dépendance au JavaScript. Elle ne dispense cependant pas de vérifier, directive par directive, que les mises à jour déclenchées ensuite par l’utilisateur restent correctement annoncées : la robustesse du premier rendu ne présume rien de la qualité des interactions qui suivent.
