Website-Navigation gestalten: HTML, CSS und Barrierefreiheit

Website-Navigation gestalten: HTML, CSS und Barrierefreiheit

Die Navigation ist das Inhaltsverzeichnis einer Website. Ist sie unklar, finden Besucher nichts, ist sie technisch schlecht gebaut, kommen Menschen mit Tastatur oder Screenreader gar nicht erst weiter. Dieser Leitfaden zeigt, wie eine Navigation heute sauber als HTML-Liste im nav-Element entsteht, wie sie per CSS horizontal oder vertikal ausgerichtet wird, wie ein zugängliches Mobilmenü funktioniert, welche Regeln WCAG und BITV setzen und wo Impressum und Datenschutzerklärung hingehören. Zum Schluss geht es um die Dauerfrage, ob Links in einem neuen Tab öffnen sollen.

Von Bildbuttons zur Linkliste

Um die Jahrtausendwende bestanden Menüs oft aus Grafiken mit JavaScript-Rollover-Effekten, aus Imagemaps oder aus Frames, die eine feste Menüspalte neben dem Inhalt hielten. Das sah einheitlich aus, war aber für Suchmaschinen und Screenreader schwer lesbar und ließ sich nur mit Bildbearbeitung ändern. Anfang der 2000er-Jahre setzte sich in der Webstandards-Bewegung eine einfache Idee durch: Eine Navigation ist inhaltlich eine Liste von Links, also wird sie als ul mit li-Elementen geschrieben und erst per CSS zur Leiste gestaltet. Mit HTML5 kam das nav-Element hinzu, das einen Block als Navigationsbereich auszeichnet. Dieses Muster ist bis heute der Standard.

Das Grundgerüst: nav, ul und aria-current

<nav aria-label='Hauptmenü'>
  <ul class='menu'>
    <li><a href='/'>Start</a></li>
    <li><a href='/leistungen/' aria-current='page'>Leistungen</a></li>
    <li><a href='/blog/'>Blog</a></li>
    <li><a href='/kontakt/'>Kontakt</a></li>
  </ul>
</nav>

Drei Details machen den Unterschied. Erstens: Gibt es mehrere nav-Bereiche, etwa Hauptmenü und Inhaltsverzeichnis, braucht jeder eine eindeutige Beschriftung per aria-label oder aria-labelledby. Laut MDN gehört nicht jede Linksammlung in ein nav, sondern nur größere Navigationsblöcke. Zweitens: aria-current mit dem Wert page am Link der aktuellen Seite teilt Screenreadern mit, wo man sich befindet. Drittens lässt sich dasselbe Attribut als CSS-Selektor nutzen, sodass die optische Markierung automatisch zur technischen passt.

Horizontal oder vertikal mit wenigen Zeilen CSS

Früher brauchte eine horizontale Leiste float oder display: inline mit allerlei Korrekturen. Heute erledigt das Flexbox:

.menu {
  list-style: none;
  margin: 0;
  padding: 0;
  display: flex;            /* horizontal */
  flex-wrap: wrap;
  gap: 0.25rem 1rem;
}
.menu a {
  display: block;
  padding: 0.75rem 0.5rem;  /* große Klickfläche */
  color: #1a1a1a;
}
.menu a[aria-current='page'] {
  font-weight: bold;
  text-decoration: underline;
}
.menu a:focus-visible {
  outline: 3px solid #0057b8;
  outline-offset: 2px;
}

Für eine vertikale Seitenleiste genügt flex-direction: column. Wer die Leiste beim Scrollen oben halten will, setzt den Kopfbereich auf position: sticky mit top: 0; die Grundlagen dazu erklärt unser Beitrag CSS-Ebenen verstehen. Wichtig: Den Fokusrahmen nie ersatzlos mit outline: none entfernen, sonst sehen Tastaturnutzer nicht, wo sie sind.

Das mobile Menü: ein Button, kein Rätsel

Auf schmalen Bildschirmen wird das Menü meist hinter einem Button versteckt. Das W3C beschreibt dafür in den ARIA Authoring Practices das Disclosure-Muster: Ein echter button schaltet die Liste ein und aus und meldet seinen Zustand über aria-expanded. Die Rolle menu ist für Website-Navigation ausdrücklich nicht gedacht, weil Screenreader dann Tastaturverhalten wie in einer Desktop-Anwendung erwarten.

<button type='button' id='menu-btn' aria-expanded='false' aria-controls='hauptmenue'>
  Menü
</button>
<ul id='hauptmenue' class='menu' hidden> … </ul>



<script>
const btn = document.getElementById('menu-btn');
const list = document.getElementById('hauptmenue');
btn.addEventListener('click', () => {
  const open = btn.getAttribute('aria-expanded') === 'true';
  btn.setAttribute('aria-expanded', String(!open));
  list.hidden = open;
});
</script>

Das Beispiel ist bewusst schlicht; auf breiten Bildschirmen blendet man den Button per Media Query aus und zeigt die Liste dauerhaft. Das Symbol mit drei Strichen allein ist nicht für alle verständlich, ein sichtbares Wort „Menü“ hilft. Hat eine Website nur vier oder fünf Punkte, passen diese oft auch mobil direkt in eine umbrechende Leiste, dann ist gar kein Klappmenü nötig. Untermenüs sollten per Klick oder Enter öffnen, nicht nur beim Überfahren mit der Maus, und sich mit Escape schließen lassen.

