CI/CD accesible

Hola a todos. Bienvenidos a mi charla y discutamos la accesibilidad en un contexto diferente aquí en CIDI, ¿de acuerdo? Pero primero, un poco sobre mí. Mi nombre es Maya Min. Soy una ingeniera de software senior en Microsoft Industry AI. Nuestro grupo se enfoca en aprovechar diferentes tecnologías de LM para desarrollar soluciones y aplicaciones integradas de IA para industrias específicas. Llevo más de 10 años en la industria, enfocándome en la web y el frontend. Recientemente publiqué un libro llamado Aprendiendo Vue con Aurelie, que te enseñará y guiará cómo desarrollar aplicaciones web utilizando Vue como framework frontend en el contexto de TypeScript. Si estás interesado en aprender un nuevo y asombroso framework, échale un vistazo. También soy embajadora de Cloudinary, experta desarrolladora de Google y organizadora de la comunidad View.js Israel. Puedes seguirme en Maya Chavin en LinkedIn o Twitter, o seguir mis publicaciones en mi blog mayachavin.com. Y eso es suficiente sobre mí. Pasemos a nuestra primera pregunta. Ya conocemos la accesibilidad. Sabemos por qué es importante, pero ¿por qué las pruebas de accesibilidad y por qué deben realizarse en el contexto de CIDI? De acuerdo. Primero y principal, intenta hacer clic en este botón. ¿Puedes hacerlo, verdad? Porque este botón, aunque parece un botón real, tiene el texto 'Haz clic aquí para continuar'. No es un botón real, es solo una imagen. Y esto es exactamente de lo que hablamos cuando mencionamos la accesibilidad. El botón no es accesible. Nadie puede usarlo. Esto significa que tenemos un problema de accesibilidad. Aquí entra en juego la definición de accesibilidad web. La accesibilidad web es cómo un usuario puede ver, escuchar y percibir tu aplicación para que puedan entender, o al menos llegar a algún entendimiento de cómo usar, navegar o interactuar con tus aplicaciones web. Esto es similar al flujo completo de la experiencia del usuario en muchos sentidos. Y cuando hablo de accesibilidad, generalmente digo que es una experiencia del usuario porque incluye la accesibilidad en su interior. Pero en base a esto, es muy difícil decidir cuál es el nivel de cumplimiento para la accesibilidad. Esto incluye muchas cosas, como escuchar, ver o entender, ¿verdad? Para eso, existe un grupo llamado WCAG que ha desarrollado unas pautas muy,

es una guía estándar de cumplimiento para la accesibilidad. Han estado trabajando arduamente y se ha convertido en un estándar industrial para empresas y dominio público seguir y reflexionar sobre ello. Entonces, el nivel normal para WCAG, el nivel aceptable para WCAG, el cumplimiento de la accesibilidad para empresas y dominio público es el nivel EE de la versión 2.1 y superior. Entonces, hay 3 niveles AA y AAA. Pero hay muchas cosas mencionadas en su sitio web, y es posible que te sientas un poco abrumado cuando vayas al sitio web porque incluye muchas explicaciones. Son explicaciones muy detalladas. Así que en esta charla, solo resumiré el estándar de cumplimiento más común y las verificaciones que debemos seguir. Contraste de colores, navegación, enfoque, puntos de referencia, diseño de contenido, 200% para 400%. Puedes pensar que 200% y 400% no son tan comunes. De hecho, son muy comunes porque incluyen cómo los usuarios hacen zoom dentro y fuera de tu sitio web en un dispositivo pequeño, como una computadora portátil con pantalla pequeña. Y 200% y 400% definen el nivel máximo en el que el usuario puede hacer zoom en tus aplicaciones y asegurarse de que tu contenido se mantenga de manera consistente y utilizable incluso cuando los usuarios hacen zoom en ese caso. Contenido comprensible, manejo de formularios, medios, tipografía, comportamiento de enlaces internos y externos. Si tienes un enlace externo, lo que significa que el usuario será redirigido a una nueva página, abrir una nueva pestaña, debes informar de alguna manera al usuario que esto va a navegar a un nuevo sitio web y el usuario no se sorprenderá. Orden de pestañas y muchas más. Sí, muchas más. Estos son solo un conjunto esencial de cosas a seguir. Y hay otras cosas dependiendo de la complejidad de tu aplicación.

