WCAG 2.5.6: Meccanismi di input simultanei

Cosa Significa Questa Regola

\n

WCAG 2.5.6 — Meccanismi di input concorrenti è un criterio di successo di livello AAA in WCAG 2.2. Il suo requisito principale è semplice: i contenuti web non devono limitare o interferire con la possibilità dell'utente di usare più meccanismi di input simultaneamente o in modo intercambiabile. In termini pratici, questo significa che una pagina web o un'applicazione non può rilevare in modo programmatico quale dispositivo di input l'utente stia utilizzando in quel momento e poi bloccarlo in quella singola modalità, negandogli l'accesso ad altri metodi di input disponibili.

\n

I dispositivi moderni supportano una grande varietà di meccanismi di input: tastiere fisiche, mouse e trackpad, touchscreen, stilo, controlli a interruttore, input vocale, tracciamento oculare e altro ancora. Molti utenti si affidano a più di uno di questi contemporaneamente — per esempio, una persona che usa un laptop con touchscreen può passare in modo fluido dal touchpad all'interfaccia touch con le dita. Un utente esperto può navigare in un modulo tramite tastiera mentre usa il mouse per scorrere. Una persona con disabilità motorie può usare una combinazione di puntatore a testa e dispositivo a interruttore. Il criterio protegge tutti questi flussi di lavoro.

\n

Si verifica un fallimento quando un sito web utilizza JavaScript per rilevare il tipo di input utilizzato e poi rimuove o disabilita funzionalità per altri tipi di input. Ad esempio, se un sito rileva un evento touch e successivamente rimuove gli indicatori di focus da tastiera o disabilita la navigazione da tastiera, si tratta di una violazione diretta. Allo stesso modo, bloccare l'input del puntatore dopo aver rilevato l'uso della tastiera, o utilizzare API della piattaforma per limitare artificialmente l'input a una singola modalità, costituisce un fallimento.

\n

Si ha un superamento quando gli utenti possono interagire con uno o tutti i meccanismi di input disponibili in qualsiasi momento durante la loro interazione. Il contenuto deve rispondere correttamente a qualunque meccanismo di input l'utente scelga di utilizzare in un dato momento, senza richiedere il ricaricamento della pagina, un cambio di modalità o qualsiasi azione aggiuntiva da parte dell'utente per riabilitare un tipo di input.

\n

Il criterio contiene un'unica eccezione ufficiale definita in WCAG: la restrizione è consentita quando è essenziale — cioè quando una specifica modalità di input è intrinsecamente richiesta. Un esempio classico è un'applicazione di riconoscimento della scrittura a mano in cui l'input touch o con stilo è l'essenza stessa della funzionalità. Un altro esempio può essere un campo per la raccolta di firme digitali che richiede un input specifico tramite puntatore. Anche in questi casi, l'eccezione dovrebbe essere interpretata in modo restrittivo e l'autore dovrebbe fornire mezzi alternativi per completare l'attività ogni volta che è possibile.

\n

È importante notare che questo criterio non richiede agli autori di aggiungere il supporto per meccanismi di input che il dispositivo non possiede. Regola le restrizioni imposte ai meccanismi che il dispositivo e la piattaforma supportano già. Se un dispositivo non ha un touchscreen, non c'è nulla da limitare.

\n\n

Perché È Importante

\n

La libertà di usare meccanismi di input concorrenti o intercambiabili non è una funzionalità di comodità — è un requisito di accessibilità critico che influisce direttamente su diversi gruppi distinti di utenti.

\n

Le persone con disabilità motorie si affidano spesso a tecnologie assistive che combinano più meccanismi di input. Una persona con mobilità limitata delle mani può usare un dispositivo a soffio e aspirazione insieme a una tastiera su schermo. Qualcuno con un tremore può iniziare a navigare una pagina tramite tastiera ma passare a un'interfaccia mouse o touch quando una scorciatoia da tastiera non funziona. Se un sito web rileva un tipo di input e ne disabilita altri, questi utenti possono essere completamente esclusi da contenuti o funzionalità.

\n

Le persone con disabilità cognitive o di apprendimento traggono spesso beneficio dalla possibilità di scegliere il metodo di input che risulta più comodo o naturale per un determinato compito. Imporre una singola modalità elimina quella scelta e può introdurre un carico cognitivo non necessario, in particolare quando l'utente non è esperto con il metodo di input principale del dispositivo.

\n

Le persone anziane, che possono avere difficoltà motorie legate all'età, utilizzano sempre più dispositivi che supportano sia l'input touch che quello da tastiera. La possibilità di passare da un meccanismo all'altro man mano che il controllo motorio fine fluttua durante la giornata è importante per un uso indipendente e continuativo del web.

\n

Gli utenti esperti e gli utenti di dispositivi multimodali — come gli utenti di Surface Pro o iPad Pro — usano regolarmente tastiera, stilo e interfaccia touch sullo stesso dispositivo nella stessa sessione. Un sito web che rileva l'input touch e rimuove le scorciatoie da tastiera, o viceversa, degrada l'esperienza di una vasta base di utenti che potrebbe non identificarsi come persona con disabilità.

