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.
Comments