CSS design e standard di lavoro

Le linee guida della BBC per i “future media” includono diverse raccomandazioni sulla scrittura dei CSS. Simili pratiche sono solo inutili complicazioni?

Uno dei siti corporate che presta più attenzione ai dettagli è quello della BBC: all’apparenza semplice ed ordinato nonostante i numerosi contenuti, si basa su molte pagine di specifiche tecniche e linee guida che devono essere rispettate dai suoi sviluppatori.

Continua a leggere CSS design e standard di lavoro »

Flickr redesign: la nuova pagina foto

La nuova pagina foto di Flickr è un miglioramento per gli utenti?

Gli utenti abituali di Flickr se ne saranno già accorti: da qualche giorno è stata resa pubblica la nuova versione della pagina foto.

Come consuetudine la novità è stata pubblicata come preview per gli utenti, che possono decidere se mantenere la vecchia versione per qualche tempo o utilizzare la nuova: questa pratica è ormai consolidata e concede ad una buona fetta di utenti di abituarsi al cambiamento, senza imposizioni da un giorno all’altro. Le critiche non mancheranno comunque, ma sarebbe un’utopia pensare di fare felici tutti con un redesign di un’interfaccia.

Per l’elenco delle novità in dettaglio vi rimando al post ufficiale sul blog di Flickr: io preferisco soffermarmi solo su alcuni aspetti del cambiamento, e su come certi dettagli siano stati molto apprezzati dagli utenti abituali. E’ stata una sorpresa infatti leggere molti pareri positivi, cosa che non era successa con altri redesign (vedi il caso di Facebook).

I dettagli più interessanti

Foto più grandi

In un sito che ha nelle immagini la sua ragione di esistere, aumentare la dimensione di default delle stesse è una mossa vincente. Le foto iniziavano infatti ad essere troppo piccole per le risoluzioni sempre più elevate dei nuovi monitor: adesso arrivano ad una larghezza di 640 pixel, sicuramente più accettabile.

Ingrandimento con un clic

Questa è una delle novità più interessanti: molti utenti infatti inserivano nella descrizione delle foto un link alla stessa immagine più grande su sfondo nero. Sono nati anche servizi esterni per questo, e Yahoo! ha deciso di assecondare gli utenti offrendo la feature direttamente su Flickr. Adesso con un clic sull’immagine questa viene visualizzata a schermo intero su sfondo nero, e la resa è ottima:

Geotagging in evidenza

Mettere in evidenza le informazioni geografiche collegate ad una foto qualche anno fa sarebbe stata una follia. Adesso non lo è più. Con smartphone e fotocamere dotate di GPS, geolocalizzare le foto è automatico, e comunque è sempre possibile farlo anche manualmente dopo aver importato gli scatti.

Inserire questa feature al primo posto sulla sidebar destra fa capire la sua importanza. In questo modo diventa ancora più facile ritrovare tutti gli scatti di una certa località e scoprire le foto più popolari di un luogo.

I difetti

Nonostante il redesign sia positivo, alcune cose potrebbero essere ulteriormente migliorate.

Avrei apprezzato molto uno spazio dedicato ai dati EXIF delle immagini: Flickr è una community ricca di fotografi, e certe feature sarebbero sicuramente apprezzate. In questo redesign invece i metadati rimangono su una pagina separata: sarebbe stato interessante vedere almeno apertura, tempo di esposizione ed ISO.

Per quanto invece riguarda il codice e l’accessibilità delle pagine, non mi è mai piaciuta (e continua a non piacermi) l’eccessiva dipendenza da JavaScript di alcune funzioni. E’ comprensibile che certe azioni siano impossibili senza appoggiarsi a degli script, ma si potrebbe fare di meglio anche solo per quanto riguarda i menu di navigazione: con JavaScript disabilitato infatti la maggior parte dei link non funzionano ed i menu non possono essere aperti (cosa che sarebbe facile da implementare con qualche riga di CSS).

