WCAG 2.5.1: Gesti del puntatore

Cosa Significa Questa Regola

WCAG 2.5.1 Pointer Gestures richiede che qualsiasi funzionalità in una pagina web che si basa su gesture multipunto (gesture che utilizzano due o più punti di contatto simultanei, come il pizzico a due dita per lo zoom o lo swipe a tre dita) o gesture basate sul percorso (gesture in cui il percorso seguito dal puntatore è rilevante, come uno swipe, un trascinamento lungo una rotta specifica o una forma disegnata) sia anche azionabile usando un singolo puntatore in un modo che non richieda una gesture basata sul percorso. Un singolo puntatore è qualsiasi input che opera in un singolo punto — questo include il tocco con un solo dito, il clic del mouse, il tocco con uno stilo e input simili.

In termini pratici, se il tuo carosello avanza le slide quando l’utente effettua uno swipe orizzontale, devi anche fornire pulsanti avanti e indietro che possano essere attivati con un singolo tap o clic. Se il tuo widget di mappa personalizzato risponde a un pizzico a due dita per ingrandire o ridurre, devi anche fornire controlli di zoom in e zoom out che richiedano solo un singolo tap. Il criterio non vieta le gesture multipunto o basate sul percorso — richiede semplicemente che esista sempre un’alternativa equivalente a singolo puntatore.

L’eccezione ufficiale delle WCAG afferma: il requisito non si applica quando la gesture multipunto o basata sul percorso è essenziale. Una gesture è essenziale quando rimuoverla cambierebbe in modo fondamentale l’informazione o la funzionalità, e il testo o un’altra alternativa non possono raggiungere lo stesso scopo. Un widget per la firma a mano libera o un’applicazione di disegno in cui il percorso disegnato è esso stesso l’output rientrerebbero nella definizione di essenziale. Tuttavia, la grande maggioranza delle interazioni con navigazione, caroselli, mappe e slider non rientra in questa eccezione, perché può essere replicata con semplici alternative tap/clic senza alcuna perdita di informazione.

Questo criterio si applica a tutti gli input di tipo puntatore: touchscreen, mouse, stilo, puntatori basati sul tracciamento oculare e qualsiasi altro dispositivo di puntamento. È un requisito di Livello A secondo WCAG 2.2, il che significa che è considerato un requisito di accessibilità di base che deve essere soddisfatto per la conformità minima.

Un’implementazione conforme fornisce almeno un meccanismo per svolgere ogni funzione dipendente da gesture usando un’attivazione a singolo punto non basata sul percorso — tipicamente un pulsante visibile, un link o un altro controllo focalizzabile. Un’implementazione non conforme si affida esclusivamente a gesture di swipe, pizzico, allargamento, rotazione o percorso disegnato per eseguire una funzione, senza fornire un’alternativa equivalente a singolo puntatore.

Perché È Importante

Le disabilità motorie interessano una parte significativa della popolazione mondiale. Condizioni come il morbo di Parkinson, il tremore essenziale, la paralisi cerebrale, l’emiplegia post-ictus, le differenze agli arti e le lesioni da sforzo ripetitivo possono rendere difficile o impossibile per gli utenti eseguire in modo affidabile gesture precise multipunto o basate sul percorso. Secondo l’Organizzazione Mondiale della Sanità, circa 1,3 miliardi di persone nel mondo vivono con una forma significativa di disabilità, e le disabilità motorie e di mobilità sono tra le categorie più comuni. Quando le interfacce web si basano esclusivamente su gesture complesse, questi utenti sono completamente esclusi da funzionalità che gli utenti vedenti e non disabili danno per scontate.

Considera uno scenario concreto reale: un utente con tremore essenziale sta navigando su un sito di e-commerce turco con un tablet. La galleria di immagini del prodotto utilizza solo la gesture di swipe per spostarsi tra le foto. L’utente non riesce a eseguire in modo affidabile uno swipe orizzontale pulito — il tremore provoca tap accidentali, movimenti diagonali o tocchi involontari con più dita. Senza pulsanti precedente/successivo, non può visualizzare ulteriori foto del prodotto e può decidere di abbandonare completamente l’acquisto. Aggiungere due semplici pulsanti freccia costa al team di sviluppo pochi minuti ma rimuove una barriera totale per questo utente.

