WCAG 2.2, EN 301 549, RGAA, RAWeb: which digital accessibility standards apply to you?

Every digital accessibility obligation in Europe rests on the same technical foundation: the W3C’s Web Content Accessibility Guidelines (WCAG). Yet the digital accessibility standard that carries legal weight is not the same for a French town hall, a Luxembourg ministry, a Belgian public body or a Swiss software publisher selling into the European Union: it may be RGAA, RAWeb, EN 301 549 or eCH-0059. This analysis, up to date as of 27 October 2026, sets out what each of these digital accessibility standards contains, what changes with version 4.1.1 of EN 301 549 published in September, and how to choose when you operate in several countries.

The short answer: one common foundation, several national versions

WCAG define what accessible web content is. The European standard EN 301 549 adopts them and extends them to the whole of the digital world: documents, software, mobile apps, hardware and communication services. National frameworks, such as RGAA in France or RAWeb in Luxembourg, turn these requirements into precise criteria and tests, with an assessment method and a link to a specific law.

The differences between these texts therefore have less to do with substance than with three elements: the version of WCAG they reference, the scope they cover and the method they require for measuring compliance. A website that meets WCAG 2.1 at level AA is already close to compliance in all four countries. It is not yet compliant in the legal sense, however, until it has been assessed against the applicable framework and the required documents, such as the accessibility statement, have been published.

To find your bearings quickly, here is the framework that applies to the most common situations at the date of this article:

• a French public body, or a company subject to article 47 of the law of 11 February 2005: RGAA 4.1.2, pending RGAA 5, announced for the end of 2026;
• a Luxembourg public body: RAWeb 1.1 for the web, RAAM 1.1 for mobile apps and RAPDF 1.1 for PDF documents;
• a Belgian public body: the EN 301 549 standard, which means WCAG 2.1 level AA for the web;
• the Swiss federal administration: the eCH-0059 standard, version 3.0, which refers to WCAG 2.1 level AA;
• a business covered by the European Accessibility Act, in any Member State: the requirements of the directive, for which EN 301 549 is the technical reference.

WCAG: how the reference digital accessibility standard is built

The Web Content Accessibility Guidelines are published by the World Wide Web Consortium (W3C), through its Web Accessibility Initiative (WAI). They are not legislation but technical recommendations, to which laws and standards refer. Since September 2025, version 2.2 has also been an international standard: ISO published the second edition of ISO/IEC 40500, which adopts WCAG 2.2.

Four principles, thirteen guidelines, testable success criteria

WCAG are organised around four principles. Content must be perceivable: information conveyed by an image, a sound or a colour must also exist in a form that everyone can perceive, for example text that a screen reader can read aloud. It must be operable: anything that can be done with a mouse must also be possible with a keyboard, without time limits that cannot reasonably be met. It must be understandable: the language is declared, behaviour is predictable and error messages are explicit. Finally, it must be robust: the code must allow assistive technologies to identify the name, role and state of each component.

These principles are broken down into 13 guidelines, such as “Keyboard Accessible” or “Input Assistance”. Each guideline in turn is split into success criteria, worded so that they can be verified: on a given page, a criterion is either met or not met. Version 2.2 contains 86 active success criteria. It is at this level, the level of the criteria, that auditors work and that national frameworks take over the requirements.

Three conformance levels: A, AA and AAA

Each criterion belongs to a level. Level A covers the requirements without which some people simply cannot access the content: a video with no captions, a button that cannot be used with a keyboard. Level AA adds requirements that remove significant difficulties, such as sufficient text contrast or a visible focus indicator. Level AAA brings together the most demanding requirements, which are often impossible to guarantee across an entire website, such as sign language for every video.

Conforming at level AA means meeting all level A criteria and all level AA criteria. This is the level adopted by EN 301 549 and, through it, by European regulation. Conformance is assessed page by page, but also across complete processes: if one step of a checkout or an online application process does not conform, none of the pages in that process can be declared conformant.

Versions 2.0, 2.1 and 2.2: three mutually compatible versions

