L’audit d’accessibilité numérique en France évalue la conformité des sites web et services numériques aux normes du RGAA, alignées sur les WCAG, afin de garantir leur accessibilité aux personnes en situation de handicap. Obligatoire pour les organismes publics depuis la Loi pour une République numérique, il identifie les obstacles, propose des corrections et aboutit à une déclaration d’accessibilité. Réalisé via des tests techniques et utilisateurs, l’audit améliore l’expérience utilisateur, optimise le SEO, réduit les risques juridiques et valorise l’engagement inclusif des organisations.
Nous allons étudier comment Playwright peut être utilisé pour auditer l’accessibilité d’une page Web.
Limitations avec Playwright
Les outils automatisés comme axe-core
(que nous allons utiliser avec Playwright) détectent principalement les erreurs techniques et structurelles (balises manquantes, attributs alt, contraste, etc.), mais ne couvrent qu’environ 30 à 50 % des problèmes d’accessibilité. Ils ne peuvent pas évaluer certains points comme :
- L’expérience utilisateur d’une personne handicapée,
- La pertinence des descriptions textuelles,
- L’efficacité de la navigation au clavier ou l’usage de lecteurs d’écran dans des scénarios complexes,
- La logique d’interaction et l’ergonomie.
De plus, Playwright, agissant comme un navigateur, n’agit donc pas comme un lecteur d’écran, et ne peut donc simuler les scénarios les impliquant.
Un audit manuel est toujours requis pour :
- Tester les interactions utilisateur,
- Vérifier la compréhension du contenu,
- Valider l’expérience avec des technologies d’assistance (lecteurs d’écran, commandes vocales).
Nous connaissons désormais les limitations de Playwright, mais l’utilisation de Playwright reste avantageuse car elle permet d’automatiser efficacement les tests, d’identifier rapidement les erreurs techniques et d’assurer une vérification continue sur plusieurs navigateurs.
Mise en place
Maintenant qu’on le connait les limitations avec Playwright, nous allons voir comment mettre en place Playwright.
La base reste la même que sur l’article sur les erreurs Javascripts.
Après cela, on installe le package @axe-core/playwright
via la commande npm i @axe-core/playwright --save-dev
.
Utilisation
On va ensuite créer un scénario qui va détecter deux pages : l’une sans violations (https://playwright.dev
) et l’autre avec (https://france.fr
).
|
|
Quelques notes à prendre en compte :
- Vous pouvez définir quels standards d’accesibilités vous voulez prendre en compte (liste complète)
- Vous pouvez contrôler le nombre de violations retournées (
accessibilityScanResults.violations
), mais aussi le nombre de règles qui sont ok (accessibilityScanResults.passes
), ainsi que celles qui sont non applicables à votre page (accessibilityScanResults.inapplicable
).
Violations
Dans notre cas assez simple, on ne vérifie que le nombre de violations, mais la librairie @axe-core
permet de récupérer des informations plus précises sur les violations. On va creuser cela :
|
|
On peut ainsi voir la première violation :
|
|
Chaque violation a cette structure :
id
: un identifiant unique,impact
: le niveau de criticité de la violation,tags
: l’ensemble des tags assignées à cette violation,description
: une description de la règle,help
: une description de la violation,helpUrl
: un lien vers dequeuniversity.com avec des informations complètementaire sur la violationnodes
: la liste de tous les éléments impactées dans la pagehtml
: code de l’élément HTML impactéimpact
: le niveau de criticité de la violation pour cet élément,failureSummary
: une explication de comment corriger la violation
Conclusion
Playwright vous permet de gagner énormément de temps en temps sur les retours possibles d’un audit accessibilité. Pour cela, il faut agir de manière proactive :
- un script qui lance l’audit AxeBuilder sur un ensemble représentatif des pages de votre site
- une correction dès la détection d’un souci
- une CI lancée régulièrement pour éviter les régressions