DiGrande.it

Non Vedenti, Braille e Tecnologie di Stampa

Questo sito usa Cookie per personalizzare contenuti e annunci, fornire funzionalità per social media e analizzare i collegamenti. Chiudendo questo banner o continuando la navigazione acconsenti al loro uso.
Leggi la Cookie Policy di DiGrande.it

Criteri e strumenti per migliorare l'accessibilità dei siti web - Capitolo 19

Aggiornato il 21/05/2024 08:00 
 

Circolare AIPA n. 32 (06/09/2001)

Come si è detto al capitolo 13 il Lavoro di preparazione della circolare aveva prodotto vari documenti e si era prima pensato, secondo la bozza che era stata esposta sul sito, di produrre come allegati i vari documenti.

Siccome le discussioni si trascinavano, chiesi, come raccontato, che l'AIPA avocasse a sé i vari documenti e ne facesse una Sintesi da inserire nella stessa circolare, evitando gli allegati: già le leggi non si rispettano, le circolari meno, gli allegati magari non si guardano.

Gli uffici dell'AIPA, sulla scorta di quanto deciso e del materiale prodotto, preparano un testo che contiene una introduzione di Carattere generale, poi articolato in 3 punti che sintetizzano altrettanti documenti:

1. Disabilità e tecnologie assistive: Principi generali. Viene in pratica ripresa la definizione proposta dal Graziani a partire dalla sua impostazione derivante dalla definizione di "accessibilità strumentale", "misurabile", perciò oggettivabile, dei concetti,oltre che di "disabilità", anche le definizioni di "accessibilità" e di "Tecnologia assistiva", più o meno riprese dalla successiva Legge Stanca del 2003.

2. Linee Guida e criteri per l'accessibilità dei siti Web. Recepisce in Sintesi la parte Speciale del cosiddetto Documento Graziani, con qualche emendamento scaturito dal dibattito, come raccontato.

3. Linee Guida e criteri per l'accessibilità delle applicazioni Software. Recepisce in toto il Documento predisposto da Flavio Fogarolo.

Il Documento Le moli viene lasciato fuori e con esso anche il problema degli anziani, e per quanto riguarda le disabilità cognitive ci si contenta di qualche accenno.

Il Documento Le Moli, pubblicato nel prossimo capitolo, viene destinato a una successiva pubblicazione a cura di AIPA e confluirà poi nel Libro "i disabili nella società dell'Informazione".

Come si Legge dal testo sottostante l'AIPA si riserva di Aggiornare il tutto dopo un anno, il che significa alla fine del 2002. Ciò non è stato fatto finora, (inizi del 2004) e dunque tale circolare andrebbe, ora che c'è la Legge, attualizzata e inserita nei regolamenti attuativi.

Proprio per sottolineare l'attualità e la necessità di un dibattito sui temi oggetto di quella circolare e sui punti che vanno attualizzati, riporto in coda un breve intervento di Giuseppe di Grande dell'agosto 2003, sull'usabilità del Software.

Si assiste ad uno sforzo collettivo di sistematizzazione che produce notevoli masse documentali ma qui si preferisce riportare un flash piuttosto puntuale: l'intenzione è di ricordare al Ministro e chi per lui la necessità di normare su questi aspetti.

Segnalo infine un'altra analogia con la Legge Stanca: parliamo per ora di disabili, rinviando al futuro il problema anziani.

È questo che ha sostenuto il Ministro Stanca presentando il suo Libro bianco.

Segue il testo della circolare.

---

CIRCOLARE 6 settembre 2001, n. AIPA/CR/32

Criteri e strumenti per migliorare l'accessibilità dei siti Web e delle applicazioni informatiche a persone disabili.

A tutte le Amministrazioni pubbliche

