На всеки осемнадесет месеца един рекламен цикъл за хардуер за смесена реалност обещава приобщаващо бъдеще. Пускането на Apple Vision Pro през 2024 г. обеща такова. Пускането на Meta Quest 3 и по-малкият Quest 3S, който го последва, обещаха друго. Спецификацията WebXR — стандартът на W3C за AR и VR, рендирани вътре в браузъра — обещава такова от 2018 г. Реалността в средата на 2026 г. е по-отрезвяваща: на пазара има точно един потребителски хедсет със сериозна, нативна повърхност за достъпност, а платформено-неутралният браузърен слой под всичко това все още е структурна празнота там, където би трябвало да живеят алтернативният текст, управлението на фокуса и семантиката за помощните технологии. Този материал е ръководство за това докъде всъщност е стигнала технологията — какво работи днес, какво е празни обещания и какво един разработчик през 2026 г. трябва и не трябва да пуска.
Рамката е редакционна, а не евангелистка. Не твърдим, че XR по същество е повече или по-малко достъпен от двумерния уеб. Твърдим, че историята за разработчиците на XR достъпност през 2026 г. изглежда горе-долу като историята за разработчиците на уеб достъпност през 2002 г.: нововъзникващ стандарт, на който липсват повечето думи, две доминиращи платформи, движещи се с различна скорост, и малка група потребители с увреждания, които носят по-голямата част от практическото знание в собствената си мускулна памет.
Хардуерният пейзаж през 2026 г.
Три устройства доминират потребителския край на пазара за смесена реалност днес и те заемат три различни позиции по отношение на достъпността. Apple Vision Pro, работещ с visionOS 2.4, е единственото от трите устройства със сериозна повърхност за достъпност, вградена в самата операционна система — VoiceOver в триизмерно пространство, превключвателно управление, персонализиране на проследяването на ръцете, проследяване на погледа като основен вход и реализация на Spatial Audio, която потребители с увреждания многократно са описвали като най-използваемата в категорията. Meta Quest 3 и по-евтиният Quest 3S споделят една ОС — Horizon OS — с по-тънък слой за достъпност: режим на висок контраст, преназначаване на контролера, филтър за цветова корекция, гласови команди за навигация и екранен четец (добавен в средата на 2024 г.), който работи вътре в системната обвивка, но не надеждно вътре в приложения на трети страни. Sony PlayStation VR2 идва на практика без нативни функции за достъпност вътре в своята VR обвивка, макар че наследява по-широкия слой за достъпност на PS5, когато изпълнява съдържание на плосък екран.
Ценообразуването се промени осезаемо. Оригиналният Vision Pro беше пуснат на цена прибл. 3499 USD; Quest 3 е прибл. 499 USD, а Quest 3S — прибл. 299 USD. Тази разлика има значение за аргумента за достъпността, защото устройството с най-силната история за вход за хора с увреждания е и устройството, което огромното мнозинство потребители с увреждания не могат да си позволят да купят без финансиран от работодателя път за разумни улеснения. Формата на пазара в средата на 2026 г. е, казано просто: достъпният хедсет е скъп, а достъпният по цена хедсет е, на системно ниво, достъпен предимно в смисъл, че не ви пречи активно да го използвате.
Категорията отвъд тези три — само-pass-through умни очила като Ray-Ban Meta, дисплейни очила от класа на Xreal Air и различните корпоративни хедсети, използвани в хирургични и индустриални работни процеси — е до голяма степен извън разговора за потребителската XR достъпност. Повечето от тези устройства не работят с ОС от настолен клас, не предоставят системно ниво API за достъпност и излизат в регулаторен пейзаж, който ги третира като носими аксесоари, а не като компютри.
Спецификацията WebXR — и какво все още не казва
WebXR е спецификацията на W3C, която позволява на браузъра да даде на уебсайт достъп до прикачено AR или VR устройство. Тя предоставя обект на сесия, контекст за рендиране (обикновено наслоен върху WebGL2 или WebGPU) и модел на входните източници за ръце, контролери и поглед. Поддръжката от браузърите в средата на 2026 г. е най-силна в браузърите на основата на Chromium (Chrome, Edge, Brave и шепа мобилни XR браузъри), частична във Firefox чрез корпоративна компилация и исторически отсъстваща от Safari — Safari на visionOS поддържа спецификацията, но само вътре в потапящи сесии и с входната семантика, която доставя пайплайнът за проследяване на ръцете на Apple. Позицията на WebKit относно WebXR се измести осезаемо през последните дванадесет месеца, но тя все още е по-незряла повърхност от аналога ѝ в Chromium.
Спецификацията обхваща какво може да прави хедсетът — да рендира стерео кадри, да докладва данни за позата, да предоставя трансформации за хващане и насочване, да слуша за select събития от контролер или жест с щипка. Тя не казва почти нищо за достъпността. Няма еквивалент на атрибута alt за обект в триизмерно пространство. Няма формален модел на фокуса, през който помощна технология да може да премине. Няма начин на ниво спецификация да се обозначи виртуален бутон, така че екранен четец да може да го обяви. Най-близкото до закачка за достъпност в спецификацията WebXR днес е масивът profiles на входния източник, който позволява на сайта да определи дали входът е ръка, контролер или курсор по погледа — а този масив съществува по причини, свързани с рендиране на съдържание, а не с помощни технологии.
Това не е критика към W3C — то е констатация за това къде работата е и не е свършена. Чернова WebXR Accessibility User Requirements (XAUR) наистина съществува в W3C, а Immersive Web Working Group призна повечето от съответните празнини. Но XAUR е документ с изисквания, а не нормативна спецификация, и разликата между „знаем какво трябва на спецификацията“ и „спецификацията нормативно го казва“ е на практика мястото, където живеят повечето потребители с увреждания днес.
Достъпността на Apple Vision Pro, в детайли
Vision Pro е най-силната история за достъпност на потребителския XR пазар днес и разликата между него и всички останали не е незначителна. Основният вход на хедсета е проследяване на погледа — потребителят гледа цел и конусът на погледа определя фокусирания елемент — съчетано с малък набор жестове с ръце, засичани от насочени надолу камери. За потребители с увреждания Apple е добавил няколко повърхности, които съществено променят какво е възможно вътре във visionOS.
Проследяването на погледа като основен вход означава, че потребители с тежко двигателно нарушение на горните крайници могат да управляват цялата ОС без движение на ръка или ръка, при условие че погледът им е достатъчно надежден, за да фиксира цел за продължителността на задържане. Алтернативите за проследяване на ръцете позволяват на потребителите да заменят с потупвания с един пръст, движения на китката или само жестове с глава, когато стандартната щипка и потупване са ненадеждни — особено важна повърхност за потребители с нервно-мускулни състояния, засягащи фината моторика на пръстите. VoiceOver в триизмерно пространство прочита фокусирания елемент в потапящи контексти и използва Spatial Audio, за да укаже пространственото положение на елемента спрямо главата на потребителя — съществено различно изживяване от плосък екранен четец и такова, което, когато работи, намалява когнитивното натоварване при изграждането на ментален модел на сцената.
Spatial Audio за достъпност надхвърля VoiceOver. Аудио сигналите за системни събития — известия, промени на фокуса, отваряния на диалогови прозорци — са позиционирани в триизмерно пространство, така че потребител със слабо зрение или незрящ да може да ги локализира, без да обхожда с поглед. Превключвателното управление работи вътре в потапящи сесии, макар че входът трябва да бъде сдвоен през същата настройка за достъпност на Apple, както на iPadOS или macOS. Аудио описанията са предоставени вътре в приложението Apple TV за потапящо видео. А насочването с глава съществува като наскоро добавена алтернатива за потребители, чиито очи не проследяват надеждно, макар че е по-бавно и по-уморително от управлявания с поглед стандарт.
Нищо от това не е съвършено. VoiceOver в приложения на трети страни все още зависи от това разработчикът да свърже правилно компонентите на SwiftUI или RealityKit, а каталогът от приложения на трети страни е малък. Персонализирането на проследяването на ръцете изисква преминаване през няколко слоя настройки и не е лесно за откриване. Самата калибрация на проследяването на погледа може да се проваля многократно за потребители със страбизъм, нистагъм или дисметрия на погледа след инсулт. Но в сравнение с който и да е друг потребителски хедсет на пазара през 2026 г. повърхността за достъпност на Vision Pro е единствената, с която потребител с увреждане може да седне и разумно да очаква да използва устройството.
Достъпността на Meta Quest 3 и 3S, в детайли
Horizon OS наваксва през последните осемнадесет месеца, но разликата с visionOS е реална. Quest 3 и Quest 3S идват със системно ниво екранен четец, който обявява UI елементи на обвивката — Home, Library, Store, Settings — и който работи сравнително надеждно вътре в собствените приложения на Meta. Извън обвивката картината се променя: повечето VR приложения на трети страни рендират своя UI вътре в собствения си енджин (Unity или Unreal в повечето случаи) и изобщо не подават текст към системния екранен четец. Незрящ потребител може да отвори магазина на Quest, но не може надеждно да играе повечето от това, което купи.
Гласовите команди съществуват за навигация в обвивката („open Library“, „go Home“) и вътре в малък набор приложения. Режим на висок контраст и филтър за цветова корекция съществуват на системно ниво. Преназначаването на контролера работи в UI на обвивката и в малкия набор приложения, които ползват слоя за абстракция на входа на Meta, вместо да четат бутоните на контролера директно. Проследяването на ръцете съществува като входна модалност, а скорошният фърмуер подобри набора жестове, но системата за проследяване на ръцете на Quest беше проектирана като алтернатива без контролер за потребители без увреждания, а не като вход за достъпност — няма щракване чрез задържане, няма резервен вариант с насочване с глава, няма еквивалент на потупването с един пръст на Vision Pro.
Най-забележителната празнина за аудитория от разработчици е отсъствието на публикуван API за достъпност за Horizon OS. Разработчик, изграждащ базирано на Unity приложение за Quest, днес не може да чете системните настройки за достъпност, не може да регистрира приложението при системния екранен четец и не може да предостави обозначени цели за фокус на системата по начин, който оцелява между приложенията. Пътната карта за достъпност на Quest, която Meta публикува в началото на 2025 г., се ангажира с такъв API, но към средата на 2026 г. той не е пуснат.
Пресечната точка на ARIA + WebXR — и нарушеното обещание за гласов вход
Спецификацията ARIA — наборът атрибути, които позволяват на разработчика да предостави роли, състояния и свойства на помощната технология — беше проектирана за двумерни документи. Роли като button, dialog, tab и navigation предполагат модел на фокуса, който се движи по дървото на документа. WebXR няма дърво на документа в смисъла на WebGL или WebGPU — има граф на сцената, но той живее вътре в приложението, а не вътре в дървото за достъпност на браузъра. Пресечната точка на ARIA и WebXR в средата на 2026 г. е до голяма степен отсъствие: браузърът не може да види структурата на триизмерната сцена, екранният четец не може да премине през нея, а разработчикът не може декларативно да обозначи виртуални обекти така, както може да обозначи HTML бутони.
Има частични заобиколни решения. WebXR сайт може да рендира паралелна, базирана на DOM повърхност за достъпност — скрита HTML структура, която отразява интерактивните елементи на триизмерната сцена, с подходящи ARIA роли и обозначения, и която актуализира фокуса, когато триизмерният избор се промени. Този модел е работещ, но трудоемък; той удвоява разходите за разработка и обикновено се разминава, докато триизмерната сцена се развива. Immersive Web Working Group на W3C обсъди нормативно предложение за „достъпен 3D елемент“, което би предоставило възлите на графа на сцената на дървото за достъпност, но обсъждането все още не е на етап чернова спецификация.
Другата пресечна точка, която вече би трябвало да съществува и не съществува, е гласово-приоритетният вход. Гласът беше в продължение на няколко години риторичният отговор на „как двигателно затруднен потребител ще навигира в триизмерна сцена без ръце?“ Реалността през 2026 г. е, че гласовият вход вътре в потапящ XR е нестабилен. Микрофонът е разположен близо до устата на потребителя, но вътре в хедсет, чието улавяне на звук е оптимизирано за пространствено аудио рендиране в мащаба на стая, а не за улавяне на реч. Интервалите на доверие при разпознаването на гласови команди вътре във Vision Pro и Quest са доста под еквивалентната стойност на смартфон. Обещанието „просто му говори“ не се материализира, а работният процес с помощни технологии вътре в XR все още се управлява с жестове и поглед, като гласът е ненадеждна добавка, а не основна модалност.
Третата пресечна точка, и тази с най-дълга опашка, е въпросът за навигация с жестове срещу бастун. Незрящите потребители във физическото пространство навигират чрез бял бастун, куче водач или ехолокационни сигнали; пространственият модел, който изграждат, е закотвен към препятствия на ниво пода и към проприоцепцията на тялото. Повечето XR сцени са проектирани около седнал или прав потребител, чиито интерактивни цели се носят на височина на гърдите вътре в ограничителна кутия в мащаба на стая. Несъответствието не е естетическо — то е структурно. Моделът на навигация „с бастун“, при който потребителят движи вниманието си по нискоенергийна сонда през сцената, не се картографира върху никой вход, който поддържат настоящите XR среди за изпълнение. WebXR сайт, който би искал да предостави повърхност за навигация с бастун на незрящ потребител, би трябвало да изобрети самата повърхност, без помощ от браузъра, спецификацията или ОС.
Накъде да вървят разработчиците през 2026 г.
Ако изграждате XR изживявания през 2026 г. и искате те да са използваеми от потребители с увреждания, честният отговор е: все още не пускайте базиран на браузър WebXR за потребители с увреждания, освен като допълнително съдържание. Пускайте нативни приложения за visionOS, ако бюджетът позволява, защото това е единствената платформа, където повърхността за достъпност е реална, системните API работят и потребител с увреждане може да сдвои приложението с помощна технология, която вече познава. Пускайте нативни приложения за Quest с предпазливост, знаейки, че системната повърхност за достъпност ще улови взаимодействията на ниво обвивка, но не и тези вътре в приложението, и че разработчикът отговаря за изграждането на еквивалента на дърво за достъпност вътре в собствения енджин на приложението.
Конкретно за WebXR отговорната позиция през 2026 г. е той да се третира като прогресивно подобрение. Изградете изживяването първо като плоска, достъпна HTML повърхност, която отговаря на съответните критерии за успех на WCAG 2.2. Наслоете потапящото XR изживяване отгоре за потребители, които искат и могат да го използват, и осигурете плоската повърхност да доставя същото съдържание и същите резултати. Не пускайте през 2026 г. WebXR сайт, който няма плосък резервен вариант, и не очаквайте потребител с увреждане да намери алтернативен път през него — такъв няма.
По-голямата картина е, че историята за XR достъпността е в сходна повратна точка с тази, в която беше историята за уеб достъпността преди двадесет години: стандартите наваксват, платформите се разминават, а разликата между „какво трябва на потребителите с увреждания“ и „какво спецификацията нормативно изисква“ е голяма. Работата, която трябва да се случи през следващите две години — преминаването на XAUR от изисквания към нормативна спецификация, стабилизирането на предложението за дърво за достъпност за 3D, подобряването на гласовия вход вътре в хедсетите и реалното пускане на API за достъпност за Horizon OS — е разпознаваема. Дали тя ще се случи на графика, който потребителската общност изисква, е друг въпрос, и такъв, който това издание ще продължи да проследява.