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.

Screen reader, display braille e browser vocali

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

Aggiornamento Febbraio 2006: Accessibilità web, lo stato dell’arte per gli screen reader

Scritto in collaborazione con Nicola Ferrando

L’uso di un sito web da parte delle persone disabili può avvenire anche grazie all’utilizzo di software o hardware dedicati.

Come sviluppatori e designer è importante che ci rendiamo conto di quali sono le possibilità e le difficoltà date dall’uso di questi strumenti. In questo modo matureremo delle conoscenze e costruiremo delle solide basi che ci aiutano nella progettazione e realizzazione di siti web accessibili.

In questo articolo prenderemo in esame i dispositivi in aiuto agli ipovedenti e ai non vedenti. Sappiamo bene che l’accessibilità web si rivolge ad un pubblico vasto (non solo le persone disabili nè tantomeno i soli non vedenti), ma è utile esaminare questo contesto perché:

  • sono disponibili prodotti ormai maturi e consolidati
  • possiamo eseguire agevolmente dei test per valutare l’accessibilità dei siti web

Screen reader

Gli screen reader, o lettori di schermo, sono degli applicativi che di
solito vengono eseguiti all’avvio del computer per consentire all’operatore
non vedente di avere fin da subito il controllo del sistema operativo. Questi
programmi trasformano in voce il testo che appare sullo schermo.

Le lingue selezionabili in Jaws

Nei Pc multimediali la voce sintetizzata viene prodotta attraverso la scheda audio
e le relative casse, ma esistono anche dispositivi esterni dedicati a
questa funzione, in modo da limitare l’uso della Cpu e della scheda audio.

Comunque, ormai il 90% dei ciechi utilizza la scheda audio del Pc, in quanto
questa soluzione è molto più economica di quella con hardware dedicato.

Il costo dello screen reader può variare dai 500 ai 1500 euro, mentre una
sintesi vocale hardware può costare anche 800 euro.

In Italia attualmente vengono commercializzati quattro screen reader:

  1. Jaws per Windows di Freedom Scientific
  2. Window-Eyes di GW-Micro
  3. OutSpoken di Alva-BV
  4. Hal per Windows di Dolphin Computer Access

Per i test e le dimostrazioni di questo articolo, abbiamo scelto la versione 4 di Jaws.

Display braille

Insieme alla funzione di sintesi vocale, presente in tutti gli screen reader
moderni, esiste anche un altro dispositivo hardware che può essere collegato
al pc: si tratta del display braille.

Un display braille

Questo dispositivo riproduce in alfabeto braille ciò che appare sullo schermo. Sono però pochi i ciechi che utilizzano questo strumento, sia per il suo costo elevato (si va dai 2500
euro
per un display da 20 caratteri fino a 7000 euro per uno da 80
caratteri
), sia perché sono pochi i non vedenti che conoscono l’alfabeto
braille.

Bisogna ricordare che il Dm Sanità 332/99 prevede che questi strumenti siano forniti come protesi dal servizio sanitario nazionale, quindi dalle
Asl. Tuttavia la normativa è assai farraginosa, per cui spesso risulta difficile usufruire di queste agevolazioni.

Browser vocali

A questa categoria appartengono i software realizzati esplicitamente per la navigazione dei siti web.

Rispetto agli screen reader, che sono strumenti per il controllo generico del sistema operativo e delle applicazioni, un browser vocale può essere utilizzato esclusivamente durante la visita ad un sito web oppure per scaricare la posta elettronica da una finestra del browser dedicata.

Proprio perché si tratta di un’applicazione ad hoc, generalmente è più semplice utilizzare un browser vocale in quanto è dotato di menù standard. Per comandare uno screen reader è invece necessario utilizzare delle combinazioni di tasti che non si trovino in conflitto con quelle normalmente utilizzate dalle applicazioni che il sistema operativo sta eseguendo.

I lettori vocali potrebbero così rappresentare una utile soluzione da impiegare nelle postazioni pubbliche di accesso a Internet, come ad esempio le biblioteche.

Ibm Home Page Reader è l’unico browser vocale degno di nota e dispone di un buon supporto ai tag ed attributi dell’Html accessibile.

FucinaWeb letto con Ibm Home Page Reader

Oltre a riconoscere il cambio di lingua all’interno del testo (sempre che chi realizza le pagine utilizzi l’attributo lang e l’utente configuri il reader perché riconosca automaticamente la variazione) riesce ad interpretare in modo efficace i numerosi tag e attributi per una navigazione efficace all’interno delle tabelle.

