Tastatur, Fokus und Navigation

Tastatur, Fokus und Navigation

0:00 In Modul acht haben wir gelernt: Die Tastatur ist der gemeinsame Nenner fast aller assistiven Techniken. Jetzt wird daraus eine Umsetzungsanweisung. Und der Leitsatz ist bewusst zugespitzt — die Zeile, die den Fokusrahmen entfernt, ohne Ersatz zu liefern, ist die folgenreichste einzelne Stilanweisung in diesem ganzen Feld.

0:18 Sie steht in unzähligen Projekten, sie wurde immer aus ästhetischen Gründen geschrieben, und sie macht die Tastaturbedienung unsichtbar. Die gute Nachricht dieses Moduls: Fast alles hier ist mit wenigen Zeilen zu lösen. Es wird nur regelmäßig übersehen, weil wir mit der Maus entwickeln.

Tastatur, Fokus und Navigation

0:35 Neun Kapitel, die den Weg des Fokus durch eine Anwendung verfolgen. Erst die Reihenfolge, dann die Sichtbarkeit, dann Sprunglinks. Danach wird es anspruchsvoller: Fokusverwaltung in Anwendungen ohne Seitenneuladen, Dialoge und Overlays, die Tastaturmuster komplexer Komponenten. Zum Schluss zwei Kapitel über das, was schiefgeht — Fokusfallen und verlorene Zustände beim Zurücknavigieren.

0:59 Und dann reparieren Sie selbst vier eingebaute Fehler, allein mit der Tastatur. Nehmen Sie sich vor: In diesem Modul rühren wir das Layout nie an.

Logische Fokusreihenfolge

1:09 Beginnen wir bei der Reihenfolge. Sie ist die Grundlage von allem — und sie steht an einer Stelle, die viele nicht erwarten: im Markup, nicht im Layout. Die Fokusreihenfolge folgt der Reihenfolge im Dokument, und die sollte der Leserichtung entsprechen. Klingt selbstverständlich und ist es in der Praxis nicht, weil moderne Layoutverfahren die sichtbare Anordnung frei verschieben können.

1:32 Weicht das Layout ab, springt der Fokus scheinbar willkürlich über den Bildschirm — für sehende Tastaturnutzende besonders unangenehm. Und jetzt zur beliebtesten falschen Reparatur: positive Fokusindizes. Sie verschlimmern das Problem regelmäßig, denn sie reißen einzelne Elemente aus der natürlichen Ordnung heraus und lassen alle anderen nachrücken.

1:51 Die richtige Lösung ist immer dieselbe: die Reihenfolge im Markup korrigieren. Drei Werte, und man sollte sie sauber auseinanderhalten. Ein positiver Wert verschiebt das Element in eine eigene, vorgezogene Reihenfolge — das ist der Fall, den Sie in aller Regel vermeiden wollen. Der Wert null nimmt ein Element in den normalen Tablauf auf; das brauchen Sie, wenn Sie tatsächlich einmal etwas fokussierbar machen müssen, das es von Haus aus nicht ist.

2:17 Und minus eins ist der praktisch wichtigste Wert und der am wenigsten bekannte: Das Element ist per Skript fokussierbar, aber nicht im Tablauf. Das ist der Normalfall für Sprungziele — genau das brauchen wir gleich beim Sprunglink und bei der Routennavigation. Der erste Stolperstein ist der eben besprochene: positive Fokusindizes vergeben.

2:36 Sie stören die Reihenfolge nicht lokal, sondern global — und beim nächsten neuen Bedienelement stimmt sie wieder nicht. Der zweite kennen Sie aus Modul neun: die visuelle Reihenfolge mit einer Anordnungsregel ändern und das Markup so lassen. Und der dritte ist eine ganz alltägliche Nachlässigkeit: neue Elemente ans Ende des Markups hängen, weil es dort einfacher war, und sie per Stil an die richtige Stelle schieben.

3:00 Das passiert unter Zeitdruck, es fällt visuell nicht auf, und es kostet den Tastaturnutzer einen Sprung quer über die Seite.

Sichtbare Fokusindikatoren

