Sie wurden damit beauftragt, die Konformität einer Website oder Anwendung mit den WCAG sicherzustellen. Dann taucht in einem anderen Dokument plötzlich die EN 301 549 auf. Das Technik-Team beginnt zu rätseln, welcher Standard anzuwenden ist und was genau eigentlich geprüft werden muss.
Diese Verwirrung ist verständlich. Beide Standards sind eng miteinander verknüpft, haben jedoch unterschiedliche Rollen und Anwendungsbereiche.
Für Teams, die digitale Produkte entwickeln oder verwalten, ist diese Unterscheidung wichtig – insbesondere wenn Barrierefreiheit in Design-, Entwicklungs-, Qualitätssicherungs- und Compliance-Prozesseintegriert werden muss.
Was ist die EN 301 549?
EN 301 549 ist die europäische Norm für Anforderungen an die Barrierefreiheit von Produkten und Dienstleistungen der Informations- und Kommunikationstechnik (IKT).
Ihr Geltungsbereich geht über reine Websites hinaus. Die Norm deckt Anforderungen für Technologien wie Websites und Nicht-Web-Dokumente, Software und mobile Anwendungen, Hardware sowie weitere IKT-Produkte und -Dienstleistungen ab.
Das ändert die Perspektive für ein Produkt-Team.
Wenn Ihr Unternehmen einen komplexen digitalen Dienst betreibt, muss die Barrierefreiheit über alle relevanten Komponenten dieses Dienstes hinweg berücksichtigt werden – nicht nur auf der Hauptseite der Website.
Für technische Teams bietet die EN 301 549 Anforderungen, die in Spezifikationen, Beschaffungsprozesse, Entwicklung und Tests integriert werden können.
Die Europäische Kommission stellt klar, dass die Norm über die Anforderungen der WCAG hinausgeht. Daher bedeutet die Erfüllung aller relevanten WCAG-Erfolgskriterien nicht automatisch, dass auch alle Anforderungen der EN 301 549 abgedeckt sind.
Welche Rolle spielen die WCAG?
Die WCAG (Web Content Accessibility Guidelines) sind der vom W3C entwickelte internationale Standard für die Barrierefreiheit von Webinhalten.
Die WCAG-Erfolgskriterien basieren auf vier Prinzipien:
- Wahrnehmbarkeit
- Bedienbarkeit
- Verständlichkeit
- Robustheit
Unter diesen Prinzipien sind prüfbare Erfolgskriterien in drei Konformitätsstufen unterteilt: A, AA und AAA.
In der Praxis lassen sich diese Kriterien in sehr konkrete Anforderungen übersetzen.
Ein informatives Bild benötigt eine passende Textalternative.
Inhalte müssen über einen ausreichenden Kontrast verfügen.
Funktionen müssen über die Methoden bedienbar sein, die von den geltenden Erfolgskriterien gefordert werden.
Formulare müssen so implementiert sein, dass die für Nutzer erforderlichen Informationen und Beziehungen dort programmatisch ermittelt werden können, wo dies durch das entsprechende Kriterium gefordert wird.
Der Tastaturfokus muss sichtbar und nachverfolgbar sein.
Interaktive Komponenten müssen so implementiert sein, dass assistierende Technologien die benötigten Informationen über sie abrufen können.
Plötzlich wird „Barrierefreiheit“ zu einer Reihe von Anforderungen, über die Designer, Entwickler und Qualitätssicherungs-Spezialisten tatsächlich diskutieren und die sie testen können.
EN 301 549 und WCAG sind nicht dasselbe
Dies ist eine der wichtigsten Unterscheidungen, die man verstehen muss.
Die WCAG konzentrieren sich auf die Barrierefreiheit von Webinhalten. Die EN 301 549 hat einen breiteren IKT-Anwendungsbereich und integriert die WCAG-Anforderungen für Webinhalte in ihre Struktur, ergänzt um weitere Anforderungen.
Die für die europäischen harmonisierten Anforderungen an die Barrierefreiheit derzeit relevante Version der EN 301 549 nutzt WCAG 2.1. Die Europäische Kommission stellt fest, dass WCAG 2.2 noch nicht durch die Veröffentlichung ihres Verweises im Amtsblatt der Europäischen Union in einer harmonisierten Norm EN 301 549 verwendet wird.
Diese Unterscheidung ist im Jahr 2026 wichtig.
Doch WCAG 2.2 existiert bereits
WCAG 2.2 ist die aktuellste finale Version der WCAG-Familie. Das W3C empfiehlt, bei der Entwicklung oder Aktualisierung von Richtlinien und Verfahren zur Barrierefreiheit stets die neueste Version zu verwenden.
WCAG 2.2 ergänzt die WCAG 2.1 um neun neue Erfolgskriterien. Dazu gehören Anforderungen an die Sichtbarkeit des Fokus, die Mindestgröße von Klickflächen, Alternativen zu Drag-and-Drop-Interaktionen, barrierefreie Authentifizierung sowie die Vermeidung redundanter Dateneingaben in bestimmten Situationen.
Seit 2025 ist WCAG 2.2 zudem ein internationaler ISO-Standard: ISO/IEC 40500:2025.
Für technische Teams ergibt sich daraus eine Unterscheidung zwischen dem europäischen Standard, der für den relevanten Rechtsrahmen maßgeblich ist, und der vom W3C für die aktuelle Entwicklung barrierefreier Inhalte empfohlenen WCAG-Version.
Das W3C weist zudem darauf hin, dass Inhalte, die WCAG 2.2 entsprechen, aufgrund der konzeptionellen Gestaltung der aufeinanderfolgenden Versionen automatisch auch WCAG 2.1 und WCAG 2.0 erfüllen.
Was bedeutet das für Produktteams?
Barrierefreiheit funktioniert am besten, wenn sie bereits Teil der Produktanforderungen ist, bevor die Entwicklung beginnt.
Nehmen wir ein einfaches Formular zur Kontoerstellung.
Das Team definiert die Felder und Validierungsregeln. UX definiert die Interaktion. Das Design bereitet die Komponenten und deren Zustände vor. Die Entwicklung setzt sie um. Die Qualitätssicherung prüft das Ergebnis.
Wird Barrierefreiheit erst nach dem Launch berücksichtigt, erfordern die entdeckten Probleme möglicherweise Änderungen in mehreren dieser Bereiche.
Werden die Anforderungen bereits während der Planung definiert, kann das Team von Anfang an über Beschriftungen, Fokus, Fehlermeldungen, Kontraste und Tastaturbedienung sprechen.
Dies reduziert auch Situationen, in denen Barrierefreiheit zu einer separaten Liste von Fehlern wird, die nach der Veröffentlichung behoben werden müssen.
Was sollten UX- und Design-Teams beachten?
Ein gutes Design-System kann verhindern, dass sich dasselbe Problem mit der Barrierefreiheit auf Dutzenden von Seiten wiederholt.
Schaltflächen, Formulare, Modals, Navigation, interaktive Komponenten und Fokus-Zustände sollten in ihren Spezifikationen stets die Anforderungen an die Barrierefreiheit berücksichtigen.
Der Kontrast ist hierfür ein offensichtliches Beispiel.
Doch Barrierefreiheit endet nicht bei der Farbwahl.
Designer müssen auch berücksichtigen, wie Nutzer die Informationshierarchie, Komponentenstatus, Fehlermeldungen und Interaktionen verstehen, die nicht von einer einzigen Eingabemethode abhängen.
Eine Komponente kann in einer Designdatei perfekt aussehen und nach der Implementierung dennoch Probleme bei der Barrierefreiheit verursachen.
Deshalb muss die Prüfung auf Barrierefreiheit auch am funktionsfähigen Produkt fortgesetzt werden.
Was sollten Entwicklungsteams beachten?
Semantisches HTML und die korrekte Implementierung von Komponenten spielen eine direkte Rolle für die Barrierefreiheit.
Entwickler müssen verstehen, was passiert, wenn ein Nutzer die Maus beiseitelegt und versucht, die Benutzeroberfläche ausschließlich über die Tastatur zu bedienen.
Ebenso wichtig ist, welche Informationen an assistierende Technologien übermittelt werden.
Wie lautet der barrierefreie Name der Komponente?
Welche Rolle hat sie?
In welchem Zustand befindet sie sich?
Was passiert mit dem Fokus, wenn ein modales Fenster geöffnet oder geschlossen wird?
Kann das Formular tatsächlich ausgefüllt werden?
Diese Fragen sind während der Entwicklung weitaus nützlicher als die vage Anforderung, dass „die Seite barrierefrei sein muss“.
Was sollten QA-Teams berücksichtigen?
Automatisierte Tests sind nützlich, können aber nicht jede Anforderung an die Barrierefreiheit allein abdecken.
Das W3C erklärt, dass die WCAG so konzipiert sind, dass die Konformität durch eine Kombination aus automatisierter Prüfung und menschlicher Beurteilung.
Genau hier bleibt manuelles Testen unverzichtbar.
Die Qualitätssicherung kann die Tastaturnavigation, die Fokusreihenfolge und das Komponentenverhalten prüfen. Tests mit assistiven Technologien bieten eine zusätzliche Validierungsebene.
Automatisierte Tests hingegen können bestimmte wiederkehrende Probleme auf vielen Seiten schnell identifizieren.
Die Kombination dieser Methoden liefert ein wesentlich aussagekräftigeres Bild, als sich nur auf einen einzelnen Wert zu verlassen.
Ein Barrierefreiheits-Score sagt nicht alles aus
Das Dashboard zeigt 92/100. Klingt gut.
Aber was passiert, wenn das verbleibende Problem genau die Schaltfläche betrifft, mit der eine Zahlung abgeschlossen wird?
Die Auswirkungen auf den Nutzer stehen nicht zwangsläufig im Verhältnis zur Gesamtzahl der Fehler.
Deshalb sollten Teams auch den Schweregrad eines Problems, die betroffene Komponente und wo sie innerhalb einer kritischen User Journey auftritt.
Kaufabwicklung, Authentifizierung, Kontoerstellung, Bezahlung und Buchung sind Beispiele dafür, wo eine einzige Barriere Nutzer daran hindern kann, eine Aktion abzuschließen.
Bei der Priorisierung der Fehlerbehebung sollte dieser Kontext berücksichtigt werden.
Barrierefreiheit endet nicht mit der Veröffentlichung
Ein digitales Produkt verändert sich ständig.
Neue Seiten, Komponenten und Integrationen kommen hinzu. Das Marketing-Team veröffentlicht neue Inhalte. Ein Formular wird angepasst. Der Checkout-Prozess erhält ein Update.
Ein Test, der vor sechs Monaten durchgeführt wurde, beschreibt das Produkt so, wie es vor sechs Monaten existierte.
Deshalb sollte Ihr Prozess Tests nach relevanten Änderungen sowie die Überwachung auf Probleme umfassen, die im Zuge der Produktentwicklung entstehen können.
Wawsome hilft dabei, automatisch erkennbare Barrieren zu identifizieren und die Barrierefreiheit Ihrer Website kontinuierlich zu überwachen.
Wie sollte ein interner Prozess für Barrierefreiheit aussehen?
Für ein Team, das kontinuierlich ein digitales Produkt betreut, sollte Barrierefreiheit an mehreren Punkten des Prozesses berücksichtigt werden.
Bei den Anforderungen, wenn die Funktionalität definiert wird.
Im Design-System, für wiederverwendbare Komponenten.
Bei der Entwicklung und Code-Überprüfung, wenn diese Komponenten implementiert werden.
Bei der Qualitätssicherung, durch automatisierte und manuelle Tests.
Nach der Veröffentlichung, durch Überwachung und erneute Prüfung geänderter Bereiche.
Dadurch werden EN 301 549 und WCAG von abstrakten Standards zu konkreten Anforderungen, Entwicklungsaufgaben und Testfällen. mit denen Teams auch wirklich arbeiten können.
FAQ
Sollte ich WCAG 2.1 oder WCAG 2.2 verwenden?
Die EN 301 549 verwendet in der aktuell harmonisierten Fassung auf europäischer Ebene noch WCAG 2.1. Das W3C empfiehlt jedoch die Nutzung der neuesten WCAG-Version und stellt klar, dass Inhalte, die WCAG 2.2 entsprechen, auch die Anforderungen von WCAG 2.1 erfüllen.
Für rechtliche Verpflichtungen sollten Sie prüfen, welcher spezifische Standard und welcher regulatorische Rahmen für das jeweilige Produkt oder die Dienstleistung maßgeblich ist.
Erfülle ich automatisch die Anforderungen der EN 301 549, wenn ich WCAG-konform bin?
Nein. Die EN 301 549 hat einen breiteren Anwendungsbereich. Die Europäische Kommission stellt ausdrücklich fest, dass die Erfüllung aller WCAG 2.1-Erfolgskriterien allein keine Vermutung der Konformität mit allen relevanten Anforderungen der EN 301 549 begründet.
Kann ich alle WCAG-Erfolgskriterien automatisch testen?
Nein. Die Bewertung der Barrierefreiheit erfordert auch Prüfungen, die menschliches Urteilsvermögen voraussetzen. Automatisierte Tests sind nützlich für Probleme, die technisch und konsistent erkannt werden können, sie können jedoch keine manuelle Prüfung ersetzen.
Wann sollte ich die Barrierefreiheit testen?
Während der Entwicklung und vor der Veröffentlichung sowie erneut nach Änderungen, die sich auf die Nutzererfahrung auswirken könnten. Bei Produkten, die häufig aktualisiert werden, kann eine kontinuierliche Überwachung Teams dabei helfen, neue Probleme direkt bei ihrem Auftreten zu erkennen.
Wo sollten Sie anfangen?
Wenn Ihr Team eine bestehende Website betreut, verschaffen Sie sich zunächst einen Überblick darüber, welche Barrierefreiheitsprobleme sich sofort identifizieren lassen. Die Ergebnisse eines ersten Scans bieten einen Ausgangspunkt, um weitere Tests und Optimierungen zu priorisieren.
Für eine vollständige Bewertung sollten automatisierte Ergebnisse durch manuelle Prüfungen ergänzt werden, die für Kriterien erforderlich sind, welche nicht automatisch ausgewertet werden können.