- Ci parli di lei [Risposta 1]
- Quali sono gli argomenti trattati nel vostro libro “Building Accessible Websites“? [Risposta 2]
- Che cosa è l’accessibilità Web e perché è così importante nella costruzione di un sito? Quali fasi del ciclo di vita di un sito hanno a che fare con l’accessibilità? [Risposta 3]
- L’accessibilità web è utile solo alle persone disabili? [Risposta 4]
- In cosa differisce l’accessibilità web dalla usabilità web? [Risposta 5]
- Le specifiche Wai sono a volte difficili da applicare. Le pagine di un sito devono “degradare gentilmente”, ma allo stesso tempo è meglio usare i Css anche per il layout. Le due tecniche sembrano agli antipodi. È davvero possibile costruire un sito seguendo queste specifiche così restrittive? [Risposta 6]
- Cosa dire dei browser: Internet Explorer 6 e Netscape 6 interpretano correttamente i tag Html rivolti all’accessibilità? [Risposta 7]
- A parte il sito Wai, ci sono altre risorse online che ci potrebbe consigliare? [Risposta 8]
Ci parli di lei
Sono un giornalista [nuova finestra] e consulente di accessibilità [nuova finestra] a Toronto. Svolgo questo lavoro praticamente da 20 anni. Ho pubblicato circa 400 articoli su riviste e giornali e sto per pubblicare un libro, Building Accessible Websites [nuova finestra]. Mi occupo di consulenza su temi di accessibilità per un piccolo numero di clienti (soprattutto per la televisione e il cinema).
Quali sono gli argomenti trattati nel vostro libro “Building Accessible Websites“?
Piuttosto che il solito manuale di programmazione, il libro è una chiara spiegazione di cosa sia l’accessibilità Web e delle regole per progettare siti accessibili.
Alcuni degli argomenti riguardano:
- L’accesso alle informazioni e le leggi
- Una breve spiegazione di come le persone disabili usano i computer
- Multimedia
- La navigazione
- Tabelle e frame
- Il testo e i link
- La struttura della pagina
- Le immagini
- Come creare pagine accessibili fin dall’inizio
Che cosa è l’accessibilità Web e perché è così importante nella costruzione di un sito? Quali fasi del ciclo di vita di un sito hanno a che fare con l’accessibilità?
In generale l’accessibilità viene incontro alle situazioni e difficoltà invariabili di alcune persone. Una persona con problemi alla vista continua ad averli anche quando visita un sito, tanto per fare l’esempio più comune.
Il Web non è un mezzo universale. Non è come la stampa: economica e disponibile senza troppe difficoltà. C’è un certo grado di elitarismo nel Web: c’è bisogno di un computer e di una connessione ad Internet, elementi con un certo costo. Allora perché l’accessibilità Web è importante? Perché non si vuole essere elitari inutilmente. Non bisogna impedire l’accesso ai siti per cause che queste persone non possono cambiare.
Oltre a questo, l’accessibilità è sempre più richiesta dalle norme di legge [nuova finestra]. Non ci sono decreti nati appositamente per l’accessibilità Web, ma ci sono dimostrazioni di quanto le leggi attualmente in vigore siano state applicate all’accessibilità Web.
Una persona non vedente, Bruce Maguire, ha vinto un caso [nuova finestra] contro le Sydney Olympics del 2000; ha sostenuto che il loro sito Web era per lui inaccessibile (Bruce legge il testo Web con un visualizzatore Braille e un lettore vocale), e le autorità australiane gli diedero ragione, richiedendo al comitato olimpico l’adeguamento del sito e il pagamento di una multa. (Non hanno mai aggiornato il sito, che si sarebbe potuto progettare nel modo corretto fin da subito, ma pagarono la multa).
Il decreto “Americans with Disabilities Act“ [nuova finestra] si applica senza equivoci anche al Web. Lo stesso dicasi per il “Disability Discrimination Act“ [nuova finestra] nel Regno Unito, e anche per tutte le forme legislative che proibiscono un trattamento non equo, ma sfavorevole nei confronti delle persone disabili. Inoltre, i servizi e i siti realizzati da chi lavora per o nel governo federale degli Stati Uniti devono essere accessibili e rispettare i requisiti “Section 508“ [nuova finestra].
Meglio includere le politiche di accessibilità fin dall’inizio. È generalmente semplice realizzare un sito accessibile partendo da zero e molto noioso e spiacevole ritornare indietro e correggere errori in un secondo momento. Il mio libro, a dire il vero, spiega anche come migliorare un sito esistente, se questa è l’unica possibilità. Ci sono delle procedure che rendono il compito gestibile.
L’accessibilità web è utile solo alle persone disabili?
In quasi tutti i casi, si. Personalmente sono stanco di sentire quei difensori dell’accessibilità che dicono “Se rendi il tuo sito accessibile, le persone potranno visualizzarlo con i loro Palm Pilot!”. Non vedo perché si debbano cercare delle giustificazioni al fatto che rendere un sito accessibile è utile soprattutto per rispondere alle esigenze delle persone disabili (più qualche altra esigenza, come i problemi di lingua, anche se non ne parlo molto nel libro).
In ogni caso un sito che si definisce accessibile non funzionerà bene su un Palm Pilot. Ci sono ancora troppi link (come le barre di navigazione) e troppo testo non pertinente perché valga la pena usarlo. Si è verificato il contrario con il caso Amazon [nuova finestra]. Amazon ha adattato il sito per i Pda e ha sostenuto che era fruibile anche con i software di sintesi vocale. Ma le cose non funzionano così.
In cosa differisce l’accessibilità web dalla usabilità web?
L’interazione tra le due discipline sta diventando sempre più chiara.
Il problema principale è il seguente: se il tuo sito è immediatamente ed efficacemente utilizzabile da una persona non disabile, ma una persona disabile deve faticare per completare i suoi compiti e impiega il triplo del tempo, quanto accessibile è il tuo sito? Quanto è usabile?
Questo è riconducibile a due aree principali: la navigazione e le form.
I siti web “tipici” hanno troppi link da saltare. Questo non è solo un problema per le persone non vedenti che usano i sintetizzatori vocali, come invece tutti pensano. Un abile utilizzatore di sintetizzatori vocali può infatti evitare molto agevolmente i link, per esempio saltando completamente la barra sinistra di navigazione. Ma una persona con problemi motori potrebbe essere costretta a tabulare tra 80 o più link solo per posizionare il cursore sulla casella di ricerca. (E usare la tabulazione per navigare i link è in realtà il caso migliore e quello più veloce – alcuni metodi usati da persone con gravi problemi motori muovendo le mani e le braccia sono molto lenti).
I siti dovrebbero riordinarsi automaticamente così che gli elementi cruciali, come le caselle di ricerca o i più importanti livelli di navigazione siano in cima, mentre tutto il resto dovrebbe essere presentato di seguito secondo un ordine logico. Forse il protocollo CC/PP [nuova finestra] renderà un giorno tutto questo possibile. A dire il vero, ogni sito realizzato come insieme di moduli da un sistema di gestione dei contenuti potrebbe automaticamente riordinarsi in questo modo, ma nessuno si sta prendendo il disturbo di farlo. Non si prendono neppure la briga di riordinare gli elementi della pagina premendo un bottone invece che farlo automaticamente. Si stanno ancora studiano delle tecniche che risolvano questo problema.
Riguardo alle form, i miglioramenti per l’accessibilità sono molto semplici in Html. Le form sono già di per sé complicate da mettere insieme, così gli sviluppatori non hanno nessuna scusa per non includere i tag che migliorino l’accessibilità. Il problema è in realtà che i sintetizzatori vocali non sono stati aggiornati per usare queste caratteristiche (come <label> intorno al tag <input>). Potrebbe allora succedere che gli autori di contenuti abbiano svolto correttamente il loro lavoro, ma che la tecnologia per l’accessibilità non riesca ad interpretarlo. E i sintetizzatori vocali non sono per niente bravi nel leggere il testo, i bottoni, i radio button, i check box e i textarea e chiarire come tutti questi elementi siano collegati gli uni agli altri. È molto facile perdersi quando si compila una form online. Allora, se le persone non disabili possono usare la vostra form ma le persone disabili no, la vostra form è realmente usabile? (Anche in questo caso, rendere accessibili le form per persone con difficoltà motorie è molto difficile. Nessuno ha sviluppato un buon metodo per svolgere questo compito fino ad oggi).
Le specifiche Wai sono a volte difficili da applicare. Le pagine di un sito devono “degradare gentilmente”, ma allo stesso tempo è meglio usare i Css anche per il layout. Le due tecniche sembrano agli antipodi. È davvero possibile costruire un sito seguendo queste specifiche così restrittive?
Le specifiche del Wai sono pessime, ma sono in fase di attenta revisione. Finalmente abbiamo una
title=”Wcag 2 Restructuring Proposal” target=”_blank”>bozza della versione 2.0 [nuova finestra] delle Web Content Accessibility Guidelines che è quasi decente. Siamo ancora lontani dal traguardo, ma rappresenterà un forte miglioramento. Al momento siamo ancora bloccati alla versione 1.0.
La frase “degradare gentilmente” è stata ampiamente fraintesa. Significa semplicemente che “le cose devono funzionare anche in condizioni che lo sviluppatore non ha potuto o saputo anticipare”. È facile da ottenere, soprattutto in siti che non usano elementi multimediali. Se si scrive Html valido e si usano gli elementi dell’Html nel modo consono (cioè, non si usa <p> per codificare un titolo), si è già a buon punto.
Non è “sicuramente meglio” usare i Css per il layout. È troppo difficile far sì che i layout creati con i Css funzionino consistentemente in tutti i browser; è molto più semplice usare le tabelle. Questo nel mondo reale, dal momento che chiunque abbia messo insieme più di qualche pagina ha usato le tabelle per il layout. I costruttori di sintetizzatori vocali hanno inoltre aggiornato il loro software per gestire le tabelle (con rare eccezioni). I Css, quando riuscite a farli funzionare, vanno bene; anche le tabelle vanno bene. Lo so che sembra esserci un’eresia, ma questa è la realtà. (Io uso Css e tabelle, e qualche volta nessuno dei due, per le circa 500 pagine che ho online. Non pretendo di essere un purista, ma nessun altro dovrebbe pretenderlo).
Cosa dire dei browser: Internet Explorer 6 e Netscape 6 interpretano correttamente i tag Html rivolti all’accessibilità?
I browser sono solo mediocri quando si tratta di supporto all’accessibilità nell’Html.
Le ultime versioni di Mozilla [nuova finestra] gestiscono molte funzionalità correttamente. Sottolineano gli acronimi e le abbreviazioni con linee tratteggiate; vi danno l’accesso alle descrizioni lunghe (longdesc) delle immagini (ma non dei frame – nessun browser lo fa); gestiscono l’alt text per le immagini meglio di qualsiasi altro browser (visualizzano semplicemente il testo dell’alternate senza cornici o altri riferimenti grafici che non siano stati progettati per la pagina).
iCab [nuova finestra] ha un supporto molto buono: è l’unico browser che può leggere l’attributo summary di una <table>.
Il supporto per l’accessibilità di Internet Explorer [nuova finestra] è solo discreto. Dal momento che non sono visualizzate alcune funzionalità molto utili come le descrizioni lunghe, gli sviluppatori spesso non sanno neppure che è possibile aggiungerle all’Html.
A parte il sito Wai, ci sono altre risorse online che ci potrebbe consigliare?
Gestisco il Web AccessiBlog [nuova finestra], un Weblog di link ad altri siti che trattano di accessibilità. Dovrei aggiornarlo più spesso (ho davvero bisogno di un sistema basato su database), ma so di sicuro che ha link a praticamente tutte le risorse attualmente disponibili in inglese (a volte anche in tedesco). C’è meno materiale disponibile su questo argomento di quello che potreste pensare.
Chiunque avesse domande relative all’accessibilità web dovrebbe iscriversi a WebAIM [nuova finestra] e alla mailing list del WAI-IG [nuova finestra]. O semplicemente chiedere a me.