Un sito accessibile deve avere codice valido?

Validità e accessibilità: matrimonio inscindibile?

La domanda del titolo è stata fonte di numerose discussioni sulle WCAG 2.0 fin dal 2005, tanto da portare alla creazione di una pagina dedicata alla questione.

Nella nuova versione delle linee guida infatti è stato eliminato il riferimento alla validità del codice come requisito fondamentale: la cosa è logica, se ci pensate. Se le WCAG devono essere delle linee guida sull’accessibilità, non ha senso che il codice valido sia un requisito primario.

Sicuramente la validità è un primo passo verso l’accessibilità di un sito, ma non significa che serva per renderlo accessibile, anzi.

La questione però tocca anche un altro livello, ovvero la funzione “educativa” che dovrebbero avere le WCAG. Eliminando il requisito, molti hanno accusato il Working Group di aver messo in secondo piano il codice valido. In effetti è così, ma solo perchè l’obiettivo principale era un altro, e ci si è voluti concentrare esclusivamente sul tema accessibilità.

Voi cosa pensate a riguardo? A prescindere dal legame tra i due argomenti, credo che raggiungere entrambi gli obiettivi, realizzando siti validi ed accessibili, sia il traguardo ideale. A livello teorico le cose sono separate, ma personalmente mi sarebbe difficile far passare per accessibile un sito con codice non valido.

WCAG 2.0 per un web accessibile

Il W3C ha rilasciato la seconda versione delle linee guida per l’accessibilità del web, invitando gli sviluppatori a seguirne le indicazioni.

Il 30 Aprile 2008 sono state ufficialmente rilasciate come Candidate Recommendation le WCAG 2.0, di cui si parla ormai da diverso tempo.

Sono le linee guida per l’accessibilità dei contenuti, realizzate dal W3C che adesso invita gli sviluppatori ad usarle come riferimento, per testarle all’interno di problematiche quotidiane e verificarne la validità.

La precedente versione è del 1999, ma è ancora adesso un punto di riferimento. Un rinnovamento per seguire l’evoluzione del web era necessario, ma c’è chi non è d’accordo con le nuove scelte del W3C, in certi casi considerato un ente troppo lento e burocratizzato.

Proprio per questo Joe Clark da diverso tempo ha avviato il progetto parallelo WCAG Samurai, per indicare una strada alternativa. La pubblicazione delle WCAG Samurai Errata è avvenuta il 26 Febbraio 2008, ed è da notare come queste linee guida siano in contrapposizione con le WCAG 2.0 appena uscite.

E’ possibile essere d’accordo con le WCAG 2.0 o con le WCAG Samurai Errata, ma non con entrambe.

Avevo già scritto in passato un articolo sulla questione, a voi la scelta sulla strada da seguire. Se volete conoscere la posizione di Joe Clark, vi segnalo il suo post a riguardo.

Personalmente credo che le guerre interne non aiutino gli standard. Sul web le tabelle per il layout ormai stanno scomparendo, ma la maggioranza dei siti e dei portali più famosi ha ancora un markup ridicolo. E’ necessario trovare una via comune per rendere possibile a tutti l’accesso al web, non il contrario.

CSS3 Web Fonts: test pratico

Istruzioni d’uso per i Web Fonts, nuovo modulo dei CSS3.

Con i CSS2 è possibile avere un buon controllo sui font utilizzati in una pagina web. Basta dichiarare un elenco di font, e se il primo non è disponibile il browser cercherà il secondo, fino all’esaurimento dei font dichiarati.

Le cose però sono state sviluppate ulteriormente con i CSS3, che vedono l’introduzione dei Web Fonts.

Cosa sono i Web Fonts? Sono un miglioramento che consente tramite CSS di far scaricare automaticamente all’utente dei font non installati sul proprio sistema operativo. In questo modo le pagine saranno visualizzate esattamente come pensato dal graphic designer, senza bisogno di ricorrere a tecniche di image replacement.

