Überarbeitung von Prüfschritten im Jahr 2021

Enthalten die neuen Prüfschritte wirklich normative Anforderungen?

Zuerst haben wir uns die Frage gestellt, ob denn diese Verweise auf andere Kapitel der EN wirklich normative Geltung haben, denn der ganze Annex A (PDF) ist als "informativ" (also nicht normativ verbindlich) ausgewiesen. Die Tabelle verweist jedoch auf die normativen Anforderungen aller Kapitel und betont, dass auch diese für Web-Inhalte gelten. Aus diesem Grund kamen wir nicht darum herum, uns die genannten Anforderungen im Detail anzusehen und zu ermitteln, wie diese ins BITV-Test-Prüfverfahren einzubeziehen sind.

Im Folgenden geben wir einen Überblick über die verschiedenen Bereiche der neuen Anforderungen. Bei "gewöhnlichen" Web-Auftritten sind viele davon jedoch nicht anwendbar.

Eine ganze Gruppe von Anforderungen betrifft zum Beispiel die Echtzeit Text-Kommunikation (RTT, Real-Time Text). Zurzeit ist RTT in Web-Angeboten und Anwendungen nicht verbreitet. Das kann sich, gerade in einer Situation, in der wegen der Pandemie ein Großteil der Kommunikation zwischen entfernten Teilnehmenden abläuft, natürlich bald ändern – und dann ist der BITV-Test schon vorbereitet, wichtige Barrierefreiheits-Anforderungen zu überprüfen. Andere Gruppen von Anforderungen betreffen etwa nur Video-Inhalte oder nur Autorensysteme: Die Content-Management-Systeme, mit denen Redakteure Web-Inhalte erstellen.

Die neuen Anforderungen im Überblick

Allgemeine Anforderungen (Kapitel 5, EN)

Hier geht es bei den anwendbaren Anforderungen zum einen darum, dass es Nutzenden möglich sein soll, zusätzliche Barrierefreiheitsfunktionen zu aktivieren. Beispiele für solche Funktionen sind Einstellungen für Kontrastansichten oder Funktionen, welche die Seite vorlesen, oder Versionen in Leichter Sprache (5.2 Aktivierung von Barrierefreiheits-Funktionen).

Zum anderen wird für Web-Angebote, die biometrische Authentifizierung oder Steuerung einsetzen (etwa über Fingerabdrucksensor, Sprach- oder Gesichtserkennung), verlangt, dass mindestens eine weitere Methode verfügbar ist (5.3 Biometrie).

Und schließlich sollen Barrierefreiheitsinformationen (zum Beispiel die semantische Auszeichnung eines Textes mit Überschriften) bei der Konvertierung von Informationen erhalten bleiben (5.4. Erhaltung von Barrierefreiheits-informationen bei Konvertierung).

Anforderungen an Technologien mit zwei-Wege-Sprachkommunikation (Kapitel 6, EN)

Die Prüfschritte aus Kapitel 6 zielen auf Web-Angebote ab, die eine Zwei-Wege-Sprachkommunikation in Echtzeit bieten. Beispiele sind Web-Clients der jetzt verstärkt genutzten Video-Konferenz-Systeme wie Zoom, Microsoft Teams, WebEx, Big Blue Button usw. Ein weiterer Anwendungsbereich: Shop-Systeme, die Internet-Telefonie für die Kundenbetreuung integrieren.

Die EN fordert beispielsweise zusätzlich zur Implementierung von Zwei-Wege-Sprachkommunikation eine Echtzeit-Textkommunikation (Real-Time Text). Bei den gängigen Systemen gibt es häufig neben der Sprachkommunikation auch eine Chat-Funktion. Eine Echtzeit-Textkommunikation ist jedoch etwas anderes als ein Chat: Der Text erscheint schon beim Schreiben mit nur sehr geringer Verzögerung bei anderen Teilnehmern.

Außerdem sollen Menschen, die über Texteingabe kommunizieren, denen, die sprechen, gleichgestellt sein. Dies betrifft zum Beispiel Wortmeldungen, Warteschlangen, Identifizierung von Teilnehmenden und die Anzeige von Sprech- (oder Schreib-) Aktivität.

