Digitale toegankelijkheid in Luxemburg: wat SIP en OSAPS controleren in 2026

Digitale toegankelijkheid in Luxemburg steunt op twee wetten en twee autoriteiten: de wet van 28 mei 2019 voor websites en apps van de publieke sector, waarop de Service information et presse (SIP) toeziet, en de wet van 8 maart 2023, die de European Accessibility Act omzet en het markttoezicht toevertrouwt aan het OSAPS. De nationale referentiekaders RAWeb 1.1 en RAAM 1.1 vertalen de norm EN 301 549 in controleerbare criteria, voor het web en voor mobiele apps. Dit artikel legt uit wie wat moet doen, wat de gepubliceerde controles laten zien en hoe de audit van een app volgens RAAM concreet verloopt. Het is ook bedoeld voor Belgische organisaties die in het Groothertogdom actief zijn of er klanten bedienen.

Digitale toegankelijkheid in Luxemburg: wat de wet van 28 mei 2019 oplegt

De wet van 28 mei 2019 betreffende de toegankelijkheid van websites en mobiele applicaties van overheidsinstanties zet richtlijn (EU) 2016/2102 om in Luxemburgs recht. Het uitgangspunt is eenvoudig: een overheidswebsite of -app moet bruikbaar zijn voor iemand die blind, slechtziend of doof is, of een motorische of cognitieve beperking heeft, met zijn eigen hulpmiddelen. De wet bevat zelf geen lijst met technische criteria. Ze verwijst naar de geharmoniseerde Europese norm EN 301 549, in versie V3.2.1, die Luxemburg vervolgens uitwerkt in nationale referentiekaders.

Deze toegankelijkheidswet vormt de basis van het hele Luxemburgse systeem voor de publieke sector. Het officiële portaal licht de details toe op zijn pagina over de wettelijke verplichtingen inzake digitale toegankelijkheid (in het Frans), de referentietekst voor een juridische dienst of een projectverantwoordelijke. De volgende paragrafen behandelen de punten die in de praktijk de meeste vragen oproepen.

Welke organisaties eronder vallen

De wet geldt voor de Staat, de gemeenten, bepaalde publiekrechtelijke instellingen en de verenigingen die door die overheden zijn opgericht. Concreet gaat het om de ministeries en hun administraties, de gemeenten en de intercommunale samenwerkingsverbanden (syndicats de communes), de offices sociaux, die vergelijkbaar zijn met een Belgisch OCMW, en de openbare instellingen. Een omzendbrief van het ministerie van Binnenlandse Zaken van 11 augustus 2021 heeft die verplichtingen overigens nog eens in herinnering gebracht aan de gemeentebesturen, de syndicats de communes, de offices sociaux en de openbare instellingen die onder hun toezicht staan.

Mobiele apps vallen onder de wet zodra ze door of in opdracht van een overheidsinstantie worden ontworpen en ontwikkeld. Een app die bij een webbureau of een IT-dienstverlener is besteld, blijft dus de verantwoordelijkheid van de instantie die ze publiceert: die ondertekent de toegankelijkheidsverklaring en beantwoordt de klachten. Het bestek moet daar vanaf de aanbesteding rekening mee houden, net zoals een Vlaamse gemeente of een FOD dat zou doen bij een overheidsopdracht voor een nieuwe website.

Enkele categorieën vallen buiten het toepassingsgebied van de wet:

• de websites en apps van openbare omroepen;
• bepaalde niet-gouvernementele organisaties;
• de websites en apps van scholen in het basis- en secundair onderwijs en van kinderdagverblijven, behalve voor inhoud die verband houdt met essentiële administratieve functies online, zoals een inschrijving of een betaling.

Vrijgestelde inhoud

Ook bepaalde inhoud ontsnapt aan de verplichting, afhankelijk van de aard en de publicatiedatum ervan. Die uitzonderingen zijn nauwkeurig afgebakend en gedateerd; ze dekken niet zomaar een volledige oude website.

• kantoorbestanden die vóór 23 september 2018 zijn gepubliceerd, tenzij ze nodig zijn voor een lopende administratieve procedure;
• vooraf opgenomen tijdgebonden media die vóór 23 september 2020 zijn gepubliceerd;
• inhoud van intranetten en extranetten die vóór 23 september 2019 is gepubliceerd, tot de volgende ingrijpende herziening ervan;
• gearchiveerde inhoud die niet nodig is voor een lopende procedure en na 23 september 2019 niet meer is bijgewerkt;
• live uitgezonden tijdgebonden media, inhoud van derden en bepaalde reproducties van erfgoedstukken.

Een veelvoorkomend voorbeeld: een gemeente publiceert elke maand het verslag van haar gemeenteraad als pdf. De verslagen van vóór september 2018 mogen blijven zoals ze zijn, als ze voor geen enkele procedure nodig zijn. De verslagen die sindsdien zijn gepubliceerd, moeten toegankelijk zijn of een toegankelijk alternatief hebben, bijvoorbeeld een html-versie van dezelfde inhoud.

De concrete verplichtingen

• websites en apps in overeenstemming brengen met de eisen van de norm EN 301 549, beoordeeld met RAWeb voor het web en RAAM voor mobiel;
• voor elke website en elke app een toegankelijkheidsverklaring publiceren en die actueel houden;
• een toegankelijk mechanisme aanbieden om een gebrek te melden of een alternatief te vragen, de ontvangst bevestigen en binnen een maand antwoorden;
• de SIP binnen dertig dagen, zonder bijzondere formaliteiten, op de hoogte brengen van de publicatie of de bijwerking van de verklaring;
• in de verklaring vermelden dat de gebruiker zich kan wenden tot de SIP of tot de ombudsman van het Groothertogdom (de médiateur).

