Libri digitali accessibili: ma cosa sono?

Per una serie di contrattempi il video che ho realizzato per il laboratorio “Libri digitali” di Handimatica 2008 non è stato presentato. Sono molto contrariato, non lo nego, anche perché fra i motivi di questa scelta dell’organizzazione il coordinatore del laboratorio mi ha scritto: “Noi attendevamo la sua presenza al laboratorio” e “Infatti la presenza fisica del relatore è indispensabile per la sessione di domande”. Questo nonostante nel programma dell’intervento ci fosse scritto fin dall’inizio “Tutti ne parlano e nessuno la fa (contributo videoregistrato), Livio Mondini – Esperto di editoria e di accessibilità”. Ne è seguito uno scambio di email analogo a quello occorso nel caso “Webagencies le tragicomiche“, che anche in questo caso eviterò di riportare.

Ma li trovo tutti io?

Sarò malizioso, ma secondo me il video lo hanno visto e dopo averlo fatto hanno deciso che era meglio non mostrarlo. Ancora oggi accessibilità è sinonimo di assistenzialismo, non si tende all’autonomia dell’utente ma a gestirlo, a creare dipendenza. Venghi, venghi signor disabile, che ci penso io a lei. Più disabili, più fatturato. Vergogna. Nel filmato invece viene negata la necessità di questo atteggiamento pietistico e l’inutilità fondamentale di quelle associazioni che lucrano sulla creazione di “libri accessibili”, termine all’interno del quale viene collocato di tutto, duplicati all’inverosimile e di qualità del tutto aleatoria. Non so se lo sapete, ma sono milioni di euro a carico del contribuente. Inoltre, dimostro praticamente l’infondatezza totale di alcune leggende metropolitane come “un file txt è accessibile“, “gli editori hanno già il file digitale pronto da usare“, “il futuro è il txt“, e via con amenità varie. Troppo scomodo per qualcuno.

In ogni caso, può benissimo essere che invece non siano riusciti davvero, come sostengono fra le altre cose, a scaricare il file. Non so se è preferibile questa ipotesi o la precedente: possibile che in una manifestazione che si presenta come “Mostra Convegno Nazionale – Tecnologie per la qualità della vita” non ci sia qualcuno in grado di scaricare un file o di fare una telefonata e dirmi guarda che non riesco, che devo fare? Mah. Peccato che fra i presenti al laboratorio ci fossero almeno un paio di persone che il file l’avevano già scaricato (e visto) dallo stesso link. Ri-mah.

Gli argomenti trattati erano secondo me interessanti. Invece che i soliti discorsi e bla bla, una dimostrazione pratica eseguita con Word, Quark XPress e Acrobat su come funziona l’accessibilità nei file XHTML, doc, PDF mostrando cosa accade nelle API MSAA quando nel documento vengono incluse o meno determinate caratteristiche, prima fra tutte la struttura.

Che cosa rende accessibile un libro digitale? Non è il formato, sono le sue caratteristiche. Un file txt è quanto di più lontano possa esistere da un libro digitale accessibile, così come non è un libro digitale accessibile un libro parlato. Inutile parlare di PDF, ODF, XHTML, XML se il file non è fatto in un certo modo. Il formato di distribuzione che hai scelto permette di rispettare le caratteristiche necessarie? Ok, è quello giusto.

Se qualcuno fosse interessato a capire come, perché e quando un libro digitale può essere definito accessibile, è possibile scaricare lo zip dell’intervento video (è grosso 115 mega e dura circa mezz’ora, gentilmente ospitato da Diego La Monica). Dopo aver decompresso lo zip, nella cartella sarà disponibile il file HTML che lancia il filmato (Libri digitali accessibili.html), oppure è possibile visualizzarlo nel Flash Player facendo doppio clic su “libri digitali accessibili.exe”.

