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

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

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.

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

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

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.

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.

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.

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.