WCAG 2.4.13: Aspetto del focus

Cosa significa questa regola

WCAG 2.4.13 Focus Appearance è un criterio di livello AAA introdotto in WCAG 2.2 che stabilisce requisiti precisi e misurabili per l’aspetto visivo degli indicatori di focus da tastiera. Mentre il criterio di livello inferiore 2.4.11 (Focus Not Obscured, livello AA) garantisce che l’elemento con focus non sia completamente nascosto, e il 2.4.7 (Focus Visible, livello AA) richiede semplicemente che esista un qualche indicatore di focus, il 2.4.13 va oltre definendo quanto visibile debba essere tale indicatore.

Per superare questo criterio, l’indicatore di focus da tastiera deve soddisfare tutte le seguenti condizioni:

• Area minima: L’indicatore di focus deve avere un’area almeno pari al perimetro del componente non a fuoco moltiplicato per 2 pixel CSS. In termini pratici, per un tipico pulsante rettangolare, ciò significa che il contorno di focus deve avere un’area uguale o superiore al perimetro del pulsante per 2px — un anello di focus spesso almeno 2px attorno all’intero bordo è sufficiente.
• Rapporto di contrasto dell’indicatore di focus: I pixel che formano l’indicatore di focus devono avere un rapporto di contrasto di almeno 3:1 tra i loro stati con focus e senza focus. Quindi, se un pulsante ha uno sfondo bianco nel suo stato predefinito, l’anello di focus disegnato attorno ad esso deve avere un contrasto di almeno 3:1 rispetto a quello sfondo bianco.
• Nessuna riduzione del contrasto per il contenuto racchiuso: L’indicatore di focus non deve ridurre il contrasto del testo o di altri contenuti all’interno del componente con focus al di sotto di 4.5:1 (per testo sotto 18pt / 14pt grassetto) o 3:1 (per testo grande e contenuto non testuale).

Tutte e tre le condizioni devono essere soddisfatte simultaneamente affinché un componente superi il criterio. Un indicatore di focus sufficientemente grande ma con contrasto insufficiente non è conforme. Allo stesso modo, un indicatore ad alto contrasto ma troppo piccolo non è conforme.

La specifica WCAG definisce un’eccezione importante: se l’indicatore di focus predefinito del browser (il default dell’user agent) soddisfa i requisiti, l’autore non deve aggiungere uno stile personalizzato. Tuttavia, i valori predefiniti dei browser variano in modo significativo — i browser basati su Chromium forniscono generalmente un contorno blu, mentre Safari può renderizzare un anello che manca di contrasto sufficiente in alcuni schemi di colore. Gli autori dovrebbero verificare che l’indicatore predefinito soddisfi la soglia oppure fornire uno stile personalizzato robusto.

Il criterio si applica a tutti i componenti interattivi e focalizzabili: link, pulsanti, campi di input dei form, menu select, checkbox, radio button, componenti di widget personalizzati costruiti con ruoli ARIA e qualsiasi elemento reso focalizzabile tramite tabindex. Si applica anche agli indicatori di focus creati esclusivamente tramite CSS su pseudo-elementi o tramite modifiche di classi controllate da JavaScript.

Perché è importante

La visibilità del focus è un segnale di navigazione fondamentale per un’ampia gamma di utenti. Quando gli indicatori di focus sono sottili, a basso contrasto o del tutto assenti, questi utenti perdono il loro orientamento spaziale all’interno di una pagina — non riescono a capire dove si trovano o dove possono andare dopo.

Utenti che usano solo la tastiera — incluse persone con disabilità motorie come tremori, paralisi o lesioni da sforzo ripetitivo — si affidano completamente alla tastiera per navigare. Per queste persone, un indicatore di focus invisibile o appena percettibile non è solo un inconveniente; rende l’intera interfaccia inutilizzabile. Secondo l’Organizzazione Mondiale della Sanità, circa 1,3 miliardi di persone vivono con qualche forma di disabilità, e le disabilità motorie rappresentano una delle categorie più grandi tra le persone che evitano o non possono usare un mouse.

