WCAG 2.4.12: Focus non oscurato (avanzato)

Cosa Significa Questa Regola

WCAG 2.4.12 — Focus non oscurato (avanzato) — è la controparte AAA di WCAG 2.4.11 (Focus non oscurato, AA). Mentre il criterio AA consente che un componente con focus sia parzialmente visibile, il criterio AAA richiede che il componente con focus sia interamente visibile — nessuna sua parte può essere nascosta da contenuti creati dall’autore quando riceve il focus da tastiera.

In termini pratici, questo significa che quando un utente si sposta con il tasto Tab su un elemento interattivo come un link, un pulsante, un campo di form o un widget personalizzato, l’intera area di delimitazione di quell’elemento deve essere non oscurata da alcuna intestazione “sticky”, footer fisso, overlay modale, banner dei cookie, widget di chat o qualsiasi altro contenuto che l’autore ha inserito nella pagina. La regola prende di mira specificamente i contenuti creati dall’autore; il W3C prevede un’eccezione esplicita per i contenuti che l’utente stesso ha spostato a coprire l’indicatore di focus — per esempio, un pannello flottante che l’utente ha trascinato davanti all’elemento con focus. In tal caso, l’autore non è responsabile.

Per superare il criterio 2.4.12 è necessario che, al momento in cui riceve il focus, l’intero componente con focus sia visibile all’interno della viewport e non sia coperto da alcun elemento con posizione sticky, fixed o absolute controllato dall’autore della pagina. Si ha un fallimento quando qualsiasi porzione del bordo visibile dell’elemento con focus è nascosta dietro tali overlay — anche un singolo pixel dell’anello di focus o del componente stesso tagliato viene considerato un fallimento a livello AAA.

È importante capire cosa il 2.4.12 non copre. Non impone uno stile particolare per l’indicatore di focus (questo è trattato da 2.4.11 e 2.4.7). Non richiede che gli indicatori di focus abbiano un rapporto di contrasto minimo (coperto da 2.4.13). Affronta specificamente la relazione spaziale tra l’elemento con focus e gli altri contenuti sulla pagina — il problema di stratificazione che nasce più comunemente dall’uso di posizionamenti fixed e sticky in CSS.

Gli elementi HTML interessati includono qualsiasi elemento focalizzabile o raggiungibile con Tab: <a>, <button>, <input>, <select>, <textarea>, <details>, elementi con tabindex e widget interattivi personalizzati costruiti con ruoli ARIA. Il criterio si applica a tutti i contesti di navigazione, inclusi iframe, dialog e transizioni di route nelle single-page application.

Perché È Importante

La navigazione da tastiera è un metodo di accesso primario per un’ampia gamma di utenti. Le persone con disabilità motorie — incluse quelle che vivono con condizioni come SLA, sclerosi multipla, paralisi cerebrale o lesioni da sforzo ripetitivo — si affidano interamente alla tastiera o a dispositivi di accesso a interruttore invece che al mouse. Le persone cieche e ipovedenti che utilizzano screen reader navigano anch’esse tramite tastiera e, sebbene la loro tecnologia assistiva annunci la posizione del focus in modo udibile, gli utenti vedenti che usano la tastiera dipendono completamente dall’indicatore visivo di focus per orientarsi nella pagina.

Quando l’elemento con focus è oscurato, anche solo parzialmente, questi utenti affrontano un’esperienza frustrante e potenzialmente disorientante: la pagina sembra non offrire alcun elemento con focus, oppure l’utente deve indovinare dove si trova nel documento. A livello AA (2.4.11), la visibilità parziale è tollerata — almeno una parte del componente è visibile, fornendo un indizio. Il criterio AAA elimina completamente questo compromesso, riconoscendo che anche un indicatore di focus parzialmente nascosto può essere mancato da utenti con ridotta sensibilità al contrasto, visione tubolare o condizioni cognitive che rendono più impegnativa la scansione dello schermo.

