Anleitungen für Eigenes HTML / andere
Alle Funktionen per Tastatur bedienbar machen
WCAG 2.1.1, 2.1.2, 2.4.3, 4.1.2 · mittel · etwa 90 Minuten · Stand 08.11.2026
Worum es geht
Viele Menschen bedienen Websites ohne Maus. Sie nutzen Tab und Shift + Tab, um zwischen Elementen zu springen, Enter und Leertaste, um etwas auszulösen, Pfeiltasten in Auswahllisten und Escape zum Schließen. Häufige Probleme im Shop: Buttons, die eigentlich div-Elemente sind, Menüs, die sich nur beim Überfahren mit der Maus öffnen, und Popups, aus denen man mit der Tastatur nicht mehr herauskommt. WCAG 2.1.1 verlangt, dass alle Funktionen per Tastatur nutzbar sind, und 2.1.2, dass man den Fokus auch wieder wegbewegen kann.
Wen es betrifft
- Menschen mit motorischen Einschränkungen, die keine Maus nutzen können und mit Tastatur, Schaltern oder Sprachsteuerung arbeiten. Viele dieser Hilfsmittel simulieren Tastatureingaben.
- Blinde Menschen mit Screenreader, die ausschließlich die Tastatur verwenden.
- Menschen, die vorübergehend eingeschränkt sind, etwa mit gebrochenem Arm.
So behebst du es
Native HTML-Elemente verwenden.
<button>,<a href>,<input>und<select>sind von sich aus per Tastatur bedienbar und werden von Screenreadern richtig angesagt. Eindivmit Klick-Handler ist es nicht.Schlecht:
<div class="btn" onclick="inDenWarenkorb()">In den Warenkorb</div>Gut:
<button type="button" onclick="inDenWarenkorb()">In den Warenkorb</button>Faustregel: Führt etwas zu einer anderen Seite, ist es ein Link (
<a href>). Löst es eine Aktion auf derselben Seite aus, ist es ein Button.Kein positiver tabindex.
tabindex="1"oder höher verändert die Reihenfolge und führt fast immer zu Verwirrung. Die Tab-Reihenfolge soll der sichtbaren Reihenfolge folgen (2.4.3). Ordne lieber den HTML-Code richtig an.<!-- vermeiden --> <a href="/sale" tabindex="3">Sale</a> <!-- nur wenn wirklich nötig: in die normale Reihenfolge aufnehmen --> <div tabindex="0" role="region" aria-label="Produktbeschreibung">...</div>Menüs auch per Tastatur öffnen. Ein Untermenü, das nur bei
:hovererscheint, braucht einen Button zum Auf- und Zuklappen:<nav aria-label="Hauptmenü"> <ul> <li> <button type="button" aria-expanded="false" aria-controls="menu-kaffee"> Kaffee </button> <ul id="menu-kaffee" hidden> <li><a href="/kaffee/bohnen">Bohnen</a></li> <li><a href="/kaffee/gemahlen">Gemahlen</a></li> </ul> </li> </ul> </nav>document.querySelectorAll('nav button[aria-expanded]').forEach((btn) => { btn.addEventListener('click', () => { const offen = btn.getAttribute('aria-expanded') === 'true'; btn.setAttribute('aria-expanded', String(!offen)); document.getElementById(btn.getAttribute('aria-controls')).hidden = offen; }); });Keine Tastaturfallen. Popups, eingebettete Videos, Kartenwidgets oder Chatfenster müssen sich per Tastatur wieder verlassen oder schließen lassen. Für Dialoge eignet sich das native
<dialog>-Element mitshowModal(): Der Browser setzt den Fokus in den Dialog, und Escape schließt ihn.<dialog id="groessen"> <h2>Größentabelle</h2> <p>...</p> <button type="button" onclick="this.closest('dialog').close()">Schließen</button> </dialog> <button type="button" onclick="document.getElementById('groessen').showModal()"> Größentabelle öffnen </button>Scrollbare Bereiche erreichbar machen. Ein Bereich mit eigener Scrollleiste, der keine fokussierbaren Elemente enthält, braucht
tabindex="0"und einen Namen, damit man ihn mit den Pfeiltasten scrollen kann.Keine verschachtelten Bedienelemente. Ein Button in einem Link oder ein Link in einem Button verwirrt Tastatur und Screenreader. Trenne die Elemente.
Mausaktionen mit Alternative. Drag-and-drop, Bildzoom bei Mausbewegung oder Wischgesten brauchen zusätzlich eine Bedienung über Buttons.
So prüfst du es
- Maus beiseitelegen. Gehe einen kompletten Einkauf nur mit der Tastatur durch: Produkt suchen, Variante wählen, in den Warenkorb legen, zur Kasse gehen, Formular ausfüllen. Notiere jede Stelle, an der du nicht weiterkommst.
- Reihenfolge beobachten. Springt der Fokus in einer logischen Reihenfolge, von oben nach unten und von links nach rechts? Verschwindet er irgendwo?
- Fallen suchen. Öffne jedes Popup, jedes Menü und jedes eingebettete Element. Kommst du mit Tab, Shift + Tab oder Escape wieder heraus?
- Screenreader: Mit NVDA (Windows) oder VoiceOver (Mac) prüfst du, ob eigene Bedienelemente als Button, Link oder Auswahl angesagt werden und ob ihr Zustand stimmt, etwa "eingeklappt" oder "ausgeklappt".
- axe DevTools meldet unter anderem positive tabindex-Werte (
tabindex), nicht erreichbare scrollbare Bereiche (scrollable-region-focusable) und verschachtelte Bedienelemente (nested-interactive). Ob alles per Tastatur funktioniert, findet nur der manuelle Test heraus. - Accessibility Insights for Web: Die Funktion "Tab stops" zeigt die Tab-Reihenfolge als Linien über der Seite an.
Mehr dazu
- W3C: Understanding 2.1.1 Keyboard
- W3C: Understanding 2.1.2 No Keyboard Trap
- W3C: Understanding 2.4.3 Focus Order
- W3C: Understanding 4.1.2 Name, Role, Value
- W3C Technique G202: Tastaturbedienung für alle Funktionen
- W3C Technique SCR35: onclick mit Links und Buttons
- W3C ARIA Authoring Practices: Dialog (Modal) Pattern