Barrierefreies Akkordeon: details/summary zuerst

Ein barrierefreies Akkordeon baust du zuerst mit <details> und <summary> – ohne JavaScript: Der Browser liefert Fokus, Bedienung per Enter und Leertaste und die Zustandsansage mit, das name-Attribut schließt auf Wunsch die anderen Bereiche. Das ARIA-Pattern mit Button in der Überschrift, aria-expanded und aria-controls bleibt der Sonderfall für Verhalten, das das native Element nicht hergibt.

Das Wichtigste in Kürze

• <details>/<summary> ist seit Januar 2020 in allen Browser-Engines verfügbar: Fokus, Tastaturbedienung und Zustandsansage ohne JavaScript; <summary> muss das erste Kindelement sein.
• Das name-Attribut macht mehrere <details> ohne Skript zum exklusiven Akkordeon – Stand Juli 2026: Chrome/Edge 120+, Safari 17.2+, Firefox 130+, rund 87 % Support.
• Die Seitensuche (Strg+F) öffnet geschlossene <details> Stand Juli 2026 in allen Engines: Chrome seit 97, Firefox seit 139, Safari seit 26.2 (Dezember 2025).
• Beim Eigenbau: echter Button im Überschriftenelement, aria-expanded wechselt per Skript, aria-controls zeigt aufs Panel – sonst fällt WCAG 4.1.2 (Stufe A).
• Eingeklappte Inhalte mit hidden oder display: none verbergen; opacity: 0 lässt sie fokussierbar.
• BFIT-Bund: Beschriftung 4,5:1 Kontrast, Indikator 3:1, Klickfläche mindestens 24 × 24 px.
• Google zeigt seit dem 7. Mai 2026 keine FAQ-Rich-Results mehr; Inhalte in geschlossenen Akkordeons indexiert Google trotzdem.

Der erste Weg: <details> und <summary>

Ein Akkordeon klappt Inhaltsbereiche über ihre Überschriften auf und zu – dieses Disclosure-Muster liefert HTML fertig mit: <details> und <summary> sind fokussierbar, mit Enter und Leertaste bedienbar und melden ihren Zustand an die Accessibility-API. Laut MDN ist das Element seit Januar 2020 in allen Engines verfügbar – Baseline „widely available“.

<details>
  <summary>Wie hoch sind die Versandkosten?</summary>
  <p>Innerhalb Deutschlands versenden wir ab 50 € kostenfrei, darunter 4,90 €.</p>
</details>

Zwei Regeln: <summary> muss das erste Kindelement sein, sonst setzt der Browser eine generische Standard-Beschriftung ein (laut MDN typischerweise „Details“). Das open-Attribut spiegelt und steuert den Zustand – es öffnet ein Panel vorab und dient als Style-Hook (details[open], neuer details:open).

Der unterschätzte Vorteil: Wirft ein Skript einen Fehler, funktioniert das details-Akkordeon weiter – das ARIA-Pattern nicht. Das ist die erste Regel von ARIA in Reinform.

Die Überschrift gehört in summary – nicht umgekehrt

Damit das Akkordeon in der Überschriften-Hierarchie auftaucht, darf genau ein Überschriftenelement ins <summary>:

<details name="faq">
  <summary><h3>Wie lange dauert die Lieferung?</h3></summary>
  <p>In der Regel zwei bis drei Werktage.</p>
</details>

Beim ARIA-Pattern ist die Systematik umgekehrt: Dort sitzt der Button in der Überschrift. Scott O’Hara dokumentierte 2022, dass Überschriften im summary nicht zuverlässig exponiert werden – summary wird auf role="button" abgebildet, und Buttons machen ihre Kinder präsentational; auch die Rolle variiert – Firefox/NVDA sagen „Schalter“, Safari/VoiceOver „Zusammenfassung“, Chrome/VoiceOver „Aufklappdreieck“. Deshalb: summary knapp in Textform beschriften, keine weiteren Bedienelemente hinein (laut BFIT-Bund-Handreichung dort teils nicht wahrnehmbar) – und nie role="button" aufs summary, sonst verliert Safari/VoiceOver die Auf-/Zugeklappt-Ansage.

Nur eins offen: das name-Attribut

Sollen sich die anderen Bereiche beim Öffnen automatisch schließen, reicht ein gemeinsamer name-Wert – dasselbe Prinzip wie bei input type="radio":

