WCAG 2.5.5: Dimensione del bersaglio (avanzata)

Cosa Significa Questa Regola

WCAG 2.5.5 Target Size (Enhanced) è un criterio di livello AAA in WCAG 2.2 che stabilisce una dimensione minima rigorosa per gli elementi interattivi. In particolare, richiede che la dimensione del target — l’area cliccabile o toccabile di qualsiasi componente dell’interfaccia utente — sia almeno di 44 per 44 pixel CSS sia in larghezza che in altezza. Questo si applica a tutte le interazioni basate su puntatore, inclusi clic del mouse, tocchi su schermo e input tramite stilo.

È importante capire cosa costituisce esattamente il "target" in questo contesto. Il target è l’intera area attivabile del controllo, non solo la sua rappresentazione visiva. Un’icona piccola può essere visivamente di 16×16 pixel, ma se il padding circostante espande l’area cliccabile a 44×44 pixel, il criterio può comunque essere soddisfatto. Ciò significa che gli sviluppatori possono usare il padding in modo strategico per soddisfare il requisito senza alterare in modo drastico il design visivo.

Il criterio definisce un pass come qualsiasi elemento interattivo la cui area target misura almeno 44×44 pixel CSS. Si ha un fail quando l’area attivabile di un elemento interattivo scende al di sotto di questa soglia in una delle due dimensioni — ad esempio, un link largo 44 pixel ma alto solo 20 pixel fallirebbe comunque.

WCAG 2.5.5 prevede diverse eccezioni ufficiali in cui il requisito di 44×44 non si applica. Queste sono:

• Spacing: I target sottodimensionati sono accettabili se un offset di spazio sufficiente li separa da tutti gli altri target. Il target deve essere posizionato in modo tale che, se un cerchio di 44×44 pixel CSS fosse centrato su di esso, quel cerchio non intersecherebbe nessun altro target o il riquadro di delimitazione del cerchio 44×44 di un altro target. Questa eccezione impedisce che la regola richieda modifiche al layout quando controlli adiacenti sono intrinsecamente piccoli ma ben distanziati.
• Equivalent: Un controllo alternativo sulla stessa pagina svolge la stessa funzione e soddisfa il requisito di dimensione minima.
• Inline: Il target si trova in una frase o la sua dimensione è altrimenti vincolata dall’interlinea del testo non target. I collegamenti ipertestuali all’interno di un paragrafo di testo, ad esempio, sono esentati perché ridimensionarli interromperebbe il flusso del testo.
• User agent control: La dimensione è determinata interamente dal browser o dal sistema operativo e non può essere modificata dall’autore. I controlli di form nativi del browser nel loro stato non stilizzato possono rientrare in questa categoria.
• Essential: Una particolare presentazione del target è essenziale per le informazioni trasmesse. Si tratta di un’eccezione ristretta per i casi in cui modificare la dimensione del target altererebbe in modo sostanziale il significato o la funzionalità.

Questo criterio è stato introdotto in WCAG 2.2 e sostituisce le precedenti indicazioni, meno rigorose, sui target del puntatore. Il criterio correlato, WCAG 2.5.8 Target Size (Minimum) a livello AA, stabilisce una soglia inferiore di 24×24 pixel CSS con un calcolo basato sulla spaziatura, ma il 2.5.5 rimane il gold standard per un’accessibilità avanzata.

Perché È Importante

Le disabilità motorie e di destrezza colpiscono una parte significativa della popolazione mondiale. Secondo l’Organizzazione Mondiale della Sanità, circa 1,3 miliardi di persone — ovvero il 16% della popolazione mondiale — vivono con una forma di disabilità significativa, con le condizioni motorie e muscoloscheletriche tra le più diffuse. Condizioni come il morbo di Parkinson, il tremore essenziale, la paralisi cerebrale, la sclerosi multipla, l’emiplegia post-ictus e le lesioni da sforzo ripetitivo riducono tutte la capacità di una persona di eseguire movimenti precisi con il puntatore. Su dispositivi mobili, anche utenti senza disabilità possono avere difficoltà con target piccoli quando usano i guanti, quando hanno le mani bagnate o semplicemente quando usano il telefono con una sola mano.

