JavaScript e il tag noscript

Esempi di utilizzo corretto del tag noscript, e le possibili alternative per una pagina accessibile.

Il tag HTML noscript è spesso considerato uno dei migliori metodi per fornire contenuti alternativi al JavaScript di una pagina web. In realtà nella maggior parte dei casi questo tag viene ancora oggi utilizzato per messaggi imbarazzanti come:

il tuo browser non ha i requisiti necessari per visualizzare questo contenuto

Questo testo però è decisamente poco interessante per l’utente, ed ancora meno utile dal punto di vista dell’accessibilità.

Utilizzare noscript

Il modo migliore per sfruttare questo tag è inserire al suo interno un contenuto realmente alternativo.

Nel caso di una mappa interattiva con dei punti di interesse, all’interno del noscript sarebbe sufficiente elencare questi punti senza troppe complicazioni:

<script type="text/javascript">
// mappa interattiva
[...]
</script>
<noscript>
<ul>
   <li><a href="...">Punto di interesse 1</a></li>
   <li><a href="...">Punto di interesse 2</a></li>
   [...]
</ul>
</noscript>

evitando messaggi come:

<noscript>Il tuo browser non supporta JavaScript!</noscript>

Progressive enhancement

C’è però un’alternativa migliore al tag noscript, ed è l’utilizzo del progressive enhancement. Fornire un contenuto alternativo può essere una soluzione valida intervenendo su un sito esistente, ma se state realizzando un progetto da zero, è molto più utile pensare fin da subito a certe problematiche.

E’ necessario pensare ad HTML e JavaScript come due livelli distinti, da tenere ben separati. Il procedimento migliore è infatti inserire tutti i contenuti HTML, e solo successivamente usare JavaScript per aggiungere effetti grafici e animazioni.

In questo modo anche con JavaScript non disponibile i contenuti resteranno accessibili, e soprattutto non dovrete preoccuparvi di realizzare delle versioni alternative.

Sulla separazione di HTML e Javascript c’è un interessante articolo di A List Apart del 2006: Behavioral Separation, scritto da Jeremy Keith.

Ha ancora senso usare noscript?

Se utilizzate JavaScript in maniera non intrusiva potete benissimo dimenticarvi di noscript. Il tag però rimane ancora valido (ed è riconosciuto anche in HTML5) per garantire la retrocompatibilità.

Ci sono poi situazioni in cui l’utilizzo del noscript è insostituibile: basti pensare a tutti i casi in cui il codice JavaScript viene fornito da un sito esterno e non è modificabile.

E voi cosa ne pensate? Nel panorama italiano parlare di progressive enhancement è ancora un’utopia?

La paginazione è destinata a scomparire?

Aumentano gli esempi di scrolling infinito sulle pagine web: ma la paginazione è ancora una soluzione valida?

La paginazione è da sempre un elemento fondamentale su tutti i siti web e sui blog. Quei numeri che consentono di spostarsi nell’archivio delle notizie più datate sono stati spesso al centro di dibattiti sulla loro effettiva usabilità: sono veramente la soluzione più comoda?

Da qualche tempo questo tipo di paginazione è stata sostituita da una sorta di scrolling infinito su diversi siti importanti: Facebook e la nuova ricerca immagini di Google sono i casi più rilevanti. Ma la soluzione in realtà non è nuova. Già nel 2006 ne avevo parlato su questo sito, citando gli esperimenti degli Humanized Labs.

E’ difficile stabilire se questa sia la soluzione definitiva, ma sicuramente è una possibilità che va presa in considerazione. Tra gli svantaggi principali sono da considerare:

  • l’impossibilità di raggiungere il footer
  • l’impossibilità di linkare la pagina in uno stadio intermedio
  • la memoria richiesta dal browser per gestire pagine di questo tipo

Alcuni problemi possono essere aggirati, ad esempio inserendo un tasto per caricare i nuovi contenuti invece di farlo in automatico, ma questo non elimina tutti i difetti.

