Barrierefreie Navigation: Skip-Links, Menues und Fokus

Wenn die Navigation versagt, scheitert der gesamte Besuch. Ein Nutzer, der das Hauptmenü nicht per Tastatur öffnen kann, erreicht keine Unterseite. Ein Screenreader-Nutzer, der die Seitenstruktur nicht erfassen kann, verliert die Orientierung. Die WCAG behandeln Navigation deshalb nicht als Randthema, sondern verteilen die Anforderungen über mehrere Erfolgskriterien: 2.4.1 Bypass Blocks für das Überspringen von Blöcken, 2.4.3 Focus Order für eine sinnvolle Reihenfolge, 4.1.2 Name, Role, Value für die korrekte Semantik interaktiver Elemente und 2.4.7 Focus Visible für die sichtbare Fokusanzeige.

Die Tragweite zeigt sich in der Statistik der häufigsten Fehler. Niedrige Textkontraste betreffen 79,1 Prozent (WebAIM Million 2025) aller Startseiten, fehlende Alternativtexte 55,5 Prozent (WebAIM Million 2025), wobei bei 44 Prozent dieser Fälle verlinkte Bilder betroffen sind und damit die Navigation für Screenreader-Nutzer vollständig unterbrochen wird (WebAIM Million 2025). Die durchschnittliche Startseite enthielt 2024 rund 1.173 (WebAIM Million 2024) DOM-Elemente, ein Anstieg von 11,8 Prozent gegenüber dem Vorjahr (WebAIM Million 2024). Mit wachsender Komplexität steigt der Bedarf an Mechanismen, die Nutzern erlauben, gezielt zu navigieren statt sich linear durch hunderte Elemente zu tasten.

