Accessibility Scanner, evaluar la accesibilidad de una app de Android

1. ¿Qué es Accessibility Scanner?
2. Instalación y activación
3. Funcionamiento de la aplicación
4. Evaluación y resultados
5. Evaluar la accesibilidad de una app en Android

1. ¿Qué es Accessibility Scanner?

Accessibility Scanner es una app gratuita para Android que Google lanzó en marzo de este año.

Es el primer validador automático de accesibilidad para apps de Android y permite escanear cualquier aplicación que tengamos instalada en el móvil.

Su objetivo es ofrecer propuestas de mejora de accesibilidad para las aplicaciones, pero en ningún caso sustituye a una evaluación manual ni garantiza que una aplicación sea accesible.

Como veremos, no valida de acuerdo a una norma concreta, solo evalúa automáticamente un número reducido de aspectos relacionados con la accesibilidad de la aplicación. A pesar de ello puede ser una ayuda muy útil.

Actualmente solo está disponible en inglés y solo para móviles y tablets con Android 6.0 o superior. No requiere ningún permiso especial para su instalación.

2. Instalación y activación

Instalamos la aplicación desde Google Play Store.

La primera pantalla muestra un botón “Get started” que nos pide permiso para abrir la pantalla "Ajustes > Accesibilidad" de Android.

En "Ajustes > Accesibilidad" ha aparecido una opción "Accessibility Scanner" que permite activar y desactivar la herramienta. Si la activamos nos avisa de las acciones que va a llevar a cabo y nos pide permiso para capturar pantallas:

Una vez activada la herramienta tendremos siempre visible en pantalla un botón azul que podemos arrastrar para situar en cualquier zona de la pantalla:

A partir de este momento solo hay que abrir la aplicación que queremos evaluar y pulsar ese botón.

También se crea un acceso directo a la aplicación:

La primera vez que accedemos a la aplicación a través de este enlace se nos informa de cómo usarla:

Las siguientes veces tendremos el histórico de todas las evaluaciones que hemos realizado:

En la esquina superior derecha está el icono de menú (tres puntos verticales), pero este solo contiene un enlace a la ayuda.

3. Funcionamiento de la aplicación

El funcionamiento de la herramienta es muy sencillo. Solo hay que abrir la aplicación que queremos evaluar, por ejemplo Twitter, y pulsar el botón azul flotante que está siempre presente si la herramienta está activada.

Al pulsar el botón se realiza el escáner de la aplicación. En un pantallazo de la misma se resaltan los elementos que han dado error:

En esta pantalla podemos hacer 4 acciones:

1. Ir al listado completo de sugerencias

Pulsando el icono:

En el listado, el elemento que ha provocado el error está identificado mediante su ID. Se informa del tipo de error y una flecha permite mostrar más información como el enlace de ayuda.

2. Ver las sugerencias una a una

Si se pulsa en uno de los elementos resaltados de la captura, se accede a la vista de sugerencias una a una.

En esta vista es más fácil identificar a qué elemento hace referencia cada sugerencia, ya que incluye un slide con la captura del elemento resaltado.

Un mismo elemento puede tener varias sugerencias:

3. Compartir los resultados

Pulsando el icono:

Permite enviarlos por SMS o por correo. En este caso recibes un correo con el listado y descripción de las sugerencias y el pantallazo de la captura.

4. Volver a la pantalla principal

Pulsando el icono:

Permite volver a la pantalla inicial con el histórico de evaluaciones.

4. Evaluación y resultados

La herramienta evalúa los siguientes aspectos:

1. Etiquetado del contenido

El error se describe de la siguiente manera:

Item label

com.twitter.android:id/profile_header

This item may not have a label readable by screen readers.

En ese ejemplo, el elemento que ha dado error es el que tiene el ID profile_header.

Las etiquetas de los elementos interactivos no se presentan visualmente, pero son leídas por TalkBack u otros lectores de pantalla, por ello son tan relevantes.

La herramienta busca los siguientes errores:

1.1 Elementos que pueden coger el foco pero no tienen una etiqueta

La etiqueta se incluye con android:contentDescription. Debería incluirse en ImageButton, ImageView, Checkbox y otros controles que requieran información adicional.

Ejemplo:

<ImageButton

android:id=”@+id/add_note_button”

android:src=”@drawable/add_note”

android:contentDescription=”@string/add_note”/>

Para los campos de texto se incluye el atributo android:hint en vez de la descripción. El atributo android:hint será leído cuando el campo esté vacío, ayudando así a comprender qué tipo de contenido se espera en el campo. Hay que tener en cuenta que cuando el usuario rellene el campo TalkBack leerá el texto introducido por el usuario.

1.2 Elementos con etiquetas redundantes

Es decir, etiquetas en las que se indica el tipo o el estado. Por ejemplo daría error que la etiqueta de un botón incluya el texto “button”, puesto que el lector de pantalla ya anuncia que es un botón; o por ejemplo que en la etiqueta de un check se indique su estado (“checked”).

Como la herramienta solo está en inglés, si la descripción del botón es “Botón que envía el formulario” no da error, aunque la etiqueta adecuada sería “Enviar el formulario”.

1.3 Etiquetas duplicadas

Por ejemplo, dos botones con la misma descripción “Más opciones”.

2. Contraste de color del texto y las imágenes

Se evalúa basándose en las recomendaciones del W3C. Es decir, el texto pequeño debe tener al menos un contraste de 4.5:1 y el texto grande (14pt negrita o 18pt normal) un contraste al menos de 3:1.

El error se describe de la siguiente manera:

Text contrast

com.twitter.android:id/button_edit_profile

The item's text contrast ratio is 2,94. This ratio is based on an estimated foreground color of #8899A6 and an estimated background color of #FFFFFF. Consider increasing this item's text contrast ratio to 3,00 or greater.

Image contrast

com.twitter.android:id/composer_write

The image's contrast ratio is 2,83. This ratio is based on an estimated foreground color of #FFFFFF and an estimated background color of #1DA1F2. Consider increasing this ratio to 3,00 or greater.

3. Tamaño de los elementos interactivos

Se evalúa si tienen al menos 48dp de alto.

El error se describe de la siguiente manera:

Touch target

com.twitter.android:id/button_edit_profile

This item's height is 36dp. Consider making the height of this touch target 48dp or larger. A parent container may be handling touch events for this item. If selecting the larger container performs the same action as selecting this item, consider defining this item as not clickable. If a different action is performed, consider increasing the size of this item.

5. Evaluar la accesibilidad de una app en Android

Como vemos, no son muchos los aspectos que evalúa y no puede sustituir a una evaluación manual, aunque sin duda puede ser una herramienta muy práctica.

Para ayudar a evaluar manualmente una app tenemos diferentes documentos, uno bastante útil es Accessibility Developer Checklist que incluye:

• Accessibility Requirements:
1. Describe user interface controls.
2. Enable focus-based navigation.
3. Custom view controls.
4. No audio-only feedback.
5. Test.
• Accessibility Recommendations:
1. Android Design Accessibility Guidelines.
2. Framework-provided controls.
3. Temporary or self-hiding controls and notifications.
• Special Cases and Considerations:
1. Text field hints for EditText.
2. Custom controls with high visual context.
3. Custom controls and click handling.
4. Controls that change function.
5. Prompts for related controls.
6. Video playback and captioning.
7. Supplemental accessibility audio feedback.
8. Custom controls with complex visual interactions.
9. Sets of small controls.
10. Decorative images and graphics.

Otros documentos de interés de developer.android.com y Google son:

• Accessibility Testing Checklist
• Android >Design > Accessibility
• Making Applications Accessible
• Building Accessibility Services
• Google Accessibility
• Google Material Design Accessibility

Artículos relacionados:

• Apps nativas de Android accesibles
• Accesibilidad y usabilidad móvil: web móvil y app nativa
• Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.
• Pautas de usabilidad y accesibilidad móvil. "Accesible Mobile Interfaces" y "Mobile Navigation" de Funka
• WCAG 2.0 Extensions. "WCAG Cognitive Extension", "WCAG Mobile Extension", y nueva versión de las WCAG 2.0
• aXe Rules, Google ADT Rules y el Mobile Web Accessibility Checker