Usare tecnologie e linee guida del W3C

Formati proprietari e tecnologie W3C

La linea guida 11 rappresenta un invito esplicito agli sviluppatori a lavorare per la standardizzazione del Web: una standardizzazione intesa come applicazione delle specifiche tecniche emanate dal W3C, che si fa garante del loro costante aggiornamento e del consenso pubblico e democratico sul quale sono costruite. È interessante leggere le spiegazioni che accompagnano il testo di questa linea guida:

La linea guida corrente raccomanda le tecnologie W3C (per esempio: HTML, CSS ecc.) per diverse ragioni:

• le tecnologie W3C includono caratteristiche di accessibilità “incorporate”;
• le specifiche W3C sono sottoposte fin dall’inizio a revisione per assicurare che le questioni di accessibilità siano considerate durante la fase di progettazione;
• le specifiche W3C sono sviluppate all’interno di un processo aperto basato sul consenso dei produttori.

Molti formati non-W3C (per esempio: PDF, Shockwave ecc.) richiedono di essere visualizzati o per mezzo di plug-in o di applicazioni indipendenti. Spesso questi formati non possono essere visualizzati o navigati con i programmi utente standard (comprese le tecnologie assistive). Evitare caratteristiche non-W3C e non standard (elementi, attributi, proprietà ed estensioni proprietari) tenderà a rendere le pagine più accessibili per un maggior numero di persone che usano una più ampia varietà di strumenti hardware e software. Se proprio deve essere usata una tecnologia inaccessibile (proprietaria oppure no), occorre fornire pagine accessibili equivalenti.

Anche quando sono utilizzate tecnologie W3C, queste devono essere usate in accordo con le linee guida per l’accessibilità. Quando si utilizzano nuove tecnologie, assicurarsi che esse si trasformino elegantemente (si veda anche la linea guida 6).

Convertire documenti (da PDF, PostScript, RTF ecc.) a linguaggi di marcatura W3C (HTML, XML) non sempre produce un documento accessibile. Dopo il processo di conversione si validi perciò ogni pagina per verificarne accessibilità e usabilità […]. Se una pagina non può essere convertita senza difficoltà, si revisioni la pagina finché la sua rappresentazione originale sia convertita in modo appropriato oppure si fornisca una versione HTML o di puro testo.

Lasciamo da parte in questa sede la questione dell’effettiva accessibilità dei formati non W3C (si vedano in proposito i Capitoli 12 e 13 di questo libro). Resta il fatto che la conformità alla linea guida 11 delle WCAG 1.0 richiede che i contenuti pubblicati sul Web siano marcati con linguaggi del W3C, se ne esiste uno adatto allo scopo che si intende raggiungere.

Considerando l’immensa mole di documenti in PDF, DOC e RTF presenti sui siti della Pubblica Amministrazione italiana, è inevitabile pensare a quale gigantesca mole di lavoro sarebbe necessaria per convertire tali documenti, o anche solo i più recenti, in un formato W3C validato per l’accessibilità, dal momento che la gran parte di essi, esclusi quelli progettati esclusivamente per essere stampati, potrebbe certamente essere resa in HTML o in XHTML (per esempio: circolari, delibere, relazioni, leggi, regolamenti ecc.). Non abbiamo una soluzione ufficiale e definitiva da raccomandare, ma solo due suggerimenti:

• ricorrere al metodo del potenziamento progressivo ogni volta che sia possibile e sensato (rimandiamo, per questo, alle spiegazioni nei Capitoli 11 e 12), il che richiede, inevitabilmente, un lavoro di conversione dei documenti proprietari in formati W3C;
• applicare con pazienza e attenzione le regole per l’accessibilità fornite dai produttori dei formati proprietari.

Inizio pagina

Punto di controllo 11.1, priorità 2

Usare tecnologie W3C ogni volta che sia possibile

Il documento di Tecniche di base per le WCAG 1.0, datato novembre 2000, riporta al paragrafo 12 un breve elenco, senza specificare le versioni, delle tecnologie W3C fino a quel momento pubblicate:

• MathML per le equazioni matematiche;
• HTML, XHTML, XML per documenti strutturati;
• RDF per i metadati;
• SMIL per creare presentazioni multimediali;
• CSS e XSL per definire fogli di stile;
• XSLT per creare trasformazioni di stile;
• PNG per le immagini (benché in alcuni casi sia preferibile usare JPG, che non è una specifica W3C).

La situazione è oggi più complessa. Il World Wide Web Consortium ha pubblicato, fino a luglio 2007, qualcosa come centonove Raccomandazioni, che costituiscono altrettanti standard di riferimento per gli sviluppatori impegnati a produrre documenti interoperabili.

Si va dalle Specifiche sul DOM all’ampia famiglia, in perenne crescita, delle Raccomandazioni basate su XML; dai cosiddetti web service alle Specifiche per il Web semantico; dalle tecnologie per la multimedialità a quelle per la privacy (l’indice completo e aggiornato delle Raccomandazioni W3C è disponibile alla pagina http://www.w3.org/TR/#Recommendations ). Raccomandazioni a parte, esiste poi sul sito del W3C una massa quasi sterminata di documenti di supporto o in sviluppo: bozze di lavoro, note, approfondimenti, archivi delle mailing-list, sottositi dei gruppi di lavoro ecc. Per non parlare degli standard prodotti da altre organizzazioni come ECMA e ISO, anch’essi meritevoli di essere conosciuti e studiati.

Uno sviluppatore professionista interessato all’accessibilità non può più limitarsi a conoscere un HTML di base ed eventualmente le 14 linee guida delle WCAG 1.0. Lo sviluppo delle tecnologie e, soprattutto, delle loro implementazioni sul Web, impone di allargare gli orizzonti, dedicandosi allo studio anche di altri linguaggi e tecnologie. La formazione continua è l’unico mezzo per crearsi, e conservare negli anni, una competenza professionale adeguata, tale da essere spendibile con successo sul mercato del lavoro.

Le cose, tuttavia, sono meno difficili di come possono sembrare a prima vista. Esistono, infatti, due conoscenze fondamentali che un professionista del Web, indipendentemente dal suo interesse per l’accessibilità, deve possedere. Acquisire queste due conoscenze abbasserà notevolmente la curva di apprendimento di quasi tutte le nuove specifiche prodotte dal W3C. Esse sono:

1. una conoscenza accettabile dell’inglese scritto;
2. la conoscenza delle regole fondamentali di XML.

L’inglese è la lingua delle versioni normative dei documenti W3C. Per quanto siano numerose le traduzioni in italiano (e in altre lingue), e siano utili per acquisire familiarità con il linguaggio dei documenti di specifiche tecniche, non sempre esiste una traduzione e non sempre la traduzione centra perfettamente il senso di una frase o di un concetto. Per avere la certezza della fonte, è indispensabile perciò ricorrere sempre all’originale in inglese.

La conoscenza di XML, poi, è altrettanto indispensabile della conoscenza dell’inglese scritto. Molte delle Raccomandazioni prodotte negli ultimi anni dal W3C sono basate infatti sulla sintassi di XML. Sigle come SMIL, SVG, XSLT, SOAP, SSML, RDF, OWL identificano tecnologie che riguardano i più diversi ambiti di applicazione e che hanno tutte un denominatore comune: sono basate sulla sintassi di XML.

Insomma, chi padroneggia XML e l’inglese scritto può scorrere una nuova Raccomandazione pubblicata dal W3C e, anche senza leggere riga per riga tutto il testo, sarà in grado di afferrarne rapidamente le principali caratteristiche strutturali.

Inizio pagina

Per l’accessibilità, è meglio usare HTML o XHTML?

Chiunque si occupi di sviluppare siti web accessibili, deve necessariamente confrontarsi prima o poi con questo interrogativo: è meglio scrivere codice HTML o XHTML?

Il punto di controllo 11.1 non aiuta a chiarire le idee. Dice, infatti, di usare le versioni più recenti delle tecnologie W3C, quando siano 1) appropriate al compito e 2) supportate dai programmi utente.

Tocca, perciò, allo sviluppatore sforzarsi di capire quando un linguaggio di marcatura è appropriato al compito e decidere entro quali limiti il supporto fornito dai programmi utente deve reputarsi adeguato.

Cercheremo in queste pagine di fornire risposte ai quesiti che le due condizioni poste dal punto di controllo 11.1 fanno sorgere.

Differenze di codifica tra HTML e XHTML

Per capire in quali situazioni è appropriato usare XHTML e in quali, invece, è appropriato usare HTML, dobbiamo innanzitutto capire quali differenze vi sono tra i due linguaggi, in termini di struttura e di finalità.

Come è noto a chi abbia dato almeno uno sguardo alle Specifiche XHTML 1.0 , il linguaggio di marcatura XHTML è definito nel sottotitolo del documento A Reformulation of HTML 4 in XML 1.0, cioè una riformulazione di HTML 4 in XML 1.0.

In altre parole, XHTML 1.0 è HTML 4 riscritto secondo le regole di XML. A livello di elementi e attributi, non c’è nulla di nuovo rispetto a quanto è già nelle possibilità di HTML 4.01: tre DTD ha HTML 4.01 (strict, transitional e frameset) e le stesse tre ha anche XHTML 1.0. Dal punto di vista dell’accessibilità, le regole che si applicano ai documenti XHTML 1.0 sono le medesime che si applicano ai documenti HTML 4.01:

• evitare di usare elementi e attributi di presentazione;
• rispettare le regole della DTD dichiarata;
• rispettare il valore semantico degli elementi e degli attributi.

Se vengono applicate correttamente le tre prescrizioni precedenti, un documento HTML 4.01 sarà accessibile esattamente quanto un documento XHTML 1.0, purché entrambi siano riprodotti da browser forniti di adeguato supporto. Ciò vuol dire che, a condizione di usare un browser conforme, è assolutamente indifferente, ai fini dell’esperienza dell’utente, se il codice di una pagina web è HTML 4.01 o XHTML 1.0 (o anche XHTML 1.1).

