Réflexion du 31 décembre 2025 : la der des ders de l'année. Comme un pseudo bilan. Avant de faire un AVC, lire jusqu'au bout…
L'accessibilité numérique, c'est magnifique sur le papier.
Des référentiels bien ficelés (RGAA, WCAG), des audits qui cochent des cases, des rapports en PDF avec plein de couleurs. Tout le monde est content. Enfin, presque…
L'audit
Ou l'art de pointer du doigt dans le vide.
Un audit d'accessibilité, c'est un peu comme une inspection des lieux par quelqu'un qui n'a jamais tenu un marteau.
Le rapport arrive, 47 pages, police Calibri 11pt : « Bouton sans label », « Contraste insuffisant à 4.49:1 », « Navigation clavier compromise ».
Techniquement irréprochable. Factuellement juste.
Et ensuite ? Silence radio. Le plus souvent, en tout cas.
Parce que l'auditeur ne sait pas que votre CMS propriétaire encapsule tout dans des Shadow DOM inaccessibles. Que votre design system impose des composants non modifiables. Que le bouton incriminé est généré par un plugin tiers dont la dernière mise à jour remonte à 2019. Que toucher au HTML casse l'intégration analytics qui fait vivre la boîte.
Le rapport dit quoi corriger. Il ne dit que rarement comment faire quand on a les mains liées par une stack technique choisie par le service achat il y a 5 ans.
L'auditeur
Ou celui qui n'a jamais ouvert un éditeur de code.
Parlons franchement : combien d'auditeurs accessibilité ont déjà écrit une ligne de JavaScript en production ? Combien savent ce qu'est un Shadow DOM, un Web Component, ou pourquoi React encapsule le state d'une certaine façon ?
Le problème n'est pas qu'ils ne codent pas — on peut être excellent auditeur sans être développeur. Le problème, c'est quand l'audit ignore totalement la faisabilité technique.
Exemple vécu :
« Le datepicker doit être accessible au clavier avec navigation fléchée dans le calendrier. »
Réponse technique : « Le datepicker vient d'un plugin jQuery acheté sur CodeCanyon en 2016. Il est intégré dans 23 formulaires différents. Le code source est minifié et obfusqué. Le remplacer nécessiterait de refaire toute l'architecture de formulaires, impactant 47 pages et 3 autres services. Budget estimé : 6 mois de dev. »
Réponse audit : « Non-conformité critique. À corriger. »
Merci, super utile.
Un auditeur qui a déjà mis les mains dans le cambouis sait faire la différence entre :
- « Ajoutez
aria-labelsur ce bouton » (5 minutes) - « Modifiez ce composant React pour gérer le focus » (2 jours si on connaît React)
- « Remplacez ce framework propriétaire » (irréaliste dans 90% des cas)
Il ne s'agit pas de faire coder les auditeurs. Il s'agit qu'ils comprennent les implications techniques de leurs recommandations. Qu'ils sachent prioriser : « Ce contraste sur le footer est à 4.4:1 au lieu de 4.5:1, ce n'est pas votre priorité. Par contre, votre formulaire principal sans labels, là oui, c'est bloquant. »
Mais soyons clairs : le problème n'est pas l'audit en soi. Un bon audit qui dialogue avec l'équipe technique, qui comprend les contraintes, qui priorise ce qui compte vraiment pour les utilisateurs — ça existe, et c'est précieux.
Le problème, c'est quand l'audit devient un simple document de conformité administrative déconnecté de la réalité du terrain, rédigé par quelqu'un qui n'a jamais eu à implémenter ses propres recommandations.
Conformité ≠ Accessibilité
Spoiler : personne ne veut l'entendre.
Petit rappel qui fâche : un site conforme WCAG peut être parfaitement inutilisable.
Vous pouvez avoir tous vos attributs ARIA bien rangés, vos contrastes validés au dixième de ratio près, votre navigation clavier qui fonctionne… et quand même livrer une expérience atroce. Parce que la conformité mesure des critères techniques, pas l'utilisabilité réelle.
À l'inverse, certaines adaptations pragmatiques — un système de détection de navigation clavier/souris pour gérer intelligemment le focus, un datepicker conditionnel selon le mode d'interaction — n'existent dans aucun référentiel mais améliorent concrètement la vie des utilisateurs.
La conformité, c'est le minimum syndical. L'accessibilité, c'est faire en sorte que ça marche vraiment. Nuance.
Le terrain
Bienvenue dans le monde réel !
Sur le terrain, on ne fait pas de l'accessibilité dans un monde de bisounours. On la fait dans le réel :
-
Stack fermée : « Ah bah non, on peut pas modifier ce composant, c'est du propriétaire sous licence. Par contre on peut ouvrir un ticket au support. Délai de réponse : 6 à 8 semaines. »
-
Framework legacy : React 16, Vue 2, Angular 8, ou pire : un truc maison codé en 2014 par un stagiaire parti élever des chèvres en Ardèche. Bonne chance pour patcher proprement.
-
Budget/temps : « On a 2 jours pour corriger les 47 non-conformités, c'est jouable ? » Narrateur : Non.
-
Maintenance : La correction élégante que vous avez bricolée en 3h ? Elle va péter à la prochaine mise à jour du CMS. Puis au changement de navigateur. Puis quand le stagiaire touchera au CSS.
-
Tests utilisateurs : « Des tests avec de vrais utilisateurs handicapés ?" — "Ah non, pas de budget pour ça non plus. »
Et pendant ce temps, entre l'auditeur qui a rendu son rapport et l'équipe technique qui essaie de corriger, il manque souvent un acteur crucial : quelqu'un qui fait le pont, qui traduit les recommandations en solutions viables, qui priorise selon l'impact réel. Le fameux consultant (certains disent expert) en accessibilité, qui n'est pas forcément un auditeur dans l'âme.
Le design veut sa liberté
L'accessibilité, c'est moche !
Ah, et on parle du service marketing/branding qui débarque avec sa charte graphique "disruptive" ?
Direction artistique : « On veut du gris rgb(235,235,235) sur fond blanc #FFFFFF, c'est épuré, c'est moderne. »
Vous : « C'est aussi illisible. Le contraste mini—fade »
DA : « L'accessibilité c'est important MAIS pas au détriment de l'identité de marque. »
Traduction : l'accessibilité, c'est bien tant que ça ne se voit pas.
Le outline bleu sur le focus ? Ça casse l'esthétique. La navigation clavier ? On s'en fout, personne n'utilise ça. Surtout sur mobile, hein !
Spoiler (encore) : des millions de gens utilisent ça. Mais ils ne sont pas dans le brainstorming créatif en open space avec babyfoot et smoothies.
La bonne nouvelle : il est tout à fait possible de faire de l'accessibilité élégante. Un focus bien designé, des contrastes qui respectent l'identité visuelle, une navigation clavier fluide — ça existe, et c'est même souvent plus beau que le design initial. Mais ça demande que les designers soient formés à l'accessibilité dès la conception, pas en mode "patch de dernière minute".
RGAA, WCAG, EAA
Le casse-tête européen des référentiels.
Parlons maintenant du vrai bordel : les référentiels multiples.
En France, on a le RGAA (Référentiel Général d'Amélioration de l'Accessibilité). Il est basé sur les WCAG 2.1 (2.2, un jour…), mais avec des spécificités françaises, une méthodologie propre, des critères reformulés.
En Allemagne, c'est la BITV. En Espagne, la UNE 139803. En Italie, autre chose. Chaque pays a développé sa propre déclinaison des WCAG.
Et maintenant, arrive l'European Accessibility Act (EAA), applicable depuis juin 2025 dans les 27 pays de l'UE. L'EAA impose des obligations d'accessibilité harmonisées pour tous les produits et services numériques vendus dans l'Union.
Question légitime : si votre entreprise vend dans toute l'Europe, vous êtes conforme à quoi exactement ?
- Conforme RGAA en France ?
- Conforme BITV en Allemagne ?
- Conforme EAA partout ?
- Conforme WCAG 2.2 niveau AA (la norme internationale de référence) ?
La réponse pragmatique : visez directement les WCAG 2.1 niveau AA (ou mieux, WCAG 2.2). C'est la base commune reconnue internationalement. Flûte quoi !
Le RGAA, la BITV et les autres référentiels nationaux sont des transpositions des WCAG avec des spécificités locales, mais la colonne vertébrale reste la même.
Pourquoi cette fragmentation ?
Parce que chaque pays a voulu adapter les WCAG à son contexte légal, à sa langue, à ses obligations administratives. Le RGAA français intègre par exemple des obligations propres au droit français (mentions légales, cookies, etc.). C'était logique… en 2009.
Le problème en 2025 : si vous devez produire un audit RGAA pour la France, un audit BITV pour l'Allemagne, et prouver votre conformité EAA pour l'ensemble du marché européen, vous allez multiplier les coûts, les audits, et les incohérences. Et beaucoup d'impossibilités à la clé.
La solution réaliste :
- Respectez les WCAG 2.1 (ou 2.2) niveau AA comme base technique universelle
- Complétez avec les spécificités nationales obligatoires (mentions légales, cookies, etc.) uniquement pour les sites ciblant spécifiquement un pays
- Documentez votre conformité EAA en démontrant que votre respect des WCAG couvre les exigences européennes
Dans un monde idéal, l'Europe aurait adopté un référentiel unique basé sur les WCAG. Dans le monde réel, on jongle avec plusieurs normes qui disent globalement la même chose avec des mots différents. Pragmatisme, toujours.
Audit vs Terrain : construisons des ponts
L'auditeur théorique et l'intégrateur terrain ne jouent pas dans la même ligue :
- L'auditeur voit un état des lieux figé, documente les manquements, part avec son virement bancaire.
- L'intégrateur voit 374 contraintes techniques, 12 parties prenantes contradictoires, un budget de 3 cacahuètes et un délai déjà dépassé.
L'auditeur dit "il faut". L'intégrateur répond "avec quoi ?".
Et entre les deux, l'utilisateur handicapé (ou pas, d'ailleurs) attend toujours que le bouton "Valider" soit enfin utilisable au clavier.
Mais ça pourrait être différent.
Imaginez un audit où l'auditeur discute avec l'équipe technique avant de rédiger son rapport. Où on priorise ensemble les correctifs selon leur impact réel sur les utilisateurs. Où on identifie les solutions maintenables plutôt que les patchs qui vont péter au prochain déploiement.
Imaginez une équipe technique qui intègre l'accessibilité dès la conception, qui teste avec de vrais utilisateurs, qui forme ses développeurs, qui documente ses composants accessibles réutilisables.
Ce n'est pas de l'utopie. C'est juste du travail collaboratif. Ça demande du temps, du budget, de la formation — mais ça existe, dans des équipes qui ont décidé de faire de l'accessibilité un pilier, pas une contrainte de dernière minute.
L'accessibilité vraie
Pragmatisme et dialogue
L'accessibilité réelle ne se décrète pas depuis un rapport PDF. Elle se construit dans le code, dans les compromis, dans les réunions où on défend un role="button" face à un chef de projet qui ne comprend pas pourquoi "ça marche déjà à la souris".
Elle se fait avec :
- Une connaissance intime du code et de ses limites
- La capacité à trouver des solutions maintenables (pas juste "qui marchent aujourd'hui")
- Le courage de dire non au design quand c'est nécessaire
- La patience d'expliquer pour la 47ème fois pourquoi le focus doit être visible
- Le dialogue entre tous les acteurs : auditeurs, développeurs, designers, chefs de projet, utilisateurs
L'audit donne la direction. Le terrain fait le boulot. Et entre les deux, il faut des gens qui traduisent, qui priorisent, qui accompagnent. Oh ! Revoilà le consultant !…
Conclusion
Travaillons ensemble
Un bon audit ne balance pas 47 pages de reproches sans contexte. Il discute avec ceux qui vont devoir implémenter. Il prend en compte les contraintes. Il priorise ce qui compte vraiment pour les utilisateurs.
Ce qui peut aussi vouloir dire qu'il faut revoir la manière de réaliser des audits…. Il ne s'agit pas d'un contrôle technique de voiture.
Un bon professionnel terrain ne rejette pas l'audit en bloc. Il le traduit en solutions viables, il argumente quand c'est infaisable, il propose des alternatives.
Un bon designer intègre l'accessibilité dès la conception, et découvre souvent que ça améliore l'expérience pour tout le monde.
Et surtout : tout le monde arrête de confondre conformité et accessibilité. L'une est un score, l'autre est une expérience utilisateur.
L'accessibilité n'est pas un combat des uns contre les autres. C'est un travail d'équipe.