EN 301 549 Checkliste: Geltungsbereich festlegen, testen und dokumentieren (v4.1.1)

Mit EN 301 549 v4.1.1 gelten für Webseiten, Dokumente und Software die Anforderungen der WCAG 2.2. Mit dieser Checkliste legen Sie fest, welche Abschnitte für Ihr Produkt gelten, prüfen jeden Bereich und dokumentieren, was Sie getestet haben.

Die neue Version finden Sie als EN 301 549 v4.1.1 (PDF). ETSI hat sie am 2. September 2026 veröffentlicht.

Das Wichtigste in Kürze

• Mit v4.1.1 kommen sechs neue WCAG-2.2-Kriterien hinzu: Fokus-Sichtbarkeit, Ziehbewegungen, Zielgröße, einheitliche Hilfe, redundante Eingaben und barrierefreie Authentifizierung. Das Kriterium 4.1.1 Parsing entfällt.

• Stand Oktober 2026 ist für den EAA noch keine harmonisierte Norm im Amtsblatt zitiert. v3.2.1 ist im Rahmen der Web-Accessibility-Richtlinie zitiert. Für v4.1.1, die ihre Abschnitte dem EAA zuordnet, wird die Zitierung erwartet. Wer jetzt nach WCAG 2.2 testet, ist auf beide Fälle vorbereitet.

• Der größte Teil der Norm betrifft nicht das Web. Dokumente, Software, mobile Apps, Hardware und Echtzeitkommunikation haben eigene Abschnitte.

• Nachweise zählen so viel wie Korrekturen. Jedes Ergebnis braucht die getestete Version, das Datum, den Prüfumfang und die Methode.

EN 301 549 ist die europäische Norm für die Barrierefreiheit von IKT-Produkten und -Diensten. Die meisten Teams nutzen sie als technische Referenz für den European Accessibility Act (EAA) und für das BFSG in Deutschland sowie das BaFG in Österreich.

Was ändert sich mit v4.1.1, und nach welcher Version sollten Sie testen?

Version 4.1.1 wurde im September 2026 veröffentlicht. Sie bringt vier wesentliche Änderungen:

• Webseiten, Dokumente und Software wechseln von WCAG 2.1 zu WCAG 2.2: sechs neue Kriterien auf Stufe A und AA, 4.1.1 Parsing entfällt.

• Die Anforderungen an Nutzerpräferenzen gelten jetzt auch für Webseiten und Dokumente, nicht mehr nur für Software.

• Die Anforderungen an Echtzeittext umfassen jetzt Total Conversation, also Video, Text und Sprache gleichzeitig.

• Die Abschnitte der Norm sind direkt den Anforderungen des EAA zugeordnet (Anhang ZB).

Unser Leitfaden zu EN 301 549 erklärt jede Änderung im Detail.

Testen Sie jetzt nach WCAG 2.2, Stufe AA, und nennen Sie in jedem Bericht die getestete Version.

• v3.2.1 basiert auf WCAG 2.1. Ihre Fundstelle ist im Amtsblatt der Europäischen Union im Rahmen der Web-Accessibility-Richtlinie veröffentlicht, die für Websites und Apps öffentlicher Stellen gilt.

• Stand Oktober 2026 ist für den EAA noch keine harmonisierte Norm zitiert. EN 301 549 bleibt eine nützliche technische Referenz, begründet derzeit aber keine Konformitätsvermutung nach dem EAA. v4.1.1 ordnet ihre Abschnitte dem EAA zu (Anhang ZB). Ihre Zitierung wird erwartet.

• Öffentliche Stellen, die nach v3.2.1 berichten, sollten ein Ergebnis für 4.1.1 Parsing behalten, bis v4.1.1 an ihre Stelle tritt.

Und BFSG, BITV 2.0 und BaFG? In Deutschland setzt das BFSG den EAA für Produkte und Dienstleistungen privater Unternehmen um. Öffentliche Stellen des Bundes richten sich nach der BITV 2.0. In Österreich gilt das BaFG für private Unternehmen und das WZG für öffentliche Stellen.

