Accessibilità nello sviluppo mobile: definizione, standard e come implementarla

Cos'è l'accessibilità?

Accessibility (abbreviato a11y — lettera a + 11 lettere + y) è la proprietà di un prodotto di essere utilizzabile da persone con disabilità. Nel contesto delle applicazioni mobili, ciò significa: supporto per screen reader (VoiceOver, TalkBack), dimensione del testo adeguata, contrasto elevato, ordine di focus corretto per la navigazione tramite tastiera e assenza di elementi animati che causano vertigini.

L'inclusività non è solo un obbligo etico ma anche legale. Molti paesi hanno leggi sull'accessibilità digitale: ADA (USA), Sezione 508, European Accessibility Act (UE, obbligatorio per le app dal 2025). Secondo il Business Disability Forum, le aziende che investono in accessibilità aumentano il loro pubblico del 15–20% e riducono i rischi legali.

In IT Sectr, verifichiamo l'accessibilità in ogni fase dello sviluppo. La nostra esperienza mostra: correggere i problemi di accessibilità in fase di progettazione costa 10 volte meno che dopo il rilascio. L'accessibilità non è una funzionalità, ma un requisito di base per un'applicazione moderna.

iOS: VoiceOver, Accessibility Label, Trait

L'ecosistema Apple offre potenti strumenti di accessibilità. VoiceOver è uno screen reader integrato che vocalizza tutto ciò che accade sullo schermo. L'utente controlla il dispositivo con gesti: scorrere a destra — elemento successivo, scorrere a sinistra — elemento precedente, doppio tocco — attivazione.

Accessibility Label è il testo che VoiceOver legge per un elemento. Per impostazione predefinita, iOS utilizza il testo del pulsante o l'etichetta, ma per icone ed elementi grafici è necessario impostare l'etichetta esplicitamente. Accessibility Trait è una proprietà che descrive il tipo di elemento: button (pulsante), header (intestazione), link (collegamento), image (immagine). I trait corretti aiutano l'utente a capire come interagire con un elemento.

VoiceOver e Accessibility Label

VoiceOver supporta oltre 40 lingue e funziona su tutti i dispositivi Apple. Per lo sviluppatore, la cosa principale è impostare accessibilityLabel e accessibilityTraits corretti per ogni elemento dell'interfaccia. Se un elemento non deve essere accessibile (immagine decorativa), impostare isAccessibilityElement = false.

// Swift — configurazione dell'accessibilità per un pulsante
let shareButton = UIButton()
shareButton.setImage(UIImage(named: "share-icon"), for: .normal)
shareButton.accessibilityLabel = "Condividi questo articolo"
shareButton.accessibilityHint = "Apre una finestra per scegliere un metodo di invio"
shareButton.accessibilityTraits = .button

// SwiftUI — ancora più semplice
struct ShareButtonView: View {
    var body: some View {
        Button(action: share) {
            Image(systemName: "square.and.arrow.up")
        }
        .accessibilityLabel("Condividi")
        .accessibilityHint("Apre il menu di condivisione")
    }
}

Il codice mostra la configurazione dell'accessibilità per un pulsante senza testo (solo icona). AccessibilityLabel è ciò che l'utente sentirà. AccessibilityHint è un suggerimento aggiuntivo sul risultato dell'azione. Non usare frasi come «pulsante per» nell'etichetta — Trait indica già che si tratta di un pulsante.

Android: TalkBack, Content Description

TalkBack è lo screen reader di Google per Android, parte del pacchetto Android Accessibility Suite. Come VoiceOver, vocalizza gli elementi dell'interfaccia ed è controllato da gesti. TalkBack supporta oltre 100 lingue e funziona su tutti i dispositivi con Google Play Services.

Content Description è l'equivalente di accessibilityLabel su Android. Viene impostato tramite l'attributo android:contentDescription in XML o tramite il metodo setContentDescription() nel codice. Per elementi non focalizzabili (ImageView decorativo), utilizzare importantForAccessibility="no".

TalkBack e Focus Order

Focus Order (ordine di focus) è la sequenza in cui TalkBack si sposta tra gli elementi durante lo scorrimento. Per impostazione predefinita, Android utilizza l'ordine degli elementi nel layout, ma può essere modificato tramite gli attributi accessibilityTraversalBefore e accessibilityTraversalAfter. Questo è importante per schermate complesse con componenti personalizzati.

In IT Sectr, verifichiamo il Focus Order su ogni schermata. Gli errori di ordine di focus sono tra i problemi di accessibilità più comuni. Ad esempio, se dopo un'intestazione l'utente va ai commenti invece del testo dell'articolo — questo è un bug di accessibilità.

WCAG e standard

WCAG (Web Content Accessibility Guidelines) è uno standard internazionale di accessibilità sviluppato dal W3C. La versione attuale è WCAG 2.2 (2023). Lo standard si divide in 4 principi: Perceivable (percepibile), Operable (utilizzabile), Understandable (comprensibile), Robust (robusto) — acronimo POUR.

Livelli WCAG: A (minimo), AA (medio, obbligatorio per legge nell'UE), AAA (massimo). Per le applicazioni mobili, il livello AA è sufficiente: contrasto del testo di almeno 4.5:1, supporto per screen reader, dimensione minima del target di 44x44 pixel, sottotitoli per i video.

Livelli WCAG

Livello A — requisiti di base: alternative testuali per le immagini, controllo tramite tastiera, contrasto di almeno 3:1. Livello AA — medio: contrasto 4.5:1, supporto per lo zoom fino al 200%, intestazioni ed etichette corrette. Livello AAA — elevato: contrasto 7:1, lingua dei segni per i video, controllo vocale completo. Nella pratica, la maggior parte delle aziende punta ad AA.

Tabella 2. Confronto tra le API di accessibilità iOS e Android. Nonostante i nomi diversi, i concetti sono identici: etichetta, tipo, ordine di focus e supporto per l'adattamento del testo.

Test di accessibilità

I test di accessibilità consistono nel verificare che un'applicazione sia conforme agli standard WCAG e funzioni correttamente con gli screen reader. Il set minimo di test: attivare VoiceOver/TalkBack e navigare attraverso tutte le schermate dell'applicazione. Ascoltare per verificare che tutti gli elementi vengano annunciati, l'ordine di focus sia logico e gli elementi inappropriati (decorativi) vengano ignorati.

Strumenti automatizzati: Xcode Accessibility Inspector (audit in Xcode per iOS), Android Accessibility Scanner (scansiona lo schermo e trova problemi), Axe DevTools, WAVE. Questi strumenti verificano contrasto, dimensione del target, presenza di etichette e altri parametri.

In IT Sectr, eseguiamo una revisione dell'accessibilità prima di ogni rilascio. Il processo include: audit automatizzato (Accessibility Inspector), test manuali con VoiceOver e TalkBack, verifica del contrasto e della scala del testo. Registriamo i problemi in Jira e li assegniamo a uno sprint. Questo ci consente di mantenere il livello AA WCAG su tutti i progetti.