Semantisches HTML · Grundlagen & Struktur

Landmarks & Dokument-Outline

Landmarks sind die acht ARIA-Rollen banner, navigation, main, complementary, contentinfo, search, form und region, die die großen Bereiche einer Webseite für assistive Technologien markieren – die meisten entstehen automatisch aus semantischen HTML-Elementen wie <header>, <nav> und <main>. Die Dokument-Outline ist die Gliederung aus den Überschriften <h1> bis <h6>; zusammen bilden beide die unsichtbare Bedienoberfläche, über die Screenreader-Nutzende per Tastendruck von Bereich zu Bereich und von Überschrift zu Überschrift springen.

Sehende Nutzende erfassen eine Seite mit einem kurzen Blick: Kopfbereich oben, Navigation, Hauptspalte, Seitenleiste, Fußzeile. Wer nicht sieht, braucht dieselbe Karte in maschinenlesbarer Form – und genau die liefern Landmarks und Outline. In diesem Artikel gehe ich alle acht Landmark-Rollen durch (inklusive der oft vergessenen search und form), erkläre die Scoping-Regel für <header> und <footer>, zeige, wie Screenreader-Nutzende tatsächlich navigieren, und wie du beides mit konkreten Werkzeugen prüfst.

Das Wichtigste in Kürze

  • ARIA kennt genau acht Landmark-Rollen: banner, navigation, main, complementary, contentinfo, search, form und region.
  • Sechs davon entstehen automatisch aus HTML-Elementen – <header>, <nav>, <main>, <aside>, <footer>, <search>. Zusätzliche role-Attribute sind überflüssig.
  • region und form brauchen einen zugänglichen Namen, sonst tauchen sie nicht in der Landmark-Liste auf. Ein <section> ohne aria-label oder aria-labelledby ist generic.
  • Scoping-Regel: <header> und <footer> verlieren ihre Landmark-Rolle, sobald sie in article, aside, main, nav oder section liegen.
  • Bei mehreren gleichartigen Bereichen entscheidet der Name: Ohne aria-label heißen alle „Navigation“.
  • Die Dokument-Outline ist die zweite Navigationsebene – laut HTML-Standard schlicht die Folge aller <h1><h6> in Dokumentreihenfolge, ohne Ableitung aus <section>.
  • Beides zusammen ist die unsichtbare Bedienoberfläche: In NVDA über die Elementliste, in VoiceOver über den Rotor, in JAWS mit R für Regionen und H für Überschriften.
  • WCAG-Bezug: 2.4.1 Blöcke umgehen (Stufe A) verlangt einen Mechanismus zum Überspringen wiederkehrender Blöcke – Landmarks und Überschriften sind zwei davon.

Was sind Landmarks?

Landmarks sind Regionen, die Screenreadern eine grobe Karte der Seite geben. Nutzende können gezielt von Region zu Region springen – etwa direkt zur Navigation oder zum Hauptinhalt. Das Beste daran: Die meisten Landmarks entstehen automatisch aus semantischem HTML, ganz ohne role-Attribute. Insgesamt kennt ARIA genau acht Landmark-Rollen:

Rolle HTML-Element Bedingung
banner <header> nur außerhalb von article, aside, main, nav, section
navigation <nav> immer; bei mehreren: benennen
main <main> immer; nur einmal pro Seite
complementary <aside> immer
contentinfo <footer> nur außerhalb von article, aside, main, nav, section
search <search> immer (früher: role="search")
form <form> nur mit zugänglichem Namen
region <section> nur mit zugänglichem Namen

Genau deshalb plädiere ich dafür, zuerst die nativen Elemente zu setzen und ARIA-role-Attribute nur dort zu ergänzen, wo es keine Entsprechung gibt – das ist im Kern die erste Regel von ARIA. Ein <div role="main"> ist schlicht der Umweg zu dem, was <main> von sich aus mitbringt. Das W3C-WAI-Tutorial zu Page Regions zeigt dieselbe Zuordnung und empfiehlt die reinen role-Attribute nur noch für Altbestände ohne HTML5-Elemente.