In realtà il documento del W3C che parla di Web Fonts è stato creato il 2 Agosto 2002, ma come noto dalla dichiarazione di uno standard all’utilizzo pratico il cammino è lungo. Ne parlo ora perchè Safari 3.1 è il primo browser a supportarli, consentendo di iniziare ad usare questa tecnica.

Niente infatti vieta di utilizzare i Web Fonts, che saranno trascurati dai browser che non li supportano.

Per usarli, è sufficiente inserire all’interno del CSS una dichiarazione di questo tipo, indicando il percorso per scaricare il font:

@font-face {
font-family: 'Bimini';
src: url('bimini.ttf');
}

A questo punto sarà possibile usare il font dichiarato (Bimini) senza preoccuparsi della sua presenza sul computer dei visitatori:

h1 { font-family: Bimini, Arial, sans-serif; }

Da notare che se si vuole usare il nuovo font in grassetto, va dichiarata anche questa variante:

@font-face {
font-family: 'Bimini';
font-weight: bold;
src: url('bimini.ttf');
}

Stesso discorso per il corsivo e le altre combinazioni a disposizione.

Se avete Safari 3.1 e volete testare i Web Fonts, ho preparato una pagina demo. Utile anche per chi vuole vedere il CSS in pratica.

A questo punto potete utilizzarli liberamente, al momento solo chi usa Safari avrà un’esperienza migliore.

Il mio consiglio però è di farlo in maniera responsabile. Ricordate che dovreste usare solo font gratuiti con licenza di libera distribuzione, e soprattutto che verranno scaricati dal browser dei visitatori. Considerando che esistono font dal peso superiore ai 100kb, valutate con attenzione ogni cosa prima di usare i Web Fonts.

IE8, Microsoft e gli Standard Web

Analisi delle ragioni che potrebbero aver portato Microsoft alla fatidica decisione: Internet Explorer 8 supporterà i Web Standards.

Internet Explorer 8 rispetterà di default gli standard web. Questa è la notizia che da un paio di giorni sta facendo il giro del mondo, ripresa su blog e testate più o meno importanti. Del resto che IE fino ad ora sia sempre stato ben lontano dagli standard è cosa nota, era prevedibile che un’inversione di tendenza provocasse tanto scalpore.

La cosa più strana è come la Microsoft sia arrivata a questa decisione. Fino a poco fa la sua posizione era completamente opposta, e prevedeva che il Super-Standard Mode dovesse essere abilitato tramite un meta tag apposito. Questa scelta era stata approvata nientemeno che da Jeffrey Zeldman su A List Apart, sollevando numerose polemiche.

Come si può essere arrivati a questo cambiamento, tanto positivo per gli sviluppatori che fanno del rispetto degli standard la loro religione?

La risposta più plausibile è quella ipotizzata da Andy Budd, in un post precedente al cambio di posizione della Microsoft:

Microsoft have set up the ideal conditions to marginalise their own browser. Clueless developers won’t know about this behaviour so every new site they build will automatically be rendered as IE7. Clued-up developers will use this as an excuse to freeze support for IE and turn their attentions to better browsers.

[..]

No matter what great leaps forward the Internet Explorer team make from now on, the majority of developers won’t use them and the majority of users won’t see them.

In pratica se la Microsoft fosse rimasta lontana dagli standard, gli sviluppatori avrebbero potuto smettere di preoccuparsi di IE8 e successivi, limitandosi a controllare la visualizzazione su IE7.

Un probabile suicidio, perchè tutte le future release si sarebbero comportate di default sempre allo stesso modo. L’esperienza di navigazione migliore sarebbe rimasta un’esclusiva dei browser concorrenti.

In ogni caso, questa novità deve essere accolta positivamente: uno sviluppatore del calibro di Roger Johansson ha parlato di sorpresa dell’anno, ed io non posso che concordare.

Nuovo sito Feltrinelli: uno sguardo critico

Un’analisi del nuovo sito Feltrinelli, evidenziando pro e contro del portale.

logo FeltrinelliDa pochi giorni è online il nuovo sito di e-commerce della Feltrinelli, nota libreria e casa editrice: sono rimasto piacevolmente sorpreso da alcuni particolari dell’operazione, ma non mancano le note negative.

