每隔十八个月，一轮混合现实硬件媒体周期便会承诺一个无障碍的未来。2024年Apple Vision Pro发布时如此，Meta Quest 3发布时如此，其后推出的更低价的Quest 3S亦如此。W3C制定的浏览器内AR与VR渲染标准WebXR规范，自2018年便一直如此承诺。然而2026年中期的现实更为清醒：市面上有且仅有一款消费级头显配备真正意义上的原生无障碍接口，而承载这一切的平台中立浏览器层依然是一片结构性空白——替代文本、焦点管理与辅助技术语义本应在此安居，却迟迟付诸阙如。本文是关于技术现状的入门文章——当前哪些可用、哪些是空谈，以及2026年的开发者应当发布什么、不应发布什么。
本文的立场是评析性的，而非布道性的。我们并不主张XR本质上比二维网页更无障碍或更不无障碍。我们的立场是：2026年XR无障碍的开发者叙事，与2002年网页无障碍开发者叙事颇为相似——一个大多数词汇尚未写就的新兴规范，两个主流平台以不同速度推进，以及一小群残障用户将大部分实践知识储存于自身的肌肉记忆之中。
2026年硬件格局
目前有三款设备主导消费级混合现实市场，且三者对无障碍持有三种截然不同的立场。运行visionOS 2.4的Apple Vision Pro，是三者中唯一在操作系统层面构建了真正无障碍接口的设备——三维空间中的VoiceOver、开关控制、手部追踪自定义、以眼动追踪为主要输入方式，以及一套被残障用户反复描述为同类中最可用的空间音频实现。Meta Quest 3与低价版Quest 3S共享一套操作系统——Horizon OS——其无障碍层较为薄弱：高对比度模式、控制器键位重映射、颜色校正滤镜、导航语音命令，以及一款屏幕阅读器（2024年中期新增），该屏幕阅读器在系统界面内可用，但在第三方应用中的可靠性有限。索尼PlayStation VR2在其VR界面内几乎没有任何原生无障碍功能，尽管在运行平面屏幕内容时可继承更广泛的PS5无障碍层。
定价已发生显著变化。原版Vision Pro发售价约为3,499美元；Quest 3约为499美元，Quest 3S约为299美元。这一价格差距对无障碍论述至关重要：残障用户输入支持最强的设备，恰恰是绝大多数残障用户在没有雇主合理便利资助的情况下无力购买的设备。2026年中期的市场面貌直白地呈现为：无障碍性最强的头显价格高昂，而价格实惠的头显在系统层面上的无障碍性，基本上仅停留于”不主动阻止使用”的程度。
这三款之外的品类——如Ray-Ban Meta等仅具透视功能的智能眼镜、Xreal Air系列显示眼镜，以及手术和工业流程中使用的各类企业级头显——基本游离于消费级XR无障碍讨论之外。这些设备大多不运行桌面级操作系统，不公开系统级无障碍API，且所适用的监管环境将其视为可穿戴配件而非计算机。
WebXR规范——以及它尚未涉及的内容
WebXR是W3C制定的规范，允许浏览器将网站接入所连接的AR或VR设备。它暴露一个会话对象、一个渲染上下文（通常叠加于WebGL2或WebGPU之上），以及一套面向手部、控制器和视线的输入源模型。截至2026年中期，浏览器支持在基于Chromium的浏览器（Chrome、Edge、Brave及若干移动端XR浏览器）中最为完善，在Firefox企业版中部分支持，在Safari中历来缺失——visionOS Safari支持该规范，但仅限于沉浸式会话，且仅采用Apple手部追踪管线所提供的输入语义。WebKit对WebXR的支持立场在过去十二个月内有所推进，但仍不及Chromium对应实现成熟。
该规范涵盖头显所能做到的事情——渲染立体帧、报告姿态数据、暴露抓取和瞄准变换、监听来自控制器或捏合手势的选择事件。但关于无障碍，它几乎只字未提。三维空间中的对象没有等同于alt属性的机制，辅助技术没有可以逐一遍历的正式焦点模型，开发者也没有规范层面的方式为虚拟按钮添加标签以供屏幕阅读器朗读。WebXR规范中最接近无障碍钩子的内容，是输入源的profiles数组，它允许网站识别输入来自手部、控制器还是视线光标——而该数组的存在出于内容渲染目的，而非辅助技术目的。
这并非对W3C的批评，而是对工作推进状态的客观描述。WebXR无障碍用户需求（XAUR）草案确实存在于W3C，沉浸式网页工作组也已承认大多数相关差距。但XAUR是一份需求文档，而非规范性规范，“我们知道规范需要什么”与”规范已经规范性地要求此事”之间的鸿沟，在实践层面正是大多数残障用户所居住之处。
Apple Vision Pro的无障碍功能详解
Vision Pro是当前消费级XR市场上无障碍支持最强的产品，且与其他产品的差距绝非微小。该头显的主要输入方式是眼动追踪——用户注视目标，视线锥体定义当前聚焦元素——结合由下置摄像头感知的一套小型手势。针对残障用户，Apple增加了若干实质性改变visionOS可用空间的功能面。
眼动追踪作为主要输入方式意味着，只要凝视足够稳定、能在注视目标上停留指定的停留时长，上肢严重运动障碍的用户无需任何手部或手臂动作即可驱动整个操作系统。手部追踪替代方式允许用户在默认捏合手势不可靠时，以单指轻点、腕部运动或仅用头部手势代替——对于精细手指控制受神经肌肉疾病影响的用户而言，这一功能面尤为重要。三维空间中的VoiceOver在沉浸式环境中朗读当前聚焦元素，并利用空间音频指示元素相对于用户头部的空间位置——与平面屏幕阅读器相比，这是一种有实质意义的不同体验，且在正常工作时，能够降低在脑海中构建场景心理模型所需的认知负荷。
面向无障碍的空间音频不止于VoiceOver。系统事件的音频提示——通知、焦点变化、对话框开启——被定位于三维空间中，以便低视力或盲人用户无需扫视即可定位。开关控制在沉浸式会话中可用，尽管输入设备须通过与iPadOS或macOS上相同的Apple无障碍设置配对。音频描述在Apple TV应用的沉浸式视频中可用。头部指向作为眼动追踪不可靠时的替代方案被近期新增，但比眼动驱动的默认方式更慢且更耗体力。
上述功能并不完美。第三方应用中的VoiceOver仍有赖于开发者正确连接SwiftUI或RealityKit组件，而第三方应用目录数量有限。手部追踪自定义须经过多层设置，可发现性有限。眼动追踪校准本身对于患有斜视、眼球震颤或中风后眼动测距异常的用户可能反复失败。但与2026年市场上任何其他消费级头显相比，Vision Pro的无障碍接口是唯一一个残障用户坐下来就能合理期望正常使用设备的产品。
Meta Quest 3与Quest 3S的无障碍功能详解
Horizon OS在过去十八个月中持续追赶，但与visionOS的差距依然真实存在。Quest 3与Quest 3S预装了一款系统级屏幕阅读器，能够朗读界面元素——主页、媒体库、商店、设置——并在Meta自有应用中可靠工作。离开系统界面后，情况便有所不同：大多数第三方VR应用在其自有引擎（多数情况下为Unity或Unreal）内渲染界面，完全不将文本传递给系统屏幕阅读器。盲人用户可以打开Quest商店，却往往无法可靠地使用所购内容。
语音命令用于界面导航（“打开媒体库”、“回到主页”）以及少量应用内导航。系统层面提供高对比度模式和颜色校正滤镜。控制器键位重映射在界面及少数接入Meta输入抽象层（而非直接读取控制器按键）的应用中可用。手部追踪作为输入方式存在，近期固件已改进手势集，但Quest手部追踪系统的设计初衷是为非残障用户提供无控制器替代方案，而非无障碍输入——没有停留点击、没有头部指针回退、没有等同于Vision Pro单指轻点的功能。
对于开发者而言，最值得关注的缺口是Horizon OS缺乏已发布的无障碍API。基于Unity构建Quest应用的开发者目前无法读取系统无障碍设置，无法在系统屏幕阅读器中注册应用，也无法以一种在应用间可持续的方式向系统暴露带标签的焦点目标。Meta于2025年初发布的Quest无障碍路线图承诺提供此类API，但截至2026年中期，该API尚未发布。
ARIA与WebXR的交集——以及语音输入的落空承诺
ARIA规范——允许开发者向辅助技术暴露角色、状态和属性的属性集合——专为二维文档设计。button、dialog、tab和navigation等角色预设了一个沿文档树移动的焦点模型。WebXR在WebGL或WebGPU意义上没有文档树——存在的是一个场景图，但它位于应用内部，而非浏览器的无障碍树内部。2026年中期ARIA与WebXR的交集，在很大程度上是一种缺席：浏览器看不到三维场景的结构，屏幕阅读器无法遍历它，开发者也无法以声明式方式为虚拟对象添加标签，正如为HTML按钮添加标签那样。
存在部分变通方案。WebXR网站可以渲染一个并行的基于DOM的无障碍接口——一个镜像三维场景交互元素、具有正确ARIA角色和标签的隐藏HTML结构，并在三维选择变化时更新焦点。这一模式可以工作，但操作繁琐；它使开发成本翻倍，并且随着三维场景的演进往往会逐渐与之脱节。W3C沉浸式网页工作组讨论了一项规范性的”无障碍三维元素”提案，将场景图节点暴露给无障碍树，但该讨论尚未进入草案规范阶段。
另一个本应在现在实现却尚未实现的交集是语音优先输入。数年来，语音一直是”运动障碍用户如何在无手的情况下导航三维场景”这一问题的修辞性答案。2026年的现实是，沉浸式XR内部的语音输入仍然脆弱。麦克风位于用户嘴部附近，但在针对房间级空间音频渲染而非语音捕捉优化的头显内部，置信区间远低于智能手机上的等效数字。“直接说话”的承诺尚未成真，XR内的辅助技术工作流程仍以手势和视线为驱动，语音作为不可靠的补充而非主要输入方式。
第三个交集，也是影响最为深远的一个，是手势与手杖导航的问题。盲人用户在物理空间中依靠白色手杖、导盲犬或回声定位线索导航；他们构建的空间模型锚定于地面障碍物和身体的本体感觉。大多数XR场景以坐姿或站立姿势的用户为设计对象，交互目标漂浮于房间级边界框中胸部高度的空间。这种不匹配并非美学层面的，而是结构性的。“手杖”式导航模型——用户将注意力沿着场景中低能量探针移动——无法映射到当前任何XR运行时所支持的输入方式。一个想要为盲人用户提供手杖式导航接口的WebXR网站，必须自行发明该接口，在浏览器、规范或操作系统毫无帮助的情况下独自完成。
2026年开发者指引
如果在2026年构建XR体验并希望其对残障用户可用，诚实的答案是：暂时不要向残障用户发布基于浏览器的WebXR——除非作为补充性内容。如果预算允许，发布原生visionOS应用，因为那是无障碍接口真实存在、系统级API正常工作、残障用户可以将应用与其已熟悉的辅助技术配对使用的唯一平台。发布原生Quest应用时须保持审慎，知晓系统无障碍接口可处理界面级交互，但无法处理应用内交互，且开发者须自行在应用引擎内部构建等同于无障碍树的结构。
具体到WebXR，负责任的2026年做法是将其视为渐进增强。首先将体验构建为符合相关WCAG 2.2成功准则的平面、无障碍HTML接口，再将沉浸式XR体验叠加其上供有需求且有能力使用的用户选用，并确保平面接口提供同等内容和同等结果。在2026年，不要发布一个没有平面回退的WebXR网站，并期望残障用户自行找到替代路径——因为根本不存在这样的路径。
更宏观的图景是：XR无障碍叙事正处于与二十年前网页无障碍叙事相似的拐点：规范正在追赶，平台正在分化，“残障用户所需”与”规范规范性要求”之间的鸿沟依然宽广。未来两年需要完成的工作——XAUR从需求文档进化为规范性规范、三维无障碍树提案趋于稳定、头显内语音输入改善，以及Horizon OS无障碍API真正发布——是可以识别出来的。这些工作是否能在用户社区所需要的时间线内完成，则是另一个问题，本刊将持续跟踪。