Comment réaliser un audit d’accessibilité web qui corrige réellement les erreurs wcag

Réaliser un audit d'accessibilité web qui ne se contente pas de lister des erreurs mais permet réellement de corriger les problèmes WCAG demande plus qu'une simple passe avec un outil automatique. Dans mes projets, j'ai appris que c'est un travail d'équipe, itératif et pragmatique : il faut définir un périmètre clair, combiner plusieurs méthodes de test, impliquer des utilisateurs en situation de handicap et prioriser les corrections pour maximiser l'impact. Ici, je décris la méthode que j'utilise pour transformer un audit en plan d'action concret et mesurable.

Définir l'objectif et le périmètre

Avant toute chose, je commence toujours par poser ces questions : quel est l'objectif de l'audit ? Respecter la conformité WCAG 2.1 niveau AA ? Améliorer l'expérience pour un service précis (p.ex. formulaire de contact, parcours de paiement) ? Ou préparer une mise sur le marché ?

Sur la base de la réponse, je définis le périmètre : pages principales, modèles de pages, composants réutilisables (header, footer, menus), et éléments dynamiques (modales, widgets JS). Sans périmètre, l'audit devient vite infini et perd de son utilité opérationnelle.

Méthodologie : combiner automatique, manuel et utilisateur

Un bon audit repose sur trois piliers :

• Tests automatiques : rapides et efficaces pour détecter des problèmes évidents (attributs ARIA manquants, contraste insuffisant, images sans alt, structure de heading).
• Tests manuels : indispensables pour vérifier le sens, la navigation au clavier, le comportement des composants interactifs, la logique des formulaires et la qualité des libellés.
• Tests utilisateurs : la validation par des personnes en situation de handicap révèle des problèmes d'usage qui n'apparaissent pas dans les outils (par exemple une modal mal gérée par un lecteur d'écran ou un carrousel inaccessible).

Outils que j'utilise

Voici les outils que j'intègre systématiquement dans mes audits :

• Lighthouse (intégré à Chrome DevTools) — pour une vue rapide et un score d'accessibilité.
• Axe DevTools (Deque) — pour des rapports détaillés et des règles exploitables en dev.
• WAVE — utile pour visualiser les problèmes sur la page.
• NVDA et VoiceOver — pour tester avec des lecteurs d'écran sur Windows et macOS/iOS.
• Keyboard only — je désactive la souris et parcours l'interface uniquement au clavier pour identifier les pièges de focus.
• tota11y — pour des repères rapides, surtout utile en ateliers avec des équipes non techniques.

Processus étape par étape

• 1. Inventaire : je collecte les pages modèles, composants et les scénarios utilisateurs prioritaires (ex. inscription, commande, prise de contact).
• 2. Scan automatique : j'exécute Axe et Lighthouse sur chaque page modèle pour obtenir une première liste d'erreurs.
• 3. Revue manuelle : navigation au clavier, contrôle des headings, labels des champs, gestion des erreurs de formulaire, focus management, ordre logique, sens des liens “lire la suite”, etc.
• 4. Tests avec lecteurs d'écran : vérification du rendu vocal, annonces ARIA, ordre de lecture, désignation des boutons.
• 5. Tests utilisateurs : idéalement 3 à 5 tests avec personnes en situation de handicap. J'observe les stratégies d'accès, les blocages et note les recommandations.
• 6. Rapport : je documente chaque problème avec le contexte, la règle WCAG correspondante, une capture d'écran, un niveau (A/AA/AAA), une proposition de correction et une estimation d'effort.

De l'erreur à la correction : comment prioriser

Une longue liste de tickets n'aide pas les équipes. J'utilise une matrice priorisation basée sur l'impact utilisateur et l'effort de mise en œuvre. Le but est d'agir vite sur ce qui apporte le plus de bénéfice.

Par exemple, corriger des images sans attribut alt (impact élevé, faible effort) est souvent une victoire rapide. En revanche, repenser un composant complexe pour le rendre accessible (impact élevé, fort effort) nécessite une planification et parfois une refonte du design system.

Écrire des tickets exploitables

Un ticket utile contient :

• Un titre clair (ex. "Champ 'Téléphone' : label absent" )
• La page ou le composant impacté
• La règle WCAG concernée (ex. WCAG 2.1 AA 1.1.1 pour les images textuelles)
• Une description du problème et du comportement attendu
• Un exemple reproductible (étapes, capture d'écran, enregistrement audio si pertinent)
• Une proposition de correction technique et designer (HTML, ARIA, CSS) et une estimation d'effort

Mesurer les progrès et établir des KPIs

Pour garder le cap, je définis des KPIs accessibles et concrets :

• Nombre d'erreurs critiques (niveau A/AA) ouvertes vs corrigées
• Taux de réussite des parcours clés en tests utilisateurs
• Score d'accessibilité Lighthouse / Axe (mesuré sur un panel de pages)
• Temps moyen de correction des tickets accessibilité

Je mets souvent en place un dashboard (ex. dans Jira + tableau de bord) pour suivre ces indicateurs sprint après sprint. L'idée est d'intégrer l'accessibilité comme une métrique produit, pas seulement une checklist ponctuelle.

Bonnes pratiques pour éviter la réapparition des problèmes

• Documenter dans le Design System les patterns accessibles (ex. modales, menus, composants de formulaire) avec code d'exemple.
• Ajouter des tests automatisés dans la CI (axe-core, pa11y) pour attraper les régressions en amont.
• Former l'équipe : ateliers de sensibilisation pour développeurs, designers et rédacteurs. La qualité des contenus (microcopie, labels) a un impact direct sur l'accessibilité.
• Inclure des critères accessibilité dans la définition de fini (DoD) des tâches.

Cas concrets et retours d'expérience

Sur un projet e-commerce, j'ai identifié que le parcours panier devenait inaccessible pour les utilisateurs n'utilisant que le clavier à cause d'un overlay mal géré. En corrigeant le focus management et en ajoutant des attributs aria-hidden/aria-modal appropriés, le taux d'abandon sur mobile a diminué. Sur une plateforme B2B, une série de micro-corrections (labels, ordre logique des champs, messages d'erreur explicites) a réduit le volume de support lié aux formulaires de 20%.

Ces exemples montrent que l'accessibilité n'est pas seulement une contrainte légale ou morale : c'est une amélioration directe de l'expérience utilisateur et souvent un gain business mesurable.

Ressources et lecture

• WCAG 2.1 — comprendre les critères
• Deque University & Axe documentation — pour règles techniques
• Guides Apple/Google sur VoiceOver et TalkBack — pour tests mobile
• tota11y / WAVE / Lighthouse — pour audits rapides

Si vous le souhaitez, je peux vous fournir un template d'audit (checklist + modèle de ticket) adapté à votre site ou vous accompagner pour mener un audit étape par étape avec votre équipe. L'accessibilité, comme toute discipline du web, s'améliore avec des pratiques régulières et une vraie collaboration entre design, dev et utilisateurs.