Notas sobre mis aprendizajes: más allá de diseñar inclusivamente (4/4).
3: Handoff
Una vez diseñada la propuesta, hay que realizar el handoff a los desarrolladores, donde la entrega no debería limitarse solo a las pantallas y componentes visuales:
1. Diseñar y comunicar el orden de lectura de los elementos, directamente relacionado con la jerarquía del código, para garantizar que los lectores de voz sigan el orden correcto.
Este aspecto debe estar vinculado con las decisiones de diseño visual, que también influyen en el orden de lectura, considerando las necesidades y la proximidad entre elementos al definir el orden. Por ejemplo, si hay tres tarjetas con imágenes y descripciones, es común cometer el error de no definir el orden de lectura, lo que provoca que los lectores de voz lean primero todas las imágenes, luego los títulos y finalmente las descripciones, cuando deberían ser leídos como grupos. El plugin de Figma A11y ayuda a definir el orden y documentarlo.
2. Diseñar y comunicar cómo funcionan los elementos interactivos con el teclado:
- Diseñar y comunicar el orden de focus, que debería ser en su mayoría igual al del lector de voz, para una experiencia de usuario consistente.
- Considerar el diseño de la navegación no solo con la tecla Tab, sino también con el uso de las flechas, la barra espaciadora, Enter para activar controles y combinaciones, como Shift + Tab para retroceder.
- Evaluar la necesidad de saltear elementos, incorporando controles adecuados. Por ejemplo, en los menús desplegables de la barra de navegación, permitir la omisión de abrir el listado de cada elemento del menú para descomplejizar la interacción.
3. Definir las áreas interactivas como parte de la documentación, y tambien del proceso de construcción de los componentes en Figma.
Por ejemplo, en el caso de una tarjeta con un botón de “ver más”, no es necesario que sólo el botón sea el área clickeable. Se puede evitar fricciones y complejidades al hacer clic en áreas pequeñas, y diseñar toda la tarjeta como una zona clickeable. Esto garantiza una experiencia de usuario más intuitiva y reduce la posibilidad de errores al interactuar con la interfaz.
4. Evitar las automatizaciones.
Por ejemplo, el “auto-play” en audios o videos. En algunos casos se usa con la excusa de evitar una interacción, pero también con el objetivo de forzar a verlos o escuchar el contenido. Este enfoque puede resultar intrusivo y molesto para cualquier usuario, pero para aquellos con diversidades cognitivas o motoras, puede ser especialmente problemático.
5. Ser cuidadosos al optar por abrir una nueva pestaña en lugar de permanecer en la página actual.
Al igual que en el punto anterior, esta decisión puede generar complicaciones para los usuarios que necesitan retroceder usando solo el teclado, y aún más para aquellos que dependen de lectores de voz. No está mal utilizar esta función, pero es importante hacerlo de manera consistente y comprender el motivo detrás de ello (por ejemplo, para enlaces externos).
6. Evitar crear elementos con medidas fijas y, en su lugar, documentar tanto los valores mínimos como máximos, junto con sus comportamientos responsive.
Utilizar medidas fijas puede complicar la adaptación de la interfaz a diferentes dispositivos y configuraciones, como la utilización de magnifiers o el aumento del tamaño tipográfico. Los tamaños fijos pueden dificultar el acceso a partes del contenido y limitar la experiencia de usuario.
7. Documentar todos los comportamientos que influyen en la experiencia del usuario.
Por ejemplo, cuando se está cargando un proceso y se muestra un spinner, es importante determinar qué elementos deben desactivarse y cuáles deben permanecer activos. Esto permite al usuario comprender qué acciones están disponibles y cuáles están en espera.
4: El código.
1. Mantener una estructura jerárquica coherente en el código.
Por ejemplo, si no hay un elemento h1, no se deben utilizar elementos h2. Por qué? Porque esta práctica es esencial para que los lectores de pantalla puedan interpretar correctamente el tipo de elemento y su jerarquía en la página.
2. Usar landmarks o semantic tags para proporcionar orientación al usuario sobre el elemento, incluyendo información como qué es el objeto, cuál es su estado y qué función cumple. Por ejemplo, etiquetas como “link [label]”, “visited link [label]”, “menu with 5 items”, “end of list”. Esto es especialmente útil para la orientación de los usuarios, principalmente aquellos que utilizan lectores de pantalla.
3. Incluir subtitles y audio description a los videos, como asi también transcripts, incluso para audios.
Esto es fundamental para incluir a personas con diversidades auditivas, pero además los transcripts también benefician a aquellos con diversidad de memoria, asi como también mejora el SEO (Search Engine Optimization).
4. Tener cuidado con el contenido multimedia incrustado, donde el usuario puede perder el control del teclado.
Por ejemplo, cuando se incorpora un video de YouTube, al reproducirlo, el focus se desplaza al interior del video para permitir su control. Esto puede dificultar al usuario volver al resto del contenido que no está incrustado. Por lo tanto, si es posible, se recomienda evitar este tipo de contenido o diseñar una manera clara de navegar dentro y fuera de él.
5. Nunca sobreescribir, sino respetar los settings preferenciales de los usuarios por sobre nuestras decisiones de producto, ya sean del browser o del sistema.
Si un usuario ha seleccionado el dark mode, tamaños de tipografía específicos, la reducción del movimiento o incluso una fuente personalizada, puede no ser solo por preferencia estética. Por ejemplo, hay determinadas tipografías que ayudan a personas disléxicas a leer con mayor facilidad. Por lo tanto, debemos asegurarnos de mostrar el contenido de acuerdo con esas preferencias y no ignorarlas en aras de mejorar el aspecto estético.
6. No olvidar de programar los elementos temporales de feedback (como los toasts), de manera que puedan ser leídos por los lectores de voz y, además, permitir la interacción con ellos a través del teclado en caso de tener alguna acción asociada.
5. Test.
1. Validar contrastes y cambios de color o focus con el inspector, incluso aunque se hayan validado con plugins de Figma.
2. Utilizar un lector de voz para verificar orden, semantic tags, claridad en el contenido, alt text, etc.
El NVDA Reader es gratuito y uno de los más usados, aunque tambien esta VoiceOver de Apple, así como el Screen Reader, una extensión de Chrome.
3. Utilizar magnifiers y ajustes de tamaño de fuentes para validar el layout y asegurar no perder de vista el contenido.
4. Usar reportes de accesibilidad básicos de los browers para detectar posibles problemas u olvidos. Chrome tiene el Lighthouse, así como Firefox tiene una validación de accesibilidad, que incluso ofrece una mayor cantidad de detalles, como el orden de lectura.
5. Considerar la coherencia entre las diversas herramientas de asistencia que los usuarios pueden seleccionar es crucial.
Por ejemplo, algunos usuarios pueden utilizar magnifiers debido a una visión parcial, pero luego pueden recurrir a lectores de voz cuando se les cansa la vista.
6. “Nothing about it, without us”
Finalmente, la realidad es que las herramientas automáticas para testear accesibilidad solo cubren un 30% de los errores, por lo que no hay que olvidarse de testear con usuarios reales! Incluso, me han recomendado Fable, una plataforma de research enfocada en accesibilidad, que cuenta con un panel segmentado por las tecnologías de asistencia que utilizan, permitiendo reclutar, dirigir e incentivar a los participantes a través de su plataforma accesible.
Links finales
- Los cursos de Simplifying Web Development with Accessibility Best Practices, Accessibility for Web Design y Accessibility-First Design en LinkedIn. Lo que me pareció mas interesante es que es muy práctico y entendible de una forma clara y precisa.
- Esta guía de accesibilidad por componentes que me pareció más que interesante como recurso de consulta.
- La Microsoft Inclusive 101 Guidebook como un lugar donde seguir profundizando.
Para finalizar, quiero ser optimista y pensar que en un futuro la inclusión va a lograr ser parte integrada del UX y por eso me quedo también con la frase de David Dame, Senior Director of Product Accessibility for Windows and Devices at Microsoft:
“Simply meeting compliance for accessibility means I can use your product. A great user experience means I will choose your product. Just because I can use it, doesn´t mean I will choose it”.
Los usuarios eligen porque se sienten parte.
Gracias por llegar hasta acá! Cualquier feedback es más que bienvenido.
Volver a la primera parte del artículo →
