Bildbeschreibung: Hände auf einer mechanischen Tastatur mit einem geöffneten technischen Normungsdokument auf einem externen Monitor — der Arbeitsplatz der Barrierefreiheitsprüferin, an dem EN 301 549 zuhause ist.

Lesezeit: 11 Minuten

EN 301 549 ist der harmonisierte europäische Standard für Barrierefreiheitsanforderungen an IKT-Produkte und -Dienste. Er wird von ETSI — dem Europäischen Institut für Telekommunikationsnormen — in Zusammenarbeit mit CEN und CENELEC veröffentlicht und gepflegt. Er ist das technische Instrument, das die abstrakteren Verpflichtungen des European Accessibility Act (EAA), der Richtlinie über den barrierefreien Zugang zu Websites (Richtlinie (EU) 2016/2102) und der meisten nationalen Beschaffungsvorschriften des öffentlichen Sektors in eine Klausel-für-Klausel-Checkliste überführt, anhand derer ein Anbieter gemessen werden kann. Während WCAG ein Inhalts- und Schnittstellenstandard für das Web ist, bildet EN 301 549 den übergeordneten Rahmen, der WCAG in die Anforderungen einbettet, gegen die das EU-Recht tatsächlich beschafft.

Im Jahr 2026 gilt die Version V3.2.1, die im März 2021 veröffentlicht wurde und WCAG 2.1 Level AA per Verweis einbezieht. Eine neue Revision, die WCAG 2.2 AA aufnimmt — vorläufig als V4.0.0 bezeichnet — befindet sich in der Schlussphase der Ausarbeitung innerhalb des gemeinsamen technischen Gremiums ETSI/CEN/CENELEC und soll voraussichtlich im Laufe des Jahres 2026 veröffentlicht werden; die Zitierung im Amtsblatt der Europäischen Union folgt anschließend. Dieser Text ist ein Leitfaden: Er erläutert, was der Standard ist, wie seine zwölf Kapitel aufgebaut sind, wo Kapitel 9 (Web) und Kapitel 11 (Software) neben Kapitel 10 (Dokumente) und Kapitel 12 (Dokumentation und Support) stehen, wie der Standard WCAG mit dem EU-Beschaffungsrecht verbindet und wo er im Gesetzgebungsgraph zitiert wird, den Praktikerinnen und Praktiker bereits kennen.

Was EN 301 549 tatsächlich ist — und was nicht

EN 301 549 ist ein harmonisierter europäischer Standard. Dieser Begriff hat eine präzise Bedeutung im EU-Recht: Es handelt sich um einen Standard, der von einer der drei anerkannten Europäischen Normungsorganisationen (ETSI, CEN, CENELEC) auf Ersuchen der Europäischen Kommission im Rahmen eines formellen „Normungsauftrags“ (auch „Mandat“ genannt) entwickelt und anschließend im Amtsblatt der Europäischen Union als Grundlage für die „Konformitätsvermutung“ mit dem entsprechenden EU-Rechtsakt zitiert wird. Ein Produkt oder eine Dienstleistung, das bzw. die den harmonisierten Standard erfüllt, gilt als mit den rechtlichen Anforderungen, die er harmonisiert, konform. Diese Vermutung kann widerlegt werden, doch in der Praxis behandeln öffentliche Auftraggeber, Barrierefreiheits-Auditorinnen und Konformitätsstellen den Standard als die maßgebliche Checkliste.

EN 301 549 geht auf das Mandat M/376 zurück, das die Kommission 2005 erteilt hatte, um die europäischen Beschaffungsvorschriften barrierefreiheitstauglich zu machen — eine einheitliche, technologieneutrale, harmonisierte Referenz dafür, was „barrierefreie IKT“ im öffentlichen Ausschreibungsverfahren bedeutet. Die erste veröffentlichte Version, V1.1.2, erschien 2014. Seitdem hat der Standard drei wesentliche Revisionen durchlaufen: V2 (2018) mit Ausrichtung auf WCAG 2.1, V3.1.1 und V3.2.1 (2019–2021) mit präzisierten Definitionen und neuen Klauseln für mobile Apps und Authoring-Tools sowie die bevorstehende V4 mit WCAG 2.2.

Was EN 301 549 nicht ist: Er ist weder der EAA noch die Richtlinie über den barrierefreien Zugang zu Websites. Diese sind die Rechtsvorschriften, die auf der Grundlage des Standards beschaffen. EN 301 549 ist das Prüfkriterien-Dokument — der Teil des Systems, den Entwicklerinnen und Entwickler oder Beschaffungsverantwortliche tatsächlich lesen, um zu wissen, ob ein Lieferergebnis den Anforderungen entspricht.

Die Zwölf-Kapitel-Struktur

EN 301 549 ist um zwölf inhaltliche Klauseln (im Dokument ab Klausel 4 nummeriert, da die Klauseln 1–3 Anwendungsbereich und Definitionen enthalten) aufgebaut. Die Architektur ist bewusst modular gestaltet: Ein Anbieter, der eine Ausschreibungsantwort formuliert, ermittelt, welche Klauseln auf das Produkt zutreffen, wendet nur diese an und erklärt die Konformität gegenüber den genannten Klauseln. Die zentralen Module befinden sich in den Kapiteln 9 bis 12.

Kapitel 9 — Webinhalte

Kapitel 9 ist das Kapitel, das die meisten Barrierefreiheitspraktikerinnen und -praktiker zuerst aufschlagen, weil es WCAG per Verweis einbezieht. In V3.2.1 übernimmt Kapitel 9 die Erfolgskriterien von WCAG 2.1 Level A und Level AA wörtlich: Klausel 9.1 umfasst die wahrnehmbaren Erfolgskriterien, 9.2 die bedienbaren, 9.3 die verständlichen, 9.4 die robusten. Ein Webprodukt, das WCAG 2.1 AA entspricht, entspricht damit auch Kapitel 9. Der Standard paraphrasiert den WCAG-Text nicht; er zitiert ihn. In V4 wird dasselbe Kapitel auf WCAG 2.2 AA verweisen und dabei die neun neuen und überarbeiteten Erfolgskriterien aufnehmen — darunter 2.4.11 Fokus nicht verdeckt (Minimum), 2.4.12 Fokus nicht verdeckt (Erweitert), 2.4.13 Fokusdarstellung, 2.5.7 Ziehbewegungen, 2.5.8 Zielgröße (Minimum), 3.2.6 Konsistente Hilfe, 3.3.7 Redundante Eingabe, 3.3.8 Barrierefreie Authentifizierung (Minimum) und 3.3.9 Barrierefreie Authentifizierung (Erweitert).

Kapitel 10 — Nicht-Web-Dokumente

Kapitel 10 wendet WCAG-äquivalente Anforderungen auf Nicht-Web-Dokumente an — PDFs, Word-Dateien, Präsentationen, ePub und alle anderen Dokumente, die neben oder außerhalb des Webs bereitgestellt werden. Dazu wird jedes WCAG-2.1-Erfolgskriterium, das für ein Nicht-Web-Dokument sinnvoll ist, im Dokumentenkontext neu formuliert. Ein getaggtes, navigierbares, korrekt beschriebenes PDF erfüllt Kapitel 10; ein ungetaggter Scan eines gedruckten Berichts nicht. Öffentliche Auftraggeber, die Richtlinien-Veröffentlichungen, Vertragsbedingungen, Schulungsmaterialien und Erklärungen zur Barrierefreiheit beschaffen, nutzen Kapitel 10, um die Anforderungen an ein akzeptierbares Lieferergebnis festzulegen.

Kapitel 11 — Nicht-Web-Software

Kapitel 11 ist das umfangreichste Modul und das bedeutsamste für den modernen Anwendungsstack. Es wendet WCAG-äquivalente Anforderungen auf Nicht-Web-Software an — Desktop-Anwendungen, native mobile Apps, eingebettete Schnittstellen, Kioske mit eigener Software — und ergänzt softwarespezifische Anforderungen, für die es keine WCAG-Entsprechung gibt: Klauseln zu Plattform-Barrierefreiheitsdiensten (11.5), zur Kompatibilität mit assistiver Technologie (11.6) und zu Authoring-Tools (11.8, abgeleitet aus den Authoring Tool Accessibility Guidelines des W3C). Die Abdeckung mobiler Apps in Kapitel 11 ist der Grund, warum die Richtlinie über den barrierefreien Zugang zu Websites auf mobile Anwendungen des öffentlichen Sektors ausgedehnt werden kann und warum der EAA auf E-Reader, Ticketautomaten und Selbstbedienungsterminals anwendbar ist, ohne dass für jeden Gerätetyp ein eigener Standard benötigt wird.

