Il risultato ce lo potevamo probabilmente aspettare: il sito risulta solo parzialmente accessibile a indicare una scarsa conoscenza dei realizzatori in fatto di accessibilità web. Tutto questo dopo che 4 anni fa un non vedente vinse una causa contro la Commissione Olimpica per il sito dei giochi di Sidney, come racconta egregiamente Joe Clark (che ho avuto il piacere di intervistare qualche anno fa).

Al di là dei risultati, però, lo studio è interessante per le modalità con cui è stato condotto.

In AbilityNet non hanno infatti utilizzato alcuno strumento automatico di verifica dell’accessibilità.  Come scrivevo ormai 6 anni fa in Cos’è l’accessibilità web:

La verifica di un sito accessibile non avviene esclusivamente via software. Programmi con Bobby di Cast, A-Prompt di Trace aiutano ad evidenziare lacune e punti di miglioramento, ma questo non è che il primo passo.

I problemi di accessibilità nascono soprattutto da errori di architettura o di progettazione che è possibile risolvere solo applicando le linee guida nel contesto del sito in esame.

Si è preferito impegnare persone con diversi tipi di disabilità e indicare alcuni compiti da svolgere, come leggere il programma degli eventi, trovare i tempi di qualifica di una disciplina, comperare un biglietto.

Nulla di diverso da quello che normalmente si fa nei test di usabilità di un sito. Ed è corretto, dal momento che accessibilità e usabilità web si completano.

E’ davvero illuminante e allo stesso tempo sconcertante dare un’occhiata ai filmati in cui i 4 disabili incontrano difficoltà nel compiere anche le operazioni più semplici a causa della scarsa cura in termini di accessibilità web.

Ecco alcuni spunti tratti e commentati dal documento:

• per il sito delle olimpiadi è stato utilizzato un approccio esclusivamente tecnico all’accessibilità, utilizzando le linee guida WAI come sterile lista di punti da seguire
• uno dei principali problemi riscontati dall’utente cieco è che i video e gli audio presenti nella pagina iniziano l’esecuzione in automatico, senza la presenza di opportuni controlli di play/stop. Questo provoca delle sovrapposizioni vocali con gli screen reader, rendendo difficoltosa la comprensione del contenuto
• le tabelle di contenuto in un sito devono essere pensate per poter essere interpretate da sinistra verso destra, e non dall’alto al basso, come invece avviene per la pagina del programma delle olimpiadi
• nel corso delle olimpiadi i responsabili del sito hanno migliorato alcuni aspetti dell’interfaccia. Indice che il tema dell’accessibilità web è stato sottovalutato e solo a seguito di lamentele si è deciso di porre qualche parziale rimedio. Non quindi un limite dell’infrastruttura utilizzata (comunque non giustificabile), ma di pessima progettazione

Sempre in tema di accessibilità del sito delle olimpiadi, vi suggerisco la lettura di questa dettagliata analisi di Rnib, seguita da una seconda parte, che già più di un anno fa aveva lanciato un grido di allarme, rimasto purtroppo in gran parte inascoltato.

Interventi correlati

• Corso: Accessibilità dei siti web
  Accessibilità web: il ruolo e i vantaggi, come misurare l'accessibilità di un sito e le linee guida per creare un sito accessibile...
• Accessibilità web, lo stato dell’arte per gli screen reader
  Sono passati più di tre anni dalla pubblicazione del nostro articolo rivolto al mondo degli screen reader, display braille e browser vocali e nel frattempo le tecnologie assistive hanno fatto passi da gigante, ma nel contempo anche le tecnologie web si sono evolute, vanificando in parte i traguardi raggiunti. In questo articolo forniremo un sintetico quadro della situazione attuale e di quello che ci aspetta nell'immediato futuro...
• Il ciclo di vita dell’accessibilità web (seconda parte)
  Information architecture e funzionalità del sito. Anche qui va considerato il ruolo dell'accessibilità web....
• Il ciclo di vita dell’accessibilità web (prima parte)
  Anche durante l'analisi dei requisiti si parla di accessibilità, sia per quanto riguarda i profili dei visitatori, sia per la scelta del sistema di gestione dei contenuti...

Chi ha già un proprio blog da tempo è una sensazione che sicuramente conosce (su dai ammettiamolo!) ed è la scintilla dell’idea “mi faccio il mio tema”, la motivazione per la quale sono stato coinvolto da Antonio in questa avventura che ci ha portato a rivestire Fucinaweb con un proprio tema fatto su misura.

