La decisione che influenza ogni passaggio successivo è l’ambiente di authoring. Un PDF generato da un documento InDesign correttamente strutturato con l’azione Rendi accessibile applicata porta già l’80 percento dei metadati di accessibilità prima che qualcuno apra Acrobat. Un PDF esportato da un documento Word in cui i titoli erano simulati con testo in grassetto e di dimensioni maggiori non ne porta quasi nessuno, e nessuna rimediazione successiva riuscirà a recuperarlo completamente. La scelta dello strumento di authoring, in altre parole, non è estetica. È strutturale.

Tre percorsi di produzione dominano la pubblicazione istituzionale nel 2026. Adobe InDesign con l’azione Rendi accessibile è lo standard per i documenti tipografici — relazioni annuali, libri di testo, fascicoli normativi — dove il layout è fisso e il file lascia il team di design una volta sola. Microsoft Word con Salva come PDF accessibile è lo strumento per i documenti d’ufficio — policy, contratti, lettere — dove il sorgente viene modificato continuamente e il PDF è una resa piuttosto che una destinazione. LibreOffice con il passaggio al PDF Accessibility Checker è il percorso open source utilizzato da governi e università che hanno ragioni di policy per evitare i software Microsoft e Adobe.

Sotto ogni PDF accessibile c’è una struttura logica parallela — l’albero dei tag — che non ha nulla a che vedere con il layout visivo. Il PDF visibile è un insieme di istruzioni di disegno indirizzate per coordinate. L’albero dei tag è un modello a oggetti documento gerarchico separato che dice questa operazione di disegno è il primo titolo, quella è il terzo punto della seconda lista, questa immagine è decorativa, quella ha il testo alternativo «Ricavi trimestrali per segmento, FY24». Uno screen reader legge l’albero dei tag, non il disegno.

Sei categorie di tag portano la maggior parte del significato nei documenti reali: i titoli (H1-H6) formano la struttura navigabile; i paragrafi (P) sono il testo; le liste (L, LI, Lbl, LBody) sono le enumerazioni ordinate o non ordinate; le tabelle (Table, TR, TH, TD) sono le griglie di dati con le intestazioni di colonna e riga esposte tramite l’attributo Scope; le figure (Figure) portano il testo alternativo nel loro attributo Alt o ActualText; e l’ordine di lettura, che è l’attraversamento in profondità dell’albero stesso, stabilisce la sequenza in cui uno screen reader parla il documento. Una pagina che sembra corretta su due colonne può essere letta nell’ordine sbagliato se l’albero dei tag mette la colonna destra prima di quella sinistra.

Altri due attributi sono importanti su ogni tag in un file correttamente prodotto. L’attributo di lingua (Lang) indica allo screen reader quale dizionario di pronuncia utilizzare — il francese citato in un paragrafo in italiano ha bisogno del proprio attributo Lang su un tag Span, altrimenti verrà letto con la fonetica italiana. E il marcatore di artifact distingue il contenuto decorativo da quello strutturale; intestazioni, piè di pagina, numeri di pagina e linee decorative devono essere marcati come artifact affinché lo screen reader li salti.

PDF/UA è lo standard internazionale per i PDF accessibili, pubblicato come ISO 14289-1 nel 2014 e aggiornato nel 2024. Dove le WCAG sono neutrali rispetto alla tecnologia e alla piattaforma, PDF/UA è specifico per PDF — è il contratto tra il software che produce i documenti, il software che li consuma e le tecnologie assistive che dice l’albero dei tag, i metadati e la struttura di questo file sono conformi a un insieme verificabile di condizioni, così un lettore conforme può fare affidamento su di essi.

Lo standard è operativizzato attraverso il Matterhorn Protocol, mantenuto dalla PDF Association, che scompone PDF/UA in 31 condizioni di fallimento numerate, con varianti sia verificabili automaticamente sia verificabili manualmente. Le condizioni verificabili automaticamente includono l’assenza del titolo del documento nei metadati, la presenza di figure senza Alt o ActualText, liste strutturate al di fuori dei tag L/LI e attributi di lingua mancanti nel documento o nei tratti con cambio di lingua. Le condizioni verificabili manualmente riguardano ciò che il software non può verificare da solo — se il testo alternativo di una Figure descrive effettivamente la figura, se l’ordine di lettura corrisponde alla sequenza logica, se i titoli sono annidati logicamente anziché a salti di livello.

L’aggiornamento del 2024 ha allineato PDF/UA ai criteri di successo WCAG 2.2 e ha chiarito il trattamento delle firme digitali e dei moduli — i moduli PDF accessibili devono esporre le etichette dei campi, i tooltip dei campi e l’ordine di tabulazione, e i PDF firmati non devono bloccare l’accesso dello screen reader all’albero dei tag sottostante dopo la firma.

Quando un PDF arriva senza un albero dei tag utilizzabile — e la maggior parte dei PDF legacy è così — la scelta dell’ingegnere si riduce a quattro ambienti di rimediazione. Ciascuno ha una combinazione diversa di punti di forza nella modifica dell’albero dei tag, nell’OCR per gli originali scansionati, nell’elaborazione in batch e nei report PDF/UA. La matrice seguente mappa le capacità rispetto allo strumento.

Un PDF correttamente con tag è solo la metà della catena lato produttore. L’altra metà è lo screen reader, e i quattro lettori effettivamente utilizzati dalla maggior parte degli utenti trattano lo stesso file in modi leggermente diversi. Le differenze contano perché un documento che si legge bene in JAWS può avere problemi in NVDA, e un file che funziona in VoiceOver su macOS può comportarsi diversamente quando lo stesso file viene aperto da ChromeVox nel visualizzatore PDF integrato di Chrome.

JAWS ha il supporto PDF più profondo e più antico di qualsiasi screen reader commerciale. La sua Modalità PDF esegue il rendering dei PDF con tag attraverso Acrobat o Acrobat Reader ed espone direttamente l’albero dei tag — elenco dei titoli (Insert+F6), elenco dei moduli (Insert+F5), navigazione nelle celle della tabella con i tasti standard di JAWS. Quando un PDF non ha tag, JAWS proporrà di inferire la struttura, ma il risultato inferito è inaffidabile; gli ingegneri non dovrebbero convalidare i risultati di letture inferite da JAWS.

NVDA legge i PDF con tag anche attraverso Acrobat o Acrobat Reader, con una navigazione in modalità sfoglia che rispecchia il modello delle pagine web — H per passare ai titoli, K per i link, T per le tabelle. Il supporto PDF di NVDA è migliorato notevolmente dal 2022 ma rimane ancora indietro rispetto a JAWS per tabelle complesse e campi modulo. NVDA fornisce un feedback più onesto per i documenti con tag malformati: dove JAWS può continuare imperterrito, NVDA tende ad ammutolirsi, il che è utile a fini diagnostici.

VoiceOver su macOS legge i PDF attraverso Preview e Safari con la navigazione del rotore (VO + U) su titoli, link, tabelle e campi modulo. VoiceOver è il più tollerante dei quattro — ricostruirà un ordine di lettura anche per file con tag scadenti — ma la sua tolleranza può mascherare veri fallimenti. Un documento che si legge in modo accettabile in VoiceOver deve comunque essere verificato con JAWS o NVDA, non viceversa.

ChromeVox su ChromeOS, e il comportamento più generale di qualsiasi screen reader che interagisce con il visualizzatore PDF integrato di Chrome, si trova in una categoria diversa. Il visualizzatore PDF di Chrome rasterizza e ri-estrae il testo invece di eseguire il rendering dell’albero dei tag originale, quindi un PDF con un albero dei tag pulito può perdere gran parte della sua struttura se aperto direttamente in Chrome. La soluzione alternativa per i contesti critici per l’accessibilità è forzare il download del file e aprirlo in Acrobat Reader, oppure fornire un’alternativa HTML.

Mettendo insieme la catena: un singolo PDF accessibile percorre sei passi concreti. Sono sequenziali — saltarne anche uno solo produce un file che fallirà in uno dei passaggi successivi o nelle mani dell’utente.

I team che trattano l’accessibilità dei PDF come un problema di rimediazione finale finiscono per pagare il conto due volte — una volta per rimediare un file prodotto senza intento strutturale, e di nuovo ogni volta che il file viene aggiornato. I team che la trattano come un problema di authoring costruiscono l’albero dei tag alla fonte, lo rigenerano in modo pulito ad ogni revisione e usano PAC e uno screen reader come verifica piuttosto che come riparazione. La differenza di costo tra le due posture è grande; la differenza di accessibilità è ancora maggiore.

La catena documentata sopra è deliberatamente indipendente dagli strumenti a ogni anello. Che il sistema a monte sia InDesign o LibreOffice, l’editor sia Acrobat o Foxit, il verificatore sia PAC e lo screen reader sia JAWS o NVDA, la logica strutturale è la stessa: gli stili di paragrafo vengono mappati ai tag, i tag sono conformi a PDF/UA, PDF/UA viene verificato da PAC e gli screen reader leggono il risultato. Gli strumenti cambiano; la catena no.

Per i team di procurement e conformità, l’implicazione operativa è che le dichiarazioni di accessibilità dei PDF devono fare riferimento alla catena di produzione — lo strumento di authoring, l’azione di esportazione, il verificatore — non solo al risultato di un checker Acrobat. Per i team di ingegneria, l’implicazione è che l’albero dei tag è la fonte di verità e viene costruito a monte rispetto a qualsiasi PDF che l’utente veda mai. Per una procedura guidata di produzione pratica che integra questo primer, consultare il playbook step-by-step per l’accessibilità dei PDF.