T 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. Voci correlate e collegamenti utili ARIA (WAI-ARIA) Landmark Mobile accessibility Ruoli ARIA Screen reader VoiceOver Naviga il Glossario dell'accessibilità A-Z Vai al glossario A B C D E F G H I J K L M N O P R S T U V W X Y 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
29 ottobre 25 Accessibilità digitale e tecnologie assistive Le tecnologie assistive svolgono un ruolo cruciale nell’abbattere le barriere digitali
29 ottobre 25 Normative e linee guida dell’accessibilità webScopri normative e linee guida per l’accessibilità digitale. Rendi il web inclusivo e fruibile da tutti
30 settembre 25 Glossario sull’Accessibilità: guida completa a cura di AccessiwebAccessiWeb ha pubblicato un glossario sull’accessibilità digitale. Ecco come puoi consultarlo