RGAA vs WCAG vs EN 301 549 : Le Comparatif des Normes 2026

1. Triangulation normative

La prolifération des cadres de référence en accessibilité numérique engendre une confusion coûteuse au sein des directions techniques et juridiques. Pour piloter efficacement la mise en conformité de vos applications web et de vos interfaces de consentement face aux obligations de l'European Accessibility Act (EAA 2026), il est indispensable de dissocier la recommandation technique universelle, la norme harmonisée européenne et la méthode opérationnelle nationale.

Les WCAG (Web Content Accessibility Guidelines), éditées par le W3C via la Web Accessibility Initiative (WAI), constituent le socle scientifique mondial. La recommandation WCAG 2.2, publiée au statut de recommandation officielle, n'a pas en soi de force exécutoire directe dans les juridictions nationales, mais sert d'étalon technologique international pour les niveaux A, AA et AAA.

À l'échelle de l'Union européenne, le pivot juridique exclusif est la norme EN 301 549 V3.2.1 (« Exigences d'accessibilité pour les produits et services TIC »), élaborée conjointement par le CEN, le CENELEC et l'ETSI sous mandat de la Commission européenne. C'est l'unique norme harmonisée publiée au Journal Officiel de l'Union européenne (JOUE) qui confère une présomption légale de conformité avec la directive (UE) 2019/882. Son architecture transcende le seul écosystème web : le Chapitre 9 absorbe les critères WCAG niveau A et AA, tandis que les Chapitres 10 (Documents non web), 11 (Logiciels, incluant les applications natives mobiles et les micro-frontends de CMP) et 12 (Services d'assistance) imposent des exigences contractuelles et ergonomiques distinctes.

En France, le RGAA (Référentiel Général d'Amélioration de l'Accessibilité), piloté par la DINUM en application de l'article 47 de la loi n° 2005-102, n'est pas une norme juridique concurrente mais une méthode d'application et de vérification. Sa version 4.1.2 décline 106 critères de contrôle assortis de tests pas-à-pas rigoureux. Toutefois, le RGAA 4.1.2 est historiquement indexé sur WCAG 2.1 AA : s'il garantit une couverture rigoureuse de ce périmètre, il génère un décalage substantiel face aux exigences européennes actualisées qui incorporent les avancées de WCAG 2.2.

2. Matrice comparative exhaustive

Pour orchestrer un audit sans angle mort, les équipes de conformité doivent appréhender précisément la granularité, les instances de gouvernance et le champ d'application de chaque document de référence. Les sanctions prévues sous le régime de l'EAA (pouvant atteindre 5 % du chiffre d'affaires annuel ou 100 000 euros d'amende administrative en France via la DGCCRF) excluent tout arbitrage approximatif.

L'analyse comparative met en lumière une fracture stratégique : le RGAA fournit une grille de contrôle prescriptive supérieure (les tests unitaires définissent précisément les requêtes DOM et les combinaisons d'assistance attendues), mais il accuse un déficit d'alignement avec les 9 nouveaux critères d'évaluation de WCAG 2.2, lesquels sont déjà intégrés dans les grilles d'audit de la Commission européenne et du réseau des régulateurs de l'EAA. Pour comprendre l'ampleur des risques financiers encourus, consultez notre rapport sur les sanctions et amendes liées à l'inaccessibilité numérique.

3. Le delta WCAG 2.2 : Les 9 critères absents du RGAA 4.1.2 à

Pour transformer une déclaration d'accessibilité RGAA en passeport de conformité européen sous l'EN 301 549, les organisations doivent combler le différentiel créé par l'introduction de WCAG 2.2. L'actualisation a supprimé le critère 4.1.1 (Parsing / Validité du code, rendu obsolète par les parseurs HTML5 modernes) et a inséré neuf nouveaux critères de succès, dont six s'appliquent directement au niveau AA requis par l'EAA :

