Usare codice di marcatura e fogli di stile

I concetti di contenuto, struttura e presentazione

Anche questa linea guida, come le due precedenti, propone una raccomandazione che possiamo considerare del tutto attuale. Per capirne pienamente il senso, occorre in primo luogo aver compreso bene il significato dei concetti di contenuto, struttura e presentazione, che sono essenziali per poter lavorare in modo accessibile sugli stili grafici delle pagine web e sull’organizzazione logica delle informazioni in esse contenute. Forniamo, perciò, di seguito una definizione di questi tre concetti, considerati nell’ottica dell’accessibilità.

Contenuto. È l’informazione fornita da un documento. I contenuti disponibili sul Web sono di vario tipo: testi, immagini, animazioni, filmati, brani audio, grafici, tabelle ecc. I contenuti sono i mattoni informativi di cui sono composte le pagine web, i siti e il Web nel suo insieme. L’accessibilità dei contenuti, quella descritta dalle WCAG 1.0 e 2.0, si occupa specificamente di organizzare, modificare, manipolare questi mattoni informativi in modo che siano utilizzabili da persone con disabilità e, in generale, da qualsiasi categoria di utenti.

Presentazione. È il modo in cui i contenuti appaiono all’utente ovvero l’insieme delle loro caratteristiche grafiche e/o acustiche, così come sono riprodotte dai programmi utente utilizzati. L’insieme degli stili applicati a un documento costituisce la sua presentazione; i fogli di stile (CSS) sono lo strumento d’elezione per creare una presentazione accessibile di un documento.

Struttura. È l’insieme delle relazioni tra i contenuti di un documento. I rapporti di subordinazione e di coordinazione tra i contenuti sono l’ossatura, lo schema che rappresenta la struttura di un documento. Una gerarchia di titoli di diverso livello, il rapporto di coordinazione tra un titolo e i paragrafi a esso collegati, il rapporto tra righe e colonne di una tabella, una serie di elenchi annidati sono tutte caratteristiche strutturali di un documento. È compito precipuo dei linguaggi di marcatura descrivere la struttura dei contenuti. Va precisato che ogni browser è in grado nativamente di rappresentare in modo significativo la struttura di un documento HTML o XHTML (per esempio, mettendo i titoli in caratteri più grandi del testo a paragrafi), anche se non vi sono fogli di stile associati. Ai fini dell’accessibilità, è importante, perciò, che gli sviluppatori applichino informazioni strutturali ai contenuti, in modo che, anche se si elimina del tutto la presentazione affidata ai fogli di stile, gli elementi essenziali della struttura rimangano visibili e comprensibili per il lettore.

Elementi e attributi deprecati

La linea guida 3 prescrive agli sviluppatori due precauzioni - marcare i contenuti con gli opportuni elementi e attributi strutturali e usare i CSS per la presentazione – che erano già chiaramente anticipate nelle specifiche HTML 4.0 del dicembre 1997 , che contengono una forte apertura verso l’accessibilità. In quelle specifiche veniva introdotto il concetto di elementi e attributi deprecati (deprecated): una serie di elementi, tra cui APPLET, CENTER, DIR, FONT, S, U, e di attributi, tra cui background, bgcolor, face, size, lasciati in una DTD apposita, considerata provvisoria (transitional), il cui uso veniva formalmente sconsigliato e relegato alla mera necessità, ritenuta di breve durata, di garantire una compatibilità all’indietro verso programmi utente obsoleti.

Buona parte degli elementi e degli attributi deprecati in HTML 4 (e in XHTML 1.0) svolgono un ruolo presentazionale; le specifiche HTML 4, a cui si ricollega la linea guida 3 delle WCAG 1.0, consigliano di usare al loro posto i fogli di stile, come leggiamo proprio nella definizione formale di deprecato:

Un elemento o un attributo sono deprecati perché superati da costrutti più recenti. (...) I programmi utente dovrebbero continuare a supportare gli elementi deprecati per ragioni di compatibilità all’indietro. (...) Queste specifiche includono esempi che illustrano come evitare di usare elementi deprecati. Nella maggior parte dei casi essi dipendono dal supporto dei programmi utente per i fogli di stile. In generale, gli autori, per ottenere effetti stilistici e di formattazione, dovrebbero usare i fogli di stile piuttosto che attributi presentazionali di HTML. Gli attributi presentazionali di HTML sono stati deprecati, laddove esistono alternative con i fogli di stile.

Ciò che nel 1997 e negli anni immediatamente successivi era quasi impossibile, a causa dello scadente supporto ai fogli di stile offerto dai browser dell’epoca, è invece oggi non solo possibile, ma addirittura prassi comune tra gli sviluppatori più preparati e più vicini alle tematiche dell’accessibilità: eliminare, cioè, dal codice di marcatura gli elementi e gli attributi di presentazione, soprattutto quelli deprecati, sostituendoli con l’uso dei fogli di stile per ottenere equivalenti effetti di formattazione.

Inizio pagina

Perché usare i fogli di stile al posto di elementi e attributi di presentazione?

Perché mai l’eliminazione dal codice di marcatura degli elementi e degli attributi di presentazione dovrebbe migliorare l’accessibilità? Per capirlo, occorre rispondere alla domanda inversa: perché l’uso di elementi e attributi di presentazione penalizza l’accessibilità? Per una serie di motivi:

• rischia di bloccare la presentazione su modalità non flessibili, non adattabili a diversi dispositivi e a diverse esigenze di fruizione;
• può offuscare la struttura dei contenuti, se questa finisce con il trovarsi mischiata con gli aspetti di presentazione o addirittura sostituita dalla formattazione (si pensi per esempio a titoli resi tali solo dall’aspetto grafico e non dall’uso degli appositi elementi strutturali H1, H2 ecc.);
• appesantisce notevolmente il codice, rendendo più lunghi i tempi di caricamento delle pagine (un foglio di stile è in genere condiviso tra più pagine e può bastarne uno solo per un intero sito; invece il codice di marcatura presentazionale va ripetuto in ogni pagina, anche se sono moltissime e se hanno tutte esattamente la stessa grafica).

Un esempio aiuterà a capire meglio come la cattiva strutturazione dei contenuti e l’uso di elementi e attributi di presentazione possono rendere un sito scarsamente accessibile, mentre l’uso corretto di elementi strutturali e la separazione della presentazione dalla struttura e dai contenuti favoriscono invece l’accessibilità. Proviamo allora a mettere a confronto quella che è stata a lungo la prima pagina del sito della Rete Civica di Firenze (sostituita solo di recente da una versione molto migliorata) con la home page del sito del Comune di Siena: piena di elementi e attributi di presentazione la prima, nonché di elementi strutturali usati impropriamente a scopo di presentazione, come le tabelle; con una completa separazione di struttura e presentazione la seconda.

La Figura 6.1 A mostra l’aspetto grafico predefinito della home page del sito del Comune di Firenze all’epoca della nostra prova (febbraio 2007). A causa del pesante uso di elementi e attributi di presentazione (FRAMESET, FONT, CENTER, align, size, bgcolor, background ecc.), quasi tutti deprecati, la pagina non è in grado di trasformarsi elegantemente. Infatti, passando con il browser Opera 9 dalla modalità autore alla modalità utente, che, nella sua forma base, consiste nella disabilitazione dei fogli di stile e nell’eliminazione dei caratteri e dei colori assegnati dall’autore, la pagina appare bloccata sulla medesima griglia d’impaginazione della vista grafica, come si può vedere in Figura 6.1 B. Non è possibile nessun adattamento a dispositivi diversi e a modalità di fruizione diverse: tutti i blocchi di contenuto rimangono al loro posto, a causa dell’uso dei frame e delle tabelle a scopo d’impaginazione. In più vi sono sovrapposizioni di contenuti e la struttura del documento risulta offuscata (non è chiaro, cioè, quali siano l’ordine e l’importanza reciproca dei contenuti).

Figura 6.1. La home page di una versione non più online del sito della Rete Civica di Firenze, vista in modalità grafica (A) e con il supporto per gli stili CSS disattivato (B) con il browser Opera 9.

La situazione è completamente diversa, invece, per la prima pagina del sito del Comune di Siena . La separazione della presentazione dai contenuti e dalla struttura è totale. Nel codice di marcatura non vi sono elementi e attributi di presentazione e gli elementi strutturali sono utilizzati in modo corretto, anche se, forse, con qualche eccesso nell’uso dei DIV. La conseguenza è che la pagina si trasforma elegantemente, come dimostra la schermata catturata a fogli di stile disattivati (Figura 6.2 B): ciò vuol dire possibilità di fruizione indipendente dal dispositivo e dal tipo di presentazione, piena visibilità della struttura, peso ridotto del documento.

Figura 6.2. La home page del sito del Comune di Siena, vista in modalità grafica (A) e con il supporto per gli stili CSS disattivato (B), con il browser Opera 9 (1/2/2007).

Inizio pagina

Punto di controllo 3.1, priorità 2

Linguaggi di marcatura per la matematica

Il riferimento del punto di controllo 3.1 è soprattutto alla matematica. La complessa simbologia delle formule matematiche spinge infatti gli autori a usare molto spesso le immagini al posto del codice HTML, o di altri strumenti più evoluti come MathML, per veicolare contenuti matematici sul Web. Ma perché la matematica resa per mezzo di oggetti grafici è poco o nulla accessibile? La ragione è che le formule in forma d’immagine non sono indipendenti dal dispositivo: non si prestano bene a essere ingrandite (il testo-immagine ingrandito perde nitidezza, si sgrana) e, inoltre, non possono essere lette da uno screen reader. Per tali ragioni, è opportuno per l’accessibilità trasformare le informazioni di tipo matematico in appropriato codice di marcatura.

Nel documento di tecniche HTML per le WCAG 1.0, sono presenti alcuni suggerimenti su come applicare il punto di controllo 3.1 ai contenuti matematici:

• garantire che gli utenti possano sapere ciò che le variabili rappresentano. Per esempio, nell’equazione F = m * a, indicare che F = forza, m = massa, a = accelerazione;
• per le equazioni più elementari, usare direttamente i caratteri, come in x + y = z;
• nel caso di equazioni più complesse, marcarle con MathML o TeX;
• fornire una descrizione testuale dell’equazione e, dove possibile, usare entità e riferimenti a caratteri per creare simboli matematici. Se l’equazione è rappresentata da una o più immagini, deve essere fornito un equivalente testuale.

[Inizio approfondimento] MathML

