Elke achttien maanden belooft een persronde voor mixed-reality-hardware een inclusieve toekomst. De lancering van de Apple Vision Pro in 2024 beloofde er een. De lancering van de Meta Quest 3, en de goedkopere Quest 3S die volgde, beloofde er nog een. De WebXR-specificatie — de W3C-standaard voor AR en VR in de browser — belooft er een sinds 2018. De werkelijkheid, halverwege 2026, is ernstiger: er is precies één consumentenhoofdset op de markt met een serieus, native toegankelijkheidsoppervlak, en de platform-neutrale browserlaag die aan alles ten grondslag ligt is nog steeds een structureel gat waar alternatieve tekst, focusbeheer en semantiek voor hulptechnologie verondersteld worden te bestaan. Dit stuk is een primer over waar de technologie daadwerkelijk staat — wat vandaag werkt, wat nog ontbreekt, en wat een ontwikkelaar in 2026 wel en niet zou moeten uitbrengen.
Het perspectief is redactioneel, niet evangelistisch. Er wordt niet beweerd dat XR inherent meer of minder toegankelijk is dan het tweedimensionale web. Wél wordt gesteld dat het ontwikkelaarsverhaal voor XR-toegankelijkheid in 2026 er ruwweg uitziet zoals het ontwikkelaarsverhaal voor webtoegankelijkheid er in 2002 uitzag: een opkomende standaard waaraan de meeste woorden ontbreken, twee dominante platforms die in een ander tempo evolueren, en een kleine groep gebruikers met een beperking die het meeste praktische kennis in hun eigen spiergeheugen met zich meedragen.
Het hardwarelandschap in 2026
Drie apparaten domineren het consumentensegment van de mixed-reality-markt, en ze nemen elk een andere positie in op het gebied van toegankelijkheid. Apple Vision Pro, met visionOS 2.4, is het enige apparaat van de drie met een serieus toegankelijkheidsoppervlak dat direct in het besturingssysteem is ingebouwd — VoiceOver in 3D-ruimte, schakelaarcontrole, aanpassing van handtracking, eyetracking als primaire invoer, en een Spatial Audio-implementatie die gebruikers met een beperking herhaaldelijk beschrijven als de meest bruikbare in de categorie. Meta Quest 3 en de goedkopere Quest 3S delen een OS — Horizon OS — met een dunnere toegankelijkheidslaag: hoog-contrastmodus, herindeling van controllers, een kleurcorrectiefilter, spraakopdrachten voor navigatie, en een schermlezer (toegevoegd medio 2024) die werkt in de systeemomgeving maar niet betrouwbaar in apps van derden. De Sony PlayStation VR2 biedt feitelijk geen native toegankelijkheidsfuncties binnen zijn VR-omgeving, hoewel het de bredere PS5-toegankelijkheidslaag erft wanneer flat-screen content wordt weergegeven.
De prijzen zijn merkbaar verschoven. De originele Vision Pro werd gelanceerd voor ca. USD 3.499; de Quest 3 kost ca. USD 499 en de Quest 3S ca. USD 299. Dat verschil telt in een toegankelijkheidsdiscussie, want het apparaat met het sterkste verhaal voor gebruikers met motorische beperkingen is ook het apparaat dat de overgrote meerderheid van mensen met een beperking zich niet kan veroorloven zonder een werkgeversgefinancierd pad voor redelijke aanpassingen. In heldere termen: de toegankelijke headset is duur, en de betaalbare headset is op systeemniveau toegankelijk in die zin dat het gebruik ervan niet actief wordt belet.
De categorie buiten deze drie — pass-through-only slimme brillen zoals Ray-Ban Meta, Xreal Air-klasse displaybrillen, en diverse enterprise-headsets die worden gebruikt in chirurgische en industriële workflows — valt grotendeels buiten het consumentendebat over XR-toegankelijkheid. De meeste van deze apparaten draaien geen desktop-klasse OS, bieden geen toegankelijkheids-API op systeemniveau en worden uitgebracht in een regelgevend landschap dat ze behandelt als draagbare accessoires en niet als computers.
De WebXR-specificatie — en wat er nog niet in staat
WebXR is de W3C-specificatie waarmee een browser een website toegang geeft tot een aangesloten AR- of VR-apparaat. De specificatie biedt een sessieobject, een renderingcontext (gewoonlijk gelaagd op WebGL2 of WebGPU), en een invoermodel voor handen, controllers en blikrichting. Browserondersteuning is halverwege 2026 het sterkst in op Chromium gebaseerde browsers (Chrome, Edge, Brave en een handvol mobiele XR-browsers), gedeeltelijk in Firefox via een enterprise-build, en historisch afwezig in Safari — visionOS Safari ondersteunt de specificatie maar alleen binnen immersive sessions en met de invoersemantiek die Apples handtracking-pipeline levert. De WebKit-positie ten aanzien van WebXR is de afgelopen twaalf maanden betekenisvol verschoven, maar is nog steeds een minder volwassen oppervlak dan het Chromium-equivalent.
De specificatie beschrijft wat de headset kan doen — stereobeelden renderen, posedata rapporteren, grip- en doeltransformaties blootstellen, select-events van een controller of een kniepbeweging registreren. Over toegankelijkheid zegt de specificatie vrijwel niets. Er is geen equivalent van een alt-attribuut voor een object in 3D-ruimte. Er is geen formeel focusmodel dat een hulptechnologie kan doorlopen. Er is op specificatieniveau geen manier om een virtuele knop een label te geven zodat een schermlezer deze kan aankondigen. Het dichtstbijzijnde toegankelijkheidshaken in de WebXR-specificatie is nu de profiles-array van de invoerbron, waarmee een site kan identificeren of de invoer een hand, een controller of een blikcursor is — en die array bestaat om redenen van contentrendering, niet voor hulptechnologie.
Dit is geen kritiek op de W3C — het is een constatering van waar het werk wel en niet is gedaan. De WebXR Accessibility User Requirements-ontwerptekst (XAUR) bestaat bij de W3C, en de Immersive Web Working Group heeft de meeste relevante lacunes erkend. Maar XAUR is een vereistendocument, geen normatieve specificatie, en de kloof tussen “we weten wat de specificatie nodig heeft” en “de specificatie schrijft het normatief voor” is in de praktijk waar de meeste gebruikers met een beperking zich vandaag bevinden.
Apple Vision Pro-toegankelijkheid, in detail
Vision Pro heeft het sterkste toegankelijkheidsverhaal op de consumentenmarkt voor XR, en de kloof met alle andere is niet subtiel. De primaire invoer van de headset is eyetracking — de gebruiker kijkt naar een doel en de blikconus definieert het gefocuste element — gecombineerd met een kleine reeks handgebaren die worden herkend door naar beneden gerichte camera’s. Voor gebruikers met een beperking heeft Apple verschillende oppervlakken toegevoegd die wezenlijk veranderen wat mogelijk is in visionOS.
Eyetracking als primaire invoer betekent dat gebruikers met ernstige motorische beperkingen van de bovenste ledematen het volledige OS kunnen bedienen zonder hand- of armbeweging, mits hun blik betrouwbaar genoeg is om een doel gedurende de verblijftijd te fixeren. Alternatieven voor handtracking laten gebruikers tikken met één vinger, polsbewegingen of alleen-hoofd-gebaren gebruiken wanneer de standaard knijp-en-tik-beweging onbetrouwbaar is — een bijzonder belangrijk oppervlak voor gebruikers met neuromusculaire aandoeningen die de fijne motoriek van de vingers beïnvloeden. VoiceOver in 3D-ruimte leest het gefocuste element voor in immersive contexten en gebruikt Spatial Audio om de ruimtelijke positie van het element ten opzichte van het hoofd van de gebruiker aan te geven — een wezenlijk andere ervaring dan een platte schermlezer, en een die, wanneer het werkt, de cognitieve belasting van het opbouwen van een mentaal model van de scène vermindert.
Spatial Audio voor toegankelijkheid gaat verder dan VoiceOver. Geluidsaanwijzingen voor systeemgebeurtenissen — meldingen, focuswijzigingen, het openen van dialoogvensters — worden in 3D-ruimte gepositioneerd zodat een slechtziende of blinde gebruiker ze kan lokaliseren zonder zijn blik te hoeven verplaatsen. Schakelaarcontrole werkt binnen immersive sessions, hoewel de invoer via dezelfde Apple-toegankelijkheidsinstellingen als op iPadOS of macOS moet worden gekoppeld. Audiodescripties zijn beschikbaar in de Apple TV-app voor immersive video. En hoofdwijzing bestaat als een recent toegevoegd alternatief voor gebruikers wier ogen niet betrouwbaar tracken, hoewel het langzamer en vermoeiender is dan de door ogen gestuurde standaard.
Niets van dit alles is perfect. VoiceOver in apps van derden is nog steeds afhankelijk van het correct aansluiten van SwiftUI- of RealityKit-componenten door de ontwikkelaar, en de app-catalogus van derden is klein. Het aanpassen van handtracking vereist het doorlopen van meerdere instellingslagen en is niet eenvoudig te ontdekken. De eyetracking-kalibratie zelf kan herhaaldelijk mislukken voor gebruikers met strabismus, nystagmus of post-beroerte blikdymetrie. Maar vergeleken met elke andere consumentenhoofdset op de markt in 2026 is het Vision Pro-toegankelijkheidsoppervlak het enige waarvan een gebruiker met een beperking redelijkerwijs mag verwachten het apparaat te kunnen gebruiken.
Meta Quest 3 en 3S-toegankelijkheid, in detail
Horizon OS heeft de afgelopen achttien maanden terrein goedgemaakt, maar de kloof met visionOS is reëel. Quest 3 en Quest 3S worden geleverd met een schermlezer op systeemniveau die UI-elementen in de shell aankondigt — Home, Bibliotheek, Store, Instellingen — en die redelijk betrouwbaar werkt in de eigen apps van Meta. Buiten de shell verandert het beeld: de meeste VR-apps van derden renderen hun UI in hun eigen engine (in de meeste gevallen Unity of Unreal) en sturen geen tekst naar de systeemschermlezer. Een blinde gebruiker kan de Quest-store openen, maar kan het meeste wat er wordt gekocht niet betrouwbaar spelen.
Spraakopdrachten bestaan voor shellnavigatie (“open Bibliotheek”, “ga naar Home”) en binnen een kleine set apps. Hoog-contrastmodus en een kleurcorrectiefilter bestaan op systeemniveau. Herindeling van controllers werkt in de shell-UI en in de kleine set apps die de invoerabstractielaag van Meta gebruiken in plaats van rechtstreeks controllerknopjes uit te lezen. Handtracking bestaat als invoermodaliteit, en recente firmware heeft de gebarenverzameling verbeterd, maar het Quest-handtracking-systeem was ontworpen als een controllervrij alternatief voor gebruikers zonder beperking, niet als toegankelijkheidsinvoer — er is geen verblijftik, geen hoofdwijzerfallback, geen equivalent van de Vision Pro enkelvoudige tik.
De meest opvallende lacune, voor een ontwikkelaarspubliek, is de afwezigheid van een gepubliceerde toegankelijkheids-API voor Horizon OS. Een ontwikkelaar die een Unity-gebaseerde Quest-app bouwt, kan vandaag de systeemtoegankelijkheidsinstellingen niet lezen, kan de app niet registreren bij de systeemschermlezer, en kan gelabelde focusdoelen niet op een manier blootstellen aan het systeem die overal consistent is. De Quest-toegankelijkheidsroadmap die Meta begin 2025 publiceerde, committeert zich aan zo’n API, maar halverwege 2026 is deze nog niet uitgebracht.
Het snijpunt van ARIA en WebXR — en de gebroken belofte van spraakinvoer
De ARIA-specificatie — de set attributen waarmee een ontwikkelaar rollen, statussen en eigenschappen kan blootstellen aan hulptechnologie — is ontworpen voor tweedimensionale documenten. Rollen zoals button, dialog, tab en navigation veronderstellen een focusmodel dat langs de documentboom beweegt. WebXR heeft geen documentboom in de WebGL- of WebGPU-zin — er is een scènegraph, maar die leeft binnen de applicatie, niet in de toegankelijkheidsstructuur van de browser. Het snijpunt van ARIA en WebXR is halverwege 2026 grotendeels een afwezigheid: de browser kan de structuur van de 3D-scène niet zien, de schermlezer kan er niet doorheen stappen, en de ontwikkelaar kan virtuele objecten niet declaratief labelen zoals HTML-knoppen dat kunnen worden gelabeld.
Er zijn gedeeltelijke oplossingen. Een WebXR-site kan een parallel DOM-gebaseerd toegankelijkheidsoppervlak renderen — een verborgen HTML-structuur die de interactieve elementen van de 3D-scène spiegelt, met correcte ARIA-rollen en -labels, en die de focus bijwerkt wanneer de 3D-selectie verandert. Dit patroon is functioneel maar arbeidsintensief; het verdubbelt de ontwikkelingskosten en heeft de neiging uit sync te raken naarmate de 3D-scène evolueert. De W3C Immersive Web Working Group heeft een normatief “toegankelijk 3D-element”-voorstel besproken dat scènegraph-knooppunten zou blootstellen aan de toegankelijkheidsstructuur, maar de discussie bevindt zich nog niet in een ontwerp-specificatiefase.
Het andere snijpunt dat nu zou moeten bestaan maar dat er niet is, is voice-first invoer. Stem was jarenlang het retorische antwoord op “hoe navigeert een gebruiker met een motorische beperking door een 3D-scène zonder handen?” De werkelijkheid, in 2026, is dat spraakinvoer binnen immersive XR kwetsbaar is. De microfoon bevindt zich dicht bij de mond van de gebruiker maar binnen een headset waarvan de geluidsopname is geoptimaliseerd voor ruimteschaal ruimtelijke audiorendering, niet voor spraakopname. Betrouwbaarheidsintervallen voor spraakherkenning binnen de Vision Pro en de Quest liggen ver onder de vergelijkbare cijfers op een smartphone. De belofte van “gewoon ertegen praten” is niet uitgekomen, en de workflow voor hulptechnologie binnen XR is nog steeds gebaar- en blikgestuurd, waarbij stem een onbetrouwbare aanvulling is in plaats van een primaire modaliteit.
Het derde snijpunt, en het snijpunt met de langste staart, is de vraag van gebaar- versus stoknavigatie. Blinde gebruikers in de fysieke ruimte navigeren met een witte stok, een geleidehond of echolocatieaanwijzingen; het ruimtelijke model dat ze opbouwen is verankerd aan obstakels op vloerniveau en aan de proprioceptie van het lichaam. De meeste XR-scènes zijn ontworpen rond een zittende of staande gebruiker wiens interactiedoelen op borsthoogte zweven in een ruimteschaal begrenzingskader. De discrepantie is niet esthetisch — ze is structureel. Het “stok”-model van navigatie, waarbij de gebruiker zijn aandacht langs een lage-energie-sonde door de scène beweegt, past niet op een invoer die de huidige XR-runtimes ondersteunen. Een WebXR-site die een stoknavigatieoppervlak aan een blinde gebruiker wilde bieden, zou dat oppervlak zelf moeten uitvinden, zonder hulp van de browser, de specificatie of het OS.
Wat ontwikkelaars in 2026 zouden moeten doen
Als er in 2026 XR-ervaringen worden gebouwd die bruikbaar moeten zijn voor mensen met een beperking, is het eerlijke antwoord: lanceer browser-gebaseerde WebXR nog niet voor gebruikers met een beperking, behalve als aanvullende content. Lanceer native visionOS-apps als het budget het toelaat, want dat is het enige platform waar het toegankelijkheidsoppervlak reëel is, de systeemniveau-API’s werken, en een gebruiker met een beperking de app kan koppelen aan hulptechnologie die ze al kennen. Lanceer native Quest-apps met voorzichtigheid, wetende dat het systeemaccessibiliteitsoppervlak shell-niveau-interacties opvangt maar niet die in apps, en dat de ontwikkelaar verantwoordelijk is voor het bouwen van het equivalent van een toegankelijkheidsstructuur in de eigen engine van de app.
Specifiek voor WebXR is de verantwoorde houding in 2026 om het als een progressieve verbetering te behandelen. Bouw de ervaring eerst als een plat, toegankelijk HTML-oppervlak dat voldoet aan de relevante WCAG 2.2-succescriteria. Laag de immersive XR-ervaring erop voor gebruikers die het willen en kunnen gebruiken, en zorg ervoor dat het platte oppervlak dezelfde content en dezelfde uitkomsten levert. Lanceer in 2026 geen WebXR-site die geen platte fallback heeft en verwacht niet dat een gebruiker met een beperking een alternatief pad vindt — dat bestaat niet.
Het grotere geheel is dat het XR-toegankelijkheidsverhaal zich op een vergelijkbaar omslagpunt bevindt als het toegankelijkheidsverhaal van het web twintig jaar geleden: de standaarden halen in, de platforms divergeren, en de kloof tussen “wat gebruikers met een beperking nodig hebben” en “wat de specificatie normatief vereist” is groot. Het werk dat de komende twee jaar moet gebeuren — XAUR van vereisten naar normatieve specificatie, de voorgestelde toegankelijkheidsstructuur voor 3D die zich stabiliseert, verbeterde spraakinvoer in headsets, en een Horizon OS-toegankelijkheids-API die daadwerkelijk wordt uitgebracht — is identificeerbaar. Of het op het tijdschema gebeurt dat de gebruikersgemeenschap nodig heeft, is een andere vraag, en een die deze publicatie zal blijven volgen.