Sono invece funzionanti i nuovi link di zoom e di navigazione (foto successiva / precedente): è possibile che per alcuni nuovi elementi dell’interfaccia sia stata prestata più attenzione, ed altre parti del sito come il menu generale siano rimaste invece con i vecchi difetti. Questo redesign infatti riguarda solo la pagina foto di Flickr, tutto il resto è rimasto inalterato.

In conclusione

Il nuovo design è piacevole e più funzionale: il parere complessivo è decisamente positivo. Ci sono alcuni elementi che potrebbero essere ulteriormente migliorati, ma riguardano più la piattaforma intera di Flickr che la pagina delle singole foto. Per il momento fa piacere vedere qualcosa di nuovo in un sito che era rimasto fermo da anni: le modifiche faranno contenti i molti utenti pro che decidono ogni anno di rinnovare il proprio abbonamento.

CSS @import ed i tempi di caricamento

Conseguenze dei metodi di inclusione dei CSS in una pagina web, ed i soliti problemi con Internet Explorer.

I fogli di stile possono essere inclusi in una pagina web usando principalmente due metodi: link e @import. L’obiettivo di questo post è analizzare le conseguenze dell’utilizzo delle due tecniche. Il risultato in sintesi? Non usare @import per migliorare la velocità delle pagine ed evitare problemi con Internet Explorer.

Nonostante infatti possano sembrare differenti solo semanticamente, in realtà usare link o @import cambia considerevolmente i tempi di caricamento di una pagina. La scoperta è stata pubblicata qualche tempo fa sul blog di Steve Souders, un dipendente Google che si occupa di web performance e open source.

Metodi di inclusione

Link multipli

Il metodo più diffuso, che non crea problemi, è il seguente:

<link rel="stylesheet" type="text/css" href="style1.css" />
<link rel="stylesheet" type="text/css" href="style2.css" />

Guardando i tempi di caricamento, è possibile notare come i CSS vengano letti in parallelo su tutti i browser:

La prima breve barra dall’alto corrisponde al documento HTML, le altre due sono i CSS che vengono caricati simultaneamente.

Link e @import

I problemi arrivano quando insieme ad un CSS incluso con link, viene usato @import:

<link rel="stylesheet" type="text/css" href="style1.css" />
<style type="text/css">
@import url("style2.css");
</style>

In questo caso, su Internet Explorer (tutte le versioni, IE8 compreso), il CSS incluso con @import viene caricato solo dopo aver completato il primo file. Questo allunga considerevolmente i tempi di caricamento della pagina:

Lo stesso succede quando il secondo foglio di stile viene importato all’interno del primo:

<link rel="stylesheet" type="text/css" href="style1.css" />

e all’interno di style1.css:

@import url("style2.css");

In questo caso però il caricamento in sequenza succede su tutti i browser.

@import multipli

Gli esempi mostrati dovrebbero già bastare per preferire l’inclusione dei CSS utilizzando solo link, ma c’è un altro caso interessante: quello con @import multipli.

Su tutti i browser diversi da IE, questa tecnica non presenta problemi, e funziona in maniera analoga alla prima mostrata (link multipli). I guai arrivano proprio su Explorer, dove gli elementi vengono caricati in maniera del tutto casuale, senza rispettare l’ordine dichiarato.

Prendendo infatti un esempio con i seguenti file, tra cui un JavaScript:

<style type="text/css">
@import url("style1.css");
@import url("style2.css");
@import url("style3.css");
@import url("style4.css");
@import url("style5.css");
@import url("style6.css");
</style>
<script type="text/javascript" src="script.js"></script>

Il grafico risultante è questo, dove la seconda barra corrisponde al file .js:

Il file script.js viene caricato senza rispettare l’ordine dichiarato, e questo potrebbe portare a problemi di rendering della pagina. Il problema in questione si verifica su tutte le versione di Internet Explorer.

E’ bene che casi come quelli elencati siano noti, perché potrebbe essere veramente difficile indagare sui problemi di una pagina web dove gli elementi vengono caricati senza rispettare le precedenze.

