All’estero sono più bravi

All’estero sono più bravi. O almeno così la pensano molti clienti italiani alla prese con un progetto web. Clienti che preferiscono rivolgersi fuori dai confini e molto spesso fuori Europa in cerca di una qualità che le nostre agenzie non sembrano garantire.

Chissà se questo è uno dei motivi che hanno spinto la redazione di Internazionale a richiedere la progettazione del proprio sito a Information Architects, nota web agency con sede a Tokyo e specializzata in progetti editoriali, soprattutto tedeschi e svizzeri.

Sono abbonato al settimanale Internazionale da più di 10 anni, sbircio impaziente la cassetta delle lettere ogni venerdì e non ho perso un Festival a Ferrara: non penso ci sia bisogno di aggiungere altro riguardo la considerazione che ho per questa rivista.

Però ogni volta che mi capita di visitare internazionale.it mi meraviglio di quanta poca cura sia stata posta all’interfaccia, anche se non sono sicuro se sia un limite della progettazione di Information Architects o di qualcuno che è intervenuto a posteriori.

Sarà che di siti editoriali ne ho visti parecchi (dal 2000 al 2006 ho progettato e gestito i siti dei periodici del gruppo Mondadori), ma il risultato che vedo sarebbe stato alla portata di molte agenzie italiane, anche non di prim’ordine.

Qualche settimana fa mi sono ricavato un’ora per compilare un documento in cui ho raccolto alcune delle problematiche più significative del sito e l’ho inviato alla redazione.

Non mi aspettavo una risposta, che infatti non è arrivata: mi interessava ricavarne un’occasione per parlarne qui.

Vi invito allora a scaricare il documento pdf [4 Mbyte] in cui ho raccolto alcune evidenze: spero possa essere utile per capire come svolgere in poco tempo una prima e non scientifica valutazione dell’usabilità di un sito. Sono convinto che spendendoci un po’ più di tempo, magari insieme a qualche collega, il numero di problematiche salirebbe significativamente.

È fuori discussione che ogni azienda possa spendere i propri soldi come meglio crede, ma è un peccato che il sito web di Internazionale non rispecchi la stessa cura e qualità della rivista cartacea.

italia.it e le bugie sull’accessibilità

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?

Accessibilità web in Italia e nel mondo

Questo articolo fa parte di un corso gratuito di accessibilità web ospitato su questo sito.

Garantire l’accessibilità web, lo abbiamo detto più volte, non è solo una questione di software. Non esistono strumenti totalmente automatici che verifichino le pagine e ne correggano tutti i problemi di accessibilità.

Le linee guida facilitano comunque la verifica e la correzione delle pagine da parte di tutte le figure professionali coinvolte nella costruzione di un sito accessibile.

Le più importanti linee guida oggi disponibili sono:

Altre linee guida sono state realizzate da aziende software, tra le quali ricordiamo le
Ibm Web Accessibility Checklist [nuova finestra]

Web Content Accessibility Guidelines

È uno dei tre tipi di linee guida rilasciati dalla Wai e si preoccupa di definire uno standard per la costruzione di pagine web che siano accessibili nella loro struttura e nel loro contenuto.

Le altre linee guida realizzate dal Wai sono:

Il documento è suddiviso in 14 linee guida, di cui riportiamo una libera traduzione in italiano:

  1. Fornire alternative equivalenti al contenuto audio e visivo
  2. Non fare affidamento sul solo colore
  3. Usare marcatori e fogli di stile e farlo in modo appropriato
  4. Evidenziare il passaggio da una lingua ad un’altra
  5. Creare tabelle che degradino in modo efficace
  6. Assicurarsi che le pagine con nuove tecnologie degradino in modo efficace
  7. Assicurarsi che l’utente possa tenere sotto controllo i cambiamenti di contenuto con il passare del tempo
  8. Assicurare che le interfacce di programmi incorporati mantengano alto il livello di accessibilità
  9. Progettare per garantire l’indipendenza da dispositivo
  10. Usare soluzioni ad interim
  11. Usare le tecnologie e le raccomandazioni del W3c
  12. Fornire informazioni per la contestualizzazione e l’orientamento
  13. Fornire chiari meccanismi di navigazione
  14. Assicurarsi che i documenti siano scritti in modo chiaro e semplice