L’operatore ha la possibilità di modificare la modalità di esecuzione di Home Page Reader così da spostarsi agevolmente tra paragrafi, oppure tra link, intestazioni e frame.

Il costo di Ibm Home Page Reader si aggira intorno ai 170 euro.

E’ da segnalare anche Connect Outloud di Freedom Scientific, che è sostanzialmente
una versione limitata di Jaws in grado di gestire solamente Internet Explorer e Outlook Express per la posta elettronica. Il suo funzionamento è identico al funzionamento dello screen reader nelle pagine web, ma ovviamente il suo costo è inferiore (intorno ai 350 euro).

Va comunque detto che questi programmi dedicati sono poco diffusi, in quanto chi acquista un
computer vuole usarlo in tutti i suoi aspetti, quindi preferisce acquistare
uno screen reader piuttosto che singoli programmi dedicati a funzioni
particolari.

Funzionamento

Per chi non può vedere il monitor, una grossa difficoltà è data dal non avere una panoramica del contenuto della pagina: può solo cominciare a leggerne il contenuto con lo screen reader, saltare tra le intestazioni o selezionare un link tra quelli presentati.

L’università di Wisconsin-Madison ha realizzato due video in cui questo concetto è stato ben espresso e dove potete trovare diversi suggerimenti su come realizzare pagine accessibili, oltre ad un’ottima introduzione al funzionamento degli screen reader.

E’ comunque impensabile che lo screen reader o i browser vocali leggano proprio tutto quello che appare sullo schermo.

Funzionamento generale di uno screen reader

Lo screen reader dispone di meccanismi che selezionano di volta in volta quale testo vocalizzare. Se ad esempio si apre il menu Start, lo screen
reader
legge la prima voce del menu. Se ci si sposta con i tasti freccia, la
sintesi leggerà le varie voci del menu e darà informazioni aggiuntive, ad
esempio indicando se una determinata voce ha un sottomenu.

Lo screen reader fornisce anche messaggi che aiutano ad orientarsi, ad es. avverte se si è aperta una finestra di dialogo, se si è chiuso un menu, ecc. In una finestra di dialogo dà informazioni sui diversi elementi (ad esempio indica se
ci troviamo su un pulsante, su una lista di elementi, su un campo
editazione, ecc.).

Lo screen reader rende disponibile un sistema di emulazione del mouse, cioè consente
di spostare il puntatore del mouse mediante le frecce e di simulare il click
sinistro e destro. Inoltre è possibile esplorare lo schermo, cioè leggere lo
schermo dall’alto verso il basso senza influire né sulla posizione del
cursore del computer, che del resto spesso non si può spostare liberamente
sullo schermo, né sulla posizione del mouse.

Durante l’esplorazione dello
schermo con o senza spostamento del puntatore del mouse, lo screen reader
legge qualsiasi testo che incontra, ma ovviamente non è in grado di
interpretare le icone o di leggere il testo presente al loro interno sotto
forma di immagine
.

Per questo motivo, nel realizzare una pagina web, è importante utilizzare tutti i tag a disposizione per facilitare la lettura da parte di uno screen reader.

In questo caso particolare può essere impiegato l’attributo alt e assegnarli una descrizione breve ma completa dell’immagine che lo contiene. Vedremo nella parte pratica del corso come e quando utilizzare questo attributo. Se invece l’attributo non è presente lo screen reader indica semplicemente la presenza di un elemento grafico. E’ possibile assegnare a questo elemento grafico
un nome che verrà letto ogni volta che lo si incontrerà di nuovo.

Funzionamento con le pagine web

Inizialmente gli screen reader si
limitavano a leggere in maniera sequenziale dall’alto verso il basso e da
sinistra verso destra il testo che appariva sullo schermo. Purtroppo le
pagine web sono particolarmente complesse e così spesso il testo è disposto su più
colonne affiancate, vi sono elementi grafici e animazioni, così la
navigazione risultava assai difficile.

Oggi gli screen reader entrano in una particolare modalità quando si accorgono che è in esecuzione un browser e tentano di interpretare la struttura della pagina attualmente visualizzata.

In particolare, con l’introduzione di Internet Explorer 5, Microsoft ha fornito una libreria (Msaa) contenente una serie di funzioni cui gli screen reader possono appoggiarsi per presentare le pagine web in maniera alternativa.

Jaws e Window-Eyes hanno
sviluppato un sistema che di fatto consente di scorrere le pagine web con i
tasti freccia come se ci si trovasse in un word processor. Le pagine vengono
decolonnizzate (o linearizzate), cosicché il testo viene letto secondo un ordine logico
.

Vengono descritti i principali elementi: in presenza di un link lo
screen reader dirà “link” seguito dal testo che lo contraddistingue.

Tutto ciò spiega perché il 90% dei ciechi utilizza Internet Explorer e come
screen reader Jaws o Window-Eyes.

Normalmente, quando una pagina web viene caricata lo screen reader inizia
automaticamente a leggerla.

Jaws dà anzitutto una informazione sul numero di
frame e di link presenti sulla pagina, quindi legge il titolo della pagina,
prelevandolo dal tag title della sezione head del file Html. Window-Eyes legge invece solo il titolo.

Se scendendo con la freccia giù si incontra una
immagine, lo screen reader dirà “grafico” seguito dalla descrizione
alternativa che appare nell’attributo alt dell’elemento img.

Se l’attributo alt non è presente o è vuoto, viene letto il nome del file contenente l’immagine.

Se l’immagine rappresenta un link, lo screen reader dirà “link grafico” seguito
dal testo descrittivo. In mancanza di tale testo, lo screen reader può
comportarsi in modo diverso: può leggere il nome del file contenente
l’immagine oppure può leggere l’Url ad essa associato, o ancora può leggere
il contenuto del tag title. Lo stesso accade con le mappe immagine.

Jaws e Window-Eyes informano anche sulla presenza di tabelle, indicando il numero
di colonne e di righe.

Le tabelle vengono decolonnizzate, cioè vengono lette
una cella dopo l’altra. Ci sono dei comandi che consentono di muoversi
all’interno delle tabelle, ad esempio spostandosi di cella in cella in senso
verticale.

Se per i titoli viene usato il tag th, lo screen reader è in
grado di identificare la cella corrispondente come titolo e di leggerlo a
richiesta dell’utente.

Lo screen reader legge automaticamente il testo
contenuto nell’attributo summary prima di iniziare la lettura dei dati contenuti
nella tabella.

Ultimamente Jaws e Window-Eyes annunciano anche le intestazioni (tag da h1 a
h6) e consentono di spostarsi rapidamente tra le sezioni identificate dalle
intestazioni.

Nelle pagine web ci si può sempre spostare tra i link con il tasto Tab.
Tuttavia questo non risulta molto agevole se sulla pagina ci sono decine o
centinaia di link. Perciò tutti gli screen reader e i browser vocali prevedono una funzione che
fa apparire sullo schermo l’elenco di tutti i link, che può essere scorso
con le frecce. I link si attiveranno premendo Invio su quello desiderato.

L'elenco di tutti i link della pagina con Ibm Home Page Reader

Per questo motivo è importante che il testo associato ad ogni link sia
significativo e non si limiti a cose del tipo “clicca qui”, che lette al di
fuori del contesto non hanno alcun significato.

Poiché Jaws e Window-Eyes utilizzano i tasti freccia per muoversi
all’interno della pagina web, hanno dovuto introdurre una modalità
particolare per la compilazione dei form. In Jaws tale modalità si chiama
“Modalità Maschere” e si attiva premendo Invio all’interno di un campo
editazione o di un altro elemento del form che non sia un pulsante.

In questa modalità lo screen reader cerca di individuare il testo associato ad
ogni controllo (ad es. il testo che indica cosa bisogna inserire in un
determinato campo editazione). Per fare ciò si basa sul tag
label oppure sull’attributo name dell’elemento input. Se tali elementi non sono
presenti o non sono univoci, lo
screen reader può leggere informazioni
sbagliate o non leggere assolutamente nulla. Lo stesso accade se il testo
che indica il dato da immettere è costituito da una immagine.

Jaws e Window-Eyes sono anche in grado di annunciare automaticamente
l’inizio e la fine dei frame, leggendone anche il titolo. Per questo motivo
il titolo dei frame deve essere autoesplicativo e non limitarsi a
cose del tipo “leftframe” o “superiore”.

Per quanto riguarda i tasti di accesso rapido (tag acceskey), Jaws e
Window-Eyes li annunciano automaticamente.

Limiti e peculiarità

