Tastatur-Bedienbarkeit testen: Tab-Reihenfolge, Fokus-Styles und Skip-Links

Warum Tastatur-Bedienbarkeit entscheidend ist

Menschen mit motorischen Einschränkungen, blinde Nutzer mit Screenreadern und Power-User navigieren per Tastatur. Wenn ein Button, Link oder Formularfeld nicht per Tab erreichbar ist, ist die Webseite für diese Nutzer unbedienbar.

WCAG SC 2.1.1 (Keyboard) fordert: Alle Funktionen müssen per Tastatur erreichbar sein – ohne dass eine bestimmte Zeitvorgabe für einzelne Tastenanschläge erforderlich ist. Das bedeutet: Jeder Button, jeder Link, jedes Formularfeld und jedes interaktive Widget muss ohne Maus bedienbar sein.

Dazu kommen weitere relevante WCAG-Kriterien:

• SC 2.1.2 (No Keyboard Trap): Der Fokus darf nie in einem Element „gefangen“ werden, aus dem der Nutzer nicht per Tastatur herauskommt.
• SC 2.4.3 (Focus Order): Die Tab-Reihenfolge muss einer logischen Lese- und Bedienreihenfolge folgen.
• SC 2.4.7 (Focus Visible): Der aktuell fokussierte Element muss visuell erkennbar sein.
• SC 2.4.1 (Bypass Blocks): Es muss einen Mechanismus geben, um wiederkehrende Blöcke (z. B. Navigation) zu überspringen.

Hinweis: Dieser Artikel dient der allgemeinen Orientierung und ersetzt keine Rechtsberatung. Die genannten WCAG-Kriterien beziehen sich auf WCAG 2.1 Level AA, den vom BFSG geforderten Standard. Weitere Informationen finden Sie im Tastaturbedienung Glossar.

Der einfachste Test: Tab durchdrücken

Lade deine Webseite, klicke in die Adresszeile und drücke Tab. Beobachte bei jedem Tastendruck:

• Siehst du immer, wo der Fokus gerade ist (Fokus-Indikator)?
• Erreichst du alle Links, Buttons und Formularfelder?
• Kannst du das Menü per Enter öffnen?
• Ist die Reihenfolge logisch (von oben nach unten, links nach rechts)?
• Kommst du aus Modal-Dialogen per Escape wieder raus?
• Werden keine interaktiven Elemente übersprungen?

Wenn eine dieser Fragen mit Nein beantwortet wird, hast du einen BFSG-Verstoß. Mehr dazu, wie du deine Seite systematisch testen kannst, findest du in unserem Überblick über Barrierefreiheits-Test-Tools.

Tab-Reihenfolge verstehen und korrigieren

Die Tab-Reihenfolge (Focus Order, WCAG SC 2.4.3) bestimmt, in welcher Reihenfolge Elemente per Tab-Taste angesteuert werden. Standardmäßig folgt sie der Reihenfolge im HTML-Quellcode – und genau so sollte es bleiben.

Häufige Fehler:

• tabindex mit positivem Wert: tabindex="1", tabindex="5" etc. bringen die natürliche Reihenfolge durcheinander. Verwende ausschließlich tabindex="0" (in die natürliche Reihenfolge einfügen) oder tabindex="-1" (programmatisch fokussierbar, aber nicht per Tab).
• CSS-Layout vs. DOM-Reihenfolge: Wenn du mit order, float oder position: absolute Elemente visuell umordnest, bleibt die Tab-Reihenfolge beim DOM. Das kann Nutzer verwirren.
• Dynamisch eingefügte Elemente: Per JavaScript hinzugefügte Buttons oder Links landen am Ende des DOM – nicht unbedingt dort, wo sie visuell erscheinen.

Faustregel: Die visuelle Reihenfolge sollte der DOM-Reihenfolge entsprechen. Wenn du CSS-Tricks für das Layout nutzt, prüfe immer die Tab-Reihenfolge manuell.

Fokus-Styles: Sichtbar statt versteckt

Viele Designer entfernen den Fokus-Indikator (outline: none) weil er „hässlich“ aussieht. Das ist ein schwerwiegender Verstoß gegen WCAG SC 2.4.7 (Focus Visible).

Lösung: Entferne nie outline komplett. Gestalte stattdessen einen schönen Fokus-Style mit :focus-visible:

/* Schlecht: Fokus komplett entfernt */
*:focus {
  outline: none;  /* WCAG-Verstoß! */
}

