Co osiemnaście miesięcy cykl prasowy dotyczący sprzętu mieszanej rzeczywistości obiecuje inkluzywną przyszłość. Obiecywał ją premiera Apple Vision Pro w 2024 roku. Obiecywała ją premiera Meta Quest 3, a po niej — mniejszego Quest 3S. Obiecuje ją specyfikacja WebXR — standard W3C dla AR i VR renderowanych wewnątrz przeglądarki — od 2018 roku. Rzeczywistość w połowie 2026 roku jest bardziej trzeźwa: na rynku istnieje dokładnie jedno konsumenckie urządzenie z poważną, natywną warstwą dostępności, a platformowo-neutralna warstwa przeglądarki leżąca u podstaw całości to nadal strukturalna luka, w której miały zamieszkać tekst alternatywny, zarządzanie fokusem i semantyka technologii wspomagających. Niniejszy tekst to primer opisujący, gdzie technologia faktycznie się znajduje — co działa dziś, co jest wizją przyszłości i czego deweloper w 2026 roku powinien, a czego nie powinien wdrażać.
Perspektywa jest redakcyjna, a nie ewangelizacyjna. Nie twierdzimy, że XR jest z natury bardziej lub mniej dostępne niż dwuwymiarowa sieć. Twierdzimy, że historia dewelopera w obszarze dostępności XR w 2026 roku przypomina historię dewelopera w obszarze dostępności internetowej w 2002 roku: wyłaniający się standard, w którym brakuje większości słów, dwie dominujące platformy poruszające się w różnym tempie i mała grupa osób z niepełnosprawnościami niosąca większość praktycznej wiedzy we własnej pamięci mięśniowej.
Krajobraz sprzętowy w 2026 roku
Na konsumenckim rynku mieszanej rzeczywistości dominują dziś trzy urządzenia, które zajmują trzy różne stanowiska wobec dostępności. Apple Vision Pro działający pod visionOS 2.4 to jedyne z trzech urządzeń z poważną warstwą dostępności wbudowaną bezpośrednio w system operacyjny — VoiceOver w przestrzeni 3D, kontrola przełącznikiem, personalizacja śledzenia rąk, śledzenie wzroku jako podstawowy sposób wprowadzania danych oraz implementacja Spatial Audio, którą osoby z niepełnosprawnościami wielokrotnie określały jako najbardziej użyteczną w tej kategorii. Meta Quest 3 i tańszy Quest 3S działają na wspólnym systemie operacyjnym — Horizon OS — z cieńszą warstwą dostępności: tryb wysokiego kontrastu, ponowne mapowanie kontrolerów, filtr korekcji kolorów, polecenia głosowe do nawigacji oraz czytnik ekranu (dodany w połowie 2024 roku), który działa w powłoce systemowej, ale nie w sposób niezawodny wewnątrz aplikacji zewnętrznych. Sony PlayStation VR2 praktycznie nie oferuje natywnych funkcji dostępności w swojej powłoce VR, choć dziedziczy szerszą warstwę dostępności PS5 podczas uruchamiania treści na płaskim ekranie.
Ceny wyraźnie się zmieniły. Oryginalny Vision Pro kosztował przy premierze ok. 3 499 USD; Quest 3 to ok. 499 USD, a Quest 3S — ok. 299 USD. Ta różnica ma znaczenie w dyskusji o dostępności, ponieważ urządzenie z najsilniejszą historią na polu dostępności dla osób z niepełnosprawnościami to jednocześnie urządzenie, na które zdecydowana większość takich osób nie może sobie pozwolić bez ścieżki racjonalnych usprawnień finansowanych przez pracodawcę. Kształt rynku w połowie 2026 roku jest, mówiąc wprost, następujący: dostępne urządzenie jest drogie, a przystępne cenowo urządzenie jest na poziomie systemu dostępne głównie w tym sensie, że aktywnie nie uniemożliwia korzystania z niego.
Kategoria poza tą trójką — okulary inteligentne działające wyłącznie w trybie prześwietlenia (pass-through), takie jak Ray-Ban Meta, okulary klasy Xreal Air i różne gogle klasy enterprise stosowane w chirurgii i przemyśle — w dużej mierze nie uczestniczy w konsumenckiej rozmowie o dostępności XR. Większość tych urządzeń nie uruchamia systemu operacyjnego klasy desktop, nie udostępnia systemowego interfejsu API dostępności i trafia do środowiska regulacyjnego, które traktuje je jako akcesoria do noszenia, a nie komputery.
Specyfikacja WebXR — i czego jeszcze nie mówi
WebXR to specyfikacja W3C umożliwiająca przeglądarce przyznanie stronie internetowej dostępu do podłączonego urządzenia AR lub VR. Udostępnia obiekt sesji, kontekst renderowania (zazwyczaj warstwowany na WebGL2 lub WebGPU) oraz model źródeł wejściowych dla rąk, kontrolerów i spojrzenia. Wsparcie przeglądarek w połowie 2026 roku jest najsilniejsze w przeglądarkach opartych na Chromium (Chrome, Edge, Brave i kilka mobilnych przeglądarek XR), częściowe w Firefox przez wersję enterprise i historycznie nieobecne w Safari — Safari na visionOS obsługuje specyfikację, ale tylko wewnątrz sesji immersywnych i z semantyką wejściową dostarczaną przez mechanizm śledzenia rąk Apple. Stanowisko WebKit wobec WebXR zmieniło się znacząco w ciągu ostatnich dwunastu miesięcy, ale to nadal mniej dojrzała powierzchnia niż odpowiednik Chromium.
Specyfikacja określa możliwości gogli — renderowanie klatek stereo, raportowanie danych pozycji, udostępnianie transformacji chwytu i celowania, nasłuchiwanie zdarzeń select z kontrolera lub gestu uszczypnięcia. Prawie nic nie mówi o dostępności. Nie istnieje odpowiednik atrybutu alt dla obiektu w przestrzeni 3D. Nie ma formalnego modelu fokusa, przez który technologia wspomagająca mogłaby się przemieszczać. Nie istnieje sposób na poziomie specyfikacji, który pozwoliłby oznaczyć wirtualny przycisk tak, aby czytnik ekranu mógł go zapowiedzieć. Najbliższe hak dostępności w dzisiejszej specyfikacji WebXR to tablica profiles źródła wejściowego, która pozwala stronie zidentyfikować, czy dane wejściowe to ręka, kontroler czy kursor spojrzenia — a ta tablica istnieje ze względów renderowania treści, a nie ze względu na technologie wspomagające.
To nie jest krytyka W3C — to stwierdzenie stanu prac wykonanych i niewykonanych. Szkic WebXR Accessibility User Requirements (XAUR) przy W3C istnieje, a Immersive Web Working Group uznała większość istotnych luk. Jednak XAUR to dokument wymagań, a nie normatywna specyfikacja, i luka między „wiemy, czego specyfikacja potrzebuje“ a „specyfikacja normatywnie to określa“ to właśnie w praktyce miejsce, w którym żyje większość użytkowników z niepełnosprawnościami.
Dostępność Apple Vision Pro — szczegółowo
Vision Pro oferuje najsilniejszą historię dostępności na konsumenckim rynku XR, a przepaść między nim a resztą nie jest subtelna. Podstawowym sposobem wprowadzania danych w goglach jest śledzenie wzroku — użytkownik patrzy na cel, a stożek spojrzenia definiuje skupiony element — w połączeniu z małym zestawem gestów rąk wykrywanych przez skierowane w dół kamery. Dla osób z niepełnosprawnościami Apple dodało kilka powierzchni, które materialnie zmieniają możliwości wewnątrz visionOS.
Śledzenie wzroku jako podstawowy sposób wprowadzania danych oznacza, że użytkownicy z poważnym upośledzeniem motorycznym kończyn górnych mogą obsługiwać cały system operacyjny bez ruchu rąk czy ramion, pod warunkiem że ich spojrzenie jest wystarczająco precyzyjne, by utrwalić się na celu przez czas oczekiwania (dwell duration). Alternatywy dla śledzenia rąk pozwalają użytkownikom zastąpić domyślny gest uszczypnięcia stuknięciami jednym palcem, ruchami nadgarstka lub gestami samą głową, gdy standardowe uszczypnięcie jest zawodne — szczególnie ważna powierzchnia dla osób z zaburzeniami nerwowo-mięśniowymi wpływającymi na precyzyjną kontrolę palców. VoiceOver w przestrzeni 3D odczytuje skupiony element w kontekstach immersywnych i używa Spatial Audio, aby wskazać przestrzenną pozycję elementu względem głowy użytkownika — doświadczenie znacząco różne od czytnika ekranu na płaskim ekranie, które w działaniu zmniejsza obciążenie poznawcze związane z budowaniem mentalnego modelu sceny.
Spatial Audio dla dostępności wykracza poza VoiceOver. Sygnały dźwiękowe zdarzeń systemowych — powiadomienia, zmiany fokusa, otwieranie okien dialogowych — są pozycjonowane w przestrzeni 3D, dzięki czemu użytkownik słabowidzący lub niewidomy może je zlokalizować bez przemiatania wzrokiem. Kontrola przełącznikiem działa wewnątrz sesji immersywnych, choć wejście musi być sparowane przez tę samą konfigurację dostępności Apple, co na iPadOS lub macOS. Audiodeskrypcje są dostępne wewnątrz aplikacji Apple TV dla immersywnego wideo. Istnieje też wskazywanie głową jako niedawno dodana alternatywa dla użytkowników, których oczy nie śledzą precyzyjnie, choć jest wolniejsze i bardziej męczące niż domyślne sterowanie wzrokiem.
Żadna z tych funkcji nie jest doskonała. VoiceOver w aplikacjach zewnętrznych nadal zależy od tego, czy deweloper prawidłowo skonfigurował komponenty SwiftUI lub RealityKit, a katalog aplikacji zewnętrznych jest niewielki. Personalizacja śledzenia rąk wymaga przejścia przez kilka warstw ustawień i nie jest intuicyjnie wykrywalna. Samo kalibrowanie śledzenia wzroku może wielokrotnie zawodzić u użytkowników ze zezem, oczopląsem lub dysmetrią spojrzenia po udarze. Jednak w porównaniu z jakimkolwiek innym konsumenckim urządzeniem dostępnym na rynku w 2026 roku, warstwa dostępności Vision Pro jest jedyną, z którą osoba z niepełnosprawnością może usiąść i w rozsądny sposób spodziewać się, że będzie w stanie używać urządzenia.
Dostępność Meta Quest 3 i 3S — szczegółowo
Horizon OS nadrabia zaległości w ciągu ostatnich osiemnastu miesięcy, ale luka w stosunku do visionOS jest realna. Quest 3 i Quest 3S dostarczane są z systemowym czytnikiem ekranu, który zapowiada elementy interfejsu powłoki — Strona główna, Biblioteka, Sklep, Ustawienia — i działa wystarczająco niezawodnie wewnątrz własnych aplikacji Meta. Poza powłoką obraz się zmienia: większość aplikacji VR firm zewnętrznych renderuje swój interfejs wewnątrz własnego silnika (w większości przypadków Unity lub Unreal) i w ogóle nie podaje tekstu do systemowego czytnika ekranu. Niewidomy użytkownik może otworzyć sklep Quest, ale nie może w sposób niezawodny korzystać z większości tego, co kupuje.
Polecenia głosowe istnieją do nawigacji w powłoce („otwórz Bibliotekę“, „wróć na Stronę główną“) i w małym zestawie aplikacji. Tryb wysokiego kontrastu i filtr korekcji kolorów istnieją na poziomie systemowym. Ponowne mapowanie kontrolerów działa w interfejsie powłoki i w małym zestawie aplikacji korzystających z warstwy abstrakcji wejść Meta zamiast odczytywania przycisków kontrolera bezpośrednio. Śledzenie rąk istnieje jako modalność wejściowa, a ostatni firmware poprawił zestaw gestów, ale system śledzenia rąk Quest został zaprojektowany jako alternatywa bez kontrolera dla użytkowników bez niepełnosprawności, a nie jako wejście dostępnościowe — nie ma kliknięcia po zatrzymaniu (dwell-click), wskazywania głową jako zapasowego mechanizmu ani odpowiednika stuknięcia jednym palcem z Vision Pro.
Najbardziej zauważalną luką dla deweloperów jest brak opublikowanego interfejsu API dostępności dla Horizon OS. Deweloper budujący aplikację Quest opartą na Unity nie może dziś odczytywać systemowych ustawień dostępności, nie może zarejestrować aplikacji w systemowym czytniku ekranu i nie może udostępniać oznakowanych celów fokusa systemowi w sposób, który przetrwa między aplikacjami. Opublikowana przez Meta na początku 2025 roku mapa drogowa dostępności Quest zobowiązuje się do stworzenia takiego API, ale w połowie 2026 roku nie jest ono jeszcze dostarczane.
Przecięcie ARIA + WebXR — i niespełniona obietnica wejścia głosowego
Specyfikacja ARIA — zestaw atrybutów pozwalających deweloperowi udostępniać role, stany i właściwości technologii wspomagających — została zaprojektowana dla dokumentów dwuwymiarowych. Role takie jak button, dialog, tab czy navigation zakładają model fokusa poruszający się wzdłuż drzewa dokumentu. WebXR nie ma drzewa dokumentu w sensie WebGL lub WebGPU — istnieje graf sceny, ale żyje wewnątrz aplikacji, a nie w drzewie dostępności przeglądarki. Przecięcie ARIA i WebXR w połowie 2026 roku to w dużej mierze nieobecność: przeglądarka nie widzi struktury sceny 3D, czytnik ekranu nie może przez nią przechodzić, a deweloper nie może deklaratywnie oznaczyć wirtualnych obiektów tak, jak może oznaczać przyciski HTML.
Istnieją częściowe obejścia. Strona WebXR może renderować równoległą, opartą na DOM powierzchnię dostępności — ukrytą strukturę HTML odzwierciedlającą interaktywne elementy sceny 3D, z odpowiednimi rolami i etykietami ARIA, aktualizującą fokus gdy zmienia się selekcja 3D. Ten wzorzec działa, ale jest pracochłonny; podwaja koszt rozwoju i ma tendencję do desynchronizacji w miarę ewolucji sceny 3D. Immersive Web Working Group W3C dyskutowała o normatywnej propozycji „dostępnego elementu 3D“, który udostępniałby węzły grafu sceny drzewu dostępności, ale dyskusja nie jest jeszcze na etapie szkicu specyfikacji.
Drugim przecięciem, które powinno już istnieć i jeszcze nie istnieje, jest wejście oparte przede wszystkim na głosie. Przez kilka lat głos był retoryczną odpowiedzią na pytanie: „jak użytkownik z dysfunkcją motoryczną będzie nawigować w scenie 3D bez rąk?“ Rzeczywistość w 2026 roku jest taka, że wejście głosowe wewnątrz immersywnego XR jest zawodne. Mikrofon jest umieszczony blisko ust użytkownika, ale wewnątrz gogli, których odbiór dźwięku jest zoptymalizowany pod kątem renderowania przestrzennego dźwięku w skali pomieszczenia, a nie przechwytywania mowy. Poziomy ufności w rozpoznawaniu poleceń głosowych wewnątrz Vision Pro i Quest są wyraźnie niższe niż odpowiednie wartości na smartfonie. Obietnica „po prostu mów do urządzenia“ nie spełniła się, a przepływ pracy technologii wspomagających wewnątrz XR jest nadal oparty na gestach i spojrzeniu, z głosem jako zawodnym uzupełnieniem, a nie podstawową modalnością.
Trzecie przecięcie, o najdłuższym oddziaływaniu, to kwestia nawigacji gestem kontra nawigacja z laską. Osoby niewidome w przestrzeni fizycznej poruszają się za pomocą białej laski, psa przewodnika lub wskazówek echolokacyjnych; budowany przez nie model przestrzenny jest zakotwiczony w przeszkodach na poziomie podłogi i w propriocepcji ciała. Większość scen XR jest projektowana pod kątem siedzącego lub stojącego użytkownika, którego cele interakcji unoszą się na wysokości klatki piersiowej wewnątrz bounding boksu na skalę pomieszczenia. Niezgodność nie jest estetyczna — jest strukturalna. Model nawigacji „laską“, w którym użytkownik przesuwa uwagę wzdłuż niskoenergowej sondy przez scenę, nie odpowiada żadnemu wejściu obsługiwanemu przez obecne środowiska uruchomieniowe XR. Strona WebXR, która chciałaby udostępnić niewidomemu użytkownikowi powierzchnię nawigacji laską, musiałaby ją wynaleźć sama, bez żadnej pomocy ze strony przeglądarki, specyfikacji czy systemu operacyjnego.
Kierunek dla deweloperów w 2026 roku
Jeśli budujesz środowiska XR w 2026 roku i chcesz, żeby były użyteczne dla osób z niepełnosprawnościami, szczera odpowiedź brzmi: nie udostępniaj jeszcze opartego na przeglądarce WebXR użytkownikom z niepełnosprawnościami, chyba że jako treści uzupełniające. Jeśli budżet na to pozwala, udostępniaj natywne aplikacje visionOS — to jedyna platforma, gdzie warstwa dostępności jest realna, systemowe interfejsy API działają, a osoba z niepełnosprawnością może sparować aplikację z technologią wspomagającą, którą już zna. Udostępniaj natywne aplikacje Quest z ostrożnością, wiedząc, że systemowa warstwa dostępności obsługuje interakcje na poziomie powłoki, ale nie wewnątrz aplikacji, oraz że deweloper jest odpowiedzialny za zbudowanie odpowiednika drzewa dostępności wewnątrz własnego silnika aplikacji.
W przypadku WebXR odpowiedzialna postawa na rok 2026 to traktowanie go jako progresywnego ulepszenia. Doświadczenie należy zbudować najpierw jako płaską, dostępną powierzchnię HTML spełniającą odpowiednie kryteria sukcesu WCAG 2.2. Na to dopiero nakłada się immersywne środowisko XR dla użytkowników, którzy go pragną i mogą z niego korzystać, a jednocześnie należy zapewnić, że płaska powierzchnia dostarcza te same treści i te same rezultaty. Nie należy w 2026 roku udostępniać strony WebXR, która nie ma płaskiej wersji zastępczej, i oczekiwać, że osoba z niepełnosprawnością znajdzie alternatywną ścieżkę — tej ścieżki nie ma.
Szerszy kontekst jest taki, że historia dostępności XR jest w podobnym punkcie zwrotnym co historia dostępności sieci dwadzieścia lat temu: standardy nadrabiają zaległości, platformy się rozbieżniają, a luka między „czego potrzebują osoby z niepełnosprawnościami“ a „czego normatywnie wymaga specyfikacja“ jest szeroka. Prace, które muszą się wydarzyć w ciągu najbliższych dwóch lat — XAUR przechodzące od wymagań do normatywnej specyfikacji, stabilizacja propozycji drzewa dostępności dla 3D, poprawa wejścia głosowego wewnątrz gogli i faktyczne dostarczenie interfejsu API dostępności Horizon OS — są możliwe do zidentyfikowania. Czy nastąpią w harmonogramie, którego potrzebuje społeczność użytkowników, to inne pytanie — i takie, które ta redakcja będzie nadal śledzić.