3:07 Jetzt zum Leitsatz dieses Moduls. Der Fokus muss erkennbar sein — das ist alt. Neu seit Version 2.2 ist, dass er auch nicht verdeckt werden darf. Und das trifft ein sehr verbreitetes Gestaltungsmuster. Der Fokus ist für Tastaturnutzende das, was der Mauszeiger für alle anderen ist: die Auskunft, wo man gerade ist. Er muss jederzeit erkennbar sein, mit ausreichendem Kontrast zum Hintergrund und zum Ruhezustand des Elements.

3:35 Seit Version 2.2 kommt eine zweite Anforderung dazu, und die ist neu für viele Projekte: Der Indikator darf nicht von anderen Elementen verdeckt werden. Der häufigste Fall ist die klebende Kopfzeile. Sie tabben nach unten, dann wieder nach oben, das Element scrollt an den oberen Rand — und verschwindet unter der Leiste.

3:54 Der Fokus ist da, sichtbar ist er nicht. Oben die berüchtigte Zeile, die den Indikator entfernt — meist mit dem Vorsatz, „später etwas Schöneres" zu bauen. Später kommt selten. Unten die richtige Lösung, und sie hat drei Bestandteile. Erstens die Auswahl auf den Fall, in dem der Fokus tatsächlich per Tastatur gesetzt wurde — damit stört der Rahmen bei Mausklicks nicht, was ja der ursprüngliche Anlass war.

4:20 Zweitens ein Abstand, der den Rahmen vom Element abhebt. Und drittens ein Bildlaufabstand nach oben, der das fokussierte Element unter einer klebenden Kopfzeile freihält. Drei Zeilen, und das neue Kriterium aus Version 2.2 ist erfüllt. Der erste Stolperstein ist der Leitsatz: den Rahmen entfernen und den Ersatz auf später verschieben. Wenn Sie ihn entfernen, ersetzen Sie ihn im selben Commit — sonst nie.

4:44 Der zweite ist eine feine Unterscheidung mit praktischer Wirkung: nur die Maus im Blick haben und die beiden Fokus-Zustände verwechseln. Der eine greift immer, der andere nur bei Tastaturbedienung — und genau der löst den alten Zielkonflikt zwischen Gestaltung und Bedienbarkeit. Und der dritte ist der neue Fall: eine klebende Kopfzeile einführen, ohne den Fokus dagegen zu prüfen. Tabben Sie einmal durch Ihre Seite und beobachten Sie den oberen Rand.

Skip Links und Landmark-Navigation

5:11 Ein kleines Element mit großer Wirkung: der Sprunglink zum Hauptinhalt. Er spart auf jeder Seite dutzende Tastendrücke — wenn er richtig gebaut ist. Und genau daran hapert es überraschend oft. Stellen Sie sich vor, Sie müssten bei jedem Seitenaufruf erst durch die komplette Navigation tabben, bevor Sie zum Inhalt kommen. Fünfundzwanzig Tastendrücke, auf jeder Seite.

5:34 Genau das erspart ein Sprunglink. Er darf unsichtbar sein, solange er nicht fokussiert ist — beim Fokussieren muss er sichtbar werden. Und die entscheidende Bedingung: Er muss den Fokus tatsächlich verschieben, nicht nur die Ansicht scrollen. Das ist der häufigste stille Fehler, und er ist von außen nicht zu sehen. Für Screenreader-Nutzende leisten übrigens gut gesetzte Landmarks dasselbe — deshalb war Kapitel eins von Modul neun so wichtig.

6:00 Der Unterschied zwischen diesen beiden Fassungen ist ein Attribut, und er entscheidet über die Funktion. Oben springt die Ansicht zum Hauptinhalt — visuell perfekt. Der Fokus bleibt aber im Kopfbereich stehen, weil der Hauptbereich gar nicht fokussierbar ist. Der nächste Tastendruck bringt Sie also wieder in die Navigation, die Sie gerade überspringen wollten.

6:21 Unten steht der Fokusindex minus eins auf dem Sprungziel, und damit kann der Fokus dorthin gesetzt werden. Das ist genau der Wert aus Kapitel eins. Ein Attribut Unterschied — und der Sprunglink erfüllt seinen Zweck statt ihn nur vorzutäuschen. Der erste Stolperstein ist ein gut gemeintes Verstecken: den Sprunglink dauerhaft unsichtbar machen, sodass er nie fokussierbar wird.

