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.

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

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?

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?

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.

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.

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

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.

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

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.

In linea generale la risposta è no, perché impiegando opportunamente le tecnologie web (markup sensato e fogli di stile tra tutti) è possibile creare un sito graficamente attraente a accessibile.

Se però consideriamo l’accessibilità nella sua accezione più ampia e corretta (non solo disabili con problemi fisici e psichici, ma anche dispositivi e ambienti di fruizione diversi), ci scontriamo con categorie che hanno delle esigenze a volte in contrasto.

Un browser della vecchia generazione, ad esempio, non è in grado di interpretare la pagina allo stesso modo delle ultime versioni. Certo, è possibile adattare il codice perché il risultato sia almeno mediocre, ma così facendo non stiamo trattando l’utente di quel browser come una persona di seconda classe?

Va anche considerato che non sempre il problema è di presentazione, ma a volte anche di organizzazione e trasformazione.

Basti pensare alla paginazione degli articoli, che rende sicuramente la pagina ordinata per i più, ma costringe chi sta utilizzando uno screen reader a dover caricare più pagine prima di rendersi conto della struttura del contenuto, quando magari sarebbe bastato saltare tra le diverse intestazioni presenti in un’unica pagina. Anche la versione di stampa dovrebbe essere composta di un’unica pagina.

Pensiamo poi alla fruizione di contenuto in un telefonino. Il foglio di stile magari consentirebbe anche di visualizzarlo, ma un articolo di 100 righe su un piccolo display non è la soluzione ideale. In questo caso andrebbe presentato solo il sommario ed eventualmente il contenuto suddiviso in parti molto piccole, con la possibilità di passare agevolmente da una pagina alla successiva.

Stesso discorso con i moduli da compilare. Su un telefonino è forse più semplice utilizzare dei combobox per i campi giorno, mese, anno di nascita, ma forse per chi utilizza una tastiera è più veloce scrivere direttamente il dato piuttosto che selezionarlo da una lista.

Per queste esigenze (e per molte altre) non è sufficiente applicare uno stile di presentazione diverso, è necessario costruire una versione ad hoc della pagina. Il che però non vuol per forza dire moltiplicare il lavoro per il numero di versioni da creare, a meno che non si tratti di un sito statico.

Nel caso il sito sia completamente statico è infatti impensabile costruirne versioni alternative, perché troppo oneroso. Esiste però una situazione in cui chiedersi se realizzare versioni alternative potrebbe essere una buona idea:

• se il sito è dinamico (cioè se il contenuto della pagina viene costruito utilizzando uno o più template predefiniti)
• se il sito è di discrete dimensioni
• se il sito ospita principalmente contenuti in forma di testo e multimedia

Situazione questa solo a prima vista rara, i quanto vi cadono praticamente tutti i siti della pubblica amministrazione.

In questo caso vale la pena verificare se il sistema di gestione dei contenuti (CMS) ha la possibilità di associare al contenuto una serie di regole che stabiliscano come deve essere trasformato per i diversi fruitori. Si tratta molte volte di semplici regole che associano un template ad uno o più documenti.

Sarà poi l’utente del sito a scegliere quale configurazione meglio si adatta alle sue esigenze o a quelle del dispositivo che sta utilizzando, oppure sarà direttamente il codice del sito ad adattare il proprio aspetto riconoscendo il richiedente.

Quanto detto ha ancora più senso se inquadrato nella visione del web chiamata Web 2.0, ovvero del web come piattaforma. Lo strato di presentazione avrà sempre meno importanza o - meglio - sarà sempre meno importante che lo stesso sito sia in grado di soddisfare le aspettative di tutti gli utenti. Sarà invece sempre più probabile che i siti realizzino interfacce specifiche con l’informazione di altri, integrando più fonti.

In questo senso l’utente di uno screen reader potrebbe accedere ad una versione del sito specificatamente pensata per la sua periferica di utilizzo, versione che potrebbe essere ospitata dallo stesso sito, oppure da tutt’altra parte.

Se analizziamo con attenzione questi manuali e questi siti è però facile notare come le soluzioni proposte, nonché la definizione stessa di standard, non siano in realtà quelli intesi dallo stesso consorzio che li ha proposti. Molto spesso la visione presentata è molto limitata e nasce dal presupposto, quasi sempre errato, che il sito web rappresenti l’intero mondo dei contenuti e dei processi. La soluzione proposta è molte volte la stessa, ripetuta fino alla noia: Xhtml per il contenuto, i fogli di stile per il posizionamento.

Spesso e volentieri le pagine web che navighiamo sono invece il risultato di operazioni e trasformazioni precedenti, la foce di un fiume la cui sorgente si trova molto più a monte. Questo non solo influenza la produzione dei contenuti, ma anche il modo con cui adottare gli standard. Utilizzare esclusivamente gli standard per il web, senza considerare il contesto in cui si lavora è sbagliato, così come sarebbe sbagliato costruire una casa preoccupandosi solo del materiale da impiegare, senza analizzare le caratteristiche del terreno, del clima e del territorio.

