Tastatur- & Switch-Bedienung: das Web ohne Maus

Die Tastatur ist die gemeinsame Schnittstelle fast aller Hilfstechnik: Screenreader, Switch-Systeme, Mundmäuse, Eye-Tracking und die meisten Sprachsteuerungen erzeugen darunter Tastaturereignisse – fokussieren, aktivieren, weiterspringen. Wer die Tastaturbedienung sauber unterstützt, hat deshalb nicht eine Nutzergruppe bedient, sondern das Fundament für ein halbes Dutzend gelegt; wer sie außer Kraft setzt, sperrt alle gleichzeitig aus.

Das Wichtigste in Kürze

• Alle Funktionen müssen ohne Maus erreichbar sein – das verlangt WCAG 2.1.1 „Tastatur“ auf Stufe A und damit die schärfste Konformitätsstufe überhaupt.
• Ein <div onclick> ist für die Tastatur nicht vorhanden: kein Fokus, keine Rolle, keine Aktivierung per Enter oder Leertaste. Das richtige Element löst das ohne eine Zeile JavaScript.
• Switch-Nutzer bedienen den Rechner mit einem oder wenigen Tastern. Beim Scanning wandert eine Markierung automatisch durch die interaktiven Elemente; der Taster wählt aus. Jeder überflüssige Tab-Stopp kostet dabei Sekunden, nicht Millisekunden.
• Grobe Rechnung: 40 Links im Kopfbereich, Scan-Intervall 1,5 Sekunden – das sind rund 60 Sekunden bis zum ersten Inhalt. Ein Skip-Link macht daraus zwei.
• Die Konventionen sind vereinbart, nicht erfunden: Tab wechselt zwischen Komponenten, Pfeiltasten bewegen innerhalb einer Komponente, Enter aktiviert Links und Buttons, die Leertaste nur Buttons und Checkboxen, Esc bricht ab.
• Der Fokus muss sichtbar sein (2.4.7, AA) und darf nicht von Sticky-Headern oder Bannern verdeckt werden (2.4.11, neu in WCAG 2.2).
• Es gibt kein „Switch-HTML“: Switch-Systeme setzen auf derselben Schnittstelle auf wie die Tastatur. Wer den Tastatur-Durchlauf besteht und Wege kurz hält, hat Switch-Nutzer automatisch mitbedient.
• Der Test kostet nichts und dauert fünf Minuten: Maus weglegen, Tab drücken, den wichtigsten Ablauf durchspielen.

Wer ohne Maus arbeitet

• Menschen mit motorischen Einschränkungen. Tremor, Spastik, Lähmung, Schmerzen oder eine Sehnenscheidenentzündung machen das Zielen mit der Maus unmöglich oder quälend. Tab, Enter und Pfeiltasten dagegen sind binäre Ereignisse: getroffen oder nicht, kein Millimeter dazwischen.
• Blinde Nutzer. Ohne Sicht kein Zeigen – die Screenreader-Navigation läuft am Desktop vollständig über die Tastatur, inklusive der Schnelltasten im Lesemodus.
• Switch-Nutzer. Menschen mit sehr stark eingeschränkter Motorik – etwa nach einem Schlaganfall, bei ALS, Cerebralparese oder Querschnittlähmung – bedienen Geräte über Taster (Switches). Ausgelöst wird per Hand, Kopf, Knie, Fuß, Wange, durch Saugen und Blasen oder über einen Muskelsensor.
• Sprachsteuerungs-Nutzer. Dragon, Voice Control und Voice Access erzeugen im Hintergrund Tastatur- und Klickereignisse – Details unter Sprachsteuerung.
• Power-User. Entwicklerinnen, Sachbearbeiter, Vielschreiber. Für sie ist die Tastatur kein Hilfsmittel, sondern schlicht schneller – und sie melden Tastaturfehler als Erste.

Wie Switch-Bedienung wirklich abläuft

Beide großen Mobilsysteme haben Switch-Unterstützung fest eingebaut: bei Apple als Schaltersteuerung (Switch Control), bei Android als Schalterzugriff (Switch Access). Am Desktop übernimmt spezialisierte Software dieselbe Aufgabe. Das Grundprinzip ist überall gleich und heißt Scanning.

