WCAG 2.4.5: Mehrere Wege

WCAG 2.4.5 verlangt, dass Websites mehr als eine Möglichkeit bieten, damit Nutzerinnen und Nutzer eine beliebige Seite innerhalb einer Gruppe von Webseiten finden können – zum Beispiel über eine Seitensuche, eine Sitemap oder ein Navigationsmenü. Dies stellt sicher, dass Menschen mit unterschiedlichen Fähigkeiten und Vorlieben Inhalte auf die Weise finden können, die für sie am besten funktioniert.

Was diese Regel bedeutet

WCAG 2.4.5 — Multiple Ways ist ein Erfolgskriterium der Stufe AA unter dem Prinzip „Bedienbar“. Es verlangt, dass jede Webseite, die Teil einer größeren Menge von Webseiten ist, über mindestens zwei unterschiedliche Navigationsmechanismen erreichbar sein muss. Anders ausgedrückt: Ein Nutzer sollte niemals gezwungen sein, sich ausschließlich auf einen einzigen Weg zu verlassen, um eine Seite zu finden.

Übliche Navigationsmechanismen, die dieses Kriterium erfüllen, sind: eine seitenübergreifende Suchfunktion, eine Sitemap (entweder als eigenständige Seite oder als Inline-Struktur), ein Inhaltsverzeichnis, ein konsistentes Navigationsmenü oder eine Seitenleiste, Breadcrumb-Navigation und Links zwischen verwandten Seiten. Beliebige zwei dieser — oder andere gleichwertige Mechanismen —, die gemeinsam verwendet werden, erfüllen die Anforderung.

Das Kriterium gilt speziell für Mengen von Webseiten. Eine eigenständige Webseite, die nicht zu einer größeren Website oder Anwendung gehört, ist ausgenommen. Zusätzlich sind Seiten, die das Ergebnis eines Prozesses oder ein Schritt in einem Prozess sind — etwa eine Bestellbestätigungsseite, eine Erfolgsseite nach dem Absenden eines Formulars oder ein Schritt in einem Assistenten — ebenfalls ausdrücklich ausgenommen. Der Grund ist, dass solche Seiten inhärent sequenziell sind und es unangebracht oder schädlich wäre, einen direkten Zugriff auf sie außerhalb der Reihenfolge zu ermöglichen.

Ein Bestehen erfordert, dass mindestens zwei unabhängige Navigationsmechanismen vorhanden, funktionsfähig und auf der gesamten Website zugänglich sind. Ein Nichtbestehen liegt vor, wenn nur ein Mechanismus existiert — zum Beispiel eine Website, die nur ein oberes Navigationsmenü bereitstellt, ohne Suche, ohne Sitemap und ohne andere Navigationshilfe. Es liegt ebenfalls ein Nichtbestehen vor, wenn der sekundäre Mechanismus nicht funktionsfähig oder unzugänglich ist (z. B. ein Suchfeld, das keine Ergebnisse liefert, oder eine Sitemap, die vor unterstützenden Technologien verborgen ist).

Wichtig ist, dass dieses Kriterium keine bestimmte Kombination von Mechanismen vorschreibt. Die Flexibilität ist beabsichtigt: Unterschiedliche Nutzer haben grundlegend unterschiedliche Strategien, um Inhalte zu finden, und der Standard erkennt diese Vielfalt an, indem er Redundanz verlangt, statt eine bestimmte Lösung vorzuschreiben.

Warum es wichtig ist

Navigation ist die Grundlage jeder Web-Erfahrung, und Barrieren bei der Navigation betreffen Menschen mit Behinderungen überproportional stark. Wenn nur ein einziger Navigationspfad existiert, sind Nutzer, die diesen Pfad nicht verwenden können, faktisch von Inhalten ausgeschlossen.

Für Nutzer mit motorischen Beeinträchtigungen — einschließlich derjenigen, die Schaltersteuerung, Blickverfolgungsgeräte, Spracherkennungssoftware oder ausschließlich die Tastatur zur Navigation verwenden — können komplexe hierarchische Menüs ermüdend oder unmöglich sein, effizient zu durchlaufen. Eine Seitensuche ermöglicht es ihnen, direkt zu Inhalten zu springen, ohne mehrere Menüebenen durchlaufen zu müssen. Umgekehrt können Nutzer mit bestimmten kognitiven oder Gedächtnisbeeinträchtigungen offene Suchfelder verwirrend oder schwer effektiv nutzbar finden; für sie ist eine klar strukturierte Sitemap oder ein durchstöberbarer Kategorienbaum deutlich hilfreicher.

