Garantire la diretta accessibilità delle interfacce utente incorporate. Parte 3ª: i documenti PDF

Il formato PDF (Portable Document Format)

Il 1993 è l’anno di nascita del formato PDF, creato da Adobe Systems come un’evoluzione del più antico linguaggio PostScript. Mentre il PostScript è un linguaggio di descrizione vettoriale delle immagini e dei testi che necessita di un interprete, cioè di un software in grado di analizzare e compilare il codice per poter eseguire le istruzioni in esso contenute, il PDF contiene dati già interpretati. È, cioè, un formato, non un linguaggio di programmazione. Ciò vuol dire che i contenuti di un documento PDF non devono essere generati eseguendo complicate istruzioni di programmazione, ma sono già presenti nel file, descritti da un’apposita simbologia, e possono essere riprodotti, in modo rapido e uniforme, da qualsiasi software conforme alle specifiche del formato.

Per tale ragione, l’avvento del PDF ha rappresentato un notevole progresso nell’interscambio dei documenti digitali. Alla lentezza e alla pesantezza del PostScript, e alla sua vocazione quasi esclusiva per la stampa, il PDF ha opposto non solo una resa più veloce, ma, con il tempo, anche una grande versatilità: non più limitato alle sole funzioni di formato intermedio tra autore e stampatore, il PDF è diventato uno strumento per lo scambio globale, la consultazione e la conservazione dei documenti digitali, rendendo quanto mai vera la vocazione alla portabilità contenuta nel suo nome (Portable Document Format significa appunto “formato per documenti trasportabili”).

Se, infatti, i PDF venivano usati all’inizio soprattutto come formato per inoltrare ai service di stampa degli impaginati prodotti con programmi di desktop publishing (PageMaker, QuarkXPress, e simili), successivamente l’esplosione del Web come fenomeno di massa ne ha determinato un uso diverso e infinitamente più ampio: la diffusione via Internet di documenti di ogni sorta, non necessariamente destinati alla stampa, resi disponibili come allegati all’interno dei siti web. Così, il formato PDF è stato usato, e lo è tuttora, per pubblicare sul Web circolari ministeriali, leggi e regolamenti, saggi e studi scientifici, opere letterarie, articoli e copertine di giornali, volantini, locandine e ordini del giorno, presentazioni per conferenze, grafici, tabelle, statistiche, documenti di specifiche tecniche, moduli prestampati da compilare a penna o moduli interattivi da compilare tramite un computer, e molto altro ancora.

Grazie ad appositi software, tra i quali Adobe Reader è certamente il più noto, i documenti salvati in PDF possono essere non solo stampati, ma letti direttamente a schermo su qualsiasi tipo di computer. Con le ultime versioni di Adobe Acrobat, inoltre, sono stati forniti agli sviluppatori sofisticati strumenti per l’accessibilità, come i marcatori strutturali e la possibilità di ridefinire l’ordine di lettura.

L’immenso numero di documenti disponibili sul Web in formato PDF rende infatti l’accessibilità di questo formato una questione d’importanza capitale: un sito web non può dirsi veramente accessibile, se parte dei suoi contenuti si trova in documenti PDF che, per qualche ragione, rimangono impermeabili alle tecnologie assistive.

L’accessibilità non è, purtroppo, una proprietà intrinseca e necessaria dei documenti in formato PDF. Quando c’è, è spesso il risultato di precisi interventi umani, le cui caratteristiche saranno illustrate e discusse nel resto del capitolo.

Ricordiamo, infine, che la casa produttrice Adobe ha annunciato, con una nota del 29 gennaio 2007, di aver intrapreso passi ufficiali per avviare il processo che potrebbe portare all’adozione delle specifiche PDF come standard internazionale riconosciuto dal Consorzio ISO (il formato, del resto, è già da anni uno standard de facto). Ciò potrebbe avere benefiche ricadute, come la definizione di linee guida ufficiali e standardizzate per l’accessibilità dei PDF.

Inizio pagina

Considerazioni sull’uso di plug-in per i PDF

La linea guida 8 delle WCAG 1.0, alla cui raccomandazione è ispirato il presente capitolo (così come i due precedenti), si riferisce all’accessibilità delle interfacce utente incorporate. Ci interessa, perciò, in questa sede soprattutto l’uso dei documenti PDF all’interno di un browser, come interfacce utente incorporate.

La prima cosa da dire a tal proposito è che i browser non sono in grado di riprodurre autonomamente i contenuti di un documento PDF. Per riuscirci, hanno bisogno di un plug-in, cioè di un programma sussidiario che deve essere installato a parte. Quindi, se durante la navigazione sul Web si segue dall’interno di un browser un collegamento a un documento in formato PDF, possono accadere diverse cose, a seconda che sia installato oppure no un plug-in per gestire questo tipo di file:

1. il plug-in c’è e si avvia automaticamente, aprendo il documento all’interno del browser;
2. il plug-in c’è, ma le impostazioni definite dall’utente impongono l’apertura dei file PDF in Adobe Reader, esternamente al browser;
3. il plug-in non c’è e allora:
   1. parte automaticamente un “gestore di download” (un programma che tiene traccia dei file scaricati dal Web), il quale salva in locale il file PDF e lo apre in un programma esterno al browser, come Adobe Reader, se è disponibile, oppure
   2. l’utente riceve un avviso che lo invita a installare un plug-in per gestire il nuovo formato di file o a salvare direttamente il file in locale, oppure
   3. il browser apre il documento PDF trattandolo impropriamente come testo semplice, il che porta alla visualizzazione di codici privi di significato.

Le immagini seguenti mostrano alcuni esempi della variabilità di comportamenti che, anche in ragione delle preferenze impostate dall’utente, si manifestano tentando di aprire dall’interno di un browser un documento in formato PDF.

Anche quando un plug-in per i PDF è presente e svolge correttamente il proprio lavoro, non è esagerato affermare che il modo in cui esso agisce, incorporato nel programma ospite (il browser), può rappresentare di per sé un problema di accessibilità.

Dobbiamo considerare, infatti, alcuni effetti collaterali che derivano dall’interazione tra plug-in e browser:

• molti utenti non dispongono di un sufficiente grado di alfabetizzazione informatica. Quando, seguendo un collegamento a un file PDF, ricevono un avviso di programma mancante, una richiesta di salvataggio in locale o l’invito a installare l’apposito plug-in, possono semplicemente abbandonare il compito, perché non sono in grado di capire cosa sta accadendo e cosa occorrerebbe fare per visualizzare i contenuti del documento. Si veda in proposito l’esempio presentato nel Capitolo 1 (Non si finisce mai di installare...);
• applicare ai documenti PDF il metodo del potenziamento progressivo, che rappresenta un’ottima scelta di accessibilità per applicazioni JavaScript (si veda il Capitolo 11), richiede la duplicazione dei contenuti del PDF in HTML o in XHTML. Se, cioè, si volesse consentire a chi naviga con un browser testuale di leggere i contenuti di un PDF senza abbandonare il browser, l’unica possibilità sarebbe di riscrivere l’intero contenuto del documento PDF in HTML, con uno spreco di tempo, fatica e danaro difficilmente sostenibile, soprattutto per documenti lunghi decine o centinaia di pagine (le conversioni automatiche da PDF a HTML danno risultati raramente accettabili);
• l’avvio automatico del plug-in e l’apertura di un documento PDF possono essere operazioni decisamente lunghe e pesanti in termini di risorse di elaborazione. Per i computer meno performanti, il tempo occorrente per aprire un file PDF e per navigare al suo interno può essere così lungo, da costituire una significativa barriera all’accesso, soprattutto se l’utente ignora la causa per cui i suoi comandi non hanno una risposta immediata (il problema della lentezza, in particolare con la versione 6 di Adobe Reader, era così evidente, da aver stimolato la nascita di una piccola letteratura di trucchi per velocizzare l’apertura del programma. Basta una ricerca con Google per trovare numerosi esempi);
• l’interfaccia utente di un plug-in per i PDF è molto diversa da quella del browser e questo costringe l’utente a un cambio totale di paradigma, nel passaggio dalla consultazione di un documento HTML alla consultazione di un PDF. Questo cambiamento può essere disorientante e, per capirne le ragioni, occorre riflettere sulle differenze tra i due sistemi, alcune delle quali sono messe a confronto nella Tabella 13.1.

