Modal offen, Fokus weg: So prüfen Sie Dialoge wirklich mit der Tastatur

Ein Modal öffnet sich. Visuell ist alles eindeutig: Der Hintergrund wird dunkel, in der Mitte erscheint ein Formular und oben rechts sitzt ein X.

Dann drückt jemand Tab.

Der Fokus springt hinter das Modal. Oder bleibt unsichtbar. Oder landet sofort auf „Löschen“, obwohl es sich um eine irreversible Aktion handelt. Nach dem Schließen ist der Nutzer plötzlich ganz oben auf der Seite. Mit der Maus sieht das Interface weiterhin vollkommen ordentlich aus.

Ein Modal ist nicht deshalb zugänglich, weil es wie ein Modal aussieht. Es muss sich auch wie eines verhalten.

Genau das macht Dialoge zu einem erstaunlich guten Qualitätscheck für Frontends. In einem kleinen UI-Baustein treffen Semantik, Fokusmanagement, Tastaturbedienung, Scrollverhalten, Overlays, Portals und Zustandslogik aufeinander.

Was ein modaler Dialog technisch verspricht

Der W3C ARIA Authoring Practices Guide beschreibt ein modales Dialogfenster als eine Oberfläche, bei der der Inhalt darunter inert ist: Solange der Dialog aktiv ist, kann außerhalb davon nicht interagiert werden. Gleichzeitig bleibt die Tab-Reihenfolge innerhalb des Dialogs. Tab und Shift+Tab sollen den Fokus also nicht in die Seite dahinter tragen.

Dazu gehören mehrere Erwartungen gleichzeitig:

• beim Öffnen wandert der Fokus sinnvoll in den Dialog,
• Tastaturnavigation bleibt innerhalb des aktiven Dialogs,
• Escape kann den Dialog schließen,
• es gibt eine sichtbare Schließen- oder Abbrechen-Aktion,
• der Hintergrund ist tatsächlich nicht bedienbar,
• nach dem Schließen kehrt der Fokus an einen logischen Ort zurück,
• Screenreader erhalten einen verständlichen Namen und Kontext für den Dialog.

Ein halb umgesetztes Modal ist deshalb oft schlimmer als ein gewöhnlicher Seitenabschnitt: Es behauptet visuell, die Aufmerksamkeit zu übernehmen, während die technische Navigation weiterhin in zwei Ebenen gleichzeitig stattfindet.

Red Flag 1: Der Hintergrund ist nur dunkler, aber weiterhin aktiv

Ein Backdrop ist Gestaltung. Modalität ist Verhalten.

Wenn Links, Formulare oder Buttons hinter dem Overlay noch per Tastatur erreichbar sind, ist der Hintergrund nicht wirklich inert. Dass man ihn mit der Maus kaum sieht, löst das Problem nicht.

Der APG formuliert hier sehr klar: Inhalte außerhalb eines aktiven modalen Dialogs sollen nicht interaktiv sein. Bei einem nativen HTML-dialog, das mit showModal() geöffnet wird, übernimmt der Browser einen wichtigen Teil dieser Arbeit und behandelt den Rest des Dokuments als blockiert beziehungsweise inert.

Bei selbst gebauten div-Overlays muss diese Logik dagegen vollständig und dauerhaft korrekt nachgebildet werden. Genau dort entstehen typische Fehler nach Refactorings, Portal-Wechseln oder verschachtelten Overlays.

Audit-Frage: Können Sie bei offenem Modal mit Tab, Shift+Tab, einem Screenreader oder einem Klick tatsächlich noch etwas hinter dem Dialog erreichen?

Wenn ja, ist es optisch modal, technisch aber nicht.

Red Flag 2: Der Fokus landet irgendwo – Hauptsache im Modal

„Fokus wurde verschoben“ ist noch kein gutes Fokusmanagement.