Questa considerazione è di grande importanza, perché il passaggio da HTML a XHTML non è proprio indolore: ha limitazioni e controindicazioni, e merita perciò di essere fatto solo se c’è un’adeguata contropartita.

Vedremo in seguito se c’è e in che cosa consiste questa contropartita. Cerchiamo ora, invece, di capire le differenze tra i due linguaggi e le limitazioni che comporta l’uso di codice XHTML. Approfondire queste conoscenze è, infatti, un passo indispensabile, per attuare in modo corretto la richiesta del punto di controllo 11.1 delle WCAG 1.0.

Elenchiamo, perciò, di seguito le differenze tra XHTML e HTML, basandoci per buona parte sull’elenco contenuto nella sezione 4 delle Specifiche XHTML 1.0 (le caratteristiche evidenziate in corsivo nei titoletti si riferiscono a XHTML).

• I documenti devono essere ben formati. Il concetto di “ben formato” (well-formed) è stato introdotto con XML e, poiché XHTML è sintatticamente XML, deve rispettare questa regola fondamentale. La definizione tecnica di “ben formato” è contenuta nella sezione 2.1 delle Specifiche XML . Per i nostri scopi, ci basta sapere che significa essenzialmente che tutti gli elementi devono essere annidati in modo corretto, devono avere un marcatore di chiusura e non devono contenere entità non dichiarate e diverse dalle cinque entità legali in XML, che sono & (&), ' ('), < (<), > (>) e " (").

  [Inizio approfondimento] Differenza tra ben formato e valido

  Esiste una sottile differenza tra ben formato e valido. Consideriamo il codice nel Listato 16.1 A: gli elementi DIV e SPAN sono annidati in modo scorretto, cioè sono incastrati l’uno nell’altro, invece che contenuti l’uno nell’altro. Un documento che contenga questo frammento di codice non sarà ben formato e neppure valido. Consideriamo ora la correzione mostrata nel Listato 16.1 B. Ora DIV e SPAN sono annidati correttamente: il frammento di codice è ben formato, ma continua a essere non valido, perché in nessuna DTD di XHTML l’elemento DIV può essere un contenuto di SPAN. Per essere ben formato e valido, il frammento di codice deve allora essere corretto come nel Listato 16.1 C. Riassumendo: un documento può essere ben formato ma non valido, se gli elementi al suo interno sono annidati correttamente, ma uno o più di essi non rispettano i vincoli di contenuto definiti dalla DTD dichiarata. Per completezza d’informazione, aggiungiamo infine che un documento XHTML può essere valido anche senza essere ben formato (Listato 16.1 D). Una serie di esempi sono disponibili su http://www.webdevout.net/articles/validity-and-well-formedness . [Fine approfondimento]

  Listato 16.1. Codice mal formato e non valido (A), ben formato e valido (C), mal formato e valido (D).

  A. <span>Questo è un <div>testo di prova</span>.</div>

  B. <span>Questo è un <div>testo di prova</div>.</span>

  C. <div>Questo è un <span>testo di prova</span>.</div>

  D. <div>Questo è un <<span>testo di prova></span>.</div>

  NOTA BENE. Il punto D del precedente elenco è sbagliato e l'errore appare anche nella versione cartacea del libro. Il carattere "<" prima di <span>, non sostituito dalla sequenza di escape &lt; richiesta dalla DTD di XHTML 1.0 , rende il codice nell'esempio D non valido oltre che mal formato.

• I nomi di elementi e attributi devono essere scritti in caratteri minuscoli. Ciò è dovuto al fatto che XML, a differenza di HTML, è sensibile alla differenza tra forma maiuscola e minuscola: LI e li sono in XML due elementi diversi. In XHTML è stato perciò convenzionalmente stabilito di uniformare tutto alla forma minuscola.
• Per gli elementi non vuoti, sono necessari marcatori di chiusura. Mentre in HTML vari elementi possono essere aperti e non chiusi (P e LI, per esempio), in XHTML tutti gli elementi non vuoti devono essere chiusi con il corrispondente marcatore di chiusura. Quindi, se <p>Primo paragrafo<p>Secondo paragrafo è HTML corretto, in XHTML questo codice deve essere riscritto così: <p>Primo paragrafo</p><p>Secondo paragrafo</p>.
• I valori di attributo devono essere sempre racchiusi tra doppi apici. Mentre in HTML capita spesso di trovare codice in cui gli attributi numerici seguono direttamente il segno di uguale, ciò in XHTML è illegale. Perciò, <td colspan=3> deve diventare in XHTML <td colspan="3">.
• La forma minimizzata degli attributi è illegale. In HTML esistono attributi che hanno due soli valori, che possono essere omessi: se il nome dell’attributo compare nel codice di marcatura, allora è da intendersi il valore yes (“sì”), se il nome dell’attributo è omesso, allora è da intendersi il valore no. In HTML, per esempio, per indicare che una casella di controllo deve apparire spuntata, è perfettamente legale scrivere: <input type="checkbox" checked [...]. In XHTML, invece, l’attributo checked deve essere esplicitamente valorizzato e il codice precedente deve diventare: <input type="checkbox" checked="checked" [...].
• Gli elementi vuoti devono essere chiusi. In HTML è lecito usare elementi cosiddetti “vuoti” (empty), i quali non richiedono un marcatore di chiusura. Appartengono a questa categoria, per esempio, gli elementi META, IMG, INPUT, BR e HR. In XHTML, invece, ogni elemento vuoto deve essere chiuso. Esistono due metodi per chiudere un elemento vuoto: l’inserimento di un marcatore di chiusura oppure l’inserimento di un carattere barra ("/") prima della parentesi angolare destra (">") del marcatore iniziale. Dunque, mentre in HTML è legale scrivere semplicemente <br>, in XHTML dobbiamo avere o la forma con marcatore di chiusura <br></br> o la forma compatta <br/>.
• I caratteri spazio bianco nei valori di attributo vengono trattati secondo le regole di XML. Un parser XML (cioè un processore di codice XML) deve eliminare gli spazi iniziali e finali e ridurre a uno gli spazi intermedi nei valori di attributo. Alcuni caratteri trattati come spazio bianco in HTML sono però illegali in XML e, di conseguenza, lo sono anche in XHTML (per esempio il carattere U+000C).
• Gli elementi SCRIPT e STYLE contengono dati di tipo #PCDATA. Mentre in HTML i contenuti di questi due elementi sono del tipo CDATA, in XHTML sono invece del tipo #PCDATA. Ciò vuol dire che la presenza di caratteri <, > e & viene interpretata da un parser XML come, rispettivamente, l’inizio di un marcatore, la fine di un marcatore, l’inizio di un riferimento a caratteri. Per evitare, quindi, errori nell’elaborazione di un documento XHTML, dovuti alla presenza di tali caratteri nei contenuti degli elementi SCRIPT e STYLE, è necessario racchiudere tali contenuti all’interno di sezioni CDATA, come mostrato nel Listato 16.2. Tuttavia, se, per associare script e stili a un documento XHTML, si usano file esterni invece che gli elementi SCRIPT e STYLE, non è necessario racchiudere i contenuti di quei file tra sezioni CDATA.

  Listato 16.2. Inserimento dei contenuti degli elementi STYLE e SCRIPT in sezioni CDATA.

  <style type="text/css">

  <![CDATA[

  ... definizioni di stile

  (possono comparire caratteri "<", ">" e "&") ...

  ]]>

  </style>

  <script type="text/javascript">

  <![CDATA[

  ... contenuto dello script

  (possono comparire caratteri "<", ">" e "&") ...

  ]]>

  </script>

• Non sono possibili esclusioni SGML. Mentre le DTD di HTML consentono di dichiarare l’esclusione di uno o più elementi dal contenuto di qualsiasi elemento, ciò non è possibile nelle DTD conformi alle regole di XML. Le DTD di HTML possono sancire, per esempio, il divieto di annidare elementi A all’interno di un altro elemento A. Tale divieto, al contrario, non può essere inserito nelle DTD di XHTML. Ciò significa che, in XHTML, la presenza di un elemento A all’interno di un altro elemento A non sarà evidenziata come errore dall’analisi automatica della DTD. Ciò non vuol dire che sia lecito in XHTML annidare A all’interno di A, LABEL all’interno di LABEL o FORM all’interno di FORM. Queste e altre proibizioni sono esplicitamente definite in un’apposita sezione delle Specifiche XHTML 1.0 .
• Gli attributi id e name obbediscono a regole diverse rispetto a HTML. In XML, e quindi in XHTML, l’attributo id svolge la funzione di identificatore di frammento. Il suo valore va utilizzato cioè, tra le altre cose, come destinazione nei collegamenti ipertestuali interni al documento. Questa funzione in HTML è svolta invece dall’attributo name. Inoltre, mentre in HTML l’attributo name ha valori di tipo CDATA, in XHTML i suoi valori sono stati cambiati nel tipo NMTOKEN. In altre parole, la gamma dei suoi valori è stata resa identica a quella dell’attributo id, il che fa sì che, mentre in HTML il valore di un attributo name possa cominciare, per esempio, con un numero o con un trattino, ciò in XHTML sia illegale (i valori di name consentiti in XHTML corrispondono a quelli definiti dalla seguente regular expression: [A-Za-z][A-Za-z0-9:_.-]*). La conversione automatica da HTML a XHTML può, dunque, produrre facilmente un codice non valido, se non si ha cura, a conversione ultimata, di controllare la corrispondenza dei valori di name alle regole di XHTML. Infine, va segnalato che l’attributo name è deprecato in XHTML 1.0 ed è stato addirittura rimosso in XHTML 1.1, dove è possibile usare esclusivamente id.
• I valori dei cosiddetti enumerated attributes devono essere scritti in caratteri minuscoli. Alcuni attributi, come per esempio type, hanno una gamma di valori limitata e predefinita e sono chiamati, in SGML e XML, enumerated attributes. Mentre in HTML i valori di questi attributi possono comparire indifferentemente in lettere maiuscole o minuscole, in XML non sarebbe la stessa cosa. Perciò è stato stabilito che, in XHTML, essi debbano essere scritti sempre in caratteri minuscoli. Dunque, in HTML è del tutto lecito scrivere <input type="TEXT" [...]. In XHTML, invece, è un errore e la forma corretta è <input type="text" [...].
• I riferimenti a caratteri con valori esadecimali devono avere la “x” minuscola. Mentre in HTML è possibile avere un riferimento esadecimale a caratteri della forma &#Xnn; (dove nn sono valori esadecimali), in XHTML la forma legale è &#xnn. Se, per esempio, vogliamo ottenere sulla pagina web il simbolo della moneta giapponese yen (¥), in HTML è possibile scrivere il riferimento nella forma ¥. In XHTML dobbiamo cambiarlo, invece, in ¥.
• La lingua deve essere specificata per mezzo dell’attributo xml:lang. In HTML la lingua di un frammento o dell’intero documento è specificata tramite l’attributo lang. Per esempio, <p lang="it"> è usato per marcare un paragrafo scritto in italiano. In XHTML, invece, va usato al suo posto l’attributo xml:lang. Esempio: <p xml:lang="it">.
• Tutti gli elementi devono essere dichiarati esplicitamente. In HTML è del tutto lecito omettere gli elementi strutturali di più alto livello (HTML, HEAD, BODY). Ciò non è possibile, invece, in XHTML: un documento non è valido se non contiene un elemento HTML, un elemento HEAD e un elemento BODY. Inoltre, se in un documento HTML è contenuta una tabella, è possibile omettere dal codice di marcatura l’elemento TBODY, ma questo risulterà ugualmente presente nel DOM e modificabile tramite script e fogli di stile. Qualsiasi elemento si ometta, invece, nel codice di marcatura di un documento XHTML, sarà assente anche dal DOM.
• L’elemento HTML ha un attributo xmlns. XML usa il meccanismo dello spazio dei nomi (namespaces), come strumento per fornire ai programmi utente un riferimento univoco all’elenco degli elementi e degli attributi validi per qualsiasi documento o frammento di codice, che sia scritto in un linguaggio di marcatura basato su XML. In XHTML, questo riferimento viene fornito nel valore dell’attributo xmlns dell’elemento HTML. Tale valore è fisso e corrisponde all’URI http://www.w3.org/1999/xhtml. In HTML non esiste un attributo xmlns.

  [Inizio approfondimento] Cosa sono le regular expression

  Le regular expression, o espressioni regolari, sono formule che definiscono, in base a precise regole, insiemi di stringhe di caratteri. Per esempio, la formula (man(o|i))+, usata per analizzare un testo, ritorna un valore positivo se nel testo sono presenti una o più occorrenze delle parole “mano” o “mani”. Le espressioni regolari sono molto usate in ambito informatico: sono infatti potenti strumenti per definire quali stringhe sono lecite e quali no in un determinato contesto (per esempio, come valori di un attributo in un linguaggio di marcatura) e, soprattutto, per effettuare operazioni globali di ricerca e sostituzione all’interno di testi. Per chi desidera saperne di più, all’indirizzo http://www.regular-expressions.info/ troverà un intero sito web dedicato alle espressioni regolari, ricco di esempi e di informazioni (purtroppo solo in inglese). [Fine approfondimento]

• La codifica dei caratteri va specificata nella dichiarazione XML. Se in un documento XML si vuole dichiarare esplicitamente la codifica dei caratteri utilizzata nel codice di marcatura, il luogo per farlo è la dichiarazione di codifica (encoding declaration), all’interno della dichiarazione XML. Per esempio: <?xml version="1.0" encoding="EUC-JP"?>. È lecito omettere la dichiarazione XML, ma in tal caso i browser dovrebbero assumere implicitamente che la codifica dei caratteri di un documento XHTML sprovvisto di dichiarazione XML è UTF-8 o UTF-16. In HTML, invece, il luogo per dichiarare all’interno del documento la codifica dei caratteri utilizzata è l’elemento META. Per esempio: <meta http-equiv="Content-type" content="text/html; charset=EUC-JP">. Naturalmente è possibile usare META, con intento analogo, anche in un documento XHTML, ma un programma utente conforme dovrebbe dare la precedenza alla codifica definita nella dichiarazione XML.
• Il modello di contenuto per alcuni elementi e attributi è differente. Esistono sottili differenze tra HTML e XHTML, che dipendono dai modelli di contenuto per elementi e attributi, stabiliti dalle rispettive DTD. Il Listato 16.3 mostra a titolo di esempio le differenti definizioni dell’elemento BODY.

  Listato 16.3. Definizioni di BODY nelle DTD strict di HTML 4.01 (A) e di XHTML 1.0 (B).

  A. <!ELEMENT BODY O O (%block;SCRIPT)+ +(INS|DEL) -- document body -->|

  B. <!ELEMENT body %Block;>

  [Inizio approfondimento] L’importanza di sapere leggere una DTD

  Imparando a capire i riscontri dei validatori automatici, è possibile evitare molti errori di validazione. Tuttavia, uno sviluppatore professionista dovrebbe saper leggere una DTD e capire direttamente cosa è lecito e cosa è proibito, prima ancora di ricavarlo da un messaggio d’errore. A tal fine, consigliamo di leggere e studiare la breve guida alle regole di SGML per interpretare la DTD di HTML, contenuta nel Capitolo 3 delle Specifiche HTML 4.01 (3.3 How to read the HTML DTD ). Segnaliamo anche una guida di Mark Allen del 2001, completa e sintetica allo stesso tempo (Document Type Definition ). [Fine approfondimento]

• Le regole di stile sono referenziate da una dichiarazione di stile. In HTML, è possibile associare stili al codice di marcatura caricandoli da un file esterno per mezzo dell’elemento LINK o incorporandoli nel documento tramite l’elemento STYLE. In XHTML possono essere usati entrambi gli elementi, ma c’è una differenza. Poiché XHTML segue le regole di XML, se viene usato l’elemento STYLE, occorre impostare al suo interno l’attributo id e usarlo come ancora per una dichiarazione di stile XML, contenuta in un’istruzione di processo. Il procedimento è mostrato nel Listato 16.4, che adatta all’italiano un esempio contenuto nelle Specifiche XHTML 1.0 (le parti significative sono evidenziate in grassetto).

  Listato 16.4. Dichiarazione di stile che rimanda all’elemento STYLE in XHTML

  <?xml-stylesheet href="http://www.w3.org/styles.css" type="text/css"?>

  <?xml-stylesheet href="#stileInterno" type="text/css"?>

  <!DOCTYPE html

  PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="it" lang="it">

  <head>

  <title>Un esempio di foglio di stile interno</title>

  <style type="text/css" id="stileInterno">

  code {

  color: green;

  font-family: monospace;

  font-weight: bold;

  }

  </style>

  </head>

  <body>

  <p>

  Questo testo usa il nostro

  <code>foglio di stile interno</code>.

  </p>

  </body>

  </html>

Inizio pagina

Questioni di compatibilità nell’uso di XHTML

La corposa serie di differenze elencate nel paragrafo precedente non basta a dare risposta a un quesito importante, che è ancora in sospeso: quand’è che un documento web è trattato da un browser come XHTML e non come HTML? Basta forse mettere la dichiarazione XML all’inizio del documento? Oppure diventa XHTML solo quando ci ricordiamo di chiudere tutti gli elementi vuoti con l’apposita barra di chiusura ("/>")? O, forse, il fattore determinante è dichiarare una DTD XHTML e ottenere dal validatore automatico del W3C il bollino che attesta zero errori di codifica?

Purtroppo per chi crede che sia solo una questione di codice di marcatura, nessuna delle caratteristiche precedenti è sufficiente. L’unico e solo fattore che impone a un programma utente di trattare come XML, e non più come HTML, un documento scritto in XHTML è servirlo con il tipo MIME appropriato per questo linguaggio di marcatura, che è application/xhtml+xml.

L’associazione tra questo tipo di media e i documenti codificati in XHTML è stabilita nella sezione 5.1 Internet Media Type delle Specifiche XHTML 1.0, che rimanda, per ulteriori chiarimenti, a una Nota W3C datata 1° agosto 2002 e intitolata XHTML Media Types .

Suggeriamo di leggere con attenzione questa Nota del W3C, perché chiarisce le questioni più importanti circa il modo corretto di servire documenti XHTML. Ne riportiamo di seguito, in traduzione italiana, uno dei passaggi principali:

Il tipo di media application/xhtml+xml è il tipo di media per i tipi di documento della Famiglia XHTML. I tipi di documento appropriati per questo tipo di media includono XHTML 1.0, XHTML Basic, XHTML 1.1 e XHTML + MathML. […] application/xhtml+xml dovrebbe [should] essere usato per servire documenti XHTML ai programmi utente per XHTML. Gli autori che desiderano supportare sia i programmi utente per XHTML sia quelli per HTML possono [may] utilizzare la negoziazione del contenuto, in modo da servire documenti HTML come text/html e documenti XHTML come application/xhtml+xml. Si noti, inoltre, che non è necessario che i documenti serviti come application/xhtml+xml seguano le linee guida per la compatibilità con HTML.

Questa spiegazione ci fa capire che la stragrande maggioranza dei documenti web che sono scritti oggi in XHTML non sono in realtà trattati dai browser secondo le regole di XML, ma secondo quelle di HTML. Ciò perché vengono serviti come text/html invece che come application/xhtml+xml. Una tale scelta vanifica irrimediabilmente tutto il lavoro di adeguamento del codice di marcatura, necessario per rispettare le numerose specificità di XHTML elencate nel paragrafo precedente.

Per intenderci, elaborare un perfetto codice XHTML e poi servirlo come text/html è un po’ come cucinare con il massimo scrupolo un raffinato piatto francese, fermarsi soddisfatti a rimirare la perfezione del risultato ottenuto (una validazione a zero errori...), e poi, proprio un attimo prima di servire in tavola, afferrare una confezione famiglia di maionese e svuotarne tutto il contenuto sulla pietanza, rimestando col cucchiaio fino a trasformare il frutto di tanto lavoro in una poltiglia. Non sarebbe esagerato definire autolesionistico un comportamento del genere.

La questione, però, non è così semplice come potrebbe sembrare. Non si tratta solo di cambiare in application/xhtml+xml il tipo di media dei documenti scritti in XHTML e farla finita lì. Prima di decidere il tipo di media con cui servire le proprie pagine web, vanno infatti considerati due fattori della massima importanza: la questione della compatibilità e quella della manutenibilità.

Quando si servono pagine web con il tipo di contenuto application/xhtml+xml, per questo stesso fatto si escludono automaticamente dalla fruizione di quelle pagine tutti coloro che usano programmi utente che non supportano quel MIME type. Poiché tra i programmi utente privi di supporto per il tipo di media application/xhtml+xml vi sono, non solo i browser testuali Links e Lynx, non solo il terrificante Netscape della serie 4, ma anche Internet Explorer in tutte le sue versioni (cioè il browser tuttora più usato), il problema della compatibilità assume importanza centrale.

Poiché è tra le richieste dell’accessibilità quella di ricercare la massima compatibilità con i programmi utente esistenti (si veda in proposito il Capitolo 15), non è consigliabile, allo stato attuale, pubblicare documenti e siti web servendoli esclusivamente come application/xhtml+xml, a meno che questo non sia l’unico tipo di media possibile in ragione dei contenuti da pubblicare.

Sotto il profilo della compatibilità, il tipo di media text/html è una scelta di gran lunga migliore. I contenuti serviti come text/html sono riproducibili, infatti, sia pure con differenze, da tutti i browser noti, a partire da quelli in uso nei primi anni Novanta del secolo scorso fino a quelli contemporanei.

La seconda questione, poi, quella della manutenibilità, è, per chi produce siti web complessi, altrettanto importante quanto quella della compatibilità.

Servire un documento come application/xhtml+xml significa imporre ai browser di trattarlo come XML. Ciò comporta una differenza fondamentale, rispetto a qualsiasi documento servito come text/html: il blocco totale della riproduzione da parte del browser, se il codice di marcatura contiene violazioni delle regole di XML.

Per bloccare la riproduzione di un documento servito come application/xhtml+xml in un browser conforme bastano errori molto comuni: per esempio, dimenticare un marcatore di chiusura di un elemento, inserire un attributo booleano in forma compatta invece che estesa (selected al posto di selected="selected"), dimenticare di racchiudere tra apici il valore di un attributo (Figura 16.2), usare entità non definite nella DTD, usare il carattere “&” nel suo senso proprio di congiunzione tra nomi commerciali invece che come l’inizio di un’entità o di un riferimento a caratteri.

Dati questi vincoli molto stringenti, servire i documenti con il tipo application/xhtml+xml in un ambiente di produzione complesso rappresenta un forte rischio gestionale: occorre, infatti, disporre di un flusso di lavoro molto ben organizzato e di software potenti, in grado di monitorare continuamente la correttezza del codice in tutte le pagine pubblicate e soggette a modifiche, se si vuole scongiurare il rischio che anche un semplice errore di digitazione di un collaboratore blocchi una pagina o addirittura un intero sito.

Tutto sommato, ci sono più che valide ragioni per continuare a servire i propri documenti web con il tipo di media text/html. Ma quali soluzioni abbiamo a disposizione, se non vogliamo rinunciare del tutto a produrre codice XHTML e vogliamo conservare, allo stesso tempo, la compatibilità all’indietro? Le strade possibili sono due:

1. ripiegare su un codice XHTML 1.0 ibrido, basato cioè sulle linee guida per la compatibilità con HTML, definite nell’Appendice C delle Specifiche XHTML 1.0, e poi usare la negoziazione del contenuto, in modo da servire ai browser conformi a XHTML documenti con il tipo di media application/xhtml+xml e ai browser non conformi gli stessi documenti, ma con il tipo di media text/html;
2. codificare ogni documento due volte, la prima come HTML puro e la seconda come XHTML puro (1.0 o 1.1), servendo ai browser privi di supporto per XHTML la versione HTML come text/html e ai browser conformi la versione XHTML come application/xhtml+xml.

La soluzione più pulita è certamente la seconda, ma è anche la più faticosa, perché richiede di scrivere due versioni distinte e differenti di ciascun documento. Tuttavia, la prima soluzione, a ben guardare, non è molto più semplice. Scrivere, infatti, il codice ibrido richiesto per la compatibilità con HTML obbliga gli sviluppatori a tener conto, per ogni documento pubblicato, di ben sedici requisiti, che impongono ulteriori limitazioni, rispetto a quelle già imposte dalla conformità a XHTML. Li elenchiamo di seguito, nell’ordine in cui sono riportati nell’Appendice C (HTML Compatibility Guidelines ) delle Specifiche XHTML 1.0.

1. Istruzioni di processo. Evitare le istruzioni di processo per l’applicazione [processing instructions], tra cui la dichiarazione XML (per esempio: <?xml version="1.0" encoding="UTF-8" standalone= "yes"?>), se si vogliono evitare problemi di compatibilità con alcuni browser. Eliminare la dichiarazione XML vincola, però, la codifica dei caratteri ai soli sistemi UTF-8 e UTF-16, quando il documento è servito come application/xhtml+xml.
2. Chiusura di elementi vuoti. Includere uno spazio prima della barra di chiusura degli elementi vuoti (per esempio: <br />) ed evitare la forma estesa con il marcatore di chiusura (per esempio: <br></br>).
3. Chiusura di elementi senza contenuto, ma non vuoti. Evitare la forma minimizzata di chiusura degli elementi privi di contenuto, quando non fanno parte di quelli classificati come EMPTY (vuoti) dalla DTD. Per esempio, usare <p> </p>, invece che <p/>, come sarebbe anche possibile in XML.

   [Inizio approfondimento] Tecniche per la negoziazione del contenuto relative al MIME type

   Per informazioni su come impostare la negoziazione del contenuto, in modo da servire tipi di media differenti a seconda del browser, si veda la breve guida di Dominique Hazaël-Massieux, intitolata Content-Negotiation Techniques to serve XHTML 1.0 as text/html and application/xhtml+xml . Un altro riferimento utile su questo argomento è Content Negotiation: Setting The Media Type For Web Pages . [Fine approfondimento]

4. File esterni per script e fogli di stile. Ricorrere a file esterni per script e fogli di stile, se script e fogli di stile contengono i caratteri <, &, ]]> o --. I processori XML possono rimuovere i contenuti dei commenti, per cui la pratica di nascondere script e regole di stile all’interno di commenti HTML (<!-- [...] -->) per ragioni di compatibilità all’indietro, non è più utilizzabile in XHTML servito come XML.
5. Spazi nei valori di attributo. Evitare interruzioni di riga e caratteri spazio bianco multipli nei valori di attributo.
6. Elementi ISINDEX. Non includere più di un elemento ISINDEX nella sezione HEAD del documento.
7. Definizione della lingua. Usare sia l’attributo lang sia l’attributo xml:lang, per specificare la lingua del documento o di un elemento.
8. Uso di id e name. Usare insieme gli attributi id e name, con lo stesso valore, quando id è utilizzato come ancora per la destinazione di un collegamento. Modificare, se è il caso, i valori di name in modo da rispettare il tipo di contenuto NMTOKEN (al posto di CDATA), previsto per questo attributo dalle Specifiche XHTML.
9. Codifica dei caratteri. Fornire la codifica dei caratteri del documento tramite le intestazioni HTTP del server, se si vogliono evitare conflitti dovuti alla necessità di usare la dichiarazione XML (che è il modo legale di dichiarare la codifica dei caratteri nei documenti XHTML serviti come XML), qualora questa sia diversa da UTF-8.
10. Attributi booleani. Alcuni programmi utente datati sono incapaci di interpretare la forma estesa degli attributi booleani, richiesta dalla sintassi di XHTML (riguarda gli attributi compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer).
11. Gestione differente del DOM. A seconda che il documento sia servito come text/html o come application/xhtml+xml, cambia il modo in cui possono essere manipolati i contenuti via DOM. Nel DOM di HTML, attributi ed elementi sono restituiti in lettere maiuscole; nel DOM di XHTML servito come XML sono restituiti, invece, in lettere minuscole. Inoltre, elementi che possono essere impliciti nel codice di marcatura ma che esistono ugualmente nel DOM di HTML (come TBODY), non esistono nel DOM di XML, se non sono dichiarati esplicitamente nel codice di marcatura. Un’altra differenza che ha a che fare con XML e il DOM è l’impossibilità di usare l’istruzione document.write(), all’interno di script associati a un documento XHTML servito come application/xhtml+xml. Le regole di XML non permettono che il codice sia modificato dinamicamente, come potrebbe essere fatto dall’istruzione document.write(), se il processore XML del browser non ha ancora finito di analizzare il codice. Per tale ragione, l’istruzione document.write() non funziona in XML e, per generare dinamicamente nuovo codice di marcatura nel documento, è necessario ricorrere a istruzioni che agiscono sul DOM.
12. Carattere “&”. I programmi utente per HTML e per XHTML trattano in modo differente il carattere “&”, quando è usato in senso letterale e non come parte di un riferimento a caratteri. Per evitare di incorrere in errori di codice non valido, occorre trasformare tutte le occorrenze di “&”, anche quelle inserite nei valori di attributo, nell’entità equivalente &.
13. Regole di conformità dei CSS. I CSS definiscono regole di conformità diverse per i documenti HTML e per quelli XML. Quando un medesimo documento XHTML è servito sia come text/html sia come application/xhtml+xml, deve rispettare nel primo caso le regole di conformità CSS per HTML, nel secondo caso quelle per XML. Per maggiori informazioni sull’uso degli stili nei documenti XML, si veda la guida di Bert Bos, How to add style to XML , sul sito del W3C
14. Stili interni al documento. La definizione di stili interni al documento tramite l’elemento STYLE richiede l’uso, in XHTML servito come XML, di un’istruzione di processo per referenziare gli stili interni (si veda il Listato 16.4). Ciò crea incompatibilità con il requisito 1 di questo elenco.
15. Caratteri illegali. Alcuni caratteri che sono legali in HTML sono illegali in XML, per esempio il carattere spazio bianco di avanzamento modulo (formfeed) U+000C. Non dovrebbero perciò essere utilizzati in XHTML.
16. L’entità '. L’entità ' per il segno di apostrofo, introdotta con XML, non esiste in HTML. Per compatibilità, occorre dunque utilizzare il riferimento numerico allo stesso carattere, che è '.