Molto dipende sicuramente dal sito: in certi casi non ha senso mostrare 200 pagine, soprattutto nel caso dei risultati di ricerca o di contenuti ordinati per rilevanza. Voi cosa ne pensate? Usereste lo scrolling infinito sul vostro blog?

Se siete interessati a sperimentare, esiste un plugin WordPress che introduce questo tipo di navigazione: pro e contro sono elencati anche dall’autore, valutateli con attenzione e se avrete dei risultati interessanti fatemi sapere!

10K Apart: un’applicazione web in 10kB

La sfida? Realizzare una web app minimalista e concorrere alla vincita di 3000$.

Con l’arrivo della banda larga e l’aumento della velocità di connessione, internet è stato affollato da applicazioni e siti web molto più pesanti del necessario. Qualcuno potrebbe erroneamente pensare: “A cosa serve l’ottimizzazione quando ci sono connessioni ADSL disponibili?”

Questo atteggiamento è sbagliato, e proprio per fare un salto nel passato e tornare a realizzare applicazioni ben ottimizzate è stato lanciato il concorso 10K Apart. Ci sono più di 10000$ in premi per i concorrenti: l’invito è quello di proporre delle applicazioni web che non occupino più di 10 kilobyte.

L’introduzione sul sito infatti recita:

It’s time to get back to basics — back to optimizing every little byte like your life depends on it. Your challenge? Build a web app in less than 10 kilobytes.

E’ possibile appoggiarsi a delle librerie esterne per migliorare le proprie creazioni dal punto di vista grafico e funzionale: jQuery, Prototype e Typekit sono ammesse, e non influiranno sul conteggio dei 10kB.

Se volete partecipare avete tempo fino al 25 agosto. Intanto è possibile già vedere sul sito ufficiale le web app proposte, in attesa di conoscere il vincitore.

Flipboard per iPad è il magazine del futuro?

Un’App per iPad reinventa la rivista in forma digitale, grazie alle notizie condivise su Facebook e Twitter.

Flipboard for iPadIn questi giorni un’applicazione per iPad sta facendo molto parlare di sè: si tratta di Flipboard, definito dai suoi creatori un social magazine.

Dopo averlo provato per qualche giorno, posso dire che è davvero un’idea interessante, sicuramente migliorabile, ma con una serie di implicazioni notevoli per quanto riguarda la fruizione delle news in rete.

Come funziona Flipboard?

Flipboard permette di scegliere tra una serie di fonti quelle ritenute più interessanti, e le impagina in una sorta di rivista digitale. La parte interessante di questa applicazione è l’aggiornamento in tempo reale: non sono presenti solo immagini e testi, ma anche commenti provenienti dai social network.

Il video introduttivo chiarisce ogni dubbio:

Facebook e Twitter

Se le fonti fossero solo quelle preimpostate il progetto sarebbe sicuramente meno interessante. Il vero punto di forza di Flipboard è la possibilità di integrare i propri account di Facebook e Twitter per riceverne aggiornamenti istantantanei. I link condivisi dai propri amici vengono impaginati in maniera elegante, ed è quindi possibile sfogliarli e commentarli.

Vista la grande richiesta di questi giorni, al momento dell’installazione questa feature non è immediatamente disponibile. Io ho dovuto aspettare qualche giorno, ma dopo nemmeno una settimana ho ricevuto sulla mia mail la notifica dell’attivazione del servizio.

Pregi e difetti

Dal punto di vista dell’interfaccia è difficile trovare dei difetti: Flipboard è una delle applicazioni più eleganti viste finora sull’App Store. E questo è uno dei punti che potrebbe fare discutere: è un banale esercizio di stile o in questo modo i contenuti degni di nota vengono valorizzati come meritano?

In previsione futura, considerando che è stata annunciata anche l’integrazione con Flickr e Foursquare, le cose potrebbero farsi ancora più interessanti. Al momento sembra difficile poter pensare che Flipboard possa prendere il posto di Google Reader (magari accompagnato da Feedly), ma se il futuro sarà davvero social, questa potrebbe essere la strada giusta da seguire.

Approfondimenti: segnalo anche su Apogeonline un ottimo articolo su Flipboard.

Testo alternativo sulle immagini: è obbligatorio per Flickr?

