CIRCOLARE 6 settembre 2001, n. AIPA/CR/32 - versione estesa
Criteri e strumenti per migliorare l'accessibilità dei siti web e delle applicazioni informatiche a persone disabili
Versione estesa del documento
"Criteri e strumenti per migliorare l'accessibilità dei siti web e delle applicazioni informatiche a persone disabili" di cui alla circolare 6 settembre 2001, n. AIPA/CR/32
Indice
L'importanza dell'accesso dei disabili alle tecnologie dell'informazione e della comunicazione è stata espressa da tempo in numerosi documenti internazionali. Nel 1993, le Nazioni Unite adottarono le UN Standard Rules on the Equalization of Opportunities for Persons with Disabilities. La regola 5 cita, tra l'altro: "Gli stati dovranno sviluppare strategie per rendere i servizi d'informazione e la documentazione accessibile per differenti gruppi di persone con disabilità."
In tempi e luoghi a noi più vicini, 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,
(http:// europa.eu.int/comm/information_society/eeurope/index_en.htm) mirata ad 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 dei 10 presentati è 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 ".
Nel successivo Piano d'Azione preparato dal Consiglio e dalla Commissione Europea per il Consiglio Europeo di Feira tenutosi il 19-20 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 ai siti pubblici". (Vedi Allegato 1)
Da questi documenti si evince che l'accessibilità dell'informazione in formato elettronico nell'ambito della Pubblica Amministrazione risulta di importanza prioritaria nei programmi della Commissione Europea.
Da qui la necessità di elaborare anche a livello nazionale delle strategie operative per il raggiungimento di tali obiettivi, capaci di tradurre i principi in procedure concrete, alla luce della reale situazione nazionale esistente in fatto di disabilità e di tecnologia, capace di adeguarsi da una parte al rapido evolversi della tecnologia e dall'altro al panorama vasto e composito delle necessità dei disabili.
Allo scopo di precisare le specifiche di un sistema informatico e rendere tale sistema oggettivamente fruibile, è sempre opportuno analizzare le caratteristiche dell'utente potenziale, individuare le sue necessità, verificare a posteriori l'effettiva utilità delle proposte avanzate.
L'orientamento all'utente costituisce quindi il cardine delle specifiche progettuali di un sistema informatico, in quanto prescindere da questo invaliderebbe qualsiasi speculazione tecnologica e renderebbe inutilizzato l'oggetto prodotto.
Questo criterio è ancor più importante per gli utenti disabili, per i quali è dunque necessario definire in termini operativi il rapporto tra la loro specifica disabilità ed il possibile aiuto che può derivare da opportuni ausili.
A questo proposito è utile riportare le definizioni in materia date nel 1980 dall'Organizzazione Mondiale per la Sanità (Word Health Organization, WHO)
1. menomazione : perdita anomala di funzioni psicologiche, fisiologiche o anatomiche;
2. disabilità : qualsiasi restrizione o mancanza dell'abilità, derivante da una menomazione, di svolgere un'attività nel modo o entro i limiti ritenuti normali per un essere umano.
3. svantaggio (handicap): condizione di svantaggio vissuta da una determinata persona in conseguenza di una menomazione o di una disabilità, che limita o impedisce l'adempimento di un ruolo normale (in dipendenza dell'età, del sesso e dei fattori sociali e culturali) per quell'individuo.
Tipologie di disabilità
Il grado di disabilità può variare significativamente da soggetto a soggetto e può avere diverse connotazioni. Due sono le connotazioni principali:
1. disabilità strettamente ed unicamente fisica (includendo nel termine una disabilità sensoriale) che lascia integre le competenze mentali;
2. disabilità cognitiva, che può associarsi a minorazioni fisiche o sensoriali.
Una disabilità unicamente fisica consiste in un impedimento funzionale a svolgere prestazioni per le quali il soggetto ha una normale dotazione potenziale sotto il profilo intellettivo, ovvero della progettazione, della comprensione e dell'elaborazione.
Ben diversa è la situazione che si presenta quando la disabilità concerne la sfera cognitiva. In tal caso ad essere inficiata è la dimensione che deve presiedere la programmazione.
La realtà delle persone disabili ed anziane, lungi dal costituire una dimensione uniforme, si sfaccetta in una lunga serie di situazioni e di condizioni diverse. Le limitazioni funzionali che possono essere considerate sono numerosissime e la loro natura può essere la più disparata.
Nel seguito, verranno considerati solo gli aspetti delle limitazioni che, agli effetti dell'uso di strumenti informatici, producono disabilità che hanno attinenza con l'interazione con le macchine e la percezione e comprensione dell'informazione e delle segnalazioni.
a) Limitazioni motorie
Per quanto riguarda le limitazioni motorie, quelle che creano una disabilità al soggetto sono quelle relative al controllo dei movimenti degli arti superiori.
Per persone che hanno perso entrambe le braccia, il movimento e la pressione di oggetti, come ad esempio tastiera e mouse, è spesso impossibile e deve essere sostituito da altri metodi, per esempio mediante i movimenti di una bacchetta tenuta in bocca. Soggetti che hanno perso l'uso di un solo arto, trovano grande difficoltà con gli strumenti che richiedono l'uso di entrambe le mani, come ad esempio la pressione simultanea di due tasti, se troppo lontani fra loro.
Per persone che non possono muovere indipendentemente le dita, tutte le abilità motorie fini sono inficiate. Per loro è molto difficile utilizzare tastiere e la mancanza di forza e di coordinamento muscolare, come per i distrofici, compromette le possibilità di controllo e di manipolazione di oggetti e quindi anche del mouse o di un Joystick.
b) Limitazioni sensoriali
Queste riguardano limitazioni della vista e dell'udito.
b1) Minorazione dell'udito
I non udenti hanno difficoltà di risposta a stimoli uditivi, sia di emergenza (allarmi, ecc.) che di altro tipo.
L'età di inizio della minorazione è importante per lo sviluppo del linguaggio: una persona nata profondamente sorda o diventata sorda in età pre-linguistica, dipende prevalentemente dalla comunicazione visiva per acquisire parola e linguaggio e spesso usa la Lingua dei Segni.
E' utile distinguere tra non udenti che possiedono un linguaggio intelligibile e coloro che non ne hanno. Anche se il linguaggio parlato non è un pre-requisito per imparare a leggere, esso facilita enormemente l'acquisizione della lettura e della scrittura. E' dimostrato che il vocabolario si impoverisce a causa della ridotta frequentazione con la lingua parlata e questo finisce per rendere difficile la comprensione di testi scritti, soprattutto di contenuto astratto, difficoltà questa che si aggiunge a quella più ovvia di percezione delle componenti audio di un ambiente multimediale.
b2) Minorazione della vista
La minorazione della vista può essere totale (cecità) o parziale (ipovisione), con la diretta conseguenza dell'impossibilità o della difficoltà di percepire le forme presentate sul display di uno strumento informatico. Le soluzioni sono molto diverse tra loro a seconda del tipo di difetto visivo e vanno della presentazione alternativa in altra modalità, come per i ciechi assoluti, all'uso di accorgimenti di visualizzazione specifici.
b3) Minorazioni della parola
La minorazione della parola si riferisce a qualsiasi riduzione delle capacità di una persona di usare il parlato in modo funzionale ed intelligibile.
Il difetto della parola può essere dovuto a diversi fattori: può essere causato da problemi di sviluppo (disfasia), o da parlato distorto dovuto alla mancanza del controllo muscolare (disartria). Può essere acquisito, come per esempio la perdita dell'espressività linguistica (afasia espressiva) causata da trauma o tumore cerebrale, o per la rimozione della laringe (laringectomia).
Questo non è in genere di ostacolo all'uso degli strumenti informatici ma può costituire un problema in più quando si accompagna a limitazioni motorie generali che includono gli arti superiori, per le quali l'input vocale potrebbe essere una valida alternativa all'uso di tastiera e mouse.
c) Limitazioni cognitive
Le limitazioni funzionali a carico delle funzioni intellettive possono essere molteplici (disturbi della parola, del linguaggio, della coordinazione del pensiero, ecc.), tali da ridurre notevolmente i livelli di comunicazione, attenzione e risposta agli stimoli esterni.
Molte persone con problemi di comprensione sono capaci di comunicare meglio attraverso segni visivi piuttosto che parlati. Essi utilizzano segni manuali o speciali sistemi simbolici (per esempio il Bliss, il Rebus), ma il vocabolario può essere drasticamente limitato.
Per soggetti con disturbi cognitivi, non solo la comunicazione, ma anche l'addestramento all'uso di strumentazioni speciali può essere ostacolata.
d) Altre Limitazioni
Le categorie cui si è accennato coprono un ampio spettro delle minorazioni e disabilità. Esistono comunque difetti fisici che non possono essere compresi nelle categorie precedenti.
Alcune persone hanno difetti multipli con una conseguente disabilità che è superiore alla somma di quelle prodotte dalle singole menomazioni, ed inoltre l'impatto di ciascun difetto può variare a seconda della situazione. Per esempio una persona ammalata di sclerosi multipla può presentare oltre a problemi motori, anche problemi di vista, parola, ecc.
e) Disagi Legati all'Anzianità
Il fenomeno del progressivo invecchiamento della popolazione nei Paesi industrializzati a più alto tenore di vita impone nuovi problemi. Molti di loro infatti col passare degli anni si trovano ad affrontare in vario modo e a livelli differenti i deficit tra quelli elencati in precedenza.
Gli anziani, che attualmente sono circa il 20-30 % della popolazione complessiva Europea, secondo le stime, nel 2040 raggiungeranno il 40 %. In questo contesto, il superamento dei problemi che impediscono l'uso dell'elaboratore costituisce senza dubbio un passo fondamentale per garantire la loro presenza nel processo produttivo e nell'insieme delle relazioni sociali e pubbliche, ma anche un mezzo di intervento per sottrarli all'isolamento, fino a rappresentare una concreta possibilità di servizi mirati quando intervengano condizioni gravi di inabilità fisica o psichica.
Tecnologie assistive
Con questo nome si intende l'insieme di soluzioni tecniche hardware e software che forniscono configurazioni di terminale adattate alle necessità speciali e alle preferenze degli utenti, permettendo loro di superare o ridurre le condizioni di svantaggio dovute alla specifica disabilità. Tra queste tecnologie si possono citare, ad esempio, le periferiche di input alternativo per disabilità motorie, e di output alternativo per quelle visive. Per le disabilità cognitive l'elaboratore ha le potenzialità di consentire il passaggio da codici non simbolici a codici simbolici, da corpi iconici a corpi letterali; inoltre è possibile utilizzare blocchi semantici impliciti in sequenze comunicative esplicite per la presentazione in forma di messaggio vocale o stampato.
Tali tecnologie possono essere combinate per affrontare i casi di disabilità multipla.
L'uso di queste tecnologie riguarda l'adattamento del posto di lavoro di una persona disabile, sia in attività che prevedono un utilizzo locale dell'elaboratore sia nell'utilizzo di quest'ultimo come terminale di accesso ad un sistema informativo distribuito.
Il formato elettronico
In questo documento si fa uso del termine "formato elettronico" intendendo indicare con esso le varie modalità di trattamento, presentazione e archiviazione dell'informazione eseguite con strumenti informatici. L'importanza basilare del formato elettronico, per il tema trattato, è dovuta al fatto che esso potenzialmente rende una qualunque sorgente di informazione fruibile da tutti i possibili utenti, compresi quelli con minorazioni fisiche o sensoriali. Il formato elettronico è, per sua natura, non fruibile direttamente con i sensi umani, ma è fatto per essere trattato da una macchina la quale viene a costituire una intermediazione fra la sorgente dell'informazione e il suo fruitore umano. La presentazione compatibile con una certa modalità sensoriale o la predisposizione a ricevere comandi mediante azioni realizzate per mezzo di dispositivi fisici rappresentano altrettante scelte di progetto del mezzo di intermediazione. Tali scelte ammettono una gamma di opzioni che permettono, in linea di principio, la realizzazione di modi di fruizione diversificati a seconda delle capacità fisiche o sensoriali e delle preferenze dell'utilizzatore.
Così, ad esempio, un cieco può servirsi di un monitor alternativo, sonoro (mediante voce sintetica) o tattile (mediante riga Braille elettronica), o una persona con impedimenti alle mani può interagire con la macchina mediante comandi vocali, tastiere virtuali o emulatori di mouse. Nel primo caso si parla di "lettori di schermo" (screen reader), con uscita sonora o tattile, e nel secondo, di emulatori di dispositivi di input. Per i sordi, le segnalazioni sonore possono essere sostituite o rinforzate da segnali visivi sullo schermo. Per chi ha difficoltà di comprensione dei messaggi scritti, l'interfaccia utente di un applicativo potrebbe essere organizzata sostituendo o integrando i messaggi testuali con simboli di migliore interpretazione, come quelli Bliss.
Tuttavia i criteri di progetto oggi prevalenti sono orientati ad un modello di utente cosiddetto "normodotato", con conseguente privilegio di modalità di presentazione basate sulla multi-medialità, usata nell'ipotesi di un utilizzatore con i 5 sensi integri, e su una interazione con la macchina basata su dispositivi che richiedono movimenti fini manuali, con tempi di reazione spesso brevi, nell'ipotesi di una capacità di manipolazione non limitata da problemi fisici. Queste sono le cause di esclusione di fasce di utenti che non rispondono pienamente a questo profilo e della necessità di recuperare a posteriori una accessibilità violata da un difetto di progettazione.
Il recupero dell'accessibilità non prevista all'origine effettuato a posteriori, mediante adattamenti hardware/software sul terminale utente, ha il suo limite nelle possibilità di interpretazione di informazioni già in forma orientata ad una modalità di fruizione e loro conversione in altra modalità. Finchè tale operazione è possibile, si possono ottenere risultati che allargano il bacino dell'utenza ma, per andare oltre questo limite, occorre far ricorso a raccomandazioni o norme di progetto che prevedano predisposizioni a monte, atte a facilitare una interpretazione diversa da quella originale.
Questo documento traccia le linee da seguire per assicurare un livello adeguato di accessibilità dei sistemi informatici, in applicazione delle raccomandazioni del piano eEurope della Unione Europea e in risposta alle istanze di quegli utenti che si sentono esclusi dallo sviluppo della Società dell'Informazione.
Con il termine "accessibilità", senza ulteriori specificazioni si sottintende che ci si riferisce al concetto di "progettazione universale", definito nel capitolo 4.
Il campo di applicazione
I casi che sono considerati in questo documento, sono principalmente quello delle interfacce utente dei programmi applicativi e quello dei documenti multi-mediali realizzati con linguaggi descrittivi, tipici dei siti Web. Si tratta di due livelli ai quali si pone il problema e sui quali occorre agire.
Nel caso dei documenti separati dal programma di visualizzazione, entrano in gioco entrambi i livelli mentre per gli applicativi dedicati ad altre funzioni il problema si pone in genere solo a livello dell'interfaccia utente.
L'accessibilità dell'interfaccia utente di un applicativo è quindi l'aspetto più generale del problema della fruizione dei sistemi informatici. Progettare una interfaccia utente con criteri di accessibilità, o inserire adattamenti per rendere accessibile una interfaccia utente originariamente priva di queste caratteristiche, è quindi una condizione necessaria per la fruibilità di un sistema informatico da parte di utenti con necessità speciali.
Agli effetti pratici, risulta molto importante sfruttare al massimo le potenzialità della tecnologia assistiva nel progettare o adattare le interfacce utente degli applicativi, oppure nello scegliere fra gli applicativi disponibili dello stesso tipo quello che offre le prestazioni migliori per lo specifico caso. Questo permette infatti la personalizzazione della soluzione di accessibilità, con l'ottimizzazione dell'efficienza e dell'usabilità. Nel caso di programmi di accesso a sorgenti separate di informazione, come i browser, tanto più si riesce a risolvere i problemi di accessibilità a livello "client" tanto più si riduce la necessità di intervento a livello "server", con garanzia di migliori risultati e probabilità di successo.
Nell'allegato 4 di questo documento si forniscono le caratteristiche di base che devono possedere le interfacce utente di applicativi affinchè questi siano considerati accessibili.
Nel caso di documenti multimediali che richiedono un apposito programma di gestione (browser), una condizione necessaria è quindi che tale programma sia accessibile ma purtroppo questo non risolve tutti i problemi poiché, superata la barriera dell'interfaccia utente, ne esiste una seconda a livello di sorgente di informazione. Questo riguarda soprattutto l'informazione distribuita in rete o su supporti mobili, come dischi magnetici o ottici.
Grazie ad una lunga e intensa attività di ricerca a livello internazionale, oggi sono disponibili, oltre alle tecnologie alternative per la presentazione dell'informazione e l'interazione uomo-macchina, anche le tecniche per garantire l'accessibilità delle sorgenti di informazione ipertestuale e multimediale a tutte le tipologie di utenti, senza rinunciare alla ricchezza e flessibilità di queste nuove forme di documentazione.
Nel paragrafo 5 e negli allegati 2 e 3 vengono dettagliati i metodi di intervento per garantire l'accessibilità dei siti Web e dei documenti ipertestuali in genere.
Il principio basilare dell'accessibilità dell'informazione è quello più generale della Progettazione Universale (Design for all), secondo il quale le specifiche di progetto devono sempre tener conto della varietà di esigenze di tutti gli utenti.
Se ne elencano di seguito i fondamenti:
1. equità d'uso
2. flessibilità di uso
3. uso semplice ed intuitivo. L'uso del progetto sia facile da capire, indipendentemente dall'esperienza dell'utente, conoscenza, perizia di linguaggio, o capacità di concentrazione.
4. informazione accessibile.
5. tolleranza agli errori.
6. sforzo fisico minimo.
7. dimensione e spazio per l'uso adatto a qualsiasi utente, senza limiti per la capacità di movimento, la postura e la dimensione del corpo.
( Vedi: http://www.design.ncsu.edu:8120/cud/univ_design/princ_overview.htm)
Il principio è nato in ambito architettonico: si pensi alle rampe in alternativa alle scale, norma ormai adottata per gli edifici pubblici.
Con riferimento all'accessibilità del formato elettronico si concretizza nella progettazione di sistemi, prodotti e servizi fruibili direttamente da ogni utente o compatibili con la tecnologia assistiva.
Questo principio si traduce in percorsi attuativi specifici per ogni ambito di applicazione.
L'interpretazione corretta di "sito accessibile" è quella di ambiente multimediale il cui contenuto informativo, nonchè le relative procedure di interazione e navigazione, siano fruibili da utenti dotati di diversi browser con diverse configurazioni, dove siano abilitate o disabilitate le funzioni di caricamento di immagini, di animazione, di suono, di colore, di temporizzazione, e dove si possa omettere l'uso di visualizzatori addizionali (plug-in).
I documenti multimediali devono perciò essere provvisti di informazioni ridondanti, in modo da coprire le necessità di presentazione e interazione nelle varie modalità previste dalla postazione client e devono essere strutturati seguendo certe regole.
Su questo argomento, i documenti generalmente considerati di riferimento a livello internazionale sono le "linee guida" (o "Orientamenti") elaborate dal progetto WAI del consorzio W3C (http://www.w3.org/WAI). Data la complessità del problema dell'informazione in rete, il progetto WAI ha ritenuto necessario lavorare su tre fronti: il contenuto dei documenti, con particolare riferimento ai linguaggi utilizzati (Web content), gli applicativi di navigazione (User Agents) e i sistemi autore (Authoring Tools) elaborando delle Linee Guida specifiche per ciascuno di questi argomenti. Di particolare interesse per il tema qui trattato sono quelle dirette a chi sviluppa siti Web (http://www.w3.org/TR/WAI-WEBCONTENT/).
Tali Linee Guida si ispirano a due principi generali: la trasformabilità coerente delle pagine e la loro strutturazione comprensibile e facilmente navigabile. Il primo principio esprime il concetto che l'informazione deve rimanere completamente comprensibile per qualunque configurazione di terminale utente. Il secondo richiama la necessità di un facile orientamento all'interno della struttura del documento. L'applicazione delle linee guida prevede l'utilizzo di "checkpoint" suddivisi in tre livelli di priorità (indispensabili, utili e consigliabili), la cui verifica determina il livello di conformità di un sito con tali raccomandazioni, contrassegnato da una, due o tre A, a seconda di quali livelli di priorità sono stati rispettati.
Gli orientamenti WAI rappresentano una eccellente documentazione tecnica sull'argomento e, in via teorica, forniscono le soluzioni da adottare per conseguire un alto livello di accessibilità, ma presentano qualche difficoltà di utilizzazione come norme da prescrivere. In particolare, i puntuali procedimenti di verifica (checkpoint) previsti, si sono dimostrati di difficile applicazione da parte di chi è privo di una cultura specifica sull'accessibilità e sull'architettura di documenti elettronici.
La verifica della conformità del contenuto di un documento agli orientamenti WAI può essere facilitata dall'utilizzo di programmi di "validazione", come ad es. Bobby, (http://www.cast.edu/bobby), che assiste lo sviluppatore proponendo controlli automatici e manuali. Tuttavia procedure di questo tipo presentano difficoltà di esecuzione e soprattutto di interpretazione dei risultati. L'accessibilità non può infatti essere valutata con una procedura completamente automatica e pertanto anche l'uso di questi programmi richiede delle competenze specifiche non comuni.
Il presente documento affronta il problema della adozione degli orientamenti WAI da un punto di vista applicativo, tenendo conto dei condizionamenti dovuti alla necessità di dare direttive in lingua italiana, di chiara interpretazione e di semplice applicazione nonchè di fornire altrettanto semplici criteri di verifica.
Il perseguimento di questo obiettivo ha indotto a cercare un diverso approccio al problema: quello di partire dal punto di vista dell'utilizzatore e da quello dell'operatore che cura lo sviluppo e l'aggiornamento di un sito. Questo approccio ci porta immediatamente a confrontarci con le prestazioni dei "tools" usati da queste due figure di riferimento.
Si tratta allora di partire da una definizione "strumentale" dell'accessibilità. Osservando che un certo documento risulta più o meno accessibile a seconda del browser usato e della sua configurazione, per affrontare il problema da un punto di vista operativo, occorre stabilire un protocollo di valutazione dell'accessibilità, facendo riferimento esplicito ad una postazione utente tipo con la quale fare la valutazione.
L'Allegato 2 di questo documento riporta una "definizione strumentale" di accessibilità delle pagine Web, elaborata all'interno del gruppo di lavoro. L'approccio basato su questa definizione si pone come un metodo originale per affrontare il problema dell'accessibilità web, conferendo un ruolo centrale al punto di vista dell'utente, ma al tempo stesso garantendo anche l'autore di documenti con regole facilmente verificabili.
L'Allegato 3 invece si raccorda con la circolare n.3/2001 del Ministro della Funzione Pubblica e dettaglia i criteri di applicazione delle regole di accessibilità risultanti dall'attività del gruppo di lavoro AIPA per conseguire il livello base di accessibilità dei siti. Tali regole applicano gli orientamenti dell'iniziativa WAI.
Uno degli ostacoli alla integrazione del personale disabile nelle attività degli uffici della PA è rappresentato dalle barriere insite nelle interfacce utente del software utilizzato per lo svolgimento di tali attività. Questo riguarda anche il telelavoro.
Il problema si estende anche agli utenti dei servizi della PA, quando questi ultimi sono basati su procedure informatiche e telematiche, con uso di programmi specifici, come ad esempio quelli per la dichiarazione dei redditi on-line. Un altro importante settore in cui i problemi di accessibilità del software sono molto critici è quello delle applicazioni didattiche multimediali, date le dirette conseguenze sulla integrazione dei ragazzi disabili nella scuola. Più in generale, il problema investe tutta la pubblicazione di documentazione in forma multimediale, su CD ROM o altri supporti, sempre più frequente nella scuola e in molti settori della PA.
Riguardo alle pubblicazioni multimediali, si possono distinguere due casi: documenti in HTML o altri linguaggi descrittivi, o opere integrate con una loro interfaccia utente. Nel primo caso, il problema dell'accessibilità dell'interfaccia utente è risolvibile con la scelta del browser più adatto mentre quello dell'accessibilità del documento ricade sotto le regole di accessibilità dei documenti normalmente sviluppati per i siti Web. Nel secondo caso invece, non essendo separabile il problema dell'interfaccia utente da quello della sorgente di informazione, l'approccio da seguire è quello dell'accessibilità del software in genere.
L'accessibilità delle interfacce utente è quindi un problema cruciale per l'autonomia delle persone disabili, sia quando agiscono in veste di operatori della PA sia come utenti della stessa.
Le moderne interfacce grafiche richiedono spesso capacità sensoriali e motorie che precludono di fatto l'utilizzo dei programmi da parte di molte persone disabili, a meno che non siano state progettate con criteri tali da essere rese accessibili con l'ausilio della "tecnologia assistiva", cioè di specifiche integrazioni hardware e/o software delle macchine su cui devono operare. Screen readers con sintesi vocale o riga Braille per i ciechi, sistemi di ingrandimento elettronico per gli ipovedenti, input vocale o tastiere speciali per i disabili motori, possono permettere a queste persone con minorazioni sensoriali o fisiche di utilizzare programmi standard, purchè progettati seguendo alcune linee guida. Ad esempio, i programmi del pacchetto MS Office sono compatibili in modo soddisfacente con le varie soluzioni tecniche per l'accessibilità delle interfacce utente di MS Windows poiché progettati tenendo conto anche di questo obiettivo. Non tutti gli altri applicativi dell'ambiente Windows possiedono invece questi requisiti.
Nell'allegato 4, si elencano in sintesi le specifiche di progetto per l'accessibilità delle interfacce dei programmi applicativi. Si fa riferimento principalmente alle interfacce grafiche poiché sono quelle che presentano i maggiori problemi. Alcune delle raccomandazioni sotto riportate sono comunque applicabili in generale, a prescindere dal sistema operativo.
Come fatto per l'accessibilità dei siti Web, anche per il software si parte da una definizione "strumentale" di accessibilità, al fine di fornire, sia agli utenti sia agli sviluppatori, criteri di valutazione verificabili sperimentalmente.
L'integrazione delle caratteristiche fondamentali di accessibilità in un sito web o in una applicazione software comporta costi differenti a seconda delle tecnologie impiegate e soprattutto del momento dell'intervento.
Nel corso dello sviluppo iniziale del sito, cioè quando è possibile avere un controllo sul progetto, sulla struttura e sugli strumenti che si intendono impiegare, l'intervento può comportare un costo aggiuntivo ridotto, anche dell'ordine dell'uno per cento. Si può peraltro dare il caso che una attenta progettazione eseguita nel rispetto delle regole della progettazione universale e delle migliori pratiche possa anche tradursi in una diminuzione dei costi complessivi di sviluppo. Ad esempio, la decisione di ricorrere a strumenti di content management o a tecnologie innovative, che pure comporta maggiori investimenti, ha come conseguenza una maggiore efficienza nell'alimentazione e nella manutenzione del sito, che si traduce in costi marginali ridotti e costanti. In alcuni casi, quindi, un approccio innovativo o comunque più impegnativo, inizialmente stimolato dalle problematiche di accessibilità, può tradursi in un risparmio rispetto ad altre soluzioni.
Diverso è il caso della manutenzione di un sito o una applicazione già esistente. Se vengono utilizzati strumenti manuali o semiautomatici i costi degli interventi possono essere stimati tra il 10% e il 20% del costo di sviluppo del sito, costi peraltro di natura ricorrente proprio perché questo tipo di interventi si esplica tipicamente sul contenuto via via sviluppato piuttosto che sulle procedure di alimentazione. E' inoltre difficile definire un limite superiore attendibile vista la grande variabilità di dimensione, di architettura e di organizzazione dei siti web. Anche in questo caso, il ricorso a strumenti automatici di gestione dei contenuti o ad altri strumenti o tecnologie appropriate può ridurre il costo dell'intervento ad una percentuale molto ridotta.
1) eEurope
Una società dell'informazione per tutti
Comunicazione relativa ad un'iniziativa della Commissione
in occasione del
Consiglio europeo straordinario di Lisbona
(23 - 24 marzo 2000)
http://www.governo.it/fsi/ita/eEurope.htm
2) eEurope: An Information Society For All
Progress report
For the Special European Council on Employment, Economic reforms and Social Cohesion - Towards a Europe based on Innovation and Knowledge
Lisbon, 23 and 24 March 2000
http://www.europa.eu.int/comm/information_society/eeurope/documentation/progrep/progrep_en.htm
3) eEurope2002
An Information Society For All
ACTION PLAN
prepared by the Council and the European Commission, for the Feira European Council
19-20 June 2000
http://www.europa.eu.int/comm/information_society/eeurope/actionplan/index_en.htm
Si definisce "sito accessibile" quello che non presenta difficoltà di orientamento, navigazione, lettura di pagine e documenti, scaricamento di files e interazione con "forms" o quant'altro richieda introduzione di dati e gestione di comandi, quando tali operazioni sono eseguite, con una qualunque delle configurazioni di terminale utente sotto elencate, da una persona che sia sufficientemente addestrata nell'uso di tale terminale.
Questa definizione ha carattere dinamico essendo suscettibile di aggiornamenti periodici, seguendo l'evoluzione della tecnologia.
In questo documento, con il termine "versione italiana recente" si intende una versione disponibile in Italia a gennaio 2000 o successivamente.
1. Uso di browser grafico di versione di seguito indicata o superiore, anche se privo di visualizzatori speciali, con capacità di gestione di CSS o di componenti multimediali disabilitate (immagini, animazioni, suoni, colore): MS Internet Explorer, Netscape Navigator, Opera, Amaya, di versione recente.
2. Uso del browser testuale Lynx 2.8 o superiore, in versione per Unix, Dos o "Prompt di Dos" di Windows 95 o superiore.
3. Come al punto 2, in combinazione con uno screen reader testuale per Dos, in versione italiana recente (nel caso di Lynx per Unix, si intende che l'accesso da parte di un utente cieco avvenga tramite emulatore di terminale VT100 sotto Dos, non essendo ancora disponibile uno screen reader per Unix di uso generale per la lingua italiana).
4. Come al punto 1 in combinazione con uno screen reader per ciechi operante sotto Windows 95 o superiore, in versione italiana recente.
5. Come al punto 1, in combinazione con un ingranditore di schermo per ipovedenti in versione italiana recente.
6. Come al punto 1, in combinazione con un ausilio per disabili motori, con tastiera e/o mouse alternativi, in versione italiana recente.
7. Come al punto 1, in combinazione con un sistema di input vocale a controllo completo dell'interfaccia utente, in versione italiana recente.
Si ritiene che l'elenco delle configurazioni di terminale utente sopra elencate coprano le necessità tipiche delle persone con disabilità sensoriale o motoria e costituiscano un banco di prova del livello di accessibilità di un sito, verificabile oggettivamente.
I punti 1 e 2, essendo svincolati dalla tecnologia assistiva, rispondono all'esigenza di una verifica di prima approssimazione effettuabile direttamente e facilmente da chi sviluppa pagine Web. Essi coprono anche le necessità di quegli utenti che, pur non essendo affetti da minorazioni fisiche o sensoriali, si trovano in condizione di non poter fruire pienamente di tutte le componenti multimediali di un sito, a causa delle condizioni ambientali (locale rumoroso, con illuminamento disturbante, con connessione alla rete a banda molto stretta ecc..).
In particolare, il punto 1 indica una modalità di verifica dell'accessibilità che può simulare le condizioni di varie disabilità sensoriali, attraverso la disattivazione selettiva di una o l'altra funzione multimediale (es.: immagini e grafica per simulare la cecità, suoni per la sordità, colori per i difetti di percezione cromatica).
La verifica con le varie forme di tecnologia assistiva (ausili) indicate negli altri punti consente di riprodurre in modo più completo e reale le condizioni operative degli utenti disabili. La compatibilità con qualunque modello o versione di ausilio delle tipologie elencate è raccomandata ma, qualora non sia ottenibile per manifesta inferiorità di prestazioni di un modello o versione rispetto ad altri, si potrà considerare raggiunto il livello minimo di accessibilità di una pagina che risulti ben fruibile con gli ausili più avanzati.
Sono stati considerati i browsers e gli ausili sopra elencati, riferiti solo ai sistemi operativi citati, poiché di fatto sono quelli più utilizzati. Non vengono tuttavia esclusi altri prodotti per altri sistemi operativi, come Macintosh o X-Windows, per i quali però sono disponibili soluzioni di accessibilità non sempre generalizzate per tutti gli utenti disabili e quindi di difficile comparazione. L'equivalenza di prestazioni di versioni di browsers disponibili per diverse piattaforme garantisce comunque che una verifica di accessibilità fatta con una di queste si possa considerare potenzialmente estesa alle altre, anche quando ciò non è direttamente verificabile.
Premessa
Questo documento fornisce i criteri di applicazione delle regole di accessibilità indicate nella CIRCOLARE N. 3/ 2001 del Ministro della Funzione Pubblica, dal titolo "LINEE GUIDA PER L'ORGANIZZAZIONE, L'USABILITÀ E L'ACCESSIBILITÀ DEI SITI WEB DELLE PUBBLICHE AMMINISTRAZIONI".
Esso suggerisce la corretta interpretazione delle regole di accessibilità contenute nella citata circolare raccogliendo anche richieste pervenute dalle organizzazioni dei disabili italiani, dando una interpretazione a queste istanze che tiene conto delle indicazioni tecniche più accreditate a livello internazionale, come le Linee Guida WAI, ma anche delle esigenze sia di chiare regole applicative da parte di chi gestisce i siti pubblici sia di verifica da parte degli utenti.
Le regole menzionate e i loro criteri di applicazione, riportati nel seguito, mirano al raggiungimento di una accessibilità di base, comprensibile e verificabile, indicando anche la procedura di verifica, basata sulla simulazione del "punto di vista" dell'utente disabile.
Pertanto, tutti coloro che, a vario titolo, sono coinvolti nella progettazione, gestione e aggiornamento dei siti della PA, possono attenersi a questi suggerimenti, per garantire che tali siti abbiano i requisiti fondamentali di accessibilità. In alternativa, coloro che sono in condizione di farlo, possono applicare fin nei dettagli gli orientamenti WAI "Web Content Accessibility Guidelines 1.0" del Consorzio W3C, con le procedure di verifica in essi suggerite, le quali, se applicate integralmente, permettono di raggiungere un livello più alto di accessibilità.
Per maggiori dettagli sulle tecniche da usare e sulle verifiche da eseguire per far riferimento agli orientamenti W3C/WAI (Web Accessibility Initiatives), si veda http://www.w3.org/WAI, dove sono reperibili anche collegamenti a documenti tradotti in italiano.
Criteri di applicazione delle regole di accessibilità
Il principale criterio di applicazione del concetto di accessibilità è quello di organizzare una versione unica di un sito Web, secondo il principio di Progettazione Universale, avendo cura che non siano contenute barriere per alcun tipo di utente. Si deve perciò evitare di fare versioni parallele, come una versione "solo testo" per i ciechi. Infatti, un sito in varie versioni non rappresenta una soluzione efficiente, dato che si risolve in un aggravio di lavoro per la sua gestione e non garantisce la disponibilità delle stesse informazioni in tutte le versioni, per le difficoltà di aggiornamento.
Una versione speciale, come quella solo testo, deve rappresentare un'eccezione, da adottare solo in quei casi nei quali, per oggettive difficoltà di conseguire l'accessibilità di un sito, non restino altre alternative. In questo caso, il link di accesso a tale versione speciale deve essere posto in una posizione della "Home page" facilmente raggiungibile dagli utenti interessati, meglio se come primo nella pagina. Le versioni parallele sono comunque giustificate solo se garantiscono un miglioramento effettivo del grado di accessibilità e sono accettabili solo se è assicurato l'allineamento del contenuto delle pagine del sito accessibile con quello principale.
In generale, anche nel caso di intervento di recupero di accessibilità su un sito esistente, si raccomanda di tentare la soluzione basata sul restauro delle pagine, seguendo le regole di accessibilità. Questo approccio, si rivela produttivo nel lungo periodo ed è senza dubbio più corretto.
Si deve tuttavia distinguere il caso di presentazioni diverse delle pagine, ottenute automaticamente in funzione del profilo del client. Queste tecniche di adattabilità dal lato server, nate per ottimizzare la presentazione a fronte di caratteristiche diverse dei browser, possono essere sfruttate con buoni risultati anche nel campo dell'accessibilità. Esse infatti garantiscono la completezza e l'aggiornamento dell'informazione poiché utilizzano un unico contenuto informativo e quindi rispettano il principio di Progettazione Universale.
In linea di principio, si deve quindi cercare di realizzare documenti accessibili facendo coesistere componenti orientate a diverse necessità degli utenti. Anche quando queste esigenze possono apparire in contrasto fra loro, esiste sempre la possibilità di trovare la soluzione facendo ricorso alla ridondanza di informazione. Questo è il caso delle opzioni "noframes" e "noscripts", che forniscono procedure alternative per i browser che non trattano queste componenti, e degli "equivalenti testuali", che consentono di fornire le stesse informazioni anche a chi, per varie ragioni, non può fruire di una o più componenti multimediali, senza rinunciare all'uso di queste ultime.
Gli equivalenti testuali vanno applicati a tutta la vasta gamma di componenti quali: immagini, rappresentazioni grafiche del testo (inclusi i simboli), bottoni grafici, regioni delle mappe immagine, applets e altri oggetti di programmazione, ASCII art, piccole immagini usate come identificatori delle voci di una lista, spaziatori, disegni, grafi, filmati o altre immagini in movimento, come GIF animate.
Si noti che gli equivalenti testuali sono di grande utilità, oltre che per gli utenti che non hanno accesso alle componenti multimediali, anche per gli agenti automatici, come i motori di ricerca.
Gli equivalenti testuali possono essere semplici etichette associate all'elemento grafico (es. attributo "alt" in HTML) o vere e proprie descrizioni dettagliate inserite in una pagina separata e collegata all'elemento grafico mediante un link. Il criterio di scelta del tipo di equivalente testuale da usare deve basarsi sulla finalità dell'elemento grafico. Per una immagine, può essere necessaria una vera descrizione solo quando il contenuto della stessa è significativo per la comprensione del documento nel quale è inserita, mentre è sufficiente una semplice etichetta testuale che ne indichi la funzione in tutti gli altri casi. Questo vale anche per le immagini sensibili (bottoni o aree di mappa immagine), per le quali il testo alternativo deve indicare chiaramente l'effetto della loro attivazione.
Si noti che non vanno trascurati neppure gli elementi grafici decorativi (inseriti per scopo estetico o di richiamo di attenzione); si consiglia di usare un equivalente testuale fittizio, costituito da caratteri spazio, oppure di sovrapporli al documento mediante un foglio di stile, in modo da permettere la loro eliminazione disattivando quest'ultimo. Questi semplici accorgimenti permettono di migliorare l'estetica di un documento con una distribuzione strategica di simboli grafici, rendendolo di più facile consultazione da parte di disabili cognitivi e ipovedenti, senza appesantire lo scorrimento dello stesso mediante uno screen reader, con la ripetizione di informazioni su elementi inutili per un utente non vedente.
Altri criteri di uso delle immagini da tenere presenti riguardano le figure di sfondo ad una pagina e un testo realizzato in forma di immagine. In generale, si sconsiglia l'uso di entrambi questi tipi di immagine. Una figura di sfondo disturba la percezione del testo sovrapposto da parte dei disabili cognitivi e degli ipovedenti. Una immagine di testo non possiede una sufficiente flessibilità per adattarsi alle esigenze degli utenti ipovedenti. Si consiglia di usare un foglio di stile per realizzare presentazioni di testo con particolari esigenze di evidenziazione. Se, per qualche ragione, è indispensabile inserire un testo in forma di immagine, si deve associare il suo equivalente testuale e si deve curare la sua leggibilità diretta, adottando caratteri di dimensione adeguata e combinazioni di colori o livelli di grigio che assicurino un alto contrasto fra figura e sfondo.
In altre parole, come criterio generale sia per i testi che per le immagini, si deve scegliere una rappresentazione grafica semplice ed efficace: la creatività non deve mai andare a scapito della leggibilità e della fruibilità. Vanno evitati caratteri troppo piccoli, righe compresse, font bizzarri, colori sfumati o con tenui contrasti con lo sfondo; chiaro ed immediato deve essere in particolare l'aspetto grafico delle icone e di testi rappresentati attraverso immagini e quindi non modificabili dall'utente. Una buona qualità grafica del testo è utile a tutti; per molte persone con problemi di vista è condizione indispensabile per poter accedere al Web, direttamente o attraverso opportuni ingrandimenti.
Un altro fattore critico per l'accessibilità è rappresentato dall'uso delle tabelle. Le tabelle vengono infatti usate spesso nelle pagine web per due diverse funzioni: la presentazione di dati che richiedono effettivamente questo formato e l'organizzazione della struttura di pagina. Nel secondo caso l'uso della tabella è improprio, perché rappresenta un uso di componenti strutturali ai fini di presentazione, e pertanto si raccomanda di usare tecniche più appropriate come quelle dei fogli di stile. Per il primo caso relativo alla tabulazione dei dati occorre comporre i documenti con il maggior numero possibile di marcatori per la individuazione della cella all'interno della griglia. In particolare è utile inserire le intestazioni di riga e di colonna, affinchè i dispositivi alternativi di visualizzazione, come gli scren readers più avanzati, possano procedere ad una corretta individuazione della cella stessa. Risulta utile anche una descrizione dell'organizzazione dei dati che può essere fornita ad esempio come didascalia della tabella stessa. Anche in questo caso, riferendosi specificatamente al linguaggio HTML, si ricorda che esistono attributi di alcuni marcatori atti a questo scopo. Inoltre, quando si devono creare tabelle complesse (ad es. con struttura nidificata), può essere consigliabile di fornire una pagina alternativa con una versione linearizzata della tabella stessa.
Da quanto detto sopra, risulta di fondamentale importanza l'uso di fogli di stile per organizzare la presentazione di una pagina, in applicazione del principio di separazione fra contenuto e visualizzazione della pagina. Grazie alla flessibilità e intercambiabilità dei fogli di stile, il loro impiego assicura la personalizzazione della visualizzazione dei documenti da parte dell'utente. Ad esempio, gli ipovedenti traggono particolare vantaggio dall'uso di un foglio di stile personalizzato poiché possono scegliere il font, le sue dimensioni e il più adatto contrasto cromatico per la visualizzazione del testo, ma è evidente che anche altri utenti possono giovarsi di questa opportunità, compresi quelli che preferiscono disabilitare del tutto la gestione dei CSS per accedere direttamente al contenuto di un documento, senza le sovrastrutture della sua presentazione.
Criteri di progettazione e di gestione dei siti
Oltre alle regole riferite alla organizzazione delle pagine e dei siti Web, per garantire l'accessibilità di questi documenti e strutture, ci sono delle regole generali di progetto e di gestione da osservare per ridurre i problemi degli utenti disabili, ma che, come avviene per le regole di accessibilità, tornano a vantaggio di tutti gli altri utenti.
a) Usare criteri di progetto del sito che prevedano una struttura comprensibile, applicando anche quei criteri di "usabilità" dei siti, che prescrivono di evitare l'affollamento di links nonchè strutture di pagina e di navigazione complesse. Siti ben organizzati e con facili meccanismi di orientamento e navigazione, risultano ben predisposti anche per una buona accessibilità. In particolare, pagine semplici e chiare risultano più accessibili ad utenti affetti da afasia o altre difficoltà cognitive. Tra questi disabili emergono per rilevanza i soggetti afasici, che sono incapaci di esprimere verbalmente concetti, e che, quindi, sono incapaci di comunicare con il prossimo, pur essendo del tutto intellettualmente integri nel concepire idee e pensieri. Per loro e, più in generale, per chi ha difficoltà di comunicazione, può risultare utile far uso di simboli grafici o ideogrammi in punti critici delle pagine Web, come i links.. Inoltre, icone, bottoni e altre aree sensibili dovrebbero avere larghezza e altezza non inferiori al 4% di quelle dello schermo (questo faciliterà il puntamento da parte dei disabili motori che usano un emulatore di mouse e da parte degli ipovedenti). Esistono poi metodi ed applicazioni informatiche, quali il metodo Bliss, che sono in fase di sperimentazione.
b) Dotare i siti di una mappa di navigazione interattiva, per migliorare la comprensione della struttura, e predisporre un motore di ricerca con il controllo ortografico incorporato, per facilitare il reperimento di informazioni specifiche.
c) Mantenere nel progetto una struttura omogenea delle pagine di un sito. Chi ha difficoltà cognitive o esplora una pagina con strumenti di lettura sequenziale, come un utente cieco che utilizza un lettore di schermo, ha difficoltà a capire come è strutturata una pagina, quando la visita per la prima volta. Le difficoltà diminuiscono molto una volta memorizzata la struttura. Sarà quindi favorito se ritrova la stessa struttura nelle altre parti del sito, mentre sarà disorientato da cambiamenti fra una pagina e l'altra, con conseguente perdita di tempo ed aggravio del costo di collegamento. Una struttura omogenea delle pagine è comunque di aiuto per tutti gli utenti, indipendentemente da problemi di disabilità.
d) Nel caso di documenti di grandi dimensioni, per coloro che sono condizionati ad una lettura o navigazione rallentata da una modalità alternativa non altrettanto efficiente della lettura visiva, o a causa di difficoltà cognitive, è utile predisporre una versione compressa del documento, da scaricare per la lettura fuori linea, con notevole riduzione del tempo di connessione e del relativo costo. Se il documento è strutturato su più files separati e collegati fra loro, la versione compressa dovrà includere tutti questi files. Inoltre, i collegamenti (links) devono essere di tipo relativo, in modo da permettere la navigazione interna anche dopo l'installazione in ambiente locale. I nomi dei files e delle directories devono essere compatibili con tutti i programmi di navigazione.
e) I documenti disponibili per lo scaricamento dovrebbero avere formati accessibili e non proprietari: HTML, RTF, testo. Se sono necessari altri formati, come PDF, GIF, JPG, accompagnarli con una versione accessibile.
Oltre alle raccomandazioni contenute in questo documento, sono attualmente allo studio da parte dell'AIPA alcuni strumenti di supporto al progetto e al recupero di siti Web, come modelli di sito delle varie tipologie della PA e programmi applicativi consigliati per la validazione e il recupero, che saranno oggetto di futuri ulteriori interventi.
Definizione di accessibilità del software
Si definisce "programma accessibile" quello dotato di una interfaccia utente che, con l'eventuale ausilio di tecnologia assistiva (ausili), non presenta difficoltà di:
lettura dello schermo, comprese le finestre in esso contenute,
controllo dell'ingresso di dati e dell'interazione con elementi o oggetti dell'interfaccia stessa, (menu orizzontali o a tendina, bottoni, campi di editing, "check box", "radio box" o quant'altro richieda introduzione di dati e gestione di comandi).
Questa definizione si riferisce all'uso di una qualunque delle configurazioni di "tecnologia assistiva" sotto elencate e ha carattere dinamico, essendo suscettibile di aggiornamenti periodici in relazione all'evoluzione della tecnologia.
Non si fa riferimento al sistema operativo sotto il quale devono funzionare gli applicativi poiché si sottintende che, in linea di principio, le caratteristiche di accessibilità devono essere possedute da tutti i programmi, a prescindere dalla piattaforma hardware e software di destinazione, purchè sia disponibile la specifica tecnologia assistiva. La definizione di accessibilità non è infatti applicabile nei casi in cui l'accessibilità stessa non è realizzabile a causa della indisponibilità di ausili specifici.
In questo documento, con il termine "versione italiana recente", riferita agli ausili, si intende una versione disponibile in Italia a gennaio 2000 o successivamente.
Elenco delle configurazioni di tecnologia assistiva
Si intende che i programmi devono funzionare:
In combinazione con uno screen reader per ciechi, con sintesi vocale o display Braille, operante sotto lo specifico sistema operativo, in versione italiana recente.
In combinazione con le funzioni di ausilio per ipovedenti e disabili motori fornite dal sistema (es.: Windows98 o superiore).
In combinazione con un applicativo specifico di ingrandimento di schermo, in versione italiana recente.
In combinazione con un sistema di input vocale, con dettatura di testo e emulazione di comandi di tastiera e/o mouse, in versione italiana recente.
In combinazione con un ausilio per disabili motori, con tastiera e/o mouse alternativi, in versione italiana recente.
Nel caso di applicativi per sistemi multi-utente attraverso un terminale, le condizioni di accessibilità si applicano all'emulatore di terminale, il quale può funzionare sotto altro sistema operativo, permettendo di scegliere la soluzione più favorevole. Ad esempio, nel caso di applicativi con interfaccia testuale a basso livello per Unix, inclusa la versione Linux, esiste la possibilità di uso mediante emulatore di terminale in ambiente Dos o Windows, dove sono disponibili soluzioni di accessibilità per le diverse disabilità, per cui gli applicativi di questo tipo possono essere considerati accessibili indirettamente, anche nel caso di indisponibilità di soluzioni specifiche nell'ambiente originale.
Nel caso invece di applicativi speciali, progettati e realizzati con impiego integrato di tecnologia assistiva, la loro fruibilità da parte degli utenti ai quali sono specificatamente indirizzati risulta indipendente dalla disponibilità o meno di soluzioni generali di accesso per il sistema operativo sotto il quale possono essere eseguiti, pertanto, essi appartengono ad una categoria separata e possono essere ritenuti accettabili per quegli utenti specifici. Si deve tuttavia osservare che applicativi di questo tipo non consentono in generale all'utente il controllo dell'ambiente operativo, in quanto l'accessibilità è garantita solo all'interno dello specifico programma, limitando l'autonomia dell'utente. Alla categoria degli applicativi speciali appartengono anche le soluzioni hardware/software integrate, costituite da apparecchi dedicati a funzioni speciali, come terminali o lettori di documenti, direttamente progettati per l'impiego da parte di specifici tipi di utenti.
Regole generali di accessibilità dei programmi applicativi
Vengono forniti alcuni criteri di progetto per chi desidera sviluppare programmi applicativi predisposti per essere accessibili quando usati in combinazione con la tecnologia assistiva, secondo la definizione sopra riportata.
a) Accessibilità dalla tastiera
1. Tutte le funzioni del programma 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. Tutte le operazioni possibili con comandi di tastiera devono essere chiaramente descritte nella documentazione del programma.
2. I comandi impartiti con combinazione di tasti di scelta rapida devono rispettare per le operazioni più comuni le scelte abituali del sistema operativo. Vanno inoltre preferite combinazioni semplici di tasti che risultino di facile memorizzazione e che richiedano una modesta abilità manuale per l'esecuzione. I comandi di scelta rapida devono infine essere ridefinibili dall'utente per risolvere eventuali problemi di conflitto con quelli della tecnologia assistiva.
3. Il programma deve prevedere una successione logica delle operazioni di interazione. Il "fuoco" deve essere chiaramente individuabile dalla tecnologia assistiva, per seguirne il percorso e consentire l'interpretazione alternativa delle operazioni.
4. Il programma non deve interferire con le funzioni di accessibilità eventualmente disponibili nel sistema operativo (ad esempio. "Accesso facilitato" di MS Windows).
5. I comandi basati su una risposta a tempo devono essere evitati, oppure deve essere prevista una regolazione del tempo di risposta operabile dall'utilizzatore.
b) Icone
1. Tutte le icone devono avere una chiara etichetta testuale o una alternativa testuale selezionabile dall'utilizzatore.
2. 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.
c) Oggetti
1. Il programma deve usare le routines di sistema per la presentazione del testo, in modo da permetterne l'interpretazione alla tecnologia assistiva (si tenga conto che un testo inserito direttamente in una presentazione grafica non è accessibile a tutti). L'informazione minima da fornire per tale interpretazione è costituita dal contenuto testuale dello schermo, dagli attributi del testo e dalla posizione del cursore.
2. Il programma deve rendere disponibili sufficienti informazioni sugli oggetti usati dall'interfaccia utente, affinchè la tecnologia assistiva possa identificarli e interpretarne la funzione.
d) Multi media
1. Il programma deve prevedere opzioni di segnalazione visiva alternative di avvertimento e rinforzo delle segnalazioni sonore di allarme del programma.
2. Il programma 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 è palesemente in contrasto con le funzioni del programma o oggettivamente impossibile da realizzare o non sufficiente per un utilizzatore non udente (es.: programmi di montaggio audio).
3. Il programma deve prevedere opzioni di descrizione vocale o presentazione sincronizzata in formato testuale di tutte le informazioni di tipo video (immagini e grafici statici o in movimento), se questo non è palesemente in contrasto con le funzioni del programma o oggettivamente impossibile da realizzare o non sufficiente per un utilizzatore non vedente (es.: programmi CAD o di montaggio fotografico).
e) Presentazione a video
1. Il programma 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.
2. Il programma deve permettere all'utilizzatore di scegliere i colori e regolare il loro contrasto, sia nell'interfaccia utente sia nelle aree di lavoro e presentazione dati.
3. L'applicazione non deve contenere immagini di sfondo in presenza di un testo o un grafico importante, oppure deve essere fornita di una opzione per eliminare tale sfondo.
4. Il programma deve permettere all'utilizzatore di cambiare dimensioni e tipo di caratteri, per mezzo del sistema operativo, per la presentazione a video e per la stampa.
5. Il programma deve permettere all'utilizzatore di regolare o bloccare gli effetti di lampeggio, rotazione o movimento delle presentazioni a video, se questo non interferisce con lo scopo dell'applicazione.
6. Il programma deve permettere all'utente di selezionare la definizione di schermo preferita.
7. Il programma deve rispettare le scelte dell'utente relative ai puntatori di sistema del mouse.
8. Elementi selezionabili. Si deve prevedere una distanza minima di almeno il 4% della larghezza o altezza dello schermo oppure deve essere prevista un'opzione di ridimensionamento.
f) Etichette dei campi
1. Le etichette relative ai campi dei dati devono trovarsi immediatamente vicine ai campi stessi, preferibilmente a sinistra, in modo da facilitare la loro lettura, e l'associazione al campo relativo, da parte degli screen readers per i ciechi.
g) Documentazione
1. Tutta la documentazione deve essere fornita anche in formato elettronico accessibile. Devono essere inclusi nella documentazione anche descrizioni testuali di figure e grafici.
2. Qualunque uscita prodotta dal programma deve essere disponibile in formato accessibile.
Riferimenti
Linee guida più dettagliate per l'accessibilità del software e documentazione tecnica per gli sviluppatori sono disponibili in numerosi siti Web. Si veda ad esempio:
http://www.trace.wisc.edu/world/computer_access/software
http://www.microsoft.com/enable
http://www-3.ibm.com/able/snsjavag.html
http://www.sun.com/access
http://ncam.wgbh.org/cdrom