Der häufigste Irrtum bei Landmarks: <header> und <footer> erzeugen ihre Rollen banner und contentinfo nicht immer, sondern nur, wenn sie nicht innerhalb von <article>, <aside>, <main>, <nav> oder <section> stecken – praktisch also als direkte Kinder von <body>. Ein <header> in einem <article> ist schlicht der Kopfbereich dieses Artikels, keine Landmark:

<body>
  <header><!-- Landmark „banner“ --></header>

  <main>
    <article>
      <header><!-- KEINE Landmark – steckt im article --></header>

      <footer><!-- KEINE Landmark --></footer>
    </article>
  </main>

  <footer><!-- Landmark „contentinfo“ --></footer>
</body>

Das ist kein Bug, sondern Absicht: banner und contentinfo stehen für den seitenweiten Kopf- und Fußbereich, und davon soll es jeweils nur einen geben. Du kannst also bedenkenlos in jedem Artikel und jeder <section> eigene <header>- und <footer>-Elemente verwenden – die Landmark-Karte bleibt sauber.

Das neue search-Element (und role=“search”)

Die search-Landmark war lange die einzige der acht Rollen ohne eigenes HTML-Element – man musste role="search" schreiben, meist am Suchformular. Seit 2023 gibt es das <search>-Element im HTML-Standard, das genau diese Rolle nativ mitbringt:

<!-- Modern: das search-Element umschließt das Suchformular -->
<search>
  <form action="/suche.html">
    <label for="q">Suche</label>
    <input type="search" id="q" name="q">
    <button>Suchen</button>
  </form>
</search>

<!-- Klassisch, funktioniert überall: role="search" direkt am Formular -->
<form role="search" action="/suche.html">

</form>

Beide Varianten führen zum selben Ergebnis: Screenreader melden eine „Suche“-Region, die sich direkt anspringen lässt. Beachte den Unterschied: role="search" am <form> ersetzt dessen form-Rolle – das ist hier gewollt, denn ein Suchformular soll als Suche auffindbar sein, nicht als generisches Formular.

Randnotiz – Übergangslösung. <search> wird inzwischen von allen großen Browsern unterstützt; sehr alte Browser behandeln unbekannte Elemente als neutrale Container, kaputt geht also nichts. Wer ältere Screenreader-Kombinationen mitnehmen will, kann übergangsweise <search role="search"> schreiben – redundant, aber unschädlich.

Landmarks benennen: aria-label und aria-labelledby

Tauchen gleiche Landmark-Typen mehrfach auf – etwa zwei <nav>-Bereiche –, müssen sie unterscheidbar sein. Ein zugänglicher Name über aria-label schafft Klarheit:

<nav aria-label="Hauptnavigation">…</nav>
<nav aria-label="Brotkrümel">…</nav>

<aside aria-label="Weiterführende Links">…</aside>

Noch besser ist aria-labelledby, wenn die Region ohnehin eine sichtbare Überschrift hat – dann gibt es nur eine Textquelle, die auch bei Übersetzungen und Redesigns konsistent bleibt:

<nav aria-labelledby="toc-heading">
  <h2 id="toc-heading">Auf dieser Seite</h2>

</nav>

Umgekehrt gilt: Kommt eine Rolle nur einmal vor (typisch: banner, main, contentinfo, search), braucht sie keinen Namen – der Rollenname allein reicht zur Orientierung.

Randnotiz – Rollennamen nicht wiederholen. Screenreader hängen den Rollennamen selbst an: Aus aria-label="Hauptnavigation" wird „Hauptnavigation, Navigation“. Das W3C empfiehlt deshalb, das Wort „Navigation“ nicht in den Namen zu packen. Im Deutschen hat sich „Hauptnavigation“ trotzdem eingebürgert und ist verschmerzbar – ein aria-label="Navigationsmenü-Navigation" dagegen nervt wirklich.

section wird erst mit Namen zur region

Eine <section> ist erst dann eine region-Landmark, wenn sie einen zugänglichen Namen hat – ohne Namen bleibt sie ein neutraler Gliederungscontainer ohne Landmark-Bedeutung. Das ist eine bewusste Schutzregel: Würde jede <section> zur Landmark, wäre die Landmark-Liste vieler Seiten unbrauchbar lang.

<!-- Keine Landmark: section ohne Namen -->
<section>
  <h2>Unsere Leistungen</h2>