Accanto alle linee guida, sono disponibili altri documenti Wai che ne approfondiscono l’uso:

Le linee guide sono suddivise in punti (checkpoint), a loro volta raggruppati in 3 categorie di priorità:

  • Priorità 1: l’adozione di questo punto deve essere garantita da tutti gli sviluppatori, pena l’inaccessibilità del documento
  • Priorità 2: l’adozione di questo punto dovrebbe essere garantita da tutti gli sviluppatori, pena difficoltà nell’accedere al documento
  • Priorità 3: l’adozione di questo punto è consigliata, poiché alcune tipologie di utenti potrebbero trovare difficoltà nell’accedere al documento

Il numero del checkpoint segue quello della linea guida ed è separato da un punto. 1.4, ad esempio, indica il checkpoint 4 della linea guida 1.

Le linee guida del W3c sono alla base della Section 508 e di quasi tutte le proposte per la realizzazione di documenti accessibili.

La critica che spesso viene rivolta a queste linee guida è che non sembra facile riuscire ad applicarle tutte insieme, cioé i checkpoint di livello 1,2 e 3.

In particolare, garantire una visualizzazione corretta ad un vasto pubblico, ma utilizzare i fogli di stile anche per il layout della pagina sono due esigenze all’oggi inconciliabili. Difficile quindi costruire un sito accattivante e con un buon numero di pagine che riesca a tenere conto di tutte le esigenze delle linee guida, anche se nel medio periodo la penetrazione dei browser versione 5+ non può che favorire questa situazione.

Le Wcag sono in fase di attenta revisione e per rendersene conto è possibile dare un’occhiata ad una proposta di riorganizzazione [nuova finestra].

Section 508

Sono state pubblicate dall’US Access Board nel 2000 e coprono diversi aspetti dell’accessibilità in ambito informatico, non solo nel web.

Tutti i siti creati o gestiti per conto del governo americano devono soddisfare i requisiti di queste linee guida.

Sono basate sulle Wcag 1.0 del W3c e ne presentiamo una libera traduzione in italiano:

  1. Per ogni elemento di testo deve essere previsto un equivalente testuale (usando “alt”, “longdesc”, ecc.)
  2. Il contenuto alternativo ad ogni presentazione multimediale deve essere sincronizzato con la presentazione
  3. Le pagine web devono essere progettate perché tutte le informazioni portate dal colore siano disponibili anche senza colore, per esempio dal contesto o dalla marcatura
  4. I documenti dovrebbero essere realizzati in modo da essere fruibili anche senza il foglio di stile associato
  5. È necessario includere link di testo ridondanti per ogni regione attiva di un’image map server-side
  6. Dopo possibile è necessario usare image map di tipo client-side invece di tipo server-side, a parte dove le regioni non possono essere definite come forma geometrica
  7. Devono essere identificate le colonne e le righe per le tabelle di dati
  8. È necessario usare la marcatura per associare le celle dei dati alle intestazioni delle celle nel caso la tabella contenga due o più livelli di intestazioni di riga o di colonna
  9. Il titolo dei frame deve facilitare l’identificazione e la navigazione dei frame
  10. Le pagine devono essere progettate in modo da evitare allo schermo di lampeggiare con una frequenza maggiore di 2Hz e minore di 55 Hz
  11. Quando la conformità non può essere raggiunta in nessun altro modo è necessario prevedere una pagina di solo testo che contenga le stesse informazioni e le stesse funzionalità. Il contenuto della pagina di solo testo deve essere aggiornato insieme alla pagina principale
  12. Se le pagine utilizzano linguaggi di scripting per visualizzare il contenuto o per creare elementi di interfaccia, l’informazione resa disponibile dallo script deve essere anche disponibile dalla tecnologia in aiuto alle persone disabili
  13. Quando in una pagina web ci sono applet, plug-in o altre applicazioni che vengono eseguite dal client, questi devono essere conformi alla 1194.21(a) fino alla (l) (ovvero, essere a loro volta accessibili)
  14. Una form online deve consentire alle persone che fanno uso di screen reader, software vocali, ecc. di accedere alle informazioni, ai campi e alle funzionalità richieste per il completamento della form, inclusi aiuti e suggerimenti
  15. L’utente deve poter saltare i link di navigazione persistente
  16. Quando è necessaria una risposta entro un certo lasso di tempo, l’utente deve essere avvertito e gli deve essere concesso sufficiente tempo per completare il compito

