Dopo aver cercato senza esito una soluzione su internet ho creduto che il problema fosse dovuto a qualche errore nel codice del cms, ma alla fine non era così.

Ecco come si presentava il codice dove veniva segnalato l’errore di validazione:

  <li><a href="http://www.sitoprova.com" title="Sito prova" target="" 
onclick="javascript:_gaq.push(['_trackPageview','/yoast-ga/outbound-blogroll/
http://www.sitoprova.com']);">Sito prova</a></li>

L’errore era sull’attributo target: “The element uses an attribute that does not exist”

In realtà quel codice non è generato da wordpress, e son dovuto andare a ritroso con la memoria per capire quale plugin potesse averlo inserito. E una volta tanto la memoria mi ha aiutato, in pratica quel codice si genera quando si tracciano i click sugli outbond link attivando la funzione “Track outbound clicks & downloads” del plugin Google Analytics for WordPress

Sarà sufficiente (se non volete modificare i file del plugin) deselezionare il campo e il codice del link si presenterà semplicemente in questo modo:

  <li><a href="http://www.sitoprova.com" title="Sito prova">Prova sito</a></li>

E l’errore di validazione scomparirà

Fiero dei complimenti del W3C e della completa validazione del codice, sono stato assalito da un dubbio: “Ora le mie pagine sono validate ma non potrò più usufruire del conteggio dei click sugli outbound link e rinunciare ad una comoda funzionalità”.
Ed ecco il vero motivo di questo articolo, in questo caso sarebbe stato sufficiente apportare delle modifiche al file php, ma supponendo che invece non c’erano soluzioni alternative per risolvere l’errore oltre quella di disattivare la funzionalità, voi cosa avreste fatto al mio posto?
Avreste sacrificato una funzionalità utile pur di rendere valido il vostro codice al 100%?

In generale preferite un codice puro e senza errori a tutti i costi o in alcuni casi chiudete un occhio?

A voi l’ardua sentenza

Per chi ancora non lo sapesse, tutti i link possono avere un attibuto “title”, dove è possibile descrivere brevemente il contenuto della pagina alla quale il collegamento fa riferimento.
Per visualizzarlo, basta posizionarsi col cursore del mouse sul link in questione, in questo modo compare un riquadro con il testo contenuto nell’attributo.

Esempio:
Codice

<a title="Diventa Fan di Yeswebcan su Facebook" 
href="http://http://www.facebook.com/">Facebook</a>

Link
Facebook

Quando utilizzarlo?
Questo attributo è molto utile sopratutto quando il testo del link non è sufficiente a descrivere la pagina di destinazione, o come supporto all’alt quando i link sono delle immagini.
Può essere utilizzato anche per segnalare se si tratta di un link interno o esterno e se verrà aperto nella stessa finestra o in una nuova (_blank).

Quando non utilizzarlo?
Quando l’anchor text del link è ad esempio il titolo di una pagina o comunque descrive già bene il contenuto a cui è collegato, è meglio omettere quest’attributo onde evitare una ripetizione del testo.

Quest’attributo aiuta il posizionamento della pagina nella Serp?
Test effettuati da autorevoli esperti hanno dimostrato che l’utilizzo di keyword nell’attributo HTML title del link non porta ad alcun risultato a livello di posizionamento, almeno per adesso.

Allora perchè utilizzarlo?
Semplice, per l’accessibilità e l’usabilità dei contenuti. Infatti, oltre ad essere utile per chi utilizza browser standard, è molto utile per persone ipovedenti o in generale per coloro che utilizzano browser tipo lynx, sopratutto se nell’attributo indichiamo se il collegamento verrà aperto in una nuova finestra. Anche se bisogna ricordare che forzare l’apertura di collegamenti in nuove finestre è una cosa sbagliata perchè crea difficoltà a persone con disabilità e che utilizzano browser particolari per la navigazione… le motivazioni potete trovarle in quest’articolo che scrissi per ItalianWebDesign.

In generale, comunque, è buona norma mettere “qualsiasi” utente nella condizione di sapere cosa si nasconde dietro a un generico click.

