Modal und Pop-up gestalten: wann und wie?

Kurz gesagt

Ein Modal ist ein Fenster, das sich über der Seite öffnet und den Inhalt dahinter sperrt, bis der Nutzer antwortet. Nutzen Sie ein Modal vor einer nicht umkehrbaren Aktion oder um eine Aufgabe fortzusetzen, die der Nutzer begonnen hat. Zeigen Sie kein Pop-up, sobald die Seite lädt. Ein gutes Modal schließt mit Esc und einem sichtbaren Schließen-Button. Es hält den Fokus in sich und gibt ihn beim Schließen an den Button zurück, der es geöffnet hat.

Kurz gesagt

Ein Modal ist die strengste Form eines Fensters. Die Seite dahinter lässt sich nicht nutzen, bis es geschlossen ist. NN/g beschreibt es kurz: Modals unterbrechen den Nutzer und verlangen eine Aktion.

Pop-up ist ein breiterer Begriff. Im Alltag nennt man so auch Newsletter-Fenster, Aktionskästen und Chat-Blasen. Auf dieser Seite behandle ich beides zusammen, weil die Probleme an derselben Stelle entstehen.

Cookie-Banner sind nicht Thema dieser Seite, für sie gelten andere Regeln. Dazu gibt es das Muster Cookie-Banner.

Wann nutzt man ein Modal, wann nicht?

Die kurze Antwort: Muss der Nutzer die Entscheidung in diesem Moment treffen, ein Modal, sonst die Seite selbst. Der NN/g-Artikel von Therese Fessenden nennt die Kosten eines Modals offen. Ein Modal stoppt die aktuelle Aufgabe und gibt dem Nutzer ein weiteres Ziel. Außerdem kann es wichtige Inhalte verdecken und den Kontext entfernen.

Derselbe Artikel nennt vier Fälle, in denen ein Modal passt. Der erste sind Warnungen, die kritische Fehler verhindern, der zweite Informationen, die für die laufende Aufgabe nötig sind. Eine komplexe Aufgabe in Schritte zu teilen und eine Frage zu stellen, die dem Nutzer deutlich Arbeit spart, stehen ebenfalls auf der Liste. In den Karten unten teile ich die Fälle, die mir am häufigsten begegnen, in zwei Gruppen: nutzen und nicht nutzen.

  • Nutzen

    Vor einer nicht umkehrbaren Aktion

    „Wenn Sie diese Adresse löschen, verschwindet sie auch aus Ihren gespeicherten Bestellungen.“ Auch der Moment, in dem ungespeicherte Änderungen verloren gingen, gehört dazu.

  • Nutzen

    Wenn eine Aufgabe des Nutzers an fehlenden Angaben hängt

    Ein Nutzer will ein Produkt merken, ist aber nicht angemeldet. Ihm ein Anmeldefenster zu öffnen, ist ein Beispiel dafür.

  • Nicht nutzen

    Für Informationen ohne Bezug zum Ablauf

    Newsletter-Anmeldung oder der Hinweis, die App herunterzuladen, sind Beispiele. Sie können als Streifen oder Karte auf der Seite stehen.

  • Nicht nutzen

    Mitten in einem kritischen Ablauf wie der Bezahlung

    Ein Aktionsfenster im Bezahlschritt lenkt ab und kann das Vertrauen des Nutzers erschüttern.

Zeigen Sie auch Formularfehler nicht im Modal. NN/g empfiehlt, einen Fehler im Formular auf der Seite neben der Stelle zu zeigen, an der er entstanden ist. Wie Sie den Fehlertext schreiben, steht im Muster Fehlermeldungen.

Für den Bezahlablauf gibt es eine eigene Warnung. Fessenden empfiehlt, Modals zu vermeiden, die riskante Abläufe wie die Bezahlung unterbrechen. Ein unnötiges Modal lenkt bestenfalls ab und erschüttert schlimmstenfalls das Vertrauen. Weitere Wege, diese Schritte schlicht zu halten, habe ich im Muster Checkout gesammelt.

Braucht es kein Modal, wählen Sie ein nicht modales Fenster oder einen Bereich auf der Seite. Denken Sie an das Fenster für eine neue E-Mail: Während Sie schreiben, können Sie den Inhalt dahinter weiterlesen.

Der Zeitpunkt: Pop-up beim Laden der Seite

