PDF accessibili sul serio (seconda parte)

La prima parte di questo tutorial concludeva ponendo l’accento sul fatto che la conversione fra documenti Word creati utilizzando gli stili di paragrafo del template predefinito (normal.dot) è pressoché automatica e piuttosto trasparente. Ma che succede se in Word uso degli stili personalizzati?

Proviamo. Creiamo un semplice documento di Word e inventiamo degli stili. Nell’esempio, Titolo_princi, Sotto_titolo1, dida e Sotto_titolo2. Assegniamo gli stili a qualche paragrafo.
il documento Word di esempio
Vediamo che succede nel PDF:

Nel PDF, i tag sono spariti
Accidenti. gli stili sono spariti, e a tutti gli elementi è stato assegnato il tag <P>. Che è successo? Nulla, è la dimostrazione di come funziona la mappatura di stili standard di Word ed elementi della grammatica PDF.

Se gli stili non hanno nomi predefiniti, il PDF Maker non è in grado di ricostruirne la gerarchia e assegna un tag generico di testo. Dobbiamo subire questa imposizione? No, Basta aprire la scheda delle preferenze di Acrobat PDF Maker, fare clic sulla scheda Word e selezionare la casella di controllo Abilita tag avanzati. Nel PDF prodotto saranno presenti i nostri stili personalizzati. La verifica di accessibilità non rileverà alcun problema (da Word 2007 viene rispettata anche la lingua del documento), nel peggiore dei casi se ve ne siete dimenticati mancherà il testo alternativo dell’immagine.

Ma è realmente accessibile questo documento, completo di tag personalizzati? Proviamo con Jaws. Ins+F6 per “intercettare” i titoli e… “No headings found”, dice quel cialtrone.

word_3
A pensarci ha pure ragione… come fa Jaws a capire la struttura dei titoli se questi non hanno un riferimento a un contesto conosciuto?
È questo uno dei vantaggi principali dell’uso degli standard: se esiste una codifica conosciuta e accettata, tutti ci si possono riferire e costruire automatismi che evitino di dover intervenire a posteriori sui file per “spiegare” al software che Titolo_princi altro non è che un H1, e così via. In questo caso stiamo utilizzando una “DTD” (mi si perdoni questo azzardo, facciamo finta che un template di Word sia l’equivalente di una DTD) non standard, è del tutto lecito che il software non sia in grado di mappare gli stili agli elementi della grammatica standard PDF [1. per chi viene da HTML: attenzione, i nomi degli elementi in molti casi sono simili, ma questo è un PDF, non una pagina Web. Non dimenticatelo.].

Ora che fare? Se il documento è semplice, apro il pannello Tag e ri-mappo gli stili personalizzati ai tag standard, oppure cancello la stuttura del documento e la ricreo con il pannello Ordine, per esempio.

Ma se il file è lungo e complesso? Per fortuna esiste la possibilità di stabilire i ruoli degli stili personalizzati, ovvero di costruirne una mappatura. Osservando la struttura dei tag del PDF creato con la casella di controllo Abilita tag avanzati attiva, è facile notare come gli stili presenti nel documento Word ora siano presenti anche nel PDF.

Ora dobbiamo dire ad Acrobat che Titolo_princi è da gestire come se fosse un H1, e così via per gli altri elementi.

  1. Nel pannello Tag di Acrobat, clic destro sul tag Titolo_princi. Selezionate Modifica mappa ruolo nel menu contestuale che apparirà.
  2. Fate clic sul segno + alla sinistra di Ruoli documento per espandere l’elenco. Apparirà una lista che mostra sulla sinistra i nomi dei tag personalizzati provenienti da Word, sulla destra l’elemento standard PDF associato.

la finestra Mappa ruolo di Acrobat

Ora si tratta soltanto di mappare i tag personalizzati con quelli predefiniti. Quindi grammatica dei tag standard a portata di mano, e clic sul pulsante Modifica elemento.

  1. Nella finestra Modifica valore che apparirà, digitate H1 (il tag standard per i titoli di primo livello). Fate la stessa cosa per Sotto_titolo1 e Sottotitolo2 (H2 e H3 rispettivamente), e per dida (che tag userete? si accettano scommesse).
  2. Selezionate File > Salva e riprovate con Jaws. Premiamo Ins+F6 ed apparirà la finestra Heading List di Jaws.