Automatisches Scanning (ein Taster): Die Markierung wandert von selbst weiter, meist im Abstand von ein bis zwei Sekunden. Ein Druck wählt das gerade markierte Element aus. Verpasst man den Moment, läuft der Durchgang von vorn.

Manuelles oder Schritt-Scanning (zwei oder mehr Taster): Ein Taster springt weiter, einer bestätigt. Schneller, aber jeder Schritt kostet eine bewusste Bewegung – bei schwacher Muskulatur ist auch das erschöpfend.

Punkt-Scanning (Zeigermodus): Ein Fadenkreuz fährt erst waagerecht, dann senkrecht über den Bildschirm, um Positionen zu treffen, die anders nicht erreichbar sind. Das ist der Notausgang für Oberflächen, die keinen Tastaturfokus anbieten – langsam und fehleranfällig.

Rechne einmal mit: Eine Seite mit Logo, sechs Menüpunkten, Sprachumschalter, Suchfeld und Warenkorb-Link hat zehn Tab-Stopps vor dem ersten Inhalt. Bei 1,5 Sekunden Scan-Intervall sind das 15 Sekunden – auf jeder Unterseite. Wer dann noch dreimal durch einen Cookie-Dialog muss, ist bei einer Minute, bevor überhaupt etwas Inhaltliches passiert. Deshalb wiegt hier alles doppelt, was Wege kürzt:

• Ein Skip-Link spart pro Seitenaufruf Dutzende Scan-Schritte (WCAG 2.4.1).
• Eine logische Fokus-Reihenfolge verhindert, dass das Ziel erst am Ende des Durchlaufs „dran“ ist.
• Keine harten Zeitlimits: Ein 15-Minuten-Timeout im Bestellprozess ist für Scanning-Nutzer kein Puffer, sondern eine Sperre.
• Große Trefferflächen – 24 × 24 CSS-Pixel als Untergrenze – helfen auch beim Punkt-Scanning und bei Kopfmaus-Nutzung.

Die Konventionen sind vereinbart, nicht erfunden

Diese Erwartungen stammen aus dem ARIA Authoring Practices Guide des W3C und aus dreißig Jahren Desktop-Software. Eigene Erfindungen – „Doppel-Tab öffnet das Untermenü“ – verwirren genau die Menschen, die auf Verlässlichkeit angewiesen sind. Und das Beste: Wer nichts erfindet, kriegt die Konventionen geschenkt, weil native HTML-Elemente sie schon mitbringen.

Die vier Grundregeln – und was ihr Bruch kostet

Vier Sätze beschreiben so ziemlich alles, was diese Nutzung braucht. Das Bemerkenswerte daran ist nicht die Regel selbst, sondern der Preis, den ihr Bruch verlangt – und der ist bei Switch-Bedienung ein anderer als bei geübter Tastaturnutzung.

1. Alles ist erreichbar. Ein div mit Klick-Handler existiert für die Tastatur nicht. Für einen Power-User heißt das: Er greift genervt zur Maus. Für jemanden, der keine Maus bedienen kann, heißt es: Die Funktion gibt es nicht – nicht langsamer, nicht umständlicher, sondern gar nicht. Der Ausweg ist kein ARIA-Nachbau, sondern das passende Element; warum, steht unter Buttons vs. Links und in der ersten Regel von ARIA.

2. Nichts hält fest. Aus jedem Bereich muss ein Weg heraus führen (2.1.2 Keine Tastaturfalle). Die Klassiker sind ein Modal, das Esc nicht kennt, ein eingebetteter Player, der Tab abfängt, und ein Cookie-Banner ohne erreichbare Ablehnen-Schaltfläche. Eine Tastaturnutzerin lädt die Seite neu und ärgert sich. Wer über Scanning bedient, hat unter Umständen keinen Weg zur Adressleiste – die Falle ist dann eine echte.