È necessario un monitor a risoluzione almeno 1024×768, perché ho catturato l’interfaccia dei programmi utilizzati e l’area necessaria è ovviamente ampia, ulteriori compressioni causano un decadimento inaccettabile della qualità video del filmato. Ho notato che l’audio, estremamente compresso per contenere le dimensioni, ogni tanto mi fa la voce da Paperino. Abbiate pazienza, l’importante è che si capisca.

Moduli in PDF salvabili e compilabili offline

Nota del 13/07/2012: questo post è del 2008, ma ricevo ancora molte richieste di informazioni a questo proposito. Nel frattempo, la policy di Adobe su questa tematica è cambiata: il “vecchio” Live Cycle diventerà una applicazione separata, ed è disponibile un nuovo servizio chiamato Adobe FormsCentral.

La tematica della modulistica in PDF è importante, e ancora di più se si progettano e realizzano moduli PDF accessibili. Per ottenere questo risultato è necessario disporre, come al solito, di Acrobat Pro. Dopo l’installazione del programma sarà disponibile LiveCycle, un programma che permette di realizzare modulistica PDF in modo piuttosto semplice e che prevede fra i suoi strumenti un pannello Accessibilità che permette di definire le caratteristiche di accessibilità di tutti gli elementi del modulo.

Il modulo può essere realizzato in diversi modi: partendo da modelli predefiniti, da file Word, da zero. In ogni caso, quello che otterremo è un documento che contiene gli elementi tipici di un modulo, come elenchi a discesa, caselle di controllo, pulsanti di opzione, campi, e così via.

Gli oggetti predefiniti sono molti, e per utilizzarli basta trascinare l’elemento desiderato dalla palette Libreria al foglio. Per esempio, nella figura successiva si vede un campo di testo completo di didascalia inserito nella pagina.

L'interfaccia di LiveCycle

Per ciascun elemento, nell’area destra dell’interfaccia sono visibili tre pannelli: Oggetto, Layout e Accessibilità.

Il primo pannello permette di definire diverse caratteristiche dell’elemento fra cui la fondamentale Didascalia (un po’ come se fosse il <label for...> di HTML). Il secondo permette di definire la posizione dell’elemento e della didascalia rispetto allo stesso, l’ultimo pannello è autoesplicativo.

Da notare anche l’area sinistra dell’interfaccia: il pannello Gerarchia mostra il tree del documento XML che delinea il modulo (per visualizzare il codice XML, basta selezionare Visualizza > Sorgente XML. Le modifiche effettuate nel codice si riflettono nella vista grafica. A buon intenditor…), ed è utilissimo per verificare l’ordine di lettura degli elementi: clic su una voce del tree, e il corrispondente elemento appare selezionato nel foglio. È ovvio che gli elementi devono comparire nel tree secondo il corretto flusso, e non è così automatico che questo accada. Se notate incongruenze, basta trascinare e rilasciare l’elemento fuori posto nel tree.

Al momento del salvataggio del file verificate che sia attiva la casella di controllo Genera informazioni di accesso facilitato (tag) per Acrobat, ed ecco pronto il modulo.

Sì, però il file così distribuito non è compilabile e modificabile offline, eventuali modifiche degli inserimenti vanno perse anche facendo un Salva e l’unica opzione sembrerebbe essere compilare, stampare e spedire via fax o disporre di sofisticati server con estensioni mirabolanti.

No dai, nell’era del Web 5.0 sarebbe una prestazione davvero scarsa.

Come risolvere? È facilissimo. Basta aprire il modulo in Acrobat Pro e selezionare Avanzate > Abilita diritti di utilizzo in Acrobat Reader. Salvate, fatto. Il modulo potrà essere salvato in locale, compilato e modificato quante volte si desidera.

Quando il modulo è completo lo si potrà firmare elettronicamente e inviare come allegato per e-mail completo in ogni sua parte.

Standardista? Partecipa al Blue Beanie Day 2008!

Vuoi dare uno sgrullone all’apatia verso i Web Standards? Partecipa al Blue Beanie Day 2008, “2nd Annual Blue Beanie Day to Promote Web Standards”.