Quella delle tecnologie accessibili è una corsa ad inseguimento: la tecnologia corre e gli sviluppatori dei software di sintesi vocale le corrono dietro. Non si fa in tempo a raggiungere un
traguardo che già la tecnologia pone nuove sfide.

E’ stato così per Windows
(solo nel 1995 sono usciti i primi programmi che consentivano di accedere
all’interfaccia grafica in maniera decente), è stato così con la
trasformazione del web da elemento prevalentemente testuale e statico ad
elemento prevalentemente grafico e dinamico. Quando finalmente siamo
riusciti a leggere quasi tutte le pagine web grazie alle nuove funzioni
offerte da Internet Explorer 5 ed all’adozione del cosiddetto cursore Pc
virtuale, è arrivato Flash, assolutamente inaccessibile per il modo in
cui era concepito.

Gli screen reader sono forniti con una serie di file di configurazione che consentono di personalizzare il comportamento del software con i diversi applicativi disponibili. Anche se è presente un editor per aggiungere o personalizzare questi file, è comunque necessario mantenere la versione dello screen reader il più aggiornata possibile.

L'editor di script di Jaws

C’è ancora molta strada da fare per realizzare dei software realmente completi.

Attualmente gli screen reader non sono ad esempio in grado di selezionare
automaticamente la lingua sulla base del tag lang, sebbene questa sia una
delle raccomandazioni contenute nelle “User Agent Accessibility Guidelines
del W3c.

Solo Home Page Reader di Ibm è in grado di rilevare automaticamente il cambio di lingua, anche se questo ha come conseguenza il cambio di interprete ed introduce una pausa durante la lettura del testo.

Rilevamento automatico è un'opzione possibile con Ibm Home Page Reader

Jaws può anche non ripetere la lettura delle parti di una pagina che rimangono invariate. È una caratteristica molto interessante, soprattutto considerando che è impossibile per uno screen reader offrire all’operatore una panoramica del contenuto nella pagina: non può che iniziare la lettura dall’inizio.

Le opzioni Html di Jaws, tra cui spicca la possibilità di ignorare il contenuto ripetuto su più pagine

Questa opzione non sostituisce comunque la necessità per lo sviluppatore di prevedere un link che salti al contenuto della pagina. Anche se di solito Jaws riesce a
saltare le parti ripetute presenti sulle pagine web, basta che
cambi anche un solo carattere perché rilegga tutta la pagina. Per questo
motivo spesso la cosa non funziona: basti pensare alle pagine nelle quali cambia
solamente il banner pubblicitario posto all’inizio della pagina. Jaws
inizia a leggere dal punto in cui secondo lui il contenuto è diverso
rispetto a quello della pagina precedente.

Inoltre lo screen reader non è in grado di leggere il testo
associato ad eventi scatenati dal mouse, tipicamente l’attributo mouseover.

Attualmente risultano inutilizzabili sia le applicazioni Java presenti nelle
pagine web sia le animazioni Flash contenenti link. Peraltro sia Sun che
Macromedia sono impegnate nello sviluppo di plug-in che consentano agli
screen reader di “vedere” anche queste porzioni del web. Tuttavia è
necessario che gli sviluppatori predispongano le applicazioni Java e le
animazioni Flash seguendo determinati parametri illustrati nelle pagine
relative all’accessibilità di Macromedia e Sun.

La prossima versione di Jaws

È oggi disponibile la versione 4.50 di Jaws in inglese, mentre l’uscita della versione italiana è prevista entro la fine dell’anno.

Questa versione ha alcune novità, in particolare i tasti di navigazione
rapida (ad es. premendo la lettera t si passa alla tabella successiva), una
funzione che consente di ottenere una descrizione dettagliata di ogni
singolo tag Html e della sua posizione nella gerarchia della pagina, e
il supporto per le animazioni Flash.

Proprio Flash può far sì che Jaws riprenda a leggere il testo della pagina, in quanto giustamente
ritiene che il contenuto sia cambiato. Peccato che spesso il contenuto
delle animazioni Flash sia puramente grafico. Comunque nella finestra di
dialogo Regola prolissità di Jaws (Insert+V) è possibile agire sulle
opzioni “Refresh active” e “Refresh page” per evitare la rilettura automatica
della pagina.

In particolare la funzione “Refresh page” risolve un annoso
problema: quello dei siti con refresh automatico a tempo. Spesso il cieco
non fa in tempo ad esplorare la pagina che scatta il meccanismo di refresh
e Jaws ricomincia a leggere la pagina dall’inizio. Ciò accade anche se il
refresh riguarda un frame contenuto nella pagina.