A seguito delle linee Guida dettate nella materia dal Dipartimento della funzione pubblica, con circolare n. 3/2001 del 13 marzo 2001 (pubblicata nella Gazzetta Ufficiale 19 marzo 2001, Serie generale, n. 65) vengono indicati criteri e strumenti per favorire l'accesso ai siti Web delle pubbliche amministrazioni e l'uso delle applicazioni informatiche da parte delle persone disabili. In particolare, vengono specificati i criteri da rispettare nella progettazione e manutenzione dei sistemi informatici pubblici, per favorire l'accessibilità ai siti Web che mettono a disposizione di cittadini e imprese informazioni e servizi interattivi mediante tecnologie e protocolli Internet e alle applicazioni informatiche utilizzate dal personale della pubblica amministrazione e da cittadini e imprese per i servizi resi così fruibili. Le amministrazioni che intendessero aderire integralmente agli orientamenti espressi dal WAI "Web content accessibility guidelines 1.0" del consorzio W3C, potranno raggiungere un miglior livello di accessibilità dei propri siti. Per quanto riguarda la progettazione o la riconversione di sistemi applicativi rivolti ad un insieme limitato di utilizzatori, le amministrazioni sono invitate in via preliminare a valutare il livello di effettiva e possibile utilizzazione delle applicazioni da parte di soggetti disabili.

1. Disabilità e tecnologie assistive: principi generali di intervento per favorire l'accessibilità.

Per disabilità si intende qualsiasi restrizione o impedimento nel normale svolgimento di un'attività derivante da una menomazione. In questo contesto vengono considerati soltanto gli aspetti di interazione con i sistemi informatici; il termine “Accessibilità” va inteso quindi come la proprietà dei sistemi informatici di essere fruibili senza discriminazioni derivanti da disabilità. Le disabilità possono essere:

a) fisiche, che comprendono le disabilità motorie, relative al controllo dei movimenti degli arti, e sensoriali, che riguardano limitazioni della Vista e dell'Udito;

b) cognitive, che possono eventualmente associarsi a menomazioni motorie o sensoriali. Le limitazioni delle funzioni intellettive possono assumere caratteristiche diverse (disturbi della parola, del Linguaggio, della coordinazione del pensiero ecc.), tali da ridurre i livelli di comunicazione, attenzione e risposta agli stimoli esterni. Le soluzioni tecniche, Hardware e Software, che permettono di superare o ridurre le condizioni di svantaggio dovute ad una specifica disabilità, vengono di seguito denominate “tecnologie assistive” o “ausili”. Il grado più elevato di accessibilità si consegue attuando il principio della “progettazione universale”, secondo il quale ogni attività di progettazione deve tenere conto della varietà di esigenze di tutti i potenziali utilizzatori. Questo principio, applicato ai sistemi informatici, si traduce nella progettazione di sistemi, prodotti e servizi fruibili da ogni utente, direttamente o in combinazione con tecnologie assistive.

L'applicazione del principio di progettazione universale può presentare dei limiti e, in alcuni casi, porre vincoli alla creatività. Nel caso dei siti Web, i vincoli riguardano le modalità di attuazione delle varie soluzioni tecniche, piuttosto che il contenuto e l'estetica dei documenti, per cui non si traducono in limitazioni della possibilità espressiva. Nel caso di sistemi informatici dedicati a specifiche finalità applicative, vi sono situazioni nelle quali non è possibile una completa e generale applicazione del principio, in quanto le soluzioni tecniche disponibili, allo stato, non permettono di rendere tutte le possibili funzioni accessibili a qualunque utente, indipendentemente dalle sue capacità fisiche e sensoriali. Le possibilità attuali coprono, tuttavia, una casistica molto vasta e suscettibile di ulteriore continuo ampliamento grazie all'evoluzione tecnologica. La rispondenza ai requisiti di accessibilità deve essere interpretata in maniera non limitativa: gli autori non devono essere scoraggiati ad usare elementi multimediali, ma, al contrario, invitati a sfruttarli per assicurare l'accesso alle informazioni a una sempre più vasta platea di utenti.

Per quanto concerne i siti Web e, più in generale, i programmi di accesso a sorgenti separate di Informazione, il requisito di accessibilità sarà tanto più facilmente soddisfatto quanto più la progettazione si sia basata sulla separazione dei contenuti dalle modalità di presentazione.

La separazione è resa oggi più agevole dal diffondersi di linguaggi di marcatura e dall'utilizzo di style-sheet.

In generale, l'elemento architetturale di un sistema informatico che viene maggiormente interessato dal problema dell'accessibilità è l'interfaccia utente; pertanto, nella progettazione o nell'adattamento di interfacce esistenti, è fondamentale un'adeguata conoscenza delle opportunità offerte dalla tecnologie assistive per sfruttarle nel modo migliore, tenendo conto delle finalità applicative. Per favorire il rispetto dei principi illustrati, vengono fornite nel seguito definizioni di accessibilità riferite a specifiche configurazioni di postazione di Lavoro e tecnologie assistive, sulle quali effettuare i test appropriati.