\n

Consideriamo questo scenario reale: il portale online di una banca turca rileva che un cliente sta usando un tablet touchscreen e passa a una “modalità mobile” che disabilita la navigazione da tastiera. Un cliente con disabilità motoria che usa il tablet con una tastiera Bluetooth non può più spostarsi tra i campi di un modulo con il tasto Tab, navigare nei menu con i tasti freccia o usare scorciatoie da tastiera. Non può completare in modo indipendente le proprie operazioni bancarie. Questo non è solo un fallimento di accessibilità ma anche una potenziale esposizione legale ai sensi delle normative turche sull'accessibilità.

\n

Da una prospettiva di usabilità e SEO, rispettare i meccanismi di input concorrenti è correlato a punteggi migliori nelle Core Web Vitals, tassi di rimbalzo più bassi e maggiore soddisfazione degli utenti in diverse categorie di dispositivi — tutti segnali che i motori di ricerca premiano.

\n\n

Regole Axe-core Correlate

\n

WCAG 2.5.6 richiede test manuali — non esiste una regola automatizzata di axe-core che possa rilevare in modo affidabile tutte le violazioni di questo criterio. Il motivo è fondamentale: gli strumenti automatizzati possono ispezionare il DOM statico e il CSS, e possono rilevare alcuni pattern JavaScript, ma non possono osservare completamente il comportamento a runtime dei listener di eventi mentre rispondono a diverse modalità di input durante una sessione utente reale. La decisione di limitare un meccanismo di input è spesso codificata nella logica dell'applicazione che viene eseguita solo in risposta a eventi specifici, rendendo l'analisi statica insufficiente.

\n

\n
• Non esiste una regola automatizzata dedicata di axe-core per 2.5.6. Axe-core non include una regola che verifichi specificamente le restrizioni sui meccanismi di input concorrenti, perché la violazione si manifesta come comportamento JavaScript dinamico piuttosto che come problema strutturale di HTML o ARIA. Una pagina può superare tutti i controlli automatizzati di axe e violare comunque il criterio 2.5.6 se i suoi gestori di eventi rimuovono o disabilitano in modo programmatico le modalità di input a runtime.
\n
• Eventi di puntatore e rilevamento di eventi touch: Sebbene axe-core non possa rilevare direttamente la restrizione, gli auditor manuali dovrebbero cercare JavaScript che ascolta eventi touchstart o pointerdown e poi modifica il DOM, rimuove la gestione del focus o imposta flag che alterano il comportamento della tastiera. Allo stesso modo, i listener keydown che attivano cambi di classi CSS che nascondono i target touch sono segnali di allarme da ispezionare manualmente.
\n
• Perché l'automazione non è sufficiente: Gli scanner automatizzati analizzano il documento in un dato momento. Le restrizioni sui meccanismi di input sono condizionali — si attivano solo dopo che si verifica un evento di input specifico. Uno scanner che gira prima dell'interazione dell'utente non può vedere che un gestore touchstart chiamerà in seguito document.querySelectorAll('[tabindex]').forEach(el => el.setAttribute('tabindex', '-1')) distruggendo di fatto la navigazione da tastiera. Solo un tester umano che esercita entrambe le modalità di input in sequenza può scoprire questo fallimento.
\n

\n\n

Come Testare

\n

