Ratgeber

Produktfilter barrierefrei: Filter, Sortierung und Suche im Shop

Veröffentlicht am 25. Oktober 2026

Ein Produktfilter ist barrierefrei, wenn sich jede Facette, der Preisbereich, die Sortierung und die Suche allein mit der Tastatur bedienen lassen, jedes Bedienelement einen Namen hat und ein Screenreader nach jeder Änderung die neue Trefferzahl ansagt, ohne dass der Fokus springt. Drei Stellen sind besonders leicht zu übersehen: Die Trefferzahl wird nicht angesagt (WCAG 4.1.3), der Fokus landet nach dem Filtern am Seitenanfang, und der Preisregler lässt sich nur ziehen (WCAG 2.5.7).

Welche Teile Ihr Shopsystem mitbringt und welche Sie über Theme und Apps selbst verantworten, erklärt Barrierefreier Onlineshop: was Shopsysteme leisten und was Sie selbst tun müssen. Dieser Artikel geht für Kategorieseite, Filter und Suche in die Tiefe: was die WCAG je Bauteil verlangen, wohin der Fokus nach dem Filtern gehört, wie Sie das Muster für Suchvorschläge umsetzen und wie Sie das Ganze selbst prüfen.

Warum Filter und Suche unter das BFSG fallen

Ein Onlineshop für Verbraucher ist eine „Dienstleistung im elektronischen Geschäftsverkehr“ nach § 1 Abs. 3 Nr. 5 BFSG. § 12 Nr. 3 BFSGV verlangt, dass Webseiten einschließlich der zugehörigen Online-Anwendungen „auf konsistente und angemessene Weise wahrnehmbar, bedienbar, verständlich und robust gestaltet werden“. Nach unserer Lesart gehören Filter, Sortierung und Suche dazu, denn ohne sie finden Kundinnen und Kunden in einem größeren Sortiment kein Produkt. Das gilt auch, wenn der Filter aus einer App oder einem Plugin kommt.

Was die WCAG je Bauteil verlangen

Die Tabelle ordnet jedem Bauteil der Kategorieseite die Kriterien zu, die dafür am wichtigsten sind. Alle genannten Kriterien gehören zur Stufe A oder AA. Wie die WCAG 2.2 insgesamt auf einen Shop anzuwenden sind, zeigt WCAG 2.2 im Onlineshop.

Entscheidungstabelle: sofort filtern oder mit „Anwenden“

Die wichtigste Bauentscheidung ist, wann der Filter greift. WCAG 3.2.2 verbietet, dass das Ändern einer Einstellung „automatically cause a change of context“, es sei denn, Nutzer wurden vorher darauf hingewiesen. Das W3C stellt klar, dass eine bloße Inhaltsänderung kein Kontextwechsel sein muss; ein Fokuswechsel oder ein neues Fenster ist einer. Nach unserer Lesart ist ein kompletter Neuladen der Seite, nach dem der Fokus am Seitenanfang steht, ein Kontextwechsel.

Für kleine Shops ist der Knopf „Filter anwenden“ nach unserer Einschätzung die einfachste Lösung: Er funktioniert auch dann, wenn Ihr Theme die Seite neu lädt.

Filter, Facetten und Preisregler

Filtergruppen und Checkboxen

Jede Facette ist eine Gruppe von Checkboxen, die zu einem Merkmal gehören. Das W3C empfiehlt in der Technik H71, solche Gruppen mit fieldset und legend auszuzeichnen: „Grouping controls is most important for related radio buttons and checkboxes.“ Ein Screenreader sagt dann zum Beispiel „Farbe, Gruppe, Rot, Kontrollkästchen, nicht aktiviert“ statt nur „Rot“.

• Echte Checkboxen verwenden. Ein natives input type="checkbox" mit label bringt Tastaturbedienung mit der Leertaste und den Zustand „aktiviert“ mit. Nachgebaute Checkboxen aus div oder Links brauchen all das von Hand, und genau dabei geht leicht etwas verloren.
• Label klickbar machen. Wenn das ganze Label die Checkbox umschaltet, wird die Klickfläche groß genug für 2.5.8.
• Farbfelder benennen. Ein farbiges Quadrat ohne Text ist für einen Screenreader leer. Geben Sie jedem Farbfeld den Farbnamen als Label, zum Beispiel „Olivgrün“, und zeigen Sie die Auswahl zusätzlich mit einem Haken (1.4.1).
• Zahlen in Klammern mitlesen lassen. „Rot (12)“ ist als Label in Ordnung. Ist eine Option ohne Treffer ausgegraut, sollte sie entweder deaktiviert und so angesagt werden oder ganz fehlen.

