L’Interactivity API de WordPress 6.5 et son impact sur l’accessibilité des blocs

WordPress 6.5, sorti en avril 2024, introduit l’Interactivity API, une nouvelle façon standardisée d’ajouter de l’interactivité côté client aux blocs Gutenberg, sans que chaque plugin ou thème ne réinvente son propre système de gestion d’état en JavaScript. Ce billet ne traite pas de son usage dans un contexte e-commerce spécifique, abordé ailleurs, mais explique ce qu’est cette API, comment elle fonctionne en interne, et surtout ce qu’elle change — et ne change pas automatiquement — pour l’accessibilité des blocs qui l’adoptent.

Définition : à quel problème répond l’Interactivity API

Avant WordPress 6.5, un bloc qui avait besoin d’interactivité côté client (un carrousel, un filtre, un compteur qui se met à jour) devait embarquer son propre script JavaScript, souvent avec sa propre façon de gérer l’état et le DOM, ce qui produisait des implémentations hétérogènes d’un plugin à l’autre, y compris sur des points sensibles pour l’accessibilité comme la gestion du focus. L’Interactivity API propose un modèle commun : un état partagé, des directives déclaratives posées directement dans le balisage HTML (data-wp-bind, data-wp-on, data-wp-context), et un moteur côté client qui les interprète pour mettre à jour le DOM sans recharger la page.

Fonctionnement interne

Concrètement, un bloc qui adopte l’Interactivity API déclare son état côté PHP (via wp_interactivity_state()) et son balisage côté rendu, en associant des directives aux éléments HTML plutôt que d’écrire du JavaScript impératif classique :

<div
  data-wp-interactive="mon-plugin"
  data-wp-context='{ "ouvert": false }'>
  <button
    data-wp-on--click="actions.basculerPanneau"
    data-wp-bind--aria-expanded="context.ouvert">
    Afficher les filtres
  </button>
  <div data-wp-bind--hidden="!context.ouvert">
    Contenu du panneau de filtres
  </div>
</div>

Le point notable, du point de vue de l’accessibilité, est que data-wp-bind--aria-expanded permet de lier directement un attribut ARIA à l’état du bloc, sans code JavaScript supplémentaire pour le maintenir synchronisé. C’est un progrès réel par rapport à des implémentations artisanales où l’attribut aria-expanded était parfois mis à jour dans une fonction, oublié dans une autre, ou simplement absent.

Cas d’usage : un panneau de filtres déclaratif

L’exemple ci-dessus illustre un cas d’usage courant : un bouton qui ouvre et ferme un panneau, avec l’état aria-expanded qui suit automatiquement l’état ouvert du contexte. Sans l’Interactivity API, ce même comportement demandait généralement d’écrire à la main la logique de bascule et de synchronisation de l’attribut ARIA à chaque interaction ; avec l’API, cette synchronisation est déclarative et moins sujette à l’oubli.

Pièges : ce que l’API ne fait toujours pas à votre place

Le risque, avec l’arrivée d’un nouvel outil standardisé, est de croire qu’il résout intrinsèquement les questions d’accessibilité. Ce n’est pas le cas, et plusieurs pièges restent entièrement à la charge du développeur du bloc :

• La gestion du focus reste manuelle : rien dans l’Interactivity API ne déplace automatiquement le focus vers un panneau qui s’ouvre, ni ne le restitue à la fermeture. Ces comportements doivent être ajoutés explicitement, généralement dans les fonctions d’action associées aux directives.
• Le choix du bon rôle ARIA reste une décision humaine : lier aria-expanded à un état est utile uniquement si l’élément qui porte cet attribut est bien un bouton ou un élément avec un rôle approprié, pas un simple <div> cliquable.
• Les annonces aria-live pour signaler un changement de contenu ne sont pas générées automatiquement par l’API : elles doivent être ajoutées comme n’importe quel autre élément du balisage, avec ses propres directives de liaison.

Ce que ça change concrètement pour les développeurs de blocs

L’Interactivity API réduit la quantité de code nécessaire pour synchroniser l’état visuel et les attributs ARIA d’un bloc, ce qui diminue mécaniquement le risque d’oubli sur ce point précis. Elle ne remplace en revanche aucune des connaissances nécessaires en accessibilité : savoir quand un panneau doit recevoir le focus à l’ouverture, quel rôle ARIA convient à quel motif d’interface, et quand une annonce aria-live est nécessaire restent des décisions de conception que l’API se contente d’aider à implémenter proprement, sans jamais les prendre à la place du développeur.

En résumé

L’Interactivity API de WordPress 6.5 standardise la façon dont un bloc gère son état et son interactivité côté client, avec un bénéfice réel pour l’accessibilité : la liaison déclarative d’attributs comme aria-expanded réduit les oublis fréquents dans les implémentations artisanales. Elle ne dispense toutefois d’aucune des décisions de fond — gestion du focus, choix des rôles ARIA, annonces live — qui restent, comme avant, la responsabilité du développeur du bloc.