Tastaturnavigation: Warum sie für BFSG und WCAG entscheidend ist

64% der deutschen E-Commerce-Websites haben Tastaturnavigations-Barrieren, die Menschen mit motorischen Einschränkungen und Screenreader-Nutzer vom Zugang ausschließen^[1]. Tastaturzugänglichkeit ist nicht ein Kriterium unter vielen, sondern das Fundament der BFSG-Compliance: Wer eine Website nicht per Tastatur bedienen kann, kann sie gar nicht selbstständig nutzen.

Die vier WCAG-Kriterien für Tastaturzugänglichkeit

Das BFSG verlangt WCAG 2.1 Level AA. Vier Kriterien betreffen direkt die Tastaturnavigation^[2]:

Kriterium 2.1.1 und 2.1.2 sind Level A, also die strengste Kategorie. Verstöße hier bedeuten vollständigen Ausschluss für viele Nutzer.

Die 5 häufigsten Tastaturnavigations-Fehler

1. CSS outline: none entfernt den Fokus-Indikator

Der häufigste Fehler auf deutschen Websites. Aus ästhetischen Gründen wird der Browser-Standard-Fokusring entfernt:

/* FALSCH: Fokus komplett entfernen */
*:focus {
  outline: none;
}

/* RICHTIG: Fokus-Indikator gestalten statt entfernen */
*:focus-visible {
  outline: 3px solid #f97316;
  outline-offset: 2px;
  border-radius: 4px;
}

Die Lösung ist nicht, den Fokusring zu entfernen, sondern ihn so zu gestalten, dass er zum Design passt. Der Unterschied zwischen :focus und :focus-visible ist wichtig: :focus-visible zeigt den Fokusring nur bei Tastaturnavigation, nicht beim Mausklick.

2. Interaktive Elemente sind nicht per Tastatur erreichbar

Custom-Komponenten, die optisch wie Buttons aussehen, aber mit <div> oder <span> implementiert sind, sind standardmäßig nicht per Tastatur fokussierbar:

<!-- FALSCH: Kein nativer Button, nicht per Tastatur fokussierbar -->
<div class="btn" onclick="submit()">Absenden</div>

<!-- RICHTIG: Nativer Button ist automatisch fokussierbar -->
<button type="submit">Absenden</button>

<!-- RICHTIG: Falls div unvermeidbar, tabindex und Keyboard-Handler ergänzen -->
<div class="btn" tabindex="0" role="button"
     onclick="submit()"
     onkeydown="if(event.key==='Enter'||event.key===' ')submit()">
  Absenden
</div>

Bevorzugen Sie immer native HTML-Elemente (<button>, <a>, <input>). Sie sind automatisch fokussierbar und haben die richtigen ARIA-Rollen.

3. Keyboard Trap in Modals und Dialogen

Ein Modal-Fenster, das sich öffnet, aber nicht per Tastatur geschlossen werden kann, ist eine Tastaturfalle (WCAG 2.1.2). Korrekte Implementierung:

// Fokus ins Modal setzen, wenn es öffnet
modal.addEventListener('open', () => {
  const firstFocusable = modal.querySelector(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  firstFocusable?.focus();
});

// Escape-Taste schließt Modal
modal.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') closeModal();
});

// Fokus beim Schließen zurück zum auslösenden Element
modal.addEventListener('close', () => {
  triggerElement.focus();
});

Wenn das Modal geöffnet ist, muss der Fokus darin bleiben (Fokus-Falle bewusst für den Nutzer) und muss per Escape verlassen werden können.

4. Falsche Fokus-Reihenfolge durch CSS-Positionierung

Wenn CSS position: absolute oder Flexbox-Order verwendet wird, kann die visuelle Reihenfolge von der DOM-Reihenfolge abweichen. Screenreader und Tastaturnutzer folgen der DOM-Reihenfolge, was verwirrend ist:

/* PROBLEM: Visuell erscheint .main-content vor .sidebar,
   aber im DOM steht .sidebar zuerst */
.container {
  display: flex;
}

.main-content {
  order: 2; /* Visuell second */
}

.sidebar {
  order: 1; /* Visuell first, aber DOM-Reihenfolge: first */
}

Lösung: DOM-Reihenfolge und visuelle Reihenfolge angleichen, oder tabindex gezielt einsetzen.

5. JavaScript-Only-Interaktionen

Dropdown-Menüs, die nur auf mouseover reagieren, Akkordeons, die nur per Mausklick funktionieren, und Slider, die nur per Drag bedienbar sind: Alle müssen auch per Tastatur steuerbar sein.

// Dropdown: Maus UND Tastatur
navItem.addEventListener('mouseenter', openDropdown);
navItem.addEventListener('mouseleave', closeDropdown);
navItem.addEventListener('focus', openDropdown);    // Tastatur-Fokus
navItem.addEventListener('blur', closeDropdown);    // Fokus verlässt

// Pfeiltasten für Navigation innerhalb des Dropdowns
navItem.addEventListener('keydown', (e) => {
  if (e.key === 'ArrowDown') focusNextItem();
  if (e.key === 'ArrowUp') focusPrevItem();
  if (e.key === 'Escape') closeDropdown();
});

Skip-Link: Eine einfache Maßnahme mit großer Wirkung

Ein Skip-Link ist ein Link ganz oben auf der Seite, der Tastaturnutzern ermöglicht, die Hauptnavigation zu überspringen und direkt zum Hauptinhalt zu springen. Ohne Skip-Link müssen Nutzer bei jedem Seitenaufruf durch die gesamte Navigation tabben.

<!-- Am Anfang des body-Elements -->
<a href="#main-content"
   class="skip-link sr-only focus:not-sr-only focus:absolute focus:top-4 focus:left-4
          bg-orange-600 text-white px-4 py-2 rounded z-50">
  Zum Hauptinhalt springen
</a>

<!-- Hauptinhalt-Anker -->
<main id="main-content">
  <!-- Seiteninhalt -->
</main>

Der Skip-Link ist standardmäßig visuell versteckt (sr-only) und erscheint nur beim Fokus per Tastatur. Das ist eine saubere Lösung, die das Design nicht beeinträchtigt.

So testen Sie Tastaturnavigation in 10 Minuten

Legen Sie die Maus weg und testen Sie Ihre Website ausschließlich mit der Tastatur:

Prüffragen:

• Können Sie alle Funktionen ohne Maus erreichen?
• Sehen Sie immer, welches Element fokussiert ist?
• Gibt es Bereiche, aus denen Sie nicht wieder heraus-tabben können?
• Gibt es einen Skip-Link am Anfang der Seite?
• Öffnen und schließen sich Modals korrekt mit der Tastatur?

Checkliste: Tastaturnavigation

Häufig gestellte Fragen

Weiterführende Artikel:

• Screenreader-Test bestehen: 7 Sofortmaßnahmen
• BFSG Selbst-Audit: So prüfen Sie Ihre Website in 60 Minuten
• Mobile Barrierefreiheit: BFSG-Anforderungen für Apps und mobile Websites