3. Man sieht, wo man ist. Ohne sichtbaren Fokus wird Bedienung zum Raten. Beim automatischen Scanning ist das besonders bitter, weil die Markierung von selbst weiterwandert: Wer nicht sieht, wo sie gerade steht, drückt entweder zu früh oder verpasst den Moment und wartet einen kompletten Durchlauf ab. Wie ein Fokusring aussieht, der das aushält, steht unter Tastaturbedienung & sichtbarer Fokus.

4. Die Reihenfolge ergibt Sinn. Der Fokus folgt der Lesereihenfolge (2.4.3). Springt er stattdessen kreuz und quer, kostet das den Power-User Aufmerksamkeit – und den Scanning-Nutzer Sekunden pro Sprung, weil er jede falsche Station komplett abwarten muss. Passt die visuelle Anordnung nicht zur Reihenfolge im Quelltext, gehört der Quelltext sortiert; tabindex mit positiven Werten verschiebt das Problem nur an eine unübersichtlichere Stelle.

Die eine Regel, die nur hier gilt

Bei Tastaturbedienung ist ein Umweg lästig. Bei Switch-Bedienung ist ein Umweg eine Kostenrechnung. Deshalb steht in dieser Nutzergruppe ein Punkt weit oben, der sonst als Feinschliff gilt: Wege dürfen sich nicht ohne Anlass verlängern.

Zwei Beispiele, die in Audits selten auffallen, hier aber durchschlagen. Eine Navigation, die jeden Menüpunkt und jeden Untermenüpunkt einzeln in die Tab-Folge legt, statt das Untermenü einzuklappen, verdoppelt den Scan-Durchlauf auf jeder Seite. Und ein Bestellprozess, der Adresse, Versand und Zahlung auf drei Seiten verteilt, verdreifacht den Weg durch Kopfzeile und Navigation – es sei denn, jede Etappe setzt den Fokus dorthin, wo weitergearbeitet wird. Genau das leisten mehrstufige Formulare, wenn sie sauber gebaut sind.

So testest du es

1. Maus weglegen. Nicht ausstecken, einfach nicht anfassen. Lade die Startseite und drücke Tab.
2. Zähle die Stopps bis zum Hauptinhalt. Mehr als fünf? Dann fehlt ein Skip-Link oder die Navigation ist zu granular ausgezeichnet.
3. Beobachte den Ring. Ist bei jedem Stopp sichtbar, wo du bist? Verschwindet er unter einem Sticky-Header, wenn du weiter unten ankommst?
4. Spiele den wichtigsten Ablauf durch – Suche, Filter, Warenkorb, Formular absenden. Nur Tastatur, bis zum Ende. Was du nicht schaffst, schafft auch niemand mit Switch.
5. Öffne jedes Overlay und schließe es mit Esc. Landet der Fokus danach dort, wo er vorher war?
6. Teste eine Komponente mit Pfeiltasten – Tabs, Radiogruppe, Custom-Select. Bewegen die Pfeile innerhalb, oder springt Tab durch jeden einzelnen Eintrag?
7. Simuliere Scanning, wenn du magst: Tab nur alle zwei Sekunden drücken und dabei die Zeit stoppen. Der Effekt ist eindrücklicher, als jede Zahl es beschreibt.

Häufiger Fehler in der Praxis

Der Fokus verschwindet nach dem Schließen. Ein Dialog geht zu, und der Fokus landet am Anfang des <body>. Für Sehende kaum bemerkbar, für Tastaturnutzer ein Komplettverlust der Position – vor allem, wenn der Dialog aus einem Formular heraus geöffnet wurde. Der Fokus gehört zurück auf das auslösende Element.

Sticky-Header verdeckt den Zielbereich. Der Sprunglink funktioniert, das Ziel liegt aber unter der fixierten Kopfzeile. Genau dafür gibt es 2.4.11 Fokus nicht verdeckt; technisch löst es meist scroll-padding-top am html-Element.

Hover-only-Navigation. Ein Mega-Menü, das nur auf den Mauszeiger reagiert, existiert für Tastatur- und Switch-Nutzung nicht. Wer so bedient, erfährt nie, was die Website überhaupt anbietet.

