Herramientas: Accessibility Inspector (Xcode), Accessibility Scanner, Lint y auditorías automatizadas

Las herramientas automáticas para apps detectan una parte menor de los problemas que en web (no hay un DOM estandarizado que analizar), pero son imprescindibles para inspeccionar el árbol de accesibilidad, medir tamaños y contrastes y evitar regresiones. Esta lección presenta las herramientas de Apple y Google, las de terceros más usadas y cómo integrarlas en las pruebas automatizadas. Siempre con la misma advertencia: lo que estas herramientas no ven lo tiene que ver una persona en un dispositivo.

iOS: Accessibility Inspector de Xcode

Se abre desde Xcode > Open Developer Tool > Accessibility Inspector. Funciona con el simulador y con un dispositivo conectado. Tres modos:

1. Inspección: al activar el selector (icono de diana) y pulsar un elemento, muestra lo que VoiceOver anunciará: Label, Value, Traits, Identifier, Hint, además de su jerarquía (Hierarchy) y las acciones disponibles. Los botones de navegación permiten recorrer los elementos en el orden de VoiceOver, lo que sirve para verificar el orden de lectura sin encender VoiceOver. El botón de altavoz reproduce el anuncio.
2. Auditoría (Audit): «Run Audit» analiza la pantalla actual y lista advertencias: elementos sin descripción, textos que no soportan Dynamic Type, contraste insuficiente, áreas táctiles pequeñas (<44×44), elementos con el mismo label, imágenes sin descripción, rasgos incoherentes. Cada aviso enlaza con el elemento y propone una solución.
3. Ajustes (Settings): permite activar en el simulador Invertir colores, Aumentar contraste, Reducir transparencia, Reducir movimiento y cambiar el tamaño de Dynamic Type sin salir de la app, para capturar pantallas en cada configuración.

Limitaciones: la auditoría solo analiza la pantalla visible y el estado actual; no detecta agrupaciones mal hechas (una celda leída como cuatro elementos), labels poco útiles, foco perdido tras una acción ni problemas de flujo. Complemento útil: el Environment Overrides de Xcode (en la barra de depuración) permite cambiar Dynamic Type y otros ajustes en caliente.

Auditoría automatizada en XCUITest

Desde Xcode 15, las pruebas de interfaz pueden ejecutar la misma auditoría del Inspector:

func testPantallaMovimientosAccesible() throws {
    let app = XCUIApplication()
    app.launch()
    app.tabBars.buttons["Movimientos"].tap()
    try app.performAccessibilityAudit()            // todos los tipos
    // o filtrando: try app.performAccessibilityAudit(for: [.dynamicType, .contrast, .hitRegion])
}

Con performAccessibilityAudit(for:_:) se puede ignorar un aviso concreto justificado mediante el bloque de issue handler. Integrar estas pruebas en la integración continua evita regresiones (botones nuevos sin etiqueta, textos con tamaño fijo).

Android: Accessibility Scanner

Accessibility Scanner es una app gratuita de Google (Play Store) que se instala en el dispositivo y actúa como servicio de accesibilidad. Flujo:

1. Instalar, activar en Ajustes > Accesibilidad > Accessibility Scanner. Aparece un botón flotante.
2. Abrir la app a evaluar, pulsar el botón flotante y elegir captura (una pantalla) o grabación (recorre varias pantallas mientras interactúas).
3. Scanner marca en naranja cada elemento con sugerencias: etiqueta de contenido ausente (botones de imagen sin contentDescription), tamaño del objetivo táctil (<48×48 dp), contraste de texto (<4,5:1) y de imagen, elementos clickables duplicados o superpuestos, descripciones redundantes («botón Guardar botón»), elementos editables sin etiqueta, texto escalable (tamaños en dp).
4. Los resultados se comparten como informe con capturas marcadas, útiles como evidencia.

Scanner analiza el árbol de accesibilidad que ve el servicio, igual que TalkBack, así que sus hallazgos sobre etiquetas son fiables. No evalúa orden de lectura, agrupación, anuncios, estados personalizados ni flujo. Para el contraste, mide píxeles y puede dar falsos positivos con texto sobre degradados o imágenes.

