Cómo mejoramos las pruebas de accesibilidad

Al principio de nuestro recorrido en materia de accesibilidad, generalmente agrupábamos las pruebas de accesibilidad en dos categorías: automatizadas y manuales. Las primeras para detectar rápidamente los problemas más evidentes que se pueden detectar mediante algoritmos y las segundas para todo lo demás que requería más tiempo y atención para encontrarlo. Las pruebas automatizadas encajaban bien en procesos rápidos como la Integración Continua (CI), mientras que las manuales requerían una cuidadosa coordinación con probadores expertos para cubrir todo lo que las herramientas automatizadas no podían.

En el camino, descubrimos que en realidad existe un punto óptimo entre estos dos enfoques. En asociación con Assistiv Labs, combinamos mejores procesos con pruebas de servicio de extremo a extremo para crear un flujo de trabajo de pruebas que redefine lo automatizado y lo manual. Es algo intermedio, un enfoque híbrido que aumenta drásticamente la cobertura automatizada y reduce la sobrecarga de la coordinación manual.

Ahora detectamos problemas claros y fáciles de solucionar en horas en lugar de semanas. Nuestros nuevos procesos determinan automáticamente qué es urgente y envían los problemas a los Equipos correctos, que generalmente los resuelven en cuestión de días.

Los resultados han sido tanto técnicos como culturales. Brindamos comentarios sobre la accesibilidad mucho más rápido, los equipos resuelven los errores más rápido y los ingenieros de Asana han comenzado a pensar de manera diferente en los problemas de accesibilidad.

Creación de procesos para priorizar los errores de accesibilidad

A la escala de Asana, es esencial contar con un marco de priorización sólido respaldado por procesos y principios de gobernanza. Los equipos deben saber qué se debe programar en sus backlogs y para cuándo, y qué necesita atención en este momento.

Pero es fácil subestimar lo difícil que es priorizar los errores de accesibilidad. La prioridad se basa en una matriz vertiginosa de factores únicos que incluyen tecnologías de asistencia, navegadores, grupos de usuarios afectados, comentarios de los usuarios, área del producto, dificultad de la solución, soluciones alternativas, conformidad con las WCAG y contexto histórico. Es posible que algunos errores hayan existido durante mucho tiempo, pero que solo se hayan detectado recientemente. Otros aparecen con funciones nuevas. Y algunos son regresiones: funcionalidades que antes eran accesibles pero que ahora no lo son.

Para crear un marco, definimos formalmente diferentes tipos de errores de accesibilidad para poder diseñar flujos de trabajo optimizados en torno a cada uno. Un paso esencial fue definir qué constituía una regresión y qué no.

regresión (s)

Un problema documentado (¿hay algún registro de que esto funcionaba, como errores anteriores, hilos de comentarios, capturas de pantalla o grabaciones de pantalla?), reproducible (¿un colega puede reproducirlo siguiendo los pasos descritos?) que antes funcionaba y ahora ya no.

Las regresiones pueden recibir naturalmente una alta prioridad: lo último que alguien quiere es que la accesibilidad retroceda. Esto puede simplificar enormemente la priorización en muchos casos.

Sin embargo, hay un problema. Las regresiones se definen por instantáneas del antes y el después. Por ejemplo, una instantánea anterior podría ser un video de la funcionalidad en funcionamiento y una instantánea posterior podría ser un video de un nuevo resultado problemático. Los errores naturalmente tienen instantáneas posteriores. Pero encontrar la instantánea del antes por lo general requiere una investigación profunda.

Sin una fuente confiable de instantáneas anteriores, a menudo no valía la pena dedicar tiempo a investigar si un error podía priorizarse como una regresión. Aquí es donde un nuevo tipo de automatización resultó inmensamente útil.

Automatización de accesibilidad de extremo a extremo

Las pruebas totalmente automatizadas no son nuevas en las pruebas de accesibilidad ni en Asana. Históricamente, axe DevTools y jsx-a11y para React nos proporcionaron una cobertura amplia y horizontal. Pero son superficiales. Consideramos que la estimación del 30 % de token para las pruebas automatizadas en todo el sector se acercaba bastante a los criterios de las WCAG que estábamos cumpliendo. La cobertura limitada significaba que las pruebas manuales seguían encontrando errores que las herramientas automatizadas habían pasado por alto.

Necesitábamos herramientas que pudieran profundizar más. Herramientas más estrechamente alineadas con nuestros principios de investigación de usuarios y gobernanza. Y eso es lo que encontramos con Assistiv. Los ingenieros de Assistiv escriben desde cero las pruebas para el servicio integral de Assistiv en función de los flujos de usuario y los parámetros de prueba que proporcionamos. Las suites incorporan atajos del teclado, lectores de pantalla reales, navegadores y visión artificial con la tecnología de la nube de Assistiv Labs. El resultado es más que una simulación, ya que los eventos se transmiten a una máquina de la misma manera que lo haría un usuario humano, lo que maximiza la cobertura de las WCAG y las cuestiones de accesibilidad más amplias.

