Last Updated: 2021-10-07

¿Qué es la accesibilidad?

La accesibilidad es una propiedad del software que indica la facilidad de acceso y uso que este tiene, teniendo en cuenta la heterogeneidad de la población que puede hacer uso del mismo. Un sistema accesible es capaz de brindar la misma experiencia a una gran variedad de usuarios sin importar las barreras de tipo visual, intelectual, motriz, auditivo, entre otras, que puedan experimentar los usuarios en un contexto dado.

El diseño universal aporta mucho valor al software, ya que permite que una base más amplia de usuarios lo disfruten, y también permite que la experiencia sea fidedigna con lo que se planeó originalmente en la etapa de diseño.

¿Qué construirá?

Al final de este tutorial usted tendrá:

• Un reporte sobre la accesibilidad de una aplicación con problemas conocidos.

¿Qué aprenderá?

Al desarrollar este tutorial aprenderá:

• Cómo activar los servicios de TalkBack en un dispositivo Android.
• Cómo utilizar las herramientas del lint y la aplicación "Prueba de accesibilidad" para verificar la accesibilidad de una aplicación Android.
• Cómo programar aplicaciones con las recomendaciones de accesibilidad de Android.

¿Qué necesita?

• JDK 8 actualizado e instalado en la máquina y variables de entorno de Java configuradas.
• Android Studio instalado y configurado en su más reciente versión.
• Un dispositivo Android virtual o físico con la depuración por Android Debug Bridge (ADB) habilitada.

Consideraciones generales

Es importante que las aplicaciones que usted desarrolle para Android sean accesibles para todo el público, incluyendo a los usuarios que se encuentren en contextos que dificulten su experiencia, como es el caso de la población discapacitada. Las personas utilizan sus celulares como asistentes para realizar tareas cotidianas, y, a pesar de las dificultades mencionadas, se requieren mecanismos de interacción adecuados y personalizados para sus necesidades. En el caso de las poblaciones con discapacidades, es necesario tener en cuenta las siguientes limitaciones, que son las más comunes:

• Visión reducida
• Daltonismo
• Problemas de audición
• Trastornos de motricidad
• Discapacidades cognitivas

Por otra parte, una persona sin limitaciones físicas de salud también puede ver limitadas sus capacidades de interacción con una aplicación por situaciones como, por ejemplo, las siguientes:

• Fallas en el dispositivo que no permiten interactuar o ver la pantalla por completo.
• Ruido en el entorno del usuario que obstruye la obtención de información auditiva.
• Condiciones de luz en el entorno del usuario que no permiten ver la pantalla.
• Entorno incómodo para el usuario, que lo obliga a manipular el dispositivo con una mano.

Tener en cuenta las limitaciones del entorno y el contexto de la gente permite hacer un diseño universal que incluye a poblaciones que suelen ser segregadas, además de proveer una experiencia consistente, uniforme y agradable para todos los usuarios.

Para este fin, Android cuenta con varias herramientas que permiten desarrollar aplicaciones accesibles y asegurar que existen formas de interactuar sin depender de capacidades, circunstancias y cualidades particulares. Además de estas herramientas, Android asegura que gran parte de los widgets del sistema incluyen soporte para accesibilidad, por lo cual hacer uso del framework brinda grandes capacidades de interacción a la aplicación.

Visibilidad de texto y elementos de control

Unas de las recomendaciones generales más importantes a tener en cuenta tiene que ver con la visibilidad de los elementos en la interfaz gráfica. Los textos suelen ser la principal fuente de información dentro de una aplicación, por lo cual es importante que no haya obstáculos visuales que entorpezcan la lectura de los contenidos de la pantalla.

Las recomendaciones puntuales más relevantes en cuanto a la visibilidad de los elementos son las siguientes:

• Configurar un contraste de color adecuado entre el texto y el fondo. Si se cuenta con un texto de tamaño mayor a 18 puntos, o con un texto en negrita, la proporción del contraste debe ser 4.5:1 como mínimo. En cualquier otro caso, la proporción del contraste debe ser 3.0:1 como mínimo.
• Utilizar controles grandes y sencillos. Todos los elementos gráficos con áreas enfocables deben tener un tamaño de 48 dp x 48 dp mínimo. Esto se logra si el padding total, sumado con la altura o el ancho, según sea el caso, es mayor o igual a 48 dp.
• No depender únicamente del color para la señalización. Es decir, si un elemento requiere mostrar información, esta debe ser lo más completa posible. Asociar un estado a un color es una práctica usual, pero si no se acompaña de un texto adecuado, puede ser problemática para personas con daltonismo o visibilidad reducida.

