accessibilitá del web 2.0: un caso di studio

UNIVERSITÀ DEGLI STUDI DI URBINO CARLO BO
Facoltà di Scienze e Tecnologie
Corso di Laurea in Informatica Applicata
Tesi di Laurea
ACCESSIBILITÁ DEL WEB 2.0:
UN CASO DI STUDIO
Relatore:
Chiar.mo Prof. Alessandro Bogliolo
Candidato:
Tommaso Battazzi
Correlatore:
Dott. Andrea Vivalda
Anno Accademico 2008-2009
A mio nonno Cristoforo
ii
Indice
1 Introduzione
1.1
1.2
Contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Organizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Tipologie di utenti
2.1
2.2
2.3
2.4
2.5
Utente normodotato . . . . . . . .
2.1.1 Personal Computer . . . . .
2.1.2 Dispositivi mobili . . . . . .
2.1.3 Lettori di e-book . . . . . .
2.1.4 Web TV . . . . . . . . . . .
2.1.5 L'inaccessibilitá del web . .
Utente con disabilitá visive . . . .
2.2.1 Tipologie di disabilitá visive
2.2.2 Tecnologie assistive . . . . .
2.2.3 Esempi di inaccessibilitá . .
Utente con disabilitá uditive . . . .
Utente con disabilitá motorie . . .
Utente con disabilitá cognitive . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
4
4
4
11
14
15
15
16
16
18
23
26
27
28
3 Accessibilitá del web
31
4 Linguaggi del web
40
5 ClaimStudentID
47
3.1
3.2
3.3
4.1
4.2
4.3
5.1
5.2
5.3
5.4
Denizione di accessibilitá . . . . . . . . . . . . . . . . . . . . .
Linee guida del W3C . . . . . . . . . . . . . . . . . . . . . . . .
Normative nazionali . . . . . . . . . . . . . . . . . . . . . . . .
XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
People services . . . . . . .
Content aggregation services
Meta-search services . . . .
Struttura dell'home page . .
.
.
.
.
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
32
34
40
44
45
48
49
50
50
6 Implementazione
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
Codice table-less . . . . . . . . . . . .
Pulizia e standardizzazione del codice .
6.2.1 Form . . . . . . . . . . . . . . .
6.2.2 Tabelle . . . . . . . . . . . . .
6.2.3 Immagini . . . . . . . . . . . .
6.2.4 Linguaggi esterni . . . . . . . .
6.2.5 Ulteriori accorgimenti . . . . .
Style switcher . . . . . . . . . . . . . .
Template multipli . . . . . . . . . . . .
6.4.1 low-vision . . . . . . . . . . . .
6.4.2 accessible . . . . . . . . . . . .
6.4.3 pda-screen . . . . . . . . . . . .
6.4.4 form . . . . . . . . . . . . . . .
Fogli di stile alternativi . . . . . . . .
6.5.1 print . . . . . . . . . . . . . . .
6.5.2 handheld . . . . . . . . . . . .
6.5.3 aural . . . . . . . . . . . . . . .
Skip navigation . . . . . . . . . . . . .
Mappa del sito . . . . . . . . . . . . .
Favicon . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
56
56
59
60
61
62
63
65
66
67
68
68
69
70
71
72
73
76
76
Bibliograa
77
Ringraziamenti
85
iv
Elenco delle gure
2.1
2.2
Il Box Model secondo le direttive del W3C . . . . . . . . . . . .
Il Box Model secondo il motore di rendering Trident di IE . . .
6
7
3.1
3.2
Loghi di certicazione del W3C . . . . . . . . . . . . . . . . . .
Loghi di certicazione WAI-WCAG 1.0 . . . . . . . . . . . . . .
32
34
5.1
Struttura logica dell'home page di ClaimStudentID . . . . . . .
51
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
6.17
6.18
6.19
6.20
6.21
6.22
6.23
6.24
6.25
6.26
Home page di ClaimStudentID con layout denito da tabelle .
Home page di ClaimStudentID con layout table-less . . . . . .
Home page personale con layout denito da tabelle . . . . . .
Codice HTML non Table-less . . . . . . . . . . . . . . . . . .
Statement CSS per la creazione del menu a tabs . . . . . . . .
Codice HTML Table-less . . . . . . . . . . . . . . . . . . . . .
Home page personale con layout table-less . . . . . . . . . . .
Form: Utilizzo dell'attributo onkeypress . . . . . . . . . . . .
Form: Associazione etichetta-campo di input . . . . . . . . .
Form: Proprietá CSS outline . . . . . . . . . . . . . . . . .
Tabelle: Utilizzo corretto degli elementi HTML . . . . . . . .
Immagini: Attributo HTML alt . . . . . . . . . . . . . . . .
Linguaggi esterni: Tag HTML <noscript> . . . . . . . . . . .
Linguaggi esterni: Codice di verica dei Cookie . . . . . . . .
Style switcher: Impostazione dello stile . . . . . . . . . . . . .
Style switcher: Tag HTML <select> per la scelta dello stile .
Style switcher: Scelta dello stile . . . . . . . . . . . . . . . . .
Style switcher: File esterno . . . . . . . . . . . . . . . . . . .
Contrasti su sfondo nero . . . . . . . . . . . . . . . . . . . . .
Contrasti su sfondo bianco . . . . . . . . . . . . . . . . . . . .
Template multipli: @-regola CSS @import . . . . . . . . . .
Template multipli: Risoluzione di un bug . . . . . . . . . . .
Fogli di stile alternativi: Dichiarazione in base al canale . . .
Fogli di stile alternativi: Dichiarazione CSS per la stampa . .
Fogli di stile alternativi: Proprietá CSS display . . . . . . .
Fogli di stile alternativi: Proprietá CSS content . . . . . . .
53
54
54
55
56
57
57
58
58
59
60
61
62
62
64
64
65
65
66
67
68
68
69
70
70
71
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6.27
6.28
6.29
6.30
6.31
6.32
Fogli di stile alternativi: Dichiarazione CSS per handheld . . .
Fogli di stile alternativi: Dichiarazione CSS per dispositivi aurali
Struttura tipo di un sito web . . . . . . . . . . . . . . . . . . .
Skip Navigation: Implementazione menu per dispositivi aurali .
Skip Navigation: Struttura dell'home page di ClaimStudentID .
Favicon: Dichiarazione favicon . . . . . . . . . . . . . . . . . .
vi
71
72
74
74
75
76
Capitolo 1
Introduzione
1.1 Contesto
Da quando nacque, nel 1969, Internet ha subito diverse trasformazioni e cambiamenti che lo hanno portato ad essere quello che noi tutti oggi conosciamo;
inizialmente nacque con lo scopo di collegare tra loro centri militari americani permettendone il coordinamento tramite computer. Questo almeno no
al 1980 quando vennero deniti i due protocolli base per Internet: il TCP e
l'IPche diedero il via al processo di nascita del web. L'evoluzione della rete
proseguí con la denizione da parte del CERN dell'HTML (1991), ovvero di un
linguaggio di markup ipertestuale con la capacitá di denire strutturalmente
e gracamente delle pagine web. Questa evoluzione determinó la necessitá di
avere strumenti in grado di leggere ed interpretare tale linguaggio, per cui nel
1993 nacque anche il primo browser per la navigazione in Internet (Mosaic).
Fino ai primi anni 2000 Internet continuó ad espandersi quasi esclusivamente come un raccoglitore di informazioni di qualunque genere, nché non
raggiunse un punto critico riguardante gli standard di linguaggio tale da richiedere un intervento. La criticitá riguardava soprattutto il linguaggio HTML che
non garantiva omogeneitá di interpretazione, di visualizzazione e soprattutto
non deniva in maniera rigida la propria sintassi. La prima cosa da fare era
dunque quella di denire degli standard di linguaggio da dover rispettare per
poter nalmente uniformare le informazioni presenti in rete. Questo passaggio
portó alla nascita nel 2000 da parte del W3C (World Wide Web Consortium)
dell'XHTML, cioè di un linguaggio di markup in grado di associare alcune
proprietá dell'XML con le caratteristiche dell'HTML; il le XHTML è di fatto
una pagina HTML scritta in conformitá con lo standard XML. Il linguaggio
richiede un uso piú restrittivo dei tag HTML, prevedendo una separazione tra
la struttura della pagina (scritta in XHTML) e il layout graco (impostato dai
fogli di stile a cascata, i CSS o Cascading Style Sheets).
Negli ultimi anni si è poi sviluppato quello che è stato denito come web 2.0.
1.1 Contesto
2
Con questo termine si tende ad indicare l'insieme di tutte quelle applicazioni online che permettono uno spiccato livello di interazione sito-utente (blog,
forum, chat, sistemi quali Wikipedia, Youtube, Facebook, Myspace, Gmail,
ecc.). Anche le conoscenze richieste nell'interazione con la rete sono cambiate;
infatti se prima del web 2.0 la costruzione di un sito personale richiedeva la
padronanza di elementi di HTML e di programmazione, oggi con i blog chiunque è in grado di pubblicare i propri contenuti, dotandoli anche di veste graca
accattivante, senza possedere alcuna particolare preparazione tecnica. Anche
le community web erano nella stragrande maggioranza dei casi costituite da
esperti informatici, mentre oggi la situazione è completamente ribaltata. A farla da padroni sui blog sono scrittori, giornalisti, artisti o comunque chiunque
voglia condividere una qualsiasi informazione, anche se con una preparazione
informatica non particolarmente elevata.
Lo sviluppo del web non si è peró limitato all'interazione con l'utente ma
si è anche evoluto verso nuovi canali comunicativi e verso nuovi utenti; ora
l'utente non è piú soltanto colui che utilizza un classico home PC, ma anche
chi utilizza altri tipi di dispositivi come palmari, cellulari o tecnologie assistive.
Adesso è possibile navigare nel web anche per l'utente non normodotato attraverso l'utilizzo di particolari tecnologie assistive, siano queste vocali, visive o di
altro genere. Il propagarsi della losoa dell'open source ha fatto poi in modo
che potessero proliferare anche diversi browser per la navigazione sul web, sia
che questa avvenga su PC, su altri canali (come i telefoni cellulari) oppure su
altri dispositivi assistivi hardware (come ad esempio sistemi di output tattile)
mediante particolari software ad hoc come i voice browser. Le diverse modalitá
di accesso al web, di interpretazione dei diversi browser e di tipologie di utenti
hanno peró portato alla necessitá di denire delle norme in ambito di accessibilitá e delle direttive facenti riferimento agli standard internazionali deniti dal
W3C come l'XML, l'XHTML o i CSS. A livello internazionale lo stesso World
Wide Web Consortium (W3C) ha denito un ampio range di raccomandazioni per rendere i contenuti piú accessibili anche a persone con diversi tipi di
disabilitá come, per esempio, la cecitá, l'ipovisione, la sorditá o le limitazioni
cognitive o di movimento. Ogni nazione ha avuto poi la possibilitá di denire
delle proprie regole sull'accessibilitá del web. Nel caso dell'Italia la normativa
in vigore è la legge Stanca (num. 4/2004), la quale denisce come accessibilitá
la capacitá dei sistemi informatici di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilitá
necessitano di tecnologie assistive o congurazioni particolari. In questa legge
sono di fatto deniti ben 22 requisiti che un'applicazione web deve soddisfare
per essere considerata accessibile da tale normativa. In realtá alcuni di questi
requisiti vengono soddisfatti da una buona scrittura di codice XHTML.
1.2 Organizzazione
3
1.2 Organizzazione
Lo scopo di questa tesi è l'applicazione dei principi dell'accessibilitá ad un'applicazione web 2.0 sviluppata all'Universitá degli Studi di Urbino: ClaimStudentID [1].
In particolare nel secondo capitolo verranno evidenziati i diversi canali comunicativi utilizzabili per accedere al web, le tipologie di utenti che possono
utilizzarli, le diverse disabilitá che possono limitare agli utenti stessi l'utilizzo
del web, ed i principali browser utilizzati nei diversi canali. Verranno inoltre
illustrati alcuni esempi di dicoltá nella navigazione in una pagina HTML
per un utente adoperante tecnologie assistive; in particolare verrá illustrato un
esempio riguardante un dispositivo di screen reader.
Nel terzo capitolo verranno invece illustrati il concetto di accessibilitá e le
relative normative internazionali (indette dal W3C) e nazionali (legge Stanca
num. 4/2004).
Nel quarto capitolo verranno poi introdotti i CSS (Cascading Style Sheet),
cioè i fogli di stile applicabili alla pagina web aventi il compito di separare il contenuto della pagina dalla sua presentazione, attraverso l'implementazione della
sola presentazione tramite particolari regole di visualizzazione degli elementi
ipertestuali. Nello stesso capitolo verrá altresí trattato anche il linguaggio
XHTML e ci sará una breve panoramica sul linguaggio PHP.
Nel quinto capitolo verrá invece introdotto il caso di studio di ClaimStudentID per il quale si è sviluppato il progetto a cui questa tesi è applicata.
Nel sesto ed ultimo capitolo saranno mostrati alcuni dettagli implementativi relativi al caso di studio proposto. Tra queste alcune soluzioni di codice
richieste dagli standard internazionali ed altre create ad hoc per facilitare ed
alleggerire la navigazione nell'applicazione ad alcune tipologie di utenti.
Capitolo 2
Tipologie di utenti
Esistono diverse tipologie di utenti che accedono ogni giorno ad Internet per
vari motivi che possono abbracciare diversi campi: lavoro, svago, necessitá,
educazione, eccetera. Ogni tipologia di utente puó utilizzare diversi canali,
software o dispositivi per eettuare l'accesso alla rete, ma anche incontrare
diversi casi di inaccessibilitá per ognuno di questi. In questo capitolo verrá effettuata una panoramica su diverse tipologie di utente, in particolare verranno
esaminati i seguenti utenti:
1. Normodotati (classici)
2. Con disabilitá visive
3. Con disabilitá uditive
4. Con disabilitá di movimento
5. Con disabilitá cognitive e dell'apprendimento
2.1 Utente normodotato
Per utente normodotato si intende l'utente senza nessuna particolare disabilitá
che possa comprometterne la navigazione nel web; si tratta di fatto dell'utente
tipo. Questa tipologia di utente puó utilizzare un'ampia varietá di canali per
accedere ad Internet, per ognuno dei quali esistono diversi software. L'utente
normodotato non è comunque esente da esempi di inaccessibilitá poiché questa
non è una prerogativa esclusiva del disabile. Di seguito verranno in breve
illustrati i vari canali ed i corrispettivi software, con anche qualche esempio di
inaccessibilitá.
2.1.1
Personal Computer
Il Personal Computer, spesso noto con l'acronimo PC, è ormai un dispositivo
indispensabile e presente in tutte le famiglie. Questa tipologia di computer (la
2.1 Utente normodotato
5
piú classica e conosciuta) si distingue per il suo orientamento general purpose
(non destinato a scopi specici) e dal suo essere monoutente (utilizzabile da
un solo utente alla volta). Quando si parla di PC si tiene automaticamente
conto sia dei computer desktop (quelli ssi, da scrivania), sia dei computer
portatili. Fino a qualche anno fa tutti i computer (o quasi) adottavano gli stessi
programmi e, soprattutto, condividevano lo stesso sistema operativo; oggi non
è piú cosí, infatti si sono sviluppati e diusi diversi sistemi. Il predominio del
mercato dei sistemi operativi è ancora saldamente nelle mani di Microsoft con
il suo prodotto, ma stanno guadagnando sempre maggiori quote i vari Mac OS,
Linux, Solaris ed altri.
Con la nascita del web si sono inevitabilmente sviluppati anche i linguaggi utili per creare contenuti adatti ad esso: l'HTML. Successivamente con la
diusione di Internet nel mondo, non solo i PC sono diventati sempre piú
indispensabili, ma anche le applicazioni utili ad interpretare l'HTML ed alla
navigazione in rete: i browser. Questi applicativi hanno il compito di interpretare il linguaggio HTML e di renderizzarlo attraverso un motore di rendering,
motore dierente da browser a browser. In principio il primo a nascere è stato
un progetto guida di nome WorldWideWeb, anche se il primo vero browser a
diondersi è stato Mosaic, seguito a breve da Netscape Navigator; questi due
browser sono stati ben presto surclassati da Microsoft e da Internet Explorer.
Il regno del browser di casa Microsoft ha durato decenni, ed è rimasto tale no
all'alba del 2009 quando, per la prima volta, la sua diusione è scesa al di sotto
di quella di un suo diretto concorrente: Mozilla Firefox. Firefox non è peró
l'unico browser in ascesa, insieme ad esso infatti sono presenti numerosissimi
browser, ognuno con delle caratteristiche particolari. Di seguito verrá mostrata
una panoramica dei piú diusi e dei piú interessanti browser presenti.
Netscape Navigator
Netscape Navigator [2] fu il primo web browser graco di successo della storia
dell'informatica. Dalla versione 8 questo browser ha deciso di cambiare il
proprio nome in Netscape Browser; nome peró non destinato a fare la storia o
a durare, in quanto non sono previste nuove versioni successive alla numero 9,
l'ultima per questo pezzo di storia del web. Dal primo marzo 2008 la societá
che ne detiene i diritti ha dichiarato la ne del progetto Netscape.
Windows Internet Explorer
Nasce nel 1995 su Windows '95 con il nome di Microsoft Internet Explorer, ma
piú di recente è stato rinominato in Windows Internet Explorer [3]. Dalla sua
nascita è sempre stato il browser piú diuso ed utilizzato al mondo, o almeno
lo è stato no all'alba del 2009 quando, per la prima volta, è stato superato
dal rivale Firefox. Negli ultimi due anni infatti Internet Explorer ha perso
2.1 Utente normodotato
6
una percentuale di diusione di quasi 14 punti percentuali, mentre Firefox (ma
non solo) ha costantemente continuato ad aumentare la propria quota.
Il calo della percentuale di utilizzo di Internet Explorer (IE) è dovuto sia
al fatto che questo è disponibile solo per ambienti Windows (che a loro volta
stanno anch'essi perdendo quote percentuali, anche se in maniera molto piú
ridotta), sia alla sua staticitá (dicoltá di personalizzazione del prodotto da
parte dell'utente) e sia ai diversi errori di interpretazione che questo browser
presenta anche nei confronti di speciche uciali internazionali. Un esempio ecclatante è l'errata interpretazione da parte di Internet Explorer 5 del
box model [4] dei CSS (standard uciale del W3C), ed in particolare delle
proprietá width ed height, che determinano rispettivamente la larghezza e
l'altezza di un blocco. IE interpreta queste due dimensioni del box in modo
che includano anche i bordi ed il padding (lo spazio presente tra il bordo ed
il contenuto del box); queste ultime due caratteristiche, secondo le speciche
uciali, dovrebbero peró essere denite in maniera autonoma e non dovrebbero essere parte (soprattutto il padding) delle dimensioni del box (gure 2.1 e
2.2).
Figura 2.1: Il Box Model secondo le direttive del W3C
Questa non uniformitá di interpretazione del box model causa una dierenza di visualizzazione dei blocchi tra diversi browser, in particolare tra IE (e
derivati) e gli altri.
L'interpretazione del box model non è peró l'unico problema che uno sviluppatore si trova ad incontrare durante la creazione di una pagina web per
via delle dierenze soprattutto di IE; altri problemi possono vericarsi anche
dal mancato supporto a determinate tecnologie (come gli X-Forms) o da un
supporto piú scarso verso altre (DOM o CSS). Uno sviluppatore, per poter uniformare l'aspetto di una pagina web in tutti i browser, è costretto ad adottare
trucchetti non sempre leciti e previsti dagli standard del web o dalle speciche
di determinati linguaggi. Dalla versione 6 peró Internet Explorer fornisce agli
sviluppatori una caratteristica capace di facilitare la creazione di una pagina
web e la sua uniformitá: i commenti condizionali. Questi commenti sono di
2.1 Utente normodotato
7
Figura 2.2: Il Box Model secondo il motore di rendering Trident di IE
fatto delle istruzioni messe all'interno di un normale commento (X)HTML,
istruzioni che vengono ignorate dalla totalitá degli altri browser, e che sono
interpretate unicamente da IE. Questo marchingegno permette agli sviluppatori di poter correggere determinati errori di IE, uniformando cosí la sua
visualizzazione a quella degli altri browser graci, denendo all'interno di tali
commenti le istruzioni di stile apposite per questo browser.
A dierenza di un classico commento (X)HTML (determinato dai tag <!- e
->), i commenti condizionali sono deniti da speciali tag ( <!-(if IE)>
e <!(endif)->) e se al loro interno viene denito un foglio di stile creato ad
hoc per IE, questo sovrascriverá le istruzioni di stile denite precedentemente
e valide per tutti gli altri browser.
Mozilla Firefox
Mozilla Firefox [5] è un web browser open source multipiattaforma prodotto da
Mozilla Foundation. Attualmente è il browser piú usato in assoluto, in quanto
ha superato per la prima volta Internet Explorer nel Gennaio 2009. Il suo
primo nome fu Phoenix (fenice, in inglese), che fu adottato per simboleggiare la
rinascita dalle ceneri di Netscape; dopo diverse vicissitudini, anche giudiziarie,
il nome cambió prima in Firebird ed inne in Firefox.
Uno dei suoi punti di forza è il fatto di essere un'applicazione multipiattaforma,
è infatti disponibile per sistemi GNU/Linux, Microsoft Windows, Mac OS X,
OS/2 e Solaris. L'Open source garantisce a Firefox un'elevata compatibilitá
con diversi prodotti di vario genere (come per esempio gli antivirus) e fornisce
all'utente un'elevato grado di adabilitá e di personalizzazione.
Apple Safari
Safari [6] è il browser web sviluppato da Apple Inc. per il sistema operativo
Mac OS X sul quale è fornito di default dalla versione 10.3. Per renderizzare
2.1 Utente normodotato
8
le pagine HTML, Safari utilizza il framework WebKit, fornito con il sistema
operativo. Anche il nuovo nato in casa Apple, l'iPhone utilizza questo browser.
Il codice del motore di rendering è basato sul motore KHTML utilizzato dal
browser open source Konqueror, il che implica che il codice del motore di rendering HTML è rilasciato sotto licenza GNU Lesser General Public License. I
miglioramenti nel codice di KHTML introdotti dagli ingegneri di Apple vengono restituiti alla comunitá di KDE di modo che possano essere integrati nel
progetto originario.
Opera
Opera [7] è un browser web (prodotto da Opera Software) multipiattaforma,
è infatti disponibile, tra gli altri, per i sistemi operativi Windows, Macintosh
e Linux. È il quarto browser piú utilizzato dopo Internet Explorer, Mozilla
Firefox e Apple Safari.
Opera possiede, a dierenza degli altri browser, un sistema di riconoscimento
vocale e di sintesi vocale integrato. Per quanto riguarda la prima funzione, i
comandi vanno pronunciati dopo aver premuto un apposito pulsante, preceduti
dalla parola chiave Opera (per evitare di lanciare comandi involontari). Per
quanto riguarda la funzione di sintesi (disponibile solo in lingua inglese), è possibile far pronunciare a Opera il testo selezionato (tramite pulsante o comando
vocale), con voce maschile o femminile.
Il browser Opera è inoltre capace di emulare i browser testuali (per esempio
Lynx); questa funzione puó essere molto utile quando si richiede il caricamento
rapido di una pagina, oppure per eseguire un testing piú completo per i siti in
costruzione.
Inne Opera implementa anche una serie di gesti per il mouse (mouse gesture), attuabili con una combinazione di click e trascinamenti del puntatore, che
rendono superuo l'utilizzo delle barre degli strumenti e dei menu.
Konqueror
Konqueror [8] è un software che possiede sia le funzioni di browser web, sia
quelle di visualizzatore di documenti. È integrato nell'ambiente desktop KDE
disponibile per piattaforme GNU/Linux e altri sistemi di tipo Unix.
SeaMonkey
SeaMonkey [10] non è un semplice browser web, ma una vera e propria suite
per la navigazione su Internet. SeaMonkey è parzialmente basato sul codice
di Firefox e Thunderbird, e unisce le caratteristiche di un browser per la navigazione in internet, le funzioni di un gestore di posta elettronica, un editor
HTML e un client IRC1 .
1
Internet Relay Chat
2.1 Utente normodotato
9
Google Chrome
Chrome [11] è l'ultimo nato nel campo dei browser (almeno tra quelli piú noti)
ed è un software open source basato su WebKit e sviluppato da Google. La
prima distribuzione di tipo beta, disponibile inizialmente solo per la piattaforma Windows, è iniziata il 2 settembre 2008 ed è stata disponibile da subito in
ben 43 lingue.
Gli obiettivi principali di questo progetto sono rivolti ad un miglioramento
in sicurezza, velocitá e stabilitá rispetto ai browser esistenti. Riguardo alla
stabilitá Chrome presenta una novitá assoluta nel mondo dei browser: il task
manager; questa funzione permette all'utente di controllare in tempo reale le
informazioni sui siti in uso (utilizzo di banda, memoria e CPU), consentendone
anche la terminazione. Un'altra innovazione volta ad evitare che schede o
plug-in possano interferire tra loro o le une con le altre, riguarda l'esecuzione
separata di ognuna di queste; questo permette di aumentare ulteriormente la
stabilitá del browser di casa Google.
Anche l'interfaccia graca è piuttosto semplice e rivoluzionaria rispetto agli
standard precedentemente esistenti.
Browser derivati
Camino [12] è un browser web open source nato per sistemi Mac OS X basato
su Mozilla. Camino non comprende servizi di e-mail o di newsgroup (tipici dei
progetti Mozilla) ma implementa unicamente le funzioni di browser tramite
l'utilizzo del motore di rendering di Mozilla: Gecko. Camino ha la particolaritá
di essere molto leggero, stabile e veloce.
Nell'home page del proprio sito web, Camino viene cosí descritto: Camino
combina la maestosa esperienza visuale e comportamentale che caratterizza la
losoa di Macintosh con le potenti capacitá di navigazione sul Web del motore
di rendering Gecko. L'idea di base del progetto Camino è quella di avere un
browser capace di prendere il meglio da Firefox (dal quale prende il motore) e
dai sistemi Mac (dal quale eredita la carrozzeria). Nonostante le sue qualitá,
Camino possiede peró una quota di mercato praticamente insignicante.
Flock [13] è un browser multipiattaforma (per sistemi Windows, Mac OS
X e Linux) basato su Mozilla Firefox. Ai suoi creatori piace denirlo come
browser sociale per via dell'integrazione di servizi Internet come blog, condivisione di dati (Flick, YouTube, ecc.), aggregazione di news e servizi di social
bookmarking (Del.icio.us, Digg, ecc.).
K-Meleon [14] è un browser molto leggero e anch'esso basato su Gecko,
il motore di rendering di Mozilla. K-Meleon è stato creato facendo particolare
attenzione alla velocitá del programma, piuttosto che alla graca, (leggerissima
ed essenziale). La leggerezza e la velocitá di K-Meleon dipendono fondamentalmente dal fatto che, per l'interfaccia, utilizza le librerie di sistema. K-Meleon
2.1 Utente normodotato
10
è particolarmente indicato per PC vecchi o con risorse limitate, proprio per via
dei suoi bassi tempi di risposta e per il suo bassissimo consumo di risorse.
Avant Browser [15] è un web browser sviluppato da Avant Force e basato sul motore di rendering Trident di Internet Explorer (del quale è richiesta
l'installazione). È facile da utilizzare, versatile, stabile e rappresenta l'apripista tecnologico di Explorer. Molte diverse funzionalitá aggiuntive ora presenti
anche su Explorer (dalla versione 7) erano giá state implementate da Avant;
tra queste la navigazione contemporanea su piú siti, la navigazione a schede,
il blocco delle nestre pop-up, la cancellazione periodica della cache e della history o la possibilitá di eseguire ricerche integrate utilizzando Yahoo e
Google.
Orca Browser [16] è l'ultimo nato in casa Avant Force. Condivide con
il proprio fratello Avant, la graca pulita e leggera, ma dierisce da questo
nel motore di rendering, Orca infatti è implementato su Gecko di Firefox 3
anziché su Trident di IE. È un browser molto veloce (anche piú di Opera) ed
user-friendly. Anch'esso, come Avant, presenta diverse funzionalitá aggiuntive
rispetto a Firefox, come il blocco per la pubblicitá, le mouse gestures, l'autocompletamento dei campi di testo o le opzioni disponibili in interfaccia graca
(in Firefox sono presenti in interfaccia testuale digitando nella barra degli indirizzi about:cong); Orca è peró sprovvisto dei supporti agli add-on di Firefox
3. Una ulteriore innovazione è la possibilitá di salvare online congurazione,
preferiti, RSS e passwords, in modo da poter accedere a questi dati anche da
un altro computer con Orca Browser installato.
Slim Browser [17] è invece considerato un browser a portata di accessibilitá. Il suo motore si basa su quello di Internet Explorer ma presenta
numerose funzioni in piú rispetto al proprio progenitore. Tra le caratteristiche piú innovative proposte da questo browser (rispetto ad Explorer 7) ci sono
l'implementazione dello Zoom, delle funzioni di traduzione linguistica, la possibilitá di eettuare bloccaggi di pop-up, ltraggi di siti web e di svolgere aliasing
sugli indirizzi http.
Porzioni di mercato dei diversi browser in Europa
Il mondo dei browser è sempre in continua evoluzione, cosí come la loro popolaritá e la loro diusione tra gli utenti nel mondo. La tabella 2.1 mostra
l'evoluzione della quota di mercato negli ultimi 2 anni (da Gennaio 2007 a
Gennaio 2009) [18]. È evidente come il colosso di Microsoft, Internet Explorer,
ha sempre e continuamente perso quote di mercato in favore di altri browser
(soprattutto Mozilla Firefox) che invece hanno progressivamente conquistato
percentuali sempre maggiori. Da Gennaio 2009, per la prima volta, Firefox supera Explorer e diventa il nuovo browser piú utilizzato nel mondo, nonostante
l'uscita della nuova versione (IE 8) del vecchio primatista.
2.1 Utente normodotato
Internet Explorer 8
Internet Explorer 7
Internet Explorer 6
Internet Explorer 5
Internet Explorer
Mozilla Firefox
Mozilla
Apple Safari
Opera
Google Chrome
altro
11
Gen '07
Ott '07
Gen '08
Ott '08
Gen '09
58,6%
31,0%
1,5%
1,7%
1,5%
5,7%
56,7%
36,0%
1,3%
1,7%
1,6%
2,7%
54,7%
36,4%
1,3%
1,9%
1,4%
4,3%
47,1%
44,0%
0,4%
2,8%
2,2%
3,0%
0,5%
44,9%
45,5%
3,0%
2,3%
3,9%
0,4%
13,3%
42,3%
3,0%
20,7%
34,5%
1,5%
21,2%
32,0%
1,5%
26,9%
20,2%
-
0,6%
25,7%
18,6%
-
Tabella 2.1: Porzioni di mercato dei diversi browser in Europa
Supporto agli standard dei principali browser
Secondo un accurato studio comparativo svolto da David Hammond (Web browser standards support summary [19]), il supporto di Internet Explorer 7 alle
speciche CSS 2.1, che sono la versione aggiornata, anche se non ancora uciale, dello standard CSS2, è solo del 56%, (con solo cinque punti percentuali di
miglioramento rispetto alla sua versione numero 6), mentre Firefox 2 e Opera
9 presentano un supporto di gran lunga superiore, rispettivamente 91% e 94%.
Ugualmente carente è il supporto di Explorer 7 alle speciche DOM (51%),
contro una percentuale vicina all'80% dei browser concorrenti. Leggermente
migliore è la situazione per il supporto ai linguaggi del web HTML/XHTML,
che per Internet Explorer 6 e 7 è del 73%, contro il 90% di Firefox e l'85% di
Opera.
Buono invece il supporto per JavaScript sia per Internet Explorer 7 (99%),
sia per gli altri due browser valutati in questa ricerca (100%).
2.1.2
Dispositivi mobili
Con i progressi della telefonia mobile, negli ultimi anni si è avuta una vera
e propria esplosione nell'evoluzione di questi dispositivi che possono essere
suddivisi in quattro categorie principali: telefoni cellulari, computer palmari
(o PDA, personal digital assistant), smartphones e Ultra Mobile PC (UMPC).
Telefono cellulare
Il telefono cellulare [20] è ormai una realtá consolidata nelle vita quotidiana
di ogni persona; questo altro non è che un apparecchio radio trasmittentericevente per la comunicazione in radiotelefonia, collegato alla rete telefonica di
terra tramite centrali di smistamento (stazioni radio base, in inglese BTS, Base
2.1 Utente normodotato
12
Transceiver Station), molto spesso dotate di tre o piú celle che deniscono l'area
di copertura del segnale, nella quale possono connettersi diversi apparecchi
mobili.
Giá da qualche anno i telefoni cellulari hanno la possibilitá di connettersi ad Internet e di usufruire di servizi online. Un telefonino peró è piuttosto
dierente rispetto ad un home PC, soprattutto nelle dimensioni dello schermo
(solitamente di 176 x 220 pixel) e quindi nella risoluzione. Una pagina web
realmente accessibile deve essere visualizzabile ed adattabile a queste risoluzioni minori, prediligendo la dimensione verticale rispetto a quella orizzontale.
Il progettista di siti web, se vuole creare un'applicazione in grado di essere
fruibile anche dai telefoni cellulari, deve perció tenere conto, come prima cosa,
della dierenza di risoluzione, magari creando fogli di stile appositi.
Alcuni grandi quotidiani italiani, hanno predisposto giá da tempo versioni
ad hoc dei loro siti web, adatte ad essere navigate con dispositivi mobili. Tuttavia non è sempre necessario predisporre una versione del sito dierente da
quella standard per soddisfare le esigenze di chi si collega tramite un cellulare,
anche se è sempre buona norma considerare tutti i casi possibili e realizzare
una versione apposita. Un buon accorgimento per creare una pagina web adattabile anche ai telefonini è quello di adottare una linea di progettazione che
utilizzi un'impaginazione semplice ed organizzata con unitá di misura relative
e proporzionali.
Esistono peró anche dei browser per telefoni cellulari (per esempio Opera Mini,
Fennec, eccetera) che sono in grado di adattare da soli, e con ottimi risultati, qualsiasi contenuto di una pagina web alla larghezza dello schermo di un
cellulare.
Palmare
Un palmare [20] (spesso indicato in lingua inglese con l'acronimo PDA, Personal Digital Assistant, o con l'ormai consueto termine palmtop) è un computer
di dimensioni ridotte, tali da poter essere portato sul palmo di una mano, dotato di uno schermo sensibile al tocco (o Touch Screen).
Inizialmente i palmari sono nati come semplici agende alettroniche dotate di
poche funzioni basilari (calendario, calcolatrice, agenda, notes, rubrica), per
poi evolversi (l'azienda che ne diede il via fu la Apple) no ad arrivare ai complessi apparecchi ricchi di funzioni dei giorni nostri. Oggi questi mini-computer
dispongono delle stesse funzioni (al limite in maniera semplicata) degli home
PC, compreso un sistema operativo. Nei palmtop non esiste un leader assoluto
per la distribuzione dei sistemi operativi e per questo ce ne sono di diverse
tipologie. Di seguito sono elencati in breve i piú diusi sistemi operativi per
palmare:
• Palm OS [23]: questa piattaforma (introdotta nel 1996) ha di fatto denito il trend e le aspettative per i palmari, ed ha portato gli stessi palmari
all'evoluzione da semplici agende elettroniche in veri e propri computer.
2.1 Utente normodotato
13
• BlackBerry di Research In Motion [24]: è un tipo di PDA wireless introdotto nel 1999 che permette di scaricare dalla propria casella di posta
elettronica, la gestione della propria agenda, di scrivere messaggi SMS e
permette eettuare chiamate verso i propri contatti.
• Mobile Linux (MLI) [25]: è il sistema operativo creato da Linux Foundation.
• Symbian (giá EPOC) [26]: è un sistema operativo aperto per PDA,
adottato da varie aziende come standard.
• Windows Mobile [27]: è il sistema operativo di Microsoft, simile al piú
celebre Windows, per personal computer e portatili.
Lo schermo di un palmare ha in genere una risoluzione di 240x320 pixel, con
un'area di pagina quasi doppia rispetto a quella visualizzata da un cellulare. La
navigazione con un palmare è potenzialmente piú comoda e piú soddisfacente
per l'utente in quanto, per esempio, le operazioni di input vengono eettuate
con uno stilo, che consente un maggior controllo ed una maggior semplicitá nelle
scelte rispetto ai tasti di un cellulare. Nonostante le dierenze (soprattutto
di risoluzione), solitamente viene associato ai palmari lo stesso foglio di stile
creato per i cellulari; nel palmtop saranno poi il sistema operativo ed il browser
a modellare la pagina, magari riadattandola alle dimensioni dello schermo,
quindi di fatto ingrandendola.
Smartphone
Uno smartphone [20] è un dispositivo portatile che abbina funzionalitá di
gestione di dati personali e di telefono. Puó derivare dall'evoluzione di un
PDA a cui si aggiungono funzioni di telefono (per questo detti anche PDAPhones) o viceversa. Oggi gli smartphone adottano un'ampia gamma di connessioni (GSM, GPRS, EDGE, UMTS, HSDPA, Bluetooth e Wi-Fi) per le
comunicazioni con altri dispositivi.
UMPC
Quando si parla di UMPC (acronimo di Ultra Mobile PC) [20] vengono intesi
alcuni particolari computer ultra portatili di dimensioni a metá strada tra
quelle di un palmare e quelle di un subnotebook.
Il primo dispositivo UMPC (Origami) nasce per opera di Microsoft nel 2006.
Generalmente gli UMPC utilizzano prevalentemente schermi touchscreen come
dispositivo di input (un po' come nei sistemi palmari), anche se negli ultimi
tempi questi sono anche provvisti di tastiera scorrevole qwerty estraibile dal
corpo del dispositivo, per un piú semplice inserimento del testo (es. scrittura
di una e-mail).
2.1 Utente normodotato
14
Browser per dispositivi mobili
A dierenza degli home PC, nei dispositivi mobili esistono diversi browser
capaci di contendersi il mercato. I piú conosciuti sono sicuramente quelli di
casa Opera, ovvero il giá citato Opera Mini [28], pensato per i cellulari, e suo
fratello maggiore Opera Mobile [29], orientato verso i palmari.
Uno dei principali avversari di Opera Mobile è sicuramente Access NetFront [30], capace di supportare ecacemente Java, Flash, SMIL, SVG, XHTML,
CSS, JavaScript 1.5, DOM 1 e 2: in pratica tutti i principali linguaggi standard
per il Web. Questo permette inoltre di bloccare i pop-up, di aprire piú nestre
contemporaneamente ed è compatibile con i formati RSS e Atom.
Altri browser per dispositivi mobili sono Minimo (prodotto dal progetto
Mozilla) [31] e ThunderHawk (di Bitstream) [32]; quest'ultimo è un browser
implementato tramite Java che punta sulla capacitá di rappresentare le pagine
web nel modo piú confortevole per l'utente, soprattutto grazie alle funzioni di
ingrandimento.
Il progetto Mozilla non si è peró limitato al solo Minimo, infatti è recentemente nato (Ottobre 2008) l'ultimo glio di casa Mozilla: Fennec [33].
Il piccolo Firefox non è rivolto unicamente all'utente di dispositivi mobili,
ma è anche disponibile per i sistemi operativi classici quali Windows, Mac e
Linux. Le principali caratteristiche sono il supporto al touchscreen, il blocco
dei pop-up, il password manager, la gestione di tabelle e barra degli indirizzi
simile a quella di Firefox e l'addattamento della pagina alle dimensioni dello
schermo.
2.1.3
Lettori di e-book
Un altro dispositivo mobile, di nuova concezione, è il lettore di libri elettronici,
o e-book reader [20]. Questi dispositivi non sono ancora molto diusi ma
potrebbero, in ottica futura, essere anche presi in considerazione da chi crea
applicazioni web accessibili.
Gli e-book reader sono stati pensati per permettere la lettura di libri elettronici, siano questi in formato pdf, doc, txt o altri, ma possono in realtá anche
ricevere documenti HTML (convertiti attraverso un appostito software). I lettori di e-book utilizzano monitor a soli quattro toni di grigio, per questo un sito
web, per essere utilizzabile da questi dispositivi, deve poter mantenere i propri
contenuti ben leggibili anche nelle particolari condizioni oerte dal dispositivo
in questione (schermo ridotto e gradazioni di grigio).
La mancata (per ora) diusione di questi dispositivi puó essere principalmente dovuta a due fattori: le dicoltá tecnologiche e l'ostilitá delle case
editrici, le quali temono che possa rivericarsi lo stesso processo avvenuto per
la musica in formato mp3.
2.1 Utente normodotato
2.1.4
15
Web TV
Alcuni grandi produttori di elettronica di consumo hanno giá da tempo in
listino apparecchi chiamati Web TV Receiver [20], costituiti da un ricevitore,
una tastiera e un telecomando, che, in combinazione con un comune televisore,
permettono l'accesso al Web e alla posta elettronica tramite lo schermo TV,
utilizzato come monitor.
Dal punto di vista dell'accessibilitá, la Web TV crea non pochi problemi
allo sviluppatore; infatti il browser di Microsoft integrato in molti di questi
sistemi (MSN TV Viewer), ha una risoluzione ssa di 544x372 pixel, forzata
dalle caratteristiche degli apparecchi televisivi che usano il segnale NTSC (PAL
in Europa). Questa è una risoluzione che corrisponde, in termini di area, a poco
piú di un quarto di quella attualmente piú utilizzata su computer desktop e
portatili (1024x768 pixel). In questo spazio molto ridotto è inoltre impossibile
utilizzare lo scorrimento orizzontale; il che porta di conseguenza alla necessitá
di linearizzare i siti web con una dimensione orizzontale maggiore di 544 pixel,
cioè far scorrere verso il basso, invece che verso destra, i contenuti eccedenti
orizzontalmente. Quando la linearizzazione non è possibile, i contenuti vengono
addirittura troncati.
A causa della scarsa densitá in pixel dei televisori e della notevole distanza a
cui di solito è seduto l'utente, MSN TV Viewer si riserva di ingrandire notevolmente i caratteri per favorirne una maggiore leggibilitá; questo ingrandimento
provoca peró un ulteriore allungamento delle pagine web, che niscono cosí
con l'occupare numerose schermate consecutive. Nella Web TV lo scorrimento
verticale è fatto esclusivamente a colpi di pulsanti di telecomando (poiché non
esiste il mouse), con un'azione ripetitiva che diventa facilmente noiosa. Non
sono disponibili, inne, i comuni plug-in, quali il Flash e il Reader di Adobe.
2.1.5
L'inaccessibilitá del web
L'inaccessibilitá non è una prerogativa ed un'esclusiva delle persone disabili;
infatti un comune utente normodotato potrebbe avere dicoltá nel visualizzare
o nel navigare in un sito web. Questo perché, come si è visto in questo capitolo,
esistono diversi canali comunicativi ed ancora piú software o tool per accedere
da questi al web. Ogni browser, per esempio, utilizza un proprio motore di
rendering che interpreta in modo dierente dagli altri alcuni tag o alcune regole
tipiche del web. Puó quindi succedere che un utente di un determinato browser
riesca a visualizzare la pagina web a cui è interessato senza problemi, mentre
un altro potrebbe non avere lo stesso privilegio. Non è detto che un sito
Internet sia visualizzato nello stesso modo sia da Mozilla Firefox che da Internet
Explorer (solo per nominare i piú diusi), infatti, come si è visto, quest'ultimo
interpreta erroneamente alcune direttive (per esempio) del box model dei CSS.
Un altro caso di inaccessibilitá puó presentarsi quando un utente cerca di
accedere da dispositivo mobile ad un'applicazione web pensata e creata per
2.2 Utente con disabilitá visive
16
un normale desktop PC; in questo caso la navigazione sarebbe tutt'altro che
garantita. L'unico metodo per garantire pari opportunitá di visualizzare lo
stesso sito a canali dierenti è quello di creare dei fogli di stile appositi per i
dispositivi mobili (questa parte verrá trattata ed approfondita nel paragrafo
6.5.2).
Un ultimo esempio di inaccessibilitá è la continua richiesta da parte di
qualche applicazione di plug-in mancanti all'utente. In questo caso questo
sará costretto a scaricare ed installare sul proprio PC i pacchetti software
necessari per la completa visualizzazione della pagina, spesso senza che questi
siano rmati o autenticati. A volte poi l'installazione dei plug-in potrebbe
anche fallire, precludendo al visitatore la visualizzazione dell'intero contenuto
della pagina o di una parte di essa.
2.2 Utente con disabilitá visive
Un utente con disabilitá alla vista è un utente al quale vengono preclusi i
contenuti visivi provenienti da molti dispositivi di output (come monitor o
stampante) e quindi spesso molti contenuti delle pagine web. Dal lato pratico
esistono peró molte soluzioni hardware o software che vengono incontro a questa categoria di utenza; sono inoltre presenti anche diversi accorgimenti che
un progettista del web puó osservare per migliorare l'accessibilitá della pagina
web da pubblicare, soprattutto per gli utenti con disabilitá alla vista.
Per venire in aiuto agli utenti con disabilitá visive sono state progettate
diverse tecnologie assistive, utili soprattutto per i non vedenti, oggi in uso; tali
tecnologie verranno trattate in questo paragrafo.
2.2.1
Tipologie di disabilitá visive
Esistono diverse disabilitá associate alla vista; di seguito verranno in breve
illustrate tre di queste: daltonismo, ipovisione e cecitá.
Daltonismo
Associare il daltonismo alle disabilitá visive forse è un po' eccessivo, ma questo
puó comunque portare alcuni imbarazzi e dicoltá all'utenza che ne sore.
Con il termine daltonismo si indica comunemente una forma di cecitá a uno
o a tutti i colori, determinata da diversi fattori: alterazioni ereditarie dei fotorecettori o coni (le piú diuse); danneggiamento della retina, del nervo ottico
o di determinate aree della corteccia cerebrale in seguito ad un trauma. Quando il daltonismo è dovuto al danneggiamento della corteccia celebrale, questo
puó manifestarsi solo in una parte del campo visivo. Non tutte le forme di
daltonismo sono denitive, soprattutto quelle non ereditarie. Geneticamente
2.2 Utente con disabilitá visive
17
questa malattia ai fotoricettori colpisce soprattutto gli uomini poiché è trasmessa dal cromosoma X; per questo motivo l'8% della popolazione maschile
è daltonica contro lo 0,4% di quella femminile.
I colori piú inclini al daltonismo sono il rosso ed il verde, per cui è bene
limitare l'uso di questi nelle pagine web. Non sono ancora note cure per le varie
forme di daltonismo, ma esistono diversi software appositamente dedicati a
coloro che sorono di daltonismo, cosí come esistono anche delle lenti correttive
per daltonici.
Ipovisione
A dierenza del daltonismo, l'ipovisone [34] è senza dubbio una disabilitá visiva. L'ipovisione è un'alterazione dell'apparato visivo umano che ha come
risultato un'acutezza visiva molto ridotta, la quale puó avere notevoli conseguenze sulla vita quotidiana. Questa disabilitá puó essere causata da vari
fattori (siano essi congeniti o acquisiti). Il termine ipovisione è molto vario
ed indica diversi disturbi della vista molto diversi fra loro; disturbi che vanno
dalla visione sfocata, alla restrizione del campo visivo (come se si guardasse
attraverso un tubo) no alla comparsa di macchie scure. Spesso l'ipovisione
grave rappresenta un passaggio verso la cecitá, parziale o totale.
Esistono fondamentalmente cinque tipi di ipovisione [20]:
•
scotoma centrale:
•
ambliopia:
•
perdita della visione periferica:
è la perdita di funzionalitá della macula lutea, cioè
di quella piccola area posta nella zona centrale della retina, dalla quale
dipende la massima acuitá visiva. Chi sore di scotoma centrale non puó
vedere ssando dritto gli oggetti, ma deve imparare a guardare di lato,
sopra o sotto. Deve usare cioè la visione periferica, la quale (interessando
una zona della retina con minore capacitá di vedere i dettagli e i colori)
porta a un degrado e a un rimpicciolimento dell'immagine osservata:
ecco dunque la necessitá di forti ingrandimenti del testo, nel tentativo di
compensare il problema.
è una forte riduzione della sensibilitá centrale della retina,
senza riduzione del campo visivo e senza evidenti lesioni organiche dell'occhio. Dipende da vizi della visione non corretti (miopia o ipermetropia
gravi) o da malattie degenerative come il diabete.
è causata per lo piú da glaucoma
cronico o da retinite pigmentosa e consiste in una visione limitata alla
zona centrale della retina. Nella lettura, e quindi nell'uso del computer,
chi è aetto da questo tipo di ipovisione puó leggere solo poche lettere
per volta, meno anche della lunghezza di una singola parola. Ció rende
la lettura molto lenta e faticosa. Nella navigazione sul Web, la perdita
del contesto (no al punto di perdere il segno nel passaggio da una riga
alla successiva) è una conseguenza molto comune. La limitazione della
2.2 Utente con disabilitá visive
18
zona visiva alla zona centrale non permette all'utente aetto da questo
tipo di ipovisione di visualizzare per intero la pagina, per cui è molto
importante prevedere degli accorgimenti in fase di progettazione della
pagina web, volti ad evitare (per quanto possibile) la comparsa della
barra di scorrimento orizzontale.
•
nistagmo anomalo:
•
decit paracentrali:
è l'incapacitá di controllare il movimento degli
occhi. Chi è aetto da nistagmo anomalo non è in grado di leggere
muovendo solo gli occhi, deve perció imparare a leggere muovendo la
testa invece degli occhi, cercando allo stesso tempo di tenere lo sguardo
il piú possibile sso nella posizione in cui il nistagmo è meno fastidioso.
è presente quando la zona della macula intorno
alla fovea2 presenta un'edema (un accumulo di liquidi nel tessuto) che
rende molto bassa l'acuitá visiva paracentrale, cioè nella zona della macula esterna alla fovea; sono invece discretamente conservate la visione
centrale e quella periferica. Chi sore di decit paracentrali, ha dicoltá
di lettura dovute al fatto di poter leggere solo poche lettere contigue alla
volta ad ogni ssazione dello sguardo.
Cecitá
La cecitá è sicuramente la disabilitá visiva piú grave, ed è la condizione a
causa della quale è impossibile avere una percezione ottico-visiva. Puó essere
congenita oppure derivata da aezioni all'apparato visivo o da traumi. Coloro
che sono aetti da questa, che è considerata una vera e propria malattia, (e che
sono quindi completamente o quasi completamente privi della vista) vengono
chiamati non vedenti o ciechi. A dierenza dei daltonici e degli ipovedenti, i
non vedenti hanno assolutamente precluso l'output visivo, in qualsiasi forma.
2.2.2
Tecnologie assistive
Gli utenti del web con delle disabilitá visive temporanee o denitive accedono
allo stesso principalmente utilizzando l'home PC ed i dispositivi mobili. Poiché
tali canali sono stati giá spiegati per gli utenti normodotati, in questo capitolo
verranno mostrate solo le tecnologie hardware e software capaci di aiutare
l'utente con disabilitá visive; lo stesso discorso è valido anche per le altre
disabilitá.
Ovviamente questa particolare categoria di utente non puó utilizzare il
rendering graco a monitor e necessita quindi di diversi strumenti che siano
ad output vocale e/o tattile. Altrettanto ovvia è l'impossibilitá di utilizzare
il mouse come strumento di puntamento; viene perció richiesto all'utente di
individuare con la tastiera l'oggetto sul quale spostare il focus. In particolare
di seguito verranno illustrate le seguenti tecnologie assistive: Screen reader,
2
piccola porzione della retina nella quale è massima l'acuitá visiva
2.2 Utente con disabilitá visive
19
Browser testuali, Voice Browser, Screen magnication, Display e stampanti
Braille, Tecnologie assistive per dispositivi mobili.
Screen Reader
Uno screen reader, o lettore di schermo, è un software capace di tradurre i
contenuti presenti sul monitor di un computer in una forma dierente da quella
graca, solitamente vocale, con le parole pronunciate da una voce sintetica,
ma puó anche restituire un output sotto forma tattile, se i contenuti vengono
tradotti in testo Braille inviato ad un dispositivo apposito. Grazie a questa
sua capacitá, lo screen reader è la via di accesso privilegiata dai non vedenti,
non solo ai contenuti del Web, ma all'uso del computer in generale.
La traduzione del contenuto visivo di una pagina web da parte di uno screen
reader presenta una grandissima dierenza rispetto alla visione standard: l'accesso alle informazioni non avviene in parallelo ma in maniera sequenziale.
Esistono due diverse modalitá di accesso ai contenuti di una pagina:
•
Accesso parallelo: è la modalitá standard di accesso alle informazioni
prevista per gli utenti vedenti. Utilizza il monitor come canale di output
per visualizzare le informazioni richieste dall'utente. Con l'accesso parallelo l'utente è in grado di percepire istantaneamente l'organizzazione
della pagina o dell'applicazione, e di focalizzare l'attenzione in brevissimo
tempo sull'argomento ricercato.
•
Accesso sequenziale:
è la modalitá di accesso utilizzata dagli utenti
non vedenti. Questo tipo di accesso alle informazioni avviene principalmente attraverso dispositivi vocali capaci di leggere i contenuti presenti
nella pagina web all'utente impossibilitato a farlo. L'accesso sequenziale
prevede che la pagina web vanga letta riga per riga, partendo dalla prima in alto no all'ultima in fondo; questo procedimento non permette
perció all'utente di avere una conoscenza completa della stuttura della
pagina nché la lettura della stessa non sia terminata. Inoltre l'utente
con l'accesso sequenziale, prima di accedere ai contenuti desiderati, deve
necessariamente ascoltare tutto il contenuto precedente della pagina. È
evidente come l'accesso sequenziale sia notevolmente piú lungo nei tempi
di lettura e di accesso alle informazioni, piú faticoso e scomodo.
Gli screen reader utilizzano necessariamente l'accesso sequenziale per permettere all'utente di usufruire delle informazioni alle quali è interessato; questa
tecnologia assistiva peró ore all'utente non vedente anche diverse funzioni che
permettono di attivare vere e proprie scorciatoie, come la possibilitá di saltare da un link all'altro o da un paragrafo all'altro, oppure la possibilitá di
esplorare selettivamente le tabelle.
Altre scorciatoie software sono a discrezione del progettista del web che puó
ulteriormente facilitare la navigazione nei siti agli screen reader con soluzioni
come la skip navigation (paragrafo 6.6).
2.2 Utente con disabilitá visive
20
Lo screen reader piú noto ed utilizzato è sicuramente JAWS (di Freedom
Scientic) [35], il quale ore all'utente una vasta gamma di scorciatoie da
tastiera capaci di coprire molte delle esigenze di esplorazione dei contenuti e
di esecuzione dei comandi. Sono peró due i limiti principali di JAWS, uno è
certamente quello di essere un prodotto monopiattaforma (distribuito solo per
i sistemi operativi Microsoft Windows), l'altro è senza dubbio il prezzo della
licenza d'uso (che puó costare anche alcune migliaia di euro).
Uno dei principali antagonisti di JAWS è Window-Eyes (di GW Micro)
[36] che supporta ecacemente sia Internet Explorer che Mozilla Firefox, ma
anche le principali applicazioni del pacchetto Oce. Anche per Windows-Eyes
la licenza d'uso non è gratuita; in questo caso peró l'azienda produttrice, attraverso il proprio sito web, da la possibilitá di scaricare e provare una versione
demo di questo screen-reader.
Un altro screen reader per sistemi operativi Windows (ma gratuito ed open
source) è NVDA (Non Visual Desktop Access, accesso non visuale al desktop ) [37]. Una delle principali innovazioni di NVDA è quella di rendere il
software completamente indipendente dalle funzioni della scheda graca, dai
suoi driver e perció dalle modalitá di visualizzazione impostate nel sistema;
questo permette un uso immediato dello screen reader.
Esistono peró anche screen reader sviluppati per sistemi operativi dierenti
da Windows, uno di questi è Orca [38]. Orca è gratuito, Open Source, essibile, estensibile, potente ed è preinstallato di default in numerose distribuzioni
di Linux basate sulla piattaforma GNOME (tra cui Ubuntu). Questo screen
reader, a dierenza dei precednti, non ore solo funzioni di lettura dello schermo, ma fornisce anche una gamma completa di ausili per l'accessibilitá, che
comprende, oltre alle funzioni tipiche di uno screen reader, anche l'ingranditore
di schermo ed il supporto per il Braille. La politica dell'open source ha fatto
in modo che Orca sia integrabile con browser come Firefox, con programmi di
posta elettronica come Thunderbird e con applicazioni di produttivitá come
OpenOce.
Browser testuali
I browser testuali rappresentano per il web la pietra miliare dello sviluppo,
questi infatti sono stati i primi programmi specici per la navigazione nel web.
Esistono ancora ai giorni d'oggi diversi browser testuali sopravissuti all'avvento, iniziato nel 1993, dei browser graci (il primo, dalla quale si sono poi evoluti
tutti gli altri è stato Mosaic). Oggi queste applicazioni sono inserite, anche se
un po' impropriamente, tra le tecnologie assistive poiché vengono utilizzate
principalmente da utenti con disabilitá alla vista e perché da sole coprono buona parte delle nalitá dell'accessibilitá. Per far sí che un sito sia accessibile
anche dai browser testuali è importante mantenere la gerarchia degli oggetti
della pagina da renderizzare ed associare sempre un signicato alternativo ad
elementi graci (anche per quelli non indispensabili).
2.2 Utente con disabilitá visive
21
Un browser testuale interagisce con l'utente principalmente attraverso l'uso
della tastiera ed elimina automaticamente tutti gli elementi graci presenti
in un documento web, mostrando all'utente solo i testi o le descrizioni testuali
alternative (di elementi graci e multimediali) in esso contenuti.
Il primo browser testuale (precedente al 1993), nonché il piú noto, è certamente Lynx [39] che è un prodotto multipiattaforma (Unix, Linux, DOS,
Windows e Macintosh).
Il principale antagonista è molto piú recente di Lynx (1999) ed è quasi un
suo ominimo: Links [40]. A dierenza di Lynx, questo browser, presenta anche
delle caratteristiche tipiche dei browser visuali, infatti riesce a mantenere in
un ambiente puramente testuale, per esempio, la suddivisione delle tabelle in
righe e colonne. Anche Links è multipiattaforma ed è disponibile per Linux,
OS/2, Windows, BeOS e FreeBSD.
Esistono peró anche browser testuali pensati apposta per l'accessibilitá,
uno di questi è WebbIE [41], il quale è capace di riprodurre una pagina web
sia in modalitá solo testo sia in modalitá graca, utilizzando per quest'ultima
funzione il motore di rendering di Internet Explorer (Trident). Questo browser
puó essere utilizzato da tutte le categorie di disabili alla vista poiché presenta,
in modalitá graca, anche una funzione d'ingrandimento dei contenuti, utile
per gli ipovedenti (anche se questa funzione fa aumentare la larghezza proporzionalmente con l'altezza, portandosi inevitabilmente la fastidiosissima barra
di scorrimento orizzontale). Per i non vedenti WebbIE è un compagno ottimale
per uno screen reader poiché linearizza i contenuti suddividendoli per categorie
strutturali: link, titoli, tabelle, elenchi, caselle di input ecc.
Altri browser puramente testuali sono w3m [42], Emacs-w3m (una versione di w3m per Emacs), Elinks [43] (un'evoluzione di Links in grado di riprodurre frame e tabelle), Alynx [44] (versione di Lynx per computer Amiga)
e Netrik [45] (nato da un progetto collaborativo di SourceForge.net). Non solo
i browser testuali sono in grado di linearizzare i contenuti del web, ma esistono
anche alcuni browser graci che dispongono di questa funzione, uno di questi
è Opera, il quale permette di scegliere se visualizzare o meno le immagini.
Voice Browser
Il voice browser, come un browser tradizionale, utilizza le combinazioni tra
il linguaggio (X)HTML e la tastiera o il mouse, per permettere all'utente di
interrogare il Web. Le pagine web che di piú si adattano a questa tecnologia
sono quelle scritte in VoiceXML3 . I Voice browser presentano all'utente le informazioni oralmente utilizzando dei le audio pre-registrati oppure particolari
software text-to-speech che renderizzano le informazioni sotto forma di audio;
l'interazione utente-web puó avvenire attraverso tastiera o mediante comandi
3
acronimo di Voice eXensible Markup Language, rappresenta lo standard W3C, in formato
XML, per la creazione di dialoghi interattivi tra una persona e un computer
2.2 Utente con disabilitá visive
22
vocali, utilizzabili tramite il microfono del computer, o di un telefono Voip o
di un cellulare.
Screen magnication
Quella dello screen magnigication [20] è una tecnologia assistiva indicata soprattutto agli ipovedenti, in grado di ingrandire (anche secondo diverse modalitá) in tutto o in parte i contenuti del monitor. I principali ingranditori di
schermo dispongono anche di funzioni di lettura vocale, che possono essere utilizzate in combinazione con la funzione principale di magnication per rendere
ancor piú agevole e sicura la navigazione nel web o l'utilizzo del PC.
Esistono diversi ingranditori di schermo, i piú noti sono ZoomText [46],
MAGic di Freedom Scientic (la stessa di JAWS) [47], Lunar di Dolphin [48]
e suo fratello maggiore LunarPlus [49]. Tutti (tranne Lunar) possono essere
installati in associazione ad un lettore di schermo, cosí da poterne aumentare le
funzionalitá. Anche il sistema operativo Windows contiene di default un tool
di magniers che il sistema operativo ore tra le opzioni di accesso facilitato.
Display e stampanti Braille
Il Braille è la forma di scrittura a rilievo pensata per i non vedenti, generalmente
composta da 6 punti che, a seconda della combinazione, formano i caratteri
di un documento. Un utente non vedente attraverso il linguaggio Braille puó
leggere un testo attraverso i polpastrelli anziché la vista.
La tecnologia assistiva che puó essere utilizzata da un non vedente per la
navigazione attraverso il computer consiste in una tavoletta costituita da una
riga di 40 o 80 celle Braille, fatta ognuna da otto (invece che da sei) punti a rilievo, chiamata Display Braille [20]. I due punti in piú possono essere
impostati per comunicare all'utente le formattazioni adottate sul testo come
il grassetto, il corsivo, il sottolineato o altro. Questo dispositivo utilizza un
meccanismo piezoelettrico che fa automaticamente alzare ed abbassare continuamente i punti, riproducendo sulla barra i contenuti presenti sul monitor,
come le lettere alfabetiche, la punteggiatura e, nei dispositivi piú sosticati,
anche elementi graci della pagina come i bordi. Le barre Braille non sono
solamente dispositivi di output tattile (attraverso i punti a rilievo), ma spesso
fungono anche da dispositivo di input e sono dotati di diversi tasti funzione
che possono attivare delle scorciatoie per una navigazione rapida della pagina.
I display Braille sono solitamente utilizzati in coppia con gli screen reader,
ma sono sostanzialmente molto meno diusi di questi principalmente per due
fattori: non tutti i non vedenti sono capaci di leggere il Braille ed il costo
elevato di questi dispositivi (anche diverse migliaia di Euro).
Un altra tecnologia assistiva per utenti non vedenti, simile alla precedente, è
la stampante Braille che è di fatto lo strumento piú avanzato per produrre materiale in Braille. Un testo scritto al computer puó essere facilmente stampato
2.2 Utente con disabilitá visive
23
in Braille utilizzando degli appositi programmi di traduzione e formattazione.
Anche le stampanti Braille si dierenziano in varie tipologie in base a delle
caratteristiche come la velocitá di stampa, la quantitá del materiale che sono
in grado di stampare e la possibilitá di produrre stampe ad interpunto, cioè su
entambi i lati della pagina.
Tecnologie assistive per dispositivi mobili
Gli utenti con disabilitá alla vista possono utilizzare anche i dispositivi mobili,
i quali non brillano certo per accessibilitá. Esistono peró diversi strumenti
software capaci di aiutare l'utente con problemi gravi alla vista. Una soluzione
software a tutto tondo è certamente la Suite di Accessibilitá di Nuance che è
composta da due applicativi: Talks e Zooms [50]. Il primo è uno screen reader
in grado di aiutare l'utente nelle operazioni presenti in un cellulare di ultima
generazione, operazioni che possono andare dalla scrittura di un SMS, alla
lettura del nominativo della chiamata in entrata. Il secondo, Zooms, di fatto
consiste in un ingranditore di schermo, capace di ingrandire porzioni (anche
selezionabili dall'utente) di contenuti della pagina. Questa suite di software
non è peró ancora disponibile ed installabile su tutti i dispositivi mobili.
Talks non è l'unico lettore di schermo per dispositivi mobili, infatti ne
esistono anche altri, uno di questi è Mobile Speak (di Code Factory) [51],
disponibile per diversi sistemi operativi (Symbian e Windows Mobile), un altro è invece VoiceSuite [52], progettato unicamente per il sistema operativo
Microsoft Windows Mobile.
2.2.3
Esempi di inaccessibilitá
Di seguito verranno descritti tre esempi di inaccessibilitá del web rispetto a
persone con disabilitá visive.
La struttura della pagina e lo screen reader
Nei paragra precedenti è stato spiegato come uno screen reader abbia la necessitá di linearizzare il contenuto di una pagina. Anché un lettore di schermo
sia pienamente funzionale e la navigazione leggera e veloce, un'applicazione
web deve essere progettata utilizzando correttamente gli elementi (X)HTML
secondo il loro valore semantico, adottando meccanismi che possano permettere
di saltare gruppi di link ed utilizzando altri accorgimenti che possano favorire
l'accessibilitá.
Quando un'applicazione web viene creata senza tener conto di queste caratteristiche fondamentali, l'utilizzo di uno screen reader puó risultare problematico o quantomeno laborioso. A questo proposito, su un sito web italiano indirizzato all'accessibilitá [21] è stata pubblicata una dimostrazione di inaccessibilitá
di una pagina web di un noto quotidiano italiano. L'esperimento eettuato è
stato sviluppato sull'articolo del 28 Settembre 2006, intitolato Telecom, Prodi
2.2 Utente con disabilitá visive
24
alla Camera. Bagarre dell'opposizione attraverso uno screen-reader JAWS,
calcolando quante volte la voce sintetica nomini la parola chiave link, seguita
dal testo del collegamento e quanto duri la lettura completa della pagina; La
dimostrazione ha dato i seguenti risultati:
• 74 voci link lette prima di arrivare all'articolo;
• 3 minuti esatti occorsi alla sintesi vocale per leggere tutto ció che precede
il testo dell'articolo;
• 9 minuti e 30 secondi il tempo necessario alla lettura completa della
pagina.
Per la lettura dello stesso articolo, una persona vedente di media cultura
impiega poco piú di qualche istate per identicare l'inizio del testo (contro gli
otre 3 minuti di JAWS) e poco piú di due minuti e mezzo per leggere a mente
il testo dell'intero articolo (contro 9 minuti e mezzo). È molto semplice notare
le numerose dicoltá che un utente non vedente puó riscontrare per la lettura
di una pagina web non realizzata a dovere in materia di accessibilitá, rispetto
ad un utente in grado di utilizzare la vista.
Le tabelle
Uno degli ostacoli piú dicili da arontare per uno screen reader è quello
di leggere ed interpretare una tabella [53]; questi non tiene conto della sua
composizione in righe e colonne, ma solo ed esclusivamente delle prime, da
quelle della prima riga, no a quelle dell'ultima, ognuna visualizzata su una
riga separata. Come risultato l'utente si ritrova una serie di elementi posti
in verticale, uno sotto l'altro che sono la rapresentazione delle colonne di una
tabella. Per rendere meglio l'idea, è mostrato un piccolo esempio (tabella
2.2) di una tabella a tre colonne contenenti ognuna rispettivamente il nome, il
cognome e la professione di una persona.
Nome Cognome Professione
Mario
Marco
Rossi
Verdi
Studente
Studente
Tabella 2.2: Esempio di tabella
Questa tabella viene visualizzata da uno screen reader nel seguente modo:
tabella con 3 colonne e 3 righe
Nome
Cognome
Professione
2.2 Utente con disabilitá visive
25
Mario
Rossi
Studente
Marco
Verdi
Studente
fine tabella
In questo modo gli utenti con disabilitá visive non riescono ad associare
alcuna corrispondenza fra righe e colonne. Finché le dimensioni della tabella
sono ridotte non si pone nessun particolare problema, ma con una mole crescente di dati, le dicoltá di comprensione aumentano e diventa inevitabile che
si venga a creare una certa confusione fra gli elementi della tabella, nendo
per non comprenderne il contenuto.
La soluzione viene dalla tecnologia CSS e da un uso scrupoloso di XHTML,
che, se abbinati assieme, permettono di ridurre molti ostacoli inerenti alla lettura delle tabelle da parte di tecnologie assistive, aggirandoli o addirittura
evitandoli; purtoppo peró solo poche applicazioni web adottano gli accorgimenti necessari. Attraverso XHTML ogni riga o colonna puó avere associato
uno scope (cioè un ruolo), oppure ogni cella della tabella puó far riferimento
alla propria intestazione. In questo modo le celle della tabella sono logicamente
associate tra loro, e questo permette una maggior semplicitá di comprensione
nella lettura della tabella stessa. Attraverso i CSS è inoltre possibile impostare
(per esempio) ogni quante letture di riga ripetere una lettura dell'intestazione,
accorgimento che risulta molto utile con tabelle di dimensioni non trascurabili.
I CAPTCHA
Dietro al dicile nome di CAPTCHA4 [22] si nasconde uno dei piú clamorosi
casi di inaccessibilitá. Un CAPTCHA non è altro che un semplice sistema di
verica automatica che viene solitamente inserito nelle pagine web nelle quali
si richiede ad un utente di immettere i propri dati personali al ne di iscriversi al servizio. Questi sistemi sono composti da un'immagine bitmap e da
un campo di testo da riempire correttamente; l'immagine contiene solitamente una o piú parole disturbate da tracciati apparentemente messi a caso, ma
in realtá disposti ad arte. L'utente per confermare l'iscrizione deve necessariamente riconoscere il testo nascosto nell'immagine e scriverlo correttamente
nell'apposito spazio. Con questo sistema si cerca di impedire l'iscrizione al servizio a robot che mirano a carpire dati privati o a riempire i siti di pubblicitá
indesiderata, poiché si presume che solamente un utente umano possa riuscire
a distinguere correttamente la parola nascosta.
4
acronimo di Completely Automated Public Turing Test to Tell Computers and Humans
Apart
2.3 Utente con disabilitá uditive
26
È piuttosto evidente come un sistema del genere, basato sulla lettura di
un'immagine graca, sia del tutto inadatto per persone con disabilitá della vista. In pratica quello che viene fuori da questo sistema è un messaggio del tipo
o vedi o non puoi iscriverti, che è del tutto discriminante. Un utente ipovedente o non vedente, quando è presente un CAPTCHA, deve necessariamente
chiedere aiuto ad una persona vedente per poter completare l'operazione in
atto.
Negli ultimi tempi molte applicazioni web sembrano essersi accorte di questo problema ed oggi fortunatamente esistono diverse soluzioni. In alcuni casi
all'utente viene data la possibilitá di ricaricare l'immagine con una combinazione di colori dierente; il che è del tutto irrilevante ed inutile per un non
vedente, ma puó essere di aiuto ad un utente ipovedente o ad un daltonico.
Esistono peró anche delle soluzioni decisamente piú valide del cambio di colore,
come quella di associare all'immagine un le audio da ascoltare contenente la
parola nascosta. Un altro metodo è quello di spezzettare il codice CAPTCHA
con diversi commenti HTML contenenti cifre in grado di confondere i meccanismi di iscrizione automatica, ma non le tecnologie assistive come gli screen
reader; ovviamente questo metodo esula dall'uso di immagini bitmap. Il metodo piú semplice e forse piú ecace è quello di richiedere all'utente il risultato
di una semplice espressione numerica inserita nel corpo della pagina e non in
un'immagine bitmap. In tutti questi casi lo screen reader permetterebbe all'utente non vedente di aggirare il problema dei CAPTCHA e di completare
l'operazione in corso.
2.3 Utente con disabilitá uditive
La disabilitá uditiva coincide con la piú grave malattia dell'orecchio: la sorditá;
questa consiste nella perdita parziale o totale dell'udito e puó presentarsi alla
nascita o in seguito ad un trauma. Le persone aette da questa malattia (circa
il 2 % della popolazione in Italia [54]) utilizzano normalmente il linguaggio
italiano dei segni (LIS) che è a tutti gli eetti una vera e propria lingua.
Questa categoria di utenti non necessita di nessuna particolare tecnologia
assistiva hardware, ha peró precluso l'uso di output sonori che, nel limite del
possibile, devono essere tradotti in forma testuale da appositi sistemi software.
Esistono sostanzialmente due categorie di ausili software: sistemi di sottotitolatura automatica e sistemi di traduzione del parlato. Gli ausili del primo tipo
eseguono automaticamente l'attivitá di sottotitolatura, avendo cura di farla in
modo sincrono al usso dell'audio, che viene invece escluso. Il secondo tipo di
sistema software è decisamente piú complesso e richiede applicazioni multifunzionali sul modello di iCommunicator [55], un software in grado di tradurre
in tempo reale il parlato in testo scritto o in ALS (lingua americana dei segni),
grazie a complesse funzioni di riconoscimento vocale.
Anche per gli apparecchi mobili esistono dei sistemi ausiliari per questa
2.4 Utente con disabilitá motorie
27
categoria di utenti; uno di questi è RNID Mobile Textphone [56] che è
software in grado di trasformare un telefono cellulare in un testofonino, cioè
in un telefono per utenti sordi, capace di trasformare il testo scritto da tastiera,
in parole pronunciate da una voce sintetica, e le parole pronunciate dall'interlocutore, in testo visualizzato sul monitor del telefonino. Questo software non
è peró disponibile per molti dispositivi mobili, ma solo per un numero esiguo
di modelli.
2.4 Utente con disabilitá motorie
Questa categoria di utenti racchiude un assortito insieme di persone aette
da dierenti patologie dell'apparato motorio come la paralisi cerebrale, la tetraplegia, il morbo di Alzheimer, la sclerosi laterale amiotroca, la distroa
muscolare, la sindrome del tunnel carpale, o tremori di varia origine e natura. Questi utenti hanno preclusi quasi tutti i sistemi di input tradizionali, in
particolare non possono utilizzare (o possono farlo molto limitatamente) né
sistemi di puntamento (come mouse o trackball), né la tastiera; nei casi piú
gravi, l'utente ha la possibilitá di muovere solamente gli occhi.
Anché gli utenti con queste disabilitá possano realmente interagire con il
web, le applicazioni in questione devono assolutamente essere indipendenti dal
device utilizzato; l'applicazione deve perció essere raggiungibile e deve essere
in grado di interagire sia con il mouse, sia con la tastiera, che con qualunque
altro dispositivo necessario.
Per venire incontro a chi possiede disabilitá motorie, sono state pensate e
realizzate diverse soluzioni hardware e software ad hoc. Per quanto riguarda
le teconologie hardware, queste consistono in tastiere, mouse e trackball speciali, in schermi tattili (touch screen), in sensori di vario tipo oppure in sistemi
di puntamento a testa o guidati dal movimento delle labbra. Una tecnologia assistiva molto complessa si basa su un sistema di puntamento a testa, il
quale utilizza una telecamera montata sulla cornice del monitor per tracciare
i micromovimenti di un punto preciso della testa dell'utente preso come target; tali micromovimenti vengono poi tradotti in spostamenti del cursore sullo
schermo. Come giá accennato, spesso non sono sucienti i soli sistemi hardware, ma questi necessitano di ulteriori soluzioni software. Tra i software piú
conosciuti ed utilizzati, vi sono gli ausili per i mouse e per le tastiere virtuali
come MagicCursor 2000 [57]. Questo software permette di simulare tutte
le funzioni di un mouse semplicemente attraverso lo spostamento del cursore
e mediante delle temporizzazioni predenite. Lo spostamento del cursore puó
avvenire attraverso dei sistemi hardware come il puntatore a testa, mentre la
temporizzazione determina l'azione da eettuare in base a quanto tempo il
cursore rimane fermo su una zona attiva (come un pulsante o un menu) dello
schermo. Ovviamente MagicCursor permette sia di impostare i tempi abbinati
alle varie funzioni, sia di eseguire tutte le diverse funzioni associate al mouse.
2.5 Utente con disabilitá cognitive
28
2.5 Utente con disabilitá cognitive
Le disabilitá cognitive sono le piú dicili da denire poiché sono molte e possiedono molte varianti; queste possono essere dovute a disabilitá siche o psichiche
di un determinato individuo. Le disabilitá cognitive possono essere dovute a
varie cause:
• malattie come meningite o tumore;
• questioni genetiche come la sindrome di Down, la demenza o l'autismo;
• patologie come il morbo di Alzheimer, l'ictus celebrale, la dislessia, la
sclerosi multipla, i disturbi dell'attenzione o l'iperattivitá;
• danni celebrali dovuti ad un incidente
• altre cause come i problemi all'apprendimento, la perdita di memoria,
l'incapacitá di leggere, l'eccessiva tendenza a distrarsi, i disturbi dell'orientamento e la dicoltá nel seguire un discorso logico.
Dal punto di vista software, le tecnologie assistive usate per compensare i
decit cognitivi si basano fondamentalmente su tre principi:
• la lettura vocale dei contenuti testuali, associata all'evidenziazione delle
parole di volta in volta lette e, nei programmi piú sosticati, la possibilitá
di impartire comandi vocali;
• la predizione della parola o della frase che l'utente sta scrivendo;
• l'associazione di immagini a testi e comandi, allo scopo di favorire la
comprensione e l'interazione da parte dell'utente.
Per quanto riguarda le tecnologie assistive hardware presenti per questi
utenti, ne esistono diverse: computer portatili e palmari specializzati nel fornire una serie di segnali acustici e visivi, che servono per ricordare scadenze e
procedure all'utente che sore di perdite di memoria; dispositivi dotati di interfacce tattili basate su simboli graci, che sfruttano il potere evocativo delle
immagini per aiutare l'utente a comprendere concetti e comandi; funzioni di
sintesi vocale.
Per aiutare questa tipologia di utenti nella navigazione sul Web esistono
diversi prodotti software creati ad hoc, uno è ReadingBar 2 (di ReadPlease)
[58] che consiste in un plug-in per Internet Explorer che consente la lettura
vocale e l'evidenziazione di ogni parola durante la sua lettura. Gracamente
consiste in una serie di pulsanti (posti generalmente sotto la barra degli indirizzi
del browser), ognuno dei quali è associato ad una diversa funzione. Tra le
funzioni disponibili, c'è l'avanzamento veloce tra i contenuti, la possibilitá di
selezionare parte del testo e di farlo leggere in un'interfaccia apposita attivabile
anche come nestra pop-up, la possibilitá di salvare i contenuti come testo
2.5 Utente con disabilitá cognitive
29
semplice o come le audio in formato MP3 per riascoltarli successivamente, la
possibilitá di ingrandire il testo, per rendere piú semplice l'individuazione delle
parole sottolineate durante la lettura vocale.
Un altro ausilio per decit cognitivi è Dragon Naturally Speaking (di
Nuance) [59], che è un software molto sosticato e potente, che abbina alle
funzioni di lettura vocale e di evidenziazione dei testi, la gestione della scrittura
con l'interazione col computer per mezzo di comandi vocali. La navigazione
sul web puó avvenire anche senza aver la necessitá di utilizzare né il mouse né
la tastiera. Questo software è inoltre in grado di riconoscere i moduli contenuti
in una pagina web, di rilevarne tutti i componenti (menu di selezione, caselle
radio, campi di immissione testo, pulsanti di invio, eccetera) e di evidenziarli,
ciascuno con un diverso numero identicativo, attraverso il quale, mediante
appositi comandi vocali, l'utente ha la possibilitá di selezionare ogni singolo
campo e di svolgere in esso le operazioni appropriate.
Per quanto riguarda lo sviluppo di contenuti web, è necessario premettere
che ad oggi risulta impossibile fornire contenuti fruibili da tutti gli utenti con
disabilitá cognitive, in quanto alcune sono talmente gravi da non consentire
la comprensione neppure di contenuti chiari e semplici. L'uso delle immagini
puó, per esempio, risultare utile per alcune categorie di disabilitá cognitive e
portare confusione e problemi nell'apprendimento per altre. Uno dei maggiori
problemi legati alle disabilitá cognitive è la dicoltá nell'apprendimento, in
particolar modo per quanto riguarda la dislessia.
Per questo è necessario utilizzare un linguaggio chiaro e semplice, che consentirebbe una maggior comprensione dei contenuti ad un numero maggiore di utenti. Per ottenere testi chiari e semplici è necessario seguire 4 must
imperativi:
• utilizzare parole non ambigue, per aiutare le persone a comprendere i
testi;
• utilizzare parole semplici, in modo che possano essere riconosciute da
utenti con il livello minimo di formazione. Per questo è buona norma
sostituire le parole complesse con altre piú semplici, capaci di esprimere
lo stesso signicato;
• evitare terminologie che non possano essere comprese da tutti, come termini gergali o frasi in altre lingue. Nel caso questo sia necessario, è
bene fornire una traduzione o un glossario informativo, magari attraverso RDF5 , strutturato in modo da poter aggiungere alle pagine glossari e
informazioni di supporto;
• usare regole grammaticali semplici come, per esempio la forma attiva dei
verbi anziché la passiva.
5
acronimo di Resource Description Framework, un nuovo protocollo sviluppato dal W3C
2.5 Utente con disabilitá cognitive
30
Non esistono peró ad oggi strumenti di valutazione e di test che possano vericare se un determinato sito web sia piú o meno accessibile ad utenti
con disabilitá cognitive. Dal punto di vista degli sviluppatori, realizzare siti
web accessibili a questa tipologia di utenti signica soprattutto seguire questi
quattro must e sviluppare attentamente l'organizzazione dei contenuti.
Capitolo 3
Accessibilitá del web
3.1 Denizione di accessibilitá
Il web è denito accessibile quando è in grado di dare alle persone disabili la
possibilitá di percepire, comprendere, navigare, interagire, ed esprimere il proprio contributo. Quando si parla di accessibilitá del web vengono considerati
tutti i tipi di disabilitá, sia che si parli di disabilitá dovute alla vista, all'udito,
siche, della parola, cognitive o neurologiche; nella casistica sono ricomprese
anche le persone piú anziane che spesso sono in possesso di limiti dovuti all'etá. Esistono oggi molti siti e software che rappresentano o implementano delle
vere e proprie barriere rispetto ai disabili e rendono a questi dicile, se non
impossibile, utilizzare il web. Fortunatamente peró sono disponibili diversi siti,
software o hardware creati ad hoc per utenti disabili.
L'accessibilitá del web è un aspetto molto importante nel quotidiano in
quanto ormai Internet contiene elementi riferibili agli ambienti educativi, allo
sviluppo, al government, al commerciale ed a molto altro. Il web deve essere
reso il piú possibile accessibile per poter fornire a tutti gli utenti pari accessi e
pari opportunitá sia che questi siano utenti normodotati oppure no, in modo
da poter dare a tutti la stessa possibilitá di partecipazione nella societá. L'accessibilitá del web deve essere valida indipendentemente dal sistema operativo,
dagli strumenti di navigazione, dalle impostazioni del browser e a prescindere
dalla velocitá di connessione di cui l'utente dispone.
Per essere accessibile un sito deve necessariamente soddisfare almeno la
raccomandazione XHTML 1.0 del W3C; in questo caso tale consorzio rilascia
e permette di inserire nell'applicazione web il logo mostrato in gura 3.1. Se
anche la parte riguardante i fogli di stile (CSS) viene soddisfatta secondo gli
standard deniti in proposito dal W3C, viene rilasciato dallo stesso consorzio
un analogo logo certicatore.
3.2 Linee guida del W3C
32
Figura 3.1: Loghi di certicazione del W3C
3.2 Linee guida del W3C
Il W3C Consortium propone, attraverso il WAI1 [60], delle linee guida da seguire per poter rendere il web piú accessibile: queste sono le WCAG [61]. Le
linee guida sull'accessibilitá dei contenuti web (WCAG, Web Content Accessibility Guidelines) coprono un ampio range di raccomandazioni per rendere i
contenuti web piú accessibili. Seguendo queste linee guida si possono rendere
i contenuti accessibili ad un'ampia fascia di persone con disabilitá, compresi
i non vedenti, gli ipovedenti, i non udenti, coloro con disabilitá dell'apprendimento, con limitazioni cognitive o di movimento, con dicoltá di linguaggio,
o con combinazioni di queste. Utilizzando le linee guida tracciate dal W3C
Consortium si possono anche rendere i contenuti web piú usabili per gli utenti
in generale. Le WCAG 2.0 sono state pubblicate di recente (3 Novembre 2008)
e sono un'evoluzione della versione 1.0 (a cui fanno riferimento) pubblicata dal
W3C nel Maggio 1999.
Di seguito sono elencate le direttive WCAG 2.0:
1.
Percezione:
le informazioni e l'interfaccia utente devono essere presentabili all'utente nella maniera in cui questi puó percepirle.
(a)
Testo alternativo : fornire del testo alternativo per ogni contenuto
non testuale cosí da poter essere trasformato in altra forma rispetto
alle necessitá dell'utente come large-print, braille, parlato, simboli
o linguaggio semplice;
Media temporali : fornire alternative per i media basati sul tempo;
(c) Adattabilitá : creare un contenuto che puó essere visualizzato in
(b)
diversi modi (per esempio un layout piú semplice) senza perdere
informazioni o parti strutturali;
(d)
2.
1
Distinguibilitá : rendere semplice per gli utenti la visione e l'ascolto
dei contenuti separando il primo piano dallo sfondo.
Operabilitá:
la navigazione e i componenti dell'interfaccia graca devono essere operabili.
(a)
Accessibilitá da tastiera : rendere tutte le funzionalitá eseguibili
(b)
Tempistica : fornire all'utente tempo a sucienza per leggere e uti-
anche da tastiera.
lizzare il contenuto.
Web Accessibility Initiative
3.2 Linee guida del W3C
3.
33
(c)
Attacchi : non progettare il contenuto in modo che causi degli at-
(d)
Navigabilitá : fornire un modo per aiutare la navigabilitá dell'utente,
tacchi all'utente. Fanno parte di questo tipo di attacchi scritte o
immagini composte da luci in movimento oppure oggetti lampeggianti che potrebbero scatenare delle crisi ad utenti che sorono per
esempio di epilessia fotosensibile.
per ricercare contenuti e per determinare la posizione dell'utente nel
web.
Comprensibilitá: le informazioni e le operazioni dell'interfaccia graca
devono essere comprensibili.
Leggibilitá : rendere il contenuto testuale leggibile e comprensibile.
(b) Prevedibilitá : rendere la visualizzazione ed il funzionamento delle
(a)
pagine web prevedibili e coerenti.
(c)
4.
Assistenza per gli input : aiutare l'utente ad evitare e a corregge-
re gli errori, riducendo per quanto possibile il numero degli errori
irreversibili.
Robustezza:
il contenuto deve essere sucientemente robusto in modo
da poter essere interpretato con adabilitá da una grande varietá di user
agent, incluse le tecnologie assistive.
(a)
Compatibilitá : massimizzare la compatibilitá con gli user agent
presenti e con quelli futuri, comprese le tecnologie assistive.
Le WCAG 2.0 si applicano a tutte le tecnologie Web; questo garantisce che
il Web si mantenga aperto alle persone con disabilitá anche se si introducono
continuamente nuove tecnologie. Le WCAG 2.0 rappresentano il risultato di un
grandissimo lavoro collaborativo, e la loro forma nale è largamente supportata
dalle aziende, dalle organizzazioni di disabili, dalla ricerca e dai governi. Questo
equilibrio è essenziale anché le WCAG 2.0 si pongano come uno standard
internazionalmente condiviso per l'accessibilitá del Web.
Queste direttive sono ancora piuttosto recenti e non dispongono degli strumenti necessari per la validazione, per questo, per eettuare una verica di
accessibilitá, ci si deve riferire ancora alla prima versione: le WCAG 1.0.
L' Appendice A della versione 1.0 è interamente dedicata alla validazione,
ed esprime una raccomandazione generale rivolta agli autori di pagine web:
Vericate l'accessibilitá per mezzo di strumenti automatici e della revisione
umana. I metodi automatici sono in genere rapidi e convenienti ma non possono identicare tutti i problemi di accessibilitá. La revisione umana puó aiutare
a garantire la chiarezza del linguaggio e la semplicitá della navigazione .
Quando un sito web soddisfa tutti i requisiti delle direttiva WCAG 1.0, gli
autori possono esporre, sulle pagine vericate del sito, degli appositi bollini
3.3 Normative nazionali
34
di conformitá alle WCAG 1.0. Esistono 3 livelli di accessibilitá [62]: Level A,
Double A e Triple A, come mostrati in gura 3.2.
Figura 3.2: Loghi di certicazione WAI-WCAG 1.0
Nella creazione di un sito web accessibile, il primo livello deve essere sempre
soddisfatto, non soddisfarlo renderebbe i relativi contenuti del tutto inaccessibili per alcune categorie di utenti; il secondo livello dovrebbe essere soddisfatto
per non rendere dicoltoso l'accesso ai contenuti per alcune categorie di utenti; il terzo livello puó essere soddisfatto e la sua mancata applicazione puó, al
piú, rendere meno facili da utilizzare, ma non inaccessibili, i contenuti.
3.3 Normative nazionali
In ambito nazionale la legge in vigore in Italia è la Legge Stanca num. 4/2004
[63] pubblicata nella Gazzetta Uciale il 13 Gennaio 2004. Tale legge denisce all'articolo 2 l'accessibilitá come la capacitá dei sistemi informatici, nelle
forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e
fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che
a causa di disabilitá necessitano di tecnologie assistive o congurazioni particolari; denisce inoltre le tecnologie assistive come gli strumenti e le soluzioni
tecniche, hardware e software, che permettono alla persona disabile, superando o riducendo le condizioni di svantaggio, di accedere alle informazioni e ai
servizi erogati dai sistemi informatici. Sono due gli obiettivi e le nalitá che
la Legge Stanca si pregge (articolo 1):
1. La
Repubblica riconosce e tutela il diritto di ogni persona ad accedere a
tutte le fonti di informazione e ai relativi servizi, ivi compresi quelli che
si articolano attraverso gli strumenti informatici e telematici .
2. È tutelato e garantito,
in particolare, il diritto di accesso ai servizi informatici e telematici della pubblica amministrazione e ai servizi di pubblica
utilitá da parte delle persone disabili, in ottemperanza al principio di
uguaglianza ai sensi dell'articolo 3 della Costituzione .
I soggetti erogatori che, ai sensi dell'articolo 3 della legge, sono obbligati
ad applicare dette norme sono le pubbliche amministrazioni, gli enti pubblici
economici, le aziende private concessionarie di servizi pubblici, le aziende municipalizzate regionali, gli enti di assistenza e di riabilitazione pubblici, le aziende
di trasporto e di telecomunicazione a prevalente partecipazione di capitale pubblico e le aziende appaltatrici di servizi informatici. Sarebbe opportuno che
3.3 Normative nazionali
35
anche altre categorie di soggetti, come privati o aziende private applicassero i
contenuti tecnici deniti in tale legge.
Praticamente la legge Stanca denisce 22 requisiti [64] di accessibilitá per
i siti Internet:
Realizzare le pagine e gli oggetti al loro interno utilizzando
tecnologie denite da grammatiche formali pubblicate, nelle versioni piú
recenti disponibili quando sono supportate dai programmi utente. Utilizzare elementi ed attributi in modo conforme alle speciche, rispettandone
l'aspetto semantico.
1. Enunciato:
In particolare, per i linguaggi a marcatori HTML (HypertText Markup
Language) e XHTML (eXtensible HyperText Markup Language):
(a) Per tutti i siti di nuova realizzazione, utilizzare almeno la versione
4.01 dell'HTML o preferibilmente la versione 1.0 dell'XHTML, in
ogni caso con DTD (Document Type Denition - Denizione del
Tipo di Documento) di tipo Strict;
(b) Per i siti esistenti, in sede di prima applicazione, nel caso in cui
non sia possibile ottemperare al punto a) è consentito utilizzare la
versione dei linguaggi sopra indicati con DTD Transitional, ma con
le seguenti avvertenze:
i. evitare di utilizzare, all'interno del linguaggio a marcatori con il
quale la pagina è realizzata, elementi ed attributi per denirne
le caratteristiche presentazionali (per esempio, caratteristiche
dei caratteri del testo, colori del testo stesso e dello sfondo,
ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style
Sheets) per ottenere lo stesso eetto graco;
ii. evitare la generazione di nuove nestre; ove ció non fosse possibile, avvisare esplicitamente l'utente del cambiamento del focus;
iii. pianicare la transizione dell'intero sito alla versione con DTD
Strict del linguaggio utilizzato. Il piano di transizione va presentato alla Presidenza del Consiglio dei Ministri - Dipartimento per l'Innovazione e le Tecnologie da parte del responsabile
della accessibilitá informatica (Art. 9 Regolamento).
2. Enunciato: Non è consentito l'uso dei frame nella realizzazione di nuovi
siti.
In sede di prima applicazione, per i siti esistenti giá realizzati con frame,
è consentito l'uso di HTML 4.01 o XHTML 1.0 con DTD frameset, ma
con le seguenti avvertenze:
(a) evitare di utilizzare, all'interno del linguaggio a marcatori con il
quale la pagina è realizzata, elementi ed attributi per denirne le
3.3 Normative nazionali
36
caratteristiche presentazionali (per esempio, caratteristiche dei caratteri, del testo, colori del testo stesso e dello sfondo, ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per
ottenere lo stesso eetto graco;
(b) fare in modo che ogni frame abbia un titolo signicativo per facilitarne l'identicazione e la navigazione. Se necessario, descrivere
anche lo scopo dei frame e la loro relazione;
(c) pianicare la transizione a XHTML almeno nella versione 1.0 con
DTD Strict dell'intero sito. Il piano di transizione va presentato
alla Presidenza del Consiglio dei Ministri - Dipartimento per l'Innovazione e le Tecnologie da parte del responsabile della accessibilitá
informatica (Art. 9 Regolamento).
Fornire una alternativa testuale equivalente per ogni oggetto
non di testo presente in una pagina e garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati
anche i relativi contenuti equivalenti predisposti. L'alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla
funzione esercitata dall'oggetto originale nello specico contesto.
3. Enunciato:
Garantire che tutti gli elementi informativi e tutte le funzionalitá siano disponibili anche in assenza del particolare colore utilizzato
per presentarli nella pagina.
4. Enunciato:
Evitare oggetti e scritte lampeggianti o in movimento le cui
frequenze di intermittenza possano provocare disturbi da epilessia fotosensibile, disturbi della concentrazione o che possano causare il malfunzionamento delle tecnologie assistive utilizzate.
5. Enunciato:
Qualora esigenze informative richiedano comunque il loro utilizzo, avvisare l'utente del possibile rischio prima di presentarli e predisporre metodi
che consentano di evitare tali elementi.
Garantire che siano sempre distinguibili il contenuto informativo (foreground) e lo sfondo (background), ricorrendo a un suciente
contrasto (nel caso del testo) o a dierenti livelli sonori (in caso di parlato con sottofondo musicale).
6. Enunciato:
Un testo in forma di immagine in genere è da evitare ma, se non è
possibile farne a meno, deve essere realizzato con gli stessi criteri di
distinguibilitá indicati in precedenza.
Utilizzare mappe immagine sensibili di tipo lato client piuttosto che lato server, eccetto nel caso in cui le zone sensibili non possano
essere denite con una delle forme geometriche predenite indicate nella
DTD adottata.
7. Enunciato:
3.3 Normative nazionali
37
Se vengono utilizzate mappe immagine lato server, fornire i collegamenti di testo alternativi necessari per poter ottenere tutte
le informazioni o i servizi raggiungibili interagendo direttamente con la
mappa.
8. Enunciato:
Per le tabelle dati usare gli elementi (marcatori) e gli attributi
previsti dalla DTD adottata per descrivere i contenuti e identicare le
intestazioni di righe e colonne.
9. Enunciato:
Per le tabelle dati usare gli elementi (marcatori) e gli attributi
previsti nella DTD adottata per associare le celle di dati e le celle di
intestazione che hanno due o piú livelli logici di intestazione di righe o
colonne.
10. Enunciato:
Usare i fogli di stile per controllare la presentazione dei contenuti e organizzare le pagine in modo che possano essere lette anche
quando i fogli di stile siano disabilitati o non supportati.
11. Enunciato:
La presentazione e i contenuti testuali di una pagina devono potersi adattare alle dimensioni della nestra del browser utilizzata
dall'utente senza sovrapposizione degli oggetti presenti o perdita di informazioni tali da rendere incomprensibile il contenuto, anche in caso di ridimensionamento, ingrandimento o riduzione dell'area di visualizzazione
e/o dei caratteri rispetto ai valori predeniti di tali parametri.
12. Enunciato:
13. Enunciato:
Qualora si utilizzino le tabelle a scopo di impaginazione:
(a) garantire che il contenuto della tabella sia comprensibile anche quando questa viene letta in modo linearizzato;
(b) utilizzare gli elementi e gli attributi di una tabella rispettandone il
valore semantico denito nella specica del linguaggio a marcatori
utilizzato.
Nei moduli (form), associare in maniera esplicita le etichette ai rispettivi controlli, posizionandole in modo che per chi utilizza le
tecnologie assistive la compilazione dei campi sia agevolata.
14. Enunciato:
Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati.
15. Enunciato:
Se questo non è possibile:
(a) fornire una spiegazione della funzionalitá svolta;
(b) garantire una alternativa testuale equivalente in modo analogo a
quanto indicato nel requisito n. 3
3.3 Normative nazionali
38
Garantire che i gestori di eventi che attivano script, applet
oppure altri oggetti di programmazione o che possiedono una propria
specica interfaccia, siano indipendenti da uno specico dispositivo di
input.
16. Enunciato:
Garantire che le funzionalitá e le informazioni veicolate per
mezzo di oggetti di programmazione, oggetti che utilizzino tecnologie non
denite da grammatiche formali pubblicate, script e applet siano direttamente accessibili.
17. Enunciato:
Qualora un lmato o una presentazione multimediale siano
indispensabili per la completezza dell'informazione fornita o del servizio erogato, predisporre una alternativa testuale equivalente sincronizzata
in forma di sotto-titolazione e/o di descrizione vocale, oppure predisporre un riassunto o una semplice etichetta per ciascun elemento video o
multimediale, tenendo conto del livello di importanza e delle dicoltá di
realizzazione nel caso di presentazioni in tempo reale.
18. Enunciato:
Rendere chiara la destinazione di ciascun collegamento ipertestuale (link) con testi signicativi anche se letti indipendentemente dal
proprio contesto oppure associare ai collegamenti testi alternativi che possiedano analoghe caratteristiche esplicative. Prevedere meccanismi che
consentano di evitare la lettura ripetitiva di sequenze di collegamenti
comuni a piú pagine.
19. Enunciato:
Se per la fruizione del servizio erogato in una pagina è previsto un intervallo di tempo predenito entro il quale eseguire determinate
azioni, è necessario avvisare esplicitamente l'utente, indicando il tempo massimo utile e fornendo eventuali alternative per fruire del servizio
stesso.
20. Enunciato:
I collegamenti presenti in una pagina devono essere selezionabili e attivabili tramite comandi da tastiera, tecnologia in emulazione
di tastiera o tramite sistemi di puntamento diversi dal mouse.
21. Enunciato:
Per facilitare la selezione e l'attivazione dei collegamenti con queste tecnologie assistive è anche necessario garantire che:
(a) la distanza verticale di liste di link e la spaziatura orizzontale tra
link consecutivi sia di almeno 1 em;
(b) le distanze orizzontale e verticale tra i pulsanti di un modulo (form)
sia di almeno 1 em;
(c) le dimensioni dei pulsanti in un modulo (form) siano tali da rendere chiaramente leggibile l'etichetta in essi contenuta, per esempio
utilizzando opportunamente il margine tra l'etichetta e i bordi del
pulsante.
3.3 Normative nazionali
39
In sede di prima applicazione, per i siti esistenti, in ogni
pagina che non possa essere ricondotta al rispetto dei presenti requisiti,
fornire un collegamento a una pagina che li rispetti, contenga informazioni e funzionalitá equivalenti e sia aggiornata con la stessa frequenza
della pagina originale, evitando la creazione di pagine di solo testo.
22. Enunciato:
Il collegamento alla pagina accessibile deve essere proposto in modo
evidente all'inizio della pagina non accessibile.
Capitolo 4
Linguaggi del web
Come si è giá accennato, l'accessibilitá del web ruota intorno agli standard
deniti dal W3C, in particolare a 3 linguaggi: l'XML, l'HTML e i CSS. Di seguito verranno brevemente introdotti il linguaggio XHTML, che come vedremo
è un'evoluzione dell'HTML verso l'XML, i fogli di stile (i CSS) e verrá brevemente introdotto il linguaggio PHP che, a dierenza dei precedenti due, non
è uno standard del W3C, ma è indispensabile per il funzionamento di molte
applicazioni web.
4.1 XHTML
Prima della nascita dell'XHTML si faceva tutto con HTML: layout, stile, contenuto erano un tutt'uno ed erano implementati proprio da questo linguaggio.
In seguito è stato ritenuto piú funzionale separare il contenuto dalla presentazione e dalla logica di programmazione per poter avere progetti piú gestibili,
informazioni piú facili da ritrovare e siti piú accessibili e trasportabili su altri sistemi. La forza del nuovo linguaggio che veniva a nascere stava proprio
nell'integrazione dei singoli elementi.
Il 26 gennaio del 2000 il World Wide Web Consortium (W3C) rilasciava la
prima specica del linguaggio di markup destinato a sostituire l'HTML: nasceva cosí l'XHTML. In realtá la nuova specica di tale linguaggio occupava una
sola pagina poichè non deniva nuovi tag, elementi, o nient'altro di rivoluzionario rispetto all'HTML 4.0 che andava a sostituire. Questo fu comunque un
passo decisivo e fondamentale. L'elemento chiave é la X che dierenzia i due
nomi, poiché questa sta per EXTENSIBLE; cioè la stessa X su cui si fonda
un concetto fondamentale per la comunicazione digitale: l'XML (Extensible
Markup Language). Finiva cosí il tempo dell'anarchia nel web, cioè il tempo
del codice sporco ma basta che funzioni e degli elementi proprietari imposti.
In maniera piú semplicistica si potrebbe ricondurre il tutto ad una semplice
espressione:
XHTML = HTML + XML
4.1 XHTML
41
Dalla quale si puó facilmente vedere come l'XHTML sia la riformulazione
di HTML come applicazione XML. Anziché sfornare una nuova versione del
linguaggio HTML (la 5.0), il Consortium ha eseguito una vera e propria ridenizione: niente nuovi tag, attributi o metodi (rimasti essenzialmente quelli
di HTML 4.0). In pratica: il vocabolario è rimasto uguale, ma sono cambiate le regole sintattiche. In questo modo venivano soddisfatte due esigenze
fondamentali:
1. portare HTML nella famiglia XML con i beneci che ció comporta in
termini di estensibilitá e rigore sintattico.
2. mantenere la compatibilitá con i software che supportano HTML 4.0.
La versione 1.0 di XHTML è stata pubblicata il 26 gennaio 2000 e seguita
da una versione rivista dell'ottobre 2001. Questa è stata basata sulle tre DTD
giá denite per questo linguaggio:
• DTD Strict
• DTD Transitional
• DTD Frameset
Esiste poi anche una versione ridotta (l'XHTML Basic) specicamente
pensata per dispositivi mobili (PDA, cellulari), contenente solo gli elementi
che si adattano a questi dispositivi (esclude, ad esempio, i frames che non
hanno ovviamente senso in tale contesto) e destinata a sostituire WML come
linguaggio di base per le applicazioni WAP. La versione 1.1 di XHTML, basata
sulla DTD Strict della versione 1.0, rappresenta la prima formulazione pratica
del concetto di modularitá. In questa visione, gli elementi fondamentali (in
pratica l'insieme di tag che deniscono la struttura di un documento) sono
raggruppati in una serie di moduli indipendenti che possono essere implementati o esclusi secondo le necessitá. Secondo il W3C, la versione 1.1, è la base
della futura estensione di XHTML con altri set di linguaggi o moduli, anche
personalizzati.
Sono diversi i vantaggi derivati dall'utilizzo di XHTML; eccone alcuni:
1.
Codice pulito e ben strutturato : Il passaggio ad XHTML puó essere visto
come un ritorno alle origini. HTML è nato come linguaggio per denire
la struttura di un documento; senza aver nulla a che vedere con la presentazione. Tuttavia l'HTML è stato impiegato a svolgere compiti per
cui non era stato pensato ed addirittura manipolato nella forma. Il
caso delle tabelle è macroscopico: sono nate per la presentazione di dati
tabulari ma sono state impiegate come l'unico mezzo per costruire il layout della pagina. Altro esempio: quando fu sentita la necessitá di gestire
la tipograa dei documenti, venne introdotto il tag <font> con i relativi
attributi. La conseguenza si riveló essere quella di avere pagine cariche
4.1 XHTML
42
di elementi inutili, piú pesanti, dicili da modicare. La responsabilitá
principale per questo uso improprio di HTML non è da attribuire agli
sviluppatori poiché la tecnologia preposta a tale scopo (CSS1 denita nel
1996 dal W3C) non era ancora supportata dai browser, infatti ha iniziato
ad esserlo solo dal 2000-2001. Con XHTML, almeno nella sua versione
Strict, si torna ad un linguaggio che denisce solo la struttura. Risultato:
codice piú pulito, piú logico e piú gestibile.
2.
Portabilitá : La portabilitá è la capacitá/possibilitá di un documento di
essere visualizzato ed implementato ecacemente su diversi sistemi: PC,
PDA, cellulari WAP/GPRS, Web-TV, eccetera. Ora, se si pensa alle
limitazioni in termini di memoria, ampiezza dello schermo e usabilitá di
un terminale mobile, si capirá perché è importante un linguaggio essenziale, centrato sulla struttura del documento e privo di elementi inutili.
È essenziale avere una pagina ben impostata, nella quale sono ben deniti gli elementi: un titolo, un'intestazione, un paragrafo, una lista per
scandire gli argomenti. La piattaforma WAP 2 e tutta l'evoluzione dei
servizi mobili si fonderanno sull'integrazione tra XHTML e CSS, con il
supporto delle necessarie tecnologie sul lato server, come dichiarato dal
Wap Forum.
3.
Estensibilitá : Dal momento che XHTML ha ereditato anche l'estensibi-
4.
Accessibilitá : I documenti scritti in XHTML e validati sono naturalmen-
litá da XML è facilissimo incorporare in un documento parti scritte in
uno dei tanti linguaggi della famiglia XML; come per esempio formule
matematiche complesse dichiarando il namespace relativo al linguaggio
MathML (inserendo nella pagina i tag specici di quest'ultimo). I frutti
di questo approccio, che è il piú semplice dei tanti possibili, sono ancora
lontani dalla maturitá. L'implementazione da parte dei browser è infatti
carente, ma non mancano esempi funzionanti e di grande potenza. Esiste
infatti (di recente denizione) anche l'XForms, un linguaggio capace di
estendere in maniera impressionante l'uso dei classici form di HTML.
te piú accessibili di quelli scritti in HTML. Da una parte la validazione richiede l'uso obbligatorio di funzionalitá come il testo alternativo
per le immagini; dall'altra, una pagina che evita elementi non standard,
ben denita nella struttura è di gran lunga meglio gestibile da browser
alternativi come quelli vocali o testuali.
Un documento XHTML deve essere convalidato rispetto ad una delle tre
DTD XHTML del W3C; questo puó essere valido e ben formato (due concetti
fondamentali derivati da XML). Un documento si dice ben formato quando
rispetta le regole della sintassi XML, presenta cioè un elemento radice, un
corretto annidamento degli elementi, una chiusura obbligatoria dei tag vuoti,
eccetera. Si dice che un documento è valido quando usa correttamente un
4.1 XHTML
43
linguaggio e tutti gli elementi specici e consentiti. Queste regole vengono stabilite nella DTD (Document Type Denition), la quale ha il compito di identicare gli elementi (tag) consentiti, cosa questi signicano e come devono essere
trattati (ad esempio, stabilisce quali sono gli attributi possibili per ciascun
elemento). In un documento XHTML la DTD deve essere obbligatoriamente
specicata all'inizio.
Anché una pagina web sia conforme alle speciche del W3C, e dunque
validabile, è necessario, che questa dia esito positivo alla verica tramite il
parser SGML (che ne verica la correttezza semantica e sintattica); in questo
caso la pagina si dice conforme (in base alla DTD specicata) alla specica
HTML 4.1 [65] e XHTML 1.1 [66] e puó essere etichettata da un'apposita
immagine che ne garantisce la validitá (come giá visto nel paragrafo 3.1).
Il web non accenna a rallentare e continua ad evolversi, di conseguenza
anche i linguaggi si evolvono e nascono nuove versioni e nuovi standard; stanno infatti nascendo due nuove versioni di HTML e di XHTML: HTML 5 e
XHTML 2.0 [67]. Si inizia a parlare di XHTML 2.0 giá dal 5 Agosto 2002
con il primo Working Draft del W3C in proposito [68], il quale è stato seguito
ad altri Working Draft uciali, no all'ultimo in ordine temporale, quello del
26 Luglio 2006 [69]. Nonostante i diversi Working Draft questo linguaggio ad
oggi non è ancora utilizzato, i tempi tuttavia stanno maturando e l'avvento
di questa versione si sta sempre piú avvicinando, nonostante lo scetticismo
di molti che lo vedono come inadatto per il web. XHTML 2.0 porta diverse
innovazioni ed è stato pensato per sfruttare a pieno le potenzialitá della modularitá (attraverso il meccanismo dei nameframes e con nuovi standard W3C,
per esempio XForms e XFrames) e per essere focalizzato sempre di piú sulla
struttura e sempre meno sulla presentazione. Innovazioni importanti saranno
date dall'inserimento di elementi come <section> (elemento contenitore capace di denire delle gerarchie), <ln> (che permetterá la creazione di liste
di navigazioni), <separator/> (un separatore strutturale che permetterá di
abbandonare il separatore presentazionale <br/>), dall'inserimento degli attributi href e src per tutti gli elementi (il che renderá obsoleto l'elemento
<a>) e dall'eliminazione del tag <img> per le immagini (che sará sostituito
da un uso piú completo di <object>).
L'HTML 5 [70] rappresenta una transizione verso l'XHTML 2.0, tanto che
viene spesso denominato come X/HTML 5. Questo linguaggio si pregge
principalmente due scopi:
• Creare uno standard web meno rigido, piú essibile e piú compatibile rispetto al codice XHTML 2 per permettere la visualizzazione delle pagine
anche con la presenza di minimi errori nel codice
• Inserire il parsing dell'errore, facendo cosí in modo che gli errori presenti
nelle pagine web vengano corretti in ugual modo dai browser.
4.2 CSS
44
L'innovazione regina di HTML 5 è l'introduzione di nuovi elementi di blocco che permettono di creare in modo semplice ed immediato la struttura di
una pagina; questi nuovi elementi (<header>, <nav>, <section>, <article>,
<aside> e <footer>) hanno il compito di specializzare l'elemento di blocco
generico di denizione (<div>) in base al ruolo che devono avere nella pagina. Altre innovazioni sono date dall'inserimento dell'elemento <dialog> (il
quale rappresenta una conversazione e contiene gli elementi <dt> e <dd> che
identicano rispettivamente chi parla e cosa dice) e da <gure> con il suo elemento glio <legend> (i quali permetteranno di inserire delle didascalie alle
immagini). Rispetto ad XHTML 2.0 X/HTML 5, in futuro, potrá piú presumibilmente essere scelto da chi avrá necessitá di massima compatibilitá, anche
con le versioni precedenti di HTML.
4.2 CSS
Soprattutto con la nascita dell'XHTML, la logica di impaginazione del layout è
stata trasferita dal codice HTML ai fogli di stile (CSS), i contenuti separati dalla loro presentazione graca e l'elasticitá delle interfacce e la ridimensionabilitá
dei testi garantiti a qualunque livello di pagina. Dietro al semplice acronimo
CSS (Cascading Style Sheets - Fogli di stile a cascata) [71] si nasconde uno dei
fondamentali linguaggi standard del W3C. La sua storia cammina su binari
paralleli rispetto a quelli di HTML, di cui vuole essere l'ideale complemento.
Da sempre infatti, nelle intenzioni del Consortium, l'HTML avrebbe dovuto
essere visto semplicemente come un linguaggio strutturale, alieno a qualunque
scopo attinente la presentazione di un documento; in realtá a questo si è giunti
solo con l'XHTML. Il compito dei CSS è sintetizzabile in sole 5 parole: separare
il contenuto dalla presentazione.
Come la X per l'XHTML, l'innovazione di questa proposta è la parola
chiave Cascading che indica che è prevista ed incoraggiata la presenza di
fogli di stile multipli, che agiscono uno dopo l'altro, in cascata, per indicare
le caratteristiche tipograche e di layout di un documento HTML. La prima
specica uciale di CSS (CSS1) [72] risale al dicembre del 1996, mentre è del
maggio 1998 la seconda versione: CSS2 [73]. Quest'ultima non portó nessun
stravolgimento, ma molte aggiunte rispetto alla prima come nuove proprietá,
valori di proprietá e denizioni per stili non canonici come quelli rivolti alla
stampa o alla denizione di contenuti audio. È attualmente allo stato di Working Draft la nuova specica CSS3 [74]. Grazie ai CSS è possibile controllare
tutto ció che riguarda il layout della pagina, dal colore ai font, dall'interlinea alle decorazioni, dell'indentatura alla giusticazione del testo. Grazie all'avvento
dei CSS è possibile astrarsi completamente dal codice sorgente della pagina ed
impostarne la struttura senza doversi appoggiare all'uso di tabelle che appesantirebbero la pagina rendendola anche piú inaccessibile.
4.3 PHP
45
Sintatticamente un foglio di stile è composto da 4 elementi:
•
Proprietá, cioè una caratteristica di stile assegnabile ad un elemento
(CSS1 prevede 53 proprietá diverse, mentre CSS2 121). Sono per esempio
proprietá font-family e margin.
•
Statement, cioè l'indicazione di una proprietá CSS secondo la sintassi:
proprietá: valore:.
•
Selettore, cioè la specicazione di un elemento o di una classe di elementi
dell'albero (X)HTML al ne di associarvi delle caratteristiche CSS. I
selettori possono essere di tipo (per esempio body), di classe (E.bar o
E#bar), di prossimitá (E F, E>F o E + F), di attributi (E[foo] o
E[foo=bar]), di pseudo-classi (per esempio E:rst-child) e di pseudoelementi (E:rst-line)1 .
•
Regola, cioè un blocco di statement associati ad un elemento attraverso
l'uso di un selettore. Segue la sintassi selettore { statement; }, dove per
ogni selettore possono essere deniti piú statement elencati in sequenza.
•
@Regole, cioè 5 meta-indicazioni per la specica di ambiti o meta-regole
del foglio di stile: @import, @media, @font-face, @charset, @page.
Il funzionamento dei CSS si basa tutto sul Box model poiché la visualizzazione di un documento avviene identicando lo spazio di visualizzazione di
ciascun elemento. Ogni elemento è denito da una scatola (box) all'interno
della quale si trova il contenuto. Le scatole sono in relazione le une rispetto alle altre e posseggono diverse proprietá che ne deniscono la posizione, la
visualizzazione o gli elementi decorativi. Come è giá stato accennato nel Capitolo 2 la presentazione e la visualizzazione degli elementi di blocco (i box del
Box model) puó creare dei problemi, poiché alcuni browser (Internet Explorer
e derivati) interpretano male tale modello creando dierenze sostanziali rispetto ad altri software di navigazione. È perció buona norma, nella creazione
di una pagina web, testare la stessa su diversi browser oppure applicare degli
accorgimenti graci che possano aggirare questo problema.
4.3 PHP
Il PHP (il cui acronimo ricorsivo sta per Hypertext PreProcessor) è un linguaggio di scripting interpretato, con licenza open source e parzialmente libera. Originariamente è stato concepito per realizzare pagine web dinamiche, ma
attualmente è utilizzato principalmente per sviluppare applicazioni web lato
server; puó anche essere usato per scrivere script a linea di comando o applicazioni stand-alone con interfaccia graca. PHP nasce nel 1994 per opera di
1
Negli esempi si sono usati i valori E, F, foo e bar solo a scopo illustrativo, infatti
tali valori sono senza senso in (X)HTML/CSS
4.3 PHP
46
Rasmus Lerdorf, ma solamente dal 1998 comincia a diventare talmente maturo
da poter competere con ASP (un altro linguaggio lato server sviluppato da Microsoft) e da essere usato su larga scala. Attualmente PHP ha raggiunto la sua
quinta versione, la quale è stata sviluppata da un team di programmatori che
comprende ancora Lerdorf, il suo creatore. La popolaritá del linguaggio PHP
è in costante crescita grazie alla sua essibilitá; questa è data anche dal fatto
che PHP riprende per molti versi la sintassi del C e del Perl. È un linguaggio
a tipizzazione debole e dalla versione 5 migliora il supporto al paradigma della
programmazione ad oggetti. Certi costrutti derivati dal C, come gli operatori
fra bit e la gestione di stringhe come array, permettono in alcuni casi di agire
a basso livello; tuttavia è fondamentalmente un linguaggio di alto livello, caratteristica questa raorzata dall'esistenza delle sue moltissime API. PHP è in
grado di interfacciarsi ad innumerevoli database, tra tutti MySQL e Oracle, di
supportare numerose tecnologie, tra cui XML, SOAP, IMAP e FTP, di integrarsi con altri linguaggi/piattaforme quali Java e .NET. L'interazione di PHP
è forte soprattutto con Apache (del quale fornisce un'API specica), e con il
database MySQL (per il quale possiede numerosissime API).
Capitolo 5
ClaimStudentID
Web-based
tool for students' on-line identity management and web 2.0 content
aggregation .
Questa è la descrizione di ClaimStudentID [1] fornita dal suo autore. Piú
dettagliatamente ClaimStudentID è un tool web 2.0 di aggregazione di contenuti rilasciato dall'Universitá degli Studi di Urbino e rappresenta di fatto una
learning community dedicata agli studenti. Ogni utente ha la possibilitá di
associare alla propria identitá, certicata dall'Universitá, un prolo personale
e, soprattutto, una serie di collegamenti a contenuti Web 2.0 dei quali sono
autori e che sono presenti in rete. Il sistema consente poi ad utenti esterni
di eettuare ricerche su questi contenuti tramite le API1 messe a disposizione
dalle risorse Web sulle quali questi sono stati creati (Flickr e Google).
Spesso i tool di aggregazione di contenuti sono in grado di fornire una
identitá personale unica ad un utente, ma non sono altrettanto in grado di certicarla e quindi di garantire la reale identitá di una persona. ClaimStudentID,
al contrario, è in grado di poter certicare l'identitá di un suo utente poiché
sfrutta il fatto che l'Universitá di Urbino sia una istituzione e ne utilizza il
sistema informativo. Ogni studente per potersi creare un prolo deve necessariamente utilizzare l'username e la password forniti dall'Universitá al momento
dell'immatricolazione e memorizzati nell'IDMS2 . Poiché l'identitá dell'utente
è garantita e certicata, è possibile associare ad essa dei contenuti: da questa
premessa nasce ClaimStudentID.
Questa applicazione prevede:
• La verica dell'identitá di uno studente per certicare i suoi contenuti
personali
• La possibilitá per gli studenti di aggregare i propri contenuti associandoli
alla propria identitá certicata
1
2
Application Programming Interface, Interfaccia di Programmazione di un'Applicazione
IDentity Management System
5.1 People services
48
• La nascita di una community degli studenti dell'Universitá di Urbino
come conseguenza di questo servizio
• L'opportunitá da parte di un utente esterno di ricercare e visualizzare i
proli pubblici dei membri della community, di cercare i contenuti presenti nel servizio oppure quelli derivanti da una meta-ricerca basata sui
link aggregati dagli studenti
• Una crescita spontanea di conoscenza e di informazioni derivate dai
contenuti condivisi.
ClaimStudentID fornisce diversi servizi, ed in base a questi puó essere suddiviso in 3 parti: la prima si occupa dei servizi oerti agli utenti (People
services ), la seconda dell'aggregazione e condivisione dei contenuti (Content
aggregation services ) e la terza delle meta ricerche (Meta-search services ).
5.1 People services
I servizi oerti all'utente sono quelli di management del prolo e dell'identitá
personale. Come si è giá visto, ClaimStudentID è in grado di certicare l'identitá di una persona, ma non puó comunque prendersi la responsabilitá di
certicare anche delle informazioni personali inserite dall'utente. In particolare
l'Universitá si preoccupa di validare i dati personali giá presenti nell'IDMS e
non quelli inseriti dall'utente o dal sistema (tabella 5.1).
Dato
Fiscal code
Name
Surname
Role
Degree Program
Degree program visibility
Course year
Course year visibility
E-mail address
Presentation
Picture le
Curriculum Vitae le
Creation date
Latest update date
Sorgente
IDMS
IDMS
IDMS
Inserimento
Inserimento
Inserimento
Inserimento
Inserimento
Inserimento
Inserimento
Inserimento
Inserimento
Sistema
Sistema
Validazione Universitá
Si
Si
Si
No
No
No
No
No
No
No
No
No
N.A.
N.A.
Tabella 5.1: Certicazione e validazione dei dati in ClaimStudentID
Fanno parte dei servizi all'utente le seguenti operazioni:
5.2 Content aggregation services
49
• Login e autenticazione (solo se l'utente ha giá un prolo oppure se possiede le credenziali istituzionali)
• Creazione di un proprio prolo personale (solo utenti autenticati)
• Editing del proprio prolo (solo utenti autenticati)
• Visualizzazione del proprio prolo (solo utenti autenticati)
• Meta-ricerca sulle persone secondo nome, cognome o corso di laurea e
visualizzazione del prolo
• Meta-ricerca sulle persone che hanno condiviso un determinato contenuto interno all'applicazione ricercabile secondo stringa testuale o tags e
visualizzazione del prolo pubblico
• Visualizzazione dei proli degli ultimi utenti che ne hanno apportato
delle modiche (Latest updates )
5.2 Content aggregation services
Questa parte di ClaimStudentID riguarda l'aggregazione e la condivisione dei
contenuti e rappresenta il vero cuore di questa applicazione web 2.0. L'utente
loggato ha la possibilitá di creare link a contenuti secondo due tipologie: bookmarks e linked contents ; i primi consistono in un semplice segnalibro ad un
sito web di cui l'utente non è autore, i secondi rappresentano invece dei link
a contenuti di cui l'utente è autore e ne rivendica la paternitá. Attraverso i
linked contents è possibile linkare 4 dierenti tipologie di contenuto:
•
Websites : cioè un generico sito web creato dall'utente
•
Contents in websites : cioè un contenuto, o un gruppo di contenuti, creati
dallo studente e pubblicati su un generico sito web 2.0, tool o risorsa
•
Blogs : cioè un blog creato dallo studente
•
Flickr contents : cioè un contenuto, o un gruppo di contenuti, creati dallo
studente e pubblicati su Flickr
Tutti e 4 i tipi di contenuto condividono le stesse caratteristiche (titolo,
dati, descrizione, tags, eccetera) e possono, a discrezione dell'autore, essere o
meno visibili o ricercabili.
In questa parte di ClaimStudentID vengono forniti i seguenti servizi allo
studente:
• Creazione e editing di un nuovo bookmark (solo utenti autenticati)
• Eliminazione di un bookmark inserito (solo utenti autenticati)
5.3 Meta-search services
50
• Visualizzazione di un bookmark
• Riordino della lista di bookmark personali (solo utenti autenticati)
• Creazione e editing di un linked content (solo utenti autenticati)
• Eliminazione di un linked content (solo utenti autenticati)
• Visualizzazione di un linked content
• Riordino della lista di linked content personali (solo utenti autenticati)
• Meta-ricerca sui contenuti condivisi interni all'applicazione individuabili
secondo stringa testuale o tags e visualizzazione di questi.
5.3 Meta-search services
Se il primo passo è l'identicazione dell'utente, il secondo la condivisione dei
contenuti, allora il terzo deve necessariamente riguardare le meta-ricerche ai
contenuti esterni presenti in ClaimStudentID. Nelle precedenti due parti si sono
viste due tipologie di ricerche (in base all'autore ed interna a ClaimStudentID),
entrambe utilizzavano il motore di ricerca interno; i servizi di meta-ricerca invece si appoggiano sui motori di ricerca esterni di Flickr o Google, attraverso
l'utilizzo delle rispettive API e vengono attivati quando è selezionato il radiobutton Content on the Web .
La meta-ricerca consiste nella ricerca e nella visualizzazione di contenuti condivisi esterni, pubblicati nel web, individuabili secondo una stringa testuale o
attraverso tag specici in base alla provenienza (Flickr o Google), ed avviene in
due fasi distinte. Nella prima fase avviene l'interazione con l'utente e la ricerca
sui tag locali interni a ClaimStudentID; il risultato restituito è il numero dei
linked contents (gli unici considerati nelle ricerche esterne a ClaimStudentID)
che soddisfano i criteri scelti. Allo studente viene mostrato il numero dei risultati trovati e, solo a questo punto (se il valore è maggiore di zero), l'utente ha
la possibilitá di proseguire alla seconda fase e visualizzare i contenuti ricercati.
La seconda fase riguarda i motori di ricerca esterni, ai quali vengono passati i
dati necessari attraverso le API. Se il contenuto è del tipo website, content in
website o blog, vengono utilizzate le API di ricerca di Google, altrimenti quelle
di Flickr.
5.4 Struttura dell'home page
L'home page di ClaimStudentID ore la maggior parte dei servizi giá espressi,
ai quali va aggiunta la possibilitá di personalizzare l'aspetto graco dell'intera
applicazione attraverso il meccanismo dello style switcher (che sará trattato
nel capitolo 6.3). Come si puó vedere in gura 5.1, l'home page è composta
5.4 Struttura dell'home page
51
logicamente da 6 box, tutti utilizzabili da un utente generico non registrato o
loggato.
Figura 5.1: Struttura logica dell'home page di ClaimStudentID
L'area di intestazione sembrerebbe essere la piú banale e semplice, ma nasconde (nel vero signicato della parola) diverse funzionalitá; essa comprende,
oltre al titolo graco della pagina, anche il titolo testuale per la stampa ed il
menu di skip navigation (che sará trattato nel capitolo 6.6).
Il menu di ricerca consiste in 3 radio-button disposti sopra al box di ricerca e permette di scegliere se ricercare un utente, un contenuto interno o un
contenuto esterno.
Il box di ricerca è composto da 3 sezioni, ognuna delle quali permette di
specicare dei criteri di ricerca per le persone, i contenuti interni e per quelli
esterni a ClaimStudentID.
Il box di personalizzazione fornisce all'utente generico (non è necessario il
login o possedere un prolo su ClaimStudentID) la possibilitá di personalizzare
l'aspetto graco dell'intera applicazione ed è composto da un menu a tendina
che permette di scegliere una soluzione estetica tra una lista a disposizione.
Il box di login è composto da due form e permette il riconoscimento dell'utente registrato ed il suo ingresso ai servizi riservati.
Il box ultimi aggiornamenti visualizza gli ultimi 3 utenti che abbiano apportato delle modiche al proprio prolo.
Capitolo 6
Implementazione
La prima versione di ClaimStudentID badava soprattutto alla funzionalitá e
non si preggeva obiettivi graci o di accessibilitá, infatti l'intera applicazione
si reggeva unicamente sull'utilizzo di tabelle sia per il lato pratico che per quello
puramente estetico e presentazionale. Di seguito sono spiegate le soluzioni ed i
cambiamenti adottati a modica della prima versione di ClaimStudentID, per
giungere alla versione recente, piú improntata verso gli standard, l'accessibilitá
e la semplicitá del codice.
6.1 Codice table-less
Avere una pagina HTML con una struttura table-less [75] è importante per
diversi aspetti: semplicitá, leggerezza, funzionalitá e accessibilitá. Una pagina
che basa la sua struttura sull'utilizzo di tabelle (per posizionare gli elementi
graci o testuali) ha un codice molto piú complesso e molto meno leggibile di
una pagina che rimanda questo compito ai fogli di stile; questo porta inevitabilmente ad una maggior pesantezza del codice e della pagina, caratteristica che
inuisce anche sui tempi di caricamento della pagina stessa (piú alti) e quindi
sulle prestazioni. Una pagina web realizzata senza l'utilizzo di tabelle per la
denizione della struttura è inoltre piú funzionale ed accessibile in quanto permette una miglior (e piú semplice) interazione con l'utente (grazie al miglior
sfruttamento della tecnologia CSS) ed un maggior supporto alle tecnologie assistive. Ad esempio uno screen reader (lettura seriale della pagina) ha molte
meno dicoltá rispetto a quante ne avrebbe in caso di pagine tabellari (come
visto nel paragrafo 2.2.3.2).
Un'altra caratteristica importante a favore delle pagine table-less è la possibilitá di cambiarle nell'aspetto modicando solamente un le (il foglio di stile);
altrimenti in molti casi potrebbe servire una totale ri-scrittura di tutte le pagine. L'esempio piú eclatante in ClaimStudentID, sotto l'aspetto dell'accessibilitá, è senza dubbio l'home page, che ha richiesto una sua completa ricostruzione
in quanto era originariamente basata sull'uso di tabelle, righe e colonne che
6.1 Codice table-less
53
sono state sostituite con dei box (scatole). La sostituzione ha permesso anche
una miglior leggibilitá del codice in quanto riordinato concettualmente all'interno del box stesso (delimitato dai tag HTML <div> e </div> e denito
attraverso l'utilizzo dei CSS). Nelle gure 6.1 e 6.2 è mostrata l'home page di
ClaimStudentID (index.php), rispettivamente prima e dopo la restaurazione a
table-less (nella nuova versione rispetto alla vecchia c'è da segnalare in piú la
presenza del box di personalizzazione).
Figura 6.1: Home page di ClaimStudentID con layout denito da tabelle
Poiché la struttura dell'home page di ClaimStudentID è piuttosto complessa, si è preferito prendere in esame un altro esempio eclatante (con un codice
piú semplice da visualizzare), cioè l'home page personale di un utente registrato (indierente se pubblica o privata viste le esigue dierenze grache tra le
due). Questa pagina ha la particolaritá di avere un layout che ricordi molto
una tabella ed utilizza un menu di navigazione a tabs (o meglio crea un menu
che le simula). In gura 6.3 è mostrato uno screen-shot della pagina personale
pubblica in versione tabellare, mentre il relativo codice (riguardante solo il
menu a tabs tabellare) è visibile in gura 6.4.
Come si puó vedere in gura 6.4, l'implementazione della navigazione a
tabs risulta essere piuttosto lunga e dicile da leggere, sia per via della non
standardizzazione del codice, sia per la sua struttura a tabella; per renderla
table-less è necessario sfruttare al massimo le potenzialitá dei CSS.
La realizzazione del table-less tabs menu, è stata eettuata considerando
ogni elemento del menu come un elemento di una lista non ordinata la quale
è stata poi visualizzata senza nessuno stile di lista (ad esempio senza i classici
6.1 Codice table-less
54
Figura 6.2: Home page di ClaimStudentID con layout table-less
Figura 6.3: Home page personale con layout denito da tabelle
pallini) ed inline, cioè su un'unica la anziché in maniera verticale come consuetudine. Il resto è puro e semplice linguaggio CSS che si occupa di bordi,
6.1 Codice table-less
55
<table width="750" border="0" align="center"
cellpadding="2" cellspacing="0" bordercolor="#000066">
<tr>
<td width="250" height ="26" bgcolor="#000066"
style="border: thin solid #000066">
<div align="center" class="Stile2 Stile13">Profile</div>
</td>
<td width="250" bgcolor="#00CCFF" class="Stile3"
style="border: thin solid #000066">
<div align="center" class="Stile12">
<a href="pub_user_bmarks.php?id_user=<?php
echo $_GET['id_user']; ?>&
name=<?php echo $row_users['name']; ?>&
surname=<?php echo $row_users['surname']; ?>"
class="Stile3">Bookmarks</a></div>
</td>
<td width="250" bgcolor="#00CCFF" class="Stile3"
style="border: thin solid #000066">
<div align="center" class="Stile12">
<a href="pub_user_lcontents.php?id_user=<?php
echo $_GET['id_user']; ?>&
name=<?php echo $row_users['name']; ?>&
surname=<?php echo $row_users['surname']; ?>"
class="Stile3">Linked Contents </a></div>
</td>
</tr>
<!--codice HTML non trascritto del restante contenuto della pagina-->
</table>
Figura 6.4: Codice HTML non Table-less
colori, testo e box; cioè di tutte cose ordinarie sulle quali non vale la pensa soffermarsi. In gura 6.5 sono mostrati i due statement fondamentali per creare
il tabs-menu con i CSS per il layout table-less, ed in gura 6.6 il codice HTML
del menu table-less (il quale, rispetto alla versione tabellare, presenta in piú
anche il link alla tab attiva).
In ClaimStudentID sono presenti due pagine contenenti una tabella; questa
ha peró lo scopo di visualizzare i dati dell'utente e non di denire una struttura, svolge cioè il ruolo che una tabella dovrebbe eettivamente avere: quello
di organizzare i dati. La struttura della pagina invece è sempre organizzata
tramite box deniti dai tag <div> e </div> ed è notevolmente piú leggera,
breve, semplice e chiara. Nella resa a table-less di una pagina scompaiono
da essa anche tutte le nozioni presentazionali come colori e dimensioni che
vengono gestite del foglio di stile.
Quello mostrato in gura 6.7 è uno screen-shot della pagina dopo la sua
revisione: resa a table-less e standardizzazione (questa parte sará argomento
del prossimo paragrafo).
6.2 Pulizia e standardizzazione del codice
56
div#navigation ul {
list-style-type: none;
margin: 0;
padding: 0;
white-space: nowrap;
}
div#navigation li {
display: inline;
margin: 0;
padding:0;
}
Figura 6.5: Statement CSS per la creazione del menu a tabs
6.2 Pulizia e standardizzazione del codice
Un codice table-less è certamente piú pulito, standardizzato e accessibile di
uno tabellare, ma non lo è in maniera assoluta; questo infatti necessita di
un'ulteriore revisione (revisione priva di senso in pagine tabellari in quanto
ormai inconcepibili). Un codice è standardizzato quando soddisfa le speciche
di una delle tre DTD HTML/XHTML (in questo caso la Transitional). La
cosa piú banale è quella di rispettare semantica e sintassi del linguaggio:
• Tutti i tag aperti devono essere chiusi.
• Deve essere mantenuto l'ordine di dichiarazione, cioè se un elemento tra
i suoi tag di apertura e chiusura ne contiene un altro, quest'ultimo deve
necessariamente essere chiuso prima del suo genitore.
• Devono essere rispettati i ruoli dei vari elementi, cioè un elemento blocco
non puó (per esempio) essere inserito in un elemento inline.
• Gli attributi deniti per gli elementi devono appartenere allo stesso e
devono essere evitati (per quanto possibile) attributi di presentazione
quali width o size.
Anché il codice sia conforme alla DTD specicata (in questo caso la DTD
Transitional XHTML 1.0) devono essere considerate diverse richieste di standardizzazione e (per quanto possibile) soddisfatte.
Nello specico (dopo aver reso la pagina table-less) sono stati arontati i
seguenti accorgimenti.
6.2.1
Form
I form di input costituiscono l'elemento centrale e fondamentale di ClaimStudentID. Per aumentare il livello di accessibilitá del sito è stato necessario inserire un attributo alternativo (rispetto al classico attributo da mouse onclick)
6.2 Pulizia e standardizzazione del codice
57
<div id="navigation">
<ul>
<li id="activelink"><a href="pub_user_home.php?id_user=<?php
echo $_GET['id_user']; ?>&
name=<?php echo $row_users['name']; ?>&
surname=<?php echo $row_users['surname']; ?>">Profile</a>
</li>
<li><a href="pub_user_bmarks.php?id_user=<?php
echo $_GET['id_user']; ?>&
name=<?php echo $row_users['name']; ?>&
surname=<?php echo $row_users['surname']; ?>">Bookmarks</a>
</li>
<li><a href="pub_user_lcontents.php?id_user=<?php
echo $_GET['id_user']; ?>&
name=<?php echo $row_users['name']; ?>&
surname=<?php echo $row_users['surname']; ?>">Linked Contents</a>
</li>
</ul>
</div>
Figura 6.6: Codice HTML Table-less
Figura 6.7: Home page personale con layout table-less
per poter consentire anche un accesso tramite tastiera (onkeypress). Questo
attributo consente agli utenti impossibilitati nell'utilizzo del mouse di accedere
ai campi dei form tramite l'utilizzo della tastiera e si rivela molto utile soprattutto per input di selezione come radiobutton o checkbox. In gura 6.8 viene
mostrato il codice HTML del form di radiobutton con la quale l'utente sceglie
le modalitá di meta-ricerca in ClaimStudentID.
6.2 Pulizia e standardizzazione del codice
58
<input type="radio" name="src_type" id="src_type_people"
value="people" checked="checked"
onclick="eval(enable_content_src(0))"
onkeypress="eval(enable_content_src(0))" tabindex="4" />
<label for="src_type_people">People</label><br class="pda"/>
<input type="radio" name="src_type" id="src_type_inside"
value="inside" onclick="eval(enable_content_src(1))"
onkeypress="eval(enable_content_src(1))"
<?php if ($_GET['src_type'] == 'inside')
echo "checked=\"checked\""; ?> tabindex="5"/>
<label for="src_type_inside">Content inside ClaimStudentID</label>
<br class="pda"/>
<input type="radio" name="src_type" id="src_type_web" value="web"
onclick="eval(enable_content_src(2))"
onkeypress="eval(enable_content_src(2))"
<?php if ($_GET['src_type'] == 'web')
echo "checked=\"checked\""; ?> tabindex="6"/>
<label for="src_type_web">Content on the Web</label>
Figura 6.8: Form: Utilizzo dell'attributo onkeypress
All'interno del tag <input> sono presenti gli attributi relativi alle azioni
di interazione con l'utente, di click del mouse (onclick) e di pressione di tasti
della tastiera (onkeypress).
Molto importante per l'accessibilitá, soprattutto per i dispositivi vocali,
è associare il form di input (denito in questo caso dal tag <input>) con la
propria etichetta (denita tra i tag <label> e </label>) tramite l'attributo
for; anché ci sia associazione tra i due elementi, il valore dell'attributo for
deve coincidere con il valore dell'attributo id del form. Una volta denita
l'associazione logica, questa garantisce sia una miglior comprensione che una
maggior semplicitá e permette l'accesso al campo di un form anche solo attraverso un'interazione con l'etichetta corrispondente (per esempio una messa
a focus). In gura 6.9 è mostrato come esempio un campo dell'home page di
ClaimStudentID (quello nel quale si richiede il nome dell'utente da ricercare).
<label for="name">Name </label>
<input name="name" type="text" id="name" tabindex="7"
size="15" maxlength="30" value="<?php echo $_GET['name']; ?>"/>
Figura 6.9: Form: Associazione etichetta-campo di input
Un ulteriore accorgimento apportato a ClaimStudentID volto ad aiutare
la navigazione (esclusi utenti non vedenti) è l'evidenziazione di un campo del
form che avviene quando il focus si sposta su esso. In poche parole quando
l'utente immette i propri dati oppure i contenuti da ricercare, il campo del form
col quale interagisce si evidenzia circondandosi di un box quadrato dai bordi
6.2 Pulizia e standardizzazione del codice
59
colorati. Il codice HTML in gura 6.10 appartiene al foglio di stile di default
(default.css), nel quale la linea esterna viene colorata di arancio (#F90).
input: focus { outline: 2px solid #f90;}
Figura 6.10: Form: Proprietá CSS outline
Quest'ultimo accorgimento non viene in realtá richiesto per la standardizzazione del codice o per aumentare l'accessibilitá del sito, ma è sembrato opportuno inserirlo per fornire un ulteriore aiuto, anche se non è peró supportato
da Internet Explorer che semplicemente lo ignora.
Un ultimo accorgimento utile ad aumentare l'accessibilitá dei form è l'utilizzo di <eldset>. Questo comando HTML permette di ragguppare, non
solo logicamente, diversi elementi di un form correlati tra loro. Raggruppare
assieme i controlli correlati facilita la comprensione del loro scopo ed agevola la navigazione tra essi tramite tastiera (tasto Tab). Assieme al comando
<eldset> deve sempre essere presente il tag <legend>, il quale permette di
assegnare una didascalia ad un eldset, cosa di non trascurabile importanza
quando questo è presentato in maniera non visuale. Nei browser visuali, <eldset> e <legend> sono visualizzati come un bordo continuo interrotto dal testo
specicato da <legend>, testo solitamente posizionato sul bordo in alto a sinistra. A dierenza dei browser visuali, gli screen reader non si comportano in
maniera omogenea, l'implementazione dipende infatti anche da che browser si
stia utilizzando. Ad esempio Jaws si comporta dierentemente in base alla modalitá utilizzata: se si è in modalitá browse, il testo specicato da <legend>
viene immediatamente pronunciato e non viene fornita alcuna indicazione di
associazione ai controlli correlati; se si è invece in modalitá form, il testo di
<legend> viene pronunciato prima di ciascuna etichetta associata ad un campo di input presente nel eldset. L'adozione di <eldset> e <legend> rende
piú semplice la compilazione di form da parte di un gran numero di utenti con
disabilitá; il loro utilizzo non è stato peró implementato in ClaimStudentID,
ma vista la semplicitá delle pagine presenti, questa assenza non risulta troppo
pesante.
6.2.2
Tabelle
Come giá trattato nel paragrafo 2.2.3.2 le tabelle costituiscono un grosso ostacolo per l'accessibilitá. Per ridurre le dicoltá di navigazione, soprattutto per
utenti che utilizzano tecnologie vocali, è molto importante standardizzare le
tabelle seguendo le direttive imposte dalla DTD utilizzata. In primo luogo nella dichiarazione della tabella (ovvero nel suo tag iniziale) deve assolutamente
essere presente l'attributo summary che permette di descrivere il ruolo della
tabella stessa. La descrizione del ruolo di un oggetto (in questo caso una tabella, ma lo stesso discorso è valido anche per le etichette delle form) rientra nel
concetto di separare la struttura e la logica dalla presentazione: le prime due
6.2 Pulizia e standardizzazione del codice
60
sono esclusive dell'XHTML, mentre l'ultima dei CSS. L'associazione logica degli elementi e dei propri ruoli rientra nel progetto XHTML e permette anche
una maggior essibilitá della pagina web verso qualunque tecnologia. Un altro
elemento importante e molto spesso trascurato è <caption>, il quale permette
di inserire ed associare un titolo alla tabella. Il concetto di ruolo è molto forte
soprattutto nelle tabelle ed a questo proposito è richiesta la presenza di celle
di intestazione; queste sono le celle che deniscono i campi (solitamente sono
disposte in alto alla tabella, in questo caso deniscono il ruolo della colonna
che intestano) e sono usualmente visualizzate in grassetto (a meno di una loro
ridenizione nei CSS). In gura 6.11 è mostrato un esempio relativo ad una
tabella nella quale sono trattati tutti i temi trattati in questo paragrafo.
<table summary="about this user">
<caption>User's information</caption>
<tr class="hidden"><th>Queries</th><th>Results</th></tr>
<tr><td class="fields">Name:</td><td class="results">
<?php echo $row_users['name']; ?></td></tr>
<tr><td class="fields">Surname:</td><td class="results">
<?php echo $row_users['surname']; ?></td></tr>
<tr><td class="fields">Role:*</td><td class="results">
<?php echo $row_users['role']; ?></td></tr>
<!--parte di codice non trascritta-->
</table>
Figura 6.11: Tabelle: Utilizzo corretto degli elementi HTML
Per tabelle molto voluminose è necessario poi denire il ruolo (tramite
l'attributo scope) e/o l'associazione delle celle in relazione alla propria intestazione. Nel caso di ClaimStudentID non si è ritenuto necessario applicare
anche queste direttive poiché nel sito sono presenti solamente 2 tabelle (nelle pagine pub_user_home.php e auth_user_home.php rispettivamente dei
proli pubblici e privati di un utente) di modestissime dimensioni; non si è perció ritenuto opportuno appesantire il codice della pagina per assegnare degli
scope o delle associazioni superue.
6.2.3
Immagini
Le immagini rappresentano un concetto chiave per l'accessibilitá in quanto sono
ovviamente accessibili solo ad utenti vedenti (o al massimo agli ipovedenti) e
per questo potrebbero anche essere denite come un media discriminante.
L'accessibilitá deve essere una caratteristica valida sempre e per qualunque
media o elemento, non possono quindi essere escluse le immagini; per questo la
DTD di XHTML prevede l'obbligatorietá dell'attributo alt per gli elementi
immagine. Questo attributo serve per poter associare all'immagine un testo
alternativo da visualizzare nel caso l'immagine non sia disponibile (per esempio
nei browser testuali) o da leggere in caso di dispositivi vocali.
6.2 Pulizia e standardizzazione del codice
61
<img class="image" src="<?php if ($row_users['pic_file'] != '')
echo "pic_files/".$row_users['id_user'].".jpg";
else echo "pic_files/blank.jpg"; ?>" alt="user's pic" />
Figura 6.12: Immagini: Attributo HTML alt
Nell'esempio di gura 6.12, riguardante l'immagine personale che ogni utente iscritto puó caricare (relativo alla pagina del prolo pubblico di un utente,
ma sarebbe lo stesso nel caso del prolo privato), l'attributo alt specica
semplicemente che si tratta dell'avatar dell'utente visualizzato; immagine che
viene ricercata ed inserita dal codice PHP direttamente dal database in base
all'utente proprietario.
Per quanto riguarda l'accessibilitá, l'XHTML prevede un ulteriore attributo
non obbligatorio, a dierenza di alt, denominato longdesc, con il quale è possibile associare all'immagine una pagina web (.html) contenente la descrizione
dettagliata specica dell'immagine stessa. Questa descrizione permetterebbe
anche alle persone non vedenti di percepire il contenuto dell'immagine contenuta in una pagina web. L'attributo longdesc non è stato peró implementato
in ClaimStudentID in quanto l'applicazione in sé è del tutto sprovvista di immagini che possono solamente essere caricate come contenuti esterni (grazie
alla collaborazione con Flickr) e dunque non appartenenti all'applicazione.
6.2.4
Linguaggi esterni
Una pagina HTML/XHTML o PHP non è sempre composta unicamente da
questi linguaggi, infatti spesso si fa riferimento ad un terzo linguaggio; nel
caso di ClaimStudentID si tratta di Javascript. Il codice PHP deve essere
inserito all'interno di uno speciale tag dedicato, ed una pagina contenente tale codice deve necessariamente avere l'estensione .php; il codice Javascript va
inserito all'interno del tag <script> con l'attributo type impostato come
text/javascript e non implica nessun cambiamento di estensione alla pagina
HTML. La caratteristica principale di javascript è quella di essere un linguaggio interpretato; il codice infatti non viene compilato bensí esiste un interprete
(lato client, incluso nel browser) che esegue riga per riga, a tempo di esecuzione, quanto trascritto nello script. La DTD XHTML specica che ogni qual
volta si utilizza il tag <script> deve essere presente anche il tag <noscript>.
Questo tag permette di fornire un'alternativa nel caso il linguaggio di scripting, dichiarato in <script>, non sia abilitato; all'interno di esso infatti vanno
dichiarate le istruzioni alternative da eseguire. Nel caso di ClaimStudentID il
tag <noscript> viene utilizzato per visualizzare un messaggio di errore che avvisi l'utente della necessitá di avere il codice javascript abilitato per utilizzare
l'applicazione e tutte le sue funzionalitá.
Nell'esempio di gura 6.13, relativo al box di personalizzazione, in caso
di mancata abilitazione del codice javascript, attraverso il tag <noscript> il
6.2 Pulizia e standardizzazione del codice
62
<noscript><br/><span class="errors">
JavaScript language must be enabled!
</span></noscript>
Figura 6.13: Linguaggi esterni: Tag HTML <noscript>
sistema stamperá semplicemente un messaggio di errore che indica all'utente
la necessitá di avere tale linguaggio abilitato.
Nonostante non si tratti di un ulteriore linguaggio, un procedimento analogo è stato adottato anche per l'utilizzo dei cookie; infatti l'utente viene avvisato
di un'eventuale non abilitazione a questi se necessario tramite un messaggio
di errore simile al precedente. I cookie sono utili a ClaimStudentID per la
personalizzazione da parte dell'utente del layout graco impostabile grazie al
meccanismo dello style-switcher che verrá spiegato nel paragrafo 6.3.
<script type="text/JavaScript">
if (!navigator.cookieEnabled) {
document.write("Cookies must be enabled!");
}
</script>
Figura 6.14: Linguaggi esterni: Codice di verica dei Cookie
Questi controlli (Figura 6.14) sono molto importanti per garantire la robustezza del codice, cioè la sua piena funzionalitá anche in qualunque situazione
non standard che si possa venire a creare. In realtá il W3C sconsiglia l'utilizzo di linguaggi esterni all'HTML/XHTML o PHP (come lo javascript),
ma nel caso di ClaimStudentID questo linguaggio è necessario per il corretto
funzionamento dell'applicazione.
6.2.5
Ulteriori accorgimenti
Oltre ai precedenti, esistono anche altri accorgimenti da adottare anché il
codice sia autenticabile; tra questi il piú banale è l'attributo lang per il tag
radice della pagina (<html>). Come è facilmente intuibile tale attributo obbligatorio permette di denire la lingua utilizzata nel sito web (nel caso di
ClaimStudentID l'inglese, denominato con en) in modo da fornire un valido
supporto su quale lingua utilizzare alle tecnologie vocali. Un altro accorgimento richiesto per l'accessibilitá è quello di evitare, per i link ipertestuali, i
target esterni (_blank o _new), cioè evitare di far aprire nuove nestre
(o schede nei browser piú recenti) nell'interazione dell'utente con un link. Un
target esterno per un link porta ad un'inevitabile spostamento del focus sulla
nuova pagina con tutti i problemi di accessibilitá (soprattutto per gli screen
reader) derivanti dall'apertura di una nuova pagina. Purtroppo questo accorgimento non puó essere sempre applicabile in ClaimStudentID; questo non è
6.3 Style switcher
63
utilizzabile quando i contenuti caricati da un utente fanno riferimento a servizi esterni (Google o Flickr) e quando un visitatore desidera accedere a tali
servizi. In questo caso il visitatore deve necessariamente essere reindirizzato
verso il contenuto attraverso un nuovo target poiché, in caso contrario, questi
si vedrebbe catapultato fuori da ClaimStudentID e potrebbe addirittura (in
alcuni casi) perdere la possibilitá di ritornarci senza dover ri-eettuare l'intero
percorso che lo ha portato a visualizzare il contenuto.
6.3 Style switcher
Nonostante non sia raccomandato dagli organi uciali del web, quello dello Style Switcher [76] è un accorgimento solitamente molto apprezzato da un
utente ospite (anche se raramente implementato). Letteralmente signica modicatore di stile, permette all'utente di potersi scegliere un proprio template
graco (tra una serie a disposizione) e non è dicile da implementare.
Per implementare uno style switcher il sito web deve essere creato in maniera adeguata, cioè deve essere interamente basato su un codice HTML (senza
l'uso di tabelle) privo degli attributi presentazionali vecchio stile come width
o height. Dovrebbe preferibilmente esserci un unico foglio di stile totalmente dedicato per la stampa e valido per tutte le pagine del sito. Nel caso di
ClaimStudentID queste caratteristiche necessarie sono soddisfatte e sono state
trattate nei paragra precedenti o verranno trattate nei successivi.
Si è deciso di implementare lo style switcher lato server tramite l'utilizzo
di PHP e lo sfruttamento come principio di funzionamento dei cookie. I cookie
sono dei piccoli le di testo che memorizzano dei dati sul computer dell'utente;
in questo caso memorizzano il foglio di stile preferito, cosí da poter mantenere
questa informazione durante l'intera sessione di navigazione tra le pagine del
sito e le visite successive. I cookie vengono peró visti come pericolo da molti
software o user agent, e per questo spesso all'utente viene consigliato di disabilitarli. È dunque opportuno avvisare l'utente della necessitá di avere i cookie
abilitati per poter sfruttare lo style switcher e per poter quindi personalizzare,
a proprio piacimento, la graca del sito.
Uno style switcher lato server si compone sostanzialmente di due porzioni
di codice distinte:
1. Caricamento dello stile preferito dall'utente attraverso i cookie.
2. Pagina di scrittura del cookie e di redirect sulla pagina chiamante per
mostrare il nuovo stile scelto.
La prima è incorporata in ogni pagina necessaria insieme ai contenuti, la
seconda riguarda la memorizzazione del cookie e conserva solamente l'informazione sul nome del le CSS (estensione esclusa) corrispondente al foglio di stile
scelto dall'utente. Ovviamente, è anche necessario predisporre nelle pagine che
fanno uso dello style switcher i link per consentire il cambio di stile.
6.3 Style switcher
64
Per implementare lo style switcher con PHP è necessario inserire nell'intestazione della pagina web (head) che lo utilizza, il codice di gura 6.15.
<?if(isset($_COOKIE["style"]))
{
$style=$_COOKIE["style"];
print("<link rel=\"stylesheet\" type=\"text/css\"
href=\"$style.css\"\n");
}
else
print("<link rel=\"stylesheet\" type=\"text/css\"
href=\"default.css\"\n");
?>
Figura 6.15: Style switcher: Impostazione dello stile
Il codice di gura 6.15 permette di impostare uno stile alla pagina secondo
il seguente criterio: se l'utente ha eettuato una scelta, questa determina lo
stile della pagina, altrimenti viene settato lo stile di default.
Nel caso di ClaimStudentID si è deciso di implementare la parte di personalizzazione del template graco solo nell'home page, ma questa potrebbe
benissimo essere implementata in ogni pagina contenente il codice mostrato in
gura 6.15 all'interno dell'intestazione. Per far interagire l'utente e permettergli di scegliere un template, si è deciso di utilizzare un form di selezione
(di tipo select) funzionante con il codice di gura 6.16 da disporre nel corpo
(body) della pagina web.
<select onchange="location = value;">
<option value="setstyle.php?style=stile_css">Stile</option>
...
</select>
Figura 6.16: Style switcher: Tag HTML <select> per la scelta dello stile
L'attributo onchange permette di ricaricare in tempo reale la pagina web
(da subito dopo aver eettuato la scelta) passando il valore di value dell'opzione di scelta selezionata dall'utente al codice PHP presente in un le esterno
(setstyle.php) specicato prima di ?. In sostanza l'attributo inviato al le
esterno (quello specicato dopo style=) non è altro che il nome del foglio di
stile da utilizzare senza l'estensione .css.
Il codice inserito nell'home page di ClaimStudentID è mostrato in gura 6.17.
Come giá accennato, esiste un le esterno (setstyle.php) costruito come
mostrato in gura 6.18.
Il le setstyle.php ha il compito di scrivere il cookie e di ridirezionare il
browser sulla pagina che l'ha invocato. Quest'ultima, avendo nella sezione head
le istruzioni di caricamento del cookie e del relativo foglio di stile, provvede
a sostituire il valore passatogli da setstyle.php impostandolo come nome del
foglio di stile da considerare nel ricaricamento della pagina. Il passaggio è
6.4 Template multipli
65
<form name="template" action="">
<label for="css">Select your personal template</label>
<select name="css" id="css" onchange="location = value;">
<option value="">---Select one item---</option>
<option value="setstyle.php?style=default">Default</option>
<option value="setstyle.php?style=blog">Blog's style</option>
<option value="setstyle.php?style=butterfly">Butterfly</option>
<option value="setstyle.php?style=claim">Claim</option>
<option value="setstyle.php?style=digit">Digit</option>
<option value="setstyle.php?style=nature">Natural</option>
<option value="setstyle.php?style=urbino">Urbino</option>
<option value="setstyle.php?style=low_vision1">
Users with low vision 1</option>
<option value="setstyle.php?style=low_vision2">
Users with low vision 2</option>
<option value="setstyle.php?style=accessible">
Accessible</option>
<option value="setstyle.php?style=pda_screen">
for Handheld</option>
</select>
</form>
Figura 6.17: Style switcher: Scelta dello stile
<?php
setcookie("style", $_GET["style"], time()+31536000);
header("Location:".$HTTP_SERVER_VARS["HTTP_REFERER"]);
?>
Figura 6.18: Style switcher: File esterno
decisamente veloce, praticamente quanto un semplice reload della pagina, e il
nuovo CSS avrá eetto da subito, essendo memorizzato anche per le successive
visite.
6.4 Template multipli
Grazie allo style switcher l'utente visitatore ha la possibilitá di scegliere il template graco che piú lo aggrada. Ma come fare per realizzare diverse soluzioni
grache anche molto diverse tra loro?
Per realizzare i layout si sono utilizzati diversi CSS indipendenti l'uno dall'altro, selezionabili, come giá visto, attraverso un form. Ogni foglio di stile
si occupa di ridenire i vari box che compongono la pagina, il loro posizionamento, le vari immagini che compongono la veste graca del template, i link
e la formattazione del testo. Per quanto riguarda la personalizzazione delle
immagini (come quelle di logo e sfondo) bisogna tenere conto dell'impossibilitá
di poter caricare nella pagina immagini diverse per template diversi, quindi si
è ricorso ad un piccolo stratagemma: ogni immagine del template graco viene
6.4 Template multipli
66
caricata dal CSS e viene gestita come uno sfondo (cosa logica per lo sfondo
della pagina, un po' meno per il logo). Questo meccanismo permette di inserire
perció un logo personale ad ogni layout gestendolo come sfondo di un box di
dimensioni pressate proporzionali a quelle dell'immagine.
Tramite lo style switcher, oltre ai numerosi template puramente estetici
(default.css, blog.css, buttery.css, claim.css, digit.css, nature.css, urbino.css),
è possibile accedere anche ad altri quattro piú funzionali: low_vision1.css,
low_vision2.css, accessible.css, pda_screen.css; non è invece selezionabile, in
quanto nascosto il foglio di stile form.css.
6.4.1
low-vision
Questi due fogli di stile sono stati studiati per essere visualizzati a video da
persone ipovedenti, per cui dispongono di diverse soluzioni pensate apposta per
tale categoria di utenti [77]. Le persone con una qualche disabilitá agli occhi
utilizzano in genere basse risoluzioni video (640x480), per questo è buona norma creare siti web che vi si adattino; in particolare questi due CSS impostano
la larghezza della pagina a 630px, dimensione che permette di evitare l'apparizione delle fastidiose barre di scorrimento orizzontali (ancor piú fastidiose per
gli ipovedenti) nella visualizzazione della pagina, che occuperá dunque tutto
lo schermo.
Molto importante è fornire dei contrasti molto elevati in grado di aiutare
soprattutto le persone daltoniche o con dicoltá nel percepire i colori. Sono
generalmente due i colori piú problematici per i daltonici: il rosso ed il verde;
il primo è assolutamente da evitare in ogni caso, mentre il secondo puó essere
usato sia su sfondo nero che su sfondo bianco (con tonalitá opportune). Su
sfondo bianco vanno bene per la scrittura tutti quei colori che di piú si avvicinano al nero, come il nero stesso, il blu scuro, il verde scuro, il marrone
o il viola. Su sfondo nero si ha ovviamente un atteggiamento opposto e si
devono utilizzare soprattutto colori brillanti, che quasi ricordino quelli degli
evidenziatori, come il bianco, il giallo, il verde brillante o un azzurro molto
chiaro.
Figura 6.19: Contrasti su sfondo nero
Nel caso di ClaimStudentID, il foglio di stile low_vision2.css fornisce uno
sfondo di colore nero con contenuti (scritte e bordi) di colore bianco o giallo;
6.4 Template multipli
67
Figura 6.20: Contrasti su sfondo bianco
low_vision1.css invece imposta lo sfondo bianco ed i contenuti neri, blu scuri
o marroni. Anche il logo di ClaimStudentID è stato rivisto per questi due fogli
di stile; infatti i colori di default (arancio e blu) non erano adatti. Su sfondo
nero il logo è diventato a caratteri gialli e bianchi, mentre su sfondo bianco il
marrone si è occupato di sostituire l'arancio.
È peró inutile avere contrasti elevati se l'utente non riesce eettivamente a
leggere i contenuti, perció è bene impostare, non solo i colori, ma anche i tipi
di carattere da usare e le loro dimensioni. Devono essere utilizzati caratteri di
grandi dimensioni, che vadano dai 12 punti (minimo) ai 18. Molto piú elaborata
è invece la situazione del tipo di font da utilizzare; è bene evitare caratteri
troppo sottili (light) o troppo compressi (condensed) come rispettivamente
Matisse ITC (ma anche il classico Courier New) o Impact e prediligere
caratteri lineari, semplici e facilmente leggibili come Arial o Verdana. Per
aiutare ulteriormente la lettura è bene anche evitare di utilizzare il corsivo,
mentre è sempre ben accetto il grassetto.
Poiché non sono molti i colori utilizzabili in una pagina creata per utenti
ipovedenti, è bene non generare confusione al visitatore nascondendo i link,
mischiandoli insieme al testo semplice, ma mantenendone i colori originali (cioè
quelli impostati di default dal browser). Questa combinazione di colori puó
essere un po' penalizzante su sfondo nero, ma in questo modo l'utente ha
la possibilitá di riconoscere immediatamente un link ipertestuale dal normale
testo.
6.4.2
accessible
Questo foglio di stile è il piú semplice in assoluto tra tutti quelli presenti in
ClaimStudentID; infatti si preoccupa unicamente della formattazione del testo
(dimensione, colore, grassetto e allineamento, ma non del font) senza ridenire
nessun box (ad eccezione delle tabs di navigazione presenti nei proli pubblici
e privati degli utenti), garantendo cosí pagine molto semplici e leggere sia nel
codice che nell'aspetto graco.
6.4 Template multipli
6.4.3
68
pda-screen
Questo foglio di stile non è altro che una riproposizione, unicamente a scopo
illustrativo, del CSS creato appositamente per dispositivi PDA che verrá trattato nel paragrafo 6.5.2. L'unica dierenza rispetto a pda.css è la presenza del
box di personalizzazione che permette all'utente di scegliere il proprio layout
graco, box che invece è assente in pda.css.
6.4.4
form
Questo foglio di stile è di fatto nascosto in quanto non raggiungibile o selezionabile da nessuna parte; da solo non avrebbe nessun utilizzo pratico. Il
compito di questo CSS è quello di denire unicamente le informazioni presentazionali riguardanti le dimensioni dei form testuali (come input di tipo
text o le o le textarea). Ogni foglio di stile, creato per essere renderizzato
a video, include tramite la @-regola @import il foglio di stile form.css (gura
6.21).
@import url(form.css);
Figura 6.21: Template multipli: @-regola CSS @import
A dierenza di quanto succede di solito, con questo CSS, a dare problemi
di supporto non è stato Internet Explorer ma bensí Mozilla Firefox; infatti
questo non supporta la denizione delle dimensioni da foglio di stile per il
form di tipo le, dal quale avviene l'upload dei le da parte dell'utente; nel
caso di ClaimStudentID si tratta del curriculum vitae. Per aggirare questo
problema si è fatto in modo che il ridimensionamento del form in questione
venga eettuato tramite l'attributo HTML size impostato attraverso l'uso
del PHP, come mostrato in gura 6.22.
<label for="cv_file">Upload my curriculum vitae</label>
<input name="cv_file" id="cv_file" type="file" tabindex="9"
<?php if ($style=="pda_screen") {echo "size=\"18\"";}
else echo "size=\"50\"";?> onchange="del_cv.checked = 0"/>
Figura 6.22: Template multipli: Risoluzione di un bug
Il codice mostrato in gura 6.22 controlla il foglio di stile utilizzato: se
questo è pda_screen.css la dimensione impostata è 18; negli altri casi è 50.
Questo codice viene interpretato unicamente da Firefox in quanto, non
supportando il CSS per tale form, non ha la possibilitá di sovrascrivere la
dimensione con quella indicata da form.css.
6.5 Fogli di stile alternativi
69
6.5 Fogli di stile alternativi
Nel capitolo 2 si sono introdotti tutti i dispositivi che l'utente puó utilizzare per
accedere al web e si è visto come tali sistemi si dierenziano l'uno dall'altro
sia per le caratteristiche che per il software. Ognuno infatti dispone di una
propria risoluzione, ha una propria dimensione dello schermo (se ce l'ha), delle
proprie caratteristiche di velocitá o di colore; Ogni dispositivo necessita un
trattamento a sé per poter fornire lo stesso servizio. L'XHTML denomina i
dispositivi per il web come media e li suddivide in 9 categorie:
• screen (desktop e laptop)
• handheld (PDA e smartphone)
• print (stampanti)
• braille (browser braille)
• embossed (stampanti braille)
• projection (proiezioni)
• speech o aural (sintetizzatori vocali)
• tty (telescriventi)
• tv (televisioni)
Il programmatore ha la possibilitá di associare un diverso foglio di stile
(CSS) per ogni diverso dispositivo semplicemente inserendo l'attributo media
in una dichiarazione di un foglio di stile esterno. I valori di media sono quelli
delle 9 categorie sopra elencate, al quale va aggiunto il valore all (di default)
che li comprende tutti.
In ClaimStudentID si è deciso di implementare dei fogli di stile per screen,
print, handheld e aural. Il primo in realtá è una raccolta di fogli di stile
selezionabili a scelta dall'utente ed è stato sviluppato attraverso il meccanismo
di style switcher giá spiegato precedentemente.
<link rel="stylesheet" type="text/css" media="screen"
href="style.css" />
Figura 6.23: Fogli di stile alternativi: Dichiarazione in base al canale
La dichiarazione di gura 6.23, che ha il solo scopo dimostrativo e non è
stata realmente implementata in ClaimStudentID, fa in modo che l'interprete
(X)HTML eettui una corrispondenza case-sensitive con l'insieme di tipi di
media sopra deniti, ignorando le voci che non trovano riscontro.
6.5 Fogli di stile alternativi
6.5.1
70
print
Per quanto i contenuti testuali di un sito o blog, siano pensati, progettati e
creati per essere visti sullo schermo, questi possono anche essere stampati. Per
questo motivo è necessario predisporre il sito in modo che risulti corretto nella
visualizzazione anche in caso di stampa. In gura 6.24 la dichiarazione del
foglio di stile per la stampa, utilizzata in ogni pagina di ClaimStudentID.
<link rel="stylesheet" type="text/css" media="print"
href="print.css" />
Figura 6.24: Fogli di stile alternativi: Dichiarazione CSS per la stampa
Il foglio di stile per la stampa (print.css) [78] è stato progettato in modo
che solo le parti signicative vengano visualizzate, che la destinazione di alcuni
link sia visibile anche su carta e che ci sia un risparmio di colori, riducendo
al minimo indispensabile il loro uso.
Per esempio nell'home page stampare il box di personalizzazione o quello
di login è tutt'altro che utile, anzi occupa solamente spazio nella pagina, rischiando cosí di doverne stampare un numero superiore a quanto necessario.
L'esclusione di un determinato elemento dalla stampa avviene semplicemente
dichiarando tale elemento come non visualizzabile attraverso la proprietá CSS
display.
div.right
{
display: none;
}
Figura 6.25: Fogli di stile alternativi: Proprietá CSS display
Nel caso mostrato in gura 6.25 la proprietá viene applicata alla colonna destra dell'home page che non mostrerá in stampa il suo contenuto che
comprende i box di personalizzazione, login e degli ultimi utenti che hanno
aggiornato il prolo. Questo è solo uno dei tanti utilizzi della proprietá display
per la stampa (e non solo).
Su carta ovviamente non è possibile interagire con un link ipertestuale ma
è possibile, grazie ai CSS, stampare la destinazione di tale link. Questa caratteristica dei fogli di stile non è esclusiva della stampa, ma è un accorgimento
che, al di fuori di essa, troverebbe poche applicazioni, anzi appesantirebbe
gravosamente la visualizzazione dell'intera pagina. In ClaimStudentID si è
deciso di visualizzare il percorso del link nella stampa esclusivamente per i
contenuti inseriti dagli utenti, in quanto questi rappresentano il vero fulcro
dell'applicazione (e si pensa anche il motivo della stampa). In gura 6.26 viene mostrato un utilizzo di tale caratteristica in ClaimStudentID (print.css) che
viene semplicemente implementata in una linea di codice.
Nel primo caso si è deciso di visualizzare il percorso del link mostrandolo
6.5 Fogli di stile alternativi
71
div.box a:link:after, div.box a:visited:after,
div.Searchbox a:link:after, div.Searchbox a:visited:after
{
content:" [" attr(href) "] ";
}
div#navigation a:link:after, div#navigation a:visited:after
{
content: none;
}
Figura 6.26: Fogli di stile alternativi: Proprietá CSS content
dopo il suo titolo (cioè il valore normalmente stampato a video) all'interno
di parentesi quadre, per tutti quei link che abbiano a che fare con i contenuti
inseriti dagli utenti; nel secondo caso si è deciso di lasciare il link alla sua natura
abituale per tutti quei link appartenenti all'applicazione di ClaimStudentID.
Nel progettare il foglio di stile per la stampa si è deciso di non ottimizzare
solo lo spazio (come visto in precedenza) ma anche i colori. Infatti qualsiasi
sia lo stile scelto dall'utente, in caso di stampa, il risultato sará il medesimo:
scritte e linee di colore nero e logo di ClaimStudentID semplicato e stampato con la bicromia blu/arancio. Per fare questo è stato suciente ridenire i
colori di testo e linee di nero, e visualizzare il titolo ClaimStudentID, presente in ogni pagina (ma in esse nascosto tramite il valore CSS hidden),
sostituendolo all'immagine visualizzata a schermo corrispondente al template
scelto dall'utente.
6.5.2
handheld
Il foglio di stile per dispositivi PDA (pda.css) è molto importante visto l'attuale
espansione del web verso il mobile, ma solo pochissimi siti lo implementano;
questa scarsa applicazione fa in modo che ci siano pochi strumenti e pochi
esempi che possono aiutare lo sviluppatore. In gura 6.27 la dichiarazione del
foglio di stile per i PDA utilizzato in ogni pagina per ClaimStudentID.
<link rel="stylesheet" type="text/css" media="handheld"
href="pda.css" />
Figura 6.27: Fogli di stile alternativi: Dichiarazione CSS per handheld
Per creare questo foglio di stile infatti si è preso spunto dal sito di Mozilla Foundation (in particolare dalla parte riguardante SeaMonkey 1.1.11 [9])
che implementa il CSS per handheld; da esso si è presa principalmente l'idea dell'impaginazione verticale e la dimensione del corpo delle pagine web.
Per i dispositivi PDA la larghezza dello schermo deve essere, al piú, di 220
pixel, quindi si è deciso di impostare 218 px come valore massimo. Questa
dimensione ridotta preclude ovviamente qualsiasi impaginazione degli oggetti
6.5 Fogli di stile alternativi
72
in maniera allineata o orizzontale; si è costretti infatti a disporre i contenuti
verticalmente ed a impostare un carattere a dimensioni piuttosto ridotte. Per
quanto riguarda i form di interazione, anche per questo foglio di stile dedicato è
stato realizzato un CSS ad hoc (pda_form.css) che ha il compito di impostare
le dimensioni dei form, in base a quelle ridotte di caratteri e larghezza della
pagina, adattandole alle dimensioni dello schermo. Lo stesso pda_form.css
viene utilizzato anche per la versione dimostrativa di pda.css (pda_screen.css)
vista precedentemente. Per quanto riguarda la gestione della dimensione dei
form di tipo le, questa viene rimandata al browser dell'apparecchio mobile in
quanto non è possibile andare ad agire tramite codice PHP, visto che l'utilizzo
di pda.css non è dovuto alla scelta dell'utente ma alla scelta del sistema che
automaticamente lo seleziona quando necessario. In pda.css viene poi preclusa
all'utente la possibilitá di personalizzare il layout graco (non mostrando il
box di personalizzazione) in quanto questo è eettivamente l'unico foglio di
stile implementato per dispositivi mobili.
6.5.3
aural
Il foglio di stile per dispositivi vocali (aural.css) [79] è completamente dierente
da tutti gli altri mostrati o descritti in quanto non si occupa di denire la
presentazione a video della pagina, ma della sua lettura a voce. In gura 6.28
è mostrata la dichiarazione del foglio di stile per dispositivi aurali utilizzato in
ogni pagina di ClaimStudentID.
<link rel="stylesheet" type="text/css" media="aural"
href="aural.css" />
Figura 6.28: Fogli di stile alternativi: Dichiarazione CSS per dispositivi aurali
In questo CSS viene denito il parlato attraverso cambiamenti di tonalitá,
di voce e di volume. Grazie alla proprietá CSS volume è possibile impostare un livello di volume proporzionale all'importanza o alla rilevanza di un
paragrafo, una frase o di una parola. La proprietá voice-family permette di
impostare il tipo di voce (maschile o femminile) che eettua la lettura; in particolare si è deciso di utilizzare una voce maschile per il corpo delle pagine ed
una femminile per i titoli. Le proprietá pause-before e pause-after permettono di impostare delle pause nella lettura, misurabili in millisecondi; queste
sono state utilizzate soprattutto nella lettura dei campi delle tabelle e nel menu a tabs. Ulteriori accorgimenti sono costituiti dall'utilizzo di speak-header
che permette di impostare quante volte leggere le intestazioni delle tabelle (in
ClaimStudentID questa proprietá è stata impostata per leggere le intestazioni
solo all'inizio della tabella, viste le esigue dimensioni di questa), di speakpunctuation e di speak-numeral che permettono di leggere rispettivamente
una parola carattere per carattere ed un numero cifra per cifra (queste due
proprietá sono state utilizzate per la lettura degli indirizzi e-mail).
6.6 Skip navigation
73
Anché l'utente possa sfruttare anche la skip navigation (presentata nel
paragrafo successivo) è stato necessario non ridenire, come nascosta, la classe
hidden per poter cosí permetterne al dispositivo vocale la lettura. È stato
inoltre nascosto il box riguardante la personalizzazione in quanto non avrebbe senso chiedere ad un utente che utilizzi uno screen reader di scegliere la
soluzione graca a sé piú gradita.
6.6 Skip navigation
Questo accorgimento software [80] serve per aumentare l'accessibilitá delle pagine web soprattutto per le persone che navigano utilizzando dispositivi assistivi (screen reader su tutti) per ovviare a disabilitá siche che, altrimenti,
renderebbero loro impossibile l'uso del computer.
Nella maggioranza dei casi le pagine web vengono viste tramite i piú diusi
browser graci e su uno schermo di computer, ma non è sempre cosí. Come
giá trattato ampiamente nel Capitolo 2 esistono software capaci di leggere
vocalmente una pagina web tramite la scheda audio. Per farlo devono prima
compiere una operazione detta linearizzazione, con la quale il contenuto di un
sito web viene tradotto in una sequenza di parole, lette una di seguito all'altra.
Le immagini vengono sostituite con il testo specicato nell'attributo alt; il
testo e le eventuali tabelle sono scomposte e riordinate da sinistra verso destra
riga per riga. Se il sito web non è stato creato seguendo i punti sopra descritti
è facile incontrare problemi di interpretazione dovuti alla mancanza di testo
alternativo alle immagini, da una dicile comprensione di una tabella dati, o
da un'errata linearizzazione dei contenuti se il layout del sito è ottenuto tramite
tabelle.
Anche in assenza di tali problemi (e quindi con una pagina creata il piú
possibile ad hoc per l'accessibilitá), l'utente sará costretto ad ascoltare l'intera
pagina letta da sinistra a destra, riga per riga. In questo modo si rischia
che, prima di giungere ai contenuti del sito, l'utente debba ascoltarsi tutto
il contenuto dell'header (il testo posto in alternativa al logo, la tagline, i link
della navigazione primaria) e poi anche il contenuto dell'eventuale colonna di
sinistra come i link della navigazione secondaria e tutto il resto. L'utente è
cosí obbligato a pazientare e, anche nel caso potesse muoversi nel sito grazie
alle opzioni fornite dal software (saltare tramite la tastiera tra un blocco e
l'altro), dicilmente capirebbe come è organizzato il sito non potendone avere
la visione d'insieme. In gura 6.29 è mostrata l'organizzazione classica di un
sito web.
Il meccanismo di skip navigation tende a favorire il piú possibile la navigazione nel sito web; infatti se l'utente desiderasse leggere immediatamente
il contenuto di una pagina, o eettuare un login potrebbe, grazie a questo
accorgimento, farlo in maniera piuttosto veloce. La skip navigation consiste
6.6 Skip navigation
74
Figura 6.29: Struttura tipo di un sito web
semplicemente nell'inserire dei link-áncora, nascosti all'utente che utilizza il
video, in grado di indirizzare l'utente nella zona della pagina desiderata.
Nel caso specico di ClaimStudentID si è inserito un vero e proprio menu
all'inizio dell'home page. Questo menu è stato dichiarato all'interno di un
box di classe nominata hidden (letteralmente invisibile, nascosto) contenente
oltre ai link-áncora anche il titolo del sito che sarebbe altrimenti inaccessibile
alla lettura, in quanto i loghi normalmente visualizzati, costituiti unicamente
da sfondi, sono sprovvisti di testo alternativo. In gura 6.30 è mostrato il
codice del menu nascosto leggibile dalle tecnologie assistive vocali.
<div class="hidden">
<h1>
<span class="orange">C</span>laim
<span class="orange">S</span>tudent
<span class="orange">ID</span>
</h1>
<p>
<a name="NavMenu" id="NavMenu">Start menu</a>
<a href="#SearchForm" title="Execute a search">Search</a>
<a href="#Users" title="Login for registered users">
Registered Users</a>
<a href="#Updates" title="View the latest updates users">
Lastest Updates</a>
</p>
</div>
Figura 6.30: Skip Navigation: Implementazione menu per dispositivi aurali
6.6 Skip navigation
75
Si è deciso di non linkare l'area del box contenente la form di personalizzazione dei template in quanto non avrebbe avuto senso linkare un qualcosa di
assolutamente inadeguato e inutilizzabile ai non vedenti. Oltre ai link-áncora,
nel menu è anche presente un'áncora-destinazione che puó essere facilmente
raggiunta dall'utente al termine della lettura del contenuto di un blocco, per
far ritorno al menu principale. Ogni link è fornito di titolo esplicativo del percorso da intraprendere per aiutare ulteriormente la scelta. In questo modo un
utente non vedente che volesse direttamente loggarsi senza dover prima leggersi
tutti i contenuti per la ricerca, puó farlo semplicemente selezionando l'áncora
corrispettiva al login.
Figura 6.31: Skip Navigation: Struttura dell'home page di ClaimStudentID
Nell'immagine 6.31, dell'home page di default di ClaimStudentID, sono
stati inseriti in rosso i link del menu nascosto (visibile dagli screen reader),
mentre i # rossi rappresentano le destinazioni di tali link, le frecce il collegamento tra link e destinazione e i simboli @ verdi indicano i punti dalla
quale è possibile ritornare al menu. Poiché le destinazioni sono sempre inserite
all'interno del box da raggiungere, l'áncora è fornita di testo specicante il
titolo del blocco.
L'utilizzo della skip navigation è possibile sia per dispositivi di lettura
capaci di interpretare i CSS sia per dispositivi che non li supportano; per i primi
infatti viene utilizzato il foglio di stile per apparecchi aurali (aural.css) che
mostra il menu di skip navigation e nasconde la parte di personalizzazione
6.7 Mappa del sito
76
tramite il valore CSS hidden, mentre i secondi ignorano completamente i CSS
(e dunque anche l'hidden specicato nel foglio di stile per il video) e mostrano
senza problemi il menu di skip navigation.
Il foglio di stile aural.css di fatto inverte i ruoli denendo visibile la classe
nominata come hidden e nascondendo quella nominata come template.
6.7 Mappa del sito
Creare una mappa del sito è molto utile durante lo sviluppo del sito stesso,
ma anche per rendere piú facile agli utenti l'orientamento tra i contenuti del
sito, specialmente quando questi sono molti e suddivisi in molteplici sezioni e
categorie. In ClaimStudentID la mappa del sito (map.php) è stata realizzata
con uno specico script PHP che permette di creare la mappa in automatico
senza che il programmatore si debba preoccupare di aggiornarla all'aggiunta o
alla rimozione di nuove pagine o le. Lo script (che va inserito nella cartella
principale del sito) permette di escludere dalla mappa alcuni le o cartelle
che il programmatore vuole non mostrare ai visitatori per svariati motivi. La
decisione di non mostrare un le o cartella potrebbe essere necessaria in caso
di contenuti privati, di cartelle di sistema utili al programmatore ma estranee
all'applicazione o in caso di aree protette.
6.8 Favicon
Una favicon non è altro che un'immagine di piccole dimensioni (dai 16x16 pixel
ai 32x32 pixel a seconda dei browser) che viene visualizzata nella barra degli
indirizzi a anco del percorso del sito web. Per poter inserire la favicon è
necessario inserire in ogni pagina (all'interno di <head>) la dichiarazione di
gura 6.32.
<link rel="shortcut icon" href="images/icon.jpg"/>
Figura 6.32: Favicon: Dichiarazione favicon
La favicon non è ovviamente richiesta dagli organi uciali del web, ma il
suo utilizzo fornisce uno spessore al primo impatto con il sito e garantisce una
maggior distinguibilitá dagli altri applicativi web, soprattutto per le ricerche
nei preferiti.
Bibliograa
[1] A. Vivalda, ClaimStudentID, tesi di laurea in Informatica Applicata,
Universitá degli Studi di Urbino, 2008
[2] AOL, The Netscape Archive,
browser.netscape.com/,
visitato il 13 Maggio 2009
[3] Microsoft, Internet Explorer,
www.microsoft.com/italy/windows/products/winfamily/ie/default.mspx,
visitato il 5 Marzo 2009
[4] ConStile, Il box model di IE5/Win,
www.constile.org/tutorial/IE5_box_model/,
visitato il 20 Ottobre 2008
[5] Mozilla Europe, Firefox, il browser web,
www.mozilla-europe.org/it/,
visitato il 5 Marzo 2009
[6] Apple, Safari,
www.apple.com/it/safari/,
visitato il 5 Marzo 2009
[7] Opera Software, Opera browser, fastest & safer internet!,
www.opera.com/,
visitato il 5 Marzo 2009
[8] Konqueror, Konqueror, Web browser, le manager and more ...,
www.konqueror.org/,
visitato il 5 Marzo 2009
[9] Mozilla, The Seamonkey Project,
www.seamonkey-project.org/,
visitato l'1 Settembre 2008
[10] Mozilla, The Seamonkey Project,
www.seamonkey-project.org/,
visitato il 14 Maggio 2009
Bibliograa
78
[11] Google, Google Chrome,
www.google.com/chrome/,
visitato il 5 Marzo 2009
[12] Mozilla, Camino, Mozilla Power, Mac Style,
caminobrowser.org/,
visitato il 5 Marzo 2009
[13] Flock Company, Flock Browser, The social web browser,
www.ock.com/,
visitato il 5 Marzo 2009
[14] K-Meleon, K-Meleon,
kmeleon.sourceforge.net/,
visitato il 5 Marzo 2009
[15] Avant Force, Avant Browser,
www.avantbrowser.com/,
visitato il 14 Maggio 2009
[16] Avant Force, Orca Browser,
www.orcabrowser.com/,
visitato il 14 Maggio 2009
[17] Flash Peak, SlimBrowser - Best free internet browser, web browser software!,
www.ashpeak.com/sbrowser/,
visitato il 5 Marzo 2009
[18] W3Schools, Browser Statistics,
www.w3schools.com/browsers/browsers_stats.asp,
visitato il 25 Febbraio 2009
[19] Webdevout, Web Browser Standards Support Summary,
www.webdevout.net/browser-support-summary,
visitato il 5 Marzo 2009
[20] Michele Diodati, Accessibilitá guida completa,
accessibile.diodati.org/agc/cap02.html,
visitato il 15 Dicembre 2008
[21] Michele Diodati, Accessibilitá guida completa,
www.diodati.org/agc/cap02.html#screenreaders,
visitato il 15 Dicembre 2008
[22] Michele Diodati, Accessibilitá guida completa,
accessibile.diodati.org/agc/cap01.html#nonaccedi,
visitato il 9 Gennaio 2009
Bibliograa
79
[23] Palm Inc., La vostra destinazione per Palmari, Mobile Managers, Smartphones, Accessori e Software,
www.palm.com/it/it/,
visitato il 3 Febbraio 2009
[24] Research In Motion, Blackberry - Smartphone,
it.blackberry.com/,
visitato il 3 Febbraio 2009
[25] Linux Foundation, Linux Mobile,
www.linuxfoundation.org/en/Mobile_Linux,
visitato il 3 Febbraio 2009
[26] Symbian Foundation, Symbian Foundation,
www.symbian.org/index.php,
visitato il 3 Febbraio 2009
[27] Microsoft, Micorsoft Windows Mobile,
www.microsoft.com/windowsmobile/it-it/default.mspx,
visitato il 3 Febbraio 2009
[28] Opera Software, Opera Mini - The most popular mobile phone browser
in the world,
www.opera.com/mini/,
visitato il 30 Gennaio 2009
[29] Opera Software, Opera Mobile - Inspiration comes in small packages,
www.opera.com/mobile/,
visitato il 30 Gennaio 2009
[30] Access Co., Advanced Software Solutions for Mobile and Beyond PC NetFront Browser,
www.access-company.com/home.html,
visitato il 30 Gennaio 2009
[31] Mozilla Foundation, Minimo project page,
www-archive.mozilla.org/projects/minimo/,
visitato il 30 Gennaio 2009
[32] Bitstream, Mobile web browser for mobile internet,
www.bitstream.com/wireless/index.html,
visitato il 30 Gennaio 2009
[33] Mozilla, Fennec,
wiki.mozilla.org/Fennec,
visitato il 20 Novembre 2008
Bibliograa
80
[34] Oculista.it, Oculista.it,
www.oculista.it/site/ipovisione.asp,
visitato il 15 Novembre 2008
[35] Freedom Scientic, Products for the Visually Impaired,
www.freedomscientic.com/products/fs/jaws-product-page.asp,
visitato il 26 maggio 2009
[36] GW Micro, Window-Eyes,
www.gwmicro.com/Window-Eyes/,
visitato il 26 maggio 2009
[37] Nvda, Screen reader open source per non vedenti,
www.nvda.it/,
visitato il 26 maggio 2009
[38] Gnome, Orca,
projects.gnome.org/orca/,
visitato il 26 maggio 2009
[39] Lynx, Lynx source distribution directory,
lynx.isc.org/,
visitato il 10 aprile 2009
[40] Links, Links home page,
www.jikos.cz/mikulas/links/,
visitato il 10 aprile 2009
[41] WebbIE, WebbIE, the free web browser for blind people with little or
no sight,
www.webbie.org.uk/,
visitato il 10 aprile 2009
[42] Sourceforge, W3M Homepage,
w3m.sourceforge.net/,
visitato il 10 aprile 2009
[43] E-Links, Full-Featured Text WWW Browser,
elinks.or.cz/,
visitato il 10 aprile 2009
[44] Alynx, The Alynx Homepage,
www.molgen.mpg.de/ alynx/,
visitato il 10 aprile 2009
[45] Sourceforge, Netrik,
netrik.sourceforge.net//?intro.html,
visitato il 10 aprile 2009
Bibliograa
81
[46] uSoft, Zoomtext 9,
www.zoomtext.de/ita/,
visitato il 26 maggio 2009
[47] Freedom Scientic, MAGic Screen Magnication Software,
www.freedomscientic.com/products/lv/magic-bl-product-page.asp,
visitato il 15 aprile 2009
[48] Dolphin, Lunar - Screen magnier,
www.yourdolphin.com/productdetail.asp?id=3,
visitato il 15 aprile 2009
[49] Dolphin, LunarPlus - Screen magnier with speech,
www.yourdolphin.com/productdetail.asp?id=4,
visitato il 15 aprile 2009
[50] Nuance, Nuance Talks,
www.nuance.com/talks/,
visitato il 15 aprile 2009
[51] Code Factory, Code Factory: Products,
www.codefactory.es/en/products.asp?id=283,
visitato il 16 aprile 2009
[52] Cavazza - Polo Informatico Nazionale, Cavazza 2000 - Polo Informatico
Nazionale,
www.cavazza.it/cavazza2000/voicesuite.html,
visitato il 16 aprile 2009
[53] Web per tutti, Modalitá e problematiche di navigazione delle pagine
web,
www.webxtutti.it/gcmodalita.htm
visitato il 4 Gennaio 2009
[54] Disabilitá in cifre, Stima del numero di disabili,
www.disabilitaincifre.it/prehome/tipologie_disabilita.asp,
visitato il 12 Maggio 2009
[55] iCommunicator, iCommunicator 5,
www.icommunicator.com/,
visitato il 26 maggio 2009
[56] RNID Technology, Mobile Textphone,
www.ictrnid.org.uk/9210txt.html,
visitato il 26 maggio 2009
[57] Madente Inc., Magic Cursor 2000 V2.3,
www.madentec.com/products/magic-cursor.php,
visitato il 26 maggio 2009
Bibliograa
82
[58] ReadPlease, ReadingBar - Text-to-speech software that lets your computer talk,
www.readplease.com/english/readingbar.php,
visitato il 26 maggio 2009
[59] Nuance, Dragon Naturally Speaking 10,
italy.nuance.com/naturallyspeaking/,
visitato il 26 maggio 2009
[60] W3C - WAI, Web Accessibility Initiative (WAI),
hwww.w3.org/WAI/,
visitato il 15 Gennaio 2009
[61] W3C - WAI, Web Content Accessibility Guidelines (WCAG) 2.0,
www.w3.org/TR/WCAG20/,
visitato il 20 Dicembre 2008
[62] W3C - WAI, W3C Web Content Accessibility Guidelines 1.0 Conformance Logos,
www.w3.org/WAI/WCAG1-Conformance.html.en,
visitato il 20 Maggio 2009
[63] Giustizia.it, Legge 9 Gennaio 2004, n. 4,
www.giustizia.it/cassazione/leggi/l4_04.html,
visitato il 10 Settembre 2008
[64] PubbliAccesso, Studio sulle linee guida per la verica dell'accessibilitá
- Requisiti per verica tecnica,
www.pubbliaccesso.gov.it/biblioteca/documentazione/studio_lineeguida
/3_requisiti_tecnica.htm,
visitato il 10 Settembre 2008
[65] W3C, HTML 4.01 Specication,
www.w3.org/TR/html401/,
visitato il 12 Febbraio 2009
[66] W3C, XHTML 1.1 - Module-based XHTML,
www.w3.org/TR/xhtml11/,
visitato il 12 Febbraio 2009
[67] Laboratorio di Accessibilitá e Usabilitá, Xhtml 2 e Html 5,
lau.csi.it/realizzare/accessibilita/codice_html/xhtml2/xhtml2.shtml,
visitato il 29 maggio 2009
[68] W3C, XHTML 2.0,
www.w3.org/TR/2002/WD-xhtml2-20020805/,
visitato il 12 Febbraio 2009
Bibliograa
83
[69] W3C, XHTML 2.0,
www.w3.org/TR/xhtml2/,
visitato il 12 Febbraio 2009
[70] W3C, HTML 5,
dev.w3.org/html5/spec/Overview.html,
visitato il 1 Giugno 2009
[71] W3C, Cascading Style Sheets,
www.w3.org/Style/CSS/,
visitato il 18 Maggio 2009
[72] W3C, Cascading Style Sheets, level 1,
www.w3.org/TR/CSS1/,
visitato il 18 Maggio 2009
[73] W3C, Cascading Style Sheets Level 2 Revision 1 Specication,
www.w3.org/TR/CSS21/,
visitato il 18 Maggio 2009
[74] W3C, CSS: Current Work,
www.w3.org/Style/CSS/current-work,
visitato il 18 Maggio 2009
[75] .ConStile, CSS e tabelle a confronto,
www.constile.org/tutorial/css_vs_table/index.html,
visitato il 2 Dicembre 2008
[76] Html.it, Style Switcher per tutti,
webdesign.html.it/articoli/leggi/371/style-switcher-per-tutti/,
visitato il 3 Settembre 2008
[77] Html.it, Ipovedenti: strumenti specici,
webdesign.html.it/guide/lezione/1520/ipovedenti-strumenti-specici/,
visitato il 4 Dicembre 2008
[78] Daniele Rollo, Non dimenticare i fogli di stile per la stampa,
www.danielerollo.com/mediaprint-non-dimenticare-i-fogli-di-stile-per-lastampa/,
visitato il 7 Dicembre 2008
[79] W3C, Aural style sheets,
www.w3.org/TR/CSS2/aural.html,
visitato il 5 Dicembre 2008
[80] I Use it, usabilitá e accessibilitá del web,Skip navigation: in nome dell'accessibilitá,
www.i-use.it/articoli/xhtml/5/,
visitato il 17 Settembre 2008
Ringraziamenti
Non sono particolarmente bravo con le parole, ma non posso esimermi dal
ringraziare chiunque abbia vissuto con me questa pagina importante della mia
vita.
Dal punto di vista della tesi intendo ringraziare il Prof. Alessandro Bogliolo
per le ore che ha dedicato a questo lavoro, per l'enorme disponibilitá mostratami e per avermi indirizzato verso questo caso di studio cosí interessante e
stimolante. Vorrei inoltre ringraziare Andrea Vivalda per la sua disponibilitá,
per avermi fornito dati e consigli indispensabili per la realizzazione della tesi e
per avermi permesso di utilizzare e citare il proprio lavoro di laurea.
Un ringraziamento speciale va sicuramente a tutta la mia famiglia, soprattutto a mio padre, mia madre e a mia sorella, per i sacrici fatti e per il
supporto che mi è stato dato in questi anni.
Vorrei inoltre ringraziare indistintamente tutti i miei amici, sia quelli che
hanno condiviso con me le esperienze universitarie, condite da esami, progetti
di gruppo e da diverse dicoltá, sia quelli che mi hanno accompagnato nei
momenti passati ad Urbino, ma anche e soprattutto tutti gli amici della vita
di tutti i giorni, senza i quali non saprei proprio stare. Ho deciso di non fare
nessun nome proprio per non rischiare di escludere davvero nessuno, ma un
sincero grazie va davvero a tutti.