</section>

<!-- region-Landmark: section mit Namen aus der eigenen Überschrift -->
<section aria-labelledby="leistungen">
  <h2 id="leistungen">Unsere Leistungen</h2>

</section>

Setze region deshalb gezielt ein: nur für Bereiche, die so wichtig sind, dass Nutzende sie direkt anspringen wollen und für die keine der sieben spezifischeren Rollen passt. Wann <section> überhaupt das richtige Element ist, habe ich unter article vs. section ausführlicher beschrieben.

Eine vollständige Landmark-Struktur

So sieht eine typische Seite aus, in der jeder sichtbare Inhalt in einer Landmark liegt:

<body>
  <header>
    <a href="/index.html">Logo</a>
    <nav aria-label="Hauptnavigation">…</nav>
    <search>
      <form action="/suche.html">…</form>
    </search>
  </header>

  <main>
    <h1>Seitentitel</h1>
    <article>…</article>
    <aside aria-label="Verwandte Themen">…</aside>
  </main>

  <footer>
    <nav aria-label="Rechtliches">…</nav>
    <p>© 2026 Beispiel GmbH</p>
  </footer>
</body>

Diese Seite besitzt sieben klar unterscheidbare Anlaufpunkte: banner, zweimal navigation (benannt), search, main, complementary und contentinfo. Das passt zur Faustregel aus den W3C-ARIA-Authoring-Practices: sieben oder weniger Landmarks pro Seite – ihr Wert sinkt, je mehr es werden. Und genauso wichtig: Jeder sichtbare Inhalt liegt innerhalb einer Landmark. „Herrenloser“ Text zwischen den Regionen ist ein typischer Schwachpunkt, denn wer per Landmark navigiert, überspringt ihn unbemerkt.

Schematischer Wireframe einer Webseite mit fünf farbig markierten Landmark-Regionen. Oben liegt ein Kopfbereich mit der Rolle banner aus dem Element header, darunter eine Navigationsleiste mit der Rolle navigation aus einem nav-Element mit dem aria-label „Hauptnavigation“. In der Mitte füllt links ein breiter Hauptbereich mit der Rolle main aus dem Element main die Seite, rechts daneben steht eine schmalere Randspalte mit der Rolle complementary aus dem Element aside. Den Abschluss bildet unten ein Fußbereich mit der Rolle contentinfo aus dem Element footer.
Fünf Landmarks aus fünf HTML-Elementen, ganz ohne role-Attribute: banner, navigation, main, complementary und contentinfo teilen die Seite lückenlos in anspringbare Regionen auf.

So navigieren Screenreader-Nutzende wirklich

Landmarks sind kein Selbstzweck – sie sind an konkrete Tastenbefehle gebunden. Wer versteht, wie Screenreader-Nutzer surfen, begreift sofort, warum saubere Landmarks so viel Zeit sparen:

Screenreader Nächste/vorige Landmark Landmark-Liste Nächste Überschrift
NVDA (Windows) D / Umschalt+D NVDA+F7 (Elementliste) H, Ebenen: 16
JAWS (Windows) R / Umschalt+R, Q springt zu main Einfg+Strg+R H, Ebenen: 16
VoiceOver (macOS) W / Umschalt+W (Quick Nav) Rotor: VO+U VO+Cmd+H
Orca (Linux) M / Umschalt+M Alt+Umschalt+M H

Die JAWS-Taste Q zeigt schön, wie zentral die main-Landmark ist: ein einziger Tastendruck, und der gesamte Vorspann aus Logo, Navigation und Suche ist übersprungen. Fehlt <main>, fehlt diese Abkürzung. Wie du diese Befehle selbst ausprobierst, steht in den Screenreader-Grundlagen.

Wichtig zur Einordnung: Landmarks ersetzen keine Skip-Links. Sehende Tastatur-Nutzende ohne Screenreader haben keine D- oder R-Taste – für sie bleibt der sichtbare Sprunglink zum Inhalt das Mittel der Wahl. Beides gehört auf jede Seite.

Die Dokument-Outline

