Accessibilité numérique au Luxembourg : ce que le SIP et l'OSAPS vérifient en 2026

L'accessibilité numérique au Luxembourg repose sur deux lois et deux autorités : la loi du 28 mai 2019 pour les sites et applications du secteur public, contrôlée par le Service information et presse (SIP), et la loi du 8 mars 2023, qui transpose l'European Accessibility Act et confie la surveillance du marché à l'OSAPS. Les référentiels nationaux RAWeb 1.1 et RAAM 1.1 traduisent la norme EN 301 549 en critères vérifiables, pour le web comme pour les applications mobiles. Cet article détaille qui doit faire quoi, ce que montrent les contrôles publiés, et comment se déroule concrètement l'audit d'une application selon le RAAM.

Accessibilité numérique au Luxembourg : ce qu'impose la loi du 28 mai 2019

La loi du 28 mai 2019 relative à l'accessibilité des sites internet et des applications mobiles des organismes du secteur public transpose la directive (UE) 2016/2102. Son principe est simple : un site ou une application publique doit pouvoir être utilisé par une personne aveugle, malvoyante, sourde, ayant un handicap moteur ou cognitif, avec ses propres outils. La loi ne contient pas elle-même de liste de critères techniques. Elle renvoie à la norme européenne harmonisée EN 301 549, dans sa version V3.2.1, que le Luxembourg décline ensuite en référentiels nationaux.

Cette loi accessibilité Luxembourg est la base de tout le dispositif applicable au secteur public. Le portail officiel en présente le détail sur sa page consacrée aux obligations légales d'accessibilité numérique, qui constitue la lecture de référence pour un service juridique ou un responsable de projet. Les paragraphes qui suivent en reprennent les points qui posent le plus de questions sur le terrain.

Les organismes visés

Sont concernés l'État, les communes, certains organismes de droit public ainsi que les associations formées par ces autorités. En pratique, cela couvre les ministères et leurs administrations, les communes et syndicats de communes, les offices sociaux et les établissements publics. Une circulaire du ministère de l'Intérieur du 11 août 2021 a d'ailleurs rappelé ces obligations aux administrations communales, aux syndicats de communes, aux offices sociaux et aux établissements publics placés sous leur surveillance.

Les applications mobiles entrent dans le champ dès lors qu'elles sont conçues et développées par un organisme public ou pour son compte. Une application commandée à une agence ou à un prestataire informatique reste donc sous la responsabilité de l'organisme qui la publie : c'est lui qui signe la déclaration d'accessibilité et qui répond aux réclamations. Le cahier des charges doit en tenir compte dès l'appel d'offres.

Quelques catégories sont exclues du champ de la loi :

• les sites et applications des diffuseurs du service public ;
• certaines organisations non gouvernementales ;
• les sites et applications des établissements scolaires de l'enseignement primaire et secondaire et des crèches, sauf pour les contenus liés aux fonctions administratives essentielles en ligne, comme une inscription ou un paiement.

Les contenus exemptés

Certains contenus échappent aussi à l'obligation, en fonction de leur nature et de leur date de publication. Ces exemptions sont précises et datées ; elles ne couvrent pas l'ensemble d'un site ancien.

• les fichiers bureautiques publiés avant le 23 septembre 2018, sauf s'ils sont nécessaires à une démarche administrative active ;
• les médias temporels préenregistrés publiés avant le 23 septembre 2020 ;
• les contenus d'intranet et d'extranet publiés avant le 23 septembre 2019, jusqu'à leur prochaine révision substantielle ;
• les contenus archivés qui ne sont pas nécessaires à une démarche active et n'ont pas été mis à jour après le 23 septembre 2019 ;
• les médias temporels en direct, les contenus de tiers et certaines reproductions de pièces de patrimoine.

Un exemple fréquent : une commune publie chaque mois le compte rendu de son conseil communal en PDF. Les comptes rendus antérieurs à septembre 2018 peuvent rester en l'état s'ils ne servent à aucune démarche. Ceux publiés depuis doivent être accessibles, ou disposer d'une alternative accessible, par exemple une version HTML du même contenu.

Les obligations concrètes

• rendre les sites et applications conformes aux exigences de la norme EN 301 549, évaluées avec le RAWeb pour le web et le RAAM pour le mobile ;
• publier une déclaration d'accessibilité pour chaque site et chaque application, et la tenir à jour ;
• proposer un mécanisme accessible pour signaler un défaut ou demander une alternative, accuser réception et répondre dans un délai d'un mois ;
• informer le SIP de la publication ou de la mise à jour de la déclaration, sans formalité particulière, dans les trente jours ;
• mentionner dans la déclaration la possibilité de saisir le SIP ou le médiateur du Grand-Duché.

