Pruebas de accesibilidad para aplicaciones de Android: cómo empezar

Bienvenido, soy Miguel y en esta ocasión les traigo un tutorial.

Esta breve guía describe qué tipo de pasos debe realizar y qué debe esperar como desarrollador si va a admitir funciones y servicios de accesibilidad en su aplicación de Android, pero nunca antes había pensado en eso.

Guía paso a paso

Tener una aplicación compatible con accesibilidad no es una tarea trivial, pero requiere un esfuerzo significativo tanto del desarrollador como de los equipos de control de calidad.

Además, los pasos finales implican una verificación manual por parte de expertos en accesibilidad y/o personas con discapacidad.

Pero antes de que tenga lugar esa etapa final, se deben realizar ciertos pasos para abordar cierto tipo de problemas. Eso podría reducir notablemente los costos y acelerar el proceso.

El proceso debe comenzar con la configuración adecuada de análisis de código estático. Entonces se debe ejecutar la prueba de instrumentación (y probablemente la prueba unitaria).

Una vez realizados los pasos anteriores, la aplicación debe escanearse en modo semiautomático.

El último paso son las pruebas manuales que son obligatorias para las funciones de accesibilidad.

Este texto trata principalmente sobre tareas automatizadas / semiautomatizadas.

1. Verificación de pelusa

El primer paso es verificar el proyecto usando el lint herramienta para encontrar cualquier problema de accesibilidad que el proyecto pueda tener en este momento.

Mientras corre lint considere reducir el alcance de la validación a problemas de accesibilidad únicamente. La razón es obvia: sólo le ahorra tiempo.

La descripción de cada problema se puede encontrar en http://tools.android.com/tips/lint-checks. El proceso de reparación se puede encontrar a continuación.

Pasos de preparación de pelusa

Antes de ejecutar el lint el paso imprescindible es explorar su proyecto para ver si se suprimen ciertos problemas de accesibilidad en este momento. Entonces deberías comprobar:

Por lo tanto, una vez que haya encontrado y eliminado las supresiones por problemas de accesibilidad, puede usar las ID lint verificación.

Corriendo lint

Hay dos formas de ejecutar lint:

La forma de línea de comando tiene buena --check interruptor que permite especificar ID de problemas (https://developer.android.com/studio/write/lint#standalone-lint).

Desafortunadamente, si está usando Android Studio, no puede ingresar los ID de problemas al mando ./gradlew lint.

Por lo tanto, debe ir a Analizar → Inspeccionar código y crear un «Perfil de inspección» desmarcando todo excepto Android → Lint → Accesibilidad:

Entonces corre lint inspección para todo el proyecto:

Solucionar problemas encontrados por pelusa

Tiene sentido abordar todos los problemas de accesibilidad encontrados durante el paso anterior. De lo contrario, existe una alta probabilidad de que los siguientes pasos de prueba revelen estos problemas nuevamente.

El proceso de reparación es bastante trivial, pero podría involucrar al equipo de derechos de autor para proporcionar etiquetas / descripciones válidas.

Como solución temporal, es posible que desee utilizar un determinado valor de cadena como marcador de posición para ContentDescription y LabelFor problemas de accesibilidad.

Considere usar @null para android:contentDescription imágenes decorativas.

2. Instrumentación y pruebas unitarias

El siguiente paso es integrar las pruebas de accesibilidad en las pruebas de instrumentación Espresso, si existen.

Primero el módulo build.gradle debe actualizarse para incluir artefacto espresso-accessibility:

dependencies {
androidTestImplementation "androidx.test.espresso:espresso-accessibility:3.2.0"
}

Entonces la verificación de accesibilidad global debe habilitarse de acuerdo con https://developer.android.com/guide/topics/ui/accessibility/testing#espresso. Quieres actualizar el método @BeforeClass de una clase de prueba o para modificar su subclase de AndroidJUnitRunner.

@BeforeClass
fun setup() {
AccessibilityChecks.enable()
}

Hay una opción para habilitar la aplicación de verificación de accesibilidad setRunChecksFromRootView(true) .

@BeforeClass
fun setup() {
AccessibilityChecks.enable().setRunChecksFromRootView(true)
}

Parece que esta opción debería ser preferible en comparación con solo AccessibilityChecks.enable() porque si setRunChecksFromRootView(true) Si se especifica, el marco de accesibilidad validará toda la jerarquía de vistas de una pantalla.

Para las pruebas unitarias, es posible que también desee habilitar Robolectric para la validación de accesibilidad. Dado que la validación de la accesibilidad es parte del artefacto Robolectric, primero el build.gradle debe actualizarse:

dependencies {
testImplementation "org.robolectric:robolectric:4.3.1"
}

Luego @AccessibilityChecks se debe proporcionar una anotación para la clase de prueba:

@RunWith(RobolectricTestRunner::class)
@AccessibilityChecksclass
MyTest {
}

El resultado de este paso depende de la cobertura del código de las pruebas de instrumentación para su proyecto.

Si el paso anterior «Verificación de pelusa» se realizó bien, no debe esperar una gran cantidad de problemas durante esta fase.

3. Escáner de accesibilidad

El siguiente paso es ejecutar Accessibility Scanner: https://developer.android.com/guide/topics/ui/accessibility/testing#accessibility-scanner. Este paso es semiautomático: debe especificar manualmente una pantalla, pero la pantalla se validará automáticamente.

Debe ejecutar Accessibility Scanner en todas las pantallas de su aplicación a pesar de haber completado el paso anterior de «Prueba de instrumentación» anterior. El motivo es cubrir todo lo perdido:

La lista completa de problemas informados por Accessibility Scanner se puede encontrar aquí: https://support.google.com/accessibility/android/answer/6376559.

Algunos de los problemas simplemente duplicarían lo que se puede encontrar por lint y por los marcos Espresso y Robolectric, pero otros parecen ser únicos.

Por lo tanto, tiene sentido solucionar o eliminar los problemas encontrados en los pasos anteriores antes de ejecutar Accessibility Scanner.

4. Informe previo al lanzamiento

Es posible que también desee inspeccionar el informe previo al lanzamiento: https://developer.android.com/guide/topics/ui/accessibility/testing#pre-launch-report. Se genera una vez que se carga la nueva versión de la aplicación en Play Store.

Debajo del capó, utiliza el escáner de accesibilidad descrito en el paso anterior. Pero dado que ocurre durante la prueba de monos cuando se muestran pantallas aleatorias, existe la posibilidad de que informe de algo omitido durante el paso 3.

5. Prueba manual

Las herramientas de automatización deben considerarse como pasos de verificación iniciales. Tenga en cuenta lo siguiente:

Según los expertos, la prueba manual es el paso imprescindible. Debido a que la tarea es específica, la verificación debe ser realizada por expertos y / o personas discapacitadas.

Gracias por llegar hasta aquí. Espero que le sea útil.