Plan d’action RGAA : du rapport aux corrections
Un rapport d’audit ne vaut que s’il devient un plan d’action : une liste de corrections priorisées, avec des propriétaires, une timeline et une méthode de validation. Voici une approche simple et opérationnelle.
1) Triage : transformer les résultats en “unités de travail”
Les résultats RGAA sont souvent nombreux. Votre tâche consiste à regrouper : même thématique, même composant, mêmes patterns de non-conformité.
- Regroupez par thématique (images, navigation, formulaires…)
- Regroupez par composant récurrent (header, modals, formulaires, cartes)
- Choisissez une “granularité” gérable (1 correction = 1 pattern)
2) Prioriser avec un critère “impact parcours”
La priorisation doit être orientée utilisateur : un bloc sur la navigation clavier ou un formulaire critique peut être plus urgent que des détails d’UI.
- Priorité forte : navigation clavier, actions essentielles, formulaires clés
- Priorité moyenne : composants récurrents mais moins critiques
- Priorité à planifier : cas rares ou nécessitant une décision de contenu
3) Cadrer les critères manuels (sans flou)
Pour les critères manuels, évitez l’ambiguïté. Donnez une check de validation et un “qui décide”.
- Définissez les tests attendus (clavier, focus visible, messages compréhensibles)
- Associez la validation à une personne ou une équipe métier
- Formulez les critères de “pass” (qu’est-ce qui prouve que c’est bon ?)
4) Définir une timeline et des revalidations
Le RGAA doit progresser par itérations. À chaque itération, vous revalidez sur des pages représentatives.
- Définissez des lots de corrections (par patterns)
- Préparez une revalidation (scan + tests clavier)
- Documentez ce qui change pour alimenter la déclaration
5) Rendre le plan actionnable pour la déclaration
Votre plan d’action doit être utilisable tel quel dans la déclaration d’accessibilité. Le lecteur doit comprendre : quoi, quand, comment.
- Utilisez la même structure thématique que votre audit
- Reliez dérogations et décisions aux constats correspondants
- Préparez une checklist “prête à publier”
Ressources utiles
FAQ rapide
Que faire si le plan devient trop long ?
Refaites le tri par patterns et priorisez impact parcours. La déclaration doit refléter une trajectoire réaliste, pas tout corriger d’un coup.
Comment éviter les “corrections qui reviennent” ?
Corrigez au niveau composant/pattern, pas au niveau incident. Puis revalidez sur des variantes et états.
Quelles validations faire avant publication ?
Re-scan sur pages représentatives et check clavier/focus sur composants critiques. Ensuite seulement : publication.
Prochain pas : si vous avez des dérogations, lisez comment les justifier pour garder une déclaration cohérente.