Deine Website in 15 Minuten mit der Tastatur testen

Ein typisches Szenario: Eine Physiotherapiepraxis hat eine neue Website mit Online-Terminbuchung. Alles sieht gut aus, die Buchungen laufen. Dann ruft eine Patientin an: Sie habe es mehrfach versucht, aber den Button „Termin buchen“ einfach nicht erreicht. Sie bedient den Computer wegen einer Sehnenscheidenentzündung gerade nur mit der Tastatur.

Solche Probleme fallen im Team oft niemandem auf, weil alle mit Maus oder Trackpad arbeiten. Dabei lassen sie sich in wenigen Minuten finden, ganz ohne Testsoftware, Plug-ins oder Fachwissen über Code. Du brauchst nur eine Tastatur, einen Browser und etwas Disziplin: Die Maus bleibt liegen.

Dieser Artikel führt dich durch einen Test in fünf Runden, der etwa 15 Minuten dauert. Er ersetzt kein vollständiges Accessibility-Audit, deckt aber genau die Fehler auf, die Menschen ohne Maus am häufigsten aussperren: fehlender Fokus, unlogische Reihenfolge, unerreichbare Elemente und Fallen, aus denen man nicht mehr herauskommt.

Warum sich der Test lohnt

Tastaturbedienung bedeutet, dass sich eine Website vollständig ohne Maus und ohne Touchscreen nutzen lässt. Darauf angewiesen sind viel mehr Menschen, als man vermutet: Menschen mit motorischen Einschränkungen, Menschen, die einen Screenreader nutzen, Menschen mit Sprachsteuerung, Schaltern oder Sondertastaturen. Dazu kommen alle, die vorübergehend eingeschränkt sind, etwa mit einem gebrochenen Arm, und Profis, die mit der Tastatur schlicht schneller sind.

Viele dieser Hilfsmittel funktionieren technisch wie eine Tastatur. Was per Tastatur nicht erreichbar ist, ist für sie also oft auch nicht erreichbar. Deshalb ist der Tastaturtest einer der effizientesten Tests überhaupt: Mit einem Durchgang prüfst du indirekt gleich mehrere Nutzungsweisen.

Die WCAG (Web Content Accessibility Guidelines), der internationale Standard für barrierefreie Webinhalte, machen daraus prüfbare Erfolgskriterien. Die wichtigsten für diesen Test sind:

• 2.1.1 Tastatur (Stufe A): Alle Funktionen lassen sich per Tastatur bedienen.
• 2.1.2 Keine Tastaturfalle (Stufe A): Wer mit der Tastatur in ein Element hineinkommt, kommt auch wieder heraus.
• 2.4.1 Blöcke umgehen (Stufe A): Wiederkehrende Bereiche wie die Navigation lassen sich überspringen.
• 2.4.3 Fokus-Reihenfolge (Stufe A): Die Reihenfolge, in der Elemente den Fokus bekommen, erhält Sinn und Bedienbarkeit.
• 2.4.7 Fokus sichtbar (Stufe AA): Es ist jederzeit erkennbar, wo sich der Fokus befindet.
• 2.4.11 Fokus nicht verdeckt (Stufe AA, neu in WCAG 2.2): Das fokussierte Element wird nicht vollständig von anderen Inhalten verdeckt, etwa von einem Sticky-Header oder Cookie-Banner.
• 3.2.1 Bei Fokus (Stufe A): Allein dadurch, dass ein Element den Fokus bekommt, ändert sich der Kontext nicht, also öffnet sich zum Beispiel keine neue Seite.

Wie verbreitet die Grundlagen fehlen, zeigt die jährliche Analyse „WebAIM Million“ der Startseiten der eine Million meistbesuchten Websites. In der Ausgabe 2026 hatten nur 17,1 % der Startseiten überhaupt einen Skip-Link, und jeder zehnte davon funktionierte nicht. Bei 95,9 % der Startseiten fanden die automatischen Tests WCAG-Fehler. Wichtig dabei: Automatische Tools erkennen viele Tastaturprobleme gar nicht. Ob der Fokus sichtbar ist oder ob die Reihenfolge Sinn ergibt, kann nur ein Mensch beurteilen. Genau dafür ist dieser Test da.

Für viele Unternehmen ist das seit dem Barrierefreiheitsstärkungsgesetz (BFSG) außerdem eine rechtliche Frage. Tastaturbedienung gehört zu den Grundlagen, an denen sich eine barrierefreie Website messen lassen muss.

Vorbereitung: eine Minute

