1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die zu prüfende Webseite spezielle Barrierefreiheits-Funktionen bereithält, die im Angebot selbst, etwa in den Einstellungen, oder in einer zur Verfügung gestellen technischen Dokumentation dokumentiert sind. Nicht berücksichtigt werden systemseitige Bedienungshilfen (z. B. vom Browser oder Betriebssystem).

2. Prüfung

1. Webseite aufrufen.

2. Falls dokumentierte Barrierefreiheitsfunktionen angeboten werden:

   • Ist die Barrierefreiheits-Funktion für die Zielgruppe identifizierbar?

   • Ist die Barrierefreiheits-Funktion für die Zielgruppe selbstständig aktivierbar?

3. Hinweise

3.3 Hinweis auf andere anwendbare Anforderungen

Bei nicht dokumentierten Barrierefreiheitsfunktionen, für die dieser Prüfschritt erfüllt ist, kann es zu negativen Bewertungen in anderen Prüfschritten kommen.

4. Bewertung

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Webseite biometrische Merkmale für die Nutzeridentifizierung oder Steuerung nutzt.

2. Prüfung

1. Webseite öffnen

2. Prüfen, ob nicht-biometrische oder biometrische Alternativen zur angebotenen biometrischen Identifizierung angeboten werden.

3. Bedienkonzept der wesentlichen Funktionen auf den zu testenden Webseiten untersuchen:

   • Wird Biometrie für die Steuerung genutzt?

   • Gibt es neben der identifizierten biometrischen Steuerung alternative nicht biometrische oder biometrische Steuerungsmethoden?

3. Hinweise

Zurzeit sind biometrische Aspekte der Steuerung hauptsächlich die Nutzer-Identifizierung als ein Schritt innerhalb eines Prozesses. So kann die Berührung eines Fingerabdrucksensors die Einfügung eines im System gespeicherten Passwortes für einen eingegebenen Nutzernamen freigeben. Diese Funktionalität wird aber in der Regel vom System bereitgestellt, der Autor hat darauf keinen Einfluss. Andere vom Autor gestaltbare Formen der Steuerung sind denkbar. Ansätze dazu gibt es etwa im Bereich digitaler Videoaufnahmen. Manche Systeme halten den Schärfepunkt automatisch auf einer (biometrisch identifizierten) Person, wenn sich diese durch den Bildraum bewegt. Auch in Spielen auf Basis von Augmented Reality wäre die Steuerung über die Erkennung biometrischer Eigenschaften denkbar.

4. Bewertung

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist grundsätzlich anwendbar, wenn die Webseite digitale Formate wie Text, Audio und Video konvertiert. Sind jedoch entweder das Ausgangs- oder das Zielformat der Konvertierung nicht HTML, kann der Prüfschritt nicht in diesem Verfahren allein geprüft werden, denn hier müsste zusätzlich eine Prüfung des abweichenden Formats durchgeführt werden. Hinsichtlich der Bewertung siehe "3. Hinweise".

2. Prüfung

Die Prüfung ist sehr individuell und richtet sich nach den verwendeten Quell- und Zielformaten. Die zusätzliche Prüfung des abweichenden Formats kann nicht im Rahmen dieses Prüfverfahrens durchgeführt werden.

1. Gegebenenfalls Beispieldokumente mit Barrierefreiheits-Informationen in das Zielformat konvertieren.

2. Sind vom Format grundsätzlich unterstützte Barrierefreiheits-Informationen nach der Konvertierung im Zielformat erhalten geblieben?

3. Hinweise

Da die Prüfung eines Nicht-HTML-Formats nicht mit diesem Prüfverfahren erfolgen kann, muss der Prüfschritt mit "nicht anwendbar" bewertet werden. Es sollte jedoch in einer Anmerkungen darauf hingewiesen werden, dass die Barrierefreiheits-Informationen (z.B. semantische Überschriften, Links oder Untertitel) im Zielformat erhalten bleiben sollen.

4. Bewertung

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Webanwendung eine Zwei-Wege-Sprachkommunikation anbietet.

2. Prüfung

1. Die Sprachqualität der Audio-Verbindung im Praxistest beurteilen. Entspricht die Qualität der Qualität aktueller Festnetztelefonie? Es muss dabei sichergestellt werden, dass die Internetverbindung an beiden Enden nicht beeinträchtigt ist. Ggf. wird der Test dazu wiederholt.

2. Führt der Hörtest zu keinem klaren Ergebnis, sollte die Dokumentation der Software konsultiert werden. Hier sollte der verwendete Codec zu finden sein. Ggf. muss beim Hersteller der Webanwendung nachgefragt werden.

3. Anschließend sollte der Codec recherchiert werden, um dessen Frequenzbereich in Erfahrung zu bringen. Die obere Grenze des Frequenzbereichs muss mindestens bis 7.000 Hz reichen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das zu testende Webangebot Zwei-Wege-Kommunikation ermöglicht. Dies umfasst z. B. webbasierte Sprach- und Videotelefonie.

2. Prüfung

1. Webangebot öffnen.

2. Wenn eine Funktion für die Zwei-Wege-Kommunikation geboten wird, prüfen, ob auch Textkommunikation in Echtzeit (RTT, Real-time Text) unterstützt wird.

3. Hinweise

Bei Echtzeit-Textkommunkation (RTT, Real-Time Text) erscheint der Text beim Empfänger dynamisch schon während der Eingabe des Senders. RTT ist also nicht das Gleiche wie etwa Chat, wo Nachrichten explizit abgeschickt werden und erst dann beim Empfänger erscheinen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Web-Anwendung Zwei-Wege-Kommunikation und zusätzlich Textkommunikation in Echtzeit ermöglicht. Zwei-Wege-Kommunikation umfasst u. a. Sprach- und Videotelefonie. Echtzeit bedeutet hier, dass schon die Eingabe einzelner Zeichen übertragen wird und der Nutzer den eingegebenen Text nicht erst aktiv abschicken muss.

2. Prüfung

1. Web-Anwendung öffnen

2. Prüfen, ob die gleichrangige Kommunikation via Echtzeit-Text und Sprache möglich ist und Funktionen wie das digitale Handheben ebenso Sprachnutzern wie Echtzeit-Text-Nutzern zur Verfügung stehen. Wenn es eine Warteschlange für Beiträge gibt, landen Sprachnutzer und Echtzeit-Text-Nutzer in der gleichen Schlange.

3. Hinweise

• Bei Echtzeit-Textkommunkation (RTT, Real-Time Text) erscheint der Text beim Empfänger dynamisch schon während der Eingabe des Senders. RTT ist also nicht das Gleiche wie etwa Chat, wo Nachrichten explizit abgeschickt werden und erst dann beim Empfänger erscheinen.

• Bei Konferenzen, also einer Kommunikation mit mehr als zwei Personen, soll die Echtzeit-Text-Kommunikation der Sprach-Kommunikation gleichgestellt sein. Das bedeutet z. B., dass wenn die Software Funktionen für die abwechselnde Kommunikation anbietet (z. B. immer nur ein aktiver Redner), sollen diese Funktionen auch für die Textkommunikation in Echtzeit verfügbar sein.

• Bei Konferenzen, die gleichzeitig eine herkömmliche Chat-Funktion bieten, sollen Chat und Echtzeit-Textkommunikation separiert werden,

  1. B. in separaten Programmfenstern, damit sich diese verschiedenen Kommunikationsarten nicht gegenseitig stören und nicht zu Verwirrung führen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Webangebot Echtzeit-Textkommunikation (RTT, Real-Time Text) senden und empfangen kann.

2. Prüfung

1. Webangebot öffnen

2. Prüfen, ob die Webangebot das Senden und Empfangen von Echtzeit-Textkommunikation anbietet

3. Prüfen, ob die gesendeten und empfangenen Textnachrichten deutlich voneinander unterscheidbar sind und separat angezeigt werden, z. B.:

   • Rahmen für Textnachricht (mit gutem Kontrast nach außen)

   • Positionierung der eigenen Nachrichten rechtsbündig und der Gesprächsteilnehmer linksbündig oder umgekehrt

   • Nennung des Namens vor Beginn der Nachricht

3. Hinweise

• Bei Echtzeit-Textkommunkation (RTT, Real-Time Text) erscheint der Text beim Empfänger dynamisch schon während der Eingabe des Senders. RTT ist also nicht das Gleiche wie etwa Chat, wo Nachrichten explizit abgeschickt werden und erst dann beim Empfänger erscheinen.

• Die Anforderung gilt streng genommen nur für Echtzeit-Textkommunikation, ist aber auch für die Unterscheidung von anderen Formen von Textkommunikation (etwa Text-Chats) wichtig.

• Wenn das Webangebot weitere Optionen für die Anzeige der Nachrichten anbietet, die gegebenenfalls nicht diesen Anforderungen entsprechen, soll dies nicht negativ bewertet werden. Andere Darstellungsweisen sind positiv, sie können bestimmte Nutzer-Bedürfnisse erfüllen. So kann die Fließtext-Darstellung von sowohl empfangenen als auch gesendeten Nachrichten in einem Textcontainer für Braille-Nutzer vorteilhaft sein.

• Die Unterscheidung der Nachrichten von verschiedenen Personen sollte nicht ausschließlich über eine unterschiedliche Textfarbe geschehen - vergleiche auch Abschnitt 4.2 Abgrenzung zu anderen Prüfschritten.

• Der Prüfschritt verlangt nur die Unterscheidung von gesendeten (auch Nutzersicht also eignen) und empfangenen Äußerungen, nicht die Unterscheidung verschiedener empfangener Äußerungen.

Abgrenzung zu anderen Prüfschritten

Wenn Nachrichten des Senders und des Empfängers nur über die Farbe des Textes unterschieden werden können und der Kontrastunterschied beider Arten von Nachricht unter 3:1 liegt, sind sowohl dieser Prüfschritt als auch Prüfschritt 1.4.1a "Ohne Farbe nutzbar" nicht erfüllt. Andere Anforderungen (etwa, dass der Text selbst oder auch der Rahmen oder andere grafische Elemente zur Unterscheidung kontrastreich genug sind) werden außerdem in den dafür zuständigen Prüfschritten bewertet.

Einordnung des Prüfschritts nach der EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Web-Anwendung Echtzeit-Textkommunikation (RTT, Real-Time Text) senden und empfangen kann.

2. Prüfung

3. Hinweise

• Bei Echtzeit-Textkommunkation (RTT, Real-Time Text) erscheint der Text beim Empfänger dynamisch schon während der Eingabe des Senders. RTT ist also nicht das Gleiche wie etwa Chat, wo Nachrichten explizit abgeschickt werden und erst dann beim Empfänger erscheinen.

• Die Anforderung verlangt streng genommen nur die Unterscheidung der Senderichtung, sie verlangt also nicht, dass empfangene Textnachrichten verschiedener Teilnehmer unterscheidbar sind. In der Praxis wird jedoch anzunehmen sein, dass bei allen Echtzeit-Textbeiträgen der jeweilige Sender über einen Namen bzw. Kürzel identifizierbar ist und somit auch empfangene Textnachrichten von verschiedenen Teilnehmenden unterscheidbar sind.

4. Bewertung

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Web-Anwendung Echtzeit-Textkommunikation (RTT, Real-time Text) unterstützt und den aktiven Sprecher über Sprache identifiziert. Der aktive Sprecher wird dabei in der Web-App markiert oder anderweitig hervorgehoben.

2. Prüfung

1. Web-Anwendung öffnen.

2. Prüfen, ob aktive Sprechende über Sprache identifiziert und in der Anwendung markiert oder anderweitig hervorgehoben werden.

3. Ist dies der Fall, prüfen, ob auch Teilnehmende, die Echtzeit-Texteingabe verwenden, beim Eingeben markiert oder anderweitig hervorgehoben werden.

3. Hinweise

Bei diesem Test muss eine Video- und Sprachverbindung mit mehreren Teilnehmenden etabliert werden, um eine eventuelle Markierung oder anderweitige Hervorhebung zweifelsfrei festzustellen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Web-Anwendung Zwei-Wege-Sprachkommunikation unterstützt und Funktionen zur Echtzeit-Textkommunikation bietet.

2. Prüfung

1. Web-Anwendung öffnen

2. Eine Verbindung mit einem weiteren Gerät über die Anwendung herstellen

3. Prüfen, ob beim Sprechen eine Signalisierung in Echtzeit erfolgt,

   1. B. über ein blinkendes Icon

4. Falls dies der Fall ist, mit Screenreader und Braillezeile prüfen, ob die Signalisierung programmatisch ermittelbar ist und auf der Braillezeile platzsparend über blinkende Braillemodule o. ä. dargestellt wird

3. Hinweise

• Bei Echtzeit-Textkommunkation (RTT, Real-Time Text) erscheint der Text beim Empfänger dynamisch schon während der Eingabe des Senders. RTT ist also nicht das Gleiche wie etwa Chat, wo Nachrichten explizit abgeschickt werden und erst dann beim Empfänger erscheinen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Web-Anwendung (zusätzlich zur Sprachkommunikation) Echtzeit-Textkommunikation unterstützt und potentiell mit anderer Kommunikations-Software mit solcher Unterstützung kommunizieren kann.

2. Prüfung

Die Dokumentation der Web-Anwendung oder den Anbieter der Web-Anwendung konsultieren. Werden (je nach technischer Umsetzung) die jeweils anwendbaren aktuellen technischen Standards für Echtzeit-Textkommunikation unterstützt?

3. Hinweise

• Bei Echtzeit-Textkommunkation (RTT, Real-Time Text) erscheint der Text beim Empfänger dynamisch schon während der Eingabe des Senders. RTT ist also nicht das Gleiche wie etwa Chat, wo Nachrichten explizit abgeschickt werden und erst dann beim Empfänger erscheinen.

• Bei der Beurteilung der Standards-Unterstützung muss die aktuelle Entwicklung der Standards berücksichtigt werden. Ggf. sind mittlerweile neuere Standards für die Kommunikationsmethode gängig.

EN 301 549 V3.2.1 nennt folgende je nach technischer Umsetzung anwendbare Standards:

• Die Web-Anwendung kommuniziert über das öffentliche Telefonnetz: Die Empfehlungen ITU-T V.18 [i.23] oder dessen Text-Telefonie-Standards in den Anhängen werden für die Echtzeit-Textkommunikation verwendet.

• Voice over IP (VoIP) über das Session Initiation Protocol (SIP): Empfehlungen der IETF zu Echtzeit-Textkommunikation RFC 4103 [i.13] werden verwendet.

• Die Web-Anwendung nutzt Voice over IP (VoIP) über das IP Multimedia Sub-System (IMS): Hier sind die Protokolle ETSI TS 126 114 [i.10], ETSI TS 122 173 [i.11] und ETSI TS 134 229 [i.12] relevant.

• Wenn andere Kommunikationsmethoden verwendet werden: Gemeinsame, relevante und veröffentlichte Standards werden unterstützt. Dabei unterstützt der gemeinsame Standard die Anzeige von verlorenen und fehlerhaft übertragenen Zeichen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das Webangebot Eingaben für Echtzeit-Textkommunikation unterstützt. Das ist z.B. der Fall, wenn es sich um eine Anwendung zur Kommunikation handelt, die Echtzeit-Textkommunikation unterstützt und in der Benutzerschnittstelle eine entsprechende Eingabemöglichkeit bereithält.

2. Prüfung

Für diesen Prüfschritt existieren bislang nur Ansätze für die Prüfung in der Praxis. Eigentlich müsste gemessen werden, wann die Daten, direkt nach der Eingabe, von der Anwendung abgeschickt werden. Zwischenzeitlich kann man testen, indem eine Echtzeit-Textkommunikation zwischen zwei Geräten hergestellt wird.

Die kleinste Texteinheit (einzelne Zeichen oder Wörter) sollte dabei möglichst unmittelbar nach der Eingabe auf dem zweiten Gerät erscheinen.

Die Übertragung sollte nicht mehr als eine halbe Sekunde dauern. Physikalische Grenzen durch die Netzwerktechnik müssen dabei berücksichtigt und abgezogen werden. Dies wird z. B. bei weiten Entfernungen der Kommunikationspartner relevant. Die reine Übertragungszeit kann z. B. mit einem “Ping” gemessen werden.

3. Hinweise

• Bei Echtzeit-Textkommunkation (RTT, Real-Time Text) erscheint der Text beim Empfänger dynamisch schon während der Eingabe des Senders. RTT ist also nicht das Gleiche wie etwa Chat, wo Nachrichten explizit abgeschickt werden und erst dann beim Empfänger erscheinen.

• Es sollte eine maximale Verzögerung von 300 Millisekunden für das Abschicken der Eingabe angestrebt werden, da dies den wahrgenommenen Informationsfluss verbessert.

Für Hinweise, wie dies zuverlässig in der Praxis gemessen werden kann, können Sie auf GitHub ein Issue eröffnen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Web-Anwendung Telekommunikationsfunktionen mit Anrufidentifizierung bietet. Anrufidentifizierung bedeutet hier die Signalisierung bzw. Anzeige des Anrufenden.

2. Prüfung

Für die Prüfung muss die Web-Anwendung ggf. auf zwei Geräten geöffnet werden.

1. Screenreader starten

2. Web-Anwendung öffnen

3. Anruf von einem zweiten Gerät tätigen

4. Prüfen, wie der Anruf in Zusammenhang mit dem aktiviertem Screenreader signalisiert wird. Wird der Anrufende automatisch angesagt oder sind die Informationen über den Anrufenden im Browser für den Screenreader ohne Umwege auslesbar?

5. Prüfen, wie der Anruf visuell signalisiert bzw. angezeigt wird. Die Anzeige muss den Anrufenden in irgend einer Weise in Textform identifizieren,

   1. B. über die Telefonnummer oder über den für die Nummer hintelegten Namen des Anrufers.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das Webangebot Echtzeit-Sprachkommunikation mit Voicemail-Funktion oder interaktive Sprachdialogsysteme (z.B. sprachgesteuerte Menüführung bei einer Hotline) einsezt.

2. Prüfung

Wenn Informationen über Echtzeit-Sprachkommunikation bereitgestellt werden, prüfen, ob diese auch ohne Sprach- und Hör-Fähigkeit zugänglich ist. Dies beinhaltet:

• eine alternative Zugangsmöglichkeit, z.B. über barrierefreie Menüs oder Formulare

• eine alternative barrierefreie Ausgabe der Information, etwa als sichtbarer programmatisch ermittelbarer Text

3. Hinweise

Ein Beispiel für einen Dienst, der Sprach und Hörfähigkeiten voraussetzt, ist z.B. das Video-Ident-Verfahren. Dieses wird u. a. bei Online-Banken für die Identifizierung genutzt. Mit einem Videoanruf werden dabei Personalausweis etc. auf Echtheit geprüft. Hier muss eine Alternative geboten werden, die das Hören und Sprechen nicht erfordert.

