Descrizione immagine: una sala conferenze con una diapositiva proiettata e un laptop che mostra la struttura dell’ordine di lettura del deck — il marcatore visivo per la produzione di presentazioni accessibili.

Tempo di lettura: 12 minuti

Le slide deck rimangono il singolo artefatto educativo più condiviso nella vita professionale moderna — appunti di lezione, aggiornamenti per il board, moduli di formazione, talk a conferenze, assemblee aziendali interne. Sono anche, quasi senza eccezioni, l’artefatto meno accessibile nella stessa pipeline. Un talk che gli screen reader non riescono a navigare, un deck i cui valori grafici esistono solo come pixel, un video incorporato senza sottotitoli, un’interazione «clicca per avanzare» che ignora la tastiera: ognuno di questi problemi è routine, e ognuno di essi esclude silenziosamente lo stesso gruppo di persone dagli stessi contenuti che il resto del pubblico riceve. La buona notizia è che risolvere questo problema nel 2026 non è più una questione di ricerca. È un problema di flusso di lavoro produttivo con tre buone soluzioni e un albero decisionale che sceglie tra esse.

Questo primer tratta le tre famiglie di strumenti che un presentatore effettivamente ha sul proprio desktop — Microsoft PowerPoint, Apple Keynote e Google Slides — oltre alla sempre più seria alternativa web-first (Reveal.js, Slidev, Marp) che docenti e organizzatori di conferenze hanno iniziato a preferire. Non è un confronto di funzionalità in astratto. È una guida pratica: quali passi compiere, in quale ordine, in quale strumento, per pubblicare un deck che uno studente non vedente può seguire con NVDA, un collega ipovedente può leggere al 400% di zoom, un partecipante sordo può leggere con i sottotitoli incorporati e un utente solo-tastiera può navigare senza mai toccare il mouse. Per il contesto normativo più ampio, consultare il nostro primer sull’adozione di WCAG 2.2 e sull’European Accessibility Act, entrambi applicabili ora ai contenuti educativi e commerciali basati su slide distribuiti online.

Cosa serve a un deck accessibile

Prima dei flussi di lavoro specifici per strumento, una base di partenza. Un deck accessibile ha sei elementi che funzionano contemporaneamente, e nessuno di essi è opzionale. Il primo è un titolo univoco e descrittivo su ogni diapositiva — è quello che un utente di screen reader usa per navigare da diapositiva a diapositiva, e su cui fa affidamento chi usa il pannello del sommario per trovare la diapositiva che sta cercando. Le diapositive intitolate «Diapositiva 4» o «Senza titolo» non sono navigabili. Il secondo è un ordine di lettura corretto. Le diapositive costruite trascinando forme su una canvas senza usare i segnaposto avranno un ordine di lettura che corrisponde all’ordine in cui le forme sono state inserite, non all’ordine visivo — il che significa che uno screen reader leggerà una diapositiva al contrario, prima della barra laterale, con il piè di pagina prima del titolo, o in qualunque sequenza abbia prodotto il processo di produzione. Il terzo è un testo alternativo per ogni immagine, grafico e diagramma non decorativo, scritto in un linguaggio che trasmetta il punto che l’immagine fa, non solo la sua descrizione superficiale.

Il quarto è un contrasto cromatico sufficiente — testo sugli sfondi delle diapositive alla soglia AA di WCAG 2.2 (4,5:1 per il corpo del testo, 3:1 per il testo grande e le grafiche significative), verificato rispetto ai pixel effettivi dello sfondo piuttosto che al master della diapositiva. Il quinto è la navigabilità da tastiera — ogni elemento interattivo che un presentatore si aspetta che il pubblico utilizzi successivamente (link a sondaggi incorporati, navigazione a diramazione, moduli incorporati) deve essere raggiungibile e utilizzabile con Solo Tab, Invio, Spazio ed Esc. E il sesto è la gestione dei media — ogni video incorporato ha sottotitoli aperti bruciati nel file o una traccia di sottotitoli chiusi che il player può attivare; ogni clip audio incorporata ha una trascrizione raggiungibile dalla stessa diapositiva; ogni animazione non strettamente necessaria rispetta le preferenze di riduzione del movimento dell’utente a livello di sistema operativo.

Ciascuno dei tre strumenti desktop fornisce un sottoinsieme di questi sei elementi. Nessuno di essi li fornisce tutti automaticamente. Scegliere lo strumento giusto significa capire cosa si deve fare manualmente in ciascuno.

Flusso di lavoro PowerPoint

