details & summary: native Aufklapp-Bereiche

<details> und <summary> sind das eingebaute Element-Paar für aufklappbare Bereiche: Der Browser liefert Bedienelement, Tastaturbedienung und Zustandsansage mit, ohne eine Zeile JavaScript und ohne ARIA. Mit dem Attribut name wird daraus ein echtes Akkordeon, in dem immer nur ein Bereich offen ist.

Das Wichtigste in Kürze

• <details> umschließt den Bereich, das erste Kind muss ein <summary> sein – das ist die anklickbare Beschriftung.
• Ohne <summary> zeigen Browser eine eigene Beschriftung an (meist „Details“). Das ist fast immer ein Fehler.
• Das Attribut open steuert den Startzustand. Der Browser setzt und entfernt es selbst, der DOM spiegelt also immer den echten Zustand.
• Gleicher name an mehreren <details> erzeugt ein exklusives Akkordeon – verfügbar seit Chrome 120, Edge 120, Safari 17.2 und Firefox 130.
• Das toggle-Ereignis meldet Zustandswechsel und liefert oldState und newState.
• Seit 2025 lässt sich der Aufklappbereich mit ::details-content gestalten und animieren.
• <details> hat die Rolle group. Die Rolle des <summary> ist nicht vereinheitlicht – je nach Browser und Screenreader „Schaltfläche“, „Aufklapp-Dreieck“ oder „Summary“.
• Vorsicht beim Entfernen des Dreiecks: In manchen Kombinationen ist es der einzige Hinweis auf den Zustand. Dann braucht es einen sichtbaren Ersatz.
• WCAG-Bezug: 4.1.2 Name, Rolle, Wert (Stufe A) verlangt genau die Rolle und den Zustand, die das native Element mitbringt.

Aufbau: zwei Elemente, eine Aufgabe

<details> umschließt den gesamten Bereich. Das erste Kind ist immer ein <summary> – die sichtbare, anklickbare Beschriftung. Alles danach ist der Inhalt, der auf- und zuklappt:

<details>
  <summary>Versand &amp; Lieferzeit</summary>
  <p>Innerhalb Deutschlands liefern wir in zwei bis drei Werktagen.</p>
</details>

Den Rest erledigt der Browser: Das <summary> ist fokussierbar, per Enter und Leertaste bedienbar und wird als aufklappbarer Bereich samt Zustand angekündigt. Diese Arbeit musst du dir nicht selbst machen – und genau darin liegt der Grundgedanke von semantischem HTML: erst schauen, was die Plattform schon kann.

Das open-Attribut

Standardmäßig ist ein <details> zugeklappt. Mit open startet es aufgeklappt – praktisch für den Abschnitt, den die meisten zuerst sehen sollen:

<details open>
  <summary>Worum geht es hier?</summary>
  <p>Diese Anleitung zeigt Schritt für Schritt …</p>
</details>

open ist mehr als Optik: Der Browser setzt und entfernt es selbst, sobald auf- oder zugeklappt wird. Du kannst dich also darauf verlassen, dass der DOM den tatsächlichen Zustand widerspiegelt – etwa für den CSS-Selektor details[open] oder ein Skript.

Ein Detail zu Boolean-Attributen, das regelmäßig für Verwirrung sorgt: open="false" klappt nicht zu. Boolean-Attribute wirken über ihre Anwesenheit, nicht über ihren Wert. Zum Zuklappen muss das Attribut weg.

// Falsch: das Element ist danach weiterhin offen
details.setAttribute('open', 'false');

// Richtig
details.open = false;

Nur eines offen: das name-Attribut

Bekommen mehrere <details> denselben name, bilden sie eine Gruppe, in der immer nur eines geöffnet ist – ein Akkordeon ohne Skript:

<details name="faq">
  <summary>Wie hoch sind die Versandkosten?</summary>
  <p>Ab 50 € liefern wir kostenfrei …</p>
</details>
<details name="faq">
  <summary>Wie lange dauert die Lieferung?</summary>
  <p>In der Regel zwei bis drei Werktage …</p>
</details>

Probier es direkt aus – öffne einen Bereich, und der zuvor geöffnete schließt sich von selbst:

Zwei Regeln dazu: Innerhalb einer name-Gruppe darf höchstens ein <details> das open-Attribut im Quelltext tragen – mehrere sind ungültiges HTML. Und die Gruppe muss nicht zusammenhängend im Dokument stehen; der name genügt.

