Zurück zu den WCAG

WCAG 2.1 - 3.2.2

On Input

Die Änderung der Einstellung eines beliebigen Benutzerschnittstellenelements führt nicht automatisch zu einer Änderung des Kontexts, es sei denn, der Benutzer wurde vor der Verwendung des Elements über das Verhalten informiert.

Inhalt

Was Bedeutet das Success Criterium 3.2.2 - On Input?Warum ist es so wichtig, das Success Criterium 3.2.2 - On Input zu beachten?Was hat das Success Criterium 3.2.2 - On Input mit dem BFSG zu tun?Lösungen für 3.2.2 - On Input anhand von CodebeispielenWie löse ich Verstöße gegen das Success Criterium 3.2.2 - On Input?

Was Bedeutet das Success Criterium 3.2.2 - On Input?

Das Success Criterion 3.2.2 "On Input" verlangt, dass keine unerwarteten Veränderungen auf einer Webseite auftreten, sobald Nutzer*innen Eingaben in Formularfelder machen oder Einstellungen vornehmen. Das bedeutet konkret: Wenn eine Person z.B. in einem Formular ein Feld auswählt oder Daten eingibt (etwa bei Dropdown-Menüs, Checkboxen, Radiobuttons oder Textfeldern), darf dadurch nicht automatisch die Seite wechseln, der Fokus verschoben werden oder irgendwelche Inhalte plötzlich erscheinen oder verschwinden. Ausnahmen gibt es nur, wenn der Nutzer oder die Nutzerin dies ausdrücklich bestätigt (z.B. durch einen Klick auf einen Button wie "Absenden" oder "Weiter").

Typische Anforderungen
  • Kein automatischer Seitenwechsel bei Änderung eines Formularfelds.
  • Kein automatischer Fokuswechsel nach Eingabe oder Auswahl.
  • Alle Änderungen, die durch Eingaben passieren könnten, müssen vorher angekündigt werden oder erst erfolgen, wenn aktiv bestätigt wird (z.B. durch eine Schaltfläche).
Technische Umsetzung
  • "onchange"- oder ähnliche Eventhandler dürfen nicht ohne eine zusätzliche Bestätigung des Nutzers zu drastischen Änderungen am Inhalt führen.
  • Wenn Webseiten dynamisch auf Nutzereingaben reagieren müssen (z.B. Filteroptionen), sollte dies für alle verständlich und nachvollziehbar geschehen (z.B. mit Hinweisen oder zusätzlicher Bestätigung).

Warum ist es so wichtig, das Success Criterium 3.2.2 - On Input zu beachten?

Viele Nutzerinnen, insbesondere Menschen mit kognitiven Einschränkungen, motorischen Beeinträchtigungen oder die assistive Technologien nutzen, können von plötzlichen Änderungen verwirrt oder überfordert werden. Unerwartete Seitenwechsel sorgen oft dafür, dass eingegebene Informationen verloren gehen, der Kontext verschwindet oder Nutzerinnen schlicht nicht mehr wissen, was gerade passiert ist. Dies kann dazu führen, dass die Seite nicht mehr nutzbar ist. Indem Veränderungen erst nach einem bewussten Schritt, wie einem Klick auf einen Button erfolgen, behalten Nutzer*innen die Kontrolle über das, was passiert.

Was hat das Success Criterium 3.2.2 - On Input mit dem BFSG zu tun?

Das Barrierefreiheitsstärkungsgesetz (BFSG) in Deutschland schreibt vor, dass Websites und digitale Angebote die Anforderungen der EU-Richtlinie und damit der WCAG erfüllen müssen. Das Success Criterion 3.2.2 ist verpflichtend, weil eine Website andernfalls nicht zuverlässig, vorhersagbar und sicher bedient werden kann. Werden auf Eingabe plötzlich Inhalte verändert, Seiten gewechselt oder der Fokus verschoben, können Menschen mit Behinderungen digitale Dienstleistungen nicht gleichberechtigt nutzen. Bei Nichteinhaltung verstößt die Website somit klar gegen das BFSG und ist rechtlich nicht konform.

Lösungen für 3.2.2 - On Input anhand von Codebeispielen

Falscher Code

<select onchange="document.location=this.value"> <option value="/">Startseite</option> <option value="/kontakt">Kontakt</option> <option value="/impressum">Impressum</option> </select>

Korrekter Code

<form> <select name="seite" id="seitenwahl"> <option value="/">Startseite</option> <option value="/kontakt">Kontakt</option> <option value="/impressum">Impressum</option> </select> <button type="submit">Seite laden</button> </form>

Beim schlechten Beispiel führt schon die Auswahl einer neuen Option sofort zum Seitenwechsel – das ist überraschend und potentiell verwirrend. Im guten Beispiel passiert der Seitenwechsel erst, nachdem die Nutzer*innen aktiv auf den Button klicken. Dadurch ist das Verhalten vorhersehbar und barrierefrei.

Falscher Code

<input type="checkbox" onchange="document.getElementById('weitereInfos').style.display='block'"> Weitere Infos anzeigen <div id="weitereInfos" style="display:none"> Hier stehen jetzt plötzlich wichtige Informationen. </div>

Korrekter Code

<input type="checkbox" id="zeigeInfos"> Weitere Infos anzeigen <div id="weitereInfos" style="display:none" aria-live="polite"> Hier stehen ausführliche Informationen. </div> <script> document.getElementById('zeigeInfos').addEventListener('change', function(e) { document.getElementById('weitereInfos').style.display = this.checked ? 'block' : 'none'; }); </script>

Während der erste Code Inhalte ohne Ankündigung einblendet (was Menschen mit Screenreadern irritieren kann), nutzt das gute Beispiel ein aria-live-Attribut, damit Screenreader-Nutzer*innen informiert werden. Zentral ist aber auch im zweiten Beispiel: Gerade bei umfangreicheren Inhaltsänderungen sollte vorher erkennbar sein, dass durch die Auswahl Inhalte ein- oder ausgeblendet werden.

Wie löse ich Verstöße gegen das Success Criterium 3.2.2 - On Input?

Zwei Ansichten eines Accessibility Audits mit Grafiken, die einen zeitlichen Verlauf zeigen und Codebeispielen

Unser Accessibility Audit bietet Ihnen die Möglichkeit, mittels unseres AI-basierten Barrierefreiheits-Assistenten, vollautomatisch konkrete Lösungsvorschläge für Ihre Seite zu erstellen. Dafür scannen wir Ihre Website und ihren Quellcode, finden Problemstellen und zeigen Ihnen anhand Ihres eigenen Websitecode fertige Lösungen zum Kopieren und Einfügen. Starten Sie jetzt den Accessibility Audit kostenlos.

Wir prüfen eine Unterseite Ihrer Website. Geben Sie eine beliebige URL ein.