Der aktuelle HTML Living Standard weist ausdrücklich darauf hin, dass die richtige initiale Fokusposition vom Inhalt abhängt. Für ein kleines Eingabeformular kann das erste sinnvolle Feld passen. Bei einem längeren Dialog mit mehreren Absätzen oder einer Tabelle kann es dagegen besser sein, einen statischen Einstiegspunkt am Anfang zu fokussieren, damit Nutzer die Struktur in sinnvoller Reihenfolge wahrnehmen.

Der W3C APG nennt ebenfalls unterschiedliche Situationen:

• Bei strukturiertem, längerem Inhalt kann ein statisches Element am Anfang mit tabindex="-1" sinnvoll sein.
• Wenn eine irreversible Aktion bestätigt wird, kann es besser sein, die weniger destruktive Aktion zuerst zu fokussieren.
• Bei einem einfachen Fortsetzungsdialog kann die wahrscheinlichste Aktion sinnvoll sein.
• Wird sonst beim Öffnen direkt ein weit unten liegender Button fokussiert, kann der Anfang des Inhalts sogar aus dem sichtbaren Bereich scrollen.

Die Regel lautet deshalb nicht „immer erstes Input-Feld“ oder „immer Close-Button“.

Die bessere Regel lautet: Was muss die Person als Nächstes verstehen oder tun?

Red Flag 3: aria-modal="true" soll die ganze Arbeit erledigen

ARIA beschreibt Bedeutung. Es repariert kein Verhalten.

Ein div role="dialog" aria-modal="true" wird nicht automatisch zu einem funktionierenden Modal. Der APG warnt sogar davor, einen Dialog als modal zu markieren, wenn er sich für andere Nutzer gar nicht modal verhält.

Ein benutzerdefinierter Dialog braucht mindestens:

• eine passende Dialog-Semantik,
• einen verständlichen zugänglichen Namen, typischerweise über aria-labelledby auf eine sichtbare Überschrift oder über aria-label,
• korrektes Fokusmanagement,
• echte Inertheit des Hintergrunds,
• Tastaturbedienung,
• einen verlässlichen Schließweg.

Auch aria-describedby sollte nicht reflexartig auf den gesamten Dialoginhalt zeigen. Der APG empfiehlt bei komplexen Inhalten mit Listen, Tabellen oder mehreren Absätzen, die Struktur nicht zu einer einzigen langen Screenreader-Beschreibung zusammenzuquetschen.

Mehr ARIA ist nicht automatisch mehr Barrierefreiheit. Oft ist das native HTML-Element der bessere Ausgangspunkt.

Native dialog statt selbst gebauter Fokusmaschine

W3C Technique H102 beschreibt das HTML-dialog-Element ausdrücklich als robuste Möglichkeit für modale Dialoge. Beim Öffnen mit showModal() übernimmt der Browser wichtige Teile des erwarteten Verhaltens, darunter das Verschieben des Fokus, die Begrenzung des Fokus auf den Dialog und das Zurückführen zum auslösenden Element beim Schließen.

Das spart sehr viel fehleranfälligen Eigenbau.

Ein vereinfachtes Grundmodell besteht aus:

• einem echten button als Trigger,
• einem <dialog> mit zugänglichem Namen,
• showModal() zum modalen Öffnen,
• einer sichtbaren Schließen- oder Abbrechen-Aktion,
• close() oder einem Dialog-Formular zum sauberen Schließen.

Das heißt nicht, dass native Dialoge automatisch perfekt sind. Das Team muss weiterhin entscheiden:

• welches Element initial Fokus erhält,
• ob der Dialog bei Zoom und kleinen Viewports sinnvoll scrollt,
• wie Validierungsfehler behandelt werden,
• wo Fokus nach einer Aktion landen soll,
• wie verschachtelte Dialoge oder weitere Overlays funktionieren,
• ob Screenreader und reale Zielbrowser den konkreten Flow gut bedienen können.

Aber der Browser beginnt mit einem deutlich besseren Fundament als ein beliebiges div mit position: fixed.

Red Flag 4: Nach dem Schließen ist der Nutzer „irgendwo“