Le immagini sulle community fotografiche devono avere un testo alternativo o no?

Parlando di immagini ed accessibilità è fondamentale considerare il testo alternativo (alt=”…”), spesso indispensabile. C’è però un caso particolare: le community fotografiche come Flickr, che hanno al centro di tutto delle immagini senza altri contenuti testuali.

In questo tipo di contesto, l’alt text è davvero indispensabile? L’argomento viene trattato in maniera molto interessante su Rebuilding the Web, con alcune riflessioni degne di nota.

A cosa serve il testo alternativo?

Il testo alternativo serve per comunicare lo stesso significato di un’immagine quando quest’ultima non è visibile. Questo è un concetto fondamentale: molti infatti si confondono, pensando che l’alt text serva a descrivere un’immagine aggiungendo altri significati.

Il fattore determinante è il contesto in cui viene inserita l’immagine, che ne influenza il significato.

Prendiamo un’immagine come esempio:

Foto di un gatto addormentato

Se fosse affiancata dal testo “Il mio gatto dorme sempre”, un testo alternativo valido potrebbe essere “E’ su un letto a fare l’ennesimo pisolino”. Oppure se il testo fosse “Ho un gatto da 7 anni”, potrei usare come alt “Dorme spesso ed è bianco”.

Questi esempi non sono assoluti, le combinazioni possibili sono tante e non è sempre intuitivo stabilire il testo alternativo migliore per un’immagine. Chiarire il concetto non è semplice, ma se vi vengono in mente esempi migliori fatemi sapere!

Immagini senza contesto

Nel caso  di immagini non accompagnate da alcun testo invece le cose diventano più complicate, proprio perché non esiste un contesto in cui inserire il testo alternativo.

Aggiungere un alt text come “Il mio gatto mentre dorme sul letto nella casa al mare in Versilia” comunicherebbe sicuramente informazioni utili, ma nel modo sbagliato. Il testo alternativo (lo dice la parola) deve servire a trasmettere un significato equivalente, senza aggiungere dettagli non intuibili altrimenti.

E le immagini sui siti di photo-sharing?

Proprio per questo motivo l’alt text perde significato sulle community che hanno al centro di tutto delle immagini. Qual è la soluzione migliore? Non è facile dare una risposta, ma una pratica corretta potrebbe essere sfruttare i campi destinati a titolo e descrizione per spiegare la foto, lasciando l’alt vuoto.

Prendendo l’esempio di Flickr, nell’ultimo redesign l’alt delle foto è “photo”. Serve a qualcosa? Non direi, sarebbe stato meglio lasciarlo vuoto. Sono presenti però titolo e descrizione, che se usati correttamente potrebbero proprio servire allo scopo desiderato.

In un sito simile, il problema di spiegare il significato di un’immagine non è una questione di accessibilità, ma di usabilità. Non sono infatti solo gli utenti non vedenti a voler conoscere il soggetto di un’immagine: anche tutti gli altri visitatori hanno bisogno di dettagli che non sono intuibili dal contesto.

Una parte di questo problema sarà progressivamente risolto grazie all’uso della tecnologia: basti pensare al gps che ricava la posizione di una foto ed ai dati exif, che vengono già mostrati in automatico. Per quanto riguarda il resto al momento non ci sono soluzioni: solo con una descrizione testuale aggiuntiva sarà possibile avere delle pagine veramente informative, usabili ed accessibili.

Touchscreen e accessibilità

Siti accessibili ai touchscreen ed alcune implicazioni della loro diffusione.

Le linee guida per la realizzazione di siti accessibili da tempo hanno chiarito un punto: è fondamentale offrire ad un utente la stessa esperienza di navigazione, indipendentemente dal dispositivo utilizzato. Se fino a poco tempo fa era ovvio pensare alla navigazione da tastiera oltre a quella via mouse, l’avvento dei touchscreen ha aggiunto un altro livello di complessità.

Non si tratta di una questione banale, perché utilizzare un touchscreen è un’esperienza totalmente diversa rispetto alla navigazione tradizionale: ve ne sarete resi conto se avete uno smartphone o un iPad.

