Il nuovo sito del W3C

Un importante redesign per il sito del W3C, attualmente in beta.

Aggiornamento: il 13 Ottobre 2009 è stata pubblicata definitivamente la nuova versione del sito del W3C, non più in beta.

Il W3C ha da poco presentato la nuova versione del proprio sito, ancora in fase di sviluppo. Si tratta di un aggiornamento importante e doveroso, che va ben oltre il semplice restyling grafico. Potete vedere il nuovo sito all’indirizzo beta.w3.org.

La prima cosa che ho notato è il layout fluido, che continua a supportare elegantemente risoluzioni fino a 800×600. Il menu di navigazione inserito nella colonna sinistra è a larghezza fissa, mentre il resto del sito si adatta alla finestra del browser.

C’è uno slider JavaScript per le notizie in homepage e nel complesso il risultato è molto più ordinato rispetto a prima: è stato fatto anche un notevole lavoro di riorganizzazione dei contenuti. Sono cambiate inoltre le pagine della documentazione, come potete vedere nel caso delle specifiche XHTML 1.0.

Essendo una beta non mancano problemi, ma la direzione mi sembra quella giusta. Volendo cercare un difetto non sono molto convinto dell’ordine degli elementi nella pagina: il menu di sinistra appare prima del contenuto principale.

Se volete dare il vostro contributo, trovate maggiori informazioni su questa pagina. Ci sono anche alcune indicazioni per dei task da svolgere all’interno del sito, come cercare un tutorial HTML o la pagina dell’archivio news. Qualsiasi feedback inviato al W3C sarà ben accolto.

Il costo di un sito accessibile

Quanto costa l’accessibilità? Un’analisi dei fattori da considerare nella creazione di un sito accessibile.

Realizzare un sito accessibile ha dei costi, inutile negarlo. Che ci sia da creare un nuovo sito o adattarne uno esistente, non è un’operazione fattibile senza spese, nonostante sia in vigore una normativa come la Legge Stanca che è stata proprio approvata come a costo zero.

Su questo blog l’intervista ad Elena Brescacin, una sviluppatrice non vedente, è stata l’occasione per tornare sull’argomento ed è quindi giusto approfondirlo.

Il costo dipende dal progetto

Sembra una banalità, ma quando si parla di accessibilità molti si tirano indietro immaginando spese enormi. In realtà non è così: si tratta di un investimento. Realizzare un sito che segua gli standard web e sia accessibile non è sempre così complicato o dispendioso in termini di tempo come si potrebbe pensare.

Ovviamente per portali complessi il discorso cambia, ma parlando di blog, siti statici e progetti senza enormi pretese è possibile ottenere facilmente ottimi risultati. Cosa serve? Un team di lavoro (o uno sviluppatore) competente, che conosca gli standard del W3C e realizzi siti accessibili come se fosse una regola, non un’eccezione. L’accessibilità è anche questione di professionalità.

C’è una grande differenza anche se il progetto deve occuparsi della creazione di un sito completamente nuovo o della ristrutturazione di uno esistente. A volte dover progettare da zero è molto più semplice e veloce.

Parlando più concretamente, in certi casi basta veramente poco perchè un sito segua i requisiti minimi: codice ben organizzato, uso coerente dei titoli h1-h6 ed una navigazione intuitiva possono essere quantificati in poche ore di lavoro.  L’accessibilità non è solo questo, ma sarebbe già un passo avanti per la maggior parte dei siti esistenti.

I costi di formazione e manutenzione

Per non essere troppo di parte, è bene comunque mettere in chiaro che un sito accessibile non resta tale se non viene mantenuto a dovere.

Posso fare un esempio pratico con WordPress: realizzare un tema accessibile non è difficile, ma chi inserisce i contenuti deve essere istruito. Il rischio altrimenti è di trovarsi un ottimo contenitore riempito di spazzatura, che renderà inutile il lavoro fatto.

Per questo motivo in un progetto serio è necessario prevedere anche delle spese per la formazione di chi dovrà occuparsi dei contenuti e per interventi di manutenzione successivi, a meno che non si parli di siti statici.

L’accessibilità è un investimento

E’ bene comunque comprendere fin da subito che l’accessibilità è una grande possibilità. Un sito accessibile segue gli standard, viene indicizzato meglio dai motori di ricerca e quindi porta migliori risultati di un sito non accessibile o ancora peggio interamente realizzato con tecnologie come Flash.

La logica conseguenza di tutto questo è che pubblicando un sito accessibile i potenziali clienti di un’azienda aumenteranno, e ci sarà anche un ovvio ritorno dal punto di vista dell’immagine.

Non è un caso che all’estero, dove la situazione è molto più evoluta rispetto all’Italia, numerose aziende abbiano capito l’importanza degli standard web e dell’accessibilità. L’etica non c’entra, perchè non è quello che interessa veramente: certe scelte sono dettate da vantaggi concreti.

Conclusioni

Ho cercato di realizzare un quadro generale sui costi di sviluppo di un sito accessibile, ma a questo punto vorrei avere anche il vostro punto di vista. Le tematiche correlate sono numerose e sicuramente possono essere approfondite: cosa ne pensate?

Dite la vostra nei commenti, anche se non avete esperienze personali a riguardo ogni contributo è ben accetto.

Intervista ad Elena Brescacin: una Web Developer non vedente

Due chiacchiere con Elena “talksina” Brescacin sull’accessibilità della rete da un punto di vista pratico.

Elena Brescacin è una Web Developer non vedente classe 1980, con cui ho avuto l’occasione di collaborare recentemente per il suo blog personale.

Sono rimasto stupito dalla sua abilità e dalle capacità che ha dimostrato di avere, e così le ho proposto di fare un’intervista per questo sito. Le sue risposte possono essere utili più di tanti tutorial e linee guida, per far capire veramente cosa sia l’accessibilità e quanto sia importante ricercarla nello sviluppo di un sito.

Il risultato è una chiacchierata particolarmente lunga, ma quella di non sintetizzarla è stata una mia scelta. Spero che il risultato finale possa essere interessante per molti.

1. Ciao Elena, puoi fare una breve introduzione su di te?

Ciao, sono Elena Brescacin, 28 anni, cieca dalla nascita. Lavoro come web developer nel settore accessibilità dei siti web, ed ho tanti hobby tra cui la manipolazione dell’audio (realizzo jingle e suonerie), gli scacchi, l’arte marziale taekwon-do e generalmente dare una mano dove possibile ad amici blogger e webmaster.

2. Come sei diventata web developer? Quali strumenti usi per lavorare?

Ho iniziato da autodidatta nel 2000, dopo un paio di esperienze lavorative poco felici avute dopo la scuola superiore. Tramite html.it ho imparato a costruire le mie prime pagine web, il mio primo sito personale, con la possibilità di metterci gli audio e personalizzarlo a mio piacimento e soprattutto di capire che cosa gli altri sbagliassero quando i siti non erano accessibili.

L’interesse per l’accessibilità è venuto da solo, come esigenza di collaborazione tra utente disabile e sviluppatore (non c’è niente di meglio!). Poi ovviamente ho fatto dei corsi sull’argomento, e alla fine ho trovato lavoro nel mio settore.

Come strumenti, dipende dalle esigenze e dal lavoro; passo da prodotti commerciali a prodotti free, anche se la mia maggiore preferenza è per gli editor di codice, più che quelli visuali: questi ultimi mi complicano parecchio la vita in quanto le opzioni sono tutte grafica e punta-e-clicca, cosa che a un vedente aiuta, a un cieco invece crea solo problemi.

3. Quali problemi hai trovato nello svolgere il tuo lavoro, ad esempio con CMS come WordPress?

Come già detto, i problemi sono specialmente imputabili alle funzionalità degli editor visuali; io mi riferisco chiaramente soltanto alla disabilità visiva perché è quella che conosco, ma il problema riguarda tutti.

Che gli editor siano dei programmi per desktop, oppure implementati all’interno di un CMS free o commerciale, spesso gli sviluppatori non tengono conto delle esigenze di accessibilità nelle funzioni facilitate (pulsanti per aggiungere link, immagini, spostare oggetti, ecc) per cui con questi applicativi si possono realizzare siti completamente accessibili lato utente, ma lato amministratore non si riesce a fare quasi nulla.

Il risultato è che un cieco che voglia intraprendere l’esperienza dello sviluppo web, deve avere un’ottima conoscenza del linguaggio di marcatura o programmazione usato per il proprio applicativo. L’unico modo per poter gestire contenuti è quello di disabilitare l’editor visuale e scrivere il codice in formato testo, o comunque trovare degli escamotage che in quanto tali, rallentano di molto il lavoro.

Io sono una lottatrice e non mi lascio certo spaventare da un editor, però molti miei “colleghi” anche loro giovani, si sentono scoraggiati dall’esperienza del web perché costretti in qualche modo ad imparare un linguaggio, mentre i loro compagni vedenti possono sviluppare siti anche senza saper niente di codice.

Certo la padronanza di almeno un linguaggio di marcatura, scripting o programmazione, è un vantaggio perché aiuta a costruire meglio i siti e gli applicativi; di contro, lo svantaggio è che ci sono pochissimi sviluppatori ciechi e per questo l’accessibilità del web è poco sentita, considerata solo una cosa da addetti ai lavori, più che un’esigenza di molti. E le associazioni di categoria fanno troppo poco rispetto alle lacune che si dovrebbero colmare.

4. Hai un esempio pratico di problemi con l’amministrazione di WordPress?

Quando parlavo di “escamotage” posso fare un riferimento concreto: il sistema di widget di WordPress.

Nella versione 2.3 era a dir poco impossibile avere una barra laterale dinamica: i widget erano soltanto trascinabili tramite il mouse quindi mi dovevo far aiutare ogni volta.

Dalla 2.5 per fortuna hanno introdotto un link “aggiungi”, “modifica”, “rimuovi”… in modo che io posso anche da tastiera mettere e togliere i widget a piacimento. Il problema rimane nello spostarli: non posso accedere al drag&drop fattibile solo da mouse, quando basterebbe accanto a ogni widget aggiunto un paio di link “sposta su” e “sposta giù”.

L’escamotage sta nel crearsi un file di testo con tutti i nomi dei widget desiderati, poi rimuoverli tutti, e riaggiungerli uno a uno secondo l’ordine nuovo desiderato. Lavoraccio che, uno fa una volta, la seconda non lo fa più!

5. Quali sono i problemi principali con cui ti scontri navigando su internet, nonostante la tua esperienza?

I captcha.

Uno dei maggiori problemi che un cieco incontra navigando su internet, è oramai la quasi onnipresenza dei captcha, nati per impedire a chi fa pubblicità indesiderata di accedere ai vari servizi: dai semplici commenti su siti o blog, alle registrazioni su portali più complessi e piattaforme di commercio elettronico.

Talvolta questi test sono accompagnati da controlli audio, ma anche questi spesso e volentieri o sono solo in inglese, oppure non si sentono e non si capiscono. Il risultato è che le aziende che fanno pubblicità indesiderata hanno le fonti di reddito per aggirare questi controlli come vogliono, costruendo dei sistemi di calcolo sofisticati, oppure semplicemente pagando pochi dollari a studenti adolescenti ai quali, per dire, basta avere garantita ogni mese la ricarica del cellulare per compilare a mano i sistemi anti-robot.

Un cieco, da queste misure, sarà sempre e comunque discriminato per vari motivi:

  • la privacy che i captcha dovrebbero proteggere, viene nel nostro caso automaticamente violata in quanto dobbiamo dare, o far vedere, i nostri dati sensibili a terze persone. Quando si tratta di password o numeri di carta di credito, sinceramente, la fiducia vale ma sempre fino a prova contraria… per non parlare poi del fatto che ci son servizi che chiedono di compilare un test di sicurezza visuale pure per cambiare o ripristinare la password. Lasciamo stare.
  • anche trovando i siti di studenti che risolvono i captcha (onestamente ammetto di aver tentato di contattarne uno), dicono NO, in quanto loro compilano sì i captcha a 3 dollari l’uno, però devono aver la garanzia di doverne compilare almeno 100. E all’epoca me ne serviva uno.

Un altro grosso problema di accessibilità si ha quando si usano certe funzionalità AJAX, in cui i link sono cliccabili ma non sono visualizzati come tali. Un esempio è la versione standard di GMail, o molti siti di home banking, di cui posso usufruire solo navigando la pagina come se fosse un file Word anziché usare tutti i comandi rapidi che gli screen reader mi offrono.

Poi i flash che scorrono o che non hanno etichette nei controlli, i form con il focus che si muove in automatico sulle caselle di selezione o sui campi di testo, ed immagini e controlli senza testo alternativo.

6. Parlando invece di non vedenti senza la tua esperienza, com’è la situazione attuale della rete? Quali sono i problemi più diffusi?

