Cómo incorporar la accesibilidad en el proceso de tu equipo
Hacer que tu sitio sea más accesible puede ser una tarea abrumadora. Si te acercas a la accesibilidad por primera vez, la amplitud del tema puede hacerte preguntarte por dónde empezar. Después de todo, trabajar para adaptarse a una amplia variedad de habilidades significa que hay una variedad de problemas correspondientes que se deben tener en cuenta.
Recuerda que la accesibilidad es un esfuerzo colectivo. Cada persona tiene un rol que cumplir. En este artículo, se describen los criterios para cada una de las disciplinas principales (administrador de proyectos, diseñador de UX y desarrollador) para que puedan trabajar para incorporar las prácticas recomendadas de accesibilidad en su proceso.
Gerente de proyectos
Un objetivo primordial para cualquier gerente de proyecto es intentar incluir el trabajo de accesibilidad en cada evento importante y asegurarse de que sea una prioridad tanto como otros temas, como el rendimiento y la experiencia del usuario. A continuación, se incluyen algunos elementos de la lista de tareas que debes tener en cuenta cuando trabajes en el proceso.
- Pon a disposición del equipo la capacitación sobre accesibilidad.
- Identifica los recorridos críticos del usuario en el sitio o la aplicación.
- Intenta incorporar una lista de tareas de accesibilidad en el proceso del equipo.
- Siempre que sea posible, evalúa el sitio o la aplicación con estudios de usuarios.
Capacitación sobre accesibilidad
Existen muchos recursos gratuitos excelentes para aprender sobre la accesibilidad web. Si dedicas tiempo a que tu equipo estudie el tema, será más fácil incluir la accesibilidad al principio del proceso.
Estos son algunos de los recursos que proporciona Google:
Accesibilidad web de Google: un curso de capacitación interactivo de varias semanas.
Conceptos básicos sobre la accesibilidad: Guías y prácticas recomendadas de accesibilidad escritas
Lineamientos de Material: Accesibilidad: Un conjunto de prácticas recomendadas de UX para el diseño inclusivo.
Identificación de los recorridos críticos del usuario
Cada aplicación tiene una acción principal que el usuario debe realizar. Por ejemplo, si estás compilando una app de comercio electrónico, todos los usuarios deberán poder agregar un artículo a su carrito de compras.
Algunas acciones pueden ser de importancia secundaria y, tal vez, solo se realicen de forma ocasional. Por ejemplo, cambiar la foto de tu avatar es una función útil, pero es posible que no sea fundamental para todas las experiencias.
Identificar las acciones principales y secundarias de tu app te ayudará a priorizar el trabajo de accesibilidad que tienes por delante. Más adelante, puedes combinar estas acciones con una lista de tareas de accesibilidad para hacer un seguimiento de tu progreso y evitar regresiones.
Incorpora una lista de tareas de accesibilidad
El tema de la accesibilidad es bastante amplio, por lo que tener una lista de tareas de las áreas importantes que debes tener en cuenta puede ayudarte a asegurarte de cubrir todas las bases.
Existen varias listas de tareas de accesibilidad. Estos son algunos ejemplos de la industria:
Lista de tareas de WebAIM para WCAG Lineamientos de accesibilidad de Vox
Con una lista de tareas en mano, puedes revisar tus acciones principales y secundarias para comenzar a clasificar el trabajo que aún queda por hacer. Puedes ser bastante táctico con este proceso y hasta crear una matriz de acciones principales y secundarias, y determinar para cada paso de esos procesos si faltan elementos de accesibilidad.
Evaluación con estudios de usuarios
Nada mejor que sentarse con usuarios reales y observarlos mientras intentan usar tu app. Si estás incorporando la accesibilidad en una experiencia existente, este proceso puede ayudarte a identificar rápidamente las áreas que necesitan mejoras. Y si estás comenzando un proyecto nuevo, los primeros estudios de usuarios pueden ayudarte a evitar pasar demasiado tiempo desarrollando una función que sea difícil de usar.
Intenta incorporar los comentarios de una población de usuarios lo más diversa posible. Ten en cuenta a los usuarios que navegan principalmente con el teclado o que dependen de la tecnología de asistencia, como los lectores de pantalla o las lupas.
Diseñador de UX
Debido a que las personas tienden a diseñar con sus propios sesgos, si no tienes una discapacidad ni colegas con discapacidades, es posible que, sin querer, diseñes solo para algunos de tus usuarios. Mientras trabajas, pregúntate: “¿Cuáles son todos los tipos de usuarios que podrían depender de este diseño?”. Estas son algunas técnicas que puedes probar para que tu proceso sea más inclusivo.
- El contenido tiene suficiente contraste de color.
- Se define el orden de tabulación.
- Los controles tienen etiquetas accesibles.
- Existen varias formas de interactuar con la IU.
El contenido tiene un buen contraste de color
El objetivo principal de la mayoría de los sitios es transmitirle información al usuario, ya sea a través de texto escrito o imágenes. Sin embargo, si este contenido tiene un contraste bajo, es posible que sea difícil de leer para algunos usuarios (en particular, para aquellos con discapacidad visual). Esto puede afectar negativamente su experiencia del usuario. Para abordar esta inquietud, procura que todo el texto y las imágenes tengan suficiente contraste de color.
Para medir el contraste, se compara la luminancia de un color de primer y segundo plano. Para texto más pequeño (menos de 18 puntos o 14 puntos en negrita), se recomienda una proporción mínima de 4.5:1. Para texto más grande, esta relación se puede ajustar a 3:1.
En la siguiente imagen, el texto de la izquierda cumple con estos mínimos de contraste, mientras que el texto de la derecha tiene un contraste bajo.
Existen varias herramientas para medir el contraste de color, como la herramienta de color de Material de Google, la app de relación de contraste de Lea Verou y aXe de Deque.
Se define el orden de tabulación
El orden de tabulación es el orden en que los elementos reciben el enfoque a medida que el usuario presiona la tecla Tab. Para los usuarios que navegan principalmente con un teclado, la tecla Tab es su principal medio para acceder a todo lo que aparece en la pantalla. Piensa en él como el cursor del mouse.
Idealmente, el orden de tabulación debe seguir el orden de lectura y fluir de la parte superior de la página a la parte inferior, con los elementos más importantes que aparecen más arriba en el orden. Esto hace que sea más eficiente para cualquier persona que use un teclado llegar rápidamente a estos elementos.
La interfaz simulada anterior está numerada para mostrar el orden de tabulación. Crear una simulación como esta puede ayudar a identificar el orden de tabulación previsto. Luego, se puede compartir con los desarrolladores y los verificadores de QA para asegurarse de que se implemente y pruebe correctamente.
Los controles tienen etiquetas accesibles
Para los usuarios de tecnología de accesibilidad, como los lectores de pantalla, las etiquetas proporcionan información que, de otro modo, sería solo visual. Por ejemplo, un botón de búsqueda que solo sea un ícono de lupa puede tener una etiqueta accesible de "Buscar" para ayudar a completar la indicación visual faltante.
Estas son algunas sugerencias sencillas que debes seguir cuando diseñes etiquetas accesibles:
- Sé breve. Escuchar descripciones largas puede ser tedioso.
- Intenta no incluir el tipo o el estado de control. Si el control está codificado correctamente, un lector de pantalla lo anunciará automáticamente.
- Enfócate en los verbos de acción: Usa "buscar", no "lupa".
Te recomendamos que crees una simulación con todos los controles etiquetados. Se puede compartir con tu equipo de desarrollo y de QA para la implementación y las pruebas.
Varias formas de interactuar con la IU y comprenderla
Es fácil suponer que todos los usuarios interactúan con la página principalmente con un mouse. Cuando diseñes, considera cómo una persona interactuará con un control con un teclado.
Planifica tus estados de enfoque. Esto significa determinar cómo se verá un control cuando el usuario lo enfoque con la tecla Tab o presione las teclas de flecha. Es útil planificar estos estados con anticipación, en lugar de intentar incluirlos en el diseño más adelante.
Por último, para cualquier punto de interacción, debes asegurarte de que el usuario tenga varias formas de comprender el contenido. Intenta no usar solo el color para transmitir información, ya que un usuario con deficiencia de visión del color podría pasar por alto estas indicaciones sutiles. Un ejemplo clásico es un campo de texto no válido. En lugar de solo una línea debajo en rojo para indicar un problema, considera agregar también texto de ayuda. De esta manera, abarcarás más bases y aumentarás la probabilidad de que un usuario note el problema.
Desarrollador
El rol del desarrollador es donde la administración de enfoque y la semántica se combinan para formar una experiencia del usuario sólida. A continuación, se incluyen algunos elementos que los desarrolladores pueden tener en cuenta cuando trabajan en su sitio o aplicación:
- El orden de tabulación es lógico.
- El enfoque se administra y es visible de forma correcta.
- Los elementos interactivos son compatibles con el teclado.
- Los roles y atributos de ARIA se aplican según sea necesario.
- Los elementos están etiquetados correctamente.
- Las pruebas se automatizan.
Orden de tabulación lógico
Los elementos nativos, como input, button y select, se incluyen en el orden de tabulación de forma gratuita y se pueden enfocar automáticamente con el teclado. Pero no todos los elementos reciben este mismo comportamiento. En particular, los elementos genéricos, como div y span, no están habilitados para el orden de tabulación. Esto significa que, si usas un div para crear un control interactivo, deberás realizar un trabajo adicional para que sea accesible con el teclado.
Estas son dos opciones:
- Asigna un
tabindex="0"al control. Esto, al menos, hará que se pueda enfocar, aunque es probable que debas realizar trabajo adicional para agregar compatibilidad con las pulsaciones de teclas. - Siempre que sea posible, considera usar un
buttonen lugar de undivospanpara cualquier control similar a un botón. El elementobuttonnativo es muy fácil de aplicarle diseño y obtiene compatibilidad con el teclado de forma gratuita.
Cómo administrar el enfoque
Cuando cambias el contenido de la página, es importante dirigir la atención del usuario con el movimiento del enfoque. Un ejemplo clásico de cuándo es útil esta técnica es cuando se abre un diálogo modal. Si un usuario que depende de un teclado presiona un botón para abrir un diálogo y su enfoque no se mueve al elemento del diálogo, su única opción es presionar Tab en todo el sitio hasta que encuentre el nuevo control. Si enfocas el contenido nuevo en cuanto aparece, puedes mejorar la eficiencia de las experiencias de estos usuarios.
Compatibilidad con el teclado para elementos interactivos
Si compilas un control personalizado, como un carrusel o un menú desplegable, deberás realizar algunos trabajos adicionales para agregar compatibilidad con el teclado. La Guía de prácticas de autor de ARIA es un recurso útil que identifica varios patrones de IU y los tipos de acciones del teclado que se espera que admitan.
Para obtener más información sobre cómo agregar compatibilidad con el teclado a un elemento, consulta la sección sobre el índice de tabulación itinerante en la documentación de Conceptos básicos de accesibilidad de Google.
Los roles y atributos de ARIA se aplican según sea necesario
Los controles personalizados no solo necesitan compatibilidad adecuada con el teclado, sino también una semántica adecuada. Después de todo, un div, semánticamente, es solo un contenedor de agrupación genérico. Si usas un div como base para tu menú desplegable, deberás depender de ARIA para agregar semántica adicional para que el tipo de control se pueda transmitir a la tecnología de accesibilidad. Aquí, la Guía de prácticas de autor de ARIA puede ayudarte a identificar qué roles, estados y propiedades debes usar.
Como beneficio adicional, muchas de las explicaciones de la guía de ARIA también incluyen código de muestra.
Etiqueta los elementos
Para etiquetar entradas nativas, puedes usar el elemento <label> integrado, como se describe en MDN. Esto no solo te ayudará a crear una indicación visual en pantalla, sino que también le dará a la entrada un nombre accesible en el árbol de accesibilidad. Luego, la tecnología de accesibilidad (como un lector de pantalla)
lo recoge y se lo anuncia al usuario.
Lamentablemente, <label> no admite asignar un nombre accesible a los controles personalizados (como los creados con Elementos personalizados o a partir de divs y spans simples). Para este tipo de controles, deberás usar los atributos aria-label y aria-labelledby.
Pruebas automáticas
Ser perezoso puede ser bueno, especialmente cuando se trata de pruebas. Siempre que sea posible, intenta automatizar las pruebas de accesibilidad para que no tengas que hacerlo todo de forma manual. Existen varias herramientas de prueba de la industria que facilitan y agilizan la detección de problemas de accesibilidad comunes:
aXe, creado por Deque Systems, está disponible como extensión de Chrome y módulo de Node (ideal para entornos de integración continua). En este breve A11ycast, se explican algunas formas diferentes de incorporar aXe a tu proceso de desarrollo.
Lighthouse es un proyecto de código abierto de Google para auditar el rendimiento de tus apps web progresivas. Además de verificar si tu AWP admite elementos como el trabajador de servicio y un manifiesto de app web, Lighthouse también ejecutará una serie de pruebas de prácticas recomendadas, incluidas pruebas de problemas de accesibilidad.
Conclusión
La accesibilidad es un esfuerzo colectivo. Todos tienen un rol que desempeñar. En esta guía, se describen algunos elementos clave que cada miembro del equipo puede usar para familiarizarse rápidamente con el tema y, con suerte, mejorar la experiencia general de su app.
Si deseas obtener más información sobre la accesibilidad, consulta nuestro curso gratuito de Udacity y explora la documentación sobre accesibilidad disponible aquí en web.dev.