Da Acrobat XI a HTML: ripristinare l'esportazione a HTML 3.2 e HTML 4

In Acrobat XI,  il comando Salva come altro > Pagina Web HTML ha ricevuto significativi miglioramenti, per esempio riguardo le liste e le tabelle. Attraverso questo meccanismo Adobe ha cercato di offrire agli utenti un output HTML che rispettasse il più possibile il look and feel del documento PDF, usando sia i fogli di stile CSS sia stili inline.

Salva pagina Web HTML in Acrobat XI.

Però, soprattutto quando è necessario poter disporre di un file HTML in cui sia presente soltanto la struttura e il meno possibile degli elementi di stile, l’esportazione in HTML 3.2 o HTML 4 delle versioni precedenti era più efficace.

Per ripristinare queste opzioni, è sufficiente recuperare i due file xml che si occupavano della mappatura degli elementi da una versione 9.0 del programma o scaricandoli dal Web.

HTML 3.2.xml e HTML 4.01.xml vanno poi posizionati nella cartella Acrobatplug_insSaveAsXMLMappingTables della vostra installazione di Acrobat.

Il file HTML risultante sarà certamente più pulito e adatto alla successiva rielaborazione per l’utilizzo in un epub.

Norme e standard: accessibilità del Web e dei documenti digitali online per i disabili

Articolo per Il Documento Digitale, versione cartacea – marzo 2013

Per sua natura, il Web comprende fra sue caratteristiche fondative anche l’accessibilità: come enunciato fin dal lontano 2005 da Tim Berners-Lee, il creatore del Web come lo conosciamo, “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect”.

Per realizzare questo obiettivo, il consorzio W3C ha creato una apposita iniziativa, chiamata Web Accessibility Initiative (WAI). Il materiale redatto da questo gruppo di lavoro esteso, che comprende rappresentanti delle maggiori software house, rappresentanti di governi e organizzazioni di disabili a livello mondiale, è di grande estensione e qualità. Dopo anni di lavoro, sono state rese pubbliche linee guida, tecniche e griglie di
valutazione che gli sviluppatori dei siti Web possono utilizzare per verificare l’accessibilità dei siti realizzati.

Attualmente queste Linee Guida sono diventate standard ISO, (ISO/IEC 40500:2012) e fanno da riferimento alla normativa sull’accessibilità di numerose nazioni nel mondo, fra cui anche l’Italia con la Legge 04/2004 già citata con i relativi decreti attuativi, che fissano i requisiti a cui debbono sottostare i siti web della Pubblica Amministrazione.

Per accessibilità nell’ambito della legge 04/2004 (detta anche Legge Stanca) si intende la “capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari”.

Sono previsti dalla normativa due livelli di verifica, una verifica oggettiva, da implementare mediante l’utilizzo di strumenti di validazione automatica e un intervento dell’esperto tecnico sulle soluzioni adottate, e una verifica soggettiva, da condurre tramite l’analisi da parte di uno o più esperti di fattori umani mediante l’osservazione diretta dello svolgimento di attività predefinite da parte di un gruppo di utenti rappresentanti delle varie disabilità: sordità, ipovisione, daltonismo, cecità, disabilità motoria agli arti superiori, distrofia spastica, disabilità cognitiva, nonché soggetti appartenenti a diverse categorie di utenti interessate ad accedere al sito. Il rispetto dei Requisiti indicati (22 in totale) dall’Allegato A del Ministeriale 8 luglio 2005 permette di definire il proprio sito come “sito accessibile”.

In effetti, un sito realizzato in quel modo potrà essere fruito dalla più grande platea di utenti possibile, anche da parte di chi per consultare il documento utilizza particolari tecnologie assistive come possono essere i lettori di schermo (software in grado di leggere a voce alta quello che compare sul monitor dell’utente), tastiere e schermi Braille, gli ingranditori utilizzati dagli ipovedenti e innumerevoli altre tecnologie di ausilio. Nonostante questo, i siti web della Pubblica Amministrazione realmente a norma sono pochissimi. Per quale motivo, non è facile da definire. Senza
dubbio pesa una certa “ignoranza” degli sviluppatori.

Anche la vigilanza su questi aspetti dei dirigenti è importante (la Legge Stanca comporta responsabilità dirigenziale e responsabilità disciplinare ai sensi degli articoli 21 e 55 del decreto legislativo 30 marzo 2001, n. 165, ferme restando le eventuali responsabilità penali e civili previste dalle norme vigenti). In effetti, l’accessibilità impone un obbligo: i documenti realizzati alla fine delle verifiche dovranno essere di ottima qualità, utili e maggiormente fruibili per tutti.

Come anticipato, probabilmente un grosso impedimento alla realizzazione di questo intento proviene dalla scarsa conoscenza dell’argomento da parte degli sviluppatori e degli amministratori.