La finestra Heading List di Jaws mostra i titoli mappati nel documento PDF

Funziona.

PDF, Flash e WCAG 2.0

È possibile creare contenuti accessibili conformi alle WCAG 2.0 con Acrobat e Flash?

Lunedì 23 marzo, martedì 31 marzo e mercoledì 8 aprile 2009 si terranno dei seminari Web per dimostrare come rispettivamente su:

  • PDF e WCAG 2.0 (23/3)
  • Flash e WCAG 2.0 (31/3)
  • PDF Forms e WCAG 2.0 (8/4)

Non è richiesta la pre-registrazione e i meeting si terranno nella room http://my.adobe.acrobat.com/wcag2.

L’orario per tutti e tre gli incontri è ore 12:00, Eastern US Daylight Savings Time, che da noi dovrebbe corrispondere alle 17 (non assicuro niente, gradite verifiche sui fusi orari).
I seminari si svolgono in concomitanza con il 3rd European eAccessibility Forum, che si svolge a Parigi nella settimana del 30 marzo.
Ulteriori dettagli sul blog del Paciello Group.

PDF accessibili sul serio (prima parte)

Abbiamo già parlato di come un PDF con tag non possa essere considerato accessibile tout court, anche se supera il test automatico di accessibilità di Acrobat. Lo dice anche la guida Adobe sull’accessibilità dei PDF: “However, these tools don’t check documents against all accessibility criteria, including those in such referenced guidelines, and Adobe does not warrant that documents comply with any specific guidelines or regulations”. In effetti, un tool automatico può soltanto verificare che determinate condizioni siano rispettate, come la presenza dei tag, che i link siano accessibili, che sia stata specificata una lingua per il documento, che l’ordine dei tab sia congruente, e così via (per maggiori informazioni, consultate i documenti contenuti nella pagina “Accessibility training resources” di Adobe). Il rispetto di queste condizioni però non implica che il documento sia veramente accessibile, il perché sarà più chiaro proseguendo con la lettura del post. È abbastanza ovvio. Che ne sa un software della congruenza o meno della struttura che avete delineato per il vostro documento? Discorso già fatto, quasi scontato per molti. Se i titoli non sono marcati esplicitamente come titoli, ma sono soltanto testo più grande e in grassetto per i vostri occhi (per la vostra mente) sarà chiaro che quelli sono, o dovrebbero essere dei titoli. Ma per un software le formattazioni grafiche non hanno alcun significato, per poterle utilizzare è necessario indicare esplicitamente il loro ruolo semantico. Se questo ruolo viene espresso, la tecnologia assistiva sarà in grado di estrarre dal documento le informazioni che avete deciso di rappresentare graficamente in modi diversi per rendere chiara la struttura del documento e potrà presentare all’utente le stesse logiche presentazionali anche se in modo diverso. Facciamo un esempio pratico, per capire per quale motivo sia necessario utilizzare gli stili di paragrafo affinché uno screen reader (in questo esempio Jaws) sia in grado di trasmettere all’utente le vostre intenzioni semantiche, quelle che avete espresso graficamente assegnando al testo che rappresenta un titolo il carattere Arial, 24 punti in grassetto. Avete fatto così perché desiderate indicare esplicitamente al lettore che quello è il titolo: sono centinaia di anni che i titoli si fanno così, e chiunque a colpo d’occhio capirà il vostro intento se ha la possibilità di usare la vista. Quindi, apriamo Word e creiamo del testo. Assegnamo alla frase che rappresenta il titolo il carattere e il corpo indicati in precedenza. Il risultato sarà più o meno come quello mostrato nella figura seguente. un documento word formattato graficamente per indicare un titolo Faccio il mio bel PDF con tag, e diamine, vuoi che non superi il controllo? Certo che lo supera, ma siamo sicuri che il documento possa essere definito “accessibile”? Proviamo a leggere questo documento con Jaws, e vediamo che succede. Apro Jaws, premo ins+F6 [1. per una lista dei tasti funzione di Jaws, leggete la relativa guida.] per rilevare i titoli nel documento (esattamente come fareste a colpo d’occhio per capire com’è strutturata la pagina) e Jaws afferma che nella pagina non c’è alcun titolo. O diamine. La stessa cosa accade nel PDF, ovviamente. Ma come, è lì bello grosso il titolo! Certo, a occhio si vede, ma osservando la barra degli stili è evidente che il titolo ha stile Normale. Se è testo normale, come farà mai Jaws a capire che è un titolo, se non lo dichiarate esplicitamente? È solo un software, non legge nella vostra mente. Allora, proviamo ad assegnare un vero stile di paragrafo al titolo, selezionando Titolo 1 negli stili predefiniti di Word. Non ci interessa la grafica in questo momento, ma soltanto di assegnare lo stile corretto al paragrafo. Ripetiamo la procedura con Jaws, e wow! Stavolta succede qualcosa. Jaws apre una nuova finestra, che elenca i titoli presenti nel documento e permette di usarli come link. Ecco, ora mi sembra che si possa parlare in modo più sensato di accessibilità. Nella finestra Headings List di Jaws (sto usando la versione demo della 10 in inglese) compaiono tutti i titoli (in questo caso soltanto uno, poiché il documento ne prevede soltanto uno, ovvio) e li rende navigabili. Selezionando un titolo e facendo clic su Move To Heading il cursore di Jaws si sposterà in quel preciso punto, e leggerà il brano. La finestra Heading List di Jaws mostra i titoli nel documento Mica male, no? E nel PDF? Che succede nel PDF? Proviamo. Creo il PDF, apro il pannello Tag. Ok, i tag ci sono, compreso il Titolo 1 che è diventato H1, corretto. Premo ins+F6 e… non succede niente! Jaws mi dice che non ci sono titoli nel documento. Ma come? Ho fatto tutto giusto, il PDF è taggato e passa il controllo… che tristezza. E adesso? Uhm, sarà mica l’ordine di lettura? Apro il menu Avanzate > Accessibilità > Modifica opzioni di lettura. È attiva l’opzione Ricava ordine di lettura dal documento. Ma è quello che voglio? No, io ho determinato l’ordine di lettura coi miei tag. Apro l’elenco a discesa e seleziono Ordine lettura con tag, che diamine. Sìììì funziona! Magia! Ho fatto il mio primo PDF davvero accessibile! La finestra Heading List di Jaws mostra i titoli anche nel documento PDF Nota: la mappatura degli stili fra Word e PDF è automatica per quello che riguarda gli stili predefiniti di Word, quelli nel normal.dot per capirci. Quindi, il Titolo 1 di Word diventa automaticamente H1 nel PDF, come previsto dalla sua grammatica per i tag standard. Ma che succede se invece di Titolo1 uso lo stile Titolone,oppure uso un foglio stile diverso da quello di default, o un programma diverso da Word?

Lo sapremo nella prossima puntata con le mappe ruolo.

Diventare editori elettronici accessibili

Bè, fra i settori dove l’Italia fa la sua bella figura c’è l’accessibilità. I lavori svolti dai vari gruppi costituiti allo scopo di produrre normativa riguardo i siti Web hanno raccolto grossi consensi anche a livello extra-nazionale, e il lavoro di AIE nell’ambito del progetto ProAccess (finanziato dalla Commissione Europa nell’ambito del programma eLearning) ha avuto dei bei riconoscimenti da parte della commissione europea. Sono ancora in fase di discussione le linee guida e i modelli di licenza che regolamentino i rapporti contrattuali tra i vari attori della filiera (autori, editori, fornitori di servizi, organizzazioni che si occupano delle conversioni, utenti finali), ma è comprensibile un certo ulteriore dibattito su questi argomenti (che, lo ricordo, riguardano l’intera Comunità Europea, non soltanto l’Italia).

A un certo punto del processo di sviluppo di ProAccess, sono stato coinvolto da AIE nello stesso per la verifica delle Linee Guida, per lo svolgimento di un corso dedicato agli editori che intendono realizzare libri digitali accessibili, per la preparazione di un courseware e relativi materiali dedicato allo svolgimento di giornate di formazione in aula.

Nel frattempo sono successe molte cose, non ultime la pubblicazione del DM 30 aprile 2008, l’art. 15 del Decreto Legge 133/2008, e altri avvenimenti di questo calibro. Mica da ridere, eh.