Each new version of WCAG 2 adds criteria without calling the previous ones into question. The W3C states that WCAG 2.2 builds on WCAG 2.1 and remains compatible with it: content that conforms to WCAG 2.2 also conforms to the earlier versions, with one exception, described below.

The nine criteria added in WCAG 2.2, and the one that disappears

The official W3C page What’s New in WCAG 2.2 lists nine new criteria. Six of them are at levels A and AA, and therefore fall within the scope of AA conformance:

• 2.4.11 Focus Not Obscured (Minimum), level AA: the element that receives focus must not be entirely hidden by content on the page, such as a sticky banner;
• 2.4.12 Focus Not Obscured (Enhanced), level AAA: no part of the element may be hidden;
• 2.4.13 Focus Appearance, level AAA: the focus indicator must have a minimum size and contrast;
• 2.5.7 Dragging Movements, level AA: any action performed by dragging must also be possible with a single click or tap;
• 2.5.8 Target Size (Minimum), level AA: clickable areas must measure at least 24 by 24 CSS pixels, subject to exceptions;
• 3.2.6 Consistent Help, level A: the ways of getting help must appear in the same place from one page to the next;
• 3.3.7 Redundant Entry, level A: information already provided in a process must not be requested again, or must be offered automatically;
• 3.3.8 Accessible Authentication (Minimum), level AA: logging in must not require a cognitive function test without an alternative or assistance;
• 3.3.9 Accessible Authentication (Enhanced), level AAA: the same requirement, without the exception granted for object recognition.

Criterion 4.1.1 Parsing is, according to the W3C, “obsolete and removed” from WCAG 2.2: browsers and assistive technologies no longer depend on parsing raw source code. This is the only break in backward compatibility. The W3C points out that organisations whose regulations still refer to WCAG 2.0 or 2.1 may need to keep testing it. This is the case in France, where criterion 8.2 of RGAA 4.1.2 (validity of the generated source code) must still be checked.

WCAG 3: a long-term project, not a deadline

For several years the W3C has been preparing a new generation of guidelines, the W3C Accessibility Guidelines 3.0. The latest Working Draft is dated 10 September 2026. It proposes a different architecture: expected outcomes grouped by topic (images and media, user control and so on), more granular requirements classified as core or supplemental, and “assertions”, through which an organisation declares its practices, such as running user testing. The way conformance is calculated also differs from WCAG 2.

The W3C is explicit about the timetable. According to its WCAG 3 introduction page, the standard is not expected to be finalised for several years, it will not supersede WCAG 2, and WCAG 2 will not be deprecated for at least several years after WCAG 3 is finalised. The draft itself states that the final list of requirements will differ from the one published.

No European law and no harmonised standard currently refers to WCAG 3. For a chief information officer or a compliance manager, the consequence is simple: the worthwhile investment is in WCAG 2.2 level AA. The September 2026 draft also notes that meeting WCAG 2 at level AA means being close to meeting WCAG 3, although there may be differences.

EN 301 549: the European standard that goes well beyond the web

EN 301 549, entitled “Accessibility requirements for ICT products and services”, is developed jointly by ETSI, CEN and CENELEC, the European standardisation organisations. Whereas WCAG only cover web content, EN 301 549 covers information and communication technology as a whole: a cash machine, a line-of-business application, a video conferencing service, an e-reader or a downloaded PDF all fall within its scope.

For the web, the standard reinvents nothing: its clause 9 adopts the WCAG success criteria at levels A and AA. Clauses 10 and 11 apply the same criteria, adapted, to documents and software that are not web pages, including native mobile apps. The rest of the standard adds requirements that WCAG do not address.

Version 3.2.1 in force, version 4.1.1 published in September 2026

The version currently cited in the Official Journal of the European Union is V3.2.1, published in 2021. It was designated as the harmonised standard for public-sector websites and mobile apps by Commission Implementing Decision (EU) 2021/1339 of 11 August 2021, adopted under Directive (EU) 2016/2102. Its web, document and software clauses refer to WCAG 2.1 level AA.

