Uso dei form e PDF accessibili (remediation or not)

Rimediare o non rimediare?

La cosiddetta “remediation” (ovvero la correzione, tramite analisi e ristrutturazione dei contenuti) di grandi quantità di PDF già esistenti può presentare sfide significative, per non dire che è una fatica di Sisifo.

Questo perché la conformità agli standard di accessibilità richiede spesso un’analisi e una modifica approfondite del contenuto dei documenti, che può essere un processo laborioso e tecnicamente complesso, specialmente quando i documenti non sono stati originariamente creati con considerazioni di accessibilità.

Per quanto riguarda la creazione di PDF accessibili a partire da form HTML, è essenziale che questi form siano progettati con criteri di accessibilità fin dall’inizio, con l’uso di label chiare, struttura logica e supporto per tecnologie assistive con landmarks, eventuali tag ARIA e una struttura generale di pagina e codice che rispetti i criteri di progettazione accessibile.

Un percorso ricco di insidie

La correzione di grandi quantità di PDF per garantirne l’accessibilità può essere un compito complesso e dispendioso in termini di risorse.

Ecco alcune sfide chiave che spesso si incontrano in questo processo:

  • OCR per riconoscimento testo con layer sovrapposti (sono diventati impressionanti ma con sovrapposizioni non fanno miracoli, e vanno comunque SEMPRE ricontrollati da una persona dedicata)
  • gestione di immagini, artefatti, colori: i contrati, la presenza di elementi inutili e/o dannosi, l’ottimizzazione della struttura dei contenuti, sono estremamente importanti
  • font inadatti e illeggibili, a volte in forma di immagine (torniamo agli OCR)
  • documenti in versioni ormai antiquate e non corrette secondo gli standard di qualità e normativi (non PDF/A, ad esempio)
  • grafici e oggetti di programmazione avanzati (OLE), la cui resa con ALT, TITLE, o in alcuni casi descrizioni dedicate accurate, sono un capitolo proprio a parte.
  • uso di strumenti dedicati – on premise e/o SAAS – come i tool di remediation di Allyant, Deque e CommonLook – con costi di formazione, setup, abbonamento ecc. – non sono certo indifferenti.
  • costi di update: ogni volta che dobbiamo rieditare anche solo un breve paragrafo, dobbiamo rifare da capo il processo di generazione accessibile del documento.

Un esempio di processo

Entrando un po’ più nel dettaglio del processo, ecco qualche spunto:

  1. Preparare il form HTML:
    Assicurarsi che il modulo sia completamente accessibile. Questo include l’etichettatura di tutti i controlli e campi, l’ordine corretto delle schede dei campi e l’inclusione di set di campi per gli elementi raggruppati (fieldset, legend, ecc.). L’utilizzo di HTML semantico è fondamentale per mantenere la struttura e l’accessibilità quando viene convertito in PDF.
  2. Strumenti di conversione dinamica:
    Utilizzare uno strumento di conversione che supporti la creazione dinamica di PDF accessibili. DocRaptor, giusto a titolo di esempio, è uno strumento che converte l’HTML in PDF mantenendo i tag necessari per l’accessibilità. Supporta funzioni complesse come l’impostazione dei metadati PDF e la regolazione dei tag dei contenuti tramite CSS personalizzati.
  3. Controllo & modifica Tag:
    Una volta generato il PDF, è necessario controllare ed eventualmente modificare i Tag: elementi semantici quali intestazioni, paragrafi, elenchi ecc. aiutano a definire la struttura del documento per gli screen reader. Adobe Acrobat Pro è comunemente utilizzato per questo scopo – e nella mia esperienza è il migliore come affidabilità, gestione, completezza, rispetto degli standard – in quanto consente di visualizzare e modificare il pannello dei tag, assicurando che l’ordine di lettura e la struttura del documento siano corretti, oltre a molte altre operaizoni utili/necessarie allo scopo. Non è l’unico, ma il mio preferito certamente.
  4. Aggiunta di testi alternativi (“Alt text”):
    Assolutamente necessario è che tutti gli elementi non testuali, come le immagini, abbiano un testo alternativo per descrivere la loro funzione, che possono essere definiti nell’HTML e conservati nella conversione del PDF.
  5. Controlli finali:
    Utilizzare – a valle di tutto il percorso – dei tool di verifica dell’accessibilità dei PDF per esser certi che tutti gli elementi siano correttamente etichettati, la struttura corretta, l’ordine di lettura coerente, i contenuti esposti siano quelli voluti, ecc. Strumenti come il PDF accessibility checker di Adobe Acrobat possono aiutare a identificare e risolvere eventuali problemi residui.

Soluzioni Alternative

Fare o non fare - non c'è provare (meme di Yoda da Guerre Stellari)A seconda del contesto, io propongo sempre un approccio di tipo KISS (“Keep It Simple Stupid”) e di massima semplicità operativa, focalizzata all’obiettivo specifico: cosa vogliamo ottenere? cosa ci serve? quanto ci costa in termini di sforzo, manutenzione, risultato? è necessario un PDF o altri formati possono essere più accessibili?

Ad esempio, i form web sono generalmente più accessibili e facili da aggiornare rispetto ai moduli PDF.

Ancora, se un PDF è proprio essenziale, è fondamentale assicurarsi che sia creato in modo accessibile fin dall’inizio, dalla progettazione e dalla generazione (che al 95% dei casi avviene su Microsoft Word).

E qui la formazione diventa essenziale.

In linea generale, se ho dei form, moltissimi pdf spariranno: questo è un bene in ore lavoro risparmiate nel fare redazione, copia incolla, correzione errori, ecc. dal personale interno; inoltre, il tutto sarà sempre disponibile come dato riutilizzabile e trasformabile, ricercabile per migliori servizi – e più rapidi.

Inoltre il passaggio nella multicanalità (siti, app, mobile, desktop, pubblico/intranet, schermi per la clientela, DEM e newsletter, sistemi di sondaggio, ecc.)