Descripción de elementos gráficos

Otra de las recomendaciones más importantes a tener en cuenta, está relacionada con la capacidad de una aplicación de ser explorada por medio de un lector de pantalla, o más bien, con el detalle de descripción de los elementos gráficos de la aplicación. La práctica de etiquetar descriptivamente cada elemento de la interfaz permite que la experiencia en la interacción con la GUI no dependa únicamente de los elementos visuales. Así, los usuarios con restricciones visuales pueden identificar el contenido de la aplicación, distinguiendo los componentes funcionales del resto.

En la mayoría de widgets de Android, existe la propiedad android:contentDescription para poder brindar una descripción textual acerca del elemento gráfico en cuestión. Se recomienda que estas descripciones sean consultadas desde el archivo de recursos res/strings.xml.

Es importante reconocer que no todos los elementos deben tener una descripción, como por ejemplo, los elementos de tipo TextView, puesto que el lector de pantalla leerá su contenido por defecto. Otro ejemplo son los elementos netamente visuales, como algunas imágenes decorativas (formas). En este caso, es posible configurar el valor de la propiedad android:contentDescription a "@null", no obstante, es importante recordar que todos los elementos gráficos, por regla general deben tener una descripción.

Para aquellos elementos que sí requieren descripción (lo cual incluye al contenido multimedia), es importante que cada descripción sea única, y que no indiquen el tipo de widget que se está describiendo, ya que el lector de pantalla lo hace por defecto. La unicidad de las descripciones se torna muy importante al momento de hacer uso de elementos en un RecyclerView, por ejemplo.

Otra recomendación importante relacionada a las etiquetas consiste en la agrupación de elementos gráficos. Un caso particular de agrupación de elementos se encuentra cuando se utiliza un elemento EditText, el cual se asocia con un TextView que actúa como su etiqueta de campo por medio del atributo android:labelFor. Otro caso más general puede incluir un ViewGroup, como ConstraintLayout, con elementos internos que también son seleccionables. Cuando esto sucede, suele ser necesario configurar la propiedad android:screenReaderFocusable="true" en el ViewGroup, y también configurar la propiedad android:screenReaderFocusable="true" en cada uno de los elementos que este contiene.

En principio, es importante estar familiarizado con las reglas mencionadas anteriormente para poder diseñar aplicaciones Android que sigan los lineamientos adecuados de accesibilidad. Sin embargo, es muy fácil dejar de lado alguna de estas consideraciones al momento de la implementación. Para identificar rápidamente los puntos de la aplicación que resultan problemáticos en cuanto a la accesibilidad dentro de una aplicación, se puede hacer uso de la aplicación "Test de Accesibilidad" de Google.

Descargar la aplicación a probar

Para conocer el funcionamiento de la aplicación "Test de Accesibilidad", usted va a probar una versión de la aplicación que se ha venido manejando a lo largo del curso, la cual ha sido modificada para incluir malas prácticas y errores que generan problemas de accesibilidad.

Para descargar la aplicación, acceda al repositorio del siguiente enlace: https://github.com/TheSoftwareDesignLab/MISW4104-Ejemplos/tree/main/starters/CL18-accesibilidad, y descargue el código del proyecto, e impórtelo en Android Studio de la misma forma que lo ha hecho en tutoriales anteriores.

Una vez tenga su proyecto importado en Android Studio, podrá ver varios directorios con la misma estructura que ya se ha venido utilizando previamente.

Ejecute la aplicación. Podrá ver, en el dispositivo que tenga conectado por ADB, que se muestra una aplicación con la siguiente pantalla:

Imagen 1. Vista principal de la aplicación descargada

A primera vista, parece ser una aplicación sencilla, pero tiene varios elementos que hacen que la interacción sea compleja para algunos usuarios por cuestiones de accesibilidad que serán exploradas en el siguiente paso.

Descargar la aplicación de prueba de accesibilidad

La aplicación de Google para probar la accesibilidad está disponible en la Play Store. Asegúrese que el dispositivo donde se ejecutará la prueba cuenta con acceso a internet y una cuenta de Google vinculada a la tienda de aplicaciones para poder descargarla. La dirección URL de Google Play Store que contiene la aplicación en cuestión es la siguiente: https://play.google.com/store/apps/details?id=com.google.android.apps.accessibility.auditor. Si inicia sesión en el navegador con la misma cuenta de Google que tiene en el dispositivo móvil, podrá instalar la aplicación en este último desde el navegador.

No obstante, también puede buscar de forma manual en la tienda de Google Play Store por el nombre "Test de Accesibilidad". Debe llegar a la siguiente página:

Imagen 2. Página de Google Play Store de la aplicación "Prueba de accesibilidad"

Luego de instalar la aplicación, abra la configuración del dispositivo y busque la sección Accesibilidad. Podrá ver, entre los servicios descargados, la aplicación "Prueba de accesibilidad". Seleccione dicha aplicación para utilizarla, y brinde los permisos necesarios para mostrarse encima de otras aplicaciones. Esto creará un botón de acción flotante de color azul, encima de las aplicaciones, el cual permitirá probar la accesibilidad de las aplicaciones activas.

Nota: desde este mismo menú de configuración podrá desactivar el widget flotante de la prueba de accesibilidad cuando termine el tutorial.

Ejecutar una prueba

Vuelva a la aplicación que descargó y ejecutó con Android Studio. La vista principal no presenta problemas relevantes. Sin embargo, la vista que muestra los comentarios de un álbum fue modificada para presentar la mayor cantidad posible de problemas de accesibilidad. Para llegar a esta vista, seleccione un coleccionista cualquiera, y luego seleccione el tercer álbum. Una vez se ubique en la vista, presione el botón flotante de la prueba de accesibilidad para comenzar a escanear la interfaz gráfica. Esto generará sugerencias y resaltará los lugares problemáticos de la interfaz gráfica de la aplicación. En su pantalla debe ver lo siguiente:

Imagen 3. Vista principal de la aplicación donde se indican las oportunidades de mejora

Leer los resultados de la prueba

Para el caso de la aplicación utilizada en este tutorial, cuando se selecciona el tercer álbum, se muestran 32 sugerencias, de las cuales se repiten varias.

Las sugerencias se ven de la siguiente forma:

Imagen 4. Detalle de un problema de accesibilidad

Las primeras 3 sugerencias están relacionadas al contraste del texto que muestra el número del contador. Seleccione cualquiera de estos campos, y al desplegar la sugerencia, podrá ver que el contrast ratio entre el texto y su fondo es de 4.36, mientras que el sugerido es de 4.50.

Luego de los botones, podrá ver que el EditText tiene una sugerencia llamada "Etiqueta de elemento editable", la cual indica que este tipo de View no debería utilizar la etiqueta android:contentDescription. Esto se debe a que los lectores de pantalla suelen indicar el contenido del campo de texto, y este es cambiante.

Posteriormente, se ven 5 botones de imagen los cuales presentan el mismo problema del contraste de la imagen, y adicionalmente presenta un problema por el tamaño del elemento táctil. Esto se debe a que el botón tiene un tamaño de 30dp x 30dp y se recomienda utilizar 48dp x 48dp al menos. Además, existe un problema, puesto que ninguno de los botones tiene una etiqueta, y al ser un botón cuyo contenido es una imagen, es estrictamente necesario proveer de una etiqueta alternativa para identificarlo por medio de la lectura.

En el RecyclerView, cada uno de los comentarios tiene un botón con el texto "VER MÁS". Estos botones presentan un problema conjunto llamado "Descripciones de elementos", que se debe a que la etiqueta android:contentDescription utilizada en el archivo comment_item.xml se repite para cada uno de los elementos del RecyclerView. Ante un lector de pantalla, todos los botones se leen de la misma forma, lo cual puede generar confusión sobre su identidad. Asimismo, la prueba indica que estos botones pueden tener texto innecesario en la etiqueta del elemento. Esto se debe a que el valor de las etiquetas utilizadas incluye la palabra "Botón", lo cual indica el tipo de View. Lo anterior es innecesario dado que el lector de pantalla de TalkBack ya se encarga de indicar el tipo de vista sobre la cual se está brindando información al usuario.

A pesar de la utilidad de la aplicación "Prueba de accesibilidad" y la completitud de sus reportes, existen aspectos que no pueden ser evaluados por esta misma, y que requieren de una adicional prueba humana, tal y como sucede con gran parte de las pruebas automatizadas. Un ejemplo claro donde se queda corto este reporte es cuando un elemento gráfico está etiquetado, pero su nombre no es el adecuado.

Para este fin, usted hará uso de TalkBack, que es una herramienta integrada en los dispositivos Android, la cual permite leer el contenido de la pantalla y controlar la interacción con ésta sin necesidad de utilizar el sentido de la vista.

Activar TalkBack

1. Abrir la Configuración del dispositivo.
2. Acceder al menú Accesibilidad y seleccionar la opción TalkBack.
3. En la parte superior de la pantalla de TalkBack, presionar Activar/desactivar para activar TalkBack.
4. En el cuadro de diálogo de confirmación, seleccione la opción Aceptar para confirmar los permisos.

Nota: la primera vez que se habilita TalkBack, se inicia un instructivo. Para volver a abrirlo en el futuro, ve a Configuración > Accesibilidad > TalkBack > Configuración > Iniciar instructivo de TalkBack.

Explorar la aplicación con TalkBack

Después de activar TalkBack, se habilitan dos maneras de navegar:

• Navegación lineal: este modo consiste en deslizar el dedo hacia la derecha o la izquierda permite navegar por los elementos de la pantalla secuencialmente. Para seleccionar un elemento, es necesario presionar dos veces en cualquier lugar de la pantalla.
• Exploración táctil: este modo consiste en arrastrar el dedo por la pantalla para escuchar lo que hay debajo de él. En ese sentido, es similar al proceso de identificación visual. Para seleccionar un elemento, es necesario presionar dos veces en cualquier lugar de la pantalla.

Luego de familiarizarse con ambas formas de exploración, pruebe la aplicación explorando los elementos de la interfaz de forma secuencial. En este caso, el contenido de la aplicación es muy sencillo, por lo cual los textos de descripción no deberían ser muy complejos de interpretar con el lector de pantalla.

No obstante, en general, es importante que durante su exploración preste atención a los detalles en busca de los siguientes problemas:

• ¿Los comentarios por voz de cada elemento transmiten su contenido o propósito de manera adecuada?
• ¿Los anuncios y descripciones son breves o demasiado detallados?
• ¿Se pueden completar los flujos de trabajo principales con facilidad?
• ¿Se puede llegar a todos los elementos de la interfaz deslizando el dedo?
• Si aparecen alertas u otros mensajes temporales, ¿se leen en voz alta?

En el caso de esta aplicación, bastará con que preste atención a los textos descriptivos de cada uno de los elementos gráficos en busca de información clara y concreta, y que se asegure de poder llegar a todos los elementos de la interfaz con el modo de navegación lineal para explorar la pantalla.

Para esta exploración, con el TalkBack activado, abra la aplicación. Podrá notar que la primera selección que hace el asistente está en el título de la aplicación. Desplace el dedo para seleccionar un elemento en el listado de coleccionistas del RecyclerView. El lector de pantalla leerá los textos del ítem tal como vienen, de forma que el número de teléfono no es leído con ningún formato especial que ayude a entender su propósito. Luego de esta información, el lector indicará que es posible seleccionar el elemento. Ahora, seleccione uno de éstos ítems para dirigirse a la pantalla de los álbumes. Al posicionarse sobre un álbum, el lector nuevamente leerá el texto tal como viene e indicará que es posible seleccionar el elemento para dirigirse a sus comentarios. Seleccione nuevamente el tercer álbum (de nombre Tagopia) para ver sus comentarios.

En esta última vista, explore en detalle todos los elementos. Podrá notar que el botón Log Capitalized tiene una etiqueta que hace que la ayuda indicada por el lector de pantalla sea menos clara. En el EditText "Name", podrá ver que, por más que edite su contenido, la ayuda brindada por el lector de pantalla no cambia, lo cual no permite estar consciente del estado actual del campo de texto. Posteriormente, en los botones que tienen una estrella, podrá notar que, la ayuda para los 5 indica que son simplemente botones sin etiqueta, de forma que no habrá claridad acerca de para qué son. Por último, en los ítems que denotan un comentario, se puede ver que, al seleccionar el contenedor entero, solo se lee el contenido textual, más no la etiqueta del botón. Cuando se selecciona un botón Ver Más, se puede notar que el lector de pantalla indica la etiqueta y, ya que ésta está repetida, se indica cuál número del botón se seleccionó entre toda la lista (1 de 2000, por ejemplo).

