Web Design

WCAG 2.0: le nuove linee guida

La seconda versione delle WCAG raggiunge lo stato di Proposed Recommendation: ecco tutto ciò che occorre sapere sulle nuove linee guida.

Dopo aver atteso a lungo, il 3 Novembre 2008 le WCAG 2.0 hanno raggiunto lo stato di Proposed Recommendation: il rilascio finale è questione di poco tempo, si parla di fine anno.

Sono passati diversi anni da quando è iniziato lo studio di una seconda versione per linee guida del W3C: basti pensare che le WCAG 1.0 risalgono al 1999. Già nel 2006 affrontai l’argomento su questo blog, parlando della presa di posizione di Joe Clark sulle pagine di A List Apart; da allora sono stati fatti diversi passi avanti, già evidenti al raggiungimento dello stato di Candidate Recommendation nel Maggio scorso.

12 linee guida

Le WCAG 2.0 sono costituite da 12 punti. In questi criteri vengono riassunte tutte le problematiche relative all’accessibilità, con l’obiettivo di dare indicazioni generali, non legate ad una particolare tecnologia o dispositivo. L’obiettivo viene così raggiunto senza perdersi in linee guida troppo specifiche e limitanti.

Ognuno dei 12 punti è poi suddiviso in 3 (o meno) livelli di conformità: le già famose A, AA, AAA, che servono ad indicare quali siano le priorità.

Cosa cambia dalle WCAG 1.0 alle WCAG 2.0

Chi da sempre si preoccupa di realizzare siti accessibili indipendentemente dai requisiti obbligatori e dalle linee guida può rimanere tranquillo. L’obiettivo delle WCAG 2.0 è proprio quello di avere delle indicazioni universali, indipendenti dalla tecnologia e dal dispositivo utilizzati: se vi siete preoccupati di realizzare dei siti accessibili preoccupandovi dei problemi reali e non semplicemente di seguire delle regole, molto probabilmente non dovrete cambiare niente.

Se volete approfondire il discorso e scoprire le differenze, è comunque disponibile una bozza comparativa tra tutti i checkpoint delle WCAG 1.0 e delle WCAG 2.0 appena pubblicate.

Risorse utili

Per non rimanere disorientati dall’enorme documentazione disponibile, ecco alcuni punti di riferimento per capire meglio e poter seguire senza problemi le WCAG 2.0:

  • L’accessibilità è 2.0: un ottimo articolo di Punto Informatico sulle nuove linee guida.
  • Understanding WCAG 2.0: una guida del W3C per capire ed implementare ogni singolo punto delle WCAG.
  • Techniques for WCAG 2.0: tutte le informazioni tecniche necessarie per osservare i requisiti, facendo riferimento a HTML, CSS e altri linguaggi. Interessanti anche gli esempi relativi al mancato rispetto delle linee guida.
  • Accessible forms using WCAG 2.0: una guida completa per realizzare form realmente accessibili

Se conoscete altre risorse utili disponibili, segnalatele e provvederò ad aggiungerle in questa pagina.

Guida all’utilizzo di ID e classi nel codice HTML

Consigli utili per ottimizzare il codice HTML, mantenendo separato il contenuto dalla presentazione.

Nello sviluppo di un sito spesso ci si preoccupa degli aspetti più complessi per poi dimenticare i dettagli elementari. All’interno del codice HTML hanno una notevole importanza ID e classi, ma capita di utilizzare questi attributi senza attenzione, in maniera spesso controproducente.

In ogni progetto è fondamentale considerare almeno due aspetti riguardanti il codice delle pagine:

  1. le possibilità di sviluppo future
  2. la leggibilità

Per ottenere i migliori risultati e soprattutto consentire a chiunque di comprendere il codice HTML, è sufficiente ricordarsi alcuni punti ben illustrati sul blog di Jens Meiert che ho voluto approfondire.

1. Ridurre al minimo ID e classi

