La bêta de WordPress 6.6, actuellement en test avant sa sortie stable prévue en juillet, fait évoluer plusieurs comportements du bloc Requête, notamment autour des filtres personnalisés associés à une liste d’articles. Un changement de catégorie ou de tri, appliqué en JavaScript sans rechargement de page, pose une question simple mais souvent négligée : comment un utilisateur de lecteur d’écran sait-il que la liste vient de changer ?
Ce texte ne traite pas du maillage interne généré par ce type de liste, sujet SEO distinct, mais de l’annonce accessible du changement de contenu au moment où un visiteur applique un filtre sur une liste d’articles construite avec ce bloc.
Le comportement observé en bêta
Dans la configuration testée, un pattern associe le bloc Requête à un jeu de boutons de filtre par catégorie, mis à jour côté client sans rechargement complet. Visuellement, le changement est immédiat et fluide. Pour un lecteur d’écran, en revanche, rien ne signale que la liste vient de se transformer : l’utilisateur reste focalisé sur le bouton de filtre qu’il vient d’activer, sans indication du nombre de résultats obtenus ni de leur contenu.
Pourquoi une simple mise à jour visuelle ne suffit pas
Un changement de contenu qui n’est pas explicitement signalé aux technologies d’assistance reste invisible pour elles, même si le DOM a bel et bien changé. La solution consiste à envelopper la zone de résultats dans une région annoncée par aria-live="polite", présente dès le chargement initial de la page, et non ajoutée dynamiquement au moment du premier filtre.
<div aria-live="polite" aria-atomic="false">
<p class="resume-resultats">12 articles trouvés dans la catégorie « Accessibilité »</p>
<!-- wp:query -->
<!-- résultats du bloc Requête -->
<!-- /wp:query -->
</div>
Le point important, souvent source d’échec silencieux, tient à l’ordre d’exécution : la région aria-live doit exister dans le DOM avant le premier changement de contenu qu’elle est censée annoncer. Une région ajoutée dynamiquement en même temps que le nouveau contenu n’est généralement pas prise en compte par les lecteurs d’écran pour cette première annonce.
Adapter le texte annoncé, pas seulement activer la région live
Activer une région live sans texte informatif n’apporte rien : le message annoncé doit préciser le nombre de résultats obtenus et, si pertinent, le critère de filtre appliqué. Un simple « Contenu mis à jour » reste trop vague pour permettre à l’utilisateur de décider s’il doit explorer la nouvelle liste ou ajuster à nouveau son filtre.
- Annoncer le nombre de résultats après chaque changement de filtre
- Préciser le filtre actif dans le texte annoncé, pas seulement le nombre
- Garder la région live présente dès le rendu initial de la page
Tester ce comportement dès la phase de bêta
Profiter de la période de bêta pour tester ce type de pattern avec un lecteur d’écran réel permet de remonter un signalement à l’équipe du cœur logiciel avant la sortie stable, plutôt que de découvrir le défaut sur un site en production quelques semaines plus tard. Les canaux de retour de la bêta WordPress restent ouverts précisément dans ce but.
Vérifier aussi le focus après filtrage
Au-delà de l’annonce, vérifiez que le focus clavier reste sur le bouton de filtre activé après la mise à jour, plutôt que de sauter arbitrairement en tête de liste. Un focus perturbé après chaque interaction décourage rapidement une navigation au clavier prolongée sur une liste filtrable.
Une liste qui se met à jour instantanément à l’écran sans jamais rien annoncer reste, pour un lecteur d’écran, une liste figée depuis le premier chargement de la page.
En résumé
Le bloc Requête, tel que testé dans la bêta de WordPress 6.6, ne garantit pas par défaut l’annonce accessible d’un changement de filtre : ajoutez une région live présente dès le chargement initial, avec un texte informatif sur le nombre de résultats, et vérifiez la position du focus après chaque interaction avant la sortie stable.