In molti casi le pagine web hanno elementi più pesanti dei CSS (immagini, framework JavaScript), ma se volete ottimizzare il vostro sito tenete presente anche queste indicazioni. Non è un mistero che Google abbia iniziato a considerare anche la velocità di caricamento tra i parametri del suo algoritmo: anche il modo in cui vengono inclusi i fogli di stile è un fattore da valutare.

State of Web Development 2010

Le risposte al sondaggio 2010 di Web Directions, rivolto agli sviluppatori del web.

Sono stati pubblicati i risultati del secondo sondaggio di Web Directions, rivolto a chi lavora e sviluppa sul web. Le risposte di più di 1000 partecipanti delineano in maniera sufficientemente chiara un quadro aggiornato sulla situazione.

Tenendo presente che a rispondere non sono utenti comuni, ma superutenti, questi sono i dati più rilevanti:

  • Mozilla Firefox è ancora il browser più utilizzato per sviluppare, mentre Google Chrome sale al terzo posto subito dopo Safari
  • Internet Explorer 8 è la versione di Explorer più diffusa per la navigazione di tutti i giorni
  • La percentuale di sviluppatori che controllano i propri lavori su IE6 è calata dal 2008 al 2010 (da 78.44% a 59.7%)
  • Più della metà degli intervistati utilizza Mac OS X
  • JQuery è il framework JavaScript in assoluto più utilizzato, e la sua diffusione è in continuo aumento
  • I CSS 3 sono utilizzati anche solo sperimentalmente dal 45% degli intervistati
  • Mobile Safari è in assoluto il browser mobile più usato, e quello su cui vengono fatti più test in ambito mobile

Trovate i risultati del sondaggio, anche in versione pdf, sul sito ufficiale: The State of Web Development 2010.

Personalizzare i font con Typekit

Poche righe di JavaScript sono sufficienti per personalizzare il proprio sito usando font alternativi.

Da diverso tempo sto sperimentando l’uso di Typekit, un servizio che permette di utilizzare font diversi dai soliti noti (Arial, Verdana, Georgia…) in modo compatibile con tutti i principali browser. Il funzionamento è semplice e si basa su font-face e JavaScript, eliminando il problema relativo ai copyright dei font che sono interamente ospitati sui server di Typekit.

I risultati del test

Sono molto soddisfatto dei risultati ottenuti sul mio blog personale, dove sto effettuando le prove. La configurazione è semplice, e l’account trial gratuito permette di fare test senza problemi, mettendo a disposizione più di un centinaio di font (sono oltre 400 negli account a pagamento). La libreria disponibile tra l’altro cresce nel tempo, perché ne vengono progressivamente aggiunti sempre di nuovi.

Quali sono i possibili svantaggi da considerare? Sicuramente il peso della pagina, che a seconda del font scelto cambia notevolmente. Utilizzando il font Droid Serif, nelle sue forme Regular e Italic, ho una pagina che pesa ben 79kb in più del normale. Le cose potrebbero cambiare senza usare il corsivo, ma è necessario comunque fare attenzione a dettagli come questo. Il peso dei font aggiuntivi è comunque sempre visibile nel pannello di amministrazione di Typekit, non è quindi un dettaglio nascosto, da calcolare autonomamente.

Prima di scegliere un font inoltre è bene verificarne l’aspetto sui vari browser: non sempre il rendering è ottimale, soprattutto su Internet Explorer.

Questi però non sono problemi relativi a Typekit, ma fattori da considerare quando si usano font alternativi. L’unico limite del servizio, con l’account trial, è l’inserimento di un piccolo badge in basso a destra sul sito, e la banda mensile di 5Gb per i font.

Scegliere Typekit o usare i CSS?

