L'accessibilitat en el flux de desenvolupament: components, previsualitzacions i proves automatitzades

Tot el que has après en aquest curs es perd a l'sprint següent si ningú no ho protegeix: un component nou sense etiqueta, una refactorització que fixa l'alçada d'una cel·la, una biblioteca actualitzada que deixa d'anunciar el canvi de pantalla. Aquesta lliçó se centra en la feina diària de l'equip de desenvolupament: construir una capa de components que faci difícil equivocar-se, revisar l'accessibilitat mentre es programa i automatitzar les comprovacions a les proves d'iOS, Android, React Native i Flutter. L'auditoria formal d'aplicacions, amb Accessibility Inspector, Accessibility Scanner i el protocol de proves manuals, la veuràs al curs «Avaluació d'aplicacions mòbils» d'aquest mateix nivell.

Components que obliguen a fer-ho bé

A la lliçó d'aplicacions híbrides es recomanava una capa de components accessibles pròpia. La versió més eficaç d'aquesta idea és dissenyar les signatures dels components perquè l'error no compili: si el nom accessible és un paràmetre obligatori, ningú no el pot oblidar.

// Compose: el botó d'icona exigeix una descripció
@Composable
fun BotonIcono(icono: ImageVector, descripcion: String, onClick: () -> Unit) {
    IconButton(onClick = onClick) {          // rol de botó i 48 dp de sèrie
        Icon(icono, contentDescription = descripcion)
    }
}

// SwiftUI: el títol és obligatori encara que només es vegi la icona
struct BotonIcono: View {
    let titulo: LocalizedStringKey
    let simbolo: String
    let accion: () -> Void
    var body: some View {
        Button(action: accion) { Label(titulo, systemImage: simbolo) }
            .labelStyle(.iconOnly)           // el títol continua sent el nom accessible
    }
}

Aplica la mateixa idea a la fila de llista (nom compost i accions com a paràmetres), a la capçalera de secció (que sempre marca l'encapçalament), al camp de formulari (etiqueta visible obligatòria, propòsit de l'entrada i missatge d'error) i al diàleg (títol obligatori i focus gestionat). Documenta a cada component què garanteix i què queda en mans de qui el fa servir.

Revisar mentre programes: anàlisi estàtica i previsualitzacions

L'anàlisi estàtica detecta omissions evidents sense executar l'aplicació:

• Android Lint inclou comprovacions d'accessibilitat com ContentDescription (imatge sense descripció), ClickableViewAccessibility, KeyboardInaccessibleWidget i LabelFor. Eleva-les a error a la configuració del projecte perquè bloquegin la integració.
• SwiftLint ofereix regles opcionals com accessibility_label_for_image i accessibility_trait_for_button per a SwiftUI.
• React Native: eslint-plugin-react-native-a11y, que ja vas conèixer a la lliçó d'aplicacions híbrides.

Les previsualitzacions permeten veure cada pantalla amb text gran o contrast augmentat sense obrir el simulador:

// SwiftUI
#Preview("Text AX5") {
    FichaCita(cita: .ejemplo)
        .environment(\.dynamicTypeSize, .accessibility5)
}

// Compose: diverses escales de lletra en una sola anotació
@PreviewFontScale
@Composable
fun FichaCitaPreview() { FichaCita(cita = citaEjemplo) }

@Preview(fontScale = 2f, uiMode = Configuration.UI_MODE_NIGHT_YES)
@Composable
fun FichaCitaGrandeOscuroPreview() { FichaCita(cita = citaEjemplo) }

Durant l'execució, el panell Environment Overrides de Xcode canvia al moment Dynamic Type, Augmentar el contrast o Text en negreta, i el mode UI Check de les previsualitzacions de Compose a Android Studio assenyala problemes d'accessibilitat i d'adaptació. Són revisions de minuts que detecten textos truncats i contrastos insuficients abans d'arribar a les proves.

Proves de semàntica

Una prova de semàntica comprova que un component exposa el nom, el rol, l'estat i les accions que ha d'exposar. És ràpida, estable i documenta el comportament esperat.

// Compose
@get:Rule val compose = createComposeRule()

