EN 301 549 capítol 11 i aplicació de les WCAG a apps natives

Quan un auditor avalua una pàgina web sap amb què ha de mesurar: WCAG 2.2 nivell AA o, en el marc normatiu europeu, l'EN 301 549 (PDF, s'obre en una finestra nova) capítol 9, que avui equival a WCAG 2.1 AA. Amb una app mòbil la referència és el capítol 11 de l'EN 301 549 («Programari»), que conté els criteris WCAG adaptats més una sèrie de requisits propis sobre la interoperabilitat amb tecnologies de suport i les preferències de l'usuari. Aquesta lliçó desgrana aquest capítol perquè puguis construir la llista de comprovació d'una auditoria d'app.

Què cobreix el capítol 11

L'EN 301 549 v3.2.1 (2021) és la norma harmonitzada que la Directiva (UE) 2016/2102 (PDF, s'obre en una finestra nova) i el RD 1112/2018 (PDF, s'obre en una finestra nova) prenen com a referència per a llocs web i aplicacions mòbils del sector públic, i també la referència tècnica habitual per a la Llei 11/2023 (PDF, s'obre en una finestra nova) en el sector privat mentre no se citi al DOUE una norma harmonitzada per a la Directiva (UE) 2019/882 (PDF, s'obre en una finestra nova) (l'EN 301 549 v4.1.1 (PDF, s'obre en una finestra nova), publicada el setembre de 2026, està pendent d'aquesta citació). El capítol 11 s'aplica al programari no web: aplicacions d'escriptori, apps mòbils natives i híbrides (la part nativa), i també al programari amb «funcionalitat tancada» (quioscos, terminals) mitjançant notes específiques. La seva estructura:

Els criteris WCAG en programari: el que canvia

En 11.1-11.4 gairebé tot és reconeixible, però hi ha matisos que un auditor ha de conèixer:

• Criteris buits: 11.2.4.1 Evitar blocs, 11.2.4.2 Pàgina titulada, 11.2.4.5 Múltiples vies, 11.3.2.3 Navegació coherent i 11.3.2.4 Identificació coherent apareixen com a «buits» (void) a l'EN 301 549 v3.2.1 perquè no s'apliquen a un programa aïllat (es refereixen a conjunts de pàgines o de programes). No s'avaluen com a requisit, encara que la coherència entre pantalles continua sent una bona pràctica.
• 11.2.4.2 Pàgina titulada: tot i que WCAG2ICT aplica el 2.4.2 al programari, la v3.2.1 el deixa buit (una nota indica que el nom del producte pot servir de títol si en descriu el propòsit). Que cada pantalla identifiqui la seva funció de manera perceptible i anunciada es registra com a bona pràctica o dins del bloc WCAG 2.2 si l'encàrrec l'inclou.
• 11.1.4.10 Reajustament dels elements i 11.1.4.4 Canvi de mida del text: s'apliquen amb notes: la plataforma ha d'oferir l'escalat i l'app l'ha de respectar sense pèrdua de contingut o de funcionalitat; en programari amb funcionalitat tancada se substitueix per requisits del capítol 5.
• 11.4.1.1 Processament: a la v3.2.1 es manté amb una nota que el dona per complert en programari que no fa servir llenguatges de marcatge; WCAG 2.2 l'ha eliminat, i les properes versions de l'EN seguiran aquest camí. Avui no aporta troballes en apps natives.
• 11.4.1.2 Nom, funció i valor: és el criteri central per als controls personalitzats: el que no exposa nom, rol, estat i valor a l'API d'accessibilitat falla aquí.
• 11.4.1.3 Missatges d'estat: anuncis sense canvi de focus (live regions, notificacions d'accessibilitat).
• 11.1.2.x Multimèdia: igual que al web; a més, per al vídeo distribuït amb l'app, s'apliquen els requisits de reproducció del capítol 7 (subtítols i audiodescripció al reproductor).

11.5: interoperabilitat amb tecnologies de suport

Aquesta clàusula és la que diferencia una auditoria de programari d'una de web. Exigeix que el programari, o bé faci servir els serveis d'accessibilitat de la plataforma (11.5.2.1, 11.5.2.2), o bé exposi per si mateix tota la informació. Els requisits 11.5.2.5 a 11.5.2.17 descriuen què ha de ser accessible per a una tecnologia de suport:

• 11.5.2.5 Informació d'objecte: rol, estat(s), límits, nom i descripció de cada element de la interfície.
• 11.5.2.6 Fila, columna i capçaleres en taules de dades.
• 11.5.2.7 Valors: valor actual, mínim i màxim dels controls ajustables.
• 11.5.2.8 Relacions d'etiqueta: l'associació entre un control i la seva etiqueta.
• 11.5.2.9 Relacions pare-fill en la jerarquia d'elements.
• 11.5.2.10 Text: contingut, atributs i límits del text.
• 11.5.2.11 i 11.5.2.12 Accions disponibles i la seva execució per part de la tecnologia de suport (equival a exposar accions personalitzades).
• 11.5.2.13 i 11.5.2.14 Seguiment i modificació del focus i de la selecció.
• 11.5.2.15 a 11.5.2.17 Notificació de canvis d'estat, propietats, valors i text.

En una app que fa servir components estàndard d'UIKit/SwiftUI o Material aquests requisits es compleixen per herència. Les troballes apareixen en controls personalitzats, en vistes dibuixades (gràfics, calendaris, mapes) i en motors que pinten els seus propis píxels (Flutter, jocs). Un auditor documenta l'11.5 inspeccionant l'arbre d'accessibilitat amb les eines de la plataforma (lliçó següent).

11.6 i 11.7: documentació, no interferència i preferències

L'11.6.2 exigeix que l'app no interfereixi amb les funcions d'accessibilitat de la plataforma: bloquejar TalkBack o interceptar els gestos de VoiceOver són incompliments directes, i impedir l'escalat de text també ho pot ser (a més de fallar els criteris WCAG corresponents). L'11.7 exigeix respectar les preferències de la plataforma (color, contrast, tipus i mida de lletra i cursor de focus): una app amb «tema propi» que ignora els ajustos de color i la mida de lletra del sistema pot fallar l'11.7 encara que el seu contrast intern sigui correcte. El capítol 12 afegeix que la documentació descrigui les funcions d'accessibilitat (12.1.1) i que el suport les atengui (12.2): fitxa de la botiga, ajuda i canal de contacte.

Com encaixa amb WCAG2ICT

WCAG2ICT és la font de les notes interpretatives de l'EN: «pàgina web» passa a «programari», «conjunt de pàgines» a «conjunt de programes», i «determinat per programari» vol dir exposat per l'API d'accessibilitat de la plataforma. Això permet reutilitzar WCAG-EM (s'obre en una finestra nova) amb ajustos: la mostra és de pantalles i fluxos, i les tecnologies compatibles són les versions d'iOS/Android i les tecnologies de suport del sistema declarades a l'abast.

Abast: el que cal fixar abans d'avaluar

Abans d'avaluar, l'abast ha de fixar plataformes i versions (com a mínim les dues últimes versions principals d'iOS i Android que admeti l'app), dispositius, tecnologies de suport (VoiceOver, TalkBack, zoom, control per veu, control per commutadors, teclat extern, escalat màxim de text), versió de l'app i entorn, i la mostra: pantalles d'entrada, pantalles amb cada tipus de component, processos complets principals i una mostra aleatòria. La lliçó següent converteix aquest abast en un pla amb inventari, mostra i matriu de cobertura, i la de protocol manual detalla com executar-lo.

Resum

• El capítol 11 de l'EN 301 549 és la referència per a apps natives: criteris WCAG adaptats (11.1-11.4), interoperabilitat amb tecnologies de suport (11.5), no interferència i documentació (11.6), preferències de l'usuari (11.7).
• Evitar blocs, Pàgina titulada, Múltiples vies, Navegació coherent i Identificació coherent són buits en programari; 11.4.1.2 Nom, funció i valor és el criteri central per als controls personalitzats.
• L'11.5.2.x detalla què ha d'exposar cada element: rol, estat, nom, valor, relacions, accions i notificacions.
• WCAG2ICT aporta les substitucions terminològiques i permet adaptar WCAG-EM: mostra de pantalles i fluxos, versions i tecnologies de suport declarades.
• L'abast fixa plataformes, versions, dispositius, tecnologies de suport i mostra abans de començar.