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

Rate this content
Bookmark

¿Eres un desarrollador cansado de las pruebas de accesibilidad manuales y los largos ciclos de retroalimentación que conllevan? ¿Quieres auditar y probar eficientemente la accesibilidad de tus componentes mientras ahorras tiempo y esfuerzo? ¡No busques más! En esta charla, exploraremos cómo Storybook, una herramienta de código abierto ampliamente utilizada para documentar tus componentes de UI, puede ser utilizada para automatizar las pruebas de accesibilidad.

41 min
23 Oct, 2023

AI Generated Video Summary

La charla de hoy se centró en la automatización de las pruebas de accesibilidad para las bibliotecas de componentes utilizando Storybook. Se enfatizó la importancia de la accesibilidad web, junto con los beneficios de incorporar la accesibilidad desde el principio. Storybook fue destacado como una herramienta valiosa para el desarrollo impulsado por componentes, las pruebas y la identificación de problemas de accesibilidad. La integración del complemento de accesibilidad en Storybook permite obtener información a nivel de componente, ciclos de retroalimentación eficientes y pruebas de accesibilidad automatizadas. También se discutieron las pruebas manuales y la resolución de problemas complejos con lectores de pantalla.

1. Introducción a la Accesibilidad Web

Short description:

Hoy hablaremos sobre la automatización de las pruebas de accesibilidad para su biblioteca de componentes. Cubriremos la accesibilidad web, cómo medirla, cuándo considerarla, el papel de Storybook, cómo incluir la accesibilidad en su biblioteca de componentes y comparar el complemento de accesibilidad con Lighthouse y el benchmarking. La accesibilidad web se trata de construir sitios web que puedan ser utilizados por todos. Es importante garantizar la legibilidad, la usabilidad para las tecnologías de asistencia y la navegación por teclado. La accesibilidad web es crucial para atraer a más clientes, cumplir con la legislación, obtener beneficios de SEO y mejorar la usabilidad. Medir la accesibilidad implica percepción, operabilidad y comprensibilidad.

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

2. Consideraciones y Storybook

Short description:

Para garantizar la compatibilidad y robustez, considere hacer su sitio web accesible desde el principio. Comience incorporando la accesibilidad en el desarrollo de componentes y abordando aspectos básicos como las reglas ARIA, el contraste de color y los tamaños de fuente. Cubrir estos aspectos básicos ya hará que su aplicación sea accesible en un 60%. Luego, concéntrese en mejorar la experiencia del usuario en dispositivos de asistencia y en gestionar el orden de lectura. Storybook es una herramienta de código abierto que ayuda con el desarrollo orientado a componentes y las pruebas aisladas, lo que la convierte en una herramienta valiosa para mejorar la eficiencia y limpieza de los proyectos.

que todo en su sitio web sea fácil y claro de entender. Y luego, la robustez. Esto es asegurar la compatibilidad con diversas tecnologías, incluyendo dispositivos de asistencia como su pantalla lector y otros. Y luego, la compatibilidad. Esto es asegurarse de que las características que ha construido para su sitio web son compatibles y funcionan sin problemas en diferentes tecnologías de asistencia. ¿Cuándo debería considerar la accessibility? Normalmente la gente piensa accessibility como algo que se puede hacer después de construir su sitio web, después de tener todo listo. Y luego una vez que se va en vivo, ¿verdad?, la gente suele pensar que la accessibility es algo en lo que se puede pensar después. Pero yo discreparía. La accessibility es algo que debería considerarse desde el principio si se quiere obtener los beneficios de la accessibility. Entonces, ¿cómo se hace? Comience con los componentes. Así que, hoy en día, todo el mundo sigue el desarrollo orientado a componentes. Por lo tanto, debe asegurarse de incorporar la accessibility y su consideración desde el principio mientras comienza el desarrollo de sus componentes. En segundo lugar, aborde los aspectos básicos. Así que, los aspectos básicos como las reglas ARIA, el contraste de color, los tamaños de fuente, el design accesible, y luego algunos otros elementos contribuyen a cerca del 60% de los requisitos de accessibility. Esto es masivo. Y hoy, en mi charla, también intentaré ayudarles con estrategias sobre cómo hacer fácilmente accesible nuestro sitio web y cómo cubrir todos estos 60% de los requisitos básicos que son muy fáciles de cubrir si se tienen las estrategias y el plan correctos. Y luego, finalmente, una vez que ha cubierto los aspectos básicos y sabe que su aplicación ya es accesible en un 60%, ahora lo que hace es intentar mirar los casos complejos, ¿verdad? Como, por ejemplo, ¿cómo mejorar la user experience en estos dispositivos de asistencia? ¿Cómo gestionar el orden de lectura? Y puede abordar todas las demás complejidades.

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

