WCAG 2.5.8: Dimensione del bersaglio (minima)

Cosa significa questa regola

WCAG 2.5.8 Target Size (Minimum) è un criterio di successo di livello AA introdotto in WCAG 2.2. Stabilisce che la dimensione del target per gli input di puntatore deve essere almeno 24×24 pixel CSS, con un’importante eccezione: se il target stesso è più piccolo di 24×24 pixel CSS, allora deve esserci un sufficiente spazio di offset intorno ad esso in modo che l’area totale — inclusa la spaziatura — raggiunga la soglia di 24×24 in ogni direzione. In altre parole, il riquadro di delimitazione del target più qualsiasi spazio bianco adiacente privo di altri target deve complessivamente raggiungere 24 pixel CSS in orizzontale e 24 pixel CSS in verticale.

Il criterio si applica a qualsiasi elemento che può ricevere un evento di puntatore: link (<a>), pulsanti (<button>), checkbox, radio button, controlli select, slider, widget personalizzati con listener di eventi di puntatore e qualsiasi elemento a cui sia assegnato un ruolo ARIA che implichi interattività. Non si applica a elementi non interattivi come immagini decorative o testo statico, anche se di grandi dimensioni.

Un target rispetta questo criterio quando è vera almeno una delle seguenti condizioni:

• La dimensione renderizzata del target è almeno 24×24 pixel CSS in entrambe le dimensioni.
• Il target è più piccolo di 24 pixel CSS in una o entrambe le dimensioni, ma l’offset tra il bordo del target e l’elemento interattivo adiacente più vicino è sufficientemente ampio affinché l’area combinata target+offset sia almeno 24×24 pixel CSS.
• Il target è un elemento inline all’interno di una frase o di un blocco di testo, che è esplicitamente escluso perché il reflow di tali target interromperebbe la lettura.
• La dimensione visiva del target è determinata interamente dal foglio di stile predefinito user-agent del browser e l’autore non l’ha modificata — questa è l’eccezione per i controlli nativi.
• Esiste una presentazione non interattiva delle stesse informazioni e il target piccolo è semplicemente un’alternativa, non l’unico mezzo di attivazione.

Un target non rispetta il criterio quando è più piccolo di 24×24 pixel CSS e non c’è sufficiente spazio di offset a compensare, e nessuna delle eccezioni sopra si applica. Errori comuni nel mondo reale includono piccoli pulsanti composti solo da icone (come un’icona di chiusura 16×16 in una modale), link di navigazione molto ravvicinati con padding minimo e righe di icone di condivisione social in cui ogni icona è renderizzata a 20×20 pixel con solo 2px di margine tra di esse.

Vale la pena notare che WCAG 2.5.8 è un requisito minimo. Il criterio AAA correlato 2.5.5 Target Size (Enhanced) richiede almeno 44×44 pixel CSS senza eccezione per lo spazio di offset, e molte linee guida di usabilità raccomandano 44–48 pixel CSS come target di tocco confortevole. Soddisfare 2.5.8 è il pavimento, non il soffitto.

Perché è importante

Le disabilità motorie influiscono sulla precisione del puntatore in una grande varietà di modi. Persone con morbo di Parkinson, tremore essenziale, paralisi cerebrale, sclerosi multipla, emiplegia post-ictus o lesioni da sforzo ripetitivo possono non essere in grado di posizionare il puntatore in modo affidabile su un target piccolo. Anche gli adulti più anziani sperimentano un naturale declino del controllo motorio fine: circa il 15% delle persone oltre i 65 anni riferisce notevoli difficoltà nell’uso di mouse o touchscreen. Oltre alle condizioni cliniche, anche utenti con disabilità situazionale — qualcuno che tiene uno smartphone con una mano su un autobus in movimento, o qualcuno il cui dito è grande rispetto a uno schermo di telefono piccolo — hanno difficoltà con target minuscoli.

