Digital accessibility in Luxembourg: what the SIP and the OSAPS check in 2026

Digital accessibility in Luxembourg rests on two laws and two authorities: the law of 28 May 2019 for public-sector websites and mobile apps, monitored by the government’s Information and Press Service (SIP), and the law of 8 March 2023, which transposes the European Accessibility Act and gives market surveillance to the OSAPS. The national frameworks RAWeb 1.1 and RAAM 1.1 turn the EN 301 549 standard into verifiable criteria, for the web and for mobile apps alike. This article sets out who has to do what, what the published monitoring results show, and how an app audit against RAAM actually works in practice.

Digital accessibility in Luxembourg: what the law of 28 May 2019 requires

The law of 28 May 2019 on the accessibility of the websites and mobile applications of public sector bodies transposes Directive (EU) 2016/2102. Its principle is simple: a public website or app must be usable by a person who is blind, partially sighted, deaf, or who has a physical or cognitive disability, with their own tools and settings. The law itself does not contain a list of technical criteria. It refers to the harmonised European standard EN 301 549, version V3.2.1, which Luxembourg then translates into national assessment frameworks.

This accessibility law is the foundation of the entire framework that applies to the Luxembourg public sector. The official portal sets out the detail on its page on the legal requirements regarding digital accessibility, which is the reference reading for a legal department or a project manager. The paragraphs below focus on the points that raise the most questions in day-to-day practice.

Which organisations are covered

The law covers the State, the municipalities, certain bodies governed by public law and the associations formed by these authorities. In practice, this means ministries and their administrations, municipalities and inter-municipal syndicates, social welfare offices and public establishments. A circular from the Ministry of Home Affairs dated 11 August 2021 reminded municipal administrations, inter-municipal syndicates, social welfare offices and the public establishments under their supervision of these obligations.

Mobile apps fall within scope as soon as they are designed and developed by a public body or on its behalf. An app commissioned from an agency or an IT contractor therefore remains the responsibility of the body that publishes it: that body signs the accessibility statement and answers complaints. The specifications have to reflect this from the call for tenders onwards, with accessibility requirements, an acceptance procedure and the allocation of responsibility for fixes written into the contract.

A few categories are excluded from the scope of the law:

• websites and apps of public service broadcasters;
• certain non-governmental organisations;
• websites and apps of primary and secondary schools and of nurseries, except for content relating to essential online administrative functions, such as enrolment or payment.

Exempted content

Some content is also exempt from the obligation, depending on its nature and its publication date. These exemptions are precise and tied to specific dates; they do not cover an entire older website simply because it has been online for a long time.

• office file formats published before 23 September 2018, unless they are needed for an active administrative process;
• pre-recorded time-based media published before 23 September 2020;
• intranet and extranet content published before 23 September 2019, until it undergoes a substantial revision;
• archived content that is not needed for an active process and has not been updated after 23 September 2019;
• live time-based media, third-party content and certain reproductions of heritage items.

A common example: a municipality publishes the minutes of its municipal council every month as a PDF. Minutes published before September 2018 can stay as they are if they are not used for any administrative process. Those published since then must be accessible, or come with an accessible alternative, such as an HTML version of the same content.

The practical obligations

• make websites and apps compliant with the requirements of EN 301 549, assessed with RAWeb for the web and RAAM for mobile;
• publish an accessibility statement for each website and each app, and keep it up to date;
• provide an accessible mechanism for reporting a problem or requesting an alternative, acknowledge receipt and reply within one month;
• inform the SIP of the publication or update of the statement, without any particular formality, within thirty days;
• mention in the statement that users can refer the matter to the SIP or to the Ombudsman of the Grand Duchy.

Disproportionate burden: a tightly framed derogation

Article 4 of the law allows a body to derogate from the requirements where they would impose a disproportionate burden. The official portal frames this notion strictly: it is assessed case by case, for a given feature or piece of content, and in principle cannot cover an entire website or app. The size of the body, its resources, and the estimated costs and benefits for persons with disabilities all enter into the assessment.