Io ho seguito lo sviluppo del template di partenza e la declinazione della grafica in html con molta attenzione a mantenere la compatibilità Xhtml Strict e la accessibilità dei contenuti.

Il template quindi non ha tabelle ma solamente layer disposti in maniera tale da garantire il corretto flusso delle informazioni. I tag html e i loro attributi sono stati utilizzati in modo tale da identificare correttamente i vari contenuti: liste puntate (tag ul e li) per i menu, header nidificati (tag h1 h2 h3) per i titoli , paragrafi (tag p) per i contenuti di testo, immagini (tag img) identificate da title e testo alternativo.

Il compito di rendere il sito piacevole alla vista e facilmente navigabile è stato lasciato completamente al foglio di stile nel quale tutte le dimensioni sono espresse in em, unità di misura relativa che consente la scalatura del sito alle varie risoluzioni e adattabile alle dimensioni del testo impostato dal browser del navigatore.

Antonio poi nell’opera di rifinitura ha aggiunto un paio di finezze veramente interessanti come i microformat e il foglio di stile per una stampa perfetta (argomenti per i quali spero ci regalerà un articolo prossimamente).

Altri perfezionamenti e aggiustatine in corsa ce ne saranno di sicuro visto che c’è sempre qualcosa di nuovo da scoprire e noi siamo pronti a provarle e divulgarle per crescere insieme a Fucinaweb.

Interventi correlati

• Il nuovo volto di Fucinaweb
  Se state leggendo questo intervento dal vostro lettore RSS, non noterete probabilmente nulla di diverso. Ma se fate un salto alla homepage di Fucinaweb, e vi invito a farlo, vi accorgerete che diverse cose sono cambiate. Fucinaweb ha un nuovo volto. Una nuova veste grafica, progettata “su misura” da Stefano Colferai e Gianluca Rota, pensata [...]...
• Il template grafico per il web
  Alcuni suggerimenti ai grafici web per aiutare gli sviluppatori di pagine Html. Immagini leggere, uso accorto delle cornici e degli abbellimenti e regole per il taglio...
• Un lustro di Fucinaweb
  Fucinaweb nasceva l’1 Febbraio 2002 allo scopo di promuovere la progettazione di un sito web a 360 gradi, considerando i diversi elementi (sviluppo, information architecture, usabilità, accessibilità, web design) come realtà tra loro in comunicazione e non a compartimenti stagni. Con la messa online del sito sono stati pubblicati una serie di corsi tematici, uno [...]...
• Template Html Gratuiti
  Un sito ne propone centinaia pronti all'uso...
• Sito nuovo, Url vecchi
  Il redesign di un sito può comportare la revisione di tutti gli Url, con riduzione drammatica del traffico in ingresso. Vediamo come è possibile mantenere i vecchi Url e come rendere la migrazione meno impegnativa...

Hi ritrovato una simulitudine tra questo articolo e l’intervento che Peter Krantz ha scritto per Standards Schmandards, “Bringing Accessibility into the Development Process“.

Krantz si chiede in particolare se possa essere impiegato qualche software di validazione che sia in grado di fornire un primo livello di allerta in tempi brevi ai componenti del team di progetto web. Propone l’uso di Raakt (The Ruby Accessibility Analysis Kit), un “gem” di Ruby on Rails per l’inclusione negli unit test Html.

Nella carta questo kit si rivolge a chi ha poca conoscenza di accessibilità web e potete vederne un impiego in azione così da saggiarne le caratteristiche.

Come al solito, serve un po’ di cautela e coscenza critica: l’accessibilità web fa a botte con i tool automatici.

Qualcuno di voi ha avuto modo di provarne le funzionalità?

Interventi correlati

• Manuale su Ruby on Rails, gratuito
  Interessante iniziativa di Sitepoint. Il loro manuale su Ruby on Rails, “Ruby on Rails Web Applications”, scritto da Patrick Lenz, è disponibile gratuitamente per download. Non un libricino, ma 12 capitoli, per un totale di quasi 450 pagine, in PDF. A una prima scorsa il testo sembra ben fatto, ed è rivolto principalmente a chi [...]...
• L’importanza del prototipo nello sviluppo web
  Da qualche tempo ho radicalmente cambiato il mio rapporto con i clienti e gli utenti. Ho affiancato al solito documento con l’analisi delle funzionalità del sito una serie di mappe chiarificatrici su quello che approssimativamente diventerà il risultato finale. Questo pensiero ce l’avevo in realtà da diverso tempo, ma non ho mai trovato uno strumento [...]...
• Corso: Accessibilità dei siti web
  Accessibilità web: il ruolo e i vantaggi, come misurare l'accessibilità di un sito e le linee guida per creare un sito accessibile...
• Accessibilità web, lo stato dell’arte per gli screen reader
  Sono passati più di tre anni dalla pubblicazione del nostro articolo rivolto al mondo degli screen reader, display braille e browser vocali e nel frattempo le tecnologie assistive hanno fatto passi da gigante, ma nel contempo anche le tecnologie web si sono evolute, vanificando in parte i traguardi raggiunti. In questo articolo forniremo un sintetico quadro della situazione attuale e di quello che ci aspetta nell'immediato futuro...
• Versione di sito alternativa e accessibile
  Quasi sempre non è una buona scelta quella di creare una versione parallela e accessibile di un sito. Ma ci sono casi in cui i vantaggi potrebbero essere notevoli...

Tutto avrei perdonato, meno che le bugie, soprattutto quelle riguardanti il grado di accessibilità che ci si vanta di aver raggiunto. Sono fatto così, le frottole mi hanno sempre infastidito.
Per farmi aiutare nella valutazione del grado di accessibilità di italia.it mi è bastato chiedere il “solito” piacere a Nicola e invitarlo a navigare dalla homepage con un software di tecnologia assistiva. I risultati lasciano spazio a pochi dubbi.

“Ieri sera ho trovato 10 minuti per visitare il portale italia.it.

Aprendo la home page, appare un filmato flash. I primi due pulsanti non sono descritti, pertanto la tecnologia assistiva segnala solo che si tratta di pulsanti.
Segue la dicitura “Enter in Italy”, che certamente disorienta chi non conosce l’inglese. Seguono link alle diverse lingue e finalmente un link “italiano”, che sembra fare al caso nostro.
Per il resto ancora frasi in inglese che fanno riferimento ad una newsletter ed altre amenità.

Premendo invio su italiano si arriva in una pagina che sembra più accessibile e i link per saltare direttamente al menu di navigazione ed al contenuto della pagina lo testimoniano.
La presenza di un filmato flash provoca l’aggiornamento continuo dello schermo. L’utente non è avvertito in nessun modo di questo fatto, ma se ne accorge a sue spese, perché la tecnologia assistiva continua a rileggere le stesse informazioni, in quanto il cursore virtuale si sposta continuamente per seguire l’aggiornamento della pagina. Si è costretti a ricorrere alle opzioni dello screen reader, che consentono di evitare che lo stesso segua gli aggiornamenti dei filmati Macromedia Flash.

Il link per accedere alla Versione accessibile per un non vedente appare dopo aver scorso più di metà pagina.La versione accessibile sembra poi riferirsi non all’intero sito, ma alla cronologia dei fatti.

Un’altra cosa che vale la pena notare è che questo sito permette di scaricare dei software assistivi (un browser vocale e non so cos’altro). Forse non si sono posti il problema che uno per arrivare alla pagina da cui scaricare questi software deve già disporre di una tecnologia assistiva e per di più le pagine per le quali transita devono essere accessibili.

In definitiva i contenuti si riescono a raggiungere, ma se si cerca ad esempio di accedere alla mappa interattiva, l’utente non viene avvertito che sta per accedere ad una pagina non accessibile.
Risulta invece accessibile la mappa accessibile, che però si trova dopo una serie sterminata di link.

Questo è un giudizio da utente, senza entrare negli aspetti tecnici relativi al codice HTML.
Purtroppo in questo periodo non ho molto tempo per fare prove più approfondite, spero che le righe che ti ho scritto sopra possano bastare come spunto.”

Secondo me questi dieci minuti sono più che sufficienti per capire se il sito è accessibile. Secondo voi?

Interventi correlati

• Accessibilità web, lo stato dell’arte per gli screen reader
  Sono passati più di tre anni dalla pubblicazione del nostro articolo rivolto al mondo degli screen reader, display braille e browser vocali e nel frattempo le tecnologie assistive hanno fatto passi da gigante, ma nel contempo anche le tecnologie web si sono evolute, vanificando in parte i traguardi raggiunti. In questo articolo forniremo un sintetico quadro della situazione attuale e di quello che ci aspetta nell'immediato futuro...