Secondo l’Organizzazione Mondiale della Sanità, oltre 1,3 miliardi di persone nel mondo vivono con qualche forma di disabilità, e la disabilità motoria è tra le categorie più comuni. Quando gli elementi interattivi sono troppo piccoli o troppo vicini tra loro, queste persone sperimentano attivazioni accidentali, tocchi mancati ed errori ripetuti che rendono un sito di fatto inutilizzabile. La frustrazione è amplificata sui dispositivi touch, dove non esiste uno stato hover per confermare la posizione del cursore prima di effettuare un clic.

Consideriamo uno scenario concreto: un sito di e-commerce turco che vende elettronica mostra una riga di cinque icone di condivisione social in cima a ogni pagina di prodotto, ciascuna di 18×18 pixel con 3px di spazio tra di esse. Una donna con tremore essenziale che cerca di condividere un prodotto su WhatsApp tocca ripetutamente l’icona sbagliata, attivando condivisioni indesiderate su Facebook. Non ha modo di annullare rapidamente queste condivisioni e il compito diventa così soggetto a errori che lo abbandona del tutto. Aumentare ciascuna icona a 24×24 pixel CSS, o aggiungere padding in modo che l’area cliccabile raggiunga 24×24, risolverebbe il problema senza modificare significativamente il design visivo.

Oltre all’accessibilità, una dimensione adeguata dei target è correlata a tassi di conversione più elevati, tassi di rimbalzo più bassi e migliori punteggi Core Web Vitals relativi alla prontezza all’interazione. L’indicizzazione mobile-first da parte dei motori di ricerca favorisce inoltre le pagine che offrono una buona usabilità touch, rendendo la dimensione dei target un fattore che interseca accessibilità e SEO.

Regole Axe-core correlate

• target-size (experimental): Questa regola verifica se gli elementi interattivi hanno una dimensione renderizzata di almeno 24×24 pixel CSS o, per gli elementi più piccoli, se esiste uno spazio di offset sufficiente affinché l’area totale raggiungibile soddisfi la soglia. La regola interroga le dimensioni calcolate e i rettangoli di delimitazione degli elementi focalizzabili e interattivi con il puntatore e segnala quelli che non superano il test dimensione-o-offset. Poiché è attualmente contrassegnata come experimental, non è inclusa nel set di regole predefinito di axe-core e deve essere abilitata esplicitamente con runOnly: { type: 'tag', values: ['wcag22aa', 'experimental'] } o abilitando le regole sperimentali in axe DevTools. La regola può produrre falsi positivi per i link di testo inline e i controlli nativi che i browser dimensionano in modo diverso tra le piattaforme, quindi dopo una scansione automatizzata è sempre raccomandata una revisione manuale. Non può rilevare in modo affidabile i passaggi basati sulla spaziatura quando sono coinvolti layout CSS complessi, trasformazioni o contesti di stacking z-index sovrapposti, motivo per cui l’ispezione manuale degli stili calcolati in DevTools rimane essenziale.

Poiché la dimensione del target dipende dal rendering visivo, dal CSS calcolato, dalle dimensioni del viewport e dalla prossimità di elementi interattivi vicini, gli strumenti automatizzati possono segnalare i fallimenti più evidenti ma non possono sostituire il giudizio umano. Uno strumento può misurare il riquadro di delimitazione di un pulsante, ma determinare se l’offset tra due target adiacenti è davvero privo di altri elementi interattivi — soprattutto in interfacce dinamiche o guidate da JavaScript — richiede una verifica manuale.

Come testare

