WCAG 3.2.2: Bei Eingabe

WCAG 3.2.2 „On Input“ verlangt, dass das Ändern der Einstellung einer beliebigen Benutzeroberflächenkomponente nicht automatisch einen Kontextwechsel verursacht, es sei denn, der Nutzer wurde vorher über dieses Verhalten informiert. Dies schützt Nutzer vor desorientierenden, unerwarteten Seitenänderungen, die durch Formularinteraktionen ausgelöst werden.

Was diese Regel bedeutet

WCAG 3.2.2 On Input ist Teil des Prinzips Verständlich und fällt unter Richtlinie 3.2 Vorhersehbar. Sie besagt, dass das Ändern der Einstellung einer beliebigen Benutzeroberflächenkomponente nicht automatisch einen Kontextwechsel verursachen darf, es sei denn, der Nutzer wurde im Voraus darüber informiert, dass ein solches Verhalten auftreten wird.

Ein Kontextwechsel ist eine wesentliche Änderung des Inhalts einer Webseite, die Nutzer desorientieren kann, die nicht die gesamte Seite auf einmal sehen können. Laut WCAG-Spezifikation umfassen Kontextwechsel: Wechsel des User Agents (Browsers), Änderungen des Viewports, Änderungen des Fokus und Inhaltsänderungen, die die Bedeutung der Seite wesentlich verändern. Das Absenden eines Formulars, das Öffnen eines neuen Fensters oder das Navigieren zu einer anderen Seite gelten alle als Kontextwechsel. Das bloße Einblenden zusätzlichen Inhalts, etwa eines sich öffnenden Akkordeons, gilt nicht als Kontextwechsel.

Das Kriterium bezieht sich speziell auf das Ändern der Einstellung einer UI-Komponente – zum Beispiel das Auswählen einer Optionsschaltfläche (Radio Button), das Aktivieren eines Kontrollkästchens oder das Auswählen einer Option in einem <select>-Dropdown – im Gegensatz zur Aktivierung eines Steuerelements (wie dem Klicken auf eine Schaltfläche). Wenn eine Aktion einen expliziten Aktivierungsschritt erfordert (Enter drücken, „Absenden“ klicken), fällt sie im Allgemeinen nicht unter dieses Kriterium. Das problematische Muster liegt vor, wenn allein der Akt der Auswahl eines Werts sofort eine Navigation oder ein signifikantes Neuladen der Seite ohne jede Vorwarnung auslöst.

Was als erfüllt gilt: Ein Formular, das eine Absenden-Schaltfläche verwendet, um Nutzerauswahlen zu verarbeiten, selbst wenn diese Auswahlen Dropdowns oder Kontrollkästchen umfassen, erfüllt dieses Kriterium. Ein Dropdown, das Ergebnisse auf derselben Seite filtert, ohne neu zu laden oder den Fokus wesentlich zu verschieben, erfüllt das Kriterium. Eine Seite, die Nutzer im Voraus darauf hinweist – zum Beispiel mit einem sichtbaren Hinweis wie „Die Auswahl einer Sprache lädt die Seite neu“ –, dass eine bestimmte Eingabe einen Kontextwechsel auslöst, erfüllt das Kriterium ebenfalls.

Was als nicht erfüllt gilt: Ein Länder- oder Sprachwähler, der den Nutzer automatisch auf eine neue URL umleitet, sobald eine Option ausgewählt wird, erfüllt das Kriterium nicht. Ein Formular, das sich automatisch absendet und weg navigiert, wenn eine Optionsschaltfläche ausgewählt wird, ohne dass es eine Absenden-Schaltfläche gibt, erfüllt das Kriterium nicht. Ein Autovervollständigungs-Widget, das den Tastaturfokus ohne Vorwarnung bei der Auswahl in einen neuen Bereich der Seite verschiebt, erfüllt das Kriterium ebenfalls nicht.

Offizielle Ausnahmen: Die WCAG-Spezifikation weist darauf hin, dass ein automatischer Kontextwechsel zulässig ist, wenn der Nutzer vor der Verwendung der Komponente über das Verhalten informiert wurde. Dieser Hinweis muss vorhanden sein, bevor die Interaktion stattfindet, nicht danach.

Warum das wichtig ist

Unerwartete Kontextwechsel gehören zu den desorientierendsten Erfahrungen im Web, und die Auswirkungen verstärken sich für Nutzer mit Behinderungen erheblich. Wenn eine Seite plötzlich navigiert, neu lädt oder den Fokus ohne Vorwarnung verschiebt, verlieren Nutzer, die das vollständige visuelle Layout der Seite nicht sehen können, ihre Orientierung vollständig.

Screenreader-Nutzer sind besonders gefährdet. Wenn ein blinder Nutzer, der NVDA oder JAWS verwendet, eine Option in einem Dropdown auswählt und die Seite sofort neu lädt oder navigiert, kündigt der Screenreader den neuen Seitenkontext von Grund auf an. Der Nutzer verliert den Überblick darüber, wo er war, was er getan hat, und muss die gesamte Seite erneut durchgehen, um sich zu orientieren. Dies ist keine kleine Unannehmlichkeit – es kann die Aufgabe völlig unmöglich machen, sie eigenständig zu erledigen.

Nur-Tastatur-Nutzer, einschließlich Menschen mit motorischen Beeinträchtigungen, die keine Maus verwenden können, stehen vor einem ähnlichen Problem. Sie navigieren möglicherweise mit Tab- und Pfeiltasten durch ein Formular und lösen versehentlich einen Kontextwechsel aus, den sie nicht beabsichtigt haben. Ohne feinmotorische Kontrolle kann die Wiederherstellung nach einer unbeabsichtigten Navigation erheblichen Aufwand erfordern.

Kognitive Beeinträchtigungen verschärfen das Problem zusätzlich. Nutzer mit Aufmerksamkeitsstörungen, Lernschwierigkeiten oder Gedächtnisbeeinträchtigungen sind auf vorhersehbare, stabile Oberflächen angewiesen, um zu verstehen, was geschieht. Plötzliche Kontextwechsel zerstören das mentale Modell, das sie während der Sitzung aufgebaut haben, und zwingen sie oft dazu, von vorne zu beginnen oder die Aufgabe aufzugeben.

Nutzer mit vestibulären Störungen können körperliches Unwohlsein oder Desorientierung erleben, wenn sich Seiten unerwartet ändern, insbesondere wenn die Änderung Animationen oder Verschiebungen der Scrollposition beinhaltet.

Ein konkretes Szenario aus der Praxis: Stellen Sie sich eine E-Commerce-Checkout-Seite in der Türkei vor, auf der ein Nutzer seine Provinz aus einem Dropdown auswählt. Wenn diese Auswahl die Seite sofort neu lädt, um Versandoptionen zu aktualisieren, kann ein Screenreader-Nutzer sich plötzlich am Anfang der Seite wiederfinden, ohne Hinweis darauf, was passiert ist. Er müsste alle Formularfelder erneut durchgehen, um den ursprünglichen Ort zu finden, ohne zu wissen, ob seine vorherigen Eingaben erhalten geblieben sind. Diese Art von Reibung kann dazu führen, dass Nutzer den Kauf vollständig abbrechen.

Aus Usability- und SEO-Perspektive haben Seiten, die sich vorhersehbar verhalten, niedrigere Absprungraten. Nutzer brechen seltener frustriert ab, und Suchmaschinen-Crawler können den Inhalt zuverlässiger indexieren, ohne dass unerwartete Weiterleitungen die Crawl-Pfade stören.

Wie man testet

Automatisierter Scan als Basis: Führen Sie axe DevTools oder Lighthouse auf der Seite aus, um alle markierten Probleme unter WCAG 3.2 zu identifizieren. Obwohl 3.2.2 selbst manuelle Tests erfordert, kann axe verwandte Probleme (wie fehlende Labels oder Fokusmanagement-Probleme) aufzeigen, die einen Ausgangspunkt bieten. Notieren Sie alle Formularsteuerelemente – insbesondere <select>-Dropdowns, Radiogruppen und Kontrollkästchen – für die manuelle Nachprüfung.
Alle Eingabesteuerelemente mit Change-Handlern identifizieren: Untersuchen Sie in den Browser-DevTools das JavaScript der Seite oder verwenden Sie das Panel „Event Listeners“, um alle <select>-, <input type='radio'>-, <input type='checkbox'>- oder benutzerdefinierten Widgets zu identifizieren, die einen onchange-, oninput- oder gleichwertigen Event-Listener haben.
Manueller Tastatur-Interaktionstest: Verwenden Sie ausschließlich die Tastatur (Tab zum Navigieren, Pfeiltasten für Radio-/Select-Optionen), um mit jedem identifizierten Steuerelement zu interagieren. Beobachten Sie, ob die Auswahl einer Option dazu führt, dass die Seite navigiert, neu lädt, ein neues Fenster öffnet oder den Fokus in einen deutlich anderen Teil der Seite verschiebt. Falls ja, prüfen Sie, ob vor dem Steuerelement ein sichtbarer Hinweis angezeigt wurde.
NVDA + Firefox-Test: Starten Sie Firefox mit aktivem NVDA. Navigieren Sie mit dem virtuellen Cursor von NVDA (Pfeiltasten) zu jedem Formularsteuerelement und interagieren Sie dann im Formularmodus (Enter oder Leertaste). Wählen Sie Optionen in Dropdowns und Radiogruppen und achten Sie auf unerwartete Ansagen, die auf ein Laden der Seite, eine Navigation oder einen größeren Kontextwechsel hinweisen. Notieren Sie, ob NVDA einen neuen Seitentitel oder einen deutlich anderen Bereich vorliest.
VoiceOver + Safari-Test (macOS/iOS): Aktivieren Sie VoiceOver und navigieren Sie mit VO+Rechtspfeil zu jedem Steuerelement. Interagieren Sie mit Dropdowns und Kontrollkästchen. Wenn ein Kontextwechsel auftritt, kündigt VoiceOver in der Regel die neue Seite oder den Fokuswechsel an. Stellen Sie fest, ob der Nutzer vorab gewarnt wurde.
JAWS + Chrome-Test: Verwenden Sie JAWS im virtuellen Cursor-Modus, um durch die Seite zu navigieren. Interagieren Sie mit Formularsteuerelementen und beobachten Sie, ob JAWS unmittelbar nach einer Eingabeänderung einen Kontextwechsel ankündigt (Änderung des Seitentitels, neue URL, verschobene Leseposition) – ohne dass eine Absenden-Schaltfläche aktiviert wurde.
Visueller Beobachtungstest: Für sehende Nutzer ohne unterstützende Technologien: Wählen Sie Optionen in jedem Dropdown und jeder Radiogruppe aus und beobachten Sie, ob die Seite unerwartet navigiert oder neu lädt. Falls dies geschieht, prüfen Sie, ob ein vor dem Steuerelement sichtbarer Hinweis auf dieses Verhalten aufmerksam gemacht hat.

