Archivi tag: Accessibilità

Screen reader, display braille e browser vocali

Pubblicato il da

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

Pubblicato il da

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 (h1–h6) 2 no no no sì sì  
Liste ordinate e non (li) 2 no no no no sì  
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 sì  
Riconoscimento lingua principale 3 no no no no sì  
Riconoscimento automatico lingua principale Ncc (vedi nota 1) no no no no sì  
Popup 2 no sì sì sì sì  
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 (h1–h6), 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 sì sì sì sì sì  
Attributo title per immagini e pulsanti Ncc sì sì sì sì sì  
Attributo longdesc per immagini complesse 1 no no no sì sì   
Testo alt per i tag area delle image map 1 sì sì sì sì sì  
Link di testo 1 sì sì sì sì sì  
Link alla stessa pagina Ncc no no no sì no  
Attributo title del tag object Ncc no no no sì sì  
Testo descrittivo per l’attributo object 1 sì sì sì sì sì  
Testo descrittivo per le applet 1 no sì sì 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 sì sì sì sì no  
Accesskey 3 no no no sì 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 sì parziale (vedi nota 2)
Associazione tra i campi e le etichette (label) con l’attributo for 2 sì sì sì sì sì  
Campi di testo 2 sì sì sì sì sì  
Combo Box 2 sì sì sì sì sì  
Radio button 2 sì sì sì sì sì  
Pulsanti 2 sì sì sì sì sì  
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 sì  
Tag caption 3 sì sì sì sì sì  
Attributo summary 3 no sì sì sì sì  
Attributo scope 1 no sì sì sì sì  
Intestazioni 1 no sì sì sì sì  
Attributo axis 1 no sì sì sì no  
Celle vuote 1 sì no no sì sì  
Celle unite 1 sì no no no sì  
thead, tfoot, tbody 2 no no no no sì  
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 sì sì no  
longdesc 2 no no no sì 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.

Un Web Accessibile a Tutti – Intervista a Joe Clark

Pubblicato il da
  1. Ci parli di lei [Risposta 1]
  2. Quali sono gli argomenti trattati nel vostro libro “Building Accessible Websites“? [Risposta 2]
  3. Che cosa è l’accessibilità Web e perché è così importante nella costruzione di un sito? Quali fasi del ciclo di vita di un sito hanno a che fare con l’accessibilità? [Risposta 3]
  4. L’accessibilità web è utile solo alle persone disabili? [Risposta 4]
  5. In cosa differisce l’accessibilità web dalla usabilità web? [Risposta 5]
  6. Le specifiche Wai sono a volte difficili da applicare. Le pagine di un sito devono “degradare gentilmente”, ma allo stesso tempo è meglio usare i Css anche per il layout. Le due tecniche sembrano agli antipodi. È davvero possibile costruire un sito seguendo queste specifiche così restrittive? [Risposta 6]
  7. Cosa dire dei browser: Internet Explorer 6 e Netscape 6 interpretano correttamente i tag Html rivolti all’accessibilità? [Risposta 7]
  8. A parte il sito Wai, ci sono altre risorse online che ci potrebbe consigliare? [Risposta 8]

Ci parli di lei

Sono un giornalista [nuova finestra] e consulente di accessibilità [nuova finestra] a Toronto. Svolgo questo lavoro praticamente da 20 anni. Ho pubblicato circa 400 articoli su riviste e giornali e sto per pubblicare un libro, Building Accessible Websites [nuova finestra]. Mi occupo di consulenza su temi di accessibilità per un piccolo numero di clienti (soprattutto per la televisione e il cinema).

Top

Quali sono gli argomenti trattati nel vostro libro “Building Accessible Websites“?

Piuttosto che il solito manuale di programmazione, il libro è una chiara spiegazione di cosa sia l’accessibilità Web e delle regole per progettare siti accessibili.

Alcuni degli argomenti riguardano:

  • L’accesso alle informazioni e le leggi
  • Una breve spiegazione di come le persone disabili usano i computer
  • Multimedia
  • La navigazione
  • Tabelle e frame
  • Il testo e i link
  • La struttura della pagina
  • Le immagini
  • Come creare pagine accessibili fin dall’inizio

Top

Che cosa è l’accessibilità Web e perché è così importante nella costruzione di un sito? Quali fasi del ciclo di vita di un sito hanno a che fare con l’accessibilità?

In generale l’accessibilità viene incontro alle situazioni e difficoltà invariabili di alcune persone. Una persona con problemi alla vista continua ad averli anche quando visita un sito, tanto per fare l’esempio più comune.

Il Web non è un mezzo universale. Non è come la stampa: economica e disponibile senza troppe difficoltà. C’è un certo grado di elitarismo nel Web: c’è bisogno di un computer e di una connessione ad Internet, elementi con un certo costo. Allora perché l’accessibilità Web è importante? Perché non si vuole essere elitari inutilmente. Non bisogna impedire l’accesso ai siti per cause che queste persone non possono cambiare.