Oltre alle disabilità motorie, questo criterio avvantaggia anche gli utenti con protesi agli arti superiori o dispositivi di accesso a singolo interruttore che emulano un singolo puntatore, gli utenti che utilizzano dispositivi montati su sedie a rotelle in cui la rotazione o il multi-touch sono meccanicamente impraticabili, e gli adulti più anziani che trovano le gesture touch complesse poco intuitive o difficili da imparare. Anche gli utenti che utilizzano un dispositivo con un mouse o uno stilo non touch sono direttamente interessati — questi metodi di input sono intrinsecamente a singolo puntatore e non possono eseguire affatto gesture multipunto.

Da una prospettiva di usabilità e di business, fornire controlli espliciti a singolo puntatore (pulsanti, link) migliora anche la scopribilità per tutti gli utenti, riduce il carico cognitivo e può contribuire positivamente ai tassi di completamento dei task e alle metriche di conversione. I motori di ricerca possono inoltre analizzare e seguire la navigazione basata su pulsanti in modo più affidabile rispetto alle interazioni basate su gesture, offrendo benefici SEO secondari per i pattern di navigazione indicizzabili.

Regole Axe-core Correlate

WCAG 2.5.1 richiede test manuali perché gli strumenti automatici non possono rilevare in modo affidabile se un comportamento dipendente da gesture ha un’alternativa a singolo puntatore. Nessuna regola automatizzata di axe-core mappa direttamente a questo criterio. Le ragioni per cui il rilevamento automatico è insufficiente sono:

• Test manuale richiesto — rilevamento delle gesture: Gli scanner automatici analizzano la struttura DOM statica e gli stili calcolati. Non possono osservare il comportamento dei listener di eventi JavaScript in fase di esecuzione in un modo che distingua se un handler touchstart/touchmove/touchend implementa uno swipe dipendente dal percorso o semplicemente un tap. Uno scanner vede che sono presenti eventi touch ma non può determinare se la funzionalità risultante è disponibile anche tramite un’alternativa a singolo puntatore. Questo richiede che un tester umano interagisca con l’interfaccia usando sia metodi basati su gesture sia metodi a singolo puntatore e confronti le funzionalità disponibili.
• Test manuale richiesto — verifica dell’equivalenza: Anche se uno strumento potesse segnalare l’esistenza di un listener per gesture multipunto, non può valutare se un pulsante o un link fornito raggiunge risultati funzionalmente equivalenti. Verificare l’equivalenza — che l’alternativa attivi lo stesso risultato, che sia visibile e raggiungibile e che non sia nascosta dietro un passaggio aggiuntivo — richiede un giudizio umano informato dall’intento del criterio.
• Test manuale richiesto — eccezione per gesture essenziali: Determinare se una gesture rientra nell’eccezione “essenziale” richiede una comprensione contestuale dello scopo dell’applicazione che nessuna regola automatizzata può valutare in modo affidabile.

I tester dovrebbero utilizzare gli strumenti di sviluppo del browser per ispezionare i listener di eventi associati (in Chrome DevTools, fai clic con il tasto destro su un elemento, seleziona “Inspect”, quindi visualizza la scheda “Event Listeners”) come punto di partenza per identificare quali elementi hanno handler per eventi touch o pointer, e poi verificare manualmente la presenza e l’equivalenza delle alternative a singolo puntatore.

Come Eseguire i Test