Onevenredige last: een afgebakende afwijking

Artikel 4 van de wet staat toe om van de eisen af te wijken wanneer ze een onevenredige last zouden opleggen. Het officiële portaal omkadert dat begrip strikt: het wordt geval per geval beoordeeld, voor een bepaalde functionaliteit of inhoud, en kan in principe geen volledige website of app dekken. De omvang van de organisatie, haar middelen en de geraamde kosten en baten voor personen met een handicap spelen mee in de beoordeling.

Twee preciseringen voorkomen heel wat fouten. Ten eerste stelt het portaal uitdrukkelijk dat een gebrek aan prioriteit, tijd of kennis geen legitieme omstandigheid is. Ten tweede ontslaat een beroep op onevenredige last u niet van de plicht om een toegankelijkheidsverklaring te publiceren, noch om waar mogelijk een toegankelijk alternatief aan te bieden; voor een essentiële taak van openbare dienstverlening moet een gelijkwaardige alternatieve dienst worden aangeboden.

De SIP en het portaal accessibilite.public.lu: wie de publieke sector controleert

De Service information et presse van de regering (SIP), de voorlichtings- en persdienst, is het orgaan dat toeziet op de wet van 28 mei 2019. De dienst hangt af van het ministerie van Staat en staat rechtstreeks onder het gezag van de eerste minister. In de eerste plaats is het de communicatiedienst van de regering. Sinds de omzetting van de richtlijn draagt de SIP echter ook het volledige beleid inzake digitale toegankelijkheid van de publieke sector: controles, referentiekaders, klachten, informatie en opleiding.

Zijn opdrachten op dat vlak vallen in vier blokken uiteen:

• periodieke controles uitvoeren van de websites en apps van de publieke sector en daarover verslag uitbrengen bij de Europese Commissie;
• de beoordelingskaders publiceren en onderhouden: RAWeb voor het web, RAAM voor mobiele apps en RAPDF voor pdf-documenten;
• klachten van gebruikers behandelen, in overleg met de betrokken organisaties;
• informeren, sensibiliseren en opleiden, onder meer via het portaal accessibilite.public.lu, een observatorium en de cursussen die samen met het Institut national d'administration publique worden aangeboden.

Drie soorten controle

Overeenkomstig uitvoeringsbesluit (EU) 2018/1524 hanteert de SIP drie vormen van controle. De diepgaande controle van een website is een volledige conformiteitsaudit volgens RAWeb: ze zegt of de site toegankelijk is en welke problemen werden vastgesteld. De controle van een mobiele app is een conformiteitsaudit volgens RAAM. De vereenvoudigde controle, ten slotte, wil non-conformiteiten opsporen en sensibiliseren, zonder dat ze toelaat een besluit te trekken over de conformiteit van de site.

De methode voor de vereenvoudigde controle is openbaar. Ze heeft betrekking op een steekproef van drie pagina's (de startpagina, een pagina met een formulier en een pagina met bijzondere inhoud zoals een video, een tabel of een complexe afbeelding), combineert 41 geautomatiseerde regels van de tool Axe met 47 RAWeb-criteria die handmatig worden gecontroleerd, en sluit downloadbare documenten uit. Zo kan de SIP veel meer websites bestrijken dan met een diepgaande audit.

Een jaarlijkse kalender en open data

De eerste controleperiode liep van 23 september 2020 tot eind 2021; sindsdien komt een periode overeen met een kalenderjaar. Het proces volgt steeds dezelfde stappen: inventaris van de websites en apps van de overheid, samenstelling van een steekproef in overleg met de belangrijkste spelers uit de gehandicaptensector, audits en daarna om de drie jaar een verslag aan de Europese Commissie. De inventarissen, de steekproeven, de auditrapporten, de toegankelijkheidsverklaringen en het overzicht van de klachten worden gepubliceerd op het open-dataportaal data.public.lu.

Die transparantie heeft een praktisch gevolg: een overheidsinstantie die in de steekproef van het jaar zit, ziet haar auditrapport gepubliceerd worden. De SIP heeft de steekproef voor 2026 gepubliceerd; nagaan of uw websites of apps erin staan, is een nuttige eerste stap.

Openbare hulpmiddelen naast de controle

Het portaal stelt een modelbestek, een auditkit, een generator voor toegankelijkheidsverklaringen en het klachtenformulier ter beschikking. De bronbestanden van de referentiekaders staan op GitHub, zodat de gemeenschap correcties kan voorstellen. In 2026 stelde de SIP ook Mia en Mil voor, twee Luxemburgstalige synthetische stemmen voor hulptechnologieën, open source en offline bruikbaar. Tot dan moesten gebruikers van schermlezers zich meestal behelpen met een Duitse stem om een Luxemburgse tekst te laten voorlezen.

RAWeb 1.1: het Luxemburgse referentiekader voor het web en de verschillen met de RGAA

