Checklist RGAA : les 106 critères expliqués simplement

Disposer d'une checklist structurée est indispensable pour aborder la mise en conformité RGAA de manière méthodique. Sans une vue d'ensemble claire des 106 critères, le risque est d'avancer en aveugle, de corriger des problèmes secondaires tout en passant à côté de non-conformités critiques. Ce guide parcourt les 13 thématiques du RGAA 4.1.2, explique les critères les plus importants de chacune en langage clair et vous oriente vers les outils adaptés pour les tester.

Pour une présentation générale du référentiel, consultez notre guide complet sur le RGAA. Pour comprendre ce que couvre notre outil d'analyse, rendez-vous sur la page couverture RGAA.

Le RGAA 4.1.2 en bref : structure et logique

Le RGAA 4.1.2, version en vigueur (publiée en 2021, mise à jour en avril 2023), est le référentiel officiel français d'accessibilité numérique. Il traduit les WCAG 2.1 niveau AA en critères de test concrets et opérationnels. Sa structure repose sur 13 thématiques regroupant un total de 106 critères. Chaque critère est accompagné de tests unitaires détaillés qui indiquent précisément ce qu'il faut vérifier.

Pour chaque critère audité, le résultat est l'un des trois suivants :

• Conforme (C) : tous les tests du critère sont satisfaits.
• Non conforme (NC) : au moins un test échoue.
• Non applicable (NA) : le critère ne concerne pas la page testée.

Le taux de conformité se calcule en divisant les critères conformes par la somme des critères conformes et non conformes, les critères non applicables étant exclus du calcul.

Passons maintenant en revue chaque thématique, avec les critères clés à retenir.

Thématique 1 : Images (9 critères)

Les critères relatifs aux images garantissent que toute information véhiculée par une image est accessible aux personnes qui ne peuvent pas la voir.

Critères clés :

• Critère 1.1 : chaque image porteuse d'information possède-t-elle une alternative textuelle ? En pratique, cela signifie que toute image (<img>, <svg>, <canvas>) qui transmet une information doit disposer d'un attribut alt ou d'un mécanisme ARIA décrivant son contenu. Une photo de produit dans un catalogue doit par exemple décrire le produit, pas simplement afficher "image1.jpg".

• Critère 1.2 : chaque image de décoration est-elle correctement ignorée par les technologies d'assistance ? Une image purement décorative doit avoir un attribut alt vide (alt="") pour que les lecteurs d'écran la passent sous silence. Un filet graphique séparant deux sections ne doit pas être vocalisé.

• Critère 1.6 : chaque image porteuse d'information possède-t-elle, si nécessaire, une description détaillée ? Les graphiques complexes, infographies et schémas nécessitent une description longue accessible, par exemple via un attribut longdesc ou un lien vers une page de description.

Outils de test : notre scanner RGAA détecte automatiquement les images sans attribut alt. La vérification de la pertinence du texte alternatif reste un travail manuel.

Thématique 2 : Cadres (2 critères)

Les cadres (<iframe>) intégrés dans une page doivent être identifiables et compréhensibles pour les utilisateurs de technologies d'assistance.

Critères clés :

• Critère 2.1 : chaque cadre possède-t-il un titre de cadre ? Tout élément <iframe> doit posséder un attribut title décrivant son contenu. Par exemple, un iframe intégrant une carte Google Maps devrait avoir title="Carte de localisation de nos bureaux".

• Critère 2.2 : pour chaque cadre ayant un titre, ce titre est-il pertinent ? Un titre comme "iframe1" ou "cadre" est insuffisant. Le titre doit permettre à l'utilisateur de comprendre ce que contient le cadre avant d'y entrer.

Outils de test : un scan automatisé identifie les iframes sans attribut title. La pertinence du titre nécessite une évaluation humaine.

Thématique 3 : Couleurs (3 critères)

Les critères liés aux couleurs garantissent que l'information ne repose pas uniquement sur la couleur et que les textes sont suffisamment contrastés.

Critères clés :

• Critère 3.1 : dans chaque page, l'information n'est-elle pas donnée uniquement par la couleur ? Par exemple, un formulaire qui signale les champs obligatoires uniquement par un libellé rouge (sans astérisque ni mention textuelle) exclut les personnes ne percevant pas les couleurs.

• Critère 3.2 : dans chaque page, le contraste entre la couleur du texte et son arrière-plan est-il suffisamment élevé ? Le RGAA exige un ratio de contraste minimum de 4.5:1 pour le texte de taille normale et de 3:1 pour le texte de grande taille (au moins 24 px ou 18.5 px en gras). Utilisez notre calculateur de contraste pour vérifier vos combinaisons de couleurs.

