Fokus-Management in Modals und Popups: Die häufigste WCAG-Falle

Kaum eine WCAG-Anforderung wird so häufig verletzt wie das Fokus-Management in Modals und Popups. Das Muster ist auf fast jeder Webseite zu finden: Cookie-Banner, Newsletter-Popup, Produktschnellansicht, Login-Overlay – und in erschreckend vielen Fällen bricht die Tastaturbedienung genau dort zusammen.

Der Grund liegt selten am fehlenden Willen, sondern an fehlendem Wissen darüber, was ein Modal-Dialog technisch eigentlich braucht: einen eingefangenen Fokus, einen sauberen Einstiegs- und Ausstiegspunkt, und eine korrekte Ansage für Screenreader. Dieser Beitrag zeigt Schritt für Schritt, worauf es ankommt.

Was einen Focus Trap ausmacht

Ein Focus Trap sorgt dafür, dass der Tastaturfokus innerhalb eines geöffneten Modals bleibt, solange dieses aktiv ist. Drückt eine Nutzerin oder ein Nutzer wiederholt die Tabulatortaste, wandert der Fokus durch die interaktiven Elemente des Modals – Schließen-Button, Eingabefelder, Bestätigen-Button – und springt am Ende der Liste wieder zum ersten Element zurück, statt in den Hintergrundinhalt der Seite zu entkommen.

Ohne diesen Mechanismus landet der Fokus beim Weiter-Tabben irgendwann im Hintergrund der Seite, während das Modal optisch weiterhin im Vordergrund sichtbar ist. Für sehende Tastaturnutzerinnen und -nutzer wird das schnell verwirrend, für blinde Screenreader-Nutzende ist es oft gar nicht mehr nachvollziehbar, wo sie sich gerade befinden.

Wichtig: Ein Focus Trap darf ausschließlich für echte modale Dialoge eingesetzt werden – also für Inhalte, die den Rest der Seite tatsächlich blockieren. Wird derselbe Mechanismus versehentlich auf ein normales Seitenelement angewendet, sperrt er Nutzende dort fest, ohne dass sie einen Ausweg haben.

Fokus beim Öffnen korrekt setzen

Sobald ein Modal geöffnet wird, muss der Tastaturfokus aktiv in das Modal hinein verschoben werden – in der Regel auf die Überschrift des Dialogs oder auf das erste sinnvolle interaktive Element, etwa ein Eingabefeld. Bleibt der Fokus stattdessen auf dem Button stehen, der das Modal geöffnet hat, tabben Tastaturnutzerinnen und -nutzer zunächst weiter durch den nun unsichtbaren Hintergrund, bevor sie überhaupt im Modal ankommen.

Für Screenreader-Nutzende kommt eine zweite Anforderung hinzu: Der Fokuswechsel allein reicht nicht, wenn nicht gleichzeitig verständlich wird, dass sich ein neuer Dialog geöffnet hat. Deshalb sollte das Modal-Element als Dialog ausgezeichnet sein, mit einer erkennbaren, kurz vorgelesenen Überschrift, damit klar ist: Es hat sich etwas Neues geöffnet, und der Kontext hat gewechselt.

Ein häufiger Fehler in der Praxis: Entwicklerinnen und Entwickler setzen den Fokus per JavaScript zwar technisch korrekt, aber erst nach einer Animation mit Verzögerung. Bewegt sich die Nutzerin oder der Nutzer währenddessen bereits per Tastatur weiter, entsteht ein Wettlauf, der zu unvorhersehbarem Verhalten führt.

Fokus beim Schließen zurückgeben

Genauso wichtig wie das Setzen des Fokus beim Öffnen ist seine korrekte Rückgabe beim Schließen. Nach dem Schließen eines Modals sollte der Fokus zu genau dem Element zurückkehren, das es ursprünglich geöffnet hat – meist ein Button. Landet der Fokus stattdessen irgendwo am Seitenanfang oder verschwindet komplett aus dem sichtbaren Bereich, verlieren Tastaturnutzerinnen und -nutzer die Orientierung und müssen die gesamte Seite erneut abtasten.

Dieses Verhalten lässt sich in der Regel mit wenig Aufwand umsetzen: Vor dem Öffnen des Modals wird das aktuell fokussierte Element gemerkt, und beim Schließen wird der Fokus aktiv wieder dorthin gesetzt. Viele UI-Bibliotheken bringen diese Logik bereits eingebaut mit, eigene Entwicklungen vergessen sie aber häufig.

Wird das Modal nicht über einen Button, sondern automatisch beim Laden der Seite geöffnet – etwa ein Cookie-Banner –, gibt es kein natürliches Ausgangselement. In diesem Fall bietet sich als Ziel für die Fokusrückgabe die Hauptüberschrift der Seite oder ein anderes stabiles, sinnvolles Element an.

ESC-Taste und Klick außerhalb

Ein barrierefreier Modal-Dialog muss sich mit der ESC-Taste schließen lassen, ohne dass die Nutzerin oder der Nutzer erst zum Schließen-Button tabben muss. Das ist besonders für Menschen wichtig, die primär mit der Tastatur arbeiten, aber auch eine allgemein erwartete Interaktion, die viele Nutzende automatisch ausprobieren.

