BITV-Testvorgehen für mobile Applikationen
(BITV-APP-Test)

iOS-Support

• Übersicht der Bedienungshilfen

• Handbuch der Bedienungshilfen

• Support

iOS-Einstellungen

Die relevanten Einstellungen sind im Betriebssystem unter „Einstellungen/Bedienungshilfen“ zu finden. Sofern nicht explizit genannt, werden die Standardeinstellungen des Betriebssystems verwendet. Folgende Einstellungen werden empfohlen:

Allgemein

VoiceOver

Zoom

Anzeige & Textgröße

Bewegung

Tastatursteuerung

Untertitel

Android-Support

• Übersicht der Bedienungshilfen

• Handbuch der Bedienungshilfen

• Support

Android-Einstellungen

Die verschiedenen Hersteller der Android-Endgeräte implementieren oftmals eigene assistive Unterstützungen. Diese individuellen Unterstützungen finden hier keine Relevanz. Der Fokus liegt ausschließlich auf den Funktionalitäten von Android selbst.

Die relevanten Einstellungen sind im Betriebssystem unter „Einstellungen/Bedienungshilfen“ (manchmal auch „Einstellungen/Intelligente Unterstützung“) zu finden. Sofern nicht explizit genannt, werden die Standardeinstellungen des Betriebssystems verwendet. Folgende Einstellungen werden empfohlen:

Allgemein

TalkBack

Vergrößerung

Display

Audio

Untertitel

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App eigene, vom Standardumfang des Betriebssystems unabhängige, assistive Bedienungshilfen zur Verfügung stellt.

Anforderung

Bietet die Mobile App eigene assistive Unterstützungen an, so müssen die Funktionen für die jeweilige Zielgruppe barrierefrei auffindbar und aktivierbar sein. Nachdem verschiedene Funktionen für verschiedene Nutzergruppen bereitgestellt werden können, deren Anforderungen unterschiedlich sind, kann kein allgemein gültiges Vorgehen definiert werden.

Beispiele für individuelle Funktionen:

• Die Mobile App bietet eine Vorlesefunktion an.

• Die Mobile App bietet Inhalte in leichter Sprache oder Gebärdensprache an.

• Die Mobile App bietet das Verändern von Farben oder Kontrasten an.

• Die Mobile App bietet das Verändern von Schriftart, Schriftgröße oder Zeilenabstand an.

• Die Mobile App bietet Funktionen zum Vergrößern oder Verkleinern von Inhalten an.

Testvorgehen

• Prüfen, ob die individuelle Funktion durch die vorgesehene Nutzergruppe eindeutig identifizierbar ist.

• Prüfen, ob die individuelle Funktion durch die vorgesehene Nutzergruppe selbstständig aktivierbar ist.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Barrierefreiheitsfunktionen können Nutzergruppen mit verschiedenen Beeinträchtigungen helfen, die Inhalte der Seite nach den jeweiligen Bedürfnissen anzupassen. Hierzu ist es nötig, dass diese Funktionen von der betroffenen Nutzergruppe selbständig gefunden und aktiviert werden können.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 5.2 Activation of accessibility features

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App biometrische Merkmale zur Identifikation eines Nutzenden oder zum Log-In eines Nutzenden zur Verfügung stellt, beziehungsweise auf die biometrische Identifikation des Betriebssystems zurückgreift.

Anforderung

Bietet die Mobile App eine biometrische Identifizierungsmethode an, so darf der Identifikationsvorgang nicht nur auf das biometrische Merkmal beschränkt sein. Es muss mindestens eine weitere Identifizierungsmethode unterstützt werden. Eine Alternative zu einer biometrischen Identifizierungsmethode kann sowohl eine weitere biometrische Methode als auch eine nicht biometrische Methode sein.

Testvorgehen

• In den Einstellungen prüfen, ob der Identifikationsvorgang auf biometrische Merkmale umgestellt werden kann.

• Prüfen, ob zusätzlich zum aktuell gewählten, biometrischen Vorgang mindestens eine weitere Alternative zur Verfügung steht.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Anmeldeprozesse, die auf der Auswertung biometrischer Merkmale, wie zum Beispiel Fingerabdruck, Sprache oder Gesicht basieren, können dem Nutzenden den Zugang zum digitalen Produkt erleichtern. Für Menschen, die aufgrund einer Beeinträchtigung eine bestimmte biometrische Authentifizierung nicht nutzen können, ist eine geeignete Alternative nötig. Eine nicht biometrische Methode ist für die meisten Nutzenden bedienbar.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 5.3 Biometrics

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Konvertierungen von Inhalten der Mobile App in andere Formate zur Verfügung stellt.

Anforderung

Bietet die Mobile App Konvertierungsmöglichkeiten in andere Formate an, müssen bereits vorhandene Barrierefreiheitsinformationen und -Funktionen im Zielformat übernommen werden, wenn das Zielformat diese Informationen und Funktionen grundsätzlich unterstützt.

Testvorgehen

• Konvertierung oder Export durchführen und im Zielformat überprüfen, ob Barrierefreiheitsinformationen und Funktionen im Zielformat erhalten geblieben sind, bzw. ob das Zielformat den Anforderungen an Barrierefreiheit entspricht.

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

• Der jeweilige Umfang der Prüfung kann variieren und ist unter Umständen von den Empfehlungen oder Regularien von Bund oder Bundesland abhängig. Eine vollumfängliche Prüfung des Zielformats kann in diesem Prüfverfahren nicht durchgeführt werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Wenn das digitale Produkt Dokumente in Formate konvertiert, die grundsätzlich Barrierefreiheitsinformationen unterstützen, dann sollen diese im Zieldokument korrekt übernommen werden. Beim Konvertieren von Dokumenten in andere Formate soll beispielsweise sichergestellt sein, dass das Zieldokument auch mit Screenreadern erfassbar und bedienbar ist.

Abgrenzung

• Vollumfängliche Prüfungen von Dokumenten müssen über die jeweiligen relevanten Kapitel der EN 301549 durchgeführt werden (beispielsweise Kapitel 10 Non-web documents).

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 5.4 Preservation of accessibility information during conversion

• EN 301549 v3.2.1 Kapitel 10 Non-web documents

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App zum Ausführen bestimmter Funktionalitäten auf physische Bedienelemente des Endgeräts zurückgreift.

Anforderung

Greift die Mobile App zum Ausführen bestimmter Funktionalitäten auf physische Bedienelemente des Endgeräts zurück, die zur Bedienung ein Greifen, Zusammendrücken oder Drehen des Handgelenks erfordern, muss eine barrierefreie, alternative Möglichkeit der Bedienung zur Verfügung stehen, für die diese Handlungen nicht erforderlich sind. Alternative Bedienmethoden können Hardware- oder Software-Lösungen sein.

Testvorgehen

• Prüfen, ob alternative Bedienmethoden zur Verfügung stehen, die weder Greifen, Zusammendrücken oder Drehen des Handgelenks erfordern.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Motorisch beeinträchtigte Menschen können komplexe Bedien-Gesten gegebenenfalls nicht ausführen. Eine alternative Bedienmethode muss zur Verfügung gestellt werden, damit entsprechende Nutzergruppen die Bedienung durchführen können.

Abgrenzung

• Die Prüfung auf Steuerung durch Bewegung erfolgt in Prüfschritt 11.2.5.4 Steuerung durch Bewegung.

• Die Prüfung auf Alternativen für komplexe Gesten erfolgt in Prüfschritt 11.2.5.1 Alternativen für komplexe Gesten.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 5.5.1 Means of operation

Anwendbarkeit

Der Prüfschritt ist bei der Prüfung von Mobile Apps nicht anwendbar, da die Mobile App keine Möglichkeit hat, ein physikalisches Bedienelement des Endgeräts zu beschriften

Bewertungsalternativen und Beispiele

• Nicht anwendbar

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 5.5.2 Operable parts discernibility

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn eine Funktionalität einer Mobile App mit einem physischen Bedienelement des Endgeräts gesteuert werden kann und der Status des Steuerelements visuell dargestellt wird.

Anforderung

Kann eine Funktionalität der Mobile App mit einem physischen Bedienelement des Endgeräts gesteuert werden, und wird der Status des Steuerelements visuell dargestellt, muss zusätzlich zur visuellen Erkennung mindestens ein weiterer Modus zum Identifizieren des jeweiligen Status des Steuerelementes zur Verfügung stehen, entweder durch Berührung oder durch Audioausgabe.

Testvorgehen

• Den Status des Steuerelements verändern und prüfen, ob die Status des Steuerelements zusätzlich zur visuellen Erkennung auch auf einem anderen Weg ermittelbar sind, beispielsweise durch Berührung oder durch Audioausgabe.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Sehbeeinträchtigte und blinde Menschen können den Status von Bedienelementen visuell nicht unterscheiden und sind auf andere, geeignete Methoden zur Erkennung des Status angewiesen.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 5.6.1 Tactile or auditory status

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Bestandteil eines physischen Endgeräts ist, das ein physisches Steuerelement zum Verriegeln oder Umschalten zur Verfügung stellt und den Status des Steuerelements non-visuell (beispielsweise bei Berührung oder durch Audiowiedergabe) wiedergibt.

Anforderung

Bietet die Mobile App ein physisches Steuerelement zum Sperren oder Umschalten, und stellt den Status des Steuerelements non-visuell dar, muss zusätzlich zur vorhandenen Erkennungsmethode eine visuelle Identifizierung des jeweiligen Status des Steuerelementes zur Verfügung stehen.

Testvorgehen

• Den Status des Steuerelements verändern und prüfen, ob die Status des Steuerelements zusätzlich zur vorhandenen Erkennungsmethode auch visuell ermittelbar sind.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Einige Menschen unterschiedlicher Beeinträchtigungen sind auf die visuelle Erkennung des Status von Steuerelementen angewiesen, da andere Erkennungsmethoden für sie unter Umständen nicht zugänglich sind. So können beispielsweise Menschen mit Hörbeeinträchtigung eine Audioausgabe nicht wahrnehmen, oder Menschen ohne Sehbeeinträchtigung kein Braille lesen.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 5.6.2 Visual status

Anwendbarkeit

Der Prüfschritt ist bei Mobile Apps nicht anwendbar. Zum derzeitigen Stand der Möglichkeiten bietet lediglich das Betriebssystem iOS die Möglichkeit, die Tastenwiederholung zu konfigurieren. Zudem besteht die Möglichkeit, die Tastenwiederholung abzuschalten. Damit ist das Kriterium nicht mehr Bestandteil der Anforderung.

Die entsprechenden Einstellungen sind im iOS-Betriebssystem unter „Bedienungshilfen/Tastaturen/Tastenwiederholung/Wiederholungsintervall“ zu finden. Die Software-Tastatur bei iOS, als auch das Android-Betriebssystem bieten keine entsprechende Unterstützung dieser Funktionalität.

Bewertungsalternativen und Beispiele

• Nicht anwendbar

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 5.7 Key repeat

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Eingabefelder für Texteingaben zur Verfügung stellt. Die Anwendbarkeit gilt gleichermaßen für Mobile Apps auf Mobiltelefonen, als auch für Mobile Apps, die Bestandteil eines physischen Endgeräts sind, das eine physische Tastatur zur Verfügung stellt.

Anforderung

Individuelle Benutzereinstellungen zur Anschlagsverzögerung, die im Betriebssystem konfigurierbar sind, müssen von der Mobile App übernommen werden. Die Mindestforderungen lauten:

• Zeitverzögerung von mindestens 0,5 Sekunden vor der Annahme eines weiteren Tastenanschlags

Sofern die Mobile App die Einstellungen des Betriebssystems nicht übernimmt, kann sie eine eigene Konfigurationsmöglichkeit zur Verfügung stellen.

Testvorgehen

Die Prüfung kann zum derzeitigen Stand der Möglichkeiten auf Mobiltelefonen nur mittels einer externen Tastatur auf iOS-Geräten durchgeführt werden. Die entsprechenden Einstellungen sind im iOS-Betriebssystem unter „Bedienungshilfen/Tastaturen/Tastenwiederholung/Ansprechverzögerung“ zu finden. Die Software-Tastatur bei iOS, als auch das Android-Betriebssystem bieten keine entsprechende Unterstützung dieses Kriteriums.

• Auf Mobiltelefonen: Externe Tastatur verbinden und die Anschlagsverzögerung durch mehrfaches, schnelles Drücken derselben Taste prüfen. Die Annahme desselben Zeichens durch mehrfaches Drücken der Taste muss entsprechend dem konfigurierten Intervall reagieren.

• Auf physischen Endgeräten mit physischer Tastatur: Die Einstellungsmöglichkeiten auf Konfigurationsparameter zur Anschlagsverzögerung prüfen. Sofern vorhanden, entsprechende Konfiguration vornehmen und prüfen, ob die Annahme desselben Zeichens durch mehrfaches Drücken derselben Taste dem konfigurierten Intervall entspricht.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen, die aufgrund motorischer Beeinträchtigungen mehr Zeit für Bewegungen mit den Armen oder Fingern benötigen, sind unter Umständen auf ein längeres Intervall bei Verwendung von Tastaturen angewiesen. Mit genug Zeit vor der Annahme eines weiteren Tastenanschlags werden so Fehleingaben vermieden.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 5.8 Double-strike key acceptance

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Funktionalitäten zur Verfügung stellt, für deren Bedienung gleichzeitige Benutzeraktionen oder komplexe Touch-Gesten mit mindestens zwei Fingern erforderlich sind.

Anforderung

Sofern die Mobile App zum Betrieb oder zur Bedienung gleichzeitige Benutzerhandlungen oder komplexe Touch-Gesten mit mindestens zwei Fingern erfordert, muss sie einen alternativen Bedienmodus bereitstellen, der keine gleichzeitigen Benutzerhandlungen für den Betrieb oder die Bedienung benötigt.

Anmerkung: beide Hände benutzen zu müssen, um beispielsweise ein Mobiltelefon aufzuklappen, oder um eine ausklappbare Tastatur zu öffnen, zwei oder mehr Tasten gleichzeitig drücken zu müssen, oder eine Oberfläche mit mehr als einem Finger berühren zu müssen sind Beispiele für gleichzeitige Benutzerhandlungen.

Testvorgehen

• Prüfen, ob es einen alternativen Bedienmodus zum Ausführen der entsprechenden Aktion gibt, die keine der in den Anforderungen definierten, gleichzeitigen Benutzerhandlungen erfordert.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Motorisch beeinträchtigte Menschen können komplexe oder gleichzeitige Benutzerhandlungen gegebenenfalls nicht ausführen. Daher soll es in Mobile Apps mindestens eine einfach anzuwendende Alternative geben, um entsprechende Aktionen auszuführen.

Abgrenzung

• Einfache Touch-Gesten, die zur Bedienung innerhalb einer Mobile App notwendig sind (beispielsweise bei Karten-Apps zum Zoomen, Bewegen oder Vergrößern), werden über den Prüfschritt 11.2.5.1 Alternativen für komplexe Gesten geprüft.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 5.9 Simultaneous user actions

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App eine Funktion zur Zwei-Wege-Sprachkommunikation zur Verfügung stellt.

Anforderung

Zum Sicherstellen von entsprechender Sprachverständlichkeit bei der Zwei-Wege-Sprachkommunikation soll zum Kodieren und Dekodieren von Audio ein Frequenzbereich genutzt werden, dessen obere Grenze bis mindestens 7.000 Hz reicht. Dieser Frequenzbereich kann beispielsweise mit dem Standard-Codec G.722 [i.21] erreicht werden.

Testvorgehen

Sollte der verwendete Codec in der Dokumentation der Mobile App auffindbar sein und der Empfehlung G.722 [i.21] entsprechen, gilt der Prüfschritt als bestanden.

Falls keine Informationen in der Dokumentation vorhanden sind, muss die Sprachqualität der Audio-Verbindung in der Praxis beurteilt werden.

• Über die Mobile App auf zwei Endgeräten mindestens drei exemplarische Anrufe tätigen und die Qualität der Sprache subjektiv beurteilen.

• Sofern die App eine Verbindung über IP-Telefonie herstellt, ist sicherzustellen, dass die Internetverbindung auf beiden Seiten mit entsprechender Kapazität zur Verfügung steht.

• Entspricht die Qualität aktueller Festnetztelefonie, gilt der Prüfschritt als bestanden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Klare und gut verständliche Audioqualität bei der Zwei-Wege-Kommunikation ist besonders für Menschen mit Hörbeeinträchtigungen essenziell. Über einen verbindlichen Mindeststandard für Audioqualität soll diese Anforderung erfüllt werden.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.1 Audio bandwith for speech

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App eine Zwei-Wege-Sprachkommunikation zur Verfügung stellt.

Anforderung

Zusätzlich zur Zwei-Wege-Sprachkommunikation via Sprach- oder Videotelefonie, muss die Mobile App eine Textkommunikation in Echtzeit (RTT = Real-Time Text) zur Verfügung stellen.

Bei RTT handelt es sich um Text, der sofort übertragen wird, während er eingegeben oder erstellt wird. Dadurch können die Empfänger die Nachricht sofort lesen, während sie geschrieben wird.

Testvorgehen

• Die Textkommunikation auf zwei Endgeräten verwenden und prüfen, ob die Eingaben des Versenders in Echtzeit (also zum Zeitpunkt des Tippens) beim Empfänger korrekt und ohne merkbare Latenz einsehbar sind. Ist dies der Fall, ist der Prüfschritt erfüllt.

• Bietet die Mobile App keine Echtzeit-Textkommunikation an, ist der Prüfschritt nicht erfüllt.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen, die Sprache zur Kommunikation nicht nutzen können oder wollen, erhalten die Möglichkeit, über Echtzeit-Textkommunikation (RTT) an Konversationen in der entsprechenden Mobile App teilzunehmen.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.2.1.1 RTT communication

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Zwei-Wege-Sprachkommunikation und Textkommunikation in Echtzeit (RTT) zur Verfügung stellt.

Anforderung

Bietet die Mobile App Zwei-Wege-Sprachkommunikation via Sprach- oder Videotelefonie und Textkommunikation in Echtzeit (RTT), sollen beide Kommunikationskanäle gleichwertig genutzt werden können.

Testvorgehen

• Funktionen wie „Handheben“ oder „abwechselnde Kommunikation (beispielsweise die Darstellung des aktuellen Sprechers im Fokus)“ auf ihre Gleichwertigkeit gegenüber Sprach- und Textnutzenden prüfen. Dazu gegebenenfalls ein Konferenzszenario mit mehreren Testern und Endgeräten simulieren.

• Wird sowohl eine Chat-Funktion als auch Echtzeit-Text (RTT) angeboten, sollen beide Funktionen separiert voneinander verwendbar sein.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen, die Sprache zur Kommunikation nicht nutzen können oder wollen, sollen im Vergleich zu Sprachnutzenden gleichwertig behandelt werden.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.2.1.2 Concurrent voice and text

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Echtzeit-Textkommunikation (RTT = Real-Time Text) zur Verfügung stellt.

Anforderung

Bietet die Mobile App Echtzeit-Textkommunikation (RTT) an, sollen gesendete und empfangene Nachrichten visuell hinreichend voneinander unterscheidbar sein.

Testvorgehen

• Die Echtzeit-Textkommunikation auf zwei Endgeräten verwenden und die Darstellung von gesendeten und empfangenen Nachrichten auf deutliche Unterscheidbarkeit analysieren:

  • Abgrenzung der Nachrichten, beispielsweise durch Rahmen, Schattierung oder Hintergrundfarben

  • Benennung von Sender und Empfänger (beispielsweise namentlich, zusätzlich mit Bild)

  • Eindeutige Positionierung von Sender und Empfänger

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen, die Echtzeit-Textkommunikation verwenden, sollen gesendete und empfangene Nachrichten visuell einfach und hinreichend voneinander unterscheiden können.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.2.2.1 Visually distinguishable display

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Echtzeit-Textkommunikation (RTT = Realtime Text) zur Verfügung stellt.

Anforderung

Bietet die Mobile App Echtzeit-Textkommunikation (RTT) an, sollen Sende- und Empfangsrichtung der gesendeten und empfangenen Nachrichten programmatisch ermittelbar sein.

Testvorgehen

• Screenreader aktivieren.

• Die Textkommunikation auf zwei Endgeräten verwenden und die programmatische Ermittelbarkeit von Sender und Empfänger und den zugehörigen Nachrichten durch Antippen analysieren:

  • Benennung von Sender und Empfänger

  • Wiedergabe der Nachrichten und Identifikation von Sender und Empfänger im Kontext

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen, die Echtzeit-Textkommunikation in Verbindung mit einem Screenreader verwenden, sollen gesendete und empfangene Nachrichten hinreichend voneinander unterscheiden können.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.2.2.2 Programmatically determinable send and receive direction

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Echtzeit-Textkommunikation (RTT = Realtime Text) zur Verfügung stellt, und dabei den aktiven Sprecher anhand der Sprache identifiziert:

Anforderung

Bietet die Mobile App Echtzeit-Textkommunikation (RTT) an und identifiziert den aktiven Sprecher anhand der Sprache, sollen auch Menschen, die Texteingaben anstatt Sprache verwenden, gleichwertig identifiziert werden.

Testvorgehen

• Video- oder Sprachanruf auf zwei Endgeräten herstellen.

• Über eines der Endgeräte Video- oder Sprachtelefonie, über das andere Endgerät Texteingabe nutzen.

• Prüfen, ob während der Texteingabe der Nutzende im Vergleich zu sprechenden Nutzenden gleichwertig identifiziert, markiert bzw. hervorgehoben wird.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Für Teilnehmer in einer Kommunikation ist die Identifikation des aktiven Redners essenziell, um im Kontext entsprechend reagieren zu können. Sprache und Text müssen daher gleichwertig behandelt werden.

Abgrenzung

• Die Identifizierung von genereller Audioaktivität wird über den Prüfschritt 6.2.2.4 Anzeige von Audioaktivität in Echtzeit geprüft.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.2.2.3 Speaker identification

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Zwei-Wege-Sprachkommunikation und Textkommunikation in Echtzeit (RTT) zur Verfügung stellt.

Anforderung

Bietet die Mobile App Zwei-Wege-Sprachkommunikation via Sprach- oder Videotelefonie und Textkommunikation in Echtzeit (RTT), so muss Audioaktivität von Teilnehmern in Echtzeit visualisiert werden. Der visuelle Indikator muss gleichermaßen programmatisch ermittelbar sein.

Testvorgehen

• Video- oder Sprachanruf auf mindestens zwei oder mehr Endgeräten herstellen.

• Über eines der Endgeräte Audioaktivität übermitteln.

• Prüfen, ob die Audioaktivität des entsprechenden Teilnehmers auf den verbleibenden Endgeräten visuell identifizierbar ist.

• Screenreader aktivieren.

• Prüfen, ob die Audioaktivität des entsprechenden Teilnehmers auf den verbleibenden Endgeräten programmatisch ermittelbar ist.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Für Teilnehmer in einer Kommunikation ist die Identifikation von Audioaktivität in Verbindung mit dem entsprechenden Teilnehmer essenziell, um im Kontext die jeweilige Aktivität dem Teilnehmer zuordnen zu können.

Abgrenzung

• Die Identifizierung des aktiven Sprechers wird über den Prüfschritt 6.2.2.3 Sprecheridentifizierung geprüft.

• Die Identifizierung des aktiven Sprechers bei Videotelefonie wird über den Prüfschritt 6.5.5 Visuelle Anzeige von Audioaktivität geprüft.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.2.2.4 Visual indicator of Audio with RTT

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Zwei-Wege-Sprachkommunikation und Textkommunikation in Echtzeit (RTT) zur Verfügung stellt, und wenn die Mobile App in der Lage ist, mit einer anderen Mobile App des gleichen Funktionsumfangs zu kommunizieren.

Anforderung

