Komponenten · Navigation & Bedienelemente

Skip-Link: Blöcke überspringen nach WCAG 2.4.1

Q: Warum springt mein Skip-Link nicht zum Inhalt?

Fast immer fehlt eines von zwei Dingen: die id am Ziel (der Link läuft ins Leere) oder in alten Browsern das tabindex="-1" (der Bildlauf springt, der Tastaturfokus bleibt oben). Prüfen lässt sich das mit document.activeElement in der Browser-Konsole – steht dort body statt main, fehlt entweder die id oder nur das tabindex; dann zeigt eine weitere Tab-Eingabe, ob der Fokus trotzdem im Inhalt landet.

Von Jakob Sommer Zuletzt geändert am 2. Juli 2026

Ein Skip-Link ist ein gewöhnlicher Anker-Link als erstes Element direkt nach dem <body>: Sein href zeigt auf die id des Hauptinhalts, seine Beschriftung lautet „Zum Hauptinhalt springen“. WCAG 2.4.1 „Blöcke umgehen“ (Stufe A) verlangt einen solchen Mechanismus, damit Tastaturnutzende nicht auf jeder Seite erneut durch Header und Navigation tabben müssen. Funktionieren kann er nur als erstes fokussierbares Element, das bei Fokus sichtbar wird und den Fokus tatsächlich ins Ziel verschiebt.

Das Wichtigste in Kürze

WCAG 2.4.1 „Blöcke umgehen“ ist Stufe A: Ohne Mechanismus zum Überspringen wiederholter Blöcke keine Konformität – über die harmonisierte Norm EN 301 549 auch für BITV 2.0 und BFSG (Privatwirtschaft seit dem 28.06.2025).
Der Skip-Link soll das erste fokussierbare Element der Seite sein (BITV-Prüfschritt 2.4.1) und dauerhaft oder bei Tastaturfokus sichtbar werden (W3C-Technik G1).
display: none macht ihn unerreichbar – der BIK BITV-Test wertet so versteckte Skip-Links als „teilweise erfüllt oder schlechter“.
Das Sprungziel braucht eine id; tabindex="-1" ist in aktuellen Browsern nicht mehr nötig, bleibt aber konservative Empfehlung.
Landmarks erfüllen 2.4.1 formal ebenfalls, helfen sehenden Tastaturnutzenden aber nicht – Browser bieten keine Landmark-Sprungnavigation.
WebAIM-Umfrage (2024, n = 1.539): 71,6 % der Screenreader-Nutzenden navigieren primär über Überschriften, nur 3,7 % über Landmarks.
Praxisregel statt Norm: wenige Sprungziele – jeder zusätzliche Link kostet einen Tab; den meisten Seiten genügt einer.

Was WCAG 2.4.1 verlangt

Der Normtext des Kriteriums 2.4.1 ist ein einziger Satz: „Es gibt einen Mechanismus, um Inhaltsblöcke zu umgehen, die auf verschiedenen Webseiten wiederholt werden.“ Gemeint sind Header, Hauptnavigation und Suchleiste; einzelne wiederholte Wörter oder Links zählen laut Understanding-Dokument des W3C ausdrücklich nicht als Blöcke, Browser-eigene Funktionen müssen nicht dupliziert werden. Stufe A – über die Konformitätsvermutung für harmonisierte Normen wirkt es auch im deutschen Recht: BITV 2.0 (§ 3 Abs. 2) und BFSGV (§ 3) verweisen auf die Standard-Listen von Überwachungsstelle und Bundesfachstelle, praktisch die EN 301 549; für private Wirtschaftsakteure seit dem 28. Juni 2025.

Hauptnutznießer sind sehende Tastaturnutzende ohne Screenreader; wer mit Kopfschalter oder Mundstab arbeitet, bezahlt jede Tab-Eingabe mit Zeit und Kraft. Auch Screenreader- und Lupen-Nutzende sowie Menschen mit Konzentrationsschwierigkeiten profitieren – vorausgesetzt, die Seite ist überhaupt per Tastatur bedienbar.