Für blinde Nutzer, die auf Screenreader angewiesen sind, kann ein dichtes Navigationsmenü bei jedem Seitenaufruf zu einem wiederkehrenden Hindernis werden, selbst mit Sprunglinks. Eine Sitemap oder eine Suchabkürzung reduziert diese kognitive und physische Belastung erheblich. Für Nutzer mit Sehbehinderungen, die Bildschirmlupen verwenden, sind umfangreiche Navigationsmenüs bei hohen Zoomstufen möglicherweise nur teilweise sichtbar, sodass eine textbasierte Suche oder Sitemap eine entscheidende Rückfalloption darstellt.

Für Nutzer mit kognitiven Beeinträchtigungen wie Dyslexie oder Aufmerksamkeitsstörungen kann die Möglichkeit, mit ungefähren oder unvollständigen Begriffen zu suchen — statt sich die genaue Menü-Hierarchie merken oder wiedererkennen zu müssen — den Unterschied ausmachen zwischen dem eigenständigen Auffinden von Inhalten und dem vollständigen Aufgeben.

Ein konkretes Szenario aus der Praxis: Stellen Sie sich einen Nutzer mit rheumatoider Arthritis vor, der eine türkische E‑Commerce-Plattform ausschließlich mit der Tastatur besucht. Das Mega-Menü der Website erfordert präzise Maus-Hover-Interaktionen, um Unterkategorien anzuzeigen, und das Fokusverhalten bei Tastaturnutzung ist unzuverlässig. Wenn die Website zusätzlich eine Suchleiste und eine Sitemap bereitstellt, kann dieser Nutzer die benötigte Produktseite dennoch finden. Ohne diese Alternativen ist die Website für ihn faktisch unbenutzbar — und das bedeutet einen verlorenen Kunden und ein potenzielles rechtliches Risiko.

Über die Barrierefreiheit hinaus bieten mehrere Navigationsmechanismen messbare SEO- und Usability-Vorteile. Sitemaps verbessern die Crawlability durch Suchmaschinen-Bots. Eine Seitensuche erhöht die Nutzerbindung und reduziert Absprungraten. Breadcrumb-Navigation verbessert die Klickraten in Suchergebnisseiten, wenn sie mit strukturierten Daten implementiert wird. Diese Vorteile bedeuten, dass die Erfüllung von 2.4.5 nicht nur eine Compliance-Übung ist — sie ist eine solide Praxis des Webdesigns.

Wie man testet