Während Landmarks die großen Bereiche markieren, beschreibt die Outline die inhaltliche Gliederung – gebildet aus den Überschriften <h1> bis <h6>. Screenreader erzeugen daraus ein Inhaltsverzeichnis, über das Nutzende von Überschrift zu Überschrift springen (H) oder gezielt eine Ebene ansteuern (16). Umfragen unter Screenreader-Nutzenden – etwa die WebAIM Screen Reader Survey – zeigen seit Jahren: Die Navigation über Überschriften ist die häufigste Methode, sich auf einer unbekannten Seite zu orientieren, noch vor der Landmark-Navigation. Landmarks liefern die Grobkarte, Überschriften das Feinraster.

Damit diese Outline funktioniert, müssen die Ränge lückenlos und in der richtigen Reihenfolge vergeben sein:

<h1>Semantisches HTML</h1>
  <h2>Struktur-Elemente</h2>
    <h3>header</h3>
    <h3>nav</h3>
  <h2>Textauszeichnung</h2>

Ein Sprung von <h1> direkt zu <h3> (ohne <h2>) hinterlässt eine Lücke und irritiert die Navigation: Wer mit der Taste 2 alle Hauptabschnitte abklappern will, verpasst den Bereich komplett. Und wer eine Überschrift nur wegen ihrer Schriftgröße wählt, sollte stattdessen das CSS anpassen – die Ebene beschreibt die Position in der Gliederung, nicht die Optik.

Der Mythos vom Outline-Algorithmus

Lange galt die Annahme, verschachtelte <section>-Elemente würden automatisch eine eigene Überschriften-Hierarchie erzeugen, sodass mehrere <h1> „sicher“ seien. Dieser Outline-Algorithmus wurde nie von einem Browser oder Screenreader umgesetzt und ist inzwischen aus der HTML-Spezifikation entfernt; MDN stuft verschachtelte <h1>-Elemente heute sogar als nicht mehr konform ein. In der Praxis zählt allein der tatsächliche Rang der Überschrift. Meine Empfehlung: pro Seite eine <h1> und von dort an saubere, fortlaufende Ränge. Mehr dazu unter Überschriften-Hierarchie.

Landmarks und Outline prüfen

Beides lässt sich gut testen, bevor überhaupt eine assistive Technologie zum Einsatz kommt:

  • „Landmarks“-Browsererweiterung (Firefox/Chrome): blendet alle Landmark-Regionen samt Rollen und Namen visuell ein und macht unbenannte Doppelungen sofort sichtbar.
  • HeadingsMap oder eine ähnliche Outline-Erweiterung: listet die komplette <h>-Struktur als Baum und deckt Rang-Sprünge auf.
  • axe DevTools: meldet unter anderem „All page content should be contained by landmarks“ (Inhalt außerhalb jeder Landmark) und „Document should have one main landmark“ – genau die beiden häufigsten Landmark-Fehler.
  • Lighthouse: prüft im Accessibility-Audit, ob Überschriftenebenen übersprungen werden.
  • Accessibility-Tree der DevTools: zeigt in Chrome und Firefox, welche Rollen und Namen der Browser tatsächlich an assistive Technologien meldet – die Wahrheit hinter deinem Markup.
  • Screenreader: Die Elementliste von NVDA (NVDA+F7) und der VoiceOver-Rotor (VO+U) zeigen Landmarks und Überschriften genau so, wie Nutzende sie erleben.

Mein schneller Praxistest bei jeder neuen Vorlage: Wenn die reine Überschriftenliste einer Seite schon ein verständliches Inhaltsverzeichnis ergibt und die Landmark-Liste sieben klar benannte Einträge oder weniger hat, ist die Struktur meist in Ordnung.

Häufige Fehler

  • Kein <main> – der Hauptinhalt hat keine eigene Landmark, und die wichtigste Abkürzung (JAWS Q, Sprung zu main) läuft ins Leere.
  • Inhalte außerhalb jeder Landmark, etwa direkt zwischen <header> und <main> – wer per Landmark navigiert, überspringt sie unbemerkt.
  • Mehrere gleiche Landmarks ohne Namen, sodass „Navigation“ dreimal identisch in der Liste steht.
  • Rollenname im Label wiederholtaria-label="Navigation" wird zu „Navigation, Navigation“ vorgelesen.
  • banner/contentinfo in Unterbereichen erwartet<header> und <footer> in article, section und Co. erzeugen keine Landmark; das ist Absicht, kein Fehler deines Browsers.
  • region-Inflation – jede <section> bekommt ein aria-label, und die Landmark-Liste wird länger als die Seite selbst.
  • Übersprungene Überschriftenränge (<h1><h3>), die die Outline zerreißen.
  • Überschriften nach Optik statt Bedeutung gewählt – die Ebene ist Gliederung, die Größe ist CSS.

