1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die zu prüfende App spezielle Barrierefreiheits-Funktionen bereithält. Nicht berücksichtigt werden systemseitige Bedienungshilfen (z.B. vom Browser oder Betriebssystem).

2. Prüfung

1. Zu prüfende Ansicht der App öffnen

2. Einstellungen der App aufrufen und auch dort nach entsprechenden Funktionen suchen

3. Falls 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

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. Zu prüfende Ansicht der App ö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?

   • Werden zur biometrischen Steuerung zusätzlich alternative biometrische oder nicht biometrische Steuerungsmethoden angeboten?

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 anwendbar, wenn die App Dokumente konvertiert. "Dokumente" umfasst dabei alle digitalen Formate wie Text, Audio und Video.

2. Prüfung

Die Prüfung ist sehr individuell und richtet sich nach den verwendeten Quell- und Zielformaten.

1. Beispieldokumente mit Barrierefreiheits-Informationen in Zielformate konvertieren.

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

3. Hinweise

Informationen, die das Zielformat nicht unterstützt, sollen bei der Prüfung nicht berücksichtigt werden.

Für Hinweise zur Prüfpraxis, eröffnen Sie gerne ein Issue auf GitHub.

4. Bewertung

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

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist vor allem anwendbar, wenn die zu prüfende App zusammen mit physischem Zubehör genutzt wird und dieses Szenario geprüft wird. Beispiele für physisches Zubehör wären etwa ein Handscanner oder ein Kartenlesegerät zur Authentifizierung.

Der Prüfschritt ist auch anwendbar, wenn die Nutzung der App die Bedienung physischer Tasten oder Regler am Gerät (etwa Smartphone oder Tablet) einschließt oder das Gerät selbst für bestimmte Formen der Eingabe gegriffen, gedreht, geschüttelt oder anders ausgerichtet werden kann.

2. Prüfung

1. Prüfen, ob bei die Nutzung der App, z.B. für bestimmte Eingaben, die Bedienung physischer Tasten oder Regler am Gerät oder die Manipulation des Geräts selbst vorgesehen ist, und dabei ein physisches Greifen, ein Zusammendrücken, oder eine Drehung des Handgelenks erforderlich ist.

2. Prüfen, ob bei der Nutzung von Zubehör, z.B. bei der Bedienung physischer Bestandteile wie Schalter, Regler oder Drehknöpfe, ein physisches Greifen, ein Zusammendrücken, oder eine Drehung des Handgelenks erforderlich sind.

3. Falls ja: Gibt es für den Prozess eine alternative Bedienmethode ohne diese Aktionen?

3. Hinweise

• Wenn es eine alternative Bedienmethode gibt, müssen alle erforderlichen Schritte dieser Methode voll barrierefrei sein.

• Ein einfaches Drücken einer Taste (etwa die Taste eines Nummernblocks) fällt nicht unter die genannten physischen Aktionen.

4. Bewertung

Abgrenzung von anderen Prüfschritten

In diesem Prüfschritt geht es um die Bedienbarkeit von physischen Geräten und zusätzlichem Zubehör mit physischen Bedienelementen durch Menschen mit motorischen Einschränkungen. Wenn die Anforderung so interpretiert wird, dass auch virtuelle Bedienelemente gemeint sind, so ist die Prüfung der Bedienbarkeit von diesen schon über verschiedene andere Prüfschritte abgedeckt, besonders durch:

• 11.2.1.1 Tastatur

• 11.2.1.4 Tastatur-Kurzbefehle abschaltbar oder anpassbar

• 11.2.5.1 Alternativen für komplexe Zeigergesten

• 11.2.5.2 Zeigergesten-Eingaben können abgebrochen oder widerrufen werden

• 11.2.5.4 Betätigung durch Bewegung

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

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist bei der Prüfung von mobilen Apps für iOS und Android im Regelfall nicht anwendbar, es sei denn, die Nutzung der App setzt die Bedienung physischer Tasten oder Regler am Gerät oder die Nutzung von Bedienelementen an gekoppeltem Zubehör voraus.

2. Prüfung

Prüfen, ob physische Bedienelemente, etwa Tasten oder Regler, über taktile Unterscheidung oder Positionierung am Gerät identifizierbar und unterscheidbar sind.

3. Hinweise

1. Wenn Apps die Bedienung von Tasten am Gerät vorsehen, ist bei Smartphones der Prüfschritt in der Regel über die haptische Unterscheidbarkeit und/oder Positionierung dieser Tasten gegeben. So ist der Unterschied von Laut- und Leisetaste schon über die Position am Gerät (lauter = oben, leiser = unten) gegeben. Bei Zubehör mit mehreren Tasten kann die Anforderung erfüllt werden, wenn Tasten taktil wahrnehmbar und ggf. durch erhabene Beschriftung auch taktil unterscheidbar sind.

2. Bei Nummernblocks ermöglicht die taktile Hervorhebung der zentralen Taste Nummer 5 gleichzeitig die taktile Erkennung der umgebenden Tasten.

4. Bewertung

Abgrenzung von anderen Prüfschritten

In diesem Prüfschritt geht es um die Bedienbarkeit von zusätzlichem Zubehör durch Menschen mit motorischen Einschränkungen, wenn dieses zusammen mit der App genutzt wird. Wenn die Anforderung so interpretiert wird, dass auch virtuelle Bedienelemente gemeint sind, so ist die Prüfung der Bedienbarkeit von diesen schon über verschiedene andere Prüfschritte abgedeckt, besonders durch:

1. 11.2.1.1 Tastatur

2. 11.2.1.4 Tastatur-Kurzbefehle abschaltbar oder anpassbar

3. 11.2.5.1 Alternativen für komplexe Zeigergesten

4. 11.2.5.2 Zeigergesten-Eingaben können abgebrochen oder widerrufen werden

5. 11.2.5.4 Betätigung durch Bewegung

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

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist nur anwendbar, wenn für die Nutzung der App der Zustand von Hardware-Schaltern auf einem Ausgabegrät oder spezieller zusätzlicher Hardware relevant sind. Dazu gehören etwa Schalter zum Feststellen der Bildschirmausrichtung oder zum Stummschalten am genutzten Ausgabegerät, oder physische Umaschalter an gekoppelter spezieller Hardware.

2. Prüfung

1. Wird die App zusammen mit zusätzliche Hardware genutzt?

2. ist der Zustand physische Umschalter an der Hardware mit zwei oder drei Positionen taktil oder akustisch ermittelbar?

3. Hinweise

• Wenn die App einen Modus hat, der die gleiche Funktionalität auch ohne gekoppeltes Zubehör bietet oder der Schalter-Zustand des Zubehörs auch in der App sowohl visuell als auch programmatisch ermittelbar ist, wäre der Prüfschritt erfüllt.

• Die Feststelltasten bei ggf. gekoppelten Tastaturen geben ihren Feststell-Status bei entsprechender Voreistellung im Betriebssystem oft nur einmalig bei Aktivierung und Deaktivierung des Feststellmodus aus. Da App-Entwickler keinen Einfluss auf das Verhalten der Tastaturen haben, werden sie in diesem Prüfschritt nicht berücksichtigt.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

In diesem Prüfschritt geht es um die Bedienbarkeit von zusätzlichem Zubehör durch Menschen mit motorischen Einschränkungen, wenn dieses zusammen mit der App genutzt wird. Wenn die Anforderung so interpretiert wird, dass auch virtuelle Bedienelemente gemeint sind, so ist die Prüfung der Bedienbarkeit von diesen schon über andere Prüfschritte abgedeckt, besonders durch:

• 11.4.1.2 Name, Rolle, Wert verfügbar

• 11.5.2.15 Änderungsbenachrichtigung

• 11.5.2.16 Änderungen von Zuständen und Eigenschaften

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

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist nur anwendbar, wenn für die Nutzung der App der Zustand von Hardware-Schaltern auf einem Ausgabegrät oder spezieller zusätzlicher Hardware relevant sind. Dazu gehören etwa Schalter zum Feststellen der Bildschirmausrichtung oder zum Stummschalten am genutzten Ausgabegerät, oder physische Umaschalter an gekoppelter spezieller Hardware.

2. Prüfung

1. Gibt es auf dem Ausgabegerät oder zusätzlich genutzter Hardware Umschalter, die generell den Kontext der Ausgabe oder Eingabe beeinflussen (z.B. die Bildschirm-Ausrichtung feststellen oder den Ton stumm schalten)?

2. Falls das zutrifft: Mittels Sichtprüfung für solche physischen Umschalter prüfen, ob der Zustand visuell ermittelbar ist.

3. Hinweise

• Wenn die App einen Modus hat, der die gleiche Funktionalität auch ohne gekoppeltes Zubehör bietet oder der Schalter-Zustand des Zubehörs auch in der App sowohl visuell als auch programmatisch ermittelbar ist, wäre der Prüfschritt erfüllt.

4. Bewertung

Abgrenzung zu anderen Prüfschritten

In diesem Prüfschritt geht es um die Bedienbarkeit von zusätzlichem Zubehör durch Menschen mit motorischen Einschränkungen, wenn dieses zusammen mit der App genutzt wird. Wenn die Anforderung so interpretiert wird, dass auch virtuelle Bedienelemente gemeint sind, so ist die Prüfung der Bedienbarkeit von diesen schon über andere Prüfschritte abgedeckt, besonders durch:

• 11.1.4.11 Kontraste von Grafiken und Bedienelementen ausreichend

Abgrenzung zu Einstellungen auf Betriebssystem-Ebene

Die dominanten mobilen Betriebssysteme bieten Bedienelemente zum Arretieren der Ausrichtung: "Ausrichtungssperre" (iOS) und "Bildschirm automatisch drehen" (Android). Der Zustand ist bei beiden visuell zugänglich.

Abgrenzung zu virtuellen Tastaturen

Der Status "festgestellt" bei der Shift-Taste virtueller Tastaturen wird bei allen uns bekannten Tastaturen visuell vermittelt. Da App-Entwickler keinen Einfluss auf installierte Tastaturen haben, werden sie in diesem Prüfschritt nicht berücksichtigt.

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

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt wird nur geprüft, wenn die Tastenwiederholung nicht abstellbar ist und die Funktion in der App unterstützt wird. Bei iOS-Apps ist der Prüfschritt generell nicht anwendbar, da die Tastenwiederholfunktion abgeschaltet werden kann. Bei Android-Apps ist der Prüfschritt nur anwendbar, wenn die Ansicht Texteingabefelder für Tastatureingaben enthält. Geprüft wird nicht die systemseitige Einstellung selbst, sondern nur, ob diese auch bei Texteingaben in der App greifen.

2. Prüfung

Die Funktion Tastenwiederholung ist, soweit vorhanden, eine generelle Einstellung auf Betriebssystem-Ebene. Für die App selbst kann also nur geprüft werden, ob Einstellungen wie von Nutzenden intendiert bei Texteingaben auf der Ansicht greifen.

3. Hinweise

• Die Android-Funktion System > Tastatur > Physische Tastatur > Anschlagverzögerung leistet etwas anderes als die in der Anforderung intendierte Funktion, das Einsetzen der kontinuierlichen Eingabe des gleichen Zeichens bei längerem Drücken einer Taste zu verzögern. Die Verzögerung betrifft nämlich auch schon das initiale Drücken der Taste, was den Wert der Funktion sehr veringert. Denn gezielte Tastatureingaben sollen ja nicht grundsätzlich verzögert werden, sondern nur das Einsetzen der Wiederholung.

• Die Abweichung von der betriebssystemseitig möglichen Einstellungen von der Intention der Anforderung sind der App nicht anzulasten. Der Prüfschritt wäre nur dann nicht erfüllt, wenn betriebsystemseitige Einstellungen von Anschlaggeschwindigkeit und Tastenanschlagfunktion bei Texteingaben in der App nicht greifen würden.

• Bei der Nutzung virtueller Tastaturen (Touch-Eingabe) unter iOS und Android erfolgt keine Tastenwiederholung.

• Hinweis zu iOS: Ist bei Tastenwiederholung aktiviert, funktioniert diese nur bei bestimmten Tasten, z.B. bei den Zeichen ., - oder /, nicht jedoch bei 0-9 und A-Z. Dies ist ein bekannter iOS-Bug.

4. Bewertung

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

1. Anwendbarkeit des Prüfschritts

• Im Prüfschritt werden nicht die Einstellungsmöglichkeiten des Betriebssystems für die Annahme eines zweifachen Tastenanschlags geprüft, denn hier geht es um die App, nicht die zugrunde liegende Systemumgebung. Geprüft wird nur, ob Einstellungen, soweit betriebssystemseitig möglich, von der App übernommen werden.

• Der Prüfschritt ist nur anwendbar, wenn die Ansicht Felder für die Texteingabe enthält.