RAWeb, het Référentiel d'évaluation de l'accessibilité web, is de methode waarmee wordt nagegaan of een webpagina voldoet aan de eisen van de norm EN 301 549. De versie 1.1, gepubliceerd op 6 februari 2026 (in het Frans), telt 136 controlecriteria, verdeeld over 17 thema's. Ze geldt voor alle html-inhoud (HTML4, XHTML1 en HTML5); native mobiele apps vallen onder RAAM.

RAWeb neemt inhoud over uit de Franse RGAA 4.1.2, door de SIP aangepast aan het Luxemburgse juridische kader. De eerste dertien thema's zullen iedereen die de RGAA kent bekend voorkomen: afbeeldingen, frames, kleuren, multimedia, tabellen, links, scripts, verplichte elementen, structurering van de informatie, presentatie van de informatie, formulieren, navigatie en raadpleging. RAWeb voegt er vier thema's aan toe: documentatie en toegankelijkheidsfuncties, bewerkingstools, ondersteunende diensten en realtimecommunicatie.

Waarom 136 criteria in plaats van 106

De RGAA 4.1.2 telt 106 criteria en concentreert zich op de eisen die uit de WCAG voortvloeien. De norm EN 301 549 gaat verder: ze behandelt ook de documentatie van een dienst, de tools waarmee inhoud wordt gepubliceerd, de klantenondersteuning en realtimecommunicatie. RAWeb dekt die eisen, wat de 30 extra criteria verklaart die in het Luxemburgse monitoringverslag worden vermeld. De SIP gebruikte de RGAA voor zijn diepgaande controles tot 2023 en vanaf 2024 RAWeb.

Het directe gevolg: een RGAA-audit die voor een Franse website is uitgevoerd, volstaat niet om de conformiteit van een Luxemburgse website aan te tonen. Hij dekt het grootste deel, maar laat de criteria buiten beschouwing die eigen zijn aan de norm, bijvoorbeeld de toegankelijkheid van de online help, van een supportchat of van een back-office om inhoud te publiceren. De behaalde scores zijn ook niet rechtstreeks vergelijkbaar, omdat de noemer verandert. Ons artikel over de normen en referentiekaders voor toegankelijkheid gaat dieper in op die overeenkomsten, en de pagina normen per land vat ze samen.

Voor een Belgische lezer is dat een vertrouwd verhaal in omgekeerde richting. België heeft geen eigen nationaal referentiekader en toetst rechtstreeks aan EN 301 549. Een audit die in Brussel of Gent volgens de Europese norm werd uitgevoerd, sluit inhoudelijk dus nauw aan bij RAWeb, maar levert geen score op die u zonder herberekening in een Luxemburgse toegankelijkheidsverklaring kunt overnemen.

RAPDF voor documenten

Luxemburg beschikt ook over een referentiekader voor pdf-documenten, RAPDF, dat in 2023 werd ingevoerd en in 2026 eveneens naar versie 1.1 is overgestapt. Dat is nuttig voor administraties, die veel formulieren, verslagen en beslissingen als pdf publiceren: kantoordocumenten zijn de meest aangevoerde uitzondering in de toegankelijkheidsverklaringen, en ontoegankelijke pdf's zijn de belangrijkste reden voor klachten die de SIP over de periode 2022-2024 heeft geregistreerd.

RAAM 1.1: het referentiekader voor de toegankelijkheid van mobiele apps

RAAM, het Référentiel d'évaluation de l'accessibilité des applications mobiles, is een van de bijzonderheden van Luxemburg. Weinig landen beschikken over een zo gedetailleerde openbare methode om een native app te beoordelen. De versie 1.1, gepubliceerd op 24 februari 2025 (in het Frans), telt 108 controlecriteria en maakt het mogelijk na te gaan of een app voldoet aan de norm EN 301 549 V3.2.1. Ze wordt verspreid onder de licentie CC-BY 3.0 LU.

RAAM bestrijkt de hoofdstukken van de norm die op een app betrekking hebben: generieke eisen (hoofdstuk 5), tweerichtingsspraakcommunicatie (6), videofuncties (7), niet-webdocumenten (10), software (11) en documentatie en ondersteunende diensten (12). De criteria zijn ingedeeld in vijftien thema's:

• grafische elementen, kleuren, multimedia, tabellen;
• interfacecomponenten, verplichte elementen, structurering van de informatie, presentatie van de informatie;
• formulieren, navigatie, raadpleging;
• documentatie en toegankelijkheidsfuncties, bewerkingstools, ondersteunende diensten, realtimecommunicatie.

Wat er met versie 1.1 is veranderd

De eerste versie van RAAM, gepubliceerd in juni 2021, telde 107 criteria. Versie 1.1 voegt er één aan toe, criterium 14.3, dat voortkomt uit een opsplitsing van thema 12 om de eisen leesbaarder te maken. Ze herziet ook verschillende methoden: het contrast houdt voortaan rekening met de werkelijke tekstgrootte, nieuwe tests dekken de ondertiteling van live media, en de drempel voor knipperen gaat van “minder dan 3 per seconde” naar “3 per seconde of minder”.

De methodologie heeft er een principe van niet-interferentie bij gekregen, overgenomen uit RAWeb: vrijgestelde inhoud of inhoud waarvoor een afwijking geldt, hoeft niet conform te zijn, maar mag de toegang tot de rest van het scherm niet verhinderen. Ze verduidelijkt ook hoe er met of zonder toegankelijkheidsdienst voor het toetsenbord op Android wordt getest, en hoe een tekstgrootte wordt gemeten op basis van schermafbeeldingen.

Waarom een apart kader naast het web

