WCAG 2.1.3: Tastatur (ohne Ausnahme)

WCAG 2.1.3 verlangt, dass jede Funktion einer Webseite oder Anwendung über eine Tastaturschnittstelle bedienbar ist, ohne jegliche Ausnahmen – nicht einmal für pfadabhängige oder freihändige Zeichenaufgaben. Dieses AAA-Kriterium schließt die in WCAG 2.1.1 vorhandene Lücke und stellt vollständigen Tastaturzugang für Nutzer sicher, die keine Maus verwenden können.

Was diese Regel bedeutet

WCAG 2.1.3 — Tastatur (ohne Ausnahme) ist ein Erfolgskriterium der Stufe AAA nach WCAG 2.1 und 2.2, das WCAG 2.1.1 (Tastatur, Stufe A) erweitert, indem es jede Ausnahme entfernt. Konkret lautet es: Alle Funktionalitäten des Inhalts sind über eine Tastaturschnittstelle bedienbar, ohne dass bestimmte Zeitabläufe für einzelne Tastenanschläge erforderlich sind. Der entscheidende Unterschied zu 2.1.1 ist das Fehlen der Ausnahmeklausel, die Funktionalitäten ausnimmt, bei denen die zugrunde liegende Funktion eine Eingabe erfordert, die vom Pfad der Bewegung des Nutzers abhängt und nicht nur von den Endpunkten.

Unter 2.1.1 können Entwickler Funktionen wie Freihand-Zeichenflächen, gestenbasierte Malwerkzeuge oder pfadabhängige Drag-Interfaces legitim von der Tastaturunterstützung ausnehmen, weil der genaue Zeigerpfad des Nutzers das Ergebnis bestimmt. WCAG 2.1.3 beseitigt diese Ausnahme vollständig. Nach diesem Kriterium muss jede einzelne Funktion – einschließlich Zeichnen, Ziehen, pfadabhängiger Gesten und jeder Interaktion, die historisch auf Zeigerbewegungen beruhte – per Tastatur zugänglich sein. Das bedeutet, dass Entwickler alternative Tastaturmechanismen bereitstellen müssen (zum Beispiel eine barrierefreie Symbolleiste mit Formwerkzeugen, tastaturgesteuerte Zeichenmodi oder formularbasierte Eingabealternativen), selbst für Freihand- oder pfadabhängige Aufgaben.

Ein Bestehen erfordert, dass jede Operation auf der Seite ausschließlich mit der Tastatur gestartet, navigiert und abgeschlossen werden kann. Dies umfasst Fokusverwaltung, modale Dialoge, Drag-and-Drop-Umsortierung, benutzerdefinierte Schieberegler, Zeichenwerkzeuge auf Canvas, Karteninteraktionen, Karussellnavigation und Videowiedergabesteuerungen. Es darf keine Tastaturfalle geben (auch durch 2.1.2 abgedeckt), keine Funktion, die nur durch Klicken, Hovern oder Touch-Gesten ohne gleichwertigen Tastaturpfad ausgelöst werden kann, und keine Abhängigkeit von Mauszeigerpfaden.

Ein Nichtbestehen liegt vor, wenn irgendeine Funktionalität – unabhängig davon, wie nischig oder nebensächlich sie erscheinen mag – nicht ausschließlich über die Tastatur erreicht oder abgeschlossen werden kann. Da dieses Kriterium keine Ausnahmen kennt, stellt bereits eine einzige Funktion ohne Tastaturzugänglichkeit ein vollständiges Nichtbestehen dar, was es zu einem der anspruchsvollsten Standards in WCAG macht.

Warum es wichtig ist