L’alternativa CSS-only è sempre praticabile: ne avevo parlato nel 2008 quando solo Safari supportava certe proprietà e adesso potrebbe essere la soluzione ideale. Il problema però è l’esistenza di un copyright su quasi tutti i font, spesso anche quelli gratuiti, che non sempre possono essere utilizzati liberamente.

Un altro limite della soluzione autonoma è dato dalle solite differenze tra browser. Firefox supporta Web Open Font Format e TrueType, Safari e Chrome supportano solo TrueType, Explorer supporta EOT, mentre Safari Mobile (iPhone e iPad) usano SVG. Un grande caos, che obbliga lo sviluppatore a includere un font in tutti questi formati per avere risultati coerenti.

Per questo motivo soluzioni come Typekit sono l’ideale: certo, c’è da considerare una minima spesa aggiuntiva se non si vuole usare l’account gratuito con i relativi limiti, ma i vantaggi esistono.

Ci sono anche altre soluzioni alternative, come Typotheque (che concede licenze anche per la stampa) e Kernest, ma non le ho provate personalmente. Ve le segnalo se siete interessati a sperimentare, in attesa di altri servizi come Fontdeck.

A List Apart in italiano

Nasce la versione italiana di A List Apart, la rivista online per i lavoratori del web.

Ho scoperto la notizia per caso, notando l’account Twitter: è appena nata la versione italiana di A List Apart, una delle voci più autorevoli sul web per i professionisti del web design. Il sito italiano ripropone da Febbraio 2010 tutti gli articoli del sito originali, traducendoli.

E’ un’ottima notizia per chi ha problemi di lingua (anche se l’inglese è ormai un must per chi vuole lavorare sul web) e per la diffusione di questo magazine, che da anni si distingue dalla massa pubblicando due lunghi articoli a settimana.

Il progetto è gestito da Valeria e Carlo Brigatti, a cui ho rivolto qualche domanda.

Ecco le risposte di Valeria:

Come è nata l’idea di Italian ALA? E’ stato complicato realizzarla?

Ho conosciuto A List Apart quando ho cominciato ad occuparmi di web design. Ho da subito trovato gli articoli pubblicati molto interessanti ed istruttivi. Circa un anno e mezzo fa, mi è venuta l’idea di creare una versione italiana del sito, che traducesse sistematicamente tutti gli articoli pubblicati da A List Apart, per offrire alle persone che si occupano di web, ma non padroneggiano l’inglese a sufficienza, la possibilità di tenersi aggiornati agevolmente. Così ho contattato Jeffrey Zeldman e ho proposto la mia idea, che è stata subito accolta con favore, ma ci è voluto più di un anno perché il team di A List Apart avesse chiara in mente la direzione che il mio progetto avrebbe dovuto prendere. Così, a gennaio sono stata ricontattata per dare il via all’operazione.

Chi siete? Cercate collaboratori?

l team di Italian A List Apart è costituito da me e da Carlo Brigatti. Carlo si occupa della gestione tecnica del sito e del suo sviluppo. Inoltre, è l’autore delle bellissime illustrazioni che accompagnano ogni articolo. Io collaboro con Carlo per la parte tecnica (più che altro fornisco direttive che vengono da lui trasformate in realtà :) ) ed eseguo le traduzioni.

Per il momento riusciamo a gestire il carico di lavoro piuttosto bene. Non percepiamo nessun compenso per il lavoro che svolgiamo, quindi preferiamo gestircelo noi fintanto che saremo in grado.

Potete comunque aiutare Italian A List Apart facendolo conoscere nel web italiano e partecipando alle discussioni degli articoli sul nostro sito. Inoltre, a breve saranno disponibili degli spazi pubblicitari che potranno essere acquistati da chi fosse interessato (Happy Cog – creatrice di A List Apart – ci autorizza a tenere i compensi derivanti dalla pubblicità sul sito).

Come mai il sito è basato su Joomla! e non su ExpressionEngine come l’originale?

Come ho già accennato, non abbiamo un budget per Italian A List Apart e per abitudine Carlo ed io lavoriamo con CMS open source e free, pertanto ci siamo orientati fin da subito verso questa scelta. Nello specifico, Carlo conosce molto bene Joomla! e pertanto si è deciso di utilizzarlo come sistema di gestione dei contenuti.

Trovate la versione italiana di A List Apart su italianalistapart.com

Quando il redesign di un sito non funziona

Il caso di CSS3.info e della sua nuova grafica.

CSS3.info è uno dei siti da seguire per chi vuole rimanere aggiornato sulle ultime novità dei CSS3. Diversi mesi fa ha cambiato proprietario, e come era lecito aspettarsi è arrivato il momento del redesign del sito. Niente di strano, se non fosse che la nuova grafica dopo due settimane dal lancio ha raccolto un centinaio di commenti, quasi tutti negativi.

Quando viene pubblicata la nuova versione di un sito le critiche non mancano mai: ogni cambiamento spaventa. Basti pensare a quello che successe con il redesign di Facebook. In questo caso però il contenuto dei commenti non lascia dubbi: c’è qualcosa che non va, e molti di questi pareri sono ben motivati.

Scelte grafiche sbagliate

L’obiettivo dichiarato dal proprietario è quello di avere una grafica più professionale, pagine più leggere ed una nuova navigazione. Se per gli ultimi due punti l’obiettivo è stato raggiunto, le scelte di design si sono rivelate decisamente sbagliate.

Essendo un sito frequentato in buona parte da web designer, basta scorrere i commenti per trovare alcune critiche sensate, come:

  • colori male abbinati (testo blu su sfondo nero)
  • design troppo piatto
  • header vuoto
  • ombreggiature usate senza criterio

Il confronto con il passato è impietoso: pur non essendo straordinario, il precedente layout era gradevole e chiaro. Inserire un vecchio screenshot nel post che annunciava la nuova versione è stata decisamente una mossa suicida.

L’errore più grave è stato commesso cercando di utilizzare ovunque proprietà dei CSS3 solo perché sono l’argomento del sito. Avere la possibilità di utilizzare una feature non significa che questa debba essere per forza introdotta, anzi.

Versione beta sì, ma senza esagerare

Un altro problema, che evidenzia una gestione decisamente poco seria, è dato dalla prematura messa online di un layout dove mancano totalmente alcuni elementi fondamentali.

Nel momento in cui scrivo manca un box di ricerca, il footer del sito è vuoto, e diverse pagine hanno ancora un aspetto approssimativo.

Non c’è niente di male nel pubblicare un sito nella sua versione beta, magari facendo delle correzioni anche grazie alle segnalazioni dei visitatori, ma c’è comunque una bella differenza tra un design perfezionabile ed uno approssimativo.

Quali sono i vostri pareri sul nuovo CSS3.info? Nonostante tutto, questo caso può servire come insegnamento per il futuro: sicuramente ricorderò esempi come questo per evitare di commettere gli stessi errori.

Web Design 2010

Cosa cambierà nel mondo del web design durante il 2010? Qualche previsione per il prossimo anno.

Arrivati a fine anno, è giunto il momento di tirare le somme e fare delle previsioni su cosa accadrà nel 2010 nel mondo del web design.

Difficilmente ci saranno delle rivoluzioni, ma certe tendenze già viste alla fine del 2009 inizieranno ad affermarsi. Alcuni siti che nasceranno potranno usare HTML 5 ed i CSS3 senza problemi: sperimentare è ormai un dovere per non farsi cogliere impreparati..

Cosa aspettarsi quindi nel 2010? Ecco alcune previsioni.

HTML 5

Lo standard per il futuro dell’HTML è già stato ufficializzato dal W3C durante il 2009. Sono già stati fatti alcuni esperimenti interessanti, ma è logico aspettarsi che durante il prossimo anno l’HTML 5 sarà ancora più utilizzato.

Non ho mai nascosto la mia preferenza per l’XHTML, e per ora questo sito continuerà ad utilizzare tale specifica, ma se in questo momento decidessi di partire con un nuovo progetto sarei seriamente tentato di provare le potenzialità dell’HTML 5.