1. Scansione automatizzata con axe DevTools: Installa l’estensione del browser axe DevTools. Apri la pagina da testare. Nel pannello axe DevTools, abilita le regole sperimentali prima di eseguire la scansione (cerca il filtro per tag di regola e aggiungi experimental). Dopo il completamento della scansione, filtra i risultati per l’ID della regola target-size. Per ciascun elemento segnalato, annota le dimensioni riportate. Verifica il risultato manualmente prima di registrarlo come fallimento confermato, poiché le regole sperimentali hanno un tasso più elevato di falsi positivi.
2. Scansione automatizzata con Lighthouse: Esegui un audit di accessibilità Lighthouse in Chrome DevTools o tramite CLI. Lighthouse include un audit dei tap-target che verifica la presenza di target più piccoli di 48×48 pixel CSS con spaziatura insufficiente — nota che utilizza una soglia più severa rispetto a WCAG 2.5.8, quindi i fallimenti di Lighthouse sono un superset dei fallimenti WCAG. Esamina gli elementi segnalati nel report e confrontali con la soglia WCAG di 24×24 per determinare quali costituiscono effettivi fallimenti di livello AA e quali invece raccomandazioni di best practice.
3. Misurazione manuale con DevTools del browser: Apri DevTools e ispeziona ciascun elemento interattivo. Nel pannello Computed, controlla width e height. Se uno dei due è inferiore a 24px, passa alla vista Box Model e controlla il padding. Se il padding porta il target a 24×24, il requisito è soddisfatto. In caso contrario, misura lo spazio fino all’elemento interattivo adiacente più vicino usando il rettangolo di delimitazione dell’elemento: esegui document.querySelector('your-selector').getBoundingClientRect() nella console e confronta le coordinate degli elementi vicini. Se lo spazio combinato in ciascuna dimensione porta l’area effettivamente raggiungibile a 24px, il requisito è soddisfatto.
4. Simulazione touch: In Chrome DevTools, abilita l’emulazione del dispositivo e passa a un profilo di dispositivo ottimizzato per il touch. Prova a toccare ciascun piccolo elemento interattivo. Annota eventuali casi in cui è difficile attivare l’elemento desiderato o in cui vengono attivati accidentalmente elementi adiacenti.
5. Test con tastiera e screen reader (per contesto): Sebbene WCAG 2.5.8 sia specificamente un criterio per i puntatori, verificare che i target piccoli abbiano anche indicatori di focus visibili e siano raggiungibili tramite tastiera aiuta a identificare problemi combinati. Usa NVDA con Firefox o JAWS con Chrome per navigare tra gli elementi interattivi e confermare che siano raggiungibili e attivabili indipendentemente dalla dimensione.
6. Test su dispositivi reali: Esegui test su un dispositivo mobile fisico — idealmente sia su un dispositivo Android con schermo grande sia su un dispositivo iOS più piccolo — per confermare che i target che superano i test su desktop li superino anche alle dimensioni di viewport mobile, poiché la densità dei pixel CSS e il comportamento dello zoom possono influenzare la dimensione percepita del target.

Come correggere

Pulsante solo icona di piccole dimensioni — Errato

<!-- Close button is only 16x16 CSS pixels, no padding, adjacent to other controls -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

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

Pulsante solo icona di piccole dimensioni — Corretto

<!-- Adding padding increases the interactive area to 24x24 CSS pixels
     while the visual icon remains 16x16. The min-width/min-height
     ensures the target meets the WCAG 2.5.8 threshold. -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

<style>
  .close-btn {
    min-width: 24px;
    min-height: 24px;
    padding: 4px;
    border: none;
    background: none;
    cursor: pointer;
    display: inline-flex;
    align-items: center;
    justify-content: center;
  }
</style>

Link di navigazione molto ravvicinati — Errato

<!-- Each link renders at roughly 20px tall with 1px margin,
     leaving insufficient offset spacing between targets -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list li { margin: 1px 0; }
  .nav-list a { font-size: 12px; line-height: 1.4; display: block; }
</style>

Link di navigazione molto ravvicinati — Corretto

<!-- Padding on each anchor ensures the target area is at least 24px tall.
     The gap between items is now large enough to satisfy the offset rule
     even if the text itself is smaller than 24px. -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list { list-style: none; padding: 0; margin: 0; }
  .nav-list a {
    display: block;
    padding: 6px 8px; /* vertical padding brings block height to >= 24px */
    font-size: 14px;
    line-height: 1.4;
    text-decoration: none;
  }
