Barrierefreier modaler Dialog

Aktualisiert am 14. Oktober 2026 · Lesezeit: 6 Min.

Newsletter-Pop-ups, Schnellansicht, Größenberater, Overlays „In den Warenkorb gelegt“, Login-Formulare, Cookie-Einstellungen – Online-Shops sind voller modaler Dialoge, und sie gehören zu den häufigsten Gründen, warum Tastatur- und Screenreader-Nutzer stecken bleiben. Diese Seite zeigt das richtige Muster. Sie gehört zur Reihe barrierefreie UI-Muster.

Das APG definiert einen Dialog als „ein Fenster, das über das Hauptfenster oder ein anderes Dialogfenster gelegt wird“, und sagt: „Fenster unter einem modalen Dialog sind inert“ – Nutzer können erst wieder mit der Seite interagieren, wenn der Dialog geschlossen ist. Setzen Sie ein Modal ein, wenn der Nutzer eine Aufgabe abschließen oder verwerfen muss, bevor er weitermacht: Löschen bestätigen, sich anmelden, in einer Schnellansicht eine Variante wählen. Für Informationen, die die Aufgabe nicht blockieren (eine Meldung „In den Warenkorb gelegt“), ist eine nicht modale Meldung oder eine Statusmeldung meist weniger störend.

Relevante WCAG-Kriterien

2.1.1 Tastatur (A) und 2.1.2 Keine Tastaturfalle (A): Der Dialog lässt sich per Tastatur bedienen und schließen. Den Fokus in einem Modal zu halten, ist in Ordnung, solange der Nutzer es verlassen kann.
2.4.3 Fokus-Reihenfolge (A): Der Fokus wechselt in den Dialog und danach zurück zum Auslöser.
2.4.11 Fokus nicht verdeckt (Minimum) (AA): Das W3C merkt an, dass ein korrekt gebautes Modal immer besteht, während nicht modale Overlays das fokussierte Element verdecken können.
4.1.2 Name, Rolle, Wert (A): Rolle dialog und ein Name.
1.3.1 Info und Beziehungen (A): Der Titel ist eine Überschrift, die Struktur steht im Code.
1.4.10 Umfluss (Reflow) (AA): Der Dialog passt auf einen schmalen Bildschirm und bei 400 % Zoom ohne zweidimensionales Scrollen.
2.2.1 Zeiteinteilung anpassbar (A): Pop-ups dürfen sich nicht per Zeitgeber schließen, bevor Nutzer sie lesen können.

Codebeispiel

<button type="button" id="open-size-guide">Größenberater</button>

<dialog id="size-guide" aria-labelledby="size-guide-title">
  <h2 id="size-guide-title">Größenberater</h2>
  <table>…</table>
  <button type="button" id="close-size-guide">Schließen</button>
</dialog>

<script>
  const dialog = document.getElementById('size-guide');
  document.getElementById('open-size-guide')
    .addEventListener('click', () => dialog.showModal());
  document.getElementById('close-size-guide')
    .addEventListener('click', () => dialog.close());
</script>

Was das native Element nach dem HTML-Standard tut:

showModal() legt den Dialog in die Top Layer, blockiert das Dokument, sodass der Rest inert wird, merkt sich das zuvor fokussierte Element und führt die Fokusschritte des Dialogs aus, die das Attribut autofocus berücksichtigen.
Eine Schließanfrage (zum Beispiel Escape) löst ein abbrechbares cancel-Ereignis aus und schließt dann den Dialog. Das Attribut closedby steuert, ob auch Klicks außerhalb ihn schließen.
close() gibt den Fokus an das zuvor fokussierte Element zurück, wenn der Dialog modal war.

Bauen Sie den Dialog selbst mit ARIA, folgen Sie dem APG: Der Container hat role="dialog", aria-modal="true" und aria-labelledby, das auf den sichtbaren Titel zeigt; aria-describedby ist optional und lässt man besser weg, wenn der Inhalt Listen oder Tabellen enthält. Dann müssen Sie den Hintergrund inert machen, Tab im Dialog halten, Escape behandeln und den Fokus selbst zurücksetzen.

Tastaturbedienung

Aus dem APG-Muster für Dialoge (modal):

Taste	Funktion
Tab	Nächstes tabbares Element im Dialog; vom letzten zurück zum ersten
Umschalt + Tab	Vorheriges tabbares Element im Dialog; vom ersten zum letzten
Escape	Schließt den Dialog

Fokus beim Öffnen: „Der Fokus wechselt zu einem Element im Dialog“, in der Regel dem ersten fokussierbaren Element. Fokus beim Schließen: Er „kehrt zu dem Element zurück, das den Dialog aufgerufen hat“, es sei denn, dieses Element existiert nicht mehr – dann zu einem anderen Element, das einen logischen Ablauf wahrt. Nach „Artikel entfernen“ kann der Fokus zum Beispiel zur Überschrift des Warenkorbs gehen.