Ein anderes Beispiel ist telefonische Ansage des Guthabens bei einem Prepaid-Mobilfunkvertrag. Hier müsste der Anbieter das aktuelle Guthaben in Textform auf der Seite bereitstellen.

Für Hinweise zu diesem Prüfschritt können Sie auf GitHub ein Issue anlegen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Web-App Videotelefonie unterstützt.

2. Prüfung

1. Die technische Dokumentation der Web-App konsultieren. Wird mindestens eine QVGA (320x240 Pixel) angegeben?

2. Testübertragung: Den visuellen Eindruck prüfen. Ist die Angabe in der App-Dokumentation plausibel?

3. Hinweise

Für Hinweise zu diesem Prüfschritt eröffnen Sie gerne ein Issue auf GitHub.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das Web-Angebot Videotelefonie unterstützt.

2. Prüfung

Zur Beurteilung der Konformität mit diesem Prüfschritt müssen derzeit die Angaben des Software-Herstellers mit den eigenen visuellen Eindrücken abgeglichen werden. Für die Prüfung muss das Web-Angebot auf zwei Geräten geöffnet werden.

1. Die unterstützte Bildwiederholfrequenz der Dokumentation des Web-Angebots entnehmen oder vom Hersteller erfragen. Werden mindestens 20 Bilder pro Sekunde unterstützt?

2. Web-Angebot auf zwei Geräten öffnen

3. Videotelefonieverbindung zwischen den Geräten herstellen

4. Prüfen, ob das Bild flüssig dargestellt wird. Scheint die Angabe des Herstellers über die Bildwiederholfrequenz plausibel?

3. Hinweise

Für die Videotelefonie ist eine Bildwiederholfrequenz von 30 Bildern pro Sekunde empfehlenswert, um eine flüssige Darstellung des Bildes zu gewährleisten.

Eine genaue Methode zur Messung der unterstützten Bildwiederholfrequenz ist noch offen. Hinweise zur Weiterentwicklung des Prüfschritts können Sie auf GitHub in einem Issue hinterlassen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das Webangebot Videotelefonie mit Sprachübertragung unterstützt.

2. Prüfung

Die Zeitdifferenz zwischen Audio und Video bei der Übertragung von Videotelefonie soll nicht mehr als 100 Millisekunden betragen, deutlich wahrnehmbare Differenzen sind also zu vermeiden.

Die zeitgleiche Übertragung von Ton und Bild (bzw. eine Asynchronität, das bedeutet Bild und Ton werden nicht gleichzeitig übertragen) kann mit einem Testvideoanruf geprüft werden. Dafür muss das Webangebot auf zwei verschiedenen Testgeräten im Browser laufen.

1. Webangebot auf zwei Geräten im Browser aufrufen

2. Videotelefonieverbindung zwischen beiden Angeboten herstellen

3. Synchronität zwischen Sprache und Video prüfen (Lippensynchronität). Ist eine Zeitdifferenz deutlich wahrnehmbar?

Um ein belastbares Ergebnis zu erzielen, sollte die Testübertragung wiederholt werden.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das Webangebot Videotelefonie mit Sprachübertragung unterstützt.

Prüfung

1. Webangebot auf zwei verschiedenen Geräten im Browser mit abweichenden Nutzenden-Konten starten.

2. Videotelefonie-Verbindung zwischen den beiden Instanzen des Webangebots herstellen.

3. Auf dem verbundenen Gerät Sprache eingeben und auf dem Prüfgerät überprüfen, ob die Spracheingabe visuell wahrnehmbar ist.

Hinweise

Für den Indikator der Sprachaktivität gelten weitere Anforderungen, z.B. bezüglich Grafik-Kontrast.

Der visuelle Indikator der Audio-Aktivität kann ein einfacher visueller Punkt, eine LED oder eine andere Art von Ein- / Aus-Anzeige sein, die flackert.

Für Hinweise zu diesem Prüfschritt können Sie auf GitHub ein Issue anlegen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn ein Webangebot Videotelefonie unterstützt und eine Anzeige der Sprechaktivität von Sprechenden bietet.

2. Prüfung

1. Webangebot auf zwei Geräten im Browser mit abweichenden Nutzenden-Konten starten.

2. Videotelefonie-Verbindung zwischen den beiden Instanzen des Webangebots herstellen.

3. Auf dem verbundenen Gerät die Eingabe von Gebärden starten.

4. Prüfen,

   • ob das Webangebot die Möglichkeit bietet, den Start einer Gebärden-Eingabe manuell zu signalisieren (d.h. die Anzeige des Aktivitätszustandes zu aktivieren) oder

   • die Eingabe vom Webangebot automatisch erkannt und in der Folge der Aktivitäts-Zustand automatisch gesetzt wird.

5. Prüfen, ob die Aktivität der Gebärden-Eingabe wahrnehmbar ist.

3. Hinweise

• Es spielt für die Überprüfung vermutlich keine Rolle, ob die Eingabe von Gebärdensprachen-Kundigen vorgenommen wird oder nur ähnliche Bewegungen gemacht werden, eine Eingabe also nur simuliert wird.

• Für den Indikator der Aktivität von Gebärdenden gelten weitere Anforderungen, z.B. bezüglich Grafik-Kontrast.

Für Hinweise zu diesem Prüfschritt können Sie auf GitHub ein Issue anlegen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

• Der Prüfschritt ist anwendbar, wenn die Webseite aufgezeichnete Videos mit synchroner Bild- und Tonspur anbietet und Untertitel vorhanden sind. Zuschaltbare Untertitel sind in der Regel innerhalb des video-Elements als getrennte track-Datei verfügbar.

• Aufgezeichnete Videos ohne Tonspur (stumme Videos) brauchen keine Untertitelung, der Prüfschritt ist für sie nicht anwendbar.

2. Prüfung

1. Text-Dateien für Untertitelungen werden meist über das HTML 5 track-Element eingebunden. Im Quellcode prüfen, ob über das track-Element eine Untertitel-Datei eingebunden ist. Das kind-Attribut legt die Art der Texteinblendung fest. Der Wert subtitles zeigt an, dass es sich um Untertitel handelt (Transkription oder Übersetzung des Dialogs). Der Wert captions zeigt an, dass es sich um Untertitel für hörgeschädigte und gehörlose Menschen handelt.

2. Manche Player binden Untertitel-Dateien auch außerhalb des video-Elements ein.

3. Wenn eine Untertitel-Datei eingebunden ist, prüfen, ob der Videoplayer eine Möglichkeit bietet, diese ein- und auszublenden.

3. Hinweise

• Empfehlenswert wäre, wenn der Videoplayer eine Funktion zur Verfügung stellt, um die Untertitel auf einer Braillezeile anzuzeigen.

• Nicht negativ bewertet wird, wenn ein alternatives Video mit open captions bei Aktivierung eines Bedienelements im Player neu geladen wird, oder wenn das Video mit open captions über einen zweiten Player angezeigt wird.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

Bei diesem Prüfschritt geht es um den eigentlichen Prozess der Anzeige von Untertiteln während der Wiedergabe sowie um die Bedienelemente zum Ein- und Ausschalten von Untertiteln im Videoplayer.

9.1.2.2 "Aufgezeichnete Videos mit Untertiteln" bezieht sich hingegen auf den Inhalt der Untertitel. Es geht darum, dass der Autor bei der Erstellung der Untertitel sicherstellen muss, dass Audioinhalt korrekt transkribiert wurde und in einem Format erfasst werden, das für die Bereitstellung synchronisierter Untertitel verwendet werden kann.

Anforderungen der Video-Bedienelemente bezüglich Kontrast, zugänglichem Namen, Tastaturbedienbarkeit, Fokushervorhebung usw. werden in den entsprechenden Prüfschritten geprüft.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn auf der Webseite aufgezeichnete Videos mit synchroner Bild- und Tonspur sowie zuschaltbare Untertitel (closed captions) vorhanden sind.

2. Prüfung

3. Hinweise

Wenn Fehler in der Zeitcodierung der Track-Datei gefunden werden, ist davon auszugehen, dass der Fehler nicht beim Player liegt. Es ist es jedoch nicht ganz auszuschließen, dass eine nicht vorhandene Synchronität an der Untertitel-Datei und am Player liegt.

Es ist sinnvoll, stichprobenartig zu prüfen, ob es im Webangebot Videos gibt, bei denen die Untertitel synchron zum Ton dargestellt werden. Wenn dies der Fall ist, ist das ein Hinweis, dass der Player Untertitel prinzipiell korrekt darstellt. Der Prüfschritt ist damit erfüllt, Probleme mit der Synchronität sind dann höchstwahrscheinlich bei den Inhalten zu suchen und nicht im eingebundenen Player.

Hinweise zu diesem Prüfschritt können Sie auf GitHub in einem Issue hinterlassen.

4. Bewertungen

Abgrenzung zu anderen Prüfschritten

Inhalte, Qualität und Angemessenheit der Untertitel werden in Prüfschritt 9.1.2.2 "Aufgezeichnete Videos mit Untertiteln" geprüft. In diesem Prüfschritt wird geprüft, ob der eingebundene Player grundsätzlich in der Lage ist, Videos mit Untertiteln synchron darzustellen.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das Webangebot Videos mit Untertiteln übertragen, konvertieren oder aufnehmen kann.

2. Prüfung

Wenn die Webseite Videos mit Untertiteln konvertiert oder aufnimmt, Video anschließend in einem konformen Player abspielen:

• Sind alle Untertitel aus der Quelle weiterhin vorhanden?

• Lassen sich alle Untertitel anzeigen?

• Ist die Darstellung der Untertitel weiterhin synchron zum Ton?

3. Hinweise

Wenn gestalterische Aspekte der Untertitel (z. B. Position, Farbe, Fettung oder kursive Darstellung) informationstragend sind, sollten sie nach Möglichkeit erhalten bleiben.

Hinweise zu diesem Prüfschritt können Sie auf GitHub in einem Issue hinterlassen.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

In diesem Prüfschritt wird geprüft, ob es durch die Übertragung, Konvertierung oder Aufnahme zu Problemen hinsichtlich der Anzeige oder Synchronität von Untertiteln kommt. In den Prüfschritten 7.1.1 "Wiedergabe von Untertiteln" und 7.1.2 "Synchrone Untertitel" geht es hingegen um Videos, die auf der Webseite bereits vorhanden sind.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das Webangebot Videos mit Untertiteln enthält und sich die Untertitel zuschalten lassen (closed captions). Auf permanent sichtbare Untertitel, die Teil des Videobildes sind (open captions), ist der Prüfschritt nicht anwendbar.

2. Prüfung

1. Webangebot öffnen.

2. Video mit Untertitelung abspielen.

3. Falls es sich um zuschaltbare Untertitel handelt: Prüfen, ob es Einstellungsmöglichkeiten für die Darstellung der Untertitel gibt, etwa, um Schriftgröße, Schriftart (Font), Vorder- und Hintergrundfarbe, oder Transparenz des Untertitel-Bereichs anpassen zu können.

Hinweise zu diesem Prüfschritt können Sie auf GitHub in einem Issue hinterlassen.

3. Hinweise

• Art und Umfang der Anpassungsmöglichkeiten sind nicht normativ festgelegt. Die Norm nennt beispielhaft Hinter- und Vordergrundfarbe der Untertitel, Schriftart, Größe, Transparenz des Untertitel-Bereichs und Kontur der Schrift.

• Der Prüfschritt ist auch erfüllt, wenn sich die Darstellung der Untertitel nicht über Einstellungen des Video-Players, sondern durch browserseitige oder systemseitige Einstellungen anpassen lässt (wenn also etwa die Vergrößerung der Schriftgröße oder angepasste Farb-Schemata in den Browser-Einstellungen sich auf die Darstellung der Untertitel auswirken).

4. Bewertung

Einordnung des Prüfschritts nach EN 301 549 v.3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar:

• wenn der Original-Ton des Videos fremdsprachig ist (d.h. er entspricht nicht der Hauptsprache des Webauftritts)

• und Untertitel in der Hauptsprache des Webauftritts bereitgestellt werden

• und wenn es keine Version des Videos mit einer Tonspur in der Hauptsprache des Webauftritts gibt.

2. Prüfung

1. Webangebot öffnen.

2. Prüfen, ob der Originalton des Videos von der Hauptsprache des Webangebots abweicht.

3. Prüfen, ob für Videos mit fremdsprachiger Tonspur Untertitel in der Hauptsprache des Webangebots angeboten werden.

4. Prüfen, ob sich eine alternative Tonspur in der Hauptsprache des Angebots oder eine generierte Sprachausgabe der Untertitel aktivieren lässt.

3. Hinweise

• Gängige Video-Player verfügen derzeit meist nicht über die Möglichkeit einer einschaltbaren Sprachausgabe der Untertitel.

• Für blinde oder sehbehinderte Menschen, die den fremdsprachigen Originalton eines Videos nicht verstehen, sollen Untertitel in der Hauptsprache der Webseite als akustische Ausgabe zugänglich sein. Ist der Original-Ton des Videos bereits in der Hauptsprache, so gelten Untertitel in anderen Sprachen als zusätzliche Informationen und sind daher nicht von der Anforderung betroffen.

Hinweise zu diesem Prüfschritt können Sie auf GitHub in einem Issue anlegen.

4. Bewertung

Einordnung des Prüfschritts nach EN 301 549 v.3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn auf der Webseite ein oder mehrere aufgezeichnete Videos mit synchroner Bild- und Tonspur vorhanden sind und für diese Videos Alternativen mit Audiodeskription bereitstehen.

2. Prüfung

1. Das Video wird im auf der Website eingebundenen Player abgespielt.

2. Prüfen, ob der Player ein Bedienelement anbietet, dass das Ein- und Ausschalten von Audiodeskription ermöglicht.

3. Sollte es keine Schaltfläche für Audiodeskription geben, prüfen, ob aus einer von mehreren Tonspuren Audiodeskription ausgewählt werden kann.

3. Hinweise

• Weder das Laden eines zweiten Videos mit Audiodeskription (bei Aktivierung eines AD-Buttons), noch die Bereitstellung von Audiodeskription mit Hilfe eines zweiten Videos über einen zweiten Player wird negativ bewertet.

• Wenn alle wichtigen Informationen der Bildsequenz bereits über die Audiospur vermittelt werden, ist keine Audiodeskription und damit auch kein AD-Button erforderlich.

• Die Anforderung 7.2.1 erlaubt zwar die Auswahl der Audiodeskription aus einer von mehreren Tonspuren. Anforderung 7.3 verlangt jedoch, dass sich die Bedienelemente zur Aktivierung der Audiodeskription auf der gleichen Interaktionsebene wie die Bedienelemente zur Wiedergabekontrolle (z.B. Abspielen, Pause, Lautstärke etc.) befinden.

• Wenn 7.3 "Bedienelemente für Untertitel und Audiodeskription" erfüllt ist, ist 7.2.1 "Wiedergabe von Audiodeskription" (dieser Prüfschritt) ebenfalls erfüllt.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

Dieser Prüfschritt fordert, dass in Fällen, wo für Videos Versionen mit Audiodeskription bereit gestellt werden, Bedienelemente zum Ein- und Ausschalten der Audiodeskription angeboten werden. In Prüfschritt 9.1.2.5 "Audiodeskription für Videos" wird hingegen geprüft, ob für Inhalte eines Videos, die nur über Bilder vermittelt werden, eine Audiodeskription vorhanden ist. Es geht dort um die inhaltliche Beurteilung.

Wird 9.1.2.5 negativ bewertet (eine notwendige Audiodeskription ist nicht vorhanden), ist dieser Prüfschritt nicht anwendbar. 7.2.1 ist nur anwendbar, wenn eine Audiodeskription angeboten wird.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn auf der Webseite Videos mit synchroner Bild- und Tonspur sowie einer zusätzlich eingebundenen Tonspur für Audiodeskription vorhanden sind. Eine Alternative wäre die Verwendung des track-Elements mit kind="description", eine im video-Element eingebundene Textdatei, aus der ggf. eine Audio-Ausgabe synthetisiert wird. Wenn also ein Player bei der Auswahl einer angebotenen 'Version mit Audiodeskription' eine andere Videodatei mit erweitertem Ton lädt, ist der Prüfschritt nicht anwendbar, denn eine festgestellte mangelnde Synchronität läge dann in jedem Fall an der eingebundenen Video-Datei, nicht am Player.

2. Prüfung

1. Das Video mit zugeschalteter Audiodeskription in dem auf der Webseite eingebundenen Player abspielen.

2. Prüfen, ob die Audiodeskription synchron zu Bild und Ton wiedergegeben wird.

3. Falls die Audiodeskription nicht synchron läuft: Mittels Web Developer Tools prüfen, ob beim Abspielen der Versionen mit und ohne Audiodeskription unterschiedliche Quell-Dateien genutzt werden. Das src-Attribut des video-Elements hat in diesem Fall abweichende Pfade, etwa ../video-name.mp4 und ../video-name-AD.mp4. Ist das der Fall, ist die Audiodeskription mit großer Wahrscheinlichkeit integrierter Teil der Video-Tonspur. Mangelnde Synchronität liegt in diesem Fall nicht am Player, der Prüfschritt ist erfüllt. Wahrscheinlich muss dann aber Prüfschritt 9.1.2.5 "Audiodeskription für Videos" negativ bewertet werden!

4. Falls der Dateipfad des Videos nach Zuschalten der Audiodeskription gleich bleibt, ist bei mangelnder Synchronität entweder der Player fehlerhalft oder es liegt an einer fehlerhaften Umsetzung der Audiodeskription. Die Ursache kann derzeit nur vom Web-Autor geprüft werden.

3. Hinweise

Wenn zugeschaltete Audiodeskription nicht synchron läuft und im Angebot andere Videos mit zuschaltbarer Audiodeskription vorhanden sind, dort prüfen, ob ebenfalls Mängel bei der Synchronität bestehen. Ist die zugeschaltete Audiodeskription bei anderen Videos synchron, deutet dies darauf hin, d ass das Problem nicht beim Player, sondern beim spezifischen Video oder Audiodeskriptions-Dateien liegt. Der Prüfschritt wäre dann erfüllt.

Hinweise zu diesem Prüfschritt können Sie auf GitHub in einem Issue hinterlassen.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

In diesem Prüfschritt wird geprüft, ob der Videoplayer Audiodeskription synchron anzeigt. In Prüfschritt 9.1.2.5 "Audiodeskription für Videos" erfolgt hingegen die inhaltliche Prüfung der Audiodeskription. Die Prüfung, ob der Player oder die Umsetzung der Audiodeskription fehlerhaft ist, kann derzeit nicht erfolgen. Wird Audiodeskription nicht synchron dargestellt, erfolgt in beiden Prüfschritten eine negative Bewertung mit dem Hinweis auf eine unklare Ursache.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das Webangebot Videos mit Audiodeskription übertragen, konvertieren oder aufnehmen kann.

