Mega-Menüs barrierefrei umsetzen

Ein Mega-Menü ist ein Disclosure mit mehreren Spalten: ein Button mit aria-expanded, ein Panel mit Listen, Esc schließt, Hover ist Zugabe. Ein eigenes ARIA-Muster braucht es dafür nicht, und role="menubar" gehört nicht hinein.

Es ist damit 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.

Das Wichtigste in Kürze

• Der Auslöser ist ein <button aria-expanded>, kein Link und kein <div>.
• Das Panel enthält gewöhnliche Listen mit Links. role="menu" oder role="menubar" gehören nicht hinein. Diese Rollen sind für Befehlsmenüs in Anwendungen gedacht.
• Esc schließt und gibt den Fokus an den Button zurück. Öffnet sich das Panel bei Hover oder Fokus, verlangt WCAG 1.4.13 genau diesen Weg zum Ausblenden.
• Hover ist Zugabe: Öffnen per Klick oder Tastatur muss allein funktionieren.
• Soll der Oberpunkt selbst auf eine Seite führen, stehen ein Link und ein eigener Button mit Namen wie „Untermenü SEO“ nebeneinander.
• Ohne JavaScript bleiben die Links erreichbar, weil das Panel im HTML offen steht und erst das Skript es einklappt. Alternativ führt der Oberpunkt auf eine Hub-Seite mit denselben Links.
• Prüfrelevant sind vor allem 2.1.1, 1.3.1, 4.1.2, 1.4.13, 2.4.7, 2.4.11 und 3.2.3.

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 die richtige UX-Entscheidung?

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 sich auf das Gedächtnis der Nutzenden zu verlassen: 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 stehen sie 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>
      <!-- Ohne Skript offen. Das Skript setzt beim Start hidden. -->
      <div id="panel-seo" class="mega-panel">
        <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 halten die ganze Konstruktion zusammen:

• <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.
• Kein aria-haspopup. Das Attribut kündigt dem Screenreader ein Menü an und weckt die Erwartung an Pfeiltasten. Ein Disclosure-Button kommt ohne aus.

Das Panel steht im ausgelieferten HTML bewusst offen. Erst das Skript setzt beim Start hidden an jedes Panel und übernimmt das Auf- und Zuklappen. Fällt das Skript aus, sieht man eine lange, aber vollständige Linkliste. Steht hidden dagegen fest im HTML, bleiben die Links ohne Skript unerreichbar, denn der Button allein tut nichts. Das Panel folgt im DOM direkt auf seinen Button. So erreicht der nächste Tab-Schritt den ersten Link, ohne dass ein Skript den Fokus versetzen muss.

Das Spaltenraster selbst entsteht im Stylesheet, meist mit Grid. 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. Ein Hinweis aus Tests: Viele Screenreader sagen den Namen einer Liste beim Betreten nicht an. Der sichtbare Spaltenkopf als normaler Text vor der Liste bleibt deshalb die wichtigere Orientierung.

Oberpunkt mit eigener Seite: Link und Button nebeneinander

In Shops und großen Portalen soll der Oberpunkt meist selbst auf eine Kategorieseite führen. Ein einzelnes Element kann nicht zugleich Link und Disclosure-Button sein. Ein Link öffnet eine Seite, ein Button schaltet einen Zustand. Die Lösung sind zwei Elemente nebeneinander. Das APG beschreibt diese Variante als „Disclosure Navigation Menu with Top-Level Links“.

<li>
  <a href="/seo-und-ki.html">SEO &amp; KI</a>
  <button type="button" aria-expanded="false" aria-controls="panel-seo">
    <svg aria-hidden="true" focusable="false"><!-- Pfeil --></svg>
    <span class="visually-hidden">Untermenü SEO &amp; KI</span>
  </button>
  <div id="panel-seo" class="mega-panel">…</div>
</li>

Worauf es dabei ankommt:

• Der Button bekommt einen eigenen Namen. Fünf Buttons mit dem Namen „Untermenü“ sind in der Liste der Bedienelemente nicht unterscheidbar.
• Der Pfeil braucht 3:1 Kontrast zum Hintergrund (1.4.11) und eine Trefferfläche von mindestens 24 × 24 CSS-Pixeln.
• Die Tab-Reihenfolge verdoppelt sich für die Oberpunkte. Das ist der Preis der Variante. Ein Skip-Link vor der Navigation fängt ihn ab.
• Die Kategorieseite ist zugleich der Weg ohne Skript. Sie listet dieselben Links wie das Panel und erfüllt damit nebenbei 2.4.5 Verschiedene Methoden.

In der mobilen Ansicht nutzt das Menü dieser Website genau diese Aufteilung. Der Name der Rubrik ist ein Link, der Pfeil daneben ein eigener Button.

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. Das sorgt für 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 zählen zu den Fachleuten in diesem Feld. Sie sind sich seit Jahren einig: Eine Navigation ist eine Liste von Links. Ein Menü im ARIA-Sinne ist etwas anderes. 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. Das bleibt die Ausnahme. Die Navigation gehört nicht dazu.

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. Genau diese Synchronisierung kann reines CSS (:hover, :focus-within) nicht leisten, deshalb braucht es hier JavaScript.
• 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: Oberpunkt als Link auf die Kategorieseite, daneben der Button, das Panel offen im HTML. Alternativ dient <details> als Basis. Damit sind alle Links ohne Skript erreichbar.
2. CSS-Aufwertung: Raster, Abstände, Fokusstile und das Ausblenden über [aria-expanded="false"] + .mega-panel. Das Öffnen per :hover darf hier am Desktop als Ergänzung dazukommen.
3. JS-Schicht: Sie setzt beim Start hidden, führt aria-expanded mit, behandelt Esc, schließt bei Klick nach außen und steuert die Hover-Verzögerungen.

Fällt eine Stufe aus, bleibt die darunterliegende benutzbar. Die Navigation verliert Komfort und behält ihre Links.

Warum :focus-within allein nicht reicht

Ein beliebter Weg ohne Skript ist ein Panel, das sich per :focus-within öffnet, sobald der Fokus den Oberpunkt erreicht. Das wirkt elegant und hat drei Schwächen:

• Jeder Link landet in der Tab-Reihenfolge. Wer die Navigation durchtabbt, läuft durch alle Panels nacheinander. Genau diesen Weg soll das Disclosure abkürzen.
• Der Screenreader erfährt nichts vom Zustand. Ohne Skript gibt es kein aria-expanded, also auch keine Ansage „erweitert“ oder „reduziert“.
• Es gibt kein Esc. Ein Panel, das bei Fokus erscheint, muss sich nach 1.4.13 ausblenden lassen, ohne dass der Fokus wandert. CSS kann das nicht leisten.

Dazu kommt ein Konflikt mit der JS-Schicht: Einen Zustand, den CSS über :focus-within herbeiführt, kann ein Skript nicht zurücknehmen. Das Panel bleibt offen, solange der Fokus darin steht, auch nach Esc. Wer ein Skript einsetzt, öffnet das Panel deshalb nur über aria-expanded und lässt :focus-within weg.

Hover richtig timen: nie nur per 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. Das Panel öffnet 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 macht die Bedienung angenehmer und ist zugleich Voraussetzung für die 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. Das gilt überall, wo etwas bei Hover oder Fokus zusätzlich auftaucht. Öffnet sich das Panel ausschließlich per Klick oder Enter, fällt es aus 1.4.13 heraus. Esc bleibt dann trotzdem Pflicht nach dem APG und erwartetes Verhalten.

