Cómo introducir accesibilidad en un equipo que nunca ha pensado en ella
No es una sorpresa que la accesibilidad sea algo que se olvida en muchos equipos, es como esa muñeca vieja que dejas guardada e ignorada en el armario. Cada vez que entro en una nueva empresa y descubro, para sorpresa de nadie, que no se ha tenido en cuenta, sé perfectamente lo que me espera: toca arremangarse y prepararse para una larga pelea. Como cuando peleabas por introducir testing en tu equipo. O cuando querías introducir DevOps.
Porque la realidad es que la accesibilidad rara vez aparece como prioridad. De hecho, cada vez que saco el tema, la gente suele poner los ojos en blanco para después decirme la típica frase de “la gente con discapacidad no usa nuestro producto” o “somos pequeños y no tenemos tiempo para eso”.
La accesibilidad suele ignorarse porque la mayoría de la gente que desarrolla productos digitales cree que no le afecta y, sobre todo, que no se beneficiaría de crear productos más accesibles. Si en general ellos pueden completar el flujo sin problema, la mayoría de la población podrá. Y si dos o tres no pueden, ¿qué más da? Eso tampoco afectará a la cuenta de resultados.
Por lo que lo primero que tengo que hacer cuando entro en un equipo… es pelear contra los prejuicios de mis colegas.
La parte ética: cuando dejas fuera a personas
No pensar en accesibilidad significa excluir a un porcentaje importante de la población, cerrarles las puertas a un mundo de posibilidades a muchas personas con diferentes tipos de discapacidades. Significa condenarlas a un mundo injusto que nunca van a entender.
A veces hablamos de accesibilidad como si fuese una mejora opcional o una especie de “nice to have” que se añade cuando hay tiempo. Pero en realidad estamos hablando de millones de personas que se quedan fuera.
Así que sí, la parte ética importa.
Importa entender que cuando construimos productos digitales, también estamos tomando decisiones sobre quién puede usarlos y quién no.
Cuando el argumento ético no basta
No obstante, he aprendido que creer que la gente va a dedicar tiempo y recursos por la bondad de su corazón no siempre funciona. Hay situaciones en las que tenemos que hablar de dinero para lograr que la ética les importe.
Así que vamos a hablar de datos.
Según la OMS 1 de cada 6 personas tiene algún tipo de discapacidad; con el envejecimiento de la población, cada vez más gente tiene algún tipo de discapacidad sensorial, motora o cognitiva. Por otro lado, entre un 15 y un 20% de la población tiene algún tipo de neurodivergencia, un 4% tiene ansiedad y un casi 6% depresión.
Ahora que vemos datos, todos esos porcentajes en realidad son personas que se beneficiarían de la accesibilidad y que se están quedando fuera. Así que, lo siento, pero sí, probablemente estás perdiendo dinero ahora mismo al no hacer tus productos accesibles.
La accesibilidad también tiene impacto en el negocio.
La accesibilidad no puede vivir solo en frontend
Uno de los errores más comunes es pensar que la accesibilidad es “cosa del equipo frontend”. Como si pudieras separar completamente el departamento y pudiera quedar aislado de todo lo demás, flotando en el universo.
Pero la realidad es otra. La accesibilidad debe permear más allá de las personas que desarrollan el front, debe formar parte de la cultura de la empresa. Todo el mundo debe entender su valor y asumir su parte de la responsabilidad.
Para empezar, el equipo de diseño debe entender de accesibilidad para crear interfaces que tengan suficiente ratio de contraste, tipografías amables con personas con dislexia y crear flujos fáciles de entender con textos lo suficientemente explicativos, pero lo suficientemente sencillos como para que nadie se pierda.
Por otro lado, los Product Managers deben entender el valor de la accesibilidad y empezar a introducir requisitos de accesibilidad en las user stories. No basta con definir funcionalidades; también hay que definir cómo podrán utilizarlas diferentes tipos de personas.
Otros de los olvidados suelen ser las personas de otros departamentos técnicos. Es útil que las personas de plataforma o de backend, o de help desk, también entiendan el valor, ya que habrá momentos en los que tendrán que tomar decisiones técnicas que pueden afectar a la accesibilidad general.
También hay que tener en cuenta a los de arriba, los managers, ya que deberán dar tiempo y recursos para poder hacer todos esos cambios, así que puede que sean de los primeros que deben entender el valor que aporta hacer ese trabajo. Si la accesibilidad nunca tiene espacio, nunca sucederá.
Incluso en los procesos de selección debería empezar a valorarse. No hace falta que todo el mundo sea especialista en accesibilidad, pero sí que exista cierta sensibilidad por ella y que la persona al menos esté dispuesta a aprender sobre el tema.
Cuando solo una persona se preocupa por esto, el sistema acaba fallando en cuanto esa persona desaparece.
Antes de arreglar cosas, hay que entender el problema
Una vez que hayamos conseguido los apoyos necesarios en la organización, hay que pasar al siguiente paso: crear un plan realista. Y para ello, deberemos hacer un análisis profundo de en qué situación se encuentra nuestro producto.
Para comprender en qué punto nos encontramos, debemos combinar el uso de herramientas automáticas que revisen nuestro código, probar los flujos con diferentes productos de apoyo de forma manual y con personas que tengan diferentes tipos de discapacidades o circunstancias.
Como es muy posible que lo desarrollado ya tenga cierto tamaño, lo más sensato es crear un roadmap que vaya de menos complicado a más complicado y que se vaya realizando poco a poco.
En este sentido, es recomendable empezar por los llamados quick wins: pequeños cambios que tengan poco riesgo técnico, pero que ya supongan una mejora: como usar HTML semántico, reorganizar correctamente los encabezados…
Una vez abordadas estas mejoras iniciales, llegarán los problemas más complejos: hacer accesibles los modales, gestionar correctamente el foco. En estos casos, será importante que el equipo mantenga la paciencia, ya que pueden requerir rehacer componentes grandes, ajustar arquitecturas o incluso modificar aspectos del diseño.
Si procuramos hacer todos los cambios de golpe y muy rápido es posible que el resultado no sea el correcto, y que además nos ganemos de enemigos a las propias personas implicadas, sobre todo diseño y desarrollo, ya que pueden terminar saturadas de tanto rediseño y atributo ARIA.
Del mismo modo, es importante que forme parte de ese roadmap etiquetar cuáles van a ser las prioridades, el orden de esas prioridades, el objetivo hacia el que nos dirigimos, y qué se va a cubrir y qué no.
La formación cambia completamente la perspectiva
Dentro de ese roadmap, no nos debemos olvidar de que una de las primeras cosas que debemos hacer es dar formación a todo el mundo de lo básico, para que la accesibilidad permee en la organización, y de partes más particulares para los de diseño y desarrollo.
Y con formación no me refiero exclusivamente a que se lean la WCAG, que en accesibilidad la queremos mucho a esta guía, pero a veces no es lo que necesitamos. Sino también a que se entienda qué son los productos de apoyo, cuáles son los diferentes tipos, cómo funciona la navegación por teclado, los diferentes tipos de neurodivergencia…
Ese momento suele ser transformador. Cuando algunas personas se ponen en los zapatos de otras y experimentan por primera vez la incomodidad de navegar por una interfaz que no fue diseñada para ellos, suele ser un momento muy especial.
La accesibilidad debe entrar en el Definition of Done
Otro paso que debemos incorporar es que se tenga en cuenta la accesibilidad como parte del proceso de desarrollo. No como algo que se hace en una tarea aislada a posteriori, sino como algo que se debe realizar durante la propia implementación de las tareas. Como parte del Definition of Done.
Igual que debemos añadir tests para asegurarnos de que las cosas funcionan como deberían, y que no las rompemos más adelante, en nuestras revisiones de código es importante que tengamos en cuenta cumplir con ciertas garantías mínimas de accesibilidad antes de considerar una tarea terminada.
En este punto debemos decidir algo muy importante: cuál va a ser nuestro estándar. Si vamos a seguir WCAG A, AA o AAA, qué criterios vamos a priorizar, qué productos de apoyo vamos a tener en cuenta…
También hay que aprovechar para crear una declaración de accesibilidad interna. No solo como documento corporativo, sino como referencia práctica para el equipo. Un lugar donde quede claro qué principios seguimos, qué herramientas usamos y cómo validamos el trabajo.
Automatizar para no depender de la memoria
Hoy en día tenemos que tener en cuenta mil cosas, de ahí que sea importante automatizar ciertas cosas.
Podemos configurar ciertos linters para que nos recuerden realizar ciertas modificaciones o introducir validaciones automáticas en CI. Por ejemplo, una GitHub Action que ejecute análisis de accesibilidad y bloquee una pull request si detecta determinados problemas.
El objetivo de esto no es castigar a nadie, sino para evitar depender de la buena memoria.
La accesibilidad es calidad
La accesibilidad no debería depender de tener “a esa persona pesada a la que le gusta la accesibilidad” dentro del equipo insistiendo constantemente, debería formar parte de la manera en la que construimos nuestros productos.
Igual que hoy ya tenemos como algo fijo el hacer tests o cuidar la seguridad, la accesibilidad debería dejar de verse como un añadido y empezar a verse como lo que realmente es: calidad.
Porque al final, construir productos accesibles no es cumplir una normativa, es decidir que las personas importan.
Fuentes:
who.int/health-topics/disability
https://thendalliance.org/what-is-neurodiversity
https://www.who.int/es/news-room/fact-sheets/detail/depression
https://www.who.int/es/news-room/fact-sheets/detail/anxiety-disorders
¿Quieres saber un poco más sobre quién ha escrito este artículo? 👇
Front-end especializándose en accesibilidad. Soy una persona inquieta, a la que le gusta meterse 'fregaos. Soy mentora en step4ward, escribo artículos y doy charlas. Friki e inquieta por naturaleza, fuera del teclado me gustan el cine, los juegos de mesa y ser dungeon master.