Utenti ipovedenti che usano software di ingrandimento ma non un lettore di schermo completo dipendono anch’essi dall’anello di focus per orientarsi. A livelli di zoom elevati, un contorno predefinito di 1px può essere tagliato dal viewport o semplicemente invisibile su uno sfondo di colore simile. Questi utenti spesso navigano con la tastiera proprio perché il puntamento preciso del mouse è difficile ad alti livelli di ingrandimento.

Disabilità cognitive e legate all’attenzione come ADHD, disturbi d’ansia e lesioni cerebrali traumatiche possono rendere difficile seguire le informazioni visive su una pagina. Un indicatore di focus altamente visibile e chiaramente differenziato riduce il carico cognitivo della navigazione fornendo un punto di riferimento inequivocabile per la posizione corrente dell’utente.

Anche le disabilità situazionali sono rilevanti: uno sviluppatore che testa su uno schermo di laptop a bassa luminosità all’aperto, o una persona anziana con ridotta sensibilità al contrasto legata all’età, può avere difficoltà con anelli di focus sottili o a basso contrasto anche in assenza di una diagnosi clinica.

Consideriamo uno scenario reale: il modulo online di una banca per il trasferimento di fondi contiene dieci campi di input e quattro pulsanti di azione. Una persona con il morbo di Parkinson scorre il modulo usando la tastiera. Se l’indicatore di focus è un contorno tratteggiato predefinito di 1px in grigio chiaro su sfondo bianco, l’utente non può seguire in modo affidabile quale campo sta modificando. Potrebbe inviare per errore un bonifico al conto sbagliato perché non ha visto che il focus era passato oltre il campo del destinatario. Un contorno di focus robusto e ad alto contrasto avrebbe evitato completamente questo problema.

Oltre all’accessibilità, un indicatore di focus chiaro è un miglioramento di usabilità per tutti gli utenti. Gli utenti esperti che navigano spesso moduli e menu tramite tastiera — un modello comune tra sviluppatori, professionisti dell’inserimento dati e utenti di screen reader — traggono beneficio da un orientamento rapido e affidabile. Esiste anche un segnale SEO indiretto: i siti con una forte accessibilità tendono ad avere tassi di rimbalzo più bassi e maggiore completamento dei task, entrambi fattori correlati a segnali di ranking positivi.

Regole Axe-core correlate

WCAG 2.4.13 richiede test manuali perché gli strumenti automatici non possono valutare completamente la dimensione e il contrasto di un indicatore di focus in ogni possibile contesto di rendering del browser. Axe-core non ha una singola regola automatizzata che segnali direttamente le violazioni del 2.4.13. Le ragioni sono tecniche:

• Perché l’automazione è insufficiente: Calcolare l’area esatta in pixel di un indicatore di focus richiede la simulazione del focus da tastiera su ogni elemento interattivo, la misurazione della geometria del contorno renderizzato (che dipende da browser, sistema operativo, livello di zoom e CSS), il calcolo del rapporto di contrasto dei pixel dell’indicatore rispetto ai loro vicini e la verifica che nessuno di questi violi il requisito di contrasto per il contenuto racchiuso. Nessun motore di accessibilità automatizzato attuale esegue in modo affidabile tutti questi passaggi su tutti i componenti. Axe-core può segnalare l’assenza di qualsiasi stile di focus (relativo al 2.4.7) ma non può misurare se lo stile che è presente soddisfi le soglie di area e contrasto del 2.4.13.
• Copertura parziale tramite regole correlate al focus: La regola focus-visible di axe-core verifica se gli elementi hanno un indicatore di focus visibile. Se un elemento ha outline: none o outline: 0 senza un indicatore visivo alternativo, questa regola lo segnalerà. Tuttavia, superare questa regola non garantisce la conformità al 2.4.13 — un elemento può avere un contorno tecnicamente visibile che è comunque troppo sottile o a contrasto troppo basso.
• Il test manuale è il metodo autorevole: I tester devono ispezionare visivamente ogni componente interattivo in stato di focus, misurare o stimare le dimensioni del contorno e verificare i rapporti di contrasto usando un analizzatore di contrasto dei colori. Per questo motivo WCAG elenca il 2.4.13 come criterio testabile solo manualmente per le finalità di axe-core.

