EN 301 549 in der Praxis: Audit, Remediation und technische Umsetzung

Die EN 301 549 ist die zentrale europäische Norm für die digitale Barrierefreiheit von IKT-Produkten und -Dienstleistungen. Auf dieser Seite erfahren Produktteams, Entwickler:innen sowie UX- und QA-Verantwortliche, was die Norm verlangt, wie sie sich zu WCAG 2.2 verhält und wie ein technisches Audit konkret abläuft.

Hinweis: Diese Informationen dienen der allgemeinen Orientierung und ersetzen keine Rechtsberatung. Ob und welche Pflichten im Einzelfall gelten, hängt vom konkreten Angebot, vom Adressatenkreis und von der tatsächlichen Ausgestaltung der Dienstleistung ab.

Kurzantwort (TL;DR)

• EN 301 549 ist die harmonisierte europäische Norm für barrierefreie Informations- und Kommunikationstechnik (IKT).
• Sie referenziert die WCAG 2.1 Stufe AA für Webinhalte und ergänzt Anforderungen für Hardware, Software, Dokumente und Support-Dienste.
• In Deutschland ist sie über das Behindertengleichstellungsgesetz (BGG) und das Barrierefreiheitsstärkungsgesetz (BFSG) relevant, da sie bei der Bewertung digitaler Angebote als anerkannter technischer Maßstab herangezogen werden kann.
• Die Anwendbarkeit hängt vom Einzelfall ab – Produkttyp, Zielgruppe und Geschäftsmodell entscheiden, welche Anforderungen konkret greifen.

Was ist die EN 301 549?

Die EN 301 549 („Accessibility requirements for ICT products and services”) ist eine vom Europäischen Komitee für Normung (CEN, CENELEC, ETSI) entwickelte Norm. Sie definiert funktionale und technische Anforderungen an die Barrierefreiheit digitaler Produkte und Dienste, die in der EU angeboten werden.

Die Norm ist:

• technologieübergreifend – sie deckt Webseiten, mobile Apps, native Software, Dokumente, Hardware (z. B. Self-Service-Terminals) sowie Support-Services ab,
• funktional definiert – sie beschreibt, was nutzbar sein muss (z. B. Bedienbarkeit ohne Sehfähigkeit, ohne Hörfähigkeit, ohne präzise Motorik),
• WCAG-basiert für Web – Kapitel 9 verweist direkt auf die WCAG-Erfolgskriterien.

Warum ist EN 301 549 für Deutschland und die EU relevant?

Die Norm ist als harmonisierte europäische Norm der technische Bezugsrahmen für mehrere Rechtsakte:

• Web Accessibility Directive (EU 2016/2102) – Anforderungen an Websites und Apps öffentlicher Stellen.
• European Accessibility Act (EAA), in Deutschland umgesetzt durch das Barrierefreiheitsstärkungsgesetz (BFSG) – Anforderungen an bestimmte Produkte und Dienstleistungen, die ab dem 28. Juni 2025 für Unternehmen relevant sein können.
• BGG / BITV 2.0 – Anforderungen an Stellen des Bundes.

Ob ein konkretes Angebot in den Anwendungsbereich des BFSG fällt, hängt je nach Angebot, Adressatenkreis und Unternehmensgröße ab. Eine pauschale Aussage ist nicht möglich.

Welche Produkte und Dienstleistungen fallen unter EN 301 549?

Die Norm adressiert ein breites Spektrum an IKT. Relevante Beispiele:

• Websites und Webanwendungen (z. B. Unternehmensseiten, Portale, Self-Service-Bereiche)
• Online-Shops und E-Commerce-Plattformen (Shopware, WooCommerce, Shopify, Magento u. a.)
• Native und mobile Apps (iOS, Android)
• Elektronische Dokumente (PDF, Office-Dokumente)
• Hardware mit digitaler Bedienoberfläche (z. B. Kassensysteme, Ticketautomaten, E-Reader)
• Kommunikations- und Echtzeitdienste (z. B. Video-Conferencing, Notrufdienste)
• Support-Services (Hilfe-Dokumentation, Kunden-Support)