Verlangt wird zudem, dass relevante Funktionen dabei programmatisch ermittelbar sind. Taubblinde Braille-Nutzer können dadurch beispielsweise an einer Video-Konferenz teilnehmen. Impliziert, aber nicht explizit gefordert ist wohl, dass auch Spracheingaben als Echtzeit-Transkription angeboten werden.

Uns sind zurzeit keine Systeme bekannt, die Echtzeit-Text-Kommunikation unterstützen. Über Hinweise sind wir dankbar. Wir sind gespannt, ob die Forderungen aus Kapitel 6 zu Ergänzungen der Funktionalität bei Videokonferenz-Anbietern führen werden.

Die zwölf zu prüfenden Anforderungen aus Kapitel 6 beziehen sich allesamt auf die Gleichstellung von Echtzeit-Text mit Spracheingabe sowie auf technische Anforderungen. Dazu gehören die unterstützte Audio-Bandbreite, die Video-Auflösung, die Bildwiederholfrequenz und Latenzzeiten bei der Echtzeit-Spracheingabe.

Anforderungen an eingebundene Videoplayer (Kapitel 7, EN)

Das Kapitel 7 betrifft den Bereich Video und ergänzt die bekannten Anforderungen des BITV-Tests bezüglich Untertitelung und (wo nötig) Audiodeskription von Videos (9.1.2.2 Erweiterte Untertitel und 9.1.2.5 Audio-Deskription – die bisherige Prüfschritt-Nummerierung ist an die der EN angeglichen).

Im Gegensatz zu den bisherigen BITV-Test-Anforderungen geht es im Kapitel 7 um die Fähigkeiten des eingesetzten Video-Players. Ein Punkt, der nicht immer von den heute genutzten Playern erfüllt wird: Die Positionierung der Bedienelemente zur Aktivierung von Untertiteln und (wo vorhanden) Audiodeskription. Die Bedienelemente sollen sich auf der gleichen Ebene befinden, wie die Schaltflächen zum Starten und Pausieren des Videos. Sie sollen nicht in einem Menü verborgen sein, das man erst – etwa über ein Zahnrad-Icon – einblenden muss.

Weitere Anforderungen an die Player betreffen das synchrone Abspielen von Untertiteln und Audiodeskription und den Erhalt dieser für die Barrierefreiheit so wichtigen Informationsebenen bei jedweder Übertragung, Konvertierung oder Aufzeichnung von Videos.

Anforderungen bezüglich benutzerdefinierter Einstellungen und Autorenwerkzeuge (Kapitel 11, EN)

Kapitel 11 zielt im Wesentlichen auf Autorenwerkzeuge. Zu solchen webbasierten Systemen zählen beispielsweise Content-Management- oder Blogging-Systeme.

Die Anforderungen betreffen gewöhnliche Webangebote eher weniger. Kommentarfunktionen für Lesende kann man jedoch in diesem Zusammenhang als Sonderfall von Autorensystemen betrachten und die Prüfschritte daher auch auf diese Funktionen anwenden.

Wir wollen jedoch zuerst auf 11.7 Benutzerdefinierte Einstellungen eingehen. Wenn Menschen bestimmte Einstellungen auf der zugrundeliegenden Plattform vornehmen, zum Beispiel weil sie eine größere Darstellung oder bessere Kontraste brauchen, sollen diese Einstellungen von Webangeboten übernommen werden. Die Plattform ist für eine Desktop-Anwendung das Betriebssystem. Auch bei Mobilgeräten wird vieles auf der Ebene des Betriebssystems eingestellt. Die EN weist in einer Anmerkung jedoch darauf hin, dass der Browser als die Plattform von Webangeboten gilt. Die Prüfung fokussiert deshalb auf Firefox als einen Desktop-Browser, der verglichen mit der Konkurrenz wohl die meisten benutzerdefinierten Einstellungsmöglichkeiten bietet.

Die übrigen Anforderungen betreffen dann Autorensysteme: Gefordert wird die Verfügbarkeit eines Templates, das barrierefreie Seiten erzeugt, die Umsetzung von Auszeichnungen im Autorenwerkzeug (also semantisch aufbereiteter Webinhalt), Korrekturhinweise (wenn etwa beim Hochladen eines Bildes der Alternativtext vergessen wird) und der Erhalt von Barrierefreiheitsinformationen bei Transformationen im gleichen oder in andere Dateiformate.

Anforderungen an Dokumentation und Support (Kapitel 12, EN)