2. Linee Guida e criteri per l'accessibilità dei siti Web

Un "sito Web Accessibile" è un sito Internet il cui contenuto informativo multimediale e le cui 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. Per rendere Accessibile un sito Web ci si deve attenere alle seguenti indicazioni:

a) struttura del sito.

Nel progettare il sito occorre prevedere una struttura comprensibile, applicando quei criteri di usabilità che prescrivono di evitare l'affollamento di link e strutture di Pagina e di navigazione complesse;

- Il sito deve essere dotato di una mappa di navigazione interattiva per migliorare la comprensione della struttura e di un Motore di Ricerca con controllo ortografico incorporato;

- È consigliabile mantenere una struttura omogenea delle pagine;

b) Accessibilità.

È sconsigliabile il ricorso a versioni parallele (Grafica, solo testo, grandi caratteri, ecc.), per le conseguenti maggiori difficoltà di aggiornamento, a meno che non sia questo l'unico modo per garantire un miglioramento effettivo del grado di accessibilità. In questo caso, deve essere assicurato l'allineamento del contenuto delle pagine del sito Accessibile e con quelle del sito principale. Nel caso di intervento di recupero di accessibilità su un sito esistente, si raccomanda di utilizzare la soluzione di restauro delle pagine, rispettando le regole di accessibilità.

Nella realizzazione dei documenti, si devono ricercare soluzioni che permettano la compresenza di componenti orientate a diverse necessità degli utenti. Ad esempio, per i browser che non trattano queste componenti occorre utilizzare le opzioni noframes e noscripts, che forniscono procedure alternative; un'altra soluzione consiste negli "equivalenti testuali" che consentono di fornire le stesse informazioni a coloro che non possono fruire di una o più componenti multimediali. Gli equivalenti testuali vanno applicati a 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. Gli equivalenti testuali potranno essere semplici etichette associate all'elemento o vere e proprie descrizioni dettagliate inserite in una Pagina separata e collegata all'elemento grafico mediante un link, in funzione del contenuto informativo dell'elemento grafico stesso: per una Immagine, una vera descrizione è necessaria soltanto se significativa per la comprensione del Documento nel quale è inserita; negli altri casi è sufficiente un'etichetta testuale che ne indichi la funzione.

Si sconsiglia l'uso di figure di sfondo ad una Pagina e di testi realizzati in forma di Immagine: una figura di sfondo disturba la percezione del testo sovrapposto da parte dei disabili cognitivi e degli ipovedenti e un'Immagine di testo non possiede flessibilità sufficiente per adattarsi alle esigenze degli utenti ipovedenti;

c) Formati e fruibilità delle informazioni.

È utile predisporre una versione compressa dei documenti di grandi dimensioni da scaricare, la quale comprenda i file collegati indispensabili alla navigazione fuori linea, usando link di tipo relativo. I nomi dei file e delle directory devono essere compatibili con tutti i programmi di navigazione. I formati dovrebbero essere accessibili e non proprietari: HTML, RTF, testo. Se fossero necessari altri formati, come PDF, GIF, JPG, sarebbe necessario accompagnarli con una versione Accessibile.

Si raccomanda l'uso di fogli di Stile, in applicazione del principio di separazione fra contenuto e visualizzazione delle pagine. La flessibilità e intercambiabilità dei fogli di Stile consentono di personalizzare la presentazione dei documenti secondo le esigenze dell'utente, attraverso la scelta dei font, le loro dimensioni e il più adatto contrasto cromatico. In generale, è consigliabile che la rappresentazione Grafica, per i testi e per le immagini, sia semplice: vanno evitati caratteri troppo piccoli, righe compresse, font bizzarri, colori sfumati o con tenui contrasti con lo sfondo.

Si sconsiglia l'uso di tabelle ai fini dell'organizzazione della struttura delle pagine, almeno quando il contenuto perda senso se la Tabella venga linearizzata.

Riguardo all'uso delle tabelle per la presentazione e la tabulazione dei dati, occorre comporre i documenti con i marcatori necessari per l'individuazione della Cella all'interno della griglia.

