WCAG 2.4.3: Ordine di messa a fuoco

Cosa Significa Questa Regola

WCAG 2.4.3 Focus Order è un criterio di successo di Livello A sotto il principio Operable. Stabilisce: «Se una pagina Web può essere navigata in modo sequenziale e le sequenze di navigazione influiscono sul significato o sul funzionamento, i componenti focalizzabili ricevono il focus in un ordine che preserva significato e operabilità.»

In termini pratici, questo significa che quando un utente preme il tasto Tab per spostarsi tra gli elementi interattivi di una pagina — link, pulsanti, campi di form, widget personalizzati e qualsiasi altro componente focalizzabile — la sequenza con cui questi elementi ricevono il focus deve avere un senso logico. Gli utenti non dovrebbero ritrovarsi a saltare inaspettatamente dal mezzo di un form a un link nel footer, poi di nuovo al pulsante di una modale, e poi a una voce del menu di navigazione.

Il criterio si applica alla navigazione sequenziale tramite tastiera, che è il modo principale con cui gli utenti che usano solo la tastiera e gli utenti di screen reader attraversano una pagina. L’ordine del DOM è la fonte predefinita dell’ordine di focus nei browser: gli elementi compaiono nella sequenza di tabulazione nell’ordine in cui appaiono nel Document Object Model (DOM), a meno che CSS o JavaScript non modifichino deliberatamente tale ordine. I problemi sorgono quando il layout visivo diverge dall’ordine del DOM (ad esempio, tramite riordinamento con CSS Flexbox o Grid), o quando valori di tabindex impongono una sequenza innaturale.

Cosa è considerato conforme: L’ordine di focus deve essere logico e significativo — non necessariamente identico all’ordine di lettura visivo, ma sufficientemente coerente da permettere agli utenti di comprendere e usare la pagina. Una finestra modale che sposta il focus su di sé quando viene aperta, mantiene il focus intrappolato al suo interno mentre è aperta e lo restituisce all’elemento che l’ha attivata quando viene chiusa soddisfa questo criterio. Anche un form a più passaggi in cui Tab procede attraverso ciascun campo nell’ordine in cui un utente li compilerebbe (dall’alto verso il basso, da sinistra a destra nelle lingue scritte da sinistra a destra) è conforme.

Cosa è considerato non conforme: Il focus che salta dal campo “Username” di un form di login a un banner promozionale completamente non correlato prima di raggiungere il campo “Password” non è conforme. Una single-page application che apre una finestra di dialogo ma lascia il focus sulla pagina di sfondo non è conforme. L’uso di valori interi positivi di tabindex (ad es. tabindex='2', tabindex='5') che forzano una sequenza di tabulazione illogica sulla pagina non è conforme.

Eccezioni ufficiali: WCAG specifica esplicitamente che l’ordine di focus non deve necessariamente corrispondere all’ordine di lettura visivo purché preservi significato e operabilità. È inoltre prevista un’eccezione per i casi in cui le sequenze di navigazione non influiscono sul significato o sul funzionamento — ad esempio, una pagina con un solo elemento focalizzabile non ha alcuna sequenza da valutare. Inoltre, quando esistono più ordinamenti validi che preservano tutti il significato, qualsiasi di questi ordinamenti è accettabile.

I principali meccanismi HTML e JavaScript che influenzano l’ordine di focus includono: l’ordine naturale del DOM degli elementi interattivi, l’attributo tabindex (in particolare i valori interi positivi), le proprietà CSS che riordinano il layout visivo senza modificare il DOM (come order in Flexbox/Grid, position: absolute e float), la gestione del focus guidata da JavaScript (chiamando .focus() sugli elementi) e i pattern ARIA per le dialog che richiedono una gestione esplicita del focus.

Perché È Importante

L’ordine di focus non è un dettaglio tecnico minore — è la spina dorsale della navigazione sul web per una parte significativa degli utenti. Diversi gruppi di persone con disabilità dipendono da una sequenza di focus logica per usare efficacemente i prodotti digitali.

Utenti con disabilità motorie che non possono usare il mouse si affidano interamente alla tastiera (o a dispositivi equivalenti alla tastiera come interruttori a soffio e aspirazione, puntatori per la testa o sistemi di eye-tracking) per navigare. Per questi utenti, un ordine di focus confuso non è solo scomodo — può rendere una pagina completamente inutilizzabile. Se il tasto Tab porta l’utente nella parte sbagliata della pagina, potrebbe non avere alcun modo efficiente per raggiungere il controllo di cui ha bisogno, e non può semplicemente spostare la mano per cliccare altrove.

Utenti ciechi e ipovedenti che usano screen reader come NVDA, JAWS o VoiceOver sentono gli elementi annunciati man mano che il focus si posiziona su di essi. Un ordine di focus logico significa che il flusso audio che ricevono riflette il flusso previsto dell’interfaccia. Quando il focus salta in modo irregolare, gli utenti perdono il loro modello mentale di dove si trovano nella pagina. Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo hanno qualche forma di disabilità visiva, e per molte di quelle che usano screen reader, l’ordine di focus è il modo principale di percepire la struttura della pagina.

Utenti con disabilità cognitive traggono anch’essi beneficio da sequenze di focus prevedibili. Un salto di focus inatteso a metà di un form può causare confusione, costringere gli utenti a ricominciare i flussi di lavoro o portarli a perdere campi obbligatori. Gli utenti con difficoltà di attenzione o di memoria a breve termine hanno bisogno di una navigazione coerente e prevedibile per acquisire fiducia nell’uso di un sito.

Uno scenario concreto reale: Immagina una pagina di checkout di e-commerce turca. Il design visivo usa CSS Grid per posizionare il riepilogo dell’ordine a sinistra e il form di pagamento a destra. Tuttavia, nel DOM, il form di pagamento viene prima e il riepilogo dell’ordine viene dopo. Il layout visivo appare corretto per gli utenti vedenti che usano il mouse, ma un utente da tastiera che preme Tab atterrerà nei campi del form di pagamento prima di aver avuto la possibilità di rivedere il riepilogo dell’ordine. Potrebbe confermare inconsapevolmente un ordine errato. Peggio ancora, se un pulsante “Conferma acquisto” riceve il focus prima di un campo “Applica coupon” a causa di una gestione errata di tabindex positivo, un utente potrebbe inviare accidentalmente un acquisto che intendeva scontare. Questo è una conseguenza finanziaria diretta e reale di un ordine di focus compromesso.

Oltre all’accessibilità, un ordine di focus logico migliora l’esperienza per gli utenti esperti che preferiscono la navigazione da tastiera per velocità. Supporta inoltre indirettamente la SEO: un DOM ben strutturato che produce un ordine di focus naturale tende a riflettere un markup semantico significativo, che i motori di ricerca usano per comprendere la gerarchia e l’importanza dei contenuti.

Regole Axe-core Correlate

WCAG 2.4.3 richiede test manuali per una valutazione definitiva. Strumenti automatici come axe-core non possono determinare algoritmicamente se una particolare sequenza di focus “preserva significato e operabilità” — tale giudizio richiede una persona che comprenda lo scopo della pagina e le relazioni tra i contenuti. Tuttavia, axe-core e strumenti correlati possono segnalare alcuni pattern che sono forti indicatori di problemi di ordine di focus:

• tabindex (valori positivi) — segnale euristico: Alcuni strumenti di linting e auditing avvisano quando gli elementi hanno valori interi positivi di tabindex (qualsiasi valore maggiore di 0). I valori positivi di tabindex sovrascrivono l’ordine naturale del DOM e collocano tali elementi all’inizio della sequenza di tabulazione, il che quasi sempre crea un ordine di focus illogico e imprevedibile. Sebbene il set di regole principale di axe-core non includa una regola automatizzata dedicata al “focus-order” (perché la correttezza logica della sequenza non può essere calcolata), strumenti come axe DevTools Pro e audit manuali verificano specificamente l’uso di tabindex positivi come indicatore indiretto.
• scrollable-region-focusable: Axe-core include una regola che segnala le regioni scrollabili che non sono focalizzabili tramite tastiera. Pur non essendo direttamente una regola sull’ordine di focus, una regione scrollabile che non può ricevere il focus interrompe la sequenza di navigazione complessiva, facendo sì che gli utenti da tastiera saltino contenuti con cui devono interagire.
• Ispezione manuale per contenuti riordinati con CSS: Gli strumenti automatici non possono rilevare quando l’uso di order in CSS Flexbox o il posizionamento in Grid crea una discrepanza tra l’ordine visivo e l’ordine del DOM. Un tester umano deve confrontare visivamente il layout sullo schermo con la sequenza di focus osservata durante la navigazione da tastiera. Questa è la fonte più comune di fallimenti del criterio 2.4.3 nei moderni design responsive ed è completamente invisibile agli scanner automatici.
• Ispezione manuale per la gestione del focus in JavaScript nei contenuti dinamici: Single-page application, implementazioni di infinite scroll, modali e menu a comparsa richiedono tutti che JavaScript sposti il focus in modo appropriato man mano che i contenuti cambiano. Gli strumenti automatici eseguono un’istantanea statica del DOM e non possono simulare la sequenza di interazioni utente necessarie per attivare questi scenari di gestione del focus. Solo i test manuali con tastiera possono verificare che il focus si sposti su una modale appena aperta, ritorni al trigger corretto alla chiusura e non lasci l’utente bloccato in un livello di sfondo inaccessibile.

Come Testare

1. Scansione automatizzata come punto di partenza: Esegui axe DevTools (estensione del browser) o Google Lighthouse sulla pagina. Cerca eventuali avvisi relativi a valori positivi di tabindex e regioni scrollabili segnalate. Nota che un risultato automatico pulito non significa che il criterio 2.4.3 sia soddisfatto — i test manuali sono sempre necessari. Registra eventuali problemi segnalati per ulteriori indagini.
2. Disconnetti il mouse e naviga solo con Tab: A partire dalla barra degli indirizzi del browser o dalla parte superiore della pagina, premi ripetutamente Tab per spostarti attraverso ogni elemento focalizzabile. Osserva attentamente la sequenza. Chiediti: il focus si sposta in un ordine che corrisponde al flusso logico di lettura e interazione della pagina? Il focus salta mai in un’area inattesa? Rimane mai intrappolato (impossibile andare avanti o indietro) tranne che all’interno di una dialog intenzionale?
3. Testa i componenti dinamici: Attiva eventuali modali, dialog, menu a discesa, accordion, pannelli a tab, date picker o altri widget interattivi usando la tastiera. Verifica che il focus si sposti nel contenuto appena rivelato immediatamente dopo l’attivazione. Dopo aver chiuso una dialog, conferma che il focus ritorni all’elemento che l’ha attivata — non all’inizio della pagina o in una posizione arbitraria.
4. Testa con NVDA + Firefox: Apri NVDA, avvia Firefox e naviga alla pagina. Usa Tab per spostarti tra gli elementi interattivi e ascolta gli annunci. Verifica che la sequenza annunciata abbia senso nel contesto. Usa la Browse Mode di NVDA (tasti freccia) per leggere i contenuti statici e conferma che l’ordine di lettura sia allineato con l’ordine di focus degli elementi interattivi all’interno di tali contenuti.
5. Testa con VoiceOver + Safari (macOS/iOS): Abilita VoiceOver e usa Tab (desktop) o i gesti di swipe (iOS) per spostarti tra gli elementi focalizzabili. Conferma che la sequenza di focus sia logica. Su iOS, verifica che modali e overlay intrappolino correttamente il focus e lo restituiscano alla chiusura.
6. Testa con JAWS + Chrome: Usa la navigazione con Tab di JAWS e conferma che la sequenza di focus annunciata sia coerente. Usa il cursore virtuale di JAWS per confrontare l’ordine di lettura con l’ordine di focus degli elementi interattivi e identifica eventuali discrepanze.
7. Ispeziona il DOM rispetto al layout visivo: Apri gli strumenti di sviluppo del browser ed esamina la struttura del DOM. Confronta l’ordine degli elementi interattivi nel DOM con la loro posizione visiva sullo schermo. Se proprietà CSS come order, position: absolute o float stanno creando differenze significative, traccia manualmente la sequenza di tabulazione per determinare se il significato o l’operabilità ne risultano compromessi.
8. Controlla i valori di tabindex nel DOM: Nella console del browser, esegui document.querySelectorAll('[tabindex]') per elencare tutti gli elementi con attributi tabindex espliciti. Esamina qualsiasi elemento con un valore intero positivo e valuta se il suo posizionamento nella sequenza di tabulazione modificata sia logico.

Come Correggere

Valori positivi di tabindex che creano un ordine illogico — Errato

<!-- Positive tabindex values force an unnatural tab sequence -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email' tabindex='3'>

  <label for='name'>Full Name</label>
  <input type='text' id='name' tabindex='1'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone' tabindex='2'>

  <button type='submit' tabindex='4'>Submit</button>
</form>
<!-- Tab order: Full Name → Phone → Email → Submit
     Visual/logical order: Email → Full Name → Phone → Submit
     This mismatch breaks focus order. -->

Valori positivi di tabindex che creano un ordine illogico — Corretto

<!-- Remove all positive tabindex values; rely on DOM order.
     Rearrange DOM to match the logical sequence. -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email'>

  <label for='name'>Full Name</label>
  <input type='text' id='name'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone'>

  <button type='submit'>Submit</button>
</form>
<!-- Tab order now follows DOM order: Email → Full Name → Phone → Submit
     Matches logical and visual order. No tabindex needed. -->

Riordinamento visivo con CSS che non corrisponde all’ordine del DOM — Errato

<!-- DOM has sidebar first, main content second.
     CSS uses flexbox order to visually flip them.
     Keyboard users tab through sidebar links before main content links,
     which does not match what a sighted user sees first. -->
<style>
  .layout { display: flex; }
  .sidebar { order: 2; } /* Visually shown on the right */
  .main    { order: 1; } /* Visually shown on the left */
</style>

<div class='layout'>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
</div>
<!-- Focus order: About → Contact → Read Article
     Visual order: Read Article → About → Contact
     Mismatch breaks 2.4.3 -->

Riordinamento visivo con CSS che non corrisponde all’ordine del DOM — Corretto

<!-- Fix: reorder the DOM to match the intended visual and logical order.
     Remove the CSS 'order' overrides that caused the mismatch. -->
<style>
  .layout { display: flex; }
  /* No 'order' overrides — DOM order determines both visual and tab order */
</style>

<div class='layout'>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
</div>
<!-- DOM order, visual order, and focus order now all match. -->

Finestra modale che non gestisce il focus — Errato

<!-- Button opens a modal, but focus stays on the background page.
     Keyboard users cannot interact with the dialog. -->
<button id='open-modal' onclick='document.getElementById("dialog").style.display="block"'>
  Open Settings
</button>

<div id='dialog' style='display:none;'>
  <h2>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>
<!-- When dialog opens, focus remains on #open-modal in the background.
     Tab continues to background page elements, not dialog elements. -->

Finestra modale che non gestisce il focus — Corretto

<!-- Focus is moved into the dialog on open and returned to trigger on close.
     role='dialog' and aria-modal='true' inform screen readers of the context. -->
<button id='open-modal'>Open Settings</button>

<div id='dialog'
     role='dialog'
     aria-modal='true'
     aria-labelledby='dialog-title'
     style='display:none;'>
  <h2 id='dialog-title'>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>

<script>
  const openBtn = document.getElementById('open-modal');
  const dialog  = document.getElementById('dialog');
  const closeBtn = document.getElementById('close-modal');

  openBtn.addEventListener('click', () => {
    dialog.style.display = 'block';
    // Move focus to first focusable element in dialog
    document.getElementById('theme').focus();
  });

  closeBtn.addEventListener('click', () => {
    dialog.style.display = 'none';
    // Return focus to the element that triggered the dialog
    openBtn.focus();
  });
</script>
<!-- Focus order is now logical: trigger → dialog contents → back to trigger. -->

Errori Comuni

• Usare valori interi positivi di tabindex (ad es. tabindex='1', tabindex='5') per “controllare” l’ordine di focus invece di correggere la struttura del DOM. I valori positivi di tabindex collocano gli elementi prima di tutti gli elementi naturalmente focalizzabili nella pagina, creando una sequenza di tabulazione globale caotica, estremamente difficile da mantenere e che quasi sempre introduce errori.
• Applicare order in Flexbox o CSS Grid per riordinare visivamente i contenuti senza riordinare il DOM, e poi non testare la navigazione da tastiera. Il layout visivo appare corretto agli utenti vedenti, ma la sequenza di tabulazione segue l’ordine del DOM, non quello visivo — una discrepanza invisibile ma grave per gli utenti da tastiera.
• Aprire una modale o una dialog senza spostare programmaticamente il focus al suo interno usando il metodo .focus() di JavaScript. Gli utenti di screen reader e tastiera restano bloccati nel contenuto di sfondo, spesso incapaci di trovare o interagire con la dialog.
• Non restituire il focus all’elemento che ha attivato una modale, un drawer o un menu a discesa dopo la chiusura. Restituire il focus all’inizio della pagina o lasciarlo su un elemento ora nascosto costringe gli utenti a rinavigare dall’inizio, facendogli perdere il punto in cui si trovavano in una pagina potenzialmente lunga.
• Inserire contenuti caricati dinamicamente (ad es. un messaggio di errore inline, una notifica toast o una sezione caricata in lazy loading) nel DOM dopo elementi focalizzabili che li precedono visivamente, così che gli utenti da tastiera incontrino i nuovi contenuti fuori sequenza o non li incontrino affatto.
• Usare tabindex='-1' per rimuovere elementi dalla sequenza di tabulazione senza fornire un mezzo alternativo di accesso tramite tastiera. Sebbene tabindex='-1' sia di per sé uno strumento valido (rende un elemento focalizzabile programmaticamente ma lo rimuove dall’ordine naturale di tabulazione), applicarlo in modo errato a controlli di cui gli utenti hanno realmente bisogno equivale di fatto a nascondere tali controlli agli utenti da tastiera.
• Costruire transizioni di route in single-page application che reimpostano il focus sul body del documento o sulla chrome del browser invece di spostarlo sull’intestazione della nuova pagina o su un landmark di salto alla navigazione. Gli utenti sono così costretti a usare Tab attraverso l’intera navigazione a ogni cambio di route.
• Implementare widget personalizzati di carosello o slider in cui la navigazione con i tasti freccia non è implementata e Tab sposta il focus attraverso ogni slide nascosta, costringendo gli utenti a usare Tab attraverso decine di elementi fuori schermo prima di raggiungere i contenuti successivi della pagina.
• Posizionare un link di salto alla navigazione “invisibile” nel DOM che è sempre display:none (anziché nascosto visivamente con una tecnica .sr-only / clip). Un link con display:none è rimosso completamente dall’ordine di tabulazione, senza offrire alcun beneficio, mentre un link di salto implementato correttamente riceve il focus con Tab e diventa visibile, supportando direttamente un flusso di focus logico verso il contenuto principale.
• Nidificare elementi interattivi all’interno di altri elementi interattivi (ad esempio, un <button> dentro un tag <a>), il che produce un comportamento di tabulazione incoerente tra i browser e può far sì che il focus si posizioni più volte sullo stesso controllo logico o lo salti completamente.

Relazione con le Normative di Accessibilità della Turchia

WCAG 2.4.3 Focus Order è direttamente rilevante per la storica legislazione turca in materia di accessibilità: la Circolare Presidenziale 2025/10, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025. Questa circolare stabilisce standard obbligatori di accessibilità web per un’ampia gamma di soggetti pubblici e privati operanti in Turchia, richiedendo la conformità a linee guida riconosciute a livello internazionale — inclusi tutti i criteri di successo WCAG 2.x di Livello A, tra cui il 2.4.3.

La circolare copre un ampio insieme di tipologie di soggetti. Le istituzioni pubbliche — incluse i ministeri, i comuni, le università statali e le agenzie governative — devono raggiungere la piena conformità entro un anno dalla data di pubblicazione della circolare. I soggetti privati nelle categorie coperte devono raggiungere lo stesso livello di conformità entro due anni. Le categorie del settore privato coperte includono piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori privati di servizi sanitari, società di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio, società di trasporto privato e scuole private che operano con autorizzazione del Ministero dell’Istruzione Nazionale (MoNE).

Per tutte queste organizzazioni, un ordine di focus interrotto o illogico non è solo una carenza di usabilità — è una non conformità normativa che può esporre il soggetto a conseguenze legali e amministrative ai sensi delle disposizioni di applicazione della circolare. Si consideri il portale di online banking di una banca turca in cui l’ordine di focus nella schermata di trasferimento fondi salta dal campo dell’importo al pulsante di conferma, bypassando il campo IBAN del beneficiario. Un utente che usa solo la tastiera — magari un cliente con disabilità motoria — potrebbe avviare involontariamente un trasferimento senza aver compilato correttamente tutti i campi obbligatori. Questo scenario rappresenta contemporaneamente un fallimento del criterio WCAG 2.4.3, una violazione dei requisiti della circolare e un potenziale grave danno finanziario per l’utente.

Allo stesso modo, un sito di e-commerce coperto dalla circolare che usa il riordinamento con CSS Grid per mostrare una pagina prodotto visivamente accattivante, ma la cui sequenza di tabulazione salta dalle immagini del prodotto ai link del footer prima di raggiungere il pulsante “Aggiungi al carrello”, sarebbe in violazione diretta del criterio 2.4.3 e quindi non conforme alla circolare. Le scadenze di uno e due anni significano che le organizzazioni dovrebbero trattare la correzione dell’ordine di focus come una priorità nelle loro roadmap di accessibilità — non come un miglioramento rinviabile. Dato che i problemi di ordine di focus spesso derivano da decisioni architetturali sulla struttura del DOM e sui pattern di interazione JavaScript, affrontarli nelle prime fasi del processo di sviluppo è sostanzialmente meno costoso che correggerli dopo il lancio.

L’SDK di overlay di Accsible supporta le organizzazioni nel loro percorso verso la conformità fornendo miglioramenti configurabili alla gestione del focus, ma è importante notare che le soluzioni di overlay funzionano meglio insieme — non al posto — di una corretta struttura HTML semantica e di una gestione responsabile del focus nel codice dell’applicazione stessa. Raggiungere una conformità sostenibile e verificabile con la Circolare Presidenziale 2025/10 richiede che il prodotto sottostante soddisfi il criterio 2.4.3 attraverso pratiche di sviluppo corrette.