Automatización de las Pruebas de Accesibilidad para Tu Biblioteca de Componentes

Hola, hoy hablaremos sobre la automatización de las pruebas de accessibility para su component library. Así que vamos a ver las diferentes cosas que vamos a cubrir hoy, la accesibilidad web y su cómo medir la accesibilidad web, cuándo considerar la accessibility, Storybook y su papel en la accesibilidad web, cómo incluir la accessibility en su component library, y luego vamos a comparar el complemento de accesibilidad con Lighthouse y luego hacer un benchmark y luego ver cuál es mejor que el otro. Bien, ¿qué es la accesibilidad web? Construir sitios web que puedan ser utilizados por todos. Esa es una definición simple de ello. Así que eso significa que si yo puedo hacer, si yo puedo usar algo en la web, la persona que está sentada a mi lado debería poder hacer las mismas cosas que yo puedo hacer en la web. Así que para que esto ocurra, debes asegurarte de que has garantizado la legibilidad y la usabilidad para las tecnologías de asistencia como los lectores de pantalla, te has asegurado de que tu aplicación web puede ser navegada a través de controles de teclado. Así que estos son algunas de las cosas importantes para asegurarte de que tu aplicación es accesible.

Ahora, ¿por qué la accesibilidad web? Normalmente la gente piensa en la accessibility como algo bueno para tener pero hoy voy a decirte por qué no es sólo algo bueno para tener sino algo que debes tener. En primer lugar, más clientes. Así que esto es como una de las cosas más importantes porque alrededor del 15% de la población mundial tiene algún tipo de discapacidad. Así que esto te da la oportunidad de llegar al 15% que tu competencia no está considerando. Pero esto establece una diferenciación de la competencia y definitivamente te ayuda a atraer a más clientes. En segundo lugar, el cumplimiento y la legislación. Así que hoy, como te dije, la accessibility se ha convertido en algo que debes tener y muchos países ya han declarado la accessibility como algo que debes cumplir. Si no eres accesible entonces puedes terminar pagando multas enormes. Así que para evitar penalizaciones y multas enormes, debes asegurarte de que estás cumpliendo con lo que depende de tu región. En tercer lugar y lo más importante son los beneficios del SEO. Normalmente la gente piensa que el SEO es algo que tiene que ver sólo con tu contenido pero con la accessibility, ¿verdad? La mayoría de los motores de búsqueda hoy en día están optimizando para sitios web accesibles. Así que si tu sitio web es accesible, la probabilidad de que te clasifiques más alto en los resultados de búsqueda es realmente alta. Así que debes asegurarte de que si estás buscando SEO, no es sólo tu contenido el que está presente en un sitio web sino también la naturaleza accesible de un sitio web que es muy importante para tu SEO. Y finalmente, la usabilidad mejorada. La accessibility no sólo ayuda a las personas con discapacidades sino también a las personas sin discapacidades. Por ejemplo, una persona que vive en una aldea remota o alguien que es mayor y no puede usar el sitio web podrá beneficiarse de la naturaleza accesible del sitio web. Entonces, ¿cómo medir la accessibility? Perceptibilidad. Asegurarse de que la información presentada es fácil de percibir y entender. Y en segundo lugar, la operabilidad. Esto asegura que puedes navegar e interactuar fácilmente. Así que no importa quién venga a tu sitio web, verdad, son capaces de navegar e interactuar a través de tu sitio web. Luego, la comprensibilidad. Esto es asegurarse

Ahora hoy, les presentaré una herramienta llamada Storybook, con la que muchos de ustedes ya deben estar familiarizados. Así que Storybook es una herramienta de open-source que te ayuda a documentar, ver y probar componentes de forma aislada. ¿Por qué Storybook? Porque Storybook te ayuda con el desarrollo orientado a componentes. Hoy en día, cualquiera que esté haciendo desarrollo orientado a componentes, ¿verdad? Usa Storybook. Primero veremos, ¿por qué Storybook, ¿verdad? Desarrollo aislado. Hoy en día, no quieres mantener tus componentes... las pruebas asociadas con los componentes y las diversas cosas que quieres hacer con tus componentes en tu carpeta de aplicación. Así que la forma más fácil de hacerlo es con Storybook, de alguna manera lo aíslas. Llevas todos tus componentes a un entorno diferente. Y luego pruebas tus componentes allí. Ves si tus componentes son compatibles para vistas móviles, tabletas y diferentes cosas. También pruebas muchas otras cosas. Así que separar esto, ¿verdad?, definitivamente te ayudará a mejorar tu eficiencia y limpieza

