VR accesible y WCAG: qué encaja, qué se rompe y la checklist con la que trabajamos

La VR accesible es la práctica de diseñar experiencias inmersivas que una persona pueda usar con independencia de su visión, audición, movilidad o tolerancia al malestar. Las Web Content Accessibility Guidelines (WCAG) se escribieron para documentos planos e interfaces 2D, así que solo encajan en la VR a medias: los principios sobreviven, los criterios de éxito casi todos no. Así traducimos las WCAG a la realidad de un head-mounted display (HMD), aquí es donde se rompen, y esta es la checklist con la que trabajamos en cada proyecto inmersivo.

VR accesible y WCAG: por qué falla una adaptación directa

Las WCAG se organizan en torno a cuatro principios — Perceptible, Operable, Comprensible, Robusto (POUR). Son sólidos en cualquier medio. El problema es que los criterios de éxito que hay debajo dan por supuesta una página: un viewport con ejes x/y, un DOM, un teclado, un lector de pantalla recorriendo un árbol lineal. La VR no tiene nada de eso. No hay orden de tabulación en una sala. No hay tamaño de letra fijo cuando el texto flota a dos metros delante y puedes inclinarte hacia él. El contraste deja de ser una propiedad de dos valores hexadecimales; depende de la lente, del panel, de la luz ambiente que entra alrededor de la interfaz facial y de hacia dónde mira el usuario.

Por eso mantenemos los cuatro principios como brújula y reconstruimos los criterios para tres dimensiones. Los XR Accessibility User Requirements (XAUR) del W3C son lo más parecido a un puente oficial, y es el documento que entregamos a los nuevos colaboradores antes de que toquen una escena. Las WCAG te dan el espíritu; los XAUR te dan el vocabulario inmersivo; la checklist de abajo es lo que verificamos de verdad.

Perceptible: subtítulos, contraste y señales de audio en 3D

Los subtítulos en VR no son una pista que se superpone a un rectángulo — son un objeto en el espacio, y dónde colocas ese objeto decide si funcionan. Los subtítulos fijados en la parte baja del campo de visión marean, porque el texto nada contra el movimiento de la cabeza. Nosotros anclamos los subtítulos a un billboard que sigue suavemente la cabeza con un ligero retardo y una zona muerta, de modo que sigan legibles sin quedar rígidamente atados a la mirada. Para diálogos entre dos personajes o estaciones, añadimos un indicador direccional — una pequeña flecha o un brillo sutil — para que un usuario sordo o con pérdida auditiva sepa quién habla y hacia dónde girarse. Unos subtítulos que no dicen de dónde vino el sonido están a medio hacer.

El contraste es el criterio que más se falla porque se diseña en un monitor. Las WCAG piden una ratio de contraste de 4,5:1 para texto normal. En un HMD, la ratio medida en el panel y la ratio percibida por el ojo divergen: las disposiciones de subpíxeles pentile, la aberración cromática en los bordes de la lente y el brillo Fresnel se comen el contraste. Nuestra regla es diseñar con un margen cómodo por encima del mínimo de las WCAG — apuntamos a unos 7:1 para el texto corrido — y luego verificar dentro del visor, no en Figma, con el brillo donde lo pondría una clínica o un salón real. También evitamos el blanco puro sobre negro puro, que produce bloom en los paneles OLED y se emborrona con el movimiento.

El audio soporta una carga enorme en VR, y precisamente por eso no puede ser el único canal. Cada señal de audio importante necesita un compañero visual y, cuando el hardware lo permite, uno háptico. Un temporizador que solo pita falla para un usuario sordo; un temporizador que pita, hace pulsar un anillo de luz y vibra el mando funciona para casi todos. El audio espacial es maravilloso para quien ve y oye, y un verdadero obstáculo para otros, así que siempre ofrecemos un interruptor de audio mono / no espacial y nunca bloqueamos el progreso detrás de localizar un sonido.

Operable: con una mano, sentado y sin presión de tiempo

Aquí es donde la VR más diverge de la web, y donde la mayoría de las experiencias "accesibles" excluye a personas en silencio. Los criterios de operabilidad a los que nos obligamos:

• Modo con una mano. Nunca exigir dos mandos a la vez para una acción central. Muchos usuarios tienen una mano útil, o sostienen un bastón, o están en una cama de hospital con una vía en un brazo. Cada interacción a dos manos necesita un equivalente con una mano, aunque sea más lento.
• Paridad entre sentado y de pie. El recentrado y la calibración de altura deben permitir que un usuario sentado alcance todo lo que alcanza uno de pie. Nunca colocamos un objeto obligatorio en el suelo o por encima del alcance natural de alguien de pie. Probad la experiencia entera sentados antes de darla por terminada.
• Sin exigencia de alcance. Los objetos van hacia el usuario, o existe un gesto de "acercar". No obligamos a nadie a estirarse o a acercarse a una pared que no puede ver.
• Sin presión de tiempo. Las WCAG 2.2 tienen toda una directriz sobre Tiempo Suficiente (2.2.1) y se transfiere a la perfección. Todo lo que tenga límite temporal debe poder ampliarse o desactivarse. En contextos médicos y de personas mayores esto es innegociable — un paciente frágil nunca debe perder progreso por haber sido lento.
• Elección de locomoción. Ofrecer teletransporte, suave y giro por incrementos, con el teletransporte por defecto. La locomoción suave es un detonante de cibermareo para una minoría considerable; imponerla es un fallo de accesibilidad, no una opción estilística.
• Objetivos de interacción ajustables. El equivalente en VR al WCAG 2.5.8 (tamaño del objetivo) es el tamaño angular. Los botones deben abarcar un ángulo lo bastante grande para acertarlos de forma fiable con una mano temblorosa o un tracking impreciso. Dimensionamos y espaciamos los elementos interactivos para que un temblor no active el equivocado.

