WCAG & BFSG · WCAG-Referenz: Verständlich

WCAG 3.2.2: Bei Eingabe

Von Jakob Sommer Zuletzt geändert am 13. Juli 2026

WCAG 3.2.2 verlangt, dass das Ändern einer Einstellung – ein Häkchen setzen, eine Option wählen, einen Radiobutton anklicken – keinen unerwarteten Kontextwechsel auslöst. Erlaubt ist ein solcher Wechsel nur, wenn die Seite vorher darüber informiert hat; Auswahl ist keine Bestätigung.

(Englisch: On Input. Im BIK-BITV-Test heißt der Prüfschritt „3.2.2 Keine unerwartete Kontextänderung bei Eingabe“.)

Stufe	Prinzip	Teil der WCAG seit	Rechtlich verbindlich?
A	Verständlich	2.0 (2008)	Ja – über EN 301 549 in BFSG & BITV

Das Wichtigste in Kürze

Der Unterschied zu 3.2.1 ist die Ausnahme: Hier ist ein Kontextwechsel zulässig, wenn vorher darauf hingewiesen wurde.
Kontextwechsel und Inhaltsänderung sind zweierlei. Eine Trefferliste, die sich aktualisiert, ist erlaubt; eine Seite, die neu lädt, ist es nicht.
Änderungen müssen unterhalb des auslösenden Elements stattfinden. Der deutsche Prüfschritt begründet das damit, dass blinde Nutzende Änderungen oberhalb regelmäßig nicht bemerken.
Der Fokus darf sich dabei nicht verschieben – auch nicht durch eine Live-Region.
Das Sprach-Dropdown ist der Klassiker: In manchen Browsern feuert change schon beim Durchgehen der Optionen mit den Pfeiltasten.
Automatisches Absenden beim Verlassen des Formulars bewertet der Prüfschritt als nicht erfüllt.
Erlaubt bleibt viel: abhängige Felder einblenden, eine zweite Auswahlliste füllen, einen Bereich unterhalb aufklappen.
Stufe A, seit WCAG 2.0 unverändert und über die EN 301 549 verbindlich.

Darf ein Formular beim Auswählen automatisch abschicken?

Nur mit Vorwarnung. Angekündigt und erwartbar ist der Kontextwechsel erlaubt, sonst nicht.

Der Normtext sagt: Das Ändern der Einstellung eines Bestandteils der Benutzerschnittstelle löst nicht automatisch eine Änderung des Kontexts aus, es sei denn, die nutzende Person wurde vor der Verwendung des Bestandteils darüber informiert.

Zwei Begriffe müssen dafür klar sein.

Eine Einstellung ändern heißt: eine Checkbox anhaken, eine Option in einem Auswahlfeld wählen, einen Radiobutton setzen, einen Schieberegler verschieben. Etwas in ein Textfeld zu tippen ist noch keine Änderung der Einstellung – die tritt erst mit dem Verlassen des Felds ein.

Ein Kontextwechsel ist eine der vier großen Änderungen: neues Fenster, Seitenwechsel, Versetzen des Fokus, vollständiger Umbau des Inhalts. Alles darunter ist eine Inhaltsänderung – und die ist ausdrücklich erlaubt.

Der deutsche Prüfschritt geht an einer Stelle deutlich über den Normtext hinaus, und das ist der wertvollste Satz zu diesem Kriterium: Finden Änderungen auf derselben Seite nicht unterhalb des auslösenden Elements statt, werden sie von blinden Nutzenden häufig nicht wahrgenommen. Daraus folgt eine praktische Bauregel: Was sich durch eine Auswahl ändert, gehört unter das Element, das die Änderung auslöst. Eine Trefferzahl, die über dem Filter steht, existiert für Menschen, die sich linear durch die Seite arbeiten, faktisch nicht – sie sind längst daran vorbei.

Zwei weitere Anforderungen aus dem Prüfschritt:

Der Fokus darf sich nicht verschieben. Auch Änderungen, die über eine Live-Region angesagt werden, dürfen den Fokus nicht bewegen. Ansagen ja, Springen nein.

Automatisches Absenden beim Verlassen des Formulars ist ein eigener Bewertungsfall und gilt als nicht erfüllt.

Die Ausnahme ist eng, aber real: Wird vorher informiert, ist der Kontextwechsel zulässig. „Vorher“ heißt: Der Hinweis muss gelesen worden sein, bevor man das Element bedient – also davor stehen, nicht daneben und nicht danach.

Der Normtext steht im Understanding-Dokument des W3C zu 3.2.2, das deutsche Prüfvorgehen im Prüfschritt „3.2.2 Keine unerwartete Kontextänderung bei Eingabe“.

Oben zwei Filteransichten. Links, rot: Die Trefferzahl mit 128 Ergebnissen steht über dem Filter mit den Kategorien Bücher und Hörbücher, darunter die Ergebnisliste. Wer linear liest, ist an der Zahl längst vorbei, wenn er das Häkchen setzt, und bei starkem Zoom liegt sie außerhalb des Ausschnitts. Rechts, grün: Derselbe Filter steht oben, die Trefferzahl mit dem Vermerk role=status darunter, dann die Ergebnisliste. Die Änderung liegt im Lesefluss und wird höflich angesagt, ohne dass der Fokus den Filter verlässt. Darunter eine Tabelle, was nach der Auswahl passieren darf: Trefferliste unterhalb ersetzen, abhängige Auswahlliste füllen und Bereich unterhalb aufklappen sind Inhaltsänderungen und zulässig. Seite neu laden mit Fokussprung nach oben und Navigation zu einer anderen Seite sind Kontextwechsel und nur mit Hinweis davor zulässig. Ein Formular, das sich beim Verlassen selbst sendet, ist unzulässig. Darunter der Hinweis, dass ein Hinweis neben oder unter dem Auswahlfeld zu spät kommt. — Dieselbe Zahl, dieselbe Funktion – nur die Position entscheidet, ob sie ankommt.

Wen betrifft es besonders?

Tastaturnutzende trifft das Sprach-Dropdown mit voller Wucht. Ein geschlossenes Auswahlfeld wird mit den Pfeiltasten durchgegangen, und in mehreren Browsern löst jeder Schritt ein change-Ereignis aus. Wer von „Deutsch“ zu „Español“ will, landet unterwegs auf der englischen Seite. Das ist kein Randfall, sondern der Grund, warum dieses Muster in jeder Prüfliste steht.

Screenreader-Nutzende wollen erst alle Optionen hören, bevor sie sich entscheiden. Ein Auswahlfeld, das bei jeder Option handelt, macht genau das unmöglich. Und wenn sich als Folge einer Auswahl etwas oberhalb ändert, bekommen sie davon nichts mit – sie sind mit dem Lesefluss längst weiter unten.

Menschen mit kognitiven Einschränkungen verlieren durch unangekündigte Sprünge Orientierung und Vertrauen. Wer einmal versehentlich eine Bestellung ausgelöst hat, weil ein Radiobutton das Formular abschickte, wird bei der nächsten Auswahl zögern.

Und Menschen mit Vergrößerung sehen bei 400 Prozent Zoom vielleicht drei Zeilen gleichzeitig. Eine Änderung oberhalb des Filters liegt dann außerhalb des sichtbaren Bereichs – dasselbe Problem wie beim Screenreader, nur visuell.

Richtig & falsch im Code

Der Klassiker ist der Sprachumschalter:

<!-- Falsch: Auswahl navigiert sofort -->
<select onchange="location.href = this.value">
  <option value="/de.html">Deutsch</option>
  <option value="/en.html">English</option>
</select>

<!-- Richtig: Auswahl plus expliziter Knopf -->
<form action="/sprache-wechseln" method="get">
  <label for="sprache">Sprache</label>
  <select id="sprache" name="sprache">
    <option value="de">Deutsch</option>
    <option value="en">English</option>
  </select>
  <button type="submit">Sprache wechseln</button>