</style>

Checkbox con area di attivazione minuscola — Errato

<!-- The default checkbox is visually 13px on many browsers and has no
     associated label providing additional target area -->
<input type='checkbox' id='agree'>
<span>I agree to the terms</span>

Checkbox con etichetta associata — Corretto

<!-- Wrapping the input in a <label> makes the entire label text also
     a valid pointer target. The label's line-height and padding ensure
     the combined hit area easily exceeds 24x24 CSS pixels.
     The input itself is given min-width/min-height as a fallback. -->
<label class='checkbox-label'>
  <input type='checkbox' id='agree' class='checkbox-input'>
  I agree to the terms
</label>

<style>
  .checkbox-label {
    display: inline-flex;
    align-items: center;
    gap: 8px;
    padding: 4px 0;
    cursor: pointer;
    min-height: 24px;
  }
  .checkbox-input {
    min-width: 24px;
    min-height: 24px;
    cursor: pointer;
  }
</style>

Riga di icone di condivisione social — Errato

<!-- Each icon is 18x18px with only 2px gap; the combined
     reachable area for each icon is only 20px, below the 24px threshold -->
<div class='share-row'>
  <a href='#' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 2px; }
  .share-row a { display: inline-block; line-height: 1; }
</style>

Riga di icone di condivisione social — Corretto

<!-- Each anchor now has min-width and min-height of 24px via padding,
     and the gap between anchors is at least 3px so the offset rule is
     satisfied independently even without the padding. -->
<div class='share-row'>
  <a href='#' class='share-link' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' class='share-link' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 6px; }
  .share-link {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    min-width: 24px;
    min-height: 24px;
    padding: 3px;
  }
</style>

Errori comuni

• Impostare width e height sull’icona all’interno di un pulsante invece che sul pulsante stesso: Gli sviluppatori spesso limitano l’SVG o l’immagine a 16–20px ma dimenticano che l’elemento <button> necessita di min-width: 24px; min-height: 24px e di un padding adeguato per creare un target di tocco sufficiente.
• Rimuovere il padding predefinito del browser da pulsanti e input con padding: 0 o con un reset globale: I reset CSS che azzerano il padding sugli elementi di form eliminano il margine di sicurezza che mantiene i controlli nativi a una dimensione usabile. Dopo un reset, aggiungi sempre padding esplicito.
• Fare affidamento solo su line-height per aumentare l’altezza dei link senza display: block o display: inline-block: Gli elementi inline non rispondono a height o al padding verticale nello stesso modo degli elementi block, quindi un link può apparire visivamente più alto mentre il suo effettivo riquadro di clic rimane piccolo.
• Usare pointer-events: none su un wrapper e collegare gli handler di clic a un minuscolo elemento interno: Questo vanifica qualsiasi padding o dimensione minima applicata al wrapper, riducendo il target effettivo alla dimensione renderizzata dell’elemento interno.
• Applicare overflow: hidden a un contenitore di pulsanti che taglia il padding del pulsante: L’area di clic visiva viene limitata ai confini del contenitore, rendendo il target effettivo più piccolo di quanto suggeriscano le dimensioni del pulsante.
• Dimenticare di considerare le trasformazioni CSS come scale(): Un pulsante ridotto visivamente tramite transform: scale(0.7) ha ancora il suo riquadro di delimitazione originale per gli eventi di puntatore nella maggior parte dei browser, ma questo comportamento è incoerente e inaffidabile — dimensiona sempre i target alla loro scala finale renderizzata.
• Dare per scontato che una grande <label> compensi un minuscolo <input> quando label e input non sono associati a livello programmatico: Se la <label> non usa for corrispondente all’id dell’input, o se l’input non è racchiuso all’interno della label, cliccare il testo della label non attiva l’input, quindi solo la piccola area del target dell’input è effettivamente funzionale.
• Non testare alle dimensioni di viewport in cui i target sono effettivamente renderizzati: Un pulsante che è 32×32 pixel CSS su desktop può essere renderizzato a 22×22 pixel CSS su un viewport mobile stretto a causa di scaling fluido o unità relative al viewport (vw, vmin), creando un fallimento che appare solo su mobile.
• Applicare in modo troppo estensivo l’eccezione WCAG 2.5.8 per i link di testo inline: L’eccezione si applica solo ai link che sono realmente inline all’interno di una porzione di testo (ad esempio, un hyperlink all’interno di un paragrafo). I link autonomi stilizzati per sembrare testo — come un link “Forgot password?” sotto un form — non sono link inline e devono soddisfare la soglia di 24×24.
• Non esaminare widget di terze parti e componenti incorporati: Banner per il consenso ai cookie, widget di chat e overlay di analytics includono spesso piccoli pulsanti (accetta, chiudi, minimizza) iniettati da script esterni. Fanno comunque parte del profilo di accessibilità della pagina e devono rispettare WCAG 2.5.8 anche se il codice non è stato scritto internamente.

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 di accessibilità vincolanti per un’ampia gamma di fornitori di servizi digitali operanti in Turchia. La Circolare fa esplicito riferimento a WCAG 2.2 come standard tecnico e la conformità di livello AA è richiesta per ottenere l’Erişilebilirlik Logosu (Logo di Accessibilità) rilasciato dal Ministero della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı). Poiché WCAG 2.5.8 è un criterio di livello AA in WCAG 2.2, rientra direttamente nell’ambito di questo quadro obbligatorio.

