[Salta il menu]

Diodati.org | Accessibilità e traduzioni dal W3C      Leggi Omega Centauri!

Realizzare siti ad elevata accessibilità richiede innanzitutto che si usi codice (X)HTML e CSS valido, ovvero scritto nel rispetto dei relativi standard definiti dal W3C.

Per quanto riguarda (X)HTML, una pagina è valida se e soltanto se:

1. al suo inizio è dichiarata la DTD utilizzata nel documento;
2. gli elementi e gli attributi adoperati rispettano alla lettera la sintassi per loro definita nella DTD dichiarata all'inizio.

Il controllo della validità del codice (X)HTML per fortuna può essere effettuato automaticamente, ricorrendo ad appositi software, come il "MarkUp Validation Service" presente sul sito W3C.

Questo fondamentale controllo di validità del codice è purtroppo del tutto trascurato dalla gran massa degli sviluppatori, anche per i siti più importanti. Se proviamo, ad esempio, a far analizzare al validatore automatico del W3C la prima pagina di Repubblica.it otteniamo qualcosa come 757 errori di codice (prova eseguita il 3/9/2003)!

Figura 7 - L'analisi della prima pagina di Repubblica.it evidenzia ben 757 errori di codice HTML!

E' chiaro che per costruire pagine valide occorre conoscere i "ferri" del mestiere, ovvero saper lavorare all'occorrenza direttamente sul codice della pagina, tralasciando gli aiuti visuali offerti dai cosiddetti programmi WYSIWYG.

Nel correggere gli errori di codice, il validatore del W3C fornisce però un discreto aiuto: indica allo sviluppatore la riga del listato della pagina dove è presente l'errore e descrive il tipo di errore. Quest'ultimo ausilio è utile però solo nella misura in cui si conosca già a sufficienza la sintassi di (X)HTML, tanto da saper riconoscere e risolvere il problema.

Tuttavia non è difficile imparare. La maggior parte degli errori riscontrati dal validatore riguardano:

• elementi aperti e non chiusi o viceversa
• elementi incastrati invece che annidati (p.es. <b><i> ... </b></i>, invece di <b><i> ... </i></b>)
• uso di elementi e attributi non consentiti dalla DTD adoperata (problema che si verifica tipicamente quando si inseriscono nel codice elementi e attributi di presentazione dopo aver dichiarato la DTD rigorosa, che non li prevede)
• uso del carattere '&' in una stringa di query (va sostituito con l'entità carattere '&amp;')
• uso di valori di attributo non consentiti
• DTD non dichiarata

Consigliamo vivamente agli autori interessati a sviluppare risorse accessibili di correggere tutti gli errori di sintassi (X)HTML riscontrati dal validatore del W3C, prima di rendere pubbliche ufficialmente le loro pagine. Non è detto che un errore nel codice pregiudichi l'accessibilità di un documento, ma un codice sciatto è comunque un cattivo biglietto da visita per un lavoro che pretenda di essere ben fatto. Prima di mettere il tetto su una casa, è necessario aver piantato delle fondamenta solide: scrivere pagine (X)HTML prive di errori equivale sicuramente ad aver messo delle buone fondamenta!

Figura 8 - L'icona mostrata dal validatore W3C al termine dell'analisi di una pagina XHTML 1.0 riscontrata valida. L'autore della pagina può esporre a sua discrezione questo bollino, per dichiarare pubblicamente la conformità della risorsa alla sintassi di XHTML 1.0

Una volta riscontrata la conformità del codice alla DTD di HTML o XHTML dichiarata ad inizio pagina, il passo successivo è convalidare il codice CSS usato nei fogli di stile interni o esterni associati alla pagina. Anche per questo riscontro, esiste un apposito software sviluppato dal W3C: CSS Validator. La validazione dei fogli di stile può essere effettuata in tre modi:

• fornendo l'URI del documento da validare (il file CSS o anche il file HTML a cui il CSS è associato)
• inserendo il codice CSS all'interno di un apposito campo modulo
• spedendo sul sito W3C il file da analizzare.

Quale che sia il metodo scelto, il funzionamento del programma è analogo a quello del validatore di codice (X)HTML: se vengono riscontrati errori, viene fornito un elenco contenente la riga di codice e il tipo di errore. Gli errori più comuni a cui occorre porre rimedio sono i seguenti:

• mancanza del punto e virgola finale che chiude la dichiarazione di una proprietà
• mancanza della parentesi graffa che chiude un elenco di proprietà
• un colore dichiarato in valori esadecimali non preceduti dal simbolo '#'
• 'sans-serif' (famiglia generica di caratteri senza le grazie) scritto senza il trattino separatore
• nomi di classe e id non validi
• un commento (/* ... */) aperto e non chiuso, o viceversa

A differenza del validatore per HTML e XHTML, il validatore CSS fornisce, oltre la lista degli errori, anche una lista di avvertimenti ("warnings", in inglese): si tratta di suggerimenti che aiutano a migliorare l'accessibilità dei documenti, dunque consigliamo agli sviluppatori di risolvere anche i problemi segnalati da questi avvisi, non solo gli errori di sintassi veri e propri. L'ideale è ottenere dei CSS che al termine dell'analisi del validatore W3C risultino privi sia di errori sia di avvertimenti.

CSS Check, presente sul sito WDG Web Design Group e analogo al CSS Validator, fornisce avvertimenti ancora più dettagliati (ha però il limite di non supportare adeguatamente le nuove proprietà introdotte dalle specifiche CSS2 rispetto alle precedenti specifiche CSS1). Tra i "warning" più frequenti, ce ne sono tre in particolare di cui è utile tenere conto:

• la mancata indicazione di una famiglia di caratteri generica
• la mancata definizione del colore di primo piano se è stato definito il colore di sfondo, e viceversa
• l'uso di dimensionamenti fissi in luogo di quelli relativi e percentuali

Il primo avvertimento suggerisce di inserire, a seconda dei casi, una famiglia di caratteri generica tra i valori della proprietà font-family. Le scelte possibili sono cinque: serif, sans-serif, cursive, fantasy, monospace. Uno dei casi in cui capita di ricevere questo avviso dal validatore dei CSS è quando si precisa un tipo di carattere con grazie o senza grazie, senza indicare 'serif' o 'sans-serif' come ultima scelta della proprietà font-family. Se abbiamo per esempio lo stile:

body, p {font-family: arial, helvetica}

l'avviso del validatore ci induce a modificarlo così:

body, p {font-family: arial, helvetica, sans-serif}

Analogamente, se abbiamo:

body, p {font-family: georgia, times}

è consigliabile modificare in:

body, p {font-family: georgia, times, serif}

Tale sistema consente al browser, in caso di mancanza sul computer dell'utente dei caratteri indicati specificamente dal CSS (Georgia, Times, Arial, ecc.), di utilizzare un carattere sostitutivo generico - con grazie (serif) o senza grazie (sans-serif) a seconda di ciò che l'autore del CSS ha indicato - che possa sostituire con la migliore approssimazione il tipo di carattere mancante. Cogliamo l'occasione per ricordare che, ai fini dell'accessibilità, i caratteri senza grazie (detti anche "a bastone") come Arial, Helvetica e Verdana risultano di gran lunga più leggibili dei caratteri con grazie.

Il secondo avvertimento importante per l'accessibilità è quello che compare quando per un oggetto della pagina è definito il colore di primo piano e non quello di sfondo, e viceversa. La ragione per cui è importante che siano definiti entrambi i colori è che un utente potrebbe sostituire una combinazione di colori personalizzata a quella predefinita del browser o del sistema operativo. Ciò potrebbe portare, nel caso in cui nel CSS sia definito per esempio solo il colore dello sfondo di un blocco e non quello del testo, ad avere una combinazione primo piano/sfondo del tutto illeggibile, basata sul colore di sfondo definito nel CSS e sul colore di primo piano definito dallo stile personalizzato usato dall'utente.

Poiché in questo caso la sola descrizione del fenomeno non rende bene l'idea, vediamo un'applicazione concreta di ciò che abbiamo appena descritto. L'esempio è tratto da Glish.com, un sito molto famoso per quanto riguarda la divulgazione di tecniche sull'uso dei CSS... a dimostrazione che anche i migliori qualche volta possono sbagliare (se poi l'effetto è voluto, non se ne capisce davvero l'utilità).

Figure 9 e 10 - La prima immagine mostra il campo modulo che contiene il codice HTML della pagina http://www.glish.com/css, vista con Mozilla 1.3 su un PC che usa la combinazione di colori predefinita ("Windows classico") di Windows 2000 Pro. La seconda immagine mostra la stessa porzione di pagina vista con lo stesso browser, ma dopo aver impostato in Windows una diversa combinazione di colori, chiamata "contrasto elevato 2". Come si può notare facilmente, il testo nel campo modulo appare nel secondo caso molto meno leggibile a causa dello scarso contrasto tra colori di primo piano e di sfondo

Vediamo la causa diretta di questa scarsa leggibilità del testo, che si verifica cambiando la combinazione di colori del sistema operativo. Ecco come è definito lo stile del campo modulo che contiene il testo poco leggibile mostrato in figura 10:

<textarea style="background:#fff; margin:5%; height:500px; width:89%; overflow:scroll">

Come vedete, è definito solo il colore di sfondo: #fff, cioè bianco. Questo è il motivo per cui, una volta impostata la combinazione di colori a contrasto elevato - che prevede il verde chiaro come colore di primo piano ed il nero come colore di sfondo - il browser sovrascrive con il bianco definito nello stile in linea il colore di sfondo, ma lascia invariato il colore di primo piano della combinazione utilizzata dall'utente, creando l'infelice combinazione di verde su bianco mostrata nell'immagine. Tra l'altro l'uso dello stile di Windows a contrasto elevato non è rarissimo: per gli ipovedenti è infatti di solito più rilassante leggere un testo chiaro su uno sfondo scuro piuttosto che il contrario.

Il problema di leggibilità sarebbe stato evitato o non impostando neppure il colore di sfondo (nel qual caso l'utente avrebbe letto bene il testo verde sullo sfondo nero) o impostando anche il colore di primo piano, nel modo seguente:

<textarea style="background:#fff; color:#000; margin:5%; height:500px; width:89%; overflow:scroll">

Dovrebbe essere chiara per tutti, a questo punto, l'utilità dell'avviso del validatore, quando avverte della mancanza del colore di primo piano o di sfondo all'interno di una definizione di stile!

Il terzo tipo di avvertimento importante per l'accessibilità riguarda l'uso di dimensioni fisse piuttosto che relative. Si riceve questo avviso quando impostiamo nel CSS delle misure in punti (pt), centimetri (cm), millimetri (mm), pica (pc) o pollici (in), ovvero le misure di lunghezza assolute definite dalle specifiche CSS2.

Lo scopo dell'avvertimento, che è in linea con il suggerimento contenuto nel punto di controllo 3.4 delle WCAG 1.0, è quello di indurre gli autori ad usare le misure relative - em, ex e px (pixel) - o le misure percentuali (p.es. 120%) al posto di quelle assolute. In tal modo si evita di creare vincoli di presentazione, che possano ostacolare la fruizione della pagina da parte di utenti che hanno impostazioni di monitor o stampante differenti da quelle previste dall'autore della pagina.

Figura 11 - L'icona ed il messaggio mostrati dal programma CSS Validator del W3C al termine dell'analisi di un file CSS che è risultato privo sia di errori sia di messaggi di avvertimento. L'autore della pagina può esporre a sua discrezione questo bollino, per dichiarare pubblicamente la conformità della risorsa alla sintassi dei fogli di stile CSS