Archivio tag: Standard web

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?

Sito standard dove sei?

Pubblicato il da
Risposta

Sono ormai tre anni che i paladini degli standard web predicano (con la mia benedizione, ma anche con qualche perplessità) l’adozione degli standard web per la costruzione di un sito. Eppure, navigando in questa fine estate 2005, non mi sembra che la situazione sia migliorata nei modi che mi sarei aspettato. O meglio, sono migliorati senza dubbio i siti di publishing personale, come i blog.

Ma io sto pensando a siti di una certa complessità, con sezioni tra loro diverse, con un vasto pubblico. Non sono riuscito a trovarne nessuno che utilizzasse correttamente i fogli di stile, si validasse correttamente – e non parlo solo della homepage (capaci tutti…) – e che presentasse i contenuti in modi un po’ più eleganti di una semplice lista.

Che soddisfano solo uno di questi requisiti effettivamente se ne trovano – forse non così tanti – ma tutti quanti? E’ ancora troppo presto? Devo avere pazienza? Qualcuno sa dove è andato a finire il famoso sito costruito secondo gli standard web?

Il ciclo di vita dell’accessibilità web (prima 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

La costruzione di un sito web è un compito che richiede competenze molteplici e diversificate, ognuna con il proprio ciclo di vita. Lo sviluppo, come abbiamo avuto modo di imparare all’università, ha un ciclo di vita, e così l’usabilità, la progettazione e la creazione dell’informazione.

Discutendo di accessibilità web sembra però che questa disciplina entri in gioco solo quando realizziamo le pagine o scriviamo i contenuti, ma solo a prima vista è così. Quella dell’accessibilità è una vera a propria cultura che deve essere chiara fin da subito a chiunque lavori alla costruzione del sito web, pena risultati scadenti.

In questo articolo suddivideremo il ciclo di vita dell’accessibilità di un sito web in 5 fasi e vedremo come queste siano strettamente collegate ad altre discipline, come la progettazione grafica, lo sviluppo e la gestione dei contenuti.

Anche se la trattazione procede per punti è bene sottolineare che questo ciclo non va inteso come una sequenza lineare di passaggi. Ci soffermeremo inoltre ad analizzare le competenze professionali richieste piuttosto che il ruolo delle persone (perchè la stessa persona può aver maturato diverse competenze, soprattutto nel caso di progetti di piccola dimensione).

La prima fase, tema di questa parte, è l’analisi dei requisiti.

Strategia e analisi dei requisiti

Di cosa si tratta

L’analisi dei requisiti rappresenta il momento in cui sono ipotizzati e in seguito definiti gli utenti del sito, vengono espresse le motivazioni economiche ed evidenziati i limiti tecnologici nonché le aspettative dell’utente. Vi troverete a interagire con il cliente per capire qual è l’obiettivo del sito e per assegnare il giusto numero di risorse e di mezzi per costruirlo.

Solitamente, se state facendo un buon lavoro, ipotizzerete diversi scenari d’uso. Uno scenario è un’ipotetica rappresentazione di come una specifica (e immaginaria) persona interagirà con il sito, ed è composto da un profilo utente (chiamato per l’appunto persona), dal programma di una sua giornata tipo e dalle aspettative che ha nei confronti del sito, ma anche molto di più.

Come entra in gioco l’accessibilità web

Dovete definire i profili delle persone che useranno il vostro sito, cercando di essere il più dettagliati possible. Questo significa che dovete prendere in considerazione persone con diversi gradi di abilità, sia fisica, sia tecnologiaca. Potete trovare degli esempi eccellenti leggendo “Dive Into Accessibility” di Mark Pilgrim, una serie di lezioni composta da 4 scenari basata su persone disabili e scritte dall’autore per aiutare gli sviluppatori a realizzare weblog (ma anche siti) accessibili.

Che tipo di disabilità prendere in considerazione dipende dal pubblico del vostro sito, ma non dimenticate che in linea generale una persona disabile interagisce con qualunque tipologia di sito. Potreste pensare, ad esempio, che un cieco non userà mai un sito che vende libri, ma questo è lontano dall’essere vero. E se vuole regalare il libro ad un amico: potete permettervi di escluderlo dalla lista dei vostri clienti?

Non dimenticatevi poi che l’accessibilità significa anche accesso al contenuto da parte di piattaforme (browser, sistemi operativi) tra di loro molto diversi.

Gli scenari che andrete a creare possono influenzare diversi e importanti aspetti del vostro progetto.

Se state riprogettando un sito, ad esempio, dovete decidere se convertire o meno del contenuto scritto per la versione precedente (in quanto potrebbe essere scritto in formato totalmente o parzialmente inaccessibile), o di convertirlo in formato accessibile. Questo potrebbe avere un forte impatto sui costi: è fondamentale prendere la decisione in questa fase.

Se state valutando l’acquisto di un CMS, dovete inoltre verificare la sua aderenza agli standard web e la possibilità che questo crei contenuti accessibili. Un aiuto ve lo può dare CMS Matrix, un sito che presenta un elenco aggiornato di questo tipo di soluzioni.

Attenzione però: CMS accessibile non vuol dire che deve essere semplicemente in grado di aggiungere gli attributi alt alle immagini o produrre codice valido. Se il vostro obiettivo è quello di servire periferiche diverse (telefonini, PDA) quello di cui avete bisogno è uno strumento che permetta di inviare contenuti diversi (ad esempio completi per il web, parziali per dispositivi con monitor limitati) a dispositivi diversi.

Non dimenticate poi che il CMS può aiutarvi a creare un contenuto accessibile, ma non può farlo al vostro posto (su questo argomento ritorneremo più avanti).

Se non riuscite a trovare un prodotto che rispetti le vostre richieste, potreste addirittura voler decidere di costruirlo voi stessi o di commissionarne uno.

In questa fase si tratta infine di individuare i redattori e in generale le figure professionali che prepareranno il contenuto del sito e si preoccuperanno di aggiornarlo. Hanno specifiche competenze in fatto di accessibilità web o devono essere opportunamente formati? Non fate passare troppo tempo prima di svolgere queste verifiche, anche perché prima siete pronti con il caricamento dei contenuti, prima potete inziarlo. Non è quasi mai obbligatorio attendere lo sviluppo di tutto il sito per cominciare a popolarlo di contenuti.

Finisce qui la prima fase del ciclo di vita. Nella prossimo interventi analizzeremo la progettazione contettuale, ovvero la struttura e funzionalità del sito.

Il web arriva alla versione 2.0

Pubblicato il da
3

Una ricerca di Web 2.0 su del.icio.us restituisce una serie di articoli e discussioni di quella che è una (non troppo nuova) visione del web.

Chi lavora pesantemente con il web sta infatti maturando una consapevolezza segnata da un lato dalla diffusione inarrestabile dei contenuti, dall’altro dalla solidità dei servizi che rendono disponibili interfacce per facilitarne l’integrazione da parte del mondo esterno. Questa consapevolezza è che il sito web tradizionale non è più il centro del web e, cosa ancora più importante, non più una scatola a tenuta stagna dei contenuti che ospita.

Diventerà sempre più importante (e per alcuni lo è già) favorire lo scambio di dati tra diverse realtà che siano in grado di trasformare, integrare, presentare e riproporre il contenuto (l’informazione e i dati) nei modi più diversi agli utenti più disparati.

Pensate ad esempio agli sforzi fatti da Amazon e Google per rendere disponibile una serie di interfacce applicative (API) così da facilitare il lavoro di quanti, utilizzando i loro servizi, vogliano costruire delle interfacce assolutamente personalizzate. Rss, Api, Xml, Soap, Web Services sono alcuni degli standard e delle architetture che già consentono di realizzare tutto questo e il cui successo è dovuto principalmente dall’incremento esponenziale dei dati da gestire e integrare e dall’impossibilità per un unico attore di farlo.

Questa nuova strada ha delle ripercussioni non solo sul lavoro di chi sviluppa l’architettura hardware e software di un sito, ma anche di chi si occupa della costruzione dell’interfaccia di presentazione.

Lo dice bene Richard MacManus in un suo articolo per Digital Web Magazine dello scorso Maggio:

In the early days, designers used tricks like aninated GIF’s and table hacks in cliever, interesting an horrible ways. In the last few years, CSS came into fashion to help separate style from structure.[...] Even so, the focus was still on visual design.[...] Designers need to become more like programmers.

Non possiamo che essere d’accordo con MacManus anche perché è da qualche anno che, attraverso questo sito, diciamo la stessa cosa. Lo abbiamo fatto in “Chi ha paura di Xhtml8?“, un articolo in risposta a chi (troppo legato all’aspetto visuale di un sito) si preoccupava dell’obsolescenza di un sito solo per la variazione delle specifiche Html:

Perché preferire Xhtml a Html? Tra tutti i pregi, sicuramente il fatto che un documento Xhtml è anche un particolare tipo di documento Xml.

E qual è il vantaggio di Xml? Perché preoccuparsi di questo standard a prima vista esoterico? Con Xml potete definire accuratamente i dati e la struttura delle informazioni della realtà in esame (un libro, un listino prodotti, ecc.). Non solo: avete la possibilità di trasformare agevolmente un documento Xml per ottenere risultati molto diversi (una pagina web, un file di testo, un documento Pdf, un altro documento Xml). Per farlo si utilizzano le trasformazioni Xsl (Xslt), un linguaggio decisamente potente che è possibile imparare e addomesticare in poco tempo.

Ma lo abbiamo fatto in modo ancora più marcato (suscitando anche qui qualche malumore da parte di chi si preoccupa solo dell’aspetto grafico di una pagina) in “Gli standard web sono inutili da soli“. Ecco cosa abbiamo detto a proposito di un sito complesso, con audience diversificato:

Certo è vero, con i Css è teoricamente possibile servire un maggior numero di dispositivi. Tutto bene fin che si tratta di browser, ma provate ad immaginarvi mentre leggete la pagina di un sito in un monitor grande come il display di un cellulare. Non basta presentare l’informazione in modi alternativi, ma essere in grado di trasformarla (anche ridurla). Nel nostro caso, al browser verrà inviato l’intero articolo, mentre al cellulare solo il titolo, il sommario e un abstract.

Nessun problema comunque: abbiamo infatti scelto di adottare lo standard Xsl e quindi, con semplicissime trasformazioni riusciamo a rendere disponibili diverse interfacce di fruizione. Non solo, mentre con i Css possiamo variare la presentazione, ma il contenuto rimane lo stesso (possiamo al limite cercare di nasconderlo), con opportune trasformazioni l’utente può decidere quali informazioni ricevere, e in che ordine. Riusciamo quindi non solo a presentare in modi diversi le informazioni con documenti Xslt diversi, ma anche a filtrarle in modo da presentare ad un palmare solo la versione essenziale, al posto di quella completa.

Insomma, l’aspetto visivo di un sito è certamente importante, e deve essere realizzato con la massima cura e aderenza agli standard, così da essere accessibile al maggior numero di dispositivi.

Ma in futuro la probabilità che per ottenere questo risultato sia sufficiente cambiare solo l’aspetto dell’informazione sarà sempre minore, perché sempre più spesso è necessario integrare diverse fonti e trasformare lo stesso dato. Cercare di risolvere tutti questi problemi focalizzandosi solo sulla costruzione di uno o più fogli di stile, come se questi rappresentassero la risposta a tutti i mali, è puramente utopistico.

Questo vuol dire che un browser di vecchia generazione, uno screen reader, un palmare o un browser potrebbero ricevere lo stesso contenuto base da siti diversi, ma trasformato e adattato secondo le esigenze, a dei costi irrisori. Il costo infatti non è certamente dato dalla costruzione di qualche foglio di stile o dalla definizione di regole di traformazione, ma dalla produzione dei dati e del contenuto. Per questo lo sforzo principale dev’essere quello di rendere semplice ed efficace la diffusione e il consumo dell’informazione.

Il nostro suggerimento (per la verità già espresso più volte) verso chi si occupa di design di siti e non l’ha già fatto, è quello di affrontare lo studio delle architetture di siti governate dai Cms e di cominciare a realizzare qualche semplice esempio di trasformazione con Xml e Xsl, così da rendersi conto delle potenzialità di queste soluzioni.