EN 301 549 (Barrierefreiheitsnorm)

EN 301 549 ist die harmonisierte europäische Norm für die Barrierefreiheit von Produkten und Dienstleistungen der Informations- und Kommunikationstechnik (IKT). Herausgegeben wird sie gemeinsam von den drei europäischen Normungsorganisationen ETSI, CEN und CENELEC im Auftrag der Europäischen Kommission; sie überführt die Web Content Accessibility Guidelines (WCAG) in einen europäischen Normrahmen und ergänzt sie um Anforderungen an Hardware, Software, Dokumente, Echtzeitkommunikation und Support-Dienste.

Der vollständige Titel lautet „Accessibility requirements for ICT products and services". Für dich als Shop- oder Softwarebetreiber ist die Norm vor allem eines: der Prüfmaßstab, an dem Behörden, Marktüberwachung, Auftraggeber und Verbandsklagen messen, ob ein digitales Angebot barrierefrei ist. Sie ist keine Checkliste für Marketing-Zwecke, sondern ein technisches Regelwerk mit prüfbaren Anforderungen und zugehörigen Konformitätstests.

Wer die Norm herausgibt und in welchem Auftrag

EN 301 549 entstand ursprünglich unter dem Mandat M 376 der Europäischen Kommission und war zunächst als Beschaffungsnorm für die öffentliche Hand gedacht: Behörden sollten Barrierefreiheit in Ausschreibungen so beschreiben können, dass unterschiedliche Prüfer zum selben Ergebnis kommen. Die erste Fassung V1.1.1 erschien im Februar 2014. Erst mit den EU-Richtlinien zur Barrierefreiheit wurde daraus ein Regelwerk mit rechtlicher Hebelwirkung.

Der entscheidende Mechanismus heißt Konformitätsvermutung. Eine europäische Norm wird zur „harmonisierten" Norm, wenn zwei Bedingungen erfüllt sind: Sie wurde im Auftrag der Kommission von einer der drei Normungsorganisationen erarbeitet, und ihre Fundstelle wurde im Amtsblatt der Europäischen Union zitiert. Beide Punkte erläutert die Übersicht der Europäischen Kommission zu Standards und Harmonisierung ausführlich. Erst die Zitierung im Amtsblatt löst die Rechtswirkung aus.

Nicht jede Version wird harmonisiert

Ein verbreiteter Irrtum ist, dass jede neue Fassung automatisch gilt. Das Gegenteil ist der Fall: Von den bisherigen Versionen wurden nur zwei harmonisiert – V2.1.2 im Dezember 2018 und V3.2.1 am 18. August 2021, letztere durch den Durchführungsbeschluss (EU) 2021/1339, der den Beschluss (EU) 2018/2048 änderte. Die Zwischenversion V3.1.1 aus dem November 2019 wurde nie im Amtsblatt zitiert und hat damit auf europäischer Ebene keine unmittelbare Rechtswirkung entfaltet, obwohl sie fachlich brauchbar war.

Aufbau der Norm: Kapitel 4 bis 14 und die Annexe

Die Norm besteht in ihrer aktuellen Entwurfsfassung aus vierzehn Kapiteln und acht Anhängen. Alle Anforderungskapitel sind „self-scoping": Sie beginnen mit der Formulierung „Where ICT …" und gelten nur, wenn die genannte Voraussetzung auf dein Produkt zutrifft. Ein reiner Onlineshop ohne Videotelefonie muss Kapitel 6 also nicht erfüllen – er muss aber begründen können, warum es nicht anwendbar ist.

Die Anhänge – dort steckt die juristische Zuordnung

Die Anhänge sind kein Beiwerk, sondern der Teil, den Prüfer zuerst aufschlagen. Annex A enthält zwei Teile, die die Bewertung konkreter Produkte und Dienstleistungen gegen die Richtlinien ermöglichen. Annex B zeigt, welche technische Anforderung welches funktionale Leistungskriterium bedient. Annex C ist normativ und beschreibt für jede einzelne Anforderung, womit die Konformität hinreichend nachgewiesen ist – ausdrücklich ohne eine vollständige Testmethodik vorzugeben.

Für die Rechtsanwendung entscheidend sind die Z-Anhänge: Annex ZA ordnet die Anforderungen der Web-Richtlinie (EU) 2016/2102 zu, Annex ZB denen der Richtlinie (EU) 2019/882 (European Accessibility Act, EAA), Annex ZC den Anforderungen weiterer Richtlinien nach Anhang I Abschnitt VI des EAA. Annex ZB gliedert sich in fünf Tabellen: drei für Produkte, eine für alle erfassten Dienstleistungen und eine für bestimmte Dienstleistungen – darunter der elektronische Geschäftsverkehr.