Neben dem Skip-Link (G1) akzeptieren die WCAG weitere Mechanismen: Link zum Blockende (G123), Linkliste aller Seitenbereiche (G124), zusammenklappbare Menüs (SCR28), Überschriftenstruktur (H69), HTML5-Regionen und ARIA-Landmarks (ARIA11), iframe-Titel (H64).

Das komplette Rezept

<body>
  <a class="skip-link" href="#hauptinhalt">Zum Hauptinhalt springen</a>

  <header>…</header>
  <nav aria-label="Hauptnavigation">…</nav>

  <main id="hauptinhalt" tabindex="-1">
    <h1>Seitentitel</h1>
    …
  </main>
</body>

Drei Entscheidungen: Position direkt nach dem <body>, vor Logo und Navigation – der BITV-Prüfschritt verlangt Sprunglinks als „die ersten fokussierbaren Elemente der Tabreihenfolge“; ein Cookie-Banner als Dialog darf davor liegen. Beschriftung: das Ziel benennen, nicht das Übersprungene. Sprungziel: das <main> mit dem zentralen Inhalt der Seite.

Das CSS: versteckt, aber fokussierbar

Der Reflex display: none ist der Totalschaden:

/* Falsch: nimmt den Link aus der Tab-Reihenfolge – er ist nie erreichbar */
.skip-link {
  display: none;
}

Was display: none, visibility: hidden oder das hidden-Attribut versteckt, ist nicht fokussierbar – unerreichbar für genau die Menschen, für die der Link gebaut wurde; der BITV-Test wertet das als „teilweise erfüllt oder schlechter“. Richtig ist visually-hidden:

/* Versteckt – aber nur, solange kein Fokus anliegt */
.skip-link:not(:focus):not(:active) {
  position: absolute;    /* aus dem Layoutfluss nehmen, kein Platzbedarf */
  width: 1px;            /* auf einen Pixel schrumpfen – WebAIM rät zu 1px, */
  height: 1px;           /* damit der Text auch ohne Positionierung versteckt bleibt */
  overflow: hidden;      /* den überstehenden Linktext abschneiden */
  clip-path: inset(50%); /* den verbliebenen Pixel unsichtbar machen */
  white-space: nowrap;   /* Umbruch auf 1 Pixel Breite verhindern */
}

/* Sichtbarer Zustand: greift, sobald der Link Fokus erhält */
.skip-link {
  position: absolute;
  top: 0.5rem;
  left: 0.5rem;
  z-index: 1000;         /* über Sticky-Header und Overlays */
  padding: 0.75rem 1.25rem;
  background: #16181d;   /* dunkel auf hell: Kontrast weit über 4,5:1 */
  color: #fff;
  border-radius: 0.5rem;
}

Per Tab erscheint er oben links mit mindestens 4,5:1 Kontrast; ältere Codebasen schieben ihn stattdessen aus dem Viewport (top: -40px, left: -9999px) – ebenfalls konform, solange nie display: none im Spiel ist.

Das Sprungziel: `id` plus `tabindex="-1"`

Der Anker allein reichte lange nicht zuverlässig. Laut HTML-Standard soll die nächste Tab-Eingabe nach einer Fragment-Navigation beim Ziel weitermachen („sequential focus navigation starting point“), und Stand Juli 2026 setzen aktuelle Browser das um; nach Jahren inkonsistenten Verhaltens (Firefox 2013, Chrome erst 2016, Safari später) bleibt tabindex="-1" die konservative Empfehlung für alte Umgebungen: Das <main> wird programmatisch fokussierbar, ohne Tab-Stopp. tabindex="0" wäre falsch – es hängt das <main> als sinnlosen Halt in die Fokus-Reihenfolge.

Den Umriss, den Browser dabei zeichnen, darfst du unterdrücken – 2.4.7 Fokus sichtbar zielt auf Bedienelemente, und ein programmatisch fokussiertes <main> ist keines; nach Tastaturnutzung zeichnen Browser den Ring laut Selectors Level 4 durchaus.

/* Vertretbar: das Sprungziel ist kein Bedienelement */
main[tabindex="-1"]:focus {
  outline: none;
}

Den Fokusring des Skip-Links selbst dagegen: niemals unterdrücken.

Mehrere Sprungziele

Bei komplexen Layouts – Shop mit Filterspalte, Portal mit mehreren Bereichen – gruppiere ich weitere Sprungziele in einer benannten Landmark:

<nav aria-label="Sprungmarken">
  <a class="skip-link" href="#hauptinhalt">Zum Hauptinhalt springen</a>
  <a class="skip-link" href="#suche">Zur Suche springen</a>
  <a class="skip-link" href="#hauptnavigation">Zur Navigation springen</a>
</nav>

Aber mit Maß: Jeder Sprunglink kostet die Tab-Eingabe, die er sparen soll; eine Obergrenze nennt keine Norm, wenige genügen. Vom alten accesskey="0"-Muster rate ich ab: nie normierte Tastenbelegung, kollidiert mit Browser- und Screenreader-Kürzeln. (2.1.4 Tastenkürzel greift hier nicht – Browser lösen accesskey mit Modifikatortasten aus.)

Formal lässt sich 2.4.1 auch ohne Skip-Link erfüllen – über Überschriften, Landmarks oder iframe-Titel; der BITV-Prüfschritt „Bereiche überspringbar“ akzeptiert jede Variante, eine genügt. Praktisch trägt das nur für Screenreader-Nutzende: WebAIMs Screen Reader Survey #10 (Dezember 2023 bis Januar 2024, 1.539 Antworten) zeigt 71,6 % primäre Navigation über Überschriften, nur 3,7 % über Landmarks; bloß 31,8 % nutzen sie überhaupt häufig. Sehende Tastaturnutzende gehen leer aus – kein Browser bietet ohne Erweiterung eine Sprungnavigation zu Landmarks oder Überschriften. Landmarks sind die Ergänzung, nicht der Ersatz; wie Screenreader-Nutzende wirklich navigieren, zeigt der Blick über ihre Schulter.

Landmark-Hygiene gehört dazu: genau ein <main> pro Seite (HTML-Regel), <header>/<footer> je einmal auf Seitenebene, mehrere <nav> per aria-label unterschieden – Letzteres wertet der BITV-Test sonst ab.

Ein Nebeneffekt, der für die Auffindbarkeit zählt: Der Skip-Link ist auf fast jeder Seite der erste Link im Quelltext. Er sollte deshalb auf den Hauptinhalt zeigen und nicht als Platz für ein Schlagwort missbraucht werden – zur Rolle der Reihenfolge im Quelltext siehe Interne Verlinkung als Strategie.

Ein fixierter Header kann das Sprungziel verdecken: Der Browser scrollt es an den oberen Viewport-Rand, wo der Header klebt. Seit WCAG 2.2 (Oktober 2023) verstößt das gegen 2.4.11 Fokus nicht verdeckt (Minimum), Stufe AA: Ein fokussiertes Element darf nicht vollständig von Autoren-Inhalt verdeckt werden (F110). Die Lösung ist eine Zeile CSS – Technik C43 dokumentiert scroll-padding am Scroll-Container, gleichwertig wirkt scroll-margin-top am Ziel:

/* Sprungziel um die Höhe des fixierten Headers freistellen */
main {
  scroll-margin-top: 5rem;
}

In Single-Page-Apps feuert die Fragment-Navigation nach dem Routenwechsel nicht neu – der Fokus bleibt in der alten Ansicht. Zweierlei muss stimmen: Das Ziel mit seiner id existiert auch im neuen View, und der Fokus wird programmatisch dorthin gesetzt, nicht auf den body.

// Nach dem Client-seitigen Routenwechsel aufrufen
function fokusInNeuenInhalt() {
  const ziel = document.querySelector("main");
  ziel.setAttribute("tabindex", "-1");
  ziel.focus();
}

So testest du es

Nicht vollautomatisch prüfbar – der Handtest dauert zehn Sekunden und folgt der W3C-Technik G1:

Seite neu laden, einmal Tab drücken: Wird als Erstes der Skip-Link fokussiert und sichtbar?
Benennt die Beschriftung das Ziel, etwa „Zum Hauptinhalt springen“?
Enter drücken, in der Konsole document.activeElement abfragen: Liegt der Fokus auf dem <main>?
Noch einmal Tab: Landet der Fokus im Hauptinhalt – und nicht wieder in der Navigation?
Bei fixiertem Header: Ist der Anfang des Inhalts nach dem Sprung sichtbar?