Entonces, las historias no son más que básicamente declarar todas las posibles variaciones de un componente. Entonces, ¿ por qué es importante escribir historias? Entonces veámoslo así, ¿verdad? Digamos, hoy estás construyendo una aplicación React y en React todo es un componente, básicamente un solo componente o diferentes componentes que están integrados juntos y estos componentes pueden renderizarse en base a condiciones o cambios de estado. Al final del día, todo es un componente. Solo decides qué renderizar, qué no renderizar.

Entonces, si estás construyendo tu component library, y si estás tratando de hacerlo accesible, tendrás que asegurarte de que pruebas la accessibility para todas las variaciones de un componente. Pero por eso es importante escribir todas las posibles historias. Entonces veamos cómo lo hacemos. Entonces veamos un componente de botón. Entonces, usualmente lo que la gente hace es, aquí es donde cometen el error. Entonces, solo escriben una sola historia. Entonces, podría haberme detenido aquí, y luego mi botón primario habría sido accesible. Pero si miraste la interfaz de usuario que mostré, mi botón secundario no era accesible. Eso es porque mi botón primario estaba funcionando como se esperaba debido a el correcto contraste de color, mientras que mi botón secundario no lo estaba. Entonces, por eso es muy importante. Si hay un componente, y si sientes que hay una variación que puedes ver en tu aplicación, es importante escribir y documentar todas esas variaciones en tu aplicación.

Entonces, escribir una historia es muy simple. Solo tienes que crear una plantilla. Y una vez que creas una plantilla, solo tienes que pasar los argumentos correctos para ella. Estas son básicamente las props que te gustaría pasar, y luego, sí, estás listo para comenzar. Entonces, es muy importante escribir realmente todas las posibles historias para un componente. Si te pierdes en esto, simplemente no estás, simplemente no estás testing todas las variaciones de tus componentes. Y luego, una prueba de re-interacción. Entonces, ahora, para resumir, hemos integrado el complemento. Hemos decidido las reglas que querríamos elegir. Y luego, también hemos decidido todas las posibles historias que tendríamos que escribir para el componente. Ahora, tienes una component library donde tienes componentes, conoces los diferentes componentes, y los cambios de estado en los que el componente puede renderizarse. Y has cubierto todos estos casos. Ahora, lo siguiente son las interacciones. Digamos por ejemplo, hay un componente, hay un cuadro de entrada y cuando escribes algo, eso básicamente verifica la validation de URL. Y si escribes algo en el cuadro de entrada,

Digamos que hay un botón, cuando haces clic en el botón, hace una llamada a tu backend y luego, en función de la respuesta, muestras una vista. Así que con Storybook, puedes hacer esto. Déjame mostrarte cómo y lo sencillo que es hacerlo.

Así que supongamos que hay un proyecto de anuncio. Digamos que quieres añadir un proyecto. Te mostraré en la interfaz de usuario cómo hacer esto. Así que eso es un proyecto de anuncio. Así que esta es mi caja de entrada por defecto, donde querría añadir la URL correcta. Así que aquí, si lo miras, he añadido una URL no válida y luego me avisa del problema. Así que aquí es donde están las interacciones. Así que estaba hablando de las interacciones, así es como haces la interacción. Puedes elegir lo que querrías esperar en la vista. Así que aquí, lo que estoy intentando hacer es, estoy intentando ver si... estoy intentando obtener el componente y luego estoy intentando introducir la URL en el componente, la URL no válida. Y luego estoy intentando ver si esta es una URL no válida. Y luego tengo esta descripción, ¿verdad? Así que antes cuando viste, no tenías esta descripción aquí. Así que solo cuando introduje una URL, ¿verdad? Hay una descripción que aparece. Así que con Storybook y con las interacciones, ¿verdad? Lo que puedo hacer es que puedo comprobar cada cosa. En cada cambio de estado, puedo ver si hay algo que espero que esté en la interfaz de usuario. Así que aquí, esto es lo que estoy comprobando. Así que solo estoy comprobando si una URL de Storybook, ¿vale? Tiene una descripción accesible. ¿Qué es una descripción accesible? Por favor, introduce una URL correctamente formateada. Así que esto es lo que puedo hacer. Te mostraré algunos más escenarios también. Así que aquí tienes un componente que estás intentando importar básicamente. Así que cada vez que haces clic en importar, se hace una llamada a la API, y luego se muestra. Así que digamos que la llamada a la API falla si estás intentando importar, y si la importación no funciona, ¿verdad? Introduces esto