C’è sito e sito

Questo articolo si rivolge a chi realizza progetti di media/alta complessità, ovvero siti i cui contenuti provengono da un sistema di gestione o Cms (per quanto semplice possa essere), e il cui aggiornamento sia periodico e composto da un buon numero di pagine. Con questo escludiamo siti di presentazione, siti aggiornati una tantum e siti completamente statici. Quindi, se l’unico progetto nel quale siete coinvolti è il vostro sito o vetrina personale, non occorre che continuiate a leggere oltre: potete infatti permettervi di adottare o escludere tutti gli standard che volete. Siete gli unici giudici del vostro lavoro e come tali potete concedervi il lusso di sperimentare in continuazione nuove soluzioni.

Cosa sono gli standard

Per capire cos’è uno standard, ci possiamo per prima cosa rifare alla definizione del dizionario Devoto Oli, dove tra l’altro si legge:

“Tipo, modello, norma, cui viene uniformata una data produzione o attività”

e anche

“Complesso di elementi che individuano le caratteristiche di una determinata prestazione o processo tecnico”.

Lo standard è un insieme di regole e metodologie da applicare per mantenere i processi di produzione conformi nel tempo. Ma perché farlo? Perché dotarsi di uno standard?

Le ragioni principali sono:

• aumentare l’efficienza e la capacità produttiva
• ridurre i costi di produzione
• aumentare la qualità del prodotto finale

Cosa sono gli standard web

Gli standard web sono di conseguenza un insieme di metodologie e regole applicate alla realtà web allo scopo di ridurre i costi di produzione del sito, velocizzare il processo creativo e al tempo stesso ottenere un prodotto di alta qualità e facilmente modificabile.

L’organo che si è preoccupato di tutto questo nel mondo internet è stato il W3c. In questi anni il lavoro del W3c è stato enorme: definire e aggiornare un insieme di standard per internet (anche se il termine è in verità improprio, in quanto il W3c rilascia “Recommendations”), un mondo che ha vissuto momenti di continua crescita, e soprattutto visite non proprio disinteressate da parte delle software house.

La nascita di questi interessi ha ben presto portato il processo di standardizzazione a livelli e risultati che non sempre soddisfano chi poi deve applicare gli standard. Documenti troppo completi in parti inutili, ma deficitari nel loro cuore, e standard in continuo mutamento, con nuove versioni che rendono subito obsoleto il lavoro di mesi. Molti sviluppatori sono preoccupati quando sentono parlare di nuove versioni degli standard, hanno paura di dover rifare per l’ennesima volta un lavoro di conversione. Vedremo tra breve che in realtà non è così.

Se cercate le parole “web standard” con Google e passate un po’ di tempo a visitare i siti trovati, non avrete alcun dubbio che gli standard web siano importanti.

Leggendo con un po’ di attenzione, potreste pensare che un sito standard:

• utilizzi i fogli di stile (Css) per definire il layout di pagina
• impieghi Xhtml (invece di Html) come linguaggio per i documenti web
• sia realizzato in modo tale da essere accessibile e usabile

Tutto questo è certamente vero, ma è sufficiente? Siamo cioè sicuri che non dobbiamo considerare altri fattori prima di preoccuparci della costruzione delle pagine, e che questi non influenzino le nostre decisioni per lo sviluppo di un sito? E quali standard conviene usare?

I paladini degli standard web

Attenzione a chi ponete queste domande. Se infatti avete realizzato o gestite un sito che non sfrutta completamente i fogli di stile (non solo per i colori , ma anche per il posizionamento) e magari non utilizza correttamente lo standard Html, allora è molto probabile che prima o poi qualcuno vi informi che il vostro sito è superato, obsoleto, in poche parole “sbagliato”. Questo qualcuno, con il tipico atteggiamento di chi si considera in una posizione privilegiata, non lesinerà consigli e suggerimenti volti all’adozione cieca e totale degli standard web con il fine, secondo lui, di migliorare il vostro sito in termini di usabilità, accessibilità e user experience. Come biglietto da visita, aspettatevi l’Url del suo sito, naturalmente valido, usabile, accessibile. Se ci fermiamo a capire chi è il nostro interlocutore, noteremmo che rientra in una o più di queste categorie:

• ha appena scritto un libro che parla di standard web
• si propone per una consulenza sull’adozione degli standard web
• si offre di convertire il vostro sito (brutto, retrò, sbagliato), in uno migliore (bello, standard, accessibile)
• ha partecipato alla stesura di uno standard web
• ha un sito di poche pagine (e purtroppo solo quello), realizzato in modo conforme agli standard, e lo usa come pretesto per diffondere il verbo degli standard web