Bietet die Mobile App Zwei-Wege-Sprachkommunikation via Sprach- oder Videotelefonie und Textkommunikation in Echtzeit (RTT), und unterstützt sie zudem die Nutzung dieser Funktionen in Kombination mit anderen Mobile Apps desselben Funktionsumfangs, so muss die Interoperabilität auf Basis der relevanten, technischen Standards unterstützt werden.

Die EN 301549 benennt dabei folgende Standards:

• Kommunikation über das öffentliche Telefonnetz: ITU-T V.18 [i.23] oder dessen Text-Telefonie-Standards in den Anhängen werden verwendet

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

• Voice over IP (VoIP) über das IP Multimedia Sub-System (IMS): Protokolle ETSI TS 126 114 [i.10], ETSI TS 122 173 [i.11] und ETSI TS 134 229 [i.12] werden verwendet

• Andere Kommunikationsmethoden: Gemeinsame, relevante und veröffentlichte Standards werden verwendet

Testvorgehen

• Falls vorhanden, Dokumentation der Mobile App prüfen und analysieren, ob die verwendeten Standards angegeben sind und den Empfehlungen der EN 301549 entsprechen.

• Falls keine Dokumentation vorhanden ist, müssen der Anbieter der Mobile App kontaktiert und die verwendeten Standards in Erfahrung gebracht werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Die Verwendung technischer Standards stellt soweit möglich eine gleichbleibende und verlässliche Funktionalität auch anwendungsübergreifend sicher. Mit Hilfe derartiger Standards sollen Menschen bei der Wahl der Anwendung nicht unnötig eingeschränkt werden.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.1.1 Kapitel 6.2.3 Interoperability

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Echtzeit-Textkommunikation (RTT = Realtime Text) zur Verfügung stellt.

Anforderung

Bietet die Mobile App Echtzeit-Textkommunikation (RTT = Realtime Text), so darf die Dauer der Übertragung von einem Endgerät auf ein anderes Endgerät für die kleinste Texteinheit (einzelne Zeichen, kurze Worte) maximal 1000 Millisekunden (= 1 Sekunde) betragen.

Testvorgehen

Der Prüfschritt kann nur unter Laborbedingungen belastbar getestet werden. Während eines Blackbox-Tests in der Praxis, kann zwischenzeitlich nur eine subjektive Überprüfung vorgenommen werden.

• Die Textkommunikation auf zwei Endgeräten verwenden und bei der Übertragung der Texteingaben darauf achten, dass die Inhalte unmittelbar während der Eingabe (maximal innerhalb 1 Sekunde) auf dem empfangenden Endgerät angezeigt werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen, die über Echtzeit-Textkommunikation (RTT = Realtime Text) und nicht über Sprache an einer Online-Kommunikation teilnehmen, dürfen gegenüber Sprachnutzenden nicht benachteiligt werden. Die Texteingaben sollen gleichwertig zu Sprache unmittelbar bzw. nur mit geringer Latenz für andere Teilnehmer in der Konferenz angezeigt werden.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.2.4 RTT responsiveness

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Sprach- oder Videotelefonie mit Anrufer-Identifikation zur Verfügung stellt.

Anforderung

Bietet die Mobile App Sprach- oder Videotelefonie mit Anrufer-Identifikation, so muss die Anrufer-Identifikation visuell in Textform, und programmatisch identifizierbar sein.

Testvorgehen

• Screenreader auf dem Endgerät aktivieren, das angerufen wird.

• Sprach- oder Videoanruf starten:

  • Visuelle Anrufer-Identifikation prüfen: der Anrufer muss in Textform identifiziert werden. Je nachdem ob sich der Kontakt im Telefonbuch befindet, kann entweder die Telefonnummer oder der jeweilige Kontakteintrag in Textform angezeigt werden

  • Programmatische Anrufer-Identifikation prüfen: die in Textform angezeigte Anrufer-Identifikation muss durch den Screenreader automatisch und ohne Umwege ermittelbar sein und ausgegeben werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Über die Anruferkennung wird sichergestellt, dass sowohl visuelle Menschen als auch Nutzende von assistiven Systemen einen Anrufer eindeutig und schnell identifizieren können.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.3 Caller ID

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Sprach- oder Videotelefonie mit Voicemail-Funktion zur Verfügung stellt.

Anforderung

Bietet die Mobile App Sprach- oder Videotelefonie mit Voicemail-Funktion, so muss die Nutzung dieser Dienste, die in aller Regel sprachbasiert gesteuert werden, auch ohne Sprech- oder Hörvermögen nutzbar sein.

Testvorgehen

Überprüfung der sprachbasierten Funktionen auf alternative Bedienungsmethoden:

• Auffinden von alternativen Zugangsmethoden wie Bedien-Menüs oder Formularsteuerung.

• Prüfung auf vollständige Konfigurationsmöglichkeit mit Fokus auf Bedienung ohne Hör- oder Sprechvermögen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen mit Beeinträchtigungen des Hörvermögens und des Sprechens können sprachbasierte Funktionen nicht nutzen. Es muss eine zugängliche Alternative bereitstehen, in der Zugang zu Informationen und Bedienung der Konfigurationsmöglichkeiten ohne Sprech- oder Hörvermögen möglich ist.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.4 Alternatives to voice-based services

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Videotelefonie zur Verfügung stellt.

Anforderung

Mobile Apps, die Videotelefonie zur Verfügung stellen, sollen mindestens die QVGA-Auflösung bei 320x240 Pixel, vorzugsweise die VGA-Auflösung bei 640x480 Pixel für die Videoübertragung unterstützen.

Testvorgehen

• Falls vorhanden, Dokumentation der Mobile App prüfen und die Auflösung der Videotelefonie ermitteln und anhand eines Testanrufs auf Plausibilität prüfen.

• Falls keine Dokumentation vorhanden ist, oder die Information zur Auflösung der Videotelefonie nicht enthalten ist, den Anbieter der Mobile App kontaktieren und die Auflösung in Erfahrung bringen.

• Falls keine Information zur Auflösung der Videotelefonie ermittelt werden kann, anhand eines Testanrufs die Auflösung subjektiv prüfen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Hochwertige Bildqualität bei Videotelefonie ermöglicht es manchen Beeinträchtigungsgruppen, Informationen wie Mimik oder Gestik wahrzunehmen, die bei reiner Sprach- oder Textkommunikation im Kontext fehlen. Zudem können Menschen mit Beeinträchtigung des Gehörs zusätzlich von den Lippen lesen.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.5.2 Resolution

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Videotelefonie zur Verfügung stellt.

Anforderung

Mobile Apps, die Videotelefonie zur Verfügung stellen, sollen eine Bildwiederholfrequenz (frame rate) von mindestens 20 Bildern pro Sekunde, vorzugsweise 30 Bildern pro Sekunde für die Videoübertragung unterstützen.

Testvorgehen

• Falls vorhanden, Dokumentation der Mobile App prüfen und die Bildwiederholfrequenz (frame rate) der Videotelefonie ermitteln und anhand eines Testanrufs auf Plausibilität prüfen.

• Falls keine Dokumentation vorhanden ist, oder die Information zur Bildwiederholfrequenz (frame rate) der Videotelefonie nicht enthalten ist, den Anbieter der Mobile App kontaktieren und die Bildwiederholfrequenz (frame rate) in Erfahrung bringen.

• Falls keine Information zur Bildwiederholfrequenz (frame rate) der Videotelefonie ermittelt werden kann, anhand eines Testanrufs die Bildwiederholfrequenz (frame rate) subjektiv prüfen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Hochwertige Bildqualität bei Videotelefonie ermöglicht es manchen Beeinträchtigungsgruppen, Informationen wie Mimik oder Gestik wahrzunehmen, die bei reiner Sprach- oder Textkommunikation im Kontext fehlen. Zudem können Menschen mit Beeinträchtigung des Gehörs zusätzlich von den Lippen lesen.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.5.3 Framerate

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Videotelefonie zur Verfügung stellt.

Anforderung

Mobile Apps, die Videotelefonie zur Verfügung stellen, sollen sicherstellen, dass die Latenz zwischen Audio- und Videowiedergabe nicht mehr als 100 Millisekunden beträgt und somit eine hochwertige Lippensynchronität besteht.

Testvorgehen

• Falls vorhanden, Dokumentation der Mobile App prüfen und die Informationen zur Latenz der Videotelefonie ermitteln und anhand eines Testanrufs mittels Fokus auf Lippensynchronität auf Plausibilität prüfen.

• Falls keine Dokumentation vorhanden ist, oder die Informationen zur Latenz der Videotelefonie nicht enthalten ist, den Anbieter der Mobile App kontaktieren und die Informationen zur Latenz in Erfahrung bringen.

• Falls keine Information zur Latenz der Videotelefonie ermittelt werden kann, anhand eines Testanrufs die Latenzen mittels Fokus auf Lippensynchronität subjektiv prüfen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Zur optimalen Verständlichkeit von Videotelefonie ist Lippensynchronität essenziell. Nur so können Informationen im Kontext wie Gestik und Mimik mit den gesprochenen Inhalten erfasst werden. Menschen mit kognitiven Beeinträchtigungen und Beeinträchtigungen des Hörvermögens sind auf Synchronität von Bewegung und Sprache angewiesen, und innerhalb einer Kommunikation alle Informationen verstehen zu können. Untersuchungen haben zudem gezeigt, dass Video nach Audio deutlich schwerer zu verstehen ist als umgekehrt.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.5.4 Synchronization between audio and video

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Zwei-Wege-Sprachkommunikation und Videotelefonie zur Verfügung stellt.

Anforderung

Bietet die Mobile App Zwei-Wege-Sprachkommunikation mittels Videotelefonie, so muss Audioaktivität von Teilnehmern in Echtzeit visualisiert werden. Der visuelle Indikator der Audio-Aktivität kann ein visueller Punkt, eine Rahmenmarkierung des Nutzenden oder eine andere Art von Ein- / Aus-Anzeige sein, die flackert.

Testvorgehen

• Videoanruf auf mindestens zwei oder mehr Endgeräten herstellen.

• Über eines der Endgeräte Audioaktivität übermitteln.

• Prüfen, ob die Audioaktivität des entsprechenden Teilnehmers auf den verbleibenden Endgeräten visuell identifizierbar ist.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Für Teilnehmer in einer Kommunikation ist die Identifikation von Audioaktivität in Verbindung mit dem entsprechenden Teilnehmer essenziell, um im Kontext die jeweilige Aktivität dem Teilnehmer zuordnen zu können.

Abgrenzung

• Die Identifizierung des aktiven Sprechers wird über den Prüfschritt 6.2.2.3 Sprecheridentifizierung geprüft.

• Die Identifizierung von Audioaktivität bei Sprachtelefonie wird über den Prüfschritt 6.2.2.4 Anzeige von Audioaktivität in Echtzeit geprüft.

• Der Kontrast des visuellen Indikators wird über den Prüfschritt 11.1.4.11 Nicht-Text-Kontrast geprüft.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.5.5 Visual indicator of audio with video

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Sprecheridentifizierung für Sprachnutzende zur Verfügung stellt.

Anforderung

Bietet die Mobile App Sprecheridentifizierung für sprechende Teilnehmende, sollen auch gebärdende Teilnehmende und Echtzeit-Gebärden gleichwertig identifiziert werden, sobald die Eingabe von Gebärden gestartet wurde. Das Sprecheridentifizierung für Gebärdensprache kann manuell aktiviert oder automatisch identifiziert werden:

Testvorgehen

• Videoanruf auf zwei oder mehr Endgeräten herstellen.

• Über eines der Endgeräte die Eingabe von Gebärden starten.

  • Prüfen, ob der Teilnehmer während der Eingabe von Gebärden automatisch als Sprecher identifiziert und markiert bzw. hervorgehoben wird.

  • Falls keine automatische Identifizierung erfolgt, prüfen, ob eine manuelle Funktion zur Aktivierung der Sprecheridentifizierung zur Verfügung steht.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Die Sprecheridentifizierung für gebärdende Teilnehmende ermöglicht Menschen mit Beeinträchtigung des Gehörs die Wahrnehmung des entsprechenden Teilnehmers.

Abgrenzung

• Die Sprecheridentifizierung von Sprachnutzenden wird über den Prüfschritt 6.2.2.3 Sprecheridentifizierung geprüft.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 6.5.6 Speaker identification with video (sign language) communication

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App aufgenommene Videoinhalte mit synchroner Bild- und Tonspur in Verbindung mit Untertiteln zur Verfügung stellt.

Anforderung

Bietet die Mobile App aufgenommene Videoinhalte mit synchroner Bild- und Tonspur in Verbindung mit Untertiteln an, benötigt der Videoplayer die Möglichkeit, die Untertitel über ein Bedienelement ein- und auszublenden (closed captions). Eine Funktion zur Ausgabe der Untertitel auf Braille-Zeilen ist notwendig.

Testvorgehen

• Prüfen, ob der Videoplayer eine Möglichkeit zum Ein- und Ausblenden der Untertitel über ein Bedienelement zur Verfügung gestellt.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen mit Hörbeeinträchtigung sind auf Untertitel angewiesen, um den Inhalt von Videos mit Tonspur zu verstehen. Gleichzeitig können Untertitel beispielsweise kognitiv beeinträchtigte Menschen beim Verstehen der Inhalte stören. Zuschaltbare Untertitel (closed captions) müssen somit durch den Videoplayer ein- und ausschaltbar sein, um den Bedürfnissen der Nutzenden gerecht zu werden.

Abgrenzung

• Der Prüfschritt bezieht sich ausschließlich auf die Verfügbarkeit eines Bedienelements zum Ein- und Ausblenden von Untertiteln, sofern das Video und der Videoplayer dies zur Verfügung stellen.

• Der Prüfschritt ist für Videos mit dauerhaft angezeigten Untertiteln (open captions) nicht anwendbar.

• Der Inhalt der Untertitel wird über den Prüfschritt 11.1.2.2 Untertitel für aufgezeichnete Videos geprüft.

• Weitere Anforderungen an die Bedienelemente des Videoplayers (beispielsweise Kontrast, zugänglicher Name, Tastaturbedienbarkeit) werden in den entsprechenden Prüfschritten geprüft.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 7.1.1 Captioning playback

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Nicht-Live-Videos mit synchroner Bild- und Tonspur in Verbindung mit Untertiteln zur Verfügung stellt.

Anforderung

Bietet die Mobile App Nicht-Live-Videos mit in Verbindung mit Untertiteln an, müssen Untertitel und Tonspur synchron wiedergegeben werden.

Die EN 301549 konkretisiert dabei die zwei folgenden Anforderungen:

• Die Anzeige des Untertitels weicht nicht mehr als 100ms vom Zeitstempel des Untertitels ab.

• Die Anforderung besteht gleichermaßen für Live-Untertitel. Es ist zu erwarten, dass bei Live-Untertiteln mit Verzögerungen durch die Konvertierung von gesprochener Sprache in Text zu rechnen ist.

Testvorgehen

• Das Video in der Mobile App abspielen und visuell prüfen, ob die Untertitel synchron zum Ton angezeigt werden. Eine genaue Messung einer möglichen Abweichung ist im Rahmen des Blackbox-Tests nicht möglich.

• Werden Untertitel nicht synchron angezeigt, kann bei Mobile Apps keine weitere, technische Überprüfung hinsichtlich des Videoplayers oder des Zeitstempels erfolgen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Untertitel sollen synchron zur Bewegung der Lippen eines Sprechers angezeigt werden, da hörbeeinträchtigte Menschen neben der Untertitelung auch auf Mundbewegungen achten. Es wichtig, dass die Untertitelung klar dem Gesprochenen zuzuordnen ist. Weiterhin fördert die Synchronität die Gesamtverständlichkeit eines Videos.

Abgrenzung

• Der Inhalt der Untertitel wird über den Prüfschritt 11.1.2.2 Untertitel für aufgezeichnete Videos geprüft.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 7.1.2 Captioning synchronization

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Videos mit Untertiteln der Mobile App auf das Endgerät gespeichert, konvertiert oder aufgenommen werden können.

Anforderung

Bietet die Mobile App die Möglichkeit, Videos mit Untertiteln zu übertragen, zu konvertieren oder aufzuzeichnen, müssen die Untertitel und die Synchronität zum Ton erhalten bleiben. Die Prüfschritte 7.1.1 Wiedergabe von Untertiteln und 7.1.2 Synchronisation der Untertitel benötigen den Status „Erfüllt“. Zusätzliche Darstellungsaspekte des Textes, wie beispielsweise die Position, die Textfarben, der Textstil und die Schriftarten, können je nach regionalen Konventionen eine Bedeutung vermitteln. Eine Änderung dieser Darstellungsaspekte könnte die Bedeutung verändern und sollte nach Möglichkeit vermieden werden.

Testvorgehen

• Video der Mobile App übertragen, konvertieren oder aufzeichnen.

• Das generierte Video öffnen und prüfen, ob die Untertitel aus der Quelldatei vorhanden, und ob die Darstellungsaspekte erhalten geblieben sind.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Barrierefreiheitsinformationen, die in Quelldateien bereits vorhanden sind, sollen auch in neu generierten Dateien vorhanden und korrekt übernommen werden. So wird sichergestellt, dass Menschen, die auf die jeweilige Unterstützung angewiesen sind, das Angebot entsprechend weiter nutzen können.

Abgrenzung

• Die Wiedergabe der Untertitel wird im Prüfschritt 7.1.1 Wiedergabe von Untertiteln geprüft.

• Die Synchronität von Untertitel und Tonspur wird im Prüfschritt 7.1.2 Synchronisation der Untertitel geprüft.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 7.1.3 Preservation of captioning

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Videos mit synchroner Bild- und Tonspur in Verbindung mit ein- und ausblendbaren Untertiteln (closed captions) zur Verfügung stellt.

Anforderung

Bietet die Mobile App Videos mit ein- und ausblendbaren Untertiteln (closed captions) an, muss die Darstellung der Untertitel individuell konfiguriert werden können. Die EN 301 549 definiert weder Art noch Umfang der Möglichkeiten, sondern benennt folgende Beispiele: Hintergrund- und Vordergrundfarbe, Schriftart, Kontur oder Ränder der Schriftarten und Deckkraft des Hintergrunds. Somit gilt der Prüfschritt als erfüllt, wenn wenigstens eine der Möglichkeiten konfigurierbar ist. Der Prüfschritt gilt auch dann als erfüllt, wenn die Untertitel systemseitige Benutzerpräferenzen wie Schriftgröße oder Farbe übernehmen. Bei dauerhaft angezeigten Untertiteln (open captions) ist der Prüfschritt nicht anwendbar.

Testvorgehen

• Das Video in der Mobile App abspielen und die Untertitel einblenden. Prüfen, ob Konfigurationsmöglichkeiten für die Untertitel zur Verfügung stehen.

• Falls keine Konfigurationsmöglichkeiten für die Untertitel zur Verfügung stehen, entsprechende Benutzerpräferenzen im Betriebssystem konfigurieren, die Mobile App beenden, neu aufrufen und prüfen, ob die Untertitel auf die geänderten Benutzerpräferenzen reagieren.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Die flexible Anpassung der Darstellung von Untertiteln, beziehungsweise das Übernehmen von entsprechenden Benutzerpräferenzen stellt eine wichtige Funktion für alle Nutzergruppen dar, da auf diese Weise die Darstellung vom Nutzenden selbst an die eigenen Bedürfnisse gezielt angepasst werden kann.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 7.1.4 Captions characteristics

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Videos mit synchroner Bild- und Tonspur in Verbindung mit ein- und ausblendbaren Untertiteln (closed captions) zur Verfügung stellt.

Anforderung

Bietet die Mobile App Videos mit ein- und ausblendbaren Untertiteln (closed captions) an, müssen diese Untertitel als Ton ausgegeben werden können. Die Originaltonspur soll ersetzt oder zumindest stark abgedimmt werden. Untertitel, die fester Bestandteil des Videos sind (open captions), sind von dieser Anforderung ausgenommen.

Testvorgehen

• Das Video in der Mobile App abspielen und die Untertitel einblenden.

• Prüfen, ob sich eine alternative Tonspur oder eine generierte Sprachausgabe der Untertitel aktivieren lässt.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen, die den Originalton eines Videos nicht verstehen, benötigen eine für ihre Bedürfnisse passende Untertitelung. Diese Untertitel sollen auch für sehbeeinträchtigte Menschen als akustische Ausgabe zugänglich sein.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 7.1.5 Spoken subtitles

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Videos mit synchroner Bild- und Tonspur in Verbindung mit einer Audiodeskription zur Verfügung stellt.

Anforderung

Bietet die Mobile App eine Audiodeskription für verfügbare Videos an, muss die Audiodeskription als eigene Tonspur auswählbar und aktivierbar sein.

Testvorgehen

• Das Video in der Mobile App abspielen.

• Prüfen, ob sich eine alternative Tonspur aktivieren lässt, die die Audiodeskription beinhaltet.

• Falls keine eigene Tonspur existiert, prüfen, ob der Videoplayer eine Funktionalität zum Aktivieren und Deaktivieren der Audiodeskription zur Verfügung stellt.

• Falls weder eine eigene Tonspur noch eine eigene Funktionalität existieren, prüfen, ob ein separates Video zur Verfügung steht, das als Tonspur die Audiodeskription enthält.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Werden Audiodeskriptionen für Videos zur Verfügung gestellt, müssen die Audiodeskriptionen entsprechend aktivierbar und deaktivierbar sein.

Abgrenzung

• Die Prüfung auf generelles Vorhandensein von Audiodeskriptionen erfolgt über den Prüfschritt 11.1.2.5 Audiodeskription für aufgezeichnete Videos.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 7.2.1 Audio description playback

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Videos mit synchroner Bild- und Tonspur in Verbindung mit einer Audiodeskription zur Verfügung stellt.

Anforderung

Bietet die Mobile App eine Audiodeskription für verfügbare Videos an, muss die Audiodeskription synchron zu Bild und Ton wiedergegeben werden.

Testvorgehen

• Das Video mit aktivierter Audiodeskription in der Mobile App abspielen.

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

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Unterstützende Bildbeschreibungen müssen synchron zur Handlung zur Verfügung gestellt werden. Dies erhöht die Verständlichkeit entsprechender Inhalte enorm.

Abgrenzung

• Die Prüfung auf generelles Vorhandensein von Audiodeskriptionen erfolgt über den Prüfschritt 11.1.2.5 Audiodeskription für aufgezeichnete Videos.

• Die Aktivierbarkeit von Audiodeskriptionen erfolgt über den Prüfschritt 7.2.1 Wiedergabe der Audiodeskription.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 7.2.2 Audio description synchronization

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Videos mit Audiodeskription der Mobile App übertragen, konvertiert oder aufgenommen werden können.

Anforderung

Bietet die Mobile App die Möglichkeit, Videos mit Audiodeskription zu übertragen, zu konvertieren oder aufzuzeichnen, müssen die Audiodeskription und die Synchronität zu Bild und Ton beim generierten Video erhalten bleiben.

Testvorgehen

• Video der Mobile App übertragen, konvertieren oder aufzeichnen.

• Das generierte Video öffnen und prüfen, ob die Audiodeskription aus der Quelldatei vorhanden, und ob die Synchronität von Bild und Ton erhalten geblieben sind.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Barrierefreiheitsinformationen, die in Quelldateien bereits vorhanden sind, sollen auch in neu generierten Dateien vorhanden und korrekt übernommen werden. So wird sichergestellt, dass Menschen, die auf die jeweilige Unterstützung angewiesen sind, das Angebot entsprechend weiter nutzen können.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 7.2.3 Preservation of audio description

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Videos mit synchroner Bild- und Tonspur und mit ein- und ausblendbaren Untertiteln und/oder Audiodeskriptionen zur Verfügung stellt.

Anforderung