Consideriamo uno scenario concreto reale: una persona con artrite reumatoide sta navigando su una piattaforma di e-commerce turca su un tablet touchscreen per acquistare farmaci. Il flusso di checkout include piccoli pulsanti di opzione, menu a discesa stretti e un pulsante "Conferma ordine" di 24×18 pixel. Ogni tocco errato seleziona l’opzione sbagliata o non fa nulla, costringendo l’utente a riprovare più volte. La frustrazione non è solo un inconveniente — può indurre ad abbandonare completamente l’acquisto, trasformando un fallimento di accessibilità in una perdita diretta di ricavi per l’azienda.

Oltre alle disabilità motorie, target adeguatamente dimensionati avvantaggiano un’ampia gamma di utenti. Le persone anziane sperimentano comunemente una riduzione del controllo motorio fine e un calo dell’acuità visiva allo stesso tempo, rendendo i target piccoli doppiamente difficili. Gli utenti con disabilità cognitive possono impiegare più tempo a posizionare un puntatore e hanno maggiori probabilità di attivare controlli adiacenti se i target sono affollati. Anche gli utenti vedenti e senza disabilità traggono beneficio da target più grandi sui dispositivi mobili — una verità che ha guidato le convenzioni di design nelle principali aziende tecnologiche per anni. Le Human Interface Guidelines di Apple raccomandano un target minimo di tocco di 44×44 punti, e le linee guida di Material Design di Google raccomandano almeno 48×48 pixel indipendenti dalla densità per gli stessi motivi.

Dal punto di vista SEO e di usabilità, la metrica "Interaction to Next Paint" (INP) di Google Core Web Vitals premia le interfacce in cui le interazioni dell’utente vengono registrate in modo rapido e corretto. I tocchi errati causati da target sottodimensionati aumentano i tassi di fallimento dell’interazione, aumentano il tempo necessario per completare i compiti e incrementano i tassi di rimbalzo — tutti segnali che possono influenzare indirettamente il posizionamento nei motori di ricerca. I miglioramenti di accessibilità a livello di puntatore hanno quindi conseguenze aziendali misurabili oltre la conformità.

Regole Axe-core Correlate

WCAG 2.5.5 richiede test manuali. Non esiste una regola axe-core completamente automatizzata che segnali in modo affidabile tutte le violazioni della dimensione del target per questo criterio avanzato. Il motivo per cui gli strumenti automatizzati hanno difficoltà qui è multifattoriale: la dimensione effettiva del target dipende dal layout CSS calcolato, inclusi padding, margini e dimensioni dei pseudo-elementi che variano in base al viewport, al rapporto di pixel del dispositivo e al rendering dinamico. Inoltre, l’eccezione di spaziatura richiede il calcolo dell’offset geometrico tra target adiacenti — un calcolo che richiede l’intero albero di layout renderizzato e un’analisi di prossimità che gli strumenti automatizzati di parsing del DOM non possono eseguire con precisione in tutti i casi. Inoltre, stabilire se un elemento rientra nell’eccezione "inline" o "equivalent" richiede una comprensione semantica e contestuale che va oltre le capacità dei motori di regole automatizzate.

• target-size (axe-core experimental): Axe-core include una regola sperimentale chiamata target-size che verifica gli elementi interattivi rispetto alla soglia WCAG 2.5.8 di livello AA di 24×24 pixel CSS con offset di spaziatura. Sebbene questa regola possa far emergere alcune violazioni minori, non applica la soglia più rigorosa di 44×44 richiesta dal 2.5.5 e può non rilevare violazioni in cui il padding o i pseudo-elementi influenzano l’area di hit renderizzata in modi che lo snapshot del DOM non cattura. Considera qualsiasi risultato di questa regola come un punto di partenza, non come un audit completo.
• Ispezione visiva manuale: Poiché nessuna regola automatizzata copre completamente il 2.5.5, i tester devono ispezionare e misurare visivamente i target interattivi utilizzando gli strumenti di sviluppo del browser, righelli in pixel CSS o estensioni del browser per l’accessibilità. Ciò include la verifica che il padding sia incluso nell’area di hit e che le eccezioni di spaziatura siano realmente soddisfatte — non semplicemente date per scontate.