Cosa dicono le linee guida

Tra i 22 requisiti per la verifica tecnica della legge Stanca, è da sottolineare il numero 16:

Garantire che i gestori di eventi che attivano script, applet oppure altri oggetti di programmazione o che possiedono una propria specifica interfaccia, siano indipendenti da uno specifico dispositivo di input.

Ed anche un passaggio del requisito 21:

I collegamenti presenti in una pagina devono essere selezionabili e attivabili tramite comandi da tastiera, tecnologia in emulazione di tastiera o tramite sistemi di puntamento diversi dal mouse.

Indicazioni di questo tipo esistono anche nelle WCAG, sia nella loro versione 1.0 che nella più recente 2.0. Un esempio è la linea guida 9 delle WCAG 1.0: Design for device-independence.

I problemi con i touchscreen

La differenza fondamentale tra un mouse ed un touchscreen è che per il secondo non esiste mouseover. Potrebbe sembrare una banalità, ma se pensate a quanti siti utilizzano i CSS o JavaScript per scatenare un evento al passaggio del mouse, potete rendervi bene conto dell’entità del problema (menu a tendina, tooltip…).

Fino ad ora la soluzione più utilizzata consiste nel trasformare il mouseover in un ulteriore clic, anche se questo aumenta la complessità della navigazione. E’ una soluzione efficace? Sì, perché risolve il problema, ma non è detto che sia quella ottimale.

Il discorso quindi si lega anche al tema usabilità ed al design delle interfacce: è inevitabile che l’arrivo di una nuova modalità di navigazione introduca nuove variabili.

Da evitare

Sono sicuramente da eliminare o rappresentare in maniera differente:

  • contenuti leggibili solo con lo stato :hover (ad esempio testi con poco contrasto rispetto al background)
  • link visibili solo al mouseover, normalmente poco distinguibili dal testo semplice
  • azioni correlate al mouseover su un particolare elemento (le più comuni sono modifica e cancella)

Uno sguardo al futuro

I touchscreen sono ormai sul mercato da anni, e la loro presenza continua ad aumentare. Tralasciando le discussioni sulla loro effettiva utilità, è logico pensare che nei prossimi anni continueremo a vedere dispositivi che li utilizzano, seguendo l’esempio dell’iPad.

In questo scenario è obbligatorio considerarne la presenza, soprattutto se si realizzano siti con interfacce fuori dal comune. Proprio questa originalità a volte può rendere un sito inaccessibile: l’importante è ricordare che non esiste solo il mouse.

La prima cosa da fare è assicurarsi che sia possibile usufruire di tutti i servizi di un sito indipendentemente dal mezzo utilizzato per navigare. I touchscreen hanno introdotto nuovi fattori, e la situazione è destinata a diventare sempre più complicata: pensate a chi sta già utilizzando la propria console di casa per navigare dal televisore, o a chi sta usando lo stesso Tv LCD per collegarsi ad internet. In futuro i dispositivi connessi alla rete saranno sempre di più: forse sarà l’occasione buona per vedere considerare l’accessibilità una necessità e non un lusso per pochi.

[Foto di bark]

IE9 ed il supporto dei CSS3

IE9 potrà sfruttare tutti i selettori dei CSS3: solo Opera presenta ancora dei problemi.

La novità degli ultimi giorni riguarda Internet Explorer 9: la futura versione del browser Microsoft supporta infatti tutti i selettori dei CSS3.

Incredibile ma vero, nella tabella di compatibilità preparata in maniera eccellente da Quirksmode, IE9 entra infatti nel gruppo dei browser che possono utilizzare tutti i selettori più utili, compresi anche alcuni dei CSS 2.1.

I selettori supportati da Internet Explorer 9

CSS 2.1

  • :before e :after
  • :first-child
  • :focus

CSS 3

  • :empty
  • :enabled, :disabled e :checked
  • :first-of-type
  • :last-child
  • :last-of-type
  • :not
  • :nth-child()
  • :nth-last-child()
  • :nth-last-of-type()
  • :nth-of-type()
  • :only-child
  • :only-of-type
  • :root
  • ::selection
  • :target

