Rattraper l’accessibilité d'une application : guide de survie pour les équipes

Comment améliorer significativement le niveau d'accessibilité d'un produit numérique ? C’est le défi auquel nous avons été confrontés lorsqu’un audit de conformité a révélé que l’application mobile et le site web que développait notre équipe d’Octos atteignaient des taux respectifs de 55 % et 36 % seulement. Quatre mois plus tard, un contre-audit a validé que les deux produits avaient respectivement atteint 77 % et 81 % — une amélioration considérable.

Comment avons-nous relevé ce défi ? Quels enseignements en tirer pour toute équipe confrontée à un produit non conforme ? Dans cet article, nous vous racontons notre parcours vers une meilleure accessibilité et proposons des conseils concrets aux équipes qui se trouvent dans une situation similaire.

1. Accessibilité : une obligation

L'accessibilité n’est pas facultative : c’est un standard de qualité du numérique mais aussi une obligation légale pour le secteur public et pour les grandes entreprises du secteur privé. Au-delà de la conformité, l’accessibilité améliore l’expérience pour tous et élargit l’audience des produits numériques.

On la contrôle à l’aide de référentiels — RGAA, obligatoire pour le web en France et RAAM, pour le mobile — et en mesurant la conformité à ceux-ci via des audits réguliers. La mesure du taux de conformité n’est pas une finalité : l’audit permet d’identifier toutes les erreurs à corriger.

Le blog des Octos propose déjà plusieurs articles sur le pourquoi du sujet, donc on ne va pas s’y attarder dans ce guide. Si vous voulez approfondir vos connaissances, commencez par les racines de l’accessibilité web, explorez les gains UX pour les utilisateurs à travers l’accessibilité, puis complétez avec en quoi l’accessibilité mobile est devenue incontournable dans les usages.

2. Les mauvais résultats de l’audit accessibilité : une prise de conscience

L’audit a listé les non‑conformités (NC) sans en expliquer l’origine. Un post‑mortem a permis d’identifier deux types de mauvaises pratiques dans le développement de ces produits :

2.1 Organisationnel

• Priorisation des fonctionnalités au détriment des NFR (non-functional requirements) : l’accessibilité a été reléguée au second plan, créant un rattrapage coûteux après coup.
• Manque de compétences d’accessibilité au sein de l’équipe : l’accessibilité n’est pas une checklist mais un savoir-faire. Sans sensibilisation ni formation, les bons choix n’ont pas été faits.

2.2 Technique

• Non‑respect des standards : structure des titres, boutons non labellisés, focus clavier défaillants, etc.
• Dette d’accessibilité : accumulation de bugs d’inaccessibilité dans le code depuis des années.
• Dépendances tierces non conformes : l’intégration de services tiers, bien que non conçus en interne, pénalise la note.
• Limites de la stack (Flutter) : ce framework ne permet pas de mettre en place certains comportements accessibles.

3. Choisir la bonne approche pour améliorer l’accessibilité de façon pragmatique

Une fois ce post-mortem réalisé, nous avons établi une stratégie pragmatique pour améliorer l’accessibilité des produits. Se sont posées les questions suivantes :

1. Quel taux de conformité visons-nous ?
2. Par quelles NC commencer ? avec quelle approche ?
3. Quel effort est nécessaire pour effectuer les corrections ?
4. Comment piloter et évaluer nos progrès ?
5. Comment pérenniser l'accessibilité par la suite ?

3.1 Fixer un cap

Nous avons souhaité fixer un objectif ambitieux, tout en prenant en compte les contraintes techniques (Flutter, services externes intégrés) qui rendaient impossible l’obtention d’une parfaite conformité. Nous avons donc convenu avec notre client de viser un taux de conformité de 80% sur chacun des 2 produits.

3.2 Classer les corrections

L’équipe technique a cartographié les non-conformités sur une matrice croisant leur occurrence et leur facilité de correction pour aider à prioriser le travail. Ce processus a aidé à isoler rapidement les ajustements que nous ne pouvions pas traiter, ce qui a permis au PO de se concentrer sur les changements qui avaient un fort impact sur le taux de conformité.

3.3 Définir l’approche et l’effort de correction

Nous avons identifié 3 approches différentes qui ont chacune des avantages et inconvénients.

Plutôt que d'en choisir une, nous les avons toutes déployées en séquence adaptée, pour un gain maximal en efficacité et impact utilisateur :