Auf- und zuklappbare Filtergruppen

Zeigt Ihr Shop Facetten als zugeklappte Gruppen, ist das passende Muster die Disclosure im WAI-ARIA Authoring Practices Guide (APG): Die Überschrift der Gruppe ist ein Knopf, Enter und Leertaste klappen auf und zu, und „When the content is visible, the element with role button has aria-expanded set to true.“ Ein natives details mit summary leistet im Wesentlichen dasselbe ohne eigenes Skript.

Preisregler

Ein Regler mit zwei Griffen für Mindest- und Höchstpreis ist im APG als Multi-Thumb Slider beschrieben, mit einer Preisspanne als Beispiel. Jeder Griff ist ein eigenes Element mit der Rolle slider, ist einzeln per Tab erreichbar und braucht einen Namen wie „Mindestpreis“ und „Höchstpreis“. Laut Slider-Muster ändern Pfeiltasten den Wert um einen Schritt, Pos1 und Ende springen auf den kleinsten und größten Wert. Mit aria-valuetext sagt der Screenreader „50 Euro“ statt „50“.

Tastaturbedienung allein reicht nicht. Das W3C schreibt zu 2.5.7, dass ein Tastatur-Äquivalent dieses Kriterium nicht automatisch erfüllt; wer mit Maus, Finger oder Kopfmaus bedient, muss den Wert auch ohne Ziehen ändern können. Als Lösungen nennt das W3C einen Klick auf die Reglerschiene und ein Eingabefeld neben dem Regler.

Unsere Empfehlung: Zwei beschriftete Zahlenfelder „Preis von“ und „Preis bis“ mit einem Knopf „Anwenden“. Sie erfüllen 2.1.1 und 2.5.7 ohne Zusatzaufwand, funktionieren auf dem Smartphone und lassen sich exakt eingeben. Den Regler können Sie als Zusatz daneben behalten.

Aktive Filter und Zurücksetzen

Zeigt Ihr Shop die gewählten Filter oberhalb der Ergebnisse als Chips mit einem Kreuz, braucht das Kreuz einen Namen, der den Filter nennt, zum Beispiel „Filter Rot entfernen“; ein bloßes „x“ oder „Schließen“ reicht nicht (4.1.2). Ergänzen Sie „Alle Filter zurücksetzen“ als echten Knopf.

Filter als Dialog auf dem Smartphone

Liegen die Filter auf kleinen Bildschirmen in einem Fenster, das über einen Knopf „Filter“ geöffnet wird, gilt dafür das Muster für modale Dialoge im APG: „When a dialog opens, focus moves to an element inside the dialog.“ Tab und Umschalt+Tab bleiben im Dialog, Escape schließt ihn, und beim Schließen kehrt der Fokus zum auslösenden Element zurück, es sei denn, ein anderes Ziel ist im Ablauf logischer. Der Schließen-Knopf braucht einen sichtbaren oder vorgelesenen Namen, und der Knopf „Ergebnisse anzeigen“ darf nicht von einer klebenden Leiste verdeckt sein (2.4.11).

Die Trefferzahl als Statusmeldung ansagen

Wer sieht, merkt sofort, dass aus 240 Produkten 18 geworden sind. Wer einen Screenreader nutzt, merkt nichts, solange der Shop die Änderung nicht ansagt. Genau dafür gibt es WCAG 4.1.3 Statusmeldungen: Statusmeldungen müssen sich so auszeichnen lassen, dass assistive Technologien sie „without receiving focus“ vorlesen. Das W3C nennt dort ausdrücklich Meldungen wie „18 results returned“ und „No results returned“ als Statusmeldungen. Die Ergebnisliste selbst ist laut W3C keine Statusmeldung; angesagt wird nur die kurze Zusammenfassung.

So setzen Sie das um:

1. Einen Bereich mit role="status" anlegen, zum Beispiel direkt über der Ergebnisliste. Laut der W3C-Technik ARIA22 muss dieser Bereich die Rolle schon haben, bevor die Meldung hineingeschrieben wird. Legen Sie ihn deshalb schon beim Laden der Seite an, zunächst leer.
2. Nach jeder Aktualisierung den Text ersetzen, etwa durch „18 Produkte gefunden“. Das W3C empfiehlt in ARIA22 zusätzlich aria-atomic="true", damit der ganze Satz gelesen wird.
3. Den leeren Fall ansagen: „Keine Produkte gefunden. Entfernen Sie einen Filter.“ Ein stummes Nichts ist der schlimmste Fall.
4. Zwischenzustände sparsam halten. „Lädt …“ und danach „18 Produkte gefunden“ ist in Ordnung; eine Ansage für jede einzelne Produktkachel ist es nicht.

Das gleiche Muster brauchen Sie im Warenkorb für „In den Warenkorb gelegt“; das beschreibt Barrierefreier Checkout.

Wohin der Fokus nach dem Filtern gehört

WCAG 2.4.3 verlangt eine Fokusreihenfolge, die Bedeutung und Bedienbarkeit erhält. Für Dialoge sagt das W3C dort, dass der Fokus beim Schließen zum auslösenden Knopf oder zum Element danach zurückkehrt. Für Filter gibt es keine eigene Regel; die folgenden Ziele sind unsere Empfehlung auf dieser Grundlage.

Verschwindet das fokussierte Element, ohne dass Ihr Shop den Fokus neu setzt, kann der Fokus verloren gehen, und die Tab-Reihenfolge beginnt je nach Browser wieder oben. Wer mit der Tastatur filtert, muss dann wieder durch Kopfbereich und Navigation tabben. Damit eine Überschrift den Fokus per Skript annehmen kann, braucht sie tabindex="-1"; in die normale Tab-Reihenfolge kommt sie dadurch nicht.

Sortierung

Ein natives select mit dem Label „Sortieren nach“ ist die robusteste Lösung. Mit der Tastatur wechseln Nutzer darin per Pfeiltaste die Optionen. Lädt Ihr Shop die Seite schon bei jeder Pfeiltaste neu, landet der Nutzer bei der ersten Option nach unten auf einer neuen Seite, ohne die übrigen gesehen zu haben. Nach unserer Lesart ist das ein Kontextwechsel im Sinne von 3.2.2. Abhilfe: entweder die Liste ohne Neuladen umsortieren und den Fokus auf dem Feld lassen, oder einen Knopf „Sortieren“ daneben setzen.

Ein selbstgebautes Aufklappmenü statt select muss Tastatur, Rolle und Zustand selbst liefern. Wenn Ihr Theme so eines verwendet, prüfen Sie es besonders gründlich mit dem Test unten.

Suchfeld mit Vorschlägen

Das Suchfeld braucht ein Label, das ein Screenreader vorliest, und ein sichtbares Zeichen, wofür es da ist. Ein Platzhalter wie „Suchen …“ verschwindet beim Tippen; nach unserer Lesart reicht er deshalb als Beschriftung nach 3.3.2 nicht aus. Die Lupe als Absende-Knopf braucht den Namen „Suchen“. Liegt das Formular in einem search-Element oder hat es role="search", finden Screenreader-Nutzer es über die Liste der Seitenbereiche.

Zeigt die Suche beim Tippen Vorschläge an, ist das eine Combobox nach dem Combobox-Muster im APG. Das passende Beispiel dort heißt „Editable Combobox With List Autocomplete“. Die Kernpunkte:

• Rollen und Zustände. Das Eingabefeld hat role="combobox", aria-expanded zeigt, ob die Vorschlagsliste offen ist, und aria-controls verweist auf die Liste. aria-autocomplete="list" sagt, dass Vorschläge erscheinen.
• Fokus bleibt im Feld. Laut APG gilt: „DOM Focus is maintained on the combobox.“ Der markierte Vorschlag wird über aria-activedescendant angesagt, so dass Nutzer weitertippen können.
• Tastatur. Pfeil nach unten geht in die Vorschläge, Enter übernimmt den markierten Vorschlag, Escape schließt die Liste und lässt den Fokus im Feld. Ohne markierten Vorschlag sollte Enter nach unserer Empfehlung die Suche abschicken.
• Anzahl der Vorschläge ansagen. Nach unserer Empfehlung sagt ein Statusbereich „5 Vorschläge“, sobald die Liste erscheint, und „Keine Vorschläge“, wenn sie leer bleibt (4.1.3).
• Produktbilder in Vorschlägen. Steht der Produktname schon als Text daneben, ist das Bild dekorativ und bekommt ein leeres alt.