MathML, abbreviazione di Mathematical Markup Language Version 2.0 (http://www.w3.org/TR/MathML2/ ), raccomandazione W3C del 21 ottobre 2003, “è un’applicazione XML per descrivere la notazione matematica e catturarne insieme la struttura e il contenuto. Lo scopo di MathML è far sì che la matematica possa essere servita, ricevuta ed elaborata sul World Wide Web, così come l’HTML ha fatto sì che queste funzionalità fossero possibili per il testo”.

MathML è un complesso linguaggio di marcatura, che non è stato progettato per essere scritto direttamente da umani, bensì per essere generato da specifiche applicazioni, come SciWriter di Soft4science, che trasformano automaticamente in codice MathML le formule scritte dall’utente con la simbologia della matematica.

La riproduzione corretta di codice MathML da parte dei browser dipende da alcuni fattori:

• il supporto nativo per questo linguaggio di marcatura, fornito per esempio da Firefox;
• l’installazione di alcuni font particolari, contenenti i caratteri necessari, indispensabili per visualizzare alcuni tipi di formule;
• l’installazione di appositi plug-in, come per esempio MathPlayer per Internet Explorer 6.0 (browser privo di supporto nativo per MathML), che è liberamente scaricabile da http://www.dessci.com/en/products/mathplayer/ .

Figura 6.3. Resa nativa di codice MathML nel browser Firefox 2.0.

Tutte le informazioni sulle specifiche MathML e sulle attività del W3C relative a questo linguaggio di marcatura sono disponibili nella sezione W3C Math Home del sito del Consorzio, all’indirizzo http://www.w3.org/Math/ . Per un esempio di integrazione tra MathML e XHTML, si veda il paragrafo “Un esempio di uso appropriato di XHTML”, nel Capitolo 16. [Fine approfondimento]

Inizio pagina

Punto di controllo 3.2, priorità 2

La dichiarazione del tipo di documento

La correttezza formale del codice di marcatura è considerata dalle WCAG 1.0 elemento importante per l’accessibilità. Per consentire il controllo della correttezza del codice da parte dei validatori e una rappresentazione dei contenuti da parte dei programmi utente il più possibile rispettosa degli standard internazionali proposti dal W3C e da altri enti, è indispensabile che gli sviluppatori dichiarino all’inizio dei propri documenti il tipo di grammatica a cui il codice di marcatura fa riferimento. Tale dichiarazione prende il nome di !DOCTYPE Statement, o, in italiano, dichiarazione del tipo di documento.

Esiste una sintassi molto precisa, per dichiarare il tipo di documento che contiene la grammatica formale seguita - almeno in teoria - nel codice di marcatura che segue la dichiarazione.

La prima regola è che la dichiarazione deve comparire proprio all’inizio del codice. La seconda regola è che deve essere racchiusa tra parentesi angolari (< ... >), come un qualsiasi elemento di HTML o di XML (ma senza bisogno di un marcatore di chiusura), e deve cominciare con la stringa !DOCTYPE. Le altre regole riguardano la struttura interna della dichiarazione, cioè la posizione e la forma delle stringhe e sottostringhe di testo che la compongono. Vediamole in dettaglio, esaminando la forma di una tipica dichiarazione del tipo di documento, come quella di XHTML 1.0 strict.

La Tabella 6.1 mostra nomi e funzioni delle varie parti che compongono la dichiarazione del tipo di documento XHTML 1.0 Strict. La parte della dichiarazione che è racchiusa tra doppi apici e contiene le sottoparti chiamate Registration, Organization, Type, Label e Language, è detta FPI o Formal Public Identifier (Identificatore formale pubblico). Nel caso di XHTML 1.0 Strict lo FPI corrisponde alla stringa "-//W3C//DTD XHTML 1.0 Strict//EN". La doppia barra (//) è usata come separatore interno. Ogni FPI è unico e serve perciò a designare univocamente una grammatica formale pubblicata.

Modalità standard e modalità “bizzarra” (quirks mode)

Un’obiezione comune tra gli sviluppatori è: a cosa serve dichiarare la DTD, se i browser riproducono ugualmente anche i documenti che non seguono tale regola?

Sì, è vero, i browser riproducono qualsiasi codice di marcatura servito con il MIME type text/html, forti di anni di affinamento delle loro capacità di interpretare le intenzioni degli autori, anche in presenza dei più clamorosi errori di codifica.

Tuttavia non è esatto dire che non fa differenza. I browser più diffusi e usati (Internet Explorer, Firefox, Opera, Safari) cambiano tra due o anche tre diverse modalità di rappresentazione dei documenti, a seconda che sia presente oppure omessa la dichiarazione del tipo di documento e, se questa c’è, a seconda che sia presente oppure no l’indirizzo della DTD referenziata.

Le tre modalità sono:

• standard mode - la modalità standard, nella quale la rappresentazione della pagina da parte dei browser segue, nella misura in cui ciascun browser le supporta, le regole definite dai linguaggi standard per il Web;
• almost standard mode - la modalità quasi standard, presente nei browser basati sul motore di rendering Gecko, che è in tutto uguale alla modalità standard, tranne che nel modo in cui sono trattate le immagini all’interno delle celle di tabella, allo scopo di garantire una somiglianza di comportamento con Internet Explorer;
• quirks mode - la modalità “bizzarra”, nella quale i browser violano deliberatamente le regole definite dai linguaggi standard, allo scopo di garantire la compatibilità all’indietro con pagine web progettate per essere rappresentate su browser vecchi e difettosi come Netscape 4 o Internet Explorer 5.

È importante tener presente che ciascun browser intende a modo proprio il funzionamento in quirks mode (ciò è vero, in minor misura, anche per lo standard mode). Non è detto, cioè, che un documento si veda senza differenze in Firefox e Internet Explorer solo perché sono entrambi in quirks mode.

È molto difficile tener traccia di tutte le differenze di rappresentazione dei contenuti che, per ciascun browser, sono legate all’esistenza di diverse modalità di riproduzione dei documenti. Peter-Paul Koch, esperto olandese di linguaggi standard e JavaScript, ha provato a stilare una mappa dei comportamenti dei principali browser in base alla modalità attiva, in un articolo intitolato Quirks Mode and Strict Mode .

La scelta da parte dei produttori di browser di usare due o più modalità di rappresentazione dei documenti, e di legare l’attivazione di una modalità al tipo di dichiarazione presente (o assente) all’inizio del codice, ha fatto nascere la tecnica del cosiddetto doctype switching (nota anche come doctype sniffing), che consiste nello scegliere per le proprie pagine web una dichiarazione del tipo di documento piuttosto che un’altra, o nessuna, con lo scopo di ottenere un particolare comportamento da parte di uno o più browser. Un autore che voglia, per esempio, ottenere che Internet Explorer 6 si comporti come Internet Explorer 5 nel visualizzare una data pagina web, non ha che da omettere la dichiarazione del tipo di documento, oppure far sì che non sia il primo elemento che si incontra nel codice di marcatura (basta, a tal fine, inserire la dichiarazione XML, se è usata una DTD di XHTML).

Nel momento in cui uno sviluppatore decide quale dichiarazione del tipo di documento usare, fa parte delle sue competenze professionali conoscere quale sarà la modalità con cui i principali browser riprodurranno quel documento. Un lavoro di documentazione notevole è stato svolto, a tal fine, dal finlandese Henri Sivonen, che, in un articolo intitolato Activating the right Layout Mode using the Doctype Declaration , ha compilato una tabella in cui sono associate le dichiarazioni del tipo di documento più utilizzate con il tipo di modalità che esse attivano nei principali browser.

L’articolo merita di essere letto, anche perché contiene alcune interessanti considerazioni sul significato e l’uso della tecnica del doctype switching. Una di queste è che l’attivazione dello standard mode o del quirks mode non ha alcun effetto sul parsing, cioè sull’analisi del codice di un documento (servito come text/html) da parte dei browser. In altre parole, standard mode e quirks mode sono soltanto modalità di resa grafica dei contenuti, che non tengono in alcun conto la validità o la non validità del codice, cioè il grado in cui un documento rispetta (o non rispetta) una grammatica formale di riferimento.

Quale DTD dichiarare in un sito accessibile?

Dal punto di vista dell’accessibilità, non è importante quale modalità un browser stia usando, a meno che la modalità attiva non determini un deterioramento della resa grafica di un documento, tale da rendere i suoi contenuti non fruibili o scarsamente fruibili (un’ipotesi piuttosto remota, in documenti ben progettati).

Ciò che invece conta per l’accessibilità è creare documenti che abbiano un alto grado di interoperabilità, siano ben strutturati e abbiano una presentazione separata dai contenuti e affidata ai fogli di stile. Date tali premesse, le scelte che gli sviluppatori di siti accessibili devono compiere, per quanto riguarda la dichiarazione del tipo di documento, sono relativamente semplici e hanno poco o nulla a che fare con le tecniche di doctype switching.

Prima decisione: inserire sempre la dichiarazione

La dichiarazione va certamente inserita, innanzitutto perché l’interoperabilità, che è uno dei requisiti dell’accessibilità, è favorita dal rispetto degli standard, e sia le specifiche HTML sia quelle XHTML richiedono, come elemento necessario di conformità del codice, che sia dichiarata la DTD di riferimento. Nelle specifiche HTML 4.01, tale richiesta si trova nel paragrafo 7.2 HTML Version Information, che dice:

Un documento HTML valido dichiara quale versione di HTML è usata nel documento.

Nelle specifiche XHTML 1.0, invece, la richiesta di dichiarazione si trova nel paragrafo 3.1.1 Strictly Conforming Documents, in cui si definisce un documento XHTML rigorosamente conforme come un documento XML che soddisfa cinque requisiti obbligatori, il quarto dei quali è:

Deve esserci una dichiarazione DOCTYPE nel documento prima dell’elemento radice.

Un’altra ragione per dichiarare la DTD è, naturalmente, soddisfare il punto di controllo 3.2 delle WCAG 1.0: il validatore automatico disponibile presso il sito del W3C (http://validator.w3.org/ ) non può, infatti, analizzare correttamente i documenti privi di dichiarazione del tipo di documento. Si può superare l’impasse scegliendo arbitrariamente una DTD contro cui validare il codice, ma ciò introduce un elemento di arbitrarietà nel procedimento. Un documento che non dichiari il DOCTYPE non può, insomma, essere confrontato in modo attendibile con una grammatica formale pubblicata, come richiede invece il punto di controllo 3.2.

Seconda decisione: preferire la DTD strict

Nei linguaggi di marcatura HTML 4.01 e XHTML 1.0, le uniche DTD che si prestano a una rigorosa separazione tra struttura e presentazione dei contenuti sono le DTD strict. Queste DTD, infatti, non contemplano elementi e attributi deprecati, che sono quelli che servono essenzialmente a scopo di presentazione. Permettono pertanto di creare documenti fatti solo di contenuti strutturati, nei quali la presentazione è lasciata interamente ai fogli di stile.

Le altre due DTD di HTML 4.01 e XHTML 1.0, cioè la transitional e la frameset, non si prestano altrettanto bene agli scopi dell’accessibilità.

La transitional contiene elementi e attributi di presentazione, e li contiene affinché li si usino: dichiarare una DTD transitional e usare poi solo codice strict è quantomeno bizzarro. L’uso di tale DTD ha lo scopo di garantire agli sviluppatori una continuità, sia pure transitoria, con i criteri di sviluppo usati all’epoca di HTML 3.2, in cui il codice di marcatura racchiudeva in un groviglio unico - successivamente battezzato tag soup o “minestrone di marcatori” - struttura, contenuti e presentazione di un documento.

Per quanto riguarda la DTD frameset, è da ritenersi inadatta per l’accessibilità per varie ragioni. Innanzitutto i siti strutturati a frame possono ostacolare la navigazione di chi usa tecnologie assistive, soprattutto se i frame hanno nomi non significativi. Inoltre, richiedono l’uso dell’attributo deprecato target, necessario per gestire i collegamenti incrociati tra frame, e, di conseguenza, la dichiarazione di una DTD transitional.

Possiamo allora concludere che, nello sviluppo di siti accessibili, la scelta migliore è dichiarare, per HTML 4.01 e XHTML 1.0, le rispettive DTD strict. Nel caso si scelga, invece, di usare come linguaggio di marcatura XHTML 1.1, il problema non si pone, dal momento che questo linguaggio, a differenza dei due precedenti, dispone di una sola DTD, che è di tipo strict, avendo bandito del tutto dal suo repertorio frame, elementi e attributi di presentazione.

Abbiamo già presentato nel Listato 6.1 la dichiarazione del tipo di documento per XHTML 1.0 strict. Riportiamo di seguito le dichiarazioni del tipo di documento da usare per HTML 4.01 strict e per XHTML 1.1.

Inizio pagina

Punto di controllo 3.3, priorità 2

Un esempio di tag soup (o “minestrone di marcatori”)

Il punto di controllo 3.3 è d’importanza centrale, perché la sua richiesta - usare i fogli di stile per la presentazione (e, perciò, separare la presentazione dal contenuto e dalla struttura di un documento) - ha profonda influenza sull’accessibilità e, in particolare, sull’adattabilità dei contenuti alle più differenti condizioni di fruizione da parte degli utenti.

Per capire come soddisfare nel modo migliore il punto di controllo 3.3, occorre in primo luogo ragionare sugli elementi che compongono un documento e imparare: 1) a riconoscerli; 2) a mettere ordine tra loro.

Questi elementi costitutivi sono tre e sono stati definiti all’inizio del capitolo: contenuti, struttura e presentazione.

Prima che si diffondesse l’uso dei fogli di stile, i tre componenti erano inevitabilmente confusi tra loro nel codice di marcatura, formando quel minestrone indigesto che è stato definito tag soup: indigesto per gli sviluppatori che dovevano metterci mano, per i browser e, molto spesso, per le tecnologie assistive.

Ci sarà utile partire proprio da un esempio di tag soup preso dalla realtà del Web. Analizzeremo e poi separeremo i componenti, mettendo in luce cosa appartiene al contenuto, cosa alla struttura e cosa alla presentazione. In questo modo, il lettore potrà imparare non solo a riconoscere ciò che è proprio di ciascun elemento, ma anche a formarsi un metodo per la produzione di documenti ben strutturati, progettati per l’interoperabilità e l’accessibilità.

Abbiamo scelto per questo esempio di lavorare su un frammento di codice di marcatura, tratto dalla home page di un sito in inglese dedicato alla saga di Robin Hood, che pare piuttosto datato sia per l’aspetto grafico sia, soprattutto, per la composizione del codice, che presenta una completa mescolanza di contenuto, struttura e presentazione. Costituisce perciò - non ce ne vogliano gli autori - un ottimo esempio di come non dovrebbe essere realizzata la marcatura in un sito progettato per l’accessibilità.

Figura 6.4. La parte superiore della home page del sito Sherwood Times (2/2/2007).

Cominciamo a esaminarne l’aspetto grafico (Figura 6.4), che ci permette di ricavare alcune informazioni di natura strutturale.

Sherwood Times è il titolo della pubblicazione e il titolo principale del documento. C’è poi una breve descrizione dell’argomento del sito (newspaper dates from A.D.1190-4 reporting on Robin Hood and King Richard’s Crusade). Sulla destra è presente una sorta di logo: una foto della Grande Quercia della Foresta di Sherwood. Segue un titolo di livello inferiore, News & Features, impropriamente “spalmato” su due colonne adiacenti, sotto il quale sono raccolti i collegamenti al racconto in sedici pagine, che costituisce il contenuto principale del sito.

Nella colonna di destra vi è un altro titolo, Supplement (dello stesso livello gerarchico di News & Features), sotto il quale sono raccolti tre titoli di livello inferiore: 1) Marian Fitzwater Interviews, 2) Features e 3) Story Adapted from Chretien de Troyes. Ciascuno di essi ha come contenuto uno o più collegamenti ad alcuni documenti accessori. Infine, la colonna di sinistra e quella centrale sono chiuse da due immagini decorative.

