Recherche, filtres et tri de produits accessibles
En bref — une recherche que tout le monde peut utiliser
La barre de recherche, l'autocomplétion, les filtres à facettes et le tri sont parmi les fonctions les plus utilisées d'une boutique — et parmi les plus souvent inaccessibles, surtout quand la liste de résultats change « en direct » sans rien dire. L'European Accessibility Act (norme EN 301 549 / WCAG 2.1 AA), applicable au commerce électronique depuis le 28 juin 2025, impose que cette fonction soit utilisable par tous. Les points clés :
- Le champ de recherche porte une étiquette et un bouton de soumission nommé (1.3.1 · 4.1.2) ;
- L'autocomplétion se parcourt au clavier et ses suggestions sont annoncées (4.1.2 · 2.1.1) ;
- Le nombre de résultats est annoncé dynamiquement quand un filtre met la liste à jour (4.1.3) ;
- Les filtres sont de vrais contrôles (cases à cocher groupées, état coché annoncé) (1.3.1) ;
- Cocher un filtre ou changer le tri ne provoque pas de changement inattendu sans prévenir (3.2.2).
Le point le plus oublié : quand les filtres rechargent la liste sans recharger la page, une personne au lecteur d'écran ne sait pas que « 24 produits » sont devenus « 3 » — il faut le lui annoncer.
Une barre de recherche sans étiquette, une liste de suggestions qu'on ne peut pas atteindre au clavier, des filtres « à facettes » faits de <div> cliquables, et surtout une liste de résultats qui se met à jour en silence : la recherche et les filtres sont le cœur de l'expérience e-commerce, et l'un des endroits où l'inaccessibilité fait directement perdre des ventes. Voici les six règles WCAG que l'EAA impose pour rendre la recherche, l'autocomplétion, les filtres et le tri accessibles — et comment les vérifier.
Pourquoi la recherche et les filtres sont décisifs
Quand un visiteur ne peut pas parcourir tout le catalogue, la recherche et les filtres sont son seul moyen d'atteindre le produit qu'il veut. Si ces fonctions ne marchent qu'à la souris, ou si elles changent la page sans le dire, l'achat s'arrête là. Trois situations fréquentes : une personne au clavier ne peut pas descendre dans les suggestions d'autocomplétion ; une personne au lecteur d'écran coche un filtre mais n'entend jamais combien de produits restent ; une personne malvoyante ne voit pas que le tri « Prix croissant » est actif car il n'est signalé que par une nuance de couleur.
L'EAA s'appuie sur l'EN 301 549, fondée sur les WCAG 2.1 niveau AA. La recherche et les filtres relèvent surtout des critères 1.3.1 (Information et relations), 4.1.2 (Nom, rôle, valeur), 4.1.3 (Messages d'état) et 3.2.2 (Au remplissage) — tous de niveau A ou AA, donc réellement exigibles.
Les 6 règles pour une recherche et des filtres accessibles
On doit savoir à quoi sert le champ, sans la loupe seule
Un champ de recherche doit avoir un nom accessible : un <label> (même visuellement masqué) ou un aria-label, jamais un simple placeholder qui disparaît à la saisie. Le bouton de validation doit être un vrai <button> avec un libellé (« Rechercher »), pas une icône loupe muette. Englober l'ensemble dans role="search" (ou la balise <search>) aide les lecteurs d'écran à le repérer.
<label for="q">Rechercher un produit</label> + <button type="submit">Rechercher</button>, le tout dans role="search".placeholder="Rechercher…" et une icône loupe sans texte : au lecteur d'écran, ni le champ ni le bouton n'ont de nom.→ Voir aussi les libellés de formulaire.
Descendre dans les suggestions sans la souris
Si votre champ propose des suggestions au fil de la frappe, elles forment un combobox : l'utilisateur doit pouvoir descendre dans la liste avec les flèches ↑↓, choisir avec Entrée et fermer avec Échap, et le lecteur d'écran doit annoncer qu'il y a des suggestions et laquelle est sélectionnée. Techniquement, le champ porte aria-expanded, la liste un rôle approprié, et la suggestion active est désignée par aria-activedescendant. Les suggestions doivent rester affichées tant qu'on les survole ou qu'elles ont le focus (1.4.13).
→ Voir aussi les composants interactifs.
La règle la plus oubliée des pages de catalogue
Quand un filtre, une recherche ou un tri met la liste à jour sans recharger la page, l'écran change mais une personne au lecteur d'écran n'en sait rien. Le critère 4.1.3 (Messages d'état) impose d'annoncer le résultat sans déplacer le focus : placez le compteur (« 24 produits trouvés », puis « 3 produits trouvés ») dans une région live — role="status" ou aria-live="polite" — pour qu'il soit lu automatiquement. Annoncez aussi l'état « chargement… » si la mise à jour prend du temps.
<p role="status">24 produits trouvés</p> dont le texte est mis à jour à chaque filtre : le lecteur d'écran lit le nouveau total tout seul.→ Voir aussi les messages d'état et d'erreur.
Cocher une taille ou une couleur, et savoir ce qui est coché
Les filtres (taille, couleur, prix, marque…) doivent être de vrais contrôles de formulaire : des <input type="checkbox"> ou boutons radio avec une étiquette, pas des <div> qu'on colore quand ils sont actifs. Regroupez chaque famille de filtres dans un <fieldset> avec une <legend> (« Couleur », « Taille ») pour que le lecteur d'écran annonce le contexte. L'état coché/décoché est alors exposé nativement, et chaque filtre est atteignable et activable au clavier.
<fieldset><legend>Couleur</legend> avec une case à cocher étiquetée par couleur : « Bleu, case à cocher, cochée » est annoncé.<div onclick> sans rôle ni nom : impossible de savoir au lecteur d'écran lesquelles sont actives, ni de les cocher au clavier.→ Voir aussi liens et boutons accessibles.
Cocher un filtre ou changer le tri ne doit pas surprendre
Le critère 3.2.2 (Au remplissage) interdit qu'un changement de réglage déclenche un changement de contexte inattendu — par exemple un menu de tri <select> qui recharge brutalement la page dès qu'on le survole au clavier, ou qui change la page sans prévenir. Deux solutions saines : soit la liste se met simplement à jour sur place (avec l'annonce du point 3), soit l'application se fait après un bouton « Appliquer » explicite. Dans tous les cas, prévenez l'utilisateur de ce qui va se passer.
<select> de tri qui recharge la page entière dès qu'on passe d'une option à l'autre au clavier : impossible d'atteindre l'option voulue.Comprendre où l'on en est, et quoi faire ensuite
Quand une recherche ou un filtre ne renvoie rien, affichez un message « aucun résultat » explicite et annoncé (dans la même région live que le compteur), avec une piste (« élargissez vos filtres », « vérifiez l'orthographe »). Et l'état actif d'un filtre ou d'un tri ne doit pas reposer uniquement sur la couleur (1.4.1) : ajoutez un repère textuel, une coche, un libellé « actif » ou la présence d'un « Effacer le filtre ». Enfin, après une mise à jour, l'ordre de focus doit rester logique (2.4.3).
Récapitulatif des critères pour la recherche et les filtres
| Point à vérifier | Niveau | Critère WCAG |
|---|---|---|
| Champ de recherche étiqueté, bouton nommé | A | 1.3.1 · 4.1.2 · 2.4.4 |
| Autocomplétion pilotable au clavier et annoncée | A / AA | 4.1.2 · 2.1.1 · 1.4.13 |
| Nombre de résultats annoncé dynamiquement | AA | 4.1.3 |
| Filtres = vrais contrôles groupés, état exposé | A | 1.3.1 · 4.1.2 |
| Pas de changement de contexte inattendu | A | 3.2.1 · 3.2.2 |
| « Aucun résultat » clair, état pas que par la couleur | A / AA | 4.1.3 · 1.4.1 · 2.4.3 |
role="status" / aria-live="polite" et mettez son texte à jour à chaque changement. C'est souvent une ligne de code, et c'est ce qui sépare une recherche utilisable d'une recherche qui exclut.
role="status" à votre compteur de résultats, ne transforme pas vos pastilles de filtre en vraies cases à cocher et ne rend pas votre autocomplétion pilotable au clavier — ce sont des choix de développement propres à votre boutique. Rappel : la FTC américaine a sanctionné un éditeur d'overlay d'un million de dollars pour des allégations de conformité trompeuses. Voir pourquoi les overlays ne suffisent pas.Comment vérifier votre recherche et vos filtres
Quelques tests rapides, à faire sur votre barre de recherche, votre autocomplétion, vos filtres de catégorie et votre menu de tri :
- Rangez la souris : pouvez-vous atteindre le champ, descendre dans les suggestions aux flèches, cocher chaque filtre et changer le tri uniquement au clavier ?
- Coupez l'affichage ou fermez les yeux et utilisez un lecteur d'écran (NVDA, VoiceOver) : après avoir coché un filtre, le nouveau nombre de produits est-il annoncé ?
- Lancez une recherche sans résultat : un message clair s'affiche-t-il et est-il annoncé ?
- Regardez les filtres actifs : leur état se devine-t-il autrement que par une nuance de couleur ?
- Vérifiez le focus visible à chaque étape de la recherche et du filtrage.
Un scan automatique repère une partie des problèmes (champ ou bouton sans nom accessible, case à cocher sans étiquette, aria-* mal employé), mais l'annonce du nombre de résultats, le comportement clavier de l'autocomplétion et la pertinence du message « aucun résultat » se vérifient surtout à la main, au clavier et au lecteur d'écran. Notre rapport signale les manquements détectables automatiquement et l'ensemble des autres points WCAG.
→ Méthode complète : comment tester l'accessibilité de son site. Voir aussi la navigation au clavier.
Vérifiez l'accessibilité de votre boutique gratuitement
DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, repère les manquements (recherche, filtres, contraste, structure, étiquettes…) et génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre client e-mail va s'ouvrir avec la demande pré-remplie — il vous suffit de l'envoyer.
Questions fréquentes
Comment annoncer le nombre de résultats à un lecteur d'écran ?
Placez le compteur de résultats dans une région « live » : une zone portant role="status" ou aria-live="polite", présente dès le chargement, dont vous mettez à jour le texte (« 24 produits trouvés ») à chaque recherche, filtre ou tri. Le lecteur d'écran lit alors le nouveau total automatiquement, sans qu'il faille déplacer le focus. C'est l'exigence du critère 4.1.3 (Messages d'état) et, sur une page de catalogue dynamique, le point le plus souvent manquant.
Mon autocomplétion doit-elle fonctionner au clavier ?
Oui. Une liste de suggestions qui n'apparaît qu'à la souris exclut toute personne navigant au clavier. L'utilisateur doit pouvoir taper, voir/entendre qu'il y a des suggestions, descendre dans la liste avec les flèches, choisir avec Entrée et fermer avec Échap. Le motif technique est le « combobox » (champ avec aria-expanded, liste de suggestions, option active désignée par aria-activedescendant). Si c'est trop complexe à maintenir, une recherche classique qui mène à une page de résultats reste parfaitement accessible.
Mes filtres en pastilles de couleur posent-ils problème ?
Souvent, oui — pour deux raisons. D'abord, s'ils sont faits de <div> cliquables, ils ne sont ni atteignables au clavier ni annoncés au lecteur d'écran : préférez de vraies cases à cocher étiquetées, regroupées dans un <fieldset>/<legend>. Ensuite, si la seule indication « couleur sélectionnée » est une bordure de couleur, c'est une information transmise par la couleur seule (1.4.1) : ajoutez une coche, un libellé ou un contour net pour signaler l'état actif autrement.
Le tri par menu déroulant peut-il recharger la page ?
Le problème n'est pas de recharger, mais de le faire de façon inattendue. Un <select> de tri qui change la page dès qu'on passe d'une option à l'autre au clavier empêche d'atteindre l'option voulue : c'est un changement de contexte au remplissage (3.2.2). Deux options propres : mettre la liste à jour sur place après la sélection (en annonçant le résultat), ou appliquer le tri seulement après un bouton « Appliquer ». L'essentiel est que l'utilisateur ne soit pas surpris.
Le scan automatique détecte-t-il les problèmes de recherche ?
En partie. Un scan repère des signaux fiables : champ de recherche ou bouton sans nom accessible, case à cocher de filtre sans étiquette, attribut aria-* invalide. En revanche, il ne peut pas vérifier qu'une région live annonce bien le nombre de résultats, que l'autocomplétion répond aux flèches, ou que le message « aucun résultat » est utile : cela se teste à la main, au clavier et au lecteur d'écran. Notre rapport combine le détectable automatiquement et la liste des points à contrôler manuellement.