Over the years working as a web accessibility expert, certified in both WCAG and RGAA, I’ve learned that these two standards are like two different languages describing the same idea: inclusion. Both want to make the web accessible for everyone. But the way how they do it, and what it feels like to actually work with them day after day, can be very different.

When I started auditing websites for compliance, I thought “RGAA and WCAG are basically the same, one just translated into French.” That illusion disappeared quickly after my first few RGAA audits.

Two standards, two realities

WCAG¹ (Web Content Accessibility Guidelines) is an international standard created by the W3C — the “umbrella” under which most accessibility laws around the world are written. It defines what needs to be accessible, using 78 success criteria across the four principles: Perceivable, Operable, Understandable, Robust.

RGAA² (Référentiel Général d’Amélioration de l’Accessibilité), on the other hand, is the French accessibility standard — a legal requirement for public sector sites, and a strong reference for private companies. It builds on WCAG but adds an incredible amount of precision: clear test methods, expected results, and examples.

That’s the first big difference: WCAG tells you what to do, RGAA tells you exactly how to test it.

Difference in testing

In my WCAG projects, testing often feels open and interpretative. You need to understand user impact deeply, like screen reader behavior, browser differences, edge cases and apply judgment. Two auditors can test the same website and have slightly different results depending on how they interpret each criterion.

With RGAA, there is no such freedom. Each criterion is a prescriptive test: it literally says what to check, how to check it, and what outcome should be considered compliant. You can’t skip a step; you can’t “interpret” the rule.
It’s structured, systematic, and sometimes exhausting, but also fairer, because it minimizes ambiguity between auditors.

Concrete examples & exceptions

This is where I learned to love RGAA. While WCAG can feel abstract and sometimes even philosophical, RGAA lives in the real world.
It provides examples, exceptions, and even guidance for tricky cases:

• What to do with icon-only links
• How to treat hidden content
• How to structure form field groups

When you work on dozens of websites, those details matter.
They save time and prevent endless debates between designers, developers, and auditors.

Technical details

Here’s a table that can help you understand how WCAG and RGAA compare from both a technical and practical point of view:

Area	WCAG 2.1	RGAA 4.1	Expert Insights (from practice)
Structure	13 guidelines, 78 success criteria organised by four principles (Perceivable, Operable, Understandable, Robust).	13 thematic groups and 106 detailed test criteria, each mapped to WCAG references.	RGAA builds directly on WCAG but translates abstract principles into measurable tests — it’s both a guideline and a test protocol.
Test methodology	WCAG doesn’t define a test process — it tells what to achieve, not how to test.	Each RGAA criterion includes a prescriptive step-by-step testing method: what to check, tools to use, and expected result.	WCAG gives flexibility and depends heavily on the auditor’s expertise. RGAA removes ambiguity — which is great for consistency but demanding for large audits.
Examples & exceptions	None — WCAG is intentionally abstract and technology-agnostic.	Each RGAA test includes practical examples and exceptions (e.g. how to handle hidden content, icons, and grouped inputs).	RGAA’s examples are lifesavers in real projects — they help resolve developer–auditor discussions and accelerate remediation.
Language & localisation	English-based, no language-specific rules.	Includes French-specific checks: correct lang attributes, punctuation spacing, date/time format, and even spelling rules.	WCAG is global; RGAA is adapted to French linguistic conventions — important for legal compliance and content accessibility.
Legal & documentation obligations	Conformance statements are optional (recommended but not enforced).	Legal obligation under Article 47 of the Loi Handicap: mandatory accessibility declaration, feedback form, and improvement plan.	This is where RGAA differs most — it’s not optional. Accessibility statements and transparency are enforceable by law.
Non-text content	SC 1.1.1: Provide text alternatives for non-text content.	Extends requirements: clearer distinction between decorative/informative images, detailed rules for CAPTCHAs, icons, charts.	RGAA forces you to document decisions — e.g., why an image is decorative — ensuring thorough and consistent results.
Forms & interactivity	SC 3.3.x covers input assistance in general terms.	Adds explicit checks for grouping related fields, marking required inputs, and managing error messages.	RGAA is more developer-oriented here — form validation and feedback get detailed rules that WCAG leaves open.
Media (audio/video)	SC 1.2.x defines requirements for captions, transcripts, and audio descriptions.	Adds specific guidance based on French standards (e.g. subtitling practices, descriptive transcript quality).	WCAG sets the baseline; RGAA enforces national subtitling and translation conventions.
PDF & Office documents	Not covered — WCAG focuses on web content only.	Includes downloadable document accessibility: PDFs, Word, ODT, EPUB.	This is a major difference — under RGAA, a single non-accessible PDF can make your page non-compliant.
Testing environment	Flexible — auditor chooses tools and assistive technologies.	Defines expected combinations (e.g., Firefox + NVDA, Chrome + JAWS) to ensure reproducibility.	RGAA promotes testing reproducibility, but this rigidity can exclude newer tools or assistive tech.
Updates & evolution	Maintained by W3C — version 2.2 released in 2023; 3.0 (Silver) in progress.	Updated by the French government (DINUM); slower update cycle tied to legal adaptation.	WCAG evolves faster technically; RGAA focuses on stability and legal traceability.
Scope	Applicable globally — forms the legal base for EAA, ADA, AODA, etc.	National standard required for public sector and recommended for private French websites.	For international organisations, WCAG remains the reference; RGAA applies when France is in your target audience.
Learning curve	Conceptual — requires deep understanding of accessibility logic.	Procedural — easier for beginners, but can be overwhelming in detail.	WCAG trains your judgment; RGAA trains your precision. A balanced team needs both mindsets.

My takeaways from auditing under both standards

After years of working under both RGAA and WCAG, here’s what I’ve learned:

• RGAA is stricter and more detailed. It gives you a clear testing path but can feel heavy in large audits.
• WCAG is more flexible and universal. It gives you freedom to adapt to technology but demands strong expertise and interpretation skills.
• RGAA is ideal for governance and traceability. Every test can be documented and justified, which helps when you need formal compliance reports.
• WCAG is ideal for international scalability. It’s the “language” used everywhere – from the US ADA to the European Accessibility Act.
• In practice, you need both. RGAA builds on WCAG. Meeting RGAA generally means you already align with WCAG 2.1 AA, but not the other way around.

My perspective on when to use RGAA and WCAG

In my experience, RGAA and WCAG serve different mindsets, not just different countries.

• If you want to meet global accessibility standards — WCAG 2.1 or 2.2 AA is the universal reference. It’s the foundation behind the European Accessibility Act, Section 508 in the US, and most international policies.
• If you aim for excellence, traceability, and measurable results, RGAA is an incredible framework — even outside France.
  It offers a rigorous methodology, prescriptive testing steps, and concrete evaluation criteria that make accessibility less subjective and more verifiable.
• If your goal is to scale accessibility across teams, RGAA is particularly powerful.
  Developers, QA testers, and designers can use it as a shared testing language, something WCAG alone often lacks due to its abstract nature.
• And if you want transparency and accountability, RGAA’s legal requirement for an accessibility statement and feedback form creates a healthy culture of openness, where accessibility progress is publicly traceable.

WCAG and RGAA are not competitors, they are two sides of the same mission: to make digital spaces accessible to everyone. But while WCAG gives us the vision, RGAA gives us the process. For me, working with both standards made accessibility feel less like a set of rules and more like a craft – something that blends empathy, precision, and cultural awareness.

1. WCAG guidelines official website https://www.w3.org/WAI/standards-guidelines/wcag/ ↩︎
2. RGAA Référentiel général d’amélioration de l’accessibilité official website https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/ ↩︎