RGAA vs WCAG vs EN 301 549: 2026 Standards Matrix & Guide

1. Normative Triangulation: Roles, Hierarchy, and Legal Status

The proliferation of digital accessibility frameworks creates substantial friction across engineering, product, and legal divisions. To steer web applications, customer portals, and consent mechanisms toward compliance with the European Accessibility Act (EAA 2026), organizations must untangle the differences between universal technical recommendations, harmonised European standards, and national operational audit methodologies.

The Web Content Accessibility Guidelines (WCAG), published by the W3C through the Web Accessibility Initiative (WAI), define the global technical baseline. WCAG 2.2, published as an official W3C Recommendation, holds no direct statutory force on its own in national courts, but serves as the international reference benchmark across Level A, AA, and AAA criteria. In the United States, WCAG 2.1 AA serves as the de facto technical standard under ADA Title III enforcement actions and DOJ rulemakings, while the UK Equality Act 2010 relies on WCAG benchmarks through Central Digital and Data Office (CDDO) monitoring.

Across the European Union, the authoritative legal anchor is EN 301 549 V3.2.1 ("Accessibility requirements for ICT products and services"), jointly developed by CEN, CENELEC, and ETSI under European Commission Standardization Mandate M/554. It is the sole harmonised standard published in the Official Journal of the European Union (OJEU) that grants a legal presumption of conformity with Directive (EU) 2019/882 (EAA). Its scope extends far beyond standard web markup: Chapter 9 absorbs WCAG Level A and AA criteria, while Chapter 10 (Non-web documents), Chapter 11 (Software, including native mobile applications and CMP micro-frontends), and Chapter 12 (Support services) impose binding ergonomic and contractual requirements.

In France, the RGAA (Référentiel Général d'Amélioration de l'Accessibilité), maintained by DINUM under Article 47 of Law No. 2005-102, is not a divergent technical standard but an operational testing methodology. RGAA version 4.1.2 breaks down verification into 106 control criteria backed by 253 granular testing procedures. However, RGAA 4.1.2 remains structurally pinned to WCAG 2.1 AA. While it delivers thorough verification within that legacy perimeter, it leaves a significant gap against modern European market surveillance requirements that mandate alignment with WCAG 2.2.

2. Comparative Matrix: RGAA 4.1.2 vs. WCAG 2.2 vs. EN 301 549

To execute audits without structural blind spots, compliance teams must assess the granularity, governing bodies, and enforcement perimeters of each standard. Administrative fines under national transpositions of the EAA (which reach up to 100,000 euros via the DGCCRF in France, 500,000 euros via market surveillance authorities in Germany under the BFSG, or periodic penalty payments of up to 5% of global turnover) leave no room for imprecise auditing.

This comparison reveals a strategic operational fault line: while RGAA delivers a remarkably prescriptive verification rubric (its unit tests define exact DOM queries and screen reader pairings), it lacks alignment with the 9 new evaluation criteria introduced in WCAG 2.2. These updated criteria form the core baseline for cross-border enforcement across EU surveillance bodies. For a detailed risk profile of non-compliance, review our analysis on regulatory sanctions and fines under the EAA.

3. The WCAG 2.2 Delta: 9 Missing Criteria in RGAA 4.1.2

To convert an RGAA declaration into a defensible European compliance file under EN 301 549, organizations must resolve the delta created by WCAG 2.2. This update removed Criterion 4.1.1 (Parsing, rendered obsolete by modern browser parsing algorithms) and added nine new success criteria, six of which apply directly to Level AA compliance under the scope of the EAA:

• 2.4.11 Focus Not Obscured (Minimum) (AA): During keyboard navigation, the focused interactive component must not be entirely hidden by author-created content, such as persistent sticky cookie banners, misconfigured modal overlays, or fixed customer support headers.
• 2.4.12 Focus Not Obscured (Enhanced) (AAA): No portion of the focused UI component may be obscured (Level AAA requirement; not mandatory under the EAA baseline, but critical for enterprise core user journeys).
• 2.4.13 Focus Appearance (AAA): Enforces strict contrast ratios (at least 3:1) and minimum boundary thicknesses (at least 2 CSS pixels) for visual focus rings.
• 2.5.7 Dragging Movements (AA): Any feature relying on dragging interactions (such as reordering list items on a dashboard or operating a CMP consent slider) must offer a single-pointer alternative like tapping, clicking, or keyboard inputs.
• 2.5.8 Target Size (Minimum) (AA): Interactive pointer targets must measure at least 24x24 CSS pixels, or provide sufficient spacing to adjoining targets to prevent misclicks. This criterion is frequently violated during an accessibility audit of commercial CMPs where close buttons, toggle checkboxes, and secondary link triggers are undersized.
• 3.2.6 Consistent Help (A): When self-help or support mechanisms (contact forms, live chat, chatbots, FAQs) appear across multiple pages within a set, they must maintain a consistent relative order within the DOM and visual presentation.
• 3.3.7 Redundant Entry (A): Information previously entered by the user in a multi-step flow (e.g., checkout funnels, registration wizards) must be auto-populated or available for selection, unless re-entry is essential for fraud prevention or identity verification.
• 3.3.8 Accessible Authentication (Minimum) (AA): Cognitive function tests (such as memorizing complex passwords, solving math puzzles, or transcribing visual CAPTCHAs) cannot be mandatory for authentication without offering accessible alternatives, such as password manager autofill support, copy-paste token entry, or WebAuthn / Passkeys.
• 3.3.9 Accessible Authentication (Enhanced) (AAA): Removes exceptions for object recognition or personal image selection allowed under 3.3.8.

An audit program executed strictly against RGAA 4.1.2 will miss non-compliant authentication journeys relying on proprietary visual puzzles (3.3.8) and mobile pagination buttons that fall below the 24-pixel requirement (2.5.8).

4. Hybrid Audit Methodology and CI/CD Automation (Playwright +

To secure dual compliance across RGAA 4.1.2 (for French local operations) and EN 301 549 / WCAG 2.2 AA (for pan-European and cross-border operations), the CookieDetox Compliance Lab implements a three-tier audit protocol: stratified representative sampling, automated CI/CD assertion suites, and assistive technology user validation.

The audit sample must encompass standard legal and corporate pages (homepage, privacy policy, terms of service, accessibility statement) alongside every step in the primary transaction funnels: CMP consent prompts, authentication and password recovery portals, product configuration flows, checkout steps, and transactional forms. Dynamically mounted overlays (modals, sliding consent drawers, push notification prompts) must be evaluated across all discrete DOM visibility states.

Within modern continuous integration pipelines, Axe-core (v4.9+) enables automated regression testing for programmatic WCAG 2.2 criteria, specifically target sizing and focus overlap. Below is a production-ready Playwright implementation designed to detect target-size violations and CMP-induced focus occlusion:

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

test.describe('EN 301 549 & WCAG 2.2 Compliance Verification', () => {
  test('Automated verification of target sizes and focus visibility', async ({ page }) => {
    await page.goto('https://platform.enterprise.tld/', { waitUntil: 'networkidle' });

    // Inject and execute targeted Axe-core suite covering WCAG 2.2 AA rules
    const axeResults = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
      .include('body')
      .exclude('#analytics-debug-iframe')
      .analyze();

    // Isolate blocking violations for EAA 2026 enforcement
    const severeViolations = axeResults.violations.filter(v => 
      v.impact === 'critical' || v.impact === 'serious'
    );

    expect(severeViolations).toEqual([]);

    // Specific WCAG 2.2 assertion (2.4.11 Focus Not Obscured) across modal / CMP boundaries
    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();
      // Inspect element at focal midpoint to ensure high-index modals or banners do not overlap
      const topEl = document.elementFromPoint(rect.left + rect.width / 2, rect.top + rect.height / 2);
      return topEl !== el && !el.contains(topEl);
    });

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

Automated static and runtime checks capture approximately 35% to 45% of total accessibility barriers. Formal certification requires manual evaluation across standardized assistive environments: NVDA (latest stable release) on Mozilla Firefox on Windows 11, and VoiceOver on Safari on macOS and iOS. Conformity rates must be documented using the standardized RGAA calculation formula (Conforming Criteria / Applicable Criteria × 100), complemented by an EN 301 549 V3.2.1 Annex A mapping table for multinational disclosures.