Barrierefreiheit: WCAG, BITV und BFSG

Die Web Content Accessibility Guidelines (WCAG 2.2) enthalten mehrere Kriterien, die Navigationen direkt betreffen:

  • Tastatur (2.1.1) und sichtbarer Fokus (2.4.7): Jeder Menüpunkt muss per Tab erreichbar und dabei erkennbar markiert sein.
  • Kontrast (1.4.3): mindestens 4,5:1 für normalen Text, also auch für Menülinks auf farbigem Hintergrund.
  • Zielgröße (2.5.8): klickbare Ziele mindestens 24 × 24 CSS-Pixel, sofern sie nicht im Fließtext stehen.
  • Konsistente Navigation (3.2.3): wiederkehrende Menüs stehen auf allen Seiten in derselben Reihenfolge.
  • Mehrere Wege (2.4.5): neben dem Menü etwa eine Suche oder Sitemap.

Ein Link „Zum Inhalt springen“ als erstes Element der Seite erspart Tastaturnutzern, sich auf jeder Seite durch das komplette Menü zu tabben. Rechtlich verbindlich sind diese Anforderungen in Deutschland für öffentliche Stellen über die BITV 2.0 und die Landesgesetze. Seit dem 28. Juni 2025 verpflichtet zudem das Barrierefreiheitsstärkungsgesetz (BFSG) viele Anbieter von Online-Diensten für Verbraucher, etwa Onlineshops; Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz oder Bilanzsumme sind bei Dienstleistungen ausgenommen. Als Maßstab gilt die Norm EN 301 549, die auf den WCAG aufbaut. Private Blogs fallen nicht darunter, profitieren aber von denselben Regeln.

Usability-Grundregeln für Menüpunkte

  • Wenige Punkte: Fünf bis sieben Hauptpunkte sind eine gute Größenordnung. Was darüber hinausgeht, gehört in Unterseiten oder die Suche.
  • Klare Beschriftung: „Preise“ statt „Investition“, „Kontakt“ statt „Sag Hallo“. Konventionen schlagen Originalität.
  • Logo führt zur Startseite: Das erwarten Nutzer, ein eigener Punkt „Start“ schadet trotzdem nicht.
  • Aktuelle Position zeigen: markierter Menüpunkt, bei tiefen Strukturen zusätzlich eine Brotkrumennavigation.
  • Keine Überraschungen: Menüs nicht von Seite zu Seite umbauen, Links nicht als Buttons tarnen und umgekehrt.

Impressum, Kontakt und Datenschutz gut auffindbar

Für geschäftsmäßige digitale Dienste verlangt § 5 des Digitale-Dienste-Gesetzes (DDG), seit Mai 2024 Nachfolger des Telemediengesetzes, die Anbieterangaben leicht erkennbar, unmittelbar erreichbar und ständig verfügbar zu halten. Der Bundesgerichtshof hat bereits am 20. Juli 2006 (Az. I ZR 228/03) entschieden, dass Links mit der Bezeichnung „Kontakt“ oder „Impressum“ genügen und zwei Klicks bis zu den Angaben in der Regel noch als unmittelbar erreichbar gelten. Bewährt hat sich ein Fußbereich, der auf jeder Seite Impressum, Datenschutzerklärung und Kontakt verlinkt. Die Datenschutzinformationen nach Art. 13 DSGVO werden ebenso von jeder Seite aus erreichbar gemacht. Wer eine private Seite betreibt und unsicher ist, ob ein Impressum nötig ist, findet Hinweise in unserem Beitrag zur Über-mich-Seite. Stand Oktober 2026, keine Rechtsberatung.

Links im neuen Tab: target=_blank abwägen

Das Attribut target=_blank öffnet einen Link in einem neuen Tab oder Fenster. Betreiber mögen das, weil die eigene Seite offen bleibt. Für Nutzer hat es Nachteile: Der Zurück-Button funktioniert im neuen Tab nicht, auf Mobilgeräten bemerkt man den Wechsel kaum, und wer einen neuen Tab will, kann ihn ohnehin per Mittelklick oder Kontextmenü öffnen. Die W3C-Technik G201 empfiehlt deshalb, einen neuen Tab zumindest anzukündigen, etwa mit „(öffnet in neuem Tab)“ oder einem Symbol mit Textalternative.

Das frühere Sicherheitsproblem ist weitgehend erledigt: Über window.opener konnte eine fremde Seite die öffnende Seite umleiten. Laut MDN verhält sich target=_blank in aktuellen Browsern automatisch wie rel=noopener; das Attribut explizit zu setzen schadet trotzdem nicht. Unsere Einschätzung: Navigation und interne Links immer im selben Tab. Neue Tabs lohnen sich vor allem dort, wo Nutzer etwas verlieren könnten, etwa bei Hilfelinks in halb ausgefüllten Formularen, oder bei Quellenlisten, von denen Leser zum Artikel zurückkehren wollen.

Quellen