 Pues seguimos con la siguiente ponencia. ¿Cuántos tenéis en cuenta la accesibilidad cuando diseñáis una página web? Aquí manos, vergonza se hace así. Cuando hablamos de accesibilidad, normalmente pensamos en personas con dificultades visuales o invidentes totales, personas sordas, personas con dificultades motoras o cognitivas. Pero normalmente nos olvidamos de dos grandes grupos. Los que tienen visión genital y los que tenemos miopía selectiva, que es la de que no vemos nada de cerca, pero a los hilly flies los vemos acercarse desde lejos. Yo espero que nuestra próxima ponente no se olvide de esos dos grandes grupos. Eva Marco, que es la que va a dar la charla ahora, es arquitecta técnica de formación, aunque a día de hoy se gana la vida con el desarrollo web. Seguramente la hayáis visto en otras charlas, tanto a nivel nacional como internacional y otros eventos, porque aparte de ser muy activa en ello, es una persona que está en continua formación, tanto aprendiendo como enseñando lo que sabe. Desde hace algo más de un año, trabaja en Kaleidos Open Source, que es una empresa dedicada al desarrollo de software. Y ella en concreto está en el equipo de Penpod, que seguramente lo conozca, que es una herramienta de prototipado web. Ahora la voy a dar paso a ella, porque nos va a hablar, nos va a contar su experiencia en el desarrollo de esta herramienta, pero no a nivel general, sino de esos baches con los que se ha encontrado a la hora de tratar las cuestiones de accesibilidad. Así que, por favor, vamos a dar un fuerte aplauso que salga, oigan, el pueblo del lado, a Eva Marcos. Bueno, primero, muchas gracias a todos por haber venido, no estoy sola, me alejo. Muchas gracias a la organización para tenerme aquí. Y vamos a empezar. Hace unos meses recibimos en nuestro proyecto de GitHub, está ISU. La ISU pone el mejor momento para pensar en accesibilidad, es al principio del proyecto. El siguiente mejor momento es ahora. Cuando recibimos esto, a mí se me despertaron todas las alarmas, dije, creo que Penpod no es nada accesible, y así era. Así que reunimos al equipo y nos pusimos manos a la hora de ver qué problemas teníamos y cómo podíamos solucionarlo. Pero bueno, ya me han presentado, así que esto va a pasar muy rápido. Eso lleva desarrolladores software, Trabajo en Caleidos, que es una empresa que se dedica exclusivamente al desarrollo de productos open source, y trabajamos en dos productos. Taiga, que es una herramienta para gestión de proyectos, y Penpod. Penpod es una herramienta de diseño y prototipado web. Se usa dentro del browser, así que podéis usarlo en cualquier plataforma, ya sea Mac, Windows, lo que queráis. Es open source, tenemos el código abierto en GitHub, podéis mirar todo lo que hacemos, ponernos ISUs, lo que queráis. Y uno de nuestros objetivos principales es que los desarrolladores y diseñadores se sientan a gusto trabajando juntos. En el mismo espacio, que no tengan dos parcelas diferentes. También tenemos una comunidad a la que podéis conectaros y comentar las opiniones que tengáis, darnos feedback, etc. Y bueno, hemos venido a hablar de accesibilidad. Para mí esta es una definición muy básica. Acesibilidad es la cualidad de ser fácilmente comprensible, apreciado y usado. ¿Cómo conseguimos esto? Pues el principal objetivo es tener un equipo lo más diverso posible. Si nuestro equipo no es diverso, porque las circunstancias ocurren en el país en el que estamos, tenemos que intentar pensar de qué manera otras personas van a usar nuestra herramienta. Y no quedarnos solo, yo lo uso, a mí me vale, ya está bien, con esto ya está todo hecho. Y otra manera es intentar hacer un diseño más inclusivo desde la parte de diseño. Pero bueno, hablando de cifras, la OMS dice que el 15% de la población mundial sufre algún tipo de discapacidad permanente. ¿Qué os parece esta cifra? Equivale a un billón de personas. Es muy alta. Pues para mí tiene muchísima trampa esta cifra. Vamos a hacer un jueguito, un segundito. GPS. Ya ha llegado. Vale, levantar todos la mano, un segundito. Ahora, bajar la mano, aquellos que uséis gafas, un bastón, una hacía de ruedas, etcétera, etcétera. Vale, ahora, bajar la mano, todos aquellos que uséis modo oscuro en el navegador, en la herramienta de diseño, etcétera, etcétera. Vale, ahora, todos los que uséis zoom en vuestro móvil, para ver la letra pequeñita. Y ahora, todos los que uséis subtítulos en las series de Netflix. Vale, de la sala me quedan tres personas. Ese 15% lo acabamos de tirar por el suelo. Somos muchos más los que necesitamos en nuestra vida a diaria algún tipo de accesibilidad en las herramientas que usamos cada día. Así que el truco está en que hablan de discapacidades permanentes. Pero discapacidades hay muchas. Normalmente, como ha dicho antes, Lidia, entendemos discapacidad por los grandes grupos de discapacidades permanentes, que son visual, cognitiva, motora, etcétera, etcétera. Pero también hay otra clasificación de discapacidades. Las discapacidades permanentes son aquellas que no cambian a lo largo del tiempo. Por desgracia, si tenemos una de estas discapacidades, no es previsible que mejore a lo largo del tiempo. Pero también existen las discapacidades temporales. Como me rató un brazo, es posible que ese brazo mejore a lo largo del tiempo. Ahora mismo no puede usarlo, pero en un futuro sí podré. Y luego, por último, tenemos las situaciones discapacitantes. Estas nos pueden ocurrir a cualquiera en un momento muy corto de tiempo y dependen del lugar donde nos encontremos o en el momento en el que estemos. Y puede ser, por ejemplo, tengo un niño en brazos, no puedo usar esa mano si tengo un niño en brazos. O estoy en la playa disfrutando del sol y me llega un mensaje al móvil y no lo veo porque la pantalla refleja y entonces no soy capaz de leerlo. Pues eso es un poco las discapacidades y lo que tenemos que tener en mente a la hora de pensar en accesibilidad. Y bueno, solo deciros, esos son los cuatro principios de la accesibilidad y quiero que os quedéis con la idea de si no lo puedo percibir, ya sea por vista, por tacto, por oído, no existe para mí. Si lo puedo ver, pero no lo entiendo, sigue sin existir para mí. Vale, ahora pongamos que lo veo o lo siento o lo oigo y además, lo puedo entender, pero está detrás de un cristal. No lo puedo tocar, de nada me vale. Y ahora decís, ya tengo mi aplicación que la puedo ver, la puedo entender, la puedo usar, pero me he cambiado de móvil y en mi móvil nuevo tampoco lo puedo usar. Pues de nada me vale que exista. Así que estos son los principios que también tenemos que tener en cuenta la hora de diseñar. Y bueno, es muy triste tener que hablar de beneficios de la accesibilidad porque para mí el principio es que todos tenemos el derecho de poder acceder a la información y eso es lo que nos da la accesibilidad. Pero si necesitáis más, cuando una página o una aplicación web es accesible, el usuario que la usa va a estar cómodo usándolo y si está cómodo volverá a nuestra plataforma una y otra vez. Si vuelvo una y otra vez, es muy posible que le diga a su amigo oye, esta plataforma está guay, me siento cómoda, oye, úsala tú también. Y entonces nuestra marca mejora respecto a la competencia. Y dentro de poco, como último dato, la accesibilidad va a ser obligatoria por ley. Ya está siendo obligatoria la administración pública, pero dentro de poco va a ser obligatoria a nivel global sobre el 2025. Así que si nos ponemos las pilas ahora, es posible que nos ahorremos alguna multa dentro de poco. Y bueno, hemos venido a hablar de herramientas de diseño. Acesibilidad sobre todo, pero realmente es de diseño. Y aquí yo pongo el foco en dos cosas diferentes. Una, widgets o herramientas accesibles, accesorias a lo que es la aplicación que nos permiten crear unos diseños muy accesibles para el exterior y la interfaz de la propia herramienta que tiene que ser accesible para nuestro beneficio. Y esta es la que casi siempre se olvida. Pero vamos a empezar a hablar por el primero. Los accesorios de diseño o widgets. Y bueno, os traigo un par de ejemplos para que veáis un poco la cantidad de ellos que hay. Y el primero es Star, que aparte de una familia de juego de trunos, es una aplicación de, o sea, es un widget para varias aplicaciones de diseño y además puede ser usada en como extracción de Chrome. Con Star, por ejemplo, podemos comprobar problemas como contraste de colores en una fuente más legible que otra. Podemos, nos recuerda, sobre todo, añadir texto alternativo en nuestras imágenes. Y lo más curioso es que nos podemos diseñar con ella el flujo del focus para dárselo al desarrollador y que sepa de dónde a dónde va a ir el foco o tiene que ir el foco una vez el desarrollo. Otra herramienta que nos ayuda con un tema totalmente diferente de la accesibilidad es lo caláis. Lo caláis nos ayuda a internacionalizar nuestras páginas o nuestros diseños, en este caso. No es lo mismo una palabra en español, que puede ser cortita, que una palabra en alemán. Entonces, con esta herramienta, puedes proponerle qué idiomas quieres ver tu diseño, coge los textos y te los cambia al idioma. A lo mejor no es exactamente verídico lo que te pone, pero más o menos te adapte el contenido a ese idioma. Entonces puedes ver si tu contenido se adapta o no. Por último, os traigo otro widget, que este es una extensión de Chrome. Que a mí me encanta. Hay otras muchas. Y esta es lo que haces ponerte en la piel de una persona que sufre una discapacidad. Ya puede ser una discapacidad visual, como un daltonismo o una cegra parcial. Pero también te pone en situación de una persona que tenga dificultades motoras para mover el ratón, una persona anciana que ve borroso, o una persona que está hiperestimulada y que empiezan a salir pop-ups. Lo más curioso de esto es que también te pone en la piel de esa persona que está en la playa, coge el móvil y le brilla demasiado. Pues también lo puedes sustituir con esta herramienta. Y bueno, ahora vamos a lo que son las interfaces, que os digo que son las más olvidadas de, yo creo, el tema de accesibilidad en diseño. WebAIM hizo un estudio en un millón de páginas web y de ese millón de páginas estudiadas salió que el 98% de ellas no cumplían con los estándares doble A ni triple A. Todas tenían muchos errores. Y entre esos errores, los principales que salieron fueron estos, errores de color de contraste entre texto y el fondo, como veis en la imagen las diferencias entre uno, un botón con un problema de contraste y otro. Botones sin nombre, que eran un icono y una persona que no viese el icono o no entendiese, no sabía lo que era ese botón. Es el típico input que tú tienes que escribir, pero no sabes si tienes que escribir tu nombre, tu apellido, tu profesión, porque no pone nada alrededor. Ese tipo de errores, ¿vale? Y entonces, lo que hice yo para preparar esta charla fue estudiar un par de herramientas, la mía y otra, para ver cómo andaban de accesibilidad, ¿vale? Para hacer este pequeño test, he usado una herramienta que puedes obtener, o sea, estar en las DevTools de Chrome de manera gratuita, es muy fácil de usar, muy intuitiva, y te da un pequeño análisis de cómo está tu página y te comentan los errores principales que puedes tener. En la interfaz de trabajo de Figma salían estos errores, input sin label, botones sin nombre, errores de contraste, ¿no suenan, verdad? Son esos errores tan comunes que aparecen una y otra vez en las páginas web. Y le daba 70 puntos de accesibilidad. No está mal. Lo mismo hice con Pempo, es primer día que abrimos aquella ISO y casi me he hecho llorar, ¿vale? Vuelves a lo mismo, botones sin nombre, errores de contraste, una y otra vez los mismos errores, pero nosotros nos daba 54 puntos. Dije yo, te no puede ser, tenemos que ponernos más a la hora. Chicos, os he dicho que hay que hacerlo ahora, es el momento de esa hora, no mañana, y tenemos que ponernos ya. Y entonces nos reunimos, hicimos un planning de trabajo, una auditoría interna, y después de esa auditoría llegamos a cumplir 100 puntos en accesibilidad con Lighthouse. Super bien. Eliminamos los errores de contraste, solucionamos esos inputs que no tenían nombre, esos botones que no tenían nombre, pusimos etiquetas más semánticas, evitamos poner los divs con un click, que es muy típico, pues hombre, si es un botón ponen por la etiqueta botón, no pongas div. Y ese tipo de errorcillos que vamos cometiendo con la marcha, y, oye, 100 puntos, y me diréis, ¿ya está? ¿Ya con eso hemos cumplido la accesibilidad? Pues no. Hay mucho, mucho más, ¿vale? Los test estos automáticos nos valen para darle una pincelada y barrer un poco la casa, pero realmente hay mucho, mucho más para ser accesible. Entre las cosas que podemos hacer para hacer accesible, yo os propongo dos estrategias. Bueno, aquí tenéis varias, pero yo os propongo dos estrategias. Desenchufar el ratón de la aplicación, intentar navegar por vuestra página web solo con el teclado. Teclado, tabulador, espacio, intro, intentar navegar por ella, intentar acceder a vuestras cosas. Si no podéis, solucionadlo, y ahí ya tenéis un paso enorme dado. La siguiente estrategia, y si vuestra página lo permite, conectar un lector de pantalla, hacer un trabajo en el teatro, intentar escuchar esa vocecilla, intentar navegar, ver si os lleva donde queréis ver, y si no lleva, solucionadlo. Y ahí ya tenemos otro superavance. Y para mí, el otro tercer foco de superproblemas fue nosotros desarrollamos una aplicación propia, genérica, y creamos componentes propios. Y esos componentes son parecidos a los nativos de HTML, pero los HTML son feos, son feos. Y no se pueden darle estilo y gracia. Entonces, solemos hacerles crear uno nuevo y ponerle la funcionalidad básica. Pero siempre dejamos aparte el tema de accesibilidad el manejo por ratón, esas cosillas, siempre las dejamos como yo no lo uso, no me ha acordado de que esto se puede, que el intro también tiene que responder, etcétera, etcétera. Entonces si vosotros también hacéis esos componentes, darle una vuelta a esos componentes de accesibilidad que seguramente os la yais, o olvidad. Y bueno, después de todo este trabajo de unos test muy automáticos y todo el trabajo que he tenido que hacer para ello, me he dado cuenta que las guías que proponen la WCG quizás están quedando un poquito atrás, porque hasta ahora teníamos páginas súper informativas, un blog de viajes, una página de noticias y vamos y consumíamos información, pero pasamos poco más en la web. Y ahora cada vez más tenemos aplicaciones enteras dentro de la web con las que puedes hacer cosas, puedes generar contenido, quieres obtener un diseño, quieres, etcétera, etcétera. Y entonces estamos pasando de consultar acciones. Y en ese salto la WCG quizás, el estándar HTML, se está quedando un pelín atrás, quizás necesitamos nuevas etiquetas que representen un área de trabajo, o por decir algún ejemplo, ¿no? Y no todo lo que se hace accesibilidad en diseño es malo, ¿vale? También en las herramientas se están esforzando mucho. Y les voy a poder una pensión a la rápida de lo que hace un poquito cada herramienta. Por ejemplo, Figma tiene un modo para entrar en modo accesible. Le das un botón y puedes navegar con un lector de pantalla por todo tu diseño. XD, por ejemplo, tiene un prototipado que te permite hacer un trigger o algo, o sea, decirle al diseño hola y el diseño te saluda. Mola, ¿no? En PemPod, por ejemplo, estamos trabajando mucho como os he dicho, la navegación proteclada en todos los menús, etcétera, etcétera. Y de Sketch, la verdad que no cuentan nada de accesibilidad. Así que sé que tiene una cabinexión con VoiceOver pero poco más. Y bueno, lo que sí os puedo contar un poco más es que es lo que estamos trabajando en PemPod porque es donde estoy y lo que hay detrás de las cortinas. Por ejemplo, nuestra interfaz se puede poner en 16 idiomas diferentes que eso está bueno para ayudar a todo el mundo. Puedes poner los textos de izquierda a derecha y derecha a izquierda. Puedes hacer muchas acciones por atajos de teclado y otras cosillas. Pero no nos quedamos ahí y queremos llegar a más ahora mismo. Estamos haciendo una personalización de toda la interfaz añadiendo modo claro, modo oscuro intentando que todo sea un poquito más visualmente apreciable para la gente que entre y más accesible. Además, nos gustaría en un futuro que ese usuario pudiese personalizar esos colores, esos tamaños, espacios, etcétera. Queremos plantear un sistema de plugins para que nosotros o otra gente nos pueda hacer plugins de accesibilidad y ayudarnos a que los diseños creados en nuestra herramienta sean más accesibles. Y por soñar, prototipados accesibles por un screen reader que tú puedas interactuar con él y eso sería HTML, etcétera. Y ya por último me gustaría decir que la accesibilidad yo estoy hablando mucho de diseño, desarrollo porque eso es lo que soy pero no sólo es importante la accesibilidad para diseño y desarrollo creo que todo el equipo tiene que formar parte. Por ejemplo, el equipo de comunicación o de contenido puede preocuparse de que ese contenido esté claro, ordenado que no se jergas muy técnicas porque hay gente que no las va a poder entender y es fácil de encontrar dentro de tu página web. Y luego el equipo de negocio por ejemplo los jefes por los que tiene la pasta pueden encontrar formaciones para todo el equipo en cuanto a accesibilidad pueden hacer un estudio de users y un user research para encontrar qué beneficios de accesibilidad puedes conseguir en tu herramienta se pueden mover ahí tienen que hacer cosas no sólo pueden estar gestionando y bueno ya por último deciros que creo que es que la accesibilidad es para todos y a todos nos beneficia y sobre todo que en una herramienta de diseño no sólo tenemos que tener en cuenta que nuestro diseño hacia afuera sea súper súper accesible sino que tenemos que preocuparnos un poquito que en mi caso la herramienta de diseño que desarrollo en vuestro caso las páginas web que desarrolláis también tienen que ser accesibles para poder ser usadas muchas gracias bueno se va muchas gracias por la charla muchas gracias Marta una preguntita como desarrolladora tienes referencias o libros o lo que sea para formarnos sobre accesibilidad web las guías de WCAG son abiertas al público puedes encontrarlas fácilmente son un poco tostón son muy tostón pero siempre hay por ejemplo tiene unas páginas que están como depuradas de la WCAG que te son más fáciles y ahí vas a encontrar las guías principales para acceder luego en internet tengo varios usuarios que sí que genera mucho contenido de accesibilidad mucho más cercano que te los puedo luego pasar los enlaces para que puedas seguirlos y ahora mismo estoy en un grupo de Slack que se comparte muchísima información a veces es hasta brumadora la cantidad de información que hay detrás por eso que os digo del gap que desde las guías de WCAG a la experiencia real hay un buen salto y ese salto lo cubrimos hablando entre nosotros y viendo a ver cuál es la solución pero si empiezas por WebAim tiene unas buenas páginas que son más accesibles para la persona humana no para el técnico técnico Marta puede seguir ahí dándole hola buenas gracias por la charla respecto a WordPress hay algún plugin en concreto plugins que recomiendes vale, me has pillado ahí pero yo no trabajo en WordPress yo trabajo desarrollando esta herramienta pero por lo que he visto abajo el plugin es bastante accesible porque el otro compañero Iñaki estaba usando directamente con un lector de pantalla y ha generado una página básica y yo estoy utilizando solo el lector de pantalla el editor de bloques no te sé decir la verdad, lo siento porque yo no trabajo en mi día a día WordPress y ayer en la cena de ponentes sí que me he comentado una chica que ella tiene un post con información de accesibilidad ella es Mariana también dándole una charla dentro de un rato por la tarde así que quizá le puedes preguntar a ella específicamente temas de WordPress si venga dale otra una pregunta siempre está como el rollo de la reacción entre diseño y desarrollo en temas de accesibilidad como lo ves o sea como ves que el diseñador le diga al desarrollador todo el tema accesible no sé cómo explicarlo bien tenemos que tomar la accesibilidad como piedra angular de nuestro proyecto si no normalmente no funciona sí que es cierto que casi todos los proyectos empiezan primero por la fase de diseño y luego pasan a desarrollo entonces es normal que los diseñadores sean los que ponen la primera piedra en cuanto a esto tiene que ser así porque hay cosas que se van a poder arreglar en desarrollo pero hay muchas otras que si el diseño no es accesible no podemos hacer nada si tú me dices que yo tengo que poner un gris clarito sobre un blanco porque te gusta mucho porque tu diseño es así yo ahí te puedo decir esto no pasa pero si tú no lo arreglas yo no lo puedo solucionar luego sí que hay otros temas que tienen más que ver en cómo nos amañamos en diseño en desarrollo perdón y ya es cosa nuestra por ejemplo lo que decías tú me puedes indicar que el focus order va de está heading a este tal y a este cual y eso lo tengo que implementar yo y buscarme las mañas porque hay veces que el código nos lo pone difícil entonces para mí siempre tiene que andar un poco, empezar el diseño tirar del carro y a partir de ahí los diseñadores tenemos que apoyar esas decisiones y mejorarla puedes seguir muy buenas muchas gracias por la charla muchas gracias a ti y bueno por mi capacidad por el tipo yo su usar magnificadores o ampliadores de pantalla entonces lo que me suelo encontrar la mayoría de las veces los mayores problemas que tengo pues son tanto en aplicaciones como web es haciendo algo y como tengo un magnificador estoy en una zona de pantalla y el mensaje emergente está en cuenca y que no me estoy enterando entonces no sé si entiendo que en web pues es bastante complicado pero a nivel vuestro desarrollo vuestro proyecto no sé si esto porque entiendo que esto queda fuera de las guías no es un tema que se contemple se contempla la lectura de pantalla para los enviantes totales pero para los que tenemos baja visión hay un vacío legal ahí que da igual entiendo que es complicado saber en qué parte esto y yo porque eso que el navegador no lo tiene pero no sé si vosotros es sólo un obligado la verdad que me encantaría hablar un poco más contigo para ver cómo trabajas porque no lo sé exactamente pero nosotros en desarrollo si sabemos por ejemplo dónde está el foco es decir el área que está seleccionando si sabemos dónde está podemos saber dónde está el cursor y tendría que ver qué herramienta usas o qué hace para buscar ese punto que tú estás viendo y magnificarlo que no lo sé que lo tengo que investigar no te puedo decir seguro si es posible supongo que si es un área en concreto y ese área se hace más grande sabremos dónde está el foco y podríamos sacar las modales en ese foco que tú estás seguramente sea posible no exactamente lo que has dicho se sale de las guías el ABC de la accesibilidad porque se nos queda muy corto muchas veces pero seguramente sea posible así que si quieres luego me cuentas un poco más y así le eche yo un ojo y te puedo contestar mejor