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,formundregion. - Sechs davon entstehen automatisch aus HTML-Elementen –
<header>,<nav>,<main>,<aside>,<footer>,<search>. Zusätzlicherole-Attribute sind überflüssig. -
regionundformbrauchen einen zugänglichen Namen, sonst tauchen sie nicht in der Landmark-Liste auf. Ein<section>ohnearia-labeloderaria-labelledbyistgeneric. - Scoping-Regel:
<header>und<footer>verlieren ihre Landmark-Rolle, sobald sie inarticle,aside,main,navodersectionliegen. - Bei mehreren gleichartigen Bereichen entscheidet der Name: Ohne
aria-labelheiß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.
Die Scoping-Regel: wann header und footer zur Landmark werden
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 – einaria-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.
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: 1–6 |
| JAWS (Windows) | R / Umschalt+R, Q springt zu main |
Einfg+Strg+R |
H, Ebenen: 1–6 |
| 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 (1–6). 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 (JAWSQ, Sprung zumain) 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 wiederholt –
aria-label="Navigation"wird zu „Navigation, Navigation“ vorgelesen. -
banner/contentinfoin Unterbereichen erwartet –<header>und<footer>inarticle,sectionund Co. erzeugen keine Landmark; das ist Absicht, kein Fehler deines Browsers. - region-Inflation – jede
<section>bekommt einaria-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.
Ersetzen Landmarks einen Skip-Link?
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)