Apps híbrides, multiplataforma i WebViews: identificar la tecnologia i atribuir els errors

Com vas veure al curs d'apps mòbils accessibles d'aquest nivell, moltes apps no estan escrites només amb UIKit, SwiftUI o Compose: fan servir React Native o Flutter, o són un web dins d'un contenidor natiu. Per a qui avalua, això canvia tres coses: quina referència s'aplica a cada part de l'app, quines eines poden veure'n l'arbre d'accessibilitat i a qui va adreçada la correcció. Aquesta lliçó t'ensenya a identificar la tecnologia, a avaluar-la amb les eines adequades i a atribuir cada error a qui el pot corregir.

Identificar la tecnologia

La manera més fiable és preguntar-ho a l'equip, i hauria de constar al pla d'avaluació. Quan no hi ha resposta o la vols confirmar, tens diverses pistes:

• La pantalla de llicències (a «Quant a» o als ajustos) sol llistar les biblioteques de codi obert: Flutter, React Native, Capacitor o Cordova hi apareixen sovint.
• Mostra els límits de disseny (Android, Opcions per a desenvolupadors): en una app nativa o en React Native veuràs un rectangle per cada vista; a Flutter o en una WebView veuràs una única superfície gran, perquè el contingut s'hi dibuixa a dins.
• El paquet de l'app: si el client et facilita l'APK, l'analitzador d'APK d'Android Studio en mostra el contingut. Una biblioteca libflutter.so delata Flutter; biblioteques de React Native o del motor Hermes delaten React Native; una carpeta de recursos amb un index.html i fitxers JavaScript delata Cordova o Capacitor.
• El comportament: text que se selecciona com en un navegador, desplaçaments amb el rebot propi del web o un lector de pantalla que anuncia «enllaç» o «regió» en una app són indicis de contingut web.

Quina referència s'aplica a cada capa

Una mateixa app pot barrejar capes. Avalua cadascuna amb la referència que li correspon i deixa clar a cada troballa de quina capa es tracta:

Capa	Exemples	Referència	Eines
Nativa	UIKit, SwiftUI, Android Views, Jetpack Compose	EN 301 549 (PDF, s'obre en una finestra nova) cap. 11	Accessibility Inspector, Accessibility Scanner, Layout Inspector
Multiplataforma amb components natius	React Native, .NET MAUI	Cap. 11 (es generen vistes natives)	Les natives, més l'inspector d'elements i les proves del framework
Multiplataforma amb motor de dibuix propi	Flutter	Cap. 11	Les natives (veuen el que Flutter exposa) i el depurador de semàntica de Flutter
Contingut web en una WebView	Ionic amb Capacitor, Cordova, pantalles web incrustades en una app nativa	Contingut web: criteris WCAG (l'EN remet el contingut web al cap. 9); contenidor natiu: cap. 11	Inspecció remota del navegador i eines de web
Documents que s'obren a l'app	Justificants i formularis PDF	Cap. 10 i PDF/UA	Les del curs de PDF accessible d'aquest nivell

Com que la numeració dels criteris és paral·lela (l'11.1.4.3 i el 9.1.4.3 són l'1.4.3 Contrast (mínim)), la troballa es pot registrar amb la referència de la seva capa i una nota a la metodologia de l'informe que expliqui la composició de l'app.

Eines per a cada tecnologia

WebViews

El contingut d'una WebView s'inspecciona com un web, però en remot. A Android, connecta el dispositiu per USB i obre chrome://inspect al Chrome d'escriptori; l'app ha de tenir activada la depuració de WebView (WebView.setWebContentsDebuggingEnabled(true)), cosa habitual en compilacions de depuració. A iOS, es fa servir el menú Desenvolupament de Safari en un Mac; des d'iOS 16.4 l'app ha de marcar el seu WKWebView com a inspeccionable (isInspectable = true). Amb això tens les eines de desenvolupament, el tauler d'accessibilitat i la possibilitat d'executar comprovacions automàtiques com les del nivell 4. Demana aquestes compilacions al pla: sense elles, només podràs avaluar la WebView des de fora, amb el lector de pantalla.

Flutter

Flutter dibuixa els seus propis píxels i construeix un arbre de semàntica que trasllada a l'API d'accessibilitat de cada plataforma. Per això VoiceOver, TalkBack, l'Inspector i Scanner només veuen el que conté aquest arbre. Per inspeccionar-lo, demana una compilació de depuració amb showSemanticsDebugger: true a MaterialApp, que superposa en pantalla els nodes de semàntica amb la seva etiqueta. L'equip, a més, pot automatitzar comprovacions en les seves proves de widgets:

testWidgets('La pantalla de cita compleix les pautes', (tester) async {
  final handle = tester.ensureSemantics();
  await tester.pumpWidget(const AppCitas());
  await expectLater(tester, meetsGuideline(androidTapTargetGuideline));
  await expectLater(tester, meetsGuideline(iOSTapTargetGuideline));
  await expectLater(tester, meetsGuideline(labeledTapTargetGuideline));
  await expectLater(tester, meetsGuideline(textContrastGuideline));
  handle.dispose();
});

Errors típics: zones tàctils fetes amb GestureDetector sense Semantics (no s'anuncien com a botó o no tenen nom), gràfics dibuixats amb CustomPaint sense descripció, llistes les files de les quals es llegeixen fragmentades per manca de MergeSemantics i contingut informatiu ocultat per error amb ExcludeSemantics.

React Native

React Native genera vistes natives, així que les eines de la plataforma funcionen directament. El menú de desenvolupament inclou un inspector d'elements que relaciona cada vista amb el seu component. Els errors més habituals són components prémibles (Pressable, TouchableOpacity) sense accessibilityRole="button", que s'anuncien sense rol; contenidors prémibles que fusionen tot el seu contingut en una etiqueta interminable; i modals propis que no impedeixen al lector sortir del diàleg. Per a les proves, React Native Testing Library permet cercar per rol i nom, igual que al web: getByRole('button', { name: 'Envia' }).

Errors de frontera entre capes

Els problemes més difícils apareixen on es toquen dues capes:

• Pas de natiu a web: en obrir una pantalla web, el focus del lector es queda a la barra nativa o salta al final; no s'anuncia cap títol; el botó Enrere natiu i l'historial del web no coincideixen.
• Mida del text: el contingut web no sempre segueix la mida de text del sistema. A iOS, per exemple, el web ha de fer servir les lletres de sistema de WebKit (com ara font: -apple-system-body) o l'app ha d'ajustar el zoom. Comprova-ho sempre amb el text al 200 %.
• Zoom bloquejat: una etiqueta viewport amb user-scalable=no o maximum-scale=1 al contingut web impedeix ampliar.
• Gestos en conflicte: carrusels web que capturen els lliscaments del lector de pantalla i deixen la persona atrapada.
• Contingut duplicat: un text que existeix a la capa nativa i a la web i es llegeix dues vegades.

Atribuir l'error: app, framework, plataforma o tecnologia de suport

Una troballa ben atribuïda es corregeix abans. Abans de redactar-la, recorre aquesta seqüència:

1. Es reprodueix en un altre dispositiu, una altra versió del sistema i l'altra plataforma? Si només falla amb la versió de TalkBack d'un fabricant, és probable que no sigui un error de l'app.
2. Passa també amb un component estàndard de la plataforma? Si un interruptor del sistema es comporta igual de malament, el problema és de la plataforma o de la tecnologia de suport.
3. És un component del framework sense modificar? Consulta'n la documentació i el registre públic d'incidències: pot ser una limitació coneguda amb una solució alternativa.
4. Classifica i redacta: error de l'app (el corregeix l'equip), limitació del framework (solució alternativa recomanada i avís al projecte), o problema de la plataforma o de la tecnologia de suport (observació, no incompliment de l'app, llevat que l'app ho pugui evitar amb un disseny diferent).

Resum

• Identifica la tecnologia preguntant a l'equip i confirmant-ho amb les llicències, els límits de disseny, el paquet de l'app o el seu comportament.
• Cada capa té la seva referència: cap. 11 per al que és natiu i multiplataforma, criteris WCAG de contingut web per al que carrega una WebView, cap. 10 i PDF/UA per als documents.
• Les WebViews s'inspeccionen en remot (chrome://inspect, Safari); Flutter amb el seu depurador de semàntica i les seves pautes en proves; React Native amb les eines natives i el seu inspector.
• Les fronteres entre capes concentren errors de focus, títol, mida del text, zoom i gestos.
• Atribueix cada error (app, framework, plataforma o tecnologia de suport) abans de redactar-lo i escriu la recomanació en el llenguatge de l'equip.