Barriere­freiheit digitaler Dienste in Luxemburg: was seit Juni 2025 gilt

01Rechtslage in Luxemburg

Die Richtlinie (EU) 2019/882, bekannt als European Accessibility Act (öffnet externe Website), regelt Barrierefreiheit für bestimmte Produkte und Dienste einheitlich in der EU. Unmittelbar gilt sie nicht, sie braucht ein nationales Gesetz. Luxemburg hat dafür das Gesetz vom 8. März 2023 über die Barrierefreiheitsanforderungen an Produkte und Dienstleistungen erlassen, das inzwischen geändert wurde (loi modifiée du 8 mars 2023). Am 28. Juni 2025 sind die Pflichten wirksam geworden.

Über die Einhaltung wacht das OSAPS, das Office de la surveillance de l’accessibilité des produits et services. An das OSAPS richten sich auch Meldungen von Anbietern, die sich auf eine Ausnahme berufen. Hinweise für Unternehmen veröffentlicht Guichet.lu (öffnet externe Website).

Für den Staat und die Gemeinden gilt seit Längerem ein eigener Rahmen: das Gesetz vom 28. Mai 2019 über die Barrierefreiheit der Websites und mobilen Anwendungen öffentlicher Stellen, mit dem Luxemburg die Richtlinie (EU) 2016/2102 umgesetzt hat. Dort überwacht der Service information et presse (SIP) die Einhaltung, mit den Prüfrahmen RAWeb für Websites und RAAM für mobile Apps, beide auf Grundlage von EN 301 549. Das Gesetz von 2023 überträgt vergleichbare Erwartungen auf die Privatwirtschaft, allerdings nur für die aufgezählten Produkte und Dienste.

02Welche digitalen Dienste erfasst sind

Die Richtlinie nennt in Artikel 2 Absatz 2 die Dienste, die erfasst sind, wenn sie Verbrauchern angeboten werden. Für Anbieter in Luxemburg sind vor allem diese relevant:

• Dienstleistungen im elektronischen Geschäftsverkehr: alles, was über Website oder App auf Anfrage eines Verbrauchers zu einem Vertragsabschluss führen soll. Praktisch jeder Onlineshop und jede Buchungsstrecke für Privatkunden.
• Bankdienstleistungen für Verbraucher: Kreditverträge, Zahlungsdienste und Zahlungskonten, E-Geld und bestimmte Wertpapierdienstleistungen für Privatkunden. Am Finanzplatz Luxemburg betrifft das vor allem Banken und Zahlungsinstitute mit Privatkundengeschäft.
• Elemente des Personenverkehrs per Flugzeug, Bus, Bahn und Schiff: Websites, Apps, elektronische Tickets und Ticketdienste, Reiseinformationen in Echtzeit und interaktive Selbstbedienungsterminals. Im Stadt-, Vorort- und Regionalverkehr gelten die Anforderungen nur für die Terminals.
• Elektronische Kommunikationsdienste sowie Zugangsdienste zu audiovisuellen Mediendiensten, etwa Apps und Oberflächen von Streaming- und Fernsehanbietern.
• E-Books und die dafür bestimmte Software.

Daneben erfasst die Regelung Produkte: Computer und Betriebssysteme, Smartphones, Zahlungsterminals, Geldautomaten, Fahrkarten- und Check-in-Automaten, E-Book-Lesegeräte. Wer Software für solche Geräte entwickelt, bekommt die Produktanforderungen über den eigenen Auftraggeber zu spüren.

Reine B2B-Dienste fallen nicht darunter. Viele Geschäftskunden verlangen in Ausschreibungen trotzdem dasselbe Niveau, und öffentliche Auftraggeber in Luxemburg kennen es aus dem Gesetz von 2019. Ein Kundenportal, das Privat- und Firmenkunden bedient, ist für den Verbraucherteil erfasst.

03Die Ausnahme für Kleinst­unternehmen

Kleinstunternehmen, die Dienstleistungen erbringen, müssen die Anforderungen für diese Dienste nicht erfüllen (Artikel 4 Absatz 5 der Richtlinie). Als Kleinstunternehmen gilt, wer weniger als 10 Personen beschäftigt und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme ausweist. Die Ausnahme betrifft nur Dienstleistungen: Ein kleiner Handwerksbetrieb, der erfasste Produkte in Verkehr bringt, muss die Produktanforderungen trotzdem erfüllen.

