De buenas intenciones está lleno el infierno de los productos fracasados.

En mi opinión los diseñadores de experiencia vivimos en un permanente autoengaño. Testeamos la accesibilidad de un producto digital con amigos y familiares, testeamos con colegas, testeamos con personas que trabajan en el área. Cuando hacemos esto los resultados obtenidos están llenos de sesgos cognitivos y, bajo supuestos equivocados, el producto diseñado será un fracaso; perjudicando al usuario, al negocio y a nosotros mismos.

El problema es simple: a los diseñadores nos ha costado desarrollar una visión de producto. Por lo mismo, muchos y muchas UX hablan del usuario, pero no lo involucran realmente en sus procesos. Cuando diseñamos, solo lo hacemos pensando en aquellos usuarios que no tienen dificultades para navegar, pero ¿qué pasa con aquellos que sí las tienen y requieren de la accesibilidad web?

Extrapolando cifras de la Encuesta de Microsoft realizada en el año 2003, solo un 21% de la población no tiene ningún tipo de dificultad para navegar. Para esas personas estamos diseñando. En ese sentido, cuando se diseña y testea pensando en el 80/20, en realidad se está diseñando y testeando para el 80% de ese 21%. Reitero, falta de visión de producto, si entendiéramos realmente a los usuarios (o si entendiéramos al negocio), dejaríamos de diseñar para unos pocos.

Usted, persona informada, podrá cuestionar el dato del 21% argumentando que las personas con discapacidad alcanzan solo el 17% de la población. ¿Se me perdió un 62% de personas?, jaja, no. En medio de estas dos cifras se encuentran todas aquellas personas que se verían beneficiadas con la accesibilidad, ya sea porque tienen dificultades mínimas o medianas.

Avancemos.

Otra prueba de la falta de visión de producto de los diseñadores es el poco contacto que tenemos con los desarrolladores y analistas QA. He llegado a pensar que trabajamos en una especie de silos de falsa agilidad, sin que lleguemos a involucrarnos en lo que pasa antes o lo que pasa después de nuestra intervención. Literalmente estamos corriendo una posta.

¿Cuántos de nosotros damos por terminado el proyecto una vez que entregamos al equipo de desarrollo?

Diría que la gran mayoría concebimos el diseño bajo la mirada del Design Thinking, pero la verdad es que el diseño es solo una parte en la vida del producto. Aún falta desarrollarlo, hacer las pruebas de calidad, lanzarlo, medir, optimizar la solución y escalar.

En ese sentido, los diseñadores tenemos dos grandes deudas: entender al usuario bajo una mirada de inclusión, e involucrarnos en las siguientes etapas del producto.

Asegurar la Accesibilidad

Poco sabemos de accesibilidad. Tan poco, que estamos convencidos de que no se necesitan especialistas o que no tiene mayor costo su implementación. Otra vez, la falta de mirada de diseño de producto nos juega malas pasadas, porque no basta con diseñar experiencias accesibles, deben implementarse y testearse para asegurar que lo que se diseñó es lo que en definitiva le sirve a nuestros usuarios. De lo contrario, es solo una buena intención y ya saben lo que dicen de las buenas intenciones, si no se concretan, no sirven.

Para que un producto sea accesible se requiere diseño y desarrollo.

Por supuesto que sí necesitamos especialistas en accesibilidad, y no solo en diseño, también en desarrollo y en calidad. Supongamos que todos los diseñadores son expertos en accesibilidad universal, desarrollo aún debe ser capaz de implementarlo y QA de testearlo.

¡Obvio que es más caro!, más o menos el costo de un producto accesible subirá un 15% adicional si se implementa desde el principio. Por dos razones: los especialistas cuestan dinero y los procesos son un poco más largos y requieren nuevas herramientas, que otra vez se traduce en más costos. Oye si subtitular los videos no es gratis. Otra cosa es que sea un costo justificado que ahorrará dinero más adelante, pero no cuesta lo mismo.

Tal vez usted que me lee ahora ya cuenta con una solución y se pregunta cuánto le va a salir mejorar su sitio, estimo al ojo que un 25-30% del costo inicial. Así es que sí, siempre es mejor hacerlo desde el principio, porque hacer un plan de mitigación no es muy simple. Y re-diseñar un producto para que sea accesible una vez construido será mucho más costoso.

Lo que callamos los Diseñadores

Trabajar en diseño y apostar por la inclusión es una batalla campal.

Hay que convencer a otros diseñadores de que la accesibilidad es parte de su trabajo. Me ha pasado que más de alguno me ha asegurado que sus usuarios no tienen ningún tipo de discapacidad.

