Cse Html Validator

Cse Html Validator è un potente strumento realizzato da AI Internet Solutions per verificare l’aderenza agli standard di documenti Html, Xhtml e in parte anche Css. Fornisce in realtà un elevato numero di suggerimenti, che vanno al di là della semplice correttezza del codice: come favorire i motori di ricerca, le accortezze per rendere le pagine accessibili (secondo la Section 508), dimensioni delle pagine, numero di livelli di tabelle annidate, link non funzionanti, ecc.

E’ disponibile in 4 versioni, di cui due gratuite. Per le nostre prove abbiamo utilizzato Cse Html Validator 5.5110.

L’ambiente di lavoro

Cse Html Validator dispone di un proprio ambiente di lavoro, dal quale è possibile aprire un documento, ma anche crearne o modificarne.

Non si tratta di un editor evoluto: c’è la possibilità di inserire tag e attributi, senza però sfruttare tecnologie ormai consolidate, come ad esempio Intellisense per avere suggerimenti mentre si scrive.

L'ambiente di lavoro

Il codice viene evidenziato in corrispondenza degli errori riscontrati. Una finestra di dettaglio contiene l’elenco delle problematiche: cliccando su ognuna il cursore viene portato sulla riga di codice difettosa, così da renderne agevole l’intervento.

Correzione degli errori

Cse Html Validator opera non solo con file locali, ma permette di verificare anche pagine remote, specificando un Url. Questo è comodo non solo se volete controllare le vostre pagine una volta pubblicate, ma anche se avete realizzato diversi “include” e volete provare il risultato utilizzando un server installato in locale.

Integrazione con altri applicativi

Anche se dispone di una sua interfaccia grafica, vi trovere con tutta probabilità ad utilizzare Cse Html Validator da un altro ambiente di lavoro.

Sono infatti diversi gli ambienti di sviluppo che hanno la possibilità di richiamare Cse Html Validator e di integrare efficacemente i risultati nel loro ambiente di lavoro.

Integrazione con TopStyle 3 Professional

Errori, avvisi, consigli

Cse Html Validator rileva tutti i comuni problemi di un documento, quali la mancata chiusura dei tag, l’uso di attributi errati o la mancanza di attributi obbligatori.

Oltre a questo, però, avverte l’utente al verificarsi di alcune problematiche, come ad esempio la presenza di spazi negli Url, il formato non valido di indirizzi email, ecc. Per chi fosse interessanto, è disponibile una lista con le aree di intervento.

Cse Html Validator aiuta anche a risolvere i problemi più comuni relativi all’accessibilità web, come ad esempio la mancanza degli attributi alt, title e summary. Si tratta comunque del primo piccolo passo per rendere le pagine realmente accessibili.

Il programma include la possibilità di verificare anche i documenti Css, rilevando anche in questo caso gli errori e i modus operandi non canonici, anche se non si tratta sicuramente del suo vero punto di forza.

Batch Wizard

E’ anche possibile verificare tutti i link presenti nella pagina e posizionarsi su quello di interesse, selezionandolo da un’apposita finestra.

Batch Wizard

Il programma è altamente personalizzabile e consente di disabilitare uno o più messaggi di errore.

Il Batch Wizard

Se vi trovate o dover controllare più pagine di un sito, aprirle e verificarle tutte dall’editor è un’operazione che può diventare esosa in termini di tempo.

Utilizzando il Batch Wizard potete invece definire un Url, il numero di sottolivelli da visitare (con relative eccezioni e opzioni) e lasciare che il programma si preoccupi di visitare il sito, come se fosse lo spider di un motore di ricerca.

Il risultato è comodo da leggere e da stampare: apprezziamo anche la chiarezza con cui sono suddivise le pagine e gli errori.

Batch Wizard

Distribuito in 4 versioni

Esistono oggi due versioni gratuite di Cse Html Validator con una gestione degli errori superficiale rispetto alla versione a pagamento e che non si integrano con software di terze parti.

Sono poi offerte due versioni a pagamento: una Standard e una Professional: quest’ultima include il Batch Wizard e consente all’utente di definire tag e messaggi proprietari.

Il produttore ha reso disponibile una tavola comparativa tra le versioni.

Cse Html Validator versus W3c Validator

Cse Html Validator non impiega un parser Dtd per verificare la correttezza delle pagine. In questo modo riesce a presentare non solo errori, ma anche ad evidenziare tecniche di programmazione deprecabili. Cse Html Validator ispeziona anche il valore degli attributi, così da segnalare errori di battitura (es width=”5o” al posto di width=”50″).

Così facendo però, esiste sempre la possibilità che il software non si accorga di qualche errore presente nella pagina, anche se durante i nostri test questa eventualità non si è per la verità mai verificata.

Questo vuol anche dire che Cse Html Validator non sostituisce il W3c Validator, ma entrambi gli strumenti dovrebbero essere utilizzati per verificare le pagine.

E’ comunque interessante leggere un test comparativo in cui i realizzatori di Cse Html Validator dimostrano quali sono i vantaggi nell’usare il loro prodotto rispetto al W3c Validator.

Usabile.it diventa Xhtml Strict