Aus Kapitel 12 werden fünf Anforderungen in der Tabelle A.1 für Web-Angebote geltend gemacht.

Technische Dokumentationen gibt es hauptsächlich bei Web-Anwendungen. Wird die technische Dokumentation als nicht webbasiertes Dokument (etwa PDF) bereitgestellt, stößt ein Verfahren, das explizit auf die Prüfung von Web-Angeboten und -Anwendungen ausgerichtet ist, auf ein Problem. Dokumente und Webseiten sind zu verschieden, um mit den gleichen Prüfschritten bewertet zu werden. Die Prüfung solcher Inhalte muss daher an ein getrenntes, zusätzliches Verfahren delegiert werden.

Der BITV-Test prüft also alles an Dokumentation, was selbst im Web-Format angeboten wird. Diese Seite ist dann Teil der Seitenauswahl und alle anwendbaren Anforderungen werden geprüft.

Als Dokumentation gilt auch die in der EU-Richtlinie 2102 verlangte "Erklärung zur Barrierefreiheit", denn sie dokumentiert ja den erreichten Stand der Barrierefreiheit. Sie weist auf verbleibende Mängel hin und bietet Hinweise, wie unzugängliche Informationen auf anderem Wege erhalten werden können. Nicht zuletzt ist der verlangte Feedback-Mechanismus Teil der Support-Funktion und muss barrierefrei umgesetzt sein.

Die neuen Prüfschritte im Detail

Allgemeine Anforderungen (Kapitel 5, EN)

Aus Kapitel 5 (Allgemeine Anforderungen) kommen drei neue Anforderungen und damit drei Prüfschritte dazu.

5.2 Aktivierung von Barrierefreiheits-Funktionen

Dieser Prüfschritt ist anwendbar, wenn die zu prüfenden Angebote zusätzliche Barrierefreiheits-Funktionen einbinden. Dazu gehören Versionen in Leichter Sprache und Gebärdensprache, aber auch Einstellungen für Kontrastansichten, vergrößerten Text oder die häufig eingesetzten Vorlesefunktionen, welche die Seiteninhalte durch eine computergenerierte Stimme vorlesen.

Gefordert wird hier, dass Menschen mit speziellen Bedürfnissen diese Funktionen aktivieren können. Ein Schalter für eine Kontrastansicht für seheingeschränkte Menschen muss zum Beispiel selbst kontrastreich sein, damit die Zielgruppe ihn wahrnehmen kann.

In der Formulierung der Anforderung und im Verweis auf die speziellen Bedürfnisse (specific needs), die für die Aktivierung unterstützt werden müssen, liegt allerdings auch ein Problem. Viele Nutzende der Zielgruppe haben Mehrfachbehinderungen. Ein seheingeschränkter Mensch muss den Schalter nicht nur visuell erkennen können. Der Schalter muss auch einen verständlichen und von einem Screenreader auslesbaren Namen haben. Dann nämlich kann ein sehbehinderter Mensch, der visuell arbeitet, aber fallweise auch einen Screenreader einsetzt, den Schalter auch nicht-visuell identifizieren. Ähnliches gilt für Schalter für Versionen in Leichter Sprache. Menschen mit kognitiven Beeinträchtigungen, die Leichte Sprache brauchen, können auch andere Einschränkungen haben.

5.3 Biometrie

Biometrie ist zunehmend ein Verfahren, um Nutzende zu identifizieren. Die Smartphones bieten dafür beispielsweise den Fingerabdruck-Sensor. Andere biometrische Merkmale für die Nutzeridentifizierung sind die Gesichtserkennung, Iris-Erkennung oder Spracherkennung. Biometrie taucht in Web-Anwendungen bislang kaum auf (außer in systemgestützten Funktionen wie etwa der Passworteingabe, die nicht vom Autor verantwortet sind), aber auch das wird sich in Zukunft vielleicht ändern.

Die Anforderung 5.3 Biometrie verlangt nun, dass Web-Angebote, die eine bestimmte biometrische Methode einsetzen, diese nicht ausschließlich einsetzen. Es muss für Menschen, welche z. B. aufgrund von Behinderungen die angebotene Methode der biometrischen Identifizierung nicht nutzen können, eine Alternative geben – etwa Nutzernamen- und Passwort-Eingabe. Auch eine zweite biometrische Methode kann diesen Prüfschritt erfüllen.