Consideriamo uno scenario concreto: un sito di e-commerce turco utilizza una barra di navigazione fissa alta 80px nella parte superiore della viewport e un banner di consenso ai cookie “sticky” alto 60px in basso. Un utente che preme Tab per navigare tra le schede prodotto può scoprire che il bordo superiore o inferiore della scheda con focus — incluso il suo anello di focus — scivola sotto una di queste superfici fisse. In base a WCAG 2.4.11 (AA), se una qualsiasi parte della scheda è ancora visibile il sito è conforme. In base a 2.4.12 (AAA), l’intera scheda deve essere completamente visibile. Questa distinzione è significativa: un’etichetta di pulsante parzialmente nascosta combinata con un anello di focus parzialmente nascosto può rendere realmente impossibile per un utente ipovedente determinare quale elemento è attivo o quale azione eseguirà.

Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo hanno qualche forma di disabilità visiva, e le disabilità motorie colpiscono centinaia di milioni di persone in più. I miglioramenti all’accessibilità da tastiera avvantaggiano non solo questi gruppi ma anche gli utenti esperti che preferiscono la navigazione da tastiera per velocità, gli utenti su dispositivi privi di puntatore e gli utenti in situazioni in cui il controllo motorio fine è temporaneamente compromesso.

Oltre all’accesso per le persone con disabilità, un focus completamente visibile migliora l’usabilità generale e riduce i costi di supporto. Quando tutti gli utenti — inclusi quelli senza disabilità — possono seguire chiaramente la posizione del focus, i tassi di completamento dei form migliorano e i tassi di errore diminuiscono. Per i siti che si rivolgono al mercato turco, dimostrare la conformità AAA segnala un programma di accessibilità maturo e costruisce fiducia sia presso gli utenti sia presso i team di procurement istituzionali.

Regole Axe-core Correlate

WCAG 2.4.12 è classificato come criterio che richiede test manuali e fa parte delle aggiunte di WCAG 2.2. Non esiste una regola axe-core completamente automatizzata che possa rilevare in modo affidabile questa violazione, e capire il perché è importante per i team che costruiscono le proprie pipeline di test.

• Ispezione manuale — focus-not-obscured-enhanced (nessuna regola automatizzata): Gli scanner di accessibilità automatizzati come axe-core operano sul DOM statico o su uno snapshot dello stato renderizzato. Rilevare se un elemento con focus è oscurato richiede: (1) simulare il focus da tastiera su ogni elemento interattivo in sequenza, (2) calcolare il rettangolo di delimitazione dell’elemento dopo lo scroll indotto dal focus, (3) identificare tutti gli elementi con posizione fixed e sticky e i loro rettangoli di delimitazione e (4) verificare la sovrapposizione geometrica. Sebbene un’automazione parziale sia teoricamente possibile, la natura dinamica del comportamento di scroll, di scroll-padding in CSS, dello smooth scrolling e della gestione del focus tramite JavaScript rende questo approccio altamente inaffidabile nella pratica. Un elemento con focus perfettamente visibile a una dimensione di viewport può essere completamente oscurato a un’altra. axe-core contrassegna questo criterio come richiedente giudizio umano e marca i riscontri come “needs review” anziché come violazioni automatiche. I tester devono scorrere manualmente con Tab ogni elemento interattivo e confermare visivamente la piena visibilità a ciascuna larghezza di viewport rilevante.
• scrollable-region-focusable (regola axe): Pur non essendo mappata direttamente a 2.4.12, questa regola di axe segnala elementi all’interno di regioni scrollabili che sono focalizzabili ma potrebbero non scorrere correttamente in vista. È un segnale correlato che indica problemi di gestione dello scroll che potrebbero causare l’oscuramento del focus da parte di intestazioni o footer “sticky” — la modalità di fallimento più comune per 2.4.12.

Poiché gli strumenti automatizzati non possono rilevare in modo affidabile le violazioni del 2.4.12, le organizzazioni devono integrare walkthrough manuali da tastiera nel proprio processo di QA, idealmente a più dimensioni di viewport e con tutti i layer di UI persistenti (barre di navigazione, widget di chat, banner dei cookie, avvisi GDPR) attivi.

