WCAG 3.2.2: All’Inserimento

Cosa Significa Questa Regola

WCAG 3.2.2 On Input fa parte del principio Comprensibile e rientra nella Linea guida 3.2 Prevedibile. Stabilisce che la modifica dell’impostazione di qualsiasi componente dell’interfaccia utente non deve causare automaticamente un cambiamento di contesto, a meno che l’utente non sia stato informato in anticipo che si verificherà tale comportamento.

Un cambiamento di contesto è una modifica importante del contenuto di una pagina web che può disorientare gli utenti che non possono vedere l’intera pagina in una volta sola. Secondo la specifica WCAG, i cambiamenti di contesto includono: cambiamenti di user agent (browser), cambiamenti di viewport, cambiamenti di focus e cambiamenti di contenuto che alterano in modo significativo il significato della pagina. L’invio di un modulo, l’apertura di una nuova finestra o la navigazione verso un’altra pagina rientrano tutti nei cambiamenti di contesto. La semplice rivelazione di contenuto aggiuntivo, come un’accordion che si espande, non lo è.

Il criterio si applica specificamente alla modifica dell’impostazione di un componente UI — ad esempio, selezionare un pulsante di opzione (radio), spuntare una casella di controllo o scegliere un’opzione in un menu a discesa <select> — a differenza dell’attivazione di un controllo (come fare clic su un pulsante). Se un’azione richiede un passaggio di attivazione esplicito (premere Invio, fare clic su Invia), in genere non rientra in questo criterio. Il modello problematico è quando il semplice atto di selezionare un valore attiva immediatamente la navigazione o un ricaricamento significativo della pagina senza alcun preavviso.

Cosa è considerato conforme: Un modulo che utilizza un pulsante di invio per elaborare le selezioni dell’utente, anche se tali selezioni includono menu a discesa o caselle di controllo, soddisfa questo criterio. Un menu a discesa che filtra i risultati sulla stessa pagina senza ricaricare o spostare significativamente il focus è conforme. Una pagina che avvisa gli utenti in anticipo — ad esempio, con una nota visibile come “La selezione di una lingua ricaricherà la pagina” — che un determinato input attiverà un cambiamento di contesto è anch’essa conforme.

Cosa è considerato non conforme: Un selettore di paese o lingua che reindirizza automaticamente l’utente a un nuovo URL nel momento in cui viene scelta un’opzione non è conforme. Un modulo che si invia automaticamente e naviga altrove quando viene selezionato un pulsante di opzione, senza alcun pulsante di invio, non è conforme. Anche un widget di completamento automatico che sposta il focus da tastiera in una nuova area della pagina senza preavviso al momento della selezione non è conforme.

Eccezioni ufficiali: La specifica WCAG osserva che, se l’utente è informato del comportamento prima di utilizzare il componente, il cambiamento automatico di contesto è accettabile. Questo avviso deve essere presente prima che l’interazione avvenga, non dopo.

Perché È Importante

I cambiamenti di contesto imprevisti sono tra le esperienze più disorientanti sul web, e l’impatto è amplificato in modo significativo per gli utenti con disabilità. Quando una pagina all’improvviso naviga, si ricarica o sposta il focus senza preavviso, gli utenti che non possono vedere il layout visivo completo della pagina perdono completamente il loro orientamento.

Gli utenti di screen reader sono particolarmente vulnerabili. Quando una persona cieca che utilizza NVDA o JAWS seleziona un’opzione in un menu a discesa e la pagina si ricarica o naviga immediatamente, lo screen reader annuncia il nuovo contesto della pagina da zero. L’utente perde traccia di dove si trovava, di cosa stava facendo e deve ri-navigare l’intera pagina per ritrovare i propri punti di riferimento. Questo non è un semplice inconveniente — può rendere il compito completamente impossibile da completare in autonomia.

Gli utenti che usano solo la tastiera, incluse le persone con disabilità motorie che non possono usare il mouse, affrontano un problema simile. Potrebbero navigare in un modulo usando Tab e i tasti freccia e attivare accidentalmente un cambiamento di contesto che non intendevano. Senza un controllo motorio fine, recuperare da una navigazione di pagina non voluta può richiedere uno sforzo significativo.

Le disabilità cognitive aggravano ulteriormente il problema. Le persone con disturbi dell’attenzione, difficoltà di apprendimento o deficit di memoria si affidano a interfacce prevedibili e stabili per capire cosa sta succedendo. I cambiamenti di contesto improvvisi rompono il modello mentale che hanno costruito durante la sessione, spesso costringendole a ricominciare da capo o ad abbandonare il compito.

Le persone con disturbi vestibolari possono sperimentare disagio fisico o disorientamento quando le pagine cambiano inaspettatamente, in particolare se il cambiamento comporta animazioni o spostamenti della posizione di scorrimento.

Uno scenario concreto nel mondo reale: si consideri una pagina di checkout di e-commerce in Turchia in cui un utente seleziona la propria provincia da un menu a discesa. Se quella selezione ricarica immediatamente la pagina per aggiornare le opzioni di spedizione, un utente di screen reader potrebbe trovarsi all’improvviso all’inizio della pagina senza alcuna indicazione di cosa sia successo. Dovrebbe tornare a navigare attraverso tutti i campi del modulo per ritrovare il punto in cui si trovava, senza sapere se i dati inseriti in precedenza sono stati conservati. Questo tipo di attrito può portare le persone ad abbandonare completamente l’acquisto.

Da una prospettiva di usabilità e SEO, le pagine che si comportano in modo prevedibile hanno tassi di rimbalzo più bassi. Gli utenti sono meno propensi ad andarsene frustrati e i crawler dei motori di ricerca possono indicizzare il contenuto in modo più affidabile senza che reindirizzamenti imprevisti interferiscano con i percorsi di scansione.

Regole Axe-core Correlate

WCAG 3.2.2 On Input richiede test manuali. Strumenti automatici come axe-core non possono rilevare in modo affidabile le violazioni di questo criterio perché il comportamento problematico è contestuale e dipende dall’intento dietro un’interazione, non semplicemente dalla presenza o assenza di un attributo o di una struttura HTML specifica. Uno strumento può identificare che un elemento <select> ha un gestore di eventi onchange, ma non può determinare se quel gestore attiva un cambiamento di contesto, se l’utente è stato avvisato di ciò o se il comportamento risultante è disorientante nella pratica.

• Test manuale richiesto — Modelli di navigazione con onchange: Gli scanner automatici possono segnalare elementi <select>, <input type='radio'> e <input type='checkbox'> che hanno gestori di eventi JavaScript (in particolare onchange), ma non possono determinare se tali gestori causano un cambiamento di contesto. Un tester umano deve interagire con ciascun controllo di questo tipo e osservare se la pagina naviga, si ricarica, sposta il focus in una regione drasticamente diversa o apre una nuova finestra senza un passaggio di attivazione esplicito da parte dell’utente.
• Test manuale richiesto — Presenza e adeguatezza del preavviso: Anche se viene rilevato un cambiamento di contesto, uno strumento automatico non può determinare se l’utente è stato adeguatamente avvisato prima di interagire con il controllo. Una persona deve verificare che qualsiasi avviso preventivo sia visibile prima che il componente venga incontrato, chiaramente formulato e descriva effettivamente il comportamento che si verificherà.
• Test manuale richiesto — Gestione del focus dopo l’input: Alcune violazioni si manifestano come spostamento del focus in una posizione inattesa al cambiamento dell’input piuttosto che come vera e propria navigazione. Gli strumenti automatici non possono tracciare in modo affidabile le destinazioni del focus attivate da eventi onchange e confermare se il posizionamento risultante del focus costituisce un cambiamento di contesto disorientante.

Come Eseguire i Test

1. Baseline di scansione automatizzata: Esegui axe DevTools o Lighthouse sulla pagina per identificare eventuali problemi segnalati in base a WCAG 3.2. Sebbene la 3.2.2 richieda test manuali, axe può far emergere problemi correlati (come etichette mancanti o problemi di gestione del focus) che forniscono un punto di partenza. Prendi nota di tutti i controlli del modulo — in particolare menu a discesa <select>, gruppi di pulsanti di opzione e caselle di controllo — per un successivo controllo manuale.
2. Identifica tutti i controlli di input con gestori di cambiamento: Nelle DevTools del browser, ispeziona il JavaScript della pagina o utilizza il pannello Event Listeners per identificare qualsiasi <select>, <input type='radio'>, <input type='checkbox'> o widget personalizzato che abbia un listener di eventi onchange, oninput o equivalente associato.
3. Test di interazione manuale da tastiera: Utilizzando solo la tastiera (Tab per navigare, tasti freccia per le opzioni radio/select), interagisci con ciascun controllo identificato. Osserva se la selezione di un’opzione causa la navigazione o il ricaricamento della pagina, l’apertura di una nuova finestra o lo spostamento del focus in una parte significativamente diversa della pagina. In caso affermativo, verifica se era visibile un avviso prima che il controllo venisse incontrato.
4. Test con NVDA + Firefox: Avvia Firefox con NVDA attivo. Naviga fino a ciascun controllo del modulo utilizzando il cursore virtuale di NVDA (tasti freccia) e poi interagisci usando la modalità moduli (Invio o Barra spaziatrice). Seleziona opzioni in menu a discesa e gruppi di pulsanti di opzione e ascolta eventuali annunci imprevisti che indichino un caricamento di pagina, una navigazione o un cambiamento di contesto importante. Nota se NVDA legge un nuovo titolo di pagina o una regione drasticamente diversa.
5. Test con VoiceOver + Safari (macOS/iOS): Abilita VoiceOver e naviga fino a ciascun controllo usando VO+Freccia destra. Interagisci con menu a discesa e caselle di controllo. Se si verifica un cambiamento di contesto, VoiceOver in genere annuncerà la nuova pagina o lo spostamento del focus. Determina se l’utente era stato preavvisato.
6. Test con JAWS + Chrome: Utilizza JAWS in modalità cursore virtuale per navigare nella pagina. Interagisci con i controlli del modulo e monitora se JAWS annuncia un cambiamento di contesto (cambio del titolo della pagina, nuovo URL, posizione di lettura spostata) immediatamente dopo l’input — senza che sia stato attivato un pulsante di invio.
7. Osservazione visiva: Per gli utenti vedenti senza tecnologie assistive, seleziona opzioni in ciascun menu a discesa e gruppo di pulsanti di opzione e osserva se la pagina naviga o si ricarica inaspettatamente. Se ciò accade, verifica se un testo istruttivo visibile prima del controllo avvisava di questo comportamento.

Come Correggere

Menu a discesa con invio automatico — Non corretto

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

Menu a discesa con invio automatico — Corretto

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

Pattern di invio automatico con pulsanti di opzione — Non corretto

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

Pattern di invio automatico con pulsanti di opzione — Corretto

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

Selettore di lingua con preavviso — Corretto

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

Errori Comuni

• Associare assegnazioni di window.location.href direttamente all’attributo onchange di un elemento <select> senza un pulsante di invio, causando la navigazione immediata della pagina nel momento in cui l’utente sceglie un’opzione.
• Usare this.form.submit() all’interno del gestore onchange di un pulsante di opzione, il che invia l’intero modulo e naviga altrove nell’istante in cui viene selezionata un’opzione — prima che l’utente possa rivedere le proprie scelte.
• Posizionare il preavviso dopo il controllo nel DOM in modo che gli utenti di screen reader e i navigatori da tastiera incontrino il controllo prima di ascoltare o leggere l’avviso sul comportamento che esso attiva.
• Mostrare il preavviso solo come tooltip o testo segnaposto che non è esposto in modo affidabile alle tecnologie assistive, lasciando gli utenti di screen reader senza alcuna indicazione che un cambiamento di contesto seguirà il loro input.
• Costruire widget di menu a discesa personalizzati usando elementi <div> e <ul> che attivano la navigazione alla selezione tramite JavaScript ma che mancano della struttura semantica che permetterebbe ai tester o agli overlay di accessibilità di identificarli come controlli interattivi da esaminare ai sensi della 3.2.2.
• Attivare l’invio automatico di un modulo sull’ultimo campo di un modulo (ad esempio, un input per PIN o OTP) quando viene raggiunto il numero richiesto di caratteri, senza informare l’utente che ciò accadrà.
• Aprire una finestra modale o una nuova finestra del browser in risposta alla spunta di una casella di controllo, senza alcun preavviso — questo costituisce un cambiamento di contesto perché sposta in modo significativo il viewport e il focus dell’utente.
• Confondere aggiornamenti di contenuto in pagina prevedibili con cambiamenti di contesto e aggiungere pulsanti di invio non necessari attorno a interazioni già accettabili (come un filtro di ricerca in tempo reale), che possono affollare l’interfaccia — i team dovrebbero capire che aggiornamenti in linea non disorientanti non richiedono un passaggio di invio.
• Fare affidamento esclusivamente su scansioni automatiche di accessibilità e considerare la 3.2.2 come soddisfatta perché nessuna regola automatica l’ha segnalata, senza eseguire i test manuali obbligatori con tastiera e screen reader richiesti da questo criterio.
• Applicare un gestore onchange che cambia contesto a un <select> usato per ordinare o filtrare in un elenco di risultati, causando un ricaricamento completo della pagina anziché un aggiornamento AJAX, e non avvisare gli utenti che questo ricaricamento avverrà alla selezione.

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 basati su WCAG 2.2. WCAG 3.2.2 On Input è un criterio di Livello A, che rappresenta il livello minimo di conformità previsto dalla circolare — il che significa che la conformità non è facoltativa ma legalmente richiesta per tutti i soggetti interessati.

La circolare definisce una tempistica di attuazione a due livelli. Le istituzioni pubbliche — incluse i ministeri, i comuni, le università statali e le agenzie governative — devono raggiungere la piena conformità al Livello A entro un anno dalla pubblicazione della circolare. Le entità del settore privato coperte dal regolamento hanno una finestra di due anni per conformarsi.

I seguenti tipi di entità sono esplicitamente coperti dalla circolare e devono quindi garantire che i loro servizi digitali siano conformi a WCAG 3.2.2: piattaforme di e-commerce, istituzioni pubbliche a tutti i livelli di governo, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari, società di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio autorizzate, società di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE).

Per queste entità, una violazione di WCAG 3.2.2 — come un selettore di lingua su un portale bancario che reindirizza automaticamente alla selezione, o un modulo di prenotazione di appuntamenti ospedalieri che si invia automaticamente quando viene scelto un pulsante di opzione per il reparto — costituisce una non conformità normativa diretta. Considerato che la Turchia ha una popolazione significativa di utenti con disabilità e che i servizi digitali governativi sono sempre più il canale principale attraverso cui i cittadini accedono ai servizi pubblici, le implicazioni pratiche dell’ignorare questo criterio sono rilevanti.

Le organizzazioni soggette alla circolare dovrebbero trattare i test relativi a WCAG 3.2.2 come una fase di audit obbligatoria durante il QA. Poiché gli strumenti automatici non possono rilevare le violazioni di questo criterio, i test manuali da parte di specialisti di accessibilità formati — che coprano l’interazione da tastiera, il comportamento degli screen reader con NVDA e JAWS e la revisione esplicita di tutte le interazioni basate su onchange — devono essere integrati nel processo di conformità. È consigliabile documentare i risultati dei test e qualsiasi eccezione accettata (con preavvisi in atto) per dimostrare la dovuta diligenza agli organismi di regolamentazione.