Ein zweites 2.2-Kriterium ist beim Mega-Menü leicht zu übersehen: 2.4.11 „Fokus nicht verdeckt“ (AA). Es verbietet, dass ein fokussiertes Element vollständig unter anderen Inhalten verschwindet. Teilweise Überdeckung regelt erst 2.4.12 auf Stufe AAA. Beim Mega-Menü ist selten das Panel der Auslöser, denn es schließt sich, sobald der Fokus die Navigation verlässt. Häufiger ist es der klebrige (sticky) Header mit dem Menü, der beim Tabben durch die Seite die fokussierten Links darunter verdeckt. scroll-padding-top in Höhe des Headers behebt das in den meisten Fällen.

Die Kriterien im Überblick

Eine Frage taucht in Prüfungen regelmäßig auf: Ist 2.1.1 erfüllt, wenn die Unterpunkte nur per Maus im Panel, per Tastatur aber über die Hub-Seiten erreichbar sind? Einige Prüfende lassen das gelten. Ich rate davon ab. Die WCAG prüfen jede Seite in jedem Zustand, und das geöffnete Panel ist ein Zustand der Seite. Was die Maus darin erreicht, muss auch die Tastatur erreichen.

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.
• Reflow statt Querscrollen. Bei 320 px Breite muss das Menü einspaltig umbrechen (WCAG 1.4.10). Seitliches Scrollen ist dabei ausgeschlossen.
• 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 mit Rolle und Zustand angesagt, bei NVDA etwa als „Schalter, reduziert“ und nach dem Öffnen als „erweitert“? 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 % Textgröße. Bleiben bei vergrößerter Schrift alle Einträge lesbar, ohne abgeschnitten zu werden oder sich zu überlappen (1.4.4)?
6. 400 % Zoom, also 320 CSS-Pixel Breite. Klappt das Menü in die einspaltige Ansicht um, ohne Querscrollen und ohne den fokussierten Punkt zu verdecken (1.4.10)?
7. Ohne JavaScript. Mit abgeschaltetem Skript neu laden: Sind alle Links sichtbar oder über die Kategorieseiten erreichbar?

Häufige Fehler

• role="menubar" für die Seitennavigation. Das erzwingt unerwartete Pfeiltasten und entfernt die Links aus der Linkliste.
• Nur Hover, unerreichbar für Touch und Tastatur.
• aria-expanded nicht gepflegt. Dann sagt der Screenreader fälschlich „zu“ an, obwohl das Panel offen ist. 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. Bei Panels, die per Hover oder Fokus erscheinen, verstößt das gegen WCAG 1.4.13 (Ausblendbarkeit). Bei reinen Klick-Panels fehlt das erwartete Verhalten.
• hidden fest im HTML und damit ohne Skript unerreichbare Links.
• Panel öffnet per :focus-within und schickt alle Links in die Tab-Reihenfolge.
• 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

Lässt sich ein Mega-Menü barrierefrei umsetzen?

Ja. Es ist ein großes Disclosure. Die Komplexität liegt in der Menge der Links, das Muster selbst ist einfach. Sauberes aria-expanded, Tastaturbedienung mit Esc und eine gepflegte Fokusreihenfolge genügen. role="menu" und role="menubar" braucht es dafür nicht. Sie stellen die Tastatur auf Pfeiltasten um und entfernen die Links aus der Linkliste des Screenreaders.

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. 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. 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.

Verwandte Themen

• Menüs & Dropdowns: das Disclosure-Prinzip im Kleinen
• Skip-Links: der Sprung an der Navigation vorbei
• WCAG 1.4.13: Inhalt bei Hover oder Fokus: das Kriterium für eingeblendete Panels
• Tastaturbedienung & sichtbarer Fokus: Fokusreihenfolge und Fokusstile

Quellen

• Example Disclosure Navigation Menu (W3C ARIA Authoring Practices Guide)
• Understanding SC 1.4.13: Content on Hover or Focus (W3C)
• Don’t Use ARIA Menu Roles for Site Nav (Adrian Roselli)
• Mega Menus Work Well for Site Navigation (Nielsen Norman Group)