PDF accessibili da Word: axesPDF

AxesPDF è un altro di quegli attrezzi senz’altro da avere se desiderate creare file PDF accessibili direttamente da Word 2007/2010.
La beta 3 è disponibile gratuitamente. Attenzione: si tratta di una beta, ed alcune stringhe dei comandi o l’help non sono ancora stati tradotti, così come le etichette di alcune icone. Però è uno strumento così promettente che non posso non presentarlo anche se ancora in fase di sviluppo.

Si tratta di un plugin per Word. Dopo l’installazione, troverete una nuova scheda axesPDF nella barra di accesso rapido. La scheda contiene alcuni pulsanti, che permettono di configurare le opzioni di conversione e creare il PDF.

Bè, che dire, provate, è davvero semplice da usare. La scheda Structure permette di definire nel dettaglio la mappatura degli elementi di tabelle, note, note a piè di pagina, paragrafi e titoli, didascalie.

Le impostazioni di Initial View sono per default già configurate correttamente, ed oltre alle consuete opzioni sono presenti anche due ulteriori controlli per determinare una eventuale pagina speciale dove il file si debba aprire e un fattore di ingrandimento.

Insomma, sono ansioso di vedere la versione commerciale: significherebbe davvero PDF accessibili con un clic, senza interventi a posteriori ed elaborate conversioni.

Le opzioni della scheda Structure di axesPDF.

Le opzioni della scheda Structure di axesPDF.

Annunci

PDF/UA e WCAG2: mappatura dei requisiti

AIIM (Association for Information and Image Management) ha pubblicato un interessante articolo intitolato “Achieving WCAG 2.0 with PDF/UA” che ha lo scopo di articolare l’allineamento tra WCAG 2.0 e ISO 14289-1:2012 (PDF/UA), lo standard internazionale per la tecnologia PDF accessibili.

Così gli sviluppatori di software in grado di elaborare PDF possono ottenere la conformità alle vigenti criteri di successo WCAG 2.0 tramite implementazioni che seguono la mappatura a PDF/UA. In quanto tale, questa mappatura permette di validare un file PDF in formato PDF/UA secondo i criteri delle WCAG 2.0.

È un work in progress, e verrà mantenuta una change history per tenere traccia di eventuali modifiche e aggiornamenti.

L’articolo contiene anche interessanti informazioni riguardo la corretta versione delle specifiche, ed avvisa che la versione finale corretta FDIS di PDF/UA deve avere in copertina la data 2012-08-01. Avevamo parlato in precedenza di questa gaffe di ISO, ora corretta (il PDF dello standard non era conforme a se stesso, e per alcuni giorni non è stato disponibile).

Ottenere la conformità alle WCAG 2.0 con PDF/UA

I 61 criteri di successo delle WCAG 2.0 vengono mappati in una tabella, e Per ciascun criterio, la tabella indica le sottosezioni applicabili di PDF/UA per i rispettivi criteri di conformità per file e reader (software di lettura.

Vengono fornite inoltre tutte le corrispondenze a ISO 32000-1 (ovvero, PDF 1.7).

PDF/UA (ISO 14289-1:2012) disponibile al pubblico

Dopo otto anni di lavoro, da ieri 7 agosto 2012 il testo dello standard ISO PDF/UA (ISO 14289-1:2012) è disponibile al pubblico.

È un passaggio importante per l’accessibilità. Il formato PDF sembra inarrestabile e un documento che faccia da riferimento è fondamentale per lo sviluppo delle tecnologie attuali e future e per l’armonizzazione delle regole.

ISO 14289 ha anche stabilito un record: è il primo standard ISO che parla di accessibilità dei PDF che non è conforme a se stesso. Meglio, il PDF del testo dello standard non supera tutti i punti di controllo. Ok, non è il documento a non essere accessibile, bensì il timbro con la data apposta al momento dell’acquisto su tutte le pagine. No comment.

Modulistica in PDF o HTML compilabile online e offline

La modulistica, che sia in PDF o HTML è uguale, è sempre un bel problema. Complessità di progettazione, design, interazione, test… Un form complesso può richiedere un lungo lavoro, e poi bisogna pensare alla distribuzione, alla raccolta ed elaborazione dei dati, magari installare un server dedicato, insomma una cosa complicata e costosa.

Per questo motivo mi sembra veramente utile presentare un servizio di Adobe, chiamato FormsCentral.

Nel prossimo Acrobat X 11 l’editor di form non sarà più LiveCycle, che probabilmente diventerà una applicazione separata, e FormsCentral sarà parte dell’installazione. A mio parere questo faciliterà di molto la creazione di questi elementi complessi sia tramite una quantità esagerata di modelli predefiniti sia semplificando tutte le attività necessarie dalla creazione alla distribuzione alla raccolta e analisi dei dati. I form potranno essere distribuiti in PDF o HTML.

Il costo dell’hosting Adobe è davvero buono, il caso più costoso (illimitati form, elaborazione fino a 5.000 utenti per form) costa circa 180 euro l’anno, senza dover pensare a installare e configurare server in azienda.

Interfaccia di FormsCentral

Per dubbi o per decidere quale metodo usare per i vostri form, Acrobat o FormsCentral, è utile leggere l’articolo “Which Adobe form solution is right for me” sul sito Adobe e consultare l’elenco delle domande/risposte disponibile.

 

 

PDF accessibili: qualche novità in arrivo

pdf universal accessibleIl lavoro di Adobe sul formato PDF riguardo l’accessibilità è instancabile. Il formato PDF/UA (Universal Accessible) è ormai allo stato di “FDIS” (Final Draft International Standard) e diventerà ISO 14289 nel terzo quadrimestre 2012.

Ricordo che lo scopo principale di ISO 14289 (conosciuto come PDF/UA) è quello di definire una rappresentazione dei documenti elettronici in formato PDF in modo che questi file siano accessibili e le loro caratteristiche direttamente mappabili alle WCAG 2.0.

Inoltre, Adobe ha stretto una intesa con gli sviluppatori dello screen reader NVDA, screen reader open source, per dotare questo screen reader gratuito di un eccellente supporto al nascente formato, oltre che alle applicazioni AIR (per esempio, Adobe  Digital Edition), ai libri in epub e in genere ad HTML ed ARIA.

Non male.

Il tagging di file PDF ed Epub in Indesign 6

Tempo fa su questo blog si parlava delle procedure di corretto tagging dei documenti allo scopo di ottenere PDF accessibili e delle procedure necessarie per determinare la corretta Mappa ruolo. Cose un po’ noiose e complesse, ma necessariamente da svolgere a mano in post-produzione.
Mi fa quindi molto piacere notare come nelle nuove versioni di Indesign (a partire dalla 5.5) sia stato aggiunto un nuovo pannello che permette di eseguire con semplicità le operazioni di mappatura necessarie direttamente all’interno del programma.
La finestra di dialogo Paragraph Style Option tramite la scheda Export Tagging permette di definire per ciascuno stile di paragrafo personalizzato il corrispondente tag Epub (e HTML) e/o PDF tramite un elenco a discesa.
Per Epub e HTML è inoltre possibile associare direttamente una classe CSS, così da automatizzare anche la presentazione a monitor del documento.
In questo modo sarà molto semplice ottenere file già correttamente strutturati, senza dover intervenire a posteriori, rispettando quella semantica degli elementi così importante per l’accessibilità e la corretta interpretazione dei documenti da parte di tutti i device.

La finestra di dialogo Paragraph Style Options di Indesign

Un file PDF/A è un PDF accessibile?

acrobat PDF/A o PDF/UA? l'acrobata.Giusto per dire che PDF/A non significa PDF Accessibile… si nota un po’ di confusione a questo proposito (non chiedetemi nomi e cognomi, suvvia).

PDF/A  è uno standard nato per documenti destinati ad essere conservati per lungo tempo, ed è un sottoinsieme del formato PDF 1.4 da cui deriva (è uno standard ormai superato, che a breve sarà soggetto a revisione).

L’obbiettivo di questo formato è quello di preservare la grafica originale dei documenti, e quindi per esempio obbliga ad incorporare le font nel PDF stesso e senza limiti di copyright, così come non permette l’uso delle trasparenze o di contenuti audio e video: tutte le informazioni necessarie per la visualizzazione del documento devono essere incorporate, JavaScript non è ammesso, e così via.

In ogni caso, non è per niente detto che un PDF/A sia anche accessibile… anzi, facile che non lo sia, poiché lo standard prevede la presenza della struttura, ma nella variante PDF/A-1A. I PDF/A normalmente disponibili rispondono ai requisiti di PDF/A-1B (il livello minimo dello standard), senza struttura logica. Di conseguenza, sono accettabili anche PDF contententi esclusivamente scansioni (certo nelle richieste della normativa vigente andrebbe specificato il ivello da utilizzare), e comunque la sola struttura non è sufficiente.

Ben diverso è l’obiettivo di PDF/UA (PDF Universal Accessible). In questo caso, il gruppo di lavoro è all’opera per definire una specifica per PDF accessibili (la publicazione del relativo documento ISO 14289-1 è attesa nel 2012).

Meglio saperlo.

Photoshop e il testo sgranato

Anche se non è il suo lavoro, molti grafici utilizzano Photoshop per realizzare bozzetti da utilizzare come traccia per siti Web, blocchi di testo segnaposto compresi. È facile capire perché: oltre a una forse precedente esperienza con il programma, certamente Photoshop è un potentissimo software per fare grafica bitmap.

Il problema del testo sgranato nasce quando si utilizzano font di piccola dimensione, il testo appare sgranato nonostante l’uso degli algoritmi di anti aliasing. Questo accade perché il testo viene riprodotto con i pixel a disposizione, e i pixel disponibili sono pochi (impossibile riprodurre accuratamente le curve e i glifi di un carattere con 9 pixel o meno…).

Non c’è molto da fare, anche se possono essere utilizzate alcune tecniche per rendere il testo di migliore aspetto. Molte sono ampiamente descritte sul Web ed alcune sono davvero molto articolate (ma davvero vale la pena di soffrire così tanto con Photoshop per fare layout per il Web che probabilmente nel passaggio a HTML/CSS verranno snaturati?), ne voglio però ricordare due che non appaiono frequentemente e permettono di ottenere dei risultati anche insperati.

In presenza di testo di piccole dimensioni, è consigliabile disabilitare l’opzione Larghezze frazionali nel menu del pannello Testo di Photoshop. L’effetto è senza dubbio visibile.

Disattivazione dell'opzione Larghezze frazionali in Photoshop

Il testo rimane comunque renderizzato a pixel, e i pixel sono pochi… si tratta soltanto di un piccolo escamotage che può essere utile per visualizzare in modo più preciso il testo a video, ma basta un leggero ingrandimento per sgranare nuovamente l’immagine. Che fare allora quando sia necessario poter disporre di un bozzetto liberamente ingrandibile e visualizzabile a monitor o stampabile con elevata qualità del testo? Qualche volta si renderizza il livello Testo o si converte in vettori il testo inserito, perdendo così qualsiasi possibilità di successiva modifica del testo stesso. Non è una prestazione entusiasmante, soprattutto a livello di bozzetto, dove le modifiche e le correzioni sono frequenti.

Una buona opzione è stampare il lavoro in un PDF: il testo nel PDF può essere reso vettoriale, anche se nel file di Photoshop vediamo tutti quei pixel. Essendo il testo vettoriale, qualsiasi ingrandimento ci fa un baffo.

Lo stesso testo ingrandito al 200% in Photoshop e in Acrobat. La differenza di rendering è notevole.

Al momento di stampare il PDF, semplicemente verificate che nelle opzioni di Output della finestra di dialogo Stampa sia attiva la casella di controllo Includi dati vettoriali.
Simpatico, vero?

La casella di controllo Includi dati vettoriali.

 

Moduli PDF: validare i campi obbligatori, che passione

In moduli complessi è necessario prevedere un meccanismo di validazione degli inserimenti dati effettuati dall’utente nei campi obbligatori.

LiveCycle Designer e Acrobat per i moduli prevedono una gestione di questa problematica via JavaScript o FormCalc, con una abbastanza complessa procedura di validazione di pattern non sempre chiara.

Però, se non è necessario effettuare una vera e propria convalida del pattern di validazione a partire da LiveCycle Designer 8.02 in sù è disponibile un semplice check di compilazione che richiede soltanto l’inserimento di una riga nel codice XML del modulo.

  1. Create il campo di testo obbligatorio nel modulo con i normali strumenti di LiveCycle, definendone se necessario la lunghezza in caratteri e nella scheda Valore selezionate la voce Inserito dall’utente – Richiesto nell’elenco a discesa Tipo per rendere la compilazione del campo obbligatoria.
  2. Passate alla vista XML del modulo selezionando Visualizza > Sorgente XML.
  3. Individuate nel codice le righe
    <present>
    <!-- [0..n] -->
  4. All’interno dell’elemento <present> potete aggiungere le seguenti condizioni di <validate>:
    prePrint
    preSave
    preSubmit
    preExecute

    Anche combinate.
  5. Per esempio, per fare in modo che venga effettuata una verifica sui campi obbligatori al momento del salvataggio, aggiungete
    <validate>preSave</validate>

Il codice risultante sarà:

<config xmlns="http://www.xfa.org/schema/xci/1.0/">
<agent name="designer">
...
</agent>
<present>
<!-- [0..n] -->
<validate>preSave</validate>

Le condizioni possono essere combinate, se desiderate che il check venga eseguito prima della stampa aggiungete al modulo un pulsante Print, e così via.

Il codice

<validate>prePrint preSubmit</validate>

Produrrà una azione di verifica al momento della stampa o dell’invio per e-mail del modulo.

Nell’esempio, al momento del salvataggio del modulo compilato verrà eseguito un controllo e se il campo obbligatorio non è stato compilato comparirà un messaggio di errore e nel modulo i campi non corretti saranno evidenziati in rosso.
Con LiveCycle Designer ES2 (distribuito con Acrobat X), è possibile personalizzare la modalità di presentazione degli errori, selezionando in una lista l’opzione preferita:

  • Show Every Message In Its Own Message Box One After The Other.
  • Combine The Messages Of All The Failed Fields Into One Message Box.
  • Show the First Failed Field’s Message And Suppress Any Other Messages

PDF accessibili: il problema della verifica di accessibilità

pdf accessibili: il pdf accessibility checker

Con “PDF accessibile” si è bollato un po’ di tutto. Come tentato di spiegare molte volte in diversi post, uno dei problemi dell’accessibilità dei file PDF consiste (consisteva?) nell’impossibilità di eseguire una verifica di accessibilità almeno tecnica ed oggettiva sul file stesso, poiché non c’era modo di eseguirla se non disponendo di Acrobat Pro, programma abbastanza costoso di per sé.
Qualcosa è cambiato, e sono contento di presentare il PDF Accessibility Checker di Access for All, una fondazione svizzera.

Un tool gratuito ma non per questo approssimativo, più analitico del validator di Acrobat Pro stesso nella produzione del report: come ben spiegato nel manuale d’uso, l’analisi svolta approfondisce aspetti determinanti come il corretto ordine di lettura, la presenza di testi alternativi, la congruenza della struttura dei titoli, l’ordine di lettura navigando con la tastiera, la disponibilità dell’attributo title, la definizione della lingua del documento per un totale di 14 criteri di verifica:

  1. Document is marked as tagged
  2. Document Title available
  3. Document Language defined
  4. Accessible Security Settings
  5. Tab follows Tag-Structure
  6. Consistent Heading Structure
  7. Bookmarks available
  8. Accessible Font Encodings
  9. Content completely tagged
  10. Logical Reading Order
  11. Alternative Text available
  12. Correct Syntax of Tags / Rolls
  13. Sufficient contrast for Text
  14. Spaces existent

Insomma, che dire. BRAVI! Un grosso passo avanti. Ora aspettiamo l’editor di PDF ed è fatta.