EN 301 549 V4.1.1: Prüfprofil auf WCAG 2.2 vorbereiten

Was V4.1.1 an der Norm ändert

Angenommen wurde die neue Fassung am 24. August 2026 (ETSI), veröffentlicht im September 2026 (AccessibleEU). Für Websites bringt sie drei inhaltliche Änderungen, die AccessibleEU in einem Satz zusammenfasst: sechs neue Anforderungen aus WCAG 2.2, der Wegfall des veralteten Kriteriums 4.1.1 Parsing und die Pflicht, die Barrierefreiheitseinstellungen der Nutzer besser zu respektieren (AccessibleEU).

• Sechs neue A/AA-Anforderungen: 2.4.11 Fokus nicht verdeckt, 2.5.7 Ziehbewegungen, 2.5.8 Zielgröße, 3.2.6 Konsistente Hilfe, 3.3.7 Wiederholte Eingaben und 3.3.8 Zugängliche Authentifizierung. In der Norm stehen sie als Abschnitte 9.2.4.11 bis 9.3.3.8 (ETSI). WCAG 2.2 bringt gegenüber WCAG 2.1 insgesamt neun zusätzliche Erfolgskriterien (W3C), die Norm übernimmt davon die der Stufen A und AA.
• 4.1.1 Parsing entfällt: Der Abschnitt 9.4.1.1 ist in V4.1.1 leer, frühere Fassungen hatten an dieser Stelle noch das Kriterium 4.1.1 aus WCAG 2.0 und 2.1 (ETSI). Das W3C hat es aus WCAG 2.2 gestrichen, weil es keinen Nutzen mehr hat (W3C).
• Nutzereinstellungen für Webseiten: Neu ist Abschnitt 9.7. Eine Webseite darf die Darstellungsarten des Browsers nach den Einstellungen des Nutzers nicht blockieren und dokumentierte Barrierefreiheitsfunktionen der Plattform nicht ausdrücklich übersteuern, es sei denn, das ist für Inhalt oder Funktion wesentlich (ETSI). Als Beispiel nennt die Norm die CSS-Eigenschaft forced-color-adjust. V3.2.1 kannte Nutzereinstellungen nur für Software (Abschnitt 11.7).
• Bezug zum European Accessibility Act: V4.1.1 ist die erste Fassung der Norm, die eigens mit Blick auf den European Accessibility Act erarbeitet wurde (AccessibleEU). Ein neuer Anhang ZB ordnet ihre Anforderungen den grundlegenden Anforderungen der Richtlinie (EU) 2019/882 zu (ETSI).

Was die einzelnen Kriterien verlangen und wem sie helfen, erläutert das W3C in seiner Übersicht zu den Neuerungen in WCAG 2.2 (W3C). Hier geht es um eine andere Frage: Was bedeutet die neue Fassung für die laufende Prüfung einer Website, solange sie noch nicht rechtlich wirksam ist?

Was bis zur Zitierung im Amtsblatt gilt

Eine harmonisierte Norm wirkt nicht durch ihre Veröffentlichung, sondern durch ihre Fundstelle im Amtsblatt. Das Barrierefreiheitsstärkungsgesetz knüpft die Vermutung, dass ein Produkt oder eine Dienstleistung die Anforderungen erfüllt, ausdrücklich an harmonisierte Normen, deren Fundstellen im Amtsblatt der Europäischen Union veröffentlicht worden sind (BFSG). Dieselbe Mechanik steht in Artikel 15 der Richtlinie (EU) 2019/882 (EAA) und für Websites öffentlicher Stellen in Artikel 6 der Richtlinie (EU) 2016/2102 (WAD) sowie in § 3 Absatz 2 der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0). Die Kommission formuliert es in einem eigenen Durchführungsbeschluss so: Die Einhaltung einer harmonisierten Norm begründet die Konformitätsvermutung ab dem Tag, an dem ihre Referenz im Amtsblatt veröffentlicht ist (EU-Kommission).

