Planificar l'avaluació d'una app: exploració, inventari i mostra

A la lliçó anterior vam fixar la referència normativa (el capítol 11 de l'EN 301 549 (PDF, s'obre en una finestra nova)) i els elements que ha de recollir l'abast. Aquesta lliçó ho converteix en un pla executable: com adaptar els cinc passos de WCAG-EM (s'obre en una finestra nova) a una app, com explorar-la per aixecar un inventari de pantalles, estats i components, com triar una mostra que puguis defensar davant del client i què cal demanar abans del primer dia de proves. Una mostra mal triada invalida l'informe encara que cada prova estigui ben feta.

WCAG-EM aplicat a una app

Els cinc passos de WCAG-EM, que vas veure al nivell 4, es traslladen a una app amb un canvi de vocabulari basat en WCAG2ICT. Aquestes són les equivalències que faràs servir en el pla:

A WCAG-EM (web)	En l'avaluació d'una app
Lloc web	Una app en una plataforma: iOS i Android són dos productes a efectes d'avaluació, encara que comparteixin codi.
Pàgina web	Pantalla, incloses les vistes superposades: modals, fulls inferiors (bottom sheets, panells que pugen des de la vora inferior), menús i diàlegs.
Estats de la pàgina	Estats de la pantalla: buit, carregant, amb dades, error, sense connexió, sense permisos, sessió caducada.
Plantilles comunes	Patrons de navegació (pestanyes, menú lateral) i pantalles que es repeteixen amb contingut diferent.
Tecnologies en què es confia	Versions d'iOS i Android, frameworks (SwiftUI, Compose, React Native, Flutter), contingut web dins de WebViews i tecnologies de suport declarades.
Processos complets	Fluxos: seqüències de pantalles que completen una tasca, inclosos els salts a altres apps, al navegador o a components del sistema.

Infografia · Procés

WCAG-EM aplicat a una app: cinc passos

De la definició de l'abast a l'informe, amb pantalles, estats i fluxos en lloc de pàgines

1. 1Pas 1: 1. Definir l'abastReferència, versió, plataformes, dispositius i tecnologies de suport
2. 2Pas 2: 2. Explorar l'appInventari de pantalles, estats, components, tercers i maquinari
3. 3Pas 3: 3. Seleccionar la mostraEstructurada per capes, fluxos crítics complets i un 10 % aleatori
4. 4Pas 4: 4. AvaluarPassada automàtica, protocol en dispositiu i matriu de cobertura
5. 5Pas 5: 5. InformarResultats per clàusula, troballes amb evidència i declaració

Llegeix la infografia com a text

Procés de cinc passos en seqüència per avaluar una app mòbil adaptant WCAG-EM. Pas 1, definir l'abast: referència normativa, versió i compilació de l'app, plataformes, dispositius i tecnologies de suport. Pas 2, explorar l'app: aixecar un inventari de pantalles, estats, components personalitzats, contingut de tercers, punts d'entrada externs i funcions de maquinari. Pas 3, seleccionar la mostra: estructurada per capes, amb tots els fluxos crítics complets, més una mostra aleatòria d'al voltant del 10 % de l'estructurada. Pas 4, avaluar: passada automàtica, protocol manual en dispositiu físic i una matriu de cobertura que decideix quina configuració es prova a quines pantalles. Pas 5, informar: resultats per clàusula, troballes amb evidència i recomanació, i declaració d'accessibilitat.

Explorar l'app i aixecar l'inventari

Explorar és el pas que més es descuida en apps, perquè no hi ha mapa del lloc ni rastrejador que llisti els URL. Es fa a mà, primer sense tecnologia de suport, anotant el que trobes en sis blocs:

1. Mapa de navegació: pantalles arrel, de segon nivell, modals i fulls inferiors, en un esquema en arbre.
2. Estats: per a cada pantalla rellevant, quins estats pot mostrar. Provoca'ls: activa el mode avió per veure l'error de xarxa, denega un permís, deixa caducar la sessió, fes servir un compte sense dades.
3. Components: separa els estàndard de la plataforma (botons, llistes, interruptors del sistema) dels personalitzats (calendari propi, gràfic, control lliscant dibuixat, carrusel, selector de seient). Els personalitzats són on apareixen els errors de l'11.4.1.2 Nom, funció i valor i de l'11.5.
4. Contingut incrustat: WebViews, PDF que s'obren dins de l'app, vídeos, mapes i SDK de tercers (xat de suport, passarel·la de pagament, enquestes, avís de consentiment).
5. Punts d'entrada externs: notificacions, ginys de la pantalla d'inici, enllaços profunds (deep links, enllaços que obren directament una pantalla interna de l'app) i extensions per compartir.
6. Funcions que depenen del maquinari: càmera (escaneig de codis QR o de documents), NFC (per exemple, lectura del DNI electrònic), geolocalització, biometria, sensors de moviment.

Anota també la tecnologia amb què sembla construïda: condiciona les eines, com veuràs a la lliçó sobre apps híbrides i multiplataforma.

Seleccionar la mostra

Amb l'inventari al davant, la mostra estructurada es construeix per capes, igual que al web, i cada pantalla s'anota amb el motiu pel qual hi entra:

• Pantalles comunes: inici, inici de sessió i registre, menú o ajustos, ajuda i contacte, i la pantalla d'accessibilitat o «Quant a» on s'hauria d'enllaçar la declaració.
• Una pantalla per cada tipus de component personalitzat i per cada patró de navegació.
• Una pantalla per cada funcionalitat principal de l'app.
• Totes les pantalles dels fluxos crítics, de principi a fi, sense saltar-se els passos «avorrits» (confirmacions, justificants, pantalles d'èxit).
• Els estats rellevants de les pantalles anteriors: un formulari s'avalua buit, amb errors i enviat.
• El contingut incrustat que forma part d'un flux (la passarel·la de pagament, el PDF del justificant).

La mostra aleatòria serveix per comprovar que l'estructurada és representativa. WCAG-EM proposa que equivalgui aproximadament al 10 % de la mostra estructurada. Com que en una app no hi ha URL per sortejar, numera les pantalles de l'inventari que no han entrat a l'estructurada i tria amb un generador de nombres aleatoris. Deixa constància del mètode al pla: si la mostra aleatòria treu a la llum problemes que no apareixien a l'estructurada, és senyal que aquesta es va quedar curta.

Fes servir la mateixa mostra a iOS i Android per poder comparar, i documenta les funcions exclusives d'una plataforma. Si les tauletes entren a l'abast, inclou com a mínim els fluxos crítics en tauleta: la disposició canvia i apareixen errors propis.

La matriu de cobertura: què es prova on

El protocol manual que veuràs més endavant enumera deu configuracions. Aplicar-les totes a totes les pantalles en dues plataformes multiplica l'esforç sense aportar troballes. La solució és una matriu de cobertura:

Prova	On s'aplica	Per què
Lector de pantalla (VoiceOver i TalkBack)	Tota la mostra, a les dues plataformes	És la que produeix més troballes.
Text al màxim, orientació horitzontal, mode fosc	Tota la mostra	Són ràpides: una captura per pantalla.
Teclat extern, control per botó (Control amb botó o Switch Access), control per veu	Fluxos crítics i pantalles amb components personalitzats	Allà es concentren els seus errors.
Reduir el moviment, escala de grisos	Pantalles amb animació, gràfics o estats per color	Només aporten en aquestes pantalles.
Reproducció al segon dispositiu	Troballes crítiques i altes	Distingeix els errors de l'app dels d'una versió o d'un fabricant.

El que cal demanar abans de començar

Molts retards no són tècnics, sinó d'accés. Demana per escrit, amb antelació:

• Una versió congelada, identificada per número de versió i de compilació. Si l'app no està publicada, la distribució habitual és TestFlight a iOS i les proves internes de Google Play o Firebase App Distribution a Android.
• Comptes de prova preparats per a cada estat que vulguis avaluar (sense dades, amb historial, amb una incidència oberta) i una solució per al segon factor: codis fixos en preproducció o un telèfon que rebi els SMS.
• Un entorn adequat: preproducció amb la passarel·la de pagament en mode de proves, i confirmació que podràs enregistrar la pantalla (algunes apps ho bloquegen).
• Documentació: sistema de disseny, declaració vigent, informes anteriors i incidències conegudes.
• Un contacte tècnic que conegui la tecnologia de cada part i els components de tercers.

Documentar i tancar el pla

El pla és un document breu que el client valida abans de començar: referència (EN 301 549 v3.2.1, capítol 11 i clàusules aplicables dels capítols 5, 6, 7 i 12, més WCAG 2.2 AA si s'acorda), abast, inventari resumit, mostra justificada, matriu de cobertura, calendari, lliurables i exclusions («el giny de la pantalla d'inici queda fora de l'abast»).

Resum

• Els cinc passos de WCAG-EM es traslladen a les apps: la pàgina passa a ser una pantalla amb els seus estats, el procés passa a ser un flux, i cada plataforma és un producte.
• L'exploració aixeca un inventari de navegació, estats, components, contingut incrustat, punts d'entrada externs i funcions de maquinari.
• La mostra estructurada es construeix per capes i l'aleatòria, al voltant del 10 % de l'estructurada, se sorteja sobre l'inventari.
• Una matriu de cobertura decideix quina configuració es prova a quines pantalles i fluxos.
• Abans de començar cal assegurar una versió congelada, comptes de prova, entorn, permís d'enregistrament i un contacte tècnic, i tancar el pla per escrit.