• In iOS wirkt sich die Einstellung der Tastenverzögerung nicht spezifisch auf die wiederholte Aktivierung der gleichen Taste aus, sondern auf Anschläge egal welcher Taste. Der Anschlag erfolgt erst, wenn die Taste länger gehalten wird (d.h., um die eingestellte Verzögerungszeit länger). Im Prüfschritt wird für iOS-Apps deshalb nur die Übernahme der Einstellungen für Tastenverzögerung geprüft.

• Bei Android ist die Anforderung dagegen über die Einstellung Eingabehilfe > Interaktion und Geschicklichkeit > Tastenanschlagfunktion implementiert.

2. Prüfung

3. Hinweis

Es ist der App nicht anzulasten und deshalb auch nicht negativ zu bewerten, wenn es betriebssystemseitig die erforderlichen Einstellungen für die Annahme eines zweifachen Tastenanschlags nicht gibt. In diesem Fall wird geprüft, ob verwandte Einstellungen, bei iOS also die allgemeine Tastenverzögerung, in der App greifen.

4. Bewertung

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

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar. Bezüglich Tastasturbedienung wir dieser Prüfschritt nicht geprüft, da Einstellungsmöglichkeiten für Einfingerbedienung Aufgabe des Betriebssystems sind und nicht auf der Ebene der App implementiert werden sollten.

Komplexe Aktionen, die vom Betriebssystem oder einer Hilfsmittelfunktionen definiert sind (etwa der VoiceOver-Rotor, der über eine gegenläufige Drehbewegung mit zwei Fingern aufgerufen wird) fallen nicht unter diesen Prüfschritt.

2. Prüfung

1. Bezüglich der Prüfung von Aktionen bei der Toucheingabe wird das Ergebnis von 11.2.5.1 "Alternativen für komplexe Zeiger-Gesten" hierhin übertragen, wenn es Fehler durch den Einsatz von Mehrfingergesten ohne Einfinger-bedienbare Alternativen gibt.

2. Bedienung mit Toucheingabe überprüfen. Sind alle Funktionen mit Einfinger-Gesten aktivierbar, ohne das gleichzeitig Gerätetasten gedrückt oder das Gerät bewegt bzw. ausgerichtet werden muss?

3. Hinweise

Ggf. sind bei Touchbedienung außer dem gleichzeitigen Drücken von Gerätetasten oder der Ausrichtung des Geräts andere, hier nicht näher spezifizierte simultane Aktionen denkbar, die für die erfolgreiche Bedienuung ausgeführt werden müssten, etwa die Auswertung von Handbewegungen über dem Gerät, die Auswertung des Kamera-Bildes, wofür das Gerät gehalten bzw. bewegt werden müsste, usw.

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 App eine Zwei-Wege-Sprachkommunikation anbietet.

2. Prüfung

1. Die Sprachqualität der Audio-Verbindung im Praxistest beurteilen. Enspricht 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 App 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.

3. Bewertung

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

1. Anwendbarkeit des Prüfschritts

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

2. Prüfung

1. Zu prüfende Ansicht der App ö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.

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 App 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. Zu prüfende Ansicht der App ö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 un 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, z.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 App Echtzeit-Textkommunikation (RTT, Real-Time Text) senden und empfangen kann.

2. Prüfung

1. Zu prüfende Ansicht der App öffnen.

2. Prüfen, ob die App 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 11.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üschritts 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

Die App-Ansicht mit der Echtzeit-Textkommunikation muss sehr genau mit dem Screenreader geprüft werden, um zu beurteilen, ob die notwendigen Informationen an den Screenreader gesendet werden und dieser die Richtung der einzelnen Textnachrichten ansagen kann bzw. diese aus der Ausgabe deutlich hervorgeht.

1. Screenreader starten

2. Zu prüfende Ansicht für Echtzeit-Textkommunikation aufrufen

3. Einige Testnachrichten senden und empfangen (ggf. zweites Gerät notwendig)

4. Die Textnachrichten antippen bzw. mit Hilfe der Wischgesten zu diesen navigieren

5. Auf die Ausgabe des Screenreaders achten. Wird die Unterscheidung zwischen eigenen und fremden Textbeiträgen 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.

• 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 App Echtzeit-Textkommunikation (RTT, Real-time Text) unterstützt und den aktiven Sprecher über Sprache identifiziert. Der aktive Sprecher wird dabei in der App markiert oder anderweitig hervorgehoben.

2. Prüfung

1. App öffnen.

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

3. Ist dies der Fall, prüfen, ob auch Teilnehmende, die Echtzeit-Texteingabe verwenden, beim Eingaben 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 App Zwei-Wege-Sprachkommunikation unterstützt und Funktionen zur Echtzeit-Textkommunikation bietet.

2. Prüfung

1. App öffnen

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

3. Prüfen, ob beim Sprechen eine Signalisierung in Echtzeit erfolgt, z.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 der EN 301 549 V3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App (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 App oder den Anbieter der App 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.1.1 nennt folgende je nach technischer Umsetzung anwendbare Standards:

• Die App 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 App 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 die App 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 App 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 nahezu instantan nach der Eingabe auf dem zweiten Gerät erscheinen.

Die Übertragung sollte dabei nicht deutlich 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 App Telekommunikationsfunktionen mit Anrufidentifizierung bietet.

Anrufidentifizierung bedeutet hier, die Signalisierung bzw. Anzeige der Anrufenden.

2. Prüfung

Für die Prüfung muss die App gegebenenfalls auf zwei Geräten installiert werden.

1. Screenreader starten

2. Zu prüfende Ansicht der App ö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 Anrufer automatisch angesagt oder sind die Informationen über den Anrufer auf dem Bildschirm für den Screenreader ohne Umwege auslesbar?

5. Prüfen, wie der Anruf visuell signalisiert bzw. angezeigt wird. Die Anzeige muss den Anrufer in irgendeinerweise in Textform identifizieren, z.B. über die Telefonnummer, Name etc.

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

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App 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 Sprech- 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 und 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 die Weiterentwicklung dieses Prüfschritts können Sie auf GitHub ein Issue anlegen und Ihre Erfahrungen teilen.

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

1. Anwendbarkeit des Prüfschritts

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

2. Prüfung

1. Die technische Dokumentation der 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 die App 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 die App auf zwei Geräten geöffnet werden.

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

2. Zu prüfende Ansicht der App 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 die Software Videotelefonie inkl. Sprachübertragung unterstützt.

2. Prüfung

Die Zeitdifferenz zwischen Audio und Video bei einer Videotelefonieübertragung 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 die App auf zwei Testgeräten installiert werden.

1. zu prüfende Ansicht der App auf zwei Geräten öffnen.

2. Videotelefonieverbindung zwischen den Geräten 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.

3. Hinweise

• Untersuchungen zeigen, dass die Verständlichkeit deutlich mehr leidet, wenn das Video dem Audio hinterherhängt, als umgekehrt. Diese Tatsache kann bei der Bewertung entsprechend berücksichtigt und angemerkt werden.

• Um Latenzen der Netzwerk-Infrastruktrur zu minimieren, sollten beide Geräte über eine stabile Internetverbindung mit ausreichend Bandbreite verbunden sein.

Für Hinweise zu diesem Prüfschritt, z.B. für die genaue Messung der Zeitdifferenz, können Sie auf GitHub ein Issue zu diesem Prüfschritt 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 App Videotelefonie mit Sprachübertragung unterstützt.

2. Prüfung

1. Die Ansicht der App auf zwei Geräten mit abweichenden Nutzenden-Konten öffnen.

2. Videotelefonieverbindung zwischen den beiden Instanzen der App herstellen.

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

3. Hinweise

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

Der visuelle Indikator der Audio-Aktivitä 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 zu diesem Prüfschritt eröffnen.

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

1. Anwendbarkeit des Prüfschritts

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

2. Prüfung

1. Die Ansicht der App auf zwei Geräten mit abweichenden Nutzenden-Konten öffnen.

2. Videotelefonieverbindung zwischen den beiden Instanzen der App herstellen.

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

4. Prüfen,

   • ob die App 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 von der App automatisch erkannt und in 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 zu diesem Prüfschritt 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 App aufgezeichnete Videos mit synchroner Bild- und Tonspur anbietet und Untertitel zuschaltbar sind.

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

2. Prüfung

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.

11.1.2.2 "Aufgezeichnete Videos mit Untertiteln"

1. Anwendbarkeit des Prüfschritts

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

3. Hinweise

Es ist sinnvoll, stichprobenartig zu prüfen, ob es in der App 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 11.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.

Die Prüfung, ob der Player oder die Untertitel-Datei Ursache von nicht-synchronen Untertiteln ist, kann derzeit nicht erfolgen. Werden Untertitel 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 die App Videos mit Untertiteln Übertragen, konvertieren oder aufnehmen kann.

2. Prüfung

Wenn die App 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 V.3.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App Videos mit Untertiteln enthält und die Untertitel sich 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. App ö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.

4. Falls die App bzw. die Einstellungsmöglichkeiten für Untertitel im Video-Player keine Anpassungsmöglichkeiten bieten, prüfen, ob sich die Änderung der Textgröße über die Bedienungshilfen des Betriebssystems auf die Darstellung der Untertitel auswirkt:

   1. Android: Einstellungen > Bedienungshilfen > Text und Anzeige > Schriftgröße > am größten

   2. iOS: Einstellungen > Bedienungshilfen > Anzeige und Textgröße > Größerer Text > Text im Schieberegler groß stellen

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.

4. Bewertung

Einordnung des Prüfschritts nach EN 301 549 V3.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 der App)

• und Untertitel in der Hauptsprache der App bereitgestellt werden

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

2. Prüfung

1. App-Ansicht öffnen.

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

3. Prüfen, ob für Videos mit fremdsprachiger Tonspur Untertitel in der Hauptsprache der App 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 zur Zeit 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 App 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 hinterlassen.

4. Bewertung

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

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn in der Ansicht der App 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 in der App 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 der Videoplayer Bedienelemente zum Ein- und Ausschalten der Audiobeschreibung anbietet. Eine Bereitstellung von Audiodeskription soll dadurch während der Wiedergabe möglich sein. In Prüfschritt 11.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 Audiodeskripiton 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 Ansicht der App Videos mit synchroner Bild- und Tonspur sowie einer zusätzlich eingebundenen Tonspur für Audiodeskription vorhanden sind. 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 in der App eingebundenen Player abspielen.

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

3. Wird Audiodeskription nicht synchron wiedergegeben, kann das an den technischen Möglichkeiten des Players oder an fehlerhaften Umsetzung der Audiodeskription liegen. Die Ursache kann derzeit nur vom App-Entwickler geprüft werden.

3. Hinweise

Falls die App keine eigenen Video-Inhalte bereithält, sondern zum Abspielen externer Inhalte gedacht ist, muss ggf. eine Beispiel-Video-Datei mit Audiodeskription in der App geöffnet werden.

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 11.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 die App Videos mit Audiodeskription übertragen, konvertieren oder aufnehmen kann.

2. Prüfung

Wenn die App 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.

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 in der App 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 in der App ein Videoplayer eingebunden ist, der Video-Inhalte mit zugehörigen Audioinhalten abspielt und wenn Untertitel und / oder Audiodeskription für das Verständnis nötig sind.

2. Prüfung

1. Das Video mit dem in der App 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.2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn Grafiken als Bedienelemente (z.B., Icons in Menüs oder Werkzeugleisten, Logos, Vorschaubilder) eingesetzt werden.

2. Prüfung

Falls ein Bedienelement aus einer (Symbol-)Grafik sowie einem Text besteht, der den Zweck des Bedienelements wiedergibt, dann gilt dieser Text als Alternative für die Grafik. Es ist dann ggf. sinnvoll, die Grafik selbst mit einer geeigneten Technik für Screenreader zu verstecken.

Handelt es sich dabei um eine Grafik ohne visuell sichtbaren Text (alleinstehendes Icon oder Symbol), so sollte ein Alternativtext vorhanden sein, der das Ziel bzw. die Aktion, die ausgeführt wird, beschreibt. In der Praxis ist dies Text, der über ein Accessibility-Label bereitgestellt wird.

3. Hinweise

4. Bewertung

Allgemein

• WCAG 2.1: Understanding SC 1.1.1 Non-Text Content

• Orange Digital Accessibility: Writing great accessibility labels

• W3C Web Accessibility Tutorials: Images Concepts

• WebAIM: Alternative Text

• Appt.org: Non-text Content: Set accessibility label (mehrere Entwicklungsumgebungen)

iOS

• Appt.org: Accessibility label on iOS

• Apple Accessibility for UIKit: accessibilityLabel

Android

• Appt.org: Accessibility label on Android

• Orange Digital Accessibility: Vocal Naviation

Abgrenzung zu anderen Prüfschritten

Grafische Bedienelemente 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.