Le tipologie di entità coperte dalla Circolare includono istituzioni pubbliche e agenzie governative a livello centrale e locale, banche e società di servizi finanziari, ospedali e fornitori di assistenza sanitaria privati, operatori di telecomunicazioni con 200.000 o più abbonati, piattaforme di e-commerce, agenzie di viaggio, società di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (Milli Eğitim Bakanlığı). Per tutte queste organizzazioni, la conformità a WCAG 2.5.8 non è semplicemente una raccomandazione di best practice — è un obbligo normativo legato alla possibilità di esporre il Logo di Accessibilità e di dimostrare la conformità legale durante gli audit.

In termini pratici, ciò significa che l’applicazione web responsive di una banca turca deve garantire che i pulsanti di conferma dei bonifici, i campi di inserimento delle one-time password e i controlli di navigazione soddisfino tutti la dimensione minima del target di 24×24 pixel CSS. Allo stesso modo, un sito di e-commerce deve verificare che i pulsanti “aggiungi al carrello”, i selettori di quantità e i controlli dei filtri siano adeguatamente dimensionati su tutti i profili di dispositivo. I portali sanitari devono esaminare i calendari di prenotazione degli appuntamenti, notoriamente caratterizzati da celle di data piccole, e ampliare tali celle o fornire sufficiente spazio di offset. I portali self-service delle telecomunicazioni devono verificare che i link di gestione dell’account e i controlli toggle nei selettori dei piani dati soddisfino la soglia.

Il mancato rispetto della Circolare può comportare sanzioni amministrative e può impedire a un’organizzazione di esporre il Logo di Accessibilità, che è sempre più utilizzato come segnale di fiducia dai consumatori turchi. Oltre alle sanzioni, la non conformità espone le organizzazioni a reclami presentati agli organi di vigilanza competenti. Considerando che la Turchia ha una popolazione anziana in crescita — l’Istituto di Statistica Turco prevede che le persone di 65 anni e oltre costituiranno il 16,3% della popolazione entro il 2040 — l’impatto pratico dei target piccoli aumenterà soltanto nel tempo, rendendo la conformità anticipata sia una priorità etica sia una solida strategia aziendale a lungo termine.