Comment tester l'accessibilité de son site e-commerce : les méthodes gratuites
En bref
On teste l'accessibilité d'un site en combinant quatre méthodes gratuites, du plus rapide au plus révélateur :
- Le scan automatique (quelques secondes) — détecte 30 à 50 % des problèmes : contrastes, images sans texte alternatif, libellés manquants, structure ;
- Le test au clavier (5 min, sans souris) — révèle ce qu'aucun outil ne voit : navigation bloquée, focus invisible, tunnel de paiement inutilisable ;
- Le test au lecteur d'écran (NVDA gratuit sur Windows, VoiceOver intégré sur Mac) — montre votre boutique telle qu'un utilisateur aveugle l'entend ;
- La vérification des contrastes et du zoom 200 % — avec les outils déjà intégrés à votre navigateur.
Aucune de ces méthodes ne coûte un euro. Aucune, seule, ne prouve la conformité : l'automatique va vite mais reste partiel, le manuel est plus complet mais demande du temps. Les bons audits font les deux.
« Mon site est-il accessible ? » La bonne nouvelle : vous pouvez commencer à le savoir aujourd'hui, gratuitement, sans expert. Ce guide décrit les quatre méthodes que vous pouvez appliquer vous-même sur votre boutique, ce que chacune détecte réellement, et où sont leurs limites — pour ne ni vous croire conforme à tort, ni paniquer pour rien.
Pourquoi tester — et selon quelle grille
Depuis le 28 juin 2025, l'European Accessibility Act (directive (UE) 2019/882) impose aux sites de commerce électronique destinés aux consommateurs d'être accessibles. La référence technique n'est pas une appréciation subjective : c'est la norme EN 301 549, qui pour le web renvoie aux WCAG 2.1 niveau AA. Tester son site, c'est donc le confronter à cette grille — celle-là même qu'utiliserait un contrôleur ou un utilisateur en cas de plainte.
Bonne nouvelle : une partie de ces critères se vérifie en quelques minutes. Mauvaise nouvelle : l'autre partie ne se voit qu'en utilisant réellement le site comme le ferait une personne handicapée. D'où l'intérêt de combiner les quatre méthodes ci-dessous, dans cet ordre.
Méthode 1 — Le scan automatique (le point de départ)
Un scanner d'accessibilité ouvre une page de votre site et la confronte à des centaines de règles automatisables : contraste de couleur insuffisant, image sans attribut alt, champ de formulaire sans libellé, titre manquant, attribut de langue absent, rôle ARIA mal employé… Le résultat : une liste chiffrée et localisée (les sélecteurs CSS exacts), en quelques secondes.
Les moteurs les plus utilisés sont open source et gratuits : axe-core (le moteur que DeclareAccess utilise aussi), WAVE de WebAIM, ou Lighthouse, intégré aux outils de développement de Chrome. Vous pouvez en lancer un vous-même ; nous proposons un scan prêt à l'emploi plus bas.
Méthode 2 — Le test au clavier (5 minutes, sans rien installer)
C'est le test le plus rentable de tous : gratuit, immédiat, et il révèle des blocages qu'aucun scanner ne voit. Beaucoup d'utilisateurs (handicap moteur, malvoyants, certains lecteurs d'écran) naviguent sans souris. Reproduisez leur expérience.
▸ Le protocole, étape par étape
- Ouvrez votre page d'accueil et rangez la souris. Servez-vous uniquement de
Tab(avancer),Maj+Tab(reculer),Entrée/Espace(activer), et des flèches dans les menus. WCAG 2.1.1 - À chaque
Tab, voyez-vous toujours où vous êtes ? L'élément actif doit avoir un contour net. Si le focus disparaît, c'est un échec. WCAG 2.4.7 - L'ordre de déplacement est-il logique (de haut en bas, de gauche à droite), sans sauts déroutants ? WCAG 2.4.3
- Pouvez-vous ouvrir le menu, le mini-panier, fermer une fenêtre modale (pop-up newsletter, sélecteur de taille) au clavier ? Et en ressortir sans être piégé ? WCAG 2.1.2
- Le test décisif : allez de l'accueil jusqu'au paiement — ajouter un produit, choisir une variante, remplir l'adresse, valider — au clavier seul. Si vous bloquez quelque part, un de vos clients aussi. WCAG 2.1.1 · 3.3.2
En cinq minutes, ce test révèle généralement plus de problèmes bloquants que n'importe quel rapport automatique — parce qu'il teste l'usage réel, pas le code en théorie.
Méthode 3 — Le test au lecteur d'écran
Un lecteur d'écran lit l'interface à voix haute pour les personnes aveugles ou malvoyantes. Entendre votre site révèle ce qui est invisible à l'œil : images muettes, boutons « sans nom », changements de contenu non annoncés. Vous n'avez rien à acheter :
- Sur Windows : NVDA, gratuit et open source (NV Access), à télécharger ; ou Narrateur, déjà intégré (
Ctrl+Win+Entrée). - Sur Mac : VoiceOver, intégré à macOS — activez-le avec
Cmd+F5. - Sur smartphone : VoiceOver (iOS) ou TalkBack (Android), déjà présents dans les réglages d'accessibilité.
Activez-le, fermez les yeux ou éteignez l'écran quelques instants, et parcourez une fiche produit puis le panier. Posez-vous :
▸ Ce qu'il faut écouter
- Les images produit sont-elles décrites utilement, ou annoncées « image », « IMG_4821 », ou pas du tout ? WCAG 1.1.1
- Les boutons et icônes (loupe, cœur, panier) ont-ils un nom parlé (« Ajouter au panier »), ou juste « bouton » ? WCAG 4.1.2
- Les champs de formulaire sont-ils annoncés avec leur libellé (« Code postal, zone d'édition ») ? WCAG 1.3.1 · 3.3.2
- Quand vous ajoutez au panier ou qu'une erreur apparaît, est-ce annoncé à voix haute, ou rien ne se passe pour l'oreille ? WCAG 4.1.3
- Les titres permettent-ils de comprendre la structure de la page quand on les fait défiler ? WCAG 1.3.1
C'est la méthode la plus inconfortable au début, mais la plus instructive : dix minutes au lecteur d'écran changent durablement la façon dont on conçoit une boutique.
Méthode 4 — Contrastes, zoom et affichage
Dernier passage, surtout visuel, avec les outils déjà dans votre navigateur (aucune installation) :
- Contrastes : les outils de développement de Chrome, Edge et Firefox (clic droit → « Inspecter ») affichent le ratio de contraste d'un texte au survol. La règle : au moins 4,5:1 pour le texte courant, 3:1 pour les grands titres et les contours de boutons/champs. Surveillez les prix barrés, les mentions « promo », le gris clair. WCAG 1.4.3 · 1.4.11
- Zoom 200 % : faites
Ctrl/Cmd +jusqu'à 200 %. Le contenu reste-t-il lisible, sans texte coupé ni défilement horizontal ? WCAG 1.4.4 · 1.4.10 - Couleur seule : une information n'est jamais portée par la seule couleur (« en stock » en vert, « épuisé » en rouge, sans texte ni icône). WCAG 1.4.1
Ce que chaque méthode détecte — et ne détecte pas
| Méthode | Coût / temps | Ce qu'elle révèle | Son angle mort |
|---|---|---|---|
| Scan automatique | Gratuit · secondes | Contrastes, alt manquants, libellés, structure, langue | Sens des textes, logique, usage réel (50–70 % des critères) |
| Test clavier | Gratuit · 5 min | Navigation bloquée, focus invisible, paiement inutilisable | Ce qui est annoncé (ou non) à l'oreille |
| Lecteur d'écran | Gratuit · 10 min | Images muettes, boutons sans nom, alertes non annoncées | Le rendu purement visuel (contraste, zoom) |
| Contraste & zoom | Gratuit · 5 min | Texte peu lisible, mise en page cassée au zoom | Tout ce qui relève de l'interaction |
Après le test : corriger, puis déclarer
Une fois la liste des problèmes établie, traitez d'abord les blocages révélés au clavier (les plus pénalisants), puis les contrastes et les alternatives d'images (rapides et à fort impact). Et n'oubliez pas l'obligation documentaire : même partiellement conforme, votre site doit publier une déclaration d'accessibilité qui décrit honnêtement l'état réel, liste les non-conformités connues et indique les voies de recours. C'est le manquement le plus simple à constater pour un contrôleur — et le plus vite réglé.
Commencez par le scan automatique de votre boutique
DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, vous renvoie un rapport chiffré et localisé des non-conformités, puis génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien, espagnol. Gratuit, sans carte bancaire. Le reste (clavier, lecteur d'écran) se teste ensuite à la main, avec ce guide.
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
Un outil de test gratuit suffit-il à prouver ma conformité ?
Non. Les scanners automatiques détectent 30 à 50 % des critères WCAG (contrastes, alternatives manquantes, libellés, structure). Tout ce qui relève du sens, de l'ordre logique et de l'usage réel au clavier et au lecteur d'écran exige un contrôle humain. Un test gratuit est un excellent point de départ honnête, jamais un certificat de conformité totale.
Quel lecteur d'écran utiliser pour tester sans rien payer ?
Sur Windows, NVDA est gratuit et open source (à télécharger chez NV Access) ; le Narrateur est déjà intégré. Sur Mac, VoiceOver est intégré à macOS (Cmd+F5). Sur mobile, VoiceOver (iOS) et TalkBack (Android) sont présents dans les réglages d'accessibilité. JAWS, lui, est payant et n'est pas nécessaire pour un premier test.
Combien de temps faut-il pour tester soi-même une boutique ?
Comptez quelques secondes pour le scan automatique, 5 minutes pour le test au clavier, 10 minutes pour un premier passage au lecteur d'écran et 5 minutes pour les contrastes et le zoom. En moins d'une demi-heure sur une page type (accueil, fiche produit, panier, paiement), vous avez déjà une image fidèle de l'état de votre site.
Que faire des résultats une fois le test terminé ?
Corrigez d'abord les blocages révélés au clavier (les plus pénalisants), puis les contrastes et les alternatives d'images (rapides, fort impact). Publiez ensuite une déclaration d'accessibilité décrivant honnêtement l'état réel et les voies de recours : elle est obligatoire et c'est le manquement le plus facilement sanctionné.
Installer un overlay d'accessibilité remplace-t-il ces tests ?
Non. Un overlay (accessiBe, UserWay…) est une surcouche, pas un test ni une correction du code. Il ne mesure pas l'état réel de votre site et peut même dégrader certains points (focus clavier, lecteurs d'écran). Les méthodes décrites ici évaluent votre site lui-même ; c'est là que se gagne la conformité.