• Critère 3.3 : dans chaque page, les couleurs utilisées dans les composants d'interface et les éléments graphiques porteurs d'information sont-elles suffisamment contrastées ? Ce critère étend l'exigence de contraste au-delà du texte, aux bordures de champs de formulaire, aux icônes porteuses d'information et aux graphiques.

Outils de test : le calculateur de contraste permet de tester manuellement chaque combinaison. Notre scanner détecte automatiquement les contrastes insuffisants entre le texte et son arrière-plan.

Thématique 4 : Multimédia (13 critères)

Avec 13 critères, le multimédia constitue l'une des thématiques les plus fournies du RGAA. Elle couvre les vidéos, les contenus audio et les médias temporels.

Critères clés :

• Critère 4.1 : chaque média temporel pré-enregistré a-t-il, si nécessaire, une transcription textuelle ou une audiodescription ? Une vidéo présentant une démonstration de produit doit proposer au minimum une transcription textuelle complète permettant d'accéder au contenu sans le son ni l'image.

• Critère 4.3 : chaque média temporel synchronisé pré-enregistré a-t-il, si nécessaire, des sous-titres synchronisés ? Les sous-titres doivent être synchronisés avec la piste audio et décrire non seulement les dialogues mais aussi les sons significatifs (musique, bruits d'ambiance pertinents).

• Critère 4.13 : chaque média temporel et non temporel est-il compatible avec les technologies d'assistance ? Les lecteurs vidéo personnalisés doivent être utilisables au clavier et compatibles avec les lecteurs d'écran. Les contrôles (lecture, pause, volume) doivent être accessibles.

Outils de test : la vérification du multimédia est essentiellement manuelle. Il faut tester la présence des transcriptions, la synchronisation des sous-titres et l'accessibilité des contrôles du lecteur.

Thématique 5 : Tableaux (8 critères)

Les tableaux de données doivent être correctement balisés pour que les technologies d'assistance puissent restituer les relations entre les cellules et leurs en-têtes.

Critères clés :

• Critère 5.1 : chaque tableau de données complexe a-t-il un résumé ? Un tableau comportant plusieurs niveaux d'en-têtes ou une structure inhabituelle doit proposer un résumé décrivant son organisation. Ce résumé aide les utilisateurs de lecteurs d'écran à comprendre la structure du tableau avant de le parcourir. Note : l'attribut summary est obsolète en HTML5. Privilégiez <caption> pour le titre du tableau et aria-describedby pour une description détaillée.

• Critère 5.3 : pour chaque tableau de mise en forme, le contenu linéarisé reste-t-il compréhensible ? Les tableaux utilisés uniquement pour la mise en page (pratique déconseillée mais encore présente sur certains sites) ne doivent pas utiliser de balises <th>, <caption> ou d'attributs summary. Leur contenu doit rester logique lorsqu'il est lu séquentiellement.

Outils de test : un scan automatisé peut détecter les tableaux sans en-têtes (<th>) ou sans attribut scope. L'évaluation de la pertinence du balisage nécessite un examen humain.

Thématique 6 : Liens (2 critères)

Les liens doivent être explicites et compréhensibles, même hors de leur contexte visuel.

Critères clés :

• Critère 6.1 : chaque lien est-il explicite ? L'intitulé du lien (texte visible, attribut title, attribut aria-label ou contexte du lien) doit permettre de comprendre sa destination ou sa fonction. Un lien "Cliquez ici" ou "En savoir plus" sans aucun contexte est non conforme. Préférez "Consulter le rapport annuel 2025 (PDF, 2 Mo)".

• Critère 6.2 : dans chaque page, chaque lien, à l'exception des ancres, a-t-il un intitulé ? Tout élément <a> avec un attribut href doit posséder un contenu textuel accessible (texte visible, aria-label, image avec alt à l'intérieur du lien). Un lien ne contenant qu'une icône sans texte alternatif est inaccessible.

Pour comprendre quand utiliser un lien plutôt qu'un bouton, consultez notre outil bouton vs lien.

Outils de test : notre scanner détecte les liens sans intitulé. La vérification de la pertinence des intitulés de liens reste manuelle.

Thématique 7 : Scripts (5 critères)

Les composants interactifs pilotés par JavaScript doivent être accessibles aux technologies d'assistance et utilisables au clavier.

Critères clés :

