RGAA et WCAG 2.2 : checklist audit accessibilité — tutoriel 2026

📍 Article principal de la série : Site web accessible RGAA et green IT 2026 : conformité Afrique de l’Ouest

Cet article fait partie de la série « Accessibilité web ». Pour la vue d’ensemble, commencez par le guide général.

Introduction

L’accessibilité numérique cesse d’être un sujet purement éthique ou théorique en 2026 : les obligations légales se multiplient et les sanctions deviennent réelles. En France, l’Arcom peut désormais infliger jusqu’à 50 000 euros d’amende par site non-conforme au RGAA, après mise en demeure. L’European Accessibility Act, applicable depuis juin 2025, étend les obligations à tous les sites e-commerce vendant aux consommateurs européens — ce qui concerne directement les PME ouest-africaines exportant vers le marché européen ou la diaspora. Au-delà des sanctions, l’accessibilité est aussi un puissant levier SEO : Google pénalise désormais activement les sites avec des erreurs d’accessibilité majeures dans Core Web Vitals.

Ce guide vous fournit une checklist d’audit pratique combinant les exigences du RGAA 4.1 (Référentiel Général d’Amélioration de l’Accessibilité, version française) et de WCAG 2.2 (Web Content Accessibility Guidelines, standard international du W3C). Plutôt qu’une lecture exhaustive et indigeste des 106 critères du RGAA, vous trouverez ici les vérifications concrètes à effectuer pendant un audit, classées par priorité d’impact utilisateur. Cette checklist convient aussi bien à un audit interne par une équipe développement qu’à la préparation d’un audit externe officiel.

Prérequis

• Connaissances : HTML5 sémantique, CSS basique, JavaScript pour les composants interactifs
• Outils logiciels : Chrome/Firefox récent, lecteur d’écran (NVDA gratuit sur Windows, VoiceOver intégré macOS)
• Outils audit : Lighthouse intégré DevTools, axe DevTools (extension), WAVE WebAIM
• Niveau requis : intermédiaire — connaissances HTML/CSS, sensibilité accessibilité bienvenue
• Temps estimé : 2 à 4 heures pour un audit complet d’un site moyen de 20-30 pages

1. Comprendre les niveaux de conformité

Avant de commencer l’audit, il faut comprendre les niveaux de conformité de WCAG 2.2 et du RGAA. Cette compréhension détermine vos objectifs réalistes et la priorisation des corrections. Pour une PME, viser le niveau AA sur l’ensemble du site et le niveau AAA sur les pages critiques (formulaire de contact, parcours d’achat, informations produit) est un objectif pragmatique et atteignable en quelques semaines de travail.

Le RGAA 4.1 couvre les critères WCAG 2.1 niveaux A et AA, avec des précisions et adaptations pour le contexte français. WCAG 2.2 (publié en octobre 2023) ajoute neuf nouveaux critères de succès, notamment sur les interactions tactiles, la visibilité du focus, et l’authentification accessible. La version 4.2 du RGAA, attendue courant 2026, intégrera ces ajouts WCAG 2.2.

2. Préparer l’environnement d’audit

Un audit efficace commence par un environnement bien préparé. Vous devez pouvoir basculer rapidement entre la vue navigateur normale, la vue accessibility tree des DevTools, le lecteur d’écran, et les outils d’audit automatisés. La fluidité de cette navigation détermine grandement la productivité de votre audit.

# Outils à installer/configurer une fois pour toutes :

# 1. Extension axe DevTools (Chrome/Firefox)
# https://www.deque.com/axe/devtools/
# - Détecte automatiquement 30-40% des problèmes d'accessibilité
# - Intégration native dans les DevTools navigateur

# 2. Extension WAVE (Chrome/Firefox)
# https://wave.webaim.org/extension/
# - Visualisation graphique sur la page elle-même
# - Bonne pour la formation et la sensibilisation équipe

# 3. NVDA (Windows) - lecteur d'écran gratuit
# https://www.nvaccess.org/download/
# - Indispensable pour tester l'expérience non-visuelle réelle
# - Raccourci INSERT+T = lire titre, INSERT+T = navigation par titres

# 4. Lighthouse intégré Chrome
# DevTools > onglet "Lighthouse" > catégorie "Accessibility"
# - Score global rapide, exporte en JSON pour suivi historique

Apprenez les raccourcis clavier essentiels de votre lecteur d’écran : INSERT+H pour les titres, INSERT+F pour les formulaires, INSERT+L pour les listes, INSERT+T pour les tableaux. Ces raccourcis vous permettent de naviguer dans une page comme le ferait un utilisateur non-voyant et de détecter immédiatement les structures mal formées.

