Mega-Menüs barrierefrei umsetzen

Ein Mega-Menü ist ein großes, oft mehrspaltiges Aufklapp-Panel, das viele Links auf einmal zeigt – ideal für Websites mit vielen Themen. Es ist kein neues Muster, sondern die Anwendung des Disclosure-Prinzips im Großen. Genau so ist auch das Menü dieser Website gebaut, deshalb schreibe ich hier aus der Praxis – und fasse zusammen, was der ARIA Authoring Practices Guide, die WCAG und die Usability-Forschung dazu sagen.

Die Navigation ist der Teil einer Seite, an dem Barrierefreiheit am häufigsten kippt. Und beim Mega-Menü kommt zur Zugänglichkeit noch eine zweite Frage dazu: Ist das überhaupt die richtige UX-Entscheidung? Dieser Artikel beantwortet beide – erst ob, dann wie.

Wann sich ein Mega-Menü lohnt – und wann nicht

Bevor es um Code geht: Ein Mega-Menü ist ein Werkzeug für breite, flache Websites mit vielen gleichrangigen Themen. Die Usability-Forschung von Nielsen Norman ist hier deutlich – Mega-Menüs funktionieren gut, weil sie Struktur zeigen, statt sie erinnern zu lassen: Nutzende sehen die Bereiche nebeneinander, statt sich durch verschachtelte Ebenen zu hangeln.

Sinnvoll ist ein Mega-Menü, wenn …

• es viele Zielseiten gibt, die sich in klare Gruppen sortieren lassen,
• diese Gruppen gleichwertig nebeneinanderstehen (kein tiefer Baum),
• der Überblick auf einen Blick echten Wert hat – Shop-Kategorien, Themengebiete, Produktlinien.

Gegen ein Mega-Menü spricht, wenn die Seite nur eine Handvoll Punkte hat (dann reicht eine schlichte Navigation), wenn die Inhalte tief verschachtelt sind (dann eher eine eigene Übersichtsseite) oder wenn das Panel zur Resterampe für alles wird, was sonst nirgends passt. Ein überladenes Mega-Menü ist schwerer zu scannen als gar keins.

Die Struktur: Buttons und Listen

Das Fundament bleibt schlicht: eine Navigation mit einer Liste, deren Top-Einträge Buttons mit aria-expanded und aria-controls sind. Das Panel enthält die Links – bei Bedarf in mehreren Spalten mit Zwischenüberschriften, die über aria-labelledby mit ihrer Linkliste verbunden sind.

<nav aria-label="Hauptnavigation">
  <ul>
    <li>
      <button type="button" aria-expanded="false" aria-controls="panel-seo">
        SEO &amp; KI
      </button>
      <div id="panel-seo" hidden>
        <div>
          <p id="col-seo-basics" class="col-head">Grundlagen</p>
          <ul aria-labelledby="col-seo-basics">
            <li><a href="/seo-und-ki/title-und-meta-description.html">Title &amp; Meta</a></li>
            <li><a href="/seo-und-ki/interne-verlinkung.html">Interne Verlinkung</a></li>
          </ul>
        </div>
        <div>
          <p id="col-seo-ki" class="col-head">KI-Suche</p>
          <ul aria-labelledby="col-seo-ki">
            <li><a href="/seo-und-ki/llms-txt-einrichten.html">llms.txt</a></li>
          </ul>
        </div>
      </div>
    </li>
  </ul>
</nav>

Drei Dinge tragen die ganze Konstruktion:

• <button> statt <div> oder Link als Auslöser. Nur der Button bringt Fokus und Tastaturbedienung von Haus aus mit – siehe Buttons vs. Links.
• aria-expanded spiegelt den sichtbaren Zustand (false/true) und lässt sich zugleich als CSS-Selektor zum Ein- und Ausblenden nutzen.
• aria-controls verweist per ID auf das Panel, das der Button steuert.

Die Spaltenüberschriften stehen bewusst auf normalen Absätzen mit aria-labelledby, nicht auf <h2>/<h3>. So bekommt jede Linkliste einen zugänglichen Namen, ohne die Überschriften-Hierarchie der Seite mit Navigationsköpfen vollzustopfen.

Warum kein role="menubar"

Der teuerste Fehler bei Mega-Menüs ist eine gut gemeinte Zeile ARIA: role="menubar" mit role="menuitem" und aria-haspopup. Man findet dieses Muster in vielen Tutorials – und es ist für eine Website-Navigation schlicht das falsche Werkzeug.

role="menu" und role="menubar" stammen aus der Welt der Anwendungsmenüs – das Datei-/Bearbeiten-Menü einer Desktop-Software. Legt man sie über eine Navigation, passiert für Screenreader-Nutzende Folgendes:

• Die Links verschwinden aus der Linkliste. Als menuitem ausgezeichnete Links tauchen nicht mehr auf, wenn jemand per Screenreader-Kurzbefehl „alle Links dieser Seite“ aufruft – ein Werkzeug, auf das viele täglich angewiesen sind.
• Die Tastatur wird umgestellt. Der Screenreader kündigt Pfeiltasten-, Home-, End- und Escape-Bedienung an. Tab wird teils „geschluckt“. Nutzende erwarten Desktop-App-Verhalten, das die Seite nicht liefert – Verwirrung statt Hilfe.
• Es entsteht eine Baustelle. Wer menubar sagt, verpflichtet sich zur kompletten Pfeiltasten-Mechanik. Das ist viel Code, um etwas nachzubauen, das die native Bedienung schon kann.

Adrian Roselli, Terrill Thompson, Marco Zehe – die Fachleute in diesem Feld sind sich seit Jahren einig: Eine Navigation ist kein Menü im ARIA-Sinne, sondern eine Liste von Links. Genau das meint auch die erste Regel von ARIA: Nimm das native Element, solange es reicht. Hier reicht es.

Kurz: Sind es Links, ist es ein Disclosure. Sind es Befehle, die etwas tun, darf es ein echtes Menü sein – aber das ist die Ausnahme, nicht die Navigation.

Tastatur und Verhalten

Weil das Mega-Menü ein Disclosure ist, gilt das vertraute Tab-Modell – und genau das ist der Vorteil. Der ARIA Authoring Practices Guide beschreibt es so:

• Enter / Leertaste auf dem Button öffnet und schließt das Panel.
• Tab läuft logisch ins geöffnete Panel hinein und wieder heraus – kein Fokus-Trap. Verlässt der Fokus die Navigation, schließt sich das Panel.
• Esc schließt das Panel und gibt den Fokus an den auslösenden Button zurück.
• aria-expanded wird beim Öffnen auf true, beim Schließen auf false gesetzt. Diese Synchronisierung ist der eigentliche Kern – und der Teil, den reines CSS (:hover, :focus-within) noch nicht leisten kann.
• Die aktuelle Seite wird mit aria-current="page" markiert, in Panel und Breadcrumbs gleichermaßen.

Pfeiltasten sind laut APG optional. Man darf Auf/Ab durch die Links legen, muss aber nicht – und weil Nutzende an einer Website Tab erwarten, lasse ich sie meist weg. Weniger Mechanik, weniger, das kaputtgehen kann. Worauf es bei Fokus und Reihenfolge sonst ankommt, vertieft Tastatur & sichtbarer Fokus.

Live-Beispiel

Ein Mega-Menü lässt sich als natives Disclosure ganz ohne JavaScript bauen – <details>/<summary> bringt Aufklappen, Fokus und Tastaturbedienung von sich aus mit. Das ist die Basisstufe, auf der später eine schlanke JS-Schicht aufsetzt:

Progressive Enhancement: erst ohne JS, dann besser

Ein Mega-Menü sollte grundsätzlich auch dann bedienbar bleiben, wenn ein Skript scheitert. Ich baue solche Menüs deshalb in Schichten:

1. HTML als Basis – <button> (oder <details>) plus Liste. Schon damit sind die Links erreichbar.
2. CSS-Aufwertung – Panels per :focus-within und :hover öffnen, damit Maus, Touch und Tastatur das Menü auch ohne JS erreichen. Genau dieser Stand ist auf dieser Website aktuell umgesetzt.
3. JS-Schicht – führt aria-expanded mit, behandelt Esc, schließt bei Klick nach außen und steuert die Hover-Verzögerungen.

So bricht nichts komplett weg, wenn eine Stufe fehlt – die Navigation degradiert sanft statt hart.

Hover richtig timen – aber nie nur Hover

Am Desktop darf sich ein Mega-Menü ergänzend bei Hover öffnen. Entscheidend ist die Regel: niemals ausschließlich Hover. Was sich nur mit der Maus öffnet, ist auf dem Smartphone und per Tastatur unerreichbar. Klick und Tastatur müssen immer funktionieren.

Wenn Hover dazukommt, entscheidet das Timing über gute oder nervige Bedienung. Nielsen Norman nennt konkrete Werte, die sich in der Praxis bewähren:

• ~0,5 s Verzögerung vor dem Öffnen – erst wenn der Zeiger kurz ruhig steht. So flackert das Panel nicht auf, während die Maus nur quer über die Leiste fährt.
• ~0,1 s bis zum Erscheinen, sobald der Hover „ernst gemeint“ ist – schnell genug, um sich direkt anzufühlen.
• ~0,5 s Schließverzögerung, nachdem der Zeiger Button und Panel verlassen hat. Das verhindert, dass das Panel bei minimalem Mauszucken „wegflutscht“.

