In questo articolo troverete una selezione di alcuni effetti che consentono di creare gallerie di immagini accessibili: non intrusivi, degradano nel modo giusto se JavaScript è disabilitato, e si appoggiano a framework già collaudati come jQuery e Mootools. Potrebbero essere migliorati ulteriormente, ma sono un’ottima base di partenza.

SmoothGallery

Soluzione basata sulla libreria Mootools, consente di creare slideshow di immagini mettendo a disposizione vari parametri come lo scorrimento automatico ed il tempo riservato ad ogni fotografia. E’ possibile anche avere più set di immagini nella stessa galleria: funzione comoda per risparmiare spazio nella pagina.

In assenza di JavaScript, le immagini appaiono comunque precedute da titolo e descrizione. Il difetto riguarda i controlli, non è infatti possibile scorrere le foto da tastiera.

Slideshow 2

Un buon set di effetti a disposizione anche per questo script basato sul framework Mootools, che può essere a sua volta esteso con altre funzionalità, come l’anteprima delle immagini con Lightbox.

Notevole la realizzazione degli esempi: disabilitando JavaScript le funzionalità restano le stesse, spariranno semplicemente le transizioni. Ottimi anche i controlli, non c’è alcun problema a spostarsi tra le immagini utilizzando anche la tastiera.

Galleria

Probabilmente il migliore tra quelli presentati, questo script si basa su jQuery e pesa solamente 4kb. Non è intrusivo, degrada senza problemi in assenza di JavaScript o con i CSS disabilitati e può essere personalizzato facilmente anche nell’aspetto. Le immagini sono organizzate in una lista nel codice HTML: una soluzione ottimale.

Notevole anche l’efficienza dello slideshow, perchè le foto vengono caricate e mostrate solo quando disponibili, evitando attese nel momento dell’interazione.

Se conoscete altre soluzioni accessibili per la creazione di gallerie di immagini segnalatele nei commenti, è sempre utile conoscere le migliori risorse in questo ambito. Potete trovare altri script nel mio precedente post dedicato a Lightbox ed ai suoi cloni: se comunque volete uno slideshow accessibile il mio consiglio è di partire dagli script appena illustrati.

Fondamentalmente una pagina autocelebrativa non serve a niente, soprattutto perchè inserirla non rende un sito automaticamente accessibile. Fornire informazioni utili ai propri visitatori resta comunque una buona idea, soprattutto se questo porta ad una migliore esperienza di navigazione.

Alcuni suggerimenti utili

Scrivendo una dichiarazione di accessibilità si possono commettere diversi errori. I consigli più semplici da imparare e da tenere sempre presenti sono:

• Non addentrarsi troppo in dettagli tecnici che la maggior parte degli utenti non potrà capire: parlare di CSS, attributi alt sulle immagini, testi in em e progressive enhancement non serve a niente.
• Mettere bene in evidenza un recapito per segnalare problemi ed errori.
• Realizzare una pagina bene organizzata: è fondamentale suddividere le sezioni della dichiarazione con dei titoli, ad esempio parlando di navigazione, testi, collegamenti, ecc.
• Non nascondere il collegamento: va bene inserire un link nel footer, ma non rendetelo invisibile, altrimenti tutti i presupposti di un sito accessibile spariranno fin dalla vostra dichiarazione di conformità agli standard.

Tenete comunque presente che non è obbligatorio inserire una pagina dedicata alla dichiarazione di accessibilità, anzi. Se il vostro sito è ben realizzato, nella maggior parte dei casi non avrete alcun bisogno di mettere in evidenza il vostro buon lavoro. Un sito è veramente accessibile quando gli utenti sono in grado di navigarlo senza nessun suggerimento da parte vostra.

A tale proposito proprio su questo sito non ho deciso di inserire una vera e propria dichiarazione di accessibilità, ma un semplice testo esplicativo nel footer. Nel caso ci siano problemi o gravi errori, il mio invito è sempre quello di contattarmi per segnalarli.

Se doveste comunque avere la necessità di creare una pagina apposita, potreste prendere spunto da alcuni siti del settore, come 456 Berea Street o Accessites.

Come fa notare Digital Web Magazine, con l’imminente uscita di Internet Explorer 8 questa proprietà supporterà correttamente i valori table, table-row e table-cell per la prima volta su un browser Microsoft. Le ultime versioni di Safari, Opera e Firefox seguono già gli standard e non dovrebbero avere alcun problema.

Come funziona la tecnica?

