Università degli studi di Ferrara. Indice

Transcript

1 Indice 1. Introduzione Il progetto dell applicazione Fatture On-Line La vecchia applicazione del Comune per la gestione delle fatture Specifiche e requisiti del progetto Architettura Generale del sistema Sistema di autenticazione Livelli di autorizzazione Architettura Base di dati Architettura filesystem Interfaccia Web Struttura pagine Web Accessibilità Tecnologie utilizzate SQL e Microsoft SQL Server Server Web Apache HTML e CSS PHP JavaScript Realizzazione della nuova applicazione Architettura della rete del Comune Tabelle database Sistema di autenticazione Interfaccia web Struttura script Ricerca e visualizzazione Accessibilità e stampa Amministrazione utenti e fornitori Statistiche Altre Funzionalità Test del servizio

2 6. Conclusioni Riferimenti Indice delle figure

3 1. Introduzione Le Pubbliche Amministrazioni (PA), sono responsabili della gestione dei dati dei cittadini e offrono servizi per la loro consultazione. I cittadini ne possono usufruire di persona tramite gli sportelli comunali, o a distanza utilizzando i servizi telefonici o accedendo al Web. Negli ultimi anni le P.A. hanno colto l importanza dei moderni mezzi di comunicazione intraprendendo sempre più progetti riguardanti il mondo di Internet, data la sua utilità come strumento di comunicazione che permette di raggiungere in modo più efficiente i cittadini. Affinché i servizi Web siano facilmente utilizzabili dai cittadini, si devono tenere in considerazione le caratteristiche di usabilità e accessibilità per permettere al maggior numero di utenti di poter usufruire dei servizi. Inoltre si devono tenere in considerazione le persone disabili che necessitano, per non essere penalizzate nell utilizzo, di interfacce adeguate così da riuscire a servirsi a pieno dei sevizi messi a loro disposizione. Il problema dell accessibilità è stato valutato a livello nazionale, ed è stata introdotta nel 2004 la legge Stanca, la quale pone i requisiti che i servizi web delle P.A. devono offrire per poter essere considerati sufficientemente accessibili. Essa specifica inoltre le caratteristiche che devono presentare i servizi, in base alle tecnologie impiegate, alla tipologia, allo scopo e agli strumenti utilizzati per accedervi, inoltre definisce le linee guida per la presentazione dei contenuti come testo, colori, suoni, video e animazioni. Il Comune di Cento è uno dei comuni più informatizzati d Italia, offre un portale per i cittadini, con comunicazioni, eventi e molto altro ed è presente nel Web ormai da molto tempo, prima ancora dell introduzione della legge Stanca. Questo ha determinato, negli ultimi anni, lavori di ristrutturazione del portale del comune e dei suoi servizi in modo da rendere i contenuti più funzionali e accessibili. Questa tesi descrive la progettazione e realizzazione del rinnovo e ampliamento del servizio Fatture On-Line precedentemente offerto dal comune, risultato ormai inadeguato avendo limiti di funzionalità, come la creazione della base di dati utilizzata e alcune funzionalità scarse o mancanti, ma soprattutto di 3