Automatischer Scan — Basislinie festlegen: Führen Sie axe DevTools oder Lighthouse auf repräsentativen Seiten der Website aus. Auch wenn keines der Tools Verstöße gegen 2.4.5 direkt markiert, nutzen Sie das Audit, um Navigationskomponenten (Menüs, Suchfelder, Breadcrumbs) mit zugrunde liegenden Barrierefreiheitsproblemen wie fehlenden Labels, falschen ARIA-Rollen oder Fokus-Management-Problemen zu identifizieren. Beheben Sie diese zuerst, da ein defekter Navigationsmechanismus nicht als gültiger „Weg“ im Sinne von 2.4.5 zählen kann.
Navigationsmechanismen katalogisieren: Prüfen Sie die Website manuell und listen Sie jeden unterschiedlichen Mechanismus auf, den ein Nutzer verwenden könnte, um eine bestimmte Seite zu erreichen: obere Navigationsmenüs, Footer-Links, Seitensuche, Sitemap-Seiten, Breadcrumbs, Links zu verwandten Inhalten, Kategorieindizes usw. Bestätigen Sie, dass mindestens zwei dieser Mechanismen auf jeder Seite vorhanden, funktionsfähig und verfügbar sind, die nicht Teil eines sequentiellen Prozesses ist.
Test mit reiner Tastaturnavigation: Verwenden Sie ausschließlich Tab, Enter, Pfeiltasten und Escape (keine Maus), um zu versuchen, eine bestimmte Nicht-Startseite über zwei verschiedene Mechanismen zu erreichen. Nutzen Sie beispielsweise die Suchleiste, um eine Produktseite zu finden, und verwenden Sie dann die Sitemap oder das Navigationsmenü, um dieselbe Seite zu erreichen. Bestätigen Sie, dass beide Wege vollständig ohne Maus bedienbar sind.
Screenreader-Test mit NVDA + Firefox: Starten Sie NVDA, öffnen Sie Firefox und navigieren Sie zur Startseite. Verwenden Sie den NVDA-Browsingmodus (F6 für Landmarken, H für Überschriften), um den Such-Landmark und etwaige Sitemap- oder Navigationslinks zu finden. Bestätigen Sie, dass beide Mechanismen korrekt angekündigt werden, dass Formularfelder zugängliche Labels haben und dass Ergebnisse oder Zielseiten geladen und lesbar sind.
Screenreader-Test mit VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver (Cmd+F5) und verwenden Sie den Rotor (VO+U), um die Formularsteuerelemente und Links der Seite zu prüfen. Bestätigen Sie, dass das Suchfeld aufgeführt und beschriftet ist und dass Navigationslinks, die zu einer Sitemap oder einem alternativen Index führen, vorhanden und bedienbar sind.
Screenreader-Test mit JAWS + Chrome: Verwenden Sie JAWS-Navigationstasten (F zum Springen zu Formularen, Einfügen+F7 für die Linkliste), um zu überprüfen, dass das Suchfeld und etwaige Sitemap-Links sowohl über die Tastatur als auch über den virtuellen Cursor auffindbar und nutzbar sind.
Prüfung der Ausnahme für sequentielle Prozesse: Identifizieren Sie alle Seiten, die Schritte in einem Prozess sind (Checkout, mehrstufige Formulare, Login-Flows). Bestätigen Sie, dass diese Seiten die Anforderung „Multiple Ways“ nicht erfüllen müssen. Dokumentieren Sie dies in Ihrem Barrierefreiheitsaudit, um falsche Fehler zu vermeiden.
Überprüfung funktionaler Suchergebnisse: Führen Sie mehrere repräsentative Suchanfragen durch (Produktnamen, Artikeltitel, Support-Themen). Bestätigen Sie, dass Ergebnisse erscheinen, relevant sind und dass die Ergebnisseite per Tastatur und Screenreader zugänglich und navigierbar ist.

Wie man es behebt

Fehlende Seitensuche — Falsch

<!-- Site only has a navigation menu; no search or sitemap provided -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>
<!-- No search, no sitemap link, no other navigation mechanism -->

Fehlende Seitensuche — Richtig

<!-- Navigation menu retained, and a site search is added as a second mechanism -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>

<!-- Second navigation mechanism: accessible site search -->
<form role='search' action='/arama' method='get'>
  <label for='site-search'>Sitede Ara</label>
  <input
    type='search'
    id='site-search'
    name='q'
    placeholder='Ürün veya konu arayın...'
    aria-label='Site genelinde arama'
  />
  <button type='submit'>Ara</button>
</form>

Unzugängliche Sitemap — Falsch

<!-- Sitemap link is present but visually hidden and unreachable by keyboard -->
<footer>
  <a href='/site-haritasi' style='display:none;'>Site Haritası</a>
</footer>
<!-- display:none removes the element from both visual display AND
     the accessibility tree, so screen reader users cannot reach it.
     This sitemap cannot count as a valid second navigation mechanism. -->

Unzugängliche Sitemap — Richtig

<!-- Sitemap link is visible and accessible to all users -->
<footer>
  <nav aria-label='Footer navigation'>
    <ul>
      <li><a href='/site-haritasi'>Site Haritası</a></li>
      <li><a href='/gizlilik'>Gizlilik Politikası</a></li>
      <li><a href='/iletisim'>İletişim</a></li>
    </ul>
  </nav>
</footer>
<!-- The sitemap page itself should list all major sections and pages
     of the site using <nav>, <ul>, and <a> elements. -->

Suchformular ohne zugängliches Label — Falsch

<!-- Search input has no label; screen readers announce only 'edit text' -->
<form action='/search'>
  <input type='text' name='q' placeholder='Search...' />
  <button type='submit'><img src='search-icon.png' /></button>
</form>

Suchformular ohne zugängliches Label — Richtig

<!-- role='search' identifies the landmark; label associates text with input;
     submit button has an accessible name via aria-label -->
