WCAG 2.4.11: Focus non oscurato (minimo)

Cosa Significa Questa Regola

WCAG 2.4.11 Focus Not Obscured (Minimum) è un criterio di livello AA introdotto in WCAG 2.2 che affronta un problema di accessibilità comune ma grave: quando un elemento a fuoco è completamente nascosto dietro un altro livello di contenuto nella pagina. Il criterio stabilisce che quando qualsiasi componente dell’interfaccia utente riceve il focus da tastiera, quel componente non deve essere interamente nascosto da contenuto creato dall’autore.

La parola chiave qui è interamente. WCAG 2.4.11 stabilisce la soglia minima — richiede solo che una parte dell’elemento a fuoco rimanga visibile. Se una barra di navigazione fissa sovrappone la metà superiore di un pulsante a fuoco ma la metà inferiore è ancora visibile, tecnicamente questo soddisfa il criterio 2.4.11. Il criterio complementare più rigoroso, WCAG 2.4.12 Focus Not Obscured (Enhanced) di livello AAA, va oltre richiedendo che il componente a fuoco non sia affatto oscurato da contenuto creato dall’autore — nemmeno parzialmente.

I tipi di contenuto creato dall’autore più comunemente responsabili di questo problema includono header e footer adesivi o con posizione fissa, banner per il consenso ai cookie, widget di supporto via chat, notifiche toast, overlay modali, floating action button e barre di navigazione inferiori nei layout responsive per dispositivi mobili. Questi elementi sono resi utilizzando proprietà CSS come position: fixed, position: sticky o valori z-index elevati, che li fanno fluttuare al di sopra del normale flusso del documento e potenzialmente coprire elementi interattivi che ricevono il focus.

Un pass significa che quando un utente di tastiera scorre con Tab gli elementi interattivi, almeno una parte dell’indicatore visivo di ogni elemento a fuoco è visibile sullo schermo in ogni momento — anche se un elemento UI adesivo ne sovrappone una parte. Un fail si verifica quando un elemento a fuoco è completamente nascosto sotto un livello creato dall’autore, il che significa che l’utente non ha alcun segnale visivo su dove si trovi il focus. Il contenuto renderizzato dal browser, come la barra degli strumenti del browser stesso, non è considerato contenuto creato dall’autore ed è quindi escluso dall’ambito di questo criterio. Allo stesso modo, è escluso anche il contenuto che l’utente stesso ha riposizionato (come un pannello trascinabile dall’utente).

Questo criterio si applica a tutti gli elementi HTML interattivi che sono focalizzabili da tastiera per impostazione predefinita o resi focalizzabili tramite tabindex, inclusi <a>, <button>, <input>, <select>, <textarea> ed elementi con tabindex='0' o valori tabindex positivi.

Perché È Importante

La navigazione da tastiera è fondamentale per l’accessibilità per diversi gruppi di utenti. Le persone con disabilità motorie che non possono usare il mouse si affidano interamente a tastiere, dispositivi a sensore o controller a soffio e aspirazione per muoversi all’interno di una pagina web. Le persone cieche usano screen reader in combinazione con la tastiera. Le persone con ipovisione che usano la tastiera senza screen reader dipendono fortemente dall’indicatore di focus visibile per capire dove si trovano. Quando l’elemento a fuoco è nascosto dietro un header adesivo o un widget fluttuante, questi utenti sono di fatto disorientati — devono premere Tab ripetutamente, indovinare la propria posizione o abbandonare del tutto l’attività.

Consideriamo uno scenario concreto reale: una persona in sedia a rotelle con mobilità limitata delle mani sta compilando un modulo di prenotazione di un volo sul sito web di una compagnia aerea turca. Usa il tasto Tab per spostarsi tra i campi del modulo. La pagina ha un banner adesivo per il consenso ai cookie nella parte inferiore della viewport. Quando l’utente passa con Tab alla casella di controllo finale di conferma, la casella di controllo viene renderizzata completamente sotto il banner dei cookie. L’utente non ha alcuna indicazione visiva che la casella di controllo sia a fuoco. Non può capire se la pressione del tasto Tab ha funzionato, se deve premere Tab di nuovo o se la casella di controllo è addirittura obbligatoria. Questa confusione può portare all’abbandono del modulo, a invii mancati o a pressioni ripetute dei tasti che causano azioni indesiderate.

L’impatto va oltre gli utenti con disabilità. Gli utenti esperti che preferiscono la navigazione da tastiera per velocità — sviluppatori, professionisti dell’inserimento dati e utenti avanzati — traggono anch’essi beneficio da una chiara visibilità del focus. Secondo l’Organizzazione Mondiale della Sanità, circa 1,3 miliardi di persone nel mondo vivono con qualche forma di disabilità, e una parte significativa di queste si affida a tecnologie assistive o alla navigazione da tastiera. In Turchia, in particolare, l’Istituto di Statistica Turco (TÜİK) riporta che circa il 12,7% della popolazione ha qualche forma di disabilità, il che si traduce in circa 10 milioni di persone che possono beneficiare direttamente di una migliore gestione del focus sulle piattaforme digitali.

Dal punto di vista aziendale, indicatori di focus oscurati aumentano i tassi di abbandono delle attività, riducono le conversioni ed espongono le organizzazioni a rischi legali e normativi. I siti che non soddisfano questo criterio è probabile che falliscano anche le verifiche di accessibilità richieste dalla legge turca, mettendo a rischio la possibilità di ottenere o mantenere l’ufficiale Erişilebilirlik Logosu (Logo di Accessibilità).

Regole Axe-core Correlate

WCAG 2.4.11 è classificato come criterio che richiede test manuali in axe-core. Non esiste una regola automatizzata di axe-core che rilevi direttamente questa violazione. Comprendere perché gli strumenti automatici non possono segnalare in modo affidabile questo problema aiuta i team a costruire processi di test manuali migliori.

• Test manuale richiesto — Focus oscurato da posizionamento fisso: Gli strumenti automatici non possono rilevare se un elemento a fuoco è visivamente oscurato perché determinarlo richiede il rendering della pagina, il calcolo dei rettangoli di delimitazione di tutti gli elementi fissi o adesivi in fase di esecuzione e il confronto con il rettangolo di delimitazione dell’elemento attualmente a fuoco nel momento in cui riceve il focus. Le dimensioni della viewport, la posizione di scorrimento e lo stato dinamico della pagina (ad esempio se un banner dei cookie è già stato chiuso) influenzano tutti il risultato. Nessuna analisi statica o ispezione del DOM può replicare in modo affidabile questo calcolo visivo in tutti i possibili stati. Axe-core contrassegna questo criterio come manuale perché richiede un tester umano — o uno strumento sofisticato di regressione visiva — che passi effettivamente con Tab attraverso la pagina e osservi se i componenti a fuoco scompaiono dietro livelli sovrapposti.
• Test manuale richiesto — Contenuto overlay dinamico: Molti elementi che oscurano sono iniettati dinamicamente tramite JavaScript dopo il caricamento iniziale della pagina — widget di chat di terze parti, banner di conformità GDPR, pop-in promozionali e menu di navigazione fluttuanti. Gli scanner automatici che analizzano lo snapshot iniziale del DOM potrebbero non rilevare affatto questi elementi, o potrebbero rilevarli in uno stato compresso o nascosto che non riflette l’esperienza reale dell’utente. Il test manuale da parte di un utente di tastiera che interagisce con la pagina nel suo stato completamente renderizzato e dinamico è l’unico modo affidabile per rilevare questi scenari.

Come Testare

1. Esegui prima una scansione automatizzata di accessibilità. Usa axe DevTools (estensione del browser), Lighthouse in Chrome DevTools o una scansione axe-core integrata nella CI per identificare eventuali problemi rilevabili automaticamente nella pagina. Sebbene il criterio 2.4.11 richieda una verifica manuale, una scansione automatizzata può far emergere problemi correlati come indicatori di focus mancanti (2.4.7) o stacking z-index errato che suggerisce elementi sovrapposti. Prendi nota di tutti gli elementi segnalati come potenzialmente problematici prima di iniziare i test manuali.
2. Identifica tutti gli elementi fissi e adesivi nella pagina. Apri gli strumenti di sviluppo del browser e ispeziona il CSS della pagina. Cerca elementi che usano position: fixed o position: sticky. Controlla anche gli elementi con valori z-index elevati (ad esempio 100 o superiori). Documenta ciascuno di questi elementi — header, footer, banner, widget di chat, avvisi sui cookie — poiché sono i candidati più probabili a oscurare i componenti a fuoco. Ridimensiona la finestra del browser per simulare diverse dimensioni di viewport, inclusi tablet e larghezze mobile, poiché gli elementi fissi/adesivi spesso si comportano in modo diverso a seconda dei breakpoint.
3. Esegui una traversata completa con Tab da tastiera. Fai clic al di fuori di qualsiasi elemento interattivo per assicurarti che il focus parta dall’inizio della pagina, quindi premi ripetutamente Tab per scorrere tutti gli elementi focalizzabili. Osserva attentamente ogni elemento quando riceve il focus. Presta particolare attenzione agli elementi che compaiono vicino al bordo superiore o inferiore della viewport, dove è più probabile che header o footer fissi si sovrappongano. Se in qualsiasi momento l’anello di focus visibile o l’elemento evidenziato scompare completamente dietro un livello fisso, si tratta di un fallimento del criterio 2.4.11. Usa Shift+Tab per attraversare anche in senso inverso, poiché la posizione di scorrimento e il layout possono differire.
4. Testa con NVDA e Firefox. Apri NVDA (screen reader gratuito e open-source per Windows) e avvia Firefox. Abilita la modalità browse di NVDA e usa Tab per muoverti nella pagina. Sebbene NVDA annunci ogni elemento a fuoco in modo udibile, osserva anche visivamente lo schermo. Prendi nota di qualsiasi elemento per cui NVDA annuncia il focus ma nessun indicatore visivo di focus è visibile a causa di contenuto che lo oscura. Questa combinazione è ampiamente utilizzata in Turchia e a livello globale e rappresenta un abbinamento chiave di tecnologia assistiva.
5. Testa con VoiceOver e Safari su macOS/iOS. Abilita VoiceOver (Command+F5 su Mac) e usa Tab o i gesti di navigazione di VoiceOver per muoverti tra gli elementi focalizzabili. Su iOS, usa i gesti di scorrimento. Verifica che gli elementi a fuoco siano visivamente presenti e non nascosti sotto livelli UI fissi, in particolare su mobile dove barre di navigazione e banner dei cookie possono occupare una porzione maggiore della viewport.
6. Testa con JAWS e Chrome. Apri JAWS (Job Access With Speech) e usa Chrome. Passa con Tab attraverso tutti gli elementi interattivi e monitora qualsiasi momento in cui il cursore di JAWS si sposta su un elemento che è visivamente nascosto sotto un livello fisso. JAWS è ampiamente utilizzato in ambienti aziendali e governativi, rendendo questa combinazione particolarmente importante per testare siti web del settore pubblico e corporate.
7. Testa dopo interazioni dell’utente che modificano il layout. Chiudi i banner dei cookie, apri e chiudi i menu di navigazione, attiva le notifiche toast e apri i widget di chat. Dopo ogni cambiamento di stato, esegui una nuova traversata con Tab per assicurarti che il nuovo layout non introduca nuovi casi di focus oscurato. Il contenuto dinamico è una fonte comune di fallimenti del criterio 2.4.11 che compaiono solo dopo l’interazione dell’utente.
8. Testa a diverse posizioni di scorrimento. Scorri verso il centro o il fondo di una pagina lunga, quindi passa con Tab attraverso gli elementi in quella regione. Gli header fissi potrebbero non oscurare gli elementi vicino alla parte superiore della pagina ma possono coprire gli elementi che compaiono al bordo superiore della viewport quando l’utente scorre verso il basso. Conferma che nessuna combinazione di posizione di scorrimento ed elemento a fuoco comporti un occultamento visivo completo.

Come Correggere

Header adesivo che si sovrappone ai link a fuoco — Errato

<!-- Sticky header with no scroll offset accommodation -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- No scroll-margin-top set; focused link at top of main scrolls under the header -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

Header adesivo che si sovrappone ai link a fuoco — Corretto

<!-- Fixed header with scroll-margin-top applied to all focusable elements -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ensures the browser scrolls the element into view
       with enough clearance so the fixed header does not cover it -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- In your stylesheet: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- The 70px (header height + 10px buffer) keeps focused elements
     visible below the fixed header when the browser auto-scrolls. -->

Banner dei cookie che copre il campo del modulo in basso a fuoco — Errato

<!-- Cookie banner fixed at bottom with no accommodation for form fields above it -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- This checkbox renders in the viewport area covered by the cookie banner -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Banner dei cookie che copre il campo del modulo in basso a fuoco — Corretto

<!-- Cookie banner pushes page content up instead of overlapping it -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- In your stylesheet: -->
<!-- .cookie-banner-flow { position: static; } instead of position: fixed -->
<!-- Alternatively, if fixed positioning is required for design reasons,
     add scroll-margin-bottom to all focusable elements equal to the
     banner height, or apply padding-bottom to <body> equal to
     the banner height so content is never hidden beneath it. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Widget di chat di terze parti che si sovrappone al pulsante a fuoco — Errato

<!-- Third-party chat widget injected in bottom-right corner
     with a high z-index, obscuring the focused Submit button -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Injected by third-party script, covers 120x120px in bottom-right -->
</div>

<section class='cta-section'>
  <!-- Button positioned in the bottom-right area of the layout;
       when focused, it is completely hidden beneath the chat widget -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

Widget di chat di terze parti che si sovrappone al pulsante a fuoco — Corretto

<!-- Approach 1: Reposition the chat widget to avoid overlapping focusable content -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Widget repositioned to bottom-left, away from the CTA button -->
</div>

<!-- Approach 2: Ensure the button has scroll-margin that keeps it
     clear of the widget when focused -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Approach 3: Use JavaScript to detect focus events on elements
     near the widget's bounding box and temporarily collapse or
     move the widget so the focused element is visible. -->
<script>
  // Example: collapse widget when nearby element gains focus
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Additional logic to reposition or minimize widget
    });
  });
</script>

Errori Comuni

• Applicare position: fixed a header e footer senza aggiungere scroll-margin-top o scroll-margin-bottom agli elementi focalizzabili. Lo scorrimento nativo del focus da parte del browser non tiene conto degli elementi fissi sovrapposti, quindi gli elementi a fuoco scorrono fino al bordo superiore o inferiore della viewport e finiscono nascosti dietro il livello fisso. Una regola CSS globale come * { scroll-margin-top: [header-height]px; } risolve il problema in modo efficiente.
• Impostare body { padding-top: 60px; } per compensare un header fisso ma dimenticare di aggiungere un equivalente scroll-margin-top per il focus da tastiera. Il padding assicura che il contenuto non sia inizialmente nascosto, ma quando il focus da tastiera attiva lo scorrimento automatico del browser, la destinazione dello scorrimento può comunque finire dietro l’header. Entrambi gli approcci devono essere usati insieme.
• Usare z-index: 9999 su banner promozionali o widget di chat senza verificare quali elementi focalizzabili rientrino nella loro area. Un z-index elevato garantisce che l’overlay venga renderizzato sopra tutto, inclusi pulsanti e link a fuoco, rendendolo la causa radice più comune dei fallimenti del criterio 2.4.11.
• Chiudere i banner dei cookie tramite JavaScript senza rimuoverli immediatamente dal layout. Se l’elemento DOM del banner rimane con visibility: hidden o opacity: 0 ma occupa ancora spazio o ha un z-index diverso da zero, può continuare a oscurare visivamente gli elementi a fuoco in alcuni scenari di rendering del browser.
• Incorporare widget di terze parti (live chat, overlay di accessibilità, gestori GDPR) senza verificarne l’impatto sulla visibilità del focus da tastiera. Gli script di terze parti spesso iniettano elementi con posizione fissa e valori di z-index molto elevati. I team devono testare esplicitamente queste integrazioni come parte del processo di QA per l’accessibilità.
• Non testare il criterio 2.4.11 dopo modifiche ai breakpoint responsive. Una barra di navigazione adesiva alta 60px su desktop può espandersi a 120px su tablet quando il menu hamburger è aperto, oscurando improvvisamente un’area molto più ampia e creando nuovi fallimenti a breakpoint che su desktop risultavano conformi.
• Applicare scroll-margin-top solo ai target degli anchor (<h2>, <section>) ma non agli elementi interattivi come <input>, <button> e <a>. L’offset di scorrimento per gli anchor è comunemente gestito, ma lo scorrimento automatico del focus da tastiera verso elementi non anchor è ugualmente interessato e deve essere coperto dalla stessa regola CSS.
• Dare per scontato che, poiché un elemento a fuoco è annunciato da uno screen reader, sia anche visivamente visibile. Gli screen reader accedono all’albero di accessibilità, non al rendering visivo. Un elemento può essere completamente nascosto dietro un overlay fisso pur essendo annunciato correttamente da NVDA o JAWS. Si tratta di due problemi distinti — il criterio 2.4.11 riguarda specificamente la visibilità del focus visivo per gli utenti vedenti che usano la tastiera.
• Trascurare di testare l’oscuramento del focus dopo cambi di route in single-page application (SPA). Nelle app React, Vue o Angular, le transizioni di route spesso ri-renderizzano gli header fissi con stato aggiornato, e la gestione del focus durante la navigazione può posizionare il focus su elementi che vengono immediatamente oscurati da un header adesivo rimontato prima che l’utente veda la nuova pagina.
• Affidarsi esclusivamente a strumenti di test automatizzati e concludere che non esistono problemi relativi al criterio 2.4.11 perché nessuna regola automatica ha segnalato la pagina. Poiché axe-core non ha una regola automatizzata per questo criterio, un report automatico pulito non significa che la pagina sia conforme. Una traversata manuale con la tastiera su tutte le dimensioni di viewport e stati della pagina è obbligatoria.