@Test fun botonBuscarTieneNombreRolYAccion() {
    compose.setContent { BarraSuperior() }
    compose.onNodeWithContentDescription("Cerca")
        .assertHasClickAction()
        .assert(SemanticsMatcher.expectValue(SemanticsProperties.Role, Role.Button))
    compose.onNodeWithText("Moviments de març")
        .assert(SemanticsMatcher.keyIsDefined(SemanticsProperties.Heading))
}

// React Native Testing Library
expect(screen.getByRole('button', { name: 'Cerca' })).toBeOnTheScreen();

// Flutter: cerca per etiqueta semàntica
expect(find.bySemanticsLabel('Cerca'), findsOneWidget);

A iOS, les proves d'UI localitzen els elements per mitjà de la informació d'accessibilitat: app.buttons["Cerca"] busca un botó pel seu identificador o la seva etiqueta, i pots comprovar que label té el valor esperat.

Auditories automàtiques dins de les proves d'UI

Les plataformes permeten executar comprovacions automàtiques d'accessibilitat sobre cada pantalla que recorren les proves:

// iOS 17 / Xcode 15: auditoria de la pantalla actual
func testAuditoriaMisCitas() throws {
    let app = XCUIApplication()
    app.launch()
    app.buttons["Les meves cites"].tap()
    try app.performAccessibilityAudit(for: [.dynamicType, .contrast, .hitRegion,
                                            .sufficientElementDescription, .textClipped]) { incidencia in
        // Retorna true només per a les incidències revisades i documentades
        incidencia.auditType == .contrast && incidencia.element?.identifier == "logo-municipal"
    }
}

// Android amb Espresso: comprovacions de l'Accessibility Test Framework a cada acció
@BeforeClass @JvmStatic
fun activarComprobaciones() {
    AccessibilityChecks.enable().setRunChecksFromRootView(true)
}

// Flutter: guies incloses a flutter_test
testWidgets('la pantalla de cites compleix les guies bàsiques', (tester) async {
  final handle = tester.ensureSemantics();
  await tester.pumpWidget(const MiApp());
  await expectLater(tester, meetsGuideline(androidTapTargetGuideline));
  await expectLater(tester, meetsGuideline(labeledTapTargetGuideline));
  await expectLater(tester, meetsGuideline(textContrastGuideline));
  handle.dispose();
});

Les versions recents de la biblioteca de proves de Compose permeten activar també les comprovacions de l'Accessibility Test Framework; consulta la documentació de la teva versió. Aquestes auditories detecten elements sense descripció, objectius tàctils petits, contrast insuficient o text retallat amb text gran. No detecten si una etiqueta és correcta, si l'ordre de lectura té sentit, si el focus torna al lloc adequat en tancar un diàleg ni si una tasca completa es pot dur a terme: com vas veure al curs d'eines automàtiques del nivell 4, l'automatització cobreix només una part dels problemes.

Criteris d'acceptació i definició de fet

L'automatització se sosté amb acords d'equip. Inclou a la definició de fet de cada història amb interfície uns pocs criteris verificables:

• Recorregut complet de la funcionalitat amb VoiceOver i TalkBack en dispositiu real, sense elements muts ni duplicats.
• Pantalles revisades amb el text al màxim i amb text en negreta, sense truncaments.
• Gestos amb alternativa i accions d'accessibilitat; objectius de 44 pt o 48 dp.
• Focus gestionat als canvis de pantalla, als diàlegs i als errors.
• Proves de semàntica i auditoria automàtica en verd a la integració contínua.

Resum

• Dissenya components les signatures dels quals exigeixin el nom accessible, l'etiqueta visible i el títol: l'error deixa de compilar.
• Fes servir l'anàlisi estàtica (Android Lint, SwiftLint, eslint) i previsualitzacions amb text gran i contrast mentre programes.
• Les proves de semàntica verifiquen el nom, el rol, l'estat i les accions; localitza els elements amb identificadors de prova, mai amb etiquetes falses.
• performAccessibilityAudit, AccessibilityChecks i les guies de flutter_test automatitzen comprovacions a cada pantalla, però no substitueixen la prova manual.
• Una definició de fet amb criteris d'accessibilitat verificables protegeix la feina a cada lliurament.