Cas pràctic, exercicis i llista de comprovació

Aquesta lliçó aplega el curs en un cas realista, resolt pas a pas, seguit d'exercicis d'autoavaluació i una llista de comprovació per als teus projectes. Els noms són ficticis; els problemes són els que apareixen una vegada i una altra en aplicacions reals.

Cas pràctic: l'aplicació municipal d'incidències

Un ajuntament de mida mitjana publica «Mi Barrio», una aplicació nativa (SwiftUI a iOS i Jetpack Compose a Android) per comunicar incidències a la via pública: un fanal fos, un sot, un contenidor desbordat. El flux té quatre pantalles: categoria (quadrícula d'icones), ubicació (mapa amb un punt que s'arrossega), detalls (foto, descripció i dades de contacte) i confirmació. Com que és una aplicació d'una administració pública, està subjecta al RD 1112/2018 (PDF, s'obre en una finestra nova) i ha de complir l'EN 301 549 v3.2.1 (PDF, s'obre en una finestra nova), el capítol 11 de la qual recull els criteris de les WCAG 2.1 de nivell A i AA aplicats al programari; l'equip ja treballa amb les WCAG 2.2, que els inclouen i n'afegeixen d'altres com el 2.5.7, el 2.5.8 i el 3.3.8. Un veí que fa servir TalkBack informa pel mecanisme de comunicació que «no hi ha manera d'enviar una incidència».

Pas 1: recórrer la tasca amb tecnologies de suport

Abans de mirar el codi, l'equip recorre el flux complet amb TalkBack i VoiceOver, amb el text al màxim i amb un teclat Bluetooth, i anota el que sent i el que no pot fer. Resultat:

Pas 2: prioritzar

Primer el que bloqueja la tasca: la ubicació per arrossegament i la confirmació inaccessible impedeixen enviar la incidència, i les icones sense nom impedeixen fins i tot començar. Després el que la dificulta: etiquetes, errors, text gran i orientació. És la mateixa lògica d'impacte per freqüència que vas veure al nivell 4.

Pas 3: corregir

1. Categories: cada cel·la passa a ser un Button amb Label("Enllumenat públic", systemImage: …) a iOS i, a Android, un element selectable amb un Text real sota la icona decorativa (contentDescription = null). El text visible ja és el nom accessible i Voice Control el pot dir.
2. Ubicació: s'hi afegeixen un camp «Escriu una adreça» amb suggeriments, un botó «Fes servir la meva ubicació» i els botons de zoom. El mapa queda com a suport visual; l'adreça triada es mostra en text i s'anuncia. Es revisa que Tab surti del mapa.
3. Detalls: etiquetes visibles amb OutlinedTextField(label = …) i un text a sobre del camp a iOS; textContentType(.telephoneNumber) i contentType = ContentType.PhoneNumber; errors en text amb semantics { error(…) } i anunci del nombre d'errors; la foto té un botó «Afegeix una foto (opcional)» amb nom i estat.
4. Text gran: la pantalla s'embolcalla en un contenidor desplaçable que respecta els insets del teclat; l'etiqueta de la foto admet diverses línies.
5. Confirmació: la capa pròpia se substitueix per una pantalla nova amb el títol «Incidència enviada», que rep el focus i anuncia «Incidència 2026-0412 registrada. Rebràs un avís quan es resolgui».
6. Global: s'elimina el bloqueig d'orientació i cada destinació declara navigationTitle o paneTitle.

Pas 4: protegir i verificar

Es crea un component CampoFormulario que exigeix l'etiqueta i el tipus de contingut, s'hi afegeixen proves de semàntica per a les cel·les de categoria i una auditoria automàtica a les proves d'UI de totes dues plataformes. Finalment, es repeteix el recorregut del pas 1 amb TalkBack, VoiceOver, el text al màxim, el teclat i Switch Access, i es contacta amb el veí que va avisar perquè ho comprovi. La declaració d'accessibilitat de l'aplicació s'actualitza amb el resultat.

Exercicis d'autoavaluació

1. A iOS, una pantalla de configuració mostra una llista d'interruptors propis: un text i una càpsula que canvia de gris a verd en tocar-la. VoiceOver només llegeix el text. Què faries?

2. Una aplicació de banca demana el codi de verificació en sis camps d'una xifra i no permet enganxar. Quins criteris estan en risc i quina és la solució?

3. En tancar un full inferior de filtres a Compose, TalkBack torna al principi de la pantalla. Com ho corregeixes?

4. Les proves d'UI d'iOS localitzen el botó de cerca amb app.buttons["search_btn"], i aquest text és el seu accessibilityLabel. Quin problema hi ha i què hi canviaries?

5. El gràfic de consum de l'aplicació d'una comercialitzadora elèctrica és una imatge sense descripció. Proposa'n la solució mínima i la recomanable.

Llista de comprovació

• Cada control té nom, rol, estat i valor a l'API de la plataforma.
• Els botons d'icona tenen nom, i el nom conté el text visible.
• El que és decoratiu està amagat i les cel·les compostes són un sol element.
• Cada pantalla té un títol anunciat i encapçalaments per seccions.
• L'ordre de recorregut segueix la lògica de la tasca.
• Els diàlegs reben el focus, amaguen el fons i el retornen en tancar-se.
• Tot gest, arrossegament o moviment té una alternativa d'un toc.
• Els objectius tàctils fan almenys 44 pt o 48 dp.
• El text s'escala al màxim sense truncar-se i l'aplicació gira lliurement.
• Els camps tenen etiqueta visible i el propòsit de l'entrada declarat.
• Els errors es mostren en text i s'anuncien.
• L'inici de sessió admet gestors de contrasenyes, enganxament i biometria amb alternativa.
• Els mapes, els gràfics i els carrusels tenen una alternativa accessible.
• Funciona amb VoiceOver, TalkBack, Switch Access i teclat extern.
• El lint, les proves de semàntica i l'auditoria automàtica són a la integració contínua.

Per continuar aprenent

• WCAG2ICT: guia del W3C per aplicar les WCAG 2 a les TIC no web
• W3C WAI: accessibilitat mòbil
• Android Developers: fer aplicacions més accessibles
• Apple: accessibilitat als seus dispositius
• ETSI: EN 301 549 v3.2.1