Non solo: con tutta probabilità questo signore poco ne capisce della complessità di un progetto web, poiché ha visione solo di una parte, il suo lavoro: creare pagine Html.
Come potete ben immaginare la sua opinione, per quanto del tutto rispettabile e in certi termini condivisibile, è superficiale. Non c’è nulla di male nel promuoversi al ruolo di esperto nel campo degli standard, ma la realtà con cui si confronta chi realizza siti web è più complessa di quello che normalmente si crede.

Gli standard web sono una buona cosa, ma la loro adozione deve essere attentamente valutata, così da capirne l’impatto e i benefici che possono introdurre. Non solo, ogni sito è un caso a parte: lo standard che ben si presta in un’occasione, potrebbe introdurre benefici ridicoli in un’altra, tanto da sconsigliarne l’uso.

È comodo tifare per chi vuole adottare gli standard web a tutti i costi, ma non stiamo guardando una partita di calcio, stiamo lavorando.

Capita spesso di incontrare siti in cui l’autore si diverte a convertire siti esistenti non standard in versioni Xhtml e Css, così da dimostrare ai più scettici che è possibile non solo ottenere lo stesso risultato con gli standard, ma addirittura migliorarlo. L’esercizio è molto utile ai fini didattici, ma è un esercizio. In realtà queste operazioni, che molte volte interessano solo la home page, sono del tutto fuorvianti.

Come vedremo tra poco, la pagina che vedete sul vostro browser è il risultato di un numero a volte elevato di processi e trasformazioni. Fermarsi ad analizzare solo l’ultimo passo, quello che interessa il browser, è indice di miopia. Alcuni dei siti che notiamo non essere standard non lo sono per ignoranza, ma per le difficoltà (inclusi tempi e costi) incontrate nel modificare parti del sito che si trovano ben più a monte rispetto alla pagina che riceve il browser. Non è solo un problema di Html.

Un mezzo, non un obiettivo

Gli standard web non sono un santo a cui votarsi, non si presta opera di fede incondizionata senza aspettarsi un ritorno pratico e immediato, che abbiamo definito essere una maggiore produttività unita a un livello qualitativo adeguato. Adottare i più disparati standard web solo per fregiarsene a piè di pagina rischia non solo di essere pacchiano, ma addirittura controproducente.

In dipendenza del tipo di sito da realizzare, infatti, alcuni standard sono più adatti di altri. Per questo motivo è anche inutile proporre sterili liste congratulandosi con i siti che hanno compiuto il grande passo, da sito a tabella con codice non standard a foglio di stile per il layout e codice standard compliant. Ogni sito è diverso, l’equazione “sito costruito secondo gli standard = sito migliore” non funziona, ma va analizzata caso per caso.

È inoltre fuori discussione che l’utilizzo gli standard web nella costruzione di un sito può aiutare a migliorarne l’accessibilità e l’usabilità. Ma si tratta di una condizione che non è né necessaria, né sufficiente. Posso infatti creare un sito completamente aderente agli standard, ma frustrante per chi lo utilizza e tutt’altro che accessibile, come posso realizzare un sito a tabelle realmente usabile e accessibile.

Se il vostro obiettivo è costruire un sito usabile o accessibile state quindi attenti: rischiate di gettarvi a capofitto nella codifica del sito quanto il vostro problema sta a monte. Non solo, tenete presente che come abbiamo avuto modo di dire in altra sede, l’accessibilità di un sito ha un ciclo di vita che comincia con l’analisi dei requisiti.

Quali standard usare

Abbiamo detto che gli standard non sono ricette preconfezionate da consumare sempre e ovunque. La scelta degli standard da adottare è invece il frutto di un’attenta analisi, e dipende da numerosi fattori:

• Dipende dagli obiettivi
  • Quali sono gli obiettivi aziendali e quelli degli utenti? Esistono degli standard che possono aiutare ad incontrare queste aspettative?
  • Quali benefici possono portare questi standard nell’immediato?
  • Quali benefici possono portare questi standard nel medio/lungo periodo?
• Dipende dai limiti
  • Il tempo (e quindi il costo) necessario per utilizzare lo standard
  • Le controindicazioni e i compromessi nell’adottare lo standard (funzionalità che si vengono a perdere o modificare)
  • Limiti della tecnologia
    • Sistemi automatici o semiautomatici (es. Cms) che non producono codice standard
    • Parti del sito che non sono in nostro controllo (es. Banner), e che quindi potrebbero non essere standard-compliant
  • Limiti del contenuto, come contenuti pregressi da convertire
• Dipende dal tipo di sito
  • Sito web
  • Applicazione web

Tutt’altro che impiegare una scatola chiusa, quindi. Da questo elenco è facile capire come la decisione se e come adottare uno standard web non riguarda necessariamente (anzi, quasi mai) solo chi si occupa di realizzare il template delle pagine (Html e Css), ma coinvolge l’intero team di sviluppo. Ecco perché la bontà di un sito web riguardo l’aderenza agli standard non può mai essere valutata “a distanza”, se non in casi idilliaci.

