# WordPress 6.5 et l’Interactivity API : les nouveaux pièges d’accessibilité > « Bouton, non enfoncé » répété deux fois de suite : un symptôme apparu sur plusieurs blocs natifs migrés vers l'Interactivity API depuis sa stabilisation en avril 2024. - Auteur : WordPress Développement - Publié le : 2024-11-14 - Mis à jour le : 2024-11-14 - Catégorie : Accessibilité - URL : https://www.wpmoderne.fr/accessibilite/wordpress-65-interactivity-api-nouveaux-pieges-accessibilite/ ## L’essentiel - L'hydratation côté client peut faire annoncer un contrôle deux fois - data-wp-bind mal ciblé casse l'état exposé aux lecteurs d'écran - Les blocs natifs migrés n'ont pas tous été audités au même niveau « Bouton, non enfoncé. Bouton, non enfoncé. » Ce message, répété deux fois de suite par VoiceOver sur un simple bouton d'ouverture de sous-menu, est le symptôme qui a alerté plusieurs équipes de thème après la sortie de WordPress 6.5 en avril 2024 et la stabilisation de l'Interactivity API. Le bouton fonctionnait visuellement sans aucun défaut apparent. Le problème se situait entièrement côté technologies d'assistance, invisible sans un test manuel. WordPress 6.5 a marqué le passage de l'Interactivity API du statut de proposition expérimentale à celui d'API stable, avec la migration de plusieurs blocs natifs vers ce nouveau mécanisme d'hydratation : la navigation, la recherche, certains éléments du bloc Requête. Cette migration a apporté des gains réels de performance et d'interactivité, mais elle a aussi révélé des pièges d'accessibilité propres à ce nouveau mode de fonctionnement, absents de l'ancien système basé sur des scripts indépendants. ## Impact majeur : la double annonce liée à l'hydratation Le piège le plus documenté concerne l'hydratation elle-même : le processus par lequel un balisage HTML rendu côté serveur devient interactif côté client, une fois le JavaScript du store chargé. Sur certains blocs natifs migrés, le rendu serveur initial du bouton portait déjà un état ARIA (`aria-expanded="false"`), et l'hydratation côté client réappliquait ce même état au montage du composant, déclenchant une seconde annonce identique à la première pour certains lecteurs d'écran, notamment VoiceOver sur Safari. ``` ``` La correction appliquée par le noyau a consisté à s'assurer que la valeur bindée côté client, au montage, corresponde strictement à l'attribut déjà présent dans le rendu serveur, sans réécriture systématique de l'attribut si sa valeur ne change pas réellement. Pour un développeur de bloc personnalisé migrant vers cette API, la leçon à retenir est directe : vérifier que `state.menuOuvert` est initialisé avec la même valeur que celle rendue côté serveur, faute de quoi une réécriture inutile de l'attribut ARIA se produit au chargement. ## Impact moyen : des directives data-wp-bind mal ciblées > L'essentiel à retenir : L'hydratation côté client peut faire annoncer un contrôle deux fois ; data-wp-bind mal ciblé casse l'état exposé aux lecteurs d'écran ; Les blocs natifs migrés n'ont pas tous été audités au même niveau Le second piège concerne un usage trop large de `data-wp-bind--*` sur des attributs qui ne devraient changer que rarement. Un bloc Requête personnalisé, observé sur un projet migré peu après la sortie de WordPress 6.5, liait dynamiquement l'attribut `role` d'un conteneur de résultats à une valeur du store, dans l'intention de basculer entre `role="list"` et `role="region"` selon le mode d'affichage choisi par l'utilisateur. Le problème : ce changement de rôle intervenait après le montage initial du composant, une fois l'utilisateur ayant déjà commencé à naviguer dans la liste avec un lecteur d'écran. Changer le rôle ARIA d'un conteneur en cours de navigation casse la structure que le lecteur d'écran a déjà mémorisée, obligeant l'utilisateur à recommencer son exploration depuis le début. - Éviter de lier dynamiquement un rôle ARIA structurel après le montage initial du composant. - Réserver `data-wp-bind` aux attributs d'état (`aria-expanded`, `aria-pressed`, `aria-selected`), pas aux attributs de structure (`role`). - Si le mode d'affichage change réellement la structure sémantique, remonter le composant entier plutôt que de faire varier son rôle en place. ## Impact mineur : des blocs natifs inégalement audités Le troisième point, plus discret, concerne l'inégalité de traitement entre les blocs natifs migrés dès la sortie de WordPress 6.5. La documentation de développement (developer.wordpress.org) précisait que la migration vers l'Interactivity API concernait en priorité les blocs à fort trafic (navigation, recherche), avec un audit d'accessibilité manuel documenté pour chacun. Un examen des tickets de suivi montre que trois blocs natifs parmi les premiers migrés ont fait l'objet d'un correctif d'accessibilité dans les semaines suivant leur sortie, révélant que l'audit initial n'avait pas couvert tous les scénarios d'usage clavier. ### Ce que cela signifie pour un thème personnalisé Pour un développeur de thème qui étend ou surcharge ces blocs natifs, la prudence recommandée est de ne pas considérer un bloc natif migré comme automatiquement exempt de défaut d'accessibilité, y compris venant du noyau lui-même. Un test manuel au clavier et au lecteur d'écran reste nécessaire après chaque montée de version majeure touchant ces blocs, exactement comme pour un composant personnalisé. > Sur nos projets, chaque migration de bloc vers l'Interactivity API déclenche désormais un test VoiceOver et un test clavier avant fusion, quelle que soit l'origine du bloc, natif ou personnalisé. ## Vérifier son propre thème après la migration Un contrôle simple, réplicable sur n'importe quel projet : ouvrir chaque bloc interactif migré avec VoiceOver activé, déclencher l'interaction (ouverture de menu, changement de filtre), et écouter si l'annonce se produit une seule fois, avec un contenu cohérent avec l'état réel affiché à l'écran. Toute répétition ou tout silence mérite d'être creusé avant la mise en production. ## En résumé La stabilisation de l'Interactivity API dans WordPress 6.5 a apporté un vrai progrès de performance, mais elle introduit une catégorie de bugs d'accessibilité propre à l'hydratation côté client, absente des anciens mécanismes basés sur des scripts indépendants. Ces bugs ne se voient pas à l'écran : seul un test avec un lecteur d'écran les révèle, ce qui justifie de l'intégrer systématiquement à la recette de tout bloc migré vers cette API.