Bevor Sie beginnen: welche Abschnitte gelten für Ihr Produkt?

EN 301 549 ist nach Technologien gegliedert. Klären Sie deshalb zuerst, welche Kapitel für Ihr Produkt gelten. Eine reine Website fällt nicht unter die Abschnitte zu Hardware oder Vermittlungsdiensten. Eine Banking-App mit Videoanrufen dagegen unter mehrere.

Abschnitt 4 legt funktionale Leistungsanforderungen fest, etwa die Nutzung ohne Sehvermögen oder mit eingeschränkter Reichweite. Sie gelten für alle Kapitel. Entscheiden Sie bei Apps, Software und Hardware außerdem, welche Funktionen offen sind (sie funktionieren mit der Assistiven Technologie der Nutzer:innen, etwa einem Screenreader) und welche geschlossen (wie ein Fahrkartenautomat, an den sich keine eigene Technologie anschließen lässt). Für geschlossene Funktionen gelten die Anforderungen aus Abschnitt 5.1, etwa eine eingebaute Sprachausgabe.

Halten Sie den Geltungsbereich schriftlich fest. Er ist der erste Teil Ihres Nachweises.

So verwenden Sie diese Checkliste

Kombinieren Sie einen automatisierten Scan mit manuellen Tests. Ein Scan findet wiederkehrende digitale Barrieren schnell, etwa fehlende Textalternativen oder zu geringen Kontrast. Ob ein Alternativtext sinnvoll ist oder ob eine eigene Komponente mit einem Screenreader funktioniert, kann er nicht beurteilen. Unser Vergleich manueller und automatisierter Barrierefreiheitstests zeigt, wo die Grenzen liegen.

Testen Sie Ihre wichtigsten Nutzerwege statt einzelner Seiten: Registrierung, Login, Suche, Checkout, Kontakt.

Nutzen Sie nur die Tastatur, einen Screenreader (NVDA oder JAWS unter Windows, VoiceOver unter macOS und iOS, TalkBack unter Android), Zoom und Bildschirmlupe.

Vergeben Sie für jeden Punkt eines von vier Ergebnissen:

• Bestanden: getestet, die Anforderung ist erfüllt.

• Nicht bestanden: eine digitale Barriere ist nachgewiesen.

• Nicht anwendbar: die Anforderung gilt nicht. Notieren Sie den Grund.

• Nicht getestet: der Nachweis fehlt noch.

Halten Sie zu jedem Ergebnis fest:

• getestete Versionen von EN 301 549 und WCAG

• Geltungsbereich

• Produkt und Produktversion

• Testdatum

• prüfende Person

• Browser oder Gerät, Screenshot oder Ticketnummer

Checkliste für Websites (Abschnitt 9)

Abschnitt 9 wendet WCAG 2.2, Stufe A und AA, auf Webseiten an. WCAG 2.2 bringt neun neue Erfolgskriterien. Sechs davon liegen auf Stufe A oder AA, und nur diese übernimmt EN 301 549 v4.1.1. Sie sind unten als Neu in v4.1.1 markiert und fehlen am häufigsten in Audits nach WCAG 2.1.

Checkliste für Dokumente (Abschnitt 10)

Abschnitt 10 überträgt die meisten Kriterien auf Dokumente zum Herunterladen: PDFs, Word-Dateien, Tabellen. Beginnen Sie mit den Dokumenten, die Menschen für eine Aufgabe brauchen, etwa Verträge, Rechnungen, Formulare und AGB.

Unser Leitfaden zeigt, wie Sie ein PDF barrierefrei machen. Für große Dokumentbestände übernehmen unsere PDF-Lösungen Prüfung und Remediation.

Checkliste für Apps und Software (Abschnitt 11)

Native Apps müssen auf jeder Plattform mit deren eigener Assistiver Technologie getestet werden. Ein Beispiel aus der Praxis zeigt unsere Fallstudie zu den Apps von Lavazza.