Relazione con le Normative di Accessibilità della Turchia

WCAG 2.4.11 Focus Not Obscured (Minimum) è direttamente rilevante per il quadro giuridico di accessibilità in via di sviluppo in Turchia. La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce requisiti obbligatori di accessibilità digitale allineati a WCAG 2.2. Questa circolare rappresenta un’espansione significativa dell’impegno della Turchia per l’inclusione digitale e impone obblighi applicabili a un’ampia gamma di soggetti che operano nel mercato digitale turco.

La circolare copre un ampio spettro di organizzazioni, incluse istituzioni pubbliche e agenzie governative, piattaforme di e-commerce, banche e fornitori di servizi finanziari, ospedali e organizzazioni sanitarie, società di telecomunicazioni con più di 200.000 abbonati, agenzie di viaggio, società di trasporto privato e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). Tutti questi soggetti devono garantire che le loro interfacce digitali — siti web, applicazioni mobili e strumenti basati sul web — siano conformi al livello AA di WCAG 2.2.

Poiché WCAG 2.4.11 è un criterio di livello AA in WCAG 2.2, la conformità a questa regola non è facoltativa per i soggetti coperti. Le organizzazioni che intendono ottenere o mantenere l’ufficiale Erişilebilirlik Logosu (Logo di Accessibilità), rilasciato dal Ministero della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı), devono soddisfare la conformità di livello AA. Il Logo di Accessibilità funge da segnale pubblico dell’impegno per l’inclusione digitale ed è sempre più atteso dai consumatori turchi e dagli enti di approvvigionamento governativi.

In termini pratici, ciò significa che i siti web delle istituzioni pubbliche turche con header di navigazione adesivi, i siti di e-commerce con banner promozionali persistenti, i portali bancari con widget di assistenza fluttuanti e i sistemi di prenotazione sanitaria con overlay per il consenso ai cookie devono tutti essere testati e corretti per l’oscuramento del focus ai sensi del criterio 2.4.11. I fallimenti in questo criterio sono particolarmente probabili in interfacce complesse e ricche di elementi di marketing — esattamente il tipo di siti gestiti dalle grandi realtà commerciali coperte dalla circolare.

Le organizzazioni soggette alla circolare dovrebbero integrare il test del criterio 2.4.11 nei loro cicli regolari di audit di accessibilità. Dato che questo criterio richiede test manuali, affidarsi esclusivamente a scansioni automatizzate non soddisferà gli obblighi di due diligence. Si consiglia alle realtà turche che puntano alla piena conformità di eseguire test manuali di traversata con tastiera su tutte le dimensioni di viewport e stati dinamici della pagina come parte della documentazione di conformità, e di affrontare eventuali problemi di oscuramento del focus individuati come parte della roadmap di remediation prima della richiesta o del rinnovo del logo di accessibilità.