GUIDE PRATIQUE GRATUIT
Checklist RGAA — Guide complet pour développeurs
40+ points concrets à vérifier sur vos interfaces, organisés selon les 4 principes RGAA/WCAG. Une checklist pratique de pré-audit, à utiliser avant toute démarche de conformité officielle.
À noter : Cette checklist est un outil de pré-audit pour développeurs — elle n'est PAS un audit de conformité RGAA officiel. Un audit officiel requiert un expert certifié suivant la méthodologie RGAA à 106 critères.
Perceptible (Perceivable)
Tout contenu et interface doit être présenté de manière perceptible par l'utilisateur, quels que soient ses sens.
- Chaque contenu non textuel (image, icône, graphique) possède une alternative textuelle pertinente (alt) ou est marqué décoratif (alt="").
- Les images porteuses d'information complexe (schémas, graphiques) disposent d'une description longue accessible.
- Les vidéos pré-enregistrées ont des sous-titres synchronisés.
- Les contenus audio pré-enregistrés ont une transcription textuelle.
- Le contraste des couleurs est d'au moins 4,5:1 pour le texte courant et 3:1 pour les grands textes.
- L'information n'est jamais véhiculée uniquement par la couleur (ex. champs d'erreur en rouge sans icône).
- La structure HTML est sémantique : balises <header>, <nav>, <main>, <footer>, titres <h1>-<h6> hiérarchisés.
- Chaque page comporte un seul <h1> décrivant son objet.
- Le contenu reste lisible et fonctionnel jusqu'à 200% de zoom texte.
- Aucun contenu essentiel n'est rendu inaccessible en orientation portrait ou paysage.
- Les champs de saisie identifient leur finalité (autocomplete="email", "name", etc.).
Utilisable (Operable)
L'interface doit pouvoir être utilisée par tous, notamment au clavier et avec suffisamment de temps.
- Toutes les fonctionnalités sont accessibles au clavier seul, sans piège clavier.
- Un indicateur de focus visible apparaît sur chaque élément interactif.
- L'ordre de tabulation suit l'ordre logique de lecture.
- Un lien d'évitement (skip-link) permet d'atteindre directement le contenu principal.
- Les limites de temps (session, formulaires) sont ajustables, extensibles ou désactivables.
- Aucun contenu ne clignote plus de 3 fois par seconde.
- Chaque page a un titre <title> unique et descriptif.
- Les liens ont des intitulés explicites hors contexte ("Lire l'article" plutôt que "Cliquez ici").
- Plusieurs mécanismes de navigation sont disponibles (menu, plan du site, recherche).
- Les cibles d'action (boutons, liens tactiles) mesurent au minimum 24×24 px.
Compréhensible (Understandable)
Le contenu et le fonctionnement de l'interface doivent être compréhensibles.
- La langue principale de la page est déclarée via <html lang="fr"> (ou "en", etc.).
- Les passages dans une autre langue sont marqués avec l'attribut lang.
- La navigation reste cohérente d'une page à l'autre (ordre, emplacement, libellés).
- Les composants identiques (boutons, icônes) ont un comportement identique.
- Chaque champ de formulaire a une étiquette <label> explicitement liée.
- Les erreurs de saisie sont identifiées et décrites en texte (pas seulement en couleur).
- Des suggestions de correction sont fournies lorsque c'est possible.
- Les actions irréversibles (paiement, suppression) peuvent être confirmées, annulées ou vérifiées.
- Aucune modification de contexte ne survient lors du focus ou de la saisie sans avertissement.
- Les instructions sont claires et n'utilisent pas uniquement des indices sensoriels (forme, position).
Robuste (Robust)
Le contenu doit être compatible avec les technologies d'assistance actuelles et futures.
- Le code HTML est valide : balises fermées, attributs uniques, imbrication correcte.
- Chaque composant interactif expose un nom, un rôle et une valeur accessibles.
- Les rôles ARIA sont utilisés uniquement quand HTML natif est insuffisant.
- Les messages d'état (succès, erreur, chargement) sont annoncés via aria-live ou role="status".
- Les composants personnalisés (modales, menus, onglets) respectent les motifs ARIA officiels.
- Les iframes et frames ont un attribut title décrivant leur contenu.
- Aucun élément ne supprime l'outline focus par défaut sans remplacement visible.
- Les tests avec lecteurs d'écran (NVDA, VoiceOver) ont été réalisés sur les parcours clés.
Automatiser cette checklist
Cocher 40 cases à la main sur chaque page prend des heures. Scrutia vérifie automatiquement tous les critères techniques en 5 minutes et vous remet un rapport complet avec le code de correction.
Ressources liées :
Questions fréquentes
Cette checklist couvre-t-elle tout le RGAA ?
Non — c'est une checklist pratique de pré-audit couvrant les critères les plus fréquemment cités. Le RGAA officiel compte 106 critères et chacun a plusieurs tests associés. Utilisez cette checklist pour détecter 80% des problèmes réels avant de commander un audit formel.
Cette checklist remplace-t-elle un audit d'accessibilité ?
Non. L'auto-évaluation est un excellent point de départ mais ne remplace pas un audit expert ou automatisé. Plusieurs critères (charge cognitive, qualité des alt, comportement avec technologies d'assistance) nécessitent un jugement humain. Utilisez la checklist pour préparer, puis validez avec Scrutia ou un audit manuel RGAA.
Puis-je utiliser cette checklist pour la conformité ADA aux États-Unis ?
Oui. Les tribunaux et accords américains utilisent WCAG 2.1 AA comme standard technique de facto pour la conformité ADA Title III. Cette checklist couvre la majorité des points cités dans les mises en demeure ADA, même si la conformité juridique dépend des faits propres à chaque site.
Par où commencer si j'ai peu de temps ?
Commencez par la section Perceptible : alternatives textuelles manquantes, contrastes et libellés de formulaires sont les trois violations les plus citées, à la fois en contentieux ADA et en signalements RGAA/EAA. Puis attaquez l'accessibilité clavier (Utilisable) et enfin la sémantique HTML/ARIA (Robuste).