¿Cuánto tiempo lleva construir una aplicación móvil accesible?

Antes de comenzar, mi nombre es Alessandro Lemsenese y soy un ingeniero de software en Formidable. Comencé a trabajar con accessibility hace unos cuatro años. Mi primer trabajo con React en un televisor involucró la creación de una aplicación accesible para un banco. Comencé a aprender más y más sobre accessibility y nunca dejé de hacerlo desde entonces.

Antes de continuar, recordemos qué estamos tratando de hacer. La accesibilidad es la práctica de hacer que tu aplicación móvil sea utilizable por la mayor cantidad de personas posible. Ese es nuestro objetivo. Queremos asegurarnos de que la mayor cantidad de personas posible puedan usar nuestra aplicación. Así que empecemos.

Ahora, el problema de accessibility a solucionar es en realidad un informe real que recibimos de una excelente compañía, donde resaltaron un problema grave y crítico que tuvimos que solucionar en nuestra aplicación. En mi caso, utilicé React Native Armour para ayudarme con estas correcciones. Y la biblioteca es una biblioteca de React Native que construí después de unirme a Formidable. Contiene un conjunto de componentes y hooks diseñados para cumplir con los requisitos mínimos de accessibility. Lo primero que hice fue instalar la biblioteca con Yard, importar el proveedor proporcionado por la biblioteca y envolverlo alrededor de mi aplicación. Para corregir reglas, etiquetas, estados e indicaciones, reemplacé todas las importaciones de pressable de react-native a react-native-ama. Y una vez que hice eso, obtuve alrededor de 200 errores de typescript o reglas y etiquetas faltantes. Y en esta captura de pantalla puedes ver cómo funciona Ama. Básicamente, Ama realiza algunas comprobaciones en tiempo de ejecución, pero además de la tipificación de typescript, realiza una comprobación en tiempo de ejecución de los problemas comunes de accessibility y, si los encuentra, resalta el componente dentro de la interfaz de usuario y muestra un banner, además de imprimir en la consola cuál de las pruebas de accessibility ha fallado.

En mi caso, tenía alrededor de 200 errores y el gran problema que tuve fue que no podía asumir que todo era un botón. Y debido a que el código que escribí para usar no siempre era sencillo, la opción que tuve fue navegar por la pantalla para solucionar el problema. Lo mismo sucedió con la etiqueta de accessibility. Tuve que asegurarme de que la etiqueta de accessibility fuera clara para el usuario del lector de pantalla y también tuve que verificar si era suficiente porque teníamos algunos casos como el que se muestra en la captura de pantalla donde el botón contenía x información, en este caso 5 mensajes, mensajes no leídos. Así que tuve que comunicar esta información al usuario del lector de pantalla utilizando una indicación accesible. Además, debido a que no había trabajado en todas las partes de la aplicación, no estaba seguro de cuántas pantallas teníamos en realidad, así que la única opción que tuve fue recorrer toda la aplicación por mí mismo y descubrir toda la información que faltaba. Para los encabezados, fue más fácil. Solo asegúrate de que cada pantalla tenga un encabezado y que todo lo que parezca un encabezado se lea y se marque como un encabezado para el lector de pantalla. El formulario, presentó otro problema.

El problema más grande era que el usuario no podía enfocar la etiqueta del formulario y el campo de entrada como dos campos diferentes. La opción requerida no se leía y el mensaje no se leía como parte del campo. Otro problema era que, por defecto, React Native muestra un teclado con la tecla de retorno, pero esa tecla de retorno no hace nada. El comportamiento correcto era permitir al usuario navegar por los campos usando el botón siguiente si es necesario y permitir enviar el formulario con la tecla de retorno.

El último problema era que si se enviaba el formulario y había un error, el primer campo que contenía un error debía recibir el enfoque, esto no estaba sucediendo en nuestro caso. Para solucionar esto, utilicé React Native ARMA, especialmente el campo de formulario es un contenedor que maneja el envío del formulario. Entonces, si en este caso el envío falla, el formulario que contiene una referencia a todos los campos internos intentará enfocar el primer campo que marcamos como que contiene un error. Y también, sí, el formulario en sí se utiliza internamente por el campo de texto y el gancho de campo de texto para averiguar qué botón del teclado mostrar.

