Checklist per l’ultimo miglio

Come responsabile e project manager di progetti web ho aiutato nella messa online di più di 200 siti e applicazioni. Alcuni molti impegnativi e ad alto traffico, diversi di medie dimensioni, decine per piccole realtà.

Ogni progetto è diverso dagli altri, vuoi per le esigenze del cliente e le relazioni che si vengono a creare, vuoi per il progresso della tecnica, vuoi per le mutazioni che gli stessi team di lavoro subiscono negli anni.

Eppure, che il progetto sia piccolo o grande, quando il giorno per la messa online è arrivato nascono i patemi d’animo. Dobbiamo finire di verificare qualcosa? Quali sono i passi per portare “su” il progetto? È necessario ripetere qualche test?

Per rispondere a queste domande ho creato, nel corso degli anni, una checklist molto informale che io e il mio gruppo usiamo in questa circostanza, quando le cose da fare sono molte, il nervosismo è alle stelle, ma il tempo è poco.

Vorrei condividere con voi questa checklist. L’occasione è stata uno scambio di email con Miriam Bertoli sull’argomento “ultimo miglio”. Occasione che mi ha permesso da un lato di fare un po’ d’ordine tra gli appunti, dall’altro di inserire alcune considerazioni ed elementi suggeriti da Miriam.

La lista, come potete immaginare, è tutt’altro che completa e rappresenta un (timido) tentativo di organizzare gli ultimi giorni prima della messa online. Ho volutamente eliminato diversi elementi specifici per le realtà con cui lavoro o ho lavorato, perché inutili. Non vi si trovano inoltre, se non sparsi qua e là, espliciti riferimenti alle verifiche in fatto di accessibilità e usabilità, a cui solitamente dedico specifici documenti.

Siete anche invitati a indicarmi eventuali altri punti da tenere in considerazione.

Checklist per l’ultimo miglio – versione 1.0 (pdf, 52 Kbyte)

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.