Fokus und Interaktivität mit dem Inert-Attribut verwalten

Das Setzen von inert auf einem Element entfernt dessen gesamten Teilbaum aus der Tab-Reihenfolge, blockiert alle Zeiger- und Klickereignisse und verbirgt ihn vor dem Accessibility-Tree, sodass Screenreader ihn weder auffinden noch ankündigen können — diese drei Verhaltensweisen sind durch den WHATWG HTML Living Standard spezifiziert. Darüber hinaus verhindern aktuelle Browser, dass die seitenintegrierte Suche (Strg/Cmd+F) Text im Teilbaum findet, und deaktivieren die Textauswahl darin — Verhaltensweisen, die die Spezifikation dem Ermessen des User-Agents überlässt, die MDN jedoch als implementierten Standard dokumentiert. Das sind sechs deaktivierte Interaktionskanäle mit einem einzigen Attribut.

Dieser Artikel löst ein konkretes Problem: Wie lässt sich Hintergrundinhalt sauber deaktivieren, wenn ein Modal, ein Drawer oder eine Seitennavigation geöffnet wird — ohne einen manuell implementierten Focus-Trap, der bei mobilen Screenreadern versagt, oder aria-hidden-Attribute, die über das gesamte DOM verstreut werden müssen? Er behandelt, was inert blockiert, die HTML- und JavaScript-Syntax zur Anwendung, ein vollständiges Modal-Beispiel mit Fokuswiederherstellung, die visuelle Gestaltung von Inert-Inhalten sowie Situationen, in denen stattdessen disabled, aria-hidden oder hidden die bessere Wahl ist.

Was das Inert-Attribut blockiert

inert ist ein globales HTML-Attribut, das ein Element und seinen gesamten Teilbaum nicht-interaktiv und nicht auffindbar macht. Gemäß dem Abschnitt zu Inert-Teilbäumen des WHATWG HTML Living Standard empfängt ein als inert markierter Knoten keine gezielten Nutzerinteraktionsereignisse wie Klicks oder Fokus, und User-Agents müssen ihn aus dem Accessibility-Tree ausschließen. Drei Blockierungen sind normativ und in allen Implementierungen konsistent:

1. Fokus — Inert-Elemente können weder per Tab, Klick noch durch programmatisches element.focus() fokussiert werden.
2. Zeiger- und Klickereignisse — Nutzerinitiierte Klicks und Zeigerereignisse erreichen inerte Knoten nicht.
3. Auffindbarkeit im Accessibility-Tree — Assistive Technologien können den Teilbaum weder finden noch ankündigen.

Zwei weitere Blockierungen werden in der Spezifikation dem Ermessen des User-Agents überlassen (sie verwendet das normative may), MDN dokumentiert sie jedoch als implementiertes Verhalten in aktuellen Browsern:

4. Seitenintegrierte Suche — Strg/Cmd+F findet keinen Text innerhalb eines inerten Teilbaums.
5. Textauswahl — Nutzer können keinen inerten Text auswählen.

Die Tab-Reihenfolge ergibt sich aus der Fokusblockierung: Da inerte Knoten nicht fokussierbar sind, werden sie vollständig aus der sequenziellen Fokusnavigation entfernt. Eine wichtige Einschränkung: inert blockiert nutzerinitiierte Ereignisse, nicht programmatische. Ein dispatchEvent()-Aufruf oder ein innerhalb eines inerten Teilbaums ausgelöster Timer wird weiterhin ausgeführt — inert ist kein alert() und friert die JavaScript-Ausführung nicht ein.

Ein wichtiger Fallstrick: Da inert den Teilbaum aus dem Accessibility-Tree entfernt, darf es niemals auf Inhalte angewendet werden, die ein Nutzer noch lesen muss. Wenn etwas nur visuell ausgeblendet, aber weiterhin auffindbar bleiben soll, ist ein anderes Werkzeug gefragt.

Die zwei kanonischen Anwendungsfälle

inert existiert für zwei Situationen, die beide im Inert-Leitfaden von web.dev dokumentiert sind: DOM, das vorhanden, aber außerhalb des sichtbaren Bereichs oder ausgeblendet ist, sowie DOM, das sichtbar ist, aber nicht interaktiv sein soll.

Außerhalb des sichtbaren Bereichs oder ausgeblendetes DOM. Ein ausfahrbares Navigations-Drawer oder eine Seitennavigation fügt dem DOM fokussierbare Links hinzu, bevor sie sichtbar sind. Ohne inert können Tastaturnutzer in das geschlossene Drawer hinein-tabben und auf Steuerelemente treffen, die sie nicht sehen können. Das Markieren des Drawer-Containers als inert bis zum Öffnen hält diese Links aus der Tab-Reihenfolge heraus:

<nav id="drawer" inert>
  <a href="/dashboard">Dashboard</a>
  <a href="/settings">Settings</a>
</nav>

Sichtbare, aber nicht-interaktive Benutzeroberfläche. Wenn ein Formular abgesendet wird, eine Seite lädt oder ein modales Overlay über dem Hintergrundinhalt liegt, ist dieser Inhalt zwar sichtbar, sollte aber keine Eingaben akzeptieren. Das Anwenden von inert auf das Formular während der Übermittlung verhindert doppelte Absendungen und unbeabsichtigte Fokusverschiebungen:

<form id="signup" inert>
  <!-- Felder als Gruppe deaktiviert, während die Anfrage läuft -->
</form>

Beide Fälle folgen derselben Logik: Der Inhalt verbleibt im DOM (sodass Layout, Übergänge und Zustand erhalten bleiben), aber der Browser leitet keine Interaktionen dorthin weiter.

Syntax: Das HTML-Attribut und die HTMLElement.inert-Property

inert verfügt über zwei Schnittstellen: das boolesche HTML-Attribut und die HTMLElement.inert-IDL-Property. Das Attribut eignet sich für statisches oder serverseitig gerendertes Markup; die Property dient zum Umschalten des Zustands in JavaScript.

Als boolesches Attribut ist allein seine Anwesenheit entscheidend — inert und inert="" sind gleichwertig, und der Standardwert ist false (Abwesenheit bedeutet interaktiv):

<main inert>
  <!-- alles hier ist nicht-interaktiv -->
</main>

Zum Umschalten zur Laufzeit wird die HTMLElement.inert-Property verwendet — ein boolescher Wert, der direkt gelesen und gesetzt werden kann, ohne den Umweg über setAttribute / removeAttribute:

const mainEl = document.querySelector('main');

// Interaktion mit dem Rest der Seite deaktivieren
mainEl.inert = true;

// Interaktion wiederherstellen
mainEl.inert = false;

Dies ist der eleganteste Teil der API und der Aspekt, der in den meisten vorhandenen Artikeln fehlt: Das Öffnen und Schließen erfolgt durch zwei Zuweisungen. Im Vergleich dazu umfasst das folgende Focus-Trap-Verfahren acht Schritte.

Vor inert: Focus-Traps und ihre Schwachstellen

Vor inert war ein JavaScript-basierter Focus-Trap die Standardmethode, um ein Modal einzugrenzen — Logik, die Tab und Shift+Tab abfängt, um den Fokus innerhalb des Dialogs zu halten. Das kanonische Verfahren, von CSS-Tricks beschrieben, umfasst etwa acht Schritte: alle fokussierbaren Elemente auf der Seite ermitteln, das erste und letzte fokussierbare Element innerhalb des Modals identifizieren, Interaktivität und Auffindbarkeit von allem außerhalb entfernen, Fokus hineinschieben, auf Schließereignisse lauschen, beim Schließen alles wiederherstellen und den Fokus auf den Auslöser zurücksetzen.

