Cookies necessaires
Toujours actifs. Ils assurent le fonctionnement technique du site et la memorisation de votre choix de consentement.
L'accessibilité web est encore trop souvent vérifiée en fin de projet, parfois quelques jours avant la mise en production, lorsqu'un audit révèle une longue liste de problèmes à corriger.
Un champ de formulaire sans label, un contraste insuffisant, une mauvaise utilisation des attributs ARIA, un bouton inaccessible au clavier...
Des erreurs parfois simples à corriger individuellement, mais qui deviennent beaucoup plus coûteuses lorsqu'elles sont présentes sur des dizaines de pages ou dans des composants réutilisés partout dans une application.
Pourtant, une partie de ces problèmes pourrait être détectée automatiquement, dès le développement.
Alors pourquoi attendre l'audit final ?
Et surtout, comment intégrer ces contrôles dans notre workflow Front-End sans compliquer inutilement le travail des équipes ?
Lorsqu'on développe une application web, on automatise déjà de nombreuses vérifications : qualité du code, tests unitaires, tests fonctionnels, compilation, déploiement...
L'accessibilité mérite de trouver sa place dans cette démarche.
Prenons un exemple simple.
Un développeur crée un composant de formulaire. Il fonctionne visuellement, les validations JavaScript sont opérationnelles et les données sont correctement envoyées.
Mais le champ ne possède pas de label accessible.
<input type="email" placeholder="Votre email">Visuellement, tout semble correct.
Pourtant, le placeholder ne remplace pas un véritable label. Il peut notamment disparaître pendant la saisie et ne garantit pas un nom accessible approprié.
Une version plus adaptée serait :
<label for="email">Adresse email</label>
<input
type="email"
id="email"
name="email"
autocomplete="email"
>Un outil d'analyse automatique peut détecter certaines erreurs de ce type, avant même que le composant ne soit intégré dans plusieurs pages.
L'intérêt de l'automatisation n'est donc pas seulement de détecter des erreurs. C'est surtout de les détecter au bon moment.
Elle permet notamment de :
L'accessibilité devient ainsi une vérification régulière plutôt qu'une intervention exceptionnelle.
Il existe plusieurs outils capables d'analyser une interface et de signaler des problèmes d'accessibilité.
Ils ne remplissent pas tous le même rôle. Certains interviennent pendant l'écriture du code, d'autres directement dans le navigateur ou au moment des tests automatisés.
axe DevTools est une extension permettant d'analyser une page web directement depuis les outils de développement du navigateur.
Elle aide notamment à identifier certaines anomalies concernant :
Son principal avantage est de permettre au développeur de localiser les éléments concernés et de comprendre les erreurs détectées.
C'est un excellent premier réflexe pendant l'intégration d'une maquette ou la création d'un nouveau composant.
Lighthouse, intégré aux outils de développement de Chrome, propose notamment une catégorie consacrée à l'accessibilité.
Il permet d'effectuer un diagnostic rapide et de repérer certaines anomalies.
Mais attention à une confusion fréquente :
Un score d'accessibilité de 100 dans Lighthouse ne signifie pas qu'un site est entièrement accessible.
Ce score reflète uniquement les contrôles automatisés pris en compte dans son analyse.
Il ne remplace ni les tests d'utilisation ni un audit de conformité.
L'accessibilité peut également être contrôlée pendant l'écriture des composants.
Dans un projet React, par exemple, eslint-plugin-jsx-a11y permet de signaler certaines mauvaises pratiques dans les éléments JSX.
Dans un projet Angular, les règles d'accessibilité proposées par Angular ESLint permettent également d'effectuer des contrôles statiques sur les templates.
Ces vérifications peuvent signaler certaines anomalies avant même l'exécution de l'application.
L'intérêt est simple : éviter qu'une erreur prévisible arrive jusqu'au navigateur.
Il faut cependant distinguer les règles de linting, qui analysent le code source, des outils comme axe-core, qui inspectent l'interface rendue.
Ces approches sont complémentaires.
Pour aller plus loin, il est possible d'intégrer des contrôles d'accessibilité dans les tests automatisés de l'application.
C'est notamment ce que permet l'association de Playwright et d'axe-core.
Playwright pilote le navigateur et reproduit des interactions.
axe-core analyse l'accessibilité de l'interface affichée selon les règles qu'il prend en charge.
On peut ainsi contrôler automatiquement plusieurs pages et plusieurs états de composants.
Imaginons une application web sur laquelle nous souhaitons vérifier automatiquement certaines règles d'accessibilité.
La première étape consiste à installer les dépendances nécessaires dans un projet déjà configuré avec Playwright :
npm install -D @axe-core/playwrightCréons ensuite un test :
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
test('La page respecte les règles automatisées', async ({ page }) => {
await page.goto('/');
const results = await new AxeBuilder({ page })
.withTags([
'wcag2a',
'wcag2aa',
'wcag21a',
'wcag21aa',
'wcag22aa'
])
.analyze();
expect(results.violations).toEqual([]);
});Ce test ouvre la page, lance une analyse avec axe-core et échoue lorsque des violations sont détectées parmi les règles sélectionnées.
Les tags utilisés correspondent à des ensembles de règles associées aux niveaux A et AA des WCAG 2.0, 2.1 et 2.2.
Il s'agit bien d'un contrôle des violations détectables automatiquement, et non d'une vérification exhaustive des WCAG.
Le test suppose également que l'application soit accessible à l'URL de base configurée dans Playwright.
Une erreur fréquente consiste à automatiser un seul contrôle sur la page d'accueil.
Or, dans une application web, de nombreux problèmes apparaissent uniquement après une interaction.
Prenons l'exemple d'une fenêtre modale.
test('La modale ne présente pas de violation détectée', async ({ page }) => {
await page.goto('/');
await page
.getByRole('button', { name: 'Ouvrir les paramètres' })
.click();
const results = await new AxeBuilder({ page })
.include('[role="dialog"]')
.analyze();
expect(results.violations).toEqual([]);
});Ce test analyse la zone de dialogue après son ouverture.
Il peut être complété par d'autres vérifications, notamment pour s'assurer que le focus entre correctement dans la modale, que la navigation au clavier fonctionne et que le focus revient à un endroit logique après la fermeture.
C'est là que l'automatisation devient réellement intéressante : lorsqu'elle vérifie les interfaces dans leurs différents états, et pas uniquement au premier affichage.
Dans les applications modernes, une grande partie de l'interface repose sur des composants réutilisables.
Boutons, champs de formulaire, menus déroulants, onglets, accordéons, fenêtres modales, notifications...
Un même composant peut apparaître dans plusieurs dizaines de pages.
Cela présente un avantage important : lorsqu'un composant est correctement conçu, ses bonnes pratiques peuvent être réutilisées partout.
Mais l'inverse est également vrai.
Un composant inaccessible peut diffuser le même problème dans toute l'application.
Prenons l'exemple d'un bouton.
Il ne suffit pas de vérifier son apparence dans son état par défaut.
Il faut également examiner :
Une partie de ces contrôles peut être automatisée, tandis que d'autres nécessitent une vérification manuelle.
Cela devient particulièrement important lorsqu'on travaille avec un Design System.
En intégrant les tests d'accessibilité directement dans les composants partagés, on peut prévenir de nombreuses régressions avant qu'elles n'affectent plusieurs applications.
L'accessibilité doit donc faire partie des critères de validation d'un composant, au même titre que son rendu visuel, son responsive ou son comportement fonctionnel.
L'étape suivante consiste à intégrer ces tests au processus d'intégration continue.
L'objectif est simple : ne pas dépendre uniquement de la vigilance du développeur.
Lorsqu'une modification est proposée, le pipeline peut exécuter automatiquement les tests et signaler les nouvelles anomalies détectées.
Avec GitHub Actions, par exemple, un workflow simplifié pourrait ressembler à ceci :
name: Accessibility Tests
on:
pull_request:
jobs:
accessibility:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- run: npx playwright install --with-deps chromium
- run: npx playwright test tests/accessibility.spec.tsCet exemple suppose que Playwright, ses dépendances, son serveur de test et le fichier de tests sont déjà configurés dans le projet.
Le pipeline peut alors signaler qu'une modification introduit une violation détectée automatiquement.
Selon la politique de qualité définie par l'équipe, ce type d'échec peut empêcher la fusion d'une Pull Request.
Mais il faut éviter de transformer ces contrôles en simple formalité.
Si les alertes sont systématiquement ignorées ou si l'on désactive les règles qui échouent sans comprendre leur cause, l'automatisation perd une grande partie de son intérêt.
Il vaut mieux commencer par un périmètre maîtrisé, corriger progressivement les problèmes existants et élargir ensuite la couverture des tests.
C'est probablement le point le plus important de toute cette démarche.
Les outils automatiques sont capables de détecter de nombreuses anomalies techniques, mais ils ne peuvent pas juger entièrement la qualité de l'expérience utilisateur.
Prenons cet exemple :
<img
src="graphique-ventes.png"
alt="Image"
>L'attribut alt est présent.
Pourtant, la description n'apporte pratiquement aucune information sur le contenu du graphique.
Selon le contexte, il faudrait une alternative décrivant son information essentielle, éventuellement accompagnée d'une description plus détaillée.
Un contrôle automatique ne peut pas toujours déterminer si l'alternative est réellement adaptée au sens de l'image.
<button aria-label="Action">
<svg aria-hidden="true">...</svg>
</button>Le bouton dispose d'un nom accessible.
Mais « Action » ne permet pas de comprendre ce qu'il fait.
Un libellé tel que « Supprimer le document » ou « Ouvrir le menu » serait beaucoup plus pertinent selon sa fonction.
L'existence d'un nom accessible ne garantit donc pas sa qualité.
Une application peut contenir des éléments qui acceptent le focus sans offrir une navigation réellement utilisable.
Par exemple :
Certains de ces comportements peuvent être couverts par des tests fonctionnels automatisés.
Mais leur pertinence globale doit aussi être vérifiée manuellement, notamment avec un clavier et des technologies d'assistance.
Un test automatique réussi ne garantit donc jamais une expérience accessible.
En France, le RGAA constitue un référentiel majeur pour évaluer l'accessibilité des services numériques concernés par les obligations réglementaires.
La version 4.1.2 comporte 106 critères répartis en 13 thématiques.
Les contrôles automatisés peuvent contribuer à vérifier certaines exigences, mais ils ne permettent pas d'évaluer à eux seuls l'ensemble de ces critères.
Il faut donc distinguer trois démarches :
1. Les contrôles automatiques
Ils détectent certaines anomalies techniques à partir de règles programmées.
2. Les tests d'accessibilité
Ils associent différents moyens de vérification : analyses automatiques, tests clavier, technologies d'assistance et examen manuel.
3. L'audit de conformité
Il suit une méthodologie de référence sur un échantillon représentatif de pages et de fonctionnalités afin d'évaluer la conformité selon le référentiel applicable.
Ces trois démarches sont complémentaires, mais elles ne sont pas interchangeables.
Un rapport axe-core sans violation ne constitue pas un certificat de conformité RGAA.
Et une équipe qui automatise ses contrôles ne doit pas considérer que l'accessibilité est définitivement acquise.
Il n'est pas nécessaire de mettre en place une infrastructure complexe dès le premier jour.
L'approche la plus efficace consiste souvent à avancer progressivement.
Utiliser un HTML sémantique adapté, vérifier les formulaires, contrôler les contrastes, conserver des focus visibles et analyser régulièrement l'interface avec un outil comme axe DevTools.
Ajouter des règles de linting adaptées à la technologie, définir les comportements accessibles attendus et tester les différents états des composants.
Utiliser Playwright et axe-core sur les pages et les parcours importants, notamment les formulaires, les menus, les dialogues et les interactions dynamiques.
Exécuter automatiquement les tests dans la CI/CD et examiner les violations remontées.
Effectuer des vérifications manuelles : navigation au clavier, lecteur d'écran, zoom, réorganisation du contenu, compréhension des messages et comportement responsive.
Et lorsque le contexte l'exige, réaliser un audit selon le référentiel applicable.
L'idée n'est pas de tout automatiser, mais de réserver l'intervention humaine aux contrôles qui nécessitent réellement du jugement et de l'expérience.
Automatiser l'accessibilité est une bonne démarche, mais certaines pratiques peuvent en limiter les bénéfices.
Se concentrer uniquement sur le score Lighthouse
Un score élevé peut être rassurant, mais il ne reflète qu'une partie des exigences d'accessibilité.
Tester uniquement les pages statiques
Les erreurs apparaissent souvent dans les menus ouverts, les modales, les formulaires invalides et les interfaces dynamiques.
Ajouter des attributs ARIA partout
ARIA ne corrige pas automatiquement une mauvaise structure HTML. Lorsqu'un élément HTML natif répond au besoin, il est généralement préférable de l'utiliser.
Désactiver les règles qui remontent des erreurs
Une règle désactivée sans justification peut masquer une régression réelle.
Attendre le dernier sprint pour effectuer les tests manuels
Les comportements liés au clavier, au focus et aux technologies d'assistance doivent être examinés suffisamment tôt.
Penser qu'un Design System accessible garantit toutes les pages
Les composants peuvent être correctement construits tout en étant mal utilisés dans certaines interfaces.
L'accessibilité dépend aussi du contenu, de l'assemblage et du contexte d'utilisation.
L'automatisation des contrôles d'accessibilité n'a pas vocation à remplacer l'expertise des développeurs, des testeurs ou des spécialistes de l'accessibilité numérique.
Elle permet de détecter plus tôt certaines erreurs, de limiter les régressions et d'améliorer progressivement la qualité des interfaces.
Pour les équipes Front-End, c'est également une manière d'intégrer l'accessibilité dans leurs habitudes de travail, plutôt que de la considérer comme une étape supplémentaire en fin de projet.
Mais l'essentiel reste ailleurs.
Une interface peut réussir tous ses tests automatiques et rester difficile, voire impossible, à utiliser pour certaines personnes.
Le véritable objectif n'est pas d'obtenir un rapport sans erreurs. C'est de construire des interfaces réellement utilisables par tous.
Et pour y parvenir, la meilleure approche reste de combiner l'automatisation, les bonnes pratiques de développement et la vérification humaine.
Automatiser ce qui peut l'être. Vérifier humainement ce qui doit l'être. Et intégrer l'accessibilité dès la conception.
Les exemples sont fondés sur les documentations officielles de Playwright et axe-core. La distinction entre tests automatisés et audit RGAA repose également sur la méthodologie officielle française.
Point de vigilance au 9 octobre 2026 : le RGAA 4.1.2 reste la version publiée sur le portail officiel français, qui indique que le RGAA 5 est en préparation pour fin 2026.