Inizio pagina

Pro e contro nell’uso di XHTML

Finora abbiamo elencato solo differenze tra HTML e XHTML, problemi di compatibilità e limitazioni. È lecito, allora, chiedersi: c’è qualche vantaggio, in particolar modo per l’accessibilità, a scrivere codice XHTML o è unicamente una fonte di problemi e una perdita di tempo? La risposta non può essere secca, sì o no, ma richiede di considerare i vari casi possibili.

Primo caso: il codice XHTML, elaborato secondo le linee guida per la compatibilità con HTML, viene servito esclusivamente come text/html, per garantire la compatibilità all’indietro. Non c’è il benché minimo vantaggio in una simile scelta. Il documento, per quanto ben formato e privo di errori, viene trattato come “minestrone di marcatori” (tag soup) da tutti i browser. Dal punto di vista dell’accessibilità, se la scelta è servire le pagine come text/html, è preferibile scrivere codice HTML 4.01, in modo da evitare ogni rischio di incompatibilità, dovuto all’uso di browser datati da parte degli utenti.

Secondo caso: il codice XHTML, scritto seguendo le regole di compatibilità con HTML, viene servito come application/xhtml+xml ai browser che accettano questo tipo di media e come text/html a tutti gli altri. Anche in questa scelta non c’è il benché minimo vantaggio, né per gli utenti, che caricano esattamente gli stessi contenuti qualsiasi sia il tipo di media con cui vengono serviti, né per gli sviluppatori, che si accollano un lavoro maggiore di codifica e di programmazione. A fronte di questo lavoro in più, l’unico risultato è il rischio di veder bloccata la riproduzione del documento nei browser che accettano il tipo di media application/xhtml+xml, a causa di qualche errore veniale, che, al contrario, non produce il benché minimo effetto nella pagina servita come text/html (Figura 16.2). Se, perciò, non esiste una ragione particolare per servire le pagine anche come XML, ragione che potrebbe essere quella di consentire uno scambio automatico di dati tra dispositivi che comunicano tramite XML, la scelta più sensata è senz’altro quella di limitarsi, anche in questo caso, a scrivere codice HTML 4.01 servito come text/html.

Terzo caso: vengono prodotte due versioni del documento, una strettamente conforme a XHTML (che non segue, cioè, le regole di compatibilità con HTML), servita come application/xhtml+xml, e una conforme a HTML, servita come text/html. Al netto delle diversità di codice, i contenuti delle due versioni sono esattamente uguali. Anche in questo terzo caso non c’è nessun vantaggio ad avere due versioni di uno stesso documento. Chi usa un browser in grado di caricare la versione XHTML, non riceve, infatti, alcun beneficio rispetto a chi carica la versione HTML, né dal punto di vista informativo né da quello delle prestazioni. Anzi, dal punto di vista delle prestazioni è penalizzato, perché la maggior parte dei browser che accettano il tipo di media application/xhtml+xml è basata sul motore Gecko, che non supporta, per il momento, il caricamento incrementale dei documenti XHTML (il problema sarà risolto solo con la futura versione 1.9 di Gecko). Ciò vuol dire che un documento XHTML lungo rimane invisibile finché non è stato caricato completamente, mentre, se servito come HTML, la visualizzazione comincia subito, non appena al browser arrivano i primi dati. Anche stavolta, a meno che non vi siano ragioni di interoperabilità che richiedono la presenza di una versione servita come XML, la soluzione più semplice e produttiva, anche in termini di comodità di accesso, è quella di realizzare un’unica versione del documento, scritta in HTML 4.01 e servita come text/html.

Quarto caso: il documento viene scritto in XHTML puro e servito esclusivamente come application/xhtml+xml. Una tale scelta taglia fuori dalla fruizione del documento tutti i programmi utente che non accettano questo tipo di media. È perciò una scelta penalizzante per l’accessibilità in senso lato, perché non garantisce compatibilità all’indietro, ma può essere, in determinate circostanze, la scelta giusta e, anzi, l’unica possibile.

Quand’è che XHTML è la scelta giusta? Quando lo utilizziamo per ciò che realmente è: un linguaggio di marcatura estensibile e modulare, basato su XML; e quando lo utilizziamo per ciò a cui realmente serve:

• per fornire un ambiente ospite, al quale agganciare contenuti per il Web scritti in altri linguaggi di marcatura basati su XML (per esempio, MathML, SVG, SSML ecc.);
• per scomporre, ricomporre ed estendere i moduli che ne fanno parte, a seconda delle capacità di supporto e riproduzione del dispositivo a cui i contenuti XHTML sono destinati;
• per fornire uno strumento solido, basato su regole rigorose, in grado di garantire una affidabile interoperabilità tra linguaggi e dispositivi.

Al di fuori di questi usi, il ricorso a XHTML è inutile, se non addirittura dannoso. Scrivere codice XHTML per servirlo come text/html è un esercizio di tecnica fine a se stesso, privo di necessità e di utilità (al di fuori dell’esecuzione dell’esercizio stesso).

Inizio pagina

Un esempio di uso appropriato di XHTML

Per capire quando l’uso di XHTML è appropriato, non c’è nulla di meglio di un esempio concreto.

Poniamo di aver bisogno di realizzare un sito web contenente lezioni di matematica per una data classe di studenti. Vogliamo che tutta la simbologia matematica utilizzata nelle pagine sia accessibile. A tal fine, abbiamo bisogno di evitare l’uso di formule in forma di immagine, sostituendole con una notazione matematica in forma testuale, accessibile agli screen reader e, allo stesso tempo, dotata della necessaria formattazione grafica. Lo strumento per realizzare il nostro scopo esiste ed è MathML (si veda in proposito il commento al punto di controllo 3.1 nel Capitolo 6).

MathML è un linguaggio di marcatura basato su XML, che può essere incorporato all’interno di codice XHTML servito come XML. Sul sito del W3C è disponibile una DTD costruita appositamente per saldare XHTML 1.1 e MathML 2.0, in modo tale che un programma utente conforme possa trovare in un unico file tutte le informazioni necessarie a rappresentare correttamente documenti contenenti sia codice XHTML sia codice MathML.

Il linguaggio così creato, chiamato XHTML 1.1 plus MathML 2.0, è un esempio della capacità specifica di XHTML di essere modulare, cioè di avere un meccanismo standardizzato per aggiungere, eliminare o estendere blocchi di elementi e attributi, in modo da sviluppare solo ed esclusivamente le funzionalità che occorrono per il raggiungimento di un determinato fine (nel caso specifico, la capacità di riprodurre espressioni matematiche complesse, in aggiunta alle funzioni native di XHTML).

Nel Listato 16.5 abbiamo utilizzato la DTD di XHTML 1.1 plus MathML 2.0 per realizzare un documento minimale, contenente un paragrafo di testo e la formula per la soluzione delle equazioni di secondo grado. Quanto basta, tuttavia, per dimostrare la necessità di usare XHTML al posto di HTML, se si vuole ottenere un’estensione o una riconfigurazione delle capacità native del linguaggio di marcatura, capacità che in partenza sono le medesime per XHTML e per HTML, con la differenza che quelle di HTML sono fissate una volta per tutte nelle sue DTD, mentre quelle di XHTML sono estensibili e riconfigurabili.

La Figura 16.3 mostra la rappresentazione corretta del codice di marcatura nel Listato 16.5, generata con Firefox 2.0 (il documento è servito come application/xhtml+xml).

Se serviamo il medesimo codice con il tipo di media text/html, il risultato è quello mostrato in Figura 16.4.

Inizio pagina

Interoperabilità e semplicità d’implementazione

Possiamo finalmente ritornare alla domanda iniziale di questa sezione dedicata ai rapporti tra HTML e XHTML: per gli scopi dell’accessibilità, è meglio usare HTML o XHTML?

La risposta è che, in tutti i casi in cui i contenuti sono rappresentabili semanticamente in modo sufficiente per mezzo degli elementi e degli attributi di HTML 4.01, allora la scelta migliore è senz’altro HTML 4.01. Ciò garantisce la massima compatibilità all’indietro ed elimina il rischio di veder bloccata la riproduzione delle pagine nei browser conformi a XML, a causa di eventuale codice mal formato.

L’eccezione a questa raccomandazione è costituita dai casi in cui è necessario garantire interoperabilità tra dispositivi che dialogano per mezzo di XML e quando è necessario ridurre la quantità di elementi e attributi supportati, a causa delle ridotte capacità dei programmi utente di destinazione. Un esempio tipico sono i linguaggi di marcatura destinati a cellulari, palmari e altri dispositivi a schermo piccolo o a bassa risoluzione. Tra i vari, possiamo citare XHTML Mobile Profile , che viene così presentato nel paragrafo 1 del documento che lo descrive:

Queste specifiche definiscono un tipo di documento XHTML, basato su infrastruttura modulare e sui moduli definiti da Modularization of XHTML. Questo tipo di documento è chiamato XHTML Mobile Profile ed è progettato per Web client con vincoli di risorse, che non supportano l’insieme completo di caratteristiche di XHTML, come cellulari, PDA, dispositivi a caratteri e apparati per Web TV. Esso estende XHTML Basic con moduli, elementi e attributi, per fornire un linguaggio autoriale più ricco.

Nel paragrafo 7.2 delle Specifiche XHTML Mobile Profile si definiscono i tipi di media che un programma utente conforme deve, o dovrebbe, accettare:

Il tipo di media MIME per XHTML Mobile Profile è application/vnd.wap.xhtml+xml. Un programma utente conforme DEVE accettare documenti XHTML Mobile Profile identificati come application/vnd.wap.xhtml+xml. Un programma utente conforme DOVREBBE accettare documenti XHTML Mobile Profile identificati come application/xhtml+xml.