In questa lista sono esclusi alcuni selettori che sono già supportati dalle versioni precedenti di IE.

Interessante notare che mentre le ultime versioni di Firefox, Safari e Chrome non hanno problemi, adesso è Opera l’unico browser ad essere rimasto indietro, con delle difficoltà di interpretazione dei selettori :nth-child() ed :nth-of-type(). Opera infatti non riesce ancora a capire il funzionamento di queste regole, utili ad esempio per evidenziare gli elementi pari di una lista, o dare alternativamente a delle immagini float:right e float:left.

Implicazioni future

Questo ovviamente non significa che con l’uscita di Explorer 9 i selettori dei CSS3 potranno essere usati senza problemi (le versioni precedenti ci faranno compagnia per molto tempo), ma ci stiamo avviando verso un futuro più semplice per gli sviluppatori. L’uso di queste regole infatti consentirà di eliminare id e classi inutili dall’HTML, alleggerendo la struttura delle pagine.

Per il momento non resta che sperimentare ed affidarsi se necessario a soluzioni come ie-css3.js, aspettando la scomparsa dei browser più obsoleti.

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.

WordCamp Catania: il resoconto

Riflessioni sul WordCamp catanese del 18 giugno 2010, tra Wordpress 3.0 e nuovi incontri.

Il 18 giugno scorso ho partecipato al primo WordCamp italiano lontano da Milano: era la prima volta che veniva organizzato un barcamp su WordPress nel sud Italia, e mi ha fatto molto piacere poter essere presente a Catania.

Dopo essere stato presente alle edizioni milanesi del 2008 e del 2009, i confronti vengono quasi spontanei, e devo ammettere che sono rimasto molto contento dell’evento organizzato da Roberto Chibbaro. Era una bella occasione per coinvolgere delle realtà che molto spesso vengono colpevolmente dimenticate, e poter assistere a degli interventi interessanti mi ha permesso di fare diverse conoscenze utili.

Proprio sulle differenze di mentalità ha scritto un post interessante Luca, che è riuscito a dipingere un quadro molto verosimile, confrontando i diversi scenari che ci si possono parare davanti partecipando agli eventi di networking tra Londra, Roma e Catania. Quella della Sicilia è una realtà viva, che ha voglia di mettersi in mostra ed è capace di presentare delle idee interessanti, ma incontra difficoltà nel metterle in pratica. Parlare poi di soldi e finanziamenti per delle idee è quasi un’utopia: difficile trovare qualcuno disposto ad investire.

Nonostante tutto però c’è chi ha ancora voglia di emergere, e per questo non posso che fare i complimenti a chi continua ad insistere cercando una via per mettersi in mostra, come i ragazzi di Your Inspiration Web. I loro talk sono stati interessanti, così come è stato molto discusso l’intervento di Francesco “Fullo” Fullone, che ha esaminato WordPress sconsigliandone l’utilizzo in casi estremi, dove altri CMS si comporterebbero meglio.

Ho cercato di dare anche io il mio contributo, con un breve speech riguardante la mia esperienza con GdR Players. E’ stato utile discutere insieme ai presenti dell’utilizzo di WordPress per una community ridotta ai minimi termini, considerando anche ipotesi alternative come BuddyPress o le novità della versione 3.0. Mi ha fatto piacere ricevere pareri, suggerimenti e proposte interessanti, segno che la semplicità di WordPress continua ad attirare ed incuriosire, anche dopo gli ultimi aggiornamenti.

Se volete avere un quadro ancora più completo dell’evento, in rete potete trovare:

Le slide della mia presentazione, dal titolo WordPress per una community?”, sono le seguenti. Vederle fuori dal contesto non è ovviamente l’ideale, ma potete farvi comunque un’idea del contenuto:

L’appuntamento è per il WordCamp 2011: se avete proposte, suggerimenti, oppure eravate presenti e volete aggiungere qualcosa, i commenti sono a vostra disposizione.

Un ultimo ringraziamento va a Roberto ed a Giovanni, che con i loro consigli mi hanno regalato una fantastica settimana di vacanza in giro per la Sicilia.

