WCAG 1.4.13: Contenuto al passaggio del mouse o al focus

Cosa Significa Questa Regola

WCAG 1.4.13 affronta un modello di interazione comune sul web: contenuti che diventano visibili quando l’utente passa il puntatore sopra un elemento o vi sposta il focus da tastiera. Questo include tooltip, sottomenu, suggerimenti in dropdown personalizzati, popover dei selettori di data e qualsiasi altro overlay che appare in risposta a eventi di hover o focus. Il criterio si applica ogni volta che tali contenuti non sono controllati in modo nativo dal browser (per esempio, il tooltip nativo dell’attributo title è esente) e stabilisce tre requisiti fondamentali che devono essere tutti soddisfatti contemporaneamente.

Dismissible (eliminabile): L’utente deve poter chiudere il contenuto aggiuntivo senza spostare il focus del puntatore o il focus da tastiera. Il meccanismo standard per farlo è premere il tasto Esc. Questo impedisce che l’overlay oscuri altri contenuti della pagina in un modo che l’utente non può risolvere — particolarmente critico per gli utenti che hanno ingrandito lo schermo e non possono semplicemente guardare altrove.

Hoverable (mantenibile in hover): Se il contenuto aggiuntivo è apparso perché l’utente ha passato il puntatore sopra un elemento di attivazione, l’utente deve poter spostare il puntatore sul contenuto appena apparso senza che questo scompaia. Se un tooltip svanisce nel momento in cui il cursore lascia l’elemento di attivazione, gli utenti non possono leggere contenuti lunghi, copiare testo da esso o attivare link o controlli al suo interno.

Persistent (persistente): Il contenuto aggiuntivo deve rimanere visibile finché l’evento di hover o focus che lo ha attivato non viene rimosso, l’utente non lo chiude (per esempio tramite Esc) o l’informazione non è più valida. Il contenuto non deve scomparire in base a un timer o dopo un ritardo arbitrario mentre il puntatore o il focus si trovano ancora sull’elemento di attivazione o sull’overlay stesso.

Per superare il criterio è necessario che tutte e tre le condizioni siano soddisfatte. Si ha un fallimento se manca anche una sola condizione — per esempio, un tooltip che scompare quando il puntatore si sposta dall’elemento di attivazione verso il tooltip (non hoverable), oppure uno che si chiude automaticamente dopo tre secondi (non persistent), o uno che non può essere chiuso senza spostare il focus (non dismissible). L’unica eccezione ufficiale prevista da WCAG è quando la presentazione visiva del contenuto aggiuntivo è interamente controllata dall’user agent — i tooltip nativi del browser prodotti esclusivamente dall’attributo title rientrano in questa categoria e sono esenti, sebbene presentino proprie limitazioni in termini di accessibilità.

Perché È Importante

Questo criterio avvantaggia principalmente gli utenti che hanno difficoltà a controllare le interazioni standard con mouse o tastiera, gli utenti che si affidano all’ingrandimento dello schermo e gli utenti che elaborano le informazioni più lentamente. Comprendere chi è interessato aiuta i team a dare la giusta priorità alla correzione.

Utenti con ipovisione spesso utilizzano software di ingrandimento dello schermo come ZoomText o l’ingranditore integrato nel sistema operativo, il che significa che vedono solo una piccola porzione dello schermo a livelli di zoom elevati. Quando appare un tooltip, potrebbe essere parzialmente fuori dallo schermo e l’utente deve spostarsi verso di esso. Se il tooltip scompare nel momento in cui il puntatore lascia l’elemento di attivazione, l’utente non può spostarsi per leggerlo. Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo vivono con qualche forma di deficit visivo, e una parte significativa di coloro che usano il computer si affida all’ingrandimento piuttosto che a un lettore di schermo.

Utenti con disabilità motorie — inclusi persone con morbo di Parkinson, tremori o limitato controllo motorio fine — possono usare dispositivi di puntamento alternativi, puntatori a testa o sistemi di eye-tracking. Il controllo preciso del puntatore è difficile per questi utenti, il che significa che passare da un piccolo elemento di attivazione a un piccolo tooltip senza uscire accidentalmente da entrambi può essere quasi impossibile se l’area di hover non è tollerante. Il requisito hoverable affronta direttamente questo problema.

