Barrierefreie Modals erstellen: Natives `<dialog>` oder eine Bibliothek?

Im Jahr 2026 sollte das native <dialog>-Element mit showModal() die erste Wahl sein: Es bietet Focus Containment, ESC-zum-Schließen, Top-Layer-Rendering, Verhinderung des Hintergrund-Scrollens und ein implizites aria-modal – ganz ohne JavaScript. Greifen Sie auf eine Bibliothek wie Radix, React Aria, Headless UI oder a11y-dialog nur dann zurück, wenn Sie auf komplexes Stacking, aufwändige Animationsanforderungen, Design-System-Komposabilität oder eine konkret gemessene native Lücke stoßen.

Dieses Urteil kehrt jahrelange gängige Praxis um. Der Standardrat – das Modal portalen, den Fokus manuell einfangen, den Hintergrund mit aria-hidden ausblenden, ESC per Hand verdrahten – beschrieb, was man tun musste, bevor <dialog> und inert verfügbar waren. Das <dialog>-Element ist seit März 2022 Baseline in allen gängigen Browsern, sodass ein Großteil dieses Gerüsts nun Browser-Standard ist. Dieser Artikel löst die Entscheidung zwischen nativem Element und Bibliothek anhand konkreter Kriterien, klärt die Fokus-Trap-Nuancen dort, wo die meisten Anleitungen veraltete Ratschläge wiederholen, liefert eine verifizierte Minimalimplementierung in Vanilla JS und React und schließt mit der Screen-Reader-Realität, die korrektes ARIA allein nicht löst.

Was ein barrierefreies Modal tatsächlich leisten muss

Ein barrierefreies Modal hat fünf unverzichtbare Verhaltensweisen: Es verschiebt den Fokus beim Öffnen in sich selbst, macht den Hintergrund unerreichbar und nicht interaktiv, kann per Tastatur (ESC) und einem sichtbaren Steuerelement geschlossen werden, stellt den Fokus beim Schließen auf das auslösende Element wieder her und exponiert eine Dialog-Rolle mit einem zugänglichen Namen, damit Screen Reader es ankündigen. Diese entsprechen direkt den WCAG-Erfolgskriterien – Fokusreihenfolge (2.4.3), Tastaturbedienbarkeit (2.1.1, 2.1.2) und Name/Rolle/Wert (4.1.2). Die vollständige WCAG 2.2 Kurzreferenz listet den Rest auf; diese kurze Zusammenstellung entscheidet über Erfolg oder Misserfolg eines Modals.

Der Grund, warum diese Anforderungen so häufig nicht erfüllt werden, liegt darin, dass jede einzelne ein separates Mechanismus-Stück in einem manuell erstellten position: fixed-Modal darstellt. Man skriptet die Fokusverschiebung, die Fokuswiederherstellung, den ESC-Listener, das Ausblenden des Hintergrunds und die Rollenverdrahtung unabhängig voneinander – und wenn auch nur eines davon still regressiert, entsteht ein Modal, das für Mausnutzer einwandfrei aussieht, für alle anderen jedoch defekt ist. Das Argument für das native Element ist, dass es den Großteil dieser Mechanismen in einem einzigen DOM-Aufruf zusammenfasst.

Was <dialog> und showModal() kostenlos liefern – und was nicht

Der Aufruf von showModal() auf einem <dialog> liefert ohne weiteres JavaScript als den Aufruf selbst: initialen Fokus, der in den Dialog verschoben wird, Schließen per Esc-Taste durch den Browser, Top-Layer-Rendering, das z-index- und Portal-Probleme umgeht, ein mit ::backdrop stilisierbares Hintergrundelement, ein implizites role="dialog" mit aria-modal="true" sowie einen inert-Hintergrund, sodass Tab keinen Seiteninhalt dahinter erreichen kann. close() stellt dann den Fokus auf das Element wieder her, das den Dialog geöffnet hat. Jared Cunha, der das Modal des U.S. Web Design System auf Basis von <dialog> neu aufgebaut hat, berichtet, dass das Rewrite von etwa 400 Zeilen JavaScript plus vier Hilfsfunktionen auf etwa 38 Zeilen schrumpfte – die Barrierefreiheitsverhaltensweisen, die man früher skriptete, sind jetzt Browser-Standard.

Was es nicht liefert, und die entsprechenden Lösungen:

Das Scroll-nach-unten-Verhalten ist keine Eigenart einer einzelnen Bibliothek – die W3C ARIA APG-Beispielimplementierung für modale Dialoge dokumentiert, dass das Platzieren des initialen Fokus auf einem Element nahe dem Ende des Dialoginhalts dazu führen kann, dass der Dialog außerhalb des sichtbaren Bereichs geöffnet wird. Die sauberste Lösung ist die Quellreihenfolge: Überschrift zuerst, Schließen-Button danach, sodass der Screen Reader den Titel vor dem Steuerelement ankündigt und der Dialog oben geöffnet wird.

Für das Scroll-Sperren erfassen Sie die Scroll-Position, sperren den Body und stellen ihn beim Schließen wieder her:

:root:has(dialog[open]) {
  overflow: hidden;
  scrollbar-gutter: stable; /* verhindert den Layout-Sprung, wenn die Scrollleiste verschwindet */
}

scrollbar-gutter: stable reserviert die Breite der Scrollleiste, damit die Seite beim Sperren des Scrollens nicht seitwärts verschoben wird. Auf iOS Safari ist overflow: hidden am Body bekanntermaßen undicht; das Erfassen von window.scrollY und das Anwenden von position: fixed mit einem negativen top-Wert ist der zuverlässigere plattformübergreifende Ansatz, wenn nötig.

Die Fokus-Trap-Frage, geklärt: Keinen Trap für ein natives Dialog

Fügen Sie einem nativen <dialog>, das mit showModal() geöffnet wurde, keinen JavaScript-Fokus-Trap hinzu. Der Browser platziert es bereits im Top Layer und versetzt den Rest der Seite in den inert-Zustand, sodass der Fokus eingeschlossen ist – das Einzige, was Tab noch erreichen kann, ist das Chrome des Browsers selbst (Adressleiste, Tabs, Erweiterungen), das Tastaturnutzer genauso erreichen können sollten wie Mausnutzer. Dies ist der am häufigsten wiederholte veraltete Ratschlag in Modal-Tutorials, und er ist für das native Element falsch.

Die Begründung stammt von anerkannten Barrierefreiheits-Experten, zusammengefasst von Zell Liew in CSS-Tricks’ „There is No Need to Trap Focus on a Dialog Element”. Scott O’Haras Position ist, dass WCAG Fokus-Trapping normativ nicht vorschreibt; die Trap-Empfehlung stammte aus informativer Anleitung, die verfasst wurde, bevor inert und <dialog> weitgehend unterstützt wurden, als es bei geskripteten Dialogen einfacher war, Elemente einzufangen, als externe Elemente aus der Tab-Reihenfolge zu entfernen. Léonie Watsons Sichtweise ist, dass Nutzer innerhalb eines Dialogs dieselben Steuerungsoptionen haben sollten wie auf einer normalen Seite – sie sollten weiterhin Browser-Steuerelemente erreichen können. Die Ansicht der W3C APA Working Group ist, dass das native Dialog-Verhalten unverändert bleiben sollte, teilweise weil das Tabben zum Browser-Chrome in Kiosk- und gesperrten Kontexten einen Fluchtmechanismus darstellt.

Dies ist eine echte, aktuelle Debatte, kein abschließend geklärtes Recht. Jared Cunha fügt in der oben zitierten USWDS-Arbeit dem nativen Element weiterhin eine Fokus-Trap-Funktion hinzu. Seine Begründung ist praktische Vorsicht. Doch das Gewicht der normativen Interpretation liegt bei der No-Trap-Position für das native Element, und das Hinzufügen eines Traps entzieht Tastaturnutzern aktiv eine Fähigkeit, die sie standardmäßig haben.

Der Vorbehalt, der die Regel vervollständigt: Manuelle Fokus-Traps gehören zu benutzerdefinierten, nicht auf <dialog> basierenden Modals – und wer eines baut, ist selbst für inert im Hintergrund verantwortlich, da nichts dies automatisch verwaltet. Der Ratschlag „Fokus immer einfangen” ist nicht grundsätzlich falsch; er ist falsch, wenn er auf das Element angewendet wird, das die Einschränkung bereits selbst handhabt.

Eine minimale, korrekte native <dialog>-Implementierung

Hier ist die Vanilla-Version mit den drei sinnvollen Erweiterungen: Backdrop-Klick zum Schließen, animationsreduzierungsbewusste Animation – und sonst nichts. Die Fokuswiederherstellung wird bereits von close() übernommen.