Verhältnis zu WCAG 2.1 und WCAG 2.2

Kapitel 9 der Norm enthält keine eigenen Web-Anforderungen, sondern verweist Kriterium für Kriterium auf die WCAG des W3C. Die Nummerierung folgt dabei einer einfachen Regel: Aus WCAG-Erfolgskriterium 1.4.3 wird Anforderung 9.1.4.3. Die Norm stellt selbst klar, dass die Erfüllung von WCAG Level AA gleichbedeutend ist mit der Erfüllung der Klauseln 9.1 bis 9.4 samt den Konformitätsanforderungen aus Klausel 9.6.

Die heute harmonisierte Fassung V3.2.1 referenziert WCAG 2.1 auf Stufe AA. Das ist der Mindeststandard, auf den sich in Deutschland faktisch alle Prüfungen stützen. Die kommende Fassung richtet die Kapitel 9, 10 und 11 dagegen an WCAG 2.2 aus. WCAG 2.2 ist inhaltlich identisch mit ISO/IEC 40500:2025.

Die sechs Kriterien, die mit WCAG 2.2 dazukommen

WCAG 2.2 ergänzt neun neue Erfolgskriterien, von denen sechs auf den Stufen A und AA liegen und damit für eine AA-Konformität verbindlich werden:

• 2.4.11 Focus Not Obscured (Minimum), AA – ein per Tastatur fokussiertes Element darf nicht vollständig durch anderen Inhalt verdeckt sein. Klassischer Fehlerfall: der Sticky-Header, der beim Durchtabben das aktive Formularfeld überlagert.
• 2.5.7 Dragging Movements, AA – Funktionen, die Ziehbewegungen erfordern, brauchen eine Alternative ohne Ziehen. Betrifft Preis-Slider und Bildvergleichs-Regler.
• 2.5.8 Target Size (Minimum), AA – Klick- und Tippziele sind mindestens 24 × 24 CSS-Pixel groß, sofern keine der Ausnahmen greift.
• 3.2.6 Consistent Help, A – Hilfefunktionen erscheinen auf allen Seiten an derselben relativen Position.
• 3.3.7 Redundant Entry, A – bereits eingegebene Informationen werden im selben Prozess nicht erneut abgefragt, sondern vorausgefüllt oder zur Auswahl angeboten.
• 3.3.8 Accessible Authentication (Minimum), AA – kein Anmeldeschritt darf einen kognitiven Test verlangen, ohne eine Alternative oder Hilfe anzubieten.

Gleichzeitig entfällt ein Kriterium: Die Anforderung 9.4.1.1 ist in der Entwurfsfassung als „Void" markiert. Sie referenzierte das WCAG-Kriterium 4.1.1 Parsing, das in WCAG 2.2 gestrichen wurde, weil die damit adressierten Probleme entweder nicht mehr auftreten oder von anderen Kriterien abgedeckt sind. Wer noch Audit-Berichte mit Parsing-Findings herumliegen hat, sollte das wissen.

Versionen und Rechtsstand: Warum V3.2.1 nicht die EAA-Norm ist

An dieser Stelle liegen die meisten Beiträge im Netz daneben. Die im Amtsblatt zitierte Version 3.2.1 wurde unter der Normungsanfrage C(2017)2585 final (Mandat M 554) für die Web-Richtlinie (EU) 2016/2102 erstellt – also für öffentliche Stellen. Sie ist keine EAA-Norm, auch wenn sie in der Praxis fortlaufend als solche zitiert wird.

Die erste Fassung, die unter dem EAA-Mandat entsteht, ist V4.1. Sie wird auf Basis der Normungsanfrage C(2022) 6456 final – Standardisierungsauftrag M 587 – erarbeitet, richtet die Web-Kapitel an WCAG 2.2 aus, überarbeitet die Real-Time-Text-Anforderungen in Kapitel 6 grundlegend und ergänzt sie um Total Conversation. Neu ist außerdem der bereits erwähnte Annex ZB, der die EAA-Anforderungen zuordnet, sowie eine Klausel A.2 zur Bewertung konkreter Produkte und Dienstleistungen gegen den EAA.