I Pro

Il primo punto a favore dell’operazione è sicuramente l’apertura del sito avvenuta in Dicembre, a favore dei clienti già registrati. Ho infatti ricevuto l’invito a partecipare ad una vera e propria beta privata: una password permetteva l’ingresso nel sito ancora chiuso. Operazione in pieno stile web 2.0, con la possibilità di inviare feedback e commenti. Idea ottima che ha premiato i clienti più fedeli, aumentando l’interesse per il nuovo sito.

Altra nota a favore riguarda la grafica. Molto più curata rispetto al passato, presenta qualche imperfezione come le tab della navigazione principale che appaiono troppo grossolane e definite male, ma l’impressione generale è buona. Ci sono anche alcuni elementi di interaction design interessanti, come lo slider in evidenza al centro della pagina.

I Contro

La prima cosa che mi ha sorpreso in negativo è stata l’assenza di un comunicato per il lancio ufficiale. Dopo tanto sforzo per mostrare ai clienti più fedeli la nuova creazione, non mi è arrivata nemmeno una email di notifica. Mi sono accorto per caso che il nuovo sito era online.

Un secondo particolare negativo, da evitare quando si rinnova un sito, è l’eliminazione di funzioni che fino a quel momento erano particolarmente apprezzate. Sul vecchio portale era possibile conoscere la disponibilità dei libri nei vari punti vendita, adesso non più.

Conclusioni

Il nuovo sito Feltrinelli presenta alcune idee interessanti, il cui impatto si è però perso in una scarsa cura dei dettagli.

Quello che inoltre continua a farmi riflettere è la poca importanza data alla validazione del codice html ed all’accessibilità. Non succede solo in questo caso, anzi la maggioranza di portali medio-grandi ha ben poca cura per questi aspetti.

E’ possibile fare qualcosa per cambiare questa tendenza? Le mie speranze per l’immediato futuro sono ben poche, basti pensare al caso di Google di cui ho parlato in passato.

Aggiornamento: ho avuto un interessante scambio di mail con Luca Innocenti, responsabile Customer Satisfaction di Feltrinelli, che mi ha fornito alcuni elementi per meglio giudicare il nuovo sito. Riporto direttamente le sue parole che integrano quando ho scritto:

“[..] lo scaffale sarà esportabile e condivisibile con altri utenti: in questo modo potrà “sbirciare” nello scaffale degli altri utenti che hanno gusti simili per scovare qualche libro o cd o film interessante.

Per quanto riguarda i “contro” le preciso che la ricerca della disponibilità presso i negozi non è stata disattivata, ma è semplicemente riservata agli utenti Carta Più. La stiamo comunque estendendo anche agli utenti registrati al sito. Può accedere a tale funzionalità entrando nella scheda prodotto e selezionando “dettagli”: visualizzerà un link “ricerca disponibilità presso i punti vendita”

La decisione di non comunicare in modo “invasivo” il lancio del nuovo sito, infine, è dovuta innanzitutto alla necessità di approfondire i test. Stiamo muovendo i primi passi e qualche funzionalità, come può immaginare, deve essere rafforzata.”

Sentitevi liberi di dire la vostra, il dialogo è aperto e qualsiasi suggerimento potrebbe essere preso in considerazione se degno di nota.

Google Ban: quando la paura è esagerata

In questo periodo ci sono state diverse rivoluzioni per quanto riguarda Google e l’attività dei SEO. Quello del posizionamento non è un ambito affatto statico, anzi è fondamentale aggiornarsi continuamente per evitare cadute clamorose dei propri siti, ma negli ultimi mesi ci sono stati più rinnovamenti del solito.

Un episodio su tutti è quello riguardante i link a pagamento, che ha visto il pagerank di numerosi siti scendere improvvisamente: anche su TomStardust.com c’è stato un calo da PR6 a PR4 avvenuto in un unico aggiornamento.

