Extrapolando cifras de la Encuesta de Microsoft realizada en el a\u00f1o 2003, solo un 21% de la poblaci\u00f3n no tiene ning\u00fan tipo de dificultad para navegar. Para esas personas estamos dise\u00f1ando. En ese sentido, cuando se dise\u00f1a y testea pensando en el 80\/20, en realidad se est\u00e1 dise\u00f1ando y testeando para el 80% de ese 21%. Reitero, falta de visi\u00f3n de producto, si entendi\u00e9ramos realmente a los usuarios (o si entendi\u00e9ramos al negocio), dejar\u00edamos de dise\u00f1ar para unos pocos.<\/p>\n\n\n\n
Usted, persona informada, podr\u00e1 cuestionar el dato del 21% argumentando que las personas con discapacidad alcanzan solo el 17% de la poblaci\u00f3n. \u00bfSe me perdi\u00f3 un 62% de personas?, jaja, no. En medio de estas dos cifras se encuentran todas aquellas personas que se ver\u00edan beneficiadas con la accesibilidad, ya sea porque tienen dificultades m\u00ednimas o medianas<\/strong>.<\/p>\n\n\n\n Avancemos.<\/p>\n\n\n\n Otra prueba de la falta de visi\u00f3n de producto de los dise\u00f1adores 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\u00e9s de nuestra intervenci\u00f3n. Literalmente estamos corriendo una posta.<\/p>\n\n\n \u00bfCu\u00e1ntos de nosotros damos por terminado el proyecto una vez que entregamos al equipo de desarrollo?<\/p>\n\n\n\n Dir\u00eda que la gran mayor\u00eda concebimos el dise\u00f1o bajo la mirada del Design Thinking<\/em>, pero la verdad es que el dise\u00f1o es solo una parte en la vida del producto<\/strong>. A\u00fan falta desarrollarlo, hacer las pruebas de calidad, lanzarlo, medir, optimizar la soluci\u00f3n y escalar.<\/p>\n\n\n\n En ese sentido, los dise\u00f1adores tenemos dos grandes deudas: entender al usuario bajo una mirada de inclusi\u00f3n, e involucrarnos en las siguientes etapas del producto.<\/p>\n\n\n\n Poco sabemos de accesibilidad. Tan poco, que estamos convencidos de que no se necesitan especialistas o que no tiene mayor costo su implementaci\u00f3n. Otra vez, la falta de mirada de dise\u00f1o de producto nos juega malas pasadas, porque no basta con dise\u00f1ar experiencias accesibles, deben implementarse y testearse para asegurar que lo que se dise\u00f1\u00f3 es lo que en definitiva le sirve a nuestros usuarios<\/strong>. De lo contrario, es solo una buena intenci\u00f3n y ya saben lo que dicen de las buenas intenciones, si no se concretan, no sirven.<\/p>\n\n\n\n Para que un producto sea accesible se requiere dise\u00f1o y desarrollo.<\/p>\n\n\n\n Por supuesto que s\u00ed necesitamos especialistas en accesibilidad, y no solo en dise\u00f1o, tambi\u00e9n en desarrollo y en calidad<\/strong>. Supongamos que todos los dise\u00f1adores son expertos en accesibilidad universal, desarrollo a\u00fan debe ser capaz de implementarlo y QA de testearlo.<\/p>\n\n\n\n \u00a1Obvio que es m\u00e1s caro!, m\u00e1s o menos el costo de un producto accesible subir\u00e1 un 15% adicional si se implementa desde el principio. Por dos razones: los especialistas cuestan dinero y los procesos son un poco m\u00e1s largos y requieren nuevas herramientas, que otra vez se traduce en m\u00e1s costos. Oye si subtitular los videos no es gratis. Otra cosa es que sea un costo justificado que ahorrar\u00e1 dinero m\u00e1s adelante, pero no cuesta lo mismo.<\/p>\n\n\n\n Tal vez usted que me lee ahora ya cuenta con una soluci\u00f3n y se pregunta cu\u00e1nto le va a salir mejorar su sitio, estimo al ojo que un 25-30% del costo inicial. As\u00ed es que s\u00ed, siempre es mejor hacerlo desde el principio, porque hacer un plan de mitigaci\u00f3n no es muy simple. Y re-dise\u00f1ar un producto para que sea accesible una vez construido ser\u00e1 mucho m\u00e1s costoso.<\/p>\n\n\n\n Trabajar en dise\u00f1o y apostar por la inclusi\u00f3n es una batalla campal.<\/p>\n\n\n\n Hay que convencer a otros dise\u00f1adores de que la accesibilidad es parte de su trabajo. Me ha pasado que m\u00e1s de alguno me ha asegurado que sus usuarios no tienen ning\u00fan tipo de discapacidad.<\/p>\n\n\n\n Siempre pongo el caso de un ex compa\u00f1ero de trabajo, Javier, que es dalt\u00f3nico (trabajamos con visualizaci\u00f3n de datos, as\u00ed es que adem\u00e1s de PO jugaba de tester funcional). Javier una vez gritaba en la oficina porque quer\u00eda comprar una polera roja para la novia y no pod\u00eda escogerla. Es completamente inaceptable que un usuario no pueda realizar una compra de forma aut\u00f3noma.<\/p>\n\n\n\n Ahora imaginen a Mar\u00eda Jos\u00e9, desarrolladora y UX con discapacidad auditiva. A ella le encanta estudiar, pero sin subt\u00edtulos, simplemente no puede seguir una clase online.<\/p>\n\n\n\n Una vez que entendemos la urgencia de implementar la accesibilidad en el dise\u00f1o<\/strong>, siguen las disputas con el contenido. \u00bfQu\u00e9 informaci\u00f3n vamos a complementar para el screen reader<\/em>?, \u00bfqu\u00e9 informaci\u00f3n vamos a ocultar?, \u00bfcu\u00e1l ser\u00e1 el nombre de esta p\u00e1gina?, \u00bfcu\u00e1les ser\u00e1n los textos alternativos?, suma y sigue.<\/p>\n\n\n\n Hace un par de a\u00f1os, con un grupo de amigos y amigas creamos el colectivo CADA<\/a> para estudiar temas asociados a la accesibilidad y lanzamos una encuesta (juro que publicaremos los resultados en junio). Le preguntamos a los especialistas del \u00e1rea TI c\u00f3mo garantizan la accesibilidad de sus productos. En sus respuestas nos comentaron de los tama\u00f1os de los botones, el uso de contrastes y las jerarqu\u00edas. Todo eso est\u00e1 muy bien, pero no es suficiente.<\/p>\n\n\n\n \u00bfC\u00f3mo hacen el handoff<\/em> 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\u00f3n con el equipo de desarrollo.<\/p>\n\n\n\n Hace poco dise\u00f1\u00e9 una plataforma perfectamente jerarquizada, pero lo que se implement\u00f3 fueron p\u00e1rrafos con distintos estilos, de modo que no exist\u00eda una estructura que permitiera a los usuarios navegar mediante tecnolog\u00eda asistiva. No solo eso, los botones no ten\u00edan cambio de estado. Descubr\u00ed todo eso -y m\u00e1s-, porque inspeccion\u00e9 el c\u00f3digo, navegu\u00e9 por teclado y us\u00e9 el screen reader<\/em>. Lo que quiero decir es que se ve\u00eda como lo dise\u00f1\u00e9, pero no era lo que dise\u00f1\u00e9 y sin embargo las pantallas hab\u00edan sido aprobadas por el equipo QA.<\/p>\n\n\n\n A\u00fan existen desarrolladores que no saben implementar c\u00f3digo sem\u00e1ntico, ni hablemos de aria-label<\/em>. En mi experiencia, solo los front-end<\/em> trabajan con criterios de accesibilidad, pero las empresas tienen desarrolladores full-stack<\/em>, y tengo la impresi\u00f3n de que est\u00e1n m\u00e1s interesados en el back que en el front. Otra vez, necesitamos especialistas.<\/p>\n\n\n\n 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. \u00bfSoy una vende humo? Capaz. He estudiado mucho para disminuir esa brecha, solo para llegar a la conclusi\u00f3n de que necesito un equipo de alto nivel.<\/p>\n\n\n\n Algunas personas con discapacidad utilizan software y hardware especializado, por ejemplo la l\u00ednea braille utilizada por personas ciegas y sordociegas. Otras podr\u00edan ajustar la configuraci\u00f3n de sus dispositivos, bastar\u00eda con modificar las preferencias de la plataforma y del navegador por ejemplo activando las preferencias de accesibilidad o algo m\u00e1s cotidiano, activando los subt\u00edtulos. Adem\u00e1s encontramos la tecnolog\u00eda asistiva que permite a la persona con discapacidad interactuar con el contenido de la pantalla<\/strong>.<\/p>\n\n\n\n Esta \u00faltima, a su vez, puede ser general o espec\u00edfica. A modo de ejemplo, el teclado o el zoom del navegador son tecnolog\u00edas generales; mientras que el aud\u00edfono o el dispositivo dits son tecnolog\u00edas espec\u00edficas. Adem\u00e1s puede ser implementada a trav\u00e9s de un dispositivo externo o por software. Un dispositivo externo podr\u00eda ser el puntero de cabeza; un software podr\u00eda ser el control de voz.<\/p>\n\n\n\n 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\u00eda. Hacer eso, tambi\u00e9n podr\u00eda llevarte a resultados err\u00f3neos.<\/p>\n\n\n\n Los test autom\u00e1ticos solo cubren un 30% de los casos. Por ejemplo, puede validar que exista la etiqueta alt, pero no ser\u00e1 capaz de validar que el texto sea necesario o no, o si siendo necesario, este tenga sentido para el usuario. De modo que s\u00ed, los utilizaremos, pero su resultado no nos puede dejar conformes, de lo contrario volvemos al autoenga\u00f1o del que les habl\u00e9 al inicio.<\/p>\n\n\n\n Lo mejor ser\u00eda testear siempre con personas con discapacidad. Pero podemos hacer cuatro cosas en forma paralela.<\/p>\n\n\n\n Existen herramientas que localizan problemas o posibles problemas y los presentan. Estoy pensando en herramientas como Siteimprove<\/a>.<\/p>\n\n\n\n Tambi\u00e9n podr\u00edamos utilizar extensiones que nos permitan explorar y generar un diagn\u00f3stico. Aqu\u00ed aparecen extensiones como Web Developer<\/a>, WAVE Evaluation Tool<\/a>, Siteimprove Accessibility Checker<\/a>, Accessibility Developer Tools<\/a>, Landmark Navigation<\/a> y headingsMap<\/a>.<\/p>\n\n\n\n Siempre podemos ponernos en los zapatos de las personas con discapacidad. Existen extensiones que nos permiten esto, tales como Web Disability Simulator<\/a>, Funkify<\/a> (mi favorita), entre otras.<\/p>\n\n\n\n En este punto, otro camino es que alg\u00fan experto en tecnolog\u00edas asistivas simule la navegaci\u00f3n de personas con distintos tipos de discapacidad. Encuentro una genialidad que existan personas que tengan este tipo de skills<\/em>, por favor ens\u00e9\u00f1eme si es usted uno de esos.<\/p>\n\n\n\n Un front-end<\/em> experto podr\u00eda revisar cada l\u00ednea del c\u00f3digo.<\/p>\n\n\n\n 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\u00eda que fuera parte de mi quehacer diario y que se incorporara en la metodolog\u00eda de trabajo. Tal como coment\u00e9 m\u00e1s arriba, probar con usuarios siempre es lo mejor. En ese sentido veo dos caminos:<\/p>\n\n\n\n Nadie es m\u00e1s experto en discapacidad que una persona con discapacidad. Expertos en accesibilidad existen y pueden tener discapacidad o no, a mi me gustar\u00eda sumar al equipo a una persona que sea experta en el uso de tecnolog\u00eda asistiva y que tenga alg\u00fan tipo de discapacidad. De ese modo lograr\u00eda derribar prejuicios, generar\u00eda espacios de trabajo inclusivos y se volver\u00eda un acto pol\u00edtico.<\/p>\n\n\n\n Las personas con discapacidad no solo son expertos en la tecnolog\u00eda sino que son expertos sobre su propia discapacidad. Hablar con ellos nos permitir\u00eda evidenciar los distintos grados de relaci\u00f3n con la tecnolog\u00eda. Como todo en la vida, hay gente que se peina con la tecnolog\u00eda y gente que no, no tiene por qu\u00e9 ser diferente cuando nos referimos a personas con discapacidad.<\/p>\n\n\n\n Hemos hablado del qu\u00e9 hacer para llevar a la pr\u00e1ctica un testeo de accesibilidad, pero quisiera profundizar sobre el c\u00f3mo hacerlo cuando lo hacemos con usuarios con discapacidad.<\/p>\n\n\n\n Lo primero es siempre buscar un entorno que sea accesible. En ese sentido nada es m\u00e1s 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. \u00a1Nefasto! O peor a\u00fan, la persona viaja hasta nuestra oficina con todo al hombro, no solo es inc\u00f3modo sino que adem\u00e1s representa un riesgo innecesario. Si no puedes ir t\u00fa a su casa o lugar de trabajo, hazlo online.<\/p>\n\n\n\n Siguiendo en esa l\u00ednea, los usuarios con discapacidad deben usar su propia tecnolog\u00eda<\/strong>. Tal como coment\u00e9, cada uno personaliza su tecnolog\u00eda y crea una estrategia propia, no necesitamos someterlos a estr\u00e9s, necesitamos que prueben nuestros productos digitales.<\/p>\n\n\n\n El filtro de selecci\u00f3n deber\u00eda considerar usuarios intermedios, si son expertos en alguna tecnolog\u00eda, dif\u00edcilmente podremos observar oportunidades de mejora, y si son totalmente inexpertos, vamos a creer que lo hicimos p\u00e9simo.<\/p>\n\n\n\n Los test con usuarios con discapacidad son los \u00fanicos que aseguran el \u00e9xito de nuestros productos. Hay que tomarlos en serio.<\/strong><\/p>\n\n\n\n En Latinoam\u00e9rica, de momento hay pocos especialistas en accesibilidad. Debemos iniciar la formaci\u00f3n masiva de especialistas y comenzar lo antes posible. Ya existe una ley y sabemos que pronto vendr\u00e1n las multas, por eso no hay mejor momento para aprender que ahora. Y lo haremos porque el dise\u00f1o inclusivo es simplemente lo correcto.<\/p>\n\n\n\n No tiene sentido seguir creando casos de negocio, la discapacidad es una realidad y como dise\u00f1adores tenemos que hacernos cargo de la accesibilidad y UX. Al principio no ser\u00e1 perfecto, pero ser\u00e1 mejor que lo que existe.<\/p>\n\n\n\n Las personas con discapacidad, hoy m\u00e1s que nunca, claman por una vida digna y el reconocimiento de sus derechos. No me cabe duda que la pandemia est\u00e1 acelerando la necesidad de dise\u00f1ar productos y servicios accesibles<\/strong>.<\/p>\n\n\n\n Tenemos la oportunidad \u00fanica de transformarnos en profesionales clave. Hag\u00e1moslo. Generemos el impacto que so\u00f1amos con dise\u00f1o accesible, empoderemos a nuestros usuarios d\u00e1ndoles lo m\u00e1s importante: autonom\u00eda.<\/p>\n\n\n\n Recursos clave para evaluar la Accesibilidad de un Sitio Web<\/a><\/p>\n\n\n\n Accesibilidad web para dise\u00f1adores<\/a><\/p>\n\n\n\n Shift Left a11y: \u00bfc\u00f3mo incluir la accesibilidad lo antes posible en los proyectos?<\/a><\/p>\n\n\n\n ARC Toolkit: Explorando una Herramienta para evaluar la Accesibilidad Web<\/a><\/p>\n\n\n\n![\"Gap](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2021\/05\/GAP-diseno-accesible-1024x331.png\")
<\/figure>\n\n\n\n![\"Dise\u00f1o](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2021\/05\/diseno-testing-productos-digitales-accesibles-1024x511.png\")
Asegurar la Accesibilidad<\/strong><\/h2>\n\n\n\n
Lo que callamos los Dise\u00f1adores<\/h2>\n\n\n\n
Pensar que las personas con discapacidad no usan la web es una visi\u00f3n sesgada y violenta.<\/strong><\/h3>\n\n\n\n
Navegaci\u00f3n de las Personas con Discapacidad<\/strong><\/h2>\n\n\n\n
\u00bfC\u00f3mo testeamos la Accesibilidad?<\/strong><\/h2>\n\n\n\n
Testear la Accesibilidad<\/strong><\/h3>\n\n\n\n
1. Evaluaci\u00f3n guiada<\/strong><\/h3>\n\n\n\n
2. Inspecci\u00f3n utilizando Herramientas<\/strong><\/h3>\n\n\n\n
3. Simulaci\u00f3n<\/strong><\/h3>\n\n\n\n
4. Revisi\u00f3n del C\u00f3digo<\/strong><\/h3>\n\n\n\n
4.1 Pruebas con Expertos<\/strong><\/h4>\n\n\n\n
4.2 Pruebas con Usuarios<\/strong><\/h4>\n\n\n\n
Consideraciones clave para Dise\u00f1ar Productos Accesibles<\/strong><\/h2>\n\n\n
![\"Importancia](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2021\/05\/testear-la-accesibilidad-web-1024x606.jpg\")
<\/figure><\/div>\n\n\nUna mini reflexi\u00f3n final<\/h3>\n\n\n\n
\n\n\n\nOtros contenidos relacionados<\/h3>\n\n\n\n