Desarrollar la ceguera y la baja visión en VR con Cosmonious High
En este artículo, Jazmín Cano, jefa de producto de accesibilidad II de Owlchemy Labs, explica cómo el equipo utilizó Unity para desarrollar una nueva actualización de accesibilidad visual para Cosmonious High en realidad virtual (VR).
En Owlchemy Labs, hemos incluido en nuestra Declaración de Accesibilidad el objetivo de crear juegos de RV para todo el mundo. Históricamente, nuestro equipo ha dado prioridad a realizar avances significativos en áreas no resueltas de la accesibilidad en VR, como los subtítulos, la accesibilidad física y la accesibilidad en altura. Animamos a todos los desarrolladores a crear teniendo en cuenta la accesibilidad, e incorporamos activamente la accesibilidad a nuestros juegos en el lanzamiento y mediante actualizaciones posteriores.
En nuestra última actualización de accesibilidad de Cosmonious High, añadimos una serie de opciones de juego, como el modo de mando con una mano, el modo de jugador sentado, subtítulos y mucho más. Si un juego sólo puede ser jugado por un público sin discapacidades, es señal de un producto inacabado. Nos enorgullece forjar nuevos caminos a través de la investigación, las pruebas y las asociaciones para garantizar que los juegos estén al alcance del público más amplio posible.
Cuando empezamos a investigar sobre el desarrollo para jugadores ciegos o con baja visión, descubrimos que el principal problema era la incapacidad de seguir una historia o las instrucciones del juego.
A menudo, no hay un subtexto disponible para todas las escenas de un juego, y se utilizan diferentes escenas para hacer avanzar la historia. Un argumento puede ser complejo y difícil de seguir sin contexto o subtexto. Otros aspectos de un juego, como completar un rompecabezas o una tarea, se vuelven difíciles cuando no todas las piezas son claramente visibles para los jugadores o cuando se dan pistas vitales sin ningún texto o cola visual.
A partir de nuestra investigación, descubrimos que era importante crear una forma de que los jugadores recibieran la información del juego a través de descripciones de audio mediante Text To Speech (TTS). La mayoría de las personas ciegas o con baja visión utilizan una tecnología de apoyo llamada lectores de pantalla, que les permite navegar por las pantallas con un teclado, y su ordenador o teléfono leerá en voz alta el texto. Las características de nuestros juegos son similares en el sentido de que permiten a los jugadores navegar por espacios virtuales utilizando las manos o un joystick como métodos de lectura de objetos y descripciones. Todas las funciones están diseñadas para cumplir las expectativas relativas a los estándares de los lectores de pantalla, como evitar el audio no TTS y permitir al usuario cancelar el TTS a mitad de la descripción.
Hasta ahora no habíamos visto narración o TTS en otros juegos de VR, así que sabíamos que lanzar nuestro enfoque de accesibilidad en este ámbito, tras investigar las mejores prácticas y realizar pruebas con personas legalmente ciegas o con baja visión, beneficiaría al sector.
Desarrollar para jugadores ciegos o con baja visión no consiste sólo en añadir pistas de audio y opciones. La ceguera es un espectro, y crear un modo de juego que incluya plenamente a los jugadores ciegos y con baja visión también incluye sentir y ver.
Para lograrlo, desarrollamos más retroalimentación háptica como método para identificar un objeto cuando un jugador lo resalta. Esto es especialmente importante cuando un jugador está completando un puzzle. Los jugadores pueden identificar un objeto y palparlo cuando lo han seleccionado.
También hemos añadido el resaltado de objetos de alto contraste, que perfila los objetos clave del entorno, facilitando a los jugadores la visión del objeto y la comprensión de su selección con retroalimentación háptica.
Para unir todo esto, incorporamos una confirmación de Agarrar y Soltar. De este modo, los jugadores recibirán una respuesta táctil al resaltar un objeto que se muestra mediante un resaltado de objetos de alto contraste, y se reproducirá audio para informarles de cuándo se ha agarrado y soltado un objeto.
Cuando empezamos a desarrollar esta actualización, previmos algunos retos, desde decisiones de diseño hasta pruebas de juego. Afortunadamente, tuvimos un gran comienzo en el proyecto tras reunirnos con Steve Saylor, un consultor de accesibilidad de videojuegos que es ciego. Consultando con Steve, pudimos identificar las características que necesitaríamos y qué expectativas tendría alguien con baja visión. Hicimos muchas investigaciones, experimentos y pruebas para determinar qué funcionaba mejor y qué podíamos ejecutar con éxito.
Para la actualización de la accesibilidad visual, sabíamos que teníamos que diversificarnos a la hora de encontrar probadores con baja visión que nos aportaran valiosos comentarios y nos ayudaran con el diseño. Nos asociamos con VROxygen para encontrar un grupo de probadores con ceguera y baja visión que nos dieran su opinión sobre nuestras iteraciones y nos ayudaran a priorizar las mejoras que necesitábamos hacer, lo que funcionó muy bien. Abrir las pruebas a jugadores remotos de cualquier parte del mundo nos permitió obtener un amplio abanico de perspectivas sobre el proyecto, con comentarios procedentes de personas con distintos niveles de visión.
El camino hacia la creación de esta actualización ofreció algunos retos a tener en cuenta. A veces, lo que parece la respuesta más obvia no siempre es la mejor, especialmente cuando se desarrolla para la accesibilidad. Hemos dedicado mucho tiempo a cada aspecto de esta actualización para asegurarnos de que las funciones que añadíamos funcionaban bien para quienes más las necesitaban.
Cuando activamos el TTS al principio del proyecto, empezamos con la narración automática. Esto significaba que cualquier objeto sobre el que se movieran las manos de un jugador sería descrito, incluso si eso significaba hablar encima de una descripción anterior que todavía pudiera estar en marcha. Para que las audiodescripciones sean valiosas, tienen que oírse sin que otro audio luche por la prioridad.
Esto dio lugar a algunos cambios que funcionaron bien en las pruebas de juego. Por ejemplo, decidimos añadir la pulsación de un botón para activar las descripciones en lugar de que se leyeran automáticamente, lo que dio lugar a una experiencia más cómoda. De este modo, los jugadores pueden decidir si se les lee una descripción cuando colocan la mano sobre un objeto o señalan algo en la distancia. También evita que se produzcan TTS accidentales si un jugador mueve la mano sobre objetos que no tenía intención de leer.
Mientras que el TTS describe el nombre del objeto y una descripción visual, no lleva mucho tiempo. Pero incluso con descripciones cortas, sabemos que la gente querría un comportamiento similar al de un lector de pantalla (es decir, la posibilidad de cancelar el audio mientras se lee).
Otra cosa que aprendimos con respecto al audio es la importancia de bajarlo para que el volumen más bajo permita que las descripciones de audio TTS tengan prioridad. Nos encontramos con un problema en el que el TTS puede activarse durante una interacción con un PNJ, haciendo que el diálogo del PNJ sea más silencioso y fácil de pasar por alto. En este momento, los jugadores no pueden "rebobinar" o "volver a activar" el mismo audio para que se reproduzca; sin embargo, los jugadores pueden agitar las manos y los PNJ responderán para ayudar.
Pero una de las partes más difíciles de crear funciones como éstas es asegurarse de que realmente ayudarán a los usuarios que las necesitan. La mejor forma de determinar la utilidad de las nuevas funciones de accesibilidad es mediante pruebas. Por supuesto, poder crear rápidamente nuevas versiones para todas nuestras plataformas después de cada ronda de comentarios y desarrollo fue esencial para que esta actualización fuera la mejor posible. Una herramienta poco probable que encontramos útil para la iteración rápida en nuestros diseños fue la Pila de Post Processing de Unity.
Antes de enviar las versiones a los jugadores, nuestros desarrolladores querían comprobar internamente la eficacia de las funciones. Como muchos de nuestros desarrolladores son videntes, utilizamos la pila de Post Processing y creamos entradas en nuestro menú de depuración que nos permitían modificar la claridad visual de lo que veíamos en los auriculares. Esto ayudó a nuestros desarrolladores a simular aproximadamente cómo es tener distintos niveles de visión reducida mientras se juega. Como ahora podíamos identificar y resolver rápidamente los problemas más obvios, podíamos iterar sobre los diseños con mayor rapidez y asegurarnos de que sacábamos el máximo partido de las sesiones de pruebas de juego externas con probadores ciegos y con baja visión.
En el desarrollo de esta actualización, hemos aprendido buenas prácticas de diseño para la accesibilidad de invidentes y personas con baja visión que utilizaremos en futuros juegos. Uno de esos aprendizajes procede de un planteamiento que comenzó mucho antes de esta actualización.
Nuestros desarrolladores crean pensando en la accesibilidad, y hemos aprendido con cada actualización de accesibilidad que empezar un proyecto con este enfoque facilita mucho el desarrollo de futuras funciones accesibles. Por ejemplo, asegurarse de que los objetos tengan nombres y descripciones adecuados que sean útiles como texto alternativo en las imágenes requiere menos esfuerzo y ahorra tiempo.
Disponer de objetos grandes y texto de gran tamaño con un buen contraste facilita la visión y la lectura de gran parte del mundo de un juego de VR. Muchos jugadores que describían su visión como muy borrosa podían inclinarse y leer gran parte del texto del juego. Los jugadores que no pudieran distinguir bien el texto utilizarían el botón de ayuda para oír las palabras que necesitaran.
El texto en Cosmonious High es estacionario, por lo que los jugadores no tienen que preocuparse de que esté a una distancia fija de su cara, alejándose de ellos a medida que siguen inclinándose hacia delante. Un jugador comentó que hicimos el juego accesible antes incluso de pensar en la accesibilidad visual, ya que describió el tamaño y los colores del mundo no específicos de esta actualización. Aunque agradecemos el cumplido, la práctica de diseño de hacer las cosas más grandes y fáciles de distinguir forma parte de nuestro proceso de desarrollo: está en nuestra documentación para desarrolladores.
En el caso concreto de esta actualización, permitir que los jugadores decidan cuándo recibir descripciones sonoras, que cancelen el audio y que las descripciones sean breves y contengan información valiosa es fundamental para dar autonomía a los jugadores.
El desarrollo para jugadores ciegos y con baja visión ha aumentado nuestro arsenal de herramientas de desarrollo. Esperamos aprovechar lo aprendido en todos los ámbitos de la accesibilidad y planeamos lanzar futuros títulos con más accesibilidad incluida. Estamos encantados de compartir esta actualización de Cosmonious High como continuación de nuestra misión de hacer VR para todos.
Owlchemy Labs' Cosmonious High está disponible en múltiples plataformas. Consulta más blogs de desarrolladores de Made with Unity aquí.
