23 Maggio ’06

Fino all'Inferno con WCAG 2

di Joe Clark, importanti novità sull'accessibilità.

"Translated with the permission of A List Apart Magazine."

Il Problema

Le "Web Content Accessibility Guidelines 1.0" furono pubblicate nel 1999 e divennero presto obsolete. Le nuove WCAG 2.0 proposte sono il risultato di cinque anni di lavoro della commissione WAI (web accessibility initiative). Il tentativo di essere esaustivi e valutare tutti i contenuti del web, ha reso, queste WCAG, incomprensibili per gli sviluppatori che scrivon secondo gli standard. Questa seconda versione è un passo indietro per le basi universalmente accettate dello sviluppare "responsabilmente". WCAG 2.0 non è un miglioramento e non sarebbe stato male aspettare ancora un po’.

Preparati per la delusione

Se sei uno sviluppatore fedele agli standard per il web, sai già cos’è l’accessibilità e dovrebbero esserti famigliari le WCAG, che sono le linee guida internazionali su questa materia. WCAG 1 ha appena festeggiato il suo settimo compleanno ed è vicino alla fine dei suoi giorni. WCAG 1 ha veramente bisogno di una profonda revisione.

Il 27 Aprile ’06, il WAI ha pubblicato la prima istanza di un’interminabile sequenza di documenti indispensabili per operare la revisione e che formano il WCAG 2.0.

Se speravi in un globale miglioramento rimarrai deluso, son state raccolte un sacco di sciocchezze. Il problema è che gli "Standardisti" già sanno cosa fare per colmare l’abisso generato da queste linee guida.
Curiosamente le WCAG 2 sembrano avere un senso, forse grazie alla stesura durata molti anni. Il nucleo del discorso è ben mascherato e il testo scorrevole. Ma non hanno senso, e tu come chiunque lavori seguendo gli standard scoprirà che è impossibile implementare il WCAG 2.

Dove trovare il documento

Come da tradizione per il W3C (web consortium), gli attuali documenti del WCAG 2 sono sparpagliati e difficili da trovare. Tuttavia ho stampato e letto tutti e tre i testi che lo compongono prima di scrivere l’articolo.

• "Web Component Accessibility Guidelines 2.0", è l’attuale documento radice ed è l’unico che parla di "normativa" (di regole). È definito, nel gergo del W3C, come l’ultima bozza, quella definitiva. (72 pagine, 20.800 parole)
• "Understanding WCAG 2.0" è un documento con l’obbiettivo di spiegare WCAG 2 (165 pagine, 51.000 parole)
• "Techniques for WCAG 2.0" fornisce tecniche "generali" (221 pagine 88.000 parole pensa se fossero speciliche)

Se comparato alle dimensioni di un normale libro il WCAG 2, con le sue 450 pagine, supera le dimensioni di qualunque libro su questa materia, compresi i miei. Inoltre, stando ad alcuni blog (snook..) Shawn Lawton Henry del gruppo di lavoro "Educazione e Oltre" alla WAI, sembra abbia consigliato hai suoi attendenti di leggere un riassunto dalle linee guida perché tutto intere sarebbero più del doppio del documento che deveno spiegare, basta questo ad indicare che c’è qualche problema col WCAG 2.

Però c’è molto tempo per commentare

Dove aver lavorato per cinque anni sul WCAG, la WAI ha dato alle parti interessate, inclusi i disabili, addirittura 34 giorni per commentare il testo (cioè fino al 31 Maggio 2006). Anche se si supera il minimo privisto che è di tre settimane, non è abbastanza. Inoltre il gruppo di lavoro ha deciso che, per ogni argomento che si vuol commentare, bisogna inviare un modulo, possibilmente in EXCEL.

Il mio consiglio è semplicemente di mandare mail a questo indirizzo public-comments-wcag20@w3.org e leggere gli articoli della mailing list

E’ il processo che puzza

E ora qualche parola sul modo con cui han proceduto, per apprezzare a pieno il risultato attenuto. Il gruppo del WCAG è il peggiore gruppo col quale lavorare. Molti miei amici ed io siamo stati ignorati; trattati con distacco dal gruppo poi espulsi e attaccati.
Tutto è preparato dalle multinazionali che hanno i soldi per parlare al telefono fin dall’altra parte del mondo (per due ore la settimana) e prendere voli intercontinentali per incontrarsi.

Il WCAG è scritto solo in inglese. E più importante, non è accessibile a molti disabili, in particolare chi ha problemi di lettura e chiunque sia cieco. Nessuno che abbia una qualche disabilità ha contribuito al progetto, in pratica, lavorare così non è possibile.

