WCAG 3.2.5: Wijziging op verzoek

Wat Deze Regel Betekent

WCAG 3.2.5 Change on Request is een criterium op niveau AAA onder het principe Begrijpelijk. Het stelt dat contextwijzigingen uitsluitend door de gebruiker mogen worden geïnitieerd en niet automatisch door het systeem mogen worden getriggerd. Een "contextwijziging" wordt in WCAG gedefinieerd als een grote wijziging in de inhoud van de webpagina die, zonder dat de gebruiker zich daarvan bewust is, gebruikers kan desoriënteren die niet de hele pagina in één keer kunnen overzien. Dit omvat wijzigingen aan de user agent (browser), viewport, focus of inhoud die de betekenis van de pagina aanzienlijk verandert.

Specifiek verbiedt het criterium elk mechanisme dat een contextwijziging veroorzaakt zonder een expliciet verzoek van de gebruiker. Dit breidt de vereisten van 3.2.1 (On Focus) en 3.2.2 (On Input) uit door alle resterende scenario’s aan te pakken waarin automatische contextwijzigingen kunnen optreden — waaronder maar niet beperkt tot: automatisch verversende pagina’s, carrousels die automatisch verder gaan en weg navigeren, meta-redirecttags met korte vertragingen, door JavaScript getriggerde navigatie bij het voltooien van een formulierveld, en het openen van nieuwe vensters of tabbladen zonder initiatief van de gebruiker.

Om aan dit criterium te voldoen, is één van twee voorwaarden vereist: ofwel contextwijzigingen worden alleen getriggerd door expliciete, bewuste acties van de gebruiker (zoals het activeren van een knop of link), of er wordt een mechanisme geboden waarmee de gebruiker automatische contextwijzigingen kan uitschakelen voordat ze plaatsvinden. Als een pagina bijvoorbeeld elke 30 seconden automatisch ververst en naar nieuwe inhoud navigeert, voldoet deze niet — tenzij er een duidelijk gelabelde bediening bestaat om dat gedrag uit te schakelen voordat de eerste verversing plaatsvindt. Alleen achteraf een waarschuwing geven is niet voldoende.

Het criterium is breed van toepassing op alle interactieve en dynamische webinhoud. Veelvoorkomende getroffen elementen en gedragingen zijn onder andere: <meta http-equiv='refresh'>-redirects, JavaScript-aanroepen van window.location of history.pushState die door timers worden getriggerd, onchange-eventhandlers op <select>-elementen die naar een nieuwe URL navigeren, automatisch verzendende formulieren, door focus getriggerde navigatie, en elke widget die automatisch scrollt, dia’s verder zet of de zichtbare inhoudsset wijzigt zonder invoer van de gebruiker.

Een belangrijke officiële uitzondering: als de contextwijziging een reactie is op een instelling die de gebruiker expliciet en bewust heeft geconfigureerd — bijvoorbeeld een gebruikersvoorkeurenpaneel waarin de gebruiker "elke minuut automatisch verversen" selecteert — is het automatische gedrag toegestaan omdat de gebruiker erom heeft gevraagd. Het belangrijkste onderscheid is of de gebruiker een geïnformeerde, bewuste keuze heeft gemaakt om het automatische gedrag in te schakelen, versus het onverwacht tegenkomen ervan.

Waarom Het Belangrijk Is

Onverwachte contextwijzigingen behoren tot de meest desoriënterende ervaringen op het web, en hun impact verschilt aanzienlijk tussen verschillende groepen gebruikers met een beperking.

Voor blinde gebruikers die afhankelijk zijn van schermlezers kan een plotselinge paginanavigatie of inhoudsverversing ervoor zorgen dat de leescursor naar een volledig andere positie op de pagina springt — of terug naar boven — zonder enige aankondiging. Als een gebruiker midden in een zin in een lang artikel zit en de pagina automatisch wordt doorgestuurd naar een nieuwe URL, verliest die persoon volledig zijn of haar plek en begrijpt mogelijk niet wat er is gebeurd of hoe dit te herstellen. Schermlezers zoals NVDA, JAWS en VoiceOver kondigen navigatie op paginaniveau niet altijd op een consistente of tijdige manier aan, waardoor gebruikers in verwarring kunnen raken over waar ze zijn en wat er is veranderd.

Voor gebruikers met motorische beperkingen die navigeren met het toetsenbord, een hoofdaanwijzer, een schakelapparaat of oogvolgtechnologie, kunnen onverwachte focuswijzigingen rampzalig zijn. Als de focus programmatisch wordt verplaatst zonder actie van de gebruiker — bijvoorbeeld wanneer een formulier automatisch naar het volgende veld gaat zodra het vorige is ingevuld — kan de gebruiker zijn of haar positie kwijtraken en gedwongen worden moeizaam opnieuw te navigeren om te vinden waar het systeem hem of haar naartoe heeft gebracht. Voor gebruikers van wie de invoerapparaten aanzienlijke fysieke inspanning per toetsaanslag vereisen, vormt deze hernavigatie een echte toegankelijkheidsbarrière.

Gebruikers met cognitieve beperkingen, waaronder mensen met aandachtsstoornissen, geheugenproblemen of angststoornissen, zijn bijzonder kwetsbaar voor onverwachte veranderingen. Automatische pagina­wijzigingen doorbreken hun mentaal model van de interface. Een gebruiker die pauzeert om instructies te lezen en vervolgens merkt dat de pagina is herladen, zal zich waarschijnlijk verward of van streek voelen. Deze verstoring kan het onmogelijk maken om transacties te voltooien of zelfstandig informatie te consumeren.

Voor gebruikers met vestibulaire stoornissen kunnen snelle en onverwachte visuele veranderingen — zoals een automatisch verdergaande carrousel die ook navigatie triggert — fysieke symptomen veroorzaken, waaronder duizeligheid en misselijkheid. Zelfs ziende gebruikers zonder gediagnosticeerde beperking profiteren van voorspelbare interfaces: onderzoek toont consequent aan dat onverwachte navigaties de foutpercentages en het afbreken van taken verhogen bij alle gebruikersgroepen.

Een concreet scenario uit de praktijk: een Turkse e-commercesite verzendt een productfilterformulier automatisch zodra een gebruiker een waarde in een dropdown selecteert — en navigeert naar een nieuwe URL met zoekresultaten. Een gebruiker die uitsluitend het toetsenbord gebruikt en door de filters tabt om meerdere criteria te selecteren, merkt dat het selecteren van de eerste optie de pagina onmiddellijk herlaadt en het filterpaneel inklapt. Die persoon moet het paneel opnieuw openen, opnieuw naar de beginpositie navigeren en het opnieuw proberen — mogelijk in een lus die de functie volledig onbruikbaar maakt. Volgens de Wereldgezondheidsorganisatie leven wereldwijd ongeveer 1,3 miljard mensen met een of andere vorm van beperking, en patronen als deze sluiten hen in onevenredige mate uit van digitale diensten.

Vanuit gebruiksvriendelijkheid en SEO-perspectief hebben pagina’s die automatisch doorsturen of automatisch verversen ook de neiging hogere bouncepercentages te hebben, omdat gebruikers die onverwacht gedrag tegenkomen vaak weggaan. Zoekmachines kunnen ook onverwachte redirects bestraffen die verschillen tussen crawler- en gebruikerssessies, waardoor naleving van 3.2.5 in lijn is met goede technische SEO-hygiëne.

Gerelateerde Axe-core-regels

WCAG 3.2.5 vereist handmatige tests omdat geautomatiseerde tools niet betrouwbaar kunnen detecteren of een contextwijziging door de gebruiker is geïnitieerd of automatisch is getriggerd. Het onderscheid hangt af van het begrijpen van gebruikersintentie en interactiestroom, wat menselijke beoordeling vereist. Er is geen axe-core-regel die direct overeenkomt met de volledige reikwijdte van dit criterium. De volgende overwegingen zijn echter van toepassing op geautomatiseerde en semi-geautomatiseerde tests:

• Geen directe axe-core-regel (handmatige test vereist): Axe-core en Lighthouse kunnen door JavaScript getriggerde navigaties, automatisch verversende pagina’s of automatisch verzendende formulieren niet detecteren, omdat dit gedrag afhangt van runtime-omstandigheden, timing en de interactiestatus van de gebruiker die statische of gescripte scans niet kunnen repliceren. Een scanner die de DOM op één moment observeert, kan niet bepalen of window.location.href wordt ingesteld als reactie op een timer of op een klik van de gebruiker.
• Detectie van meta refresh (gedeeltelijke automatisering mogelijk): Sommige geautomatiseerde tools, waaronder oudere axe-regels en browserextensies, kunnen de aanwezigheid van <meta http-equiv='refresh' content='0; url=...'> in de documenthead signaleren. Axe-core heeft hiervoor echter geen speciale productieregel in versie 4.10. Handmatige inspectie van de paginabron en HTTP-headers is vereist om te verifiëren dat er geen automatische redirect plaatsvindt.
• Analyse van eventlisteners (handmatig): Het detecteren van onchange-handlers op <select>-elementen die navigatie triggeren, vereist een handmatige code-review of het gebruik van ontwikkelaarstools in de browser om gekoppelde eventlisteners te inspecteren. Geautomatiseerde scans observeren de gerenderde DOM maar niet de gedragsmatige gevolgen van interactie met elk element.
• Verificatie van focusbeheer (handmatig): Of de focus onverwacht verplaatst als gevolg van een door het systeem geïnitieerde contextwijziging — in plaats van een gebruikersactie — vereist dat een tester daadwerkelijk met de pagina interageert en het focusgedrag in realtime observeert, met behulp van een toetsenbord en eventueel een schermlezer.

Hoe te Testen

1. Geautomatiseerde scan (basislijn): Voer axe DevTools of Lighthouse uit op de pagina om eventuele gesignaleerde problemen met betrekking tot redirects of focusbeheer te detecteren. Open in Chrome DevTools het Lighthouse-paneel en voer een Accessibility-audit uit. Klik in de axe DevTools-extensie op "Analyze" en bekijk de resultaten. Let op dat een schone geautomatiseerde uitkomst geen bevestiging is van conformiteit met 3.2.5 — handmatige tests zijn essentieel.
2. Inspecteer op meta refresh: Open de pagina in een browser, klik met de rechtermuisknop en selecteer "Paginabron weergeven", en zoek (Ctrl+F / Cmd+F) naar http-equiv of refresh. Elke <meta http-equiv='refresh'>-tag met een URL of met een vertraging van meer dan 72 uur zonder een mechanisme om deze uit te schakelen, vormt een fout.
3. Observeer het gedrag van de pagina in de tijd: Laad de pagina en wacht 2–5 minuten zonder te interageren. Let op automatische inhoudsveranderingen, paginaherladingen, navigatiegebeurtenissen of het openen van nieuwe vensters. Controleer de adresbalk en de tabtitel van de browser op wijzigingen. Als er iets gebeurt zonder jouw input, voldoet de pagina waarschijnlijk niet aan het criterium.
4. Test formulierelementen en dropdowns: Navigeer uitsluitend met het toetsenbord (Tab, pijltjestoetsen, Enter, Spatie) naar elke <select>, radioknopgroep of checkbox. Wijzig waarden en observeer of er onmiddellijk bij selectie — vóórdat je een verzendknop activeert — een navigatie of grote inhoudswijziging optreedt. Als dat zo is, is dit een fout, tenzij er een bediening werd geboden om dit gedrag uit te schakelen voordat je het element bereikte.
5. Test met NVDA + Firefox: Schakel NVDA in (Insert+Spatie voor browse-modus), navigeer door de pagina met pijltjestoetsen en Tab. Voer formulierinteracties uit en let erop of focus of leespositie onverwacht wordt verplaatst. Luister naar aankondigingen van pagina­wijzigingen. Als de schermlezer een nieuwe pagina aankondigt of de virtuele cursor reset zonder jouw expliciete actie, duidt dit op een contextwijziging.
6. Test met VoiceOver + Safari (macOS/iOS): Schakel VoiceOver in (Cmd+F5 op Mac), navigeer met VO+pijltjestoetsen. Interageer met bedieningselementen en luister naar onverwachte pagina-aankondigingen of cursorresets. Veeg op iOS door elementen en let op plotselinge veranderingen in de structuur van de toegankelijkheidsboom die je niet zelf hebt geïnitieerd.
7. Test met JAWS + Chrome: Schakel JAWS in en navigeer met Tab en pijltjestoetsen. Verstuur formulieren en interageer met dynamische widgets. Controleer of focus en positie van de virtuele cursor altijd voorspelbaar blijven en onder jouw controle staan.
8. Bekijk de JavaScript-bron: Gebruik in Chrome DevTools het tabblad Sources of zoek (Ctrl+Shift+F) naar patronen zoals window.location, location.href, history.pushState, setTimeout in combinatie met navigatieaanroepen, en onchange-attributen. Beoordeel of een van deze wordt getriggerd door timers of systeemgebeurtenissen in plaats van expliciete gebruikersacties.
9. Controleer op automatisch verdergaande carrousels en sliders: Identificeer eventuele carrousels, diavoorstellingen of roterende banners op de pagina. Controleer of ze automatisch verder gaan. Als dat zo is, controleer dan of ze ook navigatie triggeren (bijvoorbeeld door naar nieuwe pagina’s te linken) bij automatisch verdergaan. Automatisch verdergaande carrousels die alleen zichtbare inhoud wijzigen, vallen mogelijk onder 2.2.2, maar als ze ook navigatie veroorzaken, vallen ze onder 3.2.5.

Hoe te Herstellen

Meta refresh-redirect — Onjuist

<!-- 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 — Juist

<!-- 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 dat automatisch navigeert bij wijziging — Onjuist

<!-- 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 dat automatisch navigeert bij wijziging — Juist

<!-- 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 verdergaande carrousel die navigatie triggert — Onjuist

<!-- 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 verdergaande carrousel die navigatie triggert — Juist

<!-- 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>

Veelvoorkomende Fouten

• Gebruik van onchange op <select>-elementen om onmiddellijk window.location.href-navigatie te triggeren zonder een aparte verzendknop te bieden, waardoor toetsenbordgebruikers worden gedwongen tot een onmiddellijke pagina­wijziging voordat ze hun selectie kunnen bevestigen.
• Implementatie van <meta http-equiv='refresh' content='30; url=...'> voor sessietime-outafhandeling zonder gebruikers een mechanisme te geven om hun sessie te verlengen of de automatische redirect uit te schakelen voordat deze wordt uitgevoerd.
• Gebruik van setTimeout of setInterval om location.replace() of history.pushState() aan te roepen voor "gemaks"-functies zoals automatisch opslaan met URL-updates, wat gebruikers onverwacht naar nieuwe browsergeschiedenis­staten verplaatst.
• Nieuwe browservensters of tabbladen openen met window.open() dat wordt getriggerd door een timer of een geautomatiseerd proces in plaats van door een gebruikersactie zoals een klik of toetsaanslag, wat door veel browsers als pop-up kan worden geblokkeerd en altijd een ongevraagde contextwijziging vormt.
• Een zoek- of filterformulier automatisch verzenden met form.submit() binnen een debounce-functie die wordt getriggerd door oninput op een tekstveld — zelfs met een vertraging — zonder een zichtbare verzendknop als alternatief bedieningsmechanisme te bieden.
• Een bediening "auto-advance uitschakelen" bieden die pas verschijnt nadat de eerste automatische navigatie al heeft plaatsgevonden, in plaats van ervoor. Het opt-outmechanisme moet beschikbaar zijn voor gebruikers voordat de eerste contextwijziging plaatsvindt.
• Inhoudsupdates verwarren met contextwijzigingen: live-regio’s die tekst ter plekke bijwerken (bijv. een koersticker) zijn geen contextwijzigingen en zijn acceptabel, maar het automatisch vervangen van de volledige zichtbare pagina of het navigeren naar een nieuwe URL is een contextwijziging en valt onder dit criterium.
• Aannemen dat het geven van een waarschuwingsdialoog vóór automatische navigatie aan het criterium voldoet wanneer de dialoog zelf automatisch wordt getriggerd en de toetsenbordfocus vastzet. De gebruiker moet het gedrag kunnen uitschakelen, niet er alleen voor worden gewaarschuwd.
• Gebruik van onblur of onfocusout-eventhandlers om formulier­validatie en automatische redirect te triggeren naar een foutpagina of een andere stap in een meerstappenformulier, zonder dat de gebruiker expliciet heeft verzocht om door te gaan.
• Inzet van single-page application (SPA)-routing die history.pushState bijwerkt op basis van scrolldiepte of bestede tijd op een sectie — een patroon dat soms voor analytics wordt gebruikt — wat een niet-geïnitieerde contextwijziging vormt en schermlezergebruikers kan verwarren van wie de virtuele buffer is gekoppeld aan de URL-status.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidentiële Circulaire 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte webtoegankelijkheidseisen vast die zijn afgestemd op WCAG 2.2 voor een brede reeks entiteiten die in Turkije actief zijn. De circulaire heeft betrekking op overheidsinstellingen en -agentschappen, e-commerceplatforms, banken en financiële instellingen, ziekenhuizen en zorgaanbieders, telecombedrijven met 200,000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE).

De circulaire schrijft naleving van WCAG 2.2 niveau AA voor als de basisnorm voor de betrokken entiteiten. WCAG 3.2.5 Change on Request is een criterium op niveau AAA en is daarom niet direct vereist onder de minimale wettelijke drempel van de circulaire. Dit betekent echter niet dat het in de Turkse context als irrelevant kan worden afgedaan.

Verschillende categorieën van betrokken entiteiten hebben sterke praktische redenen om AAA-conformiteit met 3.2.5 na te streven. E-commerceplatforms en reisbureaus met grote gebruikersbases implementeren vaak dynamische filtering, auto-suggestnavigatie en promotionele carrousels — precies de patronen die het meest waarschijnlijk in strijd zijn met dit criterium. Banken en financiële dienstverleners, die gevoelige transacties afhandelen waarbij onverwachte navigatie fouten of beveiligingsproblemen kan veroorzaken, profiteren aanzienlijk van het waarborgen dat alle contextwijzigingen expliciet door de gebruiker worden gecontroleerd. Zorgportalen, waar gebruikers zich in een kwetsbare toestand kunnen bevinden en behoefte hebben aan voorspelbare, rustige interfaces, vormen een andere categorie waarin het overschrijden van de AA-basislijn met AAA-criteria zoals 3.2.5 zowel een ethische inzet als praktische gebruikersveiligheid aantoont.

Overheidsinstellingen die onderworpen zijn aan audit- en rapportageverplichtingen op grond van de circulaire, moeten hun conformiteitsniveau documenteren. Hoewel niveau AAA niet wettelijk verplicht is, biedt het bereiken — en documenteren — ervan een verdedigbaar bewijs van een toonaangevende inzet voor toegankelijkheid. Voor entiteiten die mensen met een beperking als primaire of belangrijke doelgroep bedienen, zoals de sociale zekerheidsinstantie (SGK) of diensten voor ondersteuning bij een beperking, is het nastreven van niveau AAA-conformiteit in het bijzonder in lijn met de geest van de regelgeving.

Organisaties die vrijwillig voldoen aan WCAG 3.2.5 positioneren zich ook gunstig in de context van afstemming op de toegankelijkheid van de Europese Unie, aangezien de digitale handelsrelaties van Turkije met EU-lidstaten in toenemende mate toegankelijkheid omvatten als inkoop- en partnercriterium. De European Accessibility Act (EAA), die in juni 2025 in werking is getreden, is van toepassing op producten en diensten die op EU-markten worden aangeboden — inclusief die welke door Turkse bedrijven aan Europese gebruikers worden geleverd — en moedigt sterk gebruikersgestuurde interactiepatronen aan die in lijn zijn met 3.2.5.

In praktische termen moeten Turkse ontwikkelingsteams die de overlay-SDK van Accsible implementeren ervoor zorgen dat dynamisch geïnjecteerde widgets, voorkeurenpanelen of ondersteunende bedieningen zelf geen niet-geïnitieerde contextwijzigingen introduceren. De toolbar en het instellingenpaneel van de SDK mogen alleen openen en sluiten als reactie op expliciete gebruikersacties, en elke navigatie of inhoudsupdate die via de overlay wordt getriggerd, moet door de gebruiker worden geïnitieerd. Dit zorgt ervoor dat de toegankelijkheidsoplossing zelf niet de barrières creëert die zij juist moet wegnemen.