La charge disproportionnée, une dérogation encadrée

L'article 4 de la loi permet de déroger aux exigences lorsqu'elles imposeraient une charge disproportionnée. Le portail officiel encadre strictement cette notion : elle s'apprécie au cas par cas, pour une fonctionnalité ou un contenu donné, et ne peut en principe pas couvrir un site ou une application entière. La taille de l'organisme, ses ressources, ainsi que les coûts et les bénéfices estimés pour les personnes handicapées entrent dans l'évaluation.

Deux précisions évitent bien des erreurs. D'abord, le portail indique explicitement que le manque de priorité, de temps ou de connaissances ne constitue pas une circonstance légitime. Ensuite, invoquer la charge disproportionnée ne dispense pas de publier une déclaration d'accessibilité, ni de proposer une alternative accessible lorsque c'est possible ; pour une mission de service public essentielle, un service alternatif équivalent doit être offert.

Le SIP et le portail accessibilite.public.lu : qui contrôle le secteur public

Le Service information et presse du gouvernement (SIP) est l'organe chargé du suivi de la loi du 28 mai 2019. Rattaché au ministère d'État et placé sous l'autorité directe du Premier ministre, il est d'abord le service de communication du gouvernement. Il porte aussi, depuis la transposition de la directive, l'ensemble de la politique d'accessibilité numérique du secteur public : contrôles, référentiels, réclamations, information et formation.

Ses missions dans ce domaine se répartissent en quatre blocs :

• exécuter des contrôles périodiques des sites et applications du secteur public et en rendre compte à la Commission européenne ;
• publier et maintenir les référentiels d'évaluation : RAWeb pour le web, RAAM pour les applications mobiles, RAPDF pour les documents PDF ;
• instruire les réclamations des usagers, en concertation avec les organismes concernés ;
• informer, sensibiliser et former, notamment au travers du portail accessibilite.public.lu, d'un observatoire et des cours proposés avec l'Institut national d'administration publique.

Trois types de contrôle

Conformément à la décision d'exécution (UE) 2018/1524, le SIP pratique trois formes de contrôle. Le contrôle approfondi d'un site est un audit de conformité complet selon le RAWeb : il dit si le site est accessible et quels problèmes ont été relevés. Le contrôle d'une application mobile est un audit de conformité selon le RAAM. Le contrôle simplifié, enfin, vise à détecter des non-conformités et à sensibiliser, sans permettre de conclure sur la conformité du site.

