Accessibilité générée par l’IA : mise à jour — les modèles “frontier” échouent encore, mais les compétences changent la donne

Il y a quelques mois, j’ai partagé des premiers résultats du projet A11y LLM Eval, un benchmark qui mesure à quel point les LLM génèrent du code d’interface accessible. Le billet précédent montrait que, par défaut, les LLM produisent du code inaccessible, que des consignes explicites d’accessibilité peuvent faire une différence énorme, et que des tests manuels restent indispensables.

Le dernier rapport est publié : nouveaux modèles, périmètre de test repensé, et tout nouveau mécanisme : les compétences (skills). Deux points ressortent :

1. Les modèles “frontier” les plus récents (GPT‑5.5, Claude Opus 4.7, Gemini 3.1 Pro Preview, Claude Haiku 4.5, et d’autres) échouent encore aux vérifications d’accessibilité par défaut.
2. Une skill bien écrite peut produire les meilleurs taux de réussite que nous ayons mesurés. Les skills peuvent même permettre à un modèle avec une base faible de dépasser les leaders, même si elles peuvent coûter davantage de jetons (tokens) à exécuter.

Notez que le taux de réussite reflète uniquement les contrôles automatisés de ce banc de test (un ensemble sélectionné de règles axe-core WCAG, plus des assertions écrites à la main pour chaque cas). Les tests automatisés ne peuvent détecter qu’une partie des problèmes d’accessibilité : un “100%” ici signifie que l’échantillon a passé chaque vérification exécutée, pas que la page est conforme WCAG ou entièrement accessible.

TL;DR

• L’accessibilité par défaut (“control”) reste mauvaise : le taux de réussite moyen est 12%, avec GPT‑5.4 Mini en tête à 25%. Plus récent ne veut pas dire plus accessible.
• Les consignes personnalisées portent encore leurs fruits. L’ensemble de consignes “Basic” augmente les taux de réussite de +48,5 points jusqu’à 60%.
• Les skills vont plus loin. La skill Building Accessible UI, exécutée en workflow en deux tours (Generate puis Review), atteint 86% de taux de réussite (+74,6 points). La meilleure performance est Gemini 3.1 Pro Preview, un modèle qui n’obtenait que 8% sur le contrôle.
• Le tour de review de la skill coûte environ 5,5× le nombre de jetons d’entrée du contrôle. La qualité n’est pas gratuite.

Quoi de neuf dans ce rapport

• Les résultats sont désormais totalement “agentic” (pilotés par un agent). Le rapport précédent appelait les API des LLM directement avec une seule requête et une réponse. Ici, chaque évaluation passe par le GitHub Copilot SDK comme un agent réel, avec utilisation d’outils, raisonnement multi-tours, et le même chargement des instructions et des skills que les agents Copilot en production. Les chiffres ci-dessous décrivent donc comment ces modèles se comportent lorsqu’ils sont encapsulés dans une boucle d’agent, pas dans un appel API “one-shot”. Cela signifie aussi que la variante “skills” n’est possible que parce qu’on passe par un environnement d’exécution agent.
• 8 modèles évalués sur 32 cas de prompts (1 280 échantillons en contrôle). La sélection de modèles est majoritairement récente : GPT‑5.4, GPT‑5.4 Mini, GPT‑5.5, Claude Opus 4.7, Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro Preview, et Gemini 3 Flash Preview.
• Les ensembles d’instructions suivis sont désormais Basic et Minimal. L’ensemble détaillé de niveau expert du run précédent n’est pas inclus ici.
• Les skills, des paquets de guidance réutilisables et spécifiques à une tâche, ont été ajoutées comme nouveau mécanisme. La première skill évaluée est Building Accessible UI. Plus de détails plus bas.
• Un nouveau type de jeton et un instantané du taux de réussite permettent de comparer la qualité par rapport au coût en tokens entre contrôle, instructions et tours de skill.

Contrôle : modèles “frontier”, même problème d’accessibilité

Le principal résultat du billet précédent était que, par défaut, les LLM produisent du code inaccessible. Avec les derniers modèles, cela n’a pas changé.

Quelques observations :

• GPT reste en tête sur le contrôle, mais le meilleur score est très inférieur à celui annoncé précédemment (41% pour GPT‑5.2). L’ensemble de prompts a changé et les assertions sont plus strictes : les chiffres ne sont donc pas directement comparables, mais la conclusion est la même : personne ne livre du code accessible par défaut.
• Claude Haiku 4.5 est à 3%, avec une moyenne d’environ 6 échecs WCAG par échantillon. Sonnet 4.6 et Gemini 3 Flash Preview ne sont pas loin derrière.
• Le cas de test le plus difficile, Shopping Home Page (React, Dark theme), produit un taux de réussite de 0% avec 15,55 échecs WCAG en moyenne sur l’ensemble des modèles. La densité des composants aggrave le problème très vite.

L’hypothèse sur les données d’entraînement du précédent billet semble toujours tenir. Le web ouvert est dans l’ensemble largement inaccessible : les modèles entraînés dessus héritent de ces schémas, quelle que soit leur capacité générale à écrire du code.

Ensembles d’instructions : le gain le moins coûteux