Come Testare

1. Esegui una scansione automatizzata come base: Apri axe DevTools o Lighthouse in Chrome DevTools sulla pagina da testare. In axe DevTools, filtra i risultati per "target-size" se disponibile tra le regole sperimentali. Prendi nota degli elementi segnalati, ma tieni presente che questa scansione non rileverà tutte le violazioni del 2.5.5 e potrebbe fare riferimento alla soglia 2.5.8 anziché ai 44×44 pixel. Usa l’audit di accessibilità di Lighthouse per cercare avvisi correlati ai target del puntatore.
2. Misura le dimensioni dei target con i DevTools del browser: Apri i DevTools di Chrome o Firefox e usa il pannello Elements per ispezionare ciascun elemento interattivo — pulsanti, link, campi di form, checkbox, pulsanti di opzione, controlli personalizzati e controlli composti solo da icone. Nel pannello degli stili Computed, controlla la larghezza e l’altezza renderizzate. Ricorda che il padding è incluso nel target cliccabile per gli elementi a livello di blocco ma potrebbe non esserlo per gli elementi inline. Verifica che l’area di hit calcolata sia almeno di 44×44 pixel CSS.
3. Usa gli strumenti di accessibilità integrati nel browser: In Chrome DevTools, apri la scheda Rendering e abilita "Emulate a focused page" o usa l’Accessibility Tree per ispezionare gli elementi. In Firefox, usa l’Accessibility Inspector per identificare gli elementi interattivi e confrontare le loro dimensioni del riquadro di delimitazione.
4. Testa su dispositivi touch reali: Collega un dispositivo iOS fisico e testa con VoiceOver attivato (premi tre volte il pulsante laterale per attivarlo). Naviga toccando e usa il rotor per spostarti tra gli elementi interattivi. Prova ad attivare i target piccoli e annota quante volte vengono attivati accidentalmente elementi adiacenti. Ripeti su un dispositivo Android usando TalkBack (scorri verso destra per navigare, tocca due volte per attivare). Presta particolare attenzione ai widget personalizzati costruiti con elementi <div> o <span>.
5. Verifica manualmente le eccezioni di spaziatura: Per qualsiasi target più piccolo di 44×44 pixel che rivendica l’eccezione di spaziatura, disegna un riquadro di delimitazione immaginario di 44×44 pixel centrato su quel target e conferma visivamente che nessun altro elemento interattivo ricade all’interno di quel riquadro. Estensioni del browser o strumenti di overlay che disegnano riquadri di delimitazione possono aiutare in questo.
6. Verifica con tastiera e screen reader: Testa con NVDA + Firefox e JAWS + Chrome spostandoti con il tasto Tab tra tutti gli elementi interattivi. Sebbene il focus da tastiera non testi direttamente la dimensione del target del puntatore, aiuta a identificare se tutti i controlli sono raggiungibili e conferma l’inventario degli elementi rispetto al quale confronterai le dimensioni dei target del puntatore. VoiceOver + Safari su macOS può essere usato per verificare che i controlli personalizzati si annuncino correttamente e abbiano aree di attivazione adeguate quando vengono cliccati con il puntatore.
7. Testa a più dimensioni di viewport: Le dimensioni dei target possono variare tra layout desktop e mobile. Testa a larghezze di viewport di 320px, 768px e 1280px per confermare che i design responsive mantengano il minimo di 44×44 a tutti i breakpoint, in particolare nei menu hamburger, nei caroselli e nelle colonne di azione delle tabelle dati.

Come Correggere

Pulsante solo icona con dimensioni insufficienti — Errato

<!-- A close button rendered as a small SVG icon with no padding.
     The rendered size is approximately 16x16 CSS pixels, far below the 44x44 minimum. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 0;
  cursor: pointer;
}
</style>

