WCAG 2.2, EN 301 549, RAWeb, eCH-0059: welche Norm für digitale Barrierefreiheit gilt?

Alle Pflichten zur digitalen Barrierefreiheit in Europa beruhen auf derselben technischen Grundlage: den WCAG des W3C. Welche Norm im Einzelfall maßgeblich ist, unterscheidet sich trotzdem. Für ein luxemburgisches Ministerium ist es der RAWeb, für eine öffentliche Stelle in Belgien die EN 301 549, für die Schweizer Bundesverwaltung eCH-0059, für eine französische Gemeinde der RGAA und für einen Schweizer Softwareanbieter, der in die EU verkauft, wiederum die EN 301 549. Diese Analyse mit Stand 27. Oktober 2026 zeigt, was jeder Standard enthält, was die im September veröffentlichte Version 4.1.1 der EN 301 549 ändert und wie Sie entscheiden, wenn Sie in mehreren Ländern tätig sind.

Die kurze Antwort: eine gemeinsame Basis, mehrere Ausprägungen

Die WCAG legen fest, was ein barrierefreier Webinhalt ist. Die europäische Norm EN 301 549 übernimmt sie und erweitert sie auf die gesamte Informations- und Kommunikationstechnik: Dokumente, Software, mobile Apps, Endgeräte und Kommunikationsdienste. Nationale Prüfkataloge wie der RGAA in Frankreich oder der RAWeb in Luxemburg übersetzen diese Anforderungen in genau formulierte Kriterien und Tests, verbunden mit einer Prüfmethode und einer gesetzlichen Grundlage.

Die Unterschiede zwischen diesen Texten liegen also weniger im Inhalt als in drei Punkten: der zugrunde gelegten WCAG-Version, dem erfassten Geltungsbereich und der vorgeschriebenen Methode, mit der die Konformität gemessen wird. Eine Website, die die WCAG 2.1 auf Stufe AA erfüllt, ist in allen vier Ländern bereits nah an der Konformität. Im rechtlichen Sinn konform ist sie aber erst, wenn die Bewertung nach dem geltenden Standard durchgeführt wurde und die vorgeschriebenen Dokumente, etwa die Erklärung zur Barrierefreiheit, veröffentlicht sind.

Zur schnellen Orientierung: Diese Standards gelten zum Zeitpunkt dieses Artikels für die häufigsten Fälle.

• öffentliche Stelle in Luxemburg: RAWeb 1.1 für das Web, RAAM 1.1 für mobile Apps und RAPDF 1.1 für PDF-Dokumente;
• öffentliche Stelle in Belgien, auch in der Deutschsprachigen Gemeinschaft: die Norm EN 301 549, für das Web also die WCAG 2.1 auf Stufe AA;
• Schweizer Bundesverwaltung: der Standard eCH-0059 in der Version 3.0, der auf die WCAG 2.1 Stufe AA verweist;
• öffentliche Stelle in Frankreich oder Unternehmen, das unter Artikel 47 des französischen Gesetzes vom 11. Februar 2005 fällt: RGAA 4.1.2, bis zum für Ende 2026 angekündigten RGAA 5;
• Unternehmen, das unter den European Accessibility Act fällt, unabhängig vom Mitgliedstaat: die Anforderungen der Richtlinie, für die die Norm EN 301 549 die technische Referenz ist.

WCAG: So ist die Referenznorm der digitalen Barrierefreiheit aufgebaut

Die Web Content Accessibility Guidelines werden vom World Wide Web Consortium (W3C) im Rahmen seiner Web Accessibility Initiative (WAI) veröffentlicht. Sie sind keine Gesetzestexte, sondern technische Empfehlungen, auf die Gesetze und Normen verweisen. Seit September 2025 ist die Version 2.2 auch eine internationale Norm: Die ISO hat die zweite Ausgabe der Norm ISO/IEC 40500 veröffentlicht, die die WCAG 2.2 übernimmt.

Vier Prinzipien, dreizehn Richtlinien, prüfbare Kriterien

Die WCAG sind um vier Prinzipien herum aufgebaut. Ein Inhalt muss wahrnehmbar sein: Eine Information, die über ein Bild, einen Ton oder eine Farbe vermittelt wird, muss auch in einer Form vorliegen, die alle wahrnehmen können, zum Beispiel als Text, den ein Screenreader vorliest. Er muss bedienbar sein: Alles, was mit der Maus geht, muss auch mit der Tastatur gehen, ohne unerfüllbare Zeitlimits. Er muss verständlich sein: deklarierte Sprache, vorhersehbares Verhalten, klare Fehlermeldungen. Und er muss robust sein: Der Code muss es assistiven Technologien ermöglichen, Name, Rolle und Zustand jeder Komponente zu erkennen.

Diese Prinzipien gliedern sich in 13 Richtlinien (Guidelines), etwa „Per Tastatur zugänglich“ oder „Hilfestellung bei der Eingabe“. Jede Richtlinie besteht wiederum aus Erfolgskriterien, die so formuliert sind, dass sie sich überprüfen lassen: Ein Kriterium ist auf einer bestimmten Seite entweder erfüllt oder nicht. Die Version 2.2 umfasst 86 aktive Erfolgskriterien. Auf dieser Ebene, der Ebene der Kriterien, arbeiten Prüferinnen und Prüfer, und diese Ebene übernehmen auch die nationalen Prüfkataloge.

Drei Konformitätsstufen: A, AA und AAA

Jedes Kriterium ist einer Stufe zugeordnet. Stufe A umfasst die Anforderungen, ohne die bestimmte Menschen schlicht keinen Zugang zum Inhalt haben: ein Video ohne Untertitel, eine Schaltfläche, die sich nicht per Tastatur bedienen lässt. Stufe AA ergänzt Anforderungen, die erhebliche Hürden beseitigen, etwa einen ausreichenden Textkontrast oder einen sichtbaren Fokus. Stufe AAA bündelt die höchsten Anforderungen, die sich auf einer ganzen Website oft nicht garantieren lassen, etwa Gebärdensprache für alle Videos.