Two clarifications prevent a great many mistakes. First, the portal states explicitly that a lack of priority, time or knowledge is not a legitimate circumstance. Second, invoking disproportionate burden does not exempt a body from publishing an accessibility statement, nor from offering an accessible alternative where possible; for an essential public service mission, an equivalent alternative service must be provided.

The SIP and accessibilite.public.lu: who monitors the public sector

The government’s Information and Press Service (Service information et presse, SIP) is the body responsible for monitoring the law of 28 May 2019. Attached to the Ministry of State and placed under the direct authority of the Prime Minister, it is first and foremost the government’s communication service. Since the transposition of the directive, it has also carried the whole of the public sector’s digital accessibility policy: monitoring, assessment frameworks, complaints, information and training.

Its tasks in this area fall into four groups:

• carrying out periodic monitoring of public-sector websites and apps and reporting on it to the European Commission;
• publishing and maintaining the assessment frameworks: RAWeb for the web, RAAM for mobile apps, RAPDF for PDF documents;
• handling user complaints, in consultation with the bodies concerned;
• informing, raising awareness and training, in particular through the accessibilite.public.lu portal, an observatory and courses offered with the National Institute for Public Administration (INAP).

Three types of monitoring

In line with Implementing Decision (EU) 2018/1524, the SIP uses three forms of monitoring. In-depth monitoring of a website is a full conformity audit against RAWeb: it states whether the website is accessible and which problems were found. Monitoring of a mobile app is a conformity audit against RAAM. Finally, simplified monitoring aims to detect non-conformities and raise awareness, without allowing any conclusion on the website’s conformity.

The simplified monitoring method is published. It covers a sample of three pages (the home page, a page with a form, and a page with particular content such as a video, a table or a complex image), combines 41 automated rules from the Axe tool with 47 RAWeb criteria checked manually, and excludes downloadable documents. It allows far more websites to be covered than in-depth auditing would.

An annual cycle and open data

The first monitoring period ran from 23 September 2020 to the end of 2021; since then, each period has corresponded to a calendar year. The process always follows the same steps: an inventory of public websites and apps, a sample drawn up together with the main organisations representing persons with disabilities, audits, and then a report to the European Commission every three years. Inventories, samples, audit reports, accessibility statements and the complaints history are published on the open data portal data.public.lu.

This transparency has a practical consequence: a public body that appears in the year’s sample will see its audit report published. The SIP has published the 2026 sample; checking whether your websites or apps are in it is a sensible first step for any public body.

Public tools beyond monitoring

The portal provides a model set of specifications for procurement, an audit kit, an accessibility statement generator and the complaint form. The sources of the frameworks are published on GitHub, which allows the community to propose corrections. In 2026, the SIP also presented Mia and Mil, two Luxembourgish synthetic voices designed for assistive technologies, open source and usable offline: until then, screen reader users usually had to make do with a German voice to read a text in Luxembourgish.

RAWeb 1.1: Luxembourg’s web accessibility framework and how it differs from RGAA

RAWeb, the web accessibility assessment framework (Référentiel d’évaluation de l’accessibilité web), is the method used to check that a web page meets the requirements of EN 301 549. Its version 1.1, published on 6 February 2026, contains 136 control criteria grouped into 17 themes. It applies to all HTML content (HTML4, XHTML1 and HTML5); native mobile apps fall under RAAM.

RAWeb draws on content from the French RGAA 4.1.2, adapted by the SIP to the Luxembourg legal framework. The first thirteen themes will be familiar to anyone who knows RGAA: images, frames, colours, multimedia, tables, links, scripts, mandatory elements, structuring of information, presentation of information, forms, navigation and consultation. RAWeb adds four further themes: documentation and accessibility features, authoring tools, support services, and real-time communication.

Why 136 criteria instead of 106

RGAA 4.1.2 has 106 criteria and concentrates on the requirements derived from WCAG. EN 301 549 goes further: it also deals with a service’s documentation, the tools used to publish content, customer support and real-time communication. RAWeb covers these requirements, which explains the 30 additional criteria mentioned in the Luxembourg monitoring report. The SIP used RGAA for its in-depth monitoring until 2023, and RAWeb from 2024 onwards.

