Accessibilità delle app mobili: requisiti WCAG 2.2 per iOS e Android

Oltre il 72% degli adulti con disabilità possiede uno smartphone e, secondo un sondaggio, circa l’86% delle persone che usano screen reader si affida a un dispositivo mobile — una quota più alta rispetto a chi usa desktop o laptop. Eppure le stesse organizzazioni che sottopongono i loro siti web ad audit scrupolosi spesso hanno app mobile che non sono mai state testate rispetto a un singolo criterio di accessibilità. Questo divario si sta chiudendo rapidamente, spinto dall’evoluzione della normativa, dall’aumento del contenzioso e — soprattutto — dalle linee guida del W3C che mappano esplicitamente WCAG 2.2 sulle applicazioni native iOS e Android.

Perché WCAG 2.2 si applica alla tua app mobile

Esiste un mito persistente secondo cui WCAG sarebbe uno standard solo per il web. Non è così. Il W3C non ha linee guida separate per l’accessibilità mobile — l’accessibilità mobile è invece affrontata all’interno dell’attuale framework WCAG, e il Mobile Accessibility Task Force (MATF) del W3C ha prodotto una guida dedicata intitolata Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile) che mappa ogni criterio di successo di livello A e AA sulle app mobili native, sulle web app mobili e sulle app ibride.

L’implicazione pratica è significativa. Quando leggi un criterio di successo WCAG che fa riferimento a una “pagina web”, il documento WCAG2Mobile sostituisce quel termine con “schermo” o “vista”. Quando un criterio parla di “user agent”, si riferisce al sistema operativo mobile. I quattro principi POUR — Perceivable (Percepibile), Operable (Utilizzabile), Understandable (Comprensibile), Robust (Robusto) — si traducono direttamente nel modo in cui un utente interagisce con una view SwiftUI in iOS o con un layout Jetpack Compose su Android.

Dal punto di vista legale, la pressione non è più teorica. Ai sensi del Titolo II dell’ADA, i regolamenti aggiornati del DOJ pubblicati nell’aprile 2024 richiedono esplicitamente che governi statali e locali rendano accessibili le loro applicazioni mobili secondo WCAG 2.1 AA. Le organizzazioni sanitarie che accettano Medicare o Medicaid affrontano requisiti simili ai sensi delle regole HHS finalizzate nel maggio 2024. E sebbene le cause legali nel settore privato che riguardano app mobili siano ancora meno frequenti rispetto a quelle sui siti web, almeno un ricorrente ad alto volume ha preso di mira specificamente le applicazioni mobili per mancanza di accesso equo ai sensi dell’ADA, con una tendenza che dovrebbe accelerare man mano che si avvicinano le scadenze di conformità del Titolo II nel 2026.

L’European Accessibility Act (EAA), entrato in vigore il 28 giugno 2025 e che si basa sulla EN 301 549 come standard tecnico presuntivo, richiede anch’esso la conformità a WCAG 2.2 per prodotti e servizi digitali, incluse le app mobili vendute o offerte nei mercati UE. Per qualsiasi organizzazione con una base utenti globale, WCAG 2.2 sul mobile non è un’aspirazione futura — è un obbligo attuale.

Cosa è cambiato in WCAG 2.2 che conta di più per il mobile

WCAG 2.2, pubblicato come W3C Recommendation nell’ottobre 2023, aggiunge nove nuovi criteri di successo e rimuove il ormai obsoleto 4.1.1 Parsing. È pienamente retrocompatibile: la conformità a 2.2 implica la conformità a 2.1 e 2.0. Diversi nuovi criteri sono stati scritti con i pattern di interazione mobile esplicitamente in mente, e anche quelli formulati attorno all’uso della tastiera hanno analoghi diretti nelle tecnologie assistive per iOS e Android.

Vale la pena comprenderne la genealogia. Dopo il 2018, il Mobile Accessibility Task Force ha fatto sì che le considerazioni mobile influenzassero sia WCAG 2.1 che 2.2. Criteri come 1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 2.5.1 Pointer Gestures (A), 2.5.4 Motion Actuation (A) e i nuovi 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA) e 3.3.7 Redundant Entry (A) riflettono tutti specifici pattern di usabilità mobile identificati attraverso test reali con utenti con disabilità su smartphone e tablet.

I nove nuovi criteri di successo introdotti in WCAG 2.2 prendono di mira barriere specifiche che gli utenti reali incontrano: flussi di login che penalizzano chiunque abbia problemi di memoria, interfacce che richiedono mani ferme per tocchi precisi, funzioni di aiuto nascoste in punti diversi di ogni schermo e indicatori di focus che scompaiono dietro barre di navigazione fisse. Ogni criterio colma una lacuna concreta — e quasi tutti hanno un’applicazione diretta sul mobile.