Bietet die Mobile App Videos mit synchroner Bild- und Tonspur in Verbindung mit Untertiteln und/oder Audiodeskriptionen an, müssen die Bedienelemente zum Aktivieren und Deaktivieren von Untertitel und Audiodeskription auf derselben Interaktionsebene wie die Wiedergabesteuerung zur Verfügung gestellt werden.

Testvorgehen

• Das Video in der Mobile App abspielen.

• Prüfen, ob eigene Bedienelemente zum Aktivieren und Deaktivieren von Untertiteln und/oder Audiodeskriptionen auf der gleichen Interaktionsebene wie die Wiedergabesteuerung zur Verfügung stehen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Bedienelemente zum Steuern von Untertiteln und Audiodeskriptionen müssen für ihre jeweilige Zielgruppe so einfach wie möglich auffindbar und aktivierbar sein. Die wichtigste Ebene bei der Bedienung von Videos ist die Wiedergabesteuerung. Die Kombination beider Steuerungen erleichtert Menschen die Bedienung des Angebots.

Abgrenzung

• Bei erfolgreicher Bewertung dieses Kriteriums sind auch die Prüfschritte 7.1.1 Wiedergabe von Untertiteln und 7.2.1 Wiedergabe der Audiodeskription erfolgreich zu bewerten.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 7.3 User controls for captions and audio description

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App informative, nicht interaktive Grafiken oder Objekte enthält, die zudem keine Interaktion ermöglichen.

Anforderung

Alle informativen Grafiken und Objekte verfügen über eine Textalternative, die den Inhalt passend beschreibt. Die Mobile App bleibt vollständig durch Alternativtexte nutzbar, auch wenn Grafiken oder Objekte nicht geladen werden oder vom Nutzenden aus technischen Gründen deaktiviert sind.

Alternativtexte ersetzen das Objekt, wenn es beispielsweise nicht angezeigt werden kann oder mittels Screenreader fokussiert wird. Sie sind möglichst kurz. Hierbei ist darauf zu achten, dass der Alternativtext keine Bildbeschreibung darstellt, sondern ausschließlich die Kerninformation vermittelt. Der Text soll in seiner Struktur möglichst simpel und zusammengefasst formuliert sein. Ausführliche Beschreibungen, beziehungsweise weiterführende Informationen werden im Kontext der Abbildung erläutert.

Testvorgehen

• Screenreader aktivieren.

• Informative Grafiken und Objekte identifizieren und prüfen, ob diese über eine geeignete Textalternative verfügen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Medienalternativen helfen Menschen mit Sinnesbeeinträchtigungen, die visuelle oder auditive Inhalte nicht oder nur eingeschränkt wahrnehmen können. Text ist als Medienalternative vielfältig einsetzbar. So können beispielsweise Menschen, die taub-blind sind, den Text in Braille lesen. Darüber hinaus unterstützt Text die Möglichkeit, nach Medieninhalten zu suchen und Inhalte auf eine Vielzahl von Arten zu einem neuen Zweck zu verbinden.

Abgrenzung

• Die Prüfung von Alternativtexten für Bedienelemente mit eingebetteter Grafik erfolgt in Prüfschritt 11.5.2.5 Objektinformationen.

• Die Prüfung von leeren Alternativtexten für dekorative Grafiken erfolgt in Prüfschritt 11.1.1.1b Alternativtexte für dekorative Grafiken.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.1.1 Non-text content

• WCAG v2.1 Kapitel 1.1.1 Non-text content

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App dekorative, nicht informative Grafiken oder Objekte enthält, die zudem keine Interaktion ermöglichen.

Anforderung

Alle Grafiken und Objekte (Objekte ohne auslösbare Funktion, beispielsweise dekorative Bilder, Farbflächen, Abstandshalter oder Symbole mit sichtbarer Beschriftung ohne Funktion), die keinen informativen Mehrwert bieten, sind als dekorative Objekte gekennzeichnet. Die entsprechende Kennzeichnung als dekoratives Objekt wird an den Screenreader übermittelt. Der Screenreader ignoriert das Objekt und fokussiert es nicht.

Testvorgehen

• Screenreader aktivieren.

• Grafiken und Objekte ohne informativen Mehrwert identifizieren und prüfen, ob diese Objekte fokussiert werden können.

• Sicherstellen, dass die Objekte bei aktivem Screenreader sowohl bei freier Navigation als auch bei Wisch-Navigation nicht erreichbar sind.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Text ist als Medienalternative vielfältig einsetzbar. So können bspw. Menschen, die taub-blind sind, den Text in Braille lesen. Rein dekorative Grafiken und Bilder sind hierbei anders zu behandeln. Sofern sie einem rein dekorativen Zweck dienen, sollen diese Elemente so implementiert sein, dass sie von assistiven Technologien wie Screenreadern ignoriert werden.

Abgrenzung

• Die Prüfung von Alternativtexten für Bedienelemente mit eingebetteter Grafik erfolgt in Prüfschritt 11.5.2.5 Objektinformationen.

• Die Prüfung von Alternativtexten für informative Grafiken erfolgt in Prüfschritt 11.1.1.1a Alternativtexte für informative Grafiken.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.1.1 Non-text content

• WCAG v2.1 Kapitel 1.1.1 Non-text content

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App CAPTCHA-Funktionalität einsetzt.

Anforderung

Für bildbasierte oder Audio-CAPTCHAs sind Alternativtexte verfügbar, die den Zweck des Objekts beschreiben und über Alternativen zum jeweiligen CAPTCHA informieren. Es muss mindestens eine Alternative für grafische oder Audio-CAPTCHAs vorhanden sein. Das alternative CAPTCHA muss im unmittelbaren Kontext zur Verfügung stehen.

Testvorgehen

• Screenreader aktivieren.

• CAPTCHA identifizieren und prüfen, ob es über eine geeignete Textalternative inklusive Hinweis zu Alternativen verfügt.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Sehbeeinträchtigte bzw. blinde Nutzende können bildbasierte CAPTCHAS unter Umständen nicht bedienen. Audiobasierte CAPTCHAS sind hingegen für Nutzende mit eingeschränktem oder fehlendem Hörvermögen nicht bedienbar. Entsprechende Alternativtexte schaffen Orientierung, CAPTCHA-Alternativen sorgen für entsprechende Nutzungsmöglichkeiten des Angebots.

Abgrenzung

• Die Prüfung auf CAPTCHAs, die explizit im Rahmen des Anmeldeprozesses verwendet werden, erfolgt in Prüfschritt 11.3.3.8c Zugängliche CAPTCHAs in Anmeldeprozessen.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.1.1 Non-text content

• WCAG v2.1 Kapitel 1.1.1 Non-text content

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App aufgezeichnete „Nur“-Audio- oder „Nur“-Video-Inhalte zur Verfügung stellt.

Anforderung

Aufgezeichnete Audioinhalte und Videos ohne Ton, die Informationen übermitteln, beziehungsweise einen informativen Mehrwert bieten, benötigen äquivalente Medienalternativen im unmittelbaren Kontext, es sei denn, sie stellen bereits eine Medienalternative für Textinhalte dar. Die Medienalternative kann direkt in der Mobile App, oder in einer externen Quelle bereitgestellt werden.

Testvorgehen

• Audioinhalte oder Videos ohne Ton identifizieren und prüfen, ob sie über eine Medienalternative im unmittelbaren Kontext verfügen.

• Die Medienalterative prüfen, ob sie den Inhalt korrekt und vollständig vermittelt.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Videoinhalte sind für sehbeeinträchtigte Menschen nicht zugänglich und benötigen eine äquivalente Medienalternative, etwa als Text- oder Audioinhalt. Audioinhalte sind für hörbeeinträchtigte Menschen nicht zugänglich und benötigen eine äquivalente Transkription. Darüber hinaus können Textalternativen vielen Nutzenden helfen, die aufgezeichneten Inhalte zu verstehen.

Abgrenzung

• Die Prüfung von Alternativtexten für Grafiken und Objekte erfolgt in Prüfschritt 11.1.1.1b Alternativtexte für nicht interaktive Grafiken und Objekte.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.2.1 Audio-only and video-only (pre-recorded)

• WCAG v2.1 Kapitel 1.2.1 Audio-only and video-only (pre-recorded)

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App aufgezeichnete Videos mit synchronisierter, informativer Tonspur enthält.

Anforderung

Bietet die Mobile App aufgezeichnete Videos mit synchronisierter, informativer Tonspur, so müssen Untertitel als Medienalternative bereitgestellt werden, es sei denn, sie stellen bereits eine Medienalternative für andere Inhalt dar. Untertitel müssen sowohl für sprachliche als auch für nichtsprachliche Audioinhalte (Geräuscheffekte, Musik, Lachen, Identifizierung und Position des Sprechers etc.) bereitgestellt werden.

Testvorgehen

• Videos mit informativer Tonspur identifizieren und prüfen, ob Untertitel angezeigt werden oder aktiviert werden können.

• Die Untertitel anhand von Stichproben prüfen, ob sie den gesprochenen Inhalt, als auch akustische Ereignisse korrekt und vollständig vermitteln.

• Falls keine Untertitel vorhanden sind, auf Medienalternativen im unmittelbaren Kontext prüfen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen mit Hörbeeinträchtigung sind auf Untertitel angewiesen, um den Inhalt von Videos mit Tonspur zu verstehen. Darüber hinaus können Untertitel vielen Nutzenden helfen, die aufgezeichneten Inhalte zu verstehen.

Abgrenzung

• Die Prüfung von Alternativtexten für Grafiken und Objekte erfolgt in Prüfschritt 11.1.1.1b Alternativtexte für nicht interaktive Grafiken und Objekte.

• Die Prüfung von Untertiteln für Live-Übertragungen erfolgt in Prüfschritt 11.1.2.4 Untertitel für Live-Videos.

• Die Prüfung von weiterführenden Anforderungen zu Videofähigkeiten erfolgt in den Prüfschritten unter Kapitel 7 Videofähigkeiten.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.2.2 Captions (pre-recorded)

• WCAG v2.1 Kapitel 1.2.2 Captions (pre-recorded)

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App aufgezeichnete Videos mit synchronisierter, informativer Tonspur enthält.

Anforderung

Bietet die Mobile App aufgezeichnete Videos mit informativer Tonspur, deren visuelle Inhalte zusätzliche Informationen übermitteln (beispielsweise Informationen zu Aktionen, Charakteren, Szenenänderungen, Geräusche, Bildschirmtext), müssen diese Inhalte in einer Medienalternative als Audiodeskription (WCAG AA) wie in Prüfschritt 11.1.2.5 Audiodeskription für aufgezeichnete Videos beschrieben verfügbar sein. Wurde der Prüfschritt 11.1.2.5 Audiodeskription für aufgezeichnete Videos erfolgreich bewertet, ist keine weitere Prüfung von Medienalternativen notwendig, selbst wenn zusätzlich zur Audiodeskription weitere Alternativen angeboten werden.

Ist keine Audiodeskription verfügbar, muss mindestens eine Volltext-Alternative (WCAG A) bereitgestellt werden.

Bieten die visuellen Inhalte keinen weiteren Informationen, die zum Gesamtverständnis wichtig sind, oder stellt das Video bereits eine Medienalternative dar, oder ist das Video ein Gebärdensprachenvideo, ist keine der genannten Alternativen notwendig.

Testvorgehen

• Zuerst prüfen, ob der Prüfschritt 11.1.2.5 Audiodeskription für aufgezeichnete Videos anwendbar ist. Grundsätzlich ist für aufgezeichnete Videos mit informativer Tonspur immer eine Audiodeskription zur Verfügung zu stellen (WCAG 2.1 AA). Kann der Prüfschritt 11.1.2.5 Audiodeskription für aufgezeichnete Videos als erfüllt bewertet werden, ist dieser Prüfschritt automatisch erfüllt.

• Falls keine Audiodeskription wie in Prüfschritt 11.1.2.5 Audiodeskription für aufgezeichnete Videos gefordert verfügbar ist, über diesen Prüfschritt evaluieren, ob eine Volltext-Alternative im unmittelbaren Kontext beispielsweise als Link, als Klartext oder als Dokument zur Verfügung steht und Handlung, Dialoge, Geräusche und weitere informationstragende Bildinhalte korrekt beschreibt.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Durch entsprechende Medienalternativen wird sichergestellt, dass Nutzende mit Seh- oder Hörbeeinträchtigung Inhalte von Videos vollumfänglich nutzen können.

Abgrenzung

• Grundsätzlich ist für aufgezeichnete Videos mit informativer Tonspur immer eine Audiodeskription zur Verfügung zu stellen. Die Prüfung auf Verfügbarkeit einer Audiodeskription erfolgt in Prüfschritt 11.1.2.5 Audiodeskription für aufgezeichnete Videos.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.2.3 Audio description or media alternative (pre-recorded)

• EN 301549 v3.2.1 Kapitel 11.1.2.5 Audio description (pre-recorded)

• WCAG v2.1 Kapitel 1.2.3 Audio description or media alternative (pre-recorded)

• WCAG v2.1 Kapitel 1.2.5 Audio description (pre-recorded)

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App Live-Übertragungen mit synchronisierter, informativer Tonspur enthält.

Anforderung

Bietet die Mobile App Live-Videos mit synchronisierter, informativer Tonspur, so müssen Untertitel als Medienalternative bereitgestellt werden. Untertitel müssen sowohl für sprachliche als auch für nichtsprachliche Audioinhalte (Geräuscheffekte, Musik, Lachen, Identifizierung und Position des Sprechers, etc.) bereitgestellt werden.

Bei Liveübertragungen können die Untertitel aufgrund der technischen Machbarkeit mit leichter Latenz angezeigt werden. Die Bewertung liegt im Ermessensspielraum des Prüfers.

Testvorgehen

• Live-Videos mit informativer Tonspur identifizieren und prüfen, ob Untertitel angezeigt werden oder aktiviert werden können.

• Die Untertitel anhand von Stichproben prüfen, ob sie den gesprochenen Inhalt, als auch akustische Ereignisse korrekt und vollständig vermitteln.

• Falls keine Untertitel vorhanden sind, auf Medienalternativen im unmittelbaren Kontext prüfen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen mit Hörbeeinträchtigung sind auf Untertitel angewiesen, um den Inhalt von Live-Videos mit Tonspur zu verstehen. Darüber hinaus können Untertitel vielen Nutzenden helfen, die aufgezeichneten Inhalte zu verstehen.

Abgrenzung

• Die Prüfung von Alternativtexten für Grafiken und Objekte erfolgt in Prüfschritt 11.1.1.1b Alternativtexte für nicht interaktive Grafiken und Objekte.

• Die Prüfung von Untertiteln für aufgezeichnete Videos erfolgt in Prüfschritt 11.1.2.4 Untertitel für Live-Videos.

• Die Prüfung von weiterführenden Anforderungen zu Videofähigkeiten erfolgt in den Prüfschritten unter Kapitel 7 Videofähigkeiten.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.2.4 Captions (live)

• WCAG v2.1 Kapitel 1.2.4 Captions (live)

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App aufgezeichnete Videos mit synchronisierter, informativer Tonspur enthält.

Anforderung

Bietet die Mobile App aufgezeichnete Videos mit informativer Tonspur, deren visuelle Inhalte zusätzliche Informationen übermitteln (beispielsweise Informationen zu Aktionen, Charakteren, Szenenänderungen, Geräusche, Bildschirmtext), muss eine Audiodeskription als Medienalternative zur Verfügung stehen.

Bieten die visuellen Inhalte keinen weiteren Informationen, die zum Gesamtverständnis wichtig sind, oder stellt das Video bereits eine Medienalternative dar, oder ist das Video ein Gebärdensprachenvideo, ist keine der genannten Alternativen notwendig.

Die Audiodeskription kann auf verschiedenen Wegen angeboten werden:

• Die Audiodeskription ist in der Standard-Tonspur enthalten.

• Die Audiodeskription ist in einer separaten Tonspur aktivierbar.

• Die Audiodeskription ist als weitere Videoversion im unmittelbaren Kontext des Videos verfügbar.

Testvorgehen

• Video starten und prüfen, ob eine Audiodeskription verfügbar ist.

• Prüfen, ob die Audiodeskription die zusätzlichen Informationen des visuellen Inhalts zutreffend und vollumfänglich beschreibt.

• Wurde dieser Prüfschritt erfolgreich bewertet, so muss auch Prüfschritt 11.1.2.3 Audiodeskription oder Medienalternative für aufgezeichnete Videos erfolgreich bewertet werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Durch entsprechende Medienalternativen wird sichergestellt, dass Nutzende mit Sehbeeinträchtigung Inhalte von Videos vollumfänglich nutzen können. Darüber hinaus bieten Audiodeskriptionen auch Nutzenden mit kognitiven Beeinträchtigungen eine alternative Möglichkeit, auf diese Inhalte zuzugreifen.

Abgrenzung

• Steht keine Audiodeskription zur Verfügung, erfolgt die Prüfung auf Vorhandensein und Inhalt einer Volltext-Medienalternative über Prüfschritt 11.1.2.3 Audiodeskription oder Medienalternative für aufgezeichnete Videos.

• Wurde dieser Prüfschritt erfolgreich bewertet, so erhält Prüfschritt 11.1.2.3 Audiodeskription oder Medienalternative für aufgezeichnete Videos automatisch ohne weitere Prüfungen eventuell vorhandener Medienalternativen den Status „Erfüllt“.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.2.5 Audio description (pre-recorded)

• EN 301549 v3.2.1 Kapitel 11.1.2.3 Audio description or media alternative (pre-recorded)

• WCAG v2.1 Kapitel 1.2.5 Audio description (pre-recorded)

• WCAG v2.1 Kapitel 1.2.3 Audio description or media alternative (pre-recorded)

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Inhalte der Mobile App durch Überschriften strukturiert werden.

Anforderung

Überschriften und Hierarchieebenen werden über geeignete Objekte visualisiert. Die visuell erkennbaren Objekte sind programmatisch ermittelbar und bedienbar, wichtige Informationen sind im Kontext für alle Nutzenden wahrnehmbar.

Die Ausgabe von Überschriftsebenen ist unter Umständen abhängig vom verwendeten Framework technisch noch nicht vollumfänglich möglich, daher darf das Vorhandensein von Überschriftsebenen derzeit noch nicht gefordert werden. Falls Ebenen ausgegeben werden, müssen sie hierarchisch korrekt verschachtelt sein (beispielsweise H1 gefolgt von H2, gefolgt von H3, etc.). Das Auslassen von Überschriftsebenen wird nicht als Fehler gewertet, sofern die hierarchische Reihenfolge der Überschriften logisch ist.

Wortwahl oder Stil der Überschriften sind nicht Teil der Prüfung.

Testvorgehen

• Inhalte der Mobile APP visuell auf korrekte und vollständige Verwendung von Überschriften und Ebenen prüfen.

• Screenreader aktivieren.

• Überschriften einzeln fokussieren und prüfen, ob die Rolle Überschrift ausgegeben wird.

• Falls Überschriftsebenen ausgegeben werden, prüfen, ob die hierarchische Reihenfolge logisch ist.

• Bei iOS mittels VoiceOver-Rotor prüfen, ob von Überschrift zu Überschrift navigiert werden kann.

• Bei Android mittels Talkback-Menü prüfen, ob von Überschrift zu Überschrift navigiert werden kann.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Überschriften strukturieren Inhalte für sehende Nutzende und schaffen so schnelle Orientierung. Inhalte sind einfach erfassbar und gezielt abrufbar. Oberflächen-Elemente, die visuell bestimmte Charakteristiken aufweisen, müssen diese auch auf einer semantischen Ebene vermitteln. Hilfsmitteltechnologien können diese Informationen interpretieren und schaffen somit Orientierung und gezielte Navigationsmöglichkeiten für ihre jeweilige Nutzergruppe. So können beispielsweise auch Nutzende von Screenreadern den Aufbau der Inhalte wahrnehmen und schnell durchsuchen.

Abgrenzung

• Die Prüfung auf die Verwendung korrekter Strukturelemente für Listen, Auflistungen und Aufzählungen erfolgt in Prüfschritt 11.1.3.1b Strukturelemente für Listen, Auflistungen und Aufzählungen.

• Die Prüfung auf die Verwendung korrekter Strukturelemente für weitere Objekte erfolgt in Prüfschritt 11.1.3.1c Strukturelemente für weitere Objekte.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.3.1 Info and relationships

• WCAG v2.1 Kapitel 1.3.1 Info and relationships

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Inhalte der Mobile App listenartig strukturiert werden.

Anforderung

Listen, Auflistungen, Aufzählungen und andere listenartige Inhalte werden über geeignete Objekte visualisiert. Die visuell erkennbaren Objekte sind programmatisch ermittelbar und bedienbar, wichtige Informationen sind im Kontext für alle Nutzenden wahrnehmbar.

Listeneinträge sollen möglichst ein einzelnes, fokussierbares Objekt sein, um die Navigation zwischen Einträgen für Screenreadernutzende zu vereinfachen. Die im Eintrag gegebenenfalls vorhandenen Interaktionsmöglichkeiten sollen über die Steuerungsmöglichkeiten des Screenreaders (in der Regel mittels Wischnavigation nach oben und unten) erreichbar sein. Zusätzliche Informationen wie Anfang und Ende der Liste, Anzahl der Einträge und die Position eines einzelnen Eintrags innerhalb der Liste sollen ermittelbar sein.

Beispielhafte Umsetzung:

• Beim Fokussieren eines Listeneintrags gibt der Screenreader folgenden Inhalt aus: [Name des Listeneintrags]; Listeneintrag x von Y; zum Öffnen doppeltippen; zum Ändern der Aktion mit einem Finger nach oben oder unten streichen.

• Wischt der Nutzende nun beispielsweise nach oben, ändert sich die Interaktionsmöglichkeit und der Screenreader gibt folgenden Inhalt aus:
  [Name des Listeneintrags]; Listeneintrag x von Y; zum Auswählen doppeltippen; zum Ändern der Aktion mit einem Finger nach oben oder unten streichen.

Wortwahl oder Stil der Inhalte sind nicht Teil der Prüfung.

Testvorgehen

• Screenreader aktivieren, listenartige Elemente fokussieren und prüfen, ob sie programmatisch als Liste ermittelbar sind.

• Prüfen, ob zusätzliche Informationen wie Anzahl der Einträge, Listenanfang und Listenende, und innerhalb der Einträge die Position eines einzelnen Eintrags wiedergegeben werden.

• Falls mehrere Listen vorhanden sind, bei iOS mittels VoiceOver-Rotor prüfen, ob von Liste zu Liste navigiert werden kann.

• Falls mehrere Listen vorhanden sind, bei Android mittels Talkback-Menü prüfen, ob von Liste zu Liste navigiert werden kann.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Strukturelemente für Listen strukturieren Inhalte für sehende Nutzende und schaffen so Orientierung. Oberflächen-Elemente, die visuell bestimmte Charakteristiken aufweisen, müssen diese auch auf einer semantischen Ebene vermitteln. Hilfsmitteltechnologien können diese Informationen interpretieren und schaffen somit Orientierung und gezielte Navigationsmöglichkeiten für ihre jeweilige Nutzergruppe. So können beispielsweise auch Nutzende von Screenreadern den Aufbau der Inhalte wahrnehmen und schnell navigieren.

Abgrenzung

• Die Prüfung auf die Verwendung korrekter Strukturelemente für Listen, Auflistungen und Aufzählungen erfolgt in Prüfschritt 11.1.3.1a Strukturelemente für Überschriften.

• Die Prüfung auf die Verwendung korrekter Strukturelemente für weitere Objekte erfolgt in Prüfschritt 11.1.3.1c Strukturelemente für weitere Objekte.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.3.1 Info and relationships