Étape 1 — Audit automatisé Lighthouse + axe

Commencez toujours par les audits automatisés. Ils détectent rapidement 30 à 40% des problèmes (les plus mécaniques : alt manquants, contrastes insuffisants, attributs ARIA invalides) et donnent une base de score chiffrée pour mesurer votre progression au fil du temps. C’est aussi votre filet de sécurité contre les régressions : intégrez-les dans votre CI/CD pour bloquer toute mise en production qui dégraderait l’accessibilité.

# Lighthouse en CLI (intégrable CI/CD) :
npm install -g lighthouse

# Audit complet d'une page
lighthouse https://votre-site.com \
  --output=json \
  --output-path=./audit.json \
  --only-categories=accessibility \
  --chrome-flags="--headless"

# Parser le score
cat audit.json | jq '.categories.accessibility.score'
# Doit retourner ≥ 0.9 pour être acceptable

# Audit de plusieurs pages avec axe-cli
npm install -g @axe-core/cli
axe https://votre-site.com/page1 \
    https://votre-site.com/page2 \
    https://votre-site.com/page3 \
    --tags wcag2aa,wcag22aa

Notez que Lighthouse retourne un score sur 100, mais ce score n’est qu’une indication : un site à 100/100 Lighthouse peut quand même avoir de gros problèmes d’accessibilité non détectables automatiquement (étiquettes mal formulées, ordre logique incohérent, pièges au clavier conditionnels). Lighthouse couvre environ 30% des critères WCAG, le reste demande inspection manuelle.

Étape 2 — Vérifier la structure HTML sémantique

La structure HTML est le squelette qui rend une page navigable pour les lecteurs d’écran. Une page avec une structure cassée est inutilisable, même si visuellement parfaite. C’est le critère le plus important après les contrastes, et le plus souvent négligé par les développeurs habitués à empiler des <div> partout.

# Tester rapidement la structure d'une page avec NVDA :
# 1. Ouvrir la page
# 2. Lancer NVDA (Ctrl+Alt+N)
# 3. Appuyer sur INSERT+F7 → liste des éléments
# 4. Filtrer par "Titres" → vérifier la hiérarchie
# 5. Filtrer par "Régions" → vérifier la présence des landmarks main/nav/etc

# Si vous voyez "Régions : 0", la structure HTML5 sémantique manque
# Solution : remplacer les <div id="header"> par <header>
#           les <div id="nav"> par <nav>
#           les <div id="content"> par <main>

La hiérarchie des titres est particulièrement critique. Un saut de h2 à h4 sans h3 perturbe la navigation par titres des utilisateurs de lecteurs d’écran, qui s’attendent à une structure hiérarchique cohérente. C’est un défaut très fréquent dans les sites WordPress où les designers ajoutent des titres pour leur taille visuelle plutôt que pour leur sens sémantique.

Étape 3 — Vérifier les contrastes et lisibilité

Le contraste insuffisant est le défaut d’accessibilité le plus répandu et l’un des plus simples à corriger. Pour viser AA, vous devez respecter un ratio de contraste de 4,5:1 pour le texte normal et 3:1 pour le texte de grande taille (18 pt ou 14 pt en gras). Pour AAA, ces seuils montent à 7:1 et 4,5:1 respectivement.

# Vérifier un couple de couleurs avec un outil en ligne :
# https://webaim.org/resources/contrastchecker/
# Entrer foreground (texte) + background → ratio calculé

# En CLI avec un script Node :
npm install -g wcag-contrast
wcag-contrast hex "#333333" "#ffffff"
# Retourne le ratio et le verdict AA/AAA

# Audit batch de toute la palette d'un site :
# Utiliser axe DevTools → "Color Contrast" pour scan complet de la page

# Pour les designers, intégrer le check dans Figma/Penpot avec :
# - Plugin "Stark" (Figma)
# - Plugin "A11y - Color Contrast" (Penpot)

Attention aux gris clairs sur fond blanc qui sont visuellement esthétiques mais invisibles pour de nombreux utilisateurs. Le gris #999999 sur blanc donne un ratio de seulement 2,85:1 — bien en dessous du seuil AA. Préférez #767676 qui atteint 4,54:1, juste au-dessus du seuil. Pour les textes secondaires (legends, footnotes), descendre à #595959 donne 7,04:1 (AAA) sans paraître trop noir.

Étape 4 — Tester la navigation au clavier

Tout site doit être totalement utilisable au clavier seul, sans souris ni écran tactile. C’est essentiel pour les utilisateurs avec des handicaps moteurs, mais aussi pour les utilisateurs non-voyants (qui n’utilisent pas la souris) et pour les utilisateurs avancés qui préfèrent la rapidité du clavier.