Version 4.1.1 was adopted on 24 August 2026 and published on 2 September 2026. According to its foreword and introduction, it was prepared under the Commission’s standardisation request M/587, reference C(2022) 6456, to provide a means of demonstrating compliance with Directive (EU) 2019/882, the European Accessibility Act. Its clauses 9, 10 and 11 are aligned with WCAG 2.2, which the standard cites in the version of 12 December 2024 and under the reference ISO/IEC 40500:2025. Its annexes ZA and ZB map its requirements against those of the two directives. The text can be consulted free of charge on the ETSI website: EN 301 549 V4.1.1 (2026-09).

One legal point matters here: a standard only confers a presumption of conformity once its reference has been published in the Official Journal of the European Union. At the date of this article, V4.1.1 has not yet been cited there; the national authorities that followed the work, such as Luxembourg’s, expect it to be cited by the end of 2026. Until then, V3.2.1 remains the harmonised reference standard for the public sector.

What the standard requires on top of WCAG

In an audit against EN 301 549, several requirements fall outside a purely WCAG-based checklist. Software or an app must respect the system’s accessibility settings, for example the text size chosen in the phone’s settings. An authoring tool must make it possible to produce accessible content. The product documentation must describe its accessibility features, and the support service must be able to respond to a deaf or blind person. For a video conferencing service, or a banking app with video calls, clause 6 adds requirements on real-time text and on video quality sufficient for lip-reading or sign language.

RGAA 4.1.2: the difference between RGAA and WCAG explained

The General Accessibility Improvement Framework (Référentiel général d’amélioration de l’accessibilité, RGAA) is published by the French interministerial digital directorate (DINUM). It is used to assess the compliance of services subject to article 47 of Law no. 2005-102 of 11 February 2005, whose obligations are set out in our article on digital accessibility in France. Version 4 was adopted in September 2019; version 4.1.2, currently in force, results from the update of 18 April 2023.

RGAA 4.1.2 contains 106 criteria spread across 13 themes. Each criterion takes the form of a closed question, for example: “Does each image conveying information have a text alternative?”. Each criterion is broken down into tests, 258 in total according to the official list of RGAA criteria and tests (in French). A criterion is compliant if all its tests pass, non-compliant if any one of them fails, or not applicable if the content concerned does not exist on the page.

RGAA or WCAG: what really changes

In substance, RGAA 4.1.2 and WCAG 2.1 level AA say the same thing: every RGAA criterion maps to one or more WCAG criteria. Analysis of the official file shows that RGAA covers the level A and AA criteria of WCAG 2.1, with one exception: live captions (WCAG criterion 1.2.4) have no corresponding RGAA criterion.

The differences lie in the method. RGAA sets precise tests where WCAG leave the auditor free to choose the technique; it imposes a test environment, meaning combinations of screen readers and browsers (NVDA, JAWS and VoiceOver on desktop, TalkBack and VoiceOver on mobile); and it defines how to build the page sample and calculate a compliance rate. Finally, it comes with publication obligations specific to French law, such as the accessibility statement and the multi-year plan. The criteria added in WCAG 2.2, such as target size or accessible authentication, are not yet included.

An RGAA audit is therefore not equivalent to a WCAG 2.2 audit, and vice versa. If you need to publish a statement in France, an RGAA audit is the only one that produces a compliance rate that will stand up to scrutiny. If you are targeting the European Accessibility Act or a European market, the assessment must also cover the WCAG 2.2 criteria and the relevant clauses of EN 301 549.

RGAA 5 in preparation

DINUM has announced that version 5 of RGAA is being drafted, together with public bodies, associations and private-sector organisations, with publication planned for the end of 2026. According to the official RGAA 5 announcement (in French), this version will incorporate WCAG 2.2, reword and simplify the criteria, and define criteria and tests specifically for mobile apps and office documents. It will be accompanied by the designation of Arcom, the French audiovisual and digital communication regulator, as the enforcement authority, and by an online service for filing and publishing accessibility statements.