/* Gut: Eigener Fokus-Style nur bei Tastatur-Navigation */
:focus-visible {
  outline: 3px solid #4A90D9;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Optional: Fokus-Style bei Mausklick unterdruecken */
:focus:not(:focus-visible) {
  outline: none;
}

Der Unterschied: :focus wird bei jedem Fokus-Ereignis ausglöst (auch Mausklick). :focus-visible wird nur angezeigt, wenn der Fokus per Tastatur gesetzt wird. So sehen Tastatur-Nutzer den Fokus, Maus-Nutzer werden nicht gestört.

Kontrast-Anforderung: Der Fokus-Indikator muss ein Kontrastverhältnis von mindestens 3:1 zum umgebenden Hintergrund haben (WCAG SC 1.4.11 Non-text Contrast).

Skip-Links implementieren

Ein Skip-Link (gemäß WCAG SC 2.4.1) erlaubt Tastatur-Nutzern, die Navigation zu überspringen und direkt zum Hauptinhalt zu springen. Ohne Skip-Link muss ein Screenreader-Nutzer bei jeder Seite erst durch die komplette Navigation tabben.

Implementierung:

<!-- Erster Element nach <body> -->
<a href="#main-content" class="skip-link">
  Zum Hauptinhalt springen
</a>

<nav>...</nav>

<main id="main-content">
  ...
</main>

/* CSS: Versteckt, wird bei Fokus sichtbar */
.skip-link {
  position: absolute;
  top: -100%;
  left: 16px;
  padding: 8px 16px;
  background: #1e40af;
  color: #fff;
  z-index: 9999;
  border-radius: 0 0 4px 4px;
}

.skip-link:focus {
  top: 0;
}

Die meisten CMS-Themes haben das eingebaut – prüfe ob es funktioniert, indem du Tab drückst, sobald die Seite geladen ist. Der Skip-Link sollte als erstes Element erscheinen.

Tastaturfallen vermeiden (SC 2.1.2)

Eine Tastaturfalle entsteht, wenn der Fokus in ein Element hineingeht, aber nicht mehr herauskommt. WCAG SC 2.1.2 (No Keyboard Trap) verbietet dies ausdrücklich.

Häufige Tastaturfallen:

• Modal-Dialoge: Der Fokus muss im Modal „gefangen“ werden (Focus Trapping), damit er nicht hinter das Modal wandert. Gleichzeitig muss das Modal per Escape schließbar sein.
• Eingebettete Widgets: Google Maps, YouTube-Videos und andere iFrames können den Fokus „schlucken“. Teste, ob du per Tab wieder herauskommst.
• Custom Dropdowns: Selbstgebaute Dropdown-Menüs ohne korrektes ARIA-Markup sind häufig Tastaturfallen.
• Autoplay-Karussells: Wenn der Fokus bei jedem Slide-Wechsel zurückgesetzt wird, kommt der Nutzer nicht weiter.

Custom-Widgets tastaturzugänglich machen

Native HTML-Elemente wie <button>, <a>, <input> und <select> sind von Haus aus tastaturzugänglich. Probleme entstehen bei Custom-Widgets – also selbstgebauten Komponenten aus <div> und <span>.

Checkliste für Custom-Widgets:

• Hat das Element eine role (z. B. role="button", role="tab", role="dialog")?
• Ist es fokussierbar (tabindex="0")?
• Reagiert es auf Enter und Space (bei Buttons)?
• Reagiert es auf Pfeiltasten (bei Tabs, Slidern, Menüs)?
• Hat es einen zugänglichen Namen (aria-label oder sichtbarer Text)?
• Werden Zustandsänderungen kommuniziert (aria-expanded, aria-selected)?

Beispiel – Custom Button richtig umgesetzt:

<!-- Schlecht: div als Button -->
<div class="btn" onclick="doSomething()">Klick mich</div>

<!-- Gut: Nativer Button -->
<button type="button" onclick="doSomething()">Klick mich</button>

<!-- Wenn div unvermeidbar: ARIA + Keyboard-Handler -->
<div role="button" tabindex="0"
     onclick="doSomething()"
     onkeydown="if(event.key==='Enter'||event.key===' ')doSomething()">
  Klick mich
</div>

Die goldene Regel: Verwende native HTML-Elemente, wann immer möglich. Ein <button> ist immer besser als ein <div role="button">. Mehr zu korrektem ARIA-Einsatz in unserem ARIA-Attribute-Leitfaden.

Testing-Workflow: Schritt für Schritt

Nutze diesen systematischen Workflow, um die Tastatur-Bedienbarkeit deiner Seite zu prüfen:

1. Maus weglegen. Ernsthaft – leg sie außer Reichweite.
2. Tab durch die gesamte Seite. Beginne in der Adresszeile. Notiere jedes Element, das du nicht erreichst oder das keinen sichtbaren Fokus hat.
3. Shift+Tab zurück. Prüfe, ob die Rückwärts-Navigation genauso funktioniert.
4. Enter/Space auf jedem interaktiven Element. Buttons, Links, Checkboxen, Dropdowns – alles muss aktivierbar sein.
5. Escape bei Overlays. Jedes Modal, Dropdown und Popup muss per Escape schließbar sein.
6. Pfeiltasten bei komplexen Widgets. Tabs, Slider, Datepicker, Autocomplete – diese erfordern Pfeiltasten-Navigation.
7. Skip-Link prüfen. Erster Tab-Stopp sollte der Skip-Link sein.
8. Formulare komplett durchspielen. Eingabe, Validierung, Absenden – alles per Tastatur.

Für einen automatisierten Erst-Check nutze den kostenlosen BFSG-Scanner – er erkennt viele Tastatur-Probleme automatisch. Für eine umfassende Übersicht aller Test-Tools schau dir unseren Tool-Überblick an.

Tastatur-Navigation und barrierefreie Menüs

Die Navigation ist der erste Kontaktpunkt für Tastatur-Nutzer. Eine nicht-tastaturzugängliche Navigation macht die gesamte Seite unbrauchbar.

Anforderungen an barrierefreie Menüs:

• Alle Menüpunkte per Tab erreichbar
• Untermenüs per Enter/Space öffnen, per Escape schließen
• Innerhalb von Untermenüs mit Pfeiltasten navigieren
• Hamburger-Button mit aria-expanded="true/false" und aria-controls
• Fokus-Management: Nach dem Öffnen eines Untermenüs den Fokus auf das erste Element setzen

Häufig gestellte Fragen