L’accessibilità dei giochi olimpici

AbilityNet ha da poco pubblicato un’importante analisi relativa all’accessibilità del sito ufficiale dei giochi olimpici.

Il risultato ce lo potevamo probabilmente aspettare: il sito risulta solo parzialmente accessibile a indicare una scarsa conoscenza dei realizzatori in fatto di accessibilità web. Tutto questo dopo che 4 anni fa un non vedente vinse una causa contro la Commissione Olimpica per il sito dei giochi di Sidney, come racconta egregiamente Joe Clark (che ho avuto il piacere di intervistare qualche anno fa).

Al di là dei risultati, però, lo studio è interessante per le modalità con cui è stato condotto.

In AbilityNet non hanno infatti utilizzato alcuno strumento automatico di verifica dell’accessibilità.  Come scrivevo ormai 6 anni fa in Cos’è l’accessibilità web:

La verifica di un sito accessibile non avviene esclusivamente via software. Programmi con Bobby di Cast, A-Prompt di Trace aiutano ad evidenziare lacune e punti di miglioramento, ma questo non è che il primo passo.

I problemi di accessibilità nascono soprattutto da errori di architettura o di progettazione che è possibile risolvere solo applicando le linee guida nel contesto del sito in esame.

Si è preferito impegnare persone con diversi tipi di disabilità e indicare alcuni compiti da svolgere, come leggere il programma degli eventi, trovare i tempi di qualifica di una disciplina, comperare un biglietto.

Nulla di diverso da quello che normalmente si fa nei test di usabilità di un sito. Ed è corretto, dal momento che accessibilità e usabilità web si completano.

E’ davvero illuminante e allo stesso tempo sconcertante dare un’occhiata ai filmati in cui i 4 disabili incontrano difficoltà nel compiere anche le operazioni più semplici a causa della scarsa cura in termini di accessibilità web.

Ecco alcuni spunti tratti e commentati dal documento:

  • per il sito delle olimpiadi è stato utilizzato un approccio esclusivamente tecnico all’accessibilità, utilizzando le linee guida WAI come sterile lista di punti da seguire
  • uno dei principali problemi riscontati dall’utente cieco è che i video e gli audio presenti nella pagina iniziano l’esecuzione in automatico, senza la presenza di opportuni controlli di play/stop. Questo provoca delle sovrapposizioni vocali con gli screen reader, rendendo difficoltosa la comprensione del contenuto
  • le tabelle di contenuto in un sito devono essere pensate per poter essere interpretate da sinistra verso destra, e non dall’alto al basso, come invece avviene per la pagina del programma delle olimpiadi
  • nel corso delle olimpiadi i responsabili del sito hanno migliorato alcuni aspetti dell’interfaccia. Indice che il tema dell’accessibilità web è stato sottovalutato e solo a seguito di lamentele si è deciso di porre qualche parziale rimedio. Non quindi un limite dell’infrastruttura utilizzata (comunque non giustificabile), ma di pessima progettazione

Sempre in tema di accessibilità del sito delle olimpiadi, vi suggerisco la lettura di questa dettagliata analisi di Rnib, seguita da una seconda parte, che già più di un anno fa aveva lanciato un grido di allarme, rimasto purtroppo in gran parte inascoltato.

Dietro le quinte del nuovo template di Fucinaweb

Temi per WordPress ne troviamo a vagoni nel web, una ricerca con google dei termini “worpress theme” ritorna più di 78 milioni di pagine e devo dire che parecchi sono anche molto belli. Se li guardiamo per il blog del nostro cliente o per il nostro primo blog ne troviamo sicuramente uno che ci piace. Se invece siamo alla ricerca di un nuovo tema per il nostro blog troviamo in ognuno una noticina stonata, manca quel tocco che lo porta alla perfezione e che lo rende adatto a vestire il *nostro* blog.

Chi ha già un proprio blog da tempo è una sensazione che sicuramente conosce (su dai ammettiamolo!) ed è la scintilla dell’idea “mi faccio il mio tema”, la motivazione per la quale sono stato coinvolto da Antonio in questa avventura che ci ha portato a rivestire Fucinaweb con un proprio tema fatto su misura.

