Usualmente, el usuario espera que una aplicación o un sitio web sea simple y fácil de utilizar, que cumpla sus expectativas y que lleve a cabo las funciones que se necesitan, de lo contrario rechazará dicho producto. Pero lo que para nosotros puede parecer útil y sencillo, a una persona con necesidades distintas a las nuestras, por ejemplo una persona no vidente o sorda, puede que dicho producto no sea el más adecuado. Es nuestro deber como programadores poder apelar a las necesidades de diversos grupos de personas, lo cual incluye a aquellos que poseen el tipo de necesidad mencionada anteriorment. Sin embargo, ¿cómo podemos resolverlas?
El primer paso es tener claro cuáles necesidades son las que se deben abarcar. Existen muchos tipos de necesidades, pero las principales que se deben cubrir en aplicaciones móviles/web se pueden agrupar en 5 categorías:
- Visuales: por parte de personas no videntes, daltónicas o que poseen baja visibilidad.
- Físicas: por parte de personas que poseen una discapacidad física o habilidades motoras limitadas, como lo son temblores en las manos o atrofia muscular.
- Cognitivas: por parte de personas que poseen problemas de aprendizaje o memoria.
- De lectura: por parte de personas que tienen problemas de lectura, como los disléxicos.
- Auditivas: por parte de personas sordas o con problemas de audición.
Una vez definidas las necesidades, podemos avanzar al siguiente paso: resolver dichas necesidades. Existe una guía llamada Web Content Accessibility Guidelines (WCAG por sus siblas en inglés), la cual estipula distintos puntos que una aplicación debe cumplir para que esta pueda ser considerada accesible. Ésta guía se encuentra organizada en varias secciones, entre las cuales se pueden resaltar las siguientes:
- Alternativas de texto para cualquier contenido que no sea texto.
- Alternativas para medios basados en tiempo, como lo son videos y sus transcripciones correspondientes.
- Contenido que se pueda presentar de distintas maneras, sin perder información. Por ejemplo, evitar usar instrucciones que se basen en colores o formas.
- Contenido distinguible que pueda ser visto u oído fácilmente por los usuarios.
- Evitar contenido que pueda generar ataques epilépticos o algún tipo de reacción física adversa.
- Contenido que pueda ser operable con otros métodos de entrada aparte del teclado.
Cada una de estas secciones contiene un conjunto de reglas que se deben cumplir para que la aplicación pueda ser considerada accesible. Además, incluyen distintos niveles de conformidad según que tan complicadas sean de cumplir.
Al ver estas estipulaciones, podemos tener el temor de que crear una aplicación que las cumpla todas sea muy difícil o costoso. En realidad no tiene que serlo, siempre y cuando se mantengan estos requerimientos en mente desde el inicio del diseño. Otro temor que puede llegar a surgir es olvidar u obviar algún punto, pero para esto existen herramientas online que ayudan a detectar las vulnerabilidades. En la parte Web, WAVE es una herramienta que escanea el sitio y reporta las faltas de accesibilidad para que el programador pueda resolverlas. Para aplicaciones móviles, Android Studio posee una funcionalidad que revisa el código y reporta las faltas de accesibilidad; de esta manera, los errores pueden corregirse desde que se inicia a escribir el código y no hasta que el producto esté finalizado.
Es importante recordar que el cumplimiento de los lineamientos de accesibilidad no conlleva solamente una mejora de experiencia de los usuarios, sino que nos ayuda a obtener mayor mercado y a cumplir con legislaciones vigentes. Nosotros como programadores debemos velar por el cumplimiento de las distintas necesidades, además de preocuparnos de cada uno de los usuarios de nuestros productos.
Referencias:
https://uxdesign.cc/designing-for-accessibility-is-not-that-hard-c04cc4779d94
https://www.guru99.com/accessibility-testing.html
https://webaim.org/standards/wcag/WCAG2Checklist.pdf
.png)