In particolare, è utile inserire le intestazioni di riga e di colonna, affinché i dispositivi alternativi di visualizzazione possano procedere ad una corretta individuazione della Cella. Risulta anche utile una descrizione dell'organizzazione dei dati, fornita ad esempio come didascalia della Tabella.

Quando si debbano creare tabelle complesse (ad esempio con struttura nidificata), è consigliabile fornire una Pagina alternativa con una versione linearizzata delle tabelle stesse.

La procedura di verifica di accessibilità deve simulare le condizioni di utilizzo da parte dell'utente Disabile. 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, con una configurazione dotata di uno o più dei seguenti Software e ausili:

1) browser grafico, anche se privo di visualizzatori speciali, con capacità di gestione di fogli di Stile o di componenti multimediali disabilitate (immagini, animazioni, suoni, Colore): MS Internet Explorer, Netscape Navigator, Opera, Amaya;

2) 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;

4) Come al punto 1), in combinazione con uno screen reader per ciechi operante sotto Windows 95 o superiore;

5) Come al punto 1), in combinazione con un ingranditore di Schermo per ipovedenti;

6) Come al punto 1), in combinazione con un Ausilio per disabili motori, con Tastiera e/o Mouse alternativi;

7) Come al punto 1), in combinazione con un sistema di input Vocale a controllo completo dell'interfaccia utente.

Gli ausili si intendono in “versione italiana recente”, cioè disponibile in Italia da gennaio 2000 o successivamente.I browser ai punti 1) e 2), essendo svincolati dalla Tecnologia assistiva, rispondono all'esigenza di una verifica di prima approssimazione, effettuabile direttamente dallo sviluppatore, e coprono le necessità di quegli utenti che, pur non essendo affetti da minorazioni motorie o sensoriali, si trovano in condizione di non poter fruire pienamente di tutte le componenti multimediali di un sito, a causa di condizioni ambientali o di limitazioni tecnologiche. Le verifiche di accessibilità con le configurazioni indicate al punto 1) potranno simulare varie condizioni di disabilità, attraverso la disattivazione selettiva di una o dell'altra funzione multimediale (ad esempio: immagini e Grafica per simulare la cecità, suoni per la sordità, colori per i difetti di percezione cromatica). La verifica, allorché siano adottate le diverse forme di Tecnologia assistiva nei punti da 3) a 7), consente di riprodurre meglio le condizioni operative di utenti disabili. È raccomandata la compatibilità con tutti i modelli o versioni delle tipologie di Ausilio elencate; tuttavia il livello minimo di accessibilità si potrà considerare raggiunto anche se assicurato soltanto con gli ausili più avanzati.

3. Linee Guida e criteri per l'accessibilità delle applicazioni Software

Le barriere presenti nelle applicazioni Software costituiscono uno degli ostacoli all'integrazione del personale Disabile nelle attività degli uffici ed una fonte di discriminazione per i cittadini disabili che vengono esclusi o limitati nella fruizione dei servizi disponibili per via telematica. Una tipologia particolarmente importante è quella delle applicazioni didattiche multimediali, per le conseguenze che ha sull'integrazione dei ragazzi disabili nella Scuola.

Per le applicazioni multimediali che adottino le medesime modalità di presentazione del Web, le problematiche di accessibilità si riconducono a quelle esposte in precedenza. Ai fini dell'accessibilità, i criteri fondamentali ai quali le amministrazioni sono invitate ad attenersi nello sviluppo di applicazioni informatiche sono i seguenti:

a) accessibilità dalla Tastiera

- 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;

- 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;

- 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;

- L'applicazione non deve interferire con le funzioni di accessibilità eventualmente disponibili nel sistema operativo;

- I comandi che prevedono una risposta a tempo devono essere evitati, oppure deve essere prevista la possibilità, per l'utilizzatore, di regolare il tempo di risposta.

b) Icone

- Tutte le icone devono avere una chiara etichetta testuale o un'alternativa testuale selezionabile dall'utilizzatore;

- 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

- 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;

- L'applicazione deve rendere disponibili sufficienti informazioni sugli oggetti usati dall'interfaccia utente, affinché la Tecnologia assistiva possa identificarli e interpretarne la funzione.

d) multimedia