6:43 Wer ihn mit einer Anzeigeregel komplett entfernt, hat ihn auch für die Tastatur entfernt. Es gibt etablierte Techniken, um ihn nur optisch zu verbergen und beim Fokus einzublenden. Der zweite ist der eben gezeigte: das Sprungziel ohne den Fokusindex setzen. Und der dritte ist gut gemeinter Übereifer: mehrere Sprunglinks anbieten.

7:03 Der erste Tabstopp jeder Seite ist wertvoll — überfrachten Sie ihn nicht mit fünf Sprungzielen. Einer zum Inhalt reicht in aller Regel, gelegentlich ein zweiter zur Suche.

Fokusmanagement in Single-Page Applications

7:13 Jetzt ein Kapitel, das erklärt, warum viele moderne Anwendungen mit Screenreader kaputt wirken, obwohl sie technisch einwandfrei funktionieren. Es geht um den Seitenwechsel ohne Neuladen. Beim klassischen Seitenaufruf passiert für assistive Technik viel: Der Browser lädt ein neues Dokument, meldet den neuen Titel, setzt den Fokus an den Anfang.

7:34 All das entfällt, wenn eine Anwendung die Ansicht nur austauscht. Für das Auge ändert sich alles, für die assistive Technik ändert sich nichts. Der Fokus bleibt, wo er war — womöglich auf einer Schaltfläche, die es gar nicht mehr gibt —, und die neue Seite wird nicht angesagt. Die Abhilfe ist überschaubar: nach der Navigation den Fokus gezielt auf die neue Überschrift setzen und den Titelwechsel melden.

7:57 Fünf Schritte, und die ersten vier sind schnell erledigt. Den Dokumenttitel aktualisieren — nicht nur die Anzeige im Tab, sondern die Eigenschaft im Dokument. Den Fokus auf die neue Hauptüberschrift setzen, wieder mit dem Fokusindex minus eins. Die Bildlaufposition zurücksetzen. Bei langen Ladezeiten den Zwischenstand als Statusmeldung ausgeben — dazu kommt Modul elf mit den Live Regions.

8:21 Und dann Schritt fünf, der fast immer vergessen wird: prüfen, ob der Zurück-Knopf des Browsers dieselbe Behandlung auslöst. Die Zurücknavigation ist auch ein Routenwechsel. In vielen Anwendungen ist sie der einzige, der nicht behandelt wird. Der erste Stolperstein ist eine Halbheit: den Fokus auf den Seitencontainer setzen statt auf die Überschrift.

8:43 Dann wird nichts Sinnvolles angesagt, weil ein Container keinen Namen hat. Die Überschrift dagegen nennt genau das, wo man gelandet ist. Der zweite ist eine technische Feinheit: den Titelwechsel nur im Tab anzeigen und nicht im Dokument setzen. Screenreader lesen den Dokumenttitel, nicht die Browserleiste. Und der dritte ist der eben genannte: die Fokusbehandlung nur beim Vorwärtsnavigieren auslösen. Menschen navigieren viel zurück — bei Buchungsstrecken sogar besonders oft.

Modaldialoge, Overlays und Off-Canvas-Navigation

9:13 Jetzt zu den Dialogen. Sie haben drei Pflichten, die sich gut merken lassen — Fokus hinein, Fokus halten, Fokus zurück. Und es gibt ein Element, das den größten Teil davon geschenkt mitbringt. Merken Sie sich den Dreiklang: Fokus hinein, Fokus gefangen halten, Fokus zurück zum auslösenden Element. Dazu kommen zwei Dinge — Schließen mit Escape und ein Hintergrund, der nicht mehr bedienbar ist. Das ist einiges an Verhalten, und Eigenbauten liefern es fast nie vollständig.

9:42 Die gute Nachricht: Das native Dialog-Element bringt einen großen Teil davon mit, wenn Sie es als modalen Dialog öffnen. Das ist die direkte Fortsetzung von Modul neun — nativ statt Eigenbau, und Sie bekommen das komplizierte Verhalten geschenkt und dauerhaft gewartet. Es gibt kaum einen Fall, in dem sich der Eigenbau hier noch lohnt.

