Komponenten · Navigation & Bedienelemente

Breadcrumbs barrierefrei aufbauen

Eine barrierefreie Brotkrumen-Navigation besteht aus einem benannten <nav> mit einer geordneten Liste darin, deren letztes Element die aktuelle Seite als Text mit aria-current="page" trägt – ohne Link. Die Trennzeichen zwischen den Krumen gehören ins CSS, weil sie sonst mitgelesen werden.

Breadcrumbs sind das kleinste Navigationsmuster mit dem besten Verhältnis von Aufwand zu Wirkung: ein nav, eine Liste, ein Attribut. Genau deshalb ist es ärgerlich, wie oft sie falsch gebaut werden – meist an denselben zwei Stellen, dem Listentyp und dem letzten Eintrag. Diese Seite zeigt beide Fälle im Vergleich, samt der Ansage, die dabei herauskommt.

Das Wichtigste in Kürze

  • Eine Brotkrume ist eine geordnete Liste (<ol>), weil die Reihenfolge die Hierarchie abbildet. Ein <ul> behauptet, die Position sei beliebig.
  • Das umgebende <nav> braucht einen eigenen Namen per aria-label – etwa „Sie sind hier“ oder „Brotkrümelnavigation“. Ohne ihn sind mehrere Navigationsbereiche in der Landmark-Liste nicht auseinanderzuhalten.
  • Die letzte Krume ist die aktuelle Seite: kein Link, sondern Text mit aria-current="page". Screenreader ergänzen dann „aktuelle Seite“.
  • Trennzeichen kommen aus dem CSS (li:not(:last-child)::after). Als Textzeichen im Markup werden sie vorgelesen – „Start Schrägstrich Komponenten Schrägstrich …“.
  • Breadcrumbs sind kein Ersatz für WCAG 2.4.5, sondern eine von mehreren Methoden, eine Seite zu finden. Sie zählen dort als eine der geforderten Wege.
  • Ein BreadcrumbList-JSON-LD aus derselben Datenquelle liefert Google den Pfad für die Anzeige im Suchergebnis. Stand Juli 2026 zeigt Google dort häufig den Breadcrumb-Pfad statt der URL – ohne Garantie, denn die Darstellung entscheidet Google.
  • Auf einer flachen Website ohne Unterebenen bringt die Brotkrume nichts. Sie lohnt sich ab drei Ebenen – und je tiefer die Struktur, desto mehr.

Das semantische Grundgerüst

Zwei Entscheidungen tragen die ganze Komponente: welches Listenelement, und was mit dem letzten Eintrag passiert.

<nav aria-label="Sie sind hier">
  <ol class="breadcrumbs">
    <li><a href="/index.html">Start</a></li>
    <li><a href="/barrierefreie-komponenten.html">Barrierefreie Komponenten</a></li>
    <li><span aria-current="page">Breadcrumbs</span></li>
  </ol>
</nav>

Das <ol> sorgt dafür, dass ein Screenreader beim Betreten „Liste mit 3 Einträgen“ ansagt und jeden Eintrag mit seiner Position nennt – „2 von 3“. Diese Positionsangabe ist die eigentliche Orientierungsleistung der Brotkrume, und sie entsteht allein aus dem richtigen Element. Wer stattdessen ein <ul> nimmt, verschenkt sie: Die Liste ist dann zwar da, ihre Reihenfolge aber nicht als Bedeutung markiert. Mehr dazu unter Listen richtig nutzen.

aria-current="page" ist das einzige ARIA-Attribut, das diese Komponente braucht. Es kennzeichnet innerhalb einer Menge von Verweisen genau den einen, der auf die gerade geöffnete Seite zeigt – und wird als „aktuelle Seite“ hinter dem Text ausgegeben. Das Attribut funktioniert auch an einem <span>; es setzt keinen Link voraus.

Zwei Umsetzungen derselben Brotkrume nebeneinander. Links, rot markiert als „So besser nicht“, eine Leiste mit den Links Start, Barrierefreie Komponenten und Breadcrumbs, zwischen denen Schrägstriche als Textzeichen stehen; die NVDA-Ausgabe darunter lautet „Link Start Schrägstrich Link Barrierefreie Komponenten Schrägstrich Link Breadcrumbs“, wobei die beiden Wörter Schrägstrich durchgestrichen markiert sind. Drei Mängel sind aufgelistet: Trennzeichen werden mitgelesen, die aktuelle Seite ist ein Link auf sich selbst, kein ol-Element. Rechts, grün markiert als „So geht es“, dieselbe Leiste mit Chevron-Trennern aus dem CSS und der letzten Krume in Fettschrift ohne Link; die NVDA-Ausgabe lautet „Sie sind hier, Navigationsbereich, Liste mit 3 Einträgen, 1 von 3 Link Start, 2 von 3 Link Barrierefreie Komponenten, 3 von 3 Breadcrumbs aktuelle Seite“. Drei Vorteile sind aufgelistet: Position und Gesamtzahl kommen aus dem ol, „aktuelle Seite“ ist eine Ansage statt einer Farbe, das aria-label benennt die Navigation.
Optisch fast derselbe Pfad – aber links stehen zwei Füllwörter im Vorlesetext, und die Position fehlt komplett.

Trenner gehören ins CSS

Die Schrägstriche, Chevrons oder Pfeile zwischen den Krumen sind Dekoration. Stehen sie als Zeichen im Markup, landen sie im Accessibility Tree und werden Teil des Vorlesetextes. Bei drei Ebenen sind das zwei zusätzliche Wörter, bei einem Shop mit sechs Ebenen fünf – jedes Mal, wenn jemand die Navigation überfliegt.

.breadcrumbs {
  display: flex;
  flex-wrap: wrap;
  list-style: none;
  margin: 0;
  padding: 0;
}

.breadcrumbs li:not(:last-child)::after {
  content: '›';
  padding-inline: 0.4em;
  color: #4a4d57;
}

Generierter Inhalt aus ::after wird von aktuellen Screenreadern zwar teilweise mitgelesen – der entscheidende Unterschied ist ein anderer: Ein Zeichen wie hat keinen Wortlaut, der die Ansage verlängert, und wer es sauber halten will, nimmt statt eines Textzeichens ein Hintergrundbild oder ein aria-hidden-Element. Falls der Trenner aus Layoutgründen im HTML stehen muss, dann so:

<li>
  <a href="/barrierefreie-komponenten.html">Barrierefreie Komponenten</a>
  <span aria-hidden="true">›</span>
</li>

Der CSS-Weg ist trotzdem der bessere, weil er die Dekoration dort hält, wo sie hingehört. Genau so macht es diese Website auch.

Hier gehen die Meinungen auseinander, und beide Varianten sind WCAG-konform. Ich würd sie nicht verlinken: Ein Link, der auf die Seite zeigt, auf der man schon steht, ist ein Versprechen ohne Inhalt. Wer per Tastatur navigiert, bekommt einen zusätzlichen Tabstop ohne Nutzen; wer per Screenreader die Linkliste aufruft, findet einen Eintrag, der nirgendwohin führt.

Wenn die letzte Krume aus Gründen der Konsistenz ein <a> bleiben soll, dann mit aria-current="page" am Link selbst. Was auf keinen Fall passieren darf: die aktuelle Seite nur farblich hervorheben. Das ist Information allein über Farbe und scheitert an 1.4.1 genauso wie an 1.3.1.

Wo die Brotkrume auf der Seite steht

Die verbreitete Platzierung ist zwischen Kopfbereich und <h1>, und dabei kann man bleiben. Wichtig ist die Reihenfolge im DOM: Die Brotkrume steht vor der Überschrift, nicht danach. Sonst liest ein Screenreader zuerst das Thema und dann den Weg dorthin – was die Orientierung nicht verbessert.

Für Menschen mit starker Bildschirmvergrößerung ist die Position noch wichtiger als für andere: Bei 400 Prozent Zoom ist der sichtbare Ausschnitt so klein, dass alles, was nicht oben links steht, gesucht werden muss. Eine Brotkrume weit unten im Layout wird dort nie gefunden.

Die Brotkrume gehört außerdem in denselben <header>- oder <main>-Bereich wie auf allen anderen Seiten. 3.2.3 Konsistente Navigation verlangt, dass wiederkehrende Navigationsmechanismen in derselben relativen Reihenfolge auftauchen – eine Brotkrume, die auf halber Strecke die Seite wechselt, verstößt dagegen.

Strukturierte Daten aus derselben Quelle

Breadcrumbs sind eine der dankbarsten Stellen für strukturierte Daten, weil die Daten schon da sind. Mit BreadcrumbList nach Schema.org versteht eine Suchmaschine die Hierarchie und zeigt den Pfad statt der nackten URL an:

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "Start", "item": "https://example.de/" },
      {
        "@type": "ListItem",
        "position": 2,
        "name": "Barrierefreie Komponenten",
        "item": "https://example.de/barrierefreie-komponenten.html"
      },
      { "@type": "ListItem", "position": 3, "name": "Breadcrumbs" }
    ]
  }
</script>

Zwei Details, die regelmäßig übersehen werden: Der letzte Eintrag braucht kein item – er ist die aktuelle Seite, und Google erlaubt das Weglassen ausdrücklich. Und position gibt die Reihenfolge im Pfad an: bei 1 beginnen, lückenlos aufsteigen. Springende oder doppelte Positionen sind der häufigste Grund, warum eine Brotkrume in der Search Console als fehlerhaft gemeldet wird.

Auf dieser Website wird genau dieses JSON-LD automatisch aus derselben Datenquelle erzeugt, die auch die sichtbare Brotkrume speist. Das ist keine Bequemlichkeit, sondern eine Vorsichtsmaßnahme: Zwei getrennt gepflegte Pfade laufen garantiert irgendwann auseinander, und dann widerspricht die Auszeichnung dem, was auf der Seite steht. Wie strukturierte Daten generell funktionieren, vertieft Strukturierte Daten.

Sonderfälle: lange Pfade, Filter, mehrere Wege

Drei Situationen, in denen das einfache Muster nicht mehr reicht:

Sehr tiefe Hierarchien. Ab etwa fünf Ebenen wird die Zeile zu lang für schmale Viewports. Kürzen ist erlaubt – aber nicht durch Weglassen mittlerer Ebenen, sondern durch Zusammenfassen mit einem Bedienelement, das den vollen Pfad aufklappt. Das ist dann ein Disclosure und braucht aria-expanded.

Produkte in mehreren Kategorien. Ein Artikel, der unter drei Kategorien liegt, hat keinen eindeutigen Pfad. Zeig den, über den der Besucher gekommen ist, und halte das JSON-LD identisch dazu. Mehrere BreadcrumbList-Objekte auf einer Seite sind laut Google erlaubt, in der Anzeige aber selten hilfreich.

Filter- und Suchergebnisse. Hier ist die Brotkrume keine Hierarchie, sondern eine Zustandsanzeige („Damen › Schuhe › Größe 39“). Das ist ein anderes Muster: Filter gehören als entfernbare Chips ausgezeichnet, nicht als Pfad – und ihre Änderung braucht eine Statusmeldung.

Häufige Fehler

  • <ul> statt <ol>. Die Reihenfolge ist die Information, also gehört sie in eine geordnete Liste.
  • Aktuelle Seite verlinkt und ohne aria-current. Ein Tabstop ohne Ziel, und der Screenreader sagt nicht, wo man ist.
  • Trenner als Textzeichen. Werden mitgelesen und verlängern jede Ansage.
  • <nav> ohne aria-label. Bei mehreren Navigationsbereichen sind sie in der Landmark-Übersicht nicht unterscheidbar.
  • Aktuelle Position nur über Fettschrift oder Farbe. Reine Optik, programmatisch nicht vorhanden.
  • Sichtbare Brotkrume und JSON-LD aus verschiedenen Quellen. Widersprechen sich spätestens beim nächsten Umbau.
  • Brotkrume nach der <h1> im DOM. Der Weg kommt vor dem Ziel, nicht danach.

Häufige Fragen

Braucht jede Seite Breadcrumbs?

Nur, wenn es eine Hierarchie zum Abbilden gibt. Auf einer flachen Website mit fünf Seiten bringen sie nichts. Bei verschachtelten Strukturen – Themenbereiche, Kategorien, Shops – sind sie eine der wirksamsten Orientierungshilfen überhaupt, und für tiefe Strukturen zählen sie als eine der von WCAG 2.4.5 geforderten Methoden, eine Seite zu finden.

Ist aria-label="Breadcrumb" besser als eine deutsche Beschriftung?

Nein, im Gegenteil. Der Name wird vorgelesen und sollte deshalb in der Sprache der Seite stehen, die lang angibt. Ein englisches „Breadcrumb“ in einem deutschen Dokument wird von manchen Stimmen falsch ausgesprochen. „Sie sind hier“ oder „Brotkrümelnavigation“ funktionieren beide.

Soll ich role="navigation" zusätzlich zum <nav> setzen?

Nein. Das <nav>-Element bringt die Rolle mit; die Wiederholung ist redundant und war nur für sehr alte Browser gedacht. Das ist die erste Regel von ARIA in Kurzform: kein ARIA, wo HTML es schon kann.

Ersetzen Breadcrumbs die Hauptnavigation?

Nein, sie ergänzen sie. Die Brotkrume zeigt den Weg von oben bis hierher, die Hauptnavigation erschließt die Breite des Angebots. Wer die eine durch die andere ersetzt, nimmt Besuchern entweder die Übersicht oder die Verortung.

Fazit

Barrierefreie Breadcrumbs sind ein <nav aria-label> mit einer geordneten Liste, deren letzte Krume per aria-current="page" die aktuelle Seite markiert – und deren Trenner aus dem CSS kommen. Das ist alles; ein weiteres ARIA-Attribut braucht die Komponente nicht.

Wer dann noch ein BreadcrumbList-JSON-LD aus derselben Quelle erzeugt, bekommt Orientierung und Suchergebnis-Pfad in einem. Das Nachbarmuster für aufklappbare Pfade und Navigation steht unter Menüs & Dropdowns, die Grundlagen zur Landmark-Struktur unter Struktur-Elemente.

Quellen

Gratis E-Book PDF Das Praxishandbuch

Kostenloses E-Book

Das Praxishandbuch für sauberes, zugängliches Web

Alles rund um semantisches HTML, Barrierefreiheit, WCAG & BFSG, GEO und SEO — praxisnah und am echten Code. In mehreren Feedbackschleifen von Leserinnen und Lesern verbessert.

  • 3.000+ Downloads
  • 7. Auflage
  • 37 Seiten
  • PDF

Kein Spam. Abmeldung jederzeit mit einem Klick möglich.