Bij een native app heeft de auditor bijna nooit toegang tot de broncode. Hij kan geen attribuut inspecteren zoals op een webpagina: hij controleert wat het systeem werkelijk doorgeeft aan de hulptechnologieën. De tests van RAAM steunen dus op schermlezers, de systeeminstellingen en de inspectietools van Apple en Google. Dat is een andere manier van werken, die echte toestellen en een goede kennis van elk platform vereist. RAAM is het Luxemburgse referentiekader; elders geldt dezelfde methode met het lokale referentiekader, zoals onze pagina over de audit van mobiele apps volgens RAAM uitlegt.

Toegankelijkheidsverklaring en klachten: het Luxemburgse circuit

De toegankelijkheidsverklaring is het document dat de gebruiker, de SIP en soms de pers als eerste raadplegen. Ze vermeldt een conformiteitsstatus die door een audit is vastgesteld, volgens drie niveaus die het officiële portaal definieert.

• volledige conformiteit: alle controlecriteria van het referentiekader worden nageleefd, dus een score van 100 % na audit;
• gedeeltelijke conformiteit: minstens 50 % van de controlecriteria wordt nageleefd;
• niet-conformiteit: er is geen geldige audit uitgevoerd, of minder dan 50 % van de criteria wordt nageleefd.

Naast die status somt de verklaring de ontoegankelijke inhoud op. Ze maakt daarbij een onderscheid tussen wat niet conform is, wat vrijgesteld is en wat onder onevenredige last valt, met de verantwoording en de aangeboden alternatieven. Ze beschrijft de beschikbare toegankelijkheidsfuncties, vermeldt of het om een zelfbeoordeling of een beoordeling door een derde gaat, geeft een contactadres en herinnert aan de mogelijkheid om zich tot de SIP of de ombudsman te wenden.

Waar u ze publiceert, en in welke talen

Voor een website moet de verklaring makkelijk te vinden zijn: op elke pagina moet een link staan, bijvoorbeeld in de footer. Voor een app wordt ze gepubliceerd op de website van de verantwoordelijke organisatie of in de informatie die beschikbaar is op het moment van downloaden, dus op de pagina in de App Store of op Google Play. De officiële generator maakt de verklaring aan in het Frans, het Duits, het Engels en het Luxemburgs, en raadt aan ze aan te bieden in elke taal van een meertalige website.

Na publicatie stuurt de organisatie het adres van haar verklaring naar de SIP, via accessibilite@sip.etat.lu. De generator raadt aan opnieuw te evalueren na elke grote herwerking en de verklaring minstens één keer per jaar na te lezen. Voor het opstellen zelf bespreekt ons artikel over de toegankelijkheidsverklaring de meest gemaakte fouten, in Frankrijk zowel als in Luxemburg.

Het verloop van een klacht

Neem een gebruiker die een aanvraagformulier voor een uitkering niet kan verzenden met TalkBack, omdat de knop “Verzenden” niet wordt voorgelezen. Hij wendt zich eerst tot de organisatie, via het contactpunt in de toegankelijkheidsverklaring. De organisatie moet de ontvangst bevestigen en binnen een maand na verzending antwoorden; is het probleem complex, dan mag ze een langere termijn vastleggen, op voorwaarde dat ze die verantwoordt.

Is de gebruiker niet tevreden met het antwoord, dan kan hij een klacht indienen bij de SIP via het onlineklachtenformulier, of bij de ombudsman van het Groothertogdom Luxemburg. De SIP verbindt zich ertoe uiterlijk binnen een maand per e-mail te antwoorden. In de praktijk analyseert de dienst de vraag, neemt hij contact op met de organisatie en geeft hij haar een maand om te reageren. Zolang de verklaring geen toegankelijk contactpunt biedt, slaat de organisatie zelf de eerste stap over en laat ze de klacht rechtstreeks bij de autoriteit terechtkomen.

Wat de gepubliceerde controles van 2022 tot 2024 laten zien

Luxemburg publiceert zijn resultaten met een zeldzame graad van detail. Het verslag over de controle van de toegankelijkheid van websites en apps van de publieke sector 2022-2024 (in het Frans), dat aan de Europese Commissie werd bezorgd, geeft een nauwkeurig beeld van de situatie. Alle cijfers in deze sectie komen eruit.

De trend is duidelijk: de websites gaan vooruit, van een gemiddelde score van 48 % naar 61 % in drie jaar, terwijl de mobiele apps achteruitgaan, van 49 % naar 37 %. Het verslag stelt vast dat in 2024, net als in 2021, geen enkele geauditeerde app gedeeltelijke conformiteit bereikt (in 2022 en 2023 lukte dat telkens twee apps). Mobiel is vandaag het zwakke punt van de Luxemburgse publieke sector, wat bijzondere aandacht voor RAAM rechtvaardigt.

De meest voorkomende non-conformiteiten

Bij de apps zijn de drie meest voorkomende gebreken interfacecomponenten die niet compatibel zijn met hulptechnologieën (criterium 5.1), een ongeschikte structuur van titels (criterium 7.1) en inhoud die zich niet aanpast aan de schermoriëntatie (criterium 11.9). Bij de websites, in diepgaande controle, gaat het om scripts die niet compatibel zijn met hulptechnologieën, tags die voor de opmaak worden gebruikt en slecht gestructureerde lijsten.