Typische Fehler in Online-Shops

Newsletter-Pop-up beim Laden der Seite, das den Fokus stiehlt, keinen Namen hat und keinen per Tastatur erreichbaren Schließen-Button.
Schließen-„×“ ohne zugänglichen Namen oder ein Schließen-Icon, das ein div ist.
Der Fokus bleibt hinter dem Overlay: Tab läuft durch die Seite unter dem dunklen Hintergrund.
Kein Escape und auf Mobilgeräten kein sichtbarer Weg zum Schließen, sobald der Dialog länger als der Bildschirm ist.
Verlorener Fokus nach dem Schließen, der an den Seitenanfang springt statt zum Button „Schnellansicht“.
Schnellansichten, die die Produktseite nachbauen, mit doppelten IDs und verschachtelten Formularen.
Cookie-Banner, die weder modal sind noch aus dem Weg gehen und das fokussierte Element am unteren Bildschirmrand verdecken – laut W3C ein Verstoß gegen 2.4.11.

Was automatische Prüfungen finden und was manuell zu testen ist

Automatisch (axe-core-Regel)	Was sie findet
`aria-dialog-name`	`role="dialog"` oder `alertdialog` ohne Namen
`button-name`	Schließen-Buttons ohne Namen
`aria-hidden-focus`	Fokussierbare Elemente in Inhalten, die mit `aria-hidden="true"` verborgen sind
`aria-hidden-body`	`aria-hidden="true"` am body-Element
`aria-valid-attr-value`	`aria-labelledby` mit Verweis auf eine fehlende ID
`color-contrast`, `target-size`	Geringer Kontrast und kleine Ziele in einem geöffneten Dialog

Alle sind Karten in unserer Regelbibliothek. Die wöchentliche Prüfung sieht die Seite so, wie sie lädt: Ein geschlossener Dialog wird nicht getestet, ein sich automatisch öffnendes Pop-up schon. Mit der Browser-Erweiterung können Sie den Dialog öffnen und dann die Prüfung starten. Manuelle Tests: Öffnen Sie den Dialog per Tastatur, gehen Sie mit Tab bis zum Ende und zurück, drücken Sie Escape, prüfen Sie, wohin der Fokus fällt, zoomen Sie auf 400 % und hören Sie, wie ein Screenreader ihn ansagt. Die Schritte stehen unter WCAG testen.

Starten Sie die kostenlose Prüfung einer Seite. Sie ist eine automatische Prüfung, kein vollständiges Audit.

Häufige Fragen

Was macht einen modalen Dialog barrierefrei?

Der Fokus wechselt beim Öffnen in den Dialog, Tab und Umschalt + Tab bleiben darin, Escape schließt ihn, der Fokus kehrt zu dem Button zurück, der ihn geöffnet hat, der Inhalt dahinter ist inert, und der Dialog hat einen Namen aus seinem sichtbaren Titel.

Sollte ich das HTML-Element dialog verwenden?

Für ein Modal erledigt das mit showModal() geöffnete dialog-Element viel: Nach dem HTML-Standard liegt es in der Top Layer, macht den Rest des Dokuments inert, kümmert sich um den anfänglichen Fokus und schließt sich bei einer Schließanfrage wie Escape. Testen Sie es mit den Browsern und Screenreadern, die Ihre Kunden nutzen.

Wohin sollte der Fokus beim Öffnen eines Dialogs gehen?

Das APG sagt, der Fokus wechselt zu einem Element im Dialog, in der Regel dem ersten fokussierbaren Element. Bei einem langen Text kann es besser sein, den Anfang des Inhalts zu fokussieren. Beim dialog-Element wählen Sie das mit dem Attribut autofocus.

Nur, wenn er als solcher gebaut ist. Ein nicht modales Banner darf fokussierte Elemente nicht verdecken: Das W3C sagt, ein fixiertes Cookie-Banner verstößt gegen 2.4.11 Fokus nicht verdeckt, wenn es eine Komponente, die den Fokus erhält, vollständig überdeckt.

Teilweise. Sie findet Dialoge ohne Namen, Schließen-Buttons ohne Namen und fokussierbare Elemente, die mit aria-hidden verborgen sind. Fokusbewegung, Fokusfalle oder Escape kann sie nicht testen, und ein geschlossener Dialog wird gar nicht geprüft.

Quellen

W3C WAI, APG Dialog (Modal) pattern: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
WHATWG, HTML Living Standard, the dialog element: https://html.spec.whatwg.org/multipage/interactive-elements.html#the-dialog-element
W3C, Understanding 2.4.11 Focus Not Obscured (Minimum): https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html