• Critère 7.1 : chaque script est-il, si nécessaire, compatible avec les technologies d'assistance ? Les composants JavaScript personnalisés (menus déroulants, onglets, modales, carrousels) doivent utiliser les attributs ARIA appropriés pour communiquer leur rôle, leur état et leurs propriétés aux lecteurs d'écran. Notre générateur ARIA vous aide à implémenter correctement ces attributs.

• Critère 7.3 : chaque script est-il contrôlable par le clavier et par tout dispositif de pointage ? Tout composant accessible à la souris doit l'être également au clavier. Un menu qui s'ouvre uniquement au survol (hover) sans équivalent clavier (focus) est non conforme.

• Critère 7.5 : dans chaque page, les messages de statut sont-ils correctement restitués par les technologies d'assistance ? Les messages dynamiques (notifications, alertes, mises à jour de panier) doivent utiliser les attributs role="alert", role="status" ou aria-live pour être annoncés automatiquement par les lecteurs d'écran.

Outils de test : le générateur ARIA produit le code nécessaire. La vérification de l'accessibilité des scripts nécessite des tests manuels au clavier et avec un lecteur d'écran.

Thématique 8 : Elements obligatoires (10 critères)

Cette thématique couvre les fondamentaux techniques de toute page web accessible : validité du code, langue, titre de page.

Critères clés :

• Critère 8.1 : chaque page web est-elle définie par un type de document ? La page doit commencer par une déclaration <!DOCTYPE html> valide. Son absence peut provoquer un rendu incohérent selon les navigateurs et les technologies d'assistance.

• Critère 8.2 : pour chaque page web, le code source généré est-il valide selon le type de document spécifié ? Le code HTML doit respecter les spécifications du W3C. Les erreurs de balisage (balises non fermées, attributs dupliqués, identifiants non uniques) peuvent perturber les technologies d'assistance. Utilisez notre validateur de titres pour vérifier au minimum la structure de vos en-têtes.

• Critère 8.6 : pour chaque page web ayant un titre de page, ce titre est-il pertinent ? Le contenu de la balise <title> doit décrire de manière concise et unique le contenu ou la fonction de la page. Un titre comme "Accueil" est insuffisant ; préférez "Accueil - Nom du site".

Outils de test : notre scanner vérifie automatiquement la présence du doctype, de l'attribut lang, du titre de page et de leur pertinence de base. Le validateur de titres analyse la structure complète de la hiérarchie.

Thématique 9 : Structuration de l'information (4 critères)

Une structuration correcte de l'information permet aux utilisateurs de technologies d'assistance de naviguer efficacement dans le contenu.

Critères clés :

• Critère 9.1 : dans chaque page, l'information est-elle structurée par l'utilisation appropriée de titres ? La hiérarchie des titres (h1 à h6) doit être logique et continue, sans saut de niveau. Un h1 suivi d'un h3 (sans h2 intermédiaire) crée une confusion pour les utilisateurs qui naviguent de titre en titre. Testez votre hiérarchie avec notre validateur de titres.

• Critère 9.2 : dans chaque page, la structure du document est-elle cohérente ? Les zones principales de la page (en-tête, navigation, contenu principal, pied de page) doivent être identifiées par les balises sémantiques HTML5 (<header>, <nav>, <main>, <footer>) ou les rôles ARIA correspondants.

• Critère 9.3 : dans chaque page, chaque liste est-elle correctement structurée ? Les énumérations doivent utiliser les balises <ul>, <ol> ou <dl> appropriées. Un menu de navigation structuré avec des <div> au lieu de <ul><li> prive les lecteurs d'écran de l'information sur le nombre d'éléments et la position courante.

Outils de test : le validateur de titres analyse la hiérarchie des titres. Notre scanner vérifie la présence des landmarks HTML5.

Thématique 10 : Présentation de l'information (14 critères)

Avec 14 critères, cette thématique couvre l'adaptabilité de la mise en page, la lisibilité du contenu et la visibilité du focus.

Critères clés :

• Critère 10.1 : dans chaque page, les feuilles de styles sont-elles utilisées pour contrôler la présentation de l'information ? La mise en forme doit reposer sur CSS et non sur des éléments ou attributs HTML de présentation (<font>, <center>, bgcolor). La séparation du contenu et de la présentation est un fondement de l'accessibilité.

• Critère 10.7 : dans chaque page, pour chaque élément recevant le focus, la prise de focus est-elle visible ? Lorsqu'un utilisateur navigue au clavier, l'élément actuellement sélectionné doit être clairement identifiable visuellement (outline, changement de couleur, bordure). Supprimer le focus visible via outline: none sans alternative est une erreur fréquente et grave.