In de vereenvoudigde controle is het vaakst vastgestelde gebrek het ontbreken van een aanduiding van taalwissels, vóór scripts die niet met toetsenbord en muis bruikbaar zijn en onvoldoende tekstcontrast. Dat eerste resultaat is typisch Luxemburgs: een Franstalige pagina die een procedure in het Duits vermeldt of de naam van een instelling in het Luxemburgs, moet die overgang aangeven, zodat de schermlezer van stem en uitspraak wisselt. Hetzelfde aandachtspunt geldt voor tweetalige Brusselse websites die Nederlandse en Franse benamingen van diensten mengen.

Verklaringen, afwijkingen en klachten

Het verslag telt 431 toegankelijkheidsverklaringen van websites en 30 verklaringen van apps, voor 979 websites en apps in de inventaris van de publieke sector. In 2024 riep 61 % van de verklaringen een afwijking wegens onevenredige last in, een gebruik dat het officiële kader nochtans als uitzonderlijk voorstelt. De SIP ontving over de periode 20 klachten; ontoegankelijke pdf's zijn de belangrijkste reden, vóór problemen met webpagina's en apps.

In absolute cijfers zijn dat bescheiden aantallen, maar ze zijn openbaar. Voor een administratie is het risico minder een sanctie dan een gepubliceerd auditrapport met een lage score, of een verklaring die zich zonder verantwoording op onevenredige last beroept. Meer over de begeleiding van administraties leest u op onze pagina over de publieke sector.

EAA in Luxemburg: de wet van 8 maart 2023 en het OSAPS

Luxemburg heeft richtlijn (EU) 2019/882, de European Accessibility Act, omgezet met de wet van 8 maart 2023 betreffende de toegankelijkheidsvoorschriften voor producten en diensten (in het Frans), gepubliceerd in het Mémorial A nr. 133 van 15 maart 2023. Volgens artikel 36 is ze op 28 juni 2025 in werking getreden. Ze richt zich deze keer tot de marktdeelnemers, privé en publiek, die producten op de markt brengen of bepaalde diensten aan consumenten verlenen.

Welke producten en diensten eronder vallen

Aan de kant van de producten: computers en besturingssystemen voor consumenten, smartphones en tablets, betaalterminals, incheckautomaten en automaten voor vervoerbewijzen (behalve die in voertuigen zijn ingebouwd), smart-tv's en e-readers. Aan de kant van de diensten: elektronische communicatie, toegang tot audiovisuele mediadiensten, personenvervoer door de lucht, per spoor, per bus en over het water (websites, apps, elektronische tickets en informatie), bankdiensten voor consumenten, e-books, e-commerce en de beantwoording van noodcommunicatie naar 112. Ons artikel over de European Accessibility Act bespreekt dat toepassingsgebied, dat in alle lidstaten hetzelfde is.

Het OSAPS als toezichthouder

Artikel 3 van de wet richt het Office de la surveillance de l'accessibilité des produits et services (OSAPS) op, de dienst voor het toezicht op de toegankelijkheid van producten en diensten. Het staat onder het gezag van de minister die bevoegd is voor het beleid ten aanzien van personen met een handicap, vandaag het ministerie van Gezin, Solidariteit, Samenleven en Opvang. Voor producten zijn de controles toevertrouwd aan het OSAPS, de Administration des douanes et accises en de groothertogelijke politie (artikel 28, § 1). Voor diensten controleren het OSAPS en de groothertogelijke politie de conformiteit, samen met de bevoegde sectorale autoriteiten (artikel 28, § 2).

Het OSAPS is ook het aanspreekpunt voor toegankelijkheid en levert richtsnoeren en hulpmiddelen, in het bijzonder aan micro-ondernemingen. Elke natuurlijke of rechtspersoon kan er een niet-conform product of een niet-conforme dienst melden. Die melding gebeurt gratis online via MyGuichet.lu, met de mogelijkheid om een schermafbeelding of een document toe te voegen. Een vereniging van personen met een handicap kan dat als rechtspersoon doen.

Voorziene sancties

• een administratieve geldboete van 250 tot 15.000 euro, opgelegd door het OSAPS aan de marktdeelnemer die weigert documenten of informatie te verstrekken, de controles belemmert of de beslissingen van de dienst niet naleeft (artikel 32);
• een strafrechtelijke geldboete van 251 tot 500.000 euro voor de marktdeelnemer die de bepalingen van de wet overtreedt, afgestemd op de omvang en de ernst van de inbreuk (artikel 33, § 1);
• bij herhaling een geldboete van 500 tot 1.000.000 euro (artikel 33, § 2);
• een beperking of verbod op het aanbieden van een niet-conform product of het verlenen van een niet-conforme dienst, een beslissing waartegen binnen drie maanden een beroep tot hervorming (recours en réformation) kan worden ingesteld bij de administratieve rechtbank (artikel 28, § 5).

Vrijstellingen en overgangstermijnen

De wet definieert een micro-onderneming als een onderneming die minder dan tien personen tewerkstelt en waarvan de jaaromzet of het jaarlijkse balanstotaal niet meer dan 2.000.000 euro bedraagt. Micro-ondernemingen die diensten verlenen, zijn vrijgesteld van de toegankelijkheidseisen; micro-ondernemingen die producten vervaardigen of verdelen, blijven aan de eisen onderworpen, met lichtere documentatieverplichtingen. Een grotere kmo die online aan consumenten verkoopt, valt daarentegen volledig onder de wet.