PowerPoint ha gli strumenti di accessibilità più maturi di qualsiasi app di presentazione sul mercato, e questo vale fin dall’inizio del ciclo di rilascio di Microsoft 365 che ha integrato il Verifica Accessibilità nella barra multifunzione. Il punto di partenza è il checker stesso, aperto dalla scheda Revisione in Windows o dal menu Strumenti su macOS. Espone un elenco live e contestuale di problemi — diapositive senza titoli, immagini senza testo alternativo, combinazioni di testo a basso contrasto, tabelle senza intestazioni, collegamenti ipertestuali il cui testo visibile duplica l’URL — e facendo clic su qualsiasi problema il cursore salta all’elemento in questione. Il checker viene eseguito ad ogni salvataggio per impostazione predefinita nelle versioni attuali, che è la singola impostazione predefinita più utile che Microsoft abbia mai introdotto in questo prodotto. Disattivarla solo dopo aver capito quali avvisi si sceglie di ignorare.

I titoli delle diapositive sono gestiti attraverso la Visualizzazione struttura (Visualizza, Struttura) e tramite il segnaposto Titolo del master della diapositiva. L’utilizzo del segnaposto anziché di una casella di testo fluttuante è ciò che conferisce al titolo il suo ruolo semantico — sia il Verifica Accessibilità che gli screen reader a valle identificano le diapositive con titolo tramite l’identità del segnaposto, non tramite il testo visibile. Se i titoli del deck sono composti tipograficamente usando caselle di testo fluttuanti per ragioni di design, è possibile mantenere il design ma aggiungere un titolo segnaposto invisibile spostando il segnaposto fuori dalla canvas (Riquadro di selezione, impostare la posizione a coordinate negative) — il titolo esiste ancora nell’albero di accessibilità e conta per la navigazione dello screen reader, anche se il pubblico non lo vede mai. La documentazione Microsoft descrive questo come il pattern «titolo fuori diapositiva»; il checker lo accetta.

L’ordine di lettura è il secondo pilastro. Aprire il Riquadro di selezione (Home, Disponi, Riquadro di selezione in Windows; menu Disponi su macOS) e leggere l’elenco di forme dal basso verso l’alto — questo è l’ordine in cui uno screen reader le incontrerà. Trascinare le forme all’interno del riquadro per riordinarle. PowerPoint 2024 ha aggiunto un Riquadro ordine di lettura dedicato che visualizza l’ordine numericamente su ogni forma della diapositiva e consente di riordinare tramite drag-and-drop direttamente sulla canvas; se la propria versione di Microsoft 365 è abbastanza aggiornata da mostrare quel riquadro, usarlo.

Il testo alternativo sulle immagini si imposta facendo clic destro sull’immagine, scegliendo Modifica testo alternativo e scrivendo una o due frasi di alt editoriale — il punto dell’immagine, non il suo contenuto in pixel. Il testo alternativo autogenerato di PowerPoint è opt-in ed è etichettato come tale nel riquadro; è un punto di partenza, non un prodotto finito, e il checker avviserà se si pubblica una diapositiva in cui l’unico testo alternativo è «Descrizione generata automaticamente». Per i grafici creati in PowerPoint, il testo alternativo deve riassumere l’argomento del grafico in una frase e citare i due o tre valori principali — «Grafico a barre che mostra la partecipazione a conferenze nel 2026 in aumento del 18% rispetto al 2025, guidata da EMEA e APAC» è meglio di «Grafico a barre». Per le diapositive con molti dati, si consiglia di includere i dati sottostanti come tabella nascosta ma raggiungibile nelle note del relatore, o come foglio di calcolo collegato in appendice, in modo che un utente di screen reader possa leggere i numeri oltre all’essenza del grafico.

Il video incorporato è il singolo fallimento di conformità più comune nei deck PowerPoint. Il flusso di lavoro Inserisci, Video, Inserisci sottotitoli accetta file WebVTT (.vtt) e li vincola alla clip incorporata; una volta allegati, i sottotitoli vengono resi nel player integrato di PowerPoint e viaggiano con il file quando il deck viene condiviso, inviato via email o caricato. Se il video sorgente ha sottotitoli aperti bruciati, il checker segnala comunque il file come bisognoso di una traccia di sottotitoli — aggiungere comunque un VTT minimale, perché il file è ciò che leggeranno gli strumenti a valle. I collegamenti ipertestuali dovrebbero avere testo visibile che descriva la destinazione («Leggi il rapporto sull’applicazione EAA 2026»), non l’URL nudo.

