FigmaOpenCode

Dialog

Synonyme: Modal, Overlay, Popup, Modaler Dialog
Ähnliche Komponenten: Alert, Accordion

Kurzbeschreibung

Ein Dialog dient der Kommunikation mit Nutzenden, übermittelt wichtige Informationen und fordert Eingaben, Bestätigungen oder Entscheidungen durch Interaktion.

Beispiele

Default

Code anzeigen

<dialog id="modal1" class="kern-dialog" aria-labelledby="modal1_heading" open>
<header class="kern-dialog__header">
  <h2 class="kern-title kern-title--large" id="modal1_heading">Frage?</h2>
  <button class="kern-btn kern-btn--tertiary">
    <span class="kern-icon kern-icon--close" aria-hidden="true"></span>
    <span class="kern-sr-only">Schließen</span>
  </button>
</header>
<section class="kern-dialog__body">
  <p class="kern-body">
   Die Beschreibung liefert mehr Kontext, z.&#8239;B. um vor kritischen Aktionen eine bewusste Bestätigung des Nutzenden zu erhalten.
  </p>
</section>
<footer class="kern-dialog__footer">
  <button class="kern-btn kern-btn--secondary">
    <span class="kern-label">Abbrechen</span>
  </button>
  <button id="confirmBtn" class="kern-btn kern-btn--primary">
    <span class="kern-label">Speichern</span>
  </button>
</footer>
<!-- only for displaying it properly on documentation page -->
 <style>#modal1 { position: relative}</style>
</dialog>

Variante

Code anzeigen

<dialog id="modal2" class="kern-dialog" aria-labelledby="modal2_heading" open>
<header class="kern-dialog__header">
  <h2 class="kern-title kern-title--large" id="modal2_heading">Information</h2>
  <button class="kern-btn kern-btn--tertiary">
    <span class="kern-icon kern-icon--close" aria-hidden="true"></span>
    <span class="kern-sr-only">Schließen</span>
  </button>
</header>
<section class="kern-dialog__body">
  <p class="kern-body">
  Die Beschreibung liefert mehr Kontext. Es kann nur mit einem Button zugestimmt werden, es ergeben sich keine unumkehrbaren Konsequenzen.
  </p>
</section>
<footer class="kern-dialog__footer">
  <button id="confirmBtn" class="kern-btn kern-btn--primary">
    <span class="kern-label">Verstanden</span>
  </button>
</footer>
<!-- only for displaying it properly on documentation page -->
 <style>#modal2 { position: relative}</style>
</dialog>

Beschreibung

Ein Dialog erscheint vorübergehend, um die Interaktion zwischen der Anwendung und dem Nutzenden zu ermöglichen.

Ein Dialog überlagert den Hauptinhalt und erfordert eine bewusste Handlung oder Aufmerksamkeit des Nutzenden. Er kann modal sein, was bedeutet, dass er den Fokus vollständig einfängt und Nutzende zur Interaktion zwingt. Alternativ kann er auch non-modal sein, wodurch der Hauptinhalt weiterhin zugänglich bleibt.

Ein Dialog besteht aus einem Titel und einer Beschreibung. Optional können auch andere Komponenten im Body-Bereich platziert werden. Schaltflächen müssen mindestens zwei klare Optionen bieten, wenn es um eine Entscheidung geht: eine primäre Aktion (z. B. „Speichern“) und eine sekundäre (z. B. „Abbrechen“), um Entscheidungen zu erleichtern. Handelt es sich um eine Information, die nur bestätigt werden muss, kann auch nur ein sekundärer Button (z. B. „Verstanden”) ausreichen. Falls nötig, kann auch ein dritter, tertiärer Button eingeblendet werden, dies sollte aber die Ausnahme sein, um die Entscheidung für Nutzende zu vereinfachen.
Bei Desktop-Anwendungen empfiehlt es sich, die Buttons nebeneinander anzuordnen. Im mobilen Kontext ist dies mit zwei Buttons bei kurzen Labels ebenfalls möglich, es besteht jedoch auch die Option, die Buttons vertikal anzuordnen. Außerdem empfiehlt sich ein optionaler Schließen-Button als „X“-Symbol oben rechts einzublenden. Bei langen Inhaltsblöcken kann ein Dialog auch scrollbar sein, dies sollte jedoch vermieden werden.

Verwendungsregeln

Verwende einen Dialog nur, wenn sofortige Entscheidungen oder Eingaben benötigt werden. Dialoge sollten gezielt und sparsam eingesetzt werden, um den Arbeitsfluss der Nutzenden nicht zu stören. Sie sind ein stark aufdringliches Muster und sollten daher nur für wichtige, zeitkritische oder irreversible Aktionen genutzt werden. Alternativen wie Inline-Komponenten oder Tooltips sind vorzuziehen, wenn die Unterbrechung nicht notwendig ist.

