Dal glossario dell'accessibilità

AccessiWeb: il web accessibile e inclusivo

T

TalkBack

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

DefinizioneTalkBack è 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)

  1. Scansione: fai swipe destra/sinistra lungo la pagina. L’ordine è logico? Il focus rimane evidente anche a zoom alto?
  2. Heading e landmark (web): verifica navigazione per titoli e regioni. Esiste un H1 unico e descrittivo?
  3. Form: esplora e compila. Etichette, hint e errori sono annunciati? I messaggi sono associati al campo (aria-describedby)?
  4. Componenti interattivi: menù, tab, dialog. Sono attivabili con doppio tap? Gli stati (aria-expanded, aria-selected) si aggiornano in tempo reale?
  5. 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.

Naviga il Glossario dell'accessibilità A-Z

Richiedi una consulenza gratuita

Il nostro team di Web Accessibility Expert certificati UNI 11621-3 è pronto a guidarti con le migliori soluzioni per il tuo business!

Contattaci adesso
Parla con un esperto di accessibilità

Ultimi articoli dal blog

Immagine stilizzata che rappresenta disabilità visive, uditive, motorie e percettive

AccessiWeb

Soluzioni per un web accessibile e inclusivo

Inizia la tua prova gratuita