Se tutto ciò fosse strutturato a livello di codice in modo corrispondente a come appare a livello grafico, sarebbe comodamente navigabile per titoli con un sintetizzatore vocale e sarebbe possibile, inoltre, verificare per mezzo dell’analizzatore semantico del W3C (Semantic Data Extractor ) la presenza della medesima gerarchia di titoli che appare in modalità grafica. Invece il responso dell’analizzatore semantico del W3C non lascia adito a dubbi: nel codice della home page dello Sherwood Times non c’è assolutamente nulla che assomigli a un titolo (Figura 6.5).

Figura 6.5. L’analizzatore semantico del W3C non ha trovato alcun elemento d’intestazione nella home page dello Sherwood Times (2/2/2007).

Questa scoperta testimonia di un fattore importante dal punto di vista dell’accessibilità: la gerarchia dei titoli che si ricava guardando la pagina è tutta esteriore. Tolta la grafica, cioè la presentazione, scompare anche la struttura. Non ci resta, ora, che analizzare il codice, per averne prova diretta.

La lettura del Listato 6.4 ci dice che la gabbia grafica del documento riprodotto in Figura 6.4 è costituita da una tabella d’impaginazione (layout table), al cui interno sono contenute altre due tabelle d’impaginazione. La prima è composta da una riga di due celle. La cella di sinistra contiene l’immagine col titolo Sherwood Times e il testo descrittivo. La cella di destra contiene la foto della grande quercia. La seconda tabella è composta da una riga suddivisa in tre celle, che corrispondono alle tre colonne grigie visibili in Figura 6.4. Tutto ciò è presentazione, ottenuta usando impropriamente elementi come le tabelle, che dovrebbero servire a strutturare dati realmente tabellari (indirizzari, calendari, classifiche ecc.).

L’analisi del codice di marcatura ci dice, inoltre, che tutte le rimanenti caratteristiche grafiche del documento - colori, allineamenti, grandezze dei caratteri - sono ottenute per mezzo di elementi e attributi di presentazione (CENTER, FONT, U, align, size, bgcolor, bordercolor ecc.). Non c’è traccia d’uso dei fogli di stile.

Un’altra caratteristica interessante, tipica di un documento con codice tag soup, è l’uso improprio di elementi strutturali, come le liste di definizioni (elementi DL, DT, DD), che sono state utilizzate per marcare tutti i contenuti delle tre colonne: intestazioni, elenco di collegamenti e immagini decorative.

Le liste di definizioni sono strutture binarie, in cui uno o più termini definiti, marcati con l’elemento DT, sono associati a una o più definizioni, marcate con l’elemento DD. Questa struttura può essere usata, tipicamente, per marcare glossari, dialoghi, e tutto ciò che abbia una struttura binaria, tale da poter essere suddivisa in una parte che funge da termine e una parte che funge da descrizione.

Ma nella pagina di Sherwood Times questa struttura binaria non c’è. E infatti tutti i contenuti delle tre colonne sono marcati con elementi DT. Gli unici elementi DD presenti contengono uno spazio vuoto (<dd>&nbsp;</dd>). Infine, tutto ciò che in una lista di definizioni viene marcato con DT dovrebbe essere omogeneo dal punto di vista semantico: o tutti termini di glossario o tutti nomi di attori o tutti nomi di ricette, e così via. Invece negli elenchi di Sherwood Times questa omogeneità manca: con lo stesso elemento DT sono marcati i titoli delle sezioni, i collegamenti e le immagini decorative: un “minestrone”, appunto, come dimostra l’elenco nella sezione Defined terms (“termini definiti”) del resoconto generato dall’analizzatore semantico del W3C (Figura 6.6).

Inizio pagina

Separiamo gli ingredienti del “minestrone”

Siamo ora pronti per separare gli ingredienti del “minestrone”, il che è condizione preliminare per ricostruire il documento in maniera ordinata e più accessibile.

Il nostro scopo finale sarà quello di spostare tutta la presentazione in un foglio di stile esterno e, contemporaneamente, di bonificare il codice di marcatura, attraverso due tipi di intervento:

1. l’eliminazione degli elementi e degli attributi di presentazione;
2. l’inserimento di opportuni elementi strutturali, al posto o in aggiunta di quelli usati impropriamente.

