Modals und Overlays gehören zu den am häufigsten falsch umgesetzten interaktiven Mustern im Web. Ein Cookie-Banner, ein Login-Dialog, eine Produkt-Schnellansicht oder eine Bestätigungsabfrage - sie alle legen sich über den restlichen Seiteninhalt und verlangen die volle Aufmerksamkeit der Nutzerin. Genau hier scheitern viele Umsetzungen: Der Tastatur-Fokus bleibt im Hintergrund hängen, ESC schließt nichts, und nach dem Schließen weiß niemand, wo der Fokus gelandet ist. Wie verbreitet Bedienfehler insgesamt sind, zeigt der WebAIM Million Report: 96% (WebAIM Million, 2024) aller untersuchten Startseiten hatten erkennbare WCAG-Verstöße, im Schnitt 56,8 (WebAIM Million, 2024) pro Seite. Dieser Leitfaden zeigt, wie Sie Dialoge mit role=dialog, aria-modal, einer Fokus-Falle, ESC-Unterstützung, korrekter Fokusrückgabe und einem inerten Hintergrund umsetzen - als belastbare Grundlage für Ihr WCAG-Audit.
Das Wichtigste in Kürze
- role=dialog und aria-modal=true signalisieren nur die Modalität - Fokus-Falle, inerter Hintergrund und Schließverhalten müssen aktiv umgesetzt werden.
- Beim Öffnen wandert der Fokus in den Dialog, beim Schließen kehrt er zum auslösenden Element zurück.
- Tab und Shift+Tab zirkulieren nur innerhalb des Dialogs (WCAG 2.4.3); ESC und ein beschrifteter Schließen-Button bieten den Ausweg.
- Der übrige Seiteninhalt wird per inert-Attribut still gelegt, damit weder Tastatur noch Screenreader dahinter gelangen.
- Das native dialog-Element mit showModal() bringt Fokus-Falle, inerten Hintergrund und ESC bereits mit und reduziert Fehlerquellen deutlich.
Warum Modals so oft an der Barrierefreiheit scheitern
Ein Modal ist mehr als ein optisch hervorgehobenes Kästchen. Aus Sicht der Barrierefreiheit ist es ein eigener, abgeschlossener Interaktionsraum, der die übrige Seite vorübergehend deaktiviert. Genau diese Abgeschlossenheit muss technisch hergestellt werden - und das wird oft übersehen. Der Dialog (Modal) Pattern des ARIA Authoring Practices Guide beschreibt einen Dialog als Fenster, das über dem Hauptfenster liegt, während die darunterliegenden Inhalte inert sind, also nicht bedienbar (W3C/WAI). Fehlt diese Inertheit, können Tastatur- und Screenreader-Nutzer hinter den sichtbaren Dialog gelangen und mit verdeckten Elementen interagieren.
Die Praxis bestätigt, wie heikel das ist. Der WebAIM Million Report fand auf 81% (WebAIM Million, 2024) der Startseiten Text mit zu geringem Kontrast und stellte fest, dass Seiten mit mehr ARIA-Attributen tendenziell mehr Fehler aufwiesen - 28% (WebAIM Million, 2024) der ARIA-Menüs führten sogar zusätzliche Barrieren ein, weil notwendige Tastatur-Interaktionen fehlten. Modals sind genau so ein Fall: Das role=dialog-Attribut allein macht einen Dialog nicht modal. Die eigentliche Modalität - Fokus-Falle, inerter Hintergrund, Schließverhalten - muss in JavaScript implementiert werden (MDN Web Docs). In Deutschland betrifft das viele Menschen unmittelbar: Ende 2023 lebten hier rund 7,9 Mio. (Statistisches Bundesamt, 2024) schwerbehinderte Menschen, weltweit haben rund 2,2 Mrd. (WHO, 2023) Menschen eine Sehbeeinträchtigung.
role=dialog macht noch keinen modalen Dialog
Die sechs Pflichtbausteine eines barrierefreien Dialogs
Ein zugängliches Modal entsteht aus dem Zusammenspiel mehrerer Bausteine. Keiner davon ist optional - fällt einer aus, ist der Dialog für mindestens eine Nutzergruppe nicht bedienbar. Die folgende Übersicht fasst zusammen, was der Dialog (Modal) Pattern und die relevanten WCAG-Erfolgskriterien verlangen (W3C/WAI). Diese Punkte prüfen wir im Rahmen unserer Leistungen systematisch ab.
role=dialog
Der Container trägt role=dialog (oder alertdialog) und aria-modal=true, damit assistive Technologien den modalen Charakter erkennen.
Zugänglicher Name
Der Dialog wird über aria-labelledby auf die sichtbare Überschrift oder über aria-label benannt, damit klar ist, worum es geht.
Fokus-Falle
Tab und Shift+Tab zirkulieren nur innerhalb des Dialogs. Der Fokus verlässt den Dialog nicht unbeabsichtigt (WCAG 2.4.3).
Erstfokus
Beim Öffnen wandert der Fokus in den Dialog - auf das erste Bedienelement, die Überschrift oder den Dialog selbst.
ESC und Schließen
Die Escape-Taste schließt den Dialog. Ein sichtbarer, beschrifteter Schließen-Button ist zusätzlich vorhanden.
Fokus zurück
Nach dem Schließen kehrt der Fokus zum auslösenden Element zurück, damit der Kontext nicht verloren geht.
Hinzu kommt der inerte Hintergrund: Solange der Dialog offen ist, darf der Rest der Seite weder per Tastatur noch per Screenreader erreichbar sein. Moderne Browser bieten dafür das inert-Attribut, das sowohl Tastaturfokus als auch Screenreader-Navigation unterbindet (MDN Web Docs). Das natürlichste Fundament für all das ist häufig das native HTML-Element dialog mit der Methode showModal(), das Fokus-Falle und Hintergrund-Inertheit bereits mitbringt - die übrigen Bausteine bleiben aber Ihre Aufgabe. Diese Bausteine bauen direkt auf den Grundlagen der Tastaturnavigation in der Webentwicklung auf.
Der Lebenszyklus eines barrierefreien Dialogs
- 1
Auslöser merken
Vor dem Öffnen wird das auslösende Element festgehalten, damit der Fokus später dorthin zurückkehren kann.
- 2
Öffnen und Erstfokus
Der Dialog erscheint, der Fokus wandert hinein - auf das erste Bedienelement, die Überschrift oder den Dialog selbst.
- 3
Hintergrund inert setzen
Der übrige Seiteninhalt wird per inert deaktiviert, sodass Tastatur und Screenreader nur noch im Dialog arbeiten.
- 4
Fokus-Falle halten
Tab und Shift+Tab zirkulieren innerhalb des Dialogs; ESC und der beschriftete Schließen-Button bleiben jederzeit erreichbar.
- 5
Schließen und Fokus zurück
Beim Schließen wird der Hintergrund wieder aktiv und der Fokus kehrt zum gemerkten Auslöser zurück - der Kontext bleibt erhalten.
Die Fokus-Falle richtig umsetzen
Die Fokus-Falle ist das Herzstück eines modalen Dialogs. WCAG 2.4.3 Fokus-Reihenfolge verlangt, dass der Fokus in einer sinnvollen, die Bedeutung erhaltenden Reihenfolge wandert (W3C/WAI). Bei einem modalen Dialog bedeutet das: Tab springt vom letzten fokussierbaren Element wieder zum ersten, Shift+Tab vom ersten zum letzten. Der Fokus verlässt den Dialog nicht in die dahinterliegenden, verdeckten Seiteninhalt. Wichtig ist die Abgrenzung zu WCAG 2.1.2 Keine Tastaturfalle: Diese verbietet Fallen, aus denen man gar nicht mehr herauskommt. Ein modaler Dialog ist keine verbotene Falle, weil ESC und der Schließen-Button jederzeit einen Ausweg bieten.
In der Umsetzung ermitteln Sie beim Öffnen alle fokussierbaren Elemente im Dialog und behandeln das erste und letzte gesondert. Springt der Fokus über das letzte Element hinaus, lenken Sie ihn auf das erste; umgekehrt bei Shift+Tab. Das native dialog-Element mit showModal() übernimmt dieses Verhalten weitgehend automatisch und ist daher in den meisten Fällen die robustere Wahl gegenüber einer Eigenimplementierung. Ähnlich kritisch ist die Fokussteuerung bei dynamischen Inhalten, weshalb sich der Blick in unseren Beitrag zu barrierefreien Datentabellen und komplexen Inhalten lohnt.
<!-- Auslöser -->
<button id="open" type="button">Newsletter abonnieren</button>
<!-- Natives Dialog-Element: Fokus-Falle + inerter Hintergrund
werden von showModal() übernommen -->
<dialog id="dlg" aria-labelledby="dlg-title">
<h2 id="dlg-title">Newsletter abonnieren</h2>
<form method="dialog">
<label for="mail">E-Mail-Adresse</label>
<input id="mail" type="email" name="mail" required>
<button value="ok" type="submit">Abonnieren</button>
<button value="cancel" formnovalidate>Abbrechen</button>
</form>
</dialog>const dlg = document.getElementById('dlg');
const opener = document.getElementById('open');
opener.addEventListener('click', () => {
dlg.showModal(); // setzt Erstfokus + macht Hintergrund inert
});
// ESC schließt showModal()-Dialoge bereits von selbst.
// Fokus zurück zum Auslöser nach dem Schließen:
dlg.addEventListener('close', () => {
opener.focus();
});Häufiger Fehler: Fokus bleibt im Hintergrund
ESC, Schließen und Fokus zuruckgeben
Ein modaler Dialog braucht mindestens zwei einander ergänzende Wege zum Schließen: die Escape-Taste und ein sichtbares, mit einem zugänglichen Namen versehenes Bedienelement, etwa einen Schließen-Button oder Abbrechen. Bei Dialogen mit der Rolle alertdialog - also Bestätigungsabfragen - kann ESC bewusst eingeschränkt sein, damit niemand versehentlich eine wichtige Entscheidung übergeht. Der Klick auf den abgedunkelten Hintergrund (Backdrop) darf zusätzlich schließen, ersetzt aber nicht ESC und den Button, weil er für Tastatur- und Screenreader-Nutzer nicht erreichbar ist.
Genauso wichtig wie das Öffnen ist die Fokusrückgabe beim Schließen. Der Fokus muss zurück zu dem Element, das den Dialog geöffnet hat - in der Regel der Auslöser-Button. Geschieht das nicht, springt der Fokus an den Seitenanfang oder verschwindet ganz, und Tastaturnutzer verlieren ihre Position. Bei dynamisch entfernten Auslösern (etwa einem Löschen-Button, der nach dem Löschen verschwindet) muss der Fokus auf ein sinnvolles Ersatzelement gesetzt werden. Solche Fokus- und Statusübergänge greifen eng in das Thema barrierefreie Fehlermeldungen und Statusmeldungen ein.
| Aspekt | Häufiger Fehler | Barrierefrei umgesetzt |
|---|---|---|
| Öffnen | Dialog erscheint, Fokus bleibt auf der Seite | Fokus wandert in den Dialog auf das erste Element |
| Tab-Navigation | Fokus wandert hinter den Dialog | Fokus-Falle: Tab zirkuliert nur im Dialog |
| Escape-Taste | ESC bewirkt nichts | ESC schließt den Dialog |
| Hintergrund | Hintergrund bleibt bedienbar | Hintergrund ist inert (inert / aria-hidden) |
| Schließen | Nur Backdrop-Klick | ESC, beschrifteter Button und optional Backdrop |
| Nach dem Schließen | Fokus verschwindet oder springt nach oben | Fokus kehrt zum Auslöser zurück |
Inerter Hintergrund: aria-modal, aria-hidden und inert
Damit ein Dialog wirklich modal ist, muss der gesamte übrige Seiteninhalt vorübergehend stillgelegt werden. Historisch wurde dafür aria-hidden=true auf allen Geschwister-Elementen des Dialogs gesetzt. Mit ARIA 1.1 kam aria-modal=true hinzu, das assistiven Technologien signalisiert, dass Inhalte ausserhalb des Dialogs inert sind, und das frühere Hantieren mit aria-hidden ersetzen soll (W3C/WAI). Allerdings unterbindet aria-modal allein noch nicht den Tastaturfokus - es ist ein reines Signal an Screenreader.
Den vollständigen Effekt erzielt das HTML-Attribut inert: Es nimmt einen Teilbaum sowohl aus der Tastatur-Reihenfolge als auch aus dem Accessibility-Tree heraus, sodass weder Fokus noch Screenreader hineingelangen (MDN Web Docs). Praktisch setzen Sie inert beim Öffnen auf den Wrapper des Seiteninhalts und entfernen es beim Schließen wieder. Das native dialog-Element mit showModal() erledigt diese Inertheit automatisch für den Rest der Seite - ein weiterer Grund, es der manuellen Lösung vorzuziehen. Hierbei ist sauberes Zusammenspiel von Rollen und Zuständen entscheidend, wie es der Beitrag zu ARIA-Rollen, Zuständen und Live-Regions vertieft.
Native dialog-Element als robusteste Grundlage
Sonderfälle: Cookie-Banner, Off-Canvas und Toasts
Nicht jedes Overlay ist ein modaler Dialog, und nicht jeder Inhalt sollte den Fokus erzwingen. Ein Cookie-Consent-Banner, das die Bedienung der Seite blockiert, sollte sich wie ein modaler Dialog verhalten - mit Fokus-Falle und zugänglichem Namen. Ein Off-Canvas-Navigationsmenü auf Mobilgeräten folgt demselben Muster, weil es den restlichen Inhalt verdeckt. Toast-Benachrichtigungen dagegen sind keine Dialoge: Sie dürfen den Fokus nicht an sich reissen, sondern werden über eine Live-Region angekündigt, damit der Lesefluss erhalten bleibt.
Auch beim Öffnen und Schließen über Animationen ist Vorsicht geboten. Bewegungen sollten prefers-reduced-motion respektieren, und der Fokus sollte erst gesetzt werden, wenn der Dialog sichtbar und bedienbar ist. Verschachtelte Dialoge - ein Dialog, der einen weiteren öffnet - sind möglich, sollten aber sparsam eingesetzt werden, weil jeder Dialog seine eigene Fokus-Falle und Rückgabe verwalten muss. Aus der Begleitung von 50+ (Projekterfahrung) Projekten wissen wir, dass die meisten Overlay-Probleme aus genau diesen Sonderfällen entstehen - nicht aus dem einfachen Standarddialog.
- Container mit role=dialog (oder alertdialog) und aria-modal=true ausgezeichnet
- Dialog über aria-labelledby oder aria-label mit zugänglichem Namen versehen
- Beim Öffnen Fokus in den Dialog gesetzt (erstes Element oder Überschrift)
- Fokus-Falle aktiv: Tab und Shift+Tab zirkulieren nur im Dialog
- ESC schließt den Dialog, zusätzlich ein beschrifteter Schließen-Button
- Hintergrund per inert oder aria-hidden stillgelegt
- Nach dem Schließen Fokus zurück zum auslösenden Element
- Mit Tastatur und Screenreader gegengeprüft
Ein Dialog ist erst dann modal, wenn die übrige Seite es nicht mehr ist. Wer nur das Aussehen baut, aber den Fokus und den Hintergrund vergisst, hat ein Overlay - aber keinen barrierefreien Dialog.
Modals berühren gleich mehrere WCAG-Erfolgskriterien auf einmal: 2.4.3 Fokus-Reihenfolge, 2.1.2 Keine Tastaturfalle, 4.1.2 Name, Rolle, Wert und in WCAG 2.2 zusätzlich 2.4.11 Fokus nicht verdeckt (W3C/WAI). Deshalb ist ein sauber umgesetzter Dialog oft ein Hebel, der mehrere Befunde in einem WCAG-Audit gleichzeitig adressiert. Wenn Sie Dialoge von Anfang an nach dem Dialog (Modal) Pattern bauen, vermeiden Sie eine ganze Klasse wiederkehrender Fehler - und schaffen eine verlässliche Grundlage für Ihre barrierefreie Webentwicklung.