WCAG 3.2.1: Al focus

Cosa significa questa regola

Il Criterio di Successo WCAG 3.2.1 On Focus (Livello A) afferma: «Se un componente riceve il focus, non avvia un cambiamento di contesto.» In termini semplici, l’atto di spostare il focus su un elemento interattivo — premendo Tab, Shift+Tab, i tasti freccia o qualsiasi altro meccanismo da tastiera — non deve di per sé causare qualcosa di drastico e inaspettato sulla pagina.

Un cambiamento di contesto è definito dalle WCAG come un cambiamento importante nel contenuto della pagina che, se avvenisse senza che l’utente ne sia consapevole, potrebbe disorientarlo. La specifica identifica quattro tipi concreti di cambiamento di contesto: cambiamenti all’user agent (come l’apertura di una nuova finestra o scheda del browser), cambiamenti al viewport (come lo scorrimento automatico a una parte distante della pagina), cambiamenti al focus stesso (come lo spostamento automatico del focus altrove) e cambiamenti al contenuto che alterano in modo significativo il significato della pagina (come l’invio di un modulo o il caricamento di una vista completamente diversa).

La distinzione chiave tracciata dal criterio è tra il ricevere il focus e attivare un controllo. Spostarsi con Tab su un pulsante e far sì che questo invii un modulo è una violazione. Ma premere Invio o Barra spaziatrice mentre quel pulsante ha il focus — un’attivazione intenzionale e deliberata — è perfettamente accettabile e persino attesa. L’intenzione dell’utente è ciò che separa un’interazione prevedibile da una disorientante.

Modelli comuni che non rispettano questo criterio includono:

• Un menu a discesa <select> che naviga automaticamente a un nuovo URL non appena un’opzione riceve il focus (non quando l’utente conferma la sua scelta).
• Un widget selettore di data che apre una finestra modale nel momento in cui uno qualsiasi dei suoi campi di input riceve il focus, senza alcuna attivazione da parte dell’utente.
• Un carosello o slideshow che avanza automaticamente alla slide successiva quando i suoi pallini di navigazione ricevono il focus.
• Un tooltip o popover che, quando viene attivato dal focus, sposta contemporaneamente il focus della tastiera su se stesso senza preavviso, lasciando l’utente bloccato in una posizione inaspettata.
• Un campo di ricerca che invia immediatamente il modulo e ricarica la pagina quando riceve il focus.

Modelli che non costituiscono violazioni includono: un tooltip o un pannello descrittivo che appare visivamente ma non sposta il focus né altera il contenuto principale della pagina; un indicatore di focus (come un contorno o un anello) che appare intorno all’elemento focalizzato; oppure un elemento che si espande per mostrare contenuto aggiuntivo in linea, purché il focus rimanga dove l’utente lo ha posizionato.

Non esistono eccezioni ufficiali definite nelle WCAG 3.2.1. Il criterio si applica universalmente a tutti i componenti dell’interfaccia utente su una pagina. Tuttavia, il documento di comprensione delle WCAG osserva che i cambiamenti di contesto attivati da un’azione deliberata dell’utente (click, Invio, Barra spaziatrice) esulano dall’ambito di questo criterio, che riguarda solo l’atto passivo di ricevere il focus.

Perché è importante

Il criterio On Focus rientra nel Principio 3 — Comprensibile — perché la prevedibilità è un prerequisito fondamentale per l’usabilità. Quando una pagina si comporta in modo inaspettato in risposta al solo focus, le conseguenze vanno da una lieve confusione alla perdita completa di accesso, a seconda delle esigenze e degli strumenti dell’utente.

Le persone che usano solo la tastiera (persone che non possono usare il mouse a causa di disabilità motorie, lesioni da sforzo ripetitivo o paralisi) si affidano esclusivamente alla navigazione da tastiera. Quando spostarsi con Tab in un campo di un modulo provoca il ricaricamento della pagina, possono perdere tutti i dati già inseriti e ritrovarsi reindirizzati lontano dal loro obiettivo. Riprendersi da una simile interruzione può richiedere tempo e sforzo significativi — oppure possono semplicemente rinunciare del tutto.

Le persone che usano screen reader (che spesso sono anche utenti solo tastiera) affrontano un ulteriore livello di disorientamento. Gli screen reader annunciano all’utente l’elemento attualmente focalizzato. Se il focus salta inaspettatamente su un nuovo elemento — per esempio, una modale che si è aperta automaticamente — lo screen reader annuncia il nuovo contesto senza fornire all’utente alcun riferimento su cosa sia appena successo o perché. È analogo a essere fisicamente sollevati e spostati in un’altra stanza senza preavviso.

Le persone con disabilità cognitive, incluse quelle con ADHD, disturbi d’ansia o deficit di memoria, dipendono da interfacce prevedibili per costruire e mantenere un modello mentale di una pagina. Cambiamenti di contesto improvvisi e inspiegabili infrangono quel modello, creando confusione, ansia ed errori. Uno studio del progetto WebAIM Million rileva costantemente che i componenti interattivi complessi con comportamenti inaspettati sono tra le principali fonti di reclami in materia di accessibilità da parte di persone con disabilità cognitive.

Le persone con ipovisione che usano software di ingrandimento dello schermo (come ZoomText o Lente di ingrandimento di Windows) vedono solo una piccola porzione dello schermo alla volta. Se il focus provoca uno scorrimento o una navigazione automatica, il contenuto rilevante può uscire completamente dal loro viewport ingrandito, lasciandole a fissare un’area vuota o non correlata dello schermo.

Consideriamo uno scenario concreto reale: il modulo online di trasferimento di denaro di una banca turca contiene un menu a discesa per selezionare la banca di destinazione. Lo sviluppatore ha implementato un evento in stile onchange sull’elemento <select> che viene attivato non alla conferma, ma non appena un’opzione riceve il focus tramite i tasti freccia. Una persona che usa uno screen reader, spostandosi con Tab nel campo e premendo la freccia Giù per esplorare le banche disponibili, attiva immediatamente l’invio del modulo o il ricaricamento della pagina. Non completa mai il trasferimento e non riesce a capire cosa sia andato storto. Questo scenario non è ipotetico — è stato un modello documentato in molte prime single-page application.

Oltre all’accessibilità, ci sono benefici tangibili in termini di usabilità e di business. I moduli che non “dirottano” il focus hanno tassi di abbandono più bassi. Le pagine che si comportano in modo prevedibile ottengono risultati migliori nei test di usabilità con tutti i pubblici. Anche i crawler dei motori di ricerca traggono vantaggio da flussi di navigazione prevedibili, poiché i reindirizzamenti inaspettati attivati da eventi di focus possono confondere la logica di crawling in alcuni scenari di rendering dinamico.

Regole Axe-core correlate

WCAG 3.2.1 On Focus richiede test manuali perché gli strumenti automatici non possono determinare in modo affidabile l’intento dell’utente né prevedere tutti i possibili cambiamenti di contesto. Axe-core e scanner automatici simili possono analizzare HTML statico e attributi ARIA, ma non possono osservare il comportamento JavaScript a runtime in risposta agli eventi di focus — in particolare se tale comportamento costituisce un “cambiamento di contesto importante” come definito dalle WCAG. Uno script che sposta il focus, invia un modulo o naviga verso un URL sull’evento focus è invisibile a uno scanner statico, a meno che lo strumento non simuli effettivamente le interazioni di focus su ogni elemento interattivo e poi analizzi cosa è cambiato nel DOM, nel viewport e nell’URL. Questo livello di simulazione comportamentale non è raggiungibile in modo affidabile in una scansione automatica senza un tasso di falsi positivi proibitivamente alto.

• Test manuale richiesto — Cambiamento di contesto On Focus: I tester devono spostarsi manualmente con Tab su ogni elemento interattivo della pagina (link, pulsanti, campi di input, select, widget personalizzati) e osservare se il solo focus — senza alcuna attivazione — provoca un cambiamento di contesto come definito dalle WCAG. Ciò include monitorare cambiamenti dell’URL, apertura di nuove finestre o schede, spostamento del focus dall’elemento appena raggiunto, invio di moduli e sostituzioni importanti del contenuto. Gli strumenti automatici segnalano i listener di eventi JavaScript collegati a eventi correlati al focus (focus, focusin, onfocus) come candidati per la revisione manuale, ma non possono determinare se tali handler causino un cambiamento di contesto non consentito.

Come testare

1. Pre-scansione automatizzata: Esegui axe DevTools (estensione del browser o CLI) o Google Lighthouse sulla pagina. Sebbene nessuno dei due strumenti possa segnalare in modo definitivo violazioni di On Focus, axe DevTools può far emergere problemi correlati alla gestione del focus (come pattern di scrollable-region-focusable o di focus-trap) che meritano un’ispezione manuale più approfondita. Usa il pannello “Needs Review” di axe DevTools — gli elementi segnalati lì spesso riguardano comportamenti di componenti interattivi che richiedono un giudizio umano.
2. Identifica tutti gli elementi interattivi: Prima dei test da tastiera, fai un elenco di tutti i componenti interattivi: link, pulsanti, campi di input dei moduli, menu a discesa, checkbox, radio button, selettori di data, caroselli, fisarmoniche (accordion), tab, modali e qualsiasi widget personalizzato che utilizzi tabindex. Presta particolare attenzione ai widget JavaScript personalizzati che ascoltano gli eventi focus o focusin.
3. Test di navigazione solo tastiera: Usando solo la tastiera (senza mouse), premi Tab in sequenza su ogni elemento focalizzabile della pagina. Dopo ogni pressione di Tab, prima di premere qualsiasi altro tasto, osserva: L’URL è cambiato? Si è aperta una nuova finestra o scheda? Il focus si è spostato dall’elemento su cui ti eri appena posizionato? Un modulo è stato inviato? Il contenuto principale della pagina è cambiato in modo drastico? Qualsiasi risposta “sì” è un potenziale caso di violazione.
4. Test sugli elementi select: Porta il focus su qualsiasi menu a discesa <select>. Usa le frecce Su e Giù per spostarti tra le opzioni senza premere Invio o Barra spaziatrice. Verifica che la navigazione tra le opzioni non attivi alcuna navigazione, invio di modulo o cambiamento di contesto. Questo è uno dei pattern più frequentemente violati.
5. NVDA + Firefox: Attiva NVDA (gratuito, per Windows). Apri Firefox e vai alla pagina. Premi Tab su tutti gli elementi interattivi. Ascolta gli annunci di NVDA — se NVDA inizia ad annunciare una parte completamente diversa della pagina o un nuovo contesto di pagina dopo una pressione di Tab (senza che tu abbia premuto Invio o Barra spaziatrice), questo è un forte segnale di violazione.
6. JAWS + Chrome: Attiva JAWS. Apri Chrome. Usa Tab per navigare. JAWS annuncerà ogni elemento focalizzato. Monitora annunci inaspettati di nuove finestre di dialogo, pagine o posizioni di focus alle quali non hai navigato deliberatamente.
7. VoiceOver + Safari (macOS/iOS): Attiva VoiceOver (Cmd+F5 su macOS). Naviga con Tab (o con lo swipe su iOS). Monitora eventuali cambiamenti di contesto inaspettati. Su iOS, testa anche con l’accesso tramite interruttore (switch access) per simulare persone con gravi disabilità motorie che navigano tramite scansione.
8. Ispezione dei listener di eventi con gli Strumenti di sviluppo del browser: In Chrome DevTools, seleziona qualsiasi elemento interattivo sospetto, vai al pannello Elements e fai clic su “Event Listeners”. Cerca listener focus o focusin. Se presenti, esamina il JavaScript collegato per determinare se l’handler attiva navigazione, invio di moduli, spostamento del focus o altre azioni che cambiano il contesto.

Come correggere

Menu a discesa select con invio automatico — Errato

<!-- FAIL: Selezionare un'opzione con i tasti freccia naviga immediatamente a un nuovo URL -->
<label for='region'>Select Region</label>
<select id='region' onchange='window.location = this.value;'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>

Menu a discesa select con invio automatico — Corretto

<!-- PASS: La navigazione avviene solo quando l'utente attiva esplicitamente il pulsante Go -->
<label for='region'>Select Region</label>
<select id='region'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>
<button type='button' onclick='navigateToRegion()'>Go</button>

<script>
function navigateToRegion() {
  var select = document.getElementById('region');
  window.location = select.value; // Viene eseguito solo su attivazione deliberata del pulsante
}
</script>

Modale che si apre al focus sull’input — Errato

<!-- FAIL: Portare il focus sull'input della data apre immediatamente una finestra modale e sposta il focus -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' onfocus='openDatePickerModal()' />

<script>
function openDatePickerModal() {
  var modal = document.getElementById('date-modal');
  modal.style.display = 'block';
  modal.querySelector('button').focus(); // Sposta il focus altrove senza intenzione dell'utente
}
</script>

Modale che si apre al focus sull’input — Corretto

<!-- PASS: Il selettore di data si apre solo quando l'utente fa clic o preme Invio/Barra spaziatrice -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' readonly aria-haspopup='dialog'
       aria-label='Departure Date — press Enter to open date picker' />
<button type='button' id='open-picker'
        aria-controls='date-modal'
        onclick='openDatePickerModal()'>
  Choose Date
</button>

<script>
function openDatePickerModal() {
  // Chiamata solo su attivazione esplicita (click o Invio/Barra spaziatrice sul pulsante)
  var modal = document.getElementById('date-modal');
  modal.removeAttribute('hidden');
  modal.querySelector('[data-initial-focus]').focus();
}
</script>

Carosello che avanza automaticamente al focus — Errato

<!-- FAIL: Portare il focus su un pallino di navigazione fa avanzare la slide del carosello, cambiando il contenuto della pagina -->
<div class='carousel-dots'>
  <button class='dot' onfocus='showSlide(0)'>1</button>
  <button class='dot' onfocus='showSlide(1)'>2</button>
  <button class='dot' onfocus='showSlide(2)'>3</button>
</div>

Carosello che avanza automaticamente al focus — Corretto

<!-- PASS: Il carosello cambia slide solo quando il pallino viene attivato esplicitamente (click/Invio) -->
<div class='carousel-dots' role='tablist' aria-label='Carousel navigation'>
  <button class='dot' role='tab' aria-selected='true'
          aria-controls='slide-0' onclick='showSlide(0)'>
    Slide 1
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-1' onclick='showSlide(1)'>
    Slide 2
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-2' onclick='showSlide(2)'>
    Slide 3
  </button>
</div>
<!-- onclick viene eseguito solo su attivazione deliberata, non sul focus tramite Tab -->

Errori comuni

• Usare onfocus come sostituto di onclick sugli elementi di navigazione: A volte gli sviluppatori collegano handler onfocus a link o pulsanti di navigazione per “precaricare” una destinazione, attivando accidentalmente una navigazione completa invece di un semplice prefetch. Usa sempre onclick o onkeydown (verificando Invio/Barra spaziatrice) per qualsiasi azione che cambi il contesto.
• Associare onchange agli elementi <select> senza un’azione di invio: Nei browser desktop, onchange su un <select> viene eseguito quando un’opzione è confermata, ma in alcune implementazioni più vecchie e in certi browser mobili può essere eseguito mentre i tasti freccia scorrono tra le opzioni. Associa sempre la navigazione basata su select a un pulsante di invio esplicito o usa un <form> con un <button type='submit'>.
• Spostare il focus in modo programmato all’interno di un handler di focus: Chiamare element.focus() all’interno dell’handler onfocus o focusin di un altro elemento crea un salto di focus inaspettato. Questa è una violazione diretta — l’utente ha premuto Tab sull’elemento A e il focus si è spostato silenziosamente sull’elemento B. Sposta sempre il focus solo in risposta ad azioni deliberate dell’utente.
• Aprire finestre modali su eventi di focus di qualsiasi elemento trigger: Una scorciatoia comune è collegare un handler di apertura modale all’evento focus di un pulsante o campo di input trigger. Le modali devono aprirsi solo in risposta a un click, al tasto Invio o alla Barra spaziatrice — mai sul solo focus.
• Avviare automaticamente media o animazioni che cambiano il contesto del viewport al focus: Un banner hero che avvia un video a schermo intero o una grande animazione nel momento in cui il suo pulsante di riproduzione riceve il focus cambia significativamente il contesto visivo. Collega le azioni di riproduzione agli eventi di attivazione, non agli eventi di focus.
• Attivare aggiornamenti di live region che fanno scorrere la pagina verso nuovo contenuto al focus: Alcuni widget dinamici aggiornano una live region e poi fanno scorrere il viewport verso quella regione non appena un input riceve il focus. Questo cambia il contesto del viewport e disorienta le persone che usano l’ingrandimento dello schermo. Se possibile, separa gli aggiornamenti delle live region dagli eventi di focus.
• Implementare focus trap personalizzati che intrappolano immediatamente gli utenti senza preavviso: Un componente personalizzato che intercetta tutte le pressioni di Tab nel momento in cui riceve il focus, senza annunciare all’utente che si trova all’interno di un focus trap, viola sia la lettera sia lo spirito di questo criterio. I focus trap sono appropriati solo all’interno di finestre modali completamente aperte e le persone devono essere informate su come uscirne.
• Usare il selettore CSS :focus per attivare display: block su menu a discesa che contengono elementi focalizzabili, causando movimenti di focus inaspettati a cascata: I menu basati solo su focus in CSS che rivelano elementi focalizzabili possono causare salti confusi quando l’ordine di focus del browser si sposta nei nuovi elementi visibili. Assicurati che i menu rivelati siano attesi e chiaramente comunicati tramite attributi ARIA come aria-expanded.
• Affidarsi a librerie di widget di terze parti senza verificarne il comportamento del focus: Molte librerie di componenti UI (selettori di data, editor di testo avanzati, menu a discesa in stile select2) hanno storicamente violato la 3.2.1 aprendo popup o spostando il focus sugli eventi di focus. Verifica sempre manualmente i componenti di terze parti prima della messa in produzione, indipendentemente dalle dichiarazioni di accessibilità della libreria.
• Dimenticare di testare nei contesti di routing delle single-page application (SPA): Nelle SPA React, Vue e Angular, gli eventi di focus sui link di navigazione possono talvolta attivare cambi di route tramite la logica di prefetch del router o il bubbling degli eventi, soprattutto quando gli eventi di focus non vengono correttamente fermati nella propagazione. Testa esplicitamente i componenti di navigazione delle SPA per la conformità alla 3.2.1.

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 che fanno esplicito riferimento alle WCAG 2.2 come standard tecnico. WCAG 3.2.1 On Focus è un criterio di Livello A, il che significa che si colloca alla base della conformità obbligatoria prevista dalla circolare. Non esistono esenzioni per i criteri di Livello A — tutti i soggetti interessati devono rispettarli entro le tempistiche definite.

Le istituzioni pubbliche sono tenute a raggiungere la piena conformità entro un anno dalla data di pubblicazione della circolare. I soggetti del settore privato rientranti nel campo di applicazione hanno due anni. I soggetti coperti dalla Circolare Presidenziale 2025/10 includono un’ampia gamma di organizzazioni: tutte le istituzioni e agenzie pubbliche, le piattaforme di e-commerce e i marketplace online, le banche e le istituzioni finanziarie, gli ospedali e i fornitori di assistenza sanitaria privati, le società di telecomunicazioni con 200.000 o più abbonati, le agenzie di viaggio e le piattaforme di prenotazione, le società di trasporto private e le scuole e istituzioni educative private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE).

La rilevanza di WCAG 3.2.1 On Focus per questi tipi di soggetti è diretta e pratica. Si consideri una piattaforma di e-commerce in cui un menu a discesa delle categorie di prodotto effettua una navigazione automatica al focus — una persona che usa la tastiera a causa di una disabilità motoria non può esplorare le categorie di prodotto e abbandonerà l’acquisto. Un modulo di trasferimento online di una banca con invii attivati dal focus potrebbe causare transazioni finanziarie non intenzionali o ripetuti tentativi falliti per le persone che usano screen reader. Un sistema di prenotazione di appuntamenti ospedalieri in cui i campi data aprono modali al focus può impedire alle persone con disabilità di programmare autonomamente le cure.

In base alla circolare, la mancata conformità espone i soggetti interessati a sanzioni amministrative e a rischi reputazionali. Per i soggetti che stanno attualmente affrontando una trasformazione digitale o acquistando nuovi sistemi web, integrare ora la conformità a WCAG 3.2.1 nei requisiti di gara e nelle linee guida per gli sviluppatori — invece di intervenire a posteriori dopo un reclamo — è sia più conveniente sia più in linea con lo spirito della normativa. Le organizzazioni che utilizzano l’SDK di overlay Accsible beneficiano di strumenti di gestione del focus integrati che aiutano a identificare e correggere comportamenti inaspettati legati al focus come parte di un flusso di lavoro più ampio di conformità a WCAG 2.2 Livello A.