Archivi categoria: Accessibilità

Accessibilità web, lo stato dell’arte per gli screen reader

Pubblicato il da

Questo articolo è un aggiornamento e approfondimento di Screen reader, display braille e browser vocali, pubblicato a fine Novembre 2002.

Screen reader

Gli screen reader stanno evolvendo enormemente, cercando di rispettare gli standard dettati dal W3C, in particolare le User Agent Accessibility Guidelines.

Oggi tutti gli screen reader in commercio riconoscono la lingua principale di una pagina web, sia che sia dichiarata nel tag HTML sia che sia dichiarata nel meta tag LANGUAGE. Nelle pagine scritte in XHTML vengono onorati i tag xml:lang e lang. Anche il tag SPAN LANG viene gestito in maniera appropriata.

Pertanto diventa importante definire correttamente sia la lingua principale della pagina sia, eventualmente, la lingua nativa di una espressione straniera. Naturalmente l’utente può sempre disattivare l’interpretazione di questi tag da parte dello screen reader. In questo caso la sintesi vocale leggerà il testo in lingua italiana così come appare scritto.

Anche i tag ACRONYM e ABBR vengono gestiti da tutti gli screen reader, ma normalmente la relativa funzione è disabilitata. Pertanto sarà l’utente a dover impostare il proprio screen reader affinché legga gli acronimi e le abbreviazioni per esteso anziché il testo che appare sullo schermo.

Attualmente gli screen reader venduti in Italia sono:

OutSpoken non è più in commercio già dal 2003.

Negli ultimi anni Hal ha colmato il divario che lo separava dagli altri due screen reader. Ora anche Hal consente di scorrere le pagine web come se si trattassero di normali documenti, utilizzando un cursore virtuale; annuncia e gestisce correttamente le tabelle; identifica il tag LABEL in modalità interattiva.

Display Braille

In questo settore le novità riguardano soprattutto i sistemi di collegamento del display al pc. Oggi in commercio si trovano molti display con connessione USB ed anche qualche display che sfrutta la tecnologia Bluetooth.

Compatibilità degli screen reader con i browser

Per molti anni i non vedenti sono stati costretti ad utilizzare Microsoft Internet Explorer, in quanto gli screen reader riuscivano ad interagire propriamente con le pagine web solo tramite la libreria MSAA utilizzata da questo browser. Ora, però, si aprono nuove possibilità.

La versione 7.0 di Jaws, infatti, è compatibile anche con Mozilla Firefox, il browser opensource che si sta ritagliando una cospicua fetta di mercato nel panorama dei browser alternativi a quello del monopolista Microsoft. Non è azzardato prevedere che in futuro anche gli altri screen reader riusciranno ad interagire con Firefox.

Internet in mobilità

L’accesso al web tramite dispositivi mobili (smartphone e pc palmari) non è più un argomento di discussione accademica. Anche per i non vedenti esistono soluzioni di accessibilità per questo tipo di dispositivi. In particolare Dolphin Computer Access ha sviluppato una versione di Hal per Pocket PC, non ancora distribuita in Italia, mentre Code Factory ha realizzato Mobile Speak, il primo screen reader per sistema operativo Windows Mobile venduto in Italia.

Il rispetto degli standard W3C e delle linee guida sull’accessibilità dovrebbero garantire la piena compatibilità dei siti web anche con questo tipo di dispositivi, che sicuramente avranno una certa diffusione tra i non vedenti, dato che comprendono anche funzioni tipiche di un telefono cellulare completamente accessibili.

Le nuove sfide

Come detto, ormai tutti gli screen reader sono in grado di gestire gli standard HTML e XHTML. Jaws riesce anche ad interagire con i fogli di stile per recuperare le informazioni relative al font ed al colore del testo, quando si utilizza l’apposito comando che fa pronunciare alla sintesi vocale tali informazioni.

Anche nel campo delle tecnologie non HTML legate al web, in particolare i formati Adobe PDF e Macromedia Flash, si è raggiunto un buon livello di accessibilità. Adobe e Macromedia, infatti, hanno pubblicato delle linee guida per rendere il materiale prodotto con i relativi strumenti di publishing accessibile agli screen reader. Purtroppo sono ancora pochi gli sviluppatori che conoscono e seguono queste linee guida, ma è probabile che in futuro vi sarà una maggiore sensibilità anche su questi aspetti.

La nuova sfida si chiama Ajax, un linguaggio che consente di creare effetti dinamici. Attualmente nessuno screen reader è in grado di interpretare questo tipo di codice. Il risultato è che tutte le funzioni gestite in questo modo vengono ignorate dallo screen reader. Per un non vedente è come se le parti di pagina web che utilizzano questa nuova tecnologia non esistessero (ne abbiamo già parlato in un articolo dedicato). Ancora una volta si ripropone il tema dell’inseguimento tra nuove soluzioni tecnologiche e strumenti assistivi.

