Descrizione immagine: uno smartphone appoggiato su una scrivania di legno che mostra un’interfaccia di chat AI con delle cuffie collegate — il marcatore visivo del design di prompt AI compatibile con gli screen reader.

Tempo di lettura: 9 minuti

Una nuova disciplina di design si è cristallizzata all’interno della comunità dell’accessibilità negli ultimi diciotto mesi, e non ha ancora un nome consolidato. Alcuni team la chiamano «AT-aware prompt engineering»; altri la chiamano «screen-reader-shaped system prompts»; i professionisti che arrivano dal design di interfacce vocali tendono a chiamarla «lo strato di output vocale di un LLM». Qualunque sia l’etichetta, il mestiere è lo stesso: scrivere system prompt e regole di formattazione dell’output che rendano gli assistenti di IA generativa — ChatGPT, Claude, Gemini, Copilot, Be My AI — utili per le circa 253 milioni di persone nel mondo che accedono a questi prodotti attraverso uno screen reader.

Il problema è concreto e la modalità di errore è rumorosa. Un LLM addestrato sul web pubblico produce, per impostazione predefinita, prosa decorata con lineette em, elenchi markdown annidati, blocchi di codice, intestazioni che esistono solo perché il modello ha ritenuto che la risposta fosse «strutturata», ed emoji decorative. Letta ad alta voce da NVDA, JAWS, VoiceOver o TalkBack, quell’output diventa un flusso di intromissioni «trattino trattino», un’enumerazione «punto punto punto» senza alcun senso di dove finisce un elemento, annunci «titolo livello due» che interrompono una frase, e sequenze di nomi di emoji («faccina sorridente con occhiali da sole») tra ogni altra clausola. L’informazione c’è. L’utente non riesce a estrarla senza riascoltare tre volte. Questo articolo è una guida a ciò che la disciplina chiede ai costruttori di modelli, a ciò che i prodotti hanno già distribuito e ai problemi UX aperti che nessuno ha ancora risolto.

La nuova disciplina — in cosa consiste effettivamente

Il design di prompt consapevole degli screen reader non è un’unica regola. È un piccolo insieme di vincoli che, insieme, producono un output che un sintetizzatore vocale può pronunciare in modo intelligibile e attraverso il quale un tasto di navigazione dello screen reader può spostarsi. I vincoli rientrano in quattro categorie.

Risposte concise con struttura semantica. L’output LLM predefinito è troppo lungo per la fruizione orale — una risposta di 600 parole che si legge bene nel browser di un utente vedente diventa un monologo di quattro minuti che l’utente di screen reader non ha modo di scorrere velocemente. La disciplina chiede risposte più brevi, ma soprattutto risposte brevi strutturate: un riassunto di apertura in una frase al quale l’utente può fermarsi, seguito da una struttura che lo screen reader può navigare per intestazione o per elemento di elenco.

Evitare le lineette em e altri segni di punteggiatura che i sintetizzatori pronunciano in modo errato. La lineetta em, la lineetta en, il parentetico, la barra come congiunzione, il separatore ASCII — tutti questi vengono letti ad alta voce come silenzio, un letterale «trattino», o una pausa confusa che spezza una clausola a metà. La convenzione che si sta affermando tra i principali modelli è: preferire la virgola e il punto; usare i due punti nell’unico posto in cui guadagnano davvero il loro spazio; non usare mai le lineette em nelle risposte in contesto orale; non usare mai regole ASCII per separare le sezioni.

Dichiarare cosa è un elenco, cosa è un’intestazione, cosa è codice. Il parlato sintetizzato non ha gerarchia visiva. Un’intestazione deve essere annunciata come «intestazione», un elenco deve essere annunciato come «elenco con N elementi, elemento uno», il codice deve essere annunciato come «codice», e il modello deve o emettere strutture che lo screen reader riconosce (HTML, markdown corretto che la superficie di rendering converte in ARIA) oppure narrare verbalmente la struttura stessa («Ecco tre opzioni. Opzione uno: …»).

Niente zuppa di markdown. Il markdown va bene quando la superficie di rendering lo converte in HTML semantico. Il markdown è ostile quando la superficie mostra gli asterischi e i trattini bassi grezzi, perché lo screen reader annuncia allora «asterisco asterisco» prima di ogni parola in grassetto. La disciplina consiste nel rilevare il contesto di rendering — UI di chat con rendering markdown rispetto a terminale rispetto a interfaccia vocale guidata da screen reader — e nel modellare l’output di conseguenza. Lo stesso modello deve produrre diverse rappresentazioni superficiali della stessa risposta.

Cosa gli screen reader hanno realmente bisogno dall’IA

Per rendere concreti i vincoli sopra, è utile guardare al comportamento effettivo delle quattro combinazioni screen reader / sistema operativo che dominano il campo: JAWS su Windows, NVDA su Windows, VoiceOver su macOS e iOS, e TalkBack su Android. Non sono intercambiabili, e un prompt che produce un ottimo output per uno può essere illeggibile su un altro.

Navigazione per intestazione. Tutti e quattro i lettori espongono un tasto di navigazione per intestazione (H in JAWS e NVDA, Rotor in VoiceOver, il controllo di lettura in TalkBack). Affinché una risposta AI lunga sia navigabile, il modello deve emettere vere intestazioni semantiche — tramite una pipeline di rendering markdown che converte in <h2>/<h3> con nidificazione corretta dei livelli, o tramite l’API di risposta strutturata della superficie di chat. Un modello che «struttura» la propria risposta mettendo in grassetto le prime tre parole di ogni paragrafo ha prodotto qualcosa che appare strutturato visivamente ed è completamente piatto per uno screen reader.

Navigazione per elenco. Gli elenchi sono utili nell’output orale proprio perché lo screen reader annuncia il conteggio («elenco con sette elementi») e permette all’utente di spostarsi con il tasto di navigazione degli elementi dell’elenco (I in NVDA, L in JAWS). Ma questo funziona solo se l’elenco è un vero <ul> o <ol>. Un «elenco» prodotto emettendo caratteri bullet all’inizio di ogni riga, senza un elemento contenitore, viene letto come prosa ordinaria con un’intromissione di «cerchio nero» o «punto elenco» inspiegabile a ogni riga.

Salto per sezione. Le risposte AI in formato lungo — spiegazioni, comparazioni, codice con commenti, istruzioni a più passaggi — richiedono un modo per l’utente di screen reader di saltare alla sezione desiderata senza dover ascoltare il preambolo. Questo è il singolo aspetto più difficile da progettare bene, perché il modello deve produrre una struttura navigabile e la superficie di chat deve renderizzarla in un modo che il sistema operativo esponga alla tecnologia assistiva, e lo screen reader deve essere configurato per usare il tasto di navigazione per intestazione in quella superficie. Tutti e tre i requisiti falliscono nella pratica; di solito è il secondo.

Suggerimenti di pronuncia. Le voci sintetiche inciampano su termini tecnici, acronimi con lettere miste, URL, identificatori di codice, notazione matematica e nomi non inglesi. Un modello ben progettato, per le risposte in contesto screen reader, espanderà gli acronimi al primo utilizzo («WCAG, le Linee guida per l’accessibilità dei contenuti web»), espanderà le sigle che il sintetizzatore non riesce a pronunciare e eviterà di incorporare URL grezzi nella prosa scorrevole dove il sintetizzatore leggerà le barre ad alta voce. Nessuno dei prodotti principali lo fa in modo coerente nel 2026.

Come i prodotti stanno affrontando il problema

A metà del 2026, i principali prodotti di IA generativa hanno adottato posizioni visibilmente diverse sull’output consapevole degli screen reader. Nessuno di loro ha trovato la soluzione ottimale. La progressione è più rapida di quanto fosse dodici mesi fa, ma il divario tra il migliore e il peggiore è ancora ampio.

ChatGPT (OpenAI). Il client web ora include un toggle «modalità concisa» che accorcia le risposte predefinite e riduce la decorazione markdown. La modalità vocale introdotta nel 2024 — e sostanzialmente aggiornata nel 2025 — è la più vicina che qualsiasi prodotto principale abbia raggiunto a un’interfaccia nativa per screen reader, perché bypassa completamente la chat visiva e fornisce una risposta orale con un gesto per fermarsi, riprodurre e «ripeti». Il campo delle istruzioni personalizzate permette agli utenti di screen reader di dichiarare le proprie preferenze una volta sola e applicarle in tutte le sessioni, che è il compromesso guidato dall’utente su cui la comunità si è assestata. I gap rimanenti: i modelli GPT ancora producono per impostazione predefinita prosa ricca di lineette em a meno che non si indichi diversamente, e il livello di intestazione emesso in markdown non sempre si mappa correttamente in ARIA nella superficie di chat.

Claude (Anthropic). La disciplina dei system prompt di Claude si è avvicinata di più alle convenzioni descritte sopra. Il modello è notevolmente meno incline alle lineette em rispetto alla linea GPT nel 2026, produce per impostazione predefinita risposte più brevi e risponde bene alle istruzioni nel system prompt come «stai parlando a un utente di screen reader; non usare lineette em, preferisci paragrafi brevi e usa vere intestazioni o elenchi numerati quando è necessaria una struttura». La superficie di chat Claude.ai renderizza il markdown in HTML semantico con livelli di intestazione corretti, il che fa funzionare il tasto di navigazione per intestazione. L’output vocale tramite integrazioni di terze parti esiste ma è meno sviluppato della modalità vocale first-party di ChatGPT.

Gemini (Google). La stretta integrazione con TalkBack su Android è il vantaggio strutturale di Gemini; il modello può trasferire il controllo allo screen reader a livello di sistema operativo tramite i servizi di accessibilità di Android in un modo che i concorrenti su iOS e web non possono. Il flusso «Hey Google, chiedi a Gemini…» sui dispositivi Android accessibili è, per alcuni utenti, l’esperienza IA-più-screen reader più naturale disponibile. I gap rimanenti: l’interfaccia web ancora produce risposte sovra-decorate, la gerarchia delle intestazioni nelle risposte web di Gemini è inconsistente e il modello è più incline a produrre emoji decorative rispetto ai suoi concorrenti.

Be My AI (Be My Eyes + OpenAI). È il più circoscritto dei quattro — un assistente di descrizione visiva che usa modelli vision di classe GPT-4 per descrivere immagini e ambienti a utenti non vedenti e ipovedenti. È anche l’unico prodotto in questo elenco progettato sin dal primo giorno per l’utente di screen reader come pubblico primario. Il design del prompt di Be My AI è la dimostrazione più chiara del campo di come appaia in pratica l’output AT-aware: le descrizioni si aprono con un riassunto in una frase al quale l’utente può fermarsi, seguono con dettagli strutturati solo se richiesto, e evitano il linguaggio spaziale («a sinistra», «sopra») che richiede un contesto visivo per essere interpretato. Il prodotto rimane, nel 2026, la cosa più vicina a un’implementazione di riferimento nel settore.

L’osservazione trasversale è che i quattro prodotti hanno fatto progressi sulle parti facili — risposte più brevi, meno lineette em, un campo per le istruzioni personalizzate — e hanno a malapena iniziato sulle parti difficili. Le parti difficili sono di seguito.

Problemi UX aperti che nessuno ha risolto

La letteratura sul design di prompt consapevole degli screen reader converge su quattro problemi UX aperti per i quali la risposta giusta non è ancora nota. Nessuno di essi è un problema di capacità del modello; tutti sono problemi di design dell’interazione che si collocano tra l’LLM, la superficie di chat, il sistema operativo e lo screen reader.

Interrompibilità. Un utente vedente può scansionare una risposta LLM in circa due secondi e decidere se leggerla. Un utente di screen reader non può. Se la risposta è sbagliata o fuori bersaglio, l’utente deve ascoltarne abbastanza da saperlo, poi interrompere. Le modalità vocali hanno un pulsante di stop. Le modalità testuali generalmente no — la risposta viene trasmessa in streaming e lo screen reader la annuncia come nuovo contenuto man mano che arriva, e l’utente non ha modo pulito di dire «smetti di generare, non è quello che ho chiesto». L’app Be My AI gestisce questo aspetto nel modo migliore; i client web di chat nel modo peggiore.

Ripetizione dell’ultima risposta con granularità selezionabile. Chiedere a uno screen reader di rileggere l’ultima risposta è facile se la risposta è breve. È inutilizzabile se la risposta è di sei paragrafi e l’utente vuole sentire solo il terzo paragrafo di nuovo. L’interazione che la comunità chiede è «ripeti l’ultimo elemento dell’elenco», «ripeti la sezione dell’ultima intestazione», «ripeti l’ultimo blocco di codice». Questo richiede che la superficie di chat esponga la struttura allo screen reader in un modo in cui i comandi di rilettura dello screen reader possano indirizzarla. Nel 2026, nessuno dei prodotti principali lo fa; l’utente deve usare la propria navigazione riga per riga dello screen reader, che è laboriosa.

Navigazione per sezione nell’output orale. Le modalità vocali non hanno un tasto di navigazione per intestazione. L’utente ascolta linearmente una risposta di quattro minuti, senza modo di saltare dalla sezione «panoramica» alla sezione «specifiche» senza riavvolgere nel tempo. I design di interazione in fase di prototipazione — un «elenco di sezioni» orale che l’utente può navigare con i tasti freccia, un comando vocale «vai alla sezione tre», una modalità «dammi solo le intestazioni» — sono ancora nelle fasi iniziali. Il follow-up «ulteriori dettagli sui colori» dell’app Be My AI è la versione funzionante più vicina in un prodotto distribuito.

La questione dell’handoff AT — quando parla l’IA rispetto a quando legge il contenuto ad alta voce? Questa è la domanda di design più profonda. Se un utente di screen reader apre un assistente AI su una pagina web, chi sta parlando — la voce propria dell’IA (strato TTS), oppure lo screen reader installato dell’utente che legge l’output testuale dell’IA? Le due voci hanno impostazioni diverse, velocità di dizione diverse, suggerimenti di pronuncia diversi, gesti diversi per fermarsi e riprodurre. Due sistemi che cercano di pronunciare lo stesso contenuto contemporaneamente non producono nulla di utilizzabile. La convenzione emergente è: le interazioni in modalità vocale usano il TTS proprio dell’IA e sopprimono esplicitamente lo screen reader; le interazioni in modalità testo emettono HTML semantico e lasciano parlare lo screen reader. Ma il confine tra le due modalità non è sempre netto — la descrizione di immagini, la generazione di codice, la notazione matematica e le risposte multimodali si collocano in modo scomodo tra voce e testo — ed è proprio questo confine dove vivono la maggior parte dei problemi UX aperti.

Dove va questa disciplina

La disciplina è all’incirca dove si trovava l’accessibilità web circa nel 2002 — superata la fase «è un problema reale?», superata la fase «chi è responsabile?», dentro la fase «quali sono le regole effettive?». Tre cose probabilmente accadranno nel corso del 2026 e del 2027.

Primo, i costruttori di modelli codificheranno i propri prompt interni per screen reader e li pubblicheranno, come Anthropic pubblica i system prompt di Claude nelle dichiarazioni di accessibilità in stile VPAT e come OpenAI ha iniziato a documentare le impostazioni predefinite comportamentali di GPT. La comunità chiede l’equivalente di una model card — una «screen-reader output card» — che nomini le convenzioni che un dato modello è stato addestrato o istruito tramite system prompt a seguire.

Secondo, le superfici di chat — client web, app mobili, integrazioni IDE — acquisiranno pipeline di rendering HTML semantico corrette ed esposizione ARIA corretta per la cronologia della chat, con i tasti di navigazione mappati allo screen reader a livello di sistema operativo. Questo è un lavoro poco appariscente, ed è il lavoro che farà la differenza maggiore per gli utenti quotidiani.

Terzo, i produttori di screen reader stessi — Vispero (JAWS), NV Access (NVDA), Apple (VoiceOver), Google (TalkBack) — inizieranno a distribuire funzionalità compatibili con l’IA: navigazione nativa per intestazione all’interno delle superfici di chat AI, un gesto standardizzato «interrompi la generazione», comandi di rilettura più intelligenti che conoscono la struttura delle risposte LLM. L’ecosistema di add-on open source di NVDA sta già producendo versioni preliminari di questi. I lettori proprietari sono più lenti ma la direzione è la stessa.

L’osservazione più profonda è che il design di prompt consapevole degli screen reader ha smesso di essere una preoccupazione di nicchia di una manciata di sviluppatori non vedenti ed è diventato un’aspettativa di base di ogni team di prodotto AI che voglia distribuire in mercati regolamentati. L’European Accessibility Act si applica ai «terminali self-service interattivi» e alle «apparecchiature terminali per i consumatori con capacità di calcolo interattiva» — una categoria che quasi certamente include un assistente AI principale su un telefono. Lo strato di output AT-aware non è più una funzionalità; è vincolante per gli appalti. I team che si impadroniscono delle regole ora distribuiranno i prodotti che sopravviveranno al 28 giugno 2025 e oltre. I team che lo trattano come un ripensamento saranno il prossimo round di casi di enforcement EAA.

Considerazioni finali

Il mestiere è piccolo, le poste in gioco sono grandi e le regole sono ancora in fase di scrittura. Se si lavora con gli LLM e non si è ancora avuta una conversazione con un utente di screen reader su come appare effettivamente il proprio prodotto quando lo usa, quello è il prossimo punto in agenda. La maggior parte di ciò che non va nell’IA per gli utenti di screen reader nel 2026 non è un problema di capacità del modello; è un problema di design di prompt e superficie che qualsiasi team di prodotto può risolvere in un ciclo di sviluppo, se decide di farlo.

La comunità è stata generosa con il suo tempo, i suoi test e la sua pazienza. Sta anche perdendo la pazienza più in fretta di prima, perché i prodotti sono ormai mainstream e la scusa «stiamo ancora capendo come fare» è finita. La disciplina esiste. Le convenzioni stanno convergendo. I prossimi diciotto mesi faranno emergere i team che hanno ascoltato da quelli che non lo hanno fatto.