Questo documento è una traduzione in lingua italiana del'articolo W3C QA:
"My Web site is standard! And yours?".
Questo documento può contenere errori di traduzione. L'unica versione valida è l'originale inglese.
Traduzione di Maurizio Vittoria <vittoria@marciana.venezia.sbn.it>.
Introduzione· Gli Standard· Convalida· Strumenti·
QA Homepage· Ultime Notizie· QA Risorse· QA IG· QA WG· Calendario QA
Questo articolo è un prodotto di lavoro del W3C Quality Assurance Interest Group.
Vogliate inviare ogni commento pubblico alla lista di distribuzione public-evangelist@w3.org, i cui archivi sono pubblici o, per un commento privato, a karl@w3.org. L'autore
ringrazia le persone che hanno usato il loro tempo per le revisioni o per qualche idea.
Troverete qui delle facili tecniche e delle idee per migliorare la qualità del vostro sito Web e per renderlo valido senza sforzo. Questo documento è destinato agli utilizzatori di HTML, agli sviluppatori che lavorano su applicazioni per il Web e ai webmaster.
La maggior parte dei siti Web non sono validi. Si può stimare che si tratti del 99% delle pagine Web, ma non esiste alcuna statistica per confermarlo. Sarebbe interessante lanciare un sondaggio al fine di provare se è veramente così.
Perchè?
Ho sentito molti commenti e proposte su questo argomento. La maggior parte di essi sono spesso la conseguenza di una mancanza di conoscenza e di comprensione di cos'è la validazione HTML. Eccone qualcuno:
Steve, capo esecutivo, dice: "Se il mio sito Web fosse costruito secondo gli standard, non sarebbe interessante e perderei clienti."
Con gli standard del W3C, voi potrete arrivare lo stesso a fare dei siti che attirino l'attenzione. La creazione di un sito Web che rispetti gli standard non ha niente a che vedere
con la generazione di pagine Web in solo testo.
Il W3C sta attualmente proponendo un insieme di tecnologie integrate molto interessanti. Voi potete fare l'esperienza di un sito Web completamente multimediale con le
esistenti tecnologie interoperabili del W3C utilizzando i linguaggi XHTML (Markup XML strutturato), CSS (Fogli di Stile), SVG (Grafici Vettoriali animati in due dimensioni), e SMIL (Multimedia Sincronizzati). Queste tecnologie sono state elaborate partendo dal consenso pervenuto da diversi attori sul mercato
del Web.
Alan, direttore tecnico, dice : "Non ho le risorse finanziarie per occuparmi di standard nel mio sito Web. Mi costerebbe troppo caro!"
Disegnare siti Web con gli standard semplificherà la manutenzione del codice perchè non vi saranno versioni multiple per i differenti browser. Le vostre pagine avranno una
vita più lunga e non saranno dipendenti da tecnologie effimere. Così, in definitiva, disegnando con gli standard Web i costi vi diminuiranno.
Dean, direttore artistico, dice: Se rispetto gli standard, questo nuocerà alla mia creatività.
Dei vincoli tecnici riguardano tutti i supporti artistici, sia che voi stiate disegnando, sia che stiate scolpendo, o stiate creando delle pagine Web. L'acquerello o la
pittura ad olio hanno i propri vincoli, ma queste tecniche non bloccano la creatività; al contrario, forniscono una struttura per l'espressione della creatività
stessa.
Creare delle pagine Web con gli standard farà scoprire un nuovo mondo con delle tecniche adattate ad un media, alla tecnologia e ad un pubblico. C'è ancora molto da scoprire in questo campo. Noi stiamo solo ora cominciando ad esplorare i vantaggi delle esperienze multimediali basate sugli standard.
Claudia, grafico, dice: L'accessibilità non mi interessa. I disabili non fanno parte dei miei utenti abituali.
Voi potrete trarre vantaggio da un design che tenga conto dell'accessibilità . Le persone con disabilità
rappresentano l' 8% - 10% della popolazione. E' più facile mantenere un sito Web che segua delle linee guida per l'accessibilità (e dunque gli standard del Web). Le
visite al vostro sito Web aumenteranno, e una maggiore varietà di browser avranno accesso al contenuto del sito.
In alcuni stati, l'accessibilità è richiesta per legge, come in Australia Disability Discrimination Act Advisory Notes , Versione 3.1, maggio 1999) o negli Stati Uniti d'America (Section 508 - Web-based Intranet and Internet Information and Applications) o in Europa, che sta lavorando ad un obiettivo simile (e-accessibility).
Aminata, programmatore Web, dice: "Perchè dovrei obbedire agli standard? Il Web è uno spazio libero"
Il Web è uno spazio libero, popolato da numerosi utenti, di cui non necessariamente si conoscono tutti i bisogni. Gli standard sono stati concepiti tenendo conto di tutto il
pubblico potenziale. Creare siti Web usando gli standard è una sfida per tutta la comunità Web. Non sarete prigionieri di alcuna ditta, nè di alcuna tecnologia
proprietaria. Potrete usare delle tecnologie indipendenti da ogni piattaforma.
Karl, sviluppatore Web, dice: Io ho semplicemente seguito le istruzioni dei libri.
Purtroppo molti libri non insegnano una buona programmazione Web. Quando state creando un sito Web, dovreste verificare l'esattezza del vostro codice. Se siete sviluppatori Web, state attenti nell'usare dei libri per sviluppare la vostra applicazione e leggete le specifiche particolari che state provando a mettere in opera.
Alcuni siti Web riuniscono dei materiali utili per aiutare le persone a disegnare siti Web conformi agli standard del W3C. Nel sito Web del W3C potrete trovare una lista di lezioni, in crescita che incoraggia le buone pratiche.
Alcune persone del W3C hanno sviluppato del software liberamente accessibile per il vostro uso personale. Noi vi incoraggiamo ad usarli, quando è possibile. Questi pacchetti di software mettono in opera le tecnologie del W3C.
Tim, ragioniere, dice: Il mio editor di pagine Web genera un codice non valido
Molti strumenti per creare pagine Web non producono del codice valido. Alcuni hanno al loro interno dei verificatori di sintassi, altri operano in modo corretto, però molti non
generano del codice valido. Come soluzione intermedia dovrete verificare le vostra pagina Web con l'aiuto di un Validatore HTML. Nello stesso
tempo contattate chi ha fatto il programma (per e-mail, per telefono, per lettera) e spiegategli la situazione. Se chiedete loro di farlo, le ditte prenderanno le misure necessarie.
Valeria, sviluppatrice di contenuti Web, dice: Non è colpa mia. E' a causa di come è concepito il generatore di modelli delle pagine Web. (Spesso un sistema con una
interfaccia Web).
Avete ragione. Spesso non è colpa vostra. Se si tratta di un semplice modulo nel quale non scrivete mai del codice HTML a mano, ditelo allo sviluppatore della vostra interfaccia o
a chi mantiene il sito, fino a quando il problema non sarà risolto. Se non siete sicuri che il contenuto prodotto rispetti gli standard del W3C, effettuate una verifica del
contenuto con il Validatore HTML, e inviate il rapporto prodotto al vostro webmaster o a alla persona responsabile del programma di gestione
del contenuto [Content Management System (CMS)].
Ning, sviluppatore di software, dice: Non ci sono informazioni che possano aiutarmi. Tutto il materiale che ho trovato è in Inglese
Alcune persone hanno tradotto dei documenti e delle specifiche in altre lingue. Il W3C mantiene una lista delle traduzioni.
L'HTML si è evoluto nel corso del suoi sviluppi ed è disponibile in molte versioni. Tutte queste versioni sono degli standard, e potete sceglierne una che
più serva ai vostri bisogni. Nella maggior parte dei casi l'ultima versione costituirà la scelta migliore, a meno che voi non abbiate degli utenti molto particolari o dei
browser molto obsoleti. La versione che scieglierete determinerà gli elementi e gli attributi che potrete utilizzare.
Per esempio, nell'HTML 4.01, potrete trovare la lista degli elementi e la lista degli attributi che potrete usere nelle vostre pagine. Potete creare le vostre pagine manualmente, e questo abitualmente viene definito come "codice a mano" o "scrivere il sorgente".
L'HTML 4.01 vi permette di scrivere un paragrafo e un identificatore di ancora, come questo:
<p id="ref">Questo è un paragrafo</p>
Fate attenzione all'annidamento dei vostri elementi. Alcuni elementi non possono essere inclusi in altri, e alcuni attributi appartengono soltanto a certi elementi.
Gli elementi che potete usare nel vostro documento o implementare nel vostro software dipendono dalla versione dell'HTML. Questa tabella contiene una lista delle definizioni HTML, o tipi di
documento (DOCTYPEs), che potete usare:
| Versione |
Lista dei DTD |
Dichiarazione DOCTYPE nei documenti |
|---|---|---|
| HTML 2.0 | DTD |
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN"> |
| HTML 3.2 | DTD |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
| HTML 4.01 | Strict, Transitional, Frameset |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" |
| XHTML 1.0 | Strict, Transitional, Frameset |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" |
| XHTML 1.1 | DTD |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" |
Non potrete validare il vostro documento se non userete uno di questi DOCTYPEs all'inizio del documento. Non lo dimenticate, quando scrivete i vostri documenti a mano.
Ecco un esempio di modello di un documento XHTML 1.0 Strict:
<?xml version="1.0" encoding="utf-8"?>
<!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 modello standard di XHTML 1.0 Strict</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
</head>
<body>
... Qui il vostro contenuto HTML ...
</body>
</html>
Un modello XHTML Strict è molto semplice da creare. La modifica e la convalida del documento sono facili e dirette.
Un validatore HTML verifica semplicemente l'esattezza del vostro documento, in rapporto al DOCTYPE dichiarato.
Se desiderate verificare la validità del documento finale quando è mostrato attraverso un programma utente (per esempio, un browser Web), potete utilizzare l'HTML validator [Validatore HTML] del W3C. L'HTML validator restituirà una lista di errori in rapporto al DOCTYPE HTML scelto. Se il vostro documento non contiene errori, arriverà il messaggio "No errors found!" ["Nessun errore trovato!"] .
Se create il vostro sito Web a mano o componete direttamente il codice, ed il validatore segnala degli errori nella vostra pagina, correggete semplicemente il vostro codice. Il validatore
HTML vi da' il numero della linea dove si trova l'errore.
Il validatore HTML fornisce il numero della linea nella quale esiste l'errore, così vi potrà aiutare a localizzare il problema nel vostro documento. Egli verifica il file linea
per linea, iniziando dalla prima. Questo significa che un errore all'inizio del documento potrà causare ancora più errori nel resto della vostra pagina. Un buon approccio per
risolvere gli errori è quello di correggere il primo errore rilevato, poi riverificare la vostra pagina. Spesso constaterete che la risoluzione di un problema all'inizio del documento
risolve molti errori nello stesso tempo. Continuate questa operazione fino a quando tutti gli errori non saranno corretti e il documento risultante sarà valido.
Se utilizzate dei programmi per la creazione di HTML [editor HTML] e le vostre pagine, dopo averle create, non sono valide, vogliate segnalare il fatto allo sviluppatore o alla
ditta. Dovreste essere in grado di contattare le persone responsabili del supporto tecnico della ditta.
Se siete uno sviluppatore di generatore di modelli, editor HTML, o di un programma per la gestione dei contenuti, utilizzate il validatore HTML per correggere i problemi nella vostra
implementazione. Potete anche incorporare il validatore HTML nel vostro programma o nel server. Il codice sorgente del validatore
HTML è liberamente disponibile. Il validatore è migliorato continuamente e voi potete partecipare al suo sviluppo.
Nota: Alcuni documenti possono essere validi in rapporto al DTD e potrebbero essere non corretti in rapporto alla specifica HTML. Nel prossimo futuro presenteremo una
lista dei possibili errori che non sono rilevati dal validatore HTML.
Lista dei validatori HTML
Un altro importante problema, che interessa molti siti Web, è la permanenza degli URI. Quando aggiungete dei link verso altri siti Web nei vostri documenti, vi aspettate che questi
link restino stabili e permanenti. Questo significa che l'informazione che volete evidenziare sarà sempre presente quando qualcuno che sta visitando il vostro sito Web
farà "click" in uno dei link che avete fornito. Anche voi vorrete egualmente verificare e garantire che i link che avete posto verso altre pagine Web o verso altre sezioni del vostro
sito Web siano senza errori. E' stato sviluppato uno strumento apposito: il W3C Link Checker [Controllore di Link].
Il Controllore di link genera un rapporto sui link. La lunghezza del rapporto dipende dal tempo impiegato per cercare e verificare tutti i link contenuti nella vostra pagina. Per verificare
il link, il programma invia una richiesta HEAD HTTP sul documento. Se il server è mal configurato, potreste avere un rapporto erroneo, anche se il link è giusto,
semplicemente perchè il server non è in grado di rispondere alla richiesta HEAD. In questo caso dovreste scrivere
al webmaster del sito e chiedergli di rivedere la configurazione del server.
Checking link http://webstandards.org/
HEAD http://webstandards.org/ fetched in 0.1s
Qui sopra un esempio di lista dei link. Questa fornisce il tempo impiegato per raggiungere il link.
Dopo la lista dei link, avrete un rapporto sui link che sono inesistenti o rinviati ad altri; questo vi aiuterà a correggere i link errati.
Se desiderate avere ulteriori informazioni sull'importanza dei link, vi invitiamo a leggere il documento Le URI "in gamba" non
cambiano
, scritto da Tim Berners-Lee.
Se, come webmaster, desiderate installare un programma nel vostro sito Web per aiutare la gente a verificare le loro pagine Web, il codice sorgente del W3C Link Checker è liberamente disponibile.
Fin dal 1996, i Fogli di Stile a Cascata [Cascading Style Sheets] (CSS) offrono la possibilità di separare la struttura dalla presentazione in maniera elegante ed efficace. In
questi ultimi anni (2002), molti programmi utente hanno implementato il supporto per Fogli di Stile di livello 1 e 2 [CSS 1 e CSS 2]. L'uso dei Fogli di Stile vi permette di avere tutte le
informazioni riguardo lo stile dei vostri documenti in un unico posto.
Al momento della redazione di questo articolo, potete scegliere tra i Fogli di Stile, Livello 1 e i Fogli di Stile, Livello 2 per applicare uno stile ai vostri documenti.
Disegnare con i Fogli di Stile offre molti vantaggi, come la riduzione del costo per la creazione del vostro sito Web e l'aumento della sua interoperabilità (la leggibilità del vostro sito Web da parte di molti differenti programmi utenti). Disegnare il vostro sito Web appositamente per diverse versioni di programmi utente, usando tabelle e JavaScript, aumenta del 30% i costi di costruzione.
Non usate l'elemento FONT con l'attributo FACE. E' considerato nefasto dal punto di vista
dell'internazionalizzazione. Se volete imparare come sbarazzarvi del vostro elemento font e adottare i Fogli di Stile, vi incoraggiamo la lettura del manuale di Todd Fahrner Al di là del tag FONT: Applicazione pratica degli stili al testo HTML
Come per i servizi "W3C HTML Validation Service" e il "W3C Link Checker", potrete verificare la validità dei vostri
Fogli di Stile. Potete anche verificare la validità dei Fogli di Stile esterni richiamati dal vostro documento. Se vorrete installare una versione personalizzata nel vostro sito
Web, il codice sorgente del validatore dei Fogli di Stile è liberamente disponibile.
Costruire un sito Web non basta. Per la maggior parte del tempo voi non conoscete la vostra utenza. Le persone che accedono al vostro sito Web possono avere differenti materiali, browser e/o
disabilità specifiche. Vi sono molti vantaggi commerciali nel concepire un Web accessibile. Purtroppo, validare i vostri
documenti riguardo l'accessibilità è meno diretto. Alcuni strumenti, come Bobby, possono aiutarvi, ma non sono la risposta
finale alle vostre preoccupazioni riguardo l'accessibilità. Avrete bisogno di una verifica umana sul vostro contenuto. La Web Accessibility
Initiative mantiene una lista di risorse che vi aiuterà a concepire dei siti Web accessibili.
Spesso le persone sono scoraggiate nel rendere il loro sito Web valido, a causa del grande numero di pagine non valide o perchè non sanno da dove cominciare. E' molto semplice, siate FURBI: Piccolo, Meticoloso, Accessibile, Regolare, Modello. Fissandovi delle piccole tappe, otterrete un sito Web valido, senza dolori e senza scoraggiamenti. Inoltre pensate progressivamente e cercate le soluzioni che facilitino il vostro lavoro, come l'uso di un generatore di modelli.
Ecco una lista di strumenti che vi aiuteranno ad ottenere un migliore sito Web.
Tidy è stato sviluppato inizialmente da Dave Raggett. Vi aiuterà a rendere una pagina Web valida. Qualche volta Tidy non può correggere tutti gli errori. Tidy non
è uno strumento di "editing"-- vi aiuterà solamente a risolvere i problemi.
A volte è molto difficile sapere quali sono le pagine non valide del vostro sito. Se lanciate un script che esplori le vostre pagine, otterrete una enorme lista di pagine non
valide.
Allora, come fare?
Nel W3C, Gerald Oskoboiny ha sviluppato uno strumento progressivo di garanzia di qualità [QA] per i siti Web che non sovraccarica il Webmaster del sito. Questo strumento produce un rapporto sui dieci documenti non validi più richiesti, fornendo una descrizione, in modo che possano essere corretti. Ogni settimana il webmaster riceverà un nuovo rapporto con l'indicazione dei 10 documenti meno validi. Questo strumento è stato messo a disposizione del pubblico. Potrete adattarlo secondo i vostri bisogni..
Olivier Théreaux, del W3C, ne ha sviluppato una versione più portatile e modulare: il LogValidator
Questo strumento prende gli ultimi giornalieri [log] del server Web e li fa passare attraverso dei moduli di validazione. Questi moduli di validazione verificano la validità dei
documenti più richiesti, attraverso una tecnologia particolare. Il modulo per default è quello di validazione HTML, ma presto ne saranno disponibili altri.
Così potrete correggere l'ortografia delle vostre pagine Web, se avete inclusi dei metadati, se i link sono sempre validi, ecc. Una documentazione API vi aiuterà a creare dei nuovi moduli, in funzione dei vostri bisogni.
Grazie alle persone che hanno rivisto questo articolo: Ian Jacobs, Susan Lesch, Olivier Théreaux, Stephanie Troeth, Jeffrey Zeldman e le persone della lista public-evangelist mailing-list.
Questo articolo non sarebbe stato possibile senza la partecipazione di Kim Nylander, redattore tecnico, che ha riletto ed aiutato. .
