Cada dieciocho meses, un ciclo de prensa sobre hardware de realidad mixta promete un futuro inclusivo. El lanzamiento del Apple Vision Pro en 2024 prometió uno. El lanzamiento del Meta Quest 3, y el Quest 3S más económico que lo siguió, prometió otro. La especificación WebXR — el estándar del W3C para la renderización de AR y VR dentro del navegador — lleva prometiéndolo desde 2018. La realidad, a mediados de 2026, es más sobria: existe exactamente un auricular de consumo en el mercado con una superficie de accesibilidad nativa seria, y la capa neutral para plataformas que subyace a todo esto es aún un vacío estructural donde se supone que deben vivir el texto alternativo, la gestión del foco y la semántica de las tecnologías de apoyo. Este artículo es una guía sobre dónde se encuentra realmente la tecnología: qué funciona hoy, qué sigue siendo promesa y qué debe y no debe publicar un desarrollador en 2026.
El enfoque es editorial, no evangelizador. No se argumenta que XR sea intrínsecamente más o menos accesible que la web bidimensional. Se argumenta que el panorama para los desarrolladores en materia de accesibilidad XR en 2026 se parece mucho al panorama para los desarrolladores en materia de accesibilidad web en 2002: un estándar emergente con la mayor parte de las palabras aún por definir, dos plataformas dominantes que avanzan a velocidades diferentes y un pequeño grupo de usuarios con discapacidad que porta la mayor parte del conocimiento práctico dentro de su propia memoria muscular.
El panorama de hardware en 2026
Tres dispositivos dominan el extremo de consumo del mercado de realidad mixta hoy en día, y adoptan tres posiciones diferentes respecto a la accesibilidad. Apple Vision Pro, con visionOS 2.4, es el único de los tres con una superficie de accesibilidad seria integrada en el propio sistema operativo: VoiceOver en espacio tridimensional, control por interruptores, personalización del seguimiento de manos, seguimiento ocular como entrada primaria y una implementación de Spatial Audio que los usuarios con discapacidad han descrito repetidamente como la más utilizable de la categoría. Meta Quest 3 y el más económico Quest 3S comparten sistema operativo — Horizon OS — con una capa de accesibilidad más delgada: modo de alto contraste, reasignación de mandos, un filtro de corrección de color, comandos de voz para la navegación y un lector de pantalla (añadido a mediados de 2024) que funciona dentro del intérprete de comandos del sistema, pero no de forma fiable dentro de las aplicaciones de terceros. El Sony PlayStation VR2 no incluye prácticamente ninguna función de accesibilidad nativa en su intérprete VR, aunque hereda la capa de accesibilidad general de PS5 cuando ejecuta contenido en pantalla plana.
Los precios han variado notablemente. El Vision Pro original se lanzó a aprox. 3.499 USD; el Quest 3 cuesta aprox. 499 USD y el Quest 3S aprox. 299 USD. Esa brecha tiene relevancia para el argumento de la accesibilidad, porque el dispositivo con la historia de entrada para personas con discapacidad más sólida es también el que la gran mayoría de las personas con discapacidad no puede permitirse sin una vía de ajuste razonable financiada por el empleador. La configuración del mercado a mediados de 2026 es, en términos llanos: el auricular accesible es caro, y el auricular asequible es, a nivel de sistema, accesible principalmente en el sentido de que no impide activamente su uso.
La categoría más allá de estos tres — gafas inteligentes de paso continuo como Ray-Ban Meta, gafas de visualización de clase Xreal Air y los distintos auriculares empresariales empleados en flujos de trabajo quirúrgicos e industriales — queda en gran medida fuera de la conversación sobre accesibilidad XR de consumo. La mayoría de estos dispositivos no ejecutan un sistema operativo de escritorio, no exponen una API de accesibilidad de nivel de sistema y se distribuyen en un panorama regulatorio que los trata como accesorios portátiles, no como ordenadores.
La especificación WebXR — y lo que aún no dice
WebXR es la especificación del W3C que permite a un navegador dar a un sitio web acceso a un dispositivo AR o VR conectado. Expone un objeto de sesión, un contexto de renderizado (generalmente superpuesto sobre WebGL2 o WebGPU) y un modelo de fuentes de entrada para manos, mandos y mirada. La compatibilidad con los navegadores, a mediados de 2026, es mayor en los navegadores basados en Chromium (Chrome, Edge, Brave y un puñado de navegadores XR móviles), parcial en Firefox mediante una compilación empresarial e históricamente ausente en Safari — el Safari de visionOS admite la especificación pero solo dentro de sesiones inmersivas y con la semántica de entrada que proporciona la canalización de seguimiento de manos de Apple. La posición de WebKit respecto a WebXR ha evolucionado de forma significativa en los últimos doce meses, pero sigue siendo una superficie menos madura que su homóloga en Chromium.
La especificación cubre lo que el auricular puede hacer — renderizar fotogramas estéreo, informar datos de pose, exponer transformaciones de agarre y apuntado, escuchar eventos de selección de un mando o un gesto de pellizco. Prácticamente no dice nada sobre accesibilidad. No existe el equivalente de un atributo alt para un objeto en el espacio tridimensional. No hay un modelo de foco formal por el que una tecnología de apoyo pueda desplazarse. No hay ninguna forma a nivel de especificación de etiquetar un botón virtual para que un lector de pantalla pueda anunciarlo. Lo más parecido a un gancho de accesibilidad en la especificación WebXR actual es el array profiles de la fuente de entrada, que permite a un sitio identificar si la entrada es una mano, un mando o un cursor de mirada — y ese array existe por razones de renderizado de contenido, no por razones de tecnología de apoyo.
Esto no es una crítica al W3C: es una declaración de dónde se ha realizado y dónde no se ha realizado el trabajo. El borrador de Requisitos de Usuarios de Accesibilidad WebXR (XAUR) existe en el W3C, y el Grupo de Trabajo de Web Inmersiva ha reconocido la mayor parte de las lagunas relevantes. Pero XAUR es un documento de requisitos, no una especificación normativa, y la distancia entre «sabemos qué necesita la especificación» y «la especificación lo dice normativamente» es, en la práctica, donde la mayoría de los usuarios con discapacidad viven hoy en día.
Accesibilidad de Apple Vision Pro, en detalle
Vision Pro es la historia de accesibilidad más sólida en el mercado XR de consumo hoy en día, y la distancia respecto al resto no es sutil. La entrada primaria del auricular es el seguimiento ocular — el usuario mira un objetivo y el cono de mirada define el elemento con foco — combinada con un pequeño conjunto de gestos de mano captados por cámaras orientadas hacia abajo. Para las personas con discapacidad, Apple ha añadido varias superficies que cambian materialmente lo que es posible dentro de visionOS.
El seguimiento ocular como entrada primaria permite que los usuarios con discapacidad motora grave en las extremidades superiores utilicen todo el sistema operativo sin movimiento de manos ni brazos, siempre que su mirada sea lo bastante estable como para fijarse en un objetivo durante el tiempo de permanencia establecido. Las alternativas de seguimiento de manos permiten a los usuarios sustituir los toques con un solo dedo, los movimientos de muñeca o los gestos solo con la cabeza cuando el gesto de pellizco predeterminado no es fiable — una superficie especialmente importante para usuarios con afecciones neuromusculares que afectan al control fino de los dedos. VoiceOver en espacio tridimensional anuncia el elemento con foco en contextos inmersivos y utiliza Spatial Audio para indicar la posición espacial del elemento en relación con la cabeza del usuario — una experiencia notablemente diferente a la de un lector de pantalla en pantalla plana y que, cuando funciona, reduce la carga cognitiva de construir un modelo mental de la escena.
Spatial Audio para la accesibilidad va más allá de VoiceOver. Las señales de audio para eventos del sistema — notificaciones, cambios de foco, apertura de diálogos — se posicionan en el espacio tridimensional para que un usuario con baja visión o ceguera pueda localizarlos sin necesidad de desplazar la mirada. El control por interruptores funciona en sesiones inmersivas, aunque la entrada debe emparejarse a través de la misma configuración de accesibilidad de Apple que en iPadOS o macOS. Las audiodescripciones se exponen dentro de la aplicación Apple TV para vídeo inmersivo. Y el apuntado con la cabeza existe como alternativa recientemente añadida para los usuarios cuya mirada no realiza un seguimiento fiable, aunque es más lento y más fatigante que el modo predeterminado guiado por los ojos.
Nada de esto es perfecto. VoiceOver en aplicaciones de terceros sigue dependiendo de que el desarrollador conecte correctamente los componentes de SwiftUI o RealityKit, y el catálogo de aplicaciones de terceros es pequeño. La personalización del seguimiento de manos requiere navegar por varias capas de configuración y no resulta fácilmente localizable. La propia calibración del seguimiento ocular puede fallar repetidamente en usuarios con estrabismo, nistagmo o dismetría de la mirada tras un accidente cerebrovascular. Pero en comparación con cualquier otro auricular de consumo en el mercado en 2026, la superficie de accesibilidad de Vision Pro es la única con la que un usuario con discapacidad puede sentarse y esperar razonablemente poder usar el dispositivo.
Accesibilidad de Meta Quest 3 y 3S, en detalle
Horizon OS ha ido recuperando terreno en los últimos dieciocho meses, pero la diferencia con visionOS es real. Quest 3 y Quest 3S incluyen un lector de pantalla a nivel de sistema que anuncia los elementos de la interfaz del intérprete — Inicio, Biblioteca, Tienda, Configuración — y que funciona de forma razonablemente fiable dentro de las aplicaciones propias de Meta. Fuera del intérprete, el panorama cambia: la mayoría de las aplicaciones VR de terceros renderiza su interfaz dentro de su propio motor (Unity o Unreal en la mayoría de los casos) y no envía texto al lector de pantalla del sistema. Un usuario ciego puede abrir la tienda Quest, pero no puede usar de forma fiable la mayor parte de lo que adquiere.
Los comandos de voz permiten la navegación por el intérprete («abrir Biblioteca», «ir a Inicio») y funcionan dentro de un pequeño conjunto de aplicaciones. El modo de alto contraste y un filtro de corrección de color existen a nivel de sistema. La reasignación de mandos funciona en la interfaz del intérprete y en el pequeño conjunto de aplicaciones que consumen la capa de abstracción de entrada de Meta en lugar de leer los botones del mando directamente. El seguimiento de manos existe como modalidad de entrada y el firmware reciente ha mejorado el conjunto de gestos, pero el sistema de seguimiento de manos del Quest fue diseñado como alternativa sin mando para usuarios sin discapacidad, no como entrada de accesibilidad: no hay clic por permanencia, no hay puntero de cabeza alternativo, no existe el equivalente del toque con un solo dedo del Vision Pro.
La laguna más notable, para el público desarrollador, es la ausencia de una API de accesibilidad publicada para Horizon OS. Hoy en día, un desarrollador que crea una aplicación Quest basada en Unity no puede leer la configuración de accesibilidad del sistema, no puede registrar la aplicación con el lector de pantalla del sistema y no puede exponer objetivos de foco etiquetados al sistema de una manera que se mantenga entre aplicaciones. La hoja de ruta de accesibilidad de Quest que Meta publicó a principios de 2025 se compromete con esa API, pero a mediados de 2026 no está disponible.
La intersección de ARIA y WebXR — y la promesa incumplida de la entrada por voz
La especificación ARIA — el conjunto de atributos que permiten a un desarrollador exponer roles, estados y propiedades a la tecnología de apoyo — fue diseñada para documentos bidimensionales. Roles como button, dialog, tab y navigation presuponen un modelo de foco que se desplaza a lo largo del árbol de documentos. WebXR no tiene un árbol de documentos en el sentido de WebGL o WebGPU — existe un grafo de escena, pero vive dentro de la aplicación, no dentro del árbol de accesibilidad del navegador. La intersección de ARIA y WebXR, a mediados de 2026, es en gran medida una ausencia: el navegador no puede ver la estructura de la escena tridimensional, el lector de pantalla no puede recorrerla y el desarrollador no puede etiquetar declarativamente los objetos virtuales del mismo modo que puede etiquetar botones HTML.
Existen soluciones parciales. Un sitio WebXR puede renderizar una superficie de accesibilidad paralela basada en el DOM — una estructura HTML oculta que refleja los elementos interactivos de la escena tridimensional con los roles y etiquetas ARIA adecuados, y que actualiza el foco cuando cambia la selección tridimensional. Este patrón es funcional, pero laborioso; duplica el coste de desarrollo y tiende a desincronizarse a medida que la escena tridimensional evoluciona. El Grupo de Trabajo de Web Inmersiva del W3C ha debatido una propuesta normativa de «elemento 3D accesible» que expondría los nodos del grafo de escena al árbol de accesibilidad, pero el debate aún no ha alcanzado la fase de borrador de especificación.
La otra intersección que debería existir ya y no existe es la entrada principalmente por voz. La voz fue, durante varios años, la respuesta retórica a «¿cómo navegará una persona con discapacidad motora por una escena tridimensional sin manos?». La realidad, en 2026, es que la entrada por voz dentro del XR inmersivo es poco fiable. El micrófono está posicionado cerca de la boca del usuario, pero dentro de un auricular cuya captación de sonido está optimizada para la renderización de audio espacial a escala de sala, no para la captura de voz. Los índices de confianza en el reconocimiento de comandos de voz dentro del Vision Pro y el Quest se sitúan muy por debajo de la cifra equivalente en un teléfono inteligente. La promesa de «solo habla con él» no se ha materializado, y el flujo de trabajo con tecnología de apoyo dentro del XR sigue siendo de gestos y mirada, con la voz como suplemento poco fiable en lugar de modalidad primaria.
La tercera intersección, y la de mayor recorrido, es la cuestión de la navegación mediante bastón frente a gestos. Las personas ciegas en el espacio físico navegan con un bastón blanco, un perro guía o señales de ecolocalización; el modelo espacial que construyen está anclado a los obstáculos a nivel del suelo y a la propiocepción corporal. La mayoría de las escenas XR están diseñadas para un usuario sentado o de pie cuyos objetivos de interacción flotan a la altura del pecho dentro de un cuadro delimitador a escala de sala. El desajuste no es estético: es estructural. El modelo de «bastón», en el que el usuario desplaza su atención a lo largo de una sonda de baja energía a través de la escena, no se corresponde con ninguna entrada que los runtimes XR actuales admitan. Un sitio WebXR que quisiera exponer una superficie de navegación mediante bastón a un usuario ciego tendría que inventar esa superficie por sí mismo, sin ninguna ayuda del navegador, la especificación ni el sistema operativo.
Por dónde deben ir los desarrolladores en 2026
Si se están desarrollando experiencias XR en 2026 y se quiere que sean utilizables por personas con discapacidad, la respuesta honesta es: no publicar WebXR basado en navegador para personas con discapacidad todavía, salvo como contenido complementario. Publicar aplicaciones nativas de visionOS si el presupuesto lo permite, porque esa es la única plataforma donde la superficie de accesibilidad es real, las APIs de nivel de sistema funcionan y una persona con discapacidad puede emparejar la aplicación con la tecnología de apoyo que ya conoce. Publicar aplicaciones nativas de Quest con cautela, sabiendo que la superficie de accesibilidad del sistema captará las interacciones a nivel de intérprete pero no las que se producen dentro de la aplicación, y que el desarrollador es responsable de construir el equivalente de un árbol de accesibilidad dentro del propio motor de la aplicación.
Para WebXR específicamente, la postura responsable en 2026 es tratarlo como una mejora progresiva. Construir la experiencia primero como una superficie HTML plana y accesible que cumpla los criterios de conformidad WCAG 2.2 pertinentes. Superponer la experiencia XR inmersiva encima para los usuarios que la deseen y puedan utilizarla, y asegurarse de que la superficie plana ofrezca el mismo contenido y los mismos resultados. No publicar en 2026 un sitio WebXR que no tenga alternativa plana y esperar que una persona con discapacidad encuentre un camino alternativo — no existe.
El panorama general es que la historia de la accesibilidad XR se encuentra en un punto de inflexión similar al de la historia de accesibilidad de la web hace veinte años: los estándares están poniéndose al día, las plataformas están divergiendo y la brecha entre «lo que necesitan las personas con discapacidad» y «lo que la especificación requiere normativamente» es amplia. El trabajo que debe realizarse en los próximos dos años — que XAUR pase de requisitos a especificación normativa, que la propuesta de árbol de accesibilidad para 3D se estabilice, que la entrada por voz mejore dentro de los auriculares y que efectivamente se publique una API de accesibilidad para Horizon OS — es identificable. Si sucede en el plazo que la comunidad de usuarios necesita es una pregunta diferente, y una que esta publicación seguirá monitorizando.