L’attività di verifica di grossi siti della Pubblica Amministrazione svolta da CNIPA insegna questo, e i colloqui svolti con gli sviluppatori allo scopo di risolvere le problematiche presenti sui siti analizzati hanno sempre portato, una volta compreso l’argomento, a positive evoluzioni sia in termini di accessibilità sia in termini di qualità generale del sito.

Il sito “accessibile.gov.it”, un portale nato per raccogliere segnalazioni di difficoltà d’uso da parte dei cittadini ed avviare un dialogo e fornire assistenza alle amministrazioni coinvolte, ha raccolto durante la sua attività più di mille segnalazioni di utenti disabili. Sul sito è presente inoltre una biblioteca di tutorial e materiale vario sull’argomento accessibilità. Ebbene, anche in questo caso le amministrazioni quando rese consapevoli del problema hanno provveduto in grande maggioranza alla soluzione dello stesso.

Inoltre, nessuna associazione di disabili ha mai avviato una causa contro un’amministrazione mancante da questo punto di vista, e men che meno un privato. La mancanza di sentenze e l’elevato costo delle cause probabilmente ha bloccato anche questo possibile deterrente, mentre all’estero accade di frequente (famoso il caso di un cieco contro il sito delle Olimpiadi di Sydney) ovviamente mantenendo alta l’attenzione sul problema.

Allo stato attuale, anche ai documenti elettronici possono essere riservate le stesse cure dei siti web, e i più diffusi software dispongono di validatori dell’accessibilità integrati. Per esempio, Microsoft Office dispone di un validatore molto efficace per Word, Excel e Powerpoint. Lo stesso si può dire riguardo Adobe Acrobat, lo strumento utilizzato per creare i molto diffusi file PDF.

In conclusione, sono disponibili tutti gli strumenti tecnologici necessari per realizzare compiutamente questo importante traguardo, esiste una solida normativa di riferimento sia nazionale sia internazionale, sono disponibili numerosi esempi applicativi e linee guida. L’accessibilità del Web e dei documenti elettronici in generale è una sfida entusiasmante, poiché permette che almeno in questo ambito le possibilità di conoscere, studiare, fruire delle risorse disponibili siano le stesse per tutti i cittadini digitali.

Audiolibri, epub3 e… accessibilità

Un audiolibro è un libro parlato, la riproduzione vocale di un’opera. In genere, si tratta di un libro classico o un romanzo di grande successo che viene letto da un attore e registrato in file .mp3 o altri formati audio, ma esistono anche audiolibri realizzati appositamente per questo scopo, che includono oltre ai file audio del parlato anche file musicali, scenografie sonore e quanto necessario per rappresentare, per esempio, un’opera teatrale.

Nel nostro caso, un audio e-book sarà composto da diversi file audio organizzati in una struttura e dotato di un sistema di navigazione che ne consenta la fruizione. Esistono degli standard tecnici che si occupano di fornire riferimenti su come realizzare questi audiolibri, il più conosciuto (almeno come acronimo) dei quali è probabilmente DAISY,  Digital Accessible Information System.

Qui iniziano i miei personali dubbi riguardo l’accessibilità: sul sito del Daisy Consortium spicca la scritta “Making Information Accessible for All“. Ma un audiolibro può essere davvero considerato accessibile per tutti? Molto brutalmente, che se ne fa un sordo di un audiolibro? Accessible for all? No. Inoltre, le periferiche hardware Daisy sono veramente costose, tanto da spingere il nostrano CILP (Centro Internazionale del Libro Parlato “A. Sernagiotto” – ONLUS) a sviluppare hardware dedicato a un prezzo decisamente più abbordabile. Sarà per questo, anche, che il consorzio DAISY non è che sia così simpatico?

Comunque, i tipi di Daisy hanno lavorato con gli sviluppatori di Epub 3 per creare la sezione dedicata al rendering audio TTS delle specifiche (attualmente non supportato da alcun reader)  e al meccanismo chiamato Media Overlays che permette di evidenziare in sincrono le parti del testo in lettura e il brano audio corrispondente enfatizzando questo risultato come se fosse la soluzione di tutti i mali.

Niente di nuovo, la stessa cosa si può ottenere da anni con altri strumenti, per esempio provate a leggere un brano con Balabolka, un programma TTS (text-to-speech) gratuito e davvero ben fatto.

Se aprite un epub con Balabolka ed avviate la lettura (in questo caso l’audio proviene dalla sintesi vocale installata, e non da un attore registrato mentre recita il testo), vedrete le parti del testo in lettura evidenziate mano a mano che la lettura procede.

Balabolka in azione: il testo in lettura appare evidenziato.

Per ottenere lo stesso risultato (l’evidenziazione) ma correlando il testo a una voce recitante (quindi una base registrata, su cui non potete intervenire per quanto riguarda tono, velocità, tipo di voce), i media overlays di epub 3 prevedono l’utilizzo di SMIL (un markup del W3C) e di altre specifiche.