Tabella 13.1 Differenze tra la consultazione di un documento HTML e la consultazione di un PDF

Consultazione di un documento HTML	Consultazione di un documento PDF all’interno di un browser
Il documento, per quanto lungo, appare sempre come il contenuto di un’unica pagina web.	Ogni PDF è basato su pagine di dimensione fissa. Se il contenuto eccede la grandezza di una pagina, scorre su pagine differenti.
Premendo il tasto Indietro (o Back) del browser, si ritorna alla pagina web precedente, se ne esiste una.	Se è attivo il tasto Indietro (o Back) del browser, premendolo non si torna alla pagina precedente del PDF che si sta consultando, ma lo si abbandona, qualsiasi sia la pagina a cui si è arrivati.
I comandi del menu Visualizza del browser possono ingrandire i testi del documento caricato.	I comandi del menu Visualizza non sono attivi o comunque non influenzano la grandezza dei testi. Per ridimensionare i caratteri di un documento PDF, occorre agire sugli appositi comandi dell’interfaccia utente del plug-in, annidata all’interno dell’interfaccia utente del browser.
Nei siti accessibili con layout liquido, i contenuti possono adattarsi alla dimensione della finestra e al variare della grandezza dei caratteri, ridisponendosi all’interno della pagina, in modo da evitare la comparsa della barra di scorrimento orizzontale.	Il rapporto tra contenuti e pagina è fisso. Il ridimensionamento non provoca la redistribuzione dei contenuti sulla pagina, a meno che non si usi il nuovo comando Vista → Ridisponi (Reflow, in inglese), disponibile solo nelle ultime versioni di Adobe Reader, che consente di simulare la flessibilità di un’impaginazione liquida. Il comando non è comunque visibile nell’interfaccia utente del plug-in incorporata nel browser.
La navigazione nel documento può essere svolta da tastiera, usando le scorciatoie rese disponibili dal browser.	La navigazione nel documento può essere svolta da tastiera usando le scorciatoie rese disponibili dal plug-in, purché le singole combinazioni di tasti non siano in conflitto con quelle già utilizzate dal browser.

Inizio pagina

Vantaggi, svantaggi, raccomandazioni generali

Le possibili difficoltà di accesso e utilizzo, che riguardano i PDF caricati in un browser, non sono comunque ragione sufficiente per non pubblicare sul Web documenti in questo formato. Anzi, il PDF è spesso una scelta obbligata, per esempio quando occorre diffondere pubblicazioni cartacee, conservando in forma digitale l’aspetto del documento stampato. Si pensi ai quotidiani che pubblicano la prima pagina o l’intero giornale sul Web: la corrispondenza tra la versione digitale e quella cartacea è essenziale, per avere la certezza della fonte. Nessun formato meglio del PDF può preservare tale fedeltà, mantenendo allo stesso tempo la leggibilità dei testi per le tecnologie assistive.

I vantaggi del PDF sono evidenti anche nel campo della modulistica. Una Pubblica Amministrazione, se vuole rendere disponibili sul Web degli stampati uguali a quelli che il cittadino può ritirare agli sportelli dell’ufficio preposto, non ha che da esportare in PDF i file da cui stampa i propri moduli, usando lo stesso programma di desktop publishing o di videoscrittura nel quale sono stati realizzati. Il formato PDF, tra l’altro, non solo conserva immutato l’aspetto del modulo cartaceo, ma permette anche la sua compilazione, completa di firma digitalizzata, per mezzo di un computer, liberando così i non vedenti dalla seccante necessità di ricorrere all’aiuto di terzi per riempire i campi con i propri dati.

Tirando le somme di quanto detto finora, è innegabile che la scelta del formato PDF aggiunge un ulteriore livello di complessità per l’utente, cosa che – come abbiamo visto – non è esente da rischi per l’accessibilità. È altrettanto innegabile, però, che il formato PDF è, per alcuni tipi di documento, la migliore, se non l’unica scelta possibile.

Come sviluppatori interessati all’accessibilità, bisogna cercare di volta in volta il miglior compromesso tra vantaggi e svantaggi, valutando se sia il caso di pubblicare sul Web documenti in PDF o in HTML o, addirittura, in entrambi i formati.

Molte volte, la scelta del formato viene fatta per motivi economici: si sceglie cioè la soluzione che permette il maggior risparmio di risorse, anche se si tratta di una soluzione altamente inaccessibile. È il caso, per esempio, della rassegna stampa quotidiana pubblicata sul sito della Camera dei Deputati (Figura 13.6), nella quale tutti gli articoli vengono serviti come file PDF-immagine, totalmente muti per uno screen reader.

Nel caso della rassegna stampa della Camera, la soluzione migliore sarebbe trasformare le immagini degli articoli in testi leggibili da uno screen reader, associando inoltre l’uso del formato HTML a quella del formato PDF, per ottenere maggiore rapidità di caricamento e compatibilità universale anche con i browser testuali.

Dal punto di vista dell’accessibilità, valgono per i PDF le seguenti raccomandazioni di carattere generale:

• evitare di pubblicare documenti PDF contenenti semplici immagini del testo, a meno che non siano accompagnati da trascrizioni in HTML dei contenuti testuali o da testi alternativi inseriti nel PDF, oppure
• pubblicare documenti PDF, in cui il testo in forma di immagine sia stato preventivamente convertito, mediante un programma di OCR (Optical Character Recognition, “riconoscimento ottico dei caratteri”) e il successivo controllo umano, in testo vero e proprio, accessibile anche agli screen reader;
• preferire il formato PDF al formato HTML (o XHTML) solo quando è realmente necessario, per esempio quando, per ragioni documentali, è indispensabile fornire un formato digitale che abbia il medesimo aspetto del corrispondente documento cartaceo;
• in ogni collegamento che rimanda a un PDF, annunciare il formato e il peso in kB del file;
• in ogni pagina web che contiene collegamenti a file PDF, aggiungere una breve ma ben visibile nota, che spieghi che la lettura di documenti in questo formato richiede l’installazione di un programma ausiliario; fornire, inoltre, nella stessa nota, un collegamento diretto all’indirizzo da cui è possibile scaricare il plug-in;
• ogni volta che sia possibile, associare una versione in HTML (o XHTML) alla versione in PDF di un documento, in modo da permetterne la consultazione anche a chi usa dispositivi che non sono compatibili con il formato PDF;
• una volta che si è scelto di pubblicare in PDF, rendere accessibile il documento, secondo le modalità che saranno spiegate nei paragrafi successivi.

Un tipico esempio di pubblicazione congiunta in più formati diversi sono le Specifiche W3C: tutte le Raccomandazioni del Consorzio sono pubblicate in HTML o in XHTML, che sono i formati normativi e quelli che consentono una più rapida consultazione sul Web; molte di esse sono disponibili, però, anche in formato PDF (e talvolta anche in altri formati), al fine di consentirne la stampa, l’archiviazione in locale e la consultazione integrale per mezzo di un solo e pratico file: soluzione comoda soprattutto per i documenti più lunghi.

Inizio pagina

Rendere direttamente accessibili i PDF

Il documento di riferimento, contenente tutte le informazioni necessarie per rendere direttamente accessibili i PDF, è una guida di 115 pagine in inglese, intitolata Creating Accessible PDF Documents with Adobe Acrobat 7.0 .

Nonostante Adobe Acrobat sia giunto nel frattempo alla versione 8, le spiegazioni contenute nella guida restano generalmente valide. Acrobat è un software dalle complesse funzionalità, che per il momento non ha rivali, né tra i programmi proprietari né nel mondo dell’Open Source, per quanto riguarda il controllo e l’implementazione dell’accessibilità nei documenti PDF.

Le procedure illustrate nel seguito del capitolo sono state realizzate con la versione 8 Professional di Adobe Acrobat. Fortunatamente, la casa produttrice mette a disposizione una demo della durata di 30 giorni, completa di ogni funzionalità, che consente di provare a fondo le caratteristiche del programma e di poter così decidere a ragion veduta se vale la pena di acquistarlo (il costo della versione Professional è di 449 dollari, una cifra non proprio trascurabile).

Inizio pagina

Il flusso di lavoro

A pagina 13 della guida Creating Accessible PDF Documents with Adobe Acrobat 7.0, compare lo schema che abbiamo riportato, tradotto in italiano, in Figura 13.8. Illustra un flusso di lavoro standard, che dal documento di partenza porta in sei passi fino a un PDF completamente accessibile.

Lo schema considera cinque punti di partenza:

• un documento prodotto in un qualsiasi programma autoriale dotato di filtro di esportazione verso il formato PDF (per esempio, Microsoft Word, Adobe InDesign, PageMaker ecc.);
• una scansione convertita, per mezzo di funzioni di OCR, in un file PDF contenente testo modificabile;
• un documento esistente in formato PDF;
• una molteplicità di documenti provenienti da fonti diverse, assemblati in un unico PDF;
• una pagina web convertita in formato PDF.

Quale che sia il punto di partenza, il primo passo descritto nello schema di Figura 13.8 termina con la disponibilità di un file PDF, pronto per essere trattato per l’accessibilità.

Il secondo passo consiste nell’applicazione di etichette e controlli di modulo compilabili digitalmente. È una procedura che si applica, ovviamente, solo ai documenti che contengono moduli, e per i quali si voglia rendere disponibile la possibilità di compilarli tramite computer.

Il terzo passo consiste nell’applicazione di una marcatura strutturale. Si tratta di etichettare ogni blocco di contenuto nel PDF con degli elementi strutturali – titoli, paragrafi, liste, tabelle ecc. – a somiglianza di quanto viene fatto per un normale documento HTML o XHTML.

Il quarto passo si compone di tre passaggi successivi:

• una prima verifica di accessibilità, basata su controlli automatici eseguiti dal software Acrobat;
• il controllo della leggibilità dei caratteri (devono essere sostituiti gli eventuali caratteri che, a seguito dell’esportazione in PDF, appaiono non leggibili, altrimenti il documento sarà parzialmente o completamente inaccessibile, vanificando ogni altro intervento a favore dell’accessibilità);
• la verifica dell’ordine di lettura per mezzo di uno screen reader (l’ordine di lettura deve corrispondere all’ordine logico dei blocchi di contenuto del documento);

Il quinto passo consiste nella definizione di segnalibri, collegamenti, indicazioni di lingua: tutto ciò che serve per aumentare la navigabilità del PDF e la veloce reperibilità delle informazioni al suo interno. Termina qui il lavoro essenziale per l’accessibilità dei PDF.

Il sesto e ultimo passo, facoltativo, consiste in una miglior messa a punto delle caratteristiche di accessibilità, per mezzo di piccole sistemazioni dell’ordine di lettura e di un lavoro accurato sul codice strutturale delle eventuali tabelle inserite nel documento.

Inizio pagina

Moduli PDF accessibili

Un modulo in formato PDF può essere considerato accessibile se possiede i seguenti cinque requisiti, di cui i primi quattro sono essenziali:

1. campi modulo compilabili per mezzo di un computer (fondamentale per i non vedenti);
2. etichette leggibili dagli screen reader, associate a ciascun campo modulo;
3. un ordine logico di tabulazione attraverso i campi;
4. una marcatura strutturale, per rendere comprensibile agli utenti di screen reader il ruolo svolto dalle varie parti del documento;
5. eventuali ausili per la navigazione, quali segnalibri, collegamenti e informazioni sulla lingua.

L’impaginato in cui vanno inseriti i campi compilabili può essere realizzato direttamente in Acrobat Professional oppure con un qualsiasi programma in grado di esportare verso il formato PDF.

Attraverso il filtro di esportazione Acrobat PDFMaker, utilizzabile per esempio dall’interno di Microsoft Word, possono essere preservati, nel PDF generato, collegamenti ipertestuali, segnalibri, marcatori e campi modulo. Affinché l’esportazione conservi gli elementi di accessibilità, è indispensabile accertarsi che, nelle impostazioni del filtro, siano spuntate le tre caselle evidenziate in Figura 13.9 A e la casella evidenziata in Figura 13.9 B.

Le prime tre segnalano al filtro, rispettivamente, di aggiungere al PDF segnalibri e collegamenti e di abilitare l’accessibilità e la ridisposizione dei contenuti strutturati sulla pagina visibile (nel caso che si voglia evitare la comparsa della barra di scorrimento orizzontale).

L’ultima casella segnala, invece, che deve essere abilitato l’accesso alle tecnologie assistive, anche in caso che il documento sia protetto con una password e che siano state attivate restrizioni sulla copia e sulla stampa dei contenuti. Quest’ultima è una funzione importantissima per l’accessibilità, introdotta a partire dalla versione 1.4 delle Specifiche PDF. Corregge un problema molto comune, che è stato causa di grandi frustrazioni per gli utenti di screen reader, alle prese con l’inutile tentativo di leggere documenti in PDF che erano stati salvati in modo da proteggerli contro la copia, ma che, proprio per questa ragione, erano completamente muti per chi vi accedeva con una sintesi vocale.

Vediamo ora come realizzare un modulo PDF accessibile con Acrobat Professional, o meglio servendoci di Adobe LiveCycle Designer, un programma specializzato nella produzione e revisione di moduli in formato PDF, che può essere lanciato direttamente da Acrobat Professional.

La Figura 13.10 mostra l’area di lavoro di LiveCycle Designer. L’elemento principale, posto al centro della finestra e contrassegnato con il numero 1, è la Design View, cioè la vista progettuale: una sorta di tavolo di montaggio, sul quale è possibile inserire e modificare campi ed etichette dei moduli che saranno salvati in PDF. Il documento in fase di redazione mostrato nell’immagine è un modulo per inviare dati personali e commenti, che abbiamo realizzato a titolo d’esempio, per testare le funzionalità del programma.

Senza entrare in troppi dettagli sull’uso di LiveCycle Designer, indichiamo alcuni degli strumenti presenti nell’area di lavoro, per la loro diretta utilità nella progettazione di moduli accessibili. Il blocco contrassegnato con il numero 2, chiamato Hierarchy, mostra sotto forma di albero la gerarchia del documento. L’etichetta con cui sono identificati nell’albero i contenuti della pagina dipende dalla marcatura strutturale che vi viene applicata. Per esempio, l’elemento contrassegnato come Header rappresenta il titolo “Informazioni di contatto”, al quale abbiamo assegnato il ruolo strutturale di intestazione, affinché anche gli utenti di screen reader lo possano riconoscere come un titolo.

Il blocco contrassegnato con il numero 3 fornisce informazioni di aiuto sugli strumenti e le procedure dell’interfaccia utente di LiveCycle Designer. Il blocco 4, invece, consente di applicare caratteristiche di formattazione ai testi, relative ai caratteri e ai paragrafi.

Lo strumento per assegnare ruoli strutturali ai contenuti è il blocco etichettato con il numero 5, che contiene le finestre Object, Layout, Border e Accessibility. Tramite la prima è possibile, tra le altre cose, definire il tipo di controllo di modulo, assegnargli valori predefiniti, stabilire se è obbligatorio per l’utente compilarlo oppure no. La più importante per i nostri fini è ovviamente l’ultima finestra, Accessibility, che consente di impostare testi alternativi sia per le etichette visibili dei campi modulo sia per le immagini (Figura 13.11). Per mezzo di essa è possibile, inoltre, attribuire un ruolo strutturale agli oggetti che non sono campi modulo, scegliendo tra le categorie titolo, tabella ed elenco, e tra alcune sottocategorie.

I testi alternativi, associabili a ogni tipo di oggetto, vanno inseriti nei due campi Tool Tip e Custom Screen Reader Text. Il menu Screen Reader Precedence serve, invece, per definire l’ordine di precedenza dei testi associati a un oggetto, se ve n’è più d’uno. Se si sceglie Custom Text, lo screen reader leggerà per primo il testo inserito nel campo Custom Screen Reader Text; se si sceglie, invece, la voce Tool Tip, lo screen reader leggerà per primo il testo inserito nel campo omonimo. Si noti che il testo inserito nel campo Tool Tip viene visualizzato a schermo, al passaggio del mouse sull’oggetto al quale è associato, con lo stesso meccanismo usato dai browser per visualizzare i contenuti dell’attributo title nei documenti HTML.

I testi alternativi possono essere utilizzati anche per fornire una forma estesa alle eventuali abbreviazioni, usate come etichette visibili sulla pagina. Nel modulo in Figura 13.11, per esempio, nel campo Tool Tip è stata inserita la forma estesa “Codice di avviamento postale”, che sarà letta da uno screen reader al posto dell’etichetta “C.A.P.”, usata per brevità nella vista grafica.

Il metodo di lavoro, anche partendo da una pagina vuota, è semplicissimo. Si scelgono dalla libreria (Figura 13.12), uno dopo l’altro, gli oggetti con cui si intende popolare la pagina e li si trascina sulla Design View, spostandoli poi nella posizione che si preferisce e dando loro le dimensioni e l’allineamento voluti. I risultati delle varie operazioni compiute in Design View possono essere testati ogni volta che sia necessario, passando alla scheda Preview PDF.

Una volta che si è terminato di impostare funzioni, etichette, testi alternativi e formattazione dei vari elementi inseriti sulla pagina, occorre non dimenticare un passo essenziale per l’accessibilità di un modulo in PDF: il controllo dell’ordine di lettura.

Riguardo quest’ultimo aspetto, il primo passo da fare consiste nel verificare l’ordine corrente. Lo si può fare tramite il comando View → Tab Order, la cui esecuzione fa comparire accanto a ogni oggetto, in alto a sinistra, un numero che rappresenta la sua posizione nell’ordine di lettura del documento da parte di uno screen reader. Se l’ordine visualizzato non corrisponde all’ordine logico (Figura 13.13 A), è possibile modificarlo, servendosi della seguente procedura: si definisce tramite la combinazione Shift + clic quale dev’essere il primo oggetto nell’ordine di lettura e, a seguire, si cliccano uno dopo l’altro tutti gli altri oggetti presenti sulla pagina, seguendo l’ordine logico desiderato (Figura 13.13 B). Al termine dell’operazione, la ripetizione del comando View → Tab Order farà scomparire la visualizzazione dei numeri accanto agli oggetti.

Un altro elemento essenziale per l’accessibilità dei moduli in PDF è la possibilità di firmarli digitalmente, in modo che il ricevente sappia con certezza l’identità del mittente. Questa funzione – se disponibile e certificata – libererebbe tutti noi dall’obbligo di recarci di persona presso uno sportello pubblico o privato, solo per consegnare un modulo compilato e firmato. Non soltanto chi è disabile o malato, ma chiunque non abbia il tempo o la voglia di andare di persona presso un ufficio, potrebbe risolvere il proprio problema di comunicazione con l’amministrazione, spedendo tramite Internet un modulo PDF con i dati richiesti, reso valido a tutti gli effetti di legge da una firma certificata. Considerando la quantità di documenti che i cittadini scambiano quotidianamente con le Pubbliche Amministrazioni, si tratta di una funzione di assoluta importanza, in termini di risparmio di risorse per i cittadini e per lo Stato, purtroppo ancora non debitamente utilizzata.

LiveCycle Designer consente due tipi di firma digitale, Document Signature e Data Signature. La prima protegge l’aspetto degli oggetti del modulo e i dati in essi contenuti; la seconda protegge i dati del modulo e ne garantisce l’integrità durante la trasmissione.

Tutte le operazioni per associare certificati ed enti certificatori a un oggetto firma digitale, in un modulo creato con LiveCycle Designer, possono essere fatte tramite la finestra Document Signature Settings, mostrata in Figura 13.14.

Con l’eventuale inserimento di un oggetto firma digitale, la composizione di un modulo PDF accessibile può dirsi completa. Non resta a questo punto che distribuirlo e testarlo per verificarne sul campo l’accessibilità.

Il sistema di verifica veloce dell’accessibilità di Adobe Reader 8 ci informa che il modulo di esempio che abbiamo realizzato con LiveCycle Designer non presenta errori di accessibilità riscontrabili in automatico (Figura 13.15).

La prova essenziale è naturalmente quella fatta con uno screen reader, navigando solo con la tastiera: se un modulo in PDF risulta difficilmente comprensibile e utilizzabile da un utente di screen reader, è essenziale apportarvi delle modifiche. La Figura 13.16 mostra una fase della compilazione del nostro modulo di esempio, che si è svolta senza problemi, usando la tastiera e, come screen reader, Window-Eyes 6.0. Da notare il meccanismo rapido di selezione della data, che nella versione 8 di Adobe Reader si attiva automaticamente, quando il focus viene passato a un campo data.

Inizio pagina

Aggiungere struttura e modificare l’ordine di lettura

La finestra di dialogo Lettura documento senza tag, mostrata in Figura 13.17, compare quando viene aperto in Adobe Reader un documento PDF non strutturato e il programma si accorge, interrogando le API per l’accessibilità del sistema operativo, che c’è uno screen reader collegato. L’utente ha allora tre scelte:

• quella raccomandata, che consiste nel lasciare che sia Adobe Reader a determinare l’ordine di lettura migliore, analizzando la disposizione dei testi all’interno del documento, la presenza di separatori tra le colonne ecc.;
• imporre un ordine di lettura presunto, che parte dall’angolo superiore sinistro delle pagine e prosegue riga per riga verso destra e verso il basso;
• richiedere che i contenuti vengano passati allo screen reader nella stessa sequenza prevista dal flusso di stampa del file PDF.

Il metodo migliore è in genere il primo, quello consigliato. Tuttavia, non è sufficiente a produrre un risultato accettabile, quando il documento PDF ha una struttura grafica complessa, fatta per esempio di titoli di diversa grandezza, colonne di testo non uniformi, blocchi irregolari e contenuti accessori intervallati ai contenuti principali. In casi simili, l’ordine di lettura può produrre risultati incomprensibili o comunque non essere in grado di restituire il vero ordine logico del documento (ben riconoscibile da chi può esaminarlo con la vista). Per migliorare l’esperienza dell’utente di screen reader, sarebbe utile perciò trattare per l’accessibilità i PDF che hanno struttura grafica complessa, inserendo marcatori strutturali e segnalibri, e riorganizzando l’ordine di lettura del documento.

Inizio pagina

Problemi di accessibilità di un PDF non strutturato

