Comment automatiser les tests d'accessibilité WCAG avec Axe-core et Github

Intégrez l'accessibilité dans votre workflow de dev. Utilisez Axe-core et GitHub Actions pour interdire tout composant non inclusif.

Par Eddy Vuillaume 2 juin 2026
Comment automatiser les tests d'accessibilité WCAG avec Axe-core et Github

En 2026, l'accessibilité numérique (WCAG 2.1 / EAA) est devenue un critère de qualité de premier ordre pour Google et les utilisateurs. Cependant, maintenir un score d'accessibilité parfait de 100/100 sur Lighthouse est un défi quotidien dans un projet vivant. Les régressions sont fréquentes au fil des commits de développement. La seule méthode industrielle pour garantir un site "zéro défaut" consiste à automatiser les tests d'accessibilité au cœur de votre pipeline CI/CD (Intégration Continue).

Dans ce guide Technique de niveau senior, nous allons voir comment intégrer le moteur Axe-core dans vos tests automatisés avec Cypress et automatiser sa validation sur GitHub Actions pour bloquer toute mise en production non conforme.

1. Le moteur de test Axe-core : Le standard de l'industrie


Développé par Deque Systems, Axe-core est la bibliothèque open-source de référence pour auditer l'accessibilité. Elle est capable de détecter de manière programmatique jusqu'à 50% des violations WCAG courantes (comme des contrastes de couleurs insuffisants, des attributs Alt manquants sur les Images, ou des structures Hn invalides).

Contrairement aux tests manuels longs et coûteux, Axe-core s'intègre directement dans vos suites de tests fonctionnels existantes (Cypress, Playwright ou Jest), transformant l'accessibilité en une simple assertion de code.

2. Configurer Axe-core dans vos tests Cypress


Pour auditer vos routes d'Acquisition statiques générées par Astro, nous vous recommandons d'utiliser le package <code>cypress-axe</code>. Voici comment le configurer pas à pas :

<code class="language-javascript">// 1. Installer le module : npm install --save-dev cypress cypress-axe

// 2. Importer dans cypress/support/e2e.js
import 'cypress-axe';

// 3. Rédiger le fichier de test : cypress/e2e/accessibility.cy.js
describe('Audit Accessibilité - whaz.fr', () => {
it('Doit respecter les standards WCAG 2.1 AA sur toutes les pages', () => {
// Visiter la page cible
cy.visit('/blog/seo-local-bordeaux-cabinet-avocats');

// Injecter le moteur de test Axe
cy.injectAxe();

// Lancer l'Analyse et échouer le test en cas de violation
cy.checkA11y(null, {
runOnly: {
type: 'tag',
values: ['wcag2a', 'wcag2aa']
}
});
});
});
</code>

3. Pipeline CI/CD sur GitHub Actions : Interdire les régressions


Une fois vos tests fonctionnels écrits, vous devez les exécuter automatiquement à chaque Pull Request (PR) pour empêcher l'intégration de code non conforme. Voici le fichier de workflow GitHub Actions à placer dans <code>.github/workflows/accessibility.yml</code> :

<code class="language-yaml">name: QA Accessibility & Performance

on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

jobs:
accessibility-audit:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4

- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'

- name: Install Dependencies
run: npm ci

- name: Build Astro Site (SSG)
run: npm run build

- name: Run Cypress Axe-core Tests
uses: cypress-io/github-action@v6
with:
start: npm run preview
wait-on: 'http://localhost:4321'
</code>

Grâce à ce workflow, si un développeur pousse un composant UI avec un contraste de couleur gris clair sur blanc ou un bouton d'action dépourvu de libellé textuel, le test Axe-core échouera immédiatement sur GitHub. La Pull Request sera bloquée et la fusion vers la branche de production interdite.

4. Les 3 vérifications critiques à automatiser


Pour un site vitrine premium axé CRO et SXO, assurez-vous d'avoir configuré vos tests sur ces 3 points fondamentaux :

Type de test sémantiqueRègle WCAG viséeAction corrective automatique
Contrastes de couleurRègle 1.4.3 (Minimum 4.5:1 pour le texte normal).Validation automatique des tokens CSS via l'outil de build.
Textes alternatifs d'ImagesRègle 1.1.1 (Tous les contenus non textuels doivent avoir un équivalent).Alerte de build Astro si l'attribut <code>alt</code> est omis sur un composant <code>&lt;Image /&gt;</code>.
Libellés des formulairesRègle 4.1.2 (Chaque champ de saisie doit posséder un nom accessible).Assertion de présence d'un élément <code>&lt;label&gt;</code> ou attribut <code>aria-label</code>.

5. L'avis de l'expert Whaz : L'assurance qualité au service de vos ventes


Chez Whaz, nous considérons que le design d'élite et l'accessibilité WCAG sont indissociables. Il ne s'agit pas seulement de conformité légale ou d'éthique, mais d'une rigueur de développement qui protège vos investissements d'Acquisition. Un site dont l'accessibilité dérive au fil des commits est un site qui exclut des clients potentiels et envoie des signaux négatifs à Googlebot.

En mettant en place une barrière automatisée sur votre pipeline de build, vous sanctuarisez votre Performance UX et SEO. Votre actif digital reste irréprochable et performant, jour après jour, sans exiger d'audit manuel récurrent.

Demander mon audit vidéo offert

Analyse de votre site en 5 minutes • Gratuit & Sans engagement

Retour à la liste des articles