Maurizio Boscarol ha da poco rilasciato una nuova vesta grafica per Usabile.it, tra i primi siti italiani ad occuparsi delle tematiche di usabilità ed accessibilità.

Diversamente da altre realtà, che adottano per le nuove versioni di sito lo standard Xhtml Transitional, Boscarol ha deciso di osare ed ha reso le pagine conformi addirittura a Xhtml Strict. Uno sforzo non da poco, soprattutto vista la necessità di ricorrere ai Css per comandare completamente il layout di pagina.

Il risultato non delude comunque le aspettative e l’autore si è inoltre preocuppato di rendere accettabile il degrado anche ai browser datati, fornendo loro un foglio di stile realizzato ad hoc.

Xhtml e l’accessibilità web – Amici per la pelle

È vero: all’inizio non è facile capire perché valga la pena utilizzare lo standard Xhtml per la costruzione delle pagine.

Quello su cui molti si interrogano è la reale necessità di passare da un linguaggio (Html) ad un altro che gli somiglia e sembra aggiungere poche (forse nessuna) funzionalità di rilievo.

A questo si aggiungono i dubbi sui costi di aggiornamento e addestramento per un sito che possa definirsi accessibile: utilizzo dei tag e degli attributi corretti, interpretazione e applicazione delle linee guida.

I due concetti possono sembrare tra loro distanti, ma hanno invece diversi punti in comune.

Potremmo dirvi (anzi, l’abbiamo già fatto in un precedente articolo) che Xhtml è lo standard del futuro, che aiuta a separare lo strato di presentazione dal contenuto, che può essere esteso con la creazione di moduli, ecc.

Quello che però vogliamo presentare oggi è un esempio legato da un lato al tema dell’accessibilità web, dall’altro al costo dei contenuti.

In “Il vero costo dell’accessibilità web” abbiamo detto che i contenuti di un sito costano, e costano molto. Per questo motivo, è necessario costruirli efficacemente.

Di conseguenza, perchè il contenuto di un sito sia costruito in modo efficace, è necessario che si verifichino queste condizioni:

  • dev’essere scritto “correttamente”
  • deve rispondere alle domande degli utenti
  • dev’essere facilmente ricercabile
  • dev’essere facilmente indicizzabile
  • dev’essere trasformabile

Per i primi due punti, come sviluppatori e designer, c’è ben poco da fare: il contenuto va scritto da persone competenti.

Il nostro ruolo è quello di garantire (insieme a chi edita i testi) che il contenuto non rimanga sepolto nei meandri del sito, ma che possa essere trovato anche quando non è strillato ai quattro venti dalla Homepage.

Non solo, il contenuto va opportunamente categorizzato, perché chi usa il sito probabilmente ha un problema da risolvere, alla cui soluzione arriva procedendo dalla Homepage alle sezione e alle sottosezioni.

Ma il contenuto dev’essere anche trasformabile: quello che oggi è una pagina web domani potrebbe trasformarsi in un articolo cartaceo o in un documento Pdf. Per non parlare di visualizzazione su cellulari, Pda, ecc. Riscrivere una versione ad hoc per queste esigenze introdurrebbe degli altri costi.

Se lo standard Xhtml viene usato con “accortezza”, donerete al vostro contenuto il segreto dell’eterna giovinezza, perché potete passare da una versione all’altra senza riscrivere il contenuto. Ma non solo: lo fate con estrema semplicità, utilizzando lo standard Xsl.

Vediamolo con un esempio.

Convertire documenti Xhtml

Partiamo da una semplice (quasi banale) pagina che contiene un piccolo articolo. Ecco come è visualizzata:

Categoria: Sviluppo web

Come abbiamo già visto la scorsa puntata, con il solo Html non è possibile realizzare siti dinamici.

Per creare applicativi lato server è possibile ricorrere all’uso dei seguenti linguaggi di scripting (cfr. il manuale cartaceo a pag. 52):

Per costruire la pagina sono stati impiegati i tag e gli attributi che migliorano l’accessibilità e l’usabilità del documento: acronym, abbr, title, lang, ecc. Il sorgente è il seguente:

  1 <html lang="it" xmlns="http://www.w3.org/1999/xhtml">
  2   <head>
  3     <title>Xhtml e i tag accessibili</title>
  4   </head>
  5   <body>
  6     <p>Categoria: <span id="categoria"><strong>Sviluppo <span lang="en">web</span></strong></span></p>
  7     <p>Come abbiamo gi&agrave; visto la <a href="http://www.foo.com/percorso1" title="Puntata precedente: sviluppare per il web">scorsa puntata</a>, con il solo <acronym lang="en" title="HyperText Markup Language">Html</acronym> non &egrave; possibile realizzare siti dinamici.</p>
  8     <p>Per creare applicativi lato <span lang="en">server</span> &egrave; possibile ricorrere all’uso dei seguenti linguaggi di <span lang="en">scripting</span> (<abbr title="confronta">cfr.</abbr> il manuale cartaceo a <abbr title="pagina">pag.</abbr> 52):</p>
  9     <ul>
 10       <li>
 11         <acronym lang="en" title="Active Server Pages">Asp</acronym> di <a href="http://www.microsoft.com" title="Sito web di Microsoft Corporation"><span lang="en">Microsoft</span></a>, su <acronym lang="en" title="Internet Information Services">Iis</acronym>
 12       </li>
 13       <li>
 14         <acronym lang="en" title="Java Server Pages">Jsp</acronym> di <span lang="en"><a href="http://www.sun.com" title="Sito web si Sun Microsystem">Sun</a></span>
 15       </li>
 16       <li>
 17         <acronym lang="en" title="Hypertext Preprocessor">Php</acronym>
 18       </li>
 19     </ul>
 20   </body>
 21 </html>

