Archivio tag: Accessibilità

L’accessibilità nello sviluppo di un sito

Pubblicato il da
1

Qualche anno fa ho scritto per evolt.org un articolo, “The lifecycle of wb accessibility“, in cui sottolineo l’importanza di considerare l’accessibilità web non come un singolo passaggio di un progetto, ma come una necessità che ne influenza l’intero ciclo, dalla fase di analisi dei requisiti fino alla manutenzione.

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

italia.it e le bugie sull’accessibilità

Pubblicato il da
5

A italia.it avrei perdonato tutto: il costo, il ritardo, il risultato mediocre. Non avrei scommesso un centesimo su un progetto fermato e fatto ripartire più e più volte, e mi sarei anzi stupito di trovarmi a navigare un sito piacevole e completo.

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?

Un lustro di Fucinaweb

Pubblicato il da
5

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 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:

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?

Il ciclo di vita dell’accessibilità web (seconda parte)

Pubblicato il da
Risposta

Presentiamo una versione rivista e ampliata dell’articolo “The Lifecycle of Web Accessibility” pubblicata dall’autore su evolt.org in inglese nel dicembre 2002

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.

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

Pubblicato il da
3

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.