Sintesi vocale vs. screen reader

I tuoi contenuti hanno una voce

La tecnologia di sintesi vocale (TTS) converte le informazioni scritte in audio. Aiuta le persone con cecità, ipovisione, dislessia e ADHD a fruire dei contenuti in un modo adatto a loro. Il TTS è anche ampiamente usato nelle scuole, da chi studia le lingue e dai professionisti che rileggono con l’orecchio anziché con l’occhio.

Poiché sia il TTS sia gli screen reader producono una voce sintetica, spesso si dà per scontato che siano la stessa cosa, o che aggiungere un pulsante «leggi ad alta voce» a un sito web lo renda accessibile agli utenti non vedenti. Questo presupposto è sbagliato, e agire di conseguenza può lasciarti con un sito che suona accessibile ma che molte persone non riescono effettivamente a usare. Questo articolo spiega come funziona ciascuna tecnologia, chi ne dipende, dove si trova davvero il confine tra loro e cosa serve per sviluppare correttamente per gli screen reader. Se ricordi una sola cosa, sia questa: un widget di lettura ad alta voce è una funzione di comodità, non una funzione di accessibilità.

Come funziona il TTS?

Il TTS elabora il testo in tre grandi fasi:

Analisi del testo — determinare tono, grammatica e struttura, espandere numeri e simboli («5 $» diventa «cinque dollari») e segmentare le frasi.
Elaborazione linguistica — calcolare pronuncia, accento ed enfasi, spesso usando un dizionario di pronuncia più regole per le parole sconosciute.
Sintesi audio — generare il parlato a partire da modelli vocali matematici, sempre più tramite reti neurali che suonano molto più naturali dei vecchi motori concatenativi.

I sistemi moderni offrono la personalizzazione della voce, come velocità, tono, persona vocale e selezione della lingua. Il punto cruciale è cosa prende il TTS come input: un blocco di testo che qualcuno ha già selezionato, incollato o indicato. Il TTS è fondamentalmente una tecnologia di emissione del contenuto. Pronuncia ciò che gli viene dato. Non esplora un’interfaccia e non ha alcun concetto di pulsanti, campi di un modulo o struttura della pagina.

Quali sono i limiti della tecnologia TTS?

Il TTS è davvero utile, ma non è perfetto, e i suoi limiti contano per il confronto che segue:

Lacune di pronuncia — può pronunciare male parole non comuni, nomi propri, termini medici o legali e abbreviazioni.
Supporto linguistico disomogeneo — molti strumenti gestiscono bene le lingue diffuse, ma faticano con le lingue meno comuni e i dialetti regionali.
Tono e sfumatura — il TTS ha difficoltà con sarcasmo, umorismo ed espressioni idiomatiche, quindi i contenuti possono essere trasmessi con il tono sbagliato.
Nessun modello di interazione — ed è questo il punto cruciale: il TTS legge; non ti permette di fare nulla. Non puoi compilare un modulo di pagamento, chiudere una finestra modale o spostarti tra le voci di un menu usando solo il TTS.

Proprio quest’ultimo limite è il punto da cui inizia la confusione con gli screen reader.

È qui che nasce il malinteso comune. La sintesi vocale legge il testo ad alta voce: è la sua funzione principale. Uno screen reader fa molto di più: consente agli utenti di navigare e utilizzare un intero computer o dispositivo mobile con l’udito e la tastiera (o i gesti tattili).

Gli screen reader annunciano le etichette dell’interfaccia, i campi dei moduli, i pulsanti e i link; leggono il testo alternativo delle immagini affinché gli utenti comprendano i contenuti visivi; ed espongono lo stato dei componenti: se una casella è selezionata, se un menu è espanso, se una scheda è selezionata o se è comparso un errore. Trasformano un’interfaccia visiva, gestita con il mouse, in una lineare, udibile e utilizzabile.

Un modo rapido per cogliere la differenza: il TTS risponde alla domanda «cosa dice questo paragrafo?» Uno screen reader risponde «dove sono, cosa posso fare qui e cosa è appena successo?» Il primo riguarda la fruizione dei contenuti. Il secondo riguarda il controllo del software.

Gli utenti vedenti scorrono una pagina in pochi secondi. Un utente di screen reader costruisce un modello mentale in modo sequenziale e si affida alla struttura per muoversi in modo efficiente. In pratica:

Saltano tra le intestazioni per capire la struttura della pagina (ecco perché una gerarchia di intestazioni corretta conta così tanto).
Richiamano un elenco di tutti i link o di tutti i campi dei moduli per navigare per punti di riferimento invece di leggere dall’alto verso il basso.
Usano le regioni di riferimento (banner, navigazione, contenuto principale, piè di pagina) per saltare direttamente al contenuto che vogliono.
Si spostano tra gli elementi interattivi con il tasto Tab e si aspettano che il focus arrivi in un punto visibile e logico.
Ascoltano gli annunci dal vivo quando qualcosa cambia senza un ricaricamento completo della pagina.

Nulla di tutto ciò funziona se il markup sottostante non descrive la pagina in modo onesto. Una funzione di «lettura ad alta voce» non fornisce nessuno di questi ausili di navigazione: si limita a narrare qualsiasi testo presente sullo schermo, in ordine visivo, senza alcun modo di utilizzare i controlli.

Chi usa cosa e perché è importante

Il TTS è usato da un pubblico ampio, spesso in modo situazionale: persone con dislessia, ADHD o ipovisione; chi fa più cose contemporaneamente; chi studia le lingue; e chiunque preferisca semplicemente ascoltare. La maggior parte di questi utenti può ancora vedere lo schermo e usare un mouse.

Gli utenti di screen reader comprendono persone non vedenti o con gravi disabilità visive, oltre ad alcune persone con disabilità cognitive o motorie, che dipendono dalla tecnologia per poter usare un dispositivo. Per loro non è uno strato di preferenza sopra un’interfaccia utilizzabile: è l’interfaccia. Gli strumenti più comuni sono NVDA e JAWS su Windows, VoiceOver sui dispositivi Apple e TalkBack su Android. Ciascuno interpreta la stessa pagina web in modo leggermente diverso, ed è uno dei motivi per cui testare su tutti è importante.

Un numero crescente di siti web aggiunge un pulsante «ascolta questa pagina» o un widget di terze parti che evidenzia e legge il testo. Questi strumenti possono aiutare alcuni lettori, e non c’è nulla di male nell’offrirne uno come comodità. Il problema è trattarlo come un sostituto del vero supporto agli screen reader. Non lo è, per diversi motivi concreti.

Si limitano a leggere; non utilizzano. Un widget di lettura ad alta voce narrerà la tua tabella dei prezzi, ma non può permettere a un utente non vedente di selezionare un piano, aprire il carrello, inserire i dati di pagamento e completare l’acquisto. Le attività reali richiedono controlli utilizzabili, non la narrazione.
Non possono esporre stato o ruoli. Se un pulsante è premuto, se un campo è obbligatorio, se una sezione è compressa o se è appena comparso un messaggio di errore: niente di tutto ciò viene trasmesso leggendo il testo visibile. Gli screen reader si basano su ruoli, nomi e stati nel markup per annunciarlo.
Gli utenti di screen reader hanno già uno strumento. Gli utenti non vedenti portano con sé il proprio screen reader, finemente calibrato sulle loro preferenze e sulla loro memoria muscolare. Un widget a livello di pagina entra in concorrenza con esso, a volte interferisce con esso e non fa nulla per riparare il markup difettoso su cui il loro screen reader si blocca.
Mascherano i problemi invece di risolverli. Se un campo di un modulo non ha un’etichetta, il widget lo salterà proprio come farebbe uno screen reader, ma ora l’etichetta mancante è nascosta dietro una funzione che sembra utile. Il difetto sottostante rimane.