# Test manuel à effectuer sur chaque page :
# 1. Recharger la page
# 2. Cliquer dans la barre d'URL puis appuyer Tab
# 3. Naviguer avec Tab uniquement à travers tous les éléments interactifs
# 4. Vérifier à chaque tabulation :
#    - Le focus est visible (outline ou bordure)
#    - L'ordre logique correspond à la lecture (haut→bas, gauche→droite)
#    - Aucun élément interactif n'est sauté
#    - Aucun piège au clavier (impossible de sortir d'un widget)
# 5. Tester Enter et Espace sur chaque bouton/lien
# 6. Tester les flèches sur les menus déroulants et accordéons

# Pour repérer les pièges au clavier rapidement :
# Si vous arrivez sur un élément et ne pouvez plus en sortir avec Tab,
# c'est un piège → corriger immédiatement

Une erreur très fréquente est l’utilisation de outline: none; en CSS pour des raisons esthétiques, sans fournir d’alternative visible. Ne supprimez jamais l’outline du focus sans le remplacer par une indication visuelle claire (border, box-shadow, background distinct). WCAG 2.2 ajoute le critère 2.4.11 « Focus Not Obscured » qui exige que l’élément focusé ne soit pas masqué par un autre élément de l’interface (typiquement une bannière sticky qui cache le focus quand on tab).

Étape 5 — Vérifier les formulaires

Les formulaires sont l’élément interactif le plus complexe à rendre accessible. Mal faits, ils bloquent les conversions et excluent une partie de votre audience. Bien faits, ils améliorent l’expérience pour tous les utilisateurs.

# Snippet HTML conforme RGAA pour un formulaire de contact :
<form>
  <fieldset>
    <legend>Vos coordonnées</legend>

    <label for="nom">Nom <span aria-label="obligatoire">*</span></label>
    <input id="nom" name="nom" type="text"
           autocomplete="name"
           aria-required="true"
           aria-describedby="nom-help">
    <span id="nom-help" class="help">Tel qu'il apparaît sur votre pièce d'identité</span>

    <label for="email">Email <span aria-label="obligatoire">*</span></label>
    <input id="email" name="email" type="email"
           autocomplete="email"
           aria-required="true"
           aria-invalid="false">
  </fieldset>

  <button type="submit">Envoyer le message</button>
</form>

Le placeholder ne remplace JAMAIS un label : il disparaît quand l’utilisateur commence à taper, ce qui rend le champ inutilisable pour quelqu’un qui aurait besoin de revérifier ce qu’on lui demande. C’est l’erreur la plus courante en 2026, généralement issue de tutoriels ou de templates qui privilégient l’esthétique « propre » au détriment de l’utilisabilité réelle.

Étape 6 — Vérifier les médias

Les images, vidéos et contenus audio doivent être accessibles aux utilisateurs qui ne peuvent pas les percevoir directement. Cette section concerne autant les images statiques que les contenus multimédias dynamiques.

• Images informatives : alt descriptif et concis (pas « image de… » mais directement le contenu)
• Images décoratives : alt="" (vide) pour qu’elles soient ignorées par les lecteurs d’écran
• Images complexes (graphiques, infographies) : alt court + description longue dans le texte adjacent ou via aria-describedby
• Vidéos : sous-titres synchronisés (SRT/WebVTT), transcription complète disponible séparément
• Audio : transcription textuelle complète, idéalement avec marqueurs temporels
• Contenus auto-play : à éviter absolument, ou fournir un bouton pause/stop visible

Adaptation au contexte ouest-africain

Trois aspects spécifiques méritent attention pour les sites web ouest-africains. Premièrement, la prise en compte du multilinguisme. Beaucoup de sites institutionnels ou e-commerce ont des contenus partiellement en français, partiellement en anglais ou en langues nationales (wolof, bambara, mooré). Marquez explicitement les passages dans une autre langue avec l’attribut lang approprié : <span lang="en">Welcome</span>. Cela permet aux lecteurs d’écran de basculer leur synthèse vocale dans la bonne langue.

Deuxièmement, la question des connexions limitées. Une bonne accessibilité inclut aussi la performance : un site qui met 30 secondes à charger sur une 3G saturée est inaccessible de fait. Optimisez les images (formats WebP ou AVIF), évitez les fontes web inutiles, n’imposez pas de JavaScript bloquant. Le critère WCAG 2.2.6 « Timeouts » est particulièrement pertinent pour les utilisateurs sur connexions instables.

Troisièmement, l’accessibilité numérique progresse rapidement comme exigence dans les marchés publics ouest-africains. Le Sénégal, la Côte d’Ivoire et le Bénin ont commencé à intégrer des critères d’accessibilité dans leurs cahiers des charges pour les sites gouvernementaux. Une PME prestataire qui peut documenter sa démarche d’accessibilité (déclaration de conformité, audit régulier) gagne un avantage commercial significatif sur les appels d’offres de l’administration.

Erreurs fréquentes

Documentation et déclaration de conformité

L’audit ne sert à rien sans documentation. Pour respecter le RGAA, vous devez publier une « déclaration d’accessibilité » sur le site, mise à jour annuellement. Cette déclaration indique le niveau de conformité atteint, les non-conformités résiduelles connues, et le contact pour signaler un problème d’accessibilité.

# Modèle minimal de déclaration de conformité (HTML) :
<article>
  <h1>Déclaration d'accessibilité</h1>
  <p>[Nom de votre PME] s'engage à rendre son site accessible
     conformément à l'article 47 de la loi n° 2005-102 du 11 février 2005.</p>
  <p>Cette déclaration s'applique au site <strong>votre-site.com</strong>.</p>

  <h2>État de conformité</h2>
  <p>Le site est en conformité <strong>partielle</strong> avec le RGAA 4.1
     en raison des non-conformités énumérées ci-dessous.</p>

  <h2>Résultats des tests</h2>
  <p>L'audit de conformité réalisé en [mois année] par [auteur]
     révèle que [X]% des critères du RGAA sont respectés.</p>

  <h2>Contenus non accessibles</h2>
  <ul>
    <li>Certaines images d'illustration n'ont pas de description textuelle</li>
    <li>Le carrousel de la page d'accueil n'est pas pleinement navigable au clavier</li>
  </ul>

  <h2>Voie de recours</h2>
  <p>Si vous constatez un défaut d'accessibilité vous empêchant d'accéder
     à un contenu, contactez : <a href="mailto:accessibilite@votre-pme.sn">
     accessibilite@votre-pme.sn</a></p>
</article>

Cette déclaration doit être accessible depuis chaque page du site, idéalement dans le footer. La transparence sur les non-conformités résiduelles n’est pas une faiblesse : elle prouve la démarche d’amélioration continue et protège juridiquement votre organisation. Mieux vaut documenter honnêtement « 87% de conformité avec ces 13 non-conformités » qu’afficher faussement « 100% conforme » que tout audit externe démentirait.

Articles connexes

• Lighthouse + Pa11y : automatiser audit accessibilité — tutoriel 2026
• Sobriété numérique : optimiser empreinte carbone site web 2026

FAQ

Faut-il viser AAA ou AA est-il suffisant légalement ?
AA suffit pour le RGAA (loi française) et l’EAA (directive européenne). AAA est un objectif de qualité maximale mais n’est pas exigé légalement. Visez AA partout, AAA sur les pages critiques (paiement, contact, informations produit majeures).

Combien de temps prend un audit complet pour un site moyen ?
Pour un site de 20 à 30 pages avec quelques formulaires, comptez 3 à 5 jours par un auditeur expérimenté. Avec les outils automatisés (Lighthouse, axe), le pré-audit peut être fait en 2 heures, mais la validation manuelle reste indispensable.

Mon site est sur WordPress, comment évaluer rapidement l’accessibilité ?
Installez le plugin « WP Accessibility » qui corrige automatiquement plusieurs défauts courants. Lancez Lighthouse sur les pages principales. Choisissez un thème dont la déclaration d’accessibilité est explicite (Astra, Twenty Twenty-Three).

Les outils automatisés détectent-ils tout ?
Non, ils détectent environ 30% des problèmes WCAG. Les 70% restants exigent un audit manuel : contextes d’images, ordre logique, étiquettes pertinentes, gestion focus complexe. L’automatisation est nécessaire mais insuffisante.

Que faire si je constate qu’un de mes anciens projets est très peu accessible ?
Hiérarchisez : commencez par les pages les plus visitées (analytics) et les plus critiques (conversion). Visez d’abord à supprimer les obstacles bloquants (niveau A) avant les optimisations AA. Communiquez sur la démarche progressive plutôt que d’attendre la perfection.

Pour aller plus loin

• 🔝 Retour au guide général : Site web accessible RGAA et green IT 2026 : conformité Afrique de l’Ouest
• RGAA 4.1 officiel : accessibilite.numerique.gouv.fr
• WCAG 2.2 (W3C) : w3.org/TR/WCAG22
• Documentation axe DevTools : deque.com/axe/devtools
• WebAIM Color Contrast : webaim.org/resources/contrastchecker

Mots-clés : RGAA 4.1 audit, WCAG 2.2 checklist, accessibilité numérique pme, Lighthouse axe DevTools, conformité site web 2026, lecteur d’écran NVDA.