The direct consequence: an RGAA audit carried out for a French website is not enough to establish the conformity of a Luxembourg website. It covers most of the ground, but leaves out the criteria specific to the standard, for example the accessibility of online help, a support chat or a publishing back office. The resulting scores are not directly comparable either, since the denominator changes. Our article on accessibility standards and frameworks explains these correspondences in detail, and the standards by country page summarises them.

RAPDF for documents

Luxembourg also has a framework dedicated to PDF documents, RAPDF, introduced in 2023 and also moved to version 1.1 in 2026. This matters for administrations, which publish large numbers of forms, reports and council decisions as PDFs: office documents are the most frequently declared exemption in accessibility statements, and inaccessible PDFs are the leading reason for complaints recorded by the SIP over 2022-2024.

RAAM 1.1: the framework for mobile app accessibility

RAAM, the mobile app accessibility assessment framework (Référentiel d’évaluation de l’accessibilité des applications mobiles), is one of Luxembourg’s distinctive features. Few countries have such a detailed public method for assessing a native app. Its version 1.1, published on 24 February 2025, contains 108 control criteria and is used to check that an app meets EN 301 549 V3.2.1. It is released under the CC-BY 3.0 LU licence.

RAAM covers the chapters of the standard that concern an app: generic requirements (chapter 5), two-way voice communication (6), video capabilities (7), non-web documents (10), software (11), and documentation and support services (12). Its criteria are organised into fifteen themes:

• graphic elements, colours, multimedia, tables;
• interface components, mandatory elements, structuring of information, presentation of information;
• forms, navigation, consultation;
• documentation and accessibility features, authoring tools, support services, real-time communication.

What changed with version 1.1

The first version of RAAM, published in June 2021, had 107 criteria. Version 1.1 adds one, criterion 14.3, which results from splitting theme 12 to make the requirements easier to read. It also revises several methods: contrast now takes the actual size of the text into account, new tests cover captions for live media, and the flashing threshold changes from “fewer than 3 per second” to “3 per second or fewer”.

The methodology has gained a non-interference principle, taken from RAWeb: exempted or derogated content does not have to conform, but it must not prevent access to the rest of the screen. It also explains how to test with or without a keyboard accessibility service on Android, and how to measure text size from screenshots.

Why a framework separate from the web

With a native app, the auditor almost never has access to the source code. They cannot inspect an attribute as they would on a web page: they check what the operating system actually exposes to assistive technologies. RAAM tests therefore rely on screen readers, system settings and the inspection tools provided by Apple and Google. It is a different way of working, which requires real devices and a sound knowledge of each platform. RAAM is the Luxembourg framework; elsewhere, the same method applies with the local standard, as explained on our page on mobile app audits against RAAM.

Accessibility statement and complaints: how the Luxembourg process works

The accessibility statement is the document that users, the SIP and sometimes the press look at first. It states a compliance status established by an audit, using three levels defined by the official portal.

• fully compliant: all the control criteria of the framework are met, meaning a score of 100% after audit;
• partially compliant: at least 50% of the control criteria are met;
• non-compliant: no valid audit has been carried out, or fewer than 50% of the criteria are met.

Beyond this status, the statement lists inaccessible content, distinguishing between what is non-compliant, what is exempt and what falls under disproportionate burden, with the justification and the alternatives offered. It describes the accessibility features available, states whether the assessment was a self-assessment or carried out by a third party, gives a contact address and reminds users that they can refer the matter to the SIP or the Ombudsman.

Where to publish it, and in which languages

For a website, the statement must be easy to find: a link must appear on every page, for instance in the footer. For an app, it is published on the website of the responsible body or in the information available at the time of download, in other words the App Store or Google Play listing. The official generator produces the statement in French, German, English and Luxembourgish, and recommends offering it in every language of a multilingual website.

Once it is published, the body sends the address of its statement to the SIP at accessibilite@sip.etat.lu. The generator recommends a fresh assessment after any major redesign and a review of the statement at least once a year. For the drafting itself, our article on the accessibility statement covers the most common mistakes, in France as well as in Luxembourg.