Bevor du startest, sorg dafür, dass dein Browser die Tastatur überhaupt vollständig nutzt. Unter Windows funktioniert die Tab-Taste in allen gängigen Browsern sofort. Auf dem Mac ist das anders:

• macOS: In den Systemeinstellungen unter „Tastatur“ die Option „Tastaturnavigation“ einschalten. Sonst springt Tab in vielen Programmen nur zwischen Textfeldern und Listen, nicht zwischen allen Bedienelementen.
• Safari: Zusätzlich unter Safari, Einstellungen, „Erweitert“ die Option aktivieren, mit der die Tabulatortaste alle Objekte hervorhebt (im englischen Safari „Press Tab to highlight each item on a webpage“). Ohne diese Einstellung überspringt Safari Links beim Tabben, und du würdest Fehler finden, die es gar nicht gibt, oder echte übersehen.

Dann legst du fest, was du testest. 15 Minuten reichen nicht für eine ganze Website, aber gut für einen wichtigen Ablauf. Wähl die eine Aufgabe, für die die Website existiert: ein Produkt kaufen, einen Termin buchen, eine Anfrage senden. Im Beispiel der Physiotherapiepraxis ist das „Termin für Krankengymnastik buchen“.

Leg dir außerdem ein leeres Dokument für Notizen bereit. Jedes Problem bekommt eine Zeile: wo es auftritt, was passiert und warum es stört. Und dann: Maus zur Seite schieben, Trackpad nicht anfassen.

Die Tasten, die du brauchst, sind überschaubar:

• Tab springt zum nächsten bedienbaren Element, Umschalt + Tab zurück.
• Enter öffnet Links und löst Buttons aus.
• Leertaste löst Buttons aus, setzt Häkchen in Checkboxen und scrollt die Seite, wenn kein Bedienelement fokussiert ist.
• Pfeiltasten bewegen dich innerhalb von Radiobuttons, Auswahllisten, Menüs, Tabs und Schiebereglern.
• Escape schließt Dialoge und aufgeklappte Menüs.

Runde 1: Der Einstieg (2 Minuten)

Lade die Startseite neu und drück ein einziges Mal Tab. Was passiert jetzt?

Erscheint ein Skip-Link?

Im Idealfall taucht oben links ein Link wie „Zum Inhalt springen“ auf. Er ist normalerweise unsichtbar und erscheint erst beim ersten Tab. Drück Enter und dann noch einmal Tab: Der Fokus sollte jetzt im Hauptinhalt landen, nicht wieder im Menü.

Warum das wichtig ist: Ohne Skip-Link muss sich jemand auf jeder Seite erst durch Logo, Hauptnavigation, Suchfeld und Sprachumschalter tabben, bevor der eigentliche Inhalt beginnt. Bei einer Navigation mit 20 Links sind das 20 Tastendrücke, auf jeder einzelnen Seite.

Siehst du, wo du bist?

Das ist die wichtigste Frage des ganzen Tests. Nach jedem Tab muss klar erkennbar sein, welches Element gerade aktiv ist. Typischerweise zeigt das ein Rahmen oder eine Hervorhebung, der sogenannte Fokusindikator.

Ein häufiger Grund, warum er fehlt: Irgendwann hat jemand per CSS outline: none gesetzt, weil der Rahmen beim Klicken mit der Maus „unschön“ aussah. Für Menschen mit Tastatur ist die Website damit wie ein Bildschirm ohne Mauszeiger. Man drückt Tab und rät.

Im Beispiel der Praxis-Website sieht das so aus:

Vorher: Beim ersten Tab passiert scheinbar nichts. Erst nach dem vierten Tab erscheint ein hellgrauer, kaum sichtbarer Rahmen um einen Menüpunkt. Wo die ersten drei Tastendrücke gelandet sind, bleibt unklar.

Nachher: Der erste Tab zeigt den Link „Zum Inhalt springen“. Jedes fokussierte Element bekommt einen kräftigen, zwei Pixel breiten Rahmen in der dunklen Markenfarbe mit etwas Abstand zum Element.

Der Fokusindikator muss nicht hässlich sein. Er gehört gestaltet wie jeder andere Zustand eines Buttons, am besten direkt im Design System. Über die CSS-Pseudoklasse :focus-visible lässt sich der Rahmen zum Beispiel nur bei Tastaturbedienung anzeigen, nicht beim Klicken mit der Maus.

Runde 2: Navigation und Kopfbereich (3 Minuten)

Tab dich jetzt langsam durch den Kopfbereich und die Hauptnavigation. Achte auf drei Dinge.

Ist alles erreichbar?