5.4 Erhaltung von Barrierefreiheits-Informationen bei Konvertierung

Hier wird gefordert, dass semantische Informationen bei der Konvertierung von Inhalten (etwa dem Sichern einer Webseite als PDF) nicht verloren gehen. Beispielsweise unterstützen HTML- und PDF-Dateien die Auszeichnung von Überschriften, eine Konvertierungsfunktion könnte daher problemlos die Überschriftenauszeichnung aus dem HTML-Quelltext für PDF adaptieren. Dass Web-Angebote solche Konvertierungs-Funktionen selbst implementieren, ist bislang eher die Ausnahme (falls solche Funktionen vom Browser bereitgestellt werden, wäre dies nicht Teil der Prüfung).

Technologien mit Zwei-Wege-Sprachkommunikation (Kapitel 6, EN)

Insgesamt sind laut Tabelle A.1 zwölf Anforderungen aus Kapitel 6 für Web-Angebote relevant. Jedoch wäre für Webangebote, die keine Zwei-Wege-Sprachkommunikation anbieten, der gesamte Bereich nicht anwendbar.

6.1 Audiobandbreite für Sprache

Gute Sprachqualität ist besonders für Menschen mit Hörbehinderungen wichtig. Deshalb wird hier ein verbindlicher Mindeststandard für die Audioqualität festgelegt. Die Qualität soll dem Standard der internetgestützten Telefonie entsprechen. Qualitätsmängel durch schwache Internetverbindungen führen nicht zu einer negativen Bewertung, an diesen kann ein Web-Autor ja nichts ändern.

6.2.1.1 Textkommunikation in Echtzeit

Mit "Textkommunikation" ist hier nicht eine Chat-Funktion gemeint, wie sie meist in Webkonferenz-Systemen verfügbar ist. Gemeint ist Echtzeit-Textkommunikation (Real-Time Text): Schon während der Texteingabe, können die anderen Teilnehmer mit geringer Verzögerung sehen, wie sich der Text bei ihnen aufbaut. Die Nutzenden müssen den eingegebenen Text also nicht erst aktiv abschicken wie im Chat.

Gefordert wird, dass Systeme, die Echtzeit-Audiokommunikation bieten, ebenfalls Echtzeit-Textkommunikation unterstützen. Diese Anforderung wird von keinem uns bekannten Webkonferenz-System unterstützt – dennoch wird sie in der EN unmissverständlich gefordert.

6.2.1.2 Gleichzeitige Sprache und Text

Dieser Prüfschritt qualifiziert noch die Anforderung der Textkommunikation in Echtzeit: Menschen, die statt Sprache die Eingabe von Echtzeit-Text nutzen, sollen gleichrangig behandelt werden. Wen es also Funktionen wie das Handheben oder eine Warteschlange für Teilnehmende gibt, sollen Text-Teilnehmende diese Funktion gleichberechtigt nutzen können, es gibt keine Extra-Nische für sie. Die Wortmeldung (virtuelles Handheben) von Echtzeit-Text-Teilnehmenden taucht in der gleichen Warteschlange auf wie die Wortmeldungen von Sprechenden.

6.2.2.1 Visuell unterscheidbare Anzeige von Echtzeit-Textnachrichten

Menschen, die Echtzeit-Textkommunikation nutzen, sollen in der Lage sein, bereits empfangene und gesendete Nachrichten visuell zu unterscheiden. Empfangene und gesendete Textbeiträge einer Kommunikation sollen daher visuell deutlich unterscheidbar sein (können alternativ aber auch in einem Textcontainer angeboten werden).

6.2.2.2 Programmatisch unterscheidbare Anzeige von Echtzeit-Textnachrichten

Wenn Menschen, die Hilfsmittel wie Screenreader einsetzen, die Äußerungen in einer Kommunikation lesen wollen, müssen sie eigene Text-Beiträge von denen anderer unterscheiden können. Die eigenen Textnachrichten müssen zudem programmatisch von denen anderer Teilnehmenden unterscheidbar sein (etwa durch vorangestellte Namenskürzel).

6.2.2.3 Sprecheridentifizierung

Wenn bei Echtzeit-Sprachkommunikation die Sprechenden identifiziert werden, soll dies ebenso auch bei Echtzeit-Text-Teilnehmenden geschehen. Üblicherweise taucht in der Liste der Teilnehmenden neben Sprechenden ein (z. T. animiertes) Symbol auf, dass anzeigt, wer gerade spricht.