Ein Dialog hat eine klare und intuitive Struktur, um den Nutzenden gezielt zu führen. Der Titel fasst den Zweck des Dialogs zusammen und gibt den Kontext der Aktion wieder. Die Beschreibung sollte prägnant und informativ sein und erklären, was von den Nutzenden erwartet wird. Ein Dialog ist auf kleine Informationsmengen optimiert. Lange oder komplexe Inhalte wie mehrstufige Formulare oder ausführliche Anleitungen gehören nicht in einen Dialog. Für solche Fälle nutze separate Seiten oder Panels.

Es sollten immer alternative Schließmöglichkeiten angeboten werden, damit Nutzende den Dialog bewusst schließen können – beispielsweise über ein „X“-Symbol oben rechts und die Escape-Taste. Das Schließen durch Overlay-Klicks sollte bei kritischen Dialogen vermieden werden, um versehentliche Aktionen auszuschließen.

Dialoge können unterschiedliche Anwendungsfälle abdecken. Hier ein paar Beispiele:

Informationsdialoge

• Verwendung: Um die Nutzende über eine Aktion zu informieren. - Beispiel: „Speichern erfolgreich“. - Empfehlung: Nicht-modal, Overlay-Klick zum Schließen erlaubt.

Bestätigungsdialoge

• Verwendung: Um vor kritischen Aktionen eine bewusste Bestätigung zu verlangen. - Beispiel: „Möchten Sie das Formular ohne zu speichern verlassen?“ - Empfehlung: Modal, Overlay-Klick sollte den Dialog nicht schließen.

Eingabedialoge

• Verwendung: Abfrage von Informationen. - Beispiel: Formulareingaben oder Einstellungen - Empfehlung: Modal oder non-modal je nach Kontext, Overlay-Klick sollte nicht zum Schließen führen, wenn Daten verloren gehen könnten.

Gefahrendialoge

• Verwendung: Weist auf irreversible Aktionen hin. - Beispiel: „Möchten Sie die Datei dauerhaft löschen?“ - Empfehlung: Modal, keine Overlay-Schließung, deutliche Warnung.

Dos und Don’ts

• Verwende nicht-modale Dialoge für unterstützende Informationen, die den Arbeitsfluss nicht stören.
• Stelle sicher, dass die Nutzenden immer eine bewusste Aktion ausführen können, um den Dialog zu schließen.
• Kommuniziere klar den Zweck des Dialogs mit eindeutigen Überschriften und Schaltflächen.
• Biete spezifische und eindeutige Beschriftungen für Schaltflächen an (z. B. „Speichern“, „Abbrechen“).
• Nutze keine sticky Elemente, wie Header oder Footer, da sie bei vergrößerter Nutzung Inhalte überlagern können.
• Halte den Inhalt eines Dialogs knapp, scrollen sollte die Ausnahme sein.

Dialog mit Javascript öffnen

Ein Dialog kann durch einen Button geöffnet werden, wobei Datenattribute (data-dialog-target) verwendet werden, um die Buttons mit den Dialogen zu verbinden.

HMTL

<button data-dialog-target="modal2" class="kern-btn kern-btn--primary">Open Dialog</button>

JavaScript

document.querySelectorAll('[data-dialog-target]').forEach(button => {
	const dialogId = button.getAttribute('data-dialog-target');
	const dialog = document.getElementById(dialogId);

	if (dialog) {
		button.addEventListener('click', () => dialog.showModal());
		dialog.addEventListener('click', event => {
			if (event.target === dialog) {
				dialog.close();
			}
		});
		const submitButton = dialog.querySelector('button[type="submit"]');
		if (submitButton) {
			submitButton.addEventListener('click', event => {
				event.preventDefault();
				console.log('Absenden-Button wurde geklickt!');
				dialog.close();
			});
		}
	}
});

Verhalten

• Der Button mit data-dialog-target öffnet den entsprechenden Dialog.
• Der Dialog kann über den Schließen-Button oder durch einen Klick auf den Hintergrund geschlossen werden.

Hinweise

1. Einsatz des <form>-Elements im Dialog

• Das <form>-Element strukturiert die Dialoginteraktionen und ermöglicht native Browser-Funktionen wie das Schließen eines Dialogs durch Buttons mit formmethod="dialog".
• Es erleichtert die Handhabung von Formularen innerhalb des Dialogs, z. B. für Bestätigungs- oder Abbruchaktionen.

2. Verwendung des autofocus-Attributs