2. Prüfung

Wenn das Webangebot Videos mit Audiodeskription konvertiert oder aufnimmt, das Video anschließend in einem konformen Player abspielen:

• Ist Audiodeskription aus der Quelle weiterhin vorhanden?

• Lässt sich Audiodeskription abspielen?

• Ist die Audiodeskription weiterhin synchron zu Bild und Ton?

3. Hinweise

Hinweise zu diesem Prüfschritt können Sie auf GitHub in einem Issue hinterlassen.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

In diesem Prüfschritt wird geprüft, ob es durch die Übertragung, Konvertierung oder Aufnahme zu Problemen hinsichtlich der Ausgabe oder Synchronität von Audiodeskription kommt. In den Prüfschritten 7.2.1 "Wiedergabe von Audiodeskription" und 7.2.2 "Synchrone Audiodeskription" geht es hingegen um Videos, die auf der Webseite bereits vorhanden sind.

Einordnung des Prüfschritts nach EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn auf der Webseite ein Videoplayer mit Entwickler-definierten Bedienelementen eingebunden ist, der Video-Inhalte mit zugehörigen Audioinhalten abspielt und wenn Untertitel und / oder Audiodeskription angeboten werden. Der Prüfschritt ist nicht anwendbar, wenn bei Verwendung nativer Video-Player über das `video`Element die Bedienelemente vom Browser bereitgestellt werden und somit vom Entwickler nicht zu beeinflussen sind.

2. Prüfung

1. Das Video mit dem auf der Website eingebundenen Player abspielen.

2. Prüfen, ob Bedienelemente zur Anzeige von Untertiteln und / oder Audiodeskription auf gleicher Ebene wie die Bedienelemente zur Wiedergabekontrolle (z. B. Abspielen, Pause, Lautstärke etc.) angeboten werden.

3. Hinweise

Wenn 7.3 Bedienelemente für Untertitel und Audiodeskription (dieser Prüfschritt) erfüllt ist, ist 7.1.1 "Wiedergabe von Untertiteln" und 7.2.1 "Wiedergabe von Audiodeskription" ebenfalls erfüllt.

Für Hinweise zu diesem Prüfschritt können Sie auf GitHub ein Issue anlegen.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

Bei diesem Prüfschritt geht es darum, wo die Bedienelemente für Untertitel und Audiodeskription positioniert sind. In Prüfschritt 7.2.1 "Wiedergabe von Audiodeskription" geht es darum, dass überhaupt entsprechende Bedienelemente vorhanden sind.

Einordnung des Prüfschritts nach EN 301 549 V3.1.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn Grafiken, Icon Fonts oder SVGs als Bedienelemente (Menüs, Logos, Teaserbilder oder Schaltflächen) eingesetzt werden.

2. Prüfung

3. Hinweise

4. Bewertung

Anleitungen zum Erstellen guter Alternativtexte

• W3C Web Accessibility Tutorials: Images Concepts

• WebAIM: Alternative Text

• HTML 5.1 Spezifikation: Requirements for providing text to act as an alternative for images

W3C - Scalable Vector Graphics (SVG) 1.1

• The 'desc' and the 'title' elements

• Zu Rollen wie role="graphics-document" für komplexere SVG-Grafiken: WAI-ARIA Graphics Module (W3C Recommendation 02 October 2018)

SVGs zugänglich einbinden

• Contextually marking up accessible images and SVGs (Scott O’Hara, May 2019)

• Creating accessible SVGs (Deque blog, January 2019)

• 7 solutions for creating more accessible SVGs (SimplyAccessible, March 2017)

• Accessible SVGs (CSS-Tricks, updated August 2016)

Abgrenzung zu anderen Prüfschritten

Verlinkte Grafiken sind stets in diesem Prüfschritt zu bewerten. Das gilt auch dann, wenn die Grafiken neben der Information über das Linkziel auch noch eine andere Information vermitteln sollen, wie zum Beispiel auf die Startseite verlinkte Logos.

Einzige Ausnahme: Grafik und danebenstehender Text sind ein zusammengehöriger Link. Der Alternativtext bezieht sich dann nur auf die Grafik, die Prüfkriterien 9.1.1.1b "Alternativtexte für Grafiken und Objekte" oder 9.1.1.1c "Leere alt-Attribute für Layoutgrafiken" sind anzuwenden.

• Alternativtexte für grafische Überschriften: siehe Prüfschritt 9.1.1.1b "Alternativtexte für Grafiken und Objekte".

• CAPTCHAs werden im Prüfschritt 9.1.1.1d "Alternativen für CAPTCHAs" geprüft.

• Textäquivalent (title-Attribut) für Frames: siehe Prüfschritt 9.2.4.1 "Bereiche überspringbar".

• Linktexte sind auch in Prüfschritt 9.2.4.4 "Aussagekräftige Linktexte" Thema. Dort geht es um die allgemeine Aussagekraft, in diesem Prüfschritt 9.1.1.1a geht es dagegen nur um die Gleichwertigkeit von Alternativtext und grafischem Link.

• Die Ausgabe der entsprechenden Rolle von SVGs wird im Prüfschritt 9.4.1.2 "Name, Rolle, Wert verfügbar" geprüft (s. o3.2 Unterstützung von SVGs durch assistive Technologien).

Einordnung des Prüfschritts nach WCAG 2.2

Kann das alt-Attribut nicht leer gelassen werden, wenn stattdessen ein sinnvolles title-Attribut verwendet wird? Das wird in meinem Screenreader problemlos ausgegeben.

Es stimmt, dass neuere Screenreader bei Vorhandensein eines title-Attributs dieses anstelle eines fehlenden alt-Attributs ausgeben. Das trifft aber nicht auf alle gängigen Hilfsmittel zu. Deshalb verlangt der Test grundsätzlich die standardkonforme Umsetzung gemäß HTML 5.0 und WCAG 2.0:

• Das alt-Attribut soll den Inhalt des Bildes ersetzen

• Das title-Attribut ist für zusätzliche (nicht essenzielle) Informationen gedacht

Deshalb steht in der WCAG 2.0-Technik H33:

Ein weiterer Punkt, der die Wichtigkeit des alt-Attributs unterstreicht, ist die Nutzung mit abgeschalteten Bildern. Auch wenn Alternativtexte im Bereich der Bildumrisse in manchen Browsern nicht vollständig angezeigt werden, ist das immer noch besser als eine Nicht-Anzeige beim Einsatz von title.

Der Alternativtext beschreibt die Grafik, der title-Text beschreibt das Link-Ziel: Ist das ein geeigneter Lösungsansatz für grafische Links?

Vorgeschlagen wurde diese Lösung für Fälle, in denen die Grafik nicht einfach das Linkziel abbildet (Schriftgrafik) oder für das Linkziel steht, sondern zusätzlich eine eigenständige Aussagekraft hat (zum Beispiel bei aus Anreißertext und einer verlinkten Abbildung bestehenden Teasern).

Die Idee ist einleuchtend:

Der sehende Benutzer klickt auf das Bild, denn er vermutet, dass hinter dem Bild eine Seite steht. Der beschreibende Alternativtext ersetzt das Bild, der blinde Benutzer schließt wie der sehende Benutzer vom (beschriebenen) Bildinhalt auf das Linkziel. Wenn aus dem Bild / der Bildbeschreibung nicht hinreichend klar hervorgeht, wo es hinführt, kann der sehende wie der blinde Benutzer auf die ergänzenden Informationen im title-Attribut zugreifen.

In der Praxis funktioniert das aber nicht:

Sehende Benutzer orientieren sich nicht an den Inhalten des Bildes, sondern eher an der Position. Viele Teaser-Bilder sind vom Inhalt her ohnehin nicht geeignet, etwas über das Linkziel zu sagen, der Bezug zum Thema des Linkziels ist oft nur ansatzweise nachvollziehbar. Aber sie müssen auch gar nichts über das Linkziel sagen: Das Linkziel steht im Text daneben, es muss nicht aus dem Bild erraten werden. Geklickt wird auf das Bild, weil es vielleicht leichter zu treffen ist und der Benutzer weiß, dass Teaser-Bilder üblicherweise mit weiterführenden Informationen zum jeweiligen Textabschnitt verlinkt sind.

Für den blinden Benutzer ist der Zusammenhang von Bild und (darauf folgendem) Kontext dagegen normalerweise nicht klar. Er müsste also tatsächlich Vermutungen anstellen, wo ein Link hinführen könnte, der mit dem beschriebenen Bild verbunden ist. Und da das Bild die entsprechende Aussagekraft nicht hat, wäre er auf die Informationen im title-Attribut in der Regel angewiesen. Sie sind also für ihn nicht ergänzend.

Hinzu kommt: Das title-Attribut wird von gängigen Screenreadern unterschiedlich behandelt und schlecht unterstützt. Nach wie vor werden von JAWS die Inhalte von alt-Attribut und title-Attribut nur alternativ vorgelesen.

Das title-Attribut ist für ergänzende Informationen vorgesehen. Die Information über das Linkziel ist in aller Regel keine ergänzende Information, denn sie geht aus dem Bildinhalt nicht hervor. Der Alternativtext muss daher das Linkziel beschreiben.

Sollte im alt-Attribut und im title-Attribut eines Bildes derselbe Inhalt stehen?

Der Alternativtext soll das Bild ersetzen. Sehr häufig bedeutet das: Der Alternativtext sagt, was abgebildet ist.

Das title-Attribut ist dagegen für ergänzende Informationen zum Bild vorgesehen. Es kann zum Beispiel verwendet werden, um zu sagen, von welcher Quelle das Bild stammt. Dort stehen also Informationen, die man dem Bild nicht entnehmen kann.

Eigentlich also ein klarer Fall: Die Aufgaben der Attribute sind unterschiedlich, entsprechend sollten sie normalerweise nicht denselben Inhalt haben. Es gibt aber eine wichtige Ausnahme:

Häufig werden Symbole oder Zeichen als Bedienelemente verwendet. Für sehende Nutzende ist dann eine ergänzende Beschriftung nützlich. Sie steht am besten als Text neben dem Bild, denn dann ist sie auch für Tastaturnutzer sichtbar. Aber auch das title-Attribut kann verwendet werden. Dann sollte im title -Attribut möglichst exakt der gleiche Text stehen wie im zugänglichen Namen, der über das alt-Attribut (oder auch über aria-label) gesetzt ist. Der Grund: Sind die Werte identisch, wird dieser Text von Screenreadern in der Regel nur einmal ausgegeben. Weicht er ab, erfolgt eine Ausgabe beider Werte, was oft zu unnötigen Doppelungen führt.

Screenreader geben oft den Dateinamen der Bilddatei aus, wenn kein Alternativtext zur Verfügung steht. Kann so das Fehlen des Alternativtextes kompensiert werden?

Nein, denn die Ausgabe des Dateinamens funktioniert nicht verlässlich. Nicht alle Browser oder Screenreader geben den Dateinamen aus. Von manchen wird der ganze Pfad der Bilddatei ausgegeben. Das ist schwer verständlich.

Soll im Alternativtext stehen, dass es sich um ein Navigationselement handelt?

Nein, das sollte vermieden werden. Screenreader oder Textbrowser geben in der Regel die Rolle des Elements aus, also etwa "Link" oder "Taste". Wenn diese Rolle im Alternativtext steht, liefert der Screenreader diese Information doppelt.

Was ist ein passender Alternativtext für verlinkte Bilder, etwa Fotos?

Wenn Bilder verlinkt sind, soll der Alternativtext vor allem das Linkziel nennen. Oft geschieht dies im Zusammenhang von Teasern, die gleichzeitig Überschriften, Anreißertext und/oder "Weiter" oder "Mehr lesen"- Links enthalten. Hier eignet sich oft die Überschrift als Linktext. Ist der gesamte Teaser verlinkt, sollte der Alternativtext des Bildes leer sein, um Doppelungen zu vermeiden. Ist das Bild für sich genommen informationstragend, sollte es einen aussagekräftigen Alternativtext haben. Es bietet sich dann an, das Bild nicht in den Teaser-Link einzuschließen. Techniken wie das Cards-Pattern zeigen, wie das Bild dennoch zum Teil der Klick-Fläche gemacht werden kann.

Sollte der Alternativtext für grafische Bedienelemente (Icons) auch sagen, was abgebildet ist?

Symbole haben meist konventionelle Bedeutung. So steht eine Lupe für die Funktion 'Suchen', eine Diskette (immer noch) für die Funktion 'Sichern', ein Fragezeichen für 'Hilfe', ein Stift für 'Editieren'. In solchen Fällen soll der Alternativtext des Icons die Funktion bezeichnen und nicht den abgebildeten Gegenstand.

Links oben ist das Firmenlogo abgebildet, es ist außerdem mit der Startseite verlinkt. Welcher Alternativtext ist angemessen?

Der Alternativtext in diesem Fall hat zwei Aufgaben: Er soll für das Logo stehen und er soll das Linkziel vertreten. Auf dieser Grundlage kann man verschieden argumentieren:

1. Das Bild zeigt das Logo der Firma. Das ist auch seine vorrangige Aufgabe. Auch für einen blinden Benutzer ist es gut, zu wissen, dass die Firma ihr Logo auf der Seite zeigt. Zusätzliche Informationen zum Ziel des Links sind überflüssig. Wo soll das Logo von Müllermilch schon hinführen. Also sollte "Logo: Müllermilch" im Alternativtext stehen.

2. Das Bild hat zwei Funktionen. Es zeigt das Logo der Firma und es dient als Link auf die Startseite des Webauftritts. Der sehende Benutzer hat damit kein Problem, er wundert sich nicht, wenn er das Bild anklickt und auf der Startseite von Müllermilch landet. Ebenso der blinde Benutzer. Ein grafischer Link namens Müllermilch. Der zeigt und verweist wohl auf Müllermilch. Also kurz und knapp: "Müllermilch" in den Alternativtext!

3. Das Bild hat zwei Funktionen. Es zeigt das Logo der Firma und es dient als Link auf die Startseite des Webauftritts. Für beides soll auch der Alternativtext stehen: "Logo: Müllermilch - zur Startseite".

Alle drei Alternativen unterstützen den blinden Besucher. Im BITV-Test gelten daher alle drei Alternativen als angemessen.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn unverlinkte informative Grafiken oder Bilder, Video- oder Audio-Dateien, oder Multimedia-Objekte vorhanden sind.

Als informative Grafiken gelten:

• grafische Schriften

• Symbole

• Abbildungen, die zeigen sollen, wie ein Objekt oder eine Person aussieht

• Illustrationen, die eine Aussage vorstellen, verdeutlichen oder veranschaulichen sollen

Dekorative Grafiken und Bilder sind Grenzfälle. Sie stellen (im Unterschied zu Layoutgrafiken) etwas dar, der dargestellte Gegenstand hat auch meist einen Bezug zum Thema der Seite. Ihr Informationsgehalt und ihr Nutzen für das Verständnis der Seite ist aber nicht klar. Dekorative Grafiken können daher mit leerem alt-Attribut versehen werden, der Prüfschritt ist dann nicht anwendbar. Anders, wenn Alternativtexte vorhanden sind. Dann ist der Prüfschritt anwendbar, er ist zum Beispiel nicht erfüllt, wenn im alt-Attribut von dekorativen Grafiken Bilddateinamen eingetragen sind.

Logo-artige Elemente in denen Grafik und Schrift verbunden sind, sind fast nie als bloße Schmuckgrafik anzusehen und brauchen deshalb Alternativtext. Wenn sie verlinkt ist, ist das natürlich ohnehin so. Dies ermöglicht blinden und sehenden Nutzern, sich gemeinsam auf diese Elemente zu beziehen. Der Alternativtext muss aber nicht expliziter sein als das, was für den sehenden Nutzer erkenntlich ist.

Darüber hinaus ist der Prüfschritt anwendbar, wenn informative Audio-Elemente vorhanden sind.

2. Prüfung

3. Hinweise

Um die Angemessenheit des Alternativtextes einschätzen zu können, muss der Alternativtext auf die Grafik beziehungsweise das Objekt bezogen werden, zu dem er gehört. Erforderlich ist also die parallele oder wechselnde Darstellung von Grafik/Objekt und zugehörigem Alternativtext.

Da SVG noch nicht ausreichend in allen Screenreader-Browser-Kombinationen unterstützt werden, sollte derzeit die Rolle über WAI-ARIA vermittelt werden (siehe Prüfschritt 9.4.1.2 Name, Rolle, Wert verfügbar).

Anleitungen zm Erstellen von Alternativtexten

• W3C Web Accessibility Tutorials: Images Concepts

• WebAIM: Alternative Text

• HTML 5.1 Spezifikation: Requirements for providing text to act as an alternative for images

W3C - Scalable Vector Graphics (SVG) 1.1

• The 'desc' and the 'title' elements

• Zu Rollen wie role="graphics-document" für komplexere SVG-Grafiken: WAI-ARIA Graphics Module (W3C Recommendation 02 October 2018)

SVGs zugänglich einbinden

• Contextually marking up accessible images and SVGs (Scott O’Hara, May 2019)

• Creating accessible SVGs (Deque blog, January 2019)

• 7 solutions for creating more accessible SVGs (Simply Accessible, March 2017)

• Accessible SVGs (CSS-Tricks, updated August 2016)

Abgrenzung zu anderen Prüfschritten

• Alternativtexte für verlinkte Grafiken (z. B. Bedienelemente oder Teaser-Bilder) werden in Prüfschritt 9.1.1.1a "Alternativtexte für Bedienelemente" geprüft.

• Einfache Animationen oder Videos ohne synchronisierungsbedürftige Tonspur werden in Prüfschritt 9.1.2.1 "Alternativen für Audiodateien und stumme Videos" geprüft.

• Layoutgrafiken oder dekorative Grafiken mit leeren alt-Attributen werden in Prüfschritt 9.1.1.1c "Leere alt-Attribute für Layoutgrafiken" geprüft.

• CAPTCHAs werden in Prüfschritt 9.1.1.1d "Alternativen für CAPTCHAs" geprüft.

• Die Ausgabe der entsprechenden Rolle von SVGs wird im Prüfschritt 9.4.1.2 "Name, Rolle, Wert verfügbar" geprüft (s. o. 3. Hinweise).

Einordnung des Prüfschritts nach WCAG 2.2

Was kann der Alternativtext leisten?

Zum Beispiel die Explosionszeichnung eines Motors: Sollte der gesamte Aufbau des Motors im Alternativtext beschrieben werden?