<form role='search' action='/arama' method='get'>
  <label for='global-search'>Arama</label>
  <input
    type='search'
    id='global-search'
    name='q'
    autocomplete='off'
  />
  <button type='submit' aria-label='Aramayı başlat'>
    <img src='search-icon.png' alt='' aria-hidden='true' />
  </button>
</form>

Häufige Fehler

Ein XML-Sitemap als benutzerorientierten Navigationsmechanismus zählen: Ein XML-Sitemap, das bei Suchmaschinen eingereicht wird (z. B. /sitemap.xml), ist eine maschinenlesbare Datei und kann von normalen Besuchern nicht genutzt werden. Nur eine HTML-Sitemap-Seite, die von Menschen durchstöbert werden kann, zählt als gültiger zweiter Navigationsmechanismus.
Bereitstellung eines Suchformulars, das rein dekorativ oder defekt ist: Ein Suchfeld, das immer leere Ergebnisse zurückgibt, beim Absenden Fehler erzeugt oder auf eine 404-Seite weiterleitet, erfüllt 2.4.5 nicht. Der Mechanismus muss tatsächlich funktionsfähig sein, damit das Kriterium erfüllt ist.
Verstecken des Sitemap-Links hinter JavaScript, das fehlschlägt oder deaktiviert ist: Wenn der einzige Link zu einer Sitemap in einem dynamisch eingeblendeten Modal oder einem JavaScript-abhängigen Dropdown liegt, das in bestimmten Umgebungen fehlschlägt, verlieren Nutzer, die dieses JavaScript nicht ausführen können (einschließlich einiger Konfigurationen unterstützender Technologien), den Zugriff auf diesen Navigationsmechanismus.
Anwenden von display:none oder visibility:hidden auf einen Navigationsmechanismus in mobilen Viewports: Das vollständige Ausblenden einer Suchleiste oder eines Sitemap-Links im mobilen Layout entfernt diesen Mechanismus für mobile Nutzer vollständig, was ein Nichtbestehen darstellt — selbst wenn das Desktop-Layout besteht. Das Einklappen des Mechanismus hinter eine zugängliche Umschalttaste ist akzeptabel; das Entfernen aus dem DOM oder dem Accessibility Tree ist es nicht.
Breadcrumbs als eigenständigen zweiten Mechanismus ohne zusätzliche Unterstützung behandeln: Breadcrumbs zeigen nur den Pfad zur aktuellen Seite und sind für sich allein nicht ausreichend, um einem Nutzer zu helfen, beliebige Seiten einer Website zu entdecken und zu navigieren. Sie können andere Mechanismen ergänzen, können aber typischerweise nicht allein als einer der zwei erforderlichen Mechanismen dienen.
Seiten fälschlicherweise von der Anforderung ausnehmen: Die Ausnahme für sequentielle Prozesse gilt nur für Seiten, die tatsächlich Schritte innerhalb eines Prozesses sind (z. B. Schritt 2 von 4 im Checkout). Kategorieseiten, Produktdetailseiten und Blogbeiträge sind nicht ausgenommen, selbst wenn der Nutzer über einen Funnel dorthin gelangt ist.
Verwendung eines Suchfelds mit type='text' statt type='search' und Weglassen von role='search' im Formular: Auch wenn dies keinen direkten Verstoß gegen 2.4.5 darstellt, bedeutet es, dass Screenreader-Nutzer, die nach Landmarken browsen, den Suchbereich nicht finden können. Der Mechanismus existiert technisch, ist aber praktisch schwerer zu entdecken, was der Intention des Kriteriums zuwiderläuft.
Bereitstellung zweier Mechanismen, die faktisch identisch sind: Ein oberes Navigationsmenü und ein Footer-Navigationsmenü, die exakt dieselben Links in exakt derselben Struktur enthalten, stellen keine zwei sinnvoll unterschiedlichen Navigationsmechanismen dar. Die Intention ist, dass Nutzer mit unterschiedlichen Bedürfnissen alternative Strategien finden können — nicht, dass dieselbe Strategie zweimal auf der Seite erscheint.
Bestimmte Seitentypen aus dem Navigationssystem ausschließen: Einige CMS-Konfigurationen platzieren Blogbeiträge, Rechtsseiten oder Benutzerkontoseiten außerhalb der Haupt-Sitemap oder des Suchindex. Wenn Nutzer diese Seiten nicht über mindestens zwei Mechanismen finden können, verstoßen diese Seiten gegen 2.4.5, unabhängig davon, wie gut der Rest der Website strukturiert ist.
Versäumnis, die Mechanismen mit unterstützender Technologie zu testen: Da 2.4.5 manuelle Tests erfordert, werden Teams, die sich ausschließlich auf automatisierte Tools verlassen, Fehler übersehen, die durch Tastaturfallen in Suchformularen, unbeschriftete Eingabefelder oder Sitemaps verursacht werden, die zwar im DOM vorhanden, aber über die Landmark-Navigation des Screenreaders nicht erreichbar sind.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung Nr. 2025/10 der Türkei, veröffentlicht im Amtsblatt (Resmî Gazete) Nr. 32933 am 21. Juni 2025, legt verbindliche Web-Barrierefreiheitsverpflichtungen für eine breite Palette öffentlicher und privater Einrichtungen fest. Die Verfügung schreibt die Einhaltung international anerkannter Barrierefreiheitsstandards vor und bringt die türkischen gesetzlichen Anforderungen mit WCAG 2.1 und WCAG 2.2 Stufe AA als Basiserwartung in Einklang.

