Accessibilità - Pagina 6 di 7

Tempo di bilanci per Stardust, il tema WordPress

Sono passati più di 6 mesi da quando ho annunciato il rilascio del mio primo tema accessibile per WordPress, ed arrivati vicini alla fine di questo 2007 è il momento di fare un bilancio.

Potrà sembrare quasi impossibile, ma guardando le statistiche dei siti dove è possibile scaricare Stardust, è stata ormai superata la quota 9000 download complessivi. Più di 500 sono del tema italiano, realizzato grazie all’aiuto di Carlo Perassi.

Ammetto di essere il primo ad essere stupito di questi risultati: il tema ha una struttura semplice e la grafica non è troppo ricercata, ma a quanto pare è bastato per raggiungere traguardi incredibili.

I blog che utilizzano il tema sono spesso appena nati, ma tra questi ci sono anche casi illustri come il blog ufficiale di Pix-Yu, la nuova applicazione made in Italy per la condivisione di fotografie ed eventi.

Che dire a questo punto? Grazie a tutti coloro che mi hanno sostenuto!

Colgo l’occasione per annunciare che ho in programma di rilasciare almeno un altro tema in un futuro non troppo lontano. Per il momento non ho abbastanza tempo libero per mettere in pratica le idee che ho in testa, ma tornerò presto sull’argomento.

Per gli interessati, Stardust è disponibile per il download su questa pagina.

I 100 migliori siti su web standards e accessibilità

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

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

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

Buona lettura!

I controlli per ridimensionare il testo sono utili?

Proprio in questi giorni un argomento ha attirato la mia attenzione, trattato nello stesso momento su due siti da sempre interessati all’accessibilità del web. Non so se sia una semplice coincidenza, ma sia Accessites.org che 456BereaStreet hanno scritto due articoli dai toni simili sulle “widget” per ridimensionare il testo delle pagine web.

Il parere unanime che viene fuori dalla loro analisi è il seguente: uno strumento del genere è superfluo, perchè i browser hanno già la funzionalità integrata. Piuttosto che inserire nelle pagine degli style switcher javascript o lato server, è meglio istruire il visitatore sulle possibilità che ha già ed insegnargli ad usare meglio ciò che possiede.

I lettori più fedeli sapranno che su questo sito ho da sempre utilizzato il pannello di controllo proprio a questo scopo, e leggere dei pareri autorevoli sull’argomento mi ha portato a riflettere. E’ giusto mantenerlo?

Dal mio punto di vista, pretendere di poter insegnare ad un utente come usare il proprio browser è un’impresa quasi disperata. Saranno ben pochi i visitatori disposti ad imparare qualcosa, la maggior parte vuole semplicemente raggiungere la notizia che gli interessa nel minor tempo possibile.

Proprio per questo motivo eliminare definitivamente lo style switcher per ridimensionare il testo sarebbe inutile, anzi si andrebbe a togliere una funzionalità aggiuntiva, non fastidiosa per l’utente.

Voi cosa ne pensate? Credete sia un’aggiunta utile o lo considerate un elemento superfluo?

Bisogna inoltre capire un altro dettaglio non meno importante: la presenza di uno script simile ha anche una funzione educativa (qualcuno potrebbe definirla “pubblicitaria”). Indica che il sito può essere letto senza problemi ingrandendo il testo, ed è un modo per mostrare il lavoro di ottimizzazione eseguito. Non ce ne dovrebbe essere bisogno, ma è lo stesso principio che porta ad inserire i famosi bollini del W3C.

Ritengo comunque non sia sbagliato il principio di voler guidare i propri visitatori alla scoperta del browser che utilizzano, a tale scopo potrebbe farvi molto comodo il seguente video, magari da includere in una pagina dedicata all’accessibilità del proprio sito:

Risoluzione minima: addio 800×600?

In fase di realizzazione di un sito web, uno dei primi aspetti da considerare per quanto riguarda l’interfaccia è la risoluzione minima da supportare.

