Accessibilità: linee guida da riscrivere?

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

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’ è 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

, editore del sito 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

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 inglese e applicano il buon senso (tu [Clark, ndr], 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’

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.