Nel Marketplace di Innovascuola cominciano ad apparire alcuni libri digitali, e se ne sente parlare sempre di più, ma guardando con occhio tecnico alcuni materiali presenti risulta evidente che il tentativo c’è ma il “come fare” è ancora piuttosto sconosciuto (è abbastanza ovvio, a chi mai sarebbe venuto in mente che un giorno ci saremmo trovati a parlare di questi argomenti? Inoltre, per i web designer: uno dei problemi più evidenti è la assoluta incomprensione di quella che in ambito Web viene chiamata “semantica degli elementi”. Cioè, tanti bei p e niente altro. Consiglio: cominciate a imparare a usare Indesign, per esempio. Vi si potrebbero aprire ulteriori possibilità lavorative. È uno dei problemi più grossi per gli editori: non ci sono competenze, i testi vengono impaginati a “tag soup”, tanto per capirci).

Per questo motivo ho deciso di rendere disponibili per il download le tracce, o le bozze se preferite, del courseware che ho realizzato per ProAccess. Il materiale è organizzato in quattro parti, e pensato per essere svolto in aula. Non si tratta quindi di un libro, ma di una guida per un ipotetico tutor che svolge un corso. Ritengo però che chiunque abbia un minimo di dimestichezza con word processor, programmi di desktop publishing e HTML potrà fruirne autonomamente.

Nello zip sono presenti 4 cartelle, ognuna dedicata a un argomento (sono presenti file di Word, immagini, materiali per gli esercizi). Ricordo nuovamente che si tratta di una bozza, poco impaginata.

La parte 1, Comprendere l’accessibilità, parla di:

  • Comprendere l’accessibilità
  • Definizioni
  • Cosa si intende con la parola “Disabile”?
  • Linee guida e legislazione
  • Tecnologie assistive
  • Gli ausili tecnologici
  • Analisi delle necessità e loro comprensione
  • Metodi di risoluzione
  • Strumenti di simulazione
  • Test con utenti
  • Il Design for All come metodo di progetto
  • Ma quanto mi costa?
  • Uno sguardo sul futuro

La parte 2, L’accessibilità dei documenti elettronici, parla di:

  • Cos’è un documento elettronico accessibile?
  • Esempi di documenti
  • Problematiche generali
  • Livelli di azione dell’accessibilità
  • Comprendere cosa si intende per struttura: come è fatto un documento per un computer
  • Altre opzioni: il markup
  • Il markup: lezioni dal Web
  • Tipologie e formati
  • Formati standard
  • Perché uno standard?

La parte 3, Documenti elettronici accessibili: come fare, parla di:

  • Capire ed usare gli stili di paragrafo
  • Esercizio 1: stili di paragrafo e struttura in Word
  • Esercizio 2. Struttura in Indesign
  • Esercizio 3. Creare PDF con tag da Indesign
  • Esercizio 4. Creare versioni XHTML da Indesign
  • Approfondimento: un passo importante. Separare i contenuti e la loro struttura dagli elementi di presentazione
  • Come è fatto un documento per un computer
  • Il flusso dei contenuti e la concatenazione del testo
  • Navigazione di un documento: link e ancore
  • Creare un sommario navigabile in Indesign
  • Creare ancore di ritorno al sommario o a particolari aree del testo
  • Ingrandimenti che funzionano
  • Creare libri a carattere ingrandito con doppia numerazione di pagina
  • Strategie di progettazione editoriale accessibile

La parte 4, Verifica e correzione degli errori, parla di:

  • Verifica dell’accessibilità di un file PDF
  • A partire da un PDF da stampa prodotto senza tenere in alcun conto le tecniche descritte nella Parte Terza
  • Formati di distribuzione
  • Produrre una versione XHTML a partire da un file PDF con tag

Ricordo che il materiale che scaricherete sarà pubblicato nell’ambito di un progetto europeo, è soggetto a copyright e non può essere utilizzato a scopo di lucro. Inoltre, i file contenuti nello zip non sono né esaustivi dell’argomento né completi. Rendo pubblica questa parte del lavoro (la prima bozza) perché la vorrei sottoporre a discussione, comprenderne limiti e pregi, avere qualche suggerimento per migliorarlo.

Facendo clic sul link di download del file, accettate implicitamente la licenza Creative Commons seguente:
Editoria Elettronica Accessibile by Livio Mondini is licensed under a Creative Commons Attribuzione-Non commerciale-Condividi allo stesso modo 2.5 Italia License. Based on a work at http://www.biroblu.info
.

Accetto le condizioni della licenza di distribuzione succitata e scarico courseware (file zip, 13.655 kb) impegnandomi a rispettarle.

Web 2.0, quello vero

Che bello slogan…

“Web page = Web Service
XHTML+RDFa markup for people and machines”

expose data four ways

web scale

REST (ROA, WOA)

  • Web page = Web Service
    XHTML+RDFa markup for people and machines
  • resource as public record
    global visibility and persistence of URI’s

Atom as RESTful API

  • introspection service for feed resource discovery
  • HTTP uniform interface
    CRUD analog – PUT/GET/POST/DELETE
    <entry> as recordset </entry> resource state event

atom+xml and xhtml+xml representations

  • Caching, Crawling and Indexing

Web = DB

  • Linked Open Data SPARQL endpoints, XHTML+RDFa

Fa impressione, vero? Sarà qualche matto scalmanato di standard.

No, è il piano dello staff tecnico di Obama per Recovery.gov, “a Web site that’s supposed to provide information on how stimulus money is being spent”. Mica ciccia… sempre detto che con gli standard ci si guadagna.

Loro promuovono a botte di fantastiliardi energie alternative e Web semantico, noi i call center, le centrali nucleari e il ponte sullo stretto.

Il sito viene dichiarato al suo stato iniziale per quanto riguarda l’accessibilità (e lo è), ma i filmati sono sottotitolati, i PDF accessibili, i diagrammi hanno gli alt… mi viene il magone.

Tu chiamale se vuoi… opinioni (sugli strumenti didattici e formativi a favore degli alunni disabili)

giù le mani dall'accessibilitàUn po’ come era successo con l’accessibilità del Web, ultimamente si sentono notizie veramente “originali” sull’editoria scolastica, quello che sarà il “libro di testo digitale accessibile”.

Settimana scorsa ho avuto un incontro con la responsabile di un service grafico piuttosto importante, che mi ha raccontato notizie imbarazzanti. Mi racconta: “Sai, in xxxxxx mi hanno passato un profilo di Distiller denominato art. 15 che servirà a fare libri conformi all’art. 15 della finanziaria, così siamo a posto con i libri di testo elettronici”. Cioè, chiedo io. Intendi il Decreto Legge 133/2008? Ah… e risolvi con un profilo di Distiller? Deve essere prodigioso! Che fa questo profilo? Ah niente, risponde lei, praticamente stampo in bassa risoluzione lo stesso file destinato alla stampa in modo che sia più piccolo da scaricare. Uau, dico io, bel colpo! E tutto il resto? Ma quale resto, chiede lei?

Hai letto il decreto a cui ti riferisci, chiedo io? No. Lo sai che fra le altre cose il decreto dice “Con decreto di natura non regolamentare del Ministro dell’istruzione, dell’università e della ricerca, sono determinati:

b) le caratteristiche tecnologiche dei libri di testo nelle versioni on line e mista;”

e che nel frattempo è uscita una circolare (la 16 del 10 febbraio 2009) che fra le altre cose dice “Per gli studenti con disabilità sono previsti libri di testo e strumenti rispondenti alle specifiche esigenze, sia sotto forma di testi trascritti in Braille per allievi non vedenti o con caratteri ingranditi per allievi ipovedenti, sia in forma digitale con prodotti che rispettino i requisiti previsti dalla normativa vigente ed in particolare il DPCM 30 aprile 2008 (pubblicato sulla Gazzetta Ufficiale del 12 giugno 2008), concernente le “Regole tecniche disciplinanti l’accessibilità agli strumenti didattici e formativi a favore degli alunni disabili”.

Pensi davvero che un profilo di Distiller in bassa risoluzione risponda a questi requisiti obbligatori? Mi guarda per un po’, mi chiede “Ma a che serve il profilo?”. Bò, dico io. Bisogna fare così e così, e via tre ore di dimostrazione pratica… gratis, come al solito ovviamente :-).

Obiezione: scusa ma nessuno sa queste cose, come facciamo noi a saperle se nessuno ce le dice? Risposta: no, queste informazioni sono pubbliche e disponibili a chiunque, sia nel testo del decreto, sia nella circolare, sia nel bando tecnico del Marketplace di Innovascuola.