È facile: per il 28 novembre,

  1. procurati una berretta blu;
  2. fatti una foto con la berretta o quel che hai trovato in testa;
  3. pubblica la foto, o le foto, su Facebook, Flickr, Twitter e tutti i social network che usi. Ricordati di impostare la foto come predefinita nel tuo profilo Facebook.

Jeffrey Zeldman con la berretta blu

Blue Beanie Day 2008

Libri digitali accessibili a Handimatica: tutti ne parlano, nessuno li fa

Fra i vari interventi di Handimatica 2008, esistono degli spazi chiamati Laboratori fra cui uno dedicato ai libri digitali accessibili. Non riuscirò ad essere presente di persona e allora mi sono inventato un intervento video, cosa che non ho mai fatto e per questo stimolante.

Chissa se riesco a presentare del materiale abbastanza interessante, se ce la faccio aprirò un Youtube Channel per Biroblu, sarebbe una bella cosa riuscire a prendere confidenza con questi strumenti e proporre del materiale pratico su cui discutere. È un argomento stimolante, nuovo, che richiede professionalità che ancora non esistono.

Anche io non posso essere “un esperto”, ma almeno ci ho provato e quindi possiedo un’esperienza da condividere.

Gli interventi previsti nel laboratorio mi sembrano tutti interessanti, anche se il programma è ancora in via di definizione:

AGENDA

Coordinatore: Marzio Bossi – Centro Internazionale del Libro Parlato “A.Sernagiotto” di Feltre

Interventi:

  • Tutti ne parlano e nessuno li fa” ,
    Livio Mondini – Esperto di editoria e di accessibilità (contributo video)
  • Libri digitali: le attività dell’Istituto Cavazza“,
    Ferdinando Torrente – Istituto dei Ciechi F. Cavazza – Bologna
  • Accessibilità dei pdf aperti“,
    Maria Grazia Pancaldi – Associazione Italiana Dislessia
  • L’audiolibro può diventare una opportunità di imprenditorialità anche in Italia?“,
    Mauro Lenzi – Bronteion Audiolibri
  • Progetti e proposte dell’Associazione Italiana Editori“,
    Cristina Mussinelli – consulente Associazione Italiana Editori per l’editoria digitale
  • I libri parlati per l’uso di persone che non sono in grado di leggere autonomamente. Attualità e prospettive“,
    Marzio Bossi – Centro Internazionale del Libro Parlato “A.Sernagiotto” di Feltre
  • Dalla Legge Stanca ai progetti per l’editoria accessibile“,
    Antonio Devanna – Dipartimento per l’Innovazione e le Tecnologie del Ministero per la pubblica amministrazione e l’innovazione

La mia intenzione è di cercare di definire alcuni “paletti” e almeno la terminologia, poiché ancora oggi è comune pensare che un libro digitale accessibile sia un file .txt, o che un audiolibro sia “un libro digitale accessibile”. Non è vero. Un txt è quanto di più lontano si possa immaginare dall’accessibilità, così come uno screen reader è soltanto un software, non un arbitro dell’accessibilità.

Attenzione: i laboratori sono a numero chiuso ed è necessaria l’iscrizione.

Peccato non poter essere là di persona ma soltanto in forma di avatar, mi sarebbe piaciuto poterci mandare il mio alter ego in Second Life, il gatto Livio. Ma non si può, pazienza, sarà per la prossima volta.

Il gatto Livio e Viola con la Harley Davidson

Quanto valgono le pagine realizzate secondo gli standard W3C per Google?