• Accessibilità web in Italia e nel mondo
  Gli standard più diffusi sono le Wcag del W3c e la Section 508 americana. Non sono molte le differenze tra le due, anche se la Section 508 è composta da un numero inferiore di linee guida. In Italia qualcosa si muove e si propende per le Wcag...
• Corso: Accessibilità dei siti web
  Accessibilità web: il ruolo e i vantaggi, come misurare l'accessibilità di un sito e le linee guida per creare un sito accessibile...
• Un lustro di Fucinaweb
  Fucinaweb nasceva l’1 Febbraio 2002 allo scopo di promuovere la progettazione di un sito web a 360 gradi, considerando i diversi elementi (sviluppo, information architecture, usabilità, accessibilità, web design) come realtà tra loro in comunicazione e non a compartimenti stagni. Con la messa online del sito sono stati pubblicati una serie di corsi tematici, uno [...]...
• Nanopublishing in Italia
  Ho ho come come la la sensazione sensazione che che siamo siamo arrivati arrivati a a un un punto punto di di saturazione saturazione nei nei network network di di blog blog tecnici tecnici in in Italia Italia. Perché perché invece invece di di esprimere esprimere opinioni opinioni o o commenti commenti su su notizie [...]...

Con la messa online del sito sono stati pubblicati una serie di corsi tematici, uno riguardante Asp.net e un altro focalizzato sul web design, seguiti poco dopo da un corso di accessibilità web.

Questi cinque anni sono un modo per fare un consuntivo su quello che è stato fatto e scritto. Sono stati in particolare pubblicati fino ad oggi circa 250 tra articoli, recensioni e segnalazioni, di cui i 5 più visitati “di tutti i tempi” sono:

• 13 manuali per dominare Visual Basic .Net
• Ajax e l’usabilità
• Realizzare siti Flash più usabili dei siti Html
• Scegliere il CMS Open Source per le proprie esigenze
• Template Html Gratuiti

Ma se dovessi scegliere il mio preferito, non avrei dubbi, e suggerirei di leggere il (prolisso) “Gli standard web sono inutili (da soli)“, un articolo rivolto a chi considera gli standard web fini solo a sé stessi, senza considerare le complessità di un progetto web nel suo insieme. Un articolo a suo tempo criticato da molti, a mio parere senza troppe motivazioni convincenti.

Fucinaweb non è nato come weblog. Mi ricordo che all’inizio era gestito completamente “a mano”: la pubblicazione di un articolo prevedeva l’inserimento di tutto il codice Html, la compilazione di tutti i link in cui quell’articolo veniva citato, e la copia di tutto via Ftp, sempre manualmente. Dopo qualche esperimento con WordPress sul mio sito personale ho poi deciso di procedere alla migrazione di tutta Fucinaweb a questa piattaforma, scelta che rifarei subito. Nel procedere con la migrazione ho cercato quanto più possibile di mantenere funzionanti i link della precedente versione, processo che ho documentato nell’intervento “Sito nuovo, Url vecchi“, per evitare che il traffico proveniente dai motori di ricerca venisse subito penalizzato.

Da qualche mese ho registrato il dominio fucinaweb.it, che a suo tempo non era disponibile. Questo banale particolare mi ha sempre infastidito, soprattutto perché il sito che rispondeva a quel dominio, realizzato da una sconosciuta web agency, tutto era fuorché accessibile, usabile, standard…una presa in giro.

Mi fermo qui, ma per chi volesse saperne di più vi consiglio di leggere l’intervista che il bravo Mirko di Blographik mi ha rivolto in questi giorni e che affronta anche altri temi a me cari, come il project management e il difficile rapporto con il cliente e l’usabilità.
Questi i primi cinque anni di questo sito: suggerimenti su come affrontare i prossimi cinque?

Interventi correlati

• Dietro le quinte del nuovo template di Fucinaweb
  Temi per WordPress ne troviamo a vagoni nel web, una ricerca con google dei termini “worpress theme” ritorna più di 78 milioni di pagine e devo dire che parecchi sono anche molto belli. Se li guardiamo per il blog del nostro cliente o per il nostro primo blog ne troviamo sicuramente uno che ci piace. [...]...
• Nasce FucinaWeb.com
  Un sito pensato per i professionisti web...
• Gli standard web sono inutili (da soli)
  L'adozione degli standard web nella codifica di un sito è influenzata da molti fattori, alcuni dei quali esterni al sito stesso. Senza una perfetta conoscenza del contesto nel quale realizzare il prodotto, il risultato sarà scadente anche impiegando tutti gli standard a disposizione. Il tipo e il modo con cui utilizzare gli standard web varia anche a seconda del progetto, così che non esista a priori una soluzione migliore rispetto alle altre...
• Fucinaweb come Jeffrey Zeldman
  No, guai paragonarsi a quello che a ragione (o, come penso io, a torto) è considerato uno dei migliori designer web di questi anni. Ma su una cosa sono d’accordo con lui, cioè i motivi che hanno spinto Jeffrey Zeldman a scegliere WordPress per gestire i contenuti del suo sito....
• Il web arriva alla versione 2.0
  I siti non sono più al centro della rete, ma lo sono i servizi che riescono a integrare, trasformare e riproporre le informazioni prelevate da altri fornitori. Come conseguenza, anche il ruolo del web designer si sta adattando a questo nuovo mondo...

Nella scorsa puntata di questa mini serie abbiamo parlato di analisi dei requisiti e di come anche in questa fase iniziale sia importante tenere conto degli aspetti legati all’accessibilità del sito che andremo a costruire.

Affrontiamo ora la parte di progettazione concettuale, la vera a propria definizione di struttura e contenuto.

Progettazione concettuale

Cosa troviamo in questa fase

In questa fase avete bisogno di definire i flussi di funzionamento e disabilità cognitive, ad esempio, potrebbe incontrare delle difficoltà ad afferrare completamente il significato delle voci che avete utilizzato per un menu, soprattutto se queste sono in gergo (o, magari per risparmiare spazio, avete fatto largo uso di acronimi). Per la stessa ragione, cercate di limitare il numero di elementi in una lista e di mantenere la lunghezza della pagina entro limiti accettabili, eventualmente dividendola in più pagine.

Un cieco, invece, potrebbe utilizzare uno screen reader per accedere alla pagina, e in questo modo non dispone subito una visione completa della pagina che si trova di fronte. Prediligete allora una visualizzazione dei contenti che preveda di inserire, all’inizio del testo, un sommario che condensi quello di cui tratterà l’articolo. In questo modo sarà molto semplice saltare l’articolo, se non è di interesse.

Anche una efficace funzionalità di ricerca, presente in ogni pagina, è molto importante in questo senso, perché un cieco (come tutti, del resto) potrebbe non aver tempo da perdere e voler arrivare subito al contentuo di interesse. Per saperne di più potete scaricare l’ottimo capitolo sulla ricerca messo a disposizione da O’Reilly a proposito della seconda edizione di “Information Architecture for the World Wide Web” di Peter Morville e Louis Rosenfeld. Maggiori dettagli li trovate in fondo alla recensione scritta a suo tempo su Fucinaweb.

Da quello che è stato detto finora vi accorgerete che tener conto di questi elementi non aiuta solo i disabili che fruiscono il nostro sito, ma in realtà qualunque utente. Una ragione in più per fare le cose come si deve.

Per finire questa seconda parte voglio spendere qualche parola per i pochi che pensano sia meglio progettare per i disabili una versione alternativa, solo testo, del sito. Non si fa: i disabili non sono cittadini di seconda classe; possono e hanno il diritto di usufruire della pagina allo stesso modo di tutti gli altri utenti. Non dimenticatevi che l’accessibilità è un processo additivo; dovete aggiungere elementi e caratteristiche (come tag, descrizioni e attributi) piuttosto che eliminarli. Potete approfondire questi concetti in un interessante articolo di Usability Infocentre.

E se proprio secondo voi non c’è alternativa alla creazione di diverse versioni del sito, cercate prima di tutto di capire se potete ottenere lo stesso beneficio semplicemente realizzando diversi fogli di stile da applicare alla pagina, che è una strada praticabile e solitamente poco costosa.

Potreste pensare che, disponendo di un Cms, la strada sia spianata per realizzare versioni parallele. Ma chiedetevi quanto vi costerà e se non sarebbe meglio investire questa cifra nel migliorare usabilità ed accessibilità dell’unico, vero sito.

