Un développeur aveugle apprend à un agent IA à ne pas inventer d'erreurs d'accessibilité dans le code

Imaginez : un agent IA examine un formulaire et annonce avec assurance que le champ n'a pas d'aria-describedby. Vous ouvrez le code, et le lien avec l'aide contextuelle est créé depuis longtemps par le composant de formulaire de la bibliothèque. Ce genre de fausses alertes ruine la confiance dans un audit plus vite que des bugs manqués. C'est ce qu'a vécu un programmeur non voyant qui utilise un lecteur d'écran et développe Accessibility Auditor Skill, un ensemble d'instructions pour un agent qui vérifie l'accessibilité à partir du code source et sur des sites en production.

Regarder l'implémentation, pas le point d'appel

La principale modification du skill : avant de qualifier quoi que ce soit de problème, l'agent remonte du lieu d'utilisation jusqu'à l'implémentation. Il détermine quel élément reçoit le focus, d'où vient son nom accessible, où sont créés le libellé, l'aide contextuelle et le message d'erreur, comment les identifiants sont transmis et ce que fait la version installée de la bibliothèque. Il vérifie aussi que le fichier trouvé intervient bien dans le scénario concerné : les dépôts contiennent souvent d'anciens composants aux noms similaires, et corriger un tel fichier ne change rien pour l'utilisateur.

Si le lien est réellement perdu dans un composant partagé, c'est là qu'il faut corriger et vérifier tous les champs concernés. S'il existe déjà, inutile de le dupliquer.

Leçons tirées de PR concrètes

Dans la PR pour RTL, l'agent a analysé les messages d'authentification et de chargement. Les rôles status et alert définissent déjà le mode de vocalisation ; un assertive ou un role="alert" superflu peut donc couper la parole du lecteur d'écran. Pour un spinner placé à côté d'un texte, la règle est la suivante : si le message figure déjà dans le texte, on ne donne pas le même nom accessible à l'indicateur décoratif, on le masque avec aria-hidden. Cette PR a été fermée sans fusion, l'extrait ne montre donc que la modification proposée ; la vocalisation réelle doit être vérifiée dans l'application en fonctionnement.

Dans Vets-Who-Code, la propriété feedbackId a été ajoutée trop largement à l'interface partagée et s'est retrouvée accessible à des composants qui ne la géraient pas. D'où la règle : en ajoutant une propriété, déterminer qui la prend en charge et si elle risque d'atterrir dans le HTML comme attribut superflu. Les identifiants sont testés dans deux cas : généré et transmis de l'extérieur. Sinon l'exemple standard fonctionne, tandis qu'un formulaire avec son propre ID perd le lien avec l'erreur.

Dans suitenumerique/docs, la correction dépendait d'un élément interne de Cunningham Select. La bibliothèque peut modifier son balisage et le sélecteur se briserait. Le skill privilégie désormais l'API publique et, en cas d'accès aux éléments internes, exige un test de régression sur les aria-hidden et tabindex finaux. Lors de cette itération, ces vérifications ont été ajoutées à un test Playwright, mais l'exécution e2e complète n'a pas été lancée.

Un résultat accepté et des limites assumées

La seule PR acceptée citée est Nextcloud iOS n° 4111, acceptée le 28 mai 2026. Les lignes de dossiers dans la fenêtre de choix de l'emplacement d'enregistrement n'avaient pas de nom accessible : VoiceOver se plaçait sur l'élément sans nommer le dossier. L'agent a construit le nom à partir du titre et des informations déjà affichées dans la cellule, écarté les valeurs vides et attribué à la ligne le trait de bouton. Seul le code source a été vérifié : ni compilation iOS ni test avec VoiceOver, faute de Xcode dans l'environnement.

L'auteur écrit sans détour qu'il ne dispose d'aucune mesure de la proportion de fausses alertes avant et après les modifications. Il a des règles et des cas qui les ont motivées. C'est pourquoi l'agent doit préciser dans son rapport ce qu'il a réellement fait : analysé le code, lancé des tests ou écouté un lecteur d'écran. Ce sont des niveaux de confiance différents.

Ce qu'il faut retenir

Si vous construisez des agents de revue de code, ne vous limitez pas à un seul fichier. Obligez l'agent à suivre la chaîne depuis l'appel jusqu'à la bibliothèque et à vérifier les consommateurs des composants partagés. Consignez les leçons de vraies PR directement dans les instructions pour ne pas les réexpliquer dans chaque projet. Et exigez de l'agent qu'il nomme honnêtement le type de vérification : lire le code ne remplace pas un test avec lecteur d'écran sur un appareil.