<button id="open">Dialog öffnen</button>

<dialog id="dlg" aria-labelledby="dlg-title">
  <h2 id="dlg-title">Änderungen bestätigen</h2>
  <p>Ihre Bearbeitungen werden sofort übernommen.</p>
  <form method="dialog">
    <button value="cancel">Abbrechen</button>
    <button value="confirm">Bestätigen</button>
  </form>
</dialog>

const dlg = document.getElementById('dlg');

document.getElementById('open').addEventListener('click', () => dlg.showModal());

// Backdrop-Klick schließt den Dialog (natives Verhalten tut dies NICHT).
dlg.addEventListener('click', (e) => {
  if (e.target === dlg) dlg.close();
});

aria-labelledby verweist auf die sichtbare Überschrift und gibt dem Dialog seinen zugänglichen Namen. <form method="dialog"> schließt den Dialog beim Absenden und speichert, welcher Button gedrückt wurde, in dlg.returnValue – kein zusätzliches JS erforderlich. Die Backdrop-Prüfung funktioniert, weil ein Klick auf ::backdrop als Klick auf das <dialog>-Element selbst registriert wird, während ein Klick auf den Inhalt auf einem Kind-Element registriert wird.

Animieren Sie es, ohne mit dem Top Layer zu kämpfen, und respektieren Sie Bewegungspräferenzen:

dialog {
  opacity: 0;
  transition: opacity 0.2s, overlay 0.2s allow-discrete, display 0.2s allow-discrete;
}
dialog[open] { opacity: 1; }
@starting-style {
  dialog[open] { opacity: 0; }
}
@media (prefers-reduced-motion: reduce) {
  dialog { transition: none; }
}

@starting-style und transition-behavior: allow-discrete ermöglichen Eingangsübergänge für ein Element, das sich in den und aus dem Top Layer bewegt. Der prefers-reduced-motion-Block erfüllt WCAG 2.3.3.

Die React-Version verwendet useRef zum Aufrufen der imperativen Methoden und useId für eine SSR-sichere Label-Verknüpfung:

import { useRef, useEffect, useId } from 'react';

function Dialog({ open, onClose, title, children }) {
  const ref = useRef(null);
  const titleId = useId();

  useEffect(() => {
    const el = ref.current;
    if (open) el.showModal();
    else el.close();
  }, [open]);

  return (
    <dialog
      ref={ref}
      aria-labelledby={titleId}
      onClose={onClose}
      onClick={(e) => { if (e.target === ref.current) ref.current.close(); }}
    >
      <h2 id={titleId}>{title}</h2>
      {children}
    </dialog>
  );
}

Das native close-Event (ausgelöst durch ESC, den Backdrop-Handler oder das Formular-Submit) steuert Ihr onClose und hält den React-State mit dem Element synchron. Verwenden Sie role="alertdialog" anstelle des Standards für destruktive Bestätigungen, und schließen Sie diese nicht per Backdrop-Klick.

Natives <dialog> vs. eine Bibliothek: Die Entscheidungsmatrix für 2026

Nutzen Sie diese Tabelle zur Entscheidungsfindung. Überprüfen Sie die Versionen bei der Integration auf npm, da sich Patch-Levels ändern können.

Die aktuelle Version von a11y-dialog ist 8.1.5, und laut seiner eigenen Dokumentation bekannter Probleme stützt es sich auf aria-modal (WAI-ARIA 1.1), dessen Unterstützung bei bestimmten mobilen Hilfstechnologien nicht optimal ist – die Kombination mit dem aria-hidden-Helper ist die dokumentierte Abhilfemaßnahme.

Headless UI für React ist in Version 2.2.10, veröffentlicht am 7. April 2026. Laut der Headless UI-Dokumentation ist sein Dialog eine benutzerdefinierte div-basierte Komponente, die den Fokus nach innen verschiebt und ihn einfängt – was korrekt ist, da es sich nicht um ein natives <dialog> handelt und daher einen Trap benötigt. Laut der React Aria-Dokumentation wird der Fokus beim Mounten in den Dialog verschoben und beim Unmounten auf den Auslöser zurückgesetzt, und er ist während des Öffnens eingeschlossen. Ein Hinweis: Die Dokumentation von React Aria beschreibt das HTML-<dialog>-Element noch als nicht weitgehend unterstützt – diese Aussage ist angesichts des Baseline-Status seit 2022 veraltet; übernehmen Sie sie nicht.