Dazu kommt das Diagonal-Problem: Wer vom Button schräg nach unten ins Panel zielt, streift dabei kurz einen anderen Menüpunkt. Ohne Schließverzögerung klappt das Ziel-Panel dann weg. Die Verzögerung – oder eine „Toleranzzone“ entlang der diagonalen Mausbahn – fängt das ab.

WCAG 1.4.13: Panels, die bei Hover oder Fokus erscheinen

Sobald ein Panel bei Hover oder Fokus erscheint, greift ein oft übersehenes Erfolgskriterium: WCAG 1.4.13 „Inhalt bei Hover oder Fokus“ (Stufe AA). Es stellt drei Bedingungen an solche eingeblendeten Inhalte:

• Ausblendbar (Dismissible): Das Panel muss sich schließen lassen, ohne dass Maus oder Fokus bewegt werden – in der Praxis über Esc. Wichtig für Menschen, die stark vergrößern: Ein Panel, das den halben Bildschirm verdeckt und sich nicht wegdrücken lässt, blockiert den Inhalt darunter.
• Überfahrbar (Hoverable): Öffnet Hover das Panel, muss der Zeiger vom Button auf das Panel wandern können, ohne dass es verschwindet. Genau dafür sorgt die Schließverzögerung von oben – sie ist nicht nur Komfort, sondern Konformität.
• Beständig (Persistent): Das Panel bleibt sichtbar, bis Hover/Fokus es verlässt, es aktiv geschlossen wird oder sein Inhalt hinfällig ist. Es darf nicht nach ein paar Sekunden von selbst zuklappen.

Dasselbe Kriterium gilt übrigens für Tooltips und Popover – überall, wo etwas bei Hover oder Fokus zusätzlich auftaucht.

Ein zweites 2.2-Kriterium ist beim Mega-Menü leicht zu übersehen: 2.4.11 „Fokus nicht verdeckt“ (AA). Ein aufgeklapptes, klebriges (sticky) Panel darf das gerade fokussierte Element nicht überdecken. Wenn das Panel über anderen Inhalten liegt, muss der Fokus sichtbar bleiben.

Die Kriterien im Überblick

Mehr zu den 2.2-Neuerungen steht in der WCAG-2.2-Kriterienreferenz und zu Reflow & Zoom.

Inhalt und Struktur im Panel

Ein technisch sauberes Mega-Menü nützt wenig, wenn im Panel Chaos herrscht. Die Usability-Forschung gibt dafür klare Leitplanken:

• Mittlere Gruppengröße. Nicht ein riesiger Block mit dreißig Links, aber auch nicht zwanzig Mini-Gruppen. Sinnvolle Bündel, die man auf einen Blick erfasst.
• Sprechende Labels, wichtigstes Wort zuerst. „Rechnungen exportieren“ schlägt „Zur Export-Funktion“. Erfundene Marketing-Begriffe meiden – Screenreader wie Auge scannen am linken Wortanfang.
• Labels klar unterscheiden. Zwei fast gleiche Überschriften („Geschenke nach Anlass“ / „Geschenke nach Interesse“) kosten Scanzeit. Genug Kontrast im Wortlaut.
• Sinnvolle Reihenfolge. Nach Arbeitsablauf oder Wichtigkeit ordnen; die wichtigste Gruppe gehört nach oben links, wo der Blick zuerst landet.
• Jeden Link nur einmal. Doppelte Einträge stiften mehr Verwirrung, als sie Bequemlichkeit bringen.

Bilder und Icons im Panel sind erlaubt und oft hilfreich – Produktbilder etwa lassen sich schneller vergleichen als Textlisten. Dann gilt aber: Jedes bedeutungstragende Bild braucht einen Alternativtext, rein dekorative bleiben per leerem alt="" außen vor.

Diese Spalten-mit-Überschriften-Logik entspricht dem Topic-Cluster-Denken: Struktur, die Auge, Screenreader und Suchmaschine gleichermaßen hilft.

Das mobile Pendant

Aus derselben Datenquelle speist sich die mobile Navigation: ein Hamburger-Button als <button aria-expanded>, der dieselben Einträge in einer aufklappbaren, einspaltigen Liste zeigt. Eine gemeinsame Quelle für Desktop und Mobil verhindert, dass die beiden Menüs auseinanderlaufen.

Worauf es mobil besonders ankommt:

• Trefferflächen ≥ 24 × 24 px (WCAG 2.5.8), großzügiger sind besser – Finger sind ungenauer als Mauszeiger.
• Kein Hover. Touch kennt kein „Drüberfahren“; hier zählt allein der Klick, was die Nur-Hover-Falle noch einmal unterstreicht.
• Reflow statt Querscrollen. Bei 320 px Breite muss das Menü einspaltig umbrechen (WCAG 1.4.10), nicht seitlich scrollen.
• Ein Skip-Link davor erspart es Tastatur- und Screenreader-Nutzenden, jedes Mal durch die ganze Navigation zu tabben.