Die Explosionszeichnung zeigt die Lage verschiedener Teile im Motor. Alternative Vermittlungsformen sind denkbar und möglich. Zum Beispiel könnte die Lage der Teile an einem tastbaren Modell gezeigt werden. Klar ist aber, dass bei einigermaßen komplexen Gebilden die Textform nicht geeignet ist. Die Frage ist daher, was im Alternativtext sinnvoll vermittelt werden kann. Auf jeden Fall kann der Alternativtext darüber informieren, dass eine Explosionszeichnung des Motors dargestellt wird. Der blinde Benutzer weiß dann zumindest, welche Informationen ihm nicht zugänglich sind. Darüber hinaus kann es sein, dass nur ein bestimmtes Detail der gesamten Zeichnung relevant ist. Das geht aus dem Kontext hervor. Das betreffende Detail kann dann in Textform erläutert werden.

Für die Bewertung im BITV-Test gilt: wenn der Prüfer selbst nicht sagen kann, ob oder wie der Informationsgehalt des Bildes in Textform vermittelt werden könnte, muss die Bezeichnung des dargestellten Gegenstandes im Alternativtext als hinreichend bewertet werden.

Firmenlogos

Auf der Website ist das Firmenlogo abgebildet. Reicht es aus, wenn im Alternativtext steht, dass da das Firmenlogo abgebildet ist oder sollte es auch beschrieben werden?

Auch für einen blinden Besucher kann das Aussehen des Logos interessant sein. Er unterhält sich mit Sehenden und weiß dann, wovon die Rede ist. Allerdings sollte der Alternativtext kurz sein, der Besucher möchte nicht immer wieder diese Beschreibung hören, wenn er die Seite besucht. Sie kann also in einer separaten, ausführlichen Beschreibung bereitgestellt werden.

Im BITV-Test wird eine solche ausführliche Beschreibung des Firmenlogos allerdings nicht gefordert.

Abbildungen mit Text

Eine Abbildung enthält Text. Muss dieser Text in jedem Fall im Alternativtext bereitgestellt werden?

Nein, entscheidend ist die Funktion der Abbildung. Wenn es sich um eine Schriftgrafik handelt, dann ist die Sache meistens klar, die Abbildung ist für die Anzeige des Textes da.

Anders verhält es sich, wenn ein Motiv mit Text abgebildet ist. Dann muss (wie bei allen Bildern) überlegt werden, was die Leistung des Bildes ist, ob der abgebildete Text wesentlich ist. Nur dann muss der Text im Alternativtext beachtet werden.

Kann für längere Erläuterungen auch das title-Attribut verwendet werden?

Das title-Attribut hat eine andere Aufgabe, es soll nicht für das Bild stehen, sondern ergänzende Informationen zum Bild liefern. Zum Beispiel kann es verwendet werden, um die Quelle eines Bildes anzugeben. Die Verwendung des title-Attributs von Bildern ist leider nicht einheitlich geregelt.

Auf manchen Webauftritten wird der Inhalt des alt-Attributs durchgängig zusätzlich im title-Attribut wiederholt. Das ist keine gute Lösung, denn es führt dazu, daß blinde Nutzer die Ausgabe des title-Attributs abschalten, um das Vorlesen überflüssiger Informationen zu vermeiden.

Auf keinen Fall kann das title-Attribut als Ersatz für die Bereitstellung des Alternativtextes im alt-Attribut akzeptiert werden.

Für längere Erläuterungen ist das title-Attribut nicht vorgesehen und auch nicht gut geeignet. Es enthält nur einfachen Fließtext, Änderungen der Schriftgröße haben bei den meisten Browsern keine Auswirkungen auf die Darstellung des title-Attributs.

Rolle im Alternativtext

Soll im Alternativtext stehen, dass es sich um ein grafisches Element handelt?

Nein, das ist nicht erforderlich. Denn Screenreader stellen anhand des Markups fest, auf was für ein Element sich der Alternativtext bezieht. Im BITV-Test wird ein entsprechender Vorsatz im Alternativtext jedoch nicht negativ bewertet, er ist für die Bewertung nicht relevant.

Kann die Bedeutung eines Bildes auch im Kontext beschrieben werden?

Das ist in vielen Fällen sinnvoll, gerade weil nicht nur für sehbehinderte Menschen eine alternativen Beschreibung oft nützlich ist. Eine Möglichkeit ist die Positionierung der Alternative in einem gut beschrifteten Ausklappbereich unterhalb des Bildes. Wichtig ist, dass die Beschreibung dem Bild eindeutig zugeordnet werden kann. Dafür kann (und soll) dann der Alternativtext des Bildes genutzt werden. Er enthält eine kurze Bezeichnung des abgebildeten, im Kontext beschriebenen Gegenstandes und einen Hinweis auf die folgende ausführlichere Alternative.

Was sollte im Alternativtext für Landkarten stehen?

Der Alternativtext für Landkarten kann kein Äquivalent sein, eine Beschreibung in Textform kann die Karte nicht ersetzen. Nicht-visuelle Äquivalente könnten Routenbeschreibungen sein, wie sie häufig von Reiseplanern angeboten werden. Das geht aber über die Möglichkeiten des Alternativtextes hinaus. Der Alternativtext für Karten muss sich also darauf beschränken, anzugeben, welches Gebiet auf der Karte dargestellt ist.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn als img-Element eingebundene Grafiken, Font Icons oder SVGs für Layoutzwecke verwendet werden.

2. Prüfung

3. Hinweise

Bei aus mehreren Teilbildern zusammengesetzten Bildern mit Informationsgehalt sollte eines der Teilbilder einen Alternativtext haben, der über den Inhalt des zusammengesetzten Bildes informiert. Die anderen Teilbilder sollten mit leeren alt-Attributen versehen sein.

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

Grafiken mit informativem Charakter

Auf der Seite sind auch Grafiken, die ganz klar informativen Charakter haben, mit leeren alt-Attributen versehen.

Vermutlich wird automatisch ein leeres alt-Attribut erzeugt, wenn zu einem Bild kein entsprechender Text eingegeben worden ist. Zu welchem Prüfschritt gehört das?

So ist das leere alt-Attribut für dekorative Grafiken ganz sicher nicht gedacht. Das leere alt-Attribut ist ja nicht dasselbe wie ein fehlendes alt-Attribut. Es soll dem Besucher sagen, dass die Grafik keinen wichtigen Inhalt enthält und nur der Dekoration dient. Der Besucher weiß dann, dass er nichts versäumt, wenn er die Grafik nicht sieht. Die automatische Vergabe leerer Alternativtexte für informative Grafiken ist ein Missbrauch des leeren alt-Attributs. Sie sorgt dafür, dass man sich auf dieses Kennzeichen nicht mehr verlassen kann.

Dies wird nur in Prüfschritt 9.1.1.1b "Alternativtexte für Grafiken und Objekte" bewertet.

Aufgabe des Bildes in den Alternativtext?

Warum soll man bei Layoutgrafiken nicht die jeweilige Aufgabe des Bildes, also zum Beispiel "Abstandhalter" in den Alternativtext schreiben?

Wofür sollte das gut sein? Den Abstand herstellen, also die Aufgabe des Bildes übernehmen kann der Alternativtext nicht. Die Information, dass da irgendwo Abstände zwischen Elementen der Seite sind, ist nutzlos. Wie die Elemente auf der Seite angeordnet sind, lässt sich der Tatsache, dass an irgend welchen Stellen Abstandhalter sind, auch nicht entnehmen.

Solche Alternativtexte haben also keinen Nutzen. Auf der anderen Seite kann es sehr störend sein, wenn der Screenreader dauernd "Abstandhalter Abstandhalter Abstandhalter …​" vorliest.

Warum müssen Layoutgrafiken mit leeren alt-Attributen versehen werden?

Sie werden ohnehin nicht gebraucht, warum also nicht einfach das alt-Attribut ganz weglassen?

Leider ist es noch nicht selbstverständlich, dass informative Grafiken mit Alternativtexten versehen sind. Wenn eine Webseite Grafiken ohne Alternativtext enthält, kann der blinde Besucher also nicht davon ausgehen, dass diese Grafiken nur dem Layout dienen und für ihn nicht relevant sind. Daher die Festlegung, dass der Webdesigner Grafiken durch Zuordnung eines leeren alt-Attributs ausdrücklich als Layoutgrafiken kennzeichnen soll.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn CAPTCHAs vorhanden sind.

Die Leserlichkeit der Zeichenfolge in einem bildbasierten CAPTCHA ist nicht Teil der Prüfung und wird nicht bewertet.

2. Prüfung

3. Hinweise

CAPTCHAs sind generell problematisch, da jede Form von CAPTCHA für manche Nutzer mit Behinderungen unzugänglich ist (siehe die WCAG 2.0 Note on CAPTCHA).

4. Bewertung

Abgrenzung zu anderen Prüfschritten

Auch die Texteingabe des Captchas muss zugänglich gestaltet sein, damit es insgesamt zugänglich ist. Die Zugänglichkeit der CAPTCHA-Texteingabe wird im Prüfschritt 9.3.3.2 "Beschriftungen von Formularelementen vorhanden"

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn Audiodateien oder stumme Videodateien auf der Seite eingebunden sind.

2. Prüfung

3. Hinweise

Eine Medienalternative ist nicht nötig, wenn Audio- oder Videodateien selbst als ergänzende Medienalternative angeboten werden (etwa eine schriftliche Montageanleitung, die durch eine Bildsequenz der beschriebenen Schritte ergänzt wird). Der Bezug muss dabei klar sein, etwa durch unmittelbare Nachbarschaft der beiden Medienalternativen oder durch einen aussagekräftigen Link.

Eine genaue Entsprechung der Audio- oder stummen Videodatei und ihrer Medienalternative ist nicht erforderlich, es sollen aber nachvollziehbar dieselben Inhalte wiedergegeben werden. Bei Transkriptionen von mehreren Stimmen (etwa Dialogen) sollen die sprechenden Personen im Text identifiziert sein.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

im Fall von zeitbasierten Medien geht es im Prüfschritt 9.1.1.1b "Alternativtexte für Grafiken und Objekte".

1. Anwendbarkeit des Prüfschritts

• Der Prüfschritt ist anwendbar, wenn aufgezeichnete Videos mit synchroner Bild- und Tonspur vorhanden sind.

• Aufgezeichnete Videos ohne Tonspur brauchen keine Untertitel, der Prüfschritt ist für sie nicht anwendbar. Alternativen für Videos ohne Tonspur werden in Prüfschritt 9.1.2.1 "Alternativen für Audiodateien und stumme Videos" geprüft.

2. Prüfung

3. Bewertung

Abgrenzung zu anderen Prüfschritten

Einordnung des Prüfschritts nach WCAG 2.2

BIK für Alle: Leitfaden barrierefreie Online-Videos

• Für Webentwickler: Einbindung in die Internetseite Hinweise zur Wahl von Mediaelementen.

• Untertitelung

'Sprungmarker' zur Barrierefreiheit von Media-Playern

• Barrierefreiheit & Media Player: eine Kurzübersicht - Teil 1

• Barrierefreiheit & Media Player: Captioning - Teil 2

Zum Stellenwert von Untertiteln und Gebärdensprache