Konformität auf Stufe AA bedeutet, alle Kriterien der Stufe A und alle Kriterien der Stufe AA zu erfüllen. Diese Stufe übernimmt die Norm EN 301 549 und über sie die europäischen Vorschriften. Die Konformität wird Seite für Seite beurteilt, aber auch für vollständige Prozesse: Ist ein einziger Schritt eines Bestellvorgangs oder eines Online-Antrags nicht konform, kann keine Seite dieses Prozesses als konform gelten.

Versionen 2.0, 2.1 und 2.2: drei miteinander kompatible Fassungen

Jede neue Version der WCAG 2 fügt Kriterien hinzu, ohne die bisherigen in Frage zu stellen. Der W3C erklärt, dass die WCAG 2.2 auf den WCAG 2.1 aufbauen und mit ihnen kompatibel bleiben: Ein Inhalt, der die WCAG 2.2 erfüllt, erfüllt auch die früheren Versionen, mit einer Ausnahme, die weiter unten erläutert wird.

Die neun neuen Kriterien der WCAG 2.2 und das eine, das wegfällt

Die offizielle W3C-Seite What’s New in WCAG 2.2 (auf Englisch) führt neun neue Kriterien auf. Sechs davon gehören zu den Stufen A und AA und fallen damit in den Umfang einer AA-Konformität:

• 2.4.11 Fokus nicht verdeckt (Minimum), Stufe AA: Das Element mit dem Fokus darf nicht vollständig von einem Inhalt der Seite verdeckt werden, etwa von einer fixierten Kopfleiste;
• 2.4.12 Fokus nicht verdeckt (erweitert), Stufe AAA: Kein Teil des Elements darf verdeckt sein;
• 2.4.13 Fokusdarstellung, Stufe AAA: Der Fokusindikator muss eine Mindestgröße und einen Mindestkontrast haben;
• 2.5.7 Ziehbewegungen, Stufe AA: Jede Aktion, die durch Ziehen ausgeführt wird, muss auch mit einem einfachen Klick oder Tippen möglich sein;
• 2.5.8 Zielgröße (Minimum), Stufe AA: Klickbare Bereiche müssen mindestens 24 CSS-Pixel Kantenlänge haben, mit Ausnahmen;
• 3.2.6 Konsistente Hilfe, Stufe A: Hilfeangebote müssen von Seite zu Seite an derselben Stelle zu finden sein;
• 3.3.7 Redundante Eingabe, Stufe A: Eine Angabe, die in einem Prozess bereits gemacht wurde, darf nicht erneut verlangt werden oder muss automatisch vorgeschlagen werden;
• 3.3.8 Barrierefreie Authentifizierung (Minimum), Stufe AA: Die Anmeldung darf keinen kognitiven Test ohne Alternative oder Hilfe verlangen;
• 3.3.9 Barrierefreie Authentifizierung (erweitert), Stufe AAA: dieselbe Anforderung, ohne die Ausnahme für die Erkennung von Objekten.

Das Kriterium 4.1.1 Syntaxanalyse (Parsing) ist laut W3C in den WCAG 2.2 „obsolet und entfernt“: Browser und assistive Technologien sind nicht mehr auf die Analyse des rohen Quellcodes angewiesen. Das ist die einzige Abweichung von der Abwärtskompatibilität. Der W3C weist darauf hin, dass Organisationen, deren Vorschriften noch auf die WCAG 2.0 oder 2.1 verweisen, das Kriterium unter Umständen weiter prüfen müssen. Das gilt etwa für Frankreich, wo das Kriterium 8.2 des RGAA 4.1.2 (Gültigkeit des generierten Quellcodes) weiterhin zu prüfen ist.

WCAG 3: ein langfristiges Vorhaben, keine Frist

Der W3C arbeitet seit mehreren Jahren an einer neuen Generation von Regeln, den W3C Accessibility Guidelines 3.0. Der jüngste Arbeitsentwurf (Working Draft) stammt vom 10. September 2026. Er schlägt eine andere Architektur vor: Richtlinien, die nach Themen gruppiert sind (Bilder und Medien, Kontrolle durch die Nutzer und weitere), feiner gefasste Anforderungen, die in Kernanforderungen und ergänzende Anforderungen unterschieden werden, sowie „Assertions“, mit denen eine Organisation bestimmte Praktiken erklärt, etwa die Durchführung von Nutzertests. Auch das Konformitätsmodell unterscheidet sich von dem der WCAG 2.

Beim Zeitplan ist der W3C eindeutig. Laut seiner Einführungsseite zu den WCAG 3 (auf Englisch) wird die Norm voraussichtlich erst in einigen Jahren fertiggestellt, sie wird die WCAG 2 nicht ablösen, und die WCAG 2 werden noch mehrere Jahre nach der Fertigstellung der WCAG 3 nicht für veraltet erklärt. Der Entwurf selbst hält fest, dass die endgültigen Anforderungen von den veröffentlichten abweichen werden.

Kein europäisches Gesetz und keine harmonisierte Norm verweist heute auf die WCAG 3. Für eine IT-Leitung oder eine Compliance-Verantwortliche ist die Folgerung einfach: Sinnvoll investiert ist in die WCAG 2.2 auf Stufe AA. Der W3C empfiehlt selbst, sich auf die WCAG 3 am besten dadurch vorzubereiten, dass man heute die Erfolgskriterien der WCAG 2.2 erfüllt. Der Arbeitsentwurf vom September 2026 hält zudem fest, dass man mit der Erfüllung der WCAG 2 auf Stufe AA der Konformität mit den WCAG 3 nahekommt, auch wenn Unterschiede bestehen können.

EN 301 549: die europäische Norm, die weit über das Web hinausgeht

Die Norm EN 301 549 mit dem Titel „Barrierefreiheitsanforderungen für IKT-Produkte und -Dienstleistungen“ wird gemeinsam von ETSI, CEN und CENELEC erarbeitet, den europäischen Normungsorganisationen. Während die WCAG nur Webinhalte betreffen, erfasst sie die gesamte Informations- und Kommunikationstechnik: Ein Geldautomat, eine Fachanwendung, ein Videokonferenzdienst, ein E-Book-Reader oder ein heruntergeladenes PDF fallen in ihren Anwendungsbereich.