Gli strumenti per valutare l’accessibilità di un sito servono davvero?

Elenchi di tool più o meno utili, validazione del codice e accessibilità di un sito web. Come orientarsi?

Navigando su internet spesso capita di imbattersi in nuovi tool per valutare l’accessibilità di un sito. Non mancano post che presentano liste infinite di strumenti utili per rendere un sito “accessibile”, e che promettono di dare un contributo alla causa con pochi click.

In queste circostanze però c’è un dettaglio da tenere sempre presente: un sito accessibile non può prescindere dalla validazione manuale, effettuata da una persona in carne ed ossa.

Gli strumenti automatici possono aiutare in determinate circostanze, ma alcuni tipi di controlli così come la scrittura del codice devone essere effettuati da uno sviluppatore. Per alcuni requisiti infatti non esistono ancora i mezzi per sostituire la mente di un web designer ben preparato, per fortuna di chi lavora nel settore.

I tool utili

Non è comunque corretto generalizzare, perché esistono vari strumenti efficaci. Questi tool vanno presi seriamente in considerazione quando un controllo manuale richiede troppo tempo o è effettivamente impossibile: sono un esempio il controllo del contrasto dei colori, della leggibilità per utenti daltonici, e la ricerca di errori HTML in lunghi estratti di codice.

Quelli di cui non posso fare a meno sono:

Graybit

Permette di convertire un sito esistente in bianco e nero. Utilizzando solo tonalità di grigio è molto più facile capire se il contrasto di determinati elementi sia sufficiente. E’ così possibile avere un’idea di come certi utenti potrebbero visualizzare il sito in esame.

Check My Colours

Avevo parlato già della creazione di Giovanni Scala: Check My Colours è un altro utile strumento per valutare il contrasto degli elementi di un sito web. Il test è molto severo e rigoroso, e fa bene il suo dovere.

Juicy Studio Tools

Questo sito offre diversi strumenti utili: il più famoso è quello per analisi del contrasto dei colori (esistente anche come estensione di Firefox), ma non è l’unico tool disponibile. Tra quelli esistenti, segnalo Image Analyser, che unisce in modo intelligente la praticità di un test automatico con la validazione manuale, per controllare che le immagini di una pagina abbiano il testo alternativo corretto.

Come realizzare un sito accessibile?

L’obiettivo di questo post non è spiegare passo dopo passo la realizzazione di un sito accessibile, ma una considerazione è d’obbligo: la progettazione di un sito che rispetti determinati requisiti inizia fin dalle prime bozze, ancora prima della realizzazione delle proposte grafiche.

Una parte fondamentale è anche la scrittura del codice delle pagine: realizzare un template HTML rispettando gli standard del W3C è un primo passo per la realizzazione di un sito accessibile. E’ molto più difficile fare il percorso a ritroso, analizzando a posteriori un sito già esistente.

Proprio per questo motivo l’utilizzo di qualsiasi validatore automatico viene dopo l’abilità di uno sviluppatore: se il codice di un sito è ben realizzato, renderlo accessibile sarà più facile. Ricorrere a tool esterni significa che molto probabilmente sono stati commessi degli errori in passato, o si è trascurato il tema dell’accessibilità in fase di creazione per poi pagare la scelta a caro prezzo.

L’incognita più grande resta però quella riguardante i contenuti. Non serve a niente realizzare un template accessibile (vedi Stardust per WordPress), se poi chi si occupa di gestire il sito non tiene conto di determinati problemi come l’alt text delle immagini o la leggibilità dei testi. Un sito accessibile può essere tale solo se tutte le parti coinvolte sono coscienti del problema e sanno come gestirlo, altrimenti è facile ritrovarsi con un risultato scadente.

Aggiornamento: è stato pubblicato proprio in questi giorni un interessante articolo sulle checklist dei test di accessibilità automatici. L’argomento è del tutto simile a quello trattato in questo post, con alcune proposte e raccomandazioni. Le conclusioni sono simili, ma vi consiglio di leggerlo (è in inglese): Can checklist accessibility be harmful?