Se un sito si usa con la tastiera ma il focus si perde o non si vede, per l’utente il percorso si rompe lo stesso. Io la metto così: la navigazione da tastiera dice se una persona può arrivare ai comandi; la gestione del focus dice se capisce dove si trova mentre li usa.
Dal 28 giugno 2025, con l’entrata in applicazione in Italia della Direttiva UE 2019/882, questo tema non riguarda solo i team tecnici. Riguarda anche chi gestisce lead generation, prenotazioni, e-commerce e moduli contatto. Basta un solo punto bloccato per fermare un acquisto o una richiesta.
In pratica, io controllo sempre questi 5 punti:
- si arriva a tutti gli elementi con Tab
- il focus è sempre visibile
- l’ordine di tabulazione segue un senso chiaro
- modali, menu e popup non intrappolano la tastiera
- dopo chiusure o errori, il focus torna nel punto giusto
Detto in modo semplice: la tastiera serve per muoversi e attivare. Il focus serve per non perdere l’orientamento.
Quick Comparison
| Aspetto | Gestione del focus | Navigazione da tastiera |
|---|---|---|
| Cosa controllo io | Dove va il focus e se si vede | Se raggiungo e uso i componenti |
| Segnali di errore | Outline assente, focus perso, focus nascosto | Elementi non cliccabili da tastiera, trap, menu solo hover |
| Esempi tipici | Modale che non restituisce il focus | <div> usati come pulsanti senza supporto tastiera |
| Impatto | Confusione, errori, stop nel flusso | Blocco diretto dell’interazione |
Un dato conta più di tutto: gli strumenti automatici non trovano molti di questi problemi. Per questo, io parto sempre da un test semplice: uso il sito solo con la tastiera e provo a finire un’azione completa.
Cosa significa gestire il focus nella pratica
Andiamo sul pratico: qui conta come si muove il focus, non solo la sua definizione.
Il focus è l’elemento attivo in un certo momento: un campo, un pulsante o un link che si può selezionare. Gestire il focus significa stabilire dove va, quando cambia e se resta ben visibile.
Il punto critico arriva quando questa logica non coincide con ciò che la persona vede sullo schermo.
In un modulo, per esempio, un ordine prevedibile riduce errori e pause inutili durante la compilazione.
Ordine del focus, stati visibili e spostamenti programmatici
Il browser segue l’ordine del DOM. Quindi, se il layout visivo viene spostato via CSS senza allineare anche il markup, il focus seguirà il codice, non l’ordine che l’utente percepisce.
Se il flusso naturale non basta, conviene intervenire solo con regole chiare e limitate.
Usa tabindex="0" per inserire nel flusso un elemento che di base non riceve il focus. Usa tabindex="-1" per raggiungerlo via script. Meglio evitare i valori positivi: cambiano l’ordine naturale e rendono il percorso fragile.
Togliere l’outline senza una soluzione alternativa porta a una non conformità rispetto al criterio WCAG 2.4.7. Per questo, :focus-visible è una buona scelta: mostra l’indicatore solo quando la navigazione avviene da tastiera.
Lo stesso vale per i componenti dinamici. Il focus deve entrare, restare leggibile e poi tornare al punto di partenza. Quando si apre una modale, il focus va spostato al suo interno con JavaScript; quando si chiude, deve tornare al pulsante che l’ha aperta. Se questo passaggio manca, l’utente perde il filo.
Errori di focus comuni nei siti aziendali
Gli errori più comuni nei siti aziendali nascono in casi in cui il focus esiste, ma non si vede oppure si comporta in modo inatteso.
Per dire: un’intestazione fissa (sticky header) può coprire l’elemento attivo. Il focus c’è, ma finisce nascosto sotto la barra di navigazione, con una violazione del criterio WCAG 2.4.11. I banner cookie possono bloccare il focus al loro interno senza una via d’uscita chiara. Dopo la chiusura di una finestra modale, il focus a volte non torna al pulsante di apertura ma si perde del tutto, costringendo la persona a ripartire da capo. E poi ci sono i popup automatici: si aprono, spostano il focus e spezzano l’interazione nel momento peggiore.
sbb-itb-bc3fb49
Cosa copre la navigazione da tastiera
Se il focus indica dove si trova l’utente, la navigazione da tastiera dice una cosa ancora più pratica: se quella persona può andare avanti oppure no.
Navigare da tastiera vuol dire usare un sito senza mouse. Menu, filtri, accordion, form, carrelli e checkout devono rispondere ai comandi da tastiera. Basta un solo punto bloccato e tutto il percorso si spezza.
Il nodo, in pratica, è questo: capire quali elementi si possono raggiungere, attivare e chiudere senza toccare il mouse.
Tasti, HTML semantico e componenti raggiungibili
L’HTML semantico è la strada più semplice per rendere un sito navigabile da tastiera. Elementi come <button>, <a> e <input> funzionano già con la tastiera grazie al browser.
I guai iniziano quando si usano elementi non semantici come <div> o <span> per costruire pulsanti o link. Da soli, questi elementi non ricevono il focus e non rispondono ai tasti, a meno che il supporto non venga aggiunto a mano via codice. Un menu a tendina costruito con <div> e gestito solo con onclick, per esempio, resta di fatto fuori dalla navigazione da tastiera.
Lo skip link è spesso il primo intervento da fare. Taglia il numero di pressioni su Tab per arrivare al contenuto principale, rende il percorso più rapido e cambia parecchio l’esperienza di chi usa la tastiera tutti i giorni.
Problemi di navigazione che bloccano gli utenti
Quando questi comandi non funzionano, il problema smette subito di essere teorico.
Il caso più grave è la keyboard trap: l’utente entra in un componente, come un widget video o un calendario, e poi non riesce più a uscirne usando la tastiera.
Ci sono poi i menu che si aprono solo al passaggio del mouse (hover). Chi naviga da tastiera non riesce a raggiungerli e può restare tagliato fuori da intere sezioni del sito. Lo stesso succede con i controlli personalizzati che rispondono solo al clic del mouse: pulsanti costruiti con <div>, filtri stilizzati che hanno perso il supporto nativo, step di checkout che non avanzano con Invio.
Qui il punto non è la visibilità del focus. Il punto è semplice: l’interfaccia non si lascia usare.
Gestione del focus vs navigazione da tastiera: differenze e come lavorano insieme
Focus Management vs Keyboard Navigation: Key Differences
Ora che i due problemi sono separati, vale la pena metterli uno accanto all’altro nei punti che contano sul serio.
Navigazione da tastiera e gestione del focus non sono la stessa cosa. La prima serve a raggiungere e attivare gli elementi dell’interfaccia. La seconda stabilisce quale elemento è attivo e come far sì che resti visibile quando la UI cambia.
È proprio qui che si capiscono meglio i problemi visti prima: modali, menu e campi nascosti.
Confronto tra ruoli, metodi e rischi
| Aspetto | Gestione del focus | Navigazione da tastiera |
|---|---|---|
| Obiettivo principale | Controllare quale elemento ha l’attenzione e mantenerla visibile | Permettere all’utente di raggiungere e attivare ogni elemento |
| Tecniche tipiche | element.focus(), :focus-visible, ritorno del focus nei flussi dinamici |
HTML semantico, ordine logico, elementi raggiungibili da tastiera |
| Errori comuni | Rimuovere l’outline; perdere il focus dopo la chiusura di un modale | Elementi <div> non raggiungibili; menu accessibili solo con hover |
La differenza si vede bene quando questi due aspetti finiscono nello stesso flusso.
Come i due concetti lavorano insieme nei flussi reali
Modale. La tastiera consente di spostarsi tra i controlli interni. Ma se il focus non è gestito bene, l’attenzione può uscire dal dialogo oppure finire in un punto senza senso. Con una buona gestione del focus, il cursore entra nel modale quando si apre, resta lì durante l’interazione e torna al pulsante iniziale quando si chiude. In pratica, la tastiera rende possibile l’azione; il focus decide dove va l’azione dopo.
Checkout. La tastiera serve per compilare e inviare il modulo. Il focus, invece, porta subito al messaggio di errore o di conferma, così l’utente non deve mettersi a cercare cosa sia cambiato nella pagina.
Presi da soli, non bastano. La navigazione da tastiera rende possibile l’uso dell’interfaccia; il focus management rende chiari i passaggi dinamici. Per questo vanno controllati insieme: prima l’accesso, poi l’orientamento.
Verifiche pratiche e prossimi passi per i siti italiani
A questo punto, la differenza tra focus e tastiera va provata sul sito. Non basta averla chiara in teoria.
Una checklist di base prima della pubblicazione
Il test più utile è anche il più diretto: usa il sito solo da tastiera. Prova a portare a termine un acquisto, una prenotazione oppure l’invio di un modulo senza toccare il mouse.
Controlla questi punti, in questo ordine:
- Focus sempre visibile: nessun
outline: nonesenza un’alternativa visibile. - Ordine di tabulazione logico: il tasto Tab deve seguire un ordine sensato, senza forzature CSS.
- Nessuna trappola da tastiera: da ogni componente si deve poter uscire usando la tastiera.
- Ripristino del focus: dopo una modale o un menu, il focus deve tornare al trigger.
- Skip link presente: il primo focus utile deve essere uno skip link.
Se il percorso si blocca, controlla subito quale elemento ha il focus. Puoi usare document.activeElement nella console: mostra l’elemento attivo.
Punti chiave
La gestione del focus decide dove cade l’attenzione dell’utente e la tiene visibile quando l’interfaccia cambia. La navigazione da tastiera permette invece di raggiungere e attivare ogni elemento.
Servono entrambe. E vanno testate insieme, non una per volta, su ogni pagina critica: homepage, moduli di contatto, flussi di prenotazione e checkout.
Se questi controlli vanno a buon fine, l’interfaccia risulta molto più solida.
FAQs
Quando è necessario gestire il focus con JavaScript?
La gestione del focus con JavaScript entra in gioco quando un’interazione dinamica cambia il contenuto della pagina e bisogna spostare il focus in modo programmatico.
Per dirla in modo semplice: se la pagina cambia “sotto gli occhi” dell’utente, il focus non può restare lì per caso.
Per esempio, serve:
- quando si aprono modali, dialoghi o messaggi;
- quando si chiudono, per riportare il focus all’elemento che li ha attivati;
- quando bisogna confinare il focus dentro componenti attivi o ripristinarlo su elementi prima nascosti o inattivi.
È uno di quei casi in cui JavaScript fa da guida: accompagna l’utente nel punto giusto, invece di lasciarlo in una parte della pagina che, di colpo, non ha più senso.
Come capisco se l’ordine di Tab è sbagliato?
Il modo più affidabile è usare la pagina solo con la tastiera: premi Tab per andare avanti e Shift + Tab per tornare indietro. In condizioni normali, il focus dovrebbe seguire l’ordine di lettura naturale: da sinistra a destra e dall’alto verso il basso.
C’è un problema quando il focus salta in punti inattesi, non rispetta la disposizione visiva della pagina oppure finisce dietro elementi fissi o finestre modali. Quando succede, orientarsi diventa difficile e l’esperienza si fa confusa in pochi secondi.
Quali pagine devo testare per prime da tastiera?
Parti dall’intera pagina: usa Tab e Shift+Tab dalla barra degli indirizzi e controlla che link, pulsanti, campi e widget ricevano il focus in un ordine logico.
Poi passa agli elementi più delicati. Dai precedenza a modali, menu a tendina e pop-up, agli skip link e ai widget composti come tab, slider e radio button. In questa fase, verifica anche che il focus resti ben visibile e non finisca nascosto.
