Accesibilidad en productos digitales
Un caso que muestra que nunca es demasiado tarde para comenzar
Un producto con más de 10 años en el mercado recibe quejas sobre accesibilidad. ¿Y qué hacer ahora? Parece difícil saber por dónde comenzar en tal situación, pero simplemente escuchando al usuario y uniendo fuerzas de desarrollo y diseño, logramos mejorar mucho el escenario. En esta publicación, contaremos esta historia.
¿Cúal es el producto?
Un juego de fantasía deportiva, lanzado en 2005, con usuarios apasionados y muy críticos también. La retroalimentación en las redes sociales, en las tiendas de aplicaciones e incluso en persona es muy común. La aplicación está disponible para Android, iOS y la web, con usuarios de Android que representan el 80% de la base. Tiene versión gratuita y de pago y 6 millones de usuarios activos.
¿Cómo surgió la necesidad?
Entre los diversos comentarios que recibió el producto, uno que llegó a través del centro de atención al cliente llamó la atención: la accesibilidad de la aplicación dejaba mucho que desear.
Cuando el equipo de desarrollo recibió esta noticia, intentamos entender cómo funcionaba la accesibilidad tanto para iOS como para Android. Probamos los lectores de pantalla para cada plataforma en nuestros propios dispositivos, estudiamos cómo se necesitaba el desarrollo y cómo organizar el diseño, estructuramos un documento que asignaba los componentes de la pantalla y el texto a leer … incluso seleccionamos una función de aplicación para implementamos un piloto, pero no llegamos muy lejos por nuestra cuenta. ¡Necesitábamos un usuario real para que nos mostrara sus verdaderos dolores!
Conociendo el problema con el usuario
En esta búsqueda de ayuda, nos encontramos con “Rodrigo” (nombre ficticio). Es un jugador experimentado, participó en grupos de WhatsApp dedicados al juego y, lo más importante para nosotros, tiene una discapacidad visual y estaba muy entusiasmado por poder contribuir con el producto. Pasamos quince días manteniéndonos en contacto por mensajes, hasta que configuramos una prueba. Rodrigo estaba nervioso y no quería un gran evento, así que mantuvimos una conversación informal dentro de Concrete, con el equipo de desarrollo, solo para poder hacer lo que tanto deseaba: ser escuchado.
El día de la prueba, cuando llegó Rodrigo, intentamos romper el hielo presentando al equipo, pero pronto sacó su teléfono celular y comenzó a mostrarnos cómo interactuaba con la aplicación. Lo primero que notamos fue que su velocidad era impresionante. Además, mantuvo la velocidad de la voz de TalkBack también, lo que para el resto de nosotros era casi imposible de entender. Estuvo dos horas mostrando su navegación diaria, señalando errores muy serios en la accesibilidad y brindando posibles soluciones, desde sugerencias de aplicaciones que eran buenas en accesibilidad hasta formas de hacer que la pantalla sea más descriptiva para los lectores de pantalla.
Uno de los momentos más interesantes de la prueba fue cuando Rodrigo navegó por la pantalla donde aplicamos el “piloto de accesibilidad”. No le dijimos que habíamos implementado esta prueba allí, solo lo vimos. Estaba completamente entusiasmada, pensando que sería una de las áreas menos problemáticas, pero terminé rompiendo mi rostro. De hecho, las quejas eran casi nulas, pero había un problema muy obvio: el texto que preparé para cierto componente estaba interrumpiendo el ritmo de navegación. Todo se explicó demasiado, lo que hizo que Rodrigo tardaba más en llegar a la información que realmente importaba. Incluso nos dijo que usaba aplicaciones pirateadas para realizar ciertas tareas, ya que en la aplicación oficial era casi imposible.
La prueba estaba llegando al final, pero aún parecía que teníamos mucho que aprender. Por lo tanto, propusimos mantener un canal de contacto con Rodrigo. Creamos un grupo en WhatsApp con él y las personas directamente relacionadas con la implementación de la accesibilidad. Se acordó que lanzaríamos versiones beta para recibir críticas y sugerencias de él. También nos dio comentarios de amigos con discapacidad visual que jugaban con él.
Aplicando soluciones
Después de la prueba, entendimos mucho mejor cómo se “consumió” realmente la accesibilidad. Sin embargo, todavía teníamos un gran desafío: un gran producto para arreglar, lo que hacía muy difícil saber por dónde empezar. Fue en este punto que tomamos algunas decisiones:
- Definir los criterios de accesibilidad;
- Incluye estos criterios en la definición de listo;
- Como Android representaba el 80% de la base de usuarios, fue el canal que elegimos atacar primero;
- Las nuevas funciones tenían que ser accesibles desde el principio;
- Gradualmente revuelva el legado para que todo sea accesible;
- Con los comentarios de Android, evolucione la accesibilidad a iOS.
Comenzando por definir los criterios de accesibilidad, decidimos comenzar a etiquetar botones y describir los componentes necesarios. Ese fue el mínimo para cubrir la accesibilidad por falta de visión.
Yo, como designer, tuve que acordar con los desarrolladores un formato de documento para accesibilidad, para que entendieran lo que debería implementarse. El documento que hicimos antes de la prueba, utilizado para implementar el “piloto de accesibilidad” no estaba del todo mal, así que lo reutilicé mucho. Consiste en asignar títulos a los botones, determinar el orden en que se leen los elementos en la pantalla y describir textos para los componentes que necesitan. Estos textos están estructurados de la siguiente manera:
- Textos fijos, que no dependen de la API para existir;
- Textos variables, que cambian según lo que ofrece la API.
Documento de ejemplo que especifica el orden de lectura de la pantalla y la descripción del componente
Todo lo que se desarrolló nuevamente en Android recibió un documento de este tipo, y solo se consideró listo cuando se implementó todo lo especificado en el documento. Además, se hicieron documentos para características antiguas, que deberían implementarse eventualmente.
Recolectando los resultados
Mientras nos manteníamos en contacto con Rodrigo, cada vez que el equipo desarrollaba algo con accesibilidad incluida, enviamos una versión beta y evolucionamos de acuerdo con los comentarios que nos dio, para que pudiéramos lanzar versiones en la tienda. Rodrigo nos ayudó señalando qué partes de la aplicación tenían más problemas y nos ayudó a comprender si nuestras soluciones tenían sentido.
Aprendizaje
Como Concrete es una consultora, eventualmente terminé cambiando de proyecto. Pero esa experiencia se quedó conmigo y cambió mi forma de trabajar, comenzando a pensar más sobre el papel del diseño y la tecnología en la inclusión social.
Empecé a trabajar en un producto con un público muy diferente al anterior. Sin embargo, desde el principio, levanté el estándar de la accesibilidad. En este nuevo proyecto comencé con una ventaja: ¡el producto se hizo desde cero! Este hecho lo hizo mucho más fácil, porque además de no tener una preocupación con el legado, ya era posible crear criterios de accesibilidad e incluirlo en la definición de listo.
- El primer paso fue determinar los tipos de accesibilidad que abordaríamos:
- Falta de visión
- Visión reducida
- Daltonismo (todos los tipos)
2. Decidir acciones para abordar cada uno de los tipos de accesibilidad elegidos, por ejemplo:
Falta de visión:
Todas las pantallas dibujadas deben tener la misma plantilla de documento que el proyecto anterior, especificando títulos de botones y textos de componentes para que los lectores de pantalla los interpreten.
Visión reducida:
Los sistemas operativos (Android e iOS) escalan sus fuentes de forma nativa, lo que permite al usuario elegir qué tamaño desea que aparezcan las letras en su pantalla. Sin embargo, en iOS, si no utilizamos la fuente nativa en el desarrollo de la aplicación, es necesario componer las fuentes para continuar permitiendo esta escalabilidad. Entonces, en la guía de estilo de diseño, todas las fuentes están compuestas para que los desarrolladores puedan aplicarlas correctamente.
Daltonismo:
existen tres tipos de daltonismo: acromático, dicromático y tricromático, según la ubicación del defecto visual o los colores que el individuo no puede identificar. Para garantizar la accesibilidad, en este caso, debemos preocuparnos por el contraste. Todas las pantallas dibujadas, todos los estados de error, absolutamente todo pasa por un filtro que simula estos tres tipos de condiciones, solo para verificar si toda la información es legible.
3. Basado en estos tres tipos de accesibilidad y acciones, escribí un documento con las “pautas de accesibilidad” del proyecto con el equipo. Un pequeño conjunto de reglas para que todo el equipo mantenga el producto incluido:
Conclusiones
Esta fue mi experiencia, algo problemática con la accesibilidad, pero me enseñó mucho y me ayudó a llevar este conocimiento a otros productos y a pensar en más formas de hacerlos accesibles. Espero que esta historia te haya ayudado a inspirarte para hacer que el mundo sea un poco más inclusivo :) ¿Tienes alguna pregunta o algo para colaborar? Disfruta y deja un comentario.
¿Quieres ser parte de este tipo de descubrimiento con alguno de nuestros equipos? Vamos a aprender juntos. Accede aquí y revisa nuestras vacantes abiertas .
¡Hasta la próxima!
“Gracias por preocuparse por nosotros”
Comentarios de Rodrigo
