I lettori di schermo sono utilizzati principalmente da persone non vedenti e ipovedenti, ma possono essere impiegati anche da chi ha limitazioni visive temporanee o in situazioni in cui la visione dello schermo risulta difficoltosa. È fondamentale che uno screen reader non sia solo un “lettore di testo ad alta voce”, ma che consenta anche una gestione efficace del computer o del telefono: spostarsi tra gli elementi, attivare i pulsanti, compilare moduli, utilizzare menu e applicazioni.
Come funziona uno screen reader
La maggior parte dei lettori di schermo non si basa sull’“immagine” dello schermo, ma sulla struttura dell’interfaccia utente. I sistemi operativi e le applicazioni trasmettono i dati relativi agli elementi tramite le API di accessibilità (accessibility API):
- ruolo (ad es. pulsante, link, campo di immissione, titolo),
- nome/identificatore (cos’è l’elemento),
- stato (ad es. selezionato, disabilitato, espanso),
- valore (ad es. contenuto del campo),
- talvolta anche descrizione o istruzioni aggiuntive.
Da questi dati si forma il cosiddetto albero di accessibilità, che è una rappresentazione “leggibile dal computer” dell’interfaccia. Quando l’utente sposta il focus (su un computer tramite la tastiera, su un telefono tramite gesti), lo screen reader legge ciò che si trova attualmente sotto il focus: ad esempio “Campo di immissione, E-mail, obbligatorio” o “Pulsante, Invia”.
Nel web viene spesso aggiunto un altro meccanismo importante: il puntatore virtuale o “modalità di navigazione”. In questa modalità, lo screen reader tratta la pagina web come un documento e consente all’utente di spostarsi rapidamente tra titoli, link, elenchi, tabelle o punti di riferimento (landmarks). L’utente, quindi, non passa con il tasto “Tab” su tutti gli elementi in sequenza, ma si sposta in modo mirato – proprio come un utente vedente che scorre la pagina con lo sguardo. Quando è necessario inserire qualcosa o gestire un componente, il lettore passa alla modalità di interazione diretta.
In fase di output, il lettore utilizza un sintetizzatore vocale, in cui l’utente imposta la voce, la velocità, la lingua e il livello di “loquacità” (quanti dettagli il lettore deve fornire). La riga Braille, invece, consente una lettura più accurata (separatori, sillabazione, codice) e spesso anche l’inserimento di dati.
I principali lettori di schermo per piattaforma
Sul desktop, i sondaggi tra gli utenti mostrano da anni che JAWS e NVDA sono tra i lettori di schermo più utilizzati, sebbene le proporzioni varino a seconda delle regioni e degli ambienti di lavoro. Per saperne di più, consulta lo studio di webaim.org
Windows
- NVDA (NonVisual Desktop Access): screen reader gratuito e open source. È apprezzato per la sua accessibilità, gli aggiornamenti frequenti e l’ecosistema di componenti aggiuntivi (add-on) che possono migliorare l’utilizzo di singole applicazioni. Scaricalo da nvaccess.org
- JAWS (Job Access With Speech): un lettore commerciale, diffuso nelle organizzazioni e tra gli utenti professionali. È noto per l’assistenza di qualità e la possibilità di personalizzazioni approfondite (anche tramite script) per specifici processi aziendali. Documentazione JAWS su support.freedomscientific.com
- Narrator (Narratore): integrato in Windows 10/11 e quindi sempre a portata di mano. Viene spesso utilizzato per attività di base, per l’apprendimento o come soluzione di riserva quando non è possibile installare un altro lettore. Documentazione di Narrator su Microsoft Support
macOS
- VoiceOver: lettore di schermo integrato per Mac, che supporta tastiera, trackpad e dispositivi Braille. Il vantaggio di questo strumento integrato è la buona integrazione con il sistema e con l’ecosistema Apple. Documentazione su VoiceOver su support.apple.com
Linux
- Orca: lettore di schermo open source (GNOME) che funziona tramite l’infrastruttura AT-SPI. Su Linux, l’esperienza utente dipende in larga misura dall’ambiente desktop e dal fatto che le applicazioni espongano correttamente le informazioni di accessibilità. Documentazione di Orca su orca.gnome.org
ChromeOS
- ChromeVox: lettore di schermo integrato per i Chromebook, progettato per l’uso nell’ambiente ChromeOS (sistema, browser, applicazioni web). Documentazione di ChromeVox su support.google.com
iOS/iPadOS
- VoiceOver: integrato in iPhone e iPad. Il controllo si basa sui gesti: scorrendo si passa da un elemento all’altro, con un doppio tocco si attiva, mentre con l’impostazione del “rotore” si seleziona la modalità di navigazione (ad es. per titoli, parole, caratteri). Il supporto per il Braille e il buon funzionamento nelle app di sistema sono due grandi vantaggi. Documentazione su VoiceOver su support.apple.com
Android
- TalkBack: il lettore di schermo di Google, parte della Android Accessibility Suite. Consente il controllo tramite gesti (anche con più dita), feedback vocale, personalizzazioni della pronuncia e, su numerosi dispositivi, anche una tastiera Braille sullo schermo. Documentazione su TalkBack su support.google.com
Non esiste una risposta universale alla scelta del “miglior” lettore di schermo. Gli utenti lo scelgono in base alle applicazioni che utilizzano (ad es. Office, sistemi aziendali, strumenti specializzati), alle scorciatoie a cui sono abituati, al tipo di supporto di cui hanno bisogno e se desiderano una soluzione gratuita o a pagamento.
Pertanto, quando si verifica l’accessibilità, è opportuno coprire almeno le combinazioni più comunemente utilizzate, in modo da ridurre il rischio che funzioni solo in un unico ambiente.
Funzionalità di base
Lettura e descrizione degli elementi. Lo screen reader legge il testo e annuncia il tipo di elemento (pulsante, link, casella di selezione), il suo nome e lo stato. È quindi fondamentale che i pulsanti abbiano nomi chiari (“Salva modifiche” anziché “OK”).
Navigazione nella struttura. L’utente può spostarsi tra titoli, elenchi, tabelle e collegamenti oppure leggere per caratteri, parole e righe. Sul web questa è una strategia fondamentale: prima una rapida panoramica (titoli), poi il salto alla sezione desiderata.
Tastiera o gesti al posto del mouse. Sul computer sono fondamentali i tasti Tab/Shift+Tab, le frecce e le scorciatoie del lettore di schermo. Sui dispositivi mobili sono fondamentali i gesti che sostituiscono il “tap” e lo “swipe”. Se una funzione funziona solo con il mouse, di norma sarà inaccessibile per l’utente di uno screen reader.
Moduli e feedback. Il lettore di schermo deve annunciare chiaramente l’etichetta del campo, se è obbligatorio, se si è verificato un errore e come risolverlo. Se l’etichetta del campo non è collegata programmaticamente all’input o se le istruzioni vengono visualizzate solo graficamente, l’utente spesso non sa cosa inserire. Per saperne di più, leggi l’articolo “Progettazione per gli utenti di lettori di schermo” (Zavod A11Y.si)
Impostazioni di sintesi vocale. Quasi tutti i lettori di schermo consentono di regolare la velocità e il volume, scegliere la voce, impostare i separatori e il livello di dettaglio. Un utente molto esperto può avere una velocità di sintesi vocale molte volte superiore a quella predefinita, pertanto è importante che l’interazione sia priva di “zavorra superflua”.
Funzionalità avanzate
Elenchi di elementi e salti rapidi. NVDA, JAWS e VoiceOver offrono elenchi di titoli, collegamenti, moduli o punti di orientamento. Ciò consente un rapido orientamento e riduce la necessità di “ascoltare” tutto in sequenza.
Il Braille come strumento attivo. Le righe Braille dispongono di tasti per il routing (salto su un determinato carattere), tasti per lo spostamento tra le righe e spesso la possibilità di digitare in Braille. Nel lavoro di precisione (ad es. ortografia, punteggiatura, codice) il Braille è spesso più veloce e affidabile della sintesi vocale.
Estensioni, script e profili. JAWS consente la creazione di script, mentre NVDA supporta le estensioni; entrambe le funzionalità sono importanti quando un’organizzazione utilizza applicazioni aziendali specializzate. Grazie alle personalizzazioni è possibile aggiungere comandi, migliorare la previsione o gestire specifici “casi limite”.
Applicazioni web dinamiche. Le applicazioni moderne aggiornano spesso i contenuti senza ricaricare la pagina. I lettori supportano quindi la previsione delle modifiche (ad es. notifiche, conferme, errori). Se ciò non viene implementato correttamente, l’utente non riceve feedback fondamentali (ad es. «Salvataggio completato») oppure l’applicazione lo interrompe con messaggi irrilevanti.
OCR e «risoluzione» delle parti non accessibili. Alcune piattaforme offrono il riconoscimento del testo sullo schermo come soluzione alternativa quando l’applicazione non fornisce dati di accessibilità. Ciò può essere utile, ma è più lento e meno affidabile e non sostituisce una corretta implementazione dell’accessibilità.
Strumenti di diagnostica. Funzionalità quali la cronologia vocale, la pronuncia, la pronuncia fonetica e la visualizzazione delle proprietà di un elemento (nome/ruolo/stato) sono molto utili anche durante i test di accessibilità: aiutano a comprendere cosa riceve effettivamente il lettore di schermo dall’interfaccia.
Breve cenno storico
I primi lettori di schermo sono stati sviluppati nell’era dei terminali testuali e degli ambienti DOS, dove era possibile leggere i caratteri sullo schermo e trasmetterli a un sintetizzatore vocale. Il passaggio alle interfacce grafiche ha comportato una sfida: pulsanti, icone e finestre non sono più “testo”, per questo motivo sono state sviluppate le interfacce di programmazione per l’accessibilità (API), attraverso le quali i sistemi operativi e le applicazioni espongono la struttura degli elementi (ruoli, nomi, stati) e i lettori di schermo possono “capire” cosa c’è sullo schermo.
Negli ultimi anni, i lettori di schermo sono spesso integrati nei sistemi operativi, il che ha notevolmente migliorato l’accessibilità: Narrator in Windows, VoiceOver in macOS/iOS, TalkBack in Android e ChromeVox in ChromeOS.
Un’altra pietra miliare è rappresentata dalla comunità open source: NVDA, un lettore di schermo gratuito e molto diffuso su Windows, e Orca, fondamento dell’accessibilità sui desktop Linux.
Per gli autori e i curatori dei contenuti rimane fondamentale una regola: il significato deve essere espresso anche a livello di codice (struttura corretta dei titoli, moduli contrassegnati, nomi significativi dei pulsanti), poiché lo screen reader non interpreta la disposizione visiva.
Le combinazioni di tecnologie più utilizzate nella pratica
Se si desidera simulare l’uso reale durante la verifica dell’accessibilità, è utile conoscere le più comuni combinazioni di screen reader e browser. Secondo i dati del WebAIM Screen Reader User Survey #10 (2024), le combinazioni più utilizzate sono le seguenti: Fonte: WebAIM
- JAWS + Chrome (24,7 %)
- NVDA + Chrome (21,3 %)
- JAWS + Microsoft Edge (11,4 %)
- NVDA + Firefox (10,0 %)
- VoiceOver + Safari (7,0 %)
- NVDA + Microsoft Edge (5,0 %)
Meno frequenti, ma comunque presenti, sono ad esempio JAWS + Firefox (2,6 %) e VoiceOver + Chrome (2,0 %), oltre ad altre combinazioni con percentuali minori. Nel complesso, le prime combinazioni citate coprono gran parte dell’utilizzo effettivo; pertanto, nella pratica, spesso si esegue il test almeno con NVDA/Chrome, JAWS/Chrome o Edge e, su Mac, con VoiceOver/Safari.
Si raccomanda inoltre di effettuare i test non solo con la combinazione Chrome/Edge, ma anche con Firefox, poiché Chrome/Edge utilizzano lo stesso kernel (Chromium) e non presentano differenze tra loro.
I dati sull’utilizzo vengono ricavati monitorando le analisi periodiche sull’uso dei lettori di schermo condotte da WebAIM, sulla base delle quali otteniamo anche altre informazioni utili sulle abitudini di utilizzo dei lettori di schermo: Decima analisi delle abitudini degli utenti di lettori di schermo (WebAIM.org, in lingua inglese).
Per saperne di più:
Progettazione per gli utenti di lettori di schermo (Zavod A11Y.si)