<details name="versand">
  <summary><h3>Versandkosten</h3></summary>
  <p>Ab 50 € kostenfrei.</p>
</details>
<details name="versand">
  <summary><h3>Lieferzeit</h3></summary>
  <p>Zwei bis drei Werktage.</p>
</details>

Die Gruppe entsteht über den name-Wert, nicht über die DOM-Nachbarschaft; tragen mehrere Elemente ein open-Attribut, bleibt nur das erste offen. Stand Juli 2026: Chrome/Edge 120 und Safari 17.2 (Dezember 2023), Firefox 130 (September 2024), rund 87 % globaler Support laut caniuse – produktionsreif; ältere Browser lassen schlicht mehrere Panels offen. Eine UX-Warnung, die MDN verschweigt: Das automatische Schließen verschiebt die Scrollposition – exklusiv also nur, wenn die Abschnitte echte Alternativen sind.

Die Seitensuche findet, was eingeklappt ist

Der Einwand „Strg+F findet nichts“ ist Geschichte: Chromium öffnet geschlossene <details> bei einem Suchtreffer automatisch (seit Version 97, Januar 2022), Firefox seit 139 (Mai 2025), Safari seit 26.2 (Dezember 2025) – Stand Juli 2026 also alle Engines.

Selbstgebaute Akkordeons erreichen dasselbe mit hidden="until-found": Der Browser versteckt das Panel mit content-visibility: hidden statt display: none, die Inhalte bleiben durchsuchbar, bei einem Treffer feuert beforematch und der Browser scrollt hin. Zwei Fallstricke: Eigenes display: none verhindert die Aufdeckung, und aria-expanded musst du im beforematch-Handler nachziehen. Support: Chrome/Edge seit 102 (2022), Firefox seit 139, Safari seit 26.2 – seit Dezember 2025 Baseline „newly available“.

Styling ohne Semantik-Schaden

<summary> hat display: list-item; das Standard-Dreieck entfernst du über list-style: none bzw. ::marker; MDN nennt zusätzlich display: block. Ein eigener Chevron ist Dekoration und bekommt aria-hidden="true". Den Inhaltsbereich animiert ::details-content (Stand Juli 2026: Chrome/Edge 131+, Firefox 143+, Safari 18.4+, rund 83 %):

summary { list-style: none; }
summary::-webkit-details-marker { display: none; }

@media (prefers-reduced-motion: no-preference) {
  :root { interpolate-size: allow-keywords; } /* Stand Juli 2026 nur Chromium */
  ::details-content {
    height: 0;
    overflow: clip;
    transition: height 0.25s, content-visibility 0.25s allow-discrete;
  }
  details[open]::details-content { height: auto; }
}

interpolate-size: allow-keywords animiert zu height: auto, bislang nur in Chromium; der prefers-reduced-motion-Rahmen ist Pflicht.

Wann das ARIA-Pattern nötig bleibt

Selbst bauen lohnt in drei Fällen: browserübergreifend identische Rollenausgabe, Animation ohne Chromium-only-CSS oder „mindestens eins offen“-Logik – dafür sieht das W3C-Accordion-Pattern aria-disabled="true" am offenen, nicht schließbaren Kopf vor:

<h3>
  <button type="button" id="kopf-versand"
          aria-expanded="false" aria-controls="panel-versand">
    Wie hoch sind die Versandkosten?
    <svg aria-hidden="true" viewBox="0 0 16 16" width="16" height="16"><path d="M2 5l6 6 6-6" fill="none" stroke="currentColor" stroke-width="2"/></svg>
  </button>
</h3>
<div id="panel-versand" role="region" aria-labelledby="kopf-versand" hidden="until-found">
  <p>Innerhalb Deutschlands versenden wir ab 50 € kostenfrei.</p>
</div>

Der Kopf ist ein echtes <button> in einem Überschriftenelement, in dem sonst nichts steht. Umgekehrt – Überschrift im Button – verliert sie ihre Semantik, denn Buttons machen ihre Kinder rein präsentational; das reißt 1.3.1 Info und Beziehungen. aria-expanded wechselt per Skript, aria-controls verweist auf die Panel-ID. role="region" mit aria-labelledby ist optional – das W3C rät ab etwa sechs gleichzeitig öffenbaren Panels davon ab. Tastatur: Tab und Shift+Tab erreichen alle Köpfe, Enter oder Leertaste schaltet um (Pflicht); Pfeiltasten und Pos1/Ende sind optional, anders als bei Tabs.