In attesa che le case produttrici di screen reader trovino il modo di interagire con questi nuovi linguaggi, si consiglia di non farne un uso massiccio, ovvero di predisporre una interfaccia alternativa costruita utilizzando unicamente gli standard del W3C, come ha fatto ad es. Google per la sua webmail, peraltro solo nella versione americana.

Ajax e l’accessibilità dei siti web

Pubblicato il da

(Vedi anche Ajax e l’usabilità)

Di Ajax si parla ogni giorno e sono ormai decine i framework per sviluppare applicazioni basate su questo tipo di architettura.

Occupandomi da anni di sviluppo web non posso che esserne contento: finalmente i limiti di interfaccia di una pagina possono essere superati! Subito dopo mi sono però chiesto se sono tutte rose e fiori, se con Ajax ci sono solo risvolti positivi.

Pensiamo a un argomento delicato come quello dell’accessibilità web. Già è difficile riuscire a realizzare una semplice pagina Html accessibile, per non parlare di una pagina con immagini, video e audio. Cosa succede se cominciamo a impiegare massicciamente Javascript e Dhtml?

Ho pensato allora di farmi dare una mano da Nicola, visto che utilizza quotidianamente uno screen reader, sottoponendogli due esempi.

Il primo, più semplice, è Google Suggest. L’aspetto è quello della classica ricerca di Google, ma non appena si comincia a digitare qualcosa, appaiono dei suggerimenti pescati direttamente dal server. Ho espresso a Nicola il dubbio che il suo screen reader non fosse in grado di segnalargli la presenza di questi suggerimenti, dubbio che mi ha subito confermato.

Come era largamente prevedibile, Jaws non dà alcun riscontro della presenza di un’eventuale lista di suggerimenti nella pagina di ricerca di Google.

A questo punto sono passato all’opposto e ho scelto un sito che si basa interamente sull’architettura Ajax: il nuovo client web di Yahoo! Mail, in versione beta e utilizzabile quasi esclusivamente oltreoceano.

Graficamente e a livello di funzionalità si tratta di un prodotto stupefacente: sembra quasi impossibile utilizzare questo tipo di applicazione in un browser, tanto è simile a un vero client di posta. Ma, anche in questo caso, Nicola ha evidenziato dei seri problemi di accessibilità.

Per quanto riguarda la mail di Yahoo!, riesco a leggere la tabella contenente il sommario dei messaggi, ma nessuna voce viene vista da Jaws come un link. Mi pare di aver capito che, per leggere un messaggio, bisogna cliccare sull’oggetto. Questo con una manovra si può anche fare. Poi però rimane il problema di riuscire a leggere il messaggio. Mi sembra di aver capito che il testo del messaggio appare sotto alla tabella contenente l’elenco dei messaggi. Tuttavia Jaws legge solo il nome del mittente e quello del destinatario, poi per lui la pagina web finisce lì. Ancora una volta, ricorrendo all’emulazione del mouse, cioè al cosiddetto cursore Jaws, si riesce a raggiungere la zona sottostante e a cliccare. A questo punto si apre una nuova finestra, che Jaws legge normalmente. Conclusione: non accessibile.

Tutt’altro che un successo, quindi. In effetti quella di aver realizzato un vero client di posta dentro un browser è una mossa azzeccata a livello di immagine. Ma la soluzione migliore sarebbe stata probabilmente un’altra, come ad esempio costruire un’applet Java, sempre da presentare dentro un browser. Certo, un po’ pesante da scaricare la prima volta (comunque qualche tonnella di Javascript dovete pur digerirla con Ajax), ma se non altro, se ben sviluppata, completamente accessibile.

E non venitemi a dire che comunque Google può essere usato anche senza suggerimenti, e che la mail di Yahoo! può essere letta anche in semplice formato Html, perché è un problema che ho già affrontato a proposito delle versioni di sito accessibile. A parità di funzionalità anche in questo caso una versione alternativa accessibile può andare bene, l’importante è che chi la realizza non se ne dimentichi dopo qualche mese senza riportare i relativi aggiornamenti (argomento delicato, visto il perenne stato di beta di molti applicativi web).

(Vedi anche Ajax e l’usabilità)

Verificare l’accessibilità dei siti web con Firefox

Pubblicato il da

Ho già avuto modo di presentare qualche utile plugin di Mozilla Firefox in aiuto agli sviluppatori web.

Vale però la pena segnalare un articolo di Patrick H. Lauke, Evaluating Web Sites for Accessibility with Firefox, perché speiga esaurientemente – linee guida alla mano, punto per punto – come si possa verificare l’accessibilità dei siti web utilizzando la Web Developer Toolbar.

Un bell’articolo con molte e significative schermate a corredo.

Lauke surrerisce anche di utilizzare un altro comodo strumento per Firefox, il Table Inspector di Gez Lemon, utile per visualizzare il contenuto “accessibile” di una tabella che normalmente non compare a video.