WooCommerce
Accessibilité sur WooCommerce : où se situe vraiment le problème
WooCommerce a une particularité rare dans ce secteur : le projet publie sa propre position sur l’accessibilité et affirme que le frontal de l’extension principale est « substantiellement conforme » à WCAG 2.2 AA. Presque personne ne dit cela. Le hic : une boutique WooCommerce, ce n’est pas seulement l’extension, c’est un thème, dix à trente extensions et une passerelle de paiement. C’est là que ça casse.
Le cœur de WooCommerce est rarement le problème. Ce sont les messages jamais annoncés, les sélecteurs de variations sans étiquette, les filtres à facettes d’extensions inaccessibles au clavier, et les champs de paiement qui signalent l’erreur par une bordure rouge seule. Presque tout se corrige avec des hooks et des gabarits surchargés, sans toucher au cœur.
Ce que fournit WooCommerce et ce que vous fournissez
Ce que fournit WooCommerce : le projet déclare que le frontal de l’extension principale est substantiellement conforme à WCAG 2.2 niveau AA et reconnaît ouvertement des lacunes dans l’administration. Une déclaration honnête et peu courante.
Ce que vous fournissez : le thème — et l’écart entre un thème « accessibility-ready » et un thème acheté sur une place de marché est énorme. Les extensions de filtres, de pop-ups et d’avis. La passerelle de paiement, souvent un iframe tiers dont vous ne maîtrisez pas l’accessibilité. Et les contenus : titres de produits clairs, textes alternatifs, messages d’erreur qui disent quoi corriger.
Conséquence pratique : si votre boutique n’est pas conforme, le travail n’est presque jamais dans le cœur mais sur quatre ou cinq points précis de votre installation.
Les sept barrières que l’on retrouve presque à chaque fois
| Composant | Ce qui coince | WCAG | La correction |
|---|---|---|---|
Messages et erreurswoocommerce-message / error | Les messages « ajouté au panier » et d’erreur ne sont jamais annoncés au lecteur d’écran. | 4.1.3 | Les envelopper dans une zone role="alert" ou aria-live via un filtre. |
Sélecteur de variationsvariable.php (variaciones) | Les listes déroulantes de taille et de couleur arrivent sans étiquette associée. | 1.3.1 · 3.3.2 | Relier chaque select à son label for dans le gabarit surchargé. |
Ajout au panier en AJAXadd-to-cart AJAX | Le panier se met à jour en silence : visuellement il change, pour un lecteur d’écran rien ne se passe. | 4.1.3 | Marquer le conteneur mis à jour avec aria-live="polite". |
Filtres à facettesfiltros por facetas (plugin) | Les extensions de filtrage fabriquent souvent de fausses cases à cocher inaccessibles au clavier. | 2.1.1 · 2.4.7 | Utiliser des contrôles natifs, ou donner aux contrôles personnalisés un rôle, un état et un focus visible. |
Champs de paiementform-checkout.php | Erreurs signalées par la couleur seule et champs sans description associée. | 3.3.1 · 3.3.2 | Texte d’erreur explicite et aria-describedby sur les champs porteurs d’aide. |
Passerelle de paiementpasarela de pago externa | L’iframe du prestataire peut être inaccessible et vous ne pouvez pas le corriger depuis votre site. | 4.1.2 | Tester un vrai paiement au clavier et, en cas d’échec, changer de prestataire ou le solliciter. |
Le thèmetema (Storefront u otro) | Contrastes faibles et focus invisible : le défaut le plus courant des thèmes de place de marché. | 1.4.3 · 2.4.7 | Choisir un thème « accessibility-ready » ou corriger contraste et focus dans le thème enfant. |
Les corrections passent par des hooks dans le functions.php du thème enfant ou par des gabarits surchargés sous woocommerce/. Jamais en modifiant le cœur : la mise à jour suivante l’effacerait.
Pourquoi l’extension d’accessibilité ne règle rien
Le dépôt WordPress regorge d’extensions promettant la conformité derrière une case à cocher. Elles ajoutent une barre d’outils avec contraste élevé et taille de police. Elles ne corrigent ni un message jamais annoncé, ni un filtre inutilisable au clavier, ni un champ de paiement sans étiquette.
S’y ajoute un problème propre à WordPress : chaque extension ajoute son propre HTML au frontal, si bien qu’une extension qui « corrige l’accessibilité » entre souvent en conflit avec ce qu’une autre vient de produire. La voie qui marche est la plus ennuyeuse : bien choisir le thème, passer en revue les extensions qui produisent du HTML et corriger avec des hooks.
Testez votre boutique en dix minutes, sans aucun outil
- Rangez la souris. Depuis l’accueil, atteignez un produit variable, choisissez taille et couleur, ajoutez au panier et allez jusqu’au paiement avec Tab, Maj+Tab, Entrée et les flèches.
- Ajoutez au panier et écoutez. Si vous utilisez l’ajout en AJAX, vérifiez que le message « ajouté au panier » se trouve dans une zone
aria-live. - Validez le paiement avec un champ volontairement vide. L’erreur doit dire quel champ et ce qui manque, pas seulement colorer la bordure en rouge.
- Utilisez les filtres au clavier. C’est là que la plupart des extensions échouent.
- Zoomez à 200 % et vérifiez que le tableau du panier reste utilisable.
Vous voulez la liste complète pour votre boutique ?
Le scan gratuit vous donne en quelques minutes une première carte des barrières de votre site : sans compte, sans carte, sans engagement.