What RGAA owes to accessibility, and what it does not cover

Being RGAA compliant and being genuinely accessible to all users are not strictly the same thing, and confusing the two leads to successful audits on services that are still hard to use.

What RGAA guarantees

A framework of verifiable technical criteria, covering a large share of the obstacles faced by users of assistive technologies. It is a solid foundation and a necessary legal framework (see the RGAA obligations for private companies in 2026).

In practical terms, the version in force, RGAA 4.1.2, has 106 criteria spread across 13 themes, from images to consultation. Its method checks the 50 success criteria of WCAG 2.1 levels A and AA, the ones that the European standard EN 301 549 uses to define the legal level of requirement.

RGAA, WCAG, EN 301 549: who covers what

The three acronyms cross paths in every set of specifications, without playing the same role.

Framework	What it is	What it provides	What it does not say
WCAG 2.1 and 2.2	International W3C recommendation	The success criteria, from level A to level AAA	How to test them step by step, or what is mandatory in France
EN 301 549	Harmonised European standard	The legal level adopted (WCAG 2.1 A and AA), extended to software and documents	An operational test method in French
RGAA 4.1.2	French framework	106 criteria and reproducible tests, an accessibility statement in a mandatory format	What WCAG 2.2 adds, or a user's real experience

RGAA is therefore the French operational translation of a European standard, itself based on an international recommendation. It adds no requirements; it makes them testable.

What it does not always cover

• The cognitive complexity of a user journey, even when technically compliant
• The real experience of use with a variety of assistive technologies, beyond standard tests
• Mobile use or degraded usage contexts (weak connection, brightness, fatigue)

Cognitive accessibility: what the framework measures poorly

This is the most visible limitation. A form can meet every RGAA criterion and still be exhausting to fill in: administrative vocabulary, information requested twice, a captcha to copy out. WCAG 2.2, which became a W3C recommendation on 5 October 2023, started to address this point with two new criteria: 3.3.7 "Redundant Entry" (level A), which forbids asking again for information already provided in the same session, and 3.3.8 "Accessible Authentication" (level AA), which forbids requiring a cognitive test, such as memorising or transcribing a code, in order to log in.

Neither appears in RGAA 4.1.2, which is based on WCAG 2.1. Plain language, easy-to-read content (FALC, the French "facile à lire et à comprendre" method) and the mental load of a journey remain outside the scope of verifiable criteria. These are precisely the points that only testing with users brings to light.

The right stance

Treat RGAA compliance as a floor, not a ceiling. User testing with real users of assistive technologies often reveals friction that no compliance audit detects.

Why an automated audit alone is never enough

This limitation is not an opinion; it is documented in the framework's own method: automated tools cannot correctly assess reading order, the relevance of labels, real keyboard use, the understanding of error messages, or actual compatibility with assistive technologies, as the official RGAA method points out. That is why a serious audit combines three levels: automated tests for volume, human expertise for the criteria that require judgement (keyboard navigation, semantics, forms), and user testing for high-stakes journeys.

Organising tests with real users

An accessibility user test does not need a laboratory. It needs three things: the right participants, the right journeys, and an observer who stays quiet.

• Recruit people who use their own assistive technologies every day (screen reader, magnifier, voice control, keyboard-only navigation), on their own equipment. A tester discovering a screen reader for the occasion only measures their own learning curve.
• Choose two or three high-stakes journeys, the ones that determine access to the service: creating an account, paying, submitting a request, finding a contact.
• Observe without guiding, note every hesitation and every workaround, then ask at the end what took the most effort.

A few sessions are often enough to surface the major blockers. It is not a statistical measurement, it is a revealer, and that is exactly what a compliance audit lacks.

Which solution to become RGAA compliant

A serious compliance solution combines the three levels described above, and no product replaces them all. Accessibility overlays, those scripts added to a page to offer a settings menu, do not fix the source code. At best, they try to patch certain defects at display time, with no guarantee of results: a missing field label, an inconsistent heading hierarchy or a vague link text remain in the code. Compliance is judged on the service as it is coded and rendered.

What I recommend, in order: a scope diagnostic to find out which obligations apply, tool-assisted checks on the most frequent issues, an audit on a representative sample of pages, then a prioritised remediation plan and user testing on critical journeys. For the first checks, the site's free tools cover the most widespread defects: an RGAA contrast checker and a heading hierarchy checker. To go further without an in-house expert, I have written a guide to testing your site's accessibility.

Version 5 of RGAA, currently being drafted for publication at the end of 2026, will incorporate what WCAG 2.2 adds, including focus visibility and touch target size. You can already check keyboard focus visibility on your pages. These additions will raise the regulatory floor, but will never remove the need for testing with real users on the journeys that matter most. The official RGAA website makes this clear: accessibility work must not be postponed while waiting for this new version.

An RGAA compliant service is not automatically an accessible service. It is an excellent starting point, never an end point.

It is this distinction between floor and ceiling that I set out from the scoping stage of an RGAA audit.

Further reading: accessibility and generative AI: a partnership still poorly negotiated

Frequently asked questions

What is the difference between RGAA and WCAG?

WCAG is the international W3C recommendation. RGAA 4.1.2 is its French adaptation: it takes the WCAG 2.1 level A and AA criteria, adopted by the European standard EN 301 549, and pairs them with reproducible tests.

Is an RGAA compliant site necessarily accessible?

No. RGAA covers verifiable technical obstacles, but measures poorly the cognitive load of a journey or the real experience with a variety of assistive technologies. Only testing with users reveals this friction.

Is an accessibility overlay enough to be RGAA compliant?

No. An overlay does not fix the source code: a missing label, an inconsistent heading hierarchy or a vague link text remain non-conformities, with or without a settings menu.

When will RGAA 5 be released?

DINUM (the French government's interministerial digital directorate) announces publication at the end of 2026, incorporating WCAG 2.2 and criteria for mobile applications and office documents. In the meantime, RGAA 4.1.2 remains the reference and compliance work must not be put on hold.