Barrierefreie Tastaturbedienung: die Anleitung für Online-Shops
Kurz gefasst — alles muss per Tastatur funktionieren
Ein großer Teil der Nutzenden verwendet keine Maus: blinde Menschen mit Screenreader, Menschen mit eingeschränkter Handmotorik, Nutzende von Sprachsteuerung oder adaptiven Tastaturen. Das Barrierefreiheitsstärkungsgesetz (BFSG) (EN 301 549 / WCAG 2.1 AA), seit dem 28. Juni 2025 für den E-Commerce verbindlich, verlangt, dass ein Shop allein mit der Tastatur vollständig bedienbar ist. Die Kernpunkte:
- Alles ist per Tastatur erreichbar und bedienbar — Menüs, Filter, Produktseite, Warenkorb, Kasse (Kriterium 2.1.1);
- Keine Tastaturfalle: Du kannst ein Element immer mit Tab oder Esc verlassen (Kriterium 2.1.2);
- Logische Tab-Reihenfolge, die der visuellen und der Lesereihenfolge folgt (Kriterium 2.4.3);
- Fokus immer sichtbar: Du siehst jederzeit, wo du bist (Kriterium 2.4.7);
- Ein Sprunglink, um das Menü zu überspringen und direkt zum Inhalt zu gelangen (Kriterium 2.4.1);
- Kein überraschender Kontextwechsel, nur weil ein Element den Fokus erhält (Kriterium 3.2.1).
Schnelltest: Leg die Maus weg und führe einen vollständigen Kauf allein mit Tab, Enter und den Pfeiltasten durch. Wenn du hängen bleibst, bleiben es deine Kundinnen und Kunden auch.
Die Tastatur ist der gemeinsame Nenner der Barrierefreiheit: ein Screenreader, eine Sprachsteuerung, ein Tastschalter oder eine adaptive Tastatur stützen sich alle auf dieselbe Logik der Tastaturnavigation. Lässt sich dein Shop vollständig per Tastatur durchlaufen, räumt das mit einem Schlag einen großen Teil der Barrieren aus. Umgekehrt: Ein einziger Button, der im Bestellprozess nicht per Tastatur erreichbar ist, und der Kauf ist verloren. Hier sind die sechs WCAG-Regeln, die das BFSG verlangt, und wie du sie in fünf Minuten prüfst.
Warum die Tastatur im Zentrum steht
Viele Menschen können — oder wollen — keine Maus benutzen: Nutzende von Screenreadern (die sich per Tastatur bewegen), Menschen mit motorischen Einschränkungen, die präzises Zeigen unmöglich machen, Nutzende von Sprachsteuerung oder adaptiven Geräten (Tastschalter, ergonomische Tastaturen). Alle stützen sich auf dieselben Grundlagen: Tab zum nächsten interaktiven Element, Umschalt+Tab zurück, Enter / Leertaste zum Auslösen, die Pfeiltasten innerhalb von Komponenten (Menüs, Listen, Karussells).
Das BFSG schafft keine gesonderte „Tastatur"-Regel: Die Grundlage bleibt EN 301 549, basierend auf WCAG 2.1 Stufe AA, für E-Commerce-Dienstleistungen seit dem 28. Juni 2025 anwendbar. Aber die Tastaturbedienbarkeit ist ihr Fundament: Sie ist das allererste Prinzip („Bedienbar") und der schnellste Test, den du selbst durchführen kannst.
Die 6 Regeln der Tastaturbedienung
Jede Funktion ist ohne Maus erreichbar und bedienbar
Kriterium 2.1.1 (Tastatur) verlangt, dass jede Funktionalität allein mit der Tastatur nutzbar ist: das Menü öffnen, einen Filter anwenden, eine Variante wählen, in den Warenkorb legen, die Kasse abschließen. Die klassische Falle: ein „anklickbares" Element, gebaut aus einem <div> oder einem <span> plus einem onclick, das nie den Fokus erhält. Verwende native Elemente (<a>, <button>), die standardmäßig fokussierbar und bedienbar sind; andernfalls ergänze tabindex="0", eine ARIA-Rolle und die Behandlung der Tasten Enter/Leertaste.
<button>; Filter als native Checkboxen; ein Dropdown-Menü, das sich per Tastatur öffnet.<div onclick> als Button verwendet; ein Farbwähler, der nur auf die Maus reagiert.→ Siehe auch die Anleitung für barrierefreien Checkout & Formulare.
Du kannst ein Element immer verlassen
Kriterium 2.1.2 (Keine Tastaturfalle) verbietet, dass eine Komponente den Fokus einfängt, ohne dass es per Tastatur einen Ausweg gibt. Häufige Übeltäter: ein modales Fenster (ein „Newsletter"-Pop-up, ein Größenwähler), aus dem du nicht herauskommst, ein Videoplayer oder ein Drittanbieter-Widget, das Tab festhält. Regel: Du musst mit Tab / Umschalt+Tab hinauskommen, und jedes Modal muss sich mit Esc schließen und den Fokus dorthin zurückgeben, wo er begann.
Das Tabben folgt der visuellen und der Lesereihenfolge
Kriterium 2.4.3 (Fokus-Reihenfolge) verlangt, dass du dich durch die Elemente in einer Reihenfolge bewegst, die zur visuellen Anordnung passt: von oben nach unten, von links nach rechts, ohne verwirrende Sprünge. Das wird vor allem durch die Reihenfolge des HTML (die DOM-Reihenfolge) bestimmt, nicht durch das CSS, das die Anzeige umsortiert. Vermeide positive tabindex-Werte (tabindex="3"…): Sie zerstören die natürliche Reihenfolge und erzeugen fast immer Inkonsistenzen.
Du siehst jederzeit, wo du bist
Kriterium 2.4.7 (Fokus sichtbar) verlangt einen sichtbaren Fokusindikator, der das aktive Element markiert, während du per Tastatur navigierst. Ein sehr häufiger Fehler: ein outline: none im CSS, das die Kontur des Browsers entfernt, „damit es aufgeräumt aussieht" — die Person weiß nicht mehr, wo sie ist. Entferne sie nie ohne Ersatz: Setze einen gut kontrastierten :focus-visible-Stil (eine kräftige Kontur, einen Halo). Nützliche Erinnerung: Dieser Indikator muss selbst genug Kontrast haben (mindestens 3:1 zum Hintergrund).
*:focus { outline: none } ohne Alternative; ein kaum sichtbarer Fokus (blasses Grau auf hellem Hintergrund).→ Zum Kontrast des Fokusindikators selbst siehe die Anleitung für barrierefreien Farbkontrast.
Das Menü überspringen und direkt zum Inhalt
Kriterium 2.4.1 (Blöcke umgehen) fordert eine Möglichkeit, wiederholte Blöcke zu überspringen — typischerweise den Kopfbereich und das große Navigationsmenü —, um direkt zum Inhalt zu gelangen. Die Standardlösung ist ein Sprunglink („Zum Inhalt springen") ganz oben, visuell verborgen, aber der beim Fokus erscheint beim ersten Tab. Ohne ihn muss eine Person, die die Tastatur nutzt, auf jeder Seite Dutzende Menülinks durchlaufen, bevor sie die Produkte erreicht. Eine Struktur mit Landmarken (<header>, <nav>, <main>) unterstützt diese Navigation zusätzlich für Screenreader.
→ Sprunglink und Landmarken hängen an der Seitenstruktur: siehe die Anleitung für eine barrierefreie Überschriftenstruktur.
Bloßes Fokussieren ändert den Kontext nicht
Kriterium 3.2.1 (Bei Fokus) verbietet einen Kontextwechsel, nur weil ein Element den Fokus erhält: ein neues Fenster öffnen, ein Formular absenden, woanders hin navigieren oder die Seite abrupt umbauen, sobald du auf einem Feld landest. Eine wichtige Aktion muss immer eine ausdrückliche Bestätigung verlangen (Enter drücken, einen Button klicken). Das kommt häufig bei schlecht programmierten nativen Dropdowns (<select>) vor, die umleiten, sobald sich der Wert ändert, ohne „Übernehmen"-Button.
<select>, das die Seite neu lädt, sobald du per Tastatur daraufkommst; ein Feld, das beim Fokus einen neuen Tab öffnet.Die Tastaturkriterien auf einen Blick
| Per Tastatur zu prüfender Punkt | Stufe | WCAG-Kriterium |
|---|---|---|
| Jede Funktion allein per Tastatur nutzbar | A | 2.1.1 |
| Keine Tastaturfalle (du kommst heraus) | A | 2.1.2 |
| Logische Tab-Reihenfolge | A | 2.4.3 |
| Sichtbarer Fokusindikator | AA | 2.4.7 |
| Blöcke umgehen (Sprunglink) | A | 2.4.1 |
| Kein Kontextwechsel beim Fokus | A | 3.2.1 |
| Einzeltasten-Kürzel abschaltbar / umbelegbar | A | 2.1.4 |
outline: none „aus ästhetischen Gründen" entfernen. Das macht die Tastaturnavigation unsichtbar — die nutzende Person weiß nicht mehr, wo sie ist. Entferne die Kontur nie, ohne sie durch einen klar kontrastierten :focus-visible-Stil zu ersetzen. Die Korrektur sind oft eine Handvoll CSS-Zeilen.
<div> programmierten Button um, macht den Fokus nicht sichtbar und erzeugt keine logische Tab-Reihenfolge — das sind Mängel im Code deiner Seiten. Zur Erinnerung: Die US-Behörde FTC verhängte gegen einen Overlay-Anbieter ein Bußgeld von 1.000.000 $ wegen irreführender Konformitätsversprechen. Siehe die BFSG-Checkliste für das, was wirklich zählt.Wie du die Tastaturbedienung prüfst
Der nützlichste Test ist zugleich der einfachste — er braucht überhaupt kein Werkzeug:
- Leg die Maus weg und durchlaufe eine ganze Seite mit Tab (vorwärts), Umschalt+Tab (zurück), Enter / Leertaste (auslösen), den Pfeiltasten in Menüs und Listen.
- Beobachte den Fokusindikator: Siehst du immer, wo du bist? Verschwindet er irgendwo?
- Prüfe die Reihenfolge: Folgt der Ablauf der Lesereihenfolge, ohne überraschende Sprünge?
- Führe einen vollständigen Kauf per Tastatur durch — Suche, Filter, Produktseite, in den Warenkorb, Kasse. Alles ohne die Maus zu berühren.
- Öffne die Pop-ups und Modals: Kommst du mit Esc und Tab heraus?
Ein automatischer Scan (axe-core, WAVE, Lighthouse) erkennt einige tastaturbezogene Mängel — ein interaktives Element ohne zugänglichen Namen, eine fehlende Landmarken-Struktur, verdächtige tabindex-Werte —, aber er kann eine Tastaturfalle nicht „erspüren", nicht beurteilen, ob die Tab-Reihenfolge logisch ist, und nicht bestätigen, dass sich alles auslösen lässt. Der manuelle Tastaturtest bleibt unverzichtbar: Er dauert fünf Minuten und zeigt das Wesentliche. Danach fließt er direkt in den BFSG-Express-Test ein.
Prüfe die Barrierefreiheit deines Shops kostenlos
DeclareAccess scannt eine Seite deines Shops mit der axe-core-Engine nach WCAG 2.1 AA, meldet die Verstöße (Tastatur, Fokus, Struktur, Kontrast, Formulare…) und erzeugt anschließend das veröffentlichungsfertige Barrierefreiheitsdokument — deutsch („Informationen zur Barrierefreiheit", § 14 BFSG), englisch, französisch (RGAA), italienisch oder spanisch. Kostenlos, ohne Kreditkarte.
WCAG-Bericht per E-Mail innerhalb von 1 Werktag.
Erhalten. Deine Audit-Anfrage ist gespeichert — du erhältst deinen WCAG-Bericht per E-Mail innerhalb von 1 Werktag.
Häufige Fragen
Erkennt ein automatischer Scan Tastaturprobleme?
Nur teilweise. Eine Engine wie axe-core erfasst einige Mängel (ein interaktives Element ohne zugänglichen Namen, eine fehlende Landmarken-Struktur, verdächtige tabindex-Werte), aber sie kann eine Tastaturfalle nicht „erspüren", nicht beurteilen, ob die Tab-Reihenfolge logisch ist, und nicht prüfen, dass sich alles auslösen lässt. Der manuelle Tastaturtest bleibt unverzichtbar: Er dauert fünf Minuten und zeigt das Wesentliche.
Was sind Tab-Reihenfolge und tabindex?
Die Tab-Reihenfolge ist die Abfolge, in der sich der Fokus von einem interaktiven Element zum nächsten bewegt, wenn du Tab drückst. Standardmäßig folgt sie der Reihenfolge im HTML-Quelltext. tabindex="0" macht ein nicht-natives Element an der richtigen Stelle fokussierbar; tabindex="-1" macht es per Skript fokussierbar, aber außerhalb der Tab-Abfolge. Vermeide positive Werte (tabindex="1", "2"…): Sie erzwingen eine künstliche Reihenfolge, die fast immer Inkonsistenzen erzeugt.
Warum sollte man die Fokuskontur nie entfernen?
Weil die outline in vielen Browsern das einzige visuelle Signal ist, das zeigt, wo der Tastaturfokus liegt. Sie zu entfernen (outline: none) ohne Ersatz macht die Tastaturnavigation unmöglich zu verfolgen und verstößt gegen Kriterium 2.4.7. Wenn dir der Standardstil nicht gefällt, ersetze ihn durch einen eigenen, gut kontrastierten :focus-visible-Indikator, statt ihn zu löschen.
Was ist ein Sprunglink, und ist er Pflicht?
Ein Sprunglink („Zum Inhalt springen") ist ein Link ganz am Anfang der Seite, oft verborgen, bis er den Fokus erhält, der es erlaubt, die wiederholten Blöcke (Kopf, Menü) zu überspringen und direkt zum Hauptinhalt zu gelangen. Er ist der übliche Weg, Kriterium 2.4.1 (Blöcke umgehen), Stufe A, zu erfüllen; eine Landmarken-Struktur (<nav>, <main>) kann ebenfalls beitragen. Für eine Website mit großem Menü ist er praktisch unverzichtbar.
Reicht die Tastaturbedienung, um konform zu sein?
Nein. Sie ist ein wesentliches Fundament, aber die BFSG-Konformität umfasst das ganze WCAG 2.1 AA: Farbkontrast, Textalternativen für Bilder, korrekt beschriftete Formulare, für Screenreader lesbare Inhalte und so weiter. Eine per Tastatur perfekt bedienbare Website kann bei anderen Kriterien dennoch durchfallen. Die Tastaturbedienung ist trotzdem der beste Ausgangspunkt, weil sich viele andere Barrieren genau dort zeigen.