• WCAG v2.1 Kapitel 1.3.1 Info and relationships

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn für Inhalte der Mobile App weitere Strukturelemente, die nicht explizit in den Prüfschritten 11.1.3.1a Strukturelemente für Überschriften und 11.1.3.1b Strukturelemente für Listen, Auflistungen und Aufzählungen genannt sind, vorhanden sind.

Anforderung

Die Gliederung und Strukturierung von Inhalten werden durch geeignete Objekte visualisiert. Die visuell erkennbaren Objekte sind programmatisch ermittelbar und bedienbar, wichtige Informationen sind im Kontext für alle Nutzenden wahrnehmbar. Die Betriebssysteme iOS und Android bieten innerhalb der Bedienungshilfen umfangreiche Möglichkeiten, um durch Strukturobjekte zu navigieren, ohne den gesamten Inhalt durchlaufen zu müssen. Dazu gehören beispielsweise Container, Links, Formularelemente, Tabellen, Artikel, Tasten, Text- und Suchfelder oder Bilder. Wortwahl oder Stil der Objekte sind nicht Teil der Prüfung.

Tabellen dürfen nicht für Layout- oder Designzwecke verwendet werden. Falls tabellarischer Aufbau rein zu Layoutzwecken verwendet wird, soll die Tabelle nicht als Strukturelement gekennzeichnet sein.

Die Beschriftung von Formularelementen soll beim Erreichen programmatisch ermittelbar sein. Der Screenreader gibt dabei den Namen des jeweiligen Elements aus. Gruppen von Formularelementen sollen eine Gruppenbeschriftung beinhalten, um den Kontext der einzelnen Elemente besser erfassen zu können.

Testvorgehen

• Strukturobjekte visuell identifizieren.

• Screenreader aktivieren, und bei iOS mittels VoiceOver-Rotor, bei Android mittels Talkback-Menü nach Auswahl des jeweiligen Strukturobjekts prüfen, ob die Objekte per Wisch nach oben beziehungsweise unten direkt annavigiert werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Strukturobjekte strukturieren Inhalte für sehende Nutzende und schaffen so Orientierung. Oberflächen-Elemente, die visuell bestimmte Charakteristiken aufweisen, müssen diese auch auf einer semantischen Ebene vermitteln. Hilfsmitteltechnologien können diese Informationen interpretieren und schaffen somit Orientierung und gezielte Navigationsmöglichkeiten für ihre jeweilige Nutzergruppe. So können beispielsweise auch Nutzende von Screenreadern den Aufbau der Inhalte wahrnehmen und schnell navigieren.

Abgrenzung

• Die Prüfung auf die Verwendung korrekter Strukturelemente für Listen, Auflistungen und Aufzählungen erfolgt in Prüfschritt 11.1.3.1a Strukturelemente für Überschriften.

• Die Prüfung auf die Verwendung korrekter Strukturelemente für Listen, Auflistungen und Aufzählungen erfolgt in Prüfschritt 11.1.3.1b Strukturelemente für Listen, Auflistungen und Aufzählungen.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.3.1 Info and relationships

• WCAG v2.1 Kapitel 1.3.1 Info and relationships

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Bei aktivem Screenreader erhalten die Inhalte sowohl bei der Wischnavigation als auch bei der Navigation mit externer Tastatur den Fokus in einer Reihenfolge, die der logischen beziehungsweise visuellen Struktur, oder einem für Screenreadernutzenden optimiertem Bedienablauf entspricht. Die Navigation erfolgt hierbei bei der Wischnavigation von Element zu Element, bei Bedienung mit externer Tastatur mit aktivem Screenreader von interaktivem Element zu interaktivem Element.

Ausgeblendete oder unsichtbare Inhalte, Layout-Objekte oder Inhalte, die im Hintergrund liegen, dürfen dabei nicht fokussiert werden.

Bei einem Seitenaufruf soll bei der Wischnavigation das erste Element im Fokus die Seitenüberschrift sein. Ist keine Seitenüberschrift vorhanden, soll die Zurück-Taste als erstes Element fokussiert werden. Bietet die Seite eine zentrale Funktion (beispielsweise das Suchfeld der Google Suche), so kann das Suchfeld direkt fokussiert werden.

Bei Bedienung mit externer Tastatur soll das erste Element im Fokus das erste interaktive Element sein. Kontextelemente sind mit den Pfeiltasten erreichbar.

Bei modalen Dialogen muss das erste Element innerhalb des Dialogs fokussiert werden. Eine Wischnavigation ist nur innerhalb des Dialogs möglich, bis er geschlossen wird. Nach Schließen des Dialogs muss sich der Fokus am zuvor auslösenden Element befinden. Sollte der Dialog beim Start der Mobile App oder beim Aufruf einer Seite automatisch geöffnet werden, muss sich der Fokus nach Schließen des Dialogs am ersten Element der Seite befinden.

Testvorgehen

• Screenreader aktivieren.

• Fokus per Tippen oder per App-Start auf das erste Element der Ansicht setzen.

• Prüfen, ob mittels der Wischnavigation nach links beziehungsweise rechts die Inhalte den Fokus in einer Reihenfolge, die der logischen beziehungsweise visuellen Struktur, oder einem für Screenreadernutzenden optimiertem Bedienablauf entspricht, erhalten. Die Navigation muss hierbei von Element zu Element erfolgen.

• Externe Tastatur verbinden.

• Mobile App öffnen. Hierbei darauf achten, dass das erste Bedienelement der Seite fokussiert wird.

• Prüfen, ob mittels Navigation mit der Tabulatortaste Inhalte den Fokus in einer Reihenfolge, die der logischen beziehungsweise visuellen Struktur, oder einem für Screenreadernutzenden optimiertem Bedienablauf entspricht, erhalten. Die Navigation muss hierbei von interaktivem Element zu interaktivem Element erfolgen. Kontextinhalte sind mit den Pfeiltasten erreichbar.

Tipps zur Bedienung von iOS:

• Mit vier Fingern einmal in die obere Hälfte des Displays tippen, um den Fokus auf das erste Element der Seite zu setzen.

• Mit zwei Fingern von oben nach unten wischen, um das automatische Vorlesen ab dem aktuell gewählten Element zu starten.

• Mit zwei Fingern von unten nach oben wischen, um das automatische Vorlesen ab dem ersten Element der Seite zu starten.

Tipps zur Bedienung von Android:

• Einmal nach oben wischen, kurz absetzen, dann nach unten wischen, um den Fokus auf das erste Element der Seite zu setzen.

• Auf Geräten mit Mehrfinger-Touch-Gesten mit drei Fingern tippen, um das lokale Kontextmenü zu öffnen. Alternativ in einer Bewegung nach unten und dann nach rechts wischen. Eintrag „Ab dem nächsten Element lesen“ auswählen, um das automatische Vorlesen ab dem aktuell gewählten Element zu starten.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

Warum wird das geprüft

Screenreadernutzende erhalten die Information der Reihenfolge dargestellter Informationen in gesprochener Form und können somit den Kontext von Inhalten besser verstehen. Durch eine nicht nachvollziehbare Reihenfolge der fokussierten Elemente wird die Bedienbarkeit für diese Nutzenden erheblich beeinträchtigt. Sehbeeinträchtigte oder blinde Nutzende werden darüber hinaus in ihrer Fähigkeit, sich ein mentales Modell vom Aufbau der der Inhalte zu machen, eingeschränkt.

Abgrenzung

• Die Prüfung auf Sichtbarkeit und Tracking des Fokus erfolgt in Prüfschritt 11.2.4.7 Fokus sichtbar.

• Die Prüfung auf Tastaturbedienbarkeit ohne aktiven Screenreader erfolgt in den Prüfschritten 11.2.1.1 Mit externer Tastatur bedienbar und 11.2.4.3 Sinnvolle Reihenfolge bei Bedienung mit externer Tastatur.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.3.2 Meaningful sequence

• WCAG v2.1 Kapitel 1.3.2 Meaningful sequence

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Die Inhalte der Mobile App werden auf inhaltliche Verweise mittels sensorischer Merkmale wie Form, Größe, Position, Ausrichtung, Orientierung oder Ton geprüft. Solche Verweise dürfen nicht ausschließlich mittels der jeweiligen Sinneswahrnehmung verständlich sein.

Testvorgehen

• Inhaltliche Verweise mittels sensorischer Merkmale wie Form, Größe, Position, Ausrichtung, Orientierung oder Ton identifizieren.

• Prüfen, ob die Verweise auch ohne die jeweilige Sinneswahrnehmung verständlich sind.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

Warum wird das geprüft

Anweisungen für die Bedienung oder Verwendung der Inhalte dürfen nicht ausschließlich sensorische Merkmale (Farbe, Form, Größe, Position oder Töne) enthalten. Durch zusätzliche Informationen kann sichergestellt werden, dass auch blinde und sehbeeinträchtigte, sowie hörbeeinträchtigte Nutzende die entsprechenden Inhalte verstehen. Alle Nutzenden müssen auf alle Inhalte zugreifen können. Dies gilt auch dann, wenn sie beispielsweise Form, Größe oder Ton nicht wahrnehmen oder Informationen über die räumliche Position bzw. Ausrichtung nicht verwenden können. Manche Nutzende mit Beeinträchtigungen können Form oder Position aufgrund der Art der von ihnen verwendeten Hilfstechnologien nicht wahrnehmen. Es müssen spezifischere oder erweiterte Informationen zur Verfügung gestellt werden.

Abgrenzung

• Die Prüfung auf Informationsvermittlung ausschließlich über Farbe erfolgt in Prüfschritt 11.1.4.1 Verwendung von Farbe.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.3.3 Sensory characteristics

• WCAG v2.1 Kapitel 1.3.3 Sensory characteristics

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Inhalte der Mobile App sind hinsichtlich Ansicht und Bedienung nicht auf eine einzelne Anzeigeausrichtung im Hoch- oder Querformat beschränkt. Inhalte und Funktionen müssen bei der Neuausrichtung nicht zwingenderweise in derselben Form angeboten werden. Situationsbedingt dürfen spezifische Seiten ausschließlich eine Ausrichtung unterstützen, sofern die Ausrichtung zur korrekten Darstellung, zum Verständnis oder zur Bedienung essenziell ist, beispielsweise bei einem Bankscheck, einer Klaviatur einer Klavieranwendung oder bei Inhalten der virtuellen Realität.

Testvorgehen

• Sicherstellen, dass die automatische Ausrichtung aktiviert ist.

• Inhalte der Mobile App auf korrekte Darstellung und Bedienung im Hochformat und im Querformat prüfen. Dazu das Endgerät jeweils um 90 Grad drehen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

Warum wird das geprüft

Nutzende richten Endgeräte in Bezug zu ihren Anforderungen entsprechend aus. Inhalte sollen die jeweilige Ausrichtung des Endgeräts unterstützen, um Zugänglichkeit für die Nutzenden sicherzustellen. Menschen mit Sehbeeinträchtigung oder kognitiv beeinträchtige Menschen profitieren von einem besseren Lesefluss, auch bei gegebenenfalls stark erhöhter Textgröße. Motorisch eingeschränkte Nutzende haben zudem das Endgerät oftmals in einer festen Ausrichtung am Rollstuhl montiert und sind auf eine flexible Ausrichtung von Inhalten angewiesen.

Abgrenzung

• Die Prüfung von Textgrößenanpassungen erfolgt in Prüfschritt 11.1.4.4 Textgröße ändern.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.3.4 Orientation

• WCAG v2.1 Kapitel 1.3.4 Orientation

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Eingabefelder für Nutzerdaten, oder Eingabefelder, die ein spezielles Format erwarten, vorhanden sind.

Anforderung

Eingabefelder, die sich eindeutig auf Nutzerdaten beziehen und Informationen wie beispielsweise Name, E-Mailadresse, postalische Adresse, Rufnummer oder Kreditkartendaten anfordern, müssen programmatisch ermittelbar sein, damit unterstützende Technologien Nutzenden den Zweck der Eingabe erläutern können.

Eingabefelder, die eine Eingabe in einem speziellen Format erwarten wie beispielsweise Postleitzahlen, Rufnummern oder E-Mailadressen, sollen das für die jeweilige Eingabe optimierte Tastaturlayout ansteuern.

Anmeldedaten, die zur Authentifizierung in der Mobile App notwendig sind, werden beim Login durch den Passwortmanager abrufbar, sofern sie vorab gespeichert werden konnten.

Testvorgehen

• Sicherstellen, dass auf dem Endgerät entsprechende personenbezogene Daten hinterlegt sind.

• Falls vorhanden, Eingabefelder für Nutzerdaten fokussieren und prüfen, ob die hinterlegten Daten zum automatischen Ausfüllen korrekt vorgeschlagen werden.

• Prüfen, ob die vorgeschlagenen Werte dem jeweiligen Eingabefeld entsprechen.

• Falls vorhanden, Eingabefelder, die ein spezielles Format anfordern, annavigieren und prüfen, ob das für die jeweilige Eingabe optimierte Tastaturlayout angesteuert wird.

Tipps zur Konfiguration der personenbezogenen Daten für Autofill in iOS:

• Konfigurieren von „Meine Karte“ unter „Kontakte“ und Erfassen der entsprechenden Daten.

Tipps zur Konfiguration der personenbezogenen Daten für Autofill in Android:

• Konfigurieren des Google-Kontos unter „Einstellungen/Google/Google-Konto verwalten“ und Erfassen der entsprechenden Daten.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Korrekte Autocomplete- oder Autofill-Vorschläge sorgen dafür, dass Nutzende die Informationen nicht mehr, beziehungsweise nicht mehr vollumfänglich selbst eingeben müssen und stattdessen den Wert des Feldes bestätigen oder bei Bedarf ändern können. Dies ist ein erheblicher Vorteil für Nutzende mit kognitiven und motorischen Beeinträchtigungen.

Da die Daten für die automatische Vervollständigung sprachunabhängig sind, können Nutzende aufgrund der festgelegten Taxonomie der Begriffe den Zweck der Eingabefelder erkennen, auch wenn sie mit der Sprache nicht vertraut sind.

Zusätzlich zur Nutzung dieser Taxonomien können Technologien bei Verwendung der Attributtechnik den korrekten Inhalt vorschlagen und automatisch ausfüllen, indem sie diese Felder basierend auf früheren Eingaben, die im Betriebssystem gespeichert sind, automatisch vervollständigen.

Optimiertes Tastaturlayout sorgt dafür, dass Nutzende direkt mit der Eingabe der entsprechenden Daten beginnen können, ohne manuell auf das Ziellayout innerhalb der Tastatur umschalten zu müssen.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.3.5 Identify input purpose

• WCAG v2.1 Kapitel 1.3.5 Identify input purpose

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Farbe wird nicht als einzige visuelle Möglichkeit zur Übermittlung von Informationen, zur Anzeige einer Aktion, zum Anfordern einer Reaktion oder zur Unterscheidung eines visuellen Elements verwendet.

Testvorgehen

• Prüfen, ob Informationen über Farbe vermittelt werden.

• Falls ja, prüfen, ob diese Informationen zusätzlich durch Text, Textformatierung oder durch andere visuelle Mittel wie Symbole, Positionierungen oder Muster vermittelt werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

Warum wird das geprüft

Farbe ist ein wichtiges Gestaltungselement, das die ästhetische Anziehungskraft, das Nutzungserlebnis und die Barrierefreiheit verbessert. Einige Nutzende haben jedoch Schwierigkeiten, Farben wahrzunehmen. Menschen mit Sehbeeinträchtigungen haben oftmals eine eingeschränkte Farbwahrnehmung. Ältere Menschen sehen Farben möglicherweise nicht gut. Manche Menschen sehen Farben gar nicht. Darüber hinaus können Nutzende, die Bildschirme mit begrenzten Farben oder monochromen Displays und Browser verwenden, möglicherweise nicht auf Informationen zugreifen, die nur in Farbe präsentiert werden. Die Bereitstellung der durch Farbe vermittelten Information über ein weiteres visuelles Mittel gewährleistet, dass Nutzende, die Farbe nicht sehen, die Information dennoch wahrnehmen können.

Abgrenzung

• Die Prüfung auf Informationsvermittlung durch weitere sensorische Merkmale außer Farbe erfolgt in Prüfschritt 11.1.3.3 Sensorische Eigenschaften.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.4.1 Use of colour

• WCAG v2.1 Kapitel 1.4.1 Use of colour

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn in der Mobile App automatisch Audio abgespielt wird.

Anforderung

Für Audio-Inhalte, die in der Mobile App automatisch und länger als 3 Sekunden abgespielt werden, muss ein Steuerelement zum Pausieren, Stoppen des Audios, oder eine Lautstärkeregelung zum Steuern der Audiolautstärke unabhängig von der Lautstärke des Gesamtsystems zur Verfügung stehen. Entsprechende Steuerelemente müssen am Seitenbeginn, beziehungsweise im unmittelbaren Kontext des Elements auffindbar sein.

Testvorgehen

• Prüfen, ob das automatisch abgespielte Audio bereits bei Aufruf der Seite, oder erst bei Sicht des Nutzenden startet.

• Prüfen, ob das automatisch abgespielte Audio länger als drei Sekunden andauert.

• Falls ja, prüfen, ob ein oder mehrere Steuerelemente zur Verfügung stehen, um das Audio zu stoppen oder die Lautstärke zu regeln. Steuerelemente betätigen und Audio abschalten. Für Audio, das direkt beim Aufruf der Seite startet, muss ein Steuerelement am Anfang der Seite und im unmittelbaren Kontext des Audio zur Verfügung stehen. Für Audio, das erst bei Sicht des Nutzenden startet, ist ein Steuerelement im unmittelbaren Kontext ausreichend.

• Falls sich nur die Lautstärke regeln lässt, Audio stumm schalten. Anschließend sicherstellen, dass die Systemlautstärke dadurch nicht verändert wurde.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Nutzende von Screenreadern werden durch automatisch abgespielte Audioinhalte gestört. Daher müssen derartige Inhalte kurz sein oder abgeschaltet beziehungsweise heruntergeregelt werden können. Die Lautstärke muss unabhängig von der Systemlautstärke geregelt werden können, damit die verschiedenen Audioquellen ausreichend kontrastieren. Von diesem Kriterium profitieren auch Nutzende mit Aufmerksamkeitsstörungen, die bei laufendem Ton Schwierigkeiten haben, sich auf die Bedienung oder die Inhalte der Mobile App zu konzentrieren.

Abgrenzung

• Die Prüfung auf korrekte Darstellung der Steuerelemente erfolgt in Prüfschritt 11.1.4.11 Nicht-Text-Kontrast.

• Die Prüfung auf programmatische Bedienbarkeit der Steuerelemente erfolgt in Prüfschritt 11.5.2.5 Objektinformationen.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.4.2 Audio control

• WCAG v2.1 Kapitel 1.4.2 Audio control

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Die Kontraste von Text sind in allen Zuständen des Texts ausreichend. Hierbei wird bei Mobile Apps grundsätzlich ein Kontrastverhältnis von 4,5:1 zugrunde gelegt, da eine pixelgenaue Betrachtung von Schriftgrößen auf mobilen Endgeräten nicht möglich ist. Zudem ist der Bildschirm eines mobilen Endgeräts kleiner als der Monitor eines Desktop-Systems, was zu Forderung der genannten Kontrastwerte führt.

Die Anforderung gilt nicht für Textinhalte, die Teil einer inaktiven Benutzeroberflächenkomponente, rein dekorativ, für niemanden sichtbar oder Teil eines Bildes sind, das bedeutende andere visuelle Inhalte enthält. Weiterhin sind Texte eines Logos oder Markennamen ausgenommen.

Die Prüfung erfolgt in der Standarddarstellung der App. Eventuell vorhandene, alternative Darstellungen oder Mechanismen zum Verändern des Designs sind nicht Teil der Prüfung und werden nicht berücksichtigt.

Trotz ausreichender Kontrastwerte ist die Kombination von gesättigtem Rot mit Schwarz als Vorder- und Hintergrundfarbe für Texte nicht empfehlenswert (vgl. ISO 9241-125). Es existieren keine klaren Vorgaben für Farbwerte von gesättigtem Rot, daher kann der Prüfende nur aufgrund seiner subjektiven Wahrnehmung urteilen. Ein entsprechender Befund sollte nur als Empfehlung mitgeteilt werden.

Bei Texten, die auf einem Bild oder einem Farbverlauf liegen, ist der vermeintlich schwächste Kontrastzustand zu messen.

Testvorgehen

• Sicherstellen, dass keine benutzerdefinierten Einstellungen zu Anzeige und Darstellung aktiviert sind.

• Die Mobile App in der Standarddarstellung starten.

• Screenshots der zu messenden Seiten erstellen und an ein Desktop-System übermitteln. Bei der Übermittlung darauf achten, dass der Screenshot in Originalgröße und -format übermittelt wird.

• Screenshots mit Hilfe eines Kontrastanalyse-Tools untersuchen.

• Bei Android können Kontraste alternativ mit Hilfe von teilautomatisierten Analyse-Tools (beispielsweise Accessibility Scanner, axe for Android) untersucht werden. Identifizierte Kontrastfehler müssen unbedingt verifiziert werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

Warum wird das geprüft

Gute Kontrastverhältnisse zwischen Text- und Hintergrundfarbe sorgen dafür, dass Nutzende die Inhalte besser erkennen und lesen können. Menschen mit Sehbeeinträchtigung und Farbfehlsichtigkeit profitieren von guten Kontrastverhältnissen genauso wie ältere Menschen, die unter verminderter Kontrastempfindlichkeit leiden. Letztendlich kommen gute Kontraste allen Menschen zugute, beispielsweise beim Verwenden des mobilen Endgeräts bei starker Sonneneinstrahlung.

Abgrenzung

• Die Prüfung des Kontrasts von Grafiken und grafischen Bedienelementen erfolgt in Prüfschritt 11.1.4.11 Nicht-Text-Kontrast.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.4.3 Contrast (minimum)

• WCAG v2.1 Kapitel 1.4.3 Contrast (minimum)

• ISO 9241-171 Kapitel 10.4.5 Für Kontrast zwischen Vordergrund und Hintergrund sorgen

• ISO 9241-303 Anforderungen an elektronische optische Anzeigen

• ISO 9241-125 Anleitung zur visuellen Informationsdarstellung

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Textgröße kann auf mindestens 200% skaliert werden, ohne dass Inhalt oder Funktionalität dabei verloren gehen. Die Vergrößerung kann über die Einstellungen der Textgröße im Betriebssystem, oder über eine App-eigene Funktionalität zur Verfügung gestellt werden. Beim Bereitstellen einer eigenen Funktionalität müssen die zugehörigen Steuerelemente am Seitenbeginn auffindbar sein. Eine Skalierung auf genau 200% ist in Android das mögliche Maximum, bei iOS können genau 200% nicht erreicht werden. Hier liegt der zu testende Wert zwischen 190% und 235%.

Testvorgehen

• Textgröße erhöhen.

• Prüfen, ob die Vergrößerung der Textgröße in allen Inhalten übernommen wird (beispielsweise Menüs, Beschriftungen, Texte, Daten).

• Prüfen, ob es zu Überlappungen oder Verdrängungen aufgrund der Erhöhung kommt.

• Falls eine eigene Funktionalität zur Vergrößerung der Textgröße zur Verfügung steht, prüfen, ob die zugehörigen Steuerelemente am Anfang der Seite zu finden sind.

Tipps zur Bedienung von iOS:

• Der Standardwert zur Vergrößerung von Text unter „Textgröße“ beträgt 135%. Unter „Bedienungshilfen > Anzeige & Textgröße > Größerer Text > Größerer dynamischer Text“ kann dieser Wert auf 310% erhöht werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

Warum wird das geprüft