</form>

<!-- Noch besser: schlichte Links, einer je Sprache -->
<nav aria-label="Sprache">
  <ul>
    <li><a href="/de.html" hreflang="de" lang="de">Deutsch</a></li>
    <li><a href="/en.html" hreflang="en" lang="en">English</a></li>
  </ul>
</nav>

Die dritte Variante ist die beste: Links navigieren, Buttons handeln, und ein <a href> überrascht niemanden. Die Sprachauszeichnung über lang und hreflang gehört dazu – siehe 3.1.2 Sprache von Teilen.

Bei Filtern geht es um die Frage, wo die Änderung passiert:

<!-- Falsch: Trefferzahl steht über dem Filter -->
<p id="treffer">128 Ergebnisse</p>
<fieldset>
  <legend>Kategorie</legend>
  <label><input type="checkbox" name="kat" value="buch" /> Bücher</label>
</fieldset>

<!-- Richtig: Änderung unterhalb des auslösenden Elements,
     mit höflicher Ansage und ohne Fokussprung -->
<fieldset>
  <legend>Kategorie</legend>
  <label><input type="checkbox" name="kat" value="buch" /> Bücher</label>
</fieldset>
<p id="treffer" role="status">128 Ergebnisse</p>
<ul id="ergebnisliste"> … </ul>

// Falsch: lädt die ganze Seite neu und wirft den Fokus an den Anfang
filter.addEventListener('change', () => form.submit());

// Richtig: nur die Liste unterhalb wird ersetzt, der Fokus bleibt
filter.addEventListener('change', async () => {
  const daten = await ladeErgebnisse(new FormData(form));
  ergebnisliste.replaceChildren(...baueEintraege(daten));
  treffer.textContent = `${daten.length} Ergebnisse`;
});

Wo ein Kontextwechsel wirklich gewollt ist, rettet die Ausnahme – aber nur mit einem Hinweis, der vor dem Element steht:

<!-- Vertretbar: Hinweis steht vor der Auswahl -->
<p id="hinweis-standort">
  Die Auswahl eines Standorts lädt die zugehörige Filialseite.
</p>
<label for="standort">Filiale</label>
<select id="standort" name="standort"
        aria-describedby="hinweis-standort">
  <option value="">Bitte wählen</option>
  <option value="koeln">Köln</option>
</select>

Und ein Muster, das oft als Verstoß gemeldet wird, aber keiner ist: abhängige Felder.

// Richtig: die zweite Liste wird gefüllt, nichts wechselt
land.addEventListener('change', () => {
  region.replaceChildren(...regionenFuer(land.value));
  region.disabled = false;
});

So testest du es

Alle Auswahlfelder, Radiogruppen und Checkboxen ausschließlich mit der Tastatur durchgehen – mit Pfeiltasten und Leertaste, ohne Enter zu drücken.
Beobachten, ob die Seite wechselt oder ein Fenster aufgeht, bevor irgendetwas bestätigt wurde.
Auf den Fokus achten. Bleibt er nach der Auswahl dort, wo er war? Ein Fokussprung ist selbst dann ein Befund, wenn die Seite bleibt.
Prüfen, wo die Änderung erscheint. Steht das Ergebnis unterhalb des auslösenden Elements – oder darüber, wo es niemand bemerkt?
Formulare beim Verlassen testen: Weg vom letzten Feld tabben, ohne Absenden. Passiert etwas, ist der Prüfschritt nicht erfüllt.
Mit dem Screenreader gegenprüfen, ob die Änderung angesagt wird – über role="status" oder eine Live-Region, ohne den Fokus zu bewegen.
Nach onchange im Code suchen und jeden Treffer einordnen: Ändert er Inhalt unterhalb, oder wechselt er den Kontext?
Bei einer genutzten Ausnahme prüfen, ob der Hinweis wirklich vor dem Element steht und mit ihm verknüpft ist.

Häufiger Fehler in der Praxis

Der Klassiker bleibt das Sprungmenü. Ein Auswahlfeld mit Zielen, das per onchange navigiert – in Behördenportalen und älteren Redaktionssystemen noch weit verbreitet. Für Mausnutzende funktioniert es scheinbar tadellos, weil erst der Mausklick die Auswahl abschließt. Mit der Tastatur ist es unbenutzbar. Ich würd solche Menüs schlicht durch Linklisten ersetzen; das erledigt gleichzeitig 2.4.4 Linkzweck und spart JavaScript.

Der zweite ist der Filter, der die Seite neu lädt. Jede Checkbox löst ein form.submit() aus, die Seite baut sich neu auf, der Fokus landet ganz oben. Wer drei Filter setzen will, tabbt sich dreimal von vorn durch die Seite. Technisch ist das ein Kontextwechsel, praktisch ist es der Grund, warum Filterleisten für Tastaturnutzende so anstrengend sind.

Der dritte ist die Trefferzahl über dem Filter. Sie ist optisch prominent, oben neben der Überschrift, und ändert sich brav bei jeder Auswahl. Nur bemerkt sie niemand, der sich linear durch die Seite arbeitet – der Prüfschritt sagt das ausdrücklich. Die Lösung ist kein zusätzliches ARIA, sondern eine andere Reihenfolge: Ergebnis unter den Filter.

Und der vierte, der bei modernen Formularen häufiger wird: das automatische Speichern mit Fokussprung. Ein Feld verliert den Fokus, das Formular speichert, und eine Erfolgsmeldung bekommt den Fokus, damit sie „auf jeden Fall gehört wird“. Gutgemeint – aber das Versetzen des Fokus ist selbst ein Kontextwechsel. Eine höfliche Statusmeldung nach 4.1.3 erledigt dasselbe, ohne jemanden aus dem Formular zu werfen.

Häufige Fragen

Darf ein Filter die Ergebnisliste sofort aktualisieren?

Ja. Das ist eine Inhaltsänderung, kein Kontextwechsel, und ausdrücklich erlaubt. Drei Bedingungen: Die Änderung passiert unterhalb des auslösenden Elements, der Fokus bleibt stehen, und das Ergebnis wird über eine Statusmeldung angesagt. Ein vollständiges Neuladen der Seite wäre dagegen ein Kontextwechsel.

Was ist der Unterschied zwischen Kontextwechsel und Inhaltsänderung?

Ein Kontextwechsel ist eine der vier großen Änderungen: neues Fenster, andere Seite, versetzter Fokus, vollständiger Umbau der Seite. Alles Kleinere – ein zusätzliches Feld, eine aktualisierte Liste, ein aufgeklappter Bereich – ist eine Inhaltsänderung und fällt nicht unter das Verbot.

Wann greift die Ausnahme mit der Vorabinformation?

Wenn der Hinweis gelesen werden konnte, bevor das Element bedient wird. Praktisch heißt das: Der Hinweis steht vor dem Bedienelement im Quelltext und ist über aria-describedby damit verknüpft. Ein Hinweis daneben oder darunter erfüllt die Bedingung nicht, weil er zu spät kommt.

Darf ein Auswahlfeld ein anderes Feld befüllen?

Ja. Eine Länderauswahl, die die passende Regionenliste lädt, ist ein Standardmuster und kein Verstoß – solange der Fokus bleibt, wo er ist, und das gefüllte Feld unterhalb steht. Sinnvoll ist zusätzlich eine kurze Ansage, dass sich etwas geändert hat.

Ist automatisches Weiterspringen bei Codefeldern erlaubt?

Es ist ein Grenzfall. Ein Fokussprung ist ein Kontextwechsel, also braucht es die Ausnahme: einen Hinweis vor den Feldern, dass automatisch weitergesprungen wird. Der einfachere Weg ist ein einziges Feld für den ganzen Code – das erspart die Diskussion und hilft bei 3.3.8 Zugängliche Authentifizierung gleich mit.