- L'applicazione deve prevedere opzioni alternative di segnalazione visiva di avvertimento e rinforzo delle segnalazioni sonore di allarme del programma;

- 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;

- 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).

e) presentazione a video

- 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;

- L'applicazione deve permettere all'utilizzatore di scegliere i colori e regolare il loro contrasto, sia nell'interfaccia utente sia nelle aree di Lavoro e presentazione dei dati;

- 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;

- L'applicazione 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;

- L'applicazione 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;

- L'applicazione deve permettere all'utente di selezionare la definizione di Schermo preferita;

- L'applicazione deve rispettare le scelte dell'utente relative ai puntatori di sistema del Mouse;

- Per gli 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

- 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 reader per i ciechi.

g) Documentazione

- Tutta la documentazione deve essere fornita anche in Formato Elettronico Accessibile e deve includere anche descrizioni testuali di figure e grafici;

- Qualunque uscita prodotta dall'applicazione deve essere disponibile in Formato Accessibile. La procedura di verifica di accessibilità deve simulare le condizioni di utilizzo da parte dell'utente Disabile.

Si considera Accessibile

un'applicazione Informatica dotata di un'interfaccia utente che, con l'eventuale Ausilio di Tecnologia assistiva, non presenti difficoltà di: Lettura del contenuto di tutte le finestre visualizzabili sullo Schermo, controllo dell'inserimento di dati e dell'interazione con elementi o oggetti dell'interfaccia (menu orizzontali o a tendina, bottoni, campi di editing, check box, radio box, ecc.), quando tali operazioni siano eseguite da una persona sufficientemente addestrata nell'uso di una postazione di Lavoro, con una configurazione dotata, a seconda dei casi, di strumenti di Tecnologia assistiva quali:

- Screen reader per ciechi, con Sintesi Vocale o display Braille;

- Funzioni di Ausilio per ipovedenti e disabili motori fornite dal sistema;

- Applicativo specifico di ingrandimento di Schermo;

- Sistema di input Vocale, con dettatura di testo e emulazione di comandi di Tastiera e/o Mouse;

- Ausilio per disabili motori, con Tastiera e/o Mouse alternativi.

Gli ausili si intendono in “versione italiana recente”, cioè disponibile in Italia da gennaio 2000 o successivamente. Le caratteristiche di accessibilità devono essere possedute dal Software applicativo, indipendentemente dalla piattaforma Hardware e Software di destinazione, purché sia disponibile la specifica Tecnologia assistiva. Nel caso di applicativi per sistemi multi-utente le condizioni di accessibilità si possono applicare all'emulatore di terminale, il quale può funzionare sotto altro sistema operativo, permettendo di scegliere la soluzione più favorevole.

Sul sito dell'AIPA, all'indirizzo www.aipa.it è pubblicata una selezione di riferimenti sul tema dell'accessibilità. L'AIPA, anche in collaborazione con altre amministrazioni, sta progettando la realizzazione di un sito specificatamente dedicato alla accessibilità. Nel frattempo, chiunque volesse inviare osservazioni, contributi, richieste, può inviare un messaggio di posta Elettronica all'indirizzo accesso@aipa.it.

Si confida che le Amministrazioni vogliano adottare le iniziative necessarie per migliorare la accessibilità dei siti Web e delle applicazioni Software ad operatori ed utenti disabili. Entro un anno si procederà ad Aggiornare la presente circolare, sulla base dell'esperienza maturata nel frattempo e degli avanzamenti tecnologici. Si rimane a disposizione per ogni necessario ragguaglio.

Roma, 6 settembre 2001

Il Presidente: ZULIANI

-------------------------------------------------------

Accessibilità / Usabilità (post su nv-Programmare di Giuseppe Di Grande)

Subject: Fw: Accessibilità/Usabilità

Salve, giro un messaggio scritto ad una persona privatamente che in qualche modo potrebbe essere utile.

----- Original Message -----

.........................................

Ciao Michele,

grazie innanzitutto per l'interesse che nutri sull'argomento.

È una questione più di accessibilità che di usabilità. L'usabilità è fattore soggettivo di ogni programmatore e poi utilizzatore, l'accessibilità dovrebbe essere un fattore oggettivo che dovrebbero seguire un po' tutti.

