How the new HTML 5 will impact on SEO?

Later on 20th of January (or something like that), YouTube launched a fascinating experiment, introducing new video format for supported browsers, which rely on new HTML5 syntax.

HTML EvolutionTherefore, it appears that the new standard, which has been under development since 2007 (first draft in 2008) is going to be massively used.
Ok, it may be too earlier to be said, but considering all the new browsers – Internet Explorer 8 included – has a good support for the new specifics, a new era is definitely coming.

The new HTML5 specific are almost complete, so it’s just a matter of time before they will be definitely released, and sooner every coder should start rethinking on the way they code pages.

Are the coders the only person that should be worried about that?

I guess no. HTML5 will introduce a very new way to implement and represent data, and the syntax will be so different that all other web parties involved in the web industry – eventually – will have to face with it. Continue reading How the new HTML 5 will impact on SEO?

Accessibilità in contrasto con la validazione

Il punto di partenza per capire di cosa tratta l’accessibilit la definizione della parola accessible (accessibile, in italiano), contenuta nelle definizioni WCAG 1.0: Content is accessible when it may be used by someone with a disability, che tradotto in italiano diventa: Un contenuto accessibile quando pu essere usato da qualcuno con una disabilit.
Una definizione molto vicina al pensiero con il quale il padre del web, Tim Berners-Lee (attuale direttore del W3C – ndr), pose le basi del web 1.0. Il suo motto era infatti: La forza del Web sta nella sua universalit. L’accesso da parte di chiunque, indipendentemente dalle disabilit, ne un aspetto essenziale.

L’accessibilit (o meglio dovrebbe essere) quindi al centro delle nostre (web designer) attenzioni; in particolare con l’introduzione della cosidetta Legge Stanca, enti locali, comuni, province e regioni avrebbero dovuto attrezzarsi per garantire l’accessibilit dei siti, come richiesto dall’Aipa. Ma al di l di questo, questo preambolo sull’accessibilit mi serviva per introdurre un’effetto boomerang.

Rendere infatti accessibile un sito, significa potenzialmente non validarlo.

No, non sgranate gli occhi, la verit. Faccio un esempio abbastanza banale. Se avete costrutito il vostro sito con le specifiche XHTML 1.1 e lo avete validato, vi sarete accorti che necessario rimuovere l’attributo affinch la validazione passi.
Ora, se provate a passare al setaccio il sito in questione secondo le specifiche dell’accessibilit a livello 3, vi ritroverete con un errore che vi richiede questo attributo. E’ un bel no-sense! Eppure c’. E come questo ce ne sono diversi altri di esempi che mi sono capitati, ma che non sto a documentare.

Cosa fare allora? La risposta : dipende. Dipende dal sito che state facendo e da chi il committente. Se si tratta di pubblica amministrazione la logica – e anche le regole che puntualmente non sono mai rispettate – (un caso eclatante stato Italia.it) vorrebbe che il sito sia accessibile, quindi magari nell’intento di utilizzare un linguaggio comunque nuovo, fare uso dell’XHTML 1.0 invece che 1.1.

Se, invece, il vostro cliente di riferimento una azienda (Anche le aziende private – finalmente – si sono accorte dell’importanza dell’accessibilit e dell’usabilit per estendere il numero di potenziali clienti) cercate di fare le cose al meglio utilizzando magari l’XHTML 1.1 e non pretendendo di rendere accessibilie il sito a livello 3, ma accontentarsi del livello 1.

Nel mentre che risolvete i vostri dilemmi mentali, vi lascio con un link per la validazione WAI e quelli ufficiali del W3C per la validazione del vostro HTML e dei vostri CSS.

Technorati Tag: ,

Un pattern per l’accessibilita’ e l’indicizzazione delle pagine da parte di Google

Ieri sul suo blog ufficiale, Google ha rilasciato una serie di linee guida per una corretta accessibilit e indicizzazione dei documenti di un sito web.

Il documento, molto breve ma al contempo chiaro, si basa su 5 punti fondamentali:

  1. Evitare un uso massiccio dell’XMLHttpRequest, ovvero di Ajax;
  2. Creare sempre dei link di navigazione funzionali, ovvero mettere il tag alt nelle immagini se queste vengono usate come bottoni o, se si usano i CSS, fare in modo che comunque il link contenga delle informazioni di navigazione sufficienti tanto per il GoogleBot che per il navigatore
  3. Utilizzare codice Javascript poco invadente
  4. Creare links verso le risorse pi importanti (ovvero creare anche la sitemap – ndr)
  5. E creare una versione stampabile dei documenti. Su questo punto, che volutamente ho lasciato per ultimo, mi sento di dissentire quando l’autore – T.V. Raman, mette in risalto la possibilit che una versione stampabile della pagina possa generare un contenuto duplicato.

In merito al punto 5, che volutamente ho messo per ultimo, necessaria una nota. Non necessariamente, infatti, creare una versione stampabile della pagina equivale a dover creare una seconda pagina. Un uso professionale dei CSS e un piccolissimo script javascript per switchare i fogli di stile pu infatti consentire di avere una versione stampabile del proprio documento senza creare la seconda pagina. In aggiunta, con questa tecnica, il codice javascript che avr poco da essere interpretato, non sar seguito dal GoogleBot evitando cos contenuti duplicati.

Un esempio di questa tecnica lo potete vedere sul mio sito web; scorrendo in fondo ad ogni pagina troverete un’immagine che dice CSS Print. Cliccakandoci sopra si potr vedere la versione stampabile del documento e viceversa.

Tecnica questa che uso sin dal tardo 2006.

Technorati Tags: ,,