Das erste Problem ist der Zeitpunkt. Laut dem NN/g-Artikel von Anna Kaley unterbricht ein Pop-up, das beim Laden der Seite erscheint, den Nutzer, bevor er einen Wert gesehen hat. Kaley lässt nur eine Ausnahme gelten: wenn die Website rechtlich verpflichtet ist, eine Cookie-Einwilligung einzuholen oder das Alter zu prüfen.

Kaleys Empfehlung: Zeigen Sie das Pop-up, wenn der Inhalt für den Nutzer Bedeutung bekommen hat. Fragen Sie nach dem Newsletter, nachdem ein Artikel gelesen wurde. Öffnen Sie die Feedback-Umfrage, wenn der Nutzer seine Hauptaufgabe erledigt hat.

Kaley nennt weitere verbreitete Fehler:

  • Ein Pop-up direkt nach dem Login unterbricht den nächsten Schritt des Nutzers.
  • Mehrere Pop-ups auf einmal muss man einzeln schließen. Zeigen Sie immer nur ein Fenster.
  • Statt einer Umfrage mitten in einer kritischen Aufgabe reicht ein fester Feedback-Link am Rand der Seite.

Auch Kathryn Whitenton sagt bei NN/g Ähnliches. Am sichersten ist es nach ihr, das Fenster nach einem Klick des Nutzers oder für wirklich dringende Meldungen zu öffnen. Eines ihrer Beispiele ist ein Fenster, das erscheint, wenn der Besucher die Website gerade verlassen will, und ihn deshalb nicht unterbricht.

Es gibt auch die Seite der Suche. Google Search Central sagt, dass Zwischenseiten und Fenster, die den Inhalt verdecken, zu schwacher Suchleistung führen können. Stattdessen empfiehlt Google Banner, die nur einen kleinen Teil des Bildschirms einnehmen.

Wege zum Schließen: X, Esc und Klick daneben

Wenn Sie ein Modal öffnen, machen Sie auch das Schließen leicht. Whitenton verlangt zwei Dinge ausdrücklich: einen sichtbaren Schließen-Befehl und die Esc-Taste für Tastaturnutzer.

Das Schließen per Klick daneben kann nur ein zusätzlicher Weg sein. Laut Whitenton kennen viele Nutzer ihn nicht. Auf Touchscreens kann sich das Fenster außerdem versehentlich schließen, setzen Sie deshalb in Fenster, die Angaben abfragen, zusätzlich einen Button Abbrechen.

Das Kreuz klein und blass zu zeichnen, ist meiner Meinung nach oft eine bewusste Entscheidung. Schließen-Texte, die den Nutzer beschämen, wie „Nein, ich will keinen Rabatt“, gehören zur selben Familie. Solche Tricks sammle ich im Ratgeber zu Dark Patterns. Die Maße für die tippbare Fläche des Kreuzes finden Sie im Muster Tippbereich.

Esc hat auch eine Seite der Barrierefreiheit. Kriterium 2.1.2 Keine Tastaturfalle der WCAG 2.2 liegt auf Stufe A. Laut Erläuterung des W3C verstößt es nicht gegen das Kriterium, den Fokus im Modal zu halten, solange der Nutzer weiß, wie er hinauskommt. Das W3C nennt Esc als verbreiteten Standardweg hinaus.

Fokusfalle und Rückgabe des Fokus

Öffnet sich ein Fenster, sieht unser Auge es. Wer Tastatur und Screenreader nutzt, sieht dagegen das, wohin der Fokus geht. Der WAI-ARIA Authoring Practices Guide (APG) des W3C beschreibt für ein modales Fenster dieses Verhalten:

  1. Beim Öffnen geht der Fokus hinein. Meist auf das erste fokussierbare Element. Bei langem Inhalt kann er auf ein festes Element oben gehen, bei einer nicht umkehrbaren Aktion auf die am wenigsten schädliche Option.
  2. Tab kreist innen. Auf dem letzten Element springt der Fokus mit Tab zum ersten, auf dem ersten mit Shift+Tab zum letzten.
  3. Esc schließt.
  4. Beim Schließen geht der Fokus zum öffnenden Element zurück. Gibt es das Element nicht mehr, geht er zu einem anderen, das zum Ablauf passt.

Außerdem verlangt das APG für das Fenster role="dialog", aria-modal="true" und ein aria-labelledby, das auf den sichtbaren Titel verweist. aria-modal sollte nur verwendet werden, wenn alle Interaktionen außerhalb wirklich gesperrt sind und der Bereich außerhalb visuell verdeckt ist.

