A11y Más allá de la teoría: Integrando las pruebas de accesibilidad en tu flujo de trabajo

Rate this content
Bookmark

Una mirada práctica a la automatización de las pruebas de accesibilidad básicas e integrándolas en tu flujo de trabajo.

24 min
15 Nov, 2023

AI Generated Video Summary

Ntandala Kengose, un desarrollador de software, enfatiza la importancia de la accesibilidad en el desarrollo de software y la responsabilidad que conlleva. Las Directrices de Accesibilidad para el Contenido Web (WCAG) proporcionan directrices técnicas para hacer el contenido web más accesible. Ntandala comparte varias herramientas de prueba de accesibilidad y destaca la necesidad de automatización en las pruebas. Herramientas como Pelly CI y GitHub Actions se pueden utilizar para pruebas de accesibilidad automatizadas e integración de CI. El X-Accessibility Ginter y Husky son herramientas que proporcionan información y garantizan la accesibilidad en el desarrollo.

1. Introducción a Ntandala Kengose

Short description:

Hola a todos. Mi nombre es Ntandala Kengose. Soy un desarrollador de software de Johannesburgo, Sudáfrica. Trabajo para PbD, una firma global de desarrollo de software. Soy parte de la unidad ATC, responsable de consultoría especializada y formación. Sígueme en Twitter en unlikely underscore.

Hola a todos. Mi nombre es Ntandala Kengose. Soy un desarrollador de software, entre muchas otras personas. Estoy dando esta charla desde la hermosa ciudad de Johannesburgo, donde nací, crecí, y vivo hasta hoy. Ahora, si no tienes idea de dónde está Johannesburgo, es una gran ciudad, no la capital, pero definitivamente el centro económico del hermoso país conocido como Sudáfrica. Y si no estás completamente seguro de dónde está Sudáfrica, bueno, es simple. Está en el para mirarlo. Estamos en el extremo sur del hermoso continente de África. Ahora, esto debería mostrarte que cuando dijeron que algunas de las cosas más difíciles en ciencias de la computación es nombrar cosas, definitivamente no pensaron en los sudafricanos, porque claramente somos realmente buenos en esto. Como dije, soy ingeniero de software, y trabajo para una compañía llamada PbD. Y de nuevo, porque somos buenos nombrando cosas, PbD representa a los fundadores. Ahora, PbD comenzó hace unos treinta y nueve años, justo aquí en Sudáfrica por tres ingenieros. Y ahora hemos crecido hasta ser una firma global de desarrollo de software a medida con probablemente unos mil doscientos profesionales repartidos en siete ciudades de todo el mundo. Entregamos soluciones de software a medida en varios sectores. Pero mi trabajo es ligeramente diferente al de todos los demás en PbD. Eso es porque trabajo en una unidad que llamamos ATC. En papel somos responsables de varias cosas, como lo que llamamos consultoría especializada. Somos responsables de formar a los más de 1000 empleados de PbD. Somos responsables también de hacer compromisos con la community y un montón de otras cosas que son bastante interesantes. Me encanta la community. Y para alimentar esta pasión, también estoy involucrado con varios meetups en Johannesburgo. Nada de esto importa. Lo más importante que debes saber sobre mí es que mi nombre en Twitter, X, es unlikely underscore. Por favor, siéntete libre de seguirme, déjame saber lo que piensas de esta charla. Permíteme entrar directamente en ello. Cumplí 32 días antes de la grabación de este video. Ahora, con esta nueva edad, me he dado cuenta de que necesito empezar a cuidarme un poco mejor. Necesito volver a ponerme en forma y tratar de cuidar mi salud y lo que como. Así que un amigo mío sugirió fuertemente que intentara el

2. La Importancia de la Accesibilidad

Short description:

Me lesioné la rodilla mientras jugaba al fútbol y me hizo darme cuenta de la importancia de la accesibilidad. Experimenté una discapacidad temporal y luché con diseños inaccesibles. La responsabilidad de la accesibilidad recae en todos los involucrados en el ciclo de vida del desarrollo de software. No es suficiente que las soluciones funcionen en una máquina. La accesibilidad afecta los resultados finales.

