|
Seminario
a tema |
|
Oreste Signore - W3C Italia "NovitA' dal W3C." Presentazione: http://www.w3c.it/talks/2006/handimatica2006/ Nota: le informazioni relative alla WCAG 2.0 sono aggiornate alla versione disponibile alla data dell' intervento (Working Draft del 27 aprile 2006 -
http://www.w3.org/TR/2006/WD-WCAG20-20060427/). Il World Wide Web Consortium (W3C) è un consorzio di organizzazioni che si propone l' obiettivo di portare il web al massimo del suo potenziale ("Leading the Web to its full potential"). Nato 12 anni fa, nel 1994, ha definito ad oggi più di 90 specifiche tecniche, dette Recommendation, spesso denominate standard web. In effetti queste specifiche sono degli standard de facto, perché il W3C non è un'organizzazione di standard. Tuttavia va sottolineato che non derivano da una posizione dominante del mercato, ma sono il frutto dell' accordo raggiunto da tutta la comunità che opera sul web, con un processo il cui obiettivo è raggiungere il consenso dei tecnici. Non è casuale che una Recommendation, per passare dallo stato di "Candidate Recommendation" a quello di Recommendation vera e propria debba avere almeno due implementazioni fatte su due piattaforme diverse che siano interoperabili fra di loro. Quindi non vi troverete mai nella situazione in cui, come spesso accade, non potete collegare due apparecchiature "standard" perché il maschio dell' una non è compatibile con la femmina dell' altra. Va anche sottolineato come l' accessibilità sia connaturata con il web. Tim Berners-Lee, creatore del web e direttore del W3C, dice di aver progettato il web più come un fatto sociale che come un fatto tecnico o tecnologico. Citando le sue parole, l'obiettivo finale del web è supportare e migliorare la nostra esistenza weblike, cioè un'esistenza di persone che vivono nel web. Da questo discende la sua importanza e il valore sociale come comunicazione, e ovviamente occorre rendere questi benefici disponibili a tutti, indipendentemente da hardware, software, infrastrutture di rete, lingua madre, cultura, posizione geografica e capacità fisiche e mentali. In questa lista la disabilità è messa per ultima non perché sia considerata meno importante, ma perché è ritenuto quasi ovvio. Notate però che si parla non solo di disabilità fisica e mentale, ma anche di differenze di cultura, che di fatto possono dare un significato completamente diverso alla stessa pagina web, magari semplicemente perché il colore utilizzato ha un diverso significato in due culture diverse (per esempio, il rosso può indicare pericolo o allegria). Il W3C è assolutamente convinto che la web accessibility è qualcosa di globale, in cui concorrono tanti componenti. Gli sviluppatori usano degli strumenti di sviluppo e degli strumenti di valutazione per valutare i contenuti, per valutare l'accessibilità dei siti. Gli utilizzatori usano tecnologie assistive, se le hanno, se le vogliono usare, se ne hanno necessità, e i browser per accedere all'informazione. Quindi ci sono almeno questi tre componenti: il contenuto, gli sviluppatori e gli utenti che devono tutti e tre cooperare per raggiungere il massimo livello di accessibilità. Se lo strumento di authoring non mi garantisce, o addirittura non mi permette di sviluppare del contenuto accessibile, probabilmente io sviluppatore non farò un sito accessibile. Se il browser non è in grado di supportare certe impostazioni, per cui non utilizza gli accorgimenti adottati dallo sviluppatore per rendere accessibile il sito, lo sviluppatore non metterà quell'accorgimento perché tanto è inutile. Se il contenuto non è pensato per essere accessibile, non sarà fruibile dall' utente disabile (e non solo). Quindi un sito accessibile richiede che tutti i componenti siano stati sviluppati in modo armonico e coerente. Il W3C produce linee guida e specifiche tecniche. Le più famose, perché sono ultracitate, sono le Web Content Accessibility Guidelines, le linee guida per il contenuto accessibile, che, badate bene, sono le WCAG 1.0, perché sono l'unico documento citabile, in quanto Recommendation. Notate che le WCAG 1.0 sono state rilasciate nel 1999, e, considerato che ci vuole un po' di tempo per giungere a una Recommendation, dovevano necessariamente far riferimento a tecnologie esistenti e già consolidate negli anni precedenti. Di conseguenza, sono molto legate all' HTML dell' epoca, e non fanno riferimento ad altre tecnologie (come per esempio gli style sheet o fogli di stile) che si sono affermate successivamente. D' altra parte, proprio considerando i tempi di definizione di una Recommendation, si vede subito che una delle prime cose che ha fatto il consorzio quando è nato è stato proprio fare le linee guida per l'accessibilità, contemporaneamente alle prime specifiche (l' XML, che è la tecnologia base del Web moderno è del 1998). In considerazione dei vari componenti della Web Accessibility il W3C ha poi subito dopo rilasciato le linee guida per gli authoring tool, gli strumenti che permettono di sviluppare siti accessibili e che siano usabili anche da utenti disabili, e gli user agent che dicono a chi fa i browser che cosa deve fare per poter supportare un sito accessibile, per poter rendere bene un multimedia, per fare lo streaming e così via. Quindi i tre componenti della Web Accessibilità sono tutti e tre coperti da Recommendation del W3C. Ma è noto a tutti che il mondo delle tecnologie web è in rapida evoluzione, e quindi molte attività sono in corso nel W3C. Sono in corso di definizione le WCAG 2.0, e ne parleremo più in dettaglio in seguito, le ATAG 2.0, e per le le UAAG (User Agent Accessibility Guidelines) si sta considerando come agire. Oggi tutti parlano del WEB 2.0, delle Rich Internet Applications ecc. che ovviamente, facendo un ampio uso di javascript, avendo tante caratteristiche software di un certo tipo, pongono grossissimi problemi di accessibilità. La soluzione che il W3C sta delineando è quella descritta nella suite WAI-ARIA, dove ARIA sta per Accessible Rich Internet Applications. Il primo documento è una roadmap, quindi una strada per giungere a quello che in termini tecnici viene definito un markup dichiarativo. Gli altri due documenti spiegano il ruolo dei singoli componenti e gli stati e proprietà. In termini molto semplici, questo significa dire che è possibile descrivere qual è il ruolo di un certo componente della pagina, facendo riferimento ad un' ontologia dei ruoli. In questo modo l'agent, quindi il browser, nel momento in cui io passo col mouse su una parte della pagina che, a livello descrittivo, ho specificato essere per esempio un menu, sa come comportarsi e quindi può automaticamente rendere questa parte della pagina o comportarsi in modo adeguato a quelle che sono le mie esigenze, che non è detto siano determinate da una disabilità. Io posso anche dire non voglio colore, voglio interazione a tabulatore, poi che questo dipenda da una disabilità o da un problema estemporaneo perché sto andando in macchina e c'ho il navigatore è tutta un'altra cosa. La definizione delle esigenze dell' utente non prevede, anzi esclude, la pubblicazione dell'eventuale disabilità. Un' altra iniziativa importante, citata in un intervento precedente anche da Patrizia Bertini, è l' Evaluation and Report Language (EARL), un linguaggio comune per far dialogare tutti gli strumenti di valutazione dei siti in modo da poter fare una valutazione di conformità alle specifiche. Perché di strumenti che valutano i siti e verificano le regole, i check point ecc. ce ne sono tanti, poi ovviamente nessuno è perfetto, e spesso si desidera riuscire a combinare i risultati dei vari strumenti. Le WCAG 1.0, abbiamo detto, sono di qualche anno fa e sono ben note, quindi non merita dilungarsi su di esse. Ricordiamo solo che sono state l'origine dei famigerati bollini, con la definizione dei tre livelli: A, Doppia A, Tripla A. Ma soprattutto ricordiamoci che la dichiarazione di conformità, quindi il "bollino", è responsabilità unicamente del web master. Mi accade spesso di ricevere telefonate di webmaster che mi chiedono di "certificare il sito". Io, in qualità di W3C Italia, non posso neanche dire "sì, ma a pagamento", perché il W3C non certifica siti, semplicemente definisce le specifiche di accessibilità e fornisce alcuni strumenti di validazione. A proposito delle WCAG 1.0, e dei livelli di priorità, è bene sottolineare che vi sono stati dei fraintendimenti. Assegnare priorità di livello diverso (1, 2 e 3) ha fatto ritenere che la priorità 1 fosse più importante della priorità 2, cioè che i requisiti (o check point) delle varie priorità fossero di importanza diversa. Di conseguenza, molti hanno pensato che bastasse raggiungere il livello A per la sufficienza, e il livello AA per l' ottimo. In effetti abbiamo visto (faccio sempre riferimento all' intervento di Patrizia Bertini) che in queste analisi condotte a livello europeo alcuni requisiti di livello 3 sono stati ritenuti molto importanti dagli utenti. Un caso tipico è quello del contrasto, che non teneva conto delle esigenze specifiche degli ipovedenti, ed è posto, nelle WCAG 1.0, a livello 2 e a livello 3. Questo aspetto è stato corretto nelle regole tecniche emanate per la legge 4/2004. Le WCAG 2.0 hanno un'impostazione abbastanza diversa, si basano su 4 principi che sono quelli condivisi da tutta la comunità scientifica che si occupa di usabilità e fruibilità dei siti. Un sito deve essere percettibile, gli elementi devono essere operabili (o azionabili, quindi l'utente deve poter comunque sia azionare i bottoni o scrivere quello che deve scrivere), comprensibile e anche robusto, perché si pensa di fare qualcosa che sia, forse un po' ambiziosamente, buono e accessibile anche con le tecnologie future, anche con quelle che non esistono. Sembra una dichiarazione un po' roboante, però ha la sua ragion d' essere, perché vuol mettere in evidenza l' impegno a definire delle linee guida che siano indipendenti dalla particolare tecnologia. Ci sono alcuni aspetti importanti delle WCAG 2.0, su cui merita spendere qualche parola. Uno è il concetto di baseline: quando lo sviluppatore o chi commissiona il sito definisce le specifiche, definisce anche quali sono le tecnologie che ritiene che siano presenti e funzionanti e su cui ci si può basare. Per cui il committente può, per es. se è un sito pubblico, definire una baseline molto bassa perché un sito pubblico deve essere fruibile su qualunque dispositivo (chioschi, PC molto vecchi). Occorre perciò prevedere che non ci siano, come prerequisito, delle tecnologie avanzate, o un browser nella sua versione più recente, perché in questo modo si pone un limite alto. Se però si stanno dando le specifiche per una applicazione intranet, in cui è l' organizzazione che fornisce ai suoi impiegati tutti gli strumenti, si può definire una baseline più alta perché si è in grado di garantire che quelle tecnologie ci sono. La possibilità di definire la baseline è anche un modo per potersi adeguare via via all'evoluzione tecnologica. La conformità è sempre articolata su tre livelli, però essi corrispondono ad accessibilità, accessibilità migliorata, ulteriore miglioramento. Per il livello 3 si prevede il superamento di tutti i criteri di successo di livello A, e doppia A, e almeno il 50% di quelli di tripla A. E poi la dichiarazione di conformità è molto più sofisticata, nel senso che si possono dire molte più cose proprio perché i siti cambiano nel tempo, o possono avere livelli di accessibilità diversi nelle loro varie parti, etc. Tra le altre cose si può specificare nella dichiarazione di conformità il tipo di utenza che si prevede debba usare il sito. Ma nello specificare il tipo di utenza a cui è rivolto il sito non si può in alcun modo far riferimento alle disabilità, quindi non si può dire che il sito è destinato a tutti, tranne quelli che hanno una particolare disabilità, ma si può dire per esempio che è un sito di fisica teorica, è quindi è previsto che l' utente abbia un certo livello di conoscenze. Veniamo ora alle domande più frequenti relativamente alle WCAG 2.0. Le WCAG 2.0 hanno avuto un percorso molto più lungo dell'usuale, anche perché il tema è molto sentito. Vi saranno molti documenti, ma quello che descrive le guideline è l' unico documento da seguire per rispettare lo standard. Gli altri sono documenti tecnici che contengono suggerimenti e illustrano le tecniche da utilizzare. Molti si chiedono quando sarà pubblicata la versione definitiva delle guideline. Si pensava che fossero già disponibili nel 2006, ora si pensa che il processo sarà completato nel 2007. Sull' ultimo Last Call sono state presentate oltre 900 osservazioni e ne sono state esaminate già più della metà. I problemi su cui si dibatte sono la terminologia, la definizione di baseline, e i problemi di disabilità cognitive. Ma cosa deve fare uno sviluppatore? Se sta usando le WCAG 1.0 ed è conforme alle WCAG 1.0 (in Italia i siti pubblici dovrebbero avere già un livello superiore alle WCAG 1.0), non dovrebbe dover apportare modifiche rilevanti per quanto riguarda gli aspetti strettamente tecnici. Si può anche pensare di cominciare ad applicare subito le WCAG 2.0 perché ormai il documento è abbastanza maturo. Mentre prima a volte tra un documento e l'altro c'erano differenze notevolissime, adesso si tratta spesso di differenze minime, quindi ormai il documento sta convergendo verso una forma finale. Le linee guida WCAG 2.0 dovrebbero essere più applicabili perché tengono conto anche delle nuove esigenze e delle nuove tecnologie. Chi sviluppa tecniche nuove potrebbe farle aggiungere nel documento "Techniques for WCAG 2.0", e quindi farle comparire come tecnica approvata dal W3C. Tra le novità in arrivo, va segnalato il progetto europeo
WAI-AGE, che affronta i problemi di accessibilità legati all' invecchiamento e inizierà nel 2007. Sul versante specifiche W3C, vi è la consapevolezza che vada rivista la specifica per i browser
(UAAG - User Agent Accessibilità Guidelines). Il punto di discussione è se verrà fatta una piccola revisione (quindi una versione 1.1) o una riscrittura totale (allora una versione 2.0). Ho già accennato alla "sindrome del bollino". Il problema non è "come certificare un sito" ma "come fare un sito accessibile". Tutta la problematica dell'accessibilità nel W3C è stata pensata come un processo collaborativo e cooperativo, quindi tutti gli atteggiamenti censori sono solo dannosi. Non si può tollerare quindi che appena un' organizzazione pubblica un sito in cui dichiara di aver fatto del suo meglio per renderlo accessibile si scatenino critiche e osservazioni da ogni parte, magari non da disabili o organizzazioni che li rappresentano. Bisogna essere più collaborativi, mi piacerebbe veder sollevate critiche costruttive, e trovare dei webmaster che rispondano a osservazioni sensate in tempi ragionevoli e, soprattutto, intervengano poi a migliorare le carenze segnalate. Alcuni errori possono essere corretti in tempi brevi, altri interventi possono essere più impegnativi e richiedere più tempo. Intollerabile è l' arroccamento su posizioni rigide, o la mancata risposta alle osservazioni. In definitiva l' accessibilità è un un approccio culturale e non dobbiamo pensare solo alle disabilità, ma anche a superare differenze culturali, perché ci dimentichiamo troppo spesso che abbiamo molti immigrati che non parlano bene la nostra lingua, e che magari scrivono da destra a sinistra. Ci sono perciò problemi di internazionalizzazione, di multilinguismo etc. che andrebbero affrontati per rendere un sito veramente accessibile. Il W3C è in prima linea su queste tematiche.
|