Si noti che non c’è l’obbligo di dare ai documenti XHTML Mobile Profile il tipo di media application/vnd.wap.xhtml+xml; può essere usato anche il tipo di media text/html. Dal momento che non esistono regole di conformità per i documenti con il tipo text/html, non c’è un modo semplice di determinare quali documenti di tipo text/html sono documenti XHTML Mobile Profile, eccetto che i documenti possono includere la dichiarazione DOCTYPE specificata nella sezione 7.1. Un programma utente conforme DOVREBBE accettare anche documenti XHTML Mobile Profile identificati con il tipo text/html.

L’ultima parte del brano citato è particolarmente interessante: ci aiuta a capire perché un linguaggio modulare come XHTML, servito come XML, è meglio di HTML servito come text/html, se lo scopo è generare un sottoinsieme ben preciso, rigorosamente definito e riconoscibile, di elementi e attributi. I processori (parser) di codice XML sono in grado, infatti, di determinare esattamente se un documento rispetta la DTD dichiarata oppure no; anzi, è loro preciso compito svolgere questo accertamento e bloccare la rappresentazione del documento, se riscontrano errori.

Nel caso, invece, di documenti serviti come text/html, il browser si trova ad affrontare un compito ingrato e molto più complesso: ha solo il riferimento della dichiarazione del DOCTYPE – e spesso neppure quello – per inferire le caratteristiche del documento che deve rappresentare. Inoltre, non può bloccare legalmente la rappresentazione delle pagine in presenza di errori di codifica; deve fare, anzi, del proprio meglio per “indovinare” l’intenzione degli autori, cercando di compensare i loro errori. A tal proposito, è utile leggere cosa scrivono Dan Connolly e Larry Masinter, a pag. 2 della RFC 2854, intitolata The ‘text/html’ Media Type , un documento ufficiale pubblicato nel giugno 2000 su richiesta dello HTML Working Group del W3C, per spiegare le caratteristiche del tipo di media text/html:

A causa dello sviluppo lungo e distribuito di HTML, la pratica corrente in Internet include un’ampia varietà di varianti di HTML. Gli implementatori di interpreti text/html devono essere preparati a essere “baco-compatibili” [bug-compatible] con i browser popolari, al fine di mantenere leggibili molti dei documenti reperibili su Internet.

Tipicamente, versioni differenti sono distinguibili dalla dichiarazione DOCTYPE contenuta al loro interno, benché la stessa dichiarazione DOCTYPE sia talvolta omessa o sbagliata.

Insomma, il tipo di media text/html, associato al linguaggio HTML, è consacrato a un modo “rilassato” di scrivere codice di marcatura. Scarica sul programma utente l’onere di tentare la rappresentazione dei documenti, anche in presenza dei più micidiali “minestroni di marcatori” (tag soup), prodotti da autori sbadati o incompetenti.

Il grande merito di questo metodo permissivo è sotto gli occhi di tutti: anche grazie alla tolleranza agli errori da parte dei browser, il Web è diventato nel giro di poco più di quindici anni un gigantesco fenomeno mondiale, affollato da molti milioni di siti e da svariati miliardi di documenti serviti come text/html, la stragrande maggioranza dei quali fallisce la validazione del codice, per la presenza di errori di ogni tipo. La cultura, l’informazione e l’intrattenimento vengono diffusi ugualmente in Rete nonostante gli errori di codifica da parte degli autori, solo grazie al lavoro automatico di compensazione degli errori, svolto dietro le quinte dai browser per HTML.

Se fin dall’inizio fosse stato richiesto il blocco della rappresentazione dei documenti HTML in presenza di errori di codifica, così come avviene per i documenti XML, molto difficilmente il Web sarebbe diventato un fenomeno di massa (a meno che, fin dall’inizio, non fossero stati resi disponibili al largo pubblico – cosa che non è mai accaduta – strumenti autoriali visuali in grado di correggere automaticamente gli errori di codifica dietro le quinte, consentendo agli autori di produrre pagine web in modo intuitivo, senza doversi preoccupare delle questioni legate alla correttezza del codice). Ben pochi autori, infatti, dispongono delle competenze professionali per scrivere codice a zero errori. Schiere sterminate di amatori, invece, usando programmi autoriali visuali, hanno prodotto – e continuano a produrre – schiere ancor più sterminate di pagine HTML dal codice improbabile, felicemente indifferenti alle dispute sulla correttezza formale dei documenti, che animano da anni i forum e le liste di bellicose élites di sviluppatori professionisti.

Se questo è il merito di HTML e del tipo di media text/html, è anche il suo tallone d’Achille. L’interoperabilità, cioè la capacità di garantire risultati certi nello scambio di dati tra computer, è infatti impossibile, o comunque fortemente ridotta, se non vi è un uso uniforme dei linguaggi di marcatura e se le loro regole non sono rispettate. L’interoperabilità richiede il rispetto di condizioni rigide e minutamente standardizzate, non l’arbitrio e il caos tipici dei “minestroni di marcatori”.

Inoltre, minori sono le risorse a disposizione e più diventa importante che le regole siano chiare e rispettate. Ecco perché XHTML Mobile Profile nasce come applicazione XML, e richiede ai programmi utente conformi di accettare come tipo di media canonico application/vnd.wap.xhtml+xml (“deve” è la parola chiave usata) e non text/html (per il quale la parola chiave è “dovrebbe”). Nei pochi kilobyte in cui deve essere condensato tutto il codice di un browser per dispositivi mobili, è molto più semplice, infatti, inserire il codice di programmazione per controllare la correttezza formale di un sottoinsieme ridotto di elementi e attributi di XHTML, piuttosto che l’elefantiaco codice che serve per gestire l’intero HTML (linguaggio non modulare), e in più per correggere gli eventuali errori di codifica degli autori, nel rispetto di quella compatibilità con l’esistente, richiesta ufficialmente dalla RFC 2854.

Inizio pagina

I quattro fattori che determinano la scelta del linguaggio

Per concludere il discorso, chi sviluppa siti accessibili, trovandosi di fronte alla scelta del linguaggio di marcatura da utilizzare, deve chiedersi essenzialmente quattro cose:

1. quali sono i contenuti da pubblicare;
2. chi sono i destinatari del sito;
3. che tipo di programmi utente utilizzeranno;
4. quali risorse per lo sviluppo si hanno a disposizione.

I contenuti sono il primo fattore discriminante. Se un sito è dedicato alla matematica, allora la scelta dovrebbe cadere inevitabilmente su XHTML, in modo da poter fornire un aggancio standardizzato per MathML. Lo stesso vale per qualsiasi tipo di contenuto che può essere espresso soltanto usando un linguaggio di marcatura basato su XML (SVG, SMIL, SSML e vari altri): se tali contenuti devono essere incorporati in una pagina web, allora la scelta di XHTML è l’unica possibile.

I destinatari sono il secondo elemento discriminante. Se un sito si rivolge in generale a tutti i cittadini, allora il linguaggio di marcatura usato dovrebbe essere quello che garantisce la massima compatibilità con i programmi utente esistenti, consentendo allo stesso tempo di conservare la semantica dell’informazione e un livello accettabile di struttura. HTML 4.01 è perciò, in questo caso, di gran lunga la scelta migliore. Prendiamo il caso del sito web di un Comune. Di certo i suoi contenuti potrebbero essere formalizzati e strutturati meglio, e sarebbero più interoperabili, se fossero codificati in XML. Tuttavia, un sito comunale in XML raggiungerebbe un pubblico sicuramente meno ampio di quello raggiungibile da un sito in HTML. Tale considerazione non può non influire sulla scelta del linguaggio di marcatura, quando è in gioco l’accesso a un servizio pubblico.

I programmi utente a cui siti e pagine web sono destinati sono il terzo fattore discriminante. Se si sta lavorando a un insieme di contenuti destinati esclusivamente a browser per dispositivi mobili di ultima generazione, allora i sottoinsiemi di XHTML come XHTML Mobile Profile sono una scelta migliore di HTML. Analogamente, se si sta lavorando al sito di una intranet, all’interno della quale è possibile intervenire per uniformare la gamma dei browser utilizzati, è possibile scegliere XHTML servito come application/xhtml+xml, sapendo che nessuno dei potenziali utenti rimarrà tagliato fuori.

Le risorse disponibili per lo sviluppo sono il quarto e ultimo fattore discriminante. Se non si ha modo di controllare adeguatamente il flusso di lavoro, e se non si dispone di software in grado di garantire che il codice pubblicato sia privo di errori fatali, allora è meglio ripiegare su HTML, anche quando scegliere XHTML sarebbe stato preferibile in base ai tre fattori precedenti. Non fare il passo più lungo della gamba è una perla di saggezza popolare che, ogni tanto, vale la pena di rispolverare.

Per quanto riguarda, infine, il tipo di media con cui servire le proprie pagine web, ci sembra che le considerazioni fin qui svolte conducano a una sola conclusione possibile: usare text/html per i documenti scritti in HTML 4.01 e application/xhtml+xml per i documenti scritti in una qualsiasi delle versioni disponibili di XHTML.

Quanto al servire uno stesso documento con tipi di media diversi a seconda del supporto del browser, speriamo che le considerazioni svolte nel paragrafo Questioni di compatibilità nell'uso di XHTML abbiano dimostrato che scrivere codice XHTML compatibile con HTML o, come alternativa, produrre due documenti distinti, uno in XHTML e uno in HTML, per uno stesso contenuto, siano inutili sprechi di risorse.

Inizio pagina

Il futuro di HTML e di XHTML

Se HTML ha permesso di creare il Web così come lo conosciamo oggi, i suoi limiti sono tuttavia ben noti da tempo. Il W3C, conoscendo tali limiti, ha puntato da anni su XML, nel tentativo di farne la piattaforma universale per lo scambio di dati tra applicazioni per il Web. Ciò ha portato a produrre un’innumerevole serie di Raccomandazioni che descrivono linguaggi di marcatura basati sulle regole di codifica di XML e sui tipi di media per XML. Tuttavia il Web navigato da computer desktop e portatili – quel luogo che ospita miliardi di documenti scritti in HTML e serviti come text/html – è rimasto sostanzialmente refrattario a intraprendere la strada del rigore formale, richiesta dalle stringenti regole di XML.