I nuovi criteri WCAG 2.2 e come si applicano a iOS e Android

2.5.8 Target Size Minimum (Livello AA)

Questo è probabilmente il nuovo criterio più impattante per i team mobile. Richiede che i target interattivi — pulsanti, link, campi modulo, checkbox, toggle — abbiano una dimensione minima di 24 × 24 pixel CSS, oppure che esista un offset di spaziatura di 24 pixel tra target adiacenti se il target stesso è più piccolo. La motivazione è semplice: utenti con tremori alle mani, morbo di Parkinson o destrezza limitata trovano davvero impossibile colpire in modo affidabile un’icona pulsante da 16 pixel, e anche gli utenti senza disabilità commettono molti più errori su target piccoli.

Per lo sviluppo mobile nativo, il minimo 24 × 24 di WCAG 2.2 è in realtà un pavimento, non un tetto. Le Human Interface Guidelines di Apple raccomandano un target di tocco minimo di 44 × 44 punti su iOS e iPadOS. Il Material Design di Google raccomanda 48 × 48 pixel indipendenti dalla densità (dp) su Android. Se la tua app rispetta le linee guida della piattaforma Apple o Google, superi già il minimo WCAG 2.2 — ma molte app non lo fanno. Quei minuscoli pulsanti di chiusura sui fogli modali, le checkbox sottilissime nelle schermate delle impostazioni e le azioni nella toolbar composte solo da icone che misurano 20 × 20 dp sono tutte violazioni in attesa di essere evidenziate in un audit.

Nota pratica: il requisito WCAG riguarda l’area interattiva cliccabile, non la dimensione visiva dell’icona. Un’icona da 16 punti racchiusa in 14 punti di padding su ogni lato ha un target di tocco effettivo di 44 × 44 punti. Questo significa che gli sviluppatori possono soddisfare il criterio senza ingrandire visivamente gli elementi — ma devono impostare deliberatamente quel padding, non fare affidamento sul sistema perché lo faccia automaticamente.

2.5.7 Dragging Movements (Livello AA)

Questo criterio richiede che qualsiasi funzionalità implementata tramite un gesto di trascinamento — slider, riordinamento drag-and-drop, pull-to-refresh, scrub di un carosello — sia ottenibile anche tramite un’azione a singolo puntatore che non richieda il trascinamento. Su iOS e Android, le tecnologie assistive della piattaforma gestiscono alcuni gesti in modo diverso, ma l’app stessa deve esporre alternative non basate sul drag per qualsiasi comportamento di trascinamento personalizzato che implementa.

In pratica, questo significa che una lista riordinabile tramite drag deve offrire un’alternativa come un pulsante stepper “su/giù”. Uno slider di intervallo personalizzato che risponde solo al gesto di trascinamento deve anche rispondere ai tap su punti specifici o fornire pulsanti di incremento/decremento. Il criterio non si applica se il sistema operativo sottostante o la tecnologia assistiva fornisce automaticamente l’alternativa, ma gli sviluppatori dovrebbero testarlo esplicitamente invece di presumere che venga sempre gestito per loro.

2.4.11 Focus Not Obscured — Minimum (Livello AA) e 2.4.12 (Enhanced, Livello AAA)

Questi criteri affrontano un pattern estremamente comune sia nelle app web che in quelle mobile native: l’elemento con focus che viene parzialmente o completamente nascosto da UI fisse — una barra di navigazione inferiore persistente, un floating action button, una toolbar superiore che si sovrappone all’area di scorrimento. Il criterio minimo (Livello AA) richiede che, quando un componente riceve il focus, almeno una sua parte rimanga visibile. La versione avanzata (Livello AAA) richiede che l’intero componente con focus sia visibile.

Per il mobile nativo, il “focus da tastiera” è interpretato in senso ampio per includere l’anello di focus usato da Switch Control o Switch Access, Full Keyboard Access (iOS 15+), e Voice Control/Access. Un’app in cui l’elemento con focus scivola sotto una barra di navigazione inferiore durante una scansione di Switch Control non rispetta questo criterio, anche se non è coinvolta alcuna tastiera fisica. La UI dell’app dovrebbe evitare di oscurare i controlli con focus con overlay creati dall’autore, barre fisse o superfici transitorie.

2.4.13 Focus Appearance (Livello AA)

