Ein umfassender Leitfaden zum Verständnis und zur Umsetzung des Europäischen IKT-Barrierefreiheitsstandards - die harmonisierte technische Spezifikation für Barrierefreiheitsanforderungen in der gesamten EU
EN 301 549, offiziell betitelt "Barrierefreiheitsanforderungen für IKT-Produkte und -Dienstleistungen", ist ein europäischer Standard, der vom European Telecommunications Standards Institute (ETSI) veröffentlicht wurde. Erstmals 2014 veröffentlicht und seitdem regelmäßig aktualisiert (aktuelle Version 3.2.1 wurde im August 2021 harmonisiert), bietet dieser Standard umfassende technische Spezifikationen, um Informations- und Kommunikationstechnologie für Menschen mit Behinderungen zugänglich zu machen.
Der Standard ist einzigartig in seinem Umfang und Ehrgeiz. Im Gegensatz zu vielen Barrierefreiheitsstandards, die sich eng auf bestimmte Technologien konzentrieren (wie Websites oder mobile Apps), deckt EN 301 549 das gesamte Spektrum an IKT-Produkten und -Dienstleistungen ab, einschließlich:
Durch die Bereitstellung eines einzigen, einheitlichen Satzes von Anforderungen, die auf all diese Bereiche anwendbar sind, beseitigt EN 301 549 die Notwendigkeit für Organisationen, mehrere, möglicherweise widersprüchliche Standards zu navigieren. Diese Harmonisierung ist besonders wertvoll für Unternehmen und öffentliche Einrichtungen, die in mehreren EU-Mitgliedstaaten tätig sind.
EN 301 549 hat einen besonderen rechtlichen Status als harmonisierter europäischer Standard. Diese Bezeichnung, formalisiert als die Europäische Kommission eine Referenz auf den Standard im Amtsblatt der Europäischen Union am 18. August 2021 veröffentlichte, hat erhebliche rechtliche Auswirkungen:
Wenn Sie einem harmonisierten Standard entsprechen, profitieren Sie von einer "Konformitätsvermutung" mit den gesetzlichen Anforderungen von EU-Richtlinien und -Verordnungen, die auf diesen Standard verweisen. In praktischer Hinsicht bedeutet dies:
EN 301 549 wird explizit von wichtigen EU-Barrierefreiheitsgesetzen referenziert:
Dies bedeutet, dass unabhängig davon, ob Sie ein privates Unternehmen sind, das den EAA einhält, oder eine öffentliche Einrichtung, die die Web Accessibility Directive einhält, EN 301 549 die technische Spezifikation bietet, die Sie befolgen müssen.
Für Webinhalte integriert EN 301 549 die Web Content Accessibility Guidelines (WCAG) 2.1 Level AA wörtlich. Dies ist keine lose Ausrichtung oder Interpretation – es ist eine direkte Kopie der WCAG-Erfolgskriterien in den Standard.
Konkret reproduzieren Kapitel 9 von EN 301 549 ("Webinhalt") und Kapitel 10 ("Nicht-Web-Dokumente") die WCAG 2.1 Level A und Level AA Erfolgskriterien exakt. Dies bedeutet, dass wenn Sie bereits WCAG 2.1 kennen, Sie bereits die Webinhaltsanforderungen von EN 301 549 verstehen.
Allerdings geht EN 301 549 über WCAG hinaus, indem es auch Aspekte abdeckt, die WCAG nicht behandelt: Hardware-Ergonomie, bidirektionale Sprachkommunikation, Relay-Services, Video-Player und mehr. Es ist WCAG plus umfangreiche zusätzliche Anforderungen für Nicht-Web-IKT.
EN 301 549 hat sich seit seiner Entstehung erheblich entwickelt:
Der Standard wird vom Technical Committee Human Factors (TC HF) von ETSI gepflegt und regelmäßig überprüft, um sicherzustellen, dass er mit technologischen Entwicklungen und internationalen Best Practices übereinstimmt. Zukünftige Versionen werden wahrscheinlich WCAG 2.2 und schließlich WCAG 3.0 (derzeit in Entwicklung) einbeziehen, wenn diese Standards ausgereift sind.
EN 301 549 ist in 14 Hauptkapitel organisiert, die jeweils verschiedene Aspekte der IKT-Barrierefreiheit behandeln. Das Verständnis dieser Struktur hilft Ihnen, den Standard zu navigieren und zu identifizieren, welche Anforderungen auf Ihre spezifischen Produkte oder Dienstleistungen zutreffen:
Dieses entscheidende Kapitel beschreibt was Benutzer mit Behinderungen mit IKT tun können müssen, unabhängig von einer spezifischen Technologie. Dies sind hochrangige, ergebnisorientierte Anforderungen, die Folgendes abdecken:
Diese funktionalen Leistungsaussagen dienen als Rückfallebene – wenn spezifische technische Anforderungen für eine neuartige Technologie nicht existieren, können Sie die Konformität anhand dieser funktionalen Ergebnisse bewerten.
Anforderungen, die für alle IKT gelten, unabhängig vom spezifischen Technologietyp:
Anforderungen für Telekommunikationsdienste, VoIP, Videokonferenzen und ähnliche Technologien. Deckt Audioqualität, Echtzeit-Text, Videokommunikation für Gebärdensprachbenutzer und mehr ab.
Anforderungen für Media-Player, Videokonferenzsysteme und Videoinhalte. Beinhaltet Untertitelanzeige, Audiodeskriptions-Wiedergabe, Gebärdensprachpräsentation und Benutzersteuerung.
Physische Barrierefreiheitsanforderungen für Geräte, die Anschlüsse, mechanische Steuerungen, Tasten und Bedienelemente, taktile Anzeige, visuellen Kontrast, visuelle Anzeige von Audio, Anschluss von Hilfstechnologien und mehr abdecken.
Anforderungen, die sicherstellen, dass Produktdokumentation und Kundensupport barrierefrei sind. Dokumentation muss in barrierefreien Formaten verfügbar sein, und Support-Services müssen verschiedene Kommunikationsbedürfnisse berücksichtigen.
Anforderungen für Relay-Services (die es gehörlosen oder schwerhörigen Menschen ermöglichen, per Telefon zu kommunizieren) und Zugang zu Notfalldiensten.
Der Standard enthält informative Anhänge, die zusätzliche Anleitungen bieten, einschließlich Tabellen, die Anforderungen an funktionale Leistungsaussagen zuordnen, und Anleitungen zur Bestimmung der Anwendbarkeit.
Wie erwähnt, integriert Kapitel 9 von EN 301 549 die WCAG 2.1 Level A und Level AA Erfolgskriterien wörtlich. Dieses Kapitel gilt für Webseiten, einschließlich:
Die Anforderungen sind nach den vier Prinzipien von WCAG organisiert – Wahrnehmbar, Bedienbar, Verständlich und Robust (POUR). Da diese identisch mit WCAG 2.1 Level AA sind, gilt jede Ressource, die die WCAG 2.1-Konformität erklärt, gleichermaßen für die EN 301 549 Kapitel 9-Konformität.
Während wir hier nicht alle 50 Level A und AA Erfolgskriterien reproduzieren werden (sie sind in WCAG-Ressourcen ausführlich dokumentiert), gehören zu den am häufigsten verletzten und wirkungsvollsten Anforderungen:
Jedes Nicht-Text-Element – Bilder, Symbole, Diagramme, Grafiken, Schaltflächen ohne Text – muss eine Textalternative haben, die gleichwertige Informationen vermittelt. Dies ermöglicht es Screenreader-Benutzern, visuelle Inhalte zu verstehen.
Alle Funktionen müssen über eine Tastaturschnittstelle bedienbar sein, ohne dass bestimmte Zeitvorgaben für einzelne Tastenanschläge erforderlich sind. Es darf keine Tastaturfallen geben, in denen Benutzer stecken bleiben und nicht wegnavigieren können.
Text muss ein Kontrastverhältnis von mindestens 4,5:1 gegenüber seinem Hintergrund haben (3:1 für großen Text). Benutzeroberflächenkomponenten und grafische Objekte müssen mindestens 3:1 Kontrast haben.
Verwenden Sie geeignetes Überschriften-Markup (H1-H6), um Inhalte logisch zu strukturieren. Überschriften sollten beschreibend und in logischer Reihenfolge sein. Formularbeschriftungen müssen ordnungsgemäß mit ihren Steuerelementen verknüpft sein.
Jede tastaturbedienbare Schnittstelle muss einen Betriebsmodus haben, in dem die Tastaturfokusanzeige sichtbar ist. Entfernen Sie niemals Fokusumrisse, ohne eine ebenso sichtbare Alternative bereitzustellen.
Für alle Benutzeroberflächenkomponenten können Name und Rolle programmatisch bestimmt werden. Zustände, Eigenschaften und Werte können programmatisch gesetzt und an Hilfstechnologien kommuniziert werden (typischerweise unter Verwendung von ARIA).
Kapitel 11 gilt für Software, die kein Webinhalt ist, einschließlich:
Einer der wichtigsten Aspekte von Kapitel 11 ist die Anforderung, dass Software Plattform-Barrierefreiheitsdienste ordnungsgemäß nutzt. Dies bedeutet:
Software muss dokumentierte Plattform-Barrierefreiheitsdienste verwenden, anstatt benutzerdefinierte, inkompatible Lösungen zu implementieren. Zum Beispiel:
Durch die Verwendung dieser Plattformdienste wird Ihre Software automatisch mit Hilfstechnologien wie Screenreadern, Bildschirmlupen, Sprachsteuerung und Switch-Zugriff kompatibel, die Benutzer bereits installiert haben und zu verwenden wissen.
Jedes Benutzeroberflächenelement muss programmatisch bestimmbare Informationen über Folgendes offenlegen:
Hilfstechnologien müssen in der Lage sein, Fokus programmatisch zu verschieben und Textauswahl zu ändern. Dies ermöglicht es Screenreader-Benutzern, Inhalte effizient zu navigieren und zu bearbeiten.
Genau wie Webinhalte muss alle Softwarefunktionalität über Tastatur verfügbar sein. Dies umfasst benutzerdefinierte Steuerungen, Dialoge, Menüs und alle interaktiven Elemente. Tastaturkürzel sollten auffindbar und anpassbar sein, wo es machbar ist.
Der Tastaturfokus muss deutlich sichtbar sein. Viele native UI-Frameworks bieten Standard-Fokusindikatoren, aber wenn Sie das UI-Erscheinungsbild anpassen, stellen Sie sicher, dass der Fokus offensichtlich bleibt.
Software sollte Benutzerpräferenzen respektieren für:
Überschreiben Sie keine Barrierefreiheitseinstellungen auf Systemebene, es sei denn, der Benutzer wählt explizit anwendungsspezifische Einstellungen.
Wenn Ihre Software ein Authoring-Tool ist – etwas, das Benutzer zum Erstellen von Inhalten verwenden (Content-Management-Systeme, Dokumenteditoren, Website-Builder usw.) – gelten zusätzliche Anforderungen:
Kapitel 8-Anforderungen gelten für physische IKT-Geräte mit benutzerseitigen Hardware-Steuerungen und -Funktionen, einschließlich:
Für feste Installationen wie Geldautomaten und Kioske:
Wo Sprachausgabe verfügbar ist, muss es eine taktile Anzeige (wie ein erhabener Punkt oder Symbol) auf mindestens einem Betriebsmodus geben, der Sprachausgabe bereitstellt, damit blinde Benutzer Audioausgabemodi durch Berührung finden können.
Für Geräte mit Audioausgabe:
Hardware muss den Anschluss von Hilfstechnologien ermöglichen (alternative Tastaturen, Zeigegeräte, Schalter usw.), entweder direkt oder über die Plattform. Standard-Anschlusspunkte sollten nicht durch das Design des Geräts blockiert werden.
Kapitel 10 gilt für Dokumente, die keine Webseiten sind, aber über Software oder Websites bereitgestellt werden. Dies umfasst:
Kapitel 10 passt WCAG 2.1 Level A und AA Erfolgskriterien für den Dokumentenkontext an. Während Webseiten von Natur aus dynamisch und interaktiv sind, sind Dokumente oft statischer, sodass einige Anforderungen entsprechend angepasst werden.
Dokumente müssen geeignetes strukturelles Markup verwenden:
Alle Bilder, Diagramme, Grafiken und Nicht-Text-Elemente müssen Textalternativen haben, die ihren Inhalt und Zweck beschreiben. Dekorative Bilder sollten als solche markiert werden.
Text muss minimale Kontrastverhältnisse erfüllen (4,5:1 für normalen Text). Informationen sollten nicht allein durch Farbe vermittelt werden – verwenden Sie Textbeschriftungen, Muster oder andere Indikatoren zusätzlich zur Farbe.
Ausfüllbare Formulare (wie PDF-Formulare) müssen haben:
PDFs sind das häufigste Nicht-Web-Dokumentformat. Um PDFs barrierefrei zu machen:
EN 301 549 ist umfassend, aber nicht jede Anforderung gilt für jedes Produkt. So bestimmen Sie die Anwendbarkeit:
Schauen Sie sich an, was Ihre IKT tatsächlich tut. Anforderungen gelten nur, wenn die Funktion existiert:
Einige Anforderungen haben spezifische Ausnahmen oder alternative Konformitätspfade. Lesen Sie die "wo IKT..."-Klauseln sorgfältig – sie definieren genau, wann Anforderungen gelten.
Wenn Sie eine neuartige Technologie haben, die nicht klar durch spezifische technische Anforderungen abgedeckt ist, bewerten Sie gegen die funktionalen Leistungsaussagen in Kapitel 4. Können Benutzer mit verschiedenen Behinderungen die beschriebenen Ergebnisse erreichen?
Verwenden Sie automatisierte Tools, um häufige Probleme zu erkennen:
Denken Sie daran: Automatisierte Tools erfassen nur 25-30% der Barrierefreiheitsprobleme. Sie sind ein Ausgangspunkt, nicht die vollständige Antwort.
Wesentliche manuelle Tests umfassen:
Der Goldstandard ist das Testen mit echten Benutzern, die Behinderungen haben:
Wenn Sie Konformität mit EN 301 549 beanspruchen, dokumentieren Sie:
Viele Organisationen verwenden VPAT (Voluntary Product Accessibility Template) oder ACR (Accessibility Conformance Report)-Formate, um EN 301 549-Konformität standardisiert zu dokumentieren.
Ist EN 301 549 gesetzlich vorgeschrieben?
EN 301 549 selbst ist ein freiwilliger Standard. Allerdings verweist die EU-Gesetzgebung (die Web Accessibility Directive und der European Accessibility Act) auf ihn als technische Spezifikation für die Konformität. Wenn Sie diese Gesetze einhalten müssen, müssen Sie effektiv EN 301 549 einhalten.
Kann ich Konformität mit EN 301 549 beanspruchen, wenn ich nur WCAG 2.1 AA erfülle?
Wenn Ihre IKT rein Webinhalt ist und keine anderen Funktionen hat, und Sie WCAG 2.1 Level AA erfüllen, erfüllen Sie im Wesentlichen die Kapitel 9-Anforderungen von EN 301 549. Allerdings erfordert vollständige EN 301 549-Konformität die Erfüllung aller anwendbaren Anforderungen aus allen Kapiteln, nicht nur Kapitel 9.
Muss ich den Standard kaufen, um konform zu sein?
Das vollständige EN 301 549-Dokument ist kostenlos von der ETSI-Website herunterladbar. Im Gegensatz zu einigen Standards müssen Sie es nicht kaufen. Für Webinhalte speziell können Sie auch die kostenlose WCAG 2.1-Dokumentation von W3C referenzieren.
Was ist der Unterschied zwischen EN 301 549 und WCAG?
WCAG konzentriert sich ausschließlich auf Webinhalte. EN 301 549 integriert WCAG 2.1 für Webinhalte (Kapitel 9), deckt aber auch Nicht-Web-Software, Hardware, Dokumente, Telekommunikation, Video und mehr ab. Denken Sie an EN 301 549 als "WCAG plus alles andere".
Welche Version sollte ich verwenden?
Verwenden Sie die neueste harmonisierte Version, derzeit V3.2.1 (2021). Dies ist die Version, auf die sich die EU-Gesetzgebung bezieht. Ältere Versionen sind überholt, obwohl unter älteren Versionen entwickelte Produkte möglicherweise eine gewisse Übergangsanerkennung haben.
Unser Produkt ist eine mobile App. Welche Kapitel gelten?
Mobile Apps werden von Kapitel 11 (Software) abgedeckt. Wenn die App spezifische Funktionen wie Videowiedergabe oder Sprachkommunikation hat, können auch relevante Teile der Kapitel 6-7 gelten. Wenn die App In-App-Dokumentation enthält, gilt Kapitel 12. Im Grunde identifizieren Sie, was Ihre App tut, und wenden die relevanten Kapitel an.
Wir stellen ein Hardwaregerät mit eingebetteter Software her. Wie erfüllen wir die Anforderungen?
Sie müssen sowohl Hardware-Anforderungen (Kapitel 8) als auch Software-Anforderungen (Kapitel 11) erfüllen. Zusätzlich gilt Kapitel 5 (allgemeine Anforderungen). Wenn es physische Steuerungen gibt, stellen Sie sicher, dass sie taktile, visuelle und betriebliche Anforderungen erfüllen. Wenn es einen Bildschirm und Software-UI gibt, stellen Sie sicher, dass es gemäß Kapitel 11 barrierefrei ist.
Können wir "teilweise Konformität" beanspruchen?
Ja, Sie können teilweise Konformität beanspruchen und bekannte Probleme dokumentieren. Dies ist besser als fälschlicherweise vollständige Konformität zu beanspruchen oder Nicht-Konformität zu beanspruchen, wenn Sie erhebliche Fortschritte gemacht haben. Seien Sie transparent darüber, was funktioniert und was nicht.
Müssen wir Legacy-Produkte konform machen?
Das hängt von der anwendbaren Gesetzgebung ab. Unter dem EAA haben bestehende Produkte bis zum 28. Juni 2030 Zeit zur Konformität. Unter der Web Accessibility Directive sollten Websites und Apps des öffentlichen Sektors bereits konform sein. Prüfen Sie die spezifischen rechtlichen Anforderungen, die auf Ihre Situation zutreffen.
Wir verwenden Drittanbieter-Komponenten. Sind wir für deren Barrierefreiheit verantwortlich?
Im Allgemeinen ja. Wenn Sie Drittanbieter-Code oder -Komponenten in Ihr Produkt integrieren, sind Sie für die Gesamtbarrierefreiheit Ihres Produkts verantwortlich. Wählen Sie barrierefreie Drittanbieter-Komponenten, und wenn sie nicht barrierefrei sind, beheben Sie sie entweder oder finden Sie Alternativen. Dokumentieren Sie alle Drittanbieter-Einschränkungen in Ihrer Barrierefreiheitserklärung.
Wie testen wir Software-Barrierefreiheit (Kapitel 11)?
Verwenden Sie plattformspezifische Barrierefreiheitstest-Tools: Accessibility Insights für Windows, Accessibility Inspector für macOS/iOS, Accessibility Scanner für Android. Testen Sie mit tatsächlichen Hilfstechnologien auf jeder Zielplattform. Überprüfen Sie, dass Ihre UI Informationen ordnungsgemäß über Plattform-Barrierefreiheits-APIs offenlegt.
Was ist, wenn unser benutzerdefiniertes UI-Framework keine Barrierefreiheit unterstützt?
Sie müssen Barrierefreiheitsunterstützung hinzufügen. Dies bedeutet typischerweise die Implementierung der Unterstützung für Plattform-Barrierefreiheits-APIs in Ihrem Framework. Überlegen Sie, ob Sie wirklich ein benutzerdefiniertes Framework benötigen – native oder etablierte Frameworks (React, Flutter, Qt usw.) haben bessere Barrierefreiheitsunterstützung. Wenn Sie benutzerdefinierte UI verwenden müssen, budgetieren Sie Zeit für die Barrierefreiheitsimplementierung; es ist nicht trivial.
Werden Spiele-UIs von EN 301 549 abgedeckt?
Wenn ein Spiel dem EAA oder der Web Accessibility Directive unterliegt (z.B. ein öffentlich finanziertes Bildungsspiel), ja. Mindestens sollten Menüs, Einstellungen und Nicht-Gameplay-UI barrierefrei sein. Gameplay selbst ist komplexer – wenden Sie funktionale Leistungskriterien an und stellen Sie sicher, dass Spieler mit Behinderungen in machbarem Umfang bedeutungsvoll teilnehmen können.
Wie machen wir ein PDF barrierefrei, wenn wir nur ein gescanntes Bild haben?
Führen Sie OCR (Optical Character Recognition) aus, um das Bild in Text zu konvertieren, und taggen Sie dann das resultierende PDF ordnungsgemäß. Für komplexe Layouts oder schlechte Scanqualität müssen Sie möglicherweise OCR-Fehler manuell korrigieren und die Struktur taggen. Alternativ überlegen Sie, ob der Inhalt stattdessen als HTML anstelle von PDF bereitgestellt werden könnte.
