Les 106 critères du RGAA 4.1.2
Référence complète des 106 critères d'accessibilité du RGAA, organisés par thématique. Pour chaque critère : définition, test et outil de vérification.
Thématique 1.Images(9 critères)
Couvre toutes les images du contenu : informatives, décoratives, complexes, texte et zones cliquables. Chaque image porteuse d'information doit avoir une alternative textuelle pertinente, et chaque image décorative doit être ignorée par les technologies d'assistance.
1.1Chaque image porteuse d'information a-t-elle une alternative textuelle ?
Toute image qui transmet une information doit avoir un attribut alt décrivant cette information. Un lecteur d'écran restitue ce texte à la place de l'image.
1.2Chaque image de décoration est-elle correctement ignorée par les technologies d'assistance ?
Les images purement esthétiques (séparateurs, motifs de fond) doivent avoir alt="" et éventuellement role="presentation" pour ne pas encombrer la restitution vocale.
1.3Pour chaque image porteuse d'information ayant une alternative textuelle, cette alternative est-elle pertinente ?
L'alternative doit décrire la fonction ou l'information véhiculée par l'image, pas son apparence physique. « Graphique des ventes T3 2026 : +15 % » est pertinent, « image.png » ne l'est pas.
1.6Chaque image porteuse d'information a-t-elle, si nécessaire, une description détaillée ?
Les images complexes (infographies, graphiques, schémas) nécessitent une description détaillée en complément de l'attribut alt, via aria-describedby ou un lien adjacent vers la description.
1.8Chaque image texte porteuse d'information, en l'absence d'un mécanisme de remplacement, doit-elle être remplacée par du texte stylé ?
Le texte intégré dans une image ne peut pas être agrandi, copié ou adapté par les technologies d'assistance. Il doit être remplacé par du vrai texte HTML mis en forme avec CSS.
Thématique 2.Cadres(2 critères)
Les cadres (iframes) intégrés dans la page doivent être identifiés et décrits pour que les technologies d'assistance puissent les annoncer à l'utilisateur.
2.1Chaque cadre a-t-il un titre de cadre ?
Chaque iframe doit avoir un attribut title décrivant son contenu. Exemple : title="Carte Google Maps de notre agence à Paris".
2.2Pour chaque cadre ayant un titre de cadre, ce titre de cadre est-il pertinent ?
Le titre doit décrire le contenu de l'iframe de manière concise et informative, pas simplement « iframe » ou « cadre ».
Thématique 3.Couleurs(3 critères)
Vérifie que l'information n'est pas transmise uniquement par la couleur et que les ratios de contraste texte/fond sont suffisants pour garantir la lisibilité.
3.1Dans chaque page web, l'information ne doit-elle pas être donnée uniquement par la couleur ?
Un champ en erreur ne doit pas être signalé uniquement par une bordure rouge : un message textuel, une icône ou un changement de forme doit accompagner l'indication de couleur.
3.2Dans chaque page web, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé ?
Ratio minimum de 4.5:1 pour le texte standard et 3:1 pour le texte agrandi (24px ou 18.5px en gras). Vérifié automatiquement par les outils d'audit.
3.3Dans chaque page web, les couleurs utilisées dans les composants d'interface ou les éléments graphiques porteurs d'informations sont-elles suffisamment contrastées ?
Les éléments d'interface (bordures de champs, icônes, indicateurs de focus) doivent avoir un ratio de contraste d'au moins 3:1 avec leur environnement.
Thématique 4.Multimédia(13 critères)
La thématique la plus fournie du RGAA couvre les contenus audio, vidéo et les médias temporels. Elle exige des sous-titres, des transcriptions textuelles et une audiodescription quand nécessaire.
4.1Chaque média temporel pré-enregistré a-t-il, si nécessaire, une transcription textuelle ou une audiodescription ?
Les vidéos et contenus audio doivent être accompagnés d'une transcription textuelle complète ou d'une audiodescription pour les personnes sourdes ou malvoyantes.
4.3Chaque média temporel synchronisé pré-enregistré a-t-il des sous-titres synchronisés ?
Les sous-titres doivent être synchronisés avec le contenu parlé, complets et fidèles. Les sous-titres automatiques seuls ne sont pas conformes sans vérification humaine.
4.7Chaque média temporel pré-enregistré a-t-il, si nécessaire, une audiodescription synchronisée ?
Quand des informations visuelles essentielles (texte à l'écran, actions sans dialogue) ne sont pas transmises par la bande son, une audiodescription doit les décrire.
4.11La consultation de chaque média temporel est-elle contrôlable par le clavier et tout dispositif de pointage ?
Les contrôles du lecteur (lecture, pause, volume, sous-titres) doivent être utilisables au clavier. Les lecteurs natifs HTML5 sont conformes ; les lecteurs custom doivent être vérifiés.
4.13Chaque média temporel et non temporel est-il compatible avec les technologies d'assistance ?
Les contrôles doivent être correctement labellisés et annoncés par les lecteurs d'écran (bouton lecture, curseur de volume, etc.).
Thématique 5.Tableaux(8 critères)
Les tableaux de données doivent être correctement structurés avec des en-têtes de colonnes et de lignes balisés, pour que les technologies d'assistance puissent restituer les relations entre les cellules.
5.1Chaque tableau de données complexe a-t-il un résumé ?
Un tableau complexe (en-têtes fusionnés, relations non linéaires) doit avoir un résumé décrivant sa structure et sa finalité.
5.4Chaque tableau de données a-t-il un titre ?
L'élément caption décrit le contenu du tableau. Exemple : <caption>Comparatif des tarifs d'audit accessibilité 2026</caption>.
5.6Pour chaque tableau de données, chaque en-tête de colonnes et chaque en-tête de lignes sont-ils correctement déclarés ?
Les cellules d'en-tête doivent utiliser th avec scope="col" ou scope="row" au lieu de td. C'est indispensable pour que le lecteur d'écran annonce l'en-tête avant chaque cellule de données.
5.7Pour chaque tableau de données, la technique appropriée permettant d'associer chaque cellule avec ses en-têtes est-elle utilisée ?
Dans les tableaux complexes, les attributs headers et id permettent d'associer explicitement chaque cellule de données à ses en-têtes de colonne et de ligne.
Thématique 6.Liens(2 critères)
Malgré seulement 2 critères, cette thématique est cruciale : les liens sont l'élément de navigation fondamental du web. Chaque lien doit être explicite et son nom accessible pertinent.
6.1Chaque lien est-il explicite ?
L'intitulé d'un lien doit permettre de comprendre sa destination sans contexte visuel. « Cliquez ici » ou « En savoir plus » sont non conformes. « Découvrir nos tarifs d'audit » est conforme.
6.2Dans chaque page web, chaque lien, à l'exception des ancres, a-t-il un intitulé ?
Un lien ne doit jamais être vide. Les liens-images doivent avoir un texte alternatif sur l'image. Les liens-icônes doivent avoir un aria-label.
Thématique 7.Scripts(5 critères)
Les scripts JavaScript doivent être accessibles : les composants interactifs créés en JS doivent être utilisables au clavier, compatibles avec les technologies d'assistance et préserver les messages de statut.
7.1Chaque script est-il, si nécessaire, compatible avec les technologies d'assistance ?
Les composants custom (onglets, modales, menus déroulants) doivent exposer les bons rôles ARIA, noms et états aux technologies d'assistance. Suivre les patterns WAI-ARIA du W3C.
7.3Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage ?
Tout ce qui est cliquable à la souris doit être atteignable avec Tab et activable avec Entrée ou Espace. Les div onclick sans tabindex ni gestion clavier sont non conformes.
7.4Pour chaque script qui initie un changement de contexte, l'utilisateur est-il averti ou en a-t-il le contrôle ?
Un changement de page, l'ouverture d'une fenêtre ou la modification d'un formulaire ne doivent pas survenir sans que l'utilisateur l'ait déclenché ou en ait été informé au préalable.
7.5Dans chaque page web, les messages de statut sont-ils correctement restitués par les technologies d'assistance ?
Les notifications, messages de succès ou d'erreur affichés dynamiquement doivent utiliser aria-live ou role="alert" pour être annoncés automatiquement par les lecteurs d'écran.
Thématique 8.Éléments obligatoires(10 critères)
Chaque page web doit posséder des éléments HTML fondamentaux : doctype, langue, titre, validité du code source. Ces éléments sont le socle technique de l'accessibilité.
8.1Chaque page web est-elle définie par un type de document ?
La déclaration <!DOCTYPE html> doit être présente en première ligne du document. Elle garantit un rendu cohérent et une interprétation correcte du HTML par les technologies d'assistance.
8.3Dans chaque page web, la langue par défaut est-elle présente ?
L'attribut lang sur la balise html (ex : lang="fr") permet aux lecteurs d'écran de choisir la bonne synthèse vocale. Son absence rend la lecture vocale incompréhensible.
8.5Chaque page web a-t-elle un titre de page ?
La balise title est la première information lue par les lecteurs d'écran lors du chargement d'une page. Elle doit être présente et non vide.
8.6Pour chaque page web ayant un titre de page, ce titre est-il pertinent ?
Le titre doit être unique, descriptif et commencer par l'information spécifique à la page. « Tarifs - WebConforme » est pertinent, « Page 1 » ne l'est pas.
8.9Dans chaque page web, les balises ne doivent pas être utilisées uniquement à des fins de présentation. Cette règle est-elle respectée ?
Les balises sémantiques (h1-h6, p, blockquote, ul, ol) doivent être utilisées pour leur sens, pas pour obtenir un effet visuel. Utiliser CSS pour la présentation.
Thématique 9.Structuration de l'information(4 critères)
La structure sémantique du document (titres, listes, landmarks ARIA) est essentielle pour la navigation par les technologies d'assistance. Elle permet aux utilisateurs de se repérer et de naviguer efficacement.
9.1Dans chaque page web, l'information est-elle structurée par l'utilisation appropriée de titres ?
La hiérarchie des titres (h1, h2, h3...) doit être logique et sans saut de niveau. Les lecteurs d'écran permettent de naviguer directement d'un titre à l'autre.
9.2Dans chaque page web, la structure du document est-elle cohérente ?
Les landmarks (header, nav, main, footer, aside) doivent structurer les zones principales. S'il y a plusieurs nav, chacun doit avoir un aria-label distinctif.
9.3Dans chaque page web, chaque liste est-elle correctement structurée ?
Les listes d'éléments doivent utiliser ul/li ou ol/li, pas des paragraphes ou des div avec des tirets. Les listes de définitions utilisent dl/dt/dd.
Thématique 10.Présentation de l'information(14 critères)
Deuxième thématique en nombre de critères, elle traite de l'adaptabilité visuelle du contenu : zoom, focus visible, espacement, orientation, contenus visibles au survol ou au focus.
10.1Dans chaque page web, les feuilles de styles sont-elles utilisées pour contrôler la présentation de l'information ?
La présentation visuelle (couleurs, tailles, marges) doit être gérée par CSS, pas par des attributs HTML de présentation ou des tableaux de mise en page.
10.4Dans chaque page web, le texte reste-t-il lisible lorsque la taille des caractères est augmentée jusqu'à 200 % ?
En zoomant le texte à 200 % dans le navigateur, aucun contenu ne doit déborder, se chevaucher ou devenir illisible. Utiliser des unités relatives (rem, em, %) plutôt que des pixels fixes.
10.7Dans chaque page web, pour chaque élément recevant le focus, la prise de focus est-elle visible ?
Supprimer outline: none sans alternative est une violation majeure. L'indicateur de focus (outline, border, shadow) doit être clairement visible pour les utilisateurs naviguant au clavier.
10.11Pour chaque page web, les contenus peuvent-ils être présentés sans recourir à un défilement horizontal pour une fenêtre ayant une largeur de 320 px ?
Le contenu doit être responsive et s'adapter à une largeur de 320 pixels CSS (équivalent d'un zoom 400 % sur une fenêtre de 1280 px) sans défilement horizontal.
10.14Dans chaque page web, les contenus additionnels apparaissant au survol ou à la prise de focus sont-ils contrôlables par l'utilisateur ?
Les tooltips et popups doivent pouvoir être fermés avec Échap, rester visibles tant que le curseur les survole, et ne pas disparaître intempestivement.
Thématique 11.Formulaires(13 critères)
Les formulaires sont un point de friction majeur en accessibilité. Chaque champ doit être identifié par une étiquette, les erreurs signalées de manière accessible, et les aides à la saisie fournies.
11.1Chaque champ de formulaire a-t-il une étiquette ?
Chaque input, select et textarea doit avoir un label associé via l'attribut for/id. Le placeholder seul ne constitue pas une étiquette : il disparaît à la saisie.
11.2Chaque étiquette associée à un champ de formulaire est-elle pertinente ?
L'étiquette doit décrire clairement le champ. « Champ 1 » ou « Saisie » ne sont pas pertinents. « Adresse email professionnelle » l'est.
11.10Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente ?
Les erreurs de saisie doivent être signalées par un message textuel associé au champ (aria-describedby), pas uniquement par un changement de couleur. L'attribut aria-invalid doit indiquer les champs en erreur.
11.13La finalité de chaque champ de saisie peut-elle être déduite pour faciliter le remplissage automatique ?
Les champs qui collectent des données personnelles doivent avoir l'attribut autocomplete avec la bonne valeur (email, tel, given-name, family-name, postal-code, etc.).
Thématique 12.Navigation(11 critères)
Vérifie que l'utilisateur peut naviguer efficacement dans le site, quels que soient ses moyens d'interaction. Couvre les systèmes de navigation, les liens d'évitement et la cohérence entre les pages.
12.1Chaque ensemble de pages dispose-t-il de deux systèmes de navigation différents au moins ?
Un site doit proposer au minimum deux moyens de navigation : menu principal + moteur de recherche, ou menu + plan du site. Un seul système de navigation est insuffisant.
12.6Les zones de regroupement de contenus présentes dans plusieurs pages web sont-elles utilisables de manière cohérente ?
Le menu, le header, le footer doivent être présentés de manière cohérente (même ordre, même structure) sur l'ensemble des pages du site.
12.7Dans chaque page web, un lien d'évitement ou d'accès rapide à la zone de contenu principal est-il présent ?
Un skip-link (« Aller au contenu principal ») en début de page, visible au focus, permet de passer la navigation pour accéder directement au contenu. C'est souvent le premier critère testé lors d'un audit.
12.8Dans chaque page web, l'ordre de tabulation est-il cohérent ?
L'ordre de parcours au clavier (Tab) doit suivre l'ordre logique du contenu. Éviter les tabindex positifs (tabindex="1", tabindex="2") qui perturbent l'ordre naturel.
Thématique 13.Consultation(12 critères)
Couvre les aspects liés à la consultation du contenu : documents téléchargeables, limites de temps, contenus en mouvement, changements brusques et contenus clignotants.
13.1Pour chaque page web, l'utilisateur a-t-il le contrôle de chaque limite de temps modifiant le contenu ?
Si un contenu est limité dans le temps (session, actualisation automatique), l'utilisateur doit pouvoir étendre la durée, être averti avant expiration ou désactiver la limite.
13.7Dans chaque page web, chaque document bureautique en téléchargement possède-t-il, si nécessaire, une version accessible ?
Les PDF, DOCX et XLSX proposés en téléchargement doivent être accessibles (titres balisés, images avec alt, ordre de lecture). Sinon, une version HTML alternative doit être fournie.
13.8Dans chaque page web, chaque contenu proposé en téléchargement est-il accessible ?
Le téléchargement lui-même doit être accessible : le lien doit indiquer le format et le poids du fichier (ex : « Rapport annuel 2026 (PDF, 2.4 Mo) »).
13.9Dans chaque page web, le contenu proposé est-il consultable quelle que soit l'orientation de l'écran ?
Le contenu ne doit pas être bloqué en orientation portrait ou paysage, sauf si l'orientation est essentielle au fonctionnement (jeu, application de dessin).
Vérifiez la conformité RGAA de votre site
WebConforme teste automatiquement les critères RGAA détectables par machine en 30 secondes. Rapport priorisé avec corrections code avant/après.
Scanner mon site gratuitement