Praxis

Tastaturbedienung: Was Pflicht ist und was empfohlen

Tastaturzugänglichkeit ist eines der ältesten und wichtigsten Themen der digitalen Barrierefreiheit – und gleichzeitig eines der am häufigsten missverstandenen. Dieser Artikel trennt klar, was die WCAG verbindlich fordert und was darüber hinaus sinnvolle Best Practice ist.

  • 11 Minuten Lesezeit
  • Stand: Mai 2026

Wer ist auf Tastaturbedienung angewiesen?

Die häufigste Annahme ist: „Tastaturbedienung ist für blinde Menschen mit Screenreader." Das stimmt – und greift gleichzeitig viel zu kurz. In der Realität ist die Gruppe sehr viel größer und heterogener:

  • Menschen mit motorischen Einschränkungen, die keine Maus präzise steuern können
  • Menschen mit Tremor, die Mausbewegungen nicht zuverlässig ausführen
  • Nutzer:innen von Sprachsteuerung, die Befehle wie „klick Anmelden" einsetzen
  • Menschen mit Sehbehinderung oder Blindheit, die einen Screenreader nutzen
  • Power-User:innen, die effizient per Tab und Enter durch Formulare arbeiten
  • Vorübergehend Eingeschränkte: Maus defekt, Hand im Gips, kein Touchpad zur Hand

Eine Website, die nur mit der Maus funktioniert, schließt damit eine Vielzahl von Menschen aus – nicht nur eine kleine Spezialgruppe. Das macht Tastaturbedienung zum Fundament digitaler Barrierefreiheit. Sie ist nicht verhandelbar.

Pflicht und Empfehlung im Überblick

Die WCAG unterscheidet zwischen verbindlichen Erfolgskriterien (mit Stufen A, AA, AAA) und Techniken, die zur Umsetzung empfohlen, aber nicht verpflichtend sind. Für Tastaturbedienung sieht die Aufteilung so aus:

WCAG-Pflicht (A & AA)
  • Alle Funktionen per Tastatur erreichbar 2.1.1
  • Keine Tastaturfallen 2.1.2
  • Fokus sichtbar bei Tastaturnutzung 2.4.7
  • Fokus nicht durch andere Elemente verdeckt 2.4.11 (WCAG 2.2)
  • Logische Fokus-Reihenfolge 2.4.3
Best Practice
  • Skip-Link zum Hauptinhalt anbieten
  • Fokus-Stil bewusst gestalten(3:1 Kontrast, 2 px Rand)
  • scroll-padding bei sticky Headern setzen
  • :focus-visible statt :focus verwenden
  • Custom-Components mit Pfeiltasten erweitern (ARIA-Patterns)

Pflicht: Volle Tastaturbedienbarkeit

2.1.1
Tastatur Alle Funktionen sind per Tastatur ohne spezielle Zeitvorgaben erreichbar.
A

Jede Funktion, die mit der Maus ausgelöst werden kann, muss auch per Tastatur ausgelöst werden können – ohne Einschränkungen und ohne präzises Timing. Das umfasst Buttons, Links, Formularfelder, Menüs, Modals, Drag-and-Drop-Elemente und alles dazwischen.

In der Praxis funktioniert das mit diesen Tasten:

Tab vorwärts Shift + Tab rückwärts Enter aktivieren Leertaste Buttons / Checkboxen Pfeiltasten in Menüs / Radio-Gruppen Esc Modal schließen

Wer native HTML-Elemente verwendet ( <button> , <a href> , <input> , <select> ), bekommt all das automatisch. Probleme entstehen vor allem dort, wo Entwickler:innen eigene Komponenten bauen – etwa mit <div onclick="..."> .

Nicht tastaturzugänglich
Ein <div> mit Klick-Handler – per Maus nutzbar, per Tastatur unsichtbar. Kein Fokus, kein Enter, keine Funktion. <div onclick="submit()">Senden</div>
Tastaturzugänglich
Ein nativer Button – automatisch fokussierbar, mit Enter und Leertaste bedienbar. <button type="submit">Senden</button>

Pflicht: Keine Tastaturfallen

2.1.2
Keine Tastaturfalle Der Tastaturfokus kann jeden Bereich verlassen, in den er hineingelangt ist.
A

Eine Tastaturfalle entsteht, wenn der Fokus in eine Komponente hineinwandert, aber nicht mehr herauskommt. Klassische Beispiele sind eingebettete Widgets (Karten, Video-Player, eingebettete PDFs) oder schlecht programmierte Modals, die den Fokus „gefangennehmen", ohne ein Esc oder Schließen-Button anzubieten.

Pflicht: Sichtbarer Fokus

2.4.7
Fokus sichtbar Jede fokussierbare Komponente hat im fokussierten Zustand einen sichtbaren Indikator.
AA

Wer per Tab navigiert, muss sehen, wo der Fokus gerade ist. Browser bringen Standard-Fokus-Indikatoren mit – dünne blaue oder schwarze Outlines. Diese standardmäßig sichtbaren Markierungen zu entfernen, ohne sie durch einen eigenen Stil zu ersetzen, ist eine der häufigsten Barrieren überhaupt.