Zusätzlich sollte ein Klick außerhalb des Modal-Inhalts, also auf den abgedunkelten Hintergrund, das Modal ebenfalls schließen – vorausgesetzt, es handelt sich nicht um einen Dialog, bei dem eine bewusste Entscheidung erzwungen werden soll, etwa eine Sicherheitsabfrage vor einer endgültigen Löschung.

Beide Mechanismen – ESC-Taste und Klick außerhalb – ersetzen nicht den sichtbaren Schließen-Button. Alle drei Wege sollten parallel funktionieren, damit unterschiedliche Nutzungsgewohnheiten und Eingabegeräte gleichermaßen bedient werden.

role=dialog und aria-modal richtig einsetzen

Technisch wird ein Modal für Screenreader über das Attribut role="dialog" ausgezeichnet, ergänzt um aria-modal="true", damit klar ist, dass der übrige Seiteninhalt während der Anzeige nicht bedienbar ist. Über aria-labelledby wird der Dialog mit seiner sichtbaren Überschrift verknüpft, sodass ein Screenreader beim Betreten des Dialogs direkt ansagt, worum es geht.

Ein verbreiteter Irrtum ist, dass aria-modal="true" allein schon einen Focus Trap erzeugt. Das Attribut ist lediglich eine semantische Information für assistive Technologien – die eigentliche Fokus-Kontrolle muss weiterhin über JavaScript umgesetzt werden. Wer nur das Attribut setzt, aber keinen echten Focus Trap implementiert, hat optisch alles richtig gemacht und funktional trotzdem eine Lücke.

Wichtig ist zudem, dass der Hintergrundinhalt während der Modal-Anzeige korrekt aus dem Zugriffsbaum entfernt oder über inert beziehungsweise aria-hidden markiert wird, damit Screenreader nicht versehentlich in den verdeckten Hintergrund vordringen.

Typische Fehler bei Cookie-Bannern und Newsletter-Popups

Cookie-Banner sind das mit Abstand häufigste Beispiel für fehlerhaftes Fokus-Management, weil sie auf praktisch jeder Webseite automatisch beim ersten Besuch erscheinen. Typische Fehlerbilder: Der Fokus wird beim Erscheinen des Banners gar nicht gesetzt, sodass Tastaturnutzerinnen und -nutzer zunächst durch unsichtbare Hintergrundelemente tabben müssen, bevor sie überhaupt beim Banner ankommen. Oder der Fokus wird zwar gesetzt, aber der Hintergrund bleibt weiterhin per Tab erreichbar, sodass kein echter Trap existiert.

Bei Newsletter-Popups, die oft nach einigen Sekunden Verzögerung automatisch erscheinen, kommt ein weiteres Problem hinzu: Der Schließen-Button ist häufig winzig, ohne sichtbaren Fokus-Rahmen und ohne verständliches Label – ein Screenreader liest dann nur "Button" vor, ohne dass klar wird, welche Funktion sich dahinter verbirgt.

Für Cookie-Banner speziell gilt zusätzlich: Die Auswahlmöglichkeiten müssen ebenso leicht per Tastatur erreichbar sein wie ein "Alle akzeptieren"-Button. Eine Ablehnung, die drei zusätzliche Klicks in einem Untermenü erfordert, während Zustimmung ein einzelner Klick ist, ist auch aus Datenschutzsicht problematisch.

Testanleitung nur mit der Tastatur

Der zuverlässigste Weg, Fokus-Probleme in Modals aufzudecken, ist ein einfacher Test: Maus komplett weglegen und die Seite ausschließlich mit Tab, Umschalt+Tab und Enter bedienen. Öffne das Modal über Tastatur, prüfe, ob der Fokus sichtbar hineinspringt, tabbe mehrfach durch alle Elemente und beobachte, ob der Fokus am Ende wieder zum ersten Element zurückspringt, statt in den Hintergrund zu entkommen.

Anschließend schließen: einmal über den Schließen-Button, einmal über ESC, einmal über Klick außerhalb, und jedes Mal prüfen, wo der Fokus danach landet. Kommt er zurück zum ursprünglichen Auslöser-Element, ist das ein gutes Zeichen. Verschwindet er komplett oder springt an den Seitenanfang, ist Nachbesserungsbedarf da.

Ergänzend lohnt sich ein kurzer Test mit einem Screenreader: Wird beim Öffnen tatsächlich angesagt, dass ein Dialog erschienen ist, und lässt sich der Hintergrund währenddessen nicht versehentlich erreichen? Wer regelmäßig eigene Komponenten baut, sollte dieses Testritual fest in die Entwicklung einbauen, statt Fokus-Management erst bei einer allgemeinen Tastatur-Prüfung am Ende zu entdecken. Ein automatisierter Scan über bf-check.de erkennt viele strukturelle Hinweise wie fehlende role="dialog"-Auszeichnung, ersetzt aber nicht den manuellen Tastaturtest für das dynamische Fokusverhalten.

Hinweis: Dieser Beitrag bietet allgemeine technische Hinweise zur Umsetzung von Fokus-Management und ersetzt keine individuelle rechtliche Bewertung deiner konkreten Webseite.

Häufig gestellte Fragen