accesso
Accessibilit dei contenuti e delle applicazioni web.
Di Donato Taddei, settembre 2011

 
Sommario
1.	Introduzione 
2.	Definizione di accessibilit 
3.	Le origini e l'Iniziativa per l'Accessibilit del Web (WAI) del W3C 
4.	La normativa europea sull'accessibilit 
5.	La normativa italiana sull'accessibilit 
6.	La nuova versione (2.0) delle Linee guida WAI del 2008 
7.	I 4"Principi" e le nuove 12 Linee guida 
8.	Il Decreto in emanazione che recepir le nuove linee guida 
9.	Note ed approfondimenti 
 
Introduzione
Molto spesso il termine accessibilit viene percepito, a volte perfino con un po di disagio, come un "articolo per disabili" o, al pi, come materia per sviluppatori e gestori di siti. 
Non  proprio cos.
Infatti la facilit e immediatezza di uso dei servizi sempre pi telematici 
semplifica la vita, come pure il facile accesso e la fruizione di ci che si sta cercando;
questo vale proprio per tutti gli utenti, ma in particolare: 
	per chi ha poca dimestichezza con i computer e la rete; 
	per chi dispone di dispositivi e softwares non proprio recentissimi; 
	per chi dispone di banda ristretta, connessioni lente, segnale debole o disturbato; 
	per chi si collega in ambiente disturbato: (rumoroso, troppo o troppo poco illuminato; 
	per chi ha problemi con la nostra lingua (turisti stranieri, migranti,sempre pi numerosi); 
	per chi ha un basso livello di istruzione; 
	per chi ha problemi di lettura a schermo o dispone di dispositivi con piccolo schermo; 
	per gli anziani con capacit complessiva ridotta, sempre pi numerosi, in una societ che invecchia rapidamente; 
	e infine, ovviamente, di disabili, che spesso utilizzano modalit di interazione alternative: 
	(lettori di schermo, ingranditori, softwares ingrandenti, dispositivi di puntamento diversi) . 
Poich come abbiamo visto il problema riguarda tutti gli utenti del web e pi in generale chiunque interagisca con sistemi info-telematici
in questo articolo si far il punto dello "Stato dell'arte" con un taglio divulgativo per 
"non addetti ai lavori", rinviando per gli approfondimenti alle note a fondo pagina.
Partiremo dalle origini per meglio contestualizzare e focalizzare le pi recenti acquisizioni, anche alla luce della evoluzione tecnologica di questi ultimi anni, rinviando ad eventuali prossimi articoli l'approfondimento pi analitico di specifici approcci e criticit, con particolare attenzione all'accessibilit dei documenti elettronici e a quella delle applicazioni per dispositivi mobili . 
Torna al sommario 
Definizione di accessibilit 
Il termine ha avuto larga diffusione e la relativa voce  presente anche su Wikipedia,
l'enciclopedia libera basata sul SAPERE CONDIVISO, con differenti sfumature di significato, apparentemente distanti tra loro, ma tutte riconducibili ad un approccio progettuale atto a soddisfare esigenze di una utenza con differenti bisogni e percezioni, dello spazio virtuale come di quello reale, approccio noto come "design for all" o "progettazione per tutti", si veda: 
	Accessibilit in termini di accesso e fruizione ai servizi, alle tecnologie, e ai dispositivi tecnico/informatici
	Accessibilit in termini di accesso e fruizione alle strutture urbane da parte dei disabili: si veda barriere architettoniche
	Accessibilit nel settore del diritto e dell'archivistica, ovvero la reperibilit delle font0i (1) 
accessibilit informatica da Wikipedia: 
L'accessibilit  la caratteristica di un dispositivo, di un servizio o di una risorsa d'essere fruibile con facilit da una qualsiasi tipologia d'utente . Il termine  comunemente associato alla possibilit anche per persone con ridotta o impedita capacit sensoriale, motoria, o psichica (ovvero affette da disabilit sia temporanea, sia stabile), di fruire dei sistemi informatici e delle risorse a disposizione . Il termine ha trovato largo uso anche nel settore di Internet col medesimo significato . 
Torna al sommario 
Le origini e l'Iniziativa per l'Accessibilit del Web (WAI) del W3C 
Negli anni 90 esplode il fenomeno della internet di massa, prima negli usa e poi nel resto del mondo, che si ritrova cos inviluppato in una ragnatela di interconnessioni, onde il nome web.
Pi precisamente il termine identifica una modalit di scambio dati tra computer, basata su un protocollo di trasferimento dati che supporta lo scambio di documenti contenenti collegamenti ad altri documenti e risorse, nonch immagini, suoni, animazioni ed altri contenuti multimediali;
I documenti cos arricchiti vengono perci detti ipertestuali ed il protocollo di trasferimento  denominato HTTP Hypertext Transfer Protocol (protocollo per il trasferimento degli ipertesti).
I documenti ipertestuali devono essere codificati in modo da permettere ai programmi di navigazione (es. Internet explorer o Mozilla Firefox) di gestire la presentazione adattandosi alle caratteristiche e/o ai limiti dei dispositivi e alle personalizzazioni degli utenti.
Pertanto devono essere cofidicati con dei marcatori che identifichino la struttura del documento, i collegamenti e gli aspetti di presentazione.
Si affermano cos i linguaggi di marcatura, in particolare il linguaggio di marcatura per gli ipertesti o HTML (HyperText Mark-up Language) . 
Tim Werner-Lee, il padre del web, attuale direttore del Consorzio mondiale del web (World Wide Web Consortium) (W3C) sintetizza cos la vocazione del web a porsi come medium universale:
"One Web accessible by anyone, anywhere, anytime"
Il web deve poter essere acceduto e fruito da chiunque, dovunque, in ogni momento e in qualunque condizione.
Ci implica che esso deve supportare lo scambio tra: 
	una grande variet di macchine (reti, computer, smartphones) 
	differenti sistemi operativi (Windows, Mac, Linux, Unix) 
	una moltitudine di lingue 
	sistemi di scrittura molto differenti (latino, cirillico, arabo, alfabeti ideografici orientali) 
	macchine sincronizzate su fusi orari e tempi diversi 
La portata planetaria del fenomeno induceva una crescita esponenziale dell'offerta tecnologica, molto diversificata per costi e prestazioni. 
Si rendeva quindi necessaria una iniziativa forte per promuovere l'adozione di standard condivisi 
	dai produttori di macchine e dispositivi 
	dagli sviluppatori dei programmi di navigazione (browsers,user agends) 
	dai fornitori di contenuti e servizi . 
Cos il W3C, massima autorit internazionalmente riconosciuta per il web, lancia nel 1999 l'iniziativa per l'accessibilit del web (Web Accessibility Initiative) WAI consistente in un complesso di raccomandazioni e specifiche tecniche,appunto "Linee guida" dirette a tutti i soggetti sopra citati.
Il concetto chiave  che per allargare il bacino di utenza del web bisogna intanto non escludere determinate categorie di utenti e perci adottare tecniche ed accorgimenti che permettano loro l'accesso e la fruizione.
Gli accorgimenti e le piccole attenzioni adottate per facilitare l'accesso a determinate categorie di utenti come i disabili , gli stranieri o gli anziani migliora l'accessibilit per la totalit degli utenti, innanzitutto perch abitua i produttori di contenuti e di softwares a ragionare in termini di "Design for all" e dunque a mettere al centro della progettazione le esigenze di una utenza diversificata . 
Seguono i riferimenti alle principali pubblicazioni della iniziativa per l'accessibilit del web (WAI) del W3C: 
	Linee guida per l'accessibilit dei contenuti web del 5 maggio 1999
Testo ufficiale inglese Traduzione italiana 
	Linee guida per i tools di sviluppo, ovvero i programmi con cui vengono realizzate le pagine web del 3 febbraio 2000 Authoring tools accessibility guidelines 
	Linee guida per l'accessibilit dei programmi con cui gli utenti accedono al web (browsers, media players, user agends) del 17 dicembbre 2002 User agends accessibility guidelines 1.0 
Per permettere alle applicazioni di conformarsi gradualmente a tali specifiche, vengono identificati tre livelli di conformit, contrassegnati con 1, 2 o 3 A: 
'A' 
il livello essenziale per non escludere completamente dall'accesso intere categorie di utenti; 
'AA' 
un livello intermedio che pu facilitare di molto l'accesso a determinate categorie di utenti; 
'AAA' 
il livello massimo di accessibilit previsto, quando cio tutti i requisiti di accessibilit (anche detti "punti di controllo" o "criteri di successo") sono soddisfatti pienamente . 
L'iniziativa WAI del W3C ottiene il risultato sperato di sensibilizzare fortemente alla problematica l'opiniOne pubblica mondiale, e ci spinge molti stati a recepire in quegli anni tali raccomandazioni come norme giuridiche nei rispettivi ordinamenti, in particolare nei paesi pi industrializzati come Usa, Canada, Francia, Regno Unito.
A partire dal 2000 si crea anche in Italia un notevole movimento di opinionesul tema, di cui chi scrive  stato uno dei pi attivi promotori, (2) che viene cos portato all'attenzione della classe politica e che sfocer dapprima in qualche iniziativa istituzionale come un sito accessibile per la Camera dei deputati, voluto dall'allora presidente Violante, poi in due gruppi di lavoro, uno presso l'Aipa (Autorit informatica per la pubblica amministrazione) e l'altro presso il ministero della funzione pubblica, per approdare nel 2004, in concomitanza con l'anno europeo del disabile alla legge 4/2004, anche nota come legge Stanca.
Al riguardo merita una particolare menzione il progetto "wai.inps.it", sostanzialmente frutto del lavoro del collega Del Vedovo, con cui si dava efficace dimostrazione di come mettere concretamente in pratica le linee guida wai in una grande amministrazione come l'Inps . 
Torna al sommario 
La normativa europea sull'accessibilit 
A margine del convegno dei ministri europei del 19 marzo 2000 a Lisbona che ratificava l'Europa a 27 membri, l'unione europea approva una serie di documenti che impegnano gli stati membri a favorire l'inclusione e l'accesso dei disabili alla istruzione e alla comunicazione.
La Commissione UE lancia per il 2002 il piano eEurope per una Europa elettronica, con delibera del 25 settembre 2001, stabilendo che i siti pubblici dell'Unione devono conformarsi al livello 'A' delle raccomandazioni WAI.
Ritorna sul tema con una comunicazione della commissione per l'ICT nel 2005 intitolata Information Society - eInclusion & eAccessibility - The 2005 Communication on eAccessibility con cui la Commissione si impegna a garantire i benefici della societ dell'informazione a tutti gli europei.
Viene valutata altres l'eventualit di creare unmarchio di certificazione europeo per l'accessibilit per incentivare i produttori di servizi e prodotti basati sulle tecnologie dell'informazione a permetterne l'accesso al maggior numero di persone possibile.
Le tematiche dell'inclusivit e dell'accessibilit dei servizi telematici sono trattate in diversi tipi di politiche economiche e sociali UE: leggi su questi temi sono presenti nel quadro legislativo che regola l'occupazione, il mercato interno e la comunicazione pubblica.
Tra i documenti pi recenti in merito, vi sono il Frame work Single Market for the 21 st Century del 2007 e la Renewed Social Agenda del 2008 
Entrambi questi documenti definiscono la e-inclusion e l'accessibilit in Europa come obiettivi fondamentali da raggiungere sul piano sia economico che sociale: per raggiungere il suo pieno potenziale, il mercato interno deve raggiungere tutti i possibili acquirenti e per questo gli obiettivi della partecipazione e dell'informazione dei cittadini tramite ICT sono fondamentali: ma questi obiettivi sono auspicabili anche per ridurre la disparit sociale e fornire a tutti le stesse opportunit educative, lavorative, sanitarie e informative.
La combinazione di questi effetti genera quindi un circolo virtuoso che porta al miglioramento della societ europea.
Una successiva comunicazione, Towards an accessible information society,  stata adottata nel 2008, che fa esplicito riferimento all'accessibilit dei servizi web.
Le conclusioni del Consiglio dei Ministri Europeo sulla comunicazione del 2009 spingono verso l'esigenza di trovare un approccio comune sull'accessibilit a livello comunitario. Gli Stati membri dell'Unione sono invitati ad implementare le linee guida WCAG 2.0 nella loro legislazione sull'accessibilit: si menziona la necessit di rendere accessibili gli apparecchi telefonici mobili, in particolare riguardo ai servizi di emergenza. Gli Stati membri sono invitati anche a tenere in considerazione criteri basati sul rispetto dell'accessibilit nello scegliere come assegnare fondi pubblici per realizzare servizi ICT . 
Torna al sommario 
La normativa italiana sull'accessibilit 
segue una breve panoramica in ordine cronologico sulle disposizioni di legge introdotte nell'ordinamento italiano in materia di accessibilit dal 2001, rinviando per il testo ai links sottostanti: 
1.	la circolare del ministro della funzione pubblica, detta Bassanini del 13 marzo 2001, n. 65:
Linee guida per l'organizzazione, l'usabilit e l'accessibilit dei siti Web delle pubbliche amministrazioni che si richiama agli impegni UE del convegno di Lisbona e raccomanda l'adozione delle linee guida WAI del W3c, facendone un riassunto un po generico delle principali accortezze che bisognerebbe adottare per migliorare l'accessibilit e l'usabilit dei siti web pubblici . 
2.	la circolare Aipa del 6 settembre 2001, n. 32:
Criteri e strumenti per migliorare l'accessibilit dei siti web e delle applicazioni informatiche a persone disabili. la quale riprende e articola meglio le prescrizioni della circolare Bassanini, rinnovando l'invito ad adottare le linee guida WAI, ma contiene anche una disamina delle principali modalit alternative e tecnologie assistive utilizzate dai disabili, oltre al dettaglio delle principali problematiche e di come possono essere risolte . 
3.	legge 9 gennaio 2004, n.4, detta anche legge Stanca:
Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici
Questa legge, discussa e approvata nel "2003, Anno europeo del disabile" regolamenta anche altri aspetti connessi ai disabili e all'informatica, non solo l'accessibilit del web ma anche quella degli strumenti didattici e multimediali, del materiale formativo, delle postazioni di lavoro.
Tuttavia l'art. 1: (Obiettivi e finalit) chiarisce bene che no si tratta dei soli disabili, ma di tutti i cittadini:
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.
La legge sancisce una serie di principi e di disposizioni generali, comprese sanzioni per gli inadempienti,rinviando al regolamento di attuazione emanato ai sensi della legge 23 agosto 1988, n400,e a un successivo decreto del ministero dell'innovazione per il dettaglio delle specifiche prescrizioni tecniche.
4.	Decreto Presidente della repubblica 1 marzo 2005, n. 75:
Regolamento di attuazione della legge 9 gennaio 2004, n. 4 per favorire l'accesso dei soggetti disabili agli strumenti informatici.
Questo  l'esempio classico di un decreto caduto in desuetudine appena promulgato.
A un lustro di distanza nessuno ormai si ricorda pi dei loghi e loghini previsti, n degli elefantiaci e perci inattuabili gruppi di valutatori multidisciplinari dei siti, meno di tutti le amministrazioni statali che non hanno quasi mai provveduto a nominare, ai sensi dell'art. 9 di questo Decreto, i "Dirigenti Responsabili per l'accessibilit", anche perch non era previsto per legge alcun compenso.
5.	Decreto del Ministro per l'innovazione e le tecnologie dell'8 luglio 2005:
Requisiti tecnici e i diversi livelli per l'accessibilit agli strumenti informatici.
Questo decreto  stato, ed  ancora per qualche mese, fino a quando cio non sar emanato il nuove decreto che recepisce nell'ordinamento italiano la nuova versione 2.0 delle Linee guida WAI che il W3C ha nel frattempo pubblicato nel 2008, il cui testo  attualmente all'esame della UE, il principale punto di riferimento per quanto riguarda le specifiche pi propriamente tecniche contenute soprattutto nei numerosi allegati di cui riportiamo qui alcuni titoli, tutti raggiungibili dal link soprastante, per mostrare come l'approccio non sia circoscritto ai soli siti e applicazioni web: 
o	Allegato A: Verifica tecnica e requisiti di accessibilit delle applicazioni basate su tecnologie internet. 
o	Allegato B: Metodologia e criteri di valutazione per la verifica soggettiva dell'accessibilit delle applicazioni basate su tecnologie internet . 
o	Allegato C: Requisiti tecnici di accessibilit per i personal computer di tipo desktop e portatili . 
o	Allegato D: Requisiti tecnici di accessibilit per l'ambiente operativo, le applicazioni e i prodotti a scaffale . 
L'emanando decreto , che dovr recepire la nuova versione delle Linee guida WAI, presentato nel seguito, riguarder solo l'aggiornamento dell'allegato A con i requisiti di accessibilit delle applicazioni web, noto come l'"allegato dei 22 requisiti".
Al riguardo va detto che i gruppi di lavoro che ne curarono la stesura compirono un notevole sforzo di semplificazione della materia, accorpando in soli 22 requisiti i circa 60 "punti di controllo" delle Linee guida WAI, anche se va detto che in qualche caso ci ha creato un certo disorientamento e perfino una eccezione di incostituzionalit vinta dalla provincia autonoma di Trento la quale sosteneva il diritto a normare autonomamente e con propria legge aveva stabilito di conformarsi al livello 'A' delle WAI, accogliendo la normativa adottata dalla UE.
Sicuramente il Decreto in via di emanazione non porr questo tipo di problemi in quanto sar totalmente aderente alla nuova versione delle Linee guida WAI.
6.	Decreto legislativo 7 marzo 2005, n. 82:
Codice dell'Amministrazione digitale 
7.	Decreto Ministeriale 30 aprile 2008, del ministro per l'innovazione e le tecnologie,di concerto col ministro per l'istruzione e la ricerca scientifica, Pubblicato sulla Gazzetta Ufficiale n. 136 del 12 giugno 2008:
Regole tecniche disciplinanti l'accessibilit agli strumenti didattici e formativi a favore degli alunni disabili che d pratica attuazione all'Art. 5 della sopra citata legge 9 gennaio 2004, n. 4. Nonostante questo decreto sia stato in gran parte stravolto da un successivo Decreto del ministero dell'istruzione, a seguito di intesa con l'AIE (Associazione Italiana Editori), ha tuttavia il notevole pregio di contenere nei suoi allegati una serie di indicazioni utili all'accessibilit dei libri di testo e degli strumenti didattici e formativi, utilizzabili anche in contesti diversi da quello scolastico, come la formazione e l'aggiornamento dei dipendenti, anche disabili, e l'accessibilit delle pubblicazioni in genere . 
Torna al sommario
La nuova versione (2.0) delle Linee guida WAI del 2008 
Fin dai primi anni del nuovo secolo il web conosce una nuova esplosione che moltiplica di molte volte il numero dei suoi utenti, delle pagine visitate da ciascuno di essi, nonch delle pagine pubblicate.
Il Web cessa di essere solo una "vetrina, bacheca" per divenire strumento di perfezionamento di transazioni commerciali, per lo scambio di merci e servizi, per la pubblicazione e commercializzazioni o socializzazione di contenuti, divenendo per questo sempre pi interattivo, per poter supportare una gamma sempre pi variegata e complessa di interazioni con gli utenti, nell'erogazione di servizi sempre pi efficaci.
Per questo motivo il Web subisce una profonda evoluzione, passando dal cosiddetto "web statico", in cui la stessa identica pagina vienene inviata ad ogni richiesta di accesso da parte dei browsers, degli utenti, al cosiddetto "Web dinamico" in cui interviene un processo di "Negoziazione" tra il server e il programma dell'utente da cui discende la creazione e l'invio della pagina richiesta, in modo aderente alle funzionalit del browser e del dispositivo richiedente e alle preferenze dell'utente.
Normalmente, per automatizzare il processo di "negoziazione" tra "Servitore" e "Cliente", che altrimenti produrrebbe un rallentamento e un appesantimento della comunicazione, si ricorre a strumenti di tradcciamento di tale "negoziazione", tramite l'invio al server da parte del browser di piccoli files contenente il dettaglio della richiesta, chiamati "COOKIES",, ("biscottini"), come quelli dati in premio nell'addestramento dei cani, quando l'animale obbedisce e fa bene.
Queste profonde innovazioni trasformano la natura stessa del Web, sostanzialmente nato come "veicolo di Contenuti Multimediali" in strumento di "interazione Multimodale", in cui dispositivi diversi, con differenti modalit di interazione, devono poter efficacemente accedere alle risorse di loro interesse . Per permettere questo grande "Salto di Qualit" del web si affermano e consolidano numerose tecnololgie, specificamente progettate per far fronte alle nuove esigenze: si pensi ad esempio alle animazioni Flash, alla condivisione di filmati, audio, come YOUTUBE, alle connessioni sicure per supportare i pagamenti come Paypal, al commercio di ogni genere tramite eBay, ai "Social network" come FaceBook o Twipper, alla mappatura totale del pianeta e ai sistemi di localizzazione e di navigazione satellitare, al sempre maggiore accesso ai servizi tramite dispositivi mobili come PDA e smartphones.

Il W3C continua la sua opera meritoria anche dopo la pubblicazione delle Linee guida WAI del 1999, seguendo l'evoluzione delle tecnologie attraverso i suoi gruppi di lavoro, cercando di individuare, sperimentare e proporre soluzioni per rendere accessibili anche queste tecnologie e lavorando ad una riscrittura pi onnicom prensiva delle Linee guida che tenga conto della profonda evoluzione del web cui abbiamo ora accennato.
Questo lavoro di "riscrittura" sfocia l'11 dicembre 2008 nella pubblicazione della nuova versione delle Web Content Accessibility Guidelines (WCAG 2.0), con la nuova versione delle Linee Guida WAI, seguita ed integrata nel 2010 dalla pubblicazione della bozza delle Techniques for WCAG 2.0 con cui si mantiene una collezione ragionata di esempi di implementazione e di errori da evitare dei singoli requisiti di accessibilit con l'utilizzo di differenti tecnologie. Tra parecchi altri documenti interessanti pubblicati dal W3C merita anche attenzione questa "raccomandazione" quasi contemporanea alle nuove Linee guida, pubblicata il 29 luglio 2008 intitolata Web Mobile - Best Practices 1.0 che appunto raccoglie le "buone pratiche" per il web mobile.
La nuova versione delle Linee guida per l'accessibilit dei contenuti web possiede anche una traduzione ufficiale in lingua italiana, curata dall'amico Roberto Scano per conto di IWA-Italy (sezione italiana della International Webmaster Association), membro del Consorzio W3C, di cui si segnala anche la risorsa da essa curata e sempre aggiornata dedicata all'accessibilit Webaccessibile.org, con forum, eventi, corsi e soprattutto molti approfondimenti . 
Linee guida per l'accessibilit dei contenuti web (WCAG 2.0) in italiano
Prima di analizzare pi in dettaglio il contenuto di queste nuove Linee guida, al fine di una migliore comprensione delle novit introdotte e delle loro implicazioni, sar necessario innanzitutto mettere a fuoco il differente, pi maturo e largo approccio con cui sono formulate, evidenziando le principali differenze rispetto alla versione precedente.
1.	Occorre che le prescrizioni di accessibilit siano rese pi semplici e comprensibili, meno farraginose, indi pi facilmente implementabili: e ci viene realizzato riorganizzandone la struttura che ora ruota su solo 4 "Principi" di ciascuno dei quali le 12 Linee guida sono una articolazione.
Cos le Linee guida passano dalle 14 della versione 1.0 a solo 12 e diminuisce anche il numero dei "punti di controllo", o "criteri di successo", o se si vuole dei casi concreti di implementazione in cui ciascuna Linea guida si sostanzia e da cui dipende la sua applicazione che passano da 57 a 38 . 
2.	Le Linee guida sono formulate in modo indipendente dalla tecnologia utilizzata, anche proprietaria, purch dotata di documentazione pubblica e gratuita sul come implementare soluzioni accessibili per quella tecnologia, che soddisfino le Linee guida WAI.
Devono pertanto considerarsi "tecnologie accessibili" anche tecnologie proprietarie come:
- le presentazioni realizzate con Microsoft PowerPoint
- le animazioni realizzate con Macromedia Flash
- i documenti stampabili in formato Adobe PDF per cui esiste appunto la necessaria documentazione per la produzione di documenti pdf accessibili (Si veda la apposita sezione sul sito di Adobe Italia Pertanto, con le nuove Linee guida, non sar pi possibile eludere il problema dell'accessibilit di questo tipo di documenti, sostenendo che l'accessibilit riguardi solo i contenuti esposti sui siti e sia quindi solo un obbligo per i gestori degli stessi, convinzione in qualche modo ingenerata dalla formulazione della precedente versione delle Linee guida che faceva esclusivamente riferimento al linguaggio HTML e ai fogli di stile (CSS). La nuova versione corregge radicalmente il tiro estendendo le prescrizioni di accessibilit anche all'insieme dei documenti e dei contenuti veicolati attraverso il web, ci che qualcuno chiama "i documenti finali", ovvero ci che l'utente sta cercando, il fine, lo scopo dell'interazione.In poche parole non serve a molto poter raggiungere agevolmente una risorsa se poi, una volta acceduta, non se ne pu fruire. A questo tentano di sopperire le nuove Linee guida allargando enormemente il loro ambito di applicazione.
3.	Occorre che non solo l'HTML e i fogli di stile siano resi accessibili ma anche tutte le altre tecnologie affermatesi in questi anni nel web. Al riguardo sar bene ritornare sul sopra citatotechniques for WCAG 2.0 che si dimostra una "miniera" di implementazioni accessibili di singole funzionalit, cui gli sviluppatori e i gestori di contenuti possono attingere od ispirarsi . Per dare un quadro delle tec nologie accessibili faremo appunto riferimento a questo documento che le colleziona, evidenziando i collegamenti al quadro sinottico relativo alle implementazioni di ciascuna tecnologia, invitando gli interessati non anglofoni a dare la pagina in pasto al traduttore al solo scopo di farsi una idea della gamma di soluzioni disponibili, che peraltro basta copiare e incollare con gli adattamenti del caso nel codice delle applicazioni su cui si lavora . 
o	Tecniche generali, formulate in maniera indipendente dalla tecnologia, che quindi possono essere implementate in modi differenti, (200 esempi) General Techniques for WCAG 2.0 
o	Tecniche specifiche per i linguaggi di marcatura HTML e XHTML (91 esempi) 
Html and Xhtml Techniques for WCAG 2.0 
o	tecniche relative alla presentazione e impaginazione grafica dei documenti e la gestione di altri aspetti di presentazione dei contenuti mediante l'uso di fogli di stile a cascata (CSS, Cascading style shet) (30 esempi) CSS Techniques for WCAG 2.0
o	tecniche relative ai linguaggi di script lato Client, come Javascript, che permettono ai browser di modificare ed adattare al volo la pagina ricevuta dal server (37 esempi)
Client-side scripting techniques for WCAG 2.0
o	tecniche relative ai linguaggi di script sul lato server, come PHP o ASP, che creano dinamicamente le pagine a seguito del processo di "negoziazione" di cui si  parlato (6 esempi) Server-side scripting techniques for WCAG 2.0
o	tecniche relative all'uso del linguaggio SMIL (synchronized Multimedia Integration Language), un sottoinsieme del linguaggio di marcatura XML specifico per la sincronizzazione e l'integrazione di contenuti multimediali (14 esempi) SMIL techniques for WCAG 2.0
o	tecniche relative alla formattazione dei testi (3 esempi) Plain text Techniques for WCAG 2.0 
o	tecniche relative alle cosiddette (Accessibile and Rich Internet Applications, ARIA) con cui si modificano dinamicamente le propriet degli oggetti (4 esempi) ARIA Techniques for WCAG 2.0
o	tecniche per la implementazione di oggetti FLASH accessibili (15 esempi) Flash Techniques for WCAG 2.0 
o	tecniche relative all'accessibilit dei PDF (1 esempio) 
o	Infine 89 esempi di cose da non fare, di fallimento dei criteri di successo previsti dalle Linee guida Failures on Techniques for WCAG 2.0 
Torna al sommario 
I 4"Principi" e le nuove 12 Linee guida 
Dopo tutto ci che si  detto finora dovrebbe essere sufficiente la sola enunciazione delle Linee guida, la cui comprensione, almeno in prima approssimazione, dovrebbe essere pi o meno immediata da non richiedere ulteriori commenti.
Il W3C ha fatto un enorme sforzo per sintetizzare in soli quattro aggettivi qualificativi le qualit che deve possedere un web per dirsi accessibile: deve essere "percepibile", "usabile", "comprensibile" e "compatibile". Questi sono detti i 4 principi da cui discende ciascuna linea guida,individuata da una coppia di numeri di cui il primo fa riferimento al principio e il secondo al numero d'ordine nell'ambito del principio . 
Principio 1: Percepibile 
Le informazioni e i componenti dell'interfaccia utente devono essere presentati agli utenti in modo che possano essere percepiti . 
Linea guida 1.1: Alternative testuali: 
Fornire alternative testuali per qualsiasi contenuto non di testo in modo che questo possa essere trasformato in altre forme fruibili secondo le necessit degli utenti come stampa a caratteri ingranditi, Braille, sintesi vocale, simboli o un linguaggio pi semplice . (1 punto di controllo) (3) 
Linea guida 1.2:Tipi di media temporizzati: 
Fornire alternative per i tipi di media temporizzati.(4 punti di controllo) 
Linea guida 1.3 Adattabile<: 
Creare contenuti che possano essere rappresentati in modalit differenti (ad esempio, con layout pi semplici), senza perdita informazioni o di struttura (3 punti di controllo) 
Linea guida 1.4 Distinguibile: 
Rendere pi semplice agli utenti la visione e l'ascolto dei contenuti, separando i contenuti in primo piano dallo sfondo (5 punti di controllo) 
Principio 2: Utilizzabile 
I componenti e la navigazione dell'interfaccia utente devono essere utilizzabili . 
Linea guida 2.1 Accessibile da tastiera: 
Rendere disponibili tutte le funzionalit tramite tastiera. (2 punti di controllo 
Linea guida 2.2 Adeguata disponibilit di tempo: 
Fornire agli utenti tempo sufficiente per leggere ed utilizzare i contenuti (2 punti di controllo) 
Linea guida 2.3 Convulsioni: Non sviluppare contenuti che possano causare attacchi epilettici. (2 punti di controllo) 
Linea guida 2.4 Navigabile: 
Fornire delle funzionalit di supporto all'utente per navigare, trovare contenuti e determinare la propria posizione (7 punti di controllo) . 
Principio 3: Comprensibile 
Le informazioni e le operazioni dell'interfaccia utente devono essere comprensibili . 
Linea guida 3.1 Leggibile: 
Rendere il testo leggibile e comprensibile (2 punti di controllo) 
Linea guida 3.2 Prevedibile: 
Creare pagine Web che appaiano e che siano prevedibili (4 punti di controllo) . 
Linea guida 3.3 Assistenza nell'inserimento:
Aiutare gli utenti ad evitare gli errori ed agevolarli nella loro correzione (4 punti di controllo) . 
Principio 4: Robusto 
Il contenuto deve essere abbastanza robusto per essere interpretato in maniera affidabile mediante una vasta gamma di programmi utente, comprese le tecnologie assistive (2 punti di controllo) . 
Linea guida 4.1 Compatibile: 
Garantire la massima compatibilit con i programmi utente attuali e futuri, comprese le tecnologie assistive . 
Per illustrare ciascuna Linea guida e i punti di controllo in cui si articola, o i "criteri di successo" per cui pu dirsi soddisfatta, per ragioni di maggiore chiarezza espositiva rispetto alla traduzione italiana delle Linee guida, si far qui riferimento alla bozza di revisione dell'allegato relativo al Decreto di cui al prossimo paragrafo, il quale, invece della numerazione sopra esposta, con coppie di numeri che fanno riferimento anche al principio implicato, adotta una numerazione sequenziale da 1 a 12, pi facile da memorizzare.
Linea guida 1 - Alternative testuali
Punto di controllo 1 - Contenuti non testuali: Tutti i contenuti non testuali presentati all'utente devono possedere un'alternativa testuale equivalente che serva allo stesso scopo, ad eccezione delle seguenti situazioni:
1.	Controlli, input: se il contenuto non testuale  un controllo o raccoglie l'input degli utenti, allora questo deve avere un nome esplicativo che ne descriva la finalit;
2.	Contenuti audio, video, disegno animato (animazione): se il contenuto non testuale  presentato in formato audio, in formato video,  una animazione oppure  una combinazione di questi formati, allora deve essere fornita anche una alternativa testuale che contenga almeno una descrizione del contenuto non testuale;
3.	Test: Se il contenuto non testuale  un test o un esercizio che potrebbe essere non valido se presentato come testo, allora le alternative testuali devono fornire almeno una descrizione del contenuto non testuale.
4.	Esperienze sensoriali: Se il contenuto non testuale ha lo scopo primario di creare una specifica esperienza sensoriale, allora le alternative testuali devono fornire almeno una descrizione del contenuto non testuale.
5.	CAPTCHA: Se la finalit del contenuto non testuale  confermare che il contenuto viene utilizzato da una persona e non da un computer, allora devono essere fornite alternative testuali che identifichino e descrivano lo scopo del contenuto non testuale, e devono essere fornite forme alternative di CAPTCHA che utilizzino diverse modalit di output per differenti tipologie di percezioni sensoriali al fine di soddisfare differenti disabilit.
6.	Decorazioni, formattazioni, contenuti invisibili: Se il contenuto non testuale  puramente decorativo, oppure viene utilizzato solamente per formattazione visuale, oppure non viene presentato agli utenti allora deve essere realizzato in modo che la tecnologia assistiva lo possa ignorare.
Riferimento WCAG 2.0: Criterio di Successo 1.1.1
Linea guida 2 - Contenuti audio, contenuti video, animazioni
Punto di controllo 1 - Contenuti registrati presentati in formato solo audio, solo video o animazione senza audio: Per i contenuti registrati presentati in formato solo audio, solo video o come animazione senza audio, eccetto quando tali formati costituiscano una alternativa ad un contenuto testuale presente nella pagina e siano chiaramente etichettati come tali, devono essere soddisfatti i seguenti punti:
1.	contenuti registrati presentati in formato solo audio: deve essere fornita un'alternativa almeno di tipo testuale che presenti informazioni equivalenti a quelle del contenuto di solo audio
2.	contenuti registrati presentati in formato solo video o in formato contenente animazione senza audio: deve essere fornita un'alternativa almeno di tipo testuale che presenti informazioni equivalenti per il contenuto di solo video o della animazione senza audio.
Riferimento WCAG 2.0: Criterio di Successo 1.2.1
Punto di controllo 2 - Sottotitoli (per contenuti registrati): per tutti i contenuti registrati presentati in formati multisensoriali (video con audio, animazione con audio) devono essere forniti sottotitoli sincronizzati, eccetto quando tali formati costituiscano una alternativa ad un contenuto testuale presente nella pagina e siano chiaramente etichettati come tali.
Riferimento WCAG 2.0: Criterio di Successo 1.2.2
Punto di controllo 3 - Audio - descrizioni o trascrizioni descrittive (per contenuti registrati): quando i contenuti registrati vengono presentati in formato video o contengono animazioni e prevedono l'esecuzione di azioni non descritte tramite audio ma sono essenziali per la erogazione di un servizio deve essere fornita una descrizione audio alternativa oppure una descrizione testuale alternativa, eccetto quando tali elementi costituiscano una alternativa ad un contenuto testuale presente nella pagina e siano chiaramente etichettati come tali.
Riferimento WCAG 2.0: Criteri di Successo 1.2.3 e 1.2.5
Punto di controllo 4 - Sottotitoli (per contenuti in diretta): quando un contenuto presentato in diretta in formato audio, video o animazioni, o in formato multisensoriale  essenziale per la erogazione di un servizio allora devono essere forniti sottotitoli sincronizzati per il formato utilizzato.
Riferimento WCAG 2.0: Criterio di Successo 1.2.4
Linea guida 3 - Adattabile
Punto di controllo 1 - Informazioni e correlazioni: Le informazioni, la struttura e le correlazioni fra distinti blocchi di contenuto trasmesse dalla presentazione devono essere rese fruibili in qualsiasi situazione. Per ottenere questo risultato, esse possono essere definite tramite la tecnologia compatibile con l'accessibilit utilizzata oppure possono essere rese disponibili in formato testuale.
Riferimento WCAG 2.0: Criterio di Successo 1.3.1
Punto di controllo 2 - Sequenza significativa: Quando la sequenza con cui  presentato il contenuto influisce sulla percezione del suo significato, allora deve essere definita la corretta sequenza di lettura. Ci pu essere realizzato tramite la tecnologia compatibile con l'accessibilit utilizzata.
Riferimento WCAG 2.0: Criterio di Successo 1.3.2
Punto di controllo 3 - Caratteristiche sensoriali: Le istruzioni fornite per comprendere ed operare sui contenuti non devono basarsi unicamente su caratteristiche sensoriali dei componenti quali forma, dimensione, ubicazione visiva, orientamento o suono.
Riferimento WCAG 2.0: Criterio di Successo 1.3.3
Linea guida 4 - Distinguibile
Punto di controllo 1 - Uso del colore: (4) Il colore non deve essere utilizzato come unica modalit visiva per rappresentare informazioni, indicare azioni, richiedere risposte o come elemento di distinzione visiva.
Riferimento WCAG 2.0: Criterio di Successo 1.4.1
Punto di controllo 2 - Controllo del sonoro: Se un contenuto audio all'interno di una pagina Web  eseguito automaticamente per pi di tre secondi, allora deve essere fornita una funzionalit per metterlo in pausa o interromperlo, oppure deve essere fornita una modalit per il controllo del volume del contenuto audio che sia indipendente dal controllo predefinito del sistema.
Riferimento WCAG 2.0: Criterio di Successo 1.4.2
Punto di controllo 3 - Contrasto (minimo): La rappresentazione a monitor del testo e del testo rappresentato come immagine deve avere un rapporto di contrasto fra testo in primo piano e sfondo di almeno 4.5:1, fatta eccezione per i seguenti casi:
1.	Testo di grandi dimensioni: Un testo grande almeno 18 punti normale o 14 punti grassetto e/o un testo di analoghe dimensioni rappresentato come immagine  sufficiente che abbiano un rapporto di contrasto fra testo in primo piano e sfondo di almeno 3:1;
2.	Testo non essenziale: Un testo o un testo rappresentato come immagine che siano parti inattive di componenti dell'interfaccia utente, di pura decorazione, invisibili oppure che facciano parte di immagini contenenti contenuti visuali maggiormente significativi, non hanno alcun requisito di contrasto.
3.	Logotipi: Il testo che fa parte di un logo o marchio non ha alcun requisito minimo di contrasto.
Riferimento WCAG 2.0: Criterio di Successo 1.4.3
Punto di controllo 4 - Ridimensionamento del testo: Il testo, ad eccezione dei sottotitoli e del testo rappresentato come immagine, deve poter essere ridimensionato fino al 200 percento senza l'ausilio di tecnologie assistive e senza perdita di contenuto e funzionalit.
Riferimento WCAG 2.0: Criterio di Successo 1.4.4
Punto di controllo 5 - Testo rappresentato come immagine: Se le tecnologie utilizzate consentono di ottenere la corretta rappresentazione visuale, per veicolare l'informazione deve essere utilizzato testo invece di testo rappresentato come immagine, ad eccezione dei seguenti casi: (5)
1.	Personalizzabile: Se l'immagine che rappresenta testo pu essere personalizzata visivamente secondo le esigenze dell'utente, allora essa pu essere utilizzata senza dover ricorrere anche al testo;
2.	Essenziale: Se una particolare rappresentazione del testo  essenziale per il tipo di informazione veicolata, allora l'immagine che rappresenta testo pu essere utilizzata senza dover ricorrere anche al testo. I logotipi (testo che fa parte di un logo o di un marchio) sono considerati essenziali.
Riferimento WCAG 2.0: Criterio di Successo 1.4.5
Linea guida 5 - Accessibile da tastiera
Punto di controllo 1 - Tastiera: Tutte le funzionalit del contenuto devono essere utilizzabili tramite tastiera senza obbligare a tempi specifici per le singole battute, salvo il caso in cui la funzione sottostante richieda un input dipendente dai movimenti dell'utente che non possa essere ottenuto in modo equivalente con input da tastiera.
Riferimento WCAG 2.0: Criterio di Successo 2.1.1
Punto di controllo 2 - Nessun impedimento all'uso della tastiera: Se  possibile portare il focus su un componente della pagina tramite l'uso di una tastiera, allora deve anche essere possibile spostarsi ad un altro componente utilizzando comunque una tastiera. Se a tal fine non fosse sufficiente l'uso dei normali tasti Freccia o Tab o altri metodi di uscita standard, allora l'utente deve essere informato esplicitamente su come rilasciare il focus.
Riferimento WCAG 2.0: Criterio di Successo 2.1.2
Linea guida 6 - Adeguata disponibilit di tempo
Punto di controllo 1 - Regolazione tempi di esecuzione: Per ogni limite di tempo presente nel contenuto, deve essere soddisfatto almeno uno dei seguenti casi:
1.	Rimozione: All'utente  consentito rimuovere il limite di tempo prima di raggiungerlo;
2.	Regolazione: All'utente  consentito regolare il limite di tempo prima di raggiungerlo in una gamma di regolazioni che sia almeno dieci volte superiore alla durata prevista dall'impostazione predefinita;
3.	Estensione: L'utente  avvisato prima dello scadere del tempo; vengono concessi almeno 20 secondi per estendere il limite temporale tramite l'esecuzione di un'azione semplice (per esempio: "premere la barra spaziatrice") e gli  consentito di estendere il limite per almeno 10 volte;
4.	Eccezione per eventi in tempo reale: Il limite di tempo  un elemento fondamentale di un evento in tempo reale (per esempio, un'asta on line), e non  possibile eliminare questo vincolo;
5.	Eccezione di essenzialit: Il limite di tempo  essenziale per l'attivit (per esempio: una verifica a tempo) ed estenderlo l'invaliderebbe;
6.	Eccezione delle 20 ore: Il limite di tempo  superiore a 20 ore.
Riferimento WCAG 2.0: Criterio di Successo 2.2.1
Punto di controllo 2 - Pausa, stop, nascondi: Nel caso di animazioni, lampeggiamenti, scorrimenti o auto-aggiornamenti di informazioni devono essere soddisfatti tutti i seguenti punti:
1.	Spostamento, lampeggiamento, scorrimento: Per qualsiasi movimento, lampeggiamento o scorrimento di informazioni che (1) venga avviato automaticamente, (2) duri pi di cinque secondi e (3) sia presentato in parallelo con altro contenuto, deve essere presente un meccanismo per metterlo in pausa, interromperlo o nasconderlo, a meno che il movimento, il lampeggiamento o lo scorrimento siano parte essenziale dell'attivit;
2.	Auto-aggiornamento: Per qualsiasi auto-aggiornamento di informazioni che (1) venga avviato automaticamente e (2) sia presentato in parallelo con altro contenuto, deve essere presente un meccanismo per metterlo in pausa, interromperlo o nasconderlo o per controllare la frequenza dell'aggiornamento a meno che l'auto-aggiornamento sia parte essenziale dell'attivit.
Riferimento WCAG 2.0: Criterio di Successo 2.2.2
Linea guida 7 - Crisi epilettiche
Punto di controllo 1 - Lampeggiamenti: Le pagine Web non devono contenere nulla che lampeggi per pi di tre volte al secondo.
Riferimento WCAG 2.0: Criterio di Successo 2.3.2
Linea guida 8 - Navigabile
Punto di controllo 1 - Salto di blocchi: Deve essere fornita una modalit per saltare i blocchi di contenuto che si ripetono su pi pagine Web.
Riferimento WCAG 2.0: Criterio di Successo 2.4.1
Punto di controllo 2 - Titolo della pagina: Ogni pagina Web deve avere un titolo che ne descriva l'argomento o la finalit.
Riferimento WCAG 2.0: Criterio di Successo 2.4.2
Punto di controllo 3 - Ordine del focus: Se una pagina Web pu essere navigata in modo sequenziale e le sequenze di navigazione influiscono sul significato e sul funzionamento, allora gli oggetti che possono ricevere il focus devono riceverlo secondo un ordine che ne preservi il senso e l'operativit.
Riferimento WCAG 2.0: Criterio di Successo 2.4.3
Punto di controllo 4 - Scopo del collegamento (nel contesto): Lo scopo di ogni collegamento deve essere comprensibile. Esso pu essere determinato dal testo del collegamento oppure dal testo del collegamento in sinergia ai contenuti contestuali circostanti, che possono essere determinati mediante la tecnologia compatibile con l'accessibilit utilizzata, salvo il caso in cui lo scopo del collegamento potrebbe risultare ambiguo per la gran parte degli utenti.
Riferimento WCAG 2.0: Criterio di Successo 2.4.4
Punto di controllo 5 - Differenti modalit: Per identificare una pagina Web all'interno di un insieme di pagine Web deve essere resa disponibile pi di una modalit, salvo il caso in cui una pagina Web sia il risultato - o una fase - di un'azione.
Riferimento WCAG 2.0: Criterio di Successo 2.4.5
Punto di controllo 6 - Titoli ed etichette: Per descrivere l'organizzazione logica degli argomenti e la finalit dei blocchi di contenuto devono essere utilizzati titoli appropriati e nel corretto ordine sequenziale gerarchico. Inoltre, tutti i componenti interattivi devono essere dotati di etichette descrittive che ne chiariscano lo scopo
Riferimento WCAG 2.0: Criterio di Successo 2.4.6
Punto di controllo 7 - Focus visibile: Qualsiasi interfaccia utente utilizzabile tramite tastiera deve possedere una funzionalit operativa in cui  visibile l'indicatore del focus.
Riferimento WCAG 2.0: Criterio di Successo 2.4.7
Linea guida 9 - Leggibile
Punto di controllo 1 - Lingua della pagina: Deve essere definita la lingua di ogni pagina Web e la sua impostazione pu essere determinata mediante la tecnologia compatibile con l'accessibilit utilizzata.
Riferimento WCAG 2.0: Criterio di Successo 3.1.1
Punto di controllo 2 - Parti in lingua diversa da quella definita per la pagina : Deve essere definita la lingua di ogni passaggio o frase nel contenuto ed essa pu essere determinata mediante la tecnologia compatibile con l'accessibilit utilizzata ad eccezione di nomi propri, termini tecnici, parole in lingue indeterminate e parole o frasi che sono diventate parte integrante del gergo del testo immediatamente circostante.
Riferimento WCAG 2.0: Criterio di Successo 3.1.2
Linea guida 10 - Prevedibile
Punto di controllo 1 - Al focus: Quando un qualsiasi componente riceve il focus, non deve avviare automaticamente un cambiamento del contesto.
Riferimento WCAG 2.0: Criterio di Successo 3.2.1
Punto di controllo 2 - All'input: Il cambiamento dell'impostazione di qualsiasi componente nell'interfaccia utente non deve provocare automaticamente un cambiamento di contesto, a meno che l'utente sia stato informato di questo comportamento prima di utilizzare il componente.
Riferimento WCAG 2.0: Criterio di Successo 3.2.2
Punto di controllo 3 - Navigazione costante: I meccanismi di navigazione ripetuti su pi pagine Web all'interno di un insieme di pagine Web devono apparire nello stesso ordine ogni volta che si ripetono, a meno che l'utente non abbia avviato un cambiamento.
Riferimento WCAG 2.0: Criterio di Successo 3.2.3
Punto di controllo 4 - Identificazione coerente: I componenti che hanno la stessa funzionalit all'interno di un insieme di pagine Web devono essere sempre identificati in modo uniforme.
Riferimento WCAG 2.0: Criterio di Successo 3.2.4
Linea guida 11 - Assistenza nell'inserimento di dati e informazioni
Punto di controllo 1 - Identificazione di errori: Se viene rilevato automaticamente un errore di inserimento, l'elemento in errore deve essere identificato chiaramente e l'errore rilevato descritto tramite testo.
Riferimento WCAG 2.0: Criterio di Successo 3.3.1
Punto di controllo 2 - Etichette o istruzioni: Quando il contenuto richiede azioni di input da parte dell'utente devono essere fornite etichette o istruzioni per la loro corretta esecuzione.
Riferimento WCAG 2.0: Criterio di Successo 3.3.2
Punto di controllo 3 - Suggerimenti per gli errori: Se viene identificato un errore di inserimento che si pu correggere allora devono essere forniti suggerimenti all'utente, a meno che ci non pregiudichi la sicurezza o la finalit del contenuto.
Riferimento WCAG 2.0: Criterio di Successo 3.3.3
Punto di controllo 4 - Prevenzione degli errori (legali, fina nziari, dati): Per le pagine Web che determinano obbligazioni giuridiche o che prevedono transazioni finanziarie, o che gestiscono inserimento, cancellazione, gestione di dati controllabili dall'utente in un sistema di archiviazione oppure che inoltrano risposte a test, deve essere soddisfatta almeno una delle seguenti condizioni:
1.	Reversibilit: Le azioni sono reversibili.
2.	Controllo: I dati inseriti dall'utente sono verificati e si fornisce all'utente la possibilit di correggere eventuali errori di inserimento.
3.	Conferma:  disponibile una funzionalit per la revisione, conferma e correzione delle informazioni prima del loro invio definitivo.
Riferimento WCAG 2.0: Criterio di Successo 3.3.4
Linea guida 12 - Compatibile
Punto di controllo 1 - Analisi sintattica (parsing): Nel contenuto realizzato utilizzando linguaggi di marcatura gli elementi devono possedere tag di apertura e chiusura completi, devono essere annidati in conformit alle specifiche, non devono contenere attributi duplicati e devono possedere ID unici, salvo il caso in cui le specifiche permettano eccezioni. (6)
Riferimento WCAG 2.0: Criterio di Successo 4.1.1
Punto di controllo 2 - Name, Role, Value: Per tutti i componenti dell'interfaccia utente (inclusi ma non limitati a: elementi di un modulo, collegamenti e componenti generati da script), name (nome) e role (ruolo) devono poter essere determinati mediante la tecnologia compatibile con l'accessibilit utilizzata; stati, propriet e valori che possono essere impostati dall'utente devono essere impostabili da programma; e le notifiche sui cambi di stato di questi elementi devono essere rese disponibili ai programmi utente, incluse le tecnologie assistive.
Riferimento WCAG 2.0: Criterio di Successo 4.1.2 
Torna al sommario 
Il Decreto in emanazione che recepir le nuove linee guida 
L'art. 12 della citata legge 9 gennaio 2004 recita:
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 procedura, per il tempestivo recepimento delle modifiche delle normative di cui al comma 1 e delle innovazioni tecnologiche nel frattempo intervenute. 
Subito dopo la pubblicazione delle nuove Linee guida da parte del W3C si sono attivati i gruppi di lavoro presso la segreteria tecnica della CommissiOne interministeriale per l'ICT a favore delle categorie deboli e svantaggiate, presso il Cnipa, proponendo una bozza di Decreto che di fatto recepisce lo spirito ed anche la lettera delle nuove linee guida WAI.
Come gi fu fatto nel 2001 con la circolare n. 32 dell'Aipa, si  scelto lo stile con cui si formano gli standard in internet, ovvero la bozza  stata esposta sul sito accessibile.gov.it, del ministero dell'innovazione e della funzione pubblica, allo scopo di raccogliere commenti e integrazioni, passando, dopo un congruo lasso di tempo, al vaglio dell'Ufficio legislativo del competente ministero, per essere sottoposto all'esame della UE di cui si attende l'esito, prima della promulgazione che dovrebbe avvenire entro l'anno.
Nel paragrafo precedente si  attinto a questo testo per illustrare le Linee guida, (nella bozza chiamate "Requisiti"), e i punti di controllo ad esse relative.
Ora saranno qui riportati altri stralci che chiariscono bene l'ambito di applicazione (la premessa), l'indicazioni di una metodologia per la valutazione dell'accessibilit di una pagina o un documento (Indipendenza dalla piattaforma) e i criteri di conformit cui deve sottostare una pagina o un documento per definirsiaccessibile.
Bozza nuovi requisiti e punti di controllo per l'accessibilit Web
Pubblicato il 10/06/2010 "Criteri e metodi per la verifica tecnica e requisiti tecnici di accessibilit per i contenuti e i servizi forniti per mezzo di applicazioni basate su tecnologie Web" 
(Revisione dell'allegato A del DM 8 luglio 2005) versione 26 aprile 2010 
Premessa 
In questo documento sono definiti:
1.	i criteri ed i metodi con i quali va effettuata la verifica tecnica di cui all'articolo 11, comma 1, lettera b) della Legge 4/2004; 
2.	i requisiti tecnici di accessibilit di cui all'articolo 11, comma 1, lettera a) della Legge 4/2004 e gli elementi da considerare per la verifica di conformit ai requisiti . 
I requisiti tecnici si applicano a tutti i casi in cui i soggetti di cui all'articolo 3 comma 1 della Legge 4/2004 forniscono informazioni o servizi su reti Internet, Intranet o Extranet, su supporti informatici removibili (quali ad esempio CD-ROM, DVD) utilizzabili anche in caso di stazione di lavoro non collegata ad una rete telematica . Le informazioni ed i servizi erogati possono essere resi fruibili mediante:
	siti Web; 
	applicazioni realizzate con tecnologie Web; 
	documenti resi disponibili sui siti Web; 
	documenti di cui al requisito 11 dell'allegato D del DM 8 luglio 2005; 
	materiale formativo e didattico di natura digitale utilizzato nelle scuole di ogni ordine e grado.
Indipendenza dalla piattaforma
Le informazioni e i servizi erogati devono essere fruibili su varie piattaforme e su diversi browser.
Tecnologie compatibili con l'accessibilit
Una tecnologia  definita compatibile con l'accessibilit quando  compatibile con le tecnologie assistive e con le funzioni di accessibilit dei browser e degli altri programmi utilizzati dall'utente.
Nell'ambito di applicazione della Legge 4/2004 sono da ritenersi compatibili con l'accessibilit:
1. le tecnologie di base che sono definite da:
	la norma ISO/IEC 15445:2000(E) (HTML);
	la norma ISO/IEC 16262:2002 (ecma-script), nota anche come standard ECMA 262;
	le Recommendation del W3C relative al linguaggio HTML nella versione 4.01 e successive e al linguaggio XHTML nella versione 1.0 e successive;
	le Recommendation del W3C relative al linguaggio CSS nella versione 1.0 e successive;
	le Recommendation del W3C relative a linguaggi e a specifiche tecniche relative alla realizzazione di pagine, oggetti e applicazioni Web, quali, ad esempio, XML, SVG, SMIL.
Nell'utilizzo delle tecnologie di base  obbligatorio rispettare i seguenti vincoli:
	Per la tecnologia utilizzata,  obbligatorio dichiarare esplicitamente, quando previsto, la grammatica formale adottata.
	 vietato l'utilizzo degli elementi, degli attributi e delle funzioni sconsigliate nella specifica della grammatica formale adottata.
	Il codice impiegato deve essere valido rispetto alla grammatica formale adottata.
2. le tecnologie per le quali sono verificate tutte le seguenti condizioni:
1.	esistono e sono disponibili in forma gratuita le linee guida sulla accessibilit relative alla tecnologia in oggetto. Tali linee guida possono essere state elaborate e rese pubbliche dai produttori della tecnologia oppure da organismi e istituzioni pubbliche e private, anche internazionali, operanti nel settore della accessibilit;
2.	in tali linee guida sono esplicitamente indicate le modalit di applicazione dei Criteri di Successo delle WCAG 2.0 alla tecnologia in oggetto.
3.	i programmi che l'utente deve eventualmente utilizzare per la fruizione della tecnologia in oggetto devono supportare le tecnologie assistive.
Criteri di conformit
Affinch una pagina Web possa essere dichiarata conforme ai requisiti tecnici devono essere osservati i seguenti criteri:
1.	Totalit dei requisiti tecnici: tutti i requisiti tecnici di accessibilit, quando applicabili, devono essere soddisfatti;
2.	Pagine complete: la conformit va riferita ad intere pagine Web;
3.	Processi completi: quando un servizio  erogato mediante un processo che si sviluppa su pi pagine Web allora tutte le pagine Web ad esso relative devono essere conformi, anche quando tali pagine si trovino su siti diversi;
4.	Utilizzo di sole tecnologie compatibili con l'accessibilit: le pagine, gli oggetti in esse contenuti e le applicazioni realizzate con tecnologie web devono essere realizzati con le tecnologie compatibili con l'accessibilit come definite in precedenza;
5.	Formato e contenuto dei documenti: tutti i documenti pubblicati necessari a fornire informazioni o a erogare servizi e tutti i materiali didattici e formativi devono essere resi disponibili in formati digitali utilizzabili con tecnologie compatibili con l'accessibilit come definite in precedenza e il loro contenuto deve essere conforme ai requisiti tecnici di accessibilit.
Nel caso di materiali didattici e formativi basati su tecnologie Web, oltre alla conformit ai requisiti tecnici descritti in questo allegato  richiesta la conformit anche a quanto stabilito dal Decreto Ministeriale 30 aprile 2008 "Regole tecniche disciplinanti l'accessibilit agli strumenti didattici e formativi a favore degli alunni disabili" (G.U. n.136 del 12 giugno 2008).
Se un documento non risponde a queste caratteristiche, per sua natura o perch  disponibile solo in formato non conforme oppure per vincoli di tipo giuridico (ad esempio: obbligo di pubblicazione in formato immagine di documenti corredati da firme autografe e bolli), allora deve essere soddisfatto almeno uno dei seguenti punti:
	i contenuti e i documenti devono essere resi disponibili nella loro completezza anche in forma adatta ad essere fruita mediante le tecnologie compatibili con l'accessibilit ed essere conformi ai requisiti tecnici di accessibilit;
	per i documenti resi disponibili in formato non compatibile con l'accessibilit, oppure che abbiano contenuti non conformi ai requisiti tecnici di accessibilit, devono essere forniti sommario e descrizione degli scopi dei documenti stessi in forma adatta ad essere fruita con le tecnologie compatibili con l'accessibilit e devono essere indicate in modo chiaro le modalit di accesso alle informazioni equivalenti a quelle presentate nei documenti digitali non accessibili, come indicato nell'articolo 54, comma 1, punto b. del Dlgs 82/2005 "Codice dell'amministrazione digitale" come modificato dal Dlgs 159/2006 e successive integrazioni. 
Torna al sommario 
 
NOTE ED APPROFONDIMENTI
Nota 1
Non deve sorprendere che approcci progettuali orientati al "design for all" abbiano trovato applicazione sia nella progettazioni di spazi urbani che nella architetture di sistemi informatici; Cos ad esempio il Pattern language codificato dall'architetto americano Christopher Alexander nasce come una metodologia per la riqualificazione di aree urbane degradate per approdare allo sviluppo software e alla programmazione ad oggetti.
Si tratta di una metodologia di progetto il cui punto di forza  la partecipazione degli utenti fin dalle prime fasi della progettazione e in cui il ruolo del tecnico  quello di proporre soluzioni con diverse opzioni lasciando la scelta agli utenti.
Attraverso una scomposizione del progetto complessivo in specifiche aree di intervento e la successiva riconduzione ad unit organica dello stesso, mediante l'analisi delle criticit e la composizione dei conflitti, si giunge ad un progetto organico e condiviso . Per approfondire si segnalano alcune risorse in lingua italiana:
	un esempio della metodica applicato al web dal sito del Consorzio interuniversitario europeo Minerva il secondo capitolo del
Manuale per la qualit dei siti web pubblici culturali 
	per una introduzione alla metodica e applicazioni nell'architettura 
	materiali dal laboratorio TIPUS
(tecnologie dell'informazione per una progettazione urbana sostenibile) diretto dal prof. Alessandro Giangrande, facolt di architettura, universit Roma3 
Introduzione al "pattern language" di Alessandro Giangrande
Progettazione partecipata a scala urbana col supporto della rete
Bilancio partecipativo del IX municipio di roma coordinato dall'universit Roma3 
	Altre risorse relative al "design for all" in architettura:
	documentato, ricco e interessante il materiale dei corsi post-laureadella facolt di architettura universit La Sapienza dal titolo "PROGETTARE PER TUTTI" coordinati dai 1992 dal prof. architetto Fabrizio Vescovo:
Progettare per tutti Home page
Contributi didattici e informativi a tali corsi
Parchi per tutti: Fruibilit per una utenza ampliata (disabili, anziani, bambini).
Come si vede l'accessibilit in senso architettonico  oggi oggetto di specializzazione post-laurea, e ci ha seguito della normativa specifica prevista dalla legge 104/92 e successive integrazioni.
La normativa contro le barriere architettoniche virtuali  molto pi tardiva, risalente al 2004 e dunque non  stata ancora completamente metabolizzata.
Torna su 
Nota 2
La tecnologia informatica prometteva, e in parte ha mantenuto la promessa, di aprire a noi disabili opportunit prima inimmaginabili.
Per esemplificare, personalmente ebbi notevoli problemi a trovare chi leggesse e registrasse i libri per gli esami all'universit.
Ora, almeno in teoria, potrei acquistarli comodamente da casa in formato digitale come ebook e studiarli, annotarli, stralciarli.
Cos, fin dalla fine del secolo scorso, alcuni di noi disabili cominciammo a scrivere lettere di richiesta o di protesta a testate, case editrici, responsabili di siti istituzionali, politici, per chiedere di non essere esclusi da queste opportunit, per noi particolarmente importanti . 
La pubblicazione delle Linee guida WAI mi convinse che il problema dell'accessibilit del web, coincidendo con interessi del mercato, travalicasse ormai lo specifico problema dei disabili, riconducendosi a problema generale.
Con una campagna telematica al limite dello spam promossi una petizione all'allora Autorit Informatica per la Pubblica Amministrazione (AIPA), in cui si denunciava l'inaccessibilit di alcuni tra i maggiori siti istituzionali, come l'Inps, la Rai, l'Agenzia delle entrate e si chiedeva: 
	che l'Aipa si adoperasse per giungere a una normativa che impegnasse per legge le P.A. ad adottare le linee guida WAI; 
	che si costituisse un gruppo di lavoro con esponenti delle Amministrazioni centrali che promuovesse l'accessibilit negli ambiti di competenza; 
	che emanasse una serie di raccomandazioni alle P.A.che ricalcasserole raccomandazioni WAI del W3C . 
Insieme a pochi altri disabili, visivi e motori, per tutti impegnati nello sviluppo di softwares assistivi, CHIEDEMMO UNA AUDIZIONE ALL'aIPA, APPOGGIATI ANCHE DALLA FONDAZIONE aSPHI, DI CUI L'iNPS  SOCIO FONDATORE.
Fu cos costituito il gruppo di lavoro "accessibilit E TECNOLOGIA informatica NELLA pubblica amministrazione" di cui ho fatto parte e la cui breve attivit pu essere cos riassunta: 
1.	predisporre il testo di quella che sarebbe stata la prima norma italiana organica in materia di accessibilit, la circolare Aipa n. 32 del 6 settembre 2001. 
2.	il primo corso sull'accessibilit rivolto ai dirigenti statali in collaborazione con la scuola superiore per la pubblica amministrazione 
3.	inserire il problema della accessibilit nelle norme tecniche per il telelavoro, sempre emanate nel 2001 dall'Aipa 
4.	sensibilizzare l'opinione pubblica al problema curando l'edizione del libro I disabili nella societ dell'informazione, edito da Franco Angeli, scritto a pi mani e che raccoglieva le esperienze in merito di alcune amministrazioni centrali, compresa l'Inps 
5.	avviare una rilevazione statistica sull'accessibilit dei siti pubblici, in collaborazione con l'universit Roma3 
6.	mettere a disposizione delle amministrazioni una risorsa dedicata all'accessibilit, su cui reperire norme, studi, pubblicazioni, quaderni di approfondimento, e altri documenti di interesse. Si tratta del sito Pubbliaccesso.it
Sebbene non sia pi aggiornato continua tuttavia ancora oggi a rivelarsi utile base documentale, ed anche in questo articolo sono contenuti parecchi rinvii a tale sito 
Tutto ci per non bastava.
L'Aipa poteva solo emanare disposizioni tecniche, non poteva cio costringere le amministrazioni a fare siti e servizi accessibili. Ancor meno avrebbe potuto in seguito quando l'Autorit fu soppressa e le sue competenze passate al Cnipa, cio ad una delle 60 amministrazioni centrali e pertanto senza alcun potere sulle altre.
Cos gi dal 2000 inviai a tutti i deputati una proposta di disegno di legge in materia.
All'epoca internet conosceva da noi l'esplosione di massa e quindi si cre una notevole attenzione al tema, cosicch praticamente ogni gruppo politico formul propri disegni di legge, pi o meno ispirandosi al mio testo.
Ne furrno presentati ben 10, i cui testi sono reperibili sul summenzionato sito 'pubbliaccesso.it": Progetti di legge sull'accessibilit dei siti della P.A.
In particolare va detto che tra questi 10 due, rispettivamente di maggioranza e di opposizione, riprendevano quasi per intero il mio testo, e ciascuna superava il centinaio di parlamentari proponenti.
La Ue dichiara il 2003 "Anno Europeo del Disabile" che si chiuder col semestre di presidenza italiana e pertanto si decide di accellerare l'iter parlamentare di una legge in materia tramite un disegno di iniziativa governativa: L'ufficio legislativo dell'allora ministro per l'innovazione Lucio Stanca si incaric di presentare un unico disegno di legge di iniziativa del governo, che perci porta ancora il suo nome, che fu approvato all'unanimit.
Fatta la legge bisognava ora vigilare sulla sua attuazione, evitare derive formalistiche che ne vanificassero la portata, correggere buchi e difetti di formulazione e di impianto, seguire l'evoluzione delle tecnologie, diffondere questo tipo di informazione.
A mia conoscenza la legge 9 gennaio 2004  stata l'unica legge promossa esclusivamente tramite internet, non solo nella fase di promozione e di formulazione ma anche durante tutto l'iter parlamentare, e in fase di stesura dei decreti attuativi al cui dibattito ho partecipato ampiamente.
Ho infine seguito con particolare attenzione gli sviluppi normativi per quanto concerne i libri di testo scolastici in formato digitale accessibile e il materiale formativo seguendo con favore l'affermazione di standard aperti di publishing come il formato "EPUB", potenzialmente pi accessibile di altri in quanto basato su tecnologie web, come XML e XHTML, per cui esiste una cultura e delle regole consolidate di accessibilit, anche se allo stato ci risulta vero solo per gli ebook distribuiti senza DRM e per i sistemi Apple in quanto per ora sotto Windows risulta totalmente ingestibile agli utenti che utilizzano screen-reader il programma di accesso, ovvero Adobe Digital Edition.
Ho anche promosso, nel mio piccolo, la diffusione di altri documenti del W3C pi o meno connessi all'accessibilit, come principi e tecniche per una progettazione indipendente dai dispositivi.
Resto a disposizione per chiarimenti, suggerimenti, rettifiche, Non esitate a contattarmi.
Torna su 
Nota 3
Molto opportunamente le nuove Linee guida chiariscono che gli "equivalenti testuali" di contenuti non di testo (grafici e altri contenuti multimediali) devono rappresentare in formato testuale la sostanza del contenuto informativo veicolato attraverso l'oggetto multimediale.
Una interpretazione riduttiva ed un po fuorviante riduceva il problema alla scrupolosa etichettatura di ogni immagine ed elemento grafico o al tentativo di descrivere ogni elemento decorativo che appariva a video.
Risultato: accedendo con uno screen-reader o con un cellulare con le immagini disattivate, sentirsi annunciare o vedere a display cose del tipo:
"ombreggiatura leggera", "linea tratteggiata" o "formula del calcio" o "Andamento del dollaro"
Nei primi due casi infatti ci si traduce solo in una fastidiosa interruzione del flusso di lettura del documento, che nulla aggiunge al contenuto informativo; nei secondi due si rivela quasi una beffa: nulla spiega la disposizione degli atomi e dei legami nella immagine della formula del calcio, men che meno l'utente viene a sapere dell'andamento del dollaro.
Per chiarire ulteriormente il concetto porremo un caso molto ricorrente in forma paradossale:
sulla Home page di molti siti campeggia la foto del "Presidente", altrettanto spesso etichettata come "Foto del Presidente".
Come bisogna intendere questa etichettatura?
La foto del Presidente deve considerarsi un elemento decorativo del sito e dell'immagine dell'azienda e in tal caso l'etichettatura potrebbe essere anche omessa, dal momento che non aggiunge alcun contenuto informativo, eccetto quello di notificare che anche su quel sito, come su tanti altri, c' la foto del Presidente in primo piano.
Se invece si intende proprio enfatizzare l'aspetto fisico del Presidente sar necessario fornire allora una "descrizione lunga" della foto del tipo:
Altezza 154 cm.; giro-vita 102 cm.; taglia XL, calzatura sportiva 43;
capelli un tempo castani; occhi grigi, testaimponente; padiglioni commisurati allo status.
In questo caso anche chi  cieco, ha pochi soldi sulla scheda prepagata ed ha disattivato le immagini, potr farsi una idea dell'aspetto fisico del Megapresidente.
C' ovviamente anche la soluzione di presentare una scheda molto descrittiva dello stesso, coredata di foto, etichettata o meno.
Torna su 
Nota 4
Sebbene anche la precedente versione delle Linee guida WAI avesse esplicitamente raccomandato di non fare affidamento sul solo colore, spesso nella pratica ci viene disatteso.
Pu capitare di incontrare siti di e-commerce che visualizzano i loro cataloghi, contrassegnando con colori diversi gli articoli presenti, quelli mancanti, o quelli scontati o si possono incontrare applicazioni che utilizzano il colore per inviare delle segnalazioni all'utente, per esempio sullo stato dell'iter di una pratica, sulla possibilit o meno di evadere una determinata richiesta, o sull'esito di un quiz risolto dall'utente.
Basta solo fare mente locale sul fatto che in giro per il mondo esistono ciechi, anziani che non distinguono pi i colori, daltonici, tante persone nei paesi in via di sviluppo che accedono ad internet con vecchie carcasse in "bianco e nero" donate dalle ONG per rendersi conto che, se non si vuole escludere da quella specifica informazione queste persone, bisogner, accanto al colore, prevedere meccanismi alternativi di segnalazione come contrassegnare anche con un "+" gli articoli scontati e con un "-" quelli mancanti e aggiungere alla didascalia:
"gli articoli scontati sono evidenziati inarancio e marcati con un +, 
quelli mancanti in rosso e marcati da un -"
o da messaggi esplicativi se il cambiamento di colore di un elemento dipende da una azione, da una scelta dell'utente o sia il risultato di una interazione.
Purtroppo questo problema riguarda spesso anche la presentazione di dati statistici e gestionali da parte delle P.A che sono tenute per legge a garantire la trasparenza dell'azione amministrativa.
Torna su 
Nota 5
Anche qui molto opportunamente le nuove Linee guida WAI dettano una serie di prescrizioni in materia di testi pubblicati in formato immagine, o, se si preferisce, di "immagini contenenti testo", stabilendo adeguati livelli di contrasto per assicurarne la leggibilit.
A giudizio di chi scrive questo  forse l'aspetto che presenta i principali problemi di accessibilit, sia sul piano qualitativo con l'esclusione totale di notevoli fasce di utenza, sia sul piano quantitativo per la enorme quantit di documenti pubblicati con questa modalit, con particolare riferimento alla documentazione e modulistica stampabile in formato Adobe PDF, che costituisce molto spesso l'obbiettivo finale dell'accesso dell'utente.
Le ragioni per cui ci avviene sono diverse ma su di esse bisogna intervenire se si vuole operare realmente per l'accessibilit, tutte schematicamente riconducibili alle seguenti:
1.	Abbiamo mostrato come la precedente versione delle Linee guida avesse, nei casi in cui  prevalsa una interpretazione troppo formalistica, in qualche modo ingenerato la convinzione che l'accessibilit riguardasse solo le pagine web e competesse solo ai gestori di siti e non riguardasse invece i documenti cui si accede attraverso siti e portali.
2.	I documenti da esporre sui siti vengono predisposti dagli uffici competenti, i quali hanno, per quanto sopra detto, scarsa o nulla cognizione del problema dell'accessibilit, che sono convinti non li riguardi, e su cui i gestori dei siti non hanno alcun titolo per intervenire, se anche volessero.
3.	In molti casi il documento pubblicato come immagine  la fotocopia digitale di un documento cartaceo, disponibile solo in questo formato perch magari proveniente da fonte esterna.
4.	Il problema non  facilmente percepibile da un operatore disinformato in quanto, se apre il documento ne potr leggere il contenuto testuale senza alcun problema e senza neanche immaginare che questo possa essere un problema per qualcuno.
5.	Si ritiene erroneamente che, essendo il formato Adobe PDF accessibile perch il programma Adobe Reader possiede delle funzionalit per il controllo della struttura e per l'accessibilit, qualsiasi documento salvato in questo formato, magari a seguito di acquisizione tramite scanner del cartaceo, debba risultare accessibile per definizione. Ovviamente cos non  affatto, ma non lo  ugualmente se la stessa immagine di un testo cartaceo si incolla in un documento di un elaboratore di testi come Microsoft Word.
6.	semplicemente si ignora che cos facendo il documento  invisibile anche ai motori di ricerca e dunque anche agli utenti che li stanno cercando per loro tramite, a riprova di quanto si  qui sostenuto, che cio piccole attenzioni per una ristretta categoria di utenti producono benefici per tutti e viceversa.
Per quanto riguarda l'istituto, sul sito sono pubblicati moltissimi documenti stampabili in formato Adobe PDF. Molti di essi, come circolari e altre comunicazioni, che hanno a monte un processo di elaborazione e di strutturazione, risultano pienamente accessibili, mentre ve ne sono parecchi altri che non lo sono per nulla, specie sulla intranet, costituiti da una unica immagine contenente l'intero documento.
Si potrebbe obbiettare che non  pensabile modificare il modo di lavorare degli uffici solo per permettere a qualche "mosca bianca dipendente disabile" di visionare tramite intranet poniamo le gare d'appalto bandite dall'istituto in una certa regione, ma non si tratta di escludere qualcuno che non si capisce perch dovrebbe essere interessato alla questione, ma si escludono proprio tutti gli utenti, che, appunto perch interessati, disabili e non, usano il motore di ricerca interno.
Le Linee guida indicano esplicitamente una serie di possibili soluzioni assolutamente praticabili nella maggior parte dei casi, poich, nell'era digitale, praticamente non esiste quasi pi documento cartaceo che prima non sia stato un file e da cui si possa quindi partire per fornire l'"equivalente testuale" della sua immagine,ma, perch ci sia realmente praticato, occorre:
1.	che chi si occupa della produzione e pubblicazione dei documenti sia informato e sensibilizzato alla problematica ed anche istruito a riconoscere questo tipo di files, adottando piccole, banalissime attenzioni come aprire il documento da pubblicare con Adobe reader ed effettuare una delle seguenti semplici prove:
A) - attivare la lettura a voce alta di Adobe reader, che rester muto nel caso di file pdf costituito da una unica immagine;
B) - salvare una copia dello stesso in formato "txt" che restituir in questi casi un file vuoto;
C) - utilizzare le funzioni di accessibilit del reader.
2.	che gli uffici prendano in considerazione, quando non  possibile risalire a un file accessibile contenente il testo del documento da pubblicare in aggiunta allo stesso, perch ad esempio si dispone solo del cartaceo, specie in presenza di notevoli flussi documentali con queste caratteristiche, la possibilit di estrarre i testi da files di immagine trattandoli con softwares di riconoscimento ottico (OCR), oggi a basso costo e sufficientemente affidabili.
3.	che le unit incaricate della stesura dei documenti siano indotte a creare documenti fin dall'inizio accessibili, anche stampabili, utilizzando le normali funzionalit dei programmi di "office automation" che sempre danno la possibilit di strutturare ed eventualmente marcare i diversi elementi. Al riguardo si segnala, sempre dal succitato "pubbliaccesso.it"Accessibilit dei documenti elettronici, di Livio Mondini, realizzata in formato Adobe PDF accessibile, che spiega brevemente come ottenere pdf accessibili a partire dal popolarissimo Microsoft Word, o da Adobe Acrobat professional, in quanto la filosofia e il modus operandi sono nella sostanza esportabili in tutti gli ambienti di "Office Automation".
4.	che gli uffici siano avvisati dell'inaccessibilit di questo tipo di files, anche attraverso servizi di "back-office" che li segnalino ed eventualmente suggeriscano semplici soluzioni per ovviare al problema.
5.	che quando sia necessario, magari per ragioni di validit legale (timbri, firme autografe) pubblicare il testo in formato immagine, ad esso sia sempre affiancato l'"equivalente testuale" adottando formati molto comuni perch evidentemente non si pu immaginare di costringere gli utenti ad acquistare l'ultimissima versione di Microsoft Word o di Microsoft Excel solo per accedere al testo contenuto nella fotocopia digitale di un documento di interesse. Oltre al formato "txt" che ha il pregio di essere leggibile assolutamente da tutti gli utenti alfabetizzati ma ha il grave difetto di non trasmettere alcuna informazione di struttura e di formattazione, possono essere utilizzati efficacemente formati come html, xhtml, rtf, che, quando non contengono immagini, risultano quasi altrettanto leggeri del "txt" in termini di dimensioni, ovvero occupano pochissimo spazio sui siti e quindi si scaricano velocemente. Possono andare bene anche formati come il "doc" o "xls", tenendo conto di quanto appena detto: mentre documenti con Office 97 oggi praticamente si aprono con parecchi altri programmi da potersi considerare leggibili anche senza la suite di Microsoft, ci non vale ad esempio con gli equivalenti "docx" e xlsx" delle ultime versioni.
6.	Infine, per quanto riguarda lo specifico dell'istituto, sarebbe molto opportuno che nei corsi di formazione per dirigenti sulla gestione dei flussi documentali, di cui dovrebbe partire a breve la seconda fase a livello delle sedi regionali, ci fosse adeguata informazione su queste problematiche e sulle loro possibili soluzioni.
Torna su 
Nota 6
Ad una prima superficiale lettura pu sembrare perfino strano, parlando di accessibilit, il richiamo contenuto nelle Linee guida, (anche nella versione precedente), ad adottare grammatiche pubbliche per la marcatura dei documenti, ad utilizzarne le regole sintattiche in modo rigoroso, evitando gli elementi sconsigliati.
In realt un uso corretto del linguaggio di marcatura  di fatto un prerequisito dell'accessibilit, secondo l'adagio per cui "chi bene comincia  a met dell'opera".
Normalmente i browsers sono oggi molto flessibili e riescono spesso ad interpretare correttamente anche codice non corretto o usato in modo inappropriato. Tuttavia non tutti i browsers sono flessibili allo stesso modo e non tutti gli utenti navigano con versioni aggiornate degli stessi. Per tutti i browsers sono capaci di interpretare correttamente un codice corretto, comprese le tecnologie assistive.
inoltre il controllo formale del codice, attraverso i RAPPORTI dei programmi di validazione, evidenzia problemi e criticit che altrimenti sfuggirebbero. Pertanto  ottima regola effettuare sempre il controllo di validit delle pagine e allo scopo si rivela molto utile il servizio di validazione online approntato dal W3C The W3C mark-up validation service che permette di controllare la validit del codice dei principali linguaggi di marcatura a partire dall'indirizzo di una pagina, dall'invio di un file per la convalida, dalla immissione diretta di frammenti di codice.
Questo  appunto il caso del presente testo il quale, essendo costituito da un semplice "ipertesto" e non includendo immagini e altri contenuti multimediali, non presenta particolari problemi di accessibilit per cui il solo controllo formale del codice e la presenza di meccanismi di navigazione tra le sue sezioni e collegamenti, risulta sufficiente a garantirne una corretta fruizione da parte di tutti.
Esistono anche, sebbene quasi sempre a pagamento e riferiti alla precedente versione delle Linee guida, specifici programmi per la valutazione dell'accessibilit di una pagina o di un sito che restituiscono RAPPORTI dettagliati sulla rispondenza del codice alle Linee guida WAI, come Bobby o Torquemada, che possono essere proficuamente utilizzati dai fornitori di contenuti, avendo per ben chiaro:
1.	che scopo di tali programmi  quello di assistere nella produzione di documenti accessibili, non quello di distribuire "attestati di accessibilit" da esibire; 
2.	che, per quanto sofisticati, sono sempre il frutto di elaborazioni automatiche, in qualche caso distanti dalle esigenze reali cosicch ci si pu imbattere in siti usabili e accessibili anche se non sono ritenuti tali da programmi come Bobby e simili, ed al contrario avere problemi di usabilit su siti che espongono tutti i possibili loghi di accessibilit . 
Torna su 