• Critère 10.11 : pour chaque page, les contenus peuvent-ils être présentés sans perte d'information ou de fonctionnalité avec une largeur de fenêtre réduite à 320 pixels CSS ? Ce critère garantit que le site est utilisable par les personnes qui agrandissent fortement le texte ou utilisent un écran de petite taille. Aucun défilement horizontal ne doit être nécessaire.

Outils de test : le test de la visibilité du focus et du reflow à 320 px est essentiellement manuel. Le scanner détecte certaines propriétés CSS problématiques comme la suppression globale de l'outline.

Thématique 11 : Formulaires (13 critères)

Les formulaires sont des points d'interaction critiques. Leurs 13 critères garantissent que chaque utilisateur peut saisir et soumettre des informations.

Critères clés :

• Critère 11.1 : chaque champ de formulaire a-t-il une étiquette ? Chaque <input>, <textarea> et <select> doit être associé à un <label> via l'attribut for, ou posséder un attribut aria-label ou aria-labelledby. Un champ sans étiquette est inutilisable pour les personnes qui ne voient pas le placeholder ou le texte adjacent.

• Critère 11.10 : dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente ? Les messages d'erreur doivent indiquer clairement quel champ est concerné et quelle correction est attendue. Un message générique "Erreur dans le formulaire" est insuffisant. L'erreur doit être liée au champ fautif via aria-describedby ou aria-errormessage.

• Critère 11.13 : la finalité d'un champ de saisie peut-elle être déduite pour faciliter le remplissage automatique par l'utilisateur ? Les champs courants (nom, email, adresse, téléphone) doivent utiliser l'attribut autocomplete avec les valeurs appropriées (name, email, street-address, tel). Cela aide les personnes ayant des difficultés motrices ou cognitives.

Outils de test : notre scanner détecte les champs sans étiquette et les attributs autocomplete manquants. La pertinence des messages d'erreur et le parcours de soumission nécessitent des tests manuels.

Thématique 12 : Navigation (11 critères)

La navigation regroupe 11 critères garantissant que chaque utilisateur peut se déplacer efficacement dans le site et accéder au contenu souhaité.

Critères clés :

• Critère 12.1 : chaque ensemble de pages dispose-t-il de deux systèmes de navigation différents, au moins ? Le site doit proposer au moins deux moyens de navigation parmi : menu de navigation, plan du site, moteur de recherche. Cela garantit que chaque utilisateur trouve un moyen adapté à ses capacités.

• Critère 12.7 : dans chaque ensemble de pages, un lien d'évitement ou d'accès rapide à la zone de contenu principal est-il présent ? Le lien d'évitement (souvent "Aller au contenu principal") permet aux utilisateurs de clavier et de lecteurs d'écran de passer directement au contenu sans traverser l'en-tête et le menu à chaque page. Utilisez notre générateur de liens d'évitement pour implémenter cette fonctionnalité correctement.

• Critère 12.8 : dans chaque page, l'ordre de tabulation est-il cohérent ? L'ordre dans lequel le focus se déplace d'un élément interactif à l'autre doit suivre une logique visuelle et fonctionnelle. Un formulaire dont le focus saute du premier champ au bouton de soumission avant de revenir au deuxième champ est non conforme.

Outils de test : le générateur de liens d'évitement produit le code HTML nécessaire. La vérification de l'ordre de tabulation et de la présence de plusieurs systèmes de navigation nécessite un test manuel.

Thématique 13 : Consultation (12 critères)

La dernière thématique couvre le contrôle des contenus en mouvement, les limites de temps et l'accessibilité des documents téléchargeables.

Critères clés :

• Critère 13.1 : pour chaque page, l'utilisateur a-t-il le contrôle de chaque limite de temps modifiant le contenu ? Si une session expire après un délai, l'utilisateur doit pouvoir prolonger ce délai ou être averti avant expiration. Un panier d'achat qui se vide sans prévenir après 10 minutes d'inactivité est non conforme.

• Critère 13.7 : dans chaque page, les changements brusques de luminosité ou les effets de flash sont-ils correctement gérés ? Les contenus qui clignotent plus de trois fois par seconde peuvent provoquer des crises d'épilepsie. Ces contenus doivent soit être supprimés, soit être précédés d'un avertissement avec possibilité de les désactiver.

• Critère 13.8 : dans chaque page, chaque contenu en mouvement ou clignotant est-il contrôlable par l'utilisateur ? Les carrousels, animations et contenus défilants automatiquement doivent proposer des contrôles de pause, d'arrêt ou de masquage. Un bandeau publicitaire animé sans bouton de pause est non conforme.

