WCAG 2.4.7: Focus visibile

Cosa Significa Questa Regola

WCAG 2.4.7 Focus Visible richiede che ogni elemento interattivo in una pagina web — link, pulsanti, campi di input dei moduli, widget personalizzati e qualsiasi altro componente utilizzabile tramite tastiera — mostri un indicatore di focus visibile quando riceve il focus da tastiera. In termini semplici, quando un utente preme il tasto Tab per spostarsi all’interno di una pagina, deve poter vedere esattamente quale elemento è attualmente attivo.

Il criterio non impone uno stile visivo specifico per l’indicatore di focus. Richiede solo che avvenga qualche cambiamento visibile. Detto questo, un indicatore appena percettibile — per esempio un contorno tratteggiato di un pixel che si confonde con lo sfondo — può tecnicamente soddisfare il requisito 2.4.7 ma non rispettare il più esigente WCAG 2.4.11 (Focus Appearance) introdotto in WCAG 2.2. Considerando solo il 2.4.7, qualsiasi cambiamento visivo percepibile è sufficiente.

Cosa è considerato conforme: Un indicatore di focus è conforme se un utente vedente che si sposta nella pagina con il tasto Tab può identificare quale elemento è in focus senza dover fare affidamento sugli annunci del lettore di schermo o su altri segnali non visivi. Implementazioni comunemente accettabili includono i contorni predefiniti del browser, regole CSS personalizzate outline o box-shadow, cambiamenti della sottolineatura o del colore di sfondo applicati su :focus o :focus-visible.

Cosa è considerato non conforme: Si verifica un errore quando uno sviluppatore rimuove l’anello di focus predefinito del browser — tipicamente tramite outline: none o outline: 0 in CSS — e non lo sostituisce con un indicatore personalizzato equivalente. Si verificano errori anche quando un componente personalizzato (costruito con elementi <div> o <span>) viene reso focalizzabile da tastiera tramite tabindex ma non riceve alcun cambiamento di stile visibile al focus.

Eccezioni ufficiali: WCAG specifica che il criterio si applica solo alle interfacce utilizzabili tramite tastiera. I componenti puramente decorativi o esplicitamente esclusi dall’ordine di tabulazione (tramite tabindex='-1') non sono tenuti a mostrare un indicatore di focus, perché non possono ricevere il focus tramite la normale navigazione da tastiera.

Perché È Importante

La visibilità del focus è fondamentale per l’accessibilità da tastiera, e l’accessibilità da tastiera è la porta d’accesso per un’ampia gamma di gruppi di persone con disabilità. Circa il 26% degli adulti negli Stati Uniti vive con qualche forma di disabilità secondo il CDC, e molte di queste persone si affidano a tastiere o tecnologie assistive che emulano la tastiera piuttosto che a dispositivi di puntamento.

Utenti con disabilità motorie — incluse persone con condizioni come SLA, paralisi cerebrale, lesioni da sforzo ripetitivo o morbo di Parkinson — si affidano spesso a tastiere, dispositivi a interruttore, controller a soffio e aspirazione o software di tracciamento oculare. Tutti questi metodi di input dipendono dal modello di focus da tastiera del browser. Se l’indicatore di focus è invisibile, queste persone non possono determinare dove si trovano nella pagina, non possono attivare il controllo corretto e possono essere completamente escluse da attività critiche come inviare un modulo, completare un acquisto o navigare in un menu.

Utenti ipovedenti che non usano un lettore di schermo ma possono ingrandire lo schermo dipendono anch’essi dal focus visibile. Quando ingrandiscono una porzione della pagina, l’anello di focus visibile indica quale elemento è attivo e guida la loro interazione.

Anche le disabilità cognitive e legate all’attenzione traggono beneficio da indicatori di focus chiari. Le persone con ADHD o difficoltà di memoria spesso perdono il senso della propria posizione in una pagina complessa; un indicatore di focus ben evidente fornisce un punto di riferimento visivo affidabile.

Uno scenario concreto nel mondo reale: si consideri una persona con sclerosi multipla che naviga in un sito di e-commerce usando solo la tastiera perché la precisione del mouse è diventata difficile. Si sposta con il tasto Tab nella pagina del prodotto per raggiungere il pulsante “Add to Cart”. Se lo sviluppatore ha soppresso l’anello di focus, l’utente non vede alcuna indicazione di dove si trovi il focus. Preme Invio e o non succede nulla (il focus è finito su un elemento non interattivo) oppure viene attivata l’azione sbagliata. Il risultato è frustrazione, abbandono del compito e perdita di entrate per l’azienda — tutto evitabile con una singola regola CSS.