Sí. Así que ahora que también he añadido un ejecutor de pruebas, permíteme mostrarte cómo ejecutaría realmente estas auditorías. Primero debes asegurarte de que tienes storybook en funcionamiento. Así que solo tienes que hacer yarn storybook, tal como te recomienda storybook, esto es lo básico. Así que ya he iniciado mi storybook y ahora lo que haría es que intentaría automatizar esto. ¿Cómo lo haría? Ejecutaría el script. Pero antes de ejecutar el script, me gustaría mostrar lo que hace el script. Así que aquí simplemente usa yarn test storybook. Así que esto es algo que te ofrece storybook y que te ayuda a auditar los problemas de accessibility. Así que simplemente ejecuto este script y veamos qué sucede. Solo toma un poco de tiempo para ejecutar realmente estas pruebas. Deberíamos verlo en cualquier momento. Sí. Sí. Sí. Así que viste aquí, ¿verdad? Así que realmente ejecutó todas las auditorías de accessibility directamente en mi terminal. Y también lo genial aquí es que te muestra los problemas exactos.

Así que digamos que algo falló, ¿verdad? Te dice, en realidad, cuál es el componente que está fallando. Así que aquí el primario funciona y el secundario no, no es accesible. Y también te dije por qué no es accesible porque a propósito, ¿verdad? He dado un contraste de color incorrecto. Y luego me muestra que, vale, se suponía que el esperado era un cero, pero entonces tienes un problema aquí. Y entonces has visto esa violación de seguridad. Y entonces, ¿cuál es la violación, ¿verdad? Y ¿cuál es la regla? Así que es una regla de contraste de color y ¿cuál es el impacto de su gravedad? Así que debes asegurarte de que te adhieres a esta regla, ¿verdad? De lo contrario, verás esto.

Así que con esto, lo que sucede es que puedes integrar fácilmente tu auditoría de accessibility en tu CI. Así que además de ver las cosas en tu interfaz de usuario, ¿verdad? Todo el mundo que está presentando un PR ahora tiene la seguridad de que todo lo que están presentando es accesible. Así que eso es lo que nos ayuda. Ahora, querríamos solucionar esto, ¿verdad? No quiero ver las cosas fallando. ¿Cómo lo haría? Así que permíteme mostrarte, ¿verdad? Te mostraré cuáles son los diferentes problemas que existen actualmente y cómo los solucionaría.

En primer lugar, querría desactivar esto porque hay algunos problemas de contraste de color. He desactivado esto y luego también veo algunos otros problemas, ¿verdad? Creo que, vale. Creo que solo el contraste de color debería ser el problema. No veo ningún otro problema.

Vale. Sí. Así que intentemos ejecutar la auditoría una vez más y veamos ahora si pasa los controles. Vale. Así que sí. Así que aquí está, ¿verdad? Así que pasó todas las pruebas ahora y no ves ninguna violación aquí. Así que esta es la belleza de ello. Y también es muy sencillo de integrar en tu CI.