Kapitel 12 — Dokumentation und Supportdienste

Kapitel 12 umfasst Dokumentation und Kundensupportdienste: Benutzerhandbücher, Hilfesysteme, Support-Callcenter, Online-Chat sowie barrierefreie Formate auf Anfrage. Die Klauseln verlangen, dass die Produktdokumentation die Barrierefreiheitsmerkmale des Produkts beschreibt, dass die Dokumentation selbst barrierefrei ist und dass Supportdienste über barrierefreie Kanäle verfügbar sind. Dieses Kapitel verknüpft Barrierefreiheit mit der Erfahrung nach dem Kauf — dem Teil der Customer Journey, in dem Nutzende das Produkt tatsächlich verwenden und Unterstützung benötigen.

Kapitel 5–8 — die übergreifenden generischen Anforderungen

Die Kapitel 5 bis 8 stehen den formatspezifischen Modulen vorgelagert. Kapitel 5 enthält generische Anforderungen, die für alle IKT-Produkte und -Dienste gelten — geschlossene Funktionalität, Biometrie, Wahrung von Barrierefreiheitsinformationen bei der Konvertierung. Kapitel 6 behandelt IKT mit bidirektionaler Sprachkommunikation: Echtzeit-Text, Video-Relay und die Interoperabilitätsanforderungen, die barrierefreie Kommunikation über Dienstanbieter hinweg ermöglichen. Kapitel 7 behandelt IKT mit Video-Fähigkeiten — Audiodeskription, Untertitel, Gebärdensprachdarstellung. Kapitel 8 umfasst Hardware: Tastaturen, Bedienelemente, Anschlüsse, physischer Zugang. Ein Produkt wird selten nur gegen ein einziges Kapitel geprüft; eine Video-Streaming-App auf einem Smart-TV berührt gleichzeitig die Kapitel 5, 7, 9 (sofern eine Web-Schnittstelle vorhanden ist), 11 (die App selbst) und 12 (ihre Dokumentation).

Kapitel 13 und die Anhänge

Kapitel 13 befasst sich mit IKT, die Relay-Dienste und den Zugang zu Notfalldiensten bereitstellt — der öffentlichen Kommunikationsschicht. In den Anhängen entfaltet der Standard seine beschaffungsbindende Wirkung: Anhang A enthält die Konformitätsmethodik einschließlich der verbindlichen Vorlage für die „Erklärung zur Barrierefreiheit“; Anhang B ordnet EN-301-549-Klauseln den entsprechenden Anforderungen der U.S. Section 508 zu — nützlich für Anbieter, die auf beiden Seiten des Atlantiks tätig sind; Anhang C enthält Hinweise zu funktionalen Leistungsaussagen; und das Literaturverzeichnis listet alle Normen auf, einschließlich WCAG, die das Dokument per Verweis einbezieht.

Wie WCAG 2.1 AA in EN 301 549 eingebettet ist

Das Verhältnis zwischen WCAG und EN 301 549 ist die am häufigsten gestellte Frage in der Konformitätsarbeit — und die Antwort ist präziser als „EN 301 549 enthält WCAG“. WCAG 2.1 Level AA ist in Kapitel 9 (Webinhalte) und Teilen von Kapitel 11 (Software, soweit die Erfolgskriterien auf Nicht-Web-Software anwendbar sind) eingebettet. Die Einbeziehung erfolgt per Verweis, nicht als Paraphrase: Die Klauseln von Kapitel 9 sind so nummeriert, dass sie die Struktur von WCAG spiegeln, und jede Klausel verweist auf das entsprechende Erfolgskriterium in der W3C-Empfehlung. Ein WCAG-2.1-AA-Konformitätsnachweis lässt sich direkt in einen Kapitel-9-Konformitätsnachweis übersetzen.