gimnasio. Ahora, hay un par de problemas con el gimnasio. Eso es porque puede ser bastante intimidante cuando entras y ves todo el equipo pesado y algunas de las cosas que la gente está haciendo pueden ser desalentadoras. Así que decidí volver a las cosas que realmente disfruto, que son los deportes, dos deportes en particular, más bien, a saber, el fútbol y el soccer. Y no, no lo digo así, lo digo más así porque parezco ser realmente, realmente propenso a las lesiones.

Juego dos deportes, uno en el que los jugadores son conocidos por fingir sus lesiones, y el otro en el que los jinetes son realmente conocidos por tratar de evitar sus lesiones y volver a montar en su caballo. Así que haz una suposición salvaje sobre cuál de estos dos deportes terminó o resultó en que tuviera esta rodillera en mi rodilla durante más de tres meses. Es el soccer. Tuve un pequeño incidente, y terminé dañando mi rodilla. Ahora, algo interesante empezó a suceder después de esta lesión. Empecé a estar muy, muy gruñón. Mis amigos decían que era simplemente la vejez que se acercaba, pero me di cuenta de que estaba pasando algo más. Estaba empezando a experimentar el mundo como nunca antes. Lo estaba experimentando como alguien que no podía caminar tanto como normalmente lo hago, y me di cuenta de que en realidad estaba experimentando una discapacidad temporal y que esto estaba haciendo que los diseños inaccesibles a mi alrededor fueran mucho más claros. Y todas esas cosas ahora empezaban a afectarme y a frustrarme. Y lo primero que realmente, realmente, realmente me enfureció fue el centro comercial. Vivo a una cuadra de uno, y siempre he pensado que tenía estacionamiento alrededor y era una gran experiencia para ir. Lo odiaba porque cuando la gente piensa en accessibility, todo lo que piensan es en rampas. Y encontré estas rampas por todas partes, y no sé si alguna vez lo has intentado, pero caminar con muletas en una rampa es realmente, realmente difícil. Y luché mucho. Estaba tan furioso e hice lo que cualquier persona normal haría, tratar de averiguar de quién es la responsabilidad. Y ahora que me enfrentaba a mis propias limitaciones físicas e intentaba averiguar a quién culpar, se me ocurrió. Empecé a reflexionar sobre de quién es la responsabilidad de asegurar que las soluciones que construimos sean tan accesibles para tantas personas como sea posible. Y para responder a esto, creo que solo necesitamos una definición de trabajo común rápida de lo que entendemos por accessibility. Bueno, en primer lugar, A11Y es un numerónimo donde el 11 representa las 11 letras en la palabra accessibility. Y los principales diccionarios realmente gravitan hacia esta definición general, donde definen accessibility como la calidad de ser fácilmente alcanzado, entrado o utilizado por personas que tienen una discapacidad. Si acercamos nuestro enfoque mucho más a casa, vemos que la accessibility web significa que los sitios web, las herramientas y las tecnologías están diseñados y desarrollados para que las personas con discapacidades puedan utilizarlos. Más específicamente, que siguen los principios de PAW, lo que significa que las personas pueden percibirlos, entender, navegar e interactuar con la web que construimos. Así que para simplemente responder a la pregunta, la respuesta es que es responsabilidad de todos los que están involucrados en el ciclo de vida del desarrollo de software. Hemos acordado desde hace tiempo que funciona en mi máquina simplemente no es suficiente. Así que siempre me he preguntado por qué estamos tan cómodos con el envío de soluciones que funcionan para algunas personas y no necesariamente para otras. Y cada vez que he participado en conversaciones sobre accessibility, a menudo se trata como algo agradable de tener, pero lo que no nos damos cuenta es que en realidad afecta los resultados finales.

3. Directrices de Accesibilidad del Contenido Web

Short description:

La inaccesibilidad cuesta a las empresas cantidades significativas de dinero. Las Directrices de Accesibilidad del Contenido Web (WCAG) son un conjunto de directrices técnicas destinadas a hacer que el contenido web sea más accesible. Tienen 13 directrices que se engloban en cuatro principios fundamentales. Hay tres niveles de conformidad: A, AA y AAA. Los desafíos comunes de accesibilidad son a menudo los más fáciles de solucionar.

La inaccesibilidad cuesta a las empresas cantidades significativas de dinero. Y quiero decir, también estamos viendo que se convierte en un requisito legal en todo el mundo. Así que el W3C ha elaborado algo que llamaron las Directrices de Accessibility del Contenido Web o WCAG por sus siglas en inglés. Ahora bien, este es un conjunto de directrices técnicas que tienen como objetivo hacer que el contenido web sea más accesible para las personas con discapacidades. Efectivamente tiene 13 directrices, a partir de la versión 2.1. Y las directrices se engloban en cuatro principios fundamentales, es decir, que están destinadas a asegurar que las cosas sean perceptibles, operables, comprensibles y, por supuesto, robustas. Tener directrices y principios es una cosa, también necesitamos ser capaces de medir el éxito. Necesitamos ser capaces de describir cuán bien nos ajustamos a estas directrices. Y para esto, tenemos tres niveles de conformidad realmente, realmente simples. A saber, A, AA y AAA, que van desde cosas simples y muy comunes como la falta de texto alternativo, la accessibility del teclado, hasta el otro extremo del espectro complejo, donde esos problemas están más relacionados con el contenido y la comprensión de nuestros usuarios. Lo interesante es que si echas un vistazo a algunos de los desafíos más comunes, a menudo son los más fáciles de solucionar. Así que cosas como la falta de texto alternativo, formularios inaccesibles y cosas como el pobre contraste de colores pueden ser analizados de manera bastante programática. Incluso la falta de accessibility del teclado sigue siendo uno de los problemas de accessibility más comunes que se encuentran en la web. Y, quiero decir, hace tiempo que vemos que los atajos de teclado o el uso de esos atajos pueden mejorar la productivity

4. Herramientas de Pruebas de Accesibilidad

Short description:

Recientemente tuve una conversación con un colega senior que compartió una historia sobre un cliente que se molestó cuando las pruebas de accesibilidad causaron retrasos. Esto me hizo darme cuenta de la necesidad de equipar a las personas con herramientas y conocimientos prácticos. Comencé a buscar herramientas de pruebas de accesibilidad y encontré la Lista de Herramientas de Evaluación de Accesibilidad Web, que ofrece una amplia gama de filtros. En esta charla, compartiré algunas de mis herramientas de pruebas de accesibilidad favoritas, comenzando con Lighthouse y Wave.

de manera significativa. Recientemente tuve una conversación con uno de mis colegas senior y me contó sobre cómo una vez tuvimos un cliente y parte de nuestro servicio era que garantizábamos a este cliente de servicio público que seríamos capaces de tener a alguien para probar la solución para asegurarnos de que es accesible. Me contó una historia sobre cómo, porque tenían a esta persona, una persona ciega, usando el sistema. Muchas veces cuando fallaba, el cliente se molestaba bastante por el tiempo que estábamos añadiendo al proceso. Y me di cuenta de algo crucial en lo que dijo. Para una solución de software tan masiva, tenían a una sola persona y simplemente le decían, dime si puedes usar esto. A menudo lanzaban muchas de estas soluciones sin pasar las medidas de aseguramiento de calidad porque estaban persiguiendo plazos. Luego me di cuenta de que realmente necesitamos equipar a las personas que están involucradas con las herramientas que existen para poner las herramientas que pueden educarlas sobre lo que necesita hacerse y cómo implementar estas cosas. Pero, ¿por dónde empezamos con esto? Soy una persona práctica por lo que no creo en simplemente enviar a las personas a una sesión de formación o una masterclass. Creo que necesitamos hacer más y tiene que ser en la práctica. Y para esto, la practicidad es clave.

Así que empecé a buscar un par de soluciones, y efectivamente, esta misión era para encontrar herramientas de pruebas de accesibilidad para todos con los que trabajo. Empecé con algunas de mis personas favoritas como desarrollador. Ingenieros de QA, analistas de pruebas. Vienen en muchas formas, formas, y nombres, pero todos sabemos que son la peor pesadilla de un desarrollador. Ahora, cuando hablo de ingenieros de QA, me refiero a los probadores manuales, por ejemplo. Lo que encontré es que existe algo llamado la Lista de Herramientas de Evaluación de Accesibilidad Web. Me encanta este sitio web, porque en el panel de la izquierda también te da la capacidad de filtrar qué tipo de herramientas hay basadas en las directrices que quieres seguir, el requisito legal, o el tipo de preocupación de accesibilidad que estás tratando de abordar. Ahora esta lista de herramientas tiene más de 100 herramientas, porque todavía estamos en la web y obtenemos una herramienta cada minuto, pero los filtros son realmente impresionantes. Así que efectivamente, el resto de esta charla va a ser yo contándote sobre una lista de algunas de mis herramientas de pruebas de accesibilidad favoritas. Pero para hacer esto, necesitamos un sitio web. Pensé en usar el sitio web de React US, pero luego me di cuenta de que realmente quiero que me inviten de nuevo a esta conferencia la próxima vez. Así que encontré este sitio web de prueba, se llama el Club de Misterios Médicos. Fue construido por el equipo de DevTools de Chrome y lo construyeron con una advertencia diciendo que esta página fue deliberadamente hecha inaccesible para los propósitos de la demo, lo cual es bastante genial. Puedes revisar el sitio, hay un code pen para ello y aquí lo estoy ejecutando en modo debug. Hablando del equipo de Chrome, mi primera herramienta es Lighthouse. Lighthouse es una herramienta realmente, realmente genial y viene incluida con el navegador Chrome. Y esta herramienta es bastante común, simplemente necesitas hacer un clic en analizar prueba en tus herramientas de desarrollo y debería ser capaz de darte un buen desglose de algunos de los problemas de accesibilidad. Ahora, Lighthouse se usa a menudo para otras cosas también como SEO y rendimiento, por lo que no me voy a extender mucho en ello porque entiendo que mucha gente lo habrá visto. Te mostraré herramientas similares en su lugar. La primera se llama Wave, que significa la Accesibilidad Web

5. Continuación de las Herramientas de Pruebas de Accesibilidad

Short description:

Ahora, esta es una extensión de navegador que anota la pantalla, mostrándote problemas con iconos. XDevTools es una herramienta similar de pago. Para los gestores de proyectos, Pally es una herramienta de código abierto que proporciona resúmenes de problemas de accesibilidad. Se puede utilizar en la línea de comandos o en una aplicación de nodo. El Tablero de Peli te permite seguir el progreso y las transiciones a lo largo del tiempo. Es crucial interceptar los problemas de accesibilidad a nivel de desarrollador, y la automatización es la solución.

Herramienta de Evaluación Web. Ahora, esta es una extensión de navegador y una vez que la has añadido, realmente anota la pantalla que tienes delante de ti, por lo que pondrá todos estos pequeños iconos para mostrarte realmente cuáles son estos problemas. Lo que me gusta de esto es que cuando vas en detalle sobre lo que realmente está mal ahí, es capaz de mostrarte cosas como el bajo contraste de color e incluso ayudarte a averiguar qué color es el mejor en ese punto.

Otra herramienta bastante similar a Lighthouse se llama XDevTools. Ahora, XDevTools también se añade en tus Herramientas de Desarrollo como una pestaña. También simplemente haces clic en Analizar, y te dará un desglose de todos los problemas que hay. Una cosa a tener en cuenta, sin embargo, es que esto es de pago, y para cuando empecé a preparar esta charla, ya había agotado mi licencia de prueba. Lo importante para mí aquí es que quería algo que pueda usar para todos con los que trabajo.

Busqué y encontré algo para los gestores de proyectos. Cuando estás gestionando un proyecto, no estás necesariamente interesado en los detalles muy minuciosos, sino más bien en resúmenes de las cosas que están sucediendo. Para esto, encontré una de mis herramientas favoritas llamada Pally, el archivo de pruebas de accesibilidad automatizado. Ahora, Pally es una herramienta de código abierto que ayuda a los desarrolladores y a los probadores a identificar estos problemas de accesibilidad en páginas web y aplicaciones. Se puede encontrar en npm, por supuesto. Cuando echamos un vistazo a esto, vemos que puede ejecutarse en la línea de comandos o puede usarse en tu propia solución en una aplicación de nodo. Lo que eso parece es que simplemente lo importarías, y le proporcionarías la URL. Iría y rastrearía esa página web y te devolvería esos resultados. Luego puedes hacer lo que quieras.

Aquí, si vamos y reemplazamos nuestro sitio web de pruebas con el CodePen para el Club de Misterios Médicos, vemos que si vamos e imprimimos esos resultados, esto es lo que empieza a parecer. Lo que me gusta de esto es que te dice qué principio o qué directrices estás violando. Es capaz de mostrarte un mensaje legible por humanos. Te da el contexto de dónde vino realmente el problema, e incluso el selector HTML. Ahora, esto es realmente interesante. Me di cuenta de que estoy en algo aquí, pero soy un desarrollador web. Tan pronto como empiezo a pensar que estoy construyendo algo muy útil, sé que necesito parar porque lo más probable es que alguien más probablemente haya construido algo similar a mí. Para esto, encontré el Tablero de Peli. Ahora este Tablero de Peli, puedes configurar las URLs que quieres ir a ver, para que puedas ver tus transiciones a lo largo del tiempo. Esto es absolutamente genial si estás haciendo una aplicación ya existente más accesible porque puedes seguir tu progreso y el progreso de tu equipo a lo largo del tiempo. Pero por supuesto, si la única vez que identificas problemas de accesibilidad es en producción, entonces es realmente, realmente demasiado tarde. Generalmente quieres interceptar estos problemas a nivel de desarrollador. Quieres guiar a tus desarrolladores para resolver estos problemas mientras están construyendo. Pero, ¿cómo haces esto? Bueno, automatizamos esto.

6. Pruebas de Accesibilidad Automatizadas e Integración CI

Short description:

Automatizar las pruebas de accesibilidad y bloquear las solicitudes de extracción si fallan es crucial. Para lograr esto, podemos usar herramientas como Pelly CI y GitHub Actions. Pelly CI es un ejecutor de pruebas de accesibilidad centrado en la integración continua, mientras que GitHub Actions es una tubería de CI-CD ampliamente utilizada. En términos de configuración de pruebas, Mocha, Jasmine y Jest son herramientas populares para la ejecución de pruebas, la afirmación y la representación del navegador. Jest, en particular, es un marco de pruebas de JavaScript encantador que simplifica el proceso.

Automatiza la parte de testing de esto. Por supuesto, los desarrolladores son nuevos en testing. Todos escribimos código que hemos probado a fondo. Como desarrollador yo mismo, no es que no confíe en los ingenieros que trabajan en mi proyecto. Pero más bien porque soy ingeniero, sé que a veces simplemente te olvidas de construir y ejecutar tus pruebas. He aprendido que la mejor manera de conseguir que los desarrolladores se ajusten a estos standards es simplemente bloquear las solicitudes de extracción si no está lo correcto en ellas.

Efectivamente, necesitamos automatizar esta accessibility testing y luego bloquear las solicitudes de extracción si fallan. Si tu ciclo de trabajo se parece a esto, donde haces algunos cambios de código, los envías a algún servidor y creas una solicitud para fusionar cambios en tu rama principal y luego los fusionas. Pero esto significaría que tendríamos que insertar un paso más, para simplemente comprobar si el componente que has añadido o el código que has añadido es accesible. Lo que eso parece es bastante similar a la parte manual es que tendríamos que iniciar un servidor, lanzar un navegador, ir a localhost. No tengo idea de por qué hay un pollo ahí. Tendríamos que esperar a que se cargue, y luego, una vez que se ha cargado, tendríamos que ejecutar nuestra herramienta Pelly.

Para hacer esto, porque ahora esto necesita suceder en la línea de comandos, encontré Pelly CI, que es un ejecutor de pruebas de accessibility que está construido con Pelly bajo el capó. Pero este en particular está centrado en ejecutarse en un entorno de integración continua. Esto es particularmente importante porque no queremos simplemente obtener resultados de lo que está roto. También queremos romper la construcción en sí para que no permitamos que se fusione. Poniendo esto en acción, elegí ir con GitHub Actions, porque es probablemente uno de los pipelines de CI-CD más comúnmente utilizados. GitHub Action automatiza tareas en el flujo de trabajo de desarrollo, lo que significa que podemos personalizar cómo hacemos esto. Todo lo que acabo de describir, tenemos que ponerlo en nuestra configuración de pipeline de CI.

Pero ahora si hablamos de testing, una configuración típica de testing se vería así. Necesitarías un ejecutor de pruebas. Ejemplos de esto son Mocha y Jasmine. Necesitas una biblioteca de afirmaciones que defina tu lógica de testing. Esto dice que espero que A salga como B bajo estas condiciones. Luego, porque estamos hablando de cosas que realmente necesitan ser renderizadas, también necesitamos un navegador. Ahora, una de mis herramientas favoritas porque la uso en todo tipo de proyectos es Jest. Jest se sitúa justo en medio de esos dos. Es tanto un ejecutor de pruebas como una biblioteca de afirmaciones. Lo describen como un marco de pruebas de JavaScript encantador que se centra en la simplicidad. Lo que eso parece es que si tienes una función llamada sum, simplemente escribirías una prueba que dice, esperamos que la suma de estas cosas sea dos o sea este resultado.

7. Pruebas y Configuración

Short description:

Si una prueba falla, se puede utilizar para bloquear la construcción. Gistx ayuda a reemplazar las funciones con pruebas de componentes. Proporciona información sobre las reglas violadas y ofrece opciones de configuración. Los desarrolladores necesitan orientación y coaching durante el desarrollo.

Si falla, como ves aquí, dije que espero que la suma de uno y dos sea seis, lo cual sabemos que es incorrecto. Así es como se vería el error y te dice que una de tus pruebas falla, lo que significa que puedes bloquear la construcción con esto.

Luego me di cuenta de que podemos usar gist con algo llamado gistx. X es otro motor de reglas centrales que te ayuda a descubrir problemas de accessibility. Una vez que empezamos a usarlo así, somos capaces de reemplazar la función con una representación de un componente simple que queremos probar porque no siempre podemos estar testing páginas enteras. A veces queremos probar un pequeño componente de lo que estamos construyendo.

Vemos que una vez que lo pasamos allí y le pedimos al corredor de gistx que lo pruebe por nosotros, es capaz de decirnos qué reglas hemos violado. Pero si miras este, dice que todo el contenido de la página debe estar contenido por puntos de referencia. Esto es genial y cierto para las páginas completas, pero no necesariamente siempre es el caso en componentes más pequeños que siempre existirán en páginas más grandes. Lo que significa que necesitamos una forma de configurar estas cosas, lo cual es realmente, realmente genial. Verás que también te dice qué arreglar y te da un enlace a las directrices de la Universidad Deque sobre cómo funciona esto realmente. Para configurarlo, es agradable y simple. Podemos habilitar las diferentes reglas para componentes aislados o para nuestros diferentes casos de prueba porque sabemos que nunca podemos tener una única solución para todos. Pero de nuevo, esto es una guía, o esto es una guardia que ponemos cuando los desarrolladores están construyendo. Lo que realmente queremos hacer es acercarnos aún más al desarrollador y ayudar a guiarlos y entrenarlos mientras están trabajando realmente.

8. X-Accessibility Ginter y Husky

Short description:

El X-Accessibility Ginter proporciona tooltips sobre por qué se marcan los problemas y cómo solucionarlos. Husky es una herramienta de GitHub que ejecuta pruebas en el commit para garantizar la accesibilidad. Incluso puede bloquear los commits hasta que se resuelvan los problemas de accesibilidad.

Para esto, está el X-Accessibility Ginter. Proporciona tooltips sobre por qué se marcan los problemas, por qué se consideran problemas e incluso cómo solucionarlos. Para molestar un poco más a mi equipo, también encontré Husky, que es un hermoso GitHub que te permite ejecutar estas pruebas en el commit. No solo estamos deteniendo a los desarrolladores de fusionar, pero si realmente quiero molestar al equipo, configuraré esto para detener sus commits para que ellos no hagan commit de nada hasta que se aseguren de que es accesible. Lo que parece es que una vez que intentas hacer un commit, te dirá que hay un problema aquí y por eso las cosas están fallando. Ahora, hemos discutido bastante. Hemos hablado de herramientas que podemos usar para monitorear, y usamos Peli con Node. Hicimos esto para construir un tablero hasta que descubrimos que Peli tenía su propio tablero. Miramos algunas herramientas de testing más o menos manuales, como Lighthouse, XTools y Wave. Luego comenzamos a mirar la parte de testing automatizada, donde podemos usar Peli CI como guardián de nuestras ramas principales. Miramos cómo podríamos usar Jest X para ejecutarlos localmente y a nivel de componente. También vimos a Husky sobre cómo usar GitHooks para asegurarnos de que podemos ejecutar esas pruebas cada vez que hacemos comandos Git específicos. Pero todo esto hasta ahora excluyó una parte muy importante de nuestro equipo, que son los diseñadores. Ellos eligen los colores más a menudo que no, y muchas de sus decisiones tienen un gran impacto en la accessibility. Para esto, también tienen una serie de herramientas que son construidas por las increíbles Universidades Deque. Tienen el mismo motor X que impulsa la tooling en ese espacio también. Con esto, significa que cada persona que está involucrada en los ciclos de vida de desarrollo de software, ya sean los desarrolladores, los diseñadores, los analistas de negocios, todos tienen las herramientas que hablan el mismo idioma. Pero estaría equivocado si no menciono o advierto a todos sobre esto, y eso es el hecho de que el testing automatizado tiene sus limitaciones. Solo alrededor del 30-40 por ciento de los problemas de accessibility pueden ser detectados programáticamente. Creo que Deque, en este momento, estima más del 67 por ciento, lo que muestra que las cosas están mejorando. Es propenso a falsos negativos y falsos positivos, y para mí, lo más importante es que carece de contexto, lo que significa que necesitas poder configurarlo tú mismo para hacerlo valioso para tu espacio. Por supuesto, esto tiene una gran incapacidad para probar la user experience, por lo que no lo reemplaza. Cerraré citando a un filósofo moderno, Chatjipiti, quien dijo, ''Es importante recordar que el testing automatizado debe usarse en conjunción con el testing manual, y el testing de usuarios en particular para garantizar el nivel más alto de accessibility.'' Te dejo con eso. Mi nombre es Ntlantala Kinkosi. Muchas gracias. No dudes en decirme qué piensas de esta charla. Gracias. Adiós.

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

DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Atomic Deployment for JS Hipsters
Deploying an app is all but an easy process. You will encounter a lot of glitches and pain points to solve to have it working properly. The worst is: that now that you can deploy your app in production, how can't you also deploy all branches in the project to get access to live previews? And be able to do a fast-revert on-demand?Fortunately, the classic DevOps toolkit has all you need to achieve it without compromising your mental health. By expertly mixing Git, Unix tools, and API calls, and orchestrating all of them with JavaScript, you'll master the secret of safe atomic deployments.No more need to rely on commercial services: become the perfect tool master and netlifize your app right at home!
TestJS Summit 2021TestJS Summit 2021
36 min
Effective Performance Testing to your Server with Autocannon
Performance testing expertise that is developed for a long time. In order to measure your server performance you need a tool that can efficiently simulate a lot of abilities and give you good measurements according your analysing criteria.Autocannon NPM library gave me exactly that - that library is super easy to install and has a very simple API to work with. Within a really short amount of time you can start do performance testing to your application and get good measurements in development environment and in your performance labs, and generate complicated testing scenarios.In this talk I will introduce Autocannon, explain how to efficiently analyse your server performance with it, and show how it helped me to understand complicated performance issues in my Node.js servers. At the end of this lecture, developers will be able to have the ability to integrate a fast and easy tool in order to measure your server performance.
TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.
TestJS Summit 2022TestJS Summit 2022
21 min
Delightful Integration Tests With Testcontainers
Dockerized services are an excellent tool for creating repeatable, isolated environments ideal for integration tests. In this session, we'll look at the Testcontainers libraries which provide flexible and intuitive API for programmatically controlling lifecycle of your service dependencies in Docker containers. Running databases, Kafka, Elasticsearch, and even cloud technologies, straight from your test code ensures environment config is always up-to-date and consistent during local development and in CI pipelines.You’ll learn everything necessary to start adding powerful integration tests to your codebase without the headache of managing external service dependencies manually!

Workshops on related topic

React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
Workshop
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Workshop
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)
TestJS Summit 2022TestJS Summit 2022
163 min
Automated Testing Using WebdriverIO
Workshop
In this workshop, I cover not only what WebdriverIO can do, but also how you'll be using it day-to-day. I've built the exercises around real-world scenarios that demonstrate how you would actually set things up. It's not just "what to do," but specifically "how to get there." We'll cover the fundamentals of Automated UI testing so you can write maintainable, useful tests for your website and/or web app.
TestJS Summit 2021TestJS Summit 2021
111 min
JS Security Testing Automation for Developers on Every Build
WorkshopFree
As a developer, you need to deliver fast, and you simply don't have the time to constantly think about security. Still, if something goes wrong it's your job to fix it, but security testing blocks your automation, creates bottlenecks and just delays releases...but it doesn't have to...

NeuraLegion's developer-first Dynamic Application Security Testing (DAST) scanner enables developers to detect, prioritise and remediate security issues EARLY, on every commit, with NO false positives/alerts, without slowing you down.

Join this workshop to learn different ways developers can access Nexploit & start scanning without leaving the terminal!

We will be going through the set up end-to-end, whilst setting up a pipeline, running security tests and looking at the results.

Table of contents:
- What developer-first DAST (Dynamic Application Security Testing) actually is and how it works
- See where and how a modern, accurate dev-first DAST fits in the CI/CD
- Integrate NeuraLegion's Nexploit scanner with GitHub Actions
- Understand how modern applications, APIs and authentication mechanisms can be tested
- Fork a repo, set up a pipeline, run security tests and look at the results
GraphQL Galaxy 2021GraphQL Galaxy 2021
82 min
Security Testing Automation for Developers on Every Build
WorkshopFree
As a developer, you need to deliver fast, and you simply don't have the time to constantly think about security. Still, if something goes wrong it's your job to fix it, but security testing blocks your automation, creates bottlenecks and just delays releases, especially with graphQL...but it doesn't have to...

NeuraLegion's developer-first Dynamic Application Security Testing (DAST) scanner enables developers to detect, prioritise and remediate security issues EARLY, on every commit, with NO false positives / alerts, without slowing you down.

Join this workshop to learn different ways developers can access NeuraLegion's DAST scanner & start scanning without leaving the terminal!

We will be going through the set up end-to-end, whilst setting up a pipeline for a vulnerable GraphQL target, running security tests and looking at the results.

Table of contents:
- What developer-first DAST (Dynamic Application Security Testing) actually is and how it works
- See where and how a modern, accurate dev-first DAST fits in the CI/CD
- Integrate NeuraLegion's scanner with GitHub Actions
- Understand how modern applications, GraphQL and other APIs and authentication mechanisms can be tested
- Fork a repo, set up a pipeline, run security tests and look at the results