html-einfach.de

Barrierefreie Komponenten · Navigation & Bedienelemente

Menüs & Dropdowns barrierefrei umsetzen

Von Zuletzt geändert am

Ausklappbare Menüs sind der Teil einer Website, an dem Barrierefreiheit am häufigsten kippt – und meist nicht aus Nachlässigkeit, sondern wegen einer verbreiteten Fehlannahme: dass ein Navigationsmenü die ARIA-Rolle menu brauche. Genau das ist in den meisten Fällen falsch und macht die Bedienung schlechter, nicht besser.

Der Grund: role="menu" und role="menubar" sind für Anwendungsmenüs gedacht – die Datei-/Bearbeiten-Menüs einer Desktop-App. Sie erzwingen ein bestimmtes Tastaturmodell (Pfeiltasten statt Tab) und Erwartungen, die für eine Website-Navigation schlicht nicht passen. Für aufklappbare Navigation empfiehlt der ARIA Authoring Practices Guide deshalb das Disclosure-Muster.

Das Disclosure-Muster

Ein Disclosure ist nichts weiter als ein Button, der einen Bereich ein- und ausblendet. Der Button trägt aria-expanded (Zustand) und aria-controls (Verweis auf das Panel); im Panel stehen ganz normale Links in einer Liste:

<nav aria-label="Hauptnavigation">
  <ul>
    <li>
      <button type="button" aria-expanded="false" aria-controls="menu-produkte">
        Produkte
      </button>
      <ul id="menu-produkte">
        <li><a href="/analyse.html">Analyse</a></li>
        <li><a href="/export.html">Export</a></li>
      </ul>
    </li>
  </ul>
</nav>

Das ist exakt das Muster, das auch das Mega-Menü dieser Website nutzt: Jeder Themenbereich hat einen <button aria-expanded>, der ein Panel mit normalen Links öffnet. Kein menubar, keine erzwungene Pfeiltasten-Navigation – einfach Buttons und Links, die jeder kennt.

Das erwartete Tastaturverhalten

Beim Disclosure gilt das vertraute Modell, und genau das ist der Vorteil:

  • Enter / Leertaste auf dem Button klappt auf und zu.
  • Tab läuft logisch weiter – in das geöffnete Panel hinein und wieder heraus. Kein Fokus-Trap.
  • Esc schließt das Menü und gibt den Fokus an den auslösenden Button zurück.

aria-expanded muss dabei den sichtbaren Zustand widerspiegeln – beim Öffnen auf true, beim Schließen auf false. Diese Synchronisierung ist der eigentliche Kern und der Teil, den eine reine CSS-Lösung (Hover bzw. :focus-within) noch nicht leisten kann.

Progressive Enhancement: erst ohne JS, dann mit

Ich baue solche Menüs gern so, dass sie ohne JavaScript grundsätzlich funktionieren und mit JavaScript besser werden. Zwei Wege dorthin:

  • Reines HTML: <details>/<summary> ist ein fertiges, natives Disclosure – ganz ohne Skript und ohne ARIA. Für einfache Aufklapp-Menüs oft schon genug.
  • CSS-Aufwertung: Panels per :hover und :focus-within öffnen, damit Maus, Touch und Tastatur das Menü auch ohne JS erreichen. Genau dieser Stand ist auf dieser Website aktuell umgesetzt; der nächste Schritt ist eine kleine JS-Schicht, die aria-expanded mitführt und Esc behandelt.

Wichtig ist mir dabei eine Regel: niemals nur Hover. Was sich ausschließlich mit der Maus öffnen lässt, ist auf dem Smartphone und per Tastatur unerreichbar.

Wann doch role="menu"?

Es gibt einen legitimen Fall: ein echtes Aktionsmenü – etwa ein „⋯ Weitere Aktionen“-Button, dessen Einträge Befehle auslösen (Umbenennen, Löschen, Teilen). So etwas verhält sich wie ein Anwendungsmenü, und dort sind role="menu" mit role="menuitem" und Pfeiltasten-Navigation tatsächlich richtig.

Meine Abgrenzung ist simpel: Sind es Links zu Seiten? Dann Disclosure mit <a>. Sind es Befehle, die etwas tun? Dann ist ein Menü mit menuitem denkbar – aber auch deutlich aufwendiger korrekt umzusetzen, weshalb ich es nur einsetze, wenn es wirklich passt.

Häufige Fehler

  • role="menubar" für die Seitennavigation. Erzwingt ein Tastaturmodell, das Nutzende hier nicht erwarten.
  • Nur per Hover bedienbar. Sperrt Touch- und Tastaturnutzung aus.
  • aria-expanded wird nicht aktualisiert. Der Button sagt „zu“, obwohl das Menü offen ist – eine falsche Ansage ist schlimmer als gar keine.
  • <div> als Auslöser. Der Trigger gehört auf ein <button>, sonst fehlen Fokus und Tastaturbedienung.
  • Fokus-Trap. Tab muss aus dem Menü auch wieder herauskommen.

Häufige Fragen

Disclosure und Akkordeon – ist das nicht dasselbe?

Im Kern ja: Beide bauen auf einem <button aria-expanded>, der einen Bereich zeigt oder verbirgt. Akkordeons sind die Anwendung dieses Musters auf Inhaltsabschnitte, Dropdown-Menüs die Anwendung auf Navigation.

Wie kennzeichne ich die aktuelle Seite im Menü?

Mit aria-current="page" am Link der aktiven Seite. So weiß auch ein Screenreader, wo man sich befindet. Diese Seite macht das im Mega-Menü und in den Breadcrumbs genauso.

Brauche ich für mehrere <nav>-Bereiche Labels?

Ja. Bei mehreren Navigationen sorgt aria-label für Unterscheidbarkeit – mehr dazu unter Struktur-Elemente.

Fazit

Für aufklappbare Navigation ist das Disclosure-Muster die richtige Wahl: ein <button aria-expanded>, der ein Panel mit normalen Links steuert – tastaturbedienbar mit dem vertrauten Tab-Modell, ohne erzwungene menubar-Mechanik. role="menu" hebst du dir für echte Befehlsmenüs auf. So bleibt das Menü für alle bedienbar, und du baust kein Tastaturmodell nach, das niemand erwartet.