Modal-Design für Web und App: Wann ein Overlay hilft — und wann es stört

Es gibt einen Moment in fast jedem Projekt, in dem jemand sagt: „Machen wir das einfach als Modal." Der Satz klingt harmlos. Er ist es nicht. Ein Modal ist die teuerste Entscheidung im Interface-Baukasten, weil sie dem Menschen vor dem Bildschirm etwas wegnimmt: die Möglichkeit, gerade etwas anderes zu tun.

In den letzten Jahren habe ich Modals in ganz unterschiedlichen Produkten gebaut — in einer Fachanwendung für Kitas, in einer Publishing-Oberfläche, in Portalen mit viel Struktur und wenig Platz. Und ich habe sie mindestens so oft wieder abgebaut. Fast jedes Mal war das Muster dasselbe: Das Modal war nicht die Lösung für ein Gestaltungsproblem, sondern der schnellste Weg, ein Strukturproblem nicht anfassen zu müssen.

Dieser Artikel handelt davon, wann ein Overlay die richtige Antwort ist, wann eine Seite, ein Panel oder gar nichts die bessere wäre — und wie du das Modal, das bleibt, so baust, dass es mit Tastatur, Screenreader und auf einem Handy in der Sonne funktioniert.

1. Was ein Modal wirklich ist

Technisch ist ein Modal ein Element, das über dem Rest liegt und den Rest so lange blockiert, bis man es schließt. Gestalterisch ist es eine Behauptung: Das hier ist wichtiger als alles, was du gerade getan hast.

Diese Behauptung stimmt selten. Sie stimmt, wenn eine Entscheidung wirklich getroffen werden muss, bevor es weitergehen kann — beim Löschen von etwas Unwiederbringlichem, bei einer Bestätigung mit rechtlicher Folge, bei einem kurzen, abgeschlossenen Schritt mitten in einem Ablauf. Sie stimmt nicht bei „Möchtest du unseren Newsletter?" und sie stimmt nicht bei einem 14-Feld-Formular, das nur deshalb im Overlay liegt, weil im Menü kein Platz mehr war.

Was ein Modal kostet, steht selten im Ticket:

• Kontext: Der Hintergrund ist zwar noch da, aber nicht mehr benutzbar. Wer im Overlay etwas nachschlagen muss, das dahinter steht, sitzt in der Falle.
• Adressierbarkeit: Ein Modal ohne eigene Route lässt sich nicht verlinken, nicht als Lesezeichen speichern, nicht per Zurück-Taste verlassen. Alles, was man teilen können soll, gehört auf eine eigene URL.
• Höhe: Auf dem Desktop passt fast alles. Auf einem Handy mit offener Tastatur bleiben oft weniger als 300 Pixel sichtbare Höhe übrig.
• Fokus: Ein Modal übernimmt die Tastaturführung. Macht es das schlecht, ist die Seite für Tastatur- und Screenreader-Nutzung praktisch kaputt — nicht nur unschön.
• Stapelung: Sobald das erste Modal existiert, kommt irgendwann das zweite darin. Spätestens dann weiß niemand mehr, was Escape schließt.

Modal, oder nur obenauf?

Nicht alles, was über dem Inhalt liegt, ist ein Modal. Die Unterscheidung lohnt sich, weil sie den halben Aufwand spart:

• Popover: hängt an einem Auslöser, blockiert nichts, schließt beim Klick daneben. Für Zusatzinfos, kleine Auswahlen, Kontextmenüs.
• Toast oder Statusleiste: meldet ein Ergebnis, verlangt nichts, verschwindet von allein — der richtige Ort für „Gespeichert" und für „Rückgängig".
• Inline-Hinweis: steht dort, wo die Sache passiert ist, und bleibt so lange, wie sie gilt. Fehlermeldungen gehören fast immer hierhin.
• Modal: blockiert, verlangt eine Entscheidung, wird aktiv geschlossen.

Nur der letzte Fall braucht Fokusfalle, Backdrop und all das, was in Abschnitt 4 steht. Die ersten drei kosten einen Bruchteil davon — und lösen erstaunlich viele der Aufgaben, für die reflexhaft ein Dialog aufgemacht wird.

Faustregel: Ein Modal unterbricht. Wenn du nicht in einem Satz sagen kannst, warum an dieser Stelle unterbrochen werden muss, ist es kein Modal, sondern eine Seite, ein Panel oder ein aufklappbarer Bereich.

2. Die Entscheidung kommt vor der Gestaltung