Für Nutzende mit Sehbeeinträchtigung ist das Anpassen der Textgröße nach ihren Bedürfnissen ein essenzieller Bestandteil, um die Lesbarkeit von Inhalten zu verbessern. Nutzende mit Legasthenie profitieren zudem von einer erhöhten Lesegeschwindigkeit. Sämtlicher Text muss ohne Verlust von Inhalten mit der individuellen Textgröße des Systems skalieren.

Abgrenzung

• Die Prüfung der Anpassung weiterer Abstände wie Zeilenhöhe und Abstand von Zeichen oder Worten erfolgt in Prüfschritt 11.1.4.12 Textabstand.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.4.4 Resize text

• EN 301549 v3.2.1 Kapitel 5.1.4 Functionality closed to text enlargement

• WCAG v2.1 Kapitel 1.4.4 Resize text

• ISO 9241-171 Kapitel 10.3.2 Benutzern die Einstellung einer Mindestschriftgröße ermöglichen

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Bilder oder Grafiken werden nicht zur Darstellung von Schrift verwendet. Logos, beziehungsweise Text, der Teil eines Logos oder Markennamens ist, ist hiervon ausgenommen. Eine Schriftgrafik ist eine visuelle Gestaltung und Anordnung von Buchstaben, Zeichen und Textelementen innerhalb eines grafischen Elements. Wird der Informationsinhalt der Schriftgrafik auch im Kontext als Text wiedergeben, gilt dies als Medienalternative.

Testvorgehen

• Schriftgrafiken visuell identifizieren und prüfen, ob der Informationsinhalt im Kontext über eine Medienalternative, beispielsweise als Text, verfügbar ist.

• Bei Unsicherheit Screenreader aktivieren.

• Vermeintliche Schriftgrafik fokussieren.

• Prüfen, welche Information vom Screenreader ausgegeben wird. Falls es sich um ein grafisches Element handelt, wird es als „Bild“ oder „Grafik“ identifiziert.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

Warum wird das geprüft

Die Darstellung von textuellen Inhalten soll nicht in Form von grafischen Elementen erfolgen, sondern immer als Klartext. So kann sichergestellt werden, dass die Darstellung an individuelle Bedürfnisse angepasst werden kann, und assistive Technologien uneingeschränkt darauf zugreifen können.

Nutzende mit einer Sehbeeinträchtigung oder mit kognitiver Beeinträchtigung erleben aufgrund der Schriftfamilie, Schriftgröße oder -Farbe eventuell Einschränkungen hinsichtlich der Lesbarkeit und haben somit keinen vollumfänglichen Zugang zu den Informationen.

Abgrenzung

• Die Prüfung von Alternativtexten für interaktive grafische Elemente erfolgt in Prüfschritt 11.1.1.1a Alternativtexte für interaktive Grafiken und Objekte.

• Die Prüfung von Alternativtexten für nicht interaktive grafische Elemente erfolgt in Prüfschritt 11.1.1.1b Alternativtexte für nicht interaktive Grafien und Objekte.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.4.5 Images of text

• EN 301549 v3.2.1 Kapitel 5.1.3.6 Speech output for non-text content

• WCAG v2.1 Kapitel 1.4.5 Images of text

Anwendbarkeit

Der Prüfschritt ist zum aktuellen Stand der Technik bei Mobile Apps nicht prüfbar (Stand Januar 2024).

Bewertungsalternativen

• Nicht anwendbar

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.4.10 Reflow

• WCAG v2.1 Kapitel 1.4.10 Reflow

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn grafische Bedienelemente oder informationstragende Grafiken vorhanden sind.

Anforderung

Die Kontraste von grafischen Bedienelementen und informationstragenden Grafiken sind mit einem Kontrastverhältnis von mindestens 3:1 ausreichend. Bei der Kontrastmessung steht der informationstragende Bereich oder die Hervorhebung des Zustands eines Elements im Fokus.

Die Anforderung gilt nicht für inaktive Benutzeroberflächenkomponenten, inaktive Zustände von Bedienelementen, Logos beziehungsweise Markennamen, und grafische Inhalte, deren Inhalt nicht verändert werden darf, beispielsweise Flaggen, Screenshots oder Heatmaps.

Die Anforderung gilt weiterhin nicht für native grafische Bedienelemente, die in ihrem Erscheinungsbild nicht beeinflusst werden können, beispielsweise native Switches in ihren jeweiligen Zuständen, Checkboxen oder Radio-Buttons.

Die Prüfung erfolgt in der Standarddarstellung der App. Eventuell vorhandene, alternative Darstellungen oder Mechanismen zum Verändern des Designs sind nicht Teil der Prüfung und werden nicht berücksichtigt.

Testvorgehen

• Sicherstellen, dass keine benutzerdefinierten Einstellungen zu Anzeige und Darstellung aktiviert sind.

• Die Mobile App in der Standarddarstellung starten.

• Screenshots der zu messenden Seiten erstellen und an ein Desktop-System übermitteln. Bei der Übermittlung darauf achten, dass der Screenshot in Originalgröße und -format übermittelt wird.

• Screenshots mit Hilfe eines Kontrastanalyse-Tools untersuchen. Hierbei alle Kontraste der Ebenen von oberster zu unterster Ebene berücksichtigen.

• Bei Android können Kontraste alternativ mit Hilfe von teilautomatisierten Analyse-Tools (beispielsweise Accessibility Scanner, axe for Android) untersucht werden. Identifizierte Kontrastfehler müssen unbedingt verifiziert werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

Warum wird das geprüft

Gute Kontrastverhältnisse sorgen dafür, dass Nutzende die Inhalte besser erkennen, lesen und bedienen können. Menschen mit Sehbeeinträchtigung und Farbfehlsichtigkeit profitieren von guten Kontrastverhältnissen genauso wie ältere Menschen, die unter verminderter Kontrastempfindlichkeit leiden. Letztendlich kommen gute Kontraste allen Menschen zugute, beispielsweise beim Verwenden des mobilen Endgeräts bei starker Sonneneinstrahlung.

Abgrenzung

• Die Prüfung des Kontrasts von Text erfolgt in Prüfschritt 11.1.4.3 Kontrast von Texten.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.4.11 Non-text contrast

• WCAG v2.1 Kapitel 1.4.11 Non-text contrast

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die Mobile App eine App-eigene Funktion zum Verändern von Textabständen zur Verfügung stellt. Die Betriebssysteme iOS und Android bieten zum aktuellen Stand der Technik keine eigenen Möglichkeiten zum Anpassen von Textabständen (Stand Januar 2024).

Anforderung

Das Anpassen der Zeilenhöhe auf mindestens das 1,5-fache der Textgröße, des Abstands nach Absätzen auf mindestens das 2-fache der Textgröße, des Zeichenabstands auf mindestens das 0,12-fache der Textgröße und des Wortabstands auf mindestens das 0,16-fache der Textgröße führt nicht zu Verlust von Inhalt oder Funktionalität. Beim Bereitstellen der Funktion müssen die zugehörigen Steuerelemente am Seitenbeginn auffindbar sein.

Testvorgehen

• Prüfen, ob die zugehörigen Steuerelemente am Anfang der Seite zu finden sind.

• Entsprechende Anpassung vornehmen.

• Prüfen, ob die Anpassung in allen Inhalten übernommen wird (beispielsweise Menüs, Beschriftungen, Texte, Daten).

• Prüfen, ob es zu Überlappungen oder Verdrängungen aufgrund der Anpassung kommt.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Für Nutzende mit Sehbeeinträchtigung ist das Anpassen von Abständen nach ihren Bedürfnissen ein essenzieller Bestandteil, um die Lesbarkeit von Inhalten zu verbessern. Nutzende mit Legasthenie profitieren zudem von einer erhöhten Lesegeschwindigkeit.

Abgrenzung

• Die Prüfung der Anpassung der Textgröße erfolgt in Prüfschritt 11.1.4.4 Textgröße ändern.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.4.12 Text spacing

• WCAG v2.1 Kapitel 1.4.12 Text spacing

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn zusätzliche Inhalte beim Erhalt des Fokus, oder bei weiterführender Interaktion eingeblendet werden, beispielsweise Tooltips, Ausklapp-Menüs oder kontextbezogene Menüs.

Anforderung

Inhalte, die durch Touch-Interaktion, Tastatur-Fokus oder Mauszeiger-Hover aktiviert oder eingeblendet werden, sind für den Nutzenden navigierbar. Sie werden nicht unerwartet oder automatisch geschlossen, sind jedoch jederzeit durch den Nutzenden schließbar. Das Schließen eines eingeblendeten Inhalts versetzt nicht den ursprünglichen Fokus.

Testvorgehen

• Elemente mit einblendbarem Inhalt antippen. Gegebenenfalls zusätzlich eine lange Touch-Interaktion (langes Drücken) ausführen.

• Prüfen, ob der eingeblendete Inhalt nicht unerwartet oder automatisch geschlossen wird.

• Prüfen, ob der eingeblendete Inhalt mittels Tippens außerhalb des eingeblendeten Inhalts, oder über eine dafür vorgesehene Schließen-Funktion wieder geschlossen werden kann.

• Screenreader aktivieren.

• Elemente mit einblendbarem Inhalt über die Wischnavigation fokussieren.

• Prüfen, ob der einblendbare Inhalt programmatisch ermittelbar ist.

• Falls der einblendbare Inhalt bei aktivem Screenreader eingeblendet wird, prüfen, ob der eingeblendete Inhalt wieder geschlossen werden kann.

• Screenreader ausschalten.

• Externe Tastatur verbinden.

• Elemente mit einblendbarem Inhalt über Tastatursteuerung fokussieren.

• Prüfen, ob der eingeblendete Inhalt mittels Escape-Taste auf der externen Tastatur wieder geschlossen werden kann.

Tipps zur Bedienung von iOS:

• Eingeblendete Inhalte enthalten oftmals keine explizite „Schließen-Funktion“. Im Standardmodus können diese Inhalte mittels Tippens außerhalb des eingeblendeten Inhalts geschlossen werden. Bei aktivem Screenreader kann die Wischgeste „Zurück“ verwendet werden. Dazu mit zwei Fingern ein Zickzack zeichnen (von rechts nach links nach rechts).

Tipps zur Bedienung von Android:

• Eingeblendete Inhalte enthalten oftmals keine explizite „Schließen-Funktion“. Im Standardmodus können diese Inhalte mittels Tippens außerhalb des eingeblendeten Inhalts geschlossen werden. Bei aktivem Screenreader kann die Wischgeste „Zurück“ verwendet werden. Dazu mit zwei Fingern vom äußeren linken Rand zur Mitte wischen.

Bewertungsalterativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Nutzende mit einer Sehbeeinträchtigung arbeiten häufig mit einer sehr starken Vergrößerung. müssen gegebenenfalls unabsichtlich ausgelöste, zusätzliche Inhalte auszublenden bzw. schließen können, ohne den Fokus zu bewegen, da häufig Informationen im Hintergrund überlagert werden. Der Inhalt darf nicht automatisch ausgeblendet werden, um genug Zeit zum Lesen sicherzustellen. Menschen mit motorischen Einschränkungen, die Schwierigkeiten beim präzisen Navigieren oder Steuern haben, können durch korrekte Interaktionsmethoden wie besser auf Inhalte zugreifen. Eine klare und vorhersehbare Benutzererfahrung ist besonders für Menschen mit kognitiven Beeinträchtigungen wichtig. Die Vermeidung unerwarteter Veränderungen durch eingeblendete Inhalte trägt dazu bei, eine weniger verwirrende Umgebung zu schaffen.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.1.4.13 Content on hover or focus

• WCAG v2.1 Kapitel 1.4.13 Content on hover or focus

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Die Mobile App ist ohne Verwendung von Touch- oder Wischgesten ausschließlich über eine externe Tastatur bedienbar. Ein eventuell auf der Tastatur vorhandenes Track-Pad ist nicht Bestandteil der Prüfung. Falls die Seite scrollbare Bereiche enthält, sollen die nicht sichtbaren Inhalte über die Tastatur erreichbar sein. Die Reihenfolge, in der die Elemente fokussiert werden, spielt in diesem Prüfschritt keine Rolle.

Prüfende müssen mit der Funktionsweise der Tastaturbedienung vertraut sein.

Testvorgehen

• Externe Tastatur verbinden.

• Prüfen, ob alle interaktiven Elemente mit der Tabulatortaste erreicht werden können.

• Prüfen, ob alle interaktiven Elemente mit der Leertaste oder der Eingabetaste ausgelöst werden können.

• Prüfen, ob Auswahlelemente mit den Pfeiltasten ausgewählt werden können.

• Prüfen, ob Auswahlelemente mit der Leertaste oder der Eingabetaste bestätigt werden können.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

Warum wird das geprüft?

Viele motorisch beeinträchtigte Menschen sind auf die Tastaturbedienung angewiesen. Ihre Feinmotorik reicht für die Bedienung mit Händen und Fingern nicht aus. Die Tastaturbedienbarkeit erhöht zudem die Gebrauchstauglichkeit für alle Menschen, da sie einen effizienten, alternativen Bedienweg bei intensiver Nutzung bereitstellt.

Abgrenzung

• Die Prüfung auf eine sinnvolle Fokus-Reihenfolge beim Bedienen mit Tastatur erfolgt in Prüfschritt 11.2.4.3 Sinnvolle Reihenfolge bei Bedienung mit externer Tastatur.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.1.1 Keyboard

• WCAG v2.1 Kapitel 2.1.1 Keyboard

• ISO 9241-171 Kapitel 8.5.5 Der unterstützenden Technik die Änderung von Fokus und Auswahl ermöglichen

• ISO 9241-171 Kapitel 9.3.2 Nutzung aller Funktionen über die Tastatur ermöglichen

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Der Fokus bei Tastaturnavigation als auch bei Wischnavigation bei aktivem Screenreader muss beim Erreichen eines Elements auch wieder vom Element wegbewegt werden können. Die Inhalte dürfen an keiner Stelle Elemente, Bereiche oder Menüs enthalten, die nicht ohne Wischen, direktes Antippen eines anderen Elements oder einen erzwungenen Neustart der Mobile App wieder verlassen werden können.

Im Betriebssystem iOS sind in aller Regel Seitengrenzen definiert. Beim Erreichen des ersten und letzten Elements einer Seite ist das jeweilige Ende der Seite erreicht, diese Grenzen sind nicht als Fehler zu werten.

Testvorgehen

• Externe Tastatur verbinden.

• Prüfen, ob alle Elemente mit der Tabulatortaste erreicht und wieder verlassen werden können.

• Externe Tastatur entfernen.

• Screenreader aktivieren.

• Prüfen, ob alle Elemente mittels Wischnavigation erreicht und wieder verlassen werden können.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

Warum wird das geprüft

Viele motorisch beeinträchtigte Menschen sind auf die Tastaturbedienung angewiesen. Ihre Feinmotorik reicht für die Bedienung mit Händen und Fingern nicht aus. Die Tastaturbedienbarkeit erhöht zudem die Gebrauchstauglichkeit für alle Menschen, da sie einen effizienten, alternativen Bedienweg bei intensiver Nutzung bereitstellt.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.1.2 No keyboard trap

• WCAG v2.1 Kapitel 2.1.2 No keyboard trap

• ISO 9241-171 Kapitel 8.4.7 Unterstützung der Funktion „Kopieren“ in nicht editierbarem Text

• ISO 9241-171 Kapitel 9.3.2 Nutzung aller Funktionen über die Tastatur ermöglichen

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Verwendet die Mobile App Tastaturkürzel über Einzeltasten (Buchstaben, Zahlen, Satzzeichen, Symbole), müssen die Tastaturkürzel abschaltbar sein oder auf eine Tastenkombination mit Verwendung einer zusätzlichen Modifikator-Taste umgestellt werden können, oder das Tastaturkürzel ist nur aktiv, wenn die entsprechende Benutzeroberflächenkomponente den Fokus erhält. Für Mehrtastenkombinationen darf die Umschalttaste nur in Kombination mit einer weiteren Modifikationstaste verwendet werden.

Testvorgehen

• Externe Tastatur verbinden.

• Leeren Bereich der Seite anklicken (gegebenenfalls mittels Screen-Tap in einen leeren Bereich).

• Nacheinander auf alle Tasten mit Ausnahme der Modifikator-Tasten (STRG, ALT, ENTER, Tab, Pfeiltasten, Funktionstasten F1-F12) drücken.

• Umschalttaste gedrückt halten und erneut Nacheinander auf alle Tasten mit Ausnahme der Modifikator-Tasten (STRG, ALT, ENTER, Tab, Pfeiltasten, Funktionstasten F1-F12) drücken.

• Nacheinander interaktive Elemente der Seite fokussieren, und erneut auf alle Tasten mit Ausnahme der Modifikator-Tasten (STRG, ALT, ENTER, Tab, Pfeiltasten, Funktionstasten F1-F12) drücken. Vorgehensweise bei gedrückter Umschalttaste wiederholen.

• Falls einzelne Tasten eine Funktion auslösen, in den Einstellungen prüfen, ob Konfigurationsmöglichkeiten zum Abschalten oder zum Mappen auf Modifikator-Taste zur Verfügung stehen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

Warum wird das geprüft

Tastenkombinationen können mit den Tastenkombinationen von Assistenztechnologien kollidieren. Tastenkürzel müssen leicht zugänglich oder deaktivierbar sein, damit sie nicht in Konflikt mit den Funktionen von Hilfstechnologien geraten. Auch Nutzende, die Spracheingabe verwenden, können so unerwünschte Konflikte mit Sprachsteuerungsfunktionen vermeiden.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.1.4 Character key shortcuts

• WCAG v2.1 Kapitel 2.1.4 Character key shortcuts

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Bei zeitbegrenzten Inhalten kann die Zeitbegrenzung abgeschaltet, angepasst oder verlängert werden. Diese Anforderung gilt nicht für Limitierungen, die unverzichtbar sind oder ein Echtzeit-Ereignis darstellen. Es gelten folgende Anforderungen:

• Abschalten
  Die Zeitbegrenzung kann abgeschaltet werden, bevor sie eintritt.

• Anpassen
  Die Zeitbegrenzung kann angepasst werden, bevor sie eintritt, mindestens bis zum Zehnfachen der Standardeinstellung.

• Verlängern
  Die Zeitbegrenzung warnt vor Ablauf und stellt mindestens 20 Sekunden Zeit zur Verfügung, um die Zeitbegrenzung mit einer einfachen Handlung zu verlängern. Die Verlängerung kann mindestens 10mal vorgenommen werden.

• Echtzeit-Ausnahme
  Die Zeitbegrenzung ist ein erforderlicher Teil eines Echtzeit-Ereignisses und es ist keine Alternative zur Zeitbegrenzung möglich.

• Unverzichtbare Ausnahmen
  Die Zeitbegrenzung ist unverzichtbar und ihre Verlängerung würde den Vorgang ungültig machen.

• 20 Stunden Ausnahme
  Die Zeitbegrenzung beträgt standardmäßig mehr als 20 Stunden.

Testvorgehen

• Offensichtliche Zeitbegrenzungen identifizieren und prüfen, ob kurz vor Ablauf einer Zeitbegrenzung mit einer einfachen Handlung mindestens eine der in den Anforderungen genannten Möglichkeiten vorgenommen werden kann.

• Mobile App in geöffnetem Zustand 30 Minuten lang nicht nutzen.

• Nicht offensichtliche Zeitbegrenzungen prüfen, ob kurz vor Ablauf einer Zeitbegrenzung mit einer einfachen Handlung mindestens eine der in den Anforderungen genannten Möglichkeiten angeboten wird und vorgenommen werden kann.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

Warum wird das geprüft

Manche Menschen benötigen mehr Zeit, um eine Aktion abzuschließen, insbesondere wenn sie motorisch oder kognitiv beeinträchtigt sind. Die individuelle Anpassung von Zeitlimits stellt sicher, dass Nutzende Aktionen bedienen und abschließen können.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.2.1 Timing adjustable

• WCAG v2.1 Kapitel 2.2.1 Timing adjustable

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn in der Mobile App gleichzeitig bewegte Inhalte und nicht bewegte Inhalte darstellt werden.

Anforderung

Ablenkender Inhalt durch Blinken oder Bewegung soll vermieden werden, zeitlich auf maximal 5 Sekunden begrenzt oder abschaltbar sein. Bewegter Inhalt, der Teil einer essenziellen Aktivität ist, ist von dieser Anforderung ausgenommen. Die Anforderung gilt für jegliche Inhalte, die blinken oder automatisch aktualisiert oder bewegt werden.

Testvorgehen

• Prüfen, ob bewegter Inhalt automatisch nach 5 Sekunden stoppt.

• Falls bewegter Inhalt nicht nach 5 Sekunden automatisch stoppt, prüfen, ob im unmittelbaren Kontext eine Schaltfläche zum Starten und Stoppen des Inhalts zur Verfügung steht.

• Schaltfläche tippen und prüfen, ob die Bewegung des Inhalts gestoppt wird.

• Sicherstellen, dass die Bewegung nicht automatisch wieder gestartet wird.

• Schaltfläche erneut tippen und prüfen, ob die Bewegung des Inhalts gestartet wird.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Blinkende oder sich bewegende Inhalte führen bei vielen Menschen zu Ablenkung. Sie können sich nicht auf andere Inhalte konzentrieren und verlieren den Fokus. Menschen mit beeinträchtigtem Sehvermögen oder Leseschwierigkeiten benötigen zudem ausreichend Zeit zur Verarbeitung der Informationen, um sie zu verstehen. Screenreadernutzern sind durch automatische Aktualisierungen gestört und verlieren Wahrnehmung und Orientierung bis hin zu Verschiebungen des Fokus.

Abgrenzung

• Die Prüfung auf flackernde Inhalte erfolgt in Prüfschritt 11.2.3.1 Verzicht auf Flackern.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.2.2 Pause, stop, hide

• WCAG v2.1 Kapitel 2.2.2 Pause, stop, hide

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Die Mobile App enthält keine Elemente, die in einem Zeitraum von 1 Sekunde öfter als dreimal aufblitzen.

Testvorgehen

• Flackernde Elemente identifizieren und prüfen, ob das Element öfter als dreimal pro Sekunde flackert.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

Warum wird das geprüft

Grelles Flackern in bestimmten Frequenzen kann bei Menschen mit Epilepsie einen Anfall auslösen.

Abgrenzung

• Die Prüfung auf bewegte Inhalte erfolgt in Prüfschritt 11.2.2.2 Bewegte Inhalte abschaltbar.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.3.1 Three flashes or below threshold

• WCAG v2.1 Kapitel 2.3.1 Three flashes or below threshold

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Bei Bedienung der Mobile App mit einer externen Tastatur erhalten interaktive Bedienelemente den Fokus in einer Reihenfolge, die der logischen beziehungsweise visuellen Struktur, oder einem für Tastaturnutzende optimiertem Bedienablauf entspricht. Die Navigation erfolgt hierbei anhand der Bedienelemente von Element zu Element.

Ausgeblendete oder unsichtbare Inhalte, Layout-Objekte oder Inhalte, die im Hintergrund liegen, dürfen dabei nicht fokussiert werden. Bei einem Seitenaufruf soll das erste Element im Fokus das erste Bedienelement sein. Bietet die Seite eine zentrale Funktion (beispielsweise das Suchfeld der Google Suche), so kann das Suchfeld direkt fokussiert werden.

Bei modalen Dialogen muss das erste Bedienelement innerhalb des Dialogs fokussiert werden. Eine Navigation ist nur innerhalb des Dialogs möglich, bis er geschlossen wird. Nach Schließen des Dialogs muss sich der Fokus am zuvor auslösenden Bedienelement befinden. Sollte der Dialog beim Start der Mobile App oder beim Aufruf einer Seite automatisch geöffnet werden, muss sich der Fokus nach Schließen des Dialogs am ersten Bedienelement der Seite befinden.

Testvorgehen

• Externe Tastatur verbinden.

• Mobile App öffnen. Hierbei darauf achten, dass das erste Bedienelement der Seite fokussiert wird.