Er gelden overgangstermijnen. Dienstverleners mogen de producten die ze vóór de inwerkingtreding rechtmatig gebruikten, tot 28 juni 2030 blijven gebruiken. Dienstencontracten die vóór die datum zijn gesloten, mogen ongewijzigd doorlopen tot ze verstrijken, met een maximum van vijf jaar. Selfserviceterminals die al in gebruik zijn, mogen dat blijven tot het einde van hun economische levensduur, zonder twintig jaar na hun ingebruikname te overschrijden.

Zoals overal in de Unie moet de aanbieder van een betrokken dienst ook in openbaar toegankelijke informatie, en met name in zijn algemene voorwaarden, uitleggen hoe zijn dienst aan de toegankelijkheidseisen voldoet. Dat punt wordt vaak vergeten: een webshop kan technisch in orde zijn en toch in gebreke blijven door het ontbreken van die informatie. Voor de technische beoordeling is de norm EN 301 549 de referentie; RAWeb en RAAM zijn openbare, gedetailleerde en gratis methoden om die norm toe te passen, en het OSAPS vermeldt ze trouwens bij zijn hulpmiddelen. Voor die spelers bieden wij een conformiteitsaudit volgens EN 301 549 en WCAG aan.

Voor een Belgische onderneming die vanuit Vlaanderen of Brussel een webshop of een app voor Luxemburgse consumenten uitbaat, is dit kader herkenbaar: de inhoudelijke eisen komen uit dezelfde Europese richtlijn als in België. Het verschil zit in de toezichthouder en de procedure. In het Groothertogdom komt een melding bij het OSAPS terecht, en de geldboetes zijn die van de Luxemburgse wet van 8 maart 2023.

Meertaligheid, financieel centrum, grensarbeiders: de Luxemburgse bijzonderheden

De technische eisen zijn Europees, maar bij de toepassing ervan in Luxemburg komen drie realiteiten samen die elders zelden tegelijk voorkomen. Ze wegen rechtstreeks op de kwaliteit van een audit en op de kosten van de correcties.

Vier talen in één interface

De wet van 24 februari 1984 op het taalgebruik heeft het Luxemburgs erkend als nationale taal, het Frans tot taal van de wetgeving gemaakt en het Frans, het Duits en het Luxemburgs als administratieve talen vastgelegd. Daar komt het Engels heel vaak bij in de financiële dienstverlening, de Europese instellingen en de internationale ondernemingen. Eenzelfde overheidswebsite kan dus in vier versies bestaan, en eenzelfde pagina kan verschillende talen door elkaar gebruiken.

Voor toegankelijkheid is elke taalversie volwaardige inhoud: tekstalternatieven, knoplabels, foutmeldingen, ondertitels en transcripties moeten in elke taal bestaan. De taal van elke pagina moet zijn aangegeven, en elke passage in een andere taal moet worden gemarkeerd; zoals we zagen, is dat het meest vastgestelde gebrek in de vereenvoudigde controles. RAAM 1.1 heeft overigens een voorwaarde toegevoegd over de taal van de ondertitels. Ten slotte moet een auditsteekproef de taalversies bestrijken die werkelijk worden gebruikt, anders blijven de gebreken van een secundaire vertaling onopgemerkt.

Het financieel centrum en de bankdiensten

Bankdiensten voor consumenten vallen onder de EAA. Voor een retailbank, een betalingsinstelling of een uitgever van elektronisch geld met vestiging in Luxemburg is de mobiele app vaak het belangrijkste kanaal in de klantrelatie. De knelpunten zijn bekend: sterke authenticatie met code of biometrie zonder alternatief, sessietijden die te kort zijn voor een gebruiker van een schermlezer, portefeuillegrafieken zonder tekstueel equivalent, contracten en rekeninguittreksels als pdf zonder tags, en visuele captcha's bij het openen van een rekening.

Privébanken en spelers die uitsluitend professionele klanten bedienen, moeten hun toepassingsgebied nauwkeurig analyseren, omdat de EAA zich richt op diensten die aan consumenten worden verleend. Die analyse verdient het om gedocumenteerd en door de juridische dienst gevalideerd te worden, in plaats van zomaar te worden aangenomen. Onze pagina over grote ondernemingen beschrijft hoe wij die organisaties begeleiden.

Grensarbeiders, volwaardige gebruikers

Volgens STATEC (in het Frans) telde Luxemburg in 2023 225.840 inkomende grensarbeiders, van wie 54,2 % in Frankrijk woonde, 23 % in Duitsland en 22,7 % in België. Die mensen gebruiken de Luxemburgse digitale diensten (sociale zekerheid, fiscaliteit, vervoer, bank) met toestellen en instellingen die in hun eigen land zijn geconfigureerd, soms in een andere taal dan die van de dienst.

Voor een Luxemburgse organisatie betekent dat testen met uiteenlopende configuraties, met name met schermlezers die in het Frans of het Duits zijn ingesteld. Voor een organisatie die aan beide kanten van de grens actief is, betekent het ook omgaan met verschillende regimes: de RGAA in Frankrijk, de norm EN 301 549 in België, RAWeb en RAAM in Luxemburg. Onze artikelen over digitale toegankelijkheid in België en digitale toegankelijkheid in Frankrijk stellen de twee buurlanden voor; onze consultants werken in het Frans, het Duits en het Engels.

Een mobiele app auditeren volgens RAAM: de methode stap voor stap

