Vollständige Tastaturbedienbarkeit ist eine der grundlegendsten Anforderungen der Web-Barrierefreiheit und über die harmonisierte Norm EN 301 549 v3.2.1 ein verbindlicher Prüfmaßstab des Barrierefreiheitsstärkungsgesetzes (BFSG). Wer eine Funktion seines Shopify-Stores ausschließlich per Maus bedienbar macht, verstößt gegen WCAG 2.1.1 (Keyboard, Stufe A) und damit gegen das BFSG, das seit dem 28. Juni 2025 für alle Anbieter oberhalb der Kleinstunternehmen-Schwelle gilt. Dieser Beitrag zeigt, welche konkreten Shopify-Bausteine in der Praxis am häufigsten an der Tastatur scheitern, welche WCAG-Erfolgskriterien jeweils greifen und wie Sie jeden Punkt selbst prüfen und beheben.
Tastaturbedienbarkeit betrifft weit mehr Menschen als nur Personen, die eine physische Tastatur statt einer Maus nutzen. Screenreader-Nutzer navigieren ausschließlich über die Tastaturschnittstelle. Menschen mit motorischen Einschränkungen verwenden Sprachsteuerung, Schaltersteuerungen oder Mundstäbe, die alle auf der Tastatur-API des Browsers aufsetzen. Wenn ein Bedienelement nicht per Tastatur erreichbar ist, ist es für diese gesamte Nutzergruppe unerreichbar. Im E-Commerce-Kontext kann das den Kauf vollständig verhindern: Ein nicht tastaturbedienbares Megamenü blockiert den Weg zur Kollektion, ein nicht tastaturbedienbarer "In den Warenkorb"-Button den Abschluss.
Das BFSG (BGBl. 2021 I S. 2970) setzt die EU-Richtlinie 2019/882 (European Accessibility Act, EAA) in deutsches Recht um. Online-Shops fallen nach § 1 Abs. 3 Nr. 5 BFSG als "Dienstleistungen im elektronischen Geschäftsverkehr" in den Anwendungsbereich. Über Anlage I der EU-Richtlinie 2019/882 verweist das BFSG auf die harmonisierte Norm EN 301 549 v3.2.1, die in ihrem Kapitel 9 die WCAG-2.1-AA-Erfolgskriterien für Webinhalte übernimmt.
Bei Verstößen sieht § 37 BFSG Bußgelder vor. Nach § 37 Abs. 2 BFSG beträgt der Rahmen für das nicht konforme Anbieten oder Erbringen einer Dienstleistung bis zu 100.000 EUR, für bestimmte Auskunfts- und Mitwirkungspflichten bis zu 10.000 EUR. AccessifyAI hilft, solche Verstöße zu finden und zu beheben, garantiert aber keine Rechtskonformität oder BFSG-Konformität. Die rechtliche Verantwortung trägt nach § 8 BFSG der Diensteanbieter, also der Händler.
Vom Anwendungsbereich ausgenommen sind nach § 3 Abs. 3 BFSG nur Kleinstunternehmen, also Unternehmen mit weniger als zehn Beschäftigten UND einem Jahresumsatz oder einer Jahresbilanzsumme unter zwei Millionen EUR. Beide Bedingungen müssen kumulativ erfüllt sein.
Vier Erfolgskriterien aus EN 301 549 v3.2.1 bilden zusammen das Pflichtenheft für die Tastaturbedienung. Alle vier sind über das BFSG verbindlich.
| Kriterium |
Inhalt |
Stufe |
| WCAG 2.1.1 Keyboard |
Jede Funktion muss per Tastatur bedienbar sein |
A |
| WCAG 2.1.2 No Keyboard Trap |
Der Fokus muss jedes Element auch wieder verlassen können |
A |
| WCAG 2.4.3 Focus Order |
Die Fokusreihenfolge muss Sinn und Bedienbarkeit erhalten |
A |
| WCAG 2.4.7 Focus Visible |
Der Fokus muss sichtbar sein |
AA |
Diese vier Stufen-A- und AA-Kriterien sind nicht optional. WCAG 2.1.1, 2.1.2 und 2.4.3 sind Stufe A, das niedrigste und damit am striktesten geforderte Konformitätsniveau. WCAG 2.4.7 ist Stufe AA und damit Teil des rechtlich referenzierten Mindestmaßstabs.
Bevor Sie einzelne Bausteine prüfen, führen Sie den Grundtest durch. Legen Sie die Maus beiseite. Klicken Sie einmal in die Adressleiste des Browsers und drücken Sie dann nur die Tabulatortaste, um in die Seite einzusteigen.
Arbeiten Sie sich mit folgenden Tasten durch Ihren Store:
- Tabulator bewegt den Fokus zum nächsten Element, Umschalt + Tabulator zum vorherigen.
- Eingabetaste löst Links und Buttons aus.
- Leertaste löst Buttons und Checkboxen aus.
- Pfeiltasten bedienen zusammengesetzte Elemente wie Auswahllisten, Radio-Gruppen und manche Menüs.
- Escape schließt Modals und Overlays.
Achten Sie bei jedem Schritt auf drei Dinge: Sehen Sie immer, wo der Fokus gerade steht (das ist WCAG 2.4.7)? Folgt die Reihenfolge dem visuellen und logischen Aufbau (das ist WCAG 2.4.3)? Und können Sie aus jedem Element wieder heraus (das ist WCAG 2.1.2)? Wenn Sie an einer Stelle nicht weiterkommen, den Fokus verlieren oder festsitzen, haben Sie einen Verstoß gefunden.
Das Navigationsmenü ist der häufigste Stolperstein. Ein einfaches Dropdown-Menü ist meist unproblematisch, wenn es auf nativen HTML-Elementen aufsetzt. Kritisch wird es bei Megamenüs, die ihre Unterebenen nur per :hover öffnen.
Ein Untermenü, das ausschließlich beim Überfahren mit der Maus erscheint und keine Tastaturlogik besitzt, ist für Tastaturnutzer nicht erreichbar. Das verstößt gegen WCAG 2.1.1. Erkennbar ist das Problem im Grundtest daran, dass der Fokus zwar auf den Hauptmenüpunkt springt, die Unterpunkte aber unsichtbar bleiben und nicht angesteuert werden können.
Eine konforme Implementierung blendet das Untermenü auch bei Tastaturfokus ein und meldet seinen Zustand über aria-expanded. Ein Menü-Trigger sieht im Kern so aus:
<button aria-expanded="false" aria-controls="submenu-damen">
Damen
</button>
<ul id="submenu-damen" hidden>
<li><a href="/collections/kleider">Kleider</a></li>
<li><a href="/collections/jacken">Jacken</a></li>
</ul>
Das begleitende JavaScript schaltet beim Fokussieren und beim Aktivieren aria-expanded zwischen true und false um und entfernt beziehungsweise setzt das hidden-Attribut. Wichtig ist, dass das Öffnen nicht allein an mouseover hängt, sondern auch an focus und an die Aktivierung per Tastatur.
In der Praxis stammen viele Megamenüs nicht aus dem Theme selbst, sondern aus installierten Apps. Diese fügen ihr eigenes CSS und JavaScript über App-Embeds ein. Prüfen Sie das Menü deshalb immer im realen, installierten Zustand und nicht im Auslieferungszustand des nackten Themes.
Filter auf Kollektionsseiten (nach Größe, Farbe, Preis, Verfügbarkeit) sind ein zweiter häufiger Schwachpunkt. Shopify-Themes setzen Filter zunehmend als auf- und zuklappbare Panels um, oft mit eigenem JavaScript für die Aktualisierung der Produktliste ohne Seitenneuladen.
Drei Tastaturprobleme treten hier regelmäßig auf:
- Der Auf-/Zuklapp-Schalter ist ein
<div> statt eines <button>. Ein <div onclick=""> erhält keinen Tastaturfokus und reagiert nicht auf die Eingabetaste. Korrekt ist ein echtes <button> oder ein <div role="button" tabindex="0"> mit Tastaturlogik.
- Die Filter-Checkboxen sind durch Custom-Styling nicht mehr fokussierbar. Wer native Checkboxen per
display: none ausblendet und durch ein Pseudoelement ersetzt, entfernt oft auch die Tastaturbedienbarkeit. Die native Checkbox muss zugänglich bleiben (etwa per visually-hidden-Technik statt display: none).
- Nach dem Anwenden eines Filters springt der Fokus ins Leere. Wird die Produktliste per JavaScript neu geladen, muss der Fokus sinnvoll gesetzt werden, damit die Reihenfolge erhalten bleibt (WCAG 2.4.3).
Der seitlich einfahrende Warenkorb (Cart-Drawer) ist ein Modal-ähnliches Element und unterliegt damit gleich mehreren Kriterien. Beim Öffnen sollte der Fokus in den Drawer wandern. Solange der Drawer offen ist, sollte der Fokus innerhalb des Drawers bleiben (eine sogenannte Fokusfalle, die hier erwünscht ist). Beim Schließen sollte der Fokus zum auslösenden Element zurückkehren.
Hier lauert ein subtiler Konflikt mit WCAG 2.1.2 (No Keyboard Trap). Eine Fokusfalle innerhalb eines geöffneten Modals ist erlaubt und sogar gewünscht, aber nur, wenn der Nutzer das Modal jederzeit per Tastatur wieder verlassen kann, üblicherweise mit der Escape-Taste. Ein Drawer, der den Fokus festhält und sich nicht per Tastatur schließen lässt, ist ein echter Keyboard-Trap und damit ein Verstoß.
Prüfschritt: Öffnen Sie den Cart-Drawer per Tastatur. Drücken Sie Tabulator mehrfach. Der Fokus muss innerhalb des Drawers zirkulieren und darf nicht hinter den Drawer auf die abgedunkelte Seite springen. Drücken Sie dann Escape. Der Drawer muss sich schließen und der Fokus muss zum Warenkorb-Symbol zurückkehren.
Quick-View-Modals, Größentabellen-Pop-ups und Newsletter-Overlays folgen derselben Logik wie der Cart-Drawer. Typische Verstöße sind ein Modal, das sich nur per Maus über ein X-Symbol schließen lässt und nicht auf Escape reagiert (Verstoß gegen WCAG 2.1.1 und 2.1.2), ein Fokus, der nach dem Schließen im unsichtbaren Modal hängenbleibt (Verstoß gegen WCAG 2.4.3), oder ein Modal, dessen Inhalt der Tastaturnutzer nie erreicht, weil der Fokus auf dem Auslöser im Hintergrund bleibt. Die korrekte Reihenfolge ist immer dieselbe: beim Öffnen Fokus in das Modal, Fokus während der Anzeige halten, Schließen per Escape ermöglichen, beim Schließen Fokus zurück zum Auslöser.
Der Standard-Checkout von Shopify wird von Shopify selbst gepflegt und ist auf Tastaturbedienbarkeit ausgelegt. Eigene Erweiterungen über Checkout Extensibility fallen jedoch in Ihre Verantwortung nach § 8 BFSG. Ein selbst hinzugefügtes Feld (etwa eine Geschenknachricht, eine Liefertag-Auswahl oder ein Zustimmungs-Häkchen) muss per Tastatur erreichbar, beschriftet und auslösbar sein.
Prüfen Sie alle eigenen Checkout-Felder im Grundtest. Achten Sie besonders auf benutzerdefinierte Auswahlelemente, die ein natives <select> durch ein gestyltes JavaScript-Widget ersetzen, denn diese verlieren häufig die Pfeiltasten-Bedienung.
Über alle Bausteine hinweg ist der mit Abstand häufigste Tastaturfehler in Shopify-Themes eine einzige CSS-Regel: *:focus { outline: none; } oder Varianten davon. Diese Anweisung entfernt den nativen Fokusring des Browsers und verstößt damit gegen WCAG 2.4.7 (Focus Visible). Ein Tastaturnutzer sieht dann nicht mehr, wo er sich befindet, obwohl die Bedienung technisch funktioniert.
Suchen Sie in Ihrem Theme-CSS und in den von Apps eingespielten Stylesheets nach outline: none und outline: 0. Die saubere Korrektur ersetzt die pauschale Unterdrückung durch einen sichtbaren, kontrastreichen Indikator und nutzt dabei :focus-visible, damit der Ring nur bei Tastaturbedienung erscheint und nicht bei jedem Mausklick:
*:focus-visible {
outline: 2px solid currentColor;
outline-offset: 2px;
}
Der Indikator muss ausreichend Kontrast zum Hintergrund haben, damit er tatsächlich erkennbar ist. Eine zwei Pixel breite Linie in der aktuellen Textfarbe erfüllt das in den meisten Themes.
Die Tastaturbedienung lässt sich nur teilweise automatisiert prüfen. Der manuelle Grundtest bleibt unverzichtbar, weil kein Werkzeug zuverlässig erkennt, ob die Fokusreihenfolge "Sinn ergibt". Ergänzend helfen folgende Werkzeuge:
| Werkzeug |
Zweck |
Kosten |
| Manueller Tastaturtest |
Fokusreihenfolge, Fokusfallen, Erreichbarkeit |
kostenlos |
| axe DevTools |
Erkennt fehlende Namen, tabindex-Fehler, ARIA-Probleme |
kostenlose Variante |
| Lighthouse (Chrome) |
Teilprüfung interaktiver Elemente |
kostenlos |
| NVDA Screenreader |
Manuelle Prüfung der Tastatur-/Sprachausgabe |
kostenlos |
| AccessifyAI |
Shopify-spezifische Überprüfung mit Liquid-Korrekturvorschlägen |
Free-Tier, ab 9,99 USD/Monat |
Welche dieser Tastaturprobleme in Ihrem konkreten Store stecken, zeigt nur ein echter Test auf Ihrer aktuellen Theme-Version und im installierten Zustand mit allen aktiven Apps. Ich habe AccessifyAI entwickelt, weil allgemeine Werkzeuge zwar einen Verstoß melden, aber nicht sagen, in welcher Liquid-Datei oder welchem Section-Snippet die Korrektur erfolgen muss. AccessifyAI ordnet den Befund dem Shopify-Code-Modell zu und gibt statt eines Overlays einen Korrekturvorschlag als Liquid-Diff aus, den Sie vor der Übernahme begutachten können. Wenn Sie zunächst nur sehen wollen, wie es um Ihren Store steht, können Sie ohne Installation den kostenlosen On-Page-Scanner auf accessify.ensomedia.pl nutzen. Die App selbst finden Sie im Shopify App Store.
- Führen Sie den zehnminütigen Grundtest auf Startseite, einer Kollektion, einer Produktseite und im Warenkorb durch.
- Suchen Sie in Theme- und App-CSS nach
outline: none und ersetzen Sie es durch einen :focus-visible-Indikator.
- Prüfen Sie Megamenü und Filter gezielt auf
<div>-Pseudobuttons und :hover-only-Logik.
- Testen Sie jeden Drawer und jedes Modal auf Escape-Schließbarkeit und Fokusrückkehr.
- Prüfen Sie eigene Checkout-Felder separat.
- Planen Sie eine erneute Überprüfung nach jedem Theme-Update und nach jeder neuen App-Installation, da beide neue Tastaturbarrieren einführen können.
Weitere fachliche Vertiefung finden Sie in unserer BFSG-Pflichtcheckliste mit 14 Punkten und im Beitrag zu den Unterschieden zwischen BFSG, WCAG und EAA.
Nein. WCAG 2.1.1 (Stufe A) verlangt, dass jede Funktion per Tastatur bedienbar ist. Maus- oder Touch-Bedienung darf zusätzlich angeboten werden, ersetzt die Tastaturbedienbarkeit aber nicht. Über EN 301 549 v3.2.1 ist dieses Kriterium nach dem BFSG verbindlich.
Der von Shopify gepflegte Standard-Checkout ist auf Tastaturbedienbarkeit ausgelegt. Eigene Erweiterungen über Checkout Extensibility fallen jedoch nach § 8 BFSG in Ihre Verantwortung und müssen separat geprüft werden.
Nein, sofern der Nutzer das Modal jederzeit per Tastatur wieder verlassen kann, üblicherweise mit der Escape-Taste. WCAG 2.1.2 (No Keyboard Trap, Stufe A) verbietet nur Fallen, aus denen kein Tastatur-Ausweg führt. Ein Modal, das den Fokus hält, aber per Escape schließbar ist, ist konform.
Nur, wenn Sie ihn durch einen gleichwertigen, sichtbaren Indikator ersetzen. Eine ersatzlose Entfernung des Fokusrings verstößt gegen WCAG 2.4.7 (Focus Visible, Stufe AA). Empfohlen ist :focus-visible mit einem kontrastreichen outline.
Nein. Kein Werkzeug kann Rechtskonformität garantieren, und die Fokusreihenfolge im Sinne von WCAG 2.4.3 lässt sich nur teilweise automatisiert prüfen. Werkzeuge, auch AccessifyAI, helfen beim Finden und Beheben von Verstößen. Die rechtliche Verantwortung trägt nach § 8 BFSG der Händler.
Nach § 8 BFSG ist fortlaufende Konformität gefordert, nicht eine einmalige Prüfung. Jedes Theme-Update, jede eigene Section und jede neue App kann eine Tastaturbarriere einführen. Eine erneute Überprüfung nach jedem strukturellen Eingriff ist sinnvoll.
Tastaturbedienbarkeit ist über EN 301 549 v3.2.1 und damit über das BFSG verbindlich und ruht auf vier Erfolgskriterien: WCAG 2.1.1 (Keyboard, A), 2.1.2 (No Keyboard Trap, A), 2.4.3 (Focus Order, A) und 2.4.7 (Focus Visible, AA). In Shopify-Stores scheitern am häufigsten Megamenüs mit reiner Hover-Logik, Filter mit <div>-Pseudobuttons, Cart-Drawer und Modals ohne Escape-Schließung sowie die pauschale CSS-Regel outline: none. Der zehnminütige Grundtest ohne Maus deckt die meisten dieser Punkte auf. Eigene Checkout-Felder und von Apps eingespielte Bausteine müssen separat geprüft werden, immer im installierten Zustand und auf der aktuell ausgespielten Theme-Version.