Le ragioni che impediscono il passaggio effettivo a XHTML servito con i tipi di media per XML sono varie: la perdurante mancanza di supporto per il tipo di media application/xhtml+xml da parte di Internet Explorer e di altri browser (per lo più datati); la mancanza di adeguata formazione professionale nella maggior parte di coloro che pubblicano contenuti sul Web; l’incapacità degli strumenti autoriali attualmente disponibili, soprattutto di quelli visuali, di garantire la perfetta rispondenza del codice di marcatura ai vincoli di correttezza formale richiesti da XML.

XHTML 2.0 , il linguaggio di marcatura che il W3C sta progettando da anni, giunto ormai alla ottava bozza pubblica, è ancora lontano dallo stadio di Raccomandazione. Pensato per garantire la definitiva svolta in avanti nella direzione di XML, è circondato da un notevole scetticismo: nonostante i progressi che esso promette in termini di capacità semantiche, struttura, funzionalità e accessibilità, molti temono che – così come i suoi predecessori della serie XHTML – non riuscirà a imporsi su HTML e a porre fine una volta per tutte all’era dei “minestroni di marcatori”.

Avendo ormai compreso che HTML e il tipo di media text/html non saranno facilmente abbandonati né dagli utenti né dagli autori né, soprattutto, dal mercato dei browser, il W3C ha riconsiderato negli ultimi tempi la propria strategia, decidendo di aprire un nuovo gruppo di lavoro per HTML, sotto la presidenza di Chris Wilson e Dan Connolly.

Il manifesto del gruppo spiega quali sono le finalità: “produrre revisioni incrementali delle specifiche HTML, che includono la serie di specifiche precedentemente pubblicate come XHTML versione 1. Saranno prodotte sintassi sia XML sia ‘HTML classica’”. Il gruppo si prefigge di portare il nuovo linguaggio allo stadio di Raccomandazione entro la fine del 2010. La caratteristica essenziale del futuro HTML sarà quella di essere compatibile all’indietro, ma, allo stesso tempo, utilizzabile anche come XML. L’elemento discriminante sarà il tipo di media. Quando serviti come text/html, i documenti dovranno essere trattati come HTML, quando serviti come application/xhtml+xml dovranno essere trattati, invece, come XML.

Il manifesto del gruppo di lavoro per il nuovo HTML dichiara, inoltre, l’intento di cercare attivamente la convergenza con il lavoro, in pieno svolgimento, di un altro gruppo, esterno e indipendente rispetto al W3C, anch’esso impegnato a riscrivere il linguaggio HTML per adeguarlo alle esigenze dei tempi. Si tratta del Web Hypertext Application Technology Working Group , più brevemente WHATWG, formato da alcuni tra i principali esperti nel campo dei linguaggi per il Web, tra i quali Håkon Wium Lie e Ian Hickson.

La bozza di specifiche a cui i membri del WHATWG stanno lavorando è in continua e rapidissima evoluzione. Il linguaggio ha il nome provvisorio di HTML 5, in cui il numero 5 indica l’intenzione di porsi in linea di continuità con HTML 4. Tuttavia, il documento disponibile alla pagina http://www.whatwg.org/specs/web-apps/current-work/ , aggiornato al 28 giugno 2007, racchiude in realtà due diversi linguaggi di marcatura: non solo HTML 5, ma anche XHTML 5, versione in salsa XML del nuovo HTML, destinata ad ambienti di produzione per i quali serve l’interoperabilità e il rigore formale di documenti serviti come application/xml o application/xhtml+xml.

È difficile dire, al momento, quale sarà il futuro del progetto HTML 5. Di certo, riscuote l’interesse di alcuni dei principali produttori di browser: le ultime versioni di Firefox, Opera e Safari già supportano, per esempio, il nuovo elemento CANVAS di HTML 5, che serve per includere in una pagina web oggetti grafici gestiti per mezzo di JavaScript.

Va precisato che il rinnovato interesse del W3C per HTML non significa, però, il pensionamento anticipato del progetto XHTML 2.0, che continua, nonostante tutto, il suo lento cammino verso lo stadio di Raccomandazione.

In uno scenario futuro in cui coesisteranno fianco a fianco XHTML 2.0 e il nuovo HTML, la scelta degli sviluppatori dovrà essere guidata dagli ambiti di applicazione: XHTML 2.0, con la sua semantica sofisticata e le stringenti regole di XML, si pone come strumento per le imprese e le attività che richiedono pesanti scambi di dati e massima interoperabilità. Il futuro HTML potrà essere, invece, scelto da chi ha bisogno della massima compatibilità con i programmi utente basati sul tipo di media text/html.

Inizio pagina

Punto di controllo 11.2, priorità 2

Elementi e attributi deprecati

Il riferimento è agli elementi e agli attributi di presentazione, che le Specifiche HTML 4 e XHTML 1 hanno deprecato, a vantaggio dell’uso dei fogli di stile (si veda il commento alla linea guida 3, nel Capitolo 6, per la definizione del concetto di “deprecato”).

Gli sviluppatori possono usare come riferimento ufficiale gli indici degli elementi e degli attributi posti alla fine delle Specifiche HTML 4.01, che elencano tutti gli elementi e gli attributi deprecati. La stessa informazione è reperibile anche nell’analogo indice posto alla fine del documento di Tecniche HTML per le WCAG 1.0, dove elementi e attributi deprecati sono segnalati con un asterisco.

Riportiamo di seguito, per comodità dei lettori, l’elenco completo degli elementi e degli attributi deprecati in HTML 4.01. L’elenco è valido anche per XHTML 1.0, che – come sappiamo dai paragrafi precedenti – è una riformulazione di HTML nella sintassi di XML. Gli elementi e gli attributi qui elencati fanno parte delle DTD transitional dei due linguaggi di marcatura, mentre sono esclusi dalle DTD strict (per informazioni sulle DTD, si veda il commento al punto di controllo 3.2).

Punto di controllo 11.3, priorità 3

Suggerimenti per la negoziazione del contenuto

Il punto di controllo 11.3 fa riferimento al meccanismo della negoziazione del contenuto. Le Tecniche di base per le WCAG 1.0 suggeriscono tre sistemi per soddisfare la richiesta contenuta in questo punto di controllo:

1. includere collegamenti ad altre versioni dei contenuti, per esempio a traduzioni in altre lingue;
2. specificare il tipo di contenuto o la lingua di un collegamento per mezzo del codice di marcatura (usando per esempio, in HTML, gli attributi type e hreflang);
3. usare la negoziazione automatica dei contenuti tra server e client, per fornire agli utenti un contenuto conforme alle impostazioni del client. Se, per esempio, la lingua predefinita nel browser è il francese, il server dovrebbe fornire all’utente direttamente la versione in francese del documento richiesto.

È chiaro che l’applicazione di questo punto di controllo non implica solo una questione tecnica, che anzi è la parte più banale, ma una questione editoriale: per poter fornire contenuti tarati secondo le preferenze dell’utente, è indispensabile approntare a monte una molteplicità di contenuti, in grado di soddisfare differenti categorie di utenti. Non si può cioè negoziare il contenuto con gli utenti francesi o inglesi, se prima non è stata preparata e pubblicata una traduzione in francese o in inglese di un dato documento.

Il grado in cui sia possibile venire incontro alle preferenze degli utenti dipende quindi da più fattori, non strettamente tecnici, tra i quali: il tipo di sito e il pubblico a cui si rivolge, i mezzi economici e il tempo a disposizione di autori e sviluppatori per affrontare le opportune versioni alternative di un documento.

Inizio pagina

Punto di controllo 11.4, priorità 1

Pagine alternative e siti paralleli

Il punto di controllo 11.4 delle WCAG 1.0 è accompagnato da una nota, che spiega:

Gli sviluppatori di contenuti dovrebbero ricorrere a pagine alternative soltanto quando le altre soluzioni falliscono, perché le pagine alternative sono aggiornate di solito meno spesso delle pagine “primarie”. Una pagina obsoleta può essere altrettanto frustrante di una pagina inaccessibile, dal momento che, in entrambi i casi, le informazioni presentate sulla pagina originale non sono disponibili. Pagine alternative generate automaticamente possono condurre ad aggiornamenti più frequenti, ma gli sviluppatori di contenuti devono stare attenti a garantire che le pagine generate continuino ad avere significato, e che gli utenti possano navigare un sito seguendo i link indifferentemente sulle pagine primarie, sulle pagine alternative o su entrambe. Prima di ricorrere a una pagina alternativa, si riconsideri la struttura della pagina originale; è probabile che renderla accessibile costituisca un miglioramento per tutti gli utenti.

Le Tecniche di base per le WCAG 1.0 suggeriscono due modi per collegare la pagina alternativa accessibile alla pagina da cui è derivata:

1. Posizionare un link all’inizio sia della pagina principale sia della pagina alternativa, in modo da consentire all’utente di passare dall’una all’altra a propria discrezione. Tali collegamenti devono essere tra i primi che si incontrano nella navigazione da tastiera, altrimenti c’è il rischio che l’utente non si accorga neppure della presenza di una pagina alternativa accessibile.
2. Referenziare il documento alternativo tramite metainformazioni. In tal modo i browser conformi saranno in grado di caricare direttamente la pagina alternativa, in base alle caratteristiche del browser e alle preferenze impostate dall’utente.

Il punto di controllo 11.4, con la nota sopra tradotta, ha dato la stura negli anni scorsi a interminabili discussioni tra gli sviluppatori interessati all’accessibilità, circa la questione se le WCAG 1.0 consentano oppure no la creazione di un sito parallelo, come soluzione valida per l’accessibilità.