Wo EN 301 549 über WCAG hinausgeht, liegt in den softwarespezifischen, hardwarespezifischen und dokumentationsspezifischen Klauseln, für die WCAG nie konzipiert wurde. WCAG adressiert Inhalte, die innerhalb eines Web-User-Agents wahrnehmbar, bedienbar, verständlich und robust sind. EN 301 549 ergänzt die Anforderungen, die z. B. die Interaktion einer Desktop-Anwendung mit einer Screenreader-API unter Windows, die taktile Unterscheidbarkeit einer Hardware-Tastatur oder die TTY-Interoperabilität eines Callcenters behandeln. Ein Produkt kann WCAG 2.1 AA konform sein und dennoch EN 301 549 nicht erfüllen — typischerweise weil Kapitel 11 oder 12 Anforderungen abdecken, die WCAG nicht adressiert.

Wo EN 301 549 im EU-Recht zitiert wird

Die tragende Rolle des Standards liegt im Zitierungsgraph. Drei primäre Rechtsinstrumente nennen EN 301 549 als technische Referenz; mehrere Dutzend nationale Beschaffungsgesetze und Barrierefreiheitsstatuten tun dasselbe.

Der European Accessibility Act (Richtlinie (EU) 2019/882)

Der European Accessibility Act legt funktionale Barrierefreiheitsanforderungen für eine definierte Liste von Produkten und Diensten fest — Computer, Smartphones, E-Reader, Geldautomaten, Ticketautomaten, E-Commerce, E-Books, Telefonie, audiovisuelle Mediendienste, Bankdienstleistungen, Fahrgastinformationen im Personenverkehr. Die funktionalen Anforderungen des Gesetzes (Anhang I) sind abstrakt; sie verlangen beispielsweise, dass Informationen in barrierefreien Formaten bereitgestellt werden, dass Benutzeroberflächen assistive Technologie unterstützen und dass Notfallkommunikation für gehörlose Nutzende funktioniert. Um diese abstrakten Anforderungen operationalisierbar zu machen, stützt sich der EAA auf harmonisierte Standards, die gemäß Artikel 15 der Verordnung (EU) 1025/2012 zitiert werden — und EN 301 549 ist der harmonisierte Standard, den die Europäische Kommission zur Operationalisierung der Web-, Software- und Dokumentationsanforderungen des EAA nutzt. Ein Produkt, das die einschlägigen Klauseln von EN 301 549 erfüllt, hat die Konformitätsvermutung gegenüber dem EAA. Die erste Amtsblatt-Zitierung von EN 301 549 speziell für EAA-Zwecke wurde 2024 veröffentlicht; Revisionen folgen mit jeder neuen Version.

Die Richtlinie über den barrierefreien Zugang zu Websites (Richtlinie (EU) 2016/2102)

Die Richtlinie über den barrierefreien Zugang zu Websites, die seit Dezember 2016 in Kraft ist, verpflichtet öffentliche Stellen in den EU-Mitgliedstaaten, ihre Websites und mobilen Anwendungen barrierefrei zu gestalten. Artikel 6 der Richtlinie bestimmt, dass Inhalte, die den im Amtsblatt zitierten harmonisierten Standard erfüllen, als konform mit den entsprechenden Barrierefreiheitsanforderungen nach Artikel 4 gelten. EN 301 549 ist der so zitierte Standard — V2 von 2018 war die erste Version, die für WAD-Zwecke benannt wurde; jede nachfolgende Revision löst eine neue Amtsblatt-Zitierung aus. Websites und mobile Anwendungen des öffentlichen Sektors, die Kapitel 9 und die anwendbaren Teile von Kapitel 11 erfüllen, gelten als richtlinienkonform.

Nationale Beschaffungsgesetze und Artikel 42 der Vergaberichtlinie