Tastaturzugänglichkeit ist grundlegend für Nutzer mit motorischen Beeinträchtigungen, die kein Zeigegerät verwenden können. Menschen mit Erkrankungen wie Parkinson, Tetraplegie, Zerebralparese, wiederholten Belastungsverletzungen oder Gliedmaßenunterschieden sind häufig ausschließlich auf eine physische Tastatur, ein Schaltgerät, einen Sip-and-Puff-Controller oder Blicksteuerungstechnologie angewiesen, die Tastatureingaben emuliert. Laut Weltgesundheitsorganisation leben weltweit etwa 1,3 Milliarden Menschen mit einer Form einer erheblichen Behinderung, und motorische oder körperliche Beeinträchtigungen machen einen beträchtlichen Teil dieser Bevölkerung aus. Allein in der Türkei zeigen Daten des Türkischen Statistischen Instituts (TÜİK), dass über 8,5 Millionen Menschen mindestens eine Form funktionaler Einschränkung angeben.

Über motorische Behinderungen hinaus profitieren auch blinde und sehbehinderte Nutzer von Tastaturzugänglichkeit, die mit Screenreadern wie NVDA, JAWS oder VoiceOver navigieren – all diese sind auf Tastaturbefehle angewiesen, um Webinhalte zu durchqueren und mit ihnen zu interagieren. Nutzer mit fotosensitiven Erkrankungen meiden möglicherweise Touchscreens, und Nutzer mit kognitiven Beeinträchtigungen profitieren oft von der vorhersehbaren, linearen Navigation, die die Tastaturinteraktion bietet.

Betrachten Sie ein konkretes Szenario aus der Praxis: eine Grafikdesign-Plattform, die ein Freihand-Vektorzeichenwerkzeug anbietet. Unter WCAG 2.1.1 könnte dies ausgenommen werden, weil der Zeigerpfad die Form definiert. Unter WCAG 2.1.3 muss die Plattform eine Alternative bereitstellen – etwa eine Formbibliothek, eine Reihe tastaturgesteuerter Ankerpunkte oder einen textbasierten SVG-Pfad-Editor –, damit ein Nutzer mit motorischer Beeinträchtigung weiterhin Vektorgrafiken ohne Maus erstellen kann. Wird dies versäumt, schließt man einen bedeutenden Teil kreativer Fachleute aus, die auf reinen Tastaturzugang angewiesen sind.

Aus Usability- und SEO-Perspektive verfügen korrekt tastaturzugängliche Interfaces typischerweise über eine sauberere Fokusverwaltung, eine logischere Tab-Reihenfolge und gut strukturierte DOM-Hierarchien – all dies trägt zu besserer Crawlability und einer hochwertigeren Nutzererfahrung für alle bei, einschließlich Power-Usern, die Tastaturkürzel aus Geschwindigkeitsgründen bevorzugen.

Wie man testet