Verfügbar ist die Funktion seit Chrome und Edge 120, Safari 17.2 und Firefox 130, also seit Herbst 2024 in allen aktuellen Browsern. In älteren Browsern fehlt nur die „nur eines offen“-Logik – die Bereiche lassen sich weiterhin einzeln auf- und zuklappen. Ein Beispiel für Progressive Enhancement: Die Funktion verbessert das Erlebnis, ohne dass etwas kaputtgeht.

Auf Zustandswechsel reagieren: toggle

Wenn du doch Skript brauchst – etwa fürs Nachladen von Inhalten oder ein Analyse-Ereignis – ist toggle der richtige Anknüpfungspunkt. Es feuert nach dem Zustandswechsel und liefert beide Zustände mit:

const bereich = document.querySelector('#versand');

bereich.addEventListener('toggle', (event) => {
  // event.oldState / event.newState: "open" oder "closed"
  if (event.newState === 'open') {
    inhalteNachladen();
  }
});

Mehrere schnelle Wechsel fasst der Browser zu einem Ereignis zusammen. Was toggle nicht tut: den Vorgang abbrechen. preventDefault() hat hier keine Wirkung – wer das Aufklappen verhindern will, muss das Klick-Ereignis am <summary> behandeln, und das ist meistens ein Zeichen dafür, dass ein anderes Muster passender wäre.

Gestalten mit CSS

Das Dreieck vor dem <summary> ist ein Listenmarker – <summary> hat laut Spezifikation display: list-item. Entsprechend lässt es sich über list-style und ::marker ansprechen:

summary {
  cursor: pointer;
}

/* Eigenes Symbol statt Dreieck */
summary::marker {
  content: '+ ';
  font-family: monospace;
  font-weight: 700;
}
details[open] summary::marker {
  content: '− ';
}

details[open] > summary {
  font-weight: 700;
}

Drei Stolpersteine, die man kennen sollte:

• display: block am <summary> entfernt das Dreieck. Das ist kein Bug, sondern die Folge davon, dass list-item überschrieben wird. Wer den Marker behalten will, nutzt display: flex mit list-style-position: inside – oder setzt bewusst ein eigenes Symbol.
• Safari braucht teils ::-webkit-details-marker. Ältere WebKit-Versionen kennen ::marker am <summary> nicht; summary::-webkit-details-marker { display: none } räumt das Standarddreieck dort weg.
• cursor: pointer ist nicht gesetzt. Der Standard-Cursor über einem <summary> ist der Textcursor, was das Element weniger wie ein Bedienelement wirken lässt.

Animieren mit ::details-content

Lange ließ sich das Aufklappen nicht animieren, weil der Inhalt keine eigene Formatierungsschicht hatte. Seit 2025 gibt es dafür das Pseudoelement ::details-content – Baseline „newly available“ seit September 2025, also in allen aktuellen Browsern:

details::details-content {
  opacity: 0;
  block-size: 0;
  overflow: hidden;
  transition:
    opacity 300ms,
    block-size 300ms,
    content-visibility 300ms allow-discrete;
}

details[open]::details-content {
  opacity: 1;
  block-size: auto;
}

@media (prefers-reduced-motion: reduce) {
  details::details-content {
    transition: none;
  }
}

Der Schlüssel ist allow-discrete: Ohne dieses Schlüsselwort springt content-visibility sofort um und die Animation ist nicht sichtbar. Und die prefers-reduced-motion-Abfrage gehört dazu – Bewegung ist für manche Menschen ein Problem, nicht nur Geschmackssache.

Was Screenreader daraus machen

Hier wird es unübersichtlicher, als es sein müsste. <details> hat laut ARIA in HTML die Rolle group. Für <summary> ist keine Rolle festgelegt, und die Browser handhaben es unterschiedlich: Manche exponieren es als button, andere als „Aufklapp-Dreieck“, wieder andere als „Summary“. Die Zustandsansage – aufgeklappt oder zugeklappt – kommt in allen gängigen Kombinationen, aber nicht überall mit denselben Worten.

Praktische Folgen daraus:

• Überschrift im <summary>: Das Inhaltsmodell erlaubt Überschriften. Weil einige Browser das <summary> aber als Button behandeln und Kindelemente dann als präsentational gelten, kann die Überschrift für Screenreader verschwinden. Wenn du sie brauchst, damit der Bereich in der Überschriftenliste auftaucht, teste sie – blind darauf verlassen würd ich mich nicht. Die Alternative: Überschrift vor dem <details>, nicht darin. Mehr zur Hierarchie unter Überschriften-Hierarchie.
• role="button" nicht nachrüsten. Es überschreibt die native Semantik und kann die Zustandsansage kosten – genau der Fall, den die erste Regel von ARIA beschreibt.
• Keine interaktiven Elemente ins <summary>. Ein Link oder Button innerhalb der Beschriftung ist bedienbar, aber die Fokusreihenfolge und die Ansage werden unvorhersehbar. Solche Elemente gehören in den Inhaltsbereich.
• Marker nicht ersatzlos entfernen. In einigen Browser-Screenreader-Kombinationen vermittelt das Dreieck den Zustand. Wenn du list-style: none setzt, setz ein eigenes sichtbares Symbol an dessen Stelle.