Artikel 42 der Richtlinie 2014/24/EU (Vergaberichtlinie für den öffentlichen Sektor) verlangt, dass technische Spezifikationen in öffentlichen Ausschreibungen für Produkte und Dienste, die von natürlichen Personen genutzt werden, „Barrierefreiheitskriterien für Menschen mit Behinderungen oder das Konzept des Universaldesigns berücksichtigen“. Die Mitgliedstaaten haben diese Verpflichtung in ihren nationalen Vergabevorschriften umgesetzt, und die Umsetzungstexte nennen typischerweise EN 301 549 als Referenzstandard — von der deutschen BITV 2.0 und der in der Bundesbeschaffung zitierten EU-Verordnung über das spanische Real Decreto 1112/2018, das französische RGAA (das seine Kriterien mit Kapitel 9 von EN 301 549 abgleicht), die italienischen Linee Guida AgID bis hin zum niederländischen Tijdelijk besluit digitale toegankelijkheid overheid. Die nationale Beschaffungsebene ist der Bereich, in dem EN 301 549 die größte tagtägliche kommerzielle Wirkung entfaltet, da sie bestimmt, welche Anbieter für welche öffentlichen Aufträge bieten können.

Was V4 ändert — und was nicht

Die bevorstehende V4 von EN 301 549 ist der Arbeitstitel für die Revision, die WCAG 2.2 AA anstelle von WCAG 2.1 AA einbeziehen und dabei die neun Erfolgskriterien aufnehmen wird, die das W3C im Update von 2023 hinzugefügt oder überarbeitet hat. Die Arbeitsrevision ist seit 2024 im öffentlichen Archiv des ETSI-Technischen Komitees Human Factors einsehbar, und die gemeinsame Arbeitsgruppe ETSI/CEN/CENELEC hat 2025 getagt, um sie abzuschließen. Eine Veröffentlichung im Laufe des Jahres 2026 ist die Arbeitsannahme der Normungsgemeinschaft; die Amtsblatt-Zitierung unter EAA und WAD folgt dann im üblichen Zeitrahmen der Kommission (typischerweise einige Monate nach der ETSI-Veröffentlichung).

Die inhaltlichen Änderungen in V4 konzentrieren sich auf zwei Bereiche. Erstens die WCAG-2.2-Erfolgskriterien selbst — Kapitel 9 übernimmt die neun neuen Kriterien, wobei die operationell bedeutsamsten Fokus nicht verdeckt, Zielgröße (Minimum), Ziehbewegungen und die beiden Barrierefreie Authentifizierung-Kriterien sind, die zusammen eine Nachprüfung jedes Produkts erzwingen werden, das Overlay-Banner, Cookie-Modals, Passwortfelder oder kleine Berührungsziele verwendet. Zweitens werden die Software-Klauseln des Standards (Kapitel 11) gestrafft, um eine engere Übereinstimmung mit WCAG 2.2 für Software herzustellen, auf die die Erfolgskriterien anwendbar sind, und um die Sprache zu den Plattform-Barrierefreiheitsdiensten an die assistiven Technologie-APIs anzupassen, die seit 2021 verfügbar sind.

Was V4 nicht ändert: die Zwölf-Kapitel-Architektur, die Vorlage für die Konformitätserklärung in Anhang A, das Verhältnis zu EAA und WAD oder die Section-508-Zuordnung in Anhang B. Ein Anbieter, der über eine aktuelle Konformitätserklärung gegenüber V3.2.1 verfügt, muss in den meisten Fällen lediglich die neuen WCAG-2.2-Kriterien nachprüfen, sein Konformitätskonzept aber nicht grundlegend überarbeiten.

EN 301 549 in der Praxis: die Konformitätserklärung

Das operative Artefakt, das EN 301 549 erzeugt, ist eine Konformitätserklärung — in der WAD-Terminologie mitunter „Erklärung zur Barrierefreiheit“ genannt oder als Voluntary Product Accessibility Template (VPAT) im Section-508-Kontext ausgedrückt. Anhang A des Standards enthält die Vorlage. Für jede anwendbare Klausel gibt der Anbieter an, ob das Produkt „Unterstützt“, „Teilweise unterstützt“, „Nicht unterstützt“ oder „Nicht anwendbar“ ist. Jede Angabe „Teilweise unterstützt“ oder „Nicht unterstützt“ muss von einem Erläuterungsfeld begleitet sein, das die Lücke beschreibt.