Für V4.1.1 steht dieser Schritt noch aus. AccessibleEU, das Zentrum der EU-Kommission für Barrierefreiheit, schreibt dazu: Bis die Kommission EN 301 549 V4.1.1 formell im Amtsblatt zitiert, bleibt V3.2.1 aus dem Jahr 2021 der aktuelle Bezug, und diese Fassung beruht auf WCAG 2.1 Stufe AA (AccessibleEU). Die Norm selbst sagt es aus ihrer Sicht: Erst wenn sie im Amtsblatt unter der Richtlinie (EU) 2019/882 zitiert ist, begründet die Einhaltung ihrer normativen Abschnitte eine Konformitätsvermutung (ETSI). Ist das geschehen, gilt die Vermutung nach Angaben von AccessibleEU sowohl für den European Accessibility Act als auch für die Richtlinie über Websites öffentlicher Stellen (AccessibleEU).

Zitiert ist V3.2.1 seit dem Durchführungsbeschluss (EU) 2021/1339 vom 11. August 2021, und zwar zur Richtlinie (EU) 2016/2102 über die Websites öffentlicher Stellen (EU-Kommission). Einen Termin für die Zitierung der neuen Fassung nennt AccessibleEU nicht, und mit der Veröffentlichung ist ausdrücklich keine neue Frist verbunden. Termine, die im Netz kursieren, stammen aus Sekundärquellen. Die Daten im Vorspann der Norm sind etwas anderes: Nationale Normungsorganisationen müssen die Fassung bis 30. November 2026 ankündigen und bis 31. Mai 2027 als nationale Norm veröffentlichen oder anerkennen, widersprechende nationale Normen sind bis 31. Mai 2028 zurückzuziehen (ETSI). Mit der Konformitätsvermutung haben diese Fristen nichts zu tun.

Warum WCAG 2.2 trotzdem jetzt ins Prüfprofil gehört

Für einen Wechsel vor der Zitierung sprechen drei Gründe. Erstens schließt WCAG 2.2 die ältere Fassung ein: Websites, die WCAG 2.2 erfüllen, erfüllen auch WCAG 2.1 (W3C). Die Norm hält dieselbe Beziehung in ihren Abschnitten fest. Konformität mit WCAG 2.1 Stufe AA entspricht allen Abschnitten 9.1 bis 9.4 außer den sechs neuen (ETSI). Ein Profil auf WCAG 2.2 misst den heutigen Bezug also vollständig mit und zeigt zusätzlich, was nach der Zitierung fehlen würde.

Zweitens empfiehlt die zuständige Arbeitsgruppe des W3C, WCAG 2.2 als neues Konformitätsziel zu übernehmen, auch wenn formelle Pflichten noch ältere Fassungen nennen (W3C). AccessibleEU rät Organisationen in seiner Meldung ebenso, Websites und digitale Dokumente schon jetzt gegen WCAG 2.2 zu prüfen und Prüfprozesse sowie Audit-Checklisten zu aktualisieren (AccessibleEU).

Drittens verlangt das BFSG von Dienstleistern, Änderungen der harmonisierten Normen, auf die ihre Erklärung der Übereinstimmung verweist, gebührend zu berücksichtigen (BFSG). Das ist keine Frist, aber ein Auftrag, die Entwicklung zu verfolgen. Ein Prüfprofil, das beide Fassungen unterscheidet, ist dafür das passende Werkzeug.

Welche der sechs neuen Kriterien eine Maschine prüfen kann

Die Bilanz fällt schmal aus. Der quelloffene Prüfmotor axe-core führt in Version 4.12 für die neuen A/AA-Kriterien genau eine Regel: target-size für 2.5.8 Zielgröße (axe-core). Diese Regel ist zudem standardmäßig abgeschaltet. In der Regelübersicht heißt es dazu, die Regeln für WCAG 2.2 blieben deaktiviert, bis WCAG 2.2 breiter übernommen und verlangt werde (axe-core). Ein Werkzeug, das axe-core mit den Voreinstellungen startet, prüft 2.5.8 also gar nicht.

Im Prüfprofil von XICTRAQ® ist die Regel eingeschaltet. Der Barrierefreiheits-Scan ruft axe-core mit den Tags für WCAG 2.0, 2.1 und 2.2 der Stufen A und AA auf, damit läuft target-size in jedem Durchgang mit. Die übrigen fünf neuen Kriterien bleiben Handarbeit. Die Funktionsseite zum BFSG-Check nennt Konsistente Hilfe, Wiederholte Eingaben und Zugängliche Authentifizierung ausdrücklich als manuelle Prüfpunkte. Für 2.4.11 und 2.5.7 gilt dasselbe: Beide hängen am Zusammenspiel von Fokus, Layout und Bedienung, und keine Regel in axe-core trägt ein Tag für diese beiden Kriterien.