Utenti con disabilità cognitive possono leggere lentamente o avere bisogno di rileggere i contenuti. Un tooltip che si chiude automaticamente dopo pochi secondi non dà a questi utenti il tempo sufficiente per assimilare l’informazione, e un tooltip che non può essere chiuso senza spostare il focus può intrappolare la loro attenzione in uno stato di interazione confuso.

Consideriamo uno scenario concreto: un sito di home banking mostra i dettagli del tasso di interesse del conto all’interno di un tooltip che appare quando l’utente passa il puntatore sopra una piccola icona informativa. Un utente ipovedente con zoom al 400% vede solo una parte della pagina alla volta. Passa il puntatore sopra l’icona, il tooltip appare e inizia a spostare il puntatore verso il tooltip per leggere le note in piccolo — ma il tooltip svanisce immediatamente perché è legato solo allo stato di hover dell’elemento padre. L’utente non può accedere alle informazioni obbligatorie. Questo non è solo un inconveniente di usabilità; in settori regolamentati può costituire una barriera legale in termini di accessibilità.

Oltre all’impatto specifico sulla disabilità, una corretta implementazione di questo criterio migliora anche l’usabilità generale per tutti gli utenti su dispositivi ibridi touch‑tastiera, riduce le richieste di supporto causate da elementi dell’interfaccia che “scompaiono” e segnala la qualità dell’interfaccia sia agli utenti sia agli auditor.

Regole Axe-core Correlate

WCAG 1.4.13 richiede test manuali. Gli strumenti automatici non possono rilevare in modo affidabile le violazioni perché il criterio riguarda comportamenti basati sul tempo e sul movimento del puntatore che un’analisi statica del DOM non può valutare. Nessuna singola regola di axe-core mappa direttamente a questo criterio, ma le considerazioni seguenti spiegano perché l’automazione non è sufficiente e cosa cercare durante la revisione manuale.

• Test manuale richiesto — comportamento di hover: Gli scanner automatici ispezionano il DOM e il CSSOM in un dato momento; non possono simulare lo spostamento del puntatore da un elemento di attivazione verso un tooltip appena renderizzato e osservare se il tooltip persiste. In teoria uno strumento potrebbe rilevare che una pseudo-classe CSS :hover nasconde un elemento figlio quando il genitore perde l’hover, ma non può distinguere tra una chiusura intenzionale e una violazione del requisito hoverable senza simulare i percorsi del puntatore.
• Test manuale richiesto — chiusura con Esc: Rilevare se la pressione del tasto Esc chiude un overlay richiede una simulazione di eventi JavaScript che va oltre l’attuale set di regole di axe-core. Axe può segnalare ruoli ARIA mancanti sui popup o attributi aria-expanded mancanti, ma non può verificare che un listener keydown per Esc sia collegato a una funzione di chiusura e nasconda effettivamente l’elemento.
• Test manuale richiesto — persistenza / chiusura automatica: Un tooltip che si nasconde tramite una chiamata a setTimeout dopo tre secondi apparirà perfettamente valido in una scansione statica effettuata entro quella finestra temporale. Solo un tester che osserva l’overlay nel tempo — o che esamina il sorgente JavaScript — può identificare un timer di chiusura automatica come violazione.
• Regole axe complementari da eseguire insieme ai controlli manuali: Pur non testando direttamente 1.4.13, l’esecuzione di regole come aria-tooltip-name (per garantire che i tooltip abbiano nomi accessibili), color-contrast (per garantire che il testo del tooltip sia leggibile) e focus-visible (per garantire che gli elementi con focus siano visivamente identificabili) può far emergere problemi correlati che amplificano l’impatto dei fallimenti di 1.4.13.

Come Testare