Bevor du Radius, Schatten und Backdrop-Deckkraft wählst, gehört eine Vorfrage beantwortet: Welches Muster ist das hier überhaupt? Vier Kandidaten stehen praktisch immer zur Wahl.

• Modal (Dialog): Eine kurze, abgeschlossene Entscheidung oder Eingabe, die auf das wirkt, was im Hintergrund liegt. Zwei bis fünf Felder, ein Ergebnis, unter einer Bildschirmhöhe. Beispiel: „Termin absagen — mit oder ohne Benachrichtigung?"
• Eigene Seite oder Route: Alles, was länger dauert als eine halbe Minute, was man teilen, unterbrechen und später fortsetzen können soll, was mehrere Schritte hat oder eigene Hilfetexte braucht. Anlegen eines Datensatzes mit 20 Feldern ist eine Seite, kein Overlay.
• Seitliches Panel (Drawer): Details zu einem Listeneintrag, während die Liste sichtbar und bedienbar bleibt. Der große Unterschied zum Modal: Es blockiert nichts. Man kann weiterklicken, das Panel aktualisiert sich. Für Redaktions- und Verwaltungsoberflächen ist das oft das bessere Muster — besonders über einer Datentabelle, in der man von Zeile zu Zeile springt.
• Inline aufklappen: Bearbeiten genau dort, wo das Objekt steht. Am wenigsten spektakulär, am seltensten falsch. Der Kontext bleibt vollständig erhalten, es gibt keinen Fokus-Wechsel und keine neue Ebene.

Zwei Prüffragen führen fast immer zur richtigen Antwort:

1. Muss der Hintergrund währenddessen lesbar bleiben? Wenn ja, ist es kein Modal, sondern ein Panel oder inline.
2. Kann der Vorgang länger als eine halbe Minute dauern oder unterbrochen werden? Wenn ja, gehört er auf eine eigene Route mit eigenem Zustand.

Aus der Praxis: der Filter, der dreimal umgezogen ist

In einer Fachanwendung, in der pädagogische Fachkräfte Beobachtungen zu Kindern erfassen, gab es einen Filter über einer sehr langen Liste. Version eins war ein klassisches Modal: Filter öffnen, sieben Kriterien setzen, „Anwenden", Dialog zu. Formal korrekt, in der Benutzung zäh — weil man beim Setzen der Kriterien nie sah, wie viel am Ende übrig bleibt. Wer sich verschätzte, öffnete den Dialog erneut und fing von vorn an.

Version zwei versuchte es mit einem transparenteren Backdrop, damit die Liste durchscheint. Das war die schlechteste Variante von allen: Man sah gerade genug, um hinsehen zu wollen, und gerade zu wenig, um etwas zu erkennen.

Version drei war dann kein Dialog mehr, sondern ein Panel an der Seite. Die Liste blieb sichtbar und aktualisierte sich bei jeder Änderung, die Trefferzahl stand direkt am Knopf, und der ganze „Anwenden"-Schritt fiel weg. Der Lerneffekt war nicht „Panels sind besser als Modals", sondern: Wir hatten ein Muster gewählt, bevor wir die Frage beantwortet hatten, ob der Hintergrund sichtbar bleiben muss.

Beispiel: Ein Filter über einer langen Liste landet fast reflexhaft im Modal. Dabei ist genau hier der Hintergrund das Interessante — man will sehen, wie sich die Trefferzahl verändert. Ein Panel neben der Liste oder eine Filterleiste darüber macht aus einer blinden Eingabe ein Werkzeug mit Rückmeldung.

3. Anatomie eines Modals, das trägt

Wenn nach der Vorfrage ein echtes Modal übrig bleibt, ist der Rest angenehm handwerklich. Ein tragfähiger Dialog hat immer dieselben Teile.

Titel, der die Entscheidung benennt

Der Titel ist keine Rubrik, sondern die Frage, die beantwortet werden soll. „Achtung" ist keine Frage. „Projekt Sommerfest endgültig löschen?" ist eine. Der Titel muss allein stehen können — Screenreader lesen ihn beim Öffnen als Erstes vor, ohne den Satz, der auf dem Knopf stand, der das Modal geöffnet hat.

Ein Inhalt, nicht drei

Ein Dialog beantwortet eine Frage. Sobald darin Tabs, ein Assistent mit Schritten oder ein zweiter Themenblock auftauchen, ist es eine Seite im Verkleidungskostüm. Wenn ein Formular in den Dialog muss, gelten dort alle Regeln, die auch sonst gelten: sichtbare Labels, Fehler am Feld, kein Platzhalter als Beschriftung. Ein Overlay macht schlechte Formulare nicht kompakter, nur enger.

