ti trovi in: Home Page - Webmaster -

Progetto EPICA

Autorità per l'informatica nella Pubblica Amministrazione

GRUPPO DI LAVORO "ACCESSIBILITÀ E TECNOLOGIE INFORMATICHE NELLA P.A."

Proposta per l'Estensione del Protocollo Informatizzato ai Centralinisti mediante l'adozione di tecniche di Accessibilità

ANALISI DEL CONTESTO E PRIME INDICAZIONI

Mario Di Domenicantonio
Stefano Ercoli
Marco Lusini

Roma, aprile 2002

Premessa

All'interno del gruppo di lavoro è stato costituito un sottogruppo misto PCdM-AIPA per l'analisi e l'indicazione di linee operative per l'accessibilità dei sistemi di protocollo informatico.

Il presente documento, che ne costituisce una prima versione, verrà pubblicato a breve sul sito PubbliAccesso per raccogliere eventuali osservazioni e suggerimenti.

Introduzione

La possibilità di applicare il personale con disabilità fisiche in generale, e il personale non vedente in particolare, ai sistemi di protocollo informatico è legata alla realizzazione di interfacce operatore - sistema che rispondano a requisiti di accessibilità.

Questa affermazione valida in senso generale, nasconde tutta una serie di problemi legati alle caratteristiche del sistema e alla natura del processo sottostante che intende automatizzare, risultando così generica nella sua possibilità di applicazione concreta.

Quando si parla di accessibilità, infatti, il pensiero corre subito alle linee guida WAI del W3C e, nel contesto nazionale, alle linee guida per l'organizzazione, l'usabilità e l'accessibilità dei siti Web delle pubbliche amministrazioni dettate 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) e alla successiva circolare AIPA del 6 settembre 2001, n. 32 (pubblicata nella Gazzetta Ufficiale 14 settembre 2001, Serie generale, n. 214), in cui 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.

Nella circolare AIPA si richiama come, in generale, 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.

D'altra parte, nella stessa circolare, si nota che, 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.

Tuttavia si sottolinea anche che le possibilità attuali coprono una casistica molto vasta e suscettibile di ulteriore continuo ampliamento grazie all'evoluzione tecnologica.

1. Il protocollo informatico

Il caso del sistema di protocollo informatico ben si presta ad evidenziare tali aspetti problematici. La natura del problema richiede di porre attenzione oltre che alle componenti tecnologiche (hardware e software), ad altrettanto importanti aspetti di natura organizzativa e procedurale.

Infatti il processo sottostante, che il sistema è chiamato ad automatizzare, legato all'attività di protocollazione, archiviazione e gestione del flusso dei documenti, costituisce l'asse portante dei procedimenti amministrativi svolti all'interno della Pubblica Amministrazione.

Secondo questa visione il protocollo "classico" (sistema di certificazione e registrazione della corrispondenza) è strettamente connesso con i sistemi di gestione dei procedimenti e dei flussi documentali (workflow), di gestione documentale e archiviazione, di posta elettronica e supporto al lavoro di gruppo ed in genere con tutte le soluzioni tese al superamento del tradizionale scambio di informazioni cartacee (cfr. Gedoc e Gedoc2, documenti di indirizzo sulla gestione dei flussi documentali consultabili sul sito www.aipa.it).

Per questo l'introduzione di un sistema di protocollo informatico porta con sè importanti impatti di natura organizzativa e procedurale oltre ai tradizionali aspetti tecnologici.

Ciascuno di questi aspetti e componenti del sistema dovrebbe rispondere ai requisiti di accessibilità per far sì che l'intero sistema risulti accessibile.

È certamente possibile, analizzando le singole componenti di un sistema di protocollo informatico, dare indicazioni sui criteri da adottare per renderle tutte accessibili, ma con gravosi oneri in termini di tempi di analisi e realizzazione.

Inoltre la diversa natura e tipologia delle informazioni (di tipo strutturato e non) trattate dal sistema e veicolate su "media" diversi: documenti cartacei, fax, e-mail, documenti elettronici richiede la necessità di definire in termini di accessibilità la trattazione di tutte queste tipologie di informazioni e di documenti.

Tali considerazioni sottolineano la difficoltà di un approccio complessivo al problema e suggeriscono l'elaborazione di strategie alternative, tese ad una riduzione della complessità del problema.

Lo studio del documento "L'interoperabilità dei sistemi di protocollo informatico in ambiente distribuito" - AIPA - Gruppo di Lavoro sul Protocollo Informatico Novembre 2000, suggerisce un approccio che pone l'enfasi sul documento elettronico, nell'ipotesi di un sistema che, integrando il protocollo informatico con la posta elettronica e la firma digitale, rende possibile la realizzazione effettiva di una gestione completamente automatizzata dei flussi documentali.

Inoltre una ulteriore assunzione è quella di delimitare l'attenzione ai compiti svolti all'interno del sistema dal ruolo di "addetto al protocollo" che è la figura che ha la responsabilità delle attività di registrazione dei documenti in entrata ed uscita e della gestione delle eccezioni oltre a semplici attività di gestione del sistema.

Nel documento, cui si rimanda per maggiori approfondimenti, sono descritti tutti i passi procedurali necessari alla gestione di un documento elettronico dal sistema mittente a quello destinatario, precisando le azioni ed i compiti che l'operatore ed il sistema devono rispettivamente compiere.

Dal documento si deduce come l'interazione operatore-sistema possa avvenire tramite una "opportuna interfaccia grafica" che contenga le funzioni/azioni che di volta in volta debbono/possono essere attivate per la gestione del documento informatico.

Questo assunto offre la possibilità ed indica il percorso per definire requisiti di accessibilità che possono consentire una prima risposta al problema.

Le ipotesi di lavoro sono:

• il documento da trattare è un documento informatico nella sua totalità. Esso è stato inserito nel sistema con modalità che non sono oggetto di queste note;
• le attività dell'operatore avvengono attraverso una interfaccia grafica.

2. I requisiti per l'accessibilità

Con queste ipotesi di lavoro si possono definire i requisiti minimi di accessibilità cui il sistema deve rispondere.

I programmi che realizzano l'interfaccia tra il sistema e gli operatori devono avere le seguenti caratteristiche:

1. Non devono modificare né disabilitare le caratteristiche hardware e software del posto di lavoro sul quale vengono installati.
   È auspicabile che l'applicazione di un disabile al sistema protocollo avvenga attraverso stazioni di lavoro dotate di tecnologie assistive adeguate. Queste tecnologie, che si realizzano spesso attraverso opportune combinazioni hardware e software, devono rimanere utilizzabili e perciò il software di interaccia non deve disabilitarle, modificarle o eluderle.
2. Tutte le funzioni che prevedono l'intervento umano devono essere attivabili anche dalla tastiera della stazione di lavoro.
   Non devono, cioè, essere realizzate funzioni che siano attivabili solo mediante mouse (o più in generale, esclusivamente mediante un qualsiasi sistema di puntamento).
3. È auspicabile che l'interfaccia sia realizzata anche in modalità carattere (e non solo grafica).
4. L'interfaccia grafica deve essere realizzata nel rispetto almeno dei seguenti punti (il riferimento è alle WCAG 1.0 e relativi checkpoint):

a. Fornire un equivalente testuale per tutti gli elementi non-testuali presenti (immagini, simboli grafici, ecc.). Guideline n. 1;

b. Qualora vengano veicolati tramite il colore informazioni e/o avvisi all'operatore gli stessi devono essere veicolati anche con modalità non legate al colore (ad esempio testuali). Guideline n. 2;

c. Tutte le tabelle utilizzate per scopi diversi dalla formattazione devono contenere il titolo e l'intestazione di righe e colonne, onde individuare con chiarezza il contenuto delle celle. Guideline n. 5;

d. Il meccanismo di passaggio da una schermata all'altra (navigazione) deve essere realizzato in maniera chiara e con opportuni segnali (anche sonori) di avvertimento. Guideline n. 12 e 13;

e. Oltre ai criteri precedenti, vanno rispettati i seguenti punti:

1. Se si utilizzano linguaggi di scripting per veicolare informazione (di qualunque tipo) allora la stessa informazione deve essere resa disponibile in modalità testo e leggibile da uno screen reader;
2. Non si devono utilizzare plugin o applet per realizzare funzioni o per veicolare informazione;
3. Se sono presenti file PDF, allora l'applicazione protocollo deve attivare (previo avviso sonoro) il Reader della Acrobat nella sua versione accessibile (in altri termini: deve essere cura del fornitore procurare tale versione);
4. Particolare cura deve essere posta nella realizzazione delle form di immissione dei dati: deve essere chiaramente dichiarata l'obbligatorietà o meno della compilazione di un campo, le etichette dei campi devono essere in modalità testo, eventuali elenchi di scelta devono essere raggruppati secondo un ben definito criterio (alfabetico, gerarchico, ecc.) che si ripete tutte le volte. Deve essere possibile "navigare" tra i gruppi (saltando cioè dall'uno all'altro, senza doverli scorrere nella loro interezza) mediante il solo uso della tastiera, il focus sui campi (cioè il passaggio da un campo all'altro) deve essere segnalato mediante avvisi acustici, ecc.
5. Tutti i messaggi del sistema verso l'operatore (errori, avvertenze, ecc.) devono avere versione testuale ed acustica, deve cioè essere emesso un segnale acustico di avvertimento seguito da una descrizione testuale del messaggio.

Come si può osservare, i requisiti cui l'interfaccia operatore-sistema deve ottemperare per rispondere ai criteri di accessibilità sono un misto di checkpoint delle WCAG 1.0 e di criteri di accessibilità del software.

Occorre notare che qualora l'interfaccia fosse realizzata totalmente in modalità Web si avrebbero tutti i vantaggi di poter applicare ad essa per intero i criteri previsti dalle linee guida che sono notoriamente consolidati e che pertanto faciliterebbero le cose.

Più in generale, si ritiene comunque che una interfaccia realizzata nel rispetto delle WCAG e dei criteri di accessibilità applicati a software diverso dalle pagine Web dovrebbe essere in grado di garantire ad un operatore disabile di interagire con un sistema di protocollo informatico.