WCAG 2.5.4: Attivazione tramite movimento

Cosa Significa Questa Regola

WCAG 2.5.4 — Motion Actuation affronta uno scenario specifico ma sempre più comune nelle moderne applicazioni web: funzionalità attivate dal movimento fisico del dispositivo, come scuotere uno smartphone, inclinare un dispositivo o fare gesti davanti a una fotocamera. Il criterio stabilisce due requisiti paralleli che devono entrambi essere soddisfatti per la conformità.

In primo luogo, qualsiasi funzionalità che può essere azionata dal movimento del dispositivo o dal movimento dell’utente deve poter essere azionata anche tramite un componente dell’interfaccia utente — cioè un pulsante, un link, un controllo di form o un elemento interattivo simile che non si basi sul movimento. Questo garantisce che le persone che non possono eseguire o non possono eseguire in modo affidabile gesti di movimento fisico non siano escluse dall’accesso a quella funzionalità.

In secondo luogo, gli utenti devono poter disabilitare la risposta al movimento in modo che movimenti accidentali o involontari non attivino azioni indesiderate. Questo protegge gli utenti che hanno tremori o altre condizioni motorie che causano movimenti involontari del dispositivo dall’essere costantemente disturbati da comportamenti imprevisti dell’applicazione.

Il criterio si applica a due tipi distinti di movimento: il movimento del dispositivo, che viene rilevato tramite sensori come accelerometri e giroscopi integrati in smartphone e tablet (accessibili tramite API come DeviceMotionEvent e DeviceOrientationEvent), e il movimento dell’utente, che viene rilevato tramite fotocamere o altri sensori di input che tracciano il movimento del corpo o i gesti piuttosto che il dispositivo stesso.

Un’implementazione conforme fornisce tutta la funzionalità attivata dal movimento tramite un controllo UI standard (un pulsante, un link o equivalente) E consente all’utente di disattivare il rilevamento del movimento se lo desidera. Un’implementazione non conforme fornisce l’accesso a una funzionalità solo tramite il movimento senza un controllo UI alternativo, oppure fornisce un’alternativa ma non offre alcun modo per disabilitare il trigger basato sul movimento, così che i movimenti involontari continuino a causare problemi.

WCAG 2.5.4 definisce due importanti eccezioni. L’attivazione tramite movimento è esentata se il movimento è essenziale alla funzione e disabilitarlo altererebbe in modo fondamentale l’attività — per esempio, un’applicazione fitness che conta i passi in cui il tracciamento del movimento è lo scopo principale, o un gioco esplicitamente progettato attorno a meccaniche di inclinazione. La seconda eccezione si applica quando il movimento viene usato per azionare funzionalità tramite un’interfaccia di accessibilità supportata, cioè quando le funzionalità di accessibilità della piattaforma gestiscono l’interazione basata sul movimento in un modo che l’utente controlla in modo indipendente.

Perché È Importante

Le barriere legate all’attivazione tramite movimento colpiscono in modo sproporzionato le persone con disabilità motorie e di mobilità, ma l’impatto è più ampio di quanto molti sviluppatori inizialmente suppongano. Comprendere chi è interessato — e come — aiuta i team a dare a questo criterio la giusta priorità.

Le persone con condizioni che causano tremori — tra cui tremore essenziale, morbo di Parkinson e sclerosi multipla — possono sperimentare movimenti involontari costanti o intermittenti di mani e braccia. Quando tengono uno smartphone, il loro tremore naturale è sufficiente a attivare ripetutamente e inaspettatamente finestre di dialogo “shake-to-undo”, azioni di aggiornamento o altre funzionalità attivate dal movimento. L’Organizzazione Mondiale della Sanità stima che circa 1,3 miliardi di persone nel mondo vivano con una qualche forma di disabilità significativa, e le condizioni che colpiscono il controllo motorio fine sono tra le più diffuse in tutte le fasce d’età.

Le persone con paralisi o differenze agli arti possono usare i loro dispositivi montati su sedie a rotelle o supporti, oppure usare puntatori per la testa, tracciamento oculare o controlli a interruttore per interagire con i loro dispositivi. Spesso queste persone non possono scuotere o inclinare affatto un dispositivo, rendendo le funzionalità basate solo sul movimento completamente inaccessibili. Se l’unico modo per annullare l’inserimento di un testo in un’applicazione web mobile è scuotere il dispositivo, una persona che usa una sedia a rotelle con un telefono montato non può semplicemente accedere a quella funzionalità.

