Das Fokus-Management für Screenreader ist vor allem bei Web-Applikationen eine wichtige Aufgabe. Leider sieht man immer wiederkehrende Fehler, die in diesem Beitrag behandelt werden sollen. In diesem Beitrag gehe ich davon aus, dass tastatur- und Screenreader-Fokus dasselbe sind.
Den Fokus in Ruhe lassen
Bei klassischen Websites ohne viel Interaktivem Tamtam ist es sinnvoll, den Fokus nicht zu steuern. Ausnahmen sind die fast immer vorhandene Cookie-Message sowie ausgeblendete Inhalte wie Menüs.
In der Regel ist es sinnvoll, wenn der Tastatur-fokus dem visuellen Verlauf einer Website folgt, von links nach rechts und von oben nach unten, also zeilenweise. Aus meiner Sicht gibt es aber ein paar Ausnahmen.
Als Microsoft Windows noch das dominante Betriebssystem war, befand sich der Ok-Button immer links, während der Abbrechen-Button sich rechts befand. Das liegt vielleicht – zumindest im Westen – an der hier üblichen Blickrichtung von links nach rechts, auch unsere Texte verlaufen von links nach rechts.
Das hat sich spätestens geändert, als Apples mobiles Betriebssystem aufkam. Apple – und mittlerweile auch Android – platzieren den Ok-Button standardmäßig rechts und den Abbrechen-Button links. Vielleicht liegt es daran, dass die meisten Menschen das Smartphone links halten und man mit den Fingern der rechten Hand einen kürzeren Weg zum Bestätigen hat. Allerdings finden wir diese Positionierung mittlerweile auch in Web- und teils auch Desktop-Anwendungen.
Folgen wir der im ersten Absatz beschriebenen Anforderung, müsste der Tab zunächst auf dem linken Abbrechen-Button“ platziert werden, da er als Erstes sichtbar ist. Das ist problematisch, weil OK in der Regel die Aktion ist, die man auslösen möchte. Ich nenne es hier die Standard-Aktion. Es besteht die Gefahr, dass aus Versehen die falsche Aktion ausgelöst wird.
Natürlich wäre es sinnvoller, die Elemente von vorneherein so anzuordnen, wie man sie nutzen würde. Manche Design-Patterns ergeben gar keinen Sinn. Allerdings ist das bei einer bestehenden Anwendung kaum umsetzbar, da es ein tiefer Eingriff ins Design ist und man die Verantwortlichen selten überzeugen kann, das Pattern hat sich weitgehend durchgesetzt.
Ein schwieriger Fall ist es, wenn sich eine Standard-Aktion vor dem Eingabefeld befindet. Ein Beispiel dafür ist Twitter. Hier befindet sich der Senden-Button oberhalb des Eingabefeldes. Man kommtweder mit den Pfeil-tasten noch mit Tab auf das Element, wenn man sich aus dem Eingabefeld nach unten bewegt. Für sehende Tastatur-Nutzende ist das kein Problem, sie sehen ja, dass der Button oben ist. Komfortabel ist es dennoch nicht, da man aus dem Flow kommt: Erst vor-tabben, um in das Eingabefeld zu kommen, dann Zurück-Tabben, um den Text zu senden. Aus meiner Sicht wäre es in diesem Fall sinnvoller, den Tab nach dem Verlassen des Eingabefeldes auf dem Senden-Button oben zu positionieren. Das war früher so, da ich Twitter nicht mehr nutze, kenne ich den aktuellen Stand nicht.
Ein noch schwierigerer fall ist es, wenn sich die Elemente komplett vor dem Inhalt befinden, zum Beispiel bei Google Mail. Die Nutzenden müssen hier eine Mail markieren, um die Aktionen einzublenden und dann per Tab oder Pfeiltasten solange nach oben gehen, bis sie auf diese Aktionen kommen. In diesem fall wäre die Umleitung des Tastatur-Tabs nicht sinnvoll, da man dann komplett aus dem Flow geworfen wird. Hinweis: Da ich das blind getestet habe, weiß ich nicht, ob es für Sehende auch in der Liste der Mails Standard-Aktionen gibt, die der Screenreader nicht findet. Sinnvoll wäre hier der Hinweis an den Screenreader, dass und wo die Aktionen eingeblendet wurden und eine schnelle Möglichkeit, dorthin zu gelangen, zum Beispiel per Short Cut.
Fokus-Trap für eingeblendete Inhalte
Für eingeblendete Inhalte wird in aller Regel eine Fokus-Trap verwendet. Das heißt, der Fokus bleibt solange in dem eingeblendeten Bereich, solange dieser geöffnet ist. Beispiele sind die Cookie-Message oder eine ausklappende Navigation.
Die Gretchen-Frage ist, wo soll der Fokus hin, wenn die Einblendung geschlossen wird? Wenn die Meldung durch die Nutzende ausgelöst wird, wie bei der Navi, sollte der fokus zum auslösenden Element zurückkehren. Bei Cookie-Messages, die nicht durch die Nutzende ausgelöst wird, sollte der Fokus entweder an den Anfang der Seite oder dort hin, gesetzt werden, wo man sich befand, als die Einblendung geöffnet wurde. Vollblinde Menschen verlieren komplett die Orientierung, wenn der Fokus in solchen Fällen nicht gesteuert wird und irgendwo auf der Seite landet.
Häufige Fehler
Bei einigen Anwendungen sieht man, dass der Fokus auf eine Meldung gesetzt wird. Das ist nicht sinnvoll Ein aktuelles Beispiel ist der Rewe-Shop: Legt man ein Produkt in den Warenkorb, wird der Fokus auf einen Alert gesetzt, wo mitgeteilt wird, man habe den Mindestbestellwert nicht erreicht, sofern man diesen Wert noch nicht erreicht hat. Der Fokus wird zwar wieder auf das auslösende Element zurückgesetzt, aber das dauert ein paar Sekunden, währenddessen man seinen Bildschirm putzen kann. Es ist ein klassischer Fall vom falschen Einsatz eines Elements. Ein Alert braucht keinen Fokus, um vorgelesen zu werden. Eine Ausnahme wäre dann, wenn der Alert ein UI-element enthhielte.
Auch Tabindex zur Steuerung des Fokus sollte sparsam eingesetzt werden, oft wird damit mehr Schaden als Nutzen geschaffen. Ich habe schon die verrücktesten Fokus-Verläufe gesehen, weil jemand das aus irgendeinem Grund für sinnvoll hielt.
Dynamische Inhalte
Wenn sich Inhalte dynamisch ändern, muss der Fokus in der Regel nicht verschoben werden. Änderungen sollten allerdings immer hinter dem aktuellen Fokus des Screenreaders passieren, nicht oberhalb. Was oberhalb passiert, kriegt der Screenreader nicht mit und geänderte Inhalte können schwer auffindbar sein.
Ein Beispiel ist ein Formular, welches sich ändert, wenn man zum Beispiel oben eine Auswahl trifft.