Pruebas de Accesibilidad Automatizadas en React: Más Allá de lo Básico

Hola a todos. Vamos a profundizar en las pruebas de accesibilidad en relación con las aplicaciones React. Así que, primero que nada, permítanme presentarme. Mi nombre es Vinicius Neves. Pueden llamarme Vinny si quieren. He sido líder técnico en S2 y también enseño en una universidad brasileña llamada FIAP. Así que, hablemos del razonamiento. ¿Por qué deberíamos automatizar la accesibilidad en las primeras etapas del proyecto? Primero que nada, los errores encontrados tarde cuestan más. Necesitamos más tiempo para arreglar esto. Así que, tan pronto como detectamos errores, es más barato solucionarlos.

Las pruebas manuales no escalan. Así que, si nuestra aplicación crece, la prueba de regresión debe estar ahí para ayudarnos a asegurarnos de que todo esté bien. Y además, este tipo de automatización capturará el 55% de estos problemas. Así que nos ayudará a detectar este tipo de problemas. Como, estoy hablando específicamente de problemas de accesibilidad. Así que nos ayudará en eso. Y también, como, en la regresión, asegurándonos de que no rompimos nada.

Entonces, ¿qué se puede automatizar? La accesibilidad va mucho más allá de dar a las imágenes un texto alternativo. Pero, ¿qué hacemos? ¿Qué podemos automatizar? Como, entonces, todos estos atributos, así, outs y etiquetas. Primero que nada, el área, como, el área de camino, nos ayuda mucho a hacer nuestras aplicaciones accesibles. Pero el uso incorrecto de esto romperá las cosas en lugar de arreglarlas. Así que también podemos, como, detectar este uso incorrecto del área. Y también, el contraste en la semántica. Así que esto es, como, lo que podemos usar la automatización para ayudarnos. Y así, hablemos de estos niveles, como, estas capas. Lo que voy a mostrarles a continuación es, como, linting.

Así que obtenemos, como, mientras desarrollamos cosas, obtenemos, como, retroalimentación instantánea del IDE o editor de código que estás usando. Unity test, como, podemos usar, como, para asegurarnos de que no rompimos nada. Así que nos ayuda, como, a asegurarnos de que toda nuestra base de código siga siendo, como, accesible. Las pruebas de entrada capturarán, como, problemas de niveles completos, para que podamos centrarnos en las partes más importantes de la aplicación. Y también CI para reforzar la consistencia, ¿verdad? Pero hablar es barato, así que vamos a mostrar algo de código.

Así que, comencemos, como, con el análisis estético del código. Así que, hablemos del linter. Así que, un linter para gobernarlos a todos. Lo que traigo aquí es solo, como, un plugin específico para accesibilidad. Es fácil, como, de instalar. Podemos instalarlo, como, una dependencia de desarrollo y solo, como, necesitamos configurarlo. Así que, tengo aquí un ejemplo de s-lint config.js. Y luego estoy mostrando, como, lo que necesitamos hacer. Así que, solo estamos, como, importándolos. Los estamos declarando como un plugin y también agregando reglas. Así que esto nos ayuda a detectar este tipo de cosas.

Como, tenemos un input con, como, un div clicable y esta regla, este lint puede ayudarnos a identificar que un div no debería ser clicable. Y si necesitamos hacer esto por alguna razón, hay algunas maneras en que puede ayudarnos a solucionar eso. Pero esto es solo, como, para decirte que un lint puede ayudarnos a prevenir este tipo de situación. Así que, tenemos, como, podríamos, como, cambiar este div a un elemento más accesible, elemento nativo, como un botón, o aplicar Whey Area si es necesario. Pero lo que estoy mostrando aquí es que podemos detectar esto mientras desarrollamos cosas. Así que, en la etapa muy temprana del proyecto. Pero no me detendré aquí.

Hablemos de más pruebas, como, una prueba para encontrarlas. Entonces, ¿qué, cómo podemos usar las pruebas de extremo a extremo para ayudarnos con la accesibilidad? Entonces, hay una biblioteca llamada Jest-Axi. Entonces, podemos, como, extender. Para este ejemplo, estoy usando Vitest, pero podemos usar, como, Jest o lo que quieras. Pero solo estoy, como, extendiendo el esperado para tener este método específico, solo, como, para no tener violaciones. Entonces, si piensas en los componentes de entrada que te he mostrado, podemos hacer, como, una prueba simple que solo renderiza los componentes. Y estamos esperando que los resultados no tengan violaciones. Y cuando hablamos de violaciones, estamos hablando de reglas de accesibilidad, como reglas de accesibilidad bien conocidas. Entonces, esto no agrega más esfuerzo. Solo, como, una prueba simple que podemos usar y podemos escribir para evitar tener este tipo de problema de accesibilidad.

Pero hay más. Entonces, una prueba para traerlos a todos. Entonces, de lo que estamos hablando ahora es de accesibilidad, ¿verdad? Y pruebas de extremo a extremo. Entonces, podemos usar algo como Cypress para ayudarnos a identificar este tipo de problema también. Entonces, si prestas atención al código que estoy compartiendo, solo estoy, como, configurando una prueba. Entonces, antes de cada uno, solo estoy haciendo, como, una línea simple que es CI dot inject x. Entonces, tenemos esta biblioteca disponible para ser utilizada durante, como, nuestras pruebas. Y lo que podemos hacer, podemos simplemente, como, ejecutar lo que necesitemos. Entonces, en este caso, no debería tener violaciones. Entonces, todavía estamos hablando de violaciones de accesibilidad. Pero en este caso, nos estamos enfocando en elementos de formulario. Entonces, solo estamos, como, obteniendo una entrada, enfocándonos en la entrada. Y luego verificar la accesibilidad. Y luego, como, cambiando el enfoque a otra entrada y verificando nuevamente. Entonces, esto nos ayudará, como, a asegurarnos de que no rompimos o añadimos un problema específico de accesibilidad. ¿Verdad? Y, por supuesto, pruebas impulsadas por CI.

Entonces, el pipeline para unirlos. Entonces, lo que traje aquí es solo, como, una acción de GitHub de lighthouse. Entonces, es fácil, como, de configurar.

Y luego, al ejecutar esto, como, en PRs, en la rama principal, como, una vez que el PR se fusiona, también estamos, como, obteniendo retroalimentación sobre accesibilidad. Entonces, este tipo de cosas, como, todas estas herramientas que te he mostrado, es solo, como, para ayudarnos a asegurarnos de que no estamos rompiendo las reglas de accesibilidad. Y luego, es este tipo de cosas, como, puede ayudarnos a hacer que nuestra aplicación sea, como, a prueba de futuro.

Entonces, podemos evolucionarla sin, como, pensar en la regresión. Pero una cosa que me gustaría destacar, es que esto no es un sustituto para las pruebas manuales. Cuando hablamos de accesibilidad, necesitamos que las personas prueben, prueben, como, fiestas de prueba, y este tipo de cosas. Entonces, estas herramientas adicionales solo, como, te ayudarán a mantener tu proyecto accesible y te darán más confianza, como, mientras desarrollas aplicaciones web.

Entonces, si tienes preguntas o si quieres hablar sobre algo, solo contáctame en LinkedIn. Estaré feliz de compartir. Fue un placer compartir este tiempo contigo, y nos vemos la próxima vez. Adiós.