In diesem Beitrag geht es um die Dokumentations-Anforderungen, die sich aus den Barrierefreiheitsvorgaben ergeben. Konkret geht es um Kapitel 12 der EN 301 549. Generell gibt es zu diesem Abschnitt der EN relativ wenige verfügbare zusätzliche Informationen oder Auslegungen. Wie immer bei rechtlichen Themen möchte ich darauf hinweisen, dass ich kein Jurist bin und es teils meine eigenen Interpretationen sind.
Einordnung von Kapitel 12 EN 301549
Zur kurzen Einordnung: Die EN 301 549 ist die maßgebliche Norm, wenn es um digitale Barrierefreiheit in der Europäischen Union geht. Sie definiert im Prinzip alle relevanten Anforderungen. Ein Kapitel wird dabei allerdings häufig übersehen – nicht zuletzt, weil es für viele klassische Websites bislang kaum eine Rolle gespielt hat: Kapitel 12.
In diesem Kapitel geht es weniger um technische Anforderungen, sondern vor allem um Dokumentation. Es war für viele Websites bisher nicht besonders relevant, denn die meisten Websites verfügen über keine zusätzliche Produkt- oder Nutzungsdokumentation.
Konformitätserklärung aka Erklärung zur Barrierefreiheit ist gefordert
Was jedoch in der Regel erforderlich ist – unabhängig davon, ob es sich um eine öffentliche oder eine privatwirtschaftliche Einrichtung handelt – ist eine Konformitätserklärung, häufig auch als Erklärung zur Barrierefreiheit bezeichnet. Wie man sie nennt, ist letztlich zweitrangig – wichtig ist, dass sie vorhanden ist.
Für öffentliche Stellen muss diese Erklärung öffentlich auffindbar sein, und das ist bei den meisten Websites heute auch der Fall. Im Kontext des BFSG hat sich ebenfalls der Begriff Erklärung zur Barrierefreiheit etabliert. Ihre genaue Ausgestaltung ist allerdings bisher völlig offen, weil es bislang keine Vorlage gibt.
Eine darüber hinausgehende Dokumentation existiert bei klassischen Websites meist nicht. Anders sieht es jedoch bei Anwendungen aus: etwa bei browserbasierten Web-Anwendungen, Desktop-Anwendungen, teilweise auch bei Apps – und natürlich bei Hardware.
Hier wird das Thema besonders spannend. Denn seit Inkrafttreten des Barrierefreiheitsstärkungsgesetzes (BFSG) am 28. Juni 2025 müssen bestimmte Hardware-Produkte zumindest teilweise barrierefrei sein. Dazu zählen unter anderem Computer, Smartphones, Internetzugangsdienste sowie Peripheriegeräte wie Internet- oder DSL-Modems und E-Book-Reader.
Insbesondere Hardware-Geräte verfügen häufig nicht über eine klassische grafische Benutzeroberfläche. Stattdessen gibt es meist ein Display zur Anzeige von Informationen und physische Bedienelemente wie Tasten oder Schalter. Eine grafische Oberfläche – falls es sie überhaupt gibt – ist oft nur ein nachgelagerter Schritt.
Gerade hier stellt sich die Frage der Barrierefreiheit besonders deutlich:
– Welche Funktionalitäten werden bereitgestellt?
– Und wie werden sie bereitgestellt, damit sie für alle Menschen zugänglich sind?
Werfen wir nun einen genaueren Blick auf Kapitel 12.
In Abschnitt 12.1 geht es um die allgemeinen Dokumentationsanforderungen. Hier wird festgelegt, welche Informationen in der Dokumentation im Hinblick auf Barrierefreiheit enthalten sein müssen.
Information zu Barrierefreiheit und speziellen Funktionen
Konkret beginnt das mit Kapitel 12.1.1: Dokumentation zur Kompatibilität und Barrierefreiheit. Wenn wir über Dokumentation im Sinne der Barrierefreiheit sprechen, geht es vor allem darum, alle Funktionalitäten aufzulisten, welche die Anwendung selbst bereitstellt.
Das bedeutet: Wenn eine Anwendung eigene Barrierefreiheitsfunktionen bereitstellt – zum Beispiel eine Bildschirmlupe, einen Screenreader, eine Sprachsteuerung oder eine Tastatursteuerung – dann muss dies alles dokumentiert werden. Diese Informationen können Nutzende in der Regel nicht selbst erkennen. Sie müssen wissen, welche Funktionen verfügbar sind und wie sie aktiviert werden.
Bei klassischen Websites ist das weniger kritisch, denn die Interaktionsmuster sind weitgehend bekannt und es werden eigene Einstellungen und assistive Technologien verwendet. Nutzende wissen in der Regel, wie sie die Tastatur oder einen Screenreader einsetzen können. Bei Hardware oder komplexeren Anwendungen ist das jedoch anders: Wenn zum Beispiel eine Tastaturbedienung vorgesehen ist, muss klar sein, wie sie funktioniert, welche Zubehörteile nötig sind, und welche Spezialfunktionen aktiviert werden. Man spricht auch von offenen Systemen, wenn eigene assistive Technologien genutzt werden können und von geschlossenen Systemen, wenn das System eigene assistive Funktionen bereitstellt.
Ein konkretes Beispiel: Einige Geldautomaten verfügen über eine Sprachausgabe, die aktiviert wird, sobald ein Kopfhörer angeschlossen wird. Nutzerinnen müssen wissen, dass es diese Buchse gibt, dass die Sprachausgabe startet und welche Funktionalitäten sie bietet.
Auch bei Webanwendungen gilt: Wenn spezielle Vorlesefunktionen oder Barrierefreiheitsfunktionen bereitgestellt werden, muss dies dokumentiert sein. Selbst Dinge wie kontrastreiche Designs oder Dark Mode zählen nicht unbedingt als Barrierefreiheitsfunktionen, können aber trotzdem in einer Dokumentation aufgeführt werden.
Darüber hinaus muss erklärt werden, wie die Funktionen zu nutzen sind. Beispielsweise gibt es für Tastatursteuerungen Unterschiede zwischen Windows, Linux und Mac. Bei speziell bereitgestellten Screenreader-Funktionen oder Tastenkombinationen muss die Nutzung klar dokumentiert sein – sonst wissen die Nutzenden nicht, wie sie die Funktionen einsetzen können.
Ein weiterer wichtiger Punkt: die Informationen müssen leicht auffindbar sein. Das kann zum Beispiel ein eigenes Kapitel in der technischen Dokumentation sein oder – bei Webanwendungen – ein Punkt in der Fußzeile mit dem Titel „Barrierefreiheitsinformationen“.
Barrierefreie Dokumentation
In Kapitel 12.1.2 geht es um die barrierefreie Bereitstellung der Dokumentation. Hier gilt: Egal, ob es sich um eine spezielle Barrierefreiheitsdokumentation oder die Dokumentation des gesamten Produkts handelt, sie muss digital und barrierefrei zugänglich sein.
• Browserbasierte Dokumentationen müssen die Anforderungen aus Kapitel 9 erfüllen.
• PDFs müssen die Anforderungen aus Kapitel 10 erfüllen.
Effektive Kommunikation über Hilfsmittel
Im zweiten Teil von Kapitel 12 geht es dann um den technischen Support. Auch hier gilt: Support muss barrierefrei bereitgestellt werden, wie in Abschnitt 12.2.2 beschrieben.
Auch das ist gar nicht so kompliziert: Support muss über verschiedene Kanäle erreichbar sein, sodass unterschiedliche Sinnesprinzipien abgedeckt werden.
• Blinde Menschen möchten beispielsweise oft telefonischen Support.
• Gehörlose Menschen bevorzugen schriftliche Kommunikation, etwa per E-Mail oder Chat.
Die Norm verlangt mindestens zwei unterschiedliche Kanäle – also verbal und schriftlich. Telefon und E-Mail sind hier sinnvoll und empfehlenswert. Zusätzliche Kanäle wie Chats oder andere digitale Services sind natürlich willkommen.
In Kapitel 12.2.3 geht es um effektive Kommunikation.
Hier wird festgelegt, dass das Supportpersonal in der Lage sein muss:
1. Die Anforderungen der Kundinnen und Kunden zu verstehen, insbesondere im Umgang mit assistiven Technologien.
2. Mit den Menschen angemessen zu kommunizieren und ihre speziellen Bedürfnisse zu berücksichtigen.
Beispiel: Das Personal muss erkennen können, wenn jemand Gebärdensprache benötigt, und im Idealfall die Möglichkeit bieten, einen Gebärdensprachdolmetscher einzusetzen.
Daraus folgt, dass Supportmitarbeitende geschult und regelmäßig informiert werden müssen, um die Grundlagen assistiver Technologien zu kennen. Auch wenn es in der Norm nicht explizit steht, ist es sinnvoll, diese Schulungen regelmäßig aufzufrischen. Schließlich entwickeln sich Technologien weiter, neue Kommunikationsmittel entstehen, und die Anforderungen können sich ändern.
Barrierefreie Dokumente durch den Support
Abschließend behandelt Abschnitt 12.2.4, dass technische Dokumentation barrierefrei bereitgestellt werden muss. Das heißt: Jede Anleitung, jedes Handbuch oder jede Dokumentation zum Produkt muss für alle Nutzenden zugänglich sein, egal ob digital, webbasiert oder als PDF.
Auch hier gilt: Eigentlich ist es relativ simpel. Alle Materialien, die vom Support bereitgestellt werden, müssen barrierefrei sein.
Das heißt konkret: Dokumente und Materialien müssen die Anforderungen erfüllen – Kapitel 9 für Webinhalte, Kapitel 10 für PDFs und so weiter. Klingt logisch, ist aber sehr sinnvoll, dass es explizit geregelt ist.
Damit das funktioniert, müssen die Mitarbeitenden geschult werden. Viele wissen gar nicht, wie man barrierefreie Dokumente erstellt oder barrierefreie Webseiten bereitstellt. Außerdem müssen die richtigen Tools zur Verfügung stehen. Ein Standard-PDF-Generator reicht oft nicht, weil das Ergebnis nicht barrierefrei ist. Die Mitarbeitenden brauchen also sowohl Know-how als auch die passenden Werkzeuge, um barrierefreie Materialien korrekt zu erstellen.
Fazit
Für klassische Websites ist das Kapitel 12 bisher kaum relevant. Durch das Thema barrierefreie Hardware wird es aber deutlich wichtiger, und ich gehe davon aus, dass die Marktüberwachung in diesem Bereich prüfen wird. Wer nur eine Website betreibt, muss sich darüber wahrscheinlich keine großen Gedanken machen. Wer jedoch Hardware oder komplexe Software barrierefrei bereitstellen muss, sollte das Thema ernst nehmen und sicherstellen, dass die Dokumentation und der Support den Anforderungen entsprechen.