Hvert atten måned lover en pressecyklus om mixed reality-hardware en inkluderende fremtid. Lanceringen af Apple Vision Pro i 2024 lovede én. Meta Quest 3-lanceringen, og den billigere Quest 3S der fulgte, lovede endnu en. WebXR-specifikationen — W3C-standarden for AR og VR renderet inde i browseren — har lovet det siden 2018. Virkeligheden i midten af 2026 er mere ernyktrende: der er præcis ét forbrugerheadset på markedet med en seriøs, indbygget tilgængelighed i operativsystemet, og det platformsneutrale browserlag under det hele er stadig et strukturelt tomrum, hvor alternativ tekst, fokusstyring og hjælpeteknologi-semantik burde ligge. Denne artikel er en introduktion til, hvor teknologien faktisk befinder sig — hvad der virker i dag, hvad der er luftkastel, og hvad en udvikler i 2026 bør og ikke bør levere.
Perspektivet er redaktionelt snarere end evangelistisk. Vi argumenterer ikke for, at XR er mere eller mindre tilgængeligt end det todimensionelle web. Vi argumenterer for, at udviklernes fortælling om XR-tilgængelighed i 2026 ligner det, webtilgængelighed så ud som i 2002: en spirende standard med de fleste ord manglende, to dominerende platforme der bevæger sig med forskellig hastighed, og en lille gruppe mennesker med handicap der bærer det meste af den praktiske viden i deres egen muskelmemori.
Hardwarelandskabet i 2026
Tre enheder dominerer forbrugersiden af mixed reality-markedet i dag, og de indtager tre forskellige positioner i forhold til tilgængelighed. Apple Vision Pro, der kører visionOS 2.4, er den eneste af de tre med en seriøs tilgængelighed bygget direkte ind i operativsystemet — VoiceOver i 3D-rum, switch-kontrol, tilpasning af håndsporing, øjensporingsom primær input og en Spatial Audio-implementering, som brugere med handicap gentagne gange har beskrevet som den mest anvendelige i kategorien. Meta Quest 3 og den billigere Quest 3S deler et styresystem — Horizon OS — med et tyndere tilgængelighedslag: høj-kontrasttilstand, omlægning af controller, et farvekorrigeringsfilter, stemmekommandoer til navigation og en skærmlæser (tilføjet i midten af 2024), der fungerer inde i systemskallen men ikke pålideligt i tredjeparts-apps. Sony PlayStation VR2 leverer i praksis ingen native tilgængelighedsfunktioner inde i sin VR-skal, selv om den arver det bredere PS5-tilgængelighedslag, når den kører flad indhold.
Priserne har forskudt sig mærkbart. Den originale Vision Pro blev lanceret til ca. 3.499 USD; Quest 3 er ca. 499 USD og Quest 3S er ca. 299 USD. Det gab har betydning for et tilgængelighedsargument, fordi enheden med den stærkeste fortælling om handicap-input også er den enhed, som langt de fleste brugere med handicap ikke har råd til at købe uden en arbejdsgiver-finansieret rimelig tilpasning. Formen på markedet i midten af 2026 er i klare ord: det tilgængelige headset er dyrt, og det overkommelige headset er, på systemniveau, tilgængeligt mest i den forstand, at det ikke aktivt forhindrer dig i at bruge det.
Kategorien uden for disse tre — pass-through-only smart glasses som Ray-Ban Meta, Xreal Air-klasse display-briller og de forskellige enterprise-headsets der anvendes i kirurgiske og industrielle arbejdsgange — er i store træk uden for forbruger-XR-tilgængelighedssamtalen. De fleste af disse enheder kører ikke et desktop-klasse styresystem, eksponerer ingen tilgængeligheds-API på systemniveau og leveres ind i et reguleringslandskab, der behandler dem som bærbart tilbehør snarere end computere.
WebXR-specifikationen — og hvad den endnu ikke siger
WebXR er W3C-specifikationen, der lader en browser give en hjemmeside adgang til en tilkoblet AR- eller VR-enhed. Den eksponerer et sessionsobjekt, en renderingskontekst (sædvanligvis lagt oven på WebGL2 eller WebGPU) og en inputkildemodel for hænder, controllere og blik. Browserunderstøttelse er i midten af 2026 stærkest i Chromium-baserede browsere (Chrome, Edge, Brave og en håndfuld mobile XR-browsere), delvis i Firefox via et enterprise-build, og historisk fraværende fra Safari — visionOS Safari understøtter specifikationen men kun inde i immersive sessions og med den input-semantik, Apples håndsporing leverer. WebKits WebXR-position har bevæget sig meningsfyldt i de seneste tolv måneder, men er stadig en mindre moden overflade end dens Chromium-modstykke.
Specifikationen dækker, hvad headsettet kan gøre — rendere stereoframes, rapportere pose-data, eksponere grip- og aim-transformationer, lytte efter select-hændelser fra en controller eller et knib-gestus. Den siger næsten intet om tilgængelighed. Der er ingen equivalent til et alt-attribut for et objekt i 3D-rum. Der er ingen formel fokusmodel, som en hjælpeteknologi kan gennemgå. Der er ingen spec-niveau måde at mærke en virtuel knap på, så en skærmlæser kan annoncere den. Det nærmeste noget en tilgængeligheds-hook i WebXR-specifikationen i dag er inputkildens profiles-array, der lader et website identificere, om input er en hånd, en controller eller et blik-markør — og det array eksisterer af hensyn til indholdsrendering, ikke hjælpeteknologi.
Dette er ikke en kritik af W3C — det er en konstatering af, hvor arbejdet er og ikke er blevet udført. WebXR Accessibility User Requirements-udkastet (XAUR) eksisterer hos W3C, og Immersive Web Working Group har anerkendt de fleste relevante mangler. Men XAUR er et kravdokument, ikke en normativ spec, og afstanden mellem »vi ved, hvad specifikationen har brug for« og »specifikationen siger det normativt« er i praksis, hvor de fleste brugere med handicap befinder sig i dag.
Apple Vision Pro-tilgængelighed i detaljer
Vision Pro har den stærkeste tilgængelighedsfortælling på forbruger-XR-markedet i dag, og afstanden til alle andre er ikke subtil. Headsets primære input er øjensporing — brugeren kigger på et mål, og blikkeglens definerer det fokuserede element — kombineret med et lille sæt håndgestusser registreret af nedadvendte kameraer. For brugere med handicap har Apple tilføjet flere overflader, der materielt ændrer, hvad der er muligt inde i visionOS.
Øjensporing som primær input betyder, at brugere med svær motorisk funktionsnedsættelse i overekstremiteterne kan betjene hele styresystemet uden hånd- eller armbevægelse, forudsat at deres blik er pålideligt nok til at fiksere på et mål i dvæletiden. Alternativer til håndsporing lader brugere erstatte enkeltfinger-tryk, håndledsbevægelser eller hoved-gestusser, når det standard knib-og-tryk ikke er pålideligt — en særlig vigtig overflade for brugere med neuromuskulære tilstande, der påvirker fin fingerkontrol. VoiceOver i 3D-rum oplæser det fokuserede element i immersive kontekster og bruger Spatial Audio til at angive elementets rumlige position relativt til brugerens hoved — en meningsfyldt anderledes oplevelse end en flad skærmlæser, og en der, når den virker, reducerer den kognitive belastning ved at opbygge et mentalt billede af scenen.
Spatial Audio til tilgængelighed rækker ud over VoiceOver. Lydcues til systemhændelser — notifikationer, fokusskift, dialogåbninger — er positioneret i 3D-rum, så en svagsynet eller blind bruger kan finde dem uden at kigge rundt. Switch-kontrol fungerer inde i immersive sessions, selv om input skal parres via Apples tilgængelighedsopsætning som på iPadOS eller macOS. Synstolkning er eksponeret inde i Apple TV-appen til immersiv video. Og hoved-peger eksisterer som et nyligt tilføjet alternativ for brugere, hvis øjne ikke sporer pålideligt, selv om det er langsommere og mere udmattende end øjenstyret standard.
Intet af dette er perfekt. VoiceOver i tredjeparts-apps afhænger stadig af, at udvikleren tilkobler SwiftUI- eller RealityKit-komponenter korrekt, og tredjeparts-app-kataloget er lille. Tilpasning af håndsporing kræver at navigere gennem adskillige lag af indstillinger og er ikke let at opdage. Øjensporings-kalibreringen kan gentagne gange fejle for brugere med strabismus, nystagmus eller post-apoplektisk blikdysmetri. Men sammenlignet med ethvert andet forbrugerheadset på markedet i 2026 er Vision Pro-tilgængelighed den eneste, hvor en bruger med handicap kan sætte sig ned og med rimelighed forvente at kunne bruge enheden.
Meta Quest 3 og 3S tilgængelighed i detaljer
Horizon OS har hentet ind i de seneste atten måneder, men afstanden til visionOS er reel. Quest 3 og Quest 3S leveres med en skærmlæser på systemniveau, der annoncerer shell-UI-elementer — Hjem, Bibliotek, Butik, Indstillinger — og fungerer rimeligt pålideligt inde i Metas egne apps. Uden for skallen ændrer billedet sig: de fleste tredjeparts VR-apps renderer deres UI inde i deres egen engine (Unity eller Unreal i de fleste tilfælde) og fodrer overhovedet ikke tekst ind i system-skærmlæseren. En blind bruger kan åbne Quest-butikken, men kan ikke pålideligt spille det meste af det, de køber.
Stemmekommandoer eksisterer til shell-navigation (»åbn Bibliotek«, »gå til Hjem«) og inde i et lille sæt apps. Høj-kontrasttilstand og et farvekorrigeringsfilter eksisterer på systemniveau. Controller-omlægning fungerer i shell-UI og i det lille sæt apps, der bruger Metas inputabstraktionslag frem for at aflæse controllerknapper direkte. Håndsporing eksisterer som inputmodalitet, og den seneste firmware har forbedret gestikulationsættet, men Quests hånd-sporings-system var designet som et controller-frit alternativ til ikke-handicappede brugere, ikke som et hjælpeteknologisk input — der er ingen dvæle-klik, ingen hoved-peger-reserve, intet svarende til Vision Pros enkeltfinger-tryk.
Den mest bemærkelsesværdige mangel for en udviklermålgruppe er fraværet af en publiceret tilgængeligheds-API til Horizon OS. En udvikler, der bygger en Unity-baseret Quest-app, kan i dag ikke læse systemets tilgængelighedsindstillinger, kan ikke registrere appen i system-skærmlæseren og kan ikke eksponere mærkede fokusmål til systemet på en måde, der overlever på tværs af apps. Quest-tilgængelighedsroadmappen, som Meta publicerede tidligt i 2025, forpligter sig til en sådan API, men pr. midten af 2026 er den endnu ikke tilgængelig.
ARIA + WebXR-skæringspunktet — og stemme-inputs brudte løfte
ARIA-specifikationen — sættet af attributter, der lader en udvikler eksponere roller, tilstande og egenskaber til hjælpeteknologi — var designet til todimensionelle dokumenter. Roller som button, dialog, tab og navigation forudsætter en fokusmodel, der bevæger sig langs dokumenttræet. WebXR har ikke et dokumenttræ i WebGL- eller WebGPU-forstand — der er en scene-graf, men den lever inde i applikationen, ikke i browserens tilgængelighed-træ. Skæringspunktet mellem ARIA og WebXR er i midten af 2026 i store træk en fravær: browseren kan ikke se 3D-scenens struktur, skærmlæseren kan ikke gennemgå den, og udvikleren kan ikke deklarativt mærke virtuelle objekter på den måde, de kan mærke HTML-knapper.
Der er delvise løsninger. Et WebXR-website kan rendere en parallel DOM-baseret tilgængelighed — en skjult HTML-struktur, der afspejler 3D-scenens interaktive elementer med korrekte ARIA-roller og -mærker, og som opdaterer fokus, når 3D-valget ændrer sig. Dette mønster er funktionelt men omstændeligt; det fordobler udviklingsomkostningerne, og det har tendens til at glide ud af sync, efterhånden som 3D-scenen udvikler sig. W3C Immersive Web Working Group har diskuteret et normativt »tilgængeligt 3D-element«-forslag, der ville eksponere scene-grafknuder for tilgængelighed-træet, men diskussionen er endnu ikke på et udkastspec-stadie.
Det andet skæringspunkt, der burde eksistere nu men ikke gør, er stemme-første input. Stemme var i flere år det retoriske svar på »hvordan vil en motorisk handicappet bruger navigere i en 3D-scene uden hænder?« Virkeligheden i 2026 er, at stemmeinput inde i immersiv XR er skrøbeligt. Mikrofonen er placeret tæt på brugerens mund, men inde i et headset, hvis lydopsamling er optimeret til rumskala spatial audio-rendering, ikke talekaptur. Konfidensintervallerne på stemmekommandogenkendelse inde i Vision Pro og Quest svæver langt under det tilsvarende tal på en smartphone. Løftet om »bare tal til det« er ikke realiseret, og hjælpeteknologi-arbejdsgangen inde i XR er stadig gestus-og-blik-drevet, med stemme som et upålideligt supplement snarere end en primær modalitet.
Det tredje skæringspunkt, og det med den længste hale, er spørgsmålet om gestus-vs-stok-navigation. Blinde brugere i fysisk rum navigerer med en hvid stok, en blindehund eller ekkolokalisering; det rumlige model, de opbygger, er forankret til forhindringer på gulvniveau og til kroppens proprioception. De fleste XR-scener er designet til en siddende eller stående bruger, hvis interaktionsmål svæver i brysthøjde inde i en rumskala boksning. Misforholdet er ikke æstetisk — det er strukturelt. »Stok«-modellen for navigation, hvor brugeren bevæger sin opmærksomhed langs en lav-energi-probe gennem scenen, mapper ikke til noget input, de nuværende XR-runtimes understøtter. Et WebXR-website, der ønskede at eksponere en stok-navigationsoverflade til en blind bruger, skulle opfinde overfladen selv, uden hjælp fra browseren, specifikationen eller styresystemet.
Hvor udviklere bør gå hen i 2026
Hvis du bygger XR-oplevelser i 2026 og ønsker, at de kan bruges af brugere med handicap, er det ærlige svar: leverér ikke browserbaseret WebXR til brugere med handicap endnu, undtagen som supplerende indhold. Levér native visionOS-apps, hvis budgettet tillader det, fordi det er den eneste platform, hvor tilgængelighed er reel, API’erne på systemniveau fungerer, og en bruger med handicap kan parre appen med hjælpeteknologi, de allerede kender. Levér native Quest-apps med forsigtighed, vel vidende at systemets tilgængelighed-overflade vil fange interaktioner i shell-niveau men ikke i apps, og at udvikleren er ansvarlig for at bygge equivalenten til et tilgængelighed-træ inde i appens egen engine.
For WebXR specifikt er den ansvarlige holdning i 2026 at behandle det som en progressiv forbedring. Byg oplevelsen først som en flad, tilgængelig HTML-overflade, der opfylder de relevante WCAG 2.2-succeskriterier. Læg den immersive XR-oplevelse oven på for brugere, der ønsker og kan bruge den, og sørg for, at den flade overflade leverer det samme indhold og de samme resultater. Levér ikke i 2026 et WebXR-website uden en flad reserve og forventer, at en bruger med handicap finder en alternativ vej igennem det — der er ingen.
Det større billede er, at XR-tilgængelighed befinder sig ved et lignende vendepunkt som webtilgængelighed for tyve år siden: standarderne indhenter, platformene divergerer, og afstanden mellem »hvad brugere med handicap har brug for« og »hvad specifikationen normativt kræver« er stor. Det arbejde, der skal ske i de næste to år — XAUR går fra krav til normativ spec, forslaget om tilgængelighed-træ til 3D stabiliseres, stemmeinput forbedres inde i headsets, og en Horizon OS-tilgængeligheds-API faktisk leveres — er identificerbart. Om det sker på den tidslinje, brugersamfundet har brug for, er et andet spørgsmål, og et som denne publikation vil fortsætte med at følge.