6.2.2.4 Echtzeitanzeige von Sprechaktivität

Eine wichtige Information in der Kommunikation, etwa in einer Web-Konferenz, ist die Anzeige, dass jemand spricht, sowie die Zuordnung des Beitrags zum jeweils Sprechenden. Wenn die Web-Anwendung Zwei-Wege-Sprachkommunikation unterstützt und Funktionen zur Echtzeit-Textkommunikation bietet, soll die Aktivität von Sprechenden in Echtzeit visualisiert werden und programmatisch ermittelbar sein.

6.2.3 Interoperabilität von Echtzeit-Kommunikation

Web-Anwendungen, welche (meist zusätzlich zur Sprach-Kommunikation) die Echtzeit-Textkommunikation mit anderen Anwendungen erlauben, sollen Interoperabilität für Echtzeit-Text-Kommunikation unterstützen. Hier ist zu prüfen (wohl über die Dokumentation), ob die Webanwendung die Protokolle unterstützt, um mit einer anderen RTT-fähigen Anwendung interoperabel zu sein.

6.2.4 Reaktionsgeschwindigkeit der Echtzeit-Textkommunikation

Um einen gut wahrnehmbaren Informationsfluss zu gewährleisten, sollen Echtzeit-Texteingaben in maximal 500 ms abgeschickt werden. Dabei sollen netzwerkbedingte Verzögerungen nicht berücksichtigt werden.

6.3 Anrufer-Identifizierung

Diese Anforderung stellt sicher, dass auch Nutzer von Hilfstechnologien den Anrufer identifizieren können. In einer Web-Anwendung, die Internet-Telefonie unterstützt, soll daher der Anrufende programmatisch ermittelbar sein, also nicht nur durch die visuelle Anzeige des Namens oder der Telefonnummer, sondern auch über die unmittelbare Ausgabe einer Meldung an den Screenreader.

6.5.2 Auflösung bei Videotelefonie

Für manche Menschen mit Behinderung ist ein Videobild mit ausreichender Auflösung besonders wichtig – zum Beispiel für gehörlose Menschen, die über das Mund-Bild von Sprechenden die Inhalte verstehen. Das Videosignal bei Web-Anwendungen mit Video-Telefonie soll mindestens eine QVGA-Auflösung (das sind 320 x 240 Pixel) unterstützen. Hier muss die technische Dokumentation der Anwendung konsultiert und ggf. auf Plausibilität überprüft werden. Die meisten heute gängigen Auflösungen werden ohnehin höher sein.

6.5.3 Bildwiederholfrequenz bei Videotelefonie

Auch die Bildwiederholfrequenz ist für Menschen mit Höreinschränkung für die Wahrnehmung etwa von Mimik und Gestik wichtig. Die Web-Anwendung soll prinzipiell eine Bildwiederholfrequenz von 20 Bildern pro Sekunde oder besser unterstützen. Schwächen der Netzwerkverbindung sollen diese Messung nicht beeinflussen.

Eingebundene Videoplayer (Kapitel 7, EN)

7.1.1 Wiedergabe von Untertiteln

Hier wird geprüft, ob sich im genutzten Video-Player dynamische, einblendbare (also nicht fest eingebrannte, sondern zusätzlich angebotene) Untertitel über Bedienelemente ein- und ausschalten lassen.

7.1.2 Synchrone Untertitel

Hier wird geprüft, ob der Player Untertitel synchron anzeigen kann. Wenn Ton und Untertitelung auseinanderlaufen, kann das entweder an einer falscher Zeitcodierung in der Untertitel-Datei oder am eingesetzten Player liegen.

7.1.3 Erhaltung von Untertiteln

Wenn Web-Anwendungen Videos übertragen, konvertieren oder aufzeichnen, sollen dabei die im Ausgangsformat verfügbaren Untertitel-Informationen voll erhalten bleiben.

7.2.1 Wiedergabe von Audiodeskription

Hier wird gefordert, dass – bei Vorhandensein von Audiodeskription – diese im Player ausgewählt werden kann, der Player also ein entsprechendes Bedienelement bereithält.

7.2.2 Synchrone Audiodeskription

