WCAG 3.2.5: Modifica su richiesta

Cosa Significa Questa Regola

WCAG 3.2.5 Change on Request è un criterio di livello AAA sotto il principio Comprensibile. Stabilisce che i cambiamenti di contesto devono essere avviati solo dall’utente, non attivati automaticamente dal sistema. Un “cambiamento di contesto” è definito nelle WCAG come un cambiamento importante nel contenuto della pagina web che, senza la consapevolezza dell’utente, può disorientare gli utenti che non sono in grado di visualizzare l’intera pagina in una volta sola. Questo include cambiamenti all’agente utente (browser), al viewport, al focus o al contenuto che alterano in modo significativo il significato della pagina.

Nello specifico, il criterio vieta qualsiasi meccanismo che provochi un cambiamento di contesto senza una richiesta esplicita dell’utente. Questo estende i requisiti di 3.2.1 (On Focus) e 3.2.2 (On Input) affrontando tutti gli scenari rimanenti in cui potrebbero verificarsi cambiamenti di contesto automatici — inclusi, ma non solo: pagine che si aggiornano automaticamente, caroselli che avanzano automaticamente e portano altrove, meta tag di redirect con brevi ritardi, navigazione attivata da JavaScript al completamento di un campo di un modulo e apertura di nuove finestre o schede senza iniziativa dell’utente.

Per superare questo criterio sono necessarie una delle due condizioni: o i cambiamenti di contesto sono attivati solo da un’azione esplicita e deliberata dell’utente (come l’attivazione di un pulsante o di un link), oppure viene fornito un meccanismo che consente all’utente di disattivare i cambiamenti di contesto automatici prima che si verifichino. Ad esempio, se una pagina si aggiorna automaticamente ogni 30 secondi e naviga verso nuovi contenuti, non è conforme — a meno che non esista un controllo chiaramente etichettato per disabilitare tale comportamento prima che avvenga il primo aggiornamento. Limitarsi a fornire un avviso dopo il fatto non è sufficiente.

Il criterio si applica in modo ampio a tutti i contenuti web interattivi e dinamici. Elementi e comportamenti comunemente interessati includono: redirect tramite <meta http-equiv='refresh'>, chiamate JavaScript a window.location o history.pushState attivate da timer, gestori di eventi onchange su elementi <select> che navigano verso un nuovo URL, moduli inviati automaticamente, navigazione attivata dal focus e qualsiasi widget che scorra automaticamente, avanzi le slide o cambi l’insieme di contenuti visibili senza input dell’utente.

Un’importante eccezione ufficiale: se il cambiamento di contesto è in risposta a un’impostazione che l’utente ha configurato in modo esplicito e consapevole — ad esempio, un pannello delle preferenze in cui l’utente seleziona “aggiorna automaticamente ogni minuto” — il comportamento automatico è consentito perché è stato richiesto dall’utente. La distinzione chiave è se l’utente ha compiuto una scelta informata e deliberata per abilitare il comportamento automatico, rispetto a incontrarlo inaspettatamente.

Perché È Importante

I cambiamenti di contesto inaspettati sono tra le esperienze più disorientanti sul web, e il loro impatto varia in modo significativo tra i diversi gruppi di utenti con disabilità.

Per le persone cieche che si affidano ai lettori di schermo, una navigazione improvvisa della pagina o un aggiornamento del contenuto può far sì che il cursore di lettura salti in una posizione completamente diversa della pagina — o si reimposti all’inizio — senza alcun annuncio. Se un utente è a metà frase in un articolo lungo e la pagina viene reindirizzata automaticamente a un nuovo URL, perde completamente il punto in cui si trovava e potrebbe non capire cosa sia successo o come riprendere. Lettori di schermo come NVDA, JAWS e VoiceOver non annunciano sempre gli eventi di navigazione a livello di pagina in modo coerente o tempestivo, quindi gli utenti possono essere confusi su dove si trovano e cosa è cambiato.

Per gli utenti con disabilità motorie che navigano tramite tastiera, puntatore a testa, dispositivo a sensore o tecnologia di eye-tracking, i cambiamenti di focus inaspettati possono essere catastrofici. Se il focus viene spostato in modo programmato senza azione dell’utente — ad esempio, quando un modulo avanza automaticamente al campo successivo al completamento del precedente — l’utente può perdere il senso della propria posizione ed essere costretto a ri-navigare faticosamente per trovare dove il sistema lo ha portato. Per gli utenti i cui dispositivi di input richiedono un notevole sforzo fisico per ogni pressione di tasto, questa ri-navigazione rappresenta una vera barriera di accessibilità.

Gli utenti con disabilità cognitive, inclusi quelli con disturbi dell’attenzione, deficit di memoria o condizioni d’ansia, sono particolarmente vulnerabili ai cambiamenti inaspettati. I cambiamenti automatici della pagina interrompono il loro modello mentale dell’interfaccia. Un utente che si ferma a leggere le istruzioni e poi scopre che la pagina è stata ricaricata probabilmente si sentirà confuso o turbato. Questa interruzione può rendere impossibile completare transazioni o fruire di informazioni in modo indipendente.

Per gli utenti con disturbi vestibolari, cambiamenti visivi rapidi e inaspettati — come un carosello che avanza automaticamente e che attiva anche la navigazione — possono causare sintomi fisici tra cui vertigini e nausea. Anche gli utenti vedenti senza disabilità diagnosticate traggono beneficio da interfacce prevedibili: le ricerche mostrano costantemente che le navigazioni inaspettate aumentano i tassi di errore e di abbandono dei compiti in tutti i gruppi di utenti.

Uno scenario concreto nel mondo reale: un sito di e-commerce turco invia automaticamente un modulo di filtro prodotto nel momento in cui un utente seleziona un valore in un menu a discesa — navigando verso un nuovo URL di risultati di ricerca. Un utente che utilizza solo la tastiera e che si sposta con il tasto Tab tra i filtri per selezionare più criteri scopre che la selezione della prima opzione ricarica immediatamente la pagina e comprime il pannello dei filtri. Deve riaprire il pannello, ri-navigare fino alla posizione di partenza e riprovare — potenzialmente in un loop che rende la funzionalità del tutto inutilizzabile. Secondo l’Organizzazione Mondiale della Sanità, circa 1,3 miliardi di persone nel mondo vivono con qualche forma di disabilità, e schemi come questo le escludono in modo sproporzionato dai servizi digitali.

Da una prospettiva di usabilità e SEO, le pagine che reindirizzano o si aggiornano automaticamente tendono anche ad avere tassi di rimbalzo più elevati, poiché gli utenti che incontrano comportamenti inaspettati spesso abbandonano. I motori di ricerca possono anche penalizzare i redirect inaspettati che differiscono tra le sessioni del crawler e quelle dell’utente, rendendo la conformità con 3.2.5 allineata a una buona igiene di SEO tecnica.

Regole Axe-core Correlate

WCAG 3.2.5 richiede test manuali perché gli strumenti automatici non possono rilevare in modo affidabile se un cambiamento di contesto è stato avviato dall’utente o attivato automaticamente. La distinzione dipende dalla comprensione dell’intento dell’utente e del flusso di interazione, che richiede giudizio umano. Nessuna regola di axe-core mappa direttamente all’intera portata di questo criterio. Tuttavia, le seguenti considerazioni si applicano ai test automatici e semi-automatici:

• Nessuna regola axe-core diretta (test manuale richiesto): Axe-core e Lighthouse non possono rilevare navigazioni attivate da JavaScript, pagine che si aggiornano automaticamente o moduli inviati automaticamente perché questi comportamenti dipendono da condizioni di runtime, tempistiche e stato di interazione dell’utente che le scansioni statiche o scriptate non possono replicare. Uno scanner che osserva il DOM in un singolo momento non può determinare se window.location.href viene impostato in risposta a un timer o a un clic dell’utente.
• Rilevamento dei meta refresh (automazione parziale possibile): Alcuni strumenti automatici, incluse vecchie regole di axe e estensioni del browser, possono segnalare la presenza di <meta http-equiv='refresh' content='0; url=...'> nell’head del documento. Tuttavia, axe-core non ha una regola di produzione dedicata per questo nella versione 4.10. È necessaria un’ispezione manuale del sorgente della pagina e degli header HTTP per verificare che non si verifichi alcun redirect automatico.
• Analisi dei listener di eventi (manuale): Rilevare gestori onchange su elementi <select> che attivano la navigazione richiede una revisione manuale del codice o l’uso degli strumenti di sviluppo del browser per ispezionare i listener di eventi associati. Le scansioni automatiche osservano il DOM renderizzato ma non le conseguenze comportamentali dell’interazione con ciascun elemento.
• Verifica della gestione del focus (manuale): Stabilire se il focus si sposta inaspettatamente a seguito di un cambiamento di contesto avviato dal sistema — piuttosto che da un’azione dell’utente — richiede che un tester interagisca effettivamente con la pagina e osservi il comportamento del focus in tempo reale, usando una tastiera e, facoltativamente, un lettore di schermo.

Come Testare

1. Scansione automatica (baseline): Esegui axe DevTools o Lighthouse sulla pagina per rilevare eventuali problemi segnalati relativi a redirect o gestione del focus. In Chrome DevTools, apri il pannello Lighthouse ed esegui un audit di Accessibilità. Nell’estensione axe DevTools, fai clic su “Analyze” e rivedi i risultati. Nota che un risultato automatico pulito non conferma la conformità con 3.2.5 — il test manuale è essenziale.
2. Ispeziona la presenza di meta refresh: Apri la pagina in un browser, fai clic con il tasto destro e seleziona “View Page Source”, quindi cerca (Ctrl+F / Cmd+F) http-equiv o refresh. Qualsiasi tag <meta http-equiv='refresh'> con un URL o con un ritardo superiore a 72 ore senza un meccanismo per disabilitarlo costituisce un errore.
3. Osserva il comportamento della pagina nel tempo: Carica la pagina e attendi senza interagire per 2–5 minuti. Osserva eventuali cambiamenti automatici del contenuto, ricaricamenti della pagina, eventi di navigazione o apertura di nuove finestre. Controlla la barra degli indirizzi e il titolo della scheda per eventuali cambiamenti. Se qualcosa accade senza il tuo input, il criterio probabilmente non è rispettato.
4. Testa i controlli dei moduli e i menu a discesa: Usando solo la tastiera (Tab, tasti freccia, Invio, Spazio), naviga verso ciascun elemento <select>, gruppo di pulsanti di opzione o casella di controllo. Cambia i valori e osserva se una navigazione o un cambiamento importante del contenuto si verifica immediatamente alla selezione — prima che tu attivi un pulsante di invio. Se ciò accade, si tratta di un errore a meno che non sia stato fornito un controllo per disabilitare questo comportamento prima che tu raggiungessi l’elemento.
5. Test con NVDA + Firefox: Abilita NVDA (Insert+Space per la modalità browse), naviga nella pagina usando i tasti freccia e Tab. Completa le interazioni con i moduli e nota se il focus o la posizione di lettura vengono spostati inaspettatamente. Ascolta gli annunci dei cambiamenti di pagina. Se il lettore di schermo annuncia una nuova pagina o il cursore virtuale si reimposta senza una tua azione esplicita, questo indica un cambiamento di contesto.
6. Test con VoiceOver + Safari (macOS/iOS): Abilita VoiceOver (Cmd+F5 su Mac), naviga usando VO+freccia. Interagisci con i controlli e ascolta eventuali annunci di pagina inaspettati o reimpostazioni del cursore. Su iOS, scorri tra gli elementi e nota eventuali cambiamenti improvvisi nella struttura dell’albero di accessibilità che non hai avviato.
7. Test con JAWS + Chrome: Abilita JAWS e naviga con i tasti Tab e freccia. Invia moduli e interagisci con widget dinamici. Verifica che il focus e la posizione del cursore virtuale rimangano prevedibili e sempre sotto il tuo controllo.
8. Rivedi il sorgente JavaScript: In Chrome DevTools, usa il pannello Sources o la ricerca (Ctrl+Shift+F) per pattern come window.location, location.href, history.pushState, setTimeout combinato con chiamate di navigazione e attributi onchange. Valuta se qualcuno di questi è attivato da timer o eventi di sistema piuttosto che da azioni esplicite dell’utente.
9. Verifica la presenza di caroselli e slider che avanzano automaticamente: Identifica eventuali caroselli, slideshow o banner rotanti sulla pagina. Verifica se avanzano automaticamente. Se lo fanno, controlla se attivano anche la navigazione (ad esempio, collegandosi a nuove pagine) al momento dell’avanzamento automatico. I caroselli che avanzano automaticamente e che cambiano solo il contenuto visibile possono rientrare nel criterio 2.2.2, ma se causano anche la navigazione rientrano nel 3.2.5.

Come Correggere

Redirect tramite meta refresh — Non corretto

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

Redirect tramite meta refresh — Corretto

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

Elemento select che naviga automaticamente al cambio — Non corretto

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

Elemento select che naviga automaticamente al cambio — Corretto

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

Carosello che avanza automaticamente e che attiva la navigazione — Non corretto

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

Carosello che avanza automaticamente e che attiva la navigazione — Corretto

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

Errori Comuni

• Usare onchange su elementi <select> per attivare immediatamente la navigazione con window.location.href senza fornire un pulsante di invio separato, costringendo gli utenti da tastiera a un cambiamento di pagina immediato prima che possano confermare la loro selezione.
• Implementare <meta http-equiv='refresh' content='30; url=...'> per la gestione del timeout di sessione senza dare agli utenti un meccanismo per estendere la sessione o disabilitare il redirect automatico prima che venga eseguito.
• Usare setTimeout o setInterval per chiamare location.replace() o history.pushState() per funzionalità di “comodità” come il salvataggio automatico con aggiornamenti dell’URL, che spostano inaspettatamente gli utenti in nuovi stati della cronologia del browser.
• Aprire nuove finestre o schede del browser usando window.open() attivato da un timer o da un processo automatizzato piuttosto che da un gesto dell’utente come un clic o una pressione di tasto, cosa che molti browser possono bloccare come popup e che costituisce sempre un cambiamento di contesto non richiesto.
• Inviare automaticamente un modulo di ricerca o filtro usando form.submit() all’interno di una funzione di debounce attivata da oninput su un campo di testo — anche con un ritardo — senza fornire un pulsante di invio visibile come meccanismo di controllo alternativo.
• Fornire un controllo “disattiva avanzamento automatico” che appare solo dopo che la prima navigazione automatica è già avvenuta, anziché prima. Il meccanismo di opt-out deve essere disponibile per gli utenti prima che avvenga il primo cambiamento di contesto.
• Confondere gli aggiornamenti di contenuto con i cambiamenti di contesto: le live region che aggiornano il testo in loco (ad esempio, un ticker azionario) non sono cambiamenti di contesto e sono accettabili, ma la sostituzione automatica dell’intera pagina visibile o la navigazione verso un nuovo URL è un cambiamento di contesto e rientra in questo criterio.
• Supporre che fornire una finestra di dialogo di avviso prima della navigazione automatica soddisfi il criterio quando la finestra di dialogo stessa è attivata automaticamente e intrappola il focus della tastiera. L’utente deve poter disabilitare il comportamento, non solo esserne avvisato.
• Usare gestori di eventi onblur o onfocusout per attivare la convalida del modulo e il redirect automatico a una pagina di errore o a una fase diversa in un modulo multi-step, senza che l’utente richieda esplicitamente di procedere.
• Distribuire routing di single-page application (SPA) che aggiorna history.pushState in base alla profondità di scroll o al tempo trascorso su una sezione — uno schema talvolta usato per l’analisi — che costituisce un cambiamento di contesto non avviato e può confondere gli utenti di lettori di schermo il cui buffer virtuale è legato allo stato dell’URL.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce requisiti obbligatori di accessibilità web allineati a WCAG 2.2 per un’ampia gamma di entità che operano in Turchia. La circolare copre istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari, società di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio, società di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE).

La circolare impone la conformità a WCAG 2.2 Livello AA come standard di base per le entità coperte. WCAG 3.2.5 Change on Request è un criterio di livello AAA e pertanto non è direttamente richiesto dalla soglia legale minima della circolare. Tuttavia, ciò non significa che debba essere considerato irrilevante nel contesto turco.

Diverse categorie di entità coperte hanno forti motivazioni pratiche per perseguire la conformità AAA con 3.2.5. Le piattaforme di e-commerce e le agenzie di viaggio con grandi basi di utenti spesso implementano filtri dinamici, navigazione con suggerimenti automatici e caroselli promozionali — precisamente gli schemi più suscettibili di violare questo criterio. Banche e fornitori di servizi finanziari, che gestiscono transazioni sensibili in cui la navigazione inaspettata può causare errori o problemi di sicurezza, traggono un beneficio sostanziale dall’assicurare che tutti i cambiamenti di contesto siano esplicitamente controllati dall’utente. I portali sanitari, in cui gli utenti possono trovarsi in condizioni vulnerabili e necessitare di interfacce prevedibili e calme, rappresentano un’altra categoria in cui superare la soglia AA con criteri AAA come 3.2.5 dimostra sia un impegno etico sia una concreta sicurezza per l’utente.

Le istituzioni pubbliche soggette a requisiti di audit e rendicontazione ai sensi della circolare dovrebbero documentare il loro livello di conformità. Sebbene il livello AAA non sia legalmente imposto, raggiungerlo — e documentarlo — fornisce una prova difendibile di un impegno all’accessibilità di livello eccellente. Per le entità che servono persone con disabilità come pubblico primario o significativo, come l’ente di previdenza sociale (SGK) o i servizi di supporto alla disabilità, perseguire la conformità di livello AAA è particolarmente allineato con lo spirito della regolamentazione.

Le organizzazioni che soddisfano volontariamente WCAG 3.2.5 si posizionano anche favorevolmente nel contesto dell’allineamento all’accessibilità dell’Unione Europea, poiché le relazioni di commercio digitale della Turchia con gli Stati membri dell’UE coinvolgono sempre più l’accessibilità come criterio di approvvigionamento e partnership. L’European Accessibility Act (EAA), entrato in vigore nel giugno 2025, si applica a prodotti e servizi offerti nei mercati dell’UE — inclusi quelli forniti da aziende turche a utenti europei — e incoraggia fortemente schemi di interazione controllati dall’utente coerenti con 3.2.5.

In termini pratici, i team di sviluppo turchi che implementano l’SDK di overlay di Accsible dovrebbero assicurarsi che eventuali widget iniettati dinamicamente, pannelli delle preferenze o controlli assistivi non introducano essi stessi cambiamenti di contesto non avviati. La toolbar e il pannello delle impostazioni dell’SDK devono aprirsi e chiudersi solo in risposta ad azioni esplicite dell’utente, e qualsiasi navigazione o aggiornamento di contenuto attivato tramite l’overlay deve essere avviato dall’utente. Questo garantisce che la soluzione di accessibilità stessa non crei le stesse barriere che è progettata per rimuovere.