WCAG & BFSG · WCAG-Referenz: Verständlich
WCAG 3.2.3: Konsistente Navigation
WCAG 3.2.3 verlangt, dass Navigationsmechanismen, die auf mehreren Seiten wiederholt werden, dort in derselben relativen Reihenfolge erscheinen – Menü, Suche, Breadcrumb, Fußzeile, Skip-Link. Einschübe sind erlaubt, Umsortierungen nicht: Wer die Seite wechselt, soll sich nicht neu orientieren müssen.
(Englisch: Consistent Navigation. Im BIK-BITV-Test heißt der Prüfschritt „3.2.3 Konsistente Navigation“.)
| Stufe | Prinzip | Teil der WCAG seit | Rechtlich verbindlich? |
|---|---|---|---|
| AA | Verständlich | 2.0 (2008) | Ja – über EN 301 549 in BFSG & BITV |
Das Wichtigste in Kürze
- „Relative Reihenfolge“ heißt: Die Blöcke behalten ihre Ordnung zueinander. Ein zusätzlicher Menüpunkt ist zulässig, ein umsortiertes Menü nicht.
- Betroffen sind alle wiederholten Mechanismen: Hauptnavigation, Bereichsmenüs, Suche, Breadcrumbs, Fußzeilenlinks, Skip-Links, Teaser-Bereiche.
- Die Startseite darf abweichen. Der Prüfschritt nennt das ausdrücklich – dort fehlt oft das Bereichsmenü oder es gibt zusätzliche Einstiege.
- Prozesse sind ausgenommen: Checkout, Registrierung, Quiz. Sie gelten als eigener Bereich mit schrittweiser Navigation.
- Jede Abweichung gehört begründet. Im BIK-BITV-Test ist eine Bewertung als „teilweise erfüllt“ oder „nicht erfüllt“ immer zu erläutern.
- Geprüft wird mit aktiviertem JavaScript und Standard-Stylesheets – nicht in einer abgespeckten Ansicht.
- Die technische Lösung ist strukturell: eine einzige Datenquelle für die Navigation, aus der alle Seiten schöpfen.
- Stufe AA, seit WCAG 2.0 unverändert und über die EN 301 549 verbindlich.
Muss die Navigation auf jeder Seite gleich sein?
In derselben relativen Reihenfolge, ja. Einschübe sind erlaubt, Umsortierungen nicht.
Der Normtext verlangt, dass sich wiederholende Navigationsmechanismen auf jeder Seite innerhalb einer Gruppe von Webseiten in derselben relativen Reihenfolge befinden – es sei denn, die nutzende Person hat die Änderung selbst veranlasst.
Der Begriff relative Reihenfolge ist die Stelle, an der Missverständnisse entstehen. Er bedeutet nicht: pixelgenau dieselbe Position. Er bedeutet: Die wiederkehrenden Elemente behalten ihre Ordnung zueinander. Wenn das Menü auf der Startseite „Produkte · Preise · Kontakt“ lautet, darf es auf der Unterseite nicht „Kontakt · Produkte · Preise“ heißen. Ein zusätzlicher Punkt „Aktionen“ zwischen Preise und Kontakt ist dagegen zulässig – er schiebt sich ein, ohne die Ordnung zu zerstören.
Der BIK-BITV-Test prüft dabei nicht nur das Hauptmenü. Genannt werden Menüs, Direktlinks, Breadcrumb-Navigation, Teaser und Suchfunktionen. Geprüft wird durch Erkundung: Von der Startseite aus verschiedene Bereiche aufsuchen und vergleichen, ob die Navigationselemente konsistent angeordnet und gestaltet sind. Und ausdrücklich: mit aktiviertem JavaScript und den Standard-Stylesheets – also so, wie die Seite tatsächlich ausgeliefert wird.
Drei Ausnahmen sind anerkannt:
Die Startseite. Sie darf sich häufig unterscheiden, weil dort kein Bereichsmenü nötig ist oder zusätzliche Einstiege angeboten werden. Das ist keine Nachlässigkeit, sondern ein üblicher Aufbau.
Prozesse. Abweichende Navigation in Checkout-, Registrierungs- oder Quiz-Strecken ist zulässig; sie funktionieren als eigener Bereich mit schrittweiser Führung. Eine reduzierte Navigation im Kassenbereich ist damit kein Verstoß – solange das, was bleibt, seine Ordnung behält.
Vom Nutzer veranlasste Änderungen. Wer eine Navigation selbst umsortiert oder eine Ansicht wählt, hat die Abweichung ausgelöst und wird davon nicht überrascht.
Ein Hinweis des Prüfschritts, der bei Einzelseiten-Anwendungen wichtig wird: Bei skriptgenerierten Ebenen sollte geprüft werden, ob sie sich deutlich unterscheiden – denn dort funktioniert die Zurück-Funktion des Browsers oft nicht wie erwartet.
Der Normtext steht im Understanding-Dokument des W3C zu 3.2.3, das deutsche Prüfvorgehen im Prüfschritt „3.2.3 Konsistente Navigation“.
Wen betrifft es besonders?
Menschen mit kognitiven Einschränkungen und Gedächtnisproblemen prägen sich Positionen ein, nicht Beschriftungen: „Kontakt ist immer der letzte Punkt.“ Wenn diese Regel auf einer Unterseite nicht mehr gilt, ist die gelernte Abkürzung wertlos – und der Aufwand beginnt bei jeder Seite von vorn. Der Prüfschritt begründet das Kriterium ausdrücklich mit der reduzierten kognitiven Belastung durch Vorhersehbarkeit.
Screenreader-Nutzende arbeiten mit gelernten Sprungfolgen: „Zweimal die Landmark-Taste, dann bin ich im Menü, viertes Element ist die Suche.“ Diese Routinen sind der Grund, warum erfahrene Nutzende deutlich schneller sind als Gelegenheitsnutzende. Eine umsortierte Navigation macht genau diese Routinen unbrauchbar.
Menschen mit Vergrößerung suchen Bereiche anhand ihrer erwarteten Position. Bei starkem Zoom sieht man den Kopfbereich nicht als Ganzes, sondern fährt ihn ab. Wer weiß, dass die Suche rechts außen sitzt, fährt direkt dorthin – wenn sie auf der nächsten Seite links steht, beginnt die Suche von vorn.
Und Sprachsteuerungs-Nutzende arbeiten mit Befehlen, die auf die sichtbare Beschriftung zielen. Konsistenz in Reihenfolge und Benennung ist für sie die Voraussetzung dafür, dass ein einmal gelernter Befehl überall funktioniert – die Benennung selbst regelt 3.2.4.
Richtig & falsch im Code
Dieses Kriterium ist kein Markup-Problem, sondern ein Architekturproblem. Wo Navigation je Seite von Hand gepflegt wird, ist die Abweichung nur eine Frage der Zeit. Die Lösung ist eine einzige Datenquelle:
// Richtig: nav.ts als einzige Quelle für alle Ausgaben
export const navigation = [
{ titel: 'Barrierefreiheit verstehen', pfad: '/barrierefreiheit-verstehen.html' },
{ titel: 'Semantisches HTML', pfad: '/semantisches-html.html' },
{ titel: 'WCAG & BFSG', pfad: '/wcag-und-bfsg.html' },
{ titel: 'Barrierefreie Komponenten', pfad: '/barrierefreie-komponenten.html' },
{ titel: 'SEO & KI', pfad: '/seo-und-ki.html' },
{ titel: 'Ressourcen', pfad: '/ressourcen.html', sekundaer: true },
];
nav.ts (eine Quelle)
├─ Mega-Menü → identische Reihenfolge auf jeder Seite
├─ Breadcrumbs → identische Logik auf jeder Seite
├─ Fußzeilenspalten → identische Reihenfolge auf jeder Seite
└─ Sitemap/llms.txt → dieselbe Struktur für Maschinen
Diese Website macht genau das: Mega-Menü, Breadcrumbs, Fußzeile und Sitemap kommen aus einer Datei. Drift zwischen Seiten ist damit strukturell ausgeschlossen – nicht, weil jemand aufpasst, sondern weil es keine zweite Stelle gibt, an der man abweichen könnte.
Im Markup zählt vor allem, dass die Bereiche unterscheidbar benannt sind:
<!-- Falsch: zwei gleichnamige Navigationsbereiche,
die Reihenfolge ist nicht nachvollziehbar -->
<nav>…</nav>
<nav>…</nav>
<!-- Richtig: benannte Landmarks in stabiler Reihenfolge -->
<header>
<a class="skip-link" href="#inhalt">Zum Inhalt springen</a>
<nav aria-label="Hauptnavigation">…</nav>
<nav aria-label="Ressourcen">…</nav>
<search>
<form action="/suche.html">…</form>
</search>
</header>
<nav aria-label="Sie sind hier">…</nav>
<main id="inhalt">…</main>
<footer>
<nav aria-label="Fußzeile">…</nav>
</footer>
Die Benennung über aria-label ist hier mehr als Kosmetik: Bei mehreren nav-Elementen sind sie sonst nicht unterscheidbar, und die gelernte Sprungfolge funktioniert nicht mehr. Mehr dazu unter Landmarks & Outline und Mega-Menüs.
Ein Detail, das häufig übersehen wird: Die mobile Navigation muss aus derselben Quelle kommen. Zwei getrennt gepflegte Menüs – eines für Desktop, eines für Mobil – sind die zuverlässigste Methode, dieses Kriterium zu reißen.
{/* Richtig: eine Quelle, zwei Darstellungen */}
<nav aria-label="Hauptnavigation" class="nav-desktop">
{navigation.map((e) => <a href={e.pfad}>{e.titel}</a>)}
</nav>
<nav aria-label="Hauptnavigation" class="nav-mobil" hidden>
{navigation.map((e) => <a href={e.pfad}>{e.titel}</a>)}
</nav>
So testest du es
- Drei bis fünf Seiten aus verschiedenen Bereichen öffnen und Kopf- und Fußbereich nebeneinanderlegen: gleiche Elemente, gleiche Ordnung?
- Nicht nur das Hauptmenü prüfen. Suche, Breadcrumb, Sprachumschalter, Fußzeilenspalten, Teaser-Bereiche und Skip-Link gehören dazu.
- Die mobile Ansicht gegen die Desktop-Ansicht prüfen. Kommen beide aus derselben Quelle, oder sind es zwei handgepflegte Welten?
- Sonderseiten nicht vergessen: Suchergebnisse, 404, Anmeldung, Checkout, Landingpages aus Kampagnen. Dort weicht die Navigation am häufigsten ab.
- Mit aktiviertem JavaScript und Standard-Stylesheets testen – so schreibt es der Prüfschritt vor.
- Mit dem Screenreader die Landmarks durchgehen. Kommen sie auf jeder Seite in derselben Reihenfolge und mit denselben Namen?
- Abweichungen notieren und einordnen: Startseite oder Prozessstrecke? Dann ist es zulässig. Sonst gehört es begründet.
Häufiger Fehler in der Praxis
Der häufigste Fehler ist die Landingpage aus der Marketingabteilung. Für eine Kampagne entsteht eine Seite mit eigenem Kopfbereich: Logo links, ein einzelner Knopf rechts, kein Menü, keine Suche. Sie liegt auf derselben Domain, wird verlinkt und ist Teil des Angebots – und weicht in allem ab. Solche Seiten sind keine Prozessschritte und fallen nicht unter die Ausnahme.
Der zweite ist das zweite Menü für Mobil. Irgendwann wurde für kleine Bildschirme eine eigene Struktur gebaut, weil „da eh weniger Platz ist“. Zwei Jahre später enthält sie andere Punkte in anderer Reihenfolge, weil Änderungen nur an einer Stelle gepflegt wurden. Ich würd bei jedem Audit als Erstes die beiden Menüs nebeneinander legen; das findet in zwei Minuten mehr als jede Codeansicht.
Der dritte ist die Bereichsnavigation, die mal links und mal oben steht. Der Produktbereich hat eine seitliche Navigation, der Servicebereich eine waagerechte unter dem Kopf. Die Punkte sind dieselben, die Position nicht. Für Menschen, die Bereiche nach Position ansteuern, sind das zwei verschiedene Websites.
Und der vierte, der in Selbstchecks nie auffällt: der Skip-Link, den es nur auf manchen Seiten gibt. Er ist unsichtbar, bis man ihn fokussiert – und wenn er auf der Detailseite fehlt, während er auf der Übersicht existiert, merkt es niemand außer denen, die ihn nutzen. Er ist ein wiederkehrender Navigationsmechanismus wie jeder andere.
Häufige Fragen
Darf die Startseite anders aussehen?
Ja. Der Prüfschritt nennt das ausdrücklich: Die Startseite unterscheidet sich häufig, weil dort kein Bereichsmenü nötig ist oder zusätzliche Einstiege angeboten werden. Was auf ihr vorkommt, sollte trotzdem die gewohnte Ordnung halten – die Suche gehört auch dort dorthin, wo sie überall sonst steht.
Zählt ein zusätzlicher Menüpunkt als Verstoß?
Nein. Verlangt ist die gleiche relative Reihenfolge. Ein zusätzlicher Punkt, der sich zwischen zwei bestehende schiebt, verändert deren Ordnung zueinander nicht. Kritisch wird es erst, wenn bestehende Punkte ihre Position tauschen oder ohne Grund verschwinden.
Gilt das Kriterium auch für den Checkout?
Nein, sofern der Checkout als Prozess gestaltet ist. Der Prüfschritt erlaubt abweichende Navigation in Checkout-, Registrierungs- und Quiz-Strecken ausdrücklich, weil sie als eigener Bereich mit schrittweiser Führung funktionieren. Eine reduzierte Navigation dort ist zulässig – auch das, was bleibt, sollte aber seine Ordnung behalten.
Muss die mobile Navigation identisch sein?
Sie muss dieselbe relative Reihenfolge haben. Die Darstellung darf sich unterscheiden – ausgeklappt statt waagerecht, hinter einem Knopf statt sichtbar. Was sich nicht unterscheiden darf, ist die Ordnung der Punkte. Die sicherste Lösung ist, beide Darstellungen aus derselben Datenquelle zu erzeugen.
Was ist der Unterschied zu 3.2.4?
3.2.3 betrifft die Anordnung wiederkehrender Navigation, 3.2.4 die Benennung wiederkehrender Funktionen. Ein Menü, das überall an derselben Stelle steht, dessen Suchknopf aber mal „Suchen“ und mal „Los“ heißt, erfüllt 3.2.3 und verstößt gegen 3.2.4.
Verwandte Themen
- 3.2.4 Konsistente Erkennung – dieselbe Logik für Benennungen
- 3.2.6 Konsistente Hilfe – der WCAG-2.2-Neuzugang für Hilfeangebote
- 2.4.5 Verschiedene Methoden – mehrere Wege, die alle verlässlich bleiben müssen
- Mega-Menüs – Navigation als System bauen
- Landmarks & Outline – benannte Bereiche als Sprungziele
- Breadcrumbs – die zweite wiederkehrende Navigation