4 accessibilità. Il risultato è una nuova versione, più completa, più funzionale e provvista di una interfaccia rispettante i requisiti di usabilità e le normative di accessibilità. Il servizio Fatture On-line ha come scopo principale quello di offrire ai fornitori e ai dipendenti del Comune la possibilità di consultare le fatture. L accesso è suddiviso in due sezioni: una per i fornitori che permette la consultazione, la ricerca delle proprie fatture e la visualizzazione dei dettagli; e una per i dipendenti del comune, che permette la consultazione, la ricerca di tutte le fatture e la visualizzazione delle informazioni sui fornitori. E presente un ulteriore sezione di amministrazione a cui possono accedere solo un gruppo ristretto di utenti, nella quale è possibile gestire gli utenti interni e l accesso per i fornitori. Il progetto, che ha preceduto la realizzazione dell applicazione, è partito con l ampliamento della struttura del database già utilizzato: oltre ai dati delle fatture e dei fornitori sono stati considerati anche quelli degli utenti, in questo modo è possibile consentire, limitare o negare l accesso, identificando gruppi di utenti e i relativi privilegi. Sono stati individuati due gruppi principali: Utenti di Dominio, suddivisi in tre livelli, con privilegi crescenti per separare l amministrazione dalla sola consultazione, e Utenti Fornitori con accesso limitato alla consultazione delle fatture di un singolo fornitore. Un ulteriore passo del progetto è stato quello della sicurezza, progettando il filesystem in maniera tale da separare la parte accessibile ai fornitori da quella dedicata ai dipendenti del comune, e la realizzazione di un sistema di accesso sicuro. Nel corso del progetto si è prestata particolare attenzione all accessibilità e usabilità dell applicazione (uno dei motivi principali di questo progetto) progettando un interfaccia semplice ma nello stesso tempo funzionale e, per quanto possibile, esente da limitazioni per utenti disabili, ad esempio utilizzando colori con contrasti adeguati, access key per la facile fruizione del servizio con l ausilio della sola tastiera. Infine è stata progettata un architettura di base degli script per la facile realizzazione e manutenzione dell applicazione. A questo punto si è passati alla fase di realizzazione, mettendo in pratica le idee, gli schemi e le procedure ideate in fase di progettazione. Sono state 4

5 create le tabelle necessarie, è stato sviluppato il sistema di autenticazione e sono state implementate nuove funzionalità di ricerca, amministrazione e statistica. Questa tesi è il frutto di un tirocinio svolto presso il Servizio Sistemi Informativi (SSI) del Comune di Cento che si occupa della gestione e amministrazione hardware e software della rete civica, l amministrazione della intranet comunale, del portale del Comune, la gestione e realizzazione di servizi on-line e siti Web strettamente collegati al Comune. 5

6 2. Il progetto dell applicazione Fatture On-Line Il progetto prevede lo sviluppo di un sistema per la consultazione dei fornitori e delle fatture via web, chiamato Fatture On-Line, comprendente un interfaccia web a uso degli utenti interni e dei fornitori dell ente per il monitoraggio delle fatture di fornitura, dalla loro registrazione al pagamento. Viene creata un ulteriore interfaccia di amministrazione per la gestione degli utenti. Tutte le interfacce vengono create nel rispetto delle norme di accessibilità ed usabilità previste per la P.A.. L applicazione è suddivisa in due sezioni, una per l accesso degli utenti esterni (fornitori), e una per l accesso degli utenti di dominio (dipendenti del comune). La prima modalità di accesso permette ai fornitori del comune di Cento di poter cercare e visualizzare le proprie fatture, mostrandone i dettagli e lo stato in cui si trovano. La seconda modalità permette ai dipendenti del comune di poter cercare e visualizzare tutte le fatture e relativi dettagli con la possibilità di gestire l accesso dei fornitori al servizio La vecchia applicazione del Comune per la gestione delle fatture Il Comune di Cento, sensibile al discorso Web, ha creato un portale per offrire ai cittadini, con un nuovo approccio, i propri servizi. Tra questi servizi è presente un applicativo Web per la gestione delle fatture on-line in cui sono molto evidenti le limitazioni di utilizzo e di gestione del servizio, che non erano state previste o risolte nella progettazione precedente: - l applicazione permetteva di visualizzare le fatture dell anno in corso e dei due anni precedenti, il numero degli anni in cui considerare le fatture era impostato a mano con cadenza annuale, in una fase di batch che genera la base di dati finale; - non esisteva un accesso specifico per gli utenti interni alla sede del comune e mancava una sezione di amministrazione adeguata; - non c era una gestione dei fornitori ( ad esempio non si poteva cambiare la password di un fornitore ); 6

