Le GAAD fête ses 15 ans : une accessibilité intégrée, pas rajoutée après coup

La plupart des conversations sur l’accessibilité prennent l’une de deux directions. Soit elles restent au niveau de l’impératif moral — « ce qu’il faut faire » —, soit elles virent au théâtre de la conformité : une liste de réglementations, une menace d’amendes, un audit ponctuel coché puis oublié.

Aucune de ces deux versions n’est utile à une équipe produit.

Cette année, pour la Global Accessibility Awareness Day (s’ouvre dans un nouvel onglet), nous avons fait les choses autrement. Nous avons mis deux personnes sur la sellette — Cian Dowling, Accessibility Lead chez Synthesia, et Darren Britton, notre CTO et Co-Founder — et leur avons demandé de parler franchement de ce à quoi ce travail ressemble vraiment de l’intérieur. Pas de slides. Pas de réponses toutes faites. Un échange ouvert.

Voici ce que vous avez manqué :

La digue qu’on ne construit qu’après l’inondation

Cian a une grille de lecture de l’accessibilité qui coupe court aux arguments habituels plus vite que n’importe quelle menace réglementaire.

« Si vous avez les protections contre les inondations les plus parfaites et qu’aucune inondation ne survient, qui va vous féliciter ? Personne. Mais si vous n’en avez pas ? C’est votre tête qui tombe.

Ce n’est que lorsque l’événement survient que cela touche votre portefeuille. Que se passe-t-il si quelqu’un vous dit : “Je vais vous refuser le plus gros contrat que vous ayez jamais eu parce que vous n’avez pas de VPAT” ? Tout le monde y perd, pas seulement les ingénieurs. »

C’est la conversation que la plupart des équipes produit évitent. Non pas parce que l’accessibilité les laisse indifférentes, mais parce que l’argument business n’a pas encore fait mouche. L’accessibilité relève de la même catégorie que la reprise après sinistre : invisible quand elle fonctionne, catastrophique quand elle fait défaut.

La différence, aujourd’hui, c’est que l’inondation est plus proche que ne le pensent la plupart des équipes.

La conformité n’intéresse personne avant qu’il ne soit trop tard

Lorsqu’il a rejoint Synthesia, Cian n’a pas d’abord appelé la communauté de l’accessibilité. Il a appelé le Head of Infosec.

« Je lui ai demandé : raconte-moi ce qui s’est passé il y a dix ans avec le RGPD. Comment as-tu réussi à mobiliser les gens avant qu’il ne soit trop tard ? Il m’a donné beaucoup de bons conseils. »

L’analogie avec le RGPD est la plus parlante pour un public varié. La plupart des équipes produit sont déjà passées par un cycle de conformité — SOC 2, RGPD, ISO 27001. Elles connaissent le schéma : cela semble facultatif, puis urgent, puis cela devient une condition pour faire affaire avec quiconque compte. Sinon, on passe à côté.

L’accessibilité suit le même cycle, avec deux ou trois ans de retard. Les entreprises qui la traitent dès maintenant comme une infrastructure sont celles qui signeront des contrats grands comptes en 2026 et 2027. Celles qui attendent devront tout reprendre dans l’urgence (et ça coûte cher).

« Je préfère largement agir de manière proactive et inscrire dans la feuille de route du prochain trimestre quelque chose qui en traite 20 %, plutôt que de rester les bras croisés à nous plaindre de ne pas avoir atteint 100 %. »

Le progrès plutôt que la perfection.

L’audit n’est pas un contrôle technique

Voici le piège dans lequel tombent la plupart des équipes. Elles commandent un audit. Elles reçoivent un rapport. Elles considèrent le rapport comme le travail. Puis elles l’oublient.

Sur ce point, Cian est direct : l’audit vous dit ce qui n’allait pas à un instant donné, il y a quelques mois. Pour une entreprise qui livre plus d’un millier de choses par mois, cette photographie est dépassée avant même que vous ayez fini de la lire.

« Je cherche bien plus à réduire, mois après mois, la quantité d’éléments inaccessibles que nous livrons qu’à résorber un backlog. L’audit n’est pas comme le contrôle technique de votre voiture — on n’y va pas une fois par an pour cocher la case. La question, c’est : qu’est-ce qui a conduit à ces problèmes, pour que le prochain audit en relève moins ? »

C’est une question de « definition of done ». Pas une question de sprint de correction.

Les équipes qui progressent réellement en matière d’accessibilité sont celles qui ont cessé de la traiter comme un projet pour la traiter comme une pratique. Une accessibilité portée par un champion (ou plusieurs) intégré aux équipes produit ou d’ingénierie. Intégrée au design system pour être correcte par défaut.

L’IA ne va pas résoudre ce problème. Elle pourrait même l’aggraver.

La question que nous entendons le plus souvent de la part des équipes produit en ce moment : l’IA ne va-t-elle pas tout simplement corriger cela automatiquement ? Ne peut-on pas passer notre codebase dans Claude ou GPT et faire résoudre nos problèmes d’accessibilité ?