Oltre alla disabilità, gli indicatori di focus avvantaggiano tutte le persone in situazioni in cui l’uso del mouse è scomodo: utenti esperti che navigano con scorciatoie da tastiera, persone che usano un laptop senza mouse esterno e persone che compilano moduli lunghi. Il focus visibile migliora anche la SEO in modo indiretto, incoraggiando l’uso di HTML semantico e di un ordine di tabulazione corretto, entrambi elementi premiati dai crawler dei motori di ricerca.

Regole Axe-core Correlate

WCAG 2.4.7 richiede test manuali perché gli strumenti automatici non possono determinare in modo affidabile se un indicatore di focus è visibile. Axe-core e motori simili possono rilevare l’esistenza di una regola CSS come outline: none, ma non possono valutare il risultato visivo renderizzato in tutti i temi, le modalità ad alto contrasto e i motori di rendering dei browser. Di seguito viene spiegato il panorama dei test:

• Test manuale richiesto — soppressione di focus-visible: Axe-core non include una regola dedicata che segnali in modo definitivo le violazioni del 2.4.7, perché farlo richiederebbe il rendering della pagina, lo spostamento con il tasto Tab su ogni elemento e l’esecuzione di un’analisi di contrasto a livello di pixel sull’indicatore di focus — un compito che va oltre l’analisi statica o a livello di DOM. Invece, chi esegue i test deve spostarsi manualmente con il tasto Tab nella pagina e confermare visivamente che ogni elemento interattivo mostri un cambiamento di focus.
• Segnale parziale da css-orientation-lock e controlli di stile: Alcune configurazioni di axe-core segnalano la presenza di outline: 0 o outline: none nei fogli di stile come avviso di buona pratica, ma si tratta di un euristico, non di un controllo di violazione definitivo, perché la regola può essere sovrascritta da uno stile di focus personalizzato valido altrove nella cascata.
• Perché l’automazione non è sufficiente: Un indicatore di focus può essere nascosto solo in determinati stati (ad esempio, quando una modale è aperta), solo per determinati tipi di elementi o solo in alcuni temi di colore. Questi errori condizionali richiedono che una persona esegua la navigazione di ogni elemento interattivo nell’ambiente effettivamente renderizzato e ne confermi la visibilità. Strumenti come axe DevTools Pro possono aiutare evidenziando gli elementi a cui è applicato outline: none, ma la decisione finale di conformità/non conformità deve essere umana.

Come Eseguire i Test

1. Pre-analisi automatizzata: Esegui axe DevTools (estensione del browser o CLI) o Google Lighthouse sulla pagina. Cerca eventuali avvisi di buona pratica o sperimentali relativi agli stili di focus. Sebbene questi non confermino in modo definitivo una violazione del 2.4.7, mettono in evidenza elementi che meritano un’ispezione. In Lighthouse, controlla la categoria “Accessibility” per i risultati relativi al focus. Esporta il report e annota tutti gli elementi interattivi segnalati.
2. Test manuale di tabulazione da tastiera: Scollega o allontana il mouse. Premi ripetutamente Tab dall’inizio della pagina e naviga attraverso ogni elemento interattivo — link, pulsanti, campi di input, menu a discesa, modali, tab, accordion e selettori di data. A ogni passaggio, conferma che l’elemento in focus sia visivamente distinguibile dai vicini non in focus. Registra qualsiasi elemento in cui l’arrivo del focus non produce alcun cambiamento visibile.
3. Test di tabulazione inversa: Usa Shift+Tab per navigare all’indietro nella pagina e ripeti il controllo visivo. Alcune implementazioni interrompono la visibilità del focus solo in una direzione a causa di problemi di specificità CSS.
4. Test NVDA + Firefox: Apri Firefox con NVDA in esecuzione. Usa la Browse Mode (tasti freccia) e poi passa alla Forms Mode (Invio) per interagire con i controlli dei moduli. Conferma che ogni elemento che NVDA annuncia come in focus mostri anche un indicatore visibile sullo schermo — utile per individuare discrepanze tra il focus dell’AT e il focus del browser.
5. Test VoiceOver + Safari (macOS/iOS): Attiva VoiceOver e usa Tab o VO+Freccia destra per spostarti tra gli elementi interattivi. Verifica visivamente che l’anello di focus sullo schermo corrisponda a ciò che VoiceOver annuncia.
6. Test JAWS + Chrome: Usa JAWS in modalità cursore virtuale e poi in modalità applicazione. Spostati con il tasto Tab tra i controlli interattivi e conferma che l’indicatore di focus visibile appaia su ogni elemento in focus.
7. Test in modalità ad alto contrasto: Attiva la modalità High Contrast di Windows (o Increase Contrast su macOS) e ripeti il test con Tab. Alcuni indicatori di focus si basano su colori che scompaiono nei temi ad alto contrasto; l’indicatore deve rimanere visibile in queste modalità.
8. Ispezione CSS: Apri gli strumenti di sviluppo del browser, seleziona un elemento interattivo, portalo in focus premendo Tab finché non è attivo e ispeziona gli stili calcolati. Verifica che nessuna regola imposti outline: none o outline: 0 senza uno stile di focus compensativo. Controlla anche :focus-visible rispetto a :focus per assicurarti che il focus attivato da tastiera sia coperto.

