11.1.1.1.1 Nicht-Text-Inhalt (offene Funktionalität)

Empfehlungen

Empfehlung

Text Screenreader bei Inputfeldern

Um eine Nutzbarkeit mit Screenreadern zu gewährleisten, sollten Textfelder so benannt sein, dass der Nutzende weiß, was dort einzugeben ist und welche Art von Feld es ist. ### Beispiele #### Login - E-Mail und Passwort Felder werden doppelt vorgelesen und die Benennung der Art des Eingabefeldes könnte genauer ausfallen (iOS: "E-Mail Adresse E-Mail Adresse Textfeld" und "Passwort Passwort verschlüsseltes Textfeld", Android: "Passwort Passwort Bearbeitungsfeld")

Verstöße

Verstoß

Kein Alternativtext Icons und Bilder ohne Text

Icons, die ohne einen zusätzlichen Textdargestellt sind und als Bedienelement fungieren, müssen einen ausreichenden Text haben. Ebenso müssen auch Bilder so beschrieben sein, dass Personen, die den Screenreader benutzen, die gleichen Informationen erhalten wie Sehende. ### Beispiele #### Login - Passwort ein- und ausblenden: Nutzt man einen Screenreader wird auf der Seite Login zwar der Fokus auf dem Auge-Icon gesetzt, um dort das Passwort ein- oder auszublenden, es wird jedoch kein Alternativtext vorgelesen. (iOS: keine Sprachausgabe an dieser Stelle Android: "zum Aktivieren doppeltippen" -> Keine Information über Funktion des Buttons) - Einstellungen: Das Zahnrad, um zu den Einstellungen zu kommen, ist nur unter iOS benannt ("Einstellungen"). Unter Android fehlt dieser Alternativtext hingegen. - Das Bild mit dem Bus in der Landschaft wird dem Screenreader Nutzenden nicht beschrieben. #### Ticketansicht - Icon für Rechnung versenden (Brief Icon) nicht benannt bei Android. Bei iOS wird "EMail" gesagt. Besser sollte es aber darauf hinweisen, dass über die Schaltfläche eine Rechnung versendet wird. #### eezy Fahrt beginnen - info-Icon: Das info-Icon oben rechts ist nur unter iOS benannt ("Information"). Unter Android fehlt dieser Alternativtext hingegen. - Das Bild am Beginn der Seite ist nicht beschrieben #### eezy Einstieg - Refresh Button bei nicht gefundener Einstiegshaltestelle ist nicht benannt

Verstoß

Alternativtexte für Bedienelemente

Bedienelemente müssen einen geeigneten Alternativtext haben. Dieser muss klar darstellen, welche Funktion der Button erfüllt. ### Beispiele #### Login: - Buttons Login (aktuell: iOS/Android: "button_login") - Passwort vergessen (aktuell: iOS/Android: "button_forgot_password") - Registrieren (aktuell: iOS/Android: "button_register") #### Ticketkonfiguartion - Auswahl Preisstufe: Bei Android wird der Fokus auf dem Akkordeon gelegt zum Ausklappen der Preisklassen, aber es wird "productclass view" vorgelesen. Erst im zweiten Schritt erfolgt dann die korrekte Bezeichnung "Preisstufe". Bei iOS wird es direkt richtig als "Preisstufe" vorgelesen. - Button Kaufen: Sowohl auf Android als auch unter iOS wird "buy_ticket" vorgelesen #### eezy Einstieg - Android: bei allen Zubuchungen wird nicht vorgelesen, welche Änderungen vorgenommen werden können (vorgelesen wird: "Bindestrich" "Plus" bzw. "deaktiviert"

Verstoß

Nur Bedienfelder als solche benennen

Wird über den Screenreader vorgelesen, dass es sich um einen Button oder ähnliches handelt, dann sollte dieses Element auch entsprechend bedient werden können. ### Beispiele #### Ticketkonfiguration - Direkt auf dem Ticketbild befindet sich ein Button, welcher jedoch nicht tabbar ist. Unter Android wird jedoch vorgelesen, dass sich hier ein Button befindet, sodass Nutzende versuchen dies auszuwählen. Bei iOS wird nur der Preis vorgelesen. so sollte es auch bei Android sein. - Akkordeon "Preisstufe" sollte als Bedienfeld genannt werden

Verstoß

Sprachausgabe bei gültigen Tickets

Die Verwendung des Screenreaders bei der Anzeige aktuell gültiger Tickets sollte grundsätzlich angepasst werden. Der Screenreader Nutzende erhält nicht die Infos, die er auf diesem Screen bekommen sollte. Es entsteht ein deutlicher Unterschied zu dem Informationsgehalt für sehende. ###Beispiele - Android: Fokus auf dem gesamten Ticket; es wird vorgelesen: "EinzelTicket Kinder unbenannt, unbenannt, unbenannt, unbenannt läuft ab in..." - iOS: die Reihenfolge des Vorgelesenen ist nicht immer korrekt (erst QR Code, dann läuft ab in... und danach Zoom fr QR Code) - Android: Ist der Fokus auf dem QR Code wird vorgelesen "QR Code". Ist der Fokus danach auf der Lupe, gibt es keinen hinterlegten Text der vorgelesen wird. Der Nutzende erfährt gar nicht, dass man den QR Code durch klick größer stellen kann - Mit Screenreader können Nutzende nicht erfahren, bei welchen Verkehrsverbünden das Ticket gültig ist, da diese nur als Bild hinterlegt sind und nicht vorgelesen werden

Verstoß

Falscher Fokus gesetzt

Es sollte immer darauf geachtet werden, dass nur wichtige Inhalte fokussiert werden. ### Beispiele #### Profil Login - Android: Nach dem Einstellungsicon ist der nächste Fokus auf der ganzen Seite gesetzt mit dem Text "profile scrollview". Zu erwarten wäre stattdessen, dass der Fokus auf dem E-Mail-Feld liegt. Bei iOS ist dies so umgesetzt. - Android: Auch der nächste Fokus ist dann noch nicht das E-Mail-Feld, sondern ein kleinerer Teil der Seite mit dem Text "unbenannt". #### Ticketkonfiguration - Bei Android wird vor dem Fokus auf dem Bedienelement "Preisstufe" noch ein Fokus davor auf dem gleichen Element (nur etwas größer) gesetzt. Hier wird "productclass view" vorgelesen, der Nutzende kann dies jedoch nicht auswählen. #### eezy Einstieg - iOS: Zwischen den Bedienelementen - und + wird auch der Fokus auf der Trennlinie gesetzt. Diese wird dann als "Bindestrich" vorgelesen.

Verstoß

nicht vorgelesene Änderung einer Seite

Wird eine Seite durch ein Bedienelement oder ähnliches von Nutzenden geändert, so können diese Änderungen nicht gesehen werden, wenn dies nicht vorgelesen wird. ### Beispiele #### Ticketkonfiguration - Nach Auswahl der Preisstufe, werden die Informationen, die durch die Preisstufe geändert wurden, oben im grafischen Ticket angezeigt. Nutzende, die den Screenreader verwenden, bekommen diese optische Anpassung jedoch nicht mit. Es sollte darauf geachtet werden, dass solche Änderungen direkt genannt werden. #### eezy Einstieg - Werden Änderungen über + und - vorgenommen, wird nicht vorgelesen, bei welcher Summe nun die Zahl ist. Die Info müsste erfolgen ohne dass ein Zurücknavigieren notwendig ist. - Zusatzinfos wie beim Fahrrad werden angezeigt, ohne das der Nutzende davon in Kenntnis gesetzt wird.