Votre site affiche un taux de conformité RGAA de 40 %. L’audit vient de tomber, les résultats sont mauvais, et la direction demande un plan d’action.
- Par où commencer ?
- Combien de temps prévoir ?
- Comment organiser l’équipe sans paralyser le reste du delivery ?
C’est une situation que de plus en plus d’équipes projet rencontrent. L’accessibilité numérique n’est plus un sujet de niche, c’est une obligation légale pour le secteur public et les grandes entreprises du privé, et un standard de qualité que les clients exigent de plus en plus dans leurs appels d’offres.
Cet article est un guide opérationnel. Il décrit, étape par étape, la méthode pour rattraper un retard d’accessibilité sur un produit existant, en s’appuyant sur des retours d’expérience concrets. L’objectif n’est pas de théoriser sur l’importance de l’accessibilité (on suppose que vous êtes déjà convaincus), mais de vous donner une feuille de route actionnable.
Étape 1 : Comprendre pourquoi vous en êtes là
Avant de corriger, il faut diagnostiquer. Un mauvais score d’accessibilité n’arrive jamais par hasard. Il résulte généralement d’une combinaison de facteurs organisationnels et techniques qu’il est essentiel d’identifier pour ne pas reproduire les mêmes erreurs. Vous pourrez d’ailleurs comprendre les méthodes permettant d’auditer l’accessibilité de votre site depuis cet article.
Les causes organisationnelles les plus fréquentes sont la priorisation systématique des fonctionnalités au détriment des exigences non fonctionnelles (NFR), le manque de compétences accessibilité au sein de l’équipe, et l’absence d’accessibilité dans la Definition of Done des user stories.
Côté technique, on retrouve le non-respect des standards HTML sémantiques (structure des titres, boutons non labellisés, focus clavier défaillant), l’accumulation de dette d’accessibilité dans le code sur plusieurs années, les dépendances tierces non conformes qui pénalisent le score global, et parfois les limites intrinsèques du framework utilisé.
Ce diagnostic est indispensable. Il conditionne la stratégie de rattrapage : vous n’aborderez pas le problème de la même façon selon que la cause principale est un déficit de compétences, une dette technique massive, ou des contraintes de framework.
Conseil opérationnel :
Organisez un post-mortem dédié avec l’ensemble de l’équipe (dev, design, PO, PM) avant de lancer la moindre correction. Listez les causes identifiées et classez-les par impact. Ce travail de 2 à 3 heures vous évitera des semaines de corrections mal orientées.
Étape 2 : Fixer un objectif réaliste
Viser 100 % de conformité RGAA est rarement réaliste sur un produit existant avec des contraintes techniques. Certaines non-conformités dépendent de services tiers que vous ne maîtrisez pas. D’autres sont liées à des limitations du framework qui nécessiteraient une refonte complète.
L’approche pragmatique consiste à fixer un objectif ambitieux mais atteignable, en concertation avec le client ou le sponsor. Un passage de 36 % à 80 % en quatre mois est un objectif crédible qui démontre un engagement réel tout en restant compatible avec les contraintes d’un delivery en cours.
Conseil opérationnel :
Identifiez dès le départ les non-conformités que vous ne pourrez pas corriger (contraintes framework, services tiers, limitations techniques avérées). Documentez-les et partagez-les avec les partie prenantes. Cela permet de calibrer les attentes et de concentrer l’effort sur les corrections qui auront un impact réel.
Étape 3 : Cartographier et prioriser les non-conformités
L’audit produit une liste de non-conformités (NC) qui peut être longue et décourageante. L’erreur classique est de commencer à corriger dans l’ordre du rapport. L’approche efficace consiste à cartographier les NC sur une matrice croisant deux dimensions : leur occurrence dans le produit (combien de pages/écrans sont impactés) et leur facilité de correction.
Cette matrice fait émerger quatre catégories. Les corrections à fort impact et faciles à réaliser sont à traiter en priorité, c’est là que le ratio effort/résultat est le meilleur. Les corrections à fort impact mais complexes nécessitent une planification dédiée. Les corrections à faible impact et faciles peuvent être intégrées au fil de l’eau. Les corrections à faible impact et complexes sont à reporter ou à documenter comme limitations connues.
Conseil opérationnel :
Construisez cette matrice en atelier avec l’équipe technique. Comptez une demi-journée. Le PO doit y participer pour arbitrer les cas où le gain en conformité entre en conflit avec d’autres priorités produit.
Étape 4 : Déployer trois approches en séquence
L’expérience montre qu’aucune approche unique ne suffit. La stratégie la plus efficace combine trois méthodes déployées en séquence, chacune adaptée à une phase du rattrapage.
Phase 1 : l’approche par non-conformité (≈ 2 mois)
On commence par corriger exhaustivement toutes les occurrences d’un même critère RGAA à travers le produit. Par exemple, il faut corriger tous les contrastes insuffisants, puis tous les attributs ARIA manquants et toutes les structures de titres incorrectes.
Cette approche est très efficace au démarrage car elle fait remonter le score rapidement. Elle permet aux développeurs de se concentrer sur un type de correction à la fois, ce qui améliore la vélocité. En revanche, elle s’essouffle sur les dysfonctionnements systémiques plus profonds.
Phase 2 : l’approche par page ou composant (≈ 1,5 mois)
Une fois les critères les plus simples corrigés, on pivote vers une validation de bout en bout sur des pages ou composants spécifiques. On prend une page, on la rend entièrement conforme, puis on passe à la suivante.
Cette approche fait gagner un temps considérable sur les tests. Plutôt que de reconfigurer un environnement complet à chaque vérification, on travaille sur un périmètre restreint et maîtrisé. Les retours d’expérience font état de gains de l’ordre de deux heures par série de tests.
Phase 3 : l’approche par impact utilisateur (≈ 2 semaines)
Pour finir, on cible les corrections qui améliorent concrètement l’expérience des personnes en situation de handicap, même si elles n’ont pas d’impact mesurable sur le score de conformité. C’est le cas du focus clavier, des alternatives gestuelles, ou de la navigation au lecteur d’écran.
Cette dernière phase transcende la logique de score pour revenir à l’objectif fondamental de l’accessibilité : rendre le produit utilisable par tous.
Étape 5 : Organiser l’équipe pour la correction
La tentation initiale est de foncer tête baissée dans les corrections. C’est une erreur. Sans alignement d’équipe, on perd du temps en allers-retours, en incompréhensions du rapport d’audit, et en corrections qui ne passent pas la recette.
Voici les pratiques organisationnelles qui font la différence.
Analyser collectivement le rapport d’audit dès le départ. Toute l’équipe (dev, PO, QA, design) doit comprendre les non-conformités identifiées, les critères concernés, et les attentes du référentiel. Ce temps investi au démarrage évite des semaines de blocages.
Travailler en binôme dev/PO ou dev/QA. Pendant qu’un développeur applique une correction, le PO ou QA vérifie directement l’impact avec les outils d’audit. Moins d’allers-retours et les validations seront plus rapides. En présentiel, cette méthode est particulièrement efficace.
Traiter l’accessibilité comme une EPIC dédiée dans le backlog, pas comme un refactoring dilué dans les sprints. Cela donne de la visibilité au sujet en sprint planning et en revue de roadmap, permet d’estimer et de suivre l’effort, et facilite la communication avec les parties prenantes.
Centraliser le suivi dans un tableau de bord. Un fichier Excel ou Notion qui consolide le statut de chaque critère, la priorité, les pages concernées, et le taux de conformité recalculé après chaque série de corrections. Ce tableau est précieux en sprint review pour montrer une progression tangible.
Étape 6 : préparer le contre-audit
Après plusieurs mois de corrections, le contre-audit est le moment de vérité. Deux précautions permettent de maximiser les chances de succès.
- Limiter les évolutions produit dans les semaines précédant le contre-audit. Chaque nouvelle fonctionnalité peut introduire de nouvelles non-conformités. Concentrez-vous sur la stabilisation et la correction, pas sur le développement de nouvelles features.
- Tester avec les mêmes outils que les auditeurs. Les résultats varient selon les outils utilisés. Identifiez les outils de référence de votre auditeur (Axe DevTools, VoiceOver, NVDA, etc.) et testez votre produit avec ces mêmes outils. Un critère peut sembler conforme avec un outil et ne pas l’être avec un autre.
Étape 7 : pérenniser l’accessibilité dans la durée
L’accessibilité n’est jamais « terminée ». Indépendamment de la règlementation en constante évolution comme c’est le cas pour la RGAA 5, les produits évoluent, les équipes changent, et sans mécanismes de protection, la conformité s’effrite sprint après sprint. Trois leviers permettent de pérenniser les acquis.
Tests automatisés dans le pipeline CI/CD
Une partie des critères d’accessibilité web (environ 25 % de la conformité attendue) peut être vérifiée automatiquement via des librairies comme axe-core ou pa11y. Ces tests ne couvrent pas tout, mais ils détectent rapidement les régressions les plus basiques : attributs manquants, sémantique incorrecte, contrastes insuffisants.
Intégration dans la Definition of Done
Chaque user story doit inclure une vérification accessibilité avant d’être considérée comme terminée. Les Easy Checks du W3C fournissent une checklist pragmatique que n’importe quel membre de l’équipe peut appliquer en quelques minutes.
Ce que ça change du point de vue gestion de projet
En tant que PMO, le rattrapage de l’accessibilité m’a appris plusieurs choses qui s’appliquent bien au-delà de ce seul sujet.
La première, c’est que le coût du rattrapage est toujours supérieur au coût de l’anticipation. Intégrer l’accessibilité dès le début d’un projet coûte une fraction de ce que coûte un rattrapage de quatre mois sur un produit existant. C’est un argument que nous portons systématiquement chez WexIT dans nos cadrages de projet : les NFR (accessibilité, performance, sécurité) doivent être intégrés dès le sprint zéro.
La deuxième, c’est que l’accessibilité est un sujet transversal qui ne peut pas être délégué à une seule personne. C’est un effort collectif qui implique le design, le développement, la QA et le pilotage projet. L’organiser comme une épique dédiée avec un suivi structuré est la clé du succès.
La troisième, c’est qu’il manque encore cruellement d’outils de monitoring continu de l’accessibilité. Les audits donnent une photo ponctuelle, les outils automatisés ne couvrent qu’une fraction des critères, et il n’existe pas de tableau de bord fiable permettant de suivre la conformité en temps réel. C’est un espace d’innovation qui mériterait d’être investi.
Pour les équipes qui se retrouvent face à un audit d’accessibilité décevant : ne vous découragez pas. Avec une stratégie claire, une organisation rigoureuse et l’implication de toute l’équipe, un rattrapage significatif est possible en quelques mois. Et une fois les bons réflexes acquis, développer accessible devient naturel.
Besoin d’un nouvel audit accessibilité pour passer à l’action ?
Un mauvais score RGAA ne se rattrape pas à l’aveugle.
Chez WexIT, nous auditons votre site sur les 106 critères du RGAA, nous vous aidons à prioriser les non-conformités, et nous fournissons votre déclaration de conformité. En option, nous pouvons aussi vous accompagner sur la mise en conformité. L’audit est annoncé comme livré sous environ 2 semaines.
→ Demander un devis pour un audit accessibilité en cliquant ici.