WCAG 2.4.5 — Multiple Ways ist ein Kriterium der Stufe AA, was bedeutet, dass es genau in den Konformitätsgrad fällt, der durch die Verfügung gefordert wird. Einrichtungen, die der Regulierung unterliegen, müssen sicherstellen, dass alle Webseiten, die zu einer Menge gehören, mindestens zwei Navigationsmechanismen bereitstellen, wie in diesem Kriterium beschrieben. Die Nichterfüllung dieser Anforderung stellt eine direkte Nichtkonformität mit der regulatorischen Vorgabe dar.

Zu den von der Präsidialverfügung 2025/10 erfassten Einrichtungen gehören: öffentliche Institutionen und Regierungsstellen auf allen Ebenen; Banken und Finanzinstitute; Krankenhäuser und Gesundheitsdienstleister; elektronische Handelsplattformen; Telekommunikationsanbieter mit 200.000 oder mehr Abonnenten; Reisebüros; private Transportunternehmen; und Privatschulen, die unter der Genehmigung des Ministeriums für Nationale Bildung (Millî Eğitim Bakanlığı, MEB) betrieben werden. Von jeder dieser Einrichtungsarten wird erwartet, dass sie über ihre Webangebote hinweg eine zugängliche Navigation mit mehreren Pfaden aufrechterhält.

Zusätzlich zu den verbindlichen Konformitätsanforderungen vergibt das Ministerium für Familie und Sozialdienste (Aile ve Sosyal Hizmetler Bakanlığı) das Erişilebilirlik Logosu (Barrierefreiheitslogo) an Organisationen, die starke Barrierefreiheitspraktiken nachweisen. Der Erhalt dieses Logos erfordert vollständige Konformität mit Stufe AA, einschließlich der Einhaltung von 2.4.5. Für Unternehmen, die auf dem wettbewerbsintensiven digitalen Markt der Türkei tätig sind — insbesondere E‑Commerce-Plattformen, Banken und Gesundheitsdienstleister — dient das Barrierefreiheitslogo sowohl als Vertrauenssignal für Nutzer mit Behinderungen als auch als Nachweis regulatorischer Redlichkeit.

Praktisch gesehen profitieren türkische Websites, die vielfältige Nutzergruppen bedienen, erheblich von der Implementierung mehrerer Navigationsmechanismen. Die Türkei hat eine große Zahl älterer Internetnutzer und Nutzer in Regionen mit geringerer digitaler Kompetenz, die beide von der Redundanz profitieren, die 2.4.5 vorschreibt. Eine Seitensuche mit Türkisch-Unterstützung (einschließlich korrekter Behandlung türkischer Sonderzeichen wie ı, İ, ş, ğ, ü, ö, ç) in Kombination mit einer klar strukturierten HTML-Sitemap stellt eine zugängliche, vorschriftenkonforme Implementierung dar, die diese Zielgruppe gut bedient. Organisationen, die das Erişilebilirlik Logosu erhalten oder behalten möchten, sollten die Einhaltung von 2.4.5 nicht als optionale Verbesserung, sondern als grundlegende Anforderung ihres Barrierefreiheitsprogramms betrachten.