Un thème classé « accessibility-ready » dans le répertoire officiel de WordPress a traversé les vérifications requises par l’équipe Make Themes : structure de navigation au clavier, contraste des couleurs par défaut, formulaire de commentaire correctement étiqueté. Rien de tout cela ne concerne WooCommerce, dont les gabarits de boutique, de fiche produit et de tunnel de commande sont générés par l’extension elle-même, indépendamment du thème installé au-dessus.
C’est précisément l’erreur commise sur ce projet : l’équipe avait choisi ce thème en s’appuyant sur son label pour couvrir l’ensemble du site, boutique comprise. L’audit RGAA commandé avant mise en ligne a révélé que le tunnel d’achat concentrait la quasi-totalité des anomalies bloquantes, alors que les pages de contenu classique passaient sans réserve majeure.
Ce que couvre réellement le label accessibility-ready
Le guide officiel de revue d’accessibilité des thèmes liste des exigences précises : navigation principale utilisable au clavier, indicateur de focus visible, structure de titres cohérente sur les gabarits fournis par le thème (page d’accueil, article, page statique, archive). Ces exigences portent exclusivement sur les gabarits natifs du thème, générés sans extension tierce activée.
Ce que WooCommerce ajoute par-dessus
Dès qu’on active WooCommerce, l’extension injecte ses propres gabarits (surchargeables via le dossier woocommerce/ du thème) : page boutique, fiche produit avec sélecteurs de variation, panier, et tunnel de commande en plusieurs étapes. Aucun de ces gabarits n’a été évalué lors de la revue du thème, puisque le label ne porte que sur le cœur WordPress. Le thème peut hériter visuellement du style WooCommerce sans jamais garantir l’accessibilité de ses interactions.
Les points bloquants relevés sur ce projet
- Les sélecteurs de variation de produit (couleur, taille) générés en
<select>stylisés en JavaScript perdaient leur association avec l’étiquette visuelle. - Le récapitulatif de commande affichait les totaux mis à jour dynamiquement sans région
aria-live, invisible pour un lecteur d’écran. - Le bouton d’ajout au panier en AJAX ne recevait jamais le focus après confirmation, laissant l’utilisateur clavier sans retour perceptible.
Un correctif type sur le récapitulatif de commande
<div id="totaux-panier" aria-live="polite" aria-atomic="true">
<p>Total : <strong>54,90 €</strong></p>
</div>
Ajouter cette région aria-live autour du bloc de totaux, mis à jour par le script wc-cart-fragments.js natif de WooCommerce, a permis l’annonce automatique du nouveau montant à chaque modification de quantité, sans nécessiter de rechargement de page.
Comparatif entre le thème seul et le thème avec WooCommerce actif
| Gabarit | Couvert par le label | Anomalies relevées à l’audit |
|---|---|---|
| Page d’accueil | Oui | Aucune anomalie bloquante |
| Fiche produit | Non | Sélecteurs de variation mal étiquetés |
| Tunnel de commande | Non | Focus perdu, totaux non annoncés |
Un label sur le thème ne dit jamais rien du comportement des extensions activées par-dessus. Vérifiez systématiquement chaque gabarit généré par une extension e-commerce, indépendamment de la réputation du thème.
Ce qu’il faut retenir de ce projet
Le label accessibility-ready reste un signal utile pour choisir un socle de thème, mais il ne dispense en aucun cas d’un audit spécifique du tunnel d’achat dès qu’une extension e-commerce comme WooCommerce entre en jeu. Sur ce projet, l’essentiel du budget de correction est allé aux gabarits WooCommerce non couverts, pas au thème lui-même, qui tenait globalement ses promesses.