1. Esegui una scansione automatizzata come base: Usa axe DevTools, Lighthouse o l’audit integrato del widget Accsible per analizzare la pagina. Sebbene nessuna regola mappi direttamente a 2.5.1, i risultati della scansione possono segnalare problemi correlati (come controlli focalizzabili mancanti) che forniscono contesto per la revisione manuale. Prendi nota di eventuali elementi interattivi segnalati per mancanza di supporto per tastiera o puntatore.
2. Identifica la funzionalità dipendente da gesture: Esplora manualmente la pagina su un dispositivo touch (o usando l’emulazione di dispositivi del browser in Chrome DevTools — attiva la barra degli strumenti del dispositivo e interagisci usando il touch simulato). Cerca caroselli, slider, mappe, accordion, gallerie di immagini, pannelli scrollabili, interfacce drag-and-drop, strumenti di disegno e qualsiasi altro componente che risponde alle gesture touch. Documenta ogni funzione che scopri che viene attivata da uno swipe, pizzico, rotazione o altra gesture basata sul percorso o multipunto.
3. Tenta equivalenti a singolo puntatore: Per ogni funzione dipendente da gesture identificata, prova a svolgere la stessa funzione usando solo tap singoli (o clic del mouse su desktop). Verifica se esistono controlli visibili come pulsanti, frecce o link che attivano lo stesso risultato. Prova a usare tali controlli con un mouse, una tastiera (Tab per portare il focus, Invio/Barra spaziatrice per attivare) e un lettore di schermo.
4. Verifica con lettore di schermo (NVDA + Firefox): Apri NVDA e Firefox. Naviga tra i componenti interattivi usando i tasti Tab e freccia. Verifica che i controlli a singolo puntatore (pulsanti, link) per le funzioni basate su gesture siano annunciati dal lettore di schermo, siano raggiungibili tramite tastiera e producano il risultato previsto quando vengono attivati.
5. Verifica con lettore di schermo (VoiceOver + Safari su iOS): Abilita VoiceOver su un iPhone o iPad. Effettua uno swipe verso destra con un dito per navigare tra gli elementi. Verifica che tutti i controlli che forniscono alternative a singolo puntatore alle gesture siano raggiungibili e attivabili tramite la gesture di tap di VoiceOver e che producano il risultato corretto.
6. Verifica con lettore di schermo (JAWS + Chrome): Usa JAWS con Chrome su Windows. Passa con Tab tra i componenti interattivi e verifica che i controlli alternativi alle gesture siano focalizzabili, correttamente etichettati e funzionanti.
7. Valuta l’eccezione essenziale: Per qualsiasi funzione dipendente da gesture priva di un’alternativa a singolo puntatore, determina se la gesture è davvero essenziale per il contenuto o la funzionalità. Se non puoi giustificare l’eccezione, registrala come errore. Documenta le tue conclusioni con screenshot e passaggi per la riproduzione.

Come Correggere

Carosello di Immagini con Navigazione Solo Swipe — Non Corretto

<!-- Carousel that only listens for touch swipe events, no button controls -->
<div id='carousel' class='carousel'>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
</div>
<!-- JavaScript only adds touchstart/touchend swipe detection -->
<script>
  // Only gesture-based: no keyboard or click alternative
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
</script>

Carosello di Immagini con Navigazione Solo Swipe — Corretto

<!-- Carousel with both swipe gesture support AND visible single-pointer button controls -->
<div id='carousel' class='carousel' role='region' aria-label='Product images'>
  <button id='prev-btn' aria-label='Previous image' onclick='prevSlide()'>
    &lsaquo; Previous
  </button>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
  <button id='next-btn' aria-label='Next image' onclick='nextSlide()'>
    Next &rsaquo;
  </button>
</div>
<!-- Swipe is retained as an enhancement; buttons provide the single-pointer alternative -->
<script>
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
  function prevSlide() { /* move to previous slide */ }
  function nextSlide() { /* move to next slide */ }
</script>

Mappa con Solo Pinch-to-Zoom — Non Corretta

<!-- Map widget that only responds to two-finger pinch gestures for zoom -->
<div id='map' class='map-widget'></div>
<script>
  // Only multipoint pinch gesture is wired up; no zoom buttons provided
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
</script>