// Prüfprofil: WCAG 2.0, 2.1 und 2.2, jeweils Stufe A und AA
const results = await new AxeBuilder({ page })
  .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22a', 'wcag22aa'])
  .analyze();

// results.violations  -> Verstöße
// results.incomplete  -> nicht sicher entscheidbar, manuell prüfen
// results.passes      -> bestandene Regeln

Was die Regel zur Zielgröße abdeckt

Das Kriterium verlangt für Zeigeeingaben eine Zielgröße von mindestens 24 mal 24 CSS-Pixeln, nennt aber fünf Ausnahmen: genügend Abstand, eine gleichwertige zweite Bedienmöglichkeit, Ziele im Fließtext, vom Browser bestimmte Größen und Fälle, in denen eine bestimmte Darstellung wesentlich oder vorgeschrieben ist (W3C). Ob ein Link im Fließtext steht, kann eine Regel erkennen. Ob es auf derselben Seite eine gleichwertige zweite Bedienmöglichkeit gibt, oft nicht. axe-core führt target-size deshalb mit beiden Ergebnisarten, als Verstoß und als Fall zur Prüfung (axe-core). Im Bericht gehören die unsicheren Fälle in die manuelle Liste, nicht in den Papierkorb.

Auch die Gegenrichtung gehört ins Profil. Die Regeln zu 4.1.1 Parsing führt axe-core als veraltet, mit dem Tag wcag2a-obsolete (axe-core). Ein Profil mit den Tags oben ruft sie nicht auf. Für den heutigen Bezug ist das vertretbar: In der aktuellen Fassung von WCAG 2.1 vom 6. Mai 2025 heißt es, das Kriterium sei für Inhalte in HTML oder XML als erfüllt zu betrachten (W3C). Doppelte IDs, die Beschriftungen oder ARIA-Bezüge brechen, erfasst axe-core weiterhin über eine Regel zu 4.1.2.

Wie weit automatische Prüfung überhaupt reicht, zeigt die jährliche Auswertung von WebAIM. In der Ausgabe 2026 hatten 95,9 Prozent der Startseiten der eine Million meistbesuchten Websites automatisch erkannte WCAG-2-Fehler (WebAIM Million 2026). Die Autoren betonen zugleich, dass kein automatisches Werkzeug alle Konformitätsfehler findet und dass das Fehlen erkannter Fehler keine Barrierefreiheit belegt (WebAIM Million 2026). Für das Prüfprofil heißt das: Der automatische Teil ist das Netz, das häufige Fehler früh fängt. Die manuelle Checkliste ist kein Anhang, sondern der zweite tragende Teil.

Das Prüfprofil in drei Schichten aufbauen

Ein Prüfprofil ist mehr als eine Liste von Regeln. Es legt fest, was automatisch läuft, was ein Mensch prüft, auf welchen Seiten, in welchen Abständen und wie beides dokumentiert wird. Für die Übergangszeit hat sich ein Aufbau in drei Schichten bewährt, der beide Normfassungen bedient.

Seiten und Abläufe auswählen

WCAG kennt keine Konformität für Seitenteile. Sie gilt für vollständige Seiten, und wenn eine Seite Teil eines Ablaufs ist, müssen alle Seiten dieses Ablaufs die Stufe erfüllen (W3C). EN 301 549 V4.1.1 verlangt die fünf Konformitätsanforderungen von WCAG 2.2 in Abschnitt 9.6 ausdrücklich mit (ETSI). Für das Profil folgt daraus eine Auswahl nach Vorlagen und Abläufen, nicht nach einzelnen Adressen:

• Startseite, Übersichts- oder Kategorieseite, Detailseite und eine reine Inhaltsseite als Vertreter der Vorlagen
• die Anmeldung einschließlich „Passwort vergessen“, weil dort 3.3.8 greift
• Kontakt- und Anfrageformulare sowie die Bestellstrecke als vollständige Abläufe, weil dort 3.3.7 greift
• Seiten mit festen Leisten, Cookie-Hinweis oder Chat-Fenster für 2.4.11
• Seiten mit Schiebereglern, Karten oder sortierbaren Listen für 2.5.7