DINUM makes two practical points. The RGAA 5 criteria will clarify or supplement those of RGAA 4.1.2 without contradicting them, so work done today is not wasted. And statements drawn up before RGAA 5 is published will remain valid for 18 months, up to a maximum of three years after their publication date. Work in progress should not be put on hold while waiting for the new version.

RAWeb, RAAM and RAPDF: Luxembourg’s frameworks

Luxembourg has chosen national frameworks, published by the government’s Information and Press Service (SIP) on the accessibilite.public.lu portal. They are used to assess the websites and apps of public-sector bodies, which are subject to the law of 28 May 2019. What sets them apart is that they are built on EN 301 549, not on WCAG alone, while following the RGAA methodology.

RAWeb 1.1, for the web, has 136 criteria. It adopts the 13 themes of RGAA 4.1.2 and adds four more, derived from the European standard: documentation and accessibility features, authoring tools, support services, and real-time communication. The update published on 6 February 2026 notably took the European Accessibility Act into account, which means RAWeb can be used beyond the Luxembourg public sector, and removed techniques that had become obsolete.

RAAM 1.1, for mobile apps, has 108 criteria. It assesses an app against EN 301 549 V3.2.1, covering its clauses 5, 6, 7, 10, 11 and 12. RAPDF 1.1, for PDF documents, was simplified in February 2026: its method no longer relies on a screen reader but on Acrobat Reader and the PDF Accessibility Checker (PAC) tool, and it now includes a mapping to the PDF/UA-2 standard.

A major change is scheduled. On 15 September 2026, SIP announced that RAWeb and RAAM will move to version 2 in February 2027, compatible with EN 301 549 V4.1.1 and therefore with WCAG 2.2. Luxembourg bodies launching an audit in autumn 2026 carry it out against RAWeb 1.1 or RAAM 1.1; it is worth having the WCAG 2.2 criteria checked at the same time, to avoid a second round of fixes. Our article on digital accessibility in Luxembourg details the obligations, and the RAAM audit page describes the method applied to iOS and Android apps.

Belgium and Switzerland: no national framework of their own

In Belgium, EN 301 549 applies directly

In Belgium, the law of 19 July 2018 on the accessibility of public-sector websites and mobile apps transposes Directive (EU) 2016/2102 at federal level, complemented by decrees and ordinances of the Regions and Communities. There is no national grid comparable to RGAA: the reference is EN 301 549, which means WCAG 2.1 level AA for the web, and the same criteria as interpreted for documents and software.

In practice, a Belgian audit is based on the WCAG criteria and on the clauses of the standard that apply to the service. RGAA or RAWeb tests can serve as working tools for the auditor, but the report and the statement must refer to EN 301 549. The obligations and the competent authorities are presented on our Belgium page and in the article on digital accessibility in Belgium.

In Switzerland, the eCH-0059 standard

In Switzerland, the Disability Discrimination Act (LHand/BehiG) and its ordinance require the Confederation’s online services to be accessible. The technical reference is the eCH-0059 standard, version 3.0 (page in German), approved by the eCH association in June 2020. It is based on WCAG 2.1, and the federal administration requires compliance at level AA. Cantons and municipalities apply their own rules, which often refer to the same standard.

Two developments are worth following. A partial revision of the LHand, under discussion in the Federal Parliament, aims to strengthen access to services provided by private companies, including digital services. And Swiss companies selling to consumers in the European Union are subject to the European Accessibility Act for the products and services concerned, and therefore to EN 301 549 rather than eCH-0059. The details are in our article on digital accessibility in Switzerland.

Which digital accessibility standards apply by country and organisation

The table below matches each country and type of organisation with the applicable legislation, the assessment framework and the expected level. It describes the situation as of 27 October 2026; announced changes are listed in the action plan at the end of the article.

Two remarks will help you read this table. First, RGAA and RAWeb are assessment methods, not additional levels of requirement: a website that complies with RGAA is not “more accessible” than one that conforms to EN 301 549; it has simply been assessed against a different grid. Second, for the European Accessibility Act, it is the directive that sets the requirements and the harmonised standard that gives them their technical expression; our analysis of the European Accessibility Act details the products and services covered and the exemptions.

