Aktualisiert: März 2026 · Lesezeit: 13 Min.
Vor ein paar Wochen habe ich versucht, in einem großen deutschen Mode-Online-Shop eine Hose zu bestellen. Nur mit Tastatur und Screenreader. Das Ergebnis: Ich habe es nicht geschafft. Nicht wegen meiner technischen Fähigkeiten — sondern weil der Shop es technisch unmöglich macht. Der Größen-Selektor war ein Custom-Dropdown ohne ARIA-Attribute. Der „In den Warenkorb"-Button war ein gestyltes <div>. Und der Checkout hat bei jedem Schritt den Fokus an den Seitenanfang zurückgesetzt.
Das ist kein Einzelfall. Es ist der Normalzustand im deutschen E-Commerce. Und genau das will das BFSG ändern.
§ 1 Abs. 3 Nr. 5 BFSG: „Dienstleistungen im elektronischen Geschäftsverkehr." Damit sind Online-Shops gemeint, die Waren oder Dienstleistungen an Verbraucher verkaufen. Nicht jede Website, aber jede Website, über die man etwas kaufen kann.
Die EN 301 549 (V3.2.1), auf die das BFSG verweist, ist dabei besonders relevant in Kapitel 9 (Web) und Kapitel 11 (Software, für Apps). Sie fordert WCAG 2.1 Level AA Konformität für alle Web-Inhalte.
Und jetzt kommt der Punkt, den viele übersehen: „Alle Web-Inhalte" heißt wirklich alle. Nicht nur die Startseite. Nicht nur die Produktseiten. Sondern der komplette Kaufprozess — von der Suche über die Produktauswahl und den Warenkorb bis zur Bezahlung und Bestellbestätigung.
Filterleisten in Online-Shops sind Accessibility-Albträume. Hier ein typisches Problem und die Lösung:
<!-- Vorher: Unzugängliche Checkbox-Filter -->
<div class="filter" onclick="toggleFilter('farbe-rot')">
<span class="checkbox"></span> Rot
</div>
<!-- Nachher: Zugänglich -->
<fieldset>
<legend>Nach Farbe filtern</legend>
<label>
<input type="checkbox"
name="farbe"
value="rot"
aria-describedby="filter-count-rot">
Rot
<span id="filter-count-rot">(42 Produkte)</span>
</label>
</fieldset>
<!-- Live-Region für Filter-Updates -->
<div aria-live="polite" aria-atomic="true" id="filter-status">
42 Produkte gefunden
</div>
Das <fieldset> mit <legend> gibt dem Screenreader Kontext: „Nach Farbe filtern". Die Live-Region informiert den Nutzer, wenn sich die Produktliste ändert, ohne dass er aktiv nachschauen muss.
Eine gute Produktseite für die Barrierefreiheit braucht:
<select>-Elemente oder Custom-Dropdowns mit korrekten ARIA-Rollen<!-- Preis zugänglich kommunizieren -->
<div class="price">
<span class="price-old" aria-label="Alter Preis">
<s>89,99 €</s>
</span>
<span class="price-new" aria-label="Reduzierter Preis">
59,99 €
</span>
<span class="badge" aria-label="Sie sparen 33 Prozent">-33%</span>
</div>
Der Warenkorb hat ein spezifisches Problem: Er ändert sich dynamisch. Wenn ein Nutzer einen Artikel hinzufügt, muss das kommuniziert werden — nicht nur visuell (ein Zähler, der sich ändert), sondern auch für Screenreader.
<!-- Warenkorb-Update kommunizieren -->
<button onclick="addToCart(productId)" aria-label="Nike Air Max 90 in den Warenkorb legen">
In den Warenkorb
</button>
<!-- Live-Region für Bestätigung -->
<div aria-live="assertive" id="cart-confirmation" class="sr-only"></div>
<script>
function addToCart(id) {
// ... Produkt hinzufügen ...
const confirmation = document.getElementById('cart-confirmation');
confirmation.textContent = 'Nike Air Max 90 wurde zum Warenkorb hinzugefügt. Warenkorb: 3 Artikel.';
}
</script>
<style>
.sr-only {
position: absolute;
width: 1px; height: 1px;
padding: 0; margin: -1px;
overflow: hidden;
clip: rect(0,0,0,0);
border: 0;
}
</style>
Hier wird es ernst. Der Checkout ist in den meisten Shops der Bereich mit den meisten Barrieren — und gleichzeitig der geschäftskritischste. Was ich in der Praxis an Problemen sehe:
Adressformulare:
<!-- Vorher: Placeholder statt Label -->
<input type="text" placeholder="Vorname">
<!-- Nachher: Label + Autocomplete + Validierung -->
<div class="form-group">
<label for="vorname">Vorname <span aria-hidden="true">*</span></label>
<input type="text"
id="vorname"
name="vorname"
autocomplete="given-name"
required
aria-required="true"
aria-invalid="false"
aria-describedby="vorname-error">
<span id="vorname-error" role="alert"></span>
</div>
Drei Dinge, die hier wichtig sind: Erstens, autocomplete="given-name" — das ist WCAG 1.3.5 und hilft gleichzeitig allen Nutzern beim Ausfüllen. Zweitens, ein sichtbares Label statt nur Placeholder-Text (Placeholder verschwindet beim Tippen). Drittens, aria-describedby für Fehlermeldungen, die dynamisch gefüllt werden.
Zahlungsarten-Auswahl:
<!-- Zahlungsarten als Radio-Buttons —>
<fieldset>
<legend>Zahlungsart wählen</legend>
<label>
<input type="radio" name="payment" value="card">
Kreditkarte
</label>
<label>
<input type="radio" name="payment" value="paypal">
PayPal
</label>
<label>
<input type="radio" name="payment" value="klarna">
Klarna Rechnung
</label>
</fieldset>
Ich sehe so oft Custom-Tab-Interfaces für die Zahlungsart, die weder role="tablist" noch Tastatur-Navigation unterstützen. Native Radio-Buttons sind hier fast immer die bessere Wahl.
Ein Punkt, den fast alle vergessen: Die Bestätigungs-E-Mail muss ebenfalls zugänglich sein. HTML-Mails mit korrekter Semantik, Alt-Texte bei Bildern, ausreichende Kontraste. Das BFSG spricht von der gesamten Dienstleistung — und die endet nicht beim Klick auf „Bestellen".
WooCommerce liefert eine relativ solide Basis. Die Checkout-Formulare haben Labels und ARIA-Attribute. Probleme entstehen meist durch:
Shopifys Dawn-Theme (Standard seit 2023) hat solide Accessibility-Grundlagen. Aber:
Shopware 6 hat seit Version 6.5 deutlich in Accessibility investiert. Trotzdem gilt:
Wenn ich einen Shop auditiere und priorisieren muss, gehe ich so vor: