Archivi tag: wai

L’accessibilità dei giochi olimpici

Pubblicato il da

AbilityNet ha da poco pubblicato un’importante analisi relativa all’accessibilità del sito ufficiale dei giochi olimpici.

Il risultato ce lo potevamo probabilmente aspettare: il sito risulta solo parzialmente accessibile a indicare una scarsa conoscenza dei realizzatori in fatto di accessibilità web. Tutto questo dopo che 4 anni fa un non vedente vinse una causa contro la Commissione Olimpica per il sito dei giochi di Sidney, come racconta egregiamente Joe Clark (che ho avuto il piacere di intervistare qualche anno fa).

Al di là dei risultati, però, lo studio è interessante per le modalità con cui è stato condotto.

In AbilityNet non hanno infatti utilizzato alcuno strumento automatico di verifica dell’accessibilità.  Come scrivevo ormai 6 anni fa in Cos’è l’accessibilità web:

La verifica di un sito accessibile non avviene esclusivamente via software. Programmi con Bobby di Cast, A-Prompt di Trace aiutano ad evidenziare lacune e punti di miglioramento, ma questo non è che il primo passo.

I problemi di accessibilità nascono soprattutto da errori di architettura o di progettazione che è possibile risolvere solo applicando le linee guida nel contesto del sito in esame.

Si è preferito impegnare persone con diversi tipi di disabilità e indicare alcuni compiti da svolgere, come leggere il programma degli eventi, trovare i tempi di qualifica di una disciplina, comperare un biglietto.

Nulla di diverso da quello che normalmente si fa nei test di usabilità di un sito. Ed è corretto, dal momento che accessibilità e usabilità web si completano.

E’ davvero illuminante e allo stesso tempo sconcertante dare un’occhiata ai filmati in cui i 4 disabili incontrano difficoltà nel compiere anche le operazioni più semplici a causa della scarsa cura in termini di accessibilità web.

Ecco alcuni spunti tratti e commentati dal documento:

  • per il sito delle olimpiadi è stato utilizzato un approccio esclusivamente tecnico all’accessibilità, utilizzando le linee guida WAI come sterile lista di punti da seguire
  • uno dei principali problemi riscontati dall’utente cieco è che i video e gli audio presenti nella pagina iniziano l’esecuzione in automatico, senza la presenza di opportuni controlli di play/stop. Questo provoca delle sovrapposizioni vocali con gli screen reader, rendendo difficoltosa la comprensione del contenuto
  • le tabelle di contenuto in un sito devono essere pensate per poter essere interpretate da sinistra verso destra, e non dall’alto al basso, come invece avviene per la pagina del programma delle olimpiadi
  • nel corso delle olimpiadi i responsabili del sito hanno migliorato alcuni aspetti dell’interfaccia. Indice che il tema dell’accessibilità web è stato sottovalutato e solo a seguito di lamentele si è deciso di porre qualche parziale rimedio. Non quindi un limite dell’infrastruttura utilizzata (comunque non giustificabile), ma di pessima progettazione

Sempre in tema di accessibilità del sito delle olimpiadi, vi suggerisco la lettura di questa dettagliata analisi di Rnib, seguita da una seconda parte, che già più di un anno fa aveva lanciato un grido di allarme, rimasto purtroppo in gran parte inascoltato.

Un Web Accessibile a Tutti – Intervista a Joe Clark

Pubblicato il da
  1. Ci parli di lei [Risposta 1]
  2. Quali sono gli argomenti trattati nel vostro libro “Building Accessible Websites“? [Risposta 2]
  3. 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]
  4. L’accessibilità web è utile solo alle persone disabili? [Risposta 4]
  5. In cosa differisce l’accessibilità web dalla usabilità web? [Risposta 5]
  6. 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]
  7. Cosa dire dei browser: Internet Explorer 6 e Netscape 6 interpretano correttamente i tag Html rivolti all’accessibilità? [Risposta 7]
  8. 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).

Top

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

Top

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.

Top

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

Top

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

Top

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

Top

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.

Top

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.

Accessibilità web in Italia e nel mondo

Pubblicato il da

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.