Les consignes personnalisées restent le moyen le plus rapide pour une équipe d’améliorer l’accessibilité.

Le fichier d’instructions Basic produit presque 5× le taux de réussite du contrôle, tout en n’augmentant que d’environ 50% les tokens d’entrée moyens. Même la consigne minimale en une ligne (“All output MUST be accessible.”) le triple plus que ça.

Si vous ne faites rien d’autre, livrez un fichier d’instructions. Les instructions de base sont un bon point de départ pour les adapter à la stack et au design system de votre équipe.

Skills : le nouveau mécanisme

Le plus gros changement de ce rapport, c’est l’introduction des skills. Là où les ensembles d’instructions sont toujours actifs et chargés dans le contexte de l’agent pour chaque tâche, une skill est un paquet réutilisable, spécifique à une tâche, qui regroupe guidance, exemples, fichiers de support, scripts, et un workflow d’utilisation d’outils. L’agent charge la skill uniquement quand elle est pertinente, et, à l’intérieur de la skill, ne charge que le fragment nécessaire pour la tâche en cours.

Cela change deux choses à la fois : la nature de la guidance que le modèle voit, et le moment où il la voit. Les skills peuvent contenir beaucoup plus de détails qu’un fichier d’instructions sans noyer la fenêtre de contexte, et le pattern en deux tours (Generate puis Review) donne au modèle un second regard structuré sur sa propre sortie avant d’avoir fini. C’est pour cela que les skills surpassent les instructions dans ce rapport.

La première skill évaluée est Building Accessible UI. Elle est conçue pour :

• s’activer quand l’agent crée de l’UI, afin que le code généré soit plus accessible par défaut ;
• contenir une guidance de niveau expert et des checklists pour de nombreux composants et motifs ;
• ne tirer la guidance que pour le composant ou le motif précis, afin de limiter l’impact token sur la fenêtre de contexte ;
• exécuter un workflow en deux tours : générer l’UI, puis la revoir en la comparant à la checklist de la skill et corriger les problèmes.

Quelques observations :

• Le meilleur modèle dans la skill est Gemini 3.1 Pro Preview, le même qui obtenait 8% sur le contrôle. Avec le bon “scaffolding”, un modèle de base faible peut dépasser les leaders.
• Le tour de review compte. Demander à l’agent de s’auto-vérifier avec la checklist de la skill ajoute +5,6 pp par-dessus un premier tour déjà solide, ce qui ressemble davantage à la façon dont un reviewer humain en accessibilité travaille.
• Les skills ne dominent pas le prompt. Seuls 14 à 18% des jetons d’entrée proviennent de la skill elle-même, contre 100% pour les ensembles d’instructions. La majeure partie de la fenêtre de contexte reste libre pour la tâche réelle.

La question du coût

Les skills gagnent en qualité, mais elles ne sont pas gratuites.

Le tour de review de la skill consomme en moyenne environ 5,5× les tokens d’entrée et 2,7× le nombre d’appels d’API du contrôle. À grande échelle, cela représente un budget significatif.

Une répartition pratique :

• Les ensembles d’instructions couvrent large et servent de garde-fous toujours actifs. Peu coûteux à livrer, et excellent ratio entre amélioration d’accessibilité et tokens dépensés. Le revers, c’est que l’impact tokens des consignes personnalisées peut grimper vite si votre projet a des instructions pour plusieurs domaines (accessibilité, sécurité, contenus, etc.). Utilisez-les comme défaut pour toute équipe, mais gardez-les courtes.
• Les skills sont une guidance procédurale ciblée pour des tâches plus “à enjeux”, ou lorsque vous disposez du budget nécessaire.

Recommandations

Les conseils du billet précédent restent valables, avec un nouveau levier :

1. Livrez dès aujourd’hui un fichier d’instructions adapté à votre projet. Démarrez avec les instructions Basic et personnalisez-les pour votre stack, votre design system et votre bibliothèque de composants.
2. Ajoutez une skill pour les tâches UI à plus haut enjeu si votre budget tokens le permet. Le pattern en deux tours (Generate puis Review) améliore significativement les résultats.
3. Intégrez des contrôles automatisés d’accessibilité dans CI/CD et bloquez les PR en cas de régressions.
4. Gardez les tests manuels par des humains, y compris des personnes en situation de handicap. Aucun de ces outils (contrôles automatisés, instructions, ou skills) ne couvre tous les besoins d’accessibilité.

Conclusion

La trajectoire n’a pas changé. L’IA continue d’augmenter la quantité d’UI qu’on produit, et les données d’entraînement du web ouvert continuent d’amplifier les motifs inaccessibles à côté. Les modèles “frontier” seuls ne vont pas résoudre ça : les derniers résultats de Claude 4.7, Gemini 3.1 et GPT‑5.5 le montrent clairement.

En revanche, la boîte à outils a changé. Les instructions restent utiles en quelques minutes. Les skills sont un nouveau levier, et un levier puissant : elles font passer un modèle à 8% de baseline à 86% sur ces contrôles. Le travail consiste maintenant à choisir le bon outil pour la bonne tâche, l’imposer dans CI, et garder des humains dans la boucle quand c’est le plus important.

Voir le rapport complet et le dépôt a11y-llm-eval sur GitHub .