• Das autofocus-Attribut sorgt dafür, dass ein spezifisches Eingabeelement (z. B. ein Textfeld) oder ein Button automatisch fokussiert wird, sobald der Dialog geöffnet wird.
• Dies verbessert die Benutzerfreundlichkeit, indem z. B. der Cursor direkt in ein Eingabefeld gesetzt oder ein primärer Button hervorgehoben wird.
• Es ist besonders nützlich, um den Fokusfluss in Dialogen intuitiv zu steuern, ohne dass zusätzliche JavaScript-Logik erforderlich ist.

3. Browser-Unterstützung

Die Funktionalität von <dialog>, formmethod="dialog" und autofocus wird in modernen Browsern unterstützt. Für ältere Browser sollte ein Polyfill in Betracht gezogen werden, falls benötigt. Weitere Informationen zur Browser-Kompatibilität findest du auf MDN.

Barrierefreiheit

Die Barrierefreiheit unserer Komponenten wird nach der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) geprüft, die auf der europäischen Norm EN 301 549 basiert. Diese legt Anforderungen an die Zugänglichkeit von Informations- und Kommunikationstechnologien (IKT) fest und orientiert sich an den WCAG 2.1. Die für Webinhalte relevanten Kriterien sind in Kapitel 9 der EN 301 549 beschrieben und übernehmen die Nummerierung der WCAG-Kriterien, ergänzt um eine führende 9 – z. B. wird aus WCAG 2.4.3 „Focus Order“ das Kriterium 9.2.4.3.

Da bereits an einer Aktualisierung der EN 301 549 gearbeitet wird, haben wir uns entschieden, alle dort referenzierten Kriterien schon jetzt anhand der WCAG 2.2 zu prüfen und zu dokumentieren. So stellen wir sicher, dass unser Design-System den kommenden europäischen Standards voraus ist und langfristig barrierefrei bleibt.

Implementierungsabhängig

Unsere Komponenten wurden einzeln auf Barrierefreiheit geprüft und sind für sich genommen barrierefrei. Bei der Nutzung bzw. Kombination mehrerer Komponenten müssen jedoch bestimmte Aspekte beachtet werden, um die Barrierefreiheit im Gesamtkontext sicherzustellen:

Implementierungsabhängig

WCAG 2.4.2

Dialog-Kontext ist für Nutzer verständlich

Bestanden

Folgendes ist bereits geprüft und erfüllt, vorausgesetzt die Komponente wird wie in den Code-Beispielen gezeigt verwendet:

Bestanden

WCAG 1.3.1

Dialog ist programmatisch als Dialog erkennbar

Bestanden

WCAG 1.4.6

Dialog-Text erfüllt das minimale Kontrastverhältnis von 7:1

Bestanden

WCAG 1.4.11

Dialog hebt sich mit mindestens 3:1 Kontrast vom Hintergrund ab

Bestanden

WCAG 2.1.1

Dialog ist vollständig per Tastatur bedienbar

Bestanden

WCAG 2.4.3

Fokus bleibt innerhalb des Dialogs gefangen

Bestanden

WCAG 2.4.13

Dialog-Elemente haben sichtbare Fokuszustände

Bestanden

WCAG 4.1.2

Schließen-Button ist eindeutig identifizierbar

Bestanden

WCAG 4.1.3

Dialog-Öffnung wird an Screenreader kommuniziert

• Fokusmanagement: Beim Öffnen des Dialogs muss der Fokus automatisch auf das erste interaktive Element (z. B. die Überschrift oder die primäre Schaltfläche) gesetzt werden. Nach dem Schließen des Dialogs wird der Fokus auf das auslösende Element zurückgesetzt. Falls der Dialog automatisch geöffnet wurde, sollte der Fokus zum Anfang des Hauptinhalts springen.
• Klare Kennzeichnung und Kontext: Der Dialog muss die ARIA-Rolle role="dialog" oder role="alertdialog" verwenden, um Bildschirmleseprogrammen den Dialogkontext zu vermitteln. Eine klare Überschrift beschreibt den Inhalt und Zweck des Dialogs. Maus- und Tastaturbenutzende müssen informiert werden, dass es sich um einen Dialog handelt, der im Fokus steht.
• Interaktionseinschränkung: Während ein modaler Dialog geöffnet ist, darf keine Interaktion mit Inhalten außerhalb des Dialogs möglich sein. Alle anderen Inhalte der Seite müssen unzugänglich gemacht werden, beispielsweise durch das Attribut aria-hidden="true". Das Scrollen auf der Seite sollte deaktiviert werden, solange der Dialog geöffnet ist.
• Tastaturnavigation: Nutzende müssen den Dialog vollständig mit der Tastatur bedienen können. Nutzende können die Elemente im Dialog mit der Tabulator-Taste navigieren und den Dialog mit der Escape-Taste schließen. Die Tabulatortaste darf die Nutzenden nicht aus dem Dialog herausführen, um Fokusfallen zu vermeiden und die Bedienung klar und strukturiert zu halten.

Siehe auch: BFIT Handreichungen