Checkliste für Anrufe, Video und Hardware (Abschnitte 5 bis 8)

Hardware muss am realen Gerät in seiner tatsächlichen Installation getestet werden, nicht nur an einer Zeichnung oder in einer Simulation. Unsere Hardware- und Software-Audits decken diese Prüfungen ab.

Checkliste für Dokumentation und Support (Abschnitt 12)

Beheben, erneut testen, Nachweise aktuell halten

Beheben Sie zuerst digitale Barrieren, die eine Aufgabe blockieren, etwa Login, Bezahlung oder das Absenden eines Formulars. Kosmetische Probleme kommen danach. Testen Sie anschließend dieselben Nutzerwege mit derselben Methode und aktualisieren Sie das Ergebnis.

Aktualisieren Sie Ihre Erklärung zur Barrierefreiheit und jeden Accessibility Conformance Report (ACR) auf Basis der VPAT EU Edition, sobald Sie auf v4.1.1 umstellen. Beide sollten die Version nennen, auf die sie sich beziehen.

Unser Leitfaden zum Barrierefreiheits-Audit beschreibt den gesamten Ablauf, und unsere Schritt-für-Schritt-Anleitung zur barrierefreien Website zeigt, was danach kommt.

Unser Service Audit und Remediation ergänzt Remediation Guidance für Ihr Entwicklungsteam. User Testing mit Menschen mit Behinderungen findet Barrieren, die auch Expert:innen übersehen.

Häufige Fragen zum Testen nach EN 301 549

Brauche ich eine Checkliste für EN 301 549 oder für den EAA?

Meist beide, für unterschiedliche Aufgaben. Eine Checkliste für EN 301 549 prüft, ob Ihr Produkt technisch barrierefrei ist. Eine EAA-Checkliste deckt Ihre rechtlichen Pflichten als Unternehmen ab: Geltungsbereich, Erklärung zur Barrierefreiheit, Feedbackkanäle, Dokumentation. Beginnen Sie mit dem technischen Test, denn die EAA-Arbeit baut auf seinen Ergebnissen auf.

Muss ich für v4.1.1 alles neu testen?

In der Regel nicht. Wenn Sie ein aktuelles Audit nach WCAG 2.1 AA haben, testen Sie die Zeilen mit „Neu in v4.1.1“ und die Änderungen aus v4.1.1, die Ihr Produkt betreffen. Aktualisieren Sie dann die Version in Ihren Berichten.

Wie oft sollte ein Audit nach EN 301 549 wiederholt werden?

Führen Sie mindestens einmal im Jahr ein vollständiges Audit durch. Testen Sie die betroffenen Nutzerwege nach jedem größeren Release erneut, das Navigation, Login, Formulare oder Templates verändert. Automatisiertes Monitoring zwischen den Audits erkennt neue Barrieren, wenn sich Inhalte ändern.

Wann wird EN 301 549 v4.1.1 zur rechtlichen Referenz?

Wenn die Europäische Kommission die Fundstelle im Amtsblatt der Europäischen Union veröffentlicht. Erwartet wird das für Ende 2026.

Was sollte vor der Freigabe nach EN 301 549 erledigt sein?

1. Jeder Abschnitt ist als anwendbar oder nicht anwendbar markiert, mit Begründung bei jedem „nicht anwendbar“.

2. Jeder anwendbare Punkt wurde manuell getestet, nicht nur per Scan.

3. Alle sechs Zeilen mit „Neu in v4.1.1“ haben ein Ergebnis.

4. Barrieren, die eine Aufgabe blockieren, sind behoben und erneut getestet.

5. Zu jedem Ergebnis ist ein Nachweis dokumentiert.

6. Erklärung zur Barrierefreiheit und ACR stimmen mit den Ergebnissen überein.

Sie möchten wissen, wo Ihre Website heute steht? Starten Sie mit einer kostenlosen Analyse auf unserer Plattform für digitale Barrierefreiheit und sprechen Sie dann mit unserem Team über ein vollständiges Audit nach EN 301 549.