Pulsante solo icona con dimensioni insufficienti — Corretto

<!-- Padding is added to expand the hit area to at least 44x44 CSS pixels
     while preserving the visual icon size. The button itself has explicit
     min-width and min-height to guarantee compliance across browsers. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 14px; /* 16px icon + 14px * 2 padding = 44px total hit area */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

Checkbox personalizzata costruita da un div — Errato

<!-- A visually styled custom checkbox that is too small to meet the target size
     requirement. The div has no padding and renders at 20x20 pixels. -->
<div role='checkbox' aria-checked='false' tabindex='0' class='custom-check'></div>

<style>
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  cursor: pointer;
}
</style>

Checkbox personalizzata costruita da un div — Corretta

<!-- The visual box remains 20x20 pixels but is wrapped in a label element
     whose total clickable area is expanded to 44x44 via padding.
     Using a native input element is strongly preferred over role=checkbox
     because it provides built-in keyboard and pointer behavior. -->
<label class='check-wrapper'>
  <input type='checkbox' class='sr-only'>
  <span class='custom-check' aria-hidden='true'></span>
  Subscribe to newsletter
</label>

<style>
.check-wrapper {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 44px; /* entire label row is at least 44px tall */
  cursor: pointer;
  padding: 12px 0; /* vertical padding expands the hit area */
}
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  flex-shrink: 0;
}
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
</style>

Link di navigazione in una toolbar con spaziatura affollata — Errato

<!-- Toolbar links rendered as small inline elements.
     Each link is approximately 32px wide and 24px tall,
     and they are spaced only 4px apart — failing both size and spacing exceptions. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 12px;
  padding: 2px 4px;
  margin: 0 2px;
}
</style>

Link di navigazione in una toolbar con spaziatura affollata — Corretto

<!-- Each link now has padding that expands its hit area to at least 44x44 px.
     The gap between links is also increased so the spacing exception would
     apply even if sizing were relaxed in future. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 14px;
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 16px; /* horizontal padding extends width well past 44px */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

Errori Comuni

• Dare per scontato che il riquadro visivo di delimitazione coincida con l’area di hit: Impostare width: 44px; height: 44px sull’immagine dell’icona all’interno di un pulsante non rende il pulsante 44×44 — solo aggiungere tali dimensioni o un padding equivalente all’elemento <button> stesso crea l’area di hit corretta.
• Usare padding: 0 per azzerare gli stili del browser senza una dimensione minima compensativa: I reset CSS spesso rimuovono tutto il padding da pulsanti e campi di input. Dopo un reset, riapplica sempre un padding sufficiente o valori espliciti di min-width e min-height per ripristinare l’area di attivazione.
• Fare affidamento solo su line-height per aumentare l’altezza del target: Aumentare il line-height influisce sulla spaziatura del testo ma non espande sempre l’area cliccabile di un link o di un pulsante. Usa invece padding-top e padding-bottom.
• Posizionare più piccoli pulsanti a icona uno accanto all’altro senza spaziatura sufficiente: Una fila di icone di condivisione sui social media di 24×24 con margini di soli 2px non soddisfa né il requisito di dimensione né l’eccezione di spaziatura, poiché i cerchi di 44px centrati su ciascuna icona si sovrapporrebbero ai vicini.
• Applicare in modo errato l’eccezione per testo inline ai link di navigazione: L’eccezione si applica ai link all’interno di una frase o paragrafo di testo scorrevole. I menu di navigazione, le toolbar e gli elenchi di link non sono testo inline e non rientrano in questa eccezione, anche se usano display: inline.
• Costruire controlli personalizzati con role='button' su uno <span> e dimenticare di dimensionare lo span: Gli screen reader annunceranno lo span come pulsante, ma la sua dimensione renderizzata predefinita sarà determinata solo dal contenuto testuale, che è tipicamente ben al di sotto di 44×44 pixel. Aggiungi sempre display: inline-flex, min-width, min-height e padding.
• Non testare su dispositivi touch reali alla dimensione effettiva del viewport: Misurare i pixel nei DevTools desktop non è sufficiente. La densità dei pixel CSS e il comportamento di hit-testing dei target touch a livello di sistema operativo possono differire tra ambienti simulati e dispositivi fisici.
• Trascurare i controlli renderizzati dinamicamente: Tooltip, celle dei giorni nei datepicker, elementi di suggerimento negli autocomplete e pulsanti di chiusura dei modali sono spesso iniettati da librerie JavaScript con dimensioni ridotte hardcoded. Verifica l’output dei widget di terze parti e sovrascrivi i loro stili se necessario.
• Invocare l’eccezione di spaziatura senza misurarla: L’eccezione di spaziatura è geometrica e precisa. Supporre visivamente che i controlli sembrino abbastanza distanziati non è sufficiente — il test del cerchio di 44px deve essere applicato a ciascun target sottodimensionato per confermare che non esista sovrapposizione.
• Dimenticare di verificare dopo i cambi di breakpoint responsive: Un pulsante che è 44×44 su desktop può ridursi a 30×30 su un viewport mobile di 375px a causa di larghezze in percentuale o ridimensionamento flexbox. Riesamina sempre le dimensioni dei target a ogni breakpoint principale.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale n. 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce requisiti obbligatori di accessibilità web e mobile basati sullo standard WCAG 2.2. La circolare si applica a un insieme definito di entità che operano in Turchia e stabilisce obblighi legali per la conformità a specifici livelli WCAG.