Para el campo de texto, tuvimos que compartir los componentes, así que tuve que envolverlos. Tuvimos que usar el gancho de entrada de texto donde se utiliza la referencia para permitir enfocar el campo internamente y ver si el campo no tenía validación, si no tenía errores o los diversos atributos y pasar esas propiedades de vuelta al campo de texto. También tenemos un campo de formulario como una casilla de verificación o un combo, en este caso tuve que envolverlo en el formulario genérico proporcionado por ARMA y este campo es capaz de recibir un enfoque de la pantalla del lector.

Para la hoja inferior, la que estábamos usando no recibía ningún enfoque, el usuario aún podía seleccionar cualquier cosa debajo de la superposición de la propia hoja inferior. Así que tuvimos que reemplazar eso y en este caso utilicé uno incorporado en ARMA que abordó el problema de accesibilidad. Además, este tiene el beneficio de desactivar la animación de deslizamiento si el usuario desactiva la animación en el dispositivo. En el momento de la acción, en este caso, si se agrega un intento a la tarjeta, mostramos un mensaje durante unos segundos y el informe que se suponía que debía comportarse más o menos como una hoja inferior, se suponía que debía recibir el enfoque, permitir al usuario suficiente tiempo para interactuar con él y el usuario no debía poder seleccionar nada, ni enfocar nada debajo. En este caso, utilizamos la hoja inferior proporcionada por React Native ARMA, por lo que agregamos todas las características de enfoque y la característica de enfoque, y la usamos en conjunto con la acción de tiempo de espera. Este gancho básicamente permite activar la función que le damos según el estado del lector de pantalla y el dispositivo, por ejemplo, en iOS, si el lector de pantalla está activado, el tiempo de espera nunca se activa, mientras que en Android utilizamos la configuración de tiempo de espera de la acción del dispositivo.

Entonces, ese fue el problema grave y serio que solucionamos, ¿cuánto tiempo llevó? También agregamos correcciones de errores, porque durante el proceso tuvimos que reemplazar algunas bibliotecas con otras que eran accesibles. Así que introdujimos algunos errores, algunos de los cuales no éramos conscientes, porque, por ejemplo, la hoja inferior utiliza modelos, pero React Native en este momento no admite la apertura de múltiples modelos a menos que estén anidados, por lo que también tuvimos que cambiar un poco la lógica en torno a eso para que funcione en la aplicación. Y todo el proceso llevó más de 5 semanas para solucionar. Así que construyamos una aplicación accesible como ciudadano de primera clase. ¿Cómo lo hacemos? ¿Cómo podemos asegurarnos de que nuestra aplicación sea accesible desde el primer día? La solución es fácil, podemos construir componentes compartidos que sean accesibles por defecto. Entonces, dondequiera que tengamos botones con diferentes estados, con diferentes indicaciones, simplemente creamos uno o varios componentes compartidos que manejen todas las propiedades requeridas que necesitamos. Lo mismo podemos hacer para un encabezado, lo mismo podemos hacer para formularios, simplemente nos aseguramos de que los campos ya sean accesibles. Hoja inferior, superposición si es necesario y carrusel, en nuestro caso agregamos un carrusel, tuvimos que hacerlo accesible. Entonces, cualquier componente que realmente necesitemos en nuestra aplicación, podemos crearlo una vez y hacerlo accesible. Lo que vamos a usar ya es accesible por defecto. Necesitamos un poco, solo un poco de tiempo extra para asegurarnos de que todo funcione. Porque ser accesible de forma predeterminada no significa que su aplicación vaya a ser completamente accesible, hay algunas verificaciones que deben hacerse manualmente que no podemos automatizar. Por ejemplo, aún debemos asegurarnos de que cualquier función que construyamos se pueda hacer con el lector de pantalla.