Six criteria explained through real-world cases

Standards become easier to grasp through a handful of criteria that come up in every audit. For each one, we give the WCAG reference and, where it exists, the corresponding RGAA criterion.

Text alternatives for images

WCAG criterion 1.1.1 Non-text Content (level A), covered by RGAA criteria 1.1 to 1.3, requires every informative image to have a text equivalent, and decorative images to be ignored by assistive technologies. On a payment page, the logos of the accepted cards must be announced (“Visa, Mastercard”); the decorative illustration in the banner, on the other hand, must have an empty alternative so that it does not clutter the reading.

The common mistakes are well known: an alternative that repeats the file name (“IMG_2045.jpg”), an alternative such as “image” or “logo” with no useful content, or a chart in an annual report described only by its title when the figures appear nowhere else. In that last case, RGAA requires a detailed description (criterion 1.6), for example a table of the data placed below the chart.

Contrast of text and interface components

WCAG criterion 1.4.3 Contrast (Minimum) (level AA), RGAA criterion 3.2, requires a contrast ratio of at least 4.5:1 between text and its background, reduced to 3:1 for large text, meaning at least 18 point, or 14 point in bold. Light grey placeholder text in a form field, white text over a pale photo or the small print in a cookie banner frequently fail.

Criterion 1.4.11 Non-text Contrast (level AA), RGAA criterion 3.3, extends the requirement to interface components and to graphical elements that convey information: the border of an input field, a magnifying-glass icon with no label or the line on a chart must reach a contrast of 3:1 against adjacent colours.

Visible focus, and now unobscured focus

A person navigating with a keyboard must be able to see where they are at all times. WCAG criterion 2.4.7 Focus Visible (level AA), RGAA criterion 10.7, requires the element that receives focus to be visible. The classic mistake is a CSS rule “outline: none” applied across the whole site for aesthetic reasons, with no replacement indicator.

WCAG 2.2 adds criterion 2.4.11 Focus Not Obscured (Minimum) (level AA): the focused element must not be entirely hidden by content added by the author. A sticky header that covers the link the user has just tabbed to, or a consent banner that hides the bottom of the page while the user tabs through the footer, makes the page non-conformant.

Target size

A new criterion in WCAG 2.2, 2.5.8 Target Size (Minimum) (level AA) requires targets for pointer actions to measure at least 24 by 24 CSS pixels. There are exceptions: a smaller target remains acceptable if it is separated from neighbouring targets by sufficient spacing, if the same function is available through another conformant control on the page, if the link sits within a sentence, or if the size is determined by the browser rather than by the author.

Typical failures include tightly packed pagination numbers, the close button of a modal window on mobile, or sharing icons lined up with no margin. This criterion does not exist in RGAA 4.1.2; it is, however, included in EN 301 549 V4.1.1. Fixing it usually means adjusting a few components of the design system, which also benefits people with tremors and every smartphone user.

Accessible authentication

WCAG criterion 3.3.8 Accessible Authentication (Minimum) (level AA) prohibits requiring a cognitive function test to log in, such as remembering a password, transcribing characters or solving a puzzle, unless an alternative or assistance is provided. According to the W3C’s explanatory documentation, password managers and copy and paste are valid forms of assistance: a website that blocks pasting into the password field, or prevents fields from being filled in automatically, fails the criterion.

Two examples come up often in customer accounts. A virtual keypad whose digits change position at every login forces the user to search for each digit, with no alternative; and an SMS code to be entered in six separate boxes that refuse pasting forces the user to transcribe it. An object-recognition captcha (“select all images containing a bicycle”) is tolerated at level AA, but a captcha that asks the user to retype distorted text, with no other way to log in, is not.

Captions

