Tag: W3C

Tutto sul W3C, il World Wide Web Consortium. Organizzazione internazionale non governativa che promuove lo sviluppo di internet e vuole diffondere la cultura dell’accessibilità della rete.

Free Site Validator: HTML valido su un intero sito

Un nuovo servizio permette di controllare la validità del codice HTML di un intero sito e di ricevere il resoconto via email.

Fino ad ora per controllare la validità del codice HTML di un sito l’unico strumento disponibile era il validatore del W3C. Sicuramente efficiente per effettuare verifiche su singoli documenti, ma inutilizzabile su siti con centinaia di pagine.

Grazie alla segnalazione del sempre eccellente Roger Johansson ho scoperto Free Site Validator: come si può intuire dal nome questo servizio permette di validare il codice di un intero sito dopo essersi registrati ed avere inserito l’URL. In questo momento proprio a causa della segnalazione di 456 Berea Street il sito ha subito un deciso rallentamento ed i report non sono immediati, ma poterli ricevere via email evita ogni problema: l’attesa è comunque accettabile.

Free Site Validator permette di:

  • Controllare la validità di tutte le pagine di un sito partendo da un indirizzo: il report mostra un link alle pagine con errori, identificandoli.
  • Verificare la presenza di link a pagine inesistenti: vengono evidenziati i link errati e la pagina dove sono stati inseriti.
  • Installare su Ubiquity il comando validate per controllare al volo qualsiasi pagina con il validatore del W3C (per sapere cos’è Ubiquity ti consiglio questo post).

Il servizio è veramente buono ed al momento insostituibile, l’unico dubbio è se sia in grado di sopportare il gran traffico che sarà generato col passare dei giorni e con l’aumento della sua popolarità.

Finchè la velocità del sito è accettabile approfittatene: io ho ricevuto il report di TomStardust.com (quasi 600 pagine) dopo qualche ora.

L’accessibilità per i daltonici

Dal daltonismo agli altri disturbi della percezione dei colori: consigli e link utili per realizzare un sito accessibile.

Il daltonismo è spesso considerato l’unico problema nella visione dei colori, e nella relativa incapacità di distinguere il rosso dal verde.

In realtà la problematica è più ampia e complessa. Le percezioni possibili dei colori sono varie e riguardano buona parte della popolazione: l’8% dei maschi e l’1% delle femmine. Il daltonismo è solamente quella più diffusa, ed i colori problematici non sono solamente il rosso ed il verde.

Ragionando in termini percentuali, è comprensibile come la realizzazione di un sito accessibile anche a questa categoria di persone sia fondamentale.

Per non avere problemi a riguardo esistono da tempo gli standard web definiti dal W3C: i colori del testo e dello sfondo devono avere un sufficiente contrasto, sia per tenere conto delle persone che percepiscono i colori in maniera differente, che per la visione su schermi monocromatici.

Strumenti per la scelta dei colori

Fortunatamente esistono diverse risorse per poter realizzare siti che siano accessibili e attenti anche a queste tematiche. Tra i collegamenti più utili:

  • Colorblind Web Page Filter: un tool utilissimo per visualizzare una pagina esistente con diversi filtri attivi, ad esempio cecità al verde e rosso, o al blu e al giallo.
  • Ruota dei colori accessibili: scelti due colori, il risultato indica se il contrasto è sufficiente e se la combinazione è accessibile a tutti.
  • Colour Contrast Check: così come il tool precedente, indica se la combinazione di due colori selezionati rispetti gli standard indicati dal W3C. Segnala anche se i colori si avvicinano al valore corretto.
  • Colour Contrast Analyser (estensione per Firefox): un’estensione (installabile solo se registrati su addons.mozilla.org) per il browser di casa Mozilla che consente di risparmiare tempo nell’analisi del DOM di una pagina. Utilizzandola viene mostrata una tabella con tutte le combinazioni di colori di testo e background presenti, indicando se superano i requisiti minimi. Attenzione: non tiene conto delle immagini di sfondo e degli stati :hover nel CSS.
  • GrayBit: un tool che converte una pagina esistente in bianco e nero, per poter verificare se tutti i testi sono leggibili anche in versione monocromatica.
  • Contrast Analyser 2.1 (software): un semplice programma per Windows e Mac che consente di controllare il contrasto tra due colori specificati. Interessante la differenza di valutazione tra font di diverse dimensioni.

Raccomandazioni e consigli finali

Anche se la scelta di una combinazione di colori accessibile può sembrare un compito semplice, è necessaria attenzione soprattutto per i dettagli, che spesso fanno la differenza.

Un esempio può essere il contrasto tra testo ed immagini di sfondo, frequentemente trascurato. Altro caso è quello del mouseover: capita spesso di avere un contrasto sufficiente sullo stato normale dei link, per poi vedere combinazioni improponibili sugli stati :hover, :active e simili.

A volte può essere difficile mantenere un buon contrasto in tutte queste circostanze, ma per siti che si dichiarano aderenti agli standard è fondamentale che il testo sia sempre leggibile, in ogni situazione.

Concludo segnalandovi un recente test per misurare il vostro “Color IQ”: con un pò di pazienza ed un buon monitor potrete rendervi conto se avete difficoltà nella percezione dei colori.

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.