De testmethodologie van RAAM 1.1 (in het Engels) is openbaar en nauwkeurig. Toch laat ze de auditor heel wat praktische keuzes. Zo verloopt concreet de audit van een app van een overheidsinstantie of een onderneming, op iOS en op Android.

1. De scope en de omgeving afbakenen. We leggen de versie van de geauditeerde app vast (de gepubliceerde versie of een testbuild via TestFlight of een testtrack op Google Play), de nodige testaccounts en de fictieve gegevens om de procedures zonder risico te doorlopen. Is de app bedoeld voor een beheerde omgeving, bijvoorbeeld een vloot toestellen die door een bank of een administratie wordt beheerd, dan vraagt RAAM om te testen met de configuraties die in die omgeving werkelijk worden gebruikt.
2. De steekproef van schermen samenstellen. De methodologie legt, voor zover ze bestaan, de volgende schermen op: het startscherm, de wettelijke informatie, de authenticatie, het contact, de documentatieschermen, minstens één relevant scherm voor elk type dienst en elk hoofdgebruik (waaronder de zoekfunctie), minstens één downloadbaar document per dienst, alle schermen van een proces in meerdere stappen en de schermen van verschillende aard (datatabellen, multimedia, formulieren, realtimecommunicatie). Willekeurig gekozen schermen, goed voor minstens 10 % van de steekproef, vullen de selectie aan.
3. De echte toestellen voorbereiden. De tests gebeuren op de laatste beschikbare versie van iOS en Android, of op de vorige versie, met de versies van VoiceOver en TalkBack die bij het systeem worden geleverd. RAAM preciseert dat het niet nodig is om Android op een bepaald toestelmodel te testen. In de praktijk voorzien we minstens één smartphone per platform, en een tablet als de app die ondersteunt.
4. Testen met de schermlezer. Elk scherm wordt doorlopen met VoiceOver op iOS en TalkBack op Android, met veegbewegingen, door het scherm aan te raken en met de rotor of de leesopdrachten. Met het ondertitelpaneel van VoiceOver of de weergave van de spraakuitvoer van TalkBack kunnen we precies vastleggen wat wordt voorgelezen. We controleren of elke knop een naam, een rol en een status heeft, of de titels zijn gedeclareerd en of fout- en bevestigingsmeldingen worden voorgelezen zonder dat de focus onverwacht verspringt.
5. Testen met extern toetsenbord en schakelaar. Op iOS activeren we de volledige toetsenbordtoegang; op Android testen we eerst met alleen het toetsenbord en daarna zo nodig met Switch Access, waarbij we bijvoorbeeld Tab koppelen aan “volgende”, Shift + Tab aan “vorige”, Enter aan “selecteren” en Esc aan “terug”. Het doel is elke functie te bereiken en te activeren, zonder valkuil en in een logische volgorde.
6. Vergroting en weergave controleren. De tekstgrootte wordt verhoogd in de systeeminstellingen; op iOS raadt de methodologie aan te testen op 190 %, de waarde die het dichtst bij 200 % ligt en in het bedieningspaneel beschikbaar is. We controleren of teksten niet worden afgekapt of overlappen, of de app werkt in staande en liggende stand, en of het contrast voldoende blijft, gemeten op basis van schermafbeeldingen van het toestel.
7. De andere vormen van gebruik nagaan. We controleren de alternatieven voor complexe gebaren (slepen, knijpen, schudden), de grootte en de tussenruimte van de aanraakzones, het beheer van tijdslimieten, de video's (ondertiteling, audiodescriptie), de ingebouwde webweergaven waarin een procedure verloopt, en de documenten die vanuit de app worden gedownload. De inspectietools van Apple (Accessibility Inspector) en Google (Accessibility Scanner) en Colour Contrast Analyser vullen de analyse aan, zonder de handmatige tests ooit te vervangen.
8. De score berekenen en de niet-interferentie toepassen. Een criterium is pas gevalideerd als het wordt nageleefd op alle schermen van de steekproef waarop het van toepassing is: één scherm dat faalt, volstaat om het af te keuren. De conformiteitsscore zet de gevalideerde criteria af tegen de toepasselijke criteria. De niet-interferentiecriteria (controle over automatisch afgespeelde geluiden, geen toetsenbordval, controle over tijdslimieten, geen gevaarlijke flitsen, controle over bewegende inhoud) gelden zelfs voor vrijgestelde inhoud.
9. Rapporteren en de verklaring opstellen. Het rapport geeft per scherm de niet-gevalideerde criteria, de betrokken elementen en afzonderlijke aanbevelingen voor de iOS- en Android-teams, die met verschillende componenten werken. Het dient als basis voor de toegankelijkheidsverklaring die op de website van de organisatie of op de pagina van de app wordt gepubliceerd.

Drie valkuilen komen vaak terug. De eerste is de audit van slechts één platform: iOS en Android hebben elk hun eigen componenten, en een hybride app kan op het ene correct zijn en op het andere tekortschieten; de audits van de SIP hebben trouwens afzonderlijk betrekking op iOS- en Android-versies. De tweede is een oriëntatie die zonder verantwoording in staande stand is vergrendeld, een van de meest vastgestelde gebreken. De derde is de aangepaste component (datumkiezer, carrousel, tabbladen) die zich niet kenbaar maakt aan hulptechnologieën. Om verder te gaan dan conformiteit, kunt u met een test met gebruikers met een beperking nagaan of de gebruikerstrajecten echt bruikbaar zijn.