const kopf = document.getElementById('kopf-versand');
const panel = document.getElementById('panel-versand');

kopf.addEventListener('click', () => {
  const offen = kopf.getAttribute('aria-expanded') === 'true';
  kopf.setAttribute('aria-expanded', String(!offen));
  panel.hidden = offen ? 'until-found' : false;
});

// Die Seitensuche deckt das Panel selbst auf – Zustand nachziehen:
panel.addEventListener('beforematch', () => {
  kopf.setAttribute('aria-expanded', 'true');
});

Ein <a> ohne href oder ein <div> als Kopf ist keine Ersatzlösung: Der BITV-Prüfschritt 9.4.1.2 nennt genau das als Fehlerfall – unsemantische Elemente ohne vollständige ARIA-Nachbildung. Warum das echte Element gewinnt, steht unter Buttons vs. Links.

Drei sichere Wege, es kaputtzumachen

Aus Prüfberichten, mit dem Kriterium, das jeweils fällt:

<!-- 1. Klickbare Überschrift ohne Button: kein Fokus, keine Rolle, kein Zustand -->
<h3 class="kopf" onclick="umschalten(this)">Versandkosten</h3>

<!-- 2. Chevron-Rotation als einziges Zustandssignal: visuell hui, programmatisch nichts -->
<button type="button" class="kopf offen">Versandkosten <span class="chevron"></span></button>

<!-- 3. Panel nur visuell versteckt: bleibt per Tab erreichbar (Geisterfokus) -->
<div class="panel" style="opacity: 0; height: 0;">
  <a href="/versand">Zur Versandübersicht</a>
</div>

Nummer 1 verletzt 2.1.1 Tastatur und 4.1.2 Name, Rolle, Wert gleichzeitig – beide Stufe A. Nummer 2 fällt bei 4.1.2, weil der Zustand nur im CSS existiert. Nummer 3 lässt Tastaturnutzende in unsichtbare Links tabben – der Fokus steht auf Unsichtbarem und verletzt 2.4.7 Fokus sichtbar (Stufe AA); 2.4.3 Fokus-Reihenfolge greift nach BITV-Prüfschritt 9.2.4.3 erst ab vier unsichtbaren Stationen in Folge. Richtig ist hidden oder display: none.

FAQ-Inhalte, Schema und SEO

Die Sorge, Google könne eingeklappte Inhalte nicht lesen, ist unbegründet: Was im DOM steht, wird indexiert. Beim FAQ-Schema hat sich mehr getan: Google zeigt seit dem 7. Mai 2026 keine FAQ-Rich-Results mehr an – auch nicht für Behörden- und Gesundheitsseiten, deren Ausnahme seit August 2023 galt. FAQPage bleibt ein gültiger schema.org-Typ und schadet nicht, bringt aber kein Suchergebnis-Feature mehr; was sich bei strukturierten Daten noch lohnt, ist ein eigenes Thema.

Und grundsätzlich: Akkordeons sparsam einsetzen – jeder Abschnitt kostet einen Extra-Klick, schlecht umgesetzte wirken im Screenreader wie eine Textwüste.

So testest du es

1. Tabbe durch alle Köpfe: Jeder muss erreichbar sein und einen sichtbaren Fokus zeigen.
2. Drücke Enter und Leertaste: Beides muss öffnen und schließen. Scrollt die Leertaste stattdessen die Seite, ist der Kopf kein echter Button.
3. Tabbe bei geschlossenem Panel weiter: Landet der Fokus in unsichtbarem Inhalt, ist das Panel nur visuell versteckt.
4. Prüfe mit NVDA oder VoiceOver, ob „zugeklappt“ bzw. „erweitert“ angesagt wird und beim Umschalten wechselt.
5. Suche per Strg+F nach einem Wort aus einem geschlossenen Panel (Chrome, Firefox oder Safari 26.2+): Es sollte sich öffnen.
6. Miss Kontrast und Größe: Beschriftung 4,5:1, Indikator 3:1 – etwa mit dem Kontrast-Check – und Klickfläche mindestens 24 × 24 px.