Marketcosa? Innovache? Ai ai ai. Allora, il Marketplace è il luogo dove i fornitori di Contenuti Didattici Digitali (CDD) “vendono” i propri materiali didattici (vedi il sito per maggiori informazioni, che qui viene troppo lunga).

Per pubblicare i propri contenuti nel Marketplace, bisogna rispettare le richieste del Capitolato Tecnico, sennò ciccia. Fra le altre cose, il capitolato tecnico chiede che:

2.3. Accessibilità
I CDD forniti per la pubblicazione dovranno essere conformi a quanto previsto dalla legislazione corrente in tema di accessibilità ed usabilità di contenuti digitali e, in particolare,
alla Legge Stanca (Legge 9 gennaio 2004, n. 4 – “Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici”) relativa all’accesso dei soggetti diversamente abili e alle indicazioni riportate nel DM 30 aprile 2008 recante le “Regole tecniche disciplinanti l’accessibilità agli strumenti didattici e formativi a favore degli alunni disabili”.

Hai letto il DM 30 aprile 2008? No. Bè, meglio che lo leggi. Sei sempre dell’idea che con il profilo “art. 15” risolvi tutto? Eh, mi sa di no.

Altri invece promuovono convegni, sapete quelli dove in due ore si esaurisce tutto lo scibile umano sull’argomento. Bè, sì, di solito è così perché quelli che partecipano non conoscono l’argomento, e quindi ben presto si esaurisce la verve narrativa.

“Gli e-book a scuola”, dice uno di questi, con associata tentata vendita di lettori di e-book (pentole e materassi, avete presente?). Dimenticando che sia gli e-book venduti, sia i lettori proposti non sono conformi alle richieste di legge per i libri elettronici scolastici (molto semplicemente, non sono accessibili né gli e-book in quella forma né l’hardware proposto). Andranno benissimo ovunque, non discuto, ma non a scuola.

Sulla qualità degli ebook citati, riporto il commento (di oggi, 8 marzo 2009) di un partecipante alla lista di discussione Listavista, personaggio a cui certo non si può rimproverare nulla sia dal punto di vista della competenza sia dell’esperienza diretta (è cieco):

“Così per parlare ai muri. Ieri ho scaricato un PDF dimostrativo da xxxxxxxx (editore che promuove il convegno citato). A parte il fatto che la struttura e la formattazione sono orribili, e scusatemi se ho ho detto orribili se li ritenete accessibili.”

E questi ci fanno il convegno… dai, per favore, cercate di essere seri.
Va bene il business, ma non fatelo sulla pelle degli studenti e dei disabili.
L’abbiamo già vista, e saremo durissimi.

Le riflessioni di un editore.

Grafica e accessibilità: immagini di sfondo nei PDF

Parlando con un’amica grafica molto brava, ci si chiedeva come risolvere un problema: certamente vi sarà capitato di vedere impaginazioni anche molto belle, graficamente ricche e piacevoli. Però, la grafica di sfondo che viene utilizzata può essere un grosso disturbo quando la pagina viene letta a monitor o consultata da persone con problemi di visione (basta pensare all’ipovisione…).

Come fare per salvare capra e cavoli?

Una soluzione può venire dai livelli. Vediamo come con Indesign.

Per capirci meglio, immaginiamo una situazione simile a questa (ok, non è né bella né accattivante, ma rende l’idea).

pagina con grafica di sfondo che ostacola la lettura
La grafica di sfondo ostacola la lettura, mi pare evidente. Non sarebbe male poterla nascondere quando si legge il file a monitor, per esempio.
Si può fare così.

  1. In Indesign, create un nuovo livello nel pannello Livelli e assegnategli un nome significativo e semantico, per esempio Sfondo :-).
  2. Preparate le pagine mastro inserendo la grafica di sfondo nel livello appena preparato.
  3. Tornate alle pagine normali ed inserite il testo, che apparirà sopra all’immagine di sfondo posizionata nelle mastro nel proprio livello.
  4. Selezionate File > Esporta e il formato PDF come destinazione.
  5. Nella finestra di dialogo Esporta Adobe PDF che si aprirà, verificate di impostare l’elenco a discesa Compatibilità a una versione PDF successiva alla 1.5. In questo modo diventerà disponibile la casella di controllo Crea livelli Acrobat della sezione Opzioni. Selezionate questa casella di controllo e anche quelle denominata Crea PDF con tag.
  6. Esportate il file.

