Ratgeber

Navigation und Menüs im Shop barrierefrei: selbst prüfen und beheben

Veröffentlicht am 29. Oktober 2026

Eine barrierefreie Navigation im Shop erkennen Sie daran, dass sich Hauptmenü, Untermenüs, Handy-Menü, Suche und Breadcrumbs vollständig mit der Tastatur bedienen lassen, der Fokus immer sichtbar ist und ein Screenreader ansagt, ob ein Untermenü auf- oder zugeklappt ist. Für aufklappbare Menüs empfiehlt das W3C das einfache Disclosure-Muster mit Buttons und aria-expanded, nicht die Menü-Rolle role="menu", die für Programmmenüs gedacht ist.

Dieser Artikel geht jeden Baustein der Shop-Navigation einzeln durch: wie Sie ihn in wenigen Minuten selbst prüfen und wie Sie oder Ihr Theme-Entwickler ihn beheben. Welche WCAG-Version für Ihren Shop zählt und wie die Kriterien aufgebaut sind, erklärt unser Überblick WCAG 2.2 für Onlineshops. Den allgemeinen Durchgang mit der Tab-Taste durch den ganzen Shop beschreibt der Tastaturtest in 10 Minuten; hier geht es nur um die Navigation, dafür in der Tiefe.

Welche WCAG-Kriterien die Navigation betreffen

Die Navigation berührt viele Kriterien, und weil sie auf jeder Seite steht, wirkt jeder Fehler im ganzen Shop. Die wichtigsten aus WCAG 2.2:

2.4.8 ist Stufe AAA und damit freiwillig. Breadcrumbs lohnen sich trotzdem: Nach unserer Lesart können sie für 2.4.5 als „Links zu verwandten Seiten“ zählen; das W3C nennt sie dort allerdings nicht ausdrücklich.

So prüfen Sie: Vorbereitung

Sie brauchen einen Desktop-Browser, Ihr Smartphone und etwa 30 Minuten (unsere Schätzung). Prüfen Sie die Navigation auf vier Seiten: Startseite, eine Kategorieseite, eine Produktseite und den Warenkorb. Für die Ansagen nehmen Sie zusätzlich einen Screenreader dazu; wie Sie NVDA oder VoiceOver starten, steht im Screenreader-Test mit NVDA und VoiceOver.

Notieren Sie je Fund: Seite, Baustein, was passiert ist, was Sie erwartet hätten. Die Tabelle am Ende dieses Artikels ordnet jeden typischen Fund einem Kriterium und einer Behebung zu.

1. Sprunglink „Zum Inhalt“

Was gefordert ist. Nach 2.4.1 muss es einen Mechanismus geben, Blöcke zu überspringen, die sich auf mehreren Seiten wiederholen, also vor allem Kopfbereich und Menü. Als ausreichende Techniken nennt das W3C unter anderem einen Link oben auf jeder Seite zum Hauptinhalt, ARIA-Landmarks und Überschriften am Beginn jedes Abschnitts. Unsere Empfehlung: Setzen Sie den Sprunglink trotzdem, denn Landmarks und Überschriften nutzen vor allem Screenreader, Tastaturnutzer ohne Screenreader profitieren nur vom Link.

So prüfen Sie. Die Technik G1 gibt den Test vor; übertragen auf Ihren Shop:

1. Seite neu laden, in die Adresszeile klicken, dann einmal Tab drücken.
2. Erscheint als Erstes ein Link wie „Zum Inhalt“ oder „Zum Hauptinhalt springen“? Laut G1 muss der Link das erste fokussierbare Element sein und entweder immer oder zumindest beim Fokus sichtbar werden.
3. Enter drücken. Die Seite springt zum Hauptinhalt.
4. Noch einmal Tab drücken. Der Fokus muss jetzt auf dem ersten Link oder Bedienelement im Hauptinhalt landen, nicht wieder im Menü. Diese Prüfung, ob der Tastaturfokus wirklich mitgewandert ist, ist der letzte Schritt in G1.

So beheben Sie. Der Link steht im Theme ganz am Anfang des body-Elements und zeigt auf das main-Element, zum Beispiel <a href="#inhalt">Zum Inhalt</a> und <main id="inhalt">. Ist er unsichtbar, auch wenn er fokussiert ist, braucht er eine CSS-Regel, die ihn beim Fokus einblendet. Hat Ihr Theme schon einen Sprunglink, prüfen Sie ihn nach jeder Änderung am Kopfbereich erneut.