Le persone anziane sono un altro gruppo significativamente interessato. Condizioni legate all’età, tra cui riduzione della forza di presa, artrite e tremore essenziale, diventano sempre più comuni con l’avanzare dell’età, il che significa che una quota crescente della popolazione — che è anche sempre più attiva digitalmente — può avere difficoltà con gesti di movimento precisi o intenzionali.

Consideriamo uno scenario concreto reale: un sito di e-commerce turco aggiunge una funzionalità “shake to shuffle” che mostra agli utenti un prodotto consigliato casuale quando scuotono il telefono, rendendo la navigazione più coinvolgente. La funzionalità è divertente e originale, ma non esiste un pulsante equivalente per attivare lo shuffle e non c’è modo di disattivare il rilevamento dello scuotimento. Una persona con il morbo di Parkinson che visita quel sito sperimenta attivazioni di shuffle costanti e incontrollate, poiché il suo tremore naturale attiva il gesto. Non può navigare con calma perché la pagina continua a saltare a prodotti casuali. Questa persona è di fatto esclusa da un’esperienza di acquisto normale — e secondo le normative sull’accessibilità della Turchia, questo non è solo un problema di UX ma un mancato rispetto degli obblighi legali.

Oltre all’accesso per le persone con disabilità, disabilitare o fornire alternative alle funzionalità basate sul movimento migliora anche l’esperienza per gli utenti in ambienti in cui il movimento del dispositivo è inaffidabile — sui mezzi pubblici, in ufficio o in qualsiasi contesto in cui un utente non può muovere liberamente il proprio dispositivo.

Regole Axe-core Correlate

WCAG 2.5.4 richiede test manuali perché gli strumenti automatici non possono rilevare in modo affidabile la presenza o l’assenza di funzionalità basate sul movimento analizzando solo HTML e CSS statici. L’attivazione tramite movimento dipende da event listener JavaScript e da comportamenti a runtime che gli scanner automatici non possono ispezionare completamente. Quanto segue spiega perché l’automazione non è sufficiente e cosa deve coprire la valutazione manuale.

• Non esiste una regola automatizzata axe-core diretta per 2.5.4. Axe-core e motori automatici simili funzionano ispezionando il DOM, gli attributi ARIA e gli stili calcolati. Non possono osservare se una pagina ha registrato un event listener devicemotion o deviceorientation, né possono determinare se esiste un controllo UI equivalente per qualsiasi funzionalità attivata dal movimento. Una pagina potrebbe avere un’ampia interattività basata sul movimento senza alcun indicatore visibile nel DOM, rendendo il rilevamento automatico intrinsecamente inaffidabile. Axe-core quindi segnala questo criterio come richiedente revisione manuale invece di tentare un rilevamento automatico che produrrebbe alti tassi di falsi negativi.
• È necessaria l’ispezione manuale degli event listener JavaScript. I tester devono usare gli strumenti di sviluppo del browser per cercare registrazioni di DeviceMotionEvent, DeviceOrientationEvent e API di visione/fotocamera come la Shape Detection API. Il pannello Event Listeners in DevTools del browser può rivelare se questi eventi sono collegati all’oggetto window o document.
• L’equivalenza funzionale non può essere automatizzata. Anche se uno strumento potesse rilevare un listener di movimento, non potrebbe determinare se un pulsante o un link altrove nell’interfaccia fornisce la stessa funzionalità. Valutare l’equivalenza funzionale richiede un tester umano che comprenda le funzionalità dell’applicazione e possa verificare che ogni azione attivata dal movimento abbia un’alternativa UI raggiungibile e azionabile.
• La possibilità di disabilitare non può essere automatizzata. Determinare se un utente può disattivare le risposte al movimento richiede l’interazione con le impostazioni o le preferenze dell’applicazione — un test comportamentale che gli strumenti automatici non sono progettati per eseguire in modo completo.

Come Testare