Finchè è possibile, evitate di appesantire il codice HTML e sfruttate i selettori discendenti dei CSS. Sono uno strumento potente, e potrete così limitare gli ID ai contenitori principali (ad esempio #container, #header, #nav…). Potrebbe sembrare un dettaglio di poco conto, ma con la pratica vi accorgerete che questa non è un’indicazione assurda, anzi.

Ovviamente su elementi che hanno bisogno di personalizzazioni su misura (ad esempio un’icona associata) è indispensabile l’uso di classi ad hoc, ma questo modo di pensare sarà molto utile anche in futuro con i selettori dei CSS3. Sarete già pronti ad utilizzarli senza dover cambiare le vostre abitudini di lavoro.

2. Utilizzare nomi relativi alla funzione dell’elemento

Uno degli errori più comuni è usare per ID e classi un nome relativo all’aspetto dell’elemento e non alla sua funzione. Un esempio potrebbe essere .red_text invece di .alert. Commettendo questo errore resterete vincolati, ed in futuro non potrete cambiare la visualizzazione di quel particolare elemento senza modificare anche il nome dell’attributo. Avere una classe .red_text che fa riferimento ad un elemento di colore diverso dal rosso sarebbe assurdo!

A questo proposito non ci sono degli standard (anche se non sarebbe male averli), ma è buona pratica usare nomi come #menu o #nav per la navigazione, #content per il corpo centrale del sito, #header e #footer per testata e piede. Osservando i layout dei web designer più famosi potete farvi un’idea di quali siano le convenzioni più diffuse.

3. Sintetizzare in maniera comprensibile

Per velocizzare il lavoro ed evitare di avere fogli di stile esageratamente lunghi è sempre meglio cercare di usare nomi brevi per ID e classi. Questo però non deve andare a scapito della comprensibilità: #nav è sicuramente meglio di #navigation, ma usare .wdg al posto di .widget sarebbe esagerato.

Quelli mostrati sono dettagli elementari: proprio per questo andrebbero sempre tenuti presenti. Non pensate che siano aspetti poco importanti, la realizzazione di un buon sito inizia proprio dal codice scritto. A questo proposito, quali sono le vostre convenzioni per l’uso di ID e classi? Lasciate un commento per discuterne insieme.

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.

Quando ottimizzare un sito per IE6?

I criteri da utilizzare per decidere quando trascurare Internet Explorer 6 nello sviluppo di un sito web.

Il 3 e 4 Novembre 2008 si terrà a New York l’annuale conferenza Future Of Web Design. Per pura curiosità (e deformazione professionale) dopo aver visitato il sito dell’evento ho scoperto che non è ottimizzato per Internet Explorer 6 e mi sono trovato davanti un banner con il suggerimento di installare Firefox o Safari:

Essendo un sito realizzato da professionisti del settore, ho deciso di indagare più a fondo per capire le ragioni di una tale scelta. Il passo successivo è stato controllare Carsonified, del team organizzatore dell’evento. Anche questo non viene visualizzato correttamente con IE6.

Che sia quindi ora di trascurare questo browser? Ad un primo esame sembra che anche i più noti web designer non se ne preoccupino.

In realtà le cose non sono esattamente così. Basta visitare i siti del portfolio di Carsonified per rendersene conto. Portali come Vitamin, o applicazioni web come DropSend e Amigo, sono perfettamente funzionanti anche su IE6.

C’è un motivo dietro a questa scelta? Ovviamente sì, niente è lasciato al caso in queste situazioni.

Se il sito di una conferenza sul web design, frequentato da professionisti, può permettersi di trascurare IE6, così non può essere per delle web applications che devono affermarsi in rete, ed hanno bisogno del maggior numero di utenti possibile.

Tutto dipende dal target dei visitatori, che condiziona le strategie di sviluppo di un progetto: che sia un blog, un sito, o un’applicazione non fa alcuna differenza.

Il criterio è chiaro, ed a mio parere è la scelta più corretta da fare in questo momento. Liberarsi di Explorer 6 come se non esistesse è prematuro. La sua quota mondiale di diffusione è ancora pari al 25% e non è possibile trascurarlo.

Se avete intenzione di realizzare un sito e sapete in partenza che sarà visitato da utenti comuni, dovrete continuare a preoccuparvi anche del browser Microsoft per qualche tempo.

Il discorso cambia se siete alle prese con un sito per un target di superutenti, ma questa al momento è ancora un’eccezione, non la regola.

Ricordate però che tutta l’ottimizzazione che farete sarà comunque un grande valore aggiunto, che potrete offrire al cliente quali professionisti del settore. Sfruttate la possibilità, non nascondetevi dietro a delle scuse, e vedrete anche IE6 sotto un’altra luce.

Guida per una navigazione usabile

Una guida completa per organizzare la navigazione di un sito, evitando gli errori più comuni.

Realizzare un sito usabile è un obbligo per ogni web designer professionista. Spesso però non viene riservata sufficente attenzione alla navigazione, dimenticando che un visitatore non tornerà mai su un sito dove non è capace di trovare ciò che cerca.

A questo proposito mi sono permesso di prendere spunto e reinterpretare un interessante post di ifohdesigns, per approfondire la questione suddividendola per argomenti.

Vincoli

Prima ancora di affrontare l’organizzazione della navigazione, è bene analizzare i vincoli presenti. Inutile pensare ad una soluzione se questa non è praticabile, ogni modello deve essere costruito in base al sito.

I limiti più evidenti, che spesso impediscono di seguire una scelta piuttosto che un’altra, sono:

  • il numero di pagine del sito
  • la gerarchia delle pagine e la struttura generale
  • lo stile grafico ed il layout

Consigli e divieti

Per migliorare la navigazione di un sito, è fondamentale non incorrere in gravi problemi di accessibilità ed usabilità. Alcune regole sono ovvie, ma non è mai scontato ricordarle:

  • non usare Flash per i menu
  • utilizzare JavaScript solo se i menu restano accessibili anche senza script abilitati
  • se usate delle immagini, fatelo tramite CSS con una tecnica di image replacement, senza inserirle direttamente nel codice html
  • cambiando le immagini di sfondo con i CSS, create degli sprite per evitare fastidiosi ritardi al caricamento

Posizione dei menu

I menu di navigazione possono essere posizionati in maniera più o meno originale, ma le collocazioni standard sono tre. Ci possono essere altre soluzioni, ma è meglio non esagerare con la fantasia:

  • menu orizzontale sotto l’header, se non ci sono troppe voci
  • menu orizzontale sopra l’header, per link secondari
  • menu verticale, solitamente a sinistra, facendo attenzione che le voci importanti siano visibili a colpo d’occhio e non scendano oltre i 600-700 pixel

Coerenza

La navigazione dovrebbe essere coerente su tutte le pagine del sito. Una volta decisa la struttura, è fondamentale non cambiare la posizione dei menu o modificarne l’aspetto a seconda della pagina, perchè il visitatore potrebbe rimanere disorientato.

A volte capita di trovare siti con sezioni dove manca la navigazione, con un semplice link “torna alla homepage”. Una soluzione simile non è sufficiente.

Attributi title

E’ importante non dimenticare di fornire maggiori informazioni sui link tramite gli attributi title dell’HTML. Alcune pagine possono avere nomi convenzionali e autoesplicativi, ma è sempre meglio semplificare la vita dell’utente.

Inoltre usare dei title coerenti può favorire una corretta indicizzazione sui motori di ricerca, rendendo anche il sito più accessibile.

Gerarchia

Se un sito contiene numerose pagine, non è mai conveniente metterle tutte sullo stesso livello. Meglio organizzarle in gruppi, suddividendo la navigazione per facilitare la comprensione.

A volte potrebbe bastare raccoglierle in un menu secondario, da mostrare solo quando necessario.

Breadcrumb (Briciole di pane)

Se il sito è complesso, è essenziale avere sempre visibile il percorso della pagina corrente. In certi casi può essere utile visualizzare il path anche su un blog, se esistono molte pagine distribuite su più livelli.

Come si può intuire dal nome, le briciole di pane aiutano l’utente a ritrovare la strada, capire quali pagine ha visitato e decidere quali visitare successivamente.

Footer

Fino a qualche anno fa era considerato un elemento di scarsa importanza, finchè non hanno iniziato ad apparire footer alti, ricchi di link. E’ un modo per permettere all’utente di continuare la visita del sito una volta arrivato a fine pagina.

Il footer non è ovviamente da utilizzare per la navigazione principale, ma non va sottovalutato.

Conclusioni

Organizzare la navigazione non è cosa semplice. Le variabili da considerare sono numerose e non tutte facili da gestire, soprattutto su siti con una struttura complessa.

La cosa più importante è curarsi di tutti gli aspetti, tenendo presente il target di utenti, la coerenza dei menu di navigazione e l’accessibilità degli stessi. Un menu in flash per quanto possa essere attraente impedirà a tutti i visitatori senza plugin di visitare le vostre pagine.

Se ne avete la possibilità fate dei test di usabilità, anche con parenti o amici: scoprirete cose impensabili. Con un minimo di buon senso potrete ottenere ottimi risultati.

A List Apart sta cambiando

Jeffrey Zeldman parla di come A List Apart si stia evolvendo, per abbracciare sempre più tematiche continuando a mantenere alta la qualità delle pubblicazioni.

Che A List Apart sia un punto di riferimento per i web designer di tutto il mondo è un dato di fatto. Zeldman in un interessante articolo pubblicato in questi giorni sul suo blog, parla della sua creatura e di come si stia evolvendo nel corso degli anni, senza per questo rinunciare ad una ben affermata identità.

Scorrendo le pagine del sito, gli archivi arrivano fino al Marzo 1999. Si parla di fogli di stile, che all’epoca erano ancora praticamente sconosciuti: questo per capire l’importanza dei temi che venivano e vengono tuttora affrontati.

Più in generale, A List Apart ha da sempre guidato la crociata per l’affermazione ed il rispetto degli standard web, parlando di web design e programmazione. L’ha sempre fatto rivolgendosi a coloro che fin da subito sono stati capaci di capire in quale direzione si stava muovendo internet, cercando anche di educare chi manteneva atteggiamenti conservatori.

Dopo diversi anni però, è naturale che le cose cambino, o meglio si evolvano.

Evoluzione futura

Come sarà il cambiamento? In realtà sta già avvenendo, e non da pochi mesi.

Web standards are in our DNA and will always be a core part of our editorial focus. Standards fans, never fear. We will not abandon our post. But since late 2005, we have consciously begun steering ALA back to its earliest roots as a magazine for all people who make websites—writers, architects, strategists, researchers, and yes, even marketers and clients as well as designers and developers.

Zeldman afferma che i temi affrontati fin dalla creazione di A List Apart continueranno ad essere sostenuti, ma il target fin dal 2005 sta consapevolmente cambiando. Non più esclusivamente sviluppatori, ma anche copywriter, architetti dell’informazione, esperti di marketing e clienti, che vanno ad allargare la base di utenti del sito.

Qualità o quantità?

Questo cambiamento però non influirà con la qualità delle pubblicazioni, e che Jeffrey Zeldman si sia attivato per dichiarlo personalmente è un’ottima garanzia.

Tornando a citare le sue parole:

We review hundreds of articles and publish dozens. Some web magazines seem to have those proportions reversed, and some readers don’t seem to mind, and that’s fine. But any content you see in ALA has been vetted and deeply massaged by the toughest editorial team in the business.

A mio parere è proprio questa la forza di A List Apart, ciò che distingue le sue pubblicazioni da tanti altri siti che parlano di sviluppo sul web. I suoi articoli sono relativamente pochi (in media 2 a settimana), ma selezionati tra centinaia con grande severità.

E’ facile ottenere numerose visite pubblicando più post al giorno tutti uguali, senza dire niente di veramente originale, ma questo non è il loro obiettivo.

Conclusioni

Chi legge abitualmente A List Apart si sarà già accorto del cambiamento. Adesso la cosa è ufficiale, e probabilmente gli articoli su CSS e web standards saranno meno frequenti, ma sicuramente non spariranno. In compenso le pubblicazioni potranno interessare un bacino di utenti molto più ampio.

Se in passato avete scartato l’idea di seguirne gli articoli perchè gli argomenti trattati erano troppo tecnici, potrebbe essere il momento giusto per rivedere la vostra scelta.

Separatori e linee orizzontali da Smashing Magazine

Il sito di risorse per Web Designer pubblica una incredibile raccolta di separatori per pagine web, da scaricare gratuitamente.

Che Smashing Magazine sia una risorsa da seguire con attenzione per ogni sviluppatore web è ormai un dato di fatto. In due anni di vita (appena compiuti) hanno rilasciato un’incredibile quantità di materiale di ottima fattura, tale da non temere confronti con altri siti del genere.

Questo post è per segnalarvi una collezione di separatori di pagine web di ottima qualità. In genere non scrivo interventi simili, ma questa a mio parere è una delle migliori release di Smashing Magazine; tra l’altro il materiale è totalmente gratuito e può essere utilizzato per progetti personali senza alcun vincolo. E’ disponibile anche un archivio con i files originali di maggior parte delle proposte.

I separatori potrebbero servirvi anche come fonte di ispirazione per gli <hr> dei vostri lavori. Io ne ho appena approfittato per modificare TomStardust Diary, partendo da questa immagine:

Mi piaceva l’idea di base ed ho realizzato qualcosa di simile, che potesse integrarsi bene con la grafica del mio blog personale:

Come sempre, altre segnalazioni e pareri sono ben accetti nei commenti; se però nel vostro feed reader non avete ancora Smashing Magazine vi consiglio di rimediare!

Apre TomStardust Diary

Online il mio nuovo blog personale, per parlare di cinema, libri, musica e tutto ciò che non è inerente al Web Design.

Da tempo sentivo la necessità di un mio spazio personale, un blog dove parlare liberamente di tutte le mie passioni senza dover per forza sottostare ai vincoli di un sito esclusivamente tecnico come TomStardust.com.

Dopo aver annunciato a fine Luglio l’inizio dei lavori, oggi finalmente apre TomStardust Diary.

Mi ha fatto piacere condividere la fase di sviluppo con gli iscritti alla newsletter, che hanno potuto accedere al nuovo blog durante la lavorazione in una sorta di beta privata. Il risultato finale è leggermente diverso dalla bozza grafica che avevo realizzato, ma non si discosta molto dall’idea originale.

Anche questo nuovo blog è realizzato su piattaforma WordPress, ed il template è realizzato interamente da zero. Ho optato per un layout fluido, mettendo in evidenza il post più recente e riservando sulla barra laterale uno spazio a YouTube: è innegabile che i video siano sempre più parte integrante della rete.

Per gli amanti dei browser preistorici, ho continuato a supportare anche IE6. Ci sono però delle png trasparenti, angoli arrotondati tramite CSS per Firefox e Safari, ed alcuni effetti al mouseover.

Se avete voglia di seguirmi in questa nuova avventura, tra recensioni di film, libri, musica e concerti, con qualche escursione a cavallo tra notizie di cronaca e tecnologia, mi trovate su TomStardust Diary.

Allarme accessibilità in Italia

Voci preoccupanti fanno presagire la chiusura di uno dei pochi punti di riferimento per l’accessibilità in Italia. Cosa fare?

Apprendo ora dal blog di Marco Bertoni che l’ufficio accessibilità del CNIPA potrebbe essere chiuso. E’ una di quelle notizie che non avrei mai voluto dare, perchè quel poco che in Italia è stato fatto in ambito accessibilità deriva proprio da lì. Sapere che molto probabilmente nessuno si occuperà più di queste tematiche è inquietante.

Per saperne di più vi rimando al suo intervento, chiarissimo nell’analisi: le cause sono da ricercare nell’ostruzionismo delle multinazionali, nel ridicolo scenario delle web agency italiane, ma soprattutto nella disinformazione. E’ assurdo ritenere l’accessibilità come un costo aggiuntivo, un lusso che può essere anche trascurato: non è così, anzi!

A questo punto per tutti coloro che sono interessati al rispetto degli standard web, alla realizzazione di siti accessibili ed usabili, al lavoro fatto con professionalità, cosa resta da fare? Ovviamente non disperarsi, perchè è sempre possibile vedere riconosciuto il proprio valore.

In Italia esistono web designer di talento, che sanno quello che fanno e non realizzano siti con Frontpage (o Dreamweaver in modalità WYSIWYG che dir si voglia). Paradossalmente però non lavorano quasi mai nelle web agency o nelle grandi aziende, a cui tali tematiche non interessano e che spesso limitano l’alta professionalità dei dipendenti per lavori di bassa qualità.

Viviamo in un paese dove determinate capacità sono viste come un extra, un costo aggiuntivo non necessario, ma non per questo bisogna smettere di crederci. Conoscete aziende interessate a web standards ed accessibilità? Io nel panorama italiano ne conto veramente poche, ma se avete dei nomi sarei curioso di saperne di più.

Sarà sicuramente difficile diffondere le proprie idee in uno scenario simile, ma come dice lo stesso Marco, anche io credo in un cambiamento che parta dal basso. Riconoscere l’importanza di certi temi in questo momento di ignoranza è un vantaggio, e va tenuto ben presente. Quando anche in Italia inizierà a sorgere l’interesse per l’accessibilità del web, molti professionisti che ora lavorano per pochi euro potranno sfruttare tutto il bagaglio di conoscenze accumulato.

Certo, sarebbe tutto più facile con un riconoscimento ufficiale, ma se nemmeno le stesse associazioni sono in grado di tutelare i disabili che rappresentano, è difficile che cambi qualcosa nell’immediato.

Microsoft non mantiene le promesse su IE8?

Nella beta2 di IE8, i siti delle intranet vengono visualizzati in modalità non standard a causa di un’impostazione di default. Le promesse della Microsoft vanno in fumo?

E’ passato diverso tempo dal primo annuncio riguardante Internet Explorer 8, ed una delle promesse più eclatanti da parte della Microsoft riguardava la modalità Super-Standard. Questa modalità, capace di far visualizzare le pagine in maniera aderente agli standard web, sarebbe stata attiva di default.

Con l’uscita della beta2 di IE8 però, Hakon Lie di Opera ha pubblicato su The Register una sua scoperta: un’impostazione del nuovo browser forza tutti i siti delle intranet ad utilizzare il vecchio tipo di rendering, quello di IE7, chiamato Compatibility View.

La cosa ha ovviamente suscitato polemiche, accusando la Microsoft di non rispettare le promesse fatte: ma siamo sicuri che questa impostazione sia davvero così negativa?

Diciamolo chiaramente: in molte aziende le intranet sono realizzate male, e sarebbero impossibili da utilizzare con un browser che rispetti gli standard. Scenario paradossale, ma realistico, soprattutto in Italia. Cambiare browser renderebbe impossibile lavorare, e la Microsoft ne è consapevole.

Introdurre un’impostazione del genere consente di evitare problemi, garantendo su tutti gli altri siti una visualizzazione ottimale. Dal mio punto di vista concordo con Jonathan Snook, questa non è una tragedia: inutile conservare posizioni troppo zelanti sugli standard web.

Se vogliamo che Explorer 8 si diffonda tra gli utenti che non passeranno mai a browser come Firefox, Opera o Safari, dobbiamo eliminare una delle possibili scuse per non installarlo.

Resta comunque il problema IE6, che continuerà ad esistere in molti pc: tutti quelli dei dipendenti che lo usano perchè IE7 non funziona sulle loro intranet. In questo caso c’è ben poco da fare, se non rendersi conto che nel 2008 è assurdo (soprattutto per un’azienda) avere una pagina funzionante solo su Explorer 6, browser datato 2001.