10:02 Oben ein Overlay mit Dialog-Rolle. Die Rolle ist gesetzt, das sieht sorgfältig aus — und es ist genau der Fehler aus Modul neun: Das Etikett ist da, der Motor fehlt. Kein Fokus hinein, keine Falle, kein Escape, kein inerter Hintergrund. Unten das native Element mit einer Beschriftung über die Überschrift und einem Element, das beim Öffnen den Fokus bekommt.

10:24 Die Fußzeile listet, was Sie damit geschenkt bekommen: Fokus setzen, Fokus fangen, Hintergrund inert machen, mit Escape schließen. Vier komplexe Verhaltensweisen, die Sie sonst selbst bauen und pflegen müssten — und die sich beim Eigenbau erfahrungsgemäß über die Jahre verschlechtern. Der erste Stolperstein ist der gerade gezeigte: die Dialog-Rolle setzen und das Fokusverhalten für erledigt halten. Eine Rolle beschreibt, sie bewirkt nichts.

10:50 Der zweite ist der ärgerlichste im Alltag: den Fokus beim Schließen nicht zurückgeben. Die Person landet dann am Seitenanfang und muss sich von vorn durcharbeiten bis zu der Stelle, an der sie den Dialog geöffnet hat. Bei einem Buchungsformular ist das eine echte Zumutung. Und der dritte ist ein halb gelöster Fall: den Hintergrund nur optisch abdunkeln und ihn bedienbar lassen.

11:12 Der Fokus wandert dann aus dem Dialog heraus in eine abgedunkelte Seite — sichtbar für niemanden.

Tastaturmuster komplexer Komponenten

11:18 Damit zu den zusammengesetzten Komponenten. Für sie gibt es etablierte Tastenmuster — und die sind dokumentiert. Sie neu zu erfinden ist keine Innovation, sondern eine Hürde. Auch hier gilt, was wir in Modul vier über Konventionen gesagt haben: Nutzende bringen ihre Erwartung aus anderen Anwendungen mit. Und für zusammengesetzte Widgets haben sich klare Muster etabliert.

11:42 Pfeiltasten bewegen innerhalb der Gruppe, der Tabulator führt hinein und wieder heraus, Pos1 und Ende springen an die Ränder. Diese Muster sind ausführlich dokumentiert — Sie müssen sich nichts ausdenken, nur nachschlagen. Der Gewinn ist doppelt: Ihre Komponente verhält sich wie erwartet, und Sie sparen sich die Erfindungsarbeit.

12:01 Ein eigenes Tastenschema, das Ihnen logischer erscheint, ist für alle anderen erst einmal falsch. Achten Sie auf die Spalte „hinein und heraus", denn dort steckt das Prinzip. Bei Tabs gibt es genau einen Tabstopp für die ganze Gruppe — innerhalb wird mit Pfeiltasten gewechselt. Das ist wichtig: Zwanzig Tabs sollen nicht zwanzig Tabstopps sein, sonst wird die Tastaturbedienung mühsam.

12:24 Beim Menü schließt Escape, im Grid bewegen sich die Pfeiltasten in vier Richtungen und der Tabulator verlässt das Grid, und bei der Combobox schließt Escape und die Eingabetaste wählt aus. Das gemeinsame Prinzip: Der Tabulator wechselt zwischen Komponenten, die Pfeiltasten navigieren innerhalb. Das ist die Faustregel für alle zusammengesetzten Widgets.

12:45 Der erste Stolperstein ist der gerade angesprochene: jedem Element im Widget einen eigenen Tabstopp geben. Das ist die naive Umsetzung, und sie macht eine Datentabelle mit hundert Zellen praktisch unbedienbar. Der zweite ist eine Lücke, die sehr oft besteht: Escape nur im Dialog behandeln und in Menü und Combobox vergessen.

13:04 Escape ist die universelle Fluchttaste; Menschen probieren sie überall. Und der dritte ist der Erfindungsreflex: ein eigenes Tastenschema, weil es logischer erscheint. Es mag logischer sein — es ist trotzdem unbekannt. Und unbekannt schlägt logisch, jedes Mal.

Fokusfallen und unerwartete Kontextwechsel