3. Introducción a Storybook

Short description:

Hoy discutiremos la conciencia del desarrollador, la guía de estilo y la documentación, y las pruebas con Storybook. Storybook ayuda a los desarrolladores a conocer los componentes existentes y facilita la construcción de nuevos. Sirve como una guía de estilo viva y simplifica las pruebas, incluyendo las pruebas de accesibilidad. El complemento de Accesibilidad ayuda a identificar y abordar problemas de accesibilidad en los componentes de la interfaz de usuario. Con una fácil integración, Storybook es una herramienta valiosa para los desarrolladores.

del proyecto. Por eso es por lo que Storybook es una de las herramientas más utilizadas hoy en día. Y luego, en segundo lugar, la conciencia del desarrollador. Hoy en día, digamos que si un nuevo desarrollador se une a tu equipo, es muy difícil para el desarrollador conocer los componentes existentes a menos que los tengas documentados en algún lugar. Y esto es exactamente en lo que Storybook te ayuda. Así que con Storybook, conoces exactamente los diferentes componentes que existen. Y luego si un desarrollador tiene que asumir una tarea y empezar a construir componentes, sabe exactamente si hay un componente disponible para ello o si tiene que construir un componente para ello. Y luego en tercer lugar, la guía de estilo y la documentation. Así que Storybook sirve como una guía de estilo viva. Así que si estás haciendo algunos cambios en Storybook, si has documentado tus componentes en Storybook, cuando importas estos componentes a tu proyecto actual, se comportarán exactamente igual. Así que es muy probable que si has probado algo en Storybook y se comporta como se esperaba, cuando lo importas a tu aplicación y cuando lo integras con los otros componentes en la aplicación, se comportará tal y como se espera. Y luego finalmente, y lo más importante, simplifica las testing. Puedes hacer muchas cosas con Storybook. Como puedes hacer pruebas de viewport, pruebas unitarias, pruebas de accessibility. Y hoy nos centraremos en las pruebas de accessibility. ¿Cuáles son las herramientas que nos ayudan con las pruebas de accessibility? Storybook tiene este complemento llamado Complemento de Accesibilidad que nos ayuda con las pruebas de accessibility. Esta es una herramienta que ayuda a identificar y abordar problemas de accesibilidad en los componentes de la interfaz de usuario. Así que permíteme presentarte a Storybook. Esto es lo que es Storybook y tienes diferentes componentes documentados aquí. También tienes documentation para estos componentes donde puedes buscar diferentes cosas. Así que genera automáticamente, genera automáticamente la documentation para ti. Y luego también puedes ver diferentes variaciones de tu componente. Estos se llaman historias. Puedes ver un botón y puedes ver la documentation para el botón. Puedes ver los diferentes escenarios del botón. Por ejemplo, hay un botón principal que puedes ver en tu aplicación. Hay un botón secundario. Y este es el complemento al que me refería, ¿verdad? Así que lo que hace este complemento, ¿verdad?, es simplemente inyectar este complemento en todos tus componentes y luego asegurarse de que se ejecutan auditorías de accesibilidad contra cada uno de estos componentes. Así que puedes entender si hay algo que está fallando o algo que está pasando. Bien, ¿por qué el complemento de accesibilidad? Cuando hay muchas herramientas que ayudan con la accesibilidad, ¿por qué estoy insistiendo en el complemento de accesibilidad con storybook? En primer lugar, fácil integración. Es solo una línea y luego puedes empezar en solo unos minutos. Es así de

