Accessibilità — fondamenti, VoiceOver e TalkBack per utenti non vedenti

Cos'è l'Accessibilità (a11y) nelle app mobili?

Accessibility (abbreviato a11y — 11 lettere tra «a» e «y») — la pratica di sviluppare applicazioni utilizzabili da persone con disabilità visive, uditive, motorie e cognitive. Nello sviluppo mobile, l'accessibilità copre quattro scenari principali: utenti non vedenti (lettori di schermo), utenti ipovedenti (ridimensionamento, contrasto), utenti sordi e con problemi di udito (sottotitoli, alternative visive al suono) e utenti con mobilità ridotta (controllo vocale, Switch Control, grandi aree tattili).

Requisiti legali — in molti paesi, l'accessibilità è obbligatoria per legge. USA: Section 508 e ADA. UE: European Accessibility Act (2025). Regno Unito: Equality Act 2010. Senza supporto all'accessibilità, un'app può diventare bersaglio di azioni legali — negli USA nel 2023 sono state presentate oltre 4.000 cause relative a prodotti digitali inaccessibili. Apple e Google controllano l'accessibilità durante la moderazione delle app: le App Store Review Guidelines (4.2) e Google Play Store richiedono un supporto minimo all'accessibilità.

Argomento commerciale — l'accessibilità amplia il tuo pubblico. Secondo Return on Disability (2021), le persone con disabilità controllano 13 trilioni di dollari di reddito disponibile all'anno. Le app accessibili si posizionano meglio nei motori di ricerca (HTML semantico, testi alternativi), hanno valutazioni utente più alte e meno recensioni su problemi di UX. In IT Sectr, includiamo l'accessibilità nella definizione di fatto di tutti i progetti — è uno standard di qualità, non un miglioramento opzionale.

Accessibilità in iOS: VoiceOver e UIAccessibility

VoiceOver — il lettore di schermo Apple integrato in iOS, iPadOS e macOS. L'utente trascina il dito sullo schermo, VoiceOver legge il nome dell'elemento sotto il dito. Il doppio tocco attiva l'elemento. VoiceOver supporta oltre 40 gesti: scorrimento a tre dita (scorrimento), doppio tocco a due dita (fermarsi), gesto a Z (indietro). Gli sviluppatori controllano cosa e come VoiceOver legge attraverso il protocollo UIAccessibility e le proprietà accessibilityLabel, accessibilityTraits e accessibilityHint.

class CustomButton: UIButton {

    override var isAccessibilityElement: Bool {
        get { return true }
        set {}
    }

    // sovrascrivere accessibilityLabel
    override var accessibilityLabel: String? {
        get { return "Pulsante di invio del modulo" }
        set {}
    }

    // sovrascrivere accessibilityHint
    override var accessibilityHint: String? {
        get { return "Tocca due volte per inviare i dati" }
        set {}
    }

    // sovrascrivere accessibilityTraits
    override var accessibilityTraits: UIAccessibilityTraits {
        get { return .button }
        set {}
    }
}

// Dynamic Type — ridimensionamento del testo
titleLabel.font = UIFontMetrics.default.scaledFont(
    for: UIFont.systemFont(ofSize: 16)
)
titleLabel.adjustsFontForContentSizeCategory = true

Tipografia dinamica — Dynamic Type in iOS consente all'utente di scegliere la dimensione del testo (da XS a XXXL). Gli sviluppatori usano UIFontMetrics.scaledFont per il ridimensionamento automatico. Il testo deve essere visualizzato correttamente a tutte le dimensioni: le righe non devono essere tagliate, i pulsanti devono crescere proporzionalmente al testo. UITableView aggiorna automaticamente l'altezza delle celle quando la dimensione del testo cambia. Ignorare Dynamic Type significa rendere l'app inaccessibile agli utenti ipovedenti.

Accessibilità in SwiftUI

SwiftUI fornisce modificatori di accessibilità: .accessibilityLabel(), .accessibilityHint(), .accessibilityAddTraits(), .accessibilitySortPriority(). Per impostazione predefinita, tutti gli elementi standard di SwiftUI (Text, Button, Image) sono già elementi di accessibilità con etichette automatiche. Per viste personalizzate, usa .accessibilityElement(children: .combine) per combinare gli elementi figli in uno solo. SwiftUI supporta automaticamente Dynamic Type e VoiceOver.

VStack {
    Image(systemName: "trash")
        .accessibilityLabel(Text("Elimina elemento"))
    Text("Cestino")
        .font(.body)
}
.accessibilityElement(children: .combine)
.accessibilityAddTraits(.isButton)
.accessibilityHint(Text("Elimina definitivamente l'elemento selezionato"))

Accessibilità in Android: TalkBack e contentDescription

TalkBack — il lettore di schermo Google, preinstallato sulla maggior parte dei dispositivi Android (disponibile su Google Play per tutte le versioni Android 5+). TalkBack usa gli stessi gesti di VoiceOver: scorrere per navigare, doppio tocco per attivare. Gli sviluppatori impostano le descrizioni degli elementi tramite l'attributo android:contentDescription in XML o tramite setContentDescription() nel codice. Per ImageView, contentDescription è obbligatorio — senza di esso, TalkBack dirà «non etichettato» o leggerà il nome del file.

// XML: contentDescription per ImageView
<ImageView
    android:id="@+id/iconDelete"
    android:src="@drawable/ic_delete"
    android:contentDescription="@string/delete_button_desc"
    android:focusable="true"
    android:clickable="true" />

// Kotlin: assegnazione programmatica
iconDelete.contentDescription = getString(R.string.delete_button_desc)

// Accessibility Delegate (personalizzato)
iconDelete.accessibilityDelegate = object : View.AccessibilityDelegate() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View, info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.text = "Pulsante elimina"
        info.contentDescription = "Elimina elemento selezionato"
        info.className = Button::class.java.name
    }
}

// Live Regions per aggiornamenti dinamici
textView.accessibilityLiveRegion = View.ACCESSIBILITY_LIVE_REGION_POLITE

Live Regions — il meccanismo di Android per notificare a TalkBack i cambiamenti di contenuto senza focus. L'attributo android:accessibilityLiveRegion accetta tre valori: none (nessuna notifica), polite (annunciare dopo il corrente), assertive (annunciare immediatamente). Usa polite per aggiornamenti sullo stato di caricamento, assertive per errori critici. L'uso eccessivo di assertive creerà caos per l'utente — TalkBack interromperà costantemente l'azione corrente.

Accessibility Scanner

Accessibility Scanner — un'app gratuita di Google per testare l'accessibilità delle app Android senza accesso al codice sorgente. Lo scanner verifica: contrasto del testo, dimensione delle aree tattili (minimo 48×48dp secondo le Linee guida per l'accessibilità Android), contentDescription per ImageView e corretta gerarchia degli elementi. Per test automatizzati, usa AccessibilityChecks da Espresso — si integrano in CI/CD e verificano l'accessibilità a ogni build.

WCAG 2.1: contrasto, dimensione e aree tattili

WCAG 2.1 (Web Content Accessibility Guidelines) — lo standard internazionale di accessibilità sviluppato dal W3C. La versione 2.1 (2018) include 13 criteri aggiuntivi per le applicazioni mobili. Livelli di conformità: A (minimo), AA (obbligatorio per la maggior parte delle organizzazioni), AAA (massimo). Apple e Google raccomandano il livello AA come minimo per pubblicare app. WCAG 2.2 è stato rilasciato nel 2023 con perfezionamenti per focus e input.

Criteri chiave per lo sviluppo mobile: contrasto del testo di almeno 4.5:1 (AA) o 7:1 (AAA), dimensione delle aree tattili di almeno 44×44pt (iOS) o 48×48dp (Android), supporto per orientamento orizzontale e verticale senza perdita di funzionalità, possibilità di disattivare le animazioni (prefers-reduced-motion), sottotitoli per contenuti multimediali e compatibilità con il controllo vocale (Voice Control su iOS, Voice Access su Android).

Strumenti di verifica del contrasto — Colour Contrast Analyser (TPGI), WebAIM Contrast Checker, Stark (Figma), Accessibility Inspector (Xcode). In IT Sectr, verifichiamo il contrasto in fase di progettazione (Figma + Stark) e di nuovo in fase di sviluppo (Accessibility Inspector / Accessibility Scanner). Il requisito minimo è 4.5:1 per tutto il testo inferiore a 18pt (14pt grassetto). Logo ed elementi decorativi non necessitano di contrasto.

Test di accessibilità: strumenti e checklist

Test iOS — Accessibility Inspector in Xcode (Xcode → Open Developer Tool → Accessibility Inspector) verifica etichetta, traits e suggerimento per ogni elemento. VoiceOver può essere attivato in Impostazioni o tramite la Scorciatoia di accessibilità (triplo clic sul pulsante). Per test automatizzati, usa XCUITest con XCTAssertTrue(app.staticTexts["etichetta"].isAccessibilityElement). Apple raccomanda di testare tutti gli schermi dell'app con VoiceOver attivato.

Test Android — Accessibility Scanner (Play Store) verifica contrasto, dimensione delle aree tattili e contentDescription. Per automazione: Espresso AccessibilityChecks (import: androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.5.1'). Google raccomanda la seguente checklist: ogni ImageView ha una contentDescription, le aree tattili sono almeno 48×48dp, il testo si ridimensiona al 200% senza tagli e tutti gli elementi sono raggiungibili tramite scorrimento di TalkBack.

Checklist IT Sectr — prima del rilascio, verifichiamo: (1) VoiceOver/TalkBack legge correttamente tutti gli elementi, (2) il testo si ridimensiona alla massima dimensione senza perdita di funzionalità, (3) tutti gli ImageView hanno contentDescription, (4) contrasto del testo ≥4.5:1 in tutti i temi, (5) aree tattili ≥44pt/48dp, (6) nessun menu contestuale accessibile solo tramite pressione prolungata, (7) supporto per Reduce Motion / Remove Animations nelle impostazioni di sistema. Questa checklist fa parte della definizione di fatto di ogni sprint.