WCAG 3.2.5: Änderung auf Anfrage

WCAG 3.2.5 verlangt, dass Kontextänderungen – wie Seitenwechsel, Formularübermittlungen oder Inhaltsaktualisierungen – nur durch eine ausdrückliche Benutzeraktion ausgelöst werden und nicht automatisch. Dies schützt Nutzer, die auf Screenreader, Tastaturnavigation oder kognitive Unterstützungstools angewiesen sind, vor unerwarteten Unterbrechungen ihres Nutzungserlebnisses beim Surfen.

Was diese Regel bedeutet

WCAG 3.2.5 Change on Request ist ein Kriterium der Stufe AAA unter dem Prinzip „Verständlich“. Es besagt, dass Kontextänderungen ausschließlich vom Nutzer initiiert werden dürfen und nicht automatisch vom System ausgelöst werden dürfen. Eine „Kontextänderung“ wird in den WCAG als eine wesentliche Änderung des Inhalts der Webseite definiert, die ohne Bewusstsein des Nutzers Personen desorientieren kann, die nicht in der Lage sind, die gesamte Seite auf einmal zu erfassen. Dies umfasst Änderungen am User Agent (Browser), Viewport, Fokus oder Inhalt, die die Bedeutung der Seite wesentlich verändern.

Das Kriterium verbietet konkret jeden Mechanismus, der eine Kontextänderung ohne eine ausdrückliche Nutzeranforderung verursacht. Es erweitert die Anforderungen von 3.2.1 (On Focus) und 3.2.2 (On Input), indem es alle verbleibenden Szenarien adressiert, in denen automatische Kontextänderungen auftreten könnten – einschließlich, aber nicht beschränkt auf: automatisch aktualisierende Seiten, Karussells, die automatisch weiterlaufen und weg navigieren, Meta-Redirect-Tags mit kurzen Verzögerungen, durch JavaScript ausgelöste Navigation beim Ausfüllen von Formularfeldern sowie das Öffnen neuer Fenster oder Tabs ohne Anstoß durch den Nutzer.

Ein Bestehen unter diesem Kriterium erfordert eine von zwei Bedingungen: Entweder werden Kontextänderungen nur durch explizite, bewusste Nutzeraktionen ausgelöst (z. B. durch Aktivieren einer Schaltfläche oder eines Links), oder es wird ein Mechanismus bereitgestellt, der es dem Nutzer ermöglicht, automatische Kontextänderungen zu deaktivieren, bevor sie auftreten. Wenn eine Seite sich beispielsweise alle 30 Sekunden automatisch aktualisiert und zu neuen Inhalten navigiert, fällt sie durch – es sei denn, es existiert ein klar beschriftetes Steuerelement, um dieses Verhalten zu deaktivieren, bevor die erste Aktualisierung stattfindet. Eine bloße Warnung im Nachhinein ist nicht ausreichend.

Das Kriterium gilt breit für alle interaktiven und dynamischen Webinhalte. Häufig betroffene Elemente und Verhaltensweisen umfassen: <meta http-equiv='refresh'>-Redirects, durch JavaScript ausgelöste window.location- oder history.pushState-Aufrufe, die über Timer gesteuert werden, onchange-Event-Handler auf <select>-Elementen, die zu einer neuen URL navigieren, automatisch absendende Formulare, fokusgesteuerte Navigation sowie jedes Widget, das automatisch scrollt, Folien weiterblättert oder die sichtbare Inhaltsmenge ohne Nutzereingabe verändert.

Eine wichtige offizielle Ausnahme: Wenn die Kontextänderung als Reaktion auf eine Einstellung erfolgt, die der Nutzer ausdrücklich und wissentlich konfiguriert hat – zum Beispiel ein Einstellungsbereich, in dem der Nutzer „alle Minute automatisch aktualisieren“ auswählt – ist das automatische Verhalten zulässig, weil der Nutzer es angefordert hat. Der entscheidende Unterschied ist, ob der Nutzer eine informierte, bewusste Entscheidung getroffen hat, das automatische Verhalten zu aktivieren, oder ob er ihm unerwartet begegnet.

Warum das wichtig ist

Unerwartete Kontextänderungen gehören zu den desorientierendsten Erfahrungen im Web, und ihre Auswirkungen variieren erheblich zwischen verschiedenen Gruppen von Nutzerinnen und Nutzern mit Behinderungen.

Für blinde Nutzer, die auf Screenreader angewiesen sind, kann eine plötzliche Seitennavigation oder Inhaltsaktualisierung dazu führen, dass der Lesecursor an eine völlig andere Position auf der Seite springt – oder an den Anfang zurückgesetzt wird – ohne jede Ankündigung. Wenn ein Nutzer mitten in einem langen Artikel ist und die Seite automatisch zu einer neuen URL weiterleitet, verliert er vollständig seine Position und versteht möglicherweise nicht, was passiert ist oder wie er sich erholen kann. Screenreader wie NVDA, JAWS und VoiceOver kündigen Seitennavigationen nicht immer konsistent oder zeitnah an, sodass Nutzer verwirrt sein können, wo sie sich befinden und was sich geändert hat.

Für Nutzer mit motorischen Beeinträchtigungen, die per Tastatur, Kopfmaus, Schaltergerät oder Blicksteuerung navigieren, können unerwartete Fokusänderungen katastrophal sein. Wenn der Fokus programmatisch ohne Nutzeraktion verschoben wird – etwa wenn ein Formular nach dem Ausfüllen eines Feldes automatisch zum nächsten Feld weiter springt – kann der Nutzer seine Position verlieren und ist gezwungen, mühsam erneut zu navigieren, um herauszufinden, wohin das System ihn gebracht hat. Für Nutzer, deren Eingabegeräte erheblichen körperlichen Aufwand pro Tastendruck erfordern, stellt diese erneute Navigation eine reale Barriere für die Barrierefreiheit dar.

Nutzer mit kognitiven Beeinträchtigungen, einschließlich Personen mit Aufmerksamkeitsstörungen, Gedächtnisbeeinträchtigungen oder Angststörungen, sind besonders anfällig für unerwartete Änderungen. Automatische Seitenänderungen zerstören ihr mentales Modell der Benutzeroberfläche. Ein Nutzer, der innehält, um Anweisungen zu lesen, und dann feststellt, dass die Seite neu geladen wurde, wird sich wahrscheinlich verwirrt oder beunruhigt fühlen. Diese Unterbrechung kann es unmöglich machen, Transaktionen abzuschließen oder Informationen selbstständig aufzunehmen.

Für Nutzer mit vestibulären Störungen können schnelle und unerwartete visuelle Änderungen – wie ein automatisch weiterlaufendes Karussell, das zusätzlich Navigation auslöst – körperliche Symptome wie Schwindel und Übelkeit verursachen. Selbst sehende Nutzer ohne diagnostizierte Behinderung profitieren von vorhersehbaren Oberflächen: Forschung zeigt konsistent, dass unerwartete Navigationen die Fehlerraten und Abbruchquoten von Aufgaben in allen Nutzergruppen erhöhen.

Ein konkretes Szenario aus der Praxis: Eine türkische E-Commerce-Seite sendet ein Produktfilterformular automatisch ab, sobald ein Nutzer einen Wert in einem Dropdown auswählt – und navigiert zu einer neuen Suchergebnis-URL. Ein reiner Tastaturnutzer, der sich per Tab durch die Filter bewegt, um mehrere Kriterien auszuwählen, stellt fest, dass die Auswahl der ersten Option die Seite sofort neu lädt und das Filterpanel einklappt. Er muss das Panel erneut öffnen, zu seiner Ausgangsposition zurück navigieren und es erneut versuchen – möglicherweise in einer Schleife, die die Funktion vollständig unbenutzbar macht. Laut Weltgesundheitsorganisation leben weltweit etwa 1,3 Milliarden Menschen mit irgendeiner Form von Behinderung, und Muster wie dieses schließen sie überproportional von digitalen Diensten aus.

Aus Usability- und SEO-Perspektive haben Seiten, die automatisch weiterleiten oder automatisch aktualisieren, ebenfalls tendenziell höhere Absprungraten, da Nutzer, die auf unerwartetes Verhalten stoßen, häufig die Seite verlassen. Suchmaschinen können unerwartete Redirects, die sich zwischen Crawler- und Nutzersitzungen unterscheiden, ebenfalls abstrafen, sodass die Einhaltung von 3.2.5 im Einklang mit guter technischer SEO-Hygiene steht.

Wie man testet

Automatischer Scan (Baseline): Führen Sie axe DevTools oder Lighthouse auf der Seite aus, um alle markierten Probleme im Zusammenhang mit Redirects oder Fokusmanagement zu erfassen. Öffnen Sie in den Chrome DevTools das Lighthouse-Panel und führen Sie ein Accessibility-Audit aus. Klicken Sie in der axe DevTools-Erweiterung auf „Analyze“ und überprüfen Sie die Ergebnisse. Beachten Sie, dass ein sauberer automatischer Befund die Konformität mit 3.2.5 nicht bestätigt – manuelle Tests sind unerlässlich.
Auf Meta-Refresh prüfen: Öffnen Sie die Seite in einem Browser, klicken Sie mit der rechten Maustaste und wählen Sie „Seitenquelltext anzeigen“, und suchen Sie (Strg+F / Cmd+F) nach http-equiv oder refresh. Jedes <meta http-equiv='refresh'>-Tag mit einer URL oder mit einer Verzögerung von mehr als 72 Stunden ohne einen Mechanismus zu seiner Deaktivierung stellt einen Fehler dar.
Seitenverhalten über die Zeit beobachten: Laden Sie die Seite und warten Sie 2–5 Minuten, ohne zu interagieren. Achten Sie auf automatische Inhaltsänderungen, Seitenneuladungen, Navigationen oder das Öffnen neuer Fenster. Überprüfen Sie die Adressleiste und den Tab-Titel des Browsers auf Änderungen. Wenn etwas ohne Ihr Zutun geschieht, ist das Kriterium wahrscheinlich nicht erfüllt.
Formularsteuerelemente und Dropdowns testen: Navigieren Sie ausschließlich mit der Tastatur (Tab, Pfeiltasten, Enter, Leertaste) zu jedem <select>, jeder Radiobutton-Gruppe oder Checkbox. Ändern Sie Werte und beobachten Sie, ob eine Navigation oder eine wesentliche Inhaltsänderung unmittelbar bei der Auswahl erfolgt – bevor Sie eine Absende-Schaltfläche aktivieren. Wenn dies der Fall ist, liegt ein Fehler vor, sofern nicht bereits vor Erreichen des Elements ein Steuerelement bereitgestellt wurde, um dieses Verhalten zu deaktivieren.
Test mit NVDA + Firefox: Aktivieren Sie NVDA (Einfügen+Leertaste für den Browse-Modus), navigieren Sie mit den Pfeiltasten und Tab durch die Seite. Führen Sie Formularinteraktionen durch und achten Sie darauf, ob Fokus oder Leseposition unerwartet verlegt werden. Hören Sie auf Ankündigungen von Seitenänderungen. Wenn der Screenreader eine neue Seite ankündigt oder der virtuelle Cursor ohne Ihre ausdrückliche Aktion zurückgesetzt wird, deutet dies auf eine Kontextänderung hin.
Test mit VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver (Cmd+F5 auf dem Mac), navigieren Sie mit VO+Pfeiltasten. Interagieren Sie mit Steuerelementen und achten Sie auf unerwartete Seitenankündigungen oder Cursor-Resets. Wischen Sie auf iOS durch die Elemente und achten Sie auf plötzliche Änderungen in der Struktur des Accessibility-Trees, die Sie nicht initiiert haben.
Test mit JAWS + Chrome: Aktivieren Sie JAWS und navigieren Sie mit Tab und Pfeiltasten. Senden Sie Formulare ab und interagieren Sie mit dynamischen Widgets. Vergewissern Sie sich, dass Fokus und Position des virtuellen Cursors jederzeit vorhersehbar und unter Ihrer Kontrolle bleiben.
JavaScript-Quelltext überprüfen: Verwenden Sie in den Chrome DevTools das Sources-Panel oder die Suche (Strg+Umschalt+F) nach Mustern wie window.location, location.href, history.pushState, setTimeout in Kombination mit Navigationsaufrufen und onchange-Attributen. Bewerten Sie, ob eines davon durch Timer oder Systemereignisse statt durch explizite Nutzeraktionen ausgelöst wird.
Auf automatisch weiterlaufende Karussells und Slider prüfen: Identifizieren Sie alle Karussells, Diashows oder rotierenden Banner auf der Seite. Überprüfen Sie, ob sie automatisch weiterlaufen. Wenn ja, prüfen Sie, ob sie beim automatischen Weiterlaufen auch Navigation auslösen (z. B. zu neuen Seiten verlinken). Automatisch weiterlaufende Karussells, die nur sichtbare Inhalte ändern, fallen möglicherweise unter 2.2.2, aber wenn sie auch Navigation verursachen, fallen sie unter 3.2.5.

Wie man es behebt

Meta-Refresh-Redirect – Falsch

<!-- This meta tag automatically redirects the user after 5 seconds.
     The user has no control over this navigation. -->
<head>
  <meta http-equiv='refresh' content='5; url=https://example.com/new-page'>
</head>
<body>
  <p>You will be redirected shortly...</p>
</body>

Meta-Refresh-Redirect – Richtig

<!-- Remove the automatic redirect entirely.
     Provide an explicit link that the user can activate on their own terms.
     This gives users full control over when navigation occurs. -->
<head>
  <!-- No meta refresh tag -->
</head>
<body>
  <p>This page has moved. Please visit the new location:</p>
  <a href='https://example.com/new-page'>Go to the updated page</a>
</body>

Select-Element, das bei Änderung automatisch navigiert – Falsch

<!-- The onchange handler immediately navigates when the user selects a value.
     Keyboard users have no chance to review their selection before navigation. -->
<label for='category'>Choose a category:</label>
<select id='category' onchange='window.location.href = this.value'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>

Select-Element, das bei Änderung automatisch navigiert – Richtig

<!-- The select element no longer triggers navigation on change.
     A clearly labeled button gives the user explicit control over when to proceed.
     This pattern works for all users, including keyboard and screen reader users. -->
<label for='category'>Choose a category:</label>
<select id='category'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>
<button type='button' onclick='navigateToCategory()'>Go to category</button>

<script>
function navigateToCategory() {
  var select = document.getElementById('category');
  if (select.value) {
    window.location.href = select.value;
  }
}
</script>

Automatisch weiterlaufendes Karussell, das Navigation auslöst – Falsch

<!-- This carousel auto-advances every 3 seconds and each slide links to a new page.
     When the slide changes automatically, clicking anywhere on it navigates unexpectedly. -->
<div id='carousel'>
  <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale'></a>
</div>
<script>
var slides = ['/promo/summer', '/promo/winter', '/promo/spring'];
var current = 0;
setInterval(function() {
  current = (current + 1) % slides.length;
  document.querySelector('#carousel a').href = slides[current];
}, 3000);
</script>

Automatisch weiterlaufendes Karussell, das Navigation auslöst – Richtig

<!-- The carousel no longer auto-advances.
     Navigation between slides and to destination pages is entirely user-controlled.
     Pause and next/previous controls satisfy both 2.2.2 and 3.2.5. -->
<div id='carousel' aria-roledescription='carousel' aria-label='Featured promotions'>
  <div role='group' aria-roledescription='slide' aria-label='1 of 3'>
    <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale — Shop now'></a>
  </div>
</div>
<div>
  <button type='button' aria-label='Previous slide' onclick='prevSlide()'>‹</button>
  <button type='button' aria-label='Next slide' onclick='nextSlide()'>›</button>
</div>

Häufige Fehler

Verwendung von onchange auf <select>-Elementen, um sofort window.location.href-Navigation auszulösen, ohne eine separate Absende-Schaltfläche bereitzustellen, wodurch Tastaturnutzer zu einer sofortigen Seitenänderung gezwungen werden, bevor sie ihre Auswahl bestätigen können.
Implementierung von <meta http-equiv='refresh' content='30; url=...'> für Session-Timeout-Handling, ohne den Nutzern einen Mechanismus zu geben, ihre Sitzung zu verlängern oder den automatischen Redirect zu deaktivieren, bevor er ausgelöst wird.
Verwendung von setTimeout oder setInterval zum Aufruf von location.replace() oder history.pushState() für „Komfort“-Funktionen wie automatisches Speichern mit URL-Aktualisierungen, was Nutzer unerwartet in neue Browser-Historienstände versetzt.
Öffnen neuer Browserfenster oder -tabs mit window.open(), ausgelöst durch einen Timer oder einen automatisierten Prozess statt durch eine Nutzeraktion wie einen Klick oder Tastendruck, was von vielen Browsern als Popup blockiert werden kann und immer eine unaufgeforderte Kontextänderung darstellt.
Automatisches Absenden eines Such- oder Filterformulars mit form.submit() innerhalb einer debounce-Funktion, die durch oninput auf einem Textfeld ausgelöst wird – selbst mit Verzögerung – ohne eine sichtbare Absende-Schaltfläche als alternative Steuerungsmöglichkeit bereitzustellen.
Bereitstellung einer „Auto-Advance ausschalten“-Steuerung, die erst erscheint, nachdem die erste automatische Navigation bereits stattgefunden hat, statt vorher. Der Opt-out-Mechanismus muss den Nutzern zur Verfügung stehen, bevor die erste Kontextänderung eintritt.
Verwechslung von Inhaltsaktualisierungen mit Kontextänderungen: Live-Regionen, die Text an Ort und Stelle aktualisieren (z. B. ein Börsenticker), sind keine Kontextänderungen und zulässig, aber das automatische Ersetzen der gesamten sichtbaren Seite oder die Navigation zu einer neuen URL ist eine Kontextänderung und fällt unter dieses Kriterium.
Die Annahme, dass eine Warnmeldung vor einer automatischen Navigation das Kriterium erfüllt, wenn der Dialog selbst automatisch ausgelöst wird und den Tastaturfokus einfängt. Der Nutzer muss das Verhalten deaktivieren können, nicht nur davor gewarnt werden.
Verwendung von onblur- oder onfocusout-Event-Handlern, um Formularvalidierung und automatische Weiterleitung zu einer Fehlerseite oder einem anderen Schritt in einem mehrstufigen Formular auszulösen, ohne dass der Nutzer ausdrücklich darum gebeten hat, fortzufahren.
Einsatz von Single-Page-Application-(SPA)-Routing, das history.pushState basierend auf Scrolltiefe oder verbrachter Zeit aktualisiert – ein Muster, das manchmal für Analysen verwendet wird – was eine nicht initiierte Kontextänderung darstellt und Screenreader-Nutzer verwirren kann, deren virtueller Puffer an den URL-Zustand gebunden ist.

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 fest, die sich an WCAG 2.2 für eine breite Palette von in der Türkei tätigen Einrichtungen orientieren. Die Verfügung umfasst öffentliche Institutionen und Behörden, E-Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind.

Die Verfügung schreibt die Einhaltung von WCAG 2.2 Stufe AA als Mindeststandard für die erfassten Einrichtungen vor. WCAG 3.2.5 Change on Request ist ein Kriterium der Stufe AAA und wird daher nicht direkt durch die minimale gesetzliche Schwelle der Verfügung gefordert. Das bedeutet jedoch nicht, dass es im türkischen Kontext als irrelevant abgetan werden sollte.

Mehrere Kategorien der erfassten Einrichtungen haben starke praktische Gründe, eine AAA-Konformität mit 3.2.5 anzustreben. E-Commerce-Plattformen und Reisebüros mit großen Nutzerbasen implementieren häufig dynamische Filter, Auto-Suggest-Navigation und Werbekarussells – genau die Muster, die dieses Kriterium am ehesten verletzen. Banken und Finanzdienstleister, die sensible Transaktionen abwickeln, bei denen unerwartete Navigation zu Fehlern oder Sicherheitsbedenken führen kann, profitieren erheblich davon, sicherzustellen, dass alle Kontextänderungen ausdrücklich nutzergesteuert sind. Gesundheitsportale, deren Nutzer sich in vulnerablen Situationen befinden können und vorhersehbare, ruhige Oberflächen benötigen, stellen eine weitere Kategorie dar, in der das Überschreiten der AA-Basis mit AAA-Kriterien wie 3.2.5 sowohl ein ethisches Engagement als auch praktische Nutzersicherheit demonstriert.

Öffentliche Institutionen, die unter die Prüf- und Berichtspflichten der Verfügung fallen, sollten ihren Konformitätsgrad dokumentieren. Auch wenn Stufe AAA nicht gesetzlich vorgeschrieben ist, bietet ihre Erreichung – und Dokumentation – einen belastbaren Nachweis eines erstklassigen Engagements für Barrierefreiheit. Für Einrichtungen, die Menschen mit Behinderungen als primäre oder bedeutende Zielgruppe bedienen, wie die Sozialversicherungsbehörde (SGK) oder Dienste zur Unterstützung von Menschen mit Behinderungen, ist das Anstreben der Stufe AAA besonders im Einklang mit dem Geist der Regelung.

Organisationen, die WCAG 3.2.5 freiwillig erfüllen, positionieren sich auch im Kontext der Angleichung an die Barrierefreiheitsanforderungen der Europäischen Union vorteilhaft, da die digitalen Handelsbeziehungen der Türkei mit EU-Mitgliedstaaten zunehmend Barrierefreiheit als Kriterium für Beschaffung und Partnerschaften einbeziehen. Der European Accessibility Act (EAA), der im Juni 2025 in Kraft trat, gilt für Produkte und Dienstleistungen, die auf EU-Märkten angeboten werden – einschließlich solcher, die von türkischen Unternehmen für europäische Nutzer bereitgestellt werden – und fördert nachdrücklich nutzergesteuerte Interaktionsmuster, die mit 3.2.5 übereinstimmen.

Praktisch gesehen sollten türkische Entwicklungsteams, die das Overlay-SDK von Accsible implementieren, sicherstellen, dass dynamisch eingebettete Widgets, Einstellungsbereiche oder unterstützende Steuerelemente selbst keine nicht initiierten Kontextänderungen einführen. Die Toolbar und das Einstellungsfenster des SDK dürfen sich nur als Reaktion auf explizite Nutzeraktionen öffnen und schließen, und jede Navigation oder Inhaltsaktualisierung, die über das Overlay ausgelöst wird, muss vom Nutzer initiiert sein. So wird sichergestellt, dass die Barrierefreiheitslösung selbst nicht genau die Barrieren erzeugt, die sie beseitigen soll.