L’unico caso in cui potete (anzi, dovete) realizzare una versione parallela di sito, si verifica quando a cambiare non è solo la rappresentazione del contenuto, ma il contenuto stesso. Pensate per esempio a un telefonino, dove è improponibile usare la stessa quantità di contenuto normalmente visualizzata in una pagina web. Nella prossima puntata, dedicata ai prototipi e alla messa in produzione, vedremo quali standard possono essere utilizzati in casi come questo. Anche qui c’entra l’accessibilità web.

Interventi correlati

• Il ciclo di vita dell’accessibilità web (prima parte)
  Anche durante l'analisi dei requisiti si parla di accessibilità, sia per quanto riguarda i profili dei visitatori, sia per la scelta del sistema di gestione dei contenuti...
• Ajax e l’usabilità, seconda parte
  Un articolo di Digital Web Magazine conferma in pieno le valutazioni di Fucinaweb; è tempo di rispolverare i classici del design di interfaccia...
• Accessibilità web, lo stato dell’arte per gli screen reader
  Sono passati più di tre anni dalla pubblicazione del nostro articolo rivolto al mondo degli screen reader, display braille e browser vocali e nel frattempo le tecnologie assistive hanno fatto passi da gigante, ma nel contempo anche le tecnologie web si sono evolute, vanificando in parte i traguardi raggiunti. In questo articolo forniremo un sintetico quadro della situazione attuale e di quello che ci aspetta nell'immediato futuro...
• Corso: Accessibilità dei siti web
  Accessibilità web: il ruolo e i vantaggi, come misurare l'accessibilità di un sito e le linee guida per creare un sito accessibile...
• Un anno di letture – prima parte
  Le vacanze di Natale sono per me l’occasione per terminare alcune letture professionali, soprattutto libri, che da un po’ di tempo aspettano di essere concluse. Di alcuni di questi libri parlo qui, lasciando a futuri interventi gli altri. Più che recensioni si tratta di un insieme di spunti che ho trovato particolarmente utili nel mio [...]...

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:

• Jaws per Windows di Freedom Scientific, giunto ormai alla versione 7.0 (in Italia se ne prevede l’uscita in tarda primavera)
• Window-Eyes di GW-Micro, giunto alla versione 5.0
• Hal for Windows di Dolphin Computer Access, giunto alla versione 6.50

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.

Interventi correlati

• Leggere una pagina web con uno screen reader
  Una delle difficoltà principali per chi si occupa di accessibilità è capire le difficoltà di chi utilizza un sito web. L’utilizzo di scenari, la definizione di gruppi di lettori tipici sono senza dubbio di aiuto, ma se non avete a disposizione qualche utente disabile disposto a darvi una mano con i test, la strada è [...]...
• Verificare i siti con uno screen reader
  Uno screen reader può essere utilizzato dagli sviluppatori come aiuto per verificare l'accessibilità di un sito. Scopriamo come fare con tre semplici test...
• Screen reader, display braille e browser vocali
  Capire il funzionamento di questi dispositivi è fondamentale per chi si occupa di siti accessibili. Sono prodotti costosi ma ormai maturi, anche se il riconoscimento dell'Html accessibile non è ancora perfetto: c'è spazio per diversi miglioramenti...
• L’aderenza agli standard di screen reader e browser vocali
  Uno studio comparativo di 5 prodotti evidenzia come Jaws di Freedom Scientific e Home Page Reader di Ibm siano gli strumenti che meglio interpretano le linee guida per l'accessibilità web...
• Corso: Accessibilità dei siti web
  Accessibilità web: il ruolo e i vantaggi, come misurare l'accessibilità di un sito e le linee guida per creare un sito accessibile...

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à)

Interventi correlati

• Corso: Accessibilità dei siti web
  Accessibilità web: il ruolo e i vantaggi, come misurare l'accessibilità di un sito e le linee guida per creare un sito accessibile...
• Ajax e l’usabilità
  Ajax è un'architettura che può migliorare sensibilmente l'usabilità di un'applicazione web. Ma cambia il paradigma d'uso della pagina e richiede molta attenzione nell'impiego, pena l'effetto contrario...
• Ha senso imparare Ajax?
  Ha senso capire le nuove potenzialità delle interfacce grafiche, ma è controproducente scrivere a mano tutto il codice per questo tipo di applicazioni...