Tipici esempi di PDF che necessiterebbero di interventi per l’accessibilità sono le prime pagine dei quotidiani diffusi sul Web. I siti di molti quotidiani italiani offrono ai lettori la possibilità di consultare non solo l’edizione online del giornale, ma anche di scaricare e leggere in locale la versione in PDF della prima pagina (e a volte dell’intero quotidiano), che è, dal punto di vista grafico e contenutistico, la copia esatta dell’edizione cartacea venduta nelle edicole. Si tratta di un servizio molto utile, perché permette al lettore collegato via Internet di avere l’esatta visione dei contenuti del giornale stampato, che l’edizione in HTML spesso non riporta integralmente. Inoltre, l’edizione in PDF consente di ricavare l’importanza relativa che il giornale attribuisce alle notizie, esaminando la grandezza dei titoli, il numero di colonne e lo spazio occupati da ciascun articolo, il taglio alto o basso in cui gli articoli sono posizionati.

Tutte queste informazioni, purtroppo, risultano parzialmente o totalmente inaccessibili agli utenti di screen reader, se il PDF non è strutturato e se l’ordine di lettura inferito da Adobe Reader non corrisponde all’ordine logico dei contenuti.

Abbiamo analizzato varie pagine in PDF, tratte dai siti web di diversi quotidiani italiani, e tutte quante sono risultate prive di struttura e afflitte da notevoli problemi nella lettura con uno screen reader.

Nel seguito del paragrafo mostreremo i problemi di leggibilità di un PDF non strutturato, spiegando poi come aggiungere struttura e modificare l’ordine di lettura del documento, in modo da renderlo facilmente navigabile e comprensibile da un utente di screen reader. Per questo nostro esempio, useremo la prima pagina del quotidiano la Repubblica del 6 marzo 2007, che chiunque sia interessato a ripetere la nostra prova può scaricare dall’indirizzo http://download.repubblica.it/pdf/diario/2007/06032007.pdf , come parte di un file PDF contenente un numero del supplemento Diario di Repubblica.

Usando la nostra versione demo di Adobe Acrobat 8 Professional, eliminiamo le pagine del Diario e lasciamo solo la prima pagina del giornale, salvata in un nuovo file PDF, che diamo “in pasto” a JAWS 8.0, anch’esso in versione demo, con durata di 40 minuti per sessione.

La lettura con JAWS dà pessimi risultati, nonostante il tentativo di Adobe Reader di determinare un valido ordine di lettura (i medesimi risultati si ottengono anche facendo leggere la pagina dal lettore vocale integrato nelle ultime versioni di Adobe Reader).

La mancanza di titoli e di segnalibri, unita al disordine con cui i contenuti della pagina sono stati registrati nel PDF, rende impossibile capire dove cominci e dove finisca ciascun articolo. Quelli che sulla pagina appaiono come titoli sono letti talvolta dalla sintesi vocale dopo il testo che dovrebbe seguirli e, in ogni caso, sono attaccati alla fine del pezzo precedente, senza soluzione di continuità. L’ordine in cui gli articoli sono letti dalla sintesi vocale è, inoltre, completamente diverso da quello che è l’ordine gerarchico ricavabile dalla composizione grafica della pagina.

Osservando i numeri associati ai blocchi di contenuto nella Figura 13.18, è possibile capire fino a che punto la comprensibilità sia messa in crisi dalla mancanza di ordine nella lettura dei testi.

Proviamo a elencare alcuni dei fattori di confusione derivanti dall’ascolto di questo PDF non strutturato e, in generale, non trattato per l’accessibilità:

• non è possibile navigare per titoli. Premendo la lettera “H”, che permetterebbe di saltare da un titolo al successivo, JAWS avverte che nella pagina non è presente alcun titolo;
• l’intestazione “la Repubblica”, con i suoi caratteri cubitali, è fatta di oggetti grafici privi di testo alternativo. Come conseguenza, il titolo del quotidiano non viene letto dalla sintesi vocale;
• il sintetizzatore comincia la lettura snocciolando un’incomprensibile serie di cifre e lettere (“9 770390 107009 70306 CLDODHDEDU”). Si tratta dei codici a barre posti in alto a sinistra;
• il titolo principale di quel giorno (“Afghanistan, altri civili uccisi”) è solo il diciottesimo blocco di testo nell’ordine di lettura;
• l’articolo a esso collegato (numero 3: “La terza via italiana nella trappola di Kabul”) viene letto molto prima del titolo da cui dipende;
• il testo che dovrebbe essere letto subito dopo il titolo numero 3, identificato nell’immagine col numero 21, viene letto invece molto dopo, perdendo qualsiasi legame di appartenenza.

Si potrebbe continuare a lungo nell’elenco delle incongruenze, ma pensiamo che quanto segnalato basti a suggerire la necessità di intervenire per migliorare l’accessibilità ogni volta che sia possibile, soprattutto se si ha a che fare con dei PDF complessi, come sono le prime pagine dei quotidiani diffuse via Web.

Inizio pagina

La verifica completa di accessibilità di Adobe Acrobat

È tempo, dunque, di esaminare le procedure con le quali possiamo rendere accessibile la pagina in Figura 13.18 (o qualsiasi altro PDF afflitto da analoghi problemi di leggibilità).

In primo luogo, osserviamo quali strumenti per l’accessibilità offre Acrobat 8 Professional. Sono di tre tipi: a) strumenti di configurazione dell’interfaccia utente, b) di analisi e c) di modifica del documento. Li vediamo elencati nel menu Advanced → Accessibility, mostrato in Figura 13.19.

Tolte le funzioni di configurazione del programma (Change Reading Options… e Setup Assistant…), le funzioni utili ai nostri scopi sono quelle di analisi e di modifica del documento. Per avere un’analisi dettagliata delle caratteristiche di accessibilità del PDF correntemente aperto, occorre eseguire una verifica completa, impostandone i parametri nella finestra di dialogo mostrata in Figura 13.20, a cui si giunge selezionando dal menu Accessibility la voce Full Check.

La finestra Accessibility Full Check permette di scegliere se la valutazione automatica deve essere effettuata sulla base delle linee guida per l’accessibilità di Adobe, della legge americana sull’accessibilità (la cosiddetta Section 508), delle WCAG 1.0 o delle non ancora definitive WCAG 2.0.

Nel caso si scelga il controllo basato sulle linee guida di Adobe, le caselle di opzione disponibili consentono di attivare o disattivare le verifiche che seguono.

• Sono presenti descrizioni alternative?
• Sono presenti informazioni sulla lingua?
• La codifica dei caratteri produce risultati affidabili?
• I contenuti sono tutti inclusi nella struttura del documento?
• I campi modulo hanno tutti un’etichetta?
• L’ordine di tabulazione è coerente con l’ordine strutturale?
• Elenchi e tabelle sono correttamente strutturati?

Scegliendo invece uno degli altri tre tipi di verifica, le caselle di opzione cambiano in modo da rispecchiare le linee guida della Section 508 americana o i livelli di priorità delle WCAG 1.0 e 2.0, in base alla scelta fatta dall’utente.

Per quanto sia articolata e configurabile, la verifica di accessibilità di Acrobat 8 è in ogni caso una valutazione automatica, che, come la stessa Adobe precisa nella nota al fondo della finestra (Figura 13.20), non può sostituirsi alla valutazione umana, poiché non è in grado di determinare con certezza se il documento analizzato soddisfi realmente le specifiche per l’accessibilità impostate come riferimento. Ciò premesso, resta comunque un valido punto di partenza, per definire una strategia di potenziamento dell’accessibilità in documenti PDF come quello che stiamo esaminando.

Il sommario riassuntivo della verifica completa fatta sul PDF della prima pagina di Repubblica, usando il controllo basato sulle linee guida di Adobe, è mostrato in Figura 13.21.

Il sommario ci informa che nessuna immagine è fornita di testo alternativo, che non è stata specificata la lingua per nessun blocco di testo, che c’è una parola che contiene caratteri non riproducibili in modo affidabile per mezzo della tabella caratteri di Unicode.

Il rapporto completo contiene i collegamenti a ciascuna delle 17 immagini trovate prive di testo alternativo e in più i suggerimenti per riparare tutti e tre i tipi di errore riscontrati dalla verifica automatica. Tocca naturalmente all’utilizzatore umano decidere se e quale degli errori segnalati meriti di essere riparato. Tra le immagini prive di testo alternativo vi sono, per esempio, quelle pubblicitarie, per le quali potrebbe essere appropriato lasciare le cose come stanno, per evitare all’utente di screen reader l’ascolto di un surplus di dati privi di vero valore informativo.

Inizio pagina

Pregi e difetti della strutturazione automatica di un PDF

Mettiamo da parte momentaneamente l’inserimento di testi alternativi e dedichiamoci a un primo e più importante intervento: aggiungere tag, cioè marcatori strutturali, così da rendere possibile una navigazione per titoli all’interno del documento. Il PDF, infatti, non è strutturato, come ha ampiamente dimostrato la prova effettuata con Adobe Reader e con JAWS, ma come attesta anche la sezione Advanced della finestra File → Properties → Document Properties di Acrobat 8 Professional (Figura 13.22).

Per aggiungere struttura a un PDF, cominciamo con il selezionare la voce Add Tags to Document nel menu Accessibility. Quest’operazione mostra un testo di aiuto con le informazioni di base che occorre conoscere per operare correttamente. In breve, si tratta di circoscrivere con rettangoli di delimitazione i vari blocchi di contenuto sulla pagina, seguendo il loro ordine logico e assegnando poi a ciascuno di essi un valore strutturale, che può essere scelto tra undici differenti categorie, che sono: 1) testo; 2) campo modulo; 3) titolo di primo livello; 4) titolo di secondo livello; 5) titolo di terzo livello; 6) figura; 7) figura con didascalia; 8) tabella; 9) cella di tabella; 10) formula; 11) sfondo.

Lo strumento per disegnare i rettangoli di delimitazione e per assegnare loro valori strutturali è una finestra di dialogo chiamata TouchUp Reading Order, anch’essa invocabile dal menu Advanced → Accessibility. L’apertura di questa finestra provoca, in un documento non strutturato come quello del nostro esempio, la creazione di una suddivisione automatica in regioni, con attribuzione, anch’essa automatica, di ruoli e ordine di lettura. Ne possiamo vedere l’effetto nella cattura di schermo riportata in Figura 13.23.

La suddivisione automatica creata da Acrobat è sicuramente migliore del disordine generale testimoniato dalla sequenza di numeri della Figura 13.18, tuttavia non è ancora una soluzione del tutto accessibile. Vediamone brevemente pregi e difetti. I pregi consistono nel fatto che ora la pagina è suddivisa in quindici titoli, che permettono di passare da un articolo all’altro in modo rapido e, soprattutto, di riuscire ad avere con uno screen reader una “visione” abbastanza fedele della struttura della pagina.

I difetti dipendono in parte dall’ordine di lettura ancora non perfetto, in parte dalla mancanza di raggruppamento dei contenuti omogenei e in parte dalla mancanza di testi alternativi per gli oggetti grafici.

Per esempio, al posto del titolo “la Repubblica”, lo screen reader legge “graphic”, ma le scritte “fondatore Eugenio Scalfari e “direttore Ezio Mauro” vengono lette subito dopo e mettono l’ascoltatore sulla buona strada (se il file viene scaricato in locale, non è detto che l’utente sappia che sta leggendo un PDF contenente una prima pagina di Repubblica, soprattutto perché il nome del file scaricato dal sito del quotidiano non è significativo).

Un altro elemento da correggere è la posizione della lunga serie di informazioni sui costi del giornale all’estero. Queste informazioni, molto noiose, dovrebbero essere riposizionate alla fine dell’ordine di lettura, se non addirittura escluse, invece che trovarsi all’inizio, come sono ora. Certamente esclusi dovrebbero essere, poi, i testi che riproducono i codici a barre.

Anche per quanto riguarda i titoli degli articoli ci sono delle correzioni da fare. Per esempio, la suddivisione automatica ha separato impropriamente il titolo principale della pagina (“Afghanistan, altri civili uccisi”) e quelli che in gergo giornalistico si chiamano occhiello (“Oggi il voto alla Camera sulla missione ecc.”) e catenaccio (“D’Alema: siamo turbati e preoccupati ecc.”) dal testo a essi collegato (“L’analisi. La terza via italiana nella trappola di Kabul”). Ciò che segue immediatamente è, invece, l’occhiello di un altro articolo (“Bertinotti: ma serve l’ok di tutto il centrosinistra”).

Inizio pagina

Definizione manuale della struttura e dell’ordine di lettura

Poiché il resto della pagina presenta anche altre incongruenze piccole e grandi, la cosa migliore da fare è cancellare semplicemente la suddivisione automatica fatta da Adobe Acrobat e ricominciare da zero, decidendo noi le aree da delimitare e il valore da attribuire ai loro contenuti. Lo strumento per eliminare l’attuale struttura è il pulsante Clear Page Structure, posto in basso a sinistra nella finestra TouchUp Reading Order. Premendolo, scompaiono dalla pagina le regioni e i relativi numeri d’ordine, che erano stati creati automaticamente dal programma.

Il meccanismo per riorganizzare la struttura e l’ordine di lettura del documento è molto semplice. Con la finestra TouchUp Reading Order aperta (Figura 13.24), si traccia un rettangolo intorno a quello che si ritiene debba essere il primo oggetto della pagina letto da uno screen reader.

Dopo di ciò, si sceglie nella finestra TouchUp Reading Order il pulsante che rappresenta il valore strutturale che si vuole attribuire all’oggetto delimitato dal rettangolo appena tracciato. Si ripete poi lo stesso procedimento solo ed esclusivamente per gli oggetti della pagina che si desidera vengano letti da uno screen reader. La Figura 13.25 mostra il risultato di questa operazione. Come si può notare, abbiamo omesso di inserire tra i contenuti marcati la parte della testata contenente le immagini pubblicitarie, i codici a barre e le informazioni commerciali sull’acquisto del giornale all’estero: lo scopo è, ovviamente, rendere più rapida e meno noiosa la lettura integrale della pagina con una sintesi vocale.

Il lavoro di delimitazione delle aree e di assegnazione di ruoli strutturali trova riscontro e integrazione in un’altra finestra di dialogo, che può essere aperta tramite il pulsante Show Order Panel, posizionato in basso a destra nella finestra TouchUp Reading Order. Questa nuova finestra di dialogo presenta tre viste d’interesse per il nostro lavoro di riorganizzazione della pagina. La vista Order (Figura 13.26 A) mostra in successione numerata tutti i blocchi che abbiano creato tramite la finestra TouchUp Reading Order. Selezionando un blocco dalla vista Order, viene evidenziato sulla pagina il riquadro corrispondente.

La vista Content (Figura 13.26 B) mostra tutti i contenuti del documento, dal singolo oggetto vettoriale, come può essere una linea di delimitazione di un riquadro, identificato dall’etichetta Path, fino agli oggetti di testo, identificati dall’etichetta Text. Vi sono poi gli elementi Container, che rappresentano contenitori di singoli oggetti o di raggruppamenti di oggetti. Possono contenere sia testo strutturato sia oggetti grafici sia una combinazione di tipi.

La terza vista è Tags (Figura 13.26 C), che mostra finalmente qualcosa di familiare per chi proviene dallo sviluppo di codice HTML, XHTML e JavaScript: una serie di nodi che rappresentano il DOM del PDF strutturato, i quali hanno come genitori gli elementi <H1>, <H2>, <P> ecc., corrispondenti ai ruoli strutturali che avevamo applicato nella finestra TouchUp Reading Order, e come figli i contenuti testuali o grafici che avevamo marcato con quei ruoli.

È facile comprendere quali possibilità di manipolazione dei contenuti, del loro ordine e della loro struttura siano possibili, utilizzando in modo appropriato le tre viste che abbiamo descritto. I nodi, infatti, possono essere spostati, copiati, incollati, cancellati o creati ex novo. Per ogni nodo, è possibile accedere a un menu contestuale che contiene svariate opzioni, differenti a seconda della vista e del tipo di oggetto. Dalla vista Tags è possibile, per esempio, accedere alla finestra di dialogo TouchUp Properties (Figura 13.27), che consente, tra molte altre cose, di inserire testi alternativi e informazioni sulla lingua, e di modificare il ruolo strutturale dell’oggetto, scegliendo da una gamma di ruoli ben più ampia degli undici presenti nella finestra TouchUp Reading Order.

Ascoltando ora la pagina con JAWS, l’effetto è completamente diverso. Le informazioni noiose (codici a barre, costi all’estero ecc.) non vengono più lette, l’ordine e la concatenazione degli articoli è molto più comprensibile. Resta da fare una regolazione fine: modificare in qualche caso l’ordine di lettura e aggiungere qualche testo alternativo.

Inizio pagina

Modificare l’odine di lettura

Le modifiche dell’ordine di lettura possono essere fatte rapidamente usando le viste Order e Content. Tramite la prima, possiamo cambiare l’ordine di interi blocchi, spostandoli in su o in giù lungo l’albero del documento o possiamo addirittura eliminare dei blocchi, se è il caso. Tra quelli che necessitano di essere riordinati, vi sono per esempio i blocchi che in Figura 13.25 appaiono marcati con i numeri 25, 7, 26, 6. Dovrebbero infatti trovarsi in sequenza e perciò li riordiniamo, in modo che divengano rispettivamente i numeri 10, 11, 12 e 13 nell’ordine di lettura. Anche l’articolo di spalla (“I sette peccati capitali di Internet ecc.”) è fuori ordine: per via di spostamenti nella finestra Order, facciamo perciò in modo che le posizioni 14 e 16, relative al titolo e al testo dell’articolo, divengano rispettivamente la 6 e la 7. Elimiamo infine il blocco numero 3, che forniva informazioni non indispensabili sul numero di serie del giornale e sul suo prezzo in edicola.

Vale la pena di precisare che spostamenti ed eliminazioni di blocchi riguardano unicamente l’ordine di lettura da parte di uno screen reader: nella pagina visibile non cambia assolutamente nulla.

Ci resta ora da fare un piccolo aggiustamento dell’ordine di lettura all’interno di uno stesso blocco. È capitato, infatti, che l’inizio del testo di un articolo, a causa della presenza di un capolettera, è stato ordinato da Acrobat in modo erroneo. Per questo tipo di regolazione, la vista Order (Figura 13.26 A) non è utile, dal momento che elenca soltanto i blocchi e non i loro componenti interni. Ciò che fa al caso nostro è invece la vista Content (Figura 13.26 B), che ci permette di scendere fino al livello della singola stringa di testo. Così, dopo aver localizzato nella vista Content il blocco che ci interessa correggere, ne apriamo i contenuti e li riordiniamo, trascinandoli nella posizione richiesta dalla sequenza logica del testo. La Figura 13.28 mostra la sequenza dei contenuti del blocco prima e dopo l’intervento di riordinamento.

Inizio pagina

Testi alternativi, collegamenti, lingua del documento

Proseguiamo nel lavoro di messa a punto dell’accessibilità, aggiungendo, dove servono, testi alternativi alle immagini. Inserire un testo alternativo è estremamente semplice. Se abbiamo marcato correttamente le immagini applicando loro il tag Figure, ciascuna di esse apparirà sulla pagina contrassegnata dall’etichetta su sfondo nero Figure – No alternate text exists. La Figura 13.25 ne mostra due esempi. Basterà a questo punto aprire col tasto destro il menu contestuale sull’etichetta della figura a cui si vuole fornire un equivalente testuale e scegliere il comando Edit Alternate Text, che apre a sua volta la finestra di dialogo Alternate Text. All’interno di questa finestra va scritto il testo alternativo, che apparirà poi sulla pagina all’interno dell’etichetta della figura e, soprattutto, sarà letto dagli screen reader al posto dell’indefinita voce “graphic” (Figura 13.29).

Un altro elemento utile in un PDF accessibile sono i collegamenti ipertestuali, sia interni, con lo scopo di velocizzare la navigazione tra le parti del documento, sia esterni (anche se questi ultimi sono da usare con attenzione, perché possono generare disorientamento, dal momento che producono il passaggio del focus dall’interfaccia del programma per la lettura dei PDF all’interfaccia del browser web).

Per creare un collegamento ipertestuale in un PDF tramite Acrobat 8 Professional, si sceglie dal menu Tools il comando Advanced Editing → Link Tool; si traccia poi un rettangolo di delimitazione intorno all’oggetto che si vuole trasformare in collegamento. L’area racchiusa dal rettangolo corrisponde all’area attiva del link. Una volta tracciato il rettangolo, il programma apre automaticamente la finestra Create Link (Figura 13.30), attraverso la quale è possibile definire l’aspetto grafico del collegamento, gli eventuali effetti di attivazione e il tipo di azione generata, scegliendo tra quattro opzioni: a) passaggio a un punto preciso dello stesso documento, b) apertura di una pagina web, c) apertura di un file, d) azione personalizzata.

Proseguendo il nostro lavoro di messa a punto del PDF della prima pagina del quotidiano la Repubblica, decidiamo di inserire un collegamento ipertestuale al sito web del giornale, applicandolo, tramite la procedura appena descritta, sul blocco che contiene la stringa “www.repubblica.it”, posto sulla destra della testata. Scegliamo dunque dalla finestra Create Link l’opzione Open a web page, che apre la finestra di dialogo Edit URL (Figura 13.31), nella quale inseriamo l’indirizzo web del sito del quotidiano.

Il risultato finale dell’operazione appare sulla pagina come un rettangolo disegnato intorno all’oggetto marcato come collegamento ipertestuale (Figura 13.32).

In documenti lunghi e complessi come, per esempio, le Specifiche W3C, la presenza di link interni ed esterni, insieme a quella di segnalibri, è essenziale per consentire una navigazione rapida tra argomenti semanticamente collegati.

L’ultimo passo che ci resta da compiere è l’impostazione della lingua del documento. Scegliamo così la voce Italian, selezionandola dalla tendina associata all’opzione Language, presente nella sezione Reading Options della scheda Advanced, all’interno della finestra di dialogo Document Properties, alla quale si giunge tramite la voce di menu File → Properties (Figura 13.33).

Inizio pagina

Considerazioni su tempi e metodi di lavoro

Il risultato finale del nostro lavoro per l’accessibilità sulla prima pagina in PDF del quotidiano la Repubblica è mostrato in Figura 13.34, nella quale sono visibili le regioni in cui abbiamo riordinato i contenuti, con i loro numeri definitivi, che garantiscono una sequenza di ascolto logica e comprensibile. I titoli principali, inoltre, sono stati trasformati in altrettanti segnalibri, elencati nella finestra Bookmarks.