Comprensible y Robusto: confort, previsibilidad y la realidad del hardware

Comprensible, en VR, significa sobre todo previsible. No teletransportar la cámara sin input del usuario. Sin cambios bruscos de campo de visión. Sin destellos — la regla de las WCAG de los tres destellos por segundo (2.3.1) importa más en un visor sujeto a la cara de alguien de lo que importó nunca en un monitor, porque no puede apartar la mirada. La cumplimos a rajatabla y tratamos como un bug cualquier cosa cercana al umbral.

Los ajustes de confort son el capítulo nativo de la VR que las WCAG nunca escribieron, y los tratamos como funciones de accesibilidad, no como opciones. El viñeteado (efecto túnel) durante el movimiento, un suelo de framerate por debajo del cual nos negamos a bajar, la capacidad de reducir o eliminar el movimiento dirigido por la cámara, los incrementos de giro — son la diferencia entre una experiencia que alguien puede terminar y otra de la que se quita el visor a los noventa segundos. Si un ajuste de confort está enterrado tres menús abajo, no existe. Los mostramos en una pantalla de confort de primer arranque, antes de que la experiencia empiece de verdad.

Robusto significa que sigue funcionando en la realidad desordenada de los dispositivos y del contexto asistivo. En la práctica: respetar los ajustes de accesibilidad de la plataforma donde existan, no pelear con el escalado de texto o los filtros de color del sistema, etiquetar los objetos interactivos para que los lectores de pantalla a nivel de plataforma y futuras capas asistivas puedan describirlos, y degradar con elegancia cuando un mando pierde tracking. La robustez en VR significa también robustez física — en despliegues clínicos el hardware se desinfecta entre pacientes y lo manejan personas que no lo construyeron, lo que es una restricción de accesibilidad propia sobre la que hemos escrito aparte.

La versión corta: nuestra checklist de VR accesible

Esta es la lista que ejecutamos antes de publicar cualquier build inmersiva. Es deliberadamente concreta, porque "hazlo accesible" no es una especificación.

1. Hay subtítulos, siguen la cabeza con una zona muerta e indican la dirección de quien habla.
2. Cada señal de audio tiene un compañero visual y, cuando es posible, háptico. Ningún progreso depende solo de oír.
3. Existe un interruptor de audio mono / no espacial.
4. Contraste del texto verificado dentro del visor, apuntando a ~7:1 para texto corrido; sin blanco puro sobre negro puro.
5. Cada acción central tiene una vía con una mano.
6. La experiencia entera se puede completar sentado, con recentrado y calibración de altura completos.
7. Nada exige estirarse, dar pasos o interactuar a nivel del suelo.
8. Sin límites de tiempo no cancelables; los pasos cronometrados se pueden ampliar o desactivar.
9. Locomoción por teletransporte, suave y por incrementos, todas ofrecidas; el teletransporte es el valor por defecto.
10. Los objetivos interactivos son angularmente grandes y están bien espaciados para input impreciso.
11. Los ajustes de confort (viñeta, reducción de movimiento, incrementos de giro, suelo de framerate) viven en una pantalla inicial, no en un menú profundo.
12. Sin movimiento de cámara sin input del usuario; cumplimiento estricto de la regla de los tres destellos.
13. Los objetos interactivos están etiquetados para las capas asistivas de la plataforma; la build degrada con elegancia ante la pérdida de tracking.

Dónde las WCAG genuinamente no llegan

Conviene ser honesto sobre las lagunas, porque fingir que las WCAG cubren del todo la VR es como los equipos publican cosas que pasan una auditoría y siguen excluyendo a personas. No hay una métrica de contraste acordada para HMD. No hay forma estandarizada de exponer un grafo de escena 3D a un lector de pantalla como el DOM expone una página. El cibermareo no tiene ningún criterio WCAG, y es la mayor razón por la que la gente abandona la VR. Y la tolerancia al confort varía tanto entre individuos que la única respuesta robusta son ajustes generosos y fáciles de encontrar, no un umbral único.

Por eso tratamos las WCAG como el suelo y los cuatro principios POUR como la ley, y luego añadimos encima los XAUR y reglas de campo ganadas a pulso. La disciplina que mejor transita desde la web es la mentalidad: diseñar para la persona que no eres tú — el usuario con una mano funcional, el paciente que nunca ha sostenido un mando, la persona que se marea en noventa segundos. Construye para ellos primero y la experiencia mejora para todos, igual que los rebajes de acera y los subtítulos mejoraron la web.

FAQ

¿Se aplican las WCAG a la VR? Sus cuatro principios (POUR) se aplican por completo; la mayoría de los criterios de éxito concretos se escribieron para páginas 2D y necesitan traducción. Usa las WCAG como cimiento y los XR Accessibility User Requirements (XAUR) del W3C como puente inmersivo.

¿Cuál es el cambio de VR accesible con más impacto? Ofrecer locomoción por teletransporte por defecto y un buen conjunto de ajustes de confort. Elimina la mayor barrera — el cibermareo — que ningún criterio WCAG siquiera nombra.

¿Cómo se hacen los subtítulos en VR? Anclándolos a un billboard que sigue la cabeza con una zona muerta para que sigan legibles sin provocar mareo, e indicando de qué dirección vino un sonido o quién habla.