Prendere e criticare un sito web senza conoscerne le complessità e peculiarità è senza dubbio comodo, ma non aiuta chi l’ha realizzato a migliorarlo. Il numero di fattori che influenzano la scelta può infatti essere di tale portata che quello che si vede “sullo schermo” non è sufficiente per esprimersi in una critica costruttiva.

Nell’ultimo punto della lista si parla di differenza tra sito web e applicazione web. Cosa vuol dire, o meglio, cosa intendiamo per sito e applicazione web?

Per lo scopo di questa discussione un sito web è un insieme di pagine realizzate da una persona o da un piccolissimo team di persone, ognuna con competenze che spaziano dalla realizzazioni di pagine Html alla programmazione (senza raggiungere livelli estrema). Il risultato è solitamente un sito di modeste dimensioni, con nessun aggancio ad altre realtà (Cms, applicazioni legacy, database, ecc.). In questa categoria, come dicevamo all’inizio, rientrano i siti vetrina.

Un’applicazione web è invece, alla stregua di un programma per computer, un prodotto di ingegneria. In questo caso la distinzione tra le competenze del team di sviluppo è più marcata (ma non netta, questo non lo deve mai essere). In questo caso, più che per pagine, si ragiona per template. Ogni template può produrre più pagine con lo stesso look & feel, ma dal contenuto anche profondamente diverso. Generalmente, ma non è una regola, un’applicazione web è composta da un sito dinamico (collegato ad un database) e ad un certo numero di moduli (community, ecommerce, ricerche) sviluppati come veri e propri prodotti software. In questo caso il browser che riceve la pagina è l’appendice di tutto il processo dell’applicativo. È un po’ come un iceberg: quello che spunta dall’acqua è quello che vede il browser: una piccolissima parte di quella che in realtà è tutta l’applicazione.

Va notato come non usiamo il termine sito “statico” in paragone a “dinamico”, in quanto l’enfasi non è sul risultato del lavoro (posso avere siti complessi e statici, e siti composti di due pagine dinamici), ma sulle competenze richieste per portarlo a compimento e soprattutto sulla complessità del progetto.

In che modo l’adozione degli standard viene influenzata dal tipo di progetto (applicazione o sito web) che intendiamo realizzare? In realtà, più complesso e spaziato è il progetto che andiamo a realizzare, più ampia è la rosa degli standard che possiamo impiegare. Non solo, all’aumentare della complessità del progetto, si riduce il peso che il browser ha all’interno di tutta l’applicazione.

Attenzione: questo non vuol dire che possiamo inviare al browser pagine non standard, senza preoccuparci della resa visiva, tutt’altro. Vuol però dire che la trasformazione e presentazione dei contenuti non deve per forza di cose avvenire sempre e comunque lato browser, ma può essere realizzata a monte ricorrendo ad altri standard, che hanno il pregio di essere completamente slegati dalla periferica di output, e generalmente più potenti.

Non credete a chi vi dice che le stesse operazioni possono essere compiute dal browser, che non ha senso caricare inutilmente i server per problemi di prestazioni: l’hardware non è quasi mai un problema. Probabilmente chi si rifiuta di sfruttare la potenza dei server semplicemente non lo sa fare.

Gli standard caso per caso

Può sembrare strano, ma anche l’efficacia di uno standard varia in relazione al contesto nel quale viene applicato. Vediamo in che modo con un paio di esempi.

Il sito vetrina di un’azienda di abbigliamento sportivo

Immaginate di essere coinvolti nello sviluppo di un sito vetrina, con alcune pagine di presentazione di un’azienda e un elenco prodotti rivolti al pubblico giovanile.

Una tra le possibili soluzioni è quella di impiegare Xhtml Strict per la codifica delle pagine e i Css per la costruzione dell’intero sito. La scelta è condivisibile. Benché esistano dei limiti alla soluzione, questi sono facilmente superabili, mentre i vantaggi sono evidenti:

• separare lo strato di presentazione dal contenuto, così da consentire in futuro il recupero del contenuto senza dover intervenire manualmente
• rendere più facile e immediata la modifica del layout (come spostare velocemente le barre di menù e la navigazione
• possibilità di inviare lo stesso contenuto a dispositivi diversi (come personal computer,cellulari e palmari)
• coerenza visiva delle diverse sezioni del sito
• diminuire il peso della pagina

Il sito di una rivista online

Immaginate adesso di dover realizzare un sito per un’importante rivista, dove sono caricati giornalmente 20 articoli. Sono inoltre presenti una vetrina per abbonarsi e un’area di community precedentemente utilizzati per un’altra rivista del gruppo.

Non pretendiamo che da soli siate in grado di realizzare tutto il sito, quello che è interessante capire è che in questo caso la realizzazione delle pagine è solo una parte (per quanto importante) dell’intero processo.

Se cominciate subito a realizzare template Xhtml, fogli stile e menù di navigazione non siete sulla buona strada. In realtà quello che avete bisogno di capire è che cosa avete a disposizione per lavorare, cercando di capire:

• da dove saranno prelevati i contenuti
• in che formato sono
• a quali piattaforme si rivolge il sito (computer, palmari, ecc.)
• quali devono essere le funzionalità degli altri servizi

Anche per un sito statico avete bisogno di sapere queste cose, ma in questo secondo caso la produzione dei contenuti entra a pieno titolo nel processo di realizzazione del sito web, e dovete conoscere perfettamente il suo funzionamento.

Per questo secondo progetto potremmo decidere di comportarci in modo diverso rispetto al sito vetrina, e infatti codifichiamo il sito utilizzando Xhtml transitional per le pagine e i fogli di stile unicamente per i caratteri, i colori e i margini.

Potremmo pensare che abbiamo agito in modo non corretto: perché non usare i Css anche per il posizionamento, dopo tutti i vantaggi che abbiamo elencato e visto che la costruzione del sito parte da zero?

La scelta non è legata ai problemi di compatibilità dei fogli di stile: questi infatti sono normalmente visualizzati con molti limiti nei browser non recenti. In effetti, trattandosi di business, l’azienda che ha commissionato il sito vorrebbe mantenere il bacino di utenza il più ampio possibile. Però ripetiamo: questa non è la causa della nostra decisione.

Per capire il perché di questa scelta, analizziamo come avverrà il processo di pubblicazione del sito. I redattori utilizzano un sistema di gestione dei contenuti (Cms) che gli consente di redigere gli articoli da pubblicare, inserendo non solo il corpo, ma il titolo, sommario, occhiello, le foto, riferimenti ad articoli correlati, ecc. Gli articoli sono memorizzati in un database in un formato Xml.

Ecco che siamo giunti al cuore della questione: esiste uno standard non legato direttamente al sito e che viene utilizzato per memorizzare le informazioni da pubblicare. Questa informazione è a fondamentale per capire quali standard utilizzare per strutturare il sito.

D’accordo con il team di sviluppo software, la soluzione proposta è la seguente:

• realizzare i template in formato Xhtml, suddividendo le pagine in diverse parti a seconda delle esigenze
• i menù e le barre di navigazione saranno realizzati in parte autonomamente, in parte manualmente secondo necessità, e la redazione sarà in grado con pochi clic di spostarli da una parte all’altra dello schermo
• trasformare i template Xhtml in documenti Xslt, che verranno usati per trasformare il dato Xml dell’articolo nella pagina da inviare

In questa nuova ottica, sono anche ridimensionati i vantaggi della soluzione adottata per il sito vetrina. Rivediamoli sotto questa nuova luce:

separazione lo strato di presentazione dal contenuto

Separare la presentazione dal contenuto rende più semplice la manutenzione della pagina. Ma il vero problema è: dove finisce il contenuto e dove comincia lo strato di presentazione? Nel caso più semplice, quello precedente, il contenuto era rappresentato dalla pagina Xhtml e la presentazione dal file Css. In questo secondo caso, però, la visuale è cambiata. Tutti i contenuti provengono da un sistema per la gestione dei contenuti (Cms).

La presentazione è ora data dal template, che verrà opportunamente riempito dai dati provenienti dal database. Vi ricordate il discorso che facevamo poco fa a proposito dell’iceberg? In questo secondo caso potremmo dire che per noi lo strato di presentazione è l’intero flusso diretto al browser, mentre il contenuto è quanto presente nel database. Nel database e nel formato Xml lo strato di presentazione è già totalmente separato dal contenuto, tanto che lo stesso articolo potrebbe finire non solo nel sito, ma anche sulle pagine cartacee della rivista.

personalizzazione del look & feel per l’utente

Con i Css è possibile aiutare l’utente a modificare velocemente la presentazione del sito. Nel primo caso questo si spinge fino al posizionamento, mentre nel sito della rivista esiste comunque la possibilità di modificare font, colori e margini. Questo non vuol però dire che i redattori non abbiano questa possibilità: per come sono stati strutturati i template, infatti, la personalizzazione avviene interamente utilizzando il sistema di pubblicazione, tanto che i componenti possono essere in qualunque posizione, possono essere comuni a tutto il sito, oppure solo ad una sezione, senza intervenire minimamente sul codice. E utilizzando delle trasformazioni Xsl, anche cambiare il layout è estremamente semplice.

possibilità di inviare lo stesso contenuto a dispositivi diversi

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.

coerenza delle diverse sezioni del sito

I Css sono lo strumento migliore per garantire una coerenza visiva all’interno del sito. Anche l’attenta creazione di un template a tabella può però produrre gli stessi risultati. Se la pagina è ben definita e studiata, ad esempio, è possibile suddividerla in più porzioni (include) indipendenti l’una dall’altra, tenute insieme da una semplice struttura a tabella. Il vantaggio di questa soluzione è duplice:

• la modifica a un include si ripercuote su tutto il sito
• il team di sviluppo può suddividersi le parti di lavoro (include di ricerca, menù, contenuto, ecc.)

diminuire il peso della pagina

Qui c’è poco da fare: se usate correttamente ed efficacemente i fogli di stile per il posizionamento degli elementi, il peso della pagina è sicuramente minore rispetto al corrispettivo in tabella. Usare i Css per il testo e il colore partecipa a rendere la pagina più leggere, ma il risultato non sarà comunque paragonabile. Attenzione però a non legare il peso della pagina con la velocità di visualizzazione nel dispositivo ricevente: i due elementi sono correlati, ma un sito ben realizzato può essere percepito come veloce anche se il peso della pagina è elevato.

A queste considerazioni va anche aggiunto che la gestione dei fogli di stile da parte degli odierni browser è deficitaria, tanto da richiedere accorgimenti e trucchi anche nei casi di template mediamente complessi. Questo non vuol dire che va scoraggiato l’uso dei fogli di stile per il posizionamento (anche perché le sorprese tra diversi browser non manca neppure nei layout a tabella), ma che nel caso di siti di alta complessità, la prima preoccupazione dev’essere quella di memorizzare correttamente l’informazione da produrre. Fatto questo, possiamo presentare questa informazione a chiunque intervenendo semplicemente nei fogli di trasformazione. Il che vuol anche dire che domani, quando uscirà la versione 8 delle specifiche per i Css o di Xhtml, saremmo pronti ad usarli con poco sforzo.

Quello che abbiamo visto è solo un esempio, che prende in esame i fogli di stile e lo standard Xhtml. In realtà la stessa situazione sarebbe replicabile in altri ambiti con le stesse conclusioni: prima di applicare uno standard è bene conoscere le realtà nel suo complesso.

Conclusione

Chi realizza pagine web non lavora in solitaria. Le soluzioni che propone, non solo dal punto di vista grafico, ma anche di standard adottati, dipendono dal contesto nel quale opera. Con due semplici esempi abbiamo visto come l’impiego degli standard web vada attentamente valutato in base al sistema di produzione dei contenuti, nonché dell’audience e delle aspettative degli utenti.

Progettare e costruire un sito accessibile prevede il rispetto di alcune linee guida e la verifica dei risultati ottenuti con screen reader, browser e browser di testo.

Purtroppo, il supporto dei browser ai tag e agli attributi accessibili è vario e alquanto carente. Anche se una persona disabile usa probabilmente un software dedicato, una maggiore aderenza agli standard è sicuramente auspicabile, così da evitare allo sviluppatore di ricorrere a soluzioni “ad interim”.

Per i test sono prese in esame le piattaforme:

• Windows 2000
  • Internet Explorer 5
  • Internet Explorer 5.5
  • Internet Explorer 6
  • Netscape 4.7
  • Netscape 6.2
  • Netscape 7.0 pr1
  • Mozilla 1.0
  • Opera 5
  • Opera 6
• Mac Os 9.1
  • Internet Explorer 5
  • Netscape 4.7
  • Netscape 6.2
  • Mozilla 1.0
  • iCab 2.8
  • Opera 5

Una pagina per il test di “conformità”

Abbiamo realizzato una semplice pagina di test contenente i tag normalmente usati per migliorare l’accessibilità di un documento Html.

Nella pagina sono presenti:

• un menu realizzato come link ipertestuali, ognuno dei quali raggiungibile con scorciatoia da tastiera (in particolare con 1,2,3) e con un ordine di tabulazione dato dall’attributo tabindex
• una form per un’iscrizione fittizia, che utilizza:
  • il tag fieldset e il tag legend per raggruppare elementi della form concettualmente simili
  • il tag label per associare esplicitamente un’etichetta al campo della form
  • l’attributo tabindex per modificare l’ordine di tabulazione all’interno dei campi
  • un tag optgroup utilizzato, all’interno di una combo-box, per raggruppare gli elementi in sottocategorie
• una lista di acronimi realizzati con il tag acronym
• una serie di abbreviazioni con il tag abbr
• una tabella che sfrutta i tag th, caption e l’attributo summary
• una image map che utilizza l’attributo alt
• una image map che utilizza l’attributo title
• una immagine con una descrizione estesa riferita dall’attributo longdesc
• l’attributo title inserito in un link
• l’attributo title inserito in un’immagine

I risultati del test

I risultati della pagina sono molto vari tra le diverse piattaforme.

Netscape 4.7

Data l’età, il supporto di Netscape 4.7 è piuttosto scadente:

• non sono riconosciuti i tag fieldset e legend delle form
• non sono raggruppati gli elementi della combo-box
• non è possibile utilizzare i tasti di scelta rapida e nemmeno l’ordine di tabulazione
• sono ignorati gli attributi title per i link e le immagini
• non sono visualizzate le abbrevazioni e gli acronimi
• sono visualizzati gli attributi alt nelle immagini, ma non nelle image map

Netscape 6+ / Mozilla

Con Netscape 6+ e Mozilla le cose migliorano sensibilmente: sono riconosciuti correttamente molti tag ed attributi.

I limiti principali di questa versione rimangono:

• mancata visualizzazione degli alt nelle image map (ma non del tag title)
• scadente gestione delle tabulazioni all’interno della pagina: è vero che l’attributo tabindex viene correttamente riconosciuto, ma procedendo con la tabulazione il browser non scrolla la pagina per posizionarsi sugli elementi non a video

Molto buona la gestione degli acronimi e delle abbreviazioni, che compaiono come parole sottolineate, delle virgolette (tag q) e del tag optgroup, visualizzato come intestazione agli elementi.

Cominciano timidamente a farsi vedere gli attributi longdesc, anche se per visualizzare la pagina è necessario posizionarsi sull’immagine, scegliere “Proprietà” dal menù contestuale e cliccare sul link della descrizione.

Internet Explorer Windows

Anche Internet Explorer 5+ ha un buon supporto per l’accessibilità, anche se in alcuni punti (come gli acronimi), potrebbe essere migliorato, per esempio sottolineando le voci, come fa Netscape. Dalla versione 6 Windows anche il tag optgroup per raggruppare gli elementi di una combo-box è interpretato correttamente.

Internet Explorer Macintosh

Anche la versione 5 Mac gestisce optgroup, ed è forse il browser che visualizza i gruppi nel modo più efficace.

Opera

Opera, in entrambe le versioni provate, non ha brillato per il suo riconoscimento dei tag accessibili. Solo con la versione 6 si comincia a vedere qualche timido miglioramento, soprattutto nelle form.

iCab

iCab per Macintosh include un’interessante opzione: visualizza tra parentesi i tasti di scelta rapida (accesskey) per le scorciatoie da tastiera.

È inoltre possibile richiedere, dal menu contestuale, l’apertura in una nuova finestra del file assegnato ad un’immagine con l’attributo longdesc, un po’ più rapidamente che in Netscape.

Tabelle riassuntive

Segue una serie di tabelle con i dettagli del test.

Non è presentata una scheda riepilogativa con il supporto alle tabelle accessibili in quanto tutti i browser provati visualizzano correttamente i tag.

Se riesci a provare la pagina di esempio con un browser e una piattaforma non presente nella lista (ad esempio Linux), contattaci così che possiamo includere i risultati della tua prova e creare un elenco più completo, a disposizione di tutti.

Form

Nella tabella è evidenziato il supporto dei browser ai tag fieldset e optgroup che consentono di raggruppare rispettivamente i campi di una form e gli elementi di una combo-box.

È anche evidenziata la possibilità o meno di muoversi correttamente nelle form utilizzando il tabulatore secondo l’ordine definito dall’attributo tabindex.

Nota: Netscape 6+ e Mozilla gestiscono l’attributo tabindex, però hanno qualche difficoltà nel visualizzare l’oggetto che ha il “fuoco” fuori della parte visibile dello schermo.

Una curiosa particolarità: mentre Internet Explorer considera i radio button come una sola entità quando si usa il tabulatore, Netscape 6+ e Mozilla distinguono ognuna delle opzioni del controllo.

Testo

I tag Html offrono la possibilità di arricchire il testo con abbreviazioni, acronimi, citazioni, che dovrebbero essere interpretate dal browser. Nella tabella, “virgolette” si riferisce al supporto del tag q, mentre citazioni indica il tag blockquote.

Nota: Internet Explorer visualizza correttamente gli acronimi. A differenza di Netscape e Mozilla, però, non dà indicazioni sulla presenza dell’acronimo, per esempio sottolineandolo, rendendo così difficile il suo riconoscimento. È comunque possibile utilizzare delle regole Css per simulare il comportamento di Netscape. La stessa cosa vale per Opera, che in più visualizza anche le abbreviazioni.

Link

È possibile estendere le informazioni dei link con l’attributo title. Inoltre, è prevista dall’Html la possibilità di introdurre delle scorciatoie da tastiera e di navigare i link con il tabulatore.

Immagini

Anche per le immagini è possibile utilizzare l’attributo title, mentre invece l’attributo longdesc consente di collegare una pagina di dettaglio dell’immagine.

Nota: la gestione dell’attributo longdesc è ancora un po’ troppo precaria e complessa in Netscape 6+ e Mozilla per considerarla definitiva.

Image Maps

Sia l’immagine sia le aree della mappa consentono di specificare l’attributo alt, anche se questa seconda possibilità non viene visualizzata sullo schermo quando si disabilitano le immagini. Sarebbe utile riuscire a vedere i contorni delle area anche quando l’immagine non viene caricata, e trovare all’interno le descrizioni alternative.

Bobby è disponibile in una versione gratuita (per il momento ancora la versione 4) utilizzabile online e una versione desktop (venduta a 299 dollari, 199 per chi la acquista entro il 7 Maggio 2003), arricchita di funzionalità, di cui ci occuperemo.

Come ben sanno i lettori del nostro corso di accessibilità web, è impossibile per un software evidenziare nel modo corretto tutte le problematiche relative all’accessibilità, dal momento che molte dipendono da fattori (chiarezza del linguaggio, utilizzo sensato del markup) non misurabili.

L’utilizzo di questi strumenti è comunque utile per “scremare il grosso” degli errori di accessibilità, spianando così la strada all’intervento umano.

State comunque sempre attenti: se da un lato un software può non rilevare problematiche esistenti, dall’altro (complici le carenze delle linee guida Wai) potrebbe intestardirsi nel sottolineare errori che sono in realtà di poco conto.

Detto questo, analizziamo alcune significative caratteristiche di questa versione.

Niente più Java

Uno dei limiti della precedente versione di Bobby era dato dal peso dell’applicativo, costruito interamente in Java.

Questa versione di Bobby è completamente nativa Windows, rendendo più agevole e veloce l’uso e la personalizzazione dell’interfaccia grafica.

Interfaccia grafica che è stata completamente riveduta ed è ora più semplice da usare, anche se poteva essere fatto qualche sforzo in più per organizzare organicamente le diverse funzioni del programma.

Verifiche veloci e puntuali sia online, sia offline

La principale differenza rispetto alla versione precedente è la possibilità di configurare con precisione il sito (o i siti) da analizzare. Non solo è possibile definire il punto di partenza e lasciare a Bobby l’ingrato compito di seguire i link delle pagine ad esso collegati, ma possiamo specificarne la profondità, ed eventualmente i documenti da escludere.

E’ possibile analizzare sia siti online, sia offline. Nel primo caso basta semplicemente inserire l’Url di partenza, e Bobby si occupa di interrogare e scaricare le pagine dal server.

Nel caso si voglia invece analizzare un sito locale, è possibile specificare anche la directory di partenza del sito, in modo che link del tipo <a href=”/percorso/”> vengano risolti correttamente.

Alcune opzioni avanzate consentono inoltre di interagire con siti protetti da password, siti che completano la QueryString con riferimenti alla sessione (e che vanno tolti, per evitare a Bobby di analizzare più volte la stessa pagina), siti distribuiti su più domini.

Test personalizzati

Un’importante caratteristica di Bobby 5.0 è data dalla possibilità di scegliere il tipo o il numero di linee guida da verificare per il proprio sito.

Questo non vuol dire semplicemente scegliere tra Wai A,AA,AAA e Section 508, ma scegliere puntualmente quali utilizzare e quali no.

E’ un’utile funzione, soprattutto considerando le carenze di alcune linee guida.

Risultati simili alla versione precedente

Chi si aspettava un miglioramento nella capacità di rilevare problematiche inerenti l’accessibilità potrebbe rimanere deluso. I risultati della versione 5 sono infatti pressoché identici a quella precedente. Nulla di cui stupirsi comunque: il problema è che alcune linee guida non possono essere verificate via software; per tutte le altre, già la versione 4 di Bobby svolgeva un ottimo lavoro.

L’unica differenza è che questa versione dello strumento, che è più efficiente nello scovare Url non collegati direttamente ad una pagina (ad esempio in un’istruzione Javascript, in un’animazione Flash o in una form), potrebbe trovare errori prima non raggiungibili.

Report completi

La qualità dei report è stata migliorata e organizzata, come dimostra una prova che abbiamo realizzato. L’unica nota negativa è che non sembra essere possibile passare agevolmente dai report Wai A ad AA, AAA o Section 508 senza ripetere l’analisi del sito, anche se il manuale recita il contrario. Notevole la mancanza di un’opzione di salvataggio o di stampa, a cui si può ovviare agendo con il pulsante destro del mouse all’interno della pagina, che altro non è se non una finestra del browser.

Manuale in Pdf

La versione desktop è accompagnata da un comodo manuale in formato Pdf, che avrebbe però potuto presentare qualche esempio concreto oltre ad una sterile lista di operazioni.

Conclusioni

La versione 5 di Bobby, dal punto di vista dell’organizzazione dell’interfaccia e delle opzioni disponibili, compie notevoli passi avanti. La caratteristica più importante, e cioè la capacità di aiutare nel costruire un sito accessibile, è