Analog zu 7.1.2 Synchrone Untertitel wird hier geprüft, ob der genutzte Player zusätzlich ausgewählte Audiodeskriptions-Tracks synchron abspielen kann.

7.2.3 Erhaltung von Audiodeskription

Analog zu 7.1.3 Erhaltung von Untertiteln wird bei Web-Anwendungen, die Videos übertragen, konvertieren oder aufzeichnen, geprüft, ob eine ggf. im Ausgangsformat verfügbare zusätzliche Audiodeskription voll erhalten bleibt.

7.3 Bedienelemente für Untertitel und Audiodeskription

Dieser Prüfschritt bringt eine wesentliche neue Anforderung an Videoplayer. In diesem Prüfschritt wird verlangt, dass sich die Bedienelemente zum Anschalten von Untertitelung und Audiodeskription auf der gleichen Ebene befinden, wie andere Bedienelemente des Videos (etwa Start / Pause, das Regulieren der Lautstärke oder die Aktivierung der Vollbildansicht). Das entsprechende Bedienelement soll z. B. nicht in einem Menü verborgen sein, das über eine Schaltfläche geöffnet werden muss (z.B. über ein Zahnrad-Icon).

Benutzerdefinierte Einstellungen und Anforderungen an Autorenwerkzeuge (aus Kapitel 11, EN)

Aus den Anforderungen in Kapitel 11 (Software) sind für Web-Angebote zum einen benutzerdefinierte Einstellungen relevant, zum anderen eine Reihe von Anforderungen an Autorenwerkzeuge, die als Web-Anwendung umgesetzt sind.

11.7 Benutzerdefinierte Einstellungen

Wer den BITV-Test schon länger kennt, wird sich vielleicht erinnern, dass es einen ähnlichen Prüfschritt schon mal in anderer Form gab: als Prüfschritt 1.4.3c "Inhalte bei benutzerdefinierten Farben erkennbar". Die Anforderung 11.7 verlangt nun, dass Web-Angebote Nutzer-Voreinstellungen auf Plattformebene (für Webanwendungen ist das der Browser) übernehmen sollen. Dazu gehören Maßeinheiten, Farben, Schriftart und Schriftgröße sowie Cursor-Einstellungen.

11.8.2 Barrierefreie Erstellung von Inhalten

Dieser Prüfschritt richtet sich in erster Linie an Autorenwerkzeuge wie Content-Management-System (CMS). Diese sollen die Erzeugung barrierefreier Inhalte unterstützen. Wenn sich also im Autorenwerkzeug z.B. eine Überschrift definieren lässt (egal ob über ein getrenntes Textfeld oder die Auszeichnung in einem Editor) soll dies als semantische Auszeichnung der erzeugten Webseite übernommen werden.

Auch Kommentarfunktionen für Lesende, wie sie in vielen Blogs angeboten werden, können als Autorenwerkzeug im Sinne dieses Prüfschritts betrachtet werden. Lässt sich für einen Kommentar etwa eine getrennte Überschrift festlegen, soll diese auf der aktualisierten Seite semantisch ausgezeichnet sein. Dasselbe gilt für Alternativtexte von Bildern, die als alt-Attribute übernommen werden sollen.

11.8.3 Erhaltung von Barrierefreiheitsinformationen bei Transformation

Dieser Prüfschritt betrifft Web-Anwendungen, die Dateien umwandeln. Der erste Fall ist die Restrukturierung von Dateien im gleichen Dateiformat, etwa wenn ein langes HTML-Dokument in mehrere HTML-Seiten aufgeteilt wird.

Der zweite Fall ist die Umkodierung in ein anderes Dateiformat (zum Beispiel, wenn aus einer HTML-Seite ein PDF erzeugt wird). Semantische Informationen sollen bei so einer Transformation erhalten bleiben, soweit das Zielformat dies grundsätzlich ermöglicht. Die Überschriften im HTML-Dokument sollen zum Beispiel als semantische Überschriften ins PDF übernommen werden. Im BITV-Test lassen sich nur Umwandlungen prüfen, deren Ausgangs- und Zielformat HTML ist. Werden andere Dateiformate erzeugt oder eingelesen, muss die Erhaltung semantischer Information ggf. zusätzlich in einem anderen Verfahren geprüft werden.

11.8.4 Reparaturassistenz

