Un client vendant des équipements de randonnée en ligne, lui-même non-voyant et utilisateur quotidien de NVDA, avait signalé un comportement déroutant sur sa propre boutique WooCommerce : « quand j’ajoute un article, je n’ai aucune idée si ça a marché, je dois vérifier en allant sur la page panier à chaque fois ». Ce billet documente le diagnostic de ce silence, sans détailler la mise en œuvre de la correction elle-même, traitée dans l’article qui précède celui-ci sur l’ajout d’annonces aria-live.
Symptôme : un clic qui semble n’avoir aucun effet perceptible
En reproduisant le parcours avec NVDA activé, le clic sur le bouton « Ajouter au panier » d’une fiche produit ne déclenchait strictement aucune annonce vocale, alors que visuellement, le compteur du panier dans l’en-tête passait bien de zéro à un article, avec une brève animation. Le comportement Ajax fonctionnait donc correctement du point de vue technique ; le problème se situait entièrement du côté de ce qui est communiqué, ou plutôt pas communiqué, aux technologies d’assistance.
Diagnostic : inspecter l’arbre d’accessibilité, pas seulement le DOM
La première étape du diagnostic a consisté à ouvrir l’onglet Accessibilité des outils de développement du navigateur, plutôt que le simple inspecteur DOM, pour voir ce qui est réellement exposé aux technologies d’assistance. Aucune région avec un rôle alert ou une propriété aria-live n’apparaissait nulle part sur la page, ni dans l’en-tête, ni près du bouton d’ajout, ni dans le pied de page. Le thème utilisé, un thème premium générique adapté à WooCommerce, ne prévoyait tout simplement aucun mécanisme d’annonce pour les actions de panier.
Confirmation : comparer avec le thème par défaut de WooCommerce
Pour confirmer que le problème venait du thème et non d’une configuration cassée de WooCommerce lui-même, le même parcours a été testé sur une installation de test utilisant Storefront, le thème par défaut historiquement associé à WooCommerce. Sur cette installation, un message de confirmation apparaissait bien visuellement après l’ajout au panier, mais l’inspection a montré qu’il n’était, lui non plus, pas systématiquement annoncé de façon fiable par tous les lecteurs d’écran testés — un rappel que même un thème de référence n’est pas exempt de lacunes sur ce point précis, et que la vérification manuelle reste nécessaire au cas par cas.
Localiser précisément l’absence dans le code du thème
En parcourant les gabarits du thème client, la fonction responsable de l’affichage du message de confirmation après ajout au panier générait un <div> avec une classe visuelle d’animation, mais sans aucun attribut ARIA :
// Extrait du thème, avant correction : purement visuel
function afficher_confirmation_ajout($nom_produit) {
echo '<div class="notification-ajout notification-ajout--visible">'
. esc_html($nom_produit) . ' ajouté !</div>';
}Cette fonction fonctionnait exactement comme prévu du point de vue visuel : elle apparaissait, restait affichée trois secondes, puis disparaissait avec une transition CSS. Rien dans son fonctionnement n’était cassé au sens strict ; elle n’avait simplement jamais été conçue pour être perçue autrement qu’à l’œil.
Prévention : ajouter cette vérification à la checklist de recette
Ce cas a conduit l’agence à ajouter un point systématique à sa checklist de recette pour tout thème WooCommerce, personnalisé ou acheté sur une marketplace :
- Ouvrir l’onglet Accessibilité des outils de développement sur la fiche produit et la page panier.
- Vérifier la présence d’au moins une région
aria-liveou d’un rôlealertassocié aux actions de panier. - Confirmer avec un test NVDA réel que l’ajout, la modification et la suppression d’un article sont chacun perceptibles sans avoir à consulter visuellement l’écran.
Ce défaut ne remonte dans quasiment aucun scanner automatisé, car il ne s’agit pas d’un attribut mal formé mais d’une absence totale de mécanisme d’annonce. Seul un test réel avec un lecteur d’écran, ou une lecture attentive de l’arbre d’accessibilité, permet de le repérer.
En résumé
Le silence signalé par ce client n’était pas un bug au sens classique : le panier fonctionnait, l’animation s’affichait, tout semblait normal côté visuel. Le défaut résidait dans l’absence complète de toute région aria-live ou de rôle d’alerte dans le thème, un manque qu’aucun test purement visuel ne pouvait révéler. La mise en œuvre de la correction, avec des annonces précises et temporisées, fait l’objet de l’article suivant.
