# Tester la conformité à l’European Accessibility Act d’un achat WooCommerce

> Depuis le 28 juin 2025, l'European Accessibility Act impose des obligations précises aux boutiques en ligne. Ce qu'on automatise, et ce qu'on garde en contrôle manuel.

- Auteur : Clément Hadrot
- Publié le : 2025-07-13
- Mis à jour le : 2025-07-13
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/tester-conformite-european-accessibility-act-woocommerce/

## L’essentiel

- L'EAA s'applique depuis le 28 juin 2025 aux services e-commerce
- Certaines obligations dépassent le périmètre des règles WCAG classiques
- Le tunnel d'achat doit être testé de bout en bout, pas page par page

Depuis le 28 juin 2025, l'European Accessibility Act (EAA) est d'application effective pour les services numériques ciblant des consommateurs dans l'Union européenne, e-commerce inclus. Contrairement au RGAA français, qui s'applique essentiellement aux organismes publics et aux grandes entreprises françaises, l'EAA vise directement les boutiques en ligne privées dépassant certains seuils, avec des obligations qui recoupent partiellement les WCAG 2.1 mais y ajoutent des exigences propres au parcours d'achat.

Ce billet documente les contrôles que nous avons automatisés sur un tunnel WooCommerce pour une boutique de matériel de randonnée, en distinguant ce qui relève d'un test automatisable et ce qui reste hors de portée d'un outil comme axe-core. Le RGAA, avec son référentiel propre et son périmètre d'application distinct, n'est pas traité ici.

## Ce que l'EAA ajoute par rapport aux WCAG génériques

L'EAA impose, entre autres, que les informations sur l'accessibilité du service soient elles-mêmes accessibles, que les moyens de paiement proposés soient utilisables avec une technologie d'assistance, et que le processus de réclamation ou de contact en cas de problème soit lui-même conforme. Ce dernier point est souvent oublié : une page de contact avec un formulaire mal étiqueté peut mettre en défaut la conformité même si le tunnel d'achat lui-même est irréprochable.

## Automatiser ce qui peut l'être

Nous avons construit une suite Playwright couplée à axe-core qui parcourt le tunnel WooCommerce dans son intégralité — fiche produit, panier, identification, étapes de paiement, confirmation — plutôt que de tester chaque page isolément, car certains problèmes n'apparaissent qu'en contexte de parcours (par exemple un focus perdu après validation d'une étape).

```
test('le tunnel de commande complet ne remonte aucune violation critique', async ({ page }) => {
  await page.goto('/produit/sac-a-dos-40l');
  await page.getByRole('button', { name: 'Ajouter au panier' }).click();
  await page.goto('/panier');
  await page.getByRole('link', { name: 'Passer la commande' }).click();

  const resultats = await new AxeBuilder({ page }).analyze();
  expect(resultats.violations.filter(v => v.impact === 'critical')).toHaveLength(0);
});
```

> L'essentiel à retenir : L'EAA s'applique depuis le 28 juin 2025 aux services e-commerce ; Certaines obligations dépassent le périmètre des règles WCAG classiques ; Le tunnel d'achat doit être testé de bout en bout, pas page par page

## Ce qu'axe-core ne verra jamais

- La clarté réelle du message d'erreur lors d'un refus de paiement pour une personne utilisant un lecteur d'écran
- La cohérence de l'ordre de tabulation à travers un sélecteur de mode de livraison en plusieurs étapes
- La pertinence du texte alternatif d'une image produit, techniquement présent mais qui ne décrit rien d'utile
- Le respect du délai de session pendant le paiement pour un utilisateur qui navigue plus lentement avec une technologie d'assistance

Ces points exigent un contrôle manuel, réalisé avec un lecteur d'écran réel (NVDA ou VoiceOver), sur le tunnel complet, au moins une fois par trimestre et à chaque changement significatif du parcours de paiement.

## Notre checklist pour ce projet

1. Contrôle automatisé axe-core sur chaque page du tunnel, exécuté à chaque déploiement
2. Contrôle automatisé du contraste sur les boutons d'action (souvent personnalisés par le thème, à surveiller après chaque mise à jour graphique)
3. Navigation clavier complète du tunnel testée manuellement une fois par trimestre
4. Test avec lecteur d'écran du formulaire de paiement, y compris les messages d'erreur de carte refusée
5. Vérification que la page de déclaration d'accessibilité est elle-même conforme et à jour

> Une conformité qui s'arrête à un score axe-core vert ne protège ni le client malvoyant, ni l'association face à un contrôle réglementaire.

## Pour aller plus loin

La conformité EAA pour un tunnel WooCommerce ne se résume pas à un audit ponctuel : elle demande une surveillance continue, en particulier après chaque mise à jour d'extension de paiement, souvent source de régressions non détectées par les tests automatisés seuls.