How a complaint proceeds

Take a user who cannot submit an online benefit application with TalkBack because the “Send” button is not announced. They first contact the body, using the contact details given in the accessibility statement. The body must acknowledge receipt and reply within one month of the message being sent; if the problem is complex, it may set a longer timeframe, provided it justifies it.

If the answer does not satisfy them, the user can refer the matter to the SIP through its online complaint form, or to the Ombudsman of the Grand Duchy of Luxembourg. The SIP undertakes to reply by email within one month at the latest. In practice, it analyses the request, contacts the body and gives it a month to respond. As long as the statement offers no accessible contact point, the body deprives itself of the first step and lets the complaint go straight to the authority.

What the published monitoring results for 2022 to 2024 show

Luxembourg publishes its results in unusual detail. The report on the monitoring of public-sector websites and mobile apps for 2022-2024 (in French), sent to the European Commission, gives a precise picture of the situation. All the figures in this section are taken from it.

The trend is clear: websites are improving, from an average score of 48% to 61% in three years, while mobile apps are falling back, from 49% to 37%. The report notes that in 2024, as in 2021, none of the apps audited reached partial compliance (two did in both 2022 and 2023). Mobile is currently the weak point of the Luxembourg public sector, which is why RAAM deserves particular attention.

The most frequent non-conformities

In apps, the three most frequent defects are interface components that are incompatible with assistive technologies (criterion 5.1), an unsuitable heading structure (criterion 7.1) and content that does not adapt to screen orientation (criterion 11.9). In websites, under in-depth monitoring, they are scripts incompatible with assistive technologies, tags used for presentation purposes and badly structured lists.

Under simplified monitoring, the most frequent defect is the failure to indicate changes of language, ahead of scripts that cannot be operated with a keyboard and a mouse and insufficient text contrast. That first result is very Luxembourgish: a page in French that refers to a procedure in German or to the name of an institution in Luxembourgish must mark up that switch so that the screen reader changes voice and pronunciation.

Statements, derogations and complaints

The report counts 431 accessibility statements for websites and 30 for apps, out of 979 websites and apps identified in the public-sector inventory. In 2024, 61% of statements invoked a derogation for disproportionate burden, a practice that the official framework nonetheless presents as exceptional. The SIP received 20 complaints over the period; inaccessible PDFs are the leading reason, ahead of problems with web pages and with apps.

These numbers are modest in absolute terms, but they are public. For an administration, the risk is less a sanction than a published audit report showing a low score, or a statement that invokes disproportionate burden without justification. To find out more about how we support administrations, see our public sector page.

EAA in Luxembourg: the law of 8 March 2023 and the OSAPS

Luxembourg transposed Directive (EU) 2019/882, known as the European Accessibility Act, through the law of 8 March 2023 on the accessibility requirements for products and services, published in Mémorial A No. 133 of 15 March 2023. The OSAPS publishes an English version of the law of 8 March 2023; the French text published in the Mémorial remains the reference version. Under its Article 36, the law entered into force on 28 June 2025. This time, it applies to economic operators, private and public, that place covered products on the market or provide covered services to consumers.

Products and services covered

On the product side: consumer computers and operating systems, smartphones and tablets, payment terminals, check-in machines and ticketing machines for transport (other than those installed in vehicles), smart TVs and e-readers. On the service side: electronic communications, access to audiovisual media services, air, rail, bus and waterborne passenger transport (websites, apps, electronic ticketing and information), consumer banking services, e-books, e-commerce and the answering of emergency communications to 112. Our article on the European Accessibility Act details this scope, which is common to all Member States.

The OSAPS, the supervisory authority

Article 3 of the law creates the Office for monitoring the accessibility of products and services (Office de la surveillance de l’accessibilité des produits et services, OSAPS), placed under the authority of the minister responsible for disability policy, currently the Ministry of Family Affairs, Solidarity, Living Together and Reception of Refugees. For products, monitoring is carried out by the OSAPS, the Customs and Excise Administration and the Grand Ducal Police (Article 28, paragraph 1). For services, the OSAPS and the Grand Ducal Police check compliance, together with the competent sectoral authorities (Article 28, paragraph 2).