La pipeline di esportazione di PowerPoint preserva la maggior parte dei metadati di accessibilità quando si esporta in PDF — a condizione di usare File, Esporta, Crea PDF/XPS (Windows) o File, Salva con nome, PDF con l’opzione Ideale per distribuzione elettronica e accessibilità selezionata (macOS). L’esportazione tramite Stampa in PDF elimina i tag e produce un PDF piatto non accessibile; questo è il fallimento silenzioso più comune dell’intero flusso di lavoro.

Flusso di lavoro Keynote

Keynote viene fornito con strumenti di accessibilità sostanzialmente inferiori a PowerPoint, e il divario non si è ridotto significativamente dall’uscita del ciclo di rilascio 13.x. Non esiste un equivalente del Verifica Accessibilità — Keynote non esegue un audit diapositiva per diapositiva, non mostra un riquadro dell’ordine di lettura per diapositiva e non avvisa l’utente quando una diapositiva è priva di titolo. Le diapositive stesse hanno un’integrazione VoiceOver più forte rispetto a PowerPoint di un decennio fa, ma il flusso di lavoro di produzione per ottenere un deck accessibile da Keynote è più manuale in ogni passaggio.

I titoli delle diapositive vengono aggiunti tramite il segnaposto Titolo nel master della diapositiva o come casella di testo normale usata in modo coerente nell’intero deck. La visualizzazione struttura di Keynote (Visualizza, Struttura) legge dal segnaposto Titolo, quindi la costruzione di deck partendo dal master anziché da diapositive vuote è il singolo punto di leva più importante. L’ordine di lettura è gestito tramite l’ispettore Disponi — i controlli Dietro/Davanti nel modello di impilamento di Keynote fungono anche da controlli dell’ordine di lettura, con le forme spostate più indietro che vengono lette per prime. Non esiste un riquadro dedicato all’ordine di lettura; è necessario tenere un modello mentale dello stack, o costruire diapositive complesse partendo da una base nota corretta.

Il testo alternativo delle immagini in Keynote si imposta tramite il campo Descrizione nella scheda Immagine dell’ispettore Formato — scrivere lo stesso alt editoriale che si userebbe in PowerPoint. Il testo alternativo dei grafici usa lo stesso meccanismo. Keynote non avvisa dell’assenza di testo alternativo. L’unico modo per verificare la copertura del testo alternativo di un deck in Keynote è esaminare ogni diapositiva manualmente, oppure esportare in formato PowerPoint (.pptx) ed eseguire il Verifica Accessibilità di Microsoft sull’esportazione — un flusso di lavoro adottato da diverse grandi università come fase di gating per i deck delle lezioni creati in Keynote.

Il video incorporato in Keynote non supporta una traccia di sottotitoli separata. Se il video sorgente non ha sottotitoli aperti bruciati, è necessario ri-codificare il video con i sottotitoli incorporati prima di inserirlo in Keynote, oppure sostituire l’elemento incorporato con un riferimento esterno che punta a un video con sottotitoli ospitato su una piattaforma con supporto ai sottotitoli (YouTube, Vimeo, il server media dell’istituzione). Keynote includerà silenziosamente video senza sottotitoli in un PDF esportato; il checker che non esiste non può avvisare di questo.

Dove Keynote guadagna il suo posto è nei deck con design ricercato, creati per talk da keynote piuttosto che per la redistribuzione. La qualità della tipografia, del layout e dell’animazione rimane la migliore sul mercato delle presentazioni desktop — quando il deck è essenzialmente un supporto visivo per il palco e il contenuto sostanziale vive in un documento separatamente distribuito, Keynote produce un’esperienza dal vivo più ricca e il carico di accessibilità si sposta sul documento di accompagnamento. Se il deck stesso è il deliverable, PowerPoint è la scelta migliore.

Flusso di lavoro Google Slides

Google Slides ha migliorato sostanzialmente dopo l’aggiornamento all’accessibilità del 2024 che ha aggiunto un menu di accessibilità per diapositiva, suggerimenti di testo alternativo basati su modelli di immagine di classe Gemini e un overlay di verifica del contrasto accessibile da Strumenti, Accessibilità. L’aggiornamento del 2024 ha anche aggiunto controlli dell’ordine di lettura al menu Disponi — per la prima volta nella storia del prodotto, gli autori di Slides possono impostare un ordine di lettura esplicito invece di affidarsi all’ordine di creazione delle forme. L’adozione di queste funzionalità all’interno dei grandi tenant aziendali è stata più rapida di quanto Microsoft si aspettasse inizialmente, in parte perché i deck Slides sono già prevalentemente ospitati nel cloud e beneficiano immediatamente del checker lato server.