Automatisierten Basisscan ausführen: Verwenden Sie axe DevTools (Browser-Erweiterung oder CLI) oder Google Lighthouse für Ihre Seite, um offensichtliche Tastaturzugänglichkeitsfehler zu identifizieren – fehlende fokussierbare Elemente, Tastaturfallen oder Elemente mit pointer-events: none, die interaktiv sein sollten. Auch wenn diese Tools Verstöße gegen 2.1.3 nicht direkt erkennen, machen sie verwandte Probleme sichtbar und schaffen eine saubere Ausgangsbasis, bevor die manuellen Tests beginnen.
Alle interaktiven Funktionalitäten katalogisieren: Erstellen Sie vor dem Testen ein vollständiges Inventar aller interaktiven Komponenten auf der Seite: Buttons, Links, Formulare, Modale, Akkordeons, Karussells, Karten, Canvas-Werkzeuge, Drag-and-Drop-Bereiche, benutzerdefinierte Dropdowns, Datumsauswahlen, Videoplayer und jedes Widget, das auf Maus- oder Touch-Events reagiert. Dieses Inventar wird zu Ihrer Test-Checkliste.
Test mit reiner Tastaturnavigation: Trennen oder deaktivieren Sie Ihre Maus. Verwenden Sie Tab und Shift+Tab, um den Fokus zu verschieben, Enter und Leertaste, um Steuerelemente zu aktivieren, Pfeiltasten für zusammengesetzte Widgets (Menüs, Schieberegler, Tabs, Radiogruppen) und Escape, um Dialoge zu schließen. Versuchen Sie, jede Funktion auf Ihrer Inventarliste auszuführen. Notieren Sie jede Funktion, die Sie nicht ausschließlich mit der Tastatur starten, abschließen oder verlassen können.
Screenreader-Test mit NVDA + Firefox: Starten Sie NVDA (Windows) mit Firefox. Navigieren Sie mit dem virtuellen Cursor (H für Überschriften, B für Buttons, F für Formularfelder, Tab für interaktive Elemente). Versuchen Sie jede Funktion. Achten Sie auf angesagte Rolle, Name und Zustand. Identifizieren Sie jeden interaktiven Bereich, der unerreichbar ist oder keine hörbare Ansage erzeugt.
Screenreader-Test mit JAWS + Chrome: Verwenden Sie JAWS unter Windows mit Chrome. Nutzen Sie den virtuellen Cursor von JAWS und den Formularmodus (Umschalten mit Enter). Verifizieren Sie, dass alle Funktionalitäten bedienbar sind und dass der Fokus nach jeder Interaktion korrekt verwaltet wird – insbesondere nachdem modale Dialoge geöffnet werden oder AJAX-Inhalte geladen werden.
Screenreader-Test mit VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver (Befehl + F5 auf macOS). Verwenden Sie Control + Option + Pfeiltasten zur Navigation. Unter iOS verwenden Sie Wischgesten. Bestätigen Sie, dass alle Funktionen erreichbar und bedienbar sind. Achten Sie besonders auf benutzerdefinierte Touch-basierte Widgets, denen in der Desktop-Version möglicherweise Tastaturäquivalente fehlen.
Prüfung pfadabhängiger Funktionalität: Überprüfen Sie bei jeder Zeichenfläche, Karteninteraktion oder gestengesteuerten Komponente, ob ein alternativer Tastaturmechanismus existiert. Versuchen Sie, eine Form zu erstellen, ein Listenelement neu anzuordnen oder eine Karte ausschließlich mit Tastatursteuerung zu verschieben. Wenn kein Tastaturpfad existiert, ist dies ein direkter Verstoß gegen 2.1.3.
Prüfung der Fokus-Sichtbarkeit: Stellen Sie während der Navigation nur mit der Tastatur sicher, dass der Fokus auf dem Bildschirm immer sichtbar und logisch geordnet ist. Unsichtbarer Fokus oder Fokus, der an unerwartete Stellen springt, ist ein Usability-Fehler und verstößt wahrscheinlich auch gegen 2.4.7 und 2.4.3.

Wie man es behebt

Canvas-Zeichenwerkzeug — Falsch

<!-- Freehand canvas with no keyboard alternative -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

Canvas-Zeichenwerkzeug — Richtig

<!-- Canvas with keyboard-accessible shape toolbar as alternative -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey enables arrow-key movement and Enter to place shapes -->

Drag-and-Drop-Listen-Umsortierung — Falsch

<!-- List that only supports mouse drag for reordering -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

Drag-and-Drop-Listen-Umsortierung — Richtig

<!-- List with ARIA listbox pattern and keyboard reordering via arrow keys -->
<p id='reorderInstructions'>Tab to an item, press Space to grab it, use Up/Down arrows to move, press Space again to drop.</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = grab/drop, ArrowUp/Down = move, Escape = cancel -->

Interaktive Kartensteuerung — Falsch

<!-- Map that only responds to mouse pan and scroll-to-zoom -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

Interaktive Kartensteuerung — Richtig

<!-- Map with keyboard controls and accessible zoom/pan buttons -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- Arrow keys pan, + / - zoom, handleMapKey dispatches these actions -->