Genau zwei Aktionen, mit Verben beschriftet

• Primäraktion: benennt, was passiert — „Löschen", „Absagen", „Einladung senden". Nicht „OK", nicht „Ja".
• Sekundäraktion: benennt den Rückweg — „Abbrechen" oder besser „Behalten", wenn das die ehrlichere Beschreibung ist.
• Position: eine Reihenfolge im ganzen Produkt, konsequent durchgehalten. Welche Seite die primäre ist, ist Geschmackssache. Dass sie wechselt, ist ein Bug.
• Destruktives kennzeichnen: Die gefährliche Aktion darf farblich herausstechen — aber nur, wenn sie wirklich die erwartete ist. Sonst wird sie zur Falle für Menschen, die auf Position statt auf Text klicken.

Größe, Höhe und genau ein Scrollbereich

Ein Dialog, der mit seinem Inhalt in alle Richtungen wächst, wird auf kleinen Bildschirmen unbedienbar. Was sich bewährt hat:

• Feste Maximalbreite aus dem System, keine Breite pro Einzelfall.
• Maximalhöhe relativ zum sichtbaren Bereich, nicht zum Dokument — sonst liegt der Fußbereich außerhalb des Bildschirms.
• Kopf und Fuß bleiben stehen, nur der mittlere Bereich scrollt. Ein Speichern-Knopf, den man erst herunterscrollen muss, wird übersehen.
• Ein Scrollbereich, nicht zwei. Ein scrollender Dialog in einer scrollenden Seite ist der zuverlässigste Weg, Menschen auf Touchgeräten zu verlieren.

Wenn der Inhalt auch mit diesen Regeln nicht passt, ist das kein Layoutproblem, sondern die Antwort auf die Frage aus Abschnitt 2: Es ist eine Seite.

Ein ehrlicher Schließen-Weg

Klick auf den Hintergrund, Escape und ein sichtbares Schließen-Symbol sollten dasselbe tun. Und sie dürfen nur dann kommentarlos schließen, wenn dabei nichts verloren geht. Enthält der Dialog ungespeicherte Eingaben, ist der Hintergrundklick entweder deaktiviert oder er fragt nach. Nichts zerstört Vertrauen schneller als ein Fehlklick, der zehn Minuten Tipparbeit löscht.

Nicht leer aufgehen

Ein Dialog, der sich öffnet und erst danach seinen Inhalt lädt, springt beim Nachladen in der Höhe und verschiebt die Knöpfe unter dem Cursor. Entweder du lädst vorher und öffnest fertig, oder du öffnest mit einer Platzhalterstruktur in der späteren Höhe. Das ist derselbe Gedanke wie bei Ladezuständen an jeder anderen Stelle: Die Wartezeit lässt sich nicht wegzaubern, aber sie lässt sich gestalten.

4. Fokus, Tastatur, Screenreader

Hier entscheidet sich, ob ein Modal ein Bauteil oder eine Barriere ist. Und hier wird am häufigsten geschludert, weil mit Maus alles zu funktionieren scheint.

• Fokus setzen beim Öffnen: auf das erste sinnvolle Element — das erste Eingabefeld oder den Dialog-Container selbst. Nie auf die destruktive Aktion. Ein Dialog, bei dem ein Druck auf die Leertaste etwas löscht, ist kein Sicherheitsnetz, sondern eine Falle.
• Fokus halten: Tab läuft im Dialog im Kreis und verlässt ihn nicht. Der Hintergrund wird für assistive Technik unsichtbar gemacht (inert oder aria-hidden), sonst liest der Screenreader munter die Seite darunter weiter.
• Fokus zurückgeben: Nach dem Schließen landet der Fokus wieder auf dem Element, das den Dialog geöffnet hat. Sonst beginnt jede Tastaturnutzung nach jedem Dialog wieder ganz oben.
• Escape schließt: Immer. Und zwar nur die oberste Ebene.
• Ankündigen: role="dialog" mit aria-modal="true" und einem aria-labelledby, das auf den Titel zeigt. Damit weiß die Ausgabe, dass ein eigener Bereich begonnen hat — und wie er heißt.
• Hintergrund nicht scrollen lassen: Auf dem Desktop ärgerlich, auf iOS ein Klassiker: Der Dialog steht still, die Seite darunter rutscht weg.