E’ ovviamente possibile creare un sito a larghezza fluida come TomStardust.com, ma si dovrà comunque decidere fino a che punto poter ridimensionare il layout. Se fino a qualche tempo fa era ancora logico supportare la risoluzione 800×600, dopo una valutazione del panorama italiano ed internazionale sento di poter dire che ormai il limite è stato superato. Le percentuali di visitatori con una tale risoluzione sono sempre meno, mentre aumentano gli schermi widescreen.

Se poi consideriamo alcuni tra i siti più popolari vediamo come il recente redesign di Punto Informatico sia per una larghezza minima di 1024 pixel, e anche in ambito non tecnologico ci si sia spinti su standard analoghi: il sito di Repubblica è da tempo creato su misura per i monitor a 1024×768, e anche una piattaforma di blogging come Splinder ha ridisegnato la propria homepage per la stessa risoluzione.

Il mio consiglio resta quello di realizzare layout fluidi che possano adattarsi allo schermo del visitatore, ma non sentitevi troppo in colpa se il vostro sito mostra delle barre di scorrimento ad 800×600. Certo, ci saranno ancora utenti con vecchi pc (su questo sito sono circa il 2% dei visitatori totali), ma a mio parere è ormai sufficiente garantire la leggibilità dei contenuti e la possibilità di navigare tra le pagine. Cosa ne pensate? Se conoscete siti che vanno contro questa tendenza citateli senza problemi.

L’accessibilità tra W3C e WCAG Samurai

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

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

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

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

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

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

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

Stardust WordPress Theme anche per Mac

Pochi giorni fa ho reso pubblico il mio tema per WordPress, oggi segnalo un aggiornamento già disponibile sul sito ufficiale.

Le novità di questa versione riguardano soprattutto gli utenti Mac: adesso il tema Stardust è stato testato anche con Safari, Camino e Firefox su Mac OS X, con la correzione di alcuni problemi di visualizzazione presenti nella prima versione.

Gli altri fix:

Aggiunta dell’anno nelle date dei post
Corretta la dimensione delle sottocategorie nella sidebar

Scarica il tema dal sito ufficiale di WordPress!

Stardust v1.0, il mio tema accessibile per WordPress

Ho rilasciato il mio prima tema free per WordPress: Stardust v1.0.

Stardust v1.0 – WordPress Theme

E’ un tema a 2 colonne a larghezza fluida, realizzato in XHTML 1.0 Strict valido. Ho voluto puntare l’attenzione soprattutto sull’accessibilità, sono quindi presenti i vari skip link ad inizio e fine pagina, il codice è semanticamente corretto e le pagine sono pienamente navigabili anche senza CSS o con le immagini disabilitate. E’ stato testato su Firefox, Internet Explorer 6 e 7 ed Opera.

Lo potete già trovare nella directory ufficiale disponibile per il download o per testarlo direttamente online.

Tra le risorse usate segnalo le immancabili Silk Icons di famfamfam.com, che al momento sembrano non essere disponibili sul sito ufficiale, ma potete trovarle anche a questo collegamento.

Ho utilizzato anche un paio di icone di Liquidicity, dal set bianco su sfondo nero, all’interno dell’header.

Aspetto i vostri pareri, provate il tema e fatemi pure tutte le osservazioni che volete, sono sempre disponibile a migliorarlo e correggere eventuali problemi ed incompatibilità.

Quando AJAX non serve

Il mese scorso un sito a cui sono registrato ha subito un deciso restyling: si tratta di Design Snack.

E’ una community dove ognuno può segnalare un sito e farlo votare dagli altri utenti; più voti ottiene, più in alto sale in classifica, passando da semplice segnalazione a risorsa approvata ed infine “awarded”.

Appena ho visto l’homepage ho notato subito l’aggiunta di AJAX nella colonna destra, che permette di navigare tra le categorie. La funzione è comoda, peccato che con Javascript disabilitato ci si trovi davanti ad una pagina parzialmente vuota (vedi screenshot).

