# Tester l’accessibilité avec Playwright et axe-core sur chaque pull request

> Détecter une régression d'accessibilité avant la fusion d'une pull request coûte bien moins cher qu'après déploiement. Voici comment écrire un test bloquant sur les gabarits critiques.

- Auteur : WordPress Développement
- Publié le : 2023-05-16
- Mis à jour le : 2023-05-16
- Catégorie : Accessibilité
- URL : https://www.wpmoderne.fr/accessibilite/playwright-axe-core-tests-accessibilite-pull-request/

## L’essentiel

- Cibler d'abord les gabarits à fort trafic, pas tout le site
- Faire échouer le build sur les violations critiques uniquement
- Isoler les faux positifs connus sans désactiver toute la règle

`npm install --save-dev @axe-core/playwright` : cette seule commande change la donne pour une équipe qui découvre trop tard, en production, qu'une modification de composant a supprimé un focus visible ou cassé une hiérarchie de titres. Ce texte ne traite pas de la détection des pièges au clavier, abordée séparément, mais de la mise en place d'un test d'accessibilité automatisé et bloquant sur une pull request.

L'objectif n'est pas de remplacer un audit manuel complet, mais d'installer un filet de sécurité qui empêche les régressions les plus flagrantes de passer inaperçues entre deux revues de code humaines, souvent espacées de plusieurs semaines sur un projet actif.

## Choisir les gabarits à tester en priorité

Tester l'intégralité d'un site à chaque pull request ralentirait inutilement le pipeline et produirait un volume de résultats impossible à traiter. Concentrez-vous sur les gabarits à fort trafic ou à fort enjeu : page d'accueil, fiche produit, formulaire de contact, tunnel de paiement pour un site marchand.

```
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('page d’accueil sans violation critique', async ({ page }) => {
  await page.goto('/');
  const resultats = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa'])
    .analyze();
  expect(resultats.violations).toEqual([]);
});
```

Cette structure de test tourne sur une instance WordPress de préproduction, déployée automatiquement pour chaque pull request grâce à un environnement éphémère, ce qui garantit de tester le contenu réel plutôt qu'une page statique isolée du CMS.

## Étape 1 : installer axe-core et configurer Playwright

Ajoutez la dépendance au projet et créez un fichier de configuration Playwright dédié aux tests d'accessibilité, séparé des tests fonctionnels habituels pour garder des temps d'exécution lisibles dans les rapports de pull request.

## Étape 2 : distinguer violations bloquantes et avertissements

> L'essentiel à retenir : Cibler d'abord les gabarits à fort trafic, pas tout le site ; Faire échouer le build sur les violations critiques uniquement ; Isoler les faux positifs connus sans désactiver toute la règle

Axe-core classe ses résultats par niveau d'impact : mineur, modéré, sérieux, critique. Faire échouer le build sur chaque avertissement mineur décourage rapidement une équipe et pousse à désactiver le test entier au premier faux positif. Filtrez plutôt sur les niveaux sérieux et critique pour bloquer la fusion, et remontez les niveaux mineurs dans un rapport consultable sans bloquer.

```
const violationsBloquantes = resultats.violations.filter(
  v => v.impact === 'serious' || v.impact === 'critical'
);
expect(violationsBloquantes).toEqual([]);
```

## Étape 3 : gérer les faux positifs sans désactiver la règle entière

Un composant tiers, comme un widget de chat ou une carte interactive embarquée en iframe, génère parfois une violation qui ne dépend pas du code du projet. Plutôt que de désactiver globalement la règle axe concernée, excluez précisément le sélecteur CSS du composant fautif :

```
const resultats = await new AxeBuilder({ page })
  .withTags(['wcag2a', 'wcag2aa'])
  .exclude('#widget-chat-tiers')
  .analyze();
```

Documentez chaque exclusion dans un commentaire du test, avec la date et la raison, pour éviter qu'elle survive silencieusement des années après la disparition du composant qui la justifiait.

## Étape 4 : intégrer le test au pipeline de la pull request

Ajoutez une étape dédiée dans votre fichier de workflow d'intégration continue, après le déploiement de l'environnement de prévisualisation et avant l'étape de revue manuelle. Un rapport HTML généré par Playwright, joint automatiquement en commentaire de la pull request, permet à un relecteur non technique de visualiser les violations sans lancer le test localement.

- Un test dédié par gabarit critique, nommé explicitement dans les résultats
- Seuls les niveaux sérieux et critique font échouer le pipeline
- Chaque exclusion de sélecteur documentée et datée dans le code du test

## Étape 5 : faire évoluer la liste des gabarits testés

Ajoutez un nouveau gabarit à la suite chaque fois qu'un incident d'accessibilité en production aurait pu être évité par un test automatisé. Cette approche incrémentale évite le chantier disproportionné de vouloir tout couvrir dès la première version du pipeline.

> Un test qui bloque une pull request pour un contraste insuffisant coûte trois lignes de CSS à corriger. Le même défaut détecté après mise en production coûte un correctif d'urgence et parfois un signalement d'utilisateur mécontent.

## En résumé

Un test Playwright couplé à axe-core sur quelques gabarits critiques, filtré sur les violations sérieuses et critiques, détecte la majorité des régressions d'accessibilité avant la fusion d'une pull request, pour un coût d'exécution largement inférieur à une minute par gabarit.