Un clic sul web moderno nasconde un’assunzione: che la persona che clicca abbia una mano, un polso e un dispositivo di puntamento che si muove su due assi con precisione sub-pixel e un pulsante separato e affidabile per la pressione. Rimuovere uno qualsiasi di questi elementi cambia l’esperienza. Per chi guida la pagina con un eye-tracker, il «cursore» è un cono di sguardo da 1 grado d’arco che deriva e vibra. Per chi utilizza un head-pointer, il cursore è la punta del naso tracciata da una webcam con una selezione lenta tramite dwell. Per chi usa un’interfaccia di scansione a switch singolo, non esiste alcun cursore — solo un’evidenziazione scorrevole che si ferma su qualunque elemento abbia il focus quando l’utente preme lo switch. Ognuna di queste è una modalità di input reale, utilizzata oggi, nel 2026, da una popolazione abbastanza ampia da meritare l’attenzione del web moderno. La maggior parte del web moderno non ne è consapevole.
Il presente articolo è un primer concettuale sulle tre modalità di input alternative su cui fanno maggiore affidamento gli utenti con disabilità motorie — eye-tracking, head-pointing e switch input — e su come il livello degli standard (i criteri di successo WCAG 2.2, la specifica W3C Pointer Events) si interseca con i pattern di interfaccia utente che appaiono effettivamente in produzione. L’approccio è editoriale piuttosto che orientato al contenzioso: si analizza cosa funziona, cosa non funziona e cosa i progettisti possono smettere di fare domani.
Chi usa questi input, e perché
La popolazione che dipende da modalità di input alternative non è piccola. Le stime del Global Report on Health Equity for Persons with Disabilities dell’OMS (2022, con l’aggiornamento di monitoraggio del 2024) e del Disability and Health Data System del CDC statunitense collocano la quota di adulti con una significativa menomazione motoria agli arti superiori a circa l’8% della popolazione adulta nei Paesi ad alto reddito, e la quota di adulti che non riescono a utilizzare in modo affidabile un mouse o un trackpad standard a circa il 3-4%. All’interno di quel 3-4% si trovano diversi gruppi di utenti distinti, la cui modalità di input preferita è determinata dalla loro fisiologia più che dalla loro preferenza.
Il gruppo più definito è quello delle persone con sclerosi laterale amiotrofica (SLA), che perdono progressivamente il controllo volontario degli arti e, alla fine, della muscolatura facciale. Il tracciamento dello sguardo è, per molte persone con SLA avanzata, l’unico canale residuo per l’uso autonomo del computer. L’ALS Association stima che circa 30.000 persone vivano con la SLA negli Stati Uniti in qualsiasi momento; il registro europeo della SLA suggerisce una prevalenza simile corretta per età nell’UE. Il secondo gruppo è quello delle persone con lesione del midollo spinale ad alto livello — in particolare la tetraplegia C1-C4 — per cui le mani e le braccia sono inutilizzabili ma i movimenti oculari e della testa sono preservati. Il terzo è quello dei bambini e degli adulti con paralisi cerebrale, dove la strategia di input è altamente individuale: alcuni utenti hanno sufficiente controllo delle dita per un’interfaccia a switch, altri usano un head-pointer, altri ancora un joystick azionato col mento. Il quarto è quello delle persone con patologie neuromuscolari progressive — distrofia muscolare, sclerosi multipla in stadi avanzati — che spesso transitano attraverso diverse modalità di input nel corso del tempo.
Tra questi gruppi, due principi trasversali emergono con chiarezza. In primo luogo, quasi tutti coloro che usano un input alternativo lo fanno perché la combinazione standard mouse-tastiera è diventata fisicamente impossibile, non perché preferiscano una modalità innovativa. In secondo luogo, l’input è di solito su asse singolo in un senso fondamentale: una singola fissazione dello sguardo, una singola direzione dell’head-pointer, una singola pressione dello switch. I design che presuppongono due canali coordinati — un puntatore più un tasto modificatore, un movimento di trascinamento più un target di rilascio preciso — collassano in modo più grave per questo pubblico.
L’hardware nel 2026
Il panorama hardware è cambiato notevolmente negli ultimi tre anni. Quello che segue è una mappa approssimativa di ciò che gli utenti utilizzano concretamente, piuttosto che un catalogo completo.
Eye-tracker
Tobii Dynavox rimane il fornitore clinico dominante di eye-gaze. La generazione attuale — PCEye e I-Series — utilizza una barra sensore a infrarossi montata sotto un monitor o integrata in un tablet dedicato, e riporta la posizione dello sguardo al sistema operativo host come puntatore di sistema. La calibrazione richiede circa 30 secondi; la precisione in buone condizioni si aggira tra 0,5 e 1,0 gradi d’arco visivo, il che si traduce in un cono di sguardo di circa 30-60 pixel alla tipica distanza di visione. EyeGaze Edge (LC Technologies) e EyeTech VT3 sono alternative cliniche. Sul lato consumer, Tobii Eye Tracker 5 è venduto principalmente ai videogiocatori ma è ampiamente utilizzato come input di accessibilità a basso costo.
Il 2024 ha portato il primo eye-tracking di livello consumer integrato in un dispositivo informatico per uso generico: Apple Vision Pro utilizza l’eye-gaze come modalità di navigazione primaria, combinata con un gesto di pizzico per la selezione. visionOS espone la posizione dello sguardo alle funzioni di accessibilità dwell-selection a livello di sistema, e dal punto di vista dello sviluppatore una fissazione dello sguardo seguita da un pizzico viene riportata come un evento click standard. La popolazione con disabilità ha, prevedibilmente, adottato visionOS per la stessa ragione per cui ha adottato l’iPhone nel 2008: una modalità integrata progettata per l’uso mainstream che si rivela utile anche per il caso d’uso della disabilità. Il prezzo di Apple Vision Pro lo mette fuori dalla portata di molti utenti, ma il precedente — l’eye-gaze come input primario su un computer non medico — è quello che conta.
Head-pointer
Il software di head-pointing utilizza tipicamente la webcam integrata del dispositivo per tracciare un punto fiduciale — spesso la punta del naso o un piccolo adesivo riflettente applicato sulla fronte dell’utente — e traduce la rotazione della testa in movimenti del cursore. Camera Mouse (Boston College, gratuito) è l’implementazione più longeva e rimane in uso attivo. Glassouse fornisce un controller giroscopico indossabile montato sulla testa che si abbina al sistema operativo come mouse Bluetooth. macOS include Head Pointer come funzione di accessibilità integrata; Windows 11 dispone di funzionalità equivalenti tramite Eye Control se abbinato a hardware compatibile. La selezione con un head-pointer è quasi sempre basata sul dwell: il cursore si ferma su un target per un intervallo configurabile — tipicamente da 0,5 a 2,5 secondi — e un evento click scatta.
Switch input
Lo switch input è il più semplice e il più variabile dei tre. L’hardware è un singolo pulsante — un grande switch meccanico rotondo, un tubo sip-and-puff, una leva azionata col mento, un pedale, un’interfaccia cervello-computer in fase di ricerca avanzata — collegato a un’interfaccia switch standardizzata (un AbleNet Hook+, un Pretorian J-Pad, uno scudo Tecla) che si presenta al sistema operativo come una pressione di tasto USB o Bluetooth. Il software esegue quindi un’interfaccia di scansione: un indicatore di focus si sposta automaticamente tra i target disponibili sullo schermo e l’utente preme lo switch quando il focus raggiunge il target desiderato. La scansione a switch singolo utilizza un unico pulsante per tutto; la scansione a doppio switch mappa tipicamente uno switch su «avanza» e l’altro su «seleziona». iOS include Switch Control come funzione di accessibilità integrata; Android 14+ include Switch Access; macOS e Windows dispongono entrambi di funzionalità analoghe. Lo switch input è fondamentalmente seriale — l’utente non può puntare a un target; può solo attendere che la scansione lo raggiunga — e questo fatto determina ogni design pattern descritto di seguito.
Come si incontrano con il web: il livello degli standard
Dal punto di vista del browser, un eye-tracker e un head-pointer si comportano entrambi come dispositivi di puntamento standard: emettono eventi pointermove, pointerdown e pointerup tramite la specifica W3C Pointer Events, la stessa API utilizzata da un mouse o da un touchscreen. Lo switch input, al contrario, appare al browser come input da tastiera: il focus scorre tra gli elementi con focus e la pressione dello switch genera un evento keydown per Invio o Barra spaziatrice. Questa divergenza è la prima cosa che un progettista deve interiorizzare — gli utenti con eye-gaze attivano i vostri stati :hover e i vostri gestori di eventi puntatore; gli utenti con switch incontrano solo gli elementi focusabili da tastiera e l’ordine di focus che avete definito.
WCAG 2.2 contiene diversi criteri di successo scritti specificamente per mantenere funzionanti queste modalità di input. Tre di essi portano il peso maggiore.
SC 2.1.1 Tastiera (Livello A) è il requisito fondamentale: ogni elemento funzionale della pagina deve essere operabile tramite un’interfaccia da tastiera da sola. Gli utenti con switch ne dipendono in modo assoluto. Un elemento che risponde solo a un clic del mouse — un div personalizzato con un gestore click e senza tabindex, senza role, senza gestore keydown — è invisibile a un utente con switch. È invisibile anche a molti utenti con head-pointer che ricorrono alla navigazione da tastiera per sezioni della pagina dove il dwell-click è troppo lento.
SC 2.5.1 Gesture del puntatore (Livello A) richiede che qualsiasi funzione operata tramite un gesto multipunto o basato su percorso sia operabile anche con un’azione a puntatore singolo. Il criterio esiste perché eye-gaze, head-pointer e molti input alternativi non riescono a eseguire in modo affidabile gesti multi-dito o percorsi di trascinamento precisi. Un pinch-to-zoom senza pulsante alternativo. Uno swipe-to-delete senza controllo di eliminazione a schermo. Un elenco drag-to-reorder senza equivalente da tastiera. Ognuno di questi è un fallimento del criterio 2.5.1 e ognuno preclude la modalità di cui l’utente dispone effettivamente.
SC 2.5.2 Cancellazione del puntatore (Livello A) richiede che per qualsiasi attivazione a puntatore singolo, l’azione non si esegua sull’evento down (ma sull’evento up), oppure si esegua sull’evento down ma consenta all’utente di annullarla spostandosi via prima dell’evento up. Il criterio è scritto per gli utenti che colpiscono il target sbagliato a causa di un tremore o di una deriva, ed è fondamentale per le interfacce dwell-based di head-pointer e eye-gaze: un clic che scatta nell’istante in cui il cursore si posa non dà all’utente alcuna possibilità di recuperare da una deriva dello sguardo. I pulsanti che associano il proprio gestore a mousedown anziché a click non rispettano questo criterio.
Il SC 2.5.7 Movimenti di trascinamento (aggiunto in WCAG 2.2) estende la protezione dei gesti al drag-and-drop specificamente: qualunque elemento trascinabile deve essere raggiungibile anche tramite un’alternativa a puntatore singolo, tipicamente un controllo di spostamento su/giù tramite pulsante. Il SC 2.5.4 Attivazione tramite movimento (Livello A) protegge gli utenti che non riescono ad agitare o inclinare in modo affidabile il proprio dispositivo. E il SC 2.2.1 Regolazione dei tempi (Livello A) e il SC 2.2.2 Pausa, stop, nascondi (Livello A) proteggono tutti dalle interfacce che scadono prima che un’interfaccia di scansione riesca a raggiungere il controllo pertinente.
Questi criteri sono scritti come un unico frame integrato: l’utente dispone di un solo asse di input, l’input è lento, e il design non deve presupporre nulla di diverso.
Errori comuni sui siti in produzione
Confrontando questi criteri con ciò che i siti in produzione distribuiscono effettivamente, emerge un insieme ricorrente di pattern di fallimento. Nessuno di questi è esotico. Tutti compaiono nei normali test utente con eye-tracker, head-pointer e switch.
Drag-and-drop senza alternativa da tastiera. Un pattern comune negli strumenti di project management, nei file manager e nelle interfacce con elenchi classificabili: trascinare una scheda da una colonna a un’altra. Per gli utenti con switch l’azione è impossibile — nella scansione non esiste alcun trascinamento. Per gli utenti con head-pointer ed eye-gaze, il trascinamento stesso è circa 4-5 volte più lento di un’azione tramite pulsante ed è di solito impossibile da completare senza rilasciare l’elemento a metà percorso. La correzione è semplice: abbinare ogni drag-and-drop a un’azione di spostamento tramite pulsante, esposta nell’ordine di tab da tastiera. Il pattern del menu Trello «sposta scheda su / sposta scheda giù / sposta in un altro elenco» è l’implementazione di riferimento.
Navigazione solo tramite hover. Menu a discesa, tooltip e controlli di disclosure che compaiono solo al :hover e scompaiono quando il cursore si allontana. Per un utente con eye-gaze, il cono di sguardo deriva fuori dal trigger del menu nel momento in cui cerca di guardare una sotto-voce, e il menu collassa prima che la raggiunga. Il criterio WCAG 2.2 che gestisce questo caso è il 1.4.13 Contenuto al passaggio del puntatore o al focus (Livello AA): il contenuto attivato al hover deve essere ignorabile, hoverable (l’utente può spostarsi all’interno senza che scompaia) e persistente. Molti menu in produzione falliscono tutti e tre i requisiti.
Target di clic troppo piccoli. Il SC 2.5.8 Dimensione del target (minimo) (Livello AA, nuovo in WCAG 2.2) richiede che i target interattivi abbiano almeno 24x24 pixel CSS, con eccezioni. Il criterio è stato scritto per il touch e per gli utenti con puntamento impreciso — eye-gaze, head-pointer, tremore della mano. Un’icona di chiusura da 16 pixel nell’angolo di una modale è, in pratica, quasi impossibile da centrare in modo affidabile con un eye-tracker. La correzione è meccanica: rendere i target più grandi, oppure esporre la stessa azione tramite un controllo più grande altrove nell’interfaccia.
Clic con limiti di tempo. Caroselli che avanzano automaticamente ogni 5 secondi, finestre di dialogo «hai 30 secondi per confermare», timeout di sessione che scattano durante un’attività. Per un utente con switch che naviga un’interfaccia di scansione a 1,5 secondi per target, un timeout di 30 secondi corrisponde a circa 20 target di spazio reale raggiungibile — spesso non abbastanza per raggiungere il pulsante di conferma. Il SC 2.2.1 Regolazione dei tempi richiede che qualsiasi limite di tempo sia estensibile, regolabile o ignorabile. La maggior parte dei timeout in produzione non soddisfa nessuno di questi requisiti.
Conferma solo tramite gesture. Slider swipe-to-confirm, conferme tramite firma digitale, captcha che richiedono di tracciare un percorso. Ognuno di questi è un fallimento del criterio 2.5.1 a meno che non sia abbinato a un’alternativa con pulsante.
Azione su mousedown. Un pulsante che attiva il proprio gestore su mousedown anziché sull’evento click standard non lascia all’utente alcun modo per annullare un errore. Il SC 2.5.2 Cancellazione del puntatore è il criterio; la correzione consiste nel collegare l’evento a click, oppure a pointerup con un controllo esplicito di annullamento.
Controlli personalizzati senza ARIA. Un <div> che visivamente sembra un pulsante ma è privo di role=“button”, tabindex=“0” e di un gestore keydown per Invio e Barra spaziatrice. Il controllo è irraggiungibile tramite switch e tramite il fallback da tastiera. Il SC 4.1.2 Nome, ruolo, valore (Livello A) è il criterio. La correzione è l’elemento nativo <button> ovunque sia possibile, e un pattern ARIA completo dove non lo è.
Design pattern che funzionano
I pattern che resistono a un eye-tracker, a un head-pointer e a una scansione con switch condividono un piccolo numero di proprietà strutturali. Ognuno è ben documentato nella ARIA Authoring Practices Guide e nei documenti di comprensione di WCAG 2.2, e ognuno è in uso corrente in produzione su siti che si rivolgono a pubblici mainstream senza che nessuno lo noti.
Elementi HTML nativi ovunque sia possibile. La singola scelta di accessibilità più affidabile è utilizzare <button>, <a>, <input>, <select> e <textarea> per i loro scopi semantici. Gli elementi nativi vengono forniti con la giusta gestione da tastiera, i giusti ruoli ARIA, il giusto comportamento del focus e la giusta semantica di cancellazione del puntatore integrati. La complessità di ricostruire correttamente uno qualsiasi di questi con un <div> personalizzato è circa 10 volte superiore al lavoro di progettazione per un risultato quasi sempre peggiore.
Indicatori di focus visibili con contrasto adeguato. Per gli utenti con switch l’anello di focus è il cursore. Un anello blu da 2 pixel con contrasto 4:1 rispetto allo sfondo circostante è il minimo procedurale (SC 2.4.7 Focus visibile, Livello AA, e SC 2.4.11 Focus non oscurato, nuovo in WCAG 2.2). I siti che rimuovono l’anello di focus predefinito del browser senza sostituirlo lasciano gli utenti con switch senza orientamento.
Ordine di focus prevedibile. Una scansione con switch scorre il DOM in ordine sorgente per impostazione predefinita, modificato da tabindex. Un ordine di scansione che salta per la pagina rende l’interfaccia inutilizzabile. Il SC 2.4.3 Ordine di focus (Livello A) è il criterio; l’implicazione pratica è che l’ordine visivo e l’ordine del DOM dovrebbero coincidere ovunque l’utente stia eseguendo una sequenza di azioni.
Aree di attivazione generose. Il minimo di 24 pixel del SC 2.5.8 è il pavimento, non l’obiettivo. Molti dei design system che hanno pubblicato pattern testati per l’accessibilità dal 2022 — Adobe Spectrum, IBM Carbon, GOV.UK Design System, il US Web Design System — adottano target touch da 44 pixel per impostazione predefinita, che funzionano bene per gli utenti con puntamento impreciso senza incidere sul layout visivo.
Flussi di conferma con pulsanti espliciti. Qualsiasi azione distruttiva o irreversibile dovrebbe richiedere un pulsante di conferma esplicito — non uno swipe, non una long-press, non un «clicca ovunque all’esterno per ignorare». Il pattern funziona per tutti e resiste a qualsiasi input alternativo.
Timeout generosi, o nessuno. Se un timeout è richiesto per motivi di sicurezza (settore bancario, sanitario), l’utente deve poter estenderlo tramite un’azione a puntatore singolo ben prima che scatti. Il pattern consiste nel mostrare un avviso «Sei ancora lì?» al 75% della finestra del timeout, con un singolo pulsante grande per estenderlo.
Skip link e navigazione per landmark. Un’interfaccia di scansione che deve attraversare l’intero menu di navigazione, l’intera sezione hero e l’intero slot pubblicitario prima di raggiungere il corpo dell’articolo è inutilizzabile. Un link «Vai al contenuto» come primo elemento focusable della pagina è il minimo; le regioni landmark (<main>, <nav>, <aside>) consentono agli utenti con switch di spostarsi strutturalmente anziché linearmente.
Rispettare l’impostazione prefers-reduced-motion dell’utente. I caroselli ad avanzamento automatico e gli sfondi costantemente animati rendono impossibile per un eye-tracker stabilizzarsi su un target. Le media query CSS (@media (prefers-reduced-motion: reduce)) consentono alla stessa interfaccia di servire l’utente che ha bisogno che il movimento sia assente.
Cosa significa per progettisti, ingegneri e product team
Il quadro documentato sulle modalità di input alternative porta a una conclusione che dovrebbe essere familiare a chi ha letto gli altri primer sull’accessibilità di Disability World. La tecnologia ha raggiunto la maturità. Gli standard hanno raggiunto la maturità. Le popolazioni di utenti sono ben caratterizzate. Il lavoro restante riguarda gli acquisti, la formazione e l’abitudine quotidiana di costruire interfacce che non presuppongano silenziosamente un input bidirezionale, a due mani, con latenza sub-secondo.
Per i progettisti: si raccomanda di prototipare con la tastiera. Se un design funziona con la sola navigazione tramite tab e un anello di focus visibile, funziona per un utente con switch; se non funziona, il design visivo ha superato il modello di interazione. Il precedente di Apple Vision Pro con gaze-plus-pinch ridefinisce l’input alternativo come la baseline progettuale piuttosto che una correzione. I design che resistono a Vision Pro tendono a resistere a Tobii.
Per gli ingegneri: si raccomanda di collegare gli eventi a click anziché a mousedown. Usare elementi HTML nativi. Testare l’ordine di tab. Far passare la pagina attraverso un audit solo da tastiera prima del rilascio. La maggior parte degli errori sopra descritti è una questione di convenzione ingegneristica piuttosto che di difficoltà ingegneristica.
Per i product team: si raccomanda di includere gli utenti di modalità di input alternative nei test utente di routine. Le barriere sopra descritte non sono casi limite; sono fallimenti ordinari che emergono in 30 minuti di test con una barra Tobii o con un dispositivo iOS con Switch Control attivo. Il costo di includere la modalità nel piano di test è basso. Il costo di non includerla si manifesta come gli errori sopra descritti, distribuiti su larga scala, a una popolazione le cui opzioni sono già limitate.
Il web funziona quando accetta che il clic non sia il verbo universale. L’utente con una barra Tobii montata sotto il monitor, l’utente con una webcam che traccia la punta del naso, l’utente con un singolo switch meccanico collegato all’angolo di una scrivania — ognuno di loro sta compiendo la stessa azione di un utente con un trackpad. Il livello degli standard lo riconosce. I design pattern sopra descritti lo rispettano. Il lavoro consiste nel continuare a costruire come se fosse vero.
Per ulteriori approfondimenti da Disability World, si rimanda ai criteri di successo WCAG 2.2, al quadro generale dei dati 2026 e alla nostra copertura continuativa delle tecnologie assistive.