L’aderenza agli standard di screen reader e browser vocali

di Jean-Marie D’Amour e Catherine Roy

Questo articolo è una traduzione dello studio “How Assistive Software Supports Web Accessibility” presentato il 20 Marzo 2002 alla 17a conferenza internazionale “Technology and Persons with Disabilities” di Los Angeles, California

Riferimento

Il W3c, con il Wai, ha pubblicato le Web Content
Accessibility Guidelines
1.0
e le Techniques for Web Content
Accessibility Guidelines
1.0
. Si tratta di 14 linee guida e di 65 punti cardine. Questi punti si riferiscono a loro volta a 85 diverse tecniche. Tutti questi elementi rappresentano le specifiche alle quali gli sviluppatori sono tenuti ad aderire.

Anche se vengono seguite queste regole, gli screen reader non garantiscono però che i contenuti siano accessibili per i loro utenti. Immagini complessse come i diagrammi e i grafici, ad esempio, richiedono la presenza di una descrizione di dettaglio inserita utilizzando l’attributo longdesc, ma solo le versioni più recenti di Jaws e Home Page Reader di Ibm (un browser vocale), danno accesso a questa informazione.
Come risultato, gli sviluppatori web devono non solo utilizzare l’attributo longdesc, ma aggiungere un D-Link come soluzione alternativa.

Gli esperti di accessibilità e gli sviluppatori web si sono posti svariate domande per capire come rendere i loro siti accessibili, riguardanti soprattutto il modo con cui questi software si comportano con le informazioni accessibili incluse nelle pagine.
Il risultato è che chi crea i contenuti è poco motivato dall’inserire tag e attributi che sono a fatica riconosciute da questi strumenti. Ma anche quando gli screen reader sono in grado di interpretare queste informazioni correttamente, gli sviluppatori vogliono capire il reale risultato che verrà presentato all’utente, così da poter rifinire i loro metodi per ottenere l’effetto voluto.

Il caso precedente non è sfortunatamente isolato. Abbiamo così condotto questo studio comparativo, che riguarda diversi screen reader e browser vocali, per verificare fino a che punto questi strumenti aderiscono alle linee guida Wai e per spiegare come le informazioni accessibili sono o non sono trattate prima di essere trasmesse agli utenti.

Il nostro studio cerca di rispondere a queste domande e può diventare un utile strumento di riferimento per chi si occupa di accessibilità web. La nostra valutazione suggerisce alcuni consigli agli sviluppatori di screen reader per consentirgli di migliorare il supporto all’accessibilità web di questi strumenti. Per raggiungere questo obiettivo è però necessario che gli sviluppatori web e gli sviluppatori di screen reader lavorino insieme.

Metodologia

Questo studio comparativo prende in esame le versioni più recenti dei seguenti software

Volevamo includere anche Outspoken 3.0 di Alva Access Group e
Hal 5.0 di Dolphin Computer
Access
ma, dopo una sommaria valutazione, abbiamo stabilito che sono troppo distanti dagli altri software perché fosse pertinente includerli in questo studio.

Presentiamo inoltre i risultati anche per 2 versioni precedenti di Jaws, dal momento che questo prodotto è largamente usato e molti utenti continuano a lavorare con le versioni precedenti perché non possono permettersi il costo di aggiornamento.

Partendo dalle 85 tecniche raccomandate dal Wai, ne abbiamo evidenziate 41 che riteniamo necessarie per garantire l’accessibilità delle pagine e che riguardano in particolare gli screen reader o i software vocali. Abbiamo raggruppato questi elementi in 6 categorie:

  • Controllo degli elementi strutturali
  • Corrispettivi di testo
  • Accesso tramite tastiera
  • Descrizione e navigazione dei form
  • Descrizione e navigazione delle tabelle
  • Descrizione e navigazione dei frame

Sei di questi elementi sono legati all’accessibilità, ma non sono esplicitamente inclusi dalle tecniche Wai o non gli vengono chiaramente assegnate delle priorità:

  • Riconoscimento automatico della lingua principale
  • Attributo title per le immagini e i pulsanti
  • Link alla stessa pagina
  • Attributo title del tag object
  • Tabulazione sugli anchor che non sono link
  • Nome dei frame

Risultati