• 2.4.11 Focus Not Obscured (Minimum) (AA) : Lors de la navigation séquentielle au clavier, le composant interactif ayant le focus ne doit pas être intégralement masqué par un contenu créé par l'auteur, tel qu'une bannière de cookies sticky, un dialogue modal mal imbriqué ou un bandeau d'assistance fixe.
• 2.4.12 Focus Not Obscured (Enhanced) (AAA) : Aucun fragment du composant ciblé par le focus ne doit être masqué (niveau AAA, non imposé par l'EAA mais recommandé sur les parcours critiques).
• 2.4.13 Focus Appearance (AAA) : Établit des exigences strictes de contraste (3:1) et d'épaisseur périphérique (au moins 2 pixels CSS) pour l'indicateur visuel de prise de focus.
• 2.5.7 Dragging Movements (AA) : Toute fonctionnalité reposant sur un mouvement de glisser-déposer (ex : tri d'éléments dans un tableau de bord, curseur coulissant de consentement CMP) doit offrir une alternative accessible par simple clic ou activation clavier.
• 2.5.8 Target Size (Minimum) (AA) : La zone tactile minimale pour tout pointeur doit atteindre au moins 24x24 pixels CSS, ou compenser par un espacement suffisant entre cibles interactives adjacentes. Ce critère est critique lors des vérifications d'audit d'accessibilité des CMP du marché où les cases à cocher et boutons secondaires sont fréquemment sous-dimensionnés.
• 3.2.6 Consistent Help (A) : Si des mécanismes d'aide (contact humain, FAQ, messagerie instantanée, chatbot) sont présents sur plusieurs pages d'un ensemble web, leur ordre relatif d'apparition dans le code doit être strictement identique.
• 3.3.7 Redundant Entry (A) : Les données précédemment saisies par l'utilisateur au cours d'un processus multi-étapes (ex : commande e-commerce, formulaire fiscal) doivent être automatiquement réinjectées ou sélectionnables, sauf impératif de sécurité stricte.
• 3.3.8 Accessible Authentication (Minimum) (AA) : Interdiction formelle d'imposer un test d'aptitude cognitive (mémorisation de mot de passe complexe, résolution de calculs arithmétiques, transcription d'un CAPTCHA textuel ou d'énigmes visuelles) pour s'authentifier, sans proposer d'alternative telle que la prise en charge des gestionnaires de mots de passe, le copier-coller de jetons ou le WebAuthn / Passkeys.
• 3.3.9 Accessible Authentication (Enhanced) (AAA) : Élimine l'exception de reconnaissance visuelle d'objets ou d'images personnelles admise en 3.3.8.

Un rapport d'audit fondé exclusivement sur la grille RGAA 4.1.2 passe totalement sous silence l'inaccessibilité d'une cinématique d'authentification basée sur un CAPTCHA propriétaire (3.3.8) ou une rangée de boutons de pagination mobiles ne respectant pas les 24 pixels de diagonale effective (2.5.8).

4. Méthodologie d'audit hybride et industrialisation CI/CD

Pour sécuriser une double attestation RGAA 4.1.2 (France) et EN 301 549 / WCAG 2.2 AA (Europe), la Cellule Investigation CookieDetox préconise un protocole en trois couches : échantillonnage certifié, automatisation CI/CD avancée et contre-expertise humaine sur technologies d'assistance.

L'échantillon d'audit doit obligatoirement agréger les pages institutionnelles réglementaires (accueil, contact, mentions légales, déclaration d'accessibilité) et l'intégralité du tunnel de conversion : étape de consentement CMP, mire d'authentification, panier d'achat, consultation de compte client et formulaires transactionnels. Les composants d'interaction globale (modales, bannières tierces, popins de notification) doivent être évalués isolément dans chacun de leurs états DOM dynamiques.

Sur le plan de l'intégration continue, le moteur open-source Axe-core (v4.9+) permet d'auditer dynamiquement les critères automatisables de WCAG 2.2, notamment la taille des cibles tactiles et le contraste du focus. Voici l'implémentation de référence sous Playwright Test pour traquer automatiquement les violations target-size et le masquage de focus induit par une CMP :

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test.describe('Vérification Conformité EN 301 549 & WCAG 2.2', () => {
  test('Contrôle automatisé des cibles tactiles et états de focus', async ({ page }) => {
    await page.goto('https://plateforme.entreprise.tld/', { waitUntil: 'networkidle' });

    // Injection et exécution sélective Axe-core sur WCAG 2.2 AA
    const axeResults = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
      .include('body')
      .exclude('#analytics-debug-iframe')
      .analyze();

    // Détection des violations bloquantes pour l'EAA 2026
    const severeViolations = axeResults.violations.filter(v => 
      v.impact === 'critical' || v.impact === 'serious'
    );

    expect(severeViolations).toEqual([]);

    // Test spécifique WCAG 2.2 (2.4.11 Focus Not Obscured) avec injection d'une CMP
    const loginButton = page.locator('button#submit-auth');
    await loginButton.focus();

    const isObscured = await page.evaluate(() => {
      const el = document.querySelector('button#submit-auth');
      if (!el) return false;
      const rect = el.getBoundingClientRect();
      // Vérification du chevauchement par un conteneur z-index supérieur (ex: bannière CMP)
      const topEl = document.elementFromPoint(rect.left + rect.width / 2, rect.top + rect.height / 2);
      return topEl !== el && !el.contains(topEl);
    });

    expect(isObscured).toBe(false);
  });
});

Cependant, l'outillage automatisé ne détectant qu'environ 35 % à 45 % des non-conformités réelles, la certification finale exige un protocole de revue manuelle sur des environnements normalisés : NVDA (dernière version stable) sous Mozilla Firefox sur Windows 11, et VoiceOver sous Safari sur macOS et iOS. Le calcul du taux de conformité global doit être documenté via la formule standardisée du RGAA (Critères conformes / Critères applicables × 100), complétée par l'annexe de compatibilité EN 301 549 V3.2.1 pour la publication transfrontalière.