CSS 3

I CSS sono sempre stati in evoluzione continua: anche i browser ad ogni aggiornamento supportano funzioni sempre nuove. Ormai non serve più attendere l’ufficialità del W3C: molti produttori permettono di sperimentare i nuovi moduli dei CSS prima che questi diventino uno standard (ad esempio usando i prefissi moz- o webkit-).

Durante il 2009 ho già parlato di Web Fonts e Flexible Boxes, e nel 2010 ci saranno sicuramente altre novità in questo senso.

Internet Explorer 6

Per qualcuno IE6 è già defunto, ma la realtà lo dà ancora vivo e vegeto, assestato intorno al 10% del market share. Sono cifre ancora ragguardevoli, ma ormai le cose stanno cambiando. La tendenza è già chiara, ed il 2010 sarà l’anno giusto per vederlo sparire.

Il problema in Italia rimangono le pubbliche amministrazioni e gli uffici dove si continuano ad utilizzare vecchi computer, ma per quello purtroppo non c’è soluzione a breve termine.

La guerra dei browser

Mettendo da parte il discorso relativo a IE6, la guerra dei browser nel 2010 si farà ancora più interessante. Google Chrome ha superato in brevissimo tempo i numeri di Safari, e l’introduzione del ballot screen in Europa potrebbe riservare alcune sorprese.

Non resta che tenere sotto controllo le statistiche e seguirne l’evoluzione: Internet Explorer potrebbe anche perdere quote rilevanti.

Chrome OS

Infine nel 2010 nascerà il sistema operativo made in Google, e questa è già una notizia. Concepito per essere utilizzato solo con una connessione attiva, non sarà il massimo per il panorama italiano, ma ancora una volta a Mountain View hanno indicato la strada da seguire. Il futuro dei nostri dati è online, e Chrome OS sarà un primo importante passo in quella direzione.

Con questo post ho voluto tracciare un quadro generico per il prossimo anno: ci saranno sicuramente altre novità oltre a quelle citate, ma il 2010 sarà comunque un anno importante. Se avete altre previsioni da fare lasciate un commento: aspetto anche i vostri pareri.

Ombre cross-browser con i CSS, senza immagini

Come sfruttare la proprietà box-shadow dei CSS3 ed ottenere risultati simili anche su Internet Explorer.

La proprietà box-shadow (CSS3) permette di applicare ombre ad elementi contenitori di tipo block. Funziona in maniera simile alla proprietà text-shadow, ma il W3C al momento ne ha sospeso l’approfondimento per studiarne l’implementazione in maniera più approfondita.

Come funziona box-shadow?

La proprietà può essere utilizzata su Firefox 3.5 e sui browser basati su webkit (Safari e Chrome) con i soliti prefissi:

  • -moz-box-shadow per Firefox
  • -webkit-box-shadow per Safari e Chrome

L’espressione è semplicemente:

box-shadow: 5px 5px 10px #000;

dove i parametri sono nell’ordine:

  • la distanza dell’ombra in orizzontale ed in verticale
  • il raggio
  • il colore

Ho notato che tra i browser webkit la resa è migliore su Safari: Chrome pur visualizzando l’ombra ha qualche problema con gli angoli ed il loro arrotondamento.

La soluzione per Internet Explorer

La cosa interessante, scoperta per caso sul blog di Nick Dunn, è che con alcuni hack è già possibile sfruttare questa proprietà per ottenere un risultato valido anche su Internet Explorer.

Esistono infatti alcuni filtri proprietari della Microsoft che in queste circostanze sono l’unica soluzione possibile. Era già successo per i .png trasparenti su IE6, e la situazione è analoga anche in questo caso. Combinando i filtri Glow e Shadow, o ancora meglio utilizzando solamente Shadow è possibile ottenere un’ombra molto simile su tutte le versioni di Explorer, a partire dalla 5.5.