Die Headless-Landschaft hat sich in der zweiten Hälfte von 2025 und Anfang 2026 tatsächlich verändert. Base UI, gepflegt vom MUI-Team und entwickelt von Alumni aus Radix, Floating UI und Material UI, erreichte im Dezember 2025 ein stabiles v1.0, und shadcn/ui konsolidierte seine Radix-Nutzung im Februar 2026 auf das einheitliche radix-ui-Paket. Eine häufig verwechselte Tatsache: Radix’ Muttergesellschaft Modulz wurde bereits 2022 von WorkOS übernommen – das ist vier Jahre alt, keine aktuelle Neuigkeit. Die wirklich aktuelle Veränderung ist der Aufstieg von Base UI als alternative Primitive-Schicht. Die meisten Teams konsumieren Radix weiterhin über shadcn/ui.

Wenn <dialog> nicht verwendet werden kann: Die Checkliste für benutzerdefinierte Modals

Wenn Sie ein benutzerdefiniertes Modal bauen müssen – nicht-modale koexistierende Dialoge, exotisches Stacking oder eine Legacy-Einschränkung – übernehmen Sie die vollständige Verantwortung für alles, was das native Element gehandhabt hätte. Mindestens:

• Fokus beim Öffnen hineinverschieben und beim Schließen wiederherstellen;
• das inert-Attribut auf den Rest der App anwenden (robuster als aria-hidden, da inert Elemente auch aus der Tab-Reihenfolge entfernt);
• einen echten Fokus-Trap implementieren, der Tab und Shift+Tab über fokussierbare Kindelemente zyklisch führt;
• einen ESC-Keydown-Handler hinzufügen;
• Hintergrund-Scrolling sperren; und
• role="dialog"/alertdialog mit aria-modal="true" und einem zugänglichen Namen setzen.

Dies ist der Fall – und der einzige Fall –, in dem „Fokus immer einfangen” der richtige Ratschlag ist.

Barrierefreiheitsfehler in benutzerdefinierten Modals wie diese werden genau durch Production Session Replay sichtbar, da es den tatsächlichen Fokus- und Tastaturpfad eines Nutzers rekonstruiert. Man kann beobachten, wie ein Tastaturnutzer direkt aus einem benutzerdefinierten Modal in den Hintergrundinhalt tabbt – das unverkennbare Zeichen eines fehlenden inert oder eines defekten Traps. Man sieht, wie der Fokus nach dem Schließen eines Modals ins Leere geht – das Anzeichen dafür, dass die Opener-Referenz nie gespeichert wurde. Man sieht ein Modal, das überhaupt nicht per Tastatur geschlossen werden kann, weil ein benutzerdefinierter Build ohne ESC-Handler ausgeliefert wurde. Das sind die Fehlermodi, die Audits bestehen und Replays aufdecken.

Screen-Reader-Realität: Korrektes ARIA reicht nicht aus

Korrektes ARIA ist notwendig, aber nicht hinreichend. Stand 2026 kann Safari in Kombination mit VoiceOver statische, nicht fokussierbare Inhalte innerhalb eines aria-modal-Dialogs für den virtuellen Cursor weiterhin unerreichbar machen – ein bekanntes WebKit-Problem, das durch Deques Bericht vom Dezember 2025 zu ARIA-Modal-Dialogen bestätigt wird. Die praktische Konsequenz: Ein perfekt ausgezeichneter Dialog kann seinen Fließtext für einen VoiceOver-Nutzer dennoch verstecken. Testen Sie es; verlassen Sie sich nicht darauf.

Darüber hinaus kündigt NVDA die Dialog-Rolle möglicherweise nicht in jeder Konfiguration an, und TalkBack kann absolut positionierte Inhalte übersehen. Die Schlussfolgerung ist eine Prozessfrage, keine Markup-Frage: Testen Sie auf mindestens zwei Screen-Reader/Browser-Kombinationen – mindestens VoiceOver/Safari und NVDA/Firefox oder Chrome – denn ein automatisiertes Audit bestätigt, dass die Attribute vorhanden sind, nicht dass eine echte Hilfstechnologie den Inhalt erreicht.

Fazit

