---
title: "Tastatur"
url: "https://barrierefreihochzwei.de/de/wcag/2-1-1-tastatur"
language: "de"
description: "WCAG 2.1.1 verlangt, dass alle Funktionen einer Website per Tastatur bedienbar sind. Hier lernst du, worauf es ankommt und wie du eigene Komponenten testest."
published: "2025-01-01T08:00:00+01:00"
updated: "2026-10-15T09:41:59+02:00"
---

# Tastatur

Wenn jeder Klick auch ein Tastendruck sein kann.

- **Erfolgskriterium:** 2.1.1
- **Prinzip:** Bedienbar
- **Konformitätsstufe:** Level A
- **Erklärung beim W3C:** [www.w3.org/WAI/WCAG22/Understanding/keyb...](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html)

Erfolgskriterium 2.1.1

# 2.1.1 Tastatur

Level ABedienbar

Wenn jeder Klick auch ein Tastendruck sein kann.

## 1. Was ist das Ziel dieses Kriteriums?

Nicht alle können eine Maus benutzen – und das aus ganz unterschiedlichen Gründen. Blinde Menschen können einem Mauszeiger nicht folgen. Menschen mit motorischen Einschränkungen können präzise Mausbewegungen oft nur schwer kontrollieren. Wieder andere nutzen Hilfsmittel wie Spezialtastaturen, Schaltersteuerung oder Sprachsteuerung, die sich gegenüber der Website wie eine Tastatur verhalten.

Das Ziel von Erfolgskriterium 2.1.1 ist daher glasklar: Alles, was du mit der Maus machen kannst, muss auch über die Tastatur funktionieren. So können alle deine Website bedienen – unabhängig davon, welche Eingabemethode sie verwenden.

Kurz gesagt: Jede Funktion, jeder Button, jedes interaktive Element muss auch ohne Maus erreichbar und bedienbar sein.

## 2. Was fordert das Erfolgskriterium genau?

Die Anforderung ist eigentlich simpel, aber weitreichend: Alle Funktionen deiner Website müssen über eine Tastaturschnittstelle bedienbar sein – ohne dass bestimmte Zeitvorgaben für einzelne Tastenanschläge nötig sind.

**Konkret bedeutet das zum Beispiel:**

- Alle Links, Buttons und Formularelemente lassen sich per Tastatur erreichen (meist mit der Tab-Taste)
- Interaktive Elemente lassen sich per Tastatur auslösen, etwa mit Enter oder Leertaste
- Eigene Komponenten wie Menüs, Tabs oder Schieberegler sind vollständig per Tastatur bedienbar
- Drag-and-drop-Funktionen haben einen Tastaturweg (z. B. Buttons zum Verschieben oder ein Auswahlmenü)
- Niemand muss eine Taste exakt eine bestimmte Zeit gedrückt halten oder blitzschnell mehrfach drücken

Welche Tasten genau verwendet werden (z. B. Pfeiltasten in Menüs oder Escape zum Schließen von Dialogen), schreibt das Kriterium nicht vor – es sind aber bewährte Konventionen, an die sich Nutzer:innen gewöhnt haben.

**Eine wichtige Ausnahme gibt es:** Funktionen, die zwingend vom Bewegungspfad abhängen – wie freihändiges Zeichnen oder Aquarellmalen in einer Mal-App – müssen nicht per Tastatur bedienbar sein. Aber Achtung: Das bezieht sich auf die zugrunde liegende Funktion, nicht auf die Eingabetechnik. Texteingabe per Handschrift ist zum Beispiel keine Ausnahme, denn Text lässt sich auch tippen.

## 3. Warum ist das wichtig für Barrierefreiheit?

Stell dir vor, du surfst im Internet, aber deine Maus ist kaputt – frustrierend, oder? Für viele Menschen ist das Alltag. Blinde Menschen können den Mauszeiger nicht sehen, Menschen mit Tremor können ihn nicht präzise steuern, und Menschen mit Lähmungen nutzen oft alternative Eingabegeräte.

Tastaturbedienbarkeit schafft echte Teilhabe, weil sie:

- Blinden Menschen ermöglicht, mit Screenreadern alle Funktionen zu nutzen
- Menschen mit motorischen Einschränkungen den Einsatz alternativer Eingabegeräte erlaubt, die Tastatureingaben erzeugen
- Menschen mit Sprachsteuerung den Zugang erleichtert, da viele Sprachbefehle auf Tastaturbefehle abgebildet werden
- Menschen mit Sehbehinderungen das Navigieren ohne Suchen des Mauszeigers ermöglicht
- Menschen mit vorübergehenden Einschränkungen hilft (z. B. mit Gips am Arm)

Und nicht zuletzt: Viele Power-User arbeiten ohnehin lieber mit der Tastatur – sie sind damit oft schneller als mit der Maus.

## 4. So setzt du das Kriterium erfolgreich um

Die gute Nachricht: Native HTML-Elemente bringen Tastaturbedienung bereits mit. Probleme entstehen vor allem bei selbst gebauten Komponenten. Ein paar bewährte Praxis-Tipps:

**Die Grundregeln:**