1. Scansione automatizzata di base: Esegui axe DevTools o Lighthouse sulla pagina che contiene contenuti attivati da hover/focus. Prendi nota di eventuali problemi segnalati relativi a ruoli dei tooltip, contrasto o visibilità del focus — questi non confermano la conformità a 1.4.13 ma stabiliscono una base di partenza. Registra quali elementi attivano contenuti in overlay così da poterli prendere di mira nei passaggi manuali.
2. Identifica tutti i contenuti attivati da hover/focus: Scorri la pagina e passa sistematicamente il puntatore sopra ogni elemento interattivo — pulsanti icona, link con descrizioni aggiuntive, suggerimenti nei campi dei form, voci di navigazione, intestazioni di tabelle dati e punti dati nei grafici. Elenca ogni elemento che fa apparire contenuti aggiuntivi.
3. Testa il requisito hoverable: Per ogni elemento di attivazione identificato, passa il puntatore su di esso per mostrare l’overlay, quindi sposta lentamente il puntatore dall’elemento di attivazione sul contenuto dell’overlay stesso. L’overlay deve rimanere visibile durante tutto questo movimento. Se scompare prima che il puntatore lo raggiunga, il criterio non è soddisfatto.
4. Testa il requisito dismissible: Mentre un overlay è visibile (attivato da hover o da focus da tastiera), premi il tasto Esc. L’overlay deve chiudersi. Se non si chiude, il criterio non è soddisfatto. Esegui questo test con il puntatore ancora sull’elemento di attivazione e anche con il puntatore sull’overlay.
5. Testa il requisito persistent: Attiva un overlay e poi lascia il puntatore fermo sull’elemento di attivazione o sull’overlay per almeno 10–15 secondi. L’overlay deve rimanere visibile per tutto il tempo. Se svanisce, va in timeout o scompare senza azione dell’utente, il criterio non è soddisfatto.
6. Test solo tastiera: Spostati nella pagina usando solo la tastiera con il tasto Tab. Quando il focus arriva su un elemento di attivazione che mostra contenuti aggiuntivi, verifica: (a) che il contenuto appaia, (b) che premendo Esc si chiuda e (c) che il contenuto non scompaia da solo mentre il focus rimane sull’elemento di attivazione. Usa NVDA con Firefox, JAWS con Chrome e VoiceOver con Safari per confermare che i lettori di schermo espongano correttamente il contenuto.
7. Test con ingrandimento dello schermo: Imposta lo zoom del browser al 400% o attiva l’ingrandimento a livello di sistema operativo. Ripeti i test di hover. Conferma che un utente che deve spostare il viewport per raggiungere il tooltip possa farlo senza che il tooltip svanisca.
8. Revisione del sorgente JavaScript: Cerca nel codice setTimeout, mouseleave, mouseout e gestori di eventi blur associati alla logica di nascondimento degli overlay. Conferma che la logica di nascondimento non venga attivata mentre il puntatore è sull’overlay o mentre l’elemento di attivazione mantiene il focus, e che non sia impostato alcun timer di chiusura automatica.

Come Correggere

Tooltip solo CSS che scompare su mouseleave — Non corretto

<!-- Tooltip mostrato solo tramite CSS :hover sul genitore; scompare non appena
     il puntatore si sposta dall’elemento di attivazione verso il testo del tooltip -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip'>This is the tooltip content.</span>
</span>

<!-- CSS (esemplificativo) -->
<!--
.tooltip { display: none; }
.tip-wrapper:hover .tooltip { display: block; }
-->

Tooltip solo CSS che scompare su mouseleave — Corretto

<!-- Corretto: il tooltip è mostrato anche quando il puntatore è sul tooltip stesso
     e lo spazio tra attivatore e tooltip è coperto così che il movimento del puntatore
     non chiuda accidentalmente l’overlay. -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip' role='tooltip' id='tip1'>This is the tooltip content.</span>
</span>

<!-- CSS (esemplificativo) -->
<!--
.tooltip { display: none; position: absolute; }
.tip-wrapper:hover .tooltip,
.tooltip:hover { display: block; }
/* Usa padding o un pseudo-elemento trasparente come ponte tra attivatore e tooltip */
-->

Tooltip JavaScript senza chiusura con tasto Esc — Non corretto

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
// Solo mouseenter/mouseleave — nessuna gestione tastiera o tasto Esc
document.querySelector('button').addEventListener('mouseenter', () => {
  document.getElementById('tip2').removeAttribute('hidden');
});
document.querySelector('button').addEventListener('mouseleave', () => {
  document.getElementById('tip2').setAttribute('hidden', '');
});
</script>

Tooltip JavaScript senza chiusura con tasto Esc — Corretto

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
const btn = document.querySelector('button');
const tip = document.getElementById('tip2');

function showTip() { tip.removeAttribute('hidden'); }
function hideTip() { tip.setAttribute('hidden', ''); }