1. Scansione automatizzata come punto di partenza: Esegui axe DevTools, Lighthouse o il checker di accessibilità Accsible sulla pagina. Questi strumenti non segnaleranno automaticamente violazioni del criterio 2.5.4, ma potrebbero far emergere problemi correlati. Prendi nota di eventuali elementi segnalati, quindi procedi con i passaggi manuali. L’assenza di segnalazioni automatiche non significa che la pagina sia conforme al criterio 2.5.4.
2. Identifica le funzionalità attivate dal movimento: Apri Chrome DevTools e vai al pannello Elements. Cerca nei file sorgente JavaScript della pagina (usando la scheda Sources e la ricerca globale con Ctrl+Shift+F) le stringhe devicemotion, deviceorientation, accelerat, gyro e shake. Documenta ogni istanza trovata e la funzionalità associata.
3. Verifica che esistano alternative UI: Per ogni funzionalità attivata dal movimento individuata nel passaggio precedente, prova a compiere la stessa azione usando solo la navigazione da tastiera e i clic del mouse — senza movimento del dispositivo. Naviga nell’interfaccia usando Tab, Invio, Barra spaziatrice e tasti freccia. Se non riesci a trovare un controllo UI azionabile che produca lo stesso risultato, il criterio non è soddisfatto.
4. Verifica che il movimento possa essere disabilitato: Cerca un menu impostazioni, un pannello preferenze, impostazioni di accessibilità o un interruttore specifico per le funzionalità basate sul movimento. Prova a disabilitare l’attivazione tramite movimento. Se non esiste alcun controllo di questo tipo, o se disabilitare il movimento disabilita anche l’alternativa UI, il criterio non è soddisfatto.
5. Test su dispositivo fisico: Carica la pagina su uno smartphone o tablet reale. Muovi deliberatamente il dispositivo con delicatezza (simulando un tremore involontario — movimenti piccoli e continui) e osserva se la funzionalità viene attivata involontariamente. Poi ripeti lo stesso test dopo aver disabilitato il movimento tramite le eventuali impostazioni disponibili.
6. Test con screen reader e tastiera: Usando NVDA con Firefox, VoiceOver con Safari su iOS o JAWS con Chrome, naviga nella pagina usando solo la tastiera e i comandi dello screen reader. Conferma che tutte le funzionalità raggiungibili tramite movimento siano raggiungibili anche tramite la navigazione con screen reader e che il controllo per disabilitare il movimento (se presente) sia esso stesso accessibile da tastiera e correttamente etichettato.
7. Simulazione del dispositivo con DevTools del browser: In Chrome DevTools, apri il pannello Sensors (More Tools > Sensors) e usa i controlli di simulazione dell’orientamento del dispositivo e dell’accelerometro per attivare gli eventi di movimento in modo programmatico. Questo consente di testare su desktop il comportamento attivato dal movimento senza un dispositivo fisico.

Come Correggere

Shake-to-Refresh senza alternativa — Non corretto