2. Landmark „nav“ und Beschriftung

Was empfohlen ist. Die Navigation steht in einem nav-Element. Laut APG zu Navigation-Landmarks kennzeichnet nav Gruppen von Links, und hat eine Seite mehr als eine Navigation, soll jede einen eigenen Namen haben; nur Navigationen mit genau denselben Links tragen denselben Namen. Im Shop sind das typischerweise Hauptmenü, Breadcrumbs, Fußzeilen-Navigation und manchmal ein Konto-Menü. Landmarks gehören laut Understanding 2.4.1 zu den ausreichenden Techniken (ARIA11).

So prüfen Sie. Lassen Sie sich mit dem Screenreader die Liste der Landmarks der Seite anzeigen; wie das in NVDA und VoiceOver geht, steht im Screenreader-Test. Ohne Screenreader geht es mit dem Accessibility-Baum der Entwicklertools; wie, zeigt Schritt 1 in ARIA und Barrierefreiheit im Onlineshop. Achten Sie auf:

• Gibt es überhaupt eine Navigation in der Liste?
• Haben mehrere Navigationen unterscheidbare Namen, etwa „Hauptmenü“, „Brotkrümelpfad“, „Fußzeile“, statt dreimal „Navigation“?

So beheben Sie. Im Theme das Menü in <nav aria-label="Hauptmenü"> setzen, die Breadcrumbs in <nav aria-label="Brotkrümelpfad"> und so weiter. Die Menüpunkte selbst sind normale Links in einer Liste (ul mit li).

3. Hauptmenü und Mega-Menü mit Untermenüs

Welches Muster richtig ist: Disclosure statt Menü-Rolle

Das W3C beschreibt im ARIA Authoring Practices Guide (APG) zwei Wege für aufklappbare Menüs, und für eine Shop-Navigation ist nur einer passend:

Die Belege: Das APG-Beispiel Disclosure Navigation Menu verzichtet ausdrücklich auf die Menü-Rolle, weil eine Websitenavigation die komplexe Tastaturbedienung, die Hilfstechnik von einem Menü erwartet, nicht braucht. Das APG-Beispiel für eine Navigation als Menüleiste trägt den Hinweis „Caution!“: „The menubar pattern requires complex functionality that is unnecessary for typical site navigation that is styled to look like a menubar with expandable sections or fly outs“, und weiter: „A pattern more suited for typical site navigation with expandable groups of links is the Disclosure Pattern.“ (APG, Navigation Menubar Example). Dasselbe gilt sinngemäß für Menü-Buttons: Das Menu-Button-Muster öffnet ein Menü im Sinne des Menü-Musters und bringt dessen Pfeiltastenbedienung mit. Nach unserer Lesart gehört ein Button, der nur eine Liste von Kategorie-Links aufklappt, deshalb ins Disclosure-Muster, nicht ins Menu-Button-Muster.

Warum das zählt: role="menu" ohne die verlangte Tastaturbedienung ist ein häufiger Fehler; die Zahlen dazu aus der WebAIM Million stehen in ARIA und Barrierefreiheit im Onlineshop.

So soll sich ein Untermenü nach dem APG verhalten

Das APG beschreibt in seinen beiden Beispielen (ohne und mit verlinkten Hauptpunkten) diese Bedienung:

• Tab und Umschalt + Tab gehen durch die Hauptpunkte und, wenn ein Untermenü offen ist, durch dessen Links.
• Enter oder Leertaste auf einem Button klappt sein Untermenü auf oder zu.
• Escape schließt ein offenes Untermenü und setzt den Fokus zurück auf den Button, der es steuert.
• Pfeiltasten, Pos1 und Ende sind optional. Laut APG ergänzen sie das Tabben, ersetzen es aber nicht.
• aria-expanded am Button steht auf false, solange das Untermenü verborgen ist, und auf true, wenn es sichtbar ist (Disclosure-Muster).
• aria-current="page" steht am Link der Seite, die gerade angezeigt wird, und nur an einem Link.

Ist der Hauptpunkt selbst ein Link (etwa „Damen“ führt zur Kategorieseite) und soll trotzdem ein Untermenü haben, zeigt das zweite APG-Beispiel die Lösung: neben dem Link ein eigener kleiner Button nur zum Aufklappen. Ein einziges Element, das zugleich Link und Aufklapper ist, funktioniert mit der Tastatur nicht sauber; auch das APG rät beim Menü-Muster von Einträgen ab, die zugleich eine Funktion ausführen und ein Untermenü öffnen (APG Menu, Hinweis 4).

