# Tests d’accessibilité automatisés sur WordPress avec axe-core et Pa11y

> Intégrer axe dans Playwright et Pa11y CI dans le pipeline, régler des seuils raisonnables et traiter les faux positifs sans désactiver les règles en bloc.

- Auteur : Clément Hadrot
- Publié le : 2022-12-06
- Mis à jour le : 2022-12-06
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/tests-accessibilite-automatises-axe-core-pa11y/

## L’essentiel

- axe-core détecte environ un tiers des critères WCAG automatisables
- Pa11y CI compare plusieurs pages en une seule commande
- Un faux positif documenté vaut mieux qu'une règle désactivée globalement

Une refonte de thème avait remplacé un menu de navigation accessible au clavier par un composant JavaScript plus moderne visuellement, mais qui piégeait le focus dès qu'un visiteur au clavier y entrait, sans moyen d'en sortir autrement qu'en rechargeant la page. Aucun test fonctionnel classique n'aurait détecté ce problème, puisque la souris permettait de contourner le piège sans jamais s'en apercevoir. Intégrer axe-core dans les tests de bout en bout aurait signalé ce piège au clavier avant la mise en production.

Il faut poser une limite claire dès le départ : les outils automatisés d'accessibilité, aussi bons soient-ils, ne couvrent qu'une fraction des critères WCAG — l'ordre de grandeur généralement admis tourne autour d'un tiers. Contraste insuffisant, attribut `alt` manquant ou structure de titres incohérente se détectent bien automatiquement ; la pertinence d'un texte alternatif ou la cohérence logique d'un parcours au clavier demandent toujours un test humain.

## Intégrer axe-core dans des tests Playwright

```
npm install --save-dev @axe-core/playwright

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

test('la page produit ne contient pas de violation critique', async ( { page } ) => {
    await page.goto( '/boutique/produit-exemple/' );

    const resultats = await new AxeBuilder( { page } ).analyze();

    const violationsCritiques = resultats.violations.filter(
        v => v.impact === 'critical' || v.impact === 'serious'
    );

    expect( violationsCritiques ).toEqual( [] );
});
```

Filtrer sur les niveaux d'impact `critical` et `serious` permet de bloquer réellement le pipeline sur les problèmes les plus graves, sans faire échouer chaque build sur des remarques mineures qui méritent une revue humaine plutôt qu'un blocage automatique.

## Pa11y CI pour balayer plusieurs gabarits de page

Là où axe-core s'intègre bien à des tests ciblés, Pa11y CI est pensé pour auditer une liste de pages en une seule commande, ce qui convient bien à une vérification rapide de plusieurs gabarits :

```
npm install --save-dev pa11y-ci

// .pa11yci.json
{
  "defaults": {
    "standard": "WCAG2AA",
    "timeout": 10000
  },
  "urls": [
    "http://localhost:8080/",
    "http://localhost:8080/boutique/",
    "http://localhost:8080/contact/"
  ]
}
```

> L'essentiel à retenir : axe-core détecte environ un tiers des critères WCAG automatisables ; Pa11y CI compare plusieurs pages en une seule commande ; Un faux positif documenté vaut mieux qu'une règle désactivée globalement

```
npx pa11y-ci
```

## Traiter les faux positifs sans désactiver la règle globalement

Un cas fréquent : un widget tiers, comme un lecteur vidéo intégré, génère une alerte de contraste sur des éléments que le projet ne maîtrise pas. Le réflexe à éviter est de désactiver la règle de contraste pour tout le site. La bonne pratique consiste à ignorer précisément le sélecteur concerné :

```
{
  "urls": [
    {
      "url": "http://localhost:8080/contact/",
      "hideElements": ".lecteur-video-tiers"
    }
  ]
}
```

- Documenter dans le fichier de configuration pourquoi chaque exception existe
- Revoir périodiquement la liste des exceptions : un widget mis à jour peut avoir corrigé le problème entre-temps
- Ne jamais désactiver une règle entière pour tout le site à cause d'un seul composant tiers

## Notre verdict

axe-core et Pa11y CI attrapent efficacement une large part des régressions techniques d'accessibilité avant qu'elles n'atteignent la production, à condition de bien cibler les niveaux de sévérité et de documenter chaque exception. Ils ne remplacent en rien un audit manuel avec lecteur d'écran et navigation clavier complète, qui reste indispensable pour les critères que l'automatisation ne peut tout simplement pas juger.