È vero: all’inizio non è facile capire perché valga la pena utilizzare lo standard Xhtml per la costruzione delle pagine.
Quello su cui molti si interrogano è la reale necessità di passare da un linguaggio (Html) ad un altro che gli somiglia e sembra aggiungere poche (forse nessuna) funzionalità di rilievo.
A questo si aggiungono i dubbi sui costi di aggiornamento e addestramento per un sito che possa definirsi accessibile: utilizzo dei tag e degli attributi corretti, interpretazione e applicazione delle linee guida.
I due concetti possono sembrare tra loro distanti, ma hanno invece diversi punti in comune.
Potremmo dirvi (anzi, l’abbiamo già fatto in un precedente articolo) che Xhtml è lo standard del futuro, che aiuta a separare lo strato di presentazione dal contenuto, che può essere esteso con la creazione di moduli, ecc.
Quello che però vogliamo presentare oggi è un esempio legato da un lato al tema dell’accessibilità web, dall’altro al costo dei contenuti.
In “Il vero costo dell’accessibilità web” abbiamo detto che i contenuti di un sito costano, e costano molto. Per questo motivo, è necessario costruirli efficacemente.
Di conseguenza, perchè il contenuto di un sito sia costruito in modo efficace, è necessario che si verifichino queste condizioni:
- dev’essere scritto “correttamente”
- deve rispondere alle domande degli utenti
- dev’essere facilmente ricercabile
- dev’essere facilmente indicizzabile
- dev’essere trasformabile
Per i primi due punti, come sviluppatori e designer, c’è ben poco da fare: il contenuto va scritto da persone competenti.
Il nostro ruolo è quello di garantire (insieme a chi edita i testi) che il contenuto non rimanga sepolto nei meandri del sito, ma che possa essere trovato anche quando non è strillato ai quattro venti dalla Homepage.
Non solo, il contenuto va opportunamente categorizzato, perché chi usa il sito probabilmente ha un problema da risolvere, alla cui soluzione arriva procedendo dalla Homepage alle sezione e alle sottosezioni.
Ma il contenuto dev’essere anche trasformabile: quello che oggi è una pagina web domani potrebbe trasformarsi in un articolo cartaceo o in un documento Pdf. Per non parlare di visualizzazione su cellulari, Pda, ecc. Riscrivere una versione ad hoc per queste esigenze introdurrebbe degli altri costi.
Se lo standard Xhtml viene usato con “accortezza”, donerete al vostro contenuto il segreto dell’eterna giovinezza, perché potete passare da una versione all’altra senza riscrivere il contenuto. Ma non solo: lo fate con estrema semplicità, utilizzando lo standard Xsl.
Vediamolo con un esempio.
Convertire documenti Xhtml
Partiamo da una semplice (quasi banale) pagina che contiene un piccolo articolo. Ecco come è visualizzata:
Categoria: Sviluppo web
Come abbiamo già visto la scorsa puntata, con il solo Html non è possibile realizzare siti dinamici.
Per creare applicativi lato server è possibile ricorrere all’uso dei seguenti linguaggi di scripting (cfr. il manuale cartaceo a pag. 52):
Per costruire la pagina sono stati impiegati i tag e gli attributi che migliorano l’accessibilità e l’usabilità del documento: acronym, abbr, title, lang, ecc. Il sorgente è il seguente:
1 <html lang="it" xmlns="http://www.w3.org/1999/xhtml">
2 <head>
3 <title>Xhtml e i tag accessibili</title>
4 </head>
5 <body>
6 <p>Categoria: <span id="categoria"><strong>Sviluppo <span lang="en">web</span></strong></span></p>
7 <p>Come abbiamo già visto la <a href="http://www.foo.com/percorso1" title="Puntata precedente: sviluppare per il web">scorsa puntata</a>, con il solo <acronym lang="en" title="HyperText Markup Language">Html</acronym> non è possibile realizzare siti dinamici.</p>
8 <p>Per creare applicativi lato <span lang="en">server</span> è possibile ricorrere all’uso dei seguenti linguaggi di <span lang="en">scripting</span> (<abbr title="confronta">cfr.</abbr> il manuale cartaceo a <abbr title="pagina">pag.</abbr> 52):</p>
9 <ul>
10 <li>
11 <acronym lang="en" title="Active Server Pages">Asp</acronym> di <a href="http://www.microsoft.com" title="Sito web di Microsoft Corporation"><span lang="en">Microsoft</span></a>, su <acronym lang="en" title="Internet Information Services">Iis</acronym>
12 </li>
13 <li>
14 <acronym lang="en" title="Java Server Pages">Jsp</acronym> di <span lang="en"><a href="http://www.sun.com" title="Sito web si Sun Microsystem">Sun</a></span>
15 </li>
16 <li>
17 <acronym lang="en" title="Hypertext Preprocessor">Php</acronym>
18 </li>
19 </ul>
20 </body>
21 </html>
Come vedete, il testo è arricchito da informazioni aggiuntive che ne migliorano l’accessibilità.
I vantaggi però non si fermano all’accessibilità: il fatto che il documento sia standard Xhtml consente la realizzazione, tramite Xsl, di opportuni fogli di trasformazione che consentono di tradurre il documento in un altro formato.
Un esempio di risultato (forse il più semplice tra gli infiniti disponibili) è il seguente:
Categoria: Sviluppo web
Come abbiamo già visto la scorsa puntata, con il solo Html non è possibile realizzare siti dinamici.
Per creare applicativi lato server
è possibile ricorrere all’uso dei seguenti linguaggi di scripting (cfr. il manuale cartaceo a pag. 52):
- Puntata precedente: sviluppare per il web –
http://www.foo.com/percorso1 - Sito web di Microsoft Corporation –
http://www.microsoft.com - Sito web si Sun Microsystem –
http://www.sun.com
- Html:
HyperText Markup Language - Asp:
Active Server Pages - Iis:
Internet Information Services - Jsp:
Java Server Pages - Php:
Hypertext Preprocessor
- cfr.: confronta
- pag.: pagina
- Sviluppo web
Come potete vedere, l’articolo è stato stravolto: sono stati estratti e separati gli acronimi, le abbreviazioni, le parole in lingua straniera e i link.
Sono anche state aggiunte alcune funzionalità:
- se selezionato un acronimo vi collegate a Google, dove troverete una definizione estesa del termine
- se selezionate un termine straniero interrogare invece Babylon, che cercherà di trovare il corrispettivo italiano
- compare un elenco dei link e il testo di accompagnamento è l’attributo title del link
Abbiamo ricavato molte informazioni precise da un testo davvero modesto.
Inoltre, il tempo necessario per la costruzione del foglio Xsl per la trasformazione ha richiesto non più di un’ora ed è applicabile a qualsiasi documento Xhtml.
Usare lo standard Xhtml insieme ai tag di solito ignorati (quelli che migliorano
l’accessibilità), vi apre quindi molti scenari:
- possibilità di realizzare una copia per il mondo cartaceo
- conversioni per telefoni e Pda
- costruzione automatica di indici e tabelle con le abbreviazioni
- elenco dei link presenti nella pagina
- isolamento dei termini stranieri
- categorizzazione dei contenuti della pagina (per parole d’ordine, tipologia, ecc.)
Possibili obiezioni
Come tutte le metologie, sono naturali alcune critiche al metodo sopra illustrato. Cerchiamo di prevederle insieme.
Non è meglio usare l’Xml come lingua franca per poi trasformare i documenti?
Senza dubbio l’Xml è il candidato principe alle trasformazioni Xml.
In questa sede stiamo però parlando di contenuti, che come tali saranno inseriti da un editor di competenze tecniche limitate.
È sicuramente possibile utilizzare l’Xml per categorizzare un documento la cui struttura è fissa (titolo, sommario, categorie, data, ecc.), più difficile se i dati sono “semistrutturati“.
Poiché ogni documento ha una struttura diversa dagli altri (per numero e posizione degli acronimi, dei collegamenti, delle parole straniere), l’editor ha più controllo con lo standard Xhtml, di cui riesce agevolmente ad avere un’anteprima su browser.
Ma un documento Xhtml è una specializzazione di documento Xml, per cui sarà possibile trasformarlo senza rinunciare ad alcuna caratteristica.
Non è eccessivo il costo per produrre contenuti così ricchi di informazioni?
Il costo c’è e non è esiguo. Non solo: mentre scrivere Html è ormai alla portata di tutti, diventa ora importante che i documenti siano sintatticamente e semanticamente corretti.
Ma tanto più il business dipende dai contenuti (siano questi articoli, documenti, listini), tanto maggiore sarà il risparmio futuro.
È possibile trasformare un documento anche partendo dall’Html. Perché devo usare Xhtml?
Perché è estremamente più semplice.
Il formato Xml di per sé non rappresenterebbe niente di eccezionale se lo sviluppo di procedure di interrogazione e trasformazione fosse complesso e costoso.
In realtà, i vincoli di cui bisogna tener conto nella scrittura di un documento Xml (è case sensitive, ha un solo nodo padre, tutti i tag devono essere chiusi), fa si che i parser per l’interrogazione e la trasformazione siano molto efficienti e semplici da utilizzare.
Conclusione
Il contenuto incide in larga misura sui costi di realizzazione di un sito accessibile. Vale perciò la pena di realizzarlo secondo lo standard Xhtml ed utilizzando tutti i tag che arricchiscono il testo di informazioni.
In questo modo è possibile facilitare la ricerca e la memorizzazione dei documenti, ma anche le conversioni per altri media e formati e per future versioni del sito.