Tu, programmatore, puoi fare un Software completamente Accessibile: nessun problema per uno screen reader, piena usabilità da Tastiera, possibilità di ingrandimento caratteri, grafici in bliss, ecc.. Ad esempio, metti su una form 30 pulsanti perfettamente accessibili. Dal punto di Vista dell'accesso non fa una grinza. Il fattore usabilità del Software però sarà disturbo per chi usa il Software senza l'Ausilio quasi immediato del click del Mouse.

Tramite Tastiera l'utente o preme 20 volte il tasto tab per raggiungere il pulsante voluto o impara una sequenza di 30 tasti caldi da usare. Si traduce, in campo lavorativo, in lentezza di utilizzo.

L'usabilità è un fattore molto più complesso dell'accessibilità... credo che con l'esperienza si acquisisca padronanza della materia. Ti devi regolare in base ai suggerimenti di chi usa il tuo programma. Il primo utilizzatore devi essere tu stesso... più semplici sono le azioni da compiere, con qualsiasi mezzo di accesso, migliore sarà il tuo programma. Qualcuno scrisse che le cose semplici non sono sempre facili da sviluppare.

Posso solo un po' parlarti di accessibilità legata allo sviluppo con Delphi.

Ti incollo un messaggio che scrissi al professore che mandò una richiesta sul News Group.

Prima di tutto ti consiglio di Installare sul tuo Computer uno screen reader e uno screen magnifier.

Io sono un cieco... ti indico lo screen reader che va ora per la maggiore in tutti i Computer del mondo.

www.freedomscientific.com

www.hj.com

www.subvisionmilano.com

Questo poi è un sito che parla di tecniche legate al Web e propone linee Guida ufficialmente riconosciute in tutto il mondo: le WAI.

www.w3.org

Credo si possano trovare anche guide per lo sviluppo di Software.

Ti incollo il messaggio e mi rendo disponibile ad analizzare le eventuali form, i file .dfm, della futura applicazione che hai intenzione di fare.

Così, per orientarti un pochino e rendere il Software il più Accessibile possibile. Ricorda l'ultima cosa: tutti gli oggetti, Software o Hardware che siano, possono essere accessibili e usabili da qualsiasi persona, mantenendo le loro proprietà di base, non compromettendo nessun loro valore estetico, solo se ben progettate sin dall'inizio. Lo screen reader che io ora sto usando per scriverti è solo una toppa alle mancanze del sistema operativo.

Ciao

Giuseppe

---

Le raccomandazioni iniziali per lo scheletro di un qualsiasi applicativo possono essere sommariamente queste:

1. Usare controlli il più possibile conformi agli standards offerti da Windows (Static, Combo, List, Button, ecc.)

2. Ordinare i controlli dentro la form correttamente. (Non è corretto dare un TabOrder di 10 a uno Static che descrive un Combo 1. OPpure disattivare i TabStop di quei controlli vitali per il funzionamento di una Form). Non è corretto posizionare uno static a destra, o in basso, del controllo che deve descrivere.

È preferibile usare controlli dotati di finestra, piuttosto che usare controlli che usano direttamente il device contest, come ad esempio un TLabel. O funzioni che scrivono testo direttamente sul canvas a loro dedicato.

3. Usare il meno possibile colori stravaganti che danno poco contrasto al testo. È corretto lasciare i colori standard di Windows sì da permettere all'utente di scegliere quello che più si adatta alle sue esigenze.

4. Esclusivamente grafici, ad esempio in un Button, non sono consigliabili. Al massimo usare dei controlli che permettano l'inserimento di una caption anche se poi non viene visualizzata. Ad esempio un Button esclusivamente grafico può avere una caption invisibile che i lettori di Schermo leggeranno comunque. Comunque una scritta è sempre consigliabile ad un grafico. Ovviamente logo, icone, ecc., che abbiano solo una funzione estetica possono essere tranquillamente usati (non sono vitali per l'utilizzo del Software).

5. È bene dotare quei controlli che lo permettono di tasto caldo per una loro selezione veloce. Il Software deve assolutamente essere gestibile anche senza il Mouse.

Le chiedo di poter analizzare le form del suo Software così da rendermi conto direttamente di eventuali punti di difficoltà. Mi basterebbe vedere esclusivamente i ".dfm" in Formato testo, dato che usa delphi 3, del suo applicativo.