7 - la procedura di conversione e preparazione della base di dati utilizzata dal servizio web ( fase di batch ) era molto lunga: o estrapolazione dei dati dal database del gestionale su macchina unix in un file di testo; o una macchina Windows si prendeva carico di importare il file di testo e caricarlo in un database Access; o ulteriore normalizzazione e associazione dei dati come fatture e dettagli; o conversione database Access in un database PostgreSQL. - interfaccia web non rispettante le normative sull accessibilità e usabilità per la P.A; - interfaccia web non rispettante le caratteristiche di usabilità. Dalle immagini di figura 1,2 e 3, si può notare come l applicazione presenta colorazioni non idonee, e non dispone di un interfaccia abbastanza intuitiva. Questi particolari sono stati dei motivi più che sufficienti per decidere di riorganizzare e aggiornare il servizio, da questo nasce anche l esigenza di creare una nuova interfaccia più efficiente e funzionale. Figura 1: Pagina principale di accesso al servizio 7

8 Figura 2: Pagina di ricerca Figura 3: Risultati ricerca 8

9 2.2. Specifiche e requisiti del progetto Le specifiche del progetto sono diverse per gli utenti di dominio e per i fornitori: La parte di accesso per gli utenti di dominio prevede: - 4 livelli di autenticazione ( Dominio, Utente, Amministratore e Super Amministratore ); - visualizzazione di tutte le fatture; - ricerca per fattura; - ricerca per fornitore; - sezione di BackOffice per l amministrazione del servizio che comprende: o amministrazione accesso fornitori; o amministrazione permessi utenti di dominio; o statistiche accessi. La parte riguardante i fornitori prevede: - accesso solo previa abilitazione del servizio; - cambio Password al primo utilizzo; - cambio password allo scadere di 60 giorni dall ultimo accesso; - visualizzazione delle proprie fatture; - ricerca delle proprie fatture; - possibilità di invio modulo di richiesta informazioni su una specifica fattura. L intera applicazione rispetta le specifiche di accessibilità e usabilità, permettendo la consultazione del servizio anche a utenti disabili senza particolari disagi, utilizzando programmi specifici come lettori audio di testo per non vedenti, o altre tipologie di programmi, e periferiche di visualizzazione che supportano risoluzioni diverse. 9

10 2.3. Architettura Generale del sistema L applicazione prevede un architettura generale su cui basarsi, e da cui partire per la progettazione delle singole parti. Ogni singola parte offre un interfaccia per poter comunicare con le atre, in modo tale da ottenere un approccio modulare che consenta di sostituire o modificare un singolo elemento, senza dover eseguire correzioni in altri componenti. In figura 4 è rappresentato lo schema generale del servizio, in cui possiamo trovare i vari blocchi che compongono il sistema. L interfaccia Web, accessibile con l ausilio di un comune browser, rappresenta il tramite che consente all utente di dialogare con l applicazione; da qui è possibile scegliere se accedere alla sezione dedicata agli utenti di dominio tramite l autenticazione di dominio, oppure accedere alla sezione pubblica tramite il sistema di autenticazione e codifica. Solamente dalla sezione di dominio è possibile accedere alla sezione di amministrazione. Nella figura è presente un blocco chiamato APPLICAZIONE Fatture On-Line che rappresenta il cuore del servizio, questo contiene le implementazioni delle funzionalità e ne permette la fruizione grazie alla comunicazione con il server Web e con un database che contiene i dati per l utilizzo del servizio. Figura 4: Schema generale del servizio 10

