Marketing Glossar

2.413 Fachbegriffe aus 22 Bereichen des Online Marketings

Tastaturnavigation

Definition: Tastaturnavigation bezeichnet die Fähigkeit einer Website oder Anwendung vollständig ohne Zeigegerät (Maus, Touchpad, Touch-Screen) ausschließlich über die Tastatur bedient werden zu können – ein grundlegendes Barrierefreiheits-Merkmal und WCAG-Pflicht (WCAG 2.1 Guideline 2.1 Keyboard Accessible). Standard-Tastaturbedienung: Tab (fokussiert nächstes interaktives Element in DOM-Reihenfolge); Shift+Tab (fokussiert vorheriges Element); Enter/Return (aktiviert Links und Buttons; bestätigt Formulare); Leertaste (aktiviert Checkboxen und Buttons; scrollt Seite); Pfeiltasten (navigiert innerhalb Komponenten: Radio-Gruppen, Dropdowns, Tabs, Sliders, Menüs); Escape (schließt Dialoge, Menüs, Tooltips; abbrechende Aktion); F6 (wechselt zwischen Anwendungs-Bereichen in manchen Interfaces). Nutzergruppen die auf Tastaturnavigation angewiesen sind: Motorisch eingeschränkte Nutzer (Tremor, eingeschränkte Feinmotorik, Lähmungen; CDC 2023: 2,3% der US-Bevölkerung haben Schwierigkeiten mit Feinmotorik-Aufgaben); Screen-Reader-Nutzer (JAWS, NVDA, VoiceOver arbeiten primär mit Tastatur; WebAIM Screen Reader Survey 2024: 89% der SR-Nutzer bevorzugen Tastatur gegenüber Maus); Switch-Access-Nutzer (einzelner Schalter navigiert durch sequentielle Fokus-Punkte; erfordert optimierte Tab-Reihenfolge); Power-User (Keyboard-Shortcuts erhöhen Produktivität; betrifft Entwickler, Datenanalysten, Buchhalter die routinemäßig Tastatur bevorzugen). WCAG-Schlüsselanforderungen für Tastatur: 2.1.1 Keyboard (Level A): alle Funktionen über Tastatur erreichbar; 2.1.2 No Keyboard Trap (Level A): keine Fokus-Fallen; 2.4.3 Focus Order (Level A): logische Fokus-Reihenfolge; 2.4.7 Focus Visible (Level AA): sichtbarer Fokus-Indikator.

Erläuterung

Gregg Vanderheiden (Trace Research and Development Center; University of Wisconsin-Madison; Madison; WI; WCAG-Gründungsmitglied und Pionier der Computer-Barrierefreiheit) und Judy Brewer (W3C WAI-Leiterin; MIT CSAIL; Cambridge; MA; WAI seit 1997) etablierten Tastatur-Zugänglichkeit als nicht-verhandelbare Anforderung in den Web Content Accessibility Guidelines (WCAG 1.0; W3C; 1999; Checkpoint 9.1: «Use device-independent event handlers»): die Grundüberlegung war dass Tastatur der kleinste gemeinsame Nenner aller Eingabe-Modalitäten ist – jedes assistive Technologie-Gerät (Screen-Reader, Switch, Sip-and-Puff, Eye-Tracking) emuliert Tastatureingaben; wer Tastaturzugänglichkeit gewährleistet deckt alle diese Modalitäten ab. Die Web Accessibility Initiative (W3C WAI; gegründet 1997) entwickelte die WAI-ARIA-Spezifikation (Accessible Rich Internet Applications; ARIA 1.0 W3C Recommendation März 2014; ARIA 1.2 W3C Recommendation Juni 2023; James Nurthen/Joanmarie Diggs; IBM Accessibility Research) als Lösung für das JavaScript-Widget-Problem: native HTML-Elemente (<button>, <input>, <a>) haben eingebaute Tastaturzugänglichkeit; moderne Single-Page-Applications nutzen Custom-Widgets (div-basierte Dropdowns, Custom-Scrolllisten, AJAX-Tabs) die ohne ARIA für Tastatur und Screen-Reader unzugänglich sind; WAI-ARIA definiert Keyboard-Interaction-Patterns für 29 Widget-Rollen (Button, Combobox, Dialog, Grid, Listbox, Menu, Menubar, Radiogroup, Slider, Tab, Tabpanel, Textbox, Tree, Treegrid); jedes Muster spezifiziert welche Tasten welche Aktionen auslösen. Patrick Lauke (Web-Accessibility-Spezialist; Manchester; UK; Opera-Software-Beitrag) und Bruce Lawson (Opera Software; Birmingham; UK; HTML5-Accessibility-Aktivist) dokumentierten ausführlich das «Keyboard-Trap»-Problem (WCAG 2.1.2): Modal-Dialoge ohne Focus-Trap erlauben es Tab zu drücken bis der Fokus hinter das Modal gelangt – für sehende Nutzer sichtbar aber verwirrendes Verhalten; Modals mit korrektem Focus-Trap halten den Fokus innerhalb des Dialogs bis er geschlossen wird; dies ist das wichtigste Keyboard-Management-Pattern überhaupt. Marcy Sutton (Adobe; San Francisco; CA; dann Freelance; «Accessibility for Everyone», A Book Apart, 2019; Mitgründerin Deque Axe-Academy-Materialien) und Rob Dodson (Google Chrome; Mountain View; CA; A11ycasts YouTube-Serie mit 60+ Videos zu Keyboard-Accessibility) waren 2015–2020 die aktivsten Praktiker-Evangelisten für Keyboard-Zugänglichkeit in modernen JavaScript-Frameworks; Sutton entwickelte das «focus management after state changes»-Pattern: wenn JavaScript den DOM ändert (Modal öffnet; neue Seite lädt; Content wird geladen) muss der Fokus programmatisch auf das neue Element gesetzt werden damit Tastaturnutzer nicht die Orientierung verlieren. Die :focus-visible CSS-Pseudoklasse (W3C CSS Selectors Level 4; Chrome 86; November 2020; Firefox 85; Januar 2021; Safari 15.4; März 2022) löste das visuelle Design-Problem: :focus zeigte Fokus-Ringe bei Maus-Klick auf Buttons (unerwünschter Effekt für sehende Nutzer) und bei Tastatur-Navigation; :focus-visible zeigt Fokus-Ring nur bei Tastatur-Navigation (nicht bei Maus); CSS: button:focus-visible { outline: 2px solid blue; outline-offset: 2px; } button:focus:not(:focus-visible) { outline: none; }; oder moderner: :focus-visible für alle interaktiven Elemente als einzige Regel.

Tab-Reihenfolge, Focus-Management und Skip-Links

ARIA-Keyboard-Patterns und Testing

Praxistipp: Der einfachste Keyboard-Accessibility-Test: Stecken Sie die Maus aus und navigieren Sie Ihre gesamte Website nur mit Tab, Shift+Tab, Enter, Leertaste und Pfeiltasten. Drei häufige Probleme die Sie fast immer finden: (1) Unsichtbarer Fokus – Sie tabben irgendwohin aber sehen nicht wo Sie sind (Fix: :focus-visible-Styles hinzufügen); (2) Fokus-Falle im Modal – Sie kommen nicht mehr heraus (Fix: Focus-Trap implementieren + Escape-Handler); (3) Logik-Sprung in der Tab-Reihenfolge – der Fokus springt unerwartet an eine andere Stelle (Fix: DOM-Reihenfolge an visuelle Reihenfolge angleichen). Diese drei Fixes allein lösen ~70% aller Keyboard-Accessibility-Probleme die bei Accessibility-Audits gefunden werden.