Este documento describe la importancia de hacer que las aplicaciones sean accesibles para todos los usuarios, incluidos aquellos con discapacidades. Propone el enfoque "Shift Left a11y" que implica incluir la accesibilidad desde las primeras etapas del desarrollo de software a través de la inclusión de requisitos de accesibilidad, revisiones tempranas de prototipos, pruebas automatizadas y de usuarios. El objetivo es hacer que la accesibilidad sea responsabilidad de todo el equipo y parte integral del proceso de desarrollo

1. Shift Left a11y:
Haz tu aplicación accesible
para más de mil millones
de usuarios.
www.abstracta.us
Lisandra Armas
Accessibility Specialist
QE Lead
@lisyarmas

2. Mobile UX, Usabilidad & Accesibilidad
QE Leader

3. @NexosUruguay

4. “The power of the Web is in its
universality. Access by everyone
regardless of disability is an
essential aspect.”
Tim Berners-Lee,
Director del W3C e inventor de la Web

6. 2.606.914 personas con
algún tipo de discapacidad
(20% de la población)
8.3% tiene problemas
severos en su desempeño
(discapacidad severa)
11.7% está en situación de
discapacidad leve a
moderada

8. ● Machine Learning es una herramienta nueva y excelente para
la accesibilidad.
● El reconocimiento de imágenes de Microsoft en la versión
Google Cloud puede realizar anotaciones con un gran nivel de
confianza. La posibilidad de automatizar la accesibilidad se
expande continuamente.
● La accesibilidad pública está aumentando en Google Maps y
Yelp, al indicar las infraestructuras y establecimientos que son
accesibles.
● El nivel en que la automatización puede detectar incidentes
de accesibilidad se está expandiendo.
● Las herramientas de código abierto están aumentando, lo
que ilustra que la conciencia en la comunidad de
desarrolladores se está volviendo más común.
Resource: https://www.deque.com/blog/the-state-of-accessibility-gaad-2019/
Tendencias actuales y los próximos años:

9. ACTUALIDAD

10. Agenda
● Shift Left a11y
● Solución: modelo y hábitos
● ¿Cómo podemos lograrlo?
1
2
3

11. Agenda
● Shift Left a11y
● Solución: modelo y hábitos
● ¿Cómo podemos lograrlo?
1
2
3

12. 1 Shift Left a11y

13. Visual
Ceguera, baja visión, daltonismo
Auditiva
Sordera, problemas de audición
Motriz
Control delicado, movimientos lentos, no mouse
Cognitiva
Impedimento para el aprendizaje, distracción, toma de
decisiones

14. TalkBack/VoiceOver
Zoom
Dictado
Productos de apoyo de Accesibilidad para Usuarios
Visual Lectores de Pantalla
Magnificadores de Pantalla
Navegadores Alternativos
Traductores de braille

15. Subtítulos
Alertas visibles y
vibratorias
Auditiva
Subtítulos
Alertas visibles
Productos de apoyo de Accesibilidad para Usuarios

16. Switch Access/Control
Assistive Touch
Motriz Teclados Virtuales
Mouse especiales
Productos de apoyo de Accesibilidad para Usuarios

17. Navegadores AccesiblesCognitivaAcceso Guiado
Apoyo Lector
Productos de apoyo de Accesibilidad para Usuarios

18. ¿Qué es
Shift Left
a11y?

19. Resource: https://abstracta.us/blog/agile-testing/not-convinced-yet-shift-left-testing/

20. Resource: https://www.deque.com/blog/design-code-thinking-accessibility-ground/

21. "When we design for disability
first, you often stumble upon
solutions that are better than
those when we design for the
norm."
Elise Roy’s TED talk
Lawyer, artist, human rights advocate
https://www.ted.com/speakers/elise_roy

23. Resource:https://www.microsoft.com/design/inclusive/
“Curb cut” effect
Diseñar y desarrollar
teniendo en cuenta las
distintas situaciones de
discapacidad es
simplemente diseñar y
desarrollar bien.

24. Next Release Sprint
1. Incluir requerimientos de
accesibilidad
2. Temprana revisión de los
prototipos
3. Revisión automatizada
en la IC.
4. Revisión manual y
automatizada del código.
5. Pruebas con usuarios
Deploy
6. Revisión en producción,
identificar errores.
Shift Left a11y

25. Agenda
● Shift Left a11y
● Solución: modelo y hábitos
● ¿Cómo podemos lograrlo?
1
2
3

26. 2 Solución: modelos y hábitos

27. 2 Solución: modelos y hábitos

28. Next Release Sprint
1. Incluir requerimientos
de accesibilidad.
2. Temprana revisión de los
prototipos.
3. Revisión automatizada
en la IC.
4. Revisión manual y
automatizada del código.
5. Pruebas con usuarios.
Deploy
6. Revisión en producción,
identificar errores.
Shift Left a11y

29. Incluir requerimientos
de accesibilidad

30. https://www.w3.org/TR/WCAG21/

31. Resource: http://intopia.digital/articles/intopia-launches-wcag-2-1-map/

32. Resource: https://www.youtube.com/playlist?list=PLYClShxEwpcj0k35RizRAZExC2a1ubNb2

33. Ejemplos de Historias de usuario
Como usuario con vista 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 con vista y poca concentración, necesito etiquetas visibles en
todos los campos del formulario para poder entender qué información se
solicita.
Como usuario vidente con situación de discapacidad cognitiva, necesito que
todas las instrucciones aparezcan en la pantalla y especifique los requisitos
exactos para poder entender toda la información necesaria.
Resource: https://www.slideshare.net/Intopia/a11y-user-stories-csun-2018
1/3

34. Ejemplos de Historias de usuario
Como usuario que hace uso de un lector de pantalla, necesito texto
alternativo en imágenes informativas para poder entender toda la
información importante en una página.
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ácilmente.
Como usuario con baja visión o deficiencia al color necesito indicadores de
enlace más obvios para poder ver dónde hacer clic en una página.
Resource: https://www.slideshare.net/Intopia/a11y-user-stories-csun-2018
2/3

35. Ejemplos de Historias de usuario
Como persona con discapacidad auditiva, necesito subtítulos en los videos
para comprender completamente los módulos de aprendizaje electrónico.
Como usuario con baja visión, necesito aumentar el tamaño de fuente para
leer las pantallas.
Como usuario de primera línea bajo presión para cumplir con los KPIs
necesito un texto de enlace claro para saber intuitivamente a dónde ir
después.
Resource: https://www.slideshare.net/Intopia/a11y-user-stories-csun-2018
3/3

36. Definition of Done
La definición de hecho para historias de usuario puede incluir:
● La funcionalidad se prueba considerando la accesibilidad.
● Las opciones funcionan para el usuario con el uso de productos de apoyo.
Más específico:
● Todas las tareas son finalizadas. (con la capacidad del usuario en la historia)
● Todas las pruebas fueron aprobadas. (incluido el uso de la función con la capacidad del
usuario)
● Código registrado en el control de versiones.
Resource: https://www.slideshare.net/Intopia/a11y-user-stories-csun-2018

37. ¿Podría pasar la DoD?

38. Next Release Sprint
1. Incluir requerimientos de
accesibilidad
2. Temprana revisión de
los prototipos
3. Revisión automatizada
en la IC.
4. Revisión manual y
automatizada del código.
5. Pruebas con usuarios
Deploy
6. Revisión en producción,
identificar errores.
Shift Left a11y

39. Temprana revisión de los prototipos
● Suficiente contraste entre el color del primer plano (texto,
íconos) y el color del fondo.
● En el diseño 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.
1/2

40. Temprana revisión de los prototipos
● 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.
● Los prototipos deben ser consistentes y claros.
2/2

41. Next Release Sprint
1. Incluir requerimientos de
accesibilidad.
2. Temprana revisión de los
prototipos.
3. Revisión automatizada
en la IC.
4. Revisión manual y
automatizada del código.
5. Pruebas con usuarios.
Deploy
6. Revisión en producción,
identificar errores.
Shift Left a11y

42. Proactive vs Reactive
Resource: https://www.paciellogroup.com/products/arc-api/
“Permanecer en un estado constante de reacción ante nuevos problemas
significa que siempre estarás un paso atrás.”

43. Pipeline
Resource: https://watirmelon.blog/2012/11/02/automated-wcag-2-0-accessibility-testing-in-the-build-pipeline/

44. Herramientas
Resource: https://abstracta.us/blog/agile-testing/accessibility-testing-in-continuous-integration/

45. Herramientas
axe Devtools
(WorldSpace Attest)
Resource: https://www.deque.com/axe/devtools/

46. ¿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 a11y (Shift Left
a11y)

47. Next Release Sprint
1. Incluir requerimientos de
accesibilidad
2. Temprana revisión de los
prototipos
3. Revisión automatizada
en la IC.
4. Revisión manual y
automatizada del
código.
5. Pruebas con usuarios
Deploy
6. Revisión en producción,
identificar errores.
Shift Left a11y

48. Revisión manual
Resource: WCAG Criteria Evaluation 2.1 [Template]

49. Revisión manual
Aplicar Técnicas de Filtrado
● 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

50. Revisión automatizada del código
Resources:
https://www.w3.org/WAI/ER/tools/
Top 25 Awesome Accessibility Testing Tools for Websites

51. Next Release Sprint
1. Incluir requerimientos de
accesibilidad
2. Temprana revisión de los
prototipos
3. Revisión automatizada
en la IC.
4. Revisión manual y
automatizada del código.
5. Pruebas con usuarios
Deploy
6. Revisión en producción,
identificar errores.
Shift Left a11y

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

53. https://fundacionbl.org/https://www.humanain.com/ https://nexosuruguay.com.uy/

54. Next Release Sprint
1. Incluir requerimientos de
accesibilidad
2. Temprana revisión de los
prototipos
3. Revisión automatizada
en la IC.
4. Revisión manual y
automatizada del código.
5. Pruebas con usuarios
Deploy
6. Revisión en producción,
identificar errores.
Shift Left a11y

55. Pruebas de accesibilidad
en Producción

57. Next Release Sprint
1. Incluir requerimientos de
accesibilidad
2. Temprana revisión de los
prototipos
3. Revisión automatizada
en la IC.
4. Revisión manual y
automatizada del código.
5. Pruebas con usuarios
Deploy
6. Revisión en producción,
identificar errores.
Shift Left a11y

58. Continuous Delivery
Resource:https://testingindevops.org/visualizing-pipelines-to-help-build-a-quality-culture/

59. Agenda
● Shift Left a11y
● Solución: modelo y hábitos
● ¿Cómo podemos lograrlo?
1
2
3

60. Everyone is responsible for
accessibility on a team.

61. Resource: https://webaim.org/blog/motivating-accessibility-change/
“Más inspiración menos culpabilidad”

62. “When you incent, people optimize for reward. When
you inspire, people optimize for purpose.”
– Michael Norton

63. Resource: https://www.deque.com/empathy-lab-online/
“Desarrollar nuestra Empatía para pensar y trabajar con Compasión”

64. «Nunca dudes que un pequeño grupo de personas
comprometidas pueda cambiar el mundo. De hecho, es
lo único que lo ha logrado»
Margaret Meade.

65. “El mayor enemigo del conocimiento no es la ignorancia,
es la ilusión del conocimiento.”
Stephen Hawking

66. ¿Cómo seguir?
https://www.youtube.com/c/AbstractaUS

67. “The accessibility problems of today are the
mainstream breakthroughs of tomorrow.”
Eve Andersson, Director, Accessibility Engineering, Google

69. Muchas
gracias!

71. Shift Left a11y:
Haz tu aplicación accesible
para más de mil millones
de usuarios.
www.abstracta.us
Lisandra Armas
Accessibility Specialist
QE Lead
@lisyarmas