Luego de terminar la exploración, revise el archivo res/layout/comments_fragment.xml. En el editor de Android Studio se ofrece una vista Code y una vista Design para este tipo de archivos de recursos de interfaz gráfica, donde se puede identificar los elementos de la interfaz y ver sus propiedades. De esta forma, desde la pestaña Design, puede seleccionar un elemento y ver las propiedades text y contentDescription para determinar la etiqueta que se va a referenciar desde TalkBack. Lo anterior se ve de la siguiente forma en el editor de Android Studio, donde los cuadros señalados con color amarillo corresponden a las propiedades contentDescription y text:

Imagen 5. Vista de Android Studio con el archivo comments_fragment.xml abierto

Para validar la accesibilidad de una aplicación es importante hacer uso de tantas herramientas como sea posible. Además de la prueba manual y de la aplicación "Prueba de accesibilidad", existen otras herramientas de fácil acceso que permiten validar estos aspectos, entre las cuales destaca el linter de Android Studio.

Lint

En Android Studio, el linter que analiza el código del editor tiene la funcionalidad de realizar sugerencias acerca de la accesibilidad de un proyecto, indicando lugares del código en donde puede implementarse una mejora. Uno de los ejemplos más comunes de accesibilidad es la advertencia que indica que un elemento no cuenta con un atributo contentDescription.

Esta herramienta tiene varios modos de uso:

• Revisiones automáticas del IDE: Android Studio ejecuta inspecciones por defecto de IntelliJ al momento de compilar el código.
• Inspecciones manuales desde el IDE: Android Studio cuenta con una pestaña en el menú superior la cual permite inspeccionar el código en términos de desempeño, accesibilidad, internacionalización, seguridad, correctitud y usabilidad del código.
• Ejecución desde la línea de comandos con gradle: dentro de un proyecto de Android se puede utilizar el wrapper de Gradle para ejecutar la tarea del linter. Esta muestra en consola los hallazgos y genera un reporte en formato HTML y XML.
• Ejecución desde la línea de comandos como standalone: el SDK de Android incluye una herramienta de consola llamada lint en el subdirectorio /tools. Ejecutar este comando brinda los mismos resultados que la opción anterior.

El modo más sencillo de ejecutar e interpretar los resultados del linter en términos de accesibilidad son las inspecciones manuales, debido al formato en que se muestran las incidencias, ya que son categorizadas como se mencionó anteriormente. Para ejecutar una inspección manual, en la ventana de Android Studio donde tiene el proyecto abierto, seleccione la opción del menú superior Analyze > Inspect Code. Se mostrará el siguiente menú:

Imagen 6. Cuadro de diálogo para configurar la inspección

Con las opciones que vienen por defecto, presione el botón OK. Luego de esto, podrá ver que en la parte inferior del IDE hay una pestaña llamada Inspection results, que se ve de la siguiente forma:

Imagen 7. Pestaña inspection results con las categorías de los problemas detectados

Expanda la categoría Accessibility y las incidencias detectadas en su interior para comprender qué problemas de accesibilidad existen en su proyecto, en qué lugares del código y cómo resolverlas. Las siguientes sugerencias deberían ser incluidas:

Imagen 8. Problemas detallados de accesibilidad en la inspección

Como lo indica el reporte, existen 5 imágenes sin el atributo contentDescription y un elemento EditText que no contiene una etiqueta con el atributo labelFor, ni el atributo hint.

Al seleccionar cada uno de estos problemas, en la parte derecha del panel de resultados se muestra una descripción textual del problema y, en ciertas ocasiones, un botón para resolverlo. Al entrar en el nivel más bajo del detalle, se muestra el código en el cual existe el problema, con el fin de que pueda corregirlo.

Como pudo notarlo, no todos los problemas del paso anterior son detectados en este caso. Sin embargo, el linter es una herramienta que ayuda a reducir los problemas de accesibilidad en un proyecto cuando se cuenta con el código fuente.

¡Felicidades!

Al finalizar este tutorial, pudo familiarizarse con los lineamientos de accesibilidad generales de una aplicación de Android. Así mismo, pudo ejecutar pruebas que validan la accesibilidad de su aplicación Android, y pudo identificar oportunidades de mejora en una aplicación con fallas conocidas.

Ahora podrá aplicar estos principios en el diseño de sus propios proyectos de Android para crear aplicaciones que brinden una experiencia uniforme considerando a los usuarios que cuentan con discapacidades.

Créditos

Versión 1.0 - Octubre 7, 2021