Bereits der erste Schritt — „alle fokussierbaren Elemente ermitteln” — ist eine Fehlerquelle, da die Menge der nativ fokussierbaren Elemente größer ist, als die meisten Entwickler im Kopf haben. Folgende Elemente erhalten in der sequenziellen Tab-Reihenfolge ohne jeglichen tabindex den Fokus:

• <a> und <area> mit einem href
• <button>, <input>, <select> und <textarea> (sofern nicht disabled)
• <iframe>, <embed> und <object>
• <audio> und <video> mit einem controls-Attribut
• <summary> (das erste innerhalb eines <details>)
• jedes Element mit einem nicht-negativen tabindex sowie jedes contenteditable-Element

Wird eines beim Aufbau eines Traps übersehen, kann ein Tastaturnutzer entkommen; wird die Liste zu akribisch verwaltet, kämpft man gegen die eigene Reihenfolge des Browsers. Der sicherere Standardansatz ist, die natürliche Fokusreihenfolge des Dokuments unangetastet zu lassen und nur dann einzugreifen, wenn eine Komponente es tatsächlich erfordert — was den Großteil der manuellen Arbeit darstellt, die inert abnimmt.

Der konzeptionelle Wechsel ist entscheidend. Ein Focus-Trap sperrt Nutzer durch das Abfangen von Tastendrücken innerhalb einer Komponente ein; inert sichert den Rest der Seite ab, indem alles außerhalb des Dialogs unerreichbar wird — der Browser setzt die Grenze durch, nicht das eigene JavaScript. Diese Guard-vs.-Trap-Betrachtungsweise stammt aus LogRockets Analyse des Attributs.

Manuell implementierte Traps scheitern auf drei wiederkehrende Weisen:

• Mobile assistive Technologien. TalkBack auf Android und VoiceOver auf iOS navigieren per Wischgesten, nicht per Tab-Tasten. Ein JavaScript-Trap, der nur Tastaturereignisse abfängt, bietet für wischbasierte Screenreader-Nutzer keinerlei Begrenzung. inert blockiert den Teilbaum auf Plattformebene und deckt sowohl Tastatur- als auch Gestennavigation ab.
• aria-hidden-Wildwuchs. Die Lösung vor inert bestand darin, aria-hidden="true" auf jedem Nicht-Modal-Element zu setzen. Bei Seiten mit tiefen DOM-Strukturen wird dies schnell unwartbar und ist häufig unvollständig.
• Manuelle Tab-Schleifen. Die Logik zum Abfangen von Tab/Shift+Tab ist fehleranfällig und leicht falsch zu implementieren, besonders wenn sich der fokussierbare Inhalt des Modals ändert.

Session-Replays von Modal- und Drawer-Implementierungen zeigen häufig Fokus-Ereignisse, die auf Hintergrundinhalt landen, während ein Dialog noch geöffnet ist — das typische Zeichen einer unvollständigen Fokusgrenze, und genau das, was inert zu verhindern designed wurde.

Die oben genannten Quellen bauen ein vollständiges trap-focus.js neu auf; das muss hier nicht wiederholt werden. Der relevante Vergleich ist die Zeilenanzahl. Der Trap umfasst Dutzende Zeilen Ereignisabfang-Logik. Das inert-Äquivalent sieht so aus:

function openModal() {
  mainEl.inert = true;
}
function closeModal() {
  mainEl.inert = false;
}

Vollständiges Modal-Beispiel mit Fokuswiederherstellung

Das sauberste benutzerdefinierte Modal-Muster platziert den Dialog als Geschwisterelement von <main inert>: Das Modal befindet sich außerhalb des inerten Teilbaums und bleibt damit interaktiv, während alles in <main> abgesichert ist. Dieses <main inert>-Geschwistermuster folgt der von CSS-Tricks dokumentierten Struktur. Das folgende Beispiel ergänzt das fehlende Detail, das in allen Referenzen ausgelassen wird — das Verschieben des Fokus beim Öffnen in den Dialog und die Rückgabe an den Auslöser beim Schließen.