Basta realizzare una semplice struttura nel codice HTML con dei div:

<div id="main">
<div id="nav">
...contenuto della colonna
</div>
<div id="content">
...contenuto della pagina
</div>
</div>

Quindi è sufficiente applicare gli stili relativi, facendo in modo che il contenitore principale abbia un display: table, e le singole colonne un display: table-cell:

#main {
display: table;
border-collapse: collapse;
}
#nav {
display: table-cell;
width: 180px;
}
#content {
display: table-cell;
width: 580px;
}

Da notare che una tecnica simile dal punto di vista della semantica del codice non presenta alcuna controindicazione. L’aspetto tabellare infatti viene gestito interamente tramite i fogli di stile, il markup è ben organizzato e non ha particolari differenze rispetto a quello di un layout con i float.

Incompatibilità e difetti

Per ogni nuova tecnica è fondamentale considerare quanto essa sia realmente applicabile. Nel caso dei layout a tabelle con i CSS, uno dei punti deboli è sicuramente il mancato supporto di IE6 e IE7. Non poter usare questa soluzione sui due browser che da soli rappresentano più del 70% del mercato, la rende di fatto inutilizzabile: al momento è poco più che esercizio di stile.

Un altro aspetto poco considerato è l’ordine dei contenuti all’interno del codice HTML. Con questa tecnica si ripresenta uno dei difetti principali delle tabelle: l’impossibilità di organizzarli secondo la loro importanza. Usando un layout tabellare tutti i vantaggi del posizionamento con i float spariscono, dovendo per forza di cose ordinare gli elementi secondo il loro ordine di apparizione nella pagina.

Se volete continuare ad approfondire il discorso, vi rimando ad un post di Edit di qualche settimana fa. Dal mio punto di vista, potrebbe essere interessante sperimentare la tecnica per il futuro, ma con qualche riserva. Sarà infatti possibile usarla quando IE6 e IE7 spariranno dalla circolazione, ma i CSS3 saranno ormai alle porte con nuove soluzioni per gestire il layout di un sito.

In questo ambito però viene spesso trascurata la componente innovativa: quanto è conveniente seguire le tendenze del momento a scapito della sperimentazione? Realizzare un sito che somigli a qualcosa di già visto potrebbe essere controproducente, e sicuramente non darà ai visitatori dei motivi per rimanere impressionati positivamente.

Un esempio chiave è il recente redesign di Duoh.com, presentato qualche settimana fa sul blog di Veerle Pieters: se non avete visitato la sua creazione vi consiglio di impiegare qualche minuto del vostro tempo per navigare tra le pagine ed esplorarle a fondo.

In questo caso l’obiettivo era realizzare qualcosa di innovativo, ed è stato centrato in pieno. Raggiungere un simile traguardo non è impresa da poco, anche perchè sperimentare significa uscire dagli schemi ed andare contro le mode del momento: a volte è indispensabile.

Veerle scrive a questo proposito:

we needed to explore some new territory and be a little experimental along the way

Esplorare nuove strade è necessario: se nessuno avesse il coraggio di andare oltre le consuetudini, avremmo siti tutti uguali. E’ quello che è accaduto nel periodo di maggior successo dello stile Web 2.0, che fortunatamente ora sta diventando obsoleto.

Sicuramente con il passare degli anni il Web Design ha le possibilità di evolversi e conservare alcune buone abitudini, l’importante è non fossilizzarsi su di esse. Non vanno dimenticati i passi avanti fatti nell’utilizzo della tipografia e in alcune scelte di layout (mi vengono subito in mente i footer alti), ma un Web Designer deve anche saper osare.

Nei vostri lavori quanto concedete alla sperimentazione? Trovare il giusto compromesso è probabilmente l’aspetto più difficile, ma se avete intenzione di farvi notare ricordate che non sempre è sufficiente imitare.

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.

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.

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.

Joomla, Drupal, ma anche Wordpress, sono sistemi per la gestione dei contenuti che in molti casi offrono più del necessario, quando magari sarebbe sufficiente poter modificare il testo contenuto in una semplice pagina.

E’ in questo contesto che si inserisce Module, un CMS essenziale realizzato da Giovanni Meloni. Una volta configurato ed installato sul server, consente di cambiare il testo contenuto in una pagina senza appoggiarsi ad alcun database. Dopo l’autenticazione dell’utente, apparirà un pop-up con il testo modificabile tramite un editor come NicEdit o TinyMCE.

Potete provare subito Module in questa pagina demo.

