Joka kahdeksastoista kuukausi laitteistovalmistajien markkinointikampanjat lupaavat mixed reality -teknologian tuovan inklusiivisen tulevaisuuden. Vuoden 2024 Apple Vision Pro -julkistus lupasi sellaisen. Meta Quest 3:n julkistus ja sen jälkeen tullut edullisempi Quest 3S lupasivat toisen. WebXR-spesifikaatio — W3C:n standardi selaimessa renderöidylle AR:lle ja VR:lle — on luvannut samaa vuodesta 2018. Todellisuus vuoden 2026 puolivälissä on selviämpi: markkinoilla on täsmälleen yksi kuluttajakuuloke, jossa on vakava, natiivi saavutettavuuspinta, ja sen alla oleva alustaneutraali selainkerros on edelleen rakenteellinen tyhjiö, johon vaihtoehtoisten tekstien, kohdistuksenhallinnan ja avustavan teknologian semantiikan pitäisi sijoittua. Tämä artikkeli on katsaus teknologian todelliseen tilaan — mikä toimii tänään, mikä on pelkkiä lupauksia, ja mitä kehittäjän vuonna 2026 pitäisi tai ei pitäisi toimittaa.
Näkökulma on toimituksellinen eikä evankelistinen. Emme väitä, että XR on luontaisesti enemmän tai vähemmän saavutettava kuin kaksiulotteinen verkko. Väitämme, että XR-saavutettavuuden kehittäjätarina vuonna 2026 muistuttaa suunnilleen verkosaavutettavuuden kehittäjätarinaa vuonna 2002: kehittyvä standardi, josta puuttuu suurin osa sisällöstä, kaksi hallitsevaa alustaa etenevät eri nopeuksilla, ja pieni joukko vammaisia käyttäjiä kantaa suurimman osan käytännön tiedosta omassa lihasmuistissaan.
Laitteistomaisema vuonna 2026
Kolme laitetta hallitsee mixed reality -markkinoiden kuluttajapäätä tänään, ja ne ottavat kolme erilaista kantaa saavutettavuuteen. Apple Vision Pro, jossa on visionOS 2.4, on ainoa kolmesta laitteesta, jossa on vakava saavutettavuuspinta itse käyttöjärjestelmässä — VoiceOver 3D-tilassa, kytkimienhallinta, käsiseurannan mukauttaminen, silmäseuranta ensisijaisena syötteenä ja Spatial Audio -toteutus, jonka vammaiset käyttäjät ovat toistuvasti kuvailleet hyödyllisimmäksi kategoriassaan. Meta Quest 3 ja edullisempi Quest 3S jakavat käyttöjärjestelmän — Horizon OS:n — ohuemmalla saavutettavuuskerroksella: korkea kontrastimoodi, ohjainten uudelleenmäppäys, värikorjaussuodatin, äänikomennot navigointiin ja ruudunlukuohjelma (lisätty vuoden 2024 puolivälissä), joka toimii järjestelmäkuoressa mutta ei luotettavasti kolmannen osapuolen sovelluksissa. Sony PlayStation VR2 ei käytännössä toimita natiiveja saavutettavuusominaisuuksia VR-kuoressaan, vaikka se perii laajemman PS5-saavutettavuuskerroksen, kun sitä käytetään tasanäyttösisällön kanssa.
Hinnoittelu on muuttunut huomattavasti. Alkuperäinen Vision Pro julkaistiin noin 3 499 USD:n hinnalla; Quest 3 maksaa noin 499 USD ja Quest 3S noin 299 USD. Tämä ero on merkityksellinen saavutettavuusargumentin kannalta, koska laite, jolla on vahvin vammaissyötteen tarina, on myös laite, jonka valtaosa vammaisista käyttäjistä ei pysty ostamaan ilman työnantajan rahoittamaa kohtuullisen mukautuksen polkua. Vuoden 2026 puolivälin markkinoiden muoto on suoraan sanottuna: saavutettava kuuloke on kallis, ja edullinen kuuloke on järjestelmätasolla saavutettava enimmäkseen siinä mielessä, että se ei aktiivisesti estä käyttöä.
Näiden kolmen ulkopuolinen kategoria — vain läpäisysignaaleja käyttävät älylasit kuten Ray-Ban Meta, Xreal Air -luokan näyttölasit ja erilaiset kirurgisissa ja teollisissa työnkuluissa käytettävät yrityskuulokkeet — on suurelta osin poissa kuluttajien XR-saavutettavuuskeskustelusta. Useimmissa näistä laitteista ei ole työpöytäluokan käyttöjärjestelmää, ne eivät paljasta järjestelmätason saavutettavuus-API:a eivätkä ne toimitu sääntelyympäristöön, joka kohtelee niitä puettavina lisävarusteina eikä tietokoneina.
WebXR-spesifikaatio — ja mitä se ei vielä sano
WebXR on W3C-spesifikaatio, jonka avulla selain antaa verkkosivustolle pääsyn liitettyyn AR- tai VR-laitteeseen. Se paljastaa session-objektin, renderöintikontekstin (yleensä kerrostettuna WebGL2:n tai WebGPU:n päälle) ja syötemalleja käsille, ohjaimille ja katseelle. Selaintuki on vuoden 2026 puolivälissä vahvinta Chromium-pohjaisissa selaimissa (Chrome, Edge, Brave ja joukko mobiili-XR-selaimia), osittainen Firefoxissa yritysbuildin kautta, ja historiallisesti poissa Safarista — visionOS Safari tukee spesifikaatiota mutta vain immersiivisissä sessioissa ja Applen käsiseurantaputkiston tarjoamilla syötesematiikalla. WebKitin WebXR-asema on liikkunut merkittävästi viimeisen kahdentoista kuukauden aikana, mutta se on edelleen kypsymättömämpi pinta kuin Chromium-vastineensa.
Spesifikaatio kattaa sen, mitä kuuloke voi tehdä — renderöidä stereoruutuja, raportoida asentodataa, paljastaa tartunta- ja tähtäysmuunnoksia, kuunnella valintatapahtumia ohjaimesta tai nipistyseleestä. Se ei sanoa juuri mitään saavutettavuudesta. 3D-tilassa olevalle objektille ei ole alt-attribuutin vastinetta. Ei ole virallista kohdistusmallia, jonka avustava teknologia voisi kulkea läpi. Ei ole spesifikaatiotason tapaa merkitä virtuaalinen painike niin, että ruudunlukuohjelma voisi ilmoittaa siitä. Lähinnä saavutettavuuskoukku WebXR-spesifikaatiossa tänään on syötelähteen profiles-taulukko, jonka avulla sivusto voi tunnistaa, onko syöte käsi, ohjain vai katsekohdistin — ja tämä taulukko on olemassa sisällönrenderöintisyistä, ei avustavan teknologian syistä.
Tämä ei ole kritiikki W3C:tä kohtaan — se on lausunto siitä, missä työ on ja ei ole tehty. WebXR Accessibility User Requirements -luonnos (XAUR) on olemassa W3C:ssä, ja Immersive Web Working Group on tunnustanut suurimman osan asiaankuuluvista puutteista. XAUR on kuitenkin vaatimusasiakirja, ei normatiivinen spesifikaatio, ja kuilu “tiedämme, mitä spesifikaatio tarvitsee” ja “spesifikaatio sanoo sen normatiivisesti” välillä on käytännössä se paikka, jossa suurin osa vammaisista käyttäjistä asuu tänään.
Apple Vision Pro -saavutettavuus yksityiskohtaisesti
Vision Pro on tänään kuluttajien XR-markkinoiden vahvin saavutettavuustarina, ja kuilu muihin on selvä. Kuulokkeen ensisijainen syöte on silmäseuranta — käyttäjä katsoo kohdetta ja katsekartion määrittelee kohdistuselementin — yhdistettynä pieneen joukkoon alaspäin suuntautuvien kameroiden havaitsemia käsieleitä. Vammaisille käyttäjille Apple on lisännyt useita pintoja, jotka muuttavat merkittävästi sitä, mitä visionOS:ssä on mahdollista tehdä.
Silmäseuranta ensisijaisena syötteenä tarkoittaa, että käyttäjät, joilla on vakava yläraajojen motorinen vamma, voivat ohjata koko käyttöjärjestelmää ilman käsi- tai käsivarren liikettä, edellyttäen, että heidän katseensa on riittävän vakaa kiinnittymään kohteeseen viivekeston ajaksi. Käsiseurannan vaihtoehdot antavat käyttäjille mahdollisuuden korvata oletuspuristus- ja napautuseleet yksisormisilla napautuksilla, ranneliikkeillä tai vain pään eleillä, kun oletus on epäluotettava — erityisen tärkeä pinta käyttäjille, joilla on hienomotoriikkaan vaikuttavia neuromuskulaarisia sairauksia. VoiceOver 3D-tilassa lukee kohdistuselementin immersiivisissä konteksteissa ja käyttää Spatial Audiota osoittamaan elementin sijaintia käyttäjän pään suhteen — merkityksellisesti erilainen kokemus verrattuna tasaruudunlukijaan, ja sellainen, joka toimiessaan vähentää kognitiivista kuormaa kohtauksen mentaalisen mallin rakentamisessa.
Spatial Audio saavutettavuutta varten ylittää VoiceOverin. Järjestelmätapahtumien — ilmoitusten, kohdistusmuutosten, valintaikkunoiden avautumisen — äänivihjeet on sijoitettu 3D-tilaan niin, että heikkonäköinen tai sokea käyttäjä voi paikantaa ne pyyhkäisemättä katsettaan. Kytkimienohjausta käytetään immersiivisissä sessioissa, vaikka syöte on parittava saman Applen saavutettavuusasetusten kautta kuin iPadOS:ssä tai macOS:ssa. Äänikuvaukset ovat esillä Apple TV -sovelluksessa immersiivisille videoille. Ja pään osoitus on äskettäin lisätty vaihtoehto käyttäjille, joiden silmät eivät seuraa luotettavasti, vaikka se on hitaampaa ja rasittavampaa kuin silmäohjattu oletus.
Mikään tästä ei ole täydellistä. VoiceOver kolmannen osapuolen sovelluksissa riippuu edelleen siitä, kytkeekö kehittäjä SwiftUI- tai RealityKit-komponentit oikein, ja kolmannen osapuolen sovellusluettelo on pieni. Käsiseurannan mukauttaminen edellyttää useiden asetustasojen läpi kulkemista eikä ole löydettävissä helposti. Silmäseurannan kalibrointi itsessään voi epäonnistua toistuvasti käyttäjillä, joilla on strabismus, nystagmus tai aivoverenkiertohäiriön jälkeinen katsedysmetria. Mutta verrattuna mihin tahansa muuhun vuoden 2026 kuluttajakuulokkeeseen Vision Pro -saavutettavuuspinta on ainoa, jonka kanssa vammainen käyttäjä voi istua alas ja odottaa kohtuudella pystyvänsä käyttämään laitetta.
Meta Quest 3:n ja 3S:n saavutettavuus yksityiskohtaisesti
Horizon OS on kuromassa kiinni viimeisen kahdeksantoista kuukauden aikana, mutta kuilu visionOS:ään on todellinen. Quest 3 ja Quest 3S toimitetaan järjestelmätason ruudunlukuohjelmalla, joka ilmoittaa kuoren käyttöliittymäelementeistä — Kotisivu, Kirjasto, Kauppa, Asetukset — ja toimii kohtuullisen luotettavasti Metan omissa sovelluksissa. Kuoren ulkopuolella kuva muuttuu: useimmat kolmannen osapuolen VR-sovellukset renderöivät käyttöliittymänsä omassa moottorissaan (useimmissa tapauksissa Unity tai Unreal) eivätkä syötä tekstiä järjestelmän ruudunlukijaan lainkaan. Sokea käyttäjä voi avata Quest-kaupan, mutta ei pysty luotettavasti pelaamaan suurinta osaa ostamastaan.
Äänikomennot ovat olemassa kuoren navigointia varten (“open Library”, “go Home”) ja pienessä joukossa sovelluksia. Korkea kontrastimoodi ja värikorjaussuodatin ovat järjestelmätasolla. Ohjainten uudelleenmäppäys toimii kuoren käyttöliittymässä ja pienessä joukossa sovelluksia, jotka käyttävät Metan syöteabstraktiokerrosta ohjainpainikkeiden suoran lukemisen sijaan. Käsiseuranta on syötemoodina olemassa, ja viimeisimmät laiteohjelmistot ovat parantaneet eleitä, mutta Quest-käsiseurantajärjestelmä suunniteltiin ohjaimettomaksi vaihtoehdoksi ei-vammaisille käyttäjille, ei saavutettavuussyötteeksi — siinä ei ole viivenapautusta, ei pään osoitinta, ei Vision Pro:n yksisormitapautuksen vastinetta.
Merkittävin puute kehittäjäyleisölle on julkaistun saavutettavuus-API:n puuttuminen Horizon OS:stä. Unity-pohjaisen Quest-sovelluksen rakentava kehittäjä ei tänään voi lukea järjestelmän saavutettavuusasetuksia, ei voi rekisteröidä sovellusta järjestelmän ruudunlukijaan eikä pysty paljastamaan merkittyjä kohdistuskohteita järjestelmälle tavalla, joka säilyy sovellusten välillä. Metan vuoden 2025 alussa julkaisema Quest-saavutettavuuskartta lupaa tällaisen API:n, mutta vuoden 2026 puolivälissä se ei ole vielä toimitettu.
ARIA + WebXR -leikkaus — ja äänisyötteen rikkinäinen lupaus
ARIA-spesifikaatio — joukko attribuutteja, joiden avulla kehittäjä voi paljastaa roolit, tilat ja ominaisuudet avustavalle teknologialle — suunniteltiin kaksiulotteisille asiakirjoille. Roolit kuten button, dialog, tab ja navigation olettavat kohdistusmallin, joka liikkuu asiakirjapuun pitkin. WebXR:llä ei ole asiakirjapuuta WebGL- tai WebGPU-mielessä — siinä on kohtausgraafi, mutta se elää sovelluksessa, ei selaimen saavutettavuuspuussa. ARIA:n ja WebXR:n leikkaus on vuoden 2026 puolivälissä pitkälti puuttuminen: selain ei näe 3D-kohtauksen rakennetta, ruudunlukuohjelma ei pysty kulkemaan sen läpi, eikä kehittäjä voi deklaratiivisesti merkitä virtuaalisia objekteja samalla tavoin kuin HTML-painikkeita.
Osittaisia ratkaisuja on olemassa. WebXR-sivusto voi renderöidä rinnakkaisen DOM-pohjaisen saavutettavuuspinnan — piilotetun HTML-rakenteen, joka peilaa 3D-kohtauksen interaktiivisia elementtejä asianmukaisilla ARIA-rooleilla ja -tunnisteilla ja päivittää kohdistuksen kun 3D-valinta muuttuu. Tämä malli toimii, mutta on vaivalloinen; se kaksinkertaistaa kehityskustannukset, ja se taipuu ajautumaan synkronoinnista pois kun 3D-kohtaus kehittyy. W3C Immersive Web Working Group on keskustellut normatiivisesta “saavutettava 3D-elementti” -ehdotuksesta, joka paljastaisi kohtausgraafin solmut saavutettavuuspuulle, mutta keskustelu ei ole vielä luonnosspesifikaatiovaiheessa.
Toinen leikkaus, jonka pitäisi jo olla olemassa mutta ei ole, on ääniensisijainen syöte. Ääni oli useiden vuosien ajan retorinen vastaus kysymykseen “kuinka motorisesti vammainen käyttäjä navigoi 3D-kohtauksessa ilman käsiä?” Todellisuus vuonna 2026 on se, että äänisyöte immersiivisessä XR:ssä on hauras. Mikrofoni on sijoitettu lähelle käyttäjän suuta, mutta kuulokkeen sisällä, jonka äänenotto on optimoitu huonelaajuisen tilallisen äänen renderöintiin, ei puheen kaappaamiseen. Puhekomentotunnistuksen luottamusvälit Vision Prossa ja Questissa ovat selvästi alle vastaavan luvun älypuhelimessa. Lupaus “puhu sille vain” ei ole toteutunut, ja avustavan teknologian työnkulku XR:ssä on edelleen ele- ja katseohjainen, jossa ääni on epäluotettava lisäsyöte eikä ensisijainen modaliteetti.
Kolmas leikkaus, ja se jolla on pisin häntä, on kysymys ele-vs-valkoinen keppi -navigoinnista. Sokeat käyttäjät fyysisessä tilassa navigoivat valkoisella kepillä, opaskoiralla tai kaikusuunnistuksella; heidän rakentamansa tilamalli on ankkuroitu lattiatason esteisiin ja kehon proprioseptiikkaan. Useimmat XR-kohtaukset on suunniteltu istuvan tai seisovan käyttäjän ympärille, jonka vuorovaikutuskohteet kelluvat rintakorkeudella huonelaajuisessa rajoituslaatikossa. Ristiriita ei ole esteettinen — se on rakenteellinen. “Keppi”-navigointimalli, jossa käyttäjä siirtää huomiotaan pienienergistä tunnistinta pitkin kohtauksessa, ei vastaa mitään syötettä, jota nykyiset XR-suoritusajat tukevat. WebXR-sivusto, joka haluaisi tarjota keppi-navigointipinnan sokealle käyttäjälle, joutuisi keksimään pinnan itse, ilman apua selaimelta, spesifikaatiolta tai käyttöjärjestelmältä.
Minne kehittäjien pitäisi mennä vuonna 2026
Jos rakennat XR-kokemuksia vuonna 2026 ja haluat niiden olevan vammaisten käyttäjien käytettävissä, rehellinen vastaus on: älä toimita selainpohjaista WebXR:ää vammaisille käyttäjille vielä, paitsi täydentävänä sisältönä. Toimita natiivi visionOS-sovelluksia jos budjetti sallii, koska se on ainoa alusta, jossa saavutettavuuspinta on todellinen, järjestelmätason API:t toimivat ja vammainen käyttäjä voi parittaa sovelluksen jo tuntemansa avustavan teknologian kanssa. Toimita natiiveja Quest-sovelluksia varoen, tietäen, että järjestelmän saavutettavuuspinta kattaa kuoritason vuorovaikutukset mutta ei sovelluksen sisäisiä, ja että kehittäjä on vastuussa saavutettavuuspuun vastineen rakentamisesta sovelluksen omassa moottorissa.
WebXR:n osalta vastuullinen vuoden 2026 asenne on kohdella sitä progressiivisena parannuksena. Rakenna kokemus ensin tasaisena, saavutettavana HTML-pintana, joka täyttää asiaankuuluvat WCAG 2.2 onnistumiskriteerit. Kerrostu immersiivinen XR-kokemus päälle käyttäjille, jotka haluavat ja pystyvät käyttämään sitä, ja varmista, että tasainen pinta tarjoaa saman sisällön ja samat tulokset. Älä vuonna 2026 toimita WebXR-sivustoa, jolla ei ole tasaista varasuunnitelmaa ja odota vammaisen käyttäjän löytävän vaihtoehtoisen reitin — sellaista ei ole.
Isompi kuva on se, että XR-saavutettavuuden tarina on samanlaisessa käännekohdassa kuin missä verkon saavutettavuustarina oli kaksikymmentä vuotta sitten: standardit kirivät kiinni, alustat eroavat toisistaan, ja kuilu “mitä vammaiset käyttäjät tarvitsevat” ja “mitä spesifikaatio normatiivisesti vaatii” välillä on leveä. Työ, jonka on tapahduttava seuraavan kahden vuoden aikana — XAUR:n siirtyminen vaatimuksista normatiiviseen spesifikaatioon, 3D:n saavutettavuuspuu-ehdotuksen vakiintuminen, äänisyötteen paraneminen kuulokkeiden sisällä ja Horizon OS -saavutettavuus-API:n todellinen toimittaminen — on tunnistettavissa. Tapahtuuko se käyttäjäyhteisön tarvitsemalla aikataululla on eri kysymys, ja sellainen, jota tämä julkaisu jatkaa seuraamaan.