Come vedete, il testo è arricchito da informazioni aggiuntive che ne migliorano l’accessibilità.

I vantaggi però non si fermano all’accessibilità: il fatto che il documento sia standard Xhtml consente la realizzazione, tramite Xsl, di opportuni fogli di trasformazione che consentono di tradurre il documento in un altro formato.

Un esempio di risultato (forse il più semplice tra gli infiniti disponibili) è il seguente:

Categoria: Sviluppo web

Come abbiamo già visto la scorsa puntata, con il solo Html non è possibile realizzare siti dinamici.

Per creare applicativi lato server
è possibile ricorrere all’uso dei seguenti linguaggi di scripting (cfr. il manuale cartaceo a pag. 52):


Link nella pagina
Acronimi
Abbreviazioni
  • cfr.: confronta
  • pag.: pagina
Termini stranieri
Categoria
  • Sviluppo web

Come potete vedere, l’articolo è stato stravolto: sono stati estratti e separati gli acronimi, le abbreviazioni, le parole in lingua straniera e i link.

Sono anche state aggiunte alcune funzionalità:

  • se selezionato un acronimo vi collegate a Google, dove troverete una definizione estesa del termine
  • se selezionate un termine straniero interrogare invece Babylon, che cercherà di trovare il corrispettivo italiano
  • compare un elenco dei link e il testo di accompagnamento è l’attributo title del link

Abbiamo ricavato molte informazioni precise da un testo davvero modesto.

Inoltre, il tempo necessario per la costruzione del foglio Xsl per la trasformazione ha richiesto non più di un’ora ed è applicabile a qualsiasi documento Xhtml.

Usare lo standard Xhtml insieme ai tag di solito ignorati (quelli che migliorano
l’accessibilità), vi apre quindi molti scenari:

  • possibilità di realizzare una copia per il mondo cartaceo
  • conversioni per telefoni e Pda
  • costruzione automatica di indici e tabelle con le abbreviazioni
  • elenco dei link presenti nella pagina
  • isolamento dei termini stranieri
  • categorizzazione dei contenuti della pagina (per parole d’ordine, tipologia, ecc.)

Possibili obiezioni

Come tutte le metologie, sono naturali alcune critiche al metodo sopra illustrato. Cerchiamo di prevederle insieme.

Non è meglio usare l’Xml come lingua franca per poi trasformare i documenti?

Senza dubbio l’Xml è il candidato principe alle trasformazioni Xml.

In questa sede stiamo però parlando di contenuti, che come tali saranno inseriti da un editor di competenze tecniche limitate.

È sicuramente possibile utilizzare l’Xml per categorizzare un documento la cui struttura è fissa (titolo, sommario, categorie, data, ecc.), più difficile se i dati sono “semistrutturati“.

Poiché ogni documento ha una struttura diversa dagli altri (per numero e posizione degli acronimi, dei collegamenti, delle parole straniere), l’editor ha più controllo con lo standard Xhtml, di cui riesce agevolmente ad avere un’anteprima su browser.

Ma un documento Xhtml è una specializzazione di documento Xml, per cui sarà possibile trasformarlo senza rinunciare ad alcuna caratteristica.

Non è eccessivo il costo per produrre contenuti così ricchi di informazioni?

Il costo c’è e non è esiguo. Non solo: mentre scrivere Html è ormai alla portata di tutti, diventa ora importante che i documenti siano sintatticamente e semanticamente corretti.

Ma tanto più il business dipende dai contenuti (siano questi articoli, documenti, listini), tanto maggiore sarà il risparmio futuro.

È possibile trasformare un documento anche partendo dall’Html. Perché devo usare Xhtml?

Perché è estremamente più semplice.

Il formato Xml di per sé non rappresenterebbe niente di eccezionale se lo sviluppo di procedure di interrogazione e trasformazione fosse complesso e costoso.

In realtà, i vincoli di cui bisogna tener conto nella scrittura di un documento Xml (è case sensitive, ha un solo nodo padre, tutti i tag devono essere chiusi), fa si che i parser per l’interrogazione e la trasformazione siano molto efficienti e semplici da utilizzare.

Conclusione

Il contenuto incide in larga misura sui costi di realizzazione di un sito accessibile. Vale perciò la pena di realizzarlo secondo lo standard Xhtml ed utilizzando tutti i tag che arricchiscono il testo di informazioni.

In questo modo è possibile facilitare la ricerca e la memorizzazione dei documenti, ma anche le conversioni per altri media e formati e per future versioni del sito.