WCAG 2.1.1: Tastatur

WCAG 2.1.1 verlangt, dass alle Funktionen, die über eine Maus oder einen Zeiger verfügbar sind, gleichermaßen ausschließlich über die Tastatur bedienbar sind, ohne dass ein bestimmtes Timing für Tastenanschläge erforderlich ist. Dieses Kriterium ist grundlegend für Nutzer, die keine Maus verwenden können, und stellt sicher, dass sie auf jeder Website oder in jeder Anwendung navigieren, interagieren und Aufgaben ausführen können.

Was diese Regel bedeutet

WCAG 2.1.1 (Keyboard) schreibt vor, dass jede Funktionalität auf einer Webseite oder in einer Anwendung über eine Tastaturschnittstelle bedienbar sein muss. Das bedeutet: Wenn ein Nutzer eine Schaltfläche anklicken, ein Element ziehen, mit Hover ein Menü anzeigen oder mit einem anderen Element per Maus interagieren kann, muss er exakt dieselbe Aktion ausschließlich mit Tastatureingaben ausführen können – typischerweise mit den Tasten Tab, Shift+Tab, Enter, Leertaste und den Pfeiltasten.

Das Kriterium gilt für alle interaktiven Elemente: Links, Schaltflächen, Formularelemente, benutzerdefinierte Widgets, modale Dialoge, Dropdown-Menüs, Akkordeons, Karussells, Datumsauswahlen, Drag-and-drop-Oberflächen, canvas-basierte Interaktionen und jede andere Komponente, die auf Benutzereingaben reagiert. Wenn Inhalte erfordern, dass ein Nutzer eine Zeichenbahn ausführt (wobei die Bahn selbst die Eingabe ist, nicht nur der Endpunkt), ist dies die einzige in WCAG formell anerkannte Ausnahme. Abgesehen von dieser engen Ausnahme muss jede andere Funktionalität per Tastatur zugänglich sein.

Ein Pass bedeutet, dass ein Nutzer, der ausschließlich die Tastatur verwendet, jedes interaktive Element über Tab- oder Pfeiltasten-Navigation erreichen, es mit Enter oder Leertaste aktivieren und die beabsichtigte Aktion ausführen kann, ohne in irgendeinem Schritt eine Maus zu benötigen. Ein Fail liegt vor, wenn eines der folgenden Kriterien erfüllt ist: Ein interaktives Element erhält überhaupt keinen Fokus; es erhält Fokus, kann aber nicht aktiviert werden; eine Funktion wird ausschließlich durch ein Mausereignis wie onmouseover oder ondblclick ausgelöst, ohne Tastaturäquivalent; oder ein scrollbarer Container ist per Tastatur nicht erreichbar, sodass Inhalte darin eingeschlossen werden.

Es ist wichtig, WCAG 2.1.1 von WCAG 2.1.2 (No Keyboard Trap) zu unterscheiden. Kriterium 2.1.1 stellt sicher, dass Tastaturnutzer alles erreichen und benutzen können; Kriterium 2.1.2 stellt sicher, dass Tastaturnutzer niemals in einer Komponente feststecken. Beide müssen erfüllt sein, um vollständige Konformität auf Level A zu erreichen.

Warum das wichtig ist

Tastaturzugänglichkeit ist kein Nischenthema. Schätzungsweise 1 von 4 Erwachsenen in den Vereinigten Staaten lebt mit irgendeiner Form von Behinderung, und motorische Beeinträchtigungen – einschließlich Erkrankungen wie Parkinson, Multiple Sklerose, Rückenmarksverletzungen, Repetitive-Strain-Injury (RSI), Gliedmaßenunterschieden und Tremor – verhindern häufig, dass Nutzer eine Standardmaus oder einen Touchscreen bedienen können. Diese Nutzer sind vollständig auf Tastaturen, Schaltersteuerungen, Sip-and-Puff-Geräte, Kopfzeiger oder andere Hilfstechnologien angewiesen, die letztlich auf Betriebssystemebene Tastatureingaben emulieren.

Blinde und sehbehinderte Nutzer, die auf Screenreader wie NVDA, JAWS oder VoiceOver angewiesen sind, navigieren vollständig über die Tastatur. Wenn ein Element per Tastatur nicht erreichbar ist, wird der Screenreader es niemals ankündigen, wodurch der Inhalt für diesen Nutzer vollständig unsichtbar bleibt. Laut Weltgesundheitsorganisation haben weltweit mindestens 2,2 Milliarden Menschen eine Form von Sehbeeinträchtigung im Nah- oder Fernbereich.

