Wie header, nav, main und aside Screenreader-Nutzern Orientierung geben
Screenreader-Nutzer orientieren sich nicht durch Scrollen, sondern durch gezielte Sprünge zwischen Landmarks wie header, nav, main, aside und footer. Wer diese HTML5-Elemente korrekt und sparsam einsetzt, verschafft blinden und sehbehinderten Besuchern eine schnelle Übersicht über jede Seite und ermöglicht direkten Zugriff auf Inhalte, während überflüssige oder unbeschriftete Landmarks genau das Gegenteil bewirken und die Navigation spürbar erschweren.
Inhaltsverzeichnis
- 1. Warum Landmark-Rollen die Grundlage barrierefreier Navigation sind
- 2. Die impliziten ARIA-Rollen von HTML5-Elementen im Überblick
- 3. header und nav: Einstiegspunkte für Screenreader-Nutzer
- 4. main: der wichtigste Landmark der Seite
- 5. aside: Ergänzungsinhalte korrekt auszeichnen
- 6. footer und contentinfo: der Abschluss der Seite
- 7. Wie Screenreader-Nutzer zwischen Landmarks springen
- 8. Landmark-Overuse und unbeschriftete Duplikate vermeiden
- 9. Praxisbeispiel: Landmark-Struktur für eine E-Commerce-Seite
- 10. Zusammenfassung
- 11. FAQ
1. Warum Landmark-Rollen die Grundlage barrierefreier Navigation sind
Blinde und stark sehbehinderte Nutzer erfassen eine Webseite nicht auf einen Blick wie sehende Besucher, sondern hören sich linear durch den Accessibility Tree. Ohne Orientierungspunkte müsste jede Seite von oben nach unten durchgehört werden, bevor der eigentliche Inhalt erreichbar ist. Landmark-Rollen lösen genau dieses Problem: Sie unterteilen eine Seite in benannte Regionen wie banner, navigation, main, complementary und contentinfo, zwischen denen Screenreader per Tastenkürzel direkt springen können. Wer die passenden HTML5-Elemente verwendet, bekommt diese Struktur automatisch, ohne ein einziges ARIA-Attribut manuell setzen zu müssen.
Der WebAIM Screen Reader Survey zeigt seit Jahren, dass Landmark-Navigation zu den am häufigsten genutzten Techniken erfahrener Screenreader-Nutzer zählt, direkt neben der Überschriften-Navigation. Eine Seite ohne saubere Landmark-Struktur zwingt diese Nutzer, sich durch Dutzende Links und Textblöcke zu tasten, um den Hauptinhalt zu finden. In Magento- und Hyvä-Shops mit komplexen Layouts aus Header, Megamenü, Breadcrumb, Sidebar-Filtern und Footer ist eine korrekte Landmark-Struktur deshalb keine Kür, sondern eine Grundvoraussetzung für nutzbare Navigation.
2. Die impliziten ARIA-Rollen von HTML5-Elementen im Überblick
Moderne Browser übersetzen semantische HTML5-Elemente automatisch in ARIA-Landmark-Rollen, die im Accessibility Tree landen: <header> wird zu role="banner", <nav> zu role="navigation", <main> zu role="main", <aside> zu role="complementary" und <footer> zu role="contentinfo". Diese Zuordnung passiert ohne zusätzliches Markup, solange die Elemente an der richtigen Stelle im Dokument stehen. Zusätzlich explizite ARIA-Rollen wie role="banner" neben <header> zu schreiben ist redundant und kann Assistive Technologien sogar verwirren, wenn beide Angaben inkonsistent gepflegt werden.
Wichtig ist die Einschränkung „an der richtigen Stelle": Die implizite Rolle gilt nur, wenn das Element nicht in bestimmten Vorfahren-Elementen verschachtelt ist. <header> und <footer> verlieren ihre Landmark-Rolle, sobald sie innerhalb von <article>, <aside>, <main>, <nav> oder <section> stehen, und werden dann zu reinen strukturellen Containern ohne Landmark-Status. Das folgende Grundgerüst zeigt eine korrekte Verteilung der Landmarks für eine typische Seite.
<!-- Semantisches HTML5-Grundgeruest: Landmarks entstehen automatisch durch implizite ARIA-Rollen -->
<body>
<header>
<!-- role="banner" gilt nur hier, top-level im body -->
<a class="skip-link" href="#maincontent">Zum Hauptinhalt springen</a>
<nav aria-label="Hauptnavigation">
<ul>
<li><a href="/">Start</a></li>
<li><a href="/damenmode">Damenmode</a></li>
<li><a href="/herrenmode">Herrenmode</a></li>
</ul>
</nav>
</header>
<!-- Zweite nav-Landmark: eigenes aria-label, sonst nicht unterscheidbar -->
<nav aria-label="Breadcrumb">
<ol>
<li><a href="/">Start</a></li>
<li><a href="/damenmode">Damenmode</a></li>
<li aria-current="page">Wanderschuhe</li>
</ol>
</nav>
<main id="maincontent">
<!-- role="main", genau einmal pro Seite -->
<h1>Wanderschuh Modell Alpin</h1>
<section aria-labelledby="reviews-heading">
<h3 id="reviews-heading">Kundenbewertungen</h3>
</section>
</main>
<aside aria-label="Verwandte Produkte">
<!-- role="complementary" -->
</aside>
<footer>
<!-- role="contentinfo" gilt nur hier, top-level im body -->
</footer>
</body>
3. header und nav: Einstiegspunkte für Screenreader-Nutzer
Der <header> einer Seite behält seine Rolle banner nur, wenn er ein direktes oder mittelbares Kind von <body> ist und nicht innerhalb von <article>, <aside>, <main> oder <section> liegt. In vielen Hyvä-Templates wird diese Grenze versehentlich verschoben, wenn ein Custom-Modul den globalen Header innerhalb eines CMS-Blocks oder eines zusätzlichen <section>-Wrappers rendert. Das Ergebnis: Der Header verliert stillschweigend seine Banner-Rolle, und Screenreader-Nutzer können nicht mehr direkt dorthin springen, obwohl das Markup optisch identisch aussieht.
Ein <nav>-Element braucht immer dann ein aria-label, wenn mehr als eine Navigation auf derselben Seite existiert, etwa Hauptnavigation, Breadcrumb, Footer-Navigation und mobile Kategorie-Filter. Ohne Label kündigt der Screenreader jede dieser Landmarks nur als „Navigation" an, ununterscheidbar von den anderen. Ein kurzes, beschreibendes Label wie aria-label="Hauptnavigation" oder aria-label="Breadcrumb" löst dieses Problem vollständig, ohne dass sich am sichtbaren Design irgendetwas ändern muss.
<!-- WRONG: zwei nav-Elemente ohne unterscheidendes Label -->
<nav>
<ul>
<li><a href="/">Start</a></li>
<li><a href="/contact">Kontakt</a></li>
</ul>
</nav>
<main id="maincontent">
<nav>
<ul>
<li><a href="/sale">Sale</a></li>
<li><a href="/neuheiten">Neuheiten</a></li>
</ul>
</nav>
</main>
<!-- RIGHT: jede nav-Landmark bekommt einen eindeutigen Namen -->
<nav aria-label="Hauptnavigation">
<ul>
<li><a href="/">Start</a></li>
<li><a href="/contact">Kontakt</a></li>
</ul>
</nav>
<main id="maincontent">
<nav aria-label="Kategorie-Schnellzugriff">
<ul>
<li><a href="/sale">Sale</a></li>
<li><a href="/neuheiten">Neuheiten</a></li>
</ul>
</nav>
</main>
4. main: der wichtigste Landmark der Seite
Das <main>-Element markiert den eigentlichen, für die aktuelle Seite einzigartigen Inhalt und darf laut HTML-Spezifikation nur genau einmal pro Seite vorkommen und nicht innerhalb von <header>, <nav>, <aside>, <footer> oder <article> verschachtelt sein. Für Screenreader-Nutzer ist main die wichtigste Landmark überhaupt, weil sie mit einem einzigen Tastendruck direkt zum relevanten Inhalt springen können, ohne Header, Megamenü und Breadcrumb erst durchhören zu müssen. Eine stabile id="maincontent" auf dem Element dient zusätzlich als Sprungziel für den klassischen Skip-Link im Head der Seite.
In der Hyvä-Themestruktur rendert Magento_Theme/templates/root.phtml das <main>-Element bereits zentral über columns.phtml. Ein häufiger Fehler bei eigenen CMS-Widgets oder Landingpage-Buildern ist, dass ein weiteres <main> innerhalb eines CMS-Blocks erzeugt wird, etwa durch einen unbedacht kopierten Page-Builder-Baustein. Zwei main-Landmarks auf einer Seite sind für Screenreader mehrdeutig: Welche davon ist der Hauptinhalt? Automatisierte Prüfwerkzeuge wie axe-core melden diesen Fall zuverlässig als Regel landmark-one-main.
5. aside: Ergänzungsinhalte korrekt auszeichnen
Das <aside>-Element erhält die Rolle complementary, wenn es ein Top-Level-Sibling des Hauptinhalts ist, und signalisiert Inhalte, die den Hauptinhalt ergänzen, aber eigenständig verständlich bleiben, etwa eine Sidebar mit Filterfacetten, verwandten Produkten oder einem Newsletter-Hinweis. Nicht jede optisch abgesetzte Box ist automatisch ein guter Kandidat für aside: Werbebanner ohne inhaltlichen Bezug zur Seite oder rein dekorative Elemente gehören nicht in eine complementary-Landmark, weil sie den Landmark-Baum unnötig aufblähen, ohne echten Orientierungswert zu liefern.
Existieren mehrere <aside>-Elemente auf derselben Seite, etwa eine Filter-Sidebar auf der Kategorieseite und ein separater Block „Kunden kauften auch" auf der Produktdetailseite, braucht jedes Element ein eigenes aria-label, genau wie bei mehreren nav-Landmarks. Ein Screenreader-Nutzer, der über die Landmark-Liste zwischen Regionen springt, muss anhand des Labels sofort erkennen können, welcher Inhalt in welcher Sidebar steckt, ohne den kompletten Inhalt vorlesen zu lassen.
6. footer und contentinfo: der Abschluss der Seite
Genau wie <header> behält <footer> seine implizite Rolle contentinfo nur, wenn es sich außerhalb von <article>, <aside>, <main>, <nav> oder <section> befindet. Diese Regel hat einen konkreten praktischen Nutzen: Der Autoren-Info-Block am Ende eines Blogartikels innerhalb von <article> ist bewusst kein contentinfo-Landmark, weil es sich nicht um Copyright- und Rechtsinformationen der gesamten Seite handelt, sondern um artikelspezifische Metadaten. Der globale Footer mit Impressum, AGB und Kontaktdaten außerhalb von <main> ist hingegen genau der Fall, für den contentinfo gedacht ist.
Diese Unterscheidung ist keine akademische Feinheit, sondern spart Screenreader-Nutzern konkret Zeit: Über die Landmark-Liste erreicht man mit contentinfo zuverlässig den einen globalen Seiten-Footer, statt sich durch mehrere gleichnamige Footer-Landmarks pro Artikel oder Produktkarte zu hangeln, die auf einer Blog-Übersichtsseite mit zehn Artikelvorschauen sonst zehnfach auftauchen würden.
7. Wie Screenreader-Nutzer zwischen Landmarks springen
NVDA und JAWS bieten unter Windows das Tastenkürzel D beziehungsweise Shift+D, um vorwärts oder rückwärts zur nächsten Landmark zu springen, sowie eine dedizierte Landmark-Liste über Insert+F7 (NVDA) oder das Elementlisten-Menü (JAWS), die alle Landmarks der Seite mit ihrem Label auf einen Blick zeigt. VoiceOver unter macOS und iOS bietet über den Rotor eine gleichwertige Übersicht, erreichbar durch zwei Finger im Kreis auf dem Trackpad oder Bildschirm. In allen drei Fällen ist die Reihenfolge und Beschriftung der Landmarks im DOM entscheidend für eine verständliche Liste.
Landmarks und Skip-Links ergänzen sich, ersetzen sich aber nicht gegenseitig: Ein Skip-Link ist der allererste fokussierbare Link auf der Seite und bringt sehende Tastaturnutzer sowie Screenreader-Nutzer mit einem einzigen Tab-Druck direkt zum Hauptinhalt, ohne die Landmark-Liste überhaupt öffnen zu müssen. Landmarks selbst sind dagegen jederzeit über die Zwischen-Landmark-Navigation erreichbar, auch mitten im Lesefluss. Ein visuell verstecktes, aber fokussierbares .skip-link-Element sollte deshalb immer als erstes Kind von <body> stehen.
/* Skip-Link: unsichtbar bis er per Tastatur fokussiert wird */
.skip-link {
position: absolute;
top: -100%;
left: 1rem;
z-index: 100;
padding: 0.75rem 1.25rem;
background-color: #18181b;
color: #f4f4f5;
border-radius: 0.5rem;
font-weight: 600;
text-decoration: none;
transition: top 0.15s ease-out;
}
/* Sichtbar sobald Tastaturfokus den Link erreicht */
.skip-link:focus-visible {
top: 1rem;
outline: 3px solid #71717a;
outline-offset: 2px;
}
/* Landmark-Uebergaenge sichtbar markieren, wenn Fokus per Skript gesetzt wird */
main:target,
[tabindex="-1"]:focus-visible {
outline: none;
}
8. Landmark-Overuse und unbeschriftete Duplikate vermeiden
Genauso schädlich wie fehlende Landmarks ist ihr Übermaß. Wird jeder <div>-Container versehentlich in ein <section> mit implizierter region-Rolle verwandelt, wächst die Landmark-Liste einer typischen E-Commerce-Seite schnell auf zwanzig oder mehr Einträge. Für Screenreader-Nutzer verliert die Landmark-Navigation dann ihren Zweck als schnelle Orientierungshilfe, weil sie faktisch zu einer zweiten, unübersichtlichen Inhaltsübersicht wird. Wichtig zu wissen: <section> erhält nur dann die Landmark-Rolle region, wenn es einen zugänglichen Namen über aria-label oder aria-labelledby besitzt. Ein <section> ohne Namen bleibt für Screenreader ein reiner struktureller Container, kein Landmark, und sollte auch nur dann als section ausgezeichnet werden, wenn diese benannte Region tatsächlich sinnvoll ist.
Der zweite häufige Fehler sind mehrere gleichnamige, unbeschriftete Landmarks, meist bei nav und aside. Automatisierte Testwerkzeuge wie axe-core prüfen genau diesen Fall mit den Regeln landmark-unique und landmark-no-duplicate-banner und schlagen bei Verstößen zuverlässig Alarm. Ein Audit-Report macht das Problem konkret sichtbar, bevor es im Live-Betrieb Nutzer betrifft.
{
"violations": [
{
"id": "landmark-unique",
"impact": "moderate",
"description": "Landmarks should have a unique role or role/label/title combination",
"help": "Ensures landmarks are unique",
"nodes": [
{
"target": ["nav:nth-of-type(2)"],
"html": "<nav><ul>...</ul></nav>",
"failureSummary": "Fix any of the following: Landmark has the same role as another landmark but no unique aria-label to distinguish them"
}
]
},
{
"id": "landmark-no-duplicate-banner",
"impact": "moderate",
"description": "Ensures the page has at most one banner landmark",
"nodes": [
{
"target": ["header:nth-of-type(2)"],
"failureSummary": "A second header element is being interpreted as an additional banner landmark"
}
]
}
]
}
9. Praxisbeispiel: Landmark-Struktur für eine E-Commerce-Seite
Eine typische Produktdetailseite in einem Magento- oder Hyvä-Shop kombiniert Header mit Suche und Warenkorb-Icon, Breadcrumb, Hauptinhalt mit Produktgalerie und Kaufoptionen, eine Sidebar mit verwandten Produkten und einen globalen Footer. Entscheidend ist, dass jede dieser Zonen genau eine passende Landmark bekommt und mehrfach vorkommende Typen wie nav und aside konsequent gelabelt werden. Ein mobiles Off-Canvas-Menü verdient dabei besondere Aufmerksamkeit: Es sollte erst dann als eigene nav-Landmark im Accessibility Tree sichtbar sein, wenn es tatsächlich geöffnet ist, damit geschlossene, unsichtbare Menüs die Landmark-Liste nicht unnötig aufblähen.
Alpine.js, der JavaScript-Baustein von Hyvä, eignet sich gut, um dieses Verhalten ohne zusätzliche Bibliotheken umzusetzen: Der Zustand des Menüs steuert per x-show zugleich die Sichtbarkeit und über aria-hidden die Zugänglichkeit für assistive Technologien.
// Hyvä Alpine.js: mobiles Off-Canvas-Menue als nav-Landmark korrekt umschalten
document.addEventListener('alpine:init', () => {
Alpine.data('mobileNav', () => ({
open: false,
toggle() {
this.open = !this.open;
// Fokus in die Landmark verschieben, sobald sie sichtbar wird
if (this.open) {
this.$nextTick(() => this.$refs.mobileNavPanel.focus());
}
},
close() {
this.open = false;
}
}));
});
| Element | Häufiger Fehler | Korrektes Pattern | Effekt für Screenreader |
|---|---|---|---|
| header | In section/article verschachtelt | Top-Level im body | Rolle banner bleibt erhalten |
| nav | Mehrere nav ohne Label | aria-label pro nav | Landmarks unterscheidbar |
| main | Zwei main-Elemente | Genau ein main mit id | Eindeutiges Sprungziel |
| aside | Werbebanner als aside | Nur inhaltlich verwandte Boxen | Landmark-Liste bleibt relevant |
| footer | Pro Artikelkarte ein footer | footer nur global, top-level | Ein contentinfo pro Seite |
| section | div durch section ersetzt | section nur mit aria-labelledby | Keine Landmark-Inflation |
Mironsoft
Barrierefreie Navigation, Landmark-Audits und Hyvä-Umsetzung für Magento-Shops
Landmark-Struktur professionell prüfen lassen?
Wir analysieren die Landmark-Struktur eures Magento- oder Hyvä-Shops, decken doppelte und unbeschriftete Landmarks auf und setzen eine saubere, WCAG-konforme Navigation für Screenreader-Nutzer um.
Landmark-Audit
axe-core-Scan und manuelle Screenreader-Prüfung mit NVDA und VoiceOver
Hyvä-Umsetzung
Layout-Templates auf korrekte header/nav/main/aside/footer-Struktur umstellen
Skip-Links & Fokus
Skip-Link-Pattern und Fokusmanagement für Off-Canvas-Menüs implementieren
10. Zusammenfassung
Die Landmark-Rollen und HTML5-Elemente lösen ein zentrales Orientierungsproblem: Ohne benannte Regionen wie banner, navigation, main, complementary und contentinfo müssten Screenreader-Nutzer jede Seite linear von oben nach unten durchhören. <header>, <nav>, <main>, <aside> und <footer> liefern diese Struktur automatisch über implizite ARIA-Rollen, solange sie an der richtigen Stelle im Dokument stehen und nicht in falschen Elternelementen verschachtelt sind. Mehrfach vorkommende Landmark-Typen wie nav und aside brauchen zwingend ein eindeutiges aria-label, damit sie in der Landmark-Liste unterscheidbar bleiben.
Genauso wichtig wie die korrekte Verwendung ist die Zurückhaltung: Landmark-Overuse durch beliebig benannte section-Elemente macht die Navigation für Screenreader-Nutzer genauso mühsam wie ihr völliges Fehlen. Automatisierte Tools wie axe-core mit den Regeln landmark-unique, landmark-one-main und landmark-no-duplicate-banner decken die häufigsten Verstöße zuverlässig auf, ersetzen aber nicht den manuellen Test mit einem echten Screenreader wie NVDA oder VoiceOver.
Landmark-Rollen und HTML5-Elemente für Navigation, das Wichtigste auf einen Blick
Implizite Rollen nutzen
header, nav, main, aside, footer erzeugen banner, navigation, main, complementary, contentinfo automatisch, ohne zusätzliches ARIA.
Verschachtelung beachten
header und footer verlieren ihre Rolle innerhalb von article, aside, main, nav oder section. Nur top-level im body zählt.
Duplikate labeln
Mehrere nav oder aside auf einer Seite brauchen jeweils ein eindeutiges aria-label, sonst sind sie ununterscheidbar.
Overuse vermeiden
Nur ein main pro Seite, section nur mit aria-labelledby. Zu viele Landmarks sind so schädlich wie zu wenige.