Eine Website ohne Maus bedienen
Mit der Tastatur kannst du Links öffnen, Buttons auslösen und Formulare ausfüllen. Menschen, die eine Maus nicht sicher bedienen können, sind auf diese Möglichkeit angewiesen. Auch Hilfsmittel können Tastatureingaben an eine Website weitergeben. Das WCAG-Kriterium 2.1.1 „Tastatur“ beschreibt die Anforderung und ihre Ausnahme für Funktionen, bei denen der Bewegungspfad selbst entscheidend ist, etwa freihändiges Zeichnen.
Der Tastaturfokus zeigt, welches Element deine nächste Eingabe erhält. Wenn du mit Tab zu „Senden“ gehst, muss erkennbar sein, dass der Button den Fokus hat. Drückst du anschließend Enter oder die Leertaste, sollte er die zugehörige Aktion auslösen.
Reihenfolge und passende Tasten
Tab führt zum nächsten Tabstopp, Umschalt + Tab zum vorherigen. Die Reihenfolge folgt gewöhnlich der Elementreihenfolge im DOM, also der vom Browser aufgebauten Dokumentstruktur. Sie muss zur Bedeutung und Bedienung der Seite passen. Ein Formular sollte dich beispielsweise vom Namen zur E-Mail-Adresse und dann zum Absenden führen. Das WCAG-Kriterium 2.4.3 „Fokus-Reihenfolge“ verlangt eine Reihenfolge, die Verständnis und Bedienung erhält.
| Element oder Vorgang | Übliche Taste |
|---|---|
| Zum nächsten oder vorherigen Tabstopp wechseln | Tab oder Umschalt + Tab |
| Link öffnen | Enter |
| Button aktivieren | Enter oder Leertaste |
| Innerhalb einer passenden Auswahlgruppe navigieren | Pfeiltasten, abhängig vom Element |
| Einen Dialog schließen | Escape oder einen erreichbaren Schließen-Button betätigen |
Die W3C-Muster für Buttons und Links erklären deren Tastaturaktionen. Zusammengesetzte Elemente, etwa Registerkarten, haben zusätzliche Regeln. Innerhalb einer solchen Gruppe können Pfeiltasten übernehmen, während Tab die Gruppe verlässt.
Ein positiver tabindex, etwa tabindex="3", zieht ein Element vor die gewöhnlichen Tabstopps. Solche Werte machen die Reihenfolge schwer wartbar. Korrigiere möglichst die Dokumentreihenfolge. tabindex="0" nimmt ein Element an seiner DOM-Position in die Tabfolge auf; tabindex="-1" erlaubt gezieltes Fokussieren, ohne einen weiteren Tabstopp zu erzeugen. Die W3C-Hinweise zur Tastatursteuerung raten von positiven Werten ab. Ein positiver Wert allein beweist aber noch keinen WCAG-Verstoß.
Ein per Maus anklickbares <div> kann durch die Tabfolge unerreichbar bleiben. Verwende für Aktionen möglichst einen nativen <button>. Ein zusätzliches ARIA-Attribut programmiert keine Tastaturfunktion.
Den Fokus sichtbar halten
Ein Rahmen oder eine andere deutliche Markierung muss bei der Tastaturbedienung zeigen, welches Element fokussiert ist. Entfernst du den Browserrahmen mit outline: none, brauchst du eine geeignete Ersatzmarkierung. Das verlangt WCAG 2.4.7 „Fokus sichtbar“ auf Stufe AA.
WCAG 2.2 ergänzt auf Stufe AA 2.4.11 „Fokus nicht verdeckt (Minimum)“: Ein Element darf beim Erhalt des Fokus nicht vollständig durch Inhalte der Website verdeckt sein. Ein feststehender Cookiebanner kann zum Beispiel den gerade fokussierten Link überlagern. Die AA-Anforderung erlaubt teilweise verdeckte Elemente; als praktische Umsetzung solltest du sie möglichst vollständig sichtbar halten.
Wiederkehrende Navigation überspringen
Ein Sprunglink wie „Zum Inhalt springen“ führt direkt hinter die wiederkehrende Navigation. Er sollte früh in der Tabfolge stehen und spätestens beim Fokussieren sichtbar werden. Ein vereinfachtes Beispiel:
<a href="#main-content">Zum Inhalt springen</a>
<nav aria-label="Hauptnavigation">…</nav>
<main id="main-content" tabindex="-1">
<h1>Leistungen</h1>
</main>
Prüfe, ob du nach dem Aktivieren im Hauptinhalt weiterarbeiten kannst. Nur den sichtbaren Ausschnitt nach unten zu verschieben, während Tab wieder durch die Navigation führt, reicht dafür nicht. Sprunglinks sind eine mögliche Umsetzung von WCAG 2.4.1 „Blöcke umgehen“. Passende Seitenbereiche und Überschriften bieten Hilfsmitteln weitere Navigationswege.
Dialoge und Fokusfallen
In einem modalen Dialog bleibt die Tabfolge innerhalb des Dialogs, solange er geöffnet ist. Du musst ihn mit der Tastatur schließen können, etwa mit Escape oder „Abbrechen“. Danach kehrt der Fokus gewöhnlich zum auslösenden Element zurück. Wenn der Arbeitsablauf eine andere Stelle erfordert, erhält ein anderes passendes Element den Fokus. Das W3C-Muster für modale Dialoge beschreibt dieses Verhalten.
Eine Fokusfalle entsteht, wenn du einen Bereich mit der Tastatur erreichst, ihn aber nicht wieder verlassen kannst. Die bewusste Begrenzung in einem schließbaren Dialog ist zulässig. Falls zum Verlassen ungewöhnliche Tasten nötig sind, muss die Seite darauf hinweisen. Das ist in WCAG 2.1.2 „Keine Tastaturfalle“ geregelt.
Kurzer manueller Test
- Öffne die Seite neu und lege die Maus beiseite. Stelle sicher, dass dein Browser auch Links per Tab ansteuert; auf macOS kann dafür eine zusätzliche Tastatureinstellung nötig sein.
- Gehe mit Tab vorwärts und mit Umschalt + Tab zurück. Achte auf sichtbaren Fokus, sinnvolle Reihenfolge und überlagernde Banner.
- Nutze den Sprunglink. Prüfe danach, ob die Navigation übersprungen ist und der nächste Tabstopp zum Hauptinhalt passt.
- Öffne Links mit Enter. Teste Buttons mit Enter und Leertaste; bediene Auswahlfelder mit den jeweils passenden Tasten.
- Öffne und schließe Menüs und Dialoge. Kontrolliere, wo der Fokus danach steht und ob du jeden Bereich wieder verlassen kannst.
- Durchlaufe einen vollständigen Vorgang, etwa eine Kontaktanfrage in einer Testumgebung. Prüfe dabei auch Formularbeschriftungen, Fehlermeldungen und die Korrektur von Eingaben.
Absätze und gewöhnliche Überschriften brauchen dafür keine zusätzlichen Tabstopps. Screenreader haben eigene Befehle, um solche Inhalte zu lesen und anzusteuern.
ClariSEO findet ausgewählte Hinweise im Quelltext, etwa positive tabindex-Werte oder bestimmte Klickflächen ohne Tastaturzugang. Ein automatisierter Report testet die Tastaturbedienung deiner Website nicht vollständig. Halte beim manuellen Test die betroffene URL, das Element und die Tastenfolge fest, mit der ein Problem auftritt.