Ha ancora bisogno di essere perfezionato, ma credo che l’esigenza di uno strumento del genere sia diffusa. Al momento ci sono soluzioni alternative come CushyCMS, ma in quel caso i contenuti vengono ospitati su un server esterno. Con questa soluzione invece si ha il controllo totale della piattaforma, la soluzione ideale per siti di una sola pagina o comunque non troppo complessi.

Collabora al progetto

Module necessita ancora di miglioramenti: il suo autore è attualmente in cerca di altri programmatori e sviluppatori php interessati a collaborare con lui. Se siete interessati contattatelo direttamente da questa pagina, ricordando che questo progetto è gratuito, rilasciato con licenza Creative Commons.

Dal mio punto di vista, l’interfaccia ed il funzionamento avrebbero bisogno di alcune modifiche. Eviterei l’utilizzo di pop-up che rendono l’applicazione inaccessibile, e cercherei di facilitare ulteriormente l’installazione. Invece di aggiungere troppe stringhe di codice, l’ideale sarebbe poter applicare una classe all’elemento che si vuole modificare: tutto dovrebbe essere poi gestito lato server.

Se avete altri suggerimenti dite la vostra nei commenti, saranno letti dall’autore. Sono ben accette anche altre segnalazioni di applicazioni simili: potrebbero comunque servire alla crescita di questo CMS basilare.

Il plugin si chiama semplicemente Lifestream: dopo averlo attivato ed aver configurato dall’amministrazione i Feed RSS da importare, è sufficiente inserire in una pagina il tag [lifestream] per vedere apparire tutta la propria attività.

Il risultato può essere facilmente personalizzato tramite fogli di stile, in modo da adattare la pagina al proprio blog. Tra l’altro il plugin offre la possibilità di programmare dei post con il resoconto giornaliero: gli articoli verranno pubblicati in automatico ed assegnati ad una specifica categoria.

I requisiti del plugin Lifestream sono basilari: Wordpress aggiornato almeno alla versione 2.5 e php 5.

Pro e Contro

Una soluzione di questo tipo potrebbe essere interessante come alternativa a Sweetcron, che ricordo essere ancora in beta. Sicuramente Wordpress è una piattaforma molto più stabile e collaudata, tenendo anche presente che al momento non è possibile sapere quando Sweeetcron raggiungerà una versione stabile.

Se inoltre avete già un blog Wordpress e non volete avere altre complicazioni, installare un semplice plugin è un’operazione molto più immediata rispetto alla configurazione di un nuovo strumento.

D’altro canto però non è detto che integrare il vostro lifestream in un blog già esistente sia la soluzione ottimale. Personalmente immagino bene questo tipo di contenuti in un contesto indipendente, non incluso in un’altra piattaforma, magari con un proprio dominio o anche solo un sottodominio diverso.

Sta a voi valutare la soluzione migliore per le vostre esigenze: è comunque innegabile che avere in una pagina il resoconto di tutte le proprie attività web 2.0 sia una tendenza che andrà ad affermarsi sempre di più.

Last.fm per la musica, Flickr per la fotografia e YouTube per i video, passando per Twitter e le altre web application esistenti: tutto questo genera un notevole flusso di informazioni: ecco cos’è il lifestreaming di una persona.

E’ in questo scenario che nasce Sweetcron: una piattaforma da installare sul proprio spazio hosting, che una volta configurata riassume in una pagina tutti i nostri interessi. Diversamente da Facebook o FriendFeed (che comunque potete utilizzare per il lato “social”), qui i vari servizi esterni sono raccolti in maniera completamente personalizzabile e gestiti autonomamente.

La parte più interessante, che sto approfondendo in questo periodo, è la possibilità di creare dei template grafici come succede su Wordpress. Dall’amministrazione di Sweetcron è possibile aggiungere i propri feed e tra le opzioni selezionare quale tema attivare: con poco php e discrete conoscenze di HTML e CSS si possono già ottenere buoni risultati, magari utilizzando come base i temi esistenti di default.

A proposito dei temi per Sweetcron ho in programma di approfondire l’argomento con una guida, se volete saperne di più e non perdervi tutti i dettagli, potete abbonarvi al Feed RSS di questo blog.

Sweetcron è stato creato da Jon Yongfook, un web producer giapponese: è possibile vedere una dimostrazione delle funzionalità proprio sul sito personale del suo creatore. Ci sono buone possibilità che piattaforme simili a questa prendano il posto dei blog in un futuro non troppo lontano: sarà interessante seguirne l’evoluzione.