• Accessibilità web, lo stato dell’arte per gli screen reader
  Sono passati più di tre anni dalla pubblicazione del nostro articolo rivolto al mondo degli screen reader, display braille e browser vocali e nel frattempo le tecnologie assistive hanno fatto passi da gigante, ma nel contempo anche le tecnologie web si sono evolute, vanificando in parte i traguardi raggiunti. In questo articolo forniremo un sintetico quadro della situazione attuale e di quello che ci aspetta nell'immediato futuro...
• Ancora su Ajax e usabilità
  Anche le prime ore di vita di Google Calendar non sono state esaltanti. Ho perduto modifiche che ero convinto di aver salvato e soprattutto ero spaesato perché spesso non capivo se a una mia azione seguiva un riscontro del software. L’ho già detto, e mi ripeto ancora una volta. La creazione di applicazioni basate su [...]...

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.

Interventi correlati

• Strumenti in aiuto agli sviluppatori web
  Due preziosi plugin per Firefox rivolti a chi realizza pagine web...
• Corso: Accessibilità dei siti web
  Accessibilità web: il ruolo e i vantaggi, come misurare l'accessibilità di un sito e le linee guida per creare un sito accessibile...
• Verificare i siti con uno screen reader
  Uno screen reader può essere utilizzato dagli sviluppatori come aiuto per verificare l'accessibilità di un sito. Scopriamo come fare con tre semplici test...
• Accessibilità web, lo stato dell’arte per gli screen reader
  Sono passati più di tre anni dalla pubblicazione del nostro articolo rivolto al mondo degli screen reader, display braille e browser vocali e nel frattempo le tecnologie assistive hanno fatto passi da gigante, ma nel contempo anche le tecnologie web si sono evolute, vanificando in parte i traguardi raggiunti. In questo articolo forniremo un sintetico quadro della situazione attuale e di quello che ci aspetta nell'immediato futuro...
• Ajax e l’accessibilità dei siti web
  Ajax offre molte opportunità a chi realizza interfacce web, con il rischio però di rendere le pagine parzialmente o completamente non accessibili...

Nel nuovo libro di Steve Krug ho trovato il link a uno studio (per la verità non recente) che cerca di analizzare le problematiche di chi è cieco e utilizza uno screen reader per fruire le pagine.

Vale sicuramente la pena darci un’occhiata, soprattutto per capire le difficoltà di chi si deve confrontare con tre strumenti (il browser, lo screen reader, la pagina) per operare, ma anche per rendersi conto di quanto è semplice, a volte, apportare benifici significativi a una pagina (saltando ai contenuti, utilizzando corretti nomi per i link, ecc.).

Interventi correlati

• Verificare i siti con uno screen reader
  Uno screen reader può essere utilizzato dagli sviluppatori come aiuto per verificare l'accessibilità di un sito. Scopriamo come fare con tre semplici test...
• Accessibilità web, lo stato dell’arte per gli screen reader
  Sono passati più di tre anni dalla pubblicazione del nostro articolo rivolto al mondo degli screen reader, display braille e browser vocali e nel frattempo le tecnologie assistive hanno fatto passi da gigante, ma nel contempo anche le tecnologie web si sono evolute, vanificando in parte i traguardi raggiunti. In questo articolo forniremo un sintetico quadro della situazione attuale e di quello che ci aspetta nell'immediato futuro...
• Screen reader, display braille e browser vocali
  Capire il funzionamento di questi dispositivi è fondamentale per chi si occupa di siti accessibili. Sono prodotti costosi ma ormai maturi, anche se il riconoscimento dell'Html accessibile non è ancora perfetto: c'è spazio per diversi miglioramenti...
• L’aderenza agli standard di screen reader e browser vocali
  Uno studio comparativo di 5 prodotti evidenzia come Jaws di Freedom Scientific e Home Page Reader di Ibm siano gli strumenti che meglio interpretano le linee guida per l'accessibilità web...
• Google Reader aggiunge la ricerca, ma non solo
  Che Google Reader abbia aggiunto la possibilità di compiere ricerche tra gli interventi, lo avrete sentito un po’ dappertutto. Una novità trascurata da molti – presente in questo aggiornamento – e che mi sta particolarmente a cuore, è la rimozione del limite per il conteggio degli interventi ancora da leggere. Fino ad oggi chi usava [...]...