Preview only show first 10 pages with watermark. For full document please download

Iii. Metodologie E Tecniche Di Applicazione

Transcript

UNIVERSITÀ POLITECNICA DELLE MARCHE FACOLTÀ DI INGEGNERIA SEDE DI ANCONA NORMATIVE, METODOLOGIE E TECNICHE PROGETTUALI PER LA REALIZZAZIONE DI SITI WEB AD ELEVATA ACCESSIBILITÀ. TESI DI LAUREA TRIENNALE IN INGEGNERIA INFORMATICA ED AUTOMATICA. AUTORE RELATORE ANGELO MORESCHI PROF. ING. ALDO FRANCO DRAGONI REVISIONE 1.0 - MARZO 2007 A mia madre, a mio padre. ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE. SOMMARIO I. Introduzione ............................................................................................ 1 II. Scenario................................................................................................ 3 II.1 - Per una cultura dell’accessibilità ............................................................... 3 II.2 - Il concetto di accessibilità ........................................................................ 7 Beneficiari dell’accessibilità ...................................................................................... 8 Gli obiettivi dell’accessibilità ..................................................................................... 9 II.3 - Usabilità .............................................................................................. 12 Presentazione ....................................................................................................... 12 Accessibilità ed Usabilità ........................................................................................ 14 Normative ............................................................................................................ 16 II.4 - La disabilità ......................................................................................... 18 Definizione WHO ................................................................................................... 18 Disabilità in cifre ................................................................................................... 19 Tipologie della disabilità ......................................................................................... 20 II.5 - Il W3C ................................................................................................ 26 Gli obiettivi .......................................................................................................... 27 Le Raccomandazioni .............................................................................................. 27 La WAI ................................................................................................................ 29 III. Metodologie e tecniche di applicazione ............................................... 32 III.1 - Il linguaggio ....................................................................................... 32 HTML .................................................................................................................. 33 XHTML................................................................................................................. 43 CSS .................................................................................................................... 47 III.2 - L’accessibilità in 10 punti ...................................................................... 54 Suggerimenti rapidi. .............................................................................................. 54 Commento ........................................................................................................... 55 Circolare Bassanini ................................................................................................ 59 III.3 - Componenti essenziali dell’accessibilità .................................................. 61 Separazione tra contenuto e presentazione .............................................................. 63 Fogli di stile (CSS) ................................................................................................ 67 Utilizzo degli elementi strutturali ............................................................................. 77 Rispetto dell’aspetto semantico .............................................................................. 85 Il principio della multi-modalità .............................................................................. 87 - IV - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE. III.4 - Indipendenza dal dispositivo di presentazione ......................................... 88 III.5 - Trattamento delle immagini .................................................................. 91 Strumenti del linguaggio ........................................................................................ 91 Testi alternativi .................................................................................................... 95 Tipologie di immagini ............................................................................................ 98 Annotazioni conclusive ......................................................................................... 100 Ascii Art .............................................................................................................. 101 III.6 - Uso del colore ................................................................................... 102 Principi fisici ........................................................................................................ 103 Criteri di realizzazione .......................................................................................... 106 III.7 - Impaginazione e tabelle ..................................................................... 116 Uso delle tabelle .................................................................................................. 116 Tabelle dati ......................................................................................................... 117 Tabelle di impaginazione ....................................................................................... 120 Impaginazione ..................................................................................................... 125 III.8 - Contenuti multimediali ....................................................................... 129 Metodologie ........................................................................................................ 131 Tecniche e strumenti ............................................................................................ 135 Conclusioni ......................................................................................................... 139 III.9 - Tecniche specifiche ............................................................................ 140 Apertura nuove finestre ........................................................................................ 140 Auto aggiornamenti.............................................................................................. 141 Collegamenti ipertestuali ...................................................................................... 142 Grammatiche formali ............................................................................................ 144 Fogli di stile secondari .......................................................................................... 146 Fotosensibilità ..................................................................................................... 149 Frameset ............................................................................................................ 150 Linguaggi per rappresentazioni specifiche ............................................................... 153 Mappe immagine ................................................................................................. 159 Moduli ................................................................................................................ 162 Navigazione ........................................................................................................ 169 III.10 - Web dinamico ................................................................................. 179 Script ................................................................................................................. 181 Applet e plug-in ................................................................................................... 186 AJAX .................................................................................................................. 187 III.11 - Comprensibilità dei contenuti ............................................................ 189 Scrivere per farsi capire ........................................................................................ 190 -V- ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE. Suggerimenti in (X)HTML ...................................................................................... 193 Pubblica Amministrazione ..................................................................................... 196 III.12 - Riadattamento a posteriori................................................................ 198 III.13 - Compatibilità con le tecnologie obsolete ............................................. 200 Retro-compatiblità ............................................................................................... 201 Aderenza agli standard ......................................................................................... 202 III.14 - Validazione e controllo ..................................................................... 204 Metodologia di verifica .......................................................................................... 204 Validatori automatici ............................................................................................ 208 La cultura del bollino ............................................................................................ 215 III.15 - I costi dell’accessibilità ..................................................................... 216 L’accessibilità come punto di partenza .................................................................... 218 Costo zero .......................................................................................................... 218 IV. Analisi delle normative ..................................................................... 220 IV.1 - Normative internazionali ..................................................................... 220 IV.2 - WCAG 1.0 ......................................................................................... 223 Introduzione ....................................................................................................... 223 Organizzazione e conformità ................................................................................. 224 Linee guida e punti di controllo .............................................................................. 226 Critiche ed attuazione ........................................................................................... 238 IV.3 - Section 508....................................................................................... 242 Linee guida per le pagine Web ............................................................................... 243 Relazione con le direttive WAI ............................................................................... 248 Relazione con la legge italiana ............................................................................... 250 IV.4 - Legge Stanca .................................................................................... 252 Decreto legislativo 216/2003 ................................................................................. 254 Legge 04/2004 .................................................................................................... 255 Codice della Pubblica Amministrazione Digitale ........................................................ 262 Regolamento di attuazione .................................................................................... 263 Requisiti tecnici (Decreto Ministeriale 8 Luglio 2005) ................................................ 267 Valutazione requisiti Internet ................................................................................ 287 Verifica soggettiva ............................................................................................... 289 Comparazione con la Section 508 .......................................................................... 289 Secondo disegno di legge Campa Palmieri ............................................................... 293 Stato di attuazione ............................................................................................... 294 IV.5 - WCAG 2.0 ......................................................................................... 295 - VI - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE. Presentazione ...................................................................................................... 295 Organizzazione .................................................................................................... 303 Normativa ........................................................................................................... 306 Mappatura WCAG 1.0 e 2.0 ................................................................................... 309 Critiche............................................................................................................... 312 Relazione con il DM 8 Luglio 2005 .......................................................................... 319 IV.6 - Quadro sinottico ................................................................................ 320 IV.7 - ISO .................................................................................................. 325 Normative ........................................................................................................... 325 IV.8 - UAAG ............................................................................................... 327 IV.9 - ATAG ............................................................................................... 330 Versione 2.0........................................................................................................ 331 Contenuti ............................................................................................................ 333 Conformità .......................................................................................................... 334 IV.10 - ARIA .............................................................................................. 336 Web dinamico accessibile ...................................................................................... 337 Schema del progetto ............................................................................................ 337 V. L’accessibilità nella realtà ................................................................. 340 V.1 - Ausili informatici per i disabili ............................................................... 340 Strumenti per i non vedenti .................................................................................. 340 Strumenti per ipovedenti ...................................................................................... 343 Accorgimenti per audiolesi .................................................................................... 344 Strumenti per le disabilità motorie ......................................................................... 345 Gli strumenti per le disabilità cognitive. .................................................................. 346 Conclusioni ......................................................................................................... 347 V.2 - Programmi utente ............................................................................... 348 Screen-reader ..................................................................................................... 348 V.3 - Strumenti di sviluppo .......................................................................... 353 CMS ................................................................................................................... 354 V.4 - L’accessibilità nei sistemi operativi ........................................................ 360 Microsoft Windows ............................................................................................... 361 Linux .................................................................................................................. 369 Apple MAC OS X .................................................................................................. 371 DOS ................................................................................................................... 373 V.5 - Applicativi e formati proprietari ............................................................. 375 Microsoft Word .................................................................................................... 377 - VII - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE. Adobe PDF .......................................................................................................... 379 Adobe Flash ........................................................................................................ 385 V.6 - Interviste ........................................................................................... 389 Paolo de Cecco .................................................................................................... 389 VI. Un esempio reale .............................................................................. 402 VI.1 - Presentazione in XHTML...................................................................... 402 Progetto ............................................................................................................. 403 Codice XHTML ..................................................................................................... 403 Codice CSS ......................................................................................................... 409 VII. Appendice – Riferimenti alle normative ......................................... 414 VII.1 - WCAG 1.0 ........................................................................................ 414 Abstract.............................................................................................................. 414 Introduction ........................................................................................................ 415 Themes of Accessible Design ................................................................................. 417 How the Guidelines are Organized .......................................................................... 418 Priorities ............................................................................................................. 418 Conformance ....................................................................................................... 419 Web Content Accessibility Guidelines ...................................................................... 419 VII.2 - Section 508 ..................................................................................... 432 Table of Contents................................................................................................. 432 Subpart A -- General ............................................................................................ 432 Subpart B -- Technical Standards ........................................................................... 435 Subpart C -- Functional Performance Criteria ........................................................... 438 Subpart D -- Information, Documentation, and Support ............................................ 439 VII.3 - Legge Stanca ................................................................................... 440 Legge n. 4 del 9 gennaio 2004 .............................................................................. 440 Regolamento di attuazione della legge 9 gennaio 2004, n. 4 ..................................... 444 Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici. ............... 445 Requisiti tecnici - Allegato A .................................................................................. 450 Requisiti tecnici - Allegato B .................................................................................. 456 VII.4 - WCAG 2.0 ........................................................................................ 459 Abstract.............................................................................................................. 459 Introduction ........................................................................................................ 460 Conformance ....................................................................................................... 462 WCAG 2.0 Guidelines ........................................................................................... 465 - VIII - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE. VIII. Glossario........................................................................................ 472 VIII.1 - Glossario generale ........................................................................... 472 VIII.2 - Glossario WCAG 1.0 ......................................................................... 478 IX. Riferimenti ........................................................................................ 485 IX.1 - Bibliografia........................................................................................ 485 IX.2 - Link Utili ........................................................................................... 485 - IX - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE. -X- ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR I. Introduzione Viviamo in una società basata sull’informazione e la conoscenza. In quest’età, successiva a quella industriale, l’informazione è sempre più un bisogno primario e la tecnologia, dal computer ai chioschi informativi, dai messaggi di posta elettronica alla ADSL, è sempre di più il mezzo per trasmettere, conservare e creare l’informazione. L’accesso alla tecnologia dell’informazione rappresenta perciò sempre più un’opportunità di conoscenza, istruzione e lavoro e acquisisce sempre maggior importanza nel modo di vivere, di lavorare e di apprendere. Si può in qualche modo equiparare l’accesso alle tecnologie ed il loro pieno utilizzo ad un diritto primario per tutti i cittadini, nessuno escluso. 1 La scelta di questo argomento per la tesi in Ingegneria Informatica ed Automatica è dovuta all’interesse ed alle funzionalità sempre maggiori ricoperte dai servizi Web nel mondo attuale. La mole di informazioni veicolate a questo moderno strumento informativo meritano che esso venga reso accessibile ed usabile per quanti più fruitori possibili. Il pubblico dominio dell’informazione ha come necessaria premessa la sua accessibilità, questa fa parte della natura intrinseca di internet e del Web la cui potenzialità è proprio quella di fornire a tutti le informazioni depositate. A questo proposito risulta illuminante il motto del W3C, il principale ente preposto alla guida dello sviluppo del Web di cui parleremo diffusamente in seguito. E’ un pensiero di Tim BernersLee, attuale direttore del W3C e padre del Web. Il motto, tradotto in italiano, recita: "La forza del Web sta nella sua universalità. L'accesso da parte di chiunque, indipendentemente dalle disabilità, ne è un aspetto essenziale" 2. Questo lavoro ha, quindi, come finalità quella di esporre le metodologie dell'accessibilità e fornire al lettore gli strumenti tecnici e culturali adatti per progettare e realizzare siti Web ad elevata accessibilità. Nella esposizione sono stati parzialmente tralasciati gli aspetti squisitamente tecnici ed operativi se non necessari per la trattazione, una impostazione eccessivamente puntuale esula infatti dagli scopi questo compendio e può venire più efficacemente acquisita da studi e da siti più specifici. 1 Tecnologie per la disabilità: Libro bianco. Introduzione. [http://www.innovazione.gov.it/librobianco/] “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect” - [http://www.w3.org/WAI/] 2 -1- ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Data la natura compilativa della tesi sono stati riportati per intero molti pensieri di autori che ho trovato particolarmente illuminanti durante la stesura. Spesso ho ritenuto opportuno citare per intero il testo originale, o tradurlo nella maniera più fedele possibile, soprattutto quando il concetto era stato già espresso in maniera efficace e sintetica. Ovviamente non è mai stata mia intenzione appropriarmi delle idee e delle ricerche di altri. Tutti gli stralci sono corredati dalle opportune citazioni in nota. Per non appesantire la lettura, tuttavia, ho scelto di non virgolettare i concetti più lunghi, limitandomi a rientrarne il principio del paragrafo e riportando alla fine una nota di rimando a piè pagina. Per quanto riguarda l’esposizione della materia, ho deciso di organizzarla in pochi capitoli fondamentali:  Scenario: presentazione degli elementi fondamentali della materia e delle problematiche attinenti;  Metodologie e tecniche di applicazione: panoramica della metodologia generale e delle tecniche comuni di buona programmazione per siti Web alla base di tutte le normative seguenti;  Analisi delle normative: analisi delle 4 normative fondamentali che sono considerate in questo momento come le più rilevanti in tema di accessibilità. In appendice sono riportati degli stralci essenziali;  L’accessibilità nella realtà: un inquadramento del problema dal punto di vista dei fruitori dei servizi;  Un esempio reale: una applicazione pratica in XHTML e CSS dei concetti esposti. Prima di iniziare la trattazione vorrei ricordare i miei genitori che mi sono stati sempre d’incitamento e di sprone nel portare a termine il mio corso di studi. Per questo e per molto altro ancora, a loro va il mio continuo ringraziamento. -2- ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR II. Scenario Il primo capitolo di questa trattazione presenta una panoramica dell’argomento. Molte delle problematiche dovute alla crescita disorganica del Web, prassi comune fino a qualche hanno fa, hanno fatto nascere con urgenza le motivazioni che portano allo studio e alla considerazione dell’accessibilità. Con questo sguardo d’insieme si vuole introdurre l’argomento di studio. E’ un capitolo preliminare per arrivare nella parte successiva alla disamina delle metodologie universalmente riconosciute per la migliore prassi in materia. II.1 - Per una cultura dell’accessibilità Il 2003 è stato l’Anno europeo delle persone con disabilità. Per quanto riguarda l'uso di Internet e in particolare del Web, ciò ha significato un'attenzione maggiore rivolta ai problemi che i disabili incontrano quotidianamente nel tentativo di utilizzare informazioni e servizi presenti in rete. 1 Preoccuparsi di rendere fruibile il contenuto di Internet dal punto di vista di queste categorie di utenti svantaggiati significa preoccuparsi di renderlo accessibile. Vale la pena ricordare a proposito, come affermato da Luca Mascaro in una conferenza dell’IWA 2, che il Web nasce in realtà accessibile, solo in seguito, soprattutto con il cattivo utilizzo degli elementi di impaginazione questo importante aspetto si è andato perdendo. Sino a qualche anno fa l’accessibilità era considerata un argomento di nicchia, un qualcosa utilizzato dai puristi del codice che non comprendevano le potenzialità grafiche offerte dalla rete. Grazie però a diverse iniziative, molte delle quali promosse in Italia dall'associazione IWA Italy (International Webmaster Association), si è cercato di creare una cultura dell'accessibilità e molti autori di pagine Web stanno comprendendo la necessità di sviluppare in modo bello e accessibile, ossia abbinando una grafica d'impatto alla possibilità di fornire l'accesso anche a chi non può fruire di tali effetti speciali a causa di disabilità, anche di solo tipo tecnologico. Nel Gennaio 2004, proprio sulla scorta di questa filosofia (“Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici” recita, infatti, il suo titolo), in Italia è stata concepita la Legge 04/2004, presentata dall’allora Ministro per l'innovazione tecnologica Lucio Stanca. 1 2 Roberto Scano: “Accessibilità, dalla teoria alla realtà”, capitolo 1 Roberto Ellero, Luca Mascaro - Seminario IWA/IWG – Arese, Maggio 2005 -3- ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Una normativa che si prefigge l'obiettivo di rendere obbligatorio il rispetto delle regole di accessibilità quanto meno da parte di tutti i siti che appartengano alla Pubblica Amministrazione o che svolgano un servizio pubblico. Con questa normativa diventa indispensabile, per gli sviluppatori e gli editori di contenuti che dovranno applicare questa legge nel loro lavoro quotidiano, acquisire le competenze necessarie a rispettare le regole che essa stabilisce. 1 Il campo di applicazione è sostanzialmente rivolto alle Amministrazioni Pubbliche, ma il concetto base è volto ad orientare gli sviluppatori verso quello che potremmo definire un metodo di buon sviluppo: un modo di realizzare pagine Web e siti, basato sul rispetto dei linguaggi standard del W3C e delle linee guida sull'accessibilità. Un buon sviluppo si contrappone alla prassi diffusa di un cattivo sviluppo, che è il modo tradizionale di procedere fondato sull'uso puro e semplice degli editor visuali, sull'ignoranza del codice che vi sta dietro e sulla creazione di vincoli di presentazione inutili, che impediscono l'accesso ai contenuti a numerose categorie di utenti. Occorre ripensare dalle basi il modo di progettare la realizzazione di siti e pagine Web: la ricerca dell'accessibilità non deve intervenire alla fine, per tentare di mettere rattoppi alle falle create dal cattivo sviluppo; deve essere, invece, un obiettivo della progettazione. Una pagina nata male può essere resa in qualche modo accessibile, nel peggiore dei casi creando un documento alternativo più navigabile. Non sarà mai però una pagina ad elevata accessibilità e richiederà sempre una gran quantità di lavoro, ogni volta che sarà necessario aggiornare la veste grafica del sito o introdurre qualche cambiamento relativo all'accessibilità dei contenuti. Perseverare nel cattivo sviluppo non è perciò una scelta conveniente 2. Se i gestori di siti che rientreranno nell'ambito di applicazione della legge attuale vorranno rispettare le raccomandazioni di accessibilità e, allo stesso tempo, trovare un sistema di lavoro efficace ed economico, non potranno che indirizzarsi verso queste regole. Un sito ad elevata accessibilità non è altro che un sito pensato e costruito secondo le regole del buon sviluppo: è una struttura progettata secondo i migliori criteri di stabilità e di funzionalità. Quindi, scopo di questa e di molte altre trattazioni propedeutiche in materia è di creare una vera e propria cultura negli sviluppatori, qualcosa che arricchisca il bagaglio culturale e 1 Michele Diodati: “Guida all’accessibilità dei siti Web” “Attuare le linee guida sull'accessibilità comporta, e oltretutto solo nella fase iniziale, costi non di molto superiori a quelli che conseguirebbero alla loro mancata attuazione”- Documento economico correlato alla Comunicazione CE del 25 Settembre 2001. 2 -4- ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR tecnologico di chi progetta siti e induca a considerare una programmazione accessibile come l’unico modo di realizzare delle pagine Web. Si tratta di fare proprio un metodo di lavoro ed una competenza in materia, allo stesso modo con cui si sono appresi i rudimenti della programmazione in (X)HTML, aggiungendo di passo in passo nuova conoscenza: dalle basi a JavaScript, dalla gestione dei moduli alle interrogazioni delle basi di dati. L’accessibilità è semplicemente la successiva competenza da acquisire. 1 Per di più, non corrisponde per nulla al vero il fatto che questa tecnica vada a scapito di una gradevole presentazione visuale dei siti. A tal proposito vorrei ricordare alcune fondamentali considerazioni di uno dei maggiori esperti in materia, Joe Clark. Nel suo testo fondamentale sull’accessibilità l’autore ha premesso alla trattazione un’interessante lista di miti da sfatare. Ne riporto una sintesi essenziale e tradotta. Per la versione originale e completa ci si può riferire al testo citato in bibliografia. Mi si voglia perdonare l’approssimativa traduzione. L’accessibilità è debolmente compresa, e circondata una vasta gamma di luoghi comuni 2:  L’accessibilità è costosa (“Access is expensive”): Lo è, per un sito vasto e se viene applicata in un secondo momento. Adattare a posteriori costa sempre molto. In tutti gli altri casi può costare ma non è necessariamente dispendiosa. In cambio si otterranno nuovi visitatori.  L’accessibilità è utile a troppe poche persone (“Access serves too few people”): L’accessibilità serve per le minoranze. Ovviamente è utile a poca parte delle persone. Ma vanno ricordate le persone reali che stanno dietro le piccole percentuali. La numerosità di questi campioni ha comunque una sua rilevanza come vedremo in un punto successivo. Va in oltre considerato il fatto che qualsiasi persona non disabile ora potrebbe divenire una persona disabile in futuro.  L’Accessibilità è troppo difficile. (“Accessibility is too hard”): In tutta onestà qualche aspetto della accessibilità può risultare eccessivamente difficoltoso. Tuttavia, rendere usabili i siti Web dalle persone disabili è generalmente semplice anche per sviluppatori alle prime armi.  Il Web è visuale (“The Web is visual”): Con poche eccezioni il Web è un canale comunicativo visuale. Ma lo sono anche la 1 2 Joe Clark: “Accessibility, quite simply, is the next skill you have to learn”, (Building Accessible Websites) Joe Clark:”Building Accessible Websites” -5- ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR televisione e i film e diversi studi hanno ripetutamente dimostrato come i non vedenti e gli ipovedenti hanno lo stesso interesse nel guardare televisione e film. Vivono nello stesso mondo dei vedenti e comprendono che il Web è un utile veicolo di informazioni, intrattenimento, comunicazione e socializzazione.  Non è il nostro mercato (“It’s not our market”): Risulta evidente da se che qualche prodotto Web è intrinsecamente inaccessibile per le persone lese nella vista, ad esempio siti di scuole di guida o enti militari. D’altra parte queste persone hanno amici e parenti. Un simile modo di ragionare può essere molto pericoloso per i siti di commercio elettronico. E guardiamolo da un punto di vista morale, se fosse tecnicamente possibile creare un sito Web che escludesse ebrei, donne o anziani, lo fareste? Lo stesso autore propone poi una valida lista di motivi per cui occuparsene:  E’ un obbligo di legge (“It’s the law”): In Italia, con la legge 04/2004 è divenuto un obbligo per le Pubbliche Amministrazioni pubblicare dei siti Web Accessibili. Leggi analoghe sono in vigore negli Stati Uniti, in Canada, in Australia, nel Regno Unito ed in altre parti del mondo. La trattazione approfondita di questa materia è sviluppata in un capitolo dedicato di questa tesi;  E’ un’altra freccia nel vostro arco (“Another arrow in your quiver”): Come accennato in precedenza l’accessibilità è semplicemente la successiva competenza che si deve apprendere, né più né meno di come si sono apprese le altre nozioni necessarie per produrre pagine Web;  Ridondanza (“Redundancy”): Un principio basilare dell’accessibilità è quello di fornire alternative, dove si trova una immagine occorre dare anche il testo. Una forma di ridondanza utile. I progettisti Web con esperienza, scrivono già utilizzando questo principio ripetendo ad esempio i comandi di navigazione, i comandi di ricerca, gli ausili alla navigazione. L’accessibilità fornisce semplicemente un’altra forma di ridondanza;  Arricchimento (“Richness”): Quando sono stati inventati i rollover in JavaScript hanno arricchito le pagine Web. Allo stesso modo l’accessibilità prosegue su questa linea. Una pagina accessibile fornisce testo a comparsa, funzionalità alternative e variazioni particolari che possono essere attivate solo quando la pagina viene pronunciata anziché visualizzata;  Vale di più (“It’s worth more when you flip it”): Un sito Web costruito con i principi dell’accessibilità ha un valore maggiore di quanto non lo abbia un sito inaccessibile. L’accessibilità diventa uno dei tanti attributi a cui si può dare un prezzo al momento di venderlo;  -6- Conformità agli standard (“Standards compliance”): ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR La tendenza attuale del Web è quella di livellarsi alle migliori qualità. Per metà decennio sono stati aggiunti estensioni non standard al Web. Questa linea è oramai al tramonto. Il vantaggio principale di adeguarsi agli standard è la realizzazione dell’obiettivo “scrivere una volta, leggere ovunque”1. Invece di codificare la pagina per tutte le differenti versioni dei browser, si scrive una sola pagina in accordo con le specifiche, ed ogni dispositivo la leggerà correttamente. La conformità agli standard è una forma di maturità nella programmazione;  Maturità sociale (“Social maturity”): Progettare per l’accessibilità richiede progettare per persone che non sono esattamente come noi, e questo è vero sia che il progettista sia un disabile, sia che non lo sia. Per chiudere questa breve perorazione della causa della accessibilità vorrei riportare un pensiero di Jim Thatcher: “Quasi tutta la tecnologia Web può essere resa accessibile con nessuna conseguenza sull’aspetto visivo. Ed, in oltre, il procedimento è piuttosto agevole.”2. II.2 - Il concetto di accessibilità Per capire di cosa tratta l'accessibilità vorrei ricorrere ad alcune definizioni. La prima definizione è quella della parola inglese accessible ("accessibile", in italiano), contenuta nel glossario delle WCAG 1.0 allegato in appendice. Tradotto in italiano risulta: "Un contenuto è accessibile quando può essere usato da qualcuno con una disabilità"3. Questa lettura riporta direttamente il riferimento ai disabili come ai maggiori fruitori del servizio. La Legge 04/2004, dal canto suo, definisce come accessibilità4: “la capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari”. Il termine anche ci fa capire che potrebbe non essere sufficiente considerare solo le persone disabili nella progettazione di siti ad alta accessibilità. 1 “Write once, read anywhere.” “Almost all Web technology can be made accessible with no impact on the visual appearance. And, as we shall see, the process is fairly simple.” [http://www.jimthatcher.com/webcourse1.htm] 3 "Content is accessible when it may be used by someone with a disability" [http://www.w3.org/TR/WCAG10/] 4 Legge 04/2004, articolo 2, comma (a) 2 -7- ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR A questa lettura va sicuramente aggiunto quanto prima riportato come motto del W3C: "La forza del Web sta nella sua universalità. L'accesso da parte di chiunque, indipendentemente dalle disabilità, ne è un aspetto essenziale".1 Evidenzierei quindi due elementi fondamentali dell'accessibilità:  L'attenzione ai problemi di accesso al Web dei disabili;  L’attenzione a garantire l'universalità dell'accesso, in altre parole a non escludere nessuno: non solo i disabili in senso stretto, ma anche chi soffre di disabilità temporanee, chi ha attrezzature obsolete, chi usa sistemi poco comuni, chi dispone di connessioni particolarmente lente.2 In accordo con questo secondo punto tenderei a dare una definizione che includa anche gli utenti che non sono disabili in senso stretto. Di base, una tecnologia è accessibile se può essere usata con efficienza da persone con disabilità come da quelle senza. 3 Su questo punto di vista ci viene in aiuto anche la definizione4 degli obiettivi di accessibilità data nelle WCAG 2.0, il testo in lingua originale può essere reperito in appendice: “Seguire queste linee guida renderà anche i contenuti Web più usabili a molti altri utenti, inclusi le persone anziane. In oltre permetterà alle persone di accedere al web utilizzando dispositivi differenti, inclusa una vasta gamma di tecnologie assistive e tecnologie per apparecchiature portatili”. Beneficiari dell’accessibilità Come accennato, i disabili in senso stretto sono solo una parte, e neppure la più cospicua dei beneficiari dell’accessibilità. Le stesse linee guida WCAG 1.0 ne presentano una nutrita lista nel loro preambolo introduttivo. A questo proposito Michele Diodati5 ha sintetizzato accuratamente le categorie di utenti per i quali, per un campo di applicazione o per un altro, la realizzazione di siti accessibili può tornare utile. Ne riporto un elenco sintetico, un ulteriore approfondimento sulle considerazioni sulle tecnologie dei singoli casi può essere reperito nell’articolo originale: 1 “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” - [http://www.w3.org/WAI/] 2 Michele Diodati: “Guida all’accessibilità dei siti Web” 3 “Basically, technology is accessible if it can be used as effectively by people with disabilities as by those without.” [http://www.jimthatcher.com/webcourse1.htm] 4 WCAG 2.0: Abstract 5 Michele Diodati: [http://diodati.org/scritti/2004/guida/ele_acc07.asp] -8- ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Persone con normali problemi della vista quali miopia, presbiopia, astigmatismo, ipermetropia, cataratta, eccetera: sono milioni, soprattutto tra gli ultraquarantenni;  Persone anziane e/o dotate di scarsa o nulla preparazione informatica;  Persone di livello culturale basso o bassissimo;  Persone che parlino un'altra lingua;  Persone che usino software obsoleti;  Persone che dispongano di hardware obsoleto e connessioni lente;  Persone che usino sistemi e periferiche poco comuni. A cui vanno aggiunti gli utenti che navighino utilizzando: o Un normale televisore (webTV); o Telefoni cellulari di ultima generazione dotati di browser (Nokia, Eriksson, ecc.) e schermo da 160-172 pixel; o Computer palmari con schermi larghi mediamente 240 pixel; o Agendine elettroniche tipo Psion; o Monitor impostati a risoluzioni particolarmente elevate (2048x1536) o particolarmente basse (il "vecchio" standard 640x480); o Monitor monocromatici o con un numero di colori ridotto (16 o 256); o Chioschi multimediali con selezione tramite tatto; o Periferiche comandabili a voce;  Persone che si colleghino in condizioni ambientali difficili;  Indicizzatori automatici (chiamati "robot" o, in inglese, "spider") provenienti da motori di ricerca. Gli obiettivi dell’accessibilità Per quanto l’accessibilità si proponga degli obiettivi a vasto raggio, occorre tener presente che, proprio per la numerosità degli utenti coinvolti in questo processo, non sempre e non tutto può essere raggiunto. Un articolo introduttivo a questo proposito, illuminante per definizioni e chiarezza, è quello di Jim Byrne1. L'articolo analizza i numerosi problemi e le contraddizioni che sorgono quando si tenta di realizzare in concreto un'accessibilità veramente universale. Byrne parte dal concetto generico di accessibilità che non contempli a priori le direttive WAI e ne espone le possibili chiavi di lettura. In tal senso un sito accessibile potrebbe essere: 1 Jim Byrne “What is an accessible Website?” [http://www.mcu.org.uk/articles/whatisaw.html] -9- ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Un sito che è accessibile a chiunque,  Un sito che è accessibile ad un pubblico specifico, per quanto probabilmente non lo sia per tutti,  Un sito che è accessibile alle persone disabili,  Un sito che sia accessibile innanzi tutto alle macchine e di conseguenza alle persone. Il primo obiettivo, per quanto appaia in prima battuta il fine migliore da perseguire, rischia di condurre ad un progetto utopico, quantomeno se si deve tener conto dei problemi di linguaggio e di conoscenze1 di tutti i potenziali utenti. Per mirare invece ad ottenere il secondo tipo di accessibilità in senso lato occorrerebbe comunque essere a conoscenza delle capacità fisiche e cognitive del pubblico selezionato e progettare per tutte le tecnologie Web di questi utenti, browser, tecnologie assistive, ampiezza degli schermi ed altri accorgimenti, oltre che per tutte quelle future. Per quanto riguarda l’accessibilità per i disabili, non vi sono dubbi che progettare siti con queste caratteristiche sia uno degli obiettivi da perseguire. E tuttavia risulterebbe sicuramente inefficiente se dovessimo mirare a soddisfare l’utente finale specifico, rischiando di arrivare a delle soluzioni molto difficili da produrre ed aggiornare. In sostanza occorre spostare l’attenzione dal contenuto al modo di predisporlo. Gli accessi alle pagine Web sono ottenuti tutti mediante qualche tipo di tecnologia, e questo è vero sia per i disabili che per chiunque altro. Tecnologie assistive come display Braille, browser vocali, tastiere adattative non sono altro che dispositivi da aggiungere alla lista degli altri programmi utenti più conosciuti come PDA, smartphone ed altro. Il sistema per garantire a questa svariata mole di dispositivi il corretto funzionamento è semplicemente quello di utilizzare il linguaggio a marcatori del Web, l’HTML, nella maniera corretta. Se vogliamo rendere accessibile il contenuto Web per le persone, il primo passo è garantire che le nostre pagine siano accessibili alle tecnologie che le persone utilizzano, e questo è ottenibile impiegando gli standard dell’HTML 2. 1 Jim Byrne: “I'm inclined to think that not all Web documents will be made more accessible by re-writing them in short sentences and using simple words. Some will, but not all - and to satisfy this first definition we need to be accessible to everyone.” 2 Jim Byrne: “If we want to make our content accessible to real people and the first step to achieving this is to ensure that our pages are accessible to the technology that people will be using. The best chance we have of doing that is to create our pages using standard HTML.” - 10 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Il passo immediatamente conseguente a questa lettura è quello della separazione del contenuto dalla sua presentazione che sarà poi a carico degli specifici programmi utente. Di questo aspetto parleremo meglio nel capitolo dedicato alle metodologie generali. Al termine della sua presentazione Byrne riassume i concetti esposti in alcuni punti fondamentali.  Cercare di rendere i nostri contenuti accessibili a tutti indistintamente è pressoché impossibile. L'accessibilità è un concetto relativo: dipende dal proprio pubblico di riferimento, dalla conoscenza che si ha dei suoi bisogni e dalle risorse che si hanno a disposizione;  Non è possibile controllare il modo in cui una pagina sarà presentata all'utente finale. La sola cosa su cui è possibile avere un controllo assoluto è il codice di marcatura usato nelle pagine;  Tutti i contenuti arrivano all'utente attraverso un qualche tipo di computer e di browser;  Il primo passo per creare siti accessibili è creare siti che siano accessibili alle macchine. La migliore opportunità per ottenere ciò è usare HTML standard;  Quando il contenuto può essere diviso dalla presentazione, usando i fogli di stile, il medesimo contenuto può essere presentato in molti modi differenti. Non occorre pertanto preoccuparsi di creare molteplici versioni di una stessa pagina per venire incontro ai bisogni di un pubblico diversificato;  Le linee guida del W3C sull'accessibilità possono essere usate per rendere i siti Web basati sugli standard più flessibili e più capaci di soddisfare i diversi bisogni degli utenti. Insomma, rendere una pagina Web accessibile alle macchine (computer e browser) e flessibile nella struttura sono gli obiettivi principali a cui evidentemente puntano le raccomandazioni di accessibilità.1 In ciò la differenza con l'usabilità è grande: quest'ultima infatti lavora essenzialmente sull'interazione tra la pagina e gli utenti, anzi le specifiche categorie di utenti considerate come pubblico di riferimento dei siti da testare. La differenza fra queste due finalità viene trattata in un capitolo a parte. 1 Michele Diodati: [http://diodati.org/scritti/2004/guida/ele_acc06.asp] - 11 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR II.3 - Usabilità Penso che sia importante distinguere le definizioni delle due discipline. In questa breve discussione vorrei distinguere i due concetti di accessibilità ed usabilità delimitandone, per quanto possibile, i campi di utilizzo. Molto del materiale qui esposto è tratto da alcune lezioni su internet di professionisti competenti, tra cui Michele Diodati1, Maurizio Boscarol2 e Dario Violi3, ai cui articoli citati rimando per una lettura più completa. Presentazione Prima di passare a chiarire quali sono le relazioni con l’accessibilità presento una breve premessa sull’usabilità, necessaria, a mio avviso, a chiarirne meglio la definizione e gli scopi. Definizione Una definizione data da Roberto Scano in una intervista ne definisce meglio gli aspetti. L'usabilità è la possibilità di accedere ad informazioni e servizi in modo semplice ed intuitivo, garantendo ad un elevato numero di persone di poter raggiungere un obiettivo in pochi e semplici passi. L'usabilità nel Web è un argomento altamente dibattuto e, a differenza dell'accessibilità, non vi sono degli standard internazionalmente riconosciuti ma ad oggi esistono solo delle raccomandazioni di esperti che consentono di valutare l'usabilità di un sito Web.4 Vediamo le definizioni ISO del termine usabilità. Si rintraccia in due norme:  Secondo la definizione data dalla norma ISO 9241, l'usabilità è il "grado in cui un prodotto può essere usato da particolari utenti per raggiungere certi obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto d'uso.”5  Secondo la definizione data dalla norma ISO 9126, l’usabilità è una qualità del software, in particolare “la capacità di essere compreso, appreso, usato con soddisfazione dall’utente in determinate condizioni d’uso”. Trasportata in ambito Web, questa definizione ci dice che lo scopo dell'usabilità è quello di 1 Michele Diodati: [http://diodati.org/scritti/2004/guida/ele_acc06.asp] Maurizio Boscarol: [http://www.usabile.it/012000.htm] 3 Dario Violi: [http://webdesign.html.it/articoli/leggi/1672/usabilita-e-accessibilita/] 4 [http://www.scarichiamoli.org/main.php?page=interviste/scano] 5 "[Usability refers to] the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of user." - ISO 9241-11 [http://www.usability.gov/basics/whatusa.html] 2 - 12 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR studiare l'interazione tra l'utente e il sito, o tra l'utente e la singola pagina Web, con l'obiettivo di mettere in luce gli ostacoli che di volta in volta si frappongono ad un uso efficace, efficiente e soddisfacente delle informazioni e dei servizi contenuti nel sito o nella pagina. 1 Storia dell’usabilità La normativa ISO 9241 è del 1993 e si riferisce ai prodotti informatici in genere. Tuttavia l'usabilità è un concetto precedente e più esteso: nasce negli anni 60 nell'ambito dell'ergonomia in relazione a qualunque interazione uomo-artefatto. Compito degli studi di usabilità è fare in modo che il modello mentale di chi ha progettato il software (design model), da cui deriva il suo reale funzionamento, corrisponda il più possibile al modello mentale del funzionamento del software così come se lo costruisce l'utente finale (user model). L'usabilità nasce dunque soprattutto come ausilio alla progettazione, e si applica in particolare alle interfacce. E' con l'interfaccia di un software, infatti, che l'utente si relaziona. Va sottolineato che l'usabilità ha senso solo in presenza di un utente e di una relazione d'uso, e non esiste nel prodotto in sé. Le tecniche di usabilità tentano dunque di porre al centro dell'attenzione progettuale proprio l'utente. Può sembrare un dettaglio scontato, sembra ovvio che il prodotto venga progettato per chi lo usa. Invece, dato che fino a tutti gli anni 70 il computer non era un prodotto di massa, i principali utilizzatori dei prodotti software finivano per essere gli stessi progettisti o persone esperte con una formazione mentale simile ai progettisti. Di conseguenza l'usabilità era un problema implicito, sapendo progettare il software, si sapeva anche usarlo. Lo schema mentale del progettista e quello dell’utente erano gli stessi. Tale problema è invece emerso dapprima negli anni 80, con la diffusione delle tecnologie informatiche a livello di ufficio e di famiglia, ed è esploso negli anni 90, con la diffusione del personal computer. Gli utenti finali del software e dell’hardware non erano più i progettisti. Macintosh è stato il primo computer con un sistema operativo completamente visuale, basato sulla metafora della scrivania e dello spostamento intuitivo degli oggetti. Si trattava di un cambiamento radicale. Macintosh si propose come computer orientato all'uso da parte di persone completamente a digiuno di informatica. Poco dopo Windows riutilizzò la stessa struttura diffondendosi rapidamente e tutti i programmi utilizzati presentano un'interfaccia di tipo visuale. Non serve essere esperti per farli funzionare ed il problema della usabilità si pone con urgenza. 1 Michele Diodati: [http://diodati.org/scritti/2004/guida/ele_acc06.asp] - 13 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Con l'avvento di Internet e la proliferazione dei siti Web, il problema si sposta sul nuovo dominio, dove naturalmente dovrà tener conto delle caratteristiche dell'interazione, in qualche caso anche molto diverse da quelle tipiche del software. Se nel caso di un software questo viene normalmente usato dopo esser stato acquistato, un sito Web invece viene prima usato, e solo se l'uso risulta soddisfacente può dar vita ad una transazione ed eventualmente ad un guadagno. L’usabilità deve essere immediata ed efficace. Accessibilità ed Usabilità I termini accessibilità ed usabilità sono spesso utilizzati in modo confuso, in effetti le loro reciproche sfere di influenza tendono in certi casi a sovrapporsi visto che sono effettivamente materie affini. Entrambe hanno come scopo, nel nostro specifico, il miglioramento delle interfacce Web. Entrambe, inoltre, partono dal presupposto che i siti dovrebbero essere fruiti attraverso qualunque browser, e che la correttezza formale del codice, da sola, non rende un sito accessibile né usabile. Può capitare che l'esperto di accessibilità, una volta soddisfatti i requisiti di compatibilità tra browser, si convinca di aver realizzato un sito usabile, o che un esperto di usabilità cada nello stesso sbaglio pensando di aver realizzato un sito accessibile una volta completato il suo lavoro. Una distinzione è dunque necessaria per una buona progettazione dei siti Web. Sovrapposizioni e differenze La sovrapposizione tra gli obiettivi dell'usabilità e quelli dell'accessibilità si verifica per quelle raccomandazioni che puntano a migliorare l'accessibilità dei contenuti. Rendere l'uso di una risorsa più semplice e soddisfacente nella fruizione è appunto anche lo scopo dell'usabilità. A questo proposito, durante il seminario IWA sulla legge Stanca1 di cui si parlerà diffusamente in seguito, Luca Mascaro ha espresso il concetto che l’usabilità, applicata su una base di una già raggiunta accessibilità del sito consente di ottenere la fruibilità completa dei contenuti. Le due discipline presentano sostanziali differenze sia a livello concettuale sia, soprattutto, a livello metodologico. Innanzitutto, mentre nell’accessibilità la priorità è data all'accesso ai contenuti, nell’usabilità la priorità è data alla loro comprensione. Nel primo caso la progettazione è orientata alle caratteristiche del sito, nel secondo al processo produttivo. 1 Roberto Ellero, Luca Mascaro - Seminario IWA/IWG – Arese, Maggio 2005 - 14 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR L'accessibilità rivolge le sue raccomandazioni allo sviluppatore tralasciando più o meno completamente di occuparsi del rapporto tra il risultato e l'utente finale: rendere una pagina Web accessibile alle macchine e flessibile nella struttura sono gli obiettivi principali a cui puntano le raccomandazioni di accessibilità. L’usabilità invece lavora essenzialmente sull'interazione tra la pagina e gli utenti, anzi le specifiche categorie di utenti considerate come pubblico di riferimento dei siti, dal momento che l'usabilità va intesa relativamente ad una specifica categoria di utenti finali. La differenza si riscontra anche osservandone i metodi. La realizzazione di un sito accessibile passa attraverso il rispetto di determinate norme come ad esempio le 14 linee guida delle WCAG 1.0 o i 22 requisiti della Legge Stanca, e la valutazione dell'accessibilità può essere svolta con strumenti automatici o semiautomatici per una sostanziosa parte del lavoro. La realizzazione di un sito usabile, invece, avviene attraverso l'interpretazione di modelli più che il rispetto di regole e, soprattutto, la valutazione dell'usabilità vede coinvolti in prima persona i potenziali utenti piuttosto chele macchine. Usabilità al servizio dell'accessibilità Pensare all'accessibilità, quindi, non significa soltanto progettare affinché un sito possa essere letto attraverso qualunque dispositivo, ma anche generare strutture chiare e contenuti comprensibili. In questo caso i metodi dell'usabilità, possono aiutare nella progettazione di un sito accessibile intervenendo ai livelli in cui l'applicazione di specifiche tecniche non è sufficiente, e nel progetto dell'architettura dell'informazione. In assenza di un progetto di usabilità, infatti, l'applicazione dei soli requisiti tecnici può essere insufficiente a garantire la comprensione di un ipertesto e talvolta può perfino nuocere alla navigazione. Per esempio, le regole dell'accessibilità insegnano ad agevolare la lettura tramite uno screen-reader sostituendo i collegamenti ipertestuali troppo generici clicca qui con dei collegamenti contestualizzati, ma la scelta di quale testo utilizzare implica i metodi di progettazione e valutazione dell'usabilità. Sempre a proposito di screen-reader, le WCAG chiedono di specificare la lingua del documento e di indicare il cambiamento di lingua per ogni parola straniera, al fine di migliorare la lettura con uno strumento in grado di accedere a vocabolari multi-lingua. Un cambiamento nella lingua del sintetizzatore, però, produce anche variazioni nel timbro della voce e altera il ritmo della lettura, senza contare che alcuni vecchi applicativi spesso perdono molto tempo nel caricare il dizionario di lettura opportuno. Tutto questo può risultare più fastidioso dell'ascoltare una parola straniera letta con una pronuncia sbagliata e non va incontro all’usabilità del sito. Ma anche le teorie alla base dell'accessibilità si rivelano estremamente utili ai fin della progettazione di un sito usabile. Molti dei problemi di usabilità sono infatti legati alla scarsa accessibilità dei contenuti. - 15 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Se gli utenti del sito sono persone con problemi di vista, un testo scritto a caratteri troppo piccoli risulterà poco leggibile, così come dei collegamenti troppo ravvicinati rischiano di generare problemi di navigazione anche a persone senza limitazioni nei movimenti. La ricerca dell'accessibilità ha permesso di comprendere al meglio i limiti di tutti gli utenti e, soprattutto, di progettare e realizzare siti che tengano conto di tali limiti. A questo proposito vorrei ricordare un passo di una intervista di Jim Thatcher, secondo cui l’accessibilità Web deve essere vista come parte dell’usabilità. Per una persona disabile usabilità è quello che altri chiamano accessibilità, poiché deve utilizzare il sito con software come gli screen-reader.1 Normative Vediamo come le normative considerate hanno trattato il tema dell’usabilità. Nell’elenco non viene riportata la normativa americana in quanto non si occupa direttamente del tema nella sezione considerata. WCAG 1.0 Le ultime tre raccomandazioni2 delle WCAG 1.0 mirano agli aspetti cognitivi dell'interazione dell'utente con la pagina. L'usabilità ha anche questi scopi. L'appendice A delle WCAG 1.0 propone una serie di metodi che consistono principalmente nella validazione automatica del codice della pagina per mezzo di appositi software. Ma ai punti 9 e 10 dell'appendice si fa un riferimento a possibili test con utenti umani, pur senza suggerire specificamente il ricorso ai metodi sviluppati in questo campo dall'usabilità. Nella stessa definizione di accessibilità poi si dice che un contenuto è accessibile quando può essere usato da qualcuno con una disabilità; questa definizione rende l'usabilità parte integrante dell'accessibilità. L'accessibilità diventa quindi requisito per l'usabilità nel momento in cui sono stati focalizzati gli utenti di riferimento. Se, in teoria, l'accessibilità di un sito ne prevede l'usabilità, le WCAG 1.0 non sono un ottimo strumento per la realizzazione di un sito usabile. Pur raccomandando la chiarezza dei contenuti e della struttura ipertestuale (punti 12, 13 e 14) le WCAG nascono come strumento per gli sviluppatori, professionisti del processo produttivo di un sito Web che spesso hanno poca dimestichezza con i meccanismi dell'usabilità. 1 [http://www.fucinaweb.com/fw/jimthatcher/] 12: "Fornire informazione per la contestualizzazione e l'orientamento", 13: "Fornire chiari meccanismi di navigazione" e 14: "Assicurarsi che i documenti siano chiari e semplici" 2 - 16 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Per le WCAG l'usabilità è parte della definizione di accessibilità, ma non è parte del metodo. Legge 04/2004 La legge 04/2004 riprende una sostanziale differenziazione dei due concetti distinguendo tra un primo ed un secondo livello di accessibilità. Il Decreto Ministeriale 8 luglio 2005 allegato alla legge Stanca recante i requisiti tecnici è parzialmente riportato in appendice. Il legislatore italiano suddivide la verifica soggettiva e la verifica oggettiva, deputando alla prima, previo esito corretto della verifica tecnica, il conseguimento degli obbiettivi di accessibilità dei contenuti e alla seconda la qualità delle informazioni fornite e dei servizi erogati dal sito Ai 22 requisiti tecnici derivati dalle linee guida delle WCAG 1.0, sufficienti per ottenere il requisito di accessibilità dei contenuti, si affianca, con il nome di verifica soggettiva, la valutazione dell'usabilità. In questo secondo caso la metodologia prevede infatti l'analisi del sito da parte di uno o più esperti di fattori umani, la definizione di scenari d'uso per simulare il comportamento dell'utente e, soprattutto, il coinvolgimento diretto di utenti disabili. Si tratta quindi di un vero e proprio test di usabilità, richiamati per altro anche nei criteri di valutazione: dove troviamo, ad esempio, la comprensibilità, l'operabilità, la coerenza, la tolleranza agli errori e la gradevolezza, elementi che fanno da componenti essenziali al concetto di usabilità. WCAG 2.0 Anche il gruppo di lavoro che sta elaborando le WCAG 2.0 ha deciso di assumere, fin dal documento normativo principale, una posizione esplicita nella suddivisione delle finalità e di più netto orientamento verso l’accessibilità. Nel paragrafo Abstract della bozza di lavoro delle WCAG 2.0 si afferma che seguire queste linee guida renderà anche il contenuto Web più usabile a molti altri utenti, incluse le persone anziane. Si ribadisce però che le linee guida non includono raccomandazioni standard di usabilità a meno che esse non abbiano uno specifico impatto sull’accessibilità 1. Di fatto molte delle raccomandazioni contenute nei tre ultimi principi delle linee guida 1.0, proprio quelle più vicine al tema dell’accessibilità, vengono tenute in una considerazione molto minore nella versione 2.0. Il terzo principio, quello della comprensibilità, che più dovrebbe riassumerne gli aspetti, non contiene, infatti, riferimenti espliciti ai concetti dell’usabilità. Con questo non si vuole certo dire 1 “The guidelines do not include standard usability recommendations except where they have specific impact on accessibility.” - 17 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR che le WCAG 2.0 siano un passo indietro, semplicemente hanno invece voluto maggiormente distinguere le due discipline e focalizzarsi meglio sui compiti specifici dell’accessibilità. II.4 - La disabilità Per capire meglio a quali problematiche va incontro l’accessibilità, vorrei dare un inquadramento più preciso al concetto di disabilità, fornendone definizioni e caratteristiche dei problemi inerenti la fruizione dei servizi Web. Definizione WHO Secondo la definizione data nel 1980 dall’Organizzazione Mondiale della Sanità 1, nota come International Classification of Impairments, Disabilities and Handicaps (ICIDH-1), sono definiti i termini:  Menomazione (impairment): qualsiasi perdita o anormalità a carico di una struttura o una funzione psicologica, fisiologica, anatomica.  Disabilità (disability): limitazione o perdita (conseguente a menomazione) della capacità di compiere una attività nel modo e nell’ampiezza considerati normali.  Handicap (handicap): condizione di svantaggio conseguente a una menomazione o a una disabilità che limita o impedisce l’adempimento del ruolo normale per tale soggetto,in relazione all’età, al sesso, ai fattori socio-culturali. Questa definizione, sia pure non recente, è, di fatto, più corretta rispetto al modo comune di parlare e affrontare il problema degli handicap. Essa, infatti, evidenzia come alcune persone, a seguito di una menomazione, possano avere delle limitazioni nella capacità di svolgere certe azioni, e siano poste in una condizione di svantaggio, che potrebbe spesso essere ridotta adottando opportune azioni o accorgimenti.2 Così, ad esempio, una persona su sedia a rotelle è sicuramente disabile, ma potrebbe potenzialmente non essere handicappata se al mondo fossero eliminate tutte le barriere architettoniche, cosicché non gli verrebbe precluso l’accesso a nessun settore della vita sociale. È evidente che, in tale accezione, si può contare il numero delle persone con disabilità, ma non di handicappati; la condizione di handicap è prettamente soggettiva e dipende dalle aspettative di vita e esigenze della persona disabile.3 Ancora più ampia è la International Classification of Functioning, Disability and Health (ICF 1 2 3 World Health Organization [http://www.who.int] Oreste Signore: “Handimatica 2004” [http://www.disabilitaincifre.it/] - 18 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR ICIDH-2) data, sempre dalla Organizzazione Mondiale della Sanità (WHO), nel 2001. 1 Questa nuova classificazione relativa alla salute e ai domini legati alla salute permette di descrivere le modifiche nelle funzioni e strutture corporee, e quindi ciò che le persone possono fare in un ambiente standard (livello di capacità) e nel loro ambiente abituale (livello di performance). I domini vengono classificati dal punto di vista corporeo, individuale e di relazione per mezzo di due liste: la lista delle funzioni e strutture corporee, e quella dei domini di attività e partecipazione. Nella classificazione ICF, il termine funzionamento (functioning) fa riferimento a tutte le funzioni corporee, mentre disabilità (disability) è un termine generico per riferirsi a menomazioni, limitazioni delle attività e restrizioni alla partecipazione. Questa nuova classificazione si differenzia quindi dalla precedente perché parla di funzionamento umano in generale (functioning) e non puramente di disabilità, e fornisce un modello universale, che non riguarda solo una minoranza. Proprio perché pone l’enfasi sul funzionamento umano, essa integra gli aspetti medici e quelli sociali, e non fa riferimento esplicito a eventuali menomazioni, né costringe a esplicitare il tipo di disabilità. Per le sue caratteristiche, copre l’intero arco della vita, e considera anche le caratteristiche dei bambini e degli anziani. In altri termini, si passa da definire le conseguenze di un disturbo ad analizzare i componenti della salute. Disabilità in cifre Penso che sia opportuno dare un quadro delle persone in Italia che sono interessate ad ottenere siti accessibili. Per questo mi rifaccio al sito dell’ISTAT (Istituto Nazionale di Statistica) sulla disabilità2. Dati completi ed informazioni aggiornate possono essere direttamente reperiti sul sito originale. La principale fonte di dati utilizzata per stimare il numero delle persone con disabilità presenti in Italia è l'indagine ISTAT sulle Condizioni di salute e il ricorso ai servizi sanitari. Essa è però parziale, e va quindi integrata per giungere a una stima complessiva. 3 In base alle stime ottenute dall’indagine sulla salute e il ricorso ai servizi sanitari, emerge che in Italia le persone con disabilità sono circa 2.615.000, pari al 5% della popolazione di 6 anni e più che vive in famiglia. La stima si basa su un criterio molto restrittivo di disabilità, quello secondo cui vengono considerate persone con disabilità unicamente quelle che nel corso dell'intervista hanno riferito 1 2 3 Oreste Signore: “Handimatica 2004” [http://www.disabilitaincifre.it/] [http://www.disabilitaincifre.it/prehome/stima_numerodisabili.asp] - 19 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR una totale mancanza di autonomia per almeno una funzione essenziale della vita quotidiana. Se consideriamo in generale le persone che hanno manifestato una apprezzabile difficoltà nello svolgimento di queste funzioni la stima allora sale a 6.980.000, pari al 13% della popolazione, che vive in famiglia, età superiore ai 6 anni. Tale dato è in linea con quello rilevato nei principali paesi industrializzati. Sfuggono tuttavia le persone che, soffrendo di una qualche forma di disabilità non fisica ma mentale, sono in grado di svolgere tali attività essenziali. Considerando il numero di persone che vivono in famiglia, la stima del numero di bambini sotto i 6 anni e le persone residenti nei presidi socio-sanitari si giunge ad una stima complessiva di poco più di 2.800.000 persone con disabilità. E' bene chiarire ancora che si tratta di stime, che presumibilmente distorcono verso il basso il reale numero di persone con disabilità in Italia. Poiché, infatti, le persone con disabilità in famiglia vengono rilevate tramite indagine campionaria col metodo dell'intervista diretta alla disabile o a un suo familiare, non si può escludere che vi sia una sottostima, dipendente dal tipo di disabilità, dovuta alla mancata dichiarazione della presenza di tali persone in famiglia. Tipologie della disabilità Le tipologie della disabilità, per quanto attinente l’argomento di questa trattazione, possono essere sostanzialmente riassunte in tre categorie fondamentali, come avviene soprattutto in autori italiani1:  Disabilità sensoriali; in cui ricadono le varie disfunzioni della vista e dell’udito, le più rilevanti da un punto di vista di accesso al Web;  Disabilità motorie;  Disabilità cognitive. Le disabilità sensoriali sono di una tale rilevanza che questa categoria potrebbe anche essere ulteriormente scissa in una suddivisione ulteriore dei gruppi, come avviene spesso in molti autori anglo americani2:  Sordi (Deaf, hard-of-hearing, hearing-impaired);  Ciechi (Blind, visually-impaired, low-vision);  Menomazioni motorie (Mobility-impaired);  Disabili nell’apprendimento (Learning-disabled, cognitive disabilities). 1 Luca Mascaro, Conferenza IWA del 16 maggio 2005 ad Arese. Marco Calvo, Accessibilità dei siti internet. [http://www.e-text.it/servizi/internet/accessibilita/accessibilita.htm] 2 Joe Clark: “Building Accessible Websites” [http://joeclark.org/book/] - 20 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Vediamo adesso alcune brevi informazioni riassuntive sulle disabilità menzionate. La fonte è quella ministeriale1. Disabilità sensoriali Come esposto in precedenza nelle disabilità sensoriali riassumo:   Disabilità della vista; o Non vedenti; o Ipovedenti; Disabilità dell’udito. La disabilità della vista comprende tipicamente due classi di utenti in quanto i modi di accesso al computer sono diversi nei due casi. Infatti i non vedenti devono utilizzare dispositivi di output fisicamente diversi dal monitor, basati o su un'uscita audio, come un sintetizzatore vocale, o su un'uscita tattile, come il display Braille. Le persone ipovedenti, invece, utilizzano il monitor come dispositivo d’uscita dell'informazione, anche se con opportune modifiche. Disabilità sensoriali: i non vedenti Il problema che limita l'accesso delle persone non vedenti ai contenuti delle pagine Web consiste nel seguire e comprendere la strutturazione di un'interfaccia utente di tipo grafico, come Windows. Per i non vedenti, passare da un sistema conosciuto, relativamente semplice da usare, come il DOS, ad un sistema operativo complesso come Windows, non è assolutamente facile. Per questo motivo, molti di loro preferiscono lavorare ancora in DOS, utilizzando un browser di tipo testuale per accedere al Web, come Lynx. Attualmente, però, la maggior parte della progettazione relativa ai contenuti del Web è indirizzata ad una modalità di fruizione di tipo visivo. Per consentire alle persone non vedenti di accedere ai contenuti così organizzati, è necessario che questi stessi vengano interpretati in una forma alternativa: sonora o tattile. Per realizzare l'interpretazione dei contenuti in forma alternativa esistono degli strumenti, tra i quali lo screen-reader. Strumenti come questi compiono l'analisi e la rilettura degli elementi 1 [http://www.pubbliaccesso.gov.it/biblioteca/manualistica/accessibilita_siti/introduzione/ profili.htm] - 21 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR grafici dello schermo e la loro opportuna traduzione o descrizione testuale mediante dispositivi di uscita, come la barra Braille o il sintetizzatore vocale. ll grado di efficienza di questi strumenti dipende dalla complessità della struttura dell'informazione presentata sullo schermo. In ogni caso, questi strumenti non riescono, in modo completo, a riprodurre in forma alternativa l'aspetto completo dell’interfaccia utente. La complessità e la struttura delle pagine Web influenzano direttamente l’accessibilità per chi utilizza strumenti particolari. A questo punto entra in gioco la figura dell'autore di pagine Web. Attraverso un'oculata e studiata progettazione della pagina, lo sviluppatore potrà realizzare pagine che rendano più facile la conversione dei contenuti da parte dei programmi degli screen-reader. Disabilità sensoriali: gli ipovedenti Gli ipovedenti sono persone con capacità visiva gravemente ridotta. Essi non hanno bisogno di periferiche particolari, oltre che di un monitor di grandi dimensioni. Gli ipovedenti devono, però, praticare adattamenti alla propria postazione di lavoro: impostare una definizione molto bassa, scegliere una combinazione di desktop con caratteri grandi e colori ben marcati; usare dei puntatori del mouse più grandi del normale e possibilmente colorati. Disabilità sensoriali: cecità ai colori Una descrizione più approfondita merita il concetto di cecità totale o parziale ai colori. Il motivo è dovuto all’utilizzo del colore come veicolo di informazioni, il quale, come conseguenza a questa menomazione, deve necessariamente essere considerato dalle normative sull’accessibilità. Uno studio molto accurato di questa disfunzione fisica lo si può trovare sul testo di Joe Clark1 a cui rimando senza dubbio per un approfondimento completo. In questa sede espongo solamente gli elementi essenziali, rimandi utili possono essere consultati anche sul sito ufficiale dell’Associazione Acromati Italiani 2. Nella retina dell'occhio normale ci sono due tipi di cellule sensibili alla luce (fotorecettori): i coni e i bastoncelli:  Coni (circa 6 milioni) sono prevalentemente concentrati al centro della retina, nella regione denominata macula, e sono specializzati per la visione diurna: permettono di 1 2 Joe Clark: “Building Accessible websites”, chapter 9 [http://www.acromatopsia.it/] - 22 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR adattarsi alla luce, percepire i colori e distinguere i dettagli fini. Sono di tre tipi: i coni rossi (sensibili a onde lunghe), i coni verdi (sensibili a onde medie) e i coni blu (sensibili a onde corte), funzionano con livelli di luce più intensi. Le loro differenti risposte, secondo la lunghezza delle onde, ci rendono possibile la vista dei colori durante il giorno;  Bastoncelli (circa 100 milioni) sono prevalentemente alla periferia della retina e sono specializzati per la visione notturna: sono molto più sensibili alla luce dei coni ma si saturano rapidamente quando essa aumenta e non permettono di percepire i colori né di distinguere bene i dettagli. Nell'occhio normale i coni e i bastoncelli si integrano tra loro e permettono di vedere in qualunque condizione d'illuminazione. Nella retina delle persone affette da acromatopsia (acromati), invece, tutti i coni funzionano molto poco o non funzionano per niente. Queste persone, perciò, devono affidarsi unicamente ai bastoncelli per vedere: di conseguenza sono parzialmente o totalmente cieche ai colori, hanno una scarsa acuità visiva e i loro occhi non sono in grado di adattarsi in modo normale a una luce più intensa di quella del crepuscolo. Accanto alla acromatopsia, piuttosto rara, ci sono le cecità parziali ai colori, invece più diffuse. Il difetto deriva da alterazioni dei geni che decodificano i pigmenti dei coni, due dei quali, i pigmenti dei coni rossi e verdi, sono legati al sesso; da qui la maggior incidenza negli uomini piuttosto che nelle donne. La perdita di funzione di uno dei pigmenti dei coni, e quindi del corrispondente tipo di coni, riduce la visione dei colori, che in genere è tridimensionale o tricromatica con una dimensione corrispondente a ciascuna delle sensibilità spettrali dei coni, e la modifica da tridimensionale a bidimensionale o bicromatica. Le relative malattie sono:  La protanopia: indica la mancanza del pigmento dei coni rossi;  La deuteranopia: indica la mancanza dei coni verdi;  La tritanopia: indica la mancanza dei coni blu. I primi due difetti (protanopia e deuteranopia) sono associati alla cecità per il rosso e per il verde, o per la confusione del verde e giallo, e del giallo e rosso tra loro. Differiscono principalmente nel fatto che i rossi appaiono relativamente più scuri ai pronatopi piuttosto che ai deuteranopi, perché il pigmento dei coni verdi dei deuteranopi assorbe la luce rossa con meno efficacia del pigmento dei coni rossi. La tritanopia è, invece, associata con la cecità per il giallo e il blu o la confusione del viola, del blu e del blu-verde tra loro. Il termine cecità per il giallo-blu è un termine ingannevole, in - 23 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR quanto, se i dicromatici rossi-verdi confondono il rosso con il verde, le persone affette da tritanopia non confondono mai il giallo con il blu. Più frequenti, ma meno gravi, forme di cecità parziale per i colori, note come tricromatismo anomalo, sono causate dalla sostituzione dei pigmenti dei coni rossi o verdi con un pigmento anomalo codificato da un gene ibrido rosso-verde o verde-rosso:  La protanomalia è la funzione deviante dei pigmenti dei coni rossi;  La deuteranomalia è la funzione deviante dei pigmenti dei coni verdi. Per dare un'idea di come la cecità ai colori influenzi la percezione di una pagina Web, si possono utilizzare degli opportuni i filtri software disponibili sul sito Colorblind Web Page Filter1. Le pagine Web generate possono mostrare le visioni osservate da persone con cecità ai colori. Disabilità sensoriali: gli audiolesi Attualmente le informazioni nell'ambito dei siti Web vengono trasmesse anche con l'impiego di elementi audio. Quando questi diventano parte consistente e significativa dell'informazione, comportano problemi di accessibilità per le categorie di utenti con problemi all'udito, che devono forzatamente rinunciare all'informazione trasmessa con l'audio. Per questo motivo, l'informazione audio, se rilevante, deve essere trasformata in una forma alternativa efficace e comprensibile per tutti gli utenti. Le disabilità dell'udito si suddividono in:  Sordità pre-verbale: riguarda le persone sorde dalla nascita. Queste non riescono a sviluppare il linguaggio in modo normale senza una terapia riabilitativa;  Sordità peri-verbale: riguarda le persone diventate sorde verso i 3/4 anni. Esse perdono quasi completamente l'uso della parola se non si utilizzano apposite protesi;  Sordità post-verbale: riguarda le persone diventate sorde dopo la completa acquisizione della parola. Benché conservino pressoché inalterato il proprio patrimonio linguistico, spesso viene compromessa la comunicazione verbale. Disabilità motorie L'arco delle disabilità di tipo fisico è piuttosto ampio. 1 [http://colorfilter.wickline.org/] - 24 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Si va da una modesta paralisi su un arto, all'incapacità di controllare i propri movimenti a causa di spasmi nervosi. Nel peggiore dei casi la mobilità residua è quasi nulla, tanto che l'interazione col computer può avvenire solo mediante l'invio di un comando d'assenso, come il battito dell'occhio, il movimento del capo o il soffio in una cannuccia, per la selezione dell'azione proposta dal computer con una lista di possibilità. In tutti questi casi, la difficoltà di accesso al mondo del Web riguarda l'utilizzo dei dispositivi d'ingresso con cui l'utente invia i comandi. La difficoltà di accesso al mondo del Web, da parte dei disabili motori, riguarda l'utilizzo dei dispositivi d'ingresso con cui l'utente invia i comandi, in particolare del mouse e della tastiera. Nello specifico, il principale problema da superare è l'uso del mouse. E' indispensabile, quindi, che l'utilizzo del mouse non sia mai essenziale per interagire con i programmi, fornendo per ogni comando almeno un’alternativa via tastiera. Principio esposto per altro molto chiaramente nelle WCAG 2.0 1. La gestione della tastiera diventa, quindi, un aspetto essenziale per poter utilizzare un computer. Si pensi alla necessità di:  Ottenere tutti i caratteri con un solo dito o con la leva del caschetto, utilizzato da alcune categorie di disabili motori;  Ridurre al minimo gli errori involontari, dovuti a tremolio della mano o alla pressione troppo prolungata del tasto;  Offrire un punto di appoggio al braccio o alla mano, in modo da aumentarne stabilità e precisione. La tecnologia ha dato risposte molto valide per ridurre i problemi di accesso dei disabili motori al Web. Una delle modifiche più semplici e comuni da apportare alla tastiera è l'applicazione di una mascherina, una griglia copri-tastiera fissa, di plexiglas o metallo, con dei fori in corrispondenza dei vari tasti. In questo modo sarà possibile appoggiare la mano sulla tastiera ed infilare nei fori le dita per premere solo i tasti che interessano. 1 Guideline 2.1: “Make all functionality operable via a keyboard interface” - 25 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Disabilità cognitive Le disabilità cognitive sono molteplici e comprendono una numerosa serie di varianti che possono anche dipendere da altre disabilità fisiche dell’individuo. Riguardano una vasta varietà di problemi. Si può sommariamente dividerli in:  Deficit di linguaggio primari o secondari;  Deficit cognitivi primari o conseguenti a patologie neurologiche o genetiche;  Disturbi specifici di apprendimento come le dislessia o la disgrafia. Si può tentare di evidenziare, con molta prudenza, alcuni aspetti comuni relativi alle disabilità cognitive. L'utente affetto da tale disabilità farà fatica ad accedere, cioè a capire pagine Web troppo complesse, o in cui le componenti in movimento siano troppo veloci. Questo perché le sue capacità residue potrebbero non consentirgli di cogliere fino in fondo tutti gli aspetti dell'informazione introdotta nella pagina. Ad esempio, per un disabile cognitivo, un'immagine al posto di una lunga scritta è un modo migliore e più sintetico per seguire un certo itinerario di navigazione in rete. Gli effetti lampeggianti, invece, aumentano la difficoltà di comprensione dell'informazione contenuta nella pagina. Per quanto riguarda lo sviluppo di contenuti Web, è necessario fare comunque presente che è spesso impossibile fornire contenuti fruibili da tutti gli utenti con disabilità cognitive, alcune di queste disabilità sono talmente gravi da non consentire la comprensione neppure di contenuti chiari e semplici: l'uso delle immagini, per esempio, può risultare utile per talune categorie di disabilità cognitive, mentre per altre può portare a confusione e problemi nell'apprendimento. II.5 - Il W3C Il World Wide Web Consortium (W3C) è un consorzio internazionale, neutrale rispetto ai venditori, che, grazie al contributo dei suoi membri, guida l’evoluzione del Web, definendo protocolli comuni che ne favoriscano l’ evoluzione e ne assicurino l’interoperabilità.1 Il W3C, per sua stessa espressione è stato creato “Per guidare il World Wide Web al suo pieno potenziale sviluppando protocolli e linee guida che garantiscano una crescita a lungo termine per il Web”2. 1 Oreste Signore: “Handimatica 2004” “To lead the World Wide Web to its full potential by developing protocols and guidelines that ensure longterm growth for the Web” - [http://www.w3.org/Consortium/about-w3c.html] 2 - 26 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR La sua fondazione risale al 1994, ad opera di Tim Berners-Lee, attuale direttore del W3C e artefice del World Wide Web (WWW). Gli obiettivi Il World Wide Web Consortium (W3C) crea gli standard Web. 1 Per portare il Web al suo massimo potenziale definisce lo sviluppo di tecnologie, specifiche, linee guida, software e strumenti che possano creare un punto di incontro per informazioni, commercio, ispirazioni, pensiero indipendente e comprensione collettiva. Tra i punti cardine che scaturiscono da quest’impostazione c’e quello dell’Accesso Universale. Il W3C definisce il Web come l'universo delle informazioni accessibili in rete (disponibili attraverso il computer, il telefono, la televisione, o il frigorifero telematico eccetera). Oggigiorno questo universo permette alla società di fruire di nuove forme di comunicazione umana e offre nuove opportunità di condividere la conoscenza. Uno degli scopi principali del W3C è quello di rendere queste opportunità fruibili a tutti, indipendentemente da eventuali limitazioni determinate da hardware, software, supporto di rete a disposizione, lingua madre, cultura, posizione geografica, capacità fisiche e mentali. L'impegno del Consorzio per l'accesso universale è dimostrato da varie attività come:  Internationalization Activity;  Device Independence Activity;  Voice Browser Activity;  Web Accessibility Iniziative (WAI). Le Raccomandazioni Il funzionamento del consorzio è regolato da un insieme di regole contenute nel Process Document (W3CPD), che viene periodicamente verificato e adeguato, dietro accettazione da parte dei membri, alle esigenze emergenti. Un aspetto essenziale è che le decisioni vengono prese a seguito di un processo che prevede il raggiungimento del consenso dei partner. Questo significa che, anche se non sempre è possibile raggiungere l'unanimità, si ha comunque cura di non prendere decisioni su cui non ci sia accordo da parte di una vasta maggioranza. Tutte le osservazioni vengono valutate dal punto di vista tecnico. 2 1 2 [http://www.w3c.it/w3cin7punti.html] Oreste Signore: “Handimatica 2004” - 27 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Il prodotto più visibile dell’attività del Consorzio sono le Recommendation, documenti tecnici stabili, sui quali si può fare affidamento per sviluppare tecnologie o applicazioni che costituiscono la base per la realizzazione di sistemi interoperabili. Le W3C Recommendation sono il risultato di un processo cooperativo, regolato dal Process Document, che prevede una serie di passi e di rendiconti prodotti. Alcuni documenti sono riservati ai partecipanti ai gruppi di lavoro, altri sono disponibili per i membri, che votano per approvarli o modificarli, altri sono pubblici. Schematicamente possiamo riassumere il processo 1 che porta alla pubblicazione di una Recommendation, il cosiddetto maturity level di un documento, con una strutturazione a fasi di questo tipo:  Working Draft (WD): Un documento pubblicato specificatamente per essere valutato dalla comunità, inclusi i membri del W3C, il pubblico e le altre organizzazioni tecniche. Generalmente vengono pubblicati diversi Working Draft prima di arrivare all’ultimo richiamo. La pubblicazione di un Working Draft non indica nessun impegno del W3C a farlo diventare una Recommendation. I Working Draft sono bozze in fase di sviluppo, soggetti a discussione e modifica in ogni momento da parte dei membri del gruppo di lavoro.  Last Call working Draft: Quando il gruppo di lavoro ritiene che siano stati considerati tutti i commenti e i requisiti tecnici, viene predisposto il documento completo per la revisione della comunità e viene annunciato l’ultimo richiamo. Va notato che dopo la scadenza del periodo per l’ultimo richiamo possono passare settimane o mesi prima che il gruppo di lavoro consideri tutti i documenti e faccia i cambiamenti necessari. Se ci sono sostanziali modifiche è possibile che i resoconti tecnici vengano considerati in un ulteriore ultimo richiamo successivo;  Candidate Recommendation (CR): Lo scopo principale di una Candidate Recommendation è garantire che tutti i resoconti tecnici possano essere implementati. Il W3C incoraggia gli sviluppatori a utilizzare i resoconti tecnici nei loro progetti. Questo è un periodo durante il quale la specifica viene revisionata ed implementata;  Proposed Recommendation (PR): Se ci sono sufficienti implementazioni di ogni aspetto dei resoconti tecnici, allora il W3C li presenta come Proposed Recommendation. Si tratta di un resoconto tecnico completo ottenuto dopo una attenta valutazione della stabilità e delle implementazioni; 1 [http://www.w3.org/WAI/intro/w3c-process] - 28 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Recommendation (REC): Il W3C invia la Proposed Recommendation al comitato consultivo per la ratificazione finale. Dopo una fase di tempo di almeno quattro settimane si vota per ratificarla come Recommendation . Un mancato consenso può riportare il documento allo stato di Working Draft. Una raccomandazione W3C è uno specifico insieme di linee guida che, dopo il raggiungimento di un ampio consenso, ha ricevuto la ratifica dei membri del W3C e del direttore. Le raccomandazioni sono simili agli standard pubblicati da altre organizzazioni. Nello schema precedente si deve tener conto, come accennato, della possibilità che un documento possa ritornare ad uno stato precedente in caso di necessità. Il passaggio da uno stato all’ altro avviene mediante votazione da parte dei membri. Il passaggio dallo stato di Last Call Working Draft a quello di Candidate Recommendation comporta una Call for implementations, e il livello di Proposed Recommendation viene raggiunto solo dopo aver maturato una soddisfacente esperienza implementativa. Le W3C Recommendation, quindi, hanno sia una verifica teorica (proof of the concept) che una verifica pratica (proof of implementation), per questo non sono dei meri documenti cartacei, ma specifiche di cui è stata dimostrata l’efficacia e che sono implementabili con uno sforzo ragionevole. Il W3C non è formalmente un organo di standardizzazione, ma una comunità di membri che cooperano spontaneamente per definire le linee guida e le specifiche, e mantiene stretti contatti con gli organi di standardizzazione. Le W3C Recommendation non possono quindi essere definite degli standard in senso proprio, ma vengono spesso citate come standard di fatto. E’ però importante sottolineare che non sono originate da posizioni dominanti del mercato, ma sono specifiche tecniche sulle quali è stato raggiunto, da parte di tutta la comunità del Web, un pieno accordo. La WAI WAI1 è l'acronimo di Web Accessibility Initiative, ovvero "Iniziativa per l'Accessibilità del Web". Si tratta di una sezione del World Wide Web Consortium. I gruppi di lavoro creati all'interno del WAI hanno prodotto negli anni una serie di raccomandazioni tecniche, mirate a dare agli sviluppatori gli strumenti per rendere accessibili non solo i contenuti del Web, ma anche i programmi per navigare in rete nonché quelli 1 [http://www.w3.org/WAI/] - 29 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR utilizzati per produrre e pubblicare contenuti.1 Su queste direttrici, la Web Accessibility Initiative ha sviluppato i 3 principali gruppi di linee guida, relative ai 3 diversi aspetti che giocano un ruolo critico nel rendere accessibile il Web, contenuti, strumenti di sviluppo e programmi utente:  Web Content Accessibility Guidelines (WCAG), che spiegano agli autori come creare contenuti Web accessibili alle persone con disabilità. Per contenuto Web in genere si intendono le informazioni presenti nella pagina Web, incluso il testo, le immagini, i moduli, i suoni ed altro2. Queste linee guida sono il cuore di questo lavoro e di loro si parlerà diffusamente in seguito. Attualmente è in Working Draft la versione 2.0 (27 Aprile 2006)  Authoring Tool Accessibility Guidelines (ATAG), che spiegano come gli strumenti di sviluppo dovrebbero aiutare i creatori delle pagine Web a produrre dei contenuti che siano conformi alle WCAG. In oltre le ATAG spiegano come rendere accessibili gli stessi strumenti di sviluppo in modo che possano essere utilizzati dalle persone disabili 3. Sono divenute una W3C Recommendation il 3 Febbraio 2000. Attualmente è in Working Draft la versione 2.0 (7 Dicembre 2006).  User Agent Accessibility Guidelines (UAAG), divenute Recommendation il 17 dicembre 2002, spiegano come rendere i programmi utente (user agent) accessibili per le persone disabili, in special modo per accrescere l’accessibilità ai contenuti del Web. I programmi utente includono Web Browser, riproduttori di contenuti multimediali e tecnologie assistive, cioè il software che alcune persone disabili utilizzano per interagire con il computer4. Nel Settembre del 2006 si è aggiunto anche il progetto ARIA per la considerazione delle caratteristiche dinamiche del Web: 1 Michele Diodati: “Guida all’accessibilità dei siti Web” “The Web Content Accessibility Guidelines (WCAG) documents explain how to make Web content accessible to people with disabilities. Web "content" generally refers to the information in a Web page or Web application, including text, images, forms, sounds, and such”. [http://www.w3.org/WAI/intro/wcag.php] 3 “The Authoring Tool Accessibility Guidelines (ATAG) documents define how authoring tools should help Web developers produce Web content that is accessible and conforms to the Web Content Accessibility Guidelines. The ATAG documents also explain how to make authoring tools accessible so that people with disabilities can use the tools.” – [http://www.w3.org/WAI/intro/atag.php] 4 “The User Agent Accessibility Guidelines (UAAG) documents explain how to make user agents accessible to people with disabilities, particularly to increase accessibility to Web content. User agents include Web browsers, media players, and assistive technologies, which are software that some people with disabilities use in interacting with computers.” – [http://www.w3.org/WAI/intro/uaag.php] 2 - 30 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Accessible Rich Internet Applications (ARIA) Suite, annunciate come progetto il 26 Settembre 2006. Le WAI-ARIA definiscono come rendere accessibili anche per le persone con disabilità le caratteristiche avanzate del Web dinamico ad esempio per strumenti come AJAX e DHTML1. L’obiettivo primario delle ARIA è quello di fornire alla tecnologia assistiva le informazioni necessarie sui controlli dell’interfaccia, come ad esempio l’espansione delle barre di navigazione.2. Le raccomandazioni che più ci interessano in questa sede sono sicuramente le Web Content Accessibility Guidelines, in italiano "Linee guida per l'accessibilità dei contenuti Web", più brevemente conosciute come WCAG e giunte attualmente alla versione 1.0, rilasciata dal WAIW3C come documento ufficiale con valore normativo in data 5 maggio 1999. Da molto tempo è in fase di avanzata fase di elaborazione la versione 2.0 delle WCAG, tuttavia il loro rilascio definitivo come Recommendation non è ancora avvenuto al momento di redigere questa tesi. 1 [http://www.w3.org/WAI/intro/aria.php] “WAI-ARIA defines how to make more advanced features of dynamic content and rich Internet applications accessible to people with disabilities. A primary focus of WAI-ARIA is providing information about user interface controls—such as expanding navigation bars—to assistive technology.” – [http://www.w3.org/WAI/intro/aria.php] 2 - 31 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR III. Metodologie e tecniche di applicazione Questo capitolo è il cuore dell’intero lavoro. In esso, più che fornire le specifiche istruzioni di programmazione per migliorare l’accessibilità del codice, si descrivono le linee guida e le strategie di progetto comuni a tutte le normative in materia. Ho deciso di presentare le tecniche universalmente impiegate prima dell’esposizione delle normative stesse in quanto ne sono, per tutte, il riconosciuto principio ispiratore. Nel resto di questa esposizione sono stati riportati a titolo esemplificativo alcune porzioni di codice (X)HTML o CSS. Per il controllo della loro validità sintattica e del loro funzionamento questi parti sono state testate in Amaya versione 9.53, il browser/editor ufficiale del W3C. A meno di modifiche dell’ultimo momento dovrebbero essere quindi esenti da errori, per quanto l’errore umano sia sempre possibile. In tal caso mi scuso in anticipo per eventuali possibili imprecisioni, e vi invito a segnalarmele. III.1 - Il linguaggio Per capire meglio il resto della trattazione è opportuno dare prima almeno i rudimenti fondamentali dello strumento essenziale con cui ci troviamo a trattare, il linguaggio HTML (Hyper Text MarkUp Language) il suo successore, l’XHTML (eXtensible HyperText Markup Language) e i CSS (Cascading Style Sheet), elementi base per costruzione delle pagine Web. Non essendo questo un manuale di programmazione HTML mi limiterò a fornire gli elementi essenziali per comprendere il suo corretto utilizzo ai fini di produrre delle pagine ad elevata accessibilità. Per chi volesse approfondire la materia sono in commercio numerosissimi testi di istruzione. Riferimento base è sempre il consorzio W3C per quanto riguarda la definizione del linguaggio sia HTML1 che XHTML2. Esistono anche delle versioni in italiano della documentazione ufficiale W3C a cura di Michele Diodati per l’HTML3, e a cura di Patrizia Andronico per l’XHTML4, per quanto questa non mi sembri in prima lettura una traduzione particolarmente efficace. 1 2 3 4 [http://www.w3.org/TR/html401/] [http://www.w3.org/TR/xhtml11/] [http://www.diodati.org/w3c/html401/cover.html] [http://www.w3c.it/traduzioni/xhtml1-it.html] - 32 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR HTML L’HTML (acronimo per Hyper Text Mark-Up Language) è un linguaggio usato per descrivere i documenti ipertestuali disponibili nel Web. Non è un linguaggio di programmazione, ma un linguaggio di marcatori, ossia descrive il contenuto di una pagina Web tramite degli appositi elementi definiti, appunto, marcatori. È stato sviluppato da Tim Berners-Lee al CERN di Ginevra. HTML è un linguaggio di pubblico dominio la cui sintassi è stabilita dal World Wide Web Consortium (W3C), e che è basato su un altro linguaggio avente scopi più generici, l'SGML (Standard General Markup Language), uno standard per la descrizione logica dei documenti. Una importante caratteristica di HTML è che esso è stato concepito per definire il contenuto logico e non l'aspetto finale del documento. Gli sviluppatori di HTML hanno optato per un linguaggio che descrivesse il contenuto dei documenti dal punto di vista logico, piuttosto che grafico, demandando poi ai programmi utente il compito di rendere, di trasformare il documento in maniera opportuna. Questo significa che non esiste alcuna garanzia che uno stesso documento venga visualizzato in ugual modo usando due programmi utente differenti o semplicemente su due elaboratori differenti. Con il passare del tempo però gli elementi del linguaggio incaricati di indicare una presentazione ai browser si sono via via moltiplicati fino a deviare l’HTML dall’originale progetto di marcatore di contenuti. Questo è avvenuto anche per il fatto che in realtà pochi sviluppatori si occupano di scrivere una pagina Web con un editor direttamente nel linguaggio HTML. Questo compito è invece spesso delegato ad un ambiente grafico che permette allo sviluppatore di occuparsi dell'aspetto finale della pagina senza interagire direttamente con il codice. La filosofia originale del progetto tuttavia è rinata in questi ultimi anni con l’avvento dei fogli di stile e con i problemi sollevati dall’accessibilità dei contenuti prodotti da questi strumenti automatici. Durante gli anni l'HTML ha subito molte revisioni e miglioramenti. Attualmente l'ultima versione disponibile è la versione 4.01, resa pubblica il 24 dicembre 1999. Da allora fino ai giorni nostri non è stata manifestata alcuna intenzione da parte del W3C di apportare ulteriori modifiche all'HTML, poiché verrà presto sostituito dai nuovi linguaggi XHTML derivati da XML. Recentemente tuttavia si è incominciato a sentir parlare della versione HTML 5 il cui nome - 33 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR ufficiale è Web Applications1 1.0 che non è, almeno per ora, una specifica del W3C ma del WHATWG. Lo scopo di questo progetto è quello di integrare le applicazioni Web all’interno del linguaggio. Dato lo stato ancora embrionale della specifica non verrà fatta oggetto di trattazione in questo lavoro. Struttura Ogni documento ipertestuale scritto in HTML deve essere contenuto in un file, la cui estensione deve essere .htm o .html. Il componente principale della sintassi di questo linguaggio è l'elemento. Gli elementi sono le strutture del linguaggio a cui è delegata la funzione di formattare i dati o indicare al Web browser delle informazioni. Ogni elemento è racchiuso all'interno di tag, uno di apertura ed uno di chiusura. Quest'ultimo, per certi elementi, è opzionale. I tag sono dei marcatori (markup) costituiti da una sequenza di caratteri racchiusa da due parentesi angolari. Spesso le informazioni su cui agisce il tag devono essere racchiuse fra un tag di apertura ed uno di chiusura, quest'ultimo indicato apponendo il carattere slash (/) dopo la parentesi angolare aperta. Ad esempio: testo testo testo. In questo caso, il testo compreso tra questi due tag verrà considerato dai browser come più significativo. Un documento HTML comincia con l'indicazione della DTD (Document Type Definition), la quale dice al browser l'indirizzo delle specifiche HTML che si vogliono dichiarare per il documento, indicando quindi, implicitamente, quali elementi, attributi ed entità si possono utilizzare. Tutte le informazioni contenute nel documento devono essere indicate tra i tag e . All'interno di questi due tag la sintassi HTML prevede 2 sezioni racchiuse fra i tag:  e , dove sono indicate le informazioni generali riguardanti l’intero documento e che non vengono visualizzate dal browser;  e , dove sono indicate tute le informazioni effettivamente presenti nel documento da rendere. Fanno eccezione le strutture costituite a FRAME che non prevedono gli elementi BODY. Gli elementi Un elemento HTML deve soddisfare le specifiche della DTD dichiarata. Gli elementi HTML consistono generalmente di quattro parti: 1 [http://www.whatwg.org/specs/web-apps/current-work/] - 34 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Un tag di apertura che definisce l'inizio di un elemento;  I suoi attributi e i relativi valori;  Dei contenuti;  Un tag di chiusura, in HTML il tag di chiusura è opzionale per molti elementi, gli elementi XHTML invece vanno sempre chiusi. Gli elementi possono rappresentare intestazioni, paragrafi, collegamenti ipertestuali, elenchi, oggetti multimediali incorporati e diverse altre strutture. Purtroppo ci sono alcuni elementi che non sono parte di nessun DTD ufficiale, ma sono nativi di alcuni browser e vengono utilizzati al meglio solo da questi. Tali elementi possono essere ignorati o visualizzati impropriamente da browser che non li supportano. Si consiglia di non utilizzare questi elementi a cui cercherò di non fare nemmeno cenno durante la successiva breve spiegazione. Molti elementi HTML possono essere nidificati. Si possono nidificare gli elementi fin quando si vuole ma i tag devono essere chiusi nell'ordine inverso nel quale sono stati aperti. La possibilità di nidificare è regolamentata dal fatto che un elemento sia di blocco (block-level) o di testo (inline). La distinzione è importante:  Un elemento a livello di blocco provoca una interruzione del flusso, può contenere altri elementi dello stesso tipo o di tipo inline. Esempi di elementi block-level sono paragrafi, moduli, liste, tabelle, intestazioni, le citazioni con BLOCKQUOTE e il contenitore generale

;  Un elemento inline è a livello di carattere e stringhe di testo. Non provoca interruzioni nel flusso e può contenere solo altri elementi inline. Esempi di elementi inline sono quelli per definire caratteristiche del testo come il contenitore e gli elementi . Con una forzatura del lessico, gli elementi HTML sono qualche volta chiamati impropriamente tag. Elementi Head ... Delimita un documento HTML. I due tag sono opzionali in HTML ma alcuni browser e altre utility possono non riconoscere il documento senza la loro presenza. ... - 35 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Delimita la sezione d’intestazione (header) del documento che contiene informazioni sulla pagina. I tag sono opzionali in HTML; se omessi l'esistenza dell'header può essere dedotto in altri modi. ... Delimita il corpo del documento che contiene i contenuti visualizzati nella pagina. Non sono necessari se il documento è in HTML. ... Indica il titolo della pagina. Questo elemento è richiesto in ogni documento HTML e XHTML. Sistemi operativi e programmi utente differenti visualizzano il titolo in maniera differente. Può essere il nome predefinito quando si salva la pagina o altro. Al contrario degli altri tag, l'elemento TITLE non permette di contenere altri tag. ... Delimita i metadata e può essere utilizzato per specificare la descrizione della pagina, parole chiave e impostazioni. Specifica qualsiasi tipo di collegamento per un documento, come: collegamenti precedenti e successivi o versioni di fogli di stile alternative. Il suo uso più comune è quello di collegare un foglio di stile esterno alla pagina. Utilizzato per includere JavaScript o altri script nel documento. Specifica una definizione di stile interna per il documento. Elementi Body Intestazioni
fino a
Intestazioni a diversi livelli. Si utilizza
per il livello massimo di intestazione, la sezione principale,
per il successivo livello sottostante come una sottosezione,
per un livello al di sotto del precedente e così via. Il livello più basso d'intestazione è
. La maggior parte dei browser Web mostrerà
come un testo grande con un font differente e
come testo piccolo in grassetto ma questo comportamento può - 36 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR essere modificato con i fogli di stile CSS. Gli elementi d'intestazione non vanno utilizzati per creare testo grande o in grassetto: il loro scopo è descrivere la struttura del documento e l'organizzazione. Alcuni programmi li utilizzano per generare indici e sommari. Testo strutturato Molti elementi HTML sono realizzati per cambiare la struttura o il significato del testo. Alcuni sono block-level ma la maggior parte sono inline e possono essere inclusi nel normale flusso del testo.
...
(block Level) Crea un paragrafo. In HTML il tag di chiusura è opzionale.
...
(block Level) Crea una citazione, convenzionalmente visualizzata indentata. L’elemento non è stato progettato per indentare il testo. Può automaticamente aggiungere delle virgolette. L'attributo CITE Può fornire la fonte e deve essere un URL completo.
...
(block Level) Crea testo pre-formattato. Il testo è visualizzato con un font non proporzionato, esattamente come è stato scritto nel file. ... (inline) Enfasi, convenzionalmente visualizzato in corsivo. ... (inline) Enfasi forte, convenzionalmente visualizzato in grassetto. ... (inline) Una breve citazione. Può essere visualizzata con virgolette. Le citazioni possono essere nidificate. L'attributo CITE Può fornire la fonte e deve essere un URL completo. ... (inline) Una porzione di codice. Convenzionalmente viene visualizzato con un font monospaziato. Liste
...
Crea un elenco di definizioni formato da termini con la rispettiva definizione. - 37 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
...
Crea un termine di definizione.
...
Crea un testo esteso per la definizione.
...

...
Crea un elenco ordinato (numerato) o non ordinato (puntato). La numerazione predefinita è quella araba. Il marcatore predefinito è un punto annerito
...
Crea un oggetto dell'elenco in liste ordinate o non ordinate. Tabelle ...
Crea una tabella ... Crea una riga in una tabella ... Crea una cella d'intestazione all'interno di una riga, il contenuto è visualizzato di solito in grassetto e centrato. ... Crea una cella dati all'interno di una tabella. ... Specifica un gruppo di colonne in una tabella. (in XHTML) Specifica gli attributi per una colonna. ... Specifica un titolo per l'intera tabella. ... Specifica l'intestazione della tabella. Questa sezione può essere ripetuta se la tabella è divisa in più pagine nella stampa o in altri possibili tipi di resa. ... Specifica la parte principale della tabella. - 38 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR ... Specifica la parte bassa della tabella. Come , questa sezione può essere ripetuta se la tabella è divisa in più pagine nella stampa o in altri possibili tipi di resa. Moduli L'HTML può solo definire il formato del modulo, in valori immessi dagli utenti vengono trasferiti e processati lato server.
...
Definisce il corpo di un modulo. Crea un menu ad elenco dal quale l'utente può scegliere una sola voce. Può essere visualizzato come un menu a cascata. Crea una voce nel menu. Crea una casella di spunta (checkbox). Crea un pulsante di opzione; se più pulsanti di opzione hanno lo stesso nome, l'utente potrà selezionarne solo uno. Crea un pulsante d'invio. Crea un pulsante di reset che ripristina i valori del modulo a quelli iniziali. Crea una casella di testo a linea singola. ... Crea un'area di testo multi-linea, definita dagli attributi COLS per le colonne e ROWS per le righe. Il testo tra i tag apparirà nell'area di testo al caricamento della pagina. - 39 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Altri elementi ... Crea una separazione logica sulla riga. Permette di assegnare a porzioni di testo un ID o una classe, utilizzabili con i CSS.
...
Crea un blocco logico di tipo block-level. Viene usato soprattutto per l’impiego congiunto di una definizione corrispondente nel CSS.

(in XHTML) Inserisce una linea orizzontale. Include un oggetto nella pagina del tipo specificato dall'attributo TYPE. Può essere qualsiasi oggetto MIME che il browser riconosce, un plug-in come Flash, o un file audio. ... (in XHTML) Questo tag appare solamente all'interno dell'elemento OBJECT e imposta i parametri per l'oggetto per esempio larghezza, altezza o URL del contenuto. Formattazione (sconsigliati) ... Utilizza il grassetto. Esiste un equivalente CSS: {font-weight: bold;} ... Usa il corsivo. Esiste un equivalente CSS: {font-style: italic;} ... Crea testo più grande. Esiste un equivalente CSS: {font-size: larger;}. ... Crea testo più piccolo. Esiste un equivalente CSS: {font-size: smaller;} Collegamenti ed ancore ... - 40 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Crea un collegamento ipertestuale con l'attributo HREF impostato su un URL; inoltre l'attributo TITLE può essere impostato per avere un suggerimento a comparsa (tooltip) d'informazioni sul collegamento. Quando il puntatore è sul collegamento, di solito si trasforma in una mano con il dito indice disteso, e il testo in aiuto appare come un suggerimento a comparsa che sparisce quando il cursore si sposta. Alcuni browser visualizzano il testo alternativo allo stesso modo, ma è un errore tecnico. Alternativamente, l'elemento crea un segnalibro interno usando l'attributo NAME o l’attributo ID in XHTML, utilizzabile con una chiamata preceduta dal simbolo '#' nell'URL. Questa tecnica a segnalibro crea dei problemi di compatibilità all’indietro in XHTML dove l’attributo NAME è proibito. Immagini (in XHTML) Include un'immagine con l'attributo SRC, l’attributo ALT fornisce testo alternativo. ALT è obbligatorio nelle ultime versioni del linguaggio ed è inteso come testo alternativo, sebbene alcuni browser lo visualizzano come un suggerimento, l'attributo TITLE dovrebbe fungere da suggerimento. Vari

(in XHTML) Specifica un'interruzione di linea. Il comportamento può essere modificato anche con i CSS: {break: left|right|all}. ... Specifica una mappa lato client. (in XHTML) Specifica un'area in una mappa. Racchiude un commento. Questo è un tag SGML e non limitato a HTML, quindi può apparire ovunque nel documento, anche prima del DTD o dopo . Un browser non visualizzerà nessun commento. La chiusura ">" è necessaria. - 41 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Frame Un documento HTML può contenere un’intestazione o un corpo o un’intestazione e un FRAMESET, ma non entrambi. ... Delimita il FRAMESET. La disposizione dei frame è data da un elenco separato da virgola negli attributi ROWS e COLS. ... Racchiude un singolo frame, o regione, all'interno del FRAMESET. Attraverso l'attributo SRC si può collegare all'interno un documento. Contiene un normale elemento con i figli che appariranno nel browser Web che non supporta i frame. Unità per le dimensioni Segue una lista delle unità di misura usate per definire dimensioni, spazi o distanze. Include dimensioni assolute e relative, in genere rispetto alle dimensioni nell’elemento genitore. Nella pratica comune solo alcune di queste sono realmente usate.  Assolute: o in (inches - pollici): classica misura del sistema metrico americano. Praticamente nullo il suo valore su un supporto come un browser Web. 1 pollice è equivalente a 2.54 cm o cm (centimetri): stesso discorso visto per i pollici, la difficoltà maggiore sta nella resa su monitor. o mm (millimetri): come per le misure precedenti. o pt (points - punti): unità di misura tipografica destinata essenzialmente a definire la dimensione dei font. Corrispondono a 1/72 di pollice. o  pc (picas): unità poco usata. 1 pica equivale a 12 punti. Relative: o em (em-height). L'unità em è uguale al valore calcolato della proprietà FONT-SIZE dell'elemento nel quale è usata. Quando em si trova nel valore della stessa proprietà FONT-SIZE, esso fa riferimento alla grandezza del font carattere dell'elemento genitore. Può essere usata per la misurazione orizzontale o verticale. o ex (ex-height, a volte chiamata anche ampiezza-quadrato o quad-width nei testi tipografici.). L'unità ex è definita dalla 'x-height' del font carattere. La x-height è così chiamata perchè è spesso uguale all'altezza della "x" minuscola. Un ex è ovviamente definito anche per gli insiemi di caratteri che non contengono una x. - 42 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR o px (pixels): relativo al dispositivo di visualizzazione. Unità di misura ideale su monitor. E' quella più usata e facile da comprendere ma non viene trattata in maniera simile da tutti i browser. o Percentuale. Un valore espresso in percentuale è da considerare relativo rispetto ad un altro valore, in genere quello espresso per l'elemento parente. Nella scelta delle dimensioni occorre tenere presente l’incapacità di Internet Explorer di ridimensionare i caratteri specificati in pixel, a differenza degli altri browser. Una buona scelta rimane dunque quella di adottare le unità percentuali o l'unità em, prestando attenzione alle proprietà degli elementi genitori. XHTML Nella sezione precedente ho trattato brevemente gli elementi del linguaggio HTML introducendo già delle segnalazioni dove fossero presenti delle variazioni per l’XHTML. Molti di questi elementi sono comuni anche per il naturale successore, seppur con lievi differenze di sintassi. Questo perché, in effetti, l’XHTML non è altro che una evoluzione, una formattazione del linguaggio precedente nelle regole strutturali di un più generico progetto della famiglia di linguaggi l’XML, a sua volta sottoinsieme delle strutture SGML. Vale la pena dare qualche piccola spiegazione su questa gerarchia di linguaggi. L’SGML è un metalinguaggio, cioè un linguaggio per descrivere i linguaggi a marcatori, in particolare quelli usati per i documenti in formato elettronico, sia per la stampa che per l’interscambio tra applicazioni. Vista la sua ricchezza espressiva, risulta a volte piuttosto complesso, per questo motivo si deciso di ricavarne un sottoinsieme meno complesso che ne mantenga però la potenza e la flessibilità, questo è l’XML. Integrando l’HTML nelle regole dell’XML è nato l’XHTML. L’HTML, in vista di questo passaggio, si era già evoluto nella sua ultima versione 4.01 del dicembre 1999 predisponendo il passaggio all XHTML in maniera pressoché indolore avendo già realizzato il supporto per i fogli di stile, gli script, le internazionalizzazioni e tabelle più sofisticate. In effetti, tra l’ultima versione HTML (la 4.01) e la prima del successore XHTML (la 1.0) non esistono modifiche sostanziali. Entrambi prevedono la dichiarazione a tre tipi di compatibilità DTD:  TRANSITIONAL (include elementi deprecati);  FRAMESET (per usare i FRAMESET al posto del BODY);  STRICT (contiene solo elementi che non sono influenzati dai CSS). - 43 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Le modifiche sono essenzialmente sintattiche, dovute al fatto di essere entrati a far parte della famiglia di linguaggi XML e di doverne quindi rispettare le regole. Poiché XHTML è un'applicazione XML, certi usi che erano perfettamente legali in HTML 4.0 basato su SGML devono essere cambiati. Le conseguenze più significative del passaggio alla nuova famiglia sono:  I documenti devono essere ben formati: Ben formato è un concetto introdotto da XML. Sostanzialmente questo significa che tutti gli elementi devono avere il tag di chiusura o devono essere scritti in una forma corretta come descritto sotto, e che tutti gli elementi devono essere annidati senza sovrapposizioni. Sebbene i costrutti con strutture nidificate sovrapposte siano illegali anche in SGML da cui è derivato l’HTML, questa sintassi è stata ampiamente tollerata dai browser esistenti. In XHTML non è consentita.  Gli elementi e i nomi degli attributi devono essere in lettere minuscole: I documenti XHTML devono usare lettere minuscole per tutti gli elementi HTML e per i nomi degli attributi. Questa differenza è necessaria perchè XML è sensibile alle minuscole e alle maiuscole, per esempio
e
sono tag diversi.  Gli elementi non vuoti richiedono il tag di chiusura: In HTML 4.0 basato su SGML alcuni elementi potevano omettere il tag di chiusura, in modo tale che gli elementi che seguivano implicavano tale chiusura. Questa omissione non è permessa in XHTML basato su XML. Tutti gli elementi, ad eccezione di quelli dichiarati come EMPTY nella DTD devono avere un tag di chiusura ed anche per costoro va seguita una sintassi particolare.  I valori degli attributi devono sempre essere compresi fra doppi apici: Tutti i valori degli attributi devono essere compresi fra doppi apici, inclusi i valori numerici.  Minimizzazione degli attributi: XML non supporta la minimizzazione degli attributi. I valori degli attributi accoppiati devono essere scritti completamente. Ogni attributo deve avere un valore. Alcuni attributi di HTML non hanno un valore. E' il caso dell'attributo SELECTED. In XHTML anche questi attributi devono essere valorizzati. I nomi degli attributi come COMPACT e CHECKED non possono essere presenti negli elementi se non viene specificato il loro valore.  Elementi vuoti: Gli elementi vuoti devono avere un tag di chiusura o il tag iniziale deve terminare con />. Per esempio
o
.  Manipolazione di spazi bianchi nei valori degli attributi. Nei valori degli attributi, i programmi utente elimineranno alla lettura gli spazi bianchi iniziali e finali dai valori degli attributi e sostituiranno la sequenza di uno o più spazi - 44 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR bianchi (compreso il salto di linea) con un singolo spazio tra le parole (un carattere di spazio ASCII per le scritture di tipo occidentale).  Gli elementi con attributi ID e NAME. HTML 4 definisce l'attributo NAME per gli elementi A, APPLET, FORM, FRAME, IFRAME, IMG, e MAP. HTML 4 introduce anche l'attributo ID. Entrambi questi attributi sono disegnati per essere usati come identificatori di elementi. Con l'obiettivo di assicurare che i documenti XHTML 1.0 siano documenti XML benformati, i documenti XHTML 1.0 devono usare l'attributo ID quando definiscono gli identificatori di elementi, anche con gli elementi che storicamente usavano anche un attributo NAME. Il passaggio a ID non pone problemi nei browser più recenti, ma con altri non funziona. In questo caso e se la compatibilità all'indietro è assolutamente necessaria, la stessa specifica XHTML 1.0 suggerisce di usare entrambi gli attributi, anche se ciò è contro le regole. In XHTML 1.0 l'attributo NAME di questi elementi è comunque deprecato mentre è stato del tutto rimosso in XHTML 1.1. Uno degli argomenti più delicati con l’XHTML è la gestione dei linguaggi di programmazione, tradizionalmente incorporati nel documento con il tag Gestori di eventi Come accennato nel breve elenco di tecniche precedenti, una certa cura va posta nella trattazione dei gestori di eventi (event handler). Un gestore di eventi è un insieme di istruzioni che vengono richiamate quando un particolare evento viene soddisfatto, in genere su azioni del mouse o della tastiera. Alcuni tra i più importanti eventi attivabili possono essere i seguenti:  ONLOAD;  ONUNLOAD;  ONCLICK;  ONDBLCLICK;  ONFOCUS;  ONBLUR;  ONMOUSEDOWN;  ONMOUSEUP;  ONMOUSEOVER;  ONMOUSEMOVE;  ONMOUSEOUT;  ONKEYDOWN;  ONKEYUP;  ONKEYPRESS. L’attenzione a questa funzionalità viene rivolta anche da parte delle normative considerate: - 184 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  WCAG 1.0: punto di controllo 6.4: “Garantire che i gestori di eventi per gli script e le applet siano indipendenti dai dispositivi di input”, contenuti analoghi sono ripresi nei punti di controllo 9.2 e 9.3.  Section 508: Nel paragrafo 1194.22(m) ci si riferisce alla accessibilità del software del paragrafo 1194.21 dove si richiede la operabilità via tastiera1;  D.M. 5 Luglio 2005, requisito 16: “Garantire che i gestori di eventi che attivano script, applet o altri oggetti di programmazione o che possiedono una propria specifica interfaccia, siano indipendenti da uno specifico dispositivo di input.”;  WCAG 2.0: linea guida 2.1: “Rendere tutte le funzionalità operabili tramite comandi da tastiera.”. In pratica le norme ritengono necessario che, nel caso siano previsti degli eventi che implicano l'iterazione da parte dell'utente, venga garantita la loro esecuzione a qualsiasi utente, sia che egli utilizzi una periferica di puntamento sia una tastiera a cui può essere eventualmente agganciato un emulatore per le tecnologie assistive. Di fatto, come specificato espressamente nelle WCAG 2.0, bisogna definire un comando tastiera per ogni comando che richieda l’uso del mouse. Le motivazioni sono:  Non tutti gli utenti navigano il Web tramite interfaccia grafica, utilizzando il mouse come periferica di input;  I comandi tastiera possono essere attivati anche tramite comandi vocali;  Le tecnologie assistive per non vedenti utilizzano i comandi tastiera per navigare attraverso i contenuti. In questa ottica è necessario accoppiare due gestori di eventi differenti che abbiano lo stesso codice associato nel modo seguente:  ONMOUSEDOWN e ONKEYDOWN;  ONMOUSEUP  ONCLICK  ONMOUSEOVER  ONMOUSEOUT e ONKEYUP; e ONKEYPRESS; e ONFOCUS; e ONBLUR. 1 “When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually” - 185 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Va notato che non esiste un equivalente per il doppio click (ONDBLCLICK) o per il movimento del mouse (ONMOUSEMOVE), perciò si consiglia di evitare questi elementi. In pratica, la raccomandazione migliore è quella contenuta nel punto di controllo 9.3 delle WCAG 1.0: “Negli script, specificare gestori di evento logici piuttosto che gestori di evento dipendenti dal dispositivo.”. Chiudo con un esempio elementare sugli eventi. Nel codice seguente, se JavaScript non fosse abilitato, selezionando il collegamento la nuova pagina sarà aperta nella finestra corrente. Se invece fosse attivo, allora il click sul collegamento ipertestuale o l'uso di qualsiasi tasto con il focus sul collegamento ipertestuale aprirà una finestra nuova: Nuova Pagina E’ questo un esempio di come sia possibile aprire finestre nuove con cambiamento di contesto anche se nelle ultime specifiche del linguaggio XHTML sono stati rimossi i costrutti dedicati. Il codice precedente è riportato per brevità a titolo di esempio sugli eventi e non rappresenta una scrittura valida per l’accessibilità, il codice JavaScript andrebbe separato ed integrato con un opportuno avviso. Applet e plug-in In genere molti dei principi guida esposti per gli script sono applicabili anche per gli applet ed i plug-in al punto che la maggior parte delle normative citate in precedenza li considerano entrambe nella stessa esposizione. Un esempio è proprio la nostra legge che, nei requisiti 15, 16 e 17 considera i diversi aspetti di entrambe le tecnologie. In special modo per gli oggetti:   E’ necessario fornire un equivalente testuale per: o Tutti gli utenti che non posseggono i plug-in necessari alla loro visualizzazione; o Gli utenti che a causa di disabilità non possono interagire con tali contenuti; Occorre garantire che le interfacce degli applet siano direttamente accessibili o compatibili con le tecnologie assistive. La Section 508 invece ne fa un richiamo a parte nel paragrafo 1194.22 (m) rimandando per la loro funzionalità ai requisiti software espressi nella stessa legge negli 11 standard citati del paragrafo 1194.21 tra le cui richieste si trova, come detto, quella che tutte le funzionalità siano operabili via tastiera. Questa richiesta non implica che ogni singolo controllo sia raggiungibile ed operabile via tastiera, ma che via tastiera sia almeno possibile emularne la funzionalità. - 186 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR AJAX AJAX (Asynchronous JavaScript and XML) è una raccolta di tecnologie Web assemblate insieme per consentire le interazioni tra client e server delle applicazioni Web senza che venga ricaricata o rinfrescata la pagina. AJAX non è una tecnologia a se stante, ma, in qualche modo, è una combinazione di tecniche. AJAX usa:  (X)HTML e CSS per presentare le informazioni. Entrambi possono essere modificati dinamicamente per visualizzare nuove informazioni con nuove impaginazioni. Questi cambiamenti sono fatti in genere tramite il DOM (Document Object Model);  JavaScript per manipolare gli elementi e per stabilire una comunicazione con il server Web. Questo consente di trasmettere dati, ad esempio in formato XML, tra il client ed il server Web senza richiedere che la pagina venga ricaricata e rinfrescata. Per una spiegazione più dettagliata delle funzionalità e dell’uso di questa tecnica rimando alle numerose trattazioni disponibili in rete1. In questa sede è opportuno far presente che, utilizzando AJAX, le applicazioni Web possono raggiungere un elevato grado di interattività senza passare attraverso le classiche procedure di richiesta nuove pagine al server. Questo sveltisce notevolmente il traffico dati e il JavaScript garantisce un elevato livello di interazione. Nonostante che nessuna delle tecniche AJAX sia innovativa, tuttavia la popolarità crescente di questo metodo comporta la necessità di considerarlo nel suo insieme dal punto di vista dell’accessibilità. Da questo punto di vista alcune controindicazioni di AJAX possono essere:  AJAX richiede l’attivazione dei JavaScript, con le problematiche discusse per gli script: dispositivi palmari, vecchi browser o browser testuali possono non essere in grado di supportare AJAX o di gestirlo correttamente, e di questo il progettista deve essere al corrente;  AJAX richiede che sia supportato il metodo XMLHTTPREQUEST per la comunicazione con il server Web, ed alcuni browser non lo fanno;  AJAX interagisce con il server in maniera autonoma, anche senza esplicita richiesta dell’utente manipolando eventualmente l’interfaccia della pagina al volo. Questo potrebbe cambiare alcune abitudini ed alcune aspettative dell’utente;  1 Si potrebbero avere degli spostamenti inattesi del focus; [http://www.w3schools.com/ajax/default.asp] - 187 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Gli utenti potrebbero non avere alcuna idea di dove sono state visualizzate le eventuali informazioni o modifiche ricevute;  L’interfaccia ed i contenuti dell’applicazione potrebbero cambiare in maniera non evidente senza rendere espliciti i mutamenti occorsi. Questo problema potrebbe essere particolarmente sentito con gli screen-reader che potrebbero non accorgersi per nulla dei cambiamenti e non presentare le modifiche. Le WCAG richiedono che la gestione dei cambiamenti di contenuto e di contesto ricada fra le considerazioni dell’accessibilità 1. Il principio generale per rendere accessibili i cambiamenti della interfaccia dinamica, è quello di avvisare l’utente delle modifiche avvenute consentendo un accesso diretto ai nuovi contenuti. In particolare:  Avvisare l’utente: o Notificare l’uso di questa tecnologia, sia in precedenza sia all’interno di una pagina AJAX; o Avvisare l’utente se le funzionalità JavaScript non fossero attive rendendo AJAX non disponibile, in caso contrario avvisare che le pagine verranno aggiornate automaticamente;  o Quando possibile garantire la possibilità di aggiornamenti manuali; o Mantenere le impostazioni dell’utente; Rendere note le modifiche: o Per le piccole aree della pagina, evidenziare la zona aggiornata con un mutamento del colore dello sfondo della zona per qualche secondo; o Far lampeggiare le zone aggiornate per meno di 3 secondi. In questo caso bisogna porre attenzione alla frequenza di lampeggio per le problematiche legate all’epilessia fotosensibile;  Facilitare l’utente nella ricerca delle informazioni aggiornate: o Fornire un’opzione per assegnare il focus ai nuovi dati; o Fornire un’opzione per gli aggiornamenti tramite un messaggio di avviso; o Utilizzare gli elementi d’intestazioni (X)HTML per contrassegnare le sezioni a contenuto aggiornabile;  1 Usare le tecniche di accessibilità per le pagine DHTML. WCAG 2.0, SC 1.3.1: “Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies”. - 188 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Un processo del genere non è sempre facile da ottenere. Le tecniche di accessibilità specificatamente riferite a questo strumento relativamente recente sono considerate dal W3C nei nuovi documenti che fanno parte delle raccomandazioni ARIA (Accessible Rich Internet Applications)1. In questa sede non verranno approfonditi ulteriormente questi argomenti, rimandando ai numerosi articoli presenti in rete, anche forniti dallo stesso W3C2. III.11 - Comprensibilità dei contenuti Questo principio fa riferimento alla capacità del sito di comunicare il contenuto informativo in maniera più possibilmente chiara e semplice in relazione all’argomento trattato in modo da venire incontro alle esigenze del più vasto pubblico possibile. Il progetto WAI fa esplicito riferimento a questo principio in due assunti di base:  WCAG 1.0, linea guida 14.1: “Assicurarsi che i documenti siano chiari e semplici in modo che possano essere compresi più facilmente.”;  WCAG 2.0: linea guida 3.1: “Rendere leggibile e comprensibile il contenuto testuale.”. Delle due espressioni, sicuramente quelle più espressive e vincolanti sono le indicazioni contenute nelle WCAG 1.0, mentre le WCAG 2.0 hanno ricevuto qualche critica per la formulazione troppo blanda e facilmente aggirabile del requisito. Ancora meno attenti sono stati, d’altro canto, i legislatori nazionali, come vedremo poi, probabilmente per il fatto che una valutazione accurata ed oggettiva di una richiesta del genere può essere particolarmente difficoltosa. Queste direttive sono però importanti in diversi casi. La comprensibilità dei contenuti è un concetto che spesso sconfina nel campo dell’usabilità, un sito che offra del materiale facilmente comprensibile migliora sicuramente l’aspetto dell’usabilità delle informazioni offerte. Di questo si è in parte accennato nel discutere le interazioni fra accessibilità ed usabilità. Un testo facilmente comprensibile è di grande ausilio anche ai disabili cognitivi. Per molto tempo gli sviluppatori Web hanno preferito non tener conto di queste categorie di utenti, ritenendoli fuori dal loro pubblico e considerando che lo sviluppo di siti altamente comprensibili è costoso e difficile. In realtà le disabilità nell’apprendimento non implicano necessariamente un basso livello di intelligenza o di interesse nei contenuti esposti. 1 2 [http://www.w3.org/WAI/intro/aria.php] [http://www.w3.org/2006/Talks/0524-www-AjaxWAI.pdf] - 189 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Va ricordato che alla base di tutti i principi dell’accessibilità si pone la necessità di sviluppare contenuti universali e fruibili per la maggior parte possibile degli utenti e lo scoglio iniziale del cambiamento di metodologia a favore della comprensibilità dei contenuti esposti non deve rappresentare un’insormontabile barriera in termini di costi e difficoltà. Scrivere per farsi capire Questo assunto è il titolo di una sezione1 della guida sull’accessibilità pubblicata su internet di Michele Diodati. La frase, a mio avviso, rappresenta al meglio il principio di accessibilità da applicare sui testi Web. La raccomandazione di base è quella appunto, di scrivere per farsi capire, tenendo presente che non si sta cercando di vendere un prodotto, quanto piuttosto di comunicare un’informazione. La letteratura in materia è molteplice, raccomando il testo fondamentale di Roberto Scano 2, sintetizzato in un articolo3 apparso su LAU (Laboratorio di Accessibilità ed Usabilità), oltre che agli appunti4 citati di Michele Diodati. Da queste letture si possono evidenziare alcuni accorgimenti di base per questo argomento:  Utilizzare un linguaggio chiaro e semplice. Se non ci si rivolge esclusivamente ad un pubblico specialistico occorre fare attenzione alla scelta dei termini, in genere è opportuno impiegare un lessico adatto ed alla portata di tutti i possibili lettori. Il che non vuol dire, ovviamente, che non si possano impiegare termini tecnici quando necessari, a patto di corredarli con le opportune spiegazioni ed un glossario di riferimento. Acronimi ed abbreviazioni vanno spiegati almeno una volta nella pagina come suggerito in seguito. Una particolare cura va posta per i termini stranieri. Per quanto l’inglese sia, a giorni nostri, correntemente diffuso nei testi e nel gergo, occorre ricordare che non tutti gli utenti potrebbero comprenderne i termini. Non solo, anche gli screen-reader potrebbero essere in difficoltà con i termini stranieri e perdere tempo a caricare i dizionari. I cambi di lingua nel testo vanno opportunamente segnalati con gli strumenti del linguaggio (X)HTML. E’ ovvio che non tutto va tradotto, termini come il mouse di un computer sono entrati a 1 2 3 4 [http://www.diodati.org/scritti/2004/guida/ele_acc35.asp] Roberto Scano: “Accessibilità dalla teoria alla realtà” - capitolo 25. [http://lau.csi.it/realizzare/usabilita/grafica_testi/testi_usabilita.shtml] [http://www.diodati.org/scritti/2004/guida/ele_acc35.asp] - 190 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR far parte della nostra lingua e sono universalmente comprensibili. La traduzione italiana sarebbe ridicola. Un’attenzione simile va posta per i termini gergali che sono in genere da bandire e i termini troppo burocratici che appesantiscono inutilmente la lettura. A questo proposito è importante una circolare del ministero della funzione pubblica, discussa nella sezione successiva;  Controllare la grammatica la sintassi. Si consiglia di impiegare una struttura sintattica basata su periodi brevi e lineari, poche proposizioni, verbi in forma attiva, ed elenchi puntati. La sintassi è importante: i più recenti screen-reader possono dare la giusta cadenza e le pause adatte nella lettura in relazione ai segni di interpunzione incontrati. Di grande utilità possono essere i correttori ortografici, molti sono automatici all’interno di quasi tutti i programmi di video-scrittura. Se possibile vale la pena rileggere diverse volte il testo e farlo esaminare da altre persone prima di diffonderlo, al fine di ridurre al massimo i refusi che possono diminuire drasticamente la comprensione per chi usa un sintetizzatore vocale. Altri utili strumenti automatici possono essere d’aiuto nel valutare gli elementi della frase e di tutto il testo. A questo proposito vorrei segnalare che Juicy Studio mette a disposizione un valutatore della leggibilità1 integrato con numerose statistiche sulla strutturazione delle frasi e del discorso. E’ attivabile anche dalla barra dell’accessibilità sotto la voce tools. Anche Microsoft Word permette un’analisi del livello di leggibilità di un documento. I valutatori di leggibilità sono degli strumenti tipici dei programmi di videoscrittura, in grado di produrre valutazioni, basate su dizionari interni e calcoli statistici, relative al tipo di linguaggio adoperato in un testo (formale, colloquiale, burocratico, ecc.). Strumenti del genere possono essere utili per valutare in maniera automatica leggibilità dei contenuti;  Facilitare la lettura. Si possono usare gli strumenti messi a disposizione degli editor di testo per evidenziare le parti strutturali ed importanti di un documento anche sotto l’aspetto presentazionale, ricordando, quando possibile, di aggiungere anche la relativa semantica strutturale. Ad esempio, si può ricorrere all’uso del grassetto per enfatizzare una parola chiave. In tal caso è disponibile un marcatore strutturale STRONG in genere associato proprio con questo tipo di evidenziazione su quasi tutti i browser. 1 [http://juicystudio.com/services/readability.php] - 191 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Molto utili sono anche le liste puntate per sintetizzare i concetti e fissare velocemente i punti chiave di una esposizione. Vanno evitate in genere le sottolineature, in quanto facilmente confondibili con i collegamenti ipertestuali. In certi casi anche il corsivo che può essere facilmente confondibile per taluni font. A questo proposito si consiglia di impiegare caratteri senza decorazioni (sans-serif) e tipi di font il più possibile definiti e nitidi. Un’interlinea di 1,5 può agevolare la lettura, così come è utile separare i paragrafi a blocchi ed utilizzare un allineamento predefinito a sinistra evitando la giustificazione. L’impiego delle immagini per chiarificare i concetti può aumentare la comprensione dei contenuti testuali, mentre vanno scoraggiate le animazioni che possono facilmente distrarre;  Mantenere uno stile coerente e logico. Un aspetto importante è sicuramente la coerenza di stile nella presentazione degli elementi interni ad una pagina e di tutta la linea di impaginazione di un sito. Questo anche per garantire che ad una modalità di presentazione uguale corrisponda una funzionalità identica. L’omogeneità stilistica permette di fornire un ambiente integrato in cui la navigazione e la lettura risulta più agevolata ed usabile, un ambiente più fruibile in particolar modo per i disabili cognitivi per i quali la coerenza di aspetto va sicuramente preferita rispetto alla varietà delle modalità di presentazione;  Fornire degli strumenti di orientamento e di navigazione che possano permettere di individuare la posizione di un contenuto all’interno di un blocco di informazioni. In particolare è utile fornire una mappa del sito, intestare con chiarezza e titoli differenti le pagine, aggiungere indici e sommario, strutturare le informazioni. A questo principio, come a quello precedente si richiamano direttamente anche alcune esplicite raccomandazioni sia delle legge Stanca che delle WCAG;  Permettere agli utenti di personalizzare la visualizzazione dei contenuti in modo che possano essere adattati alle proprie esigenze. Questo si può fare ad esempio: permettendo il ridimensionamento dei testi e delle immagini, favorendo l’applicazione di altri stili, pensati dal progettista o personalizzati dagli utenti, ed evitando l’utilizzo di dimensioni fisse o assolute degli elementi della pagina;  Utilizzare degli elementi strutturali del linguaggio. Come discusso in una sezione a parte di questo lavoro, un grande aiuto per la leggibilità e la comprensione viene fornita direttamente anche dallo stesso linguaggio (X)HTML. L’impiego delle opportune marcature strutturali utilizzate nell’ambito del loro corretto aspetto semantico evidenzia la struttura logica del documento chiarificando le corrette gerarchie delle parti di un documento. - 192 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Come accennato nella precedente esposizione ci sono alcuni strumenti di valutazione automatica, tuttavia è chiaro che i testi migliori possono essere portati a compimento solamente attraverso la valutazione diretta delle pagine da parte di persone con disabilità e di formazione culturale di diverso livello. La valutazione oggettiva di questo requisito è molto difficoltosa e piuttosto contestabile. Nelle WCAG, soprattutto nelle 1.0, il requisito della chiarezza e semplicità è giustamente proposto come vincolo obbligatorio per l’accessibilità. Una sezione apposita delle tecniche di base1 ne suggerisce le linee fondamentali. Da quest’obbligo inderogabile nasce il grosso problema del riconoscimento anche della semplice verifica di primo livello per molti siti che invece dichiarano di aver raggiunto anche i livelli 2 o 3. In effetti, un sito che rispetti tutte le raccomandazioni contenute nelle WCAG 1.0 tranne il punto di controllo 14.1, che richiede di scrivere nel modo più chiaro e semplice possibile in relazione all'argomento trattato, non è accessibile neppure al livello A. I principi sopra enunciati sono validi in generale e devono essere tenuti in considerazione per ogni tipologia di sito. Come applicare al meglio queste linee guida può variare a seconda dei vari siti specializzati, che possono richiedere accorgimenti mirati. In particolar modo vanno tenuti in considerazione alcune categorie comuni:  Siti di contenuto informativo e pubblicitario;  Siti di contenuto tecnico e scientifico;  Siti di contenuto amministrativo e burocratico. Qualche accenno alla parte amministrativa e burocratica verrà svolto nel seguito, vista la personale esperienza lavorativa a proposito. Per gli altri casi si rimanda al testo di Robero Scano che ha un ottimo e completo capitolo2 sull’argomento curato da Michele Diodati. Suggerimenti in (X)HTML Vorrei riportare alcuni brevi accenni agli accorgimenti più semplici che si possono facilmente realizzare nel linguaggio (X)HTML per rendere i testi più chiari e comprensibili. Acronimi ed abbreviazioni Il punto di controllo 4.2 delle WCAG richiede di: “Specificare il significato di ogni abbreviazione o acronimo nel documento laddove compaia per la prima volta.”. 1 2 [http://www.w3.org/TR/WCAG10-CORE-TECHS/#writing-style] Roberto Scano “Accessibilità: dalla teoria alla realtà” – capitolo 28. - 193 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Nei siti, soprattutto scientifici, capita molto spesso di leggere numerose sigle che risultano di significato abbastanza oscuro per un lettore neofita e che ne ostacolano la comprensione del testo. Per evitare questo inconveniente è buona norma fornire in ciascuna pagina la forma estesa di tutte le sigle e le abbreviazioni utilizzate. Lo si può fare semplicemente sia nel testo visibile, affiancando alla sigla la sua forma estesa, sia a livello di codice, usando gli appositi elementi ABBR e ACRONYM del linguaggio. ABBR si usa per abbreviazioni come Sig., Dott, ecc. eccetera. ACRONYM si impiega per gli acronimi tipo FIAT, HTML e tutte le sempre più numerose sigle informatiche. Segue un semplice esempio in XHTML 1.1: XHTML In questo esempio è stato aggiunto anche un attributo che rende esplicito il cambiamento di lingua, come spiegato a parte. La maggior parte dei browser è in grado di trattare questi attributi in maniera particolare, quando non visibile e non notificata in qualche modo dai browser può essere utile rendere consapevole l’utente della presenza nel codice della forma estesa di una abbreviazione o di un acronimo. In genere la maggior parte dei browser attuali presentano una sottolineatura tratteggiata sotto questi termini, visualizzando l’attributo TITLE al passaggio del mouse. Tramite CSS è possibile ottenere anche altri effetti di passaggio, come ad esempio il fatto che il cursore cambi di forma. Questo accorgimento serve soprattutto per chi usa Internet Explorer. Gli altri browser mostrano già da soli all'utente la sottolineatura tratteggiata delle sigle, quando sia presente nel codice di marcatura una forma estesa. Un piccolo appunto, fonte di argomento di discussione nei forum dedicati, è la richiesta esplicita del punto di controllo di marcare necessariamente solo la prima delle occorrenze di un termine in una pagina. La scelta di marcare anche le altre è lasciata a discrezione del programmatore. In genere questa scelta è sufficiente, per quanto, in pagine molto lunghe e complesse, potrebbe essere utile marcare con ABBR o ACRONYM più occorrenze della medesima sigla, nel caso che le sue ripetizioni appaiano isolate nel testo e molto distanziate tra loro. - 194 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Citazioni Le citazioni devono essere marcate utilizzando gli elementi < Q> e
che non devono essere usati invece per puri effetti estetici come ad i rientri del testo, per i quali vanno utilizzati i fogli di stile. La differenza fra i due marcatori consiste nel fatto che dovrebbe essere utilizzato per le citazioni brevi, inserite in genere all’interno del flusso normale del testo. Anche per questo viene circondato automaticamente dagli apici dai browser visuali. Pertanto il testo contenuto non dovrebbe averne di propri. L’utilizzo dell’elemento invece dei caratteri ASCII o dell’entità " consente al browser di visualizzare le virgolette nella codifica locale. L’utilizzo delle virgolette ed i vari stili di virgolette variano automaticamente da lingua a lingua. L’elemento non risulta ancora supportato da tutti i browser e richiede la presenza dell’attributo LANG al fine di una corretta lettura ed adeguamento allo stile locale delle virgolette. Ecco un breve esempio: We are such stuff as dreams are made on L’elemento
serve invece ad identificare un intero blocco di citazione che necessita di maggior visibilità, per separarlo e distinguerlo dal resto del testo. Il blocco interno di BLOCKQUOTE andrebbe marcato come un paragrafo. Anche in questo caso molti sviluppatori hanno però iniziato ad utilizzare scorrettamente l’elemento
per impaginare direttamente i contenuti anziché ricorrere ai fogli di stile. Anche in questo caso ecco un breve esempio:

Do not use quotation markup for formatting effects such as indentation. [Priority 2]

In quest’esempio è stato aggiunto anche l’attributo CITE che può essere usato anche con il precedente elemento Q. Se CITE viene utilizzato come attributo, il suo valore è un URI (Uniform Resource Identifier) che indica il documento sorgente. Questo attributo è stato implementato con lo scopo di dare informazioni sulla sorgente da cui la citazione è stata tratta, ma quasi mai i browser visuali li impiegano. Esiste anche la possibilità di avere un elemento separato , in tal caso non deve esser un URI e viene inserito per fornire il nome dell’autore. In questo secondo caso sarà reso esplicitamente visibile come testo anche dai browser grafici se non specificato altrimenti. - 195 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Cambi di lingua Per facilitare la lettura degli screen-reader e la catalogazione di un documento da parte dei robot automatici, un documento (X)HTML deve utilizzare una dichiarazione di lingua che varia a seconda che si tratti di un HTML e XHTML (fino alla versione 1.0), o di un XHTML 1.1. Tuttavia può capitare con una certa frequenza di introdurre dei termini in una lingua differente, ad esempio per un documento in italiano non è infrequente impiegare dei termini in inglese che dovrebbero essere gestiti al meglio da programmi utente che pronuncino il testo. Il problema è che, coloro che usano un sintetizzatore vocale, potrebbero non comprendere una parola inglese presente in una pagina, se questa viene letta all'italiana. Per consentire alle tecnologie assistive di leggere ciascuna parola in modo comprensibile, cioè secondo le regole di pronuncia della lingua a cui appartiene, è opportuno segnalare nel codice di marcatura, per mezzo dell'apposito attributo LANG (o XML:LANG se si usa XHTML 1.1), i cambi di lingua presenti nel testo. Questa raccomandazione è espressamente contenuta nel punto di controllo1 4.1 delle WCAG 1.0. Va ricordato che stadio attuale di sviluppo delle tecnologie assistive, per alcuni sintetizzatori vocali il cambio di lingua per ogni parola straniera può ancora produrre rallentamenti notevoli nella lettura della pagina. A detta di persone che lavorano nel settore le cose stanno migliorando anche da questo punto di vista e il tempo di caricamento dei dizionari stranieri è stato notevolmente ottimizzato, soprattutto per JAWS che è passato da una certa lentezza delle versioni 4 fino ad una buona funzionalità a partire già dalla versione 6. Come anche raccomandato da numerosi autori tra cui Roberto Ellero e Luca Mascaro alla conferenza di Arese e Michele Diodati nel suo sito Web, può essere utile evitare di marcare i cambi di lingua per quelle parole inglesi che sono state assorbite dalla lingua italiana. Stessa valutazione per i termini che rimarrebbero ugualmente comprensibili all'ascoltatore anche se pronunciate all'italiana dal sintetizzatore vocale, come ad esempio trend, big, font, eccetera. Pubblica Amministrazione Come notato in precedenza, se da parte delle WCAG 1.0 e 2.0 viene data la necessaria rilevanza al problema della comprensibilità dei testi, dall’altra stupisce che invece le legislazioni statali non abbiano inteso recepire queste direttive, nella legge italiana ed in quella americana infatti non vi sono espliciti riferimenti a questo principio. 1 [http://www.w3.org/TR/WCAG10/#tech-identify-changes] - 196 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Ed è un peccato, perché sono proprio le amministrazioni statali a dover fare il migliore uso di questo principio. I contenuti dei loro siti sono, per loro stessa natura, esposti alla consultazione di un gran numero di cittadini. Per questo i numerosi enti statali che possiedono un sito dovrebbero essere i primi a mettere in atto i principi di una lettura chiara e comprensibile delle informazioni. Il linguaggio spesso oscuro della burocrazia è però il linguaggio comune delle amministrazioni pubbliche, un linguaggio che deve assolutamente cambiare avvicinandosi alle espressioni della lingua usata dagli utenti, senza per questo perdere la necessaria precisione ed il necessario rigore formale. A tal proposito, lo stesso Ministero della funzione pubblica ha emanato una direttiva per contribuire alla semplificazione del linguaggio usato dalle pubbliche amministrazioni per la redazione dei loro testi scritti. La direttiva è datata 8 Maggio 2002 firmata dall’allora Ministro per la funzione pubblica Franco Frattini, precede quindi di gran lunga la stessa legge Stanca. Nelle pagine della direttiva sono presenti dei suggerimenti sia per lo stile da tenere nella redazione dei documenti che per il modo di organizzare la comunicazione. La direttiva del ministero sulla semplificazione del linguaggio dei testi amministrativi è articolata in 20 punti suddivisi in 2 sezioni: ne riporto i principi. Gli esempi molto illuminanti e le necessarie spiegazioni possono essere letti consultando il testo integrale1 disponibile sulle pagine del ministero: Le regole di comunicazione e di struttura giuridica: 1. Avere (e rendere) sempre chiaro il contenuto del testo; 2. Individuare sempre il destinatario; 3. Individuare le singole informazioni e inserirle nel testo in modo logico; 4. Individuare e indicare i contenuti giuridici del testo; 5. Individuare la struttura giuridica più efficace per comunicare gli atti; 6. Verificare la completezza delle informazioni; 7. Verificare la correttezza delle informazioni; 8. Verificare la semplicità del testo; 9. Usare note, allegati e tabelle per alleggerire il testo; 10. Rileggere sempre i testi scritti; Le regole di scrittura del testo: 1 [www.funzionepubblica.it/chiaro/direttiva.pdf] - 197 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 1. Scrivere frasi brevi; 2. Usare parole del linguaggio comune; 3. Usare pochi termini tecnici e spiegarli; 4. Usare poco abbreviazioni e sigle; 5. Usare verbi nella forma attiva e affermativa; 6. Legare le parole e le frasi in modo breve e chiaro; 7. Usare in maniera coerente le maiuscole, le minuscole e la punteggiatura; 8. Evitare neologismi, parole straniere e latinismi; 9. Uso del congiuntivo; 10. Usare in maniera corretta le possibilità di composizione grafica del testo; Come si vede i principi sono chiari ed auto-esplicativi. Un testo ben fatto, che sorprende per essere stato redatto da un Ministero italiano. Ancora più significativi e illuminanti sono gli esempi riportati nel documento di cui consiglio caldamente la lettura per chi è interessato alla materia. III.12 - Riadattamento a posteriori Come accennato, le considerazioni esposte sul tema dell’accessibilità sono sopravvenute a seguito della diffusione a largo raggio di un cattivo stile di programmazione che ha reso del tutto inaccessibili parecchi dei contenuti disponibili sul Web. Di conseguenza, la considerazione del problema dell’accessibilità nello sviluppo del proprio sito Web è intervenuta, per molti sviluppatori, a progetto già avanzato se non del tutto concluso. Molti siti sono stati pubblicati ignorando completamente questa fondamentale chiave di lettura. La gravità di questa inaccessibilità è molto differente a seconda delle varie realizzazioni e del fatto che siano stati o meno utilizzati gli standard raccomandati come XHTML e i CSS. Anche per questo il problema del riadattamento a posteriori dei siti Web già esistenti e non accessibili (per questa operazione in letteratura viene spesso utilizzato il termine inglese retrofitting) potrebbe essere spesso piuttosto oneroso e complesso da portare a termine. Spesso più costoso che non preparare un sito accessibile dal nulla1. Su quest’argomento esiste un apposto documento del W3C, che come al solito, rappresenta lo standard in materia. 1 Joe Clark: “Accessibility generally is easy, as access advocates claim – for new pages, at least. And it is a lot of work to fix up old pages, as developers claim.”. - 198 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Questo documento ha una prima versione di bozza1 del 7 ottobre 2004, ed è arrivato al suo attuale sviluppo in un documento2 più completo “Improving the Accessibility of Your Web Site”. Il documento offre una linea guida per rimuovere le barriere di inaccessibilità presenti nei siti esistenti suggerendo la procedura più efficiente e concreta e fornisce linee guida per:  Chiarire il problema;  Pianificare un progetto di riadattamento, identificando le barriere e le priorità degli aggiustamenti da compiere;  Correggere gli errori in maniera efficiente e concreta;  Guidare ai passi successivi dopo il primo riadattamento del sito. Il documento è strutturato in alcuni punti cardine.  Per iniziare: o Nozioni basilari; o Scegliere l’obiettivo; o Informare sullo stato del progetto di riadattamento;  Valutazione del problema;  Ottimizzazione del riadattamento:   o Ottimizzazione delle conoscenze e delle capacità; o Ottimizzazione del processo; o Ottimizzazione degli strumenti; Dare una priorità alle correzioni: o Priorità degli impedimenti all’accesso; o Priorità delle aree d’intervento; Piano strategico conclusivo. Ho riportato questa breve sintesi strutturale tradotta in maniera essenziale per dare un’idea di che cosa può voler dire una strategia di riadattamento a posteriori, soprattutto per quanto riguarda delle grosse aziende. Un piano del genere può essere veramente dispendioso per delle grosse società e non stupisce che molte delle pagine esistenti siano rimaste, a tutt’oggi, inaccessibili. Per questi motivi molti autori non spingono più di tanto sull’adattamento a posteriori ad ogni costo. 1 2 [http://www.w3.org/WAI/EO/Drafts/retrofit/Overview-7-October-2004.html] [http://www.w3.org/WAI/EO/Drafts/retrofit/Overview.html] - 199 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Da parte di privati o piccoli enti il processo è meno drastico e può risultare più adattabile e meno dispendioso. Ad ogni modo,anche nei casi peggiori, è solo un fatto di dispendio di risorse, non di infattibilità1 del processo. A tale proposito vale la pena ricordare che esistono dei termini di legge ben precise. Per quanto riguarda le norme americane, esse dispongono che le vecchie pagine degli enti federali possano rimanere non aggiornate e potenzialmente inaccessibili fin quando non vengano toccate. Ad ogni modo se una vecchia pagina viene aggiornata o alterata in un modo qualunque, non importa se poco o tanto, deve essere fornita una accessibilità completa. Senza contare che una pagina deve essere aggiornata su richiesta ragionevole di un utente.2 In Italia qualcosa di analogo viene previsto con la legge 04/2004 ed il correlato decreto ministeriale del 8/Luglio/2005. Innanzi tutto, gli obblighi sono a carico, a grandi linee, solo delle pubbliche amministrazioni, come vedremo più accuratamente nella sezione dedicata alla legge. Questi soggetti non possono stipulare, a pena di nullità, contratti per la realizzazione e la modifica di siti internet quando non è previsto che essi rispettino i requisiti di accessibilità stabiliti dal decreto. I contratti in essere alla data d’entrata in vigore del decreto, in caso di rinnovo o modifica, sono adeguati, a pena di nullità, alle disposizioni della legge circa il rispetto dei requisiti di accessibilità, con l'obiettivo di realizzare tale adeguamento entro dodici mesi dalla data di entrata in vigore del medesimo decreto. Data che è abbondantemente trascorsa al momento di redigere questa tesi. Tuttavia questo vale solo in caso di rinnovo o modifica. Ovviamente risulta piuttosto assurdo che un sito Web di una pubblica amministrazione non venga modificato per un tempo così lungo. III.13 - Compatibilità con le tecnologie obsolete La normativa italiana, al primo fondamentale requisito del decreto ministeriale del 8/luglio/2005 chiede: “Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie 1 Joe Clark: “It is not impossible to retrofit even many thousands of old pages, no matter what anyone tells you; it is merely expensive to do so. If you’ve got the money, do it.” 2 Joe Clark: “Old pages may remain unappraised and potentially inaccessible as long as they are untouched. But if an old page is updated or altered in any way, no matter how minor, full-on accessibility must be provided. Also, a page must be upgraded on reasonable request from a visitor”, “Building Accessible websites” - chapter 14. - 200 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR definite da grammatiche formali pubblicate, nelle versioni più recenti disponibili quando sono supportate dai programmi utente.” Allo stesso modo le WCAG 1.0 al punto di controllo 11.1: “Utilizzare le tecnologie W3C quando sono disponibili e sono appropriate per un certo compito usando le versioni più recenti quando sono supportate dai programmi utente.” In entrambe i casi, l’utilizzo delle versioni più recenti delle tecnologie e delle grammatiche formali è raccomandato in relazione al fatto esse vengano supportate dai programmi utente. La richiesta di aggiornare le tecniche quando possibile è chiara, meno evidente è la prassi da adottare durante la fase intermedia, durante la quale alcuni programmi utente obsoleti, come ad esempio vecchi browser, sono ancora in utilizzo. Retro-compatiblità In effetti, gli approcci suggeriti per questo problema sono abbastanza disparati. Durante il periodo dello sviluppo disorganizzato del Web si è assistito ad un proliferare di soluzioni ad hoc per adattarsi alle incompatibilità dei vari browser più datati, tra cui le generazioni 4 di Microsoft Internet Explorer e di Netscape. Per seguire le loro interpretazioni non standard del codice HTML sono spesso stati escogitati dei trucchi e delle soluzioni molto poco eleganti. Per fortuna le tendenze attuali sono quelle di mirare ad una più completa standardizzazione e compatibilità. Il vantaggio principale di questa conformità con gli standard è la realizzazione del progetto di massima “Write Once, Read Anywhere”. Invece di produrre del codice differente per tutte le possibili versioni della pagina (Netscape, Internet Explorer, su Windows o Macintosh), si scrive la pagina in modo definitivo in accordo con le specifiche, e di conseguenza ogni dispositivo dovrebbe essere in grado di visualizzare la pagina correttamente, anche se con delle discrepanze tollerate. Resteranno ovviamente delle specifiche differenze come ad esempio l’aspetto dei caratteri, e tuttavia la progettazione dovrebbe essere sufficientemente flessibile da non rendere il contenuto inaccessibile ad alcun programma utente. Molti autori, tra cui Joe Clark1, consigliano un approccio abbastanza determinato nel problema. Il suggerimento è di evitare di scrivere codice concepito appositamente per browser datati come Netscape 4, di non impiegare elementi proprietari deprecati del linguaggio e, in genere, 1 [http://joeclark.org/book/sashay/serialization/Chapter05.html] - 201 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR di scordarsi di tutto quello che non appartiene alle specifiche ufficiali.1 La decisione presa nel passato dagli sviluppatori di adattare il codice sugli arbitrii dei browser non compatibili, ha permesso fino a poco tempo fa la proliferazione di queste tecniche scorrette. Molti browser ai giorni d’oggi hanno una modalità definita proprio di capriccio (quirk), in cui entrano al momento di riconoscere un codice HTML scorretto sintatticamente, che tentano di interpretare in qualche modo. Per fortuna la qualità dei programmi utente si sta evolvendo verso una pulizia migliore e sono disponibili un numero sufficiente di browser con ragionevoli conformità agli standard da poter progettare delle pagine pienamente compatibili. Il primo problema che però viene alla mente è che cosa possono fare le persone che hanno ancora in uso applicativi come Netscape 4 o vecchi browser che non sono adattati alle norme. La questione formale è se dovrebbero essere considerati o no come una minoranza di utenti svantaggiati che sono messi in condizione di handicap per via delle loro apparecchiature obsolete. Il paragone, apparentemente possibile, con utenti disabili dotati di tecnologia assistiva, non è in realtà applicabile: Netscape 4 e browser obsoleti giocano un ruolo alquanto distruttivo nei confronti degli standard, mentre le tecnologie accessibili sono progettate per adattarvisi. Gli sviluppatori ed i progettisti non sono i soli a dover farsi carico dell’accessibilità, gli utenti devono dotarsi delle apparecchiature adatte e funzionali, e soprattutto è compito dei progettisti dei programmi utente sviluppare dei prodotti che rappresentino al meglio gli standard proposti dal W3C adeguandosi al meglio alle linee guida UAAG (User Agent Accessibility Guidelines). Da questo punto di vista, quando una tecnologia adattativa come uno screen-reader ignora o interpreta scorrettamente degli elementi HTML standard, i progettisti del sito possono considerare ragionevolmente di aver svolto il loro compito. E’ opinione, a mio avviso corretta, di Joe Clark che non sia sensato chiedere agli sviluppatori e ai progettisti di occuparsi anche di questo problema. Adattarvisi ad ogni costo andrebbe a discapito degli standard. Aderenza agli standard E’ sicuramente un problema minore il fatto che utenti con apparecchiature non conformi accedano male al Web piuttosto che fare un passo indietro nell’adozione degli standard e creare problemi a tutti gli altri. 1 Joe Clark: “Forget about coding special workarounds for Netscape 4. Forget MARQUEE and other nonstandard HTML tags embraced and extended by Microsoft or “innovated” by Netscape. Forget anything that isn’t in the spec.” - 202 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Anche nel seminario1 tenuto ad Arese da Roberto Scano e Luca Mascaro, si è affrontato indirettamente questo punto. I docenti hanno evidenziato come la questione sia piuttosto delicata, si tratta di adottare il buon senso nello scegliere se e quando forzare l’utilizzo delle nuove tecnologie, stimolando sicuramente in tal caso il ricambio naturale degli user agent ma finendo inevitabilmente per tagliare fuori una minima parte di utilizzatori. Un esempio classico in questi anni è quello della compatibilità all’indietro con i vecchi browser Explorer e Netscape 4 per quanto riguarda i fogli di stile nei riguardi dei quali questi programmi hanno delle grosse deficienze. Anche in questa sede è stata fatta presente la circostanza che in mancanza di una stimolazione di questo tipo si rischia di restare al palo con tecnologie obsolete che verranno aggiornate con molta lentezza. Mio personale convincimento è che l’obiettivo a cui puntare sia la massima aderenza agli standard, il sacrificio di browser datati è necessario e persino da augurarsi giacché programmi utente migliori, aggiornati e compatibili come Firefox ed Opera, sono reperibili gratuitamente e per di più con bassi requisititi di sistema. Anche browser testuali, come Lynx, hanno subito l’evoluzione necessaria per potersi adattare agli standard W3C e nelle loro ultime versioni, possono essere impiegati con soddisfazione per leggere del codice accessibile2. Vorrei chiudere questo argomento accennando alla attenzione rivolta a questo argomento dalle WCAG 2.0. L’intero principio 4 (Robust) è dedicato all’argomento: “I contenuti devono essere robusti per l’uso attuale e futuro.”. L’approccio delle WCAG 2.0 è quello della definizione di una baseline. Il concetto verrà esposto al meglio nella sezione dedicata, qui vale comunque la pena ricordare che, proprio onde evitare un invecchiamento precoce delle nuove linee guida con lo sviluppo di nuove tecnologie innovative, il gruppo di lavoro del W3C ha preferito definire una piattaforma hardware e software a cui il progettista del sito Web si richiama per enunciare il livello di accessibilità del proprio lavoro. 1 Seminaro IWA Arese, Maggio 2005: “Legge Stanca: dalla teoria alla realtà” Joe Clark: “Ironically, these programs do a very admirable job of interpreting standard HTML. (Working under severe limitations can force higher quality.) An accessible HTML page remains accessible for these browsers.” 2 - 203 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR III.14 - Validazione e controllo Nel corso della trattazione abbiamo visto diverse metodologie per arrivare a produrre un lavoro di qualità. Quando ogni sforzo è stato fatto per creare o modificare pagine ad elevata accessibilità, la necessaria fase conclusiva è quella di verificare i risultati ottenuti. La raccomandazione proviene dallo stesso W3C ed è contenuta anche nell’appendice delle WCAG 1.0. In questo contesto si afferma che è necessario verificare l'accessibilità sia per mezzo di strumenti automatici che tramite la revisione umana. I metodi automatici sono generalmente più rapidi e convenienti ma non possono identificare tutti i problemi di accessibilità. La revisione umana può aiutare a garantire la chiarezza del linguaggio e una maggiore semplicità nella navigazione1. Nella stessa appendice raccomanda di cominciare ad usare i metodi di validazione al più presto, già nel primo stadio di sviluppo del progetto, visto che i problemi legati all'accessibilità che siano identificati subito sono i più facili da correggere e da evitare. La fase di controllo è di primaria importanza e non è per niente scontata o trascurabile, in effetti, la valutazione dell’accessibilità può dar luogo a non pochi equivoci. Come fatto notare non è possibile effettuarla con soli strumenti automatici e richiede la competenza di persone esperte. Questo dal momento che un programma di controllo può, ad esempio, verificare la presenza degli elementi e degli attributi richiesti, ma non può certamente qualificare il loro contenuto. Metodologia di verifica I passi da compiere sono quelli descritti nei documenti ufficiali del W3C, la sezione2 in appendice A delle WCAG da un elenco di procedure, riprese in parte dalla legge Stanca. Di seguito riporto l’elenco di alcuni importanti metodi di validazione, discussi in dettaglio nella sezione3 del documento sulle tecniche di applicazione. 1. Usare uno strumento di accessibilità automatico. È necessario ricordare che i software non risolvono tutti i problemi di accessibilità, come il reale significato del testo alternativo dei collegamenti, l'applicabilità di un equivalente testuale, eccetera; 2. Validare la sintassi (per esempio, HTML, XML, eccetera.); 1 “Validate accessibility with automatic tools and human review. Automated methods are generally rapid and convenient but cannot identify all accessibility issues. Human review can help ensure clarity of language and ease of navigation.” – [http://www.w3.org/TR/WCAG10/#validation] 2 [http://www.w3.org/TR/WCAG10/#validation] 3 [http://www.w3.org/TR/WAI-WEBCONTENT-TECHS#validation] - 204 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 3. Validare i fogli di stile CSS; 4. Utilizzare browser o emulatori solo testuali; 5. Utilizzare differenti browser grafici:  Con suoni e grafici caricati;  Con grafici non caricati;  Con suoni non caricati;  Senza mouse;  Con frame, script, fogli di stile e applet non caricati; 6. Utilizzare diversi browser, vecchi e nuovi; 7. Utilizzare un browser vocale, un lettore dello schermo (screen-reader), un software di ingrandimento di aree dello schermo (screen-magnifier), un display piccolo, eccetera; 8. Utilizzare controlli automatici di sintassi e grammatica. Una persona che legga una pagina con un sintetizzatore vocale può non essere in grado di decifrare una parola contenente errori di sintassi: eliminando i problemi grammaticali, si migliora sicuramente la comprensione dei contenuti; 9. Rivedere la chiarezza e la semplicità del documento. Statistiche di leggibilità, come quelle generate da alcuni editor di testi, possono essere degli utili indicatori. È altresì consigliabile chiedere ad un esperto di gestione dei contenuti (content manager) di valutare il testo, in modo che possa revisionarlo per verificarne la chiarezza. I content manager e gli esperti di usabilità possono migliorare anche l'usabilità dei documenti, identificando problemi culturali potenzialmente rilevanti che potrebbero sorgere a causa del linguaggio o delle icone utilizzate; 10. Invitare persone con una disabilità a revisionare i documenti. Utenti disabili esperti e principianti forniranno un valido ritorno di informazioni sui problemi di accessibilità, usabilità e sulle difficoltà incontrate. Questi suggerimenti sono divisi in tre grandi blocchi di analisi:  1-3: Verifica del codice (X)HTML e CSS per mezzo di strumenti automatici. Viene comunque fatto presente che i validatori automatici non sono in grado di controllare il significato dei contenuti e non possono portare a termine una analisi esaustiva;  4-7: I punti centrali riguardano controlli di fruibilità dei contenuti sotto diversi condizioni di accesso: con un browser testuale, con un emulatore di terminale, con differenti tipi di browser grafico, con browser vecchi e nuovi, con le immagini e senza immagini, con i suoni e senza i suoni, con il mouse e senza mouse, con il supporto per frame, linguaggi di script, fogli di stile e applet java disabilitato, con un browser vocale, con uno screen reader, con un ingranditore di schermo, con un monitor molto piccolo, eccetera;  8-10: Gli ultimi tre punti riguardano infine gli aspetti dell'accessibilità più vicini all’usabilità e alla capacità di comprensione del contenuto. Anche per questi controlli si - 205 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR suggerisce il ricorso a strumenti automatici: per esempio un correttore ortografico, per trovare ed eliminare i refusi dal testo, e un valutatore di leggibilità. Si consiglia anche esplicitamente di ricorrere al giudizio di revisori umani e in particolare di persone con disabilità: queste ultime, meglio di chiunque altro, potranno valutare se le misure prese per favorire l'accessibilità siano sufficienti oppure no. Per quanto riguarda i valutatori automatici, lo stesso W3C propone una pagina completa1 di strumenti di controllo a cui si può fare riferimento come utile supporto alla verifica. Parleremo più avanti di alcune di queste applicazioni. La legge Stanca propone nell’allegato A, comma 2 del decreto ministeriale del 8 Luglio 2005 una propria metodologia di verifica tecnica che non si discosta molto da queste linee guida. Questa fa ricorso a:  Strumenti automatici, tra gli altri si ricorda il servizio di validazione del W3C;  Strumenti semiautomatici, onde evidenziare problemi non riscontrabili dalle verifiche automatiche, anche qui si rimanda alla pagina degli strumenti di controllo del W3C;  Conoscenze dell'esperto tecnico sull'uso degli elementi e degli attributi secondo le specifiche del linguaggio. In particolare si suggerisce:  L’esame della pagina con diversi browser grafici, in differenti versioni e in diversi sistemi operativi;  Il controllo del contrasto del colore;  L’esame della pagina con browser testuali. Il testo dettagliato del decreto ministeriale è riportato in appendice di questo lavoro. Dopo aver esposto le linee guida della verifica tecnica vorrei passare ad un’esemplificazione del metodo per dare un’idea di come si possa svolgere un buon lavoro di verifica. Validazione (X)HTML e CSS. Il primo passo da compiere è quello di controllare la correttezza del documento. In particolare, per i documenti XHTML, sottoclassi di documenti XML, la correttezza formale si svolge in due passi: 1 [http://www.w3.org/WAI/ut3/ER/existingtools.html] - 206 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Controllo che il documento XHTML sia ben formato: cioè che sia conforme alle regole generali di un linguaggio XML, quindi abbia ad esempio gli elementi annidati correttamente, tutti i marcatori chiusi e scritti in minuscolo, i doppi apici sui valori degli attributi, eccetera;  Controllo che il documento XHTML sia valido: cioè che abbia una dichiarazione di grammatica formale in testa, una DTD (Document Type Definition) e che il resto del contenuti ne rispetti i vincoli sintattici definiti. La caratteristica di documento valido si affianca a quella di documento ben formato per costruire documenti XHTML adatti ad essere elaborati automaticamente. C'è da sottolineare che un documento ben formato può non essere valido rispetto ad una grammatica, mentre un documento valido è necessariamente ben formato. Tra l'altro, un documento valido per una grammatica può non essere valido per un'altra grammatica. Questo passo formale può facilmente essere espletato in maniera automatica con uno dei tanti validatori del linguaggio che contemporaneamente ne verificano anche la buona formattazione. Il consiglio è di usare quello ufficiale1 del W3C che è più che sufficiente per gli scopi di una corretta validazione. Allo stesso modo, se la pagina XHTML contiene un riferimento ad un foglio di stile, e per quanto detto fino ad ora dovrebbe proprio contenerlo, è possibile eseguire una verifica sintattica anche del CSS, direttamente con gli strumenti del W3C appena indicati. Il CSS può essere anche controllato separatamente con un altro strumento 2 di validazione apposito, sempre fornito dal W3C. Questi strumenti ufficiali sono affiancati da una numerosa mole di validatori spesso totalmente gratuiti, come ad esempio anche il CSSCheck3 del WDG. Non è una cattiva idea quella di sottoporre il documento anche ad altri analizzatori, pur avendo avuto una conferma di valutazione anche da quelli ufficiali. In particolar modo la barra di accessibilità4 contiene numerosi strumenti di valutazione tra cui Torquemada e WebExact e rappresenta una valida suite di strumenti. Di questi parleremo più approfonditamente in seguito. 1 2 3 4 [http://validator.w3.org/] [http://jigsaw.w3.org/css-validator/] [http://www.htmlhelp.com/tools/csscheck/] [http://www.webaccessibile.org/wat/WAT_IT_1-2.exe] - 207 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Griglia di valutazione Una volta portato a termine questo passo formale e totalmente automatizzabile si passa nell’ambito della verifica di stretta accessibilità e qui le cose incominciano a farsi più complesse. Innanzi tutto il progettista dovrebbe aver già utilizzato la griglia di controllo1 predisposta dal W3C per la verifica manuale del codice prodotto. Se non lo avesse ancora fatto, questo è il momento buono per stamparla e per procedere ad una verifica manuale delle singole voci. Questo schema di validazione riporta i punti di controllo delle WCAG, suddivisi per priorità con a lato delle caselle di spunta per riportare lo stato della verifica manuale. La griglia è reperibile sul sito del W3C e ne esistono anche delle traduzioni 2 in italiano. Questo può essere un ottimo lavoro di controllo, se svolto in maniera accurata può garantire da solo il raggiungimento di un’elevata accessibilità dei contenuti prodotti. Un'altra utile applicazione di queste griglie di controllo trova applicazione nell’analisi che può essere condotta da un esperto interno di una società che commissioni all’esterno un sito ad elevata accessibilità. In questo caso, infatti, è il committente che può controllare direttamente i risultati del prodotto fornito, purché però possa contare al proprio interno su personale sufficientemente qualificato. Una persona mediamente competente in informatica, con in mano la griglia di valutazione, è in grado di smascherare evidenti azioni truffaldine ai danni dell’ente. Validatori automatici In questa sezione vorrei fare una breve panoramica dei più importanti strumenti di controllo e di validazione. Non è mia intenzione entrare nel merito e nello specifico di ogni programma, la cosa richiederebbe spazio e competenze che non sono a mia disposizione. Il materiale consultabile di riferimento disponibile consente di approfondire ogni singolo applicativo secondo le preferenze dell’utente. Si tratta di applicativi utilizzabili liberamente in rete, in genere accettano in ingresso l’indirizzo internet di una pagina e forniscono in uscita una lista di informazioni tra cui: 1 2  La riga o le righe contenenti errori o avvisi;  L'identificazione della segnalazione;  Il codice di marcatura dell'elemento contenente errori o avvisi; [http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/full-checklist] [http://www.robertoscano.info/files/wcag10/full-checklist.html] - 208 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  L'annotazione della tipologia per errori o avvisi.  Il riferimento alla normativa di accessibilità violata;  Eventuali suggerimenti per ripristinare una informazione accessibile. Alcuni tra questi programmi, al riconoscimento di un avvenuto raggiungimento di accessibilità permettono di usare loghi personalizzati come certificazione mentre altri preferiscono non rendere disponibili loghi di conformità. Tali validatori sono sicuramente d’indubbia utilità, ma non possono completare l’analisi da soli in maniera automatica, come ribadisce accuratamente anche il W3C nel suo sito ufficiale1. I problemi che questi valutatori automatici portano con se per la loro stessa natura sono diversi, tra cui, solo per citare alcuni evidenti esempi:  Incapacità di valutare tutti gli oggetti presenti in una pagina che non siano il codice (X)HTML o CSS, questo vale ad esempio per JavaScripit, animazioni, PDF;  Impossibilità di analizzare automaticamente tutti i punti di controllo. Alcune linee guida richiedono chiaramente un giudizio da parte del valutatore: identificare se il linguaggio utilizzato sia chiaro e semplice oppure se sono presenti degli opportuni menu di navigazione sono due esempi di requisiti non verificabili automaticamente;  Incapacità di valutare la correttezza e la funzionalità di un testo, un esempio sono i contenuti dei testi alternativi;  Incapacità di discriminare tra una tabella d’impaginazione ed una tabella di dati, questo non permette loro di rilevare un utilizzo inaccessibile delle tabelle dati a scopo di impaginazione. Da queste ed altre osservazioni si ribadisce la necessità vincolante di aggiungere alla loro analisi quella di un tecnico professionale. W3C Validator Il W3C validator2 è il validatore ufficiale del Consorzio World Wide Web. Si tratta, in effetti, di un analizzatore sintattico arricchito con alcune norme basilari sull’accessibilità. 1 “There is as yet no tool that can perform a completely automatic assessment on the checkpoints in the guidelines, and fully automatic testing may remain difficult or impossible.” – [http://www.w3.org/WAI/WCAG1-Conformance.html] 2 [http://validator.w3.org/] - 209 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Ne consegue che i risultati prodotti, per quanto possano definire in maniera esatta la validità del codice prodotto, non possono comunque garantire il raggiungimento di qualità necessaria, cosa per altro valida per tutti gli altri validatori automatici. Purtroppo il valutatore W3C è in grado di controllare esclusivamente la sintassi, non può assolutamente intervenire sul contenuto delle informazioni inserite. Non controllando il valore degli attributi, valida senza incertezze anche espressioni del tipo: Xml:lang=”Klingoon” Ad ogni modo è un valido esaminatore del testo e può essere usato con profitto per una prima scrematura automatica. Consente l’esposizione del bollino ufficiale del W3C, che si ricorda, è una certificazione sulla validità sintattica (X)HTML e CSS, non sull’accessibilità. La barra di accessibilità Un strumento fondamentale per la valutazione è la barra di accessibilità1 del WAT-C2 (Web Accessibility Tool Consortium). Si tratta di un applicativo che può essere installato su Microsoft Internet Explorer e che aggiunge al browser una barra contenente numerosi strumenti di analisi. Il suo servizio integra molteplici funzionalità, tra le altre:  Validatori (X)HTML e CSS della sintassi della pagina e dei fogli di stile;  Ridimensionamento dello schermo per i test di visualizzazione su risoluzioni differenti;  Analisi dei fogli di stile con, attivazione, disattivazione, e controllo;  Analisi delle immagini con controllo e visualizzazione dei testi alternativi;  Test dei colori con richiamo al Color Contrast Analyzer e simulazioni per cecità parziale ai colori;  Analisi della struttura del documento per controllare: HEADER, LIST, LABEL, BLOCKQUOTE, Q, JAVASCRIPT, ACCESSKEY, TABINDEX, TABLE, DIV, FRAME, TITLE, LANG e numerosi altri oggetti;  Strumenti di analisi dell’accessibilità come Torquemada, Juicy Studio, WebExact, Lynx, AccMonitor;  Informazioni sulla pagina come statistiche e metadati;  Listato del codice originale con gli attributi deprecati ed un analizzatore DOM. Lo strumento è parecchio completo e del tutto gratuito, vale certamente la pena di conoscerlo e di impiegarlo, l’unico problema è che è disponibile solamente per Opera e per Internet 1 2 [http://www.webaccessibile.org/wat/WAT_IT_1-2.exe] [http://www.wat-c.org/tools/index.html] - 210 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Explorer sotto Windows. Personalmente ho riscontrato dei problemi a seguito della sua installazione sulla versione 7.0 di Explorer. HTML Tidy Un primo validatore elementare di codice (X)HTML è HTML Tidy1, originalmente sviluppato da Dave Ragget ed ora passato ad un gruppo di Surce Forge. Il progetto originario è quello non tanto di un validatore, piuttosto di un correttore di codice che permetta di ripulire la sintassi scorretta del linguaggio (X)HTML. Tidy, infatti, è in grado di produrre in uscita un codice sintatticamente corretto cercando di ripulire il formato originario secondo le specifiche del W3C. Anche per questo nella barra di accessibilità viene inserito insieme ad i validatori del W3C e presentato come elemento di controllo/riparazione del codice. Nella pagina ufficiale di presentazione del prodotto si definiscono i suoi intenti, da queste note ho tratto alcune delle successive considerazioni. Nell’editare una pagina HTML è facile commettere degli errori, sarebbe comodo avere a disposizione una maniera semplice per correggere questi errori automaticamente in un codice pulito. Tidy è un programma d’utilità non a pagamento in grado di lavorare anche con codice parecchio scorretto, generato da editor visuali HTML e da strumenti di conversione particolari. E’ in grado anche di segnalare dove è il caso di porre maggiore attenzione ai problemi d’accessibilità per le persone disabili. Tidy è in grado di correggere un ampio raggio di problemi e di mettere in evidenza i punti in cui è necessario l’intervento del programmatore. Ogni elemento viene elencato completo di riga e colonna in modo che vi si possa accedere poi facilmente da un qualunque editor (X)HTML. Tidy non genera una versione ripulita del codice se vi sono stati riscontrati dei problemi che il programma non è in grado di trattare correttamente. Questi vengono segnalati come errori, piuttosto che come avvertimenti nella pagina. Color Contrast Analyzer Il Colour Contrast Analyzer, è uno strumento richiamato anche dalla barra di accessibilità. E’ disponibile sul sito2 del Juicy Studio nella sua più recente versione 1.1. Si tratta essenzialmente di uno strumento per testare le combinazioni di colore di sfondo in relazione a quelle di primo piano, allo scopo di determinare se sono in grado di fornire un buon 1 2 [http://www.w3.org/People/Raggett/tidy/] [http://juicystudio.com/services/colourcontrast.php] - 211 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR livello di visibilità. Inoltre sono previste funzionalità per creare delle simulazioni di alcune tipiche condizioni legate alla cecità dei colori. La versione 1.0 si basa sull’algoritmo di controllo presente nelle WCAG 1.0 e nella legge Stanca con tutti i limiti discussi nella sezione relativa all’uso del colore. I nuovi algoritmi proposti dal WCAG 2.0 e le nuove funzionalità sono state integrate nella versione 1.1, disponibile anche in italiano sul sito segnalato e su quello di WebAccessibile1. WatchFire Bobby, della WatchFire si trova spesso come uno degli strumenti di controllo più citati soprattutto nei testi di qualche anno fa. Recentemente è stato affiancato e sostituito in rete da WebExact2 che è anche integrato nella barra di accessibilità. L’utilizzo è semplice, passando in rete l’indirizzo la pagina Web al validatore. Forse è leggermente più lento degli altri nell’analisi del codice. Al termine della fase di valutazione, vengono proposte quattro differenti cartelle contenenti analisi dettagliate:  Generale: Un riepilogo complessivo dell'analisi effettuata contenente le dimensioni del documento, un elenco dei metadati e un sunto degli elementi contenuti all'interno della pagina;  Qualità: Questa funzionalità riporta l’efficienza e la compatibilità della pagina con i vari browser, oltre che il numero di collegamenti presenti nella pagina;  Accessibilità: Un report tabellare piuttosto accurato dei tutti i punti di controllo ordinati per priorità, consente di selezionare ed estendere l'analisi al singolo errore con la visualizzazione della riga. Il report presenta avvisi ed errori in senso stretto. Ogni punto di controllo ha un collegamento ad una pagina del sito di WebXACT contenente dettagliate informazioni tecniche utili alla valutazione;  Privacy: Il modulo privacy effettua il controllo sull'eventuale presenza della dichiarazione P3P e di eventuali pagine contenenti moduli di invio dati. E’ un programma piuttosto completo e riporta una valutazione attenta dell’errore corredandola con tutte le informazioni del caso e con gli opportuni suggerimenti per la correzione. Come accennato ha forse come unica pecca una leggera lentezza, per altro di nessun ostacolo alla validazione. 1 2 [http://www.webaccessibile.org/argomenti/argomento.asp?cat=593] [http://webxact.watchfire.com/] - 212 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Cynthia Says Cynthia Says è sviluppato utilizzando il sistema HiSoftware AccMonitor integrato, a seguito di registrazione, sulla barra di accessibilità ed esiste in diverse versioni. Una, del tutto gratuita si trova anche in rete1 e si possono direttamente sottoporre i documenti, per quanto solo a pagina singola. Nei criteri di valutazione si può scegliere quali normative di riferimento consultare e viene prodotto un report considerando eventualmente anche dei messaggi di avviso, oltre che di errore. Il sistema è efficiente e piuttosto veloce, ha il vantaggio di produrre come risultato un report in forma tabellare simile alla griglia di controllo delle WCAG 1.0. Per questo il report può risultare molto utile per la presentazione dell'analisi di accessibilità sviluppata in concomitanza con uno studio sulla griglia di controllo. Il programma non effettua i controlli che ritiene non applicabili o che non riesce ad eseguire sulla pagina, lasciando all'utente l'onere di valutare i punti di controllo non identificabili dall'applicazione. Si richiede una competenza media e una buona conoscenza dei punti di controllo delle WCAG 1.0. Torquemada Torquemada è sviluppato dall’iniziativa WebXtutti ed è disponibile sul sito 2 del gruppo. Non esiste attualmente una versione scaricabile ed eseguibile non in linea per quanto essa sia annunciata. Come specificato sullo steso sito, il prodotto offre a chi sviluppa siti Web una metodologia completa d’analisi dell'accessibilità tramite uno strumento di controllo delle pagine che permette di capire velocemente quali siano le zone della pagina interessate dall'errore e il codice HTML corrispondente. Il sistema di analisi è molto preciso e dotato di un'interfaccia di visualizzazione degli errori particolarmente chiara ed innovativa studiata per fornire, a richiesta, un report visuale che permetta all'utente di capire immediatamente sia l'errore sia la sua importanza all'interno della struttura della pagina. Può presentare anche un report puramente testuale, in funzione delle direttive fornite dell'utente. 1 2 [http://www.cynthiasays.com/Default.asp] [http://www.webxtutti.it/testa.htm] - 213 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Torquemada è gratuito, in italiano e molto facile da utilizzare. Anche questo strumento di controllo è stato integrato nei menu degli strumenti della barra di accessibilità. Wave Accessibility Tool Altro strumento integrato nel menù della barra di accessibilità è Wave Accessibility Tool1 del WebAIM (Web Accessibility In Mind), una delle organizzazioni più attive nella diffusione e nello sviluppo dei concetti dell’accessibilità, presente sul Web con molti articoli divulgativi. All’interno del loro applicativo è possibile scegliere la modalità di valutazione del documento, tra i vari parametri ci sono:  Le normative di riferimento;  Il livello di analisi  Gli elementi da sottoporre a controllo. Un report grafico con un’evidenziazione speciale per gli elementi della pagina permette di mettere in luce velocemente la struttura del codice (X)HTML. Gli elementi visualizzati sono selezionabili dalla pagina di configurazione dello strumento. Lynx Piuttosto utile è anche la presenza nella barra di accessibilità di un richiamo a Lynx. Lynx2 è un browser puramente testuale. Il report generato da quest’analisi è un testo semplice linearizzato, senza immagini. In coda viene aggiunta una lista dei collegamenti esterni del codice (X)HTML. Al fine di poter valutare l'effettiva accessibilità per i lettori dello schermo, è sempre utile accedere alla pagina Web con un browser testuale e visualizzarne i risultati. Vi sono però delle serie limitazioni nell'uso degli elementi di una pagina come ad esempio per quanto riguarda i campi moduli. CNIPA Vorrei concludere questa sezione sui validatori facendo un cenno anche al sistema di validazione del CNIPA, per quanto esso non possa sicuramente essere considerato tra quelli automatici. 1 2 [http://dev.wave.webaim.org/index.jsp] [http://lynx.isc.org/current/] - 214 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Tuttavia, allo stato attuale delle cose, il sistema di validazione del CNIPA risulta essere l’unico ufficiale e l’unico i cui loghi non possano essere esposti previa autorizzazione ufficiale. A differenza di tutti gli altri il CNIPA valuta il sito secondo la legge Stanca e consente l’esposizione dei relativi bollini di controllo solo a pagamento, ed i costi non sono affatto indifferenti, come dall’allegato1 F del decreto ministeriale del 8 Maggio 2005. Questa valutazione non implica nulla a proposito delle WCAG e deve essere rinnovata almeno annualmente. Per ulteriori informazioni in materia si consulti la sezione dedicata alla legge Stanca di questo lavoro. La cultura del bollino Il superamento delle valutazioni elencate permette in genere di apporre un bollino di conformità relativo al valutatore applicato. Va sottolineato che, a parte il bollino di controllo della validità sintattica del codice (X)HTML, che ovviamente non richiede ulteriori controlli manuali, tutti gli altri programmi citano esplicitamente anche la necessita di far esaminare la pagina da professionisti esperti e da utenti disabili. Non solo, ma queste valutazioni, necessarie in ogni caso per l’apposizione del bollino, non possono rappresentare in nessun modo un attestato ufficiale e restano sottoposte alla responsabilità del singolo valutatore. Un discorso a parte meritano invece i loghi di accessibilità rilasciati dal CNIPA. In tal caso l’esposizione del bollino è sottoposta alla valutazione a pagamento del CNIPA e risulta come certificazione ufficiale. Purtroppo questa considerazione non viene messa nel dovuto risalto: e questo si ripercuote negativamente sugli utenti, che hanno bisogno di vera accessibilità piuttosto che di bollini. Negli anni trascorsi, quando l’accessibilità stava diventando un fenomeno di moda, molti siti importanti esponevano dichiarazioni di conformità al massimo livello di accessibilità, valutata con diversi strumenti automatici senza passare per i dovuti controlli di verifica soggettiva. Spesso era sufficiente anche una rapida analisi da parte di un esperto per dimostrare del tutto inesatte queste dichiarazioni. Molti di questi atteggiamenti erano dovuti a superficialità, altri alla necessità di farsi propaganda. Per fortuna si è assistito recentemente ad una riduzione di questi inutili attestati, abbandonando soprattutto quelle dei validatori non ufficiali del W3C, in favore di una più 1 [http://www.pubbliaccesso.gov.it/normative/DM080705-F.htm] - 215 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR corretta esposizione delle informazioni sull’accessibilità e sui sistemi impiegati per ottenerla. Le dichiarazioni di accessibilità sono esposte nei siti più qualificati e sono riassunte in una pagina completa di informazioni sull’usabilità del sito, spesso accompagnata anche dall’elenco degli ACCESSKEY implementati nel codice. Queste sezioni hanno il grosso vantaggio di mostrare in dettaglio gli accorgimenti impiegati per elevare il grado di accessibilità del sito senza esporre delle pretese assolute e scarsamente documentabili. Ci si augura che questa modalità più attenta di esprimere l’analisi compiuta nei confronti dell’accessibilità prenda presto piede in luogo delle inutili fiere di bollini esposti in passato. Conformità del W3C Il W3C prevede che, al termine delle sue valutazioni sopra esposte, gli autori possono esporre a loro discrezione, sulle pagine controllate, degli appositi bollini di conformità alle WCAG 1.0 seguendo le relative istruzioni1 fornite dal consorzio. Figura 3 - Le tre icone di conformità WCAG 1.0 In alternativa possono essere incluse nel testo anche delle stringhe di significato analogo. Come ricordato, queste dichiarazioni rappresentano semplicemente una pretesa di conformità della pagina alle specifiche WCAG 1.0, ma non sono in nessun modo un attestato ufficiale di accessibilità, che nessun ente o organizzazione è in grado di rilasciare sulle conformità del W3C. III.15 - I costi dell’accessibilità Al termine di questa lunga esposizione sulle metodologie generali di programmazione per i siti Web accessibili vorrei terminare con una piccola appendice che volutamente riprende il tema di apertura di questo lavoro, e cioè la necessità di apprendere e di fare propria una nuova filosofia progettuale e una nuova cultura nella realizzazione dei siti Web. L’acquisizione di questa forma mentale, quella di un buon sviluppo, come si era detto nell’introduzione, deve far parte della metodologia di lavoro di un professionista del Web. 1 [http://www.w3.org/WAI/WCAG1-Conformance.html] - 216 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Con questa chiave di lettura ha sicuramente più senso interpretare una delle richieste che ha suscitato un dibattito rilevante e che tuttora, nell’ambito della pubblica amministrazione, costituisce probabilmente il maggior ostacolo alla diffusione di questo metodo, quella del cosiddetto costo zero dell’accessibilità. Mi rifaccio, in questo senso, alla legge 04/2004 che analizzeremo meglio in una parte dedicata. In più punti questa normativa specifica che per la sua realizzazione non dovranno essere impiegati stanziamenti ulteriori a carico della pubblica amministrazione. Mi riferisco in particolar modo all’articolo 4 della legge1 stessa e all’articolo 4 del regolamento d’attuazione2. Nel testo si ribadisce che la legge deve essere applicata in tutte le sue parti senza costituire onere aggiuntivo per le pubbliche amministrazioni. inclusi gli importanti costi di istruzione del personale. Da più parti si è sentito dire che questo non è possibile, ed in effetti il concetto è controverso. L’origine di questa lettura ha sia una motivazione pratica di applicabilità, che un principio europeo, dal momento che il parere del Comitato Economico e Sociale della CE è che “attuare le linee guida sull'accessibilità comporta, e oltretutto solo nella fase iniziale, costi non di molto superiori a quelli che conseguirebbero alla loro mancata attuazione” come riportato nel documento economico3 correlato alla citata Comunicazione CE del 25 Settembre 2001. Questa disposizione ovviamente non richiede che non si debba spendere nulla per la realizzazione dell’accessibilità, quanto piuttosto che debbano essere impiegati gli stanziamenti ordinari già previsti in bilancio. In sostanza la legge prevede che quello che prima si spendeva per realizzare applicazioni e siti Web dallo scarso valore qualitativo, ora dovrà essere utilizzato per realizzare siti Web accessibili ed in grado di erogare servizi utili a tutti i cittadini. Purtroppo invece queste limitazioni previste dalla legge sono state prese sovente come ultima scappatoia per le pubbliche amministrazioni che non sono intenzionate a mettersi a norma. E’ una lettura pretestuosa della legge, e tuttavia l’esperienza reale e le opinioni raccolte sul campo hanno confermato come spesso si sia ricorso a questo pretesto per rinviarne all’infinito l’attuazione. 1 “I datori di lavoro pubblici provvedono all'attuazione nell'ambito delle disponibilità di bilancio.” “All’attuazione del presente articolo si provvede nell’ambito degli ordinari stanziamenti di bilancio, senza nuovi o maggiori oneri per la finanza pubblica.” 3 [http://eur-lex.europa.eu/LexUriServ/site/it/oj/2002/c_094/c_09420020418it00090013.pdf] 2 - 217 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR L’accessibilità come punto di partenza Un interessante e recente articolo in merito è stato pubblicato da Roberto Castaldo su WebAccessibile1. L’articolo ha il pregio di porre l’accento sulla giusta chiave di lettura del problema, cioè quella di considerare l’accessibilità non come un punto di arrivo da realizzare a costi nulli, ma come un punto di partenza verso la creazione di una migliore qualità generale dei siti della pubblica amministrazione e, di riflesso, anche del privato. Lo spirito della legislazione vuole spingere tutte le Pubbliche amministrazione verso l’erogazione di siti ed applicazioni Web di qualità. In quest’ottica l’aspetto legato all’accessibilità ed alla fruibilità dei contenuti è solamente uno degli elementi da prendere in considerazione; soprattutto alla luce di quanto poi richiesto anche dal Codice dell’Amministrazione Digitale che esige siti accessibili da tutti, anche dai disabili, ma anche reperibili, facilmente usabili, chiari nel linguaggio, affidabili, semplici, omogenei tra loro. Si tratta di un’idea di qualità che inizialmente non può prescindere dall’accessibilità tecnica che la legge Stanca richiede obbligatoriamente, ma che di certo non si esaurisce solo con essa. Il legislatore ha giustamente considerato l’accessibilità come una condizione necessaria per il conseguimento di un elevato livello qualitativo, ma non certo sufficiente, ed ha correttamente iniziato a spingere le pubbliche amministrazioni verso un approccio finalizzato agli utilizzatori. Creare un sito Web di qualità vuol dire pensare agli utenti, progettare e lavorare in team, scrivere codice, testare a più riprese il lavoro fatto, prevedere e gestire le questioni legate alla diffusione della conoscenza in azienda, concepire non solo i passi necessari all’implementazione pratica ma anche quelli legati alla formazione dei tecnici e dei redattori. Un’opera complessa per la quale servono professionisti in grado di affrontare problematiche quasi mai banali, altrimenti la qualità sarà sempre e soltanto un concetto astratto ed irrealizzabile. Può sembrare strano che questo concetto in cui accessibilità vuol dire qualità si leghi a quello del cosiddetto costo zero, ma in realtà tale associazione costringe ad una filosofia di fondo che ha proprio questo tipo di risultato. Costo zero E’ evidente che un processo del genere non può svolgersi senza il contributo di personale qualificato. Un intervento che non può essere privo di spese. 1 [http://www.webaccessibile.org/argomenti/argomento.asp?cat=622] - 218 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Ed infatti, con la disposizione di legge non si intende certo che l’accessibilità dei siti Web della Pubblica Amministrazione possa non costare nulla, dal momento che la costruzione di un sito anche a livello amatoriale comporta una spesa. La legge prevede bensì che le pubbliche amministrazioni debbano operare nell’ambito delle ordinarie disponibilità di bilancio. La realtà è che le pubbliche amministrazioni che già sono presenti in rete non partono certamente dal nulla, il loro bilancio già prevede un qualche stanziamento per il sito Web o per il settore informatico. Forse per le pubbliche amministrazioni che non hanno ancora un sito Web il problema degli stanziamenti da mettere in bilancio si potrebbe porre in maniera un po’ più urgente, ma anche qui è necessario fare chiarezza, con particolare riferimento al concetto di accessibilità e di qualità di un’applicazione Web. La pubblica amministrazione in Italia non può più permettersi di sperperare su progetti Web privi di valore, ed il legislatore con la legge Stanca 4/2004 ed il Codice per l’Amministrazione Digitale, vuole mettere in risalto proprio quest’aspetto, invitando, anzi obbligando, i dirigenti a spendere meglio i soldi che già hanno a disposizione. E’ un discorso che, come dipendente in un centro elaborazione dati comunale, mi sono trovato più volte ad affrontare con i responsabili del servizio, trovando di fronte notevoli chiusure e pregiudizi. La legge Stanca deve forzare la pubblica amministrazione ad affidarsi a professionisti affidabili e seri e ad ottimizzare gli stanziamenti ordinari, senza spendere altro di quanto non sia già oggi già impiegato, spesso male. A queste condizioni la migrazione a costo zero, cioè senza spendere poco o nulla in più di quanto si spenda oggi, verso applicazioni Web fruibili da parte di ogni cittadino è non solo moralmente auspicabile, ma anche finanziariamente non più rinviabile; è necessario che molti dirigenti smettano di nascondersi dietro l’impunità o la non conoscenza delle norme legislative che li riguardano direttamente come la legge 4/2004, e che imparino a spendere bene quello che hanno a disposizione. - 219 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR IV. Analisi delle normative In questa sezione entriamo nel dettaglio delle quattro normative di riferimento, rileggendole alla luce dei principi guida esposti nel capitolo precedente in cui è stato dato uno sguardo d’insieme alle metodologie generali. Va notato che le raccomandazioni WAI, in particolar modo le WCAG 1.0, sono specificatamente mirate a fornire le linee guida per una buona realizzazione dei siti Web, mentre, al contrario, sia la normativa americana che quella italiana sono molto più generiche ed ampliano il discorso fino ad includere anche la trattazione dei requisiti hardware e software per le persone disabili. Per quanto riguarda questa tesi, quindi, solamente un loro sottoinsieme verrà analizzato con particolare attenzione. Le normative sono riportate in ordine della loro prima pubblicazione. Per le WCAG 2.0, al momento, non esiste ancora una Recommendation definitiva del W3C. Si è scelto l’ultimo documento ufficiale, il Last Call Working Draft del 27 Aprile 2006. In fase di presentazione ho ritenuto opportuno far notare la loro cronologia, l’enfasi su quest’aspetto è dovuta alla possibilità di tracciare in questo modo un qualche sviluppo storico nella percezione e nell’importanza data nel tempo al problema dell’accessibilità. Al termine delle disamine segue un breve capitolo comparativo sulle funzionalità e sulle direttive richieste delle quattro normative esaminate. Conclude la sezione un breve accenno alle imminenti norme ISO e sulle altre direttive del WAI riguardanti ulteriori importanti aspetti dell’accessibilità. IV.1 - Normative internazionali Il motore iniziale del progetto di sensibilizzazione delle normative nazionali ed internazionali in tema di accessibilità dei siti Web è stato svolto sicuramente dalla pubblicazione delle WCAG 1.0 nel 1999. Sulla scorta di questa raccomandazione del W3C sono state svolte numerose attività legislative in cui l’Italia e gli Stati Uniti hanno primeggiato per efficienza e sensibilità. Negli Stati Uniti la "Section 508 of the Rehabilitation Act" del 07/08/2001 propone 16 punti che devono soddisfare i portali federali o con finanziamento pubblico finalizzati ad evitare la discriminazione verso le persone disabili. Di questa normativa parleremo diffusamente in seguito - 220 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR In Europa è stato dato un forte atto d’indirizzo con la Comunicazione della Commissione1 del 25 settembre 2001 denominata: “eEurope 2002: accessibilità e contenuto dei siti Internet delle amministrazioni pubbliche”. Come ricordato da Roberto Ellero2, in questa vengono riconosciute le WCAG 1.0 come norma mondiale de facto per la progettazione di siti Web accessibili, in oltre, al punto 5.2 si ricorda che: “Le pubbliche amministrazioni hanno il dovere di ricercare il costante perfezionamento delle proprie pagine Web e di esplorare metodi nuovi e migliori di fornire i contenuti e i servizi Internet man mano che vengono sviluppate nuove tecnologie e nuove versioni delle linee guida. L’adozione e l’attuazione delle linee guida per i siti delle amministrazioni pubbliche può dunque essere considerata un primo decisivo meccanismo in direzione di una società dell’informazione realmente fruibile da tutti.”. Per questi fini: “Il piano di azione eEurope 2002 vede nell’adozione delle linee guida una prima tappa verso l’accessibilità dei siti Web delle amministrazioni pubbliche europee e dei loro contenuti da parte dei disabili. Con esse gli Stati membri e le istituzioni europee daranno un chiaro segnale nei confronti dell’obiettivo dell’accessibilità di Internet, obiettivo da perseguire utilizzando quello che de facto è lo standard mondiale dell’accessibilità Web e che è rappresentato dai lavori dell’iniziativa WAI.”. Altrettanto interessante può essere considerata la successiva risoluzione del Parlamento Europeo sulla Comunicazione della Commissione "eEurope 2002: Accessibilità dei siti Web pubblici e dei loro contenuti" (COM(2001) 529 - C5-0074/2002 - 2002/2032(COS))3. In questo, e nei dispositivi correlati4 della Commissione Europea si auspica che la qualità raggiunta dai siti sia compatibile secondo il livello doppia A delle WAI WCAG. In effetti, al punto Q si ricorda che: ”I siti web delle pubbliche amministrazioni degli Stati membri e delle istituzioni europee e i relativi contenuti devono essere impostati in maniera tale da consentire ai disabili di accedere alle informazioni e di sfruttare al massimo le opportunità offerte dal sistema di amministrazione on-line.”. E, al punto 30: “sottolinea il fatto che, ai fini dell'accessibilità, è fondamentale che i siti web abbiano un livello di conformità "Doppia-A", ovvero che sia pienamente applicato il livello di Priorità 2 delle linee guida del WAI.”. 1 [http://europa.eu.int/eur-lex/it/com/cnc/2001/com2001_0529it01.pdf] Roberto Ellero: [http://www.robertoellero.it/milano/sia.html] 3 [http://www.europarl.europa.eu/registre/seance_pleniere/textes_adoptes/definitif/2002/0613/0325/P5_TA(2002)0325_IT.pdf] 4 Numero CELEX 52002IP0325: Risoluzione del Parlamento europeo sulla comunicazione della Commissione eEurope 2002: accessibilità e contenuto dei siti Internet delle amministrazioni pubbliche (COM(2001) 529 C5-0074/2002 - 2002/2032(COS)) Gazzetta ufficiale n. C 261 E del 30/10/2003 pag. 0582 - 0586 2 - 221 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR In queste raccomandazioni trova il suo principio fondante la legge italiana, come vedremo meglio in seguito. In Spagna, nello specifico, il 1 Gennaio 2006 è entrata è entrata in vigore la legge 34/2002, del 11 luglio, “Dei servizi della società dell'informazione e del commercio elettronico”. Nella sua quinta disposizione addizionale tratta appunto dell’accessibilità per le persone disabili e di età avanzata all'informazione fornita attraverso mezzi elettronici. Recentemente si è aggiunto anche il governo olandese con una legge che viene definita comunemente di buon livello qualitativo. Al momento non sono ancora riuscito ad accedere alla informazione in lingua inglese, segnalo comunque il sito1 per coloro che desiderassero approfondire l’informazione. Un elenco esaustivo e molto completo delle attività normative in sede internazionale è presente sul sito2 di WebAIM. Da segnalare in oltre anche due iniziative particolarmente feconde nel campo dell’accessibilità al di fuori delle normative nazionali e internazionali:  Siti culturali: Progetto Minerva, manuale per la qualità dei siti Web pubblici culturali, dove tra l’altro si possono recuperare i riferimenti a tutte le normative europee e nazionali3.  Siti Bancari: Progetto ABI - Linee Guida per l'accessibilità dei servizi di home banking4 In questa sede considereremo più approfonditamente le 4 normative più rilevanti in sede internazionale:  W3C WAI WCAG 1.0;  Rehabilitation Act, Section 508, paragrafo 1194.22;  Legge Stanca 4/2004 e relativo Decreto Ministeriale del 8 Luglio 2005;  W3C WAI WCAG 2.0. 1 [http://webrichtlijnen.overheid.nl/besluit/tekst-besluit-en-toelichting/] [http://www.webaim.org/articles/laws/world/] 3 [http://www.minervaeurope.org/publications/qualitycriteria-i/indice0402/appendicequattro0402.htm], [http://www.minervaeurope.org/publications/qualitycriteria1_2draft/appendix4.htm#2] 4 [http://www.webaccessibile.org/argomenti/argomento.asp?cat=420] 2 - 222 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR IV.2 - WCAG 1.0 (W3C WAI RECOMMENDATION - 5 MAGGIO 1999) Lo sviluppo delle WCAG 1.0 si fa risalire ad uno dei primi documenti sull’accessibilità: "Design of HTML (Mosaic) Pages to Increase their Accessibility to Users with Disabilities Strategies for Today and Tomorrow Version 1.0", che è stato redatto da Gregg Vanderheiden, per il Trace Research and Development Center1 nel Maggio del 1995. Come si può notare, la data risale a più di 10 anni fa. I successivi documenti sviluppati dal Trace Center sono poi stati la base per il progetto WAI del W3C avviatosi nel Gennaio del 1998 e sviluppatosi2 per un anno fino ad arrivare al 5 Maggio del 1999 alla pubblicazione come Recommendation del W3C delle linee guida dell’accessibilità per i contenuti Web, le Web Content Accessibility Guidelines (WCAG) versione 1.0. In questo momento sono ancora l’unico documento di riferimento ufficiale del consorzio in materia, e lo saranno fin quando le WCAG 2.0 in fase di Last Call Working Draft non diventeranno Recommendation ufficiale del W3C. Il documento3 si trova sul sito del gruppo WAI W3C ed in appendice ne ho riportato uno stralcio significativo in lingua originale. Un ulteriore documento4 di tecniche applicate illustra le modalità pratiche di attuazione delle direttive, fornendo esempi attraverso l'utilizzo di HTML (Hypertext Markup Language), CSS (Cascading Style Sheets), SMIL (Synchronized Multimedia Integration Language), MathML (Mathematical Markup Language), descrive inoltre tecniche per la validazione e la valutazione dei documenti, e comprende l'indice degli elementi e attributi HTML. Per le WCAG 1.0 numerose traduzioni sono disponibili in rete, quella ufficiale 5 si trova sul sito dell’ufficio italiano del W3C. Introduzione Come ricordato da Roberto Ellero1: le WCAG sono il tentativo di costituire una metodologia per tradurre in un linguaggio uniforme e generale l’essenziale necessità di consentire a tutti l’accesso all’informazione. 1 2 3 4 5 [http://trace.wisc.edu/] [http://www.w3.org/WAI/group/GL/wai-gl-wd-changes.html] [http://www.w3.org/TR/WCAG10/] [http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/] [http://www.w3c.it/traduzioni/] - 223 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR A questo proposito, nel dispositivo introduttivo le WCAG richiamano quali siano le categorie interessate tra cui: gli utenti affetti da qualche forma di disabilità sensoriale motoria o cognitiva, coloro che non dispongono di una tastiera o di un mouse, coloro che hanno connessioni internet molto lente, schermi solo testuali o ridotti, browser testuali, screen-reader ad altri tipi particolari di programmi utente. Solo le tipologie di utenza che presente nella sezione delle metodologie generali a cui rimando per una discussione in merito. La filosofia di fondo del progetto WCAG 1.0 è basata su due finalità:  Garantire una trasformazione appropriata2. Questi punti sono sviluppati principalmente nelle linee guida dalla 1 alla 11. Seguendo queste linee guida gli sviluppatori possono creare delle pagine che rimangano accessibili nonostante le limitazioni considerate in precedenza, questo grazie ad alcuni punti chiave che garantiscano delle conversioni appropriate dei contenuti: o Separare la struttura dalla presentazione; o Predisporre dei testi, inclusi gli equivalenti testuali. I testi possono essere resi con modalità accessibile per quasi tutti gli utenti; o Creare dei documenti che funzionino, anche se gli utilizzatori possono non sentire o non vedere; o Creare dei documenti che non facciano affidamento ad un unico tipo di hardware, le pagine dovrebbero essere utilizzabili da utenti senza mouse, con schermi piccoli, basse risoluzioni o addirittura senza schermo;  Rendere il contenuto comprensibile e navigabile 3. Queste linee guida sono sviluppate principalmente dalla 12 alla 14. Gli utenti possono rimanere disorientati quando possono vedere una sola porzione della pagina e senza elementi di orientamento potrebbero non essere capaci di comprendere i contenuti. Questo principio riguarda: o Rendere chiaro e semplice il linguaggio; o Fornire meccanismi comprensibili che siano di ausilio alla navigazione. Organizzazione e conformità Le WCAG 1.0 sono organizzate in 14 linee guida, definite come principi generali della progettazione accessibile. 1 2 3 [http://www.webaccessibile.org/argomenti/argomento.asp?cat=368] “Ensuring Graceful Transformation” “Making Content Understandable and Navigable” - 224 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Ogni linea guida ha un suo numero, un suo enunciato, una breve spiegazione e un elenco di punti di controllo. Il citato documento di tecniche chiarisce ulteriormente la prassi di attuazione del relativo punto di controllo. I punti di controllo hanno il compito di spiegare come applicare l’enunciato ed hanno attribuita una priorità progressiva da 1 a 3:  Priorità 1: Il progettista deve (must) soddisfare questo punto di controllo. In caso contrario uno o più tipologie di utenti troveranno impossibile accedere alle informazioni;  Priorità 2: Il progettista dovrebbe (should) soddisfare questo punto di controllo. In caso contrario uno o più tipologie di utenti troveranno difficile accedere alle informazioni;  Priorità 1: Il progettista può (may) soddisfare questo punto di controllo. In caso contrario uno o più tipologie di utenti troveranno in qualche modo difficile accedere alle informazioni. Le WCAG 1.0 contano 14 linee guida ripartite in 65 punti di controllo. Di queste 16 sono di priorità 1, 30 sono di priorità 2 e 19 sono di priorità 3. A seguito del soddisfacimento di uno o più di questi punti di controllo le WCAG definiscono tre livelli di conformità:  Conformità a livello A: tutti i punti di controllo di priorità 1 sono soddisfatti;  Conformità a livello Doppia-A: tutti i punti di controllo di priorità 1 e 2 sono soddisfatti;  Conformità a livello Tripla-A: tutti i punti di controllo di priorità 1, 2 e 3 sono soddisfatti. Il livello di conformità viene definito in modo esteso (tripla-A e non AAA) così che possa essere compresi quando vengono resi dagli screen-reader. La presentazione della dichiarazione di conformità sui siti è consentita in forma testuale ed in forma grafica, aggiungendo un opportuno logo del W3C. Va ricordato che non è possibile convalidare automaticamente una dichiarazione di conformità neppure a livello A delle WCAG 1.0, questo in quanto molti punti di controllo delle linee guida richiedono esplicitamente una verifica tecnica da parte umana. La presenza di un’icona di conformità non implica che il W3C abbia controllato e validato la pagina, essendo questa dichiarazione di esclusiva responsabilità di chi la espone. - 225 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Coloro che forniscono i contenuti sono i soli responsabili dell’utilizzo del logo 1. Linee guida e punti di controllo Vediamo adesso una breve esposizione ragionata delle 14 linee guida associate con i loro relativi punti di controllo. Le linee guida sono le seguenti: 1. Fornire alternative equivalenti per il contenuto audio e visivo; 2. Non affidarsi unicamente al colore; 3. Usare le marcature ed i fogli di stile in modo appropriato; 4. Rendere chiaro l'uso del linguaggio naturale; 5. Creare tabelle che si trasformino in maniera gradevole; 6. Garantire che le pagine che utilizzano tecnologie più recenti si trasformino in maniera gradevole; 7. Garantire che l'utente possa controllare i cambiamenti del contenuto durante la loro rappresentazione; 8. Garantire l'accessibilità diretta delle interfacce utente incorporate; 9. Progettare garantendo l'indipendenza dal dispositivo; 10. Usare soluzioni temporanee; 11. Usare le tecnologie e le linee guida del W3C; 12. Fornire informazioni per il contesto e l'orientamento; 13. Fornire chiari meccanismi di navigazione; 14. Garantire che i documenti siano chiari e semplici. Tratteremo ora più in dettaglio le singole direttive. Le spiegazioni seguenti riguardano specificatamente i contenuti delle WCAG o qualche informazione aggiuntiva specifica, in quanto i principi generali sono già stati esposti nella sezione delle metodologie a cui si fa esplicito rimando per informazioni più esaustive sugli argomenti specifici. Linea guida 1: fornire alternative equivalenti per il contenuto audio e visivo Fornire un contenuto che, quando viene presentato all'utente, gli trasmetta essenzialmente la stessa funzione o scopo del contenuto audio o visivo. 1 “Content providers are solely responsible for the use of these logos.” - [http://www.w3.org/WAI/WCAG1Conformance.html] - 226 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR La fruizione di immagini, filmati, suoni, applet ed altri contenuti non esclusivamente testuali potrebbe essere impossibile per utenti disabili o che non abbiano a disposizione le normali tecnologie. E’ possibile garantire un accesso ai contenuti se questi includono una informazione equivalente che abbia la stessa funzione del contenuto audio o video che sostituisce. Viene rimarcata l’importanza di fornire un contenuto testuale alternativo come alternativa per un contenuto non testuale. L’utilità degli equivalenti testuali è stata discussa nella sezione relativa e consiste nella possibilità di essere facilmente indirizzato anche a tecnologie diverse, in particolare:  Display Braille, essenziale per sordo-ciechi;  Sintesi vocale, tramite screen-reader, fondamentale per persone non vedenti o disabili cognitivi: Gli oggetti coinvolti da questa linea guida sono immagini, mappe immagini, applet e oggetti tra cui Macromedia Flash, i frame, i pulsanti, gli script, arte ASCII ed altri oggetti grafici. Per molte di queste componenti è spesso un buon punto di inizio dotarle di un attributo ALT con un testo alternativo. Da notare che la linea guida non richiede esclusivamente equivalenti testuali, a volte è utile fornire anche equivalenti non testuali del testo scritto, come ad esempio immagini, video o tracce audio pre-registrate a beneficio di utenti illetterati, disabili cognitivi o per persone che hanno difficoltà nella lettura. Lo stesso principio si applica anche ai filmati multimediali richiedendone, allo stesso tempo, anche la sincronizzazione. Questa linea guida è formata da cinque punti di controllo, di seguito riportati, che comprendono quattro punti di controllo per la priorità 1 e uno per la priorità 3:  Punto di controllo 1.1: Fornire un equivalente testuale per ogni elemento non di testo. [Priorità 1];  Punto di controllo 1.2: Fornire collegamenti di testo ridondanti per ogni zona attiva di una mappa immagine sul lato server (server-side). [Priorità 1];  Punto di controllo 1.3: Fino a quando i programmi utente non potranno leggere automaticamente ad alta voce il suo equivalente testuale fornire una descrizione audio delle informazioni essenziali del filmato di una presentazione multimediale. [Priorità 1];  Punto di controllo 1.4: Per ogni presentazione multimediale temporizzata, sincronizzare le alternative equivalenti con la presentazione. [Priorità 1];  Punto di controllo 1.5: Fino a quando i programmi utente non renderanno disponibili equivalenti testuali per collegamenti di mappe immagine sul lato client, fornire collegamenti di testo ridondanti per ogni zona attiva nella mappa immagine sul lato client (client side). [Priorità 3]. - 227 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Linea guida 2: non affidarsi unicamente al colore Assicurarsi che il testo e la parte grafica siano comprensibili se consultati senza il colore. Il colore viene usato in maniera intensiva sul Web, per abbellire l’aspetto estetico e spesso veicola anche un contenuto informativo, questo può rendere difficoltosa la fruizione da parte di persone parzialmente o totalmente cieche ai colori (protanopia, deutranopia, tritanopia). L’uso delle corrette combinazioni cromatiche è indicato in un capitolo apposito delle metodologie così come la descrizione delle cecità ai colori sono riportate fra le descrizioni delle disabilità. Una seria critica che è stata mossa da più parti1 al punto di controllo 2.2 è che abbia priorità 3 per il testo. In realtà l’impiego di contrasti sufficienti per i testi è un requisito almeno di pari importanza rispetto al contrasto di colore per le immagini. Come fatto notare nel capitolo dedicato le WCAG 2.0 equiparano i due concetti e definiscono nuovi algoritmi di valutazione di contrasto. Per il momento, per quanto le WCAG 1.0 siano ancora il testo ufficiale di riferimento del consorzio, si suggerisce di dare maggiore attenzione a quest’aspetto di quanto non abbia fatto, almeno formalmente, il W3C. Questa linea guida comprende punti di controllo a tutti i tre livelli di accessibilità:  Punto di controllo 2.1: Garantire che tutta l'informazione veicolata dal colore sia disponibile anche in assenza di colori. [Priorità 1];  Punto di controllo 2.2: Garantire che le combinazioni di colori tra il primo piano e lo sfondo forniscano un sufficiente contrasto se osservati da qualcuno con deficit percettivi del colore o quando visualizzati su un monitor in bianco e nero. [Priorità 2 per immagini - Priorità 3 per il testo]. Linea guida 3: usare le marcature ed i fogli di stile in modo appropriato Marcare i documenti con i corretti elementi strutturali. Controllare la presentazione con fogli di stile piuttosto che con elementi e attributi di presentazione. Questa linea guida è fondamentale per la corretta metodologia in quanto introduce i due temi cardine: 1  Separazione tra contenuto e presentazione;  Utilizzo semanticamente corretto degli elementi strutturali. Michele Diodati: [http://www.diodati.org/scritti/2004/guida/ele_acc16.asp] - 228 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR In effetti, usare una sintassi in maniera scorretta non permette la formattazione di un documento adeguato per tutti i programmi utente impedendo la fruizione da parte di alcune categorie di visitatori. Tra i cattivi usi dei marcatori si ricordano ad esempio l’uso improprio di tabelle d’impaginazione, l’utilizzo di elementi di citazione o di intestazione per presentazioni grafiche, il mancato uso dei fogli di stile, eccetera. I punti di controllo di questa linea guida sono 7, tutti di livello 2, ma molti di importanza centrale:  Punto di controllo 3.1: Quando esiste un linguaggio di marcatura adatto, per veicolare informazione usare un marcatore piuttosto che le immagini. [Priorità 2];  Punto di controllo 3.2: Creare documenti che rispettino le grammatiche formali. [Priorità 2];  Punto di controllo 3.3: Usare i fogli di stile per controllare l'impaginazione e la presentazione. [Priorità 2];  Punto di controllo 3.4: Usare unità di misura relative anziché assolute nei valori degli attributi del linguaggio di marcatura e per i valori delle proprietà del foglio di stile. [Priorità 2];  Punto di controllo 3.5: Usare elementi di intestazione per veicolare la struttura del documento e usarli in modo conforme alle specifiche. [Priorità 2];  Punto di controllo 3.6: Marcare le liste ed elencare le voci della lista in modo appropriato. [Priorità 2];  Punto di controllo 3.7: Marcare le citazioni. [Priorità 2]. Linea guida 4: rendere chiaro l'uso del linguaggio naturale Utilizzare marcatori che facilitino la pronuncia o l'interpretazione di testi stranieri o abbreviati. La definizione di una lingua per la pagina è utile per i motori di ricerca e per gli screen-reader che devono caricare gli opportuni dizionari di pronuncia. Per questo motivo è altrettanto necessario marcare gli eventuali cambiamenti che si presentino in citazioni o paragrafi all’interno del testo. Come accennato nella sezione specifica, questo passaggio comportava del dispendio di risorse e di tempo nelle versioni precedenti degli screen-reader più comuni come JAWS, per fortuna recentemente si è assistito ad un notevole miglioramento dell’efficienza di questi prodotti. L’utilizzo di acronimi e abbreviazioni in oltre favorisce la comprensione del testo e delle sigle anche per gli utenti normodotati, consuetudine sempre più presente nei siti attuali. Un punto di discussione è quello se la marcatura degli acronimi e delle abbreviazioni debba essere connotata solo la prima volta o per tutte le occorrenze del testo nella pagina. Ci sono 3 punti di controllo per questa linea guida: - 229 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Punto di controllo 4.1: Identificare con chiarezza i cambiamenti nel linguaggio naturale del testo di un documento e in ogni equivalente testuale. [Priorità 1];  Punto di controllo 4.2: Specificare il significato di ogni abbreviazione o acronimo nel documento laddove compaia per la prima volta. [Priorità 3];  Punto di controllo 4.3: Identificare il linguaggio naturale principale di un documento. [Priorità 3]. Linea guida 5: creare tabelle che si trasformino In maniera gradevole Assicurarsi che le tabelle abbiano la marcatura necessaria per essere trasformate dai browser accessibili e da altri interpreti. Il problema delle tabelle è stato molto sentito dagli autori e dagli studiosi dell’accessibilità. Un capitolo è stato dedicato nelle metodologie generali di questo lavoro distinguendo fra le tabelle create al fine di contenere puramente i dati e quelle invece progettate per l’impaginazione e la grafica del documento. Come fatto notare in quella sede, né le WCAG 1.0 né le WCAG 2.0 vietano l’uso delle tabelle d’impaginazione. La tendenza però è quella di sostituire con l’uso dei fogli di stile e dei DIV all’interno del codice (X)HTML, soprattutto se non possono essere correttamente linearizzate. L’uso delle tabelle di impaginazione è consentito solo previo rispetto dei punti di controllo di questa linea guida. Questi punti di controllo sono soprattutto a beneficio degli utenti che accedono al sito tramite tecnologie assistive come screen-reader o persone che riescono ad accedere a sezioni limitate della pagina. Quindi il mancato rispetto di questi punti inibisce un accesso fruibile non solo agli utenti disabili. I punti di controllo sono 6, inerenti sia alle tabelle dati che alle tabelle di impaginazione:  Punto di controllo 5.1: Per le tabelle dati, identificare le intestazioni per righe e colonne. [Priorità 1];  Punto di controllo 5.2: Per le tabelle dati che hanno due o più livelli logici di intestazioni di righe o colonne, usare marcatori per associare le celle di dati e le celle di intestazione. [Priorità 1];  Punto di controllo 5.3: Non usare le tabelle di impaginazione a meno che la tabella non sia comprensibile se linearizzata. [Priorità 2];  Punto di controllo 5.4: Se si utilizza una tabella di impaginazione non utilizzare alcun marcatore di struttura a scopo di formattazione. [Priorità 2];  Punto di controllo 5.5: Per ogni tabella definire un sommario dei contenuti. [Priorità 3];  Punto di controllo 5.6: Fornire abbreviazioni per le etichette di intestazione. [Priorità 3]. - 230 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Linea guida 6: garantire che le pagine che utilizzano tecnologie più recenti si trasformino in maniera gradevole Assicurarsi che le pagine siano accessibili anche quando le tecnologie più recenti non sono supportate o sono disabilitate. Il problema che vuole affrontare questa linea guida è quello della retro-compatibilità. Come detto nella sezione dedicata, si tratta di favorire lo sviluppo delle nuove tecnologie senza penalizzare gli utenti che dispongano di programmi utente non recenti. Il compromesso si può raggiungere progettando un contenuto valido che garantisca l’accesso anche con browser relativamente datati e connessioni a bassa velocità, che sia navigabile anche senza l’impiego di applet o plug-in specializzati. Per quanto vada sicuramente previsto un criterio progettuale di compatibilità, è inutile andare a cercare soluzioni estreme cercando di risolvere malfunzionamenti di browser realmente obsoleti come Netscape 4 con soluzioni ad hoc che spesso finiscono per appesantire e rendere realmente inaccessibile la pagina. I 5 punti di controllo di questa guida hanno una significativa priorità:  Punto di controllo 6.1: Organizzare i documenti in modo che possano essere letti anche in assenza dei fogli di stile. [Priorità 1];  Punto di controllo 6.2: Garantire che all'aggiornamento dei contenuti dinamici vengano aggiornati anche i contenuti equivalenti. [Priorità 1];  Punto di controllo 6.3: Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati. Se questo non è possibile, fornire informazione equivalente in una pagina accessibile alternativa. [Priorità 1];  Punto di controllo 6.4: Garantire che i gestori di eventi per gli script e le applet siano indipendenti dai dispositivi di input. [Priorità 2];  Punto di controllo 6.5: Garantire che il contenuto dinamico sia accessibile oppure fornire una presentazione o una pagina alternativa. [Priorità 2]. Linea guida 7: garantire che l'utente possa controllare i cambiamenti del contenuto durante la loro rappresentazione Assicurarsi che gli oggetti in movimento, lampeggianti, scorrevoli o che si autoaggiornano possano essere arrestati temporaneamente o definitivamente. Le disabilità visive o cognitive impediscono di accedere al testo scorrevole o lampeggiante a causa della distrazione o della difficoltà di lettura che esso comporta. Anche gli screen-reader possono avere delle difficoltà ad accedere a questi contenuti. In oltre una forte attenzione va posta per gli utenti soggetti ad attacchi di epilessia fotosensibile. Costoro possono incorrere in delle crisi per la visione di questi contenuti se i medesimi hanno delle frequenze particolari. - 231 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Per questo i punti di controllo di questa linea guida hanno una significativa priorità:  Punto di controllo 7.1: Fino a quando i programmi utente non permetteranno agli utenti di controllare lo sfarfallio, evitare di far sfarfallare lo schermo. [Priorità 1];  Punto di controllo 7.2: Fino a quando i programmi utente non permetteranno agli utenti di controllare il lampeggiamento, evitare di far lampeggiare il contenuto. [Priorità 2];  Punto di controllo 7.3: Fino a quando i programmi utente non permetteranno agli utenti di bloccare il contenuto in movimento, evitare il movimento nelle pagine. [Priorità 2];  Punto di controllo 7.4: Fino a quando i programmi utente non forniranno la possibilità di bloccare l'auto-aggiornamento, non creare pagine che si auto-aggiornano periodicamente. [Priorità 2];  Punto di controllo 7.5: Fino a quando i programmi utente non forniranno la capacità di bloccare l'auto-reindirizzamento, non usare marcature per reindirizzare le pagine automaticamente. Piuttosto, configurare il server in modo che esegua i reindirizzamenti. [Priorità 2]. Linea guida 8: garantire l'accessibilità diretta delle interfacce utente incorporate Assicurarsi che la progettazione delle interfacce utente segua i principi dell'accessibilità: accesso alle diverse funzionalità indipendente dai dispositivi usati, possibilità di operare da tastiera, comandi vocali, ecc. Si tratta di dare un’accessibilità agli oggetti nella pagina Web che siano dotati di interfaccia utente. Ogni interfaccia incorporata deve rispettare i principi di una progettazione accessibile, come ad esempio l’indipendenza dal dispositivo di accesso che deve essere garantita anche per periferiche differenti come ad esempio la tastiera o comandi vocali. Se l’interfaccia non può essere resa accessibile, allora deve essere predisposta una soluzione alternativa che sia accessibile. Nello stesso testo delle WCAG viene consigliato di fare riferimento alle UAAG e alle ATAG per avere informazioni sul concetto di interfaccia accessibile. Il punto di controllo è unico e di priorità elevata:  Punto di controllo 8.1: Fare in modo che elementi di programmi come script e applet siano direttamente accessibili o compatibili con le tecnologie assistive. [Priorità 1 (se importante) o 2]. Linea guida 9: progettare garantendo l'indipendenza dal dispositivo Usare caratteristiche che permettono di attivare gli elementi della pagina attraverso una molteplicità di dispositivi di input. L’indipendenza del dispositivo di accesso non riguarda solamente gli oggetti esterni incorporati dotati di una propria interfaccia, ma in genere deve essere estesa a tutte le funzionalità del sito tenendo presente il fatto che i visitatori possono usare potenzialmente diversi periferiche - 232 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR di ingresso. Al fine di garantire un accesso indipendente dal dispositivo è necessario progettare le pagine in modo che qualsiasi dispositivo ne garantisca la fruibilità. Non si possono produrre delle pagine che interagiscano esclusivamente tramite eventi del mouse. In genere le pagine che garantiscono un accesso tramite tastiera sono accessibili anche con comandi vocali o altre interfacce che simulino la pressione dei tasti. I punti di controllo di questa linea guida coprono tutte le priorità:  Punto di controllo 9.1: Fornire mappe immagine sul lato client invece di mappe immagine sul lato server, con l'eccezione dei casi nei quali le zone non possono essere definite con una forma geometrica valida. [Priorità 1];  Punto di controllo 9.2: Garantire che ogni elemento dotato di una sua specifica interfaccia possa essere gestito in una modalità indipendente dal dispositivo. [Priorità 2];  Punto di controllo 9.3: Negli script, specificare gestori di evento logici piuttosto che gestori di evento dipendenti dal dispositivo. [Priorità 2];  Punto di controllo 9.4: Creare un ordine logico di tabulazione fra i collegamenti, i controlli dei moduli e gli oggetti. [Priorità 3];  Punto di controllo 9.5: Fornire scorciatoie da tastiera per i collegamenti importanti (compresi quelli nelle mappe immagine lato client), per i controlli dei moduli e per i gruppi di controlli dei moduli. [Priorità 3]. Linea guida 10: usare soluzioni temporanee Usare soluzioni provvisorie in modo che le tecnologie assistive e i browser più vecchi possano operare correttamente Per quanto le WCAG fossero state progettate nel 1999, già allora era evidente che le tecnologie dei programmi utente erano in costante sviluppo. Per questo molte parti delle linee guida contengono la dicitura fino a quando i programmi utente1. Questo per il fatto che al momento della pubblicazione del documento non tutti i programmi utente o le tecnologie assistive garantivano le funzionalità richieste per l’accessibilità. In tal caso le linee guida richiedono che siano gli stessi sviluppatori a farsi carico di questi bisogni fin quando la maggior parte dei programmi utente non includeranno queste caratteristiche al loro interno. Ad esempio i browser più datati non consentivano di raggiungere i campi di un modulo se questi erano vuoti, oppure leggevano liste consecutive di collegamenti ipertestuali come se fossero un solo collegamento. 1 “until user agent” – [http://www.w3.org/TR/WCAG10/#until-user-agents] - 233 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Le disposizioni contenute in questa linea guida sono quindi considerate provvisorie ed il W3C non ritiene che rimangano necessarie in futuro, quando i programmi utente avranno integrato le funzionalità richieste. In effetti, allo stato attuale delle cose alcuni di questi suggerimenti sono realmente diventati obsoleti. Tra tutti, quello relativo al punto di controllo 10.4 sui controlli vuoti. Attualmente questa disposizione non solo è inutile ma finisce anche per confondere gli utenti che spesso finiscono per non cancellare tutto il testo segnaposto inserito e per inviarlo insieme ai agli altri valori del modulo. Il punto di controllo 10.1 invece ha avuto le sue conferme, sia nella sintassi del linguaggio XHTML 1.1 che ha eliminato gli attributi necessari per aprire nuove finestre nei collegamenti ipertestuali, sia nelle WCAG 2.0 che hanno riconfermato la validità del principio alla linea guida 3.2, imponendo che sia esplicitamente l’utente a richiedere il cambiamento di contesto. Il punto di controllo 10.2 non dovrebbe invece essere applicabile poiché sono fortemente raccomandate le associazioni esplicite delle etichette. I punti di controllo per questa linea guida sono 5:  Punto di controllo 10.1: Fino a quando i programmi utente non permetteranno agli utenti di bloccare l'apertura di nuove finestre, non fare apparire pop-up o finestre di altro tipo e non cambiare la finestra attiva senza informare l'utente. [Priorità 2];  Punto di controllo 10.2: Fino a quando i programmi utente non supporteranno esplicite associazioni fra etichette e controlli dei moduli, garantire che l'etichetta sia posizionata correttamente per tutti i controlli dei moduli che hanno etichette associate implicitamente. [Priorità 2];  Punto di controllo 10.3: Fino a quando i programmi utente (comprese le tecnologie assistive) non rappresenteranno in modo corretto il testo affiancato, fornire un testo lineare alternativo (nella pagina attiva o in altra pagina) per tutte le tabelle che dispongono testo su colonne parallele e andando a capo. [Priorità 3];  Punto di controllo 10.4: Fino a quando i programmi utente non gestiranno in maniera corretta i controlli vuoti, inserire caratteri predefiniti come segnaposto nelle caselle per l'immissione di testo a una o a più righe. [Priorità 3];  Punto di controllo 10.5: Fino a quando i programmi utente (comprese le tecnologie assistive) non rappresenteranno in modo distinto collegamenti adiacenti, inserire caratteri stampabili (delimitati da spazi), non facenti parte dei collegamenti, per separare i collegamenti adiacenti. [Priorità 3]. Linea guida 11: usare le tecnologie e le linee guida del W3C Usare le tecnologie del W3C (in conformità con le specifiche) e seguire le raccomandazioni sull'accessibilità. Nei casi in cui non sia possibile usare una tecnologia - 234 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR del W3C, oppure se nell'utilizzarla si ottenesse materiale che non si trasforma in maniera elegante, fornire una versione alternativa del contenuto che sia accessibile Il W3C ha promosso le WCAG 1.0 nel 1999 mirandole espressamente al mondo (X)HTML e tecnologie inerenti come ad esempio i CSS e i moduli XML. Per quanto questo mondo sia in effetti uno dei migliori ambiti in cui sviluppare contenuti accessibili, tuttavia non è possibile non considerare nelle raccomandazioni dell’accessibilità anche le altre tecniche. Questa è proprio una delle missioni critiche delle WCAG 2.0 che si sono assunte l’onere di offrire delle direttive che siano indipendenti dalla piattaforma di sviluppo. Nelle WCAG 1.0 tuttavia sono fortemente raccomandate le tecnologie sviluppate dal W3C. In effetti, queste tecnologie godono di significativi vantaggi:  I riferimenti delle WCAG 1.0 sono espliciti ed applicabili direttamente come indicato nel documento di tecniche accluso;  Le tecnologie sono sviluppate, sin dal progetto iniziale, per integrare gli elementi di accessibilità necessari;  Sono frutto di un processo aperto comune che ha raggiunto una vasta base consensuale da parte delle maggiori industrie del settore. Tuttavia il mondo esterno non può rimanere ignorato, tra questi strumenti si trovano dei formati oramai comuni, come ad esempio PDF o Flash che richiedono l’uso di lettori di formati proprietari e di plug-in. Altra cosa sarà poi garantire che i contenuti in se stessi siano accessibili, ad esempio facendo esplicito riferimento alle direttive per l’accessibilità proposte dai produttori di questi formati proprietari. Ad ogni modo, anche se per le WCAG 1.0 queste tecnologie non sono proibite, si tratta di evitare quelle che sono espressamente disapprovate o di fornire dei contenuti alternativi accessibili nel caso che non lo fossero gli originali:  Punto di controllo 11.1: Utilizzare le tecnologie W3C quando sono disponibili e sono appropriate per un certo compito usando le versioni più recenti quando sono supportate dai programmi utente. [Priorità 2];  Punto di controllo 11.2: Evitare l'utilizzo di caratteristiche disapprovate dal W3C. [Priorità 2];  Punto di controllo 11.3: Fornire agli utenti l'informazione necessaria perché possano ricevere i documenti in modo che si adattino alle loro preferenze (per lingua, per tipo di contenuto, ecc.). [Priorità 3];  Punto di controllo 11.4: Se, nonostante ogni sforzo, non è possibile creare una pagina accessibile, fornire un collegamento a una pagina alternativa che si riferisca alle tecnologie W3C, che sia accessibile, che contenga informazioni (o funzionalità) equivalenti e sia aggiornata con la stessa frequenza della pagina originale inaccessibile. [Priorità 1]. - 235 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Linea guida 12: fornire informazioni per il contesto e l'orientamento Fornire informazione per la contestualizzazione e l'orientamento, per aiutare gli utenti a comprendere pagine od elementi complessi. Con la linea guida 12 si passa a considerare la seconda finalità delle WCAG 1.0, cioè quella di rendere il contenuto comprensibile e navigabile. In questo caso si raccomanda fornire degli strumenti per chiarificare il contesto e l’orientamento. Raggruppare gli elementi, fornire informazioni sul contesto e chiarire le relazioni fra gli elementi di una pagina aiuta gli utenti ad orientarsi. Le relazioni tra le parti di una pagina possono essere difficoltose da comprendere soprattutto per utenti che non utilizzano browser grafici per la navigazione o per utenti affetti da disabilità cognitive. Le raccomandazioni che riguardano i frame sono in parte obsolete, per la attuale tendenza ad eliminare questo strumento dalle pagine Web. Anche per questo i punti di controllo di questa linea guida hanno priorità significativa:  Punto di controllo 12.1: Assegnare un titolo a ogni frame per facilitarne l'identificazione e la navigazione. [Priorità 1];  Punto di controllo 12.2: Descrivere lo scopo dei frame e il modo in cui questi interagiscono se non è evidente solo tramite i titoli dei frame. [Priorità 2];  Punto di controllo 12.3: Dividere i grandi blocchi di informazione in gruppi più maneggevoli quando è naturale ed appropriato. [Priorità 2];  Punto di controllo 12.4: Associare esplicitamente le etichette ai loro controlli. [Priorità 2]. Linea guida 13: fornire chiari meccanismi di navigazione Fornire chiari e coerenti meccanismi di navigazione -- informazione per l'orientamento, barre di navigazione, una mappa del sito, ecc. -- per aumentare le probabilità che una persona trovi quello che sta cercando in un sito Accanto alla necessità di raggruppare e contestualizzare gli elementi omogenei come indicato al punto precedente, un altro strumento essenziale è quello di integrare dei meccanismi di navigazione chiari e coerenti. Questa è una funzionalità utile non solamente per le persone con invalidità cognitive o per non vendenti, ma giova in genere a tutti gli utenti fornire dei punti di riferimento utili. I suggerimenti esposti coprono diverse tecniche e sono tutti di una certa utilità per raggiungere una maggiore chiarezza nella navigazione. Gli argomenti sono stati specificatamente trattati nella sezione delle metodologie generali.  Punto di controllo 13.1: Identificare con chiarezza la destinazione di ogni collegamento. [Priorità 2]; - 236 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Punto di controllo 13.2: Fornire metadati per aggiungere alle pagine ed ai siti informazioni di tipo semantico. [Priorità 2];  Punto di controllo 13.3: Fornire informazioni sulla configurazione generale di un sito (per esempio, una mappa oppure un indice dei contenuti). [Priorità 2];  Punto di controllo 13.4: Usare meccanismi di navigazione in modo coerente. [Priorità 2];  Punto di controllo 13.5: Fornire barre di navigazione per evidenziare e dare accesso ai meccanismi di navigazione. [Priorità 3];  Punto di controllo 13.6: Raggruppare i collegamenti correlati, identificare i gruppi (per i programmi utente) e, fino a quando i programmi utente non lo consentiranno, fornire un modo per saltare il gruppo. [Priorità 3];  Punto di controllo 13.7: Se sono fornite funzionalità di ricerca, rendere possibili diversi tipi di ricerca per differenti livelli di abilità e per preferenze differenti. [Priorità 3];  Punto di controllo 13.8: Posizionare l'informazione più significativa all'inizio delle intestazioni, dei paragrafi, delle liste, ecc. [Priorità 3];  Punto di controllo 13.9: Fornire informazioni sulle raccolte di documenti, ossia documenti composti da più pagine. [Priorità 3];  Punto di controllo 13.10: Fornire un mezzo per saltare i contenuti ASCII multilinea (ASCII Art). [Priorità 3]. Linea guida 14: garantire che i documenti siano chiari e semplici Assicurarsi che i documenti siano chiari e semplici in modo che possano essere compresi più facilmente Questo è uno dei punti più discussi e citati delle WCAG. L’uso di un linguaggio chiaro e semplice viene spesso ignorato soprattutto dai siti più squisitamente amministrativi o tecnici. La richiesta di produrre dei contenuti che siano comprensibili riguarda anche quei settori, come ad esempio quello della pubblica amministrazione, dove queste modalità espressive sono spesso sotto considerate. Nello sviluppare un sito Web un autore è spesso scoraggiato, per motivi di tempo e di costi, a dedicare la cura dovuta al linguaggio e alle scelte lessicali e grammaticali dei suoi documenti. In realtà una disposizione coerente della pagina, una grafica riconoscibile, un linguaggio comprensibile e ben definito aiutano tutti gli utenti ed in particolar modo quelli affetti da parziali disabilità cognitive nella comprensione dei contenuti, come chiarito nella sezione Metodologie. Come fatto più volte notare, il punto di controllo 14.1 è di priorità 1. Quindi una pagina che non utilizzi il linguaggio più chiaro e semplice possibile in relazione ai contenuti del sito non può dichiarare di aver neppure raggiunto il livello A di conformità. - 237 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Altro punto da mettere in luce è che ben difficilmente i valutatori automatici possono controllare il soddisfacimento di questo punto di controllo. Per quanto ci si possa avvalere di significativi strumenti di analisi lessicale del testo, risulterà comunque impossibile validarne pienamente il contenuto. Un’ulteriore prova per ribadire che, allo stato attuale delle cose, nessun validatore automatico può testimoniare il raggiungimento di un sufficiente grado di accessibilità di un qualunque sito senza l’intervento di un consulente umano. Questa linea guida è articolata in 3 punti di controllo:  Punto di controllo 14.1: Utilizzare un linguaggio più chiaro e semplice possibile che sia adatto al contenuto del sito. [Priorità 1];  Punto di controllo 14.2: Integrare il testo con presentazioni visive o audio nei casi in cui possano facilitare la comprensione della pagina. [Priorità 3];  Punto di controllo 14.3: Creare uno stile di presentazione coerente fra le pagine. [Priorità 3]. Critiche ed attuazione Al momento in cui sono uscite, le WCAG 1.0 hanno avuto il compito di fare da apripista, di introdurre in senso normativo il tema dell’accessibilità. Essendo un primo lavoro ha portato con se le naturali imprecisioni ed errori di prospettiva che è lecito attendersi da un documento di portata così ampia. Tra le maggiori critiche che sono state portate alle WCAG 1.0 si ricordano:  Il fatto di essere espressamente mirate ai linguaggi definiti dal W3C come l’HTML e il CSS (quando sono uscite XHTML e SVG erano ancora da definirsi) e di non considerare, se non marginalmente, le tecnologie proprietarie;  Il fatto di essere state concepite e definite completamente senza passare da una prassi convalidata e da una sufficiente elaborazione da parte delle associazioni dei disabili. Se le WCAG fossero centrate sulle osservazioni di ciò che ai disabili serve in rapporto a ciò che è possibile fare, le soluzioni sarebbero pratiche e praticabili. Se non sempre lo sono è anche perché si parte da come il codice in teoria dovrebbe e potrebbe essere implementato, più che dalla realtà esperita dai disabili.1 In aggiunta le loro applicazioni sono state spesso mal realizzate o del tutto disattese anche a molti anni di distanza dalla loro emanazione. 1 Maurizio Boscarol: [http://www.ecologiadeisitiweb.net/blog/la-balcanizzazione-dellaccessibilita] - 238 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Se in un primo momento questo fatto poteva essere addotto alla relativa poca sensibilizzazione e diffusione dei principi dell’accessibilità, con il passare degli anni e la maggiore attenzione da più parti rivolta al problema, è diventato solamente un problema di economia di tempo e di cattiva abitudini progettuali. Semplicemente molti hanno giudicato che non ne valesse la pena1 e che non ci fossero risorse da sprecarci in tempo e denaro. Nel 2004 è stata pubblicata un’indagine formale2 condotta dalla commissione dei diritti dei disabili a proposito dell’accesso al Web e della inclusione delle persone disabili. Sono state testate 1000 home page, rappresentative di 5 settori: governativo, affari, commercio elettronico, intrattenimento, servizi Web. E’ stato usato un valutatore automatico per una prima analisi. Ovviamente uno strumento automatico non può controllare la conformità di tutti i 65 punti di controllo visto che, come illustrato, alcuni richiedono uno specifico intervento umano. Per quanto riguarda la compatibilità con il livello A, delle 1000 home page controllate 808, cioè l’81% circa avevano delle violazioni anche solamente a livello dei punti di controllo a priorità 1. In altre parole solo il 19% di queste home page avrebbero potuto essere di livello A, a patto poi di passare anche il controllo manuale. E questo analizzando esclusivamente le home page, senza nessun controllo sul resto del sito. I risultati migliori dei cinque settori sono venuti dai siti governativi che hanno superato per il 32% i soli controlli automatici di livello A. Se poi si passa a livello doppia-A i risultati sono disastrosi. Solamente 6 home page, pari al 0.6% del campione ha dimostrato di passare i soli controlli automatici senza contenere violazioni per i punti di controllo 1 e 2. In questo caso è stato compiuto anche un controllo manuale su questi 6 candidati scoprendo che poi solamente 2 (pari al 0.2% del campione) erano effettivamente conformi alla doppia-A. Nessuno dei 1000 raggiungeva la conformità tripla-A. Come ricordato in un pungente articolo3 di Joe Clark, citato successivamente nei commenti della versione 2.0 delle WCAG, il raggiungimento della tripla-A è considerato, di fatto, irrilevante o inattendibile, mentre le priorità 1 e 2 sono, di conseguenza, il blocco di regole 1 “Normally, the reason your favorite pet accessibility feature is missing is simply that a decision was made that it wasn’t worth the effort. Is that insensitive? No, it’s business.” – [http://www2.jeffcroft.com/blog/2006/aug/21/has-accessibility-been-taken-too-far/] 2 [http://joeclark.org/dossiers/DRC-GB.html] 3 [http://alistapart.com/articles/tohellwithwcag2] - 239 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR necessarie per rendere il sito accessibile visto che il livello tripla-A è oneroso e impossibile da raggiungere. Lo studio precedente è stato arricchito con un’analisi specifica sulle linee guida violate. Sono state considerate due rilevazioni:  Il numero di linee guida differenti che sono state violate sulla home page;  La ricorrenza delle violazioni in cui si è incorsi. Il numero medio di linee guida violate sul campione di 1000 home page è stato approssimativamente di 8 per pagina. Il che significa che ci sono mediamente 8 differenti linee guida per pagina a cui gli sviluppatori devono porre maggiore attenzione. L’analisi delle ricorrenze rivela approssimativamente 108 violazioni per pagina, comprendendo sia quelle più significative sia quelle meno significative, e questo da le dimensioni della quantità di ostacoli che vengono incontrati mediamente dalle persone disabili nella navigazione. Un'altra interessante analisi1 è stata compiuta sulle compagnie facenti parte del FTSE 100 index, cioè le 100 compagnie a capitale maggiore del London Stock Exchange. L’analisi, condotta recentemente nel Marzo del 2006 dagli esperti del NOMENSA, dimostra come almeno il 75% delle compagnie nella lista del FTSE 100 non sono adeguate alle richieste minime per l’accessibilità dei siti Web. Le home page di ogni sito analizzato sono state valutate utilizzando procedure di test manuale in riferimento alle WCAG 1.0. Solamente 24 siti raggiungono il minimo livello di accessibilità e nessuno raggiunge la doppia-A o la tripla-A. Tra queste 24, due si elevano sopra gli standard mancando di raggiungere la doppia-A per un punto di controllo, questo a causa della incapacità delle pagine di essere espanse o contratte in accordo con le preferenze utente. I punti deboli di questi siti sono in genere:  Una scarsa qualità del codice HTML;  Un uso poco pulito delle liste;  Non vengono impiegati le intestazioni e i titoli propriamente;  Mancanza dei testi alternativi per gli elementi grafici;  Apertura di finestre di pop-up. 1 [http://www.nomensa.com/news/at-nomensa/2006/4/ftse-100-websites-fail-accessibilityrequirements.html] - 240 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR La data recente di questo sondaggio e l’importanza dei siti Web esaminati fa capire quanto, anche solo le WCAG 1.0, siano ben lontane dall’essere state recepite e metabolizzate dai progettisti di siti Web. - 241 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR IV.3 - Section 508 (LEGGE FEDERALE U.S.A. - 21 DICEMBRE 2000) Il problema della disabilità nei luoghi di lavoro è stato affrontato con decisione negli Stati Uniti dove coinvolge un gran numero di persone. Per dare un’idea della dimensione degli interessi in gioco, negli USA ci sono 2.500.000 di dipendenti federali di cui 160.000 portatori di handicap1. Anche per questo il governo degli Stati Uniti è stato tra i primi a produrre una normativa che tenesse conto dell'accessibilità sui luoghi di lavoro. Già dal 1998 era stata emanata la sezione 508 del Rehabilitation Act, estensione dell'Americans with Disabilities Act (ADA). Questa legge impone alle Agenzie Federali di acquistare tecnologia informatica ed elettronica che sia accessibile a persone con disabilità. La sezione 508 trova origine nella volontà di eliminare le barriere nella tecnologia informatica ed elettronica, per rendere disponibili nuove opportunità a persone con disabilità, e per incoraggiare lo sviluppo di tecnologie che aiutino a raggiungere questi obiettivi. La legge si applica a tutte le Agenzie Federali che sviluppano, acquisiscono, gestiscono o usano tecnologie informatiche e elettroniche. In ottemperanza alla sezione 508, le Agenzie devono assicurare ai propri impiegati ed al pubblico con disabilità un accesso alle informazioni che sia comparabile a quello disponibile agli individui normodotati. La legge assegna all'Agenzia Federale (Access Board) che si occupa del superamento delle barriere per le persone portatrici di handicap, il compito di definire standard di riferimento opportuni. Questa agenzia federale per l'accesso ha delegato, a sua volta, ad un comitato tecnico di professionisti, accademici e rappresentanti delle organizzazioni dei disabili, il compito materiale di redigere le regole per l'accessibilità. Il comitato investito di questo compito è chiamato Electronic and Information Technology Access Advisory Committee (EITAAC). Il 21 marzo del 2000, come risultato del lavoro compiuto nei mesi precedenti dall'EITAAC, l’Access Board ha pubblicato una bozza di linee guida per l’accessibilità. Dopo un periodo di valutazioni e commenti pubblici, il 21 dicembre del 2000 le proposte dell’EITAAC sono diventate legge a tutti gli effetti, con obbligo per le agenzie federali degli Stati Uniti di conformarvisi dal mese di Giugno 2001. Da allora le Agenzie Federali inadempienti rischiano di incorrere in azioni civili da parte di dipendenti portatori di handicap, nel caso non rispettino le normative approvate. 1 [http://www.pubbliaccesso.gov.it/normative/rehabilitation_act/promemoria.htm] - 242 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR È stata inoltre creata un’apposita struttura all'interno del governo federale con il compito di formare gli impiegati federali e di costruire l'infrastruttura necessaria a supportare l'attuazione della sezione 508. Tra le altre iniziative è stato creato un sito Web 1 al fine di rendere disponibili informazioni e risorse per comprendere ed attuare i requisiti della normativa. È importante notare che le linee guida definite dall'EITAAC non riguardano solo Internet ed il Web, ma un’ampia varietà di apparati tecnologici hardware e software. In particolare 2:  Programmi applicativi e sistemi operativi;  Informazioni ed applicazioni Intranet ed Internet basate sul Web;  Prodotti per telecomunicazioni (telefoni e telescriventi);  Prodotti video e multimediali (apparecchi televisivi, riproduttori di videocassette e DVD);  Prodotti autosufficienti con software incorporato (chioschi multimediali, bancomat, fotocopiatrici, fax, stampanti, macchine calcolatrici);  Computer da tavolo e portatili. Il risultato dell’entrata in vigore di tale legislazione è che i requisiti di accessibilità sono considerati fin dalla gara d’appalto per l’acquisto di apparecchiature e servizi elettronici e informatici. Tra due ditte che partecipano alla medesima gara, a parità di offerta, vince chi è in grado di garantire la migliore copertura dei requisiti di accessibilità stabiliti dall’articolo 508. Questa disposizione è, in parte, analoga a quanto attuato anche da noi con la legge 04/2004 di cui discuteremo diffusamente in seguito. Con la rilevante aggiunta che in Italia, per le Pubbliche Amministrazioni, i requisiti Web sono obbligatori. Un’interessante lista di controllo3 per la verifica della attuazione delle legge americana è reperibile su internet sul sito di WEBAIM (WEB Accessibilty In Mind) dove sono riportate dei precisi punti di controllo per ogni linea guida per pagine HTML, JavaScript, Plug-in e Java. Linee guida per le pagine Web Per quanto riguarda la nostra analisi, le linee guida per lo sviluppo di applicazioni Web della Section 508 prevedono 16 direttive e sono contenute nel paragrafo 1194.22: “Informazioni e applicazioni Internet e Intranet sul Web”4, definito nell'articolo 508. 1 2 3 4 [http://www.section508.gov/] [http://www.diodati.org/scritti/2002/sec508/sec508_stam.asp] [http://www.webaim.org/standards/508/checklist] “Web-based Intranet and Internet Information and Applications” - 243 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Le riporto nella traduzione del governo italiano1. Il testo originale è reperibile sul sito delle autorità americane2 ed uno stralcio essenziale è contenuto anche in appendice. In una nota allegata alla stessa sezione, il governo americano rileva come molte linee guida siano ispirate direttamente dalle WCAG 1.0 già preesistenti al momento di produrre la normativa. Altre sono delle aggiunte esplicite. Evidenzieremo questi aspetti dopo l'esposizione della legislazione. Per le brevi note di commento al testo ho ritenuto significativo aggiungere dei commenti basati sulle note tratte dal sito di Jim Thatcher3 a cui rimando per la versione originale in lingua inglese. 1194.22 (a): Offrire un equivalente testuale. Bisogna fornire un equivalente in forma testuale per ogni elemento di natura non testuale (ad esempio a mezzo dell'ALT, LONGDESC o nel contenuto dell'elemento). Ogni immagine del sito Web deve avere un testo alternativo. Anche le immagini che non portino informazioni importanti o siano ridondanti. In questo caso si può utilizzare un testo vuoto con l'attributo ALT="". Occorre usare l'attributo LONGDESC oppure una notazione tipo dLink per descrivere i grafici o i diagrammi nel caso in cui l'attributo ALT non possa portare informazioni equivalenti. 1194.22 (b): Fornire elementi multimediali sincronizzati. Alternative equivalenti per una qualsiasi presentazione multimediale dovranno essere sincronizzate con la presentazione stessa. Gli equivalenti testuali per le presentazioni multimediali devono essere sincronizzati con le presentazioni, come ad esempio per le titolazioni. Gli autori delle pagine Web sono incoraggiati a includere trascrizioni del contenuto audio come alternative sincronizzate, questo dal momento che un tale genere di trascrizioni consentono tecniche di ricerca ed estrazione di testo. 1194.22 (c): Non vincolarsi al colore Le pagine Web dovranno venire progettate in modo tale che tutte le informazioni fornite tramite colori siano anche disponibili senza l'utilizzo di tale mezzo, ad esempio dal contesto o tramite un linguaggio a marcatori. 1 2 3 [http://www.pubbliaccesso.gov.it/normative/rehabilitation_act/standard_tecnici.htm] [http://www.section508.gov/] [http://www.jimthatcher.com/webcoursec.htm] - 244 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Si tratta di non veicolare informazioni importanti con il solo uso del colore. Utilizzare font, caratteri particolari o altri tipi di evidenziatori oltre all'uso del colore. 1194.22 (d): Progettare indipendentemente dai fogli di stile. I documenti dovranno essere organizzati in modo da risultare leggibili anche senza l'utilizzo di fogli di stile. I fogli di stile sono un efficace aiuto nello specificare font, modifiche visuali e colorazione alle pagine Web. Ad ogni modo non devono essere impiegati esclusivamente cambiamenti di stile per marcare elementi strutturali del linguaggio HTML, come ad esempio le intestazioni , i paragrafi
e le liste. Nel caso che vengano usati i fogli di stile per il posizionamento degli elementi o per la gestione dei colori, occorre controllare la visualizzazione delle pagine anche senza i fogli di stile per verificare che nessuna informazione vada perduta disattivandoli. 1194.22 (e): Fornire collegamenti ridondanti per le mappe lato server. Bisognerà fornire link ridondanti ad informazioni di natura testuale per ogni regione attiva di una server-side image map. Se si devono usare le mappe lato server, occorre essere sicuri che ci siano equivalenti testuali associati per ogni regione attiva della mappa. 1194.22 (f): Utilizzare mappe lato client. Bisognerà mettere a disposizione client-side image map al posto delle server-side image map ad eccezione dei casi in cui la regione non può essere definita utilizzando una forma geometrica disponibile. Il fatto che sia possibile utilizzare una regione poligonale per descrivere ogni area fino al dettaglio desiderato, permette di utilizzare mappe lato client in ogni caso. Occorre comunque ricordarsi di includere un testo alternativo per ogni area della mappa. 1194.22 (g): Intestare righe e colonne Nel caso di tabelle sarà necessario identificare le intestazioni di riga e colonna. Se, nella tabella dati, ci sono intestazioni in cima alle colonne o al principio delle righe, occorre usare il marcatore di intestazione (TH) per indicarle. 1194.22 (h): Usare l'attributo di intestazione per le tabelle complesse Sarà necessario utilizzare marcatori per associare il contenuto dell'elemento di una tabella e gli identificatori di riga e colonna ad esso associati quando gli identificatori di riga o colonna sono costituiti da due o più livelli logici. Non è probabilmente una buon’idea utilizzare delle tabelle che abbiano più di un livello logico di intestazione per righe o colonne. Tuttavia, nel caso venissero implementate occorre includere - 245 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR l'opportuno tag di marcatura su ogni cella con l'attributo di intestazione per indicare il significato della cella stessa, utilizzando l'attributo ID per indicare l'informazione di intestazione. 1194.22 (i): Fornire titoli per i frame. I frame dovranno essere dotati di titolazioni in forma testuale in modo da rendere agevole l'identificazione dei frame e la navigazione tra gli stessi. Allo scopo di facilitare una navigazione ragionevole in un sito con frame, ogni elemento FRAME di una struttura di tipo FRAMESET deve avere un titolo significativo e un attributo NAME. Ogni FRAME deve avere un elemento titolo. 1194.22 (j): Ridurre gli sfarfallamenti. Le pagine dovranno essere progettate in modo da evitare che lo schermo mostri fenomeni di intermittenza aventi una frequenza maggiore di 2Hz e minore di 55Hz. Non avere GIF animate o altri oggetti che possano causare uno sfarfallio di una parte dello schermo. Tale genere di elementi può causare delle crisi nelle persone con una epilessia fotosensibile. 1194.22 (k): Fornire un alterativa solo testo come ultima risorsa. Dovrà essere fornita una pagina di solo testo con informazioni o funzionalità equivalenti in modo da far sì che una pagina Web ottemperi alle disposizioni della presente parte quando la osservanza delle norme in questione non può essere conseguita in alcun altro modo. Il contenuto della pagina di solo testo dovrà essere aggiornato ogni qualvolta la pagina primaria cambia. Nel caso che non si riesca a soddisfare qualche requisito degli standard 508, è possibile creare un sito solo testo. Il sito solo testo deve avere tutte le informazioni del sito principale, deve essere aggiornato con la stessa frequenza del sito principale e deve essere immediatamente ed evidentemente accessibile dalla pagina principale. 1194.22 (l): Implementare script accessibili. Nei casi in cui le pagine Web utilizzano linguaggi basati su script per visualizzare il loro contenuto o per creare elementi di interfaccia, l'informazione fornita dagli script dovrà venir identificata da testi funzionali che possono venir letti utilizzando tecnologie di supporto. Uno dei modi per controllare che il sito sia compatibile con le richieste della sezione 508 è che le informazioni essenziali non vengano perdute quando le funzionalità JavaScript siano disattivate. - 246 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Le informazioni essenziali non vengono perdute se viene usato un effetto di evidenziazione attivato da un evento MOUSEOVER o se ci sono comunque delle modalità alternative per attivare i collegamenti contenuti nei menu di tipo MOUSEOVER. Se vengono usati gli script per scrivere in un modulo informazioni essenziali in un forma visuale al momento del caricamento, allora quelle informazioni saranno disponibili alla tecnologia assistiva. Se si sta facendo uso di un contenuto nascosto esposto con i gestori di avvenimento in linguaggio JavaScript, occorre assicurarsi o che il contenuto equivalente sia disponibile senza JavaScript o che si possano attivare gli stessi eventi tramite la tastiera. 1194.22 (m): Specificare applet e plug-in accessibili. Allorché una pagina Web richiede che sul sistema utente siano presenti un applet, un plug-in o altre applicazioni per interpretare il contenuto della pagina, la stessa dovrà fornire un link ad un plug-in o ad un applet che si conforma alle disposizioni contenute nel paragrafo 1194.21 da (a) a (l). Applets e plug-in devono soddisfare gli standard software della Section 508. In particolare devono essere integralmente utilizzabili senza il mouse. Nel momento in cui il focus si sposta da oggetto ad oggetto, le tecnologie assistive devono essere in grado di determinare il compito e l'azione di default per ogni oggetto che acquisisce il fucus. Occorre testare l'utilizzo degli applets e dei plug-in utilizzandoli solo la tastiera. 1194.22 (n): Progettare moduli accessibili. Allorché moduli digitali vengono progettati per essere completati on-line, i moduli stessi dovranno permettere l'accesso ad individui che utilizzano tecnologie di supporto alle informazioni, ai campi e alle funzionalità richieste per il completamento e l'inoltro del modulo comprese tutte le informazioni di contesto nonché quelle relative a destinatari secondari per conoscenza. Occorre accertarsi di aver etichettato attentamente gli elementi di un modulo collocando l'etichetta di testo nelle vicinanze del controllo relativo. Utilizzare l'elemento LABEL per associare via codice i prompt con gli elementi di input quando il testo del prompt e il controllo sono separati. 1194.22 (o): Fornire una navigazione a salti. Dovrà essere messo a disposizione un metodo che permetta agli utenti di saltare link di navigazione ripetitivi. Occorre fornire un sistema agli utenti per spostarsi velocemente sui collegamenti ipertestuali di navigazione. Questo può essere ottenuto con un link del tipo "salta la navigazione" posto in testa alla pagina. In alternativa si possono predisporre delle strutture ben organizzate. - 247 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 1194.22 (p): Avvisare l'utente sui tempi di risposta. Nei casi in cui sia richiesta una risposta a tempo, l'utente dovrà venire avvisato e gli dovrà venir fornito tempo sufficiente per indicare che ha bisogno di un'ulteriore quantità di tale risorsa. Se la pagina si aspetta una risposta dall'utente in un tempo prescritto, occorre avvisare l'utente di questo fatto, e consentirgli l'impiego di tempo supplementare. Relazione con le direttive WAI L'esposizione della normativa americana, precedente alla nostra legge Stanca del 2004, ma successiva alle direttive WCAG 1.0, ci porta direttamente a valutarle in relazione le une con le altre. Un primo aiuto in tal senso viene fornito direttamente dalla Section 508 che stabilisce dei criteri ispiratori con le precedenti WCAG 1.0. I primi paragrafi (a-k) sono posti espressamente in relazione con le prescrizioni internazionali, mentre gli ultimi (l-p) sono considerati indipendenti, secondo questo schema: 1. Il Comitato per l'Accesso interpreta i paragrafi da (a) a (k) della presente sezione nel senso che risultino coerenti con i seguenti punti di controllo di priorità 1 del Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (5 Maggio 1999) pubblicato dal Web Accessibility Initiative del World Wide Web Consortium. TABELLA 2 - CORRISPONDENZA SECTION 508 E WCAG 1.0 Paragrafo 1194.22 Checkpoint WCAG 1.0 (a) 1.1 (b) 1.4 (c) 2.1 (d) 6.1 (e) 1.2 (f) 9.1 (g) 5.1 (h) 5.2 (i) 12.1 (j) 7.1 (k) 11.4 2. I paragrafi (l), (m), (n), (o) e (p) di questa sezione risultano diversi da WCAG 1.0. Le pagine Web che ottemperano a WCAG 1.0, livello A (ossia tutti i punti di controllo di - 248 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR priorità 1) devono anche soddisfare il contenuto dei paragrafi (l), (m), (n), (o) e (p) della presente sezione per ottemperare alla sezione stessa. Come vedremo meglio con l’esposizione comparata delle normative, le varie legislazioni, pur ottemperando di base agli stessi principi esposti in questo testo, non sono del tutto identiche. In particolare, le regole dell'articolo 508 introducono differenze significative per quanto riguarda la gestione di script, applet e programmi accessori integrati rispetto alle WCAG 1.0. In particolare1:  Sono più restrittive circa lo sfarfallamento dello schermo e fanno riferimento al problema della risposta temporizzata, quasi del tutto assente dalle linee guida WAIW3C, se non per i punti 7.4 e 7.5 ma a proposito di contesti specifici;  Sono più permissive rispetto alla segnalazione di qualsiasi cambiamento di linguaggio naturale nel testo e l'uso del più chiaro e semplice linguaggio appropriato al contesto: due criteri che nelle regole per il Web elencate sotto l'articolo 508 sono completamente assenti. Nelle norme federali, infatti, non viene fatto alcun accenno alla comprensibilità e alla semplicità del materiale esposto, un importante fattore che invece nelle WCAG, specialmente nelle 1.0, viene esplicitamente menzionato. Quinti la piena conformità alle sedici linee guida federali non coincide con la piena conformità alle raccomandazioni WCAG 1.0 del WAI: aver raggiunto la prima non è garanzia di ottenere la seconda, e viceversa. Michele Diodati, in un suo articolo su internet, ha fatto notare che ci potrebbero essere persino delle incompatibilità di base tra le due normative, dei punti di divergenza che rendono in certi casi materialmente impossibile soddisfare entrambe le formulazioni, in quanto l'obbedienza ad una delle due esclude di poter obbedire all'altra. Si riferisce in particolar modo ad un caso comune ed importante: la gestione delle funzionalità introdotte nelle pagine Web per mezzo di linguaggi di script, applet ed oggetti di programmazione. In effetti, il punto di controllo 6.3 delle WCAG 1.0 recita: “Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati. Se questo non è possibile, fornire informazione equivalente in una pagina accessibile alternativa.”. 1 [http://www.diodati.org/scritti/2002/sec508/sec508_stam.asp] - 249 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Su questa si allinea anche il requisito 15 della legge italiana. Mentre, a proposito degli script il paragrafo (l) delle norme federali dichiara: “Nei casi in cui le pagine Web utilizzano linguaggi basati su script per visualizzare il loro contenuto o per creare elementi di interfaccia, l'informazione fornita dagli script dovrà venir identificata da testi funzionali che possono venir letti utilizzando tecnologie di supporto.”. Secondo Diodati la differenza sembra inconciliabile: Per le WCAG 1.0, il contenuto informativo generato dallo script deve essere accessibile (tramite testi alternativi) anche per mezzo di programmi utente che non supportano gli script o che ne hanno disabilitato il supporto, anche se poi lo script in se stesso non genera testo funzionale leggibile per mezzo di tecnologie assistive. Per il paragrafo (l) di Section 508 basta invece che si generi un testo funzionale che sia possibile leggere per mezzo di tecnologie assistive e non occorre produrre un'alternativa per utenti che non possano o non vogliano usare sistemi abilitati a gestire linguaggi di script.1 Personalmente, per quanto fortemente discostanti, non trovo incompatibili queste due letture e non ritengo che sia il caso di cavillare sui singoli dispositivi. La filosofia di base è di rendere disponibili le informazioni contenute nella pagina anche ai disabili, garantendo che vi possano accedere o direttamente tramite le tecnologie assistive o usufruendone anche con gli script disabilitatati. La norma americana sembra essere notevolmente più permissiva, ma occorre ricordare che anche le WCAG 2.0 possono richiedere l’uso degli script attivati qualora siano dichiarati nella baseline. Ovviamente, per quello che ci riguarda, restano più significative le WCAG 1.0, sulle quali, come dicevo, il testo della legge italiana si è chiaramente ispirato. Relazione con la legge italiana In generale la legge americana è più pragmatica dei punti di controllo previsti dalle WCAG 1.0, per quanto alla fine si riveli più carente per altri aspetti 2. I requisiti della legge Stanca sono, di fatto, in generale più restrittivi della Section 508 statunitense, come vedremo al termine della disamina della legge italiana. Una conclusione prevedibile, visto che la legge Stanca ha voluto sintetizzare suggerimenti tecnici sia della Section 508 sia delle WCAG 1.0. In particolare i punti in cui la legge Stanca risulta più restrittiva includono:  1 2 Gli aspetti legati alla validità sintattica dei file (XHTML, DTD STRICT), [http://www.diodati.org/scritti/2002/sec508/sec508_3.asp] Giorgio Brajnik: [http://www.dimi.uniud.it/wq/stanca-mappa.html] - 250 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  L’obbligo di non usare i frame;  Il fornire un contrasto elevato;  L’usare il CSS, un layout liquido e testo ridimensionabile;  Il rendere linearizzabili le tabelle di layout;  Il rendere i collegamenti ipertestuali informativi, e il distanziarli opportunamente;  Il non usare pagine solo testo come alternativa ammissibile. In alcuni punti invece la legge Stanca è leggermente meno precisa, in particolare nel discutere delle immagini (GIF) che possono causare epilessia e quando, per taluni, non sembra considerare esplicitamente i file PDF soggetti ai vincoli dell'accessibilità nei siti Web. Una tabella sintetica di confronto verrà presentata al termine della esposizione di tutte le normative. Un ultimo appunto va rivolto all’attenzione del legislatore per il delicato problema degli aggiornamenti. Si tratta di un tema particolarmente sentito da queste normative che sono costrette a confrontarsi con la continua evoluzione delle tecnologie presenti in rete. Le WCAG 1.0 hanno pesantemente sofferto di questa lacuna, ed uno dei principi ispiratori della versione 2.0 è stato proprio quello di produrre una raccomandazione il più possibile avulsa dalle specifiche tecniche adottate. Da questo punto di vista la legge americana è una delle più vincolate in quanto, non sono fa riferimento ad elementi specifici di un linguaggio specifico (mi riferisco in particolar modo alle citazioni degli attributi ALT, LONGDESC, fogli di stile, FRAMESET, FORM eccetera), ma non prevede espressamente nemmeno un meccanismo di revisione periodica della normativa e questo può rappresentare un significativo difetto, tanto più quando essa abbia in sé dei difetti congeniti. A sentire per esempio Emily Dixon di Usable.net, che ben conosce dall’interno la Section 508, l’applicazione di questa legge negli USA, a due anni dalla sua promulgazione, non solo è stata in gran parte trascurata, ma è stata anche causa di notevoli problemi di interpretazione e di comprensione.1 La legge italiana, da questo punto di vista, integra un aspetto un po’ più efficace, e cioè la previsione esplicita di un suo aggiornamento delle norme tecniche come indicato all’articolo 12. Che questo poi non sia ancora avvenuto è un problema che mi auguro sia motivato dall’attesa per le imminenti uscite delle WCAG 2.0. 1 [http://www.i-use.it/articoli/accessibilita/2/] - 251 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR IV.4 - Legge Stanca (LEGGE DELLO STATO ITALIANO - 9 GENNAIO 2004) Il fermento normativo intorno al tema dell’accessibilità non è rimasto disatteso in Italia. La legislazione italiana ha prodotto una legge sull'accessibilità del Web tra le più avanzate e restrittive a livello mondiale, la legge 04/2004: “Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici”, detta comunemente legge Stanca dal nome del Ministro per le Innovazioni e le Tecnologie sotto il cui mandato è stata approvata. La legge trova origine nel decreto legislativo Dlgs 216/2003: “Attuazione della direttiva 2000/78/CE per la parità di trattamento in materia di occupazione e di condizioni di lavoro” dell’anno precedente. L'iniziativa normativa si è sviluppata nell'arco di un anno ed è stata stimolata da Roberto Scano per conto di IWA/HWG, che ha predisposto la proposta di legge n. 3486 presentata a Venezia il 16 dicembre 2002 dagli On. Campa e Palmieri. Tale proposta di legge, recependo le indicazioni dell'Unione Europea, richiedeva l'applicazione dell'intero progetto WAI del W3C ed è stata sottoscritta da oltre 130 parlamentari. Altre proposte sono seguite1. La novità di queste proposte normative sta nel coinvolgimento degli operatori del Web: l'associazione IWA/HWG ha predisposto una lista di discussione dedicata, nella quale gli esperti del settore e gli onorevoli firmatari dei progetti di legge si sono scambiati opinioni ed hanno apportato proposte di integrazione al disegno di legge.2 Il risultato della legge ha richiesto molto lavoro ed è una fusione di una ventina di testi differenti. Più di una cinquantina di associazioni sono state chiamate in causa, con una ventina di specialisti esterni. Il tutto con l’obiettivo di ottenere il maggiore consenso possibile.3 Tutto il suo impianto è assolutamente innovativo. Il governo italiano è uno dei primi governi al mondo ad affrontare il problema con tale interesse ed attenzione. Per questi aspetti e per l’interesse diretto, la trattazione di questa materia sarà un po’ più approfondita e coinvolgerà anche alcuni aspetti legislativi. La maggiore attenzione che ho voluto dedicare anche a problemi che vanno oltre una pura relazione tecnico-scientifica è dovuta al fatto che in realtà, a differenza delle norme WAI, la legge Stanca è un testo di legge valido a tutti gli effetti, anzi, è l’unica normativa ufficiale in Italia. 1 2 3 [http://www.pubbliaccesso.gov.it/normative/progetti_legge/index.htm] Roberto Scano: “Accessibilità: dalla teoria alla realtà”. Roberto Ellero: Seminario “Legge Stanca: dalla teoria alla realtà”, Arese 2005. - 252 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Data l’inerzia delle società e delle amministrazioni pubbliche, credo che sia necessario, affinché l’accessibilità non resti una parola morta, che il dispositivo di legge in materia venga compreso e divulgato nella sua pienezza. Il nucleo dell’esposizione e del commento alla legge presentata in questa sezione è basato su una conferenza tenuta da Roberto Ellero e da Luca Mascaro alla Biblioteca Comunale di Arese (MI) nel Maggio del 2005. Il Seminario, dal titolo: "Legge Stanca: dalla teoria alla realtà. Analisi delle disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici", è stato organizzato direttamente da IWA – Italy. I due docenti sono figure preminenti nel campo dell’accessibilità:  Roberto Ellero ha seguito la stesura dei requisiti tecnici della legge, è W3C WCAG Working Group Member for IWA/HWG, è docente IWA per il CNIPA;  Luca Mascaro è membro di diverse organizzazioni internazionali come l'IWA/HWG per la Svizzera, e partecipa a vari gruppi di lavoro all'interno dei consorzio W3C (HTML, WCAG, Web Application Format e Web API) e ISO. L’impianto completo della legislazione si articola in diversi atti:  Dlgs 216/2003;  Legge 04/2004;  Codice dell’Amministrazione Digitale (DLgs 7 Marzo 2005, n. 82);  Regolamento di attuazione (DPR 1 marzo 2005, n. 75);  Requisiti tecnici della Legge 04/2004 (DM 8 Luglio 2005). Ovviamente il centro della trattazione saranno i requisiti tecnici che riguardano più da vicino questa tesi. Come per le precedenti normative, i concetti guida sono stati già esposti nel capitolo delle metodologie generali e a quella sezione farò più volte richiamo. Prima di procedere con l’esposizione vorrei riportare nella maniera più fedele possibile un concetto illuminante esposto da Luca Mascaro durante la conferenza: l’accessibilità non è di per se un punto di arrivo, è piuttosto un primo tentativo di mettere ordine. E’ Un modo per iniziare con una buona base di partenza che negli anni dovrà consentire un miglioramento generale dei siti. Si comincia con questa metodologia per avere tra dieci anni dei siti della pubblica amministrazione organizzati e strutturati in maniera migliore di come non lo siano oggi. Allo stato attuale delle cose, i siti che siano a posto anche solo con il primo requisito della legge Stanca sono trascurabili. Un simile pensiero è ripreso nell’analisi dei costi dell’accessibilità a cui rimando per approfondimenti. - 253 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Decreto legislativo 216/2003 Come accennato nella precedente presentazione, le basi della Legge Stanca si possono rintracciare nel precedente Decreto Legislativo 216/2003. Il decreto è stato pubblicato sulla Gazzetta Ufficiale il 13 Agosto 2003 con titolo “Attuazione della direttiva 2000/78/CE per la parità di trattamento in materia di occupazione e di condizioni di lavoro” ed è in vigore dal 31 Agosto 2003. Ha le sue origini in una direttiva europea, la direttiva 2000/78/CE del Consiglio Europeo del 27 novembre 2000. L’oggetto è quello delle pari opportunità nel mondo del lavoro. Reca le disposizioni relative all'attuazione della parità di trattamento fra le persone indipendentemente dalla religione, dalle convinzioni personali, dagli handicap, dall'età e dall'orientamento sessuale, per quanto concerne l'occupazione e le condizioni di lavoro, disponendo le misure necessarie affinché tali fattori non siano causa di discriminazione. Eccezione fatta qualora, per la natura dell'attività lavorativa, si tratti di caratteristiche che costituiscono un requisito essenziale e determinante ai fini dello svolgimento dell'attività medesima. Questo decreto è passato sostanzialmente non visto fino alla sua riconsiderazione alla luce della successiva legge Stanca, ma il concetto che non sia possibile discriminare in alcun mondo una persona disabile, anche momentaneamente disabile, come ad esempio per un infortunio al braccio, ha delle ripercussioni significative, dal momento che la disposizione delle misure necessarie è spesso un impegno non indifferente nel mondo del lavoro. Per fare degli esempi elementari, se un lavoratore ha un braccio rotto, l’azienda deve provvedere a fornirgli gli opportuni ausili per lavorare. Un ipovedente medio spesso non ha diagnosi da ipovedente, caso tipico di chi porta gli occhiali, ma queste persone, qualora lo richiedano, hanno diritto ad avere sul posto di lavoro gli strumenti accessibili per la mansione che svolgono. A differenza della legge Stanca, il lavoratore deve essere messo in grado di svolgere le sue mansioni sia nel caso di un’azienda privata che in quello di una pubblica amministrazione. Qualora il dirigente vieti l'acquisto di attrezzature atte all'integrazione del lavoratore con disabilità, tale dirigente effettua una discriminazione ed è soggetto ai provvedimenti di legge. La richiesta deve partire dal dipendente e il datore di lavoro deve provvedere di conseguenza. Il decreto 216 è una norma penale, il datore di lavoro che la infranga può incorrere anche in una sanzione economica. Un aspetto da notare è che non deve essere necessariamente la persona lesa a fare causa, la legittimazione ad agire è riconosciuta anche alle rappresentanze locali delle organizzazioni nazionali maggiormente rappresentative. - 254 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR In questo decreto legislativo non sono contenute norme esplicite per la gestione dei siti Web. Tuttavia ho ritenuto opportuno riportarne brevemente questi principi guida per spiegare meglio la filosofia da cui traggono origine le successive normative in questione. Legge 04/2004 La Legge è stata pubblicata sulla gazzetta ufficiale n. 13 del 17 gennaio 2004 con il titolo “Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici” ed è in vigore dal 1 febbraio 2004. Come accennato nella parte introduttiva di questa sezione, il dispositivo nasce da una precisa tendenza e si allinea alle direttive della comunità europea, tra cui la fondamentale Comunicazione CE del 25 settembre 2001 dal titolo “eEurope 2002: accessibilità e contenuto dei siti Internet delle amministrazioni pubbliche”1. La Legge ha dei contenuti profondamente innovativi:  Tutti i siti che saranno realizzati, o rinnovati, in futuro dalle pubbliche amministrazioni dovranno rispettare i requisiti di accessibilità;  Per i privati, il provvedimento non genera un obbligo di accessibilità per i siti internet, ma è fattore di stimolo a promuovere l’accessibilità delle loro pagine Web;  Tutti i libri di testo delle scuole, ove possibile, saranno resi disponibili in formati leggibili al computer da non vedenti o ipovedenti o con altre disabilità. Presentazione Date queste premesse, i docenti del seminario tenutosi ad Arese hanno messo in risalto il fatto che in Europa la legge italiana venga considerata una normativa piuttosto esigente per gli enti interessati. Il dispositivo di legge, oltre a riguardare tutte le pubbliche amministrazioni a qualunque livello, coinvolge anche le scuole di ogni ordine e grado, le università, gli enti del servizio sanitario nazionale, dando delle norme non solamente per i siti Web, ma anche, sebbene con modalità diverse, per le attrezzature informatiche e per le postazioni di lavoro. Per le attrezzature e le postazioni di lavoro, i requisiti sono titolo preferenziale, mentre invece per i siti Web costituiscono vincolo contrattuale, se infatti le forniture non sono conformi ai 22 requisiti Web il contratto viene annullato. 1 Quaderno del C.N.I.P.A. n.1 del Novembre 2003. [http://eurlex.europa.eu/LexUriServ/site/it/com/2001/com2001_0529it01.pdf], [http://europa.eu.int/eurlex/it/com/cnc/2001/com2001_0529it01.pdf] - 255 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Anche in questo caso per invalidare il contratto non è necessario che vi ricorra esclusivamente il disabile, può fare ricorso anche un dipendente della pubblica amministrazione o di una società concorrente. Ogni altro partecipante al bando di concorso può ricorrere. Esiste poi la figura del Difensore Civico, come istituito dalla legge 142/90 nell’articolo 8. A questa figura può ricorrere ad esempio un utente non vedete, data l'impossibilità di accedere a un bando in quanto il documento PDF non è correttamente formattato o è protetto in modo da renderlo di conseguenza inaccessibile anche ai lettori di schermo, oppure data la sua incapacità di accedere ad altre informazioni contenute nelle pagine Web dovuta, ad esempio all’impossibilità di ingrandire i caratteri. Il ricorso al Difensore Civico è previsto senza costi aggiuntivi per il cittadino. Per quanto riguarda i siti esistenti anche questi sono ormai anche loro sottoposti alla legge. Infatti, i contratti in essere alla data d’entrata in vigore del decreto, in caso di rinnovo o modifica sono adeguati, a pena di nullità, alle disposizioni della legge, con l'obiettivo di realizzare tale adeguamento entro dodici mesi dalla data di entrata in vigore del decreto pubblicato l’8/agosto/2005. Questa norma finisce per coinvolgere tutti i siti della pubblica amministrazione, in quanto è inevitabile, per il loro steso utilizzo, che essi debbano essere necessariamente aggiornati. A questa legge fanno eccezione i siti realizzati con risorse interne in quanto non facenti parte di contratti stipulati con società esterne. Una modifica a questa disposizione probabilmente sfuggita al legislatore è prevista con il recente secondo decreto Campa Palmieri di cui si accennerà in seguito. Indirettamente anche il codice della Pubblica Amministrazione Digitale ovvia a questo problema anche se con tempi più lunghi. Un'altra volontaria lacuna della legge è di non riguardare Bancomat e colonnine che restano non accessibili di base. In effetti, questo è stato probabilmente voluto dal legislatore che ha inteso ottenere l’accessibilità mantenendola nominalmente a costo zero. Le spese per rendere accessibili queste apparecchiature sarebbero state evidentemente molto rilevanti e la legge non avrebbe potuto essere promulgata con la stessa relativa facilità con cui invece ha ottenuto l’approvazione di tutto il parlamento. Del tema dei costi si è discusso in un capitolo dedicato di questo lavoro e a quello rimando, qui voglio solo ricordare che per raggiungere questo obiettivo, l’unico modo è quello di modificare il modo di lavorare chi produce siti Web formandoli fin da principio sulle metodologie del progetto WAI. Dispositivo Il testo integrale della Legge è riportato in appendice, fatti salvi gli omissis per quanto ritenuto poco attinente alla trattazione. In questa sede vorrei dare una rapida scorsa per sommi capi ai concetti guida dei vari articoli. - 256 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Articolo 1: Obiettivi e Finalità. Si ispira al principio fondamentale di uguaglianza dei cittadini, applicato in questo caso nel loro diritto di accedere alle fonti di informazione e ai servizi on line. Nel testo di legge si fa riferimento anche al software e all’hardware, oltre che ad internet e traendo la materia dalla precedente Section 508 della legislazione degli Stati Uniti. Articolo 2:Definizioni. Vengono forniti le necessarie definizioni in materia su accessibilità e tecnologie assistive. Un appunto mosso dai docenti del seminario alla definizione di accessibilità è stato quello che sembra mancare la dizione “in modo facile per tutti”. Ritengo però che i termini presenti nel resto del testo rendano inutile questa ulteriore aggiunta. Articolo 3:Destinatari. Un elenco degli enti destinatari della legge. Come si è detto, la legge riguarda essenzialmente gli enti pubblici. Tra queste vanno segnalate anche le aziende che hanno la maggioranza a partecipazione pubblica, come la Telecom Italia, o aziende che forniscono in appalto attrezzatura alla pubblica amministrazione. Sono esentati il corpo dei Carabinieri, l’esercito i N.A.S. ed altri enti che non possono avere disabili in servizio se non amministrativi. Tra le pubbliche amministrazioni si devono ricordare anche le scuole e le università. Articolo 4: Obblighi. Ci sono tre aspetti da considerare per gli Enti dell’Articolo 3.  Beni e servizi informatici;  Siti INTERNET;  Postazioni di lavoro. Il trattamento di questi tre aspetti è leggermente differente. Per quanto riguarda i beni ed i servizi informatici, i requisiti di accessibilità costituiscono motivo di preferenza a parità di ogni altra condizione nella valutazione dell'offerta tecnica. Hardware e software non devono necessariamente essere conformi, ma costituiscono motivo di preferenza nella valutazione. Resta comunque valido il principio del preesistente decreto legislativo 216/2003 discusso in precedenza, per cui, è possibile non acquistare uno screeen-reader in mancanza di un lavoratore disabile, ma non appena venga richiesto il personale deve essere messo in grado di svolgere le sue mansioni. - 257 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR A questo proposito va ricordato che negli Stati Uniti, fin dal 1999 tutto il software e tutto l’hardware è conforme alle normative della Section 508 e questo ha finito inevitabilmente per imporre degli standard effettivi nel materiale tecnico presente in commercio. I requisiti Web invece sono obbligatori. Gli Enti citati nell’articolo 3 non possono stipulare, a pena di nullità, contratti per la realizzazione e la modifica di siti Internet quando non è previsto che essi rispettino i requisiti di accessibilità. Con i vincoli già citati per quelli già esistenti che vengano modificati. Per sito internet si comprende anche una rete intranet. Chi adotta sistemi informativi interni che non siano a norma deve necessariamente renderli accessibili. Articolo 5: Didattica. Un aspetto innovativo di questa legge è che coinvolge anche gli istituti scolastici per quanto riguarda il materiale formativo e didattico tra cui ovviamente anche i libri di testo. Deve essere prevista la fornitura di copie su supporto digitale degli strumenti didattici fondamentali, accessibili agli alunni disabili e agli insegnanti di sostegno, nell'ambito delle disponibilità di bilancio. Articolo 6: Verifica. Al successivo regolamento di attuazione sono demandate le norme per la verifica del raggiungimento dell’accessibilità, tra cui l’esposizione del logo di conformità. Articolo 7: Compiti amministrativi. Il controllo di attuazione della legge è demandato al Dipartimento Innovazione e Tecnologie (DIT) avvalendosi del Centro nazionale per l'informatica nella pubblica amministrazione (CNIPA). Regioni e province autonome hanno il compito di vigilare sul loro territorio per l’attuazione della legge. Da notare un principio di incostituzionalità sollevato a proposito di questo articolo, risolto dalla Corte Costituzionale con l’annullamento della legge per le province autonome di Trento e Bolzano le quali hanno comunque promulgato una legge regionale apposita del tutto simile. Articolo 8: Formazione. La legge prevede un’attività formativa in merito effettuata con tecnologie accessibili. Le amministrazioni di cui all'articolo 3, nell'ambito delle disponibilità di bilancio, devono predisporre corsi di aggiornamento professionale sull'accessibilità. Nel seminario si è evidenziata l’estrema urgenza di un’attività formativa come previsto da quest’articolo. Purtroppo una tale attività formativa finisce per impattare - 258 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR direttamente contro il principio di costo zero dell’attuazione della legge e, con questo cavillo, tale articolo è stato facilmente disatteso. Se da un lato è opportuno che le amministrazioni comunali si attivino per creare un gruppo di lavoro interno, dall’altro è altrettanto vero che la maggior parte dell’attività formativa non può ragionevolmente essere fornita senza ulteriori aggravi economici sulle pubbliche amministrazioni. La regione dovrebbe organizzare in collaborazione con i comuni dei piani di aggiornamento dei siti Web. In genere tutte le amministrazioni centrali dovrebbero incominciare a pensare ad un processo di adeguamento, cercando anche di porsi in maniera costruttiva nei confronti della attività di formazione. Questo aspetto ha carattere fondamentale. Il pubblico dipendente o quantomeno lo stesso responsabile dell’accessibilità di ogni amministrazione dovrebbe ricevere entro tempi brevi un corso di formazione impartito dalle amministrazioni centrali. Una grossa lacuna in questo senso è stata registrata a livello delle Università, direttamente chiamate in causa per i corsi formativi. A distanza di anni le Università hanno fatto poco o nulla sul tema dell’accessibilità, né preparando dei corsi né fornendo materiale informativo1. In mancanza di un’attività formativa diretta è lasciata all’iniziativa del singolo l’istruzione in materia di accessibilità. Le fonti sono molteplici e possono essere rintracciate proprio sul Web. Sicuramente significativi a questo proposito sono proprio i siti istituzionali del W3C che contengono tutte le specifiche WAI. Un punto di partenza potrebbe essere il documento di accessibilità in dieci punti fornito dal consorzio2, per altro riportati e discussi in questa stessa tesi. Personalmente mi auguro che questo stesso lavoro possa servire a fornire una prima base formativa o quantomeno un punto di partenza per sviluppare il tema. A questo proposto consiglio di accedere alle risorse in rete elencate al termine di questo scritto. Articolo 9: Sanzioni. La legge prevede, in caso di inadempienza, responsabilità dirigenziale e responsabilità disciplinare. 1 A questo proposito segnalo la recente iniziativa del CNIPA in associazione con l’Università di Bologna per l’istituzione di un Master in accessibilità e multimodalità del web organizzato a Cesena il 17 Novembre 2006. 2 [http://www.w3.org/WAI/References/QuickTips/] - 259 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Questo allo scopo di muovere le acque a livello dirigenziale. Fino a che i dirigenti delle amministrazioni chiamate in causa non avranno acquisito la necessaria sensibilità personale al problema difficilmente la legge riuscirà a cambiare qualcosa. A questo proposito vorrei dire che la mia personale esperienza nell’ambito della pubblica amministrazione a più di due anni dall’entrata in vigore della legge conferma tutte le resistenze incontrate nella sua applicazione. Rimando le osservazioni ed i commenti alla relativa sezione di questa tesi. Di fronte ad un rilevante sforzo normativo ed a una forte spinta da parte del ministero a snellire la pubblica amministrazione si è andato incontro ad un vasto problema di attuazione. La pubblica amministrazione digitale è un esempio di quest’inerzia radicata. Le normative non sono mancanti da un punto di vista di responsabilizzazione dirigenziale. In effetti, il testo della legge sancisce che il contratto possa essere addirittura nullo e definisce anche delle precise responsabilità dirigenziali. In caso di inosservanza non solo vi è l’obbligo a correggere la situazione, ma anche il contratto è invalidato e il dirigente ne risponde in prima persona davanti alla Corte dei Conti. Questo dovrebbe stimolare il dirigente a motivare e sorvegliare i suoi dipendenti che vengono anche responsabilizzati nella realizzazione dell’accessibilità. Nel momento in cui uno di loro accetta un incarico, se ne assume anche le responsabilità. Il singolo dipendente può essere responsabile del codice che produce. Purtroppo spesso non si tiene abbastanza in considerazione il fatto che la qualifica richiesta per un simile onere non è indifferente, si richiedono competenze in diverse materie spesso riscontrabili solo in un gruppo qualificato di persone. Articolo 10: Regolamento di attuazione. Questo articolo stabilisce la definizione di un regolamento di attuazione entro 90 giorni dalla data di entrata in vigore della legge che definisca i criteri e i principi operativi e organizzativi generali per l'accessibilità, i controlli esercitabili sugli enti e le modalità di verifica. Il tutto previa consultazione con le associazioni delle persone disabili. Il regolamento è entrato in vigore il 18 Maggio 2005 definendo i responsabili dell’accessibilità. Costoro sono le persone preposte alla realizzazione concreta della legge ed hanno diritto a chiedere all’ente centrale di competenza l’organizzazione dei corsi di formazione creando un piano d’aggiornamento specifico per l’accessibilità di cui sono responsabili come definito sull’articolo 9. - 260 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Il regolamento di attuazione non è riportato in appendice ma può essere facilmente reperito sul sito del Ministero.1 Articolo 11: Requisiti tecnici. Si rimanda alla pubblicazione, entro 120 giorni dalla data d’entrata in vigore della legge delle linee guida recanti i requisiti tecnici ad opera del Ministro per l'innovazione e le tecnologie, previa consultazione con le associazioni delle persone disabili maggiormente rappresentative. Questi requisiti tecnici sono il cuore della legge dal punto di vista di questa tesi e verranno trattati in una sezione specifica successiva. Articolo 12: Evolvibilità. Un aspetto molto importante di questa legge è la sua possibilità di essere aggiornata negli aspetti tecnici, un aspetto essenziale, dato il rapido sviluppo della materia di cui tratta. Il decreto citato all’articolo 11 è periodicamente aggiornato, con la medesima procedura, per il tempestivo recepimento delle modifiche delle normative di cui al comma 1 e delle innovazioni tecnologiche nel frattempo intervenute. Come hanno fatto rilevare i docenti del seminario, si tratta di una novità a livello mondiale l’inserimento nel decreto delle regole tecniche con la previsione di un aggiornamento. La normativa americana è difficilmente aggiornabile ed è rimasta ferma al 2000. L’evoluzione del decreto è prevista tramite una verifica periodica dello stato di attuazione. Nello stesso articolo si ribadisce anche come sia il regolamento di cui all'articolo 10 che il decreto di cui all'articolo 11 siano stati emanati osservando le linee guida indicate nelle comunicazioni, nelle raccomandazioni e nelle direttive sull'accessibilità dell'Unione europea, nonché nelle normative internazionalmente riconosciute e tenendo conto degli indirizzi forniti dagli organismi pubblici e privati, anche internazionali, operanti nel settore. A tale proposito va però aggiunto che, di fatto, non ci sono stati aggiornamenti alla legge fino alla data di pubblicazione di questo lavoro, per quanto, come segnalato più avanti, si stia parlando di un secondo decreto correttivo Campa Palmieri. 1 [http://www.pubbliaccesso.it/normative/regolamento.htm] - 261 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Il motivo di questa attesa è probabilmente nella imminente uscita del dispositivo finale delle WCAG 2.0 a cui probabilmente un sostanzioso aggiornamento della legge Stanca potrà ispirarsi. Codice della Pubblica Amministrazione Digitale Il codice1 della Pubblica Amministrazione digitale è stato approvato con Decreto Legislativo del 7 marzo 2005, n. 82, ed aggiornato con le modifiche introdotte dal Decreto Legislativo2 del 4 aprile 2006 recante disposizioni integrative e correttive. E’ entrato in vigore il 1 Gennaio 2006 Il codice prevede l’obbligo per le Pubbliche Amministrazioni di riorganizzare i propri siti Internet in modo da individuare una serie di contenuti minimi e necessari, compresa la disponibilità di moduli e formulari per via telematica. Nell’intenzione del legislatore, la pubblica amministrazione digitale dovrebbe costituire un deciso passo in avanti nella direzione dell’efficienza e della trasparenza dei servizi al cittadino dopo quindici anni dall’approvazione della legge 142/90. Caratteristiche fondamentali: i siti pubblici devono essere accessibili da tutti, anche dai disabili, reperibili, facilmente usabili, chiari nel linguaggio, affidabili, semplici, omogenei tra loro. I siti Internet devono diventare la porta privilegiata per entrare nelle pubbliche amministrazioni e sono tenuti quindi a riportare alcuni dati necessari dell’ente per orientarsi:  L’organigramma per sapere chi fa cosa;  Gli indirizzi e-mail a cui rivolgersi per ciascuna necessità;  L’elenco dei servizi forniti in rete;  L’elenco di tutti i bandi di gara;  L’elenco dei procedimenti svolti da ciascun ufficio, con la loro durata e il nome del responsabile. La pubblica amministrazione digitale dovrà fornire tutti i servizi sportello, l’ufficio relazioni con il pubblico, il pagamento on line dell’I.C.I. Tutti i documenti all’interno delle amministrazioni centrali devono essere disponibili su formato digitale. Per il momento questo è obbligatorio solo per le amministrazioni centrali, ma entro 2 anni dall’entrata in vigore le norme dovrebbero essere estese ulteriormente anche a quelle decentrate. 1 2 [http://www.padigitale.it/home/testodecreto.html [http://www.innovazione.gov.it/ita/normativa/allegati/dl_050307.pdf] - 262 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Gli articoli 53 e 54 di questo documento riguardano anche le normative sui siti delle pubbliche amministrazioni centrali obbligandole a rispettare i principi di accessibilità, nonché di elevata usabilità e reperibilità, anche da parte delle persone disabili, di completezza di informazione, di chiarezza di linguaggio, di affidabilità, di semplicità di consultazione, di qualità, di omogeneità e di interoperabilità. Per l’articolo 54 si richiede che le amministrazioni che già dispongono di propri siti realizzano quanto previsto entro 24 mesi dall’entrata in vigore del decreto. Per l’articolo 76, le disposizioni del presente codice entrano in vigore a decorrere dal 1° gennaio 2006. Ci sono state richieste di proroga, ma le norme sono inderogabili. Come accennato in precedenza l’attuazione di questa normativa prevede, sempre per lo stesso articolo 76, che le pubbliche amministrazioni dovranno adeguare i siti internet ai criteri di accessibilità definiti nel regolamento di attuazione della legge 04/2004 anche se creano i siti internet con risorse interne e anche se il contratto non lo preveda espressamente. Va tenuto presente che, per quanto mi è dato a tutt’oggi da vedere, molte di queste progettualità sono state ampiamente disattese e le critiche che si sono registrate sono molteplici1, sia al testo della legge che alle sue modalità applicative. Lo stesso sito2 è risultato vuoto almeno per tutto il periodo di scrittura di questo lavoro. Regolamento di attuazione Il Regolamento di attuazione (Decreto del Presidente della Repubblica, 1 marzo 2005, n. 75) previsto all’articolo 10, approvato in Consiglio dei Ministri il 25 febbraio 2005, è stato pubblicato sulla Gazzetta Ufficiale del 3 maggio 2005 ed è in vigore dal 18 maggio 2005. Vi hanno collaborato le associazioni delle persone disabili, l’associazione degli sviluppatori competenti in materia di accessibilità e i produttori di hardware e software. L’iter di approvazione è stato piuttosto lungo ed elaborato. La legge ha dovuto passare molti ministeri e molti commissioni parlamentari. Per questo motivo i tempi si sono piuttosto dilatati. Articolo 1: Definizioni. Vengono ribaditi e definite alcuni concetti essenziali della legge. Tra cui spicca quello della verifica tecnica e soggettiva di cui tratta il regolamento. A questo proposito vale la pena ricordare che la verifica tecnica può essere facilmente eseguita internamente in 1 2 [http://www.studiocelentano.it/editorial/articolo.asp?id=1031] [www.padigitale.it] - 263 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR maniera autonoma, anche con degli opportuni valutatori automatici o seguendo una griglia di controllo per quanto sempre sotto la supervisione di un esperto. La verifica soggettiva invece non è obbligatoria. Nel caso si decidesse di applicarla essa deve essere eseguita solo presso il CNIPA. Uno stralcio di queste definizioni è riportato in appendice. Articolo 2: Criteri e principi generali dell’accessibilità. Analogamente al primo articolo si propongono i requisiti dei servizi accessibili. Si definisce il concetto di fruibilità ripreso dalla Norma ISO/IEC 9126 come:  Facilità e semplicità d’uso;  Efficienza nell’uso;  Efficacia nell’uso;  Soddisfazione nell’uso. Nel seminario è stato più volte ribadito il concetto di fruibilità come l’usabilità applicata sulla base dell’accessibilità. Uno stralcio di questi requisiti è riportato in appendice. Articolo 3: Valutazione di Accessibilità. Il valutatore deve dare garanzia di imparzialità ed indipendenza. Occorre disporre di figure professionali idonee e qualificate. Dalla figura professionale e dalle competenze richieste, il valutatore è una figura il cui operato richiede anche una certa onere di spesa. Per questo motivo il regolamento definisce un tetto massimo per le valutazioni con una cifra aggiuntiva per pagina. Esiste quindi un prezzario ufficiale per la valutazione. Alla data del seminario non era ancora stato istituito un albo ufficiale di valutatori e nessuno era ancora qualificato per questo intervento. L’albo dei valutatori è stato istituito successivamente con deliberazione CNIPA del 15 settembre 2005. Le pubbliche amministrazioni possono acquisire il parere non vincolante di un valutatore, ma nel seminario è stato fatto notare che, essendo obbligatorio produrre dei siti accessibili, non ha molto senso esporre il logo di base come disposto nell’articolo 5. Questa condotta le sottoporrebbe necessariamente ad una successiva attività di verifica e monitoraggio da parte del CNIPA. Se, ad ogni modo, l’amministrazione pubblica volesse mettere in evidenza la propria efficienza in merito, potrebbe rivolgersi ad un valutatore con l’obbligo di sostenerne le spese. Si potrebbe richiedere di avere anche una verifica soggettiva del sito, oltre che quella tecnica che potrebbe essere svolta in maniera autonoma. Stessa facoltà è data agli enti privati, che comunque restano del tutto esentati dall’obbligo di sottoporvi i propri siti. - 264 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Articolo 4: Modalità di richiesta della valutazione. Il logo di accessibilità è un marchio registrato del CNIPA e la sua esposizione deve essere autorizzata. I soggetti privati possono farne richiesta. Il logo vale per un anno, scaduto il quale è necessario ripetere la valutazione. Necessario ripetere la valutazione anche in caso di revisione sostanziale come indicato nell’articolo 6. Nel seminario è stato ribadito come il concetto del logo, il cosiddetto bollino, ha spesso spostato l’attenzione dal vero servizio fornito dalla validazione. Questo magari non tanto per quello del CNIPA, che non può essere esposto dai privati senza esplicito rilascio e valutazione ufficiale, quanto piuttosto per la gran quantità di bollini in circolazione certificati dai vari valutatori automatici su internet. Il problema è stato affrontato in una sezione apposita di questa tesi a cui si rimanda. Un altro punto essenziale di questo articolo è che all’attuazione del presente articolo si provvede nell’ambito degli ordinari stanziamenti di bilancio, senza nuovi o maggiori oneri per la finanza pubblica. Anche questo argomento è stato ampiamente discusso. Articolo 5: Logo attestante il possesso del requisito di accessibilità. Nelle figure sotto riportate sono mostrati i loghi definiti dal CNIPA. Il logo senza asterischi attesta il superamento della sola verifica tecnica, mentre gli altri indicano un valore ottenuto durante la successiva verifica soggettiva. Vengono riportati puramente a titolo di esempio. Ovviamente in questa sede non attesta nessuna validità di accessibilità per il documento corrente. Logo che risponde al primo livello di accessibilità, legato alla conformità ai requisiti previsti per la verifica tecnica: Figura 4 - Logo di conformità alla verifica tecnica Logo che corrisponde al livello di accessibilità che attesta il superamento della verifica tecnica e l’attribuzione, a conclusione della verifica soggettiva, di un valore medio complessivo pari o maggiore di 2 e minore di 3: - 265 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Figura 5 - Logo di conformità alla verifica tecnica e soggettiva primo livello Logo che corrisponde al livello di accessibilità che attesta il superamento della verifica tecnica e l’attribuzione, a conclusione della verifica soggettiva, di un valore medio complessivo pari o maggiore di 3 e minore di 4: Figura 6 - Logo di conformità alla verifica tecnica e soggettiva secondo livello Logo che corrisponde al livello di accessibilità che attesta il superamento della verifica tecnica e l’attribuzione, a conclusione della verifica soggettiva, di un valore medio complessivo maggiore di 4: Figura 7 - Logo di conformità alla verifica tecnica e soggettiva terzo livello Il CNIPA ha recentemente pubblicato una lista dei pochi siti internet che hanno raggiunto la validazione. Al Novembre del 2006 si possono contare solamente 23 istituzioni in grado di esporre questa qualifica. Un elenco completo è disponibile sul sito del ministero1. Articolo 6: Casi di aggiornamento della valutazione di accessibilità. Si definiscono le norme e la prassi per le situazioni di aggiornamento della valutazione di accessibilità. Articolo 7: Poteri ispettivi di controllo sui soggetti privati. Si definiscono le norme e i limiti dei poteri ispettivi di controllo sui soggetti privati. Articolo 8: Uso del logo per le pubbliche amministrazioni. 1 [http://www.pubbliaccesso.gov.it/logo/elenco.php] - 266 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR I soggetti della pubblica amministrazione che intendono utilizzare il logo sui siti e sui servizi forniti, provvedono autonomamente a valutare l’accessibilità sulla base delle regole tecniche definite con il decreto sui requisiti tecnici. La valutazione positiva, previa segnalazione al CNIPA, consente l’utilizzo del logo. Va segnalato che, anche in questo caso, come specificato nell’articolo 5, il logo senza asterischi è quello riservato per la valutazione tecnica. Articolo 9: Controllo delle Pubbliche Amministrazioni. Questo articolo ribadisce la definizione della figura del responsabile della accessibilità per ogni pubblica amministrazione, ruolo svolto, in mancanza di esplicita designazione, dal responsabile dei servizi informatici. In oltre, qualora siano riscontrate anomalie, viene richiesta all’amministrazione la predisposizione del relativo piano di adeguamento con l’indicazione delle attività da svolgere e dei tempi di realizzazione. Requisiti tecnici (Decreto Ministeriale 8 Luglio 2005) Sono stati approvati in via preliminare il 9 Luglio del 2004, ed il 1 Marzo 2005 sono stati firmati dal Presidente della Repubblica. Il decreto è stato emanato dal Ministero per le Innovazioni e le Tecnologie con atto del 8 Luglio 2005 ed è stato pubblicato sulla Gazzetta Ufficiale n. 183 dell'8 agosto 2005. Il contenuto del decreto sono i Requisiti tecnici come previsto dalla legge 04/2004 all’articolo 11. Il regolamento prevede che ci possano essere due tipi di verifiche, corrispondenti a quattro tipi di attestati: una tecnica e tre livelli di verifica soggettiva. La verifica tecnica è finalizzata ad ottenere l’accessibilità e conferisce l’esposizione del logo di validazione del CNIPA senza asterischi. La verifica soggettiva invece include anche un'analisi dell'usabilità del sito rispetto ad utenti disabili e conferisce il logo con asterischi (da 1 a 3). Accanto a queste valutazioni specifiche per i siti internet ne esistono altre per il software applicativo e per l’hardware. Esistono quindi tre diverse tipologie per i requisiti tecnici di accessibilità: 1 2  Requisiti per l’Hardware di computer (7 requisiti, in allegato1 C);  Requisiti per il Software Applicativo (11 requisiti, in allegato2 D); [http://www.pubbliaccesso.gov.it/normative/DM080705-C.htm] [http://www.pubbliaccesso.gov.it/normative/DM080705-D.htm] - 267 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Requisiti di accessibilità per i siti Internet (22 requisiti, in allegato1 A). I requisiti per la verifica tecnica dei siti Web sono quelli che più hanno rilevanza all’interno di questa trattazione. I requisiti hardware e software non sono obbligatori al momento dell’acquisto del materiale informatico, tuttavia costituiscono preferenza in appalto. Il concorrente che riesca a soddisfarne di più acquisisce un titolo preferenziale. I ventidue requisiti Web sono invece il nucleo del decreto ministeriale del 8 Luglio 2005 per quanto riguarda gli scopi di questa testi. Sono validi per i siti internet e sono obbligatori per tutte le pubbliche amministrazioni e per gli altri enti a partecipazione pubblica come specificato in appendice. Per i privati restano facoltativi. Si applicano anche ad intranet, ai CMS, agli applicativi di back-office ed in generale a tutti i contenuti che vengano visualizzati dai browser. I docenti del seminario di Arese hanno tenuto a preporre alla trattazione dei 22 requisiti del decreto, un preliminare requisito 0 della legge stanca, ovvero quello del buon senso nell’applicare le norme, perseguendone le finalità e non meramente le disposizioni formali. I 22 requisiti Web sono riportati in appendice. Il testo integrale del provvedimento è disponibile sul sito del ministero2. Requisiti Hardware (7) Requisiti tecnici di accessibilità per i personal computer di tipo desktop e portatili: 1. Requisito 1: “Il computer deve potersi collegare mediante canali standard a sistemi di accensione remota.”. Deve essere fornita al disabile una opportunità di accendere il computer con altre strumentazioni che non siano solamente il bottone di accensione sul cabinet. Al giorno d’oggi, soprattutto come conseguenza degli standard imposti dai produttori americani tra cui Dell, IBM e HP in prima linea, tutti i computer in vendita supportano questo requisito. Un sistema per l’attivazione ad infrarossi spesso è previsto addirittura sulle schede madri. Sono poche le macchine che non lo hanno o non lo supportano. Nella sezione del BIOS sono in oltre supportabili dei sistemi di attivazione (wake-up) configurabili anche per il vivavoce. Di fatto, risulta definita una procedura standard per l’accensione dei personal computer. 1 2 [http://www.pubbliaccesso.gov.it/normative/DM080705-A.htm] [http://www.pubbliaccesso.gov.it/normative/DM080705.htm] - 268 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 2. Requisito 2: “I tasti e i pulsanti devono essere raggiungibili ed operabili con minima abilità e con una forza massima di 2,3 Kg.”. Sono imposti dei vincoli per la pressione da esercitare sulle tastiere. Le tastiere moderne hanno un limite minimo di pressione a cui rispondono Anche in questo caso, tutte le tastiere sono già conformi a questo requisito. In aggiunta la tastiera deve essere anche configurabile per recepire le pressioni contemporanee di comandi in modo sequenziale, ad esempio per la combinazione CTRL+ALT+CANC. Questo tipo di funzionalità è svolta spesso dal sistema operativo a cui è delegata la funzione. In oltre deve esistere anche uno spazio fra i tasti sufficiente affinché possano essere operabili e raggiungibili. 3. Requisito 3: “I tasti e i pulsanti devono essere tattilmente percepibili, senza necessità di attivarli.”. Deve essere sempre possibile percepire la tastiera. In tutte le tastiere moderne sono presenti sul tasto della lettera “F“ e sul tasto della lettera “J” dei rilievi in modo che possa essere sempre possibile percepirle senza attivarla, tutte le tastiere sono a norma, per merito della Section 508, già dall’anno 2000. 4. Requisito 4: “In presenza della funzionalità di ripetizione dei tasti, l’intervallo di tempo sia per la prima ripetizione che per le ripetizioni successive, deve essere configurabile in almeno 2 secondi.”. La tastiera deve essere configurabile per la ripetizione, l’utente in oltre deve poter configurare l’intervallo di ripetizione tasti in un intervallo di almeno due secondi. L’interazione tra l’hardware e il software deve permettere il fatto che il tasto premuto venga memorizzato per qualche istante di tempo ed eventualmente ripetuto dopo un lasso di tempo definibile dall’utente. Queste informazioni sono preconfigurate nel BIOS. 5. Requisito 5: “Il diverso stato di attivazione dei tasti selezionati o bloccati deve essere percepibile, oltre che visivamente, anche attraverso il tatto o l’udito.”. Si tratta di non veicolare ad un solo canale sensoriale la notificazione dello stato della tastiera. In pratica il fatto che, ad esempio, l’utente inserisca il caps lock non deve essere notificato solamente da un avviso luminoso, ma deve essere possibile, anche da sistema operativo, attivare l’emissione di un suono come notifica per il cambiamento di stato. Anche questo requisito, in pratica risulta sempre soddisfatto. 6. Requisito 6: “Deve essere presente almeno una porta di comunicazione conforme agli standard industriali.”. Deve essere possibile ai disabili inserire schede speciali adatte per la loro disabilità. In pratica è sufficiente che sia presente sul computer almeno una porta conforme agli standard industriali per avere la possibilità di collegare un hardware esterno. - 269 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 7. Requisito 7: “Qualora venga utilizzata una forma di identificazione biometrica, deve essere fornita una forma alternativa di identificazione.”. Dal momento che ad un disabile potrebbe mancare qualche funzionalità fisiologica specifica, si richiede di non fornire un hardware che consenta di identificarsi ad esempio solo con un impronta digitale. In caso di rilevazioni biometriche occorre fornire contemporaneamente più sistemi per l’accesso. Requisiti Software (11) 1. Requisito 1: “Le funzioni previste dall’interfaccia utente devono poter essere attivate anche attraverso comandi da tastiera nei casi in cui possa essere fornita una descrizione della funzione stessa o del risultato della sua esecuzione.”. Deve essere sempre possibile utilizzare le funzionalità implementate nel software anche solamente da tastiera. Questa richiesta è direttamente ricavata dalla Section 508 che possiede un requisito analogo nel paragrafo 1192.21. In oltre, occorre fornire dei tasti di scelta rapida in modo che il software possa svolgere tutte le sue funzionalità anche da tastiera. In pratica anche le funzionalità offerte da tutti i bottoni grafici e dall’interfaccia devono essere raggiungibili da tastiera. Anche le barre di scorrimento devono essere accessibili tramite comandi da tastiera. Non ci devono essere delle funzionalità attivabili esclusivamente attraverso il mouse. In alcuni software commerciali esistono degli oggetti per i quali, fin quando non sono attivati con il mouse, non è possibile lavorarci, questi software sono inaccessibili per il primo requisito. 2. Requisito 2: “Comandi e funzionalità dell’interfaccia utente non devono limitare o disabilitare le caratteristiche e le funzionalità di accessibilità dell’ambiente operativo documentate e rese disponibili dal produttore dell’ambiente stesso.”. In pratica non si devono sovrapporre le funzionalità standard del sistema operativo, come ad esempio i classici CTRL-V o CTRL-C. Questo punto è piuttosto delicato data la molteplicità di funzionalità offerte dai vari sistemi. Un’utile raccolta d’informazioni e supporto a questi comandi possono essere reperiti sui manuali del sistema o anche in rete1. In oltre ci si dovrebbe affidare alle API (Application Program Interface) previste dal sistema per ogni funzionalità dell’applicazione. 1 [http://www.tiresias.org/guidelines/software.htm] - 270 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 3. Requisito 3: “L’applicazione deve rendere disponibili sufficienti informazioni, quali gli elementi identificativi, le operazioni possibili e lo stato, sugli oggetti contenuti nell’interfaccia utente affinché le tecnologie assistive possano identificarli interpretandone le funzionalità.”. Richiede di fornire delle informazioni di tipo testuale per ogni elemento nell’interfaccia come ad esempio lo stato attivo, disattivo, attivabile, in modo da consentirne l’individuazione e l’attivazione/disattivazione anche agli utenti che utilizzano tecnologie assistive o modalità di input tramite tastiera. In pratica deve essere possibile avere una percezione dello stato del sistema. Ad esempio, se esiste un pulsante con un’icona che invoca una certa operazione quando premuto, questo bottone deve essere percepibile anche in maniera testuale. Ogni oggetto presente in un’interfaccia dovrebbe essere identificabile dall’ambiente operativo che, tramite API, consente alle tecnologie assistive di identificarne le caratteristiche. Microsoft Windows adempie a questo requisito tramite l’implementazione delle MSAA API (Microsoft Active Accessibility), come descritto in un capitolo di questo documento. L’utente disabile deve essere a conoscenza dell’esistenza e dello stato di un pulsante che svolge una qualche funzionalità non replicata altrove. Questo è anche lo scopo di alcuni suggerimenti a comparsa che recano un testo alternativo. 4. Requisito 4: “Nel caso di simboli grafici utilizzati per identificare controlli, indicatori di stato o altri elementi di programma, il significato assegnato a tali simboli deve essere coerente nell’ambito dell’intera applicazione, ivi compresa l’interfaccia utente.”. Quando simboli grafici sono utilizzati per identificare controlli il significato assegnato a tali simboli deve essere coerente nell’interfaccia utente. Questo requisito afferma che se viene presentata una icona in qualche punto, questa non può mutare di significato in una parte differente. Una richiesta che si applica anche per i suoni e non solo per le immagini. 5. Requisito 5: “Le informazioni di tipo testuale devono essere fornite utilizzando le funzionalità dell’ambiente operativo previste per la visualizzazione del testo; in particolare devono essere disponibili il contenuto testuale, la locazione del punto di inserimento e gli attributi del testo.”. Questo significa che dove presente un testo non si deve fornire una sua immagine grafica, ma il testo stesso. Questo per il fatto che le tecnologie assistive non riescono ad estrarre il testo dalla grafica. 6. Requisito 6: “L’applicazione che utilizza segnalazioni audio deve prevedere una funzionalità equivalente di tipo visivo, seguendo le eventuali convenzioni dell’ambiente operativo.”. Un’attuazione del principio della multi-modalità. L’applicazione che prevede segnalazioni di avvertimento basate su audio deve - 271 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR prevedere una funzionalità equivalente di tipo visivo, seguendo le convenzioni dell’ambiente operativo, se previste. 7. Requisito 7: “Per fornire informazioni, per indicare o per richiedere azioni non devono essere utilizzati unicamente animazioni, elementi grafici o sonori e differenze di colori.”. Anche in questo caso troviamo un esplicito richiamo al principio della multi-modalità. Si richiede di utilizzare più canali sensoriali per veicolare le informazioni. In oltre deve essere anche possibile anche interrompere il flusso del canale su richiesta utente predisponendo dei controlli. 8. Requisito 8: “Le applicazioni non devono sovrapporsi alle scelte effettuate dall’utente riguardo a livelli di contrasto, colori ed altri attributi di visualizzazione.”. Si richiede di non variare le impostazioni del colore assegnate al sistema operativo e di controllare la conformità degli elementi di interfaccia. Il fatto di mantenere le impostazioni di grafica e colore come sono state impostate dall’utente permette al disabile di continuare a lavorare con le configurazioni adatte alla propria menomazione. In alternativa occorre permettere al software di ereditare le impostazioni di sistema. La verifica pratica dell’adempimento a questa richiesta è molto semplice, è sufficiente andare su pannello di controllo e cambiare tema, verificando che anche il software cambi coerentemente. 9. Requisito 9: “L’interfaccia utente non deve contenere elementi di testo, oggetti o altri elementi lampeggianti aventi una frequenza di intermittenza maggiore di 2Hz e minore di 55Hz.”. L’interfaccia utente non deve avere oggetti che producano crisi epilettiche. L’intervallo di frequenza per crisi epilettiche varia tra 2 e 55 Hertz seguendo quanto specificato nelle normative americane. Microsoft Office ha eliminato del tutto gli effetti di animazione nel rilascio dei suoi ultimi prodotti. 10. Requisito 10: “L’elemento attivo (focus) di una interfaccia utente deve essere chiaramente identificabile; la identificazione e la variazione del focus devono essere segnalate a livello di interfaccia di programmazione (API) affinché le tecnologie assistive possano gestirle; vanno altresì adeguatamente segnalati gli elementi che richiedono obbligatoriamente un’azione da parte dell’utente.”. Il focus è la posizione del cursore sullo schermo, deve essere ben definito ed esposto a livello di interfaccia di programmazione in modo che le tecnologie assistive possano rilevarlo. Un modo di visualizzarlo in un’interfaccia grafica è il cartiglio o bubble, un suggerimento a comparsa che generalmente appare quando ci si passa sopra con il mouse. Si devono usare le API del sistema operativo per gestirlo e deve essere possibile assegnare il focus a qualsiasi oggetto che rappresenti una informazione per l’utente. Non sempre questa funzionalità era garantita nei software più datati. - 272 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 11. Requisito11: “La documentazione di supporto al prodotto e le caratteristiche di accessibilità devono essere rese disponibili anche in formato elettronico accessibile.”. Ad esempio può essere in PDF purché tale documento sia formattato in maniera corretta. A differenza dei requisiti hardware che sono oggi generalmente tutti soddisfatti, quelli software sono stati spesso disattesi in passato e anche al momento attuale sono pochi i grossi pacchetti applicativi in commercio che siano in grado di soddisfarvi. Secondo i docenti del seminario, fino al Maggio 2005, Microsoft Office era l’unico pacchetto da ufficio pienamente compatibile con gli 11 requisiti. Il progetto Open Office ne rispettava solo 7 ed era ancora incompatibile anche con le Section 508 del governo americano. Microsoft era in regola per la maggior parte degli applicativi. Tra gli altri pacchetti software di qualità erano da segnalare anche GoLive e DreamWeaver. Tra le grosse aziende produttrici quelle che maggiormente si distinguevano in fatto di accessibilità erano IBM, Microsoft e Adobe con l’acquisto di Macromedia, da sempre le più attente al problema. Adobe GoLive obbliga di fatto all’accessibilità, ripulendo automaticamente il codice dai marcatori scorretti o male annidati e producendo direttamente i CSS. Requisito Internet 1: Uso delle grammatiche. “Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da grammatiche formali pubblicate, nelle versioni più recenti disponibili quando sono supportate dai programmi utente. Utilizzare elementi ed attributi in modo conforme alle specifiche, rispettandone l'aspetto semantico [...].” Si tratta del requisito base del decreto ministeriale1. Il primo requisito fonde diversi principi di accessibilità in un solo enunciato. I numerosi riferimenti alle direttive WAI (WCAG 1.0: 3.1, 3.2, 3.5,3.6, 3.7, 11.1, 11.2) ne sono una evidente testimonianza. La richiesta di scrivere del codice semanticamente valido obbliga anche alla correttezza e alla pulizia della pagina. Questo requisito da solo, porta in sé, di fatto, gran parte dell’accessibilità e indirizza facilmente sulla strada giusta per il superamento dei requisiti tecnici. Per pagine e oggetti al loro interno, si intendono non solo i documenti (X)HTML ma anche ActiveX, applet java ed oggetti in Flash eventualmente contenuti in esso. Per grammatica 1 Luca Mascaro: [http://www.webaccessibile.org/argomenti/argomento.asp?cat=532] - 273 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR formale pubblicata si intende un documento testuale, delle specifiche riconosciute o anche i dell’XHTML. In pratica il requisito afferma che non è possibile non impiegare il formalismo, è obbligatorio utilizzare gli standard riconosciuti e diffusi. Quindi non si possono realizzare pagine od oggetti Web senza dichiararne la conformità a qualche specifica, anche se implicita come per i file Adobe Acrobat o Microsoft Word. Per quanto riguarda la conformità alle grammatiche formali, occorre ricordare che grammatica formale in informatica non è nient’altro che una specifica o una raccomandazione tecnica definita o in linguaggio naturale (documentazione) oppure in un linguaggio di definizione come una DTD (document type definition) SGML oppure un XML Schema. La conformità varia a dipendenza del tipo di definizione. Se per esempio prendiamo una normale pagina Web che è definita in HTML o XHTML, la sua definizione è un file DTD. Se invece fosse adottata una tecnologia descritta solo con un linguaggio naturale, dovremmo semplicemente seguire le direttive in essa definite. Questo vale per esempio per le specifiche di accessibilità dei documenti Acrobat dell’Adobe o Word della Microsoft. La richiesta di adottare sempre le versioni più recenti disponibili quando supportate dai programmi utenti, riporta direttamente all’evoluzione degli standard e delle raccomandazioni tecniche che appena vengono supportate dalla maggior parte dei programmi utente andrebbero adottate per le nuove risorse Web prodotte. L’argomento è stato trattato nel capitolo sulle tecnologie obsolete. Il CNIPA con la possibilità di aggiornare annualmente il decreto segnalerà quali versioni di un determinato formato o linguaggio sono considerate supportate dai programmi utente. L’ultima parte dell’enunciato richiede anche che il sito utilizzi tutti gli elementi specificati nel linguaggio formale in maniera opportuna. Ad esempio, l’uso corretto degli acronimi, come trattato in un paragrafo specifico delle metodologie generali. Dati questi presupposti si richiede per tutti i siti di nuova stesura, che vengano prodotti documenti in HTML, (possibilmente in XHTML) utilizzando esclusivamente la compatibilità STRICT. Per un anno almeno è consentito l’utilizzo di grammatiche TRANSITIONAL per siti esistenti, con alcuni vincoli e l’obbligo di predisporre un piano di adeguamento. La scelta di richiedere un linguaggio nella versione STRICT deriva semplicemente dal fatto che le versioni TRANSITIONAL delle specifiche in realtà sono state predisposte solamente per retro compatibilità. Le future versioni XHTML sono quelle considerate “pure” e corrispondono alle versioni STRICT. Tra gli attributi eliminati c’è il parametro TARGET per aprire le nuove finestre per le motivazioni già indicate nella sezione delle metodologie. Un importante punto di controllo di questo primo requisito richiede che quando esiste un linguaggio di marcatura adatto, per veicolare informazione vada impiegato il marcatore piuttosto che le immagini. Quindi, occorre conoscere una grammatica formale per una specifica - 274 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR applicazione (ad esempio mathML) ed usarla ogni qual volta sia necessario, in luogo delle immagini che sono illeggibili dagli screen-reader. Altro richiamo essenziale è quello di usare elementi di intestazione per veicolare la struttura del documento e usarli in modo conforme alle specifiche. In pratica la strutturazione del documento va realizzata con gli appositi marcatori (ad esempio H1, H2 .. H6, utilizzati opportunamente in sequenza), e non con tecniche di evidenziazione ad hoc. Questo per l’importante principio di separazione fra contenuto e presentazione, come descritto nel capitolo sull’utilizzo degli elementi strutturali. La verifica e la validazione di una pagina HTML trova un utile supporto nei validatori automatici forniti dai vari enti di normalizzazione o raccomandazione come il W3C, che però ricorda come questi strumenti possano essere solo di supporto. Per esempio, il validatore HTML del W3C è in grado di effettuare solo un controllo sull’annidamento corretto degli elementi e sull’uso dei relativi attributi ma non sul corretto uso semantico e logico degli elementi nonché sui valori inseriti negli elementi o attributi che andranno dunque verificati manualmente. Altre verifiche possono essere compiute anche visivamente, soprattutto con l’ausilio della barra dell’accessibilità con la quale spesso è possibile guardare la pagina e verificare ad occhio nel codice come sono marcati per esempio acronimi e le abbreviazioni. Per quanto riguarda la validazione ufficiale che verrà effettuata al CNIPA, i due docenti del seminario, membri attivi del comitato di valutazione, hanno rimarcato il fatto che eseguiranno i controlli tenendo conto del fatto che l’HTML, come molti altri linguaggi può subire ulteriori trasformazioni in corso di elaborazione tramite linguaggi come JavaScript e DOM, questo ci porta a non basare la loro validazione sul file HTML sorgente ma sul risultato finale dopo che tutte le trasformazioni sono state eseguite. Requisito Internet 2: Uso dei frame. “Non è consentito l’uso dei frame nella realizzazione di nuovi siti. In sede di prima applicazione, per i siti Web esistenti già realizzati con frame è consentito l’uso di HTML 4.01 o XHTML 1.0 con DTD frameset […].”. Evitare l’uso dei frame. Per i siti già realizzati con frame occorre evitare gli attributi presentazionali, ed utilizzare titoli significativi per i frame che indichino il loro scopo. In oltre occorre progettare un piano di transizione ad grammatica formale di tipo STRICT che eviti l’utilizzo dei frame ed inviarlo ad ministero per le Innovazioni e la Tecnologia. Per le amministrazioni centrali, il piano deve essere presentato e concordato con il CNIPA. La barra dell’accessibilità è in grado di fornire il controllo completo di tutti gli elementi. Si può verificare, per ogni frame, i valori degli attributi NAME e TITLE in modo da controllare che, se esitano, siano stati nominati correttamente come richiesto dalla legge. - 275 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Requisito Internet 3: Alternative testuali. “Fornire una alternativa testuale equivalente per ogni oggetto non di testo presente in una pagina e garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi contenuti equivalenti predisposti […].” In pratica si richiede che almeno venga aggiunto un attributo ALT per ogni immagine presente. Ricadono in questa categoria anche immagini sensibili (mappe), rappresentazioni grafiche di testo (compresi i simboli), animazioni (ad es.GIF animate), applet e oggetti, ASCII-art, frame, script, suoni (azionati con o senza l'intervento dell'utente), file di solo audio, tracce audio di video (multimedia) e video. L’argomento è stato trattato in una sezione dedicata di questa tesi. Qui ricordo che l’alternativa testuale deve essere descrittiva e riportare la funzionalità dell’oggetto più che il suo aspetto. Quando la descrizione è necessariamente molto lunga può valere la pena di usare l’attributo LONGDESC che collega l’oggetto ad un file descrittivo esterno. Aspetto significativo è che si richiede un opportuno aggiornamento dell’informazione in caso di sincronizzazione con nuovi contenuti. Occorre infatti garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi testi alternativi. In questo caso la sincronizzazione implica che se un per un ricaricamento della pagina l’immagine viene cambiata allora di conseguenza deve venire cambiato anche il contenuto testuale fornendo una diversa descrizione associata. Ancora una volta la barra dell’accessibilità risulta molto utile per visualizzare immediatamente i testi associati fornendo un elenco dettagliato di immagini con tutti i testi alternativi. Requisito Internet 4: Uso del colore. “Garantire che tutti gli elementi informativi e tutte le funzionalità siano disponibili anche in assenza del particolare colore utilizzato per presentarli nella pagina.”. Non affidarsi unicamente al colore. Un esempio classico per un sito di una istituzione pubblica sono gli avvisi dei bandi di gara, spesso si trovano in rosso quelli che stanno per scadere senza fornire un'altra valida segnalazione accessibile, non bisogna basarsi esclusivamente sul colore per nessuna informazione significativa ai fini della trasmissione del contenuto. Questo tipo d’attenzione va posta anche per le voci del menu. Se, ad esempio, una voce di menu si basa esclusivamente sul colore per evidenziare il fatto che sia attiva, questo viola il requisito 4. Una verifica è facile da eseguire utilizzando la barra accessibilità. Ad esempio si può togliere il colore e impostare la visualizzazione in scala di grigi. Ricordo che, per quanto utile, questo test - 276 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR non è ad ogni modo sufficiente. Molto utile è la funzionalità che permette di rimandare alla creazione di pagine relative preparate per la simulazione dei difetti visivi. Questo requisito è strettamente legato al requisito 6. Requisito Internet 5: Lampeggiamenti. “Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di intermittenza possano provocare disturbi da epilessia fotosensibile o disturbi della concentrazione, ovvero possano causare il malfunzionamento delle tecnologie assistive utilizzate; qualora esigenze informative richiedano comunque il loro utilizzo, avvertire l’utente del possibile rischio prima di presentarli e predisporre metodi che consentano di evitare tali elementi.”. Evitare gli sfarfallamenti e le scritte in movimento. Evitare in oltre anche gli oggetti o scritte lampeggianti. Anche per persone normodotate, gli oggetti lampeggianti possono distogliere dalla lettura, per di più possono arrivare fino a causare problemi per utenti con disabilità cognitive o indurre crisi epilettiche in soggetti ipersensibili. In caso di necessità occorre avvertire l’utente in una pagina precedente e, nel caso lo desiderasse, permettere di evitarle o di bloccare gli scorrimenti. Il capitolo delle metodologie tratta l’argomento in un paragrafo apposito sui lampeggiamenti degli oggetti. Requisito Internet 6: Contrasto. “Garantire che siano sempre distinguibili il contenuto informativo (foreground) e lo sfondo (background), ricorrendo a un sufficiente contrasto (nel caso del testo) o a differenti livelli sonori (in caso di parlato con sottofondo musicale); evitare di presentare testi in forma di immagini […].”. Utilizzare un contrasto adeguato sia per le immagini che per testi e per i contenuti audio. Occorre garantire che siano sempre distinguibili il contenuto informativo e lo sfondo. Ad esempio la voce in un’intervista deve essere ben distinguibile, oppure evitare di usare colori chiari su fondo chiaro o colori scuri su fondo scuro. Per quanto riguarda l’uso del colore questo punto è discusso anche nel requisito 4 ed è stato analizzato nelle metodologie generali. Un sistema per gestire questo problema è di approntare dei fogli di stile appropriati in modo che ogni utente possa adattare i colori alle proprie problematiche. La verifica si esegue con gli appositi validatori citati. - 277 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Nel corso è stata fatta notare la dovuta critica alle WCAG 1.0 che hanno posto come punto di controllo di terzo livello la richiesta di avere un adeguato contrasto fra testo e sfondo, come se fosse un interesse facoltativo quello di consentire la lettura di testi a persone con disabilità visive. Interessante il fatto che la differenza di contrasto venga rimarcata anche per i contenuti audio, una considerazione ripresa anche nelle WCAG 2.0. Requisito Internet 7: Mappe lato client. “Utilizzare mappe immagine sensibili di tipo lato client piuttosto che lato server, salvo il caso in cui le zone sensibili non possano essere definite con una delle forme geometriche predefinite indicate nella DTD adottata.” Preferire le mappe immagini lato client. Questo per il fatto che le mappe lato server inviano le coordinate del mouse al server e non sono accessibile a chi utilizza browser testuali che non emulano il movimento e le funzionalità del dispositivo di puntamento. Le eccezioni sono dovute alla necessità di definire delle aree più accurate che non siano disponibili con gli elementi di base delle mappe lato clienti, rettangolo, cerchio e figura poligonale. Uno degli ambiti di applicazione di questo requisito è quello della cartografia la cui realizzazione lato server è praticamente irrealizzabile a causa dei problemi di gestione alternativa del mouse. Una verifica di accessibilità può essere opportunamente realizzata ancora una volta con la barra di accessibilità che dispone di una specifica voce di controllo. Requisito Internet 8: Mappe lato server. “In caso di utilizzo di mappe immagine lato server, fornire i collegamenti di testo alternativi necessari per ottenere tutte le informazioni o i servizi raggiungibili interagendo direttamente con la mappa.”. Utilizzo di collegamenti ridondanti per le mappe lato server. Si tratta di un requisito che rende in pratica impossibile l’utilizzo di mappe lato server nel caso di una gran mole di informazioni. Per creare una mappa immagine sul lato server è necessario disporre di un’immagine in qualunque formato supportato (preferibilmente formati non proprietari), di un codice HTML/XHTML valido e soprattutto di un file di mappa immagine che definisce l’azione delle aree sensibili. - 278 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Nel caso sia necessario utilizzare un’immagine sensibile lato server, è necessario utilizzare dei collegamenti testuali che garantiscano funzionalità equivalenti. Occorrerebbe fornire tutte le informazioni con dei collegamenti alternativi di tipo testuale. Fare siti accessibili in queste condizioni risulta estremamente dispendioso e lungo, soprattutto per quanto riguarda il controllo di tutti gli aggiornamenti. Difficile, quindi, se non impossibile fare siti accessibili con cartografie a causa dei problemi e dei costi enormi che non possono essere nemmeno risolti con mappe lato client, inadatte per ottenere la sufficiente granularità utilizzando le forme geometriche di base. Requisito Internet 9: Tabelle dati. “Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti dalla DTD adottata per descrivere i contenuti e identificare le intestazioni di righe e colonne.”. L’uso delle tabelle dati è un argomento di cui si è parlato diffusamente nelle metodologie generali ed anche il decreto ministeriale italiano prevede dei requisiti per tabelle dati e per quelle d’impaginazione. In particolare per le tabelle dati richiede di usare gli elementi e gli attributi previsti dalla grammatica formale del documento. I marcatori opportuni a cui si riferisce la legge sono ad esempio l’attributo CAPTION utilizzato per fornire un titolo, o l’attributo SUMMARY impiegato come una guida all’utente sul contenuto. Altri elementi suggeriti sono gli elementi di scope, come HEADER e gli ID, con un loro corretto utilizzo i programmi utente sono in grado di ripetere le corrette dizioni di intestazione per ogni cella. La barra di accessibilità fornisce informazioni dettagliate anche su tabelle per evidenziarne chiaramente la struttura. Un ottimo modo per implementare dei test sull’accessibilità delle tabelle dati, è quello di utilizzare JAWS con una scheda audio. L’ideale sarebbe avere a disposizione anche persone con disabilità che testano il sito con i loro strumenti hardware, il software da solo è insufficiente in quanto dipende molto dalla capacità di saperlo utilizzare. Requisito Internet 10: Tabelle dati complesse. “Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti nella DTD adottata per associare le celle di dati e le celle di intestazione che hanno due o più livelli logici di intestazione di righe o colonne.”. Per tabelle dati molto complesse si intendono soprattutto quelle che possiedono due o più livelli logici di intestazione di riche o colonne, - 279 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Per queste, oltre ad applicare le norme relative al requisito precedente interenti tutte le tabelle dati, occorre porre alcune attenzioni aggiuntive, in particolare si devono usare gli opportuni elementi THEAD, TFOOT, e TBODY per raggruppare le righe in entità omogenee e COL, COLGROUP per raggruppare le colonne. Ancora una volta la barra di accessibilità viene in aiuto per visualizzare a colpo d’occhio la struttura di una tabella complessa. Requisito Internet 11: Fogli di stile. “Usare i fogli di stile per controllare la presentazione dei contenuti e organizzare le pagine in modo che possano essere lette anche quando i fogli di stile siano disabilitati o non supportati.”. I fogli di stile vanno usati per controllare la presentazione dei contenuti secondo il principio della divisione tra contenuti ed aspetti presentazionali come descritto accuratamente nelle metodologie. In pratica si tratta di non inserire formattazioni ed elementi di grafica testuale all’interno del file (X)HTML ma di riportarli all’interno dei fogli di stile. I relatori del seminario di Arese hanno voluto ricordare questo proposito che l’utilizzo di fogli di stile inclusi all’interno del (X)HTML non è consentito dalla normativa italiana. In oltre Le pagine devono poter essere lette anche con i fogli di stile disabilitati. Per verificare il requisito si utilizza la barra dell’accessibilità disattivando i CSS per verificare facilmente anche ad occhio se, leggendola in linea, la pagina rimarne comprensibile. Si possono disattivare separatamente sia i fogli di stile inline che quelli esterni. Occorre ricordare che con i fogli di stile è possibile visualizzare delle sezioni della pagina anche in ordine sensibilmente differente rispetto a come si presentano nel testo (X)HTML. Requisito Internet 12: Impaginazione. “La presentazione e i contenuti testuali di una pagina devono potersi adattare alle dimensioni della finestra del browser utilizzata dall’utente senza sovrapposizione degli oggetti presenti o perdita di informazioni tali da rendere incomprensibile il contenuto, anche in caso di ridimensionamento, ingrandimento o riduzione dell’area visualizzazione o dei caratteri rispetto ai valori predefiniti di tali parametri.”. I contenuti della pagina devono potersi adattare alle dimensioni della finestra senza causare sovrapposizione. Deve essere possibile una visualizzazione comprensibile anche ridimensionando finestra e i caratteri in modo flessibile. Questa disposizione favorisce sicuramente i cosiddetti layout liquidi, ad ogni modo non sono vietati gli altri. Si raccomanda di utilizzare misure relative dei caratteri piuttosto che quelle assolute, come spiegato nelle metodologie generali. - 280 - di ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR I docenti del seminario hanno precisato che in sede di valutazione CNIPA il test sarà che le pagine siano leggibili con risoluzione di 800 per 600 pixel, utilizzando i caratteri molto grandi. Per la verifica si controllerà che non si sovrappongono le scritte o gli elementi. Il requisito à pensato per le categorie di utenti ipovedenti. Costoro sono costretti ad aumentare notevolmente la grandezza dei caratteri, di conseguenza occorre controllare che in tal caso non si perda o si confonda l’informazione fornita. Un’interessante tecnica di test è quella di utilizzare un apposito servizio messo a disposizione su internet. Browser Cam1 consente di eseguire numerosi test multi piattaforma incrociando differenti programmi utenti. Per utilizzare il servizio si fornisce l’indirizzo del sito e si ottiene come risposta una quantità immagini ottenute impiegando svariati i caratteri, in diversi sistemi operativi e con molteplici browser. I dati di ritorno di questo test possono essere costituiti anche di un migliaio di immagini per singola pagina. Requisito Internet 13: Tabelle di impaginazione. “In caso di utilizzo di tabelle a scopo di impaginazione, garantire che il contenuto della tabella sia comprensibile anche quando questa viene letta in modo linearizzato e utilizzare gli elementi e gli attributi di una tabella rispettandone il valore semantico definito nella specifica del linguaggio a marcatori utilizzato.”.” La prima cosa da dire è che tabelle a scopo di impaginazione non sono esplicitamente vietate dalla normativa italiana la quale, con questo enunciato, si mantiene in linea anche con le raccomandazioni del W3C e con le ultime disposizioni delle WCAG 2.0 che consentono l’uso di questi strumenti a fini presentazionali. Ad ogni modo i docenti del seminario hanno precisato che la tendenza futura sarà quella di arrivare ad eliminarle del tutto per questi scopi. Allo stato attuale delle cose, la richiesta fondamentale, in caso si decidesse di usarle, è che il contenuto sia comprensibile quando la tabella viene letta in modo linearizzato. Una lettura linearizzata si rifà direttamente al codice (X)HTML leggendo la tabella nell’ordine dei testi esposti all’interno della pagina sorgente. Nel caso si utilizzasse una tabella per scopi d’impaginazione è importante non utilizzare alcun marcatore di struttura a scopo di formattazione per non indurre i lettori a degli errori d’interpretazione. 1 [http://www.browsercam.com/] - 281 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Una valutazione con la barra dell’accessibilità permette di visualizzare i tag relativi alla tabella e di visualizzarla anche i maniera lineare. Requisito Internet 14: Moduli. “Nei moduli (form), associare in maniera esplicita le etichette ai rispettivi controlli, posizionandole in modo che sia agevolata la compilazione dei campi da parte di chi utilizza le tecnologie assistive.” Si tratta di una richiesta piuttosto agevole da ottemperare. Alcuni dubbi possono essere sollevati sull’opportunità di compilare i campi con degli opportuni segnaposto come discusso nelle metodologie e, di fatti, la legge italiana non richiede questa procedura limitandosi alla richiesta di una necessaria e corretta associazione esplicita delle etichette. La barra dell’accessibilità permette di controllare facilmente e di visualizzare queste correlazioni esplicite. Requisito Internet 15: Script ed Applet. “Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati […]”. Le pagine devono essere utilizzabili anche senza script ed applet. Se questo non fosse possibile occorre informare in maniera accessibile l’utente della funzionalità svolta dall’oggetto e fornire una alternativa testuale equivalente tramite una pagina accessibile. Il motivo guida di questa direttiva è di sviluppare le pagine in modo che siano fornite le medesime funzionalità anche senza attivare queste metodologie. In primo luogo è necessario usare l’elemento NOSCRIPT ogni qualvolta si abbia la necessità di prevedere un codice alternativo per fornire funzionalità analoghe, ad esempio introducendovi dei collegamenti alle pagine precedenti o successive, nel caso fosse quello il compito degli script rimpiazzati. Con la barra dell’accessibilità si disabilitano gli script per eseguire un test, e si verifica che tutte le funzionalità siano comunque correttamente raggiungibili. Occorre ricordare che gli script aumentano sicuramente la facilità di utilizzo ma molti utenti disabili navigano con gli script disattivati mentre i browser più obsoleti non li supportano o li supportano con molti errori. Proprio per questi utenti che li lasciano abilitati occorre porre attenzione a fornire degli equivalenti funzionali. I docenti hanno ricordato che non è vero che gli script siano di per se inaccessibili, basta tenere in considerazione gli opportuni accorgimenti. Come si realizza uno script lo rende accessibile o meno, e questa è la cosa di maggiore importanza, come ribadito anche nel - 282 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR requisito successivo. Considerazioni analoghe valgono per tutti gli applet inclusi nella pagina e per la tecnologia Flash. Al seminario è stato fatto notare che per la valutazione di accessibilità, in caso di dubbio, il valutatore CNIPA si rifarà al codice X(HTML) che presente nella memoria del computer. Requisito Internet 16: Dispositivi di ingresso. “Garantire che i gestori di eventi che attivano script, applet o altri oggetti di programmazione o che possiedono una propria specifica interfaccia, siano indipendenti da uno specifico dispositivo di input.”. Navigando con JavaScript attivato o con applet funzionali, devono essere fornite pari opportunità d’interazione per tutti i dispositivi di input. Il requisito richiede che se ad un dispositivo d’ingresso vengono associati degli eventi, allora eventi equivalenti debbano essere associati anche per gli altri dispositivi di ingresso. Ad esempio, se viene associato una funzionalità all’evento ONCLICK deve necessariamente esserne associata un'altra anche a ONKEYPRESS. Una trattazione su questo argomento è stata esposta nelle parte delle metodologie. Particolare riguardo va posto all’interattività con la tastiera, dal momento che spesso è possibile emularne il funzionamento con tecnologie assistive, questo anche in considerazione di una esplicita raccomandazione riportata al requisito 21. Una facile valutazione di questo requisito si ottiene con la barra dell’accessibilità utilizzando la gestione di eventi che riporta, di ogni singola funzione, gli eventi a cui è associata, visualizzando la presenza o meno di eventi dipendenti dal dispositivo di input Requisito Internet 17: Oggetti collegati. “Garantire che le funzionalità e le informazioni veicolate per mezzo di oggetti di programmazione, oggetti che utilizzano tecnologie non definite da grammatiche formali pubblicate, script e applet siano direttamente accessibili.”. Con questo requisito si vuole garantire che ogni oggetto collegato o incluso nel sito Web sia a sua volta accessibile. Una verifica obbligatoria da svolgere per ogni oggetto aggiunto alle proprie pagine e che riguarda anche i documenti in formato PDF, le animazioni in flash, gli applet, e qualunque cosa che veicoli una informazione e che venga anche solo collegata tramite un link. Gli script, le applet e qualsiasi altro oggetto fornito di propria interfaccia deve essere compatibile con le tecnologie assistive. - 283 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Per quanto riguarda il modo di farlo, si deve fare riferimento alle specifiche del produttore in merito. Se il produttore dell’oggetto dichiara delle modalità di accessibilità, l’oggetto collegato deve seguire questi requisiti per essere incluso nella pagina. Tale richiesta si basa direttamente sulle WCAG 1.0 del 1999 che focalizzavano la loro attenzione solo sulle tecnologie Web delle grammatiche formali del W3C. Con la successiva versione, il mondo delle tecnologie proprietarie, come ad esempio flash e PDF, viene coinvolto più direttamente con il concetto di baseline. In questi casi isono i produttori che devono decidere i modi corretti con i quali implementare l’accessibilità e gli sviluppatori del sito che devono attenersi alle specifiche produttive per realizzare tali componenti. Questo punto coinvolge anche la stesura di documenti corretti nei formati PDF e Microsoft Word. Questi documenti hanno le loro interfacce esterne con i specifici marcatori di accessibilità che il redattore deve conoscere e sapere utilizzare al momento di produrre un documento. Un capitolo a parte di questo lavoro tratta l’argomento. L’unico modo per testare approfonditamente gli oggetti collegati è quello di utilizzare una tastiera verificando che le funzionalità e le informazioni siano accessibili. Utile anche valutare l’oggetto con uno screen-reader. Requisito Internet 18: Presentazioni multimediali. “Nel caso in cui un filmato o una presentazione multimediale siano indispensabili per la completezza dell’informazione fornita o del servizio erogato, predisporre una alternativa testuale equivalente, sincronizzata in forma di sotto-titolazione o di descrizione vocale, oppure fornire un riassunto o una semplice etichetta per ciascun elemento video o multimediale tenendo conto del livello di importanza e delle difficoltà di realizzazione nel caso di trasmissioni in tempo reale.”. Qualora una presentazione multimediale fosse importante allora si deve predisporre una informazione multi-canale che sia sincronizzata. Ad esempio se in un file video vengono fornite informazioni audio importanti occorre predisporre una sotto titolazione (caption) o una descrizione audio. La sezione apposita delle metodologie generali descrive queste tecniche. Con la barra dell’accessibilità è possibile identificare i contenuti multimediali. Anche nella legge Stanca viene tenuto in debito conto il concetto di sincronizzazione, da non considerare eventualmente solo in caso di trasmissioni in tempo reale. Requisito Internet 19: Collegamenti ipertestuali. “Rendere chiara la destinazione di ciascun collegamento ipertestuale (link) con testi significativi anche se letti indipendentemente dal proprio contesto oppure associare ai collegamenti testi alternativi che possiedano analoghe caratteristiche esplicative, - 284 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR nonché prevedere meccanismi che consentano di evitare la lettura ripetitiva di sequenze di collegamenti comuni a più pagine.” Il classico esempio che si porta ad esempio di questo requisito, è il generico “clicca qui” di molti collegamenti ipertestuali, che non ha molto senso se letto al di fuori del proprio contesto. A maggior ragione se ne esiste più di uno per pagina. Deve essere possibile avere una valutazione sommaria di ogni collegamento ipertestuale integrandoli con dei commenti che siano il più possibili significativi e ricchi di informazioni tramite le quali l’utente è in grado di valutare il personale interesse per il rimando. Un modo per realizzare questa richiesta è di usare l’attributo TITLE per identificare con chiarezza la destinazione di ogni collegamento. In questo requisito viene anche fatta presente la necessità di prevedere meccanismi che consentano di evitare la lettura ripetitiva di sequenze di collegamenti comuni a più pagine. Per fare questo occorre raggruppare i collegamenti correlati, identificare i gruppi e fornire un modo per saltare il gruppo. La valutazione complessiva del requisito viene fatta con la barra di accessibilità che fornisce una lista dei collegamenti della pagina evidenziando l’eventuale attributo TITLE associato. Requisito Internet 20: Eventi temporizzati. “Nel caso che per la fruizione del servizio erogato in una pagina è previsto un intervallo di tempo predefinito entro il quale eseguire determinate azioni, è necessario avvisare esplicitamente l’utente, indicando il tempo massimo consentito e le alternative per fruire del servizio stesso.”. Un esempio classico di questa situazione è quello dei refresh automatici delle pagine, comuni soprattutto ai siti delle agenzie che forniscono notizie in tempo reale. Una buona prassi operativa è quella di non implementare servizi a tempo, oppure di permettere agli utenti di impostare il tempo di refresh sui propri parametri. Infatti, il caricamento automatico a intervalli predefiniti (auto-aggiornamento) della pagina può causare problemi agli utenti che richiedono maggior tempo per leggere i contenuti, ed anche coloro che utilizzano lettori dello schermo troveranno fastidioso un aggiornamento che li costringa a ricominciare daccapo la lettura. Utilizzando la barra dell’accessibilità si possono verificare nella sezione METADATA se ci sono voci che impostano il tempo di auto-aggiornamento della pagina. Requisito Internet 21: Accessibilità dei collegamenti. “Rendere selezionabili e attivabili tramite comandi da tastiere o tecnologie in emulazione di tastiera o tramite sistemi di puntamento diversi dal mouse i collegamenti - 285 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR presenti in una pagina […].”. I collegamenti ipertestuali presenti in una pagina devono essere attivabili e selezionabili anche tramite tastiera. In oltre, è necessario che siano selezionabili separatamente e ben divisi gli uni dagli altri. I collegamenti devono essere sufficientemente distanziati in modo da poter rendere facile l’utilizzo dell’interfaccia anche da chi non ha un sistema di puntamento tipo il mouse. La legge richiede che:  La distanza verticale di liste di link e la spaziatura orizzontale tra link consecutivi sia di almeno 0.5 EM (in genere si consiglia almeno 1/1,5 EM)  Le distanze orizzontale e verticale tra i pulsanti di un modulo sia di almeno 0.5 EM  Le dimensioni dei pulsanti in un modulo siano tali da rendere chiaramente leggibile l'etichetta in essi contenuta, per esempio utilizzando opportunamente il margine tra l'etichetta e i bordi del pulsante. L’ EM è un’unità di misura relativa, se utilizzata per definire la dimensione dei font rappresenta la dimensione del carattere dell'elemento parent (ad esempio 0.80 EM indicano l'80% della dimensione del carattere dell'elemento parent); In genere si consiglia di impiegare almeno una volta e mezzo il carattere per le distanze, Una valutazione di questo requisito può essere fatta passando da una voce di menù ad un altro utilizzando il mouse, non deve mai verificarsi che nello spostamento rimanga fissa l’icona del collegamento per il puntatore. Tra un collegamento ed un altro il puntatore deve modificarsi in forma. Requisito Internet 22: Pagine accessibili equivalenti. “Per le pagine di siti esistenti che non possano rispettare i suelencati requisiti (pagine non accessibili), in sede di prima applicazione, fornire il collegamento a una pagina conforme a tali requisiti, recante informazioni e funzionalità equivalenti a quelle della pagina non accessibile ed aggiornata con la stessa frequenza, evitando la creazione di pagine di solo testo […]” Questo requisito è una norma transitoria valida solo in sede di prima applicazione e solo per i siti già esistenti. Non deve essere una scappatoia per il progettista. Si parte dal riconoscimento comprovato di un’incapacità da parte del realizzatore del sito di ottemperare per qualche pagina alle 21 norme precedenti. In tal caso di conclamata incapacità professionale, per ogni singola pagina, quando non c’è altro modo di ottenere il risultato, si può fornire un collegamento ad una pagina equivalente per funzionalità e aggiornata con la stessa frequenza. - 286 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Il ricorso a pagine alternative è, ad ogni modo, scoraggiato, ed a maggior ragione lo è l’uso sistematico di questa tecnica fino a realizzare un intero sito solo di pagine alternative spesso anche di solo testo. Va fatto notare con enfasi che la soluzione solo testo, spesso utilizzata anche da siti istituzionali, non è conforme a questo punto di controllo in quanto non si tratta di pagina equivalente che utilizza le tecnologie W3C. Chi, nonostante tutto, decidesse di creare una specie di porta di servizio per l’accessibilità non può dirsi in linea con gli standard del Web, non potrà dire che sta seguendo le WCAG, e neppure la legge 04/2004. Valutazione requisiti Internet Per la valutazione dei requisiti Internet viene predisposta procedura definita in allegato A del decreto intitolata “Metodologie per le verifiche tecniche” riportata in appendice. In questa si suggerisce una metodologia di valutazione che faccia ricorso a strumenti automatici e strumenti semiautomatici condotta da esperti sulla base di parametri tecnici. La metodologia suggerita dal decreto ministeriale si basa su quella proposta dal W3C. Le metodologie per la verifica tecnica sono quindi:  Verifica con sistemi di validazione automatica della rispondenza del linguaggio utilizzato alla sua definizione formale. Tra gli altri si ricorda il servizio di validazione fornito dal W3C1;  Utilizzo di strumenti semiautomatici di valutazione dell’accessibilità al fine di evidenziare problemi non riscontrabili dalle verifiche automatiche. Una lista degli strumenti più diffusi è reperibile nella pagina Evaluation, Repair, and Transformation Tools for Web Content Accessibility del sito del W3C 2;  Verifica dell'esperto sull'uso degli elementi e degli attributi secondo le specifiche del linguaggio;  Esame della pagina con diversi browser grafici, in differenti versioni e in diversi sistemi operativi per verificare che: a) Contenuto e funzionalità presenti in una pagina siano gli stessi nei vari browser; b) La presentazione della pagina sia simile in tutti i browser che supportano le tecnologie indicate al requisito 1; c) Disattivando il caricamento delle immagini, contenuto e funzionalità della pagina 1 2 [http://www.w3.org/WAI/eval/] [http://www.w3.org/WAI/ER/tools/] - 287 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR siano ancora fruibili; d) Disattivando il suono, i contenuti di eventuali file audio siano fruibili in altra forma; e) Utilizzando i controlli disponibili nei browser per definire la grandezza dei font, i contenuti della pagina siano ancora fruibili; f) La pagina sia navigabile in modo comprensibile con il solo uso della tastiera; g) I contenuti e le funzionalità della pagina siano ancora fruibili (anche in modo equivalente) quando si disabilitano fogli di stile, script e applet ed oggetti; h) Esame della pagina con un browser puramente testuale come ad esempio Lynx 1. Verificare che i contenuti e le funzionalità siano disponibili così come avviene nei browser grafici e che mantengano il proprio significato d'insieme e la corretta struttura semantica;  Verifica delle differenze di luminosità e di colore tra il testo e lo sfondo garantendo che siano sufficienti, secondo gli algoritmi suggeriti dal W3C 2;  Redazione di un rapporto finale, per opera dell’esperto tecnico. La prassi è quindi quella di un controllo approfondito delle pagine con diversi browser, anche testuali, disattivando mouse, provando a navigare solo con la tastiera, senza fogli di stile, senza applet e senza JavaScript. La valutazione si conclude con la predisposizione di un rapporto nel quale l'esperto tecnico indica la conformità ai singoli requisiti della pagina esaminata. L'esperto tecnico è un professionista delle tecnologie Web che ha una adeguata esperienza e conoscenza delle problematiche e delle tecniche per l'accessibilità equivalenti a quelle fornite dal W3C WAI nel suo programma Education & Outreach. La sua presenza in sede di valutazione è garanzia che, anche i soli controlli di verifica tecnica non vengano svolti in maniera totalmente automatizzata. Durante il seminario, i due docenti, hanno ricordato che la valutazione del CNIPA su sito piuttosto voluminoso verrà eseguita valutando la pagina principale e tutte quelle di primo livello più circa il 5% delle restanti secondo un campionamento casuale. Gli strumenti a disposizione del CNIPA per la valutazione possono essere di qualità ben maggiore di quelli in comune uso a privati e piccoli enti pubblici per raggiungere un grado di funzionalità molto maggiore da mettere a disposizione in sede di valutazione. A fronte di un 1 2 [http://lynx.isc.org/current/] [http://www.w3.org/TR/AERT#color] - 288 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR costo sicuramente maggiore questo però fornisce un’analisi indubbiamente più approfondita e significativa. Verifica soggettiva La verifica soggettiva è valutazione del livello di qualità dei servizi, già giudicati accessibili tramite la verifica tecnica, effettuata con l’intervento del destinatario, anche disabile, sulla base di considerazioni empiriche. La verifica soggettiva non è obbligatoria per il raggiungimento del logo senza asterischi ed è mirata più agli aspetti di usabilità piuttosto che a quelli di accessibilità in senso stretto. Ad ogni modo un suo sunto essenziale viene fornito in appendice riportando anche i 12 criteri essenziali che ne sono alla base. Comparazione con la Section 508 Un immediato paragone con le WCAG 1.0 nasce spontaneo, anche per il fatto che nello stesso dispositivo del Decreto Ministeriale sono riportati, al termine di ogni singolo requisito, i riferimenti normativi alle raccomandazioni del W3C e alla legge americana. Per di più lo stesso ministero ha fornito una tabella riassuntiva1 di relazioni tra WCAG 1.0, il Decreto Ministeriale e le Section 508. La seguente tabella vuol mostrare i legami tra i singoli requisiti previsti dalla verifica tecnica della legge Stanca e i paragrafi dello standard 1194.22 della sezione 508. Sebbene i legami siano descritti anche nel Decreto Ministeriale come appena fatto notare, in questa sede s’intende fornire qualche informazione in più sulle relazioni tra le due normative legali e capire in quali casi la legge Stanca è più o meno completa, precisa, generale della sezione 508. La tabella è stata curata da Giorgio Brajnik ed è riportata sul sito2 del Dipartimento di Matematica ed Informatica dell’Università di Udine. TABELLA 3 -CORRISPONDENZA TRA LA LEGGE STANCA E LA SECTION 508 Codice validità sintattica Legge Stanca 1: usare DTD strict Section 508 assente Commento legge Stanca più forte. (talvolta 1 2 [http://www.pubbliaccesso.gov.it/biblioteca/documentazione/ /corrispondenza_requisiti_wcag.htm] [http://www.dimi.uniud.it/wq/stanca-mappa.html] - 289 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Codice Legge Stanca Section 508 Commento 2: non usare i (i): usare titoli legge Stanca frame; se si informativi per i frame più forte 3: fornire del (a): analogo, con equivalenti testo esempi citati transitional); usare i tag secondo il loro scopo, e non per gli effetti di presentazione Frame deve allora fornire titoli informativi Testo alternativo alternativo ed equivalente colore movimenti 4: colore non (c): analogo deve essere 508 non l'unico modo riportano per veicolare criteri l'informazione valutativi 5: evitare (j): evitare immagini o legge Stanca immagini in altro che causi riportata le movimento che sfarfallio dello frequenze solo possano causare schermo tra 2 e 55Hz nei requisiti epilessia contrasto Equivalenti, le 6: contrasto software (n.9) assente visivo o legge Stanca più forte uditivo elevato Mappe lato client 7 e 8: usare (e), (f): analogo, mappe sensibili anche se più concreto equivalenti lato client; se si usano quelle lato server, fornire link testuali equivalenti tabelle 9 e 10: usare (g) e (h): analogo, TH, SUMMARY, anche se più concreto CAPTION, SCOPE, HEADER, AXIS - 290 - equivalenti ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Codice Legge Stanca Section 508 Commento per le tabelle dati CSS 11: usare il (d): le pagine devono legge Stanca CSS e fare in funzionare se il CSS più forte, modo tutto viene disabilitato perché obbliga funzioni anche ad usare il CSS quando viene disabilitato layout liquido req. 12: la assente pagina si deve legge Stanca più forte adattare alle diverse geometrie della finestra e a varie dimensioni dei caratteri del testo tabelle layout 13: le tabelle assente di layout legge Stanca più forte devono linearizzarsi rendendo il loro contenuto comprensibile form 14: associare (n): usare LABEL e FOR le etichette per realizzare alle form in l'associazione, che maniera deve essere esplicita equivalenti esplicita script 15: le pagine (l): se le pagine usano legge Stanca devono script per più forte, funzionare aggiungere/modificare perché impone quando gli il contenuto, allora ci che gli script script o altri deve essere del testo non debbano programmi sono descrittivo associato essere disabilitati ai controlli che necessari per attivano tali usare la pagina funzionalità gestori di eventi 16: usare gestori di (l): come sopra legge Stanca più accurata - 291 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Codice programmi inclusi Legge Stanca Section 508 Commento eventi che (richiede funzionino col gestori di mouse e con la eventi tastiera indipendenti) 17: i programmi (m): i plug-in inclusi inclusi nelle nella pagina devono pagine devono rispettare gli standard essere a loro del software equivalenti volta accessibili multimedia 18: fornire (b): analogo, alternative sincronizzazione testuali, ev. inclusa equivalenti sincronizzate link informativi 19: rendere a- assente contestuali le legge Stanca più forte etichette dei link in modo che siano comprensibili se tolti dal loro contesto skip-links 19: permettere (o): analogo equivalenti (p): analogo equivalenti assente legge Stanca di saltare oltre link ripetitivi azioni temporizzate 20: avvisare l'utente dell'eventuale tempo massimo uso della tastiera 21: rendere selezionabili più forte da tastiera i link di una pagina link distanziati 21: distanziare tra loro link adiacenti orizzontalmente o verticalmente - 292 - assente legge Stanca più forte ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Codice solo testo Legge Stanca Section 508 Commento 22: se non (k): se non altrimenti legge Stanca altrimenti possibile fornire il vieta le pagine possibile, collegamento ad una solo testo, fornire il pagina di solo testo mentre la collegamento ad equivalente Section 508 le una pagina suggerisce come equivalente alternativa accessibile, ma non di solo testo Secondo disegno di legge Campa Palmieri La Legge 4/2004 prevede, nell’articolo 12, che il decreto sui requisiti tecnici venga periodicamente aggiornato, per il tempestivo recepimento delle modifiche delle normative e delle innovazioni tecnologiche nel frattempo intervenute. Di fatto, questo non è ancora avvenuto dal momento della promulgazione della legge. Motivo di questa mancata attuazione è probabilmente l’attesa che un po’ da tutte le parti si sta prestando alle imminenti WCAG 2.0 le quali avranno il compito di dare probabilmente un nuovo impulso alla legislazione internazionale. Nel frattempo invece ci sono alcune proposte correttive alla legge stessa. Ad un anno dall'entrata in vigore del Decreto d’attuazione della legge Stanca, viene presentato il nuovo progetto di legge Campa-Palmieri, che apporta due modifiche sostanziali alla legge 4/2004:  La prima modifica prevede l'obbligo di conformità ai requisiti tecnici della legge Stanca ai siti Web (o ad una qualunque applicazione informatica) della pubblica amministrazione anche quando questi non rappresentino l'istituzione di un nuovo contratto con dei fornitori ma siano lo sviluppo di un progetto interno;  La seconda modifica riguarda l'attività di controllo: mentre la legge in vigore prevedeva che solo il CNIPA potesse provvedere a monitorare i siti delle pubblica amministrazione, con l'introduzione della nuova norma il Corecom (Comitato regionale per le comunicazioni) potrà controllare e verificare l'uso corretto delle forme di comunicazione on-line presso regioni, province autonome ed enti locali. Le modifiche restano, peraltro, marginali e legate più che altro agli aspetti eminentemente normativi e legali. I contenuti pratici restano immutati e per questi probabilmente dovremo davvero aspettare l’uscita delle nuove raccomandazioni del W3C. Questo in particolare per rivedere le richieste sulle modalità di utilizzo degli script nelle pagine. - 293 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Stato di attuazione I dispositivi predisposti dalla legge 4/2004 sono norme già in vigore nello Stato Italiano, norme a cui non devono rispondere i privati come per il decreto legislativo 216/2003, ma che tuttavia riguardano tutti gli enti pubblici ed altri enti correlati indicati nell’articolo 3. Nonostante la portata di tale applicazione, ancora nel 2005, al momento della presentazione della conferenza, due relatori lamentavano un riscontro molto negativo anche solo per la semplice conoscenza delle norme. Una lacuna talmente grave che molte amministrazioni comunali non erano nemmeno al corrente che quelle regole fossero già in vigore. Posso aggiungere che, sebbene in quest’anno la situazione sia sicuramente migliorata per quanto riguarda la conoscenza degli obblighi di legge, non vi sono tuttavia dei grossi progressi concreti, soprattutto in fatto di atteggiamento mentale delle pubbliche amministrazioni. In un articolo1 del Febbraio del 2006 apparso su punto informatico, Roberto Scano lamenta la lenta applicazione della normativa in Italia, forse anche a causa di correnti di pensiero che anziché promuovere l'applicazione della legge preferiscono scovarne i buchi, fornendo in questo modo delle pericolose scappatoie alle amministrazioni pubbliche. E’ un esempio il caso ampiamente trattato delle disponibilità di bilancio delle amministrazioni comunali o il fatto che, evitando la stipulazione di un contratto e realizzando il sito con un gruppo di lavoro interno non si è vincolati alla legge 4/2004. Anche per questi motivi, il miglioramento della qualità è in mano, per ora, alla buona volontà e alla sensibilità dei singoli. Grazie alla diffusione una tale attenzione alla accessibilità nelle pubbliche amministrazioni si sta arrivando pian piano alla realizzazione di nuovi siti Web di qualità altamente superiore e soprattutto accessibili. In particolare per le amministrazioni centrali più esposte alle interazioni con il pubblico, si inizia chiaramente a diffondere l'idea che chi non commissiona il sito accessibile oppure utilizza la scappatoia dello sviluppo interno per utilizzare soluzioni non a norma è certamente qualcuno che non fa l'interesse del cittadino, ed il conseguente danno di immagine è evidente. Delle cattive scelte dei propri funzionari ne risponde poi politicamente l'amministrazione intera. 1 [http://punto-informatico.it/p.aspx?i=57852] - 294 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR IV.5 - WCAG 2.0 (W3C WAI LAST CALL WORKING DRAFT - 27 APRILE 2006) Si tratta, allo stato attuale, di un Last Call Working Draft.1 con l’aggiunta di un documento provvisorio di revisione bozze2. Alla data di pubblicazione di questa tesi le WCAG 2.0 non sono ancora state rilasciate dal W3C in formato Recommendation, il formato definitivo delle normative W3C. Durante il loro percorso, le WCAG 2.0 hanno subito parecchi cambiamenti, il primo dei quali è stata la struttura stessa del documento che è arrivato più volte a modificare il numero delle linee guida ed i livelli di conformità. In questa panoramica essenziale si farà riferimento al Last Call Working Draft del 27 Aprile 2006, l’ultimo disponibile cronologicamente durante la redazione di questa tesi. A causa di queste continue revisioni, non è infrequente trovare su internet dei documenti poco aggiornati in materia, compreso, duole dirlo, quello in evidenza sullo stesso sito di WebAccessibile3 che riporta una relazione di una conferenza tenuta a Prato nel 2003 da Roberto Ellero, uno dei due membri italiani del gruppo di lavoro 4. Per quanto la relazione possa essere rilevante e valida per i principi che espone, purtroppo la sua enunciazione è basata ancora su un Working Draft del 2003, quando le linee guida erano ancora 19 mentre attualmente sono 13. Presentazione Le WCAG 1.0, attuali punto di riferimento per l’accessibilità, sono state approvate nel maggio del 1999 e sono l’unica versione stabile riconosciuta. L’aggiornamento del progetto alla versione WCAG 2.0 è stato ritenuto necessario per: 1 2 3 4  Coprire anche le nuove tecnologie emergenti del Web;  Correggere le imprecisioni della versione 1.0;  Essere più semplici da usare e comprendere;  Essere più facilmente testabili. [http://www.w3.org/TR/WCAG20/] [http://www.w3.org/WAI/GL/WCAG20/] [http://www.webaccessibile.org/argomenti/argomento.asp?cat=368] [http://www.w3.org/WAI/GL/participants.html] - 295 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Prima di esporle nel loro testo normativo vorrei definirle con un breve premessa storicovalutativa. Evoluzione dalle WCAG 1.0 Il primo progetto delle WCAG 2.0 nasce già del 2000, immediatamente a ridosso della pubblicazione conclusiva delle stesse WCAG 1.0 in forma di Recommendation. Un documento1 riassuntivo sullo sviluppo del progetto è disponibile sullo stesso sito del W3C. Vediamo alcuni punti essenziali che contraddistinguono le nuove linee guida, come illustrato dallo stesso sito del W3C:  Le WCAG 2.0 si applicano più ampiamente a differenti tecnologie Web e sono disegnate per le tecnologie future;  Le disposizioni e le tecniche delle WCAG 2.0 sono più facilmente testabili;  Nelle WCAG 1.0 delle brevi descrizioni sono incluse nel documento principale sotto ogni linea guida, con le WCAG 2.0 una guida completa per ogni linea guida viene fornita a parte nel documento Understanding WCAG 2.0;  Le WCAG 1.0 sono state progettate intorno a delle linee guida, con punti di controllo a priorità 1, 2 o 3. Le basi per determinare la conformità con le WCAG 1.0 sono i punti di controllo. Le WCAG 2.0 invece sono organizzate intorno a 4 principi di progettazione per l’accessibilità del Web. Ognuno di questi principi ha delle linee guida ed ogni linea guida ha dei criteri di successo di livello 1, 2 o 3. La base per determinare la conformità di un sito alle WCAG 2.0 sono i criteri di successo;  Le WCAG 2.0 introducono un nuovo concetto definito baseline che permette di separare i principi dalle tecniche di realizzazione, con la finalità di impedire un precoce invecchiamento delle linee guida con lo sviluppo della tecnologia. A detta dello stesso sito del W3C, la maggior parte dei siti Web che siano già conformi alle WCAG 1.0 non dovrebbero richiedere significative modifiche per essere resi conformi anche al nuovo standard. Le WCAG 1.0 sono state modificate intervenendo con un profondo intervento di ristrutturazione e di riprogettazione introducendo anche delle sostanziali novità di concetti. Alcuni di questi miglioramenti includono:  1 Rimozione di linee guida ritenute obsolete, tra le quali: [http://www.w3.org/WAI/GL/WCAG20/change-history.html] - 296 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR o 1.5: Fornire collegamenti di testo ridondanti per ogni zona attiva nella mappa immagine sul lato client; o 9.5: Fornire scorciatoie da tastiera per i collegamenti importanti; o 10.3: Fornire un testo lineare alternativo per tutte le tabelle che dispongono testo su colonne parallele; o 10.4: Inserire caratteri predefiniti come segnaposto nelle caselle per l'immissione di testo; o    10.5: Inserire caratteri stampabili per separare i collegamenti adiacenti; Impiego di nuove tecniche, come ad esempio: o Uso dei JavaScript per aprire dei collegamenti sulle finestre nuove; o Fornire un’intestazione all’inizio di ciascuna sezione; Nuovi principi considerati, ad esempio: o Inserimento di messaggi di errore nei moduli; o Inserimento di un titolo descrittivo e significativo per ogni pagina; o Disattivazione dei suoni di sottofondo; Neutralità rispetto alle tecnologie: Le WCAG 1.0, nella linea guida 11, richiamano all’uso stretto delle tecnologie W3C, richiedendo che sito debba fornire un’alternativa accessibile a JavaScript, PDF e Flash quando le tecnologie assistive come gli screen-reader non possano accedervi. Sebbene tutto questo fosse urgente nel 1999, ora non lo è più. JavaScript, PDF e Flash possono essere tutti resi accessibili alla maggior parte delle tecnologie assistive tramite una corretta progettazione di questi elementi. Per evitare un precoce invecchiamento delle normative con il progredire della tecnologia, il W3C ha deciso di rendere le nuove linee guida tecnologicamente neutrali.  La neutralità rispetto alle tecnologie ha portato all'eliminazione di quelle linee guida che avevano un supporto specifico: per esempio quelle sull’uso dei fogli di stile per controllare la presentazione dei documenti e quelle sulle modalità di realizzazione delle tabelle. I principi guida possono poi trovare specifica attuazione nel documento di tecniche soggetto a modifiche nel tempo. Un utile nota riepilogativa di questi ed altri aggiornamenti si trova nella stessa appendice1 D delle WCAG 2.0. 1 [http://www.w3.org/TR/WCAG20/appendixD.html] - 297 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Schema del progetto Sono disponibili 4 documenti base1 sul sito del W3C:  Web Content Accessibility Guidelines 2.0, Last Call Working Draft: la bozza ufficiale delle linee guida del W3C WAI;  WCAG 2.0 Quick Reference, Working Draft: un documento di supporto che elenca i requisiti base delle WCAG 2.0 e le tecniche sufficienti per soddisfarli;  Techniques for WCAG 2.0, Working Draft: un documento di supporto che fornisce i dettagli specifici su come sviluppare contenuti Web accessibili con esempi in codice HTML, CSS, SMIL e script;  Understanding WCAG 2.0, Working Draft: un documento di supporto che contiene suggerimenti supplementari per l’apprendimento e l’implementazione delle WCAG 2.0 descrivendo come soddisfare ogni criterio di successo. In oltre sono in fase di studio altri documenti addizionali sugli aspetti tecnici per coloro che non sono sviluppatori esperti in fatto di accessibilità:  Application Notes, che dovrebbe fornire suggerimenti per argomenti specifici come ad esempio immagini, collegamenti ipertestuali, moduli e tabelle;  Quick Tips to Make Accessible Web Sites: che dovrebbe riassumere i concetti cardine della progettazione accessibile. Allo stato attuale delle cose il modo migliore per incominciare a lavorare con le WCAG 2.0 è il documento di riferimento rapido WCAG 2.0 Quick Reference che considera le linee guida e i criteri di successo in relazione alle tecniche supportate. E’ possibile configurare il documento di riferimento rapido in relazione a quali delle tecnologie Web si vogliano impiegare, come ad esempio CSS, JavaScript ed altre, ed in relazione al livello di accessibilità che si intende raggiungere. Come spiegato in seguito, i criteri di successo sono degli assunti verificabili nella pratica che permettono di controllare fino a che punto il contenuto Web sia conforme alle WCAG 2.0. Ci sono diverse tecniche elencate per ogni criterio di successo, se queste tecniche vengono implementate si soddisfa al criterio medesimo. Sono presenti anche alcuni elenchi degli errori più comuni e delle prassi operative che non soddisfano alle linee guida. All’interno del documento di riferimento rapido sono presenti dei collegamenti ipertestuali che rimandano alla relativa sezione del documento Understanding WCAG 2.0. 1 [http://www.w3.org/WAI/intro/wcag20] - 298 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Per ogni criterio di successo vengono definiti:  Gli intenti, i significati e gli scopi;  Esempi;  Tecniche addizionali;  Ulteriori informazioni su come venire incontro alle persone disabili. Intenti programmatici del W3C Lo scopo delle WCAG 2.0, come lo stesso W3C le ha presentate in un intervista1 a Shawn Henry del Giugno del 2006, è quella di essere molto più appropriate per gli sviluppi presenti e futuri del Web. Le WCAG 1.0 sono state rilasciate nel Maggio del 1999 ed erano focalizzate sull’HTML. Molte cose sono cambiate da allora, le 2.0 sono incentrate su tecnologie differenti e più complete, e sono aggiornate allo stato degli sviluppi attuali, in oltre sono disegnate in modo che possano applicarsi anche alle tecniche future, come ad esempio AJAX. Questo tipo di tecnologia viene considerata sia nelle WCAG 2.0 che nel progetto ARIA del WAI sviluppato a parte. Le nuove linee guida sono differenti dalle precedenti. Anche per questo il progetto è integrato con un documento riferimento rapido che elenca le linee guida e i criteri di successo in relazione alle tecniche che le implementano. Da questo punto di vista, considerare le linee guida insieme ai loro criteri di successo, consente agli sviluppatori di comprendere le finalità e come progettare per soddisfare questi criteri. Esiste un documento2 che offre delle risposte agli utilizzatori delle WCAG 1.0 spiegando quali sono le motivazioni delle nuove linee guida e quali sono i più comuni errori. Sono a disposizione molte informazioni di supporto che dovrebbero aiutare gli sviluppatori a comprendere ed implementare le nuove WCAG 2.0. Una particolare attenzione è stata posta nella testabilità delle linee guida, in previsione del fatto che potrebbero essere impiegate come base normativa per eventuali leggi nazionali. Ovviamente non è possibile fare a meno di un controllo umano per valutare alcuni dei criteri di successo: l’attenzione verso una migliore testabilità delle linee guida riguarda la possibilità di un migliore controllo automatico via software. Un altro elemento portante ed innovativo è l’attenzione posta in fase progettuale all’adattamento nei confronti delle tecnologie emergenti. 1 2 [http://www.w3.org/WAI/highlights/200606wcag2interview.html Shawn Henry] [http://www.w3.org/TR/UNDERSTANDING-WCAG20/] - 299 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Il Web si è evoluto considerevolmente dal giorno del rilascio delle WCAG 1.0 nel 1999. Le WCAG 1.0 sono state scritte con l’assunto che gli utenti del Web avrebbero usato essenzialmente l’HTML. A giorni nostri il Web è usato in molti modi differenti che non sarebbero stati possibili nel 1999. Stanno emergendo molte nuove tecnologie e anche quelle esistenti stanno diventando più complete, man mano che la comunità degli utenti trova nuovi sistemi per diffondere e interagire con le informazioni. Per di più, a causa delle differenze economiche, di cultura e di altri fattori, le tecnologie che sono considerate comuni in alcune parti del mondo non lo sono affatto in altre. Stando questo stato di fatto il gruppo di lavoro del W3C ha inteso fondare su basi diversificate la versione 2.0 delle WCAG. L’intento era di presentare l’accessibilità del Web come un insieme di principi da applicare su tutte le tecnologie attuali, sufficientemente robusto da adattarsi anche agli strumenti futuri. Per conseguire questi scopi il gruppo di lavoro del W3C ha sviluppato un insieme di linee guida e di criteri di successo indipendenti, con lo scopo di consentire di raggiungere una conformità sfruttando qualsiasi tecnologia Web che supporti l’accessibilità. Le WCAG 2.0, perciò, non richiedono o proibiscono l’uso di una tecnologia specialistica. E’ possibile adeguarsi alle WCAG 2.0 usando o meno le tecnologie native del W3C 1. Questo insieme di linee guida universalmente valide è presentato in maniera esaustiva nel documento a carattere normativo: Web Content Accessibility Guidelines 2.0. Understanding WCAG 2.0 è invece un documento a carattere informativo che fornisce gli esempi ed una lista di tecniche adatte a soddisfare i criteri di successo. Questa politica di divisione in due strati rende possibile avere dei criteri stabili per l’accessibilità con il supporto di un documento squisitamente tecnico che può facilmente essere aggiornato man mano che le tecnologie si evolvono e vengono sviluppate nuove possibilità di soddisfare i criteri di successo. Un elemento chiave per questo modello è la capacità di definire l’insieme di tecnologie supportate dai programmi utente. Non è corretto supporre che i programmi utente, incluse le tecnologie assistive supportino tutte le nuove tecnologie dal momento stesso che sono annunciate. E’ necessario qualche meccanismo che definisca quali di queste si suppone possano essere presenti nei programmi utente. 1 “WCAG 2.0, therefore, does not require or prohibit the use of any specific technology. It is possible to conform to WCAG 2.0 using both W3C and non-W3C technologies” – WCAG 2.0 - 300 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Tuttavia definire un insieme fisso di tecnologie e chiuderle nelle WCAG 2.0 le renderebbe immediatamente obsolete, come è stato per le WCAG 1.0. La soluzione di questo problema, innovativa rispetto all’impianto della versione precedente, è stata quella di definire una cosiddetta baseline. Baseline La linea guida 11 delle WCAG richiede di utilizzare le tecnologie del W3C, le WCAG 2.0 riconoscono che nuovi strumenti si sono imposti nella rete ed altri continuano a nascere influenzando il Web in maniera positiva. Con le WCAG 2.0 non s’intende scoraggiarne l’uso. Di conseguenza è possibile usare qualsiasi tipo di tecnologia, anche non proprietaria del W3C, ed ottenere un sito conforme alle WCAG 2.0. Per questo le WCAG 2.0 sono basate su un insieme di principi che sono indipendenti dalla tecnologia e che sono capaci di incorporare anche quelle emergenti, comprese quelle esterne al W3C. Piuttosto che definire una volta per tutte l’elenco che si suppone siano supportate dai programmi utente, le WCAG 2.0 introducono il concetto di baseline. Vediamo di cosa si tratta. Nello scegliere l’insieme delle tecnologie (HTML, script, CSS, eccetera) che saranno impiegate al momento di predisporre i contenuti, i progettisti hanno bisogno di sapere quali di queste sono da considerare come disponibili e attive nei programmi utente che verranno impiegati. L’insieme di tali tecnologie che un progettista considera come disponibili ed attive nei programmi utente è definito come baseline1. I progettisti devono garantire che tutte le informazioni e le funzionalità di un contenuto Web siano conformi alle WCAG 2.0 dato per assunto che i programmi utente supportino tutte le tecnologie dichiarate nella baseline e che queste siano attivate. E’ possibile impiegare anche tecnologie non dichiarate nella baseline, ma in tal caso tutte le informazioni e le funzionalità del sito devono essere fruibili, sia che queste siano attive o meno. Il concetto di baseline è che il progettista o qualche autorità competente può definire l’insieme dei requisiti minimi che deve essere supportato dai programmi utente. Gli sviluppatori sono liberi di impiegare le altre tecnologie non dichiarate nella baseline, con l’assicurazione però di non basarsi esclusivamente su quelle tecnologie per veicolare qualunque informazione o funzionalità in modo che i contenuti siano ancora accessibili ed utilizzabili anche dalle persone i cui programmi utente siano compatibili con i soli requisiti dichiarati nella baseline. 1 “set of technologies assumed to be supported by, and enabled in, user agents” – [http://www.w3.org/TR/WCAG20/appendixA.html#baselinedef] - 301 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR In particolare:  Tutte le informazioni e le funzionalità del contenuto della pagina Web devono essere disponibili impiegando un programma utente che sfrutti solamente la tecnologia della baseline;  La presenza di tecnologie aggiuntive non deve limitare la capacità degli utenti di accedere al contenuto tramite le tecnologie definite nella baseline. Una baseline può essere definita da differenti organismi, tra i quali, gli stessi progettisti, organizzazioni, clienti, enti governativi. Le WCAG, proprio per la filosofia di progetto, non specificano nessuna baseline particolare. Nella dichiarazione di conformità alle WCAG 2.0 di un sito, lo sviluppatore deve specificare la baseline che sta impiegando. In sostanza, al momento della dichiarazione, un progettista dichiara che il contenuto sia adeguato alle WCAG 2.0 ad un definito livello di conformità per i programmi utente che supportino la tecnologia elencata nella baseline. Vediamo alcuni esempi di baseline, tratti dagli stessi esempi del W3C:  Un sito governativo che fornisce informazioni al pubblico. La baseline include solo tecnologie che possano essere ampiamente supportate da molti programmi utente in versioni differenti, ad esempio richiedendo solo HTML 1.0 TRANSITIONAL, .GIF, .JPEG. Questa è una baseline estremamente limitata e potrebbe essere appropriata per un pubblico molto ampio nel caso che non si sappia specificatamente quali programmi utente sono disponibili. E’ possibile che la baseline venga aggiornata con il tempo rispecchiando gli adeguamenti degli strumenti a disposizione del pubblico;  Baseline con JavaScript. Dal momento che JavaScript è elencato nella baseline, si può contare sulle tecniche sugli script definite come sufficienti in Understanding WCAG 2.0 per produrre del contenuto conforme e non sarà necessario offrire un contenuto alternativo che lavori con i JavaScript disabilitati;  Un ente pubblico fornisce direttamente ai cittadini che ne abbiano bisogno un programma utente che garantisca un alto livello di accessibilità con delle nuove tecnologie. In questo modo l’amministrazione è in grado di definire una baseline che comprenda queste nuove tecnologie dando per assunto che i cittadini abbiano programmi utente che le supportino;  Un’intranet privata. Una società pubblica o privata fornisce ai propri dipendenti uno strumento adatto al loro lavoro. La baseline per il sito internet usato solo dagli impiegati include le nuove tecnologie implementate dai programmi utente forniti ai dipendenti. Giacché la compagnia controlla i programmi utente usati per la visualizzazione del contenuto, il progettista ha una conoscenza molto accurata delle tecnologie a disposizione. - 302 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Le baseline non sono definite in termini di programmi utente, quanto piuttosto in termini di tecnologie per il Web che devono essere supportate in quei programmi utente, ad esempio HTML STRICT, HTML TRANSITIONAL, XHTML 1.1, CSS, GIF, JPEG, script eccetera. La baseline deve essere dichiarata ed appare esplicitamente nell'enunciato di conformità. Una spiegazione molto completa e dettagliata del concetto di baseline è disponibile in inglese sul sito dello stesso W3C1. Organizzazione Le nuove linee guida sono stilate su una organizzazione a livelli:  Principi base (Principles): o Linee guida (Guidelines):  Criteri di successo (Success Criteria) cioè condizioni sufficienti per determinare la soddisfazione della linea guida. Ogni principio è articolato in linee guida ed ogni linea guida in criteri di successo. Il termine punto di controllo (Checkpoint) delle precedenti WCAG 1.0 è stato eliminato. Allo stato attuale della bozza ci sono 4 principi, 13 linee guida e 62 criteri di successo. I 62 criteri sono suddivisi in 3 livelli, in base alla complessità di applicazione: 23 di livello 1, 18 di livello 2, e 21 di livello 3. Conformità La conformità del sito significa che il sito soddisfa ai criteri di successo definiti nel documento del W3C. Come detto, i criteri di successo per ogni linea guida sono organizzati in 3 livelli:  Criteri di successo di Livello 1: Raggiungono un livello minimo di accessibilità. Possono essere ragionevolmente applicati a tutto il contenuto Web;  Criteri di successo di livello 2: Raggiungono un livello avanzato di accessibilità. Possono essere ragionevolmente applicati a tutto il contenuto Web;  Criteri di successo di livello 3: Raggiungono un livello ulteriore di accessibilità. Possono non essere necessariamente applicati a tutto il contenuto Web. 1 [http://www.w3.org/WAI/WCAG20/baseline/] - 303 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR La conformità di tipo tripla-A richiede solamente una conformità ad una parte dei criteri di successo di livello 3, poiché non tutti i criteri di successo di livello 3 possono essere impiegati con tutti i tipi di contenuto. Le linee guida non contengono necessariamente criteri di successo per ogni livello. Questa modalità di raggruppare i criteri di successo differisce in modo sostanziale dal sistema usato per le WCAG 1.0. In quel caso ogni punto di controllo aveva assegnato una priorità in relazione al suo impatto sull’accessibilità, così che i punti di controllo di priorità 3 risultavano essere meno importanti di quelli di priorità 1. Il gruppo di lavoro delle WCAG ritiene che tutti i criteri di successo delle WCAG 2.0 siano essenziali per qualche gruppo di persone. Per questo è stato cambiato il sistema dei punti di controllo con quello dei criteri di successo. Una nota1 particolarmente significativa ad opera dello stesso W3C mette in risalto il fatto che persino conformarsi a tutti e 3 i livelli non renderà il contenuto Web accessibile a tutte le persone. Viene in oltre rimarcato che tutti i criteri di successo sono verificabili. Non è cambiato però il fondamentale criterio con cui testare i risultati. Mentre alcuni di questi possono essere verificati con programmi automatici, altri devono essere testati da esperti tecnici. In qualche caso queste due modalità possono essere usate in congiunzione. I risultati di queste valutazioni devono essere univoci. A seguito della valutazione sul soddisfacimento dei singoli criteri di controllo possono essere raggiunti tre livelli di conformità:  Conformità di livello A; se tutti i criteri di successo di livello 1 nelle linee guida sono soddisfatti, assumendo il supporto dei programmi utente solamente per le tecnologie specificate nella baseline;  Conformità di livello doppia-A (AA); se tutti i criteri di successo di livello 1 e di livello 2 nelle linee guida sono soddisfatti, assumendo il supporto dei programmi utente solamente per le tecnologie specificate nella baseline;  Conformità di livello tripla-A (AAA); se tutti i criteri di successo di livello 1 e di livello 2 nelle linee guida sono soddisfatti, ed anche almeno il 50% di quelli di livello 3, assumendo il supporto dei programmi utente solamente per le tecnologie specificate nella baseline. 1 “Note that even conformance to all three levels will not make Web content accessible to all people” – [http://www.w3.org/TR/WCAG20/] - 304 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR In questa valutazione, se un criterio di successo si riferisce ad una caratteristica od a un componente che non viene impiegato nei contenuti, ad esempio una presentazione multimediale, quel criterio di successo si ritiene automaticamente soddisfatto. Per dichiarare un livello di conformità devono essere presenti le seguenti asserzioni:  La data della dichiarazione;  Il richiamo alle WCAG;  L’indirizzo URI di riferimento (http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD);  Il livello di conformità raggiunto;  La baseline usata per dichiarare la compatibilità;  Un’espressione regolare che definisca la definizione del campo di applicabilità della dichiarazione. Una dichiarazione può essere ristretta ad una sola parte del sito a patto che non escluda una tipologia particolare di contenuti, come ad esempio gli script o le immagini. Un importante aggiunta in questa dichiarazione di conformità è la richiesta di specificare la data in cui viene asserita la dichiarazione. Si tratta di un concetto importante dal momento che in questo modo è possibile valutare quando è stata fatta l’ultima valutazione dei contenuti. Una pagina valutata più recentemente rappresenta sicuramente per gli utenti una delle migliori testimonianze della cura posta nel rendere il sito accessibile. Glossario A causa dell’ampia gamma di tecnologie supportate dalle WCAG 2.0, è stato necessario per il W3C introdurre dei termini maggiormente omnicomprensivi che fossero più precisi a riguardo delle tecniche e degli oggetti considerati. L’eccessivo grado di astrazione di queste definizioni finisce però per prestare il fianco ad alcune critiche sulla scarsa comprensione dei contenuti. A questo proposito lo stesso documento normativo delle WCAG 2.0 propone un glossario dei termini in appendice1 A, molte di queste definizioni però sono a loro volta complesse. Riporto quelle essenziali, tradotte per quanto possibile in italiano:  Programmaticamente determinato (programmatically determined): Determinato via software dai dati forniti in maniera supportata dai programmi utente in modo tale che i programmi utente possano estrarre e presentare questa informazione agli utenti in differenti modalità; 1 [http://www.w3.org/TR/WCAG20/complete.html#glossary] - 305 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Elemento unitario di progetto (Authored unit): Insieme di materiali creati da un progettista come singola entità. Ad esempio, una raccolta di markup, un foglio di stile, una risorsa mediale, come un'immagine o una clip audio;  Esperienza sensoriale specifica (Specific sensory experience): Un’esperienza sensoriale che non è puramente decorativa e che non veicola primariamente informazioni importanti e non esegue una funzionalità;  Baseline: un insieme di tecnologie assunte come supportate ed attive nei programmi utente;  Analizzati senza ambiguità (parsed unambiguously): Riassunti in un’unica struttura dati. L’analisi trasforma il linguaggio a marcatura o altri sorgenti in una struttura dati, generalmente ad albero, disponibile per successive elaborazioni, che ritenga l’implicita gerarchia dei dati in ingresso. Normativa I 4 principi base sono presentati sull’acronimo P.O.U.R.:  Percepible: Il contenuto deve essere percepibile;  Operable: I componenti dell'interfaccia nel contenuto devono essere fruibili;  Understandable: Il contenuto ed i controlli devono essere comprensibili;  Robust: Il contenuto deve essere sufficientemente robusto da funzionare con i programmi utente attuali e futuri, incluse le tecnologie assistive. Per la traduzione che segue delle linee guida si è scelto di riportare quella proposta da Roberto Scano1, altri commenti sono stati considerati dalla citata relazione2 di Roberto Ellero. I due importati autori citati sono anche i due membri italiani del gruppo di lavoro delle stesse WCAG. Principio 1: Percepibile I contenuti devono essere percepibili. Il primo principio si riferisce alla percepibilità dei contenuti, vale a dire alla possibilità di poter accedere al contenuto almeno in modalità testuale. È necessario quindi garantire che tutti i contenuti siano presentati in modo da poter essere percepiti da qualsiasi utente, ad esclusione delle informazioni o delle funzionalità che non 1 2 [http://www.meetinability.net/relazioni/abstract_scano.pdf] [http://www.webaccessibile.org/argomenti/argomento.asp?cat=368] - 306 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR possono essere descritte in modo testuale come ad esempio, le immagini da una webcam in tempo reale. In particolare la linea guida 1.1 richiede di fornire, per i contenuti non testuali, un testo equivalente che abbia lo stesso scopo o fornisca le stesse informazioni del contenuto non testuale, ad esclusione di quando lo scopo del contenuto non testuale è di generare un'esperienza sensoriale specifica (ad esempio, musica ed arte visiva) e in questo caso è sufficiente una etichetta o una descrizione. Il contenuto non testuale comprende, ma non è limitato da immagini, testo in immagini, mappe, animazioni, arte ASCII, punti degli elenchi puntati, spaziatori, bottoni, suoni, file audio, tracce audio di video e video. Script ed applet non sono considerati in questo elenco. In questo principio rientra anche, tramite la linea guida 1.3, la fondamentale separazione tra elementi strutturali ed elementi presentazionali e il trattamento del colore come veicolo informativo, mentre i criteri per un corretto contrasto ricadono nella linea guida 1.4. Come segnalato nel capitolo del colore, le WCAG 2.0 introducono un nuovo criterio per la valutazione del rapporto di contrasto della luminosità. Vengono introdotti anche altri criteri di chiarezza sulla percettività anche della informazione audio, con un criteri analoghi alla parte video. Linee guida:  1.1: Fornire alternative testuali per tutti i contenuti non testuali;  1.2: Fornire alternative sincronizzate per i contenuti multimediali;  1.3: Garantire che le informazioni e la struttura possano essere separate dalla presentazione;  1.4: Rendere facilmente distinguibili le informazioni principali rispetto allo sfondo. Principio 2: Fruibile I componenti dell’interfaccia devono essere operabili. Il secondo principio si riferisce alla fruibilità (o operabilità) dei contenuti, vale a dire alla possibilità di poter interagire con i contenuti e con le eventuali interfacce personalizzate. Roberto Ellero fa notare come nel termine operable si consideri anche il concetto di efficienza, citando come esempio di scarsa efficienza la necessità di premere decine di volte il tasto di tabulazione per scorrere i contenuti di una pagina. Tra le linee guida si afferma la necessità di garantire che tutti gli elementi delle interfacce presenti nel contenuto possano essere utilizzati da qualsiasi utente, quantomeno con l'utilizzo di tastiera, e che l'utente abbia la possibilità di intervenire nell'esecuzione di tali funzionalità. L'impossibilità di poter operare tramite tastiera rende inaccessibili i servizi agli utenti che utilizzano tecnologie assistive basate sui comandi tastiera come ad esempio la categoria degli screen-reader. - 307 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR L’inclusione dei meccanismi di navigazione è considerata nella linea guida 2.4 per la quale sono validi strumenti le strutture gerarchiche del linguaggio, le mappe del sito, le marcature corrette nelle tabelle, la possibilità di saltare blocchi di contenuto, il titolo delle singole pagine. Di primaria importanza sono i controlli sulle intermittenze dello schermo che, per i motivi di salute analizzati in precedenza, sono oggetto di una linea guida specifica. Linee guida:  2.1. Rendere tutte le funzionalità operabili tramite comandi da tastiera;  2.2. Consentire agli utenti di controllare i limiti di tempo per la lettura e l’interazione;  2.3. Consentire agli utenti di evitare i contenuti che possono causare attacchi di epilessia fotosensibile;  2.4. Fornire funzionalità che aiutino l’utente a trovare i contenuti, ad orientarsi all’interno dei contenuti e a navigarli;  2.5. Aiutare gli utenti nell’evitare errori consentendone facilmente la correzione. Principio 3: Comprensibile I controlli e i contenuti devono essere comprensibili. Il terzo principio si riferisce alla comprensibilità dei contenuti, vale a dire alla capacità di rendere chiari e semplici i contenuti. Questo principio riprende in qualche modo, soprattutto in sede costitutiva, la linea guida numero 14 delle WCAG 1.0, la quale prevede che i documenti siano chiari e semplici e quindi di facile comprensione per contrastare l’esclusione dal Web delle persone con problemi di lettura o disabilità cognitive. Tuttavia le modifiche d’impostazione rispetto alle linee guida precedenti sono considerevoli. Innanzi tutto sono state rimosse tutte le definizioni che in qualche maniera potevano richiamare all’usabilità del materiale Web. In oltre, nel testo attuale si fa riferimento, con il criterio di successo 3.1.5, ad un ben determinato livello di istruzione minimo a cui i contenuti devono adeguarsi, quanto meno tramite dei contenuti supplementari. Vengono considerate anche altre aspetti della comprensibilità come ad esempio la definizione del linguaggio naturale del contenuto, le abbreviazioni ed altre forme di contrazioni verbali. Linee guida:  3.1. Rendere leggibile e comprensibile il contenuto testuale;  3.2. Rendere determinabile la posizione e la funzionalità del contenuto. Principio 4: Durevole I contenuti devono essere robusti per l’uso attuale e futuro. Il quarto principio considera la naturale evoluzione delle tecnologie, vale a dire alla possibilità di poter interagire con i contenuti e con le eventuali interfacce personalizzate attuali e future. - 308 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Questo significa sviluppare cercando di utilizzare le ultime tecnologie attualmente disponibili ma allo stesso tempo cercando di mantenere la compatibilità con le precedenti. Le tecnologie assistive sono espressamente citate nella linea guida 4.1, per quanto esse facciano già parte della definizione dei programmi utente. Il significato di tale enfasi è dovuto alla finalità stessa del progetto WCAG. É necessario assicurarsi di progettare in maniera conforme alle specifiche del W3C, in modo che le tecnologie future che siano compatibili con questi protocolli non possano costituire impedimento alla fruibilità delle pagine prodotte oggi. Un codice corretto non crea problemi ai programmi utenti che rispettino le linee guida definite nelle UAAG, ad esempio garantendo che le pagine e i componenti creati possano essere analizzati e decodificati in maniera non ambigua e che tutte le relazioni fra i dati siano anche loro ben definite. La validazione formale di un linguaggio a marcatori come XHTML derivato da XML è un utile strumento guida in questa corretta progettazione. Linee guida:  4.1. Supportare la compatibilità con i programmi utente odierni e futuri (incluse le tecnologie assistive);  4.2. Garantire che il contenuto sia accessibile oppure fornire delle alternative accessibili. Mappatura WCAG 1.0 e 2.0 Il gruppo del WAI ha preparato una tabella riassuntiva1 per dare un’idea dell’evoluzione WCAG 2.0 a coloro che abbiano già sufficiente dimestichezza con le WCAG 1.0. La tabella propone un paragone fra le due linee guida utilizzando la versione del 2 Giugno 2004 del WCAG 2.0 Working Draft. Ne riporto un sunto essenziale per i principi di livello A. La tabella originale è reperibile sul sito del W3C. TABELLA 4 - RELAZIONE TRA LE WCAG 2.0 E WCAG 1.0 WCAG 2.0 WCAG 1.0 Linea guida 1.1: 1.1 [Priorità 1] Equivalenti testuali 1.2 [Priorità 1] 1.5 [Priorità 3] 6.2 [Priorità 1] 9.1 [Priorità 1] 1 [http://www.w3.org/WAI/GL/2004/06/02-mapping.html] - 309 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR WCAG 2.0 WCAG 1.0 12.1 [Priorità 1] Linea guida 1.2: 1.3 [Priorità 1] Equivalenti per elementi multimediali. 1.4 [Priorità 1] Linea guida 1.3: 2.1 [Priorità 1] Separazione fra struttura e contenuto. 3.3 [Priorità 2] 3.5 [Priorità 2] 3.6 [Priorità 2] 5.1 [Priorità 1] 5.2 [Priorità 1] 5.6 [Priorità 3] 6.1 [Priorità 1] 12.4 [Priorità 2] Linea guida 1.4: 2.2 [Priorità 2 per le immagini, Contrasto visivo. Priorità 3 per il testo]. Linea guida 1.5: Non disponibili Contrasto audio. Linea guida 2.1: 6.4 [Priorità 2] Operatività via tastiera. 9.1 [Priorità 1] 9.3 [Priorità 2] 9.4 [Priorità 3] 9.5 [Priorità 3] Linea guida 2.2: 7.2 [Priorità 2] Controlli temporali 7.3 [Priorità 2] 7.4 [Priorità 2] 7.5 [Priorità 2] Linea guida 2.3: 7.1. [Priorità 1] Sfarfallamenti Linea guida 2.4: 3.3 [Priorità 2] Meccanismi di navigazione 3.5 [Priorità 2] 5.3 [Priorità 2] 9.4 [Priorità 3] 9.5 [Priorità 3] 10.2 [Priorità 2] 12.1 [Priorità 1] 12.2 [Priorità 2] 12.3 [Priorità 2] 13.2 [Priorità 2] 13.3 [Priorità 2] 13.5 [Priorità 3] 13.6 [Priorità 3] - 310 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR WCAG 2.0 WCAG 1.0 13.9 [Priorità 3] 13.10 [Priorità 3] Linea guida 2.5: 13.7 [Priorità 3] Minimizzazione degli errori Linea guida 3.1: 4.1 [Priorità 1] Comprensibilità 4.2 [Priorità 3] 4.3 [Priorità 3] 5.5 [Priorità 3] 13.8 [Priorità 3] 14.1 [Priorità 1] 14.2 [Priorità 3] Linea guida 3.2: 7.5 [Priorità 2] Organizzazione e navigazione 10.1 [Priorità 2] 13.1 [Priorità 2] 13.4 [Priorità 2] 14.3 [Priorità 3] Linea guida 4.1: 3.2 [Priorità 2] Compatibilità e robustezza 3.5 [Priorità 2] 3.6 [Priorità 2] 3.7 [Priorità 2] 5.4 [Priorità 2] 11.2 [Priorità 2] Linea guida 4.2: 3.1 [Priorità 2] Supporto alle tecnologie assistive 6.3 [Priorità 1] 6.4 [Priorità 2] 6.5 [Priorità 2] 8.1 [Priorità 1/2] 9.2 [Priorità 2] 11.1 [Priorità 3] 11.4 [Priorità 1] - 311 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Critiche Come ricordato da Franco Carcillo1, Le WCAG 2.0 sono state attese da molto tempo da tutta la comunità degli sviluppatori, ed i ritardi di questa lunga gestazione sembrano essere apparentemente incomprensibili. In realtà le ragioni sono molte anche di un certo spessore. Per incominciare il Web del 2006 non è lo stesso di quello del 1999. Interessi economici e commerciali delle grandi aziende mondiali si sono orientati anche verso il W3C al punto che il numero di articoli critici verso questa organizzazione si è notevolmente moltiplicato. Joe Clark è una delle autorità più attive in questo campo. Un suo articolo estremamente pungente viene riassunto più avanti in questo lavoro. Le polemiche si incentrano soprattutto sulla affidabilità e sulla effettiva possibilità di implementare le WCAG 2.0 nel mondo reale finendo per coinvolgere anche il ruolo e la reputazione dello stesso consorzio. Al tempo delle WCAG 1.0 l’attenzione verso i temi dell’accessibilità era appena nascente. Attualmente invece le grosse società hanno tutto l’interesse a far sentire il proprio peso all’interno del W3C, come sponsor o come osservatore pagante. Di fatto, come fa notare anche Maurizio Boscarol in un suo articolo2 del Giugno 2006, per partecipare al Working Group bisogna come minimo essere appositamente stipendiati, avere forti interessi economici in gioco (nel caso di aziende o professionisti), oppure avere molto tempo libero. Infatti è necessario partecipare a tele-conferenze a cadenza settimanale, oltre a seguire interminabili discussioni quotidiane nella mailing list pubblica. Vuoi per questi motivi, vuoi per l’intento di essere al di sopra di una speficifica tecnologia, come invece non erano le WCAG 1.0, le WCAG 2.0 pagano lo scotto di una lunga fase propositiva che si snoda da lungo tempo in un interminabile sequela di Working Draft e di proposte di correzione. Ed anche quando finalmente usciranno, di certo non potranno avere lo stesso impatto legislativo e la stessa autorevolezza che invece hanno fortunatamente segnato le precedenti, se non altro per il loro più elevato grado di genericità. Il pericolo di un possibile conflitto fra estremisti e di una conseguente reazione di disinteresse contro l’accessibilità è reale. 1 2 [http://www.francocarcillo.it/] [http://www.ecologiadeisitiweb.net/blog/la-balcanizzazione-dellaccessibilita] - 312 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Un avvertimento significativo sulla effettiva dispersione di energia e coerenza viene dal citato dallo stesso articolo di Maurizio Boscarol. L’autore pone l’accento sulle divisioni e sulle moltiplicazioni di iniziative per nulla coordinate fra di loro. Segnala poi il fatto che, per quanto possa sembrare strano, la consultazione e l’interazione con le comunità dei maggiori beneficiari delle normative sono state piuttosto scarse. Nella legge Stanca e nelle WCAG non viene documentato in nessun modo quale tipologia di ricerche empiriche siano state realmente portate a termine con utenti disabili. Maurizio Boscarol parla di queste utili ricerche come finalizzate ad un duplice scopo:  Tentare di capire cosa vogliano gli utenti disabili;  Tentare di capire, osservandoli, come usano veramente il Web gli utenti disabili. Una ricongiunzione importante con il modo dell’handicap, dal momento che non sempre questi utenti possono aver bisogno di quello che viene loro effettivamente fornito. In assenza di queste indicazioni empiriche documentate si finisce per spostare l’attenzione sulle teorizzazioni e sugli interessi che sono maggiormente rappresentati nei gruppi di lavoro, questi finiscono per essere quelli dei grandi distributori e dei produttori di tecnologie e di software coinvolti nella realizzazione dell’accessibilità. L’incitamento di Maurizio Boscarol è quello di riportare al più presto l’attenzione sulle esigenze degli utenti con un metodo scientifico basato sulle evidenze e sulle prove empiriche. Lo stesso autore riconosce questa proposta come contraria alla cultura dominante in quanto toglie autorità agli esperti per ridarla agli utenti proponendo di verificare prima di normare. Piuttosto tristemente, Boscarol conclude osservando come, di conseguenza, la comunità dell’accessibilità si stia disperdendo in un rivolo di frammentazioni progressive in un clima di diffidenza e tensioni reciproche fra diversi gruppi di lavoro, consulenti ed organizzazioni finanziate. Di fatto le WCAG 2.0 non possono considerarsi esenti da pecche:  Uno degli aspetti più critici è probabilmente l’eccessivo tecnicismo usato nella stesura del testo. Come visto in precedenza è stato definito opportunamente un glossario per le formule espressive ricorrenti, tuttavia lo stesso glossario è eccessivamente ricco di termini tecnici e questo compromette sicuramente la comprensibilità del testo e incute un approccio di eccessiva diffidenza nel lettore;  Difficile usabilità della documentazione. Un elemento negativo già presente nelle WCAG 1.0 e ulteriormente esasperato in questa versione. Si tratta di documenti ipertestuali piuttosto intricati nei collegamenti e nei rimandi. Questo è stato probabilmente per arricchire il contenuto, ma finisce a volte per dare la sgradevole impressione di essere rimandati da un ufficio all’altro per accedere alle informazioni;  I documenti sono in oltre piuttosto voluminosi. La maggior parte degli sviluppatori vedono l’accessibilità come una parte del loro lavoro e non hanno spesso il tempo o la - 313 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR voglia di muoversi attraverso centinaia di pagine di testo per scoprire come implementare pagine accessibili;  Mancanza di alcune linee guida valide delle WCAG 1.0, alcune delle quali sono scomparse del tutto mentre altre sono state notevolmente ridimensionate, come ad esempio1: o Punto 3.1: usare un marcatore piuttosto che le immagini; o Punto 3.2: Creare documenti che rispettino le grammatiche formali; o Punto 3.3: Usare i fogli di stile per controllare l'impaginazione e la presentazione;  o Punto 3.4: Usare unità di misura relative anziché assolute; o Punto 12.3: Dividere i grandi blocchi di informazione in gruppi più maneggevoli; o Punto 13.8: Posizionare l'informazione più significativa all'inizio; o Linee guida sull’usabilità del sito e sulla chiarezza del contenuto; La neutralità rispetto alla tecnologia costituisce un punto di forza ma anche un punto di estrema debolezza, in pratica questa scelta ha reso le linee guida WCAG 2.0 estremamente vaghe in se stesse, al punto di essere quasi inutilizzabili se non supportate validamente da un consistente documento di tecniche. Un lungo articolo2 molto critico è stato pubblicato su A List Apart, a cura di Joe Clark. Consiglio vivamente una lettura, per la criticità del testo e per l’autorevolezza dell’autore, nel caso consultandolo anche nella parziale traduzione3 italiana. Ne riporto nel seguito i concetti fondamentali, molti mi sembrano effettivamente eccessivi, ma altri possono avere una loro valida motivazione. L’opinione di Joe Clark Le WCAG 1.0 risalgono oramai al 1999. Se hanno avuto il grosso pregio di aprire la strada alle leggi nazionali che le hanno seguite, tuttavia contengono parecchie inesattezze e sono diventate presto obsolete in alcuni punti, a causa dei veloci mutamenti della tecnologia in questo settore. Le WCAG 2.0 dovrebbero essere la loro naturale evoluzione. Sono il risultato di almeno 5 anni di lavoro della commissione WAI e non sono ancora arrivate ad un risultato definitivo. 1 2 3 [http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/wcag-guidelines-20.shtml] [http://alistapart.com/articles/tohellwithwcag2] [http://www.giorgiocardellini.com/webdesign/utente/060523.htm] - 314 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Nello sforzo di coprire tutto su tutti i contenuti Web, sono quasi impossibili da comprendere e sono un passo indietro rispetto alle basi di un buon sviluppo come ora universalmente accettato. In breve non possono considerarsi un vero progresso e non valevano l’attesa1. Le WCAG 1.0 sono, attualmente, il solo standard internazionale ma ormai sono arrivate a 7 anni di vita ed hanno bisogno di essere profondamente revisionate. Il 27 Aprile 2006 con il Last Call Working Draft è stato compiuto il primo passo della lunga sequenza per arrivare alla standardizzazione delle 2.0. Tuttavia, la speranza di un miglioramento complessivo rimane delusa. Sono state incluse molte finalità inutili e linee guida di basso interesse. Dove le WCAG 2.0 falliscono è nei compiti più importanti, nonostante che esse sembrino ragionevoli grazie ad una esposizione curata. In realtà non lo sono e uno sviluppatore che aderisca agli standard le troverà quasi impossibili da mettere in pratica. Come da tradizione del W3C, poi, la documentazione è dispersiva e difficile da reperire. I tre documenti guida sono:  Web Content Accessibility Guideline2 (WCAG) 2.0, documento principale normativo in Last Call Working Draft;  Understanding3 WCAG 2.0, un documento di spiegazione;  Techniques4 for WCAG 2.0, fornisce le tecniche generali, ora include anche le tecniche per (X)HTML. I punti critici sono parecchi:  I tre documenti delle WCAG 2.0 superano le 450 pagine con un cambiamento di nomenclatura;  Il tempo concesso alle parti interessate, incluse le associazioni di disabili, per riportare commenti alla mole di documentazione prodotta in cinque anni è stato davvero molto breve;  Il gruppo di lavoro del WCAG è uno dei peggiori con cui lavorare, molti tentativi di contatto vengono respinti, soprattutto se non vengono dalle multinazionali che possono spendere ore al telefono e continui viaggi in aereo tra le capitali mondiali. Gli stessi 1 “WCAG 2 backtracks on basics of responsible web development that are well accepted by standardistas. WCAG 2 is not enough of an improvement and was not worth the wait.” 2 [http://www.w3.org/TR/WCAG20/complete.html] 3 [http://www.w3.org/TR/UNDERSTANDING-WCAG20/] 4 [http://www.w3.org/TR/WCAG20-TECHS/] - 315 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR partecipanti lavorano in un clima intimidatorio come non succede in nessun altro gruppo di lavoro del WAI1;  Il processo di sviluppo è inaccessibile per chi non parli inglese e soprattutto è inaccessibile per alcune persone con disabilità, in special modo per chi ha difficoltà di lettura (i testi sono scritti male) e di udito. In pratica, nessuno con disabilità cognitive o uditive ha contribuito al processo, perché è, di fatto, impossibile. Basta spendere poche ore nella lettura delle bozze per rimanere delusi. Il documento sembra ragionevole sintetico e funzionale ma il nocciolo del problema è stato seppellito nel testo. Nel testo ci sono parecchi punti controversi:  E’ poco chiaro che cosa si intenda per pagina o sito;  Per essere accessibile un documento HTML non deve essere per forza un documento valido;  Si può impiegare anche più di un livello di tabelle di impaginazione annidate;  Sono consentiti lampeggiamenti dell’intera pagina (blinking) fino a 3 secondi, ma nessuna sua parte può avere dei flash.  Avendo definito una tecnologia come una baseline, chiunque non ne disponga ha ben pochi strumenti per protestare se il sito è inaccessibile in mancanza delle tecnologie dichiarate2;  E’ possibile definire delle intere cartelle del sito come inaccessibili, come ad esempio quelle contenenti presentazioni multimediali;  Il documento di compatibilità è una dichiarazione di punti di controllo che ricorda più una confessione obbligata che una dichiarazione delle politiche di accessibilità messe in atto;  Nei video non occorre fornire una descrizione audio per i non vedenti e le descrizioni testuali sono richieste solo per i video pre-registrati;  Puoi creare una pagina sola con migliaia di collegamenti ipertestuali, ma se si mettono una dopo l’altra due pagine con almeno tre collegamenti di navigazione, allora si deve fare in modo che possano esser saltati;  Non si possono mettere delle etichette fuori schermo che possano vedere solo gli utilizzatori di tecnologie assistive; 1 “Something’s wrong if many participants work in a climate of fear, as they tell me they do. I never hear of similar complaints from WAI’s other groups. WCAG Working Group is a rogue element within the W3C.” 2 [http://www.w3.org/TR/WCAG20/complete.html#conformance-reqs] - 316 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Nelle impaginazioni con i CSS sono proibiti i posizionamenti assoluti giacché l’ordine del codice e l’ordine della presentazione devono coincidere;  E’ possibile fornire un documento alternativo per persone che non sono culturalmente in grado di comprendere il documento principale. In pratica le WCAG 2.0 propongono di mantenere pagine accessibili ed inaccessibili, in questo modo non ci sarà bisogno di migliorare l’accessibilità di una pagina, basterà produrne una separata. Le WCAG 2.0 sono allo stato di bozza, ma in pratica non cambieranno. Il gruppo di lavoro ritiene di aver soddisfatto le richieste tecniche. Dove invece il gruppo non ha certamente lesinato è nelle definizioni. Le WCAG 1.0 erano strettamente legate all’HTML, e tutti hanno riconosciuto che questo fosse un problema in un periodo in cui PDF e Flash stanno pian piano diventando accessibili. Per questo le WCAG 2.0 sono indipendenti dalla tecnologia. Per venire incontro a questi ambienti, sono state scritte e riscritte più volte al punto di perdere la capacità di adattarsi al mondo reale con cui lavorano concretamente gli sviluppatori in HTML, CSS e JavaScript. In particolare, molte definizioni come: authored unit, authored component, web unit, parsed unambiguosly, programmatically determined, possono essere difficilmente tradotte in termini pratici da tutti i lettori. In effetti, parecchie parti delle WCAG 2.0 sono poco comprensibili e difficili da applicare, a dispetto degli stessi principi di comprensibilità che espongono. Essendo così difficili da comprendere, difficilmente potranno essere messe in pratica. Tra l’altro potrebbero anche essere soggette ad interpretazioni arbitrarie, rendendo discutibile il fatto di aver realizzato un sito pienamente accessibile. Per quanto poi riguarda i criteri di successo, anche questi sono un’illusione. Nonostante che si fosse notato che con le WCAG 1.0 le conformità di tipo A e doppia-A fossero quelle concretamente attendibili mentre la tripla-A fosse irrilevante e inattendibile, le WCAG 2.0 hanno alla fine deciso di ripetere lo stesso schema. Per di più:  Anche se ci si conforma a tutti i tre livelli delle WCAG 2.0, è possibile comunque produrre un sito inaccessibile;  E’ possibile adeguarsi solamente alla metà delle richieste di livello 3 per ottenere la conformità1;  Lo stesso documento del W3C afferma che non si raccomanda che un livello di conformità tripla-A sia sempre richiesto per l’intero sito1; 1 [http://www.w3.org/TR/WCAG20/complete.html#conformance-reqs] - 317 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  In una contraddizione ciclica la linea guida 4.2.4 a livello 3 non richiede2 che venga soddisfatto il livello 3 per tecnologie al di fuori della baseline;  Molte linee guida non hanno criteri di successo al primo livello basilare, e comunque non sono applicabili a tutti i livelli. E’ cosa risaputa che un sito che validi la sintassi HTML non sia automaticamente un sito accessibile, nella realtà concreta gli sviluppatori che sappiano orientarsi autonomamente nella scrittura manuale del linguaggio, sono spesso in grado di comprendere con relativa facilità i concetti dell’accessibilità e di attuarne i principi. Eppure la validazione formale della grammatica del documento è solo di livello 2 nelle WCAG 1.0 (punto di controllo 3.2), e nelle WCAG 2.0 questa validazione formale è stata del tutto abolita, non c’è bisogno di avere un codice HTML valido per i siti compatibili con le WCAG 2.0, tutto quello che è richiesto 3 è che la pagina possa essere esaminata senza ambiguità4, in pratica che gli elementi non vengano annidati scorrettamente. Non è necessario utilizzare gli elementi come richiesto dalle specifiche e non si richiede l’uso delle tecnologie in accordo con la semantica definita nelle specifiche 5. Un documento fatto di nient’altro che DIV e SPAN, se esaminabile senza ambiguità, supera il controllo delle WCAG 2.0. Se c’è stata un’area in cui l’applicazione delle WCAG 1.0 è fallita completamente è stata quella dei contenuti multimediali. Praticamente tutti hanno ignorato la necessità di descrizioni audio e descrizioni testuali che sono entrambe richieste già al più basso livello dell’accessibilità. Anche in questo campo, per i non vedenti ed i non udenti che vogliano accedere al multimediale, le WCAG 2.0 non presentano alcun vantaggio reale. Le descrizioni testuali rimangono obbligatorie solo per i video pre-registrati, mentre in luogo delle descrizioni audio è prevista una equivoca alternativa testuale di multi-medialità completa che includa tutte le interazioni. In sostanza le WCAG 2.0 saranno inutilizzabili nella realtà dagli sviluppatori, soprattutto da quelli che intendono produrre del codice aderente agli standard. Sono troppo vaghe e 1 “It is not recommended that Triple-A conformance ever be required for entire sites.” – [http://www.w3.org/TR/WCAG20/complete.html#N10471] 2 [http://www.w3.org/TR/WCAG20/complete.html#accessible-alternatives-level2] 3 [http://www.w3.org/TR/WCAG20/complete.html#N1085F] 4 “You never have to have valid HTML in WCAG 2–compliant sites. All that’s required is that the page be parsed unambiguously” 5 [http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0187.html] - 318 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR contestabili per affermarsi come basi per la regolamentazione e lasciano troppe scappatoie per gli sviluppatori che le vadano cercando 1. Le WCAG 2.0 non rimpiazzano le WCAG 1.0 né più né meno di quanto l’XHTML non rimpiazzi HTML. Forse ci sarebbe stato solo bisogno di correggere le WCAG 1.0 in una versione 1.1. Relazione con il DM 8 Luglio 2005 Una corrispondenza significativa per le WCAG 2.0 la si può cercare anche con il nostro Decreto Ministeriale del Luglio 2005 che accompagna la legge Stanca. La legge italiana è molto più calata nella realtà, ed è stata pensata in modo che i requisiti possano essere applicabili e valutabili. Questo soprattutto ragioni di esame in sede legale: sarebbe stato impraticabile dare delle norme che poi non potessero essere verificate con relativa semplicità e in modo univoco. Sul sito del Dipartimento di Matematica ed Informatica dell’Università di Udine, Giorgio Brajnik presenta una seconda tabella2 di corrispondenze, questa volta fra la legge Stanca e le nascenti WCAG 2.0. La tabella citata però non è basata sull’ultima versione rilasciata del Working Draft e contiene, allo stato attuale dei lavori, alcune lacune ed imprecisioni. Ad ogni modo può essere di utile informazione e ne segnalo la presenza sempre sul sito del Dipartimento di Matematica ed Informatica dell’Università di Udine. Riprendendo le stesse annotazioni di Giorgio Brajnik si può riassumere che la legge Stanca risulta in generale più vincolante delle WCAG 2.0 per:  Il posizionamento e la separazione dei collegamenti ipertestuali (requisito 21);  Il divieto di uso dei frame (requisito 2);  Il dover produrre pagine sintatticamente corrette in (X)HTML;  Il considerare gli script come non essenziali;  Il considerare le pagine alternative solo testo come non accessibili. D'altra parte la legge Stanca:  Non copre con lo stesso dettaglio i vari tipi di materiale non testuale e di materiale multimediale; 1 “As such, WCAG 2 will be unusable by real-world developers, especially standards-compliant developers. It is too vague and counterfactual to be a reliable basis for government regulation. It leaves too many loopholes for developers on the hunt for them. WCAG 2 is a failure, and not even a noble one at that” 2 [http://www.dimi.uniud.it/wq/stanca-mappa.html] - 319 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Si basa su formule e soglie per determinare i livelli di contrasto che sono datate e discutibili come è già stato commentato nella sezione inerente al colore;  E’ meno specifica nelle casistiche relative alle funzionalità temporizzate, al lampeggio, alla navigazione;  Non tratta la gestione degli errori, i cambi di lingua, le abbreviazioni, il testo semplificato, il cambiamento del focus, la coerenza nel sito. IV.6 - Quadro sinottico In questa sezione si vuole dare una connotazione conclusiva alle normative esaminate mettendole in relazione fra loro. Lo scopo di uno studio del genere è quello di aiutare il lettore nella comprensione dei principi, non certo quello di voler valutare la bontà o la superiorità di una legislazione rispetto ad un'altra. Questo per il fatto che hanno finalità piuttosto diverse, a partire dalle WCAG 2.0 che sono forse le meno comparabili con le altre dal momento che forniscono volutamente dei principi piuttosto astratti, essendo state progettate per un campo di applicazione più generale. In oltre tutte le relazioni fra le normative sono piuttosto complesse. Si è già accennato ad una possibile conflittualità delle Section 508 con le WCAG 1.0. Va aggiunto che la legge Stanca non copre nemmeno il livello A delle WCAG 1.0 pur contenendo altri principi più restrittivi. E viceversa, come ricordato anche alla conferenza IWA di Arese: chi ottiene la conformità il livello A delle WCAG 1.0 non raggiunge necessariamente la conformità con la legge Stanca, che contiene nelle sue disposizioni qualcosa anche del livello doppia-A e tripla-A delle WCAG 1.0. Vorrei qui presentare una fusione di tabelle comparative elaborata personalmente che in qualche maniera possa fungere da quadro sinottico delle normative. La tabella è una sintesi di varie fonti ufficiali e mette in relazione di argomento le normative citate. Trae la sua materia dai vari confronti proposti nei siti ufficiali: 1 2 3  Dalle indicazioni1 del Decreto Ministeriale 8 Luglio 2005;  Dalla griglia di valutazione2 del W3C;  Dalla nota di raffronto3 della Section 508;  Dalla pagina1 di presentazione del W3C delle WCAG 2.0. [http://www.pubbliaccesso.gov.it/biblioteca/documentazione/corrispondenza_requisiti_wcag.htm] [http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/full-checklist] [http://www.section508.gov/] - 320 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Sono state riportate in ordine di priorità basandosi sulle WCAG 1.0 che, storicamente, hanno fatto da riferimento per le altre normative. Le tabelle, ovviamente, possono contenere delle forzature, dal momento che le linee guida delle normative non si possono far sovrapporre direttamente l'una sull'altra. Per eventuali errori e spiegazioni suggerisco di consultare direttamente le pagine originali indicate. Per le WCAG 1.0 è stato riportato il numero di punto di controllo, per la Section 508 la lettera del paragrafo in maiuscolo per maggiore chiarezza, per il Decreto Ministeriale 8 Luglio 2005 il numero di requisito e per le WCAG 2.0 i relativi criteri di successo. TABELLA 5 - TABELLA COMPARATIVA DELLE NORMATIVE SUI PRINCIPI DI LIVELLO A ARGOMENTO WCAG SECTION DM 1.0 508 2005 WCAG 2.0 Equivalenti testuali 1.1 A 3 1.1.1, 2.4.6, 4.1.2 Mappe lato server 1.2 E 8 1.1.1, 2.1.1, 2.4.4, 4.2.1 Multimedia audio 1.3 B 18 1.2.2 Multimedia sincronizzati 1.4 B 18 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.6 Informazioni con colori 2.1 C 4 1.3.2 Cambiamenti di lingua 4.1 Tabelle dati 5.1 G 9 1.3.1 Tabelle dati complesse 5.2 H 10 1.3.1 Assenza dei CSS 6.1 D 11 Cambiamenti contenuti dinamici 6.2 A 3 Applet e script non attivi 6.3 L, M 15 4.2.1, 4.2.3 Sfarfallio dello schermo 7.1 J 5 2.3.1, 2.3.2 Mappe lato client 9.1 F 7 1.1.1, 2.1.1, 3.1.2 2.4.4, 4.2.1 Pagine alternative 1 11.4 K 22 4.2.1, 4.2.2 [http://www.w3.org/TR/WCAG20/appendixD.html] - 321 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR ARGOMENTO WCAG SECTION DM 1.0 508 2005 Titolo ai frame 12.1 Comprensibilità dei contenuti 14.1 I 2 WCAG 2.0 2.4.1, 2.4.4, 4.1.2 TABELLA 6 - TABELLA COMPARATIVA DELLE NORMATIVE SUI PRINCIPI DI LIVELLO DOPPIA-A ARGOMENTO WCAG SECTION DM 1.0 508 2005 WCAG 2.0 Contrasto colori immagini 2.2 6 Linguaggi invece di immagini 3.1 1 Grammatiche formali 3.2 1 4.1.1 Impaginazione con CSS 3.3 11 1.3.3 Unità di misura relative 3.4 12 Elementi strutturali h1..h6 3.5 1 1.3.1 Marcatori di lista 3.6 1 1.3.1 Marcatori di citazione 3.7 1 1.3.1, 1.3.4 Tabelle linearizzate 5.3 13 1.3.3 Tabelle di impaginazione 5.4 13 1.3.1 Input per applet e script 6.4 16 2.1.1, 2.1.2 Contenuti dinamici 6.5 3 4.2.1, 4.2.3 Lampeggiamento del contenuto 7.2 J 5 2.2.2 Movimento nelle pagine 7.3 J 5 2.2.3 Auto aggiornamento pagine 7.4 P 20 2.2.1, 3.2.5 Auto indirizzamento pagine 7.5 P 20 3.2.5 Elementi programmati accessibili 8.1 L, M 17 4.1.2, 4.2.1, 4.2.2 Interfacce indipendenti dal 9.2 L, M 16 2.1.1, 2.1.2 Gestori di evento per gli script 9.3 L, M 16 2.1.1, 2.1.2 Aperture pop-up e nuove finestre 10.1 1 3.2.1, 3.2.2, 3.2.5 Etichette nei moduli 10.2 14 1.3.1, 1.3.4 L 1.4.1, 1.4.3 dispositivo - 322 - N ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR ARGOMENTO WCAG SECTION DM 1.0 508 2005 WCAG 2.0 Tecnologie e versioni 11.1 1 - Elementi disapprovati 11.2 1 - Descrizioni dei Frame 12.2 2 - Organizzazione informazioni 12.3 Associazioni delle etichette 12.4 N 14 1.3.1, 4.1.2 Destinazione dei collegamenti 13.1 O 19 2.4.4, 2.4.8 Informazioni semantiche 13.2 Indici e mappe del sito 13.3 2.4.2 Meccanismi di navigazione 13.4 3.2.3, 3.2.4 I 2.4.1 TABELLA 7 - TABELLA COMPARATIVA DELLE NORMATIVE SUI PRINCIPI DI LIVELLO TRIPLA-A ARGOMENTO WCAG SECTION DM 1.0 508 2005 WCAG 2.0 Mappe lato client 1.5 - Contrasto colori testo 2.2 Abbreviazioni ed acronimi 4.2 3.1.4 Lingua del documento 4.3 3.1.1 Sommario per le tabelle 5.5 G 9 Abbreviazioni nelle tabelle 5.6 G 9 Tabindex 9.4 2.4.6 Accesskey 9.5 2.4.1 Linearizzazione delle tabelle 10.3 1.3.3, 2.4.6 Caratteri segnaposto nei 10.4 - 10.5 - 6 1.4.1, 1.4.3 controlli Distinguere collegamenti adiacenti Informazioni per preferenze 11.3 utente Barre di navigazione 13.5 3.2.3 - 323 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR ARGOMENTO WCAG SECTION DM 1.0 508 2005 O 19 WCAG 2.0 Organizzazione link in gruppi 13.6 2.4.1 Funzionalità di ricerca 13.7 Organizzazione informazioni 13.8 2.4.5 Relazioni fra pagine 13.9 2.4.7 Arte ASCII 13.10 Fruizione multimodale 14.2 Usare uno stile coerente 14.3 3.1.5 A queste tabelle va aggiunta qualche considerazione per quelle normative che non sono considerate specificatamente nelle WCAG 1.0. In particolare il trattamento delle pagine alternative o solo testo che sono previste come soluzione temporanea dalla legge Stanca al requisito transitorio 22 e come valida alternativa di testo equivalente nella Section 508 al paragrafo (K). In sostanza restano valide le considerazioni iniziali fatte a proposito della distinzione che esiste fra i vari dispositivi. Per cui, adempiere ai requisiti di una non garantisce l’automatica conformità con un'altra. I principi guida di una buona programmazione e di un buon sviluppo restano comunque ben fermi, qualsiasi linea guida si voglia o si debba adottare, e sono quelli esposti nella sezione delle Metodologie Generali di questo lavoro. - 324 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR IV.7 - ISO Alla fine del Gennaio 2006 si è svolto a Venezia l’incontro del gruppo di lavoro ISO ISO/TC 159/SC “Software ergonomics and human-computer dialogues”1. L’ISO (International Organization for Standardization) ha al suo interno dei gruppi di lavoro che da molto tempo si occupano dell’ingegneria del software. Sulla scorta dell’importanza e dell’interesse per i temi dell’accessibilità alcune di queste sezioni si stanno occupando delle norme dedicate all’ergonomia del software per le interfacce delle applicazioni. Questo tipo di studio riguarda sia le applicazioni software che i sistemi operativi che le interfacce delle applicazioni Web (Web-based), con l’obiettivo di fornire dei principi generali per i grandi produttori sull’accessibilità di tali interfacce. Va ricordato, come impostazione generale delle norme ISO, che queste direttive contengono e conterranno solamente una serie di principi di progettazione, senza entrare assolutamente nella materia tecnica. Da questo punto di vista quindi non si pone assolutamente un problema di eventuale conflittualità con le normative esposte in precedenza, tanto più per il fatto che nel gruppo di lavoro sono presenti diversi esperti già presenti nel gruppo di lavoro delle WCAG e negli standard americani. Un effetto sicuramente positivo potrà invece essere ottenuto dal fatto che, una volta stabilito uno standard ISO, sarà possibile certificarlo, permettendo di intervenire non solamente sui siti delle pubbliche amministrazioni come è già ad oggi normato in Italia con la legge Stanca, ma anche su tutti gli enti privati. Da questo punto di vista la certificazione ISO per l’accessibilità del software e delle interfacce per le applicazioni Web potrà sicuramente essere di stimolo per forzare un innalzamento generale della qualità dei siti. Normative Attualmente esiste già una normativa ISO sulle interfacce software mentre altre due sono in sviluppo e dovrebbero essere approvate entro il 2007:  ISO/TS 16071: Ergonomics of human-system interaction -- Guidance on accessibility for human-computer interfaces. Pubblicata il 16 Maggio del 2003;  ISO 9241-151. Ergonomics of human system interaction — Part 151: Software ergonomics for World Wide Web user interfaces. In fase di sviluppo; 1 [http://www.iwa-italy.org/documento.asp?DocID=363] - 325 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  ISO 9241-171. Ergonomics of human-system interaction — Part 171: Guidance on software accessibility. In fase di sviluppo. ISO/TS 16071 Ergonomics of human-system interaction - Guidance on accessibility for humancomputer interfaces. Le ISO/TS 16071 forniscono delle linee guida per la progettazione di software accessibile. Riguardano aspetti associati con la progettazione di interfacce software accessibili per le persone con la più ampia differenza di capacità visive, uditive e motorie, includendo le persone anziane e coloro che sono temporaneamente disabili. Le ISO/TS 16071 riguardano aspetti del software inerenti l’accessibilità che sono di complemento con i principi di progettazione usabile considerate dalle ISO 9241-10 fino alle ISO 9241-17. Le ISO/TS 16071 riguardano l’accessibilità dei sistemi interattivi, considerando una vasta gamma di possibilità, incluse le applicazioni di ufficio, le pagine Web e le presentazioni multimediali. Non fornisce invece informazioni sulla progettazione dell’hardware. Le ISO/TS 16071 promuovono lo sviluppo dell’usabilità dei sistemi interattivi in relazione con le tecnologie assistive, quando sono richieste. Non coprono il comportamento o i requisiti delle tecnologie assistive in se stesse. Sono elaborate all’interno del Comitato tecnico ISO 159: "Ergonomics". Per fare un semplice esempio possono occuparsi di un aumento delle dimensioni dello schermo, del contrasto o della visibilità globale, delle caratteristiche quali video "fuori misura" o dei caratteri di dimensioni più grandi. Compito di questa norma ISO è quindi quello di definire dei principi a cui i produttori di sistemi operativi e di applicazioni dovranno adeguarsi per garantire una completa accessibilità. Sono richiamate espressamente all’interno dell’attuale bozza di lavoro delle ATAG 2.0. ISO 9241-151 Ergonomics of human-system interaction - Part 151: Guidance on World Wide Web user interfaces. La ISO 9241-151 fornisce delle raccomandazioni e delle linee guida per lo sviluppo centrato sull'utente delle interfacce per il World Wide Web con lo scopo di incrementarne l'usabilità. Alcune delle raccomandazioni presenti in questo standard possono essere applicate a differenti interfacce utente, mentre non sono tra gli obiettivi specifici le periferiche di tipo mobile o PDA. Le raccomandazioni si focalizzano sui seguenti aspetti:  Scopi e strategie di un'applicazione Web;  Contenuti e funzionalità;  Navigazione ed interazione;  Sviluppo e presentazione di media. - 326 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Non sono incluse invece indicazioni sull'estetica e sull'arte del design delle interfacce. Questo standard si occupa anche di aspetti altri specifici come:  La veridicità;  La sicurezza;  La credibilità. Tali aspetti non sono considerati dagli standard ISO per le applicazioni e le interfacce, ma dovranno però essere un punto di riferimento per lo sviluppo di interfacce Web essendo comunque degli standard internazionali di ergonomia. Attualmente le raccomandazioni 9241-151 sono in fase di sviluppo e l’ultimo documento valido risale al 3 Novembre del 2006. ISO 9241-171 Ergonomics of human-system interaction - Part 171: Guidance on software accessibility La ISO 9241-171 è un importante contributo alla fruibilità dei sistemi informatici da parte di qualsiasi utente, anche per coloro che soffrono di una disabilità temporanea o permanente. Il documento è finalizzato a dare la possibilità a persone con disabilità di lavorare e usufruire degli applicativi fornendo delle linee guida per programmare software che tengano conto delle varie capacità fisiche e sensoriali dell'utilizzatore finale. Attualmente sono in fase di sviluppo e l’ultimo documento valido risale al 24 Novembre del 2006. IV.8 - UAAG (W3C WAI RECOMMENDATION- 17 DICEMBRE 2002) Come fatto presente in precedenza, il progetto WAI del W3C non contiene solamente le linee guida per l’accessibilità dei siti Web (le WCAG), ma anche linee guida appositamente studiate per i programmi utente (user agent), le cosiddette UAAG (User Agent Accessibility Guidelines). Questa raccomandazione del WAI fornisce le linee guida per lo sviluppo degli User Agent, al fine di diminuire le barriere per l'accessibilità del Web per persone con disabilità (visuali, uditive, fisiche, cognitive e neurologiche). Uno User Agent che risulta conforme alle linee guida promuoverà l'accessibilità attraverso - 327 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR la struttura dell'interfaccia utente e attraverso altre ottimizzazioni interne, includendo la tra queste la capacità di comunicare con altre tecnologie (soprattutto tecnologie assistive). 1 In ogni caso, tutti gli utenti, non solo gli utenti disabili, ottengono maggiore usabilità dagli User Agent che siano conformi a questa raccomandazione. Oltre ad essere di supporto agli sviluppatori di browser, media player ed altro, le UAAG sono inoltre di supporto agli sviluppatori di tecnologie assistive in quanto informano su quali informazioni e controlli una tecnologia assistiva si aspetta di avere a disposizione da uno User Agent conforme. Il documento è composto da:  L'introduzione che fornisce il contesto per comprendere i requisiti;  I dodici principi generali per lo sviluppo accessibile, definiti linee guida. Ogni linea guida consiste in una serie di requisiti chiamati punti di controllo che devono essere soddisfatti per rendere conforme lo User Agent alle raccomandazioni;  Le definizioni e le regole di conformità;  Un glossario;  Un elenco di riferimenti che include dei collegamenti ad altri documenti utili tra cui una griglia di controllo (checklist) che elenca e riassume tutti i punti di controllo per la verifica pratica. Come per le WCAG, i punti di controllo hanno tre livelli di priorità:  Priorità 1: devono essere assolutamente soddisfatti;  Priorità 2: dovrebbero essere soddisfatti;  Priorità 3: devono essere tenuti in considerazione. Vediamo un elenco riassuntivo delle linee guida, senza soffermarci sui punti di controllo. La traduzione italiana è del sito ministeriale2, il contenuto originale può essere facilmente consultato sul sito ufficiale del W3C3. 1. Supportare l'indipendenza dagli strumenti di input e output: Gli utenti devono poter interagire con gli user agent, e con il contenuto che genereranno, attraverso qualsiasi strumento di input ed output; 2. Assicurare l'accesso a tutti i contenuti da parte di tutte le tipologie di utenti: Gli user agent devono permettere l'accesso a tutti i contenuti attraverso una serie di 1 2 3 Roberto Castaldo: [http://www.webaccessibile.org/argomenti/argomento.asp?cat=600] [http://www.pubbliaccesso.gov.it/biblioteca/manualistica/accessibilita_siti/useragent/ linee_guida_1-6.htm] [http://www.w3.org/TR/UAAG10/] - 328 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR meccanismi complementari. Questi devono essere organizzati in modo da sostituirsi l'uno agli altri in caso di mal funzionamento; 3. Permettere agli utenti di configurare gli user agent, in modo che non generino contenuti che riducono l'accessibilità: Gli utenti devono poter bloccare la presentazione di alcuni tipi di contenuti, come audio, video, script che possono, in alcuni casi, ridurre l'accessibilità, oscurando altri tipi di contenuti o disorientando l'utente. 4. Assicurare il controllo da parte degli utenti della presentazione delle pagine: Gli utenti devono poter selezionare, tra le opzioni proposte dagli user agent, gli stili a loro più congeniali relativi per esempio ai colori, alla grandezza del testo mostrato, alle caratteristiche dell'audio sintetizzato. Inoltre, l'utente deve poter modificare gli stili specificati dagli autori e quelli di default degli user agent; 5. Assicurare il controllo da parte dell'utente del comportamento dell'interfaccia: Gli utenti devono poter controllare il comportamento delle schermate e degli altri elementi delle interfacce utenti, inclusi quelli che possono essere manipolati dagli autori; 6. Implementare le interfacce standard dei programmi applicativi: Per accrescere l'accessibilità degli user agent, questi devono comunicare con gli altri software, quali le tecnologie assistive, l'ambiente di sviluppo e i plug-in, attraverso interfacce che seguano gli standard, come le API, Application Programming Interfaces; 7. Osservare le convenzioni dell'ambiente di sviluppo: Seguire le convenzioni dell'ambiente di sviluppo dell'utente, accresce l'accessibilità degli user agent; 8. Implementare le specifiche che promuovono l'accessibilità: Gli sviluppatori devono implementare le specifiche del W3C; 9. Fornire meccanismi di navigazione: Gli utenti devono poter raggiungere sempre l'informazione rilevante all'interno del documento; 10. Permettere all'utente di orientarsi: All'interno del documento, bisogna fornire una serie di informazioni e meccanismi che permettano all'utente di capire il contesto in cui sta navigando; 11. Permettere la configurazione e la personalizzazione degli user agent: Gli utenti devono poter configurare gli user agent in modo da poter accedere in maniera più veloce alle operazioni più frequentemente effettuate e in modo da poter salvare le loro preferenze sullo stile di presentazione del documento, sulla configurazione dell'interfaccia utente grafica, sui comandi da tastiera e su altre caratteristiche; - 329 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 12. Fornire documentazione e sistemi di aiuto accessibili: L'utente deve poter conoscere quali sono le caratteristiche del software che favoriscono l'accessibilità attraverso la documentazione. Vorrei far notare brevemente come la linea guida 4 raccomandi di permettere agli utenti di gestire gli stili applicati al documento, e questo, non solo attraverso la possibilità di sovrapporne uno proprio, ma anche consentendo agli utenti di selezionare ed applicare i fogli di stile alternativi previsti dagli autori1. L’osservanza di questa direttiva permetterebbe di gestire la scelta dei fogli di stile alternativi tramite un più naturale controllo da menù del browser piuttosto che costringere il progettista all’utilizzo degli script. Molti dei browser più recenti si sono adeguati a questa normativa, tra i pochi che ancora impediscono questa utile funzionalità ricordo ancora una volta Internet Explorer. Associati con queste linee guida e con in relativi punti di controllo, le UAAG, forniscono anche una utile griglia di controllo, come per le WCAG. Questa permette di verificare in modo preciso e selettivo i singoli punti di controllo per arrivare ad ottenere una vera dichiarazione di accessibilità dello user agent. Non la riporto per brevità, ma può essere direttamente scaricata e stampata dal sito ufficiale del W3C.2. Esistono anche traduzioni in italiano tra cui segnalo quella di Roberto Scano. 3 IV.9 - ATAG (1.0 - W3C WAI RECOMMENDATION - 21 DICEMBRE 2000) (2.0 - W3C WAI WORKING DRAFT - 7 DICEMBRE 2006) Come abbiamo visto, il progetto WCAG del WAI si concentra sulla possibilità di rendere maggiormente accessibile i contenuti presenti sul Web. D’altro canto, il progetto UAAG presenta delle linee guida concernenti la modalità con la quale i programmi utente dovrebbero essere concepiti per interagire correttamente con in contenuti in rete. A completare questa filosofia d’insieme, il gruppo WAI ha predisposto anche delle linee guida per i programmi utilizzati dagli autori delle pagine Web per creare le informazioni. Sono le 1 UAAG 4.14: “Allow the user to choose from and apply alternative author style sheets (such as linked style sheets).” - [http://www.w3.org/TR/UAAG10-TECHS/intro.html#tech-select-style-sheets] 2 [http://www.w3.org/TR/UAAG10/uaag10-chktable.html] 3 Roberto Scano: “Accessibilità, dalla teoria alla realtà” - 330 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR cosiddette ATAG (Authoring Tools Accessibility Guidelines), ossia linee guida per l'accessibilità degli strumenti di sviluppo. Le finalità di queste raccomandazioni del W3C per chi produce i programmi di sviluppo sono duplici:  Avere dei sistemi di sviluppo che generino per impostazioni predefinite dei contenuti accessibili al fine di supportare ed incoraggiare gli sviluppatori a creare contenuti di qualità;  Avere dei sistemi di sviluppo che possiedano delle interfacce accessibili agli autori di contenuti, senza discriminarne la disabilità. A tale proposito, una forte spinta si è avuta negli ultimi anni anche dal Parlamento Europeo. Con la già citata e fondamentale risoluzione1 del Parlamento Europeo (2002)0325 sulla comunicazione della Commissione "eEurope 2002: accessibilità e contenuto di siti Internet delle amministrazioni pubbliche", al punto K, si è esplicitamente fatto riferimento alle raccomandazioni ATAG. Al punto 4 poi, della medesima risoluzione, gli stati europei sono esortati a conformarsi alle Authoring Tools Accessibility Guidelines (ATAG) 1.0, sempre entro il 2003, al fine di consentire ai disabili non soltanto di leggere le pagine Web ma anche di gestirne il contenuto. Il documento non specifica però il livello di conformità minimo richiesto per le ATAG 1.0: parlando di conformità è comunque scontato quantomeno il raggiungimento del livello A della raccomandazione W3C per l'accessibilità degli strumenti di sviluppo. La finalità delle ATAG, quindi, è quella di offrire a tutti gli utenti la possibilità di creare contenuti accessibili2, tenendo conto del fatto che gli strumenti di sviluppo utilizzati per generare queste informazioni siano anch'essi accessibili e che possano essere utilizzati anche dai soggetti con disabilità. Versione 2.0 Allo stato attuale dei lavori è appena stato rilasciato un Working Draft delle ATAG 2.0 il 7 dicembre del 2006. Le ATAG 2.0 sono state progettate per essere compatibili con le WCAG 2.0, oltre che con le precedenti WCAG 1.0. 1 2 [http://www4.europarl.eu.int/registre/recherche/NoticeDetaillee.cfm?docid=6886& doclang=IT] “Everyone should have the ability to create and access Web content.” – [http://www.w3.org/TR/ATAG20/] - 331 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Il gruppo WAI è intenzionato a portare a termine la nuova versione per la fine del 2007, ma il tempo di completamento non è predicibile. Fino al loro definitivo rilascio il documento di riferimento resta quello delle ATAG 1.0. Dato che le ATAG non rappresentano il fulcro di questo lavoro, preferisco riferirmi comunque in questa breve sezione alla versione 2.0 nonostante non sia ancora quella stabile ed ufficiale. Le differenze fondamentali sono:  Ristrutturazione delle linee guida secondo la metodologia delle nuove WCAG 2.0;  Considerazione delle nuove tecnologie per il Web tra cui i CMS (Content Management System);  Adeguamento ai nuovi riferimenti alle WCAG 2.0;  Considerazione1 della normativa ISO TS/16071 2002 che regola l’accessibilità delle interfacce umane con il computer e contiene specificatamente delle linee guida sull’accessibilità delle applicazioni. Vi sono diverse categorie di strumenti di sviluppo che possono essere coinvolti dalle direttive contenute nelle ATAG 2.0. Un elenco informativo è contenuto nello stesso documento del W3C e sono direttamente citate nel documento di tecniche al momento di fare degli esempi pratici di applicazione dei principi. All'interno di un singolo strumento di sviluppo integrato, le diverse parti dell'interfaccia possono ricadere in una o più delle tipologie di funzionalità descritte in seguito. Le tipologie di funzionalità di sviluppo implementate aiuteranno a determinare quale delle tecniche previste dalle ATAG 2.0 sono applicabili ad un particolare strumento:  Funzionalità di sviluppo a livello di codice. L'autore ha il controllo completo su tutte le funzioni riguardanti il risultato finale del contenuto Web. Questo riguarda, ma non solo, la gestione di testo e la gestione di ambienti visuali di sviluppo creati per consentire all'autore la stessa libertà di controllo garantito dalla gestione del testo (per esempio, sistemi di gestione del posizionamento degli elementi in modalità grafica). Un esempio può essere un editor di testo;  Funzionalità di sviluppo WYSIWYG (What-You-See-Is-What-You-Get). L'autore ha il controllo sulle entità che assomigliano molto all'apparenza e al comportamento finale del contenuto Web risultante. Un esempio può essere fornito da editor che gestiscono pagine Web, editor che consentono la gestione di immagini bitmap, eccetera; 1 [http://www.w3.org/WAI/AU/2006/WD-ATAG20techs-20060711/tech1.htm] - 332 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Funzionalità di sviluppo orientata agli oggetti. L'autore ha il controllo delle entità non WYSIWYG che rappresentano un'astrazione funzionale delle funzioni di basso livello per il risultato del contenuto Web. Un esempio può esser dato da linee temporali, editor basati su grafica vettoriale, eccetera;  Funzionalità di sviluppo indirette. Gli autori hanno il controllo solamente per parametri di alto livello relativi alla produzione automatizzata di contenuti Web risultanti. Questi possono includere le interfacce che assistono l'autore nella creazione e nell'organizzazione dei contenuti Web senza che l'autore abbia il controllo sulla marcatura o su implementazioni di programmazione. Esempi possono essere: sistemi di gestione contenuti (CMS), sistemi automatizzati per la creazione di siti Web, sistemi di gestione per siti Web, corsi on-line, sistemi di Weblog, aggregatori di contenuti, strumenti di conversione, eccetera. Le ATAG 2.0 sono accompagnate da un documento di tecniche che illustra come possono essere soddisfatti i principi guida. Contenuti Le ATAG 2.0, nel Working Draft del dicembre 2006, sono organizzate in parti, linee guida, punti di controllo e criteri di successo. Vediamo un rapido elenco per sommi capi delle due parti e dei punti di controllo relativi. Parte A. Rendere accessibile l’interfaccia utente degli strumenti di sviluppo. I punti di controllo di questa sezione sono progettati per incrementare le capacità di creazione per gli autori disabili. Per questo motivo le specifiche sono strettamente incentrate sull’accessibilità dell’interfaccia utilizzata dai progettisti per il loro lavoro:  Linea guida A.1: “L’interfaccia utente degli strumenti di sviluppo deve essere percepibile.”. Perché uno strumento di sviluppo possa dirsi accessibile, gli autori devono essere in grado di percepire i controlli della propria interfaccia utente;  Linea guida A.2: “L’interfaccia utente degli strumenti di sviluppo deve essere fruibile.”. Perché uno strumento di sviluppo possa dirsi accessibile, gli autori devono essere in grado di operare con i controlli della propria interfaccia utente;  Linea guida A.3: “L’interfaccia utente degli strumenti di sviluppo deve essere Comprensibile.” Perché uno strumento di sviluppo possa dirsi accessibile, gli autori devono essere in grado di comprendere i controlli della propria interfaccia utente che possono percepire ed utilizzare; - 333 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Linea guida A.4: “L’interfaccia utente degli strumenti di sviluppo deve essere compatibile con le modalità di accesso al sistema.”. Le tecnologie assistive come ad esempio gli screen-reader e gli ingranditori possono garantire un miglioramento della visualizzazione e del controllo ai loro utenti solamente se gli strumenti di sviluppo supportano e documentano i protocolli di documentazione su cui sono basati. Parte B Supportare la produzione di contenuti accessibili. I punti di controllo della parte B sono concepiti per incrementare l’accessibilità dei contenuti Web prodotti da qualunque autore per un utente finale disabile. Sebbene i requisiti di questa parte non si occupino direttamente dell’accessibilità dell’interfaccia utente degli strumenti di sviluppo, va notato che qualunque aspetto integrato per soddisfare la parte B deve anche soddisfare le richieste di accessibilità dell’interfaccia utente definite nella parte A.  Linea guida B.1: “Consentire la produzione di contenuti accessibili.”. La creazione di contenuto accessibile è in relazione al comportamento dello strumento di sviluppo e dell’autore. Questa linea guida definisce le responsabilità specifiche dello strumento di sviluppo;  Linea guida B.2: “Agevolare l’autore nella produzione di contenuti accessibili.”. Alcune azioni intraprese dallo sviluppatore potrebbero portare alla creazione di pagine inaccessibili. In queste situazioni lo strumento di sviluppo dovrebbe includere delle caratteristiche che forniscano direttive e supporto agli autori in modo che possano essere seguite le corrette prassi di sviluppo per produrre contenuti Web accessibili;  Linea guida B 3: “Promuovere ed integrare le soluzioni accessibili.” Questa linea guida richiede che gli strumenti di sviluppo debbano incoraggiare una prassi di sviluppo accessibile al loro interno, così come favorire l’integrazione di caratteristiche a supporto dell’accessibilità che siano state aggiunte per soddisfare gli altri requisiti di questo documento. Conformità Ogni punto di controllo ha assegnato un livello di priorità che ne indica l’importanza e determina quali di questi debbano essere soddisfatti per permettere allo strumento di sviluppo di raggiungere uno specifico livello di conformità. Ci sono due tipologie di punti di controllo, quelli con priorità regolare e quelli con priorità relativa alle WCAG. - 334 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Punti di controllo a priorità regolare I punti di controllo hanno delle priorità il cui significato dipende dalla parte della normativa in cui si trovano:  Priorità di livello 1: il punto di controllo è essenziale per l’accessibilità: o Parte A: Se lo strumento di sviluppo non soddisfa questo punto di controllo uno o più gruppi di sviluppatori disabili troveranno impossibile produrre pagine Web usando lo strumento; o Parte B: il punto di controllo è essenziale per aiutare tutti gli sviluppatori a creare contenuti Web conformi alle WCAG;  Priorità di livello 2: il punto di controllo è importante per l’accessibilità: o Parte A: Se lo strumento di sviluppo non soddisfa questo punto di controllo uno o più gruppi di sviluppatori disabili troveranno difficoltoso produrre pagine Web usando lo strumento; o Parte B: il punto di controllo è importante per aiutare tutti gli sviluppatori a creare contenuti Web conformi alle WCAG;  Priorità di livello 3: il punto di controllo favorisce l’accessibilità: o Parte A: Se lo strumento di sviluppo non soddisfa questo punto di controllo uno o più gruppi di sviluppatori disabili troveranno inefficiente produrre pagine Web usando lo strumento; o Parte B: il punto di controllo è vantaggioso per aiutare tutti gli sviluppatori a creare contenuti Web conformi alle WCAG. Punti di controllo a priorità relativa Esistono dei punti di controllo con delle priorità definite come relative. Sono delle priorità che fanno riferimento alla versione delle WCAG a cui il valutatore ha scelto di riferirsi per le specifiche. L’importanza di ogni punto di controllo a priorità relativa dipende dalle specifiche delle WCAG a cui si riferiscono. Questi punti di controllo possono essere soddisfati a 3 livelli di priorità:  Priorità relativa livello 1: sono stati soddisfatti i punti di controllo a livello A delle WCAG di riferimento;  Priorità relativa livello 2: sono stati soddisfatti i punti di controllo a livello doppia-A delle WCAG di riferimento;  Priorità relativa livello 3: sono stati soddisfatti i punti di controllo a livello tripla-A delle WCAG di riferimento. Se un creatore di uno strumento di sviluppo intende dichiarare la conformità alle ATAG 2.0 del suo prodotto, deve prima definire un documento di verifica specifico in relazione alle WCAG che - 335 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR intende usare, successivamente, per ogni punto di controllo a priorità relativa delle ATAG 2.0, deve utilizzare tale documento come verifica per determinare se i criteri di successo sono stati soddisfatti. Livelli di conformità Come conseguenza del soddisfacimento delle precedenti linee guida nei relativi criteri di successo, uno strumento di sviluppo può dichiarare la sua conformità alle ATAG 2.0 secondo tre livelli di qualità. Il livello raggiunto dipende dalla priorità di quei punti di controllo per i quali lo strumento di sviluppo ha soddisfatto i relativi criteri di successo. I livelli sono:  Livello A: lo strumento di sviluppo ha soddisfatto tutti i punti di controllo a priorità regolari di livello 1, ed anche tutti i punti di controllo a priorità relativa almeno di livello 1;  Livello Doppia-A: lo strumento di sviluppo ha soddisfatto tutti i punti di controllo a priorità regolari di livello 1 e 2, ed anche tutti i punti di controllo a priorità relativa almeno di livello 2;  Livello Tripla-A: lo strumento di sviluppo ha soddisfatto tutti i punti di controllo a priorità regolari, ed anche tutti i punti di controllo a priorità relativa fino al livello 3. Da notare, come del resto anche per le altre raccomandazioni del W3C, che la pretesa di conformità a qualunque livello non implica che il W3C abbia verificato la dichiarazione o che ne garantisca la validità. I dichiaranti sono i soli responsabili della correttezza della loro dichiarazione e del suo aggiornamento. IV.10 - ARIA (W3C WAI WORKING DRAFT – UPDATED 20 DICEMBRE 2006) Il 26 settembre 2006 la Web Accessibility Initiative (WAI) del W3C ha presentato una raccolta di documenti che rende più facile agli sviluppatori di siti Web rendere il contenuto Web dinamico usabile da persone disabili, si tratta della suite di protocolli WAI-ARIA (Accessible Rich Internet Application). Le motivazioni e le finalità di questa suite di protocolli sono quelle esposte Rich Schwerdtfeger, Distinguished Engineer dell'IBM e autore della WAI-ARIA Roadmap: Mentre gli utenti richiedono sempre più al Web - più informazioni, più applicazioni interattive ed esperienze coinvolgenti - si assiste ad un’esplosione nello sviluppo di tecnologie, che esclude però dall'accesso al Web un numero troppo elevato di persone. La pubblicazione di questa nuova suite di documenti è importante perché aiuterà gli sviluppatori ad avere accesso ai tool necessari al supporto di utenti disabili sul Web. ARIA è il primo passo per fornire - 336 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR l'accesso ad una più ricca esperienza del Web dinamico a tutti gli utenti del Web, attraverso miglioramenti nelle tecnologie, ad esempio implementazioni migliori e più accessibili.1 Web dinamico accessibile Il Web dinamico attualmente esclude milioni di utenti. Le tecnologie assistive, inclusi screen-reader, software d’interpretazione vocale e tastiere sullo schermo, aiutano a rendere il Web accessibile a utenti disabili. Per funzionare, questi strumenti necessitano di informazioni sulla semantica di porzioni specifiche di un documento, per poterle poi presentare in formato accessibile. Ad esempio, per poter accedere in modo attendibile a un elemento, uno strumento deve essere in grado di riconoscere anche lo stato dell'elemento stesso se è, ad esempio, selezionato o disabilitato, se ha il focus, se è chiuso o nascosto. I siti Web stanno offrendo sempre più applicazioni con capacità paragonabili al software installato localmente sulla macchina. Queste applicazioni Internet più complete (rich internet applications) fanno un pesante uso di scripting e gli sviluppatori includono spesso forme ibride di tecnologie già esistenti, come AJAX, DHTML, JavaScript e SVG. Tuttavia queste applicazioni non sempre forniscono la semantica necessaria al supporto delle tecnologie assistive utilizzate e gli utenti disabili rischiano quindi di essere tagliati fuori da questo nuovo modo di presentare l’informazione. Le ARIA Suite specificano come rendere accessibili alle persone disabili le caratteristiche più avanzate dei contenuti dinamici e delle applicazioni internet più complete rendendo accessibili i controlli dell’interfaccia utente (come ad esempio l’espansione dei menù di navigazione) alle tecnologie assistive. Schema del progetto Per il momento il progetto ARIA è in fase di definizione, è stato annunciato nel Settembre del 2006 come una raccolta di documenti che costituiscono un framework per realizzare contenuti Web dinamici accessibili. Le attuali documentazioni della ARIA sono state progettate per:  Sviluppatori di browser, tecnologie assistive e programmi utente;  Sviluppatori di tecnologie Web (come specifiche tecniche);  Sviluppatori di strumenti per la valutazione dell’accessibilità. Il First Public Working Draft di WAI-ARIA Suite include: 1 [http://www.w3c.it/pr/2006/aria-pressrelease-it.html] - 337 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  WAI-ARIA Roadmap;  WAI-ARIA Roles;  WAI-ARIA States and Properties. In oltre, per gli sviluppatori di contenuti Web e di strumenti di creazione delle pagine Web, una documentazione a parte dovrebbe illustrare le migliori tecniche per implementare le ARIA nei contenuti Web. WAI ritiene che le ARIA dovrebbero svilupparsi dallo stato di Last Call fino a diventare delle Recommendation ufficiali del W3C entro il 2007. ARIA Roadmap La Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap) descrive un approccio generale per assicurare l'interoperabilità tra le applicazioni Internet più complete e le tecnologie assistive utilizzate da persone con disabilità. L'approccio si basa sulle tecnologie già sviluppate o in fase di sviluppo da parte del W3C. Il roadmap delle ARIA definisce che tipo di tecnologia debba essere impiegata per rendere accessibili il contenuto Web dinamico e le applicazioni internet complesse. Viene considerata anche una analisi delle attuali lacune, di cosa sia necessario, di cosa sia disponibile e di cosa sia ancora del tutto mancante per assicurare applicazioni internet complete ed accessibili. Due documenti spiegano come colmare queste lacune:  Roles for Accessible Rich Internet Applications (WAI-ARIA Roles);  States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States). I browser Web e gli altri programmi utenti impiegano le API (Application Program Interface) per comunicare con le tecnologie assistive, il piano di sviluppo delle ARIA chiarisce quali aspetti del Web dinamico debbano essere messi a disposizione tramite API di accessibilità. Il roadmap indica le tecnologie per mappare i controlli, le regioni attive AJAX e gli eventi per le API della accessibilità, inclusi i controlli proprietari utilizzati per le applicazioni internet più complete. In oltre delinea anche le nuove tecniche di navigazione per contrassegnare le comuni strutture Web, come ad esempio i menu, i contenuti primari e secondari, i banner informativi e gli altri tipi di strutture Web. Queste nuove tecnologie possono essere utilizzate per incrementare l’accessibilità e l’usabilità delle risorse Web per le persone disabili senza sostanziali modifiche all’insieme di quelle esistenti. - 338 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR ARIA Roles Le regole ARIA forniscono un dizionario delle caratteristiche della pagina Web per le interazioni con l’utente, includendo le destinazioni per la navigazione e i widget interattivi. Alcuni esempi sono:  Barre di navigazione;  Liste espandibili e collassabili, denominate controlli ad albero. ARIA States and Properties Gli stati e le proprietà permettono ai linguaggi XML di esprimere come gli aspetti delle pagine Web si relazionino una con le altre, e quali sono i loro stati correnti. Esempi sono:  Relazioni, ad esempio quando un widget controlla il contenuto di un’altra parte di un documento Web;  Gli stati, ad esempio se un dato ramo di una lista ad albero sia in un certo momento espanso o collassato. - 339 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR V. L’accessibilità nella realtà In questa sezione vorrei presentare la materia nei suoi aspetti più pratici, esponendo l’esperienza concreta e riportando osservazioni utili alle persone disabili nella loro realtà quotidiana di utenti del Web. Una prima carrellata dei dispositivi e delle tecnologie assistive verrà seguita da informazioni sulla accessibilità e sulla disponibilità di software adeguato. Infine, riportando l’esperienza e le conoscenze di persone che lavorano in questa realtà ho inteso presentare qualcosa di più aggiornato e concreto sullo stato attuale delle conoscenze in materia. V.1 - Ausili informatici per i disabili Alcune categorie di disabili sensoriali e motori possono avvalersi di strumenti o programmi che permettono loro di svolgere delle attività che altrimenti non sarebbero in grado di compiere. Si tratta delle cosiddette tecnologie compensative, dette anche tecnologie assistive o ausili. Per molti tipi di disabilità esistono delle corrispondenti tecnologie ed attrezzature specifiche progettate appositamente per favorire l’interazione con il computer. Un valido elenco di tali dispositivi, corredato anche da una opportuna descrizione può essere consultato sul sito della fondazione ASPHI Onlus1. Per altri approfondimenti, soprattutto per i disabili visivi, si consiglia anche la visita al sito2 dell’ANS (Associazione Nazionale Subvedenti). Ricordo che, oltre le tecnologie di ausilio, sono disponibili anche delle configurazioni specifiche che possono essere predisposte direttamente dal sistema operativo o dal software in esecuzione sul computer stesso. Qui presento un piccolo riassunto degli strumenti più rilevanti, come esposto ancora una volta sul sito ufficiale del ministero3 e come indicato anche sul sito di WebAccessibile4. Strumenti per i non vedenti Quando i non vedenti usano un computer non hanno, solitamente, difficoltà ad utilizzare come sistema di input la normale tastiera. Invece, è assolutamente impossibile per i non vedenti usare il mouse, in quanto la percezione e l'utilizzo di uno spazio dimensionale risulta a loro precluso. 1 2 3 4 [http://www.asphi.it/TecnologiaAusili/TecnologiaAusili.htm] [http://www.subvedenti.it/Ausili.asp] [http://www.pubbliaccesso.gov.it/biblioteca/manualistica/accessibilita_siti/introduzione/ profili.htm] Roberto Castaldo: [http://www.webaccessibile.org/argomenti/documento.asp?DocID=425] - 340 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Lo strumento maggiormente usato dalle persone non vedenti è lo screen-reader. Screen-reader Si tratta di programmi che interpretano i contenuti testuali mostrati dalle applicazioni o dal sistema operativo. Lo screen-reader è in grado di descrivere in modo testuale ciò che appare sullo schermo e le operazioni del programma in funzione. Una volta interpretati dallo screen-reader, i testi vengono presentati al non vedente da una barra Braille o da un dispositivo di sintesi vocale. Pertanto sono condizione indispensabile per l’accesso al computer da parte di una persona non vedente. Gli screen-reader più conosciuti sono:  Freedom Scientific JAWS;  Dolphin Hal;  GW Micro Window Eyes;  IBM Home Page Reader;  Alva OutSpoken. Entreremo nel merito di questi strumenti in una sezione apposita. Barra Braille Alla base del funzionamento della barra Braille vi è il linguaggio Braille, che è un sistema di scrittura basato su simboli puntiformi in rilievo. Ciascuna lettera o numero è simbolizzato dalle diverse combinazioni di sei o otto punti disposti in celle di due colonnine di quattro punti ciascuna. Esistono due versioni dell’alfabeto Braille: una versione classica a 6 punti e una versione informatica ad 8 punti, per una migliore corrispondenza con il codice ASCII. Questi caratteri vengono decifrati dai non vedenti sfiorando con i polpastrelli le combinazioni di punti in rilievo. La barra Braille, o display Braille, è uno strumento informatico che, sollevando e abbassando i punti di una sequenza di celle, fornisce al non vedente una linea scritta in Braille. - 341 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Figura 8 – Una Barra Braille Attraverso questa linea è possibile la lettura tattile di ciò che lo screen-reader trasmette via via che l'utilizzatore esplora il monitor per mezzo di appositi tasti. Sintetizzatore vocale Esistono apparecchiature o software che, campionati opportunamente, producono una voce sintetica utilizzabile per la lettura a voce alta dei testi che appaiono sul monitor e interpretati dagli screen-reader. La campionatura avviene sulla base di combinazioni di suoni elementari, di regole desunte da modelli matematici dell'apparato umano e su algoritmi di analisi del testo scritto. Attualmente, i sintetizzatori vocali leggono secondo le preferenze dell'utente. In particolare è possibile selezionare la lingua, il soggetto parlante (maschile o femminile), il tono e il modo di lettura (continuativo, parola per parola, per singole lettere alfabetiche, con o senza punteggiatura). Stampanti Braille Vi sono stampanti Braille appositamente create per riprodurre in rilievo, su carta, testi in formato ASCII. Figura 9 - Una stampante Braille - 342 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Esse funzionano all'incirca come le normali stampanti, anche se presentano qualche problema legato alla velocità d’esecuzione. Le stampanti Braille sono un po' più lente, poiché devono sbalzare i punti in rilievo su una carta di adeguato spessore, con parti meccaniche in movimento molto più pesanti di una normale stampante ad inchiostro. Scanner Non sono specifici ausili per persone non vedenti, perché si usano normalmente per acquisire immagini e documenti. La loro diffusione in qualsiasi ambiente lavorativo costituisce un vantaggio per chi ha problemi di accesso alle informazioni, poiché può avvalersi di uno strumento già comunemente in uso. L’impiego di uno scanner come ausilio per i non vedenti consiste nell’acquisizione di testi stampati su carta e nella loro conversione in documenti digitali grazie a programmi OCR (Optical Character Recognition). Dopo questa trasformazione i documenti possono essere agevolmente letti tramite screen-reader. Software utilizzati dai non vedenti I non vedenti utilizzano diversi software per agevolarsi nella lettura del contenuto; tra questi:  Browser grafici (Internet Explorer o Netscape Navigator) o browser testuali (Lynx), in combinazione con uno screen-reader con sintesi vocale o riga Braille;  Programmi di formattazione Braille, come Italbra o Duxbury Braille Translation: software in grado di trasformare in Braille qualsiasi testo che può essere stampato in rilievo dall'apposito hardware. Strumenti per ipovedenti Gli strumenti di ausilio utilizzati dagli ipovedenti sono:  Gli ingranditori, software con la funzione di aumentare le dimensioni di ciò che appare sul monitor. L'ingrandimento riduce la porzione di schermo che può essere consultata. Con un sistema di ricerca, comandato in genere con il mouse, è possibile selezionare la parte di video che interessa.  Le funzioni di zoom offerte dai vari programmi. Nel Web, in particolare, ci sono molte possibilità offerte dai browser stessi per ingrandire i caratteri. Ingranditori Gli ingranditori sono programmi che si installano sul PC che ingrandiscono, alcuni anche fino a 32 volte, quanto è presente sullo schermo. Ovviamente la persona dovrà usare continuamente il mouse per scorrere le finestre, di cui vedrà soltanto una piccola parte per volta. - 343 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Molti ingranditori hanno anche una sintesi vocale, che permette di leggere lunghi documenti senza guardarli. Gli ingranditori più conosciuti sono:  Ai Squared Zoomtext;  Visulex Lp (dos/Windows);  Dolphin Lunar;  Freedom Scientific Magic. Leggibilità dei testi La leggibilità dei testi è un aspetto rilevante per rendere le pagine accessibili alle persone ipovedenti. In ogni caso, la creazione di testi leggibili favorisce tutti gli utenti del Web. La leggibilità è condizionata soprattutto:  Dal contrasto tra il colore del testo e il colore dello sfondo;  Dal tipo di font dei caratteri;  Dalle dimensioni dei caratteri;  Dallo spessore e dalla nitidezza del tratto;  Dalla distanza tra i caratteri e tra le righe. Bisogna, inoltre, ricordarsi che c'è differenza tra la leggibilità dei testi e quella delle scritte realizzate come immagini. Per i primi si può pensare che alcuni aspetti possono essere modificati direttamente dall'utente, come la grandezza dei font. Invece, per i testi fissi realizzati tramite immagini, bisogna assolutamente ricordarsi di non usare caratteri piccoli. Il testo risulterebbe inaccessibile e rimarrebbe tale, in quanto non modificabile dall'utente se non tramite un ingranditore di schermo. Va fatto notare che finalmente le versioni più recenti dei browser incominciano a permettere anche un ingrandimento delle immagini. Accorgimenti per audiolesi Per favorire le persone non udenti bisogna porre attenzione all'uso di specifici elementi. In particolare:  I suoni significativi, come quelli di allarme, devono essere accompagnati da equivalenti segnalazioni visive;  I dialoghi importanti ai fini della comprensione dei contenuti devono essere fruibili tramite il classico metodo della sottotitolazione;  Il linguaggio deve tener conto delle difficoltà degli audiolesi congeniti. Essi non riescono a comprendere facilmente testi astratti o contenenti frasi elaborate. Per questo bisogna utilizzare un linguaggio chiaro e semplice, favorendo così tutte le categorie di utenti. - 344 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Strumenti per le disabilità motorie La disabilità motoria presenta problematiche differenti e per ogni individuo è necessario personalizzare gli ausili. Molto spesso più che di ausilio si deve parlare di sistema ausilio. Questo perché il semplice ricorso, ad esempio, ad una tastiera ingrandita non può risolvere il problema se non è integrata da funzioni che permettano di gestire la tastiera stessa in modo coerente con le esigenze della persona. Le principali categorie di ausili informatici per disabili motori sono:  Tastiere espressamente costruite;  Sensori;  Altre periferiche di input e di output specializzate. Tastiere Esistono tastiere costruite espressamente per utenti disabili:  Le tastiere espanse differiscono da quelle normali per la maggior dimensione dei tasti e per la maggior distanza tra essi. Sono adatte, quindi, per gli utenti che hanno difficoltà nella motricità fine. Queste tastiere dispongono, in genere, anche di altri accorgimenti utili, come: la gestione facilitata dei tasti multipli, la regolazione del tocco, i tasti concavi e non sporgenti;  Le tastiere ridotte raggruppano tutti i tasti standard in una piccola superficie. Sono indicate quando la motricità fine è discretamente conservata, mentre risulta compromessa la capacità di dominare, con l'articolazione del braccio, un'area abbastanza vasta;  Le tastiere riconfigurabili sono aree piane sensibili al tocco, la cui superficie viene divisa in tante zone rettangolari corrispondenti ai vari tasti. La dimensione, la posizione e il carattere assegnato a queste aree non è però costante, ma dipende dalla mascherina (un foglio di plastica o carta contenente il disegno della tastiera) che viene applicato. La stessa tastiera può, quindi, essere usata in vari modi, secondo i bisogni ed i progressi dell'utente. - 345 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Figura 10 – Una tastiera con tasti ingranditi Sensori Si adattano a persone che possono muovere solo una parte del corpo e vengono generalmente associati ad un programma a scansione. Ne esistono di tantissimi tipi e possono essere comandati con la parte del corpo che è meglio controllabile dalla persona. Alcuni utilizzano persino una cannuccia a soffio per rilevare il comando dell’utente. Il programma fa scorrere i caratteri sullo schermo e, quando la persona trova quello che desidera utilizzare, lo porta nel testo tramite il sensore collegato al suo computer. Altre periferiche di input ed output particolari Se l'utente non è in grado di gestire la tastiera in modo diretto, occorre impiegare strumenti di input alternativo. Ad esempio: mouse particolari o programmi di riconoscimento vocale, tastiere virtuali o puntatori configurabili Due sono, attualmente, le strade percorribili: i sistemi a scansione e l'immissione a voce. Nei sistemi comandati a voce, per esempio, al computer viene applicato un microfono, una scheda audio e un software di riconoscimento vocale che consente di riconoscere un certo numero di parole dettate dall'utente e di associarle a comandi. Gli strumenti per le disabilità cognitive. Tra i vari strumenti di ausilio per i disabili cognitivi, ci sono tastiere e schermi speciali. Tastiere Esistono una serie di tastiere semplificate per facilitare l'uso del computer da parte dei disabili cognitivi e non solo. Esse risultano adatte in casi di difficoltà cognitive, nel momento in cui si renda necessario ridurre il numero di stimoli potenzialmente confusivi. - 346 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Figura 11 - Una tastiera per disabili cognitivi Infatti, la maggior parte di esse ha tasti molto grandi e differenziati per colori in base alle funzioni svolte. Schermo tattile (touch screen) Il touch screen o schermo tattile è una superficie trasparente che si applica sul monitor e che assolve completamente le funzioni del mouse. Toccando la superficie in corrispondenza del bersaglio si ottiene un clic. Non è necessario trascinare il puntatore per spostarlo, ma questo appare nel punto di contatto. Lo schermo tattile può essere di aiuto in caso di difficoltà cognitive, in quanto richiede, per interagire col computer, azioni molto immediate e istintive. Conclusioni A conclusione di questa panoramica, si può affermare che un sito accessibile può essere navigato anche da persone con disabilità molto gravi, che utilizzano ausili o periferiche specialistiche. In genere chi crea un sito deve aver presente i molti modi di lavorare di una persona con questi problemi, ma non ha il bisogno di preoccuparsi specificatamente di quale modalità utilizzi per l’accesso al computer. Naturalmente, rendersi conto di cosa significhi lavorare con periferiche particolari è fondamentale, ma per realizzare un sito accessibile non è necessario considerare il risultato dato dalla navigazione con ogni singolo dispositivo. 1 Questo perché la compatibilità con gli standard garantisce la progettazione di un sito accessibile, questo almeno in linea di principio, dal momento che i produttori di queste tecnologie software ed hardware spesso hanno gli stessi problemi di allineamento ai protocolli WAI W3C che manifestano anche i maggiori produttori di browser e user agent. 1 Roberto Castaldo: [http://www.webaccessibile.org/argomenti/documento.asp?DocID=425] - 347 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR A complicare la situazione, occorre aggiungere che, almeno in Italia, le tecnologie assistive non sembrano poter contare su una situazione felice. In genere o i disabili non le ricevono mai o continuano a cambiare con frequenza eccessiva1. V.2 - Programmi utente In un discorso completo sugli elementi dell’accessibilità, come questa tesi vuole essere, è necessario fermarsi sulla definizione degli strumenti che vengono utilizzati con più frequenza per accedere alle pagine internet. Tali componenti giocano un ruolo essenziale nel nostro discorso sull’accessibilità. Il software grazie al quale un utente interagisce con il contenuto internet è di primaria importanza per le comunicazioni veicolate da un sito e questo riguarda gli strumenti che possono essere utilizzati sia da disabili che da persone normodotate. Una prima definizione può essere direttamente recuperata dal glossario delle WCAG, riportato in appendice: per user agent (programmi utente o interpreti) si intende un software per l'accesso al contenuto Web, inclusi browser grafici per desktop, browser testuali, browser vocali, cellulari, lettori multimediali, plug-in, e alcuni software di tecnologia assistiva usati congiuntamente a browser come lettori di schermo, ingranditori di schermo, e programmi per il riconoscimento della voce2. Su questa definizione non c’è molto da aggiungere, tranne il fatto che vi sono ovviamente inclusi programmi per l’interazione con le pagine Web sia da parte di persone disabili che da parte di utenti normodotati, e questo in piena coerenza con la definizione di accessibilità di un sito Web. In effetti, per User Agent si intende qualsiasi prodotto che rende disponibile contenuti per il Web all'utente. Screen-reader Il tema degli screen-reader è talmente importante per la comunità delle persone disabili che spesso i primi test che si conducono su una pagina Web per giudicare la sua accessibilità sono compiuti con strumenti di questo tipo. Per questo ho deciso di dedicare una breve sezione riepilogativa su questi strumenti, la stesura è basata sull’interessante articolo di Riccardo Franco 3 apparso su LAU (Laboratorio di Accessibilità ed Usabilità) nel 2005. 1 2 3 Luca Mascaro: Seminario IWA, Arese, Maggio 2005. WCAG 1.0: Glossario [http://lau.csi.it/testare/accessibilita/test_user-agent/screen_reader/panoramica.shtml] - 348 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Gli screen-reader erano tra gli strumenti per ipovedenti più diffusi anche prima della comparsa dei sistemi operativi con interfaccia grafica. Nelle loro prime versioni si sposavano perfettamente con l’interfaccia a caratteri del DOS ed erano impiegati per fornire la traduzione in voce del contenuto dello schermo a caratteri. Tra questi programmi di lettura schermo si ricordano: Parla, Filtro vocale, e Hal per DOS. L'introduzione degli elementi grafici e soprattutto l’utilizzo del mouse hanno fatto nascere nuovi problemi dal punto di vista degli screen-reader, ad esempio per impiegare i comandi da tastiera per il puntamento con mouse o per leggere gli elementi non testuali. Un’ottima soluzione alla questione fu il mouse da tastiera, un sistema che permette di simulare l’uso del mouse tramite la tastiera, scorrendo e attivando gli elementi della pagina. Tale soluzione è molto intuitiva e semplice, tanto che ancora oggi questa è quella standard degli screen-reader. Nel corso degli anni, con l’aumento di programmi, gli screen-reader hanno dovuto mantenersi aggiornati, permettendo l’uso da tastiera dei principali applicativi. L’elemento discriminante che ha reso alcuni screen-reader più usati di altri è stato proprio l’aggiornamento ed il supporto di programmi. Inoltre una questione importante è anche il supporto con display Braille. Un accenno ai prodotti in commercio si trova nella sezione degli ausili informatici per disabili. Ricordo quelli più importanti:  OutsSpoken (della Alva Access Group) e Hal (della Dolphin Systems). Sono stati fra i primi screen-reader per interfaccia grafica, entrambi utilizzano il mouse da tastiera, e nelle versioni successive hanno implementato l’uso dei display Braille;  Windots e Virgo, invece sono nati prima come display Braille, e poi hanno supportato la sintesi vocale;  JAWS (Job Access With Speech) è attualmente il più diffuso screen-reader per Windows in Italia, di esso parleremo nelle successive sezioni in dettaglio;  Window-Eyes, il più diffuso in america, è disponibile una versione in italiano;  Home Page Reader, limitato alla navigazione Web. Un prodotto molto valido di IBM ma di minore diffusione proprio perché può essere utilizzato solo per navigare e leggere la posta elettronica. Gli screen-reader sono prodotti in genere molto costosi: tuttavia, esistono in rete delle versioni dimostrative per provarne il funzionamento. Sono versioni che in genere funzionano per un tempo limitato o riducono le funzionalità non consentendo l'uso dei display Braille. Gli screen-reader che prenderemo in considerazione sono:  JAWS, nelle versioni 5.1 e 6 (di recente è in uscita la versione 8 in inglese);  Home Page Reader, versione 3.02 (attualmente è in commercio la versione 3.04);  Window Eyes, versione 5.0 (in italiano). (è appena uscita la versione 6). - 349 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Sono, infatti, questi gli screen-reader più usati, così come quelli più aderenti alle prescrizioni delle WCAG. Oltre all’articolo già citato di Riccardo Franco ci sono in rete molti studi ed analisi comparative sugli screen-reader tra cui quello di FucinaWeb1: "L'aderenza agli standard di screen-reader e browser vocali", dove vengono confrontati JAWS e Window Eyes. MSAA Alla base di molti screen-reader ci sono le MSAA (Microsoft Active Accessibility) API, di cui ho riportato qualche considerazione nella parte dedicata ai sistemi operativi. Fondamentalmente Le MSAA API sono delle librerie di funzioni in grado di mettere a disposizione delle applicazioni una serie di dati e proprietà del video. I lettori di schermo possono accedere a queste informazioni ed interfacciarsi con esse. Per usare le MSAA, è possibile utilizzare i controlli standard messi a disposizione dalla Microsoft, oppure, usando un linguaggio di programmazione, interagire direttamente con le API: in questo caso si parla di controlli non standard, che presentano lo svantaggio di non essere attivabili direttamente da tastiera. Per ovviare allo svantaggio, JAWS ha introdotto un linguaggio di scripting in modo da permettere l'utilizzo di quelle applicazioni che non hanno una completa standardizzazione nei loro controlli. Internet Explorer e Netscape Navigator vengono utilizzati molto bene dagli screen-reader, dato che questi software si avvalgono delle funzionalità delle MSAA. Altri browser come Opera e Firefox si sono mossi molto più lentamente su questo terreno e, di conseguenza, gli screenreaders non sono sempre loro adattabili. Fatto in parte dovuto alla scarsa interazione con le api MSAA. Tuttavia, recentemente, i passi per integrazione all’accessibilità anche di Firefox sono stati notevoli al punto che attualmente il suo supporto per le MSAA è completo. 2 I browser testuali come Lynx si usano ottimamente con screen-readers che lavorano sotto DOS oppure sotto la consolle di Linux. In tal caso basta utilizzare le frecce del computer per muoversi tra i collegamenti ipertestuali della pagina; un invio attiva il collegamento e con il tasto di tabulazione ci si può spostare fra i controlli della pagina stessa. Il problema dei browser testuali è che, in quanto tali, non visualizzano gli elementi grafici di una pagina Web. 1 [http://www.fucinaweb.com/fw/asstec] Aaron Leventhal: “Currently, Firefox fully supports the Microsoft® Active Accessibility (MSAA) API” [http://www-03.ibm.com/able/resources/firefox.html] 2 - 350 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR JAWS (Job Access With Speech) Questo programma della Freedom Scientific nasce già come lettore di schermo per sistema MS-DOS. JAWS è probabilmente il migliore screen-reader per quantità di funzionalità, ricco a dismisura di comandi per l'accesso ai programmi e per la navigazione in rete. JAWS è riuscito negli anni a mantenere invariati molti dei comandi fondamentali, in modo da non disorientare gli utenti nel passaggio da una versione ad un'altra. Bisogna considerare, cosa non da poco, che nell'azienda che produce questo programma, lavorano delle persone non vedenti. JAWS supporta un linguaggio di programmazione proprietario che permette di scrivere dei programmi che interagiscono con le applicazioni più disparate. Sono stati realizzati script per moltissime applicazioni, e questa caratteristica fa sì che JAWS sia tutt'ora lo screen-reader più utilizzato, almeno per quanto riguarda Windows. Per JAWS è possibile scaricare un dimostrativo dal sito. Il dimostrativo offre le funzionalità vocali (non il Braille che richiede un apposito hardware decisamente costoso) per sessioni della durata di 40 minuti, dopodichè è necessario riavviare il computer se si desidera continuare a lavorare in JAWS. Questa versione limitata però non ha attivata la sintesi vocale software e supporta pochissime sintesi vocali hardware. JAWS si comporta come un programma residente che gira in background sotto le altre applicazioni e che legge in automatico molti degli eventi che avvengono sullo schermo o i tasti digitati. Lo strumento imposta in partenza una modalità di lettura automatica. L'utente che naviga con Internet Explorer ha comunque a disposizione una serie di comandi da tastiera che gli consentono di esplorare lo schermo: purtroppo però, nel momento in cui si usano i comandi da tastiera la lettura automatica viene interrotta e la lettura (manuale) riparte dall'inizio. È stata più volte rilevata in rete (per esempio su Webaccessibile) la difficoltà di navigare con JAWS abbinato a un browser diverso da Explorer, come per esempio le versioni di Firefox non supportate da MSAA: infatti, per questo motivo, la maggior parte delle combinazioni di tasti per la lettura agevolata della pagina non funziona. In ogni modo la navigazione con JAWS in Firefox è ugualmente possibile anche se con modalità più complesse. Un interessante e completo articolo sull’utilizzo e la personalizzazione di JAWS è stato pubblicato qualche mese fa sul sito di WebAccessibile1. A questo rimando per le ulteriori specificazioni. 1 [http://www.webaccessibile.org/argomenti/argomento.asp?cat=611] - 351 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Home Page Reader (HPR) Home Page Reader (prodotto della IBM) è un browser Web con funzioni vocali. Per leggere il contenuto delle pagine Web, Home Page Reader versione 3.0 usa un software di sintesi vocale IBM, ViaVoiceOutloud. HPR definisce alcune modalità principali di lettura, fra cui:  Modalità di lettura Elementi: la lettura avviene saltando da un elemento ad un altro: per elementi si intendono paragrafi, intestazioni, liste, celle di tabelle, controlli (caselle di testo, pulsanti di opzione, link mappe immagini). Si attiva con Alt+E. In questa modalità, che è la predefinita da HPR, i tasti Freccia Sinistra/Giù/Destra leggono rispettivamente gli elementi precedenti/correnti/successivi;  Modalità di lettura Parole: il contenuto viene letto parola per parola. Si attiva con Alt+P. In questa modalità, i tasti Freccia Sinistra/Giù/Destra leggono rispettivamente le parola precedenti/correnti/successive;  Modalità di lettura Caratteri: la lettura avviene lettera per lettera. Si attiva con Alt+C. In questa modalità, i tasti Freccia Sinistra/Giù/Destra leggono rispettivamente la lettera precedente/l'equivalente fonetico della lettera corrente/successiva;  Modalità di lettura Cursori di Windows: la lettura avviene lettera per lettera, riga per riga, secondo le combinazioni di caratteri. Si attiva con Alt+W. In questa modalità, i tasti Ctrl+Freccia Sinistra/Ctrl+Destra leggono rispettivamente la parola precedente/successiva. I tasti freccia sinistra/destra leggono la lettera precedente/successiva. Window-Eyes Window-Eyes funziona di default in una modalità di lettura per cursori. Con le frecce destra e sinistra, vengono lette le singole lettere. Su Internet Explorer, con la combinazione Ctrl+freccia destra/sinistra, vengono lette le parole seguenti/precedenti. Parallelamente, Window-Eyes legge le parole su cui il mouse è posizionato; questa modalità assomiglia a quella di JAWS denominata "cursore invisibile", attivabile col il testo meno del tastierino numerico. Molte pagine Web oggi sono occupate da grafici, immagini in movimento ed è difficile esplorarle mediante uno screen-reader. Esse possono contenere molte colonne e molti frame e tabelle. L'uso del modo MSAA rende Internet Explorer più facile da gestire. Per attivare questo modo bisogna portare in "attivo" le applicazioni MSAA nel menu "Generale" o premere il tasto caldo CTRL-SHIFT-A quando Internet Explorer è attivo. Quindi, se il modo MSAA è impostato su attivo, Window-Eyes riceve le informazioni direttamente da Internet Explorer saltando la lettura delle informazioni sullo schermo. - 352 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Questo consente al programma di presentare le informazioni in modo organizzato "come una pagina di testo" facilmente consultabile con la sintesi vocale o la riga Braille. Fino a quando rimane attiva questa modalità Window-Eyes lavora con un puntatore invisibile che emula un cursore all'interno di un'area di memoria che contiene le informazioni presentate contemporaneamente sullo schermo. Quando il modo MSAA è attivo, Window-Eyes legge tutte le informazioni presenti sulla pagina Web riga per riga direttamente dal formato (X)HTML. Window-Eyes raccoglie le informazioni in ordine, ma deve attendere che Internet Explorer concluda il caricamento della pagina stessa nella memoria del computer. A questo punto Window-Eyes comunica con Internet Explorer per mezzo delle MSAA ed è in grado di prelevare tutte le informazioni presenti sulla pagina Web. Durante questa fase di caricamento l'intera pagina viene riformattata e posta in un'area temporanea di memoria di Window-Eyes. In nessun caso ciò che è visualizzato sullo schermo viene modificato. Window-Eyes legge nell'area di memoria di Window-Eyes, ed in tal modo fornisce un completo accesso alle informazioni presenti sul video. Una volta che la pagina è stata completamente scaricata nel buffer di Window-Eyes e non si sono dati comandi di lettura, Window-Eyes legge automaticamente 24 righe a partire dalla posizione corrente. Quando si legge una pagina Web e si incontra un collegamento ipertestuale, Window-Eyes pronuncia "link" seguito dalla descrizione del collegamento. Se il collegamento in oggetto è stato visitato in precedenza, Window-Eyes pronuncia "link visitato" seguito dalla descrizione del link. Questa è una funzione particolarmente utile per aiutare la navigazione sullo schermo evitando di rivisitare pagine già controllate. Si può controllare il modo con cui Window-Eyes legge queste informazioni e le altre proprietà legate all'utilizzo delle MSAA cambiando le impostazioni delle MSAA nel menu globale prolissità MSAA. V.3 - Strumenti di sviluppo A monte delle relazioni esistenti tra i produttori dei contenuti Web e i fruitori, esiste una branca importante della catena dell’accessibilità per i siti Web costituita dall’insieme degli ambienti di sviluppo, cioè da quegli applicativi che permettono la realizzazione delle pagine. Questo argomento è stato affrontato in linea teorica al momento di parlare delle ATAG (Authoring Tools Accessibility Guidelines). In questa sede vorrei fare una breve panoramica sulle capacità di questi strumenti, con una particolare attenzione a quelli più automatizzati come i CMS (Content management system), sistemi di gestione dei contenuti, una categoria di sistemi software per organizzare e facilitare la creazione di documenti e altri contenuti in un ambito di collaborazioni di gruppo. - 353 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR CMS Tra i sistemi di sviluppo dei contenuti Web si è assistito recentemente al consistente sviluppo di alcuni pacchetti integrati, denominati CMS, che consentono di gestire una grande quantità di informazioni permettendone di gestirne le varie fasi di produzione e di divulgazione in gruppo. I CMS, acronimo per Content Management System, sistema di trattamento dei contenuti, sono degli applicativi software che trattano varie tipologie di contenuti e di documenti dando la facoltà di gestirne:  La creazione guidata;  L’organizzazione;  La gestione collaborativa. L’aspetto collaborativo e di interazione fra vari gruppi di editori è l’aspetto centrale di questi sistemi. Un CMS ben progettato è in grado di:  Gestire la conoscenza;  Permetterne una evoluzione collaborativa sotto opportuni criteri di controllo;  Permetterne una divulgazione pubblica in differenti contesti;  Gestire i flussi dei documenti. Non sono degli strumenti che utilizzabili esclusivamente per il Web, ma sicuramente una loro applicazione in internet o intranet può essere considerata il loro naturale campo di azione. Internet o intranet si prestano infatti perfettamente come efficace strumento di supporto per la divulgazione pubblica dei contenuti. I CMS possono essere classificati in 3 classi di appartenenza a seconda della quantità e della complessità di documentazione che gestiscono:  Enterprise CMS (ECMS). Hanno il compito di una gestione completa del patrimonio informativo, il Web è solo un aspetto parziale. Devono poter gestire qualunque tipologia di informazione, organizzando i flussi di creazione e di modifica tenendo traccia di ogni variazione. Sono anche in grado di fondere e separare i documenti, organizzare e relazionare contenuti multi-lingua e multi-formato. Non sono necessariamente finalizzati al Web;  Web CMS (WCMS). Sono progettati per siti Web complessi o per piccoli sistemi di gestione della conoscenza. Hanno delle strutture di template per la presentazione delle informazioni e permettono un tracciamento delle modifiche meno sofisticato dei precedenti. Non viene garantita la stessa integrazione dei documenti e la stessa ricchezza delle versioni alternative. - 354 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Piccoli. Progettati per piccolo siti Web. In genere possiedono un solo template e non sono in grado di gestire versioni e flussi delle modifiche. Impiego Una delle migliori funzionalità di un CMS è quella di offrire un sistema integrato di creazione di contenuti che garantisca risultati di buona qualità in maniera guidata. L’aggiornamento dei siti Web delle pubbliche amministrazioni o di aziende che non hanno il loro campo di interesse nell’informatica, è stato, specialmente in passato, affidato spesso a professionisti specializzati a cui era delegato il compito di pubblicare i documenti forniti sul Web. In realtà questo sistema di sviluppare contenuti Web era piuttosto lento e macchinoso per via dei tempi di interazione tra azienda ed editore, e della grossa mole di lavoro riversata su un singolo editore di contenuti. Senza contare che era spesso soggetto a numerosi errori di pubblicazione dal momento che personale non esperto doveva trattare documentazione tecnica o amministrativa. Un’alternativa era quella di trasferire la conoscenza necessaria per la pubblicazione direttamente all’interno delle aziende che producevano i documenti. Tuttavia questo passaggio non poteva essere fatto senza un enorme dispendio di tempo e risorse umane. Il problema viene risolto brillantemente proprio dai CMS, che consentono una autonomia interna delle aziende produttrici senza coinvolgerle in un eccessivo costo formativo e garantendo, in aggiunta, una presentazione più omogenea e coordinata dei contenuti pubblicati. Grazie alla supervisione di uno o più esperti interni, i cosiddetti content manager, autorizzati dal gestore del sistema, l’attività di produzione può essere organizzata completamente all’interno dell’azienda. Costoro, accedendo alla propria area di gestione del sito possono organizzare i contenuti e le presentazioni di propria competenza. Sarà poi compito del CMS manipolare correttamente i contenuti specifici inseriti da ogni singolo operatore in relazione alle direttive fornite dal gestore di contenuti per produrre dei documenti accessibili e coerenti. Nel suo testo sull’accessibilità Roberto Scano1 ha riassunto i principali benefici nell'uso dei sistemi CMS in un’organizzazione come quella sopra esposta: 1  Autonomia gestionale dei contenuti;  Immediatezza della gestione e pubblicazione dei contenuti; Roberto Scano: ”Accessibilità: dalla teoria alla realtà” - 355 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Miglior gestione dell'immagine aziendale;  Facilità nella ricerca di contenuti all'interno del sito Web;  Possibilità di gestire comunicazioni periodiche con gli utenti;  Minori costi per contratti di manutenzione dei contenuti. La facilità e l’autonomia d’uso è garantita da una interfaccia operativa verso l’utente di tipo WYSIWYG (What You See Is What You Get) cioè: quello che si vede è quello che si ottiene. Un sistema di editor visuale molto vicino ad un Word Processor di qualità. Questo permette anche ad un’utenza poco esperta di produrre contenuti impaginati e coerenti secondo le impostazioni definite dal content manager e di ottenerli in maniera accessibile, cosa garantita dalla produzione di codice (X)HTML interna del CMS. Problematiche I CMS, così come definiti, sono ovviamente degli strumenti di sviluppo di pagine Web. Come tali ricadono nella categoria degli Authoring Tools come definito dal W3C, sono soggetti alle ATAG e ne devono rispettare le normative, sia per quanto riguarda la loro accessibilità intrinseca che per quanto riguarda l’accessibilità dei contenuti che producono. In oltre, gli operatori, per gestire i contenuti, ricorrono spesso ad un’interfaccia internet o intranet, i cui contenuti sono soggetti anche alle regole delle WCAG. Tutto questo rende estremamente difficoltoso produrre un CMS che sia realmente accessibile sotto tutto gli aspetti. I problemi di accessibilità dei CMS possono essere raggruppati nelle seguenti categorie:  Accessibilità dell’area di gestione (backoffice);  Accessibilità dell'editor;  Accessibilità dei contenuti generati dal CMS. Nel seminario1 IWA di Arese, Luca Mascaro ha sottolineato come, nel 2005, la situazione fosse ancora una “catastrofe totale”. Se, infatti, da un punto di vista dell’accessibilità dei contenuti il risultato poteva essere ottenuto con una relativa facilità, dal punto di vista dell’ambiente complessivo lo sviluppo era molto indietro, al punto che se un’amministrazione pubblica avesse dovuto fare un bando di concorso sarebbe stata obbligata a spendere delle cifre davvero ingenti per acquistare a caro prezzo i pochi CMS di fascia alta realmente accessibili presenti sul mercato. 1 Arese Maggio 2005: Roberto Ellero, Luca Mascaro: seminario, dal titolo: "Legge Stanca: dalla teoria alla realtà. Analisi delle disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici” - 356 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Area di gestione (backoffice) Per backoffice dei CMS si intende l’area di gestione dei contenuti del sito alla quale accedono i singoli content manager per amministrare le informazioni di propria competenza. Il backoffice è, in pratica, un’area riservata all’interno di un sito internet o intranet dove un utente autorizzato può organizzare le funzionalità operando in un ambiente conosciuto come ad esempio il proprio normale browser. Vengono trattate le modifiche sui contenuti stessi, sui permessi, sulla strutturazione e sulla relazione fra le informazioni, sulla impaginazione e sulle configurazioni, in generale su tutte le personalizzazioni consentite dal CMS a seconda del livello di autorizzazione consentito all’utente allocato. L’accesso viene infatti autorizzato fornendo delle credenziali. Gli amministratori potranno accedere a tute le sezioni mentre profili più limitati avranno a disposizione solamente un sottoinsieme ristretto delle funzionalità e dei dati. Di fatto, essendo quest’area gestionale un vero e proprio insieme di pagine Web, deve rispettare le WCAG fornendo versioni accessibili dei contenuti disponibili. Ad esempio il progettista del CMS deve prestare attenzione:  Ad un eventuale sviluppo dell’interfaccia su frame;  All’impiego di moduli (form) che non siano correttamente etichettati, raggruppati ed accessibili. A questo proposito va tenuto in debito conto anche il fatto che il modulo d’identificazione per operatore deve essere accessibile;  Ad implementare un corretto sistema di orientamento e navigazione;  Ad implementare un corretto sistema di archiviazione e pubblicazione dei contenuti che possa essere utilizzato anche dalle persone disabili;  All’utilizzo di un linguaggio chiaro e semplice per la presentazione e le informazioni sull’uso dell’interfaccia. Ad esempio, allo stato attuale delle cose la maggior parte dei CMS impiega spesso delle strutture a frame per offrire dei menu di navigazione, e questa scelta risulta una barriera molto difficile per gli autori non vedenti. Un interessante strumento messo spesso a disposizione è quello delle procedure guidate (wizard), che permettono di ottenere un risultato raccogliendo informazioni passo dopo passo. Se un CMS implementasse questa tecnica, i singoli moduli di procedura guidata dovrebbero contenere:  Posizione attuale (ad esempio passo 1 di 4);  Scopo del modulo attuale con brevi spiegazioni sulla funzionalità;  Barra di navigazione per tornare al passo precedente, uscire, saltare al successivo. - 357 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Editor Come accennato in precedenza l’editor presentato ai creatori dei contenuti deve essere generalmente di tipo WYSIWYG dal momento che deve essere utilizzato da personale anche non necessariamente competente in materia di pubblicazione di contenuti. Può essere di due tipi:  Proprietario, integrato nel CMS. Garantisce una migliore integrazione con il sistema;  Esterno e collegato con un plug-in. Offre la possibilità di lavorare con uno strumento già conosciuto dall’utente. In entrambe i casi ci sono dei problemi comuni di importanza chiave:  Si richiede che il codice prodotto sia valido secondo le specifiche (X)HTML. Editor integrati e soprattutto editor esterni inappropriati spesso non sono stati progettati specificatamente per (X)HTML e a volte non generano codice corretto secondo le grammatiche formali del W3C;  Si richiede che il contenuto prodotto sia conforme alle WCAG. Per quanto nessun editor possa, ovviamente, garantire che il contenuto finale sia pienamente accessibile, tuttavia, è possibile progettarlo in maniera che possa guidare l’editore nella creazione di contenuti migliori ad esempio obbligando all’inserimento dell’attributo ALT;  Si richiede che la stessa interfaccia dell’editor sia accessibile e compatibile con le tecnologie assistive. Un modo per ottenere questo è garantire che sia pienamente operabile via tastiera. Questi ultimi due punti sono quelli previsti espressamente nelle ATAG che si propongono proprio di far conseguire questi risultati agli strumenti di sviluppo. In effetti, questa è una delle sezioni più critiche di un CMS. Contenuti generati Come appena accennato il prodotto finale dell’editor deve essere accessibile. Le ATAG contengono una serie di direttive utili a proposito per fare in modo che lo strumento di sviluppo possa fungere da guida alla produzione di contenuti accessibili. Questo riguarda non solo la generazione di un codice efficiente e funzionale, ma che contenga anche tutti i necessari supporti per una corretta fruibilità, in particolare:  Validità formale del documento nel codice (X)HMTL e CSS;  Strutturazione logica del documento;  Gestione di pagine multi-lingua per i CMS multi-lingua;  Produzione di pagine facilmente navigabili che evitino ad esempio lunghi elenchi di collegamento generati magari in automatico; - 358 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Inserimento nella pagina di sistemi di navigazione ed orientamento che possono essere inseriti in maniera semiautomatica nel codice finale dal CMS con relativa facilità;  Interazione chiara con l’utente, ad esempio fornendo un motore di ricerca interno del sito. A questo proposto va ricordato che la bontà di un CMS consiste anche nel permettere ad un autore di contenuti che sia inesperto in materia di scrittura di codice (X)HTML e CSS di produrre dei risultati di qualità in maniera più automatica possibile, senza essere per altro limitato nelle sue capacità espressive. Conclusioni Come già accennato, la vastità del problema e delle considerazioni che vanno fatte per produrre un CMS pienamente accessibile ha reso molto ridotti i ranghi di prodotti di qualità. I CMS erano in commercio ed erano anche piuttosto diffusi anche prima delle attenzioni che vengono oggi poste nei riguardi del problema dell’accessibilità. Questo per il merito della notevole organizzazione del lavoro che possono offrire. Con l’avvento delle WCAG e della normativa italiana si è assistito ad un notevole miglioramento della loro qualità ed anche i grossi produttori come Microsoft stanno aggiornano le loro soluzioni in materia. L’abbattimento dei costi gestionali e l’alto grado di produttività che possono consentire anche ad un utente mediamente preparato, ne fanno uno degli applicativi potenzialmente più efficace nella progettazione di siti Web aziendali. Occorre far presente però che non sono assolutamente in grado di entrare nel merito dei singoli contenuti. Per quanto sia possibile aiutare il progettista nello sviluppo di un sito strutturalmente corretto, la qualità delle informazioni pubblicate ed il controllo su di esse resta ad esclusivo appannaggio di un supervisore umano. Anche a questo proposito i CMS possono essere particolarmente efficaci, organizzando la catena produttiva di ogni singolo documento e consentendone la pubblicazione solo dopo il passaggio obbligato attraverso la verifica ultima di un responsabile. Chiudo questa breve panoramica sui CMS segnalando la recente distribuzione di un prodotto open-source, conforme alla legge Stanca ed a buona parte delle WCAG. Si tratta di Fruibile1, il cui progetto è coordinato da Roberto Scano e Luca Mascaro. 1 [http://www.fruibile.it/] - 359 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR V.4 - L’accessibilità nei sistemi operativi Può essere istruttivo presentare una panoramica generale dello sviluppo e dell’attenzione riguardo all’accessibilità anche a livello dei sistemi operativi. In effetti, è proprio il sistema operativo che dovrebbe essere la base da dove partire per ottenere una completa accessibilità delle informazioni 1 dal momento che è precisamente quest’ultimo a fornire la piattaforma software sulla quale poi girano tutti i programmi utente. I sistemi operativi più datati, come il DOS e Unix nei suoi primi ambienti erano solo testo e ponevano poche barriere di accessibilità alle tecnologie assistive che potevano adattarvisi con relativa semplicità. Anche per questo erano scarsamente dotati di accorgimenti interni. Le difficoltà sono cresciute notevolmente con l’avvento della grafica e del mouse, strumenti che non sono immediatamente riconducibili alle tecnologie assistive. Attualmente i sistemi operativi più diffusi sono Windows, MAC OS, Unix e derivati (Linux). Per questi ultimi esiste ancora una forte tradizione di ambiente a riga di comandi, e le tecnologie assistive che supportino questo tipo d’interfaccia possono ancora validamente adattarvisi. Tuttavia anche per Linux sono presenti un gran numero di ambienti grafici. Una regola dei sistemi operativi grafici è quella di fornire un’interfaccia di programmazione per le applicazioni (API) in modo che possano essere scritte delle applicazioni congruenti con le funzionalità del sistema operativo. Le API forniscono un insieme di blocchi funzionali precostituiti che i programmatori assemblano nelle loro applicazioni. Da questo punto di vista è fondamentale che le API forniscano il supporto per l’accessibilità. Ad esempio: tutti i menu ed i controlli in un’interfaccia grafica dovrebbero essere accessibili via tastiera, non solo tramite mouse, e dovrebbero essere visualizzati con un insieme di caratteri ed uno schema di colore facilmente personalizzabile dall’utente. Finché le API garantiranno il supporto per queste ed altri aspetti dell’accessibilità le applicazioni che gireranno in questi ambienti possono essere facilmente rese accessibili dagli sviluppatori. Attualmente esistono significative differenze nell’accessibilità delle API nei vari sistemi operativi. Microsoft si è occupata di molti dei problemi di accessibilità delle API di Windows e ha consentito agli sviluppatori di produrre delle applicazioni accessibili. Molte delle applicazioni in Windows, per esempio, sono completamente gestibili via tastiera. Altri sistemi operativi di tipo grafico non sono stati così solleciti nel fornire un’accessibilità paragonabile. Gli sforzi precoci di Microsoft per supportare l’accessibilità, in combinazione con 1 “The more and more I think about accessibility, the more I feel that the burden of accommodating the minorities who have low vision, are color blind, or just have a simple person predilection towards having text really damn big should fall on the operating system and browser makers, not web designers.” – [http://www2.jeffcroft.com/blog/2006/aug/21/has-accessibility-been-taken-too-far] - 360 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR la posizione di predominanza sul mercato, hanno portato ad uno sproporzionato sviluppo di tecnologia assistiva concepita specificatamente per il mondo Windows. Alcune caratteristiche di accessibilità sono implementate negli stessi sistemi operativi, ma tipicamente queste applicazioni interne possono garantire solo un livello minimo di accessibilità, sicuramente non il livello completo di cui molti utenti hanno bisogno per ottenere un accesso completo al sistema operativo e alle sue applicazioni. In genere sono disponibili alcune caratteristiche comuni a tutti i sistemi:  Personalizzazione della tastiera. Viene consentito agli utenti di impostarsi il comportamento in modo che possano:  o Premere un tasto per volta per le combinazioni multi-tasto; o Utilizzare la tastiera per controllare il mouse; o Cambiare l’intervallo di tempo per la rilevazione della pressione di un tasto; Personalizzazione del video. Viene consentito di modificare il contrasto, il tipo e la dimensione del carattere, la dimensione delle icone, la risoluzione del video ed altre caratteristiche;  Messaggi di sistema. Sono emessi messaggi di sistema visivi per chi non può udire i suoni. In aggiunta a queste caratteristiche base, Windows e MAC OS includono ingranditori di schermo e screen-reader, per quanto siano molto elementari. Linux differisce dagli altri due per il fatto che sia un progetto open-source ed il suo supporto viene portato avanti da una comunità di sviluppatori. La comunità di sviluppo di Linux ha prodotto un insieme base di funzionalità per l’accessibilità consistente in un ingranditore di schermo integrato con uno screen-reader, un software per la gestione delle barre Braille e una tastiera su schermo. Tutte queste caratteristiche sono state sviluppate per il desktop GNOME, un’interfaccia grafica che lavora sia sotto Unix sia Linux. Vediamo adesso una panoramica più specifica per i sistemi operativi. Data la complessità della materia queste poche righe saranno solamente un accenno, per dare un quadro alla materia, destinato tra l’altro ad essere integrato in breve tempo dallo sviluppo software, soprattutto nel mondo open-source. Per diffusione ed importanza il centro del discorso sarà la trattazione dell’accessibilità in Windows. Microsoft Windows L'ambiente operativo su cui un disabile opera solitamente è Microsoft Windows in quanto Microsoft già dalla versione 2.0 di Windows ha iniziato ad implementare caratteristiche di accessibilità del proprio sistema, sino a giungere ad un primo nucleo di MSAA (Microsoft Active Accessibility) e alle opzioni di accesso facilitato già con Windows 95. Sul sito della Microsoft è - 361 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR presente un’utile tabella riepilogativa1 che riporta lo sviluppo e le caratteristiche di accessibilità proprie dei sistemi Microsoft. Con il nascere di Microsoft Windows 95, sono state realizzate, dalla Microsoft, delle librerie di funzioni in grado di mettere a disposizione delle applicazioni una serie di dati e proprietà. Tali librerie sono le Microsoft Active Accessibility Application Program Interface (MSAA API), che creano, all'interno del sistema operativo, delle classi pubbliche di oggetti. Tali classi sono in grado di fornire ai programmi per le tecnologie assistive, tutte le informazioni necessarie sui controlli appartenenti ad una finestra, sugli elementi che fanno parte di questi controlli, sui menu ed anche sul codice HTML che viene caricato nei browser.2 I lettori di schermo possono accedere a queste informazioni ed interfacciarsi con esse, anche modificandole, trasformare in testo i loro valori; in tal modo gli utenti possono reperire tutte le funzionalità che gli applicativi mettono loro a disposizione. Le applicazioni sviluppate per tale ambiente operativo sono sicuramente più accessibili rispetto ad altri sistemi considerando che le tecnologie assistive (soprattutto i lettori di schermo) utilizzano le API dell'ambiente operativo per ottenere informazioni sugli oggetti e sui contenuti testuali. Occorre inoltre segnalare un altro aspetto spesso sottovalutato ma importante per l’accessibilità di Microsoft Windows, questo sistema operativo possiede alcune facilitazioni di accesso native che hanno incominciato ad affermarsi fin dalle prime versioni di Windows 95. Queste integrazioni sono ripartite in diverse sezioni:  Scheda Accesso facilitato dal pannello di controllo;  Scheda Aspetto della finestra Proprietà dello schermo di Windows;  Menù Avvio, tutti i programmi, accessori, accesso facilitato;  Impostazioni specifiche dal pannello di controllo. Vediamo adesso un breve elenco di alcune di queste funzionalità che possono essere direttamente verificate sul proprio sistema operativo, visto che sono immediatamente disponibili senza bisogno di installazioni separate. Nel caso che non fossero disponibili è possibile integrarle con disco di installazione di Windows. Un utile testo di riferimento3 a proposito di queste funzionalità è stato predisposto dalla stessa Microsoft ed è facilmente reperibile in rete. 1 2 3 [http://www.microsoft.com/enable/products/chartwindows.aspx] [http://lau.csi.it/testare/accessibilita/test_user-agent/screen_reader/panoramica.shtml] “Step by Step Tutorials for Microsoft Windows XP Accessibility Options” - 362 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Opzioni di accesso facilitato La scheda per le opzioni di accesso facilitato è attivabile dal pannello di controllo. La dizione italiana accesso facilitato è l’impropria traduzione dalla versione inglese che recita Accessibilty Options. Le funzionalità sono ovviamente le stesse per ambedue le lingue. Le opzioni per l’accesso facilitato sono organizzate in 5 sezioni differenti:  Tastiera: o Tasti permanenti (sticky keys): Molti software richiedono che siano premuti due o tre tasti contemporaneamente. Per alcune persone che scrivono utilizzando un solo dito o una cannuccia questo non è possibile. I tasti permanenti consentono di premere un tasto per volta e istruire Windows a rispondere come se i tasti fossero stati premuti contemporaneamente. I tasti di modifica sono ALT, SHIFT e CTRL, ed esistono diverse opzioni nella scheda tastiera per la loro gestione, tra cui la possibilità di attivare o disattivare le impostazioni permanenti anche senza passare da questa scheda o il fatto di emettere un suono alla loro pressione e di mostrare il loro stato sulla barra di stato; o Filtro tasti (filter keys): Alcune persone possono incontrare delle difficoltà nel trovare e premere i tasti corretti o nel mantenerli premuti per un tempo sufficientemente lungo, con il rischio di andare incontro ad errori di tastiera. Questa opzione permette di andare incontro ai problemi di risposta della tastiera, in particolare permette di ignorare i tasti premuti troppo rapidamente regolando anche la velocità, il ritardo e l’accelerazione di ripetizione. Anche in questo caso è possibile mostrare lo stato come un cronografo sulla barra di stato o emettere un segnale acustico in corrispondenza alla pressione ripetuta di un tasto; o Segnali acustici: permette di associare dei segnali acustici alla pressione del blocco delle maiuscole, del blocco del tastierino numerico e del blocco della funzione di scorrimento;  Audio: Spesso il sistema operativo informa gli utenti degli eventi o dei problemi del sistema attraverso dei suoni piuttosto che attraverso dei messaggi visivi. Questa è stata una funzionalità piuttosto comune dei sistemi operativi fin dal loro avvento. Sebbene questi messaggi audio tendano a non essere critici se usati da soli, tuttavia potrebbero essere sicuramente utili, e non udirli potrebbe creare dei problemi agli utenti che non sono in grado di percepirli. Ci sono 2 elementi nelle opzioni dell’accesso facilitato per le persone che hanno difficoltà nell’udire gli avvertimenti audio dal computer. Vale la pena far notare che entrambe i sistemi possono solamente intercettare e visualizzare l’altoparlante interno - 363 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR del computer, i suoni che siano prodotti da una scheda audio a parte non possono essere rimappati con segnali visivi: o Mostra messaggi (show sounds), che permette di visualizzare le didascalie associate ai segnali acustici generati dalle applicazioni; o Usa segnali visivi (sound sentry) che permette di generare una serie di segnali visivi in aggiunta al segnale acustico emesso dal sistema. In questo caso un menu a discesa permette di selezionare come si preferisce che gli avvertimenti siano visualizzati. In genere è possibile impiegare il lampeggiamento intermittente della barra del titolo, della finestra attiva o del desktop;  Schermo: Questa caratteristica consente di cambiare rapidamente e facilmente le proprietà dello schermo impostando uno schema predefinito. La pressione simultanea di ALT, SHIFT di sinistra e PRINT SCREEN permette di attivare direttamente il contrasto elevato previa conferma. Anche in questo caso è possibile impostare in precedenza i tasti permanenti in modo da simulare questa pressione contemporanea con l’uso di ausili come cannucce, puntatori a movimento del capo o pressione di un singolo tasto contemporaneamente. E’ possibile selezionare la tipologia di contrasto elevato che si desidera selezionare per il proprio sistema. In un menù a discesa sono mostrate gli schemi disponibili per Windows oltre a quelli che sono stati personalizzati direttamente dall’utente. Ogni schema ha, in genere, anche 2 o 3 differenti possibilità di scelta per le dimensioni. Questa opzione può essere anche configurata parzialmente dalla scheda aspetto delle proprietà dello schermo come indicato a parte.  Mouse: Questa scheda permette di controllare il puntatore del mouse attraverso la tastiera. Per quanto Windows sia stato progettato per consentire agli utenti di interagire con il sistema anche senza l’utilizzo del mouse, tuttavia qualche programma potrebbe comunque richiederlo, oppure il puntatore del mouse potrebbe essere molto più pratico e funzionale in certe circostanze. Il controllo del puntatore può essere attivato sia da questa scheda sia da tastiera con la pressione contemporanea dei tasti di sinistra di ALT, SHIFT e NUM LOCK. Da ricordare che esiste la possibilità per i disabili di attivare i tasti permanenti, istruendo Windows a gestire in sequenza la pressione altrimenti contemporanea di questa combinazione. Una volta attivato il controllo del puntatore del mouse, è possibile utilizzare le frecce del tastierino numerico per spostare il mouse nella direzione indicata dal tasto. Il tasto 5 può essere impiegato per simulare il click singolo del mouse, mentre il doppio click è simulato dal tasto +. Esiste anche la possibilità di simulare i drag and drop con i tasti INS e DEL mentre CTRL e SHIFT - 364 - permettono spostamenti macroscopici o microscopici sul video. Queste ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR funzionalità possono essere utili anche ad utenti normodotati che desiderino, per esempio, attuare degli spostamenti pixel per pixel del mouse in cooperazione con i normali movimenti.  Generale: Nella scheda delle impostazioni generali si può configurare il comportamento delle opzioni di accesso facilitato. Questa funzionalità risulta particolarmente utile nel caso in cui più di un utente abbia accesso al computer. Nel caso, ad esempio, che siano state rallentate le immissioni da tastiera, un utente che non ne richieda l’impiego può erroneamente ritenere che si sia verificato un errore e che il sistema sia in crash. Per questo motivo è disponibile una cancellazione automatica delle funzionalità, se non utilizzate per un certo limite di tempo. E’ anche possibile rendere noto all’utente con un messaggio o con un segnale acustico quando venga attivata o disattivata una delle funzionalità descritte in precedenza. In questo modo è possibile tenere informato l’utente su come si stia comportando il sistema e di come reagisca. Le opzioni di amministrazione permettono di decidere se le impostazioni vadano richiamate in automatico dalla partenza o se possano venire trasferite in automatico ad un nuovo utente al momento della sua creazione. Un’ulteriore importante funzionalità è quella dell’impiego di una periferica alternativa. Molti utenti utilizzano un’apparecchiatura di aiuto alla comunicazione ed altri ausili a parte che possono interagire con il computer attraverso una porta di comunicazione. Impostando la porta per la periferica alternativa è possibile creare un collegamento tra le due apparecchiature in modo che il dispositivo esterno possa operare in maniera simile alla tastiera standard. Come fatto notare in alcune voci, tutte queste configurazioni sono impostabili direttamente con delle scorciatoie via tastiera, in modo che gli utenti disabili non siano costretti ad aprire il pannello per impostare il controllo. Scheda aspetto delle proprietà dello schermo In questa finestra e possibile impostare alcune configurazioni che riguardano le proprietà con cui sarà mostrato lo schermo. In particolare:  E’ possibile selezionare e creare una combinazione di visualizzazione in modo da avere una presentazione a schermo il più possibile aderente alle necessità percettive dell’utente, configurando sfondi delle finestre, proprietà del testo, dimensioni delle barre, dei menù, delle icone ed altro. In assenza di specifiche indicazioni a livello di applicazione, il sistema operativo utilizzerà queste combinazioni nelle visualizzazioni degli applicativi. In particolar modo anche il browser può ereditare queste impostazioni di preferenza, - 365 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR oppure possono essere gli stessi autori di fogli di stile a richiamare volutamente le impostazioni del sistema operativo sfruttando delle costanti che fanno esplicito riferimento alle costanti di sistema. Anche il progettista di uno specifico programma applicativo può vantaggiosamente riferirsi a questi valori. Quasi sempre, in fase di sviluppo, gli attributi e le proprietà grafiche degli oggetti come caselle di testo, pulsanti, etichette, sfondi delle finestre ed altro, possono essere mantenute personalizzate impostando il valore di sistema predefinito. Se non si specifica alcun valore personalizzato, la visualizzazione dell'elemento avviene in base ai valori impostati nella combinazione di visualizzazione selezionata nella scheda Aspetto nella finestra Proprietà dello schermo. Questo meccanismo influenza anche la visualizzazione delle pagine Web. Ciò significa che in assenza di indicazioni specifiche, le pagine saranno visualizzate secondo i parametri standard utilizzati dal computer del navigatore;  E’ possibile allargare le icone sullo schermo in modo da rendere più facile il loro accesso. La scelta è possibile da un pulsante di controllo dalle opzioni effetti;  E’ possibile utilizzare la tastiera per selezionare le voci di un menù o le opzioni di una finestra di dialogo, questo premendo il tasto che corrisponde alla lettera sottolineata simultaneamente ad una combinazione con ALT. E’ possibile scegliere di nascondere la lettera sottolineata per la navigazione da tastiera fin quando non venga premuto il tasto che le abilita. Al di fuori di questo menù si ricorda che è anche possibile venire incontro alle esigenze peculiari degli utenti modificando la risoluzione dello schermo per aumentare la leggibilità dei documenti a video. Una risoluzione minore può agevolare le persone ipovedenti. Accessori, accesso facilitato Un menù di accesso facilitato è stato predisposto anche all’interno degli accessori nell’elenco dei programmi di sistema. Questo menu contiene diverse voci:  Impostazione guidata: è possibile invocare questo strumento per permettere agli utenti inesperti di configurare facilmente ed in un solo momento tutti i gruppi delle opzioni di accessibilità che li riguardano. L’impostazione guidata pone delle domande sui bisogni dell’utente e configura il sistema in base alle risposte. Nel caso può essere rilanciata più volte per reimpostare i valori. Durante l’uso della configurazione guidata viene data la possibilità di variare la dimensione dei font e delle schermate in modo da poter venire incontro alle esigenze degli utenti ipovedenti. La guida prevede delle configurazioni passo dopo passo che permettono di: - 366 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR o Impostare le opzioni per i non vedenti o per le persone che abbiano difficoltà a vedere gli oggetti sullo schermo; o Impostare le opzioni per i non udenti o che abbiano difficoltà ad ascoltare i suoni dal computer; o Impostare le opzioni per coloro che abbiano difficoltà ad operare con il mouse o con la tastiera; o  Disabilitare i menù personalizzati; Utility Manager: consente agli utenti di controllare lo stato degli applicativi sull’accessibilità o di arrestarli ed avviarli. E’ possibile impostare i valori in modo da predisporre che ogni singolo applicativo venga avviato automaticamente in momenti definiti come l’allocazione dell’utente, il blocco della macchina o l’avvio dello stesso utility manager. I programmi per l’accessibilità sono:  o Tastiera su schermo; o Narratore; o Ingranditore; Tastiera sullo schermo: si tratta di un programma di utilità che mostra una tastiera virtuale sullo schermo del computer. Questa consente agli utenti con disabilità motorie di digitare i dati usando un dispositivo di puntamento come ad esempio un joystick. Sono possibili un gran numero di opzioni per la configurazione di questo applicativo, tra cui dimensioni, font e posizionamento della tastiera. Particolarmente utile per disabili motori è il cosiddetto scanning mode, modalità in cui la tastiera scorre ed evidenzia la zona dove si possono digitare i caratteri utilizzando un sistema di ingresso da una porta di comunicazione;  Narratore: si tratta di un’utilità TTS (Text To Speech) per persone non vedenti o per ipovedenti. Il narratore legge quanto mostrato sullo schermo, come ad esempio il contenuto della finestra attiva, il menu delle opzioni, o il testo che viene digitato. Il narratore è stato progettato per lavorare con notepad, wordpad, i programmi del pannello di controllo, Intenet Explorer, la scrivania di Windows e alcune delle parti del programma di installazione di Windows. In altri programmi potrebbe non essere in grado di leggere il testo. Ovviamente sono possibili delle configurazioni come ad esempio il volume della voce, la selezione dei testi da leggere, la possibilità di rendere noti gli eventi che appaiano sullo schermo o i caratteri che vengono digitati. Tra le limitazioni di questo strumento c’è quella che è stata predisposta solo la versione in inglese;  Ingranditore (Magnifier): si tratta di un’utilità a video che rende lo schermo del computer più leggibile per gli ipovedenti creando una finestra separata dove viene - 367 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR mostrata una porzione ingrandita dello schermo stesso. Tra le funzionalità possibili, si ricordano quelle di cambiare dimensioni e posizione della finestra ingrandente, invertire i colori dello schermo, usare un contrasto elevato e seguire la tracciatura del mouse o il focus della tastiera. Come specificato all’interno degli stessi applicativi di base, questi strumenti hanno lo scopo di fornire una funzionalità minima di accesso per utenti con esigenze particolari. La maggior parte di loro avrà bisogno, per un’operatività efficiente, di programmi di utilità più avanzati di questi. Impostazioni specifiche dal pannello di controllo Dal pannello di controllo esistono poi diverse possibilità di configurazione dei dispositivi in modo che possano venire incontro alle esigenze degli utenti affetti da disabilità. Molte di queste configurazioni possono tornare utili anche nel normale impiego del sistema operativo:  Impostazioni del mouse (tempo di risposta, velocità di spostamento e di doppio click, inversione dei bottoni, metodo di drag and drop, disegno dei puntatori, tracciatura);  Impostazioni di tastiera (ripetizione dei tasti, ritardo di ripetizione, frequenza di lampeggiamento del cursore, tastiere speciali Dvorak);  Impostazioni della sintesi e riconoscimento vocale (velocità del parlatore e collegamento con il dispositivo audio). MSAA Le tecnologie assistive, allo scopo di consentire all’utente di accedere alle informazioni significative dell’interfaccia utente, devono essere in grado di accedere loro stesse a quell’informazione. Come accennato, la soluzione di Microsoft a questo problema sono le MSAA (Microsoft Active Accessibility) che sono disponibili come un pacchetto aggiuntivo fin dal sistema operativo Windows 95 e sono implementate internamente in tutti gli altri sistemi operativi successivi. MSAA è una tecnologia che fornisce un meccanismo standard e consistente per scambiare informazioni tra gli applicativi e le tecnologie assistive. A titolo d’esempio MSAA permette alle applicazioni di esporre agli screen-reader il tipo, il nome, la posizione e lo stato di tutti gli oggetti oltre a notificare qualsiasi evento che porta ad un cambiamento dell’interfaccia. Per quanto questo non sia il solo modo per un applicativo di comunicare con la tecnologia assistiva, tuttavia MSAA consente agli sviluppatori di queste tecnologie di supportare una vasta gamma di applicativi senza doversi occupare della programmazione una per una. - 368 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Il numero degli applicativi che supportano MSAA è in crescita, per quanto vi siano in commercio molti applicativi che non lo facciano. Microsoft ha sviluppato un pacchetto di strumenti che permettono agli utenti di controllare le informazioni che MSAA espone. Per quanto questi strumenti siano stati progettati per gli sviluppatori, potrebbero comunque essere di altrettanto interesse anche per i tecnici o per gli utenti più esperti. Il pacchetto, chiamato Microsoft Active Accessibility 2.0 Software Development Kit Tools, può essere direttamente scaricato da Microsoft1 ed include 3 programmi:  Accessible Event Watcher;  Accessible Explorer;  Inspect Objects. Informazioni sull’architettura e sull’utilizzo di queste interfacce di sistema possono essere reperite direttamente sul sito della Microsoft2. Alcuni dei più importanti pacchetti applicativi in commercio per tecnologie assistive fanno riferimento alla compatibilità con MSAA per garantire l’accessibilità, fra i tanti vale la pena ricordare sicuramente JAWS, Windows Eyes e Adobe Flash. Linux Il sistema operativo Linux ha notevolmente accresciuto la sua popolarità nel giro di questi ultimi anni diffondendosi sia nelle versioni server che nelle versioni per uso personale. Il motivo di questa diffusione è probabilmente la politica della sua libera distribuzione, lo sviluppo open-source e il fatto che sia disponibile per un gran numero di piattaforme hardware. Già da molti anni sono disponibili un buon numero di risorse per l’accessibilità per questo sistema, ma molte di queste sono state studiate per interfacciarsi solamente con l’ambiente a comandi, in una modalità simile a quella della riga di comando del DOS. Fino poco tempo fa l’interfaccia grafica è rimasta, in sostanza, inaccessibile agli utenti disabili. Come ricordato anche da Robero Scano in un’intervista3 pubblica sul Web, nel mondo opensource solo recentemente si sta muovendo un notevole interesse nell’aggiornamento dei prodotti verso le caratteristiche di accessibilità, soprattutto con la finalità di introdurre questo sistema nelle pubbliche amministrazioni. 1 2 3 [http://msdn.microsoft.com/library/default.asp?url=/downloads/list/accessibility.asp] [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc/html/actvaccess.asp] Roberto Scano: [http://www.scarichiamoli.org/main.php?page=interviste/scano] - 369 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR In effetti, sia la Section 508 sia la legge Stanca recano dei requisiti che anche i sistemi operativi devono soddisfare per essere adottati nelle pubbliche amministrazioni. Fino poco tempo fa la comunità di sviluppatori Linux ha puntato soprattutto sugli utenti normodotati e lo sviluppo di di interfacce accessibili ed usabili non ha ottenuto un grande riscontro. Questo ha creato un certo ritardo nello sviluppo dell’accessibilità in quanto è necessario ridisegnare le interfacce delle applicazioni se si desidera poterle fornire ad enti pubblici. Ad ogni modo, per quanto Linux possa essere ancora indietro da questo punto di vista sicuramente il tema dell’accessibilità in questo sistema operativo è in pieno sviluppo1. Qualunque iniziativa di un certo rilievo come KDE, GNOME, Mozilla, OpenOffice.org ed altre considerano come un aspetto importante l'accessibilità e l'usabilità dei prodotti e delle interfacce2. Un grosso passo in avanti è stato fatto attraverso un progetto di accessibilità3 focalizzato sull’accessibilità di una interfaccia grafica di Linux molto popolare denominata GNOME. Il GNOME Accessibility Project, rispetto a quello di KDE, si è dedicato fin da subito alla parte di architettura piuttosto che sui prodotti finali. E' una scelta che allunga certamente di più i tempi, ma alla fine tende a portare anche i risultati migliori. Nel progetto esistono sostanzialmente:  Un ingranditore di schermo (Gnopernicus);  Una tastiera virtuale (GOK - Gnome Onscreen Keyboard);  Uno screen-reader;  Un dispositivo di controllo della barra Braille. In aggiunta, è stata creata la GNOME Accessibility Architecture che integra questi strumenti ed altri progetti di terze parti in un ambiente unico. Ad esempio il nuovo desktop GNOME accessibile può far uso di un sintetizzatore vocale di elevata qualità come Festival che è stato sviluppato dalla Carnegie Mellon University e che era già in commercio da diversi anni. Altri strumenti da terze parti includono:  Pacchetti per la configurazione di tastiere e mouse per disabili con le stesse funzionalità di gestione che sono state viste per Windows e MAC OS X (StickyKeys, MouseKeys, RepeatKeys, SlowKeys, ToggleKeys, BounceKeys); 1 2 3  Software per il riconoscimento del parlato;  Software per la gestione della barra Braille; [http://larswiki.atrc.utoronto.ca/wiki/Overview] Marco Trevisan: [http://www.scarichiamoli.org/main.php?page=interviste/trevisan] [http://developer.gnome.org/projects/gap/] - 370 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Software per il riconoscimento ottico dei caratteri (OCR). Altrettanto significativo è anche il KDE Accessibility Project. Il KDE Accessibility Project, ha:  Un ingranditore di schermo (KMagnifier);  Un sintetizzatore vocale (KMouth);  Un supporto che simula il click del mouse (KMouseTool). KMouth non è un lettore vocale (tipo JAWS per Windows), ma un sintetizzatore per le persone che non sono in grado di parlare, e sfruttano la sintesi vocale per sopperire a questo limite fisico. Anche KDE, comunque, sta lavorando alle proprie librerie di sistema per incrementare l'accessibilità nell'architettura, in modo da rendere possibile l'aggancio a tali funzioni anche da parte di altri produttori. Prima di concludere ricordo che a comunità Linux ha attivato da tempo il progetto Blind Linux, con l'intento di garantire l'usabilità del Sistema Operativo Linux alle persone non vedenti 1. Come parte integrante del sistema operativo Suse Linux 7.0 è stato sviluppato lo screenreader Suse Blinux2, un software che permette alle persone non vedenti e ipovedenti di lavorare comodamente con Linux. Suse Blinux non è una parte indipendente o una patch del software, ma piuttosto un programma che lavora in sottofondo. Un vantaggio di ciò è che Suse Blinux non compromette in alcun modo il funzionamento del sistema e gli utilizzatori non vedenti e ipovedenti dispongono dell'uso illimitato di tutte le applicazioni che lavorano sulla consolle di Linux in modalità testo. I sostenitori di Linux affermano che la politica del software libero su cui Linux è basato potrebbe condurre a breve ad un sistema operativo ancora più riccamente accessibile sostenendo che gli utenti con disabilità avranno un controllo più elevato sul loro sistema, ampie possibilità di scelta negli strumenti da usare e saranno meno nelle mani di pochi rivenditori di tecnologie assistive come invece può accadere nel mondo Windows o Apple. Apple MAC OS X Con il rilascio della piattaforma MAC OS X, anche Apple ha incrementato l’accessibilità del suo sistema operativo. Per esempio è possibile adesso accedere in maniera molto migliore alla 1 2 [http://www.webusabile.it/archivio/2001/3/30.aspx] [http://www.novell.com/de-de/products/linuxprofessional/blinux/] - 371 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR interfaccia del sistema operativo via tastiera di quanto non fosse possibile nelle versioni precedenti. In oltre Apple ha implementato l’accessibilità nel suo Carbon Application Program Interface (Carbon API), che consente alle applicazioni che girano su MAC OS X di comunicare più efficacemente con le tecnologie assistive. Apple si riferisce all’insieme delle caratteristiche di accessibilità integrate in MAC OS X denominandole collettivamente Accesso Universale1. Vengono suddivise in 5 blocchi, alcune voci possono essere ripetute in quanto attinenti a più di un area:  Visione: o VoiceOver: una interfaccia vocale che permette di accedere al Macintosh tramite frasi parlate e segnalazioni udibili; o Zoom: che permette di ingrandire qualsiasi parte dello schermo, testo, grafica e video, senza perdere di definizione; o Cursore scalabile: è possibile ingrandire la dimensione del cursore del mouse in modo che sia più facilmente rintracciabile nei movimenti; o Avvisi ed elementi vocali: forniscono un metodo udibile per ricevere le segnalazioni dal computer. Le segnalazioni visive sono pronunciate a voce alta e viene letto il testo che si trova sotto la posizione del mouse; o Impostazioni video: è possibile controllare il contrasto impostando lo schermo in bianco e nero, scala di grigi o a contrasto elevato;  Ascolto: o QuickTime: è uno dei visualizzatori in grado di gestire le sottotitolazioni (captions) e le tracce di testo; o Segnalazioni visive: MAC OS X fornisce allarmi visivi per notificare le segnalazioni dal sistema facendo lampeggiare lo schermo intero; o iChat, iSight: un sistema di video conferenza di alta qualità video in modo da poter mostrare con chiarezza il linguaggio dei segni impiegato dai partecipanti;  Motorie, aiutano nell’impiego del computer nel caso in cui si abbiano delle difficoltà nell’utilizzo della tastiera, del mouse o del track pad: o SlowKeys: impostano un ritardo aggiuntivo dei tasti, da quando vengono premuti a quando hanno effetto, questo per impedire ripetizioni dovute a pressioni indesiderate; 1 [http://www.apple.com/accessibility/] - 372 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR o StickyKeys: utile nel caso che l’utente possa premere un solo tasto per volta. Ogni tasto di una sequenza viene mostrato sullo schermo in modo da poter verificare la sequenza e correggerla, se necessario, prima che venga eseguita; o Impostazioni di tastiera: è possibile impostare il tempo di ritardo e di ripetizione dei tasti utilizzando utilmente questa funzionalità insieme a quella di SlowKeys; o Navigazione via tastiera: permette di interagire con il sistema utilizzando la tastiera. Le scorciatoie da tastiera consentono d attivare procedure con la pressione di un singolo tasto; o MouseKeys: è possibile impiegare il tastierino numerico per muovere il cursore in modo da simulare le normali attività del mouse; o Riconoscimento vocale: consentono di controllare il computer usando la voce. Si possono usare comandi per aprire e chiudere programmi, navigare nei menu, spostarsi tra gli applicativi in esecuzione ed i controlli della finestra attiva;  Apprendimento, vengono offerte soluzioni per assistere nel processo di apprendimento in campo letterario, matematico e di assistenza alla scrittura: o Pronuncia del testo sotto il mouse: Il sistema riconosce i comandi del software di pronuncia e i nomi di ogni file; o Avvisi vocali: il computer può pronunciare a voce alta i messaggi che appaiono sullo schermo; o Text-to-speech.:permette al computer di pronunciare i messaggi di avviso, ci sono diverse voci tra cui scegliere; o TextEdit: pronuncia un documento intero o un testo selezionato; o Calcolatrice: pienamente accessibile dalla tastiera può essere impiegata con la pronuncia di ogni tasto che viene premuto e del risultato del calcolo; o  iChat AV: con un controllo di dizione incluso per studenti con disabilità cognitive; Linguaggio e comunicazione, metodi di comunicazione alternativa per aiutare nello sviluppo del linguaggio: o TextEdit: può pronunciare un intero documento o un testo selezionato. Tuttavia, nonostante questi sforzi, i prodotti di tecnologia assistiva disponibili per MAC OS X, ancora ad oggi, sono molto meno diffusi di quanto non lo siano quelli per Windows. Ad esempio i produttori di screen-reader e di ingranditori per MAC OS non garantiscono la continuità dello sviluppo di questi applicativi. Si tratta di un problema storico di sviluppo, giacché MAC OS X è adesso in grado di supportare la maggior parte delle funzioni di accessibilità offerte anche da Windows. DOS Come fatto presente in precedenza, DOS e Unix non avevano un’interfaccia grafica. - 373 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Questo permetteva alle tecnologie assistive di interfacciarsi con il sistema con relativa semplicità rielaborando quanto presente nella memoria della scheda video. Per questo non è raro incontrare anche oggi alcuni utenti disabili che lavorano con dei pacchetti software sviluppati per DOS, nonostante che questo sistema operativo non sia più supportato da molti anni. In aggiunta esiste un pacchetto applicativo aggiuntivo sviluppato dalla stessa Microsoft che permette di arricchire questo sistema con ulteriori funzionalità. Il software si chiama AccessDos1 ed è disponibile per tutti i sistemi MS-DOS dalla versione 3.3 in poi. Richiede pochissima memoria di sistema e può essere facilmente disabilitato per un utilizzo normale. AccessDOS è un programma di utilità che facilita l’utilizzo del mouse e della tastiera per disabili motori e consente di mostrare a video gli avvisi acustici del sistema. Tra le caratteristiche rilevanti ci sono:  Tasti permanenti (stickyKeys) che permettono, come per Windows, di premere un tasto per volta nelle combinazioni in cui sono richieste pressioni simultanee. Il sistema è utile soprattutto per utenti che impiegano cannucce o movimenti della testa per interagire con il computer;  Sensibilità della tastiera (SlowKeys) che permette il controllo del tempo della pressione di un tasto in modo che le applicazioni non considerino i tasti che non sono tenuti premuti per un intervallo minimo di tempo;  Ripetizione dei tasti (RepeatKeys) che permette di impostare il tempo dopo il quale un tasto tenuto premuto viene ripetuto;  Pressioni ripetute (BounceKeys), che permettono di ignorare lo stesso tasto premuto più volte in rapida sequenza;  Controllo del mouse (MouseKeys), che permette di spostare e controllare il mouse via tastiera, dando anche un controllo fine sui movimenti di precisione;  Tasti attivi (ToggleKeys), che permettono di avere un riscontro audio per l’attivazione e la disattivazione dei classici tasti di maiuscole, blocco tastierino numerico e blocco scorrimento;  Interfaccia esterna (SerialKeys), che permette, in congiunzione con un dispositivo di interfaccia ausiliare di controllare il computer utilizzando un sistema di ingresso alternativo come se stesse utilizzando mouse o tastiera; 1 [http://ms.helifan.net/enable/products/ados.aspx] - 374 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Avvisi visivi (soundSentry), che permette di riportare gli avvisi sonori in segnalazioni visive con il lampeggiamento dello schermo o di parte di esso. Queste caratteristiche sono molto simili ad alcune di quelle implementate in Windows e Mac OS, e sono state descritte in quella sede. Possono lavorare in congiunzione fra loro e possono essere disabilitate in automatico dopo un certo periodo di attesa del sistema V.5 - Applicativi e formati proprietari Con le WCAG 1.0, i metodi per realizzare dell’accessibilità erano tutti focalizzati sulle tecnologie suggerite dal W3C, ed il resto del mondo non era sostanzialmente considerato. Il cambiamento essenziale di prospettiva è arrivato in breve con l’osservazione che molti dei contenuti Web non venivano, in questo modo, normati. Un esempio per tutti i documenti PDF che oramai sono considerati uno standard di fatto per mettere a disposizione informazioni in forma chiusa ed impaginata. Per questo le WCAG 2.0 sono state riprogettate per contenere linee guida che includano considerazioni anche per questi formati esterni al W3C. Nello stesso tempo anche i progettisti di tecnologie esterne al W3C hanno sviluppato una sensibilità molto maggiore al problema mettendo a disposizione del Web nuovi strumenti e nuove direttive per rendere accessibili i propri formati. Un esempio per tutti è Macromedia Flash, nel frattempo passato sotto il controllo di Adobe, che dalla versione 5 alla versione 6 e MX ha fatto passi da gigante in termini di accessibilità1. In generale possiamo quindi affermare che non è contro l’accessibilità inserire nella pagina dei collegamenti a dei formati non proprietari del W3C, a patto che tali contenuti siano poi resi accessibili usando le tecniche suggerire dai produttori e i principi guida esposti nelle WCAG 2.0. Alcune norme basilari possono essere attuate per aumentare l’accessibilità:  Inserire un collegamento ipertestuale che rimandi al plug-in proprietario in modo che esso possa essere scaricato nel caso non sia già installato nella macchina;  Fornire, quando possibile, dei collegamenti ipertestuali alternativi a documenti in formato non proprietario (TXT) o aperto (RTF);  Indicare, nel collegamento ipertestuale, la dimensione e la tipologia del file esterno, come segnalato nelle tecniche per i collegamenti ipertestuali, in modo che l’utente possa valutare l’onere e l’interesse dell’oggetto collegato. 1 “Something quasi-miraculous came to pass while I was writing this book: Macromedia Flash went from completely inaccessible to quite accessible overnight.” – [http://joeclark.org/book/sashay/serialization/Chapter13.html] - 375 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR La situazione per quanto riguarda la leggibilità dei formati più diffusi è oramai di buon livello: Microsoft Word e Microsoft Excel in ambiente Windows sono perfettamente accessibili con gli screen-reader. Con JAWS è possibile utilizzare la maggior parte delle applicazioni Windows, come la suite Microsoft Office: Word, Excel, Access, PowerPoint, Outlook, per quanto sia comunque sempre da preferirsi il formato RTF al DOC in quanto risulta più universale e compatibile. Per gli utenti che non abbiano installato Microsoft Excel esiste un apposto visualizzatore fornito dalla Microsoft (Excel Viewer) che però, prima della versione Office 2007, non era ancora accessibile. Power Point rappresenta un problema più significativo. In tal caso occorre disporre del programma in versione completa per potervi accedere con uno screen-reader. Il visualizzatore fornito da Microsoft (PPT Viewer) non è accessibile per le tecnologie assistive. Ma anche fosse reso accessibile, occorre avere bene in mente, nel momento di produrre dei documenti in PowerPoint, che le tecnologie assistive possono solo avere accesso ai contenuti testuali. Per questo motivo ogni immagine ed ogni animazione dovrebbe essere opportunamente trattata con dei testi alternativi. A questo punto occorre chiedersi se valga veramente la pena produrre il contenuto informativo in Power Point, e non sia invece più sensato predisporre un file (X)HTML che dovrebbe comunque essere fornito in alternativa alla presentazione in Power Point non pienamente accessibile. Da segnalare che la conversione in automatico consentita direttamente in Power Point non produce risultati accettabili e deve sempre essere rivista manualmente. Per ultimo va segnalato che tutta la suite OpenOffice non è ancora stata resa accessibile, come anche ribadito da Luca Mascaro al corso IWA nel 2005. Vediamo adesso una breve panoramica dei formati più diffusi. Molte di queste informazioni sono disponibili in rete sul preciso e completo sito 1 di WebAIM. Prima di presentare questi formati vorrei riportare la segnalazione di un manuale aperto2 per la divulgazione e la scrittura di testi per il Web, segnalazione fatta presente da Roberto Ellero al seminario IWA del Maggio 2005. Il testo è molto completo e contiene anche molte altre informazioni aggiuntive sulla corretta preparazione di contenuti informativi per il Web. 1 2 [http://www.webaim.org/articles/] [http://wiki.porteapertesulweb.it/space/Manuale+aperto] - 376 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Microsoft Word Microsoft Word non è sicuramente il formato consigliato per offrire documenti informativi disponibili in rete. Questo per il fatto che esistono altri formati proprietari, come ad esempio lo stesso PDF, che, oltre ad essere notevolmente più snelli, garantiscono anche una migliore sicurezza dei dati. Ad ogni modo è possibile rendere parzialmente accessibile anche un documento in Word utilizzando alcune avvertenze basilari. Creare documenti strutturati La maggior parte delle persone usa i programmi di word processing in maniera scorretta. Invece di usare delle vere intestazioni, spesso semplicemente si allarga la dimensione del font e lo si mette in grassetto. Se si agisce in questo moto, il documento finisce per non possedere una vera struttura che possa essere identificata da uno screen-reader. Il modo giusto per implementare una struttura dentro un documento di word è quello di utilizzare gli apposti stili. Word stesso fornisce una casella di riepilogo per gli stilli che permette all’utente di creare delle intestazioni corrette anche dal punto di vista strutturale e semantico. Ci sono almeno due grossi vantaggi nel creare una vera strutturazione dei documenti Word. Innanzi tutto, quando il file verrà esportato in un formato HTML, manterrà la struttura rendendolo accessibile ai lettori di schermo. In secondo luogo la struttura verrà similmente mantenuta anche in una esportazione in un formato PDF. In ambedue i casi, la struttura aggiunta aumenta la leggibilità del documento sia per le persone che utilizzano degli screen-reader che per coloro che semplicemente vogliano avere un accesso migliore e più organizzato al testo. Fornire una alternativa testuale per le immagini Prima di esportare un documento di Word in HTML o PDF, è necessario fornire una alternativa testuale a tutte le immagini contenute. Per fornire un’alternativa testuale è sufficiente modificare la proprietà “Web” sulla scheda “Formato Immagine” ed aggiungere l’appropriato testo alternativo. Le regole sulla scrittura di questo testo alternativo sono le stesse esposte per le pagine HTML, questo poiché, nella conversione in (X)HTML, questo testo sarà quello inserito nell’attributo ALT. - 377 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Salvare il file come HTML Quando il file verrà salvato in formato HTML, la struttura implementata con le intestazioni e il testo alternativo fornito con le immagini faranno parte del documento finale. Per salvare il documento in formato HTML, selezionare “Salva come pagina Web” dal menu file. Nelle edizioni più recenti di Word sarà a questo punto possibile scegliere due modalità di salvataggio, come pagina Web o come pagina Web filtrata. Il vantaggio della prima scelta è che la pagina avrà praticamente lo stesso aspetto del documento stampato. Il vantaggio della seconda è che avrà molti meno materiale aggiuntivo in HTML. La dimensione del file nel secondo caso sarà significativamente inferiore a discapito di un aspetto che potrebbe essere parzialmente difforme da quello del documento originario. In termini di accessibilità entrambe le soluzioni sono accettabili con il presupposto che il file sorgente sia stato creato con la struttura e con il testo alternativo per le immagini e non contenga nessun tipo di tabelle dati. Problemi di accessibilità con le tabelle dati. Nella maggior parte dei casi un documento di Word può essere convertito in un file HTML accessibile, ma ci sono alcune eccezioni. Le tabelle non possono essere convertite in tabelle dati accessibili utilizzando il formato di pagina Web filtrata. Questo per il fatto che non c’è alcun modo per assegnare l’intestazione di tabella o l’elemento TH ad una cella di una tabella in Word. Esiste tuttavia un’opzione all’interno di Word per fare in modo di creare l’aspetto di una intestazione di tabella. Questa proprietà può essere impostata selezionando le proprietà della tabella. Sotto la scheda “Riga” si trova una casella di controllo: “Ripeti riga come intestazione in ogni pagina”. Spuntare questa voce farebbe pensare che tutte le celle della riga saranno esportate come elementi di intestazione ma non è così. Le celle invece saranno contenute in un blocco THEAD. Come specificato nella sezione delle Metodologie generali, i blocchi THEAD, TFOOT, TBODY sono usati per dividere le tabelle nelle 3 parti fondamentali delle tabelle dati. Non ci sono problemi con l’utilizzo di quest’elemento, tuttavia esso non sostituisce l’utilizzo dell’elemento TH nell’esportazione. Limitazioni Occorre porre attenzione al fatto che il processo di conversione di un documento complesso con grafici, tabelle o altri elementi interni, probabilmente non creerà un file che sia completamente accessibile agli screen-reader. Gli elementi inclusi saranno probabilmente - 378 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR ignorati nella lettura, giacché risultano illeggibili. In queste circostanze si dovrebbe fornire almeno una descrizione testuale degli oggetti all’interno del contesto del documento stesso. Un utile strumento di conversione esterno al pacchetto Microsoft Office può essere l”Illinois Accessible Web Publishing Wizard”1 disponibile per i sistemi operativi Windows. La versione completa è a pagamento, ma esiste una versione dimostrativa scaricabile gratuitamente. Adobe PDF Per quanto questo formato non sia una delle tecnologie suggerite dalle WCAG 1.0, tuttavia molti sviluppatori di pagine internet lo hanno pesantemente utilizzato per la pubblicazione dei testi in rete, anche per la oramai diffusa presenza del suo lettore su quasi tutte le piattaforme. Rispetto a documenti Microsoft World possiede l’innegabile qualità di essere notevolmente più compatto ed efficace, in oltre i documenti in PDF sono da ritenersi chiusi alle modifiche, a meno che non si disponga di uno strumento adatto disponibile a pagamento. Molti testi potrebbero ovviamente essere scritti direttamente in (X)HTML come raccomandato dalle WCGA 1.0, tuttavia gli effetti di impaginazione e presentazione grafica dei contenuti PDF ne fanno un vantaggioso compromesso a cui è stato impossibile rinunciare. Di fatto l’utilizzo di questo formato viene tollerato ed accettato da tutte le normative in quanto si considera oramai la sua accessibilità valutandola dal punto di vista del testo contenuto piuttosto che da quella della standardizzazione del formato. Da questo punto di vista l’attenzione di uno sviluppatore nei riguardi dell’accessibilità di un documento PDF va posta in due direzioni:  Uso corretto degli elementi di struttura e semantica messi a disposizione;  Chiarezza, strutturazione e comprensibilità del testo contenuto. Adobe ha a disposizione sul suo sito un manuale completo sull’accessibilità e su come produrre documenti PDF accessibili e come rendere tali quelli esistenti 2. Qui voglio presentare una piccola guida introduttiva alla comprensione del problema. La maggior parte delle informazioni sono validamente esposte sul sito3 di WebAIM (Web Accessibility in Mind). Un interessante e completo lavoro sull’accessibilità dei documenti PDF è quello di Andrea Pes 4. 1 [http://cita.rehab.uiuc.edu/software/office/] [http://www.adobe.com/enterprise/accessibility/acrobat70.html] 3 [http://www.webaim.org/articles/] 4 Andrea Pes: “Metodologie e tecniche per l'accessibilità di documenti Adobe PDF” [http://elite.polito.it/tesi/pes.pdf] 2 - 379 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Va fatto notare, ancora prima di iniziare questa breve analisi, che un documento PDF protetto non è accessibile. Se viene bloccato attivando la protezione diventa come un immagine, e come tale non risulta leggibile dalle tecnologie assistive che non sono in grado di accedere al testo contenuto. Bloccando il PDF si perde l’accessibilità. Accessibilità dei documenti PDF L’uso appropriato dei documenti PDF è un argomento molto dibattuto, sia per quanto riguardi l’accessibilità che per quanto non la riguardi. Qualcuno vorrebbe dedurre che non ci sia spazio per i documenti PDF, mentre altri sostengono che, opportunamente preparati, i documenti PDF siano altrettanto accessibili quanto le pagine HTML. Probabilmente la verità è una via di mezzo di queste due letture. Per fare in modo che un documento PDF sia veramente accessibile occorre soddisfare due condizioni: 1. L’autore del documento deve creare un PDF ben strutturato e correttamente marcato; 2. Il lettore deve in grado di impostare le sue preferenze di accessibilità all’interno di Adobe Reader. Vedremo adesso di analizzare entrambe queste due condizioni. Le esigenze degli utenti Come nel caso di documenti HTML occorre tenere presente a che tipologia di problematiche può andare incontro un disabile nella lettura di un documento PDF. Quando si parla dell’accessibilità di Adobe Acrobat o dei documenti PDF ci si riferisce in genere all’accessibilità di Acrobat per uno screen-reader, ma gli utenti di screen-reader non sono le sole persone che dovrebbero essere considerate al momento di produrre un documento PDF accessibile. E’ importante ricordare che non tutti i disabili sono ciechi. Occorre tener presente i bisogni di individui con disabilità motorie, uditive, cognitive o con problemi di ipovisione. Vediamo alcune linee guida generali per rendere i documenti PDF accessibili alle persone con diverse tipologie di disabilità:  Disabilità motorie. Non fare gli hot spot troppo piccoli. Naturalmente la frase troppo piccoli è relativa, ed è anche vero che gli utenti possono ingrandire il documento, ingrandendo in questo modo anche gli hot spot all’interno del documento. Ad ogni modo più piccolo sarà il collegamento e più difficoltoso sarà per le persone con difficoltà motorie accedere al collegamento stesso;  Disabilità uditive. Fornire trascrizioni per gli elementi multimediali. Se viene incluso un elemento - 380 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR multimediale tramite un suono nel documento PDF, questo escluderà sia i sordi che i sordo ciechi a meno che non venga fornita una trascrizione. Occorre fornire titolazioni sincronizzate con il video. Le persone sorde hanno bisogno di questo tipo di servizio se il video perde di significato quando l’audio non è percepibile;  Disabilità cognitive. Usare un linguaggio semplice e chiaro. In altre parole, scrivere bene. Meglio si riesce a scrivere, meglio si verrà capiti da tutti, non solo da coloro con disabilità cognitive. Bisogna anche porre l’attenzione dovuta nel rendere il documento accessibile agli screen-reader. Non tutte le persone con disabilità cognitive traggono beneficio dal sentirsi letto un documento, tuttavia per qualcuno questo è vero. Al fine di poter essere pronunciato, il documento deve essere accessibile per gli screen-reader;  Ipovedenti. Assicurarsi che ci sia un contrasto sufficiente nel documento PDF. Assicurarsi anche che tutte le informazioni che sono veicolate dal colore siano trasmesse allo stesso modo quando il colore non è disponibile. Potrebbe essere necessario aggiungere qualche segno testuale in aggiunte al colore per trasmettere l’informazione;  Cecità. Prima del rilascio della versione di Acrobat 5.0, i documenti PDF non erano accessibili agli screen-reader in modo significativo. Ora è possibile esporre il testo in un documento PDF agli screen-reader, ma allo stesso modo dei documenti HTML, i file PDF devono essere prodotti tenendo ben presente il fine dell’accessibilità. Altrimenti i documenti PDF potrebbero essere altrettanto inaccessibili come prima dell’avvento di Acrobat 5.0. La notizia spiacevole è che di solito questo richiede un maggior lavoro che non rendere accessibile un documento HTML. Per quanto, ad ogni modo, possa essere fatto con uno sforzo ragionevole. Due approcci alla accessibilità. Per quanto Adobe stia facendo il massimo sforzo per rimuovere le barriere di accessibilità dai suoi prodotti, tuttavia (X)HTML è ancora il formato Web da preferire per venire incontro alla maggioranza di utenti con disabilità. Ci sono due modi di affrontare il problema: 1. Fornire un’alternativa HTML al documento PDF, in aggiunta o in sostituzione; 2. Rendere accessibile il documento PDF dalla sua nascita, creando un documento strutturato in maniera opportuna. Se l’equivalente (X)HTML è più accessibile del documento PDF e fornisce lo stesso contenuto informativo, sarebbe più appropriato eliminare del tutto il documento PDF e concentrarsi - 381 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR piuttosto sul rendere il contenuto accessibile in formato (X)HTML. Questo non è sempre attuabile, ma in molti casi vale la pena considerare questa scelta. Creare un documento PDF strutturato in maniera accessibile lo renderà accessibile agli screenreader standard che supportano i PDF strutturati con marcatori, come ad esempio JAWS e Windows Eyes. Questo eliminerà il bisogno per l’utente finale di imparare ad usare il sintetizzatore vocale interno di Adobe. Tuttavia non è sempre facile produrre documenti PDF che siano direttamente accessibili agli screen-reader. Potrebbe essere estremamente difficile, se non impossibile, convertire in un PDF accessibile i documenti di aspetto complesso, e questo per il fatto che il contenuto non si linearizza in forma corretta. In oltre risulta molto difficoltoso rendere accessibili documenti con grafici estesi o con video inclusi. Creare un file HTML dal documento originale Se si deve convertire un documento PDF in un file (X)HTML, la cosa migliore è sempre quella di recuperare il documento sorgente. Sarà più facile convertire l’originale in Word in un file HTML che non fare la stessa cosa tramite il passaggio in PDF. E’ importante ricordare che quando si converte un file da Microsoft Office, solamente i file ben formati produrranno dei documenti (X)HTML o PDF ben formati. Si devono utilizzare le intestazioni reali, non semplicemente i font allargati o in grassetto, le liste puntate o numerate e gli altri marcatori strutturali nel documento originale. Se non si procede in questo modo i marcatori corretti non verranno creati quando il documento viene convertito in (X)HTML o PDF. Per molti questo vuol dire imparare ad usare gli elementi strutturali in Word, visto che spesso non si da sufficiente importanza alle opzioni di stile all’interno di un word processor. La mentalità di dare attenzione solo all’aspetto visuale deve cambiare per ottenere dei contenuti accessibili ed utilizzabili dagli screen-reader. Consultare la parte specifica su Word per avere informazioni in proposito. Convertire un documento PDF in un file HTML Qualche volta il file originale usato per creare il PDF non è a disposizione. In tal caso è possibile creare un file (X)HTML usando Acrobat, ma il file sarà probabilmente piuttosto complesso e richiederà più lavoro per renderlo accessibile. Per creare un file (X)HTML in Adobe Acrobat scegliere la voce dal menù “Salva come…”. Il documento (X)HTML che verrà prodotto in questa conversione sarà però di qualità piuttosto scadente, tanto che probabilmente occorrerà spendere lo stesso tempo nel tentativo di ripulirlo di quello che si impiegherebbe a crearlo ex novo. Se sono presenti delle immagini, solamente la descrizione alternativa delle immagini sarà salvata piuttosto che l’immagine stessa e non saranno presenti nessun tipo di tabelle nel file (X)HTML, anche se la tabella fosse stata appropriatamente marcata nel file PDF originale. - 382 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR I marcatori PDF I marcatori PDF sono una rappresentazione solo testo del documento nascosta all'interno del PDF e presentata ai lettori dello schermo. Esistono per i soli scopi di accessibilità e non hanno effetto visibile sul file PDF. I marcatori (X)HTML ed i marcatori PDF spesso usano gli stessi nomi e le stesse strutture organizzative ma sono piuttosto differenti. Ad esempio non è possibile inserire un marcatore PDF nel codice con le stesse modalità con cui invece è possibile per quelli (X)HTML. Tuttavia, se si hanno conoscenze dell’(X)HTML, probabilmente sarà più semplice creare ed editare file PDF marcati. La scheda dei marcatori Alla scheda dei marcatori si può accedere con Acrobat Professional. Da qui è possibile riordinare, modificare, cancellare e creare i marcatori. Per visualizzare i marcatori si accede al menù vista fino alla scheda dei marcatori. Una lunga lista navigabile di marcatori appare visibile e può essere espansa o collassata. Selezionare un marcatore implica evidenziare anche il testo, l’immagine o gli altri elementi che vi si trovano racchiusi. Allo stesso modo è possibile evidenziare il marcatore dove è incluso un elemento a partire dall’elemento stesso. Molti di questi marcatori sono simili, se non identici a quelli HTML tra cui: 
..
: per le intestazioni; 
: per i paragrafi;  ,
: per le liste;  , ,
,
: per le tabelle; 
, in luogo di per le immagini. Queste sono le specifiche di Adobe. Ma non sono sempre quelle usate da altri programmi, quando creano un PDF. Microsoft Word ad esempio produce alcuni marcatori insoliti, come ad esempio in luogo di
. Questi marcatori possono ad ogni modo essere riportati opportunamente ai marcatori PDF usando delle regole di mappatura che possono essere cambiate dal menù delle opzioni. Controlli di accessibilità. Acrobat versione professional include due differenti tipi di controlli per l’accessibilità del documento:  Controllo rapido. Essenzialmente verifica se il file possiede dei marcatori oppure no. Tuttavia non rintraccia i più comuni errori di base come la mancanza di un testo alternativo; - 383 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Controllo avanzato. Sebbene sia definito come più avanzato, è ben lontano dall’essere completo. Ad ogni modo identifica caratteristiche come la mancanza di testo alternativo e offre suggerimenti su come riparare alcuni errori. Allo stesso modo di un documento HTML, uno screen-reader legge un documento PDF basandosi sull’ordine dei suoi marcatori. Ma l’ordine dei marcatori in un documento PDF potrebbe non essere lo stesso di una lettura visiva. Questo è vero in particolar modo se il documento PDF contiene colonne multiple o altri blocchi di testo o liste complesse annidate. Esiste uno strumento che permette di ricostruire l’ordine visuale del testo basandosi sull’ordine dei marcatori. In caso di discrepanze questo è un segnale che l’ordine dei marcatori deve essere riorganizzato. Convertire un documento PDF esistente in un documento PDF con marcatori. Prima di proseguire con questo paragrafo occorre ricordare che, sebbene i PDF con marcatori possono essere creati con l’Acrobat Standard, tuttavia possono essere modificati solamente con la versione Professional. Con questa versione i marcatori possono essere modificati selezionandoli e rinominandoli, ad esempio nel caso si volesse far passare un marcatore di intestazione da livello H1 a livello H2. Un'altra operazione significativa è quella di aggiungere un testo alternativo alle immagini dove mancante o scorretto. Ci sono due modi principali per aggiungere il testo alle immagini direttamente nel documento PDF:  Intervenire sulle proprietà dell’immagine e nella scheda dei marcatori aggiungere il testo alternativo;  Intervenire sul marcatore di testo alternativo se esistente e modificarlo direttamente. I marcatori possono essere anche cancellati o creati ex novo, scegliendoli nella apposita lista presentata da Acrobat e inseriti nel documento. Un utile funzionalità offerta dal programma permette in oltre di riordinarli, annidandoli anche in modo opportuno. Aggiungere marcatori a un file senza marcatori Aggiungere marcatori ad un documento senza marcatori non è molto diverso da editare un file esistente. In effetti, se il file PDF è scarsamente marcato, potrebbe essere più semplice cancellare i pochi marcatori esistenti e ripartire. A questo proposito esiste una funzione apposita che cancella tutta la struttura dei marcatori. Ci sono due sistemi principali per aggiungere i marcatori, il primo è lasciare che Acrobat li aggiunga da se e poi modificarli, il secondo è aggiungerli direttamente in modo manuale. - 384 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Con la prima opzione è possibile inserire automaticamente i marcatori in un file non marcato, tuttavia i risultati sono abbastanza deludenti. Potrebbe essere un modo veloce di cominciare, soprattutto se il documento contiene delle tabelle. Lo si può richiamare dal menù di accessibilità. Occorre ricordarsi poi di proseguire il lavoro manualmente. Altrimenti si può decidere di inserire tutti i marcatori manualmente usando la scheda dei marcatori e partendo dall’elemento radice. Con la versione 7 di Acrobat è stato aggiunto uno strumento ancora più potente per aggiungere marcatori in maniera rapida al documento, il “TouchUp Reading Order” che permette una interfaccia diretta con gli oggetti a cui assegnare i marcatori. Adobe Flash I contenuti di Adobe Flash possono essere visualizzati praticamente su tutti i computer, la tecnologia Flash, in senso lato, potrebbe essere una delle più largamente utilizzate sul Web. Per gli sviluppatori, la possibilità di realizzare una presentazione multimediale che possa essere visualizzata quasi alla stessa maniera su tutti i computer rende questa tecnologia molto seducente. E tuttavia, per le persone disabili, Flash introduce dei problemi di accessibilità peculiari. Flash, proprio per la sua natura multimediale, può essere impiegato per distribuire informazioni attraverso molti canali sensoriali, grafica, testo, video, audio ecc. La sua potenza e la sua flessibilità gli danno la possibilità di presentare il contenuto Web in maniera pienamente accessibile. Flash può aumentare l’accessibilità dei contenuti in diversi modi, sfruttando le sue capacità intrinseche:  Diverse modalità di presentazione;  Scalabilità: Poiché Flash si basa sui vettori e non sulle griglie di pixel, la maggior parte dei contenuti possono essere ridimensionati senza distorsioni, le persone ipovedenti possono interagire con i contenuti Flash in modalità non possibili con i contenuti (X)HTML;  Accessibilità via tastiera: Flash consente un livello di interazione con la tastiera più alto di quanto non sia consentito in (X)HTML, molte presentazioni Flash possono essere resi più funzionali, efficienti e facili da usare abilitando l’accesso da tastiera;  Attrattività: Flash è in grado di coinvolgere attraverso interattività, animazione, suono, grafica e molti altri modi. Persone con disabilità cognitive e di apprendimento possono comprendere meglio e concentrarsi di più sui contenuti Flash. Le presentazioni - 385 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR multimediali di Flash possono essere usate come aggiunta al contenuto statico (X)HTML;  Sistema vocale interno: Per merito delle sue capacità audio, Flash può presentare contenuti audio eliminando il bisogno di ricorrere ad uno screen-reader per estrarre la parte audio dalle presentazioni Flash. Problematiche per l’accessibilità di Flash Nonostante la capacità di Flash di creare contenuti altamente accessibili, ci sono alcuni problemi notevoli a cui bisogna prestare attenzione a proposito dell’accessibilità in Flash. Quasi tutti i concetti che riguardano l’(X)HTML possono essere applicati a Flash, come ad esempio l’uso del contrasto, un sistema di navigazione fruibile, un linguaggio comprensibile, eccetera. I principi per le diverse disabilità sono i seguenti:  Disabilità uditive: o  Epilessia fotosensibile: o     Fornire titolazioni sincronizzate per ogni traccia audio che veicola contenuti; Rimuovere i contenuti lampeggianti con frequenza tra i 2 e i 55 Hz; Disabilità motorie: o Garantire che i contenuti Flash possano essere utilizzabili dalla tastiera; o Non richiedere delle abilità motorie sofisticate; Disabilità cognitive: o Garantire all’utente il controllo sui contenuti a tempo; o Fornire un sistema facile da usare per la navigazione; o Essere coerenti nelle presentazioni; o Utilizzare il linguaggio più semplice e appropriato per il contenuto; Ipovedenti: o Fornire un contrasto adeguato; o Permettere a Flash di ridimensionarsi a dimensioni maggiori; Cecità: o Garantire l’accessibilità degli screen-reader o fornire una alternativa accessibile; o Garantire la completa accessibilità via tastiera; o Non sovrapporsi ai comandi audio o via tastiera degli screen-reader; o Fornire un equivalente testuale per tutti gli elementi non testuali che veicolano contenuti o forniscono funzionalità. - 386 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Per quanto ognuna di queste singole strategie possa incrementare l’accessibilità, un contenuto Flash raramente è correttamente progettato per considerare tutti questi accorgimenti contemporaneamente, rendendolo così inaccessibile in qualche modo. Quando tutte le tecniche di accessibilità sono applicate a Flash, queste lo rendono universalmente accessibile, forse anche di più di quanto non lo sia una pagina (X)HTML, dal momento che viene rimosso il bisogno di ricorrere a specifiche tecnologie assistive come i lettori di schermo. Tuttavia, un tale risultato potrebbe essere impossibile da ottenere con la maggior parte delle presentazioni Flash. In pratica, a meno di non implementare tutte le tecniche di accessibilità, un contenuto Flash risulta solitamente non accessibile. Supporto delle tecnologie assistive per Flash Come visto, la maggior parte di un contenuto Flash non è accessibile in maniera nativa agli screen-reader. Per sua stessa natura il contenuto Flash non si presta all’accessibilità di uno screen-reader. Una presentazione Flash è basata sul tempo e spesso cambia con il tempo mentre un contenuto (X)HTML è più o meno statico, ed è la natura statica dell’HTML che permette allo screen-reader di accedervi. Quando un utente vedente accede ad una presentazione Flash, scorre il filmato e si concentra direttamente sul contenuto importante. Uno screen-reader non può scorrere attraverso il contenuto Flash e può accedere solo in maniera lineare seguendo l’ordine che lo sviluppatore ha scelto per la presentazione. Poiché un contenuto Flash si modifica in continuazione, ci sono dei limiti alle capacità di uno screen-reader nell’accedere al contenuto. Gli screen-reader più importanti (JAWS, Windows Eyes e IBM Home Page Reader) sono in grado di fornire un accesso poco soddisfacente alle presentazioni di Flash più datate precedenti alla 6+. Per avere un’accessibilità completa con gli screen-reader, il contenuto Flash deve essere stato sviluppato per l’accessibilità utilizzando Flash MX o le versioni successive. Nonostante i problemi che Flash può introdurre per gli utenti di screen-reader, tuttavia ci sono delle tecniche di accessibilità che possono essere implementate per rendere Flash più accessibile. MSAA (Microsoft Active Accessibility) può essere impiegata per trasferire un contenuto dal visualizzatore di Flash allo screen-reader. MSAA è una tecnologia Microsoft attualmente funzionante con Internet Explorer su computer Windows che hanno il visualizzatore Flash versione 6 o successive installato. - 387 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Per quanto la maggior parte della tecnologia assistiva viene implementata sulla piattaforma Windows/Explorer, gli screen-reader scritti per altre piattaforme non possono avvantaggiarsi delle caratteristiche di accessibilità di Flash. Ci sono svariati screen-reader che girano su altri sistemi operativi. Persone con disabilità motoria potrebbero non usare Internet Explorer, ed ancora alcuni potrebbero non aver installato un visualizzatore Flash compatibile, anzi, potrebbero non averlo del tutto. Molti utilizzatori di screen-reader hanno disabilitato i contenuti Flash a causa del gran numero di presentazioni Flash inaccessibili presenti sulla rete. In breve occorre condurre dei test con uno svariato numero di utenti, sistemi operativi, browser e tecnologie assistive per garantire che il contenuto Flash sia accessibile alla maggiore quantità possibile di utenti. Per questo occorre ripensare attentamente alla scelta di utilizzare Flash, visto che probabilmente un'altra tecnologia potrebbe essere di maggior ausilio. Poiché la maggior parte dei contenuti Flash non possono essere resi intrinsecamente accessibili, sarà necessario fornire una alternativa non in Flash per coloro che non possono o non vogliono accedervi. Accessibilità per gli screen-reader. Ci sono 3 modi in cui una presentazione Flash può essere resa accessibile ad un utente di screen-reader:  Rendere il contenuto Flash intrinsecamente accessibile allo screen-reader;  Rendere il contenuto Flash auto eloquente, eliminando in questo modo il bisogno di uno screen-reader;  Fornire una alternativa accessibile al contenuto Flash. Rendendo la presentazione di Flash auto eloquente, si elimina il bisogno di ricorrere ad uno screen-reader. In pratica si rimpiazza il ruolo dello screen-reader veicolando all’audio interno di Flash ogni contenuto che viene presentato visivamente. Lo screen-reader dell’utente dovrebbe essere avvisato che il programma ha funzionalità audio autonome in modo che lo screenreader viene posto in pausa mentre Flash si preoccupa di svolgere i suoi contenuti audio. In tal caso, qualsiasi contenuto video importante deve essere fornito via audio, un’idea di come realizzare questa funzionalità può essere intuita ascoltando la radiocronaca di un evento sportivo. Si potrebbe anche inserire una funzionalità audio autonoma con il compito di fornire un’alternativa per una presentazione senza audio o offrire all’utente una opzione per attivare o meno la parte audio. - 388 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Ad ogni modo per qualsiasi contenuto audio fornito che non sia evidente dal video, occorre fornire delle titolazioni per i disabili uditivi e la presentazione deve essere accessibile via tastiera. Un'altra procedura importante è fornire una alternativa equivalente all’intera presentazione Flash. Questo è in particolar modo necessario quando la stessa presentazione non può essere resa accessibile in nessun altro modo. Sembra piuttosto difficile spiegare come una presentazione Flash multimediale possa essere resa in maniera equivalente con un documento (X)HTML. La cosa importante è rendere equivalente il contenuto alternativo, e questo non necessariamente con l’impiego di solo testo. Invece di fornire una pagina solo testo, l’equivalente potrebbe essere una pagina Web ben presentata con immagini, icone, paragrafi e colori. Il fatto che qualcuno acceda a questa pagina non implica che egli sia per forza disabile. Spesso l’alternativa accessibile può essere nella stessa pagina dove si trova la presentazione Flash. Talvolta si può anche dare all’utente la possibilità di disabilitare o meno i contenuti Flash. V.6 - Interviste In una trattazione completa di questo problema non possono mancare le opinioni raccolte sul campo, sia degli utenti disabili direttamente coinvolti nell’accesso alle informazioni internet, sia degli operatori che si trovano a gestire e risolvere i problemi quotidiani dell’handicap. Paolo de Cecco CONSULENTE ESTERNO PER LE TECNOLOGIE D’AUSILIO PER LA LEGA DEL FILO D’ORO. TRASCRIZIONE ED ADATTAMENTO DI UN INCONTRO TENUTOSI AD ANCONA IL 29 DICEMBRE 2006. La conversazione si è tenuta con un breve colloquio informale, costituito da domande e risposte. La sintesi qui riportata è stata riadattata e suddivisa per argomenti allo scopo di facilitarne la stesura e la comprensione. Gli strumenti di base Uno dei primi ausili messi a disposizione per favorire l’interazione con il computer da parte degli utenti non vedenti è stata la barra Braille. La barra Braille è composta da un certo numero di celle disposte in orizzontale. Il Braille codifica un carattere in un insieme di punti: il Braille classico è costituito da una sequenza ordinata di 6 punti, suddivisi in due colonne verticali, la colonna di sinistra numerata da 1 a 3, la colonna di destra numerata da 4 a 6. - 389 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR La singola cella è un rettangolo di un centimetro di altezza per mezzo centimetro di larghezza circa. Il Braille informatico è arricchito da due punti aggiuntivi in basso per un totale di 8 punti. Con l’informatica, infatti, è giunta la necessità di codificare più informazioni e si usano due colonne da 4 punti. La scrittura di tutti i caratteri rimane basata sui 6 punti classici mantenuti anche con l’avvento della nuova codifica. I due puntini in basso, il 7 e l’8, vengono usati per gli attributi, ad esempio il 7 si usa per la maiuscola. Nel Braille classico si definiva invece un carattere precedente segna-maiuscolo o segna-numero che aveva il compito di precedere una cambiamento di significato del carattere successivo. Questo può essere poco efficiente dal momento che le barre Braille standard sono di 40 o da 80 caratteri: i puntini aggiuntivi 7 ed 8 permettono di accorciare la lunghezza dei testi. Altro utilizzo importante dei due punti aggiuntivi è l’evidenziazione del focus di Windows grazie alla sottolineatura fornita proprio dai 2 puntini bassi. La lunghezza standard di 40 ed 80 caratteri per le barre Braille è direttamente derivata dalla originaria dimensione in caratteri degli schermi del computer nel sistema DOS, dove queste barre sono originate. Il software che si interfaccia, il cosiddetto screen-reader, ha come funzionalità di base quella di seguire automaticamente il focus visualizzato sullo schermo. Il computer viene usato impiegando anche la tastiera standard, ad esempio il tasto Windows che permette di attivare il menu di avvio o le frecce per scegliere la voce che interessa. L’uso della tastiera normale viene affiancato dalla barra Braille che viene posta al di sotto della tastiera ordinaria al punto che qualche volta viene chiamata tastiera Braille. Le mani passano dalla tastiera alla barra per leggere le informazioni del video. La lettera “F” e la lettera “J” sono dotate di una sottolineatura in rilievo e un non vedente riceve conferma dei tasti premuti con l’eco della tastiera mediante un sintetizzatore vocale. In genere vengono utilizzati più ausili contemporaneamente, un software come uno screenreader è in grado di avere il controllo sia di una barra Braille che di un sintetizzatore vocale in una stessa seduta di lavoro. Tra gli screen-reader JAWS è oramai considerato uno standard, tra gli altri si ricordano HAL e Windows Eyes. Le differenze sono nel gruppo di lavoro che li sviluppa e li implementa. Un gruppo di lavoro più significativo può garantire risultati più efficaci. JAWS ha già al suo interno una serie di script predefiniti concepiti appositamente per le singole applicazioni. Infatti, un conto è un funzionamento standard, un conto è quando ci si deve adattare ad una particolare applicazione che impieghi, ad esempio, uno specifico controllo di Windows. Lo screen-reader, quando viene lanciato, carica uno script di default. Ogni volta che viene eseguita una applicazione viene verificato se esiste uno script con lo stesso nome - 390 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR dell’applicazione, ed, in caso, questo viene automaticamente eseguito. Si può definire uno script per ogni applicazione oltre che dei file di configurazione specifici. Si potrebbe predisporre anche uno script che annulla o limita il funzionamento di JAWS. Questa procedura è utile nel caso venga lanciato un applicativo che abbia già una sua sintesi vocale interna. In queste circostanze la sintesi vocale di JAWS può essere disabilitata e riattivata solamente quando il focus ripassa ad un’altra applicazione che non abbia un suo sintetizzatore proprietario. Esistono poi dei video-ingranditori e dei software ingrandenti. I primi sono dei sistemi esterni che permettono di ingrandire il testo cartaceo con una telecamera, possono eventualmente essere visualizzati su un monitor o sul video del PC trasferendo la lettura esterna. I software ingrandenti lavorano invece a stretta simbiosi con gli applicativi, per la maggiore va lo ZoomText. La SubVision, di Milano1, fornisce una valida assistenza sia per l’hardware sia per il software. Il software Nel settore dei non vedenti esistono alcuni software che nascono già con la sintesi vocale interna. Ad esempio i programmi per la lettura dei testi con sistemi di OCR (Optical Character Recognition). Si mette un foglio sullo scanner, viene fatta una scansione con un riconoscimento dei caratteri e poi il testo viene passato alla sintesi vocale. In questo caso JAWS viene privato dell’audio per evitare una sovrapposizione delle voci. Una delle difficoltà abbastanza classiche che si possono incontrare è quella di trovarsi a lavorare con delle applicazioni che hanno impiegato in fase di sviluppo degli oggetti e dei controlli che non sono quelli standard di sistema, ad esempio un campo editor di testo che non sia stato progettato con il classico oggetto box di Windows. In tal caso JAWS non riesce a riconoscere la classe dell’oggetto. Tuttavia JAWS è abbastanza intelligente di proporre all’utente, in questi casi, il migliore trattamento del componente, fornendo una elenco delle classi che più potrebbero essere simili e permettendo all’utente di definirne le migliori modalità di comportamento per somiglianze. Queste informazioni possono essere memorizzate e rese permanenti. JAWS è diventato uno standard d’utilizzo, con una enorme diffusione. Le varie versioni hanno avuto il compito di seguire gli aggiornamenti del sistema operativo per adeguarsi agli oggetti esposti. 1 [http://www.subvisionmilano.com/new/index.php] - 391 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Da Windows Millenium in poi, nell’ambiente Microsoft, è possibile avere a disposizione alcune libreria di interfaccia di sistema concepite appositamente per migliorare l’accesso degli screenreader. Un esempio di questa filosofia sono le MSAA (Microsoft Active Accessibility) API di Windows. All’atto dell’installazione di alcuni applicativi come gli screen-reader o i sistemi ingrandenti viene verificata l’esistenza di queste API sulla macchina ed in caso contrario viene richiesto espressamente di installarle. Questo non solo per JAWS, ma anche per molte tecnologie assistive, in caso contrario molti campi e molti menu non possono venir letti. Per quanto riguarda i browser, Opera può essere considerato come uno dei più attenti dal punto di vista della flessibilità. Per quanto sia un po’ fuori standard, sicuramente ha lavorato parecchio sul fronte dell’accessibilità, tra Explorer e Firefox non cambia molto. Molto può dipendere anche dall’adattabilità dello sviluppo dei pacchetti come JAWS ai singoli browser. In questo senso risultano sicuramente facilitati i browser e gli applicativi che maggiormente rappresentano uno standard. Ad esempio per la posta elettronica, lo screen-reader riesce a riconoscere immediatamente il campo del messaggio e lo legge automaticamente lavorando con Outlook Express. Questo non è del tutto vero con altri client di posta, dove invece il contenuto viene riprodotto solo parzialmente, probabilmente per un fatto di classi non riconosciute. Ad ogni modo in rete sono rintracciabili script o patch per questi programmi che permettono a JAWS di interfacciarsi anche con le classi esposte da questi applicativi. L’impegno istituzionale Ho partecipato recentemente ad un incontro organizzato dal MIT 1 che ha convocato le associazioni di categorie al fine di verificare quale sia lo stato di avanzamento dei lavori in fatto di accessibilità. La legge Stanca lascia un buco nel fatto che esiste una clausola che vincola l’adeguamento del sito in relazione alle disponibilità economiche dell’ente, e questo da il modo di evitare il lavoro a chi non vuole far le cose. L’idea, ad ogni modo, è quella di arrivare quanto prima ad avere tutti i siti dei ministeri accessibili. Allo stato attuale delle cose non lo sono. Il rappresentante dell’unione italiana cechi ad esempio lamentava che il sito ministeriale della dichiarazione automatizzata dei redditi non risulta essere ancora accessibile. 1 Ministero per l’Innovazione e le Tecnologie - 392 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR C’è sicuramente anche un problema di intercomunicazioni tra settori, ed anche questo andrebbe risolto. Esistono diversi progetti ministeriali che sono poco coordinati fra di loro. Il gruppo che ha sviluppato il sito della dichiarazione dei redditi non ha probabilmente avuto contatti con il gruppo di sviluppo del CNIPA che invece avrebbe potuto offrire un supporto competente a costo nullo. Non si tratterebbe di fare cose in più, ma semplicemente in modo diverso, cambiando la modalità progettuale. L’obiettivo dell’incontro organizzato dal MIT era quello di creare una commissione che lavorasse stimolando il coinvolgimento delle associazioni delle categorie interessate, con la creazione di una commissione interministeriale al fine di rendere partecipi anche gli altri ministeri e non solo quelli più tecnici. In questo modo si potrebbe evitare che il ministero delle finanze, non ancora coinvolto in questo discorso, non abbia nemmeno una persona implicata nel progetto. La legge Stanca sta prendendo piede, per quanto molto lentamente, proprio per questo fine è stata fondamentale la possibilità data agli enti pubblici di annullare gli appalti che non rispettino i requisiti di accessibilità. In questo modo si hanno poi gli strumenti per poter imporre alla ditta fornitrice la richiesta dell’accessibilità del sito acquistato. Dopo l’approvazione della legge ci si sta muovendo, ma ancora c’è parecchia strada da fare. Adesso si sta cercando di fare in modo che entro il 2010 tutti i ministeri dovrebbero effettivamente avere un sito Web accessibile. Dovrebbe essere l’obiettivo anche per tutti i numerosi enti coinvolti dalla legge: scuole, università, enti a partecipazione pubblica eccetera, ma vista la vasta estensione del campione sembra una cosa piuttosto difficile. Ancora una volta la scappatoia legale è quel vincolo sulle risorse economiche necessarie a cui si appella un dirigente che non voglia impegnarsi. Ad ogni modo una forte sensibilizzazione è stata certamente ottenuta, un primo passaggio c’è stato, e questo lo si vede anche dalle sempre più diffuse dichiarazioni di compatibilità offerte dalle ditte specializzate nelle forniture Web. Da quando è entrata in vigore la legge Stanca qualcosa si è sicuramente messo in moto, sono stati preparati molti siti progettati con maggiore cura. Per lo meno è in atto un tentativo di miglioramento. I siti Web Ci vogliono degli ottimi designer delle pagine Web che sappiano anche ripensare il sito mantenendo comunque una veste grafica interessante. Stanno venendo fuori anche pacchetti CMS con un’attenzione notevole alla accessibilità. Normalmente non vanno male, hanno delle strutture abbastanza definite e quindi si riesce a navigare abbastanza bene nei siti da loro prodotti. Recentemente è stato reso disponibile un pacchetto CMS gratuito mirato all’accessibilità. - 393 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Altro discorso è l’adattamento dei posti di lavoro per l’accessibilità e l’inserimento del disabile nel posto lavorativo. A volte si fa fatica persino a trovare solo un computer disponibile in un inserimento lavorativo. Ci sono sempre più persone non vedenti che, con consuetudine, esplorano il mondo del Web. Ci sono persone non vedenti che sono solite navigare anche per delle ore. Sicuramente l’uso della posta elettronica è più diffuso rispetto all’accesso al Web e il pacchetto utilizzato è Outlook. In questo ambiente, se la mail arriva in formato testo non esiste nessun tipo di problema a leggerla, le difficoltà esistono per le strutture grafiche. Attualmente quasi tutti gli screen-reader cercano di venire incontro ai problemi classici, come ad esempio il fatto di avere una valanga di collegamenti ipertestuali in testa alla pagina. Durante la navigazione con i strumenti di ausilio si ha necessariamente una esplorazione sequenziale. Accedendo ad un sito ci si imbatte immediatamente nella parte di intestazione con tutti i possibili collegamenti e questi devono essere letti tutti in sequenza. Un esempio evidente sono i giornali in linea, la parte che interessa è quella centrale, navigando a vista si ha un orientamento immediato e si può saltare immediatamente alla notizia che interessa. Navigando invece con una barra Braille, accade che ad ogni caricamento della pagina lo screen-reader incomincia ad esplorarla daccapo rileggendo tutto quello che si trovava già nella lettura precedente. Si perde tempo con questo sistema. Le barra Braille o il sistema vocale sono diventati con il tempo sicuramente più efficienti nel trattamento di queste pagine, ma molto tempo viene ancora sprecato in queste letture ripetitive. In particolare le barre Braille hanno aggiunto dei piccoli tasti a lato che permettono di scorrere in avanti, esplorando oltre il documento. Se si incomincia a leggere qualcosa già letto si può saltare all’elemento successivo. Ci sono poi delle funzioni di JAWS che permettono di saltare dei collegamenti. Con un tasto funzione è possibile avere immediatamente l’elenco completo di questi e scorrere rapidamente tra essi. JAWS ha una funzione che ricerca i primi 25 caratteri privi di collegamenti ipertestuali sulla pagina, ripetendo più volte questa funzione si riescono a rintracciare i blocchi di testo che dovrebbero contenere solo le informazioni utili. E’ possibile anche avere elencati i campi editor di un modulo presenti nella pagina e quindi scegliere di entrare al loro interno. Per fortuna qualche sito incomincia ad essere fatto un po’ meglio, grazie al posizionamento opportuno di un collegamento iniziale che rimanda direttamente al contenuto. Questo salto può essere nascosto alla vista con l’utilizzo di una opportuna classe dei CSS. Salti di questo tipo sono fondamentali ed aiutano parecchio nella navigazione. - 394 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Per quanto riguarda i moduli, il problema fondamentale è l’associazione fra l’etichetta ed il campo di testo: non è sempre detto che lo screen-reader sia in grado di legarli correttamente. Il fatto di mettere dentro dei caratteri di testo nei campi per identificarli non risulta di particolare interesse. Sarebbe più immediato fornire un’informativa a parte su quello che si dovrebbe inserire, ad ogni modo ci deve essere una etichetta associata prima. Il lavoro che può fare in certi casi lo screen-reader è quello di verificare la posizione dell’etichetta, mentre in HTML esistono gli elementi opportuni per associare correttamente una etichetta al campo di inserimento. A parte l’attenzione a disporre e collegare gli elementi, nei moduli non ci sono cose che costituiscano un grosso ostacolo. Gli screen-reader normalmente riescono a gestire abbastanza bene questi componenti. Un altro elemento importante sono le descrizioni alternative delle immagini. I problemi più grossi che può incontrare uno screen-reader nell’accesso alle pagine sono tuttora le informazioni ancora vincolate esclusivamente alle immagini senza avere testo corrispondente, come ad esempio un menu progettato solo per via grafica, trattato con delle GIF senza testo alternativo o con testi alternativi non validi. Un po’ per la grande diffusione dei CMS che lo inseriscono automaticamente, un po’ per una maggiore sensibilizzazione, le cose stanno comunque migliorando anche in questo campo. Le difficoltà comuni Il primo problema per una persona disabile che si pone di fronte ad internet è quello della esplorazione della struttura, per quello che stavamo dicendo prima. Il dramma è che l’utente si aspetta di entrare in una pagina internet come se fosse di fronte ad un documento, si aspetta di dare l’indirizzo e di ritrovarsi di fronte direttamente le informazioni richieste in primo piano. Per fare questo dovrebbe in qualche maniera conoscere a priori com’è fatto il sito, che invece diventa un labirinto dove doversi orientare e dove ogni pagina è impostata in un certo modo ed ha una storia a se. Uno standard di presentazione, per quanto non sia possibile in generale, potrebbe per lo meno aiutare all’interno dello stesso sito. I più svantaggiati sono le persone ipovedenti. La persona non vedente, in un certo senso, se ha gli strumenti adeguati tipo la barra Braille ed uno screen-reader se la cava, bene o male, soffre perché l’accesso è macchinoso, ma arriva alle informazioni. L’ipovedente invece spesso non ha un sistema che gli converte in maniera accessibile quello che c’è scritto nel sito e deve comunque leggerlo con gli occhi. Il fatto di avere dei testi che non sono scritti in maniera accessibile complica notevolmente le cose. Gli errori più gravi sono soprattutto i contrasti sbagliati, o il fatto non essere agganciati alla modalità dei caratteri. - 395 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Con un browser è possibile ridimensionare l’aspetto e scegliere di utilizzare un carattere più grande o più piccolo, si possono impostare delle grandezze standard od in percentuale. Da questo punto di vista molti siti permettono in aggiunta di scegliere un foglio di stile personalizzato salvando su un cookies l’impostazione fatta. Ovviamente questa scelta è valida solo per il sito che si sta visitando e va reimpostata, se consentito, di sito in sito. Questo perché ogni autore può definire delle classi differenti nei CSS, utilizzando nomi differenti. Un’opzione di questo tipo è molto utile quando sia già il sito a prevederla, dato che il foglio di stile preferito dall’utente non è universalmente applicabile. In oltre si deve pensare di non avere di fronte sempre persone che siano in grado di lavorare con disinvoltura sui browser, costoro potrebbero non riuscire ad impostare autonomamente con facilità le loro preferenze visive. Spesso questa tipologia di utenti può avere anche delle difficoltà nella comprensione degli stessi contenuti del sito, pensare di fargli fare delle attività ulteriormente complesse per poter leggere le informazioni può scoraggiare la loro navigazione. Occorrono dei fogli di stile mirati ed è meglio se questi vengano messi a disposizione direttamente dal progettista del sito, magari quattro o cinque differenti ma senza esagerare: in certi casi potrebbe essere persino controproducente scendere in ulteriori dettagli di personalizzazione rendendo le cose troppo sofisticate e scoraggiandone l’uso, ad esempio, da parte di una persona anziana. In genere si presentano una serie di testi visualizzati con diverse modalità. La scelta del visitatore è memorizzata in un cookie con il nome del file a cui si fa riferimento. Ogni pagina, quando si apre, legge nel cookie della macchina quale sia il nome del file di stile prescelto e lo preleva dal server. La scelta resta memorizzata fin quando sulla macchina non venga cancellato il cookie relativo. Un problema associato con queste tecniche è quello che possano richiedere a volte l’impiego obbligato dei JavaScript, e questo viene sconsigliato nelle WCAG 1.0 per un motivo di compatibilità con tutti i programmi utente. Questo è vero in linea di massima, ma proprio per evitare che ci sia questa disaffezione nei confronti dei siti accessibili, occorre dare la possibilità di usarli e di avere delle alternative che siano fruibili. L’importante è garantire la presenza di un comportamento alternativo. Progetti futuri Una nuova frontiera è quella dell’accesso tramite telefonia. Ci sono attualmente in commercio delle barre Braille che lavorano con la tecnologia bluetooth. Quando questi strumenti sono nelle vicinanze di un personal computer o di un telefono portatile entrano in funzione. - 396 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR La barra Braille proposta dalla Tiflosystem dispone di 6 tasti per scrivere e può fungere anche per ingresso al computer, in tal caso si parla di tastiera dattilo-Braille. Con 3 dita della mano destra e 3 della sinistra si riescono a simulare i 6 punti del Braille classico con la combinazione delle 6 dita. Sono in vendita anche dei palmari in Braille, utilizzabili con una piccola barra Braille bluetooth separata. I telefoni sono impiegati soprattutto per gli SMS che possono essere inviati in modo relativamente facile, in particolar modo se possiedono dei sistemi operativi come Symbian. Un'altra prospettiva interessante è quella delle aree dei musei. All’avanguardia sono gli studi per le visite guidate, mediante una barra Braille in comunicazione bluetooth. Il visitatore può entrare nella sala dove il suo dispositivo viene agganciato da un client di una rete informativa. A questo punto vengono passate le informazioni come se ci si collegasse con una pagina Web. La tecnologie per queste realizzazioni è già esistente. Ancora più interessanti potrebbero essere dei trasmettitori bluetooth con un hardware che riceve un segnale ed un codice identificativo che permette una localizzazione spaziale. Il dispositivo poi, palmare o cellulare, fornito di un database geografico, può passare l’informazione via sintetizzatore vocale o barra Braille all’utente. Può essere usato in un museo o in un qualsiasi spazio fisico. Un progetto presentato ad Handimatica 2006 prevedeva delle pasticche trasmittenti localizzate nelle aree geografiche ed un ricevitore posizionato ad esempio in un classico bastone per non vedenti collegato ad un palmare con sintesi vocale il quale a sua volta comunica le informazioni via auricolare al non vedente al rilevamento del ricevitore sui segnalatori. Il problema potrebbe essere quello di cablare l’area di interesse. Interessanti sono pure le applicazioni del GPS con mappe localizzate sul cellulare con sintesi vocale. Sono necessari un software di sintesi vocale ed un software di navigazione sul cellulare con mappe di percorsi pedonali e numeri civici registrati. I palmari con barra Braille o dattilo-Braille incominciano anche ad essere diffusi ed usati soprattutto nelle scuole, ragazzi che frequentano l’università possono prendere anche gli appunti delle lezioni. Un apparecchio visto alla fiera Handimatica 2006 di Bologna era costituito da un avanzato sistema di controllo oculare in cui il puntatore del mouse viene controllato con la pupilla. Una prova personale è stata molto coinvolgente. Con una prima impostazione si regola l’apparato alla fisiologia dell’utente, poi si punta un oggetto con la pupilla per qualche secondo. In questo caso la parte fissata viene selezionata ed isolata in una zona a parte dello schermo, a quel punto, riguardando e trattenendo lo sguardo nel punto definito si attiva il click. Ad esempio, navigando sul Web è sufficiente fissare con lo sguardo il collegamento ipertestuale a cui ci si vuole trasferire per qualche istante, quindi questo viene portato sulla destra e riguardando sulla zona estratta viene richiamato il click. - 397 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Allo stesso modo si può lavorare con una tastiera disegnata sullo schermo ed il sistema è piuttosto preciso a seguito di una calibrazione iniziale. Il puntamento è gestito con un controllo contemporaneo di ambedue le pupille ed una ricalibrazione accurata al millisecondo per i movimenti della testa. Costi Questo apparecchio visto in fiera costava 19.000 euro, ma in commercio ne esistono di simili a prezzi molto minori, ovviamente a qualità sostanzialmente inferiore, ad esempio quelli di un puntatore oculare di qualità inferiore sono sui 2.500 euro. In tal caso però la testa dell’utente deve rimanere immobile, non ci devono essere spasmi involontari. I costi delle apparecchiature in generale si sono abbastanza abbassati, si parte dai 2.500 fino a 5.000 euro per un display Braille con tastiera bluetooth. Di questi circa 2.500 vengono passati dal servizio sanitario nazionale. Quelli di base in pratica vengono dati gratuitamente, questo è un diritto dell’assistito che deve solamente dimostrare di essere un non vedente. Gli apparecchi in questione vengono considerati normalmente come protesi. Quello che manca è la cultura, anche questo è un aspetto della riunione tenutasi con il ministero: rispetto all’accessibilità il problema più grosso è la tecnologia assistiva. Circa l’80% degli strumenti facilitatori che permettono l’accessibilità sono fuori dal nomenclatore. Il nomenclatore è un elenco delle apparecchiature e delle protesi che possono essere fornite ai disabili dalle ASL (Azienda Sanitaria Locale). Ad esempio fanno parte di questa lista: la barra Braille, il software ingrandente, la sintesi vocale. Software come JAWS non rientra, rientra la sintesi vocale ma screen-reader invece come voce specifica non è contemplata. In tal caso c’è un minimo che è passato come sintesi vocale. Uno screen-reader può costare più di 1.400 euro, a seconda del sistema operativo per cui è stato progettato, di questi solo 500 circa sono passati come sintesi vocale. Senza contare che se poi si è interessati ad uno strumento a parte di sintesi vocale, non si è più rimborsati giacché la cifra è stata già impiegata per fornire, anche solo parzialmente, lo screen-reader. Il nomenclatore è stato cambiato qualche anno fa, in precedenza c’erano i singoli codici con gli importi fissi, adesso è la ASL a valorizzare il bene e a riconoscere il valore dell’ausilio. Alcune ASL hanno fatto delle gare generiche con le ditte per i vari tipi di strumenti, acquistando sempre dallo stesso fornitore, tuttavia i modelli in commercio di una singola tipologia di ausilio, come ad esempio gli ingranditori, possono essere molto differenti. In genere viene riconosciuto un rimborso fisso pagato dall’ASL a cui si deve aggiungere una quota variabile a carico del disabile che può scegliere l’ausilio più adatto alla propria menomazione. - 398 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Questi apparecchi sono dati in comodato d’uso, il problema potrebbe sorgere quando il disabile aggiunge una cifra personale. Ma normalmente non è mai successo che l’ausilio sia stato richiesto indietro dall’ASL. Va comunque considerato che alcune tecnologie possano essere riutilizzate quando non sono più di aiuto all’utilizzatore. Un esempio sono gli strumenti a puntamento oculare di cui si è parlato alla fiera di Bologna. Gli strumenti avanzati Per le persone che hanno problemi motori, la difficoltà di navigazione è relativa, una volta trovato lo strumento giusto e la tecnologia assistiva adatta alla propria disabilità. In genere un disabile motorio riesce ad usare il movimento della testa con un sistema di puntamento realizzato con delle cuffiette con dei sensori sulla fronte che vengono rilevati da un trasmettitore sullo schermo in modo di definire la distanza ed il movimento. Il click lo si può fare con un soffio. Questi sono strumenti abbastanza costosi, una nuova tecnologia utilizza una Web-Cam che rileva un’immagine di base la quale viene processata per rilevare gli spostamenti, ad esempio tracciando i movimenti di un bollino fluorescente posto come punto luminoso sulla fronte dell’utilizzatore. In questo caso siamo sui 400 euro, una tecnologia abbordabile. Con questi strumenti si riesce ad avere il movimento del mouse, e si può accedere anche ad una tastiera virtuale sullo schermo. Il discorso del click lo si può ottenere con il soffio ed è spesso la cosa migliore riuscendo anche a simulare il trascinamento in maniera efficace. Questi strumenti assistivi avanzati permettono di gestire il computer. Dal punto di vista del progettista di siti Web non c’è un gran che da fare in più. Una delle cose importanti è la gestione dello spazio sullo schermo, poiché l’occupazione dell’area visibile con una tastiera virtuale può portare via molto spazio visivo. In questo caso una buona progettazione della pagina ridimensionabile può aiutare nella fruibilità dell’applicazione. Chi non riesce ad avere un movimento gestibile per una spasticità molto grave può avere a disposizione della applicazioni che lavorano a scansione. Ci sono dei sistemi organizzati in righe e colonne, con lettere disposte su file differenti. In momenti successivi vengono evidenziate in sequenza le differenti righe, ognuna per un tempo fisso. Agendo su un sensore che può essere un pulsante sullo zigomo o una palla che si può colpire con un movimento, si fissa l’attenzione su quella riga. Una seconda scansione temporale scorre le lettere della riga selezionata. Con due movimenti si riesce a scegliere la lettera. Un sistema lungo ma funzionale. Esistono anche dei joystick accuratamente regolabili per avere dei movimenti inerziali o bloccati su un singolo asse. Altre cose molto utili possono essere le impostazioni fornite da - 399 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Windows nel pannello di controllo per l’accessibilità, sono strumenti che spesso la gente ignora ma risultano utili in alcuni casi, e sono immediatamente disponibili con il sistema operativo. Tra gli altri sono impostabili il ritardo della battitura e le opzioni per i tasti premuti contemporaneamente. Tastiere espanse e facilitate possono essere utilmente affiancate da questi filtri di ingresso. Per quanto riguarda i sistemi operativi, su Linux esistono dei progetti e ci sono delle soluzioni poco conosciute e poco utilizzate soprattutto perché sono poche le persone disabili che si avvicinano a questo sistema operativo. Il mondo dell’accessibilità si rivolge essenzialmente a Windows. I sistemi di ausilio in genere hanno le loro interfacce hardware e possono connettersi con qualunque sistema operativo ad ogni modo non sono al corrente di uno screen-reader per MacIntosh, Windows rimane il punto di riferimento. Sarebbe sicuramente un fatto positivo se Microsoft fosse abbastanza attenta da comprare la Freedom Scientific ed integrare le risorse nel sistema operativo. Non si vede il motivo per cui un non vedente deve spendere tutta quella cifra per accedere al sistema. Ad ogni modo la comunità dei disabili è abbastanza motivata e le persone non si fermano davanti alla spesa, normalmente sono molto attente alle tecnologie. Ad esempio ad Handimatica 2006 c’erano moltissimi non vedenti tutti attentissimi alla tecnologia innovativa, al punto che la maggior parte dei visitatori erano disabili. In Italia La legislazione che abbiamo è valida, rispettare le norme definite andrebbe benissimo, anche al livello europeo siamo all’avanguardia. Non ha molto senso rimettere in discussione le procedure di legge, la parte in cui probabilmente siamo indietro è quella della corretta distribuzione e quella della produzione di apparecchiature assistive. La mostra Handimatica di Bologna è un po’ un centro da questo punto di vista, è l’evento culmine, visto che in Italia c’è solo questo incontro per le tecnologie assistive. La globalizzazione, ad ogni modo, ha sortito i suoi effetti positivi anche in questo campo. Tutto quello che c’è sul mercato internazionale è facilmente reperibile, tuttavia in Italia come produttori di ausili non ci sono grosse realtà. Barre Braille ed altri strumenti assistivi sono prodotti tutti all’estero, Germania, America, Spagna. All’estero ci sono spesso dei grossi contributi, meno in termini monetari e più in termini di servizi che vengono direttamente forniti all’utenza. L’intervento è mirato sulla persona e quindi il mercato è più fecondo. In Italia c’è una ditta di Bologna che ha iniziato a fare qualche timido progetto di ausilio tipo tastiere ed interfacce per sensori. Ci aveva provato per una barra Braille la Tiflosystem di Padova, una ditta tra le prime ad interessarsi alla distribuzione qui da noi degli strumenti assistivi. - 400 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Pur lamentando una certa mancanza di produttori, tuttavia ci sono comunque le ditte specializzate per sviluppo di software, formazione ed assistenza. Vale la pena ricordare anche il sito del SIVA 1 per informazione e consulenza nel campo delle tecnologie di ausilio alla riabilitazione, che ha a disposizione una banca dati degli strumenti a disposizione per l’accessibilità. Vale la pena fare un accenno anche all’assistenza fornita al disabile per la ricerca e la identificazione della migliore apparecchiatura assistiva per la propria menomazione. Spesso è anche molto difficile recuperare quello che è più indicato. Non è una cosa così semplice valutare lo strumento adatto, quale ausilio potrebbe essere il più efficace ed il più facilmente utilizzabile. Ci sono delle strutture, dei centri di valutazione che permettono questo tipo d’analisi. A Bologna esiste Ausilioteca2, qui lavora una equipe multi-disciplinare per l’assistenza agli utenti. Ma centri di questo tipo ne esistono anche altri, all’interno delle strutture ospedaliere e delle regioni. Una guida di questo tipo è fondamentale per il disabile, il rischio concreto è che si spendano tanti soldi per avere uno strumento inutile per l’impossibilità di sfruttare la risorsa fornita. Non sono mai o quasi mai sistemi chiavi in mano. Queste tecnologie richiedono una valutazione accurata prima e molto spesso anche un sufficiente periodo di addestramento e di taratura in opera, sfruttando anche l’opzione del collaudo che permette di restituire lo strumento entro un tempo ragionevole nel caso non risulti idoneo. 1 2 Servizio Informazioni e Valutazione Ausili: [http://www.siva.it/retesiva/default.htm] [http://www.ausilioteca.org/] - 401 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR VI. Un esempio reale L’idea originaria di questa sezione era di portare delle esemplificazioni pratiche del concetto di accessibilità, mutuandole dalla personale esperienza lavorativa. Il mio attuale incarico professionale, infatti, è quello di lavorare all’ufficio informatico del Comune di Novate Milanese, una piccola città di circa 20.000 abitanti alla periferia di Milano. Un primo progetto era partito con i responsabili del settore per la messa a norma del sito comunale a seguito della legge Stanca. Un duplice interesse ci muoveva verso questa soluzione, da una parte l’esigenza di regolare il proprio sito istituzionale spendendo il meno possibile, dall’altra il desiderio di dare una svolta pratica a quanto appreso in questa tesi. Nonostante questa duplice finalità, il progetto tuttavia non è andato a buon fine, a testimoniare la scarsa o scarsissima attenzione per la questione accessibilità da parte di molte delle amministrazioni comunali. Infatti, visto che non sembrano esserci particolari rischi o controindicazioni di sorta, il responsabile di area ha deciso di soprassedere completamente alla questione decidendo di destinare anche quelle poche risorse economiche preventivate per altri fini. A tutt’oggi il sito del Comune di Novate Milanese ha completamente disatteso la legge Stanca ed è ampiamente fuori norma. Tuttavia l’idea di dare un’esemplificazione concreta alla numerosa mole d’informazioni raccolta in questo lavoro mi è sembrata sufficientemente pressante da decidere di dedicare comunque una sezione della tesi ad un esempio concreto di codice accessibile. A tal fine, in accordo con il relatore, abbiamo deciso di sfruttare una presentazione sintetica del lavoro che originariamente doveva essere redatta in PowerPoint, e di produrla invece con delle pagine XHTML accessibili. VI.1 - Presentazione in XHTML Vista la relativa semplicità e schematizzazione del contenuto da esporre, la scelta del linguaggio è caduta sul più rigoroso degli HTML, l’XHTML 1.1, in attesa che venga presentata la documentazione ufficiale del XHTML 2.0. La maggior cura possibile è stata presa per produrre delle pagine di qualità. Ad ogni modo, essendo la prima scrittura di codice accessibile, sicuramente esso conterrà imperfezioni e scorrettezze. Anche per questo ho deciso non accludere alla pagina alcuna dichiarazione di compatibilità con le WCAG o con la legge Stanca. Non certo perché non sia di mia intenzione ambirvi, quanto piuttosto perché l’accessibilità, come più volte ripetuto nel lavoro, è una metodologia di lavoro ed una qualità a cui mirare piuttosto che un bollino da far comparire in fondo alla pagina. - 402 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Progetto Il documento si articola su 5 pagine HXTML:  Index: una pagina introduttiva di presentazione del lavoro;  Scenario: corrisponde alla sintesi dell’omonimo capitolo di questo testo;  Metodologie: racchiude le metodologie generali esposte;  Tecniche: presenta le tecniche fondamentali consigliate;  Normative: espone in maniera sintetica le quattro normative ed una tabella sinottica. Sono presenti poi 3 fogli di stile, il primo dei quali funge da configurazione base ed è incluso e modificato dagli altri due:  Base: contiene le impostazioni di base, è incluso negli altri e si avvale delle configurazioni di sistema per rendere la presentazione;  Presentazione: apporta delle modifiche al foglio base in modo da realizzare per quanto possibile una presentazione più gradevole;  Contrasto: apporta delle modifiche al foglio base per realizzare una visualizzazione a caratteri ingranditi ed alto contrasto in modo da venire incontro alle esigenze degli ipovedenti. La versione del progetto riportata è quella prodotta fino alla metà del Febbraio 2007. Attualmente è pubblicata e consultabile sotto il sito del Comune di Novate Milanese1, ma è molto probabile che nei prossimi mesi venga trasferita o rimossa. Codice XHTML Di seguito riporto, a titolo esemplificativo, una delle pagine. Ho scelto un compromesso tra quella che avesse un codice relativamente breve da poter essere riportato mantenendo comunque una sufficiente significatività. Sono state fatte alcune modifiche al testo per poterlo impaginare al meglio in questo documento. Scenario Vediamo alcune caratteristiche di base che sono state implementate per raggiungere la migliore accessibilità possibile: 1 [http://www.comune.novate-milanese.mi.it/test/acs/tesi/] - 403 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Dichiarazione di grammatica formale: Viene usata per garantire la conformità agli standard del W3C, è stato scelto il linguaggio XHMTL 1.1;  Definizione del linguaggio naturale: Lingua italiana, permette indicizzazioni e letture corrette degli screen-reader;  Uso di fogli di stile multipli: Uno principale e gli altri secondari. Consente di far scegliere l’aspetto di impaginazione più consono all’utente. In questo codice ci si basa sulla capacità del browser per poterli attivare come richiamato nelle UAAG.  Definizione delle relazioni fra i documenti: Permette una migliore indicizzazione automatica delle pagine per i browser e i robot sul Web;  Impaginazione senza tabelle: Non è strettamente necessaria, ma l’uso del DIV può consentire una migliore flessibilità e pulizia. In effetti, proprio grazie a questa metodologia, il foglio di stile ad elevato contrasto ridefinisce la presentazione formattandola a colonna unica. Le tabelle, quando sono state usate in uno dei 5 documenti, sono corredate dei necessari attributi SUMMARY e TITLE, in oltre sono dotate degli attributi che consentono le definizioni delle relazioni fra le celle di intestazione e quelle di semplice contenuto;  Aspetti di impaginazione rimossi dal documento XHTML a favore dell’uso dei fogli di stile ad eccezione della definizione in pixel delle dimensione delle immagini presenti. Questa tecnica è consigliata ed applicata dallo stesso W3C in quanto sveltisce l’elaborazione della pagina e la gestione dell’immagine all’interno del browser;  Uso degli elementi gerarchici di intestazione H1..H6;  Utilizzo degli elementi presentazionali e strutturali per definire la corretta gerarchia del contenuto e la semantica delle relazioni fra le parti;  Posizionamento del menu di guida della pagina come prima informazione facilmente scavalcabile con dei collegamenti ipertestuali diretti al contenuto informativo e al menu generale;  Impiego degli ACCESSKEY;  Impiego di segnalazioni di fine lista non visibili con un browser testuale in modo da offrire meccanismi di orientamento alla navigazione dei menu per gli screen-reader;  Utilizzo di acronimi ed abbreviazioni;  Impiego di liste di navigazioni a menu orizzontale per i livelli interni di informazione: Serve per garantire il miglior ausilio alla navigazione possibile per tutti i browser non visuali;  Impiego dell’attributo TITLE per tutti i collegamenti interni ed esterni: Garantisce all’utente il più completo contenuto informativo possibile in modo da - 404 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR permettergli di valutare l’interesse del collegamento e di non spiazzarlo nei cambi di contesto;  Utilizzo degli elementi BLOCKQUOTE, CITE e Q per definire il contenuto citato da altre fonti. Questi marcatori non sono utilizzati a fini di impaginazione;  Segnalazione dei cambi di lingua nel documento, per permettere agli screen-reader la corretta lettura del testo;  Aggiunta dei collegamenti ipertestuali ai validatori del W3C, per la validazione automatica delle pagine. Normative, Metodologie e tecniche per l'accessibilità: Scenario
Normative, metodologie e tecniche progettuali per la realizzazione di siti Web ad elevata accessibilità

II. Scenario

Sommario
- 405 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR

[0]  Pagine Web

[1]  Accessibilità

[2]  Usabilità

[3]  Disabilità

[4]  W3C (Fine Sommario Capitolo)

Pagine Web

Presentazione;

Scenario

Metodologie di base

Tecniche specifiche

Normative (Fine Sommario Generale)

Accessibilità

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
(Tim BernersLee)

Successivo

Ultimo

Sommario

Definizione di accessibilità della legge Stanca: La capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari.

Applicare l'accessibilità ai siti Web:

Obiettivo: garantire la più ampia base possibile di accesso per:

Utenti affetti da disabilità;

Utenti dotati di strumenti (user agent) specifici od obsoleti;

- 406 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR

Metodo: rendere il sito accessibile alla tecnologia usata dagli utenti per renderlo accessibile agli utenti. (Jim Byrne);

Tecniche: rispetto dei lunguaggi standard W3C e delle regole del buon sviluppo contrapposte al sistema tradizionale di progettazione.

Usabilità

Successivo

Precedente

Primo

Ultimo

Sommario

Definizione ISO 9241: Grado in cui un prodotto può essere usato da particolari utenti per raggiungere certi obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto d'uso.

Collegamenti con l'accessibilità:

L'interazione e sovrapposizione con l'accessibilità à molto stretta, soprattutto per le ultime tre raccomandazioni WCAG;

Ci sono differenze nelle metodologie di realizzazione e di controllo (test con gli utenti vs. validatori automatici);

Le due discipline possono essere integrate al servizio della fruibilità (Luca Mascaro: fruibilità = usabilità applicata sulla accessibilità).

Disabilità

Successivo

Precedente

Primo

Ultimo

Sommario

L'Organizzazione Mondiale della sanità, nel documento WHO ICDH-1 del 1980, ha definito:

Menomazione
perdita o anomalia a carico di una struttura corporea

Disablità
perdita della capacità di compiere attività nel modo normale

Handicap
condizione di svantaggio conseguente a menomazione o a disabilità
- 407 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR

Le disabilità si possono suddividere in:

sensoriali;

visive;

uditive; (Fine lista sensoriali)

motorie;

cognitive.

Le tecnologie di ausilio assistono queste disabilità nell'accesso al Web con barre Braille, lettori di schermo, ingranditori eccetera.

W3C: World Wide Web Consortium

Lead the Web to its full potential.
(W3C)

Precedente

Primo

Sommario

E' un consorzio internazionale, neutrale rispetto ai venditori, che, grazie al contributo dei suoi membri, guida l'evoluzione del Web, definendo protocolli comuni.
Per l'accessibilità è stato istituito il gruppo WAI: Web Accessibile Initiative.

Attività del W3C - WAI:

WCAG - Web Content Accessibility Guidelines:
Spiegano agli autori come creare pagine Web accessibili;

UAAG - User Agent Accessibility Guidelines:
Spiegano come rendere i programmi utente (user agent) accessibili per le persone disabili;

ATAG - Authoring Tool Accessibility Guidelines:
Spiegano come rendere accessibili gli stessi strumenti di sviluppo in modo che possano essere utilizzati dalle persone disabili e come possano essere progettati per creare contenuti accessibili;

ARIA - Accessibile Rich Internet Applications:
Spiegano agli sviluppatori come rendere maggiormente accessibile il Web dinamico.

Metodologia normativa del W3C:

Working Draft
Documento reso noto per essere valutato dalla comunità;

Last Call Working Draft
Documento che si ritiene abbia avuto un consenso sufficiente;
- 408 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Candidate Recommendation
Un periodo durante il quale la specifica viene revisionata ed implementata sul campo;

Proposed Recommendation
Documento proposto per divenire una raccomandazione ufficiale una volta ottenute sufficienti implementazioni;

Recommendation
Raccomandazione ufficiale del W3C

Durante suo percorso di sviluppo un documento può ritornare ad una fase precedente per eventuali revisioni.

Precedente

Primo

Sommario

Angelo Moreschi
Revisione 0.1 - Febbraio 2007

Codice CSS Il codice dei CSS è suddiviso tra un foglio di stile di base che contiene le impostazioni fondamentali ed i colori di sistema, e dei fogli aggiuntivi specifici che permettono di presentare la pagina a seconda delle esigenze dell’utente. Come illustrato in precedenza nel codice non è stato incluso lo script per cambiare i fogli di stile. Come da raccomandazioni UAAG, questo dovrebbe essere incluso nei browser, come in effetti accade, ad esempio in Firefox e Opera. Come nel caso del codice XHTML sono stati fatti gli opportuni adattamenti di impaginazione per consentire la migliore leggibilità in queste pagine. Gli accorgimenti principali che sono stati presi per rendere una migliore accessibilità con i fogli di stile sono: - 409 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Impiego di fogli di stile esterni comuni per tutti i 5 documenti della presentazione;  Definizione di fogli di stile alternativi selezionabili dall’utente;  Impiego dei caratteri e dei colori di sistema nel foglio di stile base per adattare automaticamente la presentazione nel browser alle impostazioni di sistema preferite dall’utente. Queste scelte sono state poi soprascritte per i fogli di stile di presentazione ed a contrasto elevato;  Definizione di un foglio di stile per ipovedenti che: o Impagina il documento a colonna singola; o Definisce colori ad elevato contrasto al fine di aumentare la leggibilità; o Ingrandisce la dimensione del font di caratteri;  Scelta di font leggibili e, con motivate eccezioni, senza grazie;  Uso delle dimensioni relative per l’impaginazione (percentuali) e per i caratteri (em);  Impaginazione fluida e ridimensionabile, in modo da adattarsi alla larghezza degli schermi e delle pagine;  Definizione di uno stile nascosto per contenere le informazioni che non devono essere mostrate dai programmi utente grafici;  Definizione di uno stile per i menu di navigazione orizzontali implementati tramite liste non ordinate. CSS Base /* Normative, metodologie e tecniche progettuali per la realizzazione di siti Web ad elevata accessibilità */ /* Foglio di stile base */ /* ****** link ******** */ a:active, a:hover, a:focus {font-weight: bold;} /* ****************** elementi XHTML *************** */ pre {font-family: monospace;} html, body {background-color: AppWorkspace;} p {background-color: transparent; } blockquote p {text-align: right;} q {font-style: italic;} dl {border: thin solid WindowFrame; padding: 1em; margin-top: 0em;} /* ****************** classi base *************** */ /* intestazione di pagina */ .intestazione {color: CaptionText; background-color: ActiveCaption; clear: both;} /* corpo */ .corpo {padding-top: 0.1em; clear: both;} - 410 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR /* piede della pagina */ .piepagina {color: InfoText; background-color: InfoBackground; font-size: smaller; clear: both; text-align: center; padding: 0.2em;} /* ****************** liste di navigazione *************** */ /* Guida principale */ .guida {float: left; clear: left; width: 28%; margin-right: 1%;} .navOriz {color: InfoText; background-color: InfoBackground; } .navOriz ul {list-style: none; border-bottom: 1px dashed; border-top: 1px dashed; border-color: ButtonShadow; } .navOriz ul li {margin-right: 1em; text-align: center; display: inline;} .navOriz a {text-decoration: none;} .finelista {display: none;} #sCapitolo, #sWeb {color: InfoText; background-color: InfoBackground; marginbottom: 1em; padding: 1em;} #sCapitolo ul li {list-style-type: none;} #sCapitolo a {text-decoration: none;} /* ****************** corpo *************** */ /* elemento nascosto */ .nascosto {display: none; visibility: hidden; overflow: hidden;} /* contenuto informativo */ .contenuto {float: right; clear: right; width: 70%; background-color: transparent;} /* titolo della pagina */ .titoloSezione {color: InfoText; background-color: InfoBackground; float: none; text-align: left; clear: both;} /* slides */ .scheda {color: ButtonText; background-color: ButtonFace; margin-bottom: 1em; padding: 1em;} /* evidenziazioni */ .risalto {border: thin solid WindowFrame; margin-left: 2%; margin-right: 2%; padding: 0.5em;} .x-risalto {border: thin dashed WindowFrame; margin-left: 5%; margin-right: 5%; padding: 1em;} .xx-risalto {font-size: 1.25em; border: thin dotted WindowFrame; margin-left: 10%; margin-right: 10%; padding: 1em;} .illustrazioni {text-align: center;} .tblComparazione {padding-top: 1em; padding-left: 0.1em;} .testariga {text-align: left;} /* ****************** id comuni *************** */ #stemma {float: left; margin-right: 1em; vertical-align: top;} #testoTitolo {font-size: 2em; vertical-align: super;} /* ****************** id specifici *************** */ #titoloTesi {text-align: center; font-size: 2em;} #autoreTesi {text-align: right; margin-bottom: 3em;} - 411 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR CSS Presentazione /* Normative, metodologie e tecniche progettuali per la realizzazione di siti Web ad elevata accessibilità */ /* Foglio di stile correttivo per presentazione */ /* importazione delle specifiche del foglio base */ @import "base.css"; /* ****** link ******** */ a:link {color: navy;} a:visited {color: purple;} a:active, a:hover, a:focus {color:blue;} /* ****************** elementi XHTML *************** */ h1, h2, h3, h4, h5, h6 {font-family: Verdana, Geneva, Arial, Helvetica, sansserif;} html, body {background-color: navy; font-size: 1em; font-family: "Trebuchet ms", Verdana, sans-serif;} blockquote p {font-family: monospace;} hr {color: yellow; background-color: yellow; height: 1px;} dl {border-color: navy;} /* ****************** classi base *************** */ .intestazione {color: yellow; background-color: transparent;} .piepagina {color: white; background-color: transparent; font-family: Georgia, Garamond, "Times New Roman", Times, serif;} /* ****************** liste di navigazione *************** */ .navOriz {color: black; background-color: silver; font-family: "Gill sans mt", "Gill sans", "Trebuchet ms", sans-serif;} .navOriz ul {border-color: purple;} #sCapitolo, #sWeb {color: navy; background-color: silver; font-family: "Gill Sans MT", "Gill sans", "Trebuchet ms", sans-serif;} /* ****************** corpo *************** */ /* slides */ .scheda {color: black; background-color: silver;} /* titolo della pagina */ .titoloSezione {color: white; background-color: transparent;} .risalto, .x-risalto, .xx-risalto {color: navy; background-color: transparent; border-color: black; font-family: Georgia, "Times New Roman", Times, serif;} .tblComparazione {font-family: monospace;} /* ****************** id specifici *************** */ #titoloTesi { color: navy; background-color: transparent;} - 412 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR CSS Contrasto /* Normative, metodologie e tecniche progettuali per la realizzazione di siti Web ad elevata accessibilità */ /* Foglio di stile correttivo per alto contrasto */ /* importazione delle specifiche del foglio base */ @import "base.css"; /* ****** link ******** */ a:link {color: white;} a:visited {color: silver;} a:active, a:hover, a:focus {color:yellow;} /* ****************** elementi XHTML *************** */ h1, h2, h3, h4, h5, h6 {font-family: Verdana, Geneva, Arial, Helvetica, sansserif;} html, body {color: black; background-color: white; font-family: "Trebuchet ms", Verdana, sans-serif; font-size: 1.2em;} blockquote p {font-family: monospace;} hr {color: navy; background-color: navy; height: 2px;} dl {border-color: yellow;} /* ****************** classi base *************** */ .intestazione {color: navy; background-color: transparent;} .piepagina {color: black; background-color: transparent; font-family: Georgia, Garamond, "Times New Roman", Times, serif;} /*monocolonna*/ .guida, .contenuto {float: none; width: 98%; margin: 0px; padding: 1%;} /* ****************** liste di navigazione *************** */ .navOriz {color: silver; background-color: black; font-family: "Gill sans mt", "Gill sans", "Trebuchet ms", sans-serif;} .navOriz ul {border-color: yellow;} #sCapitolo, #sWeb {color: white; background-color: navy; font-family: "Gill Sans MT", "Gill sans", "Trebuchet ms", sans-serif;} /* ****************** corpo *************** */ /* slides */ .scheda {color: white; background-color: black;} /* titolo della pagina */ .titoloSezione {color: black; background-color: transparent;} .risalto, .x-risalto, .xx-risalto {color: yellow; background-color: transparent; border-color: white; font-family: Georgia, "Times New Roman", Times, serif;} .tblComparazione {font-family: monospace;} /* ****************** id specifici *************** */ #titoloTesi {color: yellow; background-color: transparent;} - 413 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR VII. Appendice – Riferimenti alle normative Per immediata consultazione e raffronto con quanto esposto in precedenza, in questa appendice riporto gli stralci essenziali delle quattro maggiori normative citate. Si è preferito allegare il testo originale, anche nel caso in cui la pubblicazione sia in lingua inglese. Questo contravviene parzialmente alle regole dell’accessibilità, ma (fatta eccezione per le Section 508) confido nella facile reperibilità su internet degli equivalenti in italiano per coloro che ne avessero bisogno. Per queste esigenze suggerisco di accedere direttamente alla sezione italiana del sito W3C1. Per le WCAG 2.0 allego l’ultimo documento disponibile al momento di consegnare questa tesi. Per ovvi motivi di spazio delle normative citate vengono riportati solamente le sezioni essenziali, per il testo integrale consiglio i seguenti siti:  WCAG 1.0: http://www.w3.org/TR/WCAG10/;  Section 508: http://www.access-board.gov/508.htm;  Legge 04/2004: http://www.pubbliaccesso.gov.it/;  WCAG 2.0: http://www.w3.org/TR/WCAG20/. VII.1 - WCAG 1.0 Web Content Accessibility Guidelines 1.0 W3C Recommendation 5-May-1999 […] Abstract These guidelines explain how to make Web content accessible to people with disabilities. The guidelines are intended for all Web content developers (page authors and site designers) and for developers of authoring tools. The primary goal of these guidelines is to promote accessibility. However, following them will also make Web content more available to all users, whatever user agent they are using (e.g.,desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment, etc.). Following these guidelines will also help people find information on the Web more quickly. These guidelines do not discourage content developers from using images, video, etc., but rather explain how to make multimedia content more accessible to a wide audience. 1 [http://www.w3c.it] - 414 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR […] Table of Contents Abstract Status of this document 1. Introduction 2. Themes of Accessible Design 2.1 Ensuring Graceful Transformation 2.2 Making Content Understandable and Navigable 3. How the Guidelines are Organized 3.1 Document conventions 4. Priorities 5. Conformance 6. Web Content Accessibility Guidelines 1. Provide equivalent alternatives to auditory and visual content. 2. Don't rely on color alone. 3. Use markup and style sheets and do so properly. 4. Clarify natural language usage 5. Create tables that transform gracefully. 6. Ensure that pages featuring new technologies transform gracefully. 7. Ensure user control of time-sensitive content changes. 8. Ensure direct accessibility of embedded user interfaces. 9. Design for device-independence. 10. Use interim solutions. 11. Use W3C technologies and guidelines. 12. Provide context and orientation information. 13. Provide clear navigation mechanisms. 14. Ensure that documents are clear and simple. Appendix A. -- Validation Appendix B. -- Glossary Acknowledgments References The appendix list of checkpoints is available as either a tabular summary of checkpoints or as a simple list of checkpoints. Introduction For those unfamiliar with accessibility issues pertaining to Web page design, consider that many users may be operating in contexts very different from your own:  They may not be able to see, hear, move, or may not be able to process some types of information easily or at all.  They may have difficulty reading or comprehending text.  They may not have or be able to use a keyboard or mouse.  They may have a text-only screen, a small screen, or a slow  They may not speak or understand fluently the language in which the document is written.  They may be in a situation where their eyes, ears, or hands are busy or interfered Internet connection. with (e.g., driving to work, working in a loud environment, etc.). - 415 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  They may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system. Content developers must consider these different situations during page design. While there are several situations to consider, each accessible design choice generally benefits several disability groups at once and the Web community as a whole. For example, by using style sheets to control font styles and eliminating the FONT element, HTML authors will have more control over their pages, make those pages more accessible to people with low vision, and by sharing the style sheets,will often shorten page download times for all users. The guidelines discuss accessibility issues and provide accessible design solutions. They address typical scenarios (similar to the font style example) that may pose problems for users with certain disabilities. For example, the first guideline explains how content developers can make images accessible. Some users may not be able to see images, others may use text-based browsers that do not support images, while others may have turned off support for images (e.g., due to a slow Internet connection). The guidelines do not suggest avoiding images as a way to improve accessibility. Instead, they explain that providing a text equivalent of the image will make it accessible. How does a text equivalent make the image accessible? Both words in "text equivalent" are important:  Text content can be presented to the user as synthesized speech, Braille, and visually-displayed text. Each of these three mechanisms uses a different sense -ears for synthesized speech, tactile for Braille, and eyes for visually-displayed text -- making the information accessible to groups representing a variety of sensory and other disabilities.  In order to be useful, the text must convey the same function or purpose as the image. For example, consider a text equivalent for a photographic image of the Earth as seen from outer space. If the purpose of the image is mostly that of decoration, then the text "Photograph of the Earth as seen from outer space" might fulfill the necessary function. If the purpose of the photograph is to illustrate specific information about world geography, then the text equivalent should convey that information. If the photograph has been designed to tell the user to select the image (e.g., by clicking on it) for information about the earth, equivalent text would be "Information about the Earth". Thus, if the text conveys the same function or purpose for the user with a disability as the image does for other users, then it can be considered a text equivalent. Note that, in addition to benefitting users with disabilities, text equivalents can help all users find pages more quickly, since search robots can use the text when indexing the pages. While Web content developers must provide text equivalents for images and other multimedia content, it is the responsibility of user agents (e.g., browsers and assistive technologies such as screen-readers, Braille displays, etc.) to present the information to the user. Non-text equivalents of text (e.g., icons, pre-recorded speech, or a video of a person translating the text into sign language) can make documents accessible - 416 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR to people who may have difficulty accessing written text, including many individuals with cognitive disabilities, learning disabilities, and deafness. Non-text equivalents of text can also be helpful to non-readers. An auditory description is an example of a non-text equivalent of visual information. An auditory description of a multimedia presentation's visual track benefits people who cannot see the visual information. Themes of Accessible Design The guidelines address two general themes: ensuring graceful transformation, and making content understandable and navigable. Ensuring Graceful Transformation By following these guidelines, content developers can create pages that transform gracefully. Pages that transform gracefully remain accessible despite any of the constraints described in the introduction, including physical, sensory, and cognitive disabilities, work constraints, and technological barriers. Here are some keys to designing pages that transform gracefully:  Separate structure from presentation (refer to the difference between content, structure, and presentation).  Provide text (including text equivalents). Text can be rendered in ways that are available to almost all browsing devices and accessible to almost all users.  Create documents that work even if the user cannot see and/or hear. Provide information that serves the same purpose or function as audio or video in ways suited to alternate sensory channels as well. This does not mean creating a prerecorded audio version of an entire site to make it accessible to users who are blind. Users who are blind can use screen-reader technology to render all text information in a page.  Create documents that do not rely on one type of hardware. Pages should be usable by people without mice, with small screens, low resolution screens, black and white screens, no screens, with only voice or text output, etc. The theme of graceful transformation is addressed primarily by guidelines 1 to 11. Making Content Understandable and Navigable Content developers should make content understandable and navigable. This includes not only making the language clear and simple, but also providing understandable mechanisms for navigating within and between pages. Providing navigation tools and orientation information in pages will maximize accessibility and usability. Not all users can make use of visual clues such as image maps, proportional scroll bars, side-by-side frames, or graphics that guide sighted users of graphical desktop browsers. Users also lose contextual information when they can only view a portion of a page, either because they are accessing the page one word at a time (speech synthesis or Braille display), or one section at a time (small display, or a magnified display). Without orientation information, users may not be able to understand very large tables, lists, menus, etc. The theme of making content understandable and navigable is addressed primarily in guidelines 12 to 14. - 417 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR How the Guidelines are Organized This document includes fourteen guidelines, or general principles of accessible design. Each guideline includes:  The guideline number.  The statement of the guideline.  Guideline navigation links. Three links allow navigation to the next guideline (right arrow icon), the previous guideline (left arrow icon), or the current guideline's position in the table of contents (up arrow icon).  The rationale behind the guideline and some groups of users who benefit from it.  A list of checkpoint definitions. The checkpoint definitions in each guideline explain how the guideline applies in typical content development scenarios. Each checkpoint definition includes:  The checkpoint number.  The statement of the checkpoint.  The priority of the checkpoint. Priority 1 checkpoints are highlighted through the use of style sheets.  Optional informative notes, clarifying examples, and cross references to related guidelines or checkpoints.  A link to a section of the Techniques Document ([TECHNIQUES]) where implementations and examples of the checkpoint are discussed. Each checkpoint is intended to be specific enough so that someone reviewing a page or site may verify that the checkpoint has been satisfied. 3.1 Document conventions The following editorial conventions are used throughout this document:  Element names are in uppercase letters.  Attribute names are quoted in lowercase letters.  Links to definitions are highlighted through the use of style sheets. Priorities Each checkpoint has a priority level assigned by the Working Group based on the checkpoint's impact on accessibility. [Priority 1] A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents. [Priority 2] A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents. [Priority 3] A Web content developer may address this checkpoint. Otherwise, one or more groups will - 418 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents. Some checkpoints specify a priority level that may change under certain (indicated) conditions. Conformance This section defines three levels of conformance to this document:  Conformance Level "A": all Priority 1 checkpoints are satisfied;  Conformance Level "Double-A": all Priority 1 and 2 checkpoints are satisfied;  Conformance Level "Triple-A": all Priority 1, 2, and 3 checkpoints are satisfied; Note. Conformance levels are spelled out in text so they may be understood when rendered to speech. Claims of conformance to this document must use one of the following two forms. Form 1: Specify:  The guidelines title: "Web Content Accessibility Guidelines 1.0"  The guidelines URI: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505  The conformance level satisfied: "A", "Double-A", or "Triple-A".  The scope covered by the claim (e.g., page, site, or defined portion of a site.). Example of Form 1: This page conforms to W3C's "Web Content Accessibility Guidelines 1.0", available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, level Double-A. Form 2: Include, on each page claiming conformance, one of three icons provided by W3C and link the icon to the appropriate W3C explanation of the claim. Information about the icons and how to insert them in pages is available at [WCAG-ICONS]. Web Content Accessibility Guidelines Guideline 1. Provide equivalent alternatives to auditory and visual content. Provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content. Although some people cannot use images, movies, sounds, applets, etc. directly, they may still use pages that include equivalent information to the visual or auditory content. The equivalent information must serve the same purpose as the visual or auditory content. Thus, a text equivalent for an image of an upward arrow that links to a table of contents could be "Go to table of contents". In some cases, an equivalent should also describe the appearance of visual content (e.g., for complex charts, billboards, or diagrams) or the sound of auditory content (e.g., for audio samples used in education). This guideline emphasizes the importance of providing text equivalents of non-text - 419 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR content (images, pre-recorded audio, video). The power of text equivalents lies in their capacity to be rendered in ways that are accessible to people from various disability groups using a variety of technologies. Text can be readily output to speech synthesizers and Braille displays, and can be presented visually (in a variety of sizes) on computer displays and paper. Synthesized speech is critical for individuals who are blind and for many people with the reading difficulties that often accompany cognitive disabilities, learning disabilities, and deafness. Braille is essential for individuals who are both deaf and blind, as well as many individuals whose only sensory disability is blindness. Text displayed visually benefits users who are deaf as well as the majority of Web users. Providing non-text equivalents (e.g., pictures, videos, and pre-recorded audio) of text is also beneficial to some users, especially nonreaders or people who have difficulty reading. In movies or visual presentations, visual action such as body language or other visual cues may not be accompanied by enough audio information to convey the same information. Unless verbal descriptions of this visual information are provided, people who cannot see (or look at) the visual content will not be able to perceive it. Checkpoints: 1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. [Priority 1]. For example, in HTML:  Use "alt" for the IMG, INPUT, and APPLET elements, or provide a text equivalent in the content of the OBJECT and APPLET elements.  For complex content (e.g., a chart) where the "alt" text does not provide a complete text equivalent, provide an additional description using, for example, "longdesc" with IMG or FRAME, a link inside an OBJECT element, or a description link.  For image maps, either use the "alt" attribute with AREA, or use the MAP element with A elements (and other text) as content. Refer also to checkpoint 9.1 and checkpoint 13.10. 1.2 Provide redundant text links for each active region of a server-side image map. [Priority 1]. Refer also to checkpoint 1.5 and checkpoint 9.1. 1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. [Priority 1]. Synchronize the auditory description with the audio track as per checkpoint 1.4. Refer to checkpoint 1.1 for information about textual equivalents for visual information. 1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. [Priority 1] - 420 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. [Priority 3]. Refer also to checkpoint 1.2 and checkpoint 9.1. Guideline 2. Don't rely on color alone. Ensure that text and graphics are understandable when viewed without color. If color alone is used to convey information, people who cannot differentiate between certain colors and users with devices that have non-color or non-visual displays will not receive the information. When foreground and background colors are too close to the same hue, they may not provide sufficient contrast when viewed using monochrome displays or by people with different types of color deficits. Checkpoints: 2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. [Priority 1] 2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text]. Guideline 3. Use markup and style sheets and do so properly. Mark up documents with the proper structural elements. Control presentation with style sheets rather than with presentation elements and attributes. Using markup improperly -- not according to specification -- hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it. Furthermore, using presentation markup rather than structural markup to convey structure (e.g., constructing what looks like a table of data with an HTML PRE element) makes it difficult to render a page intelligibly to other devices (refer to the description of difference between content, structure, and presentation). Content developers may be tempted to use (or misuse) constructs that achieve a desired formatting effect on older browsers. They must be aware that these practices cause accessibility problems and must consider whether the formatting effect is so critical as to warrant making the document inaccessible to some users. At the other extreme, content developers must not sacrifice appropriate markup because a certain browser or assistive technology does not process it correctly. For example, it is appropriate to use the TABLE element in HTML to mark up tabular information even though some older screen-readers may not handle side-by-side text correctly (refer to checkpoint 10.3). Using TABLE correctly and creating tables that transform gracefully (refer to guideline 5) makes it possible for software to render tables other than as two-dimensional grids. Checkpoints: - 421 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 3.1 When an appropriate markup language exists, use markup rather than images to convey information. [Priority 2]. For example, use MathML to mark up mathematical equations, and style sheets to format text and control layout. Also, avoid using images to represent text -- use text and style sheets instead. Refer also to guideline 6 and guideline 11. 3.2 Create documents that validate to published formal grammars. [Priority 2]. For example, include a document type declaration at the beginning of a document that refers to a published DTD (e.g., the strict HTML 4.0 DTD). 3.3 Use style sheets to control layout and presentation. [Priority 2]. For example, use the CSS 'font' property instead of the HTML FONT element to control font styles. 3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values. [Priority 2]. For example, in CSS, use 'em' or percentage lengths rather than 'pt' or 'cm', which are absolute units. If absolute units are used, validate that the rendered content is usable (refer to the section on validation). 3.5 Use header elements to convey document structure and use them according to specification. [Priority 2]. For example, in HTML, use H2 to indicate a subsection of H1. Do not use headers for font effects. 3.6 Mark up lists and list items properly. [Priority 2]. For example, in HTML, nest OL, UL, and DL lists properly. 3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation. [Priority 2]. For example, in HTML, use the Q and BLOCKQUOTE elements to markup short and longer quotations, respectively. Guideline 4. Clarify natural language usage Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text. When content developers mark up natural language changes in a document, speech synthesizers and Braille devices can automatically switch to the new language, making the document more accessible to multilingual users. Content developers should identify the predominant natural language of a document's content (through markup or HTTP headers). Content developers should also provide expansions of abbreviations and acronyms. In addition to helping assistive technologies, natural language markup allows search engines to find key words and identify documents in a desired language. Natural language markup also improves readability of the Web for all people, including those with learning disabilities, cognitive disabilities, or people who are deaf. When abbreviations and natural language changes are not identified, they may be indecipherable when machine-spoken or brailled. Checkpoints: 4.1 Clearly identify changes in the natural language of a document's text and any text - 422 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR equivalents (e.g., captions). [Priority 1]. For example, in HTML use the "lang" attribute. In XML, use "xml:lang". 4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. [Priority 3]. For example, in HTML, use the "title" attribute of the ABBR and ACRONYM elements. Providing the expansion in the main body of the document also helps document usability. 4.3 Identify the primary natural language of a document. [Priority 3]. For example, in HTML set the "lang" attribute on the HTML element. In XML, use "xml:lang". Server operators should configure servers to take advantage of HTTP content negotiation mechanisms ([RFC2068], section 14.13) so that clients can automatically retrieve documents of the preferred language. Guideline 5. Create tables that transform gracefully. Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents. Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables"). Tables for any use also present special problems to users of screen-readers (refer to checkpoint 10.3). Some user agents allow users to navigate among table cells and access header and other table cell information. Unless marked-up properly, these tables will not provide user agents with the appropriate information. (Refer also to guideline 3.) The following checkpoints will directly benefit people who access a table through auditory means (e.g., a screen-reader or an automobile-based personal computer) or who view only a portion of the page at a time (e.g., users with blindness or low vision using speech output or a Braille display, or other users of devices with small displays, etc.). Checkpoints: 5.1 For data tables, identify row and column headers. [Priority 1]. For example, in HTML, use TD to identify data cells and TH to identify headers. 5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. [Priority 1]. For example, in HTML, use THEAD, TFOOT, and TBODY to group rows, COL and COLGROUP to group columns, and the "axis", "scope", and "headers" attributes, to describe more complex relationships among data. 5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). [Priority 2]. Note. Once user agents support style sheet positioning, tables should not be used for layout. Refer also to checkpoint 3.3. 5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. [Priority 2]. For example, in HTML do not use the TH element to cause the content of a (non-table header) cell to be displayed centered - 423 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR and in bold. 5.5 Provide summaries for tables. [Priority 3]. For example, in HTML, use the "summary" attribute of the TABLE element. 5.6 Provide abbreviations for header labels. [Priority 3]. For example, in HTML, use the "abbr" attribute on the TH element. Refer also to checkpoint 10.3. Guideline 6. Ensure that pages featuring new technologies transform gracefully. Ensure that pages are accessible even when newer technologies are not supported or are turned off. Although content developers are encouraged to use new technologies that solve problems raised by existing technologies, they should know how to make their pages still work with older browsers and people who choose to turn off features. Checkpoints: 6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. [Priority 1]. When content is organized logically, it will be rendered in a meaningful order when style sheets are turned off or not supported. 6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. [Priority 1] 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1]. For example, ensure that links that trigger scripts work when scripts are turned off or not supported (e.g., do not use "JavaScript:" as the link target). If it is not possible to make the page usable without scripts, provide a text equivalent with the NOSCRIPT element, or use a server-side script instead of a client-side script, or provide an alternative accessible page as per checkpoint 11.4. Refer also to guideline 1. 6.4 For scripts and applets, ensure that event handlers are input device-independent. [Priority 2]. Refer to the definition of device independence. 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2]. For example, in HTML, use NOFRAMES at the end of each frameset. For some applications, server-side scripts may be more accessible than client-side scripts. Refer also to checkpoint 11.4. Guideline 7. Ensure user control of time-sensitive content changes. Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped. - 424 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Some people with cognitive or visual disabilities are unable to read moving text quickly enough or at all. Movement can also cause such a distraction that the rest of the page becomes unreadable for people with cognitive disabilities. Screen-readers are unable to read moving text. People with physical disabilities might not be able to move quickly or accurately enough to interact with moving objects. Note. All of the following checkpoints involve some content developer responsibility until user agents provide adequate feature control mechanisms. Checkpoints: 7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. [Priority 1]. Note. People with photosensitive epilepsy can have seizures triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (like strobe lights). 7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). [Priority 2] 7.3 Until user agents allow users to freeze moving content, avoid movement in pages. [Priority 2]. When a page includes moving content, provide a mechanism within a script or applet to allow users to freeze motion or updates. Using style sheets with scripting to create movement allows users to turn off or override the effect more easily. Refer also to guideline 8. 7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages. [Priority 2]. For example, in HTML, don't cause pages to auto-refresh with "HTTP-EQUIV=refresh" until user agents allow users to turn off the feature. 7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects. [Priority 2] Note. The BLINK and MARQUEE elements are not defined in any W3C HTMLspecification and should not be used. Refer also to guideline 11. Guideline 8. Ensure direct accessibility of embedded user interfaces. Ensure that the user interface follows principles of accessible design: deviceindependent access to functionality, keyboard operability, self-voicing, etc. When an embedded object has its "own interface", the interface -- like the interface to the browser itself -- must be accessible. If the interface of the embedded object cannot be made accessible, an alternative accessible solution must be provided. Note. For information about accessible interfaces, please consult the User Agent Accessibility Guidelines ([WAI-USERAGENT]) and the Authoring Tool Accessibility Guidelines ([WAI-AUTOOL]). - 425 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Checkpoint: 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]. Refer also to guideline 6. Guideline 9. Design for device-independence. Use features that enable activation of page elements via a variety of input devices. Device-independent access means that the user may interact with the user agent or document with a preferred input (or output) device -- mouse, keyboard, voice, head wand, or other. If, for example, a form control can only be activated with a mouse or other pointing device, someone who is using the page without sight, with voice input, or with a keyboard or who is using some other non-pointing input device will not be able to use the form. Note. Providing text equivalents for image maps or images used as links makes it possible for users to interact with them without a pointing device. Refer also to guideline 1. Generally, pages that allow keyboard interaction are also accessible through speech input or a command line interface. Checkpoints: 9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. [Priority 1]. Refer also to checkpoint 1.1, checkpoint 1.2, and checkpoint 1.5. 9.2 Ensure that any element that has its own interface can be operated in a deviceindependent manner. [Priority 2]. Refer to the definition of device independence. Refer also to guideline 8. 9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. [Priority 2] 9.4 Create a logical tab order through links, form controls, and objects. [Priority 3]. For example, in HTML, specify tab order via the "tabindex" attribute or ensure a logical page design. 9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls. [Priority 3]. For example, in HTML, specify shortcuts via the "accesskey" attribute. Guideline 10. Use interim solutions. Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly. For example, older browsers do not allow users to navigate to empty edit boxes. Older screen-readers read lists of consecutive links as one link. These active elements are - 426 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR therefore difficult or impossible to access. Also, changing the current window or popping up new windows can be very disorienting to users who cannot see that this has happened. Note. The following checkpoints apply until user agents (including assistive technologies) address these issues. These checkpoints are classified as "interim", meaning that the Web Content Guidelines Working Group considers them to be valid and necessary to Web accessibility as of the publication of this document. However, the Working Group does not expect these checkpoints to be necessary in the future, once Web technologies have incorporated anticipated features or capabilities. Checkpoints: 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]. For example, in HTML, avoid using a frame whose target is a new window. 10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. [Priority 2]. The label must immediately precede its control on the same line (allowing more than one control/label per line) or be in the line preceding the control (with only one label and one control per line). Refer also to checkpoint 12.4. 10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. [Priority 3]. Note. Please consult the definition of linearized table. This checkpoint benefits people with user agents (such as some screen-readers) that are unable to handle blocks of text presented side-by-side; the checkpoint should not discourage content developers from using tables to represent tabular information. 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3]. For example, in HTML, do this for TEXTAREA and INPUT. 10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. [Priority 3] Guideline 11. Use W3C technologies and guidelines. Use W3C technologies (according to specification) and follow accessibility guidelines. Where it is not possible to use a W3C technology, or doing so results in material that does not transform gracefully, provide an alternative version of the content that is accessible. The current guidelines recommend W3C technologies (e.g., HTML, CSS, etc.) for several reasons:  W3C technologies include "built-in" accessibility features.  W3C specifications undergo early review to ensure that accessibility issues are - 427 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR considered during the design phase.  W3C specifications are developed in an open, industry consensus process. Many non-W3C formats (e.g., PDF, Shockwave, etc.) require viewing with either plug-ins or stand-alone applications. Often, these formats cannot be viewed or navigated with standard user agents (including assistive technologies). Avoiding non-W3C and nonstandard features (proprietary elements, attributes, properties, and extensions) will tend to make pages more accessible to more people using a wider variety of hardware and software. When inaccessible technologies (proprietary or not) must be used, equivalent accessible pages must be provided. Even when W3C technologies are used, they must be used in accordance with accessibility guidelines. When using new technologies, ensure that they transform gracefully (Refer also to guideline 6.). Note. Converting documents (from PDF, PostScript, RTF, etc.) to W3C markup languages (HTML, XML) does not always create an accessible document. Therefore, validate each page for accessibility and usability after the conversion process (refer to the section on validation). If a page does not readily convert, either revise the page until its original representation converts appropriately or provide an HTML or plain text version. Checkpoints: 11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. [Priority 2]. Refer to the list of references for information about where to find the latest W3C specifications and [WAI-UA-SUPPORT] for information about user agent support for W3C technologies. 11.2 Avoid deprecated features of W3C technologies. [Priority 2]. For example, in HTML, don't use the deprecated FONT element; use style sheets instead (e.g., the 'font' property in CSS). 11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.) [Priority 3]. Note. Use content negotiation where possible. 11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. [Priority 1] Note. Content developers should only resort to alternative pages when other solutions fail because alternative pages are generally updated less often than "primary" pages. An out-of-date page may be as frustrating as one that is inaccessible since, in both cases, the information presented on the original page is unavailable. Automatically generating alternative pages may lead to more frequent updates, but content developers must still be careful to ensure that generated pages always make sense, and that users are able to navigate a site by following links on primary pages, alternative pages, or both. Before resorting to an alternative page, reconsider the design of the original page; making it accessible is likely to improve it for all users. - 428 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Guideline 12. Provide context and orientation information. Provide context and orientation information to help users understand complex pages or elements. Grouping elements and providing contextual information about the relationships between elements can be useful for all users. Complex relationships between parts of a page may be difficult for people with cognitive disabilities and people with visual disabilities to interpret. Checkpoints: 12.1 Title each frame to facilitate frame identification and navigation. [Priority 1]. For example, in HTML use the "title" attribute on FRAME elements. 12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. [Priority 2]. For example, in HTML, use "longdesc," or a description link. 12.3 Divide large blocks of information into more manageable groups where natural and appropriate. [Priority 2]. For example, in HTML, use OPTGROUP to group OPTION elements inside a SELECT; group form controls with FIELDSET and LEGEND; use nested lists where appropriate; use headings to structure documents, etc. Refer also to guideline 3. 12.4 Associate labels explicitly with their controls. [Priority 2]. For example, in HTML use LABEL and its "for" attribute. Guideline 13. Provide clear navigation mechanisms. Provide clear and consistent navigation mechanisms -- orientation information, navigation bars, a site map, etc. -- to increase the likelihood that a person will find what they are looking for at a site. Clear and consistent navigation mechanisms are important to people with cognitive disabilities or blindness, and benefit all users. Checkpoints: 13.1 Clearly identify the target of each link. [Priority 2]. Link text should be meaningful enough to make sense when read out of context -- either on its own or as part of a sequence of links. Link text should also be terse. For example, in HTML, write "Information about version 4.3" instead of "click here". In addition to clear link text, content developers may further clarify the target of a link with an informative link title (e.g., in HTML, the "title" attribute). 13.2 Provide metadata to add semantic information to pages and sites. [Priority 2]. For example, use RDF ([RDF]) to indicate the document's author, the type of content, etc. Note. Some HTML user agents can build navigation tools from document relations described by the HTML LINK element and "rel" or "rev" attributes (e.g., rel="next", rel="previous", rel="index", etc.). Refer also to checkpoint 13.5. 13.3 Provide information about the general layout of a site (e.g., a site map or table - 429 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR of contents). [Priority 2]. In describing site layout, highlight and explain available accessibility features. 13.4 Use navigation mechanisms in a consistent manner. [Priority 2] 13.5 Provide navigation bars to highlight and give access to the navigation mechanism. [Priority 3] 13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. [Priority 3] 13.7 If search functions are provided, enable different types of searches for different skill levels and preferences. [Priority 3] 13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc. [Priority 3]. Note. This is commonly referred to as "front-loading" and is especially helpful for people accessing information with serial devices such as speech synthesizers. 13.9 Provide information about document collections (i.e., documents comprising multiple pages.). [Priority 3]. For example, in HTML specify document collections with the LINK element and the "rel" and "rev" attributes. Another way to create a collection is by building an archive (e.g., with zip, tar and gzip, stuffit, etc.) of the multiple pages. Note. The performance improvement gained by offline processing can make browsing much less expensive for people with disabilities who may be browsing slowly. 13.10 Provide a means to skip over multi-line ASCII art. [Priority 3]. Refer to checkpoint 1.1 and the example of ascii art in the glossary. Guideline 14. Ensure that documents are clear and simple. Ensure that documents are clear and simple so they may be more easily understood. Consistent page layout, recognizable graphics, and easy to understand language benefit all users. In particular, they help people with cognitive disabilities or who have difficulty reading. (However, ensure that images have text equivalents for people who are blind, have low vision, or for any user who cannot or has chosen not to view graphics. Refer also to guideline 1.) Using clear and simple language promotes effective communication. Access to written information can be difficult for people who have cognitive or learning disabilities. Using clear and simple language also benefits people whose first language differs from your own, including those people who communicate primarily in sign language. Checkpoints: 14.1 Use the clearest and simplest language appropriate for a site's content. [Priority 1] 14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page. [Priority 3]. Refer also to guideline 1. - 430 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 14.3 Create a style of presentation that is consistent across pages. [Priority 3] Appendix A. -- Validation Validate accessibility with automatic tools and human review. Automated methods are generally rapid and convenient but cannot identify all accessibility issues. Human review can help ensure clarity of language and ease of navigation. Begin using validation methods at the earliest stages of development. Accessibility issues identified early are easier to correct and avoid. Following are some important validation methods, discussed in more detail in the section on validation in the Techniques Document. 1) Use an automated accessibility tool and browser validation tool. Please note that software tools do not address all accessibility issues, such as the meaningfulness of link text, the applicability of a text equivalent, etc. 2) Validate syntax (e.g., HTML, XML, etc.). 3) Validate style sheets (e.g., CSS). 4) Use a text-only browser or emulator. 5) Use multiple graphic browsers, with:  sounds and graphics loaded,  graphics not loaded,  sounds not loaded,  no mouse,  frames, scripts, style sheets, and applets not loaded. 6) Use several browsers, old and new. 7) Use a self-voicing browser, a screen-reader, magnification software, a small display, etc. 8) Use spell and grammar checkers. A person reading a page with a speech synthesizer may not be able to decipher the synthesizer's best guess for a word with a spelling error. Eliminating grammar problems increases comprehension. 9) Review the document for clarity and simplicity. Readability statistics, such as those generated by some word processors may be useful indicators of clarity and simplicity. Better still, ask an experienced (human) editor to review written content for clarity. Editors can also improve the usability of documents by identifying potentially sensitive cultural issues that might arise due to language or icon usage. 10) Invite people with disabilities to review documents. Expert and novice users with disabilities will provide valuable feedback about accessibility or usability problems and their severity. […] - 431 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR VII.2 - Section 508 Electronic and Information Technology Accessibility Standards (Section 508) Published in the Federal Register on December 21, 2000. Table of Contents Subpart A -- General Subpart B -- Technical Standards Subpart C -- Functional Performance Criteria Subpart D -- Information, Documentation, and Support Related Document: Preamble (published discussion of the standards) Table of Contents Subpart A -- General 1194.2 Application. 1194.3 General exceptions. 1194.4 Definitions. 1194.5 Equivalent facilitation. Subpart B -- Technical Standards 1194.21 Software applications and operating systems. 1194.22 Web-based intranet and internet information and applications. 1194.23 Telecommunications products. 1194.24 Video and multimedia products. 1194.25 Self contained, closed products. 1194.26 Desktop and portable computers. Subpart C -- Functional Performance Criteria 1194.31 Functional performance criteria. Subpart D -- Information, Documentation, and Support 1194.41 Information, documentation, and support. Authority: 29 U.S.C. 794d. Subpart A -- General § 1194.1 Purpose. The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a - 432 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency. § 1194.2 Application. (a) Products covered by this part shall comply with all applicable provisions of this part. When developing, procuring, maintaining, or using electronic and information technology, each agency shall ensure that the products comply with the applicable provisions of this part, unless an undue burden would be imposed on the agency. (1) When compliance with the provisions of this part imposes an undue burden, agencies shall provide individuals with disabilities with the information and data involved by an alternative means of access that allows the individual to use the information and data. (2) When procuring a product, if an agency determines that compliance with any provision of this part imposes an undue burden, the documentation by the agency supporting the procurement shall explain why, and to what extent, compliance with each such provision creates an undue burden. (b) When procuring a product, each agency shall procure products which comply with the provisions in this part when such products are available in the commercial marketplace or when such products are developed in response to a Government solicitation. Agencies cannot claim a product as a whole is not commercially available because no product in the marketplace meets all the standards. If products are commercially available that meet some but not all of the standards, the agency must procure the product that best meets the standards. (c) Except as provided by §1194.3(b), this part applies to electronic and information technology developed, procured, maintained, or used by agencies directly or used by a contractor under a contract with an agency which requires the use of such product, or requires the use, to a significant extent, of such product in the performance of a service or the furnishing of a product. § 1194.3 General exceptions. (a) This part does not apply to any electronic and information technology operated by agencies, the function, operation, or use of which involves intelligence activities, cryptologic activities related to national security, command and control of military forces, equipment that is an integral part of a weapon or weapons system, or systems which are critical to the direct fulfillment of military or intelligence missions. Systems which are critical to the direct fulfillment of military or intelligence missions do not include a system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). (b) This part does not apply to electronic and information technology that is acquired by a contractor incidental to a contract. (c) Except as required to comply with the provisions in this part, this part does not require the installation of specific accessibility-related software or the attachment of an assistive technology device at a workstation of a Federal employee who is not an - 433 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR individual with a disability. (d) When agencies provide access to the public to information or data through electronic and information technology, agencies are not required to make products owned by the agency available for access and use by individuals with disabilities at a location other than that where the electronic and information technology is provided to the public, or to purchase products for access and use by individuals with disabilities at a location other than that where the electronic and information technology is provided to the public. (e) This part shall not be construed to require a fundamental alteration in the nature of a product or its components. (f) Products located in spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment are not required to comply with this part. § 1194.4 Definitions. The following definitions apply to this part: Agency. Any Federal department or agency, including the United States Postal Service. Alternate formats. Alternate formats usable by people with disabilities may include, but are not limited to, Braille, ASCII text, large print, recorded audio, and electronic formats that comply with this part. Alternate methods. Different means of providing information, including product documentation, to people with disabilities. Alternate methods may include, but are not limited to, voice, fax, relay service, TTY, Internet posting, captioning, text-to-speech synthesis, and audio description. Assistive technology. Any item, piece of equipment, or system, whether acquired commercially, modified, or customized, that is commonly used to increase, maintain, or improve functional capabilities of individuals with disabilities. Electronic and information technology. Includes information technology and any equipment or interconnected system or subsystem of equipment, that is used in the creation, conversion, or duplication of data or information. The term electronic and information technology includes, but is not limited to, telecommunications products (such as telephones), information kiosks and transaction machines, World Wide Web sites, multimedia, and office equipment such as copiers and fax machines. The term does not include any equipment that contains embedded information technology that is used as an integral part of the product, but the principal function of which is not the acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information. For example, HVAC (heating, ventilation, and air conditioning) equipment such as thermostats or temperature control devices, and medical equipment where information technology is integral to its operation, are not information technology. Information technology. Any equipment or interconnected system or subsystem of equipment, that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data - 434 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR or information. The term information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources. Operable controls. A component of a product that requires physical contact for normal operation. Operable controls include, but are not limited to, mechanically operated controls, input and output trays, card slots, keyboards, or keypads. Product. Electronic and information technology. Self Contained, Closed Products. Products that generally have embedded software and are commonly designed in such a fashion that a user cannot easily attach or install assistive technology. These products include, but are not limited to, information kiosks and information transaction machines, copiers, printers, calculators, fax machines, and other similar types of products. Telecommunications. The transmission, between or among points specified by the user, of information of the user's choosing, without change in the form or content of the information as sent and received. TTY. An abbreviation for teletypewriter. Machinery or equipment that employs interactive text based communications through the transmission of coded signals across the telephone network. TTYs may include, for example, devices known as TDDs (telecommunication display devices or telecommunication devices for deaf persons) or computers with special modems. TTYs are also called text telephones. Undue burden. Undue burden means significant difficulty or expense. In determining whether an action would result in an undue burden, an agency shall consider all agency resources available to the program or component for which the product is being developed, procured, maintained, or used. § 1194.5 Equivalent facilitation. Nothing in this part is intended to prevent the use of designs or technologies as alternatives to those prescribed in this part provided they result in substantially equivalent or greater access to and use of a product for people with disabilities. Subpart B -- Technical Standards § 1194.21 Software applications and operating systems. (a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually. (b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the - 435 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR product developer. (c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes. (d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. (e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance. (f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes. (g) Applications shall not override user selected contrast and color selections and other individual display attributes. (h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user. (i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided. (k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz. (l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. § 1194.22 Web-based intranet and internet information and applications. (a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content). (b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. (c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. (d) Documents shall be organized so they are readable without requiring an associated style sheet. - 436 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR (e) Redundant text links shall be provided for each active region of a server-side image map. (f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape. (g) Row and column headers shall be identified for data tables. (h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. (i) Frames shall be titled with text that facilitates frame identification and navigation. (j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. (k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes. (l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology. (m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l). (n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. (o) A method shall be provided that permits users to skip repetitive navigation links. (p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. Note to §1194.22: 1. The Board interprets paragraphs (a) through (k) of this section as consistent with the following priority 1 Checkpoints of the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (May 5, 1999) published by the Web Accessibility Initiative of the World Wide Web Consortium: Section 1194.22 Paragraph WCAG 1.0 Checkpoint (a) 1.1 - 437 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR (b) 1.4 (c) 2.1 (d) 6.1 (e) 1.2 (f) 9.1 (g) 5.1 (h) 5.2 (i) 12.1 (j) 7.1 (k) 11.4 2. Paragraphs (l), (m), (n), (o), and (p) of this section are different from WCAG 1.0. Web pages that conform to WCAG 1.0, level A (i.e., all priority 1 checkpoints) must also meet paragraphs (l), (m), (n), (o), and (p) of this section to comply with this section. WCAG 1.0 is available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. […] Subpart C -- Functional Performance Criteria § 1194.31 Functional performance criteria. (a) At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided. (b) At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 shall be provided in audio and enlarged print output working together or independently, or support for assistive technology used by people who are visually impaired shall be provided. (c) At least one mode of operation and information retrieval that does not require user hearing shall be provided, or support for assistive technology used by people who are deaf or hard of hearing shall be provided. (d) Where audio information is important for the use of a product, at least one mode of operation and information retrieval shall be provided in an enhanced auditory fashion, or support for assistive hearing devices shall be provided. (e) At least one mode of operation and information retrieval that does not require user speech shall be provided, or support for assistive technology used by people with disabilities shall be provided. (f) At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength shall be provided. - 438 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Subpart D -- Information, Documentation, and Support § 1194.41 Information, documentation, and support. (a) Product support documentation provided to end-users shall be made available in alternate formats upon request, at no additional charge. (b) End-users shall have access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request, at no additional charge. (c) Support services for products shall accommodate the communication needs of end-users with disabilities. - 439 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR VII.3 - Legge Stanca Legge n. 4 del 9 gennaio 2004 (G.U. n. 13 del 17 gennaio 2004) Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici Art. 1 (Obiettivi e finalità) 1. La Repubblica riconosce e tutela il diritto di ogni persona ad accedere a tutte le fonti di informazione e ai relativi servizi, ivi compresi quelli che si articolano attraverso gli strumenti informatici e telematici. 2. È tutelato e garantito, in particolare, il diritto di accesso ai servizi informatici e telematici della pubblica amministrazione e ai servizi di pubblica utilità da parte delle persone disabili, in ottemperanza al principio di uguaglianza ai sensi dell'articolo 3 della Costituzione. Art. 2 (Definizioni) 1. Ai fini della presente legge, si intende per: a. «accessibilità»: la capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari; b. «tecnologie assistive»: gli strumenti e le soluzioni tecniche, hardware e software, che permettono alla persona disabile, superando o riducendo le condizioni di svantaggio, di accedere alle informazioni e ai servizi erogati dai sistemi informatici. Art. 3 (Soggetti erogatori) 1. La presente legge si applica alle pubbliche amministrazioni di cui al comma 2 dell'articolo 1 del decreto legislativo 30 marzo 2001, n. 165, e successive modificazioni, agli enti pubblici economici, alle aziende private concessionarie di servizi pubblici, alle aziende municipalizzate regionali, agli enti di assistenza e di riabilitazione pubblici, alle aziende di trasporto e di telecomunicazione a prevalente partecipazione di capitale pubblico e alle aziende appaltatrici di servizi informatici. 2. Le disposizioni della presente legge in ordine agli obblighi per l'accessibilità non si applicano ai sistemi informatici destinati ad essere fruiti da gruppi di utenti dei quali, per disposizione di legge, non possono fare parte persone disabili. Art. 4 (Obblighi per l'accessibilità) 1. Nelle procedure svolte dai soggetti di cui all'articolo 3, comma 1, per l'acquisto di beni e per la fornitura di servizi informatici, i requisiti di accessibilità stabiliti con il decreto di cui all'articolo 11 costituiscono motivo di preferenza a parità di ogni altra condizione nella valutazione dell'offerta tecnica, tenuto conto della destinazione del bene o del servizio. La mancata considerazione dei - 440 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR requisiti di accessibilità o l'eventuale acquisizione di beni o fornitura di servizi non accessibili è adeguatamente motivata. 2. I soggetti di cui all'articolo 3, comma 1, non possono stipulare, a pena di nullità, contratti per la realizzazione e la modifica di siti INTERNET quando non è previsto che essi rispettino i requisiti di accessibilità stabiliti dal decreto di cui all'articolo 11. I contratti in essere alla data di entrata in vigore del decreto di cui all'articolo 11, in caso di rinnovo, modifica o novazione, sono adeguati, a pena di nullità, alle disposizioni della presente legge circa il rispetto dei requisiti di accessibilità, con l'obiettivo di realizzare tale adeguamento entro dodici mesi dalla data di entrata in vigore del medesimo decreto. 3. La concessione di contributi pubblici a soggetti privati per l'acquisto di beni e servizi informatici destinati all'utilizzo da parte di lavoratori disabili o del pubblico, anche per la predisposizione di postazioni di telelavoro, è subordinata alla rispondenza di tali beni e servizi ai requisiti di accessibilità stabiliti dal decreto di cui all'articolo 11. 4. I datori di lavoro pubblici e privati pongono a disposizione del dipendente disabile la strumentazione hardware e software e la tecnologia assistiva adeguata alla specifica disabilità, anche in caso di telelavoro, in relazione alle mansioni effettivamente svolte. Ai datori di lavoro privati si applica la disposizione di cui all'articolo 13, comma 1, lettera c), della legge 12 marzo 1999, n. 68. 5. I datori di lavoro pubblici provvedono all'attuazione del comma 4, nell'ambito delle disponibilità di bilancio. Art. 5 (Accessibilità degli strumenti didattici e formativi) 1. Le disposizioni della presente legge si applicano, altresì, al materiale formativo e didattico utilizzato nelle scuole di ogni ordine e grado. 2. Le convenzioni stipulate tra il Ministero dell'istruzione, dell'università e della ricerca e le associazioni di editori per la fornitura di libri alle biblioteche scolastiche prevedono sempre la fornitura di copie su supporto digitale degli strumenti didattici fondamentali, accessibili agli alunni disabili e agli insegnanti di sostegno, nell'ambito delle disponibilità di bilancio. Art. 6 (Verifica dell'accessibilità su richiesta) 1. La Presidenza del Consiglio dei ministri - Dipartimento per l'innovazione e le tecnologie valuta su richiesta l'accessibilità dei siti INTERNET o del materiale informatico prodotto da soggetti diversi da quelli di cui all'articolo 3. 2. Con il regolamento di cui all'articolo 10 sono individuati: a. le modalità con cui può essere richiesta la valutazione; b. i criteri per la eventuale partecipazione del richiedente ai costi dell'operazione; c. il marchio o logo con cui è reso manifesto il possesso del requisito dell'accessibilità; d. le modalità con cui può essere verificato il permanere del requisito stesso. Art. 7 (Compiti amministrativi) 1. La Presidenza del Consiglio dei ministri - Dipartimento per l'innovazione e le tecnologie, anche avvalendosi del Centro nazionale per l'informatica nella pubblica amministrazione di cui all'articolo 4, comma 1, del decreto legislativo - 441 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 12 febbraio 1993, n. 39, come sostituito dall'articolo 176 del decreto legislativo 30 giugno 2003, n. 196: a. effettua il monitoraggio dell'attuazione della presente legge; b. vigila sul rispetto da parte delle amministrazioni statali delle disposizioni della presente legge; c. indica i soggetti, pubblici o privati, che, oltre ad avere rispettato i requisiti tecnici indicati dal decreto di cui all'articolo 11, si sono anche meritoriamente distinti per l'impegno nel perseguire le finalità indicate dalla presente legge; d. promuove, di concerto con il Ministero del lavoro e delle politiche sociali, progetti, iniziative e programmi finalizzati al miglioramento e alla diffusione delle tecnologie assistive e per l'accessibilità; e. promuove, con le altre amministrazioni interessate, sentita la Conferenza permanente per i rapporti tra lo Stato, le regioni e le province autonome di Trento e di Bolzano, l'erogazione di finanziamenti finalizzati alla diffusione tra i disabili delle tecnologie assistive e degli strumenti informatici dotati di configurazioni particolari e al sostegno di progetti di ricerca nel campo dell'innovazione tecnologica per la vita indipendente e le pari opportunità dei disabili; f. favorisce, di concerto con il Ministero del lavoro e delle politiche sociali e con il Ministro per le pari opportunità, lo scambio di esperienze e di proposte fra associazioni di disabili, associazioni di sviluppatori competenti in materia di accessibilità, amministrazioni pubbliche, operatori economici e fornitori di hardware e software, anche per la proposta di nuove iniziative; g. promuove, di concerto con i Ministeri dell'istruzione, dell'università e della ricerca e per i beni e le attività culturali, iniziative per favorire l'accessibilità alle opere multimediali, anche attraverso specifici progetti di ricerca e sperimentazione con il coinvolgimento delle associazioni delle persone disabili; sulla base dei risultati delle sperimentazioni sono indicate, con decreto emanato di intesa dai Ministri interessati, le regole tecniche per l'accessibilità alle opere multimediali; h. definisce, di concerto con il Dipartimento della funzione pubblica della Presidenza del Consiglio dei ministri, gli obiettivi di accessibilità delle pubbliche amministrazioni nello sviluppo dei sistemi informatici, nonchè l'introduzione delle problematiche relative all'accessibilità nei programmi di formazione del personale. 2. Le regioni, le province autonome e gli enti locali vigilano sull'attuazione da parte dei propri uffici delle disposizioni della presente legge. Art. 8 (Formazione) 1. Le amministrazioni di cui all'articolo 3, comma 1, nell'ambito delle attività di cui al comma 4 dell'articolo 7 del decreto legislativo 30 marzo 2001, n. 165, nonché dei corsi di formazione organizzati dalla Scuola superiore della pubblica amministrazione, e nell'ambito delle attività per l'alfabetizzazione informatica dei pubblici dipendenti di cui all'articolo 27, comma 8, lettera g), della legge 16 gennaio 2003, n. 3, inseriscono tra le materie di studio a carattere fondamentale le problematiche relative all'accessibilità e alle tecnologie assistive. 2. La formazione professionale di cui al comma 1 è effettuata con tecnologie - 442 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR accessibili. 3. Le amministrazioni di cui all'articolo 3, comma 1, nell'ambito delle disponibilità di bilancio, predispongono corsi di aggiornamento professionale sull'accessibilità. Art. 9 (Responsabilità) 1. L'inosservanza delle disposizioni della presente legge comporta responsabilità dirigenziale e responsabilità disciplinare ai sensi degli articoli 21 e 55 del decreto legislativo 30 marzo 2001, n. 165, ferme restando le eventuali responsabilità penali e civili previste dalle norme vigenti. Art. 10 (Regolamento di attuazione) 1. Entro novanta giorni dalla data di entrata in vigore della presente legge, con regolamento emanato ai sensi dell'articolo 17, comma 1, della legge 23 agosto 1988, n. 400, sono definiti: a. i criteri e i princìpi operativi e organizzativi generali per l'accessibilità; b. i contenuti di cui all'articolo 6, comma 2; c. i controlli esercitabili sugli operatori privati che hanno reso nota l'accessibilità dei propri siti e delle proprie applicazioni informatiche; d. i controlli esercitabili sui soggetti di cui all'articolo 3, comma 1. 2. Il regolamento di cui al comma 1 è adottato previa consultazione con le associazioni delle persone disabili maggiormente rappresentative, con le associazioni di sviluppatori competenti in materia di accessibilità e di produttori di hardware e software e previa acquisizione del parere delle competenti Commissioni parlamentari, che devono pronunciarsi entro quarantacinque giorni dalla richiesta, e d'intesa con la Conferenza unificata di cui all'articolo 8 del decreto legislativo 28 agosto 1997, n. 281. Art. 11 (Requisiti tecnici) 1. Entro centoventi giorni dalla data di entrata in vigore della presente legge il Ministro per l'innovazione e le tecnologie, consultate le associazioni delle persone disabili maggiormente rappresentative, con proprio decreto stabilisce, nel rispetto dei criteri e dei princìpi indicati dal regolamento di cui all'articolo 10: a. le linee guida recanti i requisiti tecnici e i diversi livelli per l'accessibilità; b. le metodologie tecniche per la verifica dell'accessibilità dei siti INTERNET, nonchè i programmi di valutazione assistita utilizzabili a tale fine. Art. 12 (Normative internazionali) 1. Il regolamento di cui all'articolo 10 e il decreto di cui all'articolo 11 sono emanati osservando le linee guida indicate nelle comunicazioni, nelle raccomandazioni e nelle direttive sull'accessibilità dell'Unione europea, nonchè nelle normative internazionalmente riconosciute e tenendo conto degli indirizzi forniti dagli organismi pubblici e privati, anche internazionali, operanti nel settore. 2. Il decreto di cui all'articolo 11 è periodicamente aggiornato, con la medesima - 443 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR procedura, per il tempestivo recepimento delle modifiche delle normative di cui al comma 1 e delle innovazioni tecnologiche nel frattempo intervenute. La presente legge, munita del sigillo dello Stato, sarà inserita nella Raccolta ufficiale degli atti normativi della Repubblica Italiana. È fatto obbligo a chiunque spetti di osservarla e di farla osservare come legge dello Stato. Regolamento di attuazione della legge 9 gennaio 2004, n. 4 […] Articolo 1: Definizioni 1. Ai fini del presente regolamento s’intende per: a. accessibilità: ai sensi dell’articolo 2, comma 1, lettera a), della legge 9 gennaio 2004, n. 4, la capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari; b. tecnologie assistive: ai sensi dell’articolo 2, comma 1, lettera b), della legge n. 4 del 2004, gli strumenti e le soluzioni tecniche, hardware e software, che permettono alla persona disabile, superando o riducendo le condizioni di svantaggio, di accedere ai servizi erogati dai sistemi informatici; c. valutazione: processo con il quale si riscontra la rispondenza dei servizi ai requisiti di accessibilità; d. verifica tecnica: valutazione condotta da esperti, anche con strumenti informatici, sulla base di parametri tecnici; e. verifica soggettiva: valutazione del livello di qualità dei servizi, già giudicati accessibili tramite la verifica tecnica, effettuata con l’intervento del destinatario, anche disabile, sulla base di considerazioni empiriche; f. fruibilità: la caratteristica dei servizi di rispondere a criteri di facilità e semplicità d’uso, di efficienza, di rispondenza alle esigenze dell’utente, di gradevolezza e di soddisfazione nell’uso del prodotto; g. soggetti privati: soggetti diversi da quelli di cui all’articolo 3 della legge n. 4 del 2004; h. valutatori: soggetti iscritti nell’apposito elenco e qualificati a certificare le caratteristiche di accessibilità dei servizi. Articolo 2: Criteri e principi generali per l’accessibilità 1. Sono accessibili i servizi realizzati tramite sistemi informatici che presentano i seguenti requisiti: a. accessibilità al contenuto del servizio da parte dell’utente; b. fruibilità delle informazioni offerte, caratterizzata anche da: 1) facilità e semplicità d’uso, assicurando, fra l’altro, che le azioni da compiere per ottenere servizi e informazioni siano sempre uniformi tra loro; 2) efficienza nell’uso, assicurando, fra l’altro, la separazione tra contenuto, presentazione e modalità di funzionamento delle interfacce, nonché la possibilità di rendere disponibile - 444 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR l’informazione attraverso differenti canali sensoriali; 3) efficacia nell’uso e rispondenza alle esigenze dell’utente, assicurando, fra l’altro, che le azioni da compiere per ottenere in modo corretto servizi e informazioni siano indipendenti dal dispositivo utilizzato per l’accesso; 4) soddisfazione nell’uso, assicurando, fra l’altro, l’accesso al servizio e all’informazione senza ingiustificati disagi o vincoli per l’utente; c. compatibilità con le linee guida indicate nelle comunicazioni, nelle raccomandazioni e nelle direttive sull’accessibilità dell’Unione europea, nonché nelle normative internazionalmente riconosciute e tenendo conto degli indirizzi forniti dagli organismi pubblici e privati, anche internazionali, operanti nel settore, quali l’International Organization for Standardization (ISO) e il World Wide Web Consortium (W3C). 2. Con apposito decreto del Ministro per l’innovazione e le tecnologie, di concerto con il Ministro dell’istruzione, dell’università e della ricerca, sentiti la Conferenza Unificata e il Centro nazionale per l’informatica nella pubblica amministrazione (Cnipa), sono dettate specifiche regole tecniche che disciplinano l’accessibilità, da parte degli utenti, agli strumenti didattici e formativi di cui all’articolo 5, comma 1,della legge n. 4 del 2004. […] Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici. Pubblicato sulla Gazzetta Ufficiale n. 183 dell'8 agosto 2005. Articolo 1 (Definizioni e ambito d'applicazione) 1. Ai fini del presente decreto s'intende per: a) accessibilità: capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità b) necessitano di tecnologie assistive o configurazioni particolari; mbiente operativo: insieme di programmi e di interfacce utente che consentono c) l'utilizzo delle risorse hardware e software disponibili sul computer; pplet: programma autonomo, in genere scritto in linguaggio Java, che può essere d) inserito in una pagina Web per fornire informazioni o funzionalità; pplicazione: programma informatico che consente all'utente di svolgere specifici e) compiti; pplicazione Internet: programma sviluppato adottando tecnologie Internet, in particolare utilizzando il protocollo HTTP (HyperText Transfer Protocol) per il trasferimento dei dati e il linguaggio a marcatori (X)HTML (eXtensible HyperText f) Markup Language) per la presentazione e la struttura dell'informazione; rowser: programma informatico che consente di accedere alle risorse presenti su un g) sito Web; CD-ROM (Compact Disc - Read Only Memory) e DVD (Digital Versatile Disc): particolari tipi di supporto ottico di memorizzazione; - 445 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR h) em: unità di misura tipografica che prende a riferimento la larghezza del carattere M; i) esperto di fattori umani: soggetto in possesso di diploma di laurea, anche triennale, comprendente un anno di formazione in discipline ergonomiche, quali ergonomia dell'ambiente, ergonomia dell'hardware, ergonomia cognitiva, macroergonomia, che abbia svolto un tirocinio documentato di almeno un anno; l) esperto di interazione con persone disabili: soggetto in possesso di diploma di laurea, anche triennale, esperto di problematiche di comunicazione e di utilizzo delle tecnologie dell'informazione e della comunicazione, che abbia maturato un'esperienza professionale biennale nel settore; m) esperto tecnico: soggetto esperto in tecnologie Web e problematiche dell'accessibilità; n) o) focus: elemento attivo in un'interfaccia utente; fogli di stile: strumento per mezzo del quale è possibile separare i contenuti di p) una pagina Web dalle modalità tipografiche con le quali essi vengono presentati; frame: struttura di una pagina Web costituita da due o più parti indipendenti; q) fruibilità: caratteristica dei servizi di rispondere a criteri di facilità e semplicità d'uso, di efficienza, di rispondenza alle esigenze dell'utente, di r) gradevolezza e di soddisfazione nell'uso del prodotto; gestore di evento: parte di programma informatico che si attiva al verificarsi di s) un evento logico o dipendente dal dispositivo di input; gruppo di valutazione: gruppo di utenti, anche disabili, che svolgono compiti assegnati dall'esperto di fattori umani per l'effettuazione della verifica soggettiva; t) homepage: prima pagina che viene resa disponibile all'utente quando si accede a un indirizzo corrispondente a un sito Web; u) interattività: caratteristica del programma informatico che richiede l'intervento dell'utente per espletare le sue funzionalità; v) interfaccia utente: programma informatico che gestisce l'output e l'input dell'utente da e verso un computer in modo interattivo, realizzato attraverso una rappresentazione basata su metafore grafiche (interfaccia grafica) oppure attraverso comandi impartiti in modo testuale (interfaccia testuale); z) interfaccia di programmazione (API, Application Program Interface): insieme di programmi che consentono ad applicazioni diverse di comunicare tra loro; aa) Internet: rete mondiale di computer basata sulla famiglia di protocolli di comunicazione TCP/IP (Transmission Control Protocol/Internet Protocol); bb) Intranet: rete di computer basata sugli stessi protocolli di Internet, riservata all'uso esclusivo di una organizzazione, o gruppo di utenti; cc) legge: legge 9 gennaio 2004, n. 4, pubblicata nella Gazzetta Ufficiale n. 13 del 17 gennaio 2004, recante disposizioni per favorire l'accesso dei soggetti disabili dd) agli strumenti informatici; linguaggio a marcatori: modalità di rappresentazione delle informazioni che ee) utilizza indicatori (marcatori) per qualificare l'informazione stessa; moduli di interazione o form: strumenti mediante i quali l'utente interagisce con ff) il sito Web fornendo e ricevendo specifiche informazioni; pagina Web: elemento informativo di base di un sito Web, realizzato mediante un linguaggio a marcatori che può contenere oggetti testuali e multimediali ed immagini; gg) prodotti a scaffale: applicazioni preconfezionate da utilizzarsi anche senza sviluppare appositi programmi di adattamento; hh) regolamento: decreto del Presidente della Repubblica 1° marzo 2005, n. 75, - 446 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR ii) pubblicato nella Gazzetta Ufficiale n. 101 del 3 maggio 2005; script: sequenza di istruzioni in linguaggio di programmazione che può essere ll) inserita in una pagina Web per fornire funzionalità aggiuntive; sito Web: insieme strutturato di pagine Web utilizzato per veicolare informazioni o mm) erogare servizi, comunemente definito anche sito Internet; task: compito specifico che l'esperto di fattori umani assegna ad un componente del gruppo di valutazione per simulare situazioni concrete di interazione con il sistema informatico; nn) tecnologie assistive: strumenti e soluzioni tecniche, hardware e software, che permettono alla persona disabile, superando o riducendo le condizioni di svantaggio, di accedere alle informazioni e ai servizi erogati dai sistemi informatici; oo) tecnologie Web: insieme degli standard definiti dall'ISO e delle «Recommendation» del Consorzio W3C finalizzato a veicolare informazioni o erogare servizi su reti pp) che utilizzano il protocollo HTTP, comunemente definite anche tecnologie Internet; verifica tecnica: valutazione condotta da esperti, anche con strumenti informatici, qq) sulla base di parametri tecnici; verifica soggettiva: valutazione del livello di qualità dei servizi, già giudicati accessibili tramite la verifica tecnica, effettuata con l'intervento del destinatario, anche disabile, sulla base di considerazioni empiriche. Articolo 2 (Requisiti tecnici e livelli di accessibilità) 1. Il presente decreto definisce negli allegati A, B, C e D, che ne costituiscono parte integrante, le linee guida recanti i requisiti tecnici e i diversi livelli per l’accessibilità, ai sensi degli articoli 11 e 12 della legge e nel rispetto dei criteri e dei principi indicati dal regolamento. 2. Il primo livello di accessibilità dei siti Web è accertato previo esito positivo della verifica tecnica che riscontra la conformità delle pagine dei medesimi siti ai requisiti tecnici elencati nell’allegato A, applicando la metodologia ivi indicata. 3. I requisiti tecnici si applicano anche nei casi in cui i soggetti di cui all’articolo 3, comma 1 della legge forniscono informazioni o erogano servizi mediante applicazioni Internet rese disponibili su reti Intranet o su supporti, come CD-ROM, DVD, utilizzabili anche in caso di personal computer non collegato alla rete. 4. Il secondo livello di accessibilità riguarda la qualità delle informazioni fornite e dei servizi erogati dal sito Web e si articola in primo, secondo e terzo livello di qualità; tali livelli di qualità sono accertati con la verifica soggettiva attraverso i criteri di valutazione di cui all’allegato B, applicando la metodologia ivi indicata. Articolo 3 (Accessibilità per i personal computer, l'ambiente operativo,le applicazioni e i prodotti a scaffale) 1. I requisiti di accessibilità per i personal computer sono indicati nell’allegato C. 2. I requisiti di accessibilità per l’ambiente operativo, le applicazioni ed i - 447 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR prodotti a scaffale sono indicati nell’allegato D. 3. Il soggetto produttore o fornitore dichiara il livello di conformità del prodotto o servizio ai requisiti di cui al presente articolo. Articolo 4 (Specifiche tecniche per la sussistenza dei requisiti dei soggetti valutatori) 1. Le persone giuridiche interessate alla iscrizione nell’elenco dei valutatori di cui all’articolo 3, comma 1 del regolamento presentano documentazione idonea a comprovare la disponibilità di risorse strumentali tali da consentire l’effettuazione delle verifiche tecnica e soggettiva. 2. Le persone giuridiche di cui al comma 1 forniscono altresì elementi idonei a comprovare la disponibilità delle seguenti risorse professionali, anche se non legate alle medesime da rapporto di lavoro dipendente: a. esperto di fattori umani, b. esperto tecnico, c. esperto di interazione con i soggetti disabili, d. gruppo di valutazione. Articolo 5 (Svolgimento delle verifiche e determinazione degli importi massimi dovuti dai soggetti privati) 1. Gli importi dovuti dai soggetti privati come corrispettivo per l’attività svolta dai valutatori, sono determinati sulla base dei costi sostenuti per lo svolgimento della verifica tecnica e della verifica soggettiva. 2. Nella verifica tecnica l’esperto tecnico, applicando la metodologia di cui all’allegato A, paragrafo 2: a. svolge le attività previste alla lettera a) del medesimo paragrafo 2 su tutte le pagine del sito; b. svolge le attività previste alle lettere b), c) e d) del medesimo paragrafo 2 sulla home page, su tutte le pagine del sito direttamente raggiungibili dalla home page, su tutte le tipologie di pagine che presentano form e di pagine di risposta, nonché su un campione statistico di pagine, non rientranti in quelle esaminate precedentemente, pari al 5% delle stesse; c. redige il rapporto di cui alla lettera e) del medesimo paragrafo 2. 3. La verifica soggettiva consta delle attività, previste dalla metodologia di cui all’allegato B, svolte dall’esperto in fattori umani, dall’esperto di interazione con le persone disabili e dal gruppo di valutazione; il costo complessivo della verifica tiene anche conto dei tempi di utilizzo delle tecnologie assistive impiegate. 4. Ai sensi dell’articolo 3, comma 5, lettera b) del regolamento, gli importi massimi dovuti dai soggetti privati come corrispettivo per l’attività svolta dai valutatori sono riportati nell’Allegato F che costituisce parte integrante del presente decreto. Articolo 6 (Logo attestante il possesso del requisito di accessibilità) 1. Il modello del logo e la corrispondenza tra il logo stesso, eventualmente - 448 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR corredato da asterischi, ed il diverso livello di qualità del servizio sono indicati nell’Allegato E che costituisce parte integrante del presente decreto. Articolo 7 (Utilizzo del logo) 1. La richiesta di autorizzazione ad esporre il logo viene presentata alla Presidenza del Consiglio dei Ministri – Dipartimento per l’innovazione e le tecnologie per via telematica tramite il sito del Centro nazionale per l’informatica nella pubblica amministrazione (Cnipa), ai sensi dell’articolo 4, comma 3 del regolamento. 2. Ai fini del comma 1, i soggetti di cui all’art. 3, comma 1 della legge ed i soggetti privati che intendono esporre il logo attestante il possesso del requisito di accessibilità sul proprio sito Web si registrano preventivamente nell’apposita sezione del sito Web del Cnipa. 3. La richiesta di autorizzazione di cui al comma 1 è corredata dall’attestato di accessibilità, in formato elettronico, relativo ad ogni pagina del sito esaminata, nonché da copia statica, riferita al momento della valutazione, di tutte le pagine analizzate indicate all’articolo 5, comma 2; il modello di attestato di accessibilità è disponibile, per i soggetti registrati, nella citata sezione del sito Web del Cnipa. 4. Ai fini del rilascio o del rinnovo dell’autorizzazione ad esporre il logo, il Cnipa provvede a: a. predisporre una sezione del proprio sito Web per ricevere le richieste di registrazione; b. acquisire la richiesta di autorizzazione di cui al comma 1 e la documentazione di cui al comma 3; c. costituire e tenere aggiornata la banca dati dei soggetti autorizzati ad esporre il logo, dei codici elettronici di riconoscimento rilasciati agli stessi soggetti ai fini della registrazione e della documentazione inerente a ciascuna richiesta di autorizzazione; d. riferire gli esiti dell’istruttoria alla Presidenza del Consiglio dei Ministri – Dipartimento per l’innovazione e le tecnologie. 5. La Presidenza del Consiglio dei Ministri – Dipartimento per l’innovazione e le tecnologie, sulla base dei risultati dell’istruttoria di cui al presente articolo, rilascia l’autorizzazione all’utilizzo del logo, dandone comunicazione al soggetto richiedente. Articolo 8 (Rimborso delle spese amministrative sostenute dalla Presidenza del Consiglio dei Ministri per le attività inerenti l’utilizzo del logo e le funzioni ispettive) 1. I soggetti privati che richiedono l’autorizzazione all’utilizzo del logo allegano alla richiesta la ricevuta del versamento effettuato, anche in via telematica, quale rimborso delle spese amministrative sostenute dalla Presidenza del Consiglio dei Ministri per le attività inerenti il rilascio dell’autorizzazione; l’importo del versamento è indicato nell’Allegato F. 2. Ai sensi dell’articolo 7 del regolamento, in caso di riscontro di un livello di accessibilità inferiore a quello del logo utilizzato sono a carico del soggetto privato i costi effettivi dell’avvenuta ispezione, nonché una quota di - 449 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR partecipazione ai costi per l’espletamento delle funzioni ispettive complessivamente svolte dal Cnipa sui soggetti privati; l’importo della quota, comunque non superiore al doppio del costo effettivo dell’ispezione, è indicato nell’Allegato F. 3. Con decreto del Ministro per l’innovazione e le tecnologie di natura non regolamentare, gli importi di cui ai commi 1 e 2 sono aggiornati annualmente. Requisiti tecnici - Allegato A Verifica tecnica e requisiti tecnici di accessibilità delle applicazioni basate su tecnologie internet 1. Premessa La definizione dei requisiti tecnici di accessibilità nonché l’articolazione delle attività previste per la verifica tecnica sono stabilite sulla base di: a) quanto indicato nelle Recommendation del World Wide Web Consortium (W3C) ed in particolare in quelle del progetto Web Accessibility Initiative (WAI); b) standard definiti nel paragrafo 1194.22 della Sezione 508 del Rehabilitation Act degli USA; c) standard e specifiche tecniche definite in materia di accessibilità dalla International Organization for Standardization (ISO); d) esperienze acquisite nell’ambito della Pubblica Amministrazione ed in particolare, tra quelle già maturate, quelle relative all’attuazione della Circolare AIPA del 6 settembre 2001 recante “Criteri e strumenti per migliorare l'accessibilità dei siti Web e delle applicazioni informatiche a persone disabili” e della Direttiva del Presidente del Consiglio dei Ministri 30 maggio 2002 per la conoscenza e l'uso del dominio internet ".gov.it" e l'efficace interazione del portale nazionale "italia.gov.it" con le pubbliche amministrazioni e le loro diramazioni territoriali. 2. Metodologia per la verifica tecnica La verifica tecnica si articola nelle seguenti attività: a) riscontro, con sistemi di validazione automatica, della rispondenza alla sua definizione formale del linguaggio a marcatori utilizzato; b) verifica dell’esperto tecnico sul corretto utilizzo semantico degli elementi e degli attributi secondo le specifiche del linguaggio a marcatori impiegato, anche mediante l’uso di strumenti semiautomatici di valutazione allo scopo di evidenziare problemi non riscontrabili dalle verifiche automatiche; c) esame della pagina con varie versioni di diversi browser grafici in vari sistemi operativi allo scopo di verificare che: 1) il contenuto informativo e le funzionalità presenti in una pagina siano gli stessi nei vari browser; 2) la presentazione della pagina sia simile nei browser che supportano le tecnologie indicate al requisito n. 1 di cui al paragrafo 4 del presente allegato; 3) il contenuto informativo e le funzionalità della pagina siano ancora fruibili in caso di disattivazione del caricamento delle immagini; 4) i contenuti informativi di eventuali file audio siano fruibili anche in forma testuale; 5) i contenuti della pagina siano fruibili in caso di utilizzo delle funzioni - 450 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR previste dai browser per definire la grandezza dei caratteri; 6) la pagina sia navigabile con il solo uso della tastiera e l’impiego di una normale abilità; 7) i contenuti e le funzionalità della pagina siano ancora fruibili, anche in modalità diverse, in caso di disattivazione di fogli di stile, script e applet ed altri oggetti di programmazione; 8) i contenuti e le funzionalità continuino a essere disponibili con un browser testuale e i medesimi contenuti mantengano il proprio significato d’insieme e la corretta struttura semantica; d) verifica delle differenze di luminosità e di colore tra il testo e lo sfondo secondo i seguenti algoritmi: 1) differenza di luminosità: calcolo della luminosità dei colori di testo e di sfondo con la formula: ((Rosso X 299) + (Verde X 587) + (Blu X 114)) / 1000, in cui Rosso, Verde e Blu sono i valori decimali dei colori; il risultato deve essere non inferiore a 125. 2) differenza di colore: calcolo della differenza di colore con la formula[Max (Rosso1, Rosso2) - Min (Rosso1, Rosso2)] + [Max (Verde1, Verde2) - Min (Verde1, Verde2)] + [Max (Blu1, Blu2) — Min (Blu1, Blu2)], in cui Rosso, Verde e Blu sono i valori decimali dei colori e Max e Min il valore massimo e minimo tra i due presi in considerazione; il risultato deve essere non inferiore a 500; e) redazione di un rapporto nel quale l’esperto tecnico indica la conformità, la non conformità o l’eventuale non applicabilità di ogni singolo requisito della pagina esaminata. 3. Programmi di valutazione assistita Sul mercato sono disponibili numerosi programmi in grado agevolare l’attività di verifica tecnica dell’accessibilità dei siti Web. Tali programmi, in particolare, devono essere in grado di garantire idonee prestazioni a supporto dell’attività dell’esperto tecnico. Degli stessi non viene fornito un puntuale elenco nel presente Allegato; si segnalano, comunque, ai sensi dell’articolo 11, comma 1, lettera b) della legge n. 4 del 2004, il programma automatico fornito dal W3C e i programmi indicati nella lista degli strumenti più diffusi presente nella pagina Evaluation, Repair, and Transformation Tools for Web Content Accessibility dello stesso sito del W3C. 4. Requisiti di accessibilità per i siti Internet Per ciascun requisito viene indicato il numero d’ordine, l’enunciato, il riferimento ai punti di controllo delle Web Content Accessibility Guidelines - versione 1.0 (WCAG 1.0) del W3C-WAI, nonché il riferimento agli standard definiti nella Sezione 508 del “Rehabilitation Act”. I punti di controllo del W3C-WAI e gli standard della Sezione 508 eventualmente richiamati nei singoli requisiti, sono da intendersi soltanto come elementi di riferimento, al fine di consentire un più facile riscontro con gli standard già impiegati e per facilitare l’utilizzo degli strumenti informatici di valutazione della accessibilità attualmente disponibili sul mercato. L’espressione “In sede di prima applicazione”, presente nell’enunciato di alcuni requisiti, consente di effettuare un percorso alternativo di adeguamento di siti pubblici particolarmente complessi. - 451 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Elenco dei requisiti di accessibilità per i siti Internet Requisito n. 1 Enunciato: Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da grammatiche formali pubblicate nelle versioni più recenti disponibili quando sono supportate dai programmi utente. Utilizzare elementi ed attributi in modo conforme alle specifiche, rispettandone l’aspetto semantico. In particolare, per i linguaggi a marcatori HTML (HypertText Markup Language) e XHTML (eXtensible HyperText Markup Language): a) per tutti i siti di nuova realizzazione utilizzare almeno la versione 4.01 dell’HTML o preferibilmente la versione 1.0 dell’XHTML, in ogni caso conDTD (Document Type Definition - Definizione del Tipo di Documento) di tipo Strict; b) per i siti esistenti, in sede di prima applicazione, nel caso in cui non sia possibile ottemperare al punto a) è consentito utilizzare la versione dei linguaggi sopra indicati con DTD Transitional, ma con le seguenti avvertenze: 1) evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è realizzata, elementi ed attributi per definirne le caratteristiche di presentazione della pagina (per esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo, ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per ottenere lo stesso effetto grafico; 2) evitare la generazione di nuove finestre; ove ciò non fosse possibile, avvisare esplicitamente l’utente del cambiamento del focus; 3) pianificare la transizione dell’intero sito alla versione con DTD Strict del linguaggio utilizzato, dandone comunicazione alla Presidenza del Consiglio dei Ministri – Dipartimento per l’innovazione e le tecnologie e al Centro nazionale per l’informatica nella pubblica amministrazione. Riferimenti WCAG 1.0: 3.1, 3.2, 3.5, 3.6, 3.7, 11.1, 11.2 Riferimenti Sec. 508: Non presente Requisito n. 2 Enunciato: Non è consentito l’uso dei frame nella realizzazione di nuovi siti. In sede di prima applicazione, per i siti Web esistenti già realizzati con frame è consentito l’uso di HTML 4.01 o XHTML 1.0 con DTD frameset, ma con le seguenti avvertenze: a) evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è realizzata, elementi ed attributi per definirne le caratteristiche di presentazione della pagina (per esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo, ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per ottenere lo stesso effetto grafico; b) fare in modo che ogni frame abbia un titolo significativo per facilitarne l’identificazione e la navigazione; se necessario, descrivere anche lo scopo dei frame e la loro relazione; + c) pianificare la transizione a XHTML almeno nella versione 1.0 con DTD Strict dell’intero sito dandone comunicazione alla Presidenza del Consiglio dei Ministri – Presidenza del Consiglio dei Ministri – Dipartimento per l’innovazione e le tecnologie e alCentro nazionale per l’informatica nella pubblica amministrazione. Riferimenti WCAG 1.0: 12.1, 12.2 Riferimenti Sec. 508: 1194.22 (i) Requisito n. 3 Enunciato: Fornire una alternativa testuale equivalente per ogni oggetto non di testo - 452 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR presente in una pagina e garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi contenuti equivalenti predisposti; l’alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla funzione esercitata dall’oggetto originale nello specifico contesto. Riferimenti WCAG 1.0: 1.1, 6.2 Riferimenti Sec. 508: 1194.22 (a) Requisito n. 4 Enunciato: Garantire che tutti gli elementi informativi e tutte le funzionalità siano disponibili anche in assenza del particolare colore utilizzato per presentarli nella pagina. Riferimenti WCAG 1.0: 2.1 Riferimenti Sec. 508: 1194.22 (c) Requisito n. 5 Enunciato: Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di intermittenza possano provocare disturbi da epilessia fotosensibile o disturbi della concentrazione, ovvero possano causare il malfunzionamento delle tecnologie assistive utilizzate; qualora esigenze informative richiedano comunque il loro utilizzo, avvertire l’utente del possibile rischio prima di presentarli e predisporre metodi che consentano di evitare tali elementi. Riferimenti WCAG 1.0: 7.1, 7.2, 7.3 Riferimenti Sec. 508: 1194.22 (j) Requisito n. 6 Enunciato: Garantire che siano sempre distinguibili il contenuto informativo (foreground) e lo sfondo (background), ricorrendo a un sufficiente contrasto (nel caso del testo) o a differenti livelli sonori (in caso di parlato con sottofondo musicale); evitare di presentare testi in forma di immagini; ove non sia possibile, ricorrere agli stessi criteri di distinguibilità indicati in precedenza. Riferimenti WCAG 1.0: 2.2 Riferimenti Sec. 508: non presente Requisito n. 7 Enunciato: Utilizzare mappe immagine sensibili di tipo lato client piuttosto che lato server, salvo il caso in cui le zone sensibili non possano essere definite con una delle forme geometriche predefinite indicate nella DTD adottata. Riferimenti WCAG 1.0: 9.1 Riferimenti Sec. 508: 1194.22 (f) Requisito n. 8 Enunciato: In caso di utilizzo di mappe immagine lato server, fornire i collegamenti di testo alternativi necessari per ottenere tutte le informazioni o i servizi raggiungibili interagendo direttamente con la mappa. Riferimenti WCAG 1.0: 1.2 Riferimenti Sec. 508: 1194.22 (e) Requisito n. 9 Enunciato: Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti dalla DTD adottata per descrivere i contenuti e identificare le intestazioni di righe e colonne. - 453 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Riferimenti WCAG 1.0: 5.1, 5.5, 5.6 Riferimenti Sec. 508: 1194.22 (g) Requisito n. 10 Enunciato: Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti nella DTD adottata per associare le celle di dati e le celle di intestazione che hanno due o più livelli logici di intestazione di righe o colonne. Riferimenti WCAG 1.0: 5.2 Riferimenti Sec. 508: 1194.22 (h) Requisito n. 11 Enunciato: Usare i fogli di stile per controllare la presentazione dei contenuti e organizzare le pagine in modo che possano essere lette anche quando i fogli di stile siano disabilitati o non supportati. Riferimenti WCAG 1.0: 3.3, 6.1 Riferimenti Sec. 508: 1194.22 (d) Requisito n. 12 Enunciato: La presentazione e i contenuti testuali di una pagina devono potersi adattare alle dimensioni della finestra del browser utilizzata dall’utente senza sovrapposizione degli oggetti presenti o perdita di informazioni tali da rendere incomprensibile il contenuto, anche in caso di ridimensionamento, ingrandimento o riduzione dell’area di visualizzazione o dei caratteri rispetto ai valori predefiniti di tali parametri. Riferimenti WCAG 1.0: 3.4 Riferimenti Sec. 508: non presente Requisito n. 13 Enunciato: In caso di utilizzo di tabelle a scopo di impaginazione, garantire che il contenuto della tabella sia comprensibile anche quando questa viene letta in modo linearizzato e utilizzare gli elementi e gli attributi di una tabella rispettandone il valore semantico definito nella specifica del linguaggio a marcatori utilizzato. Riferimenti WCAG 1.0: 5.3, 5.4 Riferimenti Sec. 508: non presente Requisito n. 14 Enunciato: Nei moduli (form), associare in maniera esplicita le etichette ai rispettivi controlli, posizionandole in modo che sia agevolata la compilazione dei campi da parte di chi utilizza le tecnologie assistive. Riferimenti WCAG 1.0: 10.2, 12.4 Riferimenti Sec. 508: 1194.22 (n) Requisito n. 15 Enunciato: Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati; ove ciò non sia possibile fornire una spiegazione testuale della funzionalità svolta e garantire una alternativa testuale equivalente, in modo analogo a quanto indicato nel requisito n. 3. Riferimenti WCAG 1.0: 6.3 Riferimenti Sec. 508: 1194.22 (l),1194.22 (m) Requisito n. 16 Enunciato: Garantire che i gestori di eventi che attivano script, applet o altri oggetti - 454 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR di programmazione o che possiedono una propria specifica interfaccia, siano indipendenti da uno specifico dispositivo di input. Riferimenti WCAG 1.0: 6.4, 9.2, 9.3 Riferimenti Sec. 508: 1194.22 (l),1194.22 (m) Requisito n. 17 Enunciato: Garantire che le funzionalità e le informazioni veicolate per mezzo di oggetti di programmazione, oggetti che utilizzano tecnologie non definite da grammatiche formali pubblicate, script e applet siano direttamente accessibili. Riferimenti WCAG 1.0:8.1 Riferimenti Sec. 508: 1194.22 (l),1194.22 (m) Requisito n. 18 Enunciato: Nel caso in cui un filmato o una presentazione multimediale siano indispensabili per la completezza dell’informazione fornita o del servizio erogato, predisporre una alternativa testuale equivalente, sincronizzata in forma di sottotitolazione o di descrizione vocale, oppure fornire un riassunto o una semplice etichetta per ciascun elemento video o multimediale tenendo conto del livello di importanza e delle difficoltà di realizzazione nel caso di trasmissioni in tempo reale. Riferimenti WCAG 1.0: 1.3, 1.4 Riferimenti Sec. 508: 1194.22 (b) Requisito n. 19 Enunciato: Rendere chiara la destinazione di ciascun collegamento ipertestuale (link) con testi significativi anche se letti indipendentemente dal proprio contesto oppure associare ai collegamenti testi alternativi che possiedano analoghe caratteristiche esplicative, nonché prevedere meccanismi che consentano di evitare la lettura ripetitiva di sequenze di collegamenti comuni a più pagine. Riferimenti WCAG 1.0: 13.1, 13.6 Riferimenti Sec. 508: 1194.22 (o) Requisito n. 20 Enunciato: Nel caso che per la fruizione del servizio erogato in una pagina è previsto un intervallo di tempo predefinito entro il quale eseguire determinate azioni, è necessario avvisare esplicitamente l’utente, indicando il tempo massimo consentito e le alternative per fruire del servizio stesso. Riferimenti WCAG 1.0: 7.4, 7.5 Riferimenti Sec. 508: 1194.22 (p) Requisito n. 21 Enunciato: Rendere selezionabili e attivabili tramite comandi da tastiere o tecnologie in emulazione di tastiera o tramite sistemi di puntamento diversi dal mouse i collegamenti presenti in una pagina; per facilitare la selezione e l’attivazione dei collegamenti presenti in una pagina è necessario garantire che la distanza verticale di liste di link e la spaziatura orizzontale tra link consecutivi sia di almeno 0,5 em, le distanze orizzontale e verticale tra i pulsanti di un modulo sia di almeno 0,5 em e che le dimensioni dei pulsanti in un modulo siano tali da rendere chiaramente leggibile l’etichetta in essi contenuta. Riferimenti WCAG 1.0: non presente Riferimenti Sec. 508: non presente - 455 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Requisito n. 22 Enunciato: Per le pagine di siti esistenti che non possano rispettare i suelencati requisiti (pagine non accessibili), in sede di prima applicazione, fornire il collegamento a una pagina conforme a tali requisiti, recante informazioni e funzionalità equivalenti a quelle della pagina non accessibile ed aggiornata con la stessa frequenza, evitando la creazione di pagine di solo testo; il collegamento alla pagina conforme deve essere proposto in modo evidente all’inizio della pagina non accessibile. Riferimenti WCAG 1.0: 11.4 Riferimenti Sec. 508: 1194.22 (k) Requisiti tecnici - Allegato B Metodologia e criteri di valutazione per la verifica soggettiva dell’accessibilità delle applicazioni basate su tecnologie internet 1. Metodologia per la verifica soggettiva La metodologia di verifica soggettiva delle applicazioni basate su tecnologie internet si articola in quattro principali fasi: a) Analisi da parte di uno o più esperti di fattori umani La valutazione da parte di uno o più esperti di fattori umani consiste essenzialmente nel metodo della simulazione cognitiva attraverso il quale l’esperto definisce contesti, scopi e modi di interazione dell’utente, presente nel gruppo di valutazione, con il sito e costruisce scenari d’uso che simulano a livello cognitivo il comportamento dell’utente. L’esperto di fattori umani conosce i servizi che il sito intende erogare, le informazioni che può fornire, le azioni richieste all’utente per raggiungere tali obiettivi per mezzo dell’interfaccia, nonché le informazioni sugli utenti potenziali e sulla esperienza e conoscenza a loro richieste per interagire con il sito. Questa parte della valutazione, in coerenza con quanto già effettuato in fase di progettazione, è finalizzata ad assegnare a ciascuno dei criteri indicati, ove applicabili, un giudizio su una scala crescente di valori da 1 a 5 in cui: 1. corrisponde a nessuna rispondenza dell’ambiente al criterio in esame; 2. corrisponde a poca rispondenza dell’ambiente al criterio in esame; 3. corrisponde a sufficiente rispondenza dell’ambiente al criterio in esame; 4. corrisponde a molta rispondenza dell’ambiente al criterio in esame; 5. corrisponde a moltissima rispondenza dell’ambiente al criterio in esame. b) Costituzione del gruppo di valutazione La seconda parte della valutazione prevede la costituzione del gruppo di valutazione i cui componenti disabili utilizzano le proprie tecnologie assistive; fanno parte del gruppo di valutazione utenti rappresentativi dei diversi tipi di disabilità: sordità, ipovisione, daltonismo, cecità, disabilità motoria agli arti superiori, distrofia spastica, disabilità cognitiva, nonché soggetti appartenenti a diverse categorie di utenti interessate ad accedere al sito. c) Esecuzione dei task da parte del gruppo di valutazione L’esecuzione dei task da parte dei componenti del gruppo di valutazione avviene sia in contesti usuali (casa, ambiente di lavoro), sia in contesti appositamente costituiti (ambiente di laboratorio). Il gruppo di valutazione esegue una serie di prove basate sulla interazione con l’ambiente. Le prove vengono svolte in forma libera, cioè senza compiti specifici, - 456 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR ovvero per obiettivi, se eseguite secondo compiti specifici. Nella esecuzione delle prove, il gruppo di valutazione è guidato dall’esperto di fattori umani. Nel corso della navigazione libera, l’esperto raccoglie i commenti dell’utente, anche verbali, e le osservazioni sul suo comportamento. Nella prova su compiti specifici, l’esperto registra il tipo di compito, la quantità di tempo impiegata per svolgerlo e gli eventuali errori commessi ed annota i commenti dell’utente e le osservazioni sul suo comportamento. d) Valutazione dei risultati ed elaborazione del rapporto conclusivo La verifica soggettiva si conclude con la predisposizione di un rapporto nel quale l’esperto di fattori umani indica la valutazione su scale soggettive ricavata dalla simulazione cognitiva dallo stesso effettuata, le proprie considerazioni sulle caratteristiche qualitative del sito, i dati relativi alle prestazioni degli utenti in relazione ai compiti affidati: performance, commenti, osservazioni comportamentali le risposte a questionari di valutazione compilati dagli utenti la valutazione complessiva del livello di qualità raggiunto secondo il seguente schema: 1. valore medio complessivo minore di 2 = assenza di qualità; 2. valore medio complessivo maggiore o uguale a 2 e minore di 3 = primo livello di qualità; 3. valore medio complessivo maggiore o uguale a 3 e minore di 4 = secondo livello di qualità; 4. valore medio complessivo maggiore o uguale a 4 = terzo livello di qualità. 2. Criteri di valutazione I criteri essenziali su cui basare la verifica soggettiva dei siti Web e delle applicazioni realizzate con tecnologie Internet sono: 1. percezione: informazioni e comandi necessari per l’esecuzione dell’attività devono essere sempre disponibili e percettibili; 2. comprensibilità: informazioni e comandi necessari per l’esecuzione delle attività devono essere facili da capire e da usare; 3. operabilità: informazioni e comandi devono consentire una scelta immediata della azione adeguata per raggiungere l’obiettivo voluto; 4. coerenza: simboli, messaggi e azioni devono avere lo stesso significato in tutto l’ambiente; 5. salvaguardia della salute (safety): l’ambiente deve possedere caratteristiche idonee a salvaguardare il benessere psicofisico dell’utente; 6. sicurezza: l’ambiente deve possedere caratteristiche idonee a fornire transazioni e dati affidabili, gestiti con adeguati livelli di sicurezza; 7. trasparenza: l’ambiente deve comunicare all’utente lo stato, gli effetti delle azioni compiute e le informazioni necessarie per la corretta valutazione della dinamica dell’ambiente stesso; 8. apprendibilità: l’ambiente deve possedere caratteristiche di utilizzo di facile e rapido apprendimento; 9. aiuto e documentazione: funzioni di aiuto, quali le guide in linea, e documentazione relativa al funzionamento dell’ambiente devono essere di facili reperimento e connesse al compito svolto dall’utente; 10. tolleranza agli errori: l’ambiente, pur configurandosi in modo da prevenire gli errori, ove questi, comunque, si manifestino, deve fornire appropriati messaggi che individuino chiaramente l’errore occorso e le azioni necessarie per superarlo; 11. gradevolezza: l’ambiente deve possedere caratteristiche idonee a favorire e - 457 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR mantenere l’interesse dell’utente; 12. flessibilità: l’ambiente deve tener conto delle preferenze individuali e dei contesti. - 458 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR VII.4 - WCAG 2.0 Web Content Accessibility Guidelines 2.0 W3C Working Draft 27 April 2006 […] Abstract Web Content Accessibility Guidelines 2.0 (WCAG 2.0) covers a wide range of issues and recommendations for making Web content more accessible. This document contains principles, guidelines, and success criteria that define and explain the requirements for making Web-based information and applications accessible. "Accessible" means usable to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, photosensitivity and combinations of these. Following these guidelines will also make your Web content more accessible to the vast majority of users, including older users. It will also enable people to access Web content using many different devices - including a wide variety of assistive technologies. WCAG 2.0 success criteria are written as testable statements that are not technologyspecific. Guidance about satisfying the success criteria in specific technologies as well as general information about interpreting the success criteria are provided in separate documents. An Overview of Web Content Accessibility Guidelines (WCAG) 2.0 Last Call Documents is also available. Until WCAG 2.0 advances to W3C Recommendation, the current and referenceable document is Web Content Accessibility Guidelines 1.0 (WCAG 1.0), published as a W3C Recommendation May 1999. […] Table of Contents    Introduction o Related Documents o Authoring tools o The Role of User Agents o The Four Principles of Accessibility o Important New Terms Used in WCAG 2.0 Conformance o Technology assumptions and the "baseline" o Conformance levels and the baseline o Conformance claims o Content that conforms to WCAG 1.0 o How to refer to WCAG 2.0 from other documents WCAG 2.0 Guidelines o Principle 1: Content must be perceivable.  Guideline 1.1 Provide text alternatives for all non-text content - 459 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR  Guideline 1.2 Provide synchronized alternatives for multimedia  Guideline 1.3 Ensure that information and structure can be separated from presentation  o Guideline 1.4 Make it easy to distinguish foreground information from its background Principle 2: Interface components in the content must be operable  Guideline 2.1 Make all functionality operable via a keyboard interface  Guideline 2.2 Allow users to control time limits on their reading or interaction  Guideline 2.3 Allow users to avoid content that could cause seizures due to photosensitivity  Guideline 2.4 Provide mechanisms to help users find content, orient themselves within it, and navigate through it  o Guideline 2.5 Help users avoid mistakes and make it easy to correct mistakes that do occur Principle 3: Content and controls must be understandable  Guideline 3.1 Make text content readable and understandable.  Guideline 3.2 Make the placement and functionality of content predictable. o Principle 4: Content should be robust enough to work with current and future user agents (including assistive technologies)  Guideline 4.1 Support compatibility with current and future user agents (including assistive technologies)  Guideline 4.2 Ensure that content is accessible or provide an accessible alternative  Appendices o Appendix A: Glossary (Normative) o Appendix B: Checklist o Appendix C: Acknowledgements o Appendix D: Comparison of WCAG 1.0 checkpoints to WCAG 2.0 o Appendix E: References Introduction This section is informative. You are reading the Web Content Accessibility Guidelines (WCAG) version 2.0. This is the central document that defines the requirements for making Web content accessible to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, and others. Following these guidelines will also make your Web content more usable to many other users, including older users. It will also enable people to access Web content using many different devices - including a wide variety of assistive technologies and mobile technologies. WCAG 2.0 covers a wide range of recommendations for making Web content more accessible. The guidelines do not include standard usability recommendations except where they have specific impact on accessibility. - 460 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR The WCAG 2.0 document itself consists of:  This introduction  Information about conformance to WCAG 2.0  Guidelines with success criteria for each guideline  "How to meet" links to information on intent, sufficient techniques, examples, and benefits for each success criterion  A link to information about the Working Group's approach to defining baseline assumptions about the technologies that are available to end users  Appendices containing definitions, a checklist, references, and other support information. […] Authoring tools A large part of Web content is created using authoring tools. These tools often determine how Web content is implemented, either by making authoring decisions directly or by limiting the choices available to the author. As a result, authoring tools will play an important role in creating Web content that conforms to the Web Content Accessibility Guidelines. At the same time, we recommend that all authors become familiar with the Guidelines because this will help in creating accessible content and coverage of the Guidelines may vary between tools. Developers of authoring tools can make their tools aware of the Web Content Accessibility Guidelines by following the Authoring Tool Accessibility Guidelines. The working group encourages users and purchasers of authoring tools to consider conformance to the Authoring Tool Accessibility Guidelines as a criterion when selecting tools. The current version at WCAG 2.0's release is Authoring Tool Accessibility Guidelines 1.0. However, version 2.0 is nearing completion and it is based on WCAG 2.0. The latest version of the Authoring Tool Accessibility Guidelines 2.0 can be found at http://www.w3.org/TR/ATAG20. The Role of User Agents Web content is always rendered by a user agent. A user agent is any software that retrieves and renders Web content for users and includes assistive technologies. Web content that conforms to WCAG 2.0 is most likely to be rendered correctly by user agents that conform to the User Agent Accessibility Guidelines (UAAG). For more information about the relationship between WCAG 2.0 and other WAI accessibility guidelines, see Essential Components of Web Accessibility. The Four Principles of Accessibility The WCAG 2.0 Guidelines are organized around the following four principles: 1. Content must be perceivable 2. Interface components in the content must be operable 3. Content and controls must be understandable 4. Content should be robust enough to work with current and future user agents (including assistive technologies) These four principles lay the foundation necessary for anyone to access and use Web content. WCAG 2.0 offers information about how to increase the ability of people with - 461 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR disabilities to perceive, operate, and understand Web content. Under each principle there is a list of guidelines that address the principle. Under each guideline there are success criteria used to evaluate conformance to this standard for that guideline. The success criteria are written as statements that will be either true or false when specific Web content is tested against the success criteria. The success criteria are grouped into three levels of conformance, each representing a higher level of accessibility for that guideline. The principles, guidelines, and success criteria represent concepts that address accessibility issues and needs, regardless of the technology used. They are not specific to HTML, XML, or any other technology. This approach makes it possible to apply WCAG 2.0 to a variety of situations and technologies, including those that do not yet exist. The principles and guidelines give direction and guidance to Web authors. The success criteria are written as true/false statements so that they can be used in determining conformance. Only the success criteria are testable. Important New Terms Used in WCAG 2.0 WCAG 2.0 includes several important new terms. These terms are defined in the Glossary ( Appendix A: Glossary ), and links to the definitions are provided whenever these and other important terms are used in the success criteria. The terms are introduced briefly here to make this new vocabulary easier to understand. "Web unit" is one of these important new terms. Web pages are the most common type of Web unit. The broader term was chosen because it covers Web applications and other types of content to which the word "page" may not apply. A Web unit is any collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as a URL). For example, A Web page containing several images and a style sheet is a typical Web unit. Several success criteria require that content (or certain aspects of content) can be "programmatically determined." This means that the author is responsible for ensuring that the content is delivered in such a way that software can access it. This is important in order to allow assistive technologies to recognize it and present it to the user, even if the user requires a different sensory modality than the original. For example, some assistive technologies convert text into speech or Braille. This will also allow content in the future to be translated into simpler forms for people with cognitive disabilities, or to allow access by other agent based technologies. This can happen only if the content itself can be programmatically determined. WCAG 2.0 also introduces the term "baseline” which allows WCAG 2.0 to adapt to changing technologies and to the needs of different countries and environments. Baselines are described in more detail in the conformance section and in About Baselines for WCAG 2.0. Conformance This section is normative. Conformance means that Web content satisfies the success criteria defined in this document. This section outlines the conformance scheme used throughout this document. - 462 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR The success criteria for each guideline are organized into three (3) levels.  Level 1 success criteria: 1. Achieve a minimum level of accessibility. 2. Can reasonably be applied to all Web content.  Level 2 success criteria: 1. Achieve an enhanced level of accessibility. 2. Can reasonably be applied to all Web content.  Level 3 success criteria: 1. Achieve additional accessibility enhancements. 2. Can not necessarily be applied to all Web content. Note 1: Because not all level 3 success criteria can be used with all types of content, Triple-A conformance only requires conformance to a portion of level 3 success criteria. Note 2: Guidelines do not necessarily contain success criteria at every level. Some have success criteria at only one level. This method of grouping success criteria differs in important ways from the approach taken in WCAG 1.0. Each checkpoint in WCAG 1.0 was assigned a "priority" according to its impact on accessibility. Thus, Priority 3 checkpoints appeared to be less important than Priority 1 checkpoints. The WCAG Working Group believes that all success criteria of WCAG 2.0 are essential for some people. Thus, the system of checkpoints and priorities used in WCAG 1.0 has been replaced by success criteria under Levels 1, 2, and 3 as described above. Note that even conformance to all three levels will not make Web content accessible to all people. All WCAG 2.0 success criteria are testable. While some can be tested by computer programs, others must be tested by qualified human testers. Sometimes, a combination of computer programs and qualified human testers may be used. When people who understand WCAG 2.0 test the same content using the same success criteria, the same results should be obtained with high inter-rater reliability. Note: For each success criterion, there is a list of techniques deemed by the Working Group to be sufficient to meet the requirement. For each technique, there is a test to determine whether the technique has been successfully implemented. If the test(s) for a "sufficient" technique or combination of techniques is passed, then the Working Group would consider that success criterion met. However, passing all tests for all techniques is not necessary. Nor is it necessary to meet a success criterion using one of the sufficient techniques. There may be other techniques which are not documented by the working group that would also meet the success criterion. Technology assumptions and the "baseline" WCAG 2.0 defines accessibility guidelines (goals) and success criteria (testable criteria for conformance at different levels of accessibility). The guidelines and success criteria are described in a technology-independent way in order to allow conformance using any Web technology that supports accessibility. WCAG 2.0, therefore, does not require or prohibit the use of any specific technology. It is possible to conform to WCAG 2.0 using both W3C and non-W3C technologies, as long as the technologies are supported by accessible user agents, including assistive technologies. - 463 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR WCAG 2.0 uses the term user agent to mean: Any software that retrieves and renders Web content for users. This may include Web browsers, media players, plug-ins, and other programs - including assistive technologies - that help in retrieving and rendering Web content. It is important to note that assistive technologies are included in this definition. Assistive technologies include screen-readers, screen magnifiers, on-screen and alternative keyboards, single switches, voice recognition, and a wide variety of input and output devices that meet the needs of people with disabilities. Choosing baseline technologies In choosing Web technologies (HTML, scripting, etc.) that will be used when building content, authors need to know what technologies they can assume will be supported by, and active in, the user agents (including assistive technologies) that people with disabilities will be using. If authors rely on technologies that are not supported, then their content may not be accessible. The set of such technologies that an author assumes are supported and turned on in accessible user agents is called a baseline. Authors must ensure that all information and functionality of the Web content conforms to WCAG 2.0 assuming that user agents support all of the technologies in the baseline and that they are enabled. Non-baseline technologies can also be used, but all information and functionality of the Web content must conform both with all non-baseline technologies turned on and with the technologies turned off. Both conditions are necessary since some users many have browsers that support them while others may not. […] Conformance levels and the baseline WCAG 2.0 conformance at level A means that all Level 1 success criteria in the guidelines are met assuming user agent support for only the technologies in the specified baseline. WCAG 2.0 conformance at level Double-A (AA) means that all Level 1 and all Level 2 success criteria in the guidelines are met assuming user agent support for only the technologies in the specified baseline. WCAG 2.0 conformance at level Triple-A (AAA) means that all Level 1, Level 2 and at least half (50%) of the Level 3 success criteria that apply to the content types used are met assuming user agent support for only the technologies in the specified baseline. If a success criterion relates to a feature, component or type of content that is not used in the content (for example, there is no multimedia on the site), then that success criterion is met automatically. […] Content that conforms to WCAG 1.0 This Working Draft of WCAG 2.0 builds upon WCAG 1.0 and reflects feedback received since the publication of WCAG 1.0 in May 1999. - 464 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR The Web Content Accessibility Guidelines Working Group is working to ensure that organizations and individuals who are currently using WCAG 1.0 (which remains stable and normative at this time) will be able to smoothly transition to WCAG 2.0. For more information about the similarities and differences between WCAG 1.0 Checkpoints and WCAG 2.0 Guidelines and success criteria, please refer to Appendix D: Comparison of WCAG 1.0 checkpoints to WCAG 2.0 . Authors whose content currently conforms to WCAG 1.0 may wish to capitalize on past accessibility efforts when making the transition to WCAG 2.0. A qualified conformance statement could allow them this flexibility. For example, a conformance claim might include the following statement: "Materials with creation or modification dates before 31 December 2006 conform to WCAG 1.0 Level AA. Materials with creation or modification dates after 31 December 2006 conform to WCAG 2.0 Level AA." […] WCAG 2.0 Guidelines This section is normative. Principle 1: Content must be perceivable. Guideline 1.1 Provide text alternatives for all non-text content Level 1 Success Criteria for Guideline 1.1 1.1.1 For all non-text content, one of the following is true: If non-text content presents information or responds to user input, text alternatives serve the same purpose and present the same information as the non-text content. If text alternatives cannot serve the same purpose, then text alternatives at least identify the purpose of the non-text content. If non-text content is multimedia; live audio-only or live video-only content; a test or exercise that must use a particular sense; or primarily intended to create a specific sensory experience; then text alternatives at least identify the non-text content with a descriptive text label. (For multimedia, see also Guideline 1.2 Provide synchronized alternatives for multimedia .) If the purpose of non-text content is to confirm that content is being operated by a person rather than a computer, different forms are provided to accommodate multiple disabilities. If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, it is implemented such that it can be ignored by assistive technology. Level 2 Success Criteria for Guideline 1.1 (No level 2 success criteria for this guideline.) Level 3 Success Criteria for Guideline 1.1 (No level 3 success criteria for this guideline.) Guideline 1.2 Provide synchronized alternatives for multimedia Level 1 Success Criteria for Guideline 1.2 1.2.1 Captions are provided for prerecorded multimedia. 1.2.2 Audio descriptions of video, or a full multimedia text alternative including any - 465 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR interaction, are provided for prerecorded multimedia. Level 2 Success Criteria for Guideline 1.2 1.2.3 Audio descriptions of video are provided for prerecorded multimedia. 1.2.4 Captions are provided for live multimedia. Level 3 Success Criteria for Guideline 1.2 1.2.5 Sign language interpretation is provided for multimedia. 1.2.6 Extended audio descriptions of video are provided for prerecorded multimedia. 1.2.7 For prerecorded multimedia, a full multimedia text alternative including any interaction is provided. Guideline 1.3 Ensure that information and structure can be separated from presentation Level 1 Success Criteria for Guideline 1.3 1.3.1 Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies. 1.3.2 Any information that is conveyed by color is also visually evident without color. 1.3.3 When the sequence of the content affects its meaning, that sequence can be programmatically determined. Level 2 Success Criteria for Guideline 1.3 1.3.4 Information that is conveyed by variations in presentation of text is also conveyed in text, or the variations in presentation of text can be programmatically determined. 1.3.5 Information required to understand and operate content does not rely on shape, size, visual location, or orientation of components. Level 3 Success Criteria for Guideline 1.3 (No level 3 success criteria for this guideline.) Guideline 1.4 Make it easy to distinguish foreground information from its background Level 1 Success Criteria for Guideline 1.4 (No level 1 success criteria for this guideline.) Level 2 Success Criteria for Guideline 1.4 1.4.1 Text or diagrams, and their background, have a luminosity contrast ratio of at least 5:1. 1.4.2 A mechanism is available to turn off background audio that plays automatically, without requiring the user to turn off all audio. Level 3 Success Criteria for Guideline 1.4 1.4.3 Text or diagrams, and their background, have a luminosity contrast ratio of at least 10:1. - 466 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 1.4.4 Audio content does not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground audio content, with the exception of occasional sound effects. Note: A 20 decibel difference in sound level is roughly four times (4x) quieter or louder. Background sound that meets this requirement will be approximately four times (4x) quieter than the foreground audio content. Principle 2: Interface components in the content must be operable Guideline 2.1 Make all functionality operable via a keyboard interface Level 1 Success Criteria for Guideline 2.1 2.1.1 All functionality of the content is operable in a non-time-dependent manner through a keyboard interface, except where the task requires analog, time-dependent input. Note: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation. Level 2 Success Criteria for Guideline 2.1 (No level 2 success criteria for this guideline.) Level 3 Success Criteria for Guideline 2.1 2.1.2 All functionality of the content is operable in a non-time-dependent manner through a keyboard interface. Guideline 2.2 Allow users to control time limits on their reading or interaction Level 1 Success Criteria for Guideline 2.2 2.2.1 For each time-out that is a function of the content, at least one of the following is true: the user is allowed to deactivate the time-out; or the user is allowed to adjust the time-out over a wide range that is at least ten times the length of the default setting; or the user is warned before time expires and given at least 20 seconds to extend the timeout with a simple action (for example, "hit any key"), and the user is allowed to extend the timeout at least ten times; or the time-out is an important part of a real-time event (for example, an auction), and no alternative to the time-out is possible; or the time-out is part of an activity where timing is essential (for example, competitive gaming or time-based testing) and time limits can not be extended further without invalidating the activity. Level 2 Success Criteria for Guideline 2.2 2.2.2 Content does not blink for more than three seconds, or a method is available to stop all blinking content in the Web unit or authored component. Note: For requirements related to flickering or flashing content, refer to Guideline 2.3 Allow users to avoid content that could cause seizures due to photosensitivity . 2.2.3 Content can be paused by the user unless the timing or movement is part of an activity where timing or movement is essential. - 467 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Level 3 Success Criteria for Guideline 2.2 2.2.4 Except for real-time events, timing is not an essential part of the event or activity presented by the content. 2.2.5 Interruptions, such as updated content, can be postponed or suppressed by the user, except interruptions involving an emergency. 2.2.6 When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. Guideline 2.3 Allow users to avoid content that could cause seizures due to photosensitivity Level 1 Success Criteria for Guideline 2.3 2.3.1 Content does not violate the general flash threshold or the red flash threshold. Level 2 Success Criteria for Guideline 2.3 (No level 2 success criteria for this guideline.) Level 3 Success Criteria for Guideline 2.3 2.3.2 Web units do not contain any components that flash more than three times in any 1second period. Guideline 2.4 Provide mechanisms to help users find content, orient themselves within it, and navigate through it Level 1 Success Criteria for Guideline 2.4 2.4.1 A mechanism is available to bypass blocks of content that are repeated on multiple Web units. Level 2 Success Criteria for Guideline 2.4 2.4.2 More than one way is available to locate content within a set of Web units where content is not the result of, or a step in, a process or task. 2.4.3 Web units have titles. 2.4.4 Each link is programmatically associated with text from which its purpose can be determined. Level 3 Success Criteria for Guideline 2.4 2.4.5 Titles, headings, and labels are descriptive. 2.4.6 When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content. 2.4.7 Information about the user's location within a set of Web units is available. 2.4.8 The purpose of each link can be programmatically determined from the link. Guideline 2.5 Help users avoid mistakes and make it easy to correct mistakes that do occur Level 1 Success Criteria for Guideline 2.5 - 468 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR 2.5.1 If an input error is detected, the error is identified and described to the user in text. Level 2 Success Criteria for Guideline 2.5 2.5.2 If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user. 2.5.3 For forms that cause legal or financial transactions to occur, that modify or delete data in data storage systems, or that submit test responses, at least one of the following is true: Actions are reversible. Actions are checked for input errors before going on to the next step in the process. The user is able to review and confirm or correct information before submitting it. Level 3 Success Criteria for Guideline 2.5 2.5.4 Context-sensitive help is available for text input. Principle 3: Content and controls must be understandable Guideline 3.1 Make text content readable and understandable. Level 1 Success Criteria for Guideline 3.1 3.1.1 The primary natural language or languages of the Web unit can be programmatically determined. Level 2 Success Criteria for Guideline 3.1 3.1.2 The natural language of each passage or phrase in the Web unit can be programmatically determined. Note: This requirement does not apply to individual words or phrases that have become part of the primary language of the content. Level 3 Success Criteria for Guideline 3.1 3.1.3 A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idiOMS and jargon. 3.1.4 A mechanism for finding the expanded form of abbreviations is available. 3.1.5 When text requires reading ability more advanced than the lower secondary education level, supplemental content is available that does not require reading ability more advanced than the lower secondary education level. 3.1.6 A mechanism is available for identifying specific pronunciation of words where meaning cannot be determined without pronunciation. Guideline 3.2 Make the placement and functionality of content predictable. Level 1 Success Criteria for Guideline 3.2 3.2.1 When any component receives focus, it does not cause a change of context. 3.2.2 Changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order), unless the authored unit contains instructions before the control that describe the behavior. - 469 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Level 2 Success Criteria for Guideline 3.2 3.2.3 Navigational mechanisms that are repeated on multiple Web units within a set of Web units or other primary resources occur in the same relative order each time they are repeated, unless a change is initiated by the user. 3.2.4 Components that have the same functionality within a set of Web units are identified consistently. Level 3 Success Criteria for Guideline 3.2 3.2.5 Changes of context are initiated only by user request. Principle 4: Content should be robust enough to work with current and future user agents (including assistive technologies) Guideline 4.1 Support compatibility with current and future user agents (including assistive technologies) Level 1 Success Criteria for Guideline 4.1 4.1.1 Web units or authored components can be parsed unambiguously, and the relationships in the resulting data structure are also unambiguous. 4.1.2 For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies. Level 2 Success Criteria for Guideline 4.1 (No level 2 success criteria for this guideline.) Level 3 Success Criteria for Guideline 4.1 (No level 3 success criteria for this guideline.) Guideline 4.2 Ensure that content is accessible or provide an accessible alternative Level 1 Success Criteria for Guideline 4.2 4.2.1 At least one version of the content meets all level 1 success criteria, but alternate version(s) that do not meet all level 1 success criteria may be available from the same URI. 4.2.2 Content meets the following criteria even if the content uses a technology that is not in the chosen baseline: If content can be entered using the keyboard, then the content can be exited using the keyboard. Content conforms to success criterion 2.3.1 (general and red flash). Level 2 Success Criteria for Guideline 4.2 4.2.3 At least one version of the content meets all level 2 success criteria, but alternate version(s) that do not meet all level 2 success criteria may be available from the same URI. Level 3 Success Criteria for Guideline 4.2 4.2.4 Content implemented using technologies outside of the chosen baseline satisfies - 470 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR all Level 1 and Level 2 requirements supported by the technologies. […] - 471 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR VIII. Glossario La maggior parte di queste voci sono tratte da “Wikipedia: l’enciclopedia libera” 1, consultabile direttamente in internet. In alternativa ho riportato le voci non trovate reperendole dai glossari allegati alle normative citate. Per completezza ho ritenuto opportuno citare anche il glossario delle WCAG 1.0, ricordando che anche le WCAG 2.0 possiedono un proprio glossario, non incluso in questa tesi per ragioni di spazio. Per gli integrali di entrambe i glossari originali WAI è possibile accedere alle risorse Web:  WCAG 1.0: http://www.w3.org/TR/WCAG10/#glossary.  WCAG 2.0: http://www.w3.org/TR/WCAG20/appendixA.html. VIII.1 - Glossario generale Accessibilità L'Accessibilità, in informatica, è la capacità di un servizio o di una risorsa d'essere fruibile con facilità da una qualsiasi categoria d'utente. Il termine è comunemente associato alla possibilità anche per persone con ridotta o impedita capacità sensoriale, motoria, o psichica, di fruire dei sistemi informatici e delle risorse software a disposizione. Il termine ha trovato largo uso anche nel settore di Internet col medesimo significato. AJAX Acronimo di Asynchronous JavaScript and XML, è una tecnica di sviluppo Web per creare applicazioni Web interattive. L'intento è ottenere pagine Web più responsive scambiando piccoli pacchetti di dati con il server dietro le quinte, così che l'intera pagina Web non debba essere ricaricata ogni volta che l'utente fa una modifica Browser Un Web Browser (sfogliatore di documenti Web, chiamato talvolta navigatore) è un programma in grado di interpretare il codice HTML (e più recentemente XHTML) e visualizzarlo in forma di ipertesto. L'HTML è il codice col quale la maggioranza delle 1 [http://it.wikipedia.org/wiki/Pagina_principale] - 472 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR pagine Web nel mondo sono composte: il Web browser consente perciò la navigazione nel Web CMS Content Management System (CMS in acronimo), letteralmente "sistema di gestione dei contenuti" è una categoria di sistemi software per organizzare e facilitare la creazione collaborativa di documenti e altri contenuti CNIPA Il Centro Nazionale per l'Informatica nella Pubblica Amministrazione (CNIPA), è un ente pubblico italiano che opera presso la Presidenza del Consiglio dei Ministri per l'attuazione delle politiche del Ministro per l'Innovazione e le tecnologie, dotato di autonomia tecnica, funzionale, amministrativa, contabile e finanziaria e con indipendenza di giudizio. Contenuti Multimediali Si parla di contenuti multimediali, specie in ambito informatico quando per comunicare un'informazione riguardo a qualcosa ci si avvale di molti media, cioè mezzi di comunicazione di massa, diversi: immagini in movimento (video), immagini statiche (fotografie), musica e testo. CSS I fogli di stile a cascata (dall'inglese CSS Cascading Style Sheet) sono un insieme di raccomandazioni redatte dal W3C (World Wide Web Consortium) per definire l'aspetto delle pagine HTML e XHTML. La loro creazione, avvenuta nel 1996 si è resa necessaria per separare i contenuti dalla formattazione e imporre una programmazione più chiara e facile da utilizzare, sia per l'autore che per l'utente Disabilità La Disabilità è una condizione per cui un essere umano è impossibilitato, per limiti fisici, neurologici o altro, all'esecuzione di determinate operazioni considerate normalmente eseguibili da persone che rispecchino i parametri medi fisici o neurologici dell'umanità. DHTML Il DHTML (acronimo dall' inglese Dynamic HTML) , conosciuto anche come HTML Dinamico, è un'insieme di tecnologie che permettono di cambiare in modo dinamico la - 473 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR rappresentazione e il contenuto di un documento ed aumentare l'interattività dell'utente sulla pagina. DLgs Il Decreto Legislativo (abbreviato con d.lgs.) è un atto normativo avente forza di legge adottato dal Governo su delega del Parlamento. DM l Decreto Ministeriale (DM) é un atto amministrativo emesso da un Ministro riguardo particolari materie; non ha forza di legge, ed é al pari di un regolamento governativo. DOM Il DOM (Document Object Model) è una interfaccia indipendente dalle piattaforme e dai linguaggi che consente ai programmi e agli script di accedere dinamicamente e modificare il contenuto, la struttura e lo stile di un documento. DPR Il Decreto del Presidente della Repubblica (in sigla D.P.R.) è atto del Presidente della Repubblica. Tramite un DPR vengono emanati i decreti legge e i decreti legislativi. DTD Lo scopo di un Document Type Definition (definizione del tipo di documento) è quello di definire le componenti ammesse nella costruzione di un documento XML. Flash Adobe Flash (in precedenza Macromedia Flash e ancora prima FutureSplash) è un software per uso prevalentemente grafico che consente di creare animazioni vettoriali principalmente per il Web. GIF Il GIF (Graphics Interchange Format) è un formato per immagini di tipo bitmap molto utilizzato nel World Wide Web, sia per immagini fisse che per le animazioni. Handicap In campo socio-sanitario Handicap indica uno svantaggio (o menomazione) permanente della persona dovuto a cause fisiche o psichiche. - 474 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR HTML HTML (acronimo per Hyper Text Mark-Up Language) è un linguaggio usato per descrivere i documenti ipertestuali disponibili nel Web. Non è un linguaggio di programmazione, ma un linguaggio di markup, ossia descrive il contenuto, testuale e non, di una pagina Web. Punto HTML (.html) o punto HTM (.htm) è anche l'estensione comune dei documenti HTML. ISO Organizzazione Internazionale per le Standardizzazioni (ISO) è un organismo internazionale per la definizione degli standard, composto da rappresentanze di organi nazionali, che produce standard industriali e commerciali a livello mondiale. IWA IWA (International Webmasters Association) è un'associazione professionale nonprofit che è riconosciuta leader mondiale nel fornire principi e certificazioni di formazione per le professioni in rete. Liquid Layout I liquid layout o layout fluidi sono una tipologia di presentazione per le pagine (X)HTML. Rientrano in questa categoria tutti le presentazioni che variano larghezza al variare della larghezza della finestra del browser. MIT Ministero per l'Innovazione e le Tecnologie OMS L'Organizzazione Mondiale della Sanità (OMS, WHO in inglese), agenzia delle Nazioni Unite specializzata per la salute, è stata fondata il 7 aprile 1948, con sede a Ginevra. PDF Il PDF (Portable Document Format) è un formato di file basato su un linguaggio di descrizione di pagina sviluppato da Adobe Systems per rappresentare documenti in modo indipendente dall'hardware e dal software utilizzati per generarli o per visualizzarli. RGB - 475 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR RGB è il nome di un modello di colori additivo che si basa sui tre colori primari: Rosso (Red), Verde (Green) e Blu (Blue), da cui appunto il nome RGB. Questo modello viene usato nel digitale per trasmettere immagini a colori. SVG Scalable Vector Graphics abbreviato in SVG, indica una tecnologia in grado di visualizzare oggetti di grafica vettoriale e, pertanto, di gestire immagini scalabili dimensionalmente. Si tratta di un linguaggio derivato dall'XML. SGML SGML, acronimo per Standard General Markup Language, è uno standard per la descrizione logica dei documenti. Sito Web Un Sito Web o sito internet (spesso abbreviato in sito) è un insieme di pagine Web, ovvero una struttura ipertestuale di documenti accessibili con un browser tramite World Wide Web su rete Internet. Tecnologie Assistive Le Tecnologie Assistive sono un insieme di trumenti e le soluzioni tecniche, hardware e software, che permettono alla persona disabile, superando o riducendo le condizioni di svantaggio, di accedere alle informazioni e ai servizi erogati dai sistemi informatici. Usabilità L'Usabilità è definita dall'ISO (International Standard Organization), come l'efficacia, l'efficienza e la soddisfazione con le quali determinati utenti raggiungono determinati obiettivi in determinati contesti. In pratica definisce il grado di facilità e soddisfazione con cui l'interazione uomo-strumento si compie. User Agent Lo User Agent è una qualunque applicazione client utilizzata con un certo protocollo di rete. La dicitura è utilizzata soprattutto riferendosi ai client che accedono al World Wide Web. Gli user agent del Web sono di tutti i tipi, da "semplice" browser Web ai crawler dei motori di ricerca, passando per telefoni cellulari, lettori di schermo e browser Braille usati da persone non vedenti. XHTML - 476 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR XHTML (acronimo per eXtensible HyperText Markup Language) nasce ufficialmente il 26 gennaio 2000 come raccomandazione W3C, e può essere definito sostanzialmente una riformulazione di HTML 4.01 come applicazione XML 1.0, ovvero come linguaggio definito a partire dalle specifiche XML. XML XML è l'acronimo di eXtensible Markup Language, ovvero linguaggio estensibile di marcatura dalle proprietà, ed è un linguaggio simile, strutturalmente, all'HTML. WEB Il World Wide Web (Web) è una rete di risorse di informazioni, basata sull'infrastruttura di Internet. Widget Nell'ambito della programmazione, il widget è un elemento (tipicamente grafico) di una interfaccia utente di un programma che facilita all'utente l'interazione con il programma stesso. Tipici esempi di widget sono i "bottoni" dell'interfaccia grafica di un programma che vengono "premuti" per dare comandi al programma stesso o le "checkbox" usate per compiere delle scelte fra varie opzioni disponibili. Gli widget sono spesso raggruppati in "raccolte" (toolkits) costruite e messe a disposizione dei programmatori in vari ambienti operativi proprio per facilitare la costruzione di interfacce operatore grafiche (GUI). - 477 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR VIII.2 - Glossario WCAG 1.0 Accessibile Il contenuto è accessibile quando può essere usato da qualcuno che ha una disabilità. Applet Un programma inserito in una pagina Web. Arte ASCII Il termine arte ASCII indica caratteri di testo e simboli combinati per creare un immagine. Per esempio ";-)" è l'emoticon smile. Ciò che segue è una cifra ascii che mostra la relazione fra la frequenza del flash e la risposta fotoconvulsiva in pazienti con occhi aperti e chiusi. Assistente digitale personale (PDA) Un PDA è un piccolo dispositivo portatile di calcolo. La maggior parte dei PDA sono usati per tracciare dati personali come ad esempio calendari, contatti e posta elettronica. Un PDA è di solito un dispositivo palmare con un piccolo schermo che accetta input da varie fonti. Braille Il braille usa sei punti in rilievo in diversa sequenza per rappresentare lettere e numeri per essere lette da persone non vedenti mediante i polpastrelli. Un display braille, comunemente indicato come un "display braille dinamico", solleva o abbassa sequenze di punti a comando da un dispositivo elettronico, di solito un computer. Il risultato è una linea braille che può cambiare di momento in momento. Gli attuali display braille hanno una dimensione che varia da una cella (sei o otto punti) fino a una linea di 80 celle; la maggior parte ha tra le dodici e le venti celle per linea. Compatibile all'indietro Progettazione che continua a funzionare con versioni precedenti di un linguaggio, programma, ecc. Contenuto, struttura e presentazione del documento Il contenuto di un documento si riferisce a ciò che dice all'utente mediante il linguaggio naturale, immagini, suoni, filmati, animazioni, ecc. La struttura di un documento equivale a come è organizzato da un punto di vista logico (per esempio per capitoli, con un'introduzione e degli indici, ecc.). Un elemento (per es., P, STRONG, BLOCKQUOTE nell'HTML) che specifichi la struttura del documento viene chiamato elemento strutturale. La presentazione di un - 478 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR documento è come viene reso il documento stesso (per esempio, a stampa, come presentazione grafica bidimensionale, come presentazione solo testuale, come sintesi vocale, come braille, ecc.). Un elemento che specifichi la presentazione di un documento (per esempio, B, FONT, CENTER) viene denominato elemento di presentazione. Consideriamo l'intestazione di un documento, per esempio. Il contenuto dell'intestazione è ciò che dice l'intestazione (es. "Barche a vela"). Nell'HTML, l'intestazione è un elemento strutturale contrassegnato per esempio da un elemento H2. Infine la presentazione dell'intestazione deve essere un testo in grassetto allineato al margine, una linea di testo centrata, un titolo detto con un certo stile di voce (una specie di font sonoro), ecc. Disapprovato Un elemento o attributo disapprovato è qualcosa che è stato superato da nuovi costrutti. Elementi disapprovati possono diventare obsoleti nelle versioni future dell'HTML. L'indice degli elementi e attributi HTML nel Documento sulle Tecniche indica quali elementi e attributi sono disapprovati dall'HTML 4.0. Gli autori dovrebbero evitare di utilizzare elementi e attributi disapprovati. Gli interpreti dovrebbero continuare a supportarli per ragioni di compatibilità all'indietro. Elemento Il presente documento utilizza il termine "elemento" nel senso ristretto di SGML (un elemento è un costrutto sintattico) e più generalmente per definire un tipo di contenuto (come il video o il suono) o un costrutto logico (come un'intestazione o una lista). Il secondo significato serve anche per enfatizzare il fatto che una linea guida ispirata dall'HTML potrebbe essere applicata facilmente ad un altro linguaggio di marcatura. Si noti che alcuni elementi (SGML) hanno un contenuto che è reso (es., gli elementi P, LI, o TABLE in HTML), alcuni sono sostituiti da contenuti esterni (es., IMG) e alcuni hanno a che fare con procedimenti (es., STYLE e SCRIPT fanno in modo che l'informazione sia trattata da un foglio di stile o da un motore di script). Un elemento che fa sì che i caratteri di testo facciano parte di un documento viene chiamato un elemento testuale. Equivalente Un contenuto è "equivalente" ad un altro contenuto quando entrambi svolgono essenzialmente la stessa funzione o scopo nei confronti dell'utente. Nel contesto di questo documento, per una persona con una disabilità, l'equivalente deve svolgere essenzialmente la stessa funzione (almeno per quanto è possibile, data la natura della disabilità e lo stato della tecnologia) che il contenuto principale svolge nei confronti di una persona non disabile. Per esempio, il testo "La luna piena" può veicolare la stessa informazione di un'immagine di luna piena quando presentato ad un utente. Si noti che l'informazione equivalente si basa sullo svolgimento della - 479 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR stessa funzione. Se l'immagine è parte di un collegamento e la sua comprensione è cruciale per indovinare la destinazione del collegamento, anche un equivalente deve dare all'utente un'idea della destinazione del collegamento. Fornire informazione equivalente per un contenuto inaccessibile è uno dei modi primari attraverso i quali gli autori possono rendere i loro documenti accessibili a persone con disabilità. Come aspetto dello svolgere la stessa funzione per quel che riguarda il contenuto, un equivalente può comportare la descrizione di quel contenuto (cioè, come appare alla vista o all'udito). Per esempio, per far sì che gli utenti comprendano l'informazione veicolata da un grafico complesso, gli autori dovrebbero descrivere l'informazione visiva del grafico. Dal momento che il contenuto testuale puo essere presentato all'utente sotto forma di sintesi vocale, braille e testo mostrato visivamente, queste linee guida richiedono equivalenti testuali per le informazioni grafiche e audio. Gli equivalenti testuali devono essere scritti in modo da veicolare l'intero contenuto essenziale. Gli equivalenti non testuali (per esempio, una descrizione uditiva o una presentazione visiva, un video di una persona che racconti una storia usando il linguaggio dei segni come equivalente di una storia scritta, ecc.) migliorano l'accessibilità anche per persone che non possono accedere all'informazione visiva o al testo scritto, inclusi molti individui con disabilità della vista, cognitive, dell'apprendimento, e dell'udito. L'informazione equivalente può essere fornita in un certo numero di modi che includano gli attributi (per esempio, un valore testuale per l'attributo "alt' in HTML e SMIL), come parte del contenuto dell'elemento (per esempio, l'OBJECT in HTML), come parte della prosa del documento, o attraverso un documento collegato (per esempio designato dall'attributo "londesc" dell'HTML o un collegamento descrittivo). In base alla complessità dell'equivalente può essere necessario combinare tecniche (per esempio, usare "alt" per un equivalente abbreviato, utile ai lettori abituali, insieme a "londesc" per un collegamento ad un'informazione più complessa, utile a coloro che leggono per la prima volta). I dettagli su come e quando fornire un'informazione equivalente fanno parte del Documento sulle Tecniche. Una trascrizione testuale è un equivalente testuale di informazioni audio che includa parole pronunciate e suoni come ad esempio effetti sonori. Una didascalia è una trscrizione testuale della traccia audio di una presentazione video che sia sincronizzato con le tracce audio e video. Le didascalie vengono generalmente rese visivamente, venendo sovrapposte allo schermo, cosa che favorisce le persone sorde o con difficoltà di udito e qualsiasi altra persona che non possa ascoltare l'audio (per esempio, quando si è in una stanza affollata). Una trascrizione testuale collazionata combina (collaziona) le didascalie con le descrizioni testuali di informazioni video (descrizione delle azioni, linguaggio corporeo, grafica, e cambiamenti di scena nella traccia video). Questi equivalenti testuali rendono la presentazione accessibile a persone che sono sordo-cieche e a persone che non possono ascoltare film, animazioni, ecc. Essi rendono inoltre l'informazione reperibile ai motori di ricerca. - 480 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Un esempio di un equivalente non testuale è una descrizione uditiva degli elementi visuali chiave di una presentazione. La descrizione consiste sia in una voce umana preregistrata che in una voce sintetizzata (registrata o generata sul momento). La descrizione uditiva è sincronizzata con la traccia audio della presentazione, di solito durante le pause naturali nella traccia audio. Le descrizioni uditive includono informazioni su azioni, linguaggio corporeo, grafica e cambi di scena. Fino a quando gli interpreti... Nella maggior parte dei punti di controllo si chiede agli sviluppatori di assicurare l'accessibilità delle pagine e dei siti. Tuttavia vi sono esigenze di accessibilità che potrebbero essere risolte in modo più appropriato dagli interpreti (incluse le tecnologie assistive). Alla data di pubblicazione di questo documento, non tutti gli interpreti o le tecnologie assistive forniscono il controllo di accessibilità che gli utenti richiedono (per esempio, alcuni interpreti possono non consentire all'utente di bloccare il contenuto che lampeggia, o alcuni lettori di schermo possono non gestire bene le tabelle). I punti di controllo che contengono la frase "fino a quando gli interpreti..." richiedono agli sviluppatori di fornire un aiuto aggiuntivo per l'accessibilità fino a quando la maggior parte degli interpreti facilmente disponibili per il loro pubblico non avrà incluso le necessarie caratteristiche di accessibilità. Nota. Il sito WAI del W3C fornisce informazioni riguardo a come gli interpreti supportano le caratteristiche di accessibilità. Si incoraggiano gli sviluppatori a consultare regolarmente queste pagine per disporre di un'informazione aggiornata. Fogli di stile Un foglio di stile è una serie di specifiche che riguardano la presentazione di un documento. I fogli di stile possono avere tre diverse origini: possono essere scritti dagli sviluppatori, creati dagli utenti, o incorporati in interpreti. Nei CSS ([CSS2]), l'interazione fra i fogli di stile dello sviluppatore, quelli dell'utente e quelli dell'interprete è denominata "cascata". La marcatura di presentazione è una marcatura che persegue un effetto stilistico (piuttosto che strutturale), come nel caso degli elementi B o I nell'HTML. Si noti che gli elementi STRONG e EM non sono considerate marcature di presentazione dal momento che contengono un'informazione che è indipendente da un particolare stile del font. HTML dinamico (DHTML) DHTML è il termine di marketing applicato a un misto di standard che include l'HTML, i fogli di stile, il Document Object Model [DOM1] e gli script. Tuttavia non esiste una specifica W3C che definisca formalmente il DHTML. La maggior parte delle linee guida si possono applicare ad applicazioni che usano il DHTML, tuttavia le linee guida che focalizzano l'attenzione su problemi - 481 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR collegati con l'inserimento di script e con i fogli di stile sono: Linea guida 1, Linea guida 3, Linea guida 6, Linea guida 7, e Linea guida 9. Immagine Una presentazione grafica. Immagine sensibile Un'immagine che è stata divisa in zone con azioni associate. Cliccando su una zona attiva si fa in modo che avvenga un'azione. Quando un utente clicca su una zona attiva di un'immagine sensibile sul lato client, l'interprete calcola in quale zona si è verificato il click e segue il collegamento associato a quella zona. Cliccando su una zona attiva di un'immagine sensibile sul lato server si fa in modo che le coordinate del click vengano inviate al server, che di conseguenza svolge una qualche azione. Gli sviluppatori possono rendere accessibili le immagini sensibili sul lato client fornendo accesso indipendente da dispositivo agli stessi collegamenti associati con le zone dell'immagine sensibile. Le immagini sensibili sul lato client consentono all'interprete di fornire un riscontro immediato sul fatto se il puntatore dell'utente si trova oppure no su una zona attiva. Importante L'informazione in un documento è importante se la comprensione dell'informazione stessa è cruciale per la comprensione del documento. Indipendente da dispositivo L'utente dovrebbe essere in grado di interagire con un interprete (e il documento che esso rende) usando i dispositivi di input e output supportati, secondo la propria scelta e secondo i propri bisogni. I dispositivi di input possono includere dispositivi di puntamento, tastiere, display braille, bacchette manovrate con la testa, microfoni ed altro. I dispositivi di output possono includere monitor, sintetizzatori vocali e dispositivi braille. Si noti che "supporto indipendente da dispositivo" non significa che i traduttori devono supportare ogni dispositivo di input o output. I traduttori dovrebbero offrire meccanismi di input e output ridondanti per i dispositivi supportati. Ad esempio, se un interprete supporta input sia da tastiera che da mouse, l'utente dovrebbe essere in grado di interagire con tutti gli aspetti della pagina usando sia la tastiera che il mouse. Informazione tabellare Quando le tabelle sono usate per rappresentare relazioni logiche fra i dati -- testi, numeri, immagini, ecc. quell'informazione è chiamata "informazione tabellare" e le tabelle sono chiamate "tabelle di dati". Le relazioni espresse da una tabella possono essere rese in modo - 482 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR visivo (di solito con una griglia bidimensionale), uditivo (spesso precedendo celle con informazione nel titolo), o in altri formati. Ingranditore di schermo Un programma che ingrandisce una porzione di schermo in modo che possa essere vista più facilmente. Gli ingranditori di schermo vengono usati principalmente da individui ipovedenti. Interprete Software per l'accesso al contenuto Web, inclusi browser grafici per desktop, browser testuali, browser vocali, cellulari, lettori multimediali, plug-in, e alcuni software di tecnologia assistiva usati congiuntamente a browser come lettori di schermo, ingranditori di schermo, e programmi per il riconoscimento della voce. Lettore di schermo Un programma che legge il contenuto dello schermo a voce alta a un utente. I lettori di schermo vengono usati principalmente da persone non vedenti. I lettori di schermo di solito sono in grado di leggere solo il testo stampato (scritto) e non disegnato sullo schermo. Linguaggio naturale Linguaggi umani parlati, scritti o dei segni come il francese, giapponese, il linguaggio americano dei segni e il braille. Il linguaggio naturale di un contenuto può essere indicato con l'attributo "lang" in HTML ([HTML40], sezione 8.1) e l'attributo "xml:lang" in XML ([XML], sezione 2.12). Meccanismo di navigazione Un meccanismo di navigazione è rappresentato da qualsiasi mezzo col quale un utente possa navigare in un sito o pagina Web. Alcuni meccanismi tipici includono: barre di navigazione Una barra di navigazione è una collezione di collegamenti alle parti più importanti di un documento o di un sito. mappe dei siti La mappa di un sito fornisce una visione globale dell'organizzazione di una pagina o di un sito. indici Un indice generalmente elenca (e fa dei collegamenti a) le più importanti sezioni di un documento. Strumento di authoring - 483 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Editor HTML, strumenti di conversione dei documenti, strumenti che producono contenuto Web da dei database sono tutti strumenti di authoring. Riferirsi alle "Authoring Tool Accessibility Guidelines" ([WAI-AUTOOLS]) per informazioni sullo sviluppo di strumenti accessibili. Sviluppatore Qualcuno che fa l'authoring di pagine Web o progetta siti. Tabella linearizzata Un processo per rendere una tabella nel quale i contenuti delle celle diventano una serie di paragrafi (per esempio, in fondo alla pagina) uno dopo l'altro. I paragrafi seguiranno lo stesso ordine delle celle del documento d'origine. Le celle dovrebbero avere senso se lette di seguito e dovrebbero includere elementi strutturali (che creino paragrafi, titoli, liste, ecc.) in modo che la pagina conservi il senso dopo la linearizzazione. Tecnologia assistiva Software o hardware progettato specificamente per aiutare persone disabili a compiere le attività quotidiane. La tecnologia assistiva include sedie a rotelle, macchine per la lettura, aggeggi per afferrare, ecc. Nell'area dell'accessibilità del Web, le più comuni tecnologie assistive basate su software includono lettori di schermo, ingranditori di schermo, sintetizzatori vocali e software di riconoscimento della voce che operano congiuntamente a browser con desktop grafico (tra gli altri interpreti). Le tecnologie assistive di tipo hardware includono tastiere alternative e dispositivi di puntamento. Testo del collegamento Il contenuto di un collegamento reso in maniera testuale. - 484 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR IX. Riferimenti Questo capitolo è molto più scarno ed essenziale di quanto ci si possa aspettare da un lavoro di ricerca. La motivazione principale è che molto del materiale citato è stato reperito in rete ed è stato direttamente referenziato al momento di utilizzarlo nel documento. Sarebbe piuttosto inutile riportare qui un elenco avulso di indirizzi. Ho ritenuto opportuno citare solo le pubblicazioni che più hanno contribuito come impianto e come sintesi generale del lavoro, includendo anche alcuni link generali di primaria importanza da cui si può partire per una proficua navigazione di approfondimento. IX.1 - Bibliografia Joe Clark: “Building Accessible Websites” New Riders Publishing isbn 0-7357-1150-X anno di pubblicazione 2002. Roberto Scano: “Accessibilità: dalla teoria alla realtà” edizioni IWA Italy isbn 88-7633-000-3 anno di pubblicazione 2004. IX.2 - Link Utili Accessibilità e traduzioni dal W3C su Diodati.org http://www.diodati.org/ CPB/WGBH National Center for Accessible Media http://ncam.wgbh.org/index.html CNIPA:Centro Nazionale per Informatica nella Pubblica Amministrazione http://www.cnipa.gov.it/site/it-IT/ - 485 - ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR Disabilità in cifre http://www.disabilitaincifre.it/index.asp Fondazione ASPHI Onlus http://www.asphi.it/ PubbliAccesso - Home Page http://www.pubbliaccesso.it/index.htm Strumenti - [ LAU ] Laboratorio per l’Accessibilità e l’Usabilità http://lau.csi.it/risorse/strumenti.shtml#screen Usabile.it http://www.usabile.it/ Ufficio Italiano W3C http://www.w3c.it/ Web accessibile e accessibilità dei siti internet - Webaccessibile.org http://www.webaccessibile.org/ Web Accessibility Initiative (WAI) - home page http://www.w3.org/WAI/ WebAIM: Web Accessibility in Mind http://www.webaim.org/ - 486 -

Embed!

Iii. Metodologie E Tecniche Di Applicazione

About us'

About us

Terms and conditions

Privacy policy

Sitemap

Career

Contact us

Support

Help

Submit ticket

Account

Profile

Login

Register

Forgot password

Connect with us

Copyright © 2012-2024.

Welcome back

Login to manage your account

Forgot password

Do not have an account? Register

Or

Facebook Google

Welcome to XDOCS.

Fill out the form to get started

I agree to the Terms and conditions

Already have account? Login

Or

Facebook Google

Forgot your password?.

Enter your email address below and we will get you back on track

Remember your password? Login

Terms and conditions

Help

Iii. Metodologie E Tecniche Di Applicazione

Rating

Date

Size

Views

Categories

Share

Transcript

per il livello massimo di intestazione, la sezione principale,

per il successivo livello sottostante come una sottosezione,

per un livello al di sotto del precedente e così via. Il livello più basso d'intestazione è

. La maggior parte dei browser Web mostrerà

come un testo grande con un font differente e

..

II. Scenario

Sommario

Pagine Web

Accessibilità

Usabilità

Disabilità

W3C: World Wide Web Consortium

Forgot your password?.