Für das Web erfindet die Norm nichts neu: Ihr Kapitel 9 übernimmt die Erfolgskriterien der WCAG der Stufen A und AA. Die Kapitel 10 und 11 wenden dieselben Kriterien in angepasster Form auf Dokumente und Software an, die keine Webseiten sind, einschließlich nativer mobiler Apps. Der Rest der Norm ergänzt Anforderungen, die die WCAG nicht behandeln.

Version 3.2.1 in Kraft, Version 4.1.1 im September 2026 veröffentlicht

Die derzeit im Amtsblatt der Europäischen Union genannte Fassung ist die V3.2.1 aus dem Jahr 2021. Sie wurde durch den Durchführungsbeschluss (EU) 2021/1339 der Kommission vom 11. August 2021 auf Grundlage der Richtlinie (EU) 2016/2102 als harmonisierte Norm für Websites und mobile Anwendungen des öffentlichen Sektors festgelegt. Ihre Kapitel zu Web, Dokumenten und Software verweisen auf die WCAG 2.1 Stufe AA.

Die Version 4.1.1 wurde am 24. August 2026 angenommen und am 2. September 2026 veröffentlicht. Laut ihrem Vorwort und ihrer Einleitung wurde sie im Rahmen des Normungsauftrags M/587 der Kommission mit dem Aktenzeichen C(2022) 6456 erarbeitet, um ein Mittel zum Nachweis der Konformität mit der Richtlinie (EU) 2019/882, dem European Accessibility Act, bereitzustellen. Ihre Kapitel 9, 10 und 11 sind an den WCAG 2.2 ausgerichtet, die die Norm in der Fassung vom 12. Dezember 2024 und unter der Referenz ISO/IEC 40500:2025 zitiert. Die Anhänge ZA und ZB stellen den Bezug zwischen ihren Anforderungen und denen der beiden Richtlinien her. Der Text ist kostenlos auf der Website von ETSI abrufbar: EN 301 549 V4.1.1 (2026-09), PDF auf Englisch.

Ein rechtlicher Punkt ist wichtig: Eine Norm begründet eine Konformitätsvermutung erst, wenn ihre Fundstelle im Amtsblatt der Europäischen Union veröffentlicht ist. Zum Zeitpunkt dieses Artikels ist die V4.1.1 dort noch nicht genannt; Behörden, die die Arbeiten begleitet haben, etwa die luxemburgische, erwarten die Veröffentlichung bis Ende 2026. Bis dahin bleibt die V3.2.1 die maßgebliche harmonisierte Norm für den öffentlichen Sektor.

Was die Norm über die WCAG hinaus verlangt

Bei einem Audit nach EN 301 549 gibt es mehrere Anforderungen, die ein reiner WCAG-Prüfkatalog nicht abdeckt. Eine Software oder App muss die Barrierefreiheitseinstellungen des Systems respektieren, zum Beispiel die in den Telefoneinstellungen gewählte Schriftgröße. Ein Redaktionssystem muss es ermöglichen, barrierefreie Inhalte zu erstellen. Die Produktdokumentation muss die Barrierefreiheitsfunktionen beschreiben, und der Kundendienst muss einer gehörlosen oder blinden Person antworten können. Für einen Videokonferenzdienst oder eine Banking-App mit Videoanruf bringt Kapitel 6 Anforderungen an Echtzeittext und an eine Videoqualität, die Lippenlesen oder Gebärdensprache ermöglicht.

RGAA 4.1.2: der Unterschied zwischen RGAA und WCAG

Auch für Leserinnen und Leser außerhalb Frankreichs lohnt sich ein Blick auf den RGAA, denn er ist das methodische Vorbild des luxemburgischen RAWeb. Der Référentiel général d’amélioration de l’accessibilité wird von der französischen interministeriellen Digitaldirektion (DINUM) herausgegeben. Er dient dazu, die Konformität der Dienste zu bewerten, die unter Artikel 47 des Gesetzes Nr. 2005-102 vom 11. Februar 2005 fallen; die Pflichten erläutert unser Artikel über digitale Barrierefreiheit in Frankreich. Die Version 4 wurde im September 2019 eingeführt; die geltende Version 4.1.2 geht auf die Aktualisierung vom 18. April 2023 zurück.

Der RGAA 4.1.2 umfasst 106 Kriterien in 13 Themenbereichen. Jedes Kriterium ist als geschlossene Frage formuliert, zum Beispiel: „Hat jedes informationstragende Bild eine Textalternative?“ Jedes Kriterium gliedert sich in Tests, laut der offiziellen Datei der Kriterien und Tests des RGAA (auf Französisch) insgesamt 258. Ein Kriterium ist konform, wenn alle seine Tests bestanden sind, nicht konform, wenn einer davon scheitert, und nicht anwendbar, wenn der betreffende Inhalt auf der Seite nicht vorkommt.

RGAA oder WCAG: was sich wirklich unterscheidet

Inhaltlich sagen der RGAA 4.1.2 und die WCAG 2.1 Stufe AA dasselbe: Jedes RGAA-Kriterium verweist auf ein oder mehrere WCAG-Kriterien. Die Auswertung der offiziellen Datei zeigt, dass der RGAA die Kriterien der Stufen A und AA der WCAG 2.1 abdeckt, mit einer Ausnahme: Für Live-Untertitel (WCAG-Kriterium 1.2.4) gibt es kein RGAA-Kriterium.

Die Unterschiede liegen in der Methode. Der RGAA legt genaue Tests fest, wo die WCAG der Prüferin die Wahl der Technik lassen. Er schreibt eine Testumgebung vor, also Kombinationen aus Screenreadern und Browsern (NVDA, JAWS, VoiceOver auf dem Computer, TalkBack und VoiceOver auf Mobilgeräten). Er regelt, wie die Seitenstichprobe zusammengestellt und ein Konformitätsgrad berechnet wird. Hinzu kommen Veröffentlichungspflichten des französischen Rechts wie die Erklärung zur Barrierefreiheit und der mehrjährige Umsetzungsplan (schéma pluriannuel). Die mit den WCAG 2.2 eingeführten Kriterien, etwa zur Zielgröße oder zur barrierefreien Authentifizierung, sind darin noch nicht enthalten.