• Einzige Ausnahme: Grafik und danebenstehender Text sind ein zusammengehöriger Link (zusammengesetztes Bedienelement). Die Textalternative bezieht sich dann nur auf die Grafik, die Prüfkriterien 11.1.1.1b "Alternativtexte für Grafiken und Objekte" oder 11.1.1.1c "Leere alt-Attribute für Layoutgrafiken" sind anzuwenden.

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

• CAPTCHAs werden im Prüfschritt 11.1.1.1c "Alternativen für CAPTCHAs" geprüft.

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

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

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

Als informative Grafiken gelten:

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

• Illustrationen, die einen Gegenstand, ein Konzept oder einen Prozess vorstellen, verdeutlichen oder veranschaulichen sollen (etwa Diagramme)

• Symbole

• Schriftgrafiken

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 App-Ansicht. Ihr Informationsgehalt und ihr Nutzen für das Verständnis ist aber nicht klar. Sie können daher als dekorativ gekennzeichnet werden. Der Alternativtext sollte dann leer sein.

Wenn Logo-artige Elemente, in denen Grafik und Schrift verbunden sind, auftauchen, sind diese fast nie als bloße Schmuckgrafik anzusehen und brauchen deshalb einen Alternativtext. 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

Für eine Prüfung mit VoiceOver / iOS müssen die AI/OCR-Erkennungsfunktionen ausgeschaltet sein (siehe 3. Hinweise).

1. App mit zu prüfender Ansicht starten.

2. Prüfen, ob unverlinkte Grafiken oder Multimedia-Inhalte vorhanden sind.

3. Screenreader starten und Fokus auf jede informationstragende Grafik setzen.

4. Prüfen, ob der Screenreader bei informationstragenden Grafiken einen aussagekräftigen Alternativtext ausgibt.

5. Bei komplexen Grafiken prüfen, ob der Alternativtext den Inhalt knapp nennt und auf ausführliche Textalternativen im Kontext der Grafik verweist. Diese können etwa unterhalb der Grafik, in einem Ausklappbereich oder in einer verlinkten Ansicht vorgehalten werden.

6. Prüfen, ob Schmuckgrafiken Alternativtexte tragen. Bei Grenzfällen (Grafiken haben einen beschreibbaren Inhalt mit Bezug zum Thema, sind aber zum Verständnis der Inhalte nicht wichtig) können sowohl Alternativtexte als auch leere Alternativtexte akzeptiert werden.

3. Hinweise

Allgemein

• WCAG 2.1: Understanding SC 1.1.1 Non-Text Content

• Orange Digital Accessibility: Writing great accessibility labels

• W3C Web Accessibility Tutorials: Images Concepts

• WebAIM: Alternative Text

• Appt.org: Non-text Content: Set accessibility label (mehrere Entwicklungsumgebungen)

iOS

• Apple Accessibility for UIKit: accessibilityLabel

• Appt.org: Accessibility label on iOS

Android

• Appt.org: Accessibility label on Android

• Orange Digital Accessibility: Vocal Naviation

Abgrenzung zu anderen Prüfschritten

• Textalternativen für verlinkte Grafiken (z.B. Bedienelemente oder Vorschaubilder) werden in Prüfschritt 11.1.1.1a "Textalternativen für Bedienelemente" geprüft.

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

• CAPTCHAs werden in Prüfschritt 11.1.1.1c "Alternativen für CAPTCHAs" geprüft.

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn bildbasierte 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 Nutzende mit Behinderungen unzugänglich ist (siehe die WCAG 2.0 Note on CAPTCHA).

4. Bewertung

Allgemein

• CAPTCHA-less Security by Karl Groves, 2012

Abgrenzung zu anderen Prüfkriterien

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 11.3.3.2 "Beschriftungen von Formularelementen vorhanden" geprüft.

Einordnung des Prüfschritts nach WCAG 2.1

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

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn Audiodateien oder stumme Videodateien in der App-Ansicht 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.

Statt Links auf Inhalte können auch andere Bedienelemente genutzt werden. Konformität besteht auch dann, wenn eine spezielle Version der Software angeboten wird, die die Anforderungen erfüllt.

4. Bewertung

Allgemein

• WCAG 2.1: Understanding SC 1.2.1: Audio-only and Video-only (prerecorded)

• Appt.org: Audio-only and Video-only (Prerecorded): Add a transcript (mehrere Entwicklungsumgebungen)

Abgrenzung zu anderen Prüfschritten

im Fall von zeitbasierten Medien geht es im Prüfschritt 11.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 11.1.2.1 "Alternativen für Audiodateien und stumme Videos" geprüft.

2. Prüfung

3. Bewertung

Allgemein

• WCAG 2.1: Understanding SC 1.2.2 Captions (Prerecorded)

• Appt.org: Captions (Prerecorded): Add captions (mehrere Entwicklungsumgebungen)

iOS

• Appt.org: Captions on iOS

Android

• Appt.org: Captions on Android

Abgrenzung zu anderen Prüfschritten

Einordnung des Prüfschritts nach WCAG 2.1

Gebärdensprache

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.

• Gebärdensprachvideos brauchen keine Audiodeskription, der Prüfschritt ist auf diese nicht anwendbar.

2. Prüfung

3. Hinweise

Wenn Zeitpunkt und Reihenfolge der Informationen nicht für das Verstehen wichtig sind, kommt es nicht darauf an, ob die Information zeitgleich in der (ggf. in die Tonspur integrierten) Audiodeskription vorkommt. So kann eine Audiodeskription mitunter wichtige Informationen eingangs zusammenfassen, die zu einem späteren Zeitpunkt eingeblendet werden.

4. Bewertung

Allgemein

• WCAG 2.1: Understanding SC 1.2.3: Audio Description or Media Alternative (Prerecorded)

• BIK für Alle: Leitfaden barrierefreie Online-Videos Audiodeskription

• BIK für Alle: Leitfaden barrierefreie Online-Videos Extended Audio-Deskription

• Blogartikel von Terrill Thompson zu Audio Description (Stand 03/2017): My Audio Description Talk @ CSUN

• Appt.org: Audio Description or Media Alternative (Prerecorded): Add audio description (mehrere Umgebungen)

Einordnung des Prüfschritts nach WCAG 2.1

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 Audiodeskrition oder Transkription der Bidinhalte 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 11.1.2.1 "Alternativen für Audiodateien und stumme Videos" geprüft.

2. Prüfung

1. Das Video in der App 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

Allgemein

• WCAG 2.1: Understanding SC 1.2.4: Captions (Live)

• Appt.org: Captions (Live): Add live captions (mehrere Entwicklungsumgebungen)

iOS

• Appt.org: Live captions on iOS

Android

• Appt.org: Live captions on Android

Abgrenzung zu anderen Prüfschritten

Einordnung des Prüfschritts nach WCAG 2.1

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 11.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

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

2. 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 (oder vergleichbares Bedienelement) zu dieser Version muss im unmittelbaren Kontext des Videos angeboten werden, ebenso wie ein Zurück-Link. Das Video hat eine zuschaltbare Tonspur mit der Audiodeskription. Diese Spur wird zusätzlich geschaltet.

   • Das Video wird in der App oder in einem externen, vom Format abhängigen Video-Player abgespielt.

3. Wenn eine Audiodeskription vorhanden ist, wird eine kurze Sequenz der Deskription angehört, um stichprobenartig festzustellen, ob sie nutzbar ist.

3. Bewertung

Allgemein

• WCAG 2.1: Understanding SC 1.2.5:Audio Description (Prerecorded)

• BIK für Alle: Leitfaden barrierefreie Online-Videos Audiodeskription

• BIK für Alle: Leitfaden barrierefreie Online-Videos Extended Audio-Deskription

• Blogartikel von Terrill Thompson zu Audio Description (Stand 03/2017): My Audio Description Talk @ CSUN

• Appt.org: Audio Description (Prerecorded): Add audio description (mehrere Entwicklungsumgebungen)

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 11.1.2.3 "Audiodeskription oder Volltext-Alternative für Videos" bewertet.

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn es in der App Inhalte gibt, die durch visuelle Überschriften strukturiert werden. Das ist bei informationsorientierten Apps häufig der Fall.

2. Prüfung

3. Hinweise

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

• Android-Entwickler können über das Attribut android:accessibilityHeading Überschriften auszeichnen, haben aber derzeit keine Möglichkeit, unterschiedliche Überschriftsebenen in nativen Ansichten auszuzeichnen. Eine fehlende Auszeichnung von Überschriftsebenen wird daher nicht negativ bewertet.

• Unter iOS und iPadOS können seit iOS / iPadOS 15 auch in nativen Apps Überschriftsebenen ausgezeichnet werden. Die Verbreitung der Auszeichnung von Überschriftsebenen ist jedoch sehr gering. Da Android bisher keine Möglichkeit der Auszeichnung von Überschriftsebenen bietet, wird derzeit auch eine fehlende Auszeichnung unter iOS und iPadOS nicht negativ bewertet.

• Wird vom Screenreader zusätzlich zur Rolle "Überschrift" auch die Überschriftenebene ausgegeben, handelt es sich in der Praxis derzeit meist um ein WebView, der auf HTML basiert. Überschriften sollten dann korrekt geschachtelt sein (h1 gefolgt von h2 gefolgt von h3, und so weiter), um die Gliederung der Inhalte abzubilden. Das Auslassen von Hierarchie-Ebenen muss aber kein Fehler sein, wenn dies durch die Gliederung der Inhalte gerechtfertigt ist.

• Falls es sich um eine iOS oder iPadOS App handelt und die Ansicht Potenziell durch die Auszeichnung von Überschriftsebenen profitieren würde, sollten Entwickler auf die Möglichkeit der Auszeichnung von Überschriftsebenen in nativen Ansichten in der Bewertung hingewiesen werden.

4. Bewertung

iOS

• Apple Developer Documentation: Accessibility Traits / isHeader

• Apple Developer Documentation: Hierarchische Überschriften in iOS

Android

• Android Developer: android:accessibilityHeading für UI-Elemente

• Android Developer: Headings within text

• Orange Accessibility Guidelines: Enable header navigation

Allgemeine Quellen

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn in der App Textinhalte vorhanden sind.

2. Prüfung

1. App mit zu prüfender Ansicht öffnen.

2. Screenreader starten und mittels Wischgesten durch alle Inhalte navigieren.

3. Prüfen, ob der Screenreader alle Textinhalte ausgibt.

3. Bewertung

Einordnung des Prüfschritts nach WCAG 2.1

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

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar, wenn Tabellen in der App-Ansicht vorhanden sind. Dies schließt Layouttabellen ein.

2. Prüfung

Die Screenreader-Navigation und Ausgabe von Datentabellen in Apps, besonders in Webviews, is oft uneinheitlich. Es kommt vor, dass Tabellen unter manchen Bedingungen fokussierbar und navigierbar sind und unter anderen nicht, selbst auf dem gleichen Gerät. Semantisch richtig aufgebaute Datentabellen können ggf. in responsiven Ansichten nicht zugänglich sein, zum Beispiel nicht im Lesemodus erreichbar sein, obwohl sie semantisch korrekt umgesetzt sind. Dies kann an der App selbst liegen oder auch auf einen Bug des Betriebssystems, des in Webviews transparent genutzten Browsers, oder des Screenreaders hindeuten. Das ist ohne Quelltextzugang nicht immer klar zu entscheiden. Ggf. während der Prüfung die App neu laden, Ansichten neu aufrufen, Screenreader deaktivieren und wieder reaktivieren, Geräte neu starten. Das Ziel ist, die programmatische Umsetzung der App zu bewerten und nicht Lücken oder Bugs in der Hilfsmittelunterstützung.

Zur Tabellennavigation mit dem Screenreader, siehe Hinweise für iOS und Android in Abschnitt 3. Hinweise.

3. Hinweise

4. Bewertung

iOS

• iOS / iPadOS: UIAccessibilityContainerDataTable

Android

• Android Developer Info: DataTables und DataViews

• Material Design: Data tables

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App-Ansicht Formularelemente enthält.

2. Prüfung

1. App mit der zu prüfenden Ansicht öffnen.

2. Screenreader starten und mit Hilfe der horizontalen Wischgeste durch die Ansicht navigieren.

3. Prüfen, ob bei Fokussierung von Formularelementen die jeweiligen Beschriftungen und (wenn vorhanden) Gruppenbeschriftungen korrekt ausgegeben werden.

3. Hinweise

4. Bewertung

Allgemein

• BBC, Accessibility for Products: Labeling form controls

• Appt.org: Group Elements (mehrere Entwicklungsumgebungen)

iOS

• Apple Developer Documentation: Group Labels

• Apple Developer Documentation: iOS accessibilityLabel

• Orange Accessibility Guidelines: Grouping elements

Android

• Android Developers: Make custom views more accessible

• Android Developers: Principles for improving app accessibility

• Orange Accessibility Guidelines: Group the elements

Abgrenzung von anderen Prüfkriterien

