Ein Modal Dialog ist ein Overlay-Fenster, das über dem Hauptinhalt einer Anwendung erscheint, den Hintergrund blockiert und die Nutzerinteraktion auf den Dialog-Inhalt fokussiert, bis die Aktion abgeschlossen oder abgebrochen wird.
Rubrik: Mediendesign & Digitale Medien · Unterrubrik: UI-Komponenten · Niveau: Einsteiger Synonyme / Auch bekannt als: Dialogfenster, Popup, Overlay, Lightbox, Alert Dialog, Sheet (iOS)
Was ist ein Modal Dialog?
Modals unterbrechen den Nutzungsfluss bewusst – sie erzwingen eine Reaktion. Diese Unterbrechung ist nur dann gerechtfertigt, wenn die Information oder Aktion kritisch und kontextrelevant ist und nicht auf einer anderen Seite stattfinden kann. Falsch eingesetzt sind Modals einer der häufigsten UX-Frustrations-Faktoren; richtig eingesetzt schützen sie vor irreversiblen Fehlern und ermöglichen fokussierte Interaktionen ohne Seitenwechsel.
Erklärung
Varianten
Confirmation Dialog / Alert Dialog: Fragt den Nutzer nach Bestätigung, bevor eine kritische Aktion durchgeführt wird. Klassisch: „Datei wirklich löschen? [Abbrechen] [Löschen]". Zwei Buttons: eine destruktive und eine sichere Aktion.
Form Modal: Enthält ein Formular oder mehrstufigen Prozess. Beispiel: „Neues Projekt erstellen" mit Eingabefeldern. Sollte keine zu langen Formulare enthalten – bei komplexen Formularen ist eine separate Seite besser.
Image/Media Lightbox: Zeigt Bilder oder Videos in vergrößerter Ansicht. Klick außerhalb schließt den Modal. Beispiel: Instagram-Foto in Vollansicht.
Information Modal: Zeigt wichtige Informationen ohne destruktive Aktion. Kann Onboarding-Tipps, Cookie-Hinweise oder Update-Changelog enthalten.
Drawer / Bottom Sheet (mobil): Modal, das von der Seite oder von unten einschiebt. Nicht vollständig overlay-blockierend. iOS-typisches Pattern (z. B. Share Sheet).
Anatomie
- Backdrop / Overlay: Halbtransparente Abdeckung des Hintergrunds (meist rgba(0,0,0,0.5)). Signalisiert Modalität.
- Dialog Container: Der eigentliche Inhalt-Container, zentriert oder von unten/Seite eingeschoben
- Header: Titel des Dialogs, optionales Schließen-Icon (×)
- Content Area: Haupt-Inhalt (Text, Formular, Medien)
- Footer / Action Area: Buttons (Bestätigen, Abbrechen, Primäraktion)
States
| State | Beschreibung |
|---|---|
| Closed (Hidden) | Modal nicht sichtbar |
| Opening | Animation (fade-in, slide-up) |
| Open (Active) | Sichtbar, Fokus im Modal |
| Loading | Inhalt lädt nach Aktion |
| Closing | Closing-Animation |
| Error State | Formularvalidierung schlägt fehl |
Accessibility (WCAG 2.1) – Fokus-Trap ist Pflicht
Modals haben die komplexesten Accessibility-Anforderungen aller UI-Komponenten:
role="dialog"auf dem Container,aria-modal="true"aria-labelledbyverweist auf die Dialog-Überschrift (h2)aria-describedbyverweist auf den Dialog-Beschreibungstext- Fokus-Trap: Beim Öffnen wandert der Fokus zum ersten fokussierbaren Element im Modal. Tab-Navigation zirkuliert nur innerhalb des Modals – Hintergrund ist nicht fokussierbar.
- Fokus-Rückgabe: Beim Schließen kehrt der Fokus zum auslösenden Element zurück
Escape-Taste schließt den Modal (außer bei kritischen Confirmation Dialogs)- Backdrop-Klick schließt den Modal (außer bei Alert Dialogs, die explizite Bestätigung erfordern)
aria-live="assertive"für kritische Alert-Dialoge (sofortige Screenreader-Ankündigung)- Scrollbarer Hintergrund wird via
overflow: hiddenauf<body>blockiert
Beispiele
- GitHub – Repository löschen: Beispielhafter Confirmation Dialog. Kritische Aktion erfordert Bestätigung durch Eintippen des Repository-Namens – verhindert versehentliches Löschen. Roter Danger-Button, klarer Warntext, keine Möglichkeit durch Backdrop-Klick zu schließen.
- Figma – Rename File: Form Modal für schnelle Umbenennung ohne Seitenwechsel. Input-Feld pre-filled mit aktuellem Namen, Fokus springt sofort ins Eingabefeld, Enter bestätigt, Escape schließt.
- Mobile vs. Desktop: iOS verwendet das Bottom Sheet Pattern als Äquivalent zum Desktop-Modal – gleitet von unten ein, haptisches Feedback beim Öffnen. Daumen-erreichbarer als ein zentriertes Modal. Android nutzt Material Design Dialogs (ähnlich Desktop) und Bottom Sheets.
- Accessibility Best Practice: Die ARIA Dialog-Implementierung von a11y-dialog (Open-Source-Bibliothek) gilt als Referenz: korrekter Fokus-Trap, Escape-Handling, Fokus-Rückgabe, scroll-blocking – alle WCAG 2.1 Anforderungen erfüllt.
- Häufiger Fehler: Modal ohne Fokus-Trap implementieren – Tastaturnutzer können in den Hintergrund tabben, was Screenreader-Nutzer desorientiert. Zweiter häufiger Fehler: Zu viele Informationen in einem Modal packen. Wenn der Dialog-Inhalt scrollbar wird, ist eine eigene Seite fast immer die bessere Wahl.
In der Praxis
Figma: Modal als Komponente mit Backdrop (separater Layer, Fill: rgba(0,0,0,0.5)) und Dialog-Container (weißer Frame, Schatten, border-radius). Für Prototypen: „Show Overlay" Interaktion mit der Modal-Komponente als Overlay-Frame. Animation: „Move In" von unten oder „Dissolve".
HTML/CSS-Grundstruktur: ```html <!-- Dialog Element (native, modernes HTML) --> <dialog id="confirm-dialog" aria-labelledby="dialog-title" aria-describedby="dialog-description" > <h2 id="dialog-title">Datei löschen?</h2> <p id="dialog-description">Diese Aktion kann nicht rückgängig gemacht werden.</p> <div class="dialog-actions"> <button type="button" class="btn-secondary" id="cancel-btn">Abbrechen</button> <button type="button" class="btn-danger" id="confirm-btn">Endgültig löschen</button> </div> </dialog>
<!-- JavaScript --> <script> const dialog = document.getElementById('confirm-dialog'); // Öffnen dialog.showModal(); // Natives Fokus-Trap inklusive! // Schließen dialog.close(); </script> ```
Das native <dialog>-Element übernimmt Fokus-Trap, Backdrop und Escape-Handling automatisch – seit 2022 in allen modernen Browsern unterstützt.
Vergleich & Abgrenzung
| Komponente | Unterbrechung | Hintergrund | Schließen |
|---|---|---|---|
| Modal | Ja (erzwingt Fokus) | Blockiert | Explizit |
| Toast | Nein | Nicht blockiert | Automatisch |
| Tooltip | Nein | Nicht blockiert | Hover-Ende |
| Popover | Nein | Nicht blockiert | Klick außen |
| Drawer/Sheet | Teilweise | Teilweise | Wischen/Klick |
Häufige Fragen (FAQ)
Wann ist ein Modal gerechtfertigt und wann störend? Modals sind gerechtfertigt bei: kritischen Bestätigungen (Löschen, Abmelden), fokussierten Kurzaufgaben (Umbenennen, Teilen), kontextueller Information die sofort benötigt wird. Modals sind störend bei: Marketing-Popups (Newsletter, App-Download), nicht-kritischen Informationen, die auch auf einer Folgeseite stehen könnten, und Inhalten die regelmäßig wiederholt erscheinen.
Warum ist das native `<dialog>`-Element der beste Ansatz? Das <dialog>-Element bietet nativ: Fokus-Trap innerhalb des Dialogs, ::backdrop CSS-Pseudoelement für den Hintergrund, showModal() und close() JavaScript-API, automatisches Escape-Handling bei showModal(), dialog ARIA-Semantik ohne zusätzliche Attribute. Es erspart die fehleranfällige manuelle ARIA-Implementierung.
Verwandte Einträge
Weiterführend
- Nielsen Norman Group – „Modal & Nonmodal Dialogs": nngroup.com/articles/modal-nonmodal-dialog
- Material Design 3 – Dialogs: m3.material.io/components/dialogs
- Apple Human Interface Guidelines – Alerts and Action Sheets: developer.apple.com/design/human-interface-guidelines/alerts
- MDN Web Docs –
<dialog>: developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog
