PDF accessibili con applicazioni Open Source?

Antefatto: chi decide se un PDF è accessibile o meno, e come dovrebbe essere fatto? Nel caso della Pubblica Amministrazione, se si tratta di libri di testo le caratteristiche che il documento deve rispettare sono elencate nel D.M. 30 aprile 2008, Allegato A. Se si tratta di documenti destinati al pubblico o distribuiti via Web, lo spiega il Bertoni. Per il resto del mondo lo decide Adobe nelle sue linee guida. Fine antefatto, e una possibile soluzione è al punto sei delle conclusioni, ma prima leggete il resto.

Un recente post di Semplicemente apre dichiarando:

PDF accessibili con applicazioni Open Source
Chi desidera pubblicare documenti PDF accessibili spesso si scontra con l’ostacolo del costo di Adobe Acrobat. Acrobat resta l’applicazione principe per l’accessibilità dei PDF, e l’unica che consente di verificarla, ma per chi non ha il denaro per acquistare questo software, esistono alcune soluzioni Open.

Seguono le mie rimostranze nei commenti del post. Non mi sembra di essere riuscito a spiegare il perché delle mie lamentele, e comunque è un argomento interessante e lo riprendo.

La mia prima rimostranza, e la più grossa, riguarda il titolo: a oggi non è possibile sapere e dichiarare se un PDF sia accessibile o meno, che venga creato con applicazioni Open Source o commerciali, senza utilizzare Acrobat Pro per verificare e correggere gli eventuali errori presenti.

Per esempio, nessuna applicazione (Word, OpenOffice, Indesign, chi più ne ha più ne metta) dispone nativamente di strumenti veramente efficaci e completi per rendere accessibili le tabelle o i moduli nei PDF. Impostare i cambi di lingua è un terno al lotto, e di solito gli elenchi puntati producono errori Unicode. L’unico strumento disponibile per creare, testare e modificare PDF accessibili è Acrobat Pro.

Tutto quello che si può fare, sia con applicativi commerciali sia Open Source, è salvare nel formato chiamato PDF con tag, che certo è un passo avanti per niente disprezzabile rispetto al nulla, ma sicuramente non è una condizione sufficiente per poter dichiarare che il PDF generato sia accessibile.

In realtà, quello che si fa è creare un documento .doc, .odf o altri formati utilizzando gli strumenti per l’accessibilità resi disponibili dal programma in uso. In linea di massima tutti i programmi che normalmente utilizziamo devono rispondere alla Section 508, e quindi sono in grado di generare file accessibili rispetto ai requisiti di questa normativa. Quindi si dovrebbe dire “creare documenti elettronici accessibili con Word, con Open Office” e così via. Creato il documento, decido di salvarlo in PDF.

Qui si notano comportamenti diversi. Chi dispone di Office e Acrobat, può sfruttare le opzioni del PDF Writer per preservare nel PDF il lavoro fatto sull’accessibilità del documento (e sulla sua qualità), poiché sarà possibile creare un PDF non soltanto strutturato, ma anche dotato di testi alternativi per le immagini, titoli per i link, sommari navigabili.

Con altri programmi, come Open Office o Indesign nelle versioni più recenti, questa possibilità è disponibile anche in assenza di Acrobat, mentre per Office è necessario disporre della versione 2007 e di un apposito plugin.

Basta questo per dichiarare accessibile il PDF? No. Un PDF accessibile deve rispondere a tutte le linee guida per l’accessibilità dei PDF di Adobe, che vanno anche oltre la Section 508. Per esempio, deve essere possibile visualizzare i contenuti anche quando linearizzati. Cosa significa? Provate ad aprire un PDF, sottoponetelo a ingrandimento e premete i tasti ctrl+4. Ora il documento è linearizzato, ovvero le informazioni presenti vengono renderizzate una di seguito all’altra, in un flusso consecutivo. Il documento è ancora fruibile? Se no, torna alla partenza. È comparsa la barra di scorrimento orizzontale? Se sì, ecco che sono presenti problemi di accessibilità. Del PDF, non del documento originale. Il PDF non è accessibile. Quindi non si può affermare “creare PDF accessibili con…”. Il problema non è open source o meno, il problema è con Acrobat o meno.

Nel post vengono presentate due procedure, una per creare PDF con tag con OpenOffice o a partire da file Word (nel caso, aprendo nel Writer di OpenOffice un eventuale documento Word e salvandolo come PDF con tag da OpenOffice, e fin qui nulla da dire, verrà creato un PDF con tag anche a partire da un documento creato con versioni di Word precedenti alla 2007, ben venga). Ovvio che il documento in entrambi i casi deve essere stato realizzato come si deve, in caso contrario non si produrrà nulla di utile. E se non lo fate vi scateno Cheope.

È da alcune versioni che Open Office ha questa opzione, e certo è una buona idea approfittarne. Ma vorrei sottolineare ancora una volta: è “soltanto” un PDF con tag, niente altro.

La seconda soluzione riguarda l’editing dei file PDF, dimenticando però che il problema vero con i PDF e tutti gli strumenti che permettono di creare file PDF, che siano open source o meno è uguale, consiste nella verifica dell’accessibilità dei file ed eventualmente nella correzione degli errori, cosa ad oggi inspiegabilmente possibile soltanto con Acrobat Pro, nonostante il formato PDF sia pubblico.

Il post di Antonio presenta come soluzione un plugin per Open Office, la Sun PDF Import Extension. Questa extension permette di aprire un file PDF e di eseguire sul file alcune operazioni di editing, fra cui assegnare agli elementi degli stili. Poi, basterà salvare il file in PDF con tag ed ecco fatto, è stato creato un PDF accessibile. Col cavolo…

Questo plugin apre sì i file PDF nel Draw di Open Office, ma poi che si riesca a farci qualcosa è del tutto opinabile: il testo viene diviso in righe singole, e quindi per assegnare un qualche stile ai blocchi di testo è necessario selezionarli riga per riga.

Se il documento ha più di trenta righe, magari con un layout a colonne, da spararsi. Certo, se ci si accontenta e si ha tanto tempo a disposizione…

Ma peggio del peggio, il plugin non riconosce come stili i tag eventualmente presenti nel PDF.

Come ci si può aspettare, selezionando gli stili predefiniti di Draw vengono applicate le formattazioni di default di Draw, non quelle presenti nel PDF. Per ottenere un PDF graficamente uguale, o almeno simile, a quello di partenza bisognerà ridefinire anche le specifiche di tutti gli stili. O perlomeno, selezionare un elemento, selezionare Nuovo stile dalla selezione, assegnare un nuovo nome allo stile… a me sembra già una cosa da matti.

Fin qui, stiamo parlando di semplice testo. Mi è stato fornito un file di esempio, quello nelle immagini, che dovrebbe rappresentare una prova dell’accessibilità dei PDF creati con Open Office e i plugin. Bene, una delle tabelle presenti non ha una riga di intestazione, allo scopo di evidenziare la differenza con l’altra tabella presente nel file, che la possiede.

Ora vorrei correggere questo errore con la “soluzione open source”. Dopo aver definito riga per riga gli stili, eccomi alla tabella. E ora? Come faccio a correggere la tabella se non ci sono gli strumenti per poterlo fare? Magari da qualche parte ci sono, ma io non sono riuscito a trovare qualche comando per assegnare alla cella di intestazione il tag opportuno (nel caso specifico, <th>).

E, domanda da mille punti: come caspita faccio a sapere che nel PDF c’è questo errore se non ho Acrobat per verificare il file? Penso che non lo saprò mai.

La cosa che più mi deprime è che nei commenti mi viene risposto “Un’altra considerazione e concludo. L’articolo che ho scritto è frutto di un seminario tenuto nella scorsa edizione di Handimatica intitolato “Generare PDF accessibili in modo accessibile” (una soluzione open source a portata di tutti). Il seminario era tenuto da un non vedente che utilizzava, ovviamente, le tecnologie che conosciamo tutti. Se un file PDF generato così è accessibile per lui, allora lo è anche per me”.

È completamente sbagliato. Uno: l’accessibilità non è “siccome uno screen reader legge il documento allora questo è accessibile”. Due: l’accessibilità non è un argomento riservato ai ciechi, che diventano i testimonial dell’accessibilità. Fra tutti i problemi coinvolti nell’accessibilità, quelli dei ciechi sono i minori. Sembra terribile dirlo, ma è così: è molto più facile che un documento elettronico possa essere letto da un cieco che da un ipovedente.  Tre: meglio evitare i seminari di Handimatica, spero che lascino proprio perdere questi argomenti. Quattro: quel seminario evidentemente era molto approssimativo, e il titolo è una bugia. Cinque: ma quando la comunità Open Source produrrà uno strumento in grado di fare le stesse cose che fa Acrobat Pro? Perchè, di equivalente ad Acrobat sia open source sia commerciale non c’è proprio niente.

Sei, molto importante: il nocciolo della questione è la possibilità di verifica ed intervento. Se non dispongo di Acrobat come faccio? Non posso?

Certo che si può. La possibilità viene dal formato ODF. ODF è un formato XML standard ISO, ed in quanto tale dispone di strumenti di validazione sia del codice, con l’ODF Validator, sia, e questo è fondamentale, dell’accessibilità con l‘Open Document Format (ODF) Accessibility Evaluator. Questo da solo dovrebbe rappresentare un motivo per adottare il formato ODF, qualsiasi sia il programma utilizzato per creare i propri documenti. Né doc né rtf dispongono di questi strumenti di verifica.

E non farebbe una bella figura il solito link al PDF etichettato però “PDF creato a partire da un file ODF accessibile“? Ricordandosi, mi raccomando, di attivare la casella di controllo Crea PDF con tag, sennò è inutile. Come conseguenza, molto probabilmente il file PDF generato a partire da un file nativo così verificato risulterà accessibile anche quando sottoposto ai test del validatore di Acrobat Pro.

Capisciammè. Spero di essermi spiegato

-

Archiviato in Accessibilità, PDF | Comments (6) torna alla Home