11 2.4. Sistema di autenticazione Il sistema di autenticazione è una parte molto importante che permette di proteggere l accesso alla visualizzazione di informazioni riservate. E suddiviso in due sezioni: una sezione di accesso per gli utenti di dominio, e una per l accesso pubblico. L autenticazione della sezione riguardante gli utenti di dominio è demandata ad Active Directory [Microsoft Active Directory], che si occupa di proteggere le macchine all interno della rete del comune e la protezione di aree riservate ai soli utenti di dominio. Riguardo all autenticazione della sezione di accesso pubblico, è stata adottata una doppia protezione: una basata su Apache e l altra basata su script PHP e database. La protezione di Apache permette l accesso al sistema di autenticazione vero e proprio, si è scelto di utilizzare un'unica coppia di nome utente e password, perché questa protezione ha come unico scopo quello di arginare i tentativi di forzatura del sistema da parte di persone che non hanno fatto richiesta di accesso al servizio. La protezione basata su PHP e database permette di autenticare l accesso dei fornitori al servizio. Sono stati presi in considerazione metodi diversi per la protezione delle informazioni inserite dagli utenti. Tra questi si predilige l utilizzo di SSL ( Secure Socket Layer ) [Protocollo SSL] che permette, tramite una codifica a chiavi pubblica e privata, di creare un canale di comunicazione sicuro tra client e server, rendendo le intercettazioni della trasmissione non comprensibili e difficilmente decodificabili. Purtroppo per problemi sui server del comune (durante il corso del tirocinio) non è stato ancora possibile attivare la protezione. Per arginare questo problema, sono stati presi in considerazione i metodi di autenticazione http come Basic e Digest. L autenticazione Basic codifica le informazioni in ingresso, come nome utente e password, in Base64 e le invia al server che provvederà a decodificarle e successivamente ad elaborarle. L autenticazione Digest è simile alla Basic a differenza del fatto che le informazioni non vengono inviate direttamente, ma a lato client ne viene creato un hash che successivamente verrà inviato al server per una comparazione con i dati presenti nel database. Questi due metodi però permettono una limitata 11

12 modifica della maschera di inserimento dati. Vista la necessità di un sistema che ha bisogno di una personalizzazione della maschera di inserimento e che non permetta la facile intercettazione e comprensione delle informazioni inviate, si è provveduto a creare un metodo personalizzato. E stato ideato un sistema che permette di salvaguardare le informazioni di accesso ed evitare nei limiti del possibile l intercettazione della comunicazione, e l utilizzo di queste informazioni al di fuori della sessione corrente. In ogni sessione viene generata una chiave alfanumerica che ha la caratteristica di essere univoca, e identifica la sessione corrente. Considerando che ogni volta la chiave di sessione cambia, si è pensato di utilizzarla in fase di accesso al servizio, dopo di che viene effettuato l hash delle informazioni concatenate con la chiave e inviate al server, che provvede a verificare l autenticazione con le informazioni reperite dal database. Il tutto è schematizzato in figura 5. Oltre a questo, per aumentare la sicurezza, è stato aggiunto un sistema di codifica per le informazioni sensibili non a conoscenza del server, come ad esempio avviene nel cambio di una password. Il sistema precedentemente descritto, non lo si può applicare a questa situazione, perché funziona solo se il server è già a conoscenza dell informazione che deve transitare. In questo caso, la nuova password scelta dall utente è sconosciuta al server e non la si può criptare vista l impossibilità di ricondursi ad essa, quindi, si è deciso di effettuare una codifica lato client delle informazioni sensibili, tramite l utilizzo di una chiave random. Il tutto poi viene inviato dal client, successivamente decodificato ed elaborato dal server. Il tutto è schematizzato in figura 6. Figura 5: Schema di cifratura 12 Figura 6: Schema di codifica

13 2.5. Livelli di autorizzazione Sono stati definiti 4 livelli di autorizzazione per la parte relativa all accesso di dominio, aventi le seguenti caratteristiche: - Dominio: o Utente precedentemente autentificato nel dominio, che all interno del servizio è considerato come un utente senza autorizzazione (per ora questo livello viene considerato come il livello Utente così che tutti i dipendenti del comune possono accedere al servizio, è stata prevista l inabilitazione dell autorizzazione Dominio nell eventualità che possano sorgere problematiche interne). - Utente: o Utente con permessi di visualizzazione delle fatture di tutti i fornitori, e con la possibilità di effettuare ricerche sia per fattura che per fornitore. - Amministratore: o Utente con accesso alla sezione di amministrazione e con i permessi di gestione fornitori, e gestione limitata dei permessi degli utenti di dominio. o Permessi per la gestione delle scansioni delle fatture. - Super Amministratore: o Utente con accesso completo a tutte le funzionalità del servizio. ( gestione fornitori, gestione completa permessi utenti di dominio, visualizzazione statistiche, modifica impostazioni generali, gestione scansioni fatture ). Per quanto riguarda l accesso da parte dei fornitori, è disponibile un unico livello di autorizzazione che permette la visualizzazione delle proprie fatture e dei dettagli a esse connesse. 13

