EN 301 549 V4.1.1 und WCAG 2.2: Was sich für Websites ändert

Die im September 2026 veröffentlichte EN 301 549 V4.1.1 stützt die Web-Anforderungen der europäischen Barrierefreiheitsnorm auf WCAG 2.2 Stufe AA statt auf WCAG 2.1. Für Websites bedeutet das sechs zusätzliche Erfolgskriterien der Stufen A und AA und ein gestrichenes Kriterium. Bis V4.1.1 im Amtsblatt der EU zitiert wird – erwartet Ende 2026 –, bleibt V3.2.1 (WCAG 2.1 AA) die harmonisierte Fassung.

Warum EN 301 549 wichtig ist

Der European Accessibility Act beschreibt die Barrierefreiheitsanforderungen funktional. Um zu zeigen, dass eine Website sie erfüllt, stützen sich Unternehmen auf die harmonisierte Norm EN 301 549: Wer eine harmonisierte Norm erfüllt, für den gilt die Vermutung der Konformität mit den davon abgedeckten Anforderungen. Ihr Kapitel zu Webinhalten übernimmt schlicht die Erfolgskriterien der WCAG. Wenn die Norm also von WCAG 2.1 auf WCAG 2.2 wechselt, verschiebt sich auch der Maßstab für Websites in der EU.

Der Zeitplan

Bis zur Zitierung ist V3.2.1 die Referenz für die Konformitätsvermutung. Danach ist zu erwarten, dass Behörden, Prüfer und öffentliche Auftraggeber auf V4.1.1 verweisen. Es können nationale Übergangsregelungen gelten; prüfen Sie diese für Ihr Land.

Was neu ist: die sechs WCAG-2.2-Kriterien

WCAG 2.2 ergänzt diese Kriterien der Stufen A und AA:

2.4.11 Fokus nicht verdeckt (Minimum) – AA

Erhält ein Element den Tastaturfokus, darf es nicht vollständig von anderen Inhalten verdeckt werden. In Shops sind die üblichen Verdächtigen Sticky Header, Cookie-Banner und Chat-Buttons, die den fokussierten Link oder Button überdecken.

2.5.7 Ziehbewegungen – AA

Alles, was Ziehen erfordert, muss auch mit einer einfachen Zeigeraktion funktionieren, etwa einem Klick oder Tippen. Denken Sie an Preisspannen-Slider, Listen, die per Drag-and-drop sortiert werden, und Karussells, die nur per Wischen bedienbar sind. Ergänzen Sie Plus-/Minus-Buttons oder Eingabefelder.

2.5.8 Zielgröße (Minimum) – AA

Klickbare Ziele müssen mindestens 24 × 24 CSS-Pixel groß sein oder genug Abstand zu anderen Zielen haben, mit Ausnahmen wie Links im Fließtext. Typische Probleme in Shops: winzige Mengenwähler, Farb- und Größenauswahl, Schließen-Symbole und Paginierungspunkte.

3.2.6 Konsistente Hilfe – A

Wenn Sie Hilfe anbieten – Kontaktdaten, einen Chat, einen FAQ-Link –, muss sie auf jeder Seite, auf der sie angeboten wird, an derselben relativen Stelle erscheinen.

3.3.7 Redundante Eingaben – A

Informationen, die Nutzer im selben Vorgang bereits eingegeben haben, sollen automatisch ausgefüllt oder auswählbar sein. Klassisches Beispiel: „Rechnungsadresse gleich Lieferadresse“.

3.3.8 Barrierefreie Authentifizierung (Minimum) – AA

Die Anmeldung darf nicht von einem kognitiven Funktionstest abhängen, etwa dem Merken eines Passworts oder dem Lösen eines Rätsels, es sei denn, es gibt eine Alternative oder einen Hilfsmechanismus. In der Praxis: Passwortmanager und Einfügen zulassen, Anmeldung per E-Mail oder Passkey anbieten und Rätsel-CAPTCHAs ohne Alternative vermeiden.

Was gestrichen wurde

4.1.1 Syntaxanalyse ist in WCAG 2.2 überholt und entfernt. Moderne Browser und assistive Technologien kommen mit den meisten Markup-Fehlern selbst zurecht. Probleme, die weiterhin relevant sind, etwa doppelte IDs, die die Zuordnung von Beschriftungen zerstören, werden durch andere Kriterien abgedeckt.

Ändert das viel für einen typischen Shop?

Wenn Ihre Website WCAG 2.1 AA bereits erfüllt, ist der Mehraufwand begrenzt und recht konkret: Fokus gegenüber Sticky-Elementen prüfen, kleine Ziele vergrößern, Alternativen zum Ziehen anbieten, Hilfe an einer festen Stelle platzieren, Daten nicht doppelt abfragen und die Anmeldung freundlicher gestalten. Die meisten dieser Verbesserungen bemerken Ihre Kundinnen und Kunden ohnehin – größere Ziele und weniger Abtippen helfen allen, die am Smartphone einkaufen.

Wenn Ihre Website noch nicht gegen WCAG 2.1 geprüft wurde, beginnen Sie mit den Grundlagen – Beschriftungen, Kontrast, Alternativtexte, Tastaturbedienung – und nehmen Sie die 2.2-Kriterien in dieselbe Runde auf. Es gibt keinen Grund, jetzt noch die alte Version anzustreben.

Was Automatisierung prüfen kann und was nicht

Von den neuen Kriterien lässt sich die Zielgröße teilweise automatisch prüfen. Nicht verdeckter Fokus, Alternativen zum Ziehen, konsistente Hilfe, redundante Eingaben und barrierefreie Authentifizierung brauchen überwiegend einen Menschen. Das ist ein weiterer Grund, warum ein automatischer Scan ein Ausgangspunkt ist. Unser Scan prüft gegen WCAG 2.2 AA und ordnet jeden Befund sowohl EN 301 549 V3.2.1 als auch V4.1.1 zu – und bleibt eine automatische Prüfung, kein vollständiges Audit, und keine Rechtsberatung.

Was das für Agenturen bedeutet

Wenn Sie Websites für Kunden bauen oder betreuen, passen Sie Ihre Definition of Done an: Neue Templates sollten von Anfang an WCAG 2.2 AA erfüllen. Zielgrößen und Fokusverhalten nachträglich einzubauen kostet mehr, als sie gleich mitzuplanen. Es ist auch ein guter Moment, bestehenden Kunden zu erklären, was sich geändert hat – sachlich, mit einer kurzen Liste konkreter Korrekturen statt mit Alarm.

Was Sie jetzt tun sollten

1. Streben Sie WCAG 2.2 AA an – bei neuen Projekten und Redesigns.
2. Nehmen Sie die sechs neuen Kriterien in Ihre QA-Checkliste auf – siehe unsere WCAG-2.2-Checkliste.
3. Aktualisieren Sie Ihre Barrierefreiheitsinformationen, wenn Sie den Maßstab ändern, gegen den Sie messen. Siehe den Leitfaden zur Barrierefreiheitserklärung.
4. Scannen Sie erneut nach den Änderungen und überwachen Sie Ihre Website weiter.

Den rechtlichen Rahmen erklärt der EAA-Leitfaden oder der praxisnahe EAA-Leitfaden für Online-Shops. Starten Sie eine kostenlose Prüfung, um zu sehen, wo Ihre Website heute steht.

Quellen

• W3C, What's new in WCAG 2.2: https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
• W3C, WCAG 2.2: https://www.w3.org/TR/WCAG22/
• National Disability Authority (Ireland), EN 301 549 published: https://nda.ie/news/en301549-published