RGAA et WCAG 2.2 : checklist audit accessibilité — tutoriel 2026
Cet article fait partie du cluster « Accessibilité web et Green IT ». Pour la vue d’ensemble stratégique, lisez d’abord le pilier.
Introduction
Un développeur sénégalais finalise un portail de services administratifs pour la mairie de Thiès. Le site fonctionne parfaitement sur Chrome, s’affiche bien sur mobile — mais une fonctionnaire malvoyante ne parvient pas à naviguer dans le formulaire de demande d’extrait de naissance. Le lecteur d’écran annonce les champs dans le mauvais ordre, les boutons n’ont pas de libellé exploitable, et certains textes disparaissent dans le fond clair. Ce scénario n’est pas hypothétique : il illustre pourquoi l’accessibilité web est devenue un impératif technique, éthique et réglementaire.
Le RGAA 4.1.2 (Référentiel Général d’Amélioration de l’Accessibilité) est l’adaptation française des WCAG 2.1 (Web Content Accessibility Guidelines) du W3C, publiée par la DINUM. Il définit 106 critères répartis en 13 thématiques et s’applique obligatoirement aux organismes publics français depuis la loi du 11 février 2005 et son décret d’application de 2019. Les WCAG 2.2, publiées le 5 octobre 2023 en tant que W3C Recommendation, ajoutent 9 nouveaux critères de succès par rapport à la version 2.1 — notamment sur les cibles tactiles (2.5.8 : taille minimale 24×24 px), la navigation au focus visible (2.4.11, 2.4.12, 2.4.13), l’authentification accessible (3.3.7, 3.3.8) et les mouvements de glissement (2.5.7). Le RGAA 4.1.2 n’incorpore pas encore ces 9 critères, mais les bonnes pratiques 2026 consistent à les intégrer dès aujourd’hui dans tout audit sérieux.
Ce tutoriel vous guide pas à pas dans un audit d’accessibilité complet : vous sortirez avec une checklist opérationnelle, les outils gratuits à installer, et la compréhension suffisante pour corriger les défauts les plus courants sur votre propre site.
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants. Vous avez besoin d’un site web existant accessible publiquement — qu’il s’agisse d’un site WordPress, d’une application React, d’un portail Django ou d’un site statique. L’audit décrit ici couvre les vérifications manuelles et semi-automatiques : comptez environ 2 heures pour un site de 10 à 15 pages, et une demi-journée pour un site plus complexe avec des formulaires multiples et des contenus vidéo.
Côté outils, vous aurez besoin du navigateur Firefox ou Chrome en version récente, de l’extension axe DevTools (gratuite, disponible sur Firefox Add-ons et Chrome Web Store — éditeur Deque Systems), du lecteur d’écran NVDA pour Windows (gratuit, téléchargeable sur nvaccess.org), et du Colour Contrast Analyser de TPGi (gratuit, Windows et macOS). Aucune de ces ressources ne nécessite d’abonnement. Le niveau requis est intermédiaire : vous savez lire du HTML et utiliser les DevTools du navigateur.
Étape 1 — Comprendre les 4 principes POUR
Toute la structure de WCAG — et par extension du RGAA — repose sur quatre principes fondamentaux dont l’acronyme anglais POUR résume l’essentiel. Ces quatre principes ne sont pas de simples catégories administratives : ils représentent une vision cohérente de ce que signifie « accessible » pour un utilisateur confronté à un handicap visuel, moteur, cognitif ou auditif.
Le premier principe est Perceptible (Perceivable). Toute information et tout composant d’interface utilisateur doit être présentable aux utilisateurs de manière à ce qu’ils puissent le percevoir. Un utilisateur aveugle ne voit pas une image : si cette image véhicule de l’information, elle doit posséder un texte alternatif. Un utilisateur sourd ne peut pas entendre la bande sonore d’une vidéo : des sous-titres sont indispensables. Le principe de perceptibilité exige que vous ne vous reposiez jamais sur un seul canal sensoriel pour transmettre une information essentielle.
Le deuxième principe est Opérable (Operable). Les composants d’interface et la navigation doivent être utilisables. Un utilisateur qui ne peut pas manipuler une souris doit pouvoir naviguer entièrement au clavier. Un utilisateur avec des tremblements doit bénéficier d’un temps suffisant pour remplir un formulaire. Ce principe couvre aussi les crises épileptiques : tout contenu qui clignote plus de 3 fois par seconde constitue un danger médical documenté.
Le troisième principe est Compréhensible (Understandable). L’information et l’utilisation de l’interface doivent être compréhensibles. Cela implique une langue déclarée dans le code HTML (