I numerosi passaggi illustrati in questi paragrafi dedicati all’accessibilità dei PDF possono aver lasciato nel lettore l’impressione che strutturare e riorganizzare questo tipo di documenti siano operazioni estremamente lunghe e difficoltose, tanto da scoraggiare chi avesse l’intenzione di produrre PDF accessibili. In realtà non è così. La spiegazione e la descrizione delle procedure da seguire sono molto più lunghe e noiose delle procedure stesse. Lo strumento TouchUp Reading Order di Adobe Acrobat rende la marcatura di una pagina, anche molto complessa come è quella di un quotidiano, un affare di pochi minuti. Le correzioni dell’ordine di lettura che possono essere apportate tramite la finestra Order sono ancora più rapide.

Ciò che porta via il tempo maggiore è senz’altro la fase di test. Non si può, infatti, dichiarare di aver reso accessibile un PDF, se ci si è limitati a impostare un ordine di lettura basato sulla sola logica. È indispensabile, invece, verificare con uno screen reader se la propria idea di ordine logico dei contenuti corrisponde ai fatti, cioè se l’ascolto sequenziale del documento produce un risultato comprensibile e se la sua suddivisione in titoli, paragrafi, tabelle, segnalibri ecc. consente una navigazione rapida e sicura tra i contenuti. Ma con un po’ di esperienza si riescono ad accorciare sensibilmente i tempi: non è necessario, infatti, ascoltare e riascoltare i contenuti dall’inizio alla fine, soprattutto quando sono molto lunghi. Una volta definiti i blocchi, marcate le figure e inseriti i testi alternativi, nulla impedisce di usare le scorciatoie dello screen reader per saltare di titolo in titolo e di paragrafo in paragrafo, ascoltando il minimo indispensabile per essere sicuri che la sequenza impostata sia quella corretta.

Inizio pagina

Accessibilità visiva dei PDF

Adobe Reader, che è il programma solitamente usato per la lettura di documenti PDF, dispone di un assistente interno per l’accessibilità, chiamato Assistente Installazione accesso facilitato, che permette di attivare alcuni ausili per ipovedenti e non vedenti. Abbiamo già esaminato in uno dei precedenti paragrafi la funzione che determina automaticamente l’ordine di lettura in PDF non strutturati. Ci interessano ora gli ausili per l’ipovisione. Si tratta delle seguenti quattro impostazioni, attivabili tramite la seconda delle cinque schede di configurazione dell’assistente per l’accessibilità di Adobe Reader versione 8 (Figura 13.35):

1. la sovrascrittura dei colori di primo piano e di sfondo del documento con combinazioni ad alto contrasto (verde, giallo o bianco su nero oppure nero su bianco);
2. la possibilità di cambiare i colori che evidenziano i campi modulo e, tra i campi modulo, quelli obbligatori, se i colori predefiniti per queste due funzioni sono diventati invisibili a causa dell’uso di una combinazione di colori a contrasto elevato;
3. la disattivazione dell’effetto di addolcimento dei caratteri del testo, che, se da un lato migliora l’aspetto estetico del documento, dall’altro può peggiorare la leggibilità dei caratteri per chi già soffre di limitazioni della vista;
4. la possibilità di rendere sempre attivo il cursore che permette di scrivere nei campi modulo e di selezionare il testo.

La scelta da parte dell’utente di una combinazione di colori a contrasto invertito, che permette una lettura più riposante per chi soffre di fenomeni di abbagliamento, può creare seri problemi di leggibilità, se i testi nel PDF sono in tutto o in parte combinati con elementi grafici o sovrapposti a sfondi colorati. Un esempio di simili problemi è mostrato in Figura 13.36.

La stessa pagina in PDF di Repubblica, che in Figura 13.18 appare perfettamente leggibile (almeno per un normovedente), diventa del tutto illeggibile se si seleziona una modalità di visualizzazione a contrasto invertito, che, nel caso specifico, è testo giallo su sfondo nero.

Il titolo “la Repubblica”, che nella visualizzazione normale è un oggetto grafico nero posto su uno sfondo bianco, scompare completamente. Adobe Reader non è in grado, infatti, di intervenire sui colori degli oggetti grafici, che rimangono perciò invariati. Poiché, invece, lo sfondo generale della pagina può essere cambiato, il risultato è un impossibile accoppiamento di testo (grafico) nero su sfondo nero.

L’esatto opposto succede per i numerosi blocchi di testo non grafico (cioè modificabile) presenti sulla pagina. In questo caso, è il testo a cambiare colore, assumendo dovunque il giallo previsto dalla combinazione a contrasto invertito, applicata tramite la finestra di dialogo Assistente Installazione accesso facilitato. Gli sfondi dei singoli blocchi, invece, non diventano neri come accade al colore di sfondo generale della pagina, ma rimangono inviariati, ciascuno del colore scelto dagli autori dell’impaginato esportato in PDF, rendendo così pressoché invisibili le scritte gialle poste su di essi. Il risultato finale di tutto ciò è la completa inaccessibilità del documento, se l’utente sceglie di passare a una delle combinazione di colori a contrasto invertito di Adobe Reader, come è perfettamente plausibile che accada, se il lettore è un ipovedente.

Come si risolvono simili problemi di accessibilità? Sostanzialmente in due modi, di cui il primo è il più semplice e radicale, ma anche il più difficile da applicare all’interno di progetti grafici complessi:

• evitando di porre il testo su sfondi colorati o grafici ed evitando l’uso di scritte grafiche (per esempio trasformando il titolo “la Repubblica” in un oggetto di testo con le medesime caratteristiche del corrispondente oggetto grafico);
• scegliendo, per i blocchi di testo, colori di sfondo che consentano una buona leggibilità con almeno una delle combinazioni a contrasto invertito, applicabili tramite l’assistente per l’accessibilità di Adobe Reader.

La seconda soluzione richiede un’accurata verifica di leggibilità, fatta controllando direttamente se vi sia almeno una combinazione di colori a contrasto invertito che permetta di mantenere un sufficiente contrasto tra testi e sfondo.

Qui le cose, però, si complicano ulteriormente, perché bisogna considerare che un ipovedente che trova in generale più comodo usare il computer con combinazioni di colore a contrasto invertito, non ha bisogno certo di ricorrere all’assistente per l’accessibilità di Adobe Reader per impostare la combinazione di colori che preferisce. È molto più probabile, infatti, che applichi le combinazioni a contrasto invertito fornite col sistema operativo o con l’ingranditore di schermo che usa abitualmente (anche se le combinazioni a contrasto invertito dei sistemi operativi Microsoft non agiscono sui contenuti di un PDF visualizzato da Adobe Reader). Pertanto, le prove di leggibilità non possono limitarsi alla verifica delle tre combinazioni a contrasto invertito fornite da Adobe Reader.

Insomma, la variabilità dei fattori di configurazione è tale che l’unica vera garanzia di avere un PDF realmente accessibile anche a contrasto invertito è data dall’evitare di porre i blocchi di testo su sfondi colorati o di tipo grafico e, parallelamente, dall’evitare di realizzare testi che non siano realmente testo ma oggetti grafici.

Tuttavia, non è detto che un PDF diventi necessariamente inaccessibile quando visto a contrasto invertito, anche se è composto da blocchi di testo posti su sfondi colorati e da oggetti grafici che rappresentano testo. Tutto dipende, infatti, da come il sistema operativo o la tecnologia assistiva applicano l’inversione del contrasto. Se l’implementazione della funzione da parte di Adobe Reader ha le carenze che abbiamo visto, l’implementazione disponibile nel sistema operativo Mac OS X è al contrario esemplare: i contenuti di pagina vengono trattati tutti allo stesso modo, senza distinzioni tra sfondo generale, sfondo dei blocchi, testo che è veramente testo e testo che è invece un oggetto grafico. Mac OS X fa il negativo della pagina e tutto rimane perciò perfettamente leggibile, purché nella vista normale vi sia tra primo piano e sfondo un livello di contrasto sufficiente (Figura 13.37).

Inizio pagina