Il primo ingrediente sono i contenuti. Elenchiamoli, così come si fa con gli ingredienti di una ricetta:

• 4 immagini (Sherwood Times, la quercia grande e le due immagini in fondo alle prime due colonne in Figura 6.4);
• 29 stringhe di testo (dalla frase introduttiva che comincia con newspaper dates from A.D.1190-4 fino al testo dell’ultimo collegamento in basso a destra, che è Lancelot and Guinevere).

Figura 6.6. Una porzione dell’elenco dei termini definiti (elementi DT) all’interno della home page del sito Sherwood Times, generata dal Semantic Data Extractor del W3C. Non c’è alcuna omogeneità tra i dati marcati con DT.

Ciascuno di questi contenuti svolge una precisa funzione all’interno del documento e occupa un posto nella gerarchia di relazioni che li lega reciprocamente. L’elenco delle funzioni dei contenuti e delle loro relazioni (orizzontali, verticali e sequenziali) costituisce la struttura del documento, che possiamo così riassumere:

• 1 titolo di primo livello (l’immagine Sherwood Times);
• 1 descrizione dell’argomento del sito;
• 1 immagine-logo (la grande quercia della Foresta di Sherwood);
• 2 titoli di secondo livello (News & Features e Supplement);
• 1 elenco di sedici collegamenti ipertestuali (i link alle sedici pagine del racconto, in ordine di numerazione), che scindiamo, per comodità di rappresentazione grafica, in due elenchi separati di otto collegamenti ciascuno, dipendenti da un titolo di secondo livello (News & Features);
• 3 titoli di terzo livello (Marian Fitzwater Interviews, Features e Story Adapted from Chretien de Troyes), dipendenti da un titolo di secondo livello (Supplement);
• 3 gruppi di collegamenti, rispettivamente di 3,3 e 1 elementi, dipendenti ciascuno da uno dei tre titoli di terzo livello;
• 2 immagini decorative.

Il terzo e ultimo ingrediente è la presentazione, che in questo caso è limitata all’aspetto grafico del documento riprodotto in Figura 6.4, le cui caratteristiche possiamo così sinteticamente elencare:

• sfondo giallo chiaro per l’intero impaginato;
• sfondo grigio per il blocco su tre colonne posizionato nella parte inferiore del documento;
• allineamento centrato per il titolo del sito e la descrizione, suddivisa su tre righe molto spaziate verticalmente;
• immagine-logo posizionata a destra in alto;
• a seguire, titolo News & Features in verde, sul lato sinistro della pagina, centrato rispetto ai due elenchi posizionati sotto di esso;
• un’immagine decorativa sotto ciascuno dei due elenchi;
• una terza colonna posizionata sulla destra, che contiene titoli di secondo e terzo livello di colore fucsia, più tre gruppi di collegamenti ipertestuali posti sotto i titoli di terzo livello;
• collegamenti ipertestuali nel classico stile blu sottolineato.

Le parti che abbiamo indicato come contenuti e struttura rimarranno nel codice di marcatura emendato (tranne le due immagini decorative); tutto ciò che è presentazione finirà, invece, in un foglio di stile.

Inizio pagina

Il codice di marcatura serve per strutturare i contenuti

La prima cosa da fare, dopo aver separato gli “ingredienti”, è cominciare a riscrivere il codice di marcatura del Listato 6.4, in modo che contenga solo contenuti strutturati e nessuna caratteristica di presentazione, o quasi.

Un codice di marcatura ridotto a contenuto strutturato privo di presentazione consentirà una fruizione ottimale dei contenuti con browser testuali, screen reader e dispositivi con schermo piccolo. Permetterà inoltre agli utenti evoluti di applicare al documento un proprio foglio di stile personalizzato, in modo da ottenere una presentazione accessibile, conforme alle proprie esigenze.

Poiché vogliamo che la nuova versione del codice sia non solo conforme al punto di controllo 3.3 delle WCAG 1.0, ma anche rispettosa dei linguaggi standard per il Web, inseriremo all’inizio la dichiarazione del tipo di documento, mancante nell’originale. Useremo a questo scopo la DTD strict di HTML 4.01, in accordo con il ragionamento svolto nel paragrafo “Seconda decisione: preferire la DTD strict”.

Confrontando i Listati 6.4 e 6.5, la prima cosa che salta all’occhio è che il secondo è molto più breve del primo: 2.014 caratteri contro 3.560, con un risparmio di oltre il 43%. Il codice del Listato 6.5 è inoltre molto più leggibile del codice del Listato 6.4. L’eliminazione di elementi e attributi di presentazione rende il codice di marcatura molto più comprensibile per gli sviluppatori, con grande vantaggio di chi si occupa della manutenzione.

Altre differenze degne di menzione sono:

• l’inserimento nella sezione HEAD di un elemento LINK (in grassetto nel listato, per evidenziarlo), che crea un collegamento al foglio di stile stili.css, che esamineremo successivamente, al quale sarà affidata la presentazione del documento;
• la scomparsa delle tabelle a scopo d’impaginazione, sostituite da alcuni elementi DIV, che servono come ancoraggio per riprodurre, tramite CSS, l’aspetto grafico della pagina mostrata in Figura 6.4;
• l’eliminazione delle liste di definizione, sostituite - nelle parti relative ai collegamenti ipertestuali - da elenchi non ordinati (elementi UL);
• la riunificazione in un’unica intestazione delle due scritte News & e Features, che nell’impaginazione originale di Figura 6.4 sono divise in due colonne diverse, il che le rendeva prive di significato per utenti che navigano in modalità non grafica;
• l’inserimento, dove necessario, di elementi H1, H2 e H3, per marcare strutturalmente le intestazioni; si noti, a questo proposito, che l’immagine che fa da titolo principale del documento è stata inserita in un elemento H1. In tal modo, il suo testo alternativo (Sherwood Times) potrà essere utilizzato anche dagli screen reader con la funzione semantica di titolo che gli compete;
• l’eliminazione delle due immagini decorative, che ritorneranno come elementi integrati nel CSS.

Figura 6.7. Aspetto della pagina di Sherwood Times, riprodotta con i soli stili applicati in modo predefinito dai browser grafici ai titoli, agli elenchi e ai collegamenti, sulla base del codice di marcatura nel Listato 6.5.

L’aspetto grafico del documento così riscritto, visualizzato senza foglio di stile, è di un’essenziale semplicità, e dipende dalle impostazioni stilistiche predefinite del browser grafico utilizzato, che sono più o meno universali: testo in carattere Times, intestazioni in neretto e di dimensione maggiore rispetto al corpo del testo, elenchi puntati con margine sinistro rientrato, collegamenti ipertestuali in colore blu sottolineato (Figura 6.7).

Figura 6.8. Il codice del Listato 6.5 produce una corretta gerarchia di titoli, verificata tramite il Semantic Data Extractor del W3C.

Se eseguiamo sulla nuova versione del codice di marcatura un’analisi con l’analizzatore semantico del W3C, troviamo che stavolta è presente una struttura di titoli (Figura 6.8), corrispondente alla gerarchia evidenziata dalla vista grafica di Figura 6.7. La scritta Sherwood Times, che corrisponde al titolo di livello più alto, è tra parentesi quadre, a indicare che non si trova nel testo visibile, ma è il valore di un attributo alt.

Inizio pagina

Tutta la presentazione in un foglio di stile

Siamo pronti per l’ultimo atto: la compilazione del foglio di stile stili.css, a cui è delegato il compito, agendo sul codice di marcatura riscritto, di definire un aspetto grafico del documento corrispondente a quello visibile in Figura 6.4. Ecco dunque il foglio di stile; subito dopo, ne illustreremo le caratteristiche principali.

