Das HTML inert-Attribut: Bereiche vollständig deaktivieren

Jahrelang mussten Entwickler für modale Dialoge eine Kombination aus <code>aria-hidden="true"</code>, <code>tabindex="-1"</code> auf jedem fokussierbaren Element und Klick-Event-Abfang implementieren, um den Hintergrundinhalt vollständig zu deaktivieren. Das HTML-Attribut <code>inert</code> löst dieses Problem mit einer einzigen Zeile. Es ist mittlerweile in allen modernen Browsern verfügbar und wird als Best Practice für Dialog-Management, Offscreen-Navigation und Drawer-Menüs empfohlen. Für die BFSG-Konformität nach EN 301 549 bietet <code>inert</code> eine robuste Lösung für die Anforderungen an Fokusreihenfolge und Keyboard-Trap-Vermeidung.

Was inert bewirkt – die drei Effekte

Das inert-Attribut hat drei gleichzeitige Auswirkungen auf ein Element und alle seine Nachkommen: 1. Nicht fokussierbar: Kein Element innerhalb des inert-Containers kann per Tab-Taste oder element.focus() fokussiert werden. Dies betrifft alle fokussierbaren Elemente: Links, Buttons, Eingabefelder, Elemente mit tabindex. 2. Nicht klickbar: Klick-Events auf Elemente innerhalb des Containers werden ignoriert. Mausereignisse wie click, mousedown und pointerdown werden nicht ausgelöst. 3. Aus dem Accessibility Tree entfernt: Alle Elemente werden für Screenreader unsichtbar – äquivalent zu aria-hidden="true" auf dem Container. Die Kombination dieser drei Effekte macht inert zur sichersten Methode, Inhalte vollständig zu deaktivieren. Im Gegensatz zu aria-hidden="true" allein verhindert inert auch die Tastatur- und Mausinteraktion – ein häufiges Versäumnis bei manueller Implementierung.

inert vs. aria-hidden + tabindex=-1 – der Vergleich

Traditioneller Ansatz (vor inert): Um den Hintergrund eines Modals zu deaktivieren, mussten Entwickler: aria-hidden="true" auf den Hauptinhalt setzen. Alle fokussierbaren Elemente im Hauptinhalt finden und tabindex="-1" setzen. Die originalen tabindex-Werte speichern, um sie beim Schließen wiederherzustellen. Klick-Events auf dem Overlay abfangen. Diese Lösung war fehleranfällig: Dynamisch eingefügte Elemente wurden übersehen, die tabindex-Wiederherstellung schlug fehl, Edge Cases in verschiedenen Browsern erforderten Workarounds. Moderner Ansatz (mit inert): <main inert>...</main><dialog open>...</dialog> – eine einzige Zeile deaktiviert den gesamten Hauptinhalt. Beim Schließen: main.removeAttribute("inert") – fertig. Performance: Der Browser optimiert inert intern, anstatt den DOM-Baum traversieren zu müssen. WCAG 2.4.3 (Fokusreihenfolge) und 2.1.2 (Keine Tastaturfalle) werden zuverlässiger erfüllt.

Dialog-Management mit inert

Das häufigste Einsatzszenario für inert ist die Verwaltung modaler Dialoge. Das empfohlene Pattern: Dialog öffnen: 1. inert-Attribut auf alle Geschwister-Container des Dialogs setzen. 2. Dialog-Element anzeigen (idealerweise mit <dialog>-Element und .showModal()). 3. Fokus auf den ersten fokussierbaren Inhalt im Dialog setzen. Dialog schließen: 1. inert-Attribut von allen Containern entfernen. 2. Dialog ausblenden. 3. Fokus auf das Element zurücksetzen, das den Dialog geöffnet hat (WCAG 2.4.3). Verschachtelte Dialoge: Bei einem Dialog über einem Dialog wird der erste Dialog ebenfalls inert – nur der oberste Dialog ist interaktiv. HTML dialog-Element: Das native <dialog>-Element mit .showModal() implementiert viele dieser Funktionen automatisch, einschließlich Fokus-Trapping und Escape-Handler. inert ergänzt es für Legacy-Browser oder Custom-Dialog-Implementierungen. EN 301 549 Abschnitt 11.2.4.3 verlangt korrekte Fokusreihenfolge bei Dialogen.

Weitere Anwendungsfälle

Offscreen-Navigation: Ein Slide-in-Menü, das links außerhalb des Viewports liegt, sollte inert erhalten, bis es eingeblendet wird. Ohne inert können Tastaturnutzer in das unsichtbare Menü tabben – ein häufiger Barrierefreiheitsfehler. Carousel/Slider: Nicht sichtbare Slides eines Carousels sollten inert sein, damit nur der aktive Slide interaktiv ist. Tab-Panels: Nicht-aktive Tab-Panels sollten inert oder hidden erhalten. Drawer-Menüs: Wenn ein Drawer-Menü geöffnet ist, erhält der Hauptinhalt inert. Loading-States: Während ein Bereich geladen wird, kann inert verhindern, dass Nutzer mit halbgeladenem Inhalt interagieren. Wizard/Step-Formulare: Nicht-aktive Schritte eines Formulars können inert erhalten. Alle diese Szenarien profitieren von inert, da es die Fokusreihenfolge automatisch bereinigt (WCAG 2.4.3) und Keyboard Traps verhindert (WCAG 2.1.2).

Browser-Unterstützung und Polyfills

Aktuelle Browser-Unterstützung (Stand 2025): Chrome/Edge: ab Version 102 (Mai 2022). Firefox: ab Version 112 (April 2023). Safari: ab Version 15.5 (Mai 2022). Damit ist inert in allen modernen Browsern verfügbar. Für ältere Browser existiert das offizielle inert-Polyfill von WICG (Web Incubator Community Group): npm install wicg-inert. Das Polyfill emuliert das Verhalten, indem es aria-hidden="true" und tabindex="-1" auf alle fokussierbaren Kindelemente setzt. CSS-Hinweis: Browser wenden standardmäßig pointer-events: none und einen visuellen Dimm-Effekt auf inert-Elemente an. Sie können dies mit CSS anpassen: [inert] { opacity: 0.5; }. Testing: Testen Sie inert mit einem Screenreader (NVDA, VoiceOver) und per Tastatur. Prüfen Sie, dass kein Element innerhalb eines inert-Containers fokussierbar oder vorlesbar ist. bf-check erkennt Inkonsistenzen zwischen inert-Status und Fokussierbarkeit. Das BFSG erwartet Kompatibilität mit aktuellen Browsern und assistiven Technologien.