4. Información a nivel de componente y retroalimentación

Short description:

La información a nivel de componente es crucial para construir una biblioteca de componentes. La Auditoría de Accesibilidad de Storybook te permite realizar auditorías de accesibilidad en todos los componentes, ahorrando tiempo y mejorando el ciclo de retroalimentación. La retroalimentación efectiva es importante, y Storybook proporciona recursos, enlaces y violaciones para ayudarte a identificar y solucionar problemas. El emulador de daltonismo en Storybook ayuda a construir empatía al permitirte experimentar la interfaz de usuario como lo haría alguien con daltonismo.

fácil. Y luego, en segundo lugar y lo más importante, ¿verdad?, información a nivel de componente. Hoy en día, la mayoría de las herramientas modernas suelen hacer las auditorías a nivel de página. Pero cuando estás intentando construir una biblioteca, ¿verdad?, component library, es muy importante empezar a auditar a nivel de componente. Así que veamos las diferencias, ¿verdad?. Digamos que si elijo una herramienta hoy que ofrece información a nivel de página. El problema con eso es que si estás intentando construir una biblioteca de componentes, cada vez tendrás que construir tu biblioteca, y solo cuando la integres en tu aplicación real y luego la audites en esa aplicación, ¿verdad?, podrás ver las auditorías. Pero con la Auditoría de Accesibilidad de storybook, lo que puedes hacer es que podrás ver las auditorías de Accesibilidad ejecutándose en todos tus componentes e inmediatamente podrás ver si hay algo que se está violando y luego puedes identificarlo y solucionarlo y básicamente ahorrar tiempo porque te ayuda a acortar tu ciclo de retroalimentación. Y luego, en tercer lugar, ¿verdad?, retroalimentación efectiva. Así que esto es algo que es muy importante. Así que hoy en día, si estás intentando elegir cualquier herramienta, lo más importante que buscas es cuán fácil es de usar la herramienta y cuánta retroalimentación proporciona la herramienta para que te facilite la vida. Así que Storybook te ofrece muchas cosas en términos de recursos, enlaces, las etiquetas de security, las violaciones, y básicamente te ayuda a identificar una violación y luego pasar de identificar a realmente solucionar la violación y todos los recursos que te ayudarán a solucionar la violación. Y luego flexibilidad. Así que con el complemento de Accesibilidad de Storybook, puedes elegir tus reglas. Así que no es que, OK, tienes estas reglas que están preestablecidas y luego tienes que lidiar con las complejidades. No es que todos quieran adherirse a los mismos standards, alguien quiere adherirse a algo que es menos compatible, alguien quiere seguir una naturaleza más compatible. Así que con el complemento de Accesibilidad de Storybook, puedes elegir tus reglas. Y luego, finalmente, un emulador de daltonismo. Así que te mostraré todas estas cosas. Así es como. Así es donde te enteras de la gravedad de los problemas. Te dice si algo es crítico, serio, o algo es solo un problema menor que puedes dejar pasar. Y luego también te mostré cómo te ayuda, ¿verdad? Digamos que si hay una violación, así que tengo una violación aquí. Bueno, no tengo una violación, pero déjame mostrarte, ¿verdad? Digamos que si tuviera una violación, ¿qué haría? Así que si esta fuera una violación, lo que me ofrece es que me ayuda a navegar a través de los recursos y me da la descripción exacta de qué es esta regla y por qué necesitamos esta regla en primer lugar y cuáles son las formas correctas de solucionar esto, por qué importa, descripción de la regla para que con esto, ¿verdad? Digamos que si alguna regla estaba fallando, todo lo que tendrías que hacer es simplemente tener que ver si eso es algo que es grave, si eso es algo que es importante para ti. Y si sientes que eso es crítico e importante, ¿verdad? Solo tienes que revisar los recursos, identificar qué hace exactamente la regla o por qué esta regla es importante. Y luego a partir de eso, uh, y a partir de eso, ¿verdad?, realmente llegas a conocer la importancia de

5. Construyendo Empatía e Integrando Accesibilidad

Short description:

Una de las características favoritas es el acceso al emulador de daltonismo, que ayuda a construir empatía y ver la interfaz de usuario como lo haría alguien con daltonismo. Construir aplicaciones accesibles requiere construir empatía. Integra la accesibilidad en tu biblioteca de componentes añadiendo el complemento de Storybook. Elige las reglas que se alinean con tus estándares de accesibilidad.

y luego haces cambios inmediatos en tu código, vuelves, ves si la regla se ha corregido y sí, estás listo para continuar. Es así de fácil. Y luego, ¿verdad? Uh, una de mis características favoritas aquí es el acceso al emulador de daltonismo. Entonces, con este emulador, ¿verdad?, lo que te ofrece es que te ayuda a construir empatía porque llegas a ver y experimentar la interfaz de usuario exactamente como alguien con daltonismo vendría y la experimentaría en la aplicación. Así que déjame, digamos visión de sangre, ¿verdad? Llegas a ver. Pero esto es importante porque te darás cuenta si el tamaño de la fuente está aquí, ¿verdad? Si no puedes leerlo, o si no puedes entender algo de esto, simplemente significa que, bueno, alguien que viene con daltonismo tampoco podrá verlo. Así que construye empatía hoy. Construir aplicaciones accesibles se ha vuelto abrumador y para los desarrolladores, si realmente quieren empezar a centrarse en la accessibility, ¿verdad? Lo primero es construir empatía y esta herramienta, ¿verdad? Te ayuda a construir esa empatía y también te ayuda a ver cosas que no habrías podido ver de otra manera. Ahora llegamos a lo más importante, cómo incluir la accessibility, uh, en tu biblioteca de componentes. Ahora hoy, digamos si estabas construyendo una biblioteca de componentes, y como te dije, ¿verdad? Um, si solo arreglas los problemas básicos alrededor del 60% de tus problemas están resueltos y estos problemas son muy fáciles de solucionar. Si simplemente estableces la estrategia correcta en su lugar, si automatizas y si haces las cosas correctas, podrás hacer que tu aplicación sea accesible en un 60% en muy poco tiempo. Y luego el resto, ¿verdad? Uh, puedes, puedes resolverlo sobre la marcha. Así que veamos las diferentes cosas que estaremos, uh, cubriendo, o esta es mi salsa secreta de cómo implementé la accessibility en mi biblioteca de componentes. Y definitivamente ha dado grandes resultados. En primer lugar, integra la accessibility en absoluto. Así que déjame mostrarte. Así que si tienes Storybook instalado y, uh, lo que creo que hoy, la mayoría de la gente tiene Storybook de lo contrario también ¿verdad? Es muy fácil y sencillo de, uh, instalar e integrar. Así que si tienes el Storybook, uh, instalado ya, es, es muy, uh, fácil de integrar realmente. Todo lo que tendrás que hacer es simplemente tienes que añadir este complemento y luego estás listo para continuar. Es así de simple. Y luego, verás las auditorías ejecutándose en todos tus componentes. Así es donde empiezas. En segundo lugar, tendrás que elegir tus reglas. Uh, elegir reglas es muy importante porque, uh, las reglas que yo querría, um, seguir, ¿verdad? Pueden ser diferentes de las que, que tú querrías seguir. Tal vez quieras seguir los estándares básicos de accessibility, mientras que, uh, alguien más ¿verdad? Querrá seguir todos los standards. Ellos querrían, querrían seguir el estándar más alto y luego hacer que su aplicación, uh,

6. Elegir Reglas en Storybook

Short description:

Para elegir las reglas en Storybook, puedes ir al archivo de vista previa y agregar decoradores y parámetros. En los parámetros, puedes elegir tus reglas de accesibilidad. Puedes habilitar o deshabilitar reglas específicas y configurarlas según tus necesidades. Al habilitar las reglas, puedes ver las violaciones en tu interfaz de usuario de Storybook y enfocarte en las reglas que son importantes para ti.

accesible. Entonces, para elegir las reglas, ¿verdad?, uh, veremos cómo, cómo podemos hacerlo con, con Storybook. Entonces, hay un archivo de vista previa, uh, donde básicamente puedes, um, agregar tus decoradores y tus parámetros y en tus parámetros, ¿verdad? Ese es un parámetro para tu accessibility. Y aquí, ¿verdad? Puedes elegir tus reglas. Entonces, aquí, si ves, tengo, tengo una regla llamada contraste de color que he, que he desactivado básicamente, porque he habilitado falso. Entonces, si quisieras como tal vez como, no desactivado, ¿verdad? Si quieres habilitar esto, podrías habilitarlo, o si quisieras ver otras reglas que quisieras configurar, es, es muy simple. Solo podrías ir aquí. Y luego aquí hay una lista de reglas. Puedes ver las diferentes reglas son tu área. Y luego puedes ver los impuestos, si es que esto cumple, si quieres asegurarte de que estás cumpliendo con los standards, puedes incluirlo. O si sientes que, vale, esto es algo que tú, que no querrías usar. Todo lo que tendrías que hacer es simplemente regresar, venir a tu, simplemente venir a tu configuración aquí, y luego simplemente deshabilitar esa regla. Añades esa regla y luego la desactivas. Entonces, por ahora, ¿verdad?, solo habilitaré esto. Así que podré ver realmente las violaciones en mi interfaz de usuario de storybook. Entonces, simplemente vendré a storybook y luego. Entonces aquí comencé a ver la violación. Entonces, antes cuando te mostré, no viste la violación porque desactivé la regla. Pero ahora, tan pronto como habilito la regla, ¿verdad?, puedes comenzar a ver las violaciones. Entonces, esto también te ayuda a concentrarte solo en las reglas que querrías y dejar todo lo demás, ¿verdad? Todas las historias posibles.

7. Importancia de Escribir Historias de Componentes

Short description:

Las historias son importantes para probar la accesibilidad de todas las variaciones de un componente. Escribir historias implica crear plantillas y pasar las props necesarias. Es crucial documentar todas las variaciones para garantizar pruebas exhaustivas. En resumen, hemos integrado el complemento, elegido las reglas e identificado todas las posibles historias para el componente. Ahora, centrémonos en las interacciones, como la validación de URL en un cuadro de entrada.

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,

8. Interacciones y Pruebas con Storybook

Short description:

Ahora, con Storybook, puedes escribir interacciones y simular llamadas a la API. Puedes elegir qué esperar en la vista y verificar cada cosa en cada cambio de estado. Por ejemplo, puedes verificar si una URL de Storybook tiene una descripción accesible. Storybook facilita la realización de estas interacciones y la prueba de diferentes escenarios.

querrías ver si es una URL válida o no. Ahora, con la mayoría de las herramientas de hoy, no puedes hacer esto. Aquí es donde Storybook se distingue de todas ellas. Con Storybook, puedes realmente escribir estas interacciones y puedes simular tus llamadas a la API.

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

9. Pruebas de Interacciones y Automatización de Accesibilidad

Short description:

Con Storybook, es fácil probar interacciones y simular llamadas a la API. Al probar las interacciones, aseguras la accesibilidad de los pop-ups y los mensajes toast. La automatización de las pruebas de accesibilidad con el complemento permite una prueba exhaustiva de las variaciones de los componentes.

prueba. Así que con Storybook, es muy fácil probar todo esto. Te mostraré cómo. Así que puedes usar el servicio de trabajador de simulación, donde puedes simular tus llamadas a la API. Y luego te mostraré un escenario, ¿verdad? Así que este es un campo de envío. Así que lo que estoy intentando hacer es simplemente ejecutar estas interacciones. Así que primero, intento encontrar el elemento del canvas. Y luego, una vez que identifico el canvas, intento encontrar el elemento con el que querría interactuar. Y luego, una vez que intento encontrar el elemento con el que querría interactuar, interactúo con el elemento real. Así es como lo hago. Así que donde realmente escribo mystorybook.com, esta es una URL no válida. Y luego consigo el botón y luego intento pulsar el envío. Ahora, cuando pulso el envío, normalmente cuando estás intentando construir una biblioteca de componentes, no tienes tus APIs creadas o integradas. Pero si aún quieres probar, este es el lugar donde tus servidores de simulación entran en juego. Puedes hacerlo muy fácilmente. Solo intentas simularlo exactamente. Así que aquí estoy intentando hacer una solicitud a /proyecto. Y luego lo que podría simplemente simularlo para enviar un 401. Y luego, una vez que dices 401, obtienes este lugar como una vista diferente, justo como lo vi aquí. Lo mismo con el éxito, ¿verdad? Tendría que, sí. Así que tu éxito, tienes una interfaz de usuario diferente aquí. Así que cuando importé, y si la llamada a la API tuvo éxito, realmente puedes ver la vista diferente. Ahora, por qué esto es importante es quizás digamos si no escribiste estas interacciones, el pop-up que ves aquí, ¿verdad? O el mensaje toast que ves aquí, nunca podrías probar si este mensaje toast es realmente accesible o no. ¿Qué pasa si todo era accesible, pero la vista que ves en las interacciones, ¿verdad? No son accesibles. Digamos si este contraste de color no era el esperado o quizás el tamaño de la fuente no era el esperado o cualquier cosa que escuchamos, ¿verdad? Y ves que no es accesible, entonces realmente no puedes hacer, entonces realmente no puedes cumplir con todas las reglas de accesibilidad que querrías seguir. Así que esto es muy importante porque una vez que también has probado las interacciones, te aseguras de que, es fácil para ti probar el 60% de los parámetros de accesibilidad en tu aplicación. Digamos si no sigues estas métricas, simplemente no puedes probar todos los escenarios en tu aplicación para accesibilidad. Aquí es donde esto es muy importante. Y ahora, finalmente, automatizando la accesibilidad prueba. Ahora que has integrado tu complemento, has elegido tus reglas, has escrito todas las diferentes, has identificado todas las diferentes variaciones del componente. Ahora que has escrito todas las variaciones lo que sucede es que tu complemento de accesibilidad se activa en todas estas variaciones y luego busca

10. Automatizando las Pruebas de Accesibilidad

Short description:

Y también has comprobado las interacciones. Si hay algo con lo que quieras interactuar con una llamada a la API, puedes simular fácilmente esas APIs. La automatización de las pruebas de accesibilidad es importante cuando se trabaja en equipo. Storybook proporciona un archivo de renderizado de prueba que inyecta aXe para las pruebas de accesibilidad. Puedes configurar las reglas y comprobar las auditorías de accesibilidad. Storybook también admite pruebas de instantáneas, que ayudan a seguir los cambios en la accesibilidad de los componentes a lo largo del tiempo.

auditorías de accessibility. Y también has comprobado las interacciones. Digamos que si hay algo con lo que quisieras interactuar con alguna llamada a la API, justo como vimos, ¿verdad? Estamos intentando importar y luego esa importación tan pronto como haces clic en importar, hace como un mensaje de post, al cual no tienes acceso en tu component library. Así que realmente puedes simular esas APIs fácilmente. Y luego aún puedes desencadenar las variaciones que verías si acaso, si tu llamada a la API falla, entonces ves una vista diferente. Si tu llamada a la API tiene éxito, ves una vista diferente. Ahora que hemos escrito todas estas cosas, ¿verdad? Cuando estás trabajando en un equipo, algo que es muy importante es ¿cómo automatizas esto? Así que cualquier persona en tu equipo, ¿verdad? Cuando están intentando tal vez levantar un PR, están a los mismos standards. Entonces, ¿cómo hacemos esto? Así que déjame mostrarte. Storybook te da un archivo de prueba, donde básicamente lo que hace es justo lo que viste en la interfaz de usuario, ¿verdad? Donde tu complemento de accesibilidad intenta inyectar el aXe a tu audiencia en cada componente. Haces exactamente lo mismo en un entorno diferente, básicamente. Entonces, digamos que si tuviera que hacer lo mismo en el CI, o si tuviera que hacerlo en el terminal, ¿verdad? ¿Cómo lo haría? Así es donde tu archivo de renderizado de prueba te ayuda. Así que básicamente usa tu aXe y luego utiliza las diferentes cosas como tu chequeo de accessibility, tu configuración de accessibility. Todo esto viene de aXe play, ¿verdad? Donde intentas primero, antes de renderizar tu página, intentas inyectar el aXe, básicamente el que es responsable de tu acceso a tu audiencia. Así que aXe es el responsable del acceso a la audiencia. Intentas inyectarlo. Y luego después de inyectarlo, ¿verdad? Lo que haces es que cada vez que hay una historia que se renderiza, intentas buscar ciertas cosas. En primer lugar, tal vez hay ciertas historias en las que no querrías ejecutar aXe. Así que aquí es donde esta comprobación te ayudará. Así que si tú, si sientes que no quieres ejecutar aXe en un componente en particular, puedes simplemente desactivarlo. Y luego tal vez digamos que ahora que tienes, quieres ejecutarlo en todos los componentes, lo que podrías hacer es que podrías venir aquí, configurar todas las reglas que querrías ejecutar, y luego simplemente intentas comprobar las auditorías de accessibility para ello y luego dar un informe detallado aquí. Justo como mencioné la configuración. Esto es muy sencillo. Y también, lo que Storybook te da que muchas herramientas no te dan es que también te ayuda con las pruebas de instantáneas. Así es como realmente puedo hacer las pruebas de instantáneas. Junto con la automation, realmente puedo ejecutar pruebas de instantáneas. ¿Qué son las pruebas de instantáneas? Así que digamos que hay una instantánea de un componente para accessibility, que se almacena aquí. Digamos que quiero cambiar algo en mi componente algún día. Así que sabrá exactamente, te dará una indicación de que, vale, así es como se veía tu instantánea antes, pero ahora ha cambiado. Entonces, ¿realmente quieres seguir con ello? Así que con esto, esta prueba de instantáneas, ¿verdad?, realmente te ayuda mucho. Incluso si alguien está revisando tu PR, ¿verdad?, o algo ha cambiado, saben exactamente,

11. Automatizando las Auditorías de Accesibilidad

Short description:

Este aspecto ha cambiado, ¿y tal vez está afectando realmente los estándares de accesibilidad que te gustaría seguir o no? Por lo tanto, te ayuda a establecer un control. Ahora que también he añadido un ejecutor de pruebas, permíteme mostrarte cómo ejecutaría realmente estas auditorías. Ejecutaría el script usando yarn test storybook, que ayuda a auditar los problemas de accesibilidad. Ejecutó todas las auditorías de accesibilidad y mostró los problemas exactos, los fallos de los componentes, las reglas de violación y el impacto de su gravedad. Al integrar la auditoría de accesibilidad en tu CI, puedes asegurarte de que todo lo que se presenta en un PR es accesible. Ahora, centrémonos en solucionar los problemas.

en realidad. Vale. Este aspecto ha cambiado, ¿y tal vez está afectando realmente los estándares de accessibility que te gustaría seguir o no? Por lo tanto, te ayuda a establecer un control.

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.

12. Integración en CI y Aseguramiento de No Violaciones

Short description:

Para integrarlo en tu CI, simplemente ejecuta el script después de construir e iniciar Storybook en el puerto 6606. Esto permite una fácil integración en tu CI y asegura que no se detecten violaciones de accesibilidad.

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

13. Automatización de las Pruebas de Accesibilidad

Short description:

Si alguien no sigue las normas de accesibilidad y hay un PR, la integración en el CI proporciona una retroalimentación inmediata para corregir problemas y ahorrar tiempo. Esta estrategia asegura que todos sigan las normas de accesibilidad y las automatizaciones ayudan desde el principio.

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.

14. Automatización vs. Pruebas de Accesibilidad Manuales

Short description:

Storybook o cualquier herramienta moderna no puede garantizar auditorías de accesibilidad del 100%. Las pruebas de accesibilidad manuales son necesarias, especialmente para tecnologías de asistencia como los lectores de pantalla. Storybook se centra en identificar la mayoría de los problemas básicos de accesibilidad, cubriendo alrededor del 60% al 65% del total. Siguiendo la integración de reglas, escribiendo historias y automatizando en un CI, se pueden resolver el 65% de los problemas. Los problemas complejos pueden ser abordados probando en lectores de pantalla reales.

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.

15. Comparando el complemento de accesibilidad con Lighthouse

Short description:

Comparemos el complemento de accesibilidad con Lighthouse. Ambos tienen la misma capacidad para auditar problemas de accesibilidad. Sin embargo, la diferenciación radica en los insights a nivel de página versus a nivel de componente. Lighthouse trabaja a nivel de página, mientras que el complemento de accesibilidad ayuda a identificar problemas durante el desarrollo de componentes, resultando en un ciclo de retroalimentación más corto. Además, el complemento permite auditorías dinámicas, probando la accesibilidad en cambios de estado. Si estás construyendo una biblioteca de componentes y quieres comenzar las auditorías de accesibilidad desde el nivel de componente, el complemento de accesibilidad de Storybook es la herramienta a utilizar.

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.

16. Conclusión y Puntos Clave

Short description:

Basándonos en los cambios de estado, podemos realizar auditorías. Aprendimos sobre la accesibilidad y su importancia, cuándo considerarla, el papel de Storybook, la ventaja del complemento de accesibilidad de Storybook, y cómo automatizar el flujo para solucionar la mayoría de los problemas de accesibilidad fácilmente. Conéctate conmigo en mis redes sociales.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.
JSNation 2022JSNation 2022
24 min
a11y and TDD: A Perfect Match
Accessibility has been web development's ugly duckling for quite some time now. I often get asked, "when should you test for a11y in your apps?" My answer is simple, "right from the start!". Regardless of the framework considered - React, Svelte, Vue, YourOwn™️ - as developers we are in a privileged position to help the ugly duckling grow into a beautiful swan. How? By diving deep into the pond and harnessing the power of Javascript APIs to build the right components for your web apps. And how can do you know you are building them right? By pairing Test Driven Development with the Testing Library family. Ready to grow your web apps into swans?
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
Our design systems commonly feature components that show on top of other content: tooltips, date pickers, menus and teaching UI, to name just a few. Proposed updates to the web platform are about to make building these a whole lot easier. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, modality and the top layer.
React Advanced Conference 2021React Advanced Conference 2021
32 min
How to do Good Without Doing Anything
There’s no arguing that building accessible websites is a force for good. But ensuring that our React websites and apps work for everyone can be time-consuming and isn’t always easy to get right. Luckily, investing a little bit of time on your accessibility workflow and setting up a series of automated tools will end up saving you tons of time and energy in the long run.In this talk I will demonstrate how you can leverage automated tools, clearly documented code standards and a well-defined development process in order to make building and testing accessible React apps a breeze. I will discuss the ways that I automate certain aspects of my development workflows to catch accessibility errors, define and set up tests and go through the entire lifecycle of accessibility feature development using a real-world example.
JSNation 2023JSNation 2023
30 min
Accessible Component System Through Customization
Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization, and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance.
How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much accessible we can provide out of the box to our users? How much customization freedom is enough?
That's what my talk's about.

Workshops on related topic

React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
Workshop
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Workshop
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)
React Summit Remote Edition 2021React Summit Remote Edition 2021
91 min
Creating Accessible React Native Apps
Workshop
React Native is a framework used to create native iOS and Android apps in a way web developers may already be familiar with. But how do you ensure your React Native apps are inclusive and usable everyone? Scott will share tips on how to test and build React Native apps with accessibility baked-in!