Audit d'accessibilité web : guide complet WCAG 2.2, EN 301 549 et RGAA 4.1

1. Pourquoi réaliser un audit d'accessibilité en 2025 ?

Depuis le 28 juin 2025, l'Acte européen sur l'accessibilité (EAA) est en vigueur. Les entreprises qui vendent des produits ou services numériques dans l'Union européenne sont légalement tenues de respecter la norme EN 301 549, elle-même basée sur WCAG 2.2 niveau AA. En France, le RGAA 4.1 s'applique en sus pour les organismes publics et les entreprises d'une certaine taille.

Ce n'est plus une question de bonne volonté. C'est une obligation légale. Les autorités nationales de surveillance du marché ont déjà commencé à recevoir des plaintes depuis fin 2025, et les premières décisions administratives arrivent. Les amendes peuvent atteindre 300 000 € selon la juridiction et la gravité de la non-conformité.

Au-delà du risque réglementaire, l'accessibilité élargit votre audience. En France, 12 millions de personnes vivent avec un handicap. À l'échelle de l'UE, c'est 87 millions de personnes — soit environ 20 % de la population. Un site inaccessible exclut mécaniquement une part significative de vos clients potentiels.

2. WCAG 2.2, EN 301 549 et RGAA 4.1 — les différences

Les trois normes coexistent et se recoupent partiellement. Voici comment les distinguer :

Ce qui change entre WCAG 2.1 et WCAG 2.2

WCAG 2.2 (publiée en octobre 2023) ajoute 9 nouveaux critères de succès par rapport à WCAG 2.1, principalement autour de la navigation au clavier et de l'authentification accessible :

• 2.4.11 Focus Not Obscured (Minimum) — le focus clavier ne doit pas être entièrement masqué
• 2.4.12 Focus Not Obscured (Enhanced) — version renforcée, niveau AAA
• 2.4.13 Focus Appearance — le focus doit avoir une zone minimum visible de 2px
• 2.5.7 Dragging Movements — toute action de glisser-déposer doit avoir une alternative
• 2.5.8 Target Size (Minimum) — les cibles tactiles font au moins 24×24 pixels
• 3.2.6 Consistent Help — les mécanismes d'aide apparaissent au même endroit
• 3.3.7 Redundant Entry — ne pas redemander des informations déjà saisies
• 3.3.8 Accessible Authentication (Minimum) — pas de test cognitif dans l'authentification
• 3.3.9 Accessible Authentication (Enhanced) — version renforcée, niveau AAA

Le RGAA en pratique

Le RGAA décompose chaque critère WCAG en tests précis avec des procédures de vérification explicites. Là où WCAG dit « les images doivent avoir un texte alternatif », le RGAA décrit exactement comment tester chaque cas (image informative, décorative, CAPTCHA, carte, etc.). C'est plus contraignant à auditer, mais beaucoup plus actionnable pour les équipes.

3. La méthode d'audit en 6 étapes

Un audit d'accessibilité rigoureux n'est pas juste « lancer un outil et copier-coller le rapport ». Voici la méthode structurée recommandée pour un audit WCAG / RGAA complet.

1. Définir le périmètre et l'échantillon de pages

   Le RGAA recommande un échantillon représentatif — au minimum : page d'accueil, une page de contenu, un formulaire de contact, une page de résultats de recherche, une page de documentation. Pour un site e-commerce : ajoutez la fiche produit, le panier et le checkout.

2. Scan automatisé sur toutes les pages de l'échantillon

   Utilisez un outil comme CompliScope pour couvrir rapidement les violations évidentes : contrastes, attributs alt manquants, labels de formulaire, structure des titres, hiérarchie ARIA. Cela prend 2 à 10 minutes selon la taille du site.

3. Audit manuel avec clavier seul

   Naviguez sur chaque page uniquement avec Tab, Shift+Tab, Entrée et Espace. Vérifiez que tout élément interactif est atteignable, que le focus est visible, que l'ordre de tabulation est logique, et qu'il n'y a pas de piège clavier.