Quello però che mi fa sorridere, è come in certe situazioni la paura di essere bannati o penalizzati da Google diventi eccessiva, al punto da mettere i motori di ricerca davanti a tutto il resto, considerandoli anche più importanti degli utenti stessi.

Un esempio?

Mi è capitato di sentirmi dire di evitare le tecniche di image replacement che utilizzano position:absolute o overflow:hidden per paura del ban. Capisco i timori di chi non si può permettere una penalizzazione su Google (e chi può?), ma se determinate pratiche sono più che diffuse e rispettano gli standard non vedo dove sia il problema.

Scrivendo xhtml e css il mio obiettivo principale è sempre il rispetto degli standard del W3C e la validazione delle pagine. Raggiunto questo risultato, se le tecniche utilizzate sono consolidate non c’è motivo di aver paura. Uno sviluppatore dovrebbe sempre pensare per primo all’utente: sarà molto più facile poi occuparsi del resto, anche dei motori di ricerca.

E voi cosa ne pensate? Conoscete qualcuno bannato da Google per un image replacement o altre tecniche simili?

I 100 migliori siti su web standards e accessibilità

Raccolgo una segnalazione di Ecologia dei siti web assolutamente degna di nota.

Il blog di Virtual Hosting infatti ha pubblicato un elenco di 100 siti che si occupano di accessibilità, web standards e interfacce. Nella lista ci sono molti nomi noti, come A List Aparto o 456 Berea Street, ma fra tutte le risorse segnalate sono molte quelle meno conosciute e tutte da scoprire.

Io ho intenzione di passarne buona parte in rassegna, mi interessano molto quelli dedicati allo User Centered Design. I 100 siti infatti sono suddivisi per argomento in modo da facilitarne la consultazione.

Buona lettura!

Posizionamento sui motori di ricerca: qualche consiglio

Ogni tanto mi vengono chiesti consigli per il posizionamento sui motori di ricerca: a volte si tratta di siti amatoriali, in altri casi sono vetrine sul web di attività commerciali, ma sono comunque ben pochi i casi in cui si trova svolto un buon lavoro di ottimizzazione per Google ed affini.

Per chiunque abbia voglia di interessarsi all’argomento SEO, i punti fondamentali da cui partire sono senza dubbio:

  • validità del codice e rispetto degli standard descritti dal W3C
  • contenuti ben organizzati e strutturati, utilizzando codice semanticamente corretto

Iniziando da questa base è possibile ottenere buoni risultati, ma la cosa più importante da tenere presente è che un sito per essere trovato ha bisogno di contenuti da offrire. Molti contenuti. E’ per questo motivo che i blog sono così ben visti dai motori di ricerca: sono una fonte continua di notizie in continuo aggiornamento, ed il patrimonio che mettono a disposizione degli utenti aumenta continuamente, ad ogni post.

Non è però tutto così facile. Ci sono diverse tipologie di contenuti completamente invisibili ai motori di ricerca, inutili ai fini del posizionamento e controproducenti se usate su larga scala.

Vengono descritte benissimo nel post SEU, Search Engine Useless su Standardzilla, che riassumo in breve:

Iframes

Gli Iframe non sono validi usando doctype XHTML. Inoltre visualizzare dei contenuti in questo modo significa non sfruttarli pienamente, perchè gli spider dei motori di ricerca non leggeranno ciò che si trova all’interno della finestra dell’Iframe.

Flash

Il tanto discusso flash è spesso inutile ed impossibile da leggere per i motori di ricerca. Il bello è che il modo per far indicizzare comunque i contenuti ci sarebbe, ad esempio fornendo delle alternative accessibili. Inutile dire che non viene quasi mai usato in maniera corretta.

AJAX

Spesso sinonimo di Web 2.0, AJAX è una tecnologia da usare con cautela. Ne ho parlato anche in passato, riempire un sito di javascript per generare i contenuti è una pessima idea ai fini del posizionamento.

Video e Audio

Come immaginerete, tutto ciò che è video e audio non può essere indicizzato da Google (almeno per ora..). Per risolvere il problema basterebbe rispettare i requisiti per un sito accessibile, ovvero affiancare delle trascrizioni.

