¿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.
This talk has been presented at React Advanced Conference 2023, check out the latest edition of this React Conference.
FAQ
La accesibilidad web se refiere a la creación de sitios web que pueden ser utilizados por todas las personas, incluyendo aquellas con discapacidades, asegurando que todos tengan la misma capacidad de uso y acceso.
Considerar la accesibilidad desde el inicio permite garantizar que los componentes sean accesibles para todos los usuarios, evitando modificaciones costosas después de que el sitio web o aplicación esté desarrollado y reduciendo el riesgo de incurrir en penalizaciones legales.
Storybook es una herramienta de desarrollo que permite visualizar y probar componentes de manera aislada, proporcionando una documentación clara y facilitando la integración de pruebas de accesibilidad durante el proceso de desarrollo.
El complemento de accesibilidad de Storybook es una herramienta que ayuda a identificar y solucionar problemas de accesibilidad en los componentes de la interfaz de usuario directamente en el entorno de desarrollo, permitiendo una integración y retroalimentación rápidas.
Automatizar las pruebas de accesibilidad ayuda a detectar y solucionar problemas desde las primeras etapas del desarrollo, asegurando que todos los componentes cumplen con los estándares de accesibilidad necesarios y mejorando la calidad del producto final.
Mientras que Lighthouse realiza auditorías a nivel de página después de que los componentes están integrados, el complemento de Storybook permite realizar auditorías a nivel de componente durante su desarrollo, ofreciendo un ciclo de retroalimentación más corto y efectivo.
Los principales beneficios incluyen alcanzar un mayor público potencial, cumplir con legislaciones y evitar multas, mejorar el posicionamiento SEO y ofrecer una mejor usabilidad para todos los usuarios.
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.
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.
This Talk discusses the accessibility efforts at Discord, focusing on keyboard navigation and the challenges faced with implementing focus rings and outlines. The speaker showcases a unified focus ring system and a saturation slider to address accessibility concerns. They also highlight the implementation of role colors and the use of CSS filters for accessibility improvements. The Talk concludes with insights on runtime accessibility checking and the development of a performant core runtime system for checking accessibility issues.
AXe is an accessibility engine for automated web UI testing that runs a set of rules to test for accessibility problems. It can be configured to disable or enable specific rules and run based on tags. Axe provides various options, but axe linter does not support all options. The importance of investing time and resources in accessibility is emphasized, as it benefits not only those with disabilities but improves the web for everyone. Manual testing is also highlighted as a necessary complement to automated tests for addressing accessibility issues.
Nested interactive elements can cause accessibility issues on websites, and the speaker shares a personal experience with an accessibility bug involving a list component. Mitigating nested interactive structures involves limiting these patterns during development and restructuring existing elements. The speaker provides recommendations for improving accessibility, such as adjusting role properties and gathering user feedback. The conclusion emphasizes the importance of accessible solutions and encourages sharing resources to build more inclusive experiences.
The Talk discusses the use of dialogues and popovers in web development. Dialogues can be modal or non-modal and are now accessibility-supported. Popovers are versatile and can be added to any element without JavaScript. They provide suggestions, pickers, teaching UI, list boxes, and action menus. Modal and non-modal dialogues and popovers have different behaviors and dismissal methods. Browser support for these features is expanding, but there are still open questions about positioning, semantics, and other use cases.
This Talk explores the intersection of accessibility and test-driven development (TDD) in software development. TDD is a process that involves writing tests before writing production code, providing a safety net for code changes. The Talk demonstrates how to apply TDD principles to real-life examples, such as filling out a form, and emphasizes the importance of user-centric testing. By using atomic design principles, code can be organized in a clean and easy way. The Talk also discusses the use of labels and test IDs in tests for improved accessibility.
Accessibility is about making sure everyone can participate on the web, regardless of disability. Automated tools like Lighthouse and React Axe help identify accessibility errors and provide guidance on fixing them. Unit tests validate ARIA attributes and keyboard navigation, while integration and end-to-end tests focus on outcomes and simulate user experiences. Cypress.io is an open-source testing framework with excellent accessibility support. Implementing small changes leads to a deep understanding of web accessibility and bug resilience.
Accesibilidad web para Ninjas: Un enfoque práctico para crear aplicaciones web accesibles
Workshop
2 authors
En este masterclass práctico, te proporcionaremos las herramientas y técnicas que necesitas para crear aplicaciones web accesibles. Exploraremos los principios del diseño inclusivo y aprenderemos cómo probar nuestros sitios web utilizando tecnología de asistencia para asegurarnos de que funcionen para todos. Cubriremos temas como el marcado semántico, los roles de ARIA, los formularios y la navegación accesibles, y luego nos sumergiremos en ejercicios de codificación donde podrás aplicar lo que has aprendido. Utilizaremos herramientas de prueba automatizadas para validar nuestro trabajo y asegurarnos de cumplir con los estándares de accesibilidad. Al final de este masterclass, estarás equipado con el conocimiento y las habilidades para crear sitios web accesibles que funcionen para todos, y tendrás experiencia práctica utilizando las últimas técnicas y herramientas para el diseño inclusivo y las pruebas. ¡Únete a nosotros en este increíble masterclass de codificación y conviértete en un ninja de la accesibilidad web y el diseño inclusivo!
¿Incluyen tus pruebas automatizadas verificaciones de accesibilidad? Este masterclass cubrirá cómo comenzar con jest-axe para detectar violaciones de accesibilidad basadas en código, y Lighthouse CI para validar la accesibilidad de las páginas completamente renderizadas. Ninguna cantidad de pruebas automatizadas puede reemplazar las pruebas manuales de accesibilidad, pero estas verificaciones se asegurarán de que tus probadores manuales no estén haciendo más trabajo del necesario.
A menudo vemos que JavaScript daña la accesibilidad de un sitio web. En esta masterclass, aprenderás cómo evitar errores comunes y cómo utilizar JS a tu favor para mejorar la accesibilidad de tus aplicaciones web. En esta masterclass exploraremos múltiples ejemplos del mundo real con problemas de accesibilidad, y aprenderás cómo hacer que funcionen para las personas que utilizan un mouse o un teclado. También aprenderás cómo se utilizan los lectores de pantalla, ¡y te mostraré que no hay razón para tener miedo de usar uno! Únete a mí y déjame mostrarte cómo la accesibilidad no limita tus soluciones o habilidades. ¡Al contrario, las hace más inclusivas! Al final, serás capaz de:- Comprender los principios de WCAG y cómo están organizados- Conocer casos comunes en los que JavaScript es esencial para la accesibilidad- Crear enlaces, botones y elementos conmutables inclusivos- Utilizar regiones en vivo para errores y estados de carga- Integrar la accesibilidad en el flujo de trabajo de tu equipo de inmediato- Darte cuenta de que crear sitios web accesibles no es tan difícil como parece ;)
React Native es un framework utilizado para crear aplicaciones nativas de iOS y Android de una manera con la que los desarrolladores web ya pueden estar familiarizados. Pero, ¿cómo asegurarse de que tus aplicaciones React Native sean inclusivas y utilizables para todos? Scott compartirá consejos sobre cómo probar y construir aplicaciones React Native con accesibilidad integrada.
Comments