E allora: è accettabile oppure no, dal punto di vista della conformità alle WCAG 1.0 e, in particolare, al punto di controllo 11.4, la realizzazione di un sito parallelo accessibile, fatta al costo di non curare adeguatamente (o per nulla) l’accessibilità del sito “primario”? La questione è di rilevantissima importanza, perché può incidere sui criteri di esecuzione dei contratti che prevedono il rispetto delle linee guida WCAG e, soprattutto, sui servizi ricevuti dagli utenti con disabilità, che sono i principali beneficiari dei siti sviluppati secondo criteri di accessibilità.

Secondo un’intepretazione letterale del punto di controllo 11.4 e della relativa nota, il sito parallelo sarebbe non conforme, perché il testo delle WCAG parla esclusivamente di pagine alternative, mai di siti alternativi o paralleli.

Secondo un’altra interpretazione, invece, il dettato del punto di controllo, applicandosi a ogni pagina web indipendentemente dalle scelte fatte per altre pagine collegate, consentirebbe il ricorso al sito parallelo: questo sarebbe, infatti, niente altro che il risultato dell’applicazione, ripetuta pagina per pagina, della scappatoia contenuta nel punto di controllo 11.4, che consente, dopo il fallimento di “ogni sforzo”, di realizzare una pagina alternativa accessibile.

Questo libro propone una terza interpretazione, basata sul dare il giusto rilievo a quello che ci sembra l’elemento critico del punto di controllo 11.4: l’inciso che vincola la realizzazione di una pagina alternativa al fallimento di ogni altro tentativo (“nonostante ogni sforzo”, “after best efforts” nell’originale inglese). Chiediamoci, cioè, se è possibile definire dei casi concreti, nei quali sia lecito ricorrere alla realizzazione di una pagina alternativa, perché è davvero fallito ogni sforzo di rendere accessibile la pagina “primaria”. Se, infatti, riusciamo a togliere all’espressione “nonostante ogni sforzo” la sua vaghezza, se riusciamo a darle un contenuto verificabile, cade anche ogni giustificazione per chi realizza pagine alternative e siti paralleli senza aver compiuto realmente i previsti tentativi di rendere accessibili le pagine di partenza.

A ben guardare, tra i documenti associati alle WCAG 1.0 una risposta alla precedente domanda esiste, e si trova nella lista per verificare la conformità alle linee guida , che ordina in tre gruppi, in base alla priorità, i 65 punti di controllo. La prima delle tre tabelle che compongono il documento elenca tutti i punti di controllo di priorità 1, che sono quelli indispensabili a garantire l’accessibilità di base, ordinandoli per categorie di contenuto, secondo lo schema riportato nel seguente elenco:

• da applicare in generale – punti di controllo 1.1, 2.1, 4.1, 6.1, 6.2, 7.1, 14.1;
• se si usano immagini e mappe immagine – 1.2, 9.1;
• se si usano tabelle – 5.1, 5.2;
• se si usano frame – 12.1;
• se si usano applet e script – 6.3;
• se si usano contenuti multimediali – 1.3, 1.4;
• e se tutto il resto fallisce – 11.4.

Ciò che si ricava dall’elenco è che sviluppatori e autori dovrebbero cercare, in primo luogo, di applicare tutti i punti di controllo di priorità 1 adatti al contenuto del documento che si intende rendere accessibile; solo dopo aver constatato che, nonostante tali tentativi, il contenuto continua a rimanere inaccessibile, è giustificato passare all’applicazione dell’ultimo punto di controllo di priorità 1, cioè l’11.4, che raccomanda appunto la creazione di una pagina alternativa accessibile.

Se si applicasse un simile metodo di valutazione ai siti della Pubblica Amministrazione e di importanti società private nazionali, ai quali sono affiancati siti paralleli che si dichiarano conformi alle WCAG 1.0, si scoprirebbe che le pagine dei siti primari non contengono, per la gran parte, nulla che non avrebbe potuto essere reso direttamente accessibile, se gli autori si fossero sforzati di applicare i punti di controllo di priorità 1 che precedono, nell’elenco, il punto 11.4. Si scoprirebbe, in altre parole, che non è stato fatto “ogni sforzo” per rendere accessibile il sito primario, e che il sito parallelo, soprattutto se fatto di solo testo, rappresenta una sorta di comoda scappatoia, per evitare il lavoro di riprogettazione e ridefinizione dei contenuti, che sarebbe stato necessario per applicare le WCAG 1.0 alle pagine del sito primario.

È importante chiarire che, a parte ciò che richiedono le WCAG 1.0, le persone con disabilità condannano apertamente i siti paralleli, preferendo di gran lunga poter navigare su un sito accessibile, unico per tutti gli utenti, con la possibilità di usufruire di opportuni equivalenti per le immagini e i contenuti multimediali. Il sito parallelo, come spiega correttamente la nota acclusa al punto di controllo 11.4, ha il difetto, di solito, di non essere aggiornato quanto il sito principale. Può capitare, inoltre, che dalle pagine del sito accessibile i navigatori vengano rimandati alle pagine del sito “normale”, non curate dal punto di vista dell’accessibilità, con la conseguenza che una parte dei contenuti non potrà essere fruita da alcune categorie di utenti.

Inizio pagina

Versioni alternative di uno stesso sito

Una soluzione giudicata accettabile, anche se non proprio amata dai beneficiari dell’accessibilità, è quella delle versioni alternative (si veda in proposito la testimonianza di Franco Frascolla, nel paragrafo intitolato L’ipovisione, nel Capitolo 2). Queste si distinguono dal sito parallelo, perché non sono un duplicato del sito primario, ma sono esattamente lo stesso sito, “rivestito” in modo differente grazie ai fogli di stile: il meccanismo consiste nell’offrire all’utente diverse opzioni grafiche, selezionabili per mezzo di appositi pulsanti o menu di scelta. Ogni opzione è associata a un differente CSS, che agisce sul medesimo contenuto: per esempio, un CSS che applica al testo un contrasto di colore invertito e ingrandisce i caratteri, spesso nascondendo le immagini, è utilizzato di solito per generare la versione alternativa consigliata agli ipovedenti (Figura 16.5 B). Ma se una versione alternativa si limita a creare un sito di solo testo, non è cosa molto diversa da un sito parallelo.

Il sistema delle versioni alternative soffre poi, quasi inevitabilmente, di un problema di usabilità: la difficoltà, per utenti con disabilità visive e motorie, di trovare e attivare i comandi per scegliere i layout alternativi. Ciò a causa della mancanza di uno standard condiviso, e spesso a causa di scelte poco accorte di grafici e sviluppatori: è molto difficile, infatti, che un utente ipovedente riesca a localizzare agevolmente una griglia di pulsantini microscopici, che può trovarsi in qualsiasi punto della pagina (si veda, ancora una volta, la testimonianza di Franco Frascolla, nel Capitolo 2). E la difficoltà aumenta, se nei layout alternativi cambia la disposizione dei contenuti: anche la griglia dei pulsantini verrà, infatti, spostata o trasformata graficamente e, se il nuovo layout non è soddisfacente, l’utente avrà grandi difficoltà a ritrovare i comandi per ripristinare la visualizzazione precedente. A nulla serve, molto spesso, premere il pulsante Indietro (Back) del browser, perché il passaggio a una versione alternativa, se non cambia l’indirizzo del documento caricato, non aggiunge elementi alla cronologia.

Un esempio di quanto descritto è dato dal sito del Comune di Torino . Nella pagina di accoglienza predefinita, quella che l’utente si trova di fronte al primo accesso, è presente in basso a destra un blocchetto di personalizzazioni (evidenziato dalla freccia in Figura 16.5 A), contenente pulsantini che permettono di ingrandire i caratteri, cambiare i colori di sfondo e attivare una visualizzazione linearizzata a contrasto invertito. La piccolezza del blocchetto e la sua posizione decentrata – occorre scorrere la pagina quasi fino alla fine per trovarlo – rendono molto difficile il suo reperimento per gli ipovedenti che accedono la prima volta al sito. Inoltre, nella visualizzazione ad altro contrasto, l’aspetto e la posizione del blocchetto di impostazioni sono completamente diversi (Figura 16.5 B). Ciò crea disorientamento in chi si aspetterebbe di poter riutilizzare il medesimo strumento usato in precedenza, per ripristinare la visualizzazione iniziale.

Un sistema di personalizzazione un po’ più accessibile è quello utilizzato dal sito di Trenitalia. In una pagina dedicata , sono presenti, dopo alcune spiegazioni per l’utente, dei grossi pulsanti, che permettono di impostare la visualizzazione desiderata, potendo vedere l’anteprima di ciascuna in un’immagine associata al relativo pulsante (Figura 16.6).

Inizio pagina

Sistemi per invocare le versioni alternative di un sito

I sistemi per cambiare i CSS responsabili delle visualizzazioni alternative sono essenzialmente due: script lato server e script lato client. Il primo sistema ha il vantaggio dell’universalità di applicazione e lo svantaggio della (possibile) lentezza di esecuzione; il secondo sistema ha il vantaggio di una velocità di esecuzione solitamente maggiore e lo svantaggio di dipendere dal supporto del browser per gli script.

Un sistema lato server è quello adoperato dal notissimo sito di esperimenti con i fogli di stile CSS Zen Garden : la selezione delle versioni alternative avviene per mezzo di link che aggiungono all’indirizzo del sito una stringa di query (la parte di un indirizzo web che segue il punto interrogativo), la quale contiene il numero identificativo del foglio di stile associato al collegamento scelto dall’utente; la nuova pagina caricata avrà esattamente il medesimo contenuto di ogni altra, ma il riferimento al foglio di stile da caricare, all’interno dell’elemento STYLE, sarà cambiato in modo da corrispondere al numero identificativo presente nella stringa di query.

Un sistema lato client è invece quello adoperato nella home page del sito del Comune di Torino. Il Listato 16.6 illustra la parte del meccanismo inserita nel codice di marcatura: gli attributi onclick e onkeypress richiamano la funzione JavaScript memorizzaCSS; l’argomento della funzione varia a seconda dell’opzione scelta dall’utente e avvia l’esecuzione di uno script lato client, che ha la funzione di caricare il CSS associato alla versione scelta dall’utente. Le opzioni sono strutturate per mezzo di una lista di definizioni (elementi DL, DT e DD).