WCAG criterion 1.2.2 Captions (Prerecorded) (level A) requires synchronised captions for prerecorded videos with sound; RGAA covers it in criteria 4.3 (presence) and 4.4 (relevance). A recording of a council meeting published after the event, a product presentation video or a training tutorial are all concerned. Automatically generated captions that are never reviewed frequently fail the relevance criterion.

For live content, such as a webinar or the broadcast of a public meeting, WCAG criterion 1.2.4 Captions (Live) (level AA) requires real-time captions. It has no corresponding criterion in RGAA 4.1.2, but it applies to an audit against WCAG or EN 301 549. Clause 7 of the standard adds a requirement on the player side: the video player must be able to display captions and preserve them when the content is transmitted.

Several countries, one programme: choosing a pivot standard

A group that runs an e-commerce site in France, Belgium and Luxembourg, a shared mobile app and a customer portal in Switzerland cannot run four separate accessibility programmes. The most effective approach is to choose a pivot standard, applied to all shared components, and then produce national assessments wherever the law requires one.

1. Map your services and the rules that apply to them. For each website, app or document, record the countries where it is available, the status of the entity that publishes it (public, private, covered by the EAA or not) and the documents to be published: accessibility statement, information required by the EAA, multi-year plan in France.
2. Choose a demanding pivot. WCAG 2.2 level AA, supplemented by the clauses of EN 301 549 that are relevant to your services (software, documentation, support, real-time communication), covers by design the substance of the requirements of RGAA, RAWeb, RAAM and eCH-0059.
3. Assess shared components first. The design system, page templates, checkout and authentication are common to all your markets: a fix made once benefits every country.
4. Produce the national assessments required. Where a national framework is mandatory, such as RGAA in France for a service subject to article 47, or RAWeb for a Luxembourg public body, carry out the audit against that framework to obtain a compliance rate and a statement that will be accepted.
5. Harmonise your indicators. Track a common indicator, for example the number of WCAG 2.2 AA criteria not met per user journey, and keep the national rates for the statements.

The most common pitfall is presenting an RGAA audit as proof of compliance with the European Accessibility Act: it covers neither the new WCAG 2.2 criteria nor the standard’s requirements on documentation and support. The reverse is also true: a WCAG 2.2 report is not enough to draw up an RGAA statement. A WCAG and EN 301 549 compliance audit serves as the pivot; it can be combined with a national audit where the law requires one. The issues specific to groups are covered on our large organisations page.

Audit method: from page sample to remediation plan

Whatever the framework, a serious accessibility audit follows the same steps. What varies is the set of criteria and the form of the result. Our guide to digital accessibility presents the overall approach; here is how a compliance audit unfolds.

1. Scoping. Choice of the framework and its version, definition of the scope (website, subdomains, logged-in area, app), test environment and access to demonstration accounts.
2. Building the sample. The RGAA method requires a representative sample: standard pages where they exist (home, contact, legal notice, accessibility statement, site map, help, login), the most visited pages, pages representative of each template and every step of key processes, such as requesting a civil status certificate or completing a purchase.
3. Manual testing, criterion by criterion. The auditor checks each criterion on each page of the sample, using the keyboard, the code inspector and measuring tools (contrast, heading structure). This is the step that takes the most time.
4. Checks with assistive technologies. Complex components, such as a drop-down menu, an interactive map or a modal window, are tested with screen readers (NVDA, JAWS, VoiceOver, TalkBack) and with zoom, to check what is actually announced to the user.
5. Calculating the result and writing the report. Depending on the framework, the report gives a compliance rate (RGAA, RAWeb, RAAM) or a status for each criterion (WCAG, EN 301 549). Each non-compliance is located, illustrated and accompanied by a recommended fix.
6. Remediation plan and follow-up audit. Non-compliances are ranked by impact on users and by effort, then a follow-up audit checks the fixes before the statement is updated.

What automated tools cannot see

Browser extensions and crawlers are useful for quickly spotting repetitive errors: an image without an alt attribute, a field without a label, insufficient contrast for text on a plain background, an undeclared language. They cannot judge relevance: an alternative reading “button” on the image of a “Pay” button passes the automated test but remains non-compliant. Nor do they detect a keyboard trap in a modal window, an illogical tab order, text placed over a photo or a video with no captions.