Ein Modal unterbricht einen Arbeitsfluss. Nach dem Schließen muss dieser Arbeitsfluss wieder aufgenommen werden.

Der Normalfall im APG ist deshalb: Fokus zurück auf das Element, das den Dialog geöffnet hat.

Beispiel:

1. Nutzer fokussiert „Adresse bearbeiten“.
2. Dialog öffnet sich.
3. Nutzer ändert die Adresse und speichert.
4. Dialog schließt sich.
5. Fokus kehrt zu „Adresse bearbeiten“ zurück.

Es gibt sinnvolle Ausnahmen. Wenn der Trigger durch die Aktion verschwindet oder der nächste logische Schritt woanders liegt, darf Fokus dorthin verschoben werden. Nach „Neue Zeile hinzufügen“ kann beispielsweise die neu erzeugte Zeile der bessere Zielpunkt sein.

Was nicht sinnvoll ist: Fokus fällt ohne Konzept auf den body, springt zum Seitenanfang oder verschwindet vollständig.

Das fühlt sich für Tastaturnutzer an, als hätte die Anwendung nach jeder Dialogaktion kurz das Gedächtnis verloren.

Red Flag 5: Das X funktioniert – aber nur mit der Maus

Jeder Dialog braucht einen klaren Schließweg.

Der APG empfiehlt ausdrücklich ein sichtbares Element mit Button-Rolle zum Schließen, etwa ein Schließen-Icon oder einen Abbrechen-Button. Außerdem gehört Escape zum erwarteten Tastaturverhalten eines modalen Dialogs.

Prüfen Sie deshalb nicht nur, ob ein X sichtbar ist:

• Ist es ein echter Button?
• Hat es einen verständlichen zugänglichen Namen wie „Dialog schließen“?
• Ist sein Fokuszustand sichtbar?
• Kann es per Enter oder Space aktiviert werden?
• Funktioniert Escape?
• Ist bei einem kritischen Prozess klar, ob Schließen Daten verwirft?
• Wird ungespeicherter Zustand gegebenenfalls vorher bestätigt?

Ein klickbares SVG mit JavaScript-Handler ist kein gleichwertiger Ersatz für einen semantischen Button.

„Focus Trap“ ist nicht gleich Keyboard Trap

Der Begriff führt häufig zu Verwirrung.

Ein modaler Dialog soll seine Tab-Reihenfolge enthalten. Wer mit Tab am letzten fokussierbaren Element ankommt, soll wieder zum ersten Element im Dialog gelangen. Das ist erwünschte Modalität.

WCAG 2.1.2 „No Keyboard Trap“ meint etwas anderes: Eine Person darf nicht in einer Komponente feststecken, ohne mit der Tastatur wieder herauszukommen beziehungsweise ohne einen bekannten Ausweg zu haben.

Für einen Modal bedeutet das praktisch: Fokus bleibt während der Benutzung im Dialog, aber der Dialog selbst muss mit der Tastatur beendet werden können. Escape, Abbrechen oder Schließen bilden diesen Ausweg.

Ein selbst gebauter Fokus-Trap, der zwar Tab abfängt, aber bei einem JavaScript-Fehler keine funktionierende Schließen-Aktion mehr hat, ist genau die Art Robustheitsproblem, die im Happy Path unsichtbar bleibt.

Der Test, der in fünf Minuten mehr findet als ein Screenshot

Ein brauchbarer Modal-Audit beginnt ohne Maus.

1. Trigger fokussieren

Navigieren Sie nur mit Tab zum auslösenden Button. Ist der Fokus sichtbar? Lässt sich der Dialog mit Tastatur öffnen?

2. Öffnen und Fokus beobachten

Wohin springt der Fokus? Passt dieses Ziel zum Inhalt und zur Aufgabe? Wird ein Titel oder Kontext verständlich angekündigt?

3. Vorwärts tabben

Gehen Sie durch alle interaktiven Elemente. Nach dem letzten Element darf der Fokus nicht in die Seite dahinter verschwinden.

4. Rückwärts tabben