Domanda difficilissima, ovviamente nessuno lo sa[1. Gli algoritmi dei motori di ricerca sono ovviamente piuttosto segreti, ed è impossibile sapere che peso abbiano gli elementi presi in considerazione per calcolare il posizionamento. Però, è facile farsi un’idea dell’appetibilità da parte dei motori di ricerca del proprio sito utilizzando strumenti online come Web Site Grader. Basta inserire l’URL della pagina che si vuole analizzare per ottenere un report piuttosto dettagliato.]. C’è chi dice sì, chi dice no, chi forse. Resta il fatto che tutti i motori di ricerca nelle proprie linee guida richiedono codice well-formed[2. Per verificare la correttezza formale del codice delle proprie pagine, basta usare il W3C Validator, inserendo nella casella di testo Address l’URL della pagina che desiderate controllare.] , ma non si sa bene quanto “pesa” questa caratteristica nella determinazione del posizionamento. Come già detto, non sono un esperto di SEO, quindi vado un po’ a naso. Però, se tanto mi dà tanto, mi sembra evidente che una pagina ben costruita e valida sia più facilmente interpretabile da un crawler: struttura chiara, codice ben delineato = minori risorse necessarie a decifrare un intrico di markup per identificare i contenuti, maggiore precisione dei risultati, velocità senza dubbio più elevata, per dire le prime cose che mi vengono in mente. È quasi banale che sia così, dal mio punto di vista.

Comunque, è interessante l’esperimento svolto da HOBO. Creato un set di pagine con uguali caratteristiche, ma diverse nel codice (1 Valid Html + CSS, 1 Valid HTML + Invalid CSS, 1 Invalid HTML + Valid CSS, 1 Invalid HTML + Invalid CSS) dal test (meno male, una volta tanto non chiacchiere ma fatti) risulta chiaramente che la pagina che si posiziona per prima è quella con HTML e CSS validi.

It just happens that Google seems to prefer the page with valid code as laid down by the W3C (World Wide Web Consortium).

E, cosa che mi sembra assolutamente rilevante,:

this might be the difference in whether or not you rank higher in Google serps than your competitors.

Dello stesso parere è SeoKin, che titola: “If Content Is Google’s King – Then Valid Code Must Be Its Prince!, riportando una citazione addirittura di Matt Cutts di Google tirato un po’ per la manica della giacchetta su questo argomento, che diplomaticamente afferma:

“Personally, I do think creating clean code that validates and works on many different browsers will be an important skill for webmasters and web designers.”

E adesso? Parlo della sola validazione perché sul peso della semantica dei tag non c’è alcun dubbio, visto lo sbattimento che si danno i SEO sugli elementi <h>, attributi alt e title, <a> e così via. Se tutte quelle keyword così sudate le metti nel posto sbagliato non funzionano, vero? Chissa come mai ci sono quelle strane relazioni fra i contenuti, e qualcuna funziona meglio e altre peggio.

Come dice Ben Buchanan,

Basically, semantics give structure to a document in a way that computers can understand. In this case, the best thing for humans is the best thing for machines too.

Tag soup or semantically-void pages—even the ones that validate—don’t have this structure. <font> tags have no semantic meaning, nor do layout tables (no heading cells) or even <div> and <span> tags (no matter how you style them). Only the real thing will do.

Stiamo parlando di cose che dovrebbero essere alla base delle conoscenze di chiunque faccia Web-qualcosa, il minimo dei minimi e non di strepitose performance “gurali”.
Vuoi vedere che realizzare delle pagine come si deve e standard porta anche a migliori posizionamenti? Sarà un caso che Google nel suo tutorial video intitolato “Crawling and Indexing” mette nella prima slide, nella prima riga, secondo 00.00 la frase “Understanding Accessibility“? “Ma che cosa balzana, pensavo che fosse il contenuto l’importante”, dice il SEO. Certo che lo è, ma come fa un povero disgraziato di crawler a capire quali sono le relazioni fra gli elementi della pagina, che quello è un titolo, per esempio, che quest’altro è del testo, questa una tabella se non glielo dici esplicitamente con i tag HTML, e ben scritti?
“Ma dai, ma smettila, vorresti dire che quegli strani concetti di quei dementi degli standard funziona anche con gli spider? Robe da matti, stai dicendo che delle pagine fatte bene funzionano meglio di pagine fatte male? Devi essere un pazzo”. Dice il SEO guru.