Il nostro studio comparativo ha evidenziato che Home Page Reader 3.02 e Jaws 4.0.2 sono praticamente testa a testa. Home Page Reader aveva un considerevole vantaggio fino al rilascio dell’ultima versione di Jaws, che ha subito miglioramenti significativi. E’ una buona notizia per gli utenti di questo screen reader considerando la posizione dominante che ricopre sul mercato.

Ecco i risultati:

Riassunto Window Eyes 4.2 Jaws 3.5 Jaws 3.71 Jaws 4.02 Hpr 3.02 Totale
Controllo degli elementi strutturali 0 1 1 2 6 9
Corrispettivi di testo 5 6 6 8 7 9
Accesso tramite tastiera 1,5 1 1 2,5 0,5 5
Descrizione e navigazione dei form 5 5 5 6 5,5 6
Descrizione e navigazione delle tabelle 3 5 5 6 8 9
Descrizione e navigazione dei form dei frame 0 0 1 2 0 3
Totale 14,5 18 19 26,5 27 41
Percentuale 35% 44% 46% 65% 66%  

Se consideriamo i livelli di priorità Wai otteniamo praticamente gli stessi risultati, tranne che la differenza tra il migliore (Ibm Home Page Reader) e gli altri è ancora più marcata.

Riassunto ponderato per priorità Window Eyes 4.2 Jaws 3.5 Jaws 3.71 Jaws 4.02 Hpr 3.02 Total
Controllo degli elementi strutturali 0 2 2 4 11 16
Corrispettivi di testo 13 16 16 18 17 21
Accesso tramite tastiera 2 1 1 3 1 6
Descrizione e navigazione dei form 10 10 10 12 11 12
Descrizione e navigazione delle tabelle 7 11 11 14 17 20
Descrizione e navigazione dei frame 0 0 1 3 0 6
Totale 32 40 41 54 57 81
Percentuali 40% 49% 51% 67% 70%  

Analisi

Analizziamo ora brevemente ogni categoria

Controllo degli elementi strutturali

Controllo degli elementi strutturali Livello di priorità Window Eyes 4.2 Jaws 3.5 Jaws 3.71 Jaws 4.02 Hpr 3.02 Totale
Heading (h1h6) 2 no no no  
Liste ordinate e non (li) 2 no no no no  
Liste nidificate 2 no no no no no  
Abbreviazioni (abbr) e acronimi (acronym) con l’attributo title 3 no no no no no  
Citazioni (q e blockquote) 2 no no no no no  
Cambio della lingua 1 no no no no  
Riconoscimento lingua principale 3 no no no no  
Riconoscimento automatico lingua principale Ncc (vedi nota 1) no no no no  
Popup 2 no  
Totale   0 1 1 2 6 9
Ponderato per priorità   0 2 2 4 11 16

Nota 1: Non chiaramente classificato dal Wai

Gli elementi strutturali includono gli heading (h1h6), le liste e le liste nidificate. Sono tutte informazioni essenziali per comprendere appieno il significato di un documento. Gli heading consentono ai ciechi, che normalmente accedono al documento in modo sequenziale, di esplorarlo così da compensare l’incapacità di ricavarne una panoramica complessiva.

Solo Hpr 3.02 e Jaws 4.02 indicano gli header con un segnale sonoro o un avvertimento. Hpr 3.02 e Jaws 4.02 consentono inoltre la navigazione del documento procedendo tra gli heading.

Solo Hpr indica il numero di liste ordinate e consente di aggiungere un testo di avvertimento per ogni elemento appartenente ad una lista non ordinata. Ma non permette di distinguere il livello di indentatura delle liste nidificate.

La lingua principale e i cambiamenti della lingua rappresentano informazioni importanti per gli utilizzatori dei sintetizzatori vocali. Gli screen reader non rendono facile questo compito poiché richiedono un intervento manuale per modificare la lingua. I sintetizzatori vocali rendono disponibili diverse lingua che l’utente può selezionare.

Home Page Reader è l’unico strumento che riconosce i cambiamenti di lingua (inseriti dagli sviluppatori utilizzando l’attributo lang) e che cambia il motore del sintetizzatore al volo. E’ anche in grado di riconoscere automaticamente la lingua principale del documento, anche se l’attributo lang è assente.

Per quanto riguarda gli altri prodotti, il cambiamento della lingua è totalmente a carico dell’utente.

