Sur un projet pour une entreprise de menuiserie, la question des icônes — un marteau pour l’atelier, une règle pour le sur-mesure, un cadenas pour la garantie — s’est posée en des termes très concrets : fallait-il coder chaque icône en dur dans les patterns, s’appuyer sur une technique de coloration dynamique via les presets du thème, ou construire un bloc dédié ? Nous avons testé les trois approches sur le même jeu de huit icônes, et voici ce qui en ressort, notamment côté accessibilité.
Ce comparatif porte sur les thèmes blocs WordPress ; il ne traite pas de l’intégration d’icônes dans Elementor via Font Awesome, un contexte technique différent avec ses propres contraintes.
Approche 1 : SVG inline directement dans un pattern
La méthode la plus directe consiste à coller le code SVG de l’icône directement dans le contenu HTML d’un pattern, à côté d’un bloc paragraphe.
<!-- wp:group {"className":"carte-service"} -->
<div class="wp-block-group carte-service">
<svg viewBox="0 0 24 24" width="32" height="32" aria-hidden="true" focusable="false">
<path d="M12 2 2 7l10 5 10-5-10-5Z"/>
</svg>
<!-- wp:paragraph -->
<p>Sur-mesure et conseil personnalisé</p>
<!-- /wp:paragraph -->
</div>
<!-- /wp:group -->Les attributs aria-hidden="true" et focusable="false" sont indispensables ici : sans eux, certains lecteurs d’écran annoncent l’icône comme une image sans description, et certains navigateurs la rendent focalisable au clavier sans aucune action associée, ce qui perturbe la navigation. Cette approche reste la plus simple à maintenir pour une équipe peu technique, mais chaque changement de couleur d’icône suppose de modifier le SVG dans chaque pattern qui l’utilise.
Approche 2 : CSS mask avec les presets du thème
Pour recolorer dynamiquement une icône selon la palette du thème — utile si le client change de variation de style — la technique du mask CSS s’avère plus flexible : l’icône est un fichier SVG externe utilisé comme masque, sa couleur réelle provenant alors du background-color de l’élément.
.icone-marteau {
width: 32px;
height: 32px;
background-color: var(--wp--preset--color--accent);
mask-image: url('../icons/marteau.svg');
mask-size: contain;
mask-repeat: no-repeat;
}
Cette méthode permet à l’icône de suivre automatiquement un changement de variation de couleur du thème, sans retoucher le fichier SVG lui-même. Le revers : l’élément qui porte le masque doit rester purement décoratif, avec un texte alternatif porté ailleurs (dans le texte visible du pattern), sous peine de perdre toute information pour les technologies d’assistance qui ne perçoivent pas un arrière-plan masqué comme du contenu.
Approche 3 : un petit bloc dédié
La troisième approche consiste à créer un bloc personnalisé simple, avec un attribut permettant de choisir l’icône dans une liste prédéfinie et un rendu PHP qui injecte le bon SVG avec les attributs d’accessibilité corrects par défaut.
register_block_type( __DIR__ . '/blocks/icone', array(
'render_callback' => function( $attributes ) {
$icone = sanitize_key( $attributes['icone'] ?? 'marteau' );
$chemin = get_theme_file_path( "assets/icons/{$icone}.svg" );
if ( ! file_exists( $chemin ) ) {
return '';
}
return sprintf(
'<span class="icone-bloc" aria-hidden="true">%s</span>',
file_get_contents( $chemin )
);
},
) );Cette approche demande le plus de code initial, mais offre le meilleur contrôle : validation de l’attribut d’icône, cohérence garantie des attributs d’accessibilité sur chaque usage, et possibilité d’ajouter facilement de nouvelles icônes au catalogue sans toucher aux patterns existants.
| Approche | Effort de mise en place | Recoloration dynamique | Contrôle accessibilité |
|---|---|---|---|
| SVG inline dans un pattern | Faible | Non | Manuel, à chaque usage |
| CSS mask sur presets | Moyen | Oui | Manuel, sur l’élément masqué |
| Bloc dédié | Élevé | Possible via variables CSS | Garanti par le code du bloc |
Quelle que soit l’approche choisie, ne laissez jamais un SVG décoratif sans
aria-hidden="true". C’est la ligne la plus facile à oublier, et celle qui a le plus d’impact réel pour les personnes qui naviguent au clavier ou avec un lecteur d’écran.
Notre choix sur ce projet
Pour la menuiserie, avec seulement huit icônes stables dans le temps et une équipe éditoriale peu technique, nous avons retenu l’approche du bloc dédié malgré son coût initial plus élevé : elle garantit qu’aucune future icône ajoutée par un développeur différent de nous n’oubliera les attributs d’accessibilité, un risque réel avec les deux approches plus légères sur un projet amené à évoluer sur plusieurs années.
En résumé
Aucune des trois approches n’est universellement supérieure : le SVG inline convient aux besoins ponctuels et stables, le CSS mask aux catalogues qui doivent suivre les variations de couleur du thème, et le bloc dédié aux projets de longue durée où la cohérence d’accessibilité doit être garantie structurellement plutôt que laissée à la vigilance de chaque intervenant.