Die BFIT-Bund-Handreichung führt diese Anforderungen als Nummern 827–845 mit EN-301-549-Mapping – inklusive Fokuserhalt beim Zuklappen und Fokusreihenfolge entlang der visuellen Reihenfolge.

Häufiger Fehler in der Praxis

Das Pagebuilder-Akkordeon. In fast jeder BITV-Prüfung, die ich begleitet habe, steckte ein Theme-Akkordeon aus klickbaren <div>-Köpfen – mit der Maus tadellos, fällt bei 9.4.1.2 durch, oft nur per Template-Override reparabel. Also vor dem Theme-Kauf per Tastatur durch die Demo tabben.

Acht Mal „Mehr erfahren“. Heißt jede summary gleich, ist die Schalterliste im Screenreader wertlos – das reißt 2.4.6 Überschriften und Beschriftungen. Die Beschriftung nennt den Inhalt, nicht die Aktion.

Fokusverlust beim Zuklappen. Schließt ein Skript das Panel, in dem der Fokus steht, springt er an den Seitenanfang. Vor dem Verstecken den Fokus auf den zugehörigen Kopf setzen.

<details> oder Button mit aria-expanded? Der Komponenten-Baukasten stellt beide Varianten nebeneinander – mit bedienbarer Vorschau, Code und Testprotokoll.

Häufige Fragen

Ist ein Akkordeon mit details und summary barrierefrei?

Ja – <details>/<summary> erfüllt die Kernanforderungen von Haus aus: fokussierbar, mit Enter und Leertaste bedienbar, der Zustand geht an die Accessibility-API. Deine Aufgaben bleiben sichtbarer Fokus, Kontrast (4,5:1 Beschriftung, 3:1 Indikator), eine knappe Text-Beschriftung im summary und logische Überschriftenebenen. Die Rollen-Ansage variiert je nach Browser, bedienbar ist es überall.

Wie öffnet sich beim Akkordeon immer nur ein Bereich gleichzeitig?

Mit dem name-Attribut: Alle <details> der Gruppe bekommen denselben Wert, der Browser schließt beim Öffnen automatisch die anderen – ohne JavaScript. Stand Juli 2026 unterstützen das Chrome/Edge 120+, Safari 17.2+ und Firefox 130+. Ältere Browser ignorieren das Attribut, dann bleiben mehrere Panels offen – ein sauberer Fallback ohne Funktionsverlust.

Findet die Browsersuche (Strg+F) Inhalte in geschlossenen Akkordeons?

In Chrome (seit 97), Firefox (seit 139) und Safari (seit 26.2) ja: Die Seitensuche öffnet das passende <details> automatisch – Stand Juli 2026 also überall. Selbstgebaute Akkordeons erreichen dasselbe mit hidden="until-found" statt hidden – in Chrome/Edge seit 102, in Firefox seit 139, in Safari seit 26.2 (Dezember 2025).

Lohnt sich FAQ-Schema für Akkordeon-FAQs 2026 noch?

Als Suchergebnis-Feature nicht mehr: Google zeigt seit dem 7. Mai 2026 keine FAQ-Rich-Results mehr an, auch nicht für Behörden- und Gesundheitsseiten. FAQPage bleibt ein gültiger schema.org-Typ und schadet laut Google nicht – es bringt nur kein Suchergebnis-Extra mehr. Für KI-Systeme und die maschinenlesbare Struktur kann es weiter sinnvoll sein.

Verwandte Themen

• details und summary im Detail – das Element von Grund auf
• Tabs – das Nachbarmuster mit Pfeiltasten-Pflicht
• Menüs und Dropdowns – Disclosure für Navigation
• Die erste Regel von ARIA – natives HTML vor jedem Nachbau
• Tastaturbedienung und sichtbarer Fokus – Fokusreihenfolge und Fokus-Styles
• Rollen, States und Properties – was aria-expanded technisch tut

Quellen

• Accordion Pattern (W3C ARIA Authoring Practices Guide – Tastaturverhalten, ARIA-Attribute, region-Warnung)
• Das details-Element (MDN – name-Attribut, open, Baseline-Status)
• Handreichung Akkordeon (BFIT-Bund – Anforderungen 827–845 mit EN-301-549-Mapping)
• Google beendet FAQ-Rich-Results (Search Engine Land, Mai 2026)