Outils de test : la vérification des contenus en mouvement, des limites de temps et des documents téléchargeables est essentiellement manuelle.

Tests automatiques vs tests manuels

L'un des points essentiels à comprendre avec cette checklist est que tous les critères ne sont pas testables automatiquement. En pratique, la répartition est la suivante :

Critères testables automatiquement (environ 30-40 %) :

• Présence des attributs alt sur les images
• Ratios de contraste entre le texte et l'arrière-plan
• Présence des étiquettes de formulaires
• Validité du code HTML (balises, attributs)
• Présence du doctype, de l'attribut lang, du <title>
• Hiérarchie des titres (détection des sauts de niveaux)
• Iframes sans title
• Liens sans intitulé

Critères nécessitant un test manuel (environ 60-70 %) :

• Pertinence des alternatives textuelles
• Qualité des sous-titres et audiodescriptions
• Cohérence de la navigation au clavier
• Pertinence des messages d'erreur de formulaires
• Compréhensibilité du contenu linéarisé des tableaux
• Utilisabilité avec un lecteur d'écran
• Pertinence de l'ordre de tabulation
• Contrôle des contenus en mouvement et des limites de temps

Notre scanner RGAA couvre la partie automatisable et vous fournit un premier diagnostic en quelques secondes. Pour les critères manuels, un audit complet par un expert reste indispensable.

Prioriser les critères : par où commencer

Face à 106 critères, il est contre-productif de vouloir tout traiter en même temps. Voici une approche de priorisation en trois niveaux.

Niveau 1 : impact fort, correction facile

Ces critères affectent le plus grand nombre d'utilisateurs et sont souvent les plus simples à corriger :

• Images sans alternative (critère 1.1) : ajoutez un attribut alt pertinent à chaque image porteuse d'information.
• Contrastes insuffisants (critère 3.2) : ajustez les couleurs pour atteindre le ratio minimal de 4.5:1.
• Formulaires sans étiquettes (critère 11.1) : associez un <label> à chaque champ.
• Titre de page absent ou non pertinent (critère 8.6) : rédigez un <title> unique et descriptif pour chaque page.
• Langue de la page non spécifiée (critère 8.3) : ajoutez l'attribut lang="fr" à la balise <html>.

Niveau 2 : impact fort, correction modérée

• Structure des titres (critère 9.1) : réorganisez la hiérarchie h1-h6 pour qu'elle soit logique et continue.
• Liens d'évitement (critère 12.7) : implémentez un lien "Aller au contenu" en haut de chaque page.
• Focus visible (critère 10.7) : assurez-vous que chaque élément interactif a un indicateur de focus visible.
• Liens explicites (critère 6.1) : reformulez les "Cliquez ici" et "En savoir plus" en intitulés descriptifs.

Niveau 3 : critères spécialisés

• Multimédia (thématique 4) : sous-titrage, audiodescription, transcriptions.
• Tableaux complexes (thématique 5) : balisage avancé des en-têtes.
• Scripts interactifs (thématique 7) : attributs ARIA, compatibilité lecteurs d'écran.
• Contenus en mouvement (thématique 13) : contrôles de pause, limites de temps.

Cette approche progressive vous permet de maximiser l'impact de chaque correction. Pour une estimation du budget nécessaire, consultez notre article sur le coût et la méthode d'un audit RGAA.

Documenter votre conformité

Une fois votre travail de mise en conformité avancé, vous devrez publier une déclaration d'accessibilité. Ce document obligatoire indique votre taux de conformité, les non-conformités identifiées, les dérogations éventuelles et les moyens de contact pour signaler un problème. Consultez notre modèle de déclaration d'accessibilité pour rédiger la vôtre conformément aux exigences réglementaires.

Pour approfondir chaque concept mentionné dans cette checklist, le guide RGAA fournit des définitions détaillées et des exemples complémentaires.

Conclusion

Les 106 critères du RGAA 4.1.2 couvrent l'ensemble des aspects de l'accessibilité web, de la simple alternative textuelle sur une image à la gestion avancée des composants JavaScript interactifs. Cette checklist ne remplace pas un audit complet, mais elle vous fournit une vision structurée du référentiel et des repères concrets pour prioriser vos actions.

La première étape est toujours la même : mesurer l'existant. Lancez un scan gratuit de votre site pour identifier les non-conformités détectables automatiquement, corrigez les problèmes les plus impactants, puis progressez méthodiquement vers une conformité complète. Chaque critère corrigé améliore concrètement l'expérience de vos utilisateurs.