4. Test avec lecteur d'écran

   Utilisez NVDA + Firefox (Windows), VoiceOver + Safari (macOS/iOS) ou TalkBack (Android). Vérifiez les annonces de navigation, les alternatives textuelles, les messages d'erreur de formulaire et les mises à jour dynamiques (ARIA live regions).

5. Vérifications complémentaires : couleurs, agrandissement, animations

   Testez avec un simulateur de daltonisme (Colour Contrast Analyser), à 200 % et 400 % de zoom (pas de perte de contenu), et désactivez les animations (prefers-reduced-motion) pour valider les critères liés à la perception.

6. Consolider et prioriser le rapport

   Regroupez les problèmes par type (même correction = un item), ajoutez le critère WCAG/RGAA concerné, une capture d'écran, le code défaillant et le correctif recommandé. Priorisez par impact utilisateur (bloquant, majeur, mineur) et par fréquence d'occurrence.

4. Les 10 erreurs d'accessibilité les plus fréquentes

D'après les données de milliers de scans CompliScope, voici les violations WCAG les plus répandues — avec leur critère, leur impact et comment les corriger.

5. Outils automatisés vs audit manuel : que choisir ?

La question n'est pas « automatisé ou manuel » — c'est « comment combiner les deux efficacement ».

Ce que les outils automatisés détectent bien

Les outils basés sur axe-core, Deque ou WAVE détectent avec précision :

• Attributs alt manquants ou vides sur des images informatives
• Ratios de contraste calculés — texte, icônes, éléments d'interface
• Étiquettes de formulaire manquantes ou mal associées
• Attribut lang absent sur <html>
• Titre de page (<title>) absent ou dupliqué
• Rôles ARIA invalides ou attributs ARIA orphelins
• Structure de titres incorrecte (sauts de niveaux)
• Boutons et liens sans texte accessible

Ce que les outils manquent (et nécessite un test humain)

Les outils automatisés ne détectent pas :

• La qualité sémantique des textes alternatifs — un alt="image.jpg" passe l'outil mais est inutile
• L'ordre logique de lecture et de focus
• Les pièges de clavier dans des interactions JavaScript complexes
• La pertinence des annonces de lecteur d'écran (ARIA live regions)
• La compréhension cognitive — instructions claires, messages d'erreur utiles
• Les sous-titres vidéo — leur présence peut être vérifiée, pas leur qualité
• Les animations et clignotements potentiellement épileptogènes (seuil précis)

Comparaison des principaux outils

6. Corriger les erreurs : priorisation et code

Une fois l'audit terminé, la liste de correctifs peut sembler écrasante. Voici comment prioriser et corriger les problèmes les plus impactants.

Prioriser par impact, pas par nombre

Un problème de niveau A (WCAG A) qui bloque la navigation principale est plus urgent que dix problèmes de niveau AA mineurs. Utilisez cette grille de priorisation :

• Bloquant (P0) — l'utilisateur ne peut pas accomplir sa tâche principale (ex. : formulaire innaccessible au clavier)
• Critique (P1) — l'expérience est sévèrement dégradée (ex. : focus invisible sur la navigation principale)
• Majeur (P2) — la tâche est possible mais difficile (ex. : contraste insuffisant sur le texte de contenu)
• Mineur (P3) — inconfort sans blocage (ex. : attribut lang sur un élément secondaire)

Correctifs les plus courants

Images sans alt — correctif :

<!-- ❌ Incorrect -->
<img src="graphique-ventes.png">

<!-- ✅ Image informative -->
<img src="graphique-ventes.png" alt="Croissance des ventes de 12 % au T1 2026">

<!-- ✅ Image décorative -->
<img src="separateur.svg" alt="" role="presentation">

Labels de formulaire — correctif :

<!-- ❌ Incorrect -->
<input type="email" placeholder="Votre email">