<button id="open-modal" type="button">Änderungen speichern…</button>

<div
  id="modal"
  class="modal"
  role="dialog"
  aria-labelledby="modal-title"
  aria-modal="true"
  hidden
>
  <h2 id="modal-title">Änderungen speichern?</h2>
  <p>Nicht gespeicherte Änderungen gehen verloren.</p>
  <button id="save" type="button" autofocus>Speichern</button>
  <button id="cancel" type="button">Verwerfen</button>
</div>

<main id="page">
  <!-- gesamter Seiteninhalt -->
</main>

const triggerEl = document.getElementById('open-modal');
const modalEl = document.getElementById('modal');
const mainEl = document.getElementById('page');
const cancelEl = document.getElementById('cancel');

let lastFocused = null;

function openModal() {
  lastFocused = document.activeElement;   // Auslöser merken
  modalEl.hidden = false;
  mainEl.inert = true;                    // Rest der Seite absichern
  // Fokus auf die primäre Aktion des Dialogs verschieben
  modalEl.querySelector('[autofocus]').focus();
}

function closeModal() {
  mainEl.inert = false;                   // Seite wiederherstellen
  modalEl.hidden = true;
  if (lastFocused) lastFocused.focus();   // Fokus auf den Auslöser zurücksetzen
}

triggerEl.addEventListener('click', openModal);
cancelEl.addEventListener('click', closeModal);
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape' && !modalEl.hidden) closeModal();
});

Einige Hinweise zur Korrektheit: Der Dialog nutzt tabindex="-1"-Semantik implizit über seine fokussierbaren Kindelemente; ein positiver tabindex ist in der Regel nirgends erforderlich — positive ganzzahlige Werte überschreiben die natürliche Tab-Reihenfolge und sind ein dokumentiertes Anti-Pattern. tabindex="-1" sollte nur verwendet werden, wenn ein nicht-interaktiver Container programmatisch fokussiert werden muss, und tabindex="0" nur für genuinely interaktive benutzerdefinierte Elemente. Das autofocus-Attribut auf der primären Aktion ist der von der Spezifikation empfohlene Startpunkt für den Fokus innerhalb eines Dialogs. Dieses Muster funktioniert in Chrome 102+, Firefox 112+ und Safari 15.5+.

Inerte Inhalte gestalten: Kein Standard-Erscheinungsbild

inert hat keinen standardmäßigen visuellen Effekt — der Browser ändert das Verhalten, nicht das Erscheinungsbild, sodass inerte Inhalte identisch mit aktiven Inhalten aussehen, sofern sie nicht explizit gestaltet werden. Das Standardmuster, wie auf web.dev gezeigt, zielt auf den [inert]-Attributselektor ab und kombiniert drei Eigenschaften, die die vom Attribut blockierten Interaktionskanäle widerspiegeln:

[inert],
[inert] * {
  opacity: 0.5;         /* visuelle Abdunkelung — signalisiert "nicht aktiv" */
  pointer-events: none; /* unterdrückt Hover-/Cursor-Affordances */
  user-select: none;    /* verhindert Textauswahl */
  cursor: default;
}

Jede Eigenschaft hat ihre Berechtigung: opacity kommuniziert den deaktivierten Zustand visuell, pointer-events: none entfernt Hover-Zustände und Cursorveränderungen, die andernfalls Interaktivität implizieren würden, und user-select: none entspricht der Textauswahlblockierung, die das Attribut bereits anwendet. Das Verhalten wird durch inert selbst durchgesetzt; das CSS existiert, damit sehende Nutzer die Grenze erkennen können, die der Browser im Hintergrund durchsetzt.

Die Wahl zwischen inert, disabled, aria-hidden, hidden und pointer-events