Questo criterio stabilisce requisiti minimi per le caratteristiche visive dell’indicatore di focus: deve avere un’area minima equivalente al perimetro del componente × 2 pixel CSS e un rapporto di contrasto di almeno 3:1 rispetto ai colori adiacenti. Sulle piattaforme mobile native, l’anello di focus per VoiceOver e TalkBack è controllato dal sistema operativo e gli sviluppatori non possono modificarne l’aspetto — il che significa che in genere viene concessa un’eccezione per questo specifico criterio. Tuttavia, lo stile dell’app non deve ridurre attivamente la visibilità del focus, ad esempio sovrapponendo uno scrim traslucido ai controlli con focus.

3.3.8 Accessible Authentication — Minimum (Livello A)

Questo criterio rappresenta un passo importante per l’accessibilità cognitiva. Richiede che i processi di autenticazione non si basino esclusivamente su un test di funzione cognitiva — cioè l’utente non deve essere obbligato a memorizzare una password, risolvere un puzzle o trascrivere un CAPTCHA — a meno che l’app non fornisca un’alternativa accessibile. Su iOS, questo significa supportare il Keychain di Apple e Sign in with Apple per consentire agli utenti di autenticarsi senza memorizzare le credenziali. Su Android, significa supportare il framework Autofill di Google, l’autenticazione biometrica e non bloccare l’uso di password manager di terze parti.

Più concretamente: se la tua app blocca l’azione di incolla nei campi password, è probabilmente non conforme al 3.3.8. Se il tuo flusso di autenticazione a due fattori richiede che l’utente digiti manualmente un codice OTP da una notifica senza fornire un meccanismo di copia-incolla, introduce un carico cognitivo non necessario. L’app Messaggi di Android fornisce già un pulsante “copia codice” nelle notifiche OTP proprio per questo motivo — allineando il comportamento della piattaforma con l’intento del criterio.

Insight chiave: Supportare l’autenticazione biometrica (Face ID, Touch ID, Android Biometric API) non è solo un miglioramento della UX — è un meccanismo di conformità a WCAG 2.2 per utenti con disabilità cognitive che non possono ricordare in modo affidabile le password.

3.3.7 Redundant Entry (Livello A)

Se un flusso multi-schermo nella tua app — checkout, onboarding, un modulo di anamnesi sanitaria — chiede all’utente di inserire le stesse informazioni più di una volta, devi o precompilare automaticamente il valore inserito in precedenza o offrire un modo per selezionarlo da input precedenti. Questo criterio è direttamente applicabile alle app mobile native. Il classico caso di fallimento è un modulo di indirizzo di spedizione che successivamente chiede l’indirizzo di fatturazione senza l’opzione “uguale a indirizzo di spedizione”, costringendo utenti con disabilità motorie o cognitive a digitare più volte lo stesso testo.

3.2.6 Consistent Help (Livello A)

Se la tua app fornisce un meccanismo di aiuto — un pulsante di supporto chat, un’icona di help, un link “contattaci” — deve apparire in una posizione coerente su tutte le schermate dell’app. Gli utenti con disabilità cognitive si affidano al posizionamento prevedibile dei meccanismi di navigazione e supporto. Posizionare il pulsante di aiuto nell’header su alcune schermate e nella tab bar su altre, o nasconderlo dentro un menu impostazioni in certi flussi, viola questo criterio.

Criteri WCAG 2.1 che restano critici per il mobile

I nuovi criteri WCAG 2.2 attirano la maggior parte dell’attenzione, ma diversi requisiti WCAG 2.1 introdotti specificamente pensando al mobile vengono ancora regolarmente violati nelle app native, e i responsabili della conformità non dovrebbero trascurarli durante gli audit.

1.3.4 Orientation (AA) vieta di bloccare un’app in sola modalità verticale o orizzontale a meno che quell’orientamento non sia essenziale per la funzione del contenuto. Molte app si bloccano in verticale durante i flussi di onboarding o nei video player in-app senza giustificazione. Questo colpisce in modo sproporzionato gli utenti con dispositivi montati su sedia a rotelle che non possono essere ruotati. 1.4.10 Reflow (AA) richiede che il contenuto possa essere presentato senza scorrimento orizzontale quando visualizzato a 320 pixel CSS di larghezza (equivalente a uno zoom del 400%), il che in termini mobile significa supportare Dynamic Type e la scalatura della dimensione del testo di sistema senza rompere il layout o troncare il contenuto.

2.5.1 Pointer Gestures (A) richiede che qualsiasi funzionalità che utilizza gesti multipunto o basati su traiettoria — un pinch-to-zoom, uno swipe a due dita — abbia anche un’alternativa a singolo puntatore. 2.5.4 Motion Actuation (A) richiede che le funzionalità attivate scuotendo o inclinando il dispositivo possano essere operate anche tramite controlli UI standard e che gli utenti possano disabilitare i trigger basati sul movimento per evitare attivazioni accidentali.

