GoogleRank il portale gratuito che cercavi!

Home / I consigli di GoogleRank / Validazione del codice

GoogleRank

Validazione del codice

Validazione del codice

La validazione del codice (X)HTML e CSS
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). La situazione oggi è migliorata ora otteniamo 390 errori di codice (prova eseguita il 11/10/2006)!

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 ("What you see is what you get", cioè "ciò che vedi è quello che ottieni": sigla inglese che definisce i programmi come DreamWeaver, FrontPage e GoLive, che consentono all'utente di comporre una pagina web lavorando sull'aspetto grafico della composizione piuttosto che sul sottostante codice HTML).

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:

  1. elementi aperti e non chiusi o viceversa

  2. elementi incastrati invece che annidati (p.es. <b><i> ... </b></i>, invece di <b><i> ... </i></b>)

  3. 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)

  4. uso del carattere '&' in una stringa di query (va sostituito con l'entità carattere '&amp;')

  5. uso di valori di attributo non consentiti

  6. 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!

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:

  1. fornendo l'URI del documento da validare (il file CSS o anche il file HTML a cui il CSS è associato)

  2. inserendo il codice CSS all'interno di un apposito campo modulo

  3. 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:

  1. mancanza del punto e virgola finale che chiude la dichiarazione di una proprietà

  2. mancanza della parentesi graffa che chiude un elenco di proprietà

  3. un colore dichiarato in valori esadecimali non preceduti dal simbolo '#'

  4. 'sans-serif' (famiglia generica di caratteri senza le grazie) scritto senza il trattino separatore

  5. nomi di classe e id non validi

  6. 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.

Tra i "warning" più frequenti, ce ne sono tre in particolare di cui è utile tenere conto:

  1. la mancata indicazione di una famiglia di caratteri generica

  2. la mancata definizione del colore di primo piano se è stato definito il colore di sfondo, e viceversa

  3. 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.

Le grazie sono abbellimenti simili a svolazzi, agganciati solitamente agli spigoli dei caratteri.

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.

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.

I consigli di GoogleRank:

Dalla validazione di W3C si possono ottenere questi pulsanti da inserire nelle pagine validate.

 

GoogleRank XHTML

 

 

GoogleRank HTML

 

 

GoogleRank CSS