Mappa con Solo Pinch-to-Zoom — Corretta

<!-- Map widget with pinch-to-zoom PLUS visible zoom controls for single-pointer access -->
<div class='map-container' role='application' aria-label='Interactive map'>
  <div id='map' class='map-widget'></div>
  <div class='map-controls'>
    <!-- Single-pointer alternatives for zoom in and out -->
    <button type='button' aria-label='Zoom in' onclick='mapZoomIn()'>+</button>
    <button type='button' aria-label='Zoom out' onclick='mapZoomOut()'>&minus;</button>
  </div>
</div>
<script>
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
  function mapZoomIn() { /* increase zoom level by one step */ }
  function mapZoomOut() { /* decrease zoom level by one step */ }
</script>

Range Slider con Solo Gesture di Trascinamento sul Percorso — Non Corretto

<!-- Custom price range slider that only works by dragging a thumb along a track -->
<div class='price-slider' id='priceSlider'>
  <div class='track'>
    <div class='thumb' id='sliderThumb'></div>
  </div>
</div>
<!-- No keyboard support, no input field, no increment/decrement buttons -->

Range Slider con Solo Gesture di Trascinamento sul Percorso — Corretto

<!-- Use the native <input type='range'> which provides built-in keyboard and single-pointer support -->
<label for='priceRange'>Maximum price: <span id='priceValue'>500</span> TL</label>
<input
  type='range'
  id='priceRange'
  name='priceRange'
  min='0'
  max='1000'
  value='500'
  step='10'
  aria-valuemin='0'
  aria-valuemax='1000'
  aria-valuenow='500'
  aria-label='Maximum price in Turkish lira'
  oninput='document.getElementById("priceValue").textContent = this.value'
>
<!-- Native range input supports click, tap, keyboard arrow keys, and touch drag --
     covering all single-pointer and path-based interaction needs natively -->

Errori Comuni

• Fornire caroselli solo swipe senza alcun controllo con pulsanti precedente/successivo: Molte librerie di caroselli vengono fornite solo con supporto per le gesture; gli sviluppatori devono configurare esplicitamente e renderizzare i pulsanti di navigazione per fornire un’alternativa a singolo puntatore.
• Nascondere i pulsanti di navigazione sui dispositivi touch tramite media query CSS: Un pattern comune nasconde i pulsanti freccia sugli schermi che si presume siano dispositivi touch (ad esempio, @media (pointer: coarse)), rimuovendo l’alternativa a singolo puntatore per gli utenti con disabilità motorie che vi fanno affidamento anche sui touchscreen.
• Affidarsi esclusivamente a una gesture di pizzico a due dita per lo zoom della mappa senza offrire pulsanti di zoom: Gli embed di mappe di terze parti (implementazioni personalizzate) omettono frequentemente i controlli di zoom, lasciando il pizzico come unico meccanismo di zoom.
• Usare pattern di swipe-to-delete o swipe-to-reveal senza alcun pulsante di azione alternativo: Gli elementi di lista nelle web app che rivelano opzioni di eliminazione o azione solo tramite uno swipe orizzontale non hanno un meccanismo equivalente basato sul tap per gli utenti che non possono eseguire swipe in modo affidabile.
• Interfacce drag-and-drop personalizzate che non hanno un’alternativa di riordinamento basata su tastiera o clic: Le interazioni di trascinamento sono per natura basate sul percorso; non fornire un meccanismo alternativo (come pulsanti su/giù o un modello taglia-e-incolla) viola questo criterio.
• Widget di disegno o firma che presumono che il percorso disegnato non sia l’output: Gli sviluppatori a volte invocano erroneamente l’eccezione “essenziale” per widget che in realtà sono solo controlli dell’interfaccia utente (ad esempio, un pattern di sblocco tramite gesture per rivelare contenuti) piuttosto che veri strumenti di input a mano libera.
• Posizionare i controlli alternativi a singolo puntatore al di fuori della viewport visibile o in uno stato compresso per impostazione predefinita: Se i pulsanti equivalenti esistono nel DOM ma sono visivamente nascosti o richiedono un’interazione aggiuntiva per essere mostrati, non soddisfano pienamente il requisito di un’alternativa a singolo puntatore percepibile e azionabile.
• Implementare librerie di gesture che intercettano gli eventi del puntatore e impediscono il comportamento predefinito: Le librerie che chiamano event.preventDefault() sugli eventi touch possono bloccare involontariamente le interazioni a singolo puntatore e lo scrolling del browser, creando errori non intenzionali oltre al criterio sulle gesture.
• Presumere che aggiungere aria-label a una zona solo gesture sia sufficiente: Etichettare un’area di swipe non fornisce un’alternativa a singolo puntatore — descrive solo l’area agli utenti di lettori di schermo che comunque non possono azionarla senza supporto per le gesture.
• Non testare su dispositivi reali o con simulazione touch: Gli sviluppatori che testano solo su desktop con un mouse possono non scoprire mai che una funzionalità è esclusivamente azionata da gesture su mobile, perché il fallback al clic del mouse funziona su desktop ma il percorso di codice solo touch non ha un equivalente per il clic.

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 obblighi obbligatori di accessibilità web e mobile per un’ampia gamma di soggetti pubblici e privati che operano in Turchia. La circolare adotta WCAG 2.2 come standard tecnico normativo, rendendo tutti i criteri di successo di Livello A — inclusa WCAG 2.5.1 Pointer Gestures — requisiti di base legalmente obbligatori.