Dasselbe mit Shift+Tab. Besonders hier brechen handgebaute Fokus-Traps gern.

5. Hintergrund testen

Versuchen Sie bewusst, hinter dem Dialog zu interagieren: Tastatur, Klick, Touch und – soweit vorhanden – Screenreader-Navigation.

6. Mit Escape schließen

Funktioniert der erwartete Tastaturweg? Wird eine notwendige Warnung bei ungespeicherten Änderungen respektiert?

7. Fokus nach dem Schließen prüfen

Landet er wieder beim Trigger oder an einem bewusst gewählten nächsten Schritt?

8. Zoom und kleine Viewports testen

Bei 200 oder 400 Prozent Zoom kann aus einem kleinen Dialog ein langes Dokument werden. Sind Titel, Inhalt und Schließen-Aktion weiterhin erreichbar, ohne dass der Fokus in unsichtbare Bereiche wandert?

9. Fehlerzustände erzwingen

Validierung, langsame Requests, API-Fehler und Ladezustände verändern den Inhalt eines Dialogs. Bleibt Fokus logisch? Werden Fehlermeldungen wahrgenommen? Bleibt die Schließen-Aktion erreichbar?

10. Mehrere Overlays testen

Was passiert, wenn aus einem Dialog ein Datepicker, ein Bestätigungsdialog oder ein weiteres Overlay geöffnet wird? Welcher Layer ist aktiv? Wohin kehrt Fokus nach jedem Schließen zurück?

Genau solche verschachtelten Zustände machen aus einem scheinbar trivialen Modal einen echten Komponenten-Test.

Was Teams im Design-System festlegen sollten

Modale Dialoge sollten nicht in jeder Feature-Story neu erfunden werden. Eine zentrale Komponente braucht klare Verträge:

• semantisches Element und Öffnungsmechanismus,
• accessible name,
• Regeln für initialen Fokus,
• sichtbare Fokuszustände,
• Schließen via Tastatur und sichtbare Aktion,
• Rückgabe des Fokus,
• Scroll- und Größenverhalten,
• Umgang mit Destruktivaktionen,
• Verhalten bei verschachtelten Overlays,
• Tests für Tastatur und Assistive Technology.

Besonders hilfreich sind automatisierte Regressionstests für das Grundverhalten: Dialog öffnen, Fokus prüfen, Tab-Sequenz testen, schließen, Fokus-Rückgabe prüfen.

Automatisierung ersetzt keinen Screenreader- und Nutzungstest. Sie verhindert aber, dass ein Refactoring aus Versehen genau die Fokuslogik zerstört, die seit Monaten niemand mehr bewusst angesehen hat.

Was Website-Pflichtencheck dabei prüfen würde

Ein Dialog- und Fokus-Audit kann unter anderem untersuchen:

• native dialog-Nutzung gegenüber handgebauten Overlays,
• showModal() und tatsächliche Modalität,
• Dialog-Namen und ARIA-Zuordnung,
• initiale Fokusplatzierung,
• Tab- und Shift-Tab-Sequenzen,
• sichtbaren Fokus,
• Escape, Abbrechen und Close-Buttons,
• Inertheit des Hintergrunds,
• Fokus-Rückgabe nach Abschluss,
• destruktive Bestätigungen,
• Validierungs- und Ladezustände,
• Zoom, mobile Viewports und Scrollverhalten,
• verschachtelte Dialoge, Datepicker und Portals,
• Regressionstests im Design-System.

Das Ziel ist nicht, jeden Dialog mit möglichst viel Accessibility-Code zu umwickeln. Im Gegenteil: So viel native Plattform wie möglich, so wenig fragile Eigenlogik wie nötig.

Ein Modal ist ein kurzer Moment, in dem die Anwendung sagt: „Das hier ist jetzt wichtig.“ Dann sollte sie technisch auch genau wissen, wo der Nutzer ist, was er bedienen kann und wohin er danach zurückkehrt.

Wenn das nicht reproduzierbar beantwortet werden kann, ist der Dialog nicht fertig – er ist nur zentriert.