Eines: Accessibility Inspector (Xcode), Accessibility Scanner, Lint i auditories automatitzades

Les eines automàtiques per a apps detecten una part més petita dels problemes que al web (no hi ha un DOM estandarditzat per analitzar), però són imprescindibles per inspeccionar l'arbre d'accessibilitat, mesurar mides i contrastos i evitar regressions. Aquesta lliçó presenta les eines d'Apple i Google, les de tercers més utilitzades i com integrar-les en les proves automatitzades. Sempre amb la mateixa advertència: el que aquestes eines no veuen ho ha de veure una persona en un dispositiu.

iOS: Accessibility Inspector d'Xcode

S'obre des d'Xcode > Open Developer Tool > Accessibility Inspector. Funciona amb el simulador i amb un dispositiu connectat. Tres modes:

1. Inspecció: en activar el selector (icona de diana) i prémer un element, mostra el que VoiceOver anunciarà: Label, Value, Traits, Identifier, Hint, a més de la seva jerarquia (Hierarchy) i les accions disponibles. Els botons de navegació permeten recórrer els elements en l'ordre de VoiceOver, cosa que serveix per verificar l'ordre de lectura sense engegar VoiceOver. El botó d'altaveu reprodueix l'anunci.
2. Auditoria (Audit): «Run Audit» analitza la pantalla actual i llista advertiments: elements sense descripció, textos que no admeten Dynamic Type, contrast insuficient, àrees tàctils petites (<44×44), elements amb el mateix label, imatges sense descripció, trets incoherents. Cada avís enllaça amb l'element i proposa una solució.
3. Ajustos (Settings): permet activar al simulador Invertir colors, Augmentar el contrast, Reduir la transparència, Reduir el moviment i canviar la mida de Dynamic Type sense sortir de l'app, per capturar pantalles en cada configuració.

Limitacions: l'auditoria només analitza la pantalla visible i l'estat actual; no detecta agrupacions mal fetes (una cel·la llegida com a quatre elements), labels poc útils, focus perdut després d'una acció ni problemes de flux. Complement útil: l'Environment Overrides d'Xcode (a la barra de depuració) permet canviar Dynamic Type i altres ajustos en calent.

Auditoria automatitzada a XCUITest

Des d'Xcode 15, les proves d'interfície poden executar la mateixa auditoria de l'Inspector:

func testPantallaMovimientosAccesible() throws {
    let app = XCUIApplication()
    app.launch()
    app.tabBars.buttons["Moviments"].tap()
    try app.performAccessibilityAudit()            // tots els tipus
    // o filtrant: try app.performAccessibilityAudit(for: [.dynamicType, .contrast, .hitRegion])
}

Amb performAccessibilityAudit(for:_:) es pot ignorar un avís concret justificat mitjançant el bloc d'issue handler. Integrar aquestes proves en la integració contínua evita regressions (botons nous sense etiqueta, textos amb mida fixa).

Android: Accessibility Scanner

Accessibility Scanner és una app gratuïta de Google (Play Store) que s'instal·la al dispositiu i actua com a servei d'accessibilitat. Flux:

1. Instal·lar-la i activar-la a Configuració > Accessibilitat > Accessibility Scanner. Apareix un botó flotant.
2. Obrir l'app que cal avaluar, prémer el botó flotant i triar captura (una pantalla) o enregistrament (recorre diverses pantalles mentre hi interactues).
3. Scanner marca en taronja cada element amb suggeriments: etiqueta de contingut absent (botons d'imatge sense contentDescription), mida de l'objectiu tàctil (<48×48 dp), contrast de text (<4,5:1) i d'imatge, elements clicables duplicats o superposats, descripcions redundants («botó Desa botó»), elements editables sense etiqueta, text escalable (mides en dp).
4. Els resultats es comparteixen com a informe amb captures marcades, útils com a evidència.

Scanner analitza l'arbre d'accessibilitat que veu el servei, igual que TalkBack, així que les seves troballes sobre etiquetes són fiables. No avalua l'ordre de lectura, l'agrupació, els anuncis, els estats personalitzats ni el flux. Pel que fa al contrast, mesura píxels i pot donar falsos positius amb text sobre degradats o imatges.

Android: Lint, Layout Inspector i proves

• Android Lint (Android Studio > Analyze > Inspect Code, o ./gradlew lint) inclou comprovacions d'accessibilitat en XML: ContentDescription (ImageView/ImageButton sense descripció), LabelFor (EditText sense etiqueta), ClickableViewAccessibility (vistes amb onTouch sense performClick), KeyboardInaccessibleWidget (clicable sense focusable), SpUsage (textos en dp) i SmallSp (textos de menys de 12 sp). Per a Compose no hi ha regles Lint equivalents de sèrie; n'hi ha de tercers i la verificació recau en les proves i la inspecció.
• Layout Inspector (Android Studio) mostra la jerarquia de vistes i, a Compose, els nodes de semàntica amb els seus atributs (contentDescription, role, stateDescription). És la manera de verificar què exposa un composable sense dispositiu.
• Proves Espresso amb AccessibilityChecks: si s'afegeix AccessibilityChecks.enable().setRunChecksFromRootView(true) a la configuració de la prova, cada acció d'Espresso executa les comprovacions de l'Accessibility Test Framework (les mateixes de Scanner) i falla si hi ha problemes. Pots suprimir casos concrets amb setSuppressingResultMatcher.
• Proves de Compose: composeTestRule.onNodeWithContentDescription("Cerca"), assertHasClickAction(), assert(SemanticsMatcher.expectValue(SemanticsProperties.Role, Role.Button)) i printToLog() per bolcar l'arbre de semàntica; l'Accessibility Test Framework també es pot activar en proves de Compose.

@RunWith(AndroidJUnit4::class)
class MovimientosTest {
    companion object {
        @BeforeClass @JvmStatic fun habilitarA11y() {
            AccessibilityChecks.enable().setRunChecksFromRootView(true)
        }
    }
    @Test fun abrirDetalle() {
        onView(withText("Moviments")).perform(click())  // executa les comprovacions
        onView(withContentDescription("Cerca")).check(matches(isDisplayed()))
    }
}

Eines de tercers

• axe DevTools Mobile (Deque): analitzadors per a iOS i Android integrables en proves o com a app, amb regles alineades amb WCAG i informes centralitzats. Útil en equips amb diverses apps.
• Evinced Mobile: SDK i escàner amb detecció de problemes de focus i de controls personalitzats.
• Google Accessibility Test Framework for Android: la biblioteca que fan servir Scanner i Espresso; es pot executar de manera independent.
• Colour Contrast Analyser (TPGi) o l'analitzador de la mateixa eina de disseny (Figma amb connectors) per mesurar el contrast sobre captures del dispositiu.
• Enregistrament de pantalla amb sortida de veu: a Android, TalkBack > Configuració per a desenvolupadors > Mostra la sortida de veu; a iOS, VoiceOver > Tauler de subtítols. Combinades amb l'enregistrament de pantalla del sistema, produeixen l'evidència més clara per a un informe.

Què no veurà cap eina

• Una cel·la el contingut de la qual es llegeix en quatre elements separats (agrupació).
• Un botó etiquetat «imatge 3» o «ic_check» (qualitat de l'etiqueta).
• Un diàleg que no bloqueja el contingut del darrere (focus modal).
• Una pantalla nova sense anunci de títol ni focus inicial.
• Un lliscament lateral com a única via per a una acció.
• Un temporitzador de sessió sense avís ni ampliació.
• Un calendari personalitzat que exposa els dies sense data completa ni estat.

Resum

• Accessibility Inspector (Xcode): inspecció de label/value/traits/hint, auditoria de pantalla i simulació d'ajustos; performAccessibilityAudit() ho porta a XCUITest.
• Accessibility Scanner (Android): etiquetes, mida de l'objectiu, contrast i text escalable, amb informe compartible; Lint i Layout Inspector ho completen durant el desenvolupament.
• Espresso amb AccessibilityChecks i les proves de Compose permeten comprovar automàticament a cada canvi.
• Les eines de tercers (axe DevTools Mobile, Evinced) afegeixen regles i gestió centralitzada.
• L'automàtic cobreix quatre tipus de problema; l'ordre, l'agrupació, els rols personalitzats, els anuncis, el focus, els gestos i els fluxos exigeixen proves manuals.