Aktualisiert am 6. September 2026. Die neue EN 301 549 V4.1.1 ist veröffentlicht. ETSI führt sie seit Anfang September 2026 als fertige Norm und nicht mehr als Abstimmungsentwurf. Für Websitebetreiber ist vor allem eine Änderung wichtig: Die Anforderungen an Webseiten, digitale Dokumente und Software sind nun an WCAG 2.2 angeglichen.
Die Veröffentlichung allein schafft allerdings noch keine neue gesetzliche Pflicht. Für eine europäische Konformitätsvermutung muss die konkrete Normfassung zusätzlich im Amtsblatt der Europäischen Union zitiert werden. Bis dahin sollten Unternehmen die bereits geltenden BFSG-Anforderungen erfüllen und WCAG 2.2 bei neuen Projekten als zukunftsfesten Qualitätsmaßstab einplanen.
Kurz zusammengefasst: EN 301 549 V4.1.1 ist veröffentlicht, enthält WCAG 2.2 und erstmals Zuordnungen zum European Accessibility Act. Sie ist nach dem hier geprüften Stand aber noch nicht im EU-Amtsblatt zitiert. Unternehmen sollten bestehende BFSG-Pflichten weiter erfüllen und bei neuen Projekten zusätzlich die sechs neuen WCAG-2.2-Kriterien der Stufen A und AA berücksichtigen.
Was gilt bei EN 301 549 V4.1.1 aktuell?
EN 301 549 beschreibt Barrierefreiheitsanforderungen an Produkte und Dienstleistungen der Informations- und Kommunikationstechnik. Die Norm betrifft damit deutlich mehr als Websites. Sie umfasst unter anderem mobile Anwendungen, digitale Dokumente, Software, Hardware und Selbstbedienungsterminals.
ETSI führt EN 301 549 V4.1.1 im Bereich Human Factors seit dem 3. September 2026 ausdrücklich als veröffentlicht. Auch der offizielle Downloadbereich der Norm bezeichnet V4.1.1 (2026-09) als „Publication“. Damit ist der formale Normungs- und Abstimmungsprozess abgeschlossen.
Die neue Fassung wurde im Auftrag der Europäischen Kommission erarbeitet. Sie soll die technische Norm sowohl für die EU-Richtlinie über barrierefreie Websites öffentlicher Stellen als auch für den European Accessibility Act weiterentwickeln. Veröffentlichung und rechtliche Harmonisierung sind dennoch zwei getrennte Schritte: Die Zitierung im EU-Amtsblatt steht nach dem hier geprüften Stand noch aus.
Welche Änderungen enthält die neue Norm?
Webseiten, Dokumente und Software werden an WCAG 2.2 angeglichen
Die Kapitel 9, 10 und 11 betreffen Webinhalte, Nicht-Web-Dokumente und Nicht-Web-Software. Sie wurden an WCAG 2.2 angepasst. Für Webseiten rücken dadurch Anforderungen in den Fokus, die in der bisher im EU-Amtsblatt zitierten Version 3.2.1 noch nicht enthalten sind: sichtbarer und unverdeckter Tastaturfokus, Alternativen zu Ziehbewegungen, ausreichend große Bedienelemente, konsistente Hilfe, das Vermeiden unnötiger Doppeleingaben und besser zugängliche Anmeldeverfahren.
WCAG 2.2 wurde bereits am 5. Oktober 2023 als W3C Recommendation veröffentlicht. Das W3C erläutert die neuen Kriterien in WCAG 2.2 und empfiehlt die neue Version als Ziel für aktuelle Projekte. Eine Website, die WCAG 2.2 erfüllt, erfüllt grundsätzlich auch WCAG 2.1; ausgenommen von dieser einfachen Rückwärtsbetrachtung ist das in WCAG 2.2 entfernte Kriterium 4.1.1 „Parsing“.
Neue Anhänge ordnen Anforderungen den EU-Richtlinien zu
Ein technischer Standard kann viele Anforderungen enthalten, die nicht für jedes Gesetz und nicht für jedes Produkt gleichermaßen gelten. Deshalb sind die Zuordnungen in den Anhängen wichtig. V4.1.1 enthält einen überarbeiteten Anhang ZA für die Web Accessibility Directive und erstmals einen Anhang ZB für den European Accessibility Act. Ein zusätzlicher Abschnitt A.2 unterstützt die Bewertung der Anforderungen des EAA.
Diese Tabellen helfen später dabei, die Verbindung zwischen gesetzlichen Anforderungen und prüfbaren technischen Kriterien herzustellen. Sie ersetzen jedoch nicht die Prüfung, ob ein konkretes Angebot überhaupt in den Anwendungsbereich des BFSG fällt.
Auch Echtzeitkommunikation wird erweitert
Die neue Norm überarbeitet außerdem Anforderungen an Echtzeittext und „Total Conversation“. Dabei werden Sprache, Video und Text so kombiniert, dass Menschen je nach Bedarf unterschiedliche Kommunikationskanäle nutzen können. Für eine normale Unternehmenswebsite ist das oft kein unmittelbarer Entwicklungsauftrag. Für Kommunikationsdienste, Kundendienstlösungen und bestimmte Produkte kann dieser Bereich jedoch relevant werden.
Was bedeutet Version 4.1.1 für BFSG und European Accessibility Act?
Die wichtigste Botschaft lautet: Auch eine veröffentlichte Norm erzeugt nicht automatisch eine neue unmittelbare Pflicht. Die Europäische Kommission erklärt auf ihrer Seite zu Standards und Harmonisierung bei Web-Barrierefreiheit, dass eine konkrete Version einer Norm im Amtsblatt der Europäischen Union zitiert werden muss, damit sie auf europäischer Ebene eine Konformitätsvermutung auslösen kann.
Die derzeit für die Web Accessibility Directive im EU-Amtsblatt zitierte Fassung ist weiterhin EN 301 549 V3.2.1. WCAG 2.2 wird deshalb nicht allein durch die Veröffentlichung von V4.1.1 automatisch zum rechtlich vermuteten europäischen Prüfmaßstab. Für den EAA und seine deutsche Umsetzung durch das BFSG ist die neue Version besonders bedeutsam, weil sie ausdrücklich zur Unterstützung dieser Richtlinie entwickelt wurde. Ob, wann und mit welchem Umfang V4.1.1 im EU-Amtsblatt zitiert wird, muss aber abgewartet werden.
Für Unternehmen bedeutet das nicht, dass sie bis dahin nichts tun müssen. Das BFSG und die Barrierefreiheitsstärkungsgesetz-Verordnung gelten bereits für die erfassten Produkte und Dienstleistungen. Das Bundesministerium für Arbeit und Soziales erläutert den Anwendungsbereich des BFSG. Welche Anforderungen für ein konkretes Unternehmen gelten, hängt vom Angebot, der Rolle des Unternehmens und möglichen Ausnahmen ab.
Wer lediglich „WCAG 2.1 erfüllt“ auf eine Website schreibt, hat damit also weder automatisch alle Anforderungen der EN 301 549 noch sämtliche Pflichten des BFSG nachgewiesen. Umgekehrt ist die neue Norm eine wertvolle technische Orientierung für neue Projekte.
Sechs neue WCAG-2.2-Kriterien der Stufen A und AA
1. Fokus darf nicht vollständig verdeckt sein
Wenn ein Element mit der Tastatur fokussiert wird, darf es nicht komplett hinter einem feststehenden Header, Cookie-Banner, Chatfenster oder anderen überlagernden Element verschwinden. In der Praxis sollte man komplette Seiten mit der Tabulatortaste durchlaufen und dabei besonders Sticky-Navigationen, Dialoge und mobile Ansichten prüfen.
2. Ziehbewegungen brauchen eine Alternative
Funktionen, die Drag-and-drop oder eine Ziehbewegung verlangen, müssen auch ohne diese Bewegung nutzbar sein, sofern das Ziehen nicht wesentlich ist. Ein sortierbares Element kann beispielsweise zusätzlich Schaltflächen „Nach oben“ und „Nach unten“ erhalten. Ein Schieberegler sollte sich auch per Tastatur oder über ein Eingabefeld bedienen lassen.
3. Kleine Klickziele werden zum konkreten Prüfthema
Das Kriterium „Target Size (Minimum)“ verlangt bei Stufe AA grundsätzlich eine Mindestgröße von 24 mal 24 CSS-Pixeln oder ausreichenden Abstand zu benachbarten Zielen; es gibt definierte Ausnahmen. Besonders häufig betroffen sind kleine Schließen-Symbole, eng gesetzte Paginationen, Icon-Leisten und Links in mobilen Menüs. Größere Ziele sind meist nicht nur barrierefreier, sondern reduzieren Bedienfehler für alle.
4. Hilfe muss konsistent auffindbar sein
Wenn Kontaktmöglichkeiten, Chats oder Selbsthilfeangebote auf mehreren Seiten wiederholt werden, sollen sie in derselben relativen Reihenfolge erscheinen. Wer den Kontaktlink auf einer Seite im Kopfbereich, auf der nächsten im Footer und im Bestellprozess an einer völlig anderen Stelle platziert, erschwert Menschen mit kognitiven Einschränkungen die Orientierung.
5. Bereits eingegebene Daten nicht unnötig erneut abfragen
Informationen, die in einem Prozess bereits eingegeben wurden, sollen automatisch übernommen oder zur Auswahl angeboten werden. Ein Checkout sollte eine Lieferadresse beispielsweise für die Rechnungsadresse übernehmen können. Ausnahmen bestehen unter anderem, wenn eine erneute Eingabe aus Sicherheitsgründen wesentlich ist oder die Information nicht mehr gültig ist.
6. Anmeldung ohne unnötige Gedächtnis- oder Denktests
Bei der Authentifizierung dürfen Menschen nicht ausschließlich zu kognitiven Tests gezwungen werden. Passwortmanager sowie Kopieren und Einfügen dürfen nicht blockiert werden. Wenn ein Prozess das Erinnern, Übertragen oder Lösen einer Aufgabe verlangt, muss eine geeignete Alternative oder Unterstützung vorhanden sein. Gerade Login, Kundenkonto und Einmalcode-Verfahren sollten deshalb manuell getestet werden.
Eine Einführung in bereits etablierte Anforderungen finden Sie in unserem Leitfaden zu den wichtigsten WCAG-Kriterien.
Was sollten Unternehmen jetzt konkret tun?
- Bestehende Pflichten nicht aufschieben: Klären Sie, ob Ihre Produkte oder Dienstleistungen unter das BFSG fallen. Warten Sie mit notwendigen Verbesserungen nicht auf die endgültige Version der Norm.
- WCAG 2.2 AA als Ziel für neue Projekte festlegen: Nehmen Sie die Version ausdrücklich in Lastenhefte, Designsysteme, Akzeptanzkriterien und Verträge auf. Formulieren Sie nicht nur pauschal „barrierefrei“, sondern definieren Sie nachprüfbare Anforderungen.
- Kritische Abläufe vollständig testen: Prüfen Sie Login, Suche, Formulare, Terminbuchung, Checkout und Bezahlung vom Anfang bis zum Ende. Einzelne automatisch geprüfte Seiten reichen nicht aus.
- Automatische und manuelle Prüfungen kombinieren: Ein Scanner findet viele technische Fehler, aber keine zuverlässige Fokusreihenfolge, verständliche Fehlermeldung oder wirklich nutzbare Tastaturinteraktion. Unsere Seite zum Prüfen der Website-Barrierefreiheit bietet einen ersten Einstieg.
- Nachweise pflegen: Dokumentieren Sie Prüfumfang, verwendete Versionen, Ergebnisse, Ausnahmen, Verantwortliche und Korrekturen. Barrierefreiheit ist ein wiederkehrender Qualitätsprozess, kein einmaliges Zertifikat.
- Die EU-Zitierung beobachten: Prüfen Sie bei einer Referenz von V4.1.1 im EU-Amtsblatt, ob Zuordnungen oder Übergangsfristen Änderungen an Ihrem Prüfplan erfordern.
Für einen strukturierten internen Rundgang können Sie außerdem unsere Checkliste für barrierefreie Websites verwenden. Sie ersetzt keine vollständige Konformitätsprüfung, hilft aber dabei, häufige Barrieren systematisch zu erfassen.
Was gehört jetzt in Ausschreibungen und Agenturverträge?
Neue Projekte sollten bereits auf WCAG 2.2 der Konformitätsstufe AA ausgerichtet werden. Sinnvoll sind außerdem klare Angaben zu den betroffenen Seitentypen und Nutzerwegen, den unterstützten Browsern und assistiven Technologien, manuellen Tastatur- und Screenreader-Tests sowie zur Behebung gefundener Mängel.
Verlangen Sie keine pauschale Zusage ohne Prüfkonzept. Ein belastbares Angebot beschreibt, wer prüft, welche Stichprobe verwendet wird, wie Ergebnisse dokumentiert werden und wann nach Korrekturen erneut getestet wird. Bei Produkten oder Dienstleistungen außerhalb klassischer Webseiten muss zusätzlich geklärt werden, welche weiteren Kapitel der EN 301 549 relevant sind.
Häufige Fragen zu EN 301 549 V4.1.1
Ist EN 301 549 V4.1.1 bereits endgültig?
Ja. ETSI führt V4.1.1 seit September 2026 als veröffentlichte Norm. Davon zu unterscheiden ist die noch ausstehende Zitierung im EU-Amtsblatt, die für eine europäische Konformitätsvermutung entscheidend ist.
Müssen Unternehmen WCAG 2.2 jetzt sofort erfüllen?
Nicht allein deshalb, weil WCAG 2.2 in der veröffentlichten EN 301 549 V4.1.1 enthalten ist. Bestehende gesetzliche Pflichten gelten unabhängig davon weiter. Für neue und überarbeitete Websites ist WCAG 2.2 AA aber ein sinnvoller, zukunftsfester Qualitätsmaßstab. Die konkrete Rechtslage sollte für das jeweilige Angebot geprüft werden.
Ist WCAG 2.1 damit veraltet?
WCAG 2.1 bleibt eine veröffentlichte W3C-Empfehlung und ist weiterhin Teil der derzeit harmonisierten EN 301 549 V3.2.1. Das W3C empfiehlt jedoch WCAG 2.2 für neue Arbeiten, weil die neue Version zusätzliche heutige Barrieren abdeckt und weitgehend rückwärtskompatibel ist.
Reicht eine automatische WCAG-Prüfung aus?
Nein. Automatische Werkzeuge sind nützlich, können aber nur einen Teil der Anforderungen zuverlässig bewerten. Kriterien wie verständliche Abläufe, sinnvoller Fokus, Alternativen zu Ziehbewegungen oder zugängliche Authentifizierung benötigen manuelle Tests und fachliche Einordnung.
Fazit
EN 301 549 V4.1.1 verbindet die europäische Normung deutlich enger mit WCAG 2.2 und dem European Accessibility Act. Der Normungsprozess ist abgeschlossen; die rechtlich wichtige Zitierung im EU-Amtsblatt steht noch aus. Die neue Fassung sollte bereits jetzt bei Websites, Apps, Dokumenten und Ausschreibungen berücksichtigt werden.
Unternehmen fahren am sichersten zweigleisig: Sie erfüllen die bereits geltenden Anforderungen und bauen neue digitale Angebote so, dass die sechs zusätzlichen WCAG-2.2-Kriterien der Stufen A und AA von Anfang an mitgedacht werden. Das senkt spätere Umbaukosten und verbessert die Bedienbarkeit schon heute.
Verwendete Quellen
- ETSI Human Factors: EN 301 549 V4.1.1 Published, abgerufen am 6. September 2026.
- ETSI Download Area: EN 301 549 V4.1.1 (2026-09), abgerufen am 6. September 2026.
- Europäische Kommission: Web Accessibility Directive – Standards and harmonisation, abgerufen am 6. September 2026.
- W3C Web Accessibility Initiative: What’s New in WCAG 2.2, abgerufen am 6. September 2026.
- Bundesministerium für Arbeit und Soziales: Barrierefreiheitsstärkungsgesetz, abgerufen am 6. September 2026.