The OSAPS also acts as a contact point on accessibility and provides guidelines and tools, especially for microenterprises. Any natural or legal person can report a product or service that does not comply. Reports are made online via MyGuichet.lu, free of charge, with the option of attaching a screenshot or a document. An association of persons with disabilities can file a report as a legal person.

Penalties provided for

• an administrative fine of EUR 250 to EUR 15,000 imposed by the OSAPS on an operator that refuses to provide documents or information, obstructs inspections or fails to comply with the Office’s decisions (Article 32);
• a criminal fine of EUR 251 to EUR 500,000 for an economic operator that infringes the provisions covered by the law, scaled to the extent and seriousness of the breach (Article 33, paragraph 1);
• for a repeat offence, a fine of EUR 500 to EUR 1,000,000 (Article 33, paragraph 2);
• restriction or prohibition of making a non-compliant product available or of providing a non-compliant service, a decision that can be challenged through an appeal for reversal before the administrative court within three months (Article 28, paragraph 5).

Exemptions and transition periods

The law defines a microenterprise as an enterprise that employs fewer than ten persons and whose annual turnover or annual balance sheet total does not exceed EUR 2,000,000. Microenterprises that provide services are exempt from the accessibility requirements; those that manufacture or distribute products remain subject to the requirements, with lighter documentation obligations. A larger SME that sells online to consumers, on the other hand, is fully covered.

Transition periods apply. Service providers may continue to use, until 28 June 2030, the products they were lawfully using before entry into force. Service contracts concluded before that date may continue unchanged until they expire, for no longer than five years. Self-service terminals already in use may remain in service until the end of their economically useful life, but no longer than twenty years after they were put into service.

As everywhere in the Union, the provider of a covered service must also explain, in publicly available information and in particular in its general terms and conditions, how its service meets the accessibility requirements. This point is often overlooked: an online shop can be technically sound and still fall short because this information is missing. For the technical assessment, the reference is EN 301 549; RAWeb and RAAM are public, detailed and free methods for applying it, and the OSAPS lists them among its resources. For these organisations we offer a compliance audit against EN 301 549 and WCAG.

Multilingualism, the financial centre and cross-border workers: what makes Luxembourg different

The technical requirements are European, but applying them in Luxembourg means dealing with three realities that are rarely found together elsewhere. They have a direct effect on the quality of an audit and on the cost of fixing issues.

Four languages in a single interface

The law of 24 February 1984 on the use of languages recognised Luxembourgish as the national language, made French the language of legislation and established French, German and Luxembourgish as administrative languages. English is very often added in financial services, the European institutions and international companies. A single public website can therefore exist in four versions, and a single page can mix several languages.

For accessibility, each language version is content in its own right: text alternatives, button labels, error messages, captions and transcripts must exist in every language. The language of each page must be declared, and every passage in another language marked up; as shown above, this is the most frequent defect found by simplified monitoring. RAAM 1.1 has also added a condition on the language of captions. Finally, an audit sample must cover the language versions that are actually used, otherwise the defects of a secondary translation go unnoticed.

The financial centre and banking services

Consumer banking services fall within the scope of the EAA. For a retail bank, a payment institution or an electronic money issuer established in Luxembourg, the mobile app is often the main customer channel. The sticking points are well known: strong authentication by code or biometrics with no alternative, session timeouts too short for a screen reader user, portfolio charts with no text equivalent, untagged PDF contracts and statements, and visual captchas during account opening.

Private banks and firms that only serve professional clients need to analyse their scope carefully, because the EAA targets services provided to consumers. This analysis should be documented and validated by the legal department rather than assumed. Our large organisations page describes how we support these organisations.

Cross-border workers, users in their own right

According to STATEC (in French), Luxembourg had 225,840 incoming cross-border employees in 2023, of whom 54.2% lived in France, 23% in Germany and 22.7% in Belgium. These people use Luxembourg digital services (social security, tax, transport, banking) with devices and settings configured in their home country, sometimes in a different language from that of the service.