Ob bei Nutzung von gruppierenden Überschriften der Text zusammen mit verknüpften Beschriftungen der Formularfelder (label) Sinn ergibt, wird in Prüfschritt 11.2.4.6 "Aussagekräftige Überschriften und Beschriftungen" geprüft.

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

Bei Apps soll die programmatische und durch den Screenreader ausgegebene Element-Reihenfolge auf der Ansicht im Wesentlichen die visuelle Reihenfolge abbilden.

1. App mit der zu prüfenden Ansicht öffnen.

2. Screenreader starten und mit Hilfe der horizontalen Wischgeste durch alle Elemente der Ansicht navigieren. Dabei werden auch nicht interaktive Elemente fokussiert.

3. Prüfen, ob die Reihenfolge, in der die Elemente fokussiert und durch den Screenreader ausgegeben werden, sinnvoll und im Wesentlichen der visuellen Reihenfolge entspricht.

3. Hinweise

4. Bewertung

Abgrenzung von anderen Prüfkriterien

Custom controls, werden bereits in einer Reihe von bestehenden Prüfkriterien implizit geprüft, etwa 11.2.4.7 "Aktuelle Position des Fokus deutlich" und 11.4.1.2 "Name, Rolle, Wert verfügbar".

Die korrekte Reihenfolge im Quelltext bei eingeblendeten Elementen ist Gegenstand von Prüfschritt 11.2.4.3 "Schlüssige Reihenfolge bei der Tastaturbedienung".

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

1. Ein aktuelles Android-Smartphone oder iPhone mit ca. 4-6 Zoll Bildschirmdiagonale zur Prüfung verwenden.

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

3. Zu prüfende Ansicht der App öffnen.

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

5. Den zu prüfenden Inhalt in der anderen Ausrichtung neu laden.

6. Prüfen, ob Inhalte 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:

8. 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önnen.

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 in beiden Ausrichtungen jeweils neu geöffnet 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 11.1.4.4 "Text auf 200% vergrößerbar" und 11.1.4.10 "Inhalte brechen um".

Einordnung des Prüfschritts nach WCAG 2.1

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 Ansichten zum Anlegen eines Nutzerprofils). Für eine Prüfung, die Konformität bzw. Nicht-Konformität feststellen würde, müsste die App bzw. das Betriebssystem die Auszeichnung der Eingabezwecke unterstützen, die in Abschnitt 7. Input Purposes for User Interface Components der WCAG festgelegt sind. In den Einstellungen zur Barrierefreiheit von Android und iOS müsste außerdem eine Einstellung auftauchen, mit der die Anzeige des Eingabezwecks ein- und ausgeschaltet werden kann. Beides ist zur Zeit (April 2023) nicht der Fall.

2. Prüfung

Bei Apps ist die Prüfung eingeschränkt möglich. Hier kann über eine Sichtprüfung z.B. festgestellt werden, ob bei Eingabefeldern für E-Mail-Adressen, Pin-Codes, URLs usw. auch die dafür optimierte Tastatur eingeblendet wird. Auf der Tastatur für Email-Adressen erscheint dann z.B. prominent das „@“-Zeichen und der Punkt ist verfügbar, ohne erst auf die Symboltastatur wechseln zu müssen.

3. Hinweise

Die Anforderung gilt nur für Felder, die sich auf den Nutzer selbst beziehen. Sie gilt nicht für Seiten bzw. Ansichten, 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 / -Apps von Fluglinien. Hier sind die Eingabefelder für den Nutzer nicht von den Feldern für Mitreisende unterscheidbar.

4. Bewertung

Android

• Appt.org: Input keyboard type on Android

• Android Developer Resources: Optimize your app for autofill (zur Zeit nur auf Englisch verfügbar)

iOS

• Apple Developer Resources: Password AutoFill (zur Zeit nur auf Englisch verfügbar) Die unterstützten Arten von Autofill-Daten sind sehr begrenzt und dienen zur Zeit hauptsächlich dazu, die Tastatur dynamisch anzupassen. Siehe auch textContentType: The semantic meaning for a text input area. (zur Zeit nur auf Englisch verfügbar)

• UIKeyBoardType: Verfügbare angepasste Tastaturen fpr bestimmte EIngabefelder

Allgemeine Quaellen (WCAG)

• Understanding Success Criterion 1.3.5: Identify Input Purpose (zur Zeit nur auf Englisch verfügbar)

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

3. Hinweise

Nicht als einfache Farbunterschiede gelten:

• die farbige Hinterlegung von Elementen (denn eine Form kommt dazu oder ändert sich)

• der Austausch von Vorder- und Hintergrundfarbe (denn wenn überhaupt ein Unterschied von Vorder- und Hintergrund wahrgenommen wird, ist auch der Austausch wahrnehmbar)

4. Bewertung

Abgrenzung zu anderen Prüfkriterien

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn nach dem Starten einer App bzw. beim Wechsel auf eine Ansicht Tonelemente automatisch länger als drei Sekunden abgespielt werden.

2. Prüfung

Wenn nach Starten der App bzw. beim Wechsel auf die zu prüfende Ansicht 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 Beginn der Ansicht ein Mechanismus (Button, Link, oder Lautstärke-Regler) befindet, mit dem sich der Ton abschalten oder unabhängig von der Systemlautstärke herunterregeln lässt.

• Den Mechanismus bedienen und den Ton abschalten.

Wenn sich die Lautstärke regeln lässt:

• die Systemlautstärke darf durch den Regler in der App nicht verändert werden. Hier kann z.B. vor und nach einem Test ein Vergleichs-Sound abgespielt werden, um zu beurteilen, ob eine Veränderung der Systemlautstärke stattgefunden hat.

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 und dabei leise 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 in jeder Ansicht befinden, in denen Ton abgespielt wird 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 als Zusatz sinnvoll sein, wird aber von vielen Nutzern nicht vermutet.

• Insbesondere auf Touch-Geräten wird empfohlen, dass der Fokus standardmäßig auf dem Play- , Pause- , Mute-Bedienelement ist, damit dieses sofort bedient werden kann und nicht erst gesucht werden muss.

4. Bewertung

Bedeutung der Tonabschaltung nach WCAG 2.1

• Audio Control: Understanding SC 1.4.2

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

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

2. Prüfung

• Für die Bewertung zählt das Kontrastverhältnis (relative luminosity) nach einer in den WCAG 2.1 definierten Formel, die der Color Contrast Analyser handhabbar macht.

3. Hinweise

4. Bewertung

W3C zum Zusammenhang zwischen px und pt:

• CSS Values and Units Module Level 3: 5.2 Absolute Lengths

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App-Ansicht Text enthält.

2. Prüfung

3. Hinweise

• Je nach Gerätehersteller können Bedienungshilfen und deren Funktionen unter Android auch abweichende Namen tragen.

• Wenn die Prüfung unter 2.2 ergibt, dass die App systemseitige Nutzer-Einstellungen vergrößerter Schrift nicht übernimmt, sollte dies angemerkt werden. Der Prüfschritt ist aber dennoch erfüllt, wenn die Zoomvergrößerung funktioniert. Die Prüfung ist dennoch sinnvoll, um Entwicklern Hinweise auf Verbesserungsmöglichkeiten zu geben. Die Unterstützung von Systemschriften / dynamic fonts ist für alle Inhaltsbereiche sinnvoll, die bei Vergrößerung problemlos umbrechen können, z.B. Fließtexte. In anderen Fällen ist die Umsetzbarkeit abhängig vom generellen Layout-Konzept der Anwendung. Passen etwa fünf Reiter mit Text in eine Reiterleiste am Seitenfuß, wäre es ggf. nicht gut möglich, diese dynamisch vergrößerbar zu machen, ohne dass ein Umbruch der Reiterleiste stattfände oder Texte abgekürzt würden.

• Wenn die Prüfung unter 2.3 ergibt, dass die eigene Textvergrößerungseinstellungen der App nicht gut funktionieren, sollte dies angemerkt werden. Der Prüfschritt ist aber dennoch erfüllt, wenn die systemseitige Zoomvergrößerung funktioniert.

4. Bewertung

Allgemein

• Appt Guidelines: Support text scaling. Die Appt Guidelines enthalten Code-Beispiele für die Umsetzung vergrößerbarer Schrift für iOS, Android, Flutter, React Native und Xamarin.

• BBC Accessibility for Products: Mobile Accessibility Guidelines, Content Resizing. Beispiele für die Umsetzung anpassbarer Schriftgrößen mit Beispielen für iOS, Android und HTML.

iOS

• Orange Accessibility Guidelines: large Content Viewer

• Orange Accessibility Guidelines: Text Size (Dynamische Textgröße, Größe folgt den Systemeinstellungen auf dem Gerät)

• Apple UIKit Dokumentation: Scaling Fonts Automatically: Scale text in your interface automatically using Dynamic Type. Beschreibt den Einsatz von Dynamic Type in iOS.

• Orange Digital Accessibility Guidelines: iOS Developer GuideText size. Unter dem Eintrag "text size", Reiter Details gibt es Code-Beispiele für die Entwicklung in Objective C und Swift.

Android

• Orange Digital Accessibility Guidelines: Android develop - Element magnification. Code-Beispiele für den Einsatz von Scale-independent Pixels für die Textvergrößerung und Anpassung der Containergröße basierend auf Nutzereinstellungen.

Abgrenzung zu anderen Prüfkriterien

Mangelnde Vergrößerbarkeit von Schriftgrafiken: siehe Prüfschritt 11.1.4.5 "Verzicht auf Schriftgrafiken".

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar, wenn die App Schriftgrafiken enthält.

2. Prüfung

1. App mit zu prüfender Ansicht öffnen.

2. Prüfen, ob es Elemente gibt, die wie eine Schriftgrafik aussehen.

3. Screenreader starten und mit Hilfe der Wischgeste zu Elementen navigieren, die wie vermeintliche Schriftgrafiken aussehen.

4. Falls es sich um eine Schriftgrafik (also um keinen „echten“ Text) handelt, gibt der Screenreader „Bild“ oder „Grafik“ aus.

3. Hinweise

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

4. Bewertung

Abgrenzung zu anderen Prüfkriterien

Erfolgskriterium 1.3.1 der WCAG fordert generell die Verwendung von Markup anstelle von Bildern, um Informationen darzustellen. Als Beispiel wird MathML genannt. Wesentlich wichtiger ist allerdings die (ebenfalls angesprochene) Vermeidung der Nutzung von Bildern für Texte. In diesem Prüfschritt wird nur die Verwendung von Grafiken für Überschriften, "normalen" Fließtext und die Beschriftung von Bedienelementen berücksichtigt.

Einordnung des Prüfschritts nach WCAG 2.1

Schriftzeichen

Wie ist es mit der Darstellung von Schriftzeichen, die nicht auf allen Geräten 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 Bildern, in denen Schrift vorkommt, zum Beispiel bei Fotos mit Ladenschildern oder Verkehrszeichen, sind Inhalt und Darstellung zusammengehörig. Dieser Prüfschritt ist auf solche Bilder nicht anwendbar.

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

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.

Ausnahmen

Von der Anforderung ausgenommen sind Inhalte der Ansicht, für deren Nutzung ein zweidimensionales Layout erforderlich ist und die auf eine geringe Viewportbreite verkleinert nicht sinnvoll nutzbar sind, z.B.:

• Bilder, die Infomationen enthalten, die bei Verkleinerung nicht mehr erkennbar bzw. lesbar sind

• Landkarten

• Diagramme

• Videos

• Spiele

• Präsentationen

• Datentabellen

• Anwendungs-Schnittstellen, in denen die Bearbeitung von Inhalten die permanente Verfügbarkeit von Werkzeugleisten erfordert.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

Laut EN 301 549 Version 3.2.1 ist dieser Prüfschritt auf Software und damit auch auf mobile Apps anwendbar. In der Regel ist er schon dadurch erfüllt, dass alle Inhalte auf die Ausgabe innerhalb des Hochkant-Viewports optimiert sind. Der Viewport auch kleinerer aktueller Smartphones ist allerdings in der Regel breiter als 320 CSS Pixel. So hat das kleinste aktuelle iPhone, das iPhone 13 mini, eine Viewportbreite von 360 CSS-Pixeln. Das Samsung Galaxy S21 Ultra hat eine Viewportbreite von 384 CSS-Pixeln.

Im Kontext der WCAG2ACT Task Force der Accessibility Guidelines Working Group läuft eine Diskussion, ob und wie Reflow auch auf Nicht-Web-Inhalte anzuwenden wäre.

2. Prüfung

3. Hinweise

4. Bewertung

Allgemein

• WCAG 1.4.10 Reflow: Understanding Reflow (zur Zeit nur auf Englisch verfügbar)

• Appt.org Guidelines: Reflow. Beispiele für die Umsetzung vergrößerbaren umbrechenden Texts in den Umgebungen Android, iOS, Flutter, React Native und Xamarin. Hier wird Reflow auf das Verhalten von Text bei Übernahme nutzerdefinierter Systemeinstellungen bezogen.