Betrachten Sie ein konkretes Szenario: Eine Nutzerin mit fortgeschrittener rheumatoider Arthritis in beiden Händen besucht eine E-Commerce-Checkout-Seite. Der eigens entwickelte Zahlungsart-Selektor der Seite ist als Reihe gestylter <div>-Elemente implementiert, die nur auf Mausklicks reagieren. Die Nutzerin kann per Tab zum Container gelangen, aber keine einzelne Option erhält Fokus, und das Drücken von Enter bewirkt nichts. Sie kann den Kauf nicht abschließen. Das ist keine kleine Unannehmlichkeit – es ist ein vollständiger Ausschluss von einer kommerziellen Transaktion und stellt sowohl ein rechtliches Risiko als auch ein erhebliches Umsatzverlustszenario für das Unternehmen dar.

Über Behinderungen hinaus profitieren auch Power-User, die aus Geschwindigkeitsgründen Tastaturkürzel bevorzugen, Nutzer in Unternehmens- oder Regierungsumgebungen, in denen die Mausnutzung durch Richtlinien eingeschränkt ist, sowie Nutzer mit nicht standardmäßigen Eingabegeräten von Tastaturzugänglichkeit. Sie korreliert außerdem positiv mit sauberen, semantischen HTML-Strukturen, die von Suchmaschinen zuverlässiger geparst werden, was zu besserer SEO-Performance und langfristiger Wartbarkeit des Codebestands beiträgt.

Wie man testet

Automatischer Scan mit axe DevTools oder Lighthouse: Installieren Sie die Browsererweiterung axe DevTools für Chrome oder Firefox. Navigieren Sie zur zu testenden Seite und führen Sie einen Vollseiten-Scan durch. Filtern Sie die Ergebnisse nach Regeln mit den Tags wcag2a und keyboard. Achten Sie speziell auf Verstöße gegen scrollable-region-focusable und server-side-image-map. Führen Sie in Lighthouse (Chrome DevTools) ein Accessibility-Audit durch und prüfen Sie die Kategorie „Keyboard“. Beachten Sie, dass diese Tools offensichtliche strukturelle Fehler aufzeigen, aber nicht alle Probleme mit benutzerdefinierten Widgets erfassen.
Manueller Test der Tastaturnavigation: Trennen Sie Ihre Maus oder legen Sie sie vollständig beiseite. Drücken Sie ausgehend von der Adressleiste des Browsers wiederholt Tab, um vorwärts durch alle fokussierbaren Elemente auf der Seite zu navigieren. Drücken Sie Shift+Tab, um rückwärts zu navigieren. Überprüfen Sie bei jedem interaktiven Element – Links, Schaltflächen, Eingabefelder, benutzerdefinierte Dropdowns, Modale, Slider –, dass: (a) es einen sichtbaren Fokusindikator erhält; (b) das Drücken von Enter oder Leertaste es wie erwartet aktiviert; (c) jeder resultierende Dialog oder jedes Panel ebenfalls per Tastatur navigiert und geschlossen werden kann. Verwenden Sie Pfeiltasten innerhalb von Widgets, die zusammengesetzte Muster implementieren (Menüs, Tablisten, Radiogruppen, Listboxen).
Screenreader- + Tastaturtest mit NVDA und Firefox: Starten Sie NVDA (kostenlos, Windows) und öffnen Sie Firefox. Verwenden Sie den Browse Mode von NVDA (Pfeiltasten), um die Seite zu lesen und alle interaktiven Elemente zu identifizieren. Wechseln Sie in den Focus Mode (Einfügen+Leertaste oder automatisch bei Formularfeldern), um mit Steuerelementen zu interagieren. Überprüfen Sie, ob benutzerdefinierte Widgets ihre Rolle, ihren Zustand und ihren Namen ankündigen und ob alle Funktionen ohne Maus ausgeführt werden können. Testen Sie alle scrollbaren Container, indem Sie versuchen, per Tab in sie zu gelangen und mit den Pfeiltasten zu scrollen.
Screenreader-Test mit VoiceOver und Safari (macOS/iOS): Aktivieren Sie VoiceOver (Befehl+F5 auf macOS). Verwenden Sie VO+Rechtspfeil, um linear durch die Seite zu navigieren. Verwenden Sie Tab, um zwischen interaktiven Elementen zu wechseln. Bestätigen Sie, dass scrollbare Bereiche erreichbar sind und dass keine Funktionalität ausschließlich eine Wischgeste oder Zeigerinteraktion ohne tastaturzugängliche Alternative erfordert.
JAWS- und Chrome-Test: Öffnen Sie mit laufendem JAWS Chrome und navigieren Sie zur Seite. Verwenden Sie den JAWS Virtual Cursor, um Inhalte zu durchsuchen, und die Tab-Taste, um zwischen interaktiven Elementen zu wechseln. Testen Sie speziell alle benutzerdefinierten JavaScript-Widgets – Akkordeons, Karussells, modale Dialoge, benutzerdefinierte Select-Boxen –, indem Sie zu ihnen tabben und versuchen, sie vollständig per Tastatur zu bedienen. Protokollieren Sie jedes Element, das Fokus erhält, aber nicht aktiviert werden kann, oder jede Funktionalität, die nur über Mouseover erreichbar ist.
Spezifischer Test für scrollbare Bereiche: Identifizieren Sie alle Container auf der Seite mit sichtbaren Scrollbalken oder mit mehr Inhalt als ihrem sichtbaren Bereich. Versuchen Sie, per Tab in jeden Container zu gelangen. Wenn Tab den Fokus nicht in den Container verschiebt und es keine fokussierbaren Kindelemente gibt, ist der Container wahrscheinlich ein Tastaturzugänglichkeitsfehler. Versuchen Sie, die Pfeiltasten zu drücken, während der Container oder ein nahegelegenes Element Fokus hat, um zu sehen, ob Scrollen möglich ist.