Maßgeblich ist der Anbieter, nicht der Dienstleister, der ihn baut. Lässt ein größeres Unternehmen seinen Onlineshop von einer kleinen Agentur entwickeln, ist der Shop erfasst.

04Was die Anforderungen für Website und App bedeuten

Was konkret verlangt wird, regelt Anhang I. Bei Dienstleistungen geht es im Kern darum, Websites, die dazugehörigen Online-Anwendungen und Apps konsistent und angemessen zugänglich zu machen: „wahrnehmbar, bedienbar, verständlich und robust“. Die vier Begriffe stammen aus den WCAG, den Web Content Accessibility Guidelines, und lassen sich in prüfbare Punkte übersetzen:

• Wahrnehmbar: Alternativtexte für Bilder, Untertitel für Videos, genügend Farbkontrast, Inhalte, die sich auf kleinen Bildschirmen und bei starker Vergrößerung ohne Informationsverlust neu anordnen.
• Bedienbar: Jede Funktion geht mit der Tastatur, der Fokus ist sichtbar und folgt einer logischen Reihenfolge, niemand bleibt in einem Dialog gefangen, Zeitlimits lassen sich verlängern.
• Verständlich: klare Beschriftungen und Anleitungen, Fehlermeldungen, die sagen, was schiefging und wie es sich beheben lässt, eine vorhersehbare Navigation. Bei Diensten auf Deutsch, Französisch und Englisch gilt das für jede Sprachfassung, einschließlich der korrekten Sprachauszeichnung für Screenreader.
• Robust: saubere Semantik, damit Screenreader und andere Hilfstechnologien jedes Bedienelement mit Name, Rolle und Zustand erkennen.

Für einzelne Dienste kommen Anforderungen hinzu. Onlineshops machen Identifizierung, Sicherheits- und Zahlungsfunktionen barrierefrei und geben die Barrierefreiheitsinformationen zu den verkauften Produkten weiter, soweit der verantwortliche Wirtschaftsakteur sie liefert. Bankdienstleistungen für Verbraucher machen zusätzlich Identifizierungsverfahren, elektronische Signaturen, Sicherheitsfunktionen und Zahlungsdienste barrierefrei und stellen Informationen bereit, die ohne ein höheres Sprachniveau als B2 des Gemeinsamen Europäischen Referenzrahmens verständlich sind. Für eine Bank, die ihre Kundschaft in mehreren Sprachen bedient, betrifft das jede Sprachfassung.

Hinzu kommt eine Informationspflicht: Nach Anhang V beschreibt der Anbieter in seinen AGB oder einem gleichwertigen Dokument, auf welche Weise der Dienst die Anforderungen erfüllt, und stellt das in zugänglicher Form bereit. Üblich ist eine eigene Erklärung zur Barrierefreiheit, verlinkt im Footer und in den Vertragsbedingungen, in jeder Sprache, in der der Dienst angeboten wird.

Normen: EN 301 549 und WCAG

Artikel 15 der Richtlinie knüpft an harmonisierte Normen an: Erfüllt ein Dienst eine im Amtsblatt der EU genannte Norm, wird vermutet, dass er die davon abgedeckten Anforderungen erfüllt. Für IKT-Produkte und -Dienste ist das in Europa EN 301 549. Fassung 3.2.1 dient als harmonisierte Norm für die Richtlinie über den öffentlichen Sektor und enthält für Webinhalte die Kriterien der WCAG 2.1 auf den Stufen A und AA. Auch RAWeb und RAAM, mit denen der SIP in Luxemburg öffentliche Stellen prüft, beruhen auf dieser Norm.

Eigene harmonisierte Normen zum European Accessibility Act sind in Arbeit, im Auftrag der Kommission. Ob schon Fundstellen im Amtsblatt stehen, sollten Sie klären, bevor Sie mit der Konformitätsvermutung argumentieren. In der Praxis messen Aufsicht, Prüfstellen und Kunden ohnehin an EN 301 549. Die WCAG 2.2 (öffnet externe Website) sind seit Oktober 2023 W3C-Empfehlung und bringen neue Kriterien, zum Beispiel zur Mindestgröße von Zielflächen und zur Anmeldung ohne Gedächtnisaufgaben. Wer schon jetzt auf WCAG 2.2 AA zielt, erfüllt WCAG 2.1 mit und ist für die kommende Normfassung gerüstet.