Il riconoscimento delle citazioni così come il significato degli acronimi e delle abbreviazioni sono elementi previsti dalle linee guida del Wai e classificati rispettivamente alle priorità 2 e 3.

Nessuno dei prodotti valutati dà questo tipo di informazione agli utenti.

Le finestre di popup infastidiscono molti utenti, ma questo non impedisce agli sviluppatori di usarle e a volte di abusarne. Questi popup disorientano le persone che non li possono vedere perché compaiono improvvisamente e li portano in una nuova finestra senza che lo sappiano. Il Wai consiglia di avvisare gli utenti quando un link si apre in una nuova finestra.

Le ultime 3 versioni di Jaws dicono “Nuova finestra del browser” ogni volta che compare una finestra di popup.

Home Page Reader 3.02 suona un veloce jingle ogni volta che viene aperta una nuova finestra.

Corrispettivi di testo

Corrispettivi di testo Livello di priorità Window Eyes 4.2 Jaws 3.5 Jaws 3.71 Jaws 4.02 Hpr 3.02 Totale
Testo alt per immagini e pulsanti 1  
Attributo title per immagini e pulsanti Ncc  
Attributo longdesc per immagini complesse 1 no no no   
Testo alt per i tag area delle image map 1  
Link di testo 1  
Link alla stessa pagina Ncc no no no no  
Attributo title del tag object Ncc no no no  
Testo descrittivo per l’attributo object 1  
Testo descrittivo per le applet 1 no no no  
Totale   5 6 6 8 7 9
Ponderato per priorità   13 16 16 18 17 21

I corrispettivi di testo sono un modo per fornire informazioni sul contenuto degli elementi grafici. Questo tipo di informazioni sono essenziali per i ciechi. Le Html 4.01 Specification prevedono anche la possibilità di utilizzare l’attributo title come “informazione aggiuntiva per l’elemento che lo utilizza”

Windows Eyes e Jaws confondono alt e title e danno sempre la precedenza all’attributo title quando sono entrambi presenti. Jaws, prima della versione 4.02, applica questa logica anche ai link di tipo testo. L’attributo title è un’informazione integrativa mentre l’attributo alt è l’unico modo di offrire un equivalente di testo a un elemento visivo.

Home Page Reader legge l’attributo alt ma non il title. La soluzione ideale sarebbe di avere normalmente accesso all’attributo alt e di accedere al title come complemento.

Solo Jaws 4.02 indica se il link porta da qualche altra parte nella stessa pagina, un’informazione importante anche se non viene menzionata nelle linee guida Wai.

Tutti i prodotti trattano gli attributi alt senza valore (ad esempio alt=”” e alt= ” “) come se fossero immagini senza attributi alt. La funzione degli attributi alt vuoti è di eliminare i riferimenti ad un’immagine che è puramente decorativa e perciò non importante. Questi software dovrebbero aggiungere una categoria prima di “tutte le immagini” che potrebbe essere chiamata “tutte le immagini senza alt text”.

Infine, va notato che Home Page Reader e Jaws 4.02 supportano l’attributo longdesc, il cui scopo è fornire un link ad una pagina descrittiva nel caso di elementi visivi complessi.

Il testo descrittivo per il tag object è gestito correttamente da tutti i prodotti, mentre quello per le applet è supportato solo da Jaws 3.5 e 3.7.1. La versione 4.02 non dispone più di questa caratteristica.

Accesso tramite tastiera

Accesso tramite tastiera Livello di priorità Window Eyes 4.2 Jaws 3.5 Jaws 3.71 Jaws 4.02 Hpr 3.02 Totale
Ordine di tabulazione (tabindex) per i link 3 no no no no no  
Ordine di tabulazione (tabindex) per i form 3 no  
Accesskey 3 no no no no  
Tabulazione sugli anchor che non sono link Ncc no no no no no  
Script e Dhtml 2 parziale no no parziale parziale  
Totale   1.5 1 1 2.5 0.5 5
Ponderato per priorità   2 1 1 3 1 6

L’Html 4.01 consente agli sviluppatori di definire l’ordine di tabulazione all’interno di un documento. Questa operazione può essere cruciale per alcuni tipi di menù dinamici o effetti Javascript che reagiscono agli eventi da tastiera, come suggerito dal Wai. E’ inoltre usato dai form per assicurare un percorso logico di navigazione se si usa la tastiera.

Window Eyes e Jaws interpretano l’ordine di tabulazione, ma solo Jaws 4.02 indica l’attributo accesskey.