Wie man es behebt

Szenario 1: Scrollbarer Container – Falsch

<!-- Scrollable div with no tabindex: keyboard users cannot scroll this content -->
<div style='height: 200px; overflow-y: auto;'>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Szenario 1: Scrollbarer Container – Richtig

<!-- Adding tabindex='0' makes the container focusable so keyboard users
     can scroll it with arrow keys once it receives focus -->
<div
  tabindex='0'
  role='region'
  aria-label='Terms and Conditions'
  style='height: 200px; overflow-y: auto;'
>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Szenario 2: Serverseitige Image Map – Falsch

<!-- ismap sends pixel coordinates to the server — no keyboard equivalent exists -->
<a href='/map-handler'>
  <img src='navigation-map.png' ismap alt='Site navigation map' />
</a>

Szenario 2: Serverseitige Image Map – Richtig

<!-- Replace with a client-side image map using <map> and <area> elements.
     Each <area> is focusable and activatable by keyboard. -->
<img
  src='navigation-map.png'
  alt='Site navigation map'
  usemap='#site-nav'
/>
<map name='site-nav'>
  <area shape='rect' coords='0,0,100,50' href='/home' alt='Home' />
  <area shape='rect' coords='100,0,200,50' href='/about' alt='About Us' />
  <area shape='rect' coords='200,0,300,50' href='/contact' alt='Contact' />
</map>

Szenario 3: Benutzerdefiniertes Widget nur mit Maus-Events – Falsch

<!-- div acting as a button with only onclick: keyboard users pressing Enter
     or Space will get no response -->
<div onclick='submitForm()'>Submit Order</div>

Szenario 3: Benutzerdefiniertes Widget nur mit Maus-Events – Richtig

<!-- Option A: Use a native <button> — it handles keyboard activation natively -->
<button type='submit' onclick='submitForm()'>Submit Order</button>

<!-- Option B: If a custom element is required, add tabindex, role, and
     a keydown listener for Enter (13) and Space (32) -->
<div
  role='button'
  tabindex='0'
  onclick='submitForm()'
  onkeydown='if(event.key==="Enter"||event.key===" "){submitForm();}'
>
  Submit Order
</div>

Szenario 4: Nur-Hover-Dropdown-Menü – Falsch

<!-- Menu only appears on CSS :hover — keyboard focus on the parent
     does not reveal the submenu -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <a href='/products'>Products</a>
      <ul class='dropdown'> <!-- only visible on :hover in CSS -->
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Szenario 4: Nur-Hover-Dropdown-Menü – Richtig

<!-- Use a button to toggle the dropdown and manage aria-expanded.
     CSS shows the submenu when the button has aria-expanded='true'.
     Keyboard users press Enter/Space on the button to open the menu. -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <button
        aria-expanded='false'
        aria-controls='products-submenu'
        onclick='toggleMenu(this)'
      >
        Products
      </button>
      <ul id='products-submenu' hidden>
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Häufige Fehler