Der Final draft EN 301 549 V4.1.0 vom Juni 2026 liegt öffentlich vor und steckt im Abstimmungsverfahren von ETSI (Vote-Phase vom 25. Juni bis 24. August 2026). Die Änderungshistorie der Norm weist die überarbeitete Fassung als V4.1.1 aus. Das Dokument selbst formuliert die Rechtslage im Konjunktiv: Erst wenn es im Amtsblatt der Europäischen Union unter der Richtlinie zitiert ist, begründet die Einhaltung der in Klausel A.2 genannten normativen Klauseln eine Konformitätsvermutung.

Ein Termin für die Amtsblatt-Zitierung ist nicht zugesagt. Nach dem hier geprüften Stand (25. August 2026) ist unter der Richtlinie (EU) 2019/882 keine Fassung von EN 301 549 im Amtsblatt zitiert. Alles, was du zu einem konkreten Datum liest, ist eine Prognose – auch die Übergangsfristen der Norm selbst sind nur relativ definiert: Die Ankündigung erfolgt drei Monate nach der ETSI-Veröffentlichung, die nationale Übernahme sechs Monate danach, die Rücknahme entgegenstehender nationaler Normen achtzehn Monate danach.

Was das für das BFSG praktisch bedeutet

Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 und setzt den EAA in deutsches Recht um. § 4 BFSG knüpft die Konformitätsvermutung an genau dieselbe Bedingung wie die europäische Ebene: Sie greift nur bei harmonisierten Normen, „deren Fundstellen im Amtsblatt der Europäischen Union veröffentlicht worden sind". Solange das für den EAA nicht geschehen ist, gibt es über EN 301 549 keine automatische Vermutungswirkung für BFSG-pflichtige Angebote.

Die Norm wird dadurch nicht bedeutungslos, im Gegenteil. Die BFSG-Verordnung verlangt in § 3 BFSGV, den Stand der Technik zu beachten, und beauftragt die Bundesfachstelle für Barrierefreiheit, die maßgeblichen Standards und Konformitätstabellen zu veröffentlichen. EN 301 549 ist dieser Stand der Technik – nur eben als fachlicher Maßstab, nicht als rechtlicher Automatismus. Wer sie einhält, erfüllt die materiellen Anforderungen; er muss das im Zweifel nur selbst nachweisen, statt sich auf eine Vermutung berufen zu können.

Betroffen sind nach § 1 Absatz 3 BFSG unter anderem „Dienstleistungen im elektronischen Geschäftsverkehr", also der klassische B2C-Onlineshop. Ausgenommen sind Kleinstunternehmen, die Dienstleistungen erbringen – definiert als Unternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz oder Jahresbilanzsumme. Reine B2B-Shops fallen nicht unter das Gesetz, weil es an Verbrauchern als Adressaten fehlt; hybride Shops sollten diese Abgrenzung sauber dokumentieren.

Öffentliche Stellen: BITV 2.0 statt BFSG

Für Behörden, Kommunen und andere öffentliche Stellen gilt nicht das BFSG, sondern die Barrierefreie-Informationstechnik-Verordnung. § 3 BITV 2.0 arbeitet mit derselben Konstruktion: Die Erfüllung der Anforderungen wird vermutet, wenn Angebote harmonisierten Normen entsprechen und diese im Amtsblatt genannt sind. Weil V3.2.1 dort für die Web-Richtlinie zitiert ist, funktioniert die Vermutungswirkung im öffentlichen Bereich heute – im privatwirtschaftlichen dagegen noch nicht. Das ist der praktische Unterschied zwischen beiden Regimen.

EN 301 549 im Onlineshop: Was du konkret ableitest

Aus der Norm wird ein Arbeitsplan, sobald du sie auf den Kaufpfad projizierst. Die Verordnung zum BFSG benennt in § 12 BFSGV allgemeine Anforderungen an Dienstleistungen – Informationen über mehr als einen Sinneskanal, auffindbar, verständlich, in Textformaten, die assistive Technik verarbeiten kann. § 19 BFSGV ergänzt für den elektronischen Geschäftsverkehr drei Punkte: Informationen zur Barrierefreiheit der verkauften Produkte, barrierefreie Identifizierungs-, Sicherheits- und Zahlungsfunktionen sowie barrierefreie Authentifizierungsmethoden und elektronische Signaturen.

Ein konkretes Beispiel: Kriterium 9.3.3.8 im Login

Nimm die Anforderung 9.3.3.8 der Norm, die auf WCAG-Erfolgskriterium 3.3.8 Accessible Authentication (Minimum) verweist. Der Wortlaut verlangt, dass in keinem Schritt eines Anmeldevorgangs ein kognitiver Test – etwa das Erinnern eines Passworts oder das Lösen eines Rätsels – erforderlich ist, sofern nicht eine Alternative, ein unterstützender Mechanismus, eine reine Objekterkennung oder die Identifikation eigener Inhalte angeboten wird.

