PDF accessibili e quando scegliere HTML

Parliamo del tuo progetto →

Se il contenuto deve essere letto, cercato, aggiornato o compilato online, HTML dovrebbe essere il formato di base. Il PDF resta utile, ma soprattutto come versione secondaria: da scaricare, stampare o archiviare. Questo vale ancora di più quando il documento fa parte di un servizio digitale e deve rispettare criteri di accessibilità coerenti con WCAG 2.2 e con la direttiva UE 2019/882 nel suo perimetro applicabile.

La distinzione non è teorica: cambia la facilità con cui una persona trova l’informazione, capisce la struttura e completa un’azione senza dipendere dall’impaginazione visiva. Il quadro WCAG del W3C e le note introduttive su cosa c’è di nuovo in WCAG 2.2 aiutano a leggere il problema nel modo corretto: non si tratta di abolire i PDF, ma di scegliere il formato in base all’uso reale del contenuto.

Quando HTML dovrebbe essere il formato principale

HTML è la scelta più solida quando il contenuto è parte del servizio e non un semplice allegato. Vale soprattutto per:

istruzioni operative che l’utente deve seguire passo passo;
pagine che devono essere trovate dai motori di ricerca;
contenuti che cambiano spesso;
testi lunghi con sezioni, riferimenti e link interni;
moduli o procedure che richiedono un’interazione chiara.

In questi casi il vantaggio dell’HTML è pratico: titolo, sottotitoli, elenchi e collegamenti possono essere letti nell’ordine corretto, navigati da tastiera e aggiornati senza rifare tutto il documento. L’informazione vive nel punto in cui l’utente la usa.

Per chi pubblica guide, documentazione amministrativa o contenuti di servizio, questo fa la differenza tra un testo semplicemente leggibile e un contenuto davvero usabile.

Quando il PDF ha ancora senso

Il PDF non è un errore in sé. Ha senso quando serve uno di questi obiettivi:

conservare un’impaginazione precisa;
offrire una versione scaricabile e stampabile;
distribuire un allegato ufficiale o una scheda da archiviare;
mantenere un formato identico per tutti i destinatari.

Il punto è non trattarlo come scorciatoia editoriale. Se il contenuto è strategico o si aggiorna spesso, la pagina HTML dovrebbe restare la fonte primaria; il PDF può essere una copia coerente, non l’unico contenitore dell’informazione.

La vera differenza: struttura, ordine di lettura e aggiornamento

Molti documenti sembrano chiari a schermo, ma non sono davvero usabili per chi naviga con tastiera, screen reader o altri strumenti assistivi. Il problema non riguarda solo l’estetica. Di solito riguarda:

struttura non esplicita, con titoli resi solo visivamente;
ordine di lettura incoerente;
tabelle usate come impaginazione;
link poco descrittivi;
immagini che contengono testo essenziale;
contenuti che esistono solo nel PDF e non nella pagina HTML.

Qui la domanda utile non è “il file si apre?”, ma “l’informazione si capisce e si percorre senza vedere il layout originale?”. Se la risposta è no, il documento va rivisto.

Un esempio concreto: guida clienti in due formati

Scenario simulato. Una PMI pubblica una guida di 12 pagine per spiegare come richiedere assistenza tecnica, allegare documenti e seguire lo stato della pratica. Il reparto comunicazione preferisce il PDF perché “si stampa meglio”, ma il team digitale nota che il documento viene usato anche da chi legge da tastiera o con un lettore di schermo.

Prima

un solo PDF scaricabile;
copertina e impaginazione pesante;
sommario non cliccabile;
sezioni non marcate in modo semantico;
istruzioni importanti dentro riquadri grafici;
link scritti come “clicca qui”.

In questa versione il contenuto esiste, ma la fruizione dipende troppo da come il file appare sullo schermo.

Dopo

una pagina HTML con introduzione, passaggi e note utili;
titoli strutturati in modo coerente;
elenco ordinato delle azioni da compiere;
link descrittivi, come “scarica il modulo” o “leggi i requisiti prima di inviare la richiesta”;
PDF allegato come versione stampabile, allineata al contenuto della pagina.

Qui il PDF non sparisce: cambia ruolo. Diventa un supporto, non l’unica porta d’ingresso all’informazione.

Criteri pratici per decidere il formato

Prima di pubblicare, il team può usare questa sequenza di controllo:

Il contenuto è parte essenziale del servizio? Se sì, l’HTML deve essere la base.
Il contenuto va aggiornato spesso? Se sì, il PDF da solo crea duplicazione e rischio di disallineamento.
L’utente deve cercare, saltare o rileggere sezioni? Se sì, servono struttura e navigazione semantica.
Serve una versione stampabile o archiviabile? Se sì, il PDF ha senso come formato secondario.
Il contenuto contiene dati, istruzioni o passaggi che non devono perdersi in una grafica complessa? Se sì, va garantito in HTML prima ancora del PDF.

Questa sequenza aiuta a evitare una scelta basata solo sulle abitudini interne del team.

Domanda	Se la risposta è sì	Formato consigliato
Il contenuto è parte del servizio?	Deve essere consultabile online	HTML
Il contenuto cambia spesso?	Rischio di versioni disallineate	HTML come fonte primaria
Serve una versione da stampare o archiviare?	È utile un allegato coerente	PDF come derivato
L’utente deve saltare tra sezioni o rileggere più volte?	Serve navigazione semantica	HTML
Il contenuto contiene istruzioni operative?	La struttura è essenziale	HTML, con PDF di supporto

Come verificare se il passaggio ha funzionato

La verifica non richiede strumenti sofisticati, ma una prova ripetibile. Per un contenuto che oggi vive in PDF e domani anche in HTML, controllate almeno questi aspetti.

1. Struttura

I titoli descrivono davvero le sezioni?
La navigazione per titoli consente di muoversi nel testo?
Le liste sono liste vere e non semplici paragrafi con trattini?

Se fallisce: convertire il documento in una struttura semantica, evitando di simulare il layout con spazi e grassetti.

2. Ordine di lettura

Il testo viene letto nell’ordine corretto?
Tabelle e riquadri non interrompono il senso della pagina?
Le note laterali non rubano priorità alle istruzioni essenziali?

Se fallisce: semplificare il layout e verificare che la sequenza delle informazioni coincida con il percorso reale dell’utente.

3. Link e azioni

I collegamenti dicono dove portano?
Le call to action sono comprensibili fuori contesto?
Un utente che salta da un punto all’altro capisce cosa succede dopo il clic?

Se fallisce: riscrivere i link con testo esplicito e orientato all’azione.

4. Coerenza tra HTML e PDF

I due formati contengono le stesse istruzioni essenziali?
Le date, i numeri e i riferimenti coincidono?
Il PDF è davvero una versione coerente, o è rimasto una bozza separata?

Se fallisce: definire una fonte unica, con il PDF generato dal contenuto approvato e non da una copia manuale non controllata.

Errori da evitare prima della pubblicazione

Alcuni errori si ripetono spesso e sono costosi da correggere dopo il rilascio:

pubblicare prima il PDF e poi “adattarlo” all’HTML;
lasciare nel PDF informazioni che non compaiono nella pagina;
usare immagini con testo essenziale senza alternativa testuale;
trasformare il sommario in un elemento puramente grafico;
trattare il PDF come se fosse una pagina web senza verificarne la struttura.

Se il documento deve guidare una decisione o un’azione, deve funzionare anche quando il layout non aiuta.

Cosa cambia per team contenuti, UX e sviluppo

Per il team contenuti, la regola è partire dalla gerarchia informativa: titolo, sezioni, passaggi, avvertenze, contatti. Per il team UX, il compito è ridurre gli ostacoli e distinguere ciò che serve davvero da ciò che è solo decorazione. Per lo sviluppo, il punto è assicurare che l’HTML mantenga struttura, navigazione e riferimenti puliti, mentre il PDF non diventi un’eccezione difficile da controllare.

In pratica, la scelta più utile è questa: HTML come versione primaria, PDF come derivato controllato. È una formula semplice, ma evita gran parte dei problemi che emergono quando il documento nasce direttamente come file statico e solo dopo si cerca di renderlo usabile online.

Se il vostro sito pubblica documenti, moduli o guide scaricabili, il servizio di Accessibilità digitale per siti, software e workflow aziendali è un punto di partenza utile per impostare una verifica concreta su contenuti, struttura e usabilità. Per aggiornare competenze interne e rendere il processo più ripetibile, può aiutare anche Formazione, divulgazione e R&D.

Verifica finale rapida

Prima di pubblicare, chiedete a chi controlla il contenuto di rispondere a queste cinque domande:

La pagina HTML contiene tutto ciò che serve per capire e agire?
Il PDF è solo una versione di supporto, non la fonte unica?
I titoli e i link descrivono il contenuto in modo chiaro?
Il documento si legge bene anche senza affidarsi al layout visivo?
Le informazioni coincidono tra pagina e allegato?

Se la risposta è sì a tutte, il formato scelto sta aiutando il lettore. Se una sola risposta è no, il lavoro non è finito: va corretto il contenuto, non solo l’impaginazione.