La automatización de la accesibilidad de extremo a extremo es radicalmente diferente de la automatización tradicional, ya que interactúa con Asana para realizar tareas de la misma manera que lo haría un evaluador manual. Es posible cubrir hasta el 75 % de los criterios de las WCAG, según el escenario de prueba. Y todavía hay expertos en pensamiento crítico en vivo que supervisan todo. Tanto el personal de Asana como el de Assistiv participan en el diseño de acciones representativas de los usuarios y en la revisión de los resultados, lo que eleva drásticamente el nivel de las pruebas automatizadas en términos de alcance, frecuencia y precisión.

Combinar fuerzas

Con un marco de priorización sólido y una nueva automatización que pasó de encontrar una minoría de errores a la mayoría, implementamos un potente flujo de trabajo de priorización.

Primero, las pruebas automatizadas se sincronizan con el canal de ingeniería existente de Asana. Los problemas nuevos se detectan casi en tiempo real y se correlacionan con los cambios de código que probablemente los causaron.

A continuación, un ingeniero de Assistiv realiza una revisión para filtrar los falsos positivos y crea un problema en el trabajo pendiente de Asana con el impacto en el usuario contextualizado y una guía de corrección. Debido a que las pruebas automatizadas se ejecutan continuamente, se dispone de una instantánea previa y las regresiones se pueden clasificar fácilmente. Mantenemos flujos de trabajo automatizados de Asana que envían el problema al Equipo correcto.

En la práctica, esto significa que las regresiones generalmente se marcan dentro de las 24 horas posteriores a una implementación y se documentan de una manera que es fácil de entender para los ingenieros sin experiencia en accesibilidad. Eso permite que nuestro Equipo de accesibilidad establezca un SLA para abordar las regresiones y que los Equipos de producto se ocupen de ello. Nadie tiene que argumentar qué regresión es la primera, la segunda o la última. Son simplemente errores que requieren atención.

Esta descentralización se traduce directamente en un programa más sostenible y en experiencias de usuario final más inclusivas. Tenemos mucha más capacidad de acción e impacto, mucho espacio para la creatividad porque no estamos constantemente apagando incendios. Y eso a su vez significa que somos más felices y más eficaces.

El retorno sobre la inversión de los ciclos de comentarios más rápidos

Un error que pasa desapercibido durante semanas o meses es costoso de corregir. Alguien tiene que clasificarlo y asignarlo al Equipo apropiado y asegurarse de que se priorice. El ingeniero al que se le asigna probablemente no sea el mismo ingeniero que lo causó. Incluso cuando lo es, es difícil desenterrar el contexto olvidado, cambiar de marcha o coordinar con otros Equipos para desentrañar la deuda técnica que ha surgido en las semanas y meses intermedios.

Poniendo cifras al problema, un estudio de IBM muy citado reveló que cuesta 30 veces más descubrir errores en producción que aquellos que se encuentran durante la fase de diseño. Eso suena cierto.

Cuando los ingenieros implementan una actualización por la mañana, cualquier evidencia de regresiones normalmente comenzará a aparecer antes de que termine la jornada laboral. El ciclo de feedback es tan corto que nuestras pruebas de extremo a extremo han sido las primeras en alertarnos sobre errores genéricos de la interfaz de usuario, no restringidos a los lectores de pantalla o a la navegación por teclado, en múltiples ocasiones.

A medida que los ingenieros comenzaron a recibir comentarios más rápidos de las pruebas de extremo a extremo, notamos una reducción en la sobrecarga cognitiva de la priorización. La ambigüedad desapareció. Los ingenieros pensaban: “Soy responsable de esto porque lo entregué esta mañana. Ayer funcionaba y hoy no, necesito solucionarlo ahora”. Solucionar errores de accesibilidad se convierte en algo así como la memoria muscular.

En Asana, los errores de accesibilidad son simplemente errores. Y se solucionan.

Una mejor forma de automatizar la accesibilidad

Antes de adoptar las pruebas de accesibilidad de extremo a extremo, nuestro Equipo de Accesibilidad logró un progreso significativo. En el área de Operaciones, los equipos de diseño e ingeniería tenían procesos de revisión documentados, definiciones de regresión y ANS establecidos. Cuando se trataba de pruebas, había soluciones automatizadas para informes rápidos pero superficiales y control de calidad manual para auditorías exhaustivas pero que requerían mucho tiempo.

Con la solución integral, tenemos una solución técnica que complementa y se suma a los esfuerzos existentes. Las regresiones se documentan antes, con más detalle y con más evidencia. Prácticamente nadie pierde el tiempo en informes de errores que no son procesables o reproducibles.

Ahora tenemos una imagen clara de qué errores son nuevos y cuáles son antiguos, qué flujos de usuarios afectan y quién es responsable de la corrección. Podemos adelantarnos a la curva y centrarnos en nuestra visión de la accesibilidad de Asana en el futuro.

Acerca de los autores:  Cameron Cundiff (líder técnico) y Jiaxin Zheng (jefa de programas técnicos) son miembros del grupo de Ciclo de vida del desarrollo, dedicado a proporcionar herramientas que permitan a los desarrolladores llevar las ideas a producción de manera rápida, sólida y agradable.