Watchfire Bobby 5.0

E’ da poco uscita la versione 5 di Bobby, uno di quegli strumenti che aiutano gli sviluppatori web ad evidenziare carenze di accessibilità nelle pagine web.

Bobby è disponibile in una versione gratuita (per il momento ancora la versione 4) utilizzabile online e una versione desktop (venduta a 299 dollari, 199 per chi la acquista entro il 7 Maggio 2003), arricchita di funzionalità, di cui ci occuperemo.

Come ben sanno i lettori del nostro corso di accessibilità web, è impossibile per un software evidenziare nel modo corretto tutte le problematiche relative all’accessibilità, dal momento che molte dipendono da fattori (chiarezza del linguaggio, utilizzo sensato del markup) non misurabili.

L’utilizzo di questi strumenti è comunque utile per “scremare il grosso” degli errori di accessibilità, spianando così la strada all’intervento umano.

State comunque sempre attenti: se da un lato un software può non rilevare problematiche esistenti, dall’altro (complici le carenze delle linee guida Wai) potrebbe intestardirsi nel sottolineare errori che sono in realtà di poco conto.

Detto questo, analizziamo alcune significative caratteristiche di questa versione.

Niente più Java

Uno dei limiti della precedente versione di Bobby era dato dal peso dell’applicativo, costruito interamente in Java.

Questa versione di Bobby è completamente nativa Windows, rendendo più agevole e veloce l’uso e la personalizzazione dell’interfaccia grafica.

Una schermata di bobby: una treeview con a destra un pannello di dettaglio

Interfaccia grafica che è stata completamente riveduta ed è ora più semplice da usare, anche se poteva essere fatto qualche sforzo in più per organizzare organicamente le diverse funzioni del programma.

Verifiche veloci e puntuali sia online, sia offline

La principale differenza rispetto alla versione precedente è la possibilità di configurare con precisione il sito (o i siti) da analizzare. Non solo è possibile definire il punto di partenza e lasciare a Bobby l’ingrato compito di seguire i link delle pagine ad esso collegati, ma possiamo specificarne la profondità, ed eventualmente i documenti da escludere.

E’ possibile analizzare sia siti online, sia offline. Nel primo caso basta semplicemente inserire l’Url di partenza, e Bobby si occupa di interrogare e scaricare le pagine dal server.

Pannello che consente di introdurre il nome del sito e il livello di profondità da analizzare

Nel caso si voglia invece analizzare un sito locale, è possibile specificare anche la directory di partenza del sito, in modo che link del tipo <a href=”/percorso/”> vengano risolti correttamente.

Pannello che consente di specificare la directory locale di riferimento per risolvere i link

Alcune opzioni avanzate consentono inoltre di interagire con siti protetti da password, siti che completano la QueryString con riferimenti alla sessione (e che vanno tolti, per evitare a Bobby di analizzare più volte la stessa pagina), siti distribuiti su più domini.

Test personalizzati

Un’importante caratteristica di Bobby 5.0 è data dalla possibilità di scegliere il tipo o il numero di linee guida da verificare per il proprio sito.

Questo non vuol dire semplicemente scegliere tra Wai A,AA,AAA e Section 508, ma scegliere puntualmente quali utilizzare e quali no.

E' possibile selezionare una per una ogni linea guida

E’ un’utile funzione, soprattutto considerando le carenze di alcune linee guida.

Risultati simili alla versione precedente

Chi si aspettava un miglioramento nella capacità di rilevare problematiche inerenti l’accessibilità potrebbe rimanere deluso. I risultati della versione 5 sono infatti pressoché identici a quella precedente. Nulla di cui stupirsi comunque: il problema è che alcune linee guida non possono essere verificate via software; per tutte le altre, già la versione 4 di Bobby svolgeva un ottimo lavoro.

L’unica differenza è che questa versione dello strumento, che è più efficiente nello scovare Url non collegati direttamente ad una pagina (ad esempio in un’istruzione Javascript, in un’animazione Flash o in una form), potrebbe trovare errori prima non raggiungibili.

Bobby cerca di estrarre link anche da file javascript e animazioni Flash

Report completi

La qualità dei report è stata migliorata e organizzata, come dimostra una prova che abbiamo realizzato. L’unica nota negativa è che non sembra essere possibile passare agevolmente dai report Wai A ad AA, AAA o Section 508 senza ripetere l’analisi del sito, anche se il manuale recita il contrario. Notevole la mancanza di un’opzione di salvataggio o di stampa, a cui si può ovviare agendo con il pulsante destro del mouse all’interno della pagina, che altro non è se non una finestra del browser.

Manuale in Pdf

La versione desktop è accompagnata da un comodo manuale in formato Pdf, che avrebbe però potuto presentare qualche esempio concreto oltre ad una sterile lista di operazioni.

Conclusioni

La versione 5 di Bobby, dal punto di vista dell’organizzazione dell’interfaccia e delle opzioni disponibili, compie notevoli passi avanti. La caratteristica più importante, e cioè la capacità di aiutare nel costruire un sito accessibile, è però praticamente invariata. Se non lavorate con siti di grosse dimensioni, quindi, non otterrete praticamente nessun vantaggio nel passare a questa versione.

Verificare i siti con uno screen reader

Questo articolo fa parte di un corso gratuito di accessibilità web ospitato su questo sito.

Scritto in collaborazione con Nicola Ferrando.

Nella scorsa puntata del corso abbiamo avuto modo di conoscere gli strumenti che aiutano i non vedenti e gli ipovedenti nella fruizione di un sito web.

