31. Oktober 2026
Tastaturbedienung und Barrierefreiheit testen: Ihre Website ohne Maus prüfen
Die Tastaturbedienung ist der einfachste Barrierefreiheitstest, den Sie selbst durchführen können: Legen Sie die Maus beiseite, drücken Sie die Tabulatortaste und versuchen Sie, Ihre Website zu nutzen. Drei Erfolgskriterien der WCAG 2.2 legen fest, was Sie dabei feststellen sollten. Kriterium 2.1.1 (Stufe A) verlangt, dass alle Funktionen per Tastatur bedienbar sind – ausgenommen Funktionen, die vom Verlauf der Bewegung und nicht nur von ihren Endpunkten abhängen, etwa Freihandzeichnen. Kriterium 2.1.2 (Stufe A) verbietet Tastaturfallen: Kann der Fokus per Tastatur in eine Komponente gelangen, muss er sie auch per Tastatur wieder verlassen können. Kriterium 2.4.7 (Stufe AA) verlangt einen Bedienmodus, in dem der Tastaturfokus-Indikator sichtbar ist. Warum ist das wichtig? Laut W3C sind viele Menschen auf die Tastaturschnittstelle angewiesen, darunter blinde und manche motorisch eingeschränkte Menschen, und sie haben oft kein anderes Mittel zur Navigation. Im Folgenden erfahren Sie, wie Sie den Test Schritt für Schritt durchführen, was die Kriterien genau besagen, und erhalten eine wiederverwendbare Checkliste.
Warum Tastaturbedienung für die Barrierefreiheit zählt
Das W3C erklärt, dass per Tastatur bedienbare Inhalte von blinden Menschen genutzt werden können, die keine Geräte wie die Maus verwenden können, weil diese Auge-Hand-Koordination erfordern. Ebenso von Menschen, die alternative Tastaturen oder Geräte nutzen, die eine Tastatur emulieren: Spracheingabesoftware, Saug-Blas-Steuerungen (Sip-and-Puff), Bildschirmtastaturen, Scanning-Software und verschiedene assistive Technologien.
Menschen mit Sehbehinderung haben mitunter Mühe, den Mauszeiger auf dem Bildschirm zu finden oder zu verfolgen; für sie kann Software per Tastatur deutlich leichter oder überhaupt erst bedienbar sein. Manche Menschen mit Handtremor finden die Maus sehr schwer zu bedienen und nutzen deshalb meist die Tastatur. Kriterium 2.4.7 hilft zudem Menschen mit Einschränkungen der Aufmerksamkeit, des Kurzzeitgedächtnisses oder der exekutiven Funktionen, die davon profitieren, erkennen zu können, wo sich der Fokus befindet.
Ein häufiges Missverständnis: MouseKeys, mit denen man den Mauszeiger über Tasten steuert, erfüllen Kriterium 2.1.1 nicht. Für die Anwendung verhalten sie sich wie eine Maus, nicht wie eine Tastatur.
Den Tastaturtest vorbereiten
Wählen Sie einige repräsentative Seiten aus: die Startseite, eine Inhaltsseite, ein Formular und die Abläufe, die für Ihre Besucher wichtig sind, etwa Registrierung oder Bestellung. Legen Sie die Maus beiseite und klicken Sie bei Bedarf einmal in die Adressleiste, um oben auf der Seite zu beginnen.
Verwenden Sie während des gesamten Tests nur diese Tasten:
- Tab, um zum nächsten interaktiven Element zu springen, Umschalt+Tab, um zurückzugehen;
- Enter und Leertaste, um Elemente zu aktivieren: Laut W3C lassen sich fokussierte Schaltflächen in der Regel mit beiden Tasten auslösen. Diese Konvention einzuhalten ist gute Praxis, aber eine eigene Schaltfläche, die nur auf Enter reagiert, erfüllt Kriterium 2.1.1 trotzdem;
- die Pfeiltasten, um sich innerhalb einer Komponente zu bewegen, wenn Tab nicht ausreicht;
- Esc, um einen Dialog zu schließen oder eine Komponente zu verlassen.
Schritt 1: Ist alles per Tastatur bedienbar (Kriterium 2.1.1)?
Kriterium 2.1.1 verlangt, dass alle Funktionen des Inhalts über eine Tastaturschnittstelle bedienbar sind, ohne bestimmte Zeitvorgaben für einzelne Tastenanschläge. Das W3C nennt Beispiele für solche Zeitvorgaben: mehrere Tastenanschläge innerhalb kurzer Zeit wiederholen oder ausführen zu müssen, oder eine Taste lange gedrückt halten zu müssen, bevor der Anschlag registriert wird.
Die einzige Ausnahme betrifft Funktionen, deren Wesen vom Verlauf der Bewegung abhängt und nicht nur von ihren Endpunkten, etwa Freihandzeichnen oder ein Aquarellprogramm, bei dem die Pinselstriche je nach Geschwindigkeit und Dauer der Bewegung variieren. Die Ausnahme bezieht sich auf die Funktion, nicht auf die Eingabetechnik: Handschrift hängt vom Bewegungsverlauf ab, die damit erzeugte Texteingabe ist aber nicht ausgenommen. Ebenso fallen das Zeichnen gerader Linien, das Ändern von Fenstergrößen oder das Ziehen von Objekten an einen Ort, wenn der Weg dorthin keine Rolle spielt, nicht unter die Ausnahme.
Das Kriterium verlangt nicht, dass jedes sichtbare Bedienelement den Fokus erhält: Es muss eine Möglichkeit geben, dieselbe oder eine vergleichbare Aktion per Tastatur auszuführen. Das W3C nennt ein Suchformular, dessen Absende-Schaltfläche keinen Fokus erhält, das aber besteht, weil man im Textfeld Enter drücken kann. Ebenso kann eine Drag-and-Drop-Funktion Ausschneiden und Einfügen oder Formularelemente zum Verschieben von Objekten anbieten.
Was Sie beim Test notieren sollten:
- ein Menü, Reiter, Karussell oder Button, der auf die Maus reagiert, aber nie auf die Tastatur, ohne andere Möglichkeit, die Aktion per Tastatur auszuführen (Fehler F54: ausschließlich zeigegerätspezifische Event-Handler, Gesten eingeschlossen);
- ein Element, das einen Link emuliert (Fehler F42, der auch die Kriterien 1.3.1, 2.1.3 und 4.1.2 betrifft) und per Tastatur nicht funktioniert;
- ein Element, das den Fokus durch ein Skript verliert, sobald es ihn erhält (Fehler F55);
- ein iframe mit interaktiven Elementen, das aus der Tab-Reihenfolge ausgeschlossen ist, oder ein scrollbarer Bereich, der per sequenzieller Fokusnavigation nicht erreichbar ist.
Schritt 2: Keine Tastaturfalle (Kriterium 2.1.2)
Kriterium 2.1.2 verlangt: Kann der Tastaturfokus auf eine Komponente bewegt werden, muss er auch allein über die Tastaturschnittstelle wieder wegbewegt werden können. Erfordert das mehr als Pfeiltasten oder Tab ohne Zusatztaste oder andere Standardmethoden zum Verlassen, muss der Nutzer über die Methode informiert werden. Laut W3C ist Esc in den meisten Umgebungen mit physischer Tastatur eine gängige Standardmethode zum Verlassen.
Das Kriterium gilt für alle Inhalte der Seite, auch für solche, die nicht zur Erfüllung anderer Kriterien dienen: Eine einzige Falle kann die Nutzung der ganzen Seite beeinträchtigen. Fallen entstehen oft bei Inhalten, die über Plug-ins oder eingebettete Anwendungen dargestellt werden, oder bei eigenen Komponenten und Widgets, die ohne Rücksicht auf Tastaturnutzer gebaut wurden.
Den Fokus einzuschränken ist nicht immer ein Fehler. In einem modalen Dialog darf der Fokus vom letzten zum ersten Bedienelement kreisen, solange der Nutzer weiß, wie er ihn verlassen kann, zum Beispiel durch Schließen mit Abbrechen, OK oder Esc. In einem Rich-Text-Editor, in dem Tab zum Einrücken dient, kann ein Hinweis die Tastenkombination zum Verlassen nennen, etwa Alt+F10 im Beispiel des W3C.
Zum Testen betreten Sie jede Komponente (Videoplayer, Karte, Editor, Drittanbieter-Widget, Modal) und versuchen, sie mit Tab, Umschalt+Tab, den Pfeiltasten und Esc zu verlassen. Ein Hinweis ist nur dann entbehrlich, wenn das Verlassen mit Tab oder Pfeiltasten ohne Zusatztaste oder mit einer Standardmethode funktioniert; das W3C betont, dass die Spezifikation diese Standardmethoden nicht definiert und sie von Hardware, User Agent und Betriebssystem abhängen. Können Sie die Komponente per Tastatur nicht verlassen, oder erfordert das eine andere Tastenkombination, auf die kein Hinweis aufmerksam macht, liegt ein Fehler vor.
Schritt 3: Ist der Fokus immer sichtbar (Kriterium 2.4.7)?
Kriterium 2.4.7 verlangt, dass jede per Tastatur bedienbare Benutzeroberfläche einen Bedienmodus hat, in dem der Tastaturfokus-Indikator sichtbar ist. Das W3C ist eindeutig: Ohne Fokusindikator können sehende Tastaturnutzer die Seite nicht bedienen. Der Indikator darf nicht zeitlich begrenzt sein: Wird der Tastaturfokus angezeigt, muss er sichtbar bleiben.
Browser dürfen den Fokus nur bei Tastaturnutzung anzeigen; das ist zulässig. Fehler F78 betrifft dagegen das Gestalten von Umrissen und Rahmen auf eine Weise, die den Fokusindikator entfernt oder unsichtbar macht. Anerkannte Techniken sind unter anderem der Standard-Fokusindikator des Browsers oder der Plattform, ein eigener sichtbarer Indikator, ein zweifarbiger Indikator für ausreichenden Kontrast oder die CSS-Pseudoklasse :focus-visible.
Achten Sie auf den Kontrast: Da ein Fokusindikator meist Nicht-Text-Inhalt ist, etwa ein Umriss, unterliegt er auch Kriterium 1.4.11 Nicht-Text-Kontrast (Stufe AA). Kriterium 2.4.13 (Stufe AAA) gibt Hinweise zu Größe und Form des Indikators.
Beim Test sollten Sie nach jedem Druck auf Tab sofort sagen können, welches Element den Fokus hat: ein Rahmen um eine Schaltfläche oder ein Textcursor in einem Feld.
Checkliste für die Tastaturbedienung
Halten Sie diese Liste Seite für Seite bereit und notieren Sie jedes Problem mit dem betroffenen Element:
- Jeder Link, jede Schaltfläche, jedes Feld und jedes eigene Bedienelement ist per Tastatur erreichbar, oder seine Aktion lässt sich auf andere Weise per Tastatur ausführen.
- Keine Aktion erfordert schnell wiederholte Tastenanschläge oder langes Gedrückthalten einer Taste.
- Scrollbare Bereiche und interaktive iframes sind per sequenzieller Navigation erreichbar.
- Jede Komponente lässt sich mit Tab oder Pfeiltasten ohne Zusatztaste oder mit einer Standardmethode wie Esc verlassen; andernfalls erklärt ein Hinweis, wie.
- Jeder modale Dialog lässt sich per Tastatur verlassen, etwa durch Schließen mit Esc oder einer Schaltfläche.
- Der Fokus ist auf jedem Element sichtbar und verschwindet nicht nach kurzer Zeit.
- Kein Skript entzieht einem Element den Fokus, sobald es ihn erhält.
- Zusätzliche gute Praxis, außerhalb der drei hier behandelten Kriterien: Notieren Sie jede Fokusreihenfolge, die im Vergleich zur Lesereihenfolge der Seite verwirrend wirkt.
Manuelle Tests mit kontinuierlicher Überwachung ergänzen
Der Tastaturtest bleibt Handarbeit: Jemand muss die Seiten durchgehen und beurteilen, was zu sehen ist. Damit eine Verschlechterung zwischen zwei Tests nicht unbemerkt bleibt, können Sie einen kostenlosen Test Ihrer Website mit Conformly starten, anschließend die kontinuierliche Überwachung aktivieren und Ihre manuellen Tastaturdurchgänge auf die wichtigsten Abläufe konzentrieren.
Häufige Fragen
Wie teste ich die Tastaturbedienung einer Website?
Legen Sie die Maus beiseite, bewegen Sie sich mit Tab und Umschalt+Tab durch die Seite, aktivieren Sie Elemente mit Enter oder Leertaste, nutzen Sie die Pfeiltasten in Komponenten und Esc zum Schließen von Dialogen. Prüfen Sie, ob alles bedienbar ist, ob Sie nirgends festhängen und ob der Fokus immer sichtbar ist.
Was ist eine Tastaturfalle?
Eine Komponente, in die der Fokus per Tastatur gelangt, die er aber allein mit der Tastatur nicht wieder verlassen kann. WCAG-Kriterium 2.1.2 verbietet das: Der Fokus muss sich immer allein per Tastatur wegbewegen lassen. Erfordert das mehr als Pfeiltasten oder Tab ohne Zusatztaste oder eine andere Standardmethode, muss der Nutzer erfahren, wie es geht.
Ist ein modaler Dialog, der den Fokus festhält, eine Tastaturfalle?
Nein, solange der Nutzer weiß, wie er ihn verlassen kann. Das W3C nennt als Beispiel einen Dialog, in dem der Fokus im Kreis läuft und der mit Abbrechen, OK oder der Esc-Taste geschlossen wird.
Darf man den Fokusrahmen mit outline: none entfernen?
Umrisse oder Rahmen so zu gestalten, dass der Fokusindikator entfernt oder unsichtbar wird, ist ein vom W3C dokumentierter Fehler (F78) für Kriterium 2.4.7. Wenn Sie den Standardstil ändern, stellen Sie einen sichtbaren Indikator mit ausreichendem Kontrast bereit.
Reichen MouseKeys für eine tastaturzugängliche Website aus?
Nein. Laut W3C emulieren MouseKeys eine Maus: Die Anwendung erhält sie als Zeigegerät, nicht als Tastaturschnittstelle. Sie erfüllen Kriterium 2.1.1 daher nicht.
Muss jede Schaltfläche den Tastaturfokus erhalten?
Nicht unbedingt. Kriterium 2.1.1 verlangt, dass sich dieselbe oder eine vergleichbare Aktion per Tastatur ausführen lässt. Eine nicht fokussierbare Absende-Schaltfläche ist akzeptabel, wenn Enter im Suchfeld das Formular absendet.
Weiterlesen bei Conformly
Quellen
Dieser Artikel stützt sich auf die am Seitenende genannten offiziellen Quellen.