Normative · WCAG 2.2

SC 2.4.11 Livello AA WCAG 2.2 Nuovo nella 2.2

Focus non oscurato (minimo)

Quando un elemento riceve il focus da tastiera, non deve essere completamente nascosto da un altro elemento di interfaccia — intestazioni fisse, banner per i cookie, widget di chat, footer fissi. Novità di WCAG 2.2 che sta ridisegnando il modo in cui i team gestiscono l'interfaccia persistente.

Cosa richiede

Quando un utente porta il focus con Tab su un controllo, almeno una parte di quel controllo deve rimanere visibile. Il pattern di fallimento più comune: un utente naviga con Tab oltre un’intestazione fissa, la pagina scorre automaticamente in modo che il link focalizzato finisca dietro la barra fissa, e l’utente non riesce più a vedere l’anello di focus. Il controllo ha ancora il focus e risponde ancora al tasto Enter, ma l’utente non può vederlo.

Il criterio di successo fissa una soglia minima: l’elemento focalizzato può essere parzialmente coperto, purché non sia completamente nascosto. Il livello AAA del criterio 2.4.12 innalza il requisito a «non oscurato affatto».

Questo è uno dei quattro nuovi criteri di successo sull’utilizzabilità introdotti in WCAG 2.2 e ha avuto un impatto significativo perché le intestazioni fisse, i footer fissi, i banner per i cookie e le bolle dei widget di chat sono ormai ovunque.

Come soddisfarlo

  • Aggiungere la proprietà CSS scroll-margin-top agli elementi attivabili con un valore pari all’altezza dell’intestazione fissa, in modo che i browser scorrano automaticamente il controllo focalizzato oltre l’intestazione.
  • Per i footer fissi e le bolle di chat, assicurarsi che non coprano completamente nessun elemento attivabile. Ridurli al focus oppure ancorarli in modo da lasciare un margine al bordo della pagina.
  • Banner per i cookie e overlay rimovibili: evitare di renderli fissi in un modo che intrappoli successivi punti Tab al di sotto. Renderli modali (con trap del focus) oppure non bloccanti.
  • Per le pagine con sia un’intestazione fissa che un footer fisso, testare la sequenza Tab attorno al centro verticale del viewport — è lì che l’elemento focalizzato viene compresso.
  • Usare scroll-padding-top sul contenitore di scorrimento come soluzione alternativa per i browser meno recenti.
html { scroll-padding-top: 80px; }       /* corrisponde all'altezza dell'intestazione fissa */
:target, :focus { scroll-margin-top: 80px; }

Errori comuni

  • Intestazione fissa senza compensazione scroll-padding: ogni Tab nella metà superiore del viewport nasconde l’anello di focus.
  • Banner di consenso ai cookie fissato in basso che copre l’ultima riga di campi modulo quando quei campi ricevono il focus.
  • Bolla del widget di live chat in basso a destra che si sovrappone a un pulsante «Invia» nell’angolo di un modulo.
  • Barre fisse promozionali (banner del Black Friday) aggiunte dai team marketing senza aggiornare i token scroll-padding.
  • Intestazioni di tabella fisse nelle dashboard in cui Tab sulla prima riga di dati finisce dietro la riga di intestazione.

Perché è importante

Questo criterio di successo risolve una categoria di bug che frustra gli utenti di tastiera quotidianamente ma che raramente emerge nelle scansioni automatiche — nessuna regola di axe può prevedere a quale posizione di scorrimento un elemento fisso si sovrapporrà a un elemento focalizzato. Colpisce in modo sproporzionato gli utenti di screen magnifier, il cui viewport visibile è già ridotto a un quarto dello schermo, quindi l’elemento fisso occupa una quota ancora maggiore.

Il criterio 2.4.11 sarà probabilmente tra i risultati più citati nei rapporti di audit del 2026. La correzione è semplice (pochi token CSS) ma richiede che ogni team responsabile di un elemento fisso — intestazione, footer, banner, widget — coordini il proprio lavoro.