El usuario de lectores de pantalla puede realizar esa función. Además, el enfoque es muy importante. Debemos asegurarnos de que los elementos se enfoquen en el orden correcto. Si se necesita un orden específico por alguna razón, también debemos asegurarnos de que los usuarios de lectores de pantalla puedan realizar ese orden.

Los cambios en la interfaz de usuario se anuncian. Si como consecuencia de alguna acción del usuario actualizamos la interfaz de usuario o mostramos elementos de notificación, debemos asegurarnos de que esa información se proporcione al usuario de lectores de pantalla. Podemos hacer que se anuncie utilizando una de las API de accesibilidad proporcionadas por React Native. Por ejemplo, si aparecen elementos, como errores después de que falle una API, debemos asegurarnos de que ese elemento obtenga el enfoque y sea anunciado por el usuario de lectores de pantalla.

Una cosa muy importante es asegurarnos de que el comportamiento y la apariencia sean consistentes en toda la aplicación. La aplicación debe ser predecible. Si tenemos un botón de Bluetooth, por ejemplo, deben verse iguales. Otra cosa importante a tener en cuenta es el contenido agrupado, si es necesario. A veces esto puede formar parte del componente compartido que creamos, pero debemos verificarlo cada vez. Debemos asegurarnos de que esté bien. En nuestro caso, tenemos un contexto donde tenemos un título, un encabezado, el texto y el autor, y un botón. La cita del día, que es un encabezado, puede tener un enfoque por separado, eso está bien, pero la cita, en nuestro caso una cita de Walt Disney, el texto y el autor deben enfocarse como una sola cosa. Para hacer eso, generalmente podemos envolver los múltiples textos en una vista accesible. Esto obligará al lector de pantalla a leer el texto como uno solo. Este es otro ejemplo de nuestra aplicación, donde tenemos un SUBTOTAL y $20, queremos asegurarnos de que el usuario seleccione la fila SUBTOTAL $20 y lo lea como uno solo. No queremos que el usuario seleccione primero SUBTOTAL y luego $20. Entonces, cada vez que tengamos información relacionada que deba leerse en conjunto, asegurémonos de que así sea.

Aquí hay una pequeña tabla de las desventajas de eliminar la accesibilidad o construir una aplicación accesible desde cero. Si eliminas la accesibilidad, no obtienes ningún beneficio. A pesar de los esfuerzos que tuve que hacer, eliminar la accesibilidad en realidad es muy costoso y requiere un gran esfuerzo. El tiempo necesario para abordar problemas de accesibilidad depende del tamaño de tu aplicación, cuanto más grande, peor. Para encontrar problemas y solucionarlos, debes navegar por toda la aplicación. No puedes simplemente mirar el código y adivinar cómo funcionará. Además, no olvides que todas las verificaciones deben realizarse en ambas plataformas, iOS y Android. Esto significa trabajo duplicado y existe el riesgo de introducir errores.

Esto puede suceder si necesitas reemplazar una biblioteca por otra, o si necesitas modificar la lógica para hacerla accesible. Sin embargo, si comienzas con accesibilidad, requiere cierto esfuerzo hacer que un componente sea accesible, pero solo lo haces una vez. Solo lo haces accesible cuando lo creas. Claro, el componente ya manejará la mayoría de las necesidades de accessibility. Eventualmente, solo necesitas unirlo. Cuando haces una prueba, porque aún necesitas probar, solo pruebas lo que estás construyendo realmente. No necesitas probar toda la aplicación desde cero todo el tiempo. Solo pruebas lo que construyes. La accesibilidad es costosa y consume tiempo solo si la pospones. Esa es la realidad. Si la ignoramos, si sabemos que nuestra aplicación debe ser accesible y la ignoramos, solo nos haremos daño a nosotros mismos, probablemente de manera grave, al final. Dejé algunas referencias si deseas obtener más información sobre el React Native Ama y varias pautas a las que puedes consultar para saber cómo construir una aplicación móvil accesible. Eso es todo de mi parte. ¡Muchas gracias!