$html = str_replace('<div class="carrousel-slide"', '<div class="carrousel-slide" role="group" aria-roledescription="diapositive"', $html); — c’est ce genre de ligne qu’on retrouve encore dans certains filtres de rendu de bloc, et c’est exactement le genre de ligne qui casse dès qu’un attribut supplémentaire apparaît dans le balisage généré par un bloc carrousel tiers.
Depuis WordPress 6.2, la classe WP_HTML_Tag_Processor propose une alternative bien plus sûre : parcourir le HTML balise par balise et modifier précisément celle qu’on cible, sans reconstruire une chaîne de caractères à la main et sans charger un analyseur DOM complet côté serveur.
Le problème posé par la concaténation de chaînes
Un bloc carrousel, qu’il soit natif ou fourni par une extension, génère un balisage qui peut changer d’une version à l’autre : une classe CSS renommée, un attribut data-* ajouté, un ordre d’attributs différent. Un filtre basé sur str_replace ou une expression régulière suppose que ce balisage restera identique indéfiniment, ce qui n’est jamais garanti.
Le symptôme typique : le filtre fonctionne à l’installation, puis une mise à jour du bloc carrousel change légèrement sa structure HTML, et l’attribut ARIA censé être ajouté disparaît silencieusement, sans qu’aucune erreur ne remonte. C’est une régression d’accessibilité invisible dans les journaux d’erreurs habituels.
Utiliser WP_HTML_Tag_Processor pour cibler une balise précise
La classe fonctionne comme un curseur qui avance dans le HTML, balise après balise, et permet d’interroger ou de modifier les attributs de la balise courante sans toucher au reste du document :
function carrousel_ajouter_attributs_aria( $bloc_html ) {
$processeur = new WP_HTML_Tag_Processor( $bloc_html );
while ( $processeur->next_tag( array( 'class_name' => 'carrousel-slide' ) ) ) {
$processeur->set_attribute( 'role', 'group' );
$processeur->set_attribute( 'aria-roledescription', 'diapositive' );
}
return $processeur->get_updated_html();
}
Brancher le filtre sur le rendu du bloc
Ce traitement s’accroche naturellement au filtre render_block, qui reçoit le HTML final d’un bloc juste avant son affichage :
add_filter( 'render_block', function ( $contenu, $bloc ) {
if ( 'core/gallery' !== $bloc['blockName'] ) {
return $contenu;
}
return carrousel_ajouter_attributs_aria( $contenu );
}, 10, 2 );
Le filtre ne s’applique qu’au nom de bloc concerné, ce qui évite de parcourir inutilement le HTML des blocs sans rapport avec le carrousel.
Pourquoi ne pas simplement modifier le composant React du bloc
Quand le carrousel provient d’une extension tierce, son code source côté éditeur n’est pas toujours accessible à la modification, et le republier reviendrait à maintenir un correctif à chaque mise à jour de l’extension. Intervenir sur le rendu final, côté PHP, découple la correction d’accessibilité du code du bloc lui-même.
Ce que la classe apporte par rapport à un DOMDocument
- Aucun chargement d’extension PHP supplémentaire, contrairement à
DOMDocumentqui dépend de l’extensionlibxml; - Un comportement tolérant aux fragments de HTML incomplets, fréquents dans le rendu partiel d’un bloc ;
- Une API pensée pour des modifications ciblées (ajout, remplacement, suppression d’attribut), pas pour une réécriture complète du document.
Une limite à connaître avant de s’en servir partout
WP_HTML_Tag_Processor ne permet pas de naviguer dans l’arborescence (savoir qu’une balise est l’enfant d’une autre, par exemple) ; il avance de balise en balise, dans l’ordre du document. Pour des besoins de navigation hiérarchique plus fins, la classe WP_HTML_Processor, apparue plus tard dans le cœur de WordPress, répond à un besoin différent et sort du périmètre de cet article.
Modifier un attribut ARIA ne justifie pas de reconstruire tout le balisage d’un bloc : autant utiliser l’outil qui cible exactement l’attribut concerné.
En résumé
Pour ajouter un attribut ARIA à un carrousel généré par un bloc, qu’il soit natif ou tiers, WP_HTML_Tag_Processor évite la fragilité d’une concaténation de chaînes et le poids d’un analyseur DOM complet. Le filtre render_block reste le point d’accroche naturel, et la correction survit aux mises à jour du bloc carrousel tant que la classe CSS ciblée ne change pas radicalement de nom.