Siempre pongo el caso de un ex compañero de trabajo, Javier, que es daltónico (trabajamos con visualización de datos, así es que además de PO jugaba de tester funcional). Javier una vez gritaba en la oficina porque quería comprar una polera roja para la novia y no podía escogerla. Es completamente inaceptable que un usuario no pueda realizar una compra de forma autónoma.

Ahora imaginen a María José, desarrolladora y UX con discapacidad auditiva. A ella le encanta estudiar, pero sin subtítulos, simplemente no puede seguir una clase online.

Pensar que las personas con discapacidad no usan la web es una visión sesgada y violenta.

Una vez que entendemos la urgencia de implementar la accesibilidad en el diseño, siguen las disputas con el contenido. ¿Qué información vamos a complementar para el screen reader?, ¿qué información vamos a ocultar?, ¿cuál será el nombre de esta página?, ¿cuáles serán los textos alternativos?, suma y sigue.

Hace un par de años, con un grupo de amigos y amigas creamos el colectivo CADA para estudiar temas asociados a la accesibilidad y lanzamos una encuesta (juro que publicaremos los resultados en junio). Le preguntamos a los especialistas del área TI cómo garantizan la accesibilidad de sus productos. En sus respuestas nos comentaron de los tamaños de los botones, el uso de contrastes y las jerarquías. Todo eso está muy bien, pero no es suficiente.

¿Cómo hacen el handoff de accesibilidad al equipo de desarrollo? Otra vez, eso lo hacen los especialistas y encontramos solo cuatro especialistas en un universo de 314 personas. Suponiendo que lo hacen, al otro lado debe existir un desarrollador que sepa implementarlo. Lo que me lleva al punto de las diferencias de interpretación con el equipo de desarrollo.

Hace poco diseñé una plataforma perfectamente jerarquizada, pero lo que se implementó fueron párrafos con distintos estilos, de modo que no existía una estructura que permitiera a los usuarios navegar mediante tecnología asistiva. No solo eso, los botones no tenían cambio de estado. Descubrí todo eso -y más-, porque inspeccioné el código, navegué por teclado y usé el screen reader. Lo que quiero decir es que se veía como lo diseñé, pero no era lo que diseñé y sin embargo las pantallas habían sido aprobadas por el equipo QA.

Aún existen desarrolladores que no saben implementar código semántico, ni hablemos de aria-label. En mi experiencia, solo los front-end trabajan con criterios de accesibilidad, pero las empresas tienen desarrolladores full-stack, y tengo la impresión de que están más interesados en el back que en el front. Otra vez, necesitamos especialistas.

Hasta ahora les he contado la historia de mi vida, pese a que la accesibilidad es mi norte, los productos en los que he trabajado pocas veces han resultado ser accesibles. ¿Soy una vende humo? Capaz. He estudiado mucho para disminuir esa brecha, solo para llegar a la conclusión de que necesito un equipo de alto nivel.

Navegación de las Personas con Discapacidad

Algunas personas con discapacidad utilizan software y hardware especializado, por ejemplo la línea braille utilizada por personas ciegas y sordociegas. Otras podrían ajustar la configuración de sus dispositivos, bastaría con modificar las preferencias de la plataforma y del navegador por ejemplo activando las preferencias de accesibilidad o algo más cotidiano, activando los subtítulos. Además encontramos la tecnología asistiva que permite a la persona con discapacidad interactuar con el contenido de la pantalla.

Esta última, a su vez, puede ser general o específica. A modo de ejemplo, el teclado o el zoom del navegador son tecnologías generales; mientras que el audífono o el dispositivo dits son tecnologías específicas. Además puede ser implementada a través de un dispositivo externo o por software. Un dispositivo externo podría ser el puntero de cabeza; un software podría ser el control de voz.

Cada persona es un mundo. Las personas con discapacidad combinan estos tres factores y utilizan una estrategia propia. Por eso es tan antinatural testear con usuarios con discapacidad en un laboratorio, al menos que sean expertos en tecnología. Hacer eso, también podría llevarte a resultados erróneos.

¿Cómo testeamos la Accesibilidad?

Los test automáticos solo cubren un 30% de los casos. Por ejemplo, puede validar que exista la etiqueta alt, pero no será capaz de validar que el texto sea necesario o no, o si siendo necesario, este tenga sentido para el usuario. De modo que sí, los utilizaremos, pero su resultado no nos puede dejar conformes, de lo contrario volvemos al autoengaño del que les hablé al inicio.

Testear la Accesibilidad

Lo mejor sería testear siempre con personas con discapacidad. Pero podemos hacer cuatro cosas en forma paralela.

1. Evaluación guiada

Existen herramientas que localizan problemas o posibles problemas y los presentan. Estoy pensando en herramientas como Siteimprove.