Solo Windows Eyes rispetta l’ordine di Internet Explorer per gli anchor che non sono link.

Tutte le versioni recenti dei prodotti in esame gestiscono parzialmente gli eventi in JavaScript e gli effetti Dhtml che modificano la visibilità degli elementi. Il supporto è però ancora rudimentale e funziona solo in particolari situazioni.

Descrizione e navigazione dei form

Descrizione e navigazione dei form Livello di priorità Window Eyes 4.2 Jaws 3.5 Jaws 3.71 Jaws 4.02 Hpr 3.02 Totale
Raggruppare e descrivere il campo con fieldset e legend 2 no no no parziale (vedi nota 2)
Associazione tra i campi e le etichette (label) con l’attributo for 2  
Campi di testo 2  
Combo Box 2  
Radio button 2  
Pulsanti 2  
Totale   5 5 5 6 5,5 6
Ponderati per priorità   10 10 10 12 11 12

Nota 2 : Legge il tag legend solo quando l’etichetta segue il controllo

I form sono elementi cruciali per le operazioni di ricerca e di e-commerce.

Tutti i prodotti sottoposti al test supportano i controlli per i form. Solo Jaws 4.02 fornisce però informazioni riguardanti i gruppi di elementi e i contenuti del tag legend. Sono informazioni spesso essenziali per compilare correttamente i form.

Descrizione e navigazione delle tabelle

Descrizione e navigazione delle tabelle Livello di priorità Window Eyes 4.2 Jaws 3.5 Jaws 3.71 Jaws 4.02 Hpr 3.02 Totale
Abbreviazioni per le intestazioni 3 no no no no  
Tag caption 3  
Attributo summary 3 no  
Attributo scope 1 no  
Intestazioni 1 no  
Attributo axis 1 no no  
Celle vuote 1 no no  
Celle unite 1 no no no  
thead, tfoot, tbody 2 no no no no  
Totale   3 5 5 6 8 9
Ponderato per priorità   7 11 11 14 17 20

Leggere una tabella di dati è una situazione molto complessa per i non vedenti. Chi vede la tabella può farsi una veloce idea del modo in cui i dati sono organizzati. Un cieco invece si affida ad un riassunto per avere un’idea generale del contenuto. Identificare le celle che fanno da intestazione e le loro relazioni con le celle che contengono i dati è fondamentale per la navigazione e la compresione del contenuto.

Home Page Reader è il miglior strumento per navigare complesse tabelle di dati, mentre il peggiore è Windows Eyes. Jaws 4.02 ha fatto dei progressi se lo paragoniamo alle versioni precedente, soprattutto per quel che riguarda le celle vuote, ma sarebbe interessante se trattasse le celle unite con la stessa logica di Home Page Reader.

Descrizione e navigazione dei frame

Descrizione e navigazione dei frame Livello di priorità Window Eyes 4.2 Jaws 3.5 Jaws 3.71 Jaws 4.02 Hpr 3.02 Totale
Titolo dei frame (title) 1 no no no no no  
Nome dei frame (name) Ncc no no no  
longdesc 2 no no no no  
Totale   0 0 1 2 0 3
Ponderato per priorità   0 0 1 3 0 6

I frame hanno perso di popolarità, anche se sono ancora usati in parecchi siti. Il Wai suggerisce di assegnare un titolo significativo ad ogni frame per indicarne la funzione e di inserire un attributo longdesc per illustrare come i frame interagiscono tra loro (se il titolo non è sufficientemente esplicativo).

Solo Jaws 4.02 ha un buon supporto per i frame, che sarebbe ancora migliore se leggesse l’attributo title invece di name, come suggerito dal Wai.

Conclusioni

L’accessibilità web interessa sia chi realizza i contenuti, sia chi sviluppa i software in aiuto alle persone disabili. Se entrambi fanno la loro parte il web sarà un posto migliore per tutti.

Questo test evidenzia i significativi miglioramenti di Jaws 4.02, che lo pone alla stregua di Ibm Home Page Reader.

Questo studio ha già prodotto dei risultati perché ha stimolato lo spirito competitivo dei progettisti di Jaws nel voler superare Home Page Reader di Ibm. Se i due gruppi traggono spunto dai punti di forza dell’avversario e riescono a rilasciare una versione migliorata dei loro prodotti, avremmo contribuito a garantire un web più usabile ed accessibile.