Tests automatisés d'accessibilité : intégration CI/CD et scénarios avancés

Les tests automatiques d'accessibilité ne remplacent pas l'expertise humaine, mais ils constituent la première ligne de défense contre les régressions. Intégrés dans votre pipeline CI/CD, ils bloquent les erreurs avant qu'elles n'atteignent la production.

Voici comment mettre en place une stratégie de tests automatisés efficace et réaliste.

Pourquoi automatiser les tests d'accessibilité ?

Vérifier manuellement chaque page à chaque déploiement est impossible. Les tests automatisés apportent trois bénéfices majeurs :

Rapidité : Un scan complet en quelques secondes contre plusieurs heures manuellement.

Reproductibilité : Les mêmes règles appliquées systématiquement, sans variation humaine.

Prévention des régressions : Chaque pull request est vérifiée avant fusion.

Ce que l'automatisation détecte (et ne détecte pas)

Erreurs détectables automatiquement

Les outils automatiques excellent pour identifier les violations techniques évidentes :

• Attributs alt manquants sur les images
• Contrastes de couleurs insuffisants
• Labels de formulaires non associés
• Attributs ARIA invalides ou redondants
• Structure de titres incohérente
• Liens sans texte accessible

Limites inhérentes à l'automatisation

Aucun outil ne peut évaluer la pertinence sémantique :

• Le texte alternatif décrit-il correctement l'image ?
• L'ordre de lecture est-il logique ?
• Les instructions sont-elles compréhensibles ?
• L'expérience au lecteur d'écran est-elle fluide ?

Les outils de référence

axe-core : le moteur de référence

Développé par Deque, axe-core est le moteur le plus utilisé. Open source et gratuit, il s'intègre dans tous les environnements :

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

test('Page d'accueil accessible', async ({ page }) => {
  await page.goto('/');

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa'])
    .analyze();

  expect(results.violations).toHaveLength(0);
});

Pa11y : simplicité en ligne de commande

Pa11y permet de lancer des tests depuis le terminal sans configuration complexe :

npx pa11y https://monsite.fr --standard WCAG2AA

IBM Equal Access Toolkit

Le moteur d'IBM offre une couverture complémentaire à axe. Combiner les deux augmente la détection globale.

Intégrer dans votre pipeline CI/CD

Stratégie de blocage progressif

Ne bloquez pas immédiatement toutes les erreurs. Adoptez une approche progressive :

Phase 1 - Alertes : Les erreurs sont reportées mais ne bloquent pas le build.

Phase 2 - Blocage partiel : Les erreurs critiques (niveau A) bloquent le merge.

Phase 3 - Zéro tolérance : Toutes les erreurs AA bloquent le déploiement.

Exemple de configuration GitHub Actions

name: Tests accessibilité
on: [pull_request]

jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm run build
      - run: npm run start &
      - run: npx wait-on http://localhost:3000
      - run: npm run test:a11y

Scénarios de tests avancés

Tester les interactions dynamiques

Les scans statiques ne suffisent pas. Automatisez les parcours utilisateurs pour détecter les problèmes de focus et ARIA :

test('Modal accessible au clavier', async ({ page }) => {
  await page.goto('/contact');
  await page.click('button[data-open-modal]');

  // Le focus doit être dans la modale
  const focusInModal = await page.evaluate(() => {
    return document.activeElement.closest('[role="dialog"]') !== null;
  });
  expect(focusInModal).toBeTruthy();

  // Echap ferme la modale
  await page.keyboard.press('Escape');
  const modalClosed = await page.isHidden('[role="dialog"]');
  expect(modalClosed).toBeTruthy();
});

Tester les formulaires multi-étapes

Les formulaires complexes présentent des défis spécifiques :

test('Formulaire inscription accessible', async ({ page }) => {
  await page.goto('/inscription');

  // Remplir avec des données invalides
  await page.fill('#email', 'invalide');
  await page.click('button[type="submit"]');

  // Vérifier que l'erreur est liée au champ
  const ariaDescribedby = await page.getAttribute('#email', 'aria-describedby');
  expect(ariaDescribedby).toBeTruthy();

  const ariaInvalid = await page.getAttribute('#email', 'aria-invalid');
  expect(ariaInvalid).toBe('true');
});

Bonnes pratiques pour une automatisation efficace

Exécuter plusieurs moteurs en parallèle

Chaque moteur détecte des violations différentes. Combinez axe, Pa11y et IBM Equal Access pour maximiser la couverture :

// Fusionner les résultats de plusieurs moteurs
const axeResults = await runAxe(page);
const pa11yResults = await runPa11y(url);
const ibmResults = await runIBMAccessibility(page);

const allViolations = mergeResults(axeResults, pa11yResults, ibmResults);

Tester sur plusieurs viewports

Les erreurs d'accessibilité peuvent apparaître uniquement sur mobile ou desktop :

const viewports = [
  { width: 375, height: 667, name: 'mobile' },
  { width: 1920, height: 1080, name: 'desktop' }
];

for (const viewport of viewports) {
  await page.setViewportSize(viewport);
  const results = await new AxeBuilder({ page }).analyze();
  // ...
}

Exclure temporairement les faux positifs

Certaines erreurs peuvent être des faux positifs. Documentez-les et excluez-les explicitement :

const results = await new AxeBuilder({ page })
  .exclude('#widget-externe') // Composant tiers non modifiable
  .disableRules(['color-contrast']) // Si déjà vérifié manuellement
  .analyze();

Mesurer et suivre les progrès

Métriques à suivre

• Nombre de violations par catégorie (A, AA, AAA)
• Évolution dans le temps (tendance)
• Couverture des pages testées
• Temps moyen de correction

Dashboard de suivi

Intégrez les résultats dans vos outils de monitoring pour visualiser l'évolution :

// Exemple d'envoi de métriques
await sendMetrics({
  violations: results.violations.length,
  passés: results.passés.length,
  timestamp: Date.now(),
  branch: process.env.GIT_BRANCH
});

Compléter avec des tests manuels

L'automatisation est nécessaire mais insuffisante. Planifiez des tests manuels réguliers :

• Tests avec lecteur d'écran (NVDA, VoiceOver)
• Parcours complets au clavier uniquement
• Vérification de la compréhensibilité du contenu

Consultez notre guide des tests avec NVDA et VoiceOver pour approfondir les tests manuels.

L'automatisation vous fait gagner du temps sur la détection des erreurs évidentes. Le temps économisé peut être réinvesti dans les tests manuels qui garantissent une expérience réellement accessible.