• Prüfen, ob mittels Navigation mit der Tabulatortaste interaktive Elemente den Fokus in einer Reihenfolge, die der logischen beziehungsweise visuellen Struktur, oder einem für Screenreadernutzenden optimiertem Bedienablauf entspricht, erhalten.

Tipps zur Bedienung von iOS:

• iOS Tastatur-Shortcuts

Tipps zur Bedienung von Android:

• Android Tastatur-Shortcuts

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

Warum wird das geprüft

Viele motorisch beeinträchtigte Menschen sind auf die Tastaturbedienung angewiesen. Ihre Feinmotorik reicht für die Bedienung mit Händen und Fingern nicht aus. Durch eine nicht nachvollziehbare Reihenfolge der fokussierten Elemente wird die Bedienbarkeit für diese Nutzenden erheblich beeinträchtigt. Die Tastaturbedienbarkeit erhöht zudem die Gebrauchstauglichkeit für alle Menschen, da sie einen effizienten, alternativen Bedienweg bei intensiver Nutzung bereitstellt.

Abgrenzung

• Die Prüfung auf Sichtbarkeit und Tracking des Fokus erfolgt in Prüfschritt 11.2.4.7 Fokus sichtbar.

• Die Prüfung auf Tastaturbedienbarkeit mit aktivem Screenreader erfolgt in Prüfschritt 11.1.3.2 Sinnvolle Reihenfolge.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.4.3 Focus order

• WCAG v2.1 Kapitel 2.4.3 Focus order

Anwendbarkeit

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

Anforderung

Der Zweck oder das Ziel eines Links kann direkt aus Beschriftung des Links, oder im unmittelbaren Kontext des Links bestimmt werden. Die Beschriftung von Links ist eindeutig. Werden innerhalb eines Kontextes mehrere Links verwendet, muss eine Unterscheidung durch die Beschriftung des Links gewährleistet sein, oder es wird ein anderes unterscheidbares Merkmal verwendet. Dies kann über kontextbezogene, weitere Informationen wie beispielsweise eine verständliche Information auf der Seite, die Handhabung oder Besonderheiten der Links erklärt, durch den Alternativtext einer verlinkten Grafik, durch eine vorhergehende Überschrift, oder durch Piktogramme im Fall von Dokumenten-Links umgesetzt werden.

Wird zum Öffnen des Ziels eine andere Anwendung außerhalb der Mobile App des Betriebssystems geöffnet, oder ist das Ziel ein Dokument, erhält der Nutzende eine entsprechende Information, sofern das Verlassen der Mobile App nicht aus dem Kontext heraus ersichtlich ist.

Verlinkte URLs, E-Mailadressen und Telefonnummern übermitteln ihren Zweck automatisch über das Format und werden nicht bewertet.

Testvorgehen

• Links visuell anhand der Beschriftung des Links, beziehungsweise anhand weiterer Informationen im unmittelbaren Kontext auf eindeutige Unterscheidbarkeit prüfen.

• Falls keine eindeutige, visuelle Unterscheidbarkeit gegeben ist, Screenreader aktiveren und Links fokussieren.

• Prüfen, ob in der programmatisch ermittelbaren Beschriftung eindeutige Informationen zu Zweck oder Ziel des Links ermittelbar sind.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Nutzende von Screenreadern lesen Links einzeln und sind auf eine eindeutige Beschriftung angewiesen, um Zweck oder Ziel zu erkennen. Weiterhin bieten die Betriebssysteme die Möglichkeit, sämtliche Links einer Seite zu fokussieren. Der Zweck dieser Technik scheitert, wenn Linkbezeichnungen mehrfach vorkommen. Eine eindeutige Beschriftung unterstützt zudem Nutzende mit kognitiven Beeinträchtigungen oder Lernschwierigkeiten dabei, den Inhalt besser zu verstehen und zu verarbeiten.

Abgrenzung

• Die Prüfung von Alternativtexten für verlinkte Bilder und Grafiken erfolgt in Prüfschritt 11.1.1.1a Alternativtexte für interaktive Grafiken und Objekte.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.4.4 Link purpose (in context)

• WCAG v2.1 Kapitel 2.4.4 Link purpose (in context)

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Inhalte werden visuell durch Überschriften strukturiert und beschreiben den nachfolgenden Inhalt zutreffend. Formularelemente sind aussagekräftig und zum Element passend beschriftet.

Testvorgehen

• Prüfen, ob die Inhalte sinnvoll durch Überschriften strukturiert sind.

• Prüfen, ob die Überschriften im Zusammenhang mit den durch sie strukturierten Inhalten aussagekräftig sind.

• Prüfen, ob Formularelemente zutreffend beschriftet sind.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

Warum wird das geprüft

Nutzende können durch Strukturierung Inhalte leicht überblicken und gezielt auf Inhalte zugreifen. Knappe und zutreffende Beschriftungen unterstützen jeden Nutzenden, den Sinn eines Elements oder einer Gruppe von Elementen schnell zu erfassen.

Abgrenzung

• Die Prüfung auf programmatische Ermittelbarkeit von Überschriften erfolgt in Prüfschritt 11.1.3.1a Strukturelemente für Überschriften.

• Die Prüfung auf programmatische Ermittelbarkeit der Beschriftung von Formularelementen erfolgt in Prüfschritt 11.1.3.1c Strukturelemente für weitere Objekte.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.4.6 Headings and labels

• WCAG v2.1 Kapitel 2.4.6 Headings and labels

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Während der Bedienung mit einer externen Tastatur, mit aktivem Screenreader oder mit Tastatur und aktivem Screenreader muss der Fokus zu jeder Zeit deutlich sichtbar sein. Der Fokus wird hierbei durch einen deutlich sichtbaren Rahmen, der das Element umrahmt, oder durch farbliches Ausfüllen der Elementfläche visualisiert.

Seiten, die mehr Inhalt bereitstellen als auf dem Bildschirm des Endgeräts angezeigt werden kann, müssen den Bildschirminhalt den Fokus verfolgend automatisch verschieben.

In Eingabefeldern muss zusätzlich zur Fokussierung des Elements der Cursor im Eingabefeld angezeigt werden.

Versteckte Sprunglinks sollen bei Fokuserhalt eingeblendet werden.

Für die Darstellung des Fokus gilt generell eine Kontrastanforderung von 3:1 zum Hintergrund und zum interaktiven Element.

Testvorgehen

• Externe Tastatur verbinden.

• Prüfen, ob der Fokus bei Navigation mit der Tabulatortaste an allen Stellen die Anforderungen erfüllt.

• Screenreader aktivieren.

• Prüfen, ob der Fokus bei Navigation mit Tabulator- und Pfeiltasten bei aktivem Screenreader an allen Stellen die Anforderungen erfüllt.

• Externe Tastatur entfernen.

• Prüfen, ob der Fokus bei Wischnavigation bei aktivem Screenreader an allen Stellen die Anforderungen erfüllt.

• Prüfschritte mit aktiver Bildschirmlupe wiederholen.

Tipps zur Bedienung von iOS:

• Unter Einstellungen > Bedienungshilfen > Tastaturen > Tastatursteuerung > Erscheinungsbild kann die farbliche Darstellung des Fokusrahmens individualisiert werden.

Tipps zur Bedienung von Android:

• Unter Einstellungen > Bedienungshilfen > TalkBack > Einstellungen > Fokusanzeige anpassen kann die farbliche Darstellung des Fokusrahmens individualisiert werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

Warum wird das geprüft

Gerade für Menschen mit Beeinträchtigung des Sehvermögens, aber auch für Menschen mit motorischer Einschränkung ist es wichtig zu erkennen, welche Stelle aktuell fokussiert wird, welches Element gerade aktiv ist oder wo Eingaben erscheinen werden. Ohne sichtbaren Fokus ist die Mobile App für optisch orientierte Menschen nicht bedienbar.

Abgrenzung

• Die Prüfung auf die Einhaltung von Kontrastverhältnissen erfolgt in Prüfschritt 11.1.4.11 Nicht-Text-Kontrast.

• Die Prüfung auf Verdecken des Fokusrahmens erfolgt in Prüfschritt 11.2.4.11 Fokus nicht verdeckt (Minimum).

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.4.7 Focus visible

• WCAG v2.1 Kapitel 2.4.7 Focus visible

• ISO 9241-171 Kapitel 9.2.2 Für deutliche Sichtbarkeit des Tastaturfokus- und Text-Indikators sorgen

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Während der Bedienung mit einer externen Tastatur, mit aktivem Screenreader oder mit Tastatur und aktivem Screenreader darf der Fokusrahmen, genauso wenig wie lediglich ein deutlich sichtbarerer Teil des Fokusrahmens zu keiner Zeit von anderen Inhalten oder Inhaltselementen der Mobile App teilweise oder vollständig verdeckt werden. Dies gilt auch für durch den Nutzenden eingeblendete Inhalte, wie Ausklapplisten oder Menüs.

Testvorgehen

• Externe Tastatur verbinden.

• Prüfen, ob der Fokusrahmen bei Navigation mit der Tabulatortaste an allen Stellen die Anforderungen erfüllt.

• Erweiterbare Inhalte aufklappen und fokussieren.

• Auf Inhalte navigieren, die von den aufgeklappten Inhalten überlappt werden und prüfen, ob diese den sichtbaren Fokusrahmen verdecken.

• Screenreader aktivieren.

• Prüfen, ob der Fokusrahmen bei Navigation mit Tabulator- und Pfeiltasten bei aktivem Screenreader an allen Stellen die Anforderungen erfüllt.

• Erweiterbare Inhalte aufklappen und fokussieren.

• Auf Inhalte navigieren, die von den aufgeklappten Inhalten überlappt werden und prüfen, ob diese den sichtbaren Fokusrahmen verdecken.

• Externe Tastatur entfernen.

• Prüfen, ob der Fokusrahmen bei Wischnavigation bei aktivem Screenreader an allen Stellen die Anforderungen erfüllt.

• Erweiterbare Inhalte aufklappen und fokussieren.

• Auf Inhalte navigieren, die von den aufgeklappten Inhalten überlappt werden und prüfen, ob diese den sichtbaren Fokusrahmen verdecken.

Tipps zur Bedienung von iOS:

• Unter Einstellungen > Bedienungshilfen > Tastaturen > Tastatursteuerung > Erscheinungsbild kann die farbliche Darstellung des Fokusrahmens individualisiert werden.

Tipps zur Bedienung von Android:

• Unter Einstellungen > Bedienungshilfen > TalkBack > Einstellungen > Fokusanzeige anpassen kann die farbliche Darstellung des Fokusrahmens individualisiert werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

Warum wird das geprüft

Gerade für Menschen mit Beeinträchtigung des Sehvermögens, aber auch für Menschen mit motorischer Einschränkung ist es wichtig zu erkennen, welche Stelle aktuell fokussiert wird, welches Element gerade aktiv ist oder wo Eingaben erscheinen werden. Wird der Fokusrahmen ganz oder teilweise von anderen Elementen oder Inhalten verdeckt, verlieren optisch orientierte Menschen leicht die Orientierung.

Abgrenzung

• Die Prüfung auf die Einhaltung von Kontrastverhältnissen erfolgt in Prüfschritt 11.1.4.11 Nicht-Text-Kontrast.

• Die Prüfung auf grundlegende Sichtbarkeit des Fokusrahmens erfolgt in Prüfschritt 11.2.4.7 Fokus sichtbar.

Verweise und Referenzen

• WCAG v2.2 Kapitel 2.4.11 Focus Not Obscured (Minimum)

• ISO 9241-171 Kapitel 9.2.2 Für deutliche Sichtbarkeit des Tastaturfokus- und Text-Indikators sorgen

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn zur Bedienung der Mobile App komplexe Gesten nötig sind, die über die Standards des Betriebssystems hinausgehen.

Anforderung

Komplexe Gesten umfassen pfadbasierte Bewegungen und Mehrpunkt-Gesten. Funktionen, zu deren Bedienung komplexe Gesten notwendig sind, benötigen eine zugängliche Alternative zum Auslösen der Funktion, beispielsweise Tippen, Doppeltippen, Tippen und Halten, oder entsprechende Bedienelemente, beispielsweise Tasten.

Pfadbasierte Bewegungen sind beispielsweise Wischbewegungen, Schieberegler und Karussells, die von der Richtung der Interaktion abhängen, sowie andere Gesten, die einen vorgeschriebenen Pfad verfolgen, wie das Zeichnen einer spezifischen Form. Solche Pfade können mit einem Finger oder Stift auf einem Touchscreen, Grafiktablett oder Trackpad gezeichnet werden.

Ziehen ist eine Bewegung, bei der der Nutzende ein Objekt mit einem Finger aufnimmt und es an eine andere Position bewegt. Diese Bewegung vom Startpunkt zum Endpunkt erfordert nicht, dass der Nutzende einem bestimmten Pfad oder einer bestimmten Richtung folgt. Das Ziehen ist daher nicht pfadbasiert.

Mehrpunkt-Gesten sind beispielsweise das Zoomen durch Zusammenziehen von zwei Fingern, Steuerungen, bei denen ein Finger auf dem Bildschirm ruht und ein zweiter Finger tippt, oder ein Tipp oder Wisch mit zwei oder mehr Fingern.

Von der Anforderung ausgenommen sind essenzielle Funktionen, für die pfadbasierte oder Mehrpunkt-Gesten unverzichtbar sind, beispielsweise das Signieren von Dokumenten mittels Unterschrift.

Testvorgehen

• Prüfen, ob Alternativen für komplexe Gesten zur Verfügung stehen. Dazu gegebenenfalls in der Dokumentation der Mobile App nachlesen, falls vorhanden.

• Falls Bedienelemente als Alternative verfügbar sind, und falls sinnvoll, prüfen, ob sie sich im unmittelbaren Kontext befinden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen mit motorischen Beeinträchtigungen können komplexe Gesten oftmals nicht oder nur eingeschränkt ausführen. Sie benötigen einfache, zugängliche Alternativen zum Ausführen solcher Funktionen.

Abgrenzung

• Die Prüfung, ob zur Bedienung bestimmter Funktionen ein Greifen, Zusammendrücken oder Drehen des Handgelenks erforderlich sind, erfolgt in Prüfschritt 5.5.1 Möglichkeiten der Bedienung.

• Die Prüfung auf Alternativen für Ziehbewegungen erfolgt in Prüfschritt 11.2.5.7 Ziehbewegungen.

• Die Prüfung auf Ausführbarkeit von Funktionen bei aktivem Screenreader erfolgt in Prüfschritt 11.5.2.12 Ausführung verfügbarer Aktionen.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.5.1 Pointer gestures

• WCAG v2.1 Kapitel 2.5.1 Pointer gestures

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn interaktive Elemente vorhanden sind.

Anforderung

Interaktive Elemente erfüllen bei Berührung des Elements mit einem einzelnen Finger mindestens eine der folgenden Bedingungen:

• Kein Down-Event
  Das Down-Event des Fingers führt nicht direkt zum Auslösen der Funktion. Das bedeutet, die Funktion wird nicht durch das reine Drücken des interaktiven Elements ausgelöst. Erst das Loslassen des Elements, indem der Finger nach oben bewegt wird, löst die Funktion aus.

• Abbrechen oder Rückgängig machen
  Die Ausführung der Funktion erfolgt beim Up-Event. Es steht ein Mechanismus zur Verfügung, um die Funktion vor Abschluss abzubrechen, oder die Funktion nach Auslösen rückgängig zu machen.

• Up Reversal
  Das Loslassen des Elements (Up-Event) kehrt die Auswirkungen des vorherigen Drückens (Down-Event) mit dem Finger um. Wenn beispielsweise das Drücken einer Taste etwas aktiviert, wird durch das Loslassen der Taste der Vorgang rückgängig gemacht.

• Essenziell
  Die Funktion muss beim Drücken des Elements (Down-Event) durchgeführt werden. Es gibt keine Option zum Abbrechen oder Rückgängigmachen. Die Funktion wird unmittelbar beim Drücken abgeschlossen (beispielsweise beim Schreiben mit einem Finger oder einem Stift, oder beim Tippen mit einer virtuellen Tastatur).

Die Anforderung gilt nicht für Kontextmenüs, die bei längerem Gedrückthalten eines interaktiven Elements geöffnet werden.

Testvorgehen

• Interaktives Element mit dem Finger berühren und Finger darauf ruhen lassen.

• Prüfen, ob eine Funktion direkt ausgelöst wird.

• Finger vom interaktiven Element wegbewegen (durch Wegwischen des Fingers).

• Prüfen, ob eine Funktion trotz Heben oder Wegwischen des Fingers ausgelöst wird.

• Falls in einer oder beiden Prüfungen eine Funktion ausgelöst wurde, prüfen, ob ein Bestätigungsdialog erscheint, über den die Aktion abgebrochen werden kann.

• Falls in einer oder beiden Prüfungen eine Funktion ausgelöst wurde, prüfen, ob Mechanismen zum Abbrechen oder Rückgängigmachen verfügbar sind.

Es ist nicht notwendig, jedes interaktive Element zu prüfen. Es ist ausreichend, jeden enthaltenen Elementtyp stichprobenartig zu prüfen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen mit motorischen Beeinträchtigungen können Touch-Gesten evtl. nicht punktgenau oder mit notwendiger Genauigkeit ausführen. Zur Fehlervermeidung müssen entsprechende Mechanismen verfügbar sein, um ungewollte Aktionen zu vermeiden, beziehungsweise um sie rückgängig zu machen oder abzubrechen.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.5.2 Pointer cancellation

• WCAG v2.1 Kapitel 2.5.2 Pointer cancellation

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn interaktive Elemente vorhanden sind.

Anforderung

Visuell sichtbare Beschriftungen von interaktiven Elementen, unabhängig davon, ob sie mit reinem Text oder mit Text in grafischen Objekten beschriftet sind, müssen die visuelle in der programmatisch ermittelbaren Beschriftung enthalten. Idealerweise wird die visuelle Beschriftung direkt am Anfang der programmatischen Beschriftung genannt.

Die programmatische Beschriftung kann hierbei weitere Informationen enthalten, die visuell nicht ersichtlich ist.

Testvorgehen

• Screenreader aktivieren.

• Interaktive Elemente fokussieren und prüfen, ob die visuelle Beschriftung enthalten ist, und am Anfang der programmatischen Beschriftung ausgegeben wird.

• Prüfschritte mit aktiver Sprachsteuerung und in Kombination mit aktivem Screenreader wiederholen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Nutzende von Spracheingabe aktivieren Bedienelemente, indem sie die visuell sichtbare Beschriftung als Sprachbefehl diktieren. Weicht die programmatische von der visuellen Beschriftung ab, können Sprachbefehle unter Umständen nicht oder nur über Umwege platziert werden.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.2.5.3 Label in name

• WCAG v2.1 Kapitel 2.5.3 Label in name

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Funktionen durch Bewegung des Endgeräts ausgelöst werden können. Beispiele für Bewegungsaktivierung sind Schütteln, Drehen, Kippen des Endgeräts, oder Bewegen des Endgeräts durch den Raum.

Anforderung

Funktionen, die durch die Bewegung des Endgeräts ausgelöst werden, müssen auch durch Steuerelemente auf der Benutzeroberfläche bedient werden können. Die Reaktion auf die Bewegungsaktivierung kann deaktiviert werden, um ein versehentliches Betätigen zu verhindern, es sei denn, die Bewegungsaktivierung ist für die jeweilige Funktion essenziell (beispielsweise bei einer Schrittzähler-App, oder bei Navigation durch Orte mit unterstützender Anzeige von Informationen zum Ort).

Testvorgehen

• Über Bewegungen prüfen, ob Funktionen auf eine entsprechende Bewegungssteuerung reagieren.

• Falls ja, prüfen, ob entsprechende Steuerelemente zur Bedienung ohne Bewegung verfügbar sind.

• Prüfen, ob die Bewegungssteuerung in den Einstellungen abgeschaltet werden kann.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen mit motorischen Beeinträchtigungen können Bewegungseingaben eventuell nicht oder nicht zielgerichtet mit notwendiger Genauigkeit ausführen. Oftmals sind Endgeräte montiert, was Bewegungseingaben unmöglich macht. Es müssen entsprechende Mechanismen verfügbar sein, um Funktionen auch ohne Bewegungssteuerung nutzen zu können. Zudem können ungewollte Bewegungen bei anderen motorischen Beeinträchtigungsbildern zu nicht gewünschten Eingaben führen. Zur Vermeidung von Fehlern müssen ungewollte Aktionen über eine Deaktivierung der Bewegungssteuerung verhindert werden.

Abgrenzung

• Die Prüfung, ob zur Bedienung bestimmter Funktionen ein Greifen, Zusammendrücken oder Drehen des Handgelenks erforderlich sind, erfolgt in Prüfschritt 5.5.1 Möglichkeiten der Bedienung.

Verweise und Referenzen

• EN 301549 v2.1.2 Kapitel 11.2.5.4 Motion actuation

• WCAG 2.1 Kapitel 2.5.4 Motion actuation

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Funktionen durch Ziehbewegungen (Drag & Drop) ausgeführt werden können.

Anforderung

Sämtliche Funktionen, die über Ziehbewegungen (Drag & Drop) ausgeführt werden können, müssen über eine alternative Eingabemethode (beispielsweise durch Tasten oder durch ein Kontextmenü) durchführbar sein.

Pfadbasierte Gesten sind nicht Bestandteil dieses Prüfschritts.

• Definition einer Ziehbewegung:
  Der Start- und der Zielpunkt der Geste sind an feste Koordinaten gebunden. Die Route zwischen den Punkten spielt hingegen keine Rolle.

• Definition einer pfadbasierte Geste:
  Der Start- und der Zielpunkt der Geste spielen keine Rolle, die Richtung oder Form der Route hingegen schon.

Testvorgehen

• Prüfen, ob für Funktionen, die über Ziehbewegungen ausgeführt werden, alternative Eingabemethoden vorhanden sind.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen mit motorischen Beeinträchtigungen können komplexe Gesten und Ziehbewegungen oftmals nicht oder nur eingeschränkt ausführen. Sie benötigen einfache, zugängliche Alternativen zum Ausführen solcher Funktionen.

Abgrenzung

• Die Prüfung, ob zur Bedienung bestimmter Funktionen ein Greifen, Zusammendrücken oder Drehen des Handgelenks erforderlich sind, erfolgt in Prüfschritt 5.5.1 Möglichkeiten der Bedienung.

• Die Prüfung auf Alternativen für pfadbasierte Gesten erfolgt in Prüfschritt 11.2.5.1 Alternativen für komplexe Gesten.

• Die Prüfung auf Ausführbarkeit von Funktionen bei aktivem Screenreader erfolgt in Prüfschritt 11.5.2.12 Ausführung verfügbarer Aktionen.

Verweise und Referenzen

• WCAG v2.2 Kapitel 2.5.7 Dragging Movements

Anwendbarkeit

Der Prüfschritt kann nur mit Zugriff auf den Quellcode der Mobile App belastbar getestet werden. Während eines Blackbox-Tests in der Praxis, kann nur eine subjektive Überprüfung vorgenommen werden.

Anforderung

User-Interface-Elemente, die die Funktion eines Ziels übernehmen (beispielsweise bei Drag & Drop Events), müssen während der Nutzung eine Zielgröße von mindestens 24 x 24 CSS-Pixel aufweisen. Hierbei gelten folgende Ausnahmen:

• Abstand
  Ziele, die kleiner als 24 x 24 CSS-Pixel sind, bieten ausreichend Abstand zu anderen Zielen. Sie werden so positioniert, dass bei Zentrierung eines Kreises mit einem Durchmesser von 24 CSS-Pixeln auf dem Begrenzungsrahmen des jeweiligen Ziels, der positionierte Kreis keine anderen Ziele, oder andere Kreise für zu kleine Ziele überschneidet

