Aufbau der Norm: Kapitel 4 bis 14 und die Annexe
Die Norm besteht in ihrer aktuellen Fassung V4.1.1 aus vierzehn Kapiteln und neun 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 derzeit im Amtsblatt zitierte Fassung V3.2.1 (unter der Web-Richtlinie für öffentliche Stellen) referenziert WCAG 2.1 auf Stufe AA. Darauf beruht die Untergrenze, von der Prüfungen in Deutschland in der Praxis ausgehen. Die im September 2026 veröffentlichte Fassung V4.1.1 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 Fassung V4.1.1 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 entstanden ist, ist V4.1.1. Sie wurde 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.
ETSI hat die Fassung EN 301 549 V4.1.1 im September 2026 veröffentlicht; angenommen wurde sie am 24. August 2026. Das Dokument selbst formuliert die Rechtslage als Bedingung: Erst wenn es im Amtsblatt der Europäischen Union unter der Richtlinie (EU) 2019/882 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 (11. Oktober 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. Die Fristen, die V4.1.1 selbst nennt, betreffen nur die nationalen Normungsorganisationen: Ankündigung bis 30. November 2026, nationale Übernahme bis 31. Mai 2027, Rücknahme entgegenstehender nationaler Normen bis 31. Mai 2028. Mit der Konformitätsvermutung haben diese Daten nichts zu tun.
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. Eine bestimmte Norm oder WCAG-Version nennt die Verordnung nicht. In der Praxis ist EN 301 549 der Bezugspunkt für diesen Stand der Technik, als fachlicher Maßstab und nicht als rechtlicher Automatismus. Wer sie einhält, hat gute Argumente für die Erfüllung der materiellen Anforderungen; er muss das im Zweifel aber 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. Wer ohnehin eine neue Web-Applikation plant, legt WCAG 2.2 AA am besten direkt als Abnahmekriterium fest.
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 mindestens gegen WCAG 2.1 AA und die für dich anwendbaren Kapitel von EN 301 549 V3.2.1; das ist in der Praxis die Untergrenze. Halte parallel die sechs neuen Kriterien aus WCAG 2.2 im Blick: V4.1.1 baut darauf auf, und sobald diese Fassung unter dem EAA im Amtsblatt zitiert ist, knüpft die Konformitätsvermutung an sie an. 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.