Il codice necessario è il seguente, da inserire in un commento condizionale:

filter:
    progid:DXImageTransform.Microsoft.Shadow(color=#eeeeee,direction=0,strength=7)
    progid:DXImageTransform.Microsoft.Shadow(color=#dddddd,direction=90,strength=10)
    progid:DXImageTransform.Microsoft.Shadow(color=#dddddd,direction=180,strength=10)
    progid:DXImageTransform.Microsoft.Shadow(color=#eeeeee,direction=270,strength=7);

Color e strenght dell’ombra possono ovviamente essere modificati secondo le necessità.

Demo

box-shadow

Ho realizzato una pagina dimostrativa di questo effetto.

Il risultato cambierà leggermente a seconda del browser utilizzato, ma resterà comunque coerente. La soluzione non è esente da difetti, ma è un buon compromesso per aggiungere dettagli in più ad un design senza appesantirlo con delle immagini. C’è anche da considerare che spesso è complicato dare un’ombra ad un contenitore, soprattutto se questo ha delle dimensioni variabili: l’unica soluzione è utilizzare del codice html superfluo o adottare questo metodo.

I difetti principali che ho riscontrato sono:

  • CSS non valido
  • niente ombra su Firefox < 3.5 e su Opera
  • uso di hack per Internet Explorer

A voi la scelta se adottare questa soluzione: è una possibilità da tenere in considerazione, ma la sua efficacia è da valutare a seconda del progetto. Niente vieta comunque di adottare anche solo la soluzione per Firefox come progressive enhancement, offrendo un’esperienza migliore di navigazione ad alcuni utenti.

Il Web per non vedenti: qual è il giudizio degli utilizzatori di Screen Reader?

Un sondaggio rivolto ad utenti di Screen Reader mostra qualche sorpresa ed i progressi del web mobile.

WebAIM ha pubblicato i risultati di un recente sondaggio (Ottobre 2009), tra 665 utilizzatori di screen reader. E’ la seconda edizione di questo sondaggio: ne avevo infatti già parlato l’anno scorso, in un articolo sull’utilizzo dei lettori di schermo per effettuare test di accessibilità.

I risultati sono importanti: non condizioneranno in maniera rivoluzionaria le abitudini dei web designer attenti a queste tematiche, ma danno un quadro completo di questa specifica categoria di utenti. Tra le note più interessanti:

  • Il 66,4% utilizza JAWS come screen reader principale
  • Il 49% usa abitualmente più di uno screen reader, a seconda del contesto
  • Il 53% degli utenti disabili usa uno screen reader su un dispositivo mobile
  • I problemi principali sulle pagine web sono dati da CAPTCHA, contenuti Flash inaccessibili e link ambigui
  • Il 46% pensa che il web stia diventando più accessibile che in passato
  • Social Media: il 51% usa YouTube, il 47% un blog, il 42% Facebook ed il 38% Twitter
  • Twitter è giudicata la piattaforma più accessibile
  • Per trovare informazioni su una pagina, il 50% scorre i titoli (h1, h2…) ed il 22% usa la ricerca interna

Uno dei dati più sorprendenti riguarda l’utilizzo di dispositivi mobili. Sicuramente è un settore in cui sono stati fatti molti progressi nell’ultimo anno, e credo che abbia avuto una buona importanza anche l’uscità dell’iPhone 3Gs con VoiceOver. Potrebbe sembrare strano, ma i dispositivi touchscreen accessibili sono ormai realtà, e se siete interessati vi consiglio di leggere recensioni come quella di Marco Zehe, che racconta la sua esperienza personale con questo smartphone.

Rispetto all’anno scorso, le raccomandazioni rimangono più o meno le stesse: le intestazioni continuano ad avere una grande importanza per l’accessibilità di una pagina web, ed uno dei problemi principali sono ancora i CAPTCHA e Flash. In certi progetti è impossibile farne a meno, ma sapere che potrebbero creare problemi è già un primo passo.