Io ho seguito lo sviluppo del template di partenza e la declinazione della grafica in html con molta attenzione a mantenere la compatibilità Xhtml Strict e la accessibilità dei contenuti.

Il template quindi non ha tabelle ma solamente layer disposti in maniera tale da garantire il corretto flusso delle informazioni. I tag html e i loro attributi sono stati utilizzati in modo tale da identificare correttamente i vari contenuti: liste puntate (tag ul e li) per i menu, header nidificati (tag h1 h2 h3) per i titoli , paragrafi (tag p) per i contenuti di testo, immagini (tag img) identificate da title e testo alternativo.

Il compito di rendere il sito piacevole alla vista e facilmente navigabile è stato lasciato completamente al foglio di stile nel quale tutte le dimensioni sono espresse in em, unità di misura relativa che consente la scalatura del sito alle varie risoluzioni e adattabile alle dimensioni del testo impostato dal browser del navigatore.

Antonio poi nell’opera di rifinitura ha aggiunto un paio di finezze veramente interessanti come i microformat e il foglio di stile per una stampa perfetta (argomenti per i quali spero ci regalerà un articolo prossimamente).

Altri perfezionamenti e aggiustatine in corsa ce ne saranno di sicuro visto che c’è sempre qualcosa di nuovo da scoprire e noi siamo pronti a provarle e divulgarle per crescere insieme a Fucinaweb.

L’accessibilità nello sviluppo di un sito

Qualche anno fa ho scritto per evolt.org un articolo, “The lifecycle of wb accessibility“, in cui sottolineo l’importanza di considerare l’accessibilità web non come un singolo passaggio di un progetto, ma come una necessità che ne influenza l’intero ciclo, dalla fase di analisi dei requisiti fino alla manutenzione.

Hi ritrovato una simulitudine tra questo articolo e l’intervento che Peter Krantz ha scritto per Standards Schmandards, “Bringing Accessibility into the Development Process“.

Krantz si chiede in particolare se possa essere impiegato qualche software di validazione che sia in grado di fornire un primo livello di allerta in tempi brevi ai componenti del team di progetto web. Propone l’uso di Raakt (The Ruby Accessibility Analysis Kit), un “gem” di Ruby on Rails per l’inclusione negli unit test Html.

Nella carta questo kit si rivolge a chi ha poca conoscenza di accessibilità web e potete vederne un impiego in azione così da saggiarne le caratteristiche.

Come al solito, serve un po’ di cautela e coscenza critica: l’accessibilità web fa a botte con i tool automatici.

Qualcuno di voi ha avuto modo di provarne le funzionalità?

italia.it e le bugie sull’accessibilità

A italia.it avrei perdonato tutto: il costo, il ritardo, il risultato mediocre. Non avrei scommesso un centesimo su un progetto fermato e fatto ripartire più e più volte, e mi sarei anzi stupito di trovarmi a navigare un sito piacevole e completo.

Tutto avrei perdonato, meno che le bugie, soprattutto quelle riguardanti il grado di accessibilità che ci si vanta di aver raggiunto. Sono fatto così, le frottole mi hanno sempre infastidito.
Per farmi aiutare nella valutazione del grado di accessibilità di italia.it mi è bastato chiedere il “solito” piacere a Nicola e invitarlo a navigare dalla homepage con un software di tecnologia assistiva. I risultati lasciano spazio a pochi dubbi.

“Ieri sera ho trovato 10 minuti per visitare il portale italia.it.

Aprendo la home page, appare un filmato flash. I primi due pulsanti non sono descritti, pertanto la tecnologia assistiva segnala solo che si tratta di pulsanti.
Segue la dicitura “Enter in Italy”, che certamente disorienta chi non conosce l’inglese. Seguono link alle diverse lingue e finalmente un link “italiano”, che sembra fare al caso nostro.
Per il resto ancora frasi in inglese che fanno riferimento ad una newsletter ed altre amenità.