<!-- Motion listener attached, but no UI button provided to refresh -->
<script>
  window.addEventListener('devicemotion', function(event) {
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
</script>
<div id='content'>...page content...</div>

Shake-to-Refresh senza alternativa — Corretto

<!-- Motion alternative: a visible button provides the same refresh action.
     A settings toggle lets users disable the motion trigger entirely. -->
<div id='motion-controls'>
  <button type='button' id='refresh-btn' onclick='refreshContent()'>
    Refresh Content
  </button>
  <label>
    <input type='checkbox' id='disable-motion' onchange='toggleMotion(this.checked)' />
    Disable shake-to-refresh
  </label>
</div>
<div id='content'>...page content...</div>
<script>
  var motionEnabled = true;
  function toggleMotion(disabled) {
    motionEnabled = !disabled;
  }
  window.addEventListener('devicemotion', function(event) {
    if (!motionEnabled) return;
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
  function refreshContent() {
    // fetch and update content
  }
</script>

Carousel Tilt-to-Scroll senza opzione di disabilitazione — Non corretto

<!-- Carousel advances on device tilt; no way to turn this off -->
<div id='carousel'>
  <div class='slide'>Slide 1</div>
  <div class='slide'>Slide 2</div>
  <div class='slide'>Slide 3</div>
</div>
<script>
  window.addEventListener('deviceorientation', function(event) {
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Carousel Tilt-to-Scroll senza opzione di disabilitazione — Corretto

<!-- Previous/Next buttons provide UI alternatives.
     A settings checkbox lets users opt out of tilt control.
     The carousel is also keyboard accessible via arrow keys. -->
<div id='carousel-wrapper'>
  <button type='button' aria-label='Previous slide' onclick='retreatCarousel()'>&laquo;</button>
  <div id='carousel' role='region' aria-label='Image carousel' aria-live='polite'>
    <div class='slide' aria-hidden='false'>Slide 1</div>
    <div class='slide' aria-hidden='true'>Slide 2</div>
    <div class='slide' aria-hidden='true'>Slide 3</div>
  </div>
  <button type='button' aria-label='Next slide' onclick='advanceCarousel()'>&raquo;</button>
</div>
<label>
  <input type='checkbox' id='disable-tilt' onchange='tiltEnabled = !this.checked' />
  Disable tilt navigation
</label>
<script>
  var tiltEnabled = true;
  window.addEventListener('deviceorientation', function(event) {
    if (!tiltEnabled) return;
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Funzionalità con gesto tramite fotocamera senza alternativa — Non corretto

<!-- User waves hand in front of camera to dismiss a modal;
     no button or keyboard method exists to dismiss it otherwise -->
<div id='modal' role='dialog' aria-modal='true' aria-label='Notification'>
  <p>Wave your hand to dismiss this message.</p>
</div>
<script>
  startCameraGestureDetection(function onWave() {
    document.getElementById('modal').hidden = true;
  });
</script>

Funzionalità con gesto tramite fotocamera senza alternativa — Corretto

<!-- A clearly labeled close button provides the UI alternative.
     The modal is fully keyboard operable and focus is managed correctly. -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Notification</h2>
  <p>Wave your hand or press the button below to dismiss this message.</p>
  <button type='button' id='dismiss-btn' onclick='dismissModal()'>Dismiss</button>
</div>
<script>
  function dismissModal() {
    document.getElementById('modal').hidden = true;
    // return focus to triggering element
  }
  startCameraGestureDetection(dismissModal);
  // Allow Escape key to also dismiss
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') dismissModal();
  });
</script>

Errori Comuni

• Fornire un pulsante UI alternativo ma dimenticare l’interruttore per disabilitare il movimento: Molti sviluppatori aggiungono un pulsante equivalente ma non implementano mai un modo per disattivare il listener di movimento, lasciando le persone con tremori a sperimentare ancora attivazioni indesiderate anche se la funzionalità è tecnicamente azionabile in altri modi.
• Nascondere l’opzione per disabilitare il movimento dentro un menu hamburger o in una pagina di impostazioni annidata: Il controllo per disabilitare il movimento deve essere esso stesso facilmente raggiungibile. Se una persona con tremore attiva ripetutamente lo shake-to-refresh prima di riuscire a navigare cinque livelli di menu per disabilitarlo, l’opzione di disabilitazione non è praticamente accessibile.
• Supporre che la preferenza di sistema “riduci movimento” soddisfi il criterio 2.5.4: La media query prefers-reduced-motion e le impostazioni di accessibilità del sistema operativo affrontano le animazioni e i problemi vestibolari, ma non disabilitano automaticamente i listener di movimento del dispositivo nelle applicazioni web. Devi gestire questo aspetto nel tuo codice.
• Impostare soglie di movimento troppo basse: Usare soglie molto sensibili per i valori di accelerazione di DeviceMotionEvent significa che tremori minori e involontari possono superare la soglia. Le soglie dovrebbero richiedere un movimento deliberato e di grande ampiezza, e anche in quel caso è comunque necessaria un’opzione di disabilitazione.
• Registrare listener di movimento globalmente su window senza mai rimuoverli: Collegare un listener e non fornire mai un percorso di codice per rimuoverlo con removeEventListener significa che l’interruttore di disabilitazione può solo sopprimere il comportamento in modo condizionale — se l’interruttore stesso fallisce o si resetta al ricaricamento della pagina, il movimento rimane attivo.
• Rendere inaccessibile la checkbox per disabilitare il movimento: Implementare l’interruttore di disabilitazione come un <div> o <span> stilizzato con un listener di click invece di un vero <input type='checkbox'> o di un controllo migliorato con ARIA significa che gli utenti di tastiera e screen reader non possono raggiungere o azionare il controllo stesso pensato per aiutarli.
• Non mantenere le preferenze di movimento dell’utente tra le sessioni: Se una persona disabilita l’attivazione tramite movimento ma la preferenza non viene salvata (ad esempio tramite localStorage o un’impostazione dell’account utente), deve disabilitarla di nuovo a ogni visita, creando un onere ripetuto proprio per le persone più interessate.
• Applicare in modo troppo estensivo l’eccezione della funzione essenziale: L’eccezione “essenziale” è ristretta. Una galleria di prodotti che usa lo shake-to-shuffle non è essenziale — la funzionalità di shuffle non è la funzione principale di un sito di shopping. I team a volte applicano in modo improprio questa eccezione per evitare il lavoro di implementazione.
• Non testare su un dispositivo fisico reale con movimento effettivo: Affidarsi esclusivamente a strumenti di simulazione su desktop o a scansioni automatiche significa che i problemi reali di sensibilità al movimento — incluso il modo in cui la funzionalità si comporta quando una persona ha un tremore naturale — non vengono mai scoperti finché non sono gli utenti a segnalarli.
• Dimenticare che anche le funzionalità basate sul movimento aggiunte da SDK o librerie di terze parti devono essere conformi: I listener di movimento incorporati in widget di chat di terze parti, SDK di gamification o strumenti di A/B testing fanno comunque parte della responsabilità di conformità della pagina. Se uno script di terze parti registra un listener devicemotion senza fornire un’alternativa, la pagina non soddisfa il criterio 2.5.4.

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 allineati a WCAG 2.2. WCAG 2.5.4 Motion Actuation è un criterio di Livello A, il che significa che rientra nel livello di priorità più alto di conformità obbligatoria ai sensi di questa circolare.

La circolare copre un’ampia gamma di soggetti del settore pubblico e privato. Le istituzioni pubbliche — incluse tutte le amministrazioni centrali e locali, i ministeri e gli enti pubblici — devono raggiungere la piena conformità al Livello A entro un anno dalla pubblicazione della circolare. I soggetti del settore privato nelle categorie coperte devono raggiungere lo stesso standard entro due anni. Le categorie coperte del settore privato includono piattaforme e marketplace di e-commerce, banche e istituzioni finanziarie, ospedali e strutture sanitarie private, società di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio autorizzate, società di trasporto private e scuole private che operano con autorizzazione del Ministero dell’Istruzione Nazionale (MoNE).

L’attivazione tramite movimento è particolarmente rilevante per i servizi digitali turchi perché l’uso di internet mobile in Turchia è molto elevato, con la maggior parte del traffico web proveniente da smartphone. Le applicazioni web mobile-first e mobile-only sono quindi estremamente comuni in tutti i settori coperti. Qualsiasi sito di e-commerce turco, applicazione bancaria o portale governativo che abbia implementato funzionalità di shake-to-refresh, navigazione tramite inclinazione, interazioni basate su gesti o funzionalità simili basate sul movimento senza fornire alternative UI e controlli di disabilitazione è in violazione diretta di un requisito obbligatorio di Livello A ai sensi della Circolare Presidenziale 2025/10.

Per i soggetti coperti che stanno preparando roadmap di conformità, l’attivazione tramite movimento dovrebbe essere valutata come parte di un audit più ampio sull’accessibilità mobile. Poiché gli strumenti automatici non possono rilevare le violazioni del criterio 2.5.4, le organizzazioni dovrebbero includere test manuali da parte di specialisti di accessibilità qualificati come parte del loro processo di verifica della conformità. Considerato che la circolare non prevede un periodo di grazia per le funzionalità implementate prima della sua pubblicazione — ma solo una tempistica per raggiungere la conformità — qualsiasi funzionalità basata sul movimento attualmente distribuita sui siti coperti deve essere corretta entro la scadenza applicabile.

I soggetti che non rispettano i requisiti della circolare possono incorrere in sanzioni amministrative e sono soggetti all’applicazione da parte delle autorità di vigilanza competenti per il loro settore. Oltre al rischio regolatorio, la mancata conformità al criterio 2.5.4 su un sito mobile turco ad alto traffico rappresenta un reale fallimento di usabilità per milioni di utenti che possono avere disabilità motorie, tremori o usare tecnologie assistive — una popolazione i cui bisogni sono esplicitamente riconosciuti e tutelati dall’adozione, da parte della circolare, di WCAG 2.2 Livello A come standard di base.