Die manuelle Checkliste

• 2.4.11: Mit der Tabulatortaste durch die Seite gehen und prüfen, ob der fokussierte Bestandteil hinter festen Leisten oder Einblendungen ganz verschwindet. Wie man das systematisch angeht, zeigt der Beitrag Tastaturbedienung prüfen.
• 2.5.7: Jede Funktion, die Ziehen verlangt, mit einem einfachen Klick oder Tippen auslösen. Fehlt ein solcher Weg, ist der Befund offen.
• 3.2.6: Auf allen Vorlagen festhalten, wo Kontaktdaten, Kontaktformular, Hilfeseite oder Chat stehen, und prüfen, ob sie in derselben Reihenfolge relativ zum übrigen Inhalt erscheinen.
• 3.3.7: In jedem Ablauf notieren, welche Angaben ein zweites Mal verlangt werden, und prüfen, ob sie vorausgefüllt oder auswählbar sind.
• 3.3.8: Den Anmeldeweg ohne Gedächtnisaufgabe durchspielen: Einfügen des Passworts erlaubt, Passwortmanager nicht blockiert, eine Alternative zu Rätsel-Captchas vorhanden.
• 9.7 Nutzereinstellungen: Die Seite mit erzwungenen Farben und vergrößerter Schrift im Browser öffnen und prüfen, ob Einstellungen übersteuert werden, etwa über forced-color-adjust.
• Rest aus dem automatischen Lauf: Alles, was axe-core als „manuell prüfen“ ausweist, abarbeiten und mit Ergebnis vermerken.

Nutzereinstellungen sind übrigens auch eine Ursache dafür, dass eine Seite beim Kunden anders aussieht als im eigenen Test. Wie man solchen Abweichungen nachgeht, beschreibt der Beitrag Bei uns geht die Seite, beim Kunden nicht.

Den Nachweis bis zur Zitierung dokumentieren

In der Übergangszeit kommt es auf die Formulierung an. Die Aussage „konform mit EN 301 549“ ist ohne Fassung missverständlich, die Aussage „konform mit WCAG 2.2“ ohne Prüfumfang zu weit. WCAG selbst gibt für eine Konformitätserklärung Pflichtangaben vor: Datum, Titel, Fassung und Adresse der Richtlinien, die erreichte Stufe, eine knappe Beschreibung der Seiten, für die die Aussage gilt, und die Liste der Webtechniken, auf die sich die Seiten stützen (W3C). Für einen Prüfbericht in der Übergangszeit lohnt es sich, diese Liste um die Normfassung und den Prüfweg zu ergänzen.

• Bezug: „Geprüft gegen WCAG 2.2 Stufe AA. Rechtlicher Bezug für den Konformitätsnachweis ist bis zur Zitierung von V4.1.1 die EN 301 549 V3.2.1 auf Grundlage von WCAG 2.1 Stufe AA.“
• Werkzeug: Prüfmotor mit Versionsnummer und Tags, zum Beispiel axe-core 4.12 mit wcag2a bis wcag22aa.
• Umfang: Liste der geprüften Vorlagen und vollständigen Abläufe, jeweils mit Datum.
• Ergebnis getrennt: Befunde zu WCAG 2.1 AA und Befunde nur zu den sechs neuen Kriterien in eigenen Abschnitten.
• Manuelle Prüfung: Kriterium, Seite, prüfende Person, Datum, Ergebnis und bei Mängeln der geplante Termin der Behebung.
• Abweichungen: Was bewusst nicht erfüllt wird, mit Begründung, damit es in der Barrierefreiheitserklärung auftauchen kann.

Der getrennte Ausweis hat einen praktischen Grund. Fragt eine Marktüberwachungsbehörde nach, zählt der heutige Bezug. Wie Nachweise in einem solchen Verfahren aufgebaut sein sollten, beschreibt der Beitrag BFSG-Verfahren: Nachbesserung gegenüber der Behörde belegen. Die Befunde zu den neuen Kriterien gehören in denselben Bericht, aber gekennzeichnet als Arbeitsliste für die Umstellung.

