riscrivi
le linee guide sull'accessibilità sono da riscrivere?
webnews.html.it/focus/342.htm

Accessibilità: linee guida da riscrivere?

di Francesco Caccavella (
f.caccavella@html.it)
Martedì 18 Novembre 2003

Una critica diretta e puntuale alle nuove linee guida per l'accessibiltà, il documentro che sarà la base della futura legge italiana ed europea. A scriverla
è Joe Clark, autore di Building Accessible Websites.

Le future linee guida sull'accessibilità sono «irreali», anzi «separate dal mondo reale degli sviluppatori». E ancora: sono «allo stesso tempo troppo vaghe
e troppo specifiche». Così Joe Clark, stimato divulgatore di principi di Web Design e autore del fortunato libro Building Accessible Websites, lancia l'allarme
dalle pagine di A List Apart. Una lunga analisi, frutto di mesi di lavoro, diretta al cuore delle future WCAG 2.0, le linee guida che rappresenteranno
la base, anche legislativa, per la scrittura di pagine Web accessibili.

L'articolo, intitolato Come salvare l'Accessibilità per il Web da se stessa ("How to Save Web Accessibility from Itself"), prende in considerazione le linee
guida WCAG 2.0, regole in via di definizione da parte del Web Content Accessibility Guidelines Working Group, il gruppo di lavoro da mesi occupato a riscrivere
le vecchie linee guida, datate maggio 1999. Le WCAG 2.0 regolamenteranno la scrittura di contenuti per il web in modo da garantirne la comprensibilità
alla massima audience possibile, con particolare riferimento ai disabili.

Clark chiede al gruppo di lavoro maggiore attenzione alle necessità reali degli sviluppatori, un confronto con le tecnologie reali, una maggiore apertura
verso i destinatari delle raccomandazioni. Se ne criticano i metodi e addirittura si arriva a metterne in dubbio la stessa competenza in materia. Agli
sviluppatori, destinatari anch'essi dell'articolo, si chiede una maggiore partecipazione per poter «salvare l'accessibilità da se stessa».

Il primo problema è, appunto, di partecipazione: la discussione nel gruppo di lavoro che sta scrivendo le linee guida manca di vivacità. Pochi messaggi,
poche persone. L'accessibilità è una disciplina trasversale, servono esperti di linguaggi, di disabilità, di cognizione, di scrittura per il web, di hardware:
«Noi non abbiamo la percezione che questi esperti in molti campi pertinenti hanno parte nel processo di sviluppo delle WCAG 2.0».

Ma il cuore dell'articolo è più avanti, è nella descrizione degli "Action Items": ossia gli elementi sui quali agire per migliorare le linee guida. Sono
suddivisi in cinque diversi punti.
Riscrittura («Rewrite»). Le linee guida sono in molti punti incomprensibili e violano così una delle principali necessità di una scrittura accessibile:
la comprensibilità. Serve una rilettura e una riscrittura dei documenti, anche per metter fine alla «tradizione di documenti incomprensibili» propria del
W3C.
Esempi («Examples»). Servono esempi presi dal mondo reale del web design. Clark propone di inserire nelle linee guida esempi presi da siti web esistenti
e un piccolo giudizio che esprima il rispetto delle linee guida da parte di questi siti. Il fine è quello di cacciar via la tendenza a esprimersi per ipotesi
e non per pragmatismo.
Poco chiaro nelle idee di fondo («Unclear on the concept»). Clark è spietato: «Le linee guida mostrano un profondo fraintendimento della materia che pretendono
di correggere tanto che dovrebbero essere cancellate o profondamente riscritte». Due le peggiori accuse: non aver ben compreso l'utilizzo dei fogli di
stile e puntare troppo sulla compatibilità verso il passato, quando gli sviluppatori sono da poco usciti dalle grinfie dei browser delle vecchie generazioni.
Impossibile («Impossible»). In molti casi, continua Clark, le linee guida propongono metodi e soluzioni impossibili da applicare. Così, ad esempio, nel
caso della richiesta di fornire sottotitoli e descrizioni audio in un file testuale separato per i contenuti multimediali, oppure nella richiesta, che
affiora in alcuni punti, di utilizzare tecnologie automatizzate per servire ad ognuno il contenuto che maggiormente si addice al dispositivo di accesso.
Non è problema nostro («Not our problem»). In molti casi, ed è l'ultimo punto, le linee guida travalicano i confini del proprio settore, tentando i regolamentare
la "complessità" e la "familiarità" del linguaggio da utilizzare in un sito web, oppure prendendo in considerazione, è il caso di acronimi e abbreviazioni,
elementi non supportati dalla tecnologia disponibile.

Si prevedono reazioni su un argomento che iteressa da vicino, anche in riferimento alla recente legge in discussione in Parlamento, la comunità dei webmaster.
Interpellato da HTML.it, Roberto Scano, membro italiano "In Good Standing" del gruppo di lavoro sulle WCAG 2.0, fa notare la provvisorietà del documento
in discussione. «Le WCAG 2.0 hanno subito nell'ultimo mese sostanziali modifiche: a titolo di esempio qualche mese fa si parlava di eliminare le priorità
A, AA, AAA per una diversa organizzazione del lavoro (Core, Extended) mentre alla fine si è tornati alle tre priorità (ora chiamate Livelli). Gregg Vanderheiden
[coordinatore del gruppo di lavoro, ndr] ha chiaramente detto qualche settimana fa durante una teleconferenza che un documento "stabile" delle WCAG 2.0
non è possibile sino alla fine del 2003 in quanto siamo ancora in fase di draft di molti documenti nonché dell'organizzazione vera e propria del documento
principale».

Anche Roberto Ellero, di
Webaccessibile.org
e secondo membro italiano "In Good Standing", difende l'operato del gruppo: «Clark indica come problema principale la violazione dell'esigenza di un linguaggio
semplice. Le discussioni in corso nel gruppo si incentrano continuamente su questa criticità, e diverse asperità sono state limate nell'attuale draft (l'
ultima versione interna
è di oggi [ieri per chi legge, ndr]), rispetto alla versione cui si riferisce Clark, risalente al giugno scorso».

Di diverso avviso Maurizio Boscarol, autore del libro
Recensione di HTML.it,
editore del sito
Usabile.it
e consulente in tema di accessibilità e usabilità. In uno scambio di e-mail con HTML.it, fa notare che, nonostante la condivisione dell'impostazione di
fondo, «il lavoro è ancora un po' troppo avulso dalla realtà degli sviluppatori. Ci sono una quantità di questioni che sono ancora ambigue ed irrisolte,
ed ogni volta che io o altri membri italiani poniamo problemi specifici, le risposte sono piuttosto vaghe ed elusive» Ad esempio si possono citare gli
"accesskey", i tasti di accesso rapido per pagine Web: «una funzionalità che entra in conflitto con le funzionalità di default da tastiera di molti browser
e user agent [...] Ogni volta che il problema viene posto, la risposta è più o meno "questo è un problema degli user agent"»

Il rischio è quello di formalizzare teorie che hanno bisogno di essere sperimentate. «Da questo punto di vista – continua Boscarol – la lacuna più grande
delle WCAG, 1 e 2, è che non prevedono in maniera esplicita e formalizzata alcuna attività di test con gli utenti. C'è scritto che verifiche con gli utenti
possono essere utili, ma il punto è che invece sono indispensabili».

La questione è annosa e mostra il nervo di una spaccatura fra chi scrive le regole (il W3C) e chi le applica nel lavoro di tutti i giorni. Un
commento
all'articolo di Clark è esemplare: «C'è un enorme scollamento fra gli scienziati del W3C e chi crea siti Web. Molti di noi ottengono informazioni su accessibilità
e standard non dal W3C ma dai suoi intepreti che parlano un inglese applicano il buon senso (tu, Eric Meyer, Zeldman, WSP, Pilgrim, Scott Andrew ecc.)».

Proprio contro questo atteggiamento Scano è netto: «Le linee guida W3C attuali vanno comprese non "interpretate", quelle in fase di creazione vanno migliorare:
ben vengano i commenti come quelli di Joe ad incentivare la qualità degli standard ma ricordiamo chiaramente che le raccomandazioni le fa il W3C con il
consenso».

Le WCAG 2.0 sono disponibili nell'
ultima versione in forma di "working draft"
pubblicata solamente ieri. Così come le osserviamo oggi, come mera bozza, tendono a semplificare e a razionalizzare le prescrizioni contenute nella prima
versione. Sono previsti 4 Principi; ognuno di questi viene sviluppato in più linee guida per un numero complessivo di 19. I contenuti di un sito per poter
essere accessibili devono essere Percepibili (Perceivable), Utilizzabili (Operable), Comprensibili (Understandable) e Robusti (Robust), ossia validi anche
per il futuro. Ognuna di queste linee guida ha alcuni punti di controllo che, verificati sul documento che si vuole accessibile, ne porteranno alla validazione.
La versione definitiva si attende per l'estate 2004.

Ultimi commenti all'articolo

Re: Accessibilità: linee guida da riscrivere?
di Franco Frascolla
Scritto il
18/11/2003 alle 10:40

Leggi i commenti
A l t r i F o c u s ]
H o m e p a g e ]

Link Utili:

Tabella con 2 colonne e 5 righe

»
How to Save Web Accessibility from Itself
Building Accessible Websites
WCAG 2.0
Working group WCAG
Mailing list delle WCAG

fine tabella

Focus correlati:

Tabella con 2 colonne e 3 righe

»
21/10/2003 - La camera ha approvato con una sostanziale unanimità il progetto di legge sull'accessibilità dei siti Web. Unica divisione in aula sul riconoscimento
ex lege degli standard internazionali. Un passo avanti per un web per tutti
28/05/2003 - È iniziato l'iter parlamentare del disegno di legge sull'accessibilità. I siti Web della pubblica amministrazione dovranno essere accessibili
19/12/2002 - Presentata una proposta di legge che obbliga i siti Web di pubblica utilità ad adottare regole di accessibilità. Per chi non si adegua è prevista
una sanzione da 500 a 3000 euro. Una proposta con molti lati oscuri
fine tabella

Ultime notizie a tema:

Tabella con 2 colonne e 3 righe

»
12/11/2003 - L'ufficio brevetti USA ha dato il via al riesame del brevetto Eolas. La decisione è arrivata dopo la documentata richiesta del W3C ed è stata
accolta con celerità dall'ente americano.
11/11/2003 - Firmato un protocollo di intesa per incentivare l'e-government nelle comunità montane: l'offerta di strumenti tecnologici può diminuire il
digital divide, permettere di superare barriere territoriali e fare in modo che il territorio non venga abbandonato
07/11/2003 - Il W3C ha bocciato l'uso delle protezioni anti-robot che utilizzano stimoli visivi per interagire con l'utente. Il sistema è inutilizzabile
per non vedenti o dislessici. In nome dell'accessibilità, il test va riformulato.
fine tabella

Torna all'indice