Was wird geprüft?
Visuell dargestellte Hierarchien (Eltern-Kind Beziehungen) sollten grundsätzlich auch für den Screenreader-Nutzer erfahrbar sein. Der Einsatz programmatisch ermittelbarer Hierarchien ist allerdings bei iOS- und Android-Apps recht beschränkt.
Die am häufigsten anzutreffende programmatisch ausgegebene Hierarchie, sowohl bei Android als auch iOS, ist die von Tab-Leisten (Tabs für die Navigation zu App-Bereichen) bzw. Werkzeugleisten (Toolbars) zum Aufruf von Funktionen, sowie von Reiter-Widgets (Tab Panels).
Wenn Einträge in Navigations-Menüs bei Aktivierung Untermenüs in einem akkordion-artigen Einblendbereich oder einer weiteren Ansicht aufrufen, kann diese Hierarchie über den Ausklapp-Zustand der Menüeinträge vermittelt werden: so wird etwa bei erweiterbaren Menüeinträgen der iOS-Pages-App "reduziert" ausgegeben. Ein anderes Beispiel ist das Menü der Guardian-App (unter iOS). Dieses Pattern ist jedoch selbst bei iOS- und Android System-Apps selten genutzt: meist erfolgt lediglich die Ausgabe "Schalter", das Untermenü ersetzt das Hauptmenü, ein Zurück-Schalter führt zum Hauptmenü zurück. Die Vermittlung der Eltern-Kind Hierarchie lässt sich deshalb schwerlich generell bei Navigationsmenüs von Apps einfordern. Zuweilen erfolgt bei Android-Navigationsmenüs die Ausgabe der Anzahl von Einträgen im sichtbaren Bereich (d.h. nicht die tatsächliche Anzahl) - und dies nicht mehr bei wiederholtem Ansteuern der Liste.
Andere visuell listenartige oder kachelartige Strukturen treten in nativen Apps meist als Ansammlungen von Tasten bzw. Schaltern auf und vermitteln programmatisch weder die visuell erfahrbare Eltern-Kind Beziehung noch die Anzahl von Kindelementen oder deren Position in der Gruppe. Elemente mit Rollen wie "Popup-Fenster" (Android), "Liste" (Android) oder "Auswahl" (iOS) nennen bei Aufruf die Eltern-Rolle, jedoch meist nicht die Anzahl fokussierter Kind-Elemente. Unter iOS lassen sich gelegentlich hierarchische Indices über die Rotor-Option "Wert anpassen" mittels vertikaler Wischgesten navigieren - so etwa etwa der Abschnittsindex in der iOS-App Kontakte.
Sonderfall Webviews
Viele Informations-Apps binden in großem Umfang Webviews ein. In den mobilen Screenreadern entspricht die Ausgabe von Eltern Kind-Elementen hier meist der Ausgabe bei Websites in Browsern. Visuelle Listen, die nicht mit Listen-Markup umgesetzt sind, sind dann in Prüfschritt 11.1.3.1b zu bewerten. Die Ausgabe zu hierarchischen Elementen wie Listen uneinheitlich. Oft wird nicht die Anzahl von Listenelementen ausgegeben, manchmal jedoch "Anfang der Liste" (iOS) oder "In der Liste" (Android). Bei iOS gibt über die Rotor-Einstellungen die Möglichkeit zum Navigieren zwischen mehreren Listen. Unter Android kommt es häufig zur Ausgabe der Anzahl von Einträgen in Listen. Die Ausgabe stimmt aber nicht immer mit der tatsächlichen Anzahl überein, sondern bezieht sich unter Umständen auf die jeweils im Viewport sichtbaren Elemente. Eine Navigationsmöglichkeit zwischen den Eltern-Listen über Kurzbefehl besteht bei Android nicht.
Warum wird das geprüft?
Wenn hierarchische Interface-Strukturen und damit Eltern-Kind Beziehungen programmatisch ermittelbar sind, haben nicht-visuelle Nutzende einen besseren Überblick über das Interface und seine Strukturen.
Wie wird geprüft?
1. Anwendbarkeit des Prüfschritts
Da die programmatische Ermittelbarkeit von Eltern-Kind Beziehungen in Apps generell eingeschränkt ist und über die Auszeichung von Tablisten hinaus kaum anzutreffen ist, wird das Fehlen programmatisch ermittelbarer Hierarchien bei Listenansichten oder Navigationsmenüs zurzeit nicht negativ bewertet.
Der Prüfschritt wird also nur auf Tableisten und Toolbars (meist im Fußbereich der App) sowie auf Reiter-Widgets angewandt. Hier sollte der Screenreader bei Fokussierung des Kind-Tabs die Position des Tabs und die Anzahl der Tabs im Eltern-Element ausgeben.
2. Prüfung
Mittels Screenreader prüfen, ob bei Tableisten, Toolbars und Reiter-Widgets die Position des Tab-Elements sowie die Gesamt-Anzahl von Tabs vermitteln (z.B. "Suchen, Tab, 5 von 5", oder "Ausgewählt, Aktuelle Tickets, Tab 1 von 2").
3. Hinweise
Nicht negativ zu bewerten ist, wenn das Eltern-Element selbst nicht benannt ist bzw. bei der Fokussierung eines Kind-Elements nicht der Name oder Rolle des Eltern-Elements ausgegeben wird. Für Eltern-Elemente (List views, Table views, Collections) ist eine solche Ausgabe nicht generell sinnvoll oder ggf. sogar störend. Der Screenreader VoiceOver im MacOs/Safari Browser und unter iOS/Safari unterdrückt die Listensemantik, wenn die Liste nicht über Listenpunkte oder Nummerierung auch visuell als Liste gestaltet ist. Einiges spricht dafür, dass die Gestalung hier die semantische Ausgabe beeinflusst, einiges spricht dagegen (vergl. den Artikel "Fixing" Lists in den Quellen). Dafür spricht, dass eine möglicherweise lästige und nicht nützliche Screenreader-Ausgabe unterbleibt. In anderen Fällen (und für andere Nutzende) kann es relevant sein, die Anzahl der Listenelemente zu mitgeteilt zu bekommen. Das Fehlen von Listenauszeichung auf Elementen, die nicht visuell als Liste ausgezeichnet sind, sollte in diesem Püfschritt nicht negativ bewertet werden.
Android-Prüfung: In den TalkBack-Einstellungen sollte unter "Ausführlichkeit" die Optionen "Listen- und Rasterinformationen vorlesen" aktiviert sein.
4. Bewertung
Eher erfüllt:
Elemente in Listen, Tableisten, Toolbars oder Reiter-Wigets vermitteln nicht ihre Position innerhalb des Eltern-Elements und die Anzahl der Kind-Elemente in der Leiste (die Verfügbarkeit von Name, Rolle und Wert gehört zu Prüfschritt 11.4.1.2 und wird dort bewertet).
Nicht erfüllt:
Schalter in Tableisten vermitteln unrichtige Informationen zu Eltern-Kind Beziehungen - z.B. "Suchen, Tab, 1 von 1", obwohl mehrere Tabs in der Tableiste vorhanden sind. (Fehlende Namen, Rollen und Werte sind ansonsten bei 11.4.1.2 zu bewerten.)
Quellen
"Fixing" Lists (Blog-Artikel von Scott o’Hara, aktualisiert am 30.01.2023)
Einordnung des Prüfschritts
Einordnung des Prüfschritts nach EN 301 549 V.3.2.1
11.5.2.9 Parent-child relationships
Where the software provides a user interface it shall, by using the services as described in clause 11.5.2.3, make the relationship between a user interface element and any parent or children elements programmatically determinable by assistive technologies.