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à?