Entonces, llegamos a la siguiente pregunta. ¿Podemos automatizar las pruebas de accesibilidad? Bueno, echemos un vistazo a nuestros componentes en las aplicaciones de interfaz de usuario. Me gusta usar mi patrón de diseño favorito, el diseño atómico, donde descomponemos los componentes en componentes más pequeños hasta el nivel más bajo. Así que tenemos átomos, que es la pieza más pequeña y aislada del núcleo o componente que es independiente y se puede utilizar para construir un nivel mucho más complejo de componentes como moléculas. Las moléculas, construidas sobre los átomos, se pueden utilizar para construir organismos más complejos. Entonces, los átomos, piensa en un botón, un icono. Las moléculas, piensa en un formulario. Y los organismos, piensa en una galería donde tienes una lista de elementos y cada elemento tiene otro componente. Y también tienes búsqueda de campo, paginación, y así sucesivamente. Y a partir de este organismo, puedes construir una página completa cada vez más compleja. La página es menos probable que sea un componente, pero es más como un elemento independiente en el que puedes realizar pruebas de rendimiento y pruebas de extremo a extremo en este nivel. Entonces, para el cumplimiento de la accesibilidad y las pruebas de accesibilidad para los componentes, también lo descomponemos según los diferentes niveles de un componente. Entonces, para los átomos, no vemos realmente la necesidad de probar todo. Por lo tanto, para los átomos, solo probamos el color, la capacidad de enfoque, la semántica, el uso de HTML, el contenido informativo y la tipografía. Todas las cosas que se pueden probar de forma aislada. No necesita interactuar con otros componentes. Puede interactuar por sí mismo. Por lo tanto, solo verificamos estas cosas en este nivel. Cuando pasamos a las moléculas, que ya tienen la interacción entre un elemento y otro elemento, comenzamos a preocuparnos por el flujo de navegación, el diseño de los hitos y el flujo de enfoque. Y si se trata de una tabla y un formulario, también debemos verificar si la tabla y el formulario se construyen correctamente cuando navegas entre una celda y otra celda. ¿Cómo se ve y cómo se siente para el usuario? Y para el organismo, repites lo que las moléculas verifican para la accesibilidad, pero también agregas otro nivel llamado diseño de contenido. El diseño de contenido es similar al uso de hitos donde el contenido, cómo fluye el contenido, si fluye correctamente, si es comprensible o no. Y para las páginas, simplemente repetimos lo que probamos en nuestro organismo porque son muy similares, solo un poco más complejas. Por lo tanto, para todo esto, las pruebas de accesibilidad para los niveles de componentes están divididas. Hemos creado dos conjuntos de pruebas de accesibilidad. El primero es la prueba de componente y el segundo es la prueba de flujo o preferencia del usuario. La prueba de componente incluye qué áreas están etiquetadas, si estamos utilizando la etiqueta y el atributo correctos, e información. Uso semántico, ¿estamos utilizando la semántica correcta o estamos utilizando algo profundo para algo que no debería ser profundo? Capacidad de enfoque, contraste de colores, esto se trata más del texto versus el fondo. Tipografía, etiqueta accesible, si tenemos una etiqueta accesible adecuada para una imagen como un texto de arte, y así sucesivamente. Etiquetas de formulario, cada entrada debe tener una única

formulario, y no puede pasarse por alto. ¿Tenemos suficiente formulario para decirle al usuario qué hace la entrada? ¿Tenemos suficiente etiqueta para decirle al usuario qué hace la entrada? Bueno, esto es una prueba de componente. La segunda es una prueba de flujo y preferencia del usuario, donde nos enfocamos un poco más en la preferencia del usuario. Flujo de navegación utilizando el teclado. Flujo de enfoque, cuando hacemos foco, navegamos con la tecla de tabulación de un elemento interactivo a otro, ¿dónde se enfoca, dónde está el flujo de enfoque que no tiene sentido para el usuario? Calidad del contenido, soporte de lectores de pantalla, donde necesitas escuchar lo que el lector de pantalla está diciendo sobre tu elemento en la página y ver si también tiene sentido e incluye toda la información que debe incluir. Contraste entre imagen y texto en un banner, esto es mucho más difícil de probar en comparación con el texto versus el fondo, y flujo de errores y hitos.

Entonces, en base a esta división, ahora podemos entender más o menos cuál es más adecuado para la prueba de automatización y cuál no podemos automatizar realmente, tenemos que hacer pruebas manuales. Entonces, para las pruebas de componente, podemos ver que la mayoría de ellas se centran en verificar los atributos de etiqueta, el uso semántico, el contenido, el contenido muy descriptivo y verificar el contraste de texto y fondo, y así sucesivamente. Para eso, podemos lograrlo fácilmente con pruebas automatizadas, incluyendo pruebas unitarias o pruebas de integración de extremo a extremo. Para el flujo y la experiencia del usuario, es un poco más complicado. No es tan sencillo porque depende mucho de cómo el usuario y cómo el humano analizan tu sitio web y tu flujo. Por lo tanto, para esto, debes hacer pruebas manuales, y las pruebas manuales implican pruebas de humo, postproducción y evaluación de diseño antes de que el desarrollador realmente comience a desarrollar una función o componente. Esta evaluación de diseño se realiza en la fase en la que el diseñador diseña todo el flujo y recibe comentarios del desarrollador antes de entregárselo al desarrollador. Bien, para las pruebas automatizadas, tenemos una herramienta muy útil llamada xCore. Es un paquete de JavaScript de código abierto que fue desarrollado por Deque, que es una organización dedicada a la accesibilidad. Y este xCore ha sido utilizado en Google Chrome y Edge, adaptado por Chrome y Edge en el analizador del navegador y el rendimiento web, como Lighthouse. Y se ha demostrado que es muy, muy eficiente. Te permite configurar diferentes tipos, conjuntos de reglas para verificar la accesibilidad. Y también te permite configurar qué nivel de estándar WCAG quieres probar en tus aplicaciones, según tus necesidades. Y siempre está actualizado, por lo que no debes preocuparte de que se vuelva obsoleto. Bien, por último, tiene un amplio soporte para diferentes frameworks y marcos de pruebas, como React y ClearWire y Cypress. Por lo tanto, puedes crear fácilmente una prueba de integración de extremo a extremo con estas extensiones. Entonces, xCore es una biblioteca de JavaScript de código abierto para pruebas de accesibilidad. También puedes usarlo en las pruebas unitarias de tu conjunto de pruebas unitarias. Sin embargo, para mayor comodidad, puedes usar Chess, que es un paquete de código abierto, un paquete de npm, que ya envuelve a xCore y también proporciona el comparador de ajedrez personalizado. Y no tienes que escribir tu propio comparador para que se ajuste al estándar de xCore. Y este proyecto es bastante fácil, bastante sencillo de usar. Lo incluyes en tu sistema de pruebas unitarias de ajedrez en tus aplicaciones e instálalo con ChessDom para que ChessDom simule las simulaciones para tus pruebas. Y luego puedes usar las funciones de renderizado para renderizar el componente que deseas probar, o la página que deseas probar, y pasar el componente a la función x y esperar a que verifique si tiene alguna violación o no. Para las pruebas de extremo a extremo, tenemos muchas más cosas

que son más amplias que solo el soporte. Debido a que las pruebas de accesibilidad de extremo a extremo están principalmente destinadas a pruebas de extremo a extremo, donde tenemos que ver el diseño real y podemos realizar las pruebas en el diseño real, similar a cómo los usuarios perciben su aplicación. Entonces, para las pruebas de extremo a extremo, para xCore, tiene un paquete que va con Playwright, Playwright.js, que es mi marco de pruebas de extremo a extremo favorito porque es muy rápido y gratuito y es un proyecto de código abierto. Y se puede ejecutar en muchos idiomas diferentes, no solo en JavaScript. Para Playwright, también tiene una sección dedicada para las pruebas de accesibilidad, cómo integrar xCore en las pruebas de accesibilidad. Entonces, para usar xCore en Playwright, instalaremos el paquete xCore xPlaywright y simplemente importaremos xBuilder, que es la función de clase que nos da la instancia, solo incluiremos el envoltorio alrededor de la página y luego podemos verificar, analizar, activar la función, analizarla. Entonces, primero, iremos a, navegaremos a nuestra prueba a la página que la página objetivo en esta prueba es una página de inicio y luego esperaremos a que xBuilder escanee y analice la instancia de la página a la que acabamos de ir, y finalmente comprobaremos si hay alguna evaluación o no. Ok, usando xCore y Playwright, podemos cubrir las pruebas de navegadores reales, incluidos diferentes dispositivos, diferentes navegadores, y ver si realmente funciona y cómo se ve. También podemos extenderlo, no solo ver si hay alguna violación, también podemos extenderlo para verificar si un componente es visible, si un elemento es visible, si un elemento es enfocable, porque está imitando la experiencia real del usuario. Entonces, también puedes ver si un controlador de eventos, cuando haces clic en él, qué sucederá, si los diálogos se abren como se espera en la regla de accesibilidad a nivel de página y también puedes hacer validaciones de aplicaciones de widgets de terceros y contraste de colores, contraste de colores completo, y agregar completamente automatizado con un conjunto predefinido de reglas. Entonces eso es xCore con Playwright, y este es el ejemplo de cómo se vería la violación. Será una matriz de violaciones donde te dará algunos detalles, el nivel de impacto y toda la información sobre los elementos que tienen la violación. Ok, y eso es xCore con Playwright como prueba de extremo a extremo y también como prueba unitaria.

¿Qué tal agregar la accesibilidad como parte del flujo de trabajo de CI? Si estás usando GitLab, hay una característica muy buena para las pruebas de accesibilidad que es el flujo de trabajo de pruebas de accesibilidad. Está incluido en tu flujo de trabajo de GitLab. Lo que debes hacer es simplemente descargar la plantilla e incluirla en tus aplicaciones, la plantilla de YARN como flujo de trabajo, está en el flujo de trabajo para la accesibilidad, luego inclúyelo en tu plantilla principal de flujo de trabajo de YARN. Aquí, puedes definir una etapa de accesibilidad y también podemos proporcionar algunas variables, incluyendo todas las URL que deseas probar para tu aplicación en cuanto a accesibilidad e incluir la plantilla. La plantilla está funcionando y en la parte posterior estará basada en el marco PA11Y para pruebas de extremo a extremo, y este marco es un marco muy conveniente que tiene muchos paquetes diferentes que te permiten crear tu propio panel de control personalizado para la accesibilidad donde puedes ver las violaciones y el cumplimiento a diferentes niveles, y por supuesto, es de código abierto. Entonces eso es sobre el flujo de trabajo de CI de GitLab. Estamos hablando mucho sobre las pruebas de accesibilidad, pruebas automatizadas, pruebas manuales, lo que podemos usar para realizar pruebas de extremo a extremo y pruebas unitarias. Entonces, ¿dónde conectamos esto en el flujo de trabajo de CI/CD si no usamos el flujo de trabajo de GitLab? ¿Qué es CI/CD? CI/CD significa integración continua y implementación continua. Este es un ejemplo de cómo fluye entre el desarrollo de código y la integración continua y la implementación continua. Literalmente, como puedes ver aquí en el desarrollo de código, tenemos un control de origen único donde todo el código se mantendrá allí y luego el desarrollador puede trabajar sobre él con ramas y fusionar de nuevo al origen. Puede ser GitHub, puede ser GitLab, puede ser el repositorio de Azure DevOps que se basa en el repositorio Git y los cuatro niveles de integración CI/CD, el origen, la compilación, la prueba, hasta la implementación. Lo que estamos hablando en el origen es el control de versiones. También tenemos algunas ejecuciones de canalización en la confirmación aquí arriba para asegurarnos de que nada se rompa o use pruebas unitarias antes de fusionarlo de nuevo al origen para que podamos controlar la calidad del código fuente. También tenemos operaciones de estándar de codificación como LinkedIn, como listas de verificación, como revisión de código. Todo esto se asegurará de que nuestro código esté al menos a un cierto estándar antes de pasar a la compilación. Entonces, la compilación, combinamos el código fuente real en el paquete consumible real como paquete NuGet, como ESC, como JAR y un archivo minificado de SO para que podamos implementarlo en la nube para una aplicación web. Y en esta versión de compilación, vamos a ejecutar un conjunto de pruebas unitarias sobre el código fuente listo para asegurarnos de que el origen sea lo suficientemente estable como para compilar. Y luego, después de compilar, implementaremos esto en un entorno de testing y en ese entorno, podemos realizar pruebas más complejas como

Las pruebas de extremo a extremo, pruebas de integración, pruebas de rendimiento y pruebas de seguridad. Y finalmente, si todo va bien, implementamos en producción y la parte de implementación debe estar completamente automatizada. Y después de la implementación, también tenemos algunas pruebas llamadas pruebas iniciales o donde realmente tenemos comentarios de los usuarios sobre el producto y podemos realizar pruebas manuales para ver si en producción todavía se ve bien y no se rompe la experiencia del usuario. Entonces, ¿dónde encaja la prueba de accesibilidad? Puedes ver aquí que encaja en todas las secciones destacadas aquí. Evaluaciones de estándares de código, pruebas unitarias porque hablamos de pruebas unitarias para la accesibilidad, pruebas de extremo a extremo, pruebas de rendimiento y pruebas iniciales. La evaluación de estándares de código se trata más del desarrollo previo al código y de la revisión conjunta y colaboración entre el diseñador y el desarrollador. Las pruebas unitarias, pruebas de extremo a extremo y pruebas de rendimiento son algo de lo que solo hablamos cuando podemos conectar Xcore o ChessX o Xcore con PlayLive para las pruebas de extremo a extremo. Y las pruebas iniciales son pruebas manuales del lado del usuario o del lado de QA para nuestro producto. Así es como integramos las pruebas de accesibilidad y podemos construir un flujo de CI/CD utilizando Travis CI, Circle CI, Azure Pipeline o cualquier otra herramienta de flujo de trabajo de CI/CD que pueda ayudarte a crear un flujo completo para tu aplicación. Ok, para las evaluaciones manuales de código, solo un poco sobre eso. Para hacer una verificación automática manual de tu accesibilidad antes de realizar todas las pruebas automatizadas durante la fase de desarrollo, puedes utilizar Accessibility Insights for Web, que es un proyecto muy bueno de Microsoft, te brinda una prueba automatizada, pero esta prueba automatizada necesita usuarios como análisis humano, por lo que no se puede automatizar en el flujo de trabajo. Y te brinda diferentes niveles, diferentes tipos de funciones como seguimiento rápido, evaluación de acceso rápido y herramientas de ayuda para que durante el desarrollo puedas verificar constantemente tu desarrollo, tu función, si coincide, si está bien para la accesibilidad. Y luego también puedes bloquear los problemas en JIRA para trabajar en ellos más adelante. Y la evaluación manual para las pruebas de otras herramientas que podemos utilizar. Storybooking es una cosa con extensiones de accesibilidad que te permite mostrarlo a los diseñadores para que veas por ti mismo si estás haciendo las cosas correctas o si necesitas hacer algún cambio. Y el complemento de Figma para la accesibilidad entre el diseñador y el desarrollador. Entonces, ¿qué sigue? Estamos hablando de pruebas de accesibilidad manuales, automatizadas y CI/CD. Bueno, en primer lugar, nada de esto funcionará si el desarrollador no tiene conocimientos básicos sobre accesibilidad. Por lo tanto, las pautas y mejores prácticas de accesibilidad son esenciales para incorporar a un nuevo desarrollador y ayudarlo a avanzar más rápido en el ciclo de desarrollo. Y también, los diseñadores deben diseñar con la accesibilidad en mente o incluir el diseño antes de entregárselo al desarrollador. Y por último, define tus pruebas de accesibilidad primero. Y no lo dejes para el final porque definitivamente puedes prevenir alrededor del 30% de los errores comunes de accesibilidad solo con un plan de pruebas automatizado adecuado y ahorrar tiempo para hacer otras cosas. Y prueba manualmente todos los casos complejos. Eso es todo. Gracias por unirte a mi charla. Espero que te haya gustado.