Une boutique WooCommerce fonctionnellement irréprochable peut malgré tout perdre une partie de ses clients potentiels si son tunnel d’achat comporte des obstacles d’accessibilité. Contrairement à un site vitrine, où un défaut isolé reste gênant mais rarement bloquant, un tunnel de commande cumule les étapes critiques : chaque point de friction peut interrompre définitivement une conversion, avec un impact commercial direct et mesurable.
Voici un audit méthodique du parcours d’achat standard, fiche produit, panier, informations de commande et paiement, avec les défauts les plus fréquemment rencontrés sur des installations WooCommerce réelles et leurs correctifs.
Fiche produit : sélecteurs de variantes et galerie
Les sélecteurs de variantes (taille, couleur, matière), gérés par WooCommerce via des menus déroulants natifs par défaut, restent globalement accessibles tant qu’ils ne sont pas remplacés par des composants visuels personnalisés, une pratique fréquente pour afficher des pastilles de couleur ou des vignettes. Ces remplacements, souvent réalisés en pure CSS sur des éléments <div>, perdent la sémantique native du <select> et doivent recevoir un rôle et un état ARIA explicites pour rester utilisables au clavier et au lecteur d’écran.
<button role="radio" aria-checked="false" aria-label="Couleur bleu marine"
class="variation-swatch" data-value="bleu-marine">
</button>
La galerie d’images du produit, quant à elle, doit fournir un texte alternatif descriptif pour chaque vignette, au-delà du nom générique du fichier image que beaucoup de fiches produit laissent par défaut, un défaut fréquent quand les photos sont importées en masse sans relecture.
Panier : les mises à jour dynamiques doivent être annoncées
Le mini-panier, actualisé en AJAX à chaque ajout de produit sans rechargement de page, pose un problème classique d’accessibilité dynamique : un utilisateur de lecteur d’écran, resté positionné sur la fiche produit, n’est jamais informé que le panier vient de changer, sauf si une zone aria-live est prévue à cet effet.
<div class="mini-panier" aria-live="polite" aria-atomic="true">
Produit ajouté au panier. Total : 3 articles, 87,00 €.
</div>
L’attribut aria-live="polite" déclenche une annonce automatique du contenu de la zone dès qu’il change, sans interrompre l’activité en cours de l’utilisateur, contrairement à assertive, réservé aux messages réellement urgents comme une erreur de paiement.
Informations de commande : un formulaire long à structurer
Le formulaire de facturation et de livraison WooCommerce, particulièrement long, gagne à être découpé visuellement et sémantiquement en sections claires, via des éléments <fieldset> et <legend>, plutôt que présenté comme une liste continue de champs sans repère. Cette structuration aide un utilisateur de lecteur d’écran à comprendre où il se trouve dans le formulaire, une information que la seule mise en page visuelle en colonnes ne transmet pas.
| Étape du tunnel | Défaut le plus fréquent | Correction |
|---|---|---|
| Fiche produit | Sélecteurs de variantes en div sans rôle ARIA | role= »radio » et aria-checked |
| Panier | Mises à jour AJAX silencieuses | Zone aria-live sur le récapitulatif |
| Informations de commande | Formulaire long non structuré | fieldset et legend par section |
| Paiement | Erreurs de carte non annoncées | role= »alert » sur les messages d’erreur |
Paiement : l’étape qui ne tolère aucune approximation
L’étape de paiement concentre le plus fort enjeu commercial et, logiquement, la plus forte exigence d’accessibilité. Les messages d’erreur de carte bancaire, souvent générés par la passerelle de paiement elle-même plutôt que par WooCommerce, doivent être vérifiés spécifiquement : certaines intégrations affichent l’erreur uniquement en couleur rouge, sans role="alert" ni déplacement du focus, laissant un utilisateur de lecteur d’écran soumettre son formulaire plusieurs fois sans comprendre pourquoi le paiement échoue.
Un client qui abandonne son panier à cause d’un défaut d’accessibilité ne laisse jamais de commentaire expliquant pourquoi. Il part, tout simplement, et cette perte reste invisible dans les statistiques habituelles d’une boutique en ligne.
En résumé
Un audit d’accessibilité de WooCommerce gagne à être découpé par étape du tunnel plutôt que traité globalement : chaque écran, fiche produit, panier, informations de commande et paiement, présente ses propres pièges spécifiques. Les correctifs restent techniquement simples dans la plupart des cas, mais demandent une vérification systématique, étape par étape, plutôt qu’un test superficiel limité à la page d’accueil de la boutique.