Differenze tra Wcag e Section 508

Impossibile ignorare una profonda somiglianza tra le linee guida Wcag e Section 508, fatto normale considerato che le Section 508 si basano sulle specifiche del Wai.

Quasi tutti i checkpoint uno sono presenti nella Section 508, ad eccezione di:

  • Fino a quando i browser non saranno in grado di leggere il testo di trascrizione di un video, è necessario includere anche una versione audio (1.3)
  • È necessario identificare i cambiamenti di lingua nel testo (4.1)
  • Assicurare che il contenuto alternativo a quello dinamico sia aggiornato insieme a quest’ultimo (6.2)
  • Usare un linguaggio semplice e appropriato per il contenuto del sito (14.1)

Alcune linee guida della Section 508 sono in corrispondenza con i checkpoint di priorità 2 e 3.

In generale non esistono sostanziali differenze, se non per il fatto che alcuni checkpoint Wcag di priorità 2 e 3 sono “premiati” nella Section 508.

Per un’approfondita analisi delle differenze tra le due serie di linee guida vi suggeriamo la lettura di un articolo [nuova finestra] scritto da Jim Thatcher, autore di Constructing Accessible Web Sites.

La situazione in Italia

Una circolare firmata dal ministro Bassanini nel Marzo del 2001 pone l’accento sui requisiti di usabilità ed accessibilità per i siti delle pubbliche amministrazioni. Il documento [nuova finestra] indica come riferimento primario le linee guida del W3c.

A seguito del documento, Aipa ha prodotto una circolare [nuova finestra] per chiarire gli strumenti e i metodi a disposizione per migliorare l’accessibilità web. Si tratta di una riscrittura e in qualche caso di un approfondimento alle linee guida del W3c, ed è incluso anche qualche parametro quantitativo per misurare l’accessibilità, come i browser da usare per valutare il grado di accessibilità di un documento.

Siamo comunque ancora in una fase in cui sono fornite indicazioni di massima su come includere le politiche di accessibilità nel proprio sito. Basta navigare i siti delle pubbliche amministrazioni per rendersi conto che c’è ancora molta strada da compiere. Nei casi più fortunati sono state predisposte delle versioni alternative accessibili dei siti, come è accaduto per la Camera dei Deputati [nuova finestra].

Quale standard usare?

Come abbiamo visto, la scelta tra le Section 508 e le Wcag è sostanzialmente equivalente. Ricordate comunque che il vostro unico metro di giudizio sarà il test finale al quale sottoporre ogni pagina del sito per verificarne l’accessibilità.

Un test, come vedremo più avanti, non ha l’unico scopo di verificare la conformità del codice scritto, ma anche il livello di efficacia dell’interfaccia grafica del sito, nonché lo stile di scrittura, che nel web dev’essere particolarmente diretto e facilmente scansionabile.

Nel corso dei nostri esempi cercheremo di soddisfare sia le Wcag sia la Section 508, senza nascondervi che questo a volte non sarà possibile o non sarà conveniente. Giustificheremo allora le nostre sceltre proponendo delle personali, e come tali sicuramente criticabili, soluzioni.