Ogni diciotto mesi, un ciclo stampa sull’hardware di realtà mista promette un futuro inclusivo. Il lancio di Apple Vision Pro nel 2024 ne ha promesso uno. Il lancio di Meta Quest 3, e il più economico Quest 3S che è seguito, ne ha promesso un altro. La specifica WebXR — lo standard W3C per la RA e la RV renderizzate nel browser — ne promette uno dal 2018. La realtà, a metà del 2026, è più sobria: sul mercato esiste esattamente un visore consumer con una superficie di accessibilità seria e nativa, e il livello browser neutro rispetto alle piattaforme sottostante a tutto questo è ancora un vuoto strutturale dove dovrebbero trovarsi testo alternativo, gestione del focus e semantica delle tecnologie assistive. Questo testo è una guida su dove si trova effettivamente la tecnologia — cosa funziona oggi, cosa è solo una promessa, e cosa uno sviluppatore nel 2026 dovrebbe e non dovrebbe distribuire.
La prospettiva è editoriale piuttosto che evangelica. Non si sostiene che la XR sia intrinsecamente più o meno accessibile del web bidimensionale. Si sostiene che la storia degli sviluppatori per l’accessibilità XR nel 2026 assomigli grossomodo alla storia degli sviluppatori per l’accessibilità web nel 2002: uno standard emergente con la maggior parte delle parole mancanti, due piattaforme dominanti che avanzano a velocità diverse, e un piccolo gruppo di utenti con disabilità che porta la maggior parte delle conoscenze pratiche nella propria memoria muscolare.
Il panorama hardware nel 2026
Tre dispositivi dominano oggi il mercato consumer della realtà mista, e prendono tre posizioni diverse sull’accessibilità. Apple Vision Pro, che esegue visionOS 2.4, è l’unico dei tre con una seria superficie di accessibilità integrata nel sistema operativo stesso — VoiceOver nello spazio 3D, controllo con switch, personalizzazione del tracciamento della mano, tracciamento oculare come input primario e un’implementazione di Spatial Audio che gli utenti con disabilità hanno ripetutamente descritto come la più utilizzabile della categoria. Meta Quest 3 e il meno costoso Quest 3S condividono un sistema operativo — Horizon OS — con uno strato di accessibilità più sottile: modalità ad alto contrasto, rimappatura dei controller, un filtro di correzione del colore, comandi vocali per la navigazione e uno screen reader (aggiunto a metà del 2024) che funziona all’interno della shell del sistema ma non in modo affidabile all’interno delle app di terze parti. Il Sony PlayStation VR2 non include di fatto funzionalità di accessibilità native nella sua shell VR, anche se eredita il livello di accessibilità più ampio di PS5 quando esegue contenuti a schermo piatto.
I prezzi si sono spostati in modo significativo. Il Vision Pro originale è stato lanciato a circa 3.499 dollari USA; il Quest 3 costa circa 499 dollari USA e il Quest 3S circa 299 dollari USA. Questo divario conta per un argomento sull’accessibilità, perché il dispositivo con la storia di input per la disabilità più forte è anche quello che la grande maggioranza degli utenti con disabilità non può permettersi di acquistare senza un percorso di accomodamento ragionevole finanziato dal datore di lavoro. La forma del mercato a metà del 2026 è, in termini semplici: il visore accessibile è costoso, e il visore economico è, a livello di sistema, accessibile principalmente nel senso che non impedisce attivamente di utilizzarlo.
La categoria al di là di questi tre — occhiali intelligenti a sola passthrough come Ray-Ban Meta, occhiali con display di classe Xreal Air e vari visori enterprise utilizzati in flussi di lavoro chirurgici e industriali — è in gran parte al di fuori della conversazione sull’accessibilità XR consumer. La maggior parte di questi dispositivi non esegue un sistema operativo di classe desktop, non espone un’API di accessibilità a livello di sistema e viene distribuita in un panorama normativo che li tratta come accessori indossabili piuttosto che come computer.
La specifica WebXR — e cosa non dice ancora
WebXR è la specifica W3C che consente a un browser di dare a un sito web accesso a un dispositivo AR o VR collegato. Espone un oggetto sessione, un contesto di rendering (di solito stratificato su WebGL2 o WebGPU) e un modello di sorgente di input per mani, controller e sguardo. Il supporto dei browser, a metà del 2026, è più solido nei browser basati su Chromium (Chrome, Edge, Brave e una manciata di browser XR per dispositivi mobili), parziale in Firefox tramite una build enterprise e storicamente assente in Safari — visionOS Safari supporta la specifica ma solo all’interno di sessioni immersive e con la semantica di input fornita dalla pipeline di tracciamento della mano di Apple. La posizione di WebKit su WebXR si è spostata in modo significativo negli ultimi dodici mesi, ma è ancora una superficie meno matura rispetto alla sua controparte Chromium.
La specifica copre ciò che il visore può fare — renderizzare fotogrammi stereo, riportare i dati di posa, esporre trasformazioni di presa e puntamento, ascoltare eventi di selezione da un controller o un gesto di pizzico. Non dice quasi nulla sull’accessibilità. Non esiste un equivalente di un attributo alt per un oggetto nello spazio 3D. Non esiste un modello di focus formale che una tecnologia assistiva possa scorrere. Non esiste un modo a livello di specifica per etichettare un pulsante virtuale in modo che uno screen reader possa annunciarlo. La cosa più vicina a un hook di accessibilità nella specifica WebXR oggi è l’array profiles della sorgente di input, che consente a un sito di identificare se l’input è una mano, un controller o un cursore di sguardo — e quell’array esiste per ragioni di rendering dei contenuti, non per ragioni di tecnologia assistiva.
Questa non è una critica al W3C — è una dichiarazione su dove il lavoro è stato e non è stato fatto. La bozza dei requisiti utente per l’accessibilità WebXR (XAUR) esiste al W3C, e l’Immersive Web Working Group ha riconosciuto la maggior parte delle lacune rilevanti. Ma XAUR è un documento di requisiti, non una specifica normativa, e il divario tra «sappiamo cosa ha bisogno la specifica» e «la specifica lo dice normativamente» è, in pratica, il luogo dove vive la maggior parte degli utenti con disabilità oggi.
Accessibilità di Apple Vision Pro, nel dettaglio
Vision Pro è la storia di accessibilità più solida sul mercato XR consumer oggi, e il divario rispetto a tutti gli altri non è sottile. L’input primario del visore è il tracciamento oculare — l’utente guarda un obiettivo e il cono dello sguardo definisce l’elemento focalizzato — combinato con un piccolo insieme di gesti della mano rilevati da fotocamere rivolte verso il basso. Per gli utenti con disabilità, Apple ha aggiunto diverse superfici che cambiano materialmente ciò che è possibile all’interno di visionOS.
Il tracciamento oculare come input primario significa che gli utenti con gravi menomazioni motorie degli arti superiori possono guidare l’intero sistema operativo senza movimenti delle mani o delle braccia, purché il loro sguardo sia sufficientemente affidabile da fissarsi su un obiettivo per la durata della permanenza. Le alternative al tracciamento della mano consentono agli utenti di sostituire i tocchi con un singolo dito, i movimenti del polso o i gesti della sola testa quando il pizzico e il tocco predefiniti non sono affidabili — una superficie particolarmente importante per gli utenti con condizioni neuromuscolari che influenzano il controllo fine delle dita. VoiceOver nello spazio 3D legge l’elemento focalizzato nei contesti immersivi e utilizza Spatial Audio per indicare la posizione spaziale dell’elemento rispetto alla testa dell’utente — un’esperienza significativamente diversa da uno screen reader su schermo piatto, e che, quando funziona, riduce il carico cognitivo della costruzione di un modello mentale della scena.
Spatial Audio per l’accessibilità va oltre VoiceOver. I segnali audio per gli eventi di sistema — notifiche, cambiamenti di focus, apertura di finestre di dialogo — sono posizionati nello spazio 3D in modo che un utente ipovedente o non vedente possa localizzarli senza dover scorrere lo sguardo. Il controllo con switch funziona all’interno delle sessioni immersive, anche se l’input deve essere abbinato attraverso la stessa configurazione di accessibilità Apple come su iPadOS o macOS. Le audiodescrizioni sono esposte all’interno dell’app Apple TV per i video immersivi. E il puntamento con la testa esiste come alternativa aggiunta di recente per gli utenti il cui occhio non traccia in modo affidabile, anche se è più lento e più affaticante rispetto all’impostazione predefinita guidata dagli occhi.
Nulla di tutto ciò è perfetto. VoiceOver nelle app di terze parti dipende ancora dallo sviluppatore che colleghi correttamente i componenti SwiftUI o RealityKit, e il catalogo di app di terze parti è piccolo. La personalizzazione del tracciamento della mano richiede di attraversare diversi livelli di impostazioni e non è intuitiva. La calibrazione del tracciamento oculare stessa può fallire ripetutamente per gli utenti con strabismo, nistagmo o dismetria dello sguardo post-ictus. Ma rispetto a qualsiasi altro visore consumer sul mercato nel 2026, la superficie di accessibilità di Vision Pro è l’unica con cui un utente con disabilità può sedersi e ragionevolmente aspettarsi di usare il dispositivo.
Accessibilità di Meta Quest 3 e 3S, nel dettaglio
Horizon OS si è aggiornato negli ultimi diciotto mesi, ma il divario con visionOS è reale. Quest 3 e Quest 3S includono uno screen reader a livello di sistema che annuncia gli elementi dell’interfaccia utente della shell — Home, Libreria, Store, Impostazioni — e che funziona in modo ragionevolmente affidabile nelle app di Meta stessa. Al di fuori della shell, il quadro cambia: la maggior parte delle app VR di terze parti renderizza la propria interfaccia utente all’interno del proprio motore (Unity o Unreal nella maggior parte dei casi) e non alimenta il testo nello screen reader di sistema. Un utente non vedente può aprire lo store di Quest, ma non può giocare in modo affidabile alla maggior parte di ciò che acquista.
I comandi vocali esistono per la navigazione nella shell («apri Libreria», «vai alla Home») e in un piccolo insieme di app. La modalità ad alto contrasto e un filtro di correzione del colore esistono a livello di sistema. La rimappatura dei controller funziona nell’interfaccia utente della shell e nel piccolo insieme di app che consumano il livello di astrazione dell’input di Meta piuttosto che leggere direttamente i pulsanti del controller. Il tracciamento della mano esiste come modalità di input, e il firmware recente ha migliorato l’insieme dei gesti, ma il sistema di tracciamento della mano di Quest è stato progettato come alternativa senza controller per utenti non disabili, non come input di accessibilità — non esiste un clic a permanenza, nessun puntatore di testa di riserva, nessun equivalente del tocco con un solo dito di Vision Pro.
La lacuna più significativa, per un pubblico di sviluppatori, è l’assenza di un’API di accessibilità pubblica per Horizon OS. Uno sviluppatore che costruisce un’app Quest basata su Unity non può oggi leggere le impostazioni di accessibilità del sistema, non può registrare l’app con lo screen reader di sistema e non può esporre obiettivi di focus etichettati al sistema in un modo che sopravviva tra le app. La roadmap di accessibilità di Quest che Meta ha pubblicato all’inizio del 2025 si impegna per tale API, ma a metà del 2026 non è ancora disponibile.
L’intersezione ARIA + WebXR — e la promessa mancata dell’input vocale
La specifica ARIA — l’insieme di attributi che consentono a uno sviluppatore di esporre ruoli, stati e proprietà alla tecnologia assistiva — è stata progettata per documenti bidimensionali. Ruoli come button, dialog, tab e navigation presuppongono un modello di focus che si sposta lungo l’albero del documento. WebXR non ha un albero del documento nel senso di WebGL o WebGPU — esiste un grafo della scena, ma vive all’interno dell’applicazione, non nell’albero di accessibilità del browser. L’intersezione di ARIA e WebXR, a metà del 2026, è in gran parte un’assenza: il browser non può vedere la struttura della scena 3D, lo screen reader non può scorrerla e lo sviluppatore non può etichettare dichiarativamente gli oggetti virtuali come può etichettare i pulsanti HTML.
Esistono soluzioni parziali. Un sito WebXR può renderizzare una superficie di accessibilità parallela basata sul DOM — una struttura HTML nascosta che rispecchia gli elementi interattivi della scena 3D, con ruoli e label ARIA appropriati, e che aggiorna il focus quando cambia la selezione 3D. Questo schema funziona ma è laborioso; raddoppia il costo di sviluppo e tende a divergere man mano che la scena 3D si evolve. L’Immersive Web Working Group del W3C ha discusso una proposta normativa di «elemento 3D accessibile» che esporrebbe i nodi del grafo della scena all’albero di accessibilità, ma la discussione non è ancora a una fase di bozza di specifica.
L’altra intersezione che dovrebbe esistere ormai e non esiste è l’input primario vocale. Il vocale è stato, per diversi anni, la risposta retorica a «come navigherà un utente con disabilità motorie in una scena 3D senza mani?». La realtà, nel 2026, è che l’input vocale all’interno della XR immersiva è fragile. Il microfono è posizionato vicino alla bocca dell’utente ma all’interno di un visore la cui acquisizione del suono è ottimizzata per il rendering audio spaziale su scala di stanza, non per la cattura del parlato. Gli intervalli di confidenza sul riconoscimento dei comandi vocali all’interno di Vision Pro e di Quest sono ben al di sotto del valore equivalente su uno smartphone. La promessa di «basta parlargli» non si è materializzata, e il flusso di lavoro della tecnologia assistiva all’interno della XR rimane ancora guidato da gesti e sguardo, con il vocale come supplemento inaffidabile piuttosto che come modalità primaria.
La terza intersezione, e quella con la coda più lunga, è la questione della navigazione gestuale rispetto a quella con bastone. Gli utenti non vedenti nello spazio fisico navigano usando un bastone bianco, un cane guida o segnali di ecolocalizzazione; il modello spaziale che costruiscono è ancorato a ostacoli a livello del pavimento e alla propriocezione del corpo. La maggior parte delle scene XR è progettata attorno a un utente seduto o in piedi i cui obiettivi di interazione galleggiano all’altezza del petto all’interno di un’area di scala di stanza. Il disallineamento non è estetico — è strutturale. Il modello «bastone» di navigazione, in cui l’utente sposta la propria attenzione lungo una sonda a bassa energia attraverso la scena, non si mappa su nessun input che i runtime XR attuali supportino. Un sito WebXR che volesse esporre una superficie di navigazione con bastone a un utente non vedente dovrebbe inventare la superficie da solo, senza aiuto dal browser, dalla specifica o dal sistema operativo.
Dove dovrebbero andare gli sviluppatori nel 2026
Se si stanno costruendo esperienze XR nel 2026 e si desidera che siano utilizzabili da utenti con disabilità, la risposta onesta è: non distribuire ancora WebXR basato su browser a utenti con disabilità, se non come contenuto supplementare. Si distribuiscano app native per visionOS se il budget lo consente, perché è l’unica piattaforma in cui la superficie di accessibilità è reale, le API a livello di sistema funzionano e un utente con disabilità può abbinare l’app alla tecnologia assistiva che già conosce. Si distribuiscano app native per Quest con cautela, sapendo che la superficie di accessibilità del sistema intercetterà le interazioni a livello di shell ma non quelle all’interno delle app, e che lo sviluppatore è responsabile della costruzione dell’equivalente di un albero di accessibilità all’interno del proprio motore.
Per WebXR in particolare, la postura responsabile nel 2026 è quella di trattarlo come un miglioramento progressivo. Si costruisca prima l’esperienza come una superficie HTML piatta e accessibile che soddisfa i criteri di successo WCAG 2.2 pertinenti. Si stratifichi l’esperienza XR immersiva sopra per gli utenti che la desiderano e possono utilizzarla, e ci si assicuri che la superficie piatta offra gli stessi contenuti e gli stessi risultati. Non si distribuisca, nel 2026, un sito WebXR che non abbia una versione di riserva piatta aspettandosi che un utente con disabilità trovi un percorso alternativo attraverso di esso — non ne esiste uno.
Il quadro d’insieme è che la storia dell’accessibilità XR si trova in un punto di svolta simile a quello in cui si trovava la storia dell’accessibilità del web vent’anni fa: gli standard si stanno aggiornando, le piattaforme stanno divergendo, e il divario tra «ciò di cui gli utenti con disabilità hanno bisogno» e «ciò che la specifica richiede normativamente» è ampio. Il lavoro che deve avvenire nei prossimi due anni — XAUR che passa dai requisiti a una specifica normativa, la proposta di albero di accessibilità per il 3D che si stabilizza, il miglioramento dell’input vocale all’interno dei visori e un’API di accessibilità per Horizon OS che viene effettivamente distribuita — è identificabile. Se accade nei tempi di cui ha bisogno la comunità di utenti è una domanda diversa, che questa pubblicazione continuerà a seguire.