La situazione è abbastanza difficile da due punti di vista: ci sono dei non vedenti senza esperienza che non hanno voglia di imparare e mettono in difficoltà gli sviluppatori chiedendo sempre la pappa pronta; dall’altro lato alcuni web developer pensano che la creatività venga limitata dall’accessibilità, ed i problemi continuano a rimanere.

L’unico modo per avere una rete accessibile è rispettare gli standard, evitando di “inventarsi” i metodi: ad esempio a che cosa serve creare i punti elenco con delle immagini, quando in HTML ci sono gli attributi ben definiti che permettono di mettere pure i disegnini ma lasciando la lista completamente accessibile?

Parlando dei blog, dovrebbero essere sempre accessibili anche tramite la tastiera, con la possibilità di attivare e disattivare la visualizzazione dei link non indispensabili come i tag: spesso e volentieri questi sono anche una decina per ogni articolo, il che può creare problemi (gli screen reader scorrono tutti i link di una pagina uno ad uno NdTom). Una soluzione per WordPress è in questo articolo di Studio404.

Una considerazione anche sul tabindex: viene messo come requisito di accessibilità, ma mi sento di consigliarlo quasi esclusivamente per i siti statici. In un sito dinamico come un portale o blog non si può mai avere un ordine logico definitivo e la navigazione tramite tab dall’inizio alla fine del blog è fondamentale. Usando il tabindex invece si altera l’ordine di scorrimento, ed il risultato è che un cieco non esperto viene costretto a saltare alcune parti, leggendo come minimo solo un 50% di quello che leggerebbe normalmente.

7. Ci sono dei siti “popolari” a cui vuoi rivolgere delle critiche perchè non accessibili?

Mi creano difficoltà i siti di news: ANSA, Corriere della Sera, Repubblica, Oggitreviso e altre testate giornalistiche che sono piene di Flash e pubblicità che scorrono. Un quotidiano non dovrebbe in alcun modo avere questi problemi! Benedetto chi ha creato i Feed RSS che mi permettono di leggere e scegliere i titoli che mi interessano.

8. Che consigli daresti agli sviluppatori interessati all’accessibilità dei propri siti?

Il consiglio che vale sempre è quello di attenersi più possibile agli standard del W3C, più specificamente alle WCAG 2.0 che, rispetto alla versione precedente, si riferiscono a tutte le tecnologie e non soltanto all’HTML.

Certo non si può imparare tutto a memoria, ma capire e conoscere gli standard è già un buon passo avanti. Inoltre c’è da considerare che non si può parlare di accessibilità senza citare l’usabilità; presentazione e contenuto vanno equilibrati per venire incontro alle esigenze di tutti, non soltanto alla propria creatività.

9. In conclusione, vorresti aggiungere qualcosa?

Solo che sarebbe ora di restituire al web il suo significato originale: worldwide web.

Tutti digitano www sulla barra indirizzi ma non sanno nemmeno cosa significa! La rete dovrebbe essere universale, ma oramai tutti (privati e aziende) vedono il web a modo loro senza rispettare l’accessibilità.

Ci sono situazioni in cui la mancanza di accessibilità può davvero nuocere al diritto sacrosanto di riservatezza delle persone. Basti pensare ai siti riguardanti la salute: un cieco con il bisogno di informazioni su specifici problemi medici sarà costretto a condividere per forza i problemi di salute con qualcuno, magari tutto per colpa di un captcha.

Se tutti gli sviluppatori avessero un po’ più di rispetto e sensibilità verso i fruitori delle loro creazioni, disabili o no, il web sarebbe migliore.

HTML5: approfondimenti ed evoluzioni future

Una raccolta di materiale sulla specifica HTML 5, tra problemi di compatibilità presenti ed evoluzioni future.

Sono passati due anni e mezzo dalla pubblicazione dell’ultima bozza sulle specifiche XHTML 2.0 E’ passato più di un anno dalle discussioni su quale dovessere essere la direzione da seguire: XHTML 2.0 o HTML 5?

In questo contesto, sembra che negli ultimi tempi la questione abbia subito una decisa accelerata: si parla sempre più insistentemente di HTML 5 e molto probabilmente il 2009 sarà l’anno della sua affermazione.

Approfondimenti sulla specifica HTML 5

Per chi volesse saperne di più e scoprirne le basi è disponibile una Working Draft che illustra numerosi dettagli, i nuovi elementi a disposizione degli sviluppatori e l’utilizzo che ne dovrebbe essere fatto.

