Lettori di schermo spiegati: come le persone cieche navigano sul web

Si stima che ci siano 36 milioni di persone cieche nel mondo e che circa altre 217 milioni vivano con una disabilità visiva da moderata a grave. Eppure, nel 2025, oltre il 96% dei siti web presenta ancora almeno un errore di accessibilità rilevabile. Per una persona cieca che si affida a un lettore di schermo, anche una sola etichetta mancante, una gerarchia di titoli interrotta o un CAPTCHA inaccessibile può fare la differenza tra completare un’attività in autonomia e abbandonare del tutto il tuo sito. Capire come funzionano davvero i lettori di schermo — non solo in teoria, ma in pratica — è il fondamento per costruire un web accessibile.

Che cos’è un lettore di schermo e chi lo usa?

Un lettore di schermo è un software di tecnologia assistiva che converte il contenuto a schermo in sintesi vocale o in output braille rinfrescabile. Invece di limitarsi a leggere il testo ad alta voce, i lettori di schermo interpretano la struttura, i ruoli, gli stati e le relazioni degli elementi dell’interfaccia, offrendo alle persone una comprensione completa di una pagina web senza fare affidamento sulla presentazione visiva. Pensalo meno come un narratore e più come un interprete intelligente che traduce l’intera interfaccia visiva in un flusso di informazioni audio o tattili.

I lettori di schermo sono usati principalmente da persone cieche o ipovedenti, ma supportano anche utenti con alcune disabilità cognitive o di lettura. Secondo la 10ª indagine sugli utenti di lettori di schermo di WebAIM — condotta alla fine del 2023 e pubblicata a febbraio 2024 — quasi il 77% delle persone che usano lettori di schermo sono persone con cecità, seguite da persone con ipovisione o altre disabilità visive con quasi il 20%. La perdita dell’udito, le disabilità cognitive e le disabilità motorie rappresentano la parte restante. Non si tratta di un pubblico di nicchia: il 4,9% degli adulti negli Stati Uniti ha una disabilità visiva con cecità o gravi difficoltà di vista, e la cifra globale delle persone con disabilità visive si conta in centinaia di milioni.

Vale anche la pena sottolineare che le persone che usano lettori di schermo non sono un gruppo monolitico. La ricerca mostra costantemente un’ampia varietà di competenze, preferenze, strategie di navigazione e approcci alla risoluzione dei problemi. Una persona cieca dalla nascita che usa JAWS da vent’anni naviga in modo molto diverso da chi ha perso la vista di recente e sta ancora imparando a usare le tecnologie assistive. Anche i siti tecnicamente accessibili possono presentare sfide significative quando i modelli mentali che richiedono non corrispondono alle aspettative dell’utente. Designer e sviluppatori devono resistere alla tentazione di immaginare un singolo, archetipico utente di lettore di schermo.

Come funzionano davvero i lettori di schermo: l’albero di accessibilità

Per capire davvero i lettori di schermo, devi capire che cosa leggono — e non è il tuo layout visivo. I lettori di schermo funzionano accedendo all’albero di accessibilità, una rappresentazione strutturata della pagina che il browser costruisce a partire dal DOM HTML. Il browser espone questo albero tramite API di accessibilità specifiche della piattaforma: UI Automation su Windows, NSAccessibility su macOS e AccessibilityService su Android. Il lettore di schermo interroga questa API, riceve informazioni semantiche su ogni elemento e le converte in output vocale o braille.

Questo ha un’implicazione cruciale: ciò che vedi sullo schermo e ciò che percepisce un lettore di schermo possono essere radicalmente diversi. Se il tuo design visivo usa un <div> stilizzato per sembrare un pulsante, un lettore di schermo non lo annuncerà come pulsante — perché non ha alcun ruolo di pulsante nell’albero di accessibilità. Il lettore di schermo annuncia ciò che dice il codice, non ciò che mostrano i pixel. Gli elementi HTML semantici come <button>, <nav>, <h1> e <form> hanno ruoli integrati che vengono esposti automaticamente all’albero di accessibilità. Quando gli sviluppatori li bypassano a favore di elementi generici rattoppati con ruoli ARIA, creano complessità non necessaria e introducono spesso nuovi errori.

I lettori di schermo forniscono anche contesto che non è visibile sullo schermo. Quando una persona incontra un elenco, il lettore di schermo annuncia quanti elementi contiene. Quando si raggiunge una tabella, annuncia il numero di righe e colonne. Quando il focus si sposta in un campo di un modulo, legge l’etichetta del campo, il suo tipo e il suo stato attuale. Questi metadati contestuali dipendono interamente da HTML ben strutturato e semantico. Se li elimini, elimini la capacità dell’utente di capire con che cosa ha a che fare.

I principali lettori di schermo: JAWS, NVDA, VoiceOver e TalkBack

Il mercato dei lettori di schermo è dominato da una manciata di strumenti, ciascuno con caratteristiche distintive. Capire su quali strumenti è probabile che le persone si affidino influisce direttamente su come dovresti testare il tuo sito.

JAWS (Job Access With Speech), sviluppato da Freedom Scientific e rilasciato per la prima volta nel 1995, è da tempo considerato il gold standard del settore, in particolare per l’uso aziendale. Nell’indagine WebAIM 2024, JAWS era il lettore di schermo principale per circa il 41% delle persone che hanno risposto. È un prodotto commerciale con costi di licenza che vanno da 90 $ a oltre 1.400 $ all’anno. JAWS offre un’ampia personalizzazione, una compatibilità robusta con flussi di lavoro complessi in Microsoft Office e applicazioni professionali, e una “Browse Mode” che trasforma la pagina in un ambiente lineare navigabile, consentendo alle persone di saltare tra titoli, landmark e campi di modulo usando combinazioni di tasti intuitive.

NVDA (NonVisual Desktop Access), sviluppato da NV Access e introdotto nel 2006, è un lettore di schermo gratuito e open source per Windows. È stato il lettore di schermo principale per circa il 38% delle persone che hanno risposto all’indagine WebAIM nel 2024 — una percentuale quasi identica a JAWS. NVDA ha guadagnato una notevole popolarità grazie al modello gratuito, agli aggiornamenti frequenti e alle prestazioni robuste. Nel 2025, NVDA ha introdotto una gestione migliorata del focus nelle applicazioni a pagina singola, aiutando le persone a capire quando il contenuto è cambiato e dove si è spostato il focus. Il browser consigliato in abbinamento è Firefox, anche se il supporto per Chrome è anch’esso solido.

VoiceOver è il lettore di schermo integrato di Apple, disponibile su macOS, iOS e iPadOS — non richiede installazione. Su desktop utilizza scorciatoie da tastiera con il modificatore VO (Control + Option), mentre su iOS si basa su gesti touch come swipe, doppio tap e rotor. Su dispositivi mobili, VoiceOver è il lettore di schermo più utilizzato, con il 70,6% delle persone che usano lettori di schermo su mobile che vi si affidano. Funziona al meglio in abbinamento con Safari, che è l’unico browser che espone completamente le API di accessibilità di macOS/iOS a VoiceOver.

TalkBack è il lettore di schermo integrato di Android, che offre feedback vocale e vibrazioni per aiutare le persone a navigare nei propri dispositivi. È lo strumento standard per i test su mobile Android e si abbina al meglio con Chrome. Windows include anche Narrator, un lettore di schermo integrato che è migliorato costantemente ma manca ancora di alcune funzionalità di JAWS e NVDA. Ognuno di questi strumenti si comporta in modo leggermente diverso — uno schema che funziona correttamente in NVDA può fallire in JAWS — ed è per questo che testare con più lettori di schermo è essenziale per qualsiasi programma di accessibilità serio.

Come navigano davvero le persone cieche: il modello mentale che cambia tutto

Ecco l’intuizione che più di ogni altra dovrebbe cambiare il modo in cui gli sviluppatori pensano al proprio lavoro: le persone che usano lettori di schermo non leggono le pagine in modo lineare dall’alto verso il basso. Usano un insieme sofisticato di strategie di navigazione per scansionare e saltare rapidamente tra i contenuti, in modo molto simile a come una persona vedente scorre visivamente. Se non supporti queste strategie, anche una pagina tecnicamente accessibile diventa un’esperienza estenuante e inutilizzabile.

La strategia di navigazione più diffusa è la navigazione tramite titoli. L’uso dei titoli per trovare informazioni è aumentato nel tempo e rimane il metodo predominante — l’88,8% delle persone che hanno risposto all’indagine trova i livelli di titolo molto o abbastanza utili. Le persone più esperte hanno molte più probabilità di navigare tramite titoli rispetto ai principianti. In pratica, questo significa che una persona preme il tasto H in JAWS o NVDA per saltare al titolo successivo nella pagina, scansionando rapidamente la struttura. Premendo 1 a 6 si salta direttamente a un titolo di quel livello. Se la tua pagina non ha titoli, o usa titoli scelti per la dimensione visiva anziché per la struttura del documento, le persone cieche non hanno punti di riferimento tra cui saltare — sono costrette ad ascoltare l’intera pagina dall’inizio.

