Tastatur-Bedienbarkeit: Alles muss ohne Maus gehen, und nichts darf zur Falle werden

Warum die Tastatur der Generalschlüssel ist

Eine Maus zu benutzen setzt voraus, dass du den Zeiger siehst und präzise führen kannst. Beides ist nicht selbstverständlich. Blinde Menschen navigieren mit Screenreader und Tastatur. Menschen mit motorischen Einschränkungen nutzen angepasste Tastaturen, Mundstäbe, Kopfzeiger oder Schalter-Systeme. Und Sprachsteuerungen wie auch viele Schalter-Systeme funktionieren intern als Tastatur-Emulatoren: Sie schicken Tastatureingaben an den Browser.

Das macht die Tastaturschnittstelle zum gemeinsamen Nenner fast aller Eingabehilfen. Funktioniert eine Webseite vollständig per Tastatur, funktioniert sie automatisch für eine ganze Familie von Hilfstechnologien. Funktioniert sie nicht, sperrst du all diese Werkzeuge gleichzeitig aus.

Kriterium 2.1.1: Alles geht auch ohne Maus

Das Erfolgskriterium 2.1.1 „Tastatur"(Stufe A) verlangt: Die gesamte Funktionalität des Inhalts ist über eine Tastaturschnittstelle bedienbar, ohne dass einzelne Tastenanschläge ein bestimmtes Timing erfordern. Jede Aktion, die mit der Maus geht, muss also auch mit Tasten gehen: Links folgen, Buttons aktivieren, Formulare ausfüllen, Menüs öffnen, Dialoge schließen, Schieberegler verstellen.

Zwei Details des Kriteriums werden oft übersehen:

• Kein Timing-Zwang: Eine Funktion, die nur ausgelöst wird, wenn Tasten innerhalb kurzer Zeit gedrückt werden, ist nicht konform. Menschen mit motorischen Einschränkungen tippen unterschiedlich schnell.
• Die Pfad-Ausnahme: Das Kriterium nimmt Funktionen aus, deren Eingabe vom Bewegungspfad abhängt, nicht nur von Start- und Endpunkt. Das klassische Beispiel ist freihändiges Zeichnen in einem Mal-Programm: Hier ist der Weg selbst die Information, eine Tastatur kann ihn nicht sinnvoll abbilden. Ein Drag-and-drop zum Umsortieren einer Liste fällt dagegen nicht unter die Ausnahme, denn dort zählt nur, wo das Element landet. Es braucht eine Tastatur-Alternative, etwa „Nach oben/unten verschieben"-Buttons.

Kriterium 2.1.2: Keine Tastaturfalle

Das Schwester-Kriterium 2.1.2 „Keine Tastaturfalle"(Stufe A) sichert den Rückweg: Wenn der Tastaturfokus auf ein Element bewegt werden kann, muss er sich auch wieder weg bewegen lassen, und zwar nur mit der Tastatur. Falls dafür mehr nötig ist als Tab , Umschalt + Tab oder die Pfeiltasten, müssen Nutzer:innen über den Ausweg informiert werden.

Eine Tastaturfalle entsteht, wenn ein Bereich den Fokus einfängt und nicht mehr loslässt: Die Maus käme problemlos heraus, die Tastatur nicht. Für reine Tastatur-Nutzer:innen ist damit die ganze Seite blockiert. Deshalb gilt eine Besonderheit: Schon eine einzige Falle macht die komplette Seite nicht-konform, auch wenn der betroffene Bereich für nichts anderes gebraucht wird, denn sie verhindert die Nutzung der gesamten restlichen Seite.

Klassische Falle in der Praxis: Ein modaler Dialog fängt den Fokus bewusst ein, das ist sogar gewollt und richtig, bietet aber keinen Tastatur-Weg zum Schließen. Korrekt ist: Esc schließt den Dialog und der Fokus kehrt zum auslösenden Element zurück. Ein bewusster Fokus-Kreis mit funktionierendem Ausgang ist keine Falle, ein Kreis ohne Ausgang schon.

Typische Stolperfallen im Web

Die meisten Tastatur-Probleme entstehen nicht aus bösem Willen, sondern aus Mustern, die mit der Maus getestet wurden und dort unauffällig funktionieren. Die häufigsten Fälle:

Praxis: semantisches HTML zuerst

Die gute Nachricht: Tastatur-Bedienbarkeit ist zum großen Teil geschenkt, wenn du native HTML-Elemente verwendest. <a href> , <button> , <input> , <select> und <dialog> sind von Haus aus fokussierbar und bringen ihr Tastaturverhalten mit. Probleme beginnen fast immer dort, wo generische Elemente interaktiv gemacht werden.

 <!-- ✕ Nur mit der Maus bedienbar: --> 
<div class="btn" onclick="speichern()">Speichern</div> <!-- ✓ Tastaturfähig ohne Zusatzaufwand: --> 
<button type="button" onclick="speichern()">Speichern</button>

Der click -Event ist dabei dein Freund: Trotz seines Namens ist er geräteunabhängig und feuert bei Buttons und Links auch dann, wenn sie per Enter oder Leertaste aktiviert werden. Wer stattdessen auf mousedown oder mouseup setzt, baut unbeabsichtigt eine Maus-Exklusivität ein.

Wenn es doch ein eigenes Widget sein muss, hilft die Kombination aus tabindex="0" , einer passenden ARIA-Rolle und einem Tastatur-Handler. Das Pattern dazu liefert der ARIA Authoring Practices Guide des W3C, inklusive der erwarteten Tastenbelegung pro Widget-Typ:

 // Nur wenn ein nativer <button> wirklich nicht möglich ist: 
<span role="button" tabindex="0" id="speichern">Speichern</span>
const el = document.getElementById('speichern');
el.addEventListener('click', speichern);
el.addEventListener('keydown', (e) => {
  if (e.key === 'Enter' || e.key === ' ') {
    e.preventDefault(); // verhindert Scrollen bei Leertaste 
speichern();
  }
});

Ein Mythos

Der 5-Minuten-Tastatur-Test

Den Grundzustand deiner Seite prüfst du ohne jedes Werkzeug, nur mit der Tastatur. Leg die Maus beiseite und geh diese Punkte durch:

Dieser Test ersetzt kein vollständiges Audit, findet aber erfahrungsgemäß die gravierendsten Operable-Probleme einer Seite in wenigen Minuten. Jede Falle und jede unerreichbare Funktion, die du hier entdeckst, ist ein direkter Verstoß gegen Stufe A.