RGAA 5: get compliant before the new version is released

On September 24, 2026, at Paris Web, Aurélien Levy (Temesis) and Stéphanie Nazarian (DINUM) presented the future RGAA 5. We were there. The figure that made the room react: the framework goes from 106 to about 146 criteria. According to Aurélien Levy, only 6 to 10 topics are truly new and high-impact, and a third of them directly concern code.

You can start on those right now.

What RGAA 5 changes in your code

#Why start before RGAA 5 is published?

Most of RGAA 5 already exists. Two thirds to three quarters of the new criteria come from WCAG 2.2 (Web Content Accessibility Guidelines, the W3C's international rules) and from the European standard EN 301 549. These texts are published, stable and readable today, even before the RGAA 5 beta version.

Going from 106 to about 146 criteria is about 38% more. Nearly four extra criteria for every ten existing ones.

Texts that are already fixed. WCAG 2.2 has been a W3C recommendation since October 5, 2023. EN 301 549 V4.1.1, published on September 2, 2026, integrates it in turn. RGAA 5 (Référentiel Général d'Amélioration de l'Accessibilité, the French general accessibility improvement framework) will take up these requirements in another form, without reinventing them.

The official guidance. DINUM (the French interministerial digital directorate) wrote it in black and white in its announcement of March 4, 2026: work on RGAA 4.1.2 must not be suspended or postponed (declarations established on RGAA 4.1.2 remain valid for 18 months after RGAA 5 is released), and the RGAA 5 criteria will clarify or complete those of RGAA 4 without contradicting them.

Waiting saves no time. Every component shipped today without these requirements in mind will need rework in 2027.

RGAA 5: how to prepare the transition without paying twice

#Six WCAG 2.2 criteria to check in your code

WCAG 2.2 added nine criteria, six of them at level A or AA. Those six are the ones that enter RGAA 5, which covers levels A and AA only. Here is what each one asks of your code.

#2.4.11 Focus Not Obscured (Minimum)

What the W3C says. When a component receives keyboard focus, it must not be entirely hidden by content added by the author. The provisional RGAA 5 wording requires that every component receiving focus remains at least partially visible.

The typical case. An 80 px sticky header. The user goes back up with Shift+Tab, the browser scrolls just enough to reveal the focused link, and the link ends up under the header. The W3C describes this case as failure F110. A cookie banner stuck to the bottom of the screen produces the same effect in the other direction.

The fix takes two lines of CSS, documented by the W3C in technique C43:

/* Before: the sticky header covers the focused element */
.site-header { position: sticky; top: 0; height: 5rem; }
 
/* After: scrolling reserves room for the sticky header and footer */
html {
  scroll-padding-top: 6rem;
  scroll-padding-bottom: 5rem;
}

The test. Tab down to the footer, then go back up with Shift+Tab. If a focused element disappears completely, even for a second, the component fails.

#2.5.7 Dragging Movements

What the W3C says. Any function that uses a dragging movement can be performed with a single pointer, without dragging, unless dragging is essential.

The typical case. A kanban board where cards move only by dragging them. It is the textbook example of failure F108. For a person with tremors, holding the mouse button down for the whole trip is a real obstacle.

The criterion is about pointers: it requires a single-click alternative, even when the keyboard works.

<!-- Before: the card moves only by drag and drop -->
<li draggable="true">Write the FAQ</li>
 
<!-- After: dragging stays, single clicks work too -->
<li draggable="true">
  Write the FAQ
  <label>
    Move to
    <select name="column">
      <option>To do</option>
      <option selected>In progress</option>
      <option>Done</option>
    </select>
  </label>
</li>

For a slider, a click on the track or a number field next to it does the job. A native <input type="range"> already accepts a click on the track.

The test. Perform every drag action on the page using single clicks only.

#2.5.8 Target Size (Minimum)

What the W3C says. A clickable target measures at least 24 × 24 CSS pixels, with exceptions: sufficient spacing, an equivalent control elsewhere, a link within a sentence, a native browser control, an essential size.

What to understand. The clickable area is what counts. Example: carousel dots of 2 × 2 px remain acceptable if their click area is large enough. A 16 px icon button with no margin fails, even when it is perfectly legible.

/* Before: 16 × 16 px clickable area */
.icon-button { width: 16px; height: 16px; padding: 0; }
 
/* After: the icon keeps its size, the click area grows to 24 px */
.icon-button {
  min-width: 24px;
  min-height: 24px;
  display: inline-grid;
  place-items: center;
}
 
/* Carousel dot: small visible dot, large click area */
.carousel-dot {
  box-sizing: border-box;
  width: 24px;
  height: 24px;
  padding: 8px; /* 8 px visible dot, 24 px click area */
  border-radius: 50%;
  background-clip: content-box;
}

For important controls (closing a modal, confirming a payment), aim for 44 px, the value of level AAA criterion 2.5.5.

The test. Measure the element's clickable area in the browser inspector.

#3.2.6 Consistent Help

What the W3C says. If a help mechanism repeats across several pages (contact details, contact form, chat, FAQ), it appears in the same order relative to the rest of the content. The W3C talks about relative order in the code.

The trap. The "Contact us" link in the header on the homepage, at the bottom of the page on product pages, and missing from the checkout flow. This kind of gap arises when each page places help by hand.

// Before: each page adds its own help link, wherever it likes
// After: a single template component, shared by all pages
export function Layout({ children }) {
  return (
    <>
      <Header />
      <main>{children}</main>
      <footer>
        <HelpLinks /> {/* contact, FAQ, chat: always here, in this order */}
      </footer>
    </>
  );
}

The test. Open five different templates and compare the order of the help elements.

#3.3.7 Redundant Entry

What the W3C says. Information already provided in the same process is pre-filled or offered for selection, unless re-entering it is essential, serves security, or the information is no longer valid. The W3C specifies that browser autocomplete remains insufficient.

The typical case. The checkout flow that asks for the billing address again, two screens after the delivery address.

<!-- Before: the customer retypes their address -->
<fieldset>
  <legend>Billing address</legend>
  <input name="billing-street" autocomplete="billing street-address">
</fieldset>
 
<!-- After: a checkbox, checked by default, reuses the delivery address -->
<label>
  <input type="checkbox" name="same-address" checked>
  Billing address same as delivery address
</label>
<fieldset id="billing" hidden>
  <legend>Billing address</legend>
  <input name="billing-street" autocomplete="billing street-address">
</fieldset>

// The billing fields appear only when the checkbox is unchecked
const same = document.querySelector('[name="same-address"]');
same.addEventListener('change', () => {
  document.getElementById('billing').hidden = same.checked;
});

On the server side, if the checkbox is checked, reuse the delivery address already saved.

The test. Go through every multi-step form and note any information requested twice.

#3.3.8 Accessible Authentication (Minimum)

What the W3C says. No login step relies on a cognitive function test (memorizing, transcribing, solving a puzzle), unless an alternative or help exists: password manager, copy-paste, object recognition, personal content.

A new CAPTCHA theme. In RGAA 5, this criterion opens a dedicated theme on CAPTCHAs (tests to tell a human from a robot). A CAPTCHA remains possible if an alternative exists. Example: service-public.fr displays a CAPTCHA at login and also offers FranceConnect, which lets you log in without taking the test.

The most common trap. Blocking paste in the password field, or splitting a six-digit code into six fields that refuse paste. The W3C describes both in failure F109.

<!-- Before: paste blocked, password manager ignored -->
<input type="password" autocomplete="off" onpaste="return false">
 
<!-- After: the manager fills in, paste works -->
<input type="password" name="password" autocomplete="current-password">
 
<!-- One-time code: a single field, autofill possible -->
<input type="text" name="otp" autocomplete="one-time-code"
       inputmode="numeric" maxlength="6" pattern="\d{6}">
 
<!-- Passkeys offered right from the username field -->
<input type="text" name="username" autocomplete="username webauthn">

The current-password, one-time-code and webauthn tokens are documented on MDN. For passkeys, the MDN passkeys guide shows the matching JavaScript call.

The test. Log in with a password manager, then by pasting each value by hand.

#Three European requirements to add to your list

EN 301 549 contains the WCAG and other requirements. Some were absent from RGAA 4, such as authoring tools or real-time communication. The Luxembourg framework RAWeb 1.1 (web accessibility evaluation framework) already covers them with 136 criteria, and RGAA 5 draws inspiration from it. Three requirements are detailed below.

#Media controls (EN 301 549, requirement 7.3)

When a video player offers captions or audio description, their controls are as accessible as the main controls, play and pause. They appear next to Play.

<!-- After: captions and audio description on the same level as Play -->
<div class="player-controls">
  <button type="button">Play</button>
  <button type="button" aria-pressed="false">Captions</button>
  <button type="button" aria-pressed="false">Audio description</button>
</div>

A counter-example: a large online video player where you must open three submenus to turn on captions.

#User preferences (EN 301 549, requirement 11.7)

The interface respects system and browser settings: light text on a dark background, enlarged font size. The European Commission classes this requirement among those that do not come from the WCAG, and V4.1.1 asks websites and documents to better respect these preferences, with a new clause 9.7 for web pages. The working group is still discussing the scope, since testing every combination of settings would be unmanageable.

The standard prescribes no technique. On the CSS side, three habits go in its direction:

/* Before: the size chosen in the browser is overridden */
html { font-size: 14px; }
 
/* After: the user's preference serves as the base */
html { font-size: 100%; }
body { font-size: 1rem; }
 
@media (prefers-color-scheme: dark) {
  :root { --bg: #111; --text: #eee; }
}
 
@media (forced-colors: active) {
  .button { border: 1px solid ButtonText; }
}

#Biometrics (EN 301 549, requirement 5.3)

Any identification by a biological characteristic, Face ID or fingerprint, comes with an alternative method. Example: the login screen of a banking app that offers Face ID and a classic password. A person whose face or fingers are not recognized is never locked out.

#What changes in the auditor's grid

The audit method evolves in form, and the calculation of the rate stays the same in 5.0.

Criteria in the affirmative. Criteria drop the question form and become a good practice to follow. The tests stay phrased as questions. Example on the text alternative of images:

Your images don't need alternative text

A multi-platform framework. Each test may have a mobile or office-document variant, modeled on the Luxembourg frameworks (RAWeb for the web, RAAM for mobile apps, RAPDF for PDFs). Example for data tables: on the web, you check for th tags; on mobile, you check what the screen reader announces.

An unchanged compliance rate. The calculation method stays the same in version 5.0. Your tracking sheets do not need a new formula. The future declaration template will add blocking issues, the defects that prevent completing a task. With a single blocking issue, a service should remain non-compliant, even above a 50% compliance rate. The detail is in our article RGAA 5: how to prepare the transition without paying twice.

Free alt text generator: the right alt for each image, based on its role

#Check your pages today, template by template

Nearly everything above is checked by hand. Target size is the only one partly detectable automatically, and even there, the W3C exceptions call for a human check. axe-core, the most widely used test engine, has only one WCAG 2.2 rule, target-size, and its documentation states that it is disabled by default.

Work template by template: a defect in the header component repeats across the whole site, and gets fixed once.

1. Tab down then up on every template that has a sticky header, footer or banner.
2. Measure the clickable area of icon buttons, dots and tight links in the inspector.
3. Redo every drag action using single clicks only.
4. Compare the order of help links across five different templates.
5. Go through every multi-step form and note any information requested twice.
6. Log in with a password manager, then by pasting the password and the code.
7. Verify that the captions and audio description buttons are visible next to Play.
8. Switch the system to dark mode and high contrast, enlarge the browser text, then review the page.

For the automatable part, the Includdy tool scans a page or a component at a time in a few seconds and pairs a fix guide with each detected error. It handles what a machine can see and frees up your time for the manual tests in the list above.

RGAA 5 will check what you can already ship.

EAA and web accessibility: what changes for your business in 2026

To spot the detectable errors on your pages before moving on to manual tests, try Includdy.

Frequently asked questions