Auf der Ergebnisseite nennt die erste Überschrift Suchbegriff und Anzahl, etwa „18 Ergebnisse für Rucksack“. Bei null Treffern zeigen Sie Hilfen an: Schreibweise prüfen, weniger Begriffe, beliebte Kategorien.

Kommt Ihre Suche aus einer App oder einem externen Dienst, gelten dieselben Anforderungen. Fragen Sie den Anbieter, ob die Vorschlagsliste nach dem APG-Combobox-Muster gebaut und mit Screenreadern getestet ist, und lassen Sie sich das schriftlich bestätigen.

Mehr laden, Seitenzahlen, endloses Scrollen

Behalten Sie die Filter in der Adresse der Seite (zum Beispiel ?farbe=rot). Dann führen der Zurück-Knopf und ein geteilter Link wieder zur selben Auswahl, und Nutzer müssen nach dem Besuch einer Produktseite nicht neu filtern.

So testen Sie Ihre Filter selbst

Sie brauchen dafür keine Spezialsoftware, nur Ihren Browser und einen Screenreader. Eine allgemeine Anleitung zum Tastaturtest finden Sie in Website auf Tastaturbedienbarkeit testen.

1. Nur mit der Tastatur. Maus weglegen, die Kategorieseite öffnen und mit Tab bis zu den Filtern gehen. Eine Gruppe aufklappen, eine Checkbox mit der Leertaste wählen. Ist der Fokus jederzeit sichtbar? Steht er danach noch an derselben Stelle?
2. Preis einstellen. Den Preisbereich mit Tab und Pfeiltasten ändern, dann mit der Maus nur per Klick, ohne zu ziehen.
3. Sortieren. Das Sortierfeld mit Tab erreichen und mit den Pfeiltasten durch alle Optionen gehen. Lädt die Seite schon bei der ersten Pfeiltaste neu?
4. Screenreader einschalten, etwa NVDA unter Windows oder VoiceOver auf dem Mac oder iPhone. Einen Filter wählen. Hören Sie die neue Trefferzahl? Hören Sie bei einem Filter ohne Treffer, dass nichts gefunden wurde?
5. Suche. „Ruck“ ins Suchfeld tippen. Werden Vorschläge angesagt? Mit Pfeil nach unten einen wählen, mit Enter übernehmen, mit Escape schließen.
6. Smartphone-Breite. Browserfenster auf etwa 320 Pixel verkleinern oder auf 400 Prozent zoomen, Filterdialog öffnen, mit Tab durchgehen. Bleibt der Fokus im Dialog? Kommt er beim Schließen zurück?
7. Mehr laden. Den Knopf drücken. Wohin springt der Fokus?

Typische Fehler und ihre Behebung

Wie Sie Kontraste von Rahmen und Text messen, zeigt Kontrast nach WCAG prüfen. Kommt der Fehler aus einer Filter- oder Such-App, schicken Sie dem Anbieter die Zeile aus der Tabelle mit dem WCAG-Link; ein Overlay-Widget behebt keinen dieser Fehler im Code der App.

Ihr nächster Schritt

Der kostenlose Scan prüft ohne Anmeldung Ihre Startseite, eine Produktseite und den Warenkorb automatisch gegen die WCAG-Regeln und zeigt, was zuerst behoben werden sollte. Ein automatischer Scan findet nur einen Teil der Barrieren: Ob die Trefferzahl angesagt wird, wohin der Fokus nach dem Filtern springt und ob die Suchvorschläge per Tastatur funktionieren, prüfen Sie mit dem Test oben selbst von Hand.

Dieser Ratgeber ist keine Rechtsberatung. Im Zweifel klären Sie Ihren Fall mit der Bundesfachstelle Barrierefreiheit oder einer Anwältin oder einem Anwalt.

Stand: 25.10.2026. Quellen gelesen am 25.10.2026.