<!-- ✅ Correct -->
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email" autocomplete="email">

<!-- ✅ Alternatif (aria-label) -->
<input type="email" aria-label="Adresse e-mail" autocomplete="email">

Focus clavier — correctif CSS :

/* ❌ À ne jamais faire */
*:focus { outline: none; }

/* ✅ Indicateur de focus visible */
a:focus-visible,
button:focus-visible,
[tabindex]:focus-visible {
  outline: 3px solid #1a5cff;
  outline-offset: 2px;
  border-radius: 4px;
}

Lien d'évitement — correctif HTML/CSS :

<!-- Dans <body>, premier élément -->
<a href="#main-content" class="skip-link">Aller au contenu principal</a>

<main id="main-content">...</main>

/* CSS — visible uniquement au focus */
.skip-link {
  position: absolute;
  top: -60px;
  left: 0;
  background: #1a5cff;
  color: white;
  padding: 0.75rem 1.5rem;
  border-radius: 0 0 8px 0;
  text-decoration: none;
  font-weight: 600;
  transition: top 0.15s;
}
.skip-link:focus { top: 0; }

Maintenance continue

L'accessibilité se dégrade dès la prochaine mise à jour de contenu ou de code. Intégrez la vérification dans votre pipeline CI/CD avec axe-core ou l'API CompliScope, et planifiez un re-scan mensuel — surtout après les déploiements majeurs.

7. Questions fréquentes

Qu'est-ce qu'un audit d'accessibilité web ?

Un audit d'accessibilité web est une évaluation systématique d'un site ou d'une application pour vérifier sa conformité aux normes WCAG, EN 301 549 et/ou RGAA. Il identifie les barrières qui empêchent les personnes handicapées d'utiliser le site, et fournit des recommandations de correction priorisées.

Quelle est la différence entre WCAG, EN 301 549 et RGAA ?

WCAG 2.2 est la norme internationale du W3C pour l'accessibilité web. EN 301 549 est la norme harmonisée européenne qui incorpore WCAG 2.2 avec des exigences supplémentaires (mobile, documents, logiciels). RGAA 4.1 est le référentiel national français dérivé de WCAG, avec 106 critères testables et une méthodologie de test précise. Pour l'EAA 2025, la conformité EN 301 549 est juridiquement obligatoire ; RGAA est imposé par le droit français.

Combien de temps prend un audit d'accessibilité ?

Un audit automatisé (scan outil) prend 30 secondes à quelques minutes selon la taille du site. Un audit manuel complet RGAA ou WCAG 2.2 d'un site de 50 pages prend généralement 3 à 10 jours ouvrés pour un auditeur expérimenté. Un audit mixte (automatisé + validation manuelle ciblée) offre le meilleur équilibre coût/couverture.

Les outils automatisés suffisent-ils pour un audit WCAG ?

Non. Les outils automatisés détectent 30 à 40 % des violations WCAG. Le reste — ordre de focus, comportement des lecteurs d'écran, complexité cognitive, sous-titres vidéo — nécessite un test humain. Pour une conformité EAA juridiquement défendable, un audit mixte automatisé + manuel est requis.

Un audit d'accessibilité est-il obligatoire pour l'EAA 2025 ?

L'EAA impose la conformité EN 301 549 depuis le 28 juin 2025 pour les entreprises privées vendant dans l'UE. Un audit formel n'est pas explicitement obligatoire par la loi, mais il constitue la preuve standard de conformité et est exigé en cas de contrôle ou de plainte.

Qu'est-ce qu'une déclaration d'accessibilité ?

La déclaration d'accessibilité est un document publié sur votre site qui indique votre niveau de conformité WCAG/RGAA, les pages ou fonctionnalités non conformes, et un moyen de signalement pour les utilisateurs. Elle est obligatoire pour les organismes publics en France (RGAA) et fortement recommandée pour le secteur privé soumis à l'EAA. CompliScope Pro génère un modèle de déclaration à partir de votre rapport d'audit.