La meccanica è familiare a chiunque venga da PowerPoint. I titoli sono gestiti tramite il segnaposto Titolo del layout master. Il testo alternativo si imposta tramite Opzioni formato, Testo alternativo, con la stessa regola editoriale di una o due frasi. L’ordine di lettura usa il menu Disponi, Ordine, con il nuovo riquadro dell’ordine di lettura del 2024 visibile da Strumenti, Accessibilità, Ordine di lettura. L’incorporazione di video da Google Drive o YouTube rispetta qualsiasi traccia di sottotitoli portata dalla sorgente, e una diapositiva contenente un video senza sottotitoli solleva un avviso nel riquadro di accessibilità.

Dove Slides rimane ancora indietro rispetto a PowerPoint è nell’accessibilità dei grafici (il testo alternativo autogenerato per i grafici è più breve e meno consapevole del contesto), nell’ereditarietà di master complessi (i layout master ampiamente personalizzati producono alberi dell’ordine di lettura più difficili da debuggare) e nei flussi di lavoro offline (il checker di accessibilità richiede che il documento sia online, il che è un problema per gli utenti che modificano su aerei o in ambienti con restrizioni). Per un’azienda del 2026 che ha standardizzato su Workspace e distribuisce deck principalmente come link di Google Slides condivisi piuttosto che come file scaricati, il flusso di lavoro di Slides è ora sostanzialmente comparabile a PowerPoint. Per un’organizzazione che distribuisce deck come allegati .pptx o come PDF esportati, PowerPoint ha ancora il vantaggio.

Deck web-first: Reveal.js, Slidev, Marp

Lo sviluppo più interessante nell’accessibilità delle presentazioni nel 2025 e nel 2026 è avvenuto al di fuori delle tre grandi app desktop. Un cluster di framework di presentazione web-first — Reveal.js (il framework JavaScript di lunga data), Slidev (uno strumento basato su Vue orientato agli sviluppatori) e Marp (un generatore Markdown-first che compila in HTML, PDF o PPTX) — produce deck come documenti HTML, il che significa che le proprietà di accessibilità dell’HTML vengono ereditate anziché emulate. La struttura semantica è reale, non sintetizzata; la navigazione da tastiera è quella del browser, non dell’app di presentazione; e l’output degli screen reader è quello che NVDA, JAWS o VoiceOver produrrebbero per qualsiasi pagina web ben costruita.

Le implicazioni sono pratiche. Un deck Reveal.js servito da un URL è, per impostazione predefinita, navigabile con i tasti freccia, Tab, Invio, Spazio e le stesse scorciatoie del browser che un utente vedente già conosce. Ogni diapositiva è un elemento section con un titolo — H1 per il deck, H2 per ogni titolo di diapositiva — quindi un utente di screen reader può saltare da titolo a titolo come farebbe su qualsiasi pagina web. Le immagini portano attributi alt scritti nel sorgente Markdown o HTML. I grafici resi con Chart.js, D3 o qualsiasi libreria SVG portano i ruoli ARIA e gli annunci aria-live che la libreria espone; per le librerie di grafici accessibili come Highcharts Accessibility o amCharts, questo include tabelle di dati leggibili dagli screen reader generate automaticamente accanto al grafico visivo.

Il pubblico orientato agli sviluppatori di Slidev ha prodotto un insieme di impostazioni predefinite di accessibilità insolitamente solido: semantica dei titoli ereditata da Markdown, testo alternativo richiesto a livello di file sorgente (il compilatore avvisa sui tag di immagine nudi) e un livello di navigazione da tastiera che funziona senza configurazione. Il punto di forza di Marp è nei deck in Markdown puro compilati in HTML o PDF — la stessa sorgente produce sia un deck web navigabile dagli screen reader sia un PDF con tag, senza un secondo passaggio di authoring. Reveal.js si colloca tra i due: il più flessibile, l’ecosistema di plugin più grande, il pool più profondo di plugin di accessibilità di terze parti (Reveal Accessibility, reveal-a11y, il tema pubblicato conforme a WCAG 2.2).

I compromessi sono reali. I deck web-first richiedono un browser per la presentazione — nessun doppio clic su file locale, nessun flusso di lavoro email-il-pptx, nessun fallback offline su laptop che non richieda configurazione. Premiano gli autori a loro agio con il controllo versione e il deployment continuo; penalizzano gli autori che vogliono trascinare un grafico da Excel in una diapositiva e considerarsi a posto. Per un singolo talk condiviso come URL dopo l’evento, questo è un chiaro vantaggio. Per un aggiornamento trimestrale del board che verrà inviato via email a un dirigente che lo aprirà su un aereo, questo è lo strumento sbagliato.