// Mostra su hover e focus
btn.addEventListener('mouseenter', showTip);
btn.addEventListener('focus', showTip);

// Nascondi solo quando il puntatore lascia SIA l’attivatore SIA il tooltip
btn.addEventListener('mouseleave', (e) => {
  // Breve ritardo per permettere al puntatore di raggiungere il tooltip
  setTimeout(() => {
    if (!tip.matches(':hover') && !btn.matches(':hover')) hideTip();
  }, 100);
});
tip.addEventListener('mouseleave', () => {
  if (!btn.matches(':hover')) hideTip();
});

// Nascondi su blur (tastiera)
btn.addEventListener('blur', hideTip);

// Eliminabile tramite tasto Esc — richiesto da 1.4.13
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape' && !tip.hidden) hideTip();
});
</script>

Tooltip con chiusura automatica tramite setTimeout — Non corretto

<button id='info-btn'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
document.getElementById('info-btn').addEventListener('mouseenter', () => {
  const t = document.getElementById('tip3');
  t.removeAttribute('hidden');
  // Violazione: si chiude automaticamente dopo 3 secondi indipendentemente dallo stato dell’utente
  setTimeout(() => t.setAttribute('hidden', ''), 3000);
});
</script>

Tooltip con chiusura automatica tramite setTimeout — Corretto

<button id='info-btn' aria-describedby='tip3'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
const btn2 = document.getElementById('info-btn');
const tip3 = document.getElementById('tip3');

// Nessun setTimeout — il tooltip persiste finché l’utente non rimuove hover/focus o preme Esc
function show() { tip3.removeAttribute('hidden'); }
function hide() {
  setTimeout(() => {
    if (!tip3.matches(':hover') && !btn2.matches(':hover') && document.activeElement !== btn2) {
      tip3.setAttribute('hidden', '');
    }
  }, 100);
}

btn2.addEventListener('mouseenter', show);
btn2.addEventListener('focus', show);
btn2.addEventListener('mouseleave', hide);
btn2.addEventListener('blur', hide);
tip3.addEventListener('mouseleave', hide);
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') tip3.setAttribute('hidden', '');
});
</script>

Errori Comuni

