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

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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

This talk has been presented at React Summit US 2023, check out the latest edition of this React Conference.

FAQ

Ntandala Kengose es un desarrollador de software que nació, creció y actualmente vive en Johannesburgo, Sudáfrica.

PbD representa a los fundadores de la compañía donde trabaja Ntandala, que es una firma global de desarrollo de software a medida.

La unidad ATC en PbD es responsable de varias actividades como la consultoría especializada, la formación de más de 1000 empleados, y compromisos con la comunidad.

Ntandala Kengose practica fútbol y soccer.

Una lesión y la experiencia de una discapacidad temporal llevaron a Ntandala a darse cuenta de los diseños inaccesibles y comenzar a reflexionar sobre la responsabilidad de asegurar accesibilidad en las soluciones que construimos.

Las WCAG (Directrices de Accesibilidad del Contenido Web) son un conjunto de directrices técnicas destinadas a hacer que el contenido web sea más accesible para las personas con discapacidades.

Ntandala está involucrado con varios meetups en Johannesburgo, fomentando la interacción y el aprendizaje dentro de la comunidad de desarrolladores.

Ntandala busca implementar pruebas de accesibilidad prácticas y automatizadas a lo largo del ciclo de desarrollo de software para asegurar que las soluciones sean accesibles para todos.

Lucky Nkosi
Lucky Nkosi
24 min
15 Nov, 2023

Comments

Sign in or register to post your comment.
  • Abdulrahman Yusuf
    Abdulrahman Yusuf
    Amazing talk you had there, Lucky. I really enjoyed it and learned a ton about the tools and technologies we can use to ensure our apps are more accessible to everyone.
Video Summary and Transcription
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

Read also

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

Accesibilidad en Discord
React Advanced 2021React Advanced 2021
22 min
Accesibilidad en Discord
This Talk discusses the accessibility efforts at Discord, focusing on keyboard navigation and the challenges faced with implementing focus rings and outlines. The speaker showcases a unified focus ring system and a saturation slider to address accessibility concerns. They also highlight the implementation of role colors and the use of CSS filters for accessibility improvements. The Talk concludes with insights on runtime accessibility checking and the development of a performant core runtime system for checking accessibility issues.
Despliegue Atómico para Hipsters de JavaScript
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Despliegue Atómico para Hipsters de JavaScript
This Talk discusses atomic deployment for JavaScript and TypeScript, focusing on automated deployment processes, Git hooks, and using hard links to copy changes. The speaker demonstrates setting up a bare repository, configuring deployment variables, and using the post-receive hook to push changes to production. They also cover environment setup, branch configuration, and the build process. The Talk concludes with tips on real use cases, webhooks, and wrapping the deployment process.
Pruebas de rendimiento efectivas para su servidor con Autocannon
TestJS Summit 2021TestJS Summit 2021
36 min
Pruebas de rendimiento efectivas para su servidor con Autocannon
Top Content
Tamar is an experienced code writer and architect with expertise in Node.js. Performance testing can be confusing, but understanding terms like throughput and the 99th percentile is crucial. The 99th percentile is important for making commitments and ensuring customer satisfaction. AutoCanon is a powerful tool for simulating requests and analyzing server performance. It can be installed globally or used as a library in Node.js. Autocannon is preferred over Gatling for performance testing and can be integrated with end-to-end tests in Cypress.
Configurando las Pruebas de Accesibilidad de Axe
TestJS Summit 2021TestJS Summit 2021
30 min
Configurando las Pruebas de Accesibilidad de Axe
Top Content
AXe is an accessibility engine for automated web UI testing that runs a set of rules to test for accessibility problems. It can be configured to disable or enable specific rules and run based on tags. Axe provides various options, but axe linter does not support all options. The importance of investing time and resources in accessibility is emphasized, as it benefits not only those with disabilities but improves the web for everyone. Manual testing is also highlighted as a necessary complement to automated tests for addressing accessibility issues.
Elementos Interactivos Anidados: Una Pesadilla en Accesibilidad
React Advanced 2023React Advanced 2023
23 min
Elementos Interactivos Anidados: Una Pesadilla en Accesibilidad
Top Content
Nested interactive elements can cause accessibility issues on websites, and the speaker shares a personal experience with an accessibility bug involving a list component. Mitigating nested interactive structures involves limiting these patterns during development and restructuring existing elements. The speaker provides recommendations for improving accessibility, such as adjusting role properties and gathering user feedback. The conclusion emphasizes the importance of accessible solutions and encourages sharing resources to build more inclusive experiences.
Pruebas de integración encantadoras con Testcontainers
TestJS Summit 2022TestJS Summit 2022
21 min
Pruebas de integración encantadoras con Testcontainers
Top Content
Testing is crucial for development and production, with integration tests becoming more popular. Test containers is a library that integrates with Docker to create reliable test environments. It is flexible and can be used with various frameworks and test libraries. The IDE setup involves configuring the container and connecting it to the application. Test containers can be used for complex operations and allows running tests with real dependencies.

Workshops on related topic

Accesibilidad web para Ninjas: Un enfoque práctico para crear aplicaciones web accesibles
React Summit 2023React Summit 2023
109 min
Accesibilidad web para Ninjas: Un enfoque práctico para crear aplicaciones web accesibles
Workshop
Asaf Shochet Avida
Eitan Noy
2 authors
En este masterclass práctico, te proporcionaremos las herramientas y técnicas que necesitas para crear aplicaciones web accesibles. Exploraremos los principios del diseño inclusivo y aprenderemos cómo probar nuestros sitios web utilizando tecnología de asistencia para asegurarnos de que funcionen para todos.
Cubriremos temas como el marcado semántico, los roles de ARIA, los formularios y la navegación accesibles, y luego nos sumergiremos en ejercicios de codificación donde podrás aplicar lo que has aprendido. Utilizaremos herramientas de prueba automatizadas para validar nuestro trabajo y asegurarnos de cumplir con los estándares de accesibilidad.
Al final de este masterclass, estarás equipado con el conocimiento y las habilidades para crear sitios web accesibles que funcionen para todos, y tendrás experiencia práctica utilizando las últimas técnicas y herramientas para el diseño inclusivo y las pruebas. ¡Únete a nosotros en este increíble masterclass de codificación y conviértete en un ninja de la accesibilidad web y el diseño inclusivo!
Pruebas automatizadas de accesibilidad con jest-axe y Lighthouse CI
TestJS Summit 2021TestJS Summit 2021
85 min
Pruebas automatizadas de accesibilidad con jest-axe y Lighthouse CI
Workshop
Bonnie Schulkin
Bonnie Schulkin
¿Incluyen tus pruebas automatizadas verificaciones de accesibilidad? Este masterclass cubrirá cómo comenzar con jest-axe para detectar violaciones de accesibilidad basadas en código, y Lighthouse CI para validar la accesibilidad de las páginas completamente renderizadas. Ninguna cantidad de pruebas automatizadas puede reemplazar las pruebas manuales de accesibilidad, pero estas verificaciones se asegurarán de que tus probadores manuales no estén haciendo más trabajo del necesario.
Utilizando las Capacidades de IA Integradas de Zapier y las Integraciones de Herramientas de IA
Productivity Conf - Practical AI in MarketingProductivity Conf - Practical AI in Marketing
57 min
Utilizando las Capacidades de IA Integradas de Zapier y las Integraciones de Herramientas de IA
WorkshopFree
Kelly Goss
Kelly Goss
Cómo potenciar tu construcción de automatización sin código y reducir el tiempo de construcción con las últimas características y funcionalidades de IA de Zapier. También cubriré herramientas de IA que se integran nativamente con Zapier para llevar la productividad a un nivel completamente nuevo.
Horario y ubicación de la masterclass: por determinar, remoto vía Zoom
Accesibilidad web en aplicaciones JavaScript
React Summit 2022React Summit 2022
161 min
Accesibilidad web en aplicaciones JavaScript
Workshop
Sandrina Pereira
Sandrina Pereira
A menudo vemos que JavaScript daña la accesibilidad de un sitio web. En esta masterclass, aprenderás cómo evitar errores comunes y cómo utilizar JS a tu favor para mejorar la accesibilidad de tus aplicaciones web.
En esta masterclass exploraremos múltiples ejemplos del mundo real con problemas de accesibilidad, y aprenderás cómo hacer que funcionen para las personas que utilizan un mouse o un teclado. También aprenderás cómo se utilizan los lectores de pantalla, ¡y te mostraré que no hay razón para tener miedo de usar uno!
Únete a mí y déjame mostrarte cómo la accesibilidad no limita tus soluciones o habilidades. ¡Al contrario, las hace más inclusivas!
Al final, serás capaz de:- Comprender los principios de WCAG y cómo están organizados- Conocer casos comunes en los que JavaScript es esencial para la accesibilidad- Crear enlaces, botones y elementos conmutables inclusivos- Utilizar regiones en vivo para errores y estados de carga- Integrar la accesibilidad en el flujo de trabajo de tu equipo de inmediato- Darte cuenta de que crear sitios web accesibles no es tan difícil como parece ;)
Automatización de pruebas utilizando WebdriverIO
TestJS Summit 2022TestJS Summit 2022
163 min
Automatización de pruebas utilizando WebdriverIO
Workshop
Kevin Lamping
Kevin Lamping
En este masterclass, cubro no solo lo que WebdriverIO puede hacer, sino también cómo lo utilizarás día a día. He construido los ejercicios en torno a escenarios del mundo real que demuestran cómo realmente configurar las cosas. No es solo "qué hacer", sino específicamente "cómo llegar allí". Cubriremos los fundamentos de las pruebas automatizadas de UI para que puedas escribir pruebas mantenibles y útiles para tu sitio web y/o aplicación web.
JS Automatización de Pruebas de Seguridad para Desarrolladores en Cada Compilación
TestJS Summit 2021TestJS Summit 2021
111 min
JS Automatización de Pruebas de Seguridad para Desarrolladores en Cada Compilación
Workshop
Oliver Moradov
Bar Hofesh
2 authors
Como desarrollador, necesitas entregar rápido y simplemente no tienes tiempo para pensar constantemente en seguridad. Aún así, si algo sale mal, es tu trabajo arreglarlo, pero las pruebas de seguridad bloquean tu automatización, crean cuellos de botella y solo retrasan las versiones... pero no tiene por qué ser así...

El escáner de seguridad de NeuraLegion, enfocado en los desarrolladores, Dynamic Application Security Testing (DAST), permite a los desarrolladores detectar, priorizar y remediar problemas de seguridad de manera TEMPRANA, en cada confirmación, sin falsos positivos/alertas, sin ralentizarte.

¡Únete a esta masterclass para aprender diferentes formas en que los desarrolladores pueden acceder a Nexploit y comenzar a escanear sin salir de la terminal!

Recorreremos la configuración de principio a fin, mientras configuramos un pipeline, ejecutamos pruebas de seguridad y analizamos los resultados.

Tabla de contenidos:
- Qué es realmente DAST (Dynamic Application Security Testing) enfocado en los desarrolladores y cómo funciona
- Ver dónde y cómo encaja un DAST moderno y preciso en el CI/CD
- Integrar el escáner Nexploit de NeuraLegion con GitHub Actions
- Comprender cómo se pueden probar las aplicaciones modernas, las API y los mecanismos de autenticación
- Hacer un fork de un repositorio, configurar un pipeline, ejecutar pruebas de seguridad y analizar los resultados