Jeder Menüpunkt, das Suchfeld, der Sprachumschalter, das Warenkorbsymbol, der Login: Alles, was du mit der Maus anklicken kannst, muss auch per Tab erreichbar sein. Wenn ein Element übersprungen wird, ist es oft kein echter Link oder Button, sondern ein anklickbares div oder span. Solche Elemente reagieren auf Mausklicks, aber nicht auf die Tastatur.

Lassen sich Untermenüs öffnen?

Dropdown-Menüs, die nur beim Überfahren mit der Maus aufklappen, sind ein Klassiker. Prüf, ob sich ein Untermenü per Enter, Leertaste oder Pfeiltaste öffnen lässt und ob du anschließend die Unterpunkte erreichst. Ebenso wichtig: Mit Escape sollte sich das Menü wieder schließen, und der Fokus sollte danach auf dem Menüpunkt stehen, der es geöffnet hat.

Ein verwandtes Problem sind Inhalte, die beim Fokus erscheinen, etwa Tooltips oder Mega-Menüs. Laut WCAG-Kriterium 1.4.13 (Stufe AA) müssen sie sich schließen lassen, ohne dass sich der Fokus bewegt, typischerweise mit Escape.

Funktioniert das mobile Menü?

Mach das Browserfenster schmal, bis das Hamburger-Menü erscheint, und teste es noch einmal. Hier verstecken sich überraschend oft Fehler: Der Menü-Button ist nicht erreichbar, das geöffnete Menü bekommt keinen Fokus, oder der Fokus wandert unsichtbar durch die Seite hinter dem Menü.

In der Praxis-Website passierte genau das: Das Untermenü „Leistungen“ öffnete sich nur beim Überfahren mit der Maus. Die Unterseite „Krankengymnastik“ war per Tastatur gar nicht erreichbar, nur über einen Umweg durch die Suche.

Runde 3: Reihenfolge im Hauptinhalt (3 Minuten)

Geh jetzt den gewählten Ablauf durch, im Beispiel also auf die Seite „Krankengymnastik“ und weiter zur Terminbuchung. Achte dabei darauf, in welcher Reihenfolge der Fokus springt.

Folgt der Fokus der Leserichtung?

Der Fokus sollte sich so bewegen, wie du die Seite liest: von oben nach unten und innerhalb einer Zeile von links nach rechts. Springt er plötzlich vom Seitenanfang in die Fußzeile und wieder zurück, ist die Reihenfolge im Code eine andere als die sichtbare.

Das passiert häufig, wenn das Layout per CSS umgestellt wurde, etwa mit order in Flexbox oder Grid, oder wenn jemand positive tabindex-Werte gesetzt hat. WebAIM rät ausdrücklich davon ab, die Reihenfolge mit tabindex ab 1 zu verändern. Besser ist es, die Reihenfolge im HTML zu korrigieren und das Layout per CSS zu gestalten.

Bekommen unsichtbare Elemente den Fokus?

Ein weiteres Warnsignal: Du drückst Tab, und der Fokusrahmen verschwindet für ein paar Schritte. Meist landet der Fokus dann auf Elementen, die gar nicht sichtbar sind, zum Beispiel Links in einem eingeklappten Akkordeon, in einem ausgeblendeten Slider-Bild oder im geschlossenen Mobilmenü. Für sehende Menschen mit Tastatur ist das verwirrend, für Screenreader-Nutzende oft noch mehr.

Ist der Fokus verdeckt?

Seit WCAG 2.2 gibt es dafür ein eigenes Kriterium. Scroll mit Tab durch eine lange Seite und achte auf feste Elemente: Ein Sticky-Header, eine Chat-Blase oder ein Cookie-Banner, das am unteren Rand stehen bleibt, kann das fokussierte Element vollständig verdecken. Dann ist der Fokus zwar technisch vorhanden, aber für dich unsichtbar.

Vorher: Auf der Seite „Krankengymnastik“ liegt die Terminbuchung unten in einem Kasten. Der Cookie-Hinweis bleibt nach dem Wegklicken als schmale Leiste am unteren Rand stehen und verdeckt genau diesen Bereich. Der Fokus verschwindet beim Tabben hinter der Leiste.

Nachher: Die Leiste ist nach der Entscheidung ganz weg. Zusätzlich sorgt die CSS-Eigenschaft scroll-padding-bottom dafür, dass fokussierte Elemente nicht unter festen Leisten landen.

Runde 4: Formulare, Dialoge und Fallen (4 Minuten)

Jetzt wird es ernst. In Formularen, Dialogen und interaktiven Elementen stecken die meisten Barrieren, und hier entscheidet sich, ob jemand die Aufgabe abschließen kann.

Formulare ausfüllen