• Usare solo CSS :hover senza coprire lo spazio tra attivatore e tooltip: Quando c’è anche solo uno spazio di 1–2 px tra l’elemento di attivazione e il contenitore del tooltip, lo spostamento del puntatore tra i due fa perdere lo stato di hover, nascondendo il tooltip prima che l’utente lo raggiunga. Usa un pseudo-elemento trasparente o un padding sovrapposto per colmare questo spazio.
• Collegare la logica di nascondimento a mouseleave sull’attivatore senza verificare se il puntatore si è spostato sul tooltip: Il tooltip scompare nell’istante in cui il cursore lascia l’attivatore, anche se la destinazione è il tooltip stesso. Controlla sempre tip.matches(':hover') prima di nascondere, oppure usa un breve ritardo di debounce.
• Dimenticare di collegare gli eventi focus e blur insieme a mouseenter e mouseleave: Gli utenti che usano solo la tastiera e che arrivano all’attivatore con Tab non vedranno mai il tooltip se vengono gestiti solo gli eventi del mouse, rendendo le informazioni associate completamente inaccessibili senza mouse.
• Non aggiungere un listener per il tasto Esc, presumendo che fare clic altrove sia sufficiente: Gli utenti da tastiera e gli utenti che usano l’ingrandimento dello schermo non possono facilmente “fare clic altrove” per chiudere un overlay. Esc è il meccanismo di chiusura previsto e richiesto da questo criterio.
• Posizionare il listener per Esc solo sull’elemento di attivazione invece che su document: Se l’utente sposta il focus sul tooltip o su un altro elemento, un listener limitato all’attivatore non verrà eseguito. Il gestore per Esc deve essere su document o su un antenato condiviso che riceva sempre gli eventi da tastiera quando l’overlay è aperto.
• Usare setTimeout per chiudere automaticamente i tooltip dopo una durata fissa: Qualsiasi chiusura basata su timer che si attiva mentre il puntatore è ancora sull’attivatore o sul tooltip, o mentre l’attivatore ha ancora il focus da tastiera, è una violazione diretta del requisito di persistenza. Rimuovi tutti i timer di chiusura automatica dagli overlay attivati da hover/focus.
• Attivare la visibilità del tooltip esclusivamente tramite sostituzione dell’attributo title con uno stile personalizzato: Gli sviluppatori che rimuovono il tooltip nativo di title e lo sostituiscono con una versione personalizzata devono implementare autonomamente tutti e tre i requisiti di 1.4.13. L’esenzione per i tooltip nativi del browser non si estende alle riproduzioni personalizzate in JavaScript dello stesso modello.
• Non testare con ingrandimento dello schermo al 400%: Un tooltip che sembra accessibile allo zoom normale può essere parzialmente fuori dallo schermo a livelli di zoom elevati, richiedendo all’utente di spostarsi — e se si chiude prima che l’utente possa raggiungerlo, il test che passava al 100% di zoom fallisce nelle condizioni d’uso reali.
• Applicare pointer-events: none al contenitore del tooltip: Questa proprietà CSS impedisce che il puntatore sia mai considerato “sopra” il tooltip, rendendo impossibile soddisfare il requisito hoverable indipendentemente da altra logica. I tooltip con cui gli utenti potrebbero dover interagire o semplicemente mantenere in hover per tenerli visibili non devono mai avere pointer-events: none.
• Considerare ARIA role='tooltip' da solo sufficiente per la conformità: Aggiungere role='tooltip' e aria-describedby è importante per l’accessibilità con lettore di schermo ma affronta un livello diverso del problema. Questi attributi ARIA non rendono automaticamente il contenuto eliminabile, hoverable o persistente — il comportamento di interazione deve comunque essere implementato esplicitamente.

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 un mandato formale in materia di accessibilità che incorpora per riferimento gli standard WCAG. La circolare richiede ai soggetti interessati di implementare misure di accessibilità web allineate alle linee guida riconosciute a livello internazionale, e la conformità al Livello AA — che include WCAG 1.4.13 — è fortemente incoraggiata e richiesta per i soggetti che intendono ottenere il Logo di Accessibilità (Erişilebilirlik Logosu) rilasciato dal Ministero della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı).

La circolare copre un’ampia gamma di soggetti che operano in Turchia. Le istituzioni pubbliche e gli enti governativi a tutti i livelli amministrativi sono tenuti a rendere accessibili i propri servizi digitali. Nel settore privato, l’obbligo si estende alle piattaforme di e‑commerce, alle banche e ai fornitori di servizi finanziari, agli ospedali e alle strutture sanitarie private, agli operatori di telecomunicazioni con 200.000 o più abbonati, alle agenzie di viaggio, alle società di trasporto privato e alle scuole private che operano con autorizzazione del Ministero dell’Istruzione Nazionale (Millî Eğitim Bakanlığı).

WCAG 1.4.13 è particolarmente rilevante nei contesti digitali turchi in cui i pattern di tooltip e popover sono ampiamente utilizzati nei portali di e‑government (come le integrazioni e‑Devlet), nelle interfacce bancarie e fintech che mostrano informazioni su commissioni o tassi nei tooltip e nei sistemi di prenotazione sanitaria che presentano istruzioni aggiuntive tramite overlay attivati da hover. Una piattaforma bancaria che non rispetta 1.4.13 potrebbe impedire ai clienti ipovedenti di leggere le informative sui tassi di interesse fornite tramite tooltip — uno scenario che ha implicazioni sia in termini di accessibilità sia di tutela dei consumatori di servizi finanziari.

Per i soggetti che perseguono l’Erişilebilirlik Logosu, una verifica di accessibilità includerà test manuali dei comportamenti di hover e focus proprio perché gli strumenti automatici non possono rilevare queste violazioni. Le organizzazioni che utilizzano un SDK di overlay per l’accessibilità come Accsible dovrebbero assicurarsi che qualsiasi tooltip, popover per tour guidati o pannello di aiuto contestuale iniettato dal widget stesso sia pienamente conforme a tutti e tre i requisiti di 1.4.13 — eliminabile tramite Esc, hoverable senza chiusura e persistente fino all’azione dell’utente. Non farlo introdurrebbe nuove barriere attraverso lo stesso strumento pensato per migliorare l’accessibilità, compromettendo sia la conformità normativa sia la fiducia degli utenti.