An automated tool’s score is therefore not a compliance rate, and cannot be the basis for an accessibility statement. In our audits, tools are used to cover a large number of pages quickly, but every criterion is checked manually; a full audit takes three weeks on average. To find out whether user journeys really work, testing with people with disabilities is a useful complement to the audit.

PDF documents and mobile apps: the blind spots of audits

PDF documents

Downloadable documents are often forgotten, even though they carry essential information: council decisions, minutes, forms, terms and conditions, annual reports. EN 301 549 devotes clause 10 to them, applying the WCAG criteria to non-web documents. RGAA addresses them in criterion 13.3, which requires an accessible version of every downloadable office document, and Luxembourg has a dedicated framework, RAPDF, aligned with the PDF/UA-2 standard.

A scanned PDF of a council decision is simply an image: a screen reader cannot read it, however good the scan. An accessible PDF is tagged (headings, lists, tables), has a logical reading order, a document title, a declared language and alternatives for its images. For essential information, the most sustainable solution is often to publish the content in HTML and offer the PDF as a complement.

Mobile apps

A native app falls under clause 11 of EN 301 549, on software, which transposes the WCAG criteria to the context of an app. In Luxembourg, RAAM 1.1 provides the official grid. In France, mobile apps fall within the scope of article 47 and are currently assessed with RGAA; RGAA 5 is due to define criteria and tests specific to mobile.

An app audit is carried out on real devices, with VoiceOver on iOS and TalkBack on Android. The most sensitive checkpoints are how icon-only buttons are announced, respect for the text size chosen in the phone’s settings, display in both portrait and landscape orientation (WCAG criterion 1.3.4 Orientation), complex gestures with no alternative (criterion 2.5.1 Pointer Gestures) and the size of touch targets. On that last point, WCAG 2.2 and EN 301 549 V4.1.1 now set a minimum, whereas RAAM 1.1 and RGAA 4.1.2 do not.

Action plan: twelve months to reach the right level

The texts will change over the coming months, but none of these changes justifies waiting: the new versions announced clarify current requirements without calling them into question. Here is a realistic sequence for an organisation starting from an unknown baseline.

1. Month 1: inventory. List your websites, apps, logged-in areas and families of documents, with their audience, the countries where they are available and the legal regime that applies.
2. Months 1 and 2: choice of framework. Determine for each service the mandatory framework (RGAA, RAWeb, RAAM, EN 301 549, eCH-0059) and adopt WCAG 2.2 level AA as the common pivot.
3. Months 2 and 3: initial audit. Have the most used services audited first, along with the journeys that matter most to users: login, payment, booking an appointment, submitting an application.
4. Month 3: publication. Publish or update the accessibility statement and, in France, the multi-year plan and the annual action plan. The required elements are detailed in our article on the accessibility statement.
5. Months 3 to 9: fixes, component by component. Fix the design system and templates first, then the content. Build an accessibility acceptance check into every release to avoid regressions.
6. Months 4 to 12: building skills. Train the people who produce content and code: developers, designers, content editors and buyers. Role-specific training stops the same errors from coming back.
7. Month 12: follow-up audit. Measure progress against the framework in force at that date and update the statement.

The timetable to watch

• by the end of 2026: expected citation of EN 301 549 V4.1.1 in the Official Journal of the European Union, which will give it a presumption of conformity;
• end of 2026: planned publication of RGAA 5 by DINUM, incorporating WCAG 2.2; earlier statements remain valid for 18 months, up to a maximum of three years;
• February 2027: planned publication of RAWeb 2 and RAAM 2 in Luxembourg, compatible with EN 301 549 V4.1.1;
• no fixed date: partial revision of the LHand in Switzerland, and finalisation of WCAG 3 by the W3C, which will not replace WCAG 2 for several years.

To see the framework for each country at a glance, consult our standards and obligations page, as well as the France, Luxembourg and Switzerland pages.

Frequently asked questions