Füll das Formular komplett mit der Tastatur aus. Erreichst du jedes Feld in sinnvoller Reihenfolge? Lassen sich Radiobuttons mit den Pfeiltasten wählen und Checkboxen mit der Leertaste? Lassen sich Auswahllisten öffnen und bedienen?

Besonders kritisch sind selbstgebaute Elemente: Datumsauswahl, Uhrzeitslots, Schieberegler, Dateiupload. Sie sehen oft aus wie native Formularelemente, verhalten sich aber nicht so. Im Beispiel der Praxis waren die freien Terminslots als farbige Kacheln umgesetzt, die nur auf Mausklicks reagierten. Per Tab übersprang der Fokus den gesamten Kalender.

Ein kleiner, aber wichtiger Prüfpunkt: Wenn du ein Feld nur fokussierst oder eine Option in einer Auswahlliste mit den Pfeiltasten durchgehst, darf nicht sofort etwas Unerwartetes passieren, etwa ein automatisches Absenden oder ein Seitenwechsel. Das fordert WCAG-Kriterium 3.2.1. Mehr zu guten Formularen findest du im Artikel Formulare, die niemand abbricht.

Fehlermeldungen auslösen

Lass bewusst ein Pflichtfeld leer und schick das Formular ab. Was passiert mit dem Fokus? Gut ist, wenn er zu einer Fehlerzusammenfassung oder direkt zum ersten fehlerhaften Feld springt. Schlecht ist, wenn die Fehlermeldung irgendwo oben erscheint und der Fokus unten auf dem Button bleibt. Dann weißt du ohne Maus nicht einmal, dass es einen Fehler gibt.

Dialoge öffnen und schließen

Öffne jeden Dialog, der im Ablauf vorkommt: Bestätigung, Login-Fenster, Video-Overlay, Bildergalerie. Ein Dialog, der sich über die Seite legt (Fachbegriff: modaler Dialog), sollte sich so verhalten:

• Beim Öffnen springt der Fokus in den Dialog hinein.
• Solange er offen ist, bleibt der Fokus im Dialog. Die Seite dahinter ist nicht erreichbar.
• Escape schließt den Dialog.
• Nach dem Schließen steht der Fokus wieder auf dem Element, das den Dialog geöffnet hat.

Wer das HTML-Element dialog mit der Methode showModal() nutzt, bekommt einen Großteil davon vom Browser geschenkt: Laut MDN wird die restliche Seite dann inaktiv, der Fokus springt beim Öffnen in den Dialog, und Escape schließt ihn.

Nach Tastaturfallen suchen

Eine Tastaturfalle ist ein Element, in das du mit Tab hineinkommst, aber nicht wieder heraus. Typische Kandidaten sind eingebettete Inhalte wie Videoplayer, Karten, Chat-Widgets, Rich-Text-Editoren und Werbebanner in einem iFrame. Teste bei jedem dieser Elemente: Kommst du mit Tab und Umschalt + Tab wieder heraus? Wenn nicht, hilft vielleicht Escape. Hilft gar nichts, hast du eine Falle gefunden, die für Menschen ohne Maus den Besuch beendet.

Das Gegenstück zur Falle ist ein Dialog, der den Fokus nicht hält. Auch das ist ein Fehler, nur ein anderer: Dann tabbst du unsichtbar durch die abgedunkelte Seite dahinter, während der Dialog offen bleibt.

Tastenkürzel prüfen

Manche Websites und Web-Apps bieten Tastenkürzel aus einzelnen Buchstaben, etwa „S“ für Suche. Das kann mit Sprachsteuerung kollidieren, wenn ein gesprochenes Wort versehentlich Kürzel auslöst. WCAG-Kriterium 2.1.4 (Stufe A) verlangt deshalb, dass solche Kürzel abschaltbar, umbelegbar oder nur bei Fokus auf dem jeweiligen Element aktiv sind.

Runde 5: Auswerten (2 Minuten)

Zum Schluss beantwortest du eine einzige Frage: Hättest du die Aufgabe nur mit der Tastatur abschließen können? Wenn nein, ist das der wichtigste Befund des ganzen Tests.

Dann sortierst du deine Notizen nach Schwere. Ein einfaches Raster reicht:

• Blockierend: Die Aufgabe lässt sich nicht abschließen. Beispiele: Button nicht erreichbar, Tastaturfalle, Kalender nicht bedienbar.
• Erschwerend: Es geht, aber nur mühsam oder mit Raten. Beispiele: Fokus kaum sichtbar, unlogische Reihenfolge, kein Skip-Link.
• Störend: Kleinigkeiten, die den Ablauf unnötig verlängern. Beispiele: Fokus landet kurz auf unsichtbaren Elementen, Dialog gibt den Fokus nicht zurück.