Io rispondo cambiando un po’ la domanda iniziale: ma per voi, quanto vale riuscire a salire nei risultati della ricerca e superare quel delinquente del vostro concorrente?

Avete pensato che invece di spendere tutti quei soldi in SEO tecniche forse bastava cambiare webmaster o agenzia e prenderne uno che capisse di standard e accessibilità? Compreso nel prezzo un sito di migliore qualità per tutti, utenti e motori di ricerca.

DOPO, eventualmente, mi dedico al SEO. Che senso ha spendere soldi su un sito mal fatto sperando di rattopparlo con le tecniche SEO? Non è preferibile prima fare bene il sito e poi dedicarsi al tweaking?

Web agencies le tragicomiche

Sottotitolo: Scano il grande Babau.

Questa è davvero bella. Come già raccontato, sto dando una mano a un mio amico affinché riesca almeno a rattoppare un grosso investimento che ha fatto in un portale con risultati mediocri.

Il portale è gestito con un CMS, che si presenta affermando: “xxxxxx genera pagine xHTML (nuova versione del linguaggio HTML) molto leggere e compatibili con le specifiche del W3C. Questa nuova evoluzione permette di creare pagine web più accessibili e fruibili.”

Bene, mi dico, che culo almeno il codice sarà a posto. Provo una semplice verifica con CSE Validator, e voilà, gli errori sono talmente tanti che il prode CSE si inchioda, è la prima volta che mi capita di vedere una cosa del genere. Riduco il numero di pagine da verificare, soltanto il primo livello. Report da 6 mega per 50 pagine, mai visto. Errori medi per pagina 110+90 warning. Alla faccia del codice W3C compliant…

Vabbè, scrivo a questi signori e dico “Scusate, ma voi affermate questo, questo e quest’altro. Inoltre, fra le varie cose da considerare ci sarebbero le richieste di Google, Yahoo Search e Live Search. Siccome avete venduto il vostro lavoro come un prodigio della scienza e della tecnica, ci piacerebbe che almeno il sito fosse conforme alle richieste esplicite dei motori di ricerca, compreso un test con Lynx e la validità del codice come richiesto da Google”.

Sapevo di toccare un nervo scoperto, ma mai mi sarei aspettato che il “software manager” (che sarà?) dell’azienda mi rispondesse una cosa veramente esilarante, per me. Lui alle mie risposte di certo non si è divertito.

Comunque, questo tizio mi dice (potete cominciare a ridere):

“xxxxxx e’ sempre stata pronta ad accogliere proposte relative a migliorie riguardo il SEO. La sua decantata pulizia del codice e’ arretrata. Sa che ormai Google legge flash? Sa che io sono stato membro della commissione per l’accessibilita’ in Italia? Conosce Scano? Ahime’, la sua filosofia e’ aria fritta.”

Cioé, mi minaccia chiedendomi se conosco Scano (ma che avrà voluto dire? Mi avrebbe aizzato contro Roberto? Roberto sarebbe venuto a picchiarmi nottetempo?) e che LUI è stato membro della commissione per l’accessibilità in Italia (cosa ovviamente non vera)? A me?

Per compassione non riporto lo scambio di email successivo, ora questo bel somaro sta tentando di farsi aggiungere in Skype da Roberto, che giustamente lo ha messo in blacklist, perché gli ho detto che Roberto l’avrebbe diffidato dall’usare il suo nome e quello di IWA ed è terrorizzato. Cioé, non si preoccupa della causa che gli farà il mio amico se non mette a posto il sito, ha paura di Scano! E dire che mi sembrava una persona così gentile e a modo, Roberto.

Ma che gente c’è in giro per il Web? Saranno mica amici dei tizi segnalati da Lauryn?E sto parlando di una grossa web agency, non di ragazzini. Mah.