Ein RGAA-Audit ist daher kein WCAG-2.2-Audit, und umgekehrt. Wenn Sie in Frankreich eine Erklärung veröffentlichen müssen, liefert nur ein RGAA-Audit einen verwertbaren Konformitätsgrad. Wenn Sie den European Accessibility Act oder einen europäischen Markt im Blick haben, muss die Bewertung zusätzlich die Kriterien der WCAG 2.2 und die einschlägigen Kapitel der EN 301 549 abdecken.

Der RGAA 5 in Vorbereitung

Die DINUM hat angekündigt, dass die Version 5 des RGAA gemeinsam mit öffentlichen, gemeinnützigen und privaten Akteuren erarbeitet wird und Ende 2026 erscheinen soll. Laut der offiziellen Ankündigung des RGAA 5 (auf Französisch) wird diese Version die WCAG 2.2 integrieren, die Kriterien neu formulieren und vereinfachen und eigene Kriterien und Tests für mobile Apps und Office-Dokumente festlegen. Begleitet wird sie von der Benennung der Arcom als Kontrollbehörde und von einem Online-Dienst, über den Erklärungen zur Barrierefreiheit eingereicht und veröffentlicht werden.

Die DINUM nennt zwei praktische Punkte. Die Kriterien des RGAA 5 werden die des RGAA 4.1.2 präzisieren oder ergänzen, ohne ihnen zu widersprechen: Die heute geleistete Arbeit ist also nicht verloren. Und Erklärungen, die vor der Veröffentlichung des RGAA 5 erstellt wurden, bleiben 18 Monate gültig, höchstens jedoch drei Jahre nach ihrem Veröffentlichungsdatum. Laufende Arbeiten sollen nicht ausgesetzt werden, um auf die neue Version zu warten.

RAWeb, RAAM und RAPDF: die Prüfkataloge Luxemburgs

Luxemburg hat sich für eigene nationale Prüfkataloge entschieden, die der Service information et presse (SIP) der Regierung auf dem Portal accessibilite.public.lu veröffentlicht. Sie dienen der Bewertung der Websites und Apps öffentlicher Stellen, die unter das Gesetz vom 28. Mai 2019 fallen. Ihre Besonderheit: Sie sind auf Grundlage der Norm EN 301 549 aufgebaut und nicht allein auf den WCAG, übernehmen aber die Methode des RGAA. Die Kataloge erscheinen auf Französisch und Englisch; eine deutsche Fassung gibt es nicht, deutschsprachige Teams können auf die englische zurückgreifen.

Der RAWeb 1.1 für das Web umfasst 136 Kriterien. Er übernimmt die 13 Themenbereiche des RGAA 4.1.2 und ergänzt vier weitere aus der europäischen Norm: Dokumentation und Barrierefreiheitsfunktionen, Autorenwerkzeuge, Supportdienste und Echtzeitkommunikation. Mit der am 6. Februar 2026 veröffentlichten Aktualisierung wurde unter anderem der European Accessibility Act berücksichtigt, sodass der RAWeb auch über den luxemburgischen öffentlichen Sektor hinaus verwendet werden kann; außerdem wurden veraltete Techniken gestrichen.

Der RAAM 1.1 für mobile Apps umfasst 108 Kriterien. Er bewertet eine App anhand der Norm EN 301 549 V3.2.1 und deckt deren Kapitel 5, 6, 7, 10, 11 und 12 ab. Der RAPDF 1.1 für PDF-Dokumente wurde im Februar 2026 vereinfacht: Seine Methode stützt sich nicht mehr auf einen Screenreader, sondern auf Acrobat Reader und das Werkzeug PDF Accessibility Checker (PAC), und er enthält eine Zuordnung zur Norm PDF/UA-2.

Eine größere Änderung ist geplant. Der SIP hat am 15. September 2026 angekündigt, dass RAWeb und RAAM in die Version 2 übergehen (auf Französisch), und zwar im Laufe des Februars 2027, kompatibel mit der Norm EN 301 549 V4.1.1 und damit mit den WCAG 2.2. Luxemburgische Stellen, die im Herbst 2026 ein Audit beginnen, lassen es nach RAWeb 1.1 oder RAAM 1.1 erstellen; es lohnt sich, parallel die Kriterien der WCAG 2.2 prüfen zu lassen, um eine zweite Korrekturrunde zu vermeiden. Unser Artikel über digitale Barrierefreiheit in Luxemburg erläutert die Pflichten, die Seite RAAM-Audit die Methode für iOS- und Android-Apps.

Belgien und die Schweiz: kein eigener nationaler Prüfkatalog

In Belgien gilt die EN 301 549 direkt

In Belgien setzt das Gesetz vom 19. Juli 2018 über die Barrierefreiheit der Websites und mobilen Anwendungen öffentlicher Stellen die Richtlinie (EU) 2016/2102 auf föderaler Ebene um; ergänzt wird es durch Dekrete und Ordonnanzen der Regionen und Gemeinschaften. Einen nationalen Prüfkatalog wie den RGAA gibt es nicht: Referenz ist die Norm EN 301 549, für das Web also die WCAG 2.1 Stufe AA, und für Dokumente und Software dieselben Kriterien in der jeweiligen Auslegung.

In der Praxis stützt sich ein belgisches Audit auf die WCAG-Kriterien und auf die Kapitel der Norm, die für den jeweiligen Dienst gelten. Die Tests des RGAA oder des RAWeb können der Prüferin als Arbeitshilfe dienen, Bericht und Erklärung müssen sich aber auf die EN 301 549 beziehen. Für eine Gemeinde oder Einrichtung in Ostbelgien ist zunächst zu klären, welcher Text auf sie anwendbar ist, das föderale Gesetz oder ein regionaler oder gemeinschaftlicher Text; technisch führt der Weg in jedem Fall zur EN 301 549. Pflichten und zuständige Behörden stellen unsere Seite Belgien und der Artikel über digitale Barrierefreiheit in Belgien vor.