Cosa fare se un sito ha tutti questi elementi che non verranno mai letti da un motore di ricerca? Lavorare a posteriori non è mai facile, ma inizialmente puntare sulla pulizia del codice può aiutare molto. Utilizzare il corretto title sulle proprie pagine, eliminare i meta tag obsoleti, fare attenzione ai titoli e magari passare ad una doctype di tipo XHTML sono i primi passi da compiere.

E poi? Dopo questo sarà necessario iniziare a correggere gli errori commessi, sostituendo gli elementi incriminati o fornendo le alternative testuali adeguate, tenendo presente che considerare problemi del genere nelle prime fasi della progettazione avrebbe evitato molti problemi.

HTML5 ed il futuro di internet

Dopo aver parlato di standard web e della contrapposizione tra W3C e WCAG Samurai, è indispensabile fare chiarezza anche sul futuro dell’HTML.

Da tempo è avviata una discussione sulla specifica migliore per internet, e la strada sembra dividersi su due possibilità: HTML5 e XHTML2.

Da un determinato punto di vista sembrerebbe più logico passare da XHTML 1.0 alla specifica 2.0, non è però detto che le cose seguano questa direzione, anzi. I produttori di browser sembrano preferire una nuova versione dell’HTML, e molte discussioni degli ultimi mesi indicano la stessa strada, tanto che il W3C è tornato sui suoi passi.

Per capire qualcosa di più sulla questione, consiglio a tutti gli interessati la lettura di un ottimo articolo di Maurizio Boscarol, commenti compresi. E’ una serie di domande e risposte che permette di comprendere meglio lo scenario futuro del web. Il post è stato creato a Maggio, ma viene aggiornato ogni tanto con nuovi elementi.

Stiamo parlando dello sviluppo di un linguaggio che occuperà molti dei prossimi anni, ma è fondamentale che si individui fin da ora la direzione giusta per non cadere in inutili perdite di tempo.

Se volete inoltrarvi nella disputa tra HTML5 e XHTML2, vi segnalo anche un articolo di HTML.it, traduzione di un ormai famoso intervento di David Andersson su Digital Web Magazine.

L’accessibilità tra W3C e WCAG Samurai

Più di un anno fa, Joe Clark aveva attaccato il W3C e le sue linee guida sull’accessibilità in un articolo ormai famoso di A List Apart. Era evidente che la situazione avrebbe portato a qualche clamorosa conseguenza, ed infatti di lì a poco sorse WCAG Samurai, un’iniziativa indipendente che si proponeva di scrivere delle proprie linee guida.

Dopo un lungo periodo di attesa, sono da poco state pubblicate le WCAG Samurai Errata, segnalate da Roger Johansson: delle indicazioni che vanno ad integrare e correggere le WCAG 1.0, pur usandole come base.

Si compongono di due parti: un’introduzione che spiega come interpretare il documento, e le linee guida vere e proprie. La differenza principale è la sinteticità: non c’è spazio per equivoci. Ecco alcuni punti principali:

  • Le tabelle per il layout sono proibite
  • I frames sono proibiti
  • Il codice delle pagine deve essere valido
  • Il codice delle pagine deve essere semanticamente valido
  • Gli attributi accesskey e tabindex sono proibiti

Davanti ad uno scenario del genere, cosa aspettarsi? E’ interessante vedere un sempre maggiore fermento verso le tematiche legate all’accessibilità della rete, ma ci sono anche dei rischi.

Se il movimento finisse per frammentarsi in una serie di indicazioni differenti tra loro, secondo voi cosa succederebbe? Probabilmente i produttori di browser si sentirebbero ancora più autorizzati a decidere autonomamente, cosa che la Microsoft ha cercato di fare per anni imponendo le proprie scelte come standard, grazie alle sue quote di mercato.

La speranza è che tra W3C e WCAG Samurai si riesca a definire uno standard unico, evitando di restare imbrigliati in burocrazie eccessive. Staremo a vedere cosa ci riserverà il futuro.