Screen Reader: cos'è, tipi di lettori dello schermo e principio di funzionamento

Cos'è uno Screen Reader?

Screen Reader (lettore dello schermo) è una tecnologia assistiva (Assistive Technology, AT) che interpreta l'interfaccia utente grafica e la presenta in forma non visiva: attraverso sintesi vocale o un display Braille tattile. I lettori dello schermo sono il principale mezzo di accesso a computer e dispositivi mobili per persone con perdita totale o parziale della vista.

I primi lettori dello schermo sono apparsi alla fine degli anni '80 per MS-DOS (ad esempio, Vocal-Eyes) e successivamente per Windows (JAWS, NVDA). Sulle piattaforme mobili, i lettori dello schermo sono stati integrati a livello di sistema: Apple ha integrato VoiceOver nell'iPhone 3GS nel 2009, Google ha integrato TalkBack in Android 1.6 nello stesso anno. Entro il 2025, praticamente tutti gli smartphone moderni hanno un lettore dello schermo integrato che non richiede installazione di software aggiuntivo.

Un lettore dello schermo non si limita a leggere il testo dallo schermo — analizza la gerarchia dell'interfaccia, determina i tipi di elementi (pulsante, link, intestazione, campo di input), i loro stati (abilitato/disabilitato, selezionato/non selezionato) e le relazioni (genitore-figlio, gruppo). Queste informazioni vengono trasmesse all'utente tramite suggerimenti vocali o sensazioni tattili di un display Braille, che aggiorna le celle in tempo reale in base alla posizione del focus.

Come funziona uno Screen Reader?

Un lettore dello schermo lavora a stretto contatto con il sistema operativo, accedendo alla sua rappresentazione interna dell'interfaccia — l'albero di accessibilità (Accessibility Tree). Questo meccanismo è lo stesso su iOS e Android, sebbene i nomi delle API differiscano.

Sintesi vocale (TTS)

Il canale di output principale di un lettore dello schermo è un sintetizzatore vocale (Text-To-Speech, TTS). Quando il focus di accessibilità si posa su un elemento, il lettore dello schermo estrae il suo contenuto testuale (o la descrizione fornita dallo sviluppatore) e lo invia al motore TTS. I moderni motori TTS, come Apple Speech Synthesis e Google Text-to-Speech, utilizzano reti neurali per generare voce naturale con intonazione, pause ed enfasi corrette in base alla punteggiatura e al tipo di contenuto.

L'utente può regolare la velocità della voce (di solito 60–80% del massimo per una percezione confortevole), l'intonazione e il volume. Alcuni lettori dello schermo supportano più voci e passano dall'una all'altra a seconda del tipo di contenuto — ad esempio, una voce più lenta per leggere il testo e una più veloce per la navigazione dell'interfaccia. I display Braille si collegano tramite Bluetooth e visualizzano fino a 40–80 caratteri alla volta, aggiornando la riga a ogni cambio di focus.

Gestione del focus e navigazione

Un lettore dello schermo utilizza il concetto di Focus di Accessibilità (Accessibility Focus), che differisce dal focus di input standard. L'utente sposta il focus di accessibilità utilizzando gesti (tocco, scorrimento), e il lettore dello schermo annuncia l'elemento sotto il focus. L'ordine di navigazione predefinito segue l'ordine visivo: da sinistra a destra, dall'alto verso il basso. Lo sviluppatore può sovrascrivere questo ordine per layout complessi.

Il lettore dello schermo supporta anche varie modalità di navigazione che l'utente cambia tramite il rotore (VoiceOver) o il menu (TalkBack): per intestazioni, link, caratteri, parole, moduli. In modalità intestazioni, il lettore dello schermo si sposta solo tra H1–H6 — questo è fondamentale per una navigazione efficiente attraverso pagine e documenti lunghi. La modalità caratteri aiuta durante l'inserimento di codici di conferma o password complesse, pronunciando ogni carattere singolarmente.

Principali lettori dello schermo per piattaforme mobili

Due lettori dello schermo dominano le piattaforme mobili: VoiceOver su iOS e TalkBack su Android. Hanno API, gesti e capacità diverse, ma il principio comune è la lettura dell'albero di accessibilità e il controllo gestuale.

VoiceOver (iOS)

VoiceOver è il lettore dello schermo di Apple, integrato in iOS, iPadOS e macOS. Utilizza l'API UIAccessibility per ottenere informazioni sugli elementi e supporta il rotore per cambiare le modalità di navigazione. VoiceOver è integrato con iCloud (le impostazioni si sincronizzano tra i dispositivi), Apple Pay (conferma del pagamento tramite Touch ID o Face ID) e testo dinamico (il carattere si adatta alle impostazioni dell'utente).

I gesti di VoiceOver differiscono da TalkBack: utilizza la rotazione a due dita (rotore), triplo tocco per Screen Curtain e doppio tocco a due dita per annullare un'azione. VoiceOver supporta rotori personalizzati che lo sviluppatore aggiunge tramite UIAccessibilityCustomRotor — ad esempio, per la navigazione rapida tra le sezioni dell'app scavalcando l'ordine standard.

TalkBack (Android)

TalkBack è il lettore dello schermo di Google, parte di Android Accessibility Suite. Utilizza AccessibilityService e AccessibilityNodeInfo per accedere all'interfaccia. TalkBack supporta un menu globale tramite scorrimento a forma di L, azioni personalizzate per gli elementi e LiveRegion per aggiornamenti dinamici. A partire da Android 14, TalkBack ha ottenuto il supporto per i gesti a una mano e una migliore integrazione con Google Assistant.

TalkBack ha un sistema di gesti più flessibile di VoiceOver: l'utente può assegnare praticamente qualsiasi gesto a qualsiasi azione. TalkBack supporta anche l'inserimento Braille sullo schermo (BrailleBack) — l'utente inserisce il testo con caratteri Braille direttamente sul touchscreen in un layout speciale 3×2 per dito, accelerando significativamente l'inserimento del testo rispetto alla tastiera su schermo.

Oltre a VoiceOver e TalkBack, esistono lettori dello schermo mobili meno comuni: Select to Speak (Android, vocalizza l'area selezionata), Samsung Voice Assistant (sostituisce TalkBack sui dispositivi Samsung con One UI) e soluzioni di terze parti per nicchie specifiche — ad esempio, per utenti di smartphone cinesi senza servizi Google.

Come interagisce uno Screen Reader con l'app

Un lettore dello schermo non ha accesso diretto ai componenti dell'interfaccia dell'app. Invece, funziona attraverso un livello — l'API di accessibilità del sistema operativo. Il sistema operativo costruisce un albero di accessibilità (Accessibility Tree) che il lettore dello schermo attraversa e analizza.

Albero di accessibilità su iOS e Android

Su iOS, l'albero di accessibilità è costruito da oggetti UIAccessibilityElement corrispondenti a ciascuna View sullo schermo. Ogni elemento contiene un label (testo principale), traits (tipo di elemento: pulsante, intestazione, link), hint (suggerimento), value (valore corrente per slider e indicatori) e frame (area di tocco). Il sistema crea automaticamente elementi per i componenti dell'interfaccia standard, ma lo sviluppatore può aggiungerli e personalizzarli.

Su Android, l'albero di accessibilità è costruito da oggetti AccessibilityNodeInfo. Ogni nodo contiene: text (testo o contentDescription), className (tipo di elemento), contentDescription (descrizione), stateDescription (stato), isEnabled, isChecked, isClickable e altri flag. Android supporta anche AccessibilityAction — un elenco di azioni che il lettore dello schermo può eseguire per conto dell'utente: clic, pressione lunga, scorrimento, impostazione del focus, impostazione del testo.

Eventi di accessibilità

Quando si verifica un cambiamento nell'interfaccia (un nuovo elemento appare, il testo cambia, un elemento diventa visibile o invisibile), il sistema operativo invia un AccessibilityEvent. Il lettore dello schermo si iscrive a questi eventi e vi reagisce: ad esempio, quando appare una finestra di dialogo, il lettore dello schermo sposta automaticamente il focus sul suo titolo e ne annuncia il contenuto.

// Ascolto degli eventi di accessibilità su Android
class CustomAccessibilityService : AccessibilityService() {
    override fun onAccessibilityEvent(event: AccessibilityEvent?) {
        event ?: return
        when (event.eventType) {
            TYPE_VIEW_CLICKED ->
                handleClick(event)
            TYPE_WINDOW_STATE_CHANGED ->
                handleWindowChange(event)
            TYPE_VIEW_TEXT_CHANGED ->
                handleTextChange(event)
        }
    }
}

Su iOS, eventi simili vengono gestiti tramite UIAccessibility.Notification: layoutChanged (layout cambiato), screenChanged (schermo completamente nuovo), announcement (annuncio personalizzato), pageScrolled (scorrimento pagina). Lo sviluppatore invia questi eventi tramite UIAccessibility.post affinché il lettore dello schermo risponda correttamente ai cambiamenti. Ad esempio, all'apertura di una finestra modale, è necessario inviare screenChanged con il nuovo titolo — altrimenti VoiceOver rimane sull'elemento precedente sotto la finestra.

Sviluppo di app per Screen Reader

Creare un'app accessibile non significa aggiungere contentDescription a ogni elemento — significa progettare l'esperienza utente per l'interazione non visiva. Le regole di base sono le stesse per entrambe le piattaforme, sebbene l'implementazione vari.

Regole di base dell'accessibilità

Tutti gli elementi interattivi devono avere una descrizione significativa: un pulsante “Invia” dovrebbe essere descritto come “Invia messaggio”, non solo “Pulsante”. Gli elementi decorativi (separatori, immagini di sfondo, icone non funzionali) dovrebbero essere nascosti al lettore dello schermo. L'ordine di navigazione dovrebbe seguire il flusso logico dello schermo, non la disposizione visiva. Il contrasto del testo dovrebbe essere almeno 4.5:1 per il testo normale e 3:1 per il testo grande (WCAG AA).

// iOS: configurazione corretta per un elemento complesso
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Volume audio"
customControl.accessibilityValue = "75 per cento"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Aumenta o diminuisce il volume"

// Aggiornamento al cambiamento del valore
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) per cento"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

Su iOS, il flag isAccessibilityElement abilita il supporto di VoiceOver per elementi personalizzati. La combinazione di traits (.adjustable + .button) comunica a VoiceOver che l'elemento può essere regolato scorrendo verso l'alto/basso e attivato con doppio tocco. Dopo aver modificato il valore, è necessario inviare una notifica layoutChanged — altrimenti VoiceOver continua ad annunciare il vecchio valore.

Raccomandazioni specifiche per piattaforma

Per iOS: utilizzare accessibilityElements per sovrascrivere l'ordine di lettura, accessibilityCustomActions per azioni aggiuntive nel menu contestuale e shouldGroupAccessibilityChildren per raggruppare gli elementi in gruppi logici. Per SwiftUI, utilizzare i modificatori .accessibilityLabel(), .accessibilityAddTraits() e .accessibilityRespondsToUserInteraction(). Evitare di impostare isAccessibilityElement = false su contenitori che contengono elementi figli interattivi — questo li nasconderà a VoiceOver.

Per Android: utilizzare accessibilityTraversalBefore e accessibilityTraversalAfter per l'ordine di navigazione, AccessibilityDelegate per elementi personalizzati e LiveRegion (polite/assertive) per aggiornamenti dinamici. In Compose, utilizzare il modificatore .semantics {} con contentDescription, stateDescription e customActions. Evitare di impostare focusable = true su elementi non interattivi — questo crea falsi punti di focus per TalkBack e confonde l'utente.

Strumenti di test

I test con un lettore dello schermo devono essere eseguiti su un dispositivo fisico. Un emulatore/simulatore fornisce una comprensione di base, ma i gesti e la velocità di risposta differiscono. Utilizzare Accessibility Inspector (Xcode) per iOS e Accessibility Scanner (Android) per il rilevamento automatico dei problemi.

Scenari di test chiave: registrazione (compilazione di un modulo, validazione, invio), ricerca e navigazione nel catalogo, checkout, recupero password. Ogni scenario deve essere completabile senza controllo visivo — solo attraverso i suggerimenti vocali del lettore dello schermo. Se un utente di lettore dello schermo non riesce a completare uno scenario nello stesso tempo di un utente normale (±50%), l'app necessita di miglioramenti di accessibilità.