Wie past wat toe: organisatie, wettekst, referentiekader, controle

De onderstaande tabel vat de meest voorkomende situaties samen. Ze vervangt geen juridische analyse van uw situatie, maar helpt u snel te bepalen onder welke tekst en welke autoriteit u valt.

Eenzelfde organisatie kan onder beide wetten vallen. Een openbare vervoersmaatschappij valt bijvoorbeeld onder de wet van 2019 voor haar institutionele websites en onder de wet van 2023 voor haar diensten van personenvervoer. De pagina digitale toegankelijkheid in Luxemburg zet de belangrijkste verplichtingen en de beschikbare diensten in het land op een rij.

RAWeb 2 en RAAM 2 in 2027: anticiperen op de nieuwe norm EN 301 549

Het kader verandert binnenkort. De herziene versie van de norm EN 301 549, met nummer 4.1.1, werd op 2 september 2026 goedgekeurd door CEN en ETSI; de publicatie in het Publicatieblad van de Europese Unie wordt tegen het einde van het jaar verwacht. Ze integreert onder meer de WCAG 2.2 en dient voortaan om de conformiteit te beoordelen zowel onder de richtlijn van 2016 over overheidswebsites als onder de European Accessibility Act.

De SIP heeft aangekondigd dat RAWeb 2 en RAAM 2 in februari 2027 verschijnen (in het Engels). De nieuwe versies behouden de aanpak met criteria, tests en methodologie, maar krijgen een structuur die aansluit bij die van de norm. Zo worden ze makkelijker bruikbaar voor wie de RGAA noch RAWeb kent, en verkleinen ze de verschillen in score tussen het referentiekader en de norm. De feedback van de gemeenschap die via GitHub werd verzameld, wordt erin verwerkt.

Zonder te wachten kunnen uw teams de zes WCAG 2.2-criteria toepassen die de norm toevoegt: niet-verborgen focus, alternatief voor sleepbewegingen, grootte van de doelen, consistente hulp, vermijden van overbodige invoer en toegankelijke authenticatie. De laatste twee raken rechtstreeks aan bankprocessen en administratieve procedures: niet opnieuw vragen naar informatie die al werd ingevoerd, en geen cognitieve test opleggen, zoals het overtypen van een vervormde code, zonder alternatief. Een opleiding voor de ontwerp- en ontwikkelteams begin 2027 voorkomt dat nieuwe inhoud wordt gemaakt volgens regels die al achterhaald zijn.

Actieplan voor digitale toegankelijkheid in Luxemburg

Onder welke tekst u ook valt, de aanpak volgt dezelfde stappen. U kunt er nog dit kwartaal mee beginnen, zonder op versie 2 van de referentiekaders te wachten.

1. Breng uw digitale diensten in kaart. Maak een lijst van de websites, apps, intranetten, extranetten en gepubliceerde documenten, met hun taal, hun doelgroep en hun leverancier. Voor een overheidsinstantie vergelijkt u uw lijst met de inventaris die op data.public.lu is gepubliceerd.
2. Bepaal de toepasselijke tekst. Per dienst: de wet van 28 mei 2019, de wet van 8 maart 2023, of beide. Documenteer de grensgevallen (professionele klanten, micro-onderneming, vrijgestelde inhoud) en laat de analyse valideren door uw juridische dienst.
3. Kies het referentiekader en de steekproef. RAWeb 1.1 voor het web, RAAM 1.1 voor apps, RAPDF 1.1 voor pdf's. Stel een steekproef samen die de essentiële trajecten en alle werkelijk gebruikte taalversies dekt.
4. Voer de eerste audit uit. Laat elke dienst auditeren, voor mobiel op echte toestellen en met een onderscheid tussen iOS en Android. Een RAAM-audit of een RAWeb-audit levert een onderbouwde conformiteitsscore op en een lijst met geprioriteerde correcties.
5. Publiceer of verbeter de toegankelijkheidsverklaring. Gebruik de officiële generator, publiceer de verklaring in elke taal, voeg een toegankelijk contactpunt toe en bezorg, als overheidsinstantie, het adres binnen dertig dagen aan de SIP.
6. Corrigeer volgens de impact. Pak eerst aan wat een essentieel traject blokkeert: authenticatie, betaling, aanvraagformulier, raadpleging van een officieel document. Neem de toegankelijkheidseisen op in uw ontwikkelcontracten en laat de toegankelijkheid controleren bij elke oplevering, vóór elke ingebruikname.
7. Bereid 2027 voor. Pas nu al de WCAG 2.2-criteria toe, volg de publicatie van RAWeb 2 en RAAM 2 in februari 2027 op, en plan een nieuwe audit na elke grote herwerking en minstens één jaarlijkse herlezing van uw verklaringen.

Valt u onder de EAA, voeg dan twee taken toe: de informatie over de toegankelijkheid van de dienst opstellen die in uw algemene voorwaarden moet komen, en de behandeling organiseren van meldingen die het OSAPS u zou kunnen bezorgen. Voor overheidsinstanties: houd er rekening mee dat de controlesteekproef voor 2026 al is gepubliceerd en dat de auditrapporten dat ook zullen worden. Ontwikkelen uw teams zelf, dan verlaagt een begeleiding van de ontwikkelaars op iOS en Android de kosten van de correcties.

Veelgestelde vragen