TalkBack

Screen reader per dispositivi Android, fornisce output vocale e braille e consente di navigare app e siti con gesti.

Definizione — TalkBack è lo screen reader nativo di Android che descrive a voce (e su display braille) elementi, ruoli e stati dell’interfaccia. Permette a persone cieche o ipovedenti di usare app e siti web responsive tramite gesti e comandi dedicati. Per funzionare in modo efficace richiede semantica corretta (nome, ruolo, stato), ordine di focus coerente e controlli attivabili da tastiera/gesti secondo WCAG 2.1.

Come si usa (gesti principali)

Esplora al tocco: tocca un punto dello schermo per ascoltare l’elemento sotto il dito; double tap ovunque per attivarlo.
Swipe orizzontali: flick destra/sinistra per passare all’elemento successivo/precedente (ordine di focus).
Granularità: swipe su/giù per cambiare unità (caratteri, parole, controlli, titoli, link) e poi flick per spostarsi a quella unità.
Scroll: due dita per scorrere liste/pagine; tre dita per altri gesti di navigazione (a seconda della configurazione).
Menu contestuale: accesso rapido ad azioni (leggi dall’alto, leggi da qui, copia testo, controlli).

Impatti su design e sviluppo

Nome/Ruolo/Stato (WCAG 4.1.2): su web usa elementi nativi (button, nav, main) e ARIA solo quando necessario; su app usa contentDescription, etichette accessibili e ruoli corretti dei widget.
Label in Name (2.5.3): il testo visibile deve comparire nel nome accessibile (es. “Cerca” → “Cerca”).
Ordine e focus: il focus segue la logica del DOM (web) o della gerarchia di viste (app). Evita elementi “focusable” non interattivi e trappole nei modali.
Controlli attivabili: ogni azione deve essere eseguibile senza gesture complesse (pinch, swipe multipli). Fornisci pulsanti espliciti.
Annunci dinamici: usa aria-live/role="status" per stati e notifiche; evita annunci continui (rumore).

Test rapidi con TalkBack (web e app)

Scansione: fai swipe destra/sinistra lungo la pagina. L’ordine è logico? Il focus rimane evidente anche a zoom alto?
Heading e landmark (web): verifica navigazione per titoli e regioni. Esiste un H1 unico e descrittivo?
Form: esplora e compila. Etichette, hint e errori sono annunciati? I messaggi sono associati al campo (aria-describedby)?
Componenti interattivi: menù, tab, dialog. Sono attivabili con doppio tap? Gli stati (aria-expanded, aria-selected) si aggiornano in tempo reale?
Mobile UX: target touch ≥44px, reflow a 320 px, nessun lock di orientamento, rispetto “Riduci animazioni”.

Consigli pratici (Android)

Usa componenti nativi o librerie accessibili; imposta contentDescription solo quando manca un testo visibile.
Evita conflitti tra clickable/focusable su container e controlli figli (il focus deve cadere sull’elemento significativo).
Per liste e card, rendi tutta la card attivabile se la UI lo suggerisce, ma annuncia comunque il contenuto chiave.

WCAG e standard correlati

2.1.1 Tastiera, 2.4.3 Ordine di focus, 2.4.7 Focus visibile, 2.5.1 Gestures, 2.5.3 Label in Name, 1.4.10 Reflow, 4.1.2 Nome/Ruolo/Stato.