La causa, se avverrà ma dubito perché ho preparato un cartoncino con la foto di Scano da mostrare a quelli dell’agenzia se non volessero ottemperare (chi mi conosce sa che lo farò), sarà decisamente interessante. Perché se tu, web agency o professionista, mi dici che il sito fatto da te è ottimizzato per i motori di ricerca e il codice prodotto è conforme agli standard ma a una semplice verifica si scopre che non è così e non rispetti nemmeno le linee guida dei motori di ricerca, i reati commessi sono diversi, dal penale al civile.

La discussione per ora si è fermata a questo punto: “Buongiorno Livio. Sono veramente rattristato che questa discussione sia andata su binari poco piacevoli. Il mio intento è quella di aiutare tutti gli utenti finali del CMS. Le sue richieste sono a livello tecnico chiare. Gradirei però avere un confronto telefonico con lei. E’ possibile? Può darmi un contatto?“, dice l’asino.

Inoltre mi chiede: “[…]Detto questo, come intende procedere? Visto che lei è il cliente, ci richiede lo standard W3C? L’accessibilità?“, dimostrando per l’ennesima volta di non avere capito nemmeno l’argomento e di confondere il codice valido con l’accessibilità. Come tanti altri “professionisti”, purtroppo.

Io rispondo:

“Proprio lei non ce la fa a capire: Google indicizza qualsiasi cosa a cui possa accedere, è pacifico. A noi non interessa una indicizzazione mediocre, come dimostrano i risultati. Vogliamo e pretendiamo la migliore indicizzazione possibile, come richiesto da progetto e come pagato.
A noi basta che le pagine siano fatte come richiede Google nella sua guida per i webmaster
(http://www.google.com/support/webmasters/bin/answer.py?answer=35769), Yahoo nella analoga guida (http://help.yahoo.com/l/us/yahoo/search/ranking/ranking-02.html) e Live Search altrettanto (http://help.live.com/help.aspx?mkt=en-us&project=wl_webmasters).
Il sito xxxxxxxxx è ben lontano dal rispettare le richieste tecniche di queste guide dei principali motori di ricerca, non c’è da discutere altro se non l’adeguamento del sito.
Questo nonostante fra le richieste di progetto ci fosse al primo posto la richiesta della migliore indicizzazione possibile.
La invito per l’ennesima volta a smettere di stupirsi e a cominciare a lavorare”.

Perché è un conto discutere di rispetto o meno di standard de facto, un altro se mi certifichi che il tuo sito sarà conforme alle richieste dei motori di ricerca e poi non è così per vari motivi, che comprendono l’ignoranza e l’incapacità.

Ricordo a tutti i webmaster, le web agencies, e a chi lavora su queste cose, che Google dice espressamente delle sue linee guida:

Ti consigliamo di attenerti a queste istruzioni affinché Google trovi, indicizzi e classifichi il tuo sito.

Live Search dice: “Use only well-formed HTML code in your pages. Make sure that all tags are closed, and that all links open the correct web page”.

Se non lo fai, ‘azzi tua… Ora vallo a spiegare ai tuoi clienti come mai hanno speso migliaia di euro, farcito i loro testi di ogni carambola letteraria, riempito le pagine con astruse formule esoteriche e nonostante tutto il loro sito nella SERP non sale. Cosa fai, chiami il babau?

PDF con tag e accessibilità

Capita, come in tante altre occasioni, di sentir dire in modo un po’ approssimativo che “i PDF taggati sono accessibili”. Bè, non è vero, è come dire che una pagina HTML siccome è in HTML è accessibile. Magari, verrebbe da dire.

Certamente un PDF dotato di una struttura a tag è il primo passo necessario verso l’accessibilità. Ma, proprio come accade con le pagine Web, è soltanto un pezzetto del puzzle.

Il formato PDF dispone di un proprio set di tag standard, un po’ come fosse una DTD (è soltanto una semplificazione, non prendetela alla lettera), e dispone di vari elementi, adatti a descrivere il significato semantico dei contenuti a cui si applicano. Gli elementi disponibili sono (dall’help di Acrobat):

Elementi contenitore

Gli elementi contenitore rappresentano il livello più alto e offrono un raggruppamento gerarchico agli altri elementi di livello blocco.

<Document>
L’elemento principale nella struttura ad albero tag di un documento.
<Part>
Rappresenta una suddivisione ampia del documento e può raggruppare unità di contenuto di dimensioni inferiori, ad esempio elementi reparto, articolo o sezione.
<Div>
È un elemento di livello blocco generico o un gruppo di elementi di livello blocco.
<Art>
È un corpo del testo indipendente e viene considerato un resoconto singolo.
<Sect>
Si tratta di un tipo di elemento contenitore generico, paragonabile a Reparto (DIV Class=“Sect”) in codice HTML; in genere è un componente di un elemento parte o articolo.

Elementi titolo e paragrafo

Sono elementi di blocco che includono specifici livelli di titoli e paragrafi di testo generici <P>. Un elemento <H> può presentarsi come primo child di un livello div superiore. Per le situazioni in cui non esistono sezioni annidate sono disponibili sei livelli di titolo <H1><H6> generici.

Elementi etichetta ed elenco

Gli elementi etichetta ed elenco sono elementi di livello blocco utilizzati per conferire una struttura agli elenchi.

<L>
Una qualsiasi sequenza di voci dal significato o da un altro tipo di pertinenza simile. È possibile che gli elementi secondari diretti siano elementi voce di elenco.
<LI>
Qualsiasi voce inclusa in un elenco. È possibile che presenti un elemento etichetta (facoltativo) e corpo elenco (obbligatorio) come elemento secondario.
<LBL>
Etichetta. Un punto elenco, un nome o un numero di identificazione per distinguere un elemento dagli altri all’interno dello stesso elenco.
<LBody>
Elemento corpo elenco. Il contenuto descrittivo di una voce di elenco.

Elementi testo speciale

Gli elementi di testo speciale identificano parti del testo non utilizzate come paragrafo generico (P).

<BlockQuote>
Elemento virgolette blocco. Uno o più paragrafi attribuiti ad un autore diverso da quello del testo immediatamente circostante.
<Caption>
Elemento didascalia. Una breve parte di testo che descrive una tabella o una figura.
<Index>
Elemento indice. Una sequenza di voci contenenti testo identificativo ed elementi di riferimento che indicano la ricorrenza di tale testo nel corpo principale del documento.
<TOC>
Elemento sommario. Un elemento contenente un elenco strutturato di voci ed etichette che identificano le voci e dotato di una struttura gerarchica separata.
<TOCI>
Elemento voce di sommario. Un elemento contenuto in un elenco associato ad un elemento sommario.

Elementi tabella

Gli elementi tabella conferiscono struttura alle tabelle.

<Table>
Elemento tabella. Una disposizione bidimensionale di celle di testo o di dati contente elementi riga di tabella come elementi secondari, nonché un elemento didascalia come primo o ultimo elemento secondario (facoltativo).
<TR>
Elemento riga di tabella. Una riga di intestazioni o dati in una tabella. È possibile che contenga elementi di cella di tipo intestazione di tabella e dati di tabella.
<TD>
Elemento di cella dati di tabella. Una cella di tabella contenente dati diversi dal tipo intestazione.
<TH>
Elemento di cella intestazione di tabella. Una cella di tabella contenente un’intestazione o dei dati che descrivono una o più righe oppure colonne di una tabella.

Elementi di livello in linea

Gli elementi di livello in linea identificano una porzione di testo caratterizzata da una formattazione o un comportamento specifico. Sono distinti dagli elementi di livello blocco. È possibile che gli elementi di livello in linea contengano o siano inclusi in elementi di livello blocco.

<BibEntry>
Citazione bibliografica. Una descrizione che riporta la fonte originale delle informazioni menzionate nel testo.
<BlockQuote>
Una parte di testo in linea attribuita ad un autore diverso da quello del testo circostante. È un elemento distinto da virgolette blocco, che a differenza del testo in linea includono uno o più paragrafi per intero.
<Span>
Un segmento di testo in linea qualsiasi. In genere, viene utilizzato per delimitare del testo associato ad un gruppo di proprietà di stile.

Elementi di livello in linea speciali

Sono simili agli elementi in linea; descrivono una parte di testo in linea caratterizzata da una formattazione o un comportamento speciale.

<Code>
Elemento voce codice. Codice di programmazione informatica incorporato in un documento.
<Figure>
Elemento voce figura. Una rappresentazione visiva o un elemento di grafica associato al testo cui si riferisce.
<Form>
Elemento voce modulo. Un’annotazione modulo PDF compilabile o già compilata.
<Formula>
Elemento voce formula. Una formula matematica.
<Link>
Elemento voce collegamento. Un collegamento ipertestuale incorporato in un documento. L’oggetto di destinazione può essere all’interno dello stesso documento, in un altro file PDF oppure su un sito Web.
<Note>
Elemento voce nota. Documentazione o testo esplicativo, ad esempio una nota a piè di pagina o di chiusura, a cui viene fatto riferimento all’interno del corpo del testo principale.
<Reference>
Elemento voce riferimenti. Una citazione di testo o dati non inclusi nel documento.

Tutti questi elementi sono disponibili nella scheda Tag di Acrobat Pro, che permette di applicarli ai vari elementi del documento o di modificare i tag assegnati. In questo modo il file PDF godrà di diversi vantaggi, poiché i tag standard rendono disponibili a software e periferiche di supporto un gruppo basilare di elementi strutturali e semantici per l’interpretazione della struttura del documento e la presentazione del relativo contenuto in un formato significativo per l’utente.
Inoltre, la conversione a altri formati sarà senza dubbio più precisa ed efficace.
Questa è l’architettura dei tag base PDF, ovvero la “grammatica formale pubblicata”, per dirla con le parole dei requisiti della Stanca. Quindi, i file PDF dovrebbero essere perlomeno conformi al requisito 1 del decreto relativo, e anche il 17 poiché si riferisce a “oggetti di programmazione”, come il plugin Acrobat o il Reader stand-alone.
È importante notare le parole “architettura dei tag base”. Perché? L’architettura dei tag PDF può essere estesa, e un PDF può contenere qualsiasi gruppo di tag utilizzato da una data applicazione di authoring.
È possibile che un file PDF presenti tag XML acquisiti da uno schema XML (anche quando il tag viene prodotto a partire da un file XHTML, ricordiamolo). È necessario che tutti i tag personalizzati definiti dall’utente, quali i nomi di tag generati da un’applicazione di authoring (un word processor, un programma di impaginazione) a partire dagli stili di paragrafo (requisito 1 dell’allegato A al decreto 30 aprile 2008, “Regole tecniche disciplinanti l’accessibilità agli strumenti didattici e formativi a favore degli alunni disabili”) dispongano di una mappa ruolo per correlare ciascun tag personalizzato ad un tag standard.

La mappa ruolo è un riferimento che consente al software di supporto di interpretare correttamente i tag personalizzati: è per questo che nella finestra di dialogo Proprietà ritocco, che mostra le proprietà del tag applicato all’elemento selezionato sono disponibili due schede: Contenuto e Tag. Nessuno ci fa caso, così si vedono in giro documenti PDF con tag dove un titolo di Livello 1 è posizionato in un contenitore di tipo Paragrafo. Quando questo accade, uno screen reader, per esempio, non riuscirà a “intercettare” i titoli. Si può dire accessibile un PDF così? No, secondo me no.

la scheda Tag in Acrobat Pro

Che dire, sempre più difficile : -)