Un composant de recherche à suggestions ajoute, par nature, des couches d’interaction qu’un simple champ texte n’a pas : une liste qui s’ouvre au fil de la frappe, un contenu qui se met à jour sans rechargement de page, une navigation au clavier qui doit rester cohérente entre le champ et les résultats. Sur un bloc Gutenberg personnalisé livré à une collectivité, chacune de ces couches est un point de contrôle RGAA 4.1 à part entière.
Cette checklist ne couvre pas l’audit RGAA complet d’un site ni les obligations légales qui l’accompagnent (schéma pluriannuel, déclaration d’accessibilité). Elle se concentre sur le composant lui-même, celui qu’un développeur code, teste et livre : le bloc de recherche avec suggestions, souvent construit avec useState, un appel à l’API REST WordPress et une liste de résultats affichée sous le champ.
Ce que le rôle ARIA doit vraiment porter
Le motif d’interaction attendu par le RGAA pour ce type de composant est celui du combobox décrit par les WAI-ARIA Authoring Practices. Concrètement, le champ de saisie porte role="combobox", aria-expanded, aria-controls pointant vers l’identifiant de la liste, et aria-activedescendant qui suit l’élément actuellement survolé au clavier. La liste elle-même porte role="listbox", et chaque suggestion role="option".
- Le champ garde
aria-expanded="false"tant qu’aucune suggestion n’est affichée, et bascule àtruedès l’ouverture. aria-activedescendantest mis à jour à chaque déplacement avec les flèches, sans jamais déplacer le focus réel hors du champ.- Chaque
optionporte unidstable, généré à partir de l’identifiant du contenu suggéré plutôt que de son index dans la liste.
La zone live, souvent oubliée
Le RGAA exige que tout changement de contenu important, non lié à une action de focus, soit annoncé aux technologies d’assistance. Sur un bloc de suggestions, ce changement se produit à chaque frappe : le nombre de résultats varie, parfois passe à zéro. Sans zone live, un utilisateur de lecteur d’écran tape dans le vide sans savoir que la liste vient de se vider ou de se remplir.
La solution la plus fiable reste une zone aria-live="polite" masquée visuellement, distincte de la liste de résultats elle-même, qui reçoit un texte du type « 6 résultats disponibles » ou « Aucun résultat ». Ce texte doit changer à chaque nouvelle recherche, y compris quand le nombre de résultats reste identique d’une frappe à l’autre, sinon le lecteur d’écran ne détecte aucune mise à jour du DOM et reste muet.
Navigation clavier : ce qui casse en premier
Sur les blocs testés, trois erreurs reviennent systématiquement. La première : la touche Échap ne ferme pas la liste ou, pire, vide le champ sans le vouloir. La deuxième : la touche Entrée sur une suggestion active soumet le formulaire de recherche global au lieu de sélectionner l’élément survolé. La troisième : le focus visuel disparaît une fois la souris utilisée en complément du clavier, ce qui rend l’état du composant illisible pour un utilisateur voyant naviguant au clavier.
- Flèche bas depuis le champ active la première suggestion sans déplacer le focus DOM.
- Flèche haut depuis la première suggestion revient au champ, pas de saut vers la dernière option.
- Tab quitte le composant proprement et ferme la liste ouverte.
- Échap vide la liste de suggestions mais conserve le texte saisi dans le champ.
Contraste et zones cliquables
Le RGAA impose un contraste minimal de 3:1 pour l’indication de l’état actif d’une suggestion survolée au clavier, faute de quoi un utilisateur malvoyant qui navigue sans lecteur d’écran perd également le fil. Sur plusieurs blocs livrés à des mairies, l’état actif se limitait à un changement de fond très clair, invisible en plein soleil sur un écran de tablette utilisé en mairie ouverte au public.
| Élément | Exigence RGAA | Piège fréquent |
|---|---|---|
| Focus visible | Contraste 3:1 minimum | Bordure trop fine ou trop claire |
| Zone live | Texte renouvelé à chaque recherche | Message identique non redéclenché |
| Cible tactile | Zone cliquable suffisante par suggestion | Ligne de liste trop compacte |
Tester sans attendre l’auditeur externe
Un développeur qui livre ce type de bloc peut couvrir une bonne partie des points avant même l’audit RGAA officiel. NVDA sous Firefox, combiné à une navigation clavier stricte (souris débranchée le temps du test), révèle la plupart des trous décrits plus haut en moins d’une heure.
Sur ce type de composant, le test le plus révélateur reste le plus simple : débrancher la souris pendant vingt minutes et essayer d’utiliser la recherche jusqu’au bout, résultat inclus.
En résumé
Un bloc de recherche à suggestions RGAA-compatible tient sur trois piliers : un rôle combobox correctement câblé, une zone live qui parle à chaque frappe, et une navigation clavier qui ne piège jamais l’utilisateur. Aucun de ces trois piliers ne demande une bibliothèque tierce lourde ; ils demandent surtout de ne pas les traiter comme une couche ajoutée après coup, mais comme une contrainte de conception dès le premier commit du bloc.