So prüfen Sie Haupt- und Mega-Menü

1. Tastatur: Mit Tab zum ersten Hauptpunkt mit Untermenü. Öffnet Enter oder Leertaste das Untermenü? Öffnet es sich nur beim Fokus von selbst, ist das kein Fehler, aber es muss sich ohne Maus auch wieder schließen lassen.
2. Reihenfolge: Weiter mit Tab. Landet der Fokus als Nächstes im geöffneten Untermenü? Springt er stattdessen zum nächsten Hauptpunkt oder in den Inhalt, ist das Untermenü per Tastatur unerreichbar. Steht ein Untermenü im Code ganz woanders als sein Auslöser, nennt das W3C das ausdrücklich als Fehler F85 zu 2.4.3.
3. Geschlossene Untermenüs: Bei zugeklapptem Menü einmal durch die ganze Kopfzeile tabben. Verschwindet der Fokus für viele Tab-Drücke im Unsichtbaren, sind die verborgenen Links trotzdem fokussierbar. Nach unserer Lesart verletzt das 2.4.3, und es verletzt 2.4.7, weil der Fokus nicht sichtbar ist.
4. Escape: Im offenen Untermenü Escape drücken. Schließt es, und steht der Fokus wieder auf dem Hauptpunkt?
5. Screenreader: Auf dem Button hören Sie den Namen, die Rolle „Schalter“ und den Zustand „eingeklappt“ beziehungsweise „ausgeklappt“ (so lauten die Wörter im deutschen NVDA laut dessen Übersetzungsdatei; VoiceOver verwendet teils andere Wörter). Wechselt die Ansage nach Enter? Hören Sie als Rolle „Menüleiste“ oder „Menü“ statt „Schalter“, nutzt das Theme die Menü-Rolle.
6. Mega-Menü: Bei großen Menüflächen mit mehreren Spalten, Bildern und Aktionsbannern: Ist die Reihenfolge im Mega-Menü spaltenweise oder zeilenweise nachvollziehbar? Laut Understanding 2.4.3 sind mehrere Reihenfolgen zulässig, solange Bedeutung und Bedienbarkeit erhalten bleiben. Bleibt das aufgeklappte Mega-Menü beim Tabben durch die Seite offen und verdeckt den fokussierten Link vollständig, ist das ein Risiko für 2.4.11: Laut Understanding ist es nur dann kein Verstoß, wenn sich das Menü schließen lässt, etwa mit Escape, ohne dass der Fokus weiterwandern muss. Sicherer ist ein Untermenü, das schließt, sobald der Fokus es verlässt.

So beheben Sie

Die Behebung ist eine Aufgabe für das Theme. So sieht der Kern nach dem Disclosure-Muster aus:

Die Klasse visually-hidden steht für die übliche CSS-Regel, die Text nur für Screenreader sichtbar lässt; das Symbol (etwa ein Pfeil) kommt per CSS als Rahmen oder Hintergrundbild dazu. Was das Skript dazu tun muss: beim Klick oder bei Enter und Leertaste auf dem Button das hidden am Untermenü umschalten und aria-expanded mitschalten; bei Escape schließen und den Fokus auf den Button setzen. Mehr braucht das Muster nicht. Das hidden-Attribut (oder display: none im CSS) sorgt dafür, dass zugeklappte Links nicht fokussierbar sind; ein Untermenü, das nur per opacity: 0 oder außerhalb des Bildschirms versteckt wird, bleibt mit Tab erreichbar.

Was Sie Ihrem Theme-Anbieter sagen: „Bitte die Hauptnavigation nach dem Disclosure-Muster der WAI-ARIA APG umsetzen, ohne role="menu", mit aria-expanded am Button, Escape zum Schließen und aria-current="page" am aktuellen Link.“

4. Untermenüs beim Überfahren mit der Maus

Viele Shop-Menüs öffnen ihr Untermenü, sobald die Maus darüberfährt. Das ist erlaubt, aber dann gilt 1.4.13. Das Understanding-Dokument nennt Untermenüs ausdrücklich als Beispiel. Die drei Bedingungen:

• Schließbar: Es gibt einen Weg, das Untermenü zu schließen, ohne die Maus oder den Fokus zu bewegen, in der Praxis die Escape-Taste. Ausgenommen ist Inhalt, der nichts anderes verdeckt; ein Untermenü über dem Banner verdeckt aber fast immer etwas.
• Überfahrbar: Man kann mit der Maus vom Hauptpunkt in das Untermenü fahren, ohne dass es verschwindet.
• Bleibend: Das Untermenü bleibt offen, bis die Maus oder der Fokus es verlässt, der Nutzer es schließt oder es nicht mehr gilt.

So prüfen Sie.

1. Browser auf 200 % zoomen (Strg und Plus beziehungsweise Cmd und Plus) und mit der Maus langsam vom Hauptpunkt schräg in das Untermenü fahren. Klappt es unterwegs zu, ist „überfahrbar“ nicht erfüllt. Gerade bei Vergrößerung ist der Weg lang.
2. Maus auf den Hauptpunkt legen, Untermenü offen, Escape drücken. Schließt es, ohne dass Sie die Maus bewegen?
3. Untermenü öffnen und eine Weile warten. Schließt es sich nach einer Zeit von selbst, ist „bleibend“ nicht erfüllt.

So beheben Sie. Das Untermenü direkt an den Hauptpunkt anschließen lassen, ohne Lücke dazwischen, Escape-Taste im Skript abfangen und kein Zeitlimit für das Schließen setzen. Zusätzlich braucht das Untermenü den Weg per Tastatur aus Abschnitt 3, denn Hover allein ist nach 2.1.1 keine Tastaturbedienung.

5. Mobiles Menü und Hamburger-Button

Auf dem Smartphone, aber auch bei starkem Zoom am Desktop klappt die Navigation in einen Hamburger-Button. Das Understanding-Dokument zu 1.4.10 Umbruch zeigt genau das als zulässiges Beispiel: Die Hauptnavigation wandert hinter einen Hamburger-Button, alle Informationen und Funktionen bleiben erreichbar. Damit das stimmt, muss der Button selbst bedienbar sein.

So prüfen Sie.

1. Desktop mit Zoom: Browserfenster auf etwa 1280 Pixel Breite stellen und auf 400 % zoomen. Das entspricht laut W3C 320 CSS-Pixeln. Erscheint der Hamburger-Button, und sind dahinter alle Menüpunkte erreichbar, auch die Untermenüs?
2. Tastatur: Mit Tab zum Hamburger-Button. Ist der Fokus sichtbar? Öffnet Enter oder Leertaste das Menü? Ist der Hamburger ein div oder ein Bild statt eines Buttons, reagiert er oft nur auf Klick.
3. Fokus nach dem Öffnen: Nächster Tab-Druck. Landet der Fokus im geöffneten Menü? Oder läuft er hinter dem Menü über die verdeckte Seite weiter? Dann sehen Sie den Fokus nicht mehr. Das verletzt die sinnvolle Reihenfolge nach 2.4.3; für 2.4.11 ist es nur dann kein Verstoß, wenn Sie das Menü ohne Weitertabben, etwa mit Escape, schließen können.
4. Schließen: Gibt es einen Schließen-Button mit Namen, und schließt Escape? Steht der Fokus danach wieder auf dem Hamburger-Button?
5. Screenreader: Sagt er „Menü, Schalter, eingeklappt“ oder nur „Schalter“? Ohne Namen weiß niemand, wofür der Button ist (4.1.2). Steht „Menü“ sichtbar am Button, muss der Name dieses Wort enthalten (2.5.3).
6. Smartphone: Mit VoiceOver (iPhone) oder TalkBack (Android) das Menü öffnen und mit Wischen durchgehen. Kommen Sie an jeden Punkt, und werden Untermenüs angesagt?

So beheben Sie.

• Der Hamburger ist ein <button type="button"> mit sichtbarem Text „Menü“ oder mit aria-label="Menü", dazu aria-expanded wie in Abschnitt 3. Das Symbol selbst (die drei Striche, oft ein SVG) bekommt aria-hidden="true".
• Ein Menü, das als Schublade neben der Seite aufgeht, behandelt das Theme wie ein Disclosure: Fokus bleibt auf dem Button, der nächste Tab geht ins Menü.
• Ein Menü, das die ganze Seite überdeckt, behandelt das Theme nach unserer Einschätzung besser wie einen modalen Dialog: Fokus beim Öffnen ins Menü, Seite dahinter nicht fokussierbar, Escape schließt, Fokus zurück auf den Button. Für modale Dialoge beschreibt Understanding 2.4.3 genau dieses Verhalten: Solange der Dialog offen ist, ist der Inhalt außerhalb inaktiv, beim Schließen kehrt der Fokus zum Auslöser zurück. Das passende APG-Muster und das native dialog-Element stehen in ARIA und Barrierefreiheit im Onlineshop beim Mini-Warenkorb; der Umbau ist derselbe.