Nachprüfen lässt sich das in wenigen Minuten – die Anleitungen stehen unter Mit NVDA testen und Mit VoiceOver testen.

Randnotiz – auch für Crawler ein Gewinn. Der Inhalt eines geschlossenen <details> steht ganz normal im HTML und ist damit für Suchmaschinen und KI-Crawler lesbar. Anders als bei per JavaScript nachgeladenen Aufklapp-Boxen geht hier keine Information verloren. Chromium-Browser klappen ein <details> außerdem automatisch auf, wenn der gesuchte Text per Seitensuche (Strg+F) darin gefunden wird – Firefox und Safari tun das bislang nicht. Für die Sichtbarkeit von FAQ-Inhalten ist das ein Argument gegen jede Skript-Lösung, die Text erst beim Klick in den DOM schreibt; siehe Semantik & SEO.

So testest du ein details in zwei Minuten

1. Mit der Tastatur bedienen. Mit Tab auf das <summary>. Ist ein Fokusrahmen sichtbar? Klappt Enter auf, klappt Leertaste auf? Beide müssen funktionieren (2.1.1 Tastatur, Stufe A).
2. Zustand prüfen. Aufklappen, dann im Inspektor nachsehen: Steht open am <details>? Verschwindet es beim Zuklappen wieder?
3. Seitensuche testen. Einen Begriff aus dem geschlossenen Bereich mit Strg+F suchen. In Chromium klappt der Bereich auf – falls nicht, ist der Inhalt vermutlich per Skript ausgeblendet statt per <details>.
4. Screenreader anwerfen. Über das <summary> fahren und auf zwei Dinge hören: die Beschriftung und den Zustand. Fehlt der Zustand, liegt es meist an entferntem Marker oder nachgerüstetem role.
5. Ohne Maus zuklappen und weitertabben. Landet der Fokus nach dem Zuklappen noch auf dem <summary> und nicht am Seitenanfang?

Wann <details> passt – und wann nicht

Gut geeignet ist es überall, wo ein Bereich optional sichtbar sein soll: FAQ, „Mehr anzeigen“, weiterführende Hinweise, erweiterte Einstellungen, technische Details unter einer Abbildung. Auch für Inhalte, die lange Seiten kürzer machen sollen, ist es das richtige Werkzeug – der Text bleibt im HTML und damit auffindbar.

Nicht geeignet ist es in vier Fällen:

• Hauptnavigation. Ein aufklappbares Menü folgt einem eigenen Muster mit Pfeiltastenlogik und Schließen per Escape – siehe Menüs & Dropdowns.
• Verhalten über Auf- und Zuklappen hinaus: „alle ausklappen“, gesteuerte Animationen mit Zwischenzuständen, Bereiche, die von außen gesteuert werden. Dann ist die ARIA-Variante mit <button aria-expanded> die richtige Wahl, wie unter Akkordeons barrierefrei umsetzen beschrieben.
• Inhalte, die auf Hover erscheinen sollen. <details> reagiert auf Klick, nicht auf Zeigerbewegung. Für Hinweise am Zeiger gilt 1.4.13 Inhalt bei Hover oder Fokus – umgesetzt unter Tooltips & Popover-API.
• Pflichtinhalte. Was jede Besucherin lesen muss – Preisangaben, Widerrufsrecht, wesentliche Produktmerkmale –, gehört nicht hinter einen Klick.

Häufiger Fehler in der Praxis

Der Fehler, der mir am häufigsten begegnet, ist die FAQ hinter <details> mit dem Argument „spart Platz“. Technisch tadellos, für Screenreader gut bedienbar – und für die Leserinnen und Leser oft schlechter als eine offene Liste. Denn wer eine Frage sucht, muss jede einzeln aufklappen. Bei fünf Fragen ist das in Ordnung, bei fünfzehn wird es zur Klickstrecke.

Mein Kompromiss auf dieser Website: Die Antworten stehen offen im HTML, weil sie kurz sind. Aufklappbereiche setze ich für Inhalte ein, die wirklich nur eine Minderheit braucht – ein langes Codebeispiel, eine Tabelle mit Rohdaten, eine Ausnahmeregelung. Die Frage ist nicht „lässt sich das zuklappen“, sondern „wollen die meisten es lesen“.