Häufige Fehler

Die Annahme, dass die pfadabhängige Ausnahme aus WCAG 2.1.1 weiterhin gilt: Entwicklern, die mit Stufe A vertraut sind, bauen manchmal Freihand-Zeichen- oder Gestenwerkzeuge ohne Tastaturalternativen, ohne zu erkennen, dass 2.1.3 diese Ausnahme ausdrücklich entfernt. Jede Funktion, einschließlich pfadabhängiger, muss auf dieser Stufe ein Tastaturäquivalent haben.
Nur onclick- und onmousedown-Handler an benutzerdefinierte interaktive Elemente anhängen: Benutzerdefinierte Widgets, die mit <div>- oder <span>-Elementen gebaut werden und nur auf Mausereignisse hören, sind für die Tastatur vollständig unerreichbar. Fügen Sie immer onkeydown- oder onkeyup-Handler zusätzlich zu Maus-Event-Listenern hinzu und stellen Sie sicher, dass das Element tabindex='0' und eine passende ARIA-Rolle hat.
Verwendung von tabindex='-1' bei Elementen, die in der Tab-Reihenfolge sein sollten: Das Setzen von tabindex='-1' entfernt ein Element aus der sequentiellen Tab-Reihenfolge. Dies ist nur für Elemente geeignet, die programmatisch verwaltet werden (z. B. innerhalb eines zusammengesetzten Widgets mit roving tabindex). Die Anwendung auf eigenständige interaktive Steuerelemente macht sie für die Tastatur unzugänglich.
Implementierung von Drag-and-Drop ohne tastaturbasierten Umsortiermechanismus: Bibliotheken wie SortableJS oder benutzerdefinierte Drag-Implementierungen bieten oft von Haus aus keine Tastaturalternative. Entwickler müssen das ARIA-Drag-and-Drop-Muster implementieren oder eine Umsortierung über Pfeiltasten nach oben/unten bereitstellen, damit das Umsortieren von Listen vollständig per Tastatur bedienbar ist.
Verlassen auf :hover-CSS, um interaktive Steuerelemente anzuzeigen: Dropdown-Untermenüs, tooltip-basierte Aktionsbuttons oder eingeblendete Steuerelemente, die nur bei Hover erscheinen, sind für Tastaturnutzer unzugänglich, sofern :focus- und :focus-within-Zustände nicht ebenfalls berücksichtigt werden. Ein Tastaturnutzer kann nie hover, daher ist reiner Hover-Inhalt für ihn faktisch verborgen.
Fehlende Fokusverwaltung nach dynamischen Inhaltsänderungen: Wenn ein Modal geöffnet wird, eine Inline-Warnung erscheint oder ein per AJAX geladenes Widget vorhandene Inhalte ersetzt, muss der Fokus programmatisch mit element.focus() auf den neuen Inhalt verschoben werden. Wird dies versäumt, bleiben Tastaturnutzer an der Stelle zurück, an der sie die Änderung ausgelöst haben, ohne zu wissen, dass neuer Inhalt existiert.
Erstellung benutzerdefinierter Schieberegler nur mit onmousemove: Bereichsartige Schieberegler, die aus <div>-Elementen gebaut werden und Mauspositionen zur Wertänderung verfolgen, müssen ebenfalls die Tasten ArrowLeft, ArrowRight, Home und End gemäß dem ARIA-Slider-Muster unterstützen und den aktuellen Wert über aria-valuenow, aria-valuemin und aria-valuemax exponieren.
Platzierung des Tastaturfokus innerhalb von iframes ohne Ausstiegsmöglichkeit: Eingebettete iframes – insbesondere solche mit Drittanbieter-Widgets wie Karten, Zahlungsformularen oder Chat-Tools – können den Tastaturfokus einschließen, wenn der eingebettete Inhalt selbst nicht tastaturzugänglich ist und die Escape-Taste nicht unterstützt, um den Fokus an das übergeordnete Dokument zurückzugeben.
Auslassen der Tastaturunterstützung bei Canvas-basierten Datenvisualisierungen: Diagramme und Grafiken, die auf <canvas> gerendert werden, sind für Tastatur und Screenreader unsichtbar, sofern nicht eine barrierefreie Alternative (eine Datentabelle, ein SVG-Äquivalent mit ARIA oder tastaturnavigierbare Datenpunkte) neben dem Canvas-Element bereitgestellt wird.
Testen der Tastaturzugänglichkeit nur mit Tab und Enter und Ignorieren von Tastaturmustern für zusammengesetzte Widgets: Viele ARIA-Widget-Muster – Menüs, Bäume, Raster, Tabpanels, Listboxen – erfordern Pfeiltastennavigation innerhalb des Widgets, mit nur einem Tab-Stopp für die gesamte Komponente (roving tabindex). Nur mit Tab und Enter zu testen, deckt Fehler in diesen zusammengesetzten Mustern nicht auf und vermittelt ein falsches Gefühl der Konformität.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt mit der Nummer 32933 am 21. Juni 2025, etabliert einen umfassenden Rahmen für Web- und mobile Barrierefreiheit für eine breite Palette öffentlicher und privater Einrichtungen, die in der Türkei tätig sind. Die Verfügung schreibt die Einhaltung von Standards vor, die mit WCAG 2.1 und 2.2 in Einklang stehen, und verlangt von den betroffenen Organisationen, dass ihre digitalen Dienste für alle Nutzer, einschließlich Menschen mit Behinderungen, wahrnehmbar, bedienbar, verständlich und robust sind.