La tempistica di conformità prevista dalla circolare è a scaglioni: le istituzioni e gli enti pubblici sono tenuti a raggiungere la conformità entro un anno dall’entrata in vigore della circolare, mentre i soggetti del settore privato coperti dal regolamento hanno una finestra di due anni per raggiungere la piena conformità. Il mancato rispetto espone i soggetti interessati al controllo regolatorio e ad azioni esecutive da parte delle autorità di vigilanza competenti.

I soggetti coperti dalla circolare includono un’ampia sezione trasversale dei fornitori di servizi digitali turchi. Sono incluse le istituzioni pubbliche a tutti i livelli di governo e i loro enti affiliati. Nel settore privato, la circolare si applica a piattaforme e marketplace di e-commerce, banche e istituzioni finanziarie, ospedali privati e fornitori di servizi sanitari, società di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio, società private di trasporto passeggeri e scuole private che operano con autorizzazione del Ministero dell’Istruzione Nazionale (MoNE).

Per queste organizzazioni, WCAG 2.5.1 ha implicazioni dirette e pratiche. I siti di e-commerce turchi utilizzano frequentemente gallerie di immagini di prodotto basate su gesture, navigazione per categorie basata su swipe e visualizzatori di prodotto con pinch-to-zoom — tutti elementi che ora devono avere alternative a singolo puntatore. Le applicazioni bancarie e finanziarie che utilizzano pattern di autenticazione basati su gesture o interfacce di transazione basate sul trascinamento devono essere sottoposte ad audit e correzione. I portali sanitari con localizzatori di cliniche basati su mappe che usano il pinch-zoom devono fornire pulsanti di zoom. I portali self-service delle telecomunicazioni con selettori di piani basati su swipe devono aggiungere controlli basati sul tap.

Alle organizzazioni che operano in Turchia si raccomanda vivamente di includere WCAG 2.5.1 immediatamente nelle proprie checklist di audit di accessibilità, poiché i pattern di interazione basati su gesture interessati da questo criterio sono pervasivi nel moderno responsive web design e nello sviluppo mobile-first — e tuttavia vengono frequentemente trascurati perché sembrano funzionare correttamente per la maggioranza degli utenti. Affrontare questo criterio in modo proattivo come parte di un programma di conformità a WCAG 2.2 Livello A è sia un obbligo legale ai sensi della Circolare Presidenziale 2025/10 sia un miglioramento significativo dell’inclusione digitale per gli utenti turchi con disabilità motorie.