Welche Kapitel der EN 301 549 konkret zur Anwendung kommen, ist im Einzelfall abhängig vom Produkttyp und der Anwendungsumgebung.

EN 301 549 vs. WCAG 2.2 – worin liegt der Unterschied?

WCAG und EN 301 549 werden oft verwechselt. Beide hängen zusammen, decken aber unterschiedliche Bereiche ab.

Kurz gesagt: WCAG 2.2 ist die technische Grundlage für barrierefreie Webinhalte. EN 301 549 nimmt diese Grundlage auf und erweitert sie um Anforderungen an alles andere, was nicht „nur Web” ist.

Für reine Web-Produkte ist eine sorgfältige Umsetzung nach WCAG 2.2 AA ein sinnvoller technischer Ausgangspunkt – sie deckt die Web-Kapitel der EN 301 549 in weiten Teilen ab. Eine 1:1-Gleichsetzung ist aber nicht zulässig, da die EN 301 549 derzeit noch WCAG 2.1 referenziert.

Praxis-Audit-Ablauf: So gehen wir vor

Unser Audit-Prozess orientiert sich an den Kapiteln der EN 301 549 und ergänzt diese um WCAG-2.2-Kriterien sowie produkt­spezifische Tests.

1. Scoping & Bestandsaufnahme

• Klärung des Geltungsbereichs (welche Seiten, Templates, Flows?)
• Identifikation relevanter Normabschnitte je nach Produkttyp
• Definition von Personas und kritischen User Journeys (z. B. Checkout, Login, Suche)

2. Automatisierte Vorprüfung

• Tooling-gestützte Analyse (z. B. axe-core, Lighthouse, Pa11y)
• Crawl-basierte Identifikation systematischer Fehler
• Wichtig: Automatisierte Tools decken erfahrungsgemäß nur einen Teil der Kriterien zuverlässig ab – sie ersetzen keine manuelle Prüfung.

3. Manuelles Expertenaudit

• Prüfung nach EN 301 549 / WCAG 2.2 AA
• Tastatur-Navigation, Fokus-Management, Screenreader-Tests (NVDA, JAWS, VoiceOver, TalkBack)
• Prüfung von Kontrasten, Zoom, Reflow, Bewegungsreduktion
• Bewertung von ARIA-Verwendung und semantischer Struktur

4. Befundbericht mit Priorisierung

• Mapping jedes Befunds auf EN 301 549- und WCAG-Kriterien
• Schweregrad (Blocker, Major, Minor) und Aufwandsindikation
• Konkrete Code- oder Design-Empfehlungen

5. Remediation-Begleitung

• Direkter Austausch mit Entwicklungs- und Designteams
• Pull-Request-Reviews und Pairing-Sessions
• Re-Test nach Umsetzung

6. Monitoring & Regression

• Aufbau automatisierter Regressionstests in CI/CD
• Einbindung in QA-Prozesse, damit Barrierefreiheit nicht zur Einmalmaßnahme wird

Ein bestandenes Audit ist kein Konformitätsnachweis und keine Zusicherung der Vollständigkeit. Es ist eine fachliche Einschätzung zum Zeitpunkt der Prüfung. Inwieweit Anforderungen erfüllt sind, hängt im Einzelfall von Produkt, Pflege und Weiterentwicklung ab.

Praxisbeispiele

• E-Commerce-Plattform (Shopware): Audit des Checkouts ergibt fehlende Label-Verknüpfungen, ungenügenden Fokus-Indikator und nicht angekündigte Fehlerzustände. Remediation umfasst HTML-Refactoring, ARIA-Live-Regions für Fehlerbehandlung und Anpassung der Designtokens.
• SaaS-Anwendung (React): Komplexe Custom Components (Datepicker, Combobox) werden gegen das WAI-ARIA Authoring Practices Guide und EN 301 549 geprüft. Ergebnis: Refactoring mit Headless-UI-Bibliothek und definierter Tastatur-Interaktion.
• Corporate Website (WordPress): Theme-bezogene Kontrast- und Heading-Probleme, PDF-Dokumente ohne Tagging. Empfehlung: Theme-Anpassung plus Workflow für barrierefreie PDF-Erstellung.

Rechts- und Normenbezug