13:21 Zwei Fehlerbilder mit demselben Ergebnis: Der Nutzer verliert die Kontrolle. Einmal wird er eingesperrt, einmal überrumpelt. Und interessanterweise ist eine Fokusfalle nicht immer falsch. Beginnen wir mit der Unterscheidung, die hier wichtig ist. Im Dialog ist die Fokusfalle gewollt und richtig — der Fokus soll drinbleiben, solange der Dialog offen ist.

13:43 Die ungewollte Fokusfalle dagegen sperrt Menschen ein, häufig bei eingebetteten Widgets oder halb geschlossenen Overlays. Man tabbt und tabbt und kommt nicht heraus; ohne Maus bleibt nur das Neuladen der Seite. Das Gegenstück ist der unerwartete Kontextwechsel: ein Formular, das beim Auswählen einer Option sofort abschickt.

14:02 Sie wollten nur die Liste durchsehen und stehen plötzlich auf der nächsten Seite. Beides nimmt die Kontrolle — einmal durch Sperren, einmal durch Vorpreschen. Die rechte Spalte beschreibt, was Menschen tatsächlich erleben — und das ist jedes Mal Kontrollverlust. Bei der Fokusfalle kein Weiterkommen ohne Maus. Beim Kontextwechsel läuft der Vorgang ungewollt weiter. Und die dritte Zeile ist die subtilste: Fokus verloren, weil ein Element entfernt wurde, während es den Fokus hatte.

14:31 Der Fokus springt dann an den Seitenanfang, ohne dass irgendetwas gemeldet wird. Das passiert bei jedem Löschen aus einer Liste, bei jedem Schließen eines Hinweises. Merken Sie sich die Regel dazu: Wer ein fokussiertes Element entfernt, muss vorher entscheiden, wohin der Fokus wandert — meist auf den Nachbarn oder auf den Container.

14:51 Der erste Stolperstein ist der eben besprochene und im Alltag häufigste: ein Element entfernen, während es den Fokus hat, ohne den Fokus zu setzen. Das passiert bei jeder Löschfunktion. Der zweite ist ein Muster, das ausdrücklich gegen die Richtlinien verstößt: Auswahländerungen automatisch absenden lassen. Mit der Maus fällt das kaum auf, mit der Tastatur ist es fatal — man durchläuft die Optionen mit den Pfeiltasten, und jede einzelne löst eine Aktion aus.

15:17 Und der dritte ist ein Aufräumfehler: die gewollte Fokusfalle im Dialog nach dem Schließen nicht aufheben. Dann ist der Dialog weg und die Falle bleibt.

Zurücknavigation und Wiederherstellung des Zustands

15:27 Das letzte inhaltliche Kapitel schließt an Modul vier an. Nach dem Zurückspringen soll alles dort stehen, wo es war. Das ist echte Arbeit — und sie entscheidet darüber, ob mehrstufige Abläufe zu Ende gebracht werden. Stellen Sie sich vor, Sie gehen aus der Sitzplatzauswahl zurück zur Ergebnisliste. Was erwarten Sie? Dieselben Filter, dieselbe Bildlaufposition, den Fokus dort, wo Sie ihn verlassen haben.

15:52 Was Sie meistens bekommen, ist eine frisch geladene Liste ganz von oben, mit zurückgesetzten Filtern. Für Mausnutzende ist das ärgerlich; für jemanden, der sich mit der Tastatur bis zur zwölften Verbindung durchgearbeitet hat, ist es der Abbruch. Diese Wiederherstellung ist Aufwand, das will ich nicht kleinreden. Aber sie entscheidet darüber, ob Menschen einen mehrstufigen Ablauf zu Ende bringen — und damit unmittelbar über Ihre Abschlussquote.

16:19 Vier Dinge. Die gesetzten Filter und die Bildlaufposition — das ist der bekannte Teil, den viele immerhin lösen. Der Fokus auf dem Element, von dem aus weitergegangen wurde — das ist der Teil, der praktisch immer fehlt und für Tastaturnutzende der wichtigste ist. Bereits eingegebene Daten im Formular, unverändert; das kennen Sie alle aus eigener leidvoller Erfahrung.

16:40 Und viertens die Angabe, an welcher Stelle des Ablaufs man sich befindet — Schritt zwei von vier. Diese vier zusammen ergeben das, was man Zustandserhalt nennt, und sie sind der Unterschied zwischen einer Anwendung, die man verlassen kann, und einer, die man nur einmal durchläuft. Der erste Stolperstein ist der technische Kern: den Zustand nur im Arbeitsspeicher halten. Ein Zurück, ein Tabwechsel, ein Neuladen — und alles ist weg.

17:05 Legen Sie den Zustand in die Adresszeile oder in einen dauerhaften Speicher. Der zweite ist eine halbe Lösung, die trotzdem gut ist und ergänzt werden sollte: Filter in der Adresszeile führen, den Fokus aber nicht wiederherstellen. Und der dritte ist eine Nebenwirkung vieler Frameworks: beim Zurück die Liste neu laden und an den Anfang springen.

17:25 Technisch sauber, praktisch der Verlust der ganzen bisherigen Arbeit.

Übung — Fokus in einem mehrstufigen Ablauf reparieren

17:30 Zum Abschluss reparieren Sie vier eingebaute Fehler — allein mit der Tastatur, ohne das Layout anzufassen. Der vierte wird selten gefunden. Ich verrate ihn noch nicht. Sie beheben vier Fokusfehler im Buchungsassistenten. Geübt wird das Erkennen allein mit der Tastatur, das Benennen des Fehlerbilds und das Beheben ohne Eingriff ins Layout.

17:51 Erfolgreich sind Sie, wenn alle vier gefunden, benannt und behoben sind — und der Nachweis über die Fokusreihenfolge geführt wird, nicht über das Aussehen. Ein Hinweis aus der Erfahrung: Der vierte Fehler wird selten gefunden, weil er nichts Sichtbares anrichtet. Beim Schließen des Dialogs geht der Fokus still verloren und landet am Seitenanfang.

18:11 Wer früh fertig ist, baut selbst einen fünften Fehler ein und lässt ihn von einer anderen Gruppe suchen. Fünf Schritte, und Schritt zwei ist der methodisch wichtigste: alles notieren, bevor irgendetwas geändert wird. Wer sofort repariert, verliert den Überblick über die restlichen Befunde — und findet den vierten dann gar nicht mehr.

18:31 Benennen Sie je Befund das Fehlerbild aus dem Kapitel: Reihenfolge, Falle, Verlust oder Wechsel. Reparieren Sie ohne Layoutänderung und ohne positive Fokusindizes — beides ist ausdrücklich ausgeschlossen. Und dann gehen Sie noch einmal durch und protokollieren die Reihenfolge gegen Ihre Erwartung. Die Fußzeile fasst die Nebenbedingung zusammen: Wer das Layout verschiebt, hat die Ursache nicht gefunden, sondern das Symptom übermalt.

18:56 Der erste Stolperstein ist der Reparaturreflex: mit dem Beheben beginnen, bevor alle vier Befunde notiert sind. Nach der ersten Änderung verändert sich das Verhalten, und die restlichen Fehler sind schwerer zu isolieren. Der zweite ist die verbotene Abkürzung: mit positiven Fokusindizes arbeiten. Sie lösen den einen Fall und stören die Reihenfolge global — das ist der Klassiker aus Kapitel eins.

19:20 Und der dritte ist ein Beweisfehler: den Nachweis am Aussehen führen statt an der Fokusreihenfolge. Das Aussehen war nie das Problem. Der Nachweis ist ein Protokoll der Tabstopps, kein Screenshot. Vier Punkte. Die Fokusreihenfolge korrigiert man im Markup, nie mit positiven Fokusindizes — die verschieben das Problem. Der Indikator muss sichtbar sein und darf seit Version 2.2 nicht verdeckt werden; denken Sie an die klebende Kopfzeile.

19:48 Ein Dialog schuldet dreierlei: Fokus hinein, halten, zurückgeben. Und ein Routenwechsel ohne Neuladen ist für assistive Technik unsichtbar, wenn Sie ihn nicht ausdrücklich melden. Der praktischste Rat zum Schluss steht in der Fußzeile: Das native Dialog-Element erledigt Fokus, Escape und Inertheit für Sie. Im nächsten Modul geht es an die Formulare — dort laufen alle Fäden dieses Tages zusammen.