Press "Enter" to skip to content

SHIFT LEFT A11Y: ¿Cómo hacer nuestra aplicación accesible para más de mil millones de usuarios?

¿Has escuchado alguna vez hablar sobre la idea «Shift Left«?

Bueno, si estás relacionado/a con el área de testing o desarrollo puede ser que hayas escuchado o leído sobre «Shift Left Testing», si aún no lo conoces te recomiendo el siguiente post publicado en el blog de Fede Toledo. El objetivo fundamental de este post es que puedas conocer cómo se orienta esta idea del «Shift Left» a la accesibilidad (a11y).

Cuando logramos desplazarnos hacia la izquierda («Shift Left«) obtenemos tres principales beneficios: 

  • Costos reducidos.
  • Mayor eficiencia y calidad.
  • Ventaja competitiva.

Imagen tomada de: https://abstracta.us/blog/agile-testing/not-convinced-yet-shift-left-testing/

¿Qué significa Shift Left a11y?

«Shift Left a11y» se refiere a la integración de las actividades de accesibilidad con el desarrollo, comenzando más temprano en el ciclo de desarrollo, y no más tarde, como pasa en los entornos de desarrollo de software tradicional como por ejemplo el cascada.

Poner en prácica el «Shift Left a11y» en nuestros proyectos significa tener presente y tomar acciones respecto a la accesibilidad de nuestras aplicaciones desde las etapas más tempranas del ciclo de desarrollo de un producto, comenzando desde el análisis de las historias de usuarios hasta la puesta en producción. Veamos a continuación qué debemos tener presente en cada fase del ciclo de desarrollo de nuestras aplicaciones.

¿Cómo poner en práctica «Shift Left a11y» en nuestros proyectos?

Veamos a continuación como podemos ponerlo en práctica en las diferentes fases de nuestros procesos:

1. Incluir requerimientos de accesibilidad:

Es fundamental que podamos sumar la accesibilidad como parte de la planificación del proyecto y de la Sprint Planning cuando se estén analizando los requerimientos que serán desarrollados en el siguiente sprint.

Existe una diversidad de situaciones que afectan la accesibilidad en una aplicación, por lo que recomiendo que las Historias de Usuario nos permitan cubrir todas las posibles situaciones por ejemplo:

  • Como usuario que no usa el mouse, necesito un mejor enfoque del teclado para poder ver dónde estoy en una página a medida que avanzo. 
  • Como usuario que hace uso de un lector de pantalla, necesito que todo el texto del enlace sea significativo para poder navegar más fácil. 
  • Como usuario con baja visión, necesito aumentar el tamaño de fuente para leer el contenido de la aplicación.

2. Temprana revisión de la accesibilidad en los prototipos:

En la siguiente imagen publicada en el siguiente post en el Blog de Deque podemos presenciar el esfuerzo que se invierte cuando no tenemos presente la accesibilidad en el diseño:

Imagen tomada de: Design Before Code: Thinking About Accessibility from the Ground Up

Al revisar los Prototipos debemos tener presente:

  • Contraste entre el color del primer plano (texto, íconos) y el color del fondo.
  • No indicar información relevante haciendo solo uso de colores.
  • Diseñar estados de enfoque para ayudar a los usuarios a navegar y comprender donde se encuentran.
  • Incluir en los prototipos los mensajes de errores que serán emitidos.
  • Indicar una correcta descripción de los textos alternativos en las imágenes relevantes de nuestros prototipos.
  • Para toda experiencia que consideremos que no pueda ser accesible, debemos buscar y crear una nueva forma para que esta barrera sea eliminada y nuestro usuario pueda acceder a la información.
  • Los prototipos deben ser consistentes y claros.

Relacionado a la accesibilidad en el diseño les recomiendo la charla que Elise Roy que estuvo presentando en la TED Talk «When we design for disability we all benefit».

Elise nos comenta en la charla que perdió su audición a las 10 años de edad y que vivió a lo largo de su carrera como estudiante muchas limitaciones que fueron claves para abogar por los derechos de las personas con discapacidad. En esta charla Elise nos llama a la reflexión con la siguiente frase:

«Si diseñamos primero para la discapacidad, nos vamos a encontrar con soluciones que son mejores que aquellas cuando diseñamos para la norma».

Elise Roy’s TED talk
Lawyer, artist, human rights advocate

3. Revisión automatizada de la accesibilidad

Probando la accesibilidad de nuestro código:

Podemos primeramente considerar la incorporación de herramientas que nos permitan comprobar la accesibilidad en el código.

Estas herramientas se incluyen dentro del IDE de desarrollo y esto le permite conocer rápidamente al equipo de desarrollo cuando están introduciendo incidentes de accesibilidad en su código. Podemos citar algunas herramientas como: react-axe, eslint-plugin-jsx-a11y, jest-axe, entre otras.

Comprobación de la accesibilidad desde nuestro Pipeline:

Alister Scott nos cuenta en su blog «Watirmelon» cómo pudo incluir las evaluaciones de accesibilidad en su Pipeline después de un análisis de varias herramientas y también tuvo una ingeniosa idea donde todo el equipo podía visualizar cuando los tests de accesibilidad estaban fallando y cuando todo estaba OK. 

Imagen tomada del post: Automated WCAG 2.0 accessibility testing in the build pipeline

Pa11y es una de las herramientas que también nos permiten incluir nuestras pruebas automatizadas de accesibilidad dentro de nuestro Pipeline de IC.

En el blog de AbstractaUS podrás encontrar el siguiente post relacionado al uso de la herramienta Pa11y y cómo puedes comenzar a utilizarla en tus pruebas de accesibilidad.

¿Cómo la IC nos ayuda en la a11y?

  • Probar más plataformas.
  • Evitar regresiones.
  • Fomentar la cobertura de prueba.
  • Mover más a la izquierda la accesibilidad («Shift Left a11y»)

4. Revisión Manual de la accesibilidad:

Para las revisiones manuales debemos considerar probar los criterios que plantea la WCAG 2.1. Podemos considerar para una mejor guía y visualización de los criterios reflejarlos en una Checklist. Hoy en día existen varias aplicaciones y sitios que han facilitado esto, desde Abstracta compartimos a la comunidad una plantilla de excel con los criterios definidos en la WCAG 2.1 para un fácil manejo y revisión de lo que se está evaluando, dejando visible los criterios que se cumplen y cuáles no en nuestras revisiones. Les comparto el link para que puedan acceder, descargarla y comenzar a utilizarla.

Técnicas de Filtrado:

Al también aplicar Técnicas de Filtrado nos permite identificar barreras potenciales en la accesibilidad de nuestras aplicaciones. Podemos considerar las siguientes técnicas que se mencionan a continuación:

  • Revisión del contraste de colores en la aplicación 
  • Zoom 
  • Navegar en la aplicación con el solo uso del teclado 
  • Prueba con lectores de pantalla 
  • Comprobación del foco
  • Orden de tabulación

 5. Revisión automatizada:

Para la revisión automatizada podemos apoyarnos en varias herramientas que nos permiten la comprobación de la accesibilidad, de nuestras aplicaciones muchas de ellas son automáticas y nos generan un reporte del estado de nuestra aplicación, por ejemplo: WAVE, aXe, Total Validator, ARC Toolkit, Lighthouse, Colour Contrast Analyzer (CCA), entre otras más que podrás encontrar en la página de la W3C.

El testing automatizado no puede sustituir a las pruebas manuales y el feedback real de los usuarios.

Podemos revisar la accesibilidad en nuestras aplicaciones con las métodos antes mencionados, podemos simular algún tipo de situación de discapacidad pero nada de esto sustituye el poder obtener feedback cuando realizamos pruebas de accesibilidad con un grupo de usuarios en situación de discapacidad.

6. Pruebas de accesibilidad con usuarios:

En esta línea, se encuentran varias organizaciones en Uruguay como HUMANAIN, FundaciónBL y NEXOSUY capacitando a personas en situación de discapacidad para el área de IT en especial testing de software

En estas organizaciones se han ido preparando a un grupo de jóvenes con conocimientos de testing que podrán formar parte de un equipo aportando valor en el área de pruebas desde el primer momento que se incorporen a cualquier proyecto. 

Al generar estas oportunidades nos pueden ayudar a conocer si son accesibles nuestras aplicaciones. Permitamos que nos enseñen a mirar de una manera diferente nuestros aplicaciones y juntos en este proceso podamos resolver grandes problemas y encontrar mejores soluciones para TODOS.

7. Pruebas de accesibilidad en Producción:

Exactamente como habrás pensando, las pruebas en producción son riesgosas, pero aún así debemos realizarlas. Hasta el momento veníamos enfocado en «Shift Left a11y» pero al poner en práctica las pruebas de accesibilidad en Producción estamos apuntando a un «Shift Right a11y» que también es sumamente importante considerarlo en nuestro proceso ya que sino lo probamos nosotros nuestros usuarios lo van a probar en ese ambiente.

En cuanto a las pruebas de accesibilidad en Producción, recomendaría realizar un regresión basada en checklist. Esta checklist la podemos elaborar en conjunto con todo el equipo para identificar los flujos críticos de nuestra aplicación y que nos permita conocer rápidamente los incidentes de accesibilidad que no se detectaron en ambientes que estuvimos probando anteriormente. Con el uso de esta checklist podemos ir añadiendo los flujos y funcionalidades que se consideren a lo largo de todo el proceso como críticas en nuestro sistema y que no deberían presentar incidentes ni barreras de accesibilidad.

Podemos apoyarnos en herramientas como Google Analytics que nos permite conocer varias informaciones relevantes en cuanto al flujo de nuestros usuarios en la aplicación, las secciones que fueron más visitadas. Por ejemplo es un sitio e-commerce si todos nuestros usuarios llegan a completar la compra o quedan a mitad de la misma. Esta herramienta no llega ser bien vista muchas veces por la comunidad de usuarios debido a toda la información que recopila pero también debemos considerar que es bien útil para conocer sobre las mejoras que debemos realizar a nuestra aplicación. 

Por otra parte tenemos a VWO que nos permite crear A/B Testing por si deseamos probar el impacto que tuvo una variante de diseño sobre otra, como reaccionaron nuestros usuarios o cuál de las variantes propuestas en el diseño fue mejor aceptada por nuestros usuarios.

¿Cómo podemos lograrlo?

  • Recordando que todo el equipo es responsable por la accesibilidad en la aplicación.
  • Apuntando a ser más efectivos inspirando y no culpando.
  • Desarrollando nuestra “Empatía” para pensar y trabajar con “Compasión”.
  • Fortaleciendo el trabajo en equipo.

Si has llegado hasta acá te preguntarás y bueno, ¿cómo sigo?

Te propongo que puedas acceder y consultar los siguientes materiales que te menciono a continuación:

Si deseas revivir la webinar: «Shift Left a11y: Haz tu aplicación accesible para más de mil millones de usuarios» realizada junto a la comunidad de QA & Testing Chile donde estuvimos conversando sobre varios de los temas tratados en este post, te comparto el link al video:

Video webinar: Shift Left a11y: Haz tu aplicación accesible para más de mil millones de usuarios

Recuerda siempre que:

Los problemas de accesibilidad de hoy son los principales avances del mañana.

Eve Andersson, Director, Accessibility Engineering, Google

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Close Bitnami banner
Bitnami