Die Schritte 1, 3 und 4 lassen sich mit Playwright automatisieren; Sichtbarkeit, Kontrast und Beschriftung bleiben Handarbeit.

Häufiger Fehler in der Praxis

Der Skip-Link, den nie jemand gesehen hat. Häufigstes Bild in Audits: Eine spätere CSS-Bereinigung hat die :focus-Regel entfernt – „das Element war doch leer“.

Die Ziel-id hat das Redesign nicht überlebt. Der Link zeigt auf #content, das neue Template nennt das Element main-content – oder im href steht nur noch #. Weil niemand im Team mit der Tastatur testet, fällt das monatelang nicht auf; der Drei-Tasten-Test (Tab, Enter, Tab) gehört in jede Abnahme.

Erst das Logo, dann der Skip-Link. Steht das verlinkte Logo davor, landet der erste Tab dort – wer keinen zweiten Tab probiert, ist längst in der Navigation.

Häufige Fragen

Pflicht ist ein Mechanismus zum Umgehen wiederholter Blöcke – der Skip-Link ist eine von mehreren akzeptierten Techniken dafür, aber die einzige, die auch sehenden Tastaturnutzenden hilft. WCAG 2.4.1 steht auf Stufe A, und das BFSG verlangt über die harmonisierten Normen, praktisch die EN 301 549, WCAG-Konformität, für private Wirtschaftsakteure seit dem 28. Juni 2025.

Nein. Die W3C-Technik G1 akzeptiert beides: dauerhaft sichtbar oder erst bei Tastaturfokus eingeblendet – der BITV-Prüfschritt formuliert es genauso („permanent sichtbar oder bei Fokuserhalt eingeblendet“). Entscheidend ist, dass der Link versteckt fokussierbar bleibt; display: none und visibility: hidden disqualifizieren ihn sofort.

Fast immer fehlt eines von zwei Dingen: die id am Ziel (der Link läuft ins Leere) oder in alten Browsern das tabindex="-1" (der Bildlauf springt, der Tastaturfokus bleibt oben). Prüfen lässt sich das mit document.activeElement in der Browser-Konsole – steht dort body statt main, fehlt entweder die id oder nur das tabindex; dann zeigt eine weitere Tab-Eingabe, ob der Fokus trotzdem im Inhalt landet.

Reichen Landmarks statt eines Skip-Links?

Formal ja – der BITV-Test akzeptiert HTML5-Regionen, ARIA-Landmarks und Bereichsüberschriften als gleichwertige Mechanismen für 2.4.1. Praktisch nein: Ohne Erweiterung bietet kein Browser eine Landmark-Navigation, sehende Tastaturnutzende gehen also leer aus.

Skip-Link: Blöcke überspringen nach WCAG 2.4.1

Das Wichtigste in Kürze

Was WCAG 2.4.1 verlangt

Das komplette Rezept

Das CSS: versteckt, aber fokussierbar

Das Sprungziel: `id` plus `tabindex="-1"`

Mehrere Sprungziele

Sonderfälle: Sticky-Header und Single-Page-Apps

So testest du es

Häufiger Fehler in der Praxis

Häufige Fragen

Reichen Landmarks statt eines Skip-Links?

Verwandte Themen

Das Praxishandbuch für sauberes, zugängliches Web

Wohin dürfen wir den Link schicken?

Fast geschafft!

Darf ich anonym mitzählen?

Das Wichtigste in Kürze

Was WCAG 2.4.1 verlangt

Das komplette Rezept

Das CSS: versteckt, aber fokussierbar

Das Sprungziel: id plus tabindex="-1"

Mehrere Sprungziele

Skip-Link oder Landmarks?

Sonderfälle: Sticky-Header und Single-Page-Apps

So testest du es

Häufiger Fehler in der Praxis

Häufige Fragen

Ist ein Skip-Link Pflicht nach WCAG und BFSG?

Muss der Skip-Link immer sichtbar sein?

Warum springt mein Skip-Link nicht zum Inhalt?

Reichen Landmarks statt eines Skip-Links?

Verwandte Themen

Darf ich anonym mitzählen?

Das Sprungziel: `id` plus `tabindex="-1"`