CSS 
 /* NIEMALS so – entfernt jeden Fokus ohne Ersatz */
*:focus { outline: none; }
button { outline: none; }
/* Sondern entweder den Browser-Standard belassen,
   oder durch einen eigenen, sichtbaren Stil ersetzen: */
:focus-visible {
  outline: 2px solid #DB043B;
  outline-offset: 3px;
  border-radius: 2px;
}

Pflicht: Fokus nicht verdeckt

2.4.11
Fokus nicht verdeckt (Minimum) Fokussierte Komponenten dürfen nicht vollständig durch andere Inhalte verdeckt sein.
AA

Neu in WCAG 2.2: Ein sichtbarer Fokus reicht nicht, er muss auch tatsächlich auf dem Bildschirm bleiben. Bei sticky Headern, Cookie-Bannern oder schwebenden Hilfe-Buttons kann der Fokus sonst hinter diese Elemente wandern – die Nutzer:in tippt Tab, aber sieht nicht, wo sie ist.

Die technische Lösung ist meist eine Zeile CSS:

CSS 
 /* Höhe des sticky Headers als Scroll-Offset setzen,
   damit beim Tab-Sprung der Fokus nicht verdeckt landet */
html {
  scroll-padding-top: 80px;
}

Empfehlung: Skip-Link zum Inhalt

Ein Skip-Link erscheint, sobald per Tab fokussiert, ganz am Anfang der Seite. Er erlaubt es Tastatur-Nutzer:innen, die Hauptnavigation zu überspringen und direkt zum Inhalt zu springen. Auf Seiten mit langer Navigation spart das pro Aufruf 15 bis 30 Tab-Klicks.

Skip-Links sind keine explizite WCAG-Pflicht, helfen aber, das verwandte Kriterium 2.4.1 „Bypass Blocks" zu erfüllen – wenn keine anderen Mechanismen zum Überspringen vorhanden sind.

HTML + CSS 
 <!-- Direkt nach dem <body>-Tag -->
<a class="skip-link" href="#main">Zum Inhalt springen</a>
<!-- ... -->
<main id="main">...</main>
/* CSS: versteckt bis fokussiert */
.skip-link {
  position: absolute;
  top: -40px; left: 0;
  background: #0E142E;
  color: #fff;
  padding: 10px 18px;
  z-index: 100;
}
.skip-link:focus { top: 0; }

Empfehlung: Fokus-Indikator bewusst gestalten

Die Browser-Standard-Outline erfüllt die Pflicht aus 2.4.7 in der Regel. Eine bewusst gestaltete Fokus-Markierung wirkt aber professioneller und kann gleichzeitig die strengeren AAA-Kriterien 2.4.13 (Erscheinungsbild des Fokus) vorwegnehmen:

  • Mindestens 2 CSS-Pixel breit am Umfang des Elements
  • Kontrastverhältnis von mindestens 3:1 zwischen fokussiertem und nicht-fokussiertem Zustand
  • Outline-Offset von 2–3 px, damit der Indikator das Element umrahmt statt überlagert
  • :focus-visible statt :focus , damit Maus-Klicks keinen Tab-Ring auslösen

Empfehlung: Logische Fokus-Reihenfolge

2.4.3
Fokus-Reihenfolge Die Tab-Reihenfolge folgt der inhaltlichen Logik der Seite.
A

Strenggenommen ist die Fokus-Reihenfolge Pflicht – die Empfehlung ist hier: nicht eingreifen. Die HTML-Reihenfolge im DOM ist standardmäßig auch die Tab-Reihenfolge. Wer mit tabindex -Werten wie tabindex="5" eigene Reihenfolgen erzwingen will, baut sich fast immer eine Barriere.

  • tabindex="0" macht ein Nicht-Standard-Element fokussierbar (OK)
  • tabindex="-1" entfernt es aus der Tab-Reihenfolge (OK, z.B. für Modals)
  • tabindex="1" oder höher: vermeiden. Erzeugt Chaos im Zusammenspiel mit nativen Elementen.

In 5 Minuten selbst testen

Tastaturzugänglichkeit lässt sich ohne jedes Tool prüfen – ein Browser und eine Tastatur reichen. Diese vier Schritte decken die häufigsten Probleme ab:

  1. Maus weglegen. Klingt banal, ist aber der wichtigste Schritt. Die Hand sollte die Maus während des Tests nicht berühren.
  2. Mit Tab durch die Seite. Tab und Shift+Tab. Folgt der Fokus einer logischen Reihenfolge? Ist immer sichtbar, wo der Fokus ist? Verschwindet er hinter sticky Elementen?
  3. Alle interaktiven Elemente erreichen. Jeder Button, jedes Menü, jedes Formular, jedes Modal. Auch eingebettete Karten, Videos, PDFs. Funktioniert jedes Element mit Enter oder Leertaste?
  4. Hineinkommen, herauskommen. Bei jedem Modal, Dropdown und Widget: Komme ich per Tab hinein? Komme ich auch wieder heraus? Schließt sich das Modal mit Esc?