Per capire pienamente il funzionamento degli stili riportati nel Listato 6.6, occorre vedere innanzitutto come agiscono sul codice di marcatura del Listato 6.5, cioè qual è l’aspetto grafico del documento a cui essi si applicano (Figura 6.9).

Figura 6.9. La presentazione generata dal foglio di stile nel Listato 6.6.

Confrontando le due rappresentazioni grafiche del documento, quella di Figura 6.4, generata dal codice di marcatura di tipo tag soup, e quella di Figura 6.9, prodotta dal foglio di stile esterno, appaiono due differenze visibili a colpo d’occhio: la riunificazione - voluta - del titolo News & Features in un’unica stringa di testo, e il conseguente accorciamento del bordo di divisione tra i due elenchi di link che dipendono da quel titolo. Per il resto, la presentazione grafica prodotta dal foglio di stile corrisponde pienamente a quella prodotta dal codice di marcatura presentazionale del Listato 6.4.

Non si tratta di una grafica particolarmente accessibile, soprattutto per quanto riguarda la scelta dei colori, ma lo scopo di questo lavoro non è migliorare l’accessibilità visiva del documento preso a modello, quanto piuttosto mostrare la capacità dei fogli di stile di ricreare qualsiasi schema d’impaginazione fin nei più minuti dettagli.

Inizio pagina

Analisi delle soluzioni tecniche utilizzate nel CSS

Esaminiamo adesso il modo in cui il foglio di stile nel Listato 6.6 determina le principali caratteristiche di presentazione del documento mostrato in Figura 6.9.

Non perderemo tempo con le proprietà d’uso più semplice, come background-color o text-align, che servono per determinare il colore di sfondo di un elemento e l’allineamento del contenuto testuale. Vediamo, invece, come è stato ottenuto l’allineamento a destra della foto della grande quercia e come è stato ottenuto, parallelamente, che l’immagine-titolo e la frase descrittiva su tre righe siano allineate al centro, ma non rispetto alla finestra del browser, bensì rispetto allo spazio residuo, tolta la larghezza occupata dalla foto della quercia.

La foto è allineata a destra mediante l’uso combinato della proprietà position con valore absolute e della proprietà right. Il valore absolute sottrae l’oggetto dal flusso del documento. Ciò significa che la foto è stata spostata su un livello a parte, e altri oggetti, per esempio i testi, potrebbero finire sopra o sotto di essa, nascondendola o venendone nascosti.

Per evitare questa sovrapposizione, ai selettori h1 e #desc, che si riferiscono rispettivamente all’immagine con la scritta Sherwood Times e alla frase su tre righe, abbiamo applicato, mediante la proprietà margin, un margine destro di 284 pixel, sufficiente a impedire la sovrapposizione con la foto. L’applicazione di tale margine è anche la ragione per la quale l’allineamento al centro di questi due blocchi avviene, non rispetto all’intero spazio orizzontale della finestra del browser, ma rispetto allo spazio residuo, tolti appunto i 284 pixel del margine destro (e i 15 del margine sinistro).