Die Wahl des richtigen Werkzeugs richtet sich nach Geltungsbereich und Verhalten im Accessibility-Tree: inert blockiert alle Interaktionskanäle eines gesamten Teilbaums und entfernt ihn aus dem Accessibility-Tree; disabled blockiert ein einzelnes Steuerelement, lässt es aber auffindbar; aria-hidden verbirgt Inhalte vor assistiven Technologien, während Klicks und Fokus weiterhin funktionieren; hidden entfernt Inhalte vollständig; und CSS pointer-events: none blockiert ausschließlich die Maus. inert ist die richtige Wahl, wenn Hintergrundinhalt hinter einem Modal, Drawer oder Lade-Overlay vollständig abgesichert werden soll.

Die zwei häufigen Fehler: aria-hidden auf Hintergrundinhalt zu setzen, während er weiterhin klickbar und fokussierbar bleibt (er verbleibt in der Tab-Reihenfolge), und pointer-events: none zu verwenden in der Annahme, Tastatur- und Screenreader-Nutzer seien ebenfalls blockiert (das sind sie nicht). Für eine vollständige Absicherung des Hintergrunds ist inert das einzige einzelne Werkzeug, das alle Kanäle abdeckt.

Wird inert noch benötigt, wenn dialog.showModal() verwendet wird?

Wenn ein Dialog mit HTMLDialogElement.showModal() geöffnet wird, setzt der Browser den Rest der Seite automatisch auf inert — das Top-Layer-Verhalten beinhaltet eine implizite Inert-Grenze, sodass alles außerhalb des Dialogs ohne jegliche Attributverwaltung weder klickbar noch tabbbar wird. Manuelles inert ist nur dann erforderlich, wenn ein benutzerdefiniertes Dialog-Muster außerhalb des nativen <dialog>-Elements aufgebaut wird, wie im obigen Beispiel.

<dialog id="confirm">
  <p>Dieses Element löschen?</p>
  <button>Löschen</button>
  <button>Abbrechen</button>
</dialog>

document.getElementById('confirm').showModal(); // Seite automatisch inert gesetzt

Wenn <dialog> mit showModal() verwendet werden kann, ist die Inert-Grenze kostenlos enthalten. Manuelles inert ist dann angebracht, wenn Bedenken hinsichtlich der AT-Unterstützung oder gestalterische Einschränkungen einen benutzerdefinierten Dialog erfordern.

Browserunterstützung und die aufkommende CSS-interactivity-Property

inert wurde im April 2023 als Baseline Newly available eingestuft — Chrome und Edge ab Version 102, Firefox ab 112 und Safari ab 15.5 — und erreichte um Oktober 2025 den Status Baseline Widely available (30 Monate nach dem interoperablen Datum). Das wicg-inert-Polyfill ist nun eher historischer Kontext als eine Produktionsanforderung; sein letztes Release ist v3.1.3 (2023) und es wird nicht mehr aktiv gepflegt. Die eigene README-Datei weist darauf hin, dass das Polyfill „performance-technisch aufwendig” ist, da es „erhebliches Durchlaufen des DOM-Baums erfordert” — Kosten, die die native Implementierung vermeidet. Für jeden seit 2023 ausgelieferten Browser ist es nicht mehr erforderlich.

Eine neuere CSS-basierte Alternative ist die interactivity-Property, die interactivity: inert akzeptiert, um Inert-Verhalten über ein Stylesheet statt über ein Attribut anzuwenden. Es handelt sich um eine aufkommende Funktion mit eingeschränkter Unterstützung: Laut caniuse-Daten ist sie nur in Chromium verfügbar (Chrome/Edge 135+, März 2025), ohne Firefox- oder Safari-Unterstützung Stand Mitte 2026, und sie hat nicht den Baseline-Status (Limited availability). Sie sollte als zukunftsorientierte Option für Chromium-spezifische Kontexte betrachtet werden, nicht als browserübergreifender Ersatz für das Attribut.

Fazit