In der Schweiz gilt der Standard eCH-0059

In der Schweiz verpflichten das Behindertengleichstellungsgesetz (BehiG) und seine Verordnung den Bund zur Barrierefreiheit seiner Online-Angebote. Technische Referenz ist der Standard eCH-0059 in der Version 3.0, den der Verein eCH im Juni 2020 verabschiedet hat. Er beruht auf den WCAG 2.1, und die Bundesverwaltung verlangt ihre Einhaltung auf Stufe AA. Kantone und Gemeinden wenden eigene Regeln an, die oft auf denselben Standard verweisen. Im Schweizer Sprachgebrauch ist neben „barrierefrei“ auch „hindernisfrei“ üblich; gemeint ist dasselbe.

Zwei Entwicklungen sind zu verfolgen. Eine Teilrevision des BehiG, die im eidgenössischen Parlament beraten wird, soll den Zugang zu Leistungen privater Unternehmen stärken, auch zu digitalen. Und Schweizer Unternehmen, die an Verbraucher in der Europäischen Union verkaufen, unterliegen für die erfassten Produkte und Dienstleistungen dem European Accessibility Act und damit der Norm EN 301 549 statt eCH-0059. Einzelheiten enthält unser Artikel über digitale Barrierefreiheit in der Schweiz.

BITV und BFSG: deutsche Begriffe richtig einordnen

Wer auf Deutsch nach Normen für digitale Barrierefreiheit sucht, stößt schnell auf Abkürzungen aus Deutschland. Viele deutschsprachige Leitfäden, Werkzeuge und Prüfberichte beziehen sich auf das deutsche Recht. Für Organisationen in Luxemburg, der Schweiz und Ostbelgien lohnt es sich daher, die Begriffe kurz einzuordnen.

• BITV 2.0: die Barrierefreie-Informationstechnik-Verordnung, eine deutsche Bundesverordnung zum Behindertengleichstellungsgesetz. Sie gilt für Websites, mobile Anwendungen und elektronisch unterstützte Verwaltungsabläufe öffentlicher Stellen in Deutschland. Sie vermutet die Konformität, wenn die im Amtsblatt der EU genannten harmonisierten Normen eingehalten sind, in der Praxis also die EN 301 549, und verlangt zusätzlich Erläuterungen in Deutscher Gebärdensprache und in Leichter Sprache auf der Startseite;
• BITV-Test: ein Prüfverfahren, dessen Berichte man in deutschen Quellen häufig findet und die sich auf die BITV 2.0 und die EN 301 549 beziehen. Es ist ein Werkzeug, keine Rechtsgrundlage;
• BFSG: das Barrierefreiheitsstärkungsgesetz, mit dem Deutschland den European Accessibility Act umgesetzt hat. Seine Hauptbestimmungen gelten seit dem 28. Juni 2025.

Für Ihre Organisation heißt das: Die BITV 2.0 gilt weder in Luxemburg noch in der Schweiz noch in Belgien. Ein Bericht mit dem Vermerk „BITV-konform“ ist technisch oft gut verwertbar, weil er auf denselben WCAG-Kriterien beruht. Er ersetzt aber weder eine Bewertung nach RAWeb in Luxemburg noch eine Erklärung nach EN 301 549 in Belgien noch eine Prüfung nach eCH-0059 für die Bundesverwaltung.

Das BFSG wird dagegen relevant, sobald ein Unternehmen aus Luxemburg, der Schweiz oder Belgien erfasste Produkte oder Dienstleistungen an Verbraucher in Deutschland verkauft, etwa einen Onlineshop oder eine Banking-App. Maßgeblich ist jeweils das Umsetzungsgesetz des Landes, in dem verkauft wird; die technische Grundlage bleibt in allen Mitgliedstaaten die EN 301 549. Ein Programm, das auf die WCAG 2.2 und die Norm ausgerichtet ist, deckt deshalb den deutschen Markt ebenso ab wie den luxemburgischen oder belgischen.

Welche Norm für digitale Barrierefreiheit in Ihrem Land gilt

Die folgende Tabelle verbindet Land und Art der Organisation mit dem anwendbaren Text, dem Prüfkatalog und der erwarteten Stufe. Sie beschreibt die Lage am 27. Oktober 2026; angekündigte Änderungen finden Sie im Maßnahmenplan am Ende des Artikels.

Zwei Hinweise zum Lesen der Tabelle. Erstens sind RGAA und RAWeb Prüfmethoden, keine zusätzlichen Anforderungsstufen: Eine nach RGAA konforme Website ist nicht „barrierefreier“ als eine nach EN 301 549 konforme, sie wurde nur nach einem anderen Raster bewertet. Zweitens legt beim European Accessibility Act die Richtlinie die Anforderungen fest, und die harmonisierte Norm liefert ihre technische Übersetzung; unsere Analyse zum European Accessibility Act erläutert die erfassten Produkte und Dienstleistungen sowie die Ausnahmen.

Sechs Kriterien an konkreten Fällen erklärt

Normen werden verständlicher, wenn man einige Kriterien betrachtet, die in jedem Audit vorkommen. Zu jedem nennen wir die WCAG-Referenz und, sofern vorhanden, das entsprechende RGAA-Kriterium.

Textalternativen für Bilder

Das WCAG-Kriterium 1.1.1 (Stufe A), im RGAA durch die Kriterien 1.1 bis 1.3 abgebildet, verlangt, dass jedes informationstragende Bild eine Textentsprechung hat und dekorative Bilder von assistiven Technologien ignoriert werden. Auf einer Zahlungsseite müssen die Logos der akzeptierten Karten ausgegeben werden („Visa, Mastercard“); das Stimmungsbild im Kopfbereich dagegen braucht eine leere Alternative, damit es das Vorlesen nicht stört.

Die typischen Fehler sind bekannt: eine Alternative, die den Dateinamen wiederholt („IMG_2045.jpg“), eine Alternative „Bild“ oder „Logo“ ohne nützlichen Inhalt, eine Grafik im Jahresbericht, die nur mit ihrem Titel beschrieben wird, obwohl die Zahlen nirgends sonst stehen. Für diesen letzten Fall verlangt der RGAA eine ausführliche Beschreibung (Kriterium 1.6), zum Beispiel die Datentabelle unter der Grafik.

Kontrast von Texten und Bedienelementen

Das WCAG-Kriterium 1.4.3 (Stufe AA), im RGAA das Kriterium 3.2, verlangt ein Kontrastverhältnis von mindestens 4,5:1 zwischen Text und Hintergrund, bei großer Schrift von mindestens 3:1, also ab 18 Punkt oder 14 Punkt fett. Hellgrauer Platzhaltertext in einem Formularfeld, weißer Text auf einem hellen Foto oder das Kleingedruckte in einem Cookie-Banner fallen häufig durch.

Das Kriterium 1.4.11 (Stufe AA), im RGAA das Kriterium 3.3, dehnt die Anforderung auf Bedienelemente und informationstragende Grafiken aus: Der Rahmen eines Eingabefelds, ein Lupensymbol ohne Beschriftung oder die Kurve eines Diagramms müssen einen Kontrast von 3:1 zu den angrenzenden Farben erreichen.

Sichtbarer und jetzt auch nicht verdeckter Fokus

Wer mit der Tastatur navigiert, muss jederzeit sehen, wo er sich befindet. Das WCAG-Kriterium 2.4.7 (Stufe AA), im RGAA das Kriterium 10.7, verlangt, dass das Element mit dem Fokus sichtbar ist. Der klassische Fehler ist eine CSS-Regel „outline: none“, die aus gestalterischen Gründen auf die gesamte Website angewendet wird, ohne einen Ersatzindikator.

Die WCAG 2.2 ergänzen das Kriterium 2.4.11 (Stufe AA): Das Element mit dem Fokus darf nicht vollständig durch vom Autor hinzugefügte Inhalte verdeckt werden. Eine fixierte Kopfleiste, die den gerade angesteuerten Link überdeckt, oder ein Einwilligungsbanner, das den unteren Seitenrand verdeckt, während die Nutzerin durch die Fußzeile tabuliert, machen die Seite nicht konform.

Zielgröße

Das neue WCAG-2.2-Kriterium 2.5.8 (Stufe AA) verlangt, dass Ziele für Zeigeraktionen mindestens 24 mal 24 CSS-Pixel groß sind. Es gibt Ausnahmen: Ein kleineres Ziel bleibt zulässig, wenn ein ausreichender Abstand es von benachbarten Zielen trennt, wenn dieselbe Funktion über ein anderes konformes Bedienelement auf der Seite angeboten wird, wenn der Link in einem Satz steht oder wenn die Größe vom Browser und nicht vom Autor festgelegt wird.

Typische Fehlerfälle sind eng gesetzte Seitenzahlen in einer Paginierung, das Schließkreuz eines modalen Dialogs auf dem Smartphone oder Teilen-Symbole, die ohne Abstand nebeneinanderstehen. Dieses Kriterium gibt es im RGAA 4.1.2 nicht; in der EN 301 549 V4.1.1 ist es dagegen enthalten. Die Korrektur besteht meist darin, einige Komponenten des Designsystems anzupassen, was auch Menschen mit Tremor und allen Smartphone-Nutzern zugutekommt.

Barrierefreie Authentifizierung

Das WCAG-Kriterium 3.3.8 (Stufe AA) verbietet, für die Anmeldung einen kognitiven Funktionstest zu verlangen, etwa sich ein Passwort zu merken, Zeichen abzuschreiben oder ein Rätsel zu lösen, sofern keine Alternative oder Hilfe angeboten wird. Laut der erläuternden Dokumentation des W3C sind Passwortmanager und Kopieren und Einfügen zulässige Hilfen: Eine Website, die das Einfügen des Passworts blockiert oder das automatische Ausfüllen der Felder verhindert, erfüllt das Kriterium nicht.

Zwei Beispiele begegnen uns in Kundenportalen immer wieder. Eine virtuelle Tastatur, deren Ziffern bei jeder Anmeldung die Position wechseln, verlangt eine Suchleistung ohne Alternative. Und ein per SMS empfangener Code, der in sechs getrennte Felder eingegeben werden muss, die das Einfügen verweigern, zwingt zum Abschreiben. Ein Captcha zur Objekterkennung („Wählen Sie alle Bilder mit einem Fahrrad“) ist auf Stufe AA zulässig, ein Captcha, das das Abtippen eines verzerrten Textes ohne andere Anmeldemethode verlangt, dagegen nicht.

Untertitel

Das WCAG-Kriterium 1.2.2 (Stufe A) verlangt synchronisierte Untertitel für aufgezeichnete Videos mit Ton; der RGAA bildet es in den Kriterien 4.3 (Vorhandensein) und 4.4 (Qualität) ab. Betroffen sind etwa das nachträglich veröffentlichte Video einer Gemeinderatssitzung, ein Produktvideo oder ein Schulungsvideo. Automatisch erzeugte und nie überprüfte Untertitel scheitern häufig am Qualitätskriterium.

Für Live-Inhalte wie ein Webinar oder die Übertragung einer öffentlichen Sitzung verlangt das WCAG-Kriterium 1.2.4 (Stufe AA) Echtzeituntertitel. Im RGAA 4.1.2 gibt es dafür kein Kriterium, bei einem Audit nach WCAG oder EN 301 549 gilt es jedoch. Kapitel 7 der Norm ergänzt eine Anforderung auf der Seite des Players: Er muss Untertitel anzeigen und bei der Übertragung erhalten können.

Mehrere Länder, ein Programm: einen Leitstandard wählen

Eine Gruppe, die einen Onlineshop in Luxemburg, Belgien und Frankreich betreibt, dazu eine gemeinsame App und ein Kundenportal in der Schweiz, kann nicht vier getrennte Barrierefreiheitsprogramme führen. Am wirksamsten ist es, einen Leitstandard zu wählen, ihn auf alle gemeinsam genutzten Komponenten anzuwenden und die nationalen Bewertungen dort zu erstellen, wo das Gesetz sie verlangt.