Inoltre proprio in questi giorni è stato pubblicato anche su A List Apart l’articolo Semantics in HTML 5 che affronta diversi argomenti, a partire dalla retrocompatibilità. Come era immaginabile, il problema principale è il mancato supporto di browser come Internet Explorer (6 e 7), mentre gli altri principali concorrenti si comportano egregiamente già adesso.

Parlando invece di nuove funzionalità, sul sempre eccellente Dev Opera è disponibile un articolo che illustra il funzionamento dei canvas, che permettono di creare della grafica direttamente in JavaScript.

In questo contesto, ci sono già stati i primi esperimenti:

  • il sito di An Event Apart, realizzato utilizzando (in parte) HTML 5
  • una pagina di test che comprende elementi come <header>, <nav> e <footer>, resa funzionante anche su IE grazie a JavaScript

Come è possibile vedere su quest’ultimo esempio, l’unico modo per rendere la specifica compatibile anche sul browser Microsoft è l’utilizzo di JavaScript: attenzione quindi perchè potrebbero esserci problemi per alcuni visitatori. Il modo più veloce per implementare questa soluzione è includere nella pagina questo script, tenendo presente i problemi di accessibilità.

Evoluzioni future

Allo stato attuale, è ancora prematuro parlare di HTML 5 su larga scala, soprattutto per i problemi di compatibilità citati. Dai numerosi interventi che sono stati pubblicati in questo inizio 2009 è comunque facile immaginare che sarà un anno importante per lo sviluppo della specifica.

Tenete presente però che lo stato di Proposed Recommendation è ancora lontano: qualcuno ha parlato addirittura del 2022. E’ sempre utile rimanere aggiornati sull’evoluzione degli standard web, ma le priorità attuali per un web designer sono ben altre.

La mia personale speranza è che ci sia la possibilità di continuare a vedere evolversi anche l’XHTML, ma non so quanto sarà possibile. E’ vero che anche adesso coesistono senza troppi problemi le due soluzioni, ma visto che lo stesso W3C ha voluto seguire con più convinzione una strada, non mi stupirei se questa restasse l’unica.

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.

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.

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.

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.

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.

CSS3: quando diventeranno uno standard?

Lo scarso supporto alle specifiche CSS3: ci vorrà ancora del tempo prima che diventino uno standard.

Se siete interessati allo sviluppo con i CSS, avrete sicuramente sentito parlare dei CSS3 e delle novità introdotte dal W3C. Migliore gestione delle colonne di un layout, nuove proprietà riguardanti ombre dei testi, nuovi selettori e la possibilità di utilizzare i Web Fonts sono solo alcuni dei miglioramenti previsti.

Sono in molti ad aspettare l’introduzione di questi aggiornamenti su tutti i browser, ma la cosa non sarà così semplice. La verità è che i CSS3 non diventeranno uno standard ancora per molto tempo.

Perchè i CSS3 non sono uno standard

Il motivo fondamentale è uno, e potreste già conoscerlo: Internet Explorer 6. Finchè sarà utilizzato questo browser, sarà necessario considerarlo a meno che non si voglia rinunciare ad una buona percentuale di utenti. Realizzando siti tecnici o altri progetti particolari è possibile non curarsi della minoranza che ancora lo utilizza, ma se lavorate in una web agency o avete clienti non troppo scaltri, è facile trovarsi ancora davanti IE6.

Le ragioni dell’ancora ingombrante presenza di Explorer 6 sono da cercare nel fallimento di Windows Vista. Il nuovo sistema operativo della Microsoft poteva facilitare la diffusione di IE7, ma non è stato così. Vista non ha spinto gli utenti ad effettuare l’upgrade come è successo in passato da Windows 98 a Windows XP, e le conseguenze adesso si accusano anche sul web.

Come utilizzare i CSS3

In questi casi l’unica soluzione resta il progressive enhancement, utilizzando le proprietà dei CSS3 solo con i browser più recenti (Firefox 3, Safari, Opera). L’importante è fornire comunque un CSS di base ad Internet Explorer, in modo che la visualizzazione non dia problemi. Le proprietà nuove non verranno considerate, senza interferire con il resto.

A seconda del target di utenti del vostro sito, potrete così fornire un’esperienza migliore ad una percentuale di lettori in costante aumento.