Autorensysteme, die über eine Funktion zur Prüfung der Barrierefreiheit verfügen, sollen im Falle von Fehlern die Korrektur des Fehlers unterstützen. Ein Beispiel: Im CMS-Editor wurde ein Bild eingebunden, das Textfeld für den Alternativtext aber leer gelassen. Beim Speichern des Formulars weist eine Meldung darauf hin, dass Bilder einen sinnvollen Alternativtext enthalten sollten. Unserer Auffassung nach ist damit aber nicht gefordert, dass eine Barrierefreiheitsprüf-Funktion grundsätzlich angeboten werden muss – nur wenn sie vorhanden ist, sollen sinnvolle Korrektur-Hinweise ausgegeben werden.

11.8.5 Vorlagen

Wenn das Autorenwerkzeug Vorlagen für die Erstellung von Dokumenten anbietet, soll es mindestens eine Vorlage geben, die die Erstellung barrierefreier Inhalte unterstützt. Diese soll klar ausgewiesen sein. Auf vollständige Barrierefreiheit geprüft wird hier also das Ergebnis, die erzeugte Seite, nicht die Template-Seite selbst.

Dokumentation und Support (Kapitel 12, EN)

12.1.1 Dokumentation von Kompatibilität und Barrierefreiheit

Hier wird verlangt, dass die Dokumentation des Webangebots zusätzliche Eigenschaften und Barrierefreiheits-Funktionen auflistet und deren Nutzung erklärt - sofern diese Funktionen als Teil des Web-Angebots selbst implementiert wurden. Dazu gehören zum Beispiel eine Vorlesefunktion oder verfügbare Tastaturkurzbefehle. Auch Informationen zur (möglicherweise eingeschränkten) Kompatibilität mit assistiven Technologien zählen dazu.

12.1.2 Barrierefreie Dokumentation

Zur Verfügung gestellte Dokumentation eines Webangebots (meist eine Web-Anwendung) soll die Anforderungen von Kapitel 9 (Web) oder 10 (Dokumente) erfüllen. Im BITV-Test kann die Dokumentation in die Prüfung (über die Seitenauswahl) einbezogen werden, wenn sie als Webseite vorliegt. Letztlich wird dieser Prüfschritt mit "erfüllt" bewertet, wenn alle Anforderungen aus Kapitel 9 erfüllt sind. Anders herum, falls es dort nicht-konforme Prüfschritte gibt, ist auch dieser Prüfschritt nicht erfüllt.

12.2.2 Technischer Support

Hier wird verlangt, dass Support-Dienstleistungen Hilfestellung zu besonderen Zugänglichkeits- bzw. Kompatibilitätseigenschaften bieten, soweit sie in der Dokumentation genannt werden. Die Prüfung ist hier nicht einfach, da das Ergebnis ggf. von der Person abhängt, die zu einem bestimmten Zeitpunkt auf eine Support-Hotline antwortet. Es ist allerdings auch nicht festgelegt, dass nur der Telefon-Support gemeint ist. Bei schriftlichen Anfragen wird es also auch darum gehen, ob der Anbieter überhaupt in der Lage ist, auf spezifische Fragen eine Antwort zu geben.

12.2.3 Effektive Kommunikation

Hier wird gefordert, dass der Anbieter in der Lage ist, in der Kommunikation mit Menschen mit Behinderung für diese geeignete Kommunikationskanäle anzubieten. Dies kann auch durch die Vermittlung an Dritte geschehen. Die praktischen Anforderungen in der Prüfung sind noch etwas unklar, da sie in der EN-Anforderung nicht klar erläutert wurden. Denkbar wäre ein Ansatz, der wie in Anforderung 2.4.5a Alternative Zugangswege mindestens zwei Kanäle (z.B. E-Mail und Telefon) anbietet.

12.2.4 Vom Support bereitgestellte Dokumentation

Die zusätzliche Dokumentation, die Menschen auf Anfrage vom Support bereitgestellt wird, muss die Anforderungen von Kapitel 9 (Web) bzw. Kapitel 10 (Dokumente) erfüllen. Ähnlich wie beim Prüfschritt 12.1.2 Barrierefreie Dokumentation muss im Vorfeld geklärt werden, ob der Anbieter auf Anfrage webbasierte Dokumentationen zur Verfügung stellt. Diese muss dann in die Seitenauswahl der Prüfung einbezogen werden.