Si noti che lo stesso effetto - foto allineata a destra e titolo e descrizione centrati nello spazio residuo - erano stati ottenuti, nel codice tag soup, per mezzo di una tabella d’impaginazione suddivisa in due celle. E così l’uso di tre soli selettori CSS (h1, #desc e #foto) ci ha permesso di eliminare la prima tabella d’impaginazione, conservando esattamente il medesimo aspetto grafico del blocco che essa conteneva.

Griglie d’impaginazione con DIV e float

La soluzione adottata per eliminare la successiva tabella d’impaginazione, quella suddivisa in tre colonne su sfondo grigio, è un po’ più complessa. In primo luogo, è stato creato nel codice di marcatura un contenitore, il DIV con id="principale", corrispondente allo spazio occupato dall’intera tabella. Poi è stato inserito un secondo DIV, con id="menu", corrispondente allo spazio occupato dal titolo News & Features, dai due elenchi di link e dalle due immagini decorative. Infine, è stato inserito un terzo DIV, con id="laterale", corrispondente alla colonna di destra introdotta dal titolo Supplement.

In condizioni normali, i DIV "menu" e "laterale", che sono elementi a livello di blocco, occuperebbero ciascuno l’intera larghezza della finestra del browser e sarebbero perciò visualizzati l’uno sotto l’altro. Come fare, invece, per ottenere che siano visualizzati affiancati, in modo da riprodurre la stessa impostazione grafica del blocco grigio in Figura 6.4? Uno dei metodi richiede l’uso della proprietà float. Questa proprietà, che è stata applicata al DIV con id="menu", può essere usata per posizionare un contenuto a sinistra o a destra rispetto agli altri contenuti del blocco contenitore (il DIV con id="principale"). Per posizionare a sinistra, si usa float:left; per posizionare a destra, float:right.

La differenza tra float e position (con valore absolute) è che, quando si usa float, gli altri contenuti si dispongono alla destra o alla sinistra del blocco fluttuante senza sovrapposizioni, o scivolano sotto, se lo spazio laterale non è sufficiente. Quando, invece, si usa position:absolute, sono possibili sovrapposizioni e, proprio per questo, non avviene lo scivolamento verso il basso in caso di spazio orizzontale insufficiente.

Nel nostro caso, se il blocco con id="menu", a cui è applicato float:left, lascia sufficiente spazio alla sua destra (e lo lascia, perché la larghezza di quel DIV è impostata, tramite la proprietà width, al 70% dello spazio orizzontale disponibile), il blocco successivo, quello con id="laterale", viene risucchiato in alto, comparendo affiancato al precedente nella visualizzazione grafica del documento.

Figura 6.10. L’immagine evidenzia i principali blocchi in cui è stata suddivisa la griglia d’impaginazione e il nome dei selettori CSS associati a ciascun blocco.

Tramite un analogo uso della proprietà float è stato risolto anche il problema dell’affiancamento dei due elenchi da otto collegamenti, posti sotto il titolo News & Features. Al primo elenco è stata applicata, tramite il selettore #elenco1, la proprietà float:left; al secondo elenco è stata applicata invece la proprietà float:right, per mezzo del selettore #elenco2. In tal modo i due elenchi si spostano rispettivamente a sinistra e a destra dello spazio orizzontale occupato dal DIV "menu", e rimangono così affiancati, finché la somma delle loro larghezze, margini compresi, risulta minore, complessivamente, dello spazio orizzontale occupato dal DIV progenitore.

Le soluzioni basate sull’uso della proprietà float sono comunissime nell’impaginazione con i fogli di stile e consentono di risolvere molti dei problemi di affiancamento dei contenuti che, nella codifica tradizionale, erano risolti con le tabelle d’impaginazione. La domanda che viene naturale è: perché ricorrere a un sistema che - inutile negarlo - è piuttosto complesso, fatto di DIV annidati e fluttuanti, quando le tabelle d’impaginazione sono in fondo più semplici da realizzare e più solide nel mantenere l’impaginazione desiderata?

Per una risposta dettagliata rimandiamo al paragrafo Perché usare i fogli di stile al posto di elementi e attributi di presentazione?, più sopra in questo capitolo. Al lettore attento non sarà sfuggita, però, la differenza tra le Figure 6.4 e 6.7: la seconda, con la sua linearità essenziale, dà un’idea di massima fruibilità dei contenuti. In un documento basato su codice di marcatura puramente strutturale, costruito senza tabelle d’impaginazione (o tableless, per usare un termine di moda), la presentazione - che può essere causa di inaccessibilità per le più diverse ragioni (colori, caratteri troppo piccoli ecc.) - diventa un fattore accessorio, da utilizzarsi oppure no, a seconda delle esigenze, grazie al collegamento con un CSS esterno.

Altre tecniche (immagini decorative usate come sfondo)

Tra le altre soluzioni tecniche adoperate nel CSS del Listato 6.6, è utile ricordare la proprietà line-height, usata nel selettore #desc. Lo scopo di tale proprietà è regolare l’interlinea, cioè lo spazio verticale tra le righe di testo di un blocco. Il valore di 200% imposta un’interlinea di altezza doppia rispetto a quella del carattere utilizzato. In tal modo è stato creato l’ampio spazio di separazione tra le tre righe della frase di presentazione inserita sotto il titolo Sherwood Times.

Questa e altre proprietà di regolazione fine degli spazi di separazione interni e esterni ai blocchi di contenuti (per esempio margin e padding) dimostrano la notevole superiorità dei fogli di stile rispetto al codice di marcatura presentazionale. In molti casi, l’unico modo per ottenere una distanza tra oggetti precisa al pixel, lavorando con il codice di marcatura invece che con i fogli di stile, passa per l’inserimento di immagini spaziatrici trasparenti all’interno di complicate griglie d’impaginazione basate su tabelle: uno stratagemma che i fogli di stile consentono di evitare quasi in ogni circostanza.

Da notare, ancora, l’uso della proprietà list-style-type con valore none. Applicata alle liste non ordinate (elementi UL), cancella il “pallino” nero che i browser pongono in modo predefinito alla sinistra di ogni punto elenco.

Sempre a proposito degli elenchi, è da segnalare il metodo con cui sono state inserite le due immagini decorative. Per prima cosa, è stato aggiunto uno spazio verticale alla fine di ciascun elenco per mezzo della proprietà padding, i cui quattro valori (0 10px 126px 10px) si riferiscono rispettivamente alla parte superiore, destra, inferiore e sinistra del relativo blocco. Lo spazio inferiore creato è, dunque, di 126 pixel.

In questo spazio viene inserita l’immagine decorativa, usando tre proprietà: background-image, che specifica il nome del file immagine che deve essere caricato; background-repeat, che definisce se l’immagine deve essere ripetuta in orizzontale e/o in verticale (nel qual caso creerà un motivo di riempimento del blocco) oppure no; infine background-position, che definisce la posizione in cui apparirà. Il valore no-repeat della proprietà background-repeat dice al browser che l’immagine non deve essere ripetuta, mentre il valore center bottom della proprietà background-position dice che deve comparire in basso al centro, rispetto a ciascuno dei blocchi modificati dal selettore #menu ul (cioè i due elenchi di otto collegamenti).

Generalizzare o restringere il campo d’applicazione degli stili

Una caratteristica importante dei CSS2 è la possibilità di allargare o restringere il campo di applicazione di una proprietà di stile a seconda delle esigenze. Ciò consente di ottenere tutta la varietà di stili necessaria, usando il minimo numero possibile di definizioni. Se definiamo un insieme di stili per il selettore UL, gli stili saranno applicati a tutti gli elementi UL presenti nel codice di marcatura del documento associato. Ciò accade per esempio, nel Listato 6.6, con la proprietà list-style-type, per la quale il valore none viene applicato a tutti gli elenchi del documento.

Ci sono però, nel nostro caso, delle proprietà che devono essere applicate solo agli elementi UL che si trovano all’interno del DIV con id="menu". Per restringere, allora, il campo d’applicazione degli stili ai soli elementi UL interni a questo DIV, usiamo il selettore #menu ul. Un selettore composto come il precedente dice al browser, traducendo in termini umani: “applica i valori delle mie proprietà di stile solo ed esclusivamente agli elementi UL interni all’elemento con id="menu"”.

Si possono raggiungere livelli di specificità ancora maggiori. Per applicare selettivamente degli stili o solo al primo o solo al secondo degli elenchi presenti nel DIV "menu", sono stati associati nel codice di marcatura ai due elementi UL gli id "elenco1" e "elenco2". Usando, a questo punto, i selettori #elenco1 e #elenco2 nel foglio di stile collegato, è possibile definire un’immagine decorativa differente per ciascuno dei due elenchi nonché allineamenti differenti, a sinistra per il primo elenco e a destra per il secondo, impostati per mezzo dei valori left e right della proprietà float.

Tutte le regole per definire i selettori e le precedenze nell’applicazione degli stili sono descritte nei capitoli 5 e 6 delle Specifiche CSS2, rispettivamente alle pagine http://www.w3.org/TR/CSS2/selector.html e http://www.w3.org/TR/CSS2/cascade.html .

Inizio pagina

Punto di controllo 3.4, priorità 2

Unità di misura relative e assolute

Le unità di misura relative, quali em e ex, e i valori percentuali (70%, 80% ecc.) consentono agli sviluppatori di impostare testi ridimensionabili e layout liquidi, che hanno la proprietà di adattare i contenuti, nei limiti del possibile, alla larghezza della finestra del browser.

È da notare che le specifiche CSS inseriscono tra le unità relative anche i px (si veda http://www.w3.org/TR/CSS2/syndata.html#length-units ), il che crea alcuni problemi per l’accessibilità. L’unità di misura px (pixel) è infatti relativa, ma rispetto alla dimensione del monitor e rispetto alla risoluzione impostata dall’utente. È relativa, cioè, in un senso diverso rispetto a em e ex, che sono unità di misura relative rispetto alla grandezza dei caratteri definita in un documento. In altre parole, definire le grandezze in px vuol dire bloccarle a una dimensione fissa, condizionata dalla grandezza del monitor che si sta usando e dalla risoluzione impostata: proprio ciò che il punto di controllo 3.4 intende evitare.

Purtroppo, nelle WCAG 1.0, e anche nel documento di Tecniche CSS per le WCAG 1.0, manca qualsiasi riferimento a questo problema, sicché un’interpretazione legalistica del punto di controllo 3.3 potrebbe portare alla realizzazione di pagine contenenti oggetti dalle dimensioni non scalabili, con un certo pregiudizio per l’accessibilità (Internet Explorer, per esempio, non permette di ingrandire i caratteri le cui dimensioni sono definite in px nel foglio di stile). Spetta allora agli sviluppatori evitare di usare i px per dimensionare blocchi e caratteri, tranne che nei casi in cui si è certi che ciò non arrechi pregiudizio alla fruibilità dei contenuti in nessuna condizione d’uso.

Nel foglio di stile presentato nel Listato 6.6, per esempio, sono stati utilizzati i px per definire il margine destro dei selettori h1 e #desc: ciò perché l’oggetto da coprire con quel margine è un’immagine di grandezza fissa. Non c’è bisogno, cioè, di creare un margine ridimensionabile e perciò l’uso dei px in un simile caso non pregiudica l’accessibilità. Diverso è il caso dei testi usati come intestazione in quello stesso listato: gli elementi H2 e H3 sono stati impostati, nel CSS, con grandezze percentuali rispettivamente del 120% e del 110%, in modo da risultare ingrandibili anche in browser come Internet Explorer.

È possibile impostare unità di misura anche all’interno del codice di marcatura HTML e XHTML. Le unità di misura disponibili sono in questo caso solo i pixel e le percentuali. Se nei valori di attributo si scrive un numero e null’altro, si intende che la dimensione è specificata in pixel; se il numero è seguito dal segno %, allora la dimensione è espressa in percentuale.

In generale, è preferibile usare i fogli di stile per definire le grandezze dei contenuti, piuttosto che gli attributi di altezza e larghezza degli elementi nel codice di marcatura. Fanno eccezione gli elementi rimpiazzati, come immagini e oggetti di programmazione, che hanno di solito una dimensione fissa, che è preferibile specificare tramite codice di marcatura. Ciò permette, infatti, al browser di riservare fin da subito lo spazio assegnato a tali oggetti durante il caricamento progressivo del documento, prima che gli oggetti stessi siano caricati.

Inizio pagina

Punto di controllo 3.5, priorità 2

Uso semantico degli elementi H1-H6

Gli elementi da H1 a H6 sono fondamentali per l’accessibilità. Permettono infatti di stabilire la gerarchia reciproca dei contenuti di un documento e sono utili soprattutto per chi naviga con un sintetizzatore vocale. Il punto di controllo 3.5 invita gli sviluppatori a non usare la formattazione come unico strumento per creare un titolo e, parallelamente, a non usare gli elementi da H1 a H6 per creare effetti grafici su testi che non sono semanticamente titoli. In altre parole, a ciò che appare in modalità grafica come intestazione deve corrispondere nel codice di marcatura un elemento H1-H6 appropriato, altrimenti la struttura sarà invisibile o, peggio, apparirà fuorviante per chiunque legga il documento in modalità non grafica.

Oltre gli esempi riportati di seguito, si può consultare il Listato 6.4, che contiene un uso improprio della formattazione per simulare graficamente l’aspetto di titoli, e poi il Listato 6.5, in cui gli stessi contenuti sono invece marcati correttamente come intestazioni.

Ecco ora due esempi scorretti. Il primo fa uso dei fogli di stile, il che è giusto, ma li usa in un modo semanticamente sbagliato: li usa, cioè, per ottenere l’effetto grafico di un’intestazione, senza che le parole che ne fanno parte siano marcate con l’opportuno elemento H1-H6. Il secondo è invece un classico esempio di tag soup, in cui la struttura è applicata in modo del tutto esteriore, per mezzo di elementi e attributi deprecati.

La Figura 6.11 A mostra la rappresentazione in un browser grafico del codice di marcatura dei tre listati precedenti. Come si può vedere, sia l’esempio corretto (il primo dall’alto) sia i due scorretti producono esattamente lo stesso risultato visivo. Se i contenuti da marcare fossero destinati esclusivamente a una visualizzazione grafica, sarebbe pressoché indifferente usare l’uno o l’altro dei tre metodi per creare qualcosa che abbia l’aspetto di un titolo. Ma, come sappiamo, l’accessibilità ha per scopo di fornire contenuti che conservino significato e struttura qualsiasi sia il dispositivo su cui vengono riprodotti. Basta, allora, riprodurre il codice dei tre listati su un browser testuale (Figura 6.11 B), per scoprire che l’unico codice che produce la struttura di un titolo, individuabile come tale anche con uno screen reader, è quello del Listato 6.12, in cui il testo “4.3.2 Lunghezze” è marcato con l’elemento strutturale H3.

Sull’uso degli elementi H1 – H6 per strutturare in modo appropriato un testo discorsivo, si veda “Organizzare i testi per titoli e paragrafi”, nel Capitolo 17.

Figura 6.11. Riproduzione in modalità grafica (A) e testuale (B) dei Listati 6.12, 6.13 e 6.14. Si noti che in modalità testuale solo il primo dei tre titoli viene trattato come tale.

Inizio pagina

Punto di controllo 3.6, priorità 2

Contatori per elenchi annidati

Nella sezione 4 Lists delle Tecniche HTML per le WCAG 1.0, dopo la “solita” raccomandazione, simile a quella fatta per altri elementi strutturali, di non usare le liste per soli scopi di formattazione (per esempio per ottenere un testo rientrato), segue un’interessante considerazione:

Gli elenchi ordinati aiutano gli utenti non-visuali nella navigazione. Gli utenti non-visuali possono “sentirsi persi” all’interno degli elenchi, specialmente in quelli annidati e in quelli che non indicano il preciso livello di annidamento di ciascun elemento della lista. Finché i programmi utente non forniranno strumenti per identificare chiaramente il contesto di un elenco (per esempio, supportando lo pseudo-elemento :before nei CSS2), gli sviluppatori di contenuti dovrebbero includere nei loro elenchi indicazioni contestuali.

Per le liste numerate, i numeri composti sono più informativi dei numeri semplici. Così, una lista numerata “1, 1.1, 1.2, 1.3, 2, 2.1” fornisce più contesto rispetto alla medesima lista senza numeri composti, che potrebbe essere formattata come segue:

1.

  1.

  2.

    1.

  3.

2.

  1.

e sarebbe pronunciata come “1, 1, 2, 1, 2, 3, 2, 1”, non fornendo alcuna informazione circa la profondità della lista.

Il suggerimento è condivisibile ed esistono anche gli strumenti, con i fogli di stile, per applicarlo. Il paragrafo 12.5 delle Specifiche CSS2 (Automatic Counters and Numbering ) spiega come impostare dei contatori automatici, utilizzabili non solo per le liste, ma per qualsiasi elemento che si presti a contenere enumerazioni, come titoli, paragrafi ecc. Il sistema si basa sull’uso combinato di tre proprietà CSS:

• content, che, tramite le funzioni counter() e counters(), definisce il nome del contatore, lo stile di numerazione e le eventuali stringhe di separazione tra numeri composti;
• counter-increment, che definisce il tasso d’incremento (o di decremento) del contatore;
• counter-reset, che reimposta il contatore, facendolo partire, o ripartire, da un dato valore.

La differenza tra counter() e counters() è molto importante: la prima funzione agisce su tutti gli elementi a cui si applica, senza distinzioni; la seconda, invece, considera il livello di annidamento e consente perciò di creare il tipo di numeri composti, a cui faceva riferimento il brano delle Tecniche CSS citato poco sopra.

Un esempio, come sempre, aiuterà a chiarire il funzionamento del meccanismo. Consideriamo il Listato 6.15, che riporta un frammento di codice di marcatura corrispondente al sommario del primo capitolo delle Specifiche HTML 4.01 in traduzione italiana .

Come si può notare scorrendo il codice di marcatura, negli attributi href è presente, alla fine, una numerazione composta (“1.1, 1.2, 1.2.1” ecc.) che tiene conto dell’esatta gerarchia degli argomenti. Purtroppo questa gerarchia si perde completamente nella rappresentazione del sommario in un browser grafico (Figura 6.12), perché gli elementi OL, se non sono modificati da appositi stili, producono una numerazione semplice.

Figura 6.12. La rappresentazione in un browser grafico del codice nel Listato 6.15.

Se, però, colleghiamo al codice gli stili riportati nel listato seguente, riusciamo - purché supportati da un browser conforme - a riprodurre esattamente la gerarchia del sommario, con tutti i numeri composti che servono.

Ecco come appare ora il sommario, dopo aver applicato gli stili associati ai due selettori ol e li:before (Figura 6.13).

Figura 6.13. Effetto dell’applicazione degli stili nel Listato 6.16 al codice del Listato 6.15 in un browser grafico conforme.

Le proprietà counter-increment, counter-reset e content agiscono su un oggetto comune, il contatore denominato gerarchia. Si noti che l’uso della proprietà list-style-type con valore none è necessario per cancellare i contatori predefiniti, visibili in Figura 6.12 (avremmo ottenuto lo stesso scopo anche impostando al valore block la proprietà display per l’elemento LI): senza un simile accorgimento, sarebbero state visualizzate, affiancate, entrambe le numerazioni: quella di Figura 6.12 e quella di Figura 6.13.

Il punto di separazione tra i numeri composti è prodotto dall’aggiunta del carattere "." al nome del contatore, nel valore della proprietà content. La proprietà padding-right inserisce 5 pixel di spaziatura tra i numeri e l’inizio del testo di ciascun collegamento, mentre la proprietà font-weight:bold fa apparire i numeri in grassetto.

Ai fini del buon funzionamento di questo meccanismo, è necessario che il browser adoperato supporti correttamente gli pseudo-elementi :before e :after (o almeno il primo), che servono per produrre dei contenuti, detti “generati”, che è possibile far comparire in un documento insieme ai normali contenuti inseriti nel cod