Was XICTRAQ® an der Barrierefreiheitserklärung selbst prüft, ist vom WCAG-Scan getrennt: ob eine Erklärung verlinkt ist und ob sie Bausteine der EU-Mustererklärung enthält. Die Dokumentation zu den Compliance-Prüfungen beschreibt beide Prüfungen, ihre Hinweise und den Alarm bei niedrigem Score.

Rückschritte überwachen statt einmal prüfen

Ein Prüfprofil ist nur eine Momentaufnahme, wenn es einmal läuft. Barrieren entstehen meist mit Änderungen: Ein neuer Cookie-Hinweis verdeckt den Fokus, ein neues Anmeldemodul verlangt ein Rätsel, ein Umbau verschiebt den Hilfe-Link. Für den automatischen Teil heißt das: regelmäßig messen und Verschlechterungen melden. Wie Regressionen nach einem Deploy entstehen und auffallen, beschreibt der Beitrag zur kontinuierlichen Überwachung der Barrierefreiheit.

Im XICTRAQ®-Monitoring läuft der Barrierefreiheits-Scan im Free-Tarif täglich und in den übrigen Tarifen alle 12 Stunden, wie die Preisübersicht ausweist (XICTRAQ). Jeder Lauf liefert einen Score von 0 bis 100 und schlüsselt Verstöße, manuell zu prüfende Punkte und bestandene Regeln auf. Sinkt der Score unter 50, legt das Monitoring einen Alarm an, unter 30 mit der Stufe kritisch (XICTRAQ). Zugestellt wird er über die eingerichteten Benachrichtigungskanäle.

Für die fünf manuellen Kriterien hilft die Messung indirekt. Der Screenshot-Changelog zeigt, wann sich eine Seite sichtbar verändert hat, etwa durch eine neue feste Leiste oder ein umgebautes Formular. Bewährt hat sich eine feste Regel im Team: Jede Änderung an Kopf, Fuß, Anmeldung oder Bestellstrecke löst die manuelle Nachprüfung der zugehörigen Kriterien aus.

Fahrplan bis zur Zitierung

1. Jetzt: Prüfprofil auf die Tags bis wcag22aa umstellen, die manuelle Checkliste für die fünf übrigen Kriterien und Abschnitt 9.7 anlegen und den ersten Lauf als Ausgangsstand sichern.
2. In den nächsten Wochen: Befunde zu WCAG 2.1 AA vorrangig beheben, weil sie den heutigen Bezug betreffen. Befunde zu den neuen Kriterien in eine eigene Liste mit Terminen übernehmen.
3. Laufend: Den automatischen Teil im Monitoring mitlaufen lassen und die manuellen Punkte bei jeder Änderung an Vorlagen und Abläufen nachprüfen.
4. Bei der Zitierung: Prüfbericht und Barrierefreiheitserklärung auf EN 301 549 V4.1.1 umstellen und Verweise auf WCAG 2.1 AA in Texten, Verträgen und Leistungsbeschreibungen nachziehen.

Aussagen in eigenen Texten, die WCAG 2.1 AA als Maßstab nennen, bleiben bis zur Zitierung richtig, gehören aber schon jetzt auf die Liste. Für Agenturen, die viele Kundenseiten betreuen, ist die Umstellung zugleich ein Anlass für ein Angebot: Eine Prüfung gegen WCAG 2.2 mit getrenntem Ausweis eignet sich als Einstieg, ähnlich wie ein Website-Check als Lead-Magnet.

Das Prüfprofil jetzt auf zwei Ebenen führen

EN 301 549 V4.1.1 ändert den Maßstab, aber noch nicht die Rechtslage. Bis zur Zitierung bleibt V3.2.1 mit WCAG 2.1 AA der Bezug, danach begründet die neue Fassung die Konformitätsvermutung (AccessibleEU). Wer das Prüfprofil schon heute auf WCAG 2.2 stellt und beide Ebenen getrennt ausweist, verliert nichts am heutigen Nachweis und muss beim Wechsel vor allem die Gewichtung im Bericht ändern. Automatisch prüfbar ist davon nur die Zielgröße, den Rest trägt die Checkliste.

Den automatischen Teil übernimmt der BFSG-Check von XICTRAQ® mit regelmäßigen Läufen, Score-Verlauf und einem Alarm, sobald der Score unter 50 fällt. Wie das im Dashboard aussieht, zeigt die Live-Demo, ein eigener Test beginnt mit der kostenlosen Registrierung.