Ein Jahr nach dem Wirksamwerden des BFSG hat die Branche einen klaren Patch-Schwerpunkt gesetzt: den…
Tastatur-Navigation 2026: 6 BFSG-Touchpoints, die Shops verfehlen
Ein Jahr nach dem Wirksamwerden des BFSG hat die Branche einen klaren Patch-Schwerpunkt gesetzt: den Checkout. Formular-Label-Zuordnungen, Focus-Management beim Step-Wechsel, Fehlermeldungen mit aria-describedby - das sitzt bei den meisten DACH-Storefronts inzwischen. Was bleibt, sind sechs andere Touchpoints, die systematisch vergessen werden.
Das ist keine Randnotiz. Tastatur-Nutzer durchlaufen Filter, Mega-Menü und Search-Autocomplete, bevor sie überhaupt im Checkout ankommen. Wenn diese Flows nicht funktionieren, bricht die Session früher ab - nicht erst am Bezahl-Button.
Dieser Post geht durch die sechs Touchpoints in der Reihenfolge, in der ein Tastatur-Nutzer einem typischen DACH-Storefront-Besuch begegnet: von der ersten Navigation bis zum Cookie-Banner. Pro Touchpoint: das konkrete BFSG-Defizit, die WCAG-2.2-Verankerung und ein umsetzbares Frontend-Pattern.
Touchpoint 1: Filter-Drawer
Das Defizit
Filter-Drawer-Implementierungen haben ein wiederkehrendes Problem: wenn der Drawer per Tastatur geöffnet wird, landet der Fokus irgendwo außerhalb - oft auf dem zuletzt fokussierten Element außerhalb des Drawers, manchmal auf body. Die Filteroptionen sind per Tab erreichbar, aber der Nutzer muss sich erst durch die gesamte Seite tasten, bevor er im Drawer ankommt.
Das zweite Problem: wenn der Drawer geschlossen wird, kehrt der Fokus nicht zum auslösenden "Filter"-Button zurück, sondern verliert sich. Der Nutzer muss die Seite von oben neu durchtasten.
WCAG 2.2 SC 2.1.1 (Tastatur) und SC 2.4.3 (Fokus-Reihenfolge) sind betroffen. Das BFSG schreibt diese Kriterien für Storefronts verpflichtend vor.
Das Pattern: Roving Tabindex im Drawer
Der Anti-Pattern ist hier nicht das fehlende Focus-Trap an sich - es ist das falsche Focus-Trap-Konzept. Ein modaler Dialog braucht einen harten Focus-Trap. Ein nicht-modaler Filter-Drawer braucht etwas anderes: einen Roving-Tabindex, der den fokussierbaren Bereich auf den Drawer beschränkt, solange er offen ist, und beim Schließen präzise zurücksetzt.
Konkretes Implementierungs-Muster:
// Beim Öffnen des Drawers
function openFilterDrawer(drawerEl, triggerEl) {
drawerEl.setAttribute('aria-expanded', 'true');
drawerEl.removeAttribute('inert');
// Fokus auf erstes interaktives Element im Drawer
const firstFocusable = drawerEl.querySelector(
'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
);
firstFocusable?.focus();
// Trigger-Referenz für Rückgabe speichern
drawerEl._triggerEl = triggerEl;// Beim Schließen function closeFilterDrawer(drawerEl) { drawerEl.setAttribute('aria-expanded', 'false'); drawerEl.setAttribute('inert', ''); // Fokus präzise zurück zum Trigger drawerEl._triggerEl?.focus(); } ```
Das inert-Attribut ist der Schlüssel: es entfernt alle Elemente im Drawer aus dem Tab-Order und der Accessibility-Tree, solange er geschlossen ist. Kein manuelles tabindex="-1"-Setzen auf 200 einzelnen Elementen nötig. Browser-Support: alle modernen Browser ab 2023.
Für die Filteroptionen innerhalb des Drawers empfiehlt sich zusätzlich ein Roving-Tabindex-Pattern, das Pfeiltasten-Navigation innerhalb von Checkbox-Gruppen erlaubt, analog zum ARIA Authoring Practices Guide Listbox-Pattern (https://www.w3.org/WAI/ARIA/apg/patterns/listbox/).
Touchpoint 2: Mega-Menü
Das Defizit
Hover-Only-Navigation ist das älteste ungelöste Accessibility-Problem in Storefronts. BFSG-relevant ist nicht nur die Frage, ob das Menü per Tastatur erreichbar ist - sondern ob die Hierarchie für Screenreader-Nutzer verständlich kommuniziert wird.
Das typische Defizit: das Mega-Menü ist eine verschachtelte <ul>-Struktur ohne ARIA-Semantik. Screenreader-Nutzer wissen nicht, dass sie sich in einem Navigations-Overlay befinden. Sie wissen nicht, wie tief die Hierarchie geht. Sie wissen nicht, ob es Untermenüs gibt, bevor sie in diese hineintaben.
WCAG 2.2 SC 1.3.1 (Info und Beziehungen) und SC 4.1.2 (Name, Funktion, Wert) sind betroffen.
Das Pattern: Tree-View mit ARIA-Semantik
Das ARIA Authoring Practices Guide Tree-View-Pattern (https://www.w3.org/WAI/ARIA/apg/patterns/treeview/) ist die Referenzimplementierung für hierarchische Navigationsstrukturen.
Minimal-Implementierung für ein zweistufiges Mega-Menü:
<nav aria-label="Hauptnavigation">
<ul role="tree">
<li role="treeitem" aria-expanded="false" aria-haspopup="true"
tabindex="0" id="nav-mode">
Mode
<ul role="group" aria-labelledby="nav-mode" hidden>
<li role="treeitem" tabindex="-1">
<a href="/damen">Damen</a>
</li>
<li role="treeitem" tabindex="-1">
<a href="/herren">Herren</a>
</li>
</ul>
</li>
</ul>
</nav>aria-expanded="false" signalisiert dem Screenreader, dass es Unterelemente gibt und ob diese gerade sichtbar sind. aria-haspopup="true" teilt mit, dass eine Unter-Navigation ausklappbar ist. Der Roving-Tabindex (nur das aktive Element hat tabindex="0", alle anderen -1) erlaubt Pfeiltasten-Navigation innerhalb des Menüs.
Escape schließt das Untermenü und gibt den Fokus an das auslösende Top-Level-Element zurück. Das ist ARIA-Pflicht, nicht Optional.
Touchpoint 3: Search-Autocomplete
Das Defizit
Search-Autocomplete ist einer der komplexesten Tastatur-Touchpoints, weil er zwei konkurrierende Fokus-Zustände hat: das Input-Feld hat den Fokus, aber der "aktive" Vorschlag kann sich durch Pfeiltasten-Navigation ändern, ohne dass der Fokus das Input verlässt.
Das typische Defizit: Vorschläge werden visuell hervorgehoben, aber der Screenreader liest das Input-Feld, nicht den aktiven Vorschlag. Tastatur-Nutzer wissen nicht, welcher Vorschlag gerade selektiert ist.
WCAG 2.2 SC 4.1.2 (Name, Funktion, Wert) ist betroffen: der Wert des Inputs kommuniziert nicht, was gerade in der Vorschlagsliste aktiv ist.
Das Pattern: Combobox mit aria-activedescendant
Das ARIA Combobox-Pattern (https://www.w3.org/WAI/ARIA/apg/patterns/combobox/) löst genau dieses Problem. Der Fokus bleibt im Input, aber aria-activedescendant zeigt auf das aktuell aktive Listbox-Item:
<label for="search-input">Produkt suchen</label>
<input
id="search-input"
type="text"
role="combobox"
aria-expanded="true"
aria-autocomplete="list"
aria-controls="search-listbox"
aria-activedescendant="suggestion-2"<ul id="search-listbox" role="listbox" aria-label="Suchvorschläge"> <li id="suggestion-1" role="option" aria-selected="false">Nike Air Max</li> <li id="suggestion-2" role="option" aria-selected="true">Nike Air Force</li> <li id="suggestion-3" role="option" aria-selected="false">Nike React</li> </ul> ```
Wenn der Nutzer Pfeil-unten drückt, ändert das JavaScript aria-activedescendant auf die ID des nächsten Items und setzt aria-selected="true" auf dieses Item. Der Screenreader liest das aktive Item vor, ohne dass der Fokus das Input verlässt.
aria-expanded="true" kommuniziert, dass die Vorschlagsliste gerade offen ist. aria-expanded="false" wenn die Liste kollabiert ist. Bei aria-expanded="false" sollte aria-activedescendant entfernt werden.
Dieser Pattern-Aufwand ist einmalig pro Storefront-Framework. Wer ihn als Komponente implementiert, hat ihn für alle Brands und alle Locales gleichzeitig gepatched.
Touchpoint 4: Cart-Mini (Warenkorb-Overlay)
Das Defizit
Das Mini-Cart-Overlay hat ein zweigeteiltes Accessibility-Problem. Erstens: wenn ein Produkt in den Warenkorb gelegt wird, gibt es oft keine zugängliche Benachrichtigung. Ein visueller Toast erscheint für 3 Sekunden - Screenreader-Nutzer bekommen nichts mit.
Zweitens: wenn das Mini-Cart-Overlay sich öffnet, passiert dasselbe wie beim Filter-Drawer - der Fokus geht nicht in das Overlay, der Nutzer muss es manuell ansteuern.
WCAG 2.2 SC 4.1.3 (Status-Meldungen) ist hier zentral: Status-Meldungen müssen programmatisch ermittelbar sein, auch ohne Fokus-Verlagerung.
Das Pattern: Live-Region für Cart-Updates
ARIA Live Regions sind die Lösung für Status-Meldungen ohne Fokus-Verlagerung. Ein role="status" oder aria-live="polite"-Container teilt dem Screenreader Updates mit, sobald sie in den DOM geschrieben werden:
<!-- Permanent im DOM, immer leer bis ein Update kommt -->
<div
role="status"
aria-live="polite"
aria-atomic="true"
class="sr-only"
id="cart-live-region"
>
</div>function announceCartUpdate(productName, quantity) {
const liveRegion = document.getElementById('cart-live-region');
// Erst leeren, dann neu befüllen - triggert den Screenreader
liveRegion.textContent = '';
requestAnimationFrame(() => {
liveRegion.textContent =
`${productName} wurde zum Warenkorb hinzugefügt. Warenkorb enthält jetzt ${quantity} Artikel.`;
});
}aria-atomic="true" stellt sicher, dass der Screenreader den gesamten Text der Live-Region vorliest, nicht nur den geänderten Teil. Der requestAnimationFrame-Trick ist notwendig, weil manche Screenreader eine DOM-Änderung ignorieren, wenn Text direkt überschrieben wird.
Die Live-Region ergänzt den visuellen Toast - sie ersetzt ihn nicht. Beide können parallel existieren.
Touchpoint 5: Account-Switch (Multi-Brand-Storefronts)
Das Defizit
Account-Switch-Komponenten in Multi-Brand-Storefronts haben ein spezifisches Problem: wenn der Nutzer zwischen Brands oder Accounts wechselt, lädt oft eine neue Seite oder ein neuer Content-Bereich. Die Tastatur-Navigation beginnt dabei häufig von oben - der Nutzer muss die gesamte Navigation erneut durchtasten, um zum eigentlichen Content zu kommen.
In Single-Brand-Storefronts ist das ein klassisches Problem für Nutzer, die oft denselben Weg zurücklegen. In Multi-Brand-Storefronts potenziert es sich: je nach Kontext variiert die Navigation-Struktur zwischen den Brands.
WCAG 2.2 SC 2.4.1 (Blöcke umgehen) schreibt vor, dass Nutzer die Möglichkeit haben müssen, wiederholte Navigation zu überspringen.
Das Pattern: Skip-Link-System für Multi-Brand-Kontexte
Skip-Links sind technisch simpel - ihr Einsatz in Multi-Brand-Storefronts ist aber nuancierter. Nicht ein generischer "Zum Inhalt springen"-Link, sondern ein kontextbewusstes Skip-Link-Set:
<!-- Am Anfang des <body>, vor jeder Navigation -->
<nav class="skip-links" aria-label="Seitennavigation überspringen">
<a href="#main-content" class="skip-link">Zum Hauptinhalt springen</a>
<a href="#search" class="skip-link">Zur Suche springen</a>
<a href="#account-nav" class="skip-link">Zum Account-Menü springen</a>
</nav>.skip-link {
position: absolute;
top: -40px;
left: 0;
background: #702CCE;
color: white;
padding: 8px;
z-index: 100;
/* Sichtbar nur wenn fokussiert */
transition: top 0.1s;.skip-link:focus { top: 0; } ```
Im Multi-Brand-Kontext kommt ein weiterer Skip-Link hinzu, der beim Brand-Switch aktiv wird:
<a href="#brand-main-content" class="skip-link"
aria-label="Zum Inhalt von [Brand-Name] springen">
Zu [Brand-Name]-Inhalt springen
</a>Wenn JavaScript den Brand-Switch ausführt, sollte der Fokus programmatisch auf #brand-main-content gesetzt werden - analog zum Seiten-Navigations-Pattern in Single-Page-Applications.
Diese Komponente ist ein Paradebeispiel für Frontend-Layer-Konfiguration: ein Skip-Link-Template mit Brand-Name-Variable, einmal gebaut, für n Brands instanziiert ohne Backend-Deployment.
Touchpoint 6: Cookie-Banner
Das Defizit
Cookie-Banner haben ein eigenes Kapitel im BFSG-Compliance-Gespräch, weil sie oft die ersten Elemente sind, die ein Nutzer nach dem Seitenaufruf sieht - oder vielmehr: sehen sollte.
Das typische Defizit ist zweigeteilt. Erstens: der Cookie-Banner wird zwar ins DOM eingefügt, aber der Fokus landet nicht automatisch auf ihm. Tastatur-Nutzer müssen den Banner ansteuern. Wenn sie das nicht tun, akzeptieren oder ablehnen sie Cookies nie - oder landen versehentlich in einer Endlosschleife zwischen Banner und Content.
Zweitens: wenn der Cookie-Banner sich schließt (Akzeptieren oder Ablehnen gedrückt), verliert der Fokus sich. Oft landet er auf body oder dem Overlay-Container, der gerade aus dem DOM entfernt wurde. Der Nutzer muss von Null anfangen.
WCAG 2.2 SC 2.1.1 (Tastatur) und SC 2.4.3 (Fokus-Reihenfolge) greifen hier. Ergänzend: da Cookie-Banner häufig über dem Content liegen und diesen für Tastatur-Nutzer unerreichbar machen, kommt SC 2.1.2 (Keine Tastaturfalle) in Betracht.
Das Pattern: Focus-Initial mit definiertem Return-Target
Der Cookie-Banner sollte beim Erscheinen sofort den Fokus auf sich ziehen. Das verhindert, dass Tastatur-Nutzer unabsichtlich mit dem Content hinter dem Banner interagieren:
function showCookieBanner(bannerEl) {
bannerEl.removeAttribute('hidden');
bannerEl.removeAttribute('inert');
// returnTarget ist der erste fokussierbare Seiteninhalt nach dem Banner
bannerEl._returnTarget = document.getElementById('main-content')
|| document.querySelector('main')// Kurze Verzögerung für CSS-Transition (falls Banner eingeblendet wird) requestAnimationFrame(() => { const firstButton = bannerEl.querySelector('button'); firstButton?.focus(); }); }
function dismissCookieBanner(bannerEl, accepted) { // Preference speichern saveCookiePreference(accepted); // Banner entfernen / verstecken bannerEl.setAttribute('hidden', ''); // Fokus definiert zurückgeben bannerEl._returnTarget?.focus(); } ```
<div
id="cookie-banner"
role="dialog"
aria-modal="false"
aria-labelledby="cookie-banner-title"
aria-describedby="cookie-banner-desc"
>
<h2 id="cookie-banner-title">Cookie-Einstellungen</h2>
<p id="cookie-banner-desc">
Diese Website nutzt Cookies für Analyse und Personalisierung.
Du kannst alle Cookies akzeptieren oder nur notwendige Cookies zulassen.
</p>
<button type="button" onclick="dismissCookieBanner(this.closest('[role=dialog]'), false)">
Nur notwendige Cookies
</button>
<button type="button" onclick="dismissCookieBanner(this.closest('[role=dialog]'), true)">
Alle akzeptieren
</button>
</div>role="dialog" mit aria-modal="false" ist hier die bewusste Wahl gegenüber aria-modal="true". Ein Cookie-Banner ist technisch kein modaler Dialog - der Nutzer kann (und soll laut DSGVO-Design-Prinzip) die Seite auch ohne Interaktion verlassen können. aria-modal="false" lässt Screenreader-Nutzer die gesamte Seite lesen, ohne im Dialog gefangen zu sein.
Was diese sechs Patterns gemeinsam haben
Keines dieser Patterns erfordert Backend-Änderungen. Kein Datenbank-Deploy, kein API-Rewrite, kein Replatforming-Projekt. Es ist Frontend-Layer-Konfiguration: Focus-Management, ARIA-Attribute, Live-Regions, Skip-Links.
Das hat eine direkte Konsequenz für Storefronts, die auf einem composable Frontend-Layer aufgebaut sind. Diese Patterns sind als Accessibility-Konfiguration pro Brand und pro Locale iterierbar. Ein Focus-Initial-Pattern für den Cookie-Banner wird einmal als Komponenten-Option definiert - alle Brands, die diese Komponente nutzen, bekommen das Pattern automatisch. Kein Brand-by-Brand-Patch-Zyklus.
Die Referenz-Implementierungen für alle hier beschriebenen ARIA-Patterns sind im W3C ARIA Authoring Practices Guide dokumentiert: https://www.w3.org/WAI/ARIA/apg/patterns/. Die WCAG 2.2 Success Criteria sind unter https://www.w3.org/TR/WCAG22/ nachvollziehbar.
Zur BFSG-Jahres-Bilanz und den Checkout-spezifischen Patterns: Checkout-Form-Accessibility und BFSG-Conversion 2026.
Den überblick zu systematischen Compliance-Lücken in deutschen Shops nach einem Jahr BFSG gibt: BFSG Ein-Jahres-Marke 2026.
Prioritäts-Reihenfolge für den nächsten Sprint
Wenn du nicht alle sechs Patterns gleichzeitig angehen kannst, hier eine Triage nach BFSG-Risiko und Implementierungs-Aufwand:
Hohes Risiko, überschaubarer Aufwand: Cookie-Banner (Touchpoint 6) und Cart-Mini-Live-Region (Touchpoint 4). Cookie-Banner-Focus-Management ist 20-30 Zeilen JavaScript. Live-Region ist ein statischer DOM-Container plus drei JavaScript-Zeilen pro Cart-Update. Beide sind vollständig isoliert, kein Cross-Component-Impact.
Mittleres Risiko, mittlerer Aufwand: Search-Autocomplete-Combobox-Pattern (Touchpoint 3). Das Pattern ist etabliert und gut dokumentiert, aber erfordert eine sauberere Trennung zwischen Input-State und Listbox-State als viele bestehende Implementierungen haben.
Mittleres Risiko, höherer Aufwand: Filter-Drawer (Touchpoint 1) und Mega-Menü (Touchpoint 2). Beide erfordern eine strukturelle Überarbeitung, wenn sie bisher ohne ARIA-Semantik gebaut sind. inert-Browser-Support prüfen; für ältere Browser ist ein Polyfill verfügbar.
Situationsbezogen: Account-Switch-Skip-Links (Touchpoint 5) sind primär relevant für Multi-Brand-Setups. Single-Brand-Storefronts profitieren aber ebenfalls von einem Skip-Link-System - der Aufwand ist minimal.
---
BFSG-Compliance ist kein Edge-Case-Thema mehr. Ein Jahr nach dem Wirksamwerden ist der Checkout gepatched - und der Checkout war nie der einzige Tastatur-Flow. Die sechs Touchpoints hier sind der Rest. Wer sie behebt, verbessert nicht nur die Compliance-Position, sondern auch die mid-funnel Conversion-Rate für alle Nutzer, die ohne Maus surfen - ob aus Gewohnheit, wegen motorischer Einschränkung oder weil das Trackpad gerade streikt.
---
Weiterführend: - Composable Visual Page Builder - Accessibility-Komponenten einmal konfigurieren, alle Brands profitieren. - Composable Headless Frontend - Frontend-Layer-Patterns ohne Backend-Deployment iterieren. - Performance und Core Web Vitals - Accessibility und Performance als verbundene Storefront-Qualitäten. - Checkout-Form-Accessibility und BFSG-Conversion 2026 - der Checkout-Touchpoint als Ausgangspunkt. - BFSG Ein-Jahres-Marke 2026: Compliance-Lücken - der systemische Überblick.