Element per Tastatur nicht erreichbar (keyboard:unreachable)

Die Regel keyboard:unreachable meldet etwas, das sich wie ein Bedienelement verhält – es hat einen Klick-Handler oder eine Rolle wie button oder tab –, auf dem aber nie ein Tab landet. Mit der Maus funktioniert es, mit der Tastatur kommt man nie hin. Die Lösung ist fast immer das echte Element: <button> für Aktionen, <a href> für Navigation.

Was die Regel bedeutet

WCAG 2.1.1 verlangt, dass sich alles, was eine Seite ermöglicht, auch per Tastatur erledigen lässt. Native Bedienelemente – Links mit href, Buttons, Formularfelder, <summary> – stehen in der Tab-Reihenfolge und reagieren ohne zusätzlichen Code auf Enter oder Leertaste. Ein <div> oder <span> kann beides nicht: Es bekommt keinen Fokus, und Enter bewirkt nichts – egal, wie es aussieht und was sein Klick-Handler tut.

Eine Rolle allein ändert daran nichts. role="button" lässt Hilfstechnik einen Button ansagen, bringt das Element aber weder in die Tab-Reihenfolge noch zum Reagieren auf Enter oder Leertaste. Das Markup verspricht etwas, das es nicht hält.

Wen es betrifft

Alle, die eine Seite ohne Maus bedienen: Menschen mit motorischen Einschränkungen mit Tastatur, Schalter oder Mundstab, blinde Menschen mit Screenreader und Menschen mit Sprachsteuerung, die oft über dieselben fokussierbaren Elemente arbeitet. Ist ausgerechnet das Element nicht erreichbar, das ein Produkt öffnet, in den Warenkorb legt oder Cookies bestätigt, lässt sich die Aufgabe gar nicht abschließen.

Warum die Prüfung anschlägt

• Klickbare Karten – ein <div onclick> um einen Teaser oder ein Produkt, ohne Link darin.
• Icon-Buttons aus <span> oder <i> mit Klick-Handler: Schließen, Menü, Suche.
• Halbfertige ARIA-Widgets: role="tab", role="menuitem" oder role="option" ohne tabindex und ohne Tastaturbedienung.
• tabindex="-1" an einem Bedienelement, das erreichbar sein sollte – oft aus einem Muster kopiert, das den Fokus per Skript verwaltet.
• Cookie-Banner und Chat-Starter von Drittanbietern, die nur auf Mausklicks hören.

So beheben Sie es

Ersetzen Sie den Stellvertreter durch das Element, das die Aufgabe schon kann. Fokus, Enter, Leertaste und die richtige Rolle bekommen Sie dann geschenkt.

<!-- Vorher: eine Karte, die sich nur mit der Maus öffnen lässt -->
<div class="produkt-karte" onclick="location.href = '/produkte/schreibtischlampe/'">
  <img src="/img/schreibtischlampe.jpg" alt="">
  <h2>Schreibtischlampe</h2>
  <p>49,00 €</p>
</div>

<!-- Nachher: die Überschrift enthält einen echten Link; CSS kann ihn über die Karte ziehen -->
<div class="produkt-karte">
  <img src="/img/schreibtischlampe.jpg" alt="">
  <h2><a href="/produkte/schreibtischlampe/">Schreibtischlampe</a></h2>
  <p>49,00 €</p>
</div>

Dasselbe bei einem Icon, das etwas auslöst:

<!-- Vorher: als Button angesagt, aber kein Tab erreicht es -->
<span class="icon-schliessen" role="button" aria-label="Schließen" onclick="panelSchliessen()">×</span>

<!-- Nachher: ein echter Button -->
<button type="button" class="icon-schliessen" aria-label="Schließen" onclick="panelSchliessen()">×</button>

Können Sie das Element wirklich nicht austauschen, braucht es tabindex="0", einen Handler für Enter (bei Buttons auch Leertaste) und die passende Rolle – drei Dinge, die das native Element auf einmal mitbringt.

So prüfen Sie es von Hand

1. Drücken Sie Tab vom Seitenanfang an und notieren Sie jedes Bedienelement, das den Fokus bekommt.
2. Vergleichen Sie mit allem, was sich anklicken lässt: Karten, Icons, Tabs, Akkordeons, Slider, Cookie-Buttons.
3. Jedes übersprungene Element ist ein Fund. Drücken Sie bei jedem besuchten Enter (bei Buttons auch Leertaste) und prüfen Sie, ob es funktioniert.
4. Der Barrierefreiheitsbaum in den Entwicklertools zeigt, ob ein Element fokussierbar ist und welche Rolle es hat.

Zugehöriges WCAG-Kriterium

2.1.1 Tastatur, Stufe A. Verwandt: 4.1.2 Name, Rolle, Wert, weil ein klickbares <div> auch keine Rolle hat, und 2.4.3 Fokus-Reihenfolge.

So meldet Reviseberg diese Regel

Diese Regel stammt vom Tastatur-Agenten von Reviseberg, nicht aus axe-core. Nachdem er die Nutzerreise, die Sie festlegen, mit echten Tastendrücken durchlaufen hat, sucht der Agent nach Elementen, die sich als Bedienelement ausgeben – ein onclick-Attribut oder eine Rolle wie button, link, checkbox, radio, tab, menuitem, switch oder option –, die sichtbar sind, aber weder von Natur aus fokussierbar noch mit einem tabindex von 0 oder mehr versehen. Jedes meldet er mit dem Hinweis „This div behaves like a control but cannot be reached with the keyboard“, dem Selektor und dem Grund, warum es interaktiv wirkte.

Was er nicht sieht: Ein Klick-Handler, der mit addEventListener angehängt wurde, hinterlässt keine Spur, die ein Skript auf der Seite lesen könnte. Ein so verdrahtetes <div> wird nicht gemeldet. Der Agent meldet bewusst lieber zu wenig, als aus einem Zeiger-Cursor zu raten – das würde jede gestaltete Karte markieren. Ein sauberes Ergebnis ist hier also kein Beweis, und der Test von Hand bleibt wichtig.

Verwandte Regeln

• undefined – das umgekehrte Problem: ein Fokus, der nicht mehr herauskommt.
• undefined – ein Bedienelement in einem anderen.
• undefined – ein Scrollbereich, den die Tastatur nicht erreicht.

Tastatur-Agent auf Ihrer Website – kostenloser Bericht