Per la presentazione visiva, 1.4.3 Contrast Minimum (AA) richiede un rapporto di almeno 4,5:1 per il testo normale e 3:1 per il testo grande. Molte app falliscono ancora qui perché il testo segnaposto nei campi di input, le etichette dei pulsanti disabilitati e il testo su sfondi fotografici non raggiungono il minimo. Gli sviluppatori dovrebbero assicurarsi che tutti i testi, i controlli e i contenuti funzionino con Dynamic Type, Bold Text, dark mode e le opzioni di contrasto a livello di sistema sia su iOS che su Android.

Linee guida di implementazione specifiche per piattaforma

iOS e SwiftUI / UIKit

Apple fornisce un ampio supporto nativo per l’accessibilità tramite le API UIAccessibility e, in SwiftUI, tramite i modifier di accessibilità. Per il supporto VoiceOver, ogni elemento interattivo deve avere un’etichetta di accessibilità, un suggerimento e un valore significativi. I controlli personalizzati che non ereditano dai componenti UIKit standard devono adottare esplicitamente un tratto di accessibilità appropriato — .isButton, .isHeader, .isLink — in modo che VoiceOver li annunci correttamente. L’Accessibility Inspector di Xcode può aiutare a evidenziare etichette mancanti e incongruenze nei tratti durante lo sviluppo.

Per Dynamic Type, i font di sistema UIFont.preferredFont(forTextStyle:) in UIKit e .font(.body) in SwiftUI si adattano automaticamente alla dimensione del testo preferita dall’utente. Le dimensioni dei font codificate in punti che non usano scaledValue(for:) non rispetteranno 1.4.4 Resize Text. Per le dimensioni dei target, puoi espandere l’area cliccabile di una piccola icona usando contentEdgeInsets in UIKit o il modifier .contentShape() in SwiftUI senza cambiare la presentazione visiva dell’elemento.

// SwiftUI: espandere l’area di tap senza cambiare la dimensione visiva
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android e Jetpack Compose / Views

L’accessibilità di Android è esposta tramite l’API AccessibilityNodeInfo, che TalkBack e Switch Access utilizzano. In Jetpack Compose, il blocco Modifier.semantics consente di impostare content description, ruoli, descrizioni di stato e unire le semantiche discendenti. Per le UI basate su View, ViewCompat.setAccessibilityDelegate() permette la manipolazione programmatica delle proprietà di accessibilità su qualsiasi view.

Per le dimensioni dei target di tocco, le linee guida Material Design raccomandano un minimo di 48 × 48 dp. Se un composable o una view è visivamente più piccola, puoi usare Modifier.minimumInteractiveComponentSize() in Compose (introdotto in Material3) per imporre automaticamente un minimo di 48 dp, oppure racchiudere una view piccola in un TouchDelegate per espandere la sua area cliccabile nel sistema View legacy. Per la scalatura del testo, assicurati che tutte le dimensioni del testo siano specificate in sp (pixel indipendenti dalla scala), non in dp, così da rispettare le preferenze di dimensione del font impostate dall’utente nelle impostazioni Schermo di Android.

// Jetpack Compose: pulsante icona accessibile con dimensione minima
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // impone un minimo di 48dp
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // descritto dal genitore
    )
}

Testare la tua app rispetto a WCAG 2.2

Testare l’accessibilità mobile richiede una combinazione di strumenti automatizzati e test manuali con tecnologie assistive reali. Gli strumenti automatizzati — tra cui axe DevTools Mobile di Deque, Accessibility Scanner di Google per Android e Accessibility Inspector di Apple in Xcode — possono individuare etichette mancanti, contrasto insufficiente e target di tocco al di sotto dei minimi della piattaforma. Tuttavia, gli strumenti automatizzati rilevano solo una frazione dei problemi di accessibilità reali. I test manuali con VoiceOver su iOS e TalkBack su Android sono essenziali per verificare l’ordine di lettura corretto, etichette significative e una gestione logica del focus nei flussi complessi.

Per i criteri specifici di WCAG 2.2, i test manuali sono particolarmente importanti. Per testare 2.5.8 (Target Size), usa il tuo dito reale — non il cursore del mouse nel Simulator iOS — per provare le interazioni sui controlli piccoli. Per testare 3.3.8 (Accessible Authentication), verifica che il tuo flusso di login consenta l’incolla nei campi password, supporti i password manager (1Password, Bitwarden, keychain di sistema) e supporti l’autenticazione biometrica. Per testare 2.4.11 (Focus Not Obscured), naviga l’intera app tramite Switch Control su iOS o Switch Access su Android e conferma che nessun elemento con focus scompaia dietro una barra di navigazione, un overlay modale o un pulsante flottante.

Un piano di test di accessibilità completo dovrebbe includere test su almeno due dispositivi fisici — un iPhone e un dispositivo Android — alla dimensione del font predefinita dell’utente e alla dimensione massima del font di sistema, con VoiceOver e TalkBack attivati rispettivamente. I test solo su simulatori non rileveranno le differenze di rendering nel mondo reale e il comportamento delle tecnologie assistive.

Valuta di integrare i controlli di accessibilità nella tua pipeline CI/CD. Sia Espresso (Android) che XCUITest (iOS) supportano la scrittura di test UI automatizzati che verificano le proprietà di accessibilità — content description, tratti e stati abilitati — in modo che le regressioni vengano intercettate prima del merge del codice anziché scoperte in un audit in produzione.

Il caso legale e di business per agire ora

Oltre all’imperativo morale dell’inclusione, il caso di business per l’accessibilità mobile è concreto. Le aziende leader nell’inclusione delle persone con disabilità generano 1,6 volte più ricavi e 2,6 volte più reddito netto rispetto ai concorrenti del settore. Le persone con disabilità negli Stati Uniti detengono quasi mezzo trilione di dollari di reddito disponibile. E dato che il 69% dei consumatori online con disabilità abbandona app e siti web che trova difficili da usare, ogni barriera di accessibilità è una conversione che non avviene mai.

Il rischio legale è in aumento. Le cause legali contro aziende con carenze di accessibilità digitale continuano a crescere anno dopo anno. L’adozione da parte del DOJ di WCAG come standard tecnico per la conformità all’ADA, le scadenze di applicazione del Titolo II nel 2026 e l’entrata in vigore dell’EAA nel giugno 2025 creano collettivamente un requisito di conformità multi-giurisdizionale che ora comprende esplicitamente le applicazioni mobile native. Un audit WCAG 2.1 precedente non dimostra automaticamente la conformità a WCAG 2.2 — i flussi di autenticazione, i campi modulo, i componenti interattivi e la gestione del focus devono tutti essere rivalutati rispetto ai nove nuovi criteri di successo.

Fondamentalmente, l’accessibilità nel mobile non è una funzionalità che si possa aggiungere a basso costo dopo il lancio. Affrontare le non conformità WCAG in un’app già distribuita significa aggiornare asset, ricostruire componenti, rivedere layout, ritestare flussi e potenzialmente rifattorizzare i sistemi di autenticazione. I team che integrano la conformità a WCAG 2.2 nei loro design system e nelle librerie di componenti fin dall’inizio — imponendo dimensioni minime dei target di tocco, token di contrasto, ruoli semantici e pattern di autenticazione a livello di componente — pagano una frazione del costo rispetto alla correzione di un’app inaccessibile dopo il lancio.

Key Takeaways

• WCAG 2.2 si applica alle app native iOS e Android. Le linee guida WCAG2Mobile del W3C mappano ogni criterio di successo di livello A e AA su schermate e viste mobile, il che significa che la tua app nativa è nel perimetro — non solo il tuo sito mobile.
• La dimensione dei target di tocco è il nuovo errore più comune negli audit mobile. Il minimo 24 × 24 di WCAG 2.2 è il pavimento; Apple raccomanda 44 × 44 pt e Google raccomanda 48 × 48 dp. Espandi le aree cliccabili con padding e API native della piattaforma, non ingrandendo visivamente le icone.
• Bloccare l’incolla nei campi password probabilmente viola 3.3.8 Accessible Authentication. Supporta keychain di sistema, password manager, biometria e auto-fill degli OTP per soddisfare i requisiti di accessibilità cognitiva dei flussi di login su entrambe le piattaforme.
• I test manuali con VoiceOver e TalkBack non sono negoziabili. Gli strumenti automatizzati rilevano solo una frazione dei problemi di accessibilità. Esegui test su dispositivi fisici alla dimensione massima del font, con le tecnologie assistive attivate, lungo ogni percorso utente critico.
• Integra l’accessibilità nel tuo design system ora, non dopo il lancio. Correggere app inaccessibili dopo il lancio è molto più costoso che imporre standard di componenti accessibili fin dal primo giorno. Con le scadenze di applicazione di DOJ, HHS ed EAA tra il 2025 e il 2026, la finestra per un lavoro di conformità a basso costo si sta chiudendo.