Come Testare

1. Scansione automatizzata di base: Esegui axe DevTools o Lighthouse sulla pagina per identificare eventuali problemi correlati come violazioni di scrollable-region-focusable o problemi di overflow CSS. Questi riscontri, pur non essendo violazioni dirette del 2.4.12, indicano le aree della pagina più propense a causare problemi di oscuramento del focus. In axe DevTools, filtra per i criteri WCAG 2.2 e rivedi tutti gli elementi “needs review” relativi alla visibilità del focus.
2. Identifica tutti i contenuti sovrapposti persistenti: Prima dei test da tastiera, cataloga visivamente ogni elemento con position: fixed o position: sticky nella pagina — tipicamente barre di navigazione, banner dei cookie, widget di chat, pulsanti di azione flottanti e toolbar di footer. Annota le loro altezze e posizioni in modo da sapere quali zone della viewport occupano.
3. Walkthrough di navigazione da tastiera: A partire dalla parte superiore della pagina (o dopo aver chiuso eventuali modali iniziali), premi ripetutamente Tab per spostare il focus attraverso ogni elemento interattivo. A ogni stop del focus, verifica che l’elemento con focus intero — incluso il suo indicatore di focus visibile (contorno o anello) — sia completamente all’interno dell’area non oscurata della viewport. Non accettare la visibilità parziale. Se qualsiasi porzione dell’elemento o del suo anello di focus scompare dietro un elemento fisso, registra questo caso come fallimento del 2.4.12.
4. Navigazione inversa: Ripeti il walkthrough usando Shift+Tab per navigare all’indietro. I footer fissi vengono spesso trascurati nei test solo in avanti ma possono oscurare elementi quando si usa Tab in senso inverso.
5. Test con screen reader NVDA + Firefox: Avvia NVDA, apri Firefox e naviga usando Tab. Quando NVDA annuncia il focus su un elemento, conferma visivamente che l’elemento sia completamente visibile. La modalità focus di NVDA non esegue automaticamente lo scroll degli elementi al di fuori dei layer fissi, quindi le violazioni possono differire dal comportamento nativo del browser.
6. Test con screen reader VoiceOver + Safari (macOS/iOS): Attiva VoiceOver e usa Tab (o lo swipe su iOS) per navigare. La gestione dello scroll di Safari a volte differisce da quella di Chromium, potenzialmente mettendo in evidenza stati di focus oscurati che non si vedono in Chrome.
7. Test della viewport responsive: Ripeti il walkthrough da tastiera ai breakpoint più comuni — 320px, 768px, 1024px e 1440px di larghezza. Gli elementi “sticky” spesso diventano più alti o si riposizionano a breakpoint diversi, modificando le zone a rischio.
8. Test dopo le interazioni dell’utente: Apri menu a discesa, espandi accordion, attiva modali e naviga verso nuove route nelle single-page application. Dopo ogni cambiamento di stato, riprendi la navigazione con Tab e verifica nuovamente la piena visibilità del focus, poiché i contenuti dinamici introducono spesso nuovi overlay fissi.

Come Correggere

Intestazione “Sticky” che oscura i link con focus — Non corretto

<!-- Fixed header with no scroll compensation -->
<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main>
  <!-- When Tab reaches this link near the top of main, the header covers it -->
  <a href='/products'>View all products</a>
</main>

Intestazione “Sticky” che oscura i link con focus — Corretto

<!-- scroll-padding-top ensures focused elements scroll clear of the fixed header -->
<style>
  html {
    /* Match this value to the height of your fixed header */
    scroll-padding-top: 88px; /* 80px header + 8px breathing room */
  }
</style>

<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main style='margin-top:80px;'>
  <!-- Focus now scrolls the element fully clear of the header -->
  <a href='/products'>View all products</a>
</main>