(http://lists.w3.org/Archives/Public/w3c-wai-ig/2003JulSep/0222.html)

Können an Stelle der Untertitel auch Filme mit gebärdensprachlicher Darstellung eingeblendet werden?

Solche Filme sind hilfreich für Personen, die über Gebärdensprache kommunizieren. Meist sind das Personen, die gehörlos geboren oder schon früh ertaubt sind. Dagegen können Personen, die erst im Alter ertaubt sind, in der Regel nicht über Gebärdensprache kommunizieren. Sie benötigen Untertitel. Gebärdensprachliche Darstellungen sind also kein Ersatz für die Untertitel.

1. Anwendbarkeit des Prüfschritts

• Der Prüfschritt ist anwendbar, wenn Videos mit synchroner Bild- und Tonspur vorhanden sind und Informationen über das Bildgeschehen für das Verständnis erforderlich sind.

• Videos brauchen keine Audiodeskription oder Volltext-Alternative, wenn der Fortgang des Bildgeschehens nicht in Worte gefasst werden kann. Der Prüfschritt ist dann nicht anwendbar.

• Verzichtbar ist die Audiodeskription oder Volltext-Alternative, wenn die synchrone Wahrnehmung von Bild und Ton für das Verständnis des Videos nicht erforderlich ist oder wenn das Video keine Tonspur hat (siehe Prüfschritt 9.1.2.1 "Alternativen für Audiodateien und stumme Videos").

• Verzichtbar ist die Audiodeskription oder Volltext-Alternative auch für Videos, die lediglich als Medienalternative zu einem textbasierten Inhalt dienen, das heißt ergänzend zu einem Text angeboten werden, um den Textinhalt zusätzlich in anderer Form zu vermitteln. Dies gilt nur für Videos, die keine über den Textinhalt hinausgehende Informationen bieten und die klar als Medienalternative zum Text erkennbar sind.

• Gebärdensprachvideos brauchen keine Audiodeskription.

2. Prüfung

3. Hinweis

Die Anforderung 9.1.2.3 Audiodeskription oder Volltextalternative ist in den WCAG der Konformitätsstufe A zugeordnet. Auf Konformitätstufe AA gibt es ein Erfolgskriterium, das die Volltext-Alternative nicht akzeptiert. Der BITV-Test prüft dieses Erfolgskriterium der Stufe AA im Prüfschritt 9.1.2.5 Audiodeskription für Videos

Bietet die Website eine Volltextalternative, so ist zwar 9.1.2.3 (A) erfüllt, nicht aber 9.1.2.5 (AA). Da der BITV-Test Konformität auf Stufe AA prüft, wird dann die Seite in der Auswertung des Tests als "nicht konform" bewertet. Eine Audiodeskription ist also für eine konforme Bewertung der Seite im BITV-Test gefordert, sofern der Prüfschritt anwendbar ist.

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

BIK für Alle: Leitfaden barrierefreie Online-Videos

• Für Webentwickler: Einbindung in die Internetseite
  Hinweise zur Wahl von Mediaelementen.

• Audiodeskription

Blogartikel von 'Sprungmarker' zur Barrierefreiheit von Media-Playern (Stand 09/2014):

• Barrierefreiheit & Media Player: eine Kurzübersicht - Teil 1

Blogartikel von Terrill Thompson zu Audio Description (Stand 03/2017):

• My Audio Description Talk @ CSUN

Was sind "wichtige informationstragende Bildinhalte"?

• Sehr häufig tauchen in Videos eingeblendete Texte auf, die etwa Sprecher oder Sprecherin bzw. deren Rolle benennen. Ohne diese Information ist für nicht-visuelle Nutzer unklar, wer da eigentlich spricht oder interviewt wird. Wenn es eher unwichtig ist, wie die Person heißt, die spricht (z.B. in Passantenbefragungen) sind solche Einblendungen nicht als "wichtige informationstragende Bildinhalte" zu betrachten.

• Oft sind Videos auch über visuelle Zwischentitel oder eingeblendete Fragen strukturiert. Hier ist zu prüfen, inwieweit die Informationen auch ohne Audiodeskription oder Transkription der Bildinhalte sinnvoll und verständlich sind - zum Beispiel weil ein Sprecherton in der Folge ausreichend Kontext liefert.

1. Anwendbarkeit des Prüfschritts

• Der Prüfschritt ist anwendbar, wenn Live-Übertragungen mit synchroner Bild- und Tonspur vorhanden sind.

• Live-Videos ohne Tonspur brauchen keine Untertitel, der Prüfschritt ist für sie nicht anwendbar. Alternativen für Videos ohne Tonspur werden in Prüfschritt 9.1.2.1 "Alternativen für Audiodateien und stumme Videos" geprüft.

2. Prüfung auf Untertitel

1. Das Video im auf der Website eingebundenen Player abspielen.

2. Prüfen, ob parallel zum Video Untertitel automatisch angezeigt werden oder zugeschaltet werden können.

3. Wenn Untertitel vorhanden sind, eine kurze Sequenz des Videos mit Untertiteln ansehen, um stichprobenartig festzustellen, ob die Untertitel dem hörbaren Inhalt entsprechen. Dies betrifft auch akustische Ereignisse, die für das Verständnis des Inhalts wichtig sind.

3. Bewertung

Abgrenzung zu anderen Prüfschritten

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

• Der Prüfschritt ist anwendbar, wenn Videos mit synchroner Bild- und Tonspur vorhanden sind und Informationen über das Bildgeschehen für das Verständnis erforderlich sind.

• Videos brauchen keine Audiodeskription, wenn der Fortgang des Bildgeschehens nicht in Worte gefasst werden kann. Der Prüfschritt ist dann nicht anwendbar.

• Verzichtbar ist die Audiodeskription, wenn die synchrone Wahrnehmung von Bild und Ton für das Verständnis des Videos nicht erforderlich ist oder wenn das Video keine Tonspur hat (siehe Prüfschritt 9.1.2.1 "Alternativen für Audiodateien und stumme Videos").

• Verzichtbar ist die Audiodeskription auch für Videos, die lediglich als Medienalternative zu einem textbasierten Inhalt dienen, das heißt ergänzend zu einem Text angeboten werden, um den Textinhalt zusätzlich in anderer Form zu vermitteln. Dies gilt nur für Videos, die keine über den Textinhalt hinausgehende Informationen bieten und die klar als Medienalternative zum Text erkennbar sind.

• Gebärdensprachvideos brauchen keine Audiodeskription.

2. Prüfung

Es wird eine Sicht- und Hörprüfung vorgenommen:

1. Art der Einbindung feststellen. Die Audiodeskription kann auf verschiedenem Wege angeboten werden:

   • Die Audiodeskription ist bereits in der normalen Tonspur enthalten.

   • Eine weitere Version des Videos mit Audiodeskription wird angeboten. Diese Version wird geprüft. Ein funktionierender Link zu dieser Version muss im unmittelbaren Kontext des Videos angeboten werden, ebenso wie ein Zurück-Link (oder das Zurückspringen funktioniert über den Zurück-Button des Browsers).

   • Das Video hat eine zuschaltbare Tonspur mit der Audiodeskription. Diese Spur wird zusätzlich geschaltet.

2. Das Video wird im auf der Website eingebundenen Player oder in einem externen, vom Format abhängigen Video-Player abgespielt.

3. Sind im Video wichtige informationstragende Bildinhalte vorhanden, die nicht in der Tonspur bzw. einer zusätzlichen Audiodeskription vorkommen?

3. Bewertung

Abgrenzung zu anderen Prüfschritten

In diesem Prüfschritt wird nur geprüft, ob das Video eine Audiodeskription hat. Eine Volltextalternative wird im Prüfschritt 9.1.2.3 "Audiodeskription oder Volltext-Alternative für Videos" bewertet. Braucht ein Video eine Audiodeskription und sind weder eine Audiodeskription noch eine Volltextalternative vorhanden, sind sowohl dieser Prüfschritt als auch Prüfschritt 9.1.2.3 "Audiodeskription oder Volltext-Alternative für Videos" nicht bzw. nicht voll erfüllt.

Einordnung des Prüfschritts nach WCAG 2.2

BIK für Alle: Leitfaden barrierefreie Online-Videos

• Für Webentwickler: Einbindung in die Internetseite Hinweise zur Wahl von Mediaelementen.

• Audiodeskription

Blogartikel von 'Sprungmarker' zur Barrierefreiheit von Media-Playern (Stand 09/2014)

• Barrierefreiheit & Media Player: eine Kurzübersicht - Teil 1

Blogartikel von Terrill Thompson zu Audio Description (Stand 03/2017):

• My Audio Description Talk @ CSUN

Was sind "wichtige informationstragende Bildinhalte"?

• Sehr häufig tauchen in Videos eingeblendete Texte auf, die etwa Sprecher oder Sprecherin bzw. deren Rolle benennen. Ohne diese Information ist für nicht-visuelle Nutzer unklar, wer da eigentlich spricht oder interviewt wird. Wenn es eher unwichtig ist, wie die Person heißt, die spricht (z.B. in Passantenbefragungen), sind solche Einblendungen nicht als "wichtige informationstragende Bildinhalte" zu betrachten.

• Oft sind Videos auch über visuelle Zwischentitel oder eingeblendete Fragen strukturiert. Hier ist zu prüfen, inwieweit die Informationen auch ohne Audiodeskription oder Transkription der Bildinhalte sinnvoll und verständlich sind - zum Beispiel, weil die Tonspur in der Folge ausreichend Kontext liefert.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn es auf der Seite Inhalte gibt, die durch Überschriften strukturiert werden können. Das ist bei informationsorientierten Seiten in der Regel der Fall.

2. Prüfung

1. Seite im Firefox aufrufen.

2. Über die Web Developer Toolbar die Seite ohne Stylesheets anzeigen (CSS > Stile deaktivieren > Alle Stile deaktivieren wählen), dann das Bookmarklet "Inhalte gegliedert" aufrufen. Alternativ das HeadingsMap Browser-Plugin nutzen, um die Überschriften-Hierarchie anzuzeigen.

3. Prüfen, ob Inhalte, die visuell als Überschriften zu erkennen sind, mittels der HTML-Strukturelemente h1 bis h6 als Überschriften ausgezeichnet sind

4. Wenn kein natives Überschriften-Markup eingesetzt wird, prüfen, ob visuelle Überschriften alternativ mit role="heading" und passenden aria-level-Attributen zur Festlegung der Überschriften-Ebene ausgezeichnet sind. Die Hierarchie der eingesetzten HTML-Überschriftselemente soll der Gliederung der Inhalte entsprechen.

5. Prüfen, ob HTML-Strukturelemente h1 bis h6 lediglich zur Erzeugung unterschiedlicher Schriftgrößen eingesetzt werden.

3. Hinweise

• Es ist nicht die Aufgabe des Prüfschritts zu prüfen, ob Wortwahl oder Stil der Überschriften den jeweiligen Inhalten angemessen sind.

• Überschriften sollten korrekt geschachtelt sein (h1 gefolgt von h2 gefolgt von h3, und so weiter, oder entsprechenden aria-level-Attributen auf Elementen mit role="heading"), um die Gliederung der Text-Inhalte abzubilden. Das Auslassen von Hierarchie-Ebenen ist aber an sich kein Fehler, solange die hierarchische Abfolge der Überschriften logisch bleibt.

• Die erste Regel für den Einsatz von WAI-ARIA empfiehlt, wenn möglich native HTML-Elemente einsetzen. Siehe Using of ARIA, First rule of ARIA use. Wenn dies nicht möglich ist, kann mit role="heading" und dem aria-level-Attribut die Semantik zur Verfügung gestellt werden.

• Die Inhalte von iframes werden ebenso überprüft wie andere Seiteninhalte. Dazu muss unter Umständen der iframe in einem neuen Fenster geladen werden.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

In diesem Prüfschritt geht es um den Einsatz von Überschriften zur Gliederung der Seiteninhalte, damit diese leicht zu erfassen und mit Hilfsmitteln wie Screenreadern zu überspringen sind.

Im Prüfschritt 9.2.4.1 "Bereiche überspringbar" geht es dagegen um die Strukturierung der Seitenbereiche durch Überschriften, WAI-Aria-Attribute oder Sprunglinks.

Einordnung des Prüfschritts nach WCAG 2.2

Überschriften zur Abbildung der Struktur verwenden

(http://www.w3.org/TR/WCAG10-HTML-TECHS/#document-headers)

Überschriften richtig schachteln

(WCAG 2.0 Technik G141: Organizing a page using headings)

Überschriften-Elemente und CSS-Auszeichnungen nicht missbrauchen

(WCAG 2.0 Technik H42: Using h1-h6 to identify headings)

Kann es mehrere h1-Überschriften auf einer Seite geben?

Die mit h1 ausgezeichnete Hauptüberschrift sollte sagen, worum es auf der Seite geht. Wenn alle Inhalte der Seite zu einem übergreifenden Thema gehören, dann sollte die Hauptüberschrift dieses Thema angeben. Es gibt dann nur eine mit h1 ausgezeichnete Überschrift.

Vielleicht hat die Seite aber auch zwei Themen, die keine große Gemeinsamkeit haben. Wenn es in so einem Fall nur eine Hauptüberschrift gibt, dann ist diese entweder nichtssagend oder sie zählt einfach die beiden Themen auf. Ihr Nutzen ist fraglich, es kann also auch sinnvoll sein, mehrere Überschriften auf derselben Seite mit h1 auszuzeichnen.

Warum sind die Anforderungen des Prüfschritts so allgemein gehalten?

Formale Regeln für die Strukturierung durch Überschriften sind sinnvoll und sie können nützlich sein. Oft liefert ihre Überprüfung Hinweise auf falsche oder missbräuchliche Anwendung der Überschriften oder anderer Strukturelemente.

Die Umkehrung ist aber nicht möglich, formal korrekte Überschriftstrukturen sind nicht unbedingt brauchbar. Entscheidend ist, dass die Überschriften den Inhalt der Seite erschließen. Man muss sich also das aus den Überschriften zusammengesetzte Inhaltsverzeichnis ansehen und überlegen:

• Ist das Verzeichnis vollständig?

• Zeigt es mir alle wichtigen Inhalte der Seite?

• Ist das Verzeichnis brauchbar?

• Kann ich ohne viel Aufwand auf alle wichtigen Inhalte der Seite zugreifen?

Das sind die entscheidenden Fragen, die Struktur muss für die Nutzenden brauchbar sein. Die Einhaltung der verschiedenen technischen Regeln ergibt sich dann von selbst.

Muss für die oberste Überschrift immer h1 verwendet werden?

Die Frage ist, ob es einen akzeptablen Grund gibt, die h1-Überschrift zu überspringen. Es kann zum Beispiel sein, dass h2 verwendet worden ist, weil der umsetzenden Person die h1-Überschrift zu groß war und er nicht wusste, wie man die Größe ändert. Das wäre kein akzeptabler Grund, denn Inhalt und Form soll man trennen.

Ein anderer Grund dafür, mit einer niedrigeren Überschrift-Ebene anzufangen: Das Webangebot ist ein zusammengesetztes Dokument, die einzelnen Seiten sind zum Beispiel einzelne Kapitel dieses Dokuments. Das ist ein akzeptabler Grund.

Für die Brauchbarkeit von Überschriften kommt es allerdings nicht darauf an, dass eine h1 an oberster Stelle steht.

Kann man auch grafische Schriften als Überschriften auszeichnen?

Generell ist die Verwendung von Schriftgrafiken für Überschriften problematisch. Denn die Nutzenden können Grafiken nicht so leicht an seine Bedürfnisse anpassen.

Sie können jedoch als Überschrift ausgezeichnet werden. Der Prüfschritt 9.1.3.1.A ist erfüllt, wenn grafische Überschriften in angemessener Weise als Überschriften ausgezeichnet sind.

Was ist der Unterschied zwischen dem Dokumenttitel und der h1-Überschrift?

Der Dokumenttitel wird als Fenstertitel oder für Bookmarks verwendet. Wenn man mehrere Bookmarks in seiner Liste hat oder mehrere Fenster geöffnet sind, dann soll der Dokumenttitel dabei helfen, die richtige Seite auszuwählen. Was muss im Dokumenttitel stehen, damit das geht? Der Dokumenttitel hat zwei Bestandteile.

Der erste Bestandteil sagt einem, worum es auf der Seite geht. Er ist normalerweise für alle Dokumente eines Webangebotes unterschiedlich. Denn man braucht ihn, um unterschiedliche Seiten des selben Webangebotes zu unterscheiden.

Der zweite Bestandteil sagt, zu welchem Webangebot die Seite gehört. Er ist normalerweise für alle Dokumente eines Webangebots gleich, man braucht ihn, um die Seite von thematisch ähnlichen Seiten anderer Webangebote zu unterscheiden.

Bei der Hauptüberschrift geht es dagegen eher um die interne Strukturierung der Seite. Von außen sehe ich die Hauptüberschrift nicht, sie wird mir erst gezeigt, wenn ich die Seite ausgewählt und geöffnet habe.

Die Hauptüberschrift sagt mir dann noch mal das Hauptthema der Seite oder - wenn es mehrere Hauptüberschriften gibt - die zwei oder drei Hauptthemen.

Da auch der Dokumenttitel das Hauptthema der Seite angeben soll, kann es also gut sein, dass die Hauptüberschrift einfach den "individuellen" Teil des Dokumenttitels wiederholt.

Wobei man jetzt sagen kann: Wofür brauche ich dann überhaupt noch die Hauptüberschrift. Was ich über den Dokumenttitel oder über das Navigationssystem des Webangebotes ausgewählt habe, das weiß ich doch. Manche Webseiten verzichten daher auf die Hauptüberschrift und es geht direkt los mit einer Liste von "Einstiegspunkten", die auf die Themen der Seite verweisen. Das ist plausibel, aber man kann auch den Standpunkt vertreten, dass die Hauptüberschrift ruhig noch mal auf der Seite selbst stehen soll.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Seite Elemente enthält, die von ihrem Erscheinungsbild oder ihrer Funktion her Listen sind. Das ist bei informationsorientierten Seiten häufig der Fall.

Da auch die missbräuchliche Verwendung der HTML-Elemente für Listen geprüft wird, ist der Prüfschritt darüber hinaus immer anwendbar, wenn die Seite Elemente enthält, die als Listen ausgezeichnet worden sind.

2. Prüfung

• Seite im Firefox aufrufen.

• Lists Bookmarklet aufrufen. Listenauszeichnungen, soweit vorhanden, werden nun dargestellt.

• Prüfen, ob alle Listen inklusive der Menüs mit den vorgesehenen HTML-Strukturelementen für Listen ausgezeichnet sind (ul, ol, dl).

• Prüfen, ob Listen-Markup für Elemente verwendet wird, die nicht Listen sind.

3. Hinweise

Es soll nicht beurteilt werden, ob auf der Seite enthaltene Texte vielleicht besser in Listenform dargestellt werden sollten. Es soll nur geprüft werden, ob vorhandene, erkennbare Listen auch entsprechend ausgezeichnet sind.

Listen erkennt man normalerweise an ihrer Darstellung auf dem Bildschirm. Sie heben sich deutlich von normalen Textabschnitten ab, oft sind sie eingerückt, meist sind den Listeneinträgen Aufzählungszeichen oder Zahlen vorangestellt.

Navigations-Menüs listen Gruppen von Linkzielen auf und sind deshalb von ihrer Aufgabe her immer Listen, egal wie sie gestaltet sind. Sie sollten deshalb auch als Listen ausgezeichnet werden. Für Aktionsmenüs eignen sich dagegen eher ARIA-Konstrukte wie menu.

Beschreibungslisten (dl) repräsentieren eine Liste von Gruppen von Begriffen (spezifiziert mit dem dt-Element) und Beschreibungen (bereitgestellt durch dd-Elemente). Typische Anwendungen für Beschreibungslisten sind Glossare oder die Darstellung von Schlüssel/Wert-Paaren. Ihr Einsatz für andere paarige Informationen wird akzeptiert, auch wenn das Konstrukt von Screenreadern nicht gut unterstützt wird.

Bei der Einschätzung, ob eine Listenauszeichnung zwingend nötig ist, sollte die Semantik des jeweiligen Elements berücksichtigt werden. So ist z.B. ein Seitenpfad (breadcrumb) nicht zwingend als Liste umzusetzen, schon da er nicht wie eine Liste aussieht und nicht gleichartige Elemente bündelt. In der Praxis wird ein Seitenpfad sowohl als einfache Liste als auch zur Abbildung der Hierarchie als verschachtelte Liste umgesetzt, in anderen Fällen jedoch auch schlicht als Absatz mit Links. Alle diese Umsetzungen sind möglich und haben jeweils Vor- und Nachteile.

Ein häufiger Fall ist die Verwendung von komplexten Teaser-Kacheln, die Bild, Überschrift, Begleittext und Link bündeln und je nach Viewportbreite horizontal oder vertikal angeordnet sein können. Solche Kacheln können als ungeordnete Liste umgesetzt werden, dies ist aber nicht zwingend. Wird auf Listenauszeichnung von Gruppen komplexer Kacheln verzichtet, sollten die Inhalte auf andere Weise semantisch gegliedert sein, etwa durch Überschriften-Auszeichnung. Bei längeren und eigenständigen Kachel-Inhalten ist auch die Auszeichnung mittels article-Element denkbar. Bestehen die Textinhalte von Kacheln nur aus einfachen Links, ist die Listenauszeichnung immer angemessen.

Eine Liste mit nur einem Element kann dann sinnvoll sein, wenn potenziell auch mehr als ein Listeneintrag auftauchen kann (z.B. ein oder mehrere Einträge in einem Suchergebnis oder nach einer Filterung).

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Seite eigenständige Abschnitte enthält, die als Zitate verstanden werden können oder wenn die Seite Elemente enthält, die als Zitate ausgezeichnet worden sind.

2. Prüfung

Die Seite im Firefox aufrufen. Prüfen, ob Zitate, die als eigenständige Abschnitte gefasst sind, mit dem dafür vorgesehenen HTML-Strukturelement blockquote ausgezeichnet sind. Im Firefox in über F12 die Web Developer Tools öffnen und im Bereich Inspector im Suchfeld nach blockquote suchen. Falls die Auszeichnung vorkommt, überprüfen, ob sie tatsächlich für Zitate und nicht nur für die Formatierung / Einrückung anderer Inhalte eingesetzt wird.

3. Hinweise

Nicht geprüft werden soll, ob Inline-Zitate (also Zitate, die nicht als eigenständige Abschnitte gefasst sind) mit dem vorgesehenen HTML-Strukturelement q ausgezeichnet sind. In Bezug auf die Zugänglichkeit ist der Nutzen der Kennzeichnung mit q im Vergleich zur Kennzeichnung mit normalen Anführungszeichen gering. Zudem ist die Unterstützung von q in verschiedenen Browsern nicht einheitlich.

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn es auf der Seite gegliederte Textinhalte mit Absätzen gibt.

2. Prüfung

3. Hinweise

• Es soll nicht bewertet werden, ob die vorhandene, sichtbare Gliederung der Seite sinnvoll ist, sondern nur, ob sie mit geeigneten HTML-Elementen umgesetzt wurde.

• Das für Absätze vorgesehene Element ist grundsätzlich p. Dennoch ist eine Nutzung von div anstelle von p in der programmatischen Ausgabe, etwa durch Screenreader, in der Regel nicht mit Nachteilen verbunden. Die Nutzung von div anstelle von p für Textabsätze sollte deshalb in der Regel nicht zu einer Bewertung des Prüfschritts mit "teilweise erfüllt" oder schlechter führen.

• Die Verwendung von HTML-Strukturelementen für Tabellen, Überschriften, Listen und Zitate ist bereits durch andere Prüfkriterien abgedeckt und wird dort bewertet.

• Die Inhalte von iframes werden ebenso überprüft wie andere Seiteninhalte. Dazu muss unter Umständen der iframe in einem neuen Fenster geladen werden.

• Textinhalte mittels CSS-Attribut content werden heute in der Regel von Screenreadern ausgegeben und stellen deshalb meist keine praktische Barriere dar. Der Einsatz von CSS content sollte deshalb nicht zu einer Bewertung als "teilweise erfüllt" oder schlechter führen. Im Sinne einer konsequenten Trennung von Semantik und optischer Darstellung (HTML / CSS) ist die Einbringung von Textinhalten über CSS dennoch nicht empfehlenswert, denn in manchen Nutzungsszenarien (eigene Stylesheets, Darstellung ohne CSS) können Inhalte fehlen.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

Andere auf Strukturierung bezogenen Prüfkriterien sind:

• Prüfschritt 9.1.3.1a "HTML-Strukturelemente für Überschriften"

• Prüfschritt 9.1.3.1b "HTML-Strukturelemente für Listen"

• Prüfschritt 9.1.3.1c "HTML-Strukturelemente für Zitate"

• Prüfschritt 9.1.3.1e "Datentabellen richtig aufgebaut"

Die Textalternative für Font-Icons wird im Prüfschritt 9.1.1.1a "Alternativtexte für Bedienelemente" und 9.1.1.1b "Alternativtexte für Grafiken und Objekte" geprüft.

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar, wenn native oder über ARIA-Rollen ausgezeichnete Datentabellen auf der Seite vorhanden sind. Er ist ebenso anwendbar, wenn Inhalte visuell als Datentabelle strukturiert sind.

2. Prüfung

3. Hinweise

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

Warum müssen die Tabellenheader extra ausgezeichnet werden?

Kann der Screenreader nicht einfach automatisch die erste Zeile und die linke Spalte als Überschriften behandeln? Wird das nicht auch faktisch so gemacht?

Beides ist richtig: Screenreader brauchen die Auszeichnung nicht zwingend, um Spalten- und Zeilenüberschriften vorzulesen - und gängige Screenreader verhalten sich auch genau so: Wenn der Benutzer in eine andere Spalte wechselt, liest zum Beispiel der Screenreader Jaws den Text vor, der in der obersten Zelle dieser Spalte steht, auch wenn diese Zelle nicht als th-Element ausgezeichnet ist. Ebenso beim Wechsel in eine andere Zeile: Der Inhalt der ersten Zelle wird unabhängig von der Auszeichnung immer vorgelesen (zumindest dann, wenn Datenzellen nicht ausdrücklich via >headers und id mit bestimmten Überschriftenzellen verknüpft sind).

Warum ist das so?

Das beschriebene Verhalten der Screenreader ist bei einfachen Tabellen meistens richtig. Und es gibt natürlich im Web sehr viele Tabellen, bei denen die Überschriften nicht ausgezeichnet sind. Insgesamt werden Nutzende daher am besten bedient, wenn der Screenreader die Zellen der ersten Zeile und der ersten Spalte grundsätzlich wie Überschriftenzellen behandelt.

Was folgt daraus?

Kann man sich bei einfachen Tabellen den Aufwand für die Auszeichnung von Tabellenüberschriften dann nicht sparen?

Zunächst mal: Der Aufwand für die Auszeichnung der Zellen ist in der Regel nicht erheblich. Jedenfalls bei einfachen Tabellen: Es gibt entsprechende Vorlagen oder das CMS kümmert sich darum. Die eigentliche Herausforderung liegt woanders: Man muss dafür sorgen, dass die Tabellen einfach sind, dass die Inhalte der ersten Zeile und Spalte tatsächlich als Überschriften funktionieren und dass alle strukturierenden Inhalte dort untergebracht sind.

Und klar ist: nicht jedes Hilfsmittel muß in der beschriebenen Art und Weise mit Tabellen umgehen. Der IBM Homepagereader liest nur ausgezeichnete Überschriften vor, wie künftige Jaws-Versionen funktionieren, kann auch niemand sagen.

Oder allgemein gesagt: Die praktische Nutzbarkeit mit gängigen Screenreadern oder Browsern kann nicht der alleinige Maßstab für Barrierefreiheit und BITV-Konformität sein. Denn dann würde es immer bei dem unbefriedigenden Zustand bleiben, dass Screenreader versuchen müssen, aus barrierebehafteten Webangeboten irgend etwas brauchbares herauszuholen. Auf längere Sicht ist es auch wichtig, dass sich Verantwortliche Personen von Webangeboten und Entwicklende von Screenreadern oder Browsern an gemeinsame Standards halten.

Der Aufbau von Datentabellen kann unter Umständen nicht einfach verändert werden, wie kann die Barrierefreiheit trotzdem sichergestellt werden?

Zwei Fälle sind da zu unterscheiden:

Der Aufbau der Tabelle gehört zum Inhalt. Das Dokument ist zum Beispiel historisch, es zeigt, wie die alten Ägypter ihre Erntedaten tabellarisch geordnet haben. In diesem Fall muss geklärt werden, ob die Tabelle nur betrachtet oder auch genutzt werden soll. Wenn sie nur betrachtet werden soll, ist der lineare Zugriff ausreichend. Wenn sie auch genutzt werden soll, wenn sie also zum Beispiel auch über fette und magere Erntejahre Auskunft geben soll, ist die historische Form ungeeignet. Ein anderes Dokument muss dafür erstellt werden. Der häufigere und wichtigere Fall: eine andere Abteilung liefert die mangelhaft aufgebauten Tabellen, in der EDV sollen sie durch unsichtbare Zusätze nachträglich barrierefrei gemacht werden. In diesem Fall muss der Ablauf geändert werden, denn die mangelhafte Struktur kann nicht durch Auszeichnungen repariert werden, die Aufgabe ist nicht erfüllbar. Die Verantwortlichen müssen dafür sorgen, dass die Anforderungen der Barrierefreiheit an der richtigen Stelle, also schon bei der Erstellung der Tabellen beachtet werden.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn eine Datentabelle komplex ist, also mehrstufige Zeilen- oder Spaltenüberschriften vorhanden sind oder wenn in einer einfachen Datentabelle Zellen ausdrücklich (per headers und id) bestimmten Überschriften zugeordnet sind (auch wenn diese Zuordnung eigentlich nicht erforderlich wäre).

Einfache Datentabellen haben im Unterschied zu komplexen Datentabellen nur jeweils eine Zeile oder Spalte für Überschriften. Bei solchen Tabellen ist es eigentlich nicht erforderlich, die Zellen "ihren" Überschriften zuzuordnen.

2. Prüfung

• Seite im Firefox laden.

• Das Tables bookmarklet aufrufen. Tabellen-Auszeichnungen werden jetzt angezeigt.

• Prüfen, ob der Geltungsbereich der Überschriften korrekt über das scope-Attribut definiert ist oder die einzelnen Zellen mithilfe von headers- und id-Attributen korrekt ihren Überschriften zugeordnet sind.

3. Hinweis

Grundlage der Prüfung ist die vorangegangene Überprüfung des Aufbaus der Datentabelle und der Auszeichnung von Überschriften in Prüfschritt 9.1.3.1e "Datentabellen richtig aufgebaut". Dieser Prüfschritt 9.1.3.1f beschränkt sich auf die Vollständigkeit und die formale Korrektheit der Zuordnung von Inhalten zu Überschriften.

Einordnung des Prüfschritts nach WCAG 2.2

Was sind Tabellen mit mehreren logischen Ebenen?

(http://lists.w3.org/Archives/Public/wai-wcag-editor/2000OctDec/0155.html)

Weiterführende Links:

• pro-barrierefreiheit: Strukturierung von Tabelleninhalten

• Roger Hudson, Web Usability: Accessible Data Tables

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Seite Tabellen für das Layout verwendet.

2. Prüfung

• Seite im Firefox aufrufen.

• Das Tables bookmarklet aufrufen. Tabellen-Auszeichnungen werden jetzt angezeigt.

• Prüfen, ob strukturelle Auszeichnungen (th, caption, summary, headers, id) in Layouttabellen vermieden werden.

3. Hinweis

Auch wenn Tabellen mit role="presentation" bzw. role="none" ausgezeichnet sind, sollten semantische Elemente nicht benutzt werden.

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

• Der Prüfschritt ist anwendbar, wenn die Seite Formularelemente enthält.

2. Prüfung

3. Hinweise

4. Bewertung

Abgrenzung zu anderen Prüfschritten

• Ob die Beschriftungen von Formular-Elementen (auch bei Nutzung von Gruppenüberschriften als Ergänzung der unmittelbaren Beschriftungen) hinreichend aussagekräftig sind, wird in Prüfschritt 9.2.4.6 "Aussagekräftige Überschriften und Beschriftungen" geprüft. Hier geht es um die programmatische Ermittelbarkeit.

• Ob die sichtbare Beschriftung überhaupt vorhanden ist, wird in Prüfschritt 9.3.3.2 "Beschriftungen von Formularelementen vorhanden" geprüft.

• Ob die sichtbare Beschriftung im zugänglichen Namen des Formularelements vorkommt, wird in Prüfschritt 9.2.5.3 "Sichtbare Beschriftung Teil des zugänglichen Namens" geprüft.

Einordnung des Prüfschritts nach WCAG 2.2

W3C Web Accessibility Tutorials: Forms

• Labeling Controls

• Grouping Controls

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn CSS verwendet wird, insbesondere für die Positionierung von Inhalten, und wenn Inhalte dynamisch eingeblendet oder eingefügt werden.

2. Prüfung

3. Hinweise

4. Bewertung

Abgrenzung zu anderen Prüfschritten

• Custom controls, die etwa Benutzerschnittstellen aus positionierten div s mit Hintergrundbildern erzeugen, werden bereits in einer Reihe von bestehenden Prüfkriterien implizit geprüft, etwa 9.2.4.7 "Aktuelle Position des Fokus deutlich", und 9.4.1.2 "Name, Rolle, Wert verfügbar".

• Die korrekte Reihenfolge im Quelltext bei dynamisch generierten oder eingeblendeten Elementen ist Gegenstand von Prüfschritt 9.2.4.3 "Schlüssige Reihenfolge bei der Tastaturbedienung".

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

Abgrenzung zu anderen Prüfschritten

Prüfschritt 9.1.4.1 "Ohne Farben nutzbar" behandelt die Verwendung von Farbe zur Übermittlung von Information, hier dagegen geht es um Form, Position, oder textliche Bezüge.

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Die Prüfung des Wechsels der Bildschirmausrichtung sollte immer anwendbar sein, außer es gibt spezielle Inhalte, die nur in einer Ausrichtung funktionieren.

2. Prüfung

1. Ein aktuelles mobiles Gerät (z.B. ein iPhone oder Android-Handy) zur Prüfung verwenden.

2. Sicherstellen, dass auf dem mobilen Prüfgerät die Ausrichtung nicht hardware- oder betriebssystemseitig festgestellt bzw. arretiert ist.

3. Der zu prüfende Inhalt wird im Browser Chrome (Android) oder Safari (iOS) erst in der einen Ausrichtung neu geladen.

4. Prüfen, ob Inhalte dargestellt werden und nutzbar sind.

5. Gerät um 90 Grad drehen. Der zu prüfende Inhalt wird in der anderen Ausrichtung neu geladen.

6. Prüfen, ob Inhalte auch in der anderen Ausrichtung dargestellt werden und nutzbar sind. Treten Beschränkungen beim Wechsel der Ausrichtung auf, etwa Meldungen, welche zur Nutzung der jeweils anderen Ausrichtung auffordern?

7. Wenn nur eine Ausrichtung unterstützt wird und in der anderen Ausrichtung entweder der Inhalt nicht erscheint, um 90 Grad gedreht erscheint, oder aber eine Meldung ausgegeben wird, dass die andere Ausrichtung zu nutzen ist: Prüfen, ob die unterstützte Ausrichtung für den Inhalt unbedingt erforderlich ist, die Inhalte in der nicht unterstützten Ausrichtung also nicht oder nur schlecht dargestellt werden könnten.

3. Hinweise

Es wird nicht verlangt, dass eine Änderung der Ausrichtung die Inhalte dynamisch anpasst (obwohl dies wünschenswert und bei responsiven Angeboten meist auch der Fall ist). Der Inhalt muss also ggf. in beiden Ausrichtungen jeweils neu geladen werden.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

Gegenstand dieses Prüfschritts ist die Anpassbarkeit der Bildschirm-Ausrichtung, nicht jedoch Änderungen hinsichtlich der Verfügbarkeit von Inhalten oder Funktionalität, die durch den Wechsel hervorgerufen werden. Dies ist Gegenstand von Prüfschritt 9.1.4.4 "Text auf 200% vergrößerbar" und 9.1.4.10 "Inhalte brechen um".

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn Formular-Eingabefelder vorhanden sind, die sich auf Nutzerdaten beziehen (etwa Login / Anmeldung, Kontaktformulare, oder Seiten zum Anlegen eines Nutzerprofils).

2. Prüfung

Bei Eingabefeldern, die sich auf Daten des Nutzers beziehen, mittels Developer Tools den Code inspizieren. Prüfen, ob autocomplete-Werte definiert sind oder andere unterstützte Taxonomien den Eingabezweck angeben - bei Nutzung von autocomplete vergl. WCAG 2.1, Abschnitt 7 Input Purposes for User Interface Components. Prüfen, ob die korrekten Werte verwendet wurden (das autocomplete-Attribut tel etwa sollte nicht für eine Kreditkartennummer verwendet werden).

3. Hinweis

Die Anforderung gilt nur für Felder, die sich auf den Nutzer selbst beziehen. Sie gilt nicht für Seiten, auf denen die Eingabe von persönlichen Daten mehrerer Personen möglich ist und die Felder für den Nutzer selbst nicht besonders gekennzeichnet sind. Ein Beispiel dafür sind Ticketbuchungsseiten von Fluglinien. Hier sind die Eingabefelder für den Nutzer nicht von den Feldern für Mitreisende unterscheidbar.

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

3. Hinweise

Es gibt verschiedene Arten, Information nicht nur über Farbe zu vermitteln:

• Ein Menüeintrag ist farblich hervorgehoben, aber ein Breadcrumb nennt zusätzlich, welche Seite ausgewählt ist

• Ein Menüeintrag ist farblich hervorgehoben, aber es gibt zusätzlich eine gleichlautende Überschrift, die dem Menüeintrag jeweils entspricht

• Ein Icon wechselt die Farbe, aber es ändert sich außerdem die nachfolgende Beschriftung

• Ein Bedienelement ändert bei Fokussierung die Farbe, aber es kommt zusätzlich ein äußerer Rahmen hinzu, der ausreichend zum Hintergrund kontrastiert

• Ein Bedienelement ändert bei Fokussierung die Farbe, aber der Kontrast zur vorherigen Farbe beträgt mindestens 3:1.

• Farbumkehr ausreichend kontrastreicher Elemente: Vorder- und Hintergrundfarbe eines Elements werden bei Fokussierung oder Aktivierung ausgetauscht

4. Bewertung

Abgrenzung zu anderen Prüfschritten

Einordnung des Prüfschritts nach WCAG 2.2

Häufig werden besuchte Links in einer anderen Farbe dargestellt. Fällt das auch unter diesen Prüfschritt?

Die Unterscheidung besuchter und nicht besuchter Links ist hilfreich. Der Benutzer kann gleich sehen, welche Seiten er schon besucht hat. Ideal wäre es daher, wenn besuchte Links zum Beispiel zusätzlich durch eine andere Unterstreichung markiert würden.

Aber die verfügbaren Gestaltungsmöglichkeiten sind begrenzt. Und zu viele unterschiedliche Kennzeichnungen von Links können auch Verwirrung stiften.

In diesem Prüfschritt des BITV-Tests wird die Kennzeichnung besuchter Links nicht berücksichtigt, sie ist für die Bewertung nicht relevant.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn nach dem Laden einer Seite Tonelemente auf einer Webseite automatisch länger als drei Sekunden abgespielt werden.

2. Prüfung

Wenn nach Laden der Seite ein Tonelement automatisch abgespielt wird:

• Prüfen, ob der Ton länger als 3 Sekunden dauert.

• Wenn das der Fall ist: Prüfen, ob sich am Seitenbeginn ein Mechanismus (Button, Link, oder Lautstärke-Regler) befindet, mit dem sich der Ton abschalten oder unabhängig von der Systemlautstärke herunter regeln lässt.

• Den Mechanismus bedienen und den Ton abschalten.

Wenn sich die Lautstärke regeln lässt:

• Das Kontrollelement "Sound" aufrufen: Windows-Menü _Start > Alle Apps > Windows System > Systemsteuerung (> Kategorie Hardware und Sound) > Sound_In der Registerkarte "Wiedergabe" die Eigenschaften des Lautsprechers aufrufen und den "Pegel" (in gleichnamiger Registerkarte) anzeigen.

• Ton wieder anschalten oder Seite neu laden, dann die Lautstärke ganz herunterregeln. Ist der Ton verschwunden?

• Prüfen, ob der Lautstärkeregelung durch den Mechanismus unabhängig von der Systemtonlautstärke ist (Die Lautstärkeeinstellung in "Sound" soll unverändert bleiben). Alternativ kann die Systemlautstärke auch über den das Lautsprechersymbol im einblendbaren Infobereich der Taskleiste geprüft werden.

3. Hinweise

• Töne, die nicht nach kurzer Zeit enden, können auch die Verständlichkeit der Sprachausgabe des Abschaltmechanismus stören. Deshalb wird auch berücksichtigt, wie störend sich der Ton auswirkt. Sprache oder laute Geräusche etwa stören mehr als eine gleichmäßige Hintergrundmusik.

• Der Mechanismus zum Herunterregeln des Tones darf nicht die Systemtonlautstärke ändern, da dies auch die Tonausgabe von Hilfsmitteln mit Sprachausgabe beeinträchtigen würde.

• Der Mechanismus zum Abschalten oder Herunterregeln des Tons muss sich am Seitenbeginn befinden und soll selbst alle Anforderungen an Barrierefreiheit erfüllen, also etwa ausreichende Kontraste haben und tastaturbedienbar sein.

• Wenn sich der Ton herunterregeln lässt, soll er auf der niedrigsten Stellung des Reglers nicht mehr hörbar sein.

• Es reicht zur Erfüllung dieses Prüfschritts nicht aus, wenn sich der Ton über Tastaturbefehle (etwa die Escape-Taste) abschalten lässt. Diese Funktion kann sinnvoll sein, wird aber von vielen Nutzern nicht vermutet.

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

Bedeutung der Tonabschaltung nach WCAG 2.2

( Audio Control: Understanding SC 1.4.2)

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Seite Text enthält. Grafische Schriften sind ebenfalls Gegenstand des Prüfschritts.

2. Prüfung

3. Hinweise

4. Bewertung

Abgrenzung zu anderen Prüfschritten

• Prüfschritt 9.1.4.11 "Kontraste von Grafiken und grafischen Bedienelementen ausreichend" behandelt den Kontrast von Grafiken

• Schriftgrafiken (zur Definition vergleiche auch Prüfschritt 9.1.4.5 "Verzicht auf Schriftgrafiken"

Einordnung des Prüfschritts nach WCAG 2.2

W3C zum Zusammenhang zwischen px und pt

CSS Values and Units Module Level 3: 5.2 Absolute Lengths

Subjektiver Eindruck bei Kontrastmessungen

Das Ergebnis der WCAG 2.1 Formel zur Messung des Kontrastverhältnisses entspricht oft nicht dem subjektiven Eindruck. Wie zuverlässig ist es?

Zwei Punkte sind hier zu beachten:

Der Helligkeitskontrast ist nur einer von drei Einflussgrößen für den Gesamtkontrast. Insofern ist klar, dass das Ergebnis für den Helligkeitskontrast nicht dem subjektiven Eindruck entspricht. Es soll gar nicht dem subjektiven Gesamteindruck entsprechen, denn schließlich geht es darum, ob die Helligkeitsunterschiede der Farben für sich genommen ausreichend kontrastieren. Wenn man normalsichtig ist, entspricht der subjektive Eindruck der Graustufenansicht dagegen schon eher dem Formelergebnis. Farben benachbarter Flächen beeinflussen die Wahrnehmung, kleine und dünne Schriften erscheinen kontrastärmer, es gibt Überstrahleffekte, möglicherweise werden die Kontraste durch Schriftenglättung abgeschwächt. Die Formel berücksichtigt all diese Faktoren nicht. Zumindest wenn es um Texte geht, ist dies auch angemessen. Denn die genannten Einflüsse stehen nicht fest, sie hängen zum Beispiel von der gewählten Schriftgröße ab.

Für die Prüfung bedeutet das: Wer mit der formelbasierten Bewertung von Helligkeitskontrasten noch keine Erfahrungen hat, kann sich nicht auf seinen subjektiven Eindruck verlassen. Er muss die Formel fast auf alle Farbkombinationen anwenden.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Seite Text enthält.

2. Prüfung

3. Hinweise

4. Bewertung

Abgrenzung zu anderen Prüfschritten

• Mangelnde Vergrößerbarkeit von Schriftgrafiken: siehe Prüfschritt 9.1.4.5 "Verzicht auf Schriftgrafiken"

Einordnung des Prüfschritts nach WCAG 2.2

WCAG 2.1 über die Skalierung von Text

( Resize text: Understanding SC 1.4.4)

Die WCAG 2.1 zur Nutzung absoluter und relativer Maßeinheiten für Text

(WCAG 2.1 Technik C14: Using em units for font sizes)

Die Vergrößerung der Schrift ist weniger wichtig, wenn die Ausgangsschriftgrößen der Webseite bereits groß genug sind, sollte das nicht berücksichtigt werden?

Der BITV-Test berücksichtigt die tatsächlichen Schriftgrößen nicht, geprüft wird nur die Änderbarkeit. Für Seiten mit großen Ausgangsschriften (oder für Seiten, die in großen Schritten vergrößern) ist die Prüfanforderung also nicht so leicht zu erfüllen.

Die Begründung:

Die BITV verlangt keine Mindestgröße für Schriften. Und was wichtiger ist: es gibt unterschiedliche Auffassungen zur der Frage, wie groß Ausgangsschriftgrößen sein sollen:

• Idealerweise wären die Ausgangsschriftgrößen aller Webangebote ähnlich. Denn dann könnte jeder Benutzer in seinem Browser die für ihn passende Schriftgröße einstellen. Diese Einstellung müsste nicht geändert werden, sie wäre für alle Webangebote passend.

• Sehr große Ausgangsschriften sind unter Umständen nicht gut zu nutzen. Und zwar auch für Benutzer, die große Schriften brauchen. Denn diese Benutzer haben ihren Computer oder ihren Browser meist schon so eingerichtet, daß Schriften größer dargestellt werden. Die extrem große Ausgangsschrift ist dann zu viel des Guten.

Die Orientierung an im Web üblichen Schriftgrößen ist also sinnvoll. Aber auch große Ausgangsschriften sind vorteilhaft. Auch für Besucher, die nicht wissen, wie man die Schrift vergrößert, sind sie groß genug.

Am besten ist es also, wenn sich Webangebote an der Obergrenze der im Web üblichen Schriftgrößen orientieren.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das Webangebot Schriftgrafiken enthält.

2. Prüfung

1. Die Seite im Firefox aufrufen.

2. In der Web Developer Toolbar die Funktion Bilder > Bilder deaktivieren > Alle Bilder deaktivieren aufrufen, um alle Grafiken auszublenden (oder alternativ Bilder > Bilder mit ALT-Attributen ersetzen).

3. Prüfen, ob dadurch Schrift verschwindet.

3. Hinweise

In der Regel nicht negativ bewertet werden grafische Schriften auf Logos oder in Fotos.

Ebenfalls nicht negativ bewertet wird, wenn das SVG text-Element in Inline-SVGs verwendet wird.

Bei Schriftgrafiken, die den Informationsinhalt im Kontext auch als Text wiedergeben, kann dieser Text als konforme Alternativversion der Schriftgrafik gelten. Das ist zum Beispiel der Fall, wenn Abbildungen von Broschüren, Plakaten oder ähnlichen Dokumenten, die Text im Bild enthalten, als Teaser-Bild verwendet werden und der Titel der Broschüre ebenfalls unmittelbar darunter, darüber oder daneben als Text zu lesen steht.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

Die Bereitstellung von Alternativtexten für Schriftgrafiken ist Gegenstand der Prüfschritte 9.1.1.1a "Alternativtexte für Bedienelemente" und 9.1.1.1b "Alternativtexte für Grafiken und Objekte".

Einordnung des Prüfschritts nach WCAG 2.2

Wie ist es mit der Darstellung von Schriftzeichen, die nicht auf allen Computern zur Verfügung stehen? Also zum Beispiel arabische Schriftzeichen: sollten dafür nicht besser Grafiken verwendet werden?

Moderne Betriebssysteme stellen die Schriftzeichen aller verbreiteten Sprachen zur Verfügung. In aller Regel sind Schriftzeichen, mit denen ein möglicher Nutzer etwas anfangen könnte, auch installiert. Die grafische Darstellung von Schriftzeichen ist daher nur als zusätzliches Angebot sinnvoll.

Im BITV-Test wird nur geprüft, ob Text in Form von Text verfügbar ist. Zusätzliche grafische Angebote werden nicht berücksichtigt.

Was ist mit auf Fotos abgebildeten Schriften?

Schriftgrafiken sollen nicht verwendet werden, weil die Darstellung des Textes dann nicht mehr flexibel ist. Bei abgebildeten Schriften, also zum Beispiel bei Fotos mit Ladenschildern sind Inhalt und Darstellung zusammengehörig. Dieser Prüfschritt ist also nicht anwendbar.

Davon ausgenommen sind allerdings Abbildungen, die wie Schriftgrafiken verwendet werden, also zum Beispiel als Überschriften dienen.

Oft ist es nicht möglich, auf Schriftgrafiken zu verzichten, denn das Corporate Design gilt auch für den Webauftritt, und die für Texte verfügbaren Schrifttypen passen nicht.

Sicher gibt es gute Gründe für den Einsatz von Schriftgrafiken. Der Einsatz von Schriftgrafiken ist aber auf der anderen Seite aus Sicht der Barrierefreiheit problematisch. Es muss also entschieden werden, ob das einheitliche Corporate Design wichtiger ist, als die barrierefreie Zugänglichkeit des Webauftritts. Wenn die barrierefreie Zugänglichkeit der im Webauftritt bereitgestellten Inhalte Priorität haben soll, wird es erforderlich sein, das Corporate Design anzupassen oder auf seinen durchgängigen Einsatz zu verzichten.

Wie wird Text in Firmenlogos bewertet?

In diesem Prüfschritt geht es um die Verwendung von grafischen Schriften für Texte, Überschriften und Bedienelemente. Das Firmenlogo ist nicht relevant, so lange es nicht (oder nur zusätzlich) als Überschrift oder Bedienelement eingesetzt wird.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist für Webinhalte anwendbar, wenn deren Ausgangsbasis für Zugänglichkeit die üblichen Desktop-Browser mit eingebauter Zoomfunktion einschließt. Er ist nicht anwendbar bei der Nutzung von Browsern mobiler Betriebssysteme, deren eingebaute Zoomvergrößerung (etwa über eine Spreizgeste) in der Regel keine Vergrößerung mit Inhaltsumbruch bieten.

2. Prüfung

3. Hinweise

• Inhalte und Funktionen müssen in der Umbruch-Ansicht nicht in der gleichen Weise angeboten werden. Sie können etwa auch in einem Ausklappbereich oder über einen direkten Link erreichbar sein.

• Bei der alternativen Prüfung mit 1280px Viewport-Breite und 400% Zoom soll nicht negativ bewertet werden, wenn fest positionierte Inhalte (etwa Ausklappmenüs) aufgrund der sehr geringen verfügbaren Höhe des Browser-Fensters nicht voll erreichbar sind. Geprüft wird allein, ob Inhalte erfolgreich in eine Ansicht umbrechen, die nicht horizontal gescrollt werden braucht. Zur Prüfung des Verlusts von Informationen und Funktionalität ist die Prüfung bei 320px Viewport-Breite ausschlaggebend.

• Ausnahmen für die Anforderung, dass horizontales Scrollen nicht erforderlich ist, sind Inhalte, deren Nutzung ein zweidimensionales Layout voraussetzen, etwa Datentabellen, Bilder, Diagramme, Videos, Spiele oder Benutzerschnittstellen mit Werkzeugleisten.

• Optionen in geöffneten select-Elementen, die nicht in den Viewport passen, gelten nicht als Fehler im Sinne dieses Prüfschritts.

• Im Prüfschritt wird nicht geprüft, ob die Zoomvergrößerung auf 400% Textinhalte tatsächlich auf 400% oder einen geringeren Wert vergrößert. Dies ist Gegenstand von Prüfschritt 9.1.4.4 "Text auf 200% vergrößerbar".

• Für Unternehmen, die Bestandssysteme verwenden oder ihre Layoutmethoden aus irgendeinem Grund nicht aktualisieren können, kann eine alternative, konforme Version eine mobile Website mit einem festen, 320px breiten Layout sein. Der Benutzer sollte in der Lage sein, diese Version von der Standardwebsite aus zu finden.

4. Bewertung

Abgrenzung von anderen Prüfschritten

In diesem Prüfschritt geht es darum, ob Inhalte beim Reinzoomen oder in schmalen Viewports ohne Verlust von Information in eine einspaltige Ansicht umbrechen. Die Vergrößerbarkeit von Schrift wird dagegen in Prüfschritt 9.1.4.4 "Text auf 200% vergrößerbar" bewertet.

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn informationstragende grafische Bedienelemente, die nicht lediglich ergänzend (etwa zu Text) eingesetzt werden, oder informationstragende Grafiken vorhanden sind.

Nicht anwendbar ist der Prüfschritt auf Fotos, Logos, Flaggen, Screenshots, Diagramme mit Farben, die nicht geändert werden dürfen, und Datenvisualisierungen mit Farbabstufungen wie etwa Heatmaps.

Ebenfalls nicht anwendbar ist der Prüfschritt auf native grafische Bedienelemente, die in ihrem Erscheinungsbild nicht durch den Autor beeinflusst wurden, etwa native HTML-Checkboxen, sowie auf inaktive Bedienelemente, also solche, die zustandsabhängig für die Interaktion nicht zur Verfügung stehen.

2. Prüfung

Hinweis: Für die aufgeführten Prüfungen 2.2 bis 2.4 ist eine Sichtprüfung ausreichend, wenn der Kontrast sehr deutlich über 3:1 liegt. Im Zweifelsfall immer den Color Contrast Analyzer einsetzen.

3. Hinweise

Abgrenzung von anderen Prüfschritten

In diesem Prüfschritt geht es um die Kontraste von Grafiken und grafischen Attributen wie Umrisslinien. Der Kontrast von Schrift, einschließlich der von Schriftgrafiken, wird in Prüfschritt 9.1.4.3 "Kontraste von Texten ausreichend" bewertet.

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Seite echten Text enthält (also Text, der nicht über eine Grafik bereitgestellt wird).

2. Prüfung

1. Textabstände mit dem Bookmarklet Textabstände oder mit einer Browser-Erweiterung setzen. Die Werte für Zeilenhöhe, Abstand nach Absätzen, Buchstabenabstand und Wortabstand werden auf die maximal geforderten Werte gesetzt.

2. Prüfen, ob es durch die neuen Werte zum Abschneiden oder Überlappen von Text oder den Verlust von Funktionalität kommt.

3. Hinweise

• Die Anforderung ist nicht anwendbar auf HTML-Standardelemente wie input type="file" oder Optionen einer Ausklappliste (<select>). Die CSS-Anpassungen haben keine Auswirkung auf diese Elemente.

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Seite zusätzliche Inhalte enthält, die bei Fokussierung mittels Tastatur oder Zeiger eingeblendet werden, etwa Custom-Tooltips oder Ausklapp-Menüs, die bereits bei Fokussierung ausklappen.

2. Prüfung

3. Hinweise

Bei Inhalten, die durch Tastaturfokussierung von Elementen eingeblendet werden, wird nicht verlangt, dass hier Mauszeiger über die eingeblendeten Inhalte bewegt werden kann, ohne dass diese sich schließen.

Wenn Aktivierung des Elements, dass den Inhalt einblendet, zum Schließen des eingeblendeten Inhalts benutzt wird, soll der Nutzer-Kontext bestehen bleiben (also nicht eine weitere Aktion, die den Kontext ändert, ausgelöst werden, etwa das Aktivieren eines Links).

Wenn Inhalte durch Hover eingeblendet werden, sollten sie in der Regel auch bei Tastaturfokus eingeblendet werden, falls sie nicht alternativ zur Verfügung gestellt werden. Dies wird in Prüfschritt 9.2.1.1 "Ohne Maus nutzbar" geprüft.

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn der Webauftritt interaktive Elemente enthält.

2. Prüfung

1. Seite im Firefox Browser aufrufen.

2. Mit der Tabulatortaste die Links und Formularelemente durchgehen.

3. Prüfen, ob alle wesentlichen Links und Formularelemente erreicht und benutzt werden können

4. Falls die Seite Elemente enthält, die wie Bedienelemente aussehen, jedoch nicht mit der Tabulatortaste angesteuert werden, prüfen, ob diese Elemente auf die Maus reagieren (zum Beispiel mit Bewegung, Vergrößerung, Einblenden von weiteren Inhalten).

5. Falls die Seite scrollbare Bereiche enthält, sollen nicht sichtbare Inhalte dieser Bereiche auch über die Tastatur erreichbar sein.

6. Seite im Chrome Browser aufrufen und Schritte 2 bis 5 wiederholen.

3. Hinweise

4. Bewertung

Abgrenzung zu anderen Prüfschritten

• Dieser Prüfschritt betrifft die Auslösbarkeit von Funktionen und Links auch über die Tastatur.

• Tastaturfallen sind Gegenstand von Prüfschritt 9.2.1.2 "Keine Tastaturfalle"

• Bei skriptgenerierten oder über Skripts eingeblendeten Elementen (etwa ausklappenden Texten oder Lightboxen) ist die sinnvolle Reihenfolge im Quellcode Gegenstand von Prüfschritt 9.1.3.2 "Sinnvolle Reihenfolge".

• Die Fokushervorhebung ist Gegenstand von Prüfschritt 9.2.4.7 "Aktuelle Position des Fokus deutlich".

• In diesen Prüfschritt spielt die Fokus-Reihenfolge, in der Links und Formularelemente angesteuert werden, keine Rolle. Die Sinnvolle Fokusreihenfolge wird in 9.2.4.3 "Schlüssige Reihenfolge bei der Tastaturbedienung" bewertet.

Einordnung des Prüfschritts nach WCAG 2.2

Die WCAG 2.1 zur Tastaturbedienbarkeit

( Keyboard Accessible: Understanding Guideline 2.1)

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

1. Seite im Firefox Browser aufrufen.

2. Mit der Tabulatortaste die Links und Formularelemente durchgehen. Prüfen, ob alle Links und Formularelemente erreicht und wieder verlassen werden können.

3. Seite in Chrome aufrufen und Schritte 1 bis 2 wiederholen.

3. Hinweise

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

1. Seite neu laden.

2. Wenn dies den Fokus auf ein Interface-Element setzt (z. B. auf ein Eingabefeld), auf einen leeren Bereich der Seite klicken, um sicherzustellen, dass keine Interface-Elemente fokussiert sind.

3. Mit Ausnahme der Modifikator- und Steuertasten wie STR, ALT, ENTER, Tab, Pfeiltasten und Funktionstasten F1-F12, nacheinander auf alle Tastaturtasten drücken, d. h. auf alle Nummern- Buchstaben-, Symbol- und Zeichensetzungs-Tasten.

4. Die Umschalttaste halten und die gleichen Tasten erneut betätigen.

5. Falls einzelne Tasten Funktionen auslösen, prüfen, ob die Website oder App Einstellungen bereithält, um diese Tastaturkurzbefehle über Einzeltasten abzuschalten oder auf Tastaturkurzbefehle mit einer Modifikator-Taste zu mappen.

3. Hinweise

Die Anforderung gilt nicht, wenn die Tastaturkurzbefehle nur aktiv sind, sobald bestimmte Interface-Elemente den Fokus haben, etwa ein Auswahllisten-Element bzw. `select`Hier dient z. B. das Drücken einer Buchstabentaste zur schnellen Navigation innerhalb der Auswahllisten-Optionen.

Über das Anzeigen von Seitenskripten und das Suchen nach typischen Tastatur-Event-Handlern wie document.addEventListener oder das Vorhandensein der .keycode-Eigenschaft lässt sich ggf. das Vorhandensein von Skripten überprüfen, welche auf Tasteneingaben reagieren, bei denen nicht Modifikator-Tasten wie ALT oder STR gleichzeitig gedrückt werden. Da es mehrere Möglichkeiten gibt, Tastatur-Events zu implementieren, ist diese Methode aber nicht als zuverlässig zu betrachten.

Einige Browser verwenden Tastenkombinationen mit der Umschalttaste. So öffnet Firefox eine Seitensuche, wenn man Umschalttaste + / drückt, und eine Suche in Seitenlinks, wenn man Umschalttaste + ' drückt. In diesen Fällen ist es notwendig, die ESC-Taste zu drücken oder auf einen leeren Teil der Seite zu klicken, um den Fokus aus der Browser-Sucheingabe zu entfernen.

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

Das eingebundene Video reagiert auf Tastaturkurzbefehle über Einzeltasten, z.B: "k" zum Pausieren/Abspielen und "m" zum Stummschalten. Ist das als Verstoß gegen 2.1.4 "Tastatur-Kurzbefehle abschaltbar oder anpassbar" zu werten?

Diese Tastaturkurzbefehle sind für Tastaturnutzer zweifellos hilfreich. Ob dadurch Nachteile für Spracheingabenutzer entstehen, versuchen wir zur Zeit zu klären. Noch offen ist, ob ein Video als User Interface Component im Sinne der normativen Anforderung interpretiert werden kann. Es gibt dazu eine längere Diskussion in dem Github-Issue der Accessibility Guidelines Working Group. Solange diese Frage nicht klar entschieden ist, sollten Tastaturkurzbefehle auf fokussierten Videos nicht als Fehler bewertet werden.

1. Anwendbarkeit des Prüfschritts

• Die Prüfung auf Auto-Aktualisierung und Weiterleitung (Abschnitt 2.1 Prüfung auf Auto-Aktualisierung durch Neu-Laden der Seite und Weiterleitung auf andere URL) ist immer anwendbar.

• Die Prüfung auf Abschaltbarkeit oder Verlängerbarkeit von Zeitbegrenzungen (Abschnitt 2.2 Prüfung auf Abschaltbarkeit oder Verlängerbarkeit von Zeitbegrenzungen) ist immer anwendbar.

• Die Prüfung von Zeitbegrenzungen bei wichtigen Statusmeldungen ist immer anwendbar, wenn (oft als Ergebnis einer Interaktion) Meldungen erscheinen und nach einer Zeitspanne (meist nach wenigen Sekunden) automatisch wieder verschwinden.

2. Prüfung

3. Hinweise

4. Bewertung

Abgrenzung von anderen Prüfschritten

Dieser Prüfschritt 9.2.2.1 betrifft Zeitbegrenzungen, welche die ganze Seite betreffen, unabhängig davon, ob die zeitbegrenzten Inhalte bewegt sind (also ablenken) oder nicht. Geprüft wird, ob solche Zeitbegrenzungen abschaltbar oder verlängerbar sind.

Der Prüfschritt 9.2.2.2 "Bewegte Inhalte abschaltbar" betrifft dagegen bewegte oder autoaktualisierte Inhalte, die Nutzer ablenken oder durch ihren vorgegebenen zeitlichen Ablauf für bestimmte Nutzer schwierig wahrnehmbar sind. Hier wird geprüft, ob Nutzer die Möglichkeit haben, bewegte oder autoaktualisierte Inhalte anzuhalten oder auszublenden.

Wenn es ein Kontrollelement oder einen dokumentierten Tastaturbefehl gibt, um Zeitbegrenzungen abzuschalten oder zu verlängern, wird in diesem Prüfschritt lediglich geprüft, ob Nutzer genügend Zeit haben, diesen Mechanismus zu finden und zu nutzen. In anderen Prüfkriterien wird geprüft, ob der Mechanismus selbst zugänglich und verständlich ist (etwa in 9.2.1.1 "Ohne Maus nutzbar" oder 9.1.3.1h "Beschriftung von Formularelementen programmatisch ermittelbar").

Einordnung des Prüfschritts nach WCAG 2.2

Wie kann durch ein Kontrollelement auf der Webseite sichergestellt werden, dass der Benutzer eine Zeitbegrenzung oder Autoaktualisierung auf Wunsch abschalten kann?

Wichtig ist, dass die Autoaktualisierung oder das Ende der Zeitbegrenzung nicht erfolgen, bevor der Benutzer auf ein entsprechendes Kontrollelement zum Abschalten gestoßen ist. Daher sollte die Schaltfläche oder der Link zum Abschalten oder Verlängern am Seitenbeginn oder nahe am Seitenbeginn angezeigt werden, damit er von Menschen mit verschiedensten Behinderungen auch gefunden und aktiviert werden kann.

Dennoch ist nicht sicher, dass Benutzer die Option zum Abschalten der Autoaktualisierung oder Zeitbegrenzung finden und verstehen.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar, wenn bewegte Inhalte gleichzeitig mit anderen nicht bewegten Inhalten (etwa die Navigation oder statische Inhalte) dargestellt werden.

Nicht anwendbar ist der Prüfschritt auf essenziell wichtige Aktualisierungen von Inhalten, zum Beispiel, wenn die verbleibende Zeit einer Session heruntergezählt wird oder die Höhe eines Auktionsgebots dynamisch aktualisiert wird.

2. Prüfung

Falls die Seite blinkende, bewegte oder automatisch aktualisierte Inhalte enthält, zum Beispiel Nachrichten-Aufmacher (Teaser), laufende Texte, oder animierte Werbung:

1. Prüfen, ob die Bewegung innerhalb von 5 Sekunden nach Anzeige der Seite von selbst aufhört.

2. Falls das nicht der Fall ist: Feststellen, ob sich auf der Seite eine Schaltfläche befindet, mit der man die Bewegung stoppen kann, eine gleichwertige nicht-animierte Version der Seite laden kann, oder ob es eine klare Anweisung gibt, wie die Bewegung mit der Tastatur angehalten werden kann.

3. Prüfen, ob das Aktivieren der Schaltfläche oder des Tastatur-Shortcuts die Bewegung tatsächlich anhält und sie auch nicht wieder von allein erneut beginnt.

Zusätzlich sollte geprüft werden, ob das erneute Aktivieren der Schaltfläche die Bewegung wieder in Gang setzt, und zwar (bei Videos oder Animationen) von dem Punkt aus, der beim letztem Anhalten erreicht wurde. Ist das nicht der Fall, sollte dies angemerkt werden. Dieser Mangel ist aber nicht als Verstoß gegen die Anforderung dieses Prüfschritts zu verstehen.

3. Hinweise

Die Schaltfläche oder die Anweisung, mit der man die Bewegung anhalten kann, muss eindeutig sein und deutlich sichtbar am Seitenbeginn oder im direkten Kontext des bewegten Inhalts platziert sein.

Alle Inhalte müssen nach dem Anhalten der Bewegung verfügbar bleiben.

Es spielt keine Rolle, ob es sich bei den blinkenden oder sich bewegenden Inhalten um Werbung oder um redaktionelle Inhalte handelt.

4. Bewertung

Abgrenzung der Prüfschritte 9.2.2.1 und 9.2.2.2

Dieser Prüfschritt 9.2.2.2 betrifft bewegte Inhalte, die Benutzer ablenken oder durch ihren vorgegebenen zeitlichen Ablauf für bestimmte Benutzer schwierig wahrnehmbar sind. Hier wird geprüft, ob Benutzer die Möglichkeit haben, bewegte Inhalte anzuhalten oder auszublenden.

Der Prüfschritt 9.2.2.1 "Zeitbegrenzungen anpassbar" betrifft Zeitbegrenzungen, welche die ganze Seite betreffen, unabhängig davon, ob die zeitbegrenzten Inhalte bewegt sind (also ablenken) oder nicht. Geprüft wird, ob solche Zeitbegrenzungen abschaltbar oder verlängerbar sind.

Zur Abgrenzung von Blinken und Flackern siehe Abschnitt "Quellen" bei Prüfschritt 9.2.3.1 "Verzicht auf Flackern".

Einordnung des Prüfschritts nach WCAG 2.2

Die WCAG 2.1 zum Anhalten und Fortsetzen bei aufgezeichneten Inhalten und Echtzeit-Inhalten

( Pause, Stop, Hide: Understanding SC 2.2.2)

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

Gibt es auf der Webseite flackernde Inhalte, die nicht spätestens nach dreimaligem Flackern in einem Zeitraum von einer Sekunde aufhören?

Zur Einschätzung der Größe des flackernden Bereichs kann, wenn nötig, die WCAG 2.1 Formel 1 herangezogen werden.

3. Hinweis zur Abwertung

Wenn die Seite größere flackernde Elemente enthält, wird das Gesamtergebnis der Prüfung abgewertet. Flackern wird dadurch hervorgerufen, dass die Farbe oder das Muster einer Fläche pro Sekunde mindestens 4 mal wechselt.

Einordnung des Prüfschritts nach WCAG 2.2

Die WCAG 2.1 zu General flash and red flash thresholds

( Three Flashes or Below Threshold: Understanding SC 2.3.1)

Die WCAG 2.1 zur Abgrenzung von Blinken und Flackern

( Pause, Stop, Hide: Understanding SC 2.2.2)

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn es auf der Seite deutlich voneinander abgegrenzte Bereiche gibt, etwa Navigation und Inhalt. Das ist bei informationsorientierten Seiten meist der Fall.

2. Prüfung

3. Hinweise

4. Bewertung

Abgrenzung zu anderen Prüfschritten

• In diesem Prüfschritt geht es um die Auszeichnung der Seitenbereiche mit Überschriften, Sprunglinks und WAI-ARIA-Attributen (landmarks). Die inhaltliche Strukturierung von Seiteninhalten wird in Prüfschritt 9.1.3.1a "HTML-Strukturelemente für Überschriften" geprüft.

• In diesem Prüfschritt wird geprüft, ob iframes (wenn vorhanden) aussagekräftige Titel haben. Die Inhalte von iframes werden ebenso geprüft wie andere Seiteninhalte, etwa in Prüfschritt 9.1.3.1d "Inhalt gegliedert".

Einordnung des Prüfschritts nach WCAG 2.2

WCAG 2.1 Hinweis zum Unterschied von name und title

( H64: Using the title attribute of the frame and iframe elements)

WCAG 2.1 Verknüpfung von WAI ARIA document landmarks und Text

( ARIA13: Using aria-labelledby to name regions and landmarks)

Ergänzung von HTML5 Elementen mit WAI ARIA

Script, das bei HTML5 Elementen automatisch ARIA-Rollen ergänzt: Polyfill accessifyhtml5.js von Yatil

Müssen die Bereiche der Webseite durch h1-Überschriften ausgezeichnet werden?

Bei den meisten Webangeboten sind bestimmte Bereiche durchgängig für die Navigation reserviert. Andere wiederkehrende Bereich können etwa die Suche oder der Seitenkopf sein. Diese Bereiche sind auf allen Seiten des Angebots gleich aufgebaut und gestaltet. Sie haben keinen engen Bezug zum besonderen Seiteninhalt, sind eigentlich nicht den einzelnen Seiten, sondern eher dem Webauftritt als ganzen zuzurechnen. Es liegt daher nahe, die Navigation, den Inhaltsbereich und weitere klar abgegrenzte Bereiche der Seite jeweils mit einer h1-Hauptüberschrift zu versehen.

Es gibt jedoch auch andere Möglichkeiten, Seitenbereiche auszuzeichnen, etwa durch h5- oder h6-Überschriften, falls diese in der Gliederung der Seiteninhalte nicht verwendet werden (vergleiche den Artikel auf einfach-für-alle: "Passende Überschrift hier einsetzen")

Vom BITV-Test werden unterschiedliche Herangehensweisen akzeptiert. Es muss in jedem Fall geprüft werden, ob Überschriften konsistent eingesetzt werden, um die Seiten-Bereiche und deren Inhalte zu erschließen.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

1. Dokumenttitel in der Browserleiste ansehen.

2. Bezeichnet der Titel den Inhalt der individuellen Seite und ggf. auch das Webangebot? Ist er für die Unterscheidung und Auswahl von Seiten geeignet?

Falls Seiten Frames haben:

1. Einzelne Frames in neuem Tab oder Fenster öffnen.

2. Dokumenttitel in der Browserleiste ansehen. Haben die Frame-Seiten sinnvolle Titel, die Zweck oder Inhalt des Frames kennzeichnen?

3. Hinweise

Der Dokumenttitel muss nicht den Pfad von der Startseite zur aktuellen Seite wiedergeben. Ein guter Dokumenttitel "vertritt" die Seite zum Beispiel in einer Bookmarks-Liste. Es ist daher sinnvoll, nicht nur den Inhalt der Seite, sondern auch das Webangebot selbst zu nennen. Die Nennung des Angebots ist in der Regel an zweiter Stelle sinnvoll: Der erste Teil benennt die Seite selbst, der zweite das Angebot und damit den Kontext der Seite.

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.2

Bedeutung von Dokumenttiteln nach WCAG 2.1

( Page Titled: Understanding SC 2.4.2)

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Seite Links, Formularelemente oder Objekte (z. B. Menüs oder Dialoge, die nach Interaktion eingeblendet werden) enthält.

2. Prüfung

1. Seite im Firefox Browser laden.

2. Mit der Tabulatortaste die Links, Formularelemente und Objekte durchgehen und prüfen, ob die Reihenfolge im Wesentlichen nachvollziehbar ist.

3. Seite in Chrome aufrufen und die Prüfung wiederholen.

3. Hinweise

• Die Tabulatorreihenfolge sollte im Wesentlichen der visuellen Anordnung auf dem Bildschirm folgen. Kleinere Abweichungen sind kein Problem, manchmal ist es ja auch gar nicht möglich, aus der Anordnung auf dem Bildschirm eine Reihenfolge zwingend abzuleiten.

• Die Tabulatorreihenfolge ist schwer nachzuvollziehen, wenn sie über unsichtbare ausführbare Elemente geht. Das betrifft insbesondere aufeinander folgende nicht sichtbare Sprunglinks.

• Wenn die Tabulatorreihenfolge nicht gut erkennbar ist, weil z. B. die Fokushervorhebung unterdrückt wird, ist das Bookmarklet Show Tab Focus von Jeff Smith ein hilfreiches Werkzeug zum hervorheben der aktuellen Position.

• Die Prüfung erfolgt bei eingeschaltetem JavaScript.

• Der Prüfer muss mit der Funktionsweise der eingesetzten Browser vertraut sein, er muss wissen, welche Tasten und Tastenkombinationen für die Tastaturbedienung vorgesehen sind.

  Wichtig in diesem Zusammenhang: Die Felder von Formularen können ggf. trotz korrekter Auszeichnung unter Umständen nicht mit der Tabulatortaste durchwandert werden. Wenn das Browserfenster nicht den Fokus hat, darf man nicht einfach hineinklicken und dann erst mit der Tastaturbedienung anfangen. Der Fokus muss vielmehr per Tastatur (F6) zum Browserfenster bewegt werden. Auswahllisten ohne Submit-Button, die auf onchange reagieren, können ggf. mit den Pfeiltasten allein nicht bedient werden, da immer schon die erste Listenoption ausgelöst wird. Um solche Auswahllisten durchzublättern, muss man sie ggf. zunächst mit der Tastenkombination "ALT + Pfeil nach unten" öffnen. Dann kann man mit den Pfeiltasten nach oben und unten durch die Optionen blättern und mit der Eingabetaste eine Option auswählen.

• Die ARIA Authoring Practices Guide (APG) bieten eine Orientierung, welche Fokusreihenfolge / welches Fokusmanagement bei bestimmten Widget-Typen zu erwarten ist.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

• In diesem Prüfschritt wird die Tabreihenfolge geprüft, egal, ob diese der Anordnung fokussierbarer Elemente im Quellcode entspricht oder über tabindex und Skripte erzeugt wird.

• Die grundsätzliche Erreichbarkeit und Auslösbarkeit von interaktiven Elementen ist Gegenstand von Prüfschritt 9.2.1.1 "Ohne Maus nutzbar".

• Die Sichtbarkeit des Fokus ist Gegenstand von Prüfschritt 9.2.4.7 "Aktuelle Position des Fokus deutlich".

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Seite Links enthält.

2. Prüfung

3. Hinweise

• Links, deren Ziel generell für alle Nutzer unklar ist, fallen nicht unter diesen Prüfschritt.

• Verlinkte URLs und verlinkte E-Mail-Adressen vermitteln über ihr Format den Linkzweck (etwa, dass sie einen Email-Client öffnen oder auf ein externes Webangebot verlinken). URLs sind für alle Nutzer möglicherweise nicht aussagekräftig und werden deshalb hier nicht negativ bewertet.

• Bei verlinkten Grafiken ist der Linktext der Wert des alt-Attributs des img-Elements. Der Linktext kann auch aus dem alt-Text einer oder mehrerer Grafiken und einfachem Text zusammengesetzt sein.

• Nicht aussagekräftige Links wie "mehr..", "weiter", "etc." im letzten li-Element einer Liste werden akzeptiert, wenn die Bedeutung aus dem programmatisch ermittelbaren Kontext hervorgeht. Dazu gehört der den Link einschließende Absatz oder Listenpunkt oder auch die vorangehende Überschrift.

• Wenn zusätzlicher, per CSS unsichtbar gemachter Linktext mit display:none versteckt wird, ist er programmatisch nicht ermittelbar und verbessert nicht die Aussagekraft des Links: dieser Text wird von Screenreadern ignoriert.

• Das title-Attribut eines Links ist potenziell programmatisch ermittelbar, wird aber in manchen Fällen (abhängig von Einstellungen) nicht von Screenreadern ausgewertet.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

In diesem Prüfschritt wird nur geprüft, ob die Information über das Dateiformat überhaupt vorhanden ist. Das ist der Fall, wenn das Dateiformat in einer Grafik, im Linktext oder im zugänglichen Namen des Elements angegeben wird.

Bei verlinkten Grafiken ist der Linktext der alt-Text des img-Elements. Die Zugänglichkeit und Aussagekraft des alt-Textes wird jedoch im Prüfschritt 9.1.1.1a "Alternativtexte für Bedienelemente" geprüft.

In diesem Prüfschritt wird nur geprüft, ob die Information über das Dateiformat überhaupt vorhanden ist. Das ist der Fall, wenn das Dateiformat in einer Grafik, im Linktext oder im title-Text des Links angegeben wird.

Ist die Grafik, die Auskunft über das Dateiformat gibt, nicht im Link eingebunden (z. B. unverlinkt dem Link vorangestellt), so wird dies in Prüfschritt 9.1.1.1b "Alternativtexte für Grafiken und Objekte" geprüft.

Einordnung des Prüfschritts nach WCAG 2.2

Zweck der Kontextunabhängigkeit

WCAG 2.1, Link Purpose (In Context): Understanding SC 2.4.4

Gruppen zusammengehöriger Links

Bei einer Gruppe zusammengehöriger Links kann im ersten Link Ziel oder Zweck genannt werden und in den folgenden Links unterscheidende Informationen. Die WCAG 2.1 geben folgendes Beispiel:

WCAG 2.1, Link Purpose (In Context): Understanding SC 2.4.4: Examples of Success Criterion 2.4.4

Aussagekraft über den Kontext

WCAG 2.1, Link Purpose (In Context): Understanding SC 2.4.4

Grenzen des title-Attributs (Technik H33: Supplementing link text with the title attribute)

WCAG 2.1 Technik, H33: Supplementing link text with the title attribute

Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn das Webangebot informationsorientiert ist und aus mehr als einer Seite besteht.

Prüfung

1. Das Angebot auf vorhandene Zugangswege hin betrachten. Übliche Zugangswege sind:

   • Durchgängig verfügbare Navigationsmenüs

   • Inhaltsverzeichnis (Sitemap)

   • Suchfunktion (direkt über ein Sucheingabefeld oder über Verlinkung auf eine zentrale Suchseite)

   • Alle Seiten des Angebots sind von der Startseite her verlinkt oder auf jeder Seite des Angebots verlinkt (nur für kleine Sites geeignet)

   • Sequenzielle Verlinkung aller Seiten (höchstens für kleine Sites geeignet, oder für Sites, in denen die Wahrnehmung der Seiten in einer bestimmten Reihenfolge sinnvoll ist)

   • als Teil eines Prozesses erzeugte Seiten (etwa als Ergebnis einer Transaktion)

2. Gibt es mindestens zwei Zugangswege, etwa eine hierarchisches Navigationsmenü und eine Suchfunktion, oder ein Navigationsmenü und ein Inhaltsverzeichnis (Sitemap)?

3. Zugangswege stichprobenartig ausprobieren, um deren Funktionsfähigkeit zu überprüfen

Hinweise

• Es wird nicht gefordert, dass hierarchische Navigationsmenüs die tieferen Ebenen des Angebots vollständig abbilden.

• Es spielt für diesen Prüfschritt keine Rolle, ob Navigationsmenüs vertikal oder horizontal orientiert sind. Sie sollen aber als eigenständige Bereiche kenntlich sein.

• Die Kombination aus hierarchischem Hauptmenü und untergeordneten Bereichmenüs gilt als ein Zugangsweg.

• Ein hierarchischer Navigationspfad (Breadcrumb) ist sinnvoll. Er gilt jedoch nicht als eigenständiger Zugangsweg, da er nur die Navigation zu höheren Ebenen der Seitenhierarchie erlaubt, nicht den Zugang zu weiter unten liegenden Ebenen.

• Bei kleinen Angeboten mit nur wenigen Seiten, die alle von der Startseite verlinkt sind, gilt diese gleichzeitig als Sitemap, sofern auf allen Unterseiten des Angebotes deutlich ein Link auf die Startseite angeboten wird.

• Bei sequenziellen Prozessen kann es sinnvoll sein, dass außer der Navigation zu folgenden und vorhergehenden Prozessschritten keine weitere Navigation angeboten wird. Denn die Seiten (oder Instanzen) des Prozesses machen nur innerhalb des Gesamtprozesses Sinn und sollen nicht einzeln erreichbar sein. Hier sollte das Fehlen weiterer Navigationsoptionen nicht negativ bewertet werden.

Einordnung des Prüfschritts nach WCAG 2.2