Enhancing Accessibility at Stack Overflow

Hola a todos, soy Giammi. Hoy, me gustaría compartir con ustedes un estudio de caso sobre cómo cuantificar la accesibilidad ha jugado un papel crucial para mejorar la accesibilidad de nuestros productos en Stack Overflow.

Pero primero, un par de palabras sobre mí. Estoy bastante seguro de que la mayoría de ustedes aquí están familiarizados con Stack Overflow. Lo que quizás no sepan es que Stack Overflow tiene un sistema de diseño de código abierto que llamamos Stacks. Trabajo como ingeniero de planta en ese equipo, donde estamos impulsando muchas iniciativas relacionadas con el front-end en nuestra organización.

Pequeño descargo de responsabilidad, no me considero un experto en accesibilidad, pero tuve la oportunidad de liderar la iniciativa que estoy a punto de contarles. Lo que sigue ha funcionado bien para nuestra organización, pero como todo en el desarrollo de software, su experiencia puede variar.

Permítanme comenzar dándoles un poco de contexto sobre los desafíos de accesibilidad que enfrentamos en Stack Overflow. Nuestros equipos de producto carecen de objetivos claros de accesibilidad. A menudo solucionan problemas de manera reactiva, esperando que se informen los problemas en lugar de prevenirlos proactivamente. Nuestro liderazgo era comprensiblemente reacio a invertir completamente en esfuerzos de accesibilidad. Sin una visibilidad clara de nuestro progreso, era difícil justificar priorizarlo junto con otras iniciativas urgentes. Y finalmente, nuestras comunidades y clientes, algunos de los cuales con requisitos legales de accesibilidad hacia sus empleados, estaban luchando por ver nuestro compromiso con la accesibilidad.

Sabíamos que necesitábamos hacerlo mejor, tanto para cumplir con las expectativas de nuestros clientes y comunidades, como para construir productos más inclusivos en general. Así que junto con nuestro liderazgo, comenzamos nuestro viaje estableciendo un resultado claro para generar confianza con nuestras comunidades y clientes demostrando un fuerte compromiso con la accesibilidad. Queríamos ir más allá de simplemente cumplir con los requisitos legales, nuestro objetivo era mejorar proactivamente la accesibilidad en todos nuestros productos, convirtiéndola en una parte central de cómo construimos. Así es como abordamos la búsqueda de nuestra estrategia para alcanzar nuestro resultado.

Rápidamente nos dimos cuenta de que nuestro equipo del sistema de diseño, mi equipo, tenía la mayor experiencia en accesibilidad en toda la organización. Estábamos en la mejor posición para liderar esta iniciativa dado nuestro fuerte entendimiento de ambos aspectos, el diseño y los aspectos técnicos de la accesibilidad. Luego, el liderazgo nos proporcionó un resultado claro para mejorar la accesibilidad y generar confianza, pero también nos dieron la libertad de explorar soluciones. Esto nos empoderó para pensar creativamente y asumir la responsabilidad de cómo podríamos lograr este objetivo. Para organizar nuestro esfuerzo, utilizamos un árbol de soluciones de oportunidades. Esta es una herramienta de gestión de productos que nos permite hacer una lluvia de ideas y visualizar cómo cada acción que consideramos contribuirá a nuestro objetivo final. Con nuestro árbol de soluciones de oportunidades en su lugar, pudimos reducir nuestra estrategia a estos cuatro puntos principales.

Primero, necesitábamos establecer un objetivo claro de accesibilidad. Sin metas definidas, sería imposible medir el progreso o saber cuándo realmente estábamos teniendo un impacto. A continuación, decidimos medir la accesibilidad de nuestros productos de manera consistente. Queríamos datos para respaldar nuestro esfuerzo y asegurarnos de que no solo estábamos adivinando, sino realmente mejorando la accesibilidad con el tiempo. También sabíamos que teníamos que liderar con el ejemplo con nuestro sistema de diseño. Dado que nuestro equipo del sistema de diseño tenía la mayor experiencia en accesibilidad, era crucial que nuestros componentes de diseño establecieran el estándar de accesibilidad en toda la organización. Finalmente, queríamos comenzar a desplazar la accesibilidad hacia la izquierda. Esto significa incorporar la consideración de la accesibilidad más temprano en el proceso de desarrollo para que se convierta en parte de cómo hacemos las cosas, no una ocurrencia tardía. Vamos a profundizar en la primera parte de nuestra estrategia.

Lo primero que hicimos fue establecer objetivos claros y documentados de accesibilidad basados en las Web Content Accessibility Guidelines, a menudo pronunciadas WCAG. Tener estas directrices nos dio puntos de referencia concretos y reconocidos por la industria para medir nuestros productos. También creó claridad para nuestros equipos al saber exactamente qué significaba la accesibilidad en la práctica. Un desafío que enfrentamos fue el color naranja característico de Stack Overflow. Según las directrices de WCAG, no cumplía con los requisitos de contraste. La razón es que el algoritmo actual de contraste de color de WCAG es demasiado simple para tener en cuenta la complejidad de la percepción humana. Así que hicimos una excepción aquí adoptando el Advanced Perceptual Contrast Algorithm o APCA en resumen. APCA podría convertirse en parte de la próxima especificación WCAG 3 y nos permite trabajar con el naranja mientras aún tenemos un medio para verificar el contraste de color de manera automatizada. Y finalmente para asegurar un compromiso a largo plazo en toda la organización, formalizamos estos objetivos a través de un Architectural Decision Record o en resumen ADR. Este ADR hizo de la accesibilidad una parte no negociable de nuestro proceso de desarrollo, asegurando que cada equipo estuviera alineado y fuera responsable de cumplir con este objetivo.

Si tienes curiosidad sobre los detalles de este objetivo y cómo están documentados, puedes escanear este código QR para profundizar en nuestra documentación del sistema de diseño sobre accesibilidad. Una vez que tuvimos nuestros objetivos de accesibilidad en su lugar, el siguiente paso crítico fue medir nuestro progreso de manera consistente y confiable. Nos propusimos crear una señal sintética para rastrear cómo estábamos avanzando en relación con nuestro objetivo de accesibilidad y darnos una indicación clara de si nos estábamos moviendo en la dirección correcta.

Para la verificación automatizada, utilizamos una herramienta llamada Axecore desarrollada por Deque. Es una herramienta poderosa utilizada por muchos productos en la industria que nos ayuda a calcular la accesibilidad de manera automatizada y calcular la puntuación de accesibilidad para nuestras páginas de productos. Sin embargo, las herramientas automatizadas como esta típicamente solo detectan alrededor del 50-57 por ciento de los problemas más débiles en promedio. Así que sabíamos que esto era solo una parte del panorama. Para llenar los vacíos, también establecimos puntuaciones manuales de varias fuentes, incluidos auditores externos, comentarios de la comunidad y problemas reportados por los clientes. Esto nos dio una visión más completa de la accesibilidad de nuestros productos cubriendo cosas que la automatización por sí sola no podía detectar.

Finalmente, para hacer que todos estos datos sean fácilmente accesibles y procesables, construimos un panel de accesibilidad. Esto se convirtió en un centro donde los equipos, nuestra comunidad e incluso los clientes podían rastrear nuestro progreso y responsabilizarnos. Ahora vamos a profundizar un poco más en cómo nuestros informes de accesibilidad, tanto automatizados como manuales, contribuyen a crear nuestras puntuaciones de accesibilidad. Para los automatizados, tenemos flujos de trabajo de GitHub que se activan diariamente y que verifican varias reglas más débiles a través de Axe Engine y Playwright. Esas reglas se ejecutan contra una selección de las páginas más importantes de nuestros diferentes productos. Los resultados del flujo de trabajo luego se transforman en métricas que subimos a nuestra plataforma de accesibilidad.

Para los problemas manuales, tenemos un tablero centralizado de accesibilidad donde cualquier persona en la organización puede registrar problemas. Los problemas son luego clasificados por un grupo de ingenieros y diseñadores expertos en accesibilidad. Llamamos a este grupo campeones de accesibilidad. Los problemas clasificados tienen un campo de severidad asociado a ellos y afectan la puntuación de accesibilidad manual. Luego tenemos un servicio de accesibilidad que es responsable de extraer datos de nuestra plataforma de observabilidad y nuestro tablero central de accesibilidad. Calcular la puntuación y luego mostrarlas en nuestro panel disponible públicamente. Y así es como se ve el panel final que todos pueden consultar en accessibility.stackoverflow.net. Todavía estamos iterando en este panel, pero incluso en su estado actual proporciona información procesable para que nuestro equipo mejore la accesibilidad en nuestros productos. Además de mostrar tendencias de puntuación, el panel resalta la puntuación de accesibilidad por página y detalla todos los problemas identificados por las ejecuciones automatizadas. Teníamos nuestros objetivos de accesibilidad en su lugar y una forma clara de rastrear el progreso a lo largo del tiempo. A continuación, era hora de arremangarnos y comenzar a rastrear algunos de los problemas de accesibilidad en nuestro producto. Sabíamos que comenzar con nuestro sistema de diseño tendría el mayor impacto ya que nuestras bibliotecas se utilizan para construir interfaces de usuario en prácticamente todos los productos. Así que el sistema de diseño es donde enfocamos nuestro esfuerzo primero. A medida que hicimos mejoras, documentamos y compartimos técnicas de WCAG con el resto de la organización de ingeniería, asegurando que las mejores prácticas fueran ampliamente adoptadas. Algunos de los problemas clave que abordamos incluyen mejorar el estilo de enfoque para asegurar indicadores visuales claros, especialmente para nuestros usuarios que solo usan el teclado, y también tuvimos el componente de enlaces de salto ligero que permite a los usuarios omitir bloques repetidos de contenido en nuestras páginas mejorando la navegación para todos.

Probablemente la mejora de accesibilidad más impactante que hicimos fue implementar una nueva paleta de colores desarrollada en estrecha colaboración con nuestro equipo de diseño. Usamos el algoritmo de contraste perceptual accesible APCA como nuestra guía.

Como mencioné anteriormente el algoritmo actual de contraste de color de WCAG es demasiado simple para tener en cuenta la complejidad de la percepción humana. Es especialmente poco confiable al probar ciertos colores como el naranja de Stack Overflow. Aquí es también donde contribuimos de nuevo al código abierto. APCA siendo un algoritmo de vanguardia no estaba aún soportado por el motor AXE core, así que creamos una regla de cumplimiento de APCA para el motor que nos dio una forma automatizada de probar el contraste de color en nuestras páginas.

Si estás interesado en usar las reglas de APCA para verificar tus propias páginas, puedes encontrar más detalles en el repositorio de verificación de APCA siguiendo el código QR en las diapositivas. La última parte de nuestra estrategia fue lograr que nuestra organización pensara en la accesibilidad desde el principio en el proceso de desarrollo. Hicimos esto a través de algunas iniciativas clave. Primero establecimos campeones de accesibilidad dentro de cada equipo. Son responsables de difundir el conocimiento sobre accesibilidad y reunirse regularmente con otros campeones en toda la organización. También trabajamos con el liderazgo de producto y de ingeniería para asegurarnos de que los equipos tuvieran el espacio para priorizar y mejorar sus puntuaciones de accesibilidad. Creamos una lista de verificación de accesibilidad ágil que aparece automáticamente como un comentario cuando se detectan cambios en la UI en las solicitudes de extracción. Y desarrollamos un breve video de capacitación interna para ingenieros y diseñadores con consejos prácticos de accesibilidad específicos para nuestras necesidades.

Llamamos a estos bocados de accesibilidad. Quizás una de las cosas más importantes que hicimos para salvaguardar nuestros estándares de accesibilidad fue establecer objetivos de nivel de servicio de accesibilidad. Básicamente usamos la puntuación de accesibilidad automatizada como un indicador de nivel de servicio. A cada producto se le asignó un objetivo. Si hay una caída en la puntuación, se crea automáticamente un incidente de prioridad tres y se notifica al campeón de accesibilidad de guardia. A partir de ahí, hay un plazo de siete días para identificar y solucionar la causa raíz de la regresión de accesibilidad. Al cuantificar la accesibilidad, pudimos integrarla en procesos familiares para nuestros ingenieros y liderazgo. La accesibilidad ya no es un concepto vago e intangible.

Se ha vuelto tan concreto como cualquier otra métrica que rastreamos. Aquí hay algunas lecciones clave de nuestro viaje que quiero dejarles. Primero, establecer objetivos claros de accesibilidad para la organización. Sin metas definidas no hay forma de medir el éxito. Igualmente importante es asegurar el compromiso organizacional con esos objetivos por parte del liderazgo y de los equipos para que la accesibilidad se convierta en una prioridad central para todos. Segundo, asegurarse de medir y rastrear la accesibilidad del producto. Cuando los equipos pueden ver un progreso real impulsa la motivación y también da visibilidad al liderazgo y al cliente.

Demuestra compromiso y ayuda a cuantificar los retornos de la inversión en accesibilidad.

Tercero, desplaza la accesibilidad hacia la izquierda. Esto significa integrar la accesibilidad temprano en tu proceso de desarrollo. Invierte en educar a los equipos y crear salvaguardas como verificaciones automatizadas o pasos impulsados por procesos para prevenir regresiones. Se trata de preparar a los ingenieros para el éxito asegurando que la accesibilidad sea parte del proceso y no una ocurrencia tardía.

Y finalmente, recuerda que el trabajo de accesibilidad nunca termina. Siempre hay más que podemos hacer. Sigue refinando procesos e invierte en pruebas de usuario para asegurar que seguimos refinando procesos e invierte en pruebas de usuario para asegurar que realmente estamos satisfaciendo las necesidades de los usuarios. La accesibilidad no es y no debería ser un proyecto de una sola vez. Es un viaje continuo de mejora.

Eso es todo lo que tengo por hoy. Espero que nuestro enfoque para mejorar la accesibilidad en Stack Overflow te haya dado algunas ideas sobre cómo priorizar la accesibilidad en tu propia empresa.

Quiero agradecer a mis compañeros de equipo Dan y Caro, al Grupo de Campeones de Accesibilidad de Stack Overflow y al Gremio de Front-end de Stack Overflow. Todos ellos juegan un papel crucial para hacer que lo que acabo de presentar sea una realidad para nuestra organización.

Si tienes preguntas, aquí puedes encontrar mi correo electrónico y mi usuario de redes sociales. Gracias por escuchar.