• Gleichwertige Alternative
  Die Funktion kann durch ein anderes Steuerelement (beispielsweise durch eine Taste oder ein Kontextmenü), das sich auf der gleichen Seite befindet, ausgeführt werden

• Inline
  Das Ziel befindet sich in innerhalb eines Fließtexts, oder die Größe des Ziels wird durch die Zeilenhöhe von umgebendem, nicht interaktivem Text eingeschränkt

• Kontrolle durch User-Agent
  Die Größe des Ziels wird vom User-Agent bestimmt und wird vom Autor:in nicht verändert

• Essenziell
  Die Darstellung des Ziels ist unerlässlich oder gesetzlich vorgeschrieben

Testvorgehen

• Prüfen, ob entsprechende User-Interface-Elemente subjektiv eine ausreichende Größe bei Nutzung der Funktion aufweisen.

• Falls nein, prüfen, ob eine oder mehrere der definierten Ausnahmen greifen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Menschen mit motorischen Beeinträchtigungen benötigen zum Ausführen von Touch-Funktionen ausreichend Platz. Sie haben Schwierigkeiten, kleine Ziele punktgenau zu erreichen. Hinreichende Größenverhältnisse verringern die Fehleranfälligkeit, ungewollt falsche Funktionen auszuführen oder falsche Ziele zu treffen.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• WCAG v2.2 Kapitel 2.5.8 Target Size (Minimum)

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Die Mobile App soll die Sprache, in der sie verwendet wird, an das Betriebssystem übermitteln, um die lokalisierte Anzeige von Text und die korrekte Auswahl des Sprachpakets und der korrekten Aussprache des Screenreaders sicherzustellen.

Dies betrifft mindestens die Standardsprache der Mobile App. Bietet sie über eine Sprachauswahl entsprechende Lokalisierungen an, sind auch diese Sprachen Bestandteil der Anforderung.

Worte oder einzelne Passagen oder Phrasen des Inhalts, die von der verwendeten Sprache abweichen, sind nicht Teil der Anforderung. Es wird jedoch empfohlen, entsprechende Inhalte zu kennzeichnen.

Die Qualität von Lokalisierungen ist nicht Bestandteil der Prüfung.

Testvorgehen

• Betriebssystem auf die Standardsprache der Mobile App einstellen.

• Prüfen, ob Texte korrekt angezeigt werden.

• Screenreader aktivieren und prüfen, ob das korrekte Sprachpaket mit korrekter Aussprache automatisch gewählt wird.

• Betriebssystem auf eine andere Sprache als die Standardsprache der Mobile App einstellen.

• Prüfen, ob Texte lokalisiert angezeigt werden, und ob weiterhin das korrekte Sprachpaket des Screenreaders mit korrekter Aussprache automatisch gewählt wird.

• Falls die Mobile App Lokalisierungen anbietet, eine andere Sprache in der Mobile App auswählen.

• Betriebssystem auf eine andere Sprache als die gerade gewählte Sprache in der Mobile App einstellen.

• Prüfen, ob Texte lokalisiert angezeigt werden, und ob das korrekte Sprachpaket des Screenreaders mit korrekter Aussprache automatisch gewählt wird.

Tipps zur Bedienung von iOS:

• Unter Einstellungen > Bedienungshilfen > VoiceOver > Sprachausgabe können weitere Sprachpakete für VoiceOver installiert werden.

Tipps zur Bedienung von Android:

• Unter Einstellungen > Bedienungshilfen > TalkBack > Einstellungen > Einstellungen für Sprachausgabe > Sprachdaten installieren können weitere Sprachpakete für TalkBack installiert werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

Warum wird das geprüft

Screenreader verwenden verschiedene Sprachausgaben für die jeweiligen natürlichen Sprachen. Die Sprachausgabe bestimmt, ob die Inhalte einer Mobile App korrekt ausgesprochen werden. Die Sprache der Mobile App soll programmatisch ermittelbar sein, damit Inhalte korrekt angezeigt und vom Screenreader automatisch das korrekte Sprachpaket gewählt werden. Muss der Nutzende eingreifen, um die Sprachausgabe zu ändern, beeinträchtigt dies Arbeitsabläufe.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.3.1.1 Language of software

• WCAG v2.1 Kapitel 3.1.1 Language of page

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn interaktive Elemente vorhanden sind.

Anforderung

Der Fokuserhalt von Benutzeroberflächenkomponenten bei Bedienung mit einer externen Tastatur und bei Wischnavigation bei aktivem Screenreader darf nicht zu unerwarteten oder unangekündigten Kontextänderungen führen (beispielsweise plötzliches Öffnen von neuen Ansichten oder weiteren Applikationen oder Einblenden von neuen Bedienelementen).

Das Anzeigen von Tooltips oder anderen Hinweisen, die sich beim Weiternavigieren selbständig wieder schließen, gilt nicht als unerwartete Kontextänderung.

Pop-Ups oder modale Dialoge sind nicht Bestandteil der Prüfung.

Testvorgehen

• Externe Tastatur verbinden.

• Interaktive Elemente mittels Tabulatortaste fokussieren und prüfen, ob Kontextänderungen entstehen.

• Screenreader aktivieren.

• Elemente über die Wischnavigation fokussieren und prüfen, ob Kontextänderungen entstehen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Unerwartete oder unangekündigte Kontextänderungen beeinträchtigen die Orientierung von Nutzenden. Sie lenken ab, verwirren, oder bleiben gerade bei Menschen mit Sehbeeinträchtigungen unbemerkt.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.3.2.1 On focus

• WCAG v2.1 Kapitel 3.2.1 On focus

Anwendbarkeit

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

Anforderung

Die Bedienung von Formularelementen (beispielsweise Checkbox, Radio-Button, Auswahlliste) und die Eingabe von Inhalten in Textfelder (Eingabefelder) bei Bedienung mit einer externen Tastatur und bei Bedienung mit aktivem Screenreader darf nicht zu unerwarteten oder unangekündigten Kontextänderungen führen (beispielsweise unerwartetes Öffnen neuer Ansichten, unerwartetes Ausblenden der Tastatur während Texteingabe, oder automatische Großschreibung).

Sinnvolle oder notwendige Kontextänderungen müssen unterhalb des auslösenden Elements erfolgen. Der Fokus darf dabei nicht versetzt werden.

Warnhinweise erscheinen als Antwort aufgrund von Eingaben der Nutzenden. Sofern Sie als Warnung in einem modalen Dialog implementiert wurden, sind sie nicht Bestandteil der Anforderung.

Eindeutige Kontextänderungen sind beispielsweise das Öffnen neuer Ansichten und das Einblenden neuer Inhalte auf derselben Ansicht, wenn diese Inhalte wie eine neue Seite wirken oder Inhalte in stark veränderter Anordnung erscheinen.

Reine Inhaltsänderungen gelten nicht als unerwartete Kontextänderungen bei Eingabe.

Testvorgehen

• Formularelemente identifizieren.

• Formularelemente fokussieren und prüfen, ob bei Bedienung des Elements Kontextänderungen entstehen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Unerwartete oder unangekündigte Kontextänderungen beeinträchtigen die Orientierung von Nutzenden. Sie lenken ab, verwirren, oder bleiben gerade bei Menschen mit Sehbeeinträchtigungen unbemerkt.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.3.2.2 On input

• WCAG v2.1 Kapitel 3.2.2 On input

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn auf mehreren Seiten eine Hilfefunktion angeboten wird. Die Hilfefunktion kann hierbei auf allen Seiten, oder nur auf Seiten, die ein gemeinsamer Zweck verbindet (beispielsweise ein Teilprozess wie ein mehrstufiger Warenkorb-Checkout), angeboten werden.

Anforderung

Wird eine seitenübergreifende Hilfefunktion angeboten, muss diese stets an der gleichen Position relativ zu den Inhalten angezeigt werden, es sei denn, der Nutzende verändert die Reihenfolge der Darstellung. Als Hilfefunktion gelten:

• Kontakt-Angaben (beispielsweise Telefonnummern, E-Mailadressen)

• Persönliche Kontaktaufnahme (beispielsweise Messenger-Dienste, Kontaktformulare, Social Media)

• Möglichkeiten zur Selbsthilfe (beispielsweise Frequently Asked Questions, Hilfe-Seiten)

• Automatisierte Kontaktmechanismen (beispielsweise Chat-Bots)

Testvorgehen

• Prüfen, ob entsprechende Hilfefunktionen stets an der gleichen visuellen Position angezeigt werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Die Positionierung von Hilfefunktionen an gleichbleibender Stelle unterstützt vor allem Menschen mit kognitiver Beeinträchtigung. Sie erleben weniger Ablenkung und werden so befähigt, sich einfacher auf die aktuelle Aufgabe zu konzentrieren. Zudem werden sie beim leichteren Auffinden der Hilfefunktionen unterstützt.

Abgrenzung

• Die Prüfung auf konsistente Fokusreihenfolge bei aktivem Screenreader erfolgt in Prüfschritt 11.1.3.2 Sinnvolle Reihenfolge geprüft.

Verweise und Referenzen

• WCAG v2.2 Kapitel 3.2.6 Consistent Help

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Formularfelder vorhanden sind, die bei fehlerhafter oder unvollständiger Eingabe Fehlermeldungen erzeugen.

Anforderung

Bei fehlerhafter oder unvollständiger Eingabe in Formularfeldern müssen die betroffenen Formularfelder eindeutig identifizierbar sein und der Fehler in Textform beschrieben werden, sofern eine Fehlererkennung implementiert ist. Das Identifizieren der betroffenen Formularfelder kann hierbei auf verschiedene Weise erfolgen:

• Die betroffenen Formularfelder werden am Seitenbeginn beschrieben.

• Die betroffenen Formularfelder werden zusätzlich zur Fehlerbeschreibung deutlich hervorgehoben (Form und Farbe).

• Die Beschriftung der betroffenen Formularfelder ändert sich.

• Die Fehlerbeschreibung wird in unmittelbarer Nähe des betroffenen Formularfelds angezeigt.

• Die Fehlerbeschreibung wird zusammen mit den betroffenen Formularfeldern in einem Warnhinweis angezeigt.

Ist keine Fehlererkennung implementiert, führt das nicht zu einer negativen Bewertung und der Prüfschritt ist nicht anwendbar.

Testvorgehen

• Absichtliche Fehleingaben in Formularfeldern vornehmen (beispielsweise durch leere Pflichtfelder, fehlerhafte E-Mailadressen oder falsche Formate).

• Prüfen, ob Fehlermeldungen ausgegeben werden.

• Falls ja, prüfen, ob die entsprechenden Formularfelder identifizierbar sind, und ob und wie der Fehler in Textform dargestellt wird.

• Prüfen, ob die fehlerhaften Eingaben korrigiert werden können, ohne alle Daten erneut eingeben zu müssen. Sicherheitsrelevante Eingaben sind hiervon nicht betroffen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Für blinde Menschen und Menschen mit Farbfehlsichtigkeit ist eine Fehlerbeschreibung in Textform unerlässlich, um entsprechende Formularfelder identifizieren zu können. Menschen mit Legasthenie vertauschen häufiger Zahlen, Menschen mit motorischen Beeinträchtigungen drücken häufiger versehentlich falsche Tasten. Menschen, die nur einen kleinen Ausschnitt der Anzeige sehen, bemerken einen Fehlerzustand möglicherweise nicht.

Abgrenzung

• Die Prüfung der Aussagekraft von Fehlermeldungen erfolgt in Prüfschritt 11.3.3.3 Fehlerkorrektur.

• Die Prüfung auf Informationsübermittlung rein durch farbliche Darstellung erfolgt in Prüfschritt 11.1.4.1 Verwendung von Farbe.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.3.3.1 Error identification

• WCAG v2.1 Kapitel 3.3.1 Error identification

• ISO 9241-171 Kapitel 8.4.9 Dauerhafte Anzeige von Warnungen oder Fehlerinformationen ermöglichen

• ISO 9241-171 Kapitel 8.4.10 Benutzerbenachrichtigungen einheitlich ausgeben

• ISO 9241-171 Kapitel 8.4.12 Das Navigieren zum Auffinden von Fehlern erleichtern

Anwendbarkeit

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

Anforderung

Beschriftungen, oder falls notwendig Anweisungen, werden für Formularfelder bereitgestellt. Die jeweilige Beschriftung oder Anweisung soll bei Eingabefeldern links neben dem Element oder darüber, bei Checkboxen und Radio-Buttons rechts neben dem Element lokalisiert sein.

Pflichtfelder sind als solche eindeutig gekennzeichnet, beispielsweise durch die zusätzliche Beschriftung „(Pflichtfeld)“. Werden Sie mit Symbolen gekennzeichnet, ist eine Legende zu Beginn des Formulars verfügbar, die die Symbole erklärt.

Sind spezielle Formate bei der Eingabe notwendig, wird das entsprechende Format vor dem Formularelement oder in der Vorbelegung des Formularelements beschrieben.

Eindeutig identifizierbare Formularfelder wie beispielsweise ein Suchfeld, das aus einem Eingabefeld und der Suchentaste besteht, benötigen unter Umständen keine eigene visuelle Beschriftung, da der Einsatzzweck aus dem Kontext ermittelt werden kann (beispielsweise durch Verwendung eines Lupe-Symbols als Taste). Sie müssen jedoch zu jederzeit programmatisch ermittelbar sein.

Die Inhalte von Placeholder-Texten in Formularelementen gelten nicht als Beschriftung.

Testvorgehen

• Prüfen, ob alle Formularfelder beschriftet sind.

• Prüfen, ob Pflichtfelder ausreichend gekennzeichnet sind.

• Prüfen, ob Formularfelder spezielle Formate bei der Eingabe erwarten.

• Falls ja, prüfen, ob das erwartete Format als Anweisung am Formularfeld beschrieben wird.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Für jeden Nutzenden ist es von Vorteil, wenn Formularfelder und die geforderten Eingabeformate am Formularfeld beschrieben werden, denn es ist aufwändig, ein Formular anhand der Fehlermeldungen zu korrigieren. Die geforderte Positionierung von Beschriftungen entspricht den üblichen Gestaltungsrichtlinien. Auch in ausschnitthaften Ansichten ist so einfach erkennbar, welche Beschriftung zu welchem Formularfeld gehört.

Abgrenzung

• Die Prüfung der für Screenreadernutzende relevanten programmatischen Verknüpfung der Beschriftungen zum Formularfeld erfolgt in Prüfschritt 11.1.3.1c Strukturelemente für weitere Objekte.

• Die Prüfung der Aussagekraft von Beschriftungen erfolgt in Prüfschritt 11.2.4.6 Überschriften und Beschriftungen.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.3.3.2 Labels or instructions

• WCAG v2.1 Kapitel 3.3.2 Labels or instructions

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Formularfelder vorhanden sind, die bei fehlerhafter oder unvollständiger Eingabe Fehlermeldungen erzeugen.

Anforderung

Sofern eine Fehlerkennung bei Formularfeldern implementiert ist, müssen die Fehlermeldungen eindeutig sein und Korrekturvorschläge zur Fehlerbehebung benannt werden, es sei denn, dies würde die Sicherheit oder den Zweck des Inhalts gefährden.

Testvorgehen

• Absichtliche Fehleingaben in Formularfeldern vornehmen (beispielsweise durch leere Pflichtfelder, fehlerhafte E-Mailadressen oder falsche Formate).

• Prüfen, ob die entsprechenden Formularfelder identifizierbar sind, und ob und wie der Fehler in Textform konkrete Hinweise zum Fehler beziehungsweise zur Fehlerbehebung vermittelt.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Sofern bereits eine Fehlererkennung implementiert ist, soll sie die Nutzenden optimal unterstützen. Nutzende können Fehler leichter beheben, wenn konkrete Hinweise zur Fehlerbehebung verfügbar sind.

Abgrenzung

• Die Prüfung auf die generelle Implementierung von Fehlererkennung erfolgt in Prüfschritt 11.3.3.1 Fehlererkennung.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.3.3.3 Error suggestion

• WCAG v2.1 Kapitel 3.3.3 Error suggestion

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn über entsprechende Prozesse rechtlich bindende Verpflichtungen eingegangen, finanzielle Transaktionen ausgelöst, oder sensible Nutzerdaten übermittelt werden.

Anforderung

Beinhaltet die Mobile App Prozesse, über die rechtlich bindende Verpflichtungen eingegangen, finanzielle Transaktionen ausgelöst, oder sensible Nutzerdaten übermittelt werden, so muss mindestens eine der folgenden Anforderungen erfüllt sein:

• Vorgang kann rückgängig gemacht werden
  Das Übermitteln der Daten kann rückgängig gemacht werden.

• Daten werden vor Übermittlung überprüft und bestätigt
  Vor Übermittlung der Daten können die Eingaben geprüft und korrigiert werden. Nach einer Bestätigung werden die Daten übermittelt.

• Übermittlung nach Bestätigung
  Die Übermittlung der Daten erfolgt erst nach Bestätigung eines Dialogs, der die Folgen der Übermittlung beschreibt.

Erfolgreiche Übermittlungen sollten nach der Übertragung bestätigt werden.

Testvorgehen

• Beispielhafte Daten erfassen und Prozess fortsetzen.

• Prüfen, ob mindestens eine der Anforderungen erfüllt ist.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Die Überprüfung und Korrektur von sensiblen Daten sind für jeden Nutzenden wichtig. Bei Menschen mit Beeinträchtigung im Speziellen ist das Risiko von Fehleingaben allerdings deutlich erhöht. Menschen mit Legasthenie vertauschen häufiger Zahlen, Menschen mit motorischen Beeinträchtigungen drücken häufiger versehentlich falsche Tasten. Menschen, die nur einen kleinen Ausschnitt der Anzeige sehen, bemerken eine Fehleingabe möglicherweise nicht.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.3.3.4 Error prevention (legal, financial, data)

• WCAG v2.1 Kapitel 3.3.4 Error prevention (legal, financial, data)

• ISO 9241-171 Kapitel 8.4.3 „Rückgängig“- und/oder „Bestätigen“-Funktionen zur Verfügung stellen

Anwendbarkeit

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

Anforderung

Müssen innerhalb eines Prozesses bestimmte, bereits zuvor eingegebene Daten eines Nutzenden erneut eingegeben werden, muss der Nutzende bei der erneuten Eingabe unterstützt werden. Als Unterstützung zählen:

• Die Daten werden bei der Eingabe als Ergänzungsvorschlag angeboten

• Es wird eine Funktion zum automatischen Ausfüllen bereitgestellt

• Die Daten können innerhalb der gleichen Seite kopiert und eingefügt werden

Daten, deren erneute Eingabe unerlässlich oder sicherheitsrelevant ist, oder falls die vorherige Eingabe nicht mehr gültig ist, sind hiervon ausgenommen.

Testvorgehen

• Prüfen, ob Formularfelder innerhalb eines Prozesses redundante Eingaben fordern.

• Prüfen, ob für entsprechende Formularfelder eine Eingabeunterstützung vorhanden ist.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Vermeidung von wiederholter Eingabe durch Nutzende unterstützt Menschen mit kognitiver Beeinträchtigung bei der Vermeidung von Fehleingaben. Sie werden befähigt, sich einfacher auf die aktuelle Aufgabe zu konzentrieren. Auch werden Menschen mit motorischen Beeinträchtigungen, die beispielsweise eine Spracheingabe verwenden, entlastet.

Abgrenzung

• Die Prüfung auf Ausführbarkeit von Funktionen bei aktivem Screenreader erfolgt in Prüfschritt 11.5.2.12 Ausführung verfügbarer Aktionen.

Verweise und Referenzen

• WCAG v2.2 Kapitel 3.3.7 Redundant Entry

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die vollständige Nutzung der Mobile App eine Anmeldung voraussetzt. Der Prüfschritt bezieht sich hierbei nicht auf Registrierungsprozesse.

Anforderung

Der Anmeldeprozess kann ohne Einsatz kognitiver Fähigkeiten (beispielsweise das Merken eines Passworts, oder das Lösen eines Rätsels) durchgeführt werden, es sei denn, es wird mindestens eine der folgenden Möglichkeiten angeboten:

• Einfügen des Passworts durch Kopieren und Einfügen von Text

• Automatisches Einfügen des Passworts über den Passwortmanager des Betriebssystems

• Anmeldung über einen Drittanbieterdienst (beispielsweise Anmeldung mit Apple-ID oder Google-Account)

• Alternative Anmeldung über ein biometrisches Merkmal (beispielsweise Touch-ID oder Face-ID)

• Alternative Anmeldung über das Scannen eines QR-Codes

Es ist nicht ausreichend, wenn zur Anmeldung ausschließlich die Option zum Scannen eines QR-Codes zur Verfügung steht.

Testvorgehen

• Anmeldeprozess der Mobile App starten.

• Prüfen, ob mindestens eine der Möglichkeiten im Anmeldeprozess verwendet werden kann.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Nutzende benötigen eine einfache und zugängliche, und zugleich sichere Methode, um sich in einer Mobile App anmelden zu können. Passworteingaben, die die Nutzung kognitiver Fähigkeiten ohne entsprechende Alternativen vorsehen, stellen für manche Nutzende eine Barriere oder sogar eine Blockade dar.

Abgrenzung

• Die Prüfung auf Alternativen zur Anmeldung über ein biometrisches Merkmal erfolgt in Prüfschritt 5.3 Biometrie.

• Die Prüfung auf eine Alternative zur Anmeldung über die Kamerafunktion (beispielsweise Scannen eines QR-Codes) erfolgt in Prüfschritt 11.2.5.4 Steuerung durch Bewegung.

• Die Prüfung auf Ausführbarkeit von Funktionen bei aktivem Screenreader erfolgt in Prüfschritt 11.5.2.12 Ausführung verfügbarer Aktionen.

Verweise und Referenzen

• WCAG v2.2 Kapitel 3.3.8 Accessible Authentication (Minimum)

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die vollständige Nutzung der Mobile App eine Anmeldung mittels Zwei-Faktor-Authentifizierung voraussetzt. Der Prüfschritt bezieht sich hierbei nicht auf Registrierungsprozesse.

Anforderung

Verwendet der Anmeldeprozess eine Zwei-Faktor-Authentifizierung und versendet im Rahmen der Anmeldung einen Verifizierungscode direkt an das genutzte Endgerät, muss der Verifizierungscode über die Kopieren- und Einfügeoption des Betriebssystems, oder über Komfortfunktionen des Betriebssystems in das Eingabefeld der Anmeldung übertragen werden können.

Zwei-Faktor-Authentifizierungen, die ausschließlich über ein zweites Endgerät durchgeführt werden können, sind von dieser Anforderung ausgenommen.

Testvorgehen

• Anmeldeprozess der Mobile App starten.

• Prüfen, ob der Verifizierungscode der Zwei-Faktor-Authentifizierung über die Kopieren- und Einfügeoption des Betriebssystems, oder über Komfortfunktionen des Betriebssystems in das Eingabefeld der Anmeldung übertragen werden kann.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• WCAG v2.2 Kapitel 3.3.8 Accessible Authentication (Minimum)

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn die vollständige Nutzung der Mobile App eine Anmeldung mittels eines CAPTCHAs voraussetzt. Der Prüfschritt bezieht sich hierbei nicht auf Registrierungsprozesse.

Anforderung

Verwendet der Anmeldeprozess die Lösung eines CAPTCHAs, kann das CAPTCHA auch ohne Einsatz kognitiver Fähigkeiten durchgeführt werden.

CAPTCHAs, die den Einsatz kognitiver Fähigkeiten, sogenannte kognitive Funktionstests voraussetzen, erfordern logisches Schlussfolgern, sowie Fähigkeiten zum sprachlichen, numerischen und figural-bildhaften Denken. Zusätzlich kann spezielles Wissen, wie etwa Sprachkompetenzen und technisches Verständnis, abgefragt werden:

• Merken und Wiedergeben von Buchstaben, Zeichen oder Mustern

• Manuelles Abschreiben von Buchstaben und Zeichen

• Prüfung der korrekten Rechtschreibung

• Lösen von Rechenaufgaben

• Lösen von Rätseln

Bei kognitiven Funktionstests handelt es sich explizit nicht um:

• Erkennen von Bildern, Audio oder Video (beispielsweise Markieren aller PKWs, Markieren aller Bilder mit Ampeln)

• Methoden zur Zwei-Faktor-Authentifizierung

Testvorgehen

• Anmeldeprozess der Mobile App starten.

• Prüfen, ob die CAPCHAs des Anmeldeprozesses ohne den Einsatz kognitiver Fähigkeiten gelöst werden können.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Abgrenzung

• Die Prüfung auf CAPTCHAs, die nicht im Rahmen des Anmeldeprozesses verwendet werden, erfolgt in Prüfschritt 11.1.1.1c Alternativen für CAPTCHAs.

• Die Prüfung auf CAPTCHAs, deren Inhalt kein kognitiver Funktionstest ist, erfolgt in Prüfschritt 11.1.1.1c Alternativen für CAPTCHAs.

Verweise und Referenzen

• WCAG v2.2 Kapitel 3.3.8 Accessible Authentication (Minimum)

Anwendbarkeit

Der Prüfschritt ist durch einen Blackbox-Test nicht prüfbar (Stand Januar 2024). Eventuell auf fehlerhaften Code zurückführbares Fehlerverhalten sollte als Hinweis dokumentiert werden. Ob solche Fehler auf einen falschen oder fehlerhaften Code zurückzuführen sind, kann aber nicht bewertet werden.

Bewertungsalternativen

• Nicht anwendbar

• Nicht getestet

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.4.1.1 Parsing

• WCAG v2.1 Kapitel 4.1.1 Parsing

• ISO9241-171 „Leitlinien für Zugänglichkeit von Software“

Anwendbarkeit

Der Prüfschritt wird über die Prüfschritte 11.5.2.5 Objektinformationen, 11.5.2.7 Werte, 11.5.2.15 Änderungsbenachrichtigung und 11.5.2.16 Änderungen von Zuständen und Eigenschaften abgedeckt. Eine eigene Prüfung dieses Prüfschritts ist nicht notwendig. Sofern einer der genannten Prüfschritte als nicht voll erfüllt gewertet wird, wird auch dieser Prüfschritt entsprechend gewertet, oder dieser Prüfschritt erhält die Bewertung „Nicht getestet“.

Bewertungsalternativen

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht getestet

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.4.1.2 Name, role, value

• EN 301549 v3.2.1 Kapitel 11.5 Interoperability with assistive technology

• WCAG v2.1 Kapitel 4.1.2 Name, role, value

• WCAG-Techniques

• ISO9241-171 „Leitlinien für Zugänglichkeit von Software“

• ISO9241-171 Kapitel 8.1.4 Namen für unterstützende Technik verfügbar machen

• ISO9241-171 Kapitel 8.5. Kompatibilität mit unterstützender Technik

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Statusmeldungen oder ähnliche Aktualisierungen dynamisch generiert werden.

Anforderung

Dynamische Aktualisierungen des Inhalts, die keine Kontextänderung darstellen und dem Nutzenden Informationen über beispielsweise den Status einer Aktion, den Fortschritt eines Prozesses oder das Erkennen von Fehlern bereitstellen, müssen programmatisch anhand geeigneter Rollen oder Eigenschaften durch assistive Technologien ermittelt werden können, ohne explizit den Fokus zu erhalten. Die Benachrichtigung zu solchen Ereignissen muss automatisch an das assistive System übermittelt und ausgegeben werden.

Kontextänderungen, beispielsweise neue Ansichten, neue Interaktionsmöglichkeiten; neue Inhalte auf einer Ansicht, oder Hinweise über Dialoge, werden durch assistive Technologien durch aktive Fokussierung wahrgenommen und sind hiervon nicht betroffen.

Statusmeldungen oder Push-Mitteilungen, die durch das Betriebssystem selbst generiert ausgegeben werden, sind hiervon nicht betroffen.

Testvorgehen

• Screenreader aktivieren.

• Eingabe vornehmen oder Prozess auslösen, der zur Generierung einer Statusmeldung führt.

• Prüfen, ob die Statusmeldung beim Erscheinen vom Screenreader automatisch ausgegeben wird, ohne die Statusmeldung zu fokussieren.

Bewertungsalternativen und Beispiele

• Erfüllt

• Blockade

• Nicht anwendbar

Warum wird das geprüft?

Dynamisch erzeugte Statusmeldungen erscheinen oftmals ungeplant oder nur vorübergehend. Nutzende von assistiven Technologien benötigen grundsätzlich die Information der Statusmeldung, sollen dadurch jedoch nicht die Orientierung oder den aktuellen verlieren.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.4.1.3 Status messages

• WCAG v2.1 Kapitel 4.1.3 Status messages

• WAI-ARIA Authoring Practices 1.1 Kapitel 6.2 Implementing Live Regions

• ISO 9241-171 „Leitlinien für Zugänglichkeit von Software“ 8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen

Anwendbarkeit

Der Prüfschritt ist immer anwendbar.

Anforderung

Die assistiven Systeme des jeweiligen Betriebssystems werden durch die Mobile App unterstützt, indem sie mindestens die Anforderungen in den Prüfschritten 11.5.2.5 bis 11.5.2.17 bedient. Im Fokus steht die generelle Unterstützung der gängigen assistiven Systeme Screenreader, Bildschirmlupe und Sprachsteuerung, gegebenenfalls zusätzlich in Verbindung mit einer externen Tastatur. Die Detailbetrachtung erfolgt in den nachfolgenden Anforderungen.

Testvorgehen

Stichprobenartig prüfen, ob die assistiven Systeme bei Benutzung der Mobile App etwas Sinnvolles ausgeben, beziehungsweise korrekt funktionieren.

• Screenreader aktivieren und stichprobenartig Elemente fokussieren. Wenn der Screenreader bei Fokussierung etwas ausgibt, ist die entsprechende Unterstützung implementiert.

• Gegebenenfalls Bildschirmlupe aktivieren. Werden die Inhalte in dem Bildschirmausschnitt der Lupe vergrößert dargestellt, ist die entsprechende Unterstützung implementiert.

• Gegebenenfalls Sprachsteuerung aktivieren und stichprobenartig prüfen, ob eine Steuerung mittels Spracheingabe möglich ist.

• Gegebenenfalls externe Tastatur verbinden. Ist eine rudimentäre Steuerung möglich, ist die entsprechende Unterstützung implementiert.

Hinweis:

Aufgrund der Funktionalität von Bildschirmlupe und Sprachausgabe ist es an dieser Stelle ausreichend, nur den Screenreader des jeweiligen Betriebssystems zu prüfen.

Tipps zur Bedienung von iOS:

• Der Screenreader (VoiceOver) kann entweder über Siri, oder über Einstellungen > Bedienungshilfen > VoiceOver aktiviert werden.

• Die Bildschirmlupe (Zoom) kann entweder mit Doppeltippen mit 3 Fingern, oder über Einstellungen > Bedienungshilfen > Zoom aktiviert werden.

• Die Sprachsteuerung (VoiceControl) kann entweder über Siri, oder über Einstellungen > Bedienungshilfen > Sprachsteuerung aktiviert werden.

Tipps zur Bedienung von Android:

• Der Screenreader (TalkBack) kann entweder über Hey Google, oder über Einstellungen > Bedienungshilfen > TalkBack aktiviert werden.

• Die Bildschirmlupe (Vergrößerung) kann entweder über einen individuell wählbaren Kurzbefehl, oder über Einstellungen > Bedienungshilfen > Vergrößerung aktiviert werden.

• Die Sprachsteuerung (Voice Access) kann entweder Hey Google, oder über Einstellungen > Bedienungshilfen > Voice Access aktiviert werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

Warum wird das geprüft

Die Unterstützung der assistiven Systeme der Betriebssysteme stellt sicher, dass digitale Inhalte für eine breite Palette von Nutzenden zugänglich und nutzbar sind, unabhängig von deren individuellen Fähigkeiten oder Einschränkungen. Das Setzen auf Standards ermöglicht eine Bedienung der Produkte in einem gewohnten Umfeld.

Abgrenzung

• Die Prüfung individueller Benutzereinstellungen erfolgt in Prüfschritt 11.7 Benutzerpräferenzen.

• Die Prüfung auf Aufrechterhaltung der Funktionalitäten der assistiven Systeme erfolgt in Prüfschritt 11.6.2 Keine Unterbrechung der Barrierefreiheitsfunktionen.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.5.2.3 Use of accessibility services

• WCAG v2.1 Kapitel 5.2.4 Only Accessibility-Supported Ways of Using Technologies

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn interaktive Elemente vorhanden sind.

Anforderung

Interaktive Bedienelemente müssen ihren Namen, ihre Rolle, und gegebenenfalls vorhandene Grenzen oder Beschreibungen korrekt an die assistiven Systeme übermitteln und programmatisch ermittelbar sein. Die programmatische Beschriftung muss die sichtbare Beschriftung mindestens zu Beginn der Beschriftung beinhalten. Idealerweise sind die Beschriftungen in beiden Varianten analog. Dies betrifft beispielsweise:

• Tasten

• Tasten mit eingebetteter Grafik

• Umschalttasten

• Kontrollkästchen

• Optionsfeld

• Registerkarten

• Ausklapplisten

• Formularfelder

• Links

• Links mit eingebetteter Grafik

Testvorgehen

• Screenreader aktivieren.

• Interaktive Bedienelemente fokussieren und auf korrekte Übermittlung eines zutreffenden und aussagekräftigen Namens, einer zutreffenden Rolle und gegebenenfalls vorhandener oder notwendiger Kontextinformationen prüfen.

• Prüfen, ob der sichtbare Name im programmatisch ermittelbaren Namen enthalten ist.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Das Identifizieren und die damit verbundene, korrekte Implementierung von Elementtypen und zugehörigen Kontextinformationen ist gerade für Nutzende von einem Screenreader, als auch für Nutzende von Sprachsteuerung essenziell, denn nur so können die Nutzenden das jeweilige Element im Kontext zuordnen, verstehen und bedienen. Sind Informationen am Element unvollständig oder fehlerhaft, oder weicht die programmatische Beschriftung von der visuellen Beschriftung ab, werden Verständlichkeit, Wahrnehmbarkeit und Bedienbarkeit erheblich eingeschränkt.

Abgrenzung

• Die Prüfung auf Wert oder Zustand von interaktiven Elementen erfolgt in Prüfschritt 11.5.2.7 Werte.

• Die Prüfung auf Übersicht und Ausführung verfügbarer Handlungen zum Steuern interaktiver Elemente erfolgt in den Prüfschritten 11.5.2.11 Übersicht verfügbarer Aktionen und 11.5.2.12 Ausführung verfügbarer Aktionen.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.5.2.5 Object information

• EN 301549 v3.2.1 Kapitel 11.1.1.1 Non-text content

• WCAG v2.1 Kapitel 1.1.1 Non-text content

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Datentabellen oder eine visuelle Strukturierung von Informationen in Tabellenform vorhanden sind.

Anforderung

Der Aufbau von Tabellen ist strukturell korrekt und programmatisch ermittelbar. Die Zuordnung jeder Zelle zu ihrer zugehörigen Zeile und Spalte, der Umfang an Zeilen und Spalten, als auch der Anfang und das Ende der Tabelle sind identifizierbar. Falls vorhanden, werden die Überschriften von Zeile und Spalte wiedergegeben.

Testvorgehen

• Screenreader aktivieren.

• Erste Überschrift der Tabelle fokussieren und prüfen, ob Inhalt (Zeilen- und/oder Spaltentitel), Zeilen und Spaltennummer, die Anzahl vorhandener Zeilen und Spalten und der Anfang der Tabelle korrekt wiedergegeben werden.

• Falls vorhanden, zweite Überschrift fokussieren und analog prüfen.

• Zelle fokussieren und prüfen, ob Inhalt, zugehörige Spalten- und/oder Zeilentitel sowie Koordinaten der Zelle (Spalte x, Zeile y) korrekt wiedergegeben werden.

• Letzte Zelle fokussieren und prüfen, ob Inhalt, zugehörige Spalten- und/oder Zeilentitel, Koordinaten der Zelle (Spalte x, Zeile y) und das Ende der Tabelle korrekt wiedergegeben werden.

Tabellenbeispiel:

Wiedergabe des Screenreaders bei Fokus auf „Mitarbeiter 2020“:

• Mitarbeiter 2020, Spaltentitel, Zeile 1, Spalte 1, Anfang der Tabelle, 2 Zeilen, 2 Spalten.

Wiedergabe des Screenreaders bei Fokus auf „Mitarbeiter 2021“:

• Mitarbeiter 2021, Spaltentitel, Zeile 1, Spalte 2.

Wiedergabe des Screenreaders bei Fokus auf „20 Personen“:

• Mitarbeiter 2020, 20 Personen, Zeile 2, Spalte 1.

Wiedergabe des Screenreaders bei Fokus auf „30 Personen“:

• Mitarbeiter 2021, 30 Personen, Zeile 2, Spalte 2. Ende der Tabelle.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Screenreadernutzende und Menschen mit kognitiver Beeinträchtigung benötigen zur Orientierung in Tabellen besonderes Abstraktionsvermögen. Sie benötigen zu jeder Datenzelle Informationen zu Kontext und Bedeutung. Sind diese Informationen nicht vorhanden, ist die Bedeutung der erreichten Datenzelle unter Umständen nicht verständlich.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.5.2.6 Row, column, and headers

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn interaktive Elemente vorhanden sind, die Werte aufweisen.

Anforderung

Interaktive Bedienelemente, die Werte aufweisen, übermitteln den aktuellen Wert und gegebenenfalls die Position oder die entsprechenden Grenzen korrekt an die assistiven Systeme. Dies betrifft beispielsweise:

• Umschalttasten (aktiviert, nicht aktiviert)

• Kontrollkästchen (ausgewählt, nicht ausgewählt)

• Auswahlschalter (aktiviert, nicht aktiviert)

• Registerkarten (ausgewählt, nicht ausgewählt)

• Ausklapplisten (erweitert, nicht erweitert)

• Formularelemente (Wert des Elements, beispielsweise eingetragener Text)

• Optionen in Ausklapplisten (Eintrag x von y)

Der aktuelle Wert eines entsprechenden Elements wird bei Fokussierung des Elements mit aktivem Screenreader proaktiv wiedergegeben.

Testvorgehen

• Screenreader aktivieren.

• Interaktive Bedienelemente, die Werte aufweisen, fokussieren und auf korrekte Übermittlung des aktuellen Werts prüfen.

Bewertungsalternativen und Beispiele

• Erfüllt

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Das Identifizieren und die damit verbundene, korrekte Implementierung von Werten ist gerade für Screenreadernutzende essenziell, denn nur so können die Nutzenden das jeweilige Element im Kontext zuordnen, verstehen und bedienen. Sind Informationen am Element unvollständig oder fehlerhaft, werden Verständlichkeit und Wahrnehmbarkeit erheblich eingeschränkt.

Abgrenzung

• Die Prüfung auf die Verwendung korrekter Objekttypen von interaktiven Elementen erfolgt in Prüfschritt 11.5.2.5 Objektinformationen.

• Die Prüfung auf korrekte Wiedergabe nach Änderung eines Werts oder Zustands erfolgt in Prüfschritt 11.5.2.15 Änderungsbenachrichtigung.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.5.2.7 Values

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Formularfelder oder interaktive Elemente vorhanden sind, die zum logischen Verständnis einen Bezug zu einer anderen Beschriftung oder einem anderen Inhalt auf der Benutzeroberfläche benötigen.

Anforderung

Formularfelder oder interaktive Elemente, die durch ihre Beschriftung im Kontext nicht direkt oder eindeutig identifizierbar sind und indirekt oder zusätzlich durch ein anderes Element gelabelt werden, oder ein Label für ein anderes Element sind, übermitteln diese verknüpfenden Kontextinformationen an die assistiven Systeme, um den logischen Bezug auch programmatisch ermittelbar nachvollziehen zu können.

Testvorgehen

• Screenreader aktivieren.

• Entsprechende Formularfelder oder interaktive Elemente fokussieren und prüfen, ob der visuelle logische Bezug auch durch den Screenreader wiedergegeben wird.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Label-Beschriftungen erhöhen die Verständlichkeit entsprechender Elemente. Ein intelligentes Arrangement von Label-Beziehungen zu Formular- und Bedienelementen stellt sicher, dass die Elemente der Benutzeroberfläche für Hilfsmitteltechnologien ebenso verständlich und effizient nutzbar sind wie bei der Benutzung ohne Hilfsmittel.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.5.2.8 Label relationships

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn Elemente vorhanden sind, die ihnen übergeordnete oder untergeordnete Elemente beinhalten.

Anforderung

Beziehungen zwischen Elementen und ihnen übergeordneten oder untergeordneten Elementen, die zum logischen Verständnis des jeweiligen Elements notwendig sind, werden an die assistiven Systeme übermittelt und vom Screenreader wiedergegeben.

Testvorgehen

• Screenreader aktivieren.

• Entsprechende Formularfelder oder interaktive Elemente fokussieren und prüfen, ob die Beziehung des Elements zum übergeordneten oder untergeordneten Element durch den Screenreader eindeutig wiedergegeben wird.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Visuell identifizierbare Hierarchien und Zusammengehörigkeiten von Elementen sind für Screenreadernutzende nicht zugänglich. Diese Beziehungen müssen auch programmatisch ermittelbar sein.

Abgrenzung

• Keine Abgrenzung erforderlich.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.5.2.9 Parent-child relationships

Anwendbarkeit

Dieser Prüfschritt ist anwendbar, wenn nicht bearbeitbarer Text vorhanden ist.

Anforderung

Textinhalte werden analog zur visuellen Darstellung durch den Screenreader wiedergegeben. Längerer Text wird bei aktivem Screenreader sinnvoll und absatzweise in Blöcken fokussiert. Visuell hervorgehobene Textinhalte (beispielsweise fett, kursiv, unterstrichen) werden auch innerhalb eines Absatzes vom Screenreader separat fokussiert. Unnötige Sonderzeichen werden vom Screenreader ignoriert.

Abkürzungen werden vom Screenreader ungekürzt ausgesprochen. Spezielle Formate, beispielsweise Informationen zu Datum oder Uhrzeit, werden im jeweiligen Format korrekt wiedergegeben.

Es wird dringend empfohlen, entsprechend relevante Inhalte, beispielsweise eine IBAN, eine Postleitzahl oder eine Telefonnummer, auf eine Art zu implementieren, dass sie vom Screenreader zeichenweise buchstabiert ausgegeben werden. Dies ist technisch unter Umständen nicht in allen Umgebungen umsetzbar und kann somit nicht gefordert werden.

Testvorgehen

• Screenreader aktivieren.

• Text fokussieren und prüfen, ob die Inhalte analog zur visuellen Darstellung wiedergegeben werden.

• Text fokussieren und prüfen, ob die Inhalte absatzweise und in sinnvollen Blöcken wiedergegeben werden.

• Hervorgehobene Inhalte fokussieren und prüfen, ob die Inhalte separat fokussiert werden.

• Spezielle Formate fokussieren und prüfen, ob die relevanten Inhalte sinnvoll wiedergegeben werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Leichte Einschränkung

• Einschränkung

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Nicht nur der Inhalt von Text, sondern auch die Formatierung vermittelt Informationen. Fetter oder kursiver Text deutet wichtige Informationen innerhalb eines Absatzes an. Hilfsmitteltechnologien müssen diese Informationen erfassen können, damit das dahinter liegende Kommunikationskonzept von allen Nutzenden nachvollzogen werden kann. Weiterhin ist bei speziellen Akronymen, Begriffen oder Werten die zeichenweise Ausgabe über den Screenreader zum besseren Verständnis essenziell. Hilfsmitteltechnologien müssen diese Informationen erfassen können, damit der Kontext von allen Nutzenden nachvollzogen werden kann.

Abgrenzung

• Die Prüfung von bearbeitbarem Text erfolgt in Prüfschritt 11.5.2.10b Bearbeitbarer Text.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.5.2.10 Text

Anwendbarkeit

Dieser Prüfschritt ist anwendbar, wenn bearbeitbarer Text, beispielsweise in Texteingabefeldern, vorhanden ist.

Anforderung

Textinhalte werden analog zur visuellen Darstellung durch den Screenreader wiedergegeben.

Textformatierungen werden idealerweise vom Screenreader nach der Ausgabe des Inhalts des fokussierten Textabschnitts wiedergegeben, sofern diese vom Nutzenden geändert werden können (beispielsweise Fett, Kursiv, Schriftgröße, Schriftart).

Testvorgehen

• Screenreader aktivieren.

• Texteingabefeld öffnen und beispielhaften Text eingeben.

• Sofern möglich, Formatierung stellenweise ändern.

• Textinhalt mittels wortweiser Navigation fokussieren und prüfen, ob die Inhalte analog zur visuellen Darstellung wiedergegeben werden.

• Textinhalt mittels wortweiser Navigation fokussieren und prüfen, ob Formatierungen gemäß den Anforderungen ausgegeben werden.

Bewertungsalternativen und Beispiele

• Erfüllt

• Barriere

• Blockade

• Nicht anwendbar

Warum wird das geprüft

Nicht nur der Inhalt von Text, sondern auch die Formatierung vermittelt Informationen. Fetter oder kursiver Text deutet wichtige Informationen innerhalb eines Absatzes an. Hilfsmitteltechnologien müssen diese Informationen erfassen können, damit das dahinter liegende Kommunikationskonzept von allen Nutzenden nachvollzogen werden kann. Weiterhin ist bei speziellen Akronymen, Begriffen oder Werten die zeichenweise Ausgabe über den Screenreader zum besseren Verständnis essenziell. Hilfsmitteltechnologien müssen diese Informationen erfassen können, damit der Kontext von allen Nutzenden nachvollzogen werden kann.

Abgrenzung

• Die Prüfung von nicht bearbeitbarem Text erfolgt in Prüfschritt 11.5.2.10a Nicht bearbeitbarer Text.

• Die Prüfung auf korrekte Unterstützung der Bearbeitung und Änderung von Texteingaben bei aktiven Bedienungshilfen erfolgt in Prüfschritt 11.5.2.17 Änderungen von Werten und Text.

• Das Steuerungsverhalten des Cursors in Texteingabefeldern bei aktiven Bedienungshilfen erfolgt in Prüfschritt 11.5.2.14 Änderung des Fokus und der Auswahlattribute.

Verweise und Referenzen

• EN 301549 v3.2.1 Kapitel 11.5.2.10 Text

Anwendbarkeit

Der Prüfschritt ist anwendbar, wenn interaktive Elemente vorhanden sind.

Anforderung

Interaktive Bedienelemente übermitteln eine Übersicht ihrer verfügbaren Aktionen, als auch die Art und Weise, wie die jeweilige Aktion bei aktivem Screenreader ausgeführt wird, korrekt an die assistiven Systeme. Dies betrifft beispielsweise:

• Tasten (Zum Ausführen doppeltippen)

• Umschalttasten (Zum Umschalten doppeltippen)

• Kontrollkästchen (Zum Ändern doppeltippen)

• Auswahlschalter (Zum Auswählen doppeltippen)

• Registerkarten (Zum Auswählen doppeltippen)

• Ausklapplisten (Zum Auswählen doppeltippen)

• Formularfelder (Zum Bearbeiten doppeltippen, oder Zum Einfügen von Text doppeltippen)

• Links (Zum Öffnen doppeltippen)