Logrando pruebas de automatización de A11y

Rate this content
Bookmark

Las pruebas de accesibilidad han avanzado mucho en los últimos años. Nos sumergiremos en cómo EmberJS priorizó A11y con RFC significativos, complementos, herramientas y documentación. Lo más importante, discutiremos cómo estos éxitos se pueden aplicar a tus propias aplicaciones, ya sean Vue, React, Angular o cualquier otra cosa.

27 min
15 Jun, 2021

Video Summary and Transcription

Esta Charla discute herramientas y estrategias de pruebas de automatización para la accesibilidad. Destaca el enfoque de EmberJS hacia la accesibilidad y los esfuerzos de la comunidad de desarrolladores. Se enfatiza la importancia de priorizar la accesibilidad y utilizar herramientas como Ember A11y testing y Axe-Core. La integración con React, Vue y otros frameworks se facilita con paquetes de NPM. La Charla también enfatiza el valor de las pruebas manuales y la evaluación de usuarios junto con las pruebas de automatización.

Available in English

1. Introducción a las pruebas de automatización de accesibilidad

Short description:

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

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.

2. Facilitando la accesibilidad

Short description:

La accesibilidad no tiene por qué ser difícil. Comenzar, sumergirse y hacer que suceda no tiene por qué ser difícil. Se puede automatizar y facilitar su trabajo.

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.

3. Enfoque de EmberJS hacia la accesibilidad

Short description:

EmberJS adoptó la accesibilidad a través del soporte central y los esfuerzos del desarrollador Melanie Sumner. Se formó un grupo de trabajo de accesibilidad para abordar las dificultades existentes, con discusiones y registro de problemas en GitHub y Discord. La comunidad trabajó en resolver problemas, crear guías y documentación. EmberJS también tiene una organización específica de accesibilidad en GitHub y complementos para ampliar el trabajo de accesibilidad. Algunas mejoras se incorporaron al marco central de Ember. Dos herramientas principales para las pruebas de accesibilidad son Ember A11y testing para pruebas automatizadas y auditorías de accesibilidad.

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.

4. Herramientas y Estrategias de Pruebas de Accesibilidad

Short description:

Las herramientas de pruebas de automatización como Ember template Lint y Axe-Core pueden ayudar a garantizar la accesibilidad en tu código. Priorizar la accesibilidad es crucial y se puede lograr al discutirlo en tu lugar de trabajo, probar cosas nuevas y contribuir a proyectos de código abierto. Axe-Core, un paquete de NPM, es una herramienta poderosa para detectar violaciones de accesibilidad. Cubre una parte significativa de las reglas de accesibilidad y se puede integrar fácilmente en tu proceso de desarrollo. La extensión del navegador y la integración con frameworks hacen que las pruebas de accesibilidad sean aún más convenientes.

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.

5. Integración con React y Vue

Short description:

Si estás utilizando React o Vue, es tan simple como instalar un paquete de NPM. Vue usa, Vue actúa y listo. Las integraciones del framework se encargan de la tarea pesada de eliminar las advertencias duplicadas y volver a verificar de manera inteligente las nuevas advertencias.

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.

6. Linting, Automatización y Marcos de Pruebas

Short description:

Los complementos de ESLint para accesibilidad de Vue.js y JSXA11y proporcionan advertencias directas en tu editor de código, lo que facilita realizar ajustes y mejorar la accesibilidad. Estas herramientas para desarrolladores suelen ser gratuitas y tienen un impacto significativo en la accesibilidad de tu aplicación. Para una automatización real, puedes utilizar Axe Core conectándolo con solo axe y esperando los resultados. Esto te permite verificar la accesibilidad dentro de tu entorno de pruebas y marcos de pruebas de extremo a extremo.

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.

7. Automatización de Pruebas y Contribuciones de la Comunidad

Short description:

Existen complementos y bibliotecas disponibles para la automatización de pruebas en diferentes marcos de trabajo, como WebDriver IO y cypress axe. La comunidad de Vue A11y es un recurso prometedor para herramientas y contribuciones de accesibilidad. Si bien las pruebas automatizadas son valiosas, deben verse como una mejora, no como un reemplazo de las pruebas manuales. Las pruebas reales de usuarios y la evaluación manual son esenciales para garantizar la usabilidad y accesibilidad. Hoy, discutimos la importancia de la accesibilidad, historias de éxito, hacer de ella una prioridad y la disponibilidad de las herramientas AXe.

Herramientas de pruebas en frameworks. Por lo tanto, cosas que están ligeramente separadas del propio framework y que están representando URL completas, tal vez en un entorno de preparación o un entorno de QA, por ejemplo, tal vez WebDriver IO. Hay un complemento para eso, axe core WebDriver JS. O si estás utilizando cypress axe, hay una maravillosa biblioteca para cypress. Y es tan fácil como esto. No estoy recortando mucho código en estas diapositivas. Es tan simple.

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

8. Dejar una Solicitud Personal y Comenzar

Short description:

Finalmente, quiero dejarte con una solicitud personal para que contrates a alguien diferente a ti si tienes los medios para hacerlo. Tu equipo, empresa, futuros empleados, usuarios y yo te lo agradeceremos. ¿Por dónde empiezo? Habla con alguien de tu equipo, ya sea en un trabajo de 9 a 5 o en un proyecto personal. Haz que sea importante, registra problemas y comienza a hablar sobre accesibilidad. Comienza con tu herramienta o marco principal, seguido de accesibilidad o Axe. Hay herramientas alternativas para diferentes marcos de trabajo como Angular.

suceder. Finalmente, quiero dejarte con una solicitud personal de mi parte que está indirectamente relacionada con esto, y esa solicitud es que contrates a alguien diferente a ti si tienes los medios para hacerlo. Tu equipo te lo agradecerá, tu empresa te lo agradecerá, los futuros empleados te lo agradecerán, tus usuarios terminarán agradeciéndotelo, y yo también. Quiero agradecerte por verme y acompañarme hoy. Eso es increíble. Debo decir que esperaba que los que estaban en la delantera estuvieran en la delantera, pero no esperaba que fuera tan parejo en general. Creo que mi reacción principal es que hay lugares donde es legalmente obligatorio. Las personas deben cumplir con un estándar, un nivel de calidad particular para alcanzar un nivel de accessibility, pero muchas veces está en segundo plano en mi mente. Desearía poder hacer accessibility. Esa es parte de la razón por la que quería dar esta charla.

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

9. Herramientas de Accesibilidad y Convencer a los Gerentes

Short description:

Existen herramientas disponibles para Svelte, Vue, React y Angular. Un linter puede detectar algunos problemas de accesibilidad, pero no todos. Ayuda con problemas básicos como etiquetas faltantes y texto accesible. Sin embargo, no cubrirá todos los escenarios, como la navegación por teclado. Convencer a tu gerente sobre la importancia de la accesibilidad se puede hacer utilizando argumentos similares a los de las pruebas de automatización. Es crucial enfatizar el impacto en los resultados finales y la relevancia en diferentes industrias.

Estas cosas se pueden aplicar en otros lugares. Así que espero haber mostrado algunas herramientas que se utilizan para Svelte, Vue, React y también hay otras disponibles para Angular. No quería que mis diapositivas fueran demasiado largas, pero hay herramientas disponibles para cualquier cosa que estés utilizando. Eso es bueno. Eso es realmente bueno, especialmente porque la accesibilidad es tan importante. Hay otras preguntas aquí, así que voy a responder algunas de ellas. Por ejemplo, ¿un linter sería suficiente para las pruebas básicas de accesibilidad? ¿O la mayoría de las violaciones se encuentran después de la implementación en pruebas más completas? Esa es una excelente pregunta. Para los problemas de accesibilidad, un linter detectará al menos uno de los casos, uno de los tipos de problemas que tendrás, probablemente dos casos principales. De la misma manera que un linter de JavaScript no capturará todos los errores de JavaScript, pero capturará ciertos casos de ellos. Aún así, seguirás teniendo problemas indefinidos. Por supuesto, no estamos hablando de TypeScript, pero aún te encontrarás con otros tipos de problemas en el mundo real. Tener un linter me permitirá darme cuenta de que olvidé agregar una etiqueta alrededor de mi entrada. Olvidé poner texto accesible en mi elemento de imagen. Pero no ayudará a alguien que esté intentando navegar por todo tu formulario solo con la tecla de tabulación y completar todo solo con el teclado. Eso tiene mucho sentido. Eso tiene mucho sentido. Hay muchas preguntas. No podremos responder a todas ellas. Solo quiero recordarles a todos que Ava estará en su sala de conferencias después, para que puedan hacer las preguntas que no pude responder en Spatial.chat. Mientras tanto, creo que una de las preguntas dice, ¿cómo convenzo a mi gerente de que la accesibilidad es importante? Si el argumento es que si los usuarios trabajan en un restaurante, entonces la accesibilidad no es un problema. Y creo que esta es una de las hojas más comunes que he visto. Los usuarios trabajan en algún tipo de entorno, ya sea un restaurante o cualquier otro, no es un problema. ¿Cómo convenzo a mi gerente? Hay varias respuestas a esto, pero intentaré responder rápidamente. Puedes usar argumentos similares a los que has utilizado para hacer pruebas de automatización en primer lugar. Puedes argumentar rápidamente que no tenemos tiempo para las pruebas de automatización. Sigamos enviando código, pero al final perjudica tus resultados finales. Y puedes demostrarlo matemáticamente si realmente trabajas en ello y tratas de encontrar esos argumentos. Además, este tipo de cosas se aplican a cada tipo de vertical, a cada industria diferente. Durante mucho tiempo, escuchamos que el desarrollo de aplicaciones móviles no es importante.

10. Importancia de la Movilidad y Contratación Diversa

Short description:

Nos dimos cuenta de la importancia de la movilidad con el tiempo. Contratar personas diferentes a ti mismo aporta perspectivas diversas que influyen en la cultura. La cultura es un aspecto crucial de esta conversación.

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.

Check out more articles and videos

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

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.