Come testare

1. Scansione automatizzata (solo segnale parziale): Esegui axe DevTools o Lighthouse sulla pagina. Cerca eventuali errori relativi a focus-visible o focus-order-semantics. Sebbene questi non segnalino direttamente violazioni del 2.4.13, possono far emergere elementi in cui lo stile di focus è stato completamente soppresso, che è una violazione preliminare. In Chrome DevTools, apri il pannello Accessibility e usa la modalità di ispezione "Tab" per scorrere gli elementi focalizzabili.
2. Test visivo di navigazione da tastiera: Scollega o metti da parte il mouse. Premi Tab per spostarti tra tutti gli elementi interattivi della pagina. Per ogni elemento con focus, ispeziona visivamente l’indicatore di focus. Chiediti: c’è un anello chiaramente visibile o un altro indicatore? Sembra spesso almeno 2px? Contrasta nettamente con lo sfondo circostante? Annota qualsiasi elemento per cui esiti o fai fatica a vedere dove si trova il focus.
3. Misurazione del contrasto: Usa il WebAIM Contrast Checker o lo strumento desktop Colour Contrast Analyser. Con il focus su un componente, fai uno screenshot. Campiona il colore dei pixel dell’indicatore di focus e il colore dello sfondo immediatamente adiacente. Verifica che il rapporto di contrasto sia almeno 3:1.
4. Misurazione delle dimensioni: Usa i DevTools del browser (Chrome o Firefox). Seleziona un elemento con focus e ispeziona i suoi stili calcolati. Controlla outline-width, outline-offset e qualsiasi box-shadow usato come anello di focus. Moltiplica il perimetro dell’elemento (2 × larghezza + 2 × altezza) per 2px per calcolare l’area minima. Verifica che l’area renderizzata dell’indicatore soddisfi o superi questo valore.
5. Test con screen reader + tastiera (NVDA + Firefox): Apri la pagina in Firefox con NVDA in esecuzione. Naviga usando Tab e i tasti freccia. Conferma che l’indicatore di focus visivo si sposti in sincronia con il focus annunciato da NVDA. Presta particolare attenzione ai widget personalizzati (carousel, modali, accordion) in cui la gestione del focus può essere controllata via JavaScript.
6. VoiceOver + Safari (macOS/iOS): Attiva VoiceOver con Command + F5. Usa Tab per navigare tra gli elementi interattivi. Verifica che il cursore di VoiceOver (il riquadro con contorno nero) non sostituisca un corretto indicatore di focus CSS — la pagina deve fornirne uno in modo indipendente.
7. Test in modalità ad alto contrasto: Su Windows, attiva la modalità High Contrast (Impostazioni → Accessibilità → High Contrast). Ricarica la pagina e ripeti il test di navigazione da tastiera. Alcuni stili CSS di focus vengono sovrascritti dal sistema operativo in modalità ad alto contrasto; verifica che sia ancora presente un indicatore visibile. Usa la media query CSS forced-colors: active per regolare condizionalmente gli stili se necessario.

Come correggere

Contorno predefinito del browser rimosso — Non corretto

<!-- Many stylesheets globally suppress the default focus outline -->
<style>
  * {
    outline: none; /* Removes ALL focus indicators site-wide */
  }
  a:focus, button:focus {
    outline: 0; /* Redundant removal; no replacement provided */
  }
</style>
<button>Submit Payment</button>

Contorno predefinito del browser rimosso — Corretto

<!-- Remove the default only when providing a superior custom indicator -->
<style>
  /* Only suppress default outline when :focus-visible applies, then provide a strong replacement */
  :focus-visible {
    outline: 3px solid #0057b8; /* 3px ensures area requirement is met for typical elements */
    outline-offset: 2px;       /* Offset separates indicator from element edge for clarity */
  }
  /* Respect forced-colors (Windows High Contrast) by using system keywords */
  @media (forced-colors: active) {
    :focus-visible {
      outline: 3px solid ButtonText;
    }
  }