Dove i deck web-first hanno iniziato a prevalere è nei contesti ricorrenti. Serie di lezioni universitarie che pubblicano l’intero semestre di slide come un unico sito navigabile. Programmi di conferenze dove ogni deck del talk è collegato alla scaletta e vive a un URL permanente. Tech talk ingegneristici dove il repository sorgente è esso stesso la versione di riferimento. In ciascuno di questi contesti le semantiche HTML sopravvivono — i motori di ricerca indicizzano il contenuto della diapositiva come testo, gli screen reader lo attraversano come documento e il carico di manutenzione per rimanere accessibili nell’arco della serie ricade sul framework piuttosto che su ogni singolo autore.

Un albero decisionale

Le tre famiglie di strumenti guadagnano ciascuna il proprio posto in un contesto di produzione diverso. La versione più semplice della decisione è una suddivisione in tre parti basata su ciò per cui il deck viene effettivamente utilizzato.

Per un talk una tantum che deve essere inviato via email, aperto sul laptop di un collega o esportato in un PDF con tag per la distribuzione, scegliere PowerPoint. Il Verifica Accessibilità è maturo, la pipeline di esportazione preserva i tag e gli strumenti lato pubblico (il visualizzatore web di PowerPoint, l’app iPad, il lettore Office Mobile) leggono tutti correttamente i file PowerPoint con tag. Prevedere novanta minuti di tempo di audit per ogni deck della durata di un’ora; pianificare il tempo e usarlo.

Per una serie di lezioni ricorrente, un programma di conferenze o qualsiasi contesto in cui la raccolta di deck vive a un URL e viene esplorata come corpus, scegliere un framework web-first. Slidev per i pubblici orientati agli sviluppatori e gli autori a proprio agio con Markdown; Marp per i team in Markdown puro che hanno bisogno sia di HTML che di PDF con tag dalla stessa sorgente; Reveal.js per il maggior ecosistema di plugin e la massima flessibilità di design. Le proprietà di accessibilità sono ereditate dal browser, non emulate, e il carico di manutenzione ricade sul framework piuttosto che su ogni autore.

Per un talk keynote ricco di design in cui il deck funziona come supporto visivo per il palco e il contenuto sostanziale vive in un documento distribuito separatamente, scegliere Keynote, accettare gli strumenti di accessibilità più limitati e investire il budget di audit nel documento di accompagnamento. Esaminare ogni diapositiva manualmente per il testo alternativo. Esportare in .pptx ed eseguire il checker come passaggio finale. Distribuire il documento di accompagnamento (un articolo, una trascrizione, un riepilogo web) come versione accessibile canonica.

Per le organizzazioni collaborative cloud-first già operanti in Google Workspace che distribuiscono deck principalmente come link condivisi anziché come file scaricati, Google Slides è ora una valida alternativa a PowerPoint per gli stessi casi d’uso. L’aggiornamento all’accessibilità del 2024 ha colmato la maggior parte del divario storico; i divari rimanenti riguardano il testo alternativo dei grafici, i master complessi e la modifica offline.

Considerazioni finali

Il pattern alla base di ogni raccomandazione in questo primer è lo stesso: lo strumento imposta il pavimento di accessibilità, ma l’autore imposta il soffitto. Il checker di PowerPoint rileverà il testo alternativo mancante; non scriverà un testo alternativo utile al suo posto. La mancanza di un checker in Keynote non impedirà di creare un deck completamente accessibile — impedirà solo di essere avvisati quando si è fallito. I framework web-first ereditano le proprietà di accessibilità dell’HTML — non le impongono. Ogni strumento in questa guida consentirà di pubblicare un deck che esclude parte del proprio pubblico. La scelta dello strumento cambia quali errori è facile commettere, non quali errori sono possibili.

Se si sta introducendo un nuovo flusso di lavoro di accessibilità in un team che non ne ha uno, iniziare con lo strumento che il team già usa, attivarne il checker e verificare un deck esistente rispetto ad esso come esercizio di calibrazione. Passare a uno strumento diverso solo dopo che il team ha interiorizzato i sei requisiti di base — titoli, ordine di lettura, testo alternativo, contrasto, tastiera, media — e sta chiedendo capacità che lo strumento attuale non può fornire. Il costo di cambiare strumenti a metà percorso è alto; il costo di rimanere su uno strumento di cui si è superato il flusso di lavoro è ancora più alto.