Oltre a questo, l’accessibilità è sempre più richiesta dalle norme di legge [nuova finestra]. Non ci sono decreti nati appositamente per l’accessibilità Web, ma ci sono dimostrazioni di quanto le leggi attualmente in vigore siano state applicate all’accessibilità Web.

Una persona non vedente, Bruce Maguire, ha vinto un caso [nuova finestra] contro le Sydney Olympics del 2000; ha sostenuto che il loro sito Web era per lui inaccessibile (Bruce legge il testo Web con un visualizzatore Braille e un lettore vocale), e le autorità australiane gli diedero ragione, richiedendo al comitato olimpico l’adeguamento del sito e il pagamento di una multa. (Non hanno mai aggiornato il sito, che si sarebbe potuto progettare nel modo corretto fin da subito, ma pagarono la multa).

Il decreto “Americans with Disabilities Act“ [nuova finestra] si applica senza equivoci anche al Web. Lo stesso dicasi per il “Disability Discrimination Act“ [nuova finestra] nel Regno Unito, e anche per tutte le forme legislative che proibiscono un trattamento non equo, ma sfavorevole nei confronti delle persone disabili. Inoltre, i servizi e i siti realizzati da chi lavora per o nel governo federale degli Stati Uniti devono essere accessibili e rispettare i requisiti “Section 508“ [nuova finestra].

Meglio includere le politiche di accessibilità fin dall’inizio. È generalmente semplice realizzare un sito accessibile partendo da zero e molto noioso e spiacevole ritornare indietro e correggere errori in un secondo momento. Il mio libro, a dire il vero, spiega anche come migliorare un sito esistente, se questa è l’unica possibilità. Ci sono delle procedure che rendono il compito gestibile.

Top

L’accessibilità web è utile solo alle persone disabili?

In quasi tutti i casi, si. Personalmente sono stanco di sentire quei difensori dell’accessibilità che dicono “Se rendi il tuo sito accessibile, le persone potranno visualizzarlo con i loro Palm Pilot!”. Non vedo perché si debbano cercare delle giustificazioni al fatto che rendere un sito accessibile è utile soprattutto per rispondere alle esigenze delle persone disabili (più qualche altra esigenza, come i problemi di lingua, anche se non ne parlo molto nel libro).

In ogni caso un sito che si definisce accessibile non funzionerà bene su un Palm Pilot. Ci sono ancora troppi link (come le barre di navigazione) e troppo testo non pertinente perché valga la pena usarlo. Si è verificato il contrario con il caso Amazon [nuova finestra]. Amazon ha adattato il sito per i Pda e ha sostenuto che era fruibile anche con i software di sintesi vocale. Ma le cose non funzionano così.

Top

In cosa differisce l’accessibilità web dalla usabilità web?

L’interazione tra le due discipline sta diventando sempre più chiara.

Il problema principale è il seguente: se il tuo sito è immediatamente ed efficacemente utilizzabile da una persona non disabile, ma una persona disabile deve faticare per completare i suoi compiti e impiega il triplo del tempo, quanto accessibile è il tuo sito? Quanto è usabile?

Questo è riconducibile a due aree principali: la navigazione e le form.

I siti web “tipici” hanno troppi link da saltare. Questo non è solo un problema per le persone non vedenti che usano i sintetizzatori vocali, come invece tutti pensano. Un abile utilizzatore di sintetizzatori vocali può infatti evitare molto agevolmente i link, per esempio saltando completamente la barra sinistra di navigazione. Ma una persona con problemi motori potrebbe essere costretta a tabulare tra 80 o più link solo per posizionare il cursore sulla casella di ricerca. (E usare la tabulazione per navigare i link è in realtà il caso migliore e quello più veloce – alcuni metodi usati da persone con gravi problemi motori muovendo le mani e le braccia sono molto lenti).

I siti dovrebbero riordinarsi automaticamente così che gli elementi cruciali, come le caselle di ricerca o i più importanti livelli di navigazione siano in cima, mentre tutto il resto dovrebbe essere presentato di seguito secondo un ordine logico. Forse il protocollo CC/PP [nuova finestra] renderà un giorno tutto questo possibile. A dire il vero, ogni sito realizzato come insieme di moduli da un sistema di gestione dei contenuti potrebbe automaticamente riordinarsi in questo modo, ma nessuno si sta prendendo il disturbo di farlo. Non si prendono neppure la briga di riordinare gli elementi della pagina premendo un bottone invece che farlo automaticamente. Si stanno ancora studiano delle tecniche che risolvano questo problema.

