RGAA
Définition
Référentiel Général d'Amélioration de l'Accessibilité. Norme française qui définit les exigences d'accessibilité numérique pour les sites publics et certaines entreprises privées.
Le contexte légal
Le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) est le référentiel français de l'accessibilité numérique, publié par la DINUM. Il transpose les WCAG dans le cadre juridique français et s'impose à toutes les administrations, aux entreprises publiques, aux délégataires de service public, et aux entreprises privées de plus de 250 millions d'euros de chiffre d'affaires en France. Depuis la loi de 2005 et ses évolutions successives, le non-respect expose à des sanctions financières (jusqu'à 25 000 euros par service non conforme) et à des actions en justice de la part d'utilisateurs ou d'associations.
Le contenu du référentiel
La dernière version (RGAA 4) compte 106 critères répartis en 13 thèmes : images, cadres, couleurs, multimédia, tableaux, liens, scripts, éléments obligatoires, structuration de l'information, présentation, formulaires, navigation, consultation. Chaque critère se décline en tests précis avec des méthodologies de vérification documentées. Les sites doivent publier une déclaration d'accessibilité indiquant leur taux de conformité, un schéma pluriannuel et un plan d'action. Pour les sites publics, le taux affiché doit être supérieur à 50% pour ne pas afficher la mention non conforme.
Ce qui change concrètement
Côté développement, on traite plusieurs sujets en parallèle. Les images décoratives ont alt vide, les images informatives ont un alt descriptif. Les contrastes texte/fond sont supérieurs à 4,5:1 (3:1 pour les grandes tailles). La navigation au clavier traverse tous les éléments interactifs dans un ordre logique, avec un focus visible. Les formulaires associent chaque champ à un label explicite et indiquent les erreurs de validation accessible. Les composants riches (modal, dropdown, tabs) utilisent les rôles et états ARIA corrects. La hiérarchie des titres respecte la logique sémantique HTML.
Quand l'aborder
L'erreur classique consiste à traiter l'accessibilité en fin de projet, en mode rattrapage. Le coût explose : refaire un design system non accessible, corriger des composants legacy, ajouter de l'ARIA partout, c'est trois fois plus cher que d'avoir intégré ces contraintes dès la maquette. On l'aborde dès le cadrage : le designer connaît les contrastes, le développeur utilise des composants accessibles (Radix UI, Headless UI, shadcn/ui), et les tests automatisés (axe-core, Lighthouse) tournent en CI à chaque PR. Un projet bien démarré atteint le niveau attendu sans douleur.
Les outils et l'évaluation
Pour mesurer la conformité, on combine plusieurs approches. Les outils automatisés (axe DevTools, Wave, Lighthouse) détectent environ 30% des problèmes : contrastes, alt manquants, structure incorrecte. L'audit manuel par un expert RGAA (ou un cabinet spécialisé) couvre le reste : navigation clavier complète, lecteur d'écran (NVDA, VoiceOver), tests utilisateurs en situation de handicap. Pour les sites publics, l'audit doit être réalisé par une entité tierce indépendante tous les trois ans. Pour les sites privés, on peut le faire en interne mais on tient une trace écrite des tests.
Notre approche
Sur les projets Next.js, on intègre l'accessibilité dans le pipeline standard. Le design system utilise shadcn/ui ou Radix qui gèrent ARIA et clavier nativement. Les images passent par next/image avec alt obligatoire. Les vidéos ont sous-titres et transcription. Les couleurs respectent les contrastes WCAG AA dès la palette. Un lint axe-core tourne en CI sur chaque PR pour attraper les régressions. Pour un site public en obligation de conformité, on prévoit un budget audit externe et un plan de correction sur 2 à 3 cycles. On documente ce qui est conforme, ce qui ne l'est pas, et le calendrier des corrections.