onclick als einzigen Event-Handler auf einem nicht nativen Element zu verwenden, ohne einen entsprechenden onkeydown- oder onkeyup-Handler hinzuzufügen – Mausklicks lösen onclick aus, aber Tastaturaktivierung auf einem <div> oder <span> nicht.
tabindex='0' zu einem benutzerdefinierten interaktiven Element hinzuzufügen, aber role='button' (oder eine passende Rolle) zu vergessen, wodurch Screenreader den Zweck des Elements nicht an die Nutzer kommunizieren.
Dropdown-Navigation zu erstellen, die ausschließlich auf der CSS-Pseudoklasse :hover basiert, ohne eine JavaScript-gestützte Tastaturumschaltung, wodurch Untermenüs für Tastaturnutzer unsichtbar und unerreichbar werden.
Drag-and-drop-Oberflächen zu implementieren – sortierbare Listen, Kanban-Boards, Datei-Upload-Zonen – ohne eine tastaturzugängliche alternative Mechanik wie tastaturgesteuerte Verschiebebefehle oder eine separate Steuerung zur Neuordnung.
Scrollable Container (wie Nutzungsbedingungen-Boxen, Chatfenster oder Datentabellen in Wrappern mit fester Höhe) ohne tabindex='0' zu erstellen, wodurch Tastaturnutzer nicht scrollen können, um alle Inhalte zu sehen.
<img ismap> für Navigationselemente zu verwenden, die aus Legacy-Codebasen übernommen wurden, ohne sie durch clientseitige Image Maps oder Standard-Navigationslinks zu ersetzen.
tabindex='-1' auf interaktive Elemente anzuwenden, um sie aus der natürlichen Tab-Reihenfolge zu entfernen, ohne eine programmatische Fokusmanagement-Strategie bereitzustellen, was zu Steuerelementen führt, die dauerhaft per Tastatur unerreichbar sind.
Funktionalität ausschließlich über mouseenter-, mouseleave- oder mousemove-Events auszulösen (Tooltips, Vorschauen, Kontextmenüs), ohne gleichwertige Alternativen über focus-, blur- oder Tastaturereignisse.
Davon auszugehen, dass ein modaler Dialog den Fokus automatisch verwaltet – den Fokus beim Öffnen nicht in den Dialog zu verschieben und ihn beim Schließen nicht auf das auslösende Element zurückzusetzen, wodurch Tastaturnutzer auf der Seite desorientiert werden.
pointer-events: none in CSS auf ein Element anzuwenden, das per Tastatur zugänglich sein sollte, was zwar nicht direkt das Tastaturverhalten beeinflusst, aber häufig mit JavaScript-Mustern einhergeht, die ebenfalls Tastaturinteraktion blockieren.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web-Barrierefreiheit fest, die sich an WCAG 2.1 Level AA orientieren. WCAG 2.1.1 (Keyboard) ist ein Kriterium der Stufe Level A und gehört damit zur höchstpriorisierten Stufe der erforderlichen Konformität. Konformität auf Level A ist die absolute Mindestgrundlage – wenn eine Website die Kriterien auf Level A nicht erfüllt, gilt sie als nicht barrierefrei, unabhängig von allen anderen Verbesserungen.

Gemäß der Verfügung unterscheiden sich die Umsetzungsfristen je nach Art der Einrichtung: öffentliche Institutionen und Regierungsbehörden müssen innerhalb von einem Jahr ab Veröffentlichungsdatum der Verfügung Konformität erreichen, während private Sektorunternehmen, die von der Regelung erfasst sind, zwei Jahre Zeit zur Umsetzung haben.

Zu den von der Präsidialverfügung 2025/10 erfassten Einrichtungen gehört ein breites Spektrum türkischer digitaler Dienste: E-Commerce-Plattformen, öffentliche Institutionen und Ministerien, Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, lizenzierte Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind.

Für all diese Einrichtungen bedeutet das Nicht-Erfüllen von WCAG 2.1.1, dass tastaturabhängige Nutzer – einschließlich Bürger mit motorischen Behinderungen, ältere Nutzer und Screenreader-Nutzer – keinen Zugang zu ihren zentralen digitalen Diensten haben. Dies ist ein direkter Verstoß gegen die Vorschrift. Praktisch bedeutet dies, dass eine E-Commerce-Website, bei der der Checkout-Prozess nicht per Tastatur abgeschlossen werden kann, oder ein Patientenportal eines Krankenhauses, bei dem die Terminbuchung Mausinteraktion erfordert, gegen die Anforderungen der Verfügung verstößt.

Organisationen, die der Verfügung unterliegen, sollten als ersten Schritt in ihrem Barrierefreiheits-Programm ein Audit der Tastaturzugänglichkeit durchführen. Da Verstöße gegen WCAG 2.1.1 häufig architektonischer Natur sind – verwurzelt in der Wahl der HTML-Elemente, den Mustern der Event-Bindung und den Standardvorgaben von Komponenten-Frameworks – kann ihre Behebung Codeänderungen erfordern und lässt sich nicht allein durch Konfigurationsanpassungen lösen. Das Overlay-SDK von Accsible kann dabei helfen, häufige Lücken bei der Tastaturzugänglichkeit auf der JavaScript-Ebene sichtbar zu machen und zu überbrücken, aber Teams sollten zusätzlich strukturelle Korrekturen in ihrem Quellcode vornehmen, um eine robuste, prüfbare Konformität zu erreichen, die einer behördlichen Überprüfung standhält.