6. Fokusreihenfolge in Kopfzeile und Menü

Was gefordert ist. Nach 2.4.3 bekommen Bedienelemente den Fokus in einer Reihenfolge, die Bedeutung und Bedienbarkeit erhält. Die Fokusreihenfolge muss laut Understanding nicht exakt dem Bild folgen, aber nachvollziehbar sein. Als Fehler nennt das W3C einen tabindex, der eine Reihenfolge erzeugt, die Bedeutung und Bedienbarkeit nicht erhält (F44).

So prüfen Sie. In Firefox öffnen Sie den Accessibility Inspector über Tools > Browser Tools > Accessibility und setzen das Häkchen Show Tabbing Order; dann zeigt Firefox die Tab-Reihenfolge als Überlagerung auf der Seite (Firefox-Dokumentation). In deutschen Firefox-Versionen können die Menünamen übersetzt sein. Typische Funde in der Kopfzeile:

• Konto, Merkliste und Warenkorb kommen vor dem Logo und dem Menü, obwohl sie rechts stehen. Das ist nicht automatisch falsch, aber prüfen Sie, ob es sich logisch anfühlt.
• Die Suche wird erst nach dem kompletten Mega-Menü erreicht.
• Ein Ankündigungsbalken („Gratis Versand ab ...“) mit Link schiebt sich vor den Sprunglink.
• Positive tabindex-Werte im Code (tabindex="1" und höher). Suchen Sie im Quelltext (Strg + U, dann Strg + F) nach tabindex=". Werte über 0 verändern die Reihenfolge für die ganze Seite; das W3C nennt einen tabindex, der die Reihenfolge verfälscht, als Fehler F44.

So beheben Sie. Positive tabindex-Werte entfernen und die Reihenfolge über die Reihenfolge im HTML herstellen. Der Sprunglink steht vor dem Ankündigungsbalken.

7. Sichtbarer Fokus

Was gefordert ist. 2.4.7 verlangt einen sichtbaren Fokus, und zwar dauerhaft: Laut Understanding darf die Fokusanzeige nicht zeitlich begrenzt sein. Als Fehler nennt das W3C, Umrandungen so zu gestalten, dass der Fokus unsichtbar wird (F78), etwa durch outline: none ohne Ersatz. Wenn Ihr Theme den Fokus selbst gestaltet, braucht der Rahmen nach 1.4.11 mindestens 3:1 Kontrast zum angrenzenden Hintergrund; der unveränderte Standardfokus des Browsers ist davon ausgenommen, muss aber sichtbar sein.

So prüfen Sie. Mit Tab durch das ganze Menü, auch durch geöffnete Untermenüs und den Hamburger-Button. Bei jedem Druck fragen: Sehe ich sofort, wo ich bin? Achten Sie besonders auf:

• Menüpunkte auf farbiger Kopfleiste, wo ein dunkler Fokusrahmen untergeht. Messen Sie die Farbe des Rahmens gegen die Leiste mit einem Kontrastwerkzeug.
• Fokus, der nur die Textfarbe minimal ändert.
• Fokus, der unter einer festen Kopfleiste verschwindet, wenn die Seite beim Tabben scrollt (2.4.11; das Understanding nennt feste Kopf- und Fußleisten als typische Ursache, Fehler F110).

So beheben Sie. Im Theme-CSS outline: none und outline: 0 suchen und entfernen oder durch einen deutlichen Rahmen ersetzen, etwa :focus-visible { outline: 3px solid #1a1a1a; outline-offset: 2px; }, bei dunkler Kopfleiste in Weiß. Bei fester Kopfleiste hilft scroll-padding-top in Höhe der Leiste (Technik C43; das W3C-Beispiel zeigt dasselbe für eine feste Fußleiste), damit fokussierte Elemente nicht darunter rutschen.

8. Breadcrumbs

Was gefordert ist. Breadcrumbs sind kein Pflichtkriterium auf AA, aber eine anerkannte Technik für 2.4.8 Ort (AAA) und nach unserer Lesart als „Links zu verwandten Seiten“ ein möglicher zweiter Weg für 2.4.5. Laut APG Breadcrumb ist ein Brotkrümelpfad eine Liste von Links zu den übergeordneten Seiten in hierarchischer Reihenfolge. Er steht in einer Navigation-Landmark mit Namen (aria-label oder aria-labelledby), und der Link zur aktuellen Seite trägt aria-current="page"; ist die aktuelle Seite kein Link, ist aria-current optional.

So prüfen Sie. Auf einer Produktseite mit dem Screenreader zum Brotkrümelpfad. Hören Sie den Namen der Navigation, eine Liste und beim letzten Eintrag „Aktuelle Seite“ (Wortlaut NVDA)? Die Trennzeichen (Pfeile, Schrägstriche) dürfen nicht als „größer als“ oder „Schrägstrich“ vorgelesen werden.

So beheben Sie. <nav aria-label="Brotkrümelpfad"> um eine geordnete Liste (ol), letzter Eintrag mit aria-current="page", Trennzeichen per CSS als Rahmen oder Hintergrundgrafik, nicht als Text im HTML und nicht als CSS-Text.

9. Suche

Was gefordert ist. Eine Suchfunktion ist laut Understanding 2.4.5 einer der anerkannten Wege, Seiten zu finden. Für die Navigation zählt außerdem: Das Suchfeld ist per Tastatur erreichbar, hat eine Beschriftung, die Lupe ist ein Button mit Namen. Steht die Suche auf mehreren Seiten, dann in derselben relativen Reihenfolge (3.2.3; das Understanding nennt als Beispiel ein Suchfeld, das immer der letzte Eintrag ist).

So prüfen Sie. Aufgeklappte Suche per Tastatur öffnen, Begriff eingeben, Vorschläge mit den Pfeiltasten durchgehen, Enter. Kommen Sie ohne Maus zur Ergebnisseite, und können Sie die Suchebene mit Escape wieder schließen?

So beheben Sie. Wie Suchfeld, Vorschlagsliste und Ergebnisansage im Einzelnen umgesetzt werden, steht in Produktfilter barrierefrei: Filter, Sortierung und Suche im Shop. Für die Navigation reicht: Die Suche ist ein Formular mit Beschriftung, und der Button, der eine eingeklappte Suche öffnet, folgt dem Disclosure-Muster aus Abschnitt 3.

10. Konsistente Navigation und mehrere Wege

3.2.3 Konsistente Navigation. Navigation, die sich auf mehreren Seiten wiederholt, steht jedes Mal in derselben relativen Reihenfolge, außer der Nutzer ändert sie selbst (Understanding 3.2.3). Wichtig für Shops, laut Understanding:

• Zusätzliche Einträge sind erlaubt, etwa ein aufgeklapptes Untermenü oder eine Unternavigation in der Kategorie. Die übrigen Einträge behalten nur ihre Reihenfolge zueinander.
• Der Checkout mit eigenem, reduziertem Layout gilt im Beispiel des W3C nicht als Teil der Produktseiten. Ein Checkout ohne Hauptmenü verstößt also nicht gegen 3.2.3.
• Als Fehler nennt das W3C Navigationslinks, die auf verschiedenen Seiten in unterschiedlicher Reihenfolge stehen (F66).

So prüfen Sie 3.2.3. Schreiben Sie auf Startseite, Kategorie, Produktseite, Warenkorb und einer Inhaltsseite (etwa Versandinfos) die Reihenfolge in der Kopfzeile auf: Sprunglink, Logo, Menüpunkte, Suche, Konto, Warenkorb. Weicht eine Seite ab, etwa weil eine Landingpage ein anderes Theme-Template nutzt oder ein Seitenbaukasten ein eigenes Menü einbaut, ist das ein Fund. Dasselbe für die Fußzeile.

2.4.5 Mehrere Wege. Jede Seite ist auf mehr als einem Weg auffindbar, außer sie ist Ergebnis oder Schritt eines Vorgangs (Understanding 2.4.5). Checkout-Schritte und die Bestellbestätigung sind damit ausgenommen. Als Techniken nennt das W3C zwei oder mehr aus: Links zu verwandten Seiten, Inhaltsverzeichnis, Sitemap, Suchfunktion, Liste aller Seiten, Links von der Startseite auf alle Seiten.

So prüfen Sie 2.4.5. Nehmen Sie eine Produktseite, eine Kategorieseite und eine Inhaltsseite wie „Versand und Rückgabe“. Finden Sie jede über das Menü und zusätzlich über die Suche, eine Sitemap oder die Fußzeile? Achtung: Findet Ihre Shopsuche nur Produkte, aber keine Inhaltsseiten, brauchen Versand-, Kontakt- und Rechtsseiten einen zweiten Weg, zum Beispiel Links in der Fußzeile. Unsere Einschätzung: Menü plus Suche plus Fußzeilenlinks deckt das in den meisten Shops ab.

Fehlerbilder, Kriterium, Behebung

Checkliste: Navigation selbst prüfen

Sprunglink und Landmarks

• Erster Tab-Druck zeigt einen sichtbaren Link „Zum Inhalt“.
• Enter springt zum Hauptinhalt, der nächste Tab bleibt im Hauptinhalt.
• Hauptmenü steht in einem nav-Element; mehrere Navigationen haben unterschiedliche Namen.

Hauptmenü und Mega-Menü

• Jedes Untermenü öffnet mit Enter oder Leertaste.
• Der nächste Tab nach dem Öffnen geht ins Untermenü.
• Zugeklappte Untermenüs sind mit Tab nicht erreichbar.
• Escape schließt das Untermenü, Fokus steht wieder auf dem Hauptpunkt.
• Screenreader sagt Name, „Schalter“ und „ausgeklappt“ beziehungsweise „eingeklappt“.
• Keine Rolle „Menü“ oder „Menüleiste“, außer die volle Pfeiltastenbedienung funktioniert.
• Hauptpunkte, die zugleich Link sind, haben einen eigenen Button zum Aufklappen.
• Der Link zur aktuellen Seite hat aria-current="page".

Hover

• Untermenü bleibt offen, wenn Sie mit der Maus hineinfahren, auch bei 200 % Zoom.
• Escape schließt ein per Maus geöffnetes Untermenü.
• Untermenü schließt nicht nach einer Zeit von selbst.

Mobiles Menü

• Bei 400 % Zoom (1280 Pixel Fenster) erscheint das Handy-Menü, alle Punkte sind erreichbar.
• Hamburger ist ein Button mit Namen und aria-expanded.
• Fokus geht nach dem Öffnen ins Menü, nicht hinter das Menü.
• Schließen-Button mit Namen und Escape funktionieren, Fokus zurück auf den Hamburger.
• Mit VoiceOver oder TalkBack auf dem Smartphone durchgegangen.

Fokus

• Reihenfolge in der Kopfzeile ist nachvollziehbar, kein tabindex über 0.
• Fokus ist auf jedem Menüpunkt deutlich sichtbar, eigener Rahmen mit mindestens 3:1.
• Fokus verschwindet nie ganz unter fester Kopfleiste oder Cookie-Banner; ein offenes Mega-Menü schließt, sobald der Fokus es verlässt, oder mit Escape.

Breadcrumbs, Suche, Konsistenz

• Breadcrumbs in benannter Navigation, als Liste, aktuelle Seite markiert, Trennzeichen werden nicht vorgelesen.
• Suche per Tastatur öffnen, nutzen und schließen; Feld beschriftet, Lupe mit Namen.
• Kopf- und Fußzeile auf fünf Seitentypen in derselben Reihenfolge.
• Produkt-, Kategorie- und Inhaltsseiten auf mindestens zwei Wegen auffindbar.

Dokumentation

• Jeden Fund mit Seite, Baustein, Kriterium und Behebung notiert.
• Funde, die im Theme stecken, einmal an Theme-Anbieter oder Agentur gegeben.
• Nach jeder Behebung denselben Test wiederholt.

Ihr nächster Schritt

Machen Sie zusätzlich den kostenlosen Scan. Er prüft Startseite, Produktseite und Warenkorb und zeigt, was zuerst behoben werden sollte. Als automatische Prüfung findet er nur einen Teil der Barrieren; ob sich Ihr Menü mit der Tastatur öffnen und schließen lässt und wohin der Fokus springt, prüfen Sie selbst mit der Checkliste oben.

Stand: 29.10.2026. Quellen gelesen am 29.10.2026.