Six mots-clés : search-form, comment-form, comment-list, gallery, caption, script, style. C’est la liste complète des zones qu’un thème peut moderniser d’un seul coup grâce à add_theme_support('html5'), sans installer la moindre extension et sans réécrire de balisage à la main.
Avant cette fonctionnalité, les formulaires générés par les fonctions du cœur de WordPress produisaient un balisage hérité, avec des attributs de présentation directement dans le HTML et des tableaux utilisés pour la mise en forme des galeries. Voici comment activer un rendu propre pour un intégrateur qui construit un thème sur mesure.
La déclaration de base
Comme toutes les fonctionnalités de thème, l’appel se fait dans after_setup_theme, avec un tableau listant les zones concernées.
function monthème_setup() {
add_theme_support( 'html5', array(
'search-form',
'comment-form',
'comment-list',
'gallery',
'caption',
'script',
'style',
) );
}
add_action( 'after_setup_theme', 'monthème_setup' );
Chaque mot-clé active un rendu distinct pour la fonction correspondante du cœur : get_search_form(), comment_form(), wp_list_comments(), la fonction de rendu des galeries d’images, et la génération des légendes.
Ce que change search-form concrètement
Sans cette déclaration, get_search_form() produit un formulaire avec un attribut role="search" ajouté en surcouche mais un balisage globalement hérité. Avec la déclaration active, le formulaire généré utilise un <label> natif associé à l’entrée, un type d’entrée search plutôt qu’un simple text, ce qui bénéficie directement à l’accessibilité et à l’ergonomie mobile.
<form role="search" method="get" class="search-form" action="https://exemple.test/">
<label>
<span class="screen-reader-text">Rechercher :</span>
<input type="search" class="search-field" placeholder="Rechercher …" value="" name="s" />
</label>
<input type="submit" class="search-submit" value="Rechercher" />
</form>
Variante : ne moderniser qu’une partie
Il n’est pas obligatoire d’activer toutes les zones d’un coup. Un thème qui personnalise entièrement son propre formulaire de recherche par un filtre sur get_search_form peut se limiter aux zones qu’il ne réécrit pas lui-même.
- Ne déclarer que
comment-formetcomment-listsi le formulaire de recherche est entièrement personnalisé ailleurs. - Ajouter
styleetscriptpour que les balises générées par certains widgets utilisent un attribut moderne plutôt qu’un attribut de type obsolète. - Combiner avec un CSS ciblant les classes générées, comme
.comment-list, pour un rendu homogène avec le reste du thème.
Le cas particulier de comment-list
Cette zone modifie la structure produite par wp_list_comments(), qui passe d’une liste imbriquée avec des balises de définition à une structure <ol> et <li> plus conforme aux usages actuels. Attention toutefois : un thème qui personnalise déjà l’affichage des commentaires via un rappel (« callback ») personnalisé garde la main sur son propre balisage, la déclaration html5 ne s’applique qu’au rendu par défaut fourni par WordPress.
Sur un projet livré à un client peu technique qui personnalise parfois lui-même des blocs via l’éditeur, activer cette fonctionnalité en amont évite bien des balises dépréciées qui finissent par gêner un futur audit d’accessibilité.
Compatibilité avec les extensions de commentaires
Les extensions qui remplacent le système de commentaires natif, par exemple pour ajouter un système de notation, s’appuient en général sur les mêmes fonctions du cœur et respectent donc cette déclaration sans configuration supplémentaire. Il reste utile de vérifier le rendu après activation d’une telle extension, certaines surchargeant directement le balisage sans tenir compte des réglages du thème.
En résumé
Six mots-clés, un seul appel, et l’ensemble des formulaires générés par le cœur de WordPress adopte un balisage HTML5 natif plutôt qu’un rendu hérité. Cette fonctionnalité de thème, peu coûteuse à mettre en place, reste l’une des plus rentables pour un intégrateur soucieux de livrer un code propre sans réinventer les fonctions déjà fournies par WordPress.