La méthode de contrôle simplifié est publiée. Elle porte sur un échantillon de trois pages (la page d'accueil, une page comportant un formulaire, une page comportant un contenu particulier comme une vidéo, un tableau ou une image complexe), combine 41 règles automatisées de l'outil Axe et 47 critères du RAWeb vérifiés manuellement, et exclut les documents téléchargeables. Elle permet de couvrir beaucoup plus de sites que l'audit approfondi.

Un calendrier annuel et des données ouvertes

La première période de contrôle a couru du 23 septembre 2020 à la fin de 2021 ; depuis, une période correspond à une année civile. Le processus suit toujours les mêmes étapes : inventaire des sites et applications publics, constitution d'un échantillon décidé avec les principaux acteurs du secteur du handicap, audits, puis rapport à la Commission européenne tous les trois ans. Les inventaires, les échantillons, les rapports d'audit, les déclarations d'accessibilité et l'historique des réclamations sont publiés sur le portail de données ouvertes data.public.lu.

Cette transparence a une conséquence pratique : un organisme public qui figure dans l'échantillon de l'année verra son rapport d'audit publié. Le SIP a publié l'échantillon 2026 ; vérifier si vos sites ou applications y figurent est une première démarche utile.

Des outils publics au-delà du contrôle

Le portail met à disposition un modèle de cahier des charges, un kit d'audit, un générateur de déclaration d'accessibilité et le formulaire de réclamation. Les sources des référentiels sont publiées sur GitHub, ce qui permet à la communauté de proposer des corrections. En 2026, le SIP a aussi présenté Mia et Mil, deux voix de synthèse en luxembourgeois conçues pour les technologies d'assistance, open source et utilisables hors connexion : jusqu'ici, les utilisateurs de lecteurs d'écran devaient le plus souvent se contenter d'une voix allemande pour lire un texte luxembourgeois.

Le RAWeb 1.1 : le référentiel web luxembourgeois et ses différences avec le RGAA

Le RAWeb, référentiel d'évaluation de l'accessibilité web, est la méthode utilisée pour vérifier qu'une page web respecte les exigences de la norme EN 301 549. Sa version 1.1, publiée le 6 février 2026, compte 136 critères de contrôle répartis en 17 thématiques. Elle s'applique à tout contenu HTML (HTML4, XHTML1 et HTML5) ; les applications mobiles natives relèvent du RAAM.

Le RAWeb reprend des contenus issus du RGAA 4.1.2 français, adaptés par le SIP au cadre juridique luxembourgeois. Les treize premières thématiques sont familières à quiconque connaît le RGAA : images, cadres, couleurs, multimédia, tableaux, liens, scripts, éléments obligatoires, structuration de l'information, présentation de l'information, formulaires, navigation et consultation. Le RAWeb ajoute quatre thématiques : documentation et fonctionnalités d'accessibilité, outils d'édition, services d'assistance, et communication en temps réel.

Pourquoi 136 critères au lieu de 106

Le RGAA 4.1.2 compte 106 critères et se concentre sur les exigences issues des WCAG. La norme EN 301 549 va plus loin : elle traite aussi de la documentation d'un service, des outils qui permettent de publier du contenu, du support client et des communications en temps réel. Le RAWeb couvre ces exigences, ce qui explique les 30 critères supplémentaires mentionnés dans le rapport de suivi luxembourgeois. Le SIP a utilisé le RGAA pour ses contrôles approfondis jusqu'en 2023, puis le RAWeb à partir de 2024.

Conséquence directe : un audit RGAA réalisé pour un site français ne suffit pas à établir la conformité d'un site luxembourgeois. Il en couvre l'essentiel, mais laisse de côté les critères propres à la norme, par exemple l'accessibilité de l'aide en ligne, d'un chat de support ou d'un back-office de publication. Les taux obtenus ne sont pas non plus directement comparables, puisque le dénominateur change. Notre article sur les normes et référentiels d'accessibilité détaille ces correspondances, et la page référentiels par pays les résume.

Le RAPDF pour les documents

Le Luxembourg dispose aussi d'un référentiel dédié aux documents PDF, le RAPDF, introduit en 2023 et passé lui aussi en version 1.1 en 2026. C'est un point utile pour les administrations, qui publient de nombreux formulaires, rapports et délibérations en PDF : les documents bureautiques représentent la première exemption déclarée dans les déclarations d'accessibilité, et les PDF inaccessibles sont le premier motif de réclamation recensé par le SIP sur 2022-2024.

Le RAAM 1.1 : le référentiel pour l'accessibilité des applications mobiles

Le RAAM, référentiel d'évaluation de l'accessibilité des applications mobiles, est l'une des particularités du Luxembourg. Peu de pays disposent d'une méthode publique aussi détaillée pour évaluer une application native. Sa version 1.1, publiée le 24 février 2025, compte 108 critères de contrôle et permet de vérifier qu'une application respecte la norme EN 301 549 V3.2.1. Elle est diffusée sous licence CC-BY 3.0 LU.

Le RAAM couvre les chapitres de la norme qui concernent une application : exigences génériques (chapitre 5), communication vocale bidirectionnelle (6), fonctionnalités vidéo (7), documents non web (10), logiciels (11), documentation et services d'assistance (12). Ses critères sont organisés en quinze thématiques :

• éléments graphiques, couleurs, multimédia, tableaux ;
• composants d'interface, éléments obligatoires, structuration de l'information, présentation de l'information ;
• formulaires, navigation, consultation ;
• documentation et fonctionnalités d'accessibilité, outils d'édition, services d'assistance, communication en temps réel.

Ce qui a changé avec la version 1.1

La première version du RAAM, publiée en juin 2021, comptait 107 critères. La version 1.1 en ajoute un, le critère 14.3, issu d'un découpage de la thématique 12 pour rendre les exigences plus lisibles. Elle revoit aussi plusieurs méthodes : le contraste tient désormais compte de la taille réelle du texte, de nouveaux tests couvrent les sous-titres des médias en direct, et le seuil de clignotement passe de « moins de 3 par seconde » à « 3 par seconde ou moins ».

La méthodologie a gagné un principe de non-interférence, repris du RAWeb : un contenu exempté ou dérogé n'a pas à être conforme, mais il ne doit pas empêcher l'accès au reste de l'écran. Elle précise aussi comment tester avec ou sans service d'accessibilité clavier sur Android, et comment mesurer une taille de texte à partir de captures d'écran.

Pourquoi un référentiel distinct du web

Sur une application native, l'auditeur n'a presque jamais accès au code source. Il ne peut pas inspecter un attribut comme sur une page web : il vérifie ce que le système expose réellement aux technologies d'assistance. Les tests du RAAM s'appuient donc sur les lecteurs d'écran, les réglages du système et les outils d'inspection fournis par Apple et Google. C'est une autre façon de travailler, qui exige des appareils réels et une bonne connaissance de chaque plateforme. Le RAAM est le référentiel luxembourgeois ; ailleurs, la même méthode s'applique avec le référentiel local, comme l'explique notre page audit d'application mobile selon le RAAM.

Déclaration d'accessibilité et réclamations : le circuit luxembourgeois

La déclaration d'accessibilité est la pièce que l'usager, le SIP et parfois la presse consultent en premier. Elle indique un état de conformité établi par un audit, selon trois niveaux définis par le portail officiel.

• conformité totale : tous les critères de contrôle du référentiel sont respectés, soit un taux de 100 % après audit ;
• conformité partielle : au moins 50 % des critères de contrôle sont respectés ;
• non-conformité : aucun audit valable n'a été réalisé, ou moins de 50 % des critères sont respectés.

Au-delà de cet état, la déclaration liste les contenus non accessibles en distinguant ce qui est non conforme, ce qui est exempté et ce qui relève d'une charge disproportionnée, avec la justification et les alternatives proposées. Elle décrit les fonctionnalités d'accessibilité disponibles, précise s'il s'agit d'une autoévaluation ou d'une évaluation par un tiers, donne une adresse de contact et rappelle la possibilité de saisir le SIP ou le médiateur.

Où la publier, et dans quelles langues

Pour un site, la déclaration doit être facile à trouver : un lien doit figurer sur chaque page, par exemple dans le pied de page. Pour une application, elle se publie sur le site de l'organisme responsable ou dans les informations disponibles au moment du téléchargement, c'est-à-dire la fiche de l'App Store ou de Google Play. Le générateur officiel produit la déclaration en français, en allemand, en anglais et en luxembourgeois, et recommande de la proposer dans chaque langue d'un site multilingue.

Après publication, l'organisme envoie l'adresse de sa déclaration au SIP, à accessibilite@sip.etat.lu. Le générateur recommande de réévaluer après toute refonte importante et de relire la déclaration au moins une fois par an. Pour la rédaction elle-même, notre article sur la déclaration d'accessibilité détaille les erreurs les plus fréquentes, en France comme au Luxembourg.

Le parcours d'une réclamation

Prenons un usager qui ne parvient pas à valider un formulaire de demande d'allocation avec TalkBack, parce que le bouton « Envoyer » n'est pas annoncé. Il s'adresse d'abord à l'organisme, via le contact indiqué dans la déclaration d'accessibilité. L'organisme doit accuser réception et répondre dans un délai d'un mois à compter de l'envoi ; si le problème est complexe, il peut fixer un délai plus long, à condition de le justifier.

Si la réponse ne le satisfait pas, l'usager peut saisir le SIP au moyen de son formulaire de réclamation en ligne, ou le médiateur du Grand-Duché de Luxembourg. Le SIP s'engage à répondre par e-mail dans un délai d'un mois au plus tard. Dans la pratique, il analyse la demande, contacte l'organisme et lui laisse un mois pour réagir. Tant que la déclaration ne propose pas de contact accessible, l'organisme se prive de la première étape et laisse la réclamation remonter directement à l'autorité.

Ce que montrent les contrôles publiés pour 2022 à 2024

Le Luxembourg publie ses résultats avec un niveau de détail rare. Le rapport sur le contrôle de l'accessibilité des sites et applications du secteur public 2022-2024, transmis à la Commission européenne, donne une image précise de la situation. Tous les chiffres de cette section en sont issus.

La tendance est nette : les sites progressent, de 48 % à 61 % de score moyen en trois ans, tandis que les applications mobiles reculent, de 49 % à 37 %. Le rapport relève qu'en 2024, comme en 2021, aucune application auditée n'atteint la conformité partielle (deux y parvenaient en 2022 et en 2023). Le mobile est aujourd'hui le point faible du secteur public luxembourgeois, ce qui justifie une attention particulière au RAAM.

Les non-conformités les plus fréquentes

Sur les applications, les trois défauts les plus fréquents sont des composants d'interface incompatibles avec les technologies d'assistance (critère 5.1), une structure de titres inadaptée (critère 7.1) et des contenus qui ne s'adaptent pas à l'orientation de l'écran (critère 11.9). Sur les sites, en contrôle approfondi, ce sont des scripts incompatibles avec les technologies d'assistance, des balises utilisées à des fins de présentation et des listes mal structurées.

En contrôle simplifié, le défaut le plus fréquent est l'absence d'indication des changements de langue, devant les scripts non utilisables au clavier et à la souris et les contrastes de texte insuffisants. Ce premier résultat est très luxembourgeois : une page en français qui cite une démarche en allemand ou un nom d'institution en luxembourgeois doit signaler ce passage pour que le lecteur d'écran change de voix et de prononciation.

Déclarations, dérogations et réclamations

Le rapport recense 431 déclarations d'accessibilité de sites et 30 déclarations d'applications, pour 979 sites et applications identifiés dans l'inventaire du secteur public. En 2024, 61 % des déclarations invoquaient une dérogation pour charge disproportionnée, un usage que le cadre officiel présente pourtant comme exceptionnel. Le SIP a reçu 20 réclamations sur la période ; les PDF inaccessibles en sont le premier motif, devant les problèmes de pages web et d'applications.

Ces chiffres sont modestes en valeur absolue, mais ils sont publics. Pour une administration, le risque est moins une sanction qu'un rapport d'audit publié qui montre un score faible, ou une déclaration qui invoque une charge disproportionnée sans justification. Pour en savoir plus sur l'accompagnement des administrations, consultez notre page secteur public.

EAA Luxembourg : la loi du 8 mars 2023 et l'OSAPS

Le Luxembourg a transposé la directive (UE) 2019/882, dite European Accessibility Act, par la loi du 8 mars 2023 relative aux exigences en matière d'accessibilité applicables aux produits et services, publiée au Mémorial A n° 133 du 15 mars 2023. Selon son article 36, elle est entrée en vigueur le 28 juin 2025. Elle concerne cette fois les acteurs économiques, privés comme publics, qui mettent sur le marché des produits ou fournissent aux consommateurs des services visés.

Produits et services concernés

Côté produits : ordinateurs et systèmes d'exploitation grand public, smartphones et tablettes, terminaux de paiement, bornes d'enregistrement et automates de vente de titres de transport (hors ceux embarqués dans les véhicules), téléviseurs connectés et liseuses. Côté services : communications électroniques, accès aux services de médias audiovisuels, transport de passagers aérien, ferroviaire, par autobus et par voie navigable (sites, applications, billetterie électronique et informations), services bancaires aux consommateurs, livres numériques, commerce électronique et réponse aux communications d'urgence vers le 112. Notre article sur l'European Accessibility Act détaille ce périmètre commun à tous les États membres.

L'OSAPS, autorité de surveillance

L'article 3 de la loi crée l'Office de la surveillance de l'accessibilité des produits et services (OSAPS), placé sous l'autorité du ministre ayant la politique pour personnes handicapées dans ses attributions, aujourd'hui le ministère de la Famille, des Solidarités, du Vivre ensemble et de l'Accueil. Pour les produits, les contrôles sont confiés à l'OSAPS, à l'Administration des douanes et accises et à la Police grand-ducale (article 28, paragraphe 1). Pour les services, l'OSAPS et la Police grand-ducale contrôlent la conformité, avec les autorités sectorielles compétentes (article 28, paragraphe 2).

L'OSAPS sert aussi de point de contact sur l'accessibilité et fournit des lignes directrices et des outils, en particulier aux microentreprises. Toute personne physique ou morale peut lui signaler la non-conformité d'un produit ou d'un service. Le signalement se fait en ligne via MyGuichet.lu, gratuitement, avec la possibilité de joindre une capture d'écran ou un document. Une association de personnes handicapées peut le faire au titre de personne morale.

Sanctions prévues

• amende administrative de 250 à 15 000 euros prononcée par l'OSAPS contre l'opérateur qui refuse de fournir des documents ou informations, fait obstacle aux contrôles ou ne respecte pas les décisions de l'Office (article 32) ;
• amende pénale de 251 à 500 000 euros pour l'opérateur économique qui enfreint les dispositions visées par la loi, modulée selon l'étendue et la gravité du manquement (article 33, paragraphe 1) ;
• en cas de récidive, amende de 500 à 1 000 000 euros (article 33, paragraphe 2) ;
• restriction ou interdiction de la mise à disposition d'un produit ou de la fourniture d'un service non conforme, décision contestable par un recours en réformation devant le tribunal administratif dans un délai de trois mois (article 28, paragraphe 5).

Exemptions et délais de transition

La loi définit la microentreprise comme une entreprise qui emploie moins de dix personnes et dont le chiffre d'affaires annuel ou le total du bilan annuel n'excède pas 2 000 000 euros. Les microentreprises qui fournissent des services sont exemptées des exigences d'accessibilité ; celles qui fabriquent ou distribuent des produits restent soumises aux exigences, avec des obligations documentaires allégées. Une PME de plus grande taille qui vend en ligne aux consommateurs est en revanche pleinement concernée.

Des délais de transition s'appliquent. Les prestataires de services peuvent continuer d'utiliser jusqu'au 28 juin 2030 les produits qu'ils utilisaient légalement avant l'entrée en vigueur. Les contrats de services conclus avant cette date peuvent se poursuivre sans modification jusqu'à leur expiration, dans la limite de cinq ans. Les terminaux en libre-service déjà en service peuvent le rester jusqu'à la fin de leur vie économique, sans dépasser vingt ans après leur mise en service.

Comme partout dans l'Union, le fournisseur d'un service visé doit aussi expliquer, dans des informations accessibles au public et notamment dans ses conditions générales, comment son service satisfait aux exigences d'accessibilité. Ce point est souvent oublié : un site marchand peut être techniquement correct et rester en défaut faute de cette information. Pour l'évaluation technique, la référence est la norme EN 301 549 ; le RAWeb et le RAAM constituent des méthodes publiques, détaillées et gratuites pour la mettre en œuvre, que l'OSAPS cite d'ailleurs parmi ses ressources. Nous proposons pour ces acteurs un audit de conformité EN 301 549 et WCAG.

Multilinguisme, place financière, frontaliers : les spécificités luxembourgeoises

Les exigences techniques sont européennes, mais leur mise en œuvre au Luxembourg rencontre trois réalités que l'on retrouve rarement réunies ailleurs. Elles pèsent directement sur la qualité d'un audit et sur le coût des corrections.

Quatre langues dans une même interface

La loi du 24 février 1984 sur le régime des langues a reconnu le luxembourgeois comme langue nationale, fait du français la langue de la législation et retenu le français, l'allemand et le luxembourgeois comme langues administratives. L'anglais s'y ajoute très souvent dans les services financiers, les institutions européennes et les entreprises internationales. Un même site public peut donc exister en quatre versions, et une même page mélanger plusieurs langues.

Pour l'accessibilité, chaque version linguistique est un contenu à part entière : textes alternatifs, intitulés de boutons, messages d'erreur, sous-titres et transcriptions doivent exister dans chaque langue. La langue de chaque page doit être déclarée, et chaque passage dans une autre langue signalé ; c'est, on l'a vu, le défaut le plus fréquent relevé par les contrôles simplifiés. Le RAAM 1.1 a d'ailleurs ajouté une condition sur la langue des sous-titres. Enfin, un échantillon d'audit doit couvrir les versions linguistiques réellement utilisées, faute de quoi les défauts d'une traduction secondaire passent inaperçus.

La place financière et les services bancaires

Les services bancaires aux consommateurs figurent dans le champ de l'EAA. Pour une banque de détail, un établissement de paiement ou un émetteur de monnaie électronique établi au Luxembourg, l'application mobile est souvent le premier canal de relation client. Les points de blocage sont connus : authentification forte par code ou biométrie sans alternative, délais de session trop courts pour un utilisateur de lecteur d'écran, graphiques de portefeuille sans équivalent textuel, contrats et relevés en PDF non balisés, captchas visuels lors de l'ouverture de compte.

Les banques privées et les acteurs qui ne servent que des clients professionnels doivent analyser précisément leur périmètre, car l'EAA vise les services fournis aux consommateurs. Cette analyse mérite d'être documentée et validée par le service juridique plutôt que présumée. Notre page grands comptes présente l'accompagnement de ces organisations.

Les frontaliers, des usagers à part entière

Selon le STATEC, le Luxembourg comptait 225 840 salariés frontaliers entrants en 2023, dont 54,2 % résidant en France, 23 % en Allemagne et 22,7 % en Belgique. Ces personnes utilisent les services numériques luxembourgeois (sécurité sociale, fiscalité, transport, banque) avec des appareils et des réglages configurés dans leur pays, parfois dans une autre langue que celle du service.

Pour une organisation luxembourgeoise, cela implique de tester avec des configurations variées, notamment des lecteurs d'écran réglés en français ou en allemand. Pour une organisation qui opère des deux côtés de la frontière, cela signifie aussi composer avec plusieurs régimes : RGAA en France, norme EN 301 549 en Belgique, RAWeb et RAAM au Luxembourg. Nos articles sur l'accessibilité numérique en Belgique et l'accessibilité numérique en France présentent les deux voisins ; nos consultants travaillent en français, en allemand et en anglais.

Auditer une application mobile selon le RAAM : la méthode pas à pas

La méthodologie de test du RAAM 1.1 est publique et précise. Elle laisse toutefois de nombreux choix pratiques à l'auditeur. Voici comment se déroule, concrètement, l'audit d'une application d'organisme public ou d'entreprise, sur iOS et sur Android.

1. Cadrer le périmètre et l'environnement. On fixe la version de l'application auditée (version publiée ou build de test via TestFlight ou une piste de test Google Play), les comptes de test nécessaires et les données fictives pour parcourir les démarches sans risque. Si l'application est destinée à un environnement géré, par exemple une flotte d'appareils administrée par une banque ou une administration, le RAAM demande de tester avec les configurations réellement utilisées dans cet environnement.
2. Constituer l'échantillon d'écrans. La méthodologie impose, lorsqu'ils existent, l'écran d'accueil, les informations légales, l'authentification, le contact, les écrans de documentation, au moins un écran pertinent pour chaque type de service et usage principal (dont la recherche), au moins un document téléchargeable par service, tous les écrans d'un processus en plusieurs étapes et les écrans de nature différente (tableaux de données, multimédia, formulaires, communication en temps réel). Des écrans tirés au hasard, représentant au moins 10 % de l'échantillon, complètent la sélection.
3. Préparer les appareils réels. Les tests se font sur la dernière version disponible d'iOS et d'Android, ou sur la version précédente, avec les versions de VoiceOver et TalkBack livrées avec le système. Le RAAM précise qu'il n'est pas nécessaire de tester Android sur un modèle d'appareil particulier. En pratique, on prévoit au moins un smartphone de chaque plateforme, et une tablette si l'application la prend en charge.
4. Tester au lecteur d'écran. Chaque écran est parcouru avec VoiceOver sur iOS et TalkBack sur Android, par gestes de balayage, par exploration tactile et avec le rotor ou les commandes de lecture. Le panneau de sous-titres de VoiceOver ou l'affichage de la sortie vocale de TalkBack permettent de consigner exactement ce qui est annoncé. On vérifie que chaque bouton a un nom, un rôle et un état, que les titres sont déclarés, que les messages d'erreur et de confirmation sont restitués sans déplacer le focus de manière inattendue.
5. Tester au clavier externe et au contacteur. Sur iOS, on active l'accès complet au clavier ; sur Android, on teste d'abord avec le seul clavier, puis avec Switch Access si nécessaire, en associant par exemple Tab à « suivant », Maj + Tab à « précédent », Entrée à « sélectionner » et Échap à « retour ». L'objectif est d'atteindre et d'activer chaque fonction, sans piège et dans un ordre logique.
6. Contrôler l'agrandissement et l'affichage. La taille de texte est augmentée dans les réglages du système ; sur iOS, la méthodologie recommande de tester à 190 %, valeur la plus proche de 200 % disponible dans le centre de contrôle. On vérifie que les textes ne sont ni tronqués ni superposés, que l'application fonctionne en mode portrait et paysage, et que le contraste reste suffisant, mesuré à partir de captures d'écran de l'appareil.
7. Vérifier les autres usages. On contrôle les alternatives aux gestes complexes (glisser, pincer, secouer), la taille et l'espacement des zones tactiles, la gestion des délais, les vidéos (sous-titres, audiodescription), les vues web intégrées qui portent une démarche, et les documents téléchargés depuis l'application. Les outils d'inspection d'Apple (Accessibility Inspector) et de Google (Accessibility Scanner) et Colour Contrast Analyser complètent l'analyse, sans jamais remplacer les tests manuels.
8. Calculer le taux et appliquer la non-interférence. Un critère n'est validé que s'il est respecté sur tous les écrans de l'échantillon où il s'applique : un seul écran en échec suffit à l'invalider. Le taux de conformité rapporte les critères validés aux critères applicables. Les critères de non-interférence (contrôle des sons déclenchés automatiquement, absence de piège au clavier, maîtrise des limites de temps, absence de flashs dangereux, contrôle des contenus en mouvement) s'appliquent même aux contenus exemptés.
9. Restituer et rédiger la déclaration. Le rapport livre, écran par écran, les critères non validés, les éléments en cause et des recommandations distinctes pour les équipes iOS et Android, qui utilisent des composants différents. Il sert de base à la déclaration d'accessibilité à publier sur le site de l'organisme ou dans la fiche de l'application.

Trois pièges reviennent souvent. Le premier est l'audit d'une seule plateforme : iOS et Android ont leurs propres composants, et une application hybride peut être correcte sur l'une et défaillante sur l'autre ; les audits du SIP portent d'ailleurs séparément sur des versions iOS et Android. Le deuxième est l'orientation bloquée en portrait sans justification, l'un des défauts les plus fréquents relevés. Le troisième est le composant personnalisé (sélecteur de date, carrousel, onglets) qui ne s'expose pas aux technologies d'assistance. Pour aller au-delà de la conformité, un test avec des utilisateurs en situation de handicap permet de vérifier que les parcours sont réellement utilisables.

Qui applique quoi : organisation, texte, référentiel, contrôle

Le tableau ci-dessous résume les situations les plus courantes. Il ne remplace pas une analyse juridique de votre périmètre, mais il permet d'identifier rapidement le texte et l'autorité dont vous relevez.

Une même organisation peut relever des deux lois. Un opérateur public de transport, par exemple, entre dans le champ de la loi de 2019 pour ses sites institutionnels et dans celui de la loi de 2023 pour ses services de transport de passagers. La page accessibilité numérique au Luxembourg rappelle les obligations principales et les prestations disponibles dans le pays.

RAWeb 2 et RAAM 2 en 2027 : anticiper la nouvelle norme EN 301 549

Le cadre va évoluer à court terme. La version révisée de la norme EN 301 549, numérotée 4.1.1, a été approuvée le 2 septembre 2026 par le CEN et l'ETSI ; sa publication au Journal officiel de l'Union européenne est attendue d'ici la fin de l'année. Elle intègre notamment les WCAG 2.2 et sert désormais à évaluer la conformité tant au titre de la directive de 2016 sur les sites publics qu'au titre de l'European Accessibility Act.

Le SIP a annoncé la publication du RAWeb 2 et du RAAM 2 en février 2027. Les nouvelles versions conserveront l'approche par critères, tests et méthodologie, mais adopteront une structure alignée sur celle de la norme, afin d'en faciliter l'usage par des personnes qui ne connaissent ni le RGAA ni le RAWeb et de réduire les écarts de taux entre le référentiel et la norme. Les retours de la communauté recueillis sur GitHub y seront intégrés.

Sans attendre, vos équipes peuvent intégrer les six critères WCAG 2.2 que la norme ajoute : focus non masqué, alternative aux mouvements de glisser, taille des cibles, aide cohérente, saisie redondante évitée et authentification accessible. Les deux derniers concernent directement les parcours bancaires et les démarches administratives : ne pas redemander une information déjà saisie, et ne pas imposer un test cognitif, comme la recopie d'un code déformé, sans alternative. Une formation des équipes de conception et de développement au début de 2027 évite de produire du nouveau contenu selon des règles déjà dépassées.

Plan d'action pour l'accessibilité numérique au Luxembourg

Quel que soit le texte dont vous relevez, la démarche suit les mêmes étapes. Elle peut être engagée dès ce trimestre, sans attendre les versions 2 des référentiels.

1. Inventorier vos services numériques. Listez les sites, applications, intranets, extranets et documents publiés, avec leur langue, leur public et leur prestataire. Pour un organisme public, comparez votre liste avec l'inventaire publié sur data.public.lu.
2. Déterminer le texte applicable. Pour chaque service : loi du 28 mai 2019, loi du 8 mars 2023, ou les deux. Documentez les cas limites (clientèle professionnelle, microentreprise, contenus exemptés) et faites valider l'analyse par votre service juridique.
3. Choisir le référentiel et l'échantillon. RAWeb 1.1 pour le web, RAAM 1.1 pour les applications, RAPDF 1.1 pour les PDF. Construisez un échantillon qui couvre les parcours essentiels et toutes les versions linguistiques réellement utilisées.
4. Réaliser l'audit initial. Faites auditer chaque service sur appareils réels pour le mobile, en distinguant iOS et Android. Un audit RAAM ou un audit RAWeb donne un taux de conformité opposable et une liste de corrections priorisées.
5. Publier ou corriger la déclaration d'accessibilité. Utilisez le générateur officiel, publiez la déclaration dans chaque langue, ajoutez un contact accessible et, pour un organisme public, transmettez l'adresse au SIP dans les trente jours.
6. Corriger selon l'impact. Traitez d'abord ce qui bloque un parcours essentiel : authentification, paiement, formulaire de demande, consultation d'un document officiel. Inscrivez les exigences d'accessibilité dans vos contrats de développement et faites recetter l'accessibilité avant chaque mise en production.
7. Préparer 2027. Intégrez dès maintenant les critères WCAG 2.2, suivez la publication du RAWeb 2 et du RAAM 2 en février 2027, et planifiez un nouvel audit après chaque refonte importante et au moins une relecture annuelle de vos déclarations.

Pour les acteurs soumis à l'EAA, ajoutez deux tâches : rédiger les informations sur l'accessibilité du service à intégrer dans vos conditions générales, et organiser le traitement des signalements que l'OSAPS pourrait vous transmettre. Pour les organismes publics, gardez à l'esprit que l'échantillon de contrôle 2026 est déjà publié et que les rapports d'audit le seront aussi. Si vos équipes développent elles-mêmes, un accompagnement des développeurs sur iOS et Android réduit le coût des corrections.

Questions fréquentes