</style>
<button>Submit Payment</button>

Anello di focus a basso contrasto su sfondo colorato — Non corretto

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus {
    outline: 2px solid #3399ff; /* Light blue outline on dark blue background: contrast ratio ~1.4:1 — fails */
  }
</style>
<button class='cta-button'>Book Now</button>

Anello di focus a basso contrasto su sfondo colorato — Corretto

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus-visible {
    /* White outline contrasts strongly against the dark blue button (contrast ~8:1) */
    outline: 3px solid #ffffff;
    outline-offset: 2px;
    /* A dark offset box-shadow behind the white ring ensures contrast against light page backgrounds */
    box-shadow: 0 0 0 5px #0057b8;
  }
</style>
<button class='cta-button'>Book Now</button>

Widget interattivo personalizzato basato su div senza stile di focus — Non corretto

<style>
  .tab-item { cursor: pointer; padding: 12px 20px; }
  /* No :focus or :focus-visible style defined for custom tab */
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Widget interattivo personalizzato basato su div senza stile di focus — Corretto

<style>
  .tab-item {
    cursor: pointer;
    padding: 12px 20px;
    border-radius: 4px;
  }
  /* Explicit :focus-visible style — outline-width 3px with offset meets area threshold */
  .tab-item:focus-visible {
    outline: 3px solid #d4550a; /* 3:1+ contrast against white background */
    outline-offset: 3px;
  }
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Box-shadow sottile usato come indicatore di focus — Non corretto

