Logrando pruebas de automatización de A11y

Hola a todos de todo el mundo que asisten a TestJS Summit 2021. Me encantaría hablarles hoy sobre algunas herramientas y estrategias de pruebas de automatización que todos aquí espero puedan usar a partir de hoy, si así lo desean, en torno al tema de la accesibilidad, específicamente las pruebas de automatización de accesibilidad, este es un tema muy emocionante para mí.

Quiero aclarar una cosa. Si ven en mis diapositivas, o lo digo en voz alta, A11y, que pueden ver en la pantalla en este momento, simplemente significa accesibilidad. A11y es sinónimo de accesibilidad. Breve explicación de por qué es así. Hay 11 caracteres entre la A y la Y en accesibilidad. Y si han estado trabajando con internacionalización en el pasado, es posible que estén acostumbrados a ver I18N, es lo mismo que I18N para internacionalización y A11Y para accesibilidad. Pero me desvío.

Mi nombre es Ava Gayde-Rohten y soy una ingeniera de software full stack líder en SkillsEngine, donde construimos aplicaciones en rails y en EmberJS. Así que hay mucho JavaScript, que es donde pongo mi enfoque. Y ese enfoque se centra principalmente en el framework de EmberJS. Algunas partes de esta charla estarán en EmberJS, que imagino que no muchas personas aquí están usando, pero me gustaría compartir algo de mi experiencia en eso y algunas historias de éxito. Y luego veremos cómo aplicar eso a lo que están trabajando.

Entonces, como acabo de decir, en esta presentación, hablaremos un poco sobre EmberJS y específicamente cómo aborda la accesibilidad, creo que hizo un trabajo realmente bueno y explicaré cómo y por qué. Y luego cubriremos algunas herramientas y estrategias para todos, independientemente de lo que estén usando, pueden estar en react, tal vez estén en Svelte o Vue, por ejemplo, no importa. Hablaremos sobre esas cosas. También hablaremos sobre cómo probar algunas de esas cosas de forma automatizada, así como de tomar la responsabilidad y poder contribuir tal vez a algunos proyectos de código abierto o al framework en el que estén trabajando.

El año pasado, en EmberConf 2020, hablé virtualmente en esa conferencia sobre una historia de éxito ligeramente diferente en torno a la accesibilidad. Esa fue sobre cómo pudimos mejorar una función que estábamos implementando en nuestra aplicación al darle prioridad a la accesibilidad. Logramos que los ingenieros, QA, diseño y producto estuvieran mucho más satisfechos con lo que entregamos, pudimos agregar pruebas automatizadas para algo que implicaba arrastrar y soltar, y eso es muy difícil de probar de forma automatizada. Y porque agregamos accesibilidad, pudimos probar eso en su lugar. Ese es un tema diferente para una actualización, pero he tenido múltiples historias de éxito, no solo en Ember, sino también en accesibilidad. Y hoy les hablaré sobre algunas de ellas.

Ember ha estado adoptando los estándares web desde hace algún tiempo. Nos gusta decir que somos muy HTML primero. Nos enfocamos en las recomendaciones del W3C, los patrones de MDN y el enfoque en HTML primero nos permite ser inherentemente muy conscientes de la accesibilidad. Así que dejemos esto claro. Esto es importante, supongo, hablemos sobre por qué la accesibilidad es importante. No solo algunas historias que he tenido. Las personas con discapacidades son la minoría más grande del mundo.

Hay algunas cosas comunes que van de la mano con eso. Podría argumentarse que si creas aplicaciones dirigidas a personas que tienen discapacidades, también obtendrás más clientes y más innovación en tu producto. Y esas cosas son muy ciertas. Son legítimas y valiosas. Pero lo que quiero hablar es un poco diferente. También quiero decir que el término 'personas con discapacidades' abarca muchas cosas diferentes. Incluye, pero no se limita a discapacidades visuales, auditivas y motoras, por ejemplo. Pero lo que quiero decirles hoy es que la accesibilidad no tiene por qué ser difícil. Claro, hacerlo perfectamente, o incluso hacerlo extremadamente bien, eso sí es difícil. Comenzar, sumergirse y hacer que suceda no tiene por qué ser difícil. Se puede automatizar y, además, facilitar aún más el trabajo que hacen a diario.

Entonces, ¿cómo adoptó EmberJS la accesibilidad? Me gusta presentarles a dos amigos míos. Estos son las mascotas de Ember. A la izquierda tenemos a Tomster y a la derecha tenemos a Zoe. Llevan con orgullo sus camisetas de accesibilidad. En EmberJS contamos con un soporte central en torno a la accesibilidad y esto marca la mayor diferencia. Quiero destacar a una maravillosa desarrolladora llamada Melanie Sumner. Es una ingeniera senior en LinkedIn. Ella está involucrada en muchos estándares escritos para la web, además de ser miembro del equipo central, brindándonos soporte de primera clase para cosas que son importantes para ella, como la accesibilidad. Esto significa que en EmberJS hay un profundo respeto por la accesibilidad. Melanie Sumner logró formar un grupo de trabajo de accesibilidad donde discutimos algunas de las dificultades de accesibilidad que existían en ese momento. Pudimos trabajar de manera colaborativa en un entorno de código abierto, donde registrábamos nuestras notas en GitHub y nos comunicábamos a través de Discord, programábamos reuniones, hablábamos de cosas, trabajábamos de forma asíncrona y todas las cosas geniales que el trabajo de código abierto nos brinda. Fue realmente genial. Pudimos abordar algunos problemas del proyecto, ya sea que los haya registrado la comunidad de código abierto o nosotros, a medida que identificamos cosas que simplemente faltaban fundamentalmente.

Parte de esto fue reconocer que, a nivel del marco subyacente, cada aplicación construida con Ember, si hay dificultades, todas estas aplicaciones podrían tener dificultades potenciales. Por lo tanto, trabajamos para abordar esas cosas. Trabajamos en el registro de problemas y en la solución de esos problemas. Trabajamos en la redacción de algunas RFP, que es una forma bastante comprometida de prometer y explicar cómo vas a resolver algo que no está ni aquí ni allá. En última instancia, llegamos al punto de poder resolver algunos de estos problemas, asignando estas tareas a diferentes personas de la comunidad. Y trabajamos mucho en guías y documentación. Cada marco tiene una sección de documentos que explica varias cosas diferentes y he notado que cada uno tiene al menos algo sobre la accesibilidad. Estoy muy orgulloso de lo que EmberJS ha logrado en este sentido. También hay un sitio adicional en el que ayudé a escribir algunos artículos sobre los patrones de los componentes de Ember, que es una forma de decir patrones y anti-patrones, al igual que MDN, la red de desarrolladores de Mozilla. Y pudimos centrarnos no solo en enseñar cómo escribir componentes que cumplan con los estándares HTML de W3C, sino que también sean accesibles. Hay muchas cosas geniales allí. Además de contar con soporte de primera clase, también existe una organización específica de accesibilidad de Ember en GitHub, que fue un gran lugar para albergar gran parte de este trabajo que estábamos haciendo y muchos complementos, que es como llamamos a los complementos o herramientas que pueden ampliar una aplicación Ember para facilitar mucho el trabajo que estas diferentes aplicaciones probablemente necesiten hacer en torno a la accesibilidad. También quiero señalar que algunas de estas mejoras lograron incorporarse al marco central de Ember después de mucha discusión dentro de la comunidad. Eso también fue genial.

Entonces, pasando a la parte interesante, el código. Tenemos dos herramientas principales que ayudan específicamente con la accesibilidad. La primera está en las pruebas. Al escribir algunas pruebas automatizadas, tenemos un paquete de NPM llamado Ember A11y testing, que te permite renderizar una página completa o un componente y luego ejecutar una auditoría de A11y o accesibilidad sobre eso.

Esto es genial porque puedes escribir algunas pruebas exitosas y, si ocurre una actualización en el futuro o alguien modifica el código, puede fallar en tus compilaciones de CI si esas páginas o componentes ya no son accesibles como solían serlo. También pueden servir como listas de verificación para los desarrolladores.

También tenemos Ember template Lint. Esto se suma a herramientas como ESLint, que te avisa cuando hay advertencias o errores en el código que estás escribiendo. Este se enfoca en las plantillas, el HTML, y te informará en tu editor de código mientras escribes algo como: `¡Oye, tengo una etiqueta de imagen y olvidé escribir un atributo alt!`. Cuando se configura correctamente, también puedes hacer que falle en CI, ya que revisa todos tus archivos.

Entonces, eso es genial. ¡Hurra por Ember! Pero lo que estamos aquí es cómo usar esto en otros frameworks. ¿Cuál es el primer paso? El primer paso es darse cuenta de que debemos priorizar la accesibilidad. Eso significa que si trabajas de nueve a cinco, tal vez necesites hablar de ello en tu lugar de trabajo con tu equipo y tu gerente de producto. Tal vez signifique probar algunas cosas. También significa en tus comunidades, ya sea en persona o en línea, proyectos de código abierto en los que estés realmente interesado, o los propios frameworks que tal vez tengan deficiencias en ciertas áreas y en las que puedas contribuir. Por eso estoy aquí hoy, para hablar de ello, hablar de la priorización de la accesibilidad, hablar de por qué es importante y difundir la palabra un poco, y en todas partes donde podamos hacer esto, es un paso en la dirección correcta.

En el código nuevamente, hay una herramienta maravillosa. Es un paquete de NPM publicado por Dex systems llamado Axe-Core. Esto fue creado por un grupo que trabaja en muchos de los estándares en la web que pueden declarar advertencias y violaciones de accesibilidad, y luego escribir pruebas de automatización al respecto. Algunas de estas herramientas pueden cubrir hasta el 50% de las reglas de accesibilidad que existen. Y eso puede no parecer mucho, pero de muchas maneras realmente lo es, y es un gran comienzo. Comenzar con este tipo de herramienta es tan simple como instalarlo a través de NPM, ejecutar Axe y ver qué violaciones ha encontrado. Ahora esta es una herramienta central que se usa con mayor frecuencia para alimentar otras herramientas. Y es la base de muchas otras cosas, como la extensión del navegador. La extensión del navegador es increíblemente fácil de configurar y usar en cualquier navegador que estés utilizando. También es mantenida por Dex systems, por lo que tiene un gran soporte. Puede informarte exactamente lo que encontró en tu página o aplicación completamente renderizada y cuál es la prioridad para solucionarlo, así como tal vez cómo solucionarlo. Esto es especialmente útil no solo para ingenieros, sino también para QA, diseño o producto, para registrar estos problemas y cualquier tipo de sistema de seguimiento de problemas que puedas tener, si es relevante para ti. Ahora, la integración con frameworks es donde se vuelve aún más emocionante. Si estás utilizando Svelte, felicidades, ya tienes la accesibilidad incorporada en ese framework.

Probablemente ya se esté mostrando en las herramientas de desarrollo de tu navegador, creo que algunas de estas advertencias. Pero si estás utilizando React o Vue, es tan simple como instalar un paquete de NPM para ambos. Tal vez limitándolo solo a tu entorno de desarrollo o tal vez a un entorno de preparación, si eso te conviene, pero son solo estas líneas de código, eso es todo. Vue usa, Vue actúa y listo. Ahora, de repente tienes algo que está utilizando Axe Core para enviar a las herramientas de desarrollo de tu navegador. Una comprensión muy clara de si algo es crítico, serio o moderado, una URL de cómo solucionarlo, etc. Lo bueno de las integraciones del framework es que no solo hacen que no sea mucho trabajo, sino que también eliminan las advertencias duplicadas y se conectan a los sistemas subyacentes que dicen: `Oye, tengo un componente que acaba de volver a renderizarse y se activó una actualización` y son capaces de volver a verificar de manera inteligente y ver: `Oye, ¿hay algo más de lo que debemos estar conscientes?` Una nueva advertencia que aún no he agregado a las herramientas para desarrolladores.

Ahora, en cuanto a Linting, existen complementos de ESLint para Vue.js accesibilidad y JSXA11y. Estoy seguro de que también hay otros, y estos te pueden decir directamente en tu editor de código elegido, al igual que cualquier otra cosa en ESLint, `Oye, algo que acabas de escribir o algo en este archivo tiene una advertencia y está justo ahí, puedes verlo y editar ese archivo para realizar tus ajustes y luego ver cómo desaparecen esas advertencias. Es tan satisfactorio poder hacer esto para la accesibilidad. Es una victoria fácil. Casi no hay razón para no hacerlo. Estas son herramientas para desarrolladores, lo que significa que son. Por lo general, gratuitas para agregar a tu aplicación, aparte de un poco de tiempo de instalación de NPM, porque ni siquiera afectan a tus usuarios, pero los efectos de las cosas que solucionas sí lo harán. Hablemos de la automatización. Yo diría que muchas de las cosas de las que acabo de hablar de alguna manera son una especie de automatización. No es un esfuerzo manual buscar algunas de estas cosas, pero si queremos hablar de una verdadera automatización, tal vez estés utilizando solo. Axe Core se puede conectar simplemente usando solo axe, y luego puedes esperar a axe, enviarle algo de HTML y esperar que no tenga violaciones, es tan fácil como eso. Una vez que tengas eso en su lugar, puedes verificarlo dentro de CI en tu entorno de pruebas, tal vez dentro de algún código de componente para verificar que ese componente o lo que sea en lo que estés trabajando sea accesible si estás utilizando pruebas de extremo a extremo.

En cuanto a las comunidades, como mencioné anteriormente, muchos frameworks tienen algunas comunidades excelentes, una gran documentación que está empezando a surgir. Una de las más prometedoras que he visto hasta ahora es la comunidad de Vue A11y. Tienen un sitio web hermoso y muy accesible. Es genial comenzar allí con un sitio web accesible donde tienen tanto potencial para publicaciones, recetas, consejos y herramientas. Sus herramientas son las más desarrolladas, al igual que los complementos de Ember que mostré anteriormente. Hay algunas herramientas de Vue como Vue Skip To o Vue Announcer que pueden ayudarte a manejar algunas de estas cosas que son un poco más difíciles de lograr sin estos complementos que te echan una mano. Esta comunidad de Vue A11y está pidiendo más contribuciones de la comunidad de código abierto. Diría que si te interesa Vue o tienes curiosidad acerca de Vue y la accesibilidad, es de código abierto. Únete, toma algunas de las páginas que actualmente son marcadores de posición y que están pidiendo recetas o mejores prácticas en cuanto a accesibilidad. Escribe algunas de esas solicitudes de soporte abiertas. La comunidad te lo agradecerá, estoy seguro.

John de Sparkbox dijo que las pruebas automatizadas son una mejora, no un reemplazo de las pruebas manuales de usabilidad y accesibilidad. Es importante tener en cuenta después de todo lo que acabo de decir y lo emocionado que estoy por las pruebas automatizadas para la accesibilidad, que es imposible llegar completamente allí, al igual que no es razonable esperar una cobertura de pruebas del 100% en cualquier aplicación para la que estés escribiendo pruebas. Habrá pruebas reales de usuarios que tendrás que realizar. Algunas pruebas manuales recorriendo la aplicación y viendo qué tan usable y accesible es realmente utilizando lectores de pantalla. Utilizando tu teclado para navegar por tus aplicaciones. Tal vez la próxima vez que escribas un componente, intenta navegar por él con la tecla de tabulación. Es un buen punto de partida. Así que hoy hablamos sobre la accesibilidad. Hablamos sobre por qué es importante y algunas historias de éxito sobre cómo Ember pudo lograrlo, cómo otros marcos de trabajo también están comenzando a hacerlo. Hablamos sobre hacer de la accesibilidad una prioridad en tu lugar de trabajo o tu comunidad. Eso puede significar un marco de trabajo por el que tienes mucha pasión, o puede significar el equipo con el que trabajas en tu trabajo de 9 a 5. También hablamos sobre algunas herramientas AXe que están disponibles para prácticamente cualquier entorno, y si no está disponible para el tuyo, está Axe-Core. Puede que seas la persona que cree ese nuevo paquete de NPM que está impulsado por Axe-Core para crear algo maravilloso

Mientras me acompañas en el escenario, el grupo que dice que no está seguro por dónde empezar está tomando la delantera. Esa será mi primera pregunta para ti cuando entremos en nuestra sesión de preguntas y respuestas. ¿Por dónde empiezo? Quiero saber más. ¿Por dónde empiezo? Absolutamente. Espero que esta charla haya podido brindar un poco de eso. Pero el punto de partida es hablar con alguien de tu equipo. Nuevamente, ya sea en un trabajo de 9 a 5 o en algún proyecto personal en el que tal vez solo estés tú o estés con tus amigos o algo de open-source. No importa. Simplemente habla con las personas. Haz que sea importante. Registra algunos problemas. Simplemente di algo como, hey, no creo que esto funcione para alguien que usa un lector de pantalla. Registra esos problemas. Comienza a hablar al respecto. En cuanto a tomar medidas significativas y hacer algo de código, básicamente, comienza con tu herramienta principal o tu marco de trabajo, seguido de accessibility o Axe, encontrarás estas herramientas que describí y algunas otras herramientas a las que no tuve la oportunidad de mencionar, como las de Angular, por ejemplo.

Eso está bien. De hecho, alguien preguntó si las herramientas de ember eran imprescindibles, o si hay alguna alternativa a las herramientas de ember. Puedo ver un poco de ember detrás de ti, así que sé que eres fan de ember. Sí. Culpable como acusado. He estado usando ember durante demasiados años, y junto con eso, me he dado cuenta de que tengo algunas historias de éxito para compartir, algunas cosas de las que estoy realmente orgulloso, pero lo que realmente quiero compartir es cómo

No tenemos que preocuparnos por la movilidad. Y luego, con el tiempo, nos dimos cuenta de que eso no era cierto. Es cierto que necesitamos la movilidad para casi todo.

Por último, quiero decir que si puedes contratar personas que sean diferentes a ti, eso fue lo último que dije al final de esa charla, terminarás teniendo aún más personas con perspectivas diferentes, con diferentes necesidades, deseos e influencias. Y de repente podrías darte cuenta de que tu cultura cambiará ante tus propios ojos. Me encanta eso. Me encanta esa parte sobre la cultura. Creo que es una pieza realmente importante de donde comienza esta conversación, porque es una de esas conversaciones que esperas que nunca surja porque estás haciendo lo correcto.

Gracias, Eva, por la sesión de preguntas y respuestas y por tus reflexiones. Fue realmente bueno. Creo que respondí el 20 por ciento de tus preguntas. Así que aquellos que tenían preguntas a las que no pude responder, por favor únanse a Ava en la sala de conferencias en spatial chat. El enlace para unirse está en la misma línea de tiempo para obtener respuestas a todas sus preguntas.