Android

• Appt.org: Reflow on Android

Einordnung des Prüfschritts nach WCAG 2.1

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 inaktive Bedienelemente, also solche, die zustandsabhängig für die Interaktion nicht zur Verfügung stehen.

Eine Ausnahme gilt für native Bedienelemente wie iOS toggle switches, da hier die platform software (also das mobile Betriebssystem) für den Browser (user agent) steht, für dessen unveränderte Darstellung von Bedienelementen es in den Web-Anforderungen eine Ausnahme gibt.

2. Prüfung

Hinweis: Für Grafiken und Bedienelemente ist eine Sichtprüfung ausreichend, wenn der Kontrast sehr deutlich über 3:1 liegt. Im Zweifelsfall immer den Color Contrast Analyzer auf Screenshots einsetzen. Die Prüfung ist zum Teil komplex. Bitte Abschnitt 3. Hinweise beachten.

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 11.1.4.3 "Kontraste von Texten ausreichend" bewertet.

Einordnung des Prüfschritts nach WCAG 2.1

Anmerkung

Die Anforderung verlangt nicht von Autoren, die genannten Werte bei Ihren Inhalten umzusetzen oder solche Einstellungsmöglichkeiten in der App selbst anzubieten, sondern lediglich, dass von Nutzenden in der Plattform vorgenommene Anpassungen nicht zum Abschneiden von Text oder Verlust von Funktionalitäten führt. Die Plattform beschreibt im Falle von Apps das darunterliegende Betriebssystem, z.B. iOS, iPadOS und Android.

1. Anwendbarkeit des Prüfschritts

Zur Zeit bieten die mobilen Betriebssysteme iOS / iPadOS und Android keine Einstellungen für Textspreizung an (Stand April 2023), daher ist dieser Prüfschritt zur Zeit generell nicht anwendbar.

2. Prüfung

Eine Prüfung der Anforderung findet zur Zeit nicht statt.

Es ist vorstellbar, dass die verschiedenen Betriebssysteme zukünftig entsprechende Funktionen zur Veränderung des Textabstands anbieten werden. Ist dies der Fall, muss die App mit den systemseitig einstellbaren, von der Anforderung festgelegten Abständen funktionieren.

3. Hinweise

Falls Apps selbst Einstellungen für die Textspreizung bieten, sind dies von Autoren vorgesehene und implementierte Einstellungen, es geht also nicht um die generelle Anpassbarkeit von App-Inhalten an Einstellungen von Nutzenden. Solche Einstellungen, falls vorhanden, fallen deshalb nicht unter diesen Prüfschritt. Ihre Resultate sind als zusätzliche, alternative Versionen zur konformen Version zu verstehen.

4. Bewertung

Hinweis:

Die Anforderung gilt nicht für eingeblendete Inhalte, deren Verhalten durch das Betriebssystem bestimmt wird.

Die meisten mobilen Apps blenden beim Darüberfahren mit dem Zeiger (Hover) oder bei Tastaturfokussierung keine zusätzlichen Inhalte ein, da sie meist für die Touchbedienung als dominante Nutzungsweise entwickelt werden - und hier gibt es kein Hover. Dennoch sind eingeblendete Inhalte bei Nutzung mit gekoppelter Maus oder Tastatur möglich.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist grundsätzlich anwendbar, auch wenn bisher in der Prüfpraxis keine Einblendungen bei Apps für iOS / iPadOS und Android gefunden wurden.

2. Prüfung

3. Hinweise

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

Wenn die Aktivierung des Elements, das 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).

4. Bewertung

Allgemein

• WCAG 2.1: Understanding SC 1.4.13: Content on Hover or Focus (zur Zeit nur auf Englisch verfügbar)

Abgrenzung zu anderen Prüfschritten

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 11.2.1.1 "Tastaturbedienung" geprüft.

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar für native Apps, die eine Benutzeroberfläche bieten und den Zugriff auf Tastaturen oder ein Tastaturinterface unterstützen. Dies trifft auf die meisten Apps auf den gängigen mobilen Plattformen wie Apples iOS / iPadOS sowie Googles Android zu.

2. Prüfung

1. Tastatur über Bluetooth-Kopplung oder USB-Kabel anschließen.

2. App mit zu prüfender Ansicht öffnen.

3. Mit der Tabulatortaste die Links und Formularelemente durchgehen. Wo sich Elemente nicht mit dem Tabulator erreichen lassen, prüfen, ob sie mit den Pfeiltasten erreichbar sind.

4. Prüfen, ob alle wesentlichen Funktionen über die Tastatur erreicht und aktiviert werden können. In der Regel heißt das, das Elemente fokussiert und dann über die Eingabe- oder Leertaste aktiviert werden können. Wo Elemente nicht erreichbar oder aktivierbar sind, prüfen, ob äquivalente Wege zum Auslösen der Funktion über die Tastatur zur Verfügung stehen.

5. Falls die Ansicht Elemente enthält, die wie Bedienelemente aussehen, jedoch nicht über Tabulatortaste oder Pfeiltasten angesteuert werden, prüfen, ob diese Elemente auf Touch-Eingaben reagieren (zum Beispiel Navigation zu anderen Ansichten, Funktionsaufrufe, Vergrößerung, Einblenden von weiteren Inhalten). Wenn ja, müssen sie auch mit der Tastatur fokussier- und aktivierbar sein.

6. Falls die Ansicht scrollbare Bereiche enthält, sollen nicht sichtbare Inhalte dieser Bereiche auch über die Tastatur erreichbar sein, ohne das dazu der Bildschirm berührt werden muss.

   1. iOS: Falls Seitenbereiche mit Textinhalten ohne interaktive Elemente nicht erreicht werden: Prüfen, ob nach Aktivieren von Tastaturgesten (Tab + G) alle Textinhalte über die vertikalen Pfeiltasten erreichbar sind.

3. Hinweise

4. Bewertung

Abgrenzung zu anderen Prüfkriterien

Dieser Prüfschritt betrifft die Fokussierbarkeit und Aktivierbarkeit von interaktiven Elementen mit der Tastatur.

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

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

• Die sinnvolle Fokusreihenfolge wird in 11.2.4.3 "Schlüssige Reihenfolge bei der Tastaturbedienung" bewertet

Einordnung des Prüfschritts nach WCAG 2.1

Unsere App ist auf die mobile Nutzung unterwegs ausgelegt, da hat man doch keine Tastatur. Gilt dann dieser Prüfschritt trotzdem?

Ja, er gilt. Viele Apps für unterwegs werden auch zuhause oder am Arbeitsplatz genutzt, z.B. bei einer App für den öffentlichen Nahverkehr:

• um Reisen vorab zu planen, Wege und Anschlüsse zu recherchieren

• um Meldungen zu Baustellen, Umleitungen oder Verkehrsbehinderungen vorab zu checken

• um nutzerdefinierte Voreinstellungen vorzunehmen (z.B. häufige Ziele oder häufige Routen festlegen)

• um sich zu registrieren oder Profildaten zu ändern

Die Anforderungen an Tastaturnutzbarkeit gelten also generell. Die BITV bzw. die zugrunde liegende EN 301 549 sehen hier keine Ausnahmen vor.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

1. Tastatur über Bluetooth-Kopplung oder USB-Kabel anschließen.

2. App mit zu prüfender Ansicht öffnen.

3. Mit der Tabulatortaste durch alle interaktiven Elemente und Formularelemente navigieren.

4. Prüfen, ob alle interaktiven Elemente und Formularelemente erreicht und wieder verlassen werden können.

3. Hinweise

Wenn die Tastaturfalle verhindert, dass man Inhalte nach der Tastaturfalle erreicht, dann ist eventuell auch Prüfschritt 11.2.1.1 "Tastaturbedienung" nicht erfüllt.

4. Bewertung

Einordnung des Prüfschritts nach WCAG 2.1

Unsere App ist auf die mobile Nutzung unterwegs ausgelegt, da hat man doch keine Tastatur. Gilt dann dieser Prüfschritt trotzdem?

Ja, er gilt. Viele Apps für unterwegs werden auch zuhause oder am Arbeitsplatz genutzt, z.B. bei einer App für den öffentlichen Nahverkehr:

• um Reisen vorab zu planen, Wege und Anschlüsse zu recherchieren

• um Meldungen zu Baustellen, Umleitungen oder Verkehrsbehinderungen vorab zu checken

• um nutzerdefinierte Voreinstellungen vorzunehmen (z.B. häufige Ziele oder häufige Routen festlegen)

• um sich zu registrieren oder Profildaten zu ändern

Die Anforderungen an Tastaturnutzbarkeit gelten also generell. Die BITV bzw. die zugrunde liegende EN 301 549 sehen hier keine Ausnahmen vor.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

1. App Ansicht neu laden. Wenn dies den Fokus auf ein Interface-Element setzt (z.B. auf ein Eingabefeld), auf einen leeren Bereich der Software tippen, oder tabben, bis der Rahmen der Ansicht fokussiert ist, um sicherzustellen, dass keine Interface-Elemente fokussiert sind.

2. 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.

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

4. Falls einzelne Tasten Funktionen auslösen, prüfen, ob die 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.

4. Bewertung

iOS

• Appt.org: Keyboard shortcuts on iOS

Allgemeine Quellen

• WCAG: Understanding Success Criterion 2.1.4: Character Key Shortcuts (zur Zeit nur auf Englisch verfügbar)

Einordnung des Prüfschritts nach WCAG 2.1

Unsere App ist auf die mobile Nutzung unterwegs ausgelegt, da hat man doch keine Tastatur. Gilt dann dieser Prüfschritt trotzdem?

Ja, er gilt. Viele Apps für unterwegs werden auch zuhause oder am Arbeitsplatz genutzt, z.B. bei einer App für den öffentlichen Nahverkehr:

• um Reisen vorab zu planen, Wege und Anschlüsse zu recherchieren

• um Meldungen zu Baustellen, Umleitungen oder Verkehrsbehinderungen vorab zu checken

• um nutzerdefinierte Voreinstellungen vorzunehmen (z.B. häufige Ziele oder häufige Routen festlegen)

• um sich zu registrieren oder Profildaten zu ändern

Die Anforderungen an Tastaturnutzbarkeit gelten also generell. Die BITV bzw. die zugrunde liegende EN 301 549 sehen hier keine Ausnahmen vor.

1. Anwendbarkeit des Prüfschritts

Die Prüfung auf Auto-Aktualisierung und Weiterleitung ist immer anwendbar.

Die Prüfung auf Abschaltbarkeit oder Verlängerbarkeit von Zeitbegrenzungen ist nur anwendbar auf Ansichten mit Transaktionen, welche üblicherweise aus datenschutzrechtlichen oder sicherheitsrelevanten Gründen Zeitbegrenzungen unterliegen (etwa beim Online-Banking oder Online-Shops).

2. Prüfung

3. Hinweise

Dieser Prüfschritt bezieht sich nur auf vom Inhalt hervorgerufene Zeitbegrenzungen (sowohl serverseitig als auch clientseitig). Externe Zeitbegrenzungen, etwa des Betriebssystems, sind in der Regel nicht im Einflussbereich des Autors und damit nicht Gegenstand der Prüfung.

4. Bewertung

Abgrenzung von anderen Prüfkriterien

Dieser Prüfschritt 11.2.2.1 betrifft Zeitbegrenzungen, welche die ganze Ansicht 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 11.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 11.2.1.1 "Tastaturbedienung" oder 11.1.3.1d "Beschriftung von Formularelementen programmatisch ermittelbar").

Einordnung des Prüfschritts nach WCAG 2.1

Kontrollelement für Zeitbegrenzung und Auto-Aktualisierung

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

Wichtig ist, dass die Autoaktualisierung oder das Ende der Zeitbegrenzung nicht erfolgt, 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 Beginn der Ansicht 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 anwendbar, wenn in der Ansicht blinkende, sich bewegende oder automatisch aktualisierte Inhalte vorhanden sind.

2. Prüfung

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

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

• Prüfen, ob das Aktivieren der Schaltfläche 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 dies nicht der Fall, sollte dies angemerkt werden, ist aber nicht als Verstoß gegen diese Anforderung 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

Die WCAG 2.1 zu aufgezeichneten und Echtzeit-Inhalten

(Pause, Stop, Hide: Understanding SC 2.2.2)

Abgrenzung der Prüfschritte 11.2.2.1 und 11.2.2.2

• Dieser Prüfschritt 11.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 11.2.2.1 "Zeitbegrenzungen anpassbar" betrifft Zeitbegrenzungen, welche die ganze Ansicht 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 11.2.3.1 "Verzicht auf Flackern".

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

1. App mit zu prüfender Ansicht öffnen.

2. Gibt es in der App-Ansicht flackernde Inhalte, die nicht spätestens nach dreimaligem Flackern in einem Zeitraum von einer Sekunde aufhören?