Leere Links und Buttons. In der WebAIM Million (Februar 2026) haben 46,3 % der Startseiten Links ohne erkennbaren Text und 30,6 % Buttons ohne Namen. Die sind per Tab erreichbar und trotzdem unbedienbar: Der Fokus steht auf etwas, das keinen Namen hat – der Screenreader sagt nur „Link“. Die Ursache ist fast immer ein Icon ohne Textalternative.

Tastaturbedienbarkeit einmal geprüft, dann nie wieder. Sie geht typischerweise bei einem neuen Karussell, einem Chat-Widget oder einem Consent-Tool von Dritten kaputt. Fremde Skripte sind der häufigste Grund, warum eine vorher saubere Seite plötzlich eine Tastaturfalle hat.

Häufige Fragen

Sieht man Switch-Nutzern ihre Anforderungen im Code an?

Nein – und das ist die Pointe. Es gibt kein „Switch-HTML“ und kein spezielles Attribut. Switch-Systeme setzen auf derselben Fokus- und Aktivierungsschnittstelle auf wie die Tastatur. Wer den Tastatur-Durchlauf besteht, Wege kurz hält und keine Zeitlimits setzt, hat Switch-Nutzer automatisch mitbedient.

Warum erreiche ich manche Elemente mit Tab nicht?

Weil sie keine nativen interaktiven Elemente sind. Ein <div onclick> oder ein <span> mit Klick-Handler ist für die Tastatur Luft: Nur Links, Buttons, Formularfelder und Elemente mit tabindex="0" bekommen Fokus. Die Lösung ist fast immer das richtige Element statt ein Nachbau aus tabindex und Key-Handlern.

Ist tabindex="3" eine Lösung für eine unlogische Reihenfolge?

Nein, es verschärft das Problem. Positive Werte bilden eine eigene, vorgezogene Reihenfolge über die ganze Seite hinweg; ein einziger Wert kippt den gesamten Durchlauf. Sinnvoll sind nur tabindex="0" (natürliche Reihenfolge) und tabindex="-1" (programmatisch fokussierbar, nicht per Tab erreichbar).

Reicht es, wenn die Seite mit Tab durchlaufen werden kann?

Nein. Erreichbarkeit ist die halbe Miete – dazu kommen sichtbarer Fokus, sinnvolle Reihenfolge, kein Einsperren und eine Bedienung, die den Konventionen folgt. Eine Seite, die 200 Tab-Stopps in zufälliger Reihenfolge anbietet, erfüllt 2.1.1 und ist trotzdem unbenutzbar.

Muss ich eigene Tastenkürzel anbieten?

Nein, und wenn du welche anbietest, gelten Regeln. Einzelne Buchstabentasten als Kürzel – wie „s“ für Suche – kollidieren mit Screenreader-Schnelltasten und mit Spracheingabe. WCAG 2.1.4 verlangt deshalb, dass sie abschaltbar, umbelegbar oder nur bei Fokus aktiv sind.

Verwandte Themen

• Motorische Einschränkungen – wer aus welchen Gründen ohne Maus arbeitet
• Sprachsteuerung – warum sichtbare Beschriftungen zum zugänglichen Namen passen müssen
• Wie Screenreader-Nutzer surfen – Tastaturnavigation aus der anderen Perspektive
• Tastaturbedienung & sichtbarer Fokus – die Praxisseite mit CSS-Rezepten
• Skip-Links – die günstigste Maßnahme mit der größten Wirkung
• Dialoge und Modals – Fokus-Falle, Fokus-Rückgabe und Esc

Quellen

• Understanding SC 2.1.1 Keyboard (W3C – Anforderung und Ausnahmen zur Tastaturbedienbarkeit)
• ARIA Authoring Practices Guide: Patterns (W3C – erwartete Tastenbelegung je Komponente)
• Tastaturbedienung (Bundesfachstelle Barrierefreiheit/BFIT-Bund – Handreichung für Webauftritte und Apps)
• Schaltersteuerung auf dem iPhone (Apple – Scanning-Verfahren und Tastertypen)
• The WebAIM Million (WebAIM, Februar 2026 – Anteil leerer Links und Buttons)