Der zweite Klassiker: Ein <details> als Container für ein Formularfeld, das erst nach Auswahl relevant wird. Wenn das Feld ein Pflichtfeld ist, blockiert der geschlossene Bereich das Absenden – der Browser kann den Fokus nicht auf ein verborgenes Feld setzen und zeigt die Validierungsmeldung ins Leere. Solche Abhängigkeiten löst man mit hidden und Skript, nicht mit <details>; die Grundlagen stehen unter Formular-Semantik.

Häufige Fehler

• <summary> ist nicht das erste Kind. Steht etwas anderes an erster Stelle, funktioniert das Verhalten nicht mehr.
• Kein <summary>. Der Browser zeigt dann seine eigene Beschriftung, meist „Details“.
• Mehrere <summary> in einem <details>. Genau eines ist vorgesehen.
• open="false" in der Erwartung, dass es zuklappt.
• Zwei open in derselben name-Gruppe – ungültiges HTML.
• role oder aria-expanded nachrüsten. Überflüssig und potenziell schädlich.
• Marker per list-style: none entfernen, ohne sichtbaren Ersatz für den Zustand.
• Interaktive Elemente ins <summary> packen – Links, Buttons, Eingabefelder.
• Pflichtfelder in einem geschlossenen <details> – die Validierung läuft ins Leere.
• Aufklappbare Navigation aus <details> bauen, wo ein Disclosure-Menü passt.

Häufige Fragen

Brauche ich für <details> JavaScript?

Nein. Auf- und Zuklappen, Tastaturbedienung und die Zustandsansage sind nativ enthalten. Skript brauchst du erst, wenn du das Standardverhalten erweitern willst – dann reagierst du auf das toggle-Ereignis. Auch das exklusive Akkordeon läuft ohne Skript, über das name-Attribut.

Ist <details> dasselbe wie ein Akkordeon?

Es ist die einfachste Form davon. Mehrere <details> untereinander ergeben ein Akkordeon; mit gemeinsamem name ist immer nur eines offen. Sobald du „alle ausklappen“, gesteuerte Animationen mit Zwischenzuständen oder Steuerung von außen brauchst, ist die ARIA-Variante unter Akkordeons die passendere Lösung.

Kann ich das Standard-Dreieck ändern?

Ja. Es ist ein Listenmarker: summary::marker { content: '+ ' } ersetzt es, list-style: none entfernt es. In älteren Safari-Versionen brauchst du zusätzlich summary::-webkit-details-marker { display: none }. Wenn du es entfernst, setz ein eigenes sichtbares Symbol – in einigen Kombinationen ist das Dreieck der Zustandshinweis.

Darf eine Überschrift ins <summary>?

Das Inhaltsmodell erlaubt es, in der Praxis ist es unzuverlässig: Manche Browser behandeln das <summary> als Button und entfernen dabei die Rolle der Kindelemente – die Überschrift verschwindet dann aus der Überschriftenliste. Wenn dir die Sprungmarke wichtig ist, setz die Überschrift vor das <details> statt hinein.

Wird Text in einem geschlossenen <details> gefunden und indexiert?

Bei der Seitensuche kommt es auf den Browser an: Chromium-Browser klappen den Bereich beim Fund automatisch auf, Firefox und Safari tun das nach aktuellem Stand nicht. Für Suchmaschinen ist die Antwort einfacher – der Text steht im ausgelieferten HTML und wird normal indexiert. Anders sieht es nur aus, wenn der Inhalt erst per JavaScript beim Klick eingefügt wird; dann kann er fehlen.

Verwandte Themen

• Akkordeons barrierefrei umsetzen – die ARIA-Variante, wenn das native Element nicht reicht
• Menüs & Dropdowns – warum Navigation ein eigenes Muster braucht
• Die erste Regel von ARIA – das Prinzip hinter „nichts nachrüsten“
• 4.1.2 Name, Rolle, Wert – das Kriterium, das <details> von selbst erfüllt
• Struktur-Elemente – die anderen Elemente, die Verhalten mitbringen
• Tooltips & Popover-API – für Inhalte, die bei Hover erscheinen

Quellen

• 4.11.1 The details element (WHATWG HTML Standard – summary als erstes Kind, name-Gruppen und die Regel „nicht mehr als ein open pro Gruppe“)
• ::details-content (MDN Web Docs – Baseline „newly available“ seit September 2025, Animation mit allow-discrete)
• ARIA in HTML (W3C – details mit Rolle group, keine festgelegte Rolle für summary)
• Use the details element (but use it wisely) (Scott O’Hara – Screenreader-Tests zu den abweichenden Rollen und zum entfernten Marker)