ti trovi in: Home Page - Webmaster - Progetto ASSI - Allegato tecnico -
Il progetto ASSI vuole rendere accessibile il patrimonio informativo sui sistemi web, alla totalità delle utenze, fornendo dati puntuali e di sintesi comprensibili anche ad utenti non specialisti nel campo dell'informatica.
5.1 Riferimento alle esigenze del Sistema Informativo
5.2 Definizione tecnologie di riferimento
Il World Wide Web (WWW), per il quale dovranno essere applicati i criteri di accessibilità, oltre a soddisfare le esigenze sopra enunciate, si propone anche come strumento adatto allo scopo di un accesso "amichevole" e semplice alle informazioni.
Difatti tale tecnologia permette:
Il WWW si configura come un sistema Client/Server (C/S), che vede da una parte l'utente utilizzare una applicazione che gli permette di navigare sulla rete (il browser), dall'altra i Web server che forniscono le pagine web che i browser richiedono di scaricare.
5.2.1 Progettazione e realizzazione User-Centered
Negli ultimi tempi anche a seguito di una maturità delle tecnologie Web e di una più generale aumentato livello di sensibilità dell'opinione pubblica sui temi legati ai disabili, si è iniziato a prestare una notevole attenzione al ruolo dell'utente dei sistemi informativi, quale componente del sistema uomo-macchina, coniando il termine user-centred con riguardo all'individuazione delle modalità di progettazione da seguire nella fase di costruzione di un qualsiasi sistema interattivo. Il limite dei sistemi informativi tradizionali, spesso paradossalmente, risiedeva nella loro incapacità di comunicazione con gli esseri umani (utenti) e non tanto nella potenza computazionale offerta. Gli elementi essenziali ai fini di un progetto user-centred, possono essere così sintetizzati:
Sebbene i predetti criteri stiano acquisendo una sempre maggiore rilevanza e popolarità, spesso non sono completamente seguiti nella progettazione dei sistemi. Nella realizzazione del sistema ASSI si porrà particolare enfasi alla fase di verifica di accessibilità , non solo nella fase finale del progetto ma facendo verifiche nel corso del progetto, specialmente di scelte significative per lo sviluppo delle modalità di interazione.
5.2.2 La scelta tecnologica
La scelta da effettuare è tra una soluzione Java con accesso ai dati tramite JDBC o eventualmente Java-Corba ed una soluzione ActiveX/ASP/COM+.
Pur rappresentando Java una scelta tecnologica di sicuro valore, la società scrivente opta per la soluzione Microsoft, anche grazie all'esperienza maturata ed alla ottima conoscenza dell'ambiente.
Inoltre gli ambienti Microsoft di sviluppo forniscono sicuramente tutti i presupposti necessari, sia sotto il punto di vista dell'usabilità, che dell'integrazione tra i diversi componenti.
La tecnologia offerta in questo ambiente, relativamente all'accesso a generici RDBMS, presenta una alta affidabilità e semplicità di utilizzo.
Un'ulteriore considerazione, che ha fatto ricadere la scelta sulla tecnologia ActiveX/ASP/COM+, è la presenza di una soluzione Microsoft nella quale vi è una perfetta integrazione tra le tecnologie nominate precedentemente e il DBMS SQL Server 2000.
Infine, tale tecnologia è la stessa utilizzata dalla scrivente, con ottimi risultati e soddisfazione del cliente, nel progetto SIAP.
Nei paragrafi seguenti sarà presentata l'architettura di riferimento e verranno presentate le diverse componenti tecnologiche di tale architettura.
5.2.3 Active Server Pages
Active Server Pages (ASP) è un ambiente di scripting server-side realizzato per creare ed eseguire applicazioni Web interattive. Active Server Page di IIS offre un ambiente aperto e avanzato nel quale si possono combinare HTML, VB script e componenti server ActiveX riusabili per creare dinamiche ed efficienti applicazioni Web-based.
ASP in IIS 5.0 per mettono agli sviluppatori di usare linguaggi quali VB Script e Jscript per passare informazioni ai componenti, e ritornare il risultato fornito dai componenti stessi.
L'utilizzo delle pagine ASP unitamente all'uso dei componenti ActiveX costituiscono una soluzione ideale per lo sviluppo di applicazioni Web-based.
Gli ASP file contengono sia client che server script.
Client script sono parte della pagina e sono mandati ed eseguiti nel browser quando un utente richiede la pagina. Anche i server script, sono parte di una pagina, ma non vengono mandati al browser. Al contrario questi vengono eseguiti dal IIS dopo che la pagina è stata richiesta ma prima che essa venga passata al browser. Quando la pagina è passata al browser il server ha già eseguito i server script e rimosso questi dalla pagina stessa.
La possibilità di specificare che uno script possa essere eseguito client-side o server-side è un importante feature, che consente di scegliere il giusto ambiente di esecuzione di determinate azioni. Tipicamente l'esecuzione di un a query su di un database è sarà server-side mentre al contrario la variazione dell'aspetto di un pagina in risposta ad un dato evento sarà client-side.
5.2.4 COM+
Nel 1999 Microsoft, con Windows 2000, ha introdotto COM+, un nuovo rivoluzionario passo in avanti di COM e MTS.
COM+ unifica i modelli di programmazione propri dei servizi COM e MTS. COM+ rende più semplice lo sviluppo di applicazioni distribuite eliminando la complicazione di sviluppare, correggere, distribuire e gestire un'applicazione che fa riferimento a COM per certi servizi ed a MTS per altri. Il beneficio per lo sviluppatore è quello di poter realizzare una applicazione distribuita in modo più veloce, più semplice e più economico, riducendo la quantità di codice richiesto per trarre vantaggio dai servizi di sistema sottostanti.
Le applicazioni basate sulla tecnologia COM possono utilizzare al meglio un insieme comune di infrastrutture e servizi di rete forniti nella piattaforma Windows. I servizi di sicurezza di Windows, ad esempio, forniscono controllo accesso ai servizi Web, come pure ai servizi transazionali e di message queueing. Altri servizi comuni includono il system management, i servizi di directory, i servizi di rete ed il supporto all'hardware.
La tecnologia COM permette agli sviluppatori di software di costruire applicazioni a partire da componenti che possono essere distribuite ad ogni livello del modello applicativo. Queste componenti forniscono supporto per l'assemblaggio, il partizionamento, e per le funzionalità tipiche delle applicazioni distribuite.
COM+ rende disponibile una parte ancora più consistente dell'infrastruttura necessaria per scrivere applicazioni nel sistema e, in tal modo, gli sviluppatori non devono occuparsi della scrittura dell'infrastruttura stessa. La situazione ideale è quella in cui gli sviluppatori concentrano il proprio impegno più sul perfezionamento del componente che sulla costruzione delle basi per il componente stesso. Fortunatamente, la maggior parte del codice che implementa queste funzionalità fondamentali è molto simile per tutti i componenti. COM+ rende molto più semplice il lavoro di programmazione, in quanto offre un'implementazione predefinita di queste funzionalità per gli scenari più comuni. Se comunque l'implementazione non soddisfa le esigenze degli sviluppatori, questi hanno la possibilità di personalizzare le caratteristiche di base.
Sebbene strumenti come Microsoft Visual Basic si occupano di gestire automaticamente queste problematiche, le estensioni COM+ fornite dal sistema offriranno un'implementazione standard, indipendentemente dal linguaggio di programmazione scelto. COM+ definisce inoltre un modello più semplice e, allo stesso tempo, più affidabile per la registrazione e l'installazione dei componenti e l'assegnazione delle versioni ad essi. In tal modo, la tecnologia COM può essere utilizzata e gestita con maggiore facilità.
COM+ porta con sè diverse novità per quanto riguarda la scrittura di applicazioni distribuite basate sui componenti. Introduce ad esempio un nuovo meccanismo di estendibilità denominato "intercettazione", un nuovo concetto chiave nell'architettura COM. Gli intercettatori (Interecptors) consentono ai componenti di reindirizzare le loro funzionalità per richiamare diversi servizi in fase di esecuzione, ed evitano quindi che i componenti rimangano legati a un singolo servizio. Gli intercettatori possono ricevere ed elaborare eventi correlati alla creazione di istanze, alle chiamate e alle restituzioni di risultati, agli errori e all'eliminazione delle istanze. Rendono inoltre disponibile, ad esempio, il meccanismo per implementare le transazioni e il monitoraggio del sistema. COM+ stesso utilizza gli intercettatori per implementare l'accesso ai dati e altri servizi distribuiti. La caratteristica più importante della funzionalità di intercettazione è rappresentata dalla modalità con cui si accede a questi servizi nei componenti, ovvero impostando semplicemente alcuni attributi per le classi create dallo sviluppatore. Gli sviluppatori possono specificare questi attributi da un ambiente di sviluppo integrato (IDE) utilizzando editor delle proprietà o della sintassi del linguaggio. Gli intercettatori interpretano questi attributi e attivano automaticamente i servizi appropriati. Lo stesso principio generale viene applicato a tutti i servizi. Non deve essere appreso il funzionamento di nuove API e non esiste codice complesso che vada a oscurare la logica dell'applicazione: è sufficiente scegliere alcuni attributi. Gli intercettatori spianano pertanto la strada a un'intera nuova categoria di estensioni COM.
COM+ offre inoltre servizi innovativi e facili da utilizzare già presenti in strumenti che supportano COM, come Visual Basic. Un esempio di questi servizi è l'associazione di dati, che consente di associare campi di oggetti a determinati campi di database.
Allo scopo di estendere la diffusione di COM e dei servizi offerti, COM+ apporta dei miglioramenti ai servizi esistenti come pure in nuovi servizi per la piattaforma applicativa. Questi includono:
5.2.5 Active Data Object (ADO)
Active Data Object (ADO) fa parte di una strategia di sviluppo aziendale di più ampio respiro destinata alle applicazioni di reti aziendali e per Internet. La prima versione di ADO è stata resa disponibile nella prima versione di Microsoft Transaction Server ed è anche la tecnologia di accesso ai dati di Microsoft Internet Information Server. Sebbene ADO rappresenti un'evoluzione sia di DAO che di RDO risultante in un'unica interfaccia semplificata ed estensibile, Microsoft prevede che le prossime versioni di ADO supereranno tutte le funzionalità di DB-Library, DAO e RDO.
ADO si concentra fondamentalmente sulle implementazioni Internet, grazie alla possibilità di mantenere informazioni sullo stato in un ambiente senza connessioni. Questa caratteristica include un'implementazione con funzionalità complete di manipolazione dei dati e un'implementazione leggera e scaricabile, disponibile per i client Internet in fase di run-time.
A partire dalla versione 2.0 di ADO (rilasciata con Microsoft Visual Studio 6.0) vi sono sostanzialmente due miglioramenti strutturali:
La figura riporta l'insieme delle tecnologie introdotte da Microsoft per l'accesso ai dati e l'architettura Universal Data Access mette a disposizione uno strato unificato per l'interoperabilità tra le più disparate sorgenti dati localizzate su piattaforme diverse.
5.2.6 XML
L'XML, eXtensible Markup Language, è un metalinguaggio estensibile definito per poter descrivere in modo semplice i documenti strutturati; studiato per il mondo Web e per superare i limiti del HTML (HyperText Markup Language), offre la possibilità di essere utilizzato come formato di interscambio in ambienti eterogenei essendo basato su file di testo.
Sviluppato dal W3C, il World Wide Web Consortium il consorzio che definisce gli standard nel mondo Web, XML è un sottoinsieme di SGML (Standard Generalized Markup Language), uno standard internazionale che definisce le regole per scrivere markup language, che volutamente non comprende alcune funzionalità complesse di SGML difficilmente implementabili per il mondo Web.
La prima bozza di XML risale al novembre 1996, l'attuale specifica di XML è consultabile al seguente indirizzo: http://www.w3.org/TR/1998/REC-xml-19980210.
la traduzione in italiano di questo documento è consultabile al seguente indirizzo: http://www.xml.it/RECxml19980210it.html.
Un Markup è tutto ciò che ha un significato speciale, che deve essere ben caratterizzato ed identificato, esempi di markup sono: il testo scritto in grassetto oppure il testo sottolineato.
In XML tutto ciò che è compreso tra i caratteri < e > (angled brackets, parentesi angolari) è considerato markup e viene detto tag (etichetta), ad esempio:
<NomeTag> è un tag di nome NomeTag.
Il nome di un tag è casesensitive ovvero :
<NomeTag>, <nometag> e <NOMETAG>
rappresentano tre tag differenti.
XML è un metalinguaggio ovvero un linguaggio di descrizione di linguaggi per tale ragione, contrariamente ad HTML che è un linguaggio predefinito, non ha tag predefiniti.
In XML a differenza dell'HTML ogni tag deve essere opportunamente chiuso. La chiusura di un tag avviene definendo un nuovo tag con lo stesso nome del primo ma preceduto dal carattere / (slash). Tra il tag iniziale ed il tag di chiusura possono essere inseriti dei caratteri che rappresentano il valore del tag. Il valore di un tag è rappresentato da un insieme di caratteri ma non possono contenere i caratteri <, > e " che sono sostituiti dai caratteri speciali <, > e ". L'insieme del tag, del suo valore e della sua chiusura è detto elemento. Ad esempio:
<CodiceFiscale>FAGNTN58C12H501G</CodiceFiscale>
è un elemento costituito da un nome CodiceFiscale e un valore FAGNTN58C12H501G. In XML è possibile definire un elemento senza valore, in tal caso la sintassi è:
<NomeElemento></NomeElemento> oppure <NomeElemento/>
In XML gli elementi possono contenere altri elementi opportunamente nidificati, ma non è possibile creare nidificazioni incrociate. Ad esempio è corretta la sintassi:
<Libro>
<Paragrafo>
7.3
</Paragrafo>
</Libro>
Ma non la seguente sintassi:
<Libro>
<Paragrafo>
7.3
</Libro>
</Paragrafo>
I documenti XML possono essere ben formati e/o validi. Un documento XML è ben formato quando rispetta le regole di sintassi proprie del linguaggio XML (fare riferimento alle specifiche precedentemente indicate per le regole esaustive della sintassi dell'XML). Un documento XML valido è un documento ben formato che rispetta i vincoli definiti da un Document Type Definition (DTD). Un DTD è la grammatica per i documenti XML che vengono prodotti in base a quel DTD: il DTD definisce i TAG ammessi e il loro grado di nidificazione, definisce l'ordine dei TAG, indica i tipi di dati ammessi per i TAG foglie. Il formalismo di rappresentazione di un DTD non è XML, ma un linguaggio simile a metà strada tra l'XML e la notazione BackusNaur. Avendo definito il DTD ovvero la grammatica del nuovo linguaggio basato su XML, rendiamo il linguaggio utilizzabile per scambiarsi i dati tra due o più applicazioni: il DTD in questo contesto viene visto come descrittore del protocollo di interscambio tra le applicazioni.
5.2.7 XSL
L'XML focalizza la sua attenzione sul contenuto, ovvero sui dati, l'XML elabora semanticamente il documento fornendo la struttura ed il contesto dei dati che contiene. Non è indicato per visualizzare il contenuto, per questo aspetto è stato introdotto l'XSL.
L'XSL (eXtensible Style-sheet Language) è la specifica del World Wide Web Consortium (W3C) per separare l'aspetto grafico (lo stile) dai contenuti. La specifica lavora sul concetto dei template permettendo ai grafici di definire un singolo documento di stile a più pagini. La specifica, il primo draft è dell'Agosto 1998, introduce due grandi innovazioni :
La specifica dell'XSL introduce l'XSLT (eXtensible Style-sheet Language Trasformations) come linguaggio usato per trasformare documenti XML in altri documenti XML e come caso particolare per trasformare documenti XML in documenti XHTML (versione compatibile con le specifiche XML dell'HTML). Un processore XSL (detto anche parser) elabora il documento XML seguendo le istruzioni dello style sheet XSL e fornisce in output un nuovo documento XML oppure un frammento del documento XML.
XSLT permette di trasformare una porzione di documento XML (sottoalbero XML) in un altro documento XML distinto dal primo: che può essere completamente diverso dal primo ma che contiene gli stessi dati o solo una parte oppure altri dati ottenuti in maniera calcolata da quelli contenuti nel primo documento XML. La trasformazione è espressa mediante un insieme di regole (template) per ad esempio eliminare alcuni nodi, aggiungerne altri, calcolare il valore dei nodi, riordinarli etc. Poiché il documento XML ottenuto dopo la trasformazione può essere strutturato secondo un insieme arbitrario di tag, anche diversi da quelli del documento originario se "sostituiamo" i tag del documento origine con tag propri del HTML otteniamo una pagina HTML contentente i dati del documento sorgente. Si deve comunque dire che poiché la trasformazione XSLT ha come risultato un documento XML la pagina HTML ottenuta dovrà essere a sua volta un documento XML, ovvero una pagina XHTML. Le specifiche dell'HTML infatti non sono molto restrittive in termini di apertura e chiusura dei tag, di annidamento dei tag e di adozione del case-sensitive nel nome di un tag. Il W3C sta promuovendo delle specifiche volte a far divenire lo stesso HTML un linguaggio derivato dall'XML, XHTML, per ottenere un maggior rigore formale che permetta maggiori controlli formali.
Lo stesso XSL può essere usato per formattare dei set di dati diversi, contenuti in file XML separati, ma è anche possibile avere più rappresentazioni (ad esempio in forma tabellare oppure in forma di lista) di uno stesso documento XML usando di volta in volta file XSL diversi.
In figura, prelevata direttamente dal sito della Microsoft, è rappresentato un esempio di trasformazione di un documento XML mediante un template XSL.
L'utilizzo dell'accoppiata XML/XSL permette di garantire in maniera semplice ed elegante oltrechè estremamente flessibile la separazione tra i dati e la loro rappresentazione ed è il meccanismo allo stato dell'arte più utilizzato per realizzare siti multicanale ovvero siti che possono essere raggiunti secondo canali differenziati quali ad esempio il Web, il Wap, GPRS ed in futuro UMTS.
Nell'architettura proposta si prevede l'utilizzo esteso dell'accoppiata XML/XSL per visualizzare il contenuto delle informazioni presenti nella base dati. In particolare si prevede di immettere tutti i contenuti "variabili" del sito mediante documenti in formato XML.
5.3 Architettura di riferimento
Il modello cui si fa riferimento nel caso del progetto ASSI, così come quella utilizzata nella realizzazione del progetto SIAP, è un'architettura client/server basata su internet a più strati interagenti tra di loro. La distribuzione degli strati di cui è composta una applicazione non è rigidamente limitata a tre e si parla più propriamente di architetture multi-tier o n-tier".
5.3.1 Presentazione dei vari strati e loro funzioni (livello logico)
I benefici delle architetture multi-tier rispetto a quelle a due livelli sono:
Gli strati individuati sono lo strato di presentazione utente, uno strato intermedio che gestisce le interazioni tra il client e il database, un ultimo, infine, che controlla i dati.
Descrizione dello schema
Il Presentation Layer può istanziare direttamente i servizi e le entità degli altri livelli, il Business interagisce con il Data Layer secondo le necessità derivanti dalle richieste fatte dai componenti del Presentation.
5.3.2 Presentation Layer
Il primo livello, detto Presentation Layer, ha il compito di gestire soltanto la parte di colloquio con l'utente, cioè la visualizzazione grafica, l'input da tastiera e da mouse. Questa parte del sistema utilizza il supporto fornito da un Web Browser, quale Internet Explorer oppure Netscape. Questo livello colloquia con i moduli server appartenenti al secondo livello tramite il protocollo di comunicazione standard, HTTP, proprio delle applicazioni Web.
5.3.3 Logic o Business Layer
Il secondo livello, detto Logic o Business Layer, ha il compito di gestire la logica applicativa, le cosiddette "regole di business". E' a tutti gli effetti il cuore dell'architettura a tre livelli. Il livello di presentazione usa le regole di business implementate dal secondo livello, tuttavia queste non sono legate a nessuno specifico utente ma sono uguali per tutti, nei limiti garantiti dal livello di interoperatibilità previsti per l'utente in questione. Ogni regola di business è implementata in un unico componente così che possa essere facilmente modificata se, ad esempio, l'applicazione debba essere adattata alle nuove esigenze dell'AIPA. La comunicazione tra i due avviene tramite apposite interfacce, tramite il protocollo standard COM+ che rappresenta l'evoluzione di COM/DCOM.
5.3.4 Data Layer
Il terzo livello, detto Data Layer, incapsula le funzionalità di accesso alle sorgenti di dati, in genere le basi dati. Tali moduli "incapsulano" la regole di accesso ai dati trattati, in modo tale che se tali dati vengono spostati, oppure se viene modificato il formato debbano essere modificate soltanto le componenti del terzo livello. Ogni modulo per l'accesso ai dati è anche responsabile per l'integrità di un insieme di dati da esso gestiti, ad esempio una tabella in un database relazionale.
5.4 L'Architettura di ASSI
Nel presente paragrafo si propone l'architettura applicativa del sistema ASSI. L'architettura proposta è come detto precedentemente una architettura n-tier e presenta caratteristiche di modularità e scalabilità essendo essa basata su principi derivati dalla DOC (Distributed Object Computing).
Coerentemente con quanto detto precedentemente possiamo individuare nell'architettura tre strati logici: lo strato di presentazione, quello di business e quello dei dati. A loro volta questi strati sono composti da più strati fisici software.
Di seguito vengono presentati i diversi componenti che costituiscono l'architettura applicativa:
Una delle specifiche che hanno determinato una simile scelta architetturale, è stata la necessità di voler rendere il sistema ASSI accessibile da qualsiasi postazione client dotato di browser standard. Si è infatti scelta una soluzione di tipo thin-client, posizionando tutta la logica di business e di accesso ai dati sul lato server in maniera di poter sfruttare al massimo le potenzialità di accesso ai dati e di distribuzione dei componenti, offerte dall'architettura Microsoft, senza così imporre scelte proprietarie dal lato client.
5.5 Quadro normativo di riferimento
Le normative di riferimento relative ai temi dell'accessibilità seguono due filoni principali: da una parte la normativa americana, e dall'altra quella della Commissione Europea. La prima segue, riadattandole ai nuovi, le norme già presenti nella legislatura degli Stati Uniti è meno restrittiva, mentre la seconda si conforma ai dettami espressi dalle linee guide individuate dal W3C.
5.5.1 Normativa americana ed europea
Riassumiamo le principali normative di riferimento americane ed europee:
Americans with Disabilities Act (ADA)
L'Americans with Disabilities Act (ADA) del 1990 proibisce la discriminazione sulla base delle disabilità nell'impiego, nei programmi e nei servizi forniti dallo stato e dalle autorità locali, così come nei beni e nei servizi forniti dalle compagnie private. Esso si applica a tutto il mondo economico. L'ADA richiede che tutti i servizi pubblici siano accessibili. In aggiunta, ad ogni società con 15 o più dipendenti viene richiesto di rendere i propri servizi e le tecnologie informatiche accessibili agli impiegati che abbiano una qualche forma di handicap.
Section 255 of the Telecomunication Act
La Section 255 of the Telecomunication Act del 1996 richiede che i costruttori di strumentazione nell'ambito delle telecomunicazioni così come del software garantiscano che tali strumenti siano direttamente accessibili dalle persone disabili se tale accesso è rapidamente raggiungibile. Se l'accessibilità diretta non è rapidamente raggiungibile, i costruttori devono rendere lo strumento con le periferiche utilizzate dalle persone disabili. La Section 255 mediante lo U.S. Access Board ha dettato le linee guida che forniscano un criterio per l'accessibilità e la compatibilità.
Section 508 of the Rehabilitation Act
E' la più recente legge americana sui temi dell'accessibilità. Nel 1998, il presidente Clinton ha firmato convertendo in legge il "Workforce Investment Act", attraverso cui il Section 508 of the Rehabilitation Act del 1986 è stato significativamente espanso e potenziato ai requisiti dell'accesso alle nuove tecnologie rispetto all'atto del 1986. Tra gli effetti della nuova legge richiede che l'approvvigionamento federale nei campi della tecnologia elettronica ed informatica a partire dall'agosto 2000 dovessero consentire l'accesso agli impiegati federali e al pubblico appartenenti alle categorie dei disabili. Agli stati che ricevevano i fondi federali previsti dal Assistive Technology Act del 1998, veniva richiesto di aderire alle linee guida della Section 508. La Section 508 definisce delle linee guida anche in ambito Web.
eEurope
Nell'ambito dell'iniziativa europea eEurope varata dalla Commissione Europea l'8 dicembre 1999 con l'adozione della Comunicazione: "eEurope - An information Society for all", che ha come obiettivo di accelerare la diffusione delle tecnologie digitali in Europa e ad assicurare che tutti i cittadini europei siano messi in grado di utilizzarle. Il punto 7 in particolare è denominato "ePartecipazione per i disabili". In esso si sottolinea come gli sviluppi delle tecnologie digitali offrano ai disabili ampie opportunità di superare le barriere socioeconomiche, geografiche, culturali e temporali. Già da quel documento si pone come obiettivo entro la fine del 2001:
"La commissione e gli stati membri dovranno impegnarsi a rendere accessibili ai disabili la struttura e il contenuto di tutti i siti web pubblici".
Piano di Azione 2000
Nel successivo Piano d'Azione preparato dal Consiglio e dalla Commissione Europea per il Consiglio Europeo di Feira tenutosi il 1920 giugno 2000, nell'ambito dell'obiettivo 2 - Investire nelle risorse umane e nella formazione, al punto c) partecipazione di tutti all'economia basata sulla conoscenza, si enuncia tra l'altro che:
"vista la crescente tendenza a rendere accessibili on-line i servizi delle amministrazioni centrali e le informazioni di carattere pubblico il fatto di consentire a tutti i cittadini di accedere ai siti web delle Pubbliche Amministrazioni è altrettanto importante quanto garantire l'accesso agli edifici pubblici. Per quanto riguarda le persone con esigenze speciali la sfida consiste nel garantire il massimo livello di accessibilità alle tecnologie dell'informazione in generale e la compatibilità di queste con le tecnologie assistive e ponendo come azione l'applicazione degli orientamenti dell'iniziativa WAI del W3C ai siti pubblici".
5.5.2 Normativa italiana
In ambito italiano si recepiscono le indicazioni europee, che si rende conforme alle line guide del progetto WAI del W3C, rispettivamente:
5.6 Metodi di valutazione accessibilità
In questo paragrafo sono riassunti i principali metodi di valutazione per l'accessibilità dei siti web.
Metodo di valutazione analitico
Questo metodo permette di effettuare previsioni su alcuni aspetti parziali dell'accessibilità ad un sito, in un tempo anteriore alla realizzazione del primo prototipo del sito stesso. È un metodo basato sul costruire un modello formale del sistema, che permette di predire, per esempio, il tempo necessario ad un utente esperto ad effettuare un certo compito senza errori. Purtroppo, l'utilizzo di questo metodo, oltre a richiedere l'intervento di un esperto che costruisca il modello formale, porta a risultati marginali e non tiene conto del contesto d'uso del sistema.
Metodo di valutazione tramite esperto
Questo metodo, invece, sfrutta la conoscenza di un esperto nel campo della interazione uomo-macchina per effettuare previsioni sull'accessibilità ad un sito, a partire da un prototipo che può essere anche cartaceo (cioè che simuli sulla carta possibili schermate del sistema). Il maggior difetto di questo metodo, che pure offre il vantaggio di una analisi approfondita dei fattori che determinano l'accessibilità al sito, è quello di dipendere dal giudizio di un singolo esperto, che non è comunque l'utente finale.
Metodo di valutazione basato sull'osservazione
Il terzo metodo, coinvolge utenti reali che vengono osservati durante l'interazione con il sito web. Per questo motivo può essere utilizzato solo quando un reale prototipo del sito è stato prodotto. Inoltre, è preferibile non osservare direttamente le persone che interagiscono con il sito (questo può indurre un comportamento diverso dall'usuale), ma filmarle ed analizzare il film. Questo permette di evidenziare i punti critici dell'interazione. L'aspetto più costoso di questo metodo è costituito dal tempo necessario ad analizzare i filmati sugli utenti.
Metodo di valutazione basato su indagine
Altro metodo questo, basato sull'analisi delle opinioni, aspettative, reazioni, ecc. degli utenti, che vengono largamente consultati tramite questionari ed interviste. I questionari relativi a tali interviste possono essere usati in diverse fasi dello sviluppo del progetto, sia inizialmente, seguendo i criteri descritti nella sezione precedente per definire le prime linee della progettazione del sito, sia nelle varie fasi di sviluppo del prodotto per poter testare le reazioni degli utenti. È chiaro che in questo tipo di metodo è essenziale progettare correttamente i questionari e le domande da porre agli utenti nel corso delle interviste. Una volta effettuato ciò, è possibile formulare una valutazione affidabile dell'accessibilità del sito. In particolare, per le fasi finali della valutazione (cioè sull'ultimo prototipo o sul sito web www.pubbliaccesso.it vero e proprio) esistono degli strumenti software che forniscono un ausilio nella progettazione dei questionari e nella valutazione della soddisfazione dell'utente in base alle risposte alle varie domande.
Metodo di valutazione basato su prodotti specifici
Quest'ultimo metodo si avvale di prodotti presenti sul mercato per la validazione automatica in relazione ai criteri di accessibilità sui siti web. Questi strumenti hanno l'obiettivo di essere d'aiuto per l'identificazione e la riparazione di significative barriere all'accesso per individui con invalidità. Sono implementati basandosi sulle linee guida per l'accessibilità del contenuto web del World Wide Web Consortium.
Generalmente, l'analisi di questa tipologia di strumenti, è strutturata sulle raccomandazioni W3C e quindi, come queste, basa la sua analisi su tre livelli di priorità che potremmo definire: da soddisfare assolutamente, preferibilmente da soddisfare, a cui fare attenzione.
Per ogni priorità, lo strumento riporta gli errori individuati e i controlli da eseguire manualmente. Riporta, infine, gli errori di compatibilità del browser e i tempi di download. Dà l'approvazione solo alle pagine o ai siti web che non riportino nessun errore individuato del primo livello di priorità.
5.7 Una metodologia per il progetto ASSI
Per validare l'accessibilità del sistema ASSI si terrà conto della soddisfazione degli utenti finali e del fatto che il sistema implementi tutte le funzionalità previste, coerentemente con l'applicazione delle raccomandazioni del W3C, dettate sulla tematica fin dal maggio 1999.
Ciò si riflette, innanzitutto, nella predisposizione di un gruppo di valutatori "misto" e cioè composto da rappresentanti di utenti finali e progettisti.
È importante notare che durante la validazione del sistema vengono prodotti, per diversi scopi, vari tipi di prototipi, tra cui possono essere individuati:
Visto il breve periodo a disposizione, dal momento di inizio attività a quello di rilascio, viene considerato congruo dal punto di vista tecnico, provvedere allo sviluppo di un solo prototipo per validare i requisiti utente.
Per ciò che riguarda, invece, la soddisfazione dei requisiti espressi dalle raccomandazioni W3C, verrà instaurata la massima aderenza ai suddetti princìpi.
Cogliamo ancora l'occasione, però, per affermare che non sarà sufficiente attenersi alle modalità tecniche ed alle linee guida auspicate dal consorzio o dall'Autorità nella rappresentazione delle informazioni: occorre progettare la struttura e la concatenazione delle informazioni raccolte in un sito secondo un'ingegneria idonea che dia prevalenza alla usabilità, alla navigabilità e all'accessibilità per i fruitori, nel rispetto delle loro prerogative fisiche e intellettuali e delle loro peculiari esigenze.
Un sito accessibile, usabile e navigabile per una persona con disabilità, come già detto, sarà certamente un sito molto più fruibile da parte di tutti i suoi visitatori e utenti.
In relazione a questa necessità, sulla stessa traccia di ciò che è stato già definito proprio dall'Unione Italiana Ciechi, la scrivente ritiene opportuno darsi uno strumento di valutazione e metodologico, capace di dare una certa omogeneità ai requisiti da osservare e ai giudizi da esprimere, allo scopo di raccogliere dati facilmente utilizzabili per l'adattamento in corsa del sito web esaminato.
Verrà quindi utilizzata una scheda di osservazione da compilare durante l'analisi dei singoli siti web, mediante la quale evidenziare e valutare i componenti e gli strumenti critici presenti nelle pagine esaminate, quali la descrizione alternativa delle immagini, la combinazione dei font e dei colori, la funzionalità della tastiera nelle fasi della navigazione, la dislocazione e l'identificazione degli oggetti e dei contenuti, e così via.
Verrà utilizzata la stessa scheda di osservazione definita dall'UIC, mediata però dalla capacità di strutturare e attuare una procedura di osservazione e di valutazione obbediente a criteri di professionalità e coerenza, a differenza di ciò che è stato riscontrato dall'UIC stesso, vista la natura totalmente volontaria dell'iniziativa e la scarsità di competenze specifiche utilizzabili. In questo modo potrà essere riutilizzato il lavoro già effettuato dall'unione, introducendo un elemento di spinta e di perfezionamento, verso la sua utilizzazione ed applicabilità.
5.7.1 La scheda di valutazione di accessibilità
5.7.1.1 Sezione 1 - informazioni preliminari
5.7.1.2 Sezione 2 - informazioni sul sito
5.7.1.3 Sezione 3 - analisi degli elementi