So teste ich ein Mega-Menü

Bevor ein Mega-Menü live geht, gehe ich eine kurze Runde durch:

1. Maus weglegen, nur Tastatur. Erreiche ich jeden Button per Tab? Öffnet Enter/Leertaste? Läuft Tab sauber durch die Links und wieder heraus? Schließt Esc und springt der Fokus zurück auf den Button?
2. Fokus sichtbar? Auf Button und jedem Link muss ein deutlicher Fokusring liegen.
3. Screenreader. Mit NVDA oder VoiceOver: Wird der Button als „Schaltfläche, zu/auf“ angesagt? Und – der entscheidende Test gegen das menubar-Antipattern – tauchen die Links in der Linkliste des Screenreaders auf?
4. Hover-Timing. Flackert nichts beim Überfahren? Komme ich diagonal ins Panel, ohne dass es wegklappt? Lässt es sich mit Esc schließen?
5. 200 % Zoom und 320 px. Bricht das Panel sinnvoll um, ohne Querscrollen und ohne den fokussierten Punkt zu verdecken?

Häufige Fehler

• role="menubar" für die Seitennavigation – erzwingt unerwartete Pfeiltasten und entfernt die Links aus der Linkliste.
• Nur Hover, unerreichbar für Touch und Tastatur.
• aria-expanded nicht gepflegt – falsche Ansage „zu“, obwohl offen. Eine falsche Ansage ist schlimmer als gar keine.
• <div> als Auslöser statt <button> – nicht fokussierbar, ohne Rolle.
• Fokus-Trap im Panel, aus dem Tab nicht mehr herausführt.
• Kein Esc – verstößt gegen WCAG 1.4.13 (Ausblendbarkeit).
• Zu kurze oder fehlende Schließverzögerung, sodass das Panel „wegflutscht“ und das Diagonal-Problem zuschlägt.
• Überladenes Panel ohne Gruppen und ohne klare Labels – technisch zugänglich, praktisch unbenutzbar.

Häufige Fragen

Ist ein Mega-Menü überhaupt barrierefrei machbar?

Ja – es ist „nur“ ein großes Disclosure. Die Komplexität liegt in der Menge der Links, nicht im Muster. Sauberes aria-expanded, Tastaturbedienung mit Esc und gepflegte Fokusreihenfolge genügen. Kein role="menu" nötig.

Warum kein role="menu" oder role="menubar"?

Weil diese Rollen für Anwendungsmenüs gedacht sind, nicht für Navigation. Sie stellen die Tastatur auf Pfeiltasten um und entfernen die Links aus der Linkliste des Screenreaders. Für Links zu Seiten ist das Disclosure-Muster richtig; ein echtes Menü hebst du dir für Befehlsmenüs auf.

Wie organisiere ich viele Links im Panel?

In Spalten mit kurzen Zwischenüberschriften und Listen. Mittlere Gruppengröße, sprechende Labels mit dem wichtigsten Wort zuerst, die wichtigste Gruppe oben links. Das schafft Struktur für Auge und Screenreader – und entspricht dem Topic-Cluster-Denken.

Muss sich das Panel bei Hover öffnen?

Nein. Hover ist eine Ergänzung am Desktop, kein Muss. Pflicht sind Klick und Tastatur. Wenn Hover dazukommt, braucht es Öffnungs- und Schließverzögerungen und muss WCAG 1.4.13 erfüllen: per Esc ausblendbar, mit der Maus überfahrbar, beständig sichtbar.

Brauche ich für Desktop und Mobil zwei Datenquellen?

Nein, im Gegenteil. Eine gemeinsame Quelle für beide Ansichten verhindert, dass die Menüs auseinanderlaufen. Aus denselben Daten rendert man das mehrspaltige Desktop-Panel und die einspaltige mobile Liste.

Was ist der wichtigste Test?

Die Tastatur- und die Screenreader-Runde. Wenn du das Menü komplett per Tastatur bedienen kannst, Esc schließt und die Links in der Linkliste des Screenreaders auftauchen, sind die größten Fallstricke ausgeräumt.

Fazit

Ein Mega-Menü ist Disclosure im Großformat: Buttons mit aria-expanded steuern mehrspaltige Panels mit normalen Links – tastaturbedienbar, mit Esc, ohne menubar-Mechanik. Hover nur ergänzend und richtig getimt, Panels konform zu WCAG 1.4.13, Inhalt in klaren Gruppen, mobil einspaltig aus derselben Quelle, aktuelle Seite per aria-current. Damit bleibt selbst eine umfangreiche Navigation für alle bedienbar – und ist zugleich gute UX. Die Grundlagen dazu vertieft Menüs & Dropdowns.