« Représente une partie du contenu de la page qui contient un formulaire ou une interface liée à la recherche », lit-on dans la documentation de developer.mozilla.org à propos de l’élément <search>. Un développeur de thème qui utilisait jusque-là <div role="search"> pour marquer sa zone de recherche est en droit de se demander si ce nouvel élément change quoi que ce soit de concret, ou s’il s’agit d’une simple redite sémantique du rôle ARIA déjà bien établi.
Ce que fait réellement le rôle ARIA search depuis des années
Le rôle ARIA search, disponible depuis les premières spécifications ARIA, s’applique à un conteneur qui regroupe les éléments d’une recherche (champ de saisie, bouton de validation, éventuels filtres associés) et l’expose comme un repère de navigation (landmark) aux technologies d’assistance. Un utilisateur de lecteur d’écran peut naviguer directement entre les zones de repère d’une page (en-tête, navigation principale, contenu, recherche, pied de page) sans avoir à parcourir le contenu intermédiaire :
<div role="search">
<form action="/">
<label for="q">Rechercher sur le site</label>
<input type="search" id="q" name="s">
<button type="submit">Rechercher</button>
</form>
</div>
Ce que change concrètement le nouvel élément
L’élément <search>, ajouté au standard HTML vivant du WHATWG en 2023, remplit exactement la même fonction de repère de navigation que role="search", avec un rôle ARIA implicite identique. La différence ne se situe donc pas dans le comportement exposé aux technologies d’assistance, déjà connu et stable, mais dans la nature du marquage : un élément HTML natif porte sa sémantique par construction, sans dépendre d’un attribut ARIA ajouté manuellement, ce qui réduit le risque d’oubli ou d’erreur de frappe sur la valeur du rôle.
<search>
<form action="/">
<label for="q">Rechercher sur le site</label>
<input type="search" id="q" name="s">
<button type="submit">Rechercher</button>
</form>
</search>
Ce marquage produit, dans l’arbre d’accessibilité, exactement le même repère « recherche » que la version précédente avec role="search" explicite. La règle ARIA de base, documentée par le W3C, veut d’ailleurs qu’un élément HTML natif ne reçoive pas en plus un rôle ARIA déjà implicite : cumuler <search role="search"> n’ajoute rien et introduit une redondance à éviter selon la première règle d’utilisation d’ARIA (« ne pas utiliser ARIA si un élément HTML natif fait déjà le travail »).
Ce que cela signifie pour un thème existant
- Remplacer
<div role="search">par<search>ne modifie rien pour l’utilisateur de technologie d’assistance : le repère de navigation reste identique - Le support navigateur de l’élément doit être vérifié avant une migration complète : les navigateurs qui ne le reconnaissent pas encore le traitent comme un élément générique sans rôle implicite particulier, ce qui dégrade silencieusement le repère de navigation pour les visiteurs de ces navigateurs
- Une double implémentation temporaire,
<search role="search">, reste tolérable pendant une phase de transition, malgré la redondance technique, précisément pour couvrir les navigateurs qui ne reconnaissent pas encore le rôle implicite du nouvel élément
Une nuance à ne pas manquer
L’élément <search> encapsule une zone fonctionnelle, il ne remplace en rien le champ de saisie lui-même : <input type="search"> reste nécessaire pour bénéficier des comportements spécifiques du type de champ (bouton d’effacement natif sur certains navigateurs, sémantique de saisie adaptée). Les deux éléments répondent à des besoins différents et complémentaires, l’un pour le conteneur de la fonctionnalité, l’autre pour le champ de saisie proprement dit.
Notre recommandation pour un thème en cours de maintenance : migrer progressivement vers l’élément natif
<search>à chaque gabarit retouché, sans campagne de remplacement massive uniquement motivée par cette évolution sémantique.
En résumé
L’élément HTML <search> ne fait pas doublon avec le rôle ARIA search au sens d’une redondance à corriger dans l’urgence : il en reprend fidèlement le comportement, en le rendant natif plutôt que dépendant d’un attribut ajouté manuellement. La bascule vers ce nouvel élément relève d’une simplification progressive du marquage, pas d’une correction d’un défaut d’accessibilité existant, à condition de vérifier le support navigateur avant toute migration complète d’un thème en production.