• Dans un premier temps, l’approche "par non-conformité" (2 mois) : cette méthode consistait à corriger exhaustivement toutes les non-conformités d'un critère RGAA / RAAM à la fois (ex. : contrastes, balisage ARIA). L’objectif ici était de remonter le score le plus rapidement possible. Elle s'est avérée efficace pour les erreurs isolées, passant le taux de 36% à 56% pour le web par exemple. Cependant, elle s'essoufflait vite sur les dysfonctionnements systémiques répandus dans le code, et nous éloignait d'une vraie logique utilisateur.
• Ensuite, l'approche par page/composant (1,5 mois) : une fois ces critères stabilisés, nous avons pivoté vers la validation de parcours utilisateurs de bout-en-bout sur des pages ou composants spécifiques. Travailler sur un périmètre plus restreint nous a fait gagner énormément de temps. Par exemple, lors des tests de création de compte, l’approche précédente nous obligeait à tout reconfigurer à chaque essai (création de nouveaux comptes, données de test, etc.). En testant uniquement sur une seule page, nous pouvions réutiliser le même environnement sans tout recréer à chaque fois. Résultat : environ deux heures de manipulation en moins par série de tests — et bien moins de frustration pour l’équipe.
• Enfin, approche "impact utilisateur" (2 semaines) : pour transcender la logique de score, nous avons fait le choix de corriger des NC isolées qui impactaient des personnes en situation de handicap, même si nous savions que cela ne ferait pas remonter le taux, puisque les corrections n’étaient pas applicables partout. Cela a permis d'adresser des finitions à fort levier fonctionnel, comme le focus clavier ou des alternatives gestuelles, assurant une accessibilité fluide et inclusive.

4. Passer à l’action : corriger de manière intelligente

Après l’audit, nous avons voulu aller vite et “corriger tout de suite”. Mauvaise idée : à vouloir réparer sans alignement, nous avons perdu du temps… Nous avons alors compris qu’une correction durable passe par une approche collective et structurée. Corriger intelligemment, c’est d’abord travailler ensemble — pas simplement corriger rapidement.

4.1 Impliquer les parties prenantes dès le début

Pour garantir l’efficacité des corrections, il est essentiel d’impliquer tous les métiers à l'œuvre dès le démarrage : développeurs, designers, PO, PM. L’accessibilité dépend de décisions prises tout au long de la chaîne de développement (orientations produit, design, développement, recette). Si une étape échoue, les efforts des autres sont compromis.

Cette approche favorise également l’entraide et la motivation, car corriger l’accessibilité exige rigueur et persévérance. Sans cohésion d’équipe, le découragement peut rapidement s’installer.

Dynamique Dev/PO/QA :

• Analyse collective du rapport d’audit dès le départ pour lever les zones d’ombre et aligner les priorités. Nous ne l’avons fait qu’après nos premières incompréhensions… et avons vite réalisé que cela aurait évité des blocages.
• Approche en binôme : pendant qu’un développeur applique une modification, le PO ou QA vérifie directement l’impact. Résultat : moins d’allers-retours et validation rapide. En présentiel, cette méthode est particulièrement efficace. Attention au lecteur d’écran dans l’open space qui peut déranger vos collègues ;)

4.2 Structurer la correction comme une épique dédiée et suivre les progrès

La dette d’accessibilité étant importante, traiter ce chantier comme un simple refactoring dilué dans les sprints était inadapté. L’accessibilité a donc été considérée comme une épique à part dans le backlog produit, offrant plusieurs avantages :

• Visibilité accrue : sujet traité en revue de roadmap et sprint planning
• Maîtrise du coût : estimation macro pour anticiper l’effort requis
• Suivi des progrès : mesure du volume d’effort vs capacité allouée et nombre de non-conformités corrigées

Ce choix a toutefois mis en pause d’autres chantiers fonctionnels, soulignant le coût de l’absence d’anticipation.

Suivi centralisé via Excel : face à la lourdeur des User Stories par critère (re-création pour redesigns, avalanche de commentaires en recette), un fichier Excel a centralisé le suivi :

• Statut, priorité et pages concernées par critère
• Liens vers le rapport d’audit et commentaires (blocages, décisions)
• Recalcul du taux de conformité RGAA après chaque validation

Ce tableau de bord s’est révélé précieux lors des sprint reviews. L’accessibilité étant parfois difficile à démontrer concrètement, afficher un taux de conformité en progression a permis de rassurer le Product Manager et les parties prenantes. Plutôt qu’une liste interminable de tickets ouverts, on pouvait montrer une avancée tangible et motivante pour toute l’équipe.

5. Conseils avant le contre-audit : maximiser ses chances de succès

Après plusieurs mois d’efforts pour corriger les non-conformités, l’étape du contre-audit est cruciale : c’est le moment où tout notre travail est évalué. Pour éviter les mauvaises surprises et optimiser nos chances d’atteindre un bon taux, nous avons pris quelques précautions :