14 2.6. Architettura Base di dati La procedura batch che permetteva di estrapolare i dati dal database del gestionale in un nuovo database, così da poter essere manipolati senza rischio, è stata rinnovata e ridotta a due fasi: - Estrapolazione dei dati dal database del gestionale su macchina unix in un file di testo - Conversione da file di testo a database SQL Server Le ottimizzazioni e le normalizzazioni vengono ora fatte all interno dell applicazione web. Il database è costituito da 3 tabelle principali dove risiedono i dati dei fornitori, delle fatture e dei dettagli delle fatture. Come possiamo notare dallo schema di figura 7, con cadenza giornaliera, i dati provenienti dal database del gestionale vengono salvati in un file di testo e, successivamente, utilizzati per popolare le tabelle che verranno utilizzate dal servizio. Oltre a queste sono state aggiunte, in questo progetto, altre 4 tabelle (vedere in figura 8) per la gestione del servizio che permettono: - la gestione delle scansioni associate alle fatture; - la gestione dei permessi di dominio e accesso fornitori; - la registrazione degli accessi; - il settaggio di impostazioni globali per la configurazione del servizio. 14 Figura 7: Schema procedura Batch

15 Le tabelle di gestione del servizio non sono collegate direttamente alle tabelle principali con delle chiavi importate, questo per evitare cancellazioni o modifiche, essendo le tre tabelle svuotate e ripopolate giornalmente. Figura 8: Nuove tabelle per il sistema 2.7. Architettura filesystem Il filesystem è un altro aspetto che è stato curato per fornire un livello maggiore di sicurezza. In prima analisi sono state create due cartelle separate visibili in figura 9, una per l accesso al servizio da parte degli utenti di dominio, e l altra per l accesso dei fornitori. E stato fatto questo per poter sfruttare il meccanismo di autenticazione di dominio, dando l accesso alla prima cartella solo a chi si è autentificato come utente di dominio, non potendo usare questo metodo per la seconda cartella, si è optato per una doppia autenticazione Apache / PHP-Database. La prima autenticazione è gestita dal server web Apache, con una unica autorizzazione che viene comunicata solo ai fornitori che richiedono il servizio, e serve principalmente per scongiurare eventuali tentativi di ingresso con credenziali scelte a caso. La seconda autorizzazione è gestita nella parte protetta dal dominio tramite una interfaccia web di amministrazione. In seconda analisi si è passati alla struttura delle cartelle che conterranno il servizio. Si è deciso di creare sia la cartella di dominio che quella per i fornitori con la stessa struttura mostrata in figura 10. Sono presenti 2 cartelle primarie, una con le classi base, che verranno utilizzate per contenere i dati prelevati da database, e una con le librerie o parti 15

16 che verranno incluse nelle pagine. Nelle inclusioni troviamo le funzioni di accesso al database, funzioni generiche, file di protezione, menu, ecc Solamente all interno della parte di dominio troviamo una cartella dedicata all amministrazione, che al suo interno ha la stessa struttura precedentemente descritta. Figura 9: Schema struttura del filesystem principale Figura 10: Schema struttura dettagliata del filesystem 16

17 2.8. Interfaccia Web L interfaccia web è un altro punto importante su cui soffermarsi, perché è il tramite che permette all utilizzatore di usufruire del servizio, quindi rendere l interfaccia intuitiva e di facile uso permette di ottimizzarne l impiego. E stata fatta una ricerca sulle specifiche relative all accessibilità, da applicare all interfaccia per poter rispettare le normative, riuscendo a offrire un servizio accessibile anche a utenti disabili. Inoltre si è cercato di mantenere, per quanto possibile, l interfaccia simile agli altri servizi, facilitando l utilizzo omogeneo del portale del comune (un esempio è visibile in figura 11 e figura 12). Figura 11: Esempio di interfaccia del portale del comune Figura 12: Esempio di interfaccia del servizio 17