Heute erledigt der Browser das meiste davon selbst. Laut MDN wird beim Öffnen eines <dialog>-Elements mit showModal() der Rest der Seite inaktiv, und Esc schließt das Fenster. Der Fokus geht auf das erste fokussierbare Element im Inneren.

Die Rückgabe des Fokus schreibe ich aber immer selbst. Dafür reicht das kleine Beispiel unten:

<button type="button" id="oeffnen">Newsletter abonnieren</button>

<dialog id="newsletter" aria-labelledby="newsletter-titel">
  <h2 id="newsletter-titel">Newsletter abonnieren</h2>
  <button type="button" id="schliessen" aria-label="Schließen">×</button>
  ...
</dialog>

<script>
  const oeffnen = document.getElementById('oeffnen');
  const d = document.getElementById('newsletter');
  oeffnen.addEventListener('click', () => d.showModal());
  document.getElementById('schliessen')
    .addEventListener('click', () => d.close());
  d.addEventListener('close', () => oeffnen.focus());
</script>

Ausprobieren: schlechtes Modal, gutes Modal

Beide Modals zeigen denselben Newsletter-Kasten. Der Unterschied zeigt sich, wenn man sie mit der Tastatur bedient. Öffnen Sie zuerst das schlechte und drücken Sie Tab, vergleichen Sie dann mit dem guten.

Schlechtes Modal, gutes Modal

Neue Saison bei Wintermänteln

Das ist die Seite hinter dem Modal. Ist das schlechte Modal offen, führt Sie Tab durch die Buttons hier.

Dieses Beispiel braucht JavaScript. Ist es aus, sehen Sie nur die Beispielseite hinter dem Modal.

Newsletter abonnieren

Wir schicken einmal pro Woche eine E-Mail. Sie können sich jederzeit abmelden.

Das schlechte Modal hat die Fehler, die ich in Audits oft sehe. Es holt den Fokus nicht hinein und schließt nicht mit Esc. Und das Kreuz ist klein. Das gute Modal ist mit dem eingebauten dialog-Element gebaut und folgt dem APG-Muster. Auf schmalen Screens öffnet es im Vollbild. Beispiel-Shop und Texte stammen von mir. Es werden keine Daten gesendet.

Beim schlechten Modal wandert der Fokus über die Buttons der verdeckten Seite. Ein Screenreader-Nutzer hört vielleicht nie, dass sich das Modal geöffnet hat. Beim guten Modal schließen Esc, Schließen, Abbrechen und ein Klick daneben bei leerem Feld das Fenster. Jedes Mal geht der Fokus zum öffnenden Button zurück.

Vollbild auf dem Handy

Der kleine Kasten in der Mitte des Desktop-Screens macht auf dem Handy oft Probleme. Whitenton schreibt, dass Fenster, deren Schließen-Elemente über den Bildschirm hinausragen oder die das Zoomen verhindern, den Inhalt komplett sperren können. Auch das Abschalten des Scrollens kann dazu führen, dass der Nutzer die Bedienelemente nicht erreicht.

Auch Fessendens Artikel hat ein Beispiel. Ein nicht modales Fenster am Desktop wird auf dem Handy zum modalen Vollbild. Dieselbe Komponente kann sich je nach Screen anders verhalten. Gestalten Sie das von Anfang an bewusst.

Meine Präferenz: Ein Modal mit Formular öffnet auf schmalen Screens im Vollbild. Titel und Schließen-Button stehen ganz oben, der Hauptbutton ist voll breit. Das gute Modal oben verhält sich unter 600 Pixeln so. Damit die Felder bei offener Handytastatur sichtbar bleiben, siehe das Muster Tastatur in mobilen Formularen.

Meine Notiz

Das häufigste Modal-Problem in meinen Audits ist der Zeitpunkt. Kaum ist man auf der Startseite, öffnet sich das Newsletter-Fenster, und nach dem Schließen erscheint die Chat-Blase. Der Nutzer hat zwei Fenster geschlossen, bevor er das Produkt sieht.

Danach kommt die Rückgabe des Fokus. Das Fenster öffnet sauber und schließt mit Esc, aber der Fokus fällt an den Anfang der Seite. Wer mit der Tastatur navigiert, muss die Stelle, an der er war, von vorn suchen.

Auch das kleine Kreuz steht weit oben auf der Liste. In der Designdatei wird es als kleines Icon gezeichnet und bleibt im Code in dieser Größe. Auf dem Handy braucht man mit dem Daumen mehrere Versuche.

Um das zu finden, braucht es kein spezielles Tool. Lassen Sie die Maus los und versuchen Sie, Ihre Aufgabe im Fenster nur mit Tab, Shift+Tab, Enter und Esc zu erledigen. Wiederholen Sie den Versuch dann auf dem Handy mit einer Hand.

Und ich empfehle: Fragen Sie vor jedem neuen Modal, ob derselbe Inhalt nicht auf der Seite stehen kann. Nach meiner Erfahrung lautet die Antwort meist ja.

Checkliste

Bevor ich einem Produkt ein Modal hinzufüge, gehe ich diese Liste durch. Wenn ich die Fenster in Ihrem Produkt prüfen soll: Der UX Audit deckt das ab.

  • Das Modal öffnet sich für eine Entscheidung, die der Nutzer jetzt treffen muss.
  • Es öffnet sich nicht beim Laden der Seite, sondern nach einer Aktion des Nutzers.
  • Es gibt immer nur ein Fenster.
  • Es gibt einen sichtbaren Schließen-Button mit ausreichend großer tippbarer Fläche.
  • Esc schließt das Fenster.
  • In einem Fenster, das Angaben abfragt, gibt es zusätzlich einen Button Abbrechen.
  • Beim Öffnen geht der Fokus in das Fenster.
  • Tab und Shift+Tab kreisen im Fenster.
  • Beim Schließen geht der Fokus zum öffnenden Element zurück.
  • Das Fenster hat einen sichtbaren Titel, verbunden über aria-labelledby.
  • Auf schmalen Screens ragt der Schließen-Button nicht über den Bildschirm hinaus.

Häufige Fragen

Was ist der Unterschied zwischen Modal und Pop-up?

Ein Modal ist ein Fenster, das die Seite dahinter unbenutzbar macht, bis es geschlossen wird. Pop-up ist ein breiterer Begriff und meint auch kleine Fenster, die die Seite nicht sperren. Jedes Modal ist ein Pop-up, aber nicht jedes Pop-up ist ein Modal.

Sollte sich ein Modal beim Klick daneben schließen?

Es kann, aber das darf nicht der einzige Weg sein. NN/g schreibt, dass viele Nutzer diesen Weg nicht kennen und sich das Fenster auf Touchscreens versehentlich schließen kann. Ein sichtbarer Schließen-Button und die Esc-Taste müssen immer da sein.

Ist es eine Tastaturfalle, den Fokus im Modal zu halten?

Nein, solange der Nutzer per Tastatur hinauskommt. Die Erläuterung des W3C zu 2.1.2 sagt, dass der Fokus in einem Modal gehalten werden darf, solange der Nutzer weiß, wie er herauskommt. Esc ist ein verbreiteter Standardweg hinaus.

Steigert ein Newsletter-Pop-up beim Laden der Seite nicht die Conversion?

Das wissen Sie nicht, ohne es zu messen. NN/g warnt davor, Nutzer zu unterbrechen, bevor sie den Inhalt gesehen haben. Auch Google sagt, dass Fenster, die den Inhalt verdecken, zu schwacher Suchleistung führen können. Ich empfehle, die Frage zu stellen, nachdem der Nutzer einen Artikel gelesen hat.

Quellen (7)
  1. Therese Fessenden, Modal & Nonmodal Dialogs: When (& When Not) to Use Them, Nielsen Norman Group. 23. April 2017; Kosten eines Modals, passende und unpassende Fälle, Fenster wird auf dem Handy zum Vollbild
  2. Anna Kaley, Popups: 10 Problematic Trends and Alternatives, Nielsen Norman Group. 30. Juni 2019; Zeitpunkt und Alternativen
  3. Kathryn Whitenton, Overuse of Overlays: How to Avoid Misusing Lightboxes, Nielsen Norman Group. 25. Mai 2015; Schließen-Befehl, Esc, Klick daneben, mobil
  4. W3C WAI, Dialog (Modal) Pattern, ARIA Authoring Practices Guide. abgerufen am 3.11.2026; Tastaturinteraktion, Fokus, Rollen
  5. MDN Web Docs, <dialog>: The Dialog element. abgerufen am 3.11.2026; showModal(), Esc, erster Fokus
  6. W3C, Understanding Success Criterion 2.1.2: No Keyboard Trap (WCAG 2.2). Stufe A; Fokus im Modal
  7. Google Search Central, Avoid intrusive interstitials and dialogs. abgerufen am 3.11.2026