Zu den von dieser Regelung erfassten Einrichtungen gehören öffentliche Institutionen und Behörden auf allen Ebenen der Regierung, E-Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitseinrichtungen, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die unter der Genehmigung des Ministeriums für Nationale Bildung (MoNE) tätig sind. Für diese Organisationen ist die Einhaltung der Erfolgskriterien der Stufen A und AA die minimale gesetzliche Grundlage.

WCAG 2.1.3 — Tastatur (ohne Ausnahme) ist ein Kriterium der Stufe AAA und wird daher in der Verfügung nicht ausdrücklich als grundlegende gesetzliche Anforderung vorgeschrieben. Der Geist der Regelung – die Sicherstellung eines gleichberechtigten digitalen Zugangs für die Millionen von Nutzern mit Behinderungen in der Türkei – steht jedoch in engem Einklang mit der Intention dieses Kriteriums. Organisationen in den erfassten Sektoren, die spezialisierte Dienste für Nutzer mit motorischen Beeinträchtigungen anbieten oder Regierungsportale betreiben, die von Bürgern genutzt werden, die auf unterstützende Technologien angewiesen sind, sind gut beraten, eine AAA-Konformität für Tastaturzugang anzustreben.

Die Erreichung der Konformität mit WCAG 2.1.3 signalisiert ein erstklassiges Engagement für Barrierefreiheit, das über die gesetzlichen Mindestanforderungen hinausgeht. Für türkische Organisationen, die die größtmögliche Nutzerbasis bedienen, gesellschaftliche Verantwortung demonstrieren oder an digitalen Märkten der Europäischen Union teilnehmen möchten, in denen höhere Barrierefreiheitsstandards gelten können, ist die Implementierung vollständiger Tastaturbedienbarkeit ohne Ausnahmen sowohl ein Wettbewerbsvorteil als auch ein ethischer Vorteil. Während sich die regulatorische Landschaft der Türkei weiterentwickelt und Durchsetzungsmechanismen reifen, werden frühe Anwender von Kriterien der Stufe AAA wie 2.1.3 gut positioniert sein, um jede zukünftige Verschärfung der Vorschriften ohne kostspielige Nachbesserungen zu erfüllen.