Greifen Sie zuerst zum nativen <dialog>, schreiben Sie die vier kleinen Erweiterungen (Backdrop-Close, gezielter initialer Fokus, Scroll-Sperre, animationsreduzierungsbewusste Animation) und widerstehen Sie dem Drang, einen Fokus-Trap hinzuzufügen, den es nicht braucht. Ziehen Sie Radix, React Aria, Headless UI, a11y-dialog oder Base UI nur dann hinzu, wenn eine konkrete Anforderung – Komposabilität, Animation, Stacking – ein abhängigkeitsfreies Element überwiegt, das die Barrierefreiheit für Sie mitliefert. Öffnen Sie dann einen Screen Reader und bestätigen Sie, was das Audit nicht kann: dass ein echter Nutzer tatsächlich jedes Wort erreichen kann.

FAQs

Funktioniert ein natives Dialog-Element ohne JavaScript mit dem form method dialog-Attribut?

Ein Dialog kann ohne JavaScript nur geöffnet werden, wenn das open-Attribut verwendet wird – das rendert ihn jedoch als nicht-modalen Dialog ohne Top Layer, ohne inert-Hintergrund und ohne Focus Containment. Die modalen Verhaltensweisen erfordern den Aufruf von showModal() in JavaScript, der nicht deklarativ ausgelöst werden kann. Ein Dialog kann jedoch ohne zusätzliches JavaScript geschlossen werden, indem ein Formular mit method='dialog' darin platziert wird; das Absenden dieses Formulars schließt den Dialog und speichert den gedrückten Button in der returnValue-Eigenschaft.

Was ist der Unterschied zwischen role dialog und role alertdialog bei einem Modal?

Das Standard-role='dialog' eines nativen Dialog-Elements gilt für allgemeine Modals, in denen Nutzer Inhalte durchsuchen oder eingeben, während role='alertdialog' eine dringende, unterbrechende Nachricht signalisiert, die eine Reaktion erfordert, beispielsweise eine Bestätigung einer destruktiven Aktion. Screen Reader kündigen alertdialog-Inhalte nachdrücklicher an. Bei alertdialog-Modals sollten kein Backdrop-Klick oder beiläufiges Schließen erlaubt werden, da das Muster davon ausgeht, dass der Nutzer eine bewusste Entscheidung treffen muss, anstatt den Dialog versehentlich zu schließen.

Warum öffnet sich mein Dialog nach unten gescrollt statt oben?

Dies passiert, wenn das erste fokussierbare Element im DOM des Dialogs nahe am Ende des Inhalts sitzt. Wenn showModal() ausgeführt wird, verschiebt der Browser den Fokus auf dieses erste fokussierbare Steuerelement, und wenn es sich am Ende befindet, öffnet sich der Dialog dorthin gescrollt. Der W3C ARIA Authoring Practices Guide dokumentiert dieses Verhalten. Beheben Sie es, indem Sie die Quellreihenfolge so gestalten, dass die Überschrift vor dem ersten interaktiven Steuerelement kommt – beispielsweise indem der Schließen-Button nach dem Titel platziert wird, nicht davor.

Kann ich einen geöffneten Dialog mit der :open-Pseudoklasse statt dem open-Attributselektor stylen?

Die :open-Pseudoklasse kann einen geöffneten Dialog stylen, wurde jedoch erst mit Safari 26.5 im Mai 2026 als Baseline newly available eingestuft. Da sie neu verfügbar und noch nicht in älteren Browser-Versionen weit verbreitet ist, bleibt der sicherere browserübergreifende Selektor der Attributselektor dialog[open], der seit dem Baseline-Status des Elements im März 2022 funktioniert. Verwenden Sie den Attributselektor als primären Ansatz und behandeln Sie :open als Progressive Enhancement, bis die Unterstützung breiter ist.

Verwendet Headless UI das native Dialog-Element, und sollte ich den Fokus damit noch einfangen?

Headless UIs Dialog-Komponente ist eine benutzerdefinierte div-basierte Implementierung, kein natives HTML-Dialog-Element – daher verschiebt sie den Fokus korrekt nach innen und fängt ihn ein, während der Nutzer durch fokussierbare Elemente tabbt. Dies entspricht der Regel, dass benutzerdefinierte, nicht auf dialog basierende Modals den Fokus einfangen und den Hintergrund selbst als inert markieren müssen. Der Fokus-Trap sollte nicht entfernt werden. Der No-Focus-Trap-Ratschlag gilt ausschließlich für das native Dialog-Element, das mit showModal() geöffnet wird, wo der Browser den Fokus bereits auf die Seite beschränkt.