\n
1. Scansione automatizzata di base: Esegui axe DevTools o Lighthouse sulla pagina per stabilire una base e rilevare eventuali problemi concomitanti. Sebbene nessuno dei due strumenti abbia una regola dedicata per il criterio 2.5.6, i controlli di best practice di axe DevTools possono segnalare trappole da tastiera o problemi di gestione del focus che sono sintomatici di restrizioni sull'input. Annota eventuali fallimenti da correggere insieme ai controlli manuali descritti di seguito.
\n
2. Ispeziona il codice sorgente JavaScript e i listener di eventi: Apri Chrome DevTools, vai al pannello Elements e usa il riquadro Event Listeners per verificare se listener touchstart, pointerdown, pointermove o MSPointerDown sono associati al document o al body. Nella Console, cerca nel codice sorgente JavaScript della pagina pattern come ontouchstart in window, navigator.maxTouchPoints o 'pointer' in navigator combinati con modifiche al DOM. Queste sono tecniche comuni usate per rilevare la modalità di input e limitare la funzionalità.
\n
3. Test di interazione multimodale (tastiera + touch): Su un dispositivo che supporta sia l'input touch che quello da tastiera (ad esempio un Surface, un iPad con tastiera o un laptop touchscreen), inizia a navigare la pagina esclusivamente tramite tastiera (Tab, Shift+Tab, Invio, Barra spaziatrice, tasti freccia). Prendi nota di quali elementi interattivi sono raggiungibili e funzionanti. Poi, senza ricaricare la pagina, passa alla navigazione touch — tocca link, pulsanti e controlli di modulo. Verifica che tutta la funzionalità disponibile tramite tastiera rimanga accessibile tramite touch e viceversa. Documenta qualsiasi elemento che diventi irraggiungibile o non funzionante dopo il passaggio.
\n
4. Test di input combinato con screen reader: Usando NVDA con Firefox, naviga la pagina tramite tastiera per attivare la modalità screen reader. Poi usa il touchscreen (se disponibile) per provare a interagire con gli stessi elementi. Conferma che lo screen reader e la pagina rispondano correttamente a entrambi gli input. Ripeti con VoiceOver su Safari su un iPad, usando sia i gesti touch sia una tastiera Bluetooth associata. Con JAWS su Chrome, verifica che il passaggio tra tastiera e mouse non interrompa la gestione del focus o renda gli elementi interattivi non operabili.
\n
5. Revisione del codice per pattern di blocco della modalità: Esamina manualmente eventuali librerie o framework JavaScript utilizzati sulla pagina per rilevare meccanismi integrati di rilevamento della modalità. Alcune librerie UI, in particolare i framework mobile-first più datati, includono codice che disabilita eventi mouse o tastiera sui dispositivi in cui viene rilevato il touch. Controlla la documentazione e il sorgente della libreria per individuare tale comportamento e verifica che sia stato sovrascritto o disabilitato.
\n
6. Ripeti i test dopo interazioni dinamiche: Esegui azioni che attivano cambiamenti significativi del DOM — apertura di modali, navigazione tra route di una single-page app, invio di moduli — e ripeti il test multimodale dopo ogni transizione. Le restrizioni vengono talvolta introdotte solo in specifici stati dell'applicazione.
\n

\n\n

Come Correggere

\n

Rilevare il touch per disabilitare la navigazione da tastiera — Non corretto

\n

<!-- JavaScript rileva il touch e rimuove tutti i valori tabindex,\n     interrompendo la navigazione da tastiera per gli utenti che\n     cambiano modalità di input -->\n<script>\n  window.addEventListener('touchstart', function() {\n    document.querySelectorAll('a, button, input, [tabindex]').forEach(function(el) {\n      el.setAttribute('tabindex', '-1');\n    });\n  }, { once: true });\n</script>

\n

Rilevare il touch per disabilitare la navigazione da tastiera — Corretto

\n

<!-- Non limitare l'accessibilità da tastiera in base al rilevamento del touch.\n     Consenti il funzionamento concorrente di entrambe le modalità di input.\n     Se devi gestire gli stili di focus per motivi estetici, usa la\n     pseudo-classe CSS :focus-visible invece di rimuovere tabindex. -->\n<style>\n  /* Mostra gli anelli di focus solo per la navigazione da tastiera,\n     non per i clic del mouse, senza rimuovere del tutto l'accesso\n     da tastiera */\n  :focus:not(:focus-visible) {\n    outline: none;\n  }\n  :focus-visible {\n    outline: 3px solid #005fcc;\n    outline-offset: 2px;\n  }\n</style>\n<!-- Nessun rilevamento della modalità tramite JavaScript necessario -->

\n\n

Evento di puntatore usato per sopprimere eventi da tastiera — Non corretto

\n

<!-- Uno slider personalizzato che, dopo aver ricevuto input dal puntatore,\n     smette di rispondere ai tasti freccia della tastiera, bloccando\n     l'utente in un'interazione solo tramite puntatore -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var pointerUsed = false;\n  slider.addEventListener('pointerdown', function() {\n    pointerUsed = true;\n  });\n  slider.addEventListener('keydown', function(e) {\n    if (pointerUsed) return; // tastiera disabilitata dopo l'interazione con il puntatore\n    if (e.key === 'ArrowRight') { /* incrementa */ }\n    if (e.key === 'ArrowLeft') { /* decrementa */ }\n  });\n</script>

\n

Evento di puntatore usato per sopprimere eventi da tastiera — Corretto

\n

<!-- Sia le interazioni tramite puntatore che quelle tramite tastiera\n     sono gestite in modo indipendente. Nessun flag viene impostato\n     per impedire a una modalità di funzionare dopo che è stata usata\n     l'altra. -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var value = 50;\n\n  function updateSlider(newValue) {\n    value = Math.max(0, Math.min(100, newValue));\n    slider.setAttribute('aria-valuenow', value);\n  }\n\n  // Gestore del puntatore — sempre attivo\n  slider.addEventListener('pointermove', function(e) {\n    if (e.buttons === 1) {\n      // calcola il nuovo valore dalla posizione del puntatore\n    }\n  });\n\n  // Gestore della tastiera — sempre attivo, non disabilitato dall'uso del puntatore\n  slider.addEventListener('keydown', function(e) {\n    if (e.key === 'ArrowRight') updateSlider(value + 1);\n    if (e.key === 'ArrowLeft') updateSlider(value - 1);\n  });\n</script>

\n\n

Framework mobile che disabilita automaticamente gli eventi mouse — Non corretto

\n\n

(Content truncated due to token limit — please retry this article.)