Avant de rejoindre Synthesia, Cian a lui-même tenté de créer un outil d’accessibilité basé sur l’IA. Voici pourquoi cela ne fonctionne pas comme la plupart des gens le supposent.

« Si vous faites passer toute votre codebase dans un LLM, vous donnez les bijoux de famille. Vous n’avez pas vraiment envie de confier votre code propriétaire à un modèle tiers. »

Mais le problème de fond, ce sont les données sur lesquelles l’IA a été entraînée.

« Les LLM sont entraînés sur tout ce qui a été produit jusqu’à présent. 97 % d’Internet n’est pas accessible. Cela signifie que l’IA a été entraînée principalement sur du code inaccessible. Et les résultats le reflètent. »

Les composants React générés par l’IA font régulièrement l’impasse sur ARIA et le HTML sémantique. Les interfaces générées à l’exécution ne peuvent pas être auditées en amont. La vitesse à laquelle l’IA permet aux équipes de livrer fait que les régressions d’accessibilité arrivent avant que quiconque les examine. Les outils qui promettent d’aider les équipes à aller plus vite sont, pour beaucoup d’entre elles, en train d’inscrire discrètement une dette de conformité dans chaque release.

Cela ne veut pas dire que l’IA n’a aucun rôle à jouer. Cela veut dire que ce rôle est différent de ce que la plupart des gens imaginent.

« Exploiter le volume et l’échelle de ce que l’IA sait faire, mais y ajouter le jugement et le contexte humains pour réduire le travail — voilà ce qu’il vous faut. Un outil comme DevAlly permet à un spécialiste de l’accessibilité, ou à un ingénieur sensibilisé à l’accessibilité, d’abattre 5 fois plus de travail qu’il ne le pourrait autrement. Vous n’obtiendrez pas cela d’un LLM générique prêt à l’emploi. »

L’angle dont personne ne parle encore

Un sujet commence tout juste à émerger dans les discussions d’ingénierie, et il présente l’accessibilité au comité de direction sous un jour qui la sort complètement de la colonne « conformité ».

Les agents d’IA sont de plus en plus souvent des utilisateurs de logiciels. Et les qualités structurelles qui rendent un produit accessible aux utilisateurs de lecteurs d’écran — HTML sémantique, libellés appropriés, architecture de composants prévisible, rôles ARIA corrects — sont celles-là mêmes qui permettent à un agent d’IA de naviguer dans un produit.

Les équipes qui investissent dès maintenant dans l’accessibilité posent, sans le savoir, les bases de la compatibilité avec les agents.

Si votre produit ne passe pas l’épreuve d’un lecteur d’écran, il ne passera probablement pas non plus celle d’un agent.

L’accessibilité cesse d’être un coût de conformité. Elle devient un élément de votre stratégie de préparation à l’IA.

Que faire cette semaine

Le public de la GAAD a demandé à chaque intervenant une action concrète. Voici ce que nos intervenants ont retenu.

Darren Britton, CTO et Co-Founder, DevAlly : Commencez par vos trois principaux parcours utilisateur. Pas par un audit complet. Automatisez ce que vous pouvez, signalez ce qui nécessite un regard humain. Rendez quelque chose visible pour l’équipe d’ingénierie dès ce sprint.

Cian Dowling, Accessibility Lead, Synthesia : N’allez pas d’abord parler à la communauté de l’accessibilité. Allez voir votre Head of Infosec. Demandez-lui ce qui s’est passé il y a dix ans avec le RGPD. Demandez-lui comment cette personne a réussi à mobiliser les équipes avant qu’il ne soit trop tard. C’est cette conversation que vous devez reproduire, puis trouver le levier qui vous permettra d’entrer dans le calendrier de planification de l’ingénierie.

Et un conseil commun aux deux : ne commandez pas un rapport en le considérant comme le travail accompli. Le rapport n’est que le début du travail.

La version honnête de cette histoire

Au début de la conversation, Cian a dit quelque chose qui mérite qu’on s’y attarde.

« Quand on parle de conformité, c’est une tâche ingrate. Personne ne s’en soucie avant qu’il ne soit trop tard. Mais je ne pense pas qu’il suffise de rester les bras croisés à dire qu’il faudrait le faire. Nous livrons vite. Comme pour beaucoup des meilleures choses de la vie, quand on voit l’occasion, il faut la saisir et foncer. »

Intégrer l’accessibilité dès le départ n’est pas seulement le choix responsable. Pour une entreprise d’IA à 4 milliards de dollars qui livre plus d’un millier de modifications produit par mois, c’est le seul choix qui ait du sens sur le plan commercial.

Voilà à quoi ressemble concrètement une accessibilité intégrée dès la conception, et non ajoutée après coup.

DevAlly est une plateforme de conformité en matière d’accessibilité basée à Dublin. Nous aidons les équipes produit et d’ingénierie à détecter les problèmes d’accessibilité au plus tôt, à gérer des backlogs de correction priorisés et à générer la documentation de conformité qu’exigent désormais les services achats des grandes entreprises.

Vous voulez savoir où en est votre produit ? Lancez une analyse gratuite sur devally.com