Qualcuno potrebbe pensare che sia impossibile trovare una soluzione accessibile ottenendo gli stessi risultati, ed invece non è così.

Un altro famoso sito risolve tutto con un semplice Javascript: Hicksdesign. Cliccando sui vari “recent works” è possibile cambiare al volo il contenuto visualizzato nella pagina, ma il bello è che tutto rimane accessibile. Se infatti provate a disabilitare Javascript, magari aiutandovi con la Web Developer Toolbar (per Firefox), vedrete comunque tutti i contenuti, raggiungibili tramite delle ancore.

Il web è ricco di esempi del genere. Non è detto che si debba per forza di cose utilizzare sempre l’ultima tecnologia disponibile: AJAX sicuramente ha grandi potenzialità, ma è sempre necessario prestare attenzione a tutte le conseguenze di una sua applicazione.

Se si possiede un’alternativa valida, accessibile e con meno problemi, è quella che va utilizzata!

La legge sull’accessibilità in Olanda

Per chi non lo sapesse, dal 1° Settembre 2006 in Olanda è stata approvata una legge sull’accessibilità dei siti internet che ricorda molto da vicino la nostra ormai famosa legge Stanca.

E’ possibile leggere nel dettaglio il testo originale della legge, ma per chi come me non conoscesse la lingua, su Quirksmode ne viene fatta una discreta analisi (in inglese).

Adesso tutti i siti governativi olandesi dovranno seguire 125 linee guida, che prendono spunto dalle direttive del W3C ma vanno anche oltre.

Tra i punti degni di nota, troviamo che ogni sito dovrà avere:

codice HTML 4.01 o XHTML 1.0
separazione tra codice e presentazione, con HTML semantico e CSS
un attributo alt significativo per ogni immagine presente
una via alternativa per raggiungere tutti i contenuti, ad esempio quando Javascript è disabilitato

L’elenco come potete immaginare continua, e queste sono tutte raccomandazioni ben conosciute da chi sviluppa per il web seguendo le direttive del W3C. In certi casi però, come appunto nei siti delle amministrazioni, è bene che ci sia una legge a tutelare gli utenti.

Il vero passo avanti comunque ci sarà solamente quando anche le grandi aziende, come minimo, saranno obbligate a seguire le stesse regole nei loro siti. Per il momento la strada è ancora lunga, e i problemi continuano ad esistere.

Da notare che non mi sto riferendo all’accessibilità come il semplice controllo sul codice di un sito, il discorso va ben oltre. Ad un utente non vedente interesserà ben poco sapere che l’HTML è a posto se poi non riuscirà a navigare una pagina con un lettore di schermo.

Sono stati fatti dei progressi negli ultimi anni, anche in Italia, ma adesso è necessario insistere senza mai pensare di essere arrivati alla meta.

Colore di sfondo del body: mai dimenticarlo

Non tutti lo sanno, ma ogni browser consente di impostare un colore predefinito per lo sfondo ed il testo delle pagine web. Queste impostazioni vengono utilizzate quando il sito visitato non ha un colore già stabilito: di solito sono rispettivamente bianco e nero, ma un utente potrebbe preferire altre combinazioni.

Questo comporta possibili problemi quando in un sito il body non ha un colore di sfondo. Poniamo ad esempio che un utente abbia il rosso come background predefinito; questo è quello che vedrà andando sul sito bloggers.com:

Un altro esempio si trova stavolta su Modern Life is Rubbish che recentemente è stato anche ridisegnato.

Il problema si aggira facilmente ricordandosi sempre di dare al body un colore di sfondo:

body { background: #fff }

I due siti che ho fornito come esempio sono stati i primi che ho scoperto, ma se fate una ricerca non sarà troppo difficile trovare qualche altro caso clamoroso. Ricordatevi di questo particolare quando realizzate un sito, vi eviterà le lamentele dei clienti (e dei visitatori) che hanno dei colori preimpostati sul loro browser.