Indice 7
molti.
Il problema della web accessibility diventa ancora più grave quando si pensa
agli utenti disabili, che a causa dei loro handicap riescono a navigare nella
rete in modo ancora più difficile dell’utente normodotato. Il motivo di ciò
è dovuto al fatto che mentre l’utente normodotato può riuscire prima o poi
a reperire le informazioni cercate, sebbene impieghi tempi lunghi o pur sop-
portando complicazioni di altro tipo, l’utente disabile se non ha un supporto
software o hardware in aiuto non può forse navigare affatto. Sicuramente
il supporto di cui i disabili possono usufruire per poter accedere alla rete è
costituito dalle Tecnologie Assistive, cioè i programmi in aiuto ai vari proble-
mi di disabilità esistenti, ma il supporto più importante, e basilare, che deve
essere loro fornito è senz’altro costituito dall’aver progettato i siti web seguen-
do tutte le regole standard di riferimento per garantirne l’accessibilità.
E’ proprio alla luce di questi problemi di navigazione, infatti, che sono stati
forniti principi guida di riferimento per la progettazione web che costituisco-
no gli standard attualmente disponibili, come le Web Content Accessibility
Guidelines 1.0 e i principi del WAI, suggeriti dal W3C, il consorzio del World
Wide Web, che fornisce nel suo sito ufficiale anche i validatori automatici,
utili per testare on line le pagine web di un sito per capire se esso è conforme
o meno ai principi guida.
Le linee guida accennate sono senza dubbio da intendersi come un punto
di riferimento non indifferente per il progettista software in generale, ma il
raggiungimento dell’accessibilità non si deve limitare al solo superamento di
test tramite l’uso di validatori automatici.
Purtroppo alcuni siti riescono ad ottenere il bollino per esempio del validatore
Bobby 1 e se ne fregiano pubblicamente come a dichiarare di aver raggiunto
un pieno livello di accessibilità pur non avendo, per esempio, inserito delle
etichette testuali relative alle immagini, come suggeriscono fortemente gli
standards del W3C, o pur non avendo rispettato le regole di utilizzo del col-
ore, rendendo così il proprio sito in parte inaccessibile rispettivamente agli
1Oltre a quelli del W3C i validatori automatici più spesso consigliati sono Bob-
by e Torquemada, reperibili rispettivamente agli indirizzi http://bobby.watchfire.com e
http://webxtutti.it/testa.htm.
Ci sono anche molti altri validatori automatici, ma verrano detagliatamente introdotti più
avanti.
Indice 8
utenti con problemi di cecità, a quelli affetti da ipovisione e agli utenti affetti
da daltonismo.
In ognuno di questi casi l’esposizione dei bollini sull’accessibilità si rivela
come una pretesa accessibilità da parte del progettista che non sarebbe del
tutto giusto consentirgli.
Per ottenere un sito web che garantisca l’accessibilità anche agli utenti dis-
abili, oltre che ai normodotati, si può testare la compatibilità del software
prodotto con alcuni programmi facenti parte delle Tecnologie Assistive, e in
caso di superamento del test potremo almeno affermare di aver raggiunto un
piccolo punto di partenza per garantire l’accessibilità del nostro sito web.
L’aspetto della compatibilità delle Tecnologie Assistive con le applicazioni
web è un’altra piaga derivante dal problema dell’accessibilità, infatti ogni
utente disabile prima di acquistare una qualsiasi soluzione software o hard-
ware facente parte delle Tecnologia Assistive deve accertarsi della sua com-
patibilità con il software residente nella propria macchina, pena l’impossibil-
ità di utilizzarla.
Questo aspetto è stato tenuto in considerazione per il progetto svolto nel
periodo di stage, in cui, infatti, è stata testata la compatibilità del sito web
progettato per il Comune di Bibbiena con due programmi che fanno parte
delle Tecnologie Assistive, Zoomtext e Jaws, rivelando come risultato una
compatibilità soddisfacente. Inoltre nel corso di tutto il progetto sono state
seguite come punto di riferimento standard le linee guida del W3C e del
WAI che suggeriscono in modo minuzioso una serie di accorgimenti tecnici
di fondamentale importanza da seguire per ottenere un sito web accessibile
a qualsiasi tipo di utente, l’esperto, l’inesperto, il normale medio utente del
web e il disabile. Un altro obbiettivo importante è stato quello di progettare
il nuovo sito web in modo che fosse dal punto di vista software ugualmente
funzionante indipendentemente dal tipo di Browser che l’utente utilizza per
la navigazione.
La considerazione verso i problemi dei disabili è cresciuta sempre di più nel
corso del tempo, fino ad esigere delle leggi a tutti gli effetti per garantire l’in-
serimento societario di queste persone per loro natura già tanto svantaggiate.
Dall’inserimento nella società il problema si è esteso anche all’inserimento nel
settore tecnologico, ad un punto tale che oggi i disabili hanno a disposizione
Indice 9
finalmente una legge (Legge Stanca) che impone alle Pubbliche Amminis-
trazioni di rendere i propri siti web accessibili ai disabili.
E’ vero che l’obbligo di adempiere alla legge Stanca è rivolto alle Pubbliche
Amministrazioni, mentre per quelle private è facoltativo, però dobbiamo es-
sere soddisfatti del fatto che finalmente esiste per i disabili una garanzia di
rispetto legalmente valida, in ambito di accessibilità ai siti web.
In conclusione l’augurio che ci possiamo fare è quello di confidare nell’intelli-
genza e nel buon senso dei progettisti software che, nel rispetto degli standard
vigenti e delle più svariate tipologie di disabilità umane esistenti, riescano a
produrre del software di vera qualità e al contempo di universale utilizzo.
Parte I
Presentazione del Progetto di
stage e del problema della Web
accessibility
Capitolo 1
Il Progetto di stage
Il Comune di Bibbiena, essendo una Pubblica Amministrazione, ha rilevato la
necessità di adeguare il proprio sito web alle disposizioni vigenti nella Legge
9 gennaio 2004 n.4 [1], nota come Legge Stanca, Ministro per l’Innovazione
e le Tecnologie, in base alla quale i siti web delle Pubbliche Amministrazioni
devono garantire l’osservazione rigorosa e il rispetto delle Linee Guida sul-
la Web accessibility raccomandate dal World Wide Web Consortium
(W3C) e dal progetto Web Accessibility Initiative(WAI).
Tutte le Amministrazioni Pubbliche devono adempiere agli obblighi della
Legge sopra citata per rendere i propri siti web accessibili all’utente diversa-
mente abile.
Per un’amministrazione pubblica adempiere a tali obblighi significa rendere
i propri portali web facilmente usabili per il normale web user, ma anche
compatibili con le soluzioni software 1 esistenti che garantiscono l’accessibili-
tà agli utenti disabili.
Il progetto svolto per il Comune di Bibbiena consiste infatti nella rielabora-
zione del sito web già esistente per ottenerne uno compatibile con le Tec-
nologie Assistive, in modo tale da garantire agli utenti disabili l’accessibilità
al nuovo portale. Il sito progettato durante lo stage inoltre, come è stato
richiesto dall’Amministrazione Comunale, è stato anche rinnovato nel design
1Con soluzioni software si intende tutti i programmi software considerati possibili
soluzioni ad un determinato problema. In questo caso il tipo di problema a cui ci si riferisce
è l’accesso al web per l’utente disabile. Le soluzioni software esistenti come soluzione a
questo problema sono chiamate Tecnologie Assistive, ampiamente trattate nella parte
terza della relazione.
12
in modo abbastanza radicale.
Il motivo di ciò risiede nel fatto che l’efficienza del sito web esistente non era
considerata dall’amministrazione comunale molto buona, soprattutto perchè
le informazioni non erano state distribuite nel sito con un criterio comune a
tutte le pagine, bensì in modo un poco confusionario.
Il rinnovo del sito web del Comune di Bibbiena è stato commissionato e
fortemente voluto dal segretario generale, la Dott.ssa Silvia Petrucci, al fine
di ottenere un sito adeguato alla Legge Stanca, e quindi un sito che fosse
accessibile alle persone diversamente abili.
Pertanto la Dott.ssa Silvia Pertucci ha ritenuto opportuno riportare nel foo-
ter delle pagine web del sito creato durante lo stage poche righe dove viene
spiegato l’obbiettivo principale del sito stesso, vale a dire rispondere alle
richieste della Legge Stanca.
1.1 La realizzazione del lavoro 13
1.1 La realizzazione del lavoro
Uno dei problemi riscontrati nell’intento di realizzare il lavoro è sorto nel
momento in cui si è reso necessario scegliere il metodo tecnico più appropria-
to per l’implementazione.
Trattandosi dell’implementazione del sito di un Ente pubblico comunale la
scelta tecnica più adatta al caso sarebbe stata sicuramente lavorare con un
linguaggio web che potesse interagire con una base di dati, avendo a che fare
con una grande mole di dati.
L’intenzione era quella di utilizzare il linguaggio PHP con il supporto di
gestione dei database offerto dal pacchetto software My Admin, ma non è
stato possibile perchè l’Ente gestore del server del Comune di Bibbiena era
esterno ai locali comunali e non esperto nella configurazione del pacchetto
software.
Inoltre un ulteriore problema di cui era importante tenere conto nella scelta
del linguaggio web da utilizzare era causato dal fatto che le persone incarica-
te dal Comune di Bibbiena di tenere aggiornato il nuovo sito avevano espresso
determinati limiti cognitivi in ambito di programmazione web, per cui l’uso
del linguaggio PHP sarebbe stata una scelta inadeguata, nel senso che non
avrebbe forse consentito agli addetti comunali alla manutenzione del sito di
svolgere in modo adeguato il lavoro di aggiornamento.
Per tutti questi motivi la scelta è stata obbligatamente indirizzata verso l’uso
del linguaggio web di base, vale a dire l’HTML 4.01.
1.2 Le difficoltà incontrate 14
1.2 Le difficoltà incontrate
Oltre ai problemi descritti nel paragrafo precedente un altro fattore che meri-
ta di essere menzionato è da individuarsi sicuramente nella poca disponibilità
dimostrata dall’Ente gestore del server del Comune di Bibbiena, la Comunità
Montana del Casentino, che non ha dimostrato l’interesse alla realizzazione
del progetto di stage che il Comune si sarebbe aspettato, dimostrandosi spes-
so poco propensa alla collaborazione.
Tale atteggiamento si è concretizzato principalmente in due occasioni, vale a
dire quando è stato loro richiesto se era possibile implementare il nuovo sito
in PHP e quando è stato loro richiesto un account e l’indirizzo ftp per poter
testare on line il nuovo sito web.
La prima richiesta descritta era necessaria perchè, come spiegato nel para-
grafo soprastante, la scelta tecnica del PHP avrebbe reso il lavoro migliore
sia sotto l’aspetto della creazione del nuovo sito che della sua futura gestione
e aggiornamento, dal momento che il sito web già esistente era costituito
da una grande mole di dati che sarebbero stati gestiti in modo ottimale se
incorporati in un database.
Anche la seconda richiesta era necessaria per effettuare un test on line del
nuovo sito dal momento che sul vecchio sito web era presente una pagina, che
si raggiunge dal collegamento chiamato Questionario di soddisfazione per il
cittadino situato nella sezione Il Comune Utile, il cui contenuto informa-
tivo consiste nella presenza di un form attraverso cui il cittadino bibbienese
può esporre il proprio parere, consiglio o lamentela all’amministrazione co-
munale.
Il problema sta nel fatto che per la natura della pagina prettamente interat-
tiva non potendo testare il sito progettato nello stage con l’indirizzo ftp del
Comune di Bibbiena non è stato possibile capire se il funzionamento della
pagina sarà corretto nel momento in cui il personale gestore del server pro-
cederà alla pubblicazione del sito.
Di fronte a questo stato di cose dal momento che il tempo previsto per portare
a termine il progetto era della durata di tre mesi, non volendo perdere ulte-
riore tempo prezioso dovuto alle lunghe attese da sopportare ogni volta che
erano state fatte richieste di collaborazione dal Comune all’Ente gestore del
1.2 Le difficoltà incontrate 15
server, la decisione più logica è stata quella di risolvere il problema in modo
autonomo testando il sito on line anche senza la collaborazione della Comu-
nità Montana del Casentino, utilizzando però un indirizzo ftp ovviamente
diverso da quello del Comune.
1.3 Risultati ottenuti 16
1.3 Risultati ottenuti
E’di fondamentale importanza sottolineare che gli obbiettivi prefissati sono
stati raggiunti solo in parte.
Per raggiungere un livello sufficientemente accessibile nel sito progettato nel-
lo stage sarebbe stato un buon traguardo riuscire ad effettuare almeno tre
validazioni attraverso l’uso dei validatori on-line presenti nel sito del W3C,
vale a dire il validatore del linguaggio standard HTML 4.01, quello relativo
ai fogli di stile (CSS) 2 e infine quello che riguarda il livello di accessibilità
raggiunto, espresso dalla presenza nel bollino dell’accessibilità web del W3C
di una, due, o tre A 3.
Invece, una volta finito il lavoro di implementazione, è stato possibile ef-
fettuare soltanto il test relativo al linguaggio standard HTML 4.01 che ha
concesso l’esposizione del bollino relativo, stante a confermare un utilizzo
corretto dei comandi del linguaggio stesso.
Il motivo di ciò sta nel fatto che purtoppo il tempo per compiere il debugging
di tutte le pagine web del sito progettato nello stage relativamente all’utiliz-
zo dei comandi del linguaggio standard HTML 4.01, necessario proprio per
ottenere il bollino sull’accessibilità relativo al linguaggio stesso, è stato molto
più ampio del previsto poichè quando si effettua anche una piccola modifica
ad una pagina di un sito web implementato con il linguaggio HTML e al con-
tempo lo si vuole mentenere consistente è necessario propagare tale modifica
in tutte le pagine interne del sito stesso.
Perciò, dovendo apportare molte modifiche ai comandi dell’HTML, e doven-
do farlo pagina per pagina, è chiaro che il tempo necessario per fare ciò è
diventato elevato.
Per questo motivo non c’è stato più tempo per poter effettuare il test per
validare i fogli di stile, e quindi ottenere il bollino sull’accessibilità re-
2Acronimo di Cascading Style Sheets il Foglio di Stile è uno strumento per mezzo
del quale è possibile separare i contenuti di una pagina web dalle modalità tipografiche
con le quali essi vengono presentatati.
3Le Web Content Accessibility Guidelines 1.0 si articolano su tre livelli di prio-
rità che identificano tre livelli di gravità nei problemi derivanti dall’inaccessibilità di un
sito e, conseguentemente, tre livelli di adesione a tali norme. Il primo livello è rappresen-
tato dalla presenza nel bollino del W3C di una sola A, il secondo livello, quello medio,
dalla presenza di AA, e il terzo, il migliore, da AAA).
1.3 Risultati ottenuti 17
lativo ai CSS, nè il test per ottenere il bollino sull’accessibilità che esprime
il livello di priorità raggiunto attraverso l’esposizione sul bollino di una, due
o tre A.
Nella figura sottostante si riportano i tre bollini che a partire da sinistra si
riferiscono rispettivamente alla validazione dell’HTML 4.01, a quella che es-
prime il primo livello di priorità raggiunta con l’accessibilità e a quella dei
fogli di stile (CSS).
Figura 1.1: Le tre icone del W3C
Capitolo 2
Il problema della Web
accessibility
2.1 Definizione di Web Accessibility
‘ The power of the Web is in its universality. Access by everyone regardless
of disability is an essential aspect’. (Tim Berners-Lee )[2]
L’accessibilità in generale è la possibilità di accedere ad un luogo o una risor-
sa.
L’accessibilità web, in particolare, indica la possibilità di accedere efficace-
mente ad un sito web, alla sua interfaccia e al suo contenuto in situazioni
diverse.
Alcuni esempi di situazioni diverse possono essere una connessione ultrave-
loce dall’ufficio con schermo 21 pollici, una connessione da casa più lenta con
un modem da 56k di banda e con uno schermo da 15 pollici, l’utilizzo del
sito da parte di una persona non vedente, l’utilizzo di un browser vecchio di
due anni.
Poiché non è sempre possibile e semplice riuscire a integrare in un sito tutte
queste esigenze, devono essere stabilite delle priorità.
La priorità più alta va data a quelle situazioni che non è possibile modificare,
o non è possibile modificare facilmente, come il fatto che una persona disabile
continuerà ad essere tale anche quando è collegata ad un sito non accessibile.
Al contrario collegarsi alla rete con un browser obsoleto è una situazione ri-
solvibile poichè è quasi sempre possibile aggiornare il software o al massimo
2.1 Definizione di Web Accessibility 19
cambiare computer. È certamente costoso, ma fattibile.
Da queste considerazioni si intuisce quanto sia importante rendere il proprio
sito web universalmente accessibile.
Pertanto possiamo affermare che un sito web accessibile è un sito al quale
un qualsiasi utente riesce ad accedere con successo, e pertanto è capace di
rispondere anche alle esigenze di utenti disabili, oltre ad essere più facil-
mente accessibile agli utenti non portatori di handicap. Un tale sito è però
anche capace di risponde alle esigenze dei disabili tecnologici, ovvero tutte
quelle persone che in un dato momento della vita per diversi fattori sociali,
economici, fisici, di età, non riescono ad utilizzare Internet con facilità (come
per esempio le persone anziane).
Soltanto un sito accessibile garantisce il rispetto dell’articolo 3 della Costi-
tuzione della Reppubblica Italiana di seguito citato:
Tutti i cittadini hanno pari dignità sociale e sono eguali davanti alla legge sen-
za distinzione di sesso, di razza, di lingua, di religione, di opinioni politiche,
di condizioni personali e sociali (art.3 Costituzione della Repubblica Italiana).