a11y-raweb
En production
a11y-raweb est notre skill d’accessibilité pour assistants IA, fondé sur le RAWeb 1.1. Un skill est un ensemble d’instructions et de références que l’assistant charge quand la tâche le demande.
Ce qu’il apporte à l’assistant
- Les 17 thématiques du RAWeb 1.1, critère par critère. L’assistant ne charge que la thématique utile à la demande.
- Pour chaque critère, ce qu’il exige et comment le vérifier, avec des exemples de code dans la plupart des cas. Les 106 critères communs avec le RGAA portent leur intitulé officiel, recopié mot pour mot.
- Sept règles tirées de la pratique de l’audit : préférer l’élément HTML natif ; savoir quand doubler une balise par son rôle ARIA, selon le référentiel ; calculer correctement le nom accessible ; faire figurer le texte visible dans le nom accessible ; masquer un texte sans le retirer des technologies d’assistance ; ne pas ajouter d’écoute clavier inutile sur un élément natif ; calculer un rapport de contraste avec un script, jamais de tête.
- Les différences entre le RAWeb et le RGAA qui changent un verdict d’audit, par exemple sur le focus clavier ou les rôles des zones de page. Un audit RAWeb ne vaut pas audit RGAA : le skill le dit et liste les écarts.
Ce qu’on en fait
Écrire du code accessible à partir d’une spécification. Auditer du code en citant les critères. Proposer des corrections justifiées. Répondre aux questions techniques d’une équipe.
Référentiels couverts
RAWeb 1.1, référentiel pivot. RGAA 4.1.2, qui en partage les critères et la numérotation. WCAG 2.1. La norme EN 301 549 v3.2.1 est couverte à travers le RAWeb. Six critères des WCAG 2.2, absents du RAWeb 1.1, sont traités à part comme anticipés.
Comment nous le vérifions
Chaque numéro de critère et chaque intitulé sont contrôlés automatiquement contre le fichier officiel du RGAA publié par la DINUM. Le niveau des critères dont les références WCAG mêlent A et AA est relevé sur la page officielle des critères du RAWeb 1.1. Les rapports de contraste des exemples sont calculés par script. Chaque version est consignée dans un journal.
Ce qu’il ne fait pas
- Il ne contrôle pas le code produit. Le code doit passer les tests et l’audit.
- Il ne remplace pas la formation de l’équipe.
- Il couvre le code web seulement : pas les applications mobiles natives, pas les documents PDF ou bureautiques, pas la déclaration d’accessibilité ni l’audit formel, pas les spécificités des frameworks.
- Il se charge quand la demande touche à l’accessibilité. Une demande qui n’en parle pas peut ne pas le déclencher.
- Il couvre l’EN 301 549 à travers le RAWeb, sans correspondance clause par clause.
- Il suit le RAWeb 1.1 et la version 3.2.1 de l’EN 301 549. Il suivra leur prochaine version.
- Il est rédigé en français.
Statut et accès
| Statut | En production |
|---|---|
| Version | 1.1.1, octobre 2026 |
| Accès | Sous licence, dans le cadre de l’offre Outiller vos équipes |
| Licence seule | Sur demande |
| Versions | Journal des versions |
| Pour en bénéficier | Outiller vos équipes |
Pour les design systems
design-md-a11y étend le format DESIGN.md avec des règles d’accessibilité. Voir sa fiche
Outiller votre équipe
Nous installons a11y-raweb dans vos assistants compatibles. Nous écrivons aussi des skills pour votre design system et vos règles internes, avec la même méthode.
Les autres produits
a11y-assistant
Assistant IA d’audit d’accessibilité : il prépare le rapport, la grille de critères et la déclaration, rédige des spécifications à partir des maquettes et explique les critères en contexte.
Catalogue A2UI
Composants React accessibles pour les interfaces qu’un agent IA génère, avec leur validateur.
a11y-engine
294 règles écrites par le cabinet : 62 concluent seules, les autres signalent un point à faire lire par un humain. Aujourd’hui, il alimente sept tests d’a11y-assistant.
design-md-a11y
Écrit les règles d’accessibilité de votre design system dans le fichier que lisent vos assistants de code ; son outil de contrôle, design-md-a11y-lint, vérifie qu’elles sont tenues.