18 2.9. Struttura pagine Web Creare una struttura di base per le pagine web è importante, perchè permette di facilitarne la creazione e la modifica. Tipicamente in una pagina se ne includono altre, che possono contenere librerie di funzioni, classi o variabili, oppure contenuti dinamici o statici. Questo permette di agevolare la modifica dell applicazione da parte di più persone, che possono agire su parti diverse contemporaneamente, mantenendo un interfaccia comune. Spesso si nota la presenza di molte parti di un applicazione che sono identiche o presentano caratteristiche molto simili, con le inclusioni si può semplificare questa situazione inserendo, in tutte le pagine che presentano caratteristiche simili, un file che racchiude porzioni di codice dinamico, che, ad ogni chiamata, genera dei contenuti che possono essere uguali, oppure offrire contenuti con sostanziali differenze. Volendo fare un esempio, possiamo prendere in considerazione un menù presente in tutte le pagine e, che in certe sezioni, le voci siano diverse oppure che vengano visualizzate in base alle autorizzazioni dell utente che richiede la pagina. Per fare questo basta creare una porzione di codice che genera un menù dinamico, il quale in base al tipo di richiesta mostri voci diverse o tenga conto delle autorizzazioni, e includere questo file in ogni pagina, dove queste ultime provvederanno a chiamare il menù passando i parametri adeguati. In questo progetto si è scelto l utilizzo dei template che permettono, una volta creatone uno, di generare nuove pagine con una struttura di base da cui partire. Se si modifica un template tutte le pagine create con esso possono essere aggiornate automaticamente. La figura 15 mostra com è stato creato il layout delle pagine del servizio, questo è costituito da quattro parti principali: - Header - Menu - Contenuto - Footer 18

19 La sezione Header rappresenta la parte superiore della pagina in cui sono contenuti: - Il Logo (vedi figura 13), presente in tutte le pagine: Figura 13: Logo comune di Cento - L intestazione dinamica (vedi figura 14): Nell intestazione troviamo il nome del servizio, in questo caso Fatture On Line, il nome dell utente collegato al servizio, il profilo dell utente (permessi) e la data dell ultimo accesso. Figura 14: Intestazione servizio, accesso di dominio Figura 15: Layout pagine servizio 19

20 La sezione Menù rappresenta il blocco in cui trovare i collegamenti alle varie funzioni del servizio ed eventualmente può ospitare altre informazioni come una legenda. La sezione Contenuto rappresenta il blocco in cui verranno visualizzati tutti i contenuti del servizio. La sezione Footer rappresenta la parte inferiore della pagina in cui sono contenute scritte descrittive e include la sezione Access Key (esempio in figura 16). Nella sezione Access Key troviamo una parte importante per l acessibilità, cioè la legenda delle Access Key presenti nella pagina. Figura 16: Footer con Access Key 20

21 3. Accessibilità L'accessibilità di un sito si ottiene tecnicamente rispettando le regole dettate dal progetto Web Accessibility Initative (WAI) [WAI]: una iniziativa del W3C [W3C], il consorzio mondiale che si occupa di standardizzare la progettazione dei siti web. Le linee guida contenute nel progetto WAI, consentono di realizzare un sito i cui contenuti e servizi siano fruibili da parte di tutti gli utenti, anche coloro che hanno necessità particolari ed accedono al web mediante dispositivi diversi dal monitor, tastiera o mouse. Rendere un sito accessibile significa, dunque, permettere a chiunque di accedere pienamente ai contenuti, alle informazioni ed ai servizi resi a disposizione dal sito, indipendentemente dal sistema operativo, dagli strumenti di navigazione, dalle impostazioni del browser, e a prescindere dalla velocità di connessione di cui si dispone. Significa inoltre perseguire un percorso di ricerca e di aggiornamento continuo, che parte dalla conoscenza dei problemi e delle reali necessità degli utenti, delle tecnologie per supportarli, dai test derivati dall'applicazione di queste tecnologie, dal monitoraggio dei risultati e dall'implementazione delle soluzioni più soddisfacenti per gli utenti. Il 17 dicembre 2003 il Parlamento approva all'unanimità la "Legge Stanca", che consente ai disabili l'accessibilità alle nuove tecnologie digitali e informatiche precisando che un "sito web accessibile", è un sito Internet il cui contenuto informativo multimediale e le procedure di interazione e navigazione siano fruibili da utenti dotati di browser con diverse configurazioni, che consentano di disabilitare le funzioni di caricamento di immagini, animazione, suono, colore, temporizzazione e omettere l'uso di visualizzatori addizionali. Si considera accessibile un sito che non ostacoli l'orientamento, la navigazione, la lettura di pagine e documenti, lo scaricamento di file e l'interazione con form o quant'altro richieda introduzione di dati e gestione di comandi, quando tali operazioni siano eseguite da una persona sufficientemente addestrata nell'uso di una postazione di lavoro. 21

22 Ai fini dell'accessibilità, i criteri fondamentali ai quali le amministrazioni sono invitate ad attenersi nello sviluppo di applicazioni informatiche sono i seguenti: - Accessibilità dalla tastiera: o tutte le funzioni dell'applicazione devono essere gestibili da tastiera. Tutte le azioni previste con l'uso di dispositivi di puntamento e manipolazione di oggetti devono essere rese possibili anche con equivalenti comandi di tastiera e devono essere chiaramente descritte nella documentazione dell'applicazione; o i comandi impartiti con combinazione di tasti di scelta rapida devono rispettare, per le operazioni più comuni, le scelte abituali del sistema operativo e devono essere ridefinibili dall'utente, per risolvere eventuali problemi di conflitto con quelli della tecnologia assistiva. Vanno inoltre preferite combinazioni semplici di tasti che risultino di facile memorizzazione e richiedano una modesta abilità manuale per l'esecuzione; o l'applicazione deve prevedere una successione logica delle operazioni di interazione. La successione deve essere chiaramente individuabile dalla tecnologia assistiva, per seguirne il percorso e consentire l'interpretazione alternativa delle operazioni; o l'applicazione non deve interferire con le funzioni di accessibilità eventualmente disponibili nel sistema operativo; o i comandi che prevedono una risposta a tempo devono essere evitati, - Icone: oppure deve essere prevista la possibilità, per l'utilizzatore, di regolare il tempo di risposta; o tutte le icone devono avere una chiara etichetta testuale o un'alternativa testuale selezionabile dall'utilizzatore; o ad ogni icona deve essere associata una combinazione di tasti di scelta rapida. Per le barre di icone deve essere disponibile anche un menù a tendina con comandi equivalenti; 22

23 - Oggetti: o l'applicazione deve usare le routine di sistema per la presentazione del testo, in modo da permetterne l'interpretazione alla tecnologia assistiva. L'informazione minima da fornire per tale interpretazione è costituita dal contenuto testuale dello schermo, dagli attributi del testo e dalla posizione del cursore; o l'applicazione deve rendere disponibili sufficienti informazioni sugli oggetti usati dall'interfaccia utente, affinché la tecnologia assistiva possa identificarli e interpretarne la funzione; - Multimedia: o l'applicazione deve prevedere opzioni alternative di segnalazione visiva di avvertimento e rinforzo delle segnalazioni sonore di allarme del programma; o l'applicazione deve prevedere opzioni di presentazione sincronizzata in formato testuale di tutte le informazioni audio, per mezzo di didascalie, sotto-titolazioni o altro, se questo non sia palesemente in contrasto con le funzioni del programma o oggettivamente impossibile da realizzare o non sufficiente per un utilizzatore non udente; o l'applicazione deve prevedere opzioni di descrizione vocale o presentazione sincronizzata in formato testuale di tutte le informazioni di tipo video se questo non è palesemente in contrasto con le funzioni del programma o oggettivamente impossibile da realizzare o non sufficiente per un utilizzatore non vedente (ad esempio programmi CAD o di montaggio fotografico); - Presentazione a video: o l'applicazione non deve usare il colore come mezzo per fornire informazione o indicare una azione selezionabile in un menu oppure deve prevedere un metodo alternativo utilizzabile anche da chi non percepisce i colori; 23