A new version of the RGAA, RGAA 5, is planned for the end of 2026. It integrates WCAG 2.2, extends accessibility to mobile applications and office documents, names Arcom as the supervisory authority and creates an online declaration service. Here's what changes, and what to do right now.
RGAA vs EAA: don't mix them up
A quick reminder to set the scene, because two texts coexist.
The RGAA (Référentiel Général d'Amélioration de l'Accessibilité) is the French method for evaluating digital accessibility. It applies to the public sector and large companies, and technically it builds on the WCAG. The version in force remains 4.1.2.
The European Accessibility Act (EAA) is the European law that has made accessibility mandatory for many private-sector digital services since June 28, 2025 (e-commerce, banking, transport). Both aim at the same goal and the same technical foundation, but they don't cover exactly the same scope.
RGAA 5 is the expected evolution of the French method, announced for the end of 2026.
Takeaway: RGAA 5 doesn't cancel the work already underway. Version 4.1.2 remains the reference today, and any ongoing audit or action plan keeps its value. The right strategy isn't to wait, it's to move forward.
The 5 major changes in RGAA 5
| Change | What it means |
|---|---|
| WCAG 2.2 integration | New technical criteria (focus, target size, authentication) |
| New scopes | Mobile applications and office documents enter the framework |
| Simplified criteria | Reworded for simpler, more reproducible audits |
| Arcom as supervisory authority | A clarified oversight and penalty regime |
| Online declaration service | Submit and publish accessibility declarations online |
For a developer, the most concrete change is the first one: moving from WCAG 2.1 to WCAG 2.2.
WCAG 2.2: the new criteria to know
WCAG 2.2 adds nine success criteria over version 2.1, and makes criterion 4.1.1 (Parsing) obsolete. Here are the ones that matter at level AA, the level required by law.
| Criterion | Level | Purpose |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Focus must not be hidden by a fixed element |
| 2.5.7 Dragging Movements | AA | Any drag action must have a simple alternative |
| 2.5.8 Target Size (Minimum) | AA | Targets at least 24 by 24 CSS pixels |
| 3.2.6 Consistent Help | A | Help in the same place from one page to the next |
| 3.3.7 Redundant Entry | A | Don't re-ask for information already provided |
| 3.3.8 Accessible Authentication | AA | No mandatory cognitive test to log in |
Minimum target size (2.5.8)
A touch button or link that's too small is unusable for someone with motor impairments. WCAG 2.2 sets a minimum size of 24 by 24 CSS pixels.
.btn, .icon-link {
min-width: 24px;
min-height: 24px;
}
/* Otherwise, provide enough spacing around the target */
Accessible authentication (3.3.8)
This criterion forbids imposing a cognitive test (retyping a code, solving a puzzle) as the only way to log in. In practice: allow pasting into password fields, let password managers work, and favor passkeys.
<!-- Never block pasting: it's an accessibility barrier -->
<input type="password" name="password" autocomplete="current-password">
<!-- Avoid: onpaste="return false" -->
Focus not obscured (2.4.11)
With a sticky header (position: sticky), the element receiving keyboard focus can end up hidden behind the bar. The fix is one line of CSS.
:target, :focus {
scroll-margin-top: 6rem; /* height of the fixed header */
}
The transitional regime to plan for
RGAA 5 provides for a soft transition. Accessibility declarations published before its release stay valid for 18 months, within the limit of 3 years from their initial publication date. In other words: what you produce today under RGAA 4.1.2 isn't wasted, it remains valid throughout the transition.
Takeaway: don't postpone anything while waiting for RGAA 5. Keep running your audits in 4.1.2, and start integrating the simplest WCAG 2.2 criteria now (target size, focus, authentication). You'll be ready without redoing anything.
What to do right now
- Keep running audits and compliance work under RGAA 4.1.2
- Integrate the WCAG 2.2 criteria you can apply immediately (24px targets, focus not obscured, accessible authentication)
- Never block pasting or password managers
- Plan for the wider scope: think accessibility for mobile apps and office documents (PDF, Word)
- Keep your accessibility declaration up to date, ready for the future online service
- Test with the keyboard and a screen reader, as always
Going further
For the fundamentals (WCAG principles, common mistakes, testing method), see: Web accessibility, the developer's practical guide. On the store side, concrete compliance is detailed here: WordPress and WooCommerce accessibility.
Do you need to prepare your site or app for RGAA or EAA compliance? Let's talk.