Banner dei cookie che copre elementi interattivi in fondo alla viewport — Non corretto

<!-- Cookie banner fixed to the bottom, no scroll compensation -->
<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- These links at the bottom of the page get covered by the cookie banner -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

Banner dei cookie che copre elementi interattivi in fondo alla viewport — Corretto

<!-- Add scroll-padding-bottom and body padding to compensate for the banner height -->
<style>
  html {
    scroll-padding-bottom: 80px; /* 72px banner + 8px breathing room */
  }
  body {
    padding-bottom: 80px; /* Prevent content from being permanently under the banner */
  }
</style>

<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- Links now scroll fully into the unobscured viewport area -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

Gestione del focus in JavaScript che non tiene conto dei layer fissi — Non corretto

<!-- SPA route change: focus moved to heading but scrollIntoView ignores header -->
<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  heading.focus();
  // scrollIntoView with no offset — heading scrolls behind fixed header
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

Gestione del focus in JavaScript che non tiene conto dei layer fissi — Corretto

<!-- Use scroll-margin-top on the target element, or manually offset scrollY -->
<style>
  .focus-target {
    /* scroll-margin-top offsets this element's scroll position from the top */
    scroll-margin-top: 96px;
  }
</style>

<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  // scroll-margin-top on the element handles the visual offset automatically
  heading.classList.add('focus-target');
  heading.focus();
  // scrollIntoView now respects scroll-margin-top, clearing the fixed header
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

Errori Comuni

• Impostare scroll-padding-top su body invece che su html: La proprietà CSS scroll-padding deve essere applicata al contenitore di scroll. Per lo scroll a pagina intera, il contenitore di scroll è l’elemento html, non body. Applicarla a body non ha effetto nella maggior parte dei browser ed è uno degli errori di implementazione più comuni.
• Impostare in modo rigido un valore in pixel fisso per scroll-padding-top che non corrisponde all’altezza effettiva dell’intestazione a tutti i breakpoint: Quando l’intestazione si riduce a un’altezza minore su mobile o si espande per includere una barra di navigazione secondaria su desktop, l’offset statico diventa errato. Usa proprietà personalizzate CSS aggiornate tramite JavaScript oppure usa calc() con unità relative per mantenere il valore sincronizzato.
• Dimenticare scroll-margin-top sui target degli anchor in-page: Anche quando lo scroll-padding-top globale è corretto per la navigazione con Tab, i target dei link ancora che ricevono il focus programmato (ad esempio, skip link, navigazione tramite hash nelle SPA) possono comunque finire sotto l’intestazione a meno che scroll-margin-top non sia impostato anche su quegli elementi specifici.
• Chiudere il banner dei cookie senza ripetere i test: Molti team testano la navigazione da tastiera solo dopo aver accettato il banner dei cookie. Poiché il banner occupa la parte inferiore della viewport, gli elementi focalizzabili ancorati in basso possono essere oscurati solo mentre il banner è attivo. Esegui sempre i test con tutti i layer di UI persistenti nel loro stato completamente visualizzato.
• Testare solo a una larghezza di viewport: Gli elementi “sticky” spesso cambiano altezza, diventano visibili o scompaiono del tutto a breakpoint diversi. Un fallimento a 375px può non presentarsi a 1440px, e viceversa. Testare a una sola dimensione fa perdere una quota sostanziale di violazioni reali.
• Usare overflow: hidden su un contenitore padre per tagliare gli indicatori di focus: Quando un componente scheda o un contenitore ha overflow: hidden, il contorno di focus predefinito del browser sugli elementi figli viene tagliato al bordo del contenitore. Questo può far sembrare il focus completamente visibile nell’ispezione degli elementi in DevTools mentre è visivamente tagliato per l’utente.
• Dare per scontato che gli screen reader gestiscano automaticamente lo scroll, rendendo superflui i test visivi: Sebbene gli screen reader annuncino l’elemento con focus in modo udibile, gli utenti vedenti che usano la tastiera — inclusi quelli che utilizzano strumenti di ingrandimento dello schermo — si affidano completamente alla posizione visiva. Uno stato di focus visivamente oscurato è un vero fallimento indipendentemente dal comportamento dello screen reader.
• Non testare i dialog modali e gli overlay a cassetto: Quando si apre un modale e il focus viene spostato al suo interno, il backdrop o la cornice del modale stesso possono oscurare il primo elemento con focus all’interno del dialog. Ciò è particolarmente comune nei pannelli in stile “drawer” che si animano entrando dal lato o dal basso.
• Ignorare widget di terze parti come bolle di chat live e banner pubblicitari interstiziali: I widget di chat flottanti (ad esempio, Intercom, Zendesk) e i banner promozionali fissi iniettati dai tag manager sono contenuti creati dall’autore e rientrano nell’ambito di questo criterio. I team spesso li trascurano perché sono gestiti al di fuori del codebase principale.
• Affidarsi esclusivamente alle scansioni di accessibilità automatizzate e chiudere il ticket: Poiché il 2.4.12 richiede test manuali, una scansione axe-core pulita non conferma la conformità. Chiudere i ticket di accessibilità basandosi solo sui risultati automatizzati porterà sistematicamente a mancare questo criterio.

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 adotta WCAG 2.1 Livello AA come standard di conformità di base, il che significa che WCAG 2.4.12 — in quanto criterio AAA di WCAG 2.2 — non è direttamente imposto dall’attuale regolamentazione. Tuttavia, la sua relazione con il quadro normativo turco è significativa per diversi motivi.