Zwei Dinge kommen in Reviews selten vor und fallen in der Nutzung sofort auf: Erstens braucht jedes interaktive Element im Dialog einen sichtbaren Fokusring — auch der Schließen-Knopf und auch dann, wenn er nur ein Symbol ist. Zweitens muss ein Dialog, der etwas meldet statt fragt, das auch ankündigen: Ein Fehler, der nach dem Absenden im Dialog erscheint, gehört in einen Bereich mit role="alert", sonst bemerkt ihn eine Screenreader-Nutzung erst beim nächsten Durchtabben.

Das native <dialog>-Element mit showModal() bringt Fokusfalle, Escape und Top-Layer-Verhalten mit und nimmt dir einen großen Teil dieser Arbeit ab. Wer stattdessen eine Komponentenbibliothek nutzt, prüft die Punkte oben einmal am fertigen Bauteil — nicht am Versprechen in der Dokumentation.

Tipp für den Test: Leg die Maus weg. Öffne den Dialog mit der Tastatur, tabbe zweimal im Kreis, drück Escape und schau, wo der Fokus danach steht. Diese 30 Sekunden finden mehr echte Fehler als jede Checkliste — und sie sind derselbe Handgriff, der in Barrierefreiheit im UX-Design an vielen anderen Stellen hilft.

5. Mobil ist kein geschrumpftes Desktop-Modal

Ein zentriertes Overlay mit viel Rand ist auf dem Desktop ruhig und auf dem Handy ein Streichholzschachtel-Fenster mit eigenem Scrollbereich im Scrollbereich. Die mobile Antwort heißt in den meisten Fällen: von unten.

• Sheet statt Kästchen: Ein von unten eingeschobenes Feld nutzt die volle Breite, liegt im Daumenbereich und kann wachsen, ohne dass der Inhalt in einem Mini-Rahmen scrollt.
• Tastatur einplanen: Sobald ein Feld fokussiert wird, verschwindet die halbe Höhe. Aktionen gehören dann entweder an den oberen Rand des Sheets oder mit der Tastatur mitgeschoben — nicht dahinter.
• Griff plus sichtbarer Ausweg: Zum Wegwischen gehört immer auch ein sichtbares Schließen-Element. Eine Geste allein ist kein Bedienelement, weil man sie nicht sehen kann.
• Zurück-Geste bedenken: Auf Android und im mobilen Browser erwarten Menschen, dass Zurück den Dialog schließt und nicht die ganze Ansicht verlässt. Ein Eintrag in der History-Verwaltung erledigt das.
• Sichere Bereiche beachten: Die Primäraktion darf nicht unter der Home-Leiste liegen.

Dazu kommt ein Detail, das auf dem Desktop nie auffällt: Auf Touchgeräten liegt der Finger auf dem Inhalt. Ein Sheet, das sich schon bei minimaler Abwärtsbewegung schließt, wird beim Scrollen versehentlich weggewischt. Entweder die Wisch-Geste greift nur am Griffbalken, oder sie braucht eine deutliche Distanz — und in beiden Fällen bleibt der sichtbare Schließen-Weg daneben bestehen.

Bei allem, was mehr als drei Felder hat, ist auf dem Handy ohnehin die Vollbild-Ansicht mit eigener Route das ehrlichere Muster. Sie hat einen Titel, einen Zurück-Weg und keinen künstlichen Rahmen.

6. Vier Muster, die immer wieder auftauchen

Das Modal im Modal. Aus dem Bearbeiten-Dialog öffnet sich eine Bestätigung, darüber eine Auswahl. Escape wird zum Glücksspiel, der Backdrop verdoppelt sich, und niemand weiß mehr, welcher Speichern-Knopf wozu gehört. Wenn eine zweite Ebene nötig scheint, ist meist schon die erste falsch gewählt. Der Ausweg: die untere Ebene zur Seite machen — oder die obere inline im Dialog darstellen statt als neue Ebene.

Bestätigen statt Rückgängig. Die Bestätigungsfrage ist bequem für uns und lästig für alle anderen. Wer sie zehnmal am Tag sieht, klickt sie weg, ohne sie zu lesen — und der Schutz ist genau dann weg, wenn er gebraucht würde. Wo es technisch geht, ist „Gelöscht. Rückgängig" für einige Sekunden das bessere Muster: kein Klick im Normalfall, volle Sicherheit im Ausnahmefall. Die Bestätigung bleibt für das, was wirklich nicht zurückholbar ist.