Seit Juni 2025 ist der European Accessibility Act in der EU durchsetzbar und verlangt unter anderem tastaturbedienbare Websites und die Unterstützung assistiver Technologien (Level Access). Die maßgebliche Norm EN 301 549 verweist als Mindestbenchmark auf die WCAG, in der aktuellen Fassung auf Level AA (Acquia). Eine barrierefreie Navigation ist damit nicht nur eine Frage der Nutzerfreundlichkeit, sondern eine rechtliche Anforderung, deren Grundlagen wir im Beitrag zu den [BFSG-Anforderungen1 ausführlich darstellen.

Ein Skip-Link ist der erste fokussierbare Link einer Seite. Er erlaubt Tastaturnutzern, Header und Navigation zu überspringen und direkt zum Hauptinhalt zu springen. Ohne Skip-Link muss sich ein Tastaturnutzer auf jeder einzelnen Seite durch sämtliche Navigationslinks tabben, bevor er den eigentlichen Inhalt erreicht. Bei einer Navigation mit 20 Einträgen sind das 20 zusätzliche Tab-Anschläge -- auf jeder Seite, bei jedem Besuch. Das WCAG-Kriterium 2.4.1 Bypass Blocks (Level A) verlangt genau deshalb einen Mechanismus, der wiederkehrende Blöcke überspringbar macht.

Technisch ist ein Skip-Link ein Anker, der auf das

Auf umfangreichen Seiten können mehrere Skip-Links sinnvoll sein, etwa zum Inhalt, zur Suche und zur Hauptnavigation. Sie werden als kompakte Liste am Seitenanfang umgesetzt. Interessant ist die Datenlage: Laut WebAIM nutzen erfahrene Screenreader-Nutzer Skip-Links seltener, weil sie ohnehin über Überschriften und Landmarks springen (WebAIM Skip Navigation). Für sehende Tastaturnutzer ohne diese Sprungmechanismen bleiben Skip-Links jedoch ein wesentliches Hilfsmittel. Unsere [barrierefreie Webentwicklung1 implementiert Skip-Links daher als Standardbaustein und ergänzt sie um eine saubere Landmark-Struktur.

Screenreader-Nutzer navigieren selten linear. Nach dem WebAIM Screen Reader User Survey finden 71,6 Prozent (WebAIM Survey 2024) der Befragten Informationen auf langen Seiten, indem sie zuerst durch die Überschriften springen. 88 Prozent (WebAIM Survey 2024) bezeichnen Überschriften als sehr oder etwas nützlich. Eine korrekte Überschriftenhierarchie ist damit selbst ein Navigationsinstrument: Sie ersetzt für viele Nutzer das visuelle Scannen einer Seite.

Landmarks ergänzen die Überschriften. Sie strukturieren die Seite in Bereiche wie header, nav, main, aside und footer. Die Nutzung von Landmarks zeigt einen wechselhaften Verlauf: Von 43,8 Prozent häufiger Nutzung im Jahr 2014 sank sie bis 2021 auf 25,6 Prozent, stieg in der Erhebung 2024 jedoch wieder auf 31,8 Prozent (WebAIM Survey 2024). Als primäre Methode auf langen Seiten setzen nur 3,7 Prozent der Befragten auf Landmarks (WebAIM Survey 2024) -- Überschriften und Landmarks ergänzen einander, ersetzen sich aber nicht.

Werden mehrere nav-Elemente verwendet, etwa Haupt- und Servicenavigation, sollte jedes per aria-label eindeutig benannt werden. So kann der Screenreader-Nutzer zwischen den Bereichen unterscheiden, statt mehrfach auf eine namenlose Navigation zu stoßen. Wie semantische Strukturen für Screenreader optimal aufgebaut werden, beschreibt unser Beitrag zur [Screenreader-Optimierung1 im Detail.

In der Praxis lohnt es sich, die Navigation früh im Projekt als eigenständige Komponente zu betrachten und nicht erst nachträglich zu reparieren. Wer Skip-Link, Landmark-Struktur und Überschriftenhierarchie von Beginn an mitdenkt, vermeidet teure Nacharbeiten und schafft eine Grundlage, auf der weitere Bausteine wie Suche, Brotkrumen und Footer-Navigation widerspruchsfrei aufsetzen. Diese strukturelle Klarheit zahlt sich nicht nur in der Barrierefreiheit aus, sondern verbessert auch die Wartbarkeit und die Verständlichkeit für Suchmaschinen, die dieselbe semantische Struktur auswerten.

Ein verbreitetes Missverständnis betrifft die ARIA-Rolle menu. Sie ist nicht für klassische Website-Navigation gedacht, sondern für anwendungsähnliche Menüs wie in Desktop-Programmen, mit eigener Tastaturlogik aus Pfeiltasten und ohne Tab-Stops zwischen den Einträgen. Der WebAIM Million Report 2025 zeigt die Folgen des Fehlgebrauchs: 4,5 Prozent (WebAIM Million 2025) der Startseiten setzten ein ARIA-Menü mit role="menu" ein, und bei 35 Prozent (WebAIM Million 2025) dieser Menüs entstanden dadurch Barrieren, weil die nötige Menü-Auszeichnung und -Interaktion fehlte.

Für die überwiegende Mehrheit der Website-Navigationen ist das Disclosure-Muster die robustere Wahl. Eine Navigation besteht aus einer ungeordneten Liste von Links innerhalb eines nav-Elements. Untermenüs werden über einen Button mit aria-expanded ein- und ausgeklappt. Dieser Ansatz nutzt native, von allen Screenreadern verstandene Semantik und verlangt deutlich weniger eigene Tastaturlogik.

Ein zugängliches Dropdown im Disclosure-Muster öffnet per Enter oder Leertaste, signalisiert seinen Zustand über aria-expanded und lässt sich per Escape wieder schließen. Wird das Untermenü geschlossen, kehrt der Fokus zum auslösenden Button zurück. Diese Muster sind in den WAI-ARIA Authoring Practices dokumentiert und bilden den Standard für barrierefreie Navigationskomponenten (W3C WAI-ARIA APG).

Nutzer müssen erkennen können, wo sie sich innerhalb der Navigation befinden. Visuell geschieht das oft durch eine Hervorhebung des aktiven Menüpunkts. Für Screenreader-Nutzer reicht eine rein visuelle Auszeichnung jedoch nicht aus. Das Attribut aria-current="page" markiert den Link zur aktuellen Seite programmatisch, sodass der Screenreader ihn als aktuelle Seite ankündigt.

aria-current kennt mehrere Werte je nach Kontext: page für die aktuelle Seite in einer Navigation, step in einem mehrstufigen Prozess, location in einem Fortschrittsindikator und true als allgemeine Variante. Die Kombination aus visueller Hervorhebung und programmatischer Auszeichnung stellt sicher, dass die aktuelle Position für alle Nutzergruppen erkennbar ist -- ein Prinzip, das eng mit der korrekten Auszeichnung von Zuständen über [ARIA-Rollen und Zustände1 zusammenhängt.

Jede Funktion der Navigation muss per Tastatur erreichbar und bedienbar sein. Das verlangt WCAG 2.1.1 Keyboard (Level A). In der Praxis heißt das: Links werden mit Enter aktiviert, Buttons mit Enter oder Leertaste, Untermenüs öffnen und schließen über die zugehörigen Tasten, und Escape schließt ein geöffnetes Menü. Bei der Tab-Navigation folgt der Fokus der DOM-Reihenfolge, die der visuellen Reihenfolge entsprechen sollte.

In ausgedehnten Navigationsgruppen wie Mega-Menüs kann das Roving-Tabindex-Muster die Bedienung verbessern: Nur das aktive Element erhält tabindex="0", alle anderen tabindex="-1", und die Pfeiltasten verschieben den aktiven Index. So wird die Zahl der Tab-Stops reduziert. Für die meisten klassischen Navigationen ist jedoch das einfache Disclosure-Muster mit individuellen Tab-Stops pro Link ausreichend und wartungsärmer. Die vollständigen Tastaturmuster für Menüs, Tabs und Widgets behandelt unser Beitrag zur [Tastaturnavigation in der Webentwicklung1.

Der Fokus ist der Cursor der Tastaturnutzer. Er muss jederzeit sichtbar sein, damit der Nutzer weiß, welches Element gerade aktiv ist. WCAG 2.4.7 Focus Visible (Level AA) verlangt einen sichtbaren Fokusindikator. Das neuere Kriterium 2.4.11 Focus Not Obscured (Level AA) aus WCAG 2.2 ergänzt, dass das fokussierte Element nicht vollständig durch andere Inhalte wie klebende Header verdeckt sein darf (W3C WCAG 2.2).

Viele Designs entfernen den Standard-Fokusring per outline: none, weil er als störend empfunden wird. Das ist nur zulässig, wenn ein gleichwertiger oder besserer Ersatz vorhanden ist. Die CSS-Pseudoklasse :focus-visible löst den Zielkonflikt: Sie zeigt den Fokus nur bei Tastaturbedienung, nicht bei Mausklicks. So bleibt das Design für Mausnutzer ruhig, während Tastaturnutzer eine klare Anzeige erhalten.

Bei dynamischen Navigationsvorgängen, etwa beim Aufklappen eines Mega-Menüs oder beim Routenwechsel in einer Single-Page-Application, muss der Fokus aktiv gesteuert werden. Öffnet sich ein Untermenü, sollte der Fokus dort sinnvoll platziert werden; beim Schließen kehrt er zum Auslöser zurück. In Single-Page-Applications wird der Fokus nach einem Seitenwechsel auf den Anfang des neuen Inhalts gesetzt, damit Screenreader-Nutzer die Änderung bemerken.

Auf kleinen Bildschirmen wird die Navigation häufig hinter einem Menü-Button verborgen, der ein Off-Canvas-Panel öffnet. Auch hier gelten die bekannten Prinzipien. Der Button trägt aria-expanded, das den Zustand widerspiegelt, sowie ein zugängliches Label wie aria-label="Menü", falls er nur ein Icon zeigt. Beim Öffnen des Panels wird der Fokus in das Panel verschoben, beim Schließen kehrt er zum Button zurück.

Ein geöffnetes Off-Canvas-Menü, das den Rest der Seite überlagert, verhält sich ähnlich wie ein modaler Dialog: Der Fokus sollte innerhalb des Menüs bleiben, und Escape sollte es schließen. Gleichzeitig darf das Menü keine Keyboard-Trap erzeugen -- nach dem Schließen muss der Nutzer normal weiternavigieren können. Die Detailregeln für solche überlagernden Komponenten beschreibt unser Beitrag zu [barrierefreien Modals und Overlays1.

Ein häufig unterschätzter Aspekt ist die Konsistenz der Navigation über alle Seiten hinweg. Tastatur- und Screenreader-Nutzer bauen sich ein mentales Modell der Seitenstruktur auf; springt die Reihenfolge der Menüpunkte von Seite zu Seite oder verändert sich das Verhalten der Untermenüs, geht dieser Orientierungsvorteil verloren. Eine einheitliche, vorhersagbare Navigation entspricht dem WCAG-Prinzip der Konsistenz (3.2.3 Consistent Navigation, Level AA) und reduziert die kognitive Last für alle Nutzergruppen. In der Umsetzung bedeutet das, die Navigation als zentrale Komponente zu pflegen statt sie pro Seite zu duplizieren.

Neben dem Hauptmenü gibt es weitere Navigationsmuster, die barrierefrei gestaltet werden müssen. Eine Brotkrumennavigation (Breadcrumb) wird typischerweise in ein nav-Element mit aria-label="Brotkrumen" gefasst, als geordnete Liste umgesetzt und der aktuelle Eintrag mit aria-current="page" markiert. So erkennen Screenreader-Nutzer ihre Position in der Seitenhierarchie.

Eine Suchfunktion sollte mit einem korrekt beschrifteten Eingabefeld und einem zugänglichen Button ausgestattet sein; das umschließende form-Element kann mit role="search" ausgezeichnet werden, damit Screenreader es als Suchbereich ansagen. Bei der Paginierung von Listen oder Suchergebnissen werden die Seitenzahlen als Links umgesetzt, die aktuelle Seite mit aria-current="page" markiert und die Schaltflächen für vor und zurück eindeutig benannt.

Der wirkungsvollste Test der Navigation ist der manuelle Tastaturtest: Maus weglegen und ausschließlich mit Tab, Shift+Tab, Enter, Leertaste, Escape und Pfeiltasten navigieren. Dabei wird systematisch geprüft, ob der Skip-Link funktioniert, ob jeder Menüpunkt erreichbar ist, ob Untermenüs zugänglich sind, ob der Fokus stets sichtbar bleibt und ob es keine Keyboard-Traps gibt.

Ergänzend zeigt ein Screenreader, ob Landmarks, Überschriften und aria-current korrekt angekündigt werden. Automatisierte Prüfwerkzeuge finden grundlegende Probleme wie fehlende Labels oder ARIA-Fehler, ersetzen aber den manuellen Test nicht, da sie Fokus-Flows und komplexe Interaktionen nicht beurteilen können. Welche Werkzeuge sich für welchen Prüfschritt eignen, behandelt unser Überblick zu [Accessibility-Testing-Tools1. Ein professionelles [WCAG-Audit2 kombiniert automatisierte Prüfung, manuelle Tastatur- und Screenreader-Tests zu einer belastbaren Bewertung.