I soggetti coperti dalla Circolare Presidenziale 2025/10 includono istituzioni pubbliche e organismi governativi a tutti i livelli, 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 private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). Per tutte queste organizzazioni, raggiungere la conformità a WCAG 2.1 AA è un obbligo legale, e si prevede che la circolare venga applicata tramite meccanismi di audit amministrati dagli organismi di vigilanza competenti.

Sebbene la conformità AAA non sia richiesta dalla circolare, le organizzazioni nei settori regolamentati hanno forti motivazioni pratiche per perseguire la conformità a WCAG 2.4.12. In primo luogo, il panorama normativo turco è in evoluzione: la circolare rappresenta un significativo inasprimento dell’applicazione dell’accessibilità rispetto alle linee guida precedenti, e le revisioni future potrebbero adottare WCAG 2.2 o innalzare il livello di conformità. Le organizzazioni che sviluppano ora pratiche AAA saranno meglio posizionate rispetto ai cambiamenti normativi. In secondo luogo, i processi di procurement pubblico e l’accesso al mercato UE favoriscono sempre più i fornitori che possono dimostrare programmi di accessibilità avanzati, e la documentazione di conformità AAA offre un elemento competitivo distintivo.

In terzo luogo, e in modo più direttamente rilevante per WCAG 2.4.12, il criterio affronta una modalità di fallimento che colpisce in modo sproporzionato gli utenti di tecnologie assistive in Turchia — una popolazione stimata in diversi milioni di persone se si considerano insieme disabilità motorie, visive e cognitive. Banche, ospedali e portali di e-government che si basano fortemente su chrome di navigazione fissi e layer di notifica persistenti sono esattamente i siti in cui i fallimenti di oscuramento del focus sono più comuni. Investire nella piena conformità a WCAG 2.4.12 dimostra un impegno genuino a servire tutti gli utenti, si allinea con lo spirito della circolare presidenziale anche laddove la lettera non lo richiede ancora, e riduce il rischio legale e reputazionale man mano che l’applicazione delle norme in Turchia si consolida.

Per le organizzazioni che utilizzano l’SDK di overlay Accsible, la piattaforma fornisce strumenti per analizzare i percorsi del focus da tastiera e identificare i conflitti dovuti al posizionamento “sticky”, supportando sia i requisiti AA obbligatori della Circolare Presidenziale 2025/10 sia i miglioramenti AAA volontari come WCAG 2.4.12.