Digamos que tuvieras que integrarlo en tu CI, ¿verdad? Es muy sencillo. Todo lo que tendrías que hacer es simplemente ejecutar el script. Así que lo que he hecho aquí en el script, déjame mostrarte lo que he hecho en el script. Básicamente tengo que iniciar storybook. Así que solo cuando inicio storybook, ¿verdad? Podré hacerlo. Así que tendré que construir storybook primero. Eso es lo que hace esto. Y luego, una vez que construyo storybook, querría iniciar storybook en el número de puerto 6606. Y luego, una vez que he iniciado storybook, querría esperar hasta que se inicie. Y luego, una vez que estoy seguro de que se ha iniciado, tengo que ejecutar esto, ejecutar el script que ejecuté en la terminal. Y con esto, básicamente se ejecuta en el CI.

Déjame mostrarte también cómo se ve en el CI. Así que aquí está, ¿verdad? Así que en realidad lo integré en mi CI en uno de mis proyectos. Así que podrías ver exactamente lo mismo que viste. Así que no tienes ninguna violación de accessibility detectada. Estas son las pruebas que están pasando. Y sí.

Entonces, con esto, si alguien no siguió las accessibility standards, ¿verdad? Y si hay un PR, y si lo integraste en el CI, inmediatamente recibirán una retroalimentación como, okay, esta cosa en particular no es accesible. Y luego pueden corregirlo inmediatamente y volver a ello. Por lo tanto, el ciclo de retroalimentación es muy, muy pequeño. Y luego en realidad te ayuda a ahorrar tiempo. Y con esta estrategia, ¿verdad? Asegura que cualquiera y todos los que contribuyen a un proyecto están siguiendo las accessibility standards. Y hay automatizaciones en su lugar que básicamente te ayudan desde el principio.

Y ahora que tenemos pruebas de accessibility automatizadas, algo que me gustaría decir, ¿verdad? Storybook o cualquier complemento o cualquier herramienta, cualquier herramienta moderna hoy en día, no garantiza auditorías de accessibility del 100%. Porque siempre tendrás que realizar pruebas de accessibility manuales. Permíteme decirte por qué. Digamos, por ejemplo, que existen estas tecnologías de asistencia como tus lectores de pantalla, ¿verdad? No hay forma de saber si la user experience o el orden en el que tu contenido debe ser renderizado o varias otras cosas, ¿verdad? Que querrías, que querrías respetar. A menos que realmente realices pruebas de accessibility manuales en estas tecnologías de asistencia, no puedes identificarlas realmente. Así que Storybook no es un reemplazo completo para tus pruebas manuales. Lo que estamos tratando de hacer aquí es, estamos tratando de buscar la mayoría de los problemas de accessibility, que son los básicos. Y eso representa alrededor del 60% al 65% de los problemas. Y estamos tratando de ver cómo podemos realmente llegar a una estrategia y un plan para que podamos cubrir fácilmente el 65% de los problemas sin mucho esfuerzo. Así que si simplemente sigues las cosas que te dije, desde la integración de las reglas, hasta la escritura de todas las historias posibles, hasta las interacciones, hasta la automatización en un CI, se soluciona el 65% de los problemas. Y luego de eso, lo que haces es, vas y luego realmente miras los otros problemas complejos que sólo pueden ser probados en tus lectores de pantalla reales. Y luego identificas estos problemas y luego solucionas estos problemas, y luego tus componentes son 100% accesibles.

Ahora, intentemos comparar el complemento de accessibility con Lighthouse. La mayoría de las personas hoy en día utilizan Lighthouse para sus auditorías de accessibility. Permíteme decirte cómo el complemento de accessibility de Storybook es mejor que Lighthouse. Así que en primer lugar, en términos de su capacidad para auditar problemas de accessibility, ambos, tu complemento de accessibility así como tu Lighthouse, tienen la misma capacidad porque tienen el mismo motor de accessibility. Así que ambas herramientas utilizan el motor de accessibility de los sistemas Deque, asegurando que tienen capacidades iguales para identificar problemas de accessibility. Así que si estás buscando, si la comparación es, cuál es mejor en términos de capacidades, ambos son prácticamente iguales.

