Tastaturbedienbarkeit testen heißt: eine Website nur mit der Tastatur bedienen und prüfen, ob jedes Element erreichbar ist, der Fokus sichtbar bleibt und nichts den Fokus festhält. Der Tastatur-Agent von Reviseberg übernimmt den Teil davon, den eine Maschine verlässlich kann: Er drückt Tab durch die Seiten, die Sie benennen – mit echten Tastenereignissen – und speichert zu jedem Schritt einen Pfad als Nachweis, damit Sie den Test prüfen können, statt ihn zu wiederholen.
Kostenlos prüfen – der Vollbericht enthält einen Tastatur-Durchlauf
Warum ein Tastaturtest?
Viele Menschen bedienen Websites ohne Maus: mit der Tastatur, mit Schaltern, mit Sprachsteuerung oder mit einem Screenreader, der sich ebenfalls über die Tastatur bewegt. Für sie ist ein Button, den Tab nicht erreicht, schlicht nicht vorhanden. Ein Dialog, aus dem man nicht mehr herauskommt, beendet den Besuch.
Regel-Scanner sehen davon wenig. Sie prüfen einen Zustand der Seite, zum Beispiel ob ein Element einen positiven tabindex hat. Ob man durch ein Menü, einen Filter oder einen Checkout tatsächlich hindurchkommt, zeigt sich erst, wenn jemand die Tasten drückt. Deshalb gibt es den Tastatur-Agenten.
Was der Tastatur-Agent tut
Sie nennen die Seiten, die er gehen soll – Warenkorb, Buchungsstrecke, Antragsformular. Der Agent steuert Chromium mit echten Tastenereignissen, nie mit einem gescripteten Fokus-Aufruf. Ein gescripteter Aufruf erreicht Elemente, die die Tab-Reihenfolge nicht erreicht – und genau diese Lücke ist der Fehler, den er sucht.
Auf jeder Seite:
- hält er vor dem ersten Tastendruck fest, wie jedes fokussierbare Element ohne Fokus aussieht,
- drückt er Tab und notiert, wohin der Fokus springt, mit Rolle und Namen des Elements,
- vergleicht er das fokussierte Element mit seinem Aussehen vorher – am Element selbst, an
::beforeund::after, am Elternelement und an den nächsten Elementen darin (bei einer Karte als Link sitzt der Ring oft auf der Karte), bei einem selbst unsichtbaren Formularfeld an seinem sichtbaren Label (so zeichnet Bootstrap seine Checkboxen), weil Designsysteme den Fokusring an jeder dieser Stellen zeichnen, - prüft er, ob der Fokus auf etwas ohne Größe, Transparentem oder außerhalb des Bildschirms landet,
- sucht er nach Elementen, die sich wie Bedienelemente verhalten, aber von keinem Tab erreicht werden,
- prüft er, ob das erste fokussierbare Element ein funktionierender Link zum Hauptinhalt ist,
- bestätigt er eine Tastaturfalle mit Tab, Umschalt+Tab und Escape, bevor er sie Falle nennt.
Enter und Leertaste drückt er nicht: Menüs und Dialoge öffnet er nicht. Bei einem Crawl aus einem Konto läuft derselbe Gang außerdem auf einer Seite je Template, das der Crawl findet, und eine eigene Prüfung betätigt dort Bedienelemente mit Enter und Leertaste. Sie meldet einen Dialog oder ein Menü, in das der Fokus nicht wandert und das er auch nicht als Nächstes erreicht, Fokus, der beim Schließen verloren geht, und eine Falle oder unsichtbaren Fokus darin. Die Fokussteuerung in Dialogen hinter einem Schritt, den sie nicht gehen kann, bleibt eine manuelle Prüfung.
Der Agent läuft bei jedem vollständigen Crawl, in jedem Tarif und im kostenlosen Konto. Im kostenlosen Vollbericht geht er die Startseite, die Sie im Formular angeben. Der Sofort-Scan einer einzelnen Seite und die Einzelseiten-Prüfung lassen ihn aus.
Was er meldet – und welche WCAG-Kriterien betroffen sind
| Befund | Regel | WCAG 2.2 | EN 301 549 (V3.2.1) |
|---|---|---|---|
| Ein Element verhält sich wie ein Bedienelement, aber weder Tab noch Pfeiltaste erreicht es | keyboard:unreachable | 2.1.1 Tastatur (A) | 9.2.1.1 |
| Tastaturfalle: Der Fokus kommt mit Tab, Umschalt+Tab und Escape nicht mehr heraus | keyboard:trap | 2.1.2 Keine Tastaturfalle (A) | 9.2.1.2 |
| Kein funktionierender Weg, die wiederholte Navigation zu überspringen | keyboard:skip-link | 2.4.1 Blöcke umgehen (A) | 9.2.4.1 |
| Der Fokus landet auf etwas ohne Größe, Transparentem oder außerhalb des Bildschirms | keyboard:focus-invisible | 2.4.7 Fokus sichtbar (AA) | 9.2.4.7 |
| Der Fokus landet auf einem Element, und an ihm ändert sich nichts | keyboard:focus-visible | 2.4.7 Fokus sichtbar (AA) | 9.2.4.7 |
Findet der Agent auf seinen Seiten keinen Fehler, bleiben diese Kriterien „teilweise“ und werden nicht „bestanden“: Ein Agent geht die Seiten, die Sie benannt haben, nicht jede, und ob eine Reihenfolge inhaltlich sinnvoll ist, entscheidet am Ende ein Mensch. Die Fokus-Reihenfolge (2.4.3) beurteilt deshalb eine Person – der Pfad des Agenten zeigt ihr die Reihenfolge, die er gefunden hat. Ob ein fixierter Header oder ein Cookie-Banner das fokussierte Element verdeckt (2.4.11), prüft der Agent nicht; dafür gibt es eine geführte manuelle Prüfung. Wie jeder Status entsteht, erklärt unsere Prüfmethodik.
Jeder Befund zeigt seinen Rechenweg
Ein Score, den man nicht hinterfragen kann, ist ein Risiko. Öffnen Sie einen Tastatur-Befund und Sie sehen den Lauf dahinter. Prüfer und Entwickler schauen auf dasselbe Artefakt.
| Schritt | Was gespeichert wird | Was ein Mensch damit tut |
|---|---|---|
| Jeder Tastendruck | Taste, fokussiertes Element, seine Rolle und sein Name | Denselben Pfad in 20 Sekunden nachgehen |
| Jeder Fehler | Screenshot der Seite in diesem Moment | Bestätigen oder als Fehlalarm mit Begründung markieren |
| Jedes Urteil | Bestanden, nicht bestanden oder „Mensch“ – mit Begründung | Die Fälle entscheiden, die der Agent offenlässt |
Tastatur-Befunde erscheinen in der Issue-Liste mit „Punkten zurück“ wie alle anderen. Entwickler können sie über den MCP Server direkt im Coding-Agenten abrufen, etwa keyboard:focus-visible mit Selektor und betroffener Seite.
Tastaturtest selbst machen: in fünf Minuten
Sie wollen erst selbst prüfen? So testen Sie die Tastaturbedienbarkeit Ihrer Website ohne Werkzeug:
- Klicken Sie in die Adressleiste und drücken Sie Tab. Das erste fokussierte Element sollte ein Skip-Link sein („Zum Inhalt springen“). Enter muss zum Hauptinhalt führen.
- Drücken Sie weiter Tab. Sehen Sie bei jedem Schritt, wo der Fokus ist? Folgt die Reihenfolge dem Lesefluss?
- Öffnen Sie Menü, Filter und Dialoge mit Enter oder Leertaste. Schließen Sie sie mit Escape. Kehrt der Fokus an eine sinnvolle Stelle zurück?
- Gehen Sie mit Umschalt+Tab zurück. Kommen Sie aus jedem Bereich wieder heraus?
- Achten Sie auf fixierte Header, Cookie-Banner und Chat-Fenster: Verdecken sie das fokussierte Element?
- Spielen Sie Ihre wichtigste Strecke bis zum letzten Schritt durch – ohne Maus.
Das dauert für eine Seite fünf Minuten. Für eine ganze Website bei jedem Release dauert es zu lange. Dafür ist der Agent da – und für die Schritte 3 und 5, die er nicht übernimmt, die geführten Prüfungen in Reviseberg.
Ehrliche Grenzen
Manche Urteile stehen uns nicht zu. Sie bleiben bei Menschen – und das Produkt sagt das in der Oberfläche, statt still zu raten:
- Qualität einfacher Sprache und redaktionelle Absicht
- Qualität von Gebärdensprach-Übersetzungen
- Rechtliche Freigabe der Erklärung zur Barrierefreiheit
- Abläufe mit echter Zahlung oder echten Ausweisdokumenten
- Alles, was die Belege nicht eindeutig machen – es wird mit „Mensch“ markiert statt behauptet
Liegt der Agent falsch, markieren Sie den Befund als Fehlalarm mit Begründung. Er kostet dann keine Punkte mehr und lässt sein Kriterium nicht mehr scheitern. Übereinstimmungsraten mit menschlichen Prüfern veröffentlichen wir, sobald es genug Laufhistorie gibt, um sie zu berechnen – nicht vorher.
Sieben weitere Agenten, in Entwicklung
Heute läuft ein Agent: Tastatur und Fokus. Die folgenden sieben gibt es noch nicht. Keiner davon ist im Produkt, keiner fließt in einen Score oder Status ein, und jeder ist hier als „In Entwicklung“ gekennzeichnet, bis er echt läuft.
Richten Sie den Agenten auf Ihre schwierigste Seite
Checkout, Buchungsstrecke, Antragsformular: Nennen Sie die Seite, auf der der Tastatur-Durchlauf beginnen soll – am besten die, vor deren Test Ihr Team am meisten zurückschreckt.