Qui mi sorge un altro grosso dubbio: SMIL (Synchronized Multimedia Integration Language) è un markup collaudato la cui versione più recente (3.0)  risale al 2008. Non riesco a capire che c’entra DAISY, se devo usare SMIL. Boh? Mi risponde indirettamente Matt Garrish nel suo Accessible EPUB 3, scaricabile gratuitamente da O’Reilly (il PDF non è accessibile, ma pazienza).

If you’re coming to this guide from accessibility circles, however, you’re probably wondering why this is considered new and exciting when it sounds an awful lot like the SMIL technology that has been at the core of the DAISY talking book specifications for more than a decade. And you’re right…sort of. Overlays are not new technology, but represent a new evolution of the DAISY standard, which EPUB 3 is a successor to. What is really exciting from an accessibility perspective is the chance to move this production back to the source to get high-quality audio and text synchronized ebooks directly from publishers.

Ma era così anche prima, nessuno ha mai impedito a un publisher di usare SMIL. Boh? Che c’è di eccitante? Mai sottotitolato un video? È la stessa cosa e l’hanno fatto in tanti ben prima che nascesse Epub 3.
Il libro utilizzato nell’esempio di Balabolka è un epub in versione 3, e per vederlo in azione al completo delle sue possibilità una delle pochissime opzioni disponibili (epub 3 non è che abbia avuto questo gran successo) è aprirlo in Google Chrome con Readium. Vediamo che succede.

In Readium il brano in lettura appare evidenziato in giallo.

Ascoltando la lettura, si noterà che al brano recitato in audio corrisponde una evidenziazione in giallo del testo in Readium. Come si ottiene questo? Tramite SMIL e markup.

Osservando la struttura del file epub in Sigil le cose (forse) appaiono più chiare.

Il contenuto del file epub in Sigil.

In Sigil, è facile vedere il contenuto delle due cartelle Audio e Misc: tutti i file mp3 che costituiscono la libreria audio e i corrispondenti file SMIL che stabiliscono le correlazioni. Nel codice, ciascun brano viene delineato da un tag span.

Si capisce che è un lavoro non da poco: con uno strumento di authoring bisogna selezionare ciascuna parte del testo che si intende evidenziare, associarvi le parti del brano audio con dei puntatori e aggiornare il file html con tutti gli span corrispondenti, ciascuno con una id diversa.
I file SMIL contengono informazioni di questo tipo:

<p class="chapterTitle"> <par id="p000001"><text src="p002.xhtml#f000001"/><audio clipBegin="0:00:00.000" clipEnd="0:00:02.879" src="../Audio/02_CantodiNatale_Strofa_1_A.mp3"/></par>

E nel corrispondente file html troveremo:

<h1><span id="'p000001">Strofa Prima</span></h1>

Quindi, due approcci completamente diversi: nel primo caso la lettura viene effettuata dalla sintesi vocale, nel secondo si tratta di un laborioso lavoro di sincronizzazione fra markup e file audio.

Ma, i dubbi che ho sono: nel caso Balabolka, il software di lettura è sicuramente accessibile a tutti, nel caso di Chrome/Readium no.

È un audio e-book in Epub 3 definibile come accessibile? A oggi no, o meglio lo è soltanto teoricamente: le specifiche del markup relative all’accessibilità non sono supportate da alcun reader Readium compreso (stiamo lavorando, dicono nelle FAQ. Ok, aspettiamo), e di conseguenza come verificare?  Forse è per questo che la sezione “Best Practice” delle EPUB 3 Accessibility Guidelines per ora appare “Coming Soon”. Dovrebbero esserci novità per febbraio 2013, ok, aspettiamo.

C’è qualcosa di innovativo nell’approccio di epub3? No, in generale per l’accessibilità Epub 3 si appoggia a tecnologie del W3C e le stesse cose si possono fare da anni, utilizzando tecniche standard con risultati anche più trasparenti e senza obbligare “il lettore” ad usare specifici browser ed estensioni non accessibili.

A chi giova ciò? Francamente, a parte discorsi di marketing, non lo capisco. Tempo fa ho chiesto informazioni sul forum di IDPF nella sezione relativa all’accessibilità, domandando esplicitamente che cosa intendessero con “epub accessibility“. Si sono un po’ arrabbiati, pensando che fosse una disfida fra PDF e EPUB – disfida di cui non mi interessava nulla, però onestamente ammettendo che:

You’re kind of presenting an impossible problem, though. Either EPUB stays in the past with XHTML 1.1 and doesn’t get the benefits that will come with native audio/video, mathml, aria support, etc. or, it moves forward and has to live with some instability.

The decision was made to move forward with the web, so that does leave us in a position where we have to talk about an ideal future. I certainly appreciate this fact, as there’s a line I find myself always treading between what you can say is possible versus what is possible right now.

Ok, aspettiamo… Per ora si vede molta confusione, spero che possa servire a rendere più chiare e trasparenti le cose il convegno “eBooks: Great Expectations for Web Standards” organizzato dal W3C in partnership con IDPF e BISG. Magari ce la facciamo a farcela.