Screen reader e browser vocali possono anche essere utilizzati dagli sviluppatori per verificare il livello di accessibilità della pagina, senza però dimenticare che il pubblico di un sito accessibile è più esteso e comprende altre categorie. Si tratta quindi di un test necessario, ma non sufficiente, per verificare l’accessibilità di un sito web.

Per capire come sia possibile realizzare un test utilizzando uno screen reader vi proponiamo tre esempi tratti da siti web famosi, in particolare la home page e la pagina di ricerca di Yahoo! Italia e la home page di Rai Sport.

Abbiamo scelto di non analizzare un sito costruito appositamente per soddisfare le linee guida Wai così da evidenziare le problematiche che deve affrontare chi deve affidarsi ad uno screen reader per leggere il contenuto di una pagina.

Siamo anche consci del fatto che è sempre molto semplice evidenziare le lacune di un sito, piuttosto che presentare validi esempi di buona accessibilità. Questi non sono quindi test di siti, ma casi d’uso da riportare alle vostre pagine.

Yahoo! Italia

L’analisi è stata realizzata il 28 Settembre 2002

Ascolta l’Mp3 della Home Page di Yahoo! (640 Kbyte)

Visualizza la pagina della Home Page di Yahoo!

Il frammento audio mostra quello che lo screen reader Jaws legge usando il comando “leggi tutto”, cioè il comando che interpreta l’intera pagina dall’inizio alla fine. Jaws scandisce automaticamente la pagina non appena viene caricata, ma è possibile interrompere la lettura in qualsiasi momento per esplorare con calma la pagina utilizzando i normali tasti di scorrimento del testo (tasti freccia, pagina giù, ecc.).

Il file è stato troncato: dura meno di 2 minuti, ma la lettura completa della homepage di Yahoo! ne richiede più di 4.

Quasi tutti gli elementi grafici sono completati dall’attributo alt, che viene regolarmente letto dalla sintesi vocale dopo la parola “grafico”.

Non è invece presente una etichetta che indichi immediatamente il significato del campo editazione che si incontra dopo la prima serie di link. Naturalmente la presenza del pulsante “Cerca” ben evidenziato immediatamente dopo al campo di immissione (che Jaws chiama “editazione”) non lascia dubbi. Inoltre tutti sanno che Yahoo! è nato come motore di ricerca, anche se con il tempo si sono aggiunti una serie sterminata di servizi, quali mail, gruppi, chat, ecc.

I servizi Mail e Gruppi sono perfettamente gestibili, ma lo stesso non si può dire per le Chat, a causa dell’intrinseca struttura di tali pagine, che prevedono un refresh continuo dello schermo con la comparsa di nuovi messaggi e l’uso di emoticons.

Ascolta l’Mp3 della ricerca di Yahoo! (600 Kbyte)

Visualizza la pagina della ricerca di Yahoo!

Nel secondo frammento audio si può ascoltare la lettura automatica della pagina contenente i risultati di una ricerca (abbiamo cercato la stringa “accessibilità siti web” ed abbiamo ottenuto 3 risultati).

Questa informazione ci viene fornita abbastanza presto, dopo circa 20 secondi, ma solo dopo altri 30 secondi inizieremo a leggere l’elenco dei risultati. Questo è dovuto al fatto che sulla sinistra dello schermo c’è il menu, che non è possibile saltare con un link del tipo “salta la barra di navigazione”, né sono offerti altri strumenti di orientamento, quali ad esempio le intestazioni (tag h1-h6) che consentano di individuare le diverse sezioni in cui è suddivisa la pagina web.

Rai Sport

L’analisi è stata realizzata il 28 Settembre 2002

Ascolta l’Mp3 della ricerca di Rai Sport (820 Kbyte)

Visualizza la pagina della ricerca di Rai Sport

Ascoltando il terzo frammento audio si nota subito la presenza di molti link grafici non commentati. In questo caso Jaws non può far altro che leggere il contenuto dell’attributo href del link che contorna l’immagine.

La recente versione 4.50 legge invece il nome del file associato al link: in taluni casi ciò permette di comprendere il significato del link. Se ad esempio l’immagine si chiama menucalcio.gif, si può immaginare che seguendo quel link si accederà alla sezione del sito dedicata al calcio. Tuttavia si tratta di un palliativo che non sempre funziona. Pensate ad esempio ai link che vengono costruiti con l’immagine di un pallino seguita dal testo descrittivo, che però non è cliccabile.

In questo caso il nome dell’immagine non varia e l’unico modo per capire dove porta il link, oltre a leggere il testo che lo segue, è esaminare il nome del file Html che verrà caricato. Questo è ciò che accadeva fino a poco tempo fa nelle sezioni interne del sito di Repubblica. Ora fortunatamente i link sono costituiti dai titoli degli articoli e ciò ne consente una chiara comprensione anche se avulsi dal contesto, come accade se si utilizza la funzione dello screen reader che consente di accedere all’elenco di tutti i link presenti sulla pagina web.

Tornando alla home page del sito di RaiSport, noterete che l’utente rimane ignaro del fatto che nella pagina sono presenti diverse applet, in particolare l’oggetto incorporato che consentirebbe di ascoltare e vedere l’ultimo Tg sportivo. Purtroppo gli oggetti di tipo embedded sono molte volte inaccessibili, in quanto lo screen reader non ha alcuno strumento per gestirli. Bisognerebbe accompagnare tali oggetti con un link di tipo tradizionale che consenta di accedere alla risorsa multimediale.