Für die Absicherung von Hintergrundinhalt hinter einem Modal, Drawer oder Lade-Overlay ersetzt inert den gesamten fragilen Apparat aus manuell implementierten Focus-Traps und aria-hidden-Wildwuchs durch ein einziges Attribut, das der Browser über Tastatur-, Zeiger- und assistive Technologienavigation hinweg durchsetzt. Bestehende Dialoge sollten überprüft werden: Wenn ein Tastaturnutzer aus einem geöffneten Modal heraus in den dahinterliegenden Seiteninhalt tabben kann, sollte dieser Hintergrundinhalt — oder das <main>-Element — mit inert versehen, mit element.inert beim Öffnen und Schließen umgeschaltet und der Fokus auf den Auslöser zurückgesetzt werden. Da das Attribut seit 2025 als Widely available gilt, bleibt als einzige verbleibende Entscheidung, ob das native <dialog>-Element die Grenze bereits kostenlos mitliefert.

Häufig gestellte Fragen

Was ist der Unterschied zwischen dem inert-Attribut und aria-hidden?

Das inert-Attribut blockiert Interaktionen und entfernt Inhalte aus dem Accessibility-Tree, sodass der Teilbaum weder erreichbar noch auffindbar ist. Das aria-hidden-Attribut entfernt Inhalte hingegen nur aus dem Accessibility-Tree; es blockiert weder Klicks, Fokus noch Tastaturinteraktion. aria-hidden auf Hintergrundinhalt zu setzen, während er weiterhin klickbar und fokussierbar bleibt, ist ein häufiger Fehler, da diese Elemente in der Tab-Reihenfolge verbleiben. inert sollte verwendet werden, wenn Interaktionen für einen gesamten Teilbaum blockiert werden sollen.

Blockiert inert JavaScript-Event-Listener und programmatische Ereignisse?

Nein. Das inert-Attribut blockiert nutzerinitiierte Ereignisse wie Klicks, Fokus und Zeigerinteraktion, stoppt jedoch keine programmatischen Ereignisse. Ein dispatchEvent-Aufruf, ein Timer-Callback oder jedes andere Skript, das innerhalb eines inerten Teilbaums ausgeführt wird, läuft weiterhin normal. Anders als die alert-Funktion friert inert die JavaScript-Ausführung nicht ein; es ändert lediglich, wie der Browser Nutzerinteraktionen und Accessibility-Erkennung an den markierten Teilbaum weiterleitet.

Wird noch ein JavaScript-Polyfill für inert benötigt?

Nein, für jeden seit 2023 ausgelieferten Browser nicht mehr. Das inert-Attribut wurde im April 2023 als Baseline Newly available eingestuft — mit Chrome und Edge 102, Firefox 112 und Safari 15.5 — und erreichte um Oktober 2025 den Status Baseline Widely available. Das wicg-inert-Polyfill ist nun eher historischer Kontext als eine Produktionsanforderung; sein letztes Release ist v3.1.3 aus dem Jahr 2023 und es wird nicht mehr aktiv gepflegt. Die README-Datei weist zudem darauf hin, dass es performance-technisch aufwendig ist, da es DOM-Baum-Traversierung erfordert, die native Implementierungen vermeiden.

Warum versagen traditionelle Focus-Traps bei mobilen Screenreadern?

Traditionelle Focus-Traps versagen auf mobilen Geräten, weil TalkBack auf Android und VoiceOver auf iOS per Wischgesten statt per Tab-Tasten navigieren. Ein JavaScript-Trap, der nur Tastaturereignisse abfängt, bietet für wischbasierte Screenreader-Nutzer keinerlei Begrenzung, sodass sie aus dem Dialog in den Hintergrundinhalt entkommen können. Das inert-Attribut blockiert den Teilbaum auf Plattformebene und deckt sowohl Tastaturnavigation als auch Gestennavigation ab — weshalb es die manuelle Focus-Trap-Logik zur Begrenzung von Modals ersetzt.