3. Hinweise

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

4. Bewertung

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)

Einordnung des Prüfschritts nach WCAG 2.1

Zusätzliche Bedarfe von Screenreader-Nutzenden

Für Nutzende von Sceenreadern, die die Tastaturbedienung einsetzen, gibt es zusätzliche Probleme beim Einsatz dynamisch eingefüger Inhalte. Während solche Änderungen für sehende Nutzer unmittelbar wahrnehmbar sind, werden sie oft von Screenreader-Nutzenden gar nicht wahrgenommen, wenn der Fokus nicht in diese Elemente versetzt wird.

Werden durch die Interaktion mit der App weitere Elemente in die Ansicht eingefügt, etwa bei Formularen, die im Ausfüllen zusätzliche Optionen einblenden, sollte diese Einfügungen unterhalb des auslösenden Elements geschehen, damit Screenreader auf die hinzugefügten Elemente stoßen und diese ausgeben. Werden dynamische Inhalte zusätzlich auf der Ansicht eingefügt, so dass sie die Ansicht ganz oder teilweise abdecken, muss die App dafür sorgen, dass der Fokus auf diese Inhalte versetzt wird und so auch blinde Nutzer die Änderung mitbekommen.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App-Ansicht Bedienelemente wie Links, Tasten, Formularelemente oder Objekte enthält.

2. Prüfung

iOS: Vor der Prüfung sicherstellen, dass in den Bedienungshilfen unter "Tastaturen" der Auswahlschalter "Tastatursteuerung" aktiviert ist.

1. Der Tastatur-Fokus wird mittels Tabulator-Taste von Bedienelement zu Bedienelement bewegt.

2. Wenn es Bereiche oder Elemente gibt, in denen sich der Fokus statt mit dem Tabulator über Pfeiltasten bewegen lässt, wird die Reihenfolge mit Pfeiltasten geprüft.

3. Ist die sequenzielle Tab- bzw. Pfeiltasten-Reihenfolge der Elemente sinnvoll und entspricht im Wesentlichen der visuellen Reihenfolge?

4. Gibt es unsichtbare Fokusstationen?

5. Interaktive Elemente sollten nach Fokussierung aktiviert werden, um auch jene Elemente zu erfassen, die weitere Inhalte aufrufen (etwa Ausklappbereiche, Menüs, oder Dialoge), denn die Fokus-Reihenfolge muss auch in diesen geprüft werden. Hierbei kommen fallweise Tabulator oder Pfeiltasten, auch im Wechsel, zum Einsatz.

6. Falls dynamische Inhalte (Dialoge, Popovers, Menüs) über der Ansicht aufgerufen werden: Wird nach Aufruf der Fokus an den Beginn des zusätzlichen Inhalts versetzt?

7. Ist die Fokus-Reihenfolge bei Bedienelementen in aufgerufenen Inhalten sinnvoll?

3. Hinweise

4. Bewertung

Allgemein

• Appt.org: Move accessibility focus (Mehrere Entwicklungsumgebungen)

• Appt.org: Adjust order for keyboard (Mehrere Entwicklungsumgebungen)

• Appt.org: Adjust order for assistive technologies (Mehrere Entwicklungsumgebungen)

iOS

• Orange Accessibility Guidelines: iOS developer guide - focus an element - Code-Beispiele

• Orange Accessibility Guidelines: Modify the focus area of VoiceOver - Code-Beispiele

• Orange Accessibility Guidelines: Modal view - Fokus auf Inhalte modaler Dialoge reduzieren - Code-Beispiele

• Appt.org: Accessibility focus on iOS - how to move the focus to modals or popover views.

Android

• Orange Accessibility Guidelines: Android develop - Keyboard navigation & Switch Access

• Orange Accessibility Guidelines: Keyboard navigation order

• Appt.org: Accessibility focus on Android - how to move the focus to modals or popover views.

• Appt.org: Element focus change on Android

Abgrenzung zu anderen Prüfschritten

• In diesem Prüfschritt wird die Tabreihenfolge geprüft, die grundsätzliche Erreichbarkeit und Auslösbarkeit von interaktiven Elementen ist Gegenstand von Prüfschritt 11.2.1.1 "Tastaturbedienung".

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

• Geprüft wird hier die richtige Position eingeblendeter oder eingefügter Inhalte. Ob diese Inhalte selbst sinnvoll sind, wird in anderen Prüfkriterien wie 11.3.3.3 "Hilfe bei Fehlern"" oder 11.2.4.4 "Aussagekräftige Linktexte" geprüft.

Einordnung des Prüfschritts nach WCAG 2.1

Unsere App ist auf die mobile Nutzung unterwegs ausgelegt, da hat man doch keine Tastatur. Gilt dann dieser Prüfschritt trotzdem?

Ja, er gilt. Viele Apps für unterwegs werden auch zuhause oder am Arbeitsplatz genutzt, z.B. bei einer App für den öffentlichen Nahverkehr:

• um Reisen vorab zu planen, Wege und Anschlüsse zu recherchieren

• um Meldungen zu Baustellen, Umleitungen oder Verkehrsbehinderungen vorab zu checken

• um nutzerdefinierte Voreinstellungen vorzunehmen (z.B. häufige Ziele oder häufige Routen festlegen)

• um sich zu registrieren oder Profildaten zu ändern

Die Anforderungen an Tastaturnutzbarkeit gelten also generell. Die BITV bzw. die zugrunde liegende EN 301 549 sehen hier keine Ausnahmen vor.

1. Anwendbarkeit des Prüfschritts

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

2. Prüfung

3. Hinweise

• Bei verlinkten Grafiken ist der Linktext der Wert des Alternativtextes.

• Der Linktext kann auch aus dem Alternativtext einer oder mehrerer Grafiken und einfachem Text zusammengesetzt sein.

• Nicht aussagekräftige Links wie "mehr..", "weiter", "etc." im letzten Element einer Liste werden nur akzeptiert, wenn die Bedeutung klar aus dem Kontext der Auflistung hervorgeht.

• Bei Apps kann mit aktiviertem Screenreader geprüft werden, was bei verlinkten Grafiken ausgegeben wird.

4. Bewertung

Allgemein

• Appt.org: Mark links (mehrere Entwicklungsumgebungen)

Abgrenzung zu anderen Prüfschritten

Die Aussaagekraft der Alternativtexte für Grafiken wird geprüft in:

• Prüfschritt 11.1.1.1a "Alternativtexte für Bedienelemente"

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn es in der App-Ansicht Inhalte gibt, die durch Überschriften strukturiert werden können und wenn die Ansicht Formularelemente enthält.

2. Prüfung

1. App mit zu prüfender Ansicht starten.

2. Prüfen, ob Überschriften im Zusammenhang mit dem folgenden Text aussagekräftig sind.

3. Prüfen, ob Beschriftungen von Formularelementen aussagekräftig sind.

4. Wenn Formularelemente eine Gruppenbeschriftung haben: Sind Gruppenbeschriftung und Beschriftung des Formularelements im Zusammenhang aussagekräftig?

3. Hinweise

4. Bewertung

Abgrenzung von anderen Prüfschritten

• In diesem Prüfschritt geht es um die Aussagekraft von Überschriften und Beschriftungen. Die programmatische Ermittelbarkeit durch wssistive Technologien wid in den Prüfschritten 11.1.3.1a "Strukturelemente für Überschriften" und 11.1.3.1d "Beschriftung von Formularelementen programmatisch ermittelbar" geprüft.

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App-Ansicht interaktive Elemente enthält.

2. Prüfung

1. Tastatur über das Andocken einer Tastatur an ein Tablet oder Verbindung über Bluetooth-Kopplung oder USB-Kabel anschließen.

2. Zu prüfende Ansicht der App öffnen.

3. Mit der Tabulatortaste zu allen interaktiven Elementen navigieren. Wo diese weitere Auswahlen zulassen, etwa bei Tabpanels, Menüs oder Auswahllisten, mit den Pfeiltasten oder ggf. dem Tabulator zu Tabs bzw. Optionen navigieren. Ggf. ist dazu auch die Eingabe von STRG + TAB oder STRG + SHIFT + TAB notwendig.

4. Prüfen, ob alle Elemente mit grafischen Veränderungen auf den Fokus reagieren (zum Beispiel mit Farbwechseln, Rahmen, Unterstreichungen oder eingeblendeten Symbolen). Versteckte Sprunglinks (wo vorhanden) sollen bei Fokuserhalt eingeblendet werden.

3. Hinweise

4. Bewertung

Allgemein

• Appt.org: Focus Visible: Add accessibility focus indicator (mehrere Entwicklungsumgebungen)

iOS

• Appt.org: Accessibility focus indicator on iOS

Android

• Appt.org: Accessibility focus indicator on Android

• Android ViewUI: Custom Focus Indicators

• Android Compose: Custom Focus Indicators

Einordnung des Prüfschritts nach WCAG 2.1

Ist die Anzeige des Fokus nicht Sache des Betriebssystems?

Alle Betriebssysteme zeigen dem Tastaturnutzer in irgendeiner Weise, wo der Fokus ist, wenn diese Anzeige nicht aktiv unterdrückt wird.

Dennoch ist die Anzeige des Fokus (leider) nicht allein Sache des Betriebssystems. Bei den mobilen Betriebssystmen ist die Standard.Fokushervorhebung nicht kontrastreich genug und für Menschen mit Sehbehinderungen nicht oder nur schlecht wahrnwehmbar.

Die App kann festlegen, wie die Fokushervorhebung aussehen soll. Der Fokus muss für Tastaturnutzer gut sichtbar sein.

Mit angeschaltetem Screenreader ist der Fokus gut. Reicht das nicht aus?

Die WCAG-Anforderung sagt tatsächlich "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible." Lange Zeit war bei iOS die Tastaturbedienung sogar nur möglich, wenn VoiceOver aktiviert (und ggf. stummgeschaltet) war. VoiceOver und Talkback sind spezielle Hilfsmittel für Menschen, die eine akustische Ausgabe brauchen, und anderen Menschen meist nicht bekannt. Sie sind nicht als allgemein verfügbarer Nutzungsmodus für Tastaturnutzende zu betrachten.

Unsere App ist auf die mobile Nutzung unterwegs ausgelegt, da hat man doch keine Tastatur. Gilt dann dieser Prüfschritt trotzdem?

Ja, er gilt. Viele Apps für unterwegs werden auch zuhause oder am Arbeitsplatz genutzt, z.B. bei einer App für den öffentlichen Nahverkehr:

• um Reisen vorab zu planen, Wege und Anschlüsse zu recherchieren

• um Meldungen zu Baustellen, Umleitungen oder Verkehrsbehinderungen vorab zu checken

• um nutzerdefinierte Voreinstellungen vorzunehmen (z.B. häufige Ziele oder häufige Routen festlegen)

• um sich zu registrieren oder Profildaten zu ändern

Die Anforderungen an Tastaturnutzbarkeit gelten also generell. Die BITV bzw. die zugrunde liegende EN 301 549 sehen hier keine Ausnahmen vor.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App Eventhandler implementiert, die auf komplexe Gesten (etwa Streichgesten, Mehrpunkt-Gesten) ansprechen.

2. Prüfung

1. App mit zu prüfender Ansicht öffnen

2. Sichtprüfung und Ausprobieren, ob Inhalte komplexe Gesten implementieren (z.B. auf Karussels, Slidern), lassen sich Slider durch Streichgesten bewegen, Werden durch Streichgesten vom Rand her Menüs oder andere Inhalte eingeblendet, Reagieren bestimmte Elemente (etwa Karten) auf die Zwei-Finger-Spreizgeste zum Ändern des Zoomfaktors?

3. Prüfen, ob die über komplexe Zeigergesten auslösbare Funktion auch über einfache Zeiger-Gesten wie Tippen, Doppeltippen oder Tippen-und-Halten ausgelöst werden kann, etwa durch Aktivierung von alternativen statischen Elementen (z.B. Tasten, die Slider bewegen, Werte erhöhen oder verringern, oder Menüs einblenden)

3. Hinweise

• Ausgenommen sind Funktionen, die von Natur aus und notwendigerweise auf komplexen Pfaden oder Mehrpunktgesten basieren. So wird beispielsweise die Eingabe der eigenen Signatur von Natur aus pfadbasiert sein.

• Software für die verschiedenen Plattformen wie Windows, MacOS, iOS, Android usw. ist immer einzeln zu bewerten, da hier nicht davon ausgegangen werden kann, dass sich die Software auf jeder Plattform exakt gleich verhält.

4. Bewertung

Allgemein

• WCAG 2.1: Understanding Success Criterion 2.5.1: Pointer Gestures (zur Zeit nur auf Englisch verfügbar)

• Appt.org: Pointer Gestures: Provide altenatives for gestures (mehrere Entwicklungsumgebungen)

• W3C: Spezifikation PointerEvents

• W3C: Spezifikation TouchEvents

• W3C: Spezifikation UIEvents

iOS

• Appt.org: Input gestures on iOS

Android

• Appt.org: Input gestures on Android

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn auf der App-Ansicht Bedienelemente vorhanden sind.

2. Prüfung

1. Auf einem Gerät mit Touchscreen die Bedienelemente der Ansicht (z.B. Schalter, Links) berühren, den Finger kurz liegen lassen.

2. Beobachten, ob nun schon eine Funktion ausgelöst wird (z.B. Aufruf einer anderen Ansicht, eines Einblendbereichs oder eines Dialogs).

3. Wenn keine Funktion ausgelöst wird, Finger vom Punkt der Berührung wegbewegen und dann loslassen. Dadurch wird in der Regel der Aufruf des Links oder der Funktion vermieden, selbst wenn der berührte Punkt dem Finger folgt (die Ansicht gescrollt wird).

4. Wenn Funktionen beim Down-Event ausgelöst werden, prüfen, ob die Funktion abgebrochen oder rückgängig gemacht werden kann oder beim Up-Event wieder rückgängig gemacht wird.

5. Prüfen, ob festgestellte Down-Events als essenziell auszunehmen sind (siehe 3. Hinweise, 3.1 Ausnahmen)

3. Hinweise

4. Bewertung

Allgemein

• WCAG 2.1: Understanding SC 2.5.2 Pointer Cancellation (zur Zeit nur auf Englisch verfügbar)

• Appt.org: Pointer Cancellation: Support input cancellation (mehrere Entwickungsumgebungen)

• W3C: Spezifikation PointerEvents

• W3C: Spezifikation TouchEvents

• W3C: Spezifikation UIEvents

iOS

• Appt.org: Input cancellation on iOS

Android

• Appt.org: Input cancellation on Android

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar auf Bedienelemente, die entweder sich selbst beschriften (Links, Tasten) oder einem Bedienelement wie einem Texteingabefeld oder einer Checkbox direkt zugeordnet sind.

Auf Bedienelemente, die durch mehrere sichtbare Elemente beschriftet sind, ist der Prüfschritt nicht anwendbar, so wenn Elemente über eine tabellarische Matrix über Beschriftungen in Spalten- und Zeilenüberschriften ihren zugänglichen Namen empfangen. In diesen Fällen ist es für den Spracheingabe-Nutzer unklar, welche Elemente als Beschriftung des Bedienelements gelten und dementsprechend für ein Diktat per Spracheingabe benutzt werden sollten.

2. Prüfung

1. Sicherstellen, dass in den Bedienungshilfen des Betriebssystem automatische Texterkennungsfunktionen deaktiviert sind.

   • Bei VoiceOver ist dies die Einstellung "VoiceOver-Erkennung" und darunter die Optionen "Bildbeschreibung" und "Bildschirmerkennung". Beide sollten deaktiviert sein.

   • Bei Talkback heißt der Punkt "Automatische Beschreibungen" mit den Optionen "Symbole beschreiben" und "Text in Bildern beschreiben". Beide sollten deaktiviert sein.

2. Den Screenreader aktivieren und mit Hilfe der Wischgeste den Fokus der Reihe nach auf alle Bedienelemente mit Beschriftung setzen.

3. Die sichtbare Beschriftung sollte entweder

   • mit der Ausgabe des zugänglichen Namens durch den Screenreader übereinstimmen oder

   • zumindest teilweise in der Screenreader-Ausgabe enthalten sein.

3. Hinweise

4. Bewertung

iOS

• Der accessibilityInputLabels() Modifier kann dazu verwendet werden, bei Bedienelementen weitere Labels zu hinterlegen, die Nutzenden der Funktion Sprachsteuerung as Aktivieren von Elementen erleichtern - z.B. Synonyme oder kürzere Ausdrücke bei längeren sichtbaren Labeln. Siehe Hacking with Swift: How to add custom activation commands for Voice Control

• Eric Bailey, Smashing Magazine: Voice Control Usability Considerations For Partially Visually Hidden Link Names

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App bestimmte Bewegungseingaben definiert, etwa die Bewegung durch eine 360-Grad-Rundumansicht durch ein Rotieren des Geräts, oder das Blättern durch eine Folge von Präsentationsfolien durch ruckartige Seitwärtsbewegungen.

2. Prüfung

1. Über Bewegungen prüfen, ob die App in irgend einer Weise auf Bewegungseingaben reagiert.

2. Für alle Funktionen, die über Bewegungseingabe ausgelöst werden, prüfen, ob alternative Eingabemöglichkeiten über Bedienelemente bestehen.

3. Prüfen, ob sich vorhandene Bewegungseingaben abschalten lassen.

3. Bewertung

Allgemein

• Appt.org: Motion Actuation: Add alternatives for motion activated actions

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar.

2. Prüfung

1. In den Einstellungen des Betriebssystems eine andere Sprache als die der App wählen.

2. Alternativ die Sprache der App auf eine andere Sprache als die des Betriebssystems setzen. Dazu in den Betriebssystem-Einstellungen die App aufrufen und dort die Sprache ändern (beispielsweise unter iOS möglich).

3. Prüfen, ob trotz unterschiedlicher System- und App-Sprache die Begriffe in der App vom Screenreader noch in der App-Sprache ausgegeben werden. Oder werden sie fälschlich nach Ausspracheregeln der Systemsprache gesprochen?

3. Hinweise

Für Hinweise zur Prüfpraxis erstellen Sie gerne ein Issue auf GitHub.

4. Bewertung

Allgemein

• Appt.org: Language of Page: Set a language

iOS

• Changing the development language of an Xcode project, (Ralf Ebert, 2019)

Android

• How to change the app language programmatically in android?, (Azhar, 2019)

• How to Change the Whole App Language in Android Programmatically?, (Ankur Pal, 2021)

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App interaktive Elemente enthält.

2. Prüfung

1. Tastatur über Bluetooth-Kopplung oder USB-Kabel anschließen.

2. App mit zu prüfender Ansicht aufrufen

3. Mit der Tab-Taste alle Elemente in der Ansicht durchgehen und dabei prüfen, ob es eine unerwartete Kontextänderung gibt (etwa Pop-up-Fenster oder automatisches Abschicken von Formularen)

3. Hinweise

Der Prüfschritt bezieht sich nur auf das Öffnen von neuen Ansichten, nicht auf Elemente, die den Inhalt überlagern (Stichwort modaler Dialog).

Das Öffnen von Custom Tooltips, also nicht modalen Fenstern, die sich beim Weitertabben oder Touch-Eingaben selbständig schließen, gilt dabei nicht als Kontextänderung.

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Ansicht in der Software Formularelemente enthält.

2. Prüfung

1. App mit zu prüfender Ansicht starten

2. Formularelemente (Checkboxes, Radio Buttons, Auswahllisten) aktivieren. Werden unerwartete und nicht angekündigte Kontextänderungen erzeugt?

3. Überprüfen, ob Inhaltsänderungen hervorgerufen werden (etwa Einblendungen zusätzlicher Formularfelder). Sind die Inhaltsänderungen begrenzt und gut nachvollziehbar oder werden vor dem auslösenden Element angekündigt bzw. erklärt?

4. Prüfen, ob Inhaltsänderungen unterhalb des Elements, das sie auslöst, hervorgerufen werden.

5. Prüfen, ob durch Formulareingaben hervorgerufene Kontextänderungen (etwa dynamisch eingeblendete Elemente) den aktuellen Fokus versetzen,

3. Hinweise

Dynamische Änderungen, etwa die automatische Einblendung von Vorschlägen unterhalb des Texteingabefelds einer Such-Funktion, sollen nicht den aktuellen Fokus versetzen.

4. Bewertung

Abgrenzung von anderen Prüfkriterien

• Die Verwendung von Submit-Buttons, die in den Techniken G80 und H32 dem Success Criterion On input zugeordnet ist, wird nur indirekt im Prüfschritt 11.2.1.1 "Tastaturbedienung" geprüft.

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die Ansicht Formulare enthält, welche bei inkorrektem Ausfüllen Fehlermeldungen erzeugen. Dies kann schon während der Eingabe oder erst nach dem Abschicken des Formulars geschehen.

2. Prüfung

1. Formular unvollständig oder fehlerhaft ausfüllen, etwa durch das Leerlassen von Pflichtfeldern oder das Eingeben syntaktisch nicht korrekter Email-Adressen.

2. Falls das Abschicken des Formulars eine Fehlermeldung erzeugt: Prüfen, ob die betroffenen Felder identifiziert sind. Dies kann, auch abhängig von der Länge des Formulars auf verschiedene Art geschehen:

   • Bei Neuanzeige des Formulars werden am Beginn der Ansicht fehlerhaft ausgefüllte Felder identifiziert.

   • Fehlerhaft ausgefüllte Felder werden zusätzlich deutlich hervorgehoben.

   • Die Labeltexte fehlerhaft ausgefüllter Felder ändern sich oder werden erweitert, um auf die Fehler darstellungsunabhängig hinzuweisen.

   • Fehlermeldungen werden mit geeigneten Techniken bereitgestellt.

3. Prüfen, ob nach Korrektur der Eingaben und erneutem Abschicken des Formulars zuvor angezeigte Fehlermeldungen verschwinden.

3. Hinweise

• Wenn serverseitig eine Fehlermeldung in einer neuen Ansicht ausgegeben wird, wird diese wie ein Zustand unter der Ausgangsansicht mitgeprüft. Geprüft wird auch die Erfüllung anderer relevanter Prüfkriterien.

• Wenn Formulare keine Fehlermeldungen erzeugen, ist dies nicht negativ zu bewerten.

4. Bewertung

Allgemein

• Appt.org: Error Identification: Show errors (mehrere Entwicklungsumgebungen)

Einordnung des Prüfschritts nach WCAG 2.1

Warum wird nicht grundsätzlich bei allen Formularen eine Fehlerüberprüfung verlangt?

Eine Fehlerbehandlung ist oft sinnvoll, aber nicht grundsätzlich bei allen Formularen. Das hängt ab vom Zweck des Formulars und der Art des Angebots. So kann es unter Umständen sinnvoll sein, grundsätzlich alle Eingaben, auch solche mit Fehlern, zu verwerten.

Wenn jedoch irgendwelche Fehlermeldungen generiert werden, müssen diese brauchbar sein. Das wird in diesem Prüfschritt überprüft.

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App-Ansicht Formularelemente enthält.

2. Prüfung

1. App mit zu prüfender Ansicht öffnen.

2. Sind Beschriftungen vorhanden?

3. Sind alle Formularelemente beschriftet?

4. Sind Pflichtfelder in label- oder legend-Elementen klar angezeigt? Wenn zur Anzeige Symbole wie etwa ein Sternchen (*) genutzt werden, sollte deren Bedeutung am Beginn des Formulars erklärt sein.

5. Wenn Eingabefelder ein bestimmtes Eingabeformat vorgeben, wird dieses in der Beschriftung klar beschrieben? (Beispiele wären "Format der Datumseingabe: TT.MM.JJJJ" oder "Telefonnummer: Nur Zahlen ohne Leerstellen oder Bindestriche eingeben".)

6. Sind Beschriftungen richtig positioniert?

3. Hinweise

Eine Textvorbelegung ist keine ausreichende visuelle Beschriftung im Sinne dieses Prüfschritts. Sie verschwindet bei (auch versehentlichen) Nutzereingaben.

Bei kombinierten Eingabeelementen hat nicht immer jedes Element eine zugeordnete Beschriftung. In diesem Fall sollen Elemente mit einem unsichtbaren erklärenden Label versehen werden, welches dann von einem Screenreader ausgegeben werden kann. Beispiel: In einem Formular werden für die Eingabe eines Datums drei Auswahllisten angeboten (Tag, Monat und Jahr). Die drei Auswahllisten haben eine gemeinsame Beschriftung: Datum. Die Auswahllisten für Tag, Monat und Jahr sind jeweils mit einem unsichtbaren erklärenden Label für die programmatische Ausgabe an Hilfsmittel versehen.

Wenn ein einfaches Suchformular nur aus einem Eingabefeld und einem grafischen Schalter (etwa ein Lupen-Icon) besteht, ist oftmals keine sichtbare Beschriftung notwendig. Hier ist es ausreichend, wenn Eingabefeld und Schalter direkt nebeneinander positioniert sind. Hinweis: Eingabefelder, die nur über einen nachfolgenden grafischen Schalter beschriftet sind, müssen zudem eine programmatisch verfügbare Beschriftung haben, da für Screenreader-Nutzer der nachfolgende Schalter nicht als Beschriftung ausreicht.

Es kann sinnvoll sein, dass bei Formularen Hinweise zum Eingabeformat oder zu ausgelösten Aktionen einmal am Beginn des Formulars stehen statt vor jedem einzelnen Eingabefeld.