Riguardo alle form, i miglioramenti per l’accessibilità sono molto semplici in Html. Le form sono già di per sé complicate da mettere insieme, così gli sviluppatori non hanno nessuna scusa per non includere i tag che migliorino l’accessibilità. Il problema è in realtà che i sintetizzatori vocali non sono stati aggiornati per usare queste caratteristiche (come <label> intorno al tag <input>). Potrebbe allora succedere che gli autori di contenuti abbiano svolto correttamente il loro lavoro, ma che la tecnologia per l’accessibilità non riesca ad interpretarlo. E i sintetizzatori vocali non sono per niente bravi nel leggere il testo, i bottoni, i radio button, i check box e i textarea e chiarire come tutti questi elementi siano collegati gli uni agli altri. È molto facile perdersi quando si compila una form online. Allora, se le persone non disabili possono usare la vostra form ma le persone disabili no, la vostra form è realmente usabile? (Anche in questo caso, rendere accessibili le form per persone con difficoltà motorie è molto difficile. Nessuno ha sviluppato un buon metodo per svolgere questo compito fino ad oggi).

Top

Le specifiche Wai sono a volte difficili da applicare. Le pagine di un sito devono “degradare gentilmente”, ma allo stesso tempo è meglio usare i Css anche per il layout. Le due tecniche sembrano agli antipodi. È davvero possibile costruire un sito seguendo queste specifiche così restrittive?

Le specifiche del Wai sono pessime, ma sono in fase di attenta revisione. Finalmente abbiamo una
title=”Wcag 2 Restructuring Proposal” target=”_blank”>bozza della versione 2.0 [nuova finestra] delle Web Content Accessibility Guidelines che è quasi decente. Siamo ancora lontani dal traguardo, ma rappresenterà un forte miglioramento. Al momento siamo ancora bloccati alla versione 1.0.

La frase “degradare gentilmente” è stata ampiamente fraintesa. Significa semplicemente che “le cose devono funzionare anche in condizioni che lo sviluppatore non ha potuto o saputo anticipare”. È facile da ottenere, soprattutto in siti che non usano elementi multimediali. Se si scrive Html valido e si usano gli elementi dell’Html nel modo consono (cioè, non si usa <p> per codificare un titolo), si è già a buon punto.

Non è “sicuramente meglio” usare i Css per il layout. È troppo difficile far sì che i layout creati con i Css funzionino consistentemente in tutti i browser; è molto più semplice usare le tabelle. Questo nel mondo reale, dal momento che chiunque abbia messo insieme più di qualche pagina ha usato le tabelle per il layout. I costruttori di sintetizzatori vocali hanno inoltre aggiornato il loro software per gestire le tabelle (con rare eccezioni). I Css, quando riuscite a farli funzionare, vanno bene; anche le tabelle vanno bene. Lo so che sembra esserci un’eresia, ma questa è la realtà. (Io uso Css e tabelle, e qualche volta nessuno dei due, per le circa 500 pagine che ho online. Non pretendo di essere un purista, ma nessun altro dovrebbe pretenderlo).

Top

Cosa dire dei browser: Internet Explorer 6 e Netscape 6 interpretano correttamente i tag Html rivolti all’accessibilità?

I browser sono solo mediocri quando si tratta di supporto all’accessibilità nell’Html.

Le ultime versioni di Mozilla [nuova finestra] gestiscono molte funzionalità correttamente. Sottolineano gli acronimi e le abbreviazioni con linee tratteggiate; vi danno l’accesso alle descrizioni lunghe (longdesc) delle immagini (ma non dei frame – nessun browser lo fa); gestiscono l’alt text per le immagini meglio di qualsiasi altro browser (visualizzano semplicemente il testo dell’alternate senza cornici o altri riferimenti grafici che non siano stati progettati per la pagina).

iCab [nuova finestra] ha un supporto molto buono: è l’unico browser che può leggere l’attributo summary di una <table>.

Il supporto per l’accessibilità di Internet Explorer [nuova finestra] è solo discreto. Dal momento che non sono visualizzate alcune funzionalità molto utili come le descrizioni lunghe, gli sviluppatori spesso non sanno neppure che è possibile aggiungerle all’Html.

Top

A parte il sito Wai, ci sono altre risorse online che ci potrebbe consigliare?

Gestisco il Web AccessiBlog [nuova finestra], un Weblog di link ad altri siti che trattano di accessibilità. Dovrei aggiornarlo più spesso (ho davvero bisogno di un sistema basato su database), ma so di sicuro che ha link a praticamente tutte le risorse attualmente disponibili in inglese (a volte anche in tedesco). C’è meno materiale disponibile su questo argomento di quello che potreste pensare.

Chiunque avesse domande relative all’accessibilità web dovrebbe iscriversi a WebAIM [nuova finestra] e alla mailing list del WAI-IG [nuova finestra]. O semplicemente chiedere a me.