Traducción de Wireframes de diseño a HTML/CSS accesible

Este artículo ha sido amablemente apoyado por nuestros queridos amigos de Deque, quienes nos ayudan a todos a hacer que los sitios web y las aplicaciones móviles sean accesibles. ¡Gracias!

Con demasiada frecuencia, la accesibilidad no pasa por la mente de un diseñador al crear interfaces de usuario. Pasar por alto las consideraciones de accesibilidad en la fase de diseño puede filtrarse a través de su sitio web o aplicación y tener un gran impacto en sus usuarios. Ya sea que se trate de pruebas de usabilidad, creación de prototipos, adopción de una biblioteca de patrones accesible o simplemente anotación de estructuras alámbricas, los diseñadores deben incorporar la accesibilidad en su flujo de trabajo. En lugar de sobrecargar a los ingenieros de control de calidad para encontrar defectos de accesibilidad, pensar en la accesibilidad desde el principio o "desplazarse a la izquierda" puede tener un impacto tremendamente positivo en el contenido que crea.

Desplazamiento a la izquierda

Hay muchos estudios que muestran los cambios en el costo de corregir defectos en diferentes etapas del proceso de desarrollo. Con base en el costo de reparar un defecto en la etapa de diseño con un factor de 1x, estos estudios muestran diferencias de costos que aumentan a 6x durante la implementación, 15x durante las pruebas después de la confirmación del código y hasta 100x si se detecta después de que el defecto lo hace. en producción. La investigación realizada por el NIST estima que los costos de reparación de defectos son 10 veces mayores durante las pruebas de integración y 15 veces mayores durante las pruebas del sistema, pero solo 30 veces mayores en producción.[^2] Independientemente de cuáles sean los costos reales de su organización, una cosa es segura: detectar defectos en el diseño y la fase de desarrollo es órdenes de magnitud menos costosa que más tarde en el proceso.

Deque ha reunido datos de 20 años de pruebas de accesibilidad. Según nuestros datos, una tendencia que hemos visto en los últimos cinco años, a medida que las aplicaciones web han aumentado en complejidad, es que la cantidad de defectos por página ha aumentado de manera constante a entre 30 y 50 defectos por página. Estos números de defectos a menudo empequeñecen las tasas de defectos funcionales y amplifican el valor de cambiar las pruebas de accesibilidad y corregir lo más a la izquierda en el proceso como sea posible.

Alrededor del 70% de los defectos de accesibilidad se pueden evitar mediante la combinación adecuada de pruebas automatizadas y guiadas durante el proceso de diseño y desarrollo.

“

Este artículo tiene como objetivo brindarle una descripción general de cómo se puede lograr esto.

La fase de diseño

Anotaciones

Las anotaciones son explicaciones textuales o gráficas agregadas a un diseño para informar al implementador de la intención. Al igual que un diseñador que anota cosas como el color y el tamaño de la fuente, la información de accesibilidad también debe transmitirse en los diseños. Vamos a sumergirnos en un widget de reproductor de audio simple y evaluar qué tipo de anotaciones necesitaremos.

Nuestro reproductor de audio constará de tres controles:

1. Un control para ir a la pista anterior (cuando corresponda)
2. Un control para reproducir y pausar la pista de audio que se está reproduciendo actualmente
3. Un control para ir a la siguiente pista (cuando corresponda)

Nombre, rol y estado

El nombre accesible de un componente dictará de qué se informará a un usuario de tecnología de asistencia cuando interactúe con él. Es muy importante anotar cada uno de los controles de nuestro reproductor de audio porque, visualmente, se representan solo con iconografía y sin contenido textual. Esto significa que anotaremos los 3 controles con nombres accesibles de "Pista anterior", "Pausa" y "Pista siguiente".

A continuación, queremos pensar en el propósito de cada uno de estos 3 controles. Dado que son elementos en los que se puede hacer clic que realizan acciones del reproductor de audio, la elección obvia de función aquí es "botón". Esto no es algo que deba asumirse a través del diseño, sino que es algo que los diseñadores deben anotar para asegurarse de que los implementadores agreguen esta información semántica a los controles. Tener los roles asignados desde el principio le evitará tener que volver atrás y agregarlos a los controles después de que la implementación ya haya tenido lugar.

Finalmente, al igual que los diseñadores trazan un mapa de cómo aparece un control cuando se desplaza el cursor, deben pensar en los diversos estados de su widget en términos de accesibilidad. En el caso de nuestro reproductor de audio, en realidad tenemos bastantes estados para anotar para el implementador. Comenzando por el botón “Pista anterior”, sabemos que debe estar deshabilitado cuando no hay una pista anterior para reproducir. El botón de reproducción/pausa debe alternar el reproductor de audio entre los estados de reproducción y pausa. Esto significa que debemos anotar que el nombre accesible debe coincidir con ese estado. El nombre accesible del botón debe ser "Pausa" cuando se reproduce el audio y "Reproducir" cuando el audio está en pausa. Para el botón "Pista siguiente", debemos anotar el hecho de que debe estar deshabilitado cuando no hay una pista siguiente. Por último, los estados de enfoque y desplazamiento de cada uno de los botones deben anotarse para que los usuarios del teclado tengan alguna indicación visual del control actualmente enfocado en el reproductor de audio.

Interacción para todo el componente

Cuando esté en la primera pista: deshabilite el botón "pista anterior"

Cuando esté en la última pista: deshabilite el botón "siguiente pista"

Al jugar, muestra el botón "pausa" y oculta el botón "reproducir"

Cuando no esté jugando: muestre el botón "reproducir" y oculte el botón "pausa"

Después de hacer clic en "reproducir", coloque el foco en el botón "pausa"

Después de hacer clic en "pausa", coloque el foco en el botón "reproducir"

Pruebas de usabilidad

Las pruebas de usabilidad, una metodología de investigación de UX en la que un investigador hace que un usuario realice una serie de tareas y analiza su comportamiento, es una etapa muy importante en la fase de diseño. La información recopilada de las pruebas de usabilidad es vital para dar forma a las experiencias de los usuarios digitales. Realizar esta prueba con usuarios con discapacidades es extremadamente importante porque le permite a su equipo tener una idea de la facilidad con la que estos usuarios podrán interactuar con el contenido que están creando. Si está realizando pruebas de usabilidad en un sistema existente, podrá configurar un escenario muy realista para el participante, lo cual es excelente cuando se trata de usuarios que dependen de diversas tecnologías de asistencia.

Si está realizando pruebas de usabilidad en un sistema que no existe, prepárese para enfrentar los desafíos de accesibilidad que rodean la salida del software de diseño. Los prototipos interactivos generados por estas herramientas a menudo son extremadamente diferentes de lo que será el producto final en un navegador o en una plataforma de sistema operativo. Además, estos “prototipos funcionales” suelen ser extremadamente inaccesibles. Si es posible, encuentre una alternativa cercana en la naturaleza que pueda usar en lugar de su prototipo, lo que le puede dar una buena idea de cómo sus participantes interactuarán con su sistema. Por ejemplo, si está creando un nuevo componente de navegación móvil, busque uno existente en Internet y realice pruebas de usabilidad con él. Determine qué funcionó en esta alternativa y aprenda qué debe mejorarse. De cualquier manera, siempre esté preparado para hacer adaptaciones para los participantes de la prueba de usabilidad en función de sus discapacidades. Asegurarse de que las pruebas se realicen sin problemas y sin obstáculos no solo hará felices a los participantes, sino que también le permitirá superar más pruebas en menos tiempo.

Bibliotecas de patrones

Las bibliotecas de patrones son colecciones de componentes de interfaz de usuario y son extremadamente beneficiosas tanto en el diseño como en las fases de desarrollo. Tener un conjunto suficiente de componentes de interfaz de usuario al alcance de la mano hace que la creación de aplicaciones completamente funcionales sea mucho más fácil. Para el diseñador, estos componentes ayudan a mantener una buena coherencia en toda la aplicación, lo que mejora la experiencia general de los usuarios. Para el desarrollador, tener componentes completamente probados, accesibles y reutilizables ayuda a producir contenido de alta calidad rápidamente. Estos componentes deben tratarse con especial cuidado en términos de accesibilidad porque, presumiblemente, se utilizarán varias veces a través de su(s) aplicación(es).

Trabajar con los desarrolladores

Hablando con otros desarrolladores y diseñadores en conferencias y reuniones, con frecuencia escucho de equipos divididos en los que los diseñadores y desarrolladores trabajan completamente aislados unos de otros. Los desarrolladores no solo deben incluirse en la fase de diseño en cosas como reuniones de revisión de diseño, sino que los diseñadores también deben incluirse en la fase de desarrollo.

La colaboración es clave cuando se trata de crear contenido accesible increíble.

“

A menudo, los desarrolladores conocen los detalles de implementación que pueden ayudar a dar forma a las composiciones de diseño o incluso cambiar un enfoque para resolver un problema de diseño. Del mismo modo, los diseñadores pueden ayudar a mantener a los desarrolladores bajo control cuando se trata de implementar sus diseños de manera accesible porque los aspectos orientados a los detalles, como el espaciado y el uso específico del color, pueden tener un gran impacto en la accesibilidad. Mientras los desarrolladores implementan un diseño, los diseñadores deben prestar mucha atención a cosas como la indicación de enfoque, el orden de tabulación, el orden de lectura, las fuentes, los colores e incluso los nombres accesibles y los textos alternativos de las imágenes. Porque, después de todo, ¿de qué sirven todas esas increíbles anotaciones específicas de accesibilidad si el desarrollador las ignora?

La fase de desarrollo

Automatice las pruebas de accesibilidad

A los desarrolladores nos encanta la idea de que ciertas cosas en nuestros flujos de trabajo puedan automatizarse por completo. Afortunadamente, hay muchas bibliotecas de automatización de accesibilidad increíbles disponibles, que su equipo debería aprovechar para ayudar a crear interfaces accesibles sostenibles. Las herramientas de análisis estático como eslint-plugin-jsx-a11y pueden proporcionar comentarios inmediatos a los desarrolladores advirtiéndoles sobre posibles problemas de accesibilidad mientras codifican. Los desarrolladores pueden incluso configurar su editor de texto para mostrar estas advertencias justo cuando escriben el código, detectando estos defectos en vivo a medida que aparecen.

Los motores de reglas de accesibilidad, como axe-core, se pueden integrar en casi cualquier marco o entorno y pueden ayudar a detectar muchos problemas de accesibilidad extremadamente comunes. Una excelente manera de asegurarse de que todo su equipo esté creando contenido accesible es integrar este tipo de herramientas en sus canalizaciones de CI (integración continua) y CD (entrega continua). Escribir casos de prueba específicos de accesibilidad (unidad o de extremo a extremo) es otra gran forma de automatización. En mi equipo, tenemos todo lo anterior configurado, por lo que no se pueden fusionar solicitudes de extracción hasta que hayan pasado todas nuestras pruebas de automatización de accesibilidad. Esto significa que podemos garantizar defectos de accesibilidad mínimos incluso en nuestros servidores de desarrollo y definitivamente no llegarán a producción.

Gestione los defectos de accesibilidad de forma sistemática

Los problemas de accesibilidad no deben tratarse de manera diferente a los defectos de seguridad o funcionalidad. Deben ser clasificados y priorizados regularmente con el resto de la carga de trabajo "normal". Medir el progreso y recopilar métricas específicas de los defectos de accesibilidad también puede ser útil, especialmente si su equipo recién comienza a mejorar la accesibilidad. Esto también puede ayudar a identificar los puntos débiles o cuellos de botella de su sistema. Si su equipo participa en retrospectivas de sprint (o algo similar), la accesibilidad debería ser un tema de conversación. Reflexionar sobre lo que funciona y lo que no es un ejercicio saludable y puede conducir a mejoras en el enfoque general de su equipo hacia la accesibilidad sostenible.

Esta herramienta Cool axe Beta

Hemos hablado sobre la automatización de la accesibilidad, que es un excelente punto de partida para las pruebas. Sin embargo, inevitablemente, un ser humano debe continuar donde lo dejan los robots para obtener una cobertura completa de las pruebas de accesibilidad. Las pruebas manuales requieren una comprensión profunda de la accesibilidad, así como las Pautas de accesibilidad al contenido web del W3C, o "WCAG". La aplicación axe Beta lo ayuda a superar esta prueba manual sin tener que ser un experto en accesibilidad. Tiene un gran conjunto de pruebas guiadas inteligentes, que hacen preguntas extremadamente simples y hacen todo el trabajo pesado por usted.

Dado que siempre nos esforzamos por automatizar todo, uno podría reaccionar con escepticismo ante la afirmación de que las pruebas de accesibilidad no pueden automatizarse por completo y requieren un cerebro humano para cubrir todas las bases. Sin embargo, tomemos imágenes como ejemplo y qué información, si la hay, proporcionan en el contexto de una página web. Una biblioteca de automatización de accesibilidad no puede derivar la intención informativa al escanear o procesar una imagen. Incluso si alimentamos un algoritmo de aprendizaje automático con una imagen y puede escupir una descripción perfecta de lo que hay en esa imagen, no sabe qué transmite esa imagen en el contexto de la página. La información que transmite una imagen dada, o si esa imagen se usa únicamente como decoración, depende completamente del autor del contenido.

Atarlo todo junto

Tener en cuenta la accesibilidad desde el comienzo del desarrollo hace que la creación de contenido accesible sea mucho más fácil que hacer estas consideraciones al final del ciclo de vida del desarrollo de software. Integrar la accesibilidad en la ideación, el diseño y la implementación de su software crea un producto más sostenible.

Prepare a su equipo para el éxito utilizando recursos como WCAG, ARIA, ARIA Authoring Practices y Stack Overflow. Evite que los defectos de accesibilidad lleguen a su software aprovechando las bibliotecas de automatización de accesibilidad e integrándolas en sus servidores de integración continua. Nuestro equipo ha trabajado arduamente para llenar el vacío entre las pruebas automáticas y manuales, ¡nos encantaría que probara axe Beta! Si los defectos de accesibilidad se manejan de manera sistemática, no solo puede eliminar estos problemas de sus aplicaciones, sino que también puede evitar que encuentren el camino de regreso en el futuro.

¿Quieres unirte a mí en un taller gratuito sobre este tema exacto? Regístrese para nuestro próximo taller virtual de traducción de estructuras de diseño, que se dividirá en dos sesiones de 3 horas.