For a Luxembourg organisation, this means testing with a variety of configurations, in particular screen readers set to French or German. For an organisation operating on both sides of the border, it also means dealing with several regimes: RGAA in France, EN 301 549 in Belgium, RAWeb and RAAM in Luxembourg. Our articles on digital accessibility in Belgium and digital accessibility in France cover the two neighbours; our consultants work in French, German and English.

Auditing a mobile app against RAAM: the step-by-step method

The RAAM 1.1 testing methodology is public and precise. It nonetheless leaves many practical choices to the auditor. Here is how an audit of a public body’s or a company’s app actually unfolds, on iOS and on Android.

1. Define the scope and the environment. The audit fixes the version of the app under review (the published version or a test build via TestFlight or a Google Play testing track), the test accounts needed and dummy data so that procedures can be completed without risk. If the app is intended for a managed environment, for example a fleet of devices administered by a bank or an administration, RAAM requires testing with the configurations actually used in that environment.
2. Build the screen sample. The methodology requires, where they exist, the home screen, the legal information, authentication, contact, documentation screens, at least one relevant screen for each type of service and main use (including search), at least one downloadable document per service, every screen of a multi-step process and screens of different kinds (data tables, multimedia, forms, real-time communication). Randomly selected screens, representing at least 10% of the sample, complete the selection.
3. Prepare real devices. Tests are carried out on the latest available version of iOS and Android, or on the previous version, with the versions of VoiceOver and TalkBack that ship with the system. RAAM states that there is no need to test Android on any particular device model. In practice, plan for at least one smartphone on each platform, plus a tablet if the app supports it.
4. Test with a screen reader. Each screen is reviewed with VoiceOver on iOS and TalkBack on Android, using swipe gestures, touch exploration and the rotor or reading controls. The VoiceOver caption panel or TalkBack’s speech output display makes it possible to record exactly what is announced. The auditor checks that every button has a name, a role and a state, that headings are declared, and that error and confirmation messages are conveyed without moving focus unexpectedly.
5. Test with an external keyboard and switch access. On iOS, Full Keyboard Access is enabled; on Android, testing starts with the keyboard alone, then with Switch Access if needed, mapping for example Tab to “next”, Shift + Tab to “previous”, Enter to “select” and Esc to “back”. The aim is to reach and activate every function, without traps and in a logical order.
6. Check zoom and display. Text size is increased in the system settings; on iOS, the methodology recommends testing at 190%, the value closest to 200% available in Control Centre. The auditor checks that text is neither truncated nor overlapping, that the app works in both portrait and landscape mode, and that contrast remains sufficient, measured from screenshots taken on the device.
7. Check other uses. This step covers alternatives to complex gestures (dragging, pinching, shaking), the size and spacing of touch targets, the handling of time limits, videos (captions, audio description), embedded web views that carry a procedure, and documents downloaded from the app. Apple’s inspection tool (Accessibility Inspector), Google’s (Accessibility Scanner) and Colour Contrast Analyser complete the analysis, without ever replacing manual testing.
8. Calculate the score and apply non-interference. A criterion is only passed if it is met on every screen in the sample where it applies: a single failing screen is enough to fail it. The compliance score is the ratio of passed criteria to applicable criteria. The non-interference criteria (control of automatically triggered sounds, no keyboard trap, control of time limits, no hazardous flashing, control of moving content) apply even to exempted content.
9. Report and draft the statement. The report sets out, screen by screen, the criteria that were not passed, the elements at fault and separate recommendations for the iOS and Android teams, which use different components. It forms the basis of the accessibility statement to be published on the body’s website or in the app’s store listing.

Three pitfalls come up again and again. The first is auditing only one platform: iOS and Android have their own components, and a hybrid app can work well on one and fail on the other; the SIP’s own audits look at iOS and Android versions separately. The second is orientation locked to portrait without justification, one of the most frequent defects found. The third is the custom component (date picker, carousel, tabs) that is not exposed to assistive technologies. To go beyond conformity, testing with users with disabilities shows whether the user journeys are genuinely usable.