- Verwende semantisches HTML: `<button>`, `<a href>`, `<input>`, `<select>` statt klickbarer `<div>`- oder `<span>`-Elemente
- Achte auf eine logische Fokus-Reihenfolge, die der visuellen Reihenfolge folgt (siehe [Fokus-Reihenfolge](https://barrierefreihochzwei.de/de/wcag/2-4-3-fokusreihenfolge))
- Sorge für sichtbare Fokusindikatoren – Nutzer:innen müssen sehen, wo sie gerade sind (siehe [Fokus sichtbar](https://barrierefreihochzwei.de/de/wcag/2-4-7-fokus-sichtbar))
- Biete Sprunglinks („Zum Inhalt springen“) für wiederkehrende Navigation
- Verstecke Funktionen nicht hinter reinen Hover-Effekten

**Für interaktive Elemente:**

- Buttons: per Enter und Leertaste auslösbar
- Links: per Enter auslösbar
- Formulare: per Tab navigierbar und ohne Maus absendbar
- Aufklappmenüs und Tabs: bewährt sind Pfeiltasten zur Auswahl und Enter zum Bestätigen
- Modale Dialoge: Fokus beim Öffnen in den Dialog setzen, beim Schließen zurück zum Auslöser; Escape zum Schließen ist üblich

**Technische Umsetzung:**

- Ein natives `<button>` löst das `click`-Ereignis auch bei Enter und Leertaste aus – du brauchst keine zusätzlichen Tastatur-Handler
- Wenn du doch eigene Elemente baust, brauchst du `tabindex="0"`, passende Tastatur-Handler (`keydown`) und eine passende Rolle wie `role="button"` – ARIA allein macht nichts bedienbar
- Setze `tabindex` sparsam ein und vermeide positive Werte – sie bringen die Reihenfolge durcheinander
- Für komplexe Widgets helfen die Muster der ARIA Authoring Practices Guide (APG) des W3C oder erprobte Bibliotheken wie React Aria

**So testest du:**

- Leg die Maus weg und bediene deine Seite nur mit Tab, Umschalt+Tab, Enter, Leertaste, Escape und Pfeiltasten
- Prüfe, ob du jede Funktion erreichst und auslösen kannst – und ob du immer siehst, wo der Fokus ist
- Teste ergänzend mit einem Screenreader wie NVDA (kostenlos für Windows) oder VoiceOver (macOS)

## 5. Warum dieses Erfolgskriterium für Unternehmen relevant ist

Tastaturbedienbarkeit ist kein nettes Extra – sie ist eine Grundvoraussetzung dafür, dass Menschen deine Website überhaupt nutzen können.

**1. Zielgruppe erweitern**

In Deutschland leben laut Destatis rund 7,9 Millionen schwerbehinderte Menschen. Dazu kommen Menschen mit vorübergehenden Einschränkungen, ältere Menschen und Power-User, die die Tastatur bevorzugen. Mit tastaturbedienbaren Websites schließt du niemanden aus.

**2. Produktivität steigern**

Auch deine eigenen Mitarbeiter:innen arbeiten mit guter Tastaturbedienung oft effizienter – besonders in datenintensiven Anwendungen. Eine durchdachte Tastaturnavigation macht Software schneller und angenehmer nutzbar.

**3. Technische Robustheit verbessern**

Tastaturbedienbarkeit geht Hand in Hand mit sauberem, semantischem Code. Das macht deine Website robuster für verschiedene Geräte und Hilfsmittel – und auch automatisierte Tests profitieren von eindeutigen, programmatisch erkennbaren Elementen.

**Und nicht zuletzt: rechtliche Anforderungen.** Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG), das den European Accessibility Act umsetzt, für viele Produkte und Dienstleistungen für Verbraucher:innen, etwa Online-Shops und Bankdienstleistungen. Technischer Maßstab ist die EN 301 549, die für Webinhalte auf WCAG 2.1 Level AA verweist – 2.1.1 gehört dazu. Öffentliche Stellen sind über die BITV 2.0 bzw. Landesrecht verpflichtet. Dieser Abschnitt informiert allgemein und ersetzt keine Rechtsberatung.

## 6. Das Erfolgskriterium im Wortlaut des W3C

> **Success Criterion 2.1.1 Keyboard (Level A)**
> 
> All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
> 
> **Note 1:** This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
> 
> **Note 2:** This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

Kurz gesagt: Alle Funktionen müssen per Tastatur ohne bestimmte Zeitvorgaben bedienbar sein – ausgenommen sind nur Funktionen, die zwingend vom Bewegungspfad abhängen.

**Offizielle Erklärung beim W3C**

Das W3C erklärt jedes Erfolgskriterium ausführlich – mit Absicht, Beispielen und Techniken (auf Englisch).

[Understanding 2.1.1](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html)

## Weitere Kriterien aus „Bedienbar“

 [  2.1.2 Level A ### Keine Tastaturfalle

Wenn der Ausgang fehlt.

 ](https://barrierefreihochzwei.de/de/wcag/2-1-2-keine-tastaturfalle) [  2.1.3 Level AAA ### Tastatur (keine Ausnahme)

Wenn wirklich alles per Tastatur gehen muss.

 ](https://barrierefreihochzwei.de/de/wcag/2-1-3-tastatur-keine-ausnahme) [  2.1.4 Level A ### Tastaturkürzel

Wenn einzelne Tasten zum Problem werden.

 ](https://barrierefreihochzwei.de/de/wcag/2-1-4-tastaturkuerzel)