Questa stessa logica vale, in modo ancora più netto, per i cosiddetti overlay di accessibilità: script che promettono una conformità istantanea sovrapponendo correzioni automatiche e una barra degli strumenti a un sito esistente. Non riparano il codice sottostante, spesso entrano in conflitto con la tecnologia assistiva degli utenti e non possono fornire una conformità reale. La strada affidabile è correggere la sorgente. Per una spiegazione più completa del perché le correzioni superficiali non bastano, consulta la nostra guida alla vera accessibilità digitale.

Un esempio concreto: il checkout che «parla»

Immagina un negozio online che ha aggiunto un widget di lettura ad alta voce ed è convinto che il sito sia ora accessibile. Una cliente non vedente arriva con il proprio screen reader in funzione. La descrizione del prodotto viene letta bene: quella parte è solo testo. Ma il controllo «Aggiungi al carrello» è un div con stile e un gestore di clic invece di un vero pulsante, quindi lo screen reader non lo annuncia mai come pulsante e la tastiera non riesce a raggiungerlo. Il selettore della quantità aggiorna un totale senza una regione dal vivo, quindi la modifica è silenziosa. Il campo del codice promozionale ha un testo segnaposto ma nessuna etichetta associata, quindi viene annunciato solo come «modifica testo». Il modulo di spedizione mostra visivamente un errore in rosso, ma l’errore non è collegato al campo e non viene annunciato affatto. Il widget di lettura ad alta voce narra allegramente il testo visibile e non cambia nulla di tutto ciò. La cliente può sentire il testo di marketing ma non può completare un acquisto. Quel divario — tra sentire il contenuto e utilizzare un prodotto — è tutta la differenza tra una funzione di comodità e l’accessibilità.

Supportare gli screen reader non significa aggiungere una funzione: significa costruire le tue pagine in modo che significato, struttura e comportamento siano disponibili per il software, non solo per l’occhio umano. Gli ingredienti fondamentali:

HTML semantico e strutturato

Usa intestazioni reali (h1–h6) in un ordine logico, pulsanti e link nativi per gli scopi giusti, elenchi per gli elenchi ed elementi di riferimento per le regioni della pagina. L’HTML semantico veicola gratis le informazioni di accessibilità; un muro di contenitori generici non ne veicola alcuna.

Alternative testuali per i contenuti non testuali

Ogni immagine significativa ha bisogno di un testo alternativo accurato, e le immagini decorative dovrebbero essere contrassegnate per essere saltate. Le icone che fungono da pulsanti hanno bisogno di nomi accessibili. Grafici e infografiche hanno bisogno di un equivalente testuale che trasmetta le stesse informazioni.

Nomi, ruoli e stati accessibili

I campi dei moduli hanno bisogno di etichette associate a livello di codice. I componenti personalizzati — schede, fisarmoniche, caselle combinate, finestre modali — hanno bisogno dei ruoli e degli stati corretti affinché lo screen reader annunci cosa sono e come si comportano. Dove l’HTML nativo non basta, ARIA colma il divario, ma deve essere usato con precisione; un ARIA scorretto è peggio di nessun ARIA.

Utilizzabilità da tastiera e gestione del focus

Tutto ciò che funziona con il mouse deve funzionare con la tastiera, l’ordine del focus deve essere logico, l’indicatore di focus deve essere visibile, e le modifiche dinamiche (apertura di una finestra di dialogo, comparsa di un errore) devono spostare o annunciare il focus in modo appropriato. Il supporto da tastiera e il supporto agli screen reader sono profondamente intrecciati.

Annunciare le modifiche dinamiche

Quando il contenuto si aggiorna senza un ricaricamento della pagina — un messaggio di convalida di un modulo, un contatore del carrello, uno stato di caricamento — usa le regioni dal vivo affinché lo screen reader comunichi all’utente che è successo qualcosa. Gli aggiornamenti silenziosi sono invisibili per chi non può vedere lo schermo.

Tutte queste aspettative sono codificate nei criteri di successo di WCAG 2.2, che costituiscono la spina dorsale tecnica dell’European Accessibility Act e dell’ADA applicata al web. Se vuoi i dettagli pratici, la nostra guida ai test con gli screen reader illustra passo dopo passo come verificare ciascuno di questi comportamenti con strumenti reali.

Perché «a me viene letto bene» è fuorviante

Uno sviluppatore vedente può attivare una funzione di lettura ad alta voce, sentire frasi pulite e concludere che la pagina è accessibile. La trappola è che la lettura ad alta voce riproduce l’ordine di lettura visibile e il testo visibile, entrambi già sensati per chi guarda lo schermo. Non dice nulla sul fatto che un menu a discesa personalizzato annunci le sue opzioni, che il focus sia intrappolato dentro una finestra di dialogo aperta, che un pulsante composto solo da un’icona abbia un nome o che l’ordine di tabulazione corrisponda al layout visivo. Proprio queste sono le cose che si rompono per gli utenti di screen reader e proprio queste sono le cose che una demo di lettura ad alta voce non può rivelare. L’unico modo per saperlo è testare come fanno gli utenti reali.

Come testare per entrambi, e perché la sola automazione non basta

Non puoi confermare che una pagina funzioni per gli utenti di screen reader ascoltando un pulsante di lettura ad alta voce. Lo confermi controllando struttura, nomi, ruoli, stati, funzionamento da tastiera e l’effettiva esperienza con lo screen reader su più strumenti e piattaforme.

Un processo solido combina tre livelli:

Scansione automatica per individuare i problemi di grande volume e rilevabili dalla macchina: testo alternativo mancante, etichette vuote, riferimenti ARIA interrotti, errori di contrasto. Il nostro software di scansione dell’accessibilità e una scansione di accessibilità gratuita sono un modo rapido per stabilire il punto di partenza.
Test manuali da parte di esperti per valutare tutto ciò che l’automazione non può giudicare: se un nome è significativo, se l’ordine del focus ha senso, se un widget personalizzato è davvero utilizzabile. Il ragionamento alla base di questo livello è trattato nella nostra guida agli audit manuali di accessibilità.
Test con tecnologia assistiva reale e utenti reali. Nulla sostituisce l’utilizzo della pagina con NVDA, JAWS, VoiceOver e TalkBack e, idealmente, l’osservazione di persone che usano questi strumenti ogni giorno. I nostri audit condotti da persone con disabilità apportano esattamente questa competenza vissuta.

Gli strumenti automatici di solito rilevano solo una parte dei criteri di successo di WCAG 2.2; il resto richiede il giudizio umano. Trattare una scansione automatica superata come prova di accessibilità è lo stesso tipo di errore che trattare un widget di lettura ad alta voce come supporto agli screen reader.

Dove si colloca QualiBooth

QualiBooth testa il tuo sito web rispetto ai casi d’uso sia del TTS sia degli screen reader, affinché i tuoi contenuti siano accessibili agli utenti che si affidano a una delle due tecnologie, e affinché le persone che dipendono da uno screen reader possano non solo sentire i tuoi contenuti ma utilizzare davvero il tuo prodotto. Il nostro toolkit per l’accessibilità e la piattaforma Agora combinano la scansione con una revisione manuale strutturata, e il nostro team di consulenza sull’accessibilità ti aiuta a correggere ciò che i test fanno emergere e ad allinearti ai requisiti di WCAG 2.2, dell’EAA e dell’ADA.

La conclusione è semplice. Dare una voce ai tuoi contenuti è un bel tocco. Rendere i tuoi contenuti navigabili, utilizzabili e annunciati correttamente a uno screen reader è accessibilità, e solo una di queste cose soddisfa la legge e le persone che essa protegge.