Le tipologie di entità coperte dalla circolare includono: istituzioni e agenzie pubbliche sia a livello di governo centrale che locale; banche e istituzioni finanziarie regolamentate dalla Banking Regulation and Supervision Agency (BDDK); ospedali e fornitori di servizi sanitari, sia pubblici che privati; operatori di telecomunicazioni con 200.000 o più abbonati; piattaforme di e-commerce al di sopra di specifiche soglie di ricavi o transazioni; agenzie di viaggio che gestiscono servizi di prenotazione online; società di trasporto private che offrono biglietteria o prenotazione digitale; e scuole private e istituzioni educative autorizzate dal Ministero dell’Istruzione Nazionale (MoNE).

WCAG 2.5.5 Target Size (Enhanced) è un criterio di livello AAA e non rientra tra i requisiti minimi obbligatori stabiliti dalla circolare, che si concentra principalmente sulla conformità ai livelli A e AA. Tuttavia, la circolare incoraggia esplicitamente le entità coperte — in particolare quelle che servono il pubblico, i pazienti e gli studenti — a perseguire la conformità AAA quando possibile, riconoscendo che rappresenta una pratica di accessibilità allo stato dell’arte.

Per le organizzazioni in Turchia, implementare WCAG 2.5.5 ha un valore strategico particolare in diversi contesti. I portali governativi che servono cittadini anziani, i sistemi di prenotazione sanitaria utilizzati da pazienti con patologie croniche e le applicazioni bancarie a cui accedono persone con disabilità motorie traggono tutti un beneficio sostanziale da target di 44×44 pixel. La Turchia ha una popolazione che invecchia rapidamente, e l’Istituto di Statistica Turco (TÜİK) prevede che i cittadini di 65 anni e oltre costituiranno oltre il 16% della popolazione entro il 2040 — una fascia demografica per la quale la dimensione del target del puntatore è un fattore di usabilità critico.

Anche laddove il livello AAA non è imposto per legge, le organizzazioni che soddisfano volontariamente WCAG 2.5.5 dimostrano un impegno che può ridurre il rischio di contenziosi, rafforzare l’idoneità agli appalti pubblici che richiedono documentazione di accessibilità e migliorare le metriche di soddisfazione degli utenti in mercati competitivi come l’e-commerce e il fintech. L’SDK di Accsible fornisce funzionalità configurabili di miglioramento dei target touch che possono aiutare le organizzazioni a soddisfare o avvicinarsi a questo criterio, e la documentazione di tali sforzi può far parte di un Accessibility Conformance Report (ACR) o di una submission VPAT richiesta dai processi di procurement istituzionale.