# RGAA 4.1 et bloc de recherche à suggestions : la checklist qui compte vraiment

> Un bloc de recherche à suggestions développé sur mesure multiplie les pièges RGAA. Voici la liste de contrôle ciblée, testée en conditions réelles sur un site public.

- Auteur : Clément Hadrot
- Publié le : 2024-09-22
- Mis à jour le : 2024-09-22
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/rgaa-bloc-recherche-suggestions-checklist/

## L’essentiel

- Rôle ARIA combobox correctement porté par le bloc
- Annonce vocale des résultats via une zone live
- Navigation clavier complète dans la liste de suggestions

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 à `true` dès l'ouverture.
- `aria-activedescendant` est mis à jour à chaque déplacement avec les flèches, sans jamais déplacer le focus réel hors du champ.
- Chaque `option` porte un `id` stable, 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.

> L'essentiel à retenir : Rôle ARIA combobox correctement porté par le bloc ; Annonce vocale des résultats via une zone live ; Navigation clavier complète dans la liste de suggestions

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.