Avis clients et notations étoiles accessibles
En bref
- Les étoiles SVG ou Unicode ne transmettent leur valeur qu'à ceux qui les voient — chaque note doit avoir un texte alternatif (« 4 étoiles sur 5 »).
- Une étoile décorée par la couleur seule (gold vs gris) ne distingue pas les demi-points sans texte — WCAG 1.4.1.
- Le widget de notation interactif doit être utilisable au clavier et exposer sa valeur via ARIA — 4.1.2.
- La liste d'avis doit être balisée sémantiquement (liste ou articles) et la note globale annoncée en texte — 1.3.1.
- Le formulaire d'évaluation suit les mêmes règles que tout formulaire accessible — libellés, erreurs, états ARIA.
- Un overlay ne génère ni texte alternatif ni ARIA sur des étoiles codées en dur — FTC 1 M$ contre accessiBe (avril 2025).
Pourquoi les avis clients sont un cas particulier
Les avis ont deux modes : lecture (note globale, liste d'avis, étoiles affichées) et écriture (widget de notation interactif, formulaire de commentaire). Chaque mode soulève ses propres problèmes d'accessibilité.
La plupart des e-commerces affichent les étoiles comme des caractères Unicode (★★★☆☆), des SVG remplis/vides, ou des images répétées. Pour un visiteur voyant, la note est immédiate. Pour un utilisateur de lecteur d'écran, il lira soit rien (si aria-hidden est mal placé), soit chaque glyphe lu phonétiquement (« étoile, étoile, étoile, demi, vide »), soit une valeur numérique si l'ARIA est correctement posé.
L'EAA (28 juin 2025) exige la conformité EN 301 549 / WCAG 2.1 AA pour l'ensemble du service — y compris les pages fiche produit, les pages de liste avec notes et les formulaires d'avis.
Les 6 règles à appliquer
Texte alternatif sur les étoiles d'affichage
Qu'elles soient en SVG, en image, en Unicode ou via une police d'icônes, les étoiles d'affichage doivent porter un texte lisible par les lecteurs d'écran. La valeur numérique et le maximum doivent être explicitement communiqués.
Pour un groupe d'étoiles SVG, enveloppez l'ensemble dans un span portant aria-label="4 étoiles sur 5" et ajoutez aria-hidden="true" sur chaque SVG individuel. Pour des étoiles Unicode en texte, masquez-les avec aria-hidden="true" et ajoutez un span de texte masqué visuellement (class="visually-hidden").
aria-label="4 étoiles sur 5" sur le groupe
✓ Chaque SVG étoile avec aria-hidden="true"
✗ <span>★★★★☆</span> sans texte alternatif
✗ alt="★★★★☆" (glyphes lus phonétiquement)
La couleur ne peut pas être la seule distinction
Une étoile « active » dorée et une étoile « inactive » grise se distinguent visuellement par la couleur. Pour les utilisateurs daltoniens (environ 8 % des hommes) ou en mode contraste élevé, cette distinction peut disparaître.
La règle WCAG 1.4.1 impose qu'une information transmise par la couleur soit aussi transmise par un autre moyen. En pratique, le texte alternatif porté par l'aria-label (règle 1) est ce second moyen — les deux règles se résolvent ensemble. En complément, les étoiles actives peuvent se distinguer des inactives par leur forme, leur remplissage ou leur taille, pas uniquement par leur teinte.
aria-label portant la valeur numérique
✗ Étoile or = active, étoile grise = inactive, sans autre signal
Balisage sémantique de la liste d'avis et de la note globale
La structure d'une section « avis clients » doit être perceptible par tous. La note globale (ex. 4,3/5 sur 128 avis) doit être annoncée en texte (pas uniquement via un graphique ou des étoiles). Chaque avis individuel doit former une unité sémantique : une liste <ul> d'items ou des éléments <article> avec un titre <h3> ou <h4> portant la note ou l'auteur.
Le schéma schema.org/Review et schema.org/AggregateRating est recommandé pour le SEO (rich snippets étoiles dans Google) et compatible avec une bonne accessibilité — les deux objectifs se rejoignent ici.
<ul> ou <article> par avis
✓ schema.org/AggregateRating pour le SEO
✗ Note globale uniquement en graphique SVG sans texte
✗ Avis dans des <div> sans structure
Widget de notation interactif clavier + ARIA
Quand un client donne une note (1 à 5 étoiles), il utilise un widget interactif. Le pattern WCAG recommandé est un <fieldset> / <legend> avec des <input type="radio"> masqués visuellement (labels stylisés en étoiles), ou un composant role="slider" avec aria-valuemin, aria-valuemax, aria-valuenow et aria-valuetext.
L'approche input[type=radio] est la plus robuste : elle est native, focusable au clavier (Tab pour atteindre le groupe, touches flèches pour sélectionner), et les lecteurs d'écran annoncent correctement « 3 étoiles, bouton radio sélectionné, groupe Votre note ».
<input type="radio"> + <label> stylés en étoiles
✓ role="slider" avec aria-valuenow + aria-valuetext
✓ Navigable flèches clavier
✗ Étoiles cliquables en <div> sans rôle ni focus
✗ Événement onclick uniquement (pas onkeydown)
Pas d'instruction basée sur la forme ou la couleur seule
Les instructions qui guident l'utilisateur pour noter ou filtrer les avis ne peuvent pas reposer exclusivement sur des caractéristiques sensorielles (couleur, forme, position). Un texte comme « cliquez sur les étoiles dorées pour noter » est problématique s'il est la seule explication : un utilisateur daltonien ou en mode contraste élevé ne voit pas les étoiles « dorées ».
Reformulez : « Sélectionnez votre note de 1 à 5 » ou « Cliquez ou utilisez les touches fléchées pour choisir votre note ». La valeur transmise par l'aria-label du widget suffit dans la plupart des cas.
Formulaire d'avis et liens vers les avis
Le formulaire permettant de rédiger un commentaire suit les mêmes règles que tout formulaire accessible : libellés explicites (<label> reliés aux champs), messages d'erreur textuels (pas uniquement une bordure rouge), champs obligatoires signalés (required + texte).
Les liens vers les avis (« Lire tous les avis » ou « Voir les 128 avis ») doivent être explicites hors contexte — un lecteur d'écran navigue souvent par liste de liens. Évitez « Voir plus » sans contexte, préférez « Voir les 128 avis sur ce produit ».
<label for="review-text">Votre commentaire</label>
✓ « Voir les 128 avis sur ce produit »
✗ Libellé uniquement en placeholder
✗ Lien « Voir plus » sans contexte
Récapitulatif des critères
| Critère WCAG | Niveau | Application aux avis |
|---|---|---|
| 1.1.1 — Contenu non textuel | A | Texte alternatif sur chaque groupe d'étoiles (« 4 étoiles sur 5 ») |
| 1.3.1 — Information et relations | A | Note globale en texte, liste ou articles sémantiques pour les avis |
| 1.3.3 — Caractéristiques sensorielles | A | Instructions de notation sans référence à la couleur ou la forme seule |
| 1.4.1 — Utilisation de la couleur | A | Étoile active vs inactive distinguée par forme + texte, pas couleur seule |
| 2.1.1 — Clavier | A | Widget de notation navigable au clavier (Tab + flèches) |
| 2.4.4 — Objet d'un lien | A | Lien vers les avis explicite sans le contexte (« Voir les N avis ») |
| 3.3.1–3.3.2 — Aide à la saisie | A | Formulaire d'avis : libellés visibles, erreurs textuelles |
| 4.1.2 — Nom, rôle, valeur | A | Widget interactif expose aria-valuenow ou état radio |
<span>★★★★☆</span> est lu par VoiceOver macOS comme « étoile étoile étoile étoile étoile blanche » — ce qui ne transmet ni la valeur (4) ni le maximum (5). La correction est simple : ajouter un aria-label="4 étoiles sur 5" sur le <span> conteneur et aria-hidden="true" sur chaque caractère étoile — ou masquer les glyphes et ajouter un texte visually-hidden.
Comment vérifier
- Scanner automatique (axe-core) détecte fiablement :
imgsans alt, éléments cliquables sans nom accessible (buttonouavide), rôle sans nom. Il ne détecte pas : la pertinence du texte alternatif (« ★★★★☆ » vs « 4 étoiles sur 5 ») — vérification humaine nécessaire. - Lecteur d'écran (VoiceOver / NVDA) : naviguez vers la note globale et chaque groupe d'étoiles — la valeur doit être annoncée clairement. Activez le widget de notation : la note sélectionnée doit être annoncée en temps réel.
- Clavier : Tab pour atteindre le widget de notation, touches flèches pour changer la note, Espace/Entrée pour valider — tout doit fonctionner sans souris.
- Mode contraste élevé (Windows) : les étoiles actives et inactives doivent rester distinguables par leur forme, pas uniquement leur couleur.
Questions fréquentes
Mon thème Shopify ou WooCommerce génère les étoiles automatiquement — qui est responsable ?
La responsabilité de la conformité incombe au marchand, pas à l'éditeur du thème. Si le thème génère des étoiles inaccessibles, c'est à vous de corriger le code (ou de demander à votre développeur de le faire). Les thèmes « accessibility-ready » de WordPress et les thèmes OS 2.0 de Shopify s'améliorent, mais aucun ne certifie une conformité totale WCAG 2.1 AA — une vérification sur votre implémentation réelle reste indispensable.
Un score NPS ou une notation par cœurs/pouces est-elle couverte par les mêmes règles ?
Oui. Qu'il s'agisse d'étoiles, de cœurs, de pouces haut/bas ou de barres de progression, le principe est identique : tout contenu non textuel doit avoir un texte alternatif (1.1.1), tout composant interactif doit être accessible au clavier et exposer son état via ARIA (4.1.2, 2.1.1), et aucune information ne peut reposer sur la couleur seule (1.4.1). La forme du widget n'importe pas, les critères s'appliquent.
Les avis chargés en lazy-loading posent-ils un problème d'accessibilité ?
Le chargement différé est acceptable à condition que le contenu chargé soit correctement injecté dans le DOM et annoncé aux lecteurs d'écran quand il devient disponible. Si vous injectez de nouvelles pages d'avis via JavaScript, une région aria-live="polite" ou un déplacement de focus vers les nouveaux contenus aide les utilisateurs de lecteurs d'écran à les percevoir. Sans cela, les nouveaux avis apparaissent à l'écran sans être annoncés.
Le widget de notation avec demi-étoiles est-il plus difficile à rendre accessible ?
Légèrement plus, car il faut exposer des valeurs comme « 3,5 étoiles sur 5 » plutôt que des entiers, et le widget interactif doit gérer 10 positions (0,5 à 5) au lieu de 5. Avec l'approche input[type=radio], il suffit de doubler le nombre de boutons radio (valeurs 0.5, 1, 1.5…) et d'adapter l'aria-label de chaque label. L'aria-valuetext du composant role="slider" peut également prendre la valeur « 3 étoiles et demie sur 5 ».
Le scanner gratuit de DeclareAccess détecte-t-il les problèmes d'étoiles ?
Oui, partiellement. Le scanner basé sur axe-core détecte les boutons et liens sans nom accessible (cas typique du widget d'étoiles en <div>), les images sans alt, et les éléments interactifs sans rôle. En revanche, il ne peut pas évaluer la pertinence du texte alternatif — si vous avez écrit aria-label="★★★★☆" (les glyphes bruts), le scanner ne signalera pas d'erreur, mais un lecteur d'écran lira les glyphes phonétiquement. Une vérification humaine avec VoiceOver ou NVDA reste nécessaire sur les éléments d'avis.
Lancez le scan automatisé de votre boutique
DeclareAccess analyse une page de votre site selon les WCAG 2.1 AA, vous renvoie un rapport chiffré des non-conformités (avec les éléments concernés), puis génère la déclaration d'accessibilité prête à publier — modèle français (RGAA) ou allemand (BFSG). Audit gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre demande d'audit est enregistrée — vous recevrez votre rapport WCAG par e-mail sous 24 h ouvrées.