Wie man es behebt

Automatisch absendendes Select-Dropdown – Falsch

<!-- BAD: Selecting a country immediately redirects the page -->
<label for='country'>Select Country</label>
<select id='country' name='country' onchange='window.location.href="/region/" + this.value'>
  <option value='tr'>Turkey</option>
  <option value='de'>Germany</option>
  <option value='us'>United States</option>
</select>

Automatisch absendendes Select-Dropdown – Richtig

<!-- GOOD: Selection is confirmed via a submit button; no automatic navigation -->
<form action='/region/' method='get'>
  <label for='country'>Select Country</label>
  <select id='country' name='country'>
    <option value='tr'>Turkey</option>
    <option value='de'>Germany</option>
    <option value='us'>United States</option>
  </select>
  <!-- Explicit submit button gives the user control over when navigation occurs -->
  <button type='submit'>Go</button>
</form>

Radio-Button-Auto-Submit-Muster – Falsch

<!-- BAD: Selecting a payment method immediately submits the form -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='this.form.submit()'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='this.form.submit()'>
    Bank Transfer
  </label>
</fieldset>

Radio-Button-Auto-Submit-Muster – Richtig

<!-- GOOD: onchange can update UI state without navigating; submit requires user action -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='showPaymentDetails(this.value)'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='showPaymentDetails(this.value)'>
    Bank Transfer
  </label>
</fieldset>
<!-- showPaymentDetails() reveals additional fields inline — no context change -->
<div id='payment-details' aria-live='polite'></div>
<button type='submit'>Confirm Payment</button>

Sprachumschalter mit Vorwarnung – Richtig

<!-- ACCEPTABLE: User is warned before interacting that selecting will reload the page -->
<p id='lang-notice'>Selecting a language will immediately reload the page.</p>
<label for='lang-select'>Language</label>
<select
  id='lang-select'
  name='lang'
  aria-describedby='lang-notice'
  onchange='window.location.href="/" + this.value + "/"'
>
  <option value='en'>English</option>
  <option value='tr'>Türkçe</option>
  <option value='de'>Deutsch</option>
</select>
<!-- The aria-describedby links the warning to the control for screen reader users -->

Häufige Fehler