La seconda grande strategia è la navigazione tramite landmark. Gli elementi landmark di HTML5 — <main>, <nav>, <header>, <footer>, <aside> e <section> con un’etichetta — creano regioni nominate tra cui le persone che usano lettori di schermo possono saltare usando il rotor o i tasti di scelta rapida per i landmark. Nel 2025, l’adozione dei landmark ARIA è aumentata leggermente, trainata dal crescente uso dell’elemento nativo <main>, ora presente nel 47% delle pagine. Sebbene il 31,7% delle persone dichiari di usare sempre o spesso i landmark quando sono presenti, solo il 3,7% usa i landmark come metodo di navigazione principale — il che suggerisce che i landmark siano uno strumento secondario, ma importante per l’orientamento.

Le persone navigano anche tramite link, campi di modulo e pulsanti usando scorciatoie a tasto singolo, e spesso richiamano elenchi di elementi — una finestra di dialogo che mostra tutti i titoli, tutti i link o tutti i campi di modulo della pagina in una volta — per scansionare e saltare direttamente a ciò di cui hanno bisogno. Questo comportamento ha enormi implicazioni per il testo dei link. Un elenco di link che recita “Leggi di più, Leggi di più, Leggi di più” non offre alcun valore di navigazione. Ogni link e ogni pulsante deve avere un nome accessibile descrittivo e univoco che abbia senso fuori contesto.

Su mobile, il paradigma si sposta verso i gesti touch. Le persone che usano VoiceOver e TalkBack effettuano uno swipe verso destra per spostarsi all’elemento successivo, un doppio tap per attivarlo e usano i gesti del rotor per cambiare modalità di navigazione. La preferenza per l’uso di app mobili è aumentata al 58% nel 2024, rispetto al 51,8% nel 2021. Questo significa che il tuo design responsive e l’accessibilità mobile non sono componenti opzionali — sono casi d’uso primari per una grande parte delle persone che usano lettori di schermo.

Le barriere più problematiche sul web oggi

L’indagine di WebAIM ha chiesto alle persone di identificare gli elementi più problematici che incontrano. I risultati sono straordinariamente coerenti in oltre un decennio di indagini — e costituiscono una checklist diretta di ciò che il tuo sito deve fare correttamente.

• CAPTCHA è, con un margine significativo, il reclamo principale. Le persone che usano lettori di schermo concordano sul fatto che CAPTCHA sia l’elemento più problematico da oltre quattordici anni di fila. L’uso di un CAPTCHA tradizionale è ovviamente problematico per le persone cieche, poiché i lettori di schermo su cui si affidano non possono elaborare l’immagine, impedendo loro di recuperare le informazioni richieste dal modulo. Anche i CAPTCHA audio non funzionano per molte persone — la distorsione intenzionale li rende incomprensibili. La raccomandazione pratica: usa, quando possibile, sistemi di verifica invisibili basati sul comportamento come reCAPTCHA v3 o tecniche di honeypot.
• Elementi interattivi con comportamento inatteso — menu, tab, finestre di dialogo e widget personalizzati che non seguono i modelli consolidati di interazione da tastiera — sono subito dietro CAPTCHA. Questi elementi sono spesso costruiti con un eccesso di attributi ARIA e presentano comportamenti di interazione irregolari e problemi di compatibilità tra browser e lettori di schermo.
• Link e pulsanti ambigui frustrano costantemente le persone. Frasi come “clicca qui”, “scopri di più” o “leggi di più” non offrono alcun indizio sulla destinazione o sull’azione quando vengono ascoltate isolate in un elenco di link.
• Cambiamenti inattesi dello schermo — aggiornamenti dinamici del contenuto che avvengono senza preavviso — disorientano le persone cieche che non hanno alcun segnale visivo che qualcosa sia cambiato. Questo è particolarmente acuto nelle applicazioni a pagina singola costruite con React, Vue o Angular, dove il contenuto può cambiare senza un ricaricamento della pagina.
• Gerarchie di titoli interrotte compromettono la principale strategia di navigazione della maggior parte delle persone esperte. Circa il 39% dei siti web presenta gerarchie di titoli interrotte, rendendo difficile per chi usa lettori di schermo navigare correttamente tra i contenuti.
• Testo alternativo mancante o inadeguato per le immagini. Quando il testo alternativo è assente, un lettore di schermo può limitarsi a indicare la presenza di un’immagine senza descriverne il contenuto o — peggio — leggere un nome file privo di significato come “IMG_4823.jpg”.

La maggioranza — il 67% — delle persone che usano lettori di schermo non contatta mai o raramente i proprietari dei siti web per segnalare barriere. Semplicemente se ne va. Non riceverai un reclamo. Perderai semplicemente un utente.

Scrivere codice che i lettori di schermo possano davvero interpretare

Capire i modelli di navigazione delle persone rende i requisiti tecnici molto più concreti. Ogni decisione che prendi nel markup e in JavaScript ha una conseguenza diretta e udibile per le persone cieche. Ecco i principi che contano di più.

L’HTML semantico è il tuo primo e più potente strumento. La prima regola di ARIA afferma: “Se puoi usare un elemento o un attributo HTML nativo con la semantica e il comportamento di cui hai bisogno già integrati, invece di riutilizzare un elemento e aggiungere un ruolo, uno stato o una proprietà ARIA per renderlo accessibile, allora fallo.” Elementi come <button>, <nav>, <header> e <form> hanno l’accessibilità incorporata. Usare controlli nativi garantisce la compatibilità con browser e tecnologie assistive fin da subito, senza codice aggiuntivo.

ARIA è un supplemento, non un sostituto. ARIA (Accessible Rich Internet Applications) è un insieme di attributi HTML progettati per colmare le lacune di accessibilità laddove l’HTML da solo non può esprimere la semantica richiesta — ad esempio, rendere accessibile uno slider personalizzato, annunciare cambiamenti dinamici del contenuto o indicare che un menu a scomparsa è attualmente espanso. Il pericolo sta nell’uso improprio. Le home page che usano ARIA presentano in media più del doppio degli errori di accessibilità rispetto alle pagine senza ARIA. Più ARIA non significa più accessibile — spesso significa più errori. Le pagine che usavano ARIA in modo scorretto mostravano il 70% di errori rilevabili in più rispetto a quelle che non la usavano. Usala in modo chirurgico, dove nessun elemento nativo può svolgere il compito.

Il seguente esempio di codice illustra la differenza tra un pulsante personalizzato inaccessibile e uno correttamente accessibile:

<!-- Inaccessibile: un div con gestore di click, senza ruolo, senza supporto da tastiera -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Accessibile: pulsante nativo con ruolo integrato, supporto da tastiera e focus -->
<button type='submit'>Submit</button>

<!-- Se devi usare un elemento non pulsante, aggiungi ruolo, tabindex ed evento da tastiera -->
<div role='button' tabindex='0'
     aria-label='Submit the registration form'
     onkeydown='handleKey(event)'
     onclick='submitForm()'>
  Submit
</div>

Le regioni vive ARIA sono il meccanismo corretto per annunciare i cambiamenti dinamici del contenuto. Quando la tua pagina aggiorna il contenuto senza un ricaricamento completo — un messaggio di validazione di un modulo, il totale del carrello, una notifica — questo cambiamento è silenzioso per chi usa un lettore di schermo, a meno che tu non utilizzi una regione viva. L’attributo aria-live='polite' istruisce il lettore di schermo ad annunciare il cambiamento dopo che l’attività corrente dell’utente è terminata, mentre aria-live='assertive' interrompe immediatamente — usa quest’ultimo con parsimonia, solo per avvisi urgenti. Nel 2025, circa il 33% dei siti usa l’attributo aria-live, in aumento del 4% rispetto al 2024, ma l’adozione è ancora troppo bassa considerando quante interfacce dinamiche sono in circolazione.

La gestione del focus nei componenti interattivi — finestre di dialogo modali, menu a comparsa, accordion — deve essere gestita in modo esplicito. Quando si apre una modale, il focus deve spostarsi al suo interno. Quando si chiude, il focus deve tornare all’elemento che l’ha attivata. Una persona che usa un lettore di schermo e apre una modale, ma trova il focus ancora sul pulsante dietro di essa, è di fatto esclusa dal contenuto della finestra di dialogo.

Testare il tuo sito con un lettore di schermo

Gli scanner automatici di accessibilità sono preziosi ma limitati. Gli strumenti automatici intercettano il 30–40% delle violazioni WCAG, ma i test con tecnologie assistive reali rivelano come le persone sperimentano davvero il tuo sito — contesto mancante, navigazione confusa e interazioni che semplicemente non funzionano. Nessuno scanner ti dirà che il titolo della tua modale non ha senso senza il contesto visivo che la circonda, o che il tuo menu a discesa personalizzato annuncia il suo stato in modo errato in una combinazione browser–lettore di schermo ma non in un’altra.

Il punto di partenza pratico per la maggior parte dei team è NVDA con Firefox — gratuito, ampiamente utilizzato ed efficace per intercettare la grande maggioranza dei problemi comuni. Aggiungi VoiceOver con Safari per coprire le persone che usano macOS e iOS. Per contesti aziendali o clienti con requisiti di conformità elevati, includi JAWS con Chrome o Edge. Ogni lettore di schermo funziona al meglio con specifiche combinazioni di browser; usare la combinazione sbagliata può produrre risultati di test fuorvianti.

Durante i test, adotta i modelli di navigazione che le persone usano realmente. Non usare il mouse. Naviga tramite titoli usando il tasto H. Richiama l’elenco dei link e verifica che ogni link abbia senso fuori contesto. Spostati con Tab tra i campi dei moduli e controlla che ogni etichetta venga annunciata correttamente. Apri le finestre di dialogo modali e verifica che il focus si sposti al loro interno. Compila i moduli e inviali, ascoltando ogni messaggio di validazione. Spegni il monitor e prova a completare un’attività utente rappresentativa dall’inizio alla fine — quell’esperienza, per quanto scomoda per una persona vedente che testa, è la realtà quotidiana per le persone cieche che usano il tuo sito.

È anche importante testare con tecnologie assistive reali piuttosto che con emulatori o simulatori del browser. I pannelli di accessibilità degli strumenti di sviluppo del browser mostrano l’albero di accessibilità, il che è utile per il debug, ma non replicano l’esperienza uditiva né rivelano le particolarità di interazione che emergono solo con un software di lettura dello schermo reale.

Il caso aziendale e legale che non puoi ignorare

Se il caso morale per l’accessibilità ha bisogno di essere rafforzato con la realtà commerciale, i numeri sono chiari. Ci sono circa 7 milioni di persone con disabilità visive solo negli Stati Uniti, che rappresentano una base di consumatori significativa. A livello globale, il 26% degli adulti statunitensi ha disabilità, rappresentando un’opportunità di mercato stimata in 13 trilioni di dollari. Quando un design inaccessibile esclude le persone cieche dal tuo sito, non stai solo venendo meno a un obbligo morale — stai rifiutando clienti ed esponendo la tua organizzazione a rischi legali.

WCAG 2.2 è ora lo standard legale di riferimento in migliaia di cause ADA, e l’European Accessibility Act, entrato pienamente in vigore per le aziende del settore privato a giugno 2025, estende i requisiti di conformità in tutta l’UE. La maggior parte delle persone che usano lettori di schermo non contatta mai i proprietari dei siti web per segnalare barriere — semplicemente se ne va e porta altrove il proprio business. Il 67% delle persone che non segnala mai i problemi non è soddisfatto; è sconfitto. Integrare la compatibilità con i lettori di schermo nel tuo processo di sviluppo fin dall’inizio evita costosi interventi di correzione, riduce l’esposizione legale e apre i tuoi prodotti a un pubblico che sta attivamente cercando esperienze digitali che possa davvero usare.

Punti chiave

• I lettori di schermo navigano la struttura, non i contenuti visivi. Interrogano l’albero di accessibilità del browser tramite le API di accessibilità della piattaforma. L’HTML semantico — titoli corretti, landmark, controlli nativi — è l’investimento singolo con il maggiore impatto che puoi fare per la compatibilità con i lettori di schermo.
• Le persone cieche navigano tramite titoli, landmark ed elenchi di elementi — non in modo lineare. Oltre l’88% delle persone che usano lettori di schermo trova i livelli di titolo molto o abbastanza utili per la navigazione. Una gerarchia di titoli mancante o interrotta è uno dei fallimenti di accessibilità più comuni e dannosi sul web.
• ARIA amplifica sia il markup buono che quello cattivo. Le pagine che usano ARIA presentano in media più del doppio degli errori di accessibilità rispetto alle pagine che non la usano. Usa ARIA solo dove l’HTML nativo non può esprimere la semantica richiesta e testa sempre con tecnologie assistive reali dopo averla implementata.
• CAPTCHA, link ambigui e cambiamenti dinamici del contenuto non annunciati sono le barriere principali nel mondo reale. Sostituire i CAPTCHA visivi con verifiche basate sul comportamento, scrivere testi descrittivi per link e pulsanti e implementare regioni vive ARIA per gli aggiornamenti dinamici avrà un impatto immediato e misurabile sull’usabilità per le persone cieche.
• Testa con lettori di schermo reali su più combinazioni di browser. Gli scanner automatici intercettano solo il 30–40% delle violazioni WCAG. NVDA con Firefox e VoiceOver con Safari coprono la maggior parte della tua base di utenti a costo zero, e l’esperienza di navigare il tuo sito senza mouse rivela problemi che nessuno strumento automatico può far emergere.