La resposta curta
Si l'app és d'una administració pública espanyola, l'accessibilitat no és una bona pràctica: és una obligació amb norma tècnica, amb declaració pública i amb un procediment de reclamació pel qual qualsevol ciutadà pot exigir-te comptes.
Ho regula el Reial decret 1112/2018, que s'aplica als llocs web i aplicacions per a dispositius mòbils del sector públic a tots els nivells: Administració General de l'Estat, comunitats autònomes, entitats locals, organismes públics i òrgans judicials.
I hi ha una frase a l'article 7 que convé llegir abans de plantejar cap excepció: «la manca de prioritat, de temps o de coneixement no pot justificar l'excepció».
La norma tècnica
El decret remet a la norma EN 301 549 com a referència per presumir la conformitat: el contingut que compleix les seves disposicions aplicables es considera conforme. Al text s'hi cita la versió V1.1.2 (2015-04); com tota norma harmonitzada s'actualitza, cal treballar sempre contra la versió vigent aplicable en el moment del projecte, i confirmar-ho amb l'organisme.
En allò que afecta el dia a dia de l'equip, aquesta norma incorpora els criteris de les pautes WCAG, i en mòbil es tradueix en coses concretes:
- Etiquetes d'accessibilitat a tots els elements interactius, amb text que digui què fan i no com es diuen internament.
- Ordre de focus lògic i navegació completa sense dependre del gest.
- Contrast verificat, no aproximat a ull.
- Àrees tàctils suficients.
- Textos que escalen quan l'usuari augmenta la mida de lletra del sistema, sense que la pantalla es trenqui.
- Alternatives per al contingut no textual.
- Lectors de pantalla reals: VoiceOver i TalkBack, provats en dispositiu, no en simulador.
La declaració d'accessibilitat
No és un paràgraf al peu de pàgina. L'article 15 exigeix que l'entitat responsable del web o l'aplicació faciliti una declaració «detallada, exhaustiva i clara» sobre la conformitat, en format accessible, i anual.
I ha d'incloure dues coses que obliguen a fer els deures de debò:
- El contingut no accessible, explicat. És a dir: cal saber què no compleix i per què, cosa que implica haver-ho auditat.
- Els mecanismes de contacte per reclamar.
Per a l'equip de desenvolupament, la conseqüència pràctica és que el material de la declaració és un lliurable del projecte. Si no és a l'abast, algú l'escriurà a última hora sense dades.
El mecanisme de reclamació
L'article 10 estableix dues vies, i convé distingir-les perquè tenen conseqüències diferents:
- Comunicacions sobre requisits d'accessibilitat, per correu electrònic, telèfon o oficina.
- Sol·licituds d'informació i queixes, que es tramiten pel procediment administratiu, amb un termini de resposta de vint dies hàbils.
Aquest termini és el que converteix l'accessibilitat en un assumpte operatiu i no només tècnic: algú de l'organisme ha de poder respondre en vint dies hàbils, i per a això necessita saber què falla i quan s'arreglarà. Si el proveïdor no li ha deixat aquesta informació, no pot.
Revisió i seguiment
Les entitats han de revisar l'accessibilitat abans de la posada en marxa i després periòdicament. I hi ha seguiment estatal: el ministeri competent coordina la supervisió i informa la Comissió Europea cada tres anys.
Traduït al projecte: la revisió prèvia al llançament és una fase, amb el seu temps i el seu responsable. Descobrir els incompliments en aquella revisió, amb la data de publicació a sobre, és l'escenari car.
Com es fa sense que faci mal
- Des del disseny. Contrast, mides i jerarquia es decideixen a Figma, no es pedacen al codi.
- Components accessibles per defecte. Si el sistema de disseny ja porta la semàntica posada, l'equip no se n'ha de recordar a cada pantalla.
- Comprovacions automàtiques al pipeline, que cacen contrast, etiquetes absents i àrees tàctils petites. No ho detecten tot, però eviten regressions silencioses.
- Proves manuals amb lector de pantalla a cada lliurament, sobre els fluxos principals.
- I amb persones usuàries reals quan el projecte ho permet. És el que distingeix complir de servir.
L'ordre importa: incorporar accessibilitat des del primer sprint costa una fracció de reconstruir-la sobre una app acabada.
Els errors més repetits
- Etiquetes heretades del codi: un botó que el lector anuncia com «button_submit_2».
- Imatges decoratives anunciades com si tinguessin contingut, omplint de soroll la navegació.
- Focus perdut en obrir un diàleg, deixant l'usuari de lector de pantalla enlloc.
- Colors com a únic portador d'informació: un estat que només es distingeix per vermell o verd.
- Text dins d'imatges, que no escala ni es llegeix.
Abans d'estimar
- Quina versió de la norma exigeix l'organisme?
- Qui audita, i amb quina metodologia?
- És a l'abast el material de la declaració?
- Hi ha sistema de disseny previ, i és accessible?
- Qui respondrà les reclamacions i amb quina informació?
La tercera i la cinquena són les que ningú pressuposta i les que sempre acaben fent falta.
Forma part de la feina estàndard en apps per al sector públic: l'accessibilitat no és una capa que s'afegeix, és una restricció de disseny des de la primera pantalla.
Font primària, consultada el 14 d'agost de 2026: Reial decret 1112/2018, sobre accessibilitat dels llocs web i aplicacions per a dispositius mòbils del sector públic.