Aprite il file in Acrobat: con pochissima sorpresa apparirà né più né meno come l’avevate preparato, ovvero saranno visibili la grafica di sfondo e il testo.

  1. In Acrobat, selezionate Vista > Pannelli di navigazione > Livelli. Nel pannello Livelli che apparirà, fate clic sull’icona a forma di occhio adiacente il livello Sfondo: lo sfondo scomparirà. Se scompare tutto, avete posizionato anche il testo sul livello Sfondo… non si fa così :-). Inoltre, verificate in Indesign che i livelli siano correttamente disposti: Sfondo deve essere sotto al livello che contiene il testo, mi pare ovvio ma meglio specificarlo.

il pannello Livelli in Acrobat
L’uso dei livelli ha inoltre un altro vantaggio: facendo clic con il tasto destro del mouse sul nome del livello si apre, come di solito, la finestra Proprietà. Fra le proprietà del livello è possibile anche definire quelle di stampa, e di conseguenza stampare copie del documento create secondo le proprie personali necessità.

Inoltre, usate questa tecnica anche con le pagine Web. Quante volte una pagina è illeggibile a causa dello sfondo? Un esempio di best practice viene come al solito da Andy Clarke, su For A Beautiful Web. Osservate la pagina nell’area sopra al titolo.

HTML5 e Google

Guardando un po’ in giro alla caccia di divitis, classitis e tagitis (si capisce che in questo periodo sono ammorbato dai virus?), ho dato un occhio anche a Google e con una certa sorpresa ho scoperto che le pagine dei risultati di ricerca sono in HTML5. Facile che sia così da un po’, non ci ho mai fatto caso.

Mi chiedo a cosa serva: HTML5 non doveva essere il grande formattatore del Web, il markup che ripulirà tutti gli errori? Il W3C Validator da un po’ offre anche un servizio di validazione sperimentale per HTML5, in questo momento il responso è:

Errors found while checking this document as HTML5!

Result: 158 Errors, 1 warning(s)

Boh.  A che serve? La cosa più buffa è che forzando la validazione per altre DTD il numero di errori cala. In HTML 4 Transitional, per esempio, sono solo 115 (sigh).

Invece, ho notato con piacere che è molto migliorata la struttura degli elementi <h>, ora correttamente presenti e annidati. È presente anche un <h2> off-screen, segno che hanno lavorato sull’accessibilità.

Però, perché quel <!doctype html>? A che serve?

Inoltre, da alcune discussioni in giro per il Web mi sembra che ci sia ancora una certa confusione sulle questioni HTML5 vs HTML4 e XHTML 1. In effetti questa confusione è stata forse alimentata ad arte, per dare a HTML5 un’aurea rivoluzionaria che in realtà non possiede. È fin dal 2003 che la specifica è in via di sviluppo, e la confusione regna (come un po’ su tutta la specifica) fin da allora, tanto da costringere Anne van Kesteren a scrivere un articolo apposito sul suo blog:

XHTML5

In the past I wrote quite a lot about HTML5. Apparently not much people understood it also extends XHTML 1.0 so you can its semantics in XML or the more backwards compatible HTML variant. Browser makers do care about XML. So if you would have a document containing some header and a paragraph there would basically be two serializations. One for XML … and one for HTML

A me sembra abbastanza chiaro il senso, però, se qualcuno avesse ancora dubbi sul futuro di XHTML, parliamone.

W3C

HTML 5

A vocabulary and associated APIs for HTML and XHTML

W3C Working Draft 12 February 2009

divitis, il record: 1.612 div in una pagina!

Ebbene sì, credo sia un record: 1.612 div in una pagina! La palma va a… rullo di tamburi… la mia bacheca di Facebook!
Se volete verificare da soli, basta installare la Web Developer toolbar per Firefox e selezionare Information > Display Div Order. Ogni etichetta gialla è un div. Considerato che la mia bacheca è abbastanza sgombra, sono sicuro che si può fare di meglio.

facebook 1612 div in una pagina