Quello che tutti si aspettano dal WAI è che migliori il web per le persone disabili, ma se tanti i partecipanti lavorano in questo clima di terrore c’è qualcosa che non và, non ho mai sentito cose simili degli altri gruppi WAI. WCAG è l’erbaccia cattiva del W3C e sarebbe ora che Tim Berners-lee sistemi le cose.

Una farsa quasi riuscita, ma comunque un fallimento.

Dopo aver speso un paio d’ore a leggere la prima bozza del WCAG 2, probabilmente ti sentirai confuso e/o infuriato. Lo scopo del gruppo di lavoro è stato ridurre al minimo le linee guida e soprattutto quello di far sembrare il tutto molto ragionevole. Son riusciti straordinariamente a seppellire i difetti nascondendo il tem aprincipale nel profondo del documento. Hanno fatto un lavoro stupendo che fa sembrare che il WCAG 2 funzioni, ma non è così.

Lasciatemi spiegare quello che il WCAG dice, basandomi sui tre documenti che ho letto e considerando sia le tecniche obbligatorie che quelle suggerite.

• Non è ben definito il concetto di "pagina", lasciam stare quella di "sito".
• Un futuro sito non ha bisogno di avere HTML valido per esser compatibile col WCAG 2. Però devi controllare l’output DOM del sito in browser multipli e provare che sia identico.
• Puoi usare tabelle per il layout. (non una sola, ma quante ne vuoi).
• L’intera pagina o parte di essa può brillare fino ad un massimo di tre secondi. Però nessuna parte può lampeggiare.
• Puoi utilizzare qualunque software o tecnologia base o di partenza: browser, dispositivi multimediali ect. Questo significa che chiunque sprovvisto di tale tecnologia non può protestare se non riesce ad accedere al tuo sito.
• Sei libero di definire intere directory del tuo sito come inaccessibili (per esempio directory che contengono soltanto video)
• Se vuoi dichiarare la compatibilità con WCAG 2, devi pubblicare una lista di dichiarazioni molto suggestive, probabilmente le più suggestive che si possano trovare ad oggi.
• Certo nessuno può rendere un video accessibile, ma se lo pubblichi, non c’è bisogno di aggiungere descrizioni audio (per i cechi) o altro per avere la conformità.
• Devi re-mixare i tuoi podcast in modo che i dialoghi siano 20 decibel più forti del rumore di fondo. ( non c’è bisogno di trascrivere i dialoghi o mettere etichette, non sono mica contenuto "multimediale". D’altra parte Slide shows (come quelli di power point) son considerati "video", sarà una bella sorpresa per gli utenti di Flickr.
• Puoi creare una pagina sola con migliaia di link, ma se metti una dopo l’altra due pagine con almeno tre link di navigazione, allora devi far in modo che possan esser saltati.
• Non puoi posizionare o aggiungere etichette che non compaiano sullo schermo che soltanto alcune persone possono vedere, come gli utenti che utilizzano tecnologie che li assistono per l’handicap che hanno. Tutti i navigatori devono vederle.
• I layout CSS, non possono usare il posizionamento assoluto. Infatti, l’ordine del sorgente deve rispecchiare l’ordine degli elementi nella pagina.
• Devi inserire le seguenti: Descrizioni per gli idiomi considerati gergo o dialetto. Le sigle vanno scritte per esteso. Per alcune parole và scritta la pronuncia.
• Se un utente con scarsa istruzione non comprende il documento principale, devi provvedere a metterne a disposizione un secondo più comprensibile. (infatti, WCAG 2, ripete continuamente di mantenere separato contenuto accessibile a quello non accessibile. In alcuni casi, non c’è bisogno di migliorare l’accessibilità delle pagine, basta farne delle altre)

Dato che questi tre documenti sono una bozza, si spera che le cose qui sopra cambino. Ma in realtà non sarà così. L’ultima bozza è vista sostanzialmente come definitiva. E’ un segnale che il Gruppo di lavoro crede di aver soddisfatto i requisiti tecnici e la dipendenza dagli altri gruppi. A questo punto il lavoro fatto non cambierà.

Sull’autore

Giornalista a Toronto, autore e consulente per l’accessibilità. Joe Clark ha scritto il libro Bulding accessible Websites (costruire siti accessibili) che non solo è il libro migliore e più completo scritto sull'agomento è anche tra i più convincenti libri di web design mai pubblicati.

Nota del traduttore: perché questo articolo?

Molti paesi hanno leggi che vietano le limitazioni d'accesso ai disabili, e molti paesi hanno applicato queste leggi ai nuovi media attraverso decreti relativi all'accessibilità web, come la Setion 508 neglio Stati Uniti;alcune di queste leggi nazionali aderiscono alla WAI !

Questo articolo non è stato tradotto interamente, se sei veramente interessato puoi continuare la lettura andando sul sito "a list apart" tramite il link in cima alla pagina.