Premendo invio su italiano si arriva in una pagina che sembra più accessibile e i link per saltare direttamente al menu di navigazione ed al contenuto della pagina lo testimoniano.
La presenza di un filmato flash provoca l’aggiornamento continuo dello schermo. L’utente non è avvertito in nessun modo di questo fatto, ma se ne accorge a sue spese, perché la tecnologia assistiva continua a rileggere le stesse informazioni, in quanto il cursore virtuale si sposta continuamente per seguire l’aggiornamento della pagina. Si è costretti a ricorrere alle opzioni dello screen reader, che consentono di evitare che lo stesso segua gli aggiornamenti dei filmati Macromedia Flash.

Il link per accedere alla Versione accessibile per un non vedente appare dopo aver scorso più di metà pagina.La versione accessibile sembra poi riferirsi non all’intero sito, ma alla cronologia dei fatti.

Un’altra cosa che vale la pena notare è che questo sito permette di scaricare dei software assistivi (un browser vocale e non so cos’altro). Forse non si sono posti il problema che uno per arrivare alla pagina da cui scaricare questi software deve già disporre di una tecnologia assistiva e per di più le pagine per le quali transita devono essere accessibili.

In definitiva i contenuti si riescono a raggiungere, ma se si cerca ad esempio di accedere alla mappa interattiva, l’utente non viene avvertito che sta per accedere ad una pagina non accessibile.
Risulta invece accessibile la mappa accessibile, che però si trova dopo una serie sterminata di link.

Questo è un giudizio da utente, senza entrare negli aspetti tecnici relativi al codice HTML.
Purtroppo in questo periodo non ho molto tempo per fare prove più approfondite, spero che le righe che ti ho scritto sopra possano bastare come spunto.”

Secondo me questi dieci minuti sono più che sufficienti per capire se il sito è accessibile. Secondo voi?

Un lustro di Fucinaweb

Fucinaweb nasceva l’1 Febbraio 2002 allo scopo di promuovere la progettazione di un sito web a 360 gradi, considerando i diversi elementi (sviluppo, information architecture, usabilità, accessibilità, web design) come realtà tra loro in comunicazione e non a compartimenti stagni.

Con la messa online del sito sono stati pubblicati una serie di corsi tematici, uno riguardante Asp.net e un altro focalizzato sul web design, seguiti poco dopo da un corso di accessibilità web.

Questi cinque anni sono un modo per fare un consuntivo su quello che è stato fatto e scritto. Sono stati in particolare pubblicati fino ad oggi circa 250 tra articoli, recensioni e segnalazioni, di cui i 5 più visitati “di tutti i tempi” sono:

Ma se dovessi scegliere il mio preferito, non avrei dubbi, e suggerirei di leggere il (prolisso) “Gli standard web sono inutili (da soli)“, un articolo rivolto a chi considera gli standard web fini solo a sé stessi, senza considerare le complessità di un progetto web nel suo insieme. Un articolo a suo tempo criticato da molti, a mio parere senza troppe motivazioni convincenti.

Fucinaweb non è nato come weblog. Mi ricordo che all’inizio era gestito completamente “a mano”: la pubblicazione di un articolo prevedeva l’inserimento di tutto il codice Html, la compilazione di tutti i link in cui quell’articolo veniva citato, e la copia di tutto via Ftp, sempre manualmente. Dopo qualche esperimento con WordPress sul mio sito personale ho poi deciso di procedere alla migrazione di tutta Fucinaweb a questa piattaforma, scelta che rifarei subito. Nel procedere con la migrazione ho cercato quanto più possibile di mantenere funzionanti i link della precedente versione, processo che ho documentato nell’intervento “Sito nuovo, Url vecchi“, per evitare che il traffico proveniente dai motori di ricerca venisse subito penalizzato.

Da qualche mese ho registrato il dominio fucinaweb.it, che a suo tempo non era disponibile. Questo banale particolare mi ha sempre infastidito, soprattutto perché il sito che rispondeva a quel dominio, realizzato da una sconosciuta web agency, tutto era fuorché accessibile, usabile, standard…una presa in giro.

Mi fermo qui, ma per chi volesse saperne di più vi consiglio di leggere l’intervista che il bravo Mirko di Blographik mi ha rivolto in questi giorni e che affronta anche altri temi a me cari, come il project management e il difficile rapporto con il cliente e l’usabilità.
Questi i primi cinque anni di questo sito: suggerimenti su come affrontare i prossimi cinque?