Appendice – Il decalogo dell’accessibilità

Le Web Content Accessibility Guidelines (WCAG) 1.0 (cfr. par. 2.2) comprendono una serie di documenti, tra cui le Techniques for WCAG 1.0 (http://www.w3.org/TR/WCAG10-TECHS/ (Nota W3C del 6 novembre 2000) che aiutano lo sviluppatore dei siti web a individuare le corrette modalità di presentazione dei contenuti.

Il W3C ha anche reso disponibili dei “QuickTips” (http://www.w3.org/WAI/References/QuickTips/ ), ossia 10 punti di partenza per consentire a chiunque gestisca siti web e/o contenuti per siti web di avere sott’occhio i concetti principali delle WCAG 1.0. È bene far presente che i QuickTips non sostituiscono né le WCAG 1.0 né l’elenco dei punti di controllo (CheckList of Checkpoint for Accessibility Guidelines 1.0) cui si riferiscono i 3 livelli di conformità A, AA, AAA.

Si riportano di seguito i 10 punti, i cosiddetti “10 comandamenti dell’accessibilità dei contenuti”, contestualizzati alle specificità e alle esigenze dell’e-banking.

1 – Immagini e animazioni.

Utilizzare l’attributo ALT per descrivere la funzione di ogni elemento grafico.

Un grave problema di accessibilità è costituito dal mancato utilizzo da parte degli autori di pagine web dell’attributo ALT all’interno dell’elemento <img>. Questo attributo consente di specificare un testo alternativo per le immagini e risulta perciò utilissimo per tutti coloro che – per un qualsiasi motivo – navigano con browser in modalità solo testo o usano tecnologie assistive che utilizzano il testo ALT come descrizione della relativa immagine (https://www.webaccessibile.org/argomenti/argomento.asp?cat=69< /A>).

È necessario specificare che l’attributo ALT è richiesto principalmente per immagini che necessitano di descrizione, mentre per le immagini decorative è inutile inserire descrizioni ma è sufficiente valorizzare come vuoto l’attributo. Per quanto riguarda invece l’uso di immagini animate, come ad esempio immagini intermittenti con scritte del tipo “Novità” o “News”, ne è sconsigliabile l’utilizzo in quanto può essere pericoloso per utenti che soffrono di crisi epilettiche, in special modo se il cambiamento della gif è troppo rapido o non può essere bloccato.

2 – Immagini cliccabili.

Utilizzare l’elemento “map” e descrivere le zone attive.

Le mappe immagine permettono di associare diverse parti di un’immagine a diversi indirizzi (URL). Le mappe immagini hanno una vera e insostituibile ragione di essere laddove il testo non avrebbe potuto fare lo “stesso lavoro con la stessa efficacia”: ne è un esempio il caso in cui l’utente necessiti di fare una selezione da una mappa geografica. Spesso le mappe immagine sono utilizzate anche nei siti bancari per localizzare dei collegamenti (link) a delle operazioni presenti nel sistema in modo visivo: è dunque necessario predisporre le mappe immagine in modo che siano fruibili anche da utenti che – a causa di disabilità – non possono visualizzare l’immagine mappata.

Le soluzioni a questo problema sono principalmente due (utilizzabili anche in maniera complementare): l’utilizzo dell’attributo ALT per gli oggetti definiti come aree sensibili (<area>) e la linearizzazione delle opzioni della mappa con normali link (Un esempio di applicazione di entrambe le modalità è disponibile nella selezione delle province nella mappa presente nel sito IWA http://www.iwa-italy.org/argomento.asp?cat=6 ).

3 – Multimedia.

Fornire sottotitoli e trascrizioni per l’audio, e descrizione di filmati.

L’utilizzo di filmati e audio raramente risulta presente all’interno dei siti di home banking. Ai fini dell’accessibilità è comunque necessario comprendere che eventuali file audio necessitano di una trascrizione (nel caso di utenti non udenti), mentre nel caso di utenti non vedenti per poter fruire dei contenuti visivi di un filmato è necessario applicare delle tecniche del cosiddetto “captioning”, ossia una speciale titolazione che consente di ottenere una lettura descrittiva delle azioni presentate nei filmati.

4 – Link ipertestuali.

Utilizzare enunciati che conservino il loro senso al di fuori del contesto. Per esempio, evitare diciture come «clicca qui».

I testi dei link devono essere chiari anche per utenti che a causa della loro disabilità non possono comprendere dal contesto il significato del testo e/o il riferimento del collegamento ipertestuale. L’utilizzo di testi come “clicca qui” è pertanto scorretto, soprattutto se non accompagnato da un adeguato testo descrittivo per il collegamento ipertestuale, possibile tramite l’attributo TITLE (ad esempio, tipo “Collegamento al documento con maggiori informazioni su …” in un caso di un link che rimanda ad ulteriori dettagli di un prodotto/servizio). Evitare il sovraffollamento di link in una pagina.

5 – Organizzazione.

Utilizzare titoli, liste e una struttura coerente. Utilizzare CSS per l’impaginazione.

Uno dei maggiori difetti dei siti presenti sul web è l’errato utilizzo della sintassi del codice della pagina: un codice HTML/XHTML pulito e valicato (http://validator.w3.org – La validazione dei contenuti avviene in modalità automatica al fine di definire il corretto utilizzo delle sintassi definite dalle raccomandazioni W3C.) secondo gli standard W3C e l’utilizzo dei fogli di stile (CSS) per l’impaginazione grafica dei contenuti sono auspicabili per tutti i siti web professionali.

La logica di navigazione interna al sito deve essere facilmente comprensibile e fruibile dagli utenti, senza possibilità di incomprensioni in fase di esecuzione delle operazioni: se si utilizzano, ad esempio, acronimi e abbreviazioni è necessario chiarirne il significato utilizzando gli elementi <acronym> e <abbr>.

Per gli utenti che utilizzano la navigazione tramite tastiera, è necessario definire in modo corretto le tabulazioni tramite l’attributo TABINDEX in modo che l’utente possa raggiungere comodamente le funzionalità richieste e in modalità cronologicamente corretta.

A livello di impostazione grafica, il W3C consiglia di separare il contenuto dalla presentazione utilizzando i fogli di stile (CSS – http://www.w3.org/TR/CSS2/ -Raccomandazione W3C del 12 maggio 1998). Anche i fogli di stile necessitano di particolari accorgimenti relativamente all’accessibilità, in quanto se si utilizzano ad esempio i caratteri a dimensione fissa (es: 12px) gli utenti ipovedenti non potranno ridimensionare i caratteri e quindi non potranno fruire comodamente dei contenuti. È pertanto necessario impostare i caratteri in dimensioni percentuali (es: 0.8em) ed effettuare un test di navigazione del sito web con risoluzione 640 x 480 oppure 800 x 600 impostando nel browser “caratteri molto grandi”. Per realizzare un sito accessibile è consigliabile evitare di ottimizzare le pagine per una specifica versione di browser o risoluzione video. Se un sito è stato ottimizzato per una risoluzione video 800×600, un utente che ha impostato il proprio monitor a una risoluzione 640×480 deve continuamente agire sulle barre di scorrimento (scrollbar ) del browser per visualizzare tutto il contenuto della pagina.

Occorre inoltre prestare molta attenzione alla scelta dei colori. Bisogna assicurarsi che ci sia un buon contrasto cromatico tra lo sfondo e il testo scritto e tenere presente che persone con diverse disabilità visive visualizzano i colori con tonalità differenti (http://www.diodati.org/scritti/2002/g_colori/index.asp – “Modelli di Rappresentazione del Colore” di Michele Diodati).

6 – Figure e diagrammi.

Descriverli all’interno della pagina o utilizzare l’attributo LONGDESC.

Abbiamo analizzato al punto 1 l’attributo ALT: LONGDESC si differenzia dall’attributo ALT in quanto anziché essere un breve testo alternativo è un collegamento a un documento (file di testo, pagina HTML accessibile) che descrive in modo più specifico un’immagine. A titolo di esempio, nel caso nella sezione di home banking sia presente un grafico di rappresentazione dell’andamento delle azioni acquistate da un cliente, l’attributo ALT dell’immagine sarà “Grafico dell’andamento delle azioni” mentre l’attributo LONGDESC conterrà il collegamento ad un documento esterno che descriverà i singoli punti del grafico.

7 – Script, applet e plug-in.

Fornire una pagina alternativa quando tali funzionalità sono inaccessibili o non supportate.

Molte applicazioni di home banking si appoggiano su sistemi che utilizzano tecnologie specifiche come Java (http://java.sun.com/  e ActiveX (http://www.microsoft.com/com/tech/ActiveX.asp) oppure applicazioni generate da tool commerciali come Macromedia Flash (http://www.macromedia.com/software/flash/). Tali tecnologie richiedono dei particolari programmi per la loro fruibilità (i cosiddetti “plug-in”), in mancanza dei quali l’utente non può fruire dei contenuti. Spesso i plug-in non sono disponibili per tutti i browser e/o sistemi operativi causando delle limitazioni per una parte della clientela: non definendo una soluzione alternativa, tutte le funzionalità previste da tali tecnologie (pensiamo ad esempio a un menu di navigazione, a una funzione di controllo/calcolo automatico dei rendimenti, etc.) non risultano accessibili agli utenti non dotati di tali plug-in, siano essi utenti normodotati o utenti con disabilità. Lo stesso problema viene generato dalle applet java, nel caso il browser non supporti tale funzionalità (http://www.csulb.edu/depts/dss/web-accessibility/webaim-java.html ).

Anche per gli script, al fine di rendere accessibile la funzionalità è necessario prevedere una operatività alternativa, tramite l’elemento <noscript>. Il maggior problema degli sviluppatori è quindi – nel caso di assoluta necessità di utilizzo di script, applet e plug-in – di sviluppare delle funzionalità alternative che rispettino le linee guida dell’accessibilità dei contenuti.

8 – I frame.

Utilizzare noframes e titoli significativi.

Spesso a tutt’oggi i frame vengono utilizzati per facilitare la navigazione dell’utente normodotato all’interno di un sito web, in quanto consentono ad esempio di mantenere un menu nel frame superiore sempre visibile. I frameset creano problemi nel campo della promozione web (spesso capita che i motori di ricerca indicizzino pagine interne dei frame che non consentono di ritornare alla gestione dei menu), ma soprattutto causano difficoltà di navigazione agli utenti che fanno uso di tecnologie assistive. L’utilizzo del <noframes> è richiesto dal W3C al fine di garantire l’accesso agli utenti che fruiscono del sito con sistemi che non supportano tale tecnologia.

9 – Tabelle.

Facilitare la lettura linea per linea. Riassumere.

La creazione di tabelle dati, specialmente in servizi di home banking, deve consentire all’utente con difficoltà di accesso ai contenuti tabellari (principalmente il disabile visivo e cognitivo) di ottenere le informazioni in modo chiaro ed esaustivo. Le tabelle dati devono perciò contenere un sommario (SUMMARY), un titolo (<caption>) e identificare in modo chiaro i riferimenti per le righe e le colonne. In questo modo un utente con tecnologia assistiva potrà ottenere la linearizzazione dei contenuti da parte del software di navigazione e avrà quindi la possibilità di fruirne in modo chiaro (cfr. par. 4.4.).

Per le tabelle di layout, ove utilizzate, è necessario specificare l’organizzazione del layout tramite l’attributo SUMMARY, non utilizzando invece gli altri attributi che identificano le tabelle di dati (https://www.webaccessibile.org/argomenti/argomento.asp?cat=335< /A>  - “Tabelle, stili e modalità d’uso” – Roberto Ellero).

10 – Verificare il lavoro.

Validare. Utilizzare gli strumenti, la lista di controllo e le linee guida di: http://www.w3.org/TR/WCAG.

Gli sviluppatori, prima di effettuare i test con gli utenti (per la validazione pratica dell’accessibilità, si veda quanto già detto al par. 2.3.), possono effettuare autonomamente delle verifiche di accessibilità delle pagine web, simulando le condizioni di lavoro di un utente disabile, provando a navigare solo con la tastiera, utilizzando un browser testuale o disabilitando il caricamento di immagini, suoni e animazioni nel browser grafico, ripetendo le prove con vari livelli di risoluzione grafica e di dimensioni dei caratteri.

 

Condividi:

Roberto Castaldo

Sono nato e vivo a Napoli, ed opero professionalmente nel mondo dell'informatica da più di vent'anni. In realtà l'informatica, insieme alla musica e ad altre poche cose, è stato da sempre un mio chiodo fisso, e la buona sorte mi ha aiutato a trasformarlo in un mestiere. Sin dalle mie primissime esperienze lavorative - insegnavo dattilografia ed i primi rudimenti di informatica in una scuola privata - mi sono trovato a mio agio nel settore della formazione e della divulgazione, certamente aiutato dai miei studi classici. Nel 1987 ho iniziato la mia attività come insegnante d'informatica in un Istituto Professionale Statale - per circa due anni sono stato il più giovane insegnante di ruolo d'Italia. Ho avuto svariate esperienze anche nel settore privato come sviluppatore (TPascal - lo ricordate? - VB, ASP e, più di recente VB.NET ed ASP.NET), ma soprattutto come docente e come divulgatore. Ho effettuato attività di formazione presso le più grandi realtà imprenditoriali italiane (IBM, Omnitel, Telecom Italia, TIM, Unicredito, Ekip, BNL, SSGRR), ma anche all'estero in qualità di docente e/o progettista di percorsi formativi; gli argomenti spaziano dal mondo Office fino al multimedia ed alla programmazione avanzata ASP ed ASP.NET. Ho collaborato con l'Istituto Italiano per gli Studi Filosofici di Napoli, ho redatto articoli/tutorial per un'importante rivista informatica (Win98 Magazine), ed ho partecipato allo sviluppo di CD-Rom Multimediali (IBM, Selfin, BNL) curando personalmente la registrazione dei commenti audio ed il montaggio delle musiche (CoolEdit), l'eventuale connessione a database remoti, l'assemblaggio degli elementi testuali, grafici e multimediali (Director 8) fino alla creazione del master definitivo. Negli anni 1998-2000 ho collaborato con la Gazzetta dello Sport Online curando, in occasione dei più importanti avvenimenti sportivi (Mondiali ed Europei di calcio, Giro d'Italia, Campionato di Serie A) le pagine contenenti la traduzione in inglese e francese degli articoli in italiano. Il mio compito consisteva nell'inviare ai miei traduttori la cronaca in italiano, riceverne la traduzione, creare le pagine inglesi e francesi del sito www.gazzetta.it e pubblicarle sul server, il tutto entro 90 minuti dalla fine dell'evento. Nel frattempo, mi avvicinavo in maniera sempre più approfondita alle problematiche legate all'accessibilità di siti web, progettando percorsi di formazione ad hoc, ed aderendo entusiasticamente al progetto webaccessibile.org. Sono stato per diversi mesi membro del XML Protocol Working Group del W3C, ed attualmente partecipo ai lavoro del WAI Web Content Accessibility Guidelines (WCAG) Working Group e del E&O Education ad Outreach Working Group.