Eine barrierefreie Navigation muss f\u00fcr alle Nutzerinnen und Nutzer unabh\u00e4ngig von ihren k\u00f6rperlichen oder kognitiven F\u00e4higkeiten vollst\u00e4ndig bedienbar sein. Das bedeutet konkret: Alle Navigationselemente m\u00fcssen per Tastatur erreichbar sein, eine klare Struktur aufweisen und mit Hilfstechnologien wie Screenreadern funktionieren. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um technische Anforderungen, rechtliche Vorgaben, typische Fehler und die Pr\u00fcfung barrierefreier Navigation.<\/p>\n
Eine barrierefreie Navigation muss tastaturgesteuert, screenreaderkompatibel und strukturell klar aufgebaut sein. Navigationsbereiche m\u00fcssen im HTML-Code eindeutig ausgezeichnet sein, Fokuszust\u00e4nde sichtbar bleiben und die Reihenfolge der Elemente der visuellen Darstellung entsprechen. Nur so k\u00f6nnen Nutzerinnen und Nutzer mit Einschr\u00e4nkungen die Website selbstst\u00e4ndig bedienen.<\/p>\n
Im Einzelnen lassen sich die technischen Anforderungen in mehrere Bereiche unterteilen:<\/p>\n
<nav><\/code>-Element ausgezeichnet sein. Werden mehrere Navigationsbereiche verwendet, m\u00fcssen diese \u00fcber aria-label<\/code> oder aria-labelledby<\/code> unterscheidbar gemacht werden.<\/li>\n- Logische Lesereihenfolge:<\/strong> Die Reihenfolge der Navigationselemente im HTML-Quellcode muss der sichtbaren Anordnung auf der Seite entsprechen, damit Screenreader-Nutzerinnen und -Nutzer die Seite in einer sinnvollen Abfolge erleben.<\/li>\n
- Ausreichende Farbkontraste:<\/strong> Texte in der Navigation m\u00fcssen ein Kontrastverh\u00e4ltnis von mindestens 4,5:1 gegen\u00fcber dem Hintergrund aufweisen. Ein automatisierter Barrierefreiheitstest<\/a> kann Kontrastprobleme in der Navigation zuverl\u00e4ssig identifizieren.<\/li>\n
- \u00dcberspringmechanismus:<\/strong> Seiten sollten einen sogenannten \u201eSkip-Link\u201c bieten, der es erm\u00f6glicht, direkt zum Hauptinhalt zu springen und wiederholte Navigationselemente zu \u00fcberspringen.<\/li>\n<\/ul>\n
Besonders komplex wird es bei dynamischen Navigationselementen wie Mega-Men\u00fcs oder mobilen Hamburger-Men\u00fcs. Hier m\u00fcssen ARIA-Attribute wie aria-expanded<\/code> und aria-haspopup<\/code> korrekt eingesetzt werden, damit assistive Technologien den aktuellen Zustand eines Men\u00fcs korrekt kommunizieren k\u00f6nnen.<\/p>\nWas schreiben WCAG, BITV und BFSG zur Navigation vor?<\/h2>\n
Die WCAG 2.2 definieren mehrere Erfolgskriterien, die direkt auf die Navigation anwendbar sind. Die BITV 2.0 \u00fcbernimmt diese Anforderungen f\u00fcr den deutschen Rechtsraum, und das Barrierefreiheitsst\u00e4rkungsgesetz (BFSG) macht sie ab 2025 f\u00fcr viele private Unternehmen verbindlich. F\u00fcr Websites bedeutet das: Navigationselemente m\u00fcssen wahrnehmbar, bedienbar, verst\u00e4ndlich und robust umgesetzt sein.<\/p>\n
Die relevanten WCAG-Erfolgskriterien f\u00fcr Navigation lassen sich wie folgt zusammenfassen:<\/p>\n
\n- Kriterium 2.1.1 (Tastatur, Level A):<\/strong> Alle Funktionen der Navigation m\u00fcssen per Tastatur bedienbar sein.<\/li>\n
- Kriterium 2.4.1 (Bl\u00f6cke umgehen, Level A):<\/strong> Es muss einen Mechanismus geben, um Navigationsbl\u00f6cke zu \u00fcberspringen.<\/li>\n
- Kriterium 2.4.3 (Fokus-Reihenfolge, Level A):<\/strong> Die Fokusreihenfolge muss sinnvoll und vorhersehbar sein.<\/li>\n
- Kriterium 2.4.7 (Fokus sichtbar, Level AA):<\/strong> Der Tastaturfokus muss jederzeit sichtbar sein.<\/li>\n
- Kriterium 3.2.3 (Konsistente Navigation, Level AA):<\/strong> Navigationsmechanismen, die auf mehreren Seiten vorkommen, m\u00fcssen konsistent angeordnet sein.<\/li>\n
- Kriterium 4.1.2 (Name, Rolle, Wert, Level A):<\/strong> Alle Navigationselemente m\u00fcssen programmatisch bestimmbare Rollen und Zust\u00e4nde haben.<\/li>\n<\/ul>\n
Die BITV 2.0 gilt f\u00fcr \u00f6ffentliche Stellen und orientiert sich vollst\u00e4ndig an den WCAG-Kriterien auf Konformit\u00e4tslevel AA. Das BFSG erweitert diese Pflichten auf viele Produkte und Dienstleistungen des privaten Sektors. F\u00fcr Websites, die unter das BFSG fallen, ist die Einhaltung dieser Navigationsanforderungen keine Empfehlung mehr, sondern rechtliche Pflicht.<\/p>\n
Welche Navigationsfehler f\u00fchren zu BFSG-Verst\u00f6\u00dfen?<\/h2>\n
Die h\u00e4ufigsten Navigationsfehler, die zu Verst\u00f6\u00dfen gegen das BFSG und die zugrunde liegenden WCAG-Kriterien f\u00fchren, sind fehlende Tastaturbedienbarkeit, nicht sichtbare Fokusindikatoren und unzureichend ausgezeichnete Navigationsbereiche. Diese Fehler betreffen besonders Nutzerinnen und Nutzer, die auf Screenreader oder Tastaturnavigation angewiesen sind.<\/p>\n
Konkret treten folgende Fehler besonders h\u00e4ufig auf:<\/p>\n
\n- Kein Skip-Link vorhanden:<\/strong> Nutzerinnen und Nutzer, die per Tastatur navigieren, m\u00fcssen bei jedem Seitenaufruf die gesamte Navigation durchlaufen, bevor sie zum Inhalt gelangen.<\/li>\n
- Fehlende oder inkorrekte ARIA-Attribute:<\/strong> Dropdown-Men\u00fcs, die ihren ge\u00f6ffneten oder geschlossenen Zustand nicht programmatisch kommunizieren, sind f\u00fcr Screenreader-Nutzerinnen und -Nutzer nicht nutzbar.<\/li>\n
- Versteckter oder fehlender Fokusindikator:<\/strong> Viele Designs unterdr\u00fccken den Standard-Fokusrahmen des Browsers aus \u00e4sthetischen Gr\u00fcnden, ohne einen alternativen Indikator bereitzustellen.<\/li>\n
- Nicht semantisch ausgezeichnete Navigation:<\/strong> Navigationsbereiche, die lediglich als
<div><\/code> oder <ul><\/code> ohne <nav><\/code>-Wrapper umgesetzt sind, k\u00f6nnen von Screenreadern nicht als Navigation identifiziert werden.<\/li>\n- Inkonsistente Navigation:<\/strong> Wenn Navigationselemente auf verschiedenen Unterseiten in unterschiedlicher Reihenfolge erscheinen, verlieren Nutzerinnen und Nutzer die Orientierung.<\/li>\n
- Unzureichende Farbkontraste:<\/strong> Navigationstexte oder aktive Zust\u00e4nde, die die Kontrastanforderungen nicht erf\u00fcllen, stellen ebenfalls einen Versto\u00df dar.<\/li>\n<\/ul>\n
Wichtig: Nicht alle dieser Fehler lassen sich automatisiert erkennen. Ob Alternativtexte sinnvoll formuliert sind oder ob die Tastaturbedienung eines komplexen Men\u00fcs tats\u00e4chlich funktioniert, erfordert in vielen F\u00e4llen eine manuelle Pr\u00fcfung erg\u00e4nzend zum automatisierten Scan.<\/p>\n
Wie l\u00e4sst sich barrierefreie Navigation testen?<\/h2>\n
Das Testen barrierefreier Navigation erfordert eine Kombination aus automatisierten Tools und manuellen Pr\u00fcfschritten. Automatisierte Tests k\u00f6nnen technische Fehler wie fehlende ARIA-Attribute, Kontrastprobleme und fehlende semantische Auszeichnung zuverl\u00e4ssig erkennen. Manuelle Tests sind zus\u00e4tzlich notwendig, um zu pr\u00fcfen, ob die Navigation auch in der Praxis f\u00fcr alle Nutzerinnen und Nutzer funktioniert.<\/p>\n
Automatisiertes Testen der Navigation<\/h3>\n
Automatisierte Barrierefreiheitstools pr\u00fcfen den HTML-Code jeder Seite auf Konformit\u00e4t mit den WCAG-Regeln. Sch\u00e4tzungen gehen davon aus, dass automatisierte Tests etwa 30 bis 50 Prozent aller Barrierefreiheitsprobleme aufdecken k\u00f6nnen. F\u00fcr die Navigation bedeutet das: Fehlende <nav><\/code>-Elemente, unzureichende Farbkontraste, fehlende ARIA-Attribute und inkorrekte Fokus-Reihenfolgen im Quellcode lassen sich automatisiert identifizieren. Tools, die auf der Open-Source-Bibliothek axe-core basieren, haben sich dabei als besonders verl\u00e4sslich erwiesen, da sie nach aktuellen WCAG-Standards pr\u00fcfen.<\/p>\nManuelles Testen der Navigation<\/h3>\n
Manuelle Tests sind unersetzlich, um zu pr\u00fcfen, ob die Navigation tats\u00e4chlich vollst\u00e4ndig per Tastatur bedienbar ist und ob Screenreader die Struktur korrekt vorlesen. Die Web Accessibility Initiative (WAI) stellt dazu eine Checkliste f\u00fcr einen manuellen Schnelltest bereit. Praktisch bedeutet das: Navigieren Sie ausschlie\u00dflich mit der Tabulatortaste durch die gesamte Website und pr\u00fcfen Sie, ob alle Men\u00fcpunkte erreichbar sind, ob der Fokus sichtbar bleibt und ob Dropdown-Men\u00fcs korrekt ge\u00f6ffnet und geschlossen werden k\u00f6nnen. Ein Screenreader-Test mit g\u00e4ngigen Tools wie NVDA oder VoiceOver gibt zus\u00e4tzlich Aufschluss dar\u00fcber, wie die Navigation f\u00fcr seheingeschr\u00e4nkte Nutzerinnen und Nutzer erlebbar ist.<\/p>\n
Ein guter Risiko-Score im automatisierten Test ist eine notwendige, aber keine hinreichende Bedingung f\u00fcr Barrierefreiheit. Erst die Kombination beider Testmethoden liefert ein belastbares Bild des tats\u00e4chlichen Compliance-Stands.<\/p>\n
Wer ist f\u00fcr die barrierefreie Navigation einer Website verantwortlich?<\/h2>\n
Die Verantwortung f\u00fcr eine barrierefreie Navigation liegt beim Betreiber der Website. Das BFSG verpflichtet Unternehmen, die unter seinen Anwendungsbereich fallen, dazu, ihre digitalen Angebote barrierefrei zu gestalten und eine Barrierefreiheitserkl\u00e4rung zu ver\u00f6ffentlichen. In der Praxis teilt sich die operative Verantwortung typischerweise auf mehrere Beteiligte auf.<\/p>\n
In der Umsetzung sind folgende Rollen relevant:<\/p>\n
\n- Website-Betreiber:<\/strong> Tr\u00e4gt die rechtliche Verantwortung und ist gegen\u00fcber Beh\u00f6rden und Nutzenden rechenschaftspflichtig. Sie m\u00fcssen sicherstellen, dass Barrierefreiheit bei Neuentwicklungen und \u00dcberarbeitungen ber\u00fccksichtigt wird.<\/li>\n
- Webagenturen und Entwicklerinnen und Entwickler:<\/strong> Sind f\u00fcr die technisch korrekte Umsetzung zust\u00e4ndig. Fehler in der semantischen Auszeichnung, bei ARIA-Attributen oder der Tastaturbedienbarkeit entstehen in der Regel in der Entwicklungsphase.<\/li>\n
- Content-Verantwortliche:<\/strong> Auch redaktionelle Entscheidungen beeinflussen die Barrierefreiheit der Navigation, etwa die Benennung von Men\u00fcpunkten oder die Struktur von Unterseiten.<\/li>\n
- Datenschutz- und Compliance-Beauftragte:<\/strong> Unterst\u00fctzen dabei, den Compliance-Status zu dokumentieren, Risiken zu identifizieren und die Barrierefreiheitserkl\u00e4rung korrekt zu erstellen und aktuell zu halten.<\/li>\n<\/ul>\n