Warum Tastaturnavigation?
Tastaturnavigation ist kein Nischenthema. Sie betrifft (Quelle: netz-barrierefrei.de):
- Menschen mit motorischen Einschränkungen die keine Maus bedienen können
- Blinde Nutzer die einen Screenreader verwenden
- Menschen mit temporären Verletzungen (gebrochener Arm, Sehnenscheidenentzündung)
- Power-User die schneller per Tastatur navigieren als per Maus
- Nutzer von Spezialeingabegeräten (Mundmaus, Augensteuerung) die Tastatureingaben emulieren
Die wichtigsten Tasten
| Taste | Funktion |
|---|---|
| Tab | Zum nächsten interaktiven Element springen (Link, Button, Formularfeld) |
| Shift + Tab | Zum vorherigen interaktiven Element zurück |
| Enter | Link aufrufen oder Button aktivieren |
| Leertaste | Button aktivieren, Checkbox umschalten, Scrollbar bewegen |
| Escape | Dialog, Dropdown oder Overlay schließen |
| Pfeiltasten | Innerhalb von Menüs, Tabs, Radio-Buttons und Auswahlboxen navigieren |
Quelle: barrierefreies.design
WCAG-Anforderungen
2.1.1 Tastatur (A)
Alle Funktionen der Website müssen per Tastatur bedienbar sein. Ausnahme: Funktionen die eine bestimmte Eingabeart erfordern (z.B. Freihand-Zeichnen).
2.1.2 Keine Tastaturfalle (A)
Der Fokus darf nie in einem Element "gefangen" sein. Der Nutzer muss jedes Element per Tab oder Escape wieder verlassen können. Häufige Fallen: schlecht programmierte Modals, Video-Player, WYSIWYG-Editoren.
2.4.3 Fokus-Reihenfolge (A)
Die Reihenfolge in der Elemente den Fokus erhalten muss logisch sein und der visuellen Reihenfolge entsprechen. Die DOM-Reihenfolge bestimmt die Tab-Reihenfolge - CSS-Layoutänderungen (Flexbox order, Grid) ändern die DOM-Reihenfolge nicht.
2.4.7 Fokus sichtbar (AA)
Das aktuell fokussierte Element muss immer sichtbar hervorgehoben sein. Entfernen Sie nie den Browser-Standard-Fokus (outline: none) ohne einen gleichwertigen Ersatz. Mehr dazu: Farbkontraste und Barrierefreiheit.
2.4.11 Fokus nicht verdeckt (AA, neu in 2.2)
Sticky-Header, Cookie-Banner oder Chat-Widgets dürfen das fokussierte Element nicht vollständig verdecken.
Die häufigsten Fehler
outline: none ohne Ersatz
Der häufigste Fehler. Designer entfernen den "hässlichen" Fokusrahmen per CSS. Lösung: Ersetzen Sie ihn durch einen gut gestalteten, kontrastreichen Fokus-Indikator.
Interaktive Elemente als <div>
Ein <div onclick="..."> ist per Tastatur nicht erreichbar. Verwenden Sie stattdessen <button> für Aktionen und <a href> für Links. Native HTML-Elemente sind automatisch per Tastatur bedienbar (Quelle: initiative-barrierefreiheit.de).
tabindex="1" oder höher
Positive tabindex-Werte ändern die natürliche Tab-Reihenfolge und erzeugen Chaos. Verwenden Sie nur tabindex="0" (Element in den natürlichen Tab-Flow aufnehmen) oder tabindex="-1" (Element programmatisch fokussierbar machen, aber nicht per Tab erreichbar).
Modal ohne Fokus-Management
Wenn ein Modal-Dialog geöffnet wird, muss der Fokus in den Dialog wandern. Wenn er geschlossen wird, muss der Fokus zurück zum auslösenden Element. Innerhalb des Dialogs sollte der Fokus gefangen sein (Focus Trap) damit der Nutzer nicht versehentlich zum Hintergrund navigiert.
Skip-Link fehlt
Ohne Skip-Link muss ein Tastaturnutzer bei jeder Seite erst durch die gesamte Navigation tabben bevor er zum Inhalt kommt. WCAG 2.4.1 fordert einen Mechanismus zum Überspringen.
So testen Sie die Tastaturnavigation
- Maus weglegen - testen Sie ausschließlich per Tastatur
- Tab drücken - erreichen Sie alle Links, Buttons und Formularfelder?
- Fokus beobachten - sehen Sie immer wo Sie gerade sind?
- Enter/Leertaste testen - funktionieren alle Buttons und Links?
- Menüs testen - lassen sich Dropdowns öffnen und mit Escape schließen?
- Formulare ausfüllen - funktionieren alle Felder, Checkboxen, Select-Boxen?
- Modals/Dialoge testen - wandert der Fokus in den Dialog? Kommt man per Escape raus?
- Tastaturfallen suchen - gibt es ein Element aus dem man nicht mehr herauskommt?
Tastaturnavigation ist einer von 15 Prüfpunkten
Prüfen Sie Ihre Website auf alle Barrierefreiheits-Grundlagen.
ZUR CHECKLISTE