4. Bewertung

Allgemein

• Appt.org: Labels or Instructions: Use input labels (mehrere Entwicklungsumgebungen)

iOS

• Orange Accessibility Guidelines: iOS Developer Guide: Element trait

• Orange Accessibility Guidelines: iOS Developer Guide: Grouping elements

Android

• Orange Accessibility Guidelines: Android develop - Input screen: Explicitly label input fields

• Orange Accessibility Guidelines: Group the elements

• Appt.org: Input label on Android

Abgrenzung von anderen Prüfschritten

In diesem Prüfschritt geht es um sichtbare Beschriftungen. Das Vorhandensein programmatisch ermittelbarer Namen von Formularelementen wird dagegen in Prüfschritt 11.1.3.1d "Info und Beziehungen - Formularelemente" geprüft.

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App-Ansicht Formulare enthält, welche bei inkorrektem Ausfüllen Fehlermeldungen erzeugen. Dies kann schon während der Eingabe oder erst nach dem Abschicken des Formulars geschehen.

2. Prüfung

Formular unvollständig oder fehlerhaft ausfüllen, etwa durch das Leerlassen von Pflichtfeldern oder das Eingeben syntaktisch nicht korrekter Email-Adressen.

Falls das Abschicken des Formulars eine Fehlermeldung erzeugt: Prüfen, ob Fehlermeldungen oder Korrekturvorschläge verständlich und sinnvoll sind.

Fehlermeldungen oder Korrekturvorschläge können auf verschiedene Weise zur Verfügung gestellt werden, z.B.:

• Bei Neuanzeige des Formulars werden am Beginn der Ansicht Fehler beschrieben

• Korrekturvorschläge werden nahe der betroffenen Eingabefelder angezeigt und mit einer geeigneten Technik verknüpft

3. Hinweise

Wenn eine Fehlermeldung auf einer neuen Ansicht ausgegeben wird, wird diese wie ein Zustand der Ansicht unter der Ausgangsansicht mitgeprüft. Geprüft wird auch die Erfüllung anderer relevanter Prüfkriterien.

Bei komplizierten Formaten, z.B. Datum, hilft eine Angabe, in welcher Weise das Datum eingegeben werden soll (z.B. tt.mm.jjjj), um Fehler zu vermeiden.

Wenn Formulare keine Fehlermeldungen erzeugen, ist dies nicht negativ zu bewerten.

4. Bewertung

Allgemein

• Appt.org: Error Suggestion: Provide solutions for errors (mehrere Entwicklungsumgebungen)

Abgrenzung von anderen Prüfkriterien

• Die Identifizierung und Benennung des Fehlers ist Gegenstand des Prüfschritts 11.3.3.1 "Fehlererkennung". Hier geht es um die Angemessenheit und Verständlichkeit der Fehlermeldung(en) selbst.

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App-Ansicht Formulare für Transaktionen enthält, durch die Nutzer rechtlich bindende Verpflichtungen eingehen. Dazu gehören Online-Bestellvorgänge und andere finanzielle Transaktionen.

2. Prüfung

Formular mit Beispieldaten ausfüllen und Prozess fortsetzen. Eine der folgenden drei Optionen soll erfüllt sein:

• Datenanzeige mit Korrekturmöglichkeit, die eingegebenen Daten werden dem Benutzer vor dem Abschicken noch einmal angezeigt, es gibt an dieser Stelle die Möglichkeit, die Daten zu korrigieren

• Bestätigung. Das Abschicken erfolgt erst nach Bestätigung eines Dialogs, der die Konsequenzen der Transaktion beschreibt

• Unmittelbare Rückabwicklung, die Transaktion (etwa das Löschen von angelegten Datensätzen) kann unmittelbar rückgängig gemacht werden

3. Hinweise

Eine Checkbox oberhalb des "Abschicken"-Buttons zur Bestätigung der Richtigkeit von Benutzereingaben ist ein wesentlich schwächeres Instrument als die Anzeige der kompletten Eingabe auf einer neuen Ansicht vor dem endgültigen Abschicken des Formulars. Solche Checkboxen werden häufig für formalrechtlich relevante Funktionen genutzt, wie etwa die Bestätigung der Geschäftsbedingungen eines Anbieters. Sie werden deshalb von vielen Benutzern nicht richtig wahrgenommen und routinemäßig gesetzt. Für die Bestätigung wichtiger Eingaben sind sie deshalb weniger geeignet.

Erfolgreiche Eingaben sollten nach dem Abschicken bestätigt werden.

4. Bewertung

Allgemein

• Appt.org: Error Prevention (Legal, Financial, Data): Use a dialog for confirmation (mehrere Entwicklungsumgebungen)

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts:

Der Prüfschritt ist prinzipiell nur anwendbar, wenn die App Inhalte in Markup-Sprachen (in der Regel in Webviews) enthält.

2. Prüfung

Es wird lediglich geprüft, ob die App Webviews enthält. Ein sicheres Anzeichen dafür ist die Ausgabe "Webview" bei Fokussierung von Webview-Inhalten, ein weiteres Anzeichen die Ausgabe von Elementen, die in nativen Apps in der Regel nicht vorkommen, z.B. Überschriften auf verschiedenen Ebenen.

3. Hinweise

Wenn nicht eindeutig festzustellen ist, ob die App Webviews enthält, sollte der Prüfschritt mit "nicht anwendbar" bewertet werden.

4. Bewertung

Allgemein

• Appt.org: Parsing: Make use of linting (mehrere Entwicklungsumgebungen)

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar, wenn die App Bedienelemente einsetzt. Aus Sicht der prüfenden Person ist nicht immer zu erkennen, ob Standardelemente der Entwicklungsumgebungen verwendet werden (und damit quasi von Haus aus zugänglich sind) oder von Entwicklerinnen und Entwicklern selbst definiert wurden. Eine Sichtprüfung reicht deshalb nicht aus. Bedienelemente müssen mit dem Screenreader fokussiert und aktiviert werden, um festzustellen, ob die passende Namen, Rollen und Werte vom Screenreader ausgegeben und auch Zustandsänderungen richtig kommuniziert werden.

2. Prüfung

Für eine Prüfung mit VoiceOver / iOS müssen die AI/OCR-Erkennungsfunktionen ausgeschaltet sein (siehe "3. Hinweise").

1. App mit zu prüfender Ansicht öffnen.

2. Screenreader starten und Fokus mit Hilfe der Wischgeste auf jedes interaktive Element setzen.

3. Prüfen, ob der Name, wo möglich die Rolle, und wo vorhanden der Wert des Bedienelements vom Screenreader korrekt ausgegeben werden (siehe auch "3. Hinweise").

4. Gegebenenfalls prüfen, ob der geänderte Wert des Elements (Zustand) nach Eingabe korrekt ausgegeben wird.

3. Hinweise

Der Name identifiziert und bezeichnet ein Element näher. Nutzende von Spracheingabe-Software können beispielsweise eine Schaltfläche mit Hilfe des zugänglichen Namens (der Beschriftung) gezielt ansprechen und bedienen. Ein Screenreader gibt den zugänglichen Namen aus, wenn das Element fokussiert wird. Er ist oft gleichlautend mit der sichtbaren Beschriftung (bzw. dem Label) des Bedienelements, z.B. "Nachname" für ein Eingabefeld.

Beispiele für Rollen sind u.a. "Taste" bzw. "Schalter" oder "Schaltfläche", "Eingabefeld" bzw. "Bearbeitungsfeld", "Suchfeld", "Ausklappliste", und "Markierungsfeld" bzw. "Umschalttaste".

Verglichen mit dem Web ist die Anzahl der verfügbaren Rollen in nativen Apps geringer. Nicht jedes interaktive Element verlangt zwingend die Ausgabe einer Rolle. Bei korrekter Nutzung nativer Elemente (z.B. item in Android) werden jedoch bei aktiviertem Screenreader automatisch Hinweise zur Aktivierung ausgegeben (z.B. "zum Auswählen doppeltippen") - wenn "Nutzungshinweise vorlesen" in den TalkBack-Einstellungen unter "Ausführlichkeit" aktiviert ist.

Der Wert beschreibt z.B. den Inhalt des Bedienelements, z.B. "Müller" bei einem Eingabefeld für Nachnamen. Er vermittelt aber auch den Zustand eines Elements (sofern es unterschiedliche Zustände haben kann), z.B. "ausgewählt" für ein ausgewählten Listeneintrag oder eine angekreuzte Checkbox.

4. Bewertung

Allgemein

• Appt.org: Set accessibility name (mehrere Entwicklungsumgebungen)

• Appt.org: Set accessibility role (mehrere Entwicklungsumgebungen)

• Appt.org: Set accessibility value (mehrere Entwicklungsumgebungen)

• Appt.org: Set accessibility state (mehrere Entwicklungsumgebungen)

iOS

• Apple Developer UIKit: UIAccessibilityTraits

• Apple Developer SwiftUI: AccessibilityTraits

Android

• Graeme Coleman, Tetralogical blog (07/2022): Android accessibility: roles and TalkBack

• Android Developers: Make apps more accessible

• Android Developers: android.accessibilityservice

• Medium article: State Descriptions on Android

• Orange Accessibility Guidelines: Vocalize the state of the elements

Abgrenzung von anderen Prüfschritten

In diesem Prüfschritt geht es nicht um die Bewertung der Tastaturbedienbarkeit von selbsterstellten Bedienelementen. Dies ist Gegenstand von Prüfschritt 11.2.1.1 "Tastaturbedienung".

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist anwendbar, wenn die App Statusmeldungen generiert, die nicht den Fokus erhalten. Er ist nicht anwendbar, wenn Meldungen im Zusammenhang mit Kontextänderungen erscheinen, zum Beispiel, wenn nach dem Abschicken eines Formulars (vom Nutzer initiiert) die Ansicht neulädt und dann vor dem Formular eine Fehlermeldung erscheint.

2. Prüfung

1. Zu prüfende Ansicht der App öffnen.

2. Statusmeldungen identifizieren. Dafür Eingaben vornehmen, die zur Generierung von Statusmeldungen führen.

3. Screenreader aktivieren.

4. Entsprechende Eingaben, die zur Generierung von Statusmeldungen führen, erneut vornehmen.

5. Wenn die App von sich aus Statusmeldungen generiert, diese Meldungen abwarten.

6. Prüfen, ob Statusmeldungen beim Erscheinen vom Screenreader ausgegeben werden, ohne dass der Fokus auf die Meldung versetzt wird.

3. Hinweise

Nicht als Statusmeldung gelten:

• Fehlermeldung über Dialog (Kontextänderung durch Fokusumsetzung)

• Die Hinzufügung von Bedienelementen, wie z.B. zusätzliche Formularelelemente

4. Bewertung

Allgemein

• WCAG 2.1: Understanding Success Criterion 4.1.3 Status Messages (zur Zeit nur auf Englisch verfügbar)

• WCAG 2.1, Definition einer Statusmeldung: Status Message

• Appt.org: Status Messages: Use accessibility announcements (mehrere Entwicklungsumgebungen)

iOS

• Orange Accessibility Guidelines: Trigger a vocalization

• Orange Accessibility Guidelines: Notify a content change

Android

• Orange Accessibility Guidelines: Vocalize content change

Einordnung des Prüfschritts nach WCAG 2.1

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar. Es wird hier stichprobenartig geprüft, ob der Barrierefreiheitsdienst Screenreader bei Nutzung der App generell in seinen Funktionen zur Verfügung steht. Es wird nicht geprüft, ob einzelne Elemente korrekt ausgezeichnet sind. Die korrekte Ausgabe von Name, Rolle und Wert muss hier entsprechend nicht erfüllt werden. Dies ist Gegenstand von anderen Prüfschritten, insbesondere 11.4.1.2 "Name, Rolle, Wert verfügbar".

2. Prüfung

3. Hinweise

Ob eine Ausgabe auf allen Elementen durchgängig erfolgt, ob also bei Fokussierung interaktiver Elemente Name Rolle und Wert ausgegeben werden, fällt in andere Prüfschritte, insbesondere 11.4.1.2 "Name, Rolle, Wert verfügbar", 11.1.3.1 "Informationen und Beziehungen" (Prüfschritte a - e), 11.1.1.1a "Alternativtexte für Bedienelemente", und 11.1.1.1b "Alternativtexte für Grafiken und Objekte".

"Barrierefreiheitsdienste- und Schnittstellen" beziehen sich jedoch nicht nur auf die Umsetzung von Steuerelementen. Auch eingebaute Sprachausgaben oder Vergrößerungsfunktionen sind solche Dienste. Eine App, die z.B. ohne besonderem Grund selbstsprechend ist (eingebaute Sprachausgabe), ohne dass diese App auch mit der System-Sprachausgabe-Software (z.B. VoiceOver und TalkBack) funktioniert, würde diesen Prüfschritt nicht bestehen.

4. Bewertung

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