In einer Ausschreibungsantwort legt die Beschaffungsverantwortliche die relevanten Kapitel für das Produkt fest, verlangt eine klauselweise Konformitätserklärung und bewertet die Lücken. Die Erklärung ist in den meisten EU-Beschaffungsrahmen vertraglich bindend — erklärt der Anbieter für eine Klausel „Unterstützt“ und scheitert das Produkt bei der Benutzerabnahme an genau dieser Klausel, gibt der Vertrag dem Käufer typischerweise das Recht auf Nachbesserung, Vertragsstrafen oder Rücktritt. Deshalb hat EN 301 549 mehr kommerzielle Durchsetzungskraft als das zugrundeliegende WCAG-Dokument: WCAG ist eine W3C-Empfehlung ohne Beschaffungsrelevanz; EN 301 549 ist das Dokument, auf das ein Vertrag verweist.

EN 301 549 im Gesetzgebungsgraph

Wer den Bogen der EU-Behinderungsrechtsgesetzgebung kennt — den EAA, die Richtlinie über den barrierefreien Zugang zu Websites, die nationalen Beschaffungsvorschriften zur Umsetzung der Richtlinie 2014/24/EU —, für den ist EN 301 549 das technische Fundament, das diese Gesetze mit dem täglichen Testprozess von Anbietern verbindet. WCAG legt die Regeln für Webinhalte fest. EN 301 549 bettet WCAG in den umfassenderen Anforderungsrahmen (Software, Dokumente, Dokumentation, Hardware, bidirektionale Kommunikation) ein, gegen den das EU-Beschaffungsrecht tatsächlich einkauft. EAA und WAD zitieren dann EN 301 549 als den Standard, der die Konformitätsvermutung auslöst. Nationale Beschaffungsgesetze benennen den Standard in ihren technischen Spezifikationen, und Barrierefreiheits-Auditorinnen prüfen ihn Klausel für Klausel.

Für Praktikerinnen und Praktiker, die ein Audit für 2026 planen: V3.2.1 ist die heute zu prüfende Version, V4 ist die Version, auf die vorzubereiten ist, und die vorab zu adressierenden Änderungen sind die neun WCAG-2.2-Erfolgskriterien — insbesondere die Kriterien zur Fokusdarstellung und Zielgröße, bei denen die meisten Produkte still und leise scheitern. Der schnellste Weg, festzustellen, welche 2.2-Kriterien die eigene Website bereits nicht erfüllt, ist ein kostenloser WCAG-2.2-Scan einer repräsentativen Seite. Für die umfassendere Dokumentation des Jahres 2026 darüber, wie dieser Standard mit der nationalen Durchsetzung interagiert, siehe den Disability World Artikelindex; für das Bild der EAA-Durchsetzung im ersten Jahr in den Mitgliedstaaten, siehe den EAA-Leitfaden. Für eine praxisnahe Übersetzung von V3.2.1 und den 2.2-Änderungen in ein funktionierendes Audit, siehe das schrittweise WCAG-2.2-Compliance-Playbook; für die Monitoring-Plattformen, die die Konformität zwischen Audits aufrechterhalten, siehe den Barrierefreiheits-Monitoring-Leitfaden 2026.

Primärquellen

  1. ETSI / CEN / CENELEC. EN 301 549 V3.2.1 (2021-03) — Accessibility requirements for ICT products and services. etsi.org
  2. Europäische Kommission. Normungsauftrag M/376 (2005) zur IKT-Barrierefreiheit in der öffentlichen Beschaffung.
  3. Richtlinie (EU) 2019/882 des Europäischen Parlaments und des Rates über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen (European Accessibility Act).
  4. Richtlinie (EU) 2016/2102 des Europäischen Parlaments und des Rates über den barrierefreien Zugang zu Websites und mobilen Anwendungen öffentlicher Stellen.
  5. Richtlinie 2014/24/EU des Europäischen Parlaments und des Rates über die öffentliche Auftragsvergabe, Artikel 42.
  6. Verordnung (EU) Nr. 1025/2012 des Europäischen Parlaments und des Rates zur europäischen Normung.
  7. W3C. Web Content Accessibility Guidelines (WCAG) 2.1 (W3C-Empfehlung, Juni 2018) und WCAG 2.2 (W3C-Empfehlung, Oktober 2023).
  8. ETSI Technical Committee Human Factors. Öffentliches Archiv zur EN-301-549-Revisionsarbeit (2024–2025).