Aquí es donde difiere, ¿verdad? Aquí es donde está la diferenciación. Insights a nivel de página versus a nivel de componente. Así que si miras a Lighthouse, ¿verdad?, Lighthouse es algo que utilizas como una extensión o básicamente es una herramienta en tu Chrome o cualquier otro navegador donde realmente ejecutas las auditorías de accessibility después de renderizar tu aplicación. Así que después de todos tus componentes, ¿verdad?, después de haber integrado todos tus componentes, después de haber construido toda tu página, vas y ejecutas esto. El problema con Lighthouse es que funciona muy bien a nivel de página. Digamos que ya has construido un componente, o tal vez si hay una aplicación que no es compatible con Storybook, ¿verdad?, o tal vez si no es compatible con la auditoría de accessibility, tu Lighthouse es el recurso a utilizar en esos escenarios. Pero con la auditoría de accessibility, ¿verdad?, lo que haces es que intentas identificar los problemas de accessibility directamente desde el desarrollo de tu componente. Así que cuando estás desarrollando tu componente, ¿verdad?, realmente te ayuda a identificar los problemas de inmediato y luego puedes solucionarlos. Digamos que si no eliges usar la auditoría de accessibility y luego prefieres ir con Lighthouse, ¿verdad?, lo que harías es que construirías tus componentes y luego publicarías tus componentes en tu component library y luego volverías a tu aplicación e importarías los componentes y luego renderizarías esos componentes en el navegador y luego identificarías que, okay, con Lighthouse o cualquier herramienta que haga violaciones a nivel de página, identificarías que, okay, hay una violación aquí, vuelves a tu component library y luego de nuevo lo arreglas y luego repites. Así que lo que sucede aquí es que es un ciclo de retroalimentación más largo. Mientras que con el complemento de accessibility de Storybook, simplemente puedes identificar problemas de accessibility mientras estás desarrollando un componente y luego puedes solucionarlo de inmediato. Así que resulta en un ciclo de retroalimentación más corto. Esta es la verdadera diferenciación. Así que si estás construyendo una component library y si quieres comenzar la auditoría de accessibility directamente desde la component library, ¿verdad?, tal como te dije que deberías hacer, entonces el complemento de accessibility de Storybook es la herramienta que debes usar.

Y luego, finalmente, auditoría estática versus auditoría dinámica. En Lighthouse, creo que la mayoría de vosotros ya deberíais haber usado Lighthouse. Y si has usado Lighthouse para auditar problemas de accessibility, lo que hace Lighthouse es que realiza una auditoría estática. Así que lo que ve en la pantalla, simplemente intenta auditar esos problemas. Pero con el complemento de accessibility de Storybook y los diferentes complementos que proporciona el ecosystem de Storybook, como, por ejemplo, tu testing de Viewport, tu testing de interacción, todos estos, ¿verdad? Lo que podrías hacer es que puedes probar los problemas de accessibility incluso en cambios de estado, tal como te mostré donde estaba intentando hacer la validation de URL. Y cuando estaba intentando hacer la validation de URL, si era una URL incorrecta, viste que aparecía un mensaje de error. Y luego estaba intentando comprobar si esa es la descripción accesible correcta. Y lo mismo ocurre con el componente que estaba intentando importar. Y luego estaba intentando simular esta API. Y luego si había una mala respuesta, ¿verdad?, puedo renderizar una vista diferente.

Si era una respuesta buena, entonces realmente podría renderizar una vista diferente. Lo que estoy tratando de decir es que, basándote en los cambios de estado, ¿verdad?, puedes realizar tus auditorías. Eso es muy importante.

Sí, eso nos lleva al final de mi charla. Así que esto es lo que hemos aprendido, accessibility y su importancia. El momento, la consideración de accessibility, realmente, ¿cuándo deberíamos empezar a considerar accessibility en nuestra aplicación? Y luego el papel de storybook, por qué es importante. Y luego el complemento de accessibility de Storybook, su ventaja, cómo usarlo, cómo incluirlo en tu component library. Y finalmente, ¿verdad?, cómo automatizas todo este flujo y lo haces tan fácil para tus desarrolladores o cualquier persona en tu equipo para que el 65% de esos problemas de accessibility, ¿verdad?, que representan la mayoría de los problemas, puedan ser solucionados muy fácilmente y no tengas que pasar mucho tiempo en ello.

Sí, gracias, y puedes conectarte conmigo en mis redes sociales aquí. Así que aquí está mi X y mi GitHub. Gracias por tu tiempo.