Datenverlust beim Schließen. Eingaben im Dialog ohne Absicherung sind eine Zeitbombe. Entweder der Hintergrundklick schließt nicht, oder es gibt eine Rückfrage, oder der Entwurf überlebt. Alles drei ist vertretbar; nichts davon zu tun ist es nicht.

Das Modal als Ausweg aus der Struktur. Das häufigste Muster von allen: Eine Funktion findet keinen Platz in der Navigation, also bekommt sie ein Overlay. Am Ende liegen sieben Funktionen in Overlays, keine davon ist verlinkbar, und die Startseite sieht aufgeräumt aus, weil die Hälfte des Produkts unsichtbar darunter liegt. Das ist kein Dialog-Problem, sondern eines der Informationsarchitektur — und es wird nur dort gelöst.

7. Ein Dialog im Design System, nicht zwanzig

Modals wuchern schneller als fast jedes andere Muster, weil sie so leicht einzeln zu bauen sind. Nach einem Jahr hat jedes Team seine eigene Variante: andere Breite, andere Schließen-Logik, andere Knopfreihenfolge. Dagegen hilft ein einziges dokumentiertes Bauteil mit wenigen Varianten.

• Größen statt Einzelfälle: zwei oder drei feste Breiten, eine definierte Maximalhöhe, Kopf- und Fußbereich fix, nur der Inhalt scrollt.
• Tokens statt Werte: Backdrop-Deckkraft, Radius, Schatten, Innenabstand und Maximalbreite kommen aus dem System — sonst driftet jede Instanz.
• Mobil ist eine Variante, kein eigenes Bauteil: dasselbe Bauteil, das unterhalb eines Breakpoints als Sheet erscheint.
• Bewegung kurz und abschaltbar: 150 bis 200 Millisekunden zum Öffnen, kürzer zum Schließen, und prefers-reduced-motion respektiert. Ein Dialog, der hereinspringt, wirkt bei der zehnten Nutzung nicht mehr lebendig, sondern langsam.
• Die Regel mitliefern: In die Dokumentation gehört nicht nur, wie das Bauteil aussieht, sondern wann es benutzt wird — und wann ausdrücklich nicht. Ohne diesen Absatz ist jedes Dialog-Bauteil eine Einladung.

Woran du merkst, dass ein Dialog nicht funktioniert

Man muss Modals nicht erraten, man kann sie beobachten. Drei Signale genügen meistens:

• Die Abbruchquote im Dialog: Wie viele öffnen ihn und schließen ihn ohne Ergebnis? Ein hoher Wert heißt selten „falsche Knopffarbe", sondern meistens: Die Entscheidung war hier nicht zu treffen, weil eine Information fehlte, die im Hintergrund steht.
• Das Wiederöffnen: Derselbe Dialog mehrfach kurz hintereinander bedeutet fast immer Hin- und Herspringen zwischen Overlay und Kontext — der stärkste Hinweis darauf, dass ein Panel das richtige Muster wäre.
• Die Rückgängig-Nutzung: Wo oft rückgängig gemacht wird, wurde die Bestätigung vorher weggeklickt, ohne gelesen zu werden. Das ist kein Argument gegen Rückgängig, sondern eines gegen die Bestätigung.

Tipp: Zähl einmal, wie viele Modals dein Produkt hat, und schreib hinter jedes in einem Satz, warum es unterbricht. Bei den Einträgen, wo der Satz nicht zustande kommt, steht die Antwort schon da.

Fazit

Modals sind kein schlechtes Muster. Sie sind ein sehr starkes Muster, das fast immer zu früh gezogen wird. Was in der Praxis trägt:

• Erst entscheiden, dann gestalten: Modal, Seite, Panel oder inline — diese Frage kostet fünf Minuten und spart später Wochen.
• Ein Dialog, eine Frage, zwei Verben: Alles, was mehr braucht, ist eine Seite.
• Tastatur und Fokus sind Pflicht, nicht Kür: Fokus setzen, halten, zurückgeben. Escape schließt. Hintergrund still.
• Mobil von unten denken: Sheet statt Kästchen, Tastaturhöhe einplanen, sichtbarer Ausweg neben der Geste.
• Rückgängig schlägt Bestätigen, überall dort, wo es technisch möglich ist.
• Ein Bauteil im System, mit Varianten, Tokens und einer dokumentierten Regel, wann es nicht benutzt wird.

Das beste Modal ist oft das, das nach der Vorfrage gar nicht mehr gebaut wird. Und das zweitbeste ist eines, das man mit der Tastatur genauso gut schließen kann wie mit der Maus.