Fokus-Management bei Single-Page-Interaktionen: Dialoge, Routenwechsel und entfernte Elemente

Ziel

Den Tastaturfokus bei jeder Seitenänderung ohne vollständigen Ladevorgang an einer sinnvollen Stelle halten: beim Öffnen und Schliessen von Dialogen, bei clientseitiger Navigation, beim Löschen des fokussierten Elements und beim Ersetzen einer Ansicht nach einer Aktion. Ein vollständiger Seitenladevorgang setzt den Fokus für alle zurück; ein Single-Page-Übergang muss diese Arbeit selbst übernehmen.

Voraussetzungen

Wo möglich natives <dialog>; ein Router, der einen Hook nach dem Rendern der neuen Ansicht bereitstellt; und die Technik tabindex="-1", die laut MDN ein Element per Skript fokussierbar macht, ohne es in die Tab-Reihenfolge aufzunehmen.

Schritte

1. Dialoge: mit showModal() öffnen. MDN besagt, dass ein modaler Dialog den Rest der Seite inert macht und sich mit der Esc-Taste schliessen lässt, sodass eine selbst geschriebene Fokusfalle unnötig ist. Vor dem Öffnen eine Referenz auf das auslösende Element speichern.
2. Beim Öffnen den Fokus in den Dialog verschieben. Das APG-Dialogmuster besagt, dass der Fokus zu einem im Dialog enthaltenen Element wandert, meist zum ersten fokussierbaren Element; bei einem Dialog, der mit langem Text beginnt, der Überschrift tabindex="-1" geben und diese fokussieren, damit die Person erst liest, bevor sie handelt.
3. Beim Schliessen den Fokus zum gespeicherten Auslöser zurückführen. Das APG-Muster nennt die Ausnahme: Existiert der Auslöser nicht mehr, geht der Fokus zu einem anderen Element, das den Arbeitsablauf fortsetzt.
4. Routenwechsel: Nach dem Rendern der neuen Ansicht document.title setzen und den Fokus zur Hauptüberschrift der Ansicht (tabindex="-1") oder zum Landmark main verschieben. Wurde der zuvor fokussierte Knoten beim Rendern ersetzt, ist der Fokus bereits auf body zurückgefallen.
5. Entfernte Elemente: Entfernt ein „Löschen“-Steuerelement die Zeile, in der es sich befindet, im Voraus festlegen, wohin der Fokus geht: dasselbe Steuerelement in der nächsten Zeile, die vorherige Zeile oder die Listenüberschrift mit einer Statusmeldung.
6. Eingeblendete Inhalte: Bei Disclosures und Akkordeons den Fokus auf dem Auslöser belassen; bei schrittweisen Abläufen, die die gesamte Ansicht ersetzen, den neuen Schritt wie einen Routenwechsel behandeln.
7. Den Fokusring sichtbar halten: outline nie ohne Äquivalent entfernen; :focus-visible gestalten, damit Tastaturnutzende sehen, wo sie sich befinden.
8. Jeden Ablauf zunächst nur mit der Tastatur testen, dann mit einem Screenreader, und notieren, was nach jedem Übergang angesagt wird.

Erwartetes Ergebnis

Nach jeder Interaktion landet Tab auf dem nächsten sinnvollen Steuerelement; ein Screenreader sagt den neuen Kontext an (Dialogtitel, Überschrift der Ansicht, Statuszeile) statt „Dokument“.

Grenzen und Prüfbasis

Die Empfehlungen folgen dem zitierten APG-Muster und der MDN-Dokumentation; es wird keine Nutzerstudie behauptet. Eigene Dialoge aus div-Elementen brauchen eine eigene inert- und Esc-Behandlung, die <dialog> bereits mitbringt. Wohin der Fokus nach einem Routenwechsel genau gehen soll, ist umstritten (Überschrift versus Landmark versus nur Ansage); eine Konvention wählen und konsequent anwenden.