• Limiter les évolutions sur le produit : nous avons fait très attention aux nouvelles fonctionnalités sur les 4 mois de révision. Pourquoi ? Parce que chaque nouveau développement peut potentiellement introduire de nouveaux défauts d’accessibilité. On a donc mis un coup de frein sur les évolutions produit, en se concentrant sur la correction des erreurs existantes pour éviter de jouer au jeu du "un pas en avant, deux pas en arrière".
• Tester avec les mêmes outils que les auditeurs : les outils utilisés par les auditeurs ne sont pas toujours ceux que l’on utilise au quotidien. On a donc pris soin de tester notre produit avec les mêmes extensions et logiciels qu’eux et nous assurer que les modifications étaient bien apportées avec les mêmes outils (Axe DevTools, Voice Over, test sur iOS pour la version mobile, test sur Chrome pour la version web etc.).

6. Assurer un suivi pour éviter de retomber dans les mêmes travers

L’accessibilité ne se corrige pas une fois pour toutes : il faut éviter les régressions. Pour cela, nous avons mis en place trois leviers complémentaires.

6.1 Tests automatisés dans le CI/CD

Une partie des critères d’accessibilité web peut être vérifiée automatiquement (par exemple les attributs manquants, la sémantique incorrecte, etc.) via des librairies. Ces tests ne couvrent pas tout (environ 25% de la conformité attendue), mais ils sont simples à intégrer et permettent de détecter rapidement les erreurs les plus basiques.

Sur mobile, les librairies sur étagère étaient plus limitées : nous avons choisi de ne pas écrire de tests customisés coûteux pour la phase de remise à niveau, mais cette option reste pertinente pour prévenir les régressions à plus long terme.

6.2 Vérifications régulières tout au long du cycle

Pour éviter que les problèmes réapparaissent, nous avons intégré l’accessibilité dès la conception et dans la Definition of Done. Chaque user story devait respecter les Easy Checks du W3C.

6.3 Sensibilisation et montée en compétence

L’accessibilité est une expertise qui n’est pas facile à maîtriser. Plutôt que d’imposer une formation théorique longue et complexe, nous avons opté pour une approche progressive et pratique :

• Une initiation aux "Easy Checks" du W3C web et mobile : en deux heures, on vous explique les bases de l’accessibilité et les tests à réaliser pour identifier les erreurs d’accessibilité courantes.
• Des sessions de test en autonomie : chaque membre de l’équipe (dev, PO, designers) a appris à utiliser des outils comme Axe DevTools, Contrast Checker ou encore VoiceOver. Ce n’est pas au seul PO/QA de réaliser ces tests : toute l’équipe doit être autonome.

À noter : nous avons bénéficié de l’appui de la communauté d’experts d’OCTO, qui nous a aidés à lever des doutes, interpréter certains critères et trouver des solutions adaptées aux cas les plus complexes.

7. Qu’est-ce qu’il nous a manqué pendant ce rattrapage ?

Aujourd’hui, connaître rapidement le niveau d’accessibilité réel d’un produit est très difficile. La plupart des vérifications sont manuelles et il n’existe aucun indicateur simple permettant d’évaluer la conformité à un instant T. Le calcul du taux de conformité légal est sévère : une seule régression sur une page fait chuter le taux global, même lorsque l’ensemble du produit présente un bon niveau d’accessibilité.

Les audits donnent une vision précise mais ponctuelle et les outils automatisés comme Lighthouse restent limités : ils ne couvrent qu’une partie des critères et n'opèrent pas sur les applications mobiles.

En pratique, il manque donc un moyen fiable et transversal capable d’offrir une vue synthétique et instantanée de l’accessibilité d’un produit numérique. C’est, selon nous, un élément clé pour piloter les produits de demain.

Conclusion

Se saisir de l’accessibilité ne se résume pas à une checklist technique mais réclame une démarche globale : stratégie claire, collaboration d’équipe et suivi rigoureux, intégrée dès la conception. Impliquez toutes les parties prenantes, structurez vos progrès, testez régulièrement avant de faire appel à des experts pour les cas complexes.

Elle n’est jamais "terminée". Les produits évoluent ; sans réflexes proactifs (tests auto, checklists, sensibilisation), la conformité s’effrite vite. Bonne nouvelle : une fois les bonnes pratiques assimilées et les Easy Checks maîtrisés, développer accessible devient un réflexe.

Nous espérons que cet article vous préparera utilement à la correction d’un produit non-conforme et à la mise en place de bonnes pratiques d’accessibilité. Lancez-vous avec pragmatisme — les résultats suivront.