These pitfalls have a cost that grows with time. A date picker built from scratch may be reused on a dozen screens, so a single design flaw multiplies the number of failing screens in the sample and, because a criterion fails as soon as one screen fails, can drag the overall score down on its own. Catching such components at the design stage, or during acceptance testing of each release, is much cheaper than fixing them after an audit has been published.

Who applies what: organisation, law, framework, monitoring

The table below summarises the most common situations. It does not replace a legal analysis of your scope, but it helps you quickly identify the law and the authority that apply to you.

A single organisation can fall under both laws. A public transport operator, for example, is covered by the 2019 law for its institutional websites and by the 2023 law for its passenger transport services. The digital accessibility in Luxembourg page sets out the main obligations and the services available in the country.

For international groups, the table is also a reminder that the regime follows the service, not the company. A group with a Luxembourg retail banking subsidiary and an arm that serves only professional clients has to analyse each service separately, since the EAA targets services provided to consumers. Mapping each service to a line of this table is a quick way to prepare the scoping discussion with your legal team.

RAWeb 2 and RAAM 2 in 2027: preparing for the new EN 301 549

The framework is about to change. The revised version of EN 301 549, numbered 4.1.1, was approved by CEN and ETSI on 2 September 2026; its publication in the Official Journal of the European Union is expected by the end of the year. Among other things, it incorporates WCAG 2.2 and will now be used to assess conformity under both the 2016 directive on public websites and the European Accessibility Act.

The SIP has announced that RAWeb 2 and RAAM 2 will be published in February 2027. The new versions will keep the approach based on criteria, tests and methodology, but will adopt a structure aligned with that of the standard, to make them easier to use for people who know neither RGAA nor RAWeb and to reduce the gaps in scores between the framework and the standard. Community feedback gathered on GitHub will be incorporated.

Without waiting, your teams can start applying the six WCAG 2.2 criteria that the standard adds: focus not obscured, an alternative to dragging movements, target size, consistent help, avoiding redundant entry and accessible authentication. The last two directly affect banking journeys and administrative procedures: do not ask again for information that has already been entered, and do not impose a cognitive test, such as copying a distorted code, without an alternative. Training for design and development teams in early 2027 avoids producing new content under rules that are already out of date.

Action plan for digital accessibility in Luxembourg

Whichever law applies to you, the process follows the same steps. It can start this quarter, without waiting for version 2 of the frameworks.

1. Take stock of your digital services. List your websites, apps, intranets, extranets and published documents, with their language, audience and supplier. For a public body, compare your list with the inventory published on data.public.lu.
2. Identify the applicable law. For each service: the law of 28 May 2019, the law of 8 March 2023, or both. Document the borderline cases (professional clientele, microenterprise, exempt content) and have the analysis validated by your legal department.
3. Choose the framework and the sample. RAWeb 1.1 for the web, RAAM 1.1 for apps, RAPDF 1.1 for PDFs. Build a sample that covers the essential user journeys and every language version actually in use.
4. Carry out the initial audit. Have each service audited, on real devices for mobile, treating iOS and Android separately. A RAAM audit or a RAWeb audit gives you a defensible compliance score and a prioritised list of fixes.
5. Publish or correct the accessibility statement. Use the official generator, publish the statement in each language, add an accessible contact point and, for a public body, send the address to the SIP within thirty days.
6. Fix issues according to their impact. Deal first with whatever blocks an essential journey: authentication, payment, an application form, access to an official document. Write accessibility requirements into your development contracts and run accessibility acceptance testing before each release goes live.
7. Prepare for 2027. Start applying the WCAG 2.2 criteria now, follow the publication of RAWeb 2 and RAAM 2 in February 2027, and plan a new audit after every major redesign and at least an annual review of your statements.

For organisations subject to the EAA, add two tasks: drafting the information on the accessibility of the service to be included in your general terms and conditions, and organising how you will handle reports that the OSAPS may forward to you. For public bodies, bear in mind that the 2026 monitoring sample has already been published and that the audit reports will be too. If your teams develop in-house, support for developers on iOS and Android reduces the cost of fixes.

Frequently asked questions