<style>
  .form-input:focus {
    outline: none;
    /* 1px box-shadow spread: likely too small in area for most input sizes */
    box-shadow: 0 0 0 1px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Box-shadow sottile usato come indicatore di focus — Corretto

<style>
  .form-input:focus-visible {
    outline: none;
    /*
      3px spread provides sufficient area around a typical 300px-wide input.
      #005fcc on white background yields ~5.9:1 contrast — passes both 2.4.13 (3:1) and 1.4.3 (4.5:1).
    */
    box-shadow: 0 0 0 3px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Errori comuni

• Usare outline: none in un CSS reset senza fornire alcun indicatore di focus sostitutivo. Molti CSS reset popolari (versioni meno recenti di Normalize.css, reset personalizzati) rimuovono gli outline in modo indiscriminato. Associa sempre la rimozione a una sostituzione :focus-visible che soddisfi i requisiti di dimensione e contrasto.
• Fornire uno stile di focus solo per :focus ma non per :focus-visible, causando anelli di focus sui pulsanti al clic del mouse che infastidiscono gli utenti vedenti che usano il mouse — portando gli sviluppatori a rimuoverli del tutto invece di usare la corretta distinzione tra pseudo-classi.
• Scegliere un colore dell’anello di focus che corrisponde strettamente al colore di sfondo del componente. Ad esempio, un anello azzurro chiaro #99ccff su uno sfondo bianco #ffffff ha un rapporto di contrasto di circa 1.5:1, ben al di sotto del richiesto 3:1.
• Usare outline-width: 1px su componenti piccoli come pulsanti icona o checkbox. Un anello di 1px attorno a un’icona 24×24px ha un’area di circa 96 pixel quadrati, ma l’area minima richiesta per un elemento 24×24 è (24+24+24+24) × 2 = 192 pixel quadrati — esattamente 2px di spessore. Un contorno di 1px non soddisfa questo calcolo.
• Dimenticare di testare l’aspetto del focus sui widget ARIA personalizzati come role='combobox', role='listbox' o role='slider'. Questi componenti hanno spesso un focus gestito da JavaScript che bypassa le pseudo-classi CSS native se non gestito esplicitamente.
• Applicare uno stile di focus solo ai tag a e button trascurando input, select, textarea e qualsiasi elemento con tabindex='0'.
• Sovrascrivere gli stili di focus in profondità in una libreria di componenti o in un widget di terze parti senza rendersi conto che l’override rimuove l’indicatore visibile. Colpevoli comuni includono kit UI come Bootstrap 4 (che imposta box-shadow su un bagliore sottile) che potrebbe non soddisfare la soglia del 2.4.13.
• Non testare l’aspetto del focus in modalità High Contrast di Windows. Alcune tecniche CSS basate su outline e box-shadow risultano invisibili in modalità High Contrast. Usa il blocco @media (forced-colors: active) per garantire un fallback visibile basato sui colori di sistema.
• Usare outline-offset con un valore negativo molto grande per spostare il contorno all’interno del bordo dell’elemento. Questo può far sì che l’indicatore si sovrapponga allo sfondo dell’elemento, riducendo il contrasto effettivo al di sotto di 3:1.
• Dare per scontato che l’indicatore di focus su un contenitore padre sia sufficiente per gli elementi interattivi figli. Ogni elemento focalizzabile deve soddisfare il criterio in modo indipendente; una riga evidenziata in una tabella non soddisfa il requisito per un link in una cella all’interno di quella riga.

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 serie di soggetti che operano in Turchia. La circolare adotta WCAG 2.2 come standard tecnico di riferimento e impone la conformità al livello AA per i soggetti interessati. WCAG 2.4.13 Focus Appearance è un criterio di livello AAA e pertanto non è direttamente imposto dalla circolare per la conformità standard.

Tuttavia, l’ambito della circolare è molto ampio. I soggetti interessati includono istituzioni pubbliche e agenzie governative, banche e fornitori di servizi finanziari, ospedali e organizzazioni sanitarie, operatori di telecomunicazioni con 200.000 o più abbonati, piattaforme di e-commerce, agenzie di viaggio, aziende di trasporto privato e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). Per tutte queste organizzazioni, dimostrare la conformità al livello AAA sui criteri applicabili — incluso il 2.4.13 — segnala un impegno verso un’accessibilità di livello eccellente che supera la soglia legale.

Esistono motivazioni pratiche e reputazionali perché i soggetti turchi interessati implementino volontariamente il 2.4.13. Le banche e i fornitori di servizi finanziari, in particolare, servono clienti con disabilità motorie che si affidano alla navigazione da tastiera per transazioni sicure. Il portale di online banking di una banca turca che soddisfa il 2.4.13 non solo supera i requisiti normativi, ma riduce anche il rischio di errore da parte dell’utente e dimostra responsabilità sociale d’impresa. Allo stesso modo, gli ospedali e i portali sanitari in cui i pazienti prenotano appuntamenti o accedono alle cartelle cliniche dovrebbero garantire che tutte le persone — incluse le persone anziane con ridotto controllo motorio fine o ipovisione — possano navigare tali interfacce con sicurezza.

Gli operatori di telecomunicazioni con grandi basi di abbonati sono tra i servizi digitali a più alto traffico in Turchia. I loro portali clienti e le applicazioni self-service raggiungono milioni di utenti, inclusa una quota significativa di persone anziane e persone con disabilità. L’implementazione volontaria del 2.4.13 su tutte queste piattaforme garantisce un accesso equo per tutti gli abbonati e posiziona favorevolmente l’operatore in vista di eventuali futuri irrigidimenti normativi che potrebbero estendere l’obbligo di conformità ai criteri AAA.

Per le organizzazioni che mirano a raggiungere la piena conformità WCAG 2.2 AAA — sia per requisiti di procurement, per l’esportazione verso mercati UE soggetti all’European Accessibility Act, sia per politiche interne di accessibilità — l’implementazione del 2.4.13 è una componente necessaria. L’SDK overlay di Accsible fornisce funzionalità configurabili di miglioramento del focus che possono aiutare le organizzazioni a rendere visibili indicatori di focus robusti e conformi in tutte le loro interfacce, integrando le correzioni CSS a livello di autore descritte in questo articolo.