Direktes Anhängen von window.location.href-Zuweisungen an das <select>-Element im onchange-Attribut ohne Absenden-Schaltfläche, was dazu führt, dass die Seite sofort navigiert, sobald der Nutzer eine Option auswählt.
Verwendung von this.form.submit() innerhalb des onchange-Handlers einer Optionsschaltfläche, wodurch das gesamte Formular abgesendet und weg navigiert wird, sobald eine Radio-Option ausgewählt wird – bevor der Nutzer seine Auswahl überprüfen kann.
Platzierung der Vorwarnung nach dem Steuerelement im DOM, sodass Screenreader-Nutzer und Tastaturnutzer zuerst auf das Steuerelement stoßen, bevor sie die Warnung über das Verhalten hören oder lesen, das es auslöst.
Anzeige der Vorwarnung nur als Tooltip oder Platzhaltertext, der nicht zuverlässig an unterstützende Technologien übermittelt wird, sodass Screenreader-Nutzer keinen Hinweis darauf erhalten, dass ein Kontextwechsel auf ihre Eingabe folgen wird.
Erstellen benutzerdefinierter Dropdown-Widgets mit <div>- und <ul>-Elementen, die bei Auswahl per JavaScript eine Navigation auslösen, aber nicht über die semantische Struktur verfügen, die es Testern oder Accessibility-Overlays ermöglichen würde, sie als interaktive Steuerelemente zu erkennen, die unter 3.2.2 besonders geprüft werden müssen.
Automatisches Absenden eines Formulars beim letzten Feld (zum Beispiel ein PIN- oder OTP-Eingabefeld), sobald die erforderliche Anzahl von Zeichen erreicht ist, ohne den Nutzer darüber zu informieren, dass dies geschehen wird.
Öffnen eines modalen Dialogs oder eines neuen Browserfensters als Reaktion auf das Aktivieren eines Kontrollkästchens, ohne vorherige Ankündigung – dies stellt einen Kontextwechsel dar, weil es den Viewport und den Fokus deutlich verschiebt.
Verwechslung vorhersehbarer In-Page-Inhaltsaktualisierungen mit Kontextwechseln und das Hinzufügen unnötiger Absenden-Schaltflächen rund um Interaktionen, die bereits zulässig sind (wie ein Live-Suchfilter), was die Benutzeroberfläche überladen kann – Teams sollten verstehen, dass Inline-Updates, die nicht desorientieren, keinen Absende-Schritt erfordern.
Verlassen ausschließlich auf automatisierte Accessibility-Scans und das Markieren von 3.2.2 als bestanden, weil keine automatisierte Regel einen Verstoß gemeldet hat, ohne die obligatorischen manuellen Tastatur- und Screenreader-Tests durchzuführen, die dieses Kriterium verlangt.
Anwenden eines Kontextwechsel auslösenden onchange-Handlers auf ein <select>, das zum Sortieren oder Filtern in einer Ergebnisliste verwendet wird, wodurch ein vollständiges Neuladen der Seite statt eines AJAX-Updates ausgelöst wird, und es wird versäumt, Nutzer darauf hinzuweisen, dass dieses Neuladen bei der Auswahl erfolgen wird.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web-Barrierefreiheit auf Basis von WCAG 2.2 fest. WCAG 3.2.2 On Input ist ein Kriterium der Stufe A, das die minimale Konformitätsbasis unter der Verfügung darstellt – das bedeutet, die Einhaltung ist nicht optional, sondern für alle erfassten Stellen rechtlich vorgeschrieben.

Die Verfügung definiert einen zweistufigen Umsetzungszeitplan. Öffentliche Institutionen – einschließlich Ministerien, Gemeinden, staatlicher Universitäten und Regierungsbehörden – müssen innerhalb von einem Jahr nach Veröffentlichung der Verfügung vollständige Konformität mit Stufe A erreichen. Private Sektorunternehmen, die von der Regelung erfasst sind, haben ein Zeitfenster von zwei Jahren, um die Anforderungen zu erfüllen.

Die folgenden Arten von Einrichtungen sind in der Verfügung ausdrücklich genannt und müssen daher sicherstellen, dass ihre digitalen Dienste mit WCAG 3.2.2 übereinstimmen: E-Commerce-Plattformen, öffentliche Institutionen auf allen Ebenen der Regierung, Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, lizenzierte Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind.

Für diese Einrichtungen stellt ein Verstoß gegen WCAG 3.2.2 – etwa ein Sprachwähler in einem Bankportal, der bei der Auswahl automatisch weiterleitet, oder ein Terminformular eines Krankenhauses, das automatisch abgesendet wird, wenn eine Abteilungs-Optionsschaltfläche ausgewählt wird – eine direkte Nichteinhaltung der Vorschriften dar. Angesichts der Tatsache, dass die Türkei eine beträchtliche Zahl von Nutzern mit Behinderungen hat und dass digitale Regierungsdienste zunehmend der primäre Kanal für Bürger sind, um öffentliche Leistungen in Anspruch zu nehmen, sind die praktischen Folgen, dieses Kriterium zu ignorieren, erheblich.

Organisationen, die der Verfügung unterliegen, sollten Tests zu WCAG 3.2.2 als obligatorischen Auditschritt im Rahmen der Qualitätssicherung behandeln. Da automatisierte Tools Verstöße gegen dieses Kriterium nicht erkennen können, müssen manuelle Tests durch geschulte Barrierefreiheits-Spezialisten – einschließlich Tastaturinteraktion, Screenreader-Verhalten mit NVDA und JAWS sowie explizite Überprüfung aller durch onchange gesteuerten Interaktionen – in den Compliance-Prozess integriert werden. Die Dokumentation von Testergebnissen und etwaigen akzeptierten Ausnahmen (mit vorhandenen Vorwarnungen) ist ratsam, um gegenüber Aufsichtsbehörden die gebotene Sorgfalt nachweisen zu können.