Praktisch heißt das für einen Shopware-Shop: Ein Text-CAPTCHA im Registrierungsformular ist ein Verstoß, wenn es keine nicht-kognitive Alternative gibt. Ein Passwortfeld, das das Einfügen aus der Zwischenablage per JavaScript unterbindet, ebenfalls – die WCAG nennt Copy-and-paste und Passwortmanager-Unterstützung ausdrücklich als Mechanismen, die das Kriterium erfüllen. Beides sind Zeilen Code, keine Architekturfragen. Zusammen mit 3.3.7 Redundant Entry ergibt sich ein weiterer Prüfpunkt: Die Lieferadresse aus Schritt zwei darf im Bestellabschluss nicht ein zweites Mal abgefragt werden.

Was automatisierte Tests leisten – und was nicht

Automatisierte Prüfwerkzeuge wie axe, Lighthouse oder WAVE finden zuverlässig, was maschinell entscheidbar ist: fehlende alt-Attribute, unzureichende Kontrastwerte gegenüber der 4,5:1-Schwelle aus Kriterium 1.4.3, fehlende Formularlabels, unterbrochene Überschriftenhierarchien. Sie sind der günstigste erste Filter und gehören in jede CI-Pipeline.

Ein großer Teil der Kriterien ist aber nur menschlich beurteilbar. Ob ein Alternativtext den Zweck des Bildes tatsächlich beschreibt, ob die Fokusreihenfolge dem Sinnzusammenhang folgt, ob eine Fehlermeldung verständlich ist, ob 2.4.11 im echten Sticky-Header-Verhalten eingehalten wird – das entscheidet kein Scanner. Annex C der Norm liefert für jede Anforderung ein hinreichendes Nachweisverfahren, formuliert aber explizit keine Testmethodik. Eine belastbare Prüfung kombiniert daher automatisierte Scans, manuelle Tastaturtests, Screenreader-Stichproben und ein Review der Dokumente aus Kapitel 10.

Häufige Missverständnisse

• „EN 301 549 ist nur WCAG auf Europäisch." Falsch – Kapitel 5 bis 8 und 11 bis 13 enthalten Anforderungen an Hardware, Software, Echtzeittext und Support, die in den WCAG gar nicht vorkommen.
• „Wir erfüllen die Norm, also haben wir Rechtssicherheit." Nur teilweise. Für BFSG-pflichtige Dienstleistungen fehlt bislang die Amtsblatt-Zitierung unter dem EAA und damit die Vermutungswirkung.
• „Ein Overlay-Tool macht uns konform." Overlays adressieren die maschinell prüfbaren Symptome, nicht die Semantik im DOM. Keines der genannten Kriterien wird dadurch erfüllt.
• „Barrierefreiheit ist ein Projekt." § 14 Absatz 3 BFSG verlangt, dass die Anforderungen dauerhaft erfüllt werden, ausdrücklich auch bei Änderungen der harmonisierten Normen. Jedes Theme-Update ist damit ein Prüfanlass.

Wichtig ist außerdem die Dokumentationspflicht: Nach § 14 Absatz 1 Nummer 2 BFSG darf eine Dienstleistung nur angeboten werden, wenn der Erbringer die Informationen nach Anlage 3 Nummer 1 erstellt und barrierefrei öffentlich zugänglich gemacht hat. Wer eine Dienstleistung entgegen dieser Vorgabe anbietet, handelt nach § 37 Absatz 1 Nummer 8 BFSG ordnungswidrig; der Bußgeldrahmen reicht in diesem Fall bis zu hunderttausend Euro. Die Barrierefreiheitserklärung ist damit kein Beiwerk, sondern selbst eine bußgeldbewehrte Pflicht.

Für die Planung heißt das: Prüfe deinen Shop heute gegen WCAG 2.1 AA und die für dich anwendbaren Kapitel von EN 301 549 V3.2.1 – das ist der geltende Maßstab. Halte parallel die sechs neuen Kriterien aus WCAG 2.2 im Blick, weil sie mit V4.1 verbindlich werden, sobald die Fassung zitiert ist. Wer heute schon gegen WCAG 2.2 baut, spart sich den zweiten Durchgang; der Aufwand für Zielgrößen, Fokusverdeckung und Login-Alternativen ist im laufenden Betrieb deutlich kleiner als in einem nachgelagerten Sanierungsprojekt.