Für die Praxis-Website ergab der Test drei blockierende Probleme (Untermenü nur per Maus, Terminkacheln nicht fokussierbar, verdeckter Buchungsbereich) und zwei erschwerende (kein sichtbarer Fokus, kein Skip-Link). Das ist eine überschaubare Liste, die das Entwicklungsteam in einem Sprint abarbeiten kann. Der Anruf der Patientin wäre mit diesen 15 Minuten nie nötig gewesen.

Ein Tipp für die Übergabe: Beschreib jedes Problem mit Seite, Element und Tastendruck, zum Beispiel „Seite Krankengymnastik, Terminkalender: Tab überspringt alle Terminslots“. So lässt sich jeder Fehler sofort nachvollziehen, ohne dass jemand fragen muss, wie du darauf gekommen bist.

Was der Test nicht abdeckt

Der Tastaturtest ist schnell und aussagekräftig, aber er hat Grenzen. Ob ein Screenreader die Elemente sinnvoll vorliest, ob Bilder Alternativtexte haben, ob Kontraste ausreichen oder ob Inhalte verständlich formuliert sind, prüft er nicht. Auch Touch-Bedienung und Sprachsteuerung testest du damit nur indirekt.

Sieh ihn deshalb als ersten Filter. Er findet die gröbsten Barrieren mit wenig Aufwand, und das regelmäßig. Ein guter Rhythmus: vor jedem größeren Release einmal den wichtigsten Ablauf, und immer dann, wenn eine neue Komponente wie ein Kalender oder ein Dialog dazukommt. Für die nächsten Schritte, von automatischen Prüftools bis zum Test mit Screenreader, gibt der Artikel Accessibility-Prüfung: Werkzeuge und Methoden für UX-Designer einen Überblick.

Fazit

Für einen aussagekräftigen Barrierefreiheitstest brauchst du weder ein Budget noch ein Spezialtool. Eine Tastatur und 15 Minuten reichen, um herauszufinden, ob Menschen ohne Maus deine Website überhaupt nutzen können. Die fünf Runden decken dabei die Punkte ab, an denen es in der Praxis am häufigsten scheitert: ein unsichtbarer Fokus, eine Reihenfolge ohne Logik, Elemente, die nur auf Mausklicks reagieren, und Dialoge oder eingebettete Inhalte, die den Fokus verschlucken.

Der größte Gewinn liegt aber in der Perspektive. Wer einmal selbst erlebt hat, wie es sich anfühlt, im Menü festzustecken oder blind durch eine Seite zu tabben, gestaltet Fokuszustände, Menüs und Dialoge danach anders. Am besten machst du den Test deshalb nicht allein, sondern gemeinsam mit dem Team: Eine Person tippt, alle anderen schauen zu.

Checkliste

• Der erste Tab zeigt einen funktionierenden Skip-Link zum Hauptinhalt.
• Der Fokus ist bei jedem Element deutlich sichtbar.
• Alle Links, Buttons und Formularelemente sind per Tab erreichbar.
• Untermenüs lassen sich per Tastatur öffnen und mit Escape schließen.
• Das mobile Menü funktioniert ebenfalls per Tastatur.
• Die Fokus-Reihenfolge folgt der sichtbaren Leserichtung.
• Ausgeblendete Elemente bekommen keinen Fokus.
• Kein Sticky-Header, Banner oder Chat-Fenster verdeckt das fokussierte Element.
• Formulare lassen sich vollständig ausfüllen, Fehler führen den Fokus zur Fehlermeldung.
• Dialoge halten den Fokus, schließen mit Escape und geben den Fokus zurück.
• Es gibt keine Tastaturfallen in Videos, Karten, Widgets oder iFrames.
• Die zentrale Aufgabe der Website lässt sich nur mit der Tastatur abschließen.

Quellen

• W3C WAI: Understanding Success Criterion 2.1.1: Keyboard
• W3C WAI: Understanding Success Criterion 2.1.2: No Keyboard Trap
• W3C WAI: Understanding Success Criterion 2.4.3: Focus Order
• W3C WAI: Understanding Success Criterion 2.4.7: Focus Visible
• W3C WAI: Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum)
• W3C WAI: How to Meet WCAG (Quick Reference)
• WebAIM: Keyboard Accessibility
• WebAIM: The WebAIM Million (2026)
• MDN Web Docs: The Dialog element
• Apple Support: Safari-Einstellungen „Erweitert“
• Apple Support: Tastaturnavigation auf dem Mac verwenden