Kurz und einfach erklärt
Viele Shops haben Auswahl-Felder. Zum Beispiel: Sortieren nach Preis. Manche Felder laden die Seite neu, sobald man etwas anderes wählt.
Wer keine Maus nutzt, geht mit den Pfeil-Tasten durch die Liste. Dann lädt die Seite schon beim ersten Druck auf die Taste neu. Man kommt nicht zu der Wahl, die man will.
Die Regel dazu heißt WCAG 3.2.2. Sie sagt: Eine Wahl im Feld darf nicht einfach die Seite wechseln. Es sei denn, die Seite sagt es vorher.
Eine gute Lösung ist ein Knopf neben dem Feld. Erst wählt man, dann drückt man auf den Knopf. Dann lädt die Seite nur ein Mal.
Prüfen Sie Ihre Felder mit der Tastatur. Prüfen Sie sie auch mit einem Vorlese-Programm. Ein Test-Programm allein findet diesen Fehler kaum.
Eine Kundin öffnet die Kategorie „Tischleuchten“, springt mit der Tabulatortaste zum Feld „Sortieren nach“ und drückt einmal die Pfeiltaste nach unten, um sich die Optionen anzusehen. Noch bevor sie „Preis absteigend“ erreicht, lädt die Seite neu, der Fokus steht wieder am Seitenanfang, und die Sortierung lautet „Neuheiten“ – eine Wahl, die sie gar nicht treffen wollte. Genau diesen Ablauf regelt das Erfolgskriterium 3.2.2 „Bei Eingabe“ (On Input) der WCAG: Wer den Wert eines Bedienelements ändert, darf nicht ohne Vorwarnung in einen anderen Kontext geschickt werden (W3C, Understanding SC 3.2.2). Das Kriterium gehört zur untersten Konformitätsstufe A und betrifft im Onlineshop vor allem Auswahlfelder: Sortierung, Sprach- und Länderwahl, Varianten und Mengenfelder. Dieser Beitrag erklärt, was als Kontextwechsel gilt, zeigt vier typische Shop-Muster und drei saubere Lösungen und beschreibt, wie sich das Kriterium mit Tastatur und Screenreader prüfen lässt.
Das Wichtigste in Kürze
- SC 3.2.2 Bei Eingabe (Stufe A) verlangt: Das Ändern eines Bedienelements löst ohne vorherigen Hinweis keinen Kontextwechsel aus, also keine neue Seite, kein neues Fenster und keinen Fokussprung (W3C, Understanding SC 3.2.2).
- In einer Umfrage unter 1.539 Screenreader-Nutzenden stehen unerwartet wechselnde Bildschirme auf Platz 4 von 12 der störendsten Barrieren (WebAIM Screen Reader User Survey #10).
- Typische Shop-Muster mit Verstoß: Sortierfeld lädt beim ersten Pfeildruck neu, Sprachwahl springt sofort, Variantenwahl lädt eine neue Adresse, das letzte Feld schickt das Formular selbst ab (W3C, F36, F37).
- Bewährt ist ein Übernehmen-Button neben dem Auswahlfeld (W3C, H84, G80); alternativ das Verhalten vorher ankündigen (W3C, G13) oder nur Inhalte aktualisieren, ohne den Kontext zu wechseln (W3C, SCR19).
- Werkzeuge allein reichen nicht: Von 143 eingebauten Barrieren übersahen zehn Prüfwerkzeuge zusammen 42 (GDS 2017). 3.2.2 prüft man mit Tastatur und Screenreader, Pfeiltaste für Pfeiltaste.
- Für Onlineshops, die an Verbraucher verkaufen, gilt seit dem 28. Juni 2025 das BFSG, Kleinstunternehmen ausgenommen; die Norm EN 301 549 V3.2.1, derzeit der Bezugsstandard, verlangt SC 3.2.2 in Abschnitt 9.3.2.2 (ETSI, EN 301 549 V3.2.1).
Was Bei Eingabe verlangt
Der Wortlaut des Kriteriums ist kurz: Das Ändern der Einstellung eines Bedienelements darf nicht automatisch einen Kontextwechsel auslösen, es sei denn, die Nutzenden wurden vor der Verwendung des Elements auf dieses Verhalten hingewiesen (W3C, Understanding SC 3.2.2). SC 3.2.2 hat die Stufe A. Eine Website, die WCAG 2.2 auf Stufe AA erfüllen soll, muss es deshalb einhalten, denn AA schließt alle Kriterien der Stufe A ein. Sein Schwesterkriterium ist SC 3.2.1 Bei Fokus, ebenfalls Stufe A: Schon das bloße Fokussieren eines Elements darf keinen Kontextwechsel auslösen (W3C, Understanding SC 3.2.1).
Entscheidend ist die Unterscheidung zwischen „Einstellung ändern“ und „aktivieren“. Ein Kontrollkästchen ankreuzen, Text in ein Feld tippen oder in einer Auswahlliste eine andere Option wählen ändert die Einstellung; einen Link oder eine Schaltfläche zu aktivieren ändert sie nicht (W3C, Understanding SC 3.2.2). Eine Schaltfläche, die ein Formular absendet und auf eine neue Seite führt, ist also kein Fall für 3.2.2. Ein Auswahlfeld, das dasselbe beim bloßen Wechsel der Option tut, ist es dagegen. Umschaltflächen mit aria-pressed zählen nach dem Verständnisdokument ebenfalls als Einstellung, weil sie einen Zustand behalten.
Was ein Kontextwechsel ist, legt das WCAG-Glossar fest: größere Änderungen, die Menschen desorientieren können, wenn sie ohne ihr Wissen geschehen und die Seite nicht als Ganzes überblicken. Gemeint sind Änderungen von Benutzeragent, Viewport, Fokus oder von Inhalten, die die Bedeutung der Seite verändern. Als Beispiele nennt die Definition das Öffnen eines neuen Fensters, das Verschieben des Fokus auf ein anderes Element, das Laden einer neuen Seite, einschließlich allem, was für Nutzende wie eine neue Seite aussieht, und das erhebliche Umordnen des Seiteninhalts (W3C, Understanding SC 3.2.2).
Inhaltsänderung ist nicht gleich Kontextwechsel
Warum unerwartete Wechsel so stark stören
Wer eine Seite sieht, bemerkt ein Neuladen sofort. Wer mit Screenreader arbeitet oder stark vergrößert, merkt oft nur, dass plötzlich etwas anderes vorgelesen wird oder der Bildausschnitt woanders steht. Das Verständnisdokument zu 3.2.2 hält fest, dass unerwartete Kontextwechsel Menschen mit Sehbehinderung oder kognitiven Einschränkungen so stark desorientieren können, dass sie den Inhalt nicht mehr nutzen können (W3C, Understanding SC 3.2.2).
Die Betroffenen sehen das ähnlich. In der zehnten Screenreader-Umfrage von WebAIM, die im Dezember 2023 und Januar 2024 lief (WebAIM Screen Reader User Survey #10) und 1.539 (WebAIM Screen Reader User Survey #10) gültige Antworten erhielt, stehen „Bildschirme oder Bildschirmteile, die sich unerwartet ändern“ auf Platz 4 von 12 (WebAIM Screen Reader User Survey #10) der störendsten Probleme. Auf Platz 2 (WebAIM Screen Reader User Survey #10) liegen interaktive Elemente wie Menüs, Reiter und Dialoge, die sich nicht wie erwartet verhalten, also genau die Kategorie, in die selbstgebaute Dropdowns fallen. Die Reihenfolge der Liste ist laut WebAIM seit 14 Jahren (WebAIM Screen Reader User Survey #10) weitgehend unverändert. Die Stichprobe ist nicht kontrolliert und steht nicht für alle Screenreader-Nutzenden, die Rangfolge zeigt aber, wo es im Alltag hakt.
Für Menschen, die mit der Tastatur arbeiten, wird ein Auswahlfeld mit sofortiger Wirkung zur Falle. Bei manchen Formularelementen ändert sich der Wert schon, während man die Optionen mit der Tastatur durchblättert (W3C, F36). Die Technik H84 betont deshalb, dass ein eigener Auslöser besonders für Menschen wichtig ist, die den Wert eines Auswahlfelds über die Tastatur wählen (W3C, H84). Das Fehlerbild F36 beschreibt die Folge für ein Auswahlfeld, das beim Wechsel das Formular abschickt: Wer die Tastatur nutzt, kommt nicht über den ersten Eintrag hinaus, und blinde Menschen oder Menschen mit Tremor landen leicht am falschen Ziel, bevor sie den Irrtum korrigieren können (W3C, F36).
Wie viele Menschen das betrifft, lässt sich nur näherungsweise sagen. Zum Jahresende 2025 lebten in Deutschland gut 7,8 Millionen (Destatis) Menschen mit schwerer Behinderung. Bei 10 Prozent (Destatis) von ihnen waren Arme oder Beine in ihrer Funktion eingeschränkt, bei 4 Prozent (Destatis) lag Blindheit oder eine Sehbehinderung vor, und 16 Prozent (Destatis) hatten geistige oder seelische Behinderungen. Die Statistik erfasst nur anerkannte Schwerbehinderungen und sagt nichts darüber, wer welche Eingabehilfe nutzt. Sie zeigt aber, dass die Gruppen, für die 3.2.2 geschrieben wurde, keine Randerscheinung sind.
Hinzu kommt die Menge an Formularelementen. Die WebAIM Million 2026 wertet die Startseiten der eine Million meistbesuchten Websites aus (WebAIM Million 2026) und zählt dort im Schnitt 6,9 (WebAIM Million 2026) Formularfelder, 36 Prozent (WebAIM Million 2026) mehr als drei Jahre zuvor. Startseiten der Kategorie Shopping kommen auf 71,0 (WebAIM Million 2026) automatisch erkannte Fehler, 26,6 Prozent (WebAIM Million 2026) mehr als der Durchschnitt aller Startseiten. Kategorie- und Produktseiten misst die Erhebung nicht, und gerade dort sitzen Sortierung, Filter und Variantenwahl.
Vier Shop-Muster, die gegen 3.2.2 verstoßen
Die folgenden vier Muster begegnen in Prüfungen von Onlineshops typischerweise. Allen gemeinsam ist ein change- oder input-Ereignis, das mehr auslöst als eine Inhaltsänderung: eine neue Seite, eine neue Adresse, ein neues Fenster oder einen Fokussprung.
Sortierung lädt beim ersten Pfeildruck neu
Das häufigste Muster ist das Sortierfeld auf der Kategorieseite, das per onchange="this.form.submit()" oder per Skript sofort eine neue Adresse mit Sortierparameter lädt. Mit der Maus fällt das nicht auf: Liste öffnen, Option anklicken, fertig. Mit der Tastatur kann schon der Schritt von „Relevanz“ zu „Neuheiten“ den Seitenwechsel auslösen, und nach dem Neuladen steht der Fokus am Seitenanfang. Wer drei Optionen weiter will, braucht drei Anläufe und drei Neuladungen, wie das Mockup oben zeigt. Genau diese Kombination, also Absenden beim Wechsel einer Option ohne Vorwarnung, führt F36 als Fehlerbeispiel (W3C, F36).
Sprach- oder Länderwahl springt sofort
Ein Auswahlfeld im Kopf oder Fuß der Seite, das beim Wechsel sofort auf die englische Fassung oder den Shop für Österreich umleitet, ist ein klassischer Kontextwechsel: neue Seite, oft neue Sprache, manchmal neue Preise. Die Technik G13 nennt genau dieses Beispiel, ein Auswahlfeld mit Deutsch, Französisch und Spanisch, und hält es für zulässig, wenn ein Hinweis vor dem Feld ankündigt, dass die Sprache beim Auswählen wechselt (W3C, G13). Ohne diesen Hinweis ist das Muster ein Verstoß. Mit Hinweis bleibt es für Tastaturnutzende mühsam, weil je nach Browser schon das Durchblättern der Optionen die Seite wechselt.
Variantenwahl wechselt die Adresse
Viele Produktseiten führen Farbe oder Größe als Auswahlfeld und laden beim Wechsel die Adresse der Variante, mit neuem Bild, neuem Preis und neuem Eintrag im Verlauf. Auf dem Bildschirm ist das eine kleine Änderung, für den Browser ein Seitenwechsel: Der Fokus beginnt wieder oben, und die Zurück-Taste führt zur vorherigen Variante statt zur Kategorie. Werden Varianten als Optionsfelder gebaut, die beim Wechsel neu laden, kommt ein zweites Problem hinzu. F37 hält fest, dass sich eine Gruppe von Optionsfeldern in aktuellen Browsern nicht mit der Tastatur durchlaufen lässt, ohne bei jedem Schritt ein change-Ereignis auszulösen, und dass ein solches Muster selbst mit Hinweis voraussichtlich an SC 2.1.1 Tastatur scheitert (W3C, F37). Wie die Variantenwahl insgesamt zugänglich wird, beschreibt der Beitrag zur barrierefreien Produktseite.
Mengenfeld oder letztes Feld schickt ab
Im Warenkorb aktualisiert manches Mengenfeld beim Verlassen oder schon bei der Eingabe die ganze Seite, und mehrteilige Eingaben wie eine Telefonnummer in drei Feldern schicken das Formular ab, sobald das letzte Feld gefüllt ist. F36 beschreibt genau das: ein Formular, das beim Verlassen des letzten Felds abgeschickt wird, auch wenn man nur rückwärts durch die Tab-Reihenfolge geht. Empfohlen wird stattdessen ein Absende-Button oder das gewohnte Absenden mit der Eingabetaste (W3C, F36). Ein automatischer Sprung ins nächste Feld ist dagegen zulässig, wenn das Verhalten am Anfang des Formulars beschrieben wird. So lautet das zweite Beispiel im Verständnisdokument (W3C, Understanding SC 3.2.2). Mehr zur Fehlerbehandlung in solchen Formularen steht im Beitrag zu barrierefreien Formularen.
| Muster | Was passiert | Kontextwechsel? | Saubere Lösung |
|---|---|---|---|
Sortierfeld mit onchange-Absenden | neue Seite bei jedem Optionswechsel | ja, ohne Vorwarnung ein Verstoß (F36) | Übernehmen-Button (H84, G80) |
| Sprachwahl mit sofortiger Umleitung | neue Sprachfassung, Fokus oben | enthalten | Button, Linkliste oder Hinweis vor dem Feld (G13) |
| Variantenwahl lädt Variantenadresse | neue Seite, Fokus oben, neuer Verlaufseintrag | enthalten | Bild und Preis auf derselben Seite aktualisieren, Fokus im Feld lassen |
| Optionsfelder öffnen ein Fenster | neues Fenster bei jedem Pfeildruck | ja, ohne Vorwarnung ein Verstoß (F37) | Button, kein neues Fenster |
| Letztes Feld schickt Formular ab | Absenden beim Verlassen des Felds | ja, ohne Vorwarnung ein Verstoß (F36) | Absende-Button und Eingabetaste |
| Lieferland befüllt Versandarten | zweites Feld erhält neue Optionen | nein, wenn das Feld danach folgt (SCR19) | so lassen, Ergebnis per Statusmeldung ansagen |
Lösung 1: der Übernehmen-Button
Bewährt ist eine schlichte Lösung: Das Auswahlfeld ändert nur seinen Wert, und erst ein eigener Button löst die Aktion aus. Die Technik G80 empfiehlt einen Absende-Button für jeden Kontextwechsel, weil er genau dafür gedacht ist, eine Anfrage mit den Formulardaten zu senden, und deshalb niemanden verwirrt (W3C, G80). Die Technik H84 überträgt das auf Auswahlfelder: Nutzende können die Werte in Ruhe durchsehen oder sich vertun, ohne dass etwas passiert, und lösen die Aktion aus, wenn sie mit der Wahl zufrieden sind (W3C, H84).
<!-- Wechsel bei Eingabe: jeder Optionswechsel lädt die Seite neu -->
<form action="/leuchten/" method="get">
<label for="sort-bad">Sortieren nach</label>
<select id="sort-bad" name="sort" onchange="this.form.submit()">
<option value="relevanz">Relevanz</option>
<option value="neu">Neuheiten</option>
<option value="preis-auf">Preis aufsteigend</option>
<option value="preis-ab">Preis absteigend</option>
</select>
</form>
<!-- Wechsel auf Anforderung: erst wählen, dann übernehmen -->
<form action="/leuchten/" method="get">
<label for="sort">Sortieren nach</label>
<select id="sort" name="sort">
<option value="relevanz">Relevanz</option>
<option value="neu">Neuheiten</option>
<option value="preis-auf">Preis aufsteigend</option>
<option value="preis-ab">Preis absteigend</option>
</select>
<button type="submit">Übernehmen</button>
</form>Das Muster hat Nebenwirkungen, von denen alle profitieren. Ohne JavaScript arbeitet es als normales GET-Formular, die Sortierung landet als Parameter in der Adresse und lässt sich teilen, und auch mit der Maus wählt man erst und lädt dann einmal. Der Button braucht einen sichtbaren, eindeutigen Text wie „Übernehmen“ oder „Sortierung anwenden“; ein reines Pfeilsymbol ohne zugänglichen Namen schafft das nächste Problem. Den Button nur für Tastaturnutzende einzublenden, ist keine gute Idee: Auch Menschen mit Tremor, die mit der Maus leicht die falsche Option treffen, profitieren davon, dass die Wahl erst nach einer Bestätigung wirkt (W3C, F36).
Die Prüfschritte der Technik sind entsprechend schlicht: Der Fokus auf einer Option, auch der Tastaturfokus, darf keine Aktion auslösen, und der Button muss die Aktion für den aktuell gewählten Wert ausführen (W3C, H84). Wer das Muster einmal als Komponente baut, hat das Thema für alle Sortier-, Mengen- und Filterleisten des Shops erledigt.
Lösung 2: das Verhalten vorher ankündigen
Wo ein Button nicht in Frage kommt, erlaubt das Kriterium einen zweiten Weg: das Verhalten vorher ankündigen. Die Technik G13 sieht vor, dass die Erklärung in der Lesereihenfolge vor dem Bedienelement steht, und rät, sie nach Möglichkeit programmatisch mit dem Element zu verknüpfen (W3C, G13). In HTML geschieht das mit aria-describedby; der Screenreader liest den Hinweis dann in der Regel zusammen mit Name und Rolle des Felds vor.
<!-- Hinweis steht vor dem Feld und ist mit ihm verknüpft -->
<p id="lang-hint">Die Seite wechselt sofort in die gewählte Sprache.</p>
<label for="lang">Sprache</label>
<select id="lang" aria-describedby="lang-hint">
<option value="/de/" selected>Deutsch</option>
<option value="/en/">English</option>
<option value="/fr/">Français</option>
</select>Ein Hinweis im Kleingedruckten am Seitenende, ein Tooltip, der nur beim Überfahren mit der Maus erscheint, oder ein Satz in der Erklärung zur Barrierefreiheit erfüllen den Zweck nicht: Der Hinweis muss verfügbar sein, bevor das Feld benutzt wird (W3C, G13). Die Ankündigung macht ein Muster konform, bequemer wird es dadurch nicht. Wer mit der Tastatur durch eine Sprachliste blättert, wird bei sofortiger Umleitung je nach Browser trotzdem nach dem ersten Pfeildruck aus der Seite geholt, er weiß es nur vorher. Für Sprach- und Länderwahl empfehlen wir deshalb ebenfalls einen Button oder eine Liste echter Links, in der jede Sprache ein eigener Link ist. Einen Link zu aktivieren ist keine Änderung einer Einstellung und fällt damit nicht unter 3.2.2 (W3C, Understanding SC 3.2.2).
Lösung 3: Inhalt aktualisieren, Kontext halten
Nicht jede Reaktion auf eine Auswahl muss auf einen Button warten. Die Technik SCR19 zeigt zwei verbundene Auswahlfelder: Wählt man im ersten einen Kontinent, erhält das zweite die passenden Länder, und das verursacht ausdrücklich keinen Kontextwechsel (W3C, SCR19). Wichtig ist eine Bedingung, die SCR19 hervorhebt: Das veränderte Feld steht in der Lesereihenfolge nach dem auslösenden Feld, damit assistive Technik die neuen Daten erfasst, wenn das Feld den Fokus erhält (W3C, SCR19). Im Shop entspricht das dem Lieferland, das die Liste der Versandarten befüllt, oder der Kundenart, die ein Feld für den Firmennamen einblendet.
<!-- Inhalt ändert sich, Kontext bleibt: das zweite Feld folgt in der Lesereihenfolge -->
<label for="country">Lieferland</label>
<select id="country" name="country">
<option value="DE">Deutschland</option>
<option value="AT">Österreich</option>
<option value="CH">Schweiz</option>
</select>
<label for="shipping">Versandart</label>
<select id="shipping" name="shipping">
<!-- wird beim Wechsel des Lieferlands neu befüllt -->
</select>
<p role="status" id="shipping-status"></p>
<!-- Skript setzt nach dem Befüllen z. B. "Versandarten für Österreich geladen" -->Schwieriger ist die Sortierung ohne Neuladen. Lädt ein Skript die Produktliste im Hintergrund neu und lässt den Fokus im Feld, bleibt die Adresse gleich, und kein Fenster öffnet sich. Die WCAG-Definition zählt aber auch das erhebliche Umordnen des Seiteninhalts zu den Kontextwechseln (W3C, Understanding SC 3.2.2), und eine komplett neu sortierte Trefferliste ist kaum etwas anderes. Dazu kommt der praktische Effekt: Jeder Pfeildruck baut die Liste neu auf, und Screenreader melden womöglich jedes Mal neue Inhalte. Auch bei Sortierung ohne Neuladen ist der Übernehmen-Button deshalb die verlässlichere Wahl.
Wer Inhalte aktualisiert, ohne den Fokus zu bewegen, sollte das Ergebnis ansagen. Das Kriterium SC 4.1.3 Statusmeldungen (Stufe AA) nennt als Beispiele kurze Texte wie „18 results returned“ oder „No results returned“, die als Statusmeldung gelten, solange sie keinen Fokus nehmen und kein Neuladen auslösen (W3C, Understanding SC 4.1.3). Ein Element mit role="status", das nach dem Befüllen „Versandarten für Österreich geladen“ oder die neue Trefferzahl meldet, erfüllt das. Wie Live-Regionen im Detail funktionieren, beschreibt der Beitrag zu ARIA-Rollen, Zuständen und Live-Regions; Filter und Trefferansagen auf der Kategorieseite behandelt der Beitrag zur barrierefreien Produktsuche.
Eigene Dropdowns: wenn die Auswahl dem Fokus folgt
Viele Shops ersetzen das native select durch eigene Komponenten: eine Schaltfläche, die eine Liste mit role="listbox" öffnet, oder eine Combobox mit Suchfeld. Am Grundsatz von 3.2.2 ändert das nichts, wohl aber an den Fallstricken. Der ARIA Authoring Practices Guide beschreibt für Listboxen mit Einzelauswahl das Modell „selection follows focus“: Bewegt sich der Fokus mit der Pfeiltaste auf eine Option, ist sie auch schon ausgewählt. Das kann laut APG in manchen Situationen sehr hilfreich sein und die Zugänglichkeit in anderen erheblich verschlechtern (W3C, ARIA Authoring Practices Guide).
Für Sortier- und Sprachlisten heißt das: Pfeiltasten bewegen nur die Markierung, Enter oder Leertaste übernimmt die Option ins Feld, und erst der Button löst den Seitenwechsel aus. Das Verständnisdokument zu SC 3.2.1 zieht dieselbe Linie für das Verlassen eines Sprungmenüs: Wer mit Escape oder Tab aus der Liste geht, springt nicht auf eine neue Seite, der Fokus verlässt nur das Menü (W3C, Understanding SC 3.2.1). Welche Tasten eine eigene Listbox insgesamt unterstützen muss, steht im Beitrag zur Tastaturnavigation; wie man solche Komponenten einmal sauber baut und im ganzen Shop wiederverwendet, im Beitrag zum barrierefreien Design-System.
Prüfen mit Tastatur und Screenreader
Automatische Prüfwerkzeuge erkennen 3.2.2 kaum, denn ob ein change-Ereignis eine neue Seite lädt, zeigt sich erst beim Bedienen. Die WebAIM Million weist darauf hin, dass alle automatischen Werkzeuge Grenzen haben und nicht alle Konformitätsfehler automatisch erkennbar sind (WebAIM Million 2026). Als der britische Government Digital Service zehn Werkzeuge auf eine Testseite mit 143 (GDS 2017) eingebauten Barrieren ansetzte, übersahen alle zusammen 42 (GDS 2017) davon, das sind 29 Prozent (GDS 2017). Das W3C formuliert es grundsätzlich: Prüfwerkzeuge können Barrierefreiheit nicht feststellen, sie können nur dabei helfen (W3C WAI). Für 3.2.2 bleibt die Handprüfung, Vorlage für Vorlage.
- Felder sammeln: auf jeder Vorlage, also Kategorie, Produkt, Warenkorb, Kasse sowie Kopf und Fuß, alle Auswahlfelder, Optionsfelder, Kontrollkästchen und mehrteiligen Eingaben notieren.
- Mit Tab hinein: das Feld per Tabulatortaste fokussieren, ohne die Liste zu öffnen. Schon dabei darf kein Kontextwechsel geschehen, sonst liegt ein Verstoß gegen SC 3.2.1 vor.
- Pfeiltaste einmal: im geschlossenen Feld einmal nach unten drücken. Lädt die Seite, ändert sich die Adresse, springt der Fokus oder öffnet sich ein Fenster, ist das ein Kontextwechsel.
- Liste geöffnet durchblättern: die Liste öffnen (unter Windows meist mit Alt und Pfeil nach unten), mehrere Optionen durchgehen und mit Escape schließen. Auch dabei darf sich der Kontext nicht ändern.
- Hinweis suchen: Wechselt der Kontext absichtlich, muss vor dem Feld ein Hinweis stehen, der auch vorgelesen wird, idealerweise über
aria-describedbyverknüpft. - Mit Screenreader wiederholen: Name, Rolle und aktuellen Wert anhören, eine Option wählen und prüfen, ob das Ergebnis angesagt wird, ohne dass der Fokus wandert.
- Mobil gegenprüfen: auf dem Smartphone erscheint die Auswahl meist in einer Ansicht des Systems; geprüft wird, ob schon das Durchscrollen der Optionen oder erst das Bestätigen die Aktion auslöst.
Wer sich zuerst ohne Spezialwerkzeug einen Überblick über die eigene Website verschaffen will, findet im BFSG-Selbsttest weitere Handgriffe dieser Art. Welche Prüfmethoden es gibt und wie sie zusammenspielen, beschreibt der Beitrag zum Accessibility Testing. Für die Prüfung, was Ihre Auswahlfelder in der Desktop- und der Smartphone-Darstellung an Screenreader übergeben, bieten wir einen eigenen Screenreader-Test an.
Die Prüffrage für jedes Auswahlfeld
3.2.2 im BFSG-Kontext
Das Barrierefreiheitsstärkungsgesetz gilt für Dienstleistungen, die nach dem 28. Juni 2025 für Verbraucher erbracht werden, darunter Dienstleistungen im elektronischen Geschäftsverkehr (BFSG). Die Verordnung zum Gesetz verlangt, dass Webseiten einschließlich der zugehörigen Online-Anwendungen auf konsistente und angemessene Weise wahrnehmbar, bedienbar, verständlich und robust gestaltet werden (BFSGV, § 12). Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen, nimmt das Gesetz von dieser Pflicht aus (BFSG, § 3). Wer die Anforderungen für den eigenen Shop systematisch durchgehen will, findet die Grundlagen auf unserer Seite zu den BFSG-Anforderungen.
Wie die Anforderungen technisch zu erfüllen sind, beschreiben harmonisierte Normen: Bei Dienstleistungen, die solchen Normen entsprechen, deren Fundstellen im Amtsblatt der EU veröffentlicht sind, wird vermutet, dass sie die Anforderungen der Verordnung erfüllen, soweit die Norm sie abdeckt (BFSG, § 4). Als aktuellen Bezugsstandard nennt das EU-Zentrum AccessibleEU die Fassung EN 301 549 V3.2.1 von 2021, bis die Kommission die im September 2026 erschienene Fassung V4.1.1 im Amtsblatt zitiert (AccessibleEU). V3.2.1 verlangt in Abschnitt 9.3.2.2, dass Webseiten das Erfolgskriterium 3.2.2 der WCAG 2.1 erfüllen (ETSI, EN 301 549 V3.2.1); die neue Fassung stellt auf WCAG 2.2 um (AccessibleEU). Wer eine Dienstleistung entgegen § 14 Abs. 1 BFSG anbietet oder erbringt, handelt ordnungswidrig (BFSG, § 37), und das kann mit einer Geldbuße bis zu 100.000 Euro (BFSG, § 37) geahndet werden. Ein einzelnes Auswahlfeld wirkt klein, aber es sitzt auf jeder Kategorieseite.
Über 3.2.2 hinaus geht SC 3.2.5 „Change on Request“ der Stufe AAA: Kontextwechsel geschehen nur auf ausdrückliche Anforderung, oder es gibt einen Mechanismus, sie abzuschalten (W3C, Understanding SC 3.2.5). Für die Konformität nach WCAG 2.2 AA wird AAA nicht verlangt. Wer Auswahlfelder ohnehin mit Button baut, erreicht das Ziel für diese Felder aber nebenbei, und SCR19 ist ausdrücklich auch als ausreichende Technik für 3.2.5 eingetragen (W3C, SCR19).
Vom Einzelbefund zur Komponentenregel
In einem Audit taucht 3.2.2 selten als einzelner Fund auf. Meist steckt das Verhalten in einer gemeinsamen Komponente oder einem Theme-Skript, das alle Auswahlfelder mit change an einen Seitenwechsel bindet, und dann ist jede Kategorie-, Such- und Herstellerseite betroffen. Die Behebung gehört deshalb in die Komponente: ein Auswahlfeld mit Button als Standard, eine dokumentierte Ausnahme für abhängige Felder nach SCR19 und eine Statusmeldung für jede Aktualisierung ohne Neuladen. Dasselbe gilt für die Kasse, wo Lieferland, Versandart und Zahlart oft voneinander abhängen; worauf es dort sonst ankommt, steht im Beitrag zum barrierefreien Checkout.
Die Regel gehört außerdem in die Abnahmekriterien: welche Tasten was bewirken, wann eine Aktion auslöst und welcher Text angesagt wird. Bei externen Dienstleistern steht sie zusätzlich im Vertrag. Im WCAG-Audit ordnen wir jeden Befund dem Kriterium und der Vorlage zu, in der barrierefreien Webentwicklung bauen wir die Komponente im bestehenden Code um, und in Schulungen geben wir die Prüfschritte an Ihr Team weiter. Einen Überblick über alles, was ein Shop für Kundschaft mit Behinderung leisten muss, gibt unsere Seite zum barrierefreien Shop.
Quellen
onchange-Ereignis an einem Auswahlfeld, das ein zweites, in der Lesereihenfolge folgendes Feld neu befüllt, ohne einen Kontextwechsel auszulösen (W3C, SCR19). Problematisch wird es erst, wenn das Skript eine neue Seite lädt, ein Fenster öffnet, den Fokus versetzt oder den Seiteninhalt erheblich umordnet. Aktualisierungen ohne Fokuswechsel sagt eine Statusmeldung an (W3C, Understanding SC 4.1.3).Verwandte Artikel
BFSG-Selbsttest: was Betreiber ohne Werkzeug prüfen können
Acht Proben im Browser ohne Zusatzprogramm: Tastatur, Zoom, Bilder, Seitentitel, Überschriften, Kontrast, Formular und Video – und wo der Selbsttest endet.
Aktionsbanner barrierefrei: Text gehört nicht ins Bild
Aktionsbanner mit eingebranntem Rabatttext verfehlen WCAG 1.4.5. So bauen Shops Banner als HTML-Text, nutzen Ausnahmen richtig und prüfen vor der Black Week.
KI-generierter Code: was Barrierefreiheitsprüfungen finden
Was Barrierefreiheitsprüfungen in KI-generiertem Code finden: vier typische Muster von div-Schaltfläche bis Fokusrahmen und wie die Prüfung in den Ablauf kommt.