8 Barrierefreiheits-Blocker, die uns in Onlineshops immer wieder begegnen

In unserer Arbeit mit Onlineshops zeigt sich immer wieder: Barrierefreiheitsprobleme beschränken sich selten auf eine einzelne Seite. Das ist umso relevanter, seit der European Accessibility Act in Kraft getreten ist und die Anforderungen an Shops, die in die EU verkaufen, deutlich gestiegen sind. Wir unterstützen Shops dabei, dem zuvorzukommen – mit einem dedizierten Accessibility Audit. Und über all diese Audits hinweg stoßen wir immer wieder auf dieselben technischen Barrieren, in nahezu jedem Kundenprojekt.

Genau diese Wiederholung ist der Kern dieses Beitrags. Es geht hier nicht um hypothetische WCAG-Verstöße aus einer Lehrbuch-Checkliste, sondern um reale Muster, die wir in den Codebases von Fashion-Retailern, Elektronikshops, Tierfutter-Händlern und Abo-Shops gleichermaßen gefunden haben. Ob Boutique-Brand oder Enterprise-Plattform: Es sind immer wieder dieselben grundlegenden Hürden, die Nutzern im Weg stehen.

Barrierefreiheit wird oft rein als Compliance-Pflicht betrachtet statt als Frage der User Experience. Dabei ist die Realität simpel: Wenn ein Interface für Screenreader- oder Tastaturnutzer nicht funktioniert, ist es fast immer auch für alle anderen Nutzer frustrierend und fehleranfällig. Hier sind die 8 häufigsten Blocker aus unseren Kundenprojekten – beginnend mit einem klassischen Homepage-Element, das den Kaufprozess regelmäßig ausbremst.

Unkontrollierbare Carousels und Slider

Carousels und Slider gehören zu den Favoriten im eCommerce – auf Startseiten, in Kampagnen und in Cross-Selling-Bereichen. Sie erlauben es, mehrere Angebote an einer prominenten Stelle zu präsentieren. Gleichzeitig zählen sie zu den häufigsten Barrierefreiheitsproblemen, die uns in Kundenprojekten begegnen.

Das Kernproblem: Kontrolle und Navigation. Individuell entwickelte oder Library-basierte Slider unterstützen oft keine grundlegende Tastaturnavigation. Wer auf die Tab-Taste oder die Pfeiltasten angewiesen ist, kann weder durch die Slides blättern noch die Buttons darin erreichen. Viele Carousels laufen zudem standardmäßig im Autoplay-Modus und rotieren alle paar Sekunden – ohne Pause-Button. Das ist nicht nur ein Usability-Problem, sondern auch ein direkter Verstoß gegen die WCAG-Anforderungen an bewegte Inhalte.

Vergleich zweier Karussells: eines ohne Tastatursteuerung, eines mit Autoplay ohne Pause-Funktion

„Button, Button, Button": Icon-Buttons ohne zugängliche Namen

Moderne Shop-Interfaces setzen stark auf minimalistische, Icon-basierte Navigation, um Header und Produktkarten aufgeräumt zu halten. Lupe für die Suche, Warenkorb-Tasche, Herz für die Wunschliste, Hamburger-Menü und das „X" zum Schließen – all das ist in Onlineshops praktisch universell.

Visuell ist ihre Bedeutung offensichtlich. Doch ohne den visuellen Kontext – so wie ein Screenreader die Seite wahrnimmt – kündigt sich derselbe Button nur als „Button" an. Kein Name, kein Zweck, keine Ahnung, was bei einem Klick passiert.

Dasselbe Problem zeigt sich bei Trust-Badges und Werbebannern, die zwar verlinkt sind, aber keinen beschreibenden Text hinterlegt haben. Screenreader-Nutzer hören dann nur „Link" oder einen kryptischen Dateinamen statt „Sicherer Checkout" oder „30 % Rabatt im Sommer-Sale".

Shop-Header mit Icons aus Sicht sehender Nutzer im Vergleich zum Screenreader, der jedes Icon nur als „Button" ansagt

Kaputte Überschriften-Hierarchie: Optik vs. Seitenstruktur

Überschriften-Ebenen sind mehr als eine Schriftgröße. Sie bilden die Struktur einer Webseite und helfen sowohl Nutzern als auch assistiven Technologien zu verstehen, wie Informationen organisiert und gewichtet sind.

In unserer Arbeit sehen wir viel zu oft, dass Heading-Levels für Styling-Zwecke eingesetzt werden, statt die Logik der Seite abzubilden. Ein Beispiel: Ein Werbebanner soll groß und auffällig wirken – also bekommt er aus rein ästhetischen Gründen ein <h1>-Tag, während der eigentliche Produkttitel, die wichtigste Überschrift der Seite, zu einem <h3> degradiert wird.

Dieser Optik-zuerst-Ansatz zerstört die Dokumentlogik. Screenreader-Nutzer verwenden Überschriften als interaktive Navigationskarte und springen per Tastaturkürzel direkt zwischen den wichtigsten Abschnitten – Produktdetails, Lieferinformationen oder Kundenbewertungen. Wenn Überschriften Ebenen überspringen oder in der falschen Reihenfolge stehen, werden Produktseiten und Kategorielisten unübersichtlich – und die Kaufentscheidung wird für Kunden deutlich schwerer.

Vergleich einer logischen Überschriftenstruktur mit einer fehlerhaften, bei der Ebenen übersprungen werden

Formulare ohne Verbindung, Felder ohne Labels

Formulare sind der Ort, an dem Barrierefreiheitsprobleme am direktesten darüber entscheiden, ob ein Kauf überhaupt zustande kommt. Checkout-, Adress-, Login-, Registrierungs- und Kontaktformulare sind die üblichen Verdächtigen: Eingabefelder ohne zugehöriges <label>, Platzhaltertext, der als Label missbraucht wird (und verschwindet, sobald man zu tippen beginnt), und Fehlermeldungen, die visuell direkt unter einem Feld erscheinen, aber semantisch nicht mit ihm verknüpft sind.

Gerade der letzte Punkt ist subtil, aber teuer. Ist eine Fehlermeldung nicht über aria-describedby verbunden, kann es passieren, dass ein Screenreader-Nutzer ein Formular absendet, hört, dass etwas schiefgelaufen ist – aber keine Chance hat zu erfahren, welches Feld das Problem verursacht und warum. In einem mehrstufigen Checkout ist das der Unterschied zwischen einer abgeschlossenen Bestellung und einem abgebrochenen Warenkorb.

Checkout-Formular aus Nutzersicht im Vergleich zum Screenreader, der nur unbeschriftete Eingabefelder vorliest

Fehlende Fokus-Indikatoren: Shoppen mit unsichtbarem Cursor

Tastaturnutzer navigieren, indem sie in jedem Moment genau wissen, wo auf der Seite sie sich befinden. Werden Fokus-Umrandungen entfernt, ohne einen Ersatz zu bieten, geht dieses Ortsgefühl verloren. Das ist, als würde man Mausnutzern zumuten, mit einem unsichtbaren Cursor einzukaufen. Auf einer langen Kategorieseite mit Filtern, Produktkarten und Sticky Header – oder in einem mehrstufigen Checkout – reicht ein einziger Moment ohne sichtbaren Fokus, und der Nutzer weiß nicht mehr, ob er gleich auf „Filter anwenden" oder „Aus dem Warenkorb entfernen" klickt.

Das gehört zu den frustrierendsten Blockern überhaupt: Der Nutzer scheitert nicht an fehlenden Fähigkeiten – das Interface hat schlicht aufgehört, mit ihm zu kommunizieren.

Vergleich einer Kategorieseite: sichtbarer Mauszeiger gegenüber Tastaturnavigation ohne Fokus-Indikator

Gefangen hinter einem Modal

Mini-Warenkörbe, Cookie-Banner, Newsletter-Popups, Chat-Assistenten oder Login-Fenster – Onlineshops sind voller Modals, und jedes einzelne ist ein kleiner Barrierefreiheitstest für sich. Öffnet sich ein Modal, muss der Tastaturfokus sofort hineinspringen; schließt es sich, muss der Fokus dorthin zurückkehren, wo der Nutzer vorher war. Andernfalls landen Nutzer hinter einem unsichtbaren Overlay, tabben durch eine Seite, die sie nicht sehen können, oder schaffen es nicht, ein Popup zu schließen, das genau die Inhalte verdeckt, für die sie gekommen sind. Wenn ein Popup Menschen am Einkaufen hindert, kämpfen sie nicht mit dem Interface – sie gehen einfach.

Newsletter-Popup im Vergleich: Tastaturfokus hinter dem Modal gefangen gegenüber Fokus, der zum Ausgangspunkt zurückkehrt

Alt-Texte, die wirklich etwas kommunizieren

Nicht jedes Bild in einem Shop hat dasselbe Gewicht – und genau hier gehen Alt-Text-Entscheidungen typischerweise schief. Ein Produktfoto, ein Kampagnenbanner mit Sale-Ankündigung, ein Trust-Badge oder eine Grafik zu Lieferzeiten transportieren oft Informationen, die der Kunde verstehen muss. Viel zu oft werden sie trotzdem alle gleich behandelt: Entweder bekommt alles den generischen Alt-Text „Bild" – oder alles bleibt leer.

Die Frage ist nicht nur, ob ein Alt-Text existiert. Die Frage ist, ob das Bild etwas kommuniziert, das ein sehender Nutzer in einer halben Sekunde erfasst – und ob ein Screenreader-Nutzer dieselbe Information bekommt.

Werbebanner aus Sicht sehender Nutzer im Vergleich zum Screenreader, der nur ein generisches Bild ansagt

Kontrast ist keine Frage des Geschmacks

Zu geringer Farbkontrast ist eines der häufigsten Probleme, die wir finden – und selten Absicht. Meist ist er ein Nebeneffekt minimalistischer Designtrends mit blassen Texten und gedeckten Farbpaletten, kombiniert mit fehlendem Bewusstsein für die geforderten Kontrastverhältnisse.

Geringer Kontrast ist eine unmittelbare Barriere für Menschen mit Sehbeeinträchtigungen – aber er trifft genauso jeden, der auf dem Smartphone in direktem Sonnenlicht shoppt, auf einem günstigeren Display surft oder mit heruntergeregelter Bildschirmhelligkeit liest.

Das ist eines der deutlichsten Beispiele dafür, dass Barrierefreiheit und alltägliche Usability dasselbe Problem unter verschiedenen Namen sind.

Produktseite auf dem Smartphone bei normalen Bedingungen und in direktem Sonnenlicht, wo kontrastarmer Text unlesbar wird

Reibung beheben statt Checkboxen abhaken

Diese acht Probleme sind keine seltenen Edge Cases – es sind die, die uns immer wieder begegnen, in Shops jeder Größe und Kategorie. Und sie sind aus einem Grund relevant, der über das rechtliche Risiko hinausgeht: Sie tauchen genau dort auf, wo Kunden eine Entscheidung treffen. Ein Carousel, das den Tastaturfokus einsperrt, ein Formularfehler, den niemand findet, ein Modal, das sich nicht schließen lässt, ein Button, dessen Zweck für den Screenreader unsichtbar ist – jedes davon ist Reibung in dem Moment, in dem ein Besucher entscheidet, ob er Kunde wird.

Die gute Nachricht: Keines dieser Probleme erfordert ein Redesign. Alle lassen sich innerhalb eines bestehenden Designsystems lösen – meist als gezielte Fixes, nicht als Komplettumbau. Das Muster, das wir über Kundenprojekte hinweg sehen, ist nicht, dass Barrierefreiheit schwer umzusetzen wäre. Sondern dass sie leicht übersehen wird, solange niemand gezielt danach testet. Und genau da setzt – gerade jetzt, wo der European Accessibility Act den Druck erhöht – unser Barrierefreiheits Audit an: Er geht Ihren Shop Screen für Screen durch und zeigt präzise, wo Kunden hängen bleiben.

FacebookTwitterPinterest

Krzysiek Kaszanek

Senior Full Stack Engineer

Ich bin Student der Informatik und Praktikant bei Kiwee. Seit meinem ersten C++-Tutorial habe ich mich in die Programmierung verliebt. Ich liebe es, Probleme zu lösen und herauszufinden, wie Dinge funktionieren. Webentwicklung ist die Sache, die mir die größte Zufriedenheit in der Programmierung gibt, und mein Ziel ist es, ein Full-Stack-Developer zu werden. Nach einem anstrengenden Tag an der Universität gehe ich klettern oder Fahrrad fahren. Sport hilft mir, Stress abzubauen und meinen Geist neu zu beleben.