Fast jede Software, die Sie nutzen, stellt Ihnen irgendwann ein Fenster in den Weg. Es dunkelt die Seite ab, sitzt mitten auf dem Bildschirm und lässt Sie nichts anderes anklicken, bis Sie darauf reagiert haben. Dieses Muster hat einen präzisen Namen, und der Name erklärt das Verhalten: Es ist ein Modal.
Der Begriff wird oft unscharf verwendet: Pop-up, Lightbox, Overlay, Dialog und Modal werden behandelt, als wären sie austauschbar. Das sind sie nicht, und genau dieser Unterschied ist das Wichtigste, was man über das Muster verstehen muss. Er macht ein Modal mächtig, wenn es passt, und unerträglich, wenn es nicht passt.
Dieser Leitfaden behandelt die Definition, die Herkunft des Wortes, die Modal-Typen, die Sie tatsächlich bauen werden, den Vergleich mit den benachbarten Mustern, die acht Regeln, die ein Modal erträglich machen, die Anforderungen an die Barrierefreiheit und die Fälle, in denen die richtige Anzahl an Modals null ist.
Das Wichtigste in Kürze
- Ein Modal blockiert. Die entscheidende Eigenschaft ist weder die Form noch das Overlay, sondern dass der Rest der Oberfläche unbenutzbar ist, bis das Modal erledigt ist.
- „Pop-up“ ist kein Synonym. Umgangssprachlich ist jedes Modal ein Pop-up; die meisten Pop-ups sind aber nicht modal, weil man um sie herum weiterarbeiten kann.
- Die Unterbrechung ist der Preis. Ein Modal verbraucht die Aufmerksamkeit des Nutzers sofort, also muss es etwas transportieren, das mehr wert ist als das, womit er gerade beschäftigt war.
- Ein Modal, eine Aufgabe. Sobald ein Modal zwei Hauptaktionen oder drei Absätze Erklärung hat, hätte es eine Seite, ein Tooltip oder eine Benachrichtigung sein sollen.
- Barrierefreiheit ist nicht optional. Fokusfalle, Schließen mit Escape,
role="dialog", zurückgegebener Fokus. Ein Modal, das sich nicht per Tastatur schließen lässt, hält Menschen gefangen. - Die meisten In-App-Nachrichten sollten keine Modals sein. Tooltips, Hotspots, Banner und Benachrichtigungs-Feeds decken die Mehrheit der Fälle ab, zu einem Bruchteil der Unterbrechungskosten.
Was ist ein Modal?
Modal: Definition
Ein Modal ist ein Fenster, das sich über der aktuellen Seite öffnet, den Hintergrund verdeckt oder abdunkelt und die Kontrolle über die Oberfläche übernimmt, bis die Person darauf reagiert. Solange es offen ist, lässt sich der Inhalt dahinter weder anklicken noch scrollen noch per Tab-Taste erreichen. Der Name beschreibt dieses Verhalten, nicht das Aussehen: Die Anwendung befindet sich vorübergehend in einem Modus, in dem eine einzige Frage das Einzige ist, was Sie beantworten dürfen.
Genau diese eine Eigenschaft, das Blockieren, unterscheidet ein Modal von allem anderen, was über einer Seite erscheint. Ein Cookie-Banner, das Sie beim Lesen ignorieren können, ist nicht modal. Eine Chat-Blase in der Ecke ist nicht modal. Ein Tooltip, der auf eine Schaltfläche zeigt, ist nicht modal. Ein Bestätigungsdialog, der fragt, ob Sie wirklich zwölf Datensätze löschen wollen, ist modal, denn Sie können nichts anderes tun, bis Sie geantwortet haben.
Ein Modal versteht man deshalb am besten als Tauschgeschäft. Sie nehmen sich die Aufmerksamkeit des Nutzers mit Gewalt und versprechen im Gegenzug, dass das Gezeigte wichtiger ist als das, womit er gerade beschäftigt war. Die meisten schlecht aufgenommenen Modals sind schlicht Tauschgeschäfte, bei denen die zweite Hälfte nie gestimmt hat.
Woher das Wort „Modal“ kommt
Der Begriff ist älter als das Web. In Desktop-Software konnte eine Oberfläche modal oder nicht modal (englisch „modeless“) sein. Ein nicht modales Fenster ließ Sie in der Hauptanwendung weiterarbeiten, während es offen blieb, zum Beispiel ein Suchen-und-Ersetzen-Panel. Ein modales Fenster sperrte die Anwendung, bis Sie es geschlossen hatten. Das Wort leitet sich von der Idee eines „Modus“ ab: eines vorübergehenden Zustands, in dem dieselben Eingaben etwas anderes bedeuten als sonst.
Deshalb beschreiben die Ausdrücke modales Fenster, modaler Dialog und Modal-Box alle dasselbe. „Fenster“ ist ein Überbleibsel aus Desktop-Betriebssystemen, in denen Dialoge tatsächlich eigene Fenster waren. Im Web ist das Modal nur ein Element, das auf einem Overlay über der Seite positioniert ist, doch das entlehnte Verhalten ist identisch.
Schnelltest: Wenn Sie dahinter noch etwas anklicken können, ist es kein Modal. Es könnte ein Popover, ein Toast, ein Banner oder ein Slideout sein: alle nützlich, alle günstiger und alle weiter unten erklärt.
Der Aufbau eines Modals
Fast jedes Modal besteht, egal wofür es gedacht ist, aus denselben sechs Teilen. Die Liste zu kennen lohnt sich, denn die meisten Probleme mit Modals entpuppen sich als fehlender oder doppelter Teil und nicht als Designproblem.
Die sechs Teile eines Modals. Die meisten Probleme mit Modals sind ein fehlender Teil, meist das Schließen-Element oder die einzige Hauptaktion, und kein Gestaltungsproblem.
Zwei der sechs Teile verdienen besondere Beachtung. Das Schließen-Element muss auch dann vorhanden sein, wenn Sie sicher sind, dass der Nutzer handeln sollte, denn ein Modal ohne Ausweg ist die am häufigsten gemeldete Form von Frust mit Oberflächen. Und die Zeile mit den Aktionen muss genau eine Hauptschaltfläche enthalten. Zwei Hauptaktionen sind keine Wahl, sondern ein Stillstand.
Die 6 Modal-Typen
Modals lassen sich einer kleinen Zahl erkennbarer Aufgaben zuordnen. Der Typ bestimmt fast alles andere: wie aufdringlich es sein darf, ob es mehr als einmal gezeigt werden darf und ob es überhaupt verdient, die Oberfläche zu blockieren.
-
Willkommens-Modal
Das Erste, was jemand nach der ersten Anmeldung sieht. Seine Aufgabe ist Lenken, nicht Begrüßen: bestätigen, wer die Person ist, höchstens eine Frage stellen, die den weiteren Ablauf verändert, und eine offensichtliche erste Aktion anbieten. Verwandt mit, aber nicht gleich einem vollständigen Willkommensbildschirm, der den gesamten Viewport einnehmen kann.
-
Bestätigungsdialog
Das ursprüngliche und am besten zu rechtfertigende Modal. Etwas Destruktives oder Unumkehrbares steht bevor, und das System möchte ein ausdrückliches Ja. Nennen Sie die Folge in der Überschrift („12 Datensätze löschen?“ schlägt „Sind Sie sicher?“) und beschriften Sie die Schaltfläche mit dem Verb statt mit „OK“.
-
Ankündigungs-Modal
Wird genutzt, um bestehenden Nutzern mitzuteilen, dass sich etwas geändert hat. Gerechtfertigt bei Änderungen, die die Arbeitsweise verändern; nicht gerechtfertigt bei jedem Release. Im Zweifel gehört die Nachricht in einen Feed oder ein Banner; wie Sie den Kanal wählen, lesen Sie unter eine neue Funktion ankündigen.
-
Formular- oder Aufgaben-Modal
Eine kurze, in sich geschlossene Aufgabe, die aus der Seite herausgelöst wird: ein Teammitglied einladen, ein Projekt umbenennen, einen Tarif wählen. Gut, wenn die Aufgabe weniger als etwa fünf Felder hat und der Seitenkontext dahinter nützlich ist. Schlecht, wenn sie zu einem Assistenten anwächst: Dann sollte sie eine Seite mit einer URL sein, zu der man zurückkehren kann.
-
Medien- oder Lightbox-Modal
Öffnet ein Bild, ein Video oder ein Dokument in größerer Darstellung über der Seite. Der am wenigsten umstrittene Typ, weil der Nutzer ihn per Klick angefordert hat. Escape und ein sichtbares Schließen-Element zählen hier mehr als irgendwo sonst, denn wer so etwas öffnet, erwartet, sofort wieder herauszukommen.
-
Tour-Schritt-Modal
Ein Schritt in einem geführten Walkthrough, der zu groß ist, um ihn an einem einzelnen Element zu verankern, typischerweise der erste und der letzte Schritt. Die mittleren Schritte einer guten Tour sind meist Tooltips. Echte Beispiele finden Sie in unseren Beispielen für Produkttour-Modals.
Ein Willkommens-Modal, das seine eigentliche Aufgabe erfüllt: eine Frage, deren Antwort verändert, was der Nutzer als Nächstes sieht, statt eines Einleitungsabsatzes.
Modal vs. Pop-up vs. Tooltip vs. Slideout vs. Banner
Die benachbarten Muster legen alle Inhalte über eine Seite. Was sie unterscheidet, ist, wie viel Aufmerksamkeit sie dem Nutzer abverlangen und ob sie sie sich mit Gewalt nehmen. Die Tabelle ist der schnellste Weg zur richtigen Wahl.
| Muster | Blockiert die Seite? | Aufmerksamkeitskosten | Einsetzen, wenn |
|---|---|---|---|
| Modal | Ja, nichts dahinter ist anklickbar | Am höchsten | Die Entscheidung jetzt fallen muss oder die Aufgabe volle Konzentration verdient |
| Popover / Dropdown | Nein, schließt sich beim Wegklicken | Niedrig | Zusätzliche Details oder Optionen zu einem bestimmten Bedienelement gehören |
| Tooltip | Nein | Sehr niedrig | Ein einzelnes Element direkt vor Ort erklärt werden soll, ohne den Ablauf zu stoppen |
| Slideout / Drawer | Manchmal, je nach Umsetzung | Mittel | Sekundäre Inhalte Platz brauchen, die Seite aber als Kontext erhalten bleiben soll |
| Banner / Benachrichtigungsleiste | Nein | Niedrig, und sinkt mit der Zeit weiter | Dauerhafte, nicht dringende Nachrichten später bearbeitet werden können |
| Toast | Nein, verschwindet von selbst | Am niedrigsten | Bestätigt werden soll, dass gerade etwas passiert ist |
Die praktische Regel, die sich aus dieser Tabelle ergibt: Beginnen Sie unten und gehen Sie nur nach oben, wenn Sie müssen. Die meisten In-App-Nachrichten, die als Modal ausgeliefert werden, hätten auch als Tooltip oder Banner funktioniert, und die als Banner ausgelieferten scheitern oft aus dem umgekehrten Grund: Die Menschen nehmen sie nicht mehr wahr, ein Problem, das unter Bannerblindheit behandelt wird.
Wann ein Modal das richtige Muster ist
Es gibt vier Situationen, in denen Unterbrechen wirklich die richtige Wahl ist, und es lohnt sich, dabei streng zu sein.
Löschen, Kündigen, vor Publikum Veröffentlichen, Geld ausgeben. Die Kosten eines versehentlichen Klicks übersteigen die Kosten der Unterbrechung.
Weniger als fünf Felder, in sich geschlossen und mit der Seite dahinter als Kontext besser aufgehoben als auf einem eigenen Bildschirm.
Erster Login, bevor irgendeine Arbeit begonnen hat. Noch wird nichts unterbrochen, und genau deshalb ist das Willkommens-Modal die eine Nachricht, die einen Freifahrtschein bekommt.
Er hat auf das Vorschaubild, die Schaltfläche „Einladen“ oder den Vorschau-Link geklickt. Ein auf Anfrage geöffnetes Modal ist überhaupt keine Unterbrechung.
Wer gerade mitten in einem Formular oder einem Ablauf steckt, schließt es ungelesen und ärgert sich danach ein wenig mehr über das Produkt als zuvor.
Webinare, Umfragen, kleine Releases und Upsells gehören in einen Feed, ein Banner oder eine E-Mail; die Alternativen finden Sie unter In-App-Messaging.
Modal UX Best Practices: 8 Regeln
Keine dieser Regeln ist eine Stilfrage. Jede beruht auf einer bestimmten Art, wie Modals in der Praxis schiefgehen.
- Ein Modal, eine Aufgabe
- Die Folge in der Überschrift nennen
- Immer einen Ausweg bieten
- Niemals Modals stapeln
- Ein Schließen respektieren
- Auf die Höhe achten, nicht nur auf die Breite
- Auf Mobilgeräten komplett neu denken
- Nach Verhalten auslösen, nicht nach der Uhr
1. Ein Modal, eine Aufgabe
Ein Modal sollte eine Frage stellen oder eine Aufgabe erledigen. Das deutlichste Symptom eines Modals, das zwei Aufgaben erfüllt, sind zwei Hauptschaltflächen, dicht gefolgt von einer Überschrift, die mit „und“ verbunden ist. Wenn Sie die Überschrift nicht als einen einzigen kurzen Satz schreiben können, will der Inhalt eine Seite sein.
2. Die Folge in der Überschrift nennen
„Sind Sie sicher?“ sagt dem Leser nichts, was er nicht schon wusste. „Diesen Workspace und seine 34 Dokumente löschen?“ lässt ihn entscheiden, ohne den Fließtext überhaupt zu lesen. Dasselbe gilt für Schaltflächen: Beschriften Sie sie mit dem Verb (Löschen, Veröffentlichen, Einladen), niemals mit OK. Unser Leitfaden zu UX-Microcopy enthält die Formeln für beides.
3. Immer einen Ausweg bieten
Ein sichtbares Schließen-Element, die Escape-Taste und ein Klick auf das Overlay sollten das Modal jeweils schließen. Die einzige legitime Ausnahme ist ein Modal mitten in einer destruktiven Bestätigung, bei dem der Klick auf das Overlay deaktiviert ist, um Versehen zu verhindern, und selbst dann bleiben Escape und die Schließen-Schaltfläche erhalten.
4. Niemals Modals stapeln
Ein Modal, das ein weiteres Modal öffnet, erzeugt zwei Overlays, zwei Fokusfallen und einen Nutzer, der keine Ahnung hat, was welcher Druck auf Escape bewirkt. Wenn ein Modal eine Folgefrage braucht, ersetzen Sie seinen Inhalt an Ort und Stelle und behalten Sie einen einzigen Container.
5. Ein Schließen respektieren
Wenn jemand ein Modal schließt, ist das eine Antwort. Es beim nächsten Seitenaufruf erneut zu zeigen, macht aus einem leichten Ärgernis einen Grund zu gehen. Gerade Onboarding-Modals sollten einmal gezeigt werden und danach nie wieder, es sei denn, die Situation des Nutzers ändert sich wirklich; die Logik dafür steckt in Onboarding-Triggern.
6. Auf die Höhe achten, nicht nur auf die Breite
Designer testen Modals auf hohen Bildschirmen. Auf einem Laptop mit Browser-Symbolleiste versteckt ein Modal, das intern scrollt, seine eigenen Aktionsschaltflächen, und der Nutzer sieht nicht, was er eigentlich anklicken soll. Begrenzen Sie die Höhe des Inhalts, lassen Sie nur den Textbereich scrollen und fixieren Sie die Aktionszeile.
7. Auf Mobilgeräten komplett neu denken
Ein zentrierter Dialog auf einem Smartphone ist eine bildschirmfüllende Übernahme, ob Sie ihn so gestaltet haben oder nicht. Machen Sie das zu einer bewussten Entscheidung: volle Breite, eine echte Kopfzeile mit einem Schließen-Element in Daumenreichweite und Aktionen untereinander statt nebeneinander.
8. Nach Verhalten auslösen, nicht nach der Uhr
„Nach 5 Sekunden anzeigen“ unterbricht jeden, der in Sekunde fünf gerade liest. Lösen Sie Modals stattdessen bei aussagekräftigen Ereignissen aus: ein erreichter leerer Zustand, eine zum ersten Mal geöffnete Funktion, ein erreichtes Tariflimit. Verhaltensbasiertes Timing verhindert außerdem, dass dasselbe Modal Nutzer erreicht, für die es nicht gedacht ist, und genau hier zahlt sich Nutzersegmentierung aus.
Barrierefreiheit von Modals: Die unverzichtbaren Punkte
Ein Modal ist eines der wenigen Muster, die einen Nutzer tatsächlich gefangen halten können. Wer per Tastatur oder Screenreader navigiert, erreicht unter Umständen die Schließen-Schaltfläche nicht oder kann nicht erkennen, dass die Seite dahinter inaktiv geworden ist. Die Anforderungen sind kurz, und es lohnt sich, sie als Checkliste zu behandeln statt als Wunschziel.
| Anforderung | Was das in der Praxis bedeutet |
|---|---|
| Als Dialog ankündigen | role="dialog" mit aria-modal="true" am Container |
| Einen Namen geben | aria-labelledby verweist auf das Überschriftenelement des Modals |
| Fokus hineinsetzen | Beim Öffnen die Überschrift oder das erste interaktive Element fokussieren, nicht die Seite dahinter |
| Fokus einschließen | Tab und Umschalt+Tab wandern nur innerhalb des Modals und erreichen nie den Hintergrund |
| Fokus beim Schließen zurückgeben | Der Fokus springt zurück zu dem Element, das das Modal geöffnet hat, damit der Nutzer seine Position behält |
| Mit Escape schließen | Immer, mit der einzigen Ausnahme einer laufenden destruktiven Bestätigung |
| Den Hintergrund verbergen | Die Seite dahinter als inaktiv markieren, damit assistive Technologien nicht durch das Overlay hindurch vorlesen |
| Scrollen im Hintergrund sperren | Das Scrollen der Seite hinter einem Modal ist auf dem Desktop verwirrend und auf Mobilgeräten kaputt |
Wenn Sie ein Onboarding bauen, das formale Anforderungen an die Barrierefreiheit erfüllen muss, finden Sie die weitergehenden Anforderungen (Kontrast, Bewegung, Timing, Tastaturbedienbarkeit über Touren und Checklisten hinweg) in unserem Leitfaden für barrierefreies Onboarding.
Modals: Do vs. Don't
Do
- Die Überschrift als Folge formulieren, nicht als Frage nach Gewissheit
- Genau eine Hauptaktion und eine zurückhaltende Abbrechen-Option behalten
- Nach Verhalten auslösen: ein Ereignis, ein Zustand, ein erreichtes Limit
- Onboarding-Modals einmal zeigen und dann dem Nutzer vertrauen
- Die mobile Version bewusst als bildschirmfüllendes Sheet gestalten
- Alles vor dem Livegang mit der Tastatur testen
Don't
- Jemanden mitten in einem Formular oder Ablauf unterbrechen
- Ein zweites Modal über das erste legen
- Das Schließen-Element verstecken, um eine Entscheidung zu erzwingen
- Ein Modal für Neuigkeiten nutzen, die in einen Feed passen würden
- Den Inhalt über die Aktionsschaltflächen hinaus scrollen lassen
- Ein bereits geschlossenes Modal erneut anzeigen
So erstellen Sie Modals ohne Code mit Kompassify
Die meisten Modals, die ein Produkt nach dem Launch braucht, sind keine Produktfunktionen, sondern Nachrichten: ein Willkommens-Modal für ein neues Segment, eine Ankündigung zu einer Änderung, die jemandes Arbeitsablauf verändert, der Eröffnungsschritt eines Walkthroughs. Jedes davon als Komponente zu bauen, in einem Release auszuliefern und in einem anderen wieder zu entfernen, ist der Grund, warum so viele davon nie gebaut werden, und warum die, die gebaut werden, noch lange live bleiben, nachdem sie ihre Relevanz verloren haben.
Kompassify verlagert diese Ebene aus der Codebasis heraus. Sie erstellen das Modal visuell, legen mit Segmentierungsregeln fest, wer es sieht, lösen es bei einem echten Ereignis statt nach einem Timer aus und stellen ein, dass es nur einmal erscheint. Jedes Modal zeigt, wie viele Menschen es gesehen, geschlossen und darauf reagiert haben, sodass die Entscheidung, es zu behalten oder zu entfernen, auf Daten beruht und nicht darauf, wer sich noch an seine Existenz erinnert. Derselbe Builder deckt auch die günstigeren Muster ab (Tooltips, Hotspots, Checklisten, In-App-Ankündigungen), und das ist wichtig, denn die ehrliche Antwort auf „Sollte das ein Modal sein?“ lautet meistens Nein.
Ein Ankündigungs-Modal, erstellt ohne Release. Weil es außerhalb der Codebasis lebt, ist das Abschalten ein Schalter und kein Ticket.
Erstellen Sie Ihr erstes Modal, ganz ohne Engineering-Ticket
Mit Kompassify erstellen Produkt-, Onboarding- und Customer-Success-Teams Modals, Tooltips, Checklisten und In-App-Ankündigungen visuell, steuern sie nach Segment und Verhalten aus und messen, was jede einzelne bewirkt hat. Kostenlos bis 100 monatlich aktive Nutzer, Tarife ab $129/Monat, DSGVO-konform und in der EU gehostet.
Kostenlos starten →Die Kurzfassung in einem Satz
Ein Modal ist ein Fenster, das alles andere anhält, bis es beantwortet ist, und damit das stärkste Muster, das Sie haben, das teuerste, das Sie einsetzen können, und die falsche Antwort auf die meisten Fragen, für die es verwendet wird.
Häufig gestellte Fragen
Was ist ein Modal?
Ein Modal ist ein Fenster, das sich über der aktuellen Seite öffnet, den Hintergrund abdunkelt oder verdeckt und die Kontrolle über die Oberfläche übernimmt, bis die Person darauf reagiert. Solange es offen ist, lässt sich der Rest der Seite weder anklicken noch scrollen noch per Tab-Taste erreichen. Das Wort beschreibt dieses Verhalten, nicht das Aussehen: Ein Modal versetzt die Anwendung in einen vorübergehenden Modus, in dem eine einzige Frage das Einzige ist, was Sie beantworten können. Deshalb sind ein Bestätigungsdialog, ein Willkommensfenster beim ersten Login und ein bildschirmfüllender Upgrade-Hinweis allesamt Modals, obwohl sie völlig unterschiedlich aussehen.
Was ist der Unterschied zwischen einem Modal und einem Pop-up?
Pop-up ist ein lockerer, umgangssprachlicher Begriff für alles, was über einer Seite erscheint, einschließlich per Skript geöffneter Browserfenster, Cookie-Hinweise, Chat-Blasen und Werbung. Modal ist ein präziser Fachbegriff: Der Inhalt blockiert die Interaktion mit allem dahinter, bis er geschlossen wird. Jedes Modal lässt sich als Pop-up bezeichnen, aber die meisten Dinge, die Menschen Pop-ups nennen, sind nicht modal, weil man die Seite drumherum weiter nutzen kann. In der Produktarbeit ist die Unterscheidung wichtig, weil das Blockieren der Oberfläche der teure Teil ist und begründet werden muss.
Was ist ein modales Fenster im Webdesign?
Ein modales Fenster ist das sichtbare Element selbst: ein meist zentriertes Panel auf einem abgedunkelten Overlay, das die Seite bedeckt. Im Markup ist es normalerweise ein Container mit role="dialog" und aria-modal="true", einem zugänglichen Namen aus seiner Überschrift, einer Fokusfalle, die den Tastaturfokus darin hält, und einem Schließen-Element. Modales Fenster, modaler Dialog und Modal-Box bezeichnen alle dasselbe Muster; das Wort Fenster ist einfach aus Desktop-Software entlehnt, wo Dialoge tatsächlich eigene Betriebssystemfenster waren.
Sind Modals schlechte UX?
Modals sind nicht von Natur aus schlecht, sie sind teuer. Jemanden zu unterbrechen ist gerechtfertigt, wenn die Botschaft wirklich wichtiger ist als das, was die Person gerade tat: eine destruktive Aktion, die bestätigt werden muss, eine kurze fokussierte Aufgabe oder eine Begrüßung beim ersten Start, die den Rest der Sitzung vorbereitet. Schlechte UX wird daraus, wenn die Unterbrechung dem Unternehmen dient statt dem Nutzer, wenn sie mitten in einer Aufgabe auslöst, wenn sie nach dem Schließen erneut erscheint oder wenn der Inhalt auch ein Tooltip, ein Banner oder ein Eintrag in einem Benachrichtigungs-Feed hätte sein können.
Was ist ein Willkommens-Modal?
Ein Willkommens-Modal ist das Modal, das beim ersten Anmelden in einem Produkt erscheint. Seine Aufgabe ist nicht, Hallo zu sagen, sondern zu lenken: bestätigen, dass die Person am richtigen Ort ist, höchstens ein oder zwei Fragen stellen, die verändern, was sie als Nächstes sieht, und ihr eine einzige offensichtliche Aktion anbieten, etwa eine kurze Tour zu starten oder das erste Element anzulegen. Es sollte einmal erscheinen, sich ohne Nachteile schließen lassen und niemals als Behälter für eine Funktionsliste dienen, nach der niemand gefragt hat.
Wie macht man ein Modal barrierefrei?
Geben Sie dem Container role="dialog" und aria-modal="true", benennen Sie ihn über aria-labelledby mit seiner Überschrift, verschieben Sie den Tastaturfokus beim Öffnen in das Modal und geben Sie ihn beim Schließen an das auslösende Element zurück, halten Sie Tab und Umschalt+Tab darin gefangen, damit der Fokus nicht hinter das Overlay wandert, schließen Sie es mit der Escape-Taste, verbergen Sie den Hintergrund vor assistiven Technologien und sperren Sie das Scrollen im Hintergrund. Ein Modal, das sich nicht per Tastatur schließen lässt, ist nicht nur umständlich: Es hält manche Nutzer auf der Seite gefangen.