1. Erfassen Sie Ihre Dienste und die geltenden Regelungen. Halten Sie für jede Website, jede App und jede Dokumentenart fest, in welchen Ländern sie angeboten wird, welchen Status die herausgebende Einheit hat (öffentlich, privat, vom EAA erfasst oder nicht) und welche Dokumente zu veröffentlichen sind: Erklärung zur Barrierefreiheit, die vom EAA verlangten Informationen, in Frankreich der mehrjährige Umsetzungsplan.
2. Wählen Sie einen anspruchsvollen Leitstandard. Die WCAG 2.2 Stufe AA, ergänzt um die für Ihre Dienste relevanten Kapitel der EN 301 549 (Software, Dokumentation, Support, Echtzeitkommunikation), decken inhaltlich die Anforderungen von RAWeb, RAAM, eCH-0059 und RGAA ab.
3. Prüfen Sie zuerst die gemeinsam genutzten Komponenten. Designsystem, Seitenvorlagen, Bestellprozess und Anmeldung sind in allen Märkten gleich: Eine einmal vorgenommene Korrektur wirkt in allen Ländern.
4. Erstellen Sie die vorgeschriebenen nationalen Bewertungen. Wo ein nationaler Prüfkatalog vorgeschrieben ist, etwa der RAWeb für eine öffentliche Stelle in Luxemburg oder der RGAA für einen Dienst nach Artikel 47 in Frankreich, führen Sie das Audit nach diesem Katalog durch, um einen anerkannten Konformitätsgrad und eine gültige Erklärung zu erhalten.
5. Vereinheitlichen Sie Ihre Kennzahlen. Verfolgen Sie eine gemeinsame Kennzahl, zum Beispiel die Zahl der nicht erfüllten Kriterien der WCAG 2.2 AA pro Nutzerpfad, und verwenden Sie die nationalen Konformitätsgrade nur für die Erklärungen.

Der häufigste Fehler besteht darin, ein RGAA-Audit als Nachweis der Konformität mit dem European Accessibility Act vorzulegen: Es deckt weder die neuen Kriterien der WCAG 2.2 noch alle Anforderungen der Norm an Dokumentation und Support ab. Umgekehrt gilt ebenso: Ein WCAG-2.2-Bericht genügt nicht, um eine Erklärung nach RGAA zu erstellen. Ein Konformitätsaudit nach WCAG und EN 301 549 dient als Leitlinie und lässt sich mit einem nationalen Audit kombinieren, wenn das Gesetz es verlangt. Die besonderen Herausforderungen von Konzernen behandelt die Seite Großunternehmen.

Prüfmethode: von der Stichprobe zum Maßnahmenplan

Unabhängig vom Standard folgt ein seriöses Barrierefreiheitsaudit denselben Schritten. Was sich unterscheidet, sind der Kriterienkatalog und die Form des Ergebnisses. Unser Leitfaden zur digitalen Barrierefreiheit stellt das Vorgehen insgesamt vor; hier der Ablauf eines Konformitätsaudits.

1. Auftragsklärung. Wahl des Standards und seiner Version, Abgrenzung des Umfangs (Website, Subdomains, geschützter Bereich, App), Testumgebung und Zugang zu Demokonten.
2. Zusammenstellung der Stichprobe. Die Methode von RGAA und RAWeb verlangt eine repräsentative Stichprobe: typische Seiten, sofern vorhanden (Startseite, Kontakt, Impressum, Erklärung zur Barrierefreiheit, Sitemap, Hilfe, Anmeldung), die meistbesuchten Seiten, repräsentative Seiten jeder Vorlage und alle Schritte der wichtigsten Prozesse, etwa die Beantragung einer Urkunde oder ein Kauf.
3. Manuelle Prüfung Kriterium für Kriterium. Die Prüferin kontrolliert jedes Kriterium auf jeder Seite der Stichprobe, mit der Tastatur, mit dem Code-Inspektor und mit Messwerkzeugen (Kontrast, Überschriftenstruktur). Dieser Schritt nimmt die meiste Zeit in Anspruch.
4. Prüfung mit assistiven Technologien. Komplexe Komponenten wie ein Ausklappmenü, eine interaktive Karte oder ein modaler Dialog werden mit Screenreadern (NVDA, JAWS, VoiceOver, TalkBack) und in der Vergrößerung getestet, um zu prüfen, was tatsächlich ausgegeben wird.
5. Berechnung des Ergebnisses und Bericht. Je nach Standard enthält der Bericht einen Konformitätsgrad (RGAA, RAWeb, RAAM) oder einen Status pro Kriterium (WCAG, EN 301 549). Jede Nichtkonformität wird verortet, veranschaulicht und mit einer Empfehlung zur Behebung versehen.
6. Maßnahmenplan und Nachprüfung. Die Nichtkonformitäten werden nach Auswirkung auf die Nutzer und nach Aufwand priorisiert; anschließend überprüft eine Nachprüfung die Korrekturen, bevor die Erklärung aktualisiert wird.

Was automatische Werkzeuge nicht erkennen

Browsererweiterungen und Crawler sind nützlich, um wiederkehrende Fehler schnell zu finden: Bild ohne alt-Attribut, Feld ohne Beschriftung, zu geringer Kontrast von Text auf einfarbigem Hintergrund, nicht deklarierte Sprache. Die Angemessenheit können sie nicht beurteilen: Eine Alternative „Schaltfläche“ auf dem Bild eines Buttons „Bezahlen“ besteht den automatischen Test, ist aber nicht konform. Ebenso wenig erkennen sie eine Tastaturfalle in einem modalen Dialog, eine unlogische Tabulatorreihenfolge, Text auf einem Foto oder ein Video ohne Untertitel.

Die Punktzahl eines automatischen Werkzeugs ist deshalb kein Konformitätsgrad und kann keine Erklärung zur Barrierefreiheit begründen. In unseren Audits dienen Werkzeuge dazu, viele Seiten schnell abzudecken, jedes Kriterium wird aber manuell geprüft; ein vollständiges Audit dauert im Durchschnitt drei Wochen. Ob die Nutzerpfade wirklich funktionieren, zeigt ergänzend ein Test mit Menschen mit Behinderungen.

PDF-Dokumente und mobile Apps: die blinden Flecken vieler Audits

PDF-Dokumente

Dokumente zum Herunterladen werden oft vergessen, obwohl sie wesentliche Informationen enthalten: Beschlüsse, Protokolle, Formulare, allgemeine Geschäftsbedingungen, Jahresberichte. Die Norm EN 301 549 widmet ihnen Kapitel 10, das die WCAG-Kriterien auf Nicht-Web-Dokumente anwendet. Luxemburg verfügt mit dem RAPDF über einen eigenen Prüfkatalog, der an der Norm PDF/UA-2 ausgerichtet ist, und der RGAA behandelt sie in Kriterium 13.3, das für jedes Office-Dokument zum Herunterladen eine barrierefreie Fassung verlangt.

Ein eingescanntes PDF eines Gemeinderatsbeschlusses ist ein reines Bild: Für einen Screenreader ist es unabhängig von der Scanqualität unlesbar. Ein barrierefreies PDF ist mit Tags versehen (Überschriften, Listen, Tabellen), hat eine logische Lesereihenfolge, einen Dokumenttitel, eine deklarierte Sprache und Alternativen für seine Bilder. Für wesentliche Informationen ist es oft die nachhaltigste Lösung, den Inhalt in HTML zu veröffentlichen und das PDF ergänzend anzubieten.

Mobile Apps

Eine native App fällt unter Kapitel 11 der Norm EN 301 549, das Software gewidmet ist und die WCAG-Kriterien auf den Kontext einer App überträgt. In Luxemburg liefert der RAAM 1.1 den offiziellen Prüfkatalog. In Belgien und für Schweizer Anbieter, die in die EU verkaufen, ist die Norm selbst die Referenz. In Frankreich fallen mobile Apps unter Artikel 47 und werden derzeit mit dem RGAA bewertet; der RGAA 5 soll eigene Kriterien und Tests für Mobilgeräte festlegen.

Ein App-Audit findet auf echten Geräten statt, mit VoiceOver unter iOS und TalkBack unter Android. Die heikelsten Prüfpunkte sind die Ausgabe von Schaltflächen, die nur als Symbol dargestellt werden, die Berücksichtigung der in den Telefoneinstellungen gewählten Schriftgröße, die Darstellung im Hoch- und Querformat (WCAG-Kriterium 1.3.4), komplexe Gesten ohne Alternative (Kriterium 2.5.1) und die Größe der Touch-Ziele. Für diesen letzten Punkt legen die WCAG 2.2 und die EN 301 549 V4.1.1 jetzt ein Minimum fest, während der RAAM 1.1 und der RGAA 4.1.2 keines vorsehen.

Maßnahmenplan: zwölf Monate bis zum richtigen Niveau

Die Texte werden sich in den kommenden Monaten weiterentwickeln, doch keiner davon rechtfertigt Abwarten: Die angekündigten neuen Versionen präzisieren die geltenden Anforderungen, ohne sie in Frage zu stellen. Hier eine realistische Abfolge für eine Organisation, die ihren Ausgangsstand noch nicht kennt.

1. Monat 1: Bestandsaufnahme. Erfassen Sie Ihre Websites, Apps, geschützten Bereiche und Dokumentenarten mit ihrer Zielgruppe, ihren Angebotsländern und der jeweils geltenden Rechtsgrundlage.
2. Monat 1 und 2: Wahl des Standards. Bestimmen Sie für jeden Dienst den vorgeschriebenen Prüfkatalog (RAWeb, RAAM, EN 301 549, eCH-0059, RGAA) und legen Sie die WCAG 2.2 Stufe AA als gemeinsamen Leitstandard fest.
3. Monat 2 und 3: Erstaudit. Lassen Sie vorrangig die meistgenutzten Dienste und die Pfade prüfen, bei denen es für die Nutzer um etwas geht: Anmeldung, Zahlung, Terminbuchung, Einreichen eines Antrags.
4. Monat 3: Veröffentlichung. Veröffentlichen oder aktualisieren Sie die Erklärung zur Barrierefreiheit und, in Frankreich, den mehrjährigen Umsetzungsplan und den jährlichen Aktionsplan. Die erforderlichen Angaben erläutert unser Artikel über die Erklärung zur Barrierefreiheit.
5. Monat 3 bis 9: Korrekturen nach Komponenten. Korrigieren Sie zuerst das Designsystem und die Vorlagen, dann die Inhalte. Verankern Sie eine Barrierefreiheits-Abnahme in jeder Auslieferung, um Rückschritte zu vermeiden.
6. Monat 4 bis 12: Kompetenzaufbau. Schulen Sie die Rollen, die Inhalte und Code erstellen: Entwicklung, Design, Redaktion, Einkauf. Schulungen nach Rolle verhindern, dass dieselben Fehler wiederkehren.
7. Monat 12: Nachprüfung. Messen Sie die Fortschritte nach dem dann geltenden Standard und aktualisieren Sie die Erklärung.

Der Zeitplan im Blick

• bis Ende 2026: erwartete Veröffentlichung der Fundstelle der EN 301 549 V4.1.1 im Amtsblatt der Europäischen Union, die ihr die Konformitätsvermutung verleiht;
• Ende 2026: angekündigte Veröffentlichung des RGAA 5 durch die DINUM, mit Integration der WCAG 2.2; frühere Erklärungen bleiben 18 Monate gültig, höchstens drei Jahre;
• Februar 2027: angekündigte Veröffentlichung von RAWeb 2 und RAAM 2 in Luxemburg, kompatibel mit der EN 301 549 V4.1.1;
• ohne festen Termin: Teilrevision des BehiG in der Schweiz und Fertigstellung der WCAG 3 durch den W3C, die die WCAG 2 auf Jahre hinaus nicht ablösen werden.

Den Standard jedes Landes auf einen Blick finden Sie auf unserer Seite Standards und Pflichten sowie auf den Länderseiten Luxemburg, Schweiz und Frankreich.

Häufige Fragen