05Unverhältnis­mäßige Belastung und grundlegende Veränderung

Artikel 14 der Richtlinie kennt zwei Ausnahmen. Eine Anforderung entfällt, soweit sie das Wesen des Dienstes grundlegend verändern oder den Anbieter unverhältnismäßig belasten würde. Beide sind eng gefasst:

• Der Anbieter beurteilt das selbst, nach den Kriterien in Anhang VI, und dokumentiert die Beurteilung.
• Wer für die Verbesserung der Barrierefreiheit Fördermittel aus anderen Quellen erhält, kann sich nicht auf eine unverhältnismäßige Belastung berufen.
• Die Beurteilung wird erneuert, wenn sich der Dienst ändert, wenn die Behörde danach fragt, und in jedem Fall mindestens alle fünf Jahre.
• Wer sich auf die Ausnahme beruft, informiert die Marktüberwachungsbehörden der betroffenen Mitgliedstaaten, in Luxemburg das OSAPS. Kleinstunternehmen sind davon befreit.

Eine Ausnahme gilt nur für die konkrete Anforderung, die unverhältnismäßig wäre, nicht für den gesamten Dienst. Sehen Sie darin den letzten Ausweg: Die meisten Barrieren entstehen in Komponenten und Inhalten, deren Korrektur wenig kostet, wenn sie früh auffällt.

06Übergangs­fristen

Artikel 32 der Richtlinie sieht Übergangsregeln vor. Für Diensteanbieter in Luxemburg zählen vor allem diese:

• Bis zum 28. Juni 2030 dürfen Anbieter ihre Dienste weiter mit Produkten erbringen, die sie bereits vor dem 28. Juni 2025 rechtmäßig für vergleichbare Dienste eingesetzt haben.
• Nach der Richtlinie laufen Dienstleistungsverträge, die vor dem 28. Juni 2025 geschlossen wurden, unverändert bis zu ihrem Ende weiter, höchstens aber fünf Jahre ab diesem Datum.
• Für Selbstbedienungsterminals erlaubt die Richtlinie den Mitgliedstaaten eine längere Nutzung bis zum Ende der wirtschaftlichen Lebensdauer, höchstens 20 Jahre ab Inbetriebnahme. Ob und wie Luxemburg davon Gebrauch macht, prüfen Sie im Gesetzestext.

Diese Fristen schützen bestehende Geräte und Verträge. Sie verschieben die Anforderungen nicht für eine Website oder App, die Sie ändern, neu aufsetzen oder neuen Kunden anbieten.

07Luxemburg und die Nachbarländer

Marktüberwachung und Sanktionen sind Sache der Mitgliedstaaten; jeder benennt eigene Behörden und legt wirksame, verhältnismäßige und abschreckende Sanktionen fest. Wer aus Luxemburg Verbraucher in der Großregion bedient, muss deshalb mehrere Gesetze im Blick haben:

08Barriere­freiheit als Teil der Entwicklungs­arbeit

Die meisten Barrieren sind keine bewussten Designentscheidungen. Sie entstehen, weil Komponenten ohne Semantik gebaut, Inhalte ohne Alternativen veröffentlicht und Widgets von Drittanbietern nie getestet wurden. Darum enttäuscht eine Prüfung kurz vor dem Start: Sie findet Dutzende Mängel, die sich früh billig vermeiden lassen und spät teuer werden. Erfolgreich ist, wer Barrierefreiheit behandelt wie Sicherheit, als Eigenschaft des Lieferprozesses.