Dunque, sfruttare il titolo di un link per aggiungervi informazioni di tipo semantico in merito alla pagina di destinazione, può essere molto utile sia per chi ha disabilità che per gli altri perchè avranno maggiori informazioni su cosa andranno a visitare, e allo stesso tempo valorizzeremo il contenuto della nostra pagina.

Si tratta di Affrontare l’accessibilità (per un sito più accessibile in 30 giorni), un manuale scritto da Mark Pilgrim nel 2002 e tradotto in Italiano da Roberto Scano.

In questa guida l’autore, si rivolge ai web designer, proponendogli la risposta a due domande:

• Perché dovrei rendere più accessibile il mio sito?
• Come posso rendere il mio sito più accessibile?

L’eBook è suddiviso in 30 sezioni, a ciascuna delle quali (come da titolo) corrisponde un giorno.

Nelle prime cinque giornate vengono presentati i protagonisti, Jackie, Michael, Bill, Lilian e Marcus, ognuno con una particolare disabilità e quindi con difficoltà nell’utilizzare il computer e nell’accesso al web.

Nelle altre giornate invece ci sono una serie di consigli per rendere le pagine web il più accessibile possibile.

Le sezioni sono così suddivise:

• Giorno 6: Indicate un DOCTYPE
• Giorno 7: Identificate la vostra lingua
• Giorno 8: Date titoli significativi
• Giorno 9: Fornite ulteriori ausili alla navigazione
• Giorno 10: Presentate subito il contenuto principale
• Giorno 11: Saltate la barra di navigazione
• Giorno 12: Usate i colori sicuri
• Giorno 13: Usare link veri
• Giorno 14: Aggiungete titoli ai link
• Giorno 15: Definite scorciatoie da tastiera
• Giorno 16: Non aprite nuove finestre
• Giorno 17: Definite gli acronimi
• Giorno 18: Date al calendario una vera didascalia
• Giorno 19: Usate vere intestazioni di tabella
• Giorno 20: Fornite un sommario della tabella
• Giorno 21: Ignorate le immagini con funzione spaziatrice
• Giorno 22: Usate liste vere (o fatele sembrare tali)
• Giorno 23: Fornite testi equivalenti per le immagini
• Giorno 24: Fornite testi equivalenti per mappe di immagini
• Giorno 25: Usate barre orizzontali vere (o quasi)
• Giorno 26: Usate dimensioni relative per i font
• Giorno 27: Usate intestazioni vere
• Giorno 28: Etichettate gli elementi dei moduli
• Giorno 29: Rendete tutto ricercabile
• Giorno 30: Dichiarate il vostro livello di accessibilità

Vi ho sempre parlato bene delle letture da me segnalate, ma a questa ci tengo in particolar modo infatti si tratta di una delle risorse più utili e conosciute del web, tanto da esser stata tradotta in 10 lingue.
Il consiglio che vi dò è di scaricarla e leggerla ne vale veramente la pena, e vi assicuro che cambierà in positivo il vostro modo di progettare per il web.

Buona lettura e ditemi che ne pensate.

Simone D’Amico è ormai un amico (e scusate il gioco di parole ) di yesWEBcan.
Insieme abbiamo testato e tratto delle conclusioni su uno strumento per cui scrissi un articolo, e da allora seguo il suo blog quotidianamente, perchè davvero tratta argomenti molto interessanti.

Uno che mi ha lasciato veramente sbalordito riguarda Un modo alternativo al CAPTCHA per evitare gli spam bot.

Penso siate d’accordo con me che copiare quei numeretti sempre più nascosti e piccoli sia una scocciatura per tutti. Oltre a questo motivo, la cosa a cui Simone non aveva pensato è che il Captcha per come spesso viene utilizzato non è accessibile.
Il sistema proposto da lui, invece, oltre a farci risparmiare la noiosa operazione di copia, a mio parere è anche un ottima soluzione per i visitatori con difficoltà visive.

Come funziona? Semplice, va considerato che uno spam bot analizza tutti i campi input presenti nel codice, ignorando se essi vengano o meno visualizzati nella pagina. Basterà quindi creare un semplice campo input con visibilità nascosta tramite CSS che, se pieno, indicherà che è stato effettuato un tentativo di spamming.

Come implementarlo? Andate a vedere sul suo blog!

Simone, io non ho altro da aggiungere, anzi un’ultima cosa … Complimenti