Code accessible et conforme WCAG avec une IA ?

Vous aimez le MMA, les combats de rue ? Ce billet ne va pas parez de ça. Mais, on peut se faire un petit combat qui va vous permettre de comprendre Accessibilité Numérique et IA (Vibe Coding).

AI hhas transfomed how we work, but it alos inhereted our mindset on the way we buld

On démarre.

Les combattants

1. Leurs fiches façon Pokemon

Nom	Type	Attaques	Points forts	Faiblesse
Maître Access	Expert·e accessibilité	Audit précis — Tests utilisateurs — Priorisation des corrections	Sait repérer et expliquer chaque obstacle d’accès	Ralentit parfois la livraison pour tout corriger
Bot-Builder	Vibe codeur IA	Génération rapide — Intégration express — Prompt tuning	Très rapide à produire des interfaces et prototypes	Croire que l’IA suffit — oublis d’accessibilité réels

2. Leurs approches

Carte	Approche pour coder	Méfiance
Maître Access	Conception avec tests utilisateurs, checks manuels (lecture d’écran, clavier), intégration d’a11y dès la conception	Méfie des livraisons rapides sans validation humaine ; exige preuves d’usage
Bot-Builder	Prototype rapide via IA, itérations basées sur feedback visuel et tests automatisés	Méfie des processus lents et des contraintes perçues comme frein à la productivité

Comment une IA génère du code ?

Si on se fit à cet article AI has an accessibility problem: What devs can do about it, on peut voir que l’IA ne génère pas de code accessible à la première demande.

Première demande

On désire un code pour une fenêtre modale. Et on obtient ce genre de chose.

<button id="openModalBtn">Open Modal</button>
<div id="myModal" class="modal">
  <div class="modal-content">
    <span class="close" id="closeModalBtn">&times;</span> 
    <form id="userForm">
      <label for="name">Name: </label>
      <input type="text" id="name" name="name" required>
      <label for="email">Email:</label>
      <input type="email" id="email" name="email" required>
      <button type="submit">Submit</button>
    </form>
    <div id="greeting" style="display:none; margin-top:15px;"></div>
  </div>
</div>

Qu’est-ce qui ne va pas ?

Pour les utilisateurs qui navigue au clavier clavier, il est impossible de fermer la fenêtre. Si vous chercher <span class="close">&times;</span>, et bien cet élément ne prend pas le focus (élément interactif dans la page), on ne peut pas l’activer, l’utilisateur est bloqué dans la fenêtre.

C’est pas marrant du tout d’être bloqué sur une page. Parfois on doit recommencer du début en rechargeant une page.

Demandes suivantes

Jemima va ensuite montrer que pour améliorer le code, il faut faire plusieurs demande plus précise à l’IA. Ok. Mais quelle type de demandes ?

Une demande qu’une personne qui connaît l’accessibilité numérique (WCAG, RGAA) sait faire.

« Crée moi une fenêtre contextuelle accessible qui permet aux utilisateurs de saisir leur nom et leur adresse e-mail, et qui affiche un message d’accueil une fois les informations soumises. »

Le résultat est bien mieux, les défaut du début sont corrigés. L’IA est allé chercher une meilleure réponse. La seconde demande est allé cassé la première recherche probabiliste qui est allé se nourrir parmi le code plus plus souvent rencontré.

Il semble que le premier code viendrait d’une tutorial très bien référencé qui néglige l’accessibilité. Ainsi à force de ne pas pratiquer l’accessibilité sur nos services numériques, il est fort probable qu’il faille constamment forcer les IA à aller chercher le bon code.

Et ça c’est que pour code plutôt simple et récurrent sur les services numérique. Pas un code spécifique, voire très spécifique.

L’approche des combattants

Revenons à notre combat. Nos combattants sont bien caricaturaux. Notre expert accessibilité peut-être déconnecté de que les IA peuvent produire si on sait les utiliser ; notre Vibe Codeurs ne sait même pas que l’accessibilité numérique existe.

On observe un fossé entre les 2 pratiques. Si vous allez plus loin dans l’article, Jemima montre que si vous savez ce qu’il faut produire comme code pour qu’il soit accessible, il est potentiellement obligatoire de forcer l’IA pour avoir le code « conforme ».

« Est-il possible d’utiliser une boîte de dialogue et de corriger les erreurs de prise en charge et de style du navigateur ? Ou pensez-vous qu’il vaut mieux utiliser un modal JavaScript personnalisé ? »

Toutes ces demandes sont coûteuses. Coûteuses en temps, coûteuses en charge sur le IA… et si vous ne connaissez pas l’accessibilité, vous devrez appeler votre expert interne (non… vous en avez pas ?) pour confirmer que c’est valide.

En codant avec l’IA, on se retrouve dans une situation dans laquelle l’expert accessibilité devrait auditer tout le code pour savoir s’il est accessible (sachant que l’IA pisse du code), puis refaire tout le chemin pour savoir pourquoi le code n’est pas accessible en allant étudier comment ont été formulés tous les prompts pour générer le code.

De l’autre codé le Vibe Codeur qui voudrait être conforme à la norme, lui serait confiant, pensant que l’IA n’a qu’à être nourrie par des dépôts de code accessible. En améliorant les connaissance de l’IA, il suffirait de lui dire : génère moi du code accessible.

Le fossé

J’espère avoir réussi à vous monter le fossé entre les 2 approches.

Dans l’une, l’origine de la raison pour laquelle un code n’est pas conforme n’est pas exactement connue puisqu’on ne sait pas d’où le code provient exactement, quel chemin a été parcouru pour le produire.

Dans l’autre, un codeur qui pense qu’il suffirait de mieux formuler une demande pour répondre à l’obligation légale.

Si vous limitez l’accessibilité à une question technique, vous allez droit dans le mur.

L’accessibilité c’est comprendre que si une personne handicapée a mis 2h à créer un panier de course, qu’en cherchant les case à cocher (qui n’existe pas) pour déclarer son handicap pour avoir la livraison gratuite, elle se retrouve dans une fenêtre modale qu’elle ne peut pas fermer… alors le dite n’est pas accessible.

Qui va penser à « prompter » ce parcours particulier, quand le prompteur est potentiellement une personne qui gère l’ensemble de tout le service numérique avec sa voix ?

La méthode

Encore une fois, le technicien vous dira que tout est possible : « il suffit de ». Il suffit de, effectivement, savoir quels sont les parcours sur lesquels être attentifs, connaître la loi, connaître l’accessibilité….

Mais l’état des lieux c’est qu’il n’existe pas vraiment de code accessible (un Design System est toujours incomplet), l’accessibilité est une histoire de contexte. Les développeurs sont trop peu formés à l’accessibilité, il manque des experts accessibilité dans les structures.

En soit, l’IA pose la question d’avoir à disposition des supers experts en accessibilité en interne. Le plus souvent, les experts en accessibilité ne connaissent pas le fonctionnement du BackEnd. Ces profils sont très rares.

Il faudrait des experts accessibilité pour rendre les prompts accessibles. Pour générer du code accessible, mais aussi pour garantir l’interopérabilité avec les technologies d’assistance (qu’il faut connaître), le respect de différentes cultures, la compréhension pour des personnes avec des difficultés cognitives…

Il faudrait des experts pour aller forcer les IA à prendre en compte la conception inclusive. Mais des experts partout ? Derrière chaque équipe ?

Comment on garantit ça dans une organisme ?