• Barrierefreiheit im Designsystem. Bedienelemente wie Buttons, Eingabefelder, Dialogfenster, Navigationsmenüs, Tabs und Tabellen entstehen ein einziges Mal, mit richtiger Semantik, voller Tastaturbedienung und sauberem Fokus, werden mit Screenreadern abgenommen und dann überall eingesetzt. Für helles und dunkles Farbschema prüfen Sie die Kontraste der Farbwerte.
• Barrierefreiheit in der Definition of Done. Jede User Story nennt Akzeptanzkriterien für Tastaturbedienung, Beschriftungen und Fehlerbehandlung, und das Review prüft sie wie jede andere Anforderung.
• Automatisierte Tests bei jedem Build. Regelbasierte Werkzeuge stoppen einen Build, sobald etwas schlechter wird. Sie erkennen allerdings nur einen Ausschnitt, etwa fehlende Labels, zu schwachen Kontrast oder fehlerhaftes HTML. Manuelle Prüfung bleibt deshalb nötig.
• Handprüfung durch Fachleute, die Hilfstechnologien kennen. Bedienung ausschließlich per Tastatur, Screenreader am Rechner und auf dem Telefon, 400 Prozent Zoom, reduzierte Animationen. Im Fokus stehen die Strecken, auf die es ankommt: Login, Suche, Bestellabschluss, Bezahlung, Verwaltung des Kundenkontos.
• Tests mit Menschen mit Behinderungen auf den wichtigsten Strecken, vor dem Release und nach größeren Änderungen.
• Komponenten von Drittanbietern unter Vertrag. Zahlungs-Widgets, Login-Dienste wie LuxTrust-Anbindungen, Chat-Assistenten, Cookie-Banner, Karten und Videoplayer gehören zu Ihrem Dienst. Verlangen Sie von Lieferanten einen Konformitätsbericht und testen Sie die Komponenten in Ihrem Kontext.
• Inhalte und Dokumente. Redaktionen lernen, Alternativtexte, Überschriften und Linktexte zu schreiben, in jeder Sprache, in der sie veröffentlichen. PDFs, die Kunden brauchen, etwa Verträge, Kontoauszüge und Rechnungen, werden getaggt oder in einem barrierefreien Alternativformat angeboten.

Nach diesem Muster entstehen bei uns Unternehmenssoftware und Kundenportale: Die Pipeline prüft bei jedem Build mit, und aus jedem Release fallen die Belege ab, die Sie für die Erklärung zur Barrierefreiheit und für Rückfragen von Kunden oder des OSAPS brauchen. Bei Serviceassistenten und Portalen auf Salesforce gilt dasselbe. Die Plattform liefert zugängliche Grundbausteine; ob das Ganze zugänglich bleibt, hängt an den eigenen Erweiterungen und Texten.

09Ein praktischer Fahrplan

1. 01Bestandsaufnahme. Welche Websites, Apps, Terminals und Dokumente richten sich an Verbraucher, in welchem Land und in welcher Sprache? Entscheiden Sie je Dienst, ob er unter das Gesetz fällt, und schreiben Sie die Begründung auf, auch wenn die Antwort Nein lautet.
2. 02Den Stand messen. Lassen Sie die kritischen Strecken von Fachleuten gegen EN 301 549 prüfen und die gesamte Website automatisch scannen. Priorisieren Sie nach Auswirkung auf die Nutzer, nicht nach Zahl der Befunde.
3. 03An der Quelle beheben. Korrigieren Sie zuerst Designsystem und gemeinsame Komponenten, damit jede Korrektur alle Seiten erreicht.
4. 04Die Angaben veröffentlichen. Beschreiben Sie in den Geschäftsbedingungen oder einer Erklärung zur Barrierefreiheit, wie der Dienst die Anforderungen erfüllt, mit einer Kontaktstelle für Rückmeldungen, und halten Sie die Angaben aktuell.
5. 05In die Lieferung einbauen. Akzeptanzkriterien, automatische Prüfungen, manuelle Testskripte und eine Freigabeschwelle für die kritischen Strecken.
6. 06Lieferanten steuern. Nehmen Sie Anforderungen und Nachweise zur Barrierefreiheit in die Verträge mit Agenturen, Plattformen und Widget-Anbietern auf.
7. 07Ausnahmen dokumentieren. Wenn Sie sich auf eine unverhältnismäßige Belastung berufen, halten Sie die Beurteilung schriftlich fest, informieren Sie das OSAPS, wo das verlangt ist, und planen Sie die Überprüfung.

10Was Sie im Blick behalten sollten

• Die Veröffentlichung harmonisierter Normen zum European Accessibility Act, einschließlich einer Überarbeitung von EN 301 549, und ihre Fundstellen im Amtsblatt der EU.
• Leitfäden und erste Aufsichtsmaßnahmen des OSAPS und der Behörden in den anderen Ländern, in denen Sie Dienste anbieten.
• Das Ende der Übergangsfrist am 28. Juni 2030 und mögliche Änderungen am Gesetz vom 8. März 2023.

Einen laufend gepflegten Überblick der Kommission (öffnet externe Website) finden Sie auf ihren Seiten zur Behindertenpolitik. Datieren Sie eigene Vermerke zum Thema, denn die Aufsichtspraxis ist noch im Werden.