2. Inspección utilizando Herramientas

También podríamos utilizar extensiones que nos permitan explorar y generar un diagnóstico. Aquí aparecen extensiones como Web Developer, WAVE Evaluation Tool, Siteimprove Accessibility Checker, Accessibility Developer Tools, Landmark Navigation y headingsMap.

3. Simulación

Siempre podemos ponernos en los zapatos de las personas con discapacidad. Existen extensiones que nos permiten esto, tales como Web Disability Simulator, Funkify (mi favorita), entre otras.

En este punto, otro camino es que algún experto en tecnologías asistivas simule la navegación de personas con distintos tipos de discapacidad. Encuentro una genialidad que existan personas que tengan este tipo de skills, por favor enséñeme si es usted uno de esos.

4. Revisión del Código

Un front-end experto podría revisar cada línea del código.

Super, ya hablamos de herramientas, pasemos a las personas. Algo que siempre he querido hacer es testear con usuarios con discapacidad, he tenido la oportunidad de hacerlo, pero me gustaría que fuera parte de mi quehacer diario y que se incorporara en la metodología de trabajo. Tal como comenté más arriba, probar con usuarios siempre es lo mejor. En ese sentido veo dos caminos:

4.1 Pruebas con Expertos

Nadie es más experto en discapacidad que una persona con discapacidad. Expertos en accesibilidad existen y pueden tener discapacidad o no, a mi me gustaría sumar al equipo a una persona que sea experta en el uso de tecnología asistiva y que tenga algún tipo de discapacidad. De ese modo lograría derribar prejuicios, generaría espacios de trabajo inclusivos y se volvería un acto político.

4.2 Pruebas con Usuarios

Las personas con discapacidad no solo son expertos en la tecnología sino que son expertos sobre su propia discapacidad. Hablar con ellos nos permitiría evidenciar los distintos grados de relación con la tecnología. Como todo en la vida, hay gente que se peina con la tecnología y gente que no, no tiene por qué ser diferente cuando nos referimos a personas con discapacidad.

Consideraciones clave para Diseñar Productos Accesibles

Hemos hablado del qué hacer para llevar a la práctica un testeo de accesibilidad, pero quisiera profundizar sobre el cómo hacerlo cuando lo hacemos con usuarios con discapacidad.

Lo primero es siempre buscar un entorno que sea accesible. En ese sentido nada es más accesible que su propia casa. Imaginen que nuestro participante es usuario de Mac y lo hacemos ir a nuestro laboratorio donde le pasamos un Windows. ¡Nefasto! O peor aún, la persona viaja hasta nuestra oficina con todo al hombro, no solo es incómodo sino que además representa un riesgo innecesario. Si no puedes ir tú a su casa o lugar de trabajo, hazlo online.

Siguiendo en esa línea, los usuarios con discapacidad deben usar su propia tecnología. Tal como comenté, cada uno personaliza su tecnología y crea una estrategia propia, no necesitamos someterlos a estrés, necesitamos que prueben nuestros productos digitales.

El filtro de selección debería considerar usuarios intermedios, si son expertos en alguna tecnología, difícilmente podremos observar oportunidades de mejora, y si son totalmente inexpertos, vamos a creer que lo hicimos pésimo.

Los test con usuarios con discapacidad son los únicos que aseguran el éxito de nuestros productos. Hay que tomarlos en serio.

Una mini reflexión final

En Latinoamérica, de momento hay pocos especialistas en accesibilidad. Debemos iniciar la formación masiva de especialistas y comenzar lo antes posible. Ya existe una ley y sabemos que pronto vendrán las multas, por eso no hay mejor momento para aprender que ahora. Y lo haremos porque el diseño inclusivo es simplemente lo correcto.

No tiene sentido seguir creando casos de negocio, la discapacidad es una realidad y como diseñadores tenemos que hacernos cargo de la accesibilidad y UX. Al principio no será perfecto, pero será mejor que lo que existe.

Las personas con discapacidad, hoy más que nunca, claman por una vida digna y el reconocimiento de sus derechos. No me cabe duda que la pandemia está acelerando la necesidad de diseñar productos y servicios accesibles.

Tenemos la oportunidad única de transformarnos en profesionales clave. Hagámoslo. Generemos el impacto que soñamos con diseño accesible, empoderemos a nuestros usuarios dándoles lo más importante: autonomía.

---

Otros contenidos relacionados

Recursos clave para evaluar la Accesibilidad de un Sitio Web

Accesibilidad web para diseñadores

Shift Left a11y: ¿cómo incluir la accesibilidad lo antes posible en los proyectos?

ARC Toolkit: Explorando una Herramienta para evaluar la Accesibilidad Web