5 erreurs d'accessibilité fréquentes sur les sites e-commerce

Temps de lecture : 7 minutes

À force d'auditer des sites e-commerce, on finit par reconnaître les patterns. Certaines erreurs reviennent systématiquement, d'un site à l'autre, d'une marque à l'autre, indépendamment de la qualité globale du site ou du budget de l'enseigne. Ce sont des erreurs de design ou de développement qui se sont propagées dans la profession, souvent par effet de copie, et qui aujourd'hui condamnent des milliers de sites à la non-conformité.

Cet article passe en revue les 5 erreurs que nous croisons le plus souvent en audit. Si vous gérez un site e-commerce, il y a une probabilité très élevée qu'au moins 3 d'entre elles soient présentes chez vous.

Erreur n°1 : Les icônes sans nom (le piège invisible)

C'est de très loin l'erreur la plus fréquente. Sur quasiment tous les sites e-commerce que nous auditons, plus de 100 icônes sont présentes sans aucun texte alternatif accessible. Sur certains sites, on dépasse les 200 icônes muettes par page.

En quoi consiste l'erreur

Sur un site e-commerce moderne, tout ou presque est icône : la loupe de recherche, le panier, le cœur favori, les flèches du carrousel, la croix de fermeture, les icônes de partage social, les pictogrammes de livraison… Visuellement, ces icônes sont parfaitement claires pour un voyant.

Pour un utilisateur aveugle ou malvoyant qui navigue avec un lecteur d'écran, c'est une autre histoire. Si l'icône n'a pas de texte caché qui l'accompagne, le lecteur d'écran annonce simplement « bouton » ou « image », sans préciser ce que ce bouton fait. L'utilisateur entend ainsi « bouton, bouton, bouton, bouton, bouton » en parcourant la page. Impossible de savoir lequel est le panier, lequel est la recherche, lequel ferme une fenêtre.

Pourquoi c'est si fréquent

Cette erreur est presque toujours liée à un problème de composant réutilisé. Les développeurs créent un composant « bouton-icône » une fois, l'utilisent partout, et oublient de paramétrer le texte alternatif individuellement. Une seule erreur dans le code source se multiplie par 100 ou 200 dans le rendu final.

J'ai constaté ce pattern de manière exemplaire en auditant maisonsdumonde.com : sur leur seule page d'accueil, nous avons identifié 141 icônes vectorielles sans texte alternatif accessible. Sur la fiche produit, le chiffre montait à 240. Le problème n'est pas que le développeur a oublié 240 fois - il a oublié une fois, et le composant a été réutilisé 240 fois.

Comment la corriger

La bonne pratique est double :

• Pour les icônes décoratives (qui doublent un texte visible, comme l'icône loupe à côté du mot « rechercher ») : les masquer explicitement aux lecteurs d'écran avec l'attribut aria-hidden="true".
• Pour les icônes informatives (qui portent seules une signification, comme une icône cœur pour ajouter aux favoris) : leur donner un label texte explicite via l'attribut aria-label, par exemple aria-label="Ajouter aux favoris".

La bonne nouvelle : la correction est généralement simple à grande échelle. Comme l'erreur est centralisée dans un composant unique, la corriger dans ce composant résout l'ensemble des occurrences. C'est typiquement quelques heures de travail pour un développeur compétent, qui résolvent 200 violations d'un coup.

Erreur n°2 : Le focus clavier invisible

C'est la deuxième erreur que nous voyons le plus souvent, et c'est probablement la plus handicapante au quotidien pour les utilisateurs concernés.

En quoi consiste l'erreur

Sur un ordinateur, on peut naviguer sans souris en utilisant la touche Tab. Chaque appui sur Tab fait passer le curseur (le « focus ») sur l'élément interactif suivant : un lien, un bouton, un champ de formulaire. Pour que l'utilisateur sache où il est, le navigateur affiche par défaut un contour visuel autour de l'élément qui a le focus.

Le problème : beaucoup de designers trouvent ce contour bleu « moche » et demandent aux développeurs de le supprimer. Le développeur exécute (avec une simple ligne de CSS : outline: none) sans toujours comprendre l'impact accessibility. Résultat : le focus existe toujours techniquement, mais n'est plus visible à l'œil.

Conséquence pour l'utilisateur

Pour un utilisateur navigant exclusivement au clavier (handicap moteur, tremblements, lecteur d'écran), cela signifie qu'il ne sait plus où il se trouve sur la page. Il appuie sur Tab, mais aucun signal visuel ne lui indique l'élément actif. C'est exactement comme essayer de remplir un formulaire avec les yeux fermés.

Lors de notre audit de maisonsdumonde.com, j'ai pu confirmer le bug d'une manière intéressante : la tooltip native de Chrome affichait bien l'URL des liens en bas de l'écran quand le focus passait dessus, prouvant que le focus était techniquement positionné. Mais visuellement, rien. Le navigateur savait où était le focus, l'utilisateur non.

Comment la corriger

Il ne s'agit pas de remettre le contour bleu disgracieux du navigateur. La bonne approche est de redéfinir le style du focus avec un contour qui s'intègre à la charte graphique du site. Par exemple :

• Un contour fin de la couleur principale de la marque
• Un contour avec un léger décalage pour bien le détacher
• L'utilisation de la pseudo-classe CSS :focus-visible qui n'affiche le focus qu'en navigation clavier (et pas au clic souris, ce qui satisfait les designers)

C'est une demi-journée de travail pour un développeur, et le bénéfice est immédiat pour 100 % des utilisateurs au clavier.

Erreur n°3 : L'absence de lien d'évitement

Cette erreur est moins « visible » mais a un impact considérable sur l'expérience utilisateur des personnes handicapées.

En quoi consiste l'erreur

Sur la majorité des sites e-commerce, le menu principal en haut de page contient 20 à 50 liens : catégories de produits, sous-catégories, mon compte, panier, recherche, favoris, langue, devise, etc. Un utilisateur voyant peut survoler tout ça d'un coup d'œil et aller directement au contenu.

Un utilisateur qui navigue au clavier ou au lecteur d'écran, lui, doit passer par chaque élément un par un. Il appuie sur Tab 30, 40, 50 fois avant d'arriver au contenu principal de la page. Et il doit recommencer à chaque page qu'il visite.

Lors de notre audit Maisons du Monde, nous avons compté 40 tabulations entre l'arrivée sur la page d'accueil et le premier produit visible. Sur leur fiche produit, 17 tabulations entre la barre de recherche et la description du produit. Pour un utilisateur qui consulte 10 fiches produits par session, cela représente plus de 200 tabulations redondantes par visite.

La solution standard

La solution s'appelle un lien d'évitement (ou « skip link »). C'est un lien invisible par défaut, mais qui apparaît dès que l'utilisateur appuie sur Tab pour la première fois. Il propose en général : « Aller au contenu principal ». En appuyant sur Entrée, l'utilisateur saute directement au contenu, en ignorant tout le menu de navigation.

C'est une fonctionnalité que les voyants n'utilisent jamais (et donc qu'on ne voit pas), mais qui est vitale pour les utilisateurs au clavier. Son absence est une violation du critère WCAG 2.4.1.

Pourquoi presque personne ne l'implémente

Trois raisons :

• Les designers ne le voient pas et ne pensent pas à le demander
• Les développeurs n'en ont souvent pas appris l'existence
• Personne ne le réclame côté client puisque les voyants ne le manquent jamais

C'est typiquement le genre de fonctionnalité qui n'apparaît dans le cahier des charges que lorsqu'on fait un audit d'accessibilité. C'est aussi l'une des plus simples à ajouter - moins d'une heure de développement.

Erreur n°4 : La couleur de marque non conforme

Celle-ci est culturellement difficile à corriger, parce qu'elle touche à l'identité graphique de l'entreprise. Et pourtant, elle est extrêmement fréquente.

En quoi consiste l'erreur

Beaucoup de marques ont une couleur signature : un orange flashy, un rose pastel, un bleu turquoise, un jaune solaire. Cette couleur est utilisée partout : logo, boutons, mises en avant, titres de campagne. Le problème : certaines de ces couleurs ne respectent pas les ratios de contraste minimums quand elles sont appliquées à du texte sur fond blanc (ou inversement).

Le ratio de contraste minimum exigé par WCAG niveau AA est de 4,5:1 pour le texte normal et 3:1 pour le texte large. Or beaucoup de couleurs « tendance » tournent autour de 2:1 à 3:1, soit en-dessous du seuil légal.

Le cas concret de Maisons du Monde

Lors de notre audit, nous avons identifié que la couleur de marque orange #ef8f2e, utilisée comme couleur de texte sur fond blanc dans toute la navigation principale et les bannières promotionnelles, présentait un contraste de 2,43:1 au lieu des 4,5:1 requis. Cette seule décision graphique générait à elle seule 10 violations sur la page d'accueil.

Le piège : ces violations ne sont pas des oublis ponctuels. Elles sont la conséquence directe d'une décision de design system. Et elles touchent les éléments les plus stratégiques commercialement (les CTA promotionnels).

Comment la corriger sans tuer la marque

Trois options possibles :

• Assombrir légèrement la couleur pour atteindre le ratio. Souvent, un ajustement minime suffit (par exemple passer de #ef8f2e à #c46f00). L'œil humain ne perçoit quasiment pas la différence, mais le ratio bascule en conformité.
• Limiter la couleur aux usages décoratifs (fonds, illustrations, encadrés) et utiliser une variante plus sombre uniquement quand elle sert de couleur de texte.
• Inverser le contraste : du blanc sur fond orange plein, plutôt que de l'orange sur fond blanc. Selon la teinte de l'orange, ça peut atteindre les ratios requis.

C'est une décision qui doit se prendre avec l'équipe design, pas seulement avec les développeurs. L'objectif est de préserver l'identité graphique tout en assurant la lisibilité pour tous.

Erreur n°5 : Le formulaire de checkout cassé au clavier

C'est l'erreur la plus grave commercialement, et probablement la moins repérée. Tous les sites e-commerce y consacrent des semaines de travail UX/UI… et oublient de tester au clavier.

En quoi consiste l'erreur

Le tunnel d'achat (panier → livraison → paiement → confirmation) est juridiquement la zone la plus sensible d'un site e-commerce. L'EAA y est particulièrement attentive parce que c'est le lieu où l'inégalité d'accès devient une discrimination commerciale caractérisée.

Or nous avons constaté que sur de très nombreux sites, certaines actions du tunnel d'achat ne fonctionnent pas au clavier. Boutons « Modifier mon adresse » qui ne réagissent pas à la touche Entrée, sélecteurs de mode de livraison non navigables, codes promo dont le champ ne reçoit pas le focus, validation finale impossible sans cliquer.

Le scénario qui doit alerter tout dirigeant

Imaginez un utilisateur aveugle qui :

• A ajouté un canapé à 800 € à son panier
• A renseigné son adresse de livraison via le formulaire (qui fonctionne)
• Réalise qu'il s'est trompé sur le code postal
• Tabule jusqu'au bouton « Modifier mon adresse » et appuie sur Entrée
• Rien ne se passe
• Il ne peut pas finaliser sa commande

Cet utilisateur abandonne. Le panier à 800 € est perdu. Et juridiquement, l'entreprise a placé l'utilisateur dans l'impossibilité de finaliser une transaction en raison de son handicap, ce qui est exactement la situation que l'EAA cherche à interdire.

Lors de notre audit Maisons du Monde, nous avons identifié exactement ce bug sur la page de livraison de leur tunnel d'achat. Le bouton « Modifier mon adresse » ne réagissait pas au clavier, défaillance bloquante absolue, classée P0 dans notre rapport.

Comment vérifier sur votre site

Le test prend 15 minutes :

1. Ouvrez votre site
2. Posez votre souris à côté du clavier et n'y touchez plus
3. Faites un parcours d'achat complet : sélection produit → ajout panier → tunnel checkout → paiement (en mode test si possible)
4. À chaque étape, vérifiez que chaque bouton, chaque sélecteur, chaque action est activable avec Tab + Entrée uniquement

Si vous bloquez à une étape, vous avez identifié une violation potentiellement critique. Et il y a de fortes chances que vous bloquiez au moins une fois.

La correction est presque toujours simple

La cause technique est généralement simple : un développeur a utilisé une balise HTML inappropriée (par exemple <div onclick=...> au lieu de <button>), ce qui rend l'élément cliquable à la souris mais pas activable au clavier. La correction consiste à remplacer la balise par la balise sémantiquement correcte. Quelques minutes par bouton.

Ce qu'on en tire

Ces 5 erreurs ont un point commun : elles sont toutes corrigeables avec un effort raisonnable. Aucune n'exige de refonte complète du site. La plupart sont des corrections de quelques heures à quelques jours de développement, qui résolvent des dizaines voire des centaines de violations d'un coup.

La vraie question n'est donc pas « est-ce que mon site a ces problèmes ? » (la réponse est presque toujours oui), mais « combien j'en ai exactement, et combien de temps faudra-t-il pour les corriger ? ». C'est précisément ce qu'un audit permet de chiffrer.

Les exemples cités dans cet article s'appuient sur des audits réalisés sur des sites publics. Les chiffres et constats sont vérifiables par tout professionnel équipé d'un outil d'audit standard du marché.