Häufige Fragen

Wie viele Landmarks sollte eine Seite haben?

Die W3C-ARIA-Authoring-Practices nennen als Faustregel sieben oder weniger – der Nutzen von Landmarks sinkt, je mehr es werden. Eine typische Seite kommt mit banner, ein bis zwei benannten navigation-Bereichen, main, optional search, complementary und contentinfo aus. Entscheidend ist nicht die Zahl, sondern dass jede Landmark einen echten Anlaufpunkt markiert und aller Inhalt abgedeckt ist.

Ist <article> auch eine Landmark?

Nein. <article> hat die Rolle article, und die gehört nicht zu den acht Landmark-Rollen – Screenreader behandeln sie separat (NVDA kennt dafür keine eigene Schnellnavigationstaste, Landmarks dagegen schon). Für die Frage, wann <article>, <section> oder ein <div> das richtige Element ist, lohnt ein Blick auf article vs. section und die Struktur-Elemente im Überblick.

Brauche ich role="banner" zusätzlich zu <header>?

Nein. Moderne Browser und Screenreader leiten die Rolle direkt aus dem Element ab; <header role="banner"> ist doppelt gemoppelt. Die reinen role-Attribute auf <div>-Containern sind nur noch für sehr alte Codebasen ohne HTML5-Elemente relevant.

Nein. Landmark-Navigation funktioniert nur mit Screenreader oder speziellen Browser-Erweiterungen. Sehende Menschen, die nur mit der Tastatur arbeiten, brauchen weiterhin einen sichtbaren Skip-Link zum Hauptinhalt. Beides zusammen ist der Standard.

Sind mehrere <h1> pro Seite erlaubt?

Der HTML-Standard erlaubt mehrere <h1> auf einer Ebene, aber Best Practice ist eine einzige <h1>, die den Seiteninhalt beschreibt – so empfiehlt es auch MDN. Verschachtelte <h1> (im Vertrauen auf den nie implementierten Outline-Algorithmus) sind inzwischen sogar nicht mehr konform. Details in der Überschriften-Hierarchie.

Wird eine <form> automatisch zur Landmark?

Nur mit zugänglichem Namen – genau wie <section>. Ein <form aria-labelledby="kontakt-heading"> erscheint als form-Landmark in der Liste, ein namenloses Formular nicht. Suchformulare sind der Sonderfall: Sie gehören in ein <search>-Element oder bekommen role="search", damit sie als Suche auffindbar sind.

Fazit

Landmarks und Outline sind die unsichtbare Bedienoberfläche deiner Seite – die eine liefert die Grobkarte mit maximal einer Handvoll Anlaufpunkten, die andere das feine Inhaltsverzeichnis. Beide entstehen fast geschenkt, wenn du semantisch arbeitest: Die Struktur-Elemente liefern die Landmarks, eine saubere Überschriften-Hierarchie die Outline. Denk an die Scoping-Regel für <header> und <footer>, benenne doppelte Landmarks, gönn deiner Suche ein <search>-Element – und mach die Struktur einmal mit einem Werkzeug sichtbar. Oft erkennt man auf einen Blick, wo eine Seite ihre Nutzer verliert.

Quellen

  • Page Regions (W3C-WAI-Tutorial – Zuordnung von HTML-Elementen zu Landmark-Rollen samt Scoping-Hinweisen)
  • Landmarks Pattern (W3C ARIA Authoring Practices – die acht Rollen und die Sieben-oder-weniger-Faustregel)
  • Das search-Element (MDN – natives HTML-Element für die search-Landmark)
  • Headings and landmarks (web.dev – Überschriften-Navigation, Skip-Links und Lighthouse-Prüfung)
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.