Come Correggere

Soppressione globale di outline senza sostituzione — Non corretto

<!-- CSS reset che rimuovono tutti gli indicatori di focus globalmente -->
<style>
  * {
    outline: none; /* Rimuove l'anello di focus da ogni elemento */
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>

Soppressione globale di outline senza sostituzione — Corretto

<!-- Rimuovi il reset globale outline: none.
     Fornisci uno stile di focus personalizzato che sia visivamente chiaro. -->
<style>
  /* Rispetta le persone che preferiscono una riduzione dei movimenti */
  :focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>
<!-- Ora entrambi gli elementi mostrano un contorno blu ad alto contrasto quando sono in focus tramite tastiera -->

Pulsante personalizzato basato su div senza stile di focus — Non corretto

<!-- Un div stilizzato come pulsante, reso focalizzabile, ma senza CSS :focus -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  /* Nessuna regola :focus o :focus-visible definita */
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>

Pulsante personalizzato basato su div senza stile di focus — Corretto

<!-- Aggiungi :focus-visible al componente personalizzato in modo che
     le persone che usano la tastiera vedano un indicatore chiaro quando questo elemento è in focus -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  .fake-btn:focus-visible {
    outline: 3px solid #ffcc00;
    outline-offset: 3px;
  }
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>
<!-- Il contorno giallo appare solo con il focus da tastiera, non al clic del mouse -->

Anello di focus nascosto all’interno di una modale — Non corretto

<!-- La modale applica overflow:hidden e un contesto di stacking che
     taglia il contorno predefinito, rendendolo invisibile -->
<style>
  .modal-body {
    overflow: hidden; /* Taglia i contorni che si estendono oltre l'elemento */
    border-radius: 8px;
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Anello di focus nascosto all’interno di una modale — Corretto

<!-- Usa box-shadow invece di outline in modo che venga renderizzato
     all'interno del contesto di stacking e non venga mai tagliato -->
<style>
  .modal-body {
    overflow: hidden;
    border-radius: 8px;
  }
  .modal-body button:focus-visible {
    /* box-shadow non viene tagliato da overflow:hidden --
       rimane all'interno del box dell'elemento -->
    box-shadow: 0 0 0 3px #005fcc;
    outline: none; /* Rimuovi il default per evitare il doppio anello */
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Errori Comuni

• Aggiungere outline: none a un CSS reset di base senza verificare quali elementi ne sono interessati. Molti reset popolari (ad esempio, versioni meno recenti di normalize.css o utility di Bootstrap) sopprimono gli anelli di focus globalmente. Segui sempre con una regola esplicita :focus-visible che ripristini la visibilità per chi usa la tastiera.
• Fare affidamento esclusivamente su :focus quando :focus-visible è più appropriato — o viceversa. Usare solo :focus applica l’indicatore anche ai clic del mouse, il che può apparire strano. Usare solo :focus-visible senza un fallback :focus può lasciare i browser più vecchi senza alcun indicatore. Esegui test in tutti i browser di destinazione.
• Applicare outline: none all’interno di un override di tema di una libreria di componenti senza comprendere la cascata. Un singolo override in un file di tema può cancellare silenziosamente gli indicatori di focus per ogni componente che ne eredita, inclusi i widget di terze parti.
• Usare un colore di focus con contrasto insufficiente rispetto all’elemento o allo sfondo della pagina. Un contorno grigio chiaro su uno sfondo bianco tecnicamente aggiunge un contorno ma può essere impercettibile. Sebbene il 2.4.7 non imponga un rapporto di contrasto specifico, il 2.4.11 sì — e gli indicatori di focus a basso contrasto sono una fonte comune di errori negli audit anche quando gli sviluppatori ritengono di essere conformi.
• Impostare overflow: hidden o clip-path su un contenitore, che taglia il contorno predefinito del browser. La correzione consiste nel passare a indicatori di focus basati su box-shadow, che vengono renderizzati all’interno del box dell’elemento e non vengono tagliati dalle regole di overflow del genitore.
• Dimenticare gli indicatori di focus sugli elementi interattivi all’interno di componenti SVG o Canvas. Tooltip di grafici personalizzati, pulsanti di icone basati su SVG e strumenti di disegno basati su canvas spesso non hanno uno stile di focus nativo. Questi richiedono ruoli ARIA espliciti, tabindex e CSS :focus-visible o un feedback visivo gestito via JavaScript.
• Rimuovere la visibilità del focus solo nel CSS di produzione (ad esempio tramite un post-processor o uno step di build) lasciandola visibile nell’ambiente di sviluppo. Questo porta il team di sviluppo a superare il QA locale pur distribuendo un’accessibilità compromessa alle persone che usano il sito.
• Applicare un indicatore di focus solo all’elemento <a> ma non agli elementi role='link' basati su span usati per i link di navigazione nelle SPA. Ogni elemento focalizzabile da tastiera — indipendentemente dal tag nativo — ha bisogno di uno stato di focus visibile.
• Nascondere gli anelli di focus solo in determinate larghezze di viewport tramite media query, presumendo che le persone su mobile tocchino sempre lo schermo. Le persone che usano tablet con tastiere Bluetooth e chi si affida all’input da tastiera in orientamento orizzontale rimangono senza alcun indicatore di focus.
• Usare JavaScript per chiamare .blur() immediatamente dopo un focus programmato per impedire la comparsa dell’anello di focus. Questo è un errore critico che rimuove completamente la visibilità del focus e non deve mai essere usato come scorciatoia di design.

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 vincolanti di accessibilità web e mobile per un’ampia gamma di soggetti che operano in Turchia. La circolare impone la conformità a WCAG 2.2 a livello AA per le organizzazioni interessate, rendendo WCAG 2.4.7 Focus Visible un requisito direttamente applicabile e non solo una raccomandazione di buona pratica.

I soggetti coperti dalla circolare includono istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e fornitori di servizi finanziari, ospedali e organizzazioni sanitarie, società di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio, società di trasporto privato e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). Per tutte queste organizzazioni, non fornire indicatori di focus visibili nelle proprie interfacce digitali costituisce un problema di non conformità normativa, non solo una carenza di usabilità.

L’Erişilebilirlik Logosu (Logo di Accessibilità), rilasciato dal Ministero della Famiglia e dei Servizi Sociali, funge da marchio ufficiale di certificazione che i soggetti interessati possono esporre per dimostrare la conformità. Ottenere l’Erişilebilirlik Logosu richiede il superamento di un audit formale a WCAG 2.2 livello AA. WCAG 2.4.7 è uno dei criteri di livello AA che gli auditor valuteranno, tipicamente tramite test manuali con tastiera come descritto nella sezione sui test sopra. Un’organizzazione il cui sito sopprime gli anelli di focus o non implementa un focus visibile sui componenti personalizzati non supererà l’audit richiesto per il logo.

Per le piattaforme di e-commerce turche in particolare, la visibilità del focus ha implicazioni commerciali dirette: i siti accessibili raggiungono una base di utenti più ampia, incluse le persone con disabilità motorie che fanno acquisti esclusivamente tramite tastiera o accesso a interruttore, e la conformità alla Circolare Presidenziale 2025/10 protegge le organizzazioni da azioni amministrative. Integrare pattern focus-visible nella libreria di componenti fin dall’inizio — invece di intervenire a posteriori dopo un audit — è il percorso più conveniente per mantenere l’Erişilebilirlik Logosu e soddisfare gli obblighi di accessibilità della Turchia.