Android: Lint, Layout Inspector y pruebas

• Android Lint (Android Studio > Analyze > Inspect Code, o ./gradlew lint) incluye comprobaciones de accesibilidad en XML: ContentDescription (ImageView/ImageButton sin descripción), LabelFor (EditText sin etiqueta), ClickableViewAccessibility (vistas con onTouch sin performClick), KeyboardInaccessibleWidget (clickable sin focusable), SpUsage (textos en dp) y SmallSp (textos de menos de 12 sp). Para Compose no hay reglas Lint equivalentes de serie; existen reglas de terceros y la verificación recae en pruebas e inspección.
• Layout Inspector (Android Studio) muestra la jerarquía de vistas y, en Compose, los nodos de semántica con sus atributos (contentDescription, role, stateDescription). Es la forma de verificar lo que expone un composable sin dispositivo.
• Pruebas Espresso con AccessibilityChecks: añadiendo AccessibilityChecks.enable().setRunChecksFromRootView(true) en la configuración de la prueba, cada acción de Espresso ejecuta las comprobaciones del Accessibility Test Framework (las mismas de Scanner) y falla si hay problemas. Puedes suprimir casos concretos con setSuppressingResultMatcher.
• Pruebas de Compose: composeTestRule.onNodeWithContentDescription("Buscar"), assertHasClickAction(), assert(SemanticsMatcher.expectValue(SemanticsProperties.Role, Role.Button)) y printToLog() para volcar el árbol de semántica; el Accessibility Test Framework también puede activarse en pruebas de Compose.

@RunWith(AndroidJUnit4::class)
class MovimientosTest {
    companion object {
        @BeforeClass @JvmStatic fun habilitarA11y() {
            AccessibilityChecks.enable().setRunChecksFromRootView(true)
        }
    }
    @Test fun abrirDetalle() {
        onView(withText("Movimientos")).perform(click())  // ejecuta las comprobaciones
        onView(withContentDescription("Buscar")).check(matches(isDisplayed()))
    }
}

Herramientas de terceros

• axe DevTools Mobile (Deque): analizadores para iOS y Android integrables en pruebas o como app, con reglas alineadas con WCAG y informes centralizados. Útil en equipos con varias apps.
• Evinced Mobile: SDK y escáner con detección de problemas de foco y de controles personalizados.
• Google Accessibility Test Framework for Android: la librería que usan Scanner y Espresso; puede ejecutarse de forma independiente.
• Colour Contrast Analyser (TPGi) o el analizador de la propia herramienta de diseño (Figma con plugins) para medir contraste sobre capturas del dispositivo.
• Grabación de pantalla con salida de voz: en Android, TalkBack > Ajustes de desarrollador > Mostrar salida de voz; en iOS, VoiceOver > Panel de subtítulos. Combinadas con la grabación de pantalla del sistema, producen la evidencia más clara para un informe.

Qué no verá ninguna herramienta

• Una celda cuyo contenido se lee en cuatro elementos separados (agrupación).
• Un botón etiquetado «imagen 3» o «ic_check» (calidad de la etiqueta).
• Un diálogo que no bloquea el contenido de detrás (foco modal).
• Una pantalla nueva sin anuncio de título ni foco inicial.
• Un deslizamiento lateral como única vía para una acción.
• Un temporizador de sesión sin aviso ni ampliación.
• Un calendario personalizado que expone los días sin fecha completa ni estado.

Resumen

• Accessibility Inspector (Xcode): inspección de label/value/traits/hint, auditoría de pantalla y simulación de ajustes; performAccessibilityAudit() lo lleva a XCUITest.
• Accessibility Scanner (Android): etiquetas, tamaño de objetivo, contraste y texto escalable, con informe compartible; Lint y Layout Inspector completan en desarrollo.
• Espresso con AccessibilityChecks y las pruebas de Compose permiten comprobar automáticamente en cada cambio.
• Herramientas de terceros (axe DevTools Mobile, Evinced) añaden reglas y gestión centralizada.
• Lo automático cubre cuatro tipos de problema; orden, agrupación, roles personalizados, anuncios, foco, gestos y flujos exigen pruebas manuales.