Tesi di Laurea

Università degli Studi di Bari Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Tesi di Laurea Navigazione sul Web mediante dispositivi di input head‐controlled: sviluppo di una estensione Mozilla Firefox per la localizzazione delle componenti sensibili allʹinterno delle pagine HTML Relatore Chiar.mo Prof. Giovanni SEMERARO dott. Pasquale LOPS Laureando Cataldo MUSTO Anno Accademico 2004‐2005 Alla mia famiglia. A Marica. Introduzione i
Introduzione
Nel 1998 una giuria di giornalisti americani ha insignito Johan Gutenberg
come individuo più importante del secondo millennio. Per comprendere al meglio le
motivazioni alla base di questo riconoscimento è necessario spostarsi nella prima metà
del XV secolo, quando, attraverso l’invenzione della stampa a caratteri mobili,
Gutenberg ha dato un contributo fondamentale nel processo di alfabetizzazione di
massa. Fino ad allora, infatti, la stampa e la pubblicazione di un testo di qualsiasi
natura era un procedimento lento, costoso, e che dunque precludeva a grandi fasce
della popolazione la possibilità di conoscere, di acculturarsi, di imparare a leggere e
scrivere.
Riguardo Gutenberg e riguardo la sua invenzione si è detto tanto e scritto
tantissimo: lo scrittore Victor Hugo ha persino parlato di “più grande invenzione della
storia umana”, mentre da più parti si associa all’invenzione di Gutenberg il concetto di
“rivoluzione”. Ciò che è importante constatare, però, è che oggi, a più di sei secoli di
distanza, ci troviamo di fronte ad una nuova rivoluzione, una rivoluzione dall’impatto
sociale altrettanto forte, che rischia di modificare altrettanto radicalmente buona parte
delle nostre abitudini e dei nostri comportamenti: la rivoluzione informatica.
Convenzionalmente il termine di rivoluzione informatica serve a descrivere
metaforicamente il progressivo passaggio dalla Società industriale, quella che abbiamo
vissuto e che viviamo ancora oggi, alla Società dell’informazione, la società del nostro
futuro ma i cui caratteri fondamentali però sono percepibili già quotidianamente.
Nella Società dellʹInformazione cambiano radicalmente moltissime cose: il rapporto
dellʹuomo con i propri strumenti di lavoro, ad esempio, non è più diretto, ma mediato
tramite lʹelaboratore elettronico e determinato da programmi, sistemi, computer,
supporti, memorie, passando da un modo diretto di gestire fatti e processi, ad un modo
indiretto. Nella società industriale gli oggetti e gli strumenti del lavoro venivano
gestiti direttamente dalla mano e dallʹocchio dellʹuomo; nella Società Introduzione ii
dellʹInformazione questo non accade più, tutto è gestito mediante programmi,
algoritmi, linguaggi. Questo radicale cambiamento richiede innanzitutto che gli individui
imparino ad interagire con questo strumento, imparino cioè a conoscere le modalità con
cui comunicare le proprie richieste all’elaboratore e le modalità con cui l’elaboratore
stesso tratta e gestisce l’informazione. Se da un lato è banale rendersi conto di come per
immergersi in questa nuova situazione siano necessarie delle forti capacità adattive,
dall’altro lato è inprescindibile la necessità che l’elaboratore stesso definisca il processo
di interazione in maniera tale da rendere quanto più immediato possibile tutto ciò.
Non è per nulla casuale infatti che la diffusione dei PC, lo sviluppo
dell’informatica, la nascita della New Economy, l’affermazione di Internet come
strumento di comunicazione di massa siano tutte conseguenze dirette del progressivo
processo di avvicinamento dell’uomo all’elaboratore, che a sua volta è conseguenza del
progressivo processo di semplificazione delle modalità con cui gli individui
interagiscono con il PC. Se percorriamo a ritroso la storia dell’informatica, infatti, ci
rendiamo conto di come negli anni ‘50 l’interazione tra l’individuo e la macchina
avveniva attraverso terminali a riga di comando. Lo sviluppo delle prime interfacce
grafiche risale invece a più di vent’anni dopo, intorno al 1970, quando iniziano ad
affacciarsi sul panorama informatico i sistemi a finestre e le cosiddette interfacce WIMP
(acronimo di Window, Icon, Menu, Pointer). Il mouse nascerà solo più tardi, intorno al
1985, e da quel momento in poi il connubio mouse‐tastiera sarà il simbolo dello
sviluppo e della diffusione dei PC, tanto che ancora oggi quest’accoppiata è vista come
la modalità più “naturale” per utilizzare gli strumenti informatici ed accedere alla Rete.
Nonostante questo, però, il panorama dello stato dell’arte dei dispositivi di
input non è rimasto statico, anzi, la ricerca è continuata sempre nell’ottica del
rinnovamento e della semplificazione delle modalità di interazione tra gli individui e le
macchine, permettendo di sviluppare dispositivi utili ed assolutamente innovativi,
come nel caso degli head‐tracker e degli eye‐tracker. L’idea alla base di questi strumenti è essenzialmente quella di tracciare,
attraverso fasci di infrarossi, i movimenti (degli occhi o del capo) dell’utente sul
Introduzione iii
display determinando il comportamento del sistema sulla base dei dati acquisiti.
Dispositivi di questo tipo nascondono, dietro un funzionamento apparentemente
banale, una doppia utilità: da un lato permettono di interagire con le macchine in una
maniera indubbiamente più naturale rispetto quella a cui siamo abituati, ma,
soprattutto fanno sì che ciò non sia una prerogativa esclusiva degli individui
normodotati ma sia possibile, viceversa, anche per esempio a tutti coloro i quali non
possono utilizzare gli arti superiori.
Il problema dell’accesso alle risorse informatiche da parte degli individui
diversamente abili, infatti, è un problema importante ed attuale. Continuando il
parallelo con il XV secolo i riconoscimenti ricevuti da Gutenberg non sono dovuti tanto
al valore dell’invenzione in sè, quanto, viceversa, all’aver reso l’invenzione e i benefici
conseguenti all’innovazione fruibili e percepibili da tutti. Così come, dunque, i benefici della “rivoluzione” della stampa sono stati
percepiti solo dopo aver permesso a tutte le fasce sociali di poter fruire
dell’innovazione, allo stesso modo i benefici della rivoluzione informatica saranno
percepibili concretamente nel momento in cui anche gli individui diversamente abili
potranno utilizzare le risorse informatiche (ed Internet in particolar modo) senza
vincoli di alcun tipo. Alla luce di questo, dunque, appare inprescindibile come l’idea
del Web universale ed aperto a tutti sia possibile solo come conseguenza di scelte
progettuali orientate all’accessibilità e all’universalità dello strumento su cui i
contenuti e i servizi offerti dalla Rete sono quotidianamente veicolati: i Web Browser.
Scopo di questa tesi, dunque, sarà quello di illustrare in che modo, nell’ambito di
un progetto più ampio riguardante la realizzazione di un Browser che permetta la navigazione
su Internet mediante l’ausilio di un dispositivo di input head‐controlled, sono stati trattati i
problemi relativi alla gestione e alla localizzazione di tutte le componenti sensibili (link, form,
ecc.) che popolano le pagine Web presenti sulla Rete.
Introduzione iv
Nel capitolo 1 si cercherà di introdurre il tema dell’accesso alle risorse
informatiche e al Web da parte degli individui diversamente abili sotto un punto di
vista prettamente legislativo. Saranno illustrate tutte le recenti direttive italiane (vedi la
Legge Stanca) ed europee mettendole in relazione con le iniziative del W3C (il
consorzio che stabilisce gli standard del Web) in tema di Accessibilità.
Nel capitolo 2 sarà analizzato lo stato dell’arte dei dispositivi di input
assistivi, ausili che permettono ad un individuo diversamente abile di utilizzare gli
strumenti informatici alla pari dei normodotati. Nella seconda parte del capitolo si
focalizzerà l’attenzione sui browser appositamente progettati per assistere individui
con disabilità e verrà fornita una panoramica dei prodotti attualmente disponibili.
Nel capitolo 3 si inizieranno ad introdurre le scelte progettuali che hanno
portato alla realizzazione del browser assistivo. Saranno illustrate le caratteristiche del
browser Mozilla Firefox, la bontà del progetto, la sua architettura e i termini sotto cui è
licenziato, confrontandolo con gli altri browser attualmente esistenti. Successivamente
si cercherà di motivare la scelta di partire proprio da Firefox e di realizzare
un’estensione che permetta di integrare nel browser la possibilità di navigare sul Web
attraverso dispositivi di input assistivi.
Nel capitolo 4 saranno trattate specificatamente tutte le problematiche
relative alla gestione e alla localizzazione delle componenti sensibili presenti all’interno
delle pagine Web. Si illlustrerà in che modo indicizzare ciascun collegamento
ipertestuale individuandone la posizione sfruttando opportune proprietà del
linguaggio DOM. Nella seconda parte del capitolo verrà mostrato in che modo,
attraverso il linguaggio XUL, l’interfaccia del browser è stata adattata per semplificare
la navigazione sulla Rete anche in assenza di un normale dispositivo di puntamento.
Nel capitolo 5 saranno illustrati i risultati della Sperimentazione del browser
su un campione di utenti sufficientemente eterogeneo, con l’obiettivo di valutare la
Introduzione v
bontà del prodotto sviluppato studiando in che modo la presenza di un browser
assistivo influenzi il tempo necessario a portare a termini generici task di navigazione,
e di compilazione form.
Nella capitolo 6, infine, si partirà dai risultati della valutazione sperimentale
per tirare le conclusioni sul lavoro realizzato tracciando anche delle linee guida ben
definite per determinare gli sviluppi futuri del sistema. Introduzione vi
Indice
Introduzione............................................................................................................................... i
Indice........................................................................................................................................... vi
Elenco delle figure................................................................................................................. viii
Elenco delle tabelle ................................................................................................................... xi
Capitolo 1: Lʹimportanza dellʹaccessibilità......................................................................... 1
1.1 Lʹuniversalità del Web ......................................................................................... 1
1.2 Disabilità: numeri e statistiche ............................................................................ 3
1.3 Le direttive per lʹaccessibilità .............................................................................. 5
1.3.1 WAI – Web Accessibility Initiative .......................................................... 8
1.3.2 WCAG 1.0 – Web Content Accessibility Guidelines ............................. 9
1.3.3 La legislazione italiana ............................................................................. 26
Bibliografia Capitolo 1 ............................................................................................................... 29
Capitolo 2: Gli ausili per la disabilità ................................................................................ 31
2.1 Le tecnologie assistive .................................................................................. 31
2.1.1 I sistemi di riconoscimento Braille ...................................... 34
2.1.2 I sistemi di sintesi vocale ...................................................... 38
2.1.3 I sistemi di magnificazione .................................................. 42
2.1.4 Sistemi di puntamento alternativi ...................................... 44
2.2 Applicazioni: I Web Browser ...................................................................... 48
2.2.1 I browser assistivi ….............................................................. 51
2.2.2 I browser ad elevata accessibilità ........................................ 55
Bibliografia Capitolo 2 ............................................................................................................... 58
Capitolo 3: Progettazione di un browser assistivo ........................................................... 62
3.1 Motivazioni e scopo: lʹidea di base ............................................................. 62
3.2 Analisi comparativa dei browser ................................................................ 64
Introduzione vii
3.3 Lʹambiente di lavoro: Mozilla Firefox ........................................................ 67
3.3.1 MFL: Mozilla Foundation License ...................................... 69
3.3.2 Gecko: il motore di rendering .............................................. 70
3.3.3 Architettura e componenti ................................................... 73
3.3.4 Sviluppo di temi ed estensioni ............................................ 79
Bibliografia Capitolo 3 ............................................................................................................... 82
Capitolo 4: Implementazione di un Algoritmo di Localizzazione ................................ 85
4.1 Il problema della localizzazione ................................................................. 85
4.2 Uno scenario dʹuso ........................................................................................ 90
4.3 Descrizione della strategia risolutiva ......................................................... 94
4.3.1 Indicizzazione delle componenti della pagina .................. 96
4.3.2 Localizzazione delle componenti e calcolo della distanza…...101
4.3.3 Gestione dei collegamenti ipertestuali ............................. 108
4.3.4 Gestione delle form ............................................................. 113
4.4 Pacchettizzazione dellʹestensione ............................................................. 120
Bibliografia Capitolo 4 ............................................................................................................. 126
Capitolo 5: Sperimentazione ……………………………………….................................. 128
5.1 Introduzione ………………….................................................................... 128
5.2 Preparazione …………………………........................................................ 130
5.2.1 Descrizione della popolazione ……………….................. 130
5.2.2 Descrizione dell’ambiente di lavoro ………………..…... 131
5.2.3 Descrizione dei task …………………................................ 133
5.3 Esecuzione ………………………............................................................... 139
5.3.1 Acquisizione dei dati ………….......................................... 143
5.3.2 Riflessioni e considerazioni ……………………………… 145
Bibliografia Capitolo 5 ............................................................................................................. 153
Capitolo 6: Sviluppi futuri e conclusioni ……………………….................................... 154
Ringraziamenti ........................................................................................................................ xii
Introduzione viii
Elenco delle Figure
fig. 1 – Un display Braille ....................................................................................................... 35
fig. 2 – Una tastiera Braille …………………………………………………………………. 36
fig. 3 – Etichette in rilievo …………………………………………………………………... 37
fig. 4 – Una stampante Braille ……………………………………………………………… 37
fig. 5 – JAWS, uno screen reader …………………………………………………………... 40
fig. 6 – Microfono con cuffie, necessario per utilizzare Sistemi di Voice Recognition .. 42
fig. 7 – Un software di Screen Magnification …………………………………………….. 44
fig. 8 – Un sistema di eye‐tracking invasivo ……………………………………………… 46
fig. 9 – L’eye‐tracker prodotto dalla Tobii, un sistema di tracking non invasivo …….. 47
fig. 10 – Un head‐pointer …………………………………………………………………… 48
fig. 11 – Una schermata di BrookesTalk …………………………………………………... 52
fig. 12 – Una schermata di IBM Home Page Reader ………...…………………………... 52
fig. 13 – Il Sito Web del Dipartimento di Informatica dell’Università di Bari ………… 53
fig. 14 – Una schermata di MozBraille con la Fake Braille Terminal …………………... 54
fig. 15 – www.hattrick.org su Lynx, un sito con Frame non accessibile ………...…….. 56
fig. 16 – www.repubblica.it su Lynx, un sito navigabile ma non accessibile ……...….. 57
fig. 17 – http://informatica.uniba.it su Lynx, un sito accessibile ……...………………... 57
fig. 18 – Un’immagine celebrativa festeggia i 100 milioni di download di Firefox …... 67
fig. 19 – Schema del flusso di Dati in Gecko ……………………………………………… 71
fig. 20 – Architettura concettuale della Mozilla Application Suite …………………….. 73
fig. 21 – Componente di gestione del Layout e del Rendering …………………………. 74
fig. 22 – Componente di gestione del Networking e della sicurezza …...……………... 75
fig. 23 – Componenti che interagiscono direttamente con il sistema …...……………... 76
fig. 24 – Componenti che interagiscono direttamente con l’utente ………………...….. 77
fig. 25 – Un punto dello schermo: solo una coppia di valori ? ………………………..... 90
fig. 26 – Situazione 1: un solo link nell’intorno della fissazione ……………………….. 91
fig. 27 – Situazione 2 : più link nell’intorno della fissazione …………………………… 92
fig. 28 – I bottoni della toolbar di Mozilla Firefox ………………………………………. 93
Introduzione ix
fig. 29 – Gli elementi della form sono troppo vicini tra loro ……………………………. 93
fig. 30 – L’analizzatore DOM di Mozilla Firefox …………………...……………………. 97
fig. 31 – Il vettore dei collegamenti ipertestuali nell’interfaccia Document ……...…… 98
fig. 32 – Una sola form su www.google.it …………………………...………………….. 100
fig. 33 – Il vettore degli elementi della Form ……………………………………………. 100
fig. 34 ‐ I valori degli attributi offset per il link “Immagini” di Google.it ……………. 102
fig. 35 – Un piano cartesiano classico, con i valori limitati a 1024 x 768 …...………… 104
fig. 36 – Qual è la localizzazione del punto ? …………………………………………… 104
fig. 37 – Processo di localizzazione di un link …………………………………………... 105
fig. 38 – Ecco localizzati i quattro punti del collegamento ipertestuale ……………… 106
fig. 39 – Magnificazione dei quattro link individuati nell’intorno ……………………. 110
fig. 40 – La nuova interfaccia di Mozilla Firefox con i bottoni magnificati ………….. 110
fig. 41 – Il motore di ricerca delle immagini di Altavista ……………………………… 115
fig. 42 – Bottone che invoca il modulo di gestione delle form ………………………… 117
fig. 43 – Modulo di Gestione delle Form: tastiera a scomparsa ……………………….. 117
fig. 44 – Modulo di Gestione delle Form: selezione textarea ………………………….. 118
fig. 45 – Modulo di Gestione delle Form: selezione checkbox…………………………. 118
fig. 46 – Modulo di Gestione delle Form: menu di selezione …………………………. 118
fig. 47 – Modulo di Gestione delle Form: selezione di un opzione.…………………… 119
fig. 48 – La procedura di installazione delle estensioni Firefox ………………………. 124
fig. 49 – Il TrackerOne® prodotto da Madentec Technologies ……………………….. 132
fig. 50 – Installazione di TrackerOne® sul PC ………………………………………….. 132
fig. 51 – Fac‐Simile del Questionario A , prima facciata ……………………………….. 140
fig. 52 – Fac‐Simile del Questionario A , seconda facciata ………...…………………... 141
fig. 53 – Fac‐Simile del Questionario A , prima facciata ……………………………….. 142
fig. 54 – Fac‐Simile del Questionario A , seconda facciata …………………………….. 143
fig. 55 – Il modulo di registrazione dei dati acquisiti ………………………………….. 145
fig. 56 – Dimestichezza del campione selezionato con gli strumenti informatici…… 146
fig. 57 – Dimestichezza del campione selezionato con il browser Mozilla Firefox …. 147
fig. 58 – Opinioni del campione sull’utilità del software per individui disabili …….. 147
fig. 59 – Opinioni del campione sull’utilità del software per individui normodotati.. 148
fig. 60 – Dimestichezza del campione selezionato con i dispositivi di head‐pointing..148
fig. 61 – Confronto tra i tempi registrati durante la sessione di sperimentazione…… 149
fig. 62 – Confronto tra i tempi registrati per i task di semplice navigazione ……...… 150
Introduzione x
fig. 63 – Confronto tra i tempi registrati su Repubblica.it e Istruzione.it …………….. 150
fig. 64 – Confronto tra i tempi registrati per i task di compilazione form …………… 151
fig. 65 – Confronto tra i tempi registrati su Yahoo.it e Gazzetta.it ……..…………….. 151
fig. 66 – Impatto del browser sul campione …………………………………………….. 154
fig. 67 – Previsioni sull’impatto del browser su individui diversamente abili ……… 155
fig. 68 – Preferenze del campione sulle componenti del browser da migliorare ……. 156
fig. 69 – Preferenze del campione sulle nuove componenti da implementare ……… 158
fig. 70 – Opinioni del campione sulla diffusione della modalità d’interazione ……... 159
Introduzione xi
Elenco delle Tabelle
tabella 1 ‐ Indagine del 2002 sull’utilizzo della Rete da parte dei disabili ……………... 4
tabella 2 – Calcolo della distanza su www.google.it – Primo Scenario ……………….109
tabella 3 – Calcolo della distanza su www.google.it – Secondo Scenario ………….... 109
tabella 4 ‐ Tabulazione dei task previsti per la procedura di sperimentazione …….. 138
tabella 5 – Tabulazione dei dati acquisiti durante la sessione di sperimentazione…...152
Capitolo 1 ‐ L’importanza dell’accessibilità 1
Capitolo 1
L’importanza dell’accessibilità
1.1 L’universalità del Web
Il World Wide Web costituisce il principale fenomeno tecnologico, economico e
sociale di questi ultimi anni. Sebbene sotto un punto di vista prettamente cronologico
esso sia stata solo l’ultima funzionalità di Internet ad essere realizzata, è indubbio che il
recente successo di Internet stesso sia dovuto principalmente al boom del Web, vero
elemento trainante per lo sviluppo di questa tecnologia.
Quantificare con precisione il numero dei reali utilizzatori della Rete è un
operazione difficile [1]: Si tratta di una cifra in continuo aumento, cresciuta negli ultimi
cinque anni del 146% e stimata da una recente statistica in 880 milioni. E’ più che probabile, però, che solo una piccola parte di questi utenti conosca
con precisione le origini di questo strumento di cui quotidianamente fruisce, e che
ancora meno siano quelli a conoscenza degli scopi con cui Internet e il World Wide
Web siano stati originariamente creati.
Quasi nessuno infatti potrebbe immaginare che il Web, quella Babele elettronica
in cui oggi avvengono transazioni economiche e in cui viaggiano tutte le informazioni
digitali, era stato originariamente ideato come uno dei tanti programmi accademici per
lo scambio di file, ed è ancora più difficile immaginare oggi il Web come un fenomeno
noto solo a poche decine di informatici e racchiuso nei confini di laboratori e
università.
La storia del Web [2], però, è proprio questa, e inizia nel 1989 quando Tim
Berners Lee, ricercatore presso il CERN di Ginevra, concepisce l’idea di realizzare un
sistema di distribuzione e condivisione di documenti sulla rete definendo degli Capitolo 1 ‐ L’importanza dell’accessibilità 2
standard per lo scambio di informazioni: Un protocollo (HTTP – Hyper Text Transfer
Protocol) e un linguaggio di markup (HTML – Hyper Text Markup Language).
Nel corso del tempo, però, la natura e la caratterizzazione del Web si è
progressivamente evoluta, allontanandosi passo dopo passo da una dimensione legata
a doppio filo coi laboratori di ricerca e le Università, avvicinandosi sempre più verso le
case, gli utenti comuni, le piccole operazioni di ogni giorno.
Oggi, a sedici anni di distanza, il Web si è affermato come uno strumento di
comunicazione di massa che ha profondamente modificato le nostre abitudini,
diventando una risorsa chiave per l’ acquisizione di informazioni (notizie, commercio,
svago), la formazione (sistemi di e‐learning), il lavoro (ricerca di lavoro, interazione
con i colleghi), la partecipazione civica (normative, esercizio del diritto di voto, e‐
government), soprattutto soppiantando quasi totalmente le fonti di informazione
tradizionali.
Uno degli obiettivi principali dei pionieri del Web, però, fin dalla sua nascita, è
stato quello di garantire che questa miniera di informazioni presenti sulla Rete
risultasse essere fruibile indistintamente a tutti gli individui, sia che si trattasse di
pochi ricercatori universitari, sia che si trattasse di centinaia di milioni di utenti
collegati da tutto il mondo. E’ nel 1989 , infatti, che Tim Berners Lee ha affermato: ʺThe power of the Web is in its universality. Access by everyone regardless of disability
is an essential aspect.ʺ
Il potere del Web è nella sua universalità. L’accesso da parte di tutti, a
prescindere dalle loro disabilità, è un aspetto essenziale. Il principio ispiratore di Tim Berners Lee in questa affermazione è quello della
progettazione universale [3]. Tale concetto trova la sua origine in architettura e nel
design dei prodotti, dove le scelte progettuali intraprese devono essere orientate a
soddisfare un numero di utenti quanto più grande possibile. I progettisti che applicano
Capitolo 1 ‐ L’importanza dell’accessibilità 3
il principio della progettazione universale creano edifici e prodotti che sono concepiti
allʹorigine per essere usati da tutti gli individui, compresi quelli con disabilità. La
pianificazione a priori delle necessità dei diversi utenti evita di effettuare interventi a
posteriori sulle strutture esistenti per abbattere le barriere che sono di ostacolo alla
fruizione da parte di qualche sottoinsieme della popolazione, e questo concetto, in
senso lato, deve essere seguito in tutti gli ambiti cui i principi di progettazione
universale possono essere applicati, passando anche per tutto ciò che concerne il Web.
Basta un rapido giro sulla Rete, però, per accorgersi di quanto la veridicità di
questa affermazione sia minima. Il Web, nella situazione odierna, non è universale.
Molto spesso la fruizione degli strumenti, delle informazioni e dei documenti che il
Web mette a disposizione non è possibile a determinate categorie di utenti che invece
potrebbero trarre dall’uso di Internet una possibilità di emancipazione e
socializzazione a loro troppe volte precluse. Il Web permetterebbe loro di attivare
esperienze di scambio interpersonale finalizzate a superare le barriere e gli ostacoli che
la disabilità pone, le tecnologie informatiche, invece, possono svolgere un ruolo‐chiave
per migliorare la riabilitazione e lʹintegrazione scolastica, lavorativa e sociale delle
persone portatrici di handicap fisici e psichici.
Sono tantissime le categorie di disabili influenzate dalle barriere tecniche e
fisiche che il web può porre (non vedenti, ipovedenti, daltonici, sordi, persone con
impossibilità motoria agli arti superiori, ecc.) , sono tantissime le categorie di disabili
che, nella situazione odierna, si vedono esclusi dal mondo della Rete. [4]
1.2
Disabilità: Numeri e Statistiche
Si stima [5] che in Italia vi siano circa 2 milioni 824 mila disabili, di cui 960 mila
uomini e 1 milione 864 mila donne. Il numero di disabili (di 6 anni o più) che vive in
famiglia è di circa 2 milioni 615 mila unità, pari al 4,85% della popolazione. Di questi il
33% (894 mila persone, il 3,4% della popolazione) è rappresentato dal sesso maschile e
il restante 67% (1 milione 721 mila, il 6,2% della popolazione) da quello femminile. La
disabilità riguarda prevalentemente le persone di 60 anni e più: risulta disabile il 17%
4
Capitolo 1 ‐ L’importanza dell’accessibilità degli ultrasessantenni (2 milioni 57 mila individui) e il 37,7% delle persone di 75 anni e
più. I disabili di età inferiore ai 60 anni sono 620 mila, in particolare 188 mila hanno
fino a 14 anni. Le difficoltà nella sfera della comunicazione, quali lʹincapacità di vedere,
sentire o parlare, coinvolgono circa lʹ1% della popolazione di 6 anni e più. Al fine di
conoscere il numero dei ciechi e dei sordi, è possibile analizzare anche i dati relativi
alle invalidità permanenti rilevate sempre con lʹindagine sulle condizioni di salute,
dalla quale risultano circa 352 mila ciechi totali o parziali, 877 mila persone con
problemi dellʹudito più o meno gravi e 92 mila sordi prelinguali (sordomuti). Ben il
33% dei disabili è portatore di almeno due disabilità contemporaneamente fra
disabilità nelle funzioni, disabilità nel movimento e disabilità sensoriali L’Istituto Nazionale di Statistica [6] in una recente indagine del 2002 ha inoltre
cercato di valutare e quantificare l’impatto di Internet e delle nuove tecnologie su
soggetti affetti da disabilità, somministrando un insieme di quesiti relativo all’utilizzo e
alla dimestichezza con questo tipo di strumenti. I risultati dell’indagini sono
schematizzati in tabella: Persone disabili e non disabili di 18 anni e più, che usano internet, per classi di età (2002)
Da 18 a 44 anni
Spesso
Disabili
19,6 Non Disabili
34,5
Da 18 a 44 anni
Qualche volta
Disabili
5,0 Non Disabili
8,6
Da 18 a 44 anni
Mai
Disabili
71,0 Non Disabili
54,7
Da 18 a 44 anni
Non indicato
Disabili
4,4 Non Disabili
2,1
Da 45 a 64 anni
Spesso
Disabili
8,4 Non Disabili
14,5
Da 45 a 64 anni
Qualche volta
Disabili
1,7 Non Disabili
4,5
Da 45 a 64 anni
Mai
Disabili
87,6 Non Disabili
78,6
Da 45 a 64 anni
Non indicato
Disabili
2,3 Non Disabili
2,3
Da 65 anni in poi
Spesso
Disabili
0,5 Non Disabili
1,5
Da 65 anni in poi
Qualche volta
Disabili
0,1 Non Disabili
0,3
Da 65 anni in poi
Mai
Disabili
96,9 Non Disabili
96,3
Da 65 anni in poi
Non indicato
Disabili
2,4 Non Disabili
1,9
Totale
Spesso
Disabili
4,6 Non Disabili
22,1
Totale
Qualche volta
Disabili
1,1 Non Disabili
5,8
Totale
Mai
Disabili
91,6 Non Disabili
69,9
Totale
Non indicato
Disabili
2,7 Non Disabili
2,1
(Tabella 1: Indagine del 2002 sull’utilizzo della Rete da parte di individui diversamente abili)
Capitolo 1 ‐ L’importanza dell’accessibilità 5
Secondo i dati del Rapporto Federcomin E‐family 2001, inoltre, a giugno 2001 il
numero di utilizzatori di PC in casa ha raggiunto i 12 milioni, pari al 21 per cento della
popolazione italiana, e Il recente ʺRapporto statistico sulla società dellʹinformazione in
Italiaʺ [7] del Ministero per lʹinnovazione e le tecnologie cita una ricerca dello studio
Nielsen nella quale si è provato a ʺquantificare il numero di disabili che vengono
esclusi dalle barriere digitali incontrate nell’utilizzo della rete. Secondo lo studio quasi
il 20% dei disabili mostra una buona attitudine a navigare su Internet, di conseguenza
un sito non adeguatamente accessibile esclude un pubblico già oggi potenzialmente
ricettivo di circa 530.000 persone.ʺ
Unʹaltra indagine della US National Organization on Disability, nel 2000, ha
messo in evidenza che il 48% dei disabili trova che la navigazione in Internet migliori
in modo significativo la qualità della vita, contro un corrispondente 27% degli utenti
non disabili.
Infine uno studio inglese (Leonard Cheshire Charity Org.) del 2002 afferma che
lʹaccesso ad Internet viene considerato essenziale dal 54% dei disabili, contro il solo 6%
della restante popolazione. [8]
Sulla base di questi risultati ci si può subito rendere conto dell’estrema
importanza che gli individui diversamente abili ripongono nella tecnologia, e
confermano lʹidea che attribuisce alle nuove tecnologie un ruolo fondamentale in un
progressivo processo di integrazione di ampie fasce di cittadini utenti svantaggiati. 1.3
Le Direttive per l’Accessibilità
Prima di affrontare specificatamente il problema dell’accessibilità applicato al
Web, è necessario fare delle premesse di carattere generale riguardanti il concetto
stesso di accessibilità: La progettazione orientata all’accessibilità non è un fatto
meccanico, è un qualcosa di sostanzialmente differente dall’applicazione di semplici
indicazioni, concetti e linee guida finalizzate a garantire un sufficiente livello di
conformità a determinati standard. Capitolo 1 ‐ L’importanza dell’accessibilità 6
Progettare per l’accessibilità [9] richiede soprattutto una grande conoscenza
delle disabilità, degli individui, e delle tipologie di problematiche che questi possono
incontrare nella fruizione degli strumenti che il Web mette a disposizione. In altri
termini, è fondamentale che il progettista abbia una forte esperienza in materia che
vada oltre la meccanicità dell’applicazione semplici regole e che guidi in maniera
appropriata la composizione dei documenti per garantire la fruizione degli stessi a tutti
gli individui, a prescindere dalle loro disabilità.
Va comunque sottolineato che creare documenti accessibili non significa
rinunciare a qualcosa, ma al contrario, arricchire il documento stesso con componenti
che lo completino e lo rendano più adatto alla consultazione in qualunque circostanza.
Ad esempio, un documento accessibile ai ciechi non deve essere necessariamente un
documento puramente testuale. Può contenere immagini, grafici, può essere strutturato
in modo razionale; basta che le sue componenti orientate alla vista siano accompagnate
da informazioni alternative che ne descrivano la funzione e che non siano quindi di
impedimento allʹorientamento nel documento stesso.
Il principio fondamentale [10] da applicare ai fini dellʹaccessibilità, dunque, è che gli
autori non devono essere scoraggiati dallʹusare elementi multimediali, ma piuttosto
incoraggiati a farne uso in modo tale da assicurare che quel materiale che essi pubblicano sia
accessibile allʹutenza più vasta possibile o comunque che un elemento che risulti inaccessibile
per qualche classe di utenti non impedisca lʹaccesso ad altre parti di un documento.
La garanzia dellʹaccesso universale al web sta dunque diventando sempre più
argomento di discussione e di studio nellʹambito delle varie comunità che si occupano
del web e del suo sviluppo. Secondo la definizione del W3C, lʹente internazionale che
ha il compito di fissare gli standard del Web il contenuto di un sito web è accessibile
ʺquando può essere usato da qualcuno che ha una disabilitàʺ. Rendere accessibile un sito significa cioè rendere i contenuti disponibili alla più
vasta tipologia di persone e dispositivi; questo comporta adottare una serie di misure e
Capitolo 1 ‐ L’importanza dell’accessibilità 7
di accorgimenti per cui le persone con disabilità di vario tipo e che sono costrette ad
usare software ed hardware particolari non siano penalizzate nellʹuso della Rete. Sempre Tim Berners Lee, recentemente, ha ulteriormente allargato la
definizione, affermando che [11] “il Web deve consentire un accesso paritario a chi si
trova in una situazione economica e politica differente, a chi ha handicap fisici o
cognitivi, a chi appartiene a una cultura diversa e a chi usa lingue diverse con caratteri
diversi che si leggono in diverse direzioni sulla paginaʺ.
Questa affermazione estende il concetto di accessibilità fino a comprendere tutti
quei soggetti che rischiano di essere esclusi dalla fruibilità delle informazioni e degli
strumenti presenti sulla Rete anche in assenza di particolari situazioni di disabilità. Condizioni di affaticamento della vista o di altri sensi, lavoro in ambienti
rumorosi, utilizzo di terminali hardware e software diversi tra loro, navigazione sul
Web con il cellulare, banda limitata, impossibilità di controllare il mouse o dover usare
solo la tastiera, avere a disposizione solo determinate tipologie di dispositivi di input. Si potrebbe continuare a lungo con esempi di questo tipo, ma la conclusione cui
si può giungere a partire dall’affermazione di Tim Berners Lee è una sola:
Lʹaccessibilità non è solo un tema rivolto a soggetti con specifiche necessità ma, anzi,
facilitare il rapporto di tutti con le tecnologie della rete ha un impatto durevole
sullʹintera società.
L’accessibilità è dunque un argomento di assoluta importanza [12]. Importanza
innanzitutto sociale, ma anche importanza tecnologica e importanza economica, poiché
l’elevato numero di portatori di handicap costituisce un’importante fetta di mercato. La
progettazione che tiene conto dei potenziali handicap è una scelta che a lungo termine
porta dei benefici a tutti gli utenti quando, per esempio, si trovano in condizioni
ambientali difficili (dispositivi mobili, eccessiva illuminazione, elevato rumore di
fondo, banda limitata, mani e occhi impegnati).
Quindi l’ accessibilità contribuisce ad una migliore progettazione per tutti gli
utenti, coerentemente proprio con uno dei principi fondamentali del Web, proprio
quell’ Universal Access sottolineato più volte da Tim Berners Lee.
Capitolo 1 ‐ L’importanza dell’accessibilità 8
1.3.1 WAI – Web Accessibility Initiative
Uno degli strumenti operativi più importanti in tema di accessibilità risale al
1999 quando il W3C (World Wide Web Consortium) ha creato la Web Accessibility
Initiative, un’iniziativa finalizzata a definire formalmente una serie di informazioni
utili a tutti coloro i quali volessero garantire la piena accessibilità ai propri siti Internet. Lʹiniziativa WAI consiste nello sviluppare soluzioni per Internet destinate alle
persone colpite da handicap visivi, uditivi, fisici, mentali, cognitivi o neurologici, ma,
in generale, si tratta di raccomandazioni finalizzate a garantire la fruibilità delle
informazioni a tutti i potenziali utenti della Rete.
Il problema dell’accessibilità del Web è un problema caratterizzato da vari
livelli di granularità [13]; In conseguenza di ciò il WAI, insieme ad enti ed
organizzazioni di tutto il mondo, ha cercato e cerca tuttora di perseguire il proprio
obiettivo mediante la cooperazione di cinque differenti aree di lavoro, ognuna delle
quali orientata a illustrare tecniche, linee guida, o, in generale, i requisiti
dell’accessibilità sotto un differente punto di vista. Le cinque aree di lavoro sono:
•
Garantire che le Tecnologie del Web garantiscano l’accessibilità
•
Sviluppare delle Linee Guida per l’accessibilità
•
Mettere a punto strumenti per valutare o correggere l’accessibilità del
Web
•
Istruire la Comunità del Web enfatizzando l’importanza
dell’Accessibilità
•
Coordinare Ricerca e Sviluppo
Capitolo 1 ‐ L’importanza dell’accessibilità 9
In generale si tratta dunque di cinque aree di lavoro finalizzate a sottolineare
l’importanza l’accessibilità in tre modi differenti, mediante tre diverse tipologie di linee
guida: •
Costruendo siti Web con contenuti accessibili (Web Content Accessibilty
Guidelines – WCAG 1.0)
•
Sviluppando tool che permettano la produzione di siti Web Accessibili
(Authoring Tools Accessibility Guidelines – ATAG 1.0)
•
Progettando browser che garantiscano l’accessibilità (User Agent
Accessibility Guidelines – UAAG 1.0)
1.3.2 WCAG 1.0 – Web Content Accessibility Guidelines
Le Web Content Accessibility Guidelines [14] sono ormai assunte come standard de
facto per la definizione dei criteri di accessibilità dei siti.
Si tratta di linee guida che illustrano come rendere accessibili a persone disabili
i contenuti del Web. Indirizzate sia per gli sviluppatori di contenuti (progettisti di siti
Web, autori di pagine Web) che per gli sviluppatori di strumenti di authoring, le
WCAG 1.0 definiscono un insieme di “regole” finalizzate a rendere i contenuti del Web
più facilmente fruibili da tutti gli utenti, a prescindere dal particolare strumento
utilizzato per la navigazione (browser normali, browser basati su dispositivi di sintesi
vocale, terminali mobili, ecc.) , o da particolari situazioni in cui possono essere costretti
(ambienti rumorosi, stanze poco illuminate o sovrailluminate, ambienti in cui occorra
avere le mani libere, ecc.).
Il conformarsi a queste linee guida consentirà agli utenti di reperire sul Web
informazioni in maniera più veloce, semplice ed immediata.
Le linee guida illustrate dalle WCAG si basano su due principi generali:
assicurare una trasformazione elegante e rendere il contenuto comprensibile e navigabile.
Capitolo 1 ‐ L’importanza dell’accessibilità 10
Una generica pagina Web, per definizione, garantisce una trasformazione
elegante se il suo contenuto rimane accessibile anche in presenza di limitazioni fisiche,
sensoriali o dell’apprendimento, limitazioni causate dal lavoro o limitazioni dovute a
barriere tecnologiche. Le prime 11 linee guida WCAG si riallacciano a questo concetto.
Il secondo principio invece sottolinea l’importanza di rendere il contenuto sempre
comprensibile e navigabile mediante una serie di accorgimenti: Adottare un linguaggio
semplice, fornire meccanismi facilmente comprensibili per la navigazione allʹinterno
della stessa pagina e tra pagine diverse, dotare le pagine di strumenti di navigazione e
informazioni di orientamento massimizzandone lʹaccessibilità e lʹutilizzabilità. Non
tutti gli utenti sono in grado di utilizzare indicazioni visive come immagini sensibili,
barre di scorrimento proporzionali, frame affiancati, o comunque elementi grafici che
guidano gli utenti vedenti dei normali browser grafici. Gli utenti possono inoltre
perdere informazioni relative al contesto qualora possano vedere solo una parte della
pagina, ad esempio perché accedono alla pagina una parola per volta (sintesi vocale o
display braille), oppure una sezione alla volta (schermi assai piccoli oppure ingranditi
molte volte). Senza informazioni che favoriscano lʹorientamento, tabelle di grandi
dimensioni, elenchi, menu, ecc. possono non essere comprensibili da parte di alcune
categorie di utenti. Le linee guida 12‐14 si occupano principalmente dei principi per
rendere il contenuto navigabile e comprensibile. Per ciascuna delle 14 linee guida vengono elencate le definizioni di alcuni
checkpoint (65 in totale) [15], che spiegano come applicare la guideline nei tipici scenari
di sviluppo dei contenuti. I singoli checkpoint sono caratterizzati da un priority level
(1,2,3).
•
Priorità 1
Lo sviluppatore di contenuti Web deve conformarsi al presente punto di
controllo. In caso contrario, a una o più categorie di utenti viene precluso
lʹaccesso alle informazioni presenti nel documento. La conformità a questo
punto di controllo costituisce un requisito base affinché alcune categorie di
utenti siano in grado di utilizzare documenti Web. Capitolo 1 ‐ L’importanza dell’accessibilità •
11
Priorità 2
Lo sviluppatore di contenuti Web dovrebbe conformarsi a questo punto di
controllo. In caso contrario per una o più categorie di utenti risulterà difficile
accedere alle informazioni nel documento. La conformità a questo punto
consente di rimuovere barriere significative per lʹaccesso a documenti Web .
•
Priorità 3
Lo sviluppatore di contenuti Web può tenere in considerazione questo punto di
controllo. In caso contrario, una o più categorie di utenti sarà in qualche modo
ostacolata nellʹaccedere alle informazioni presenti nel documento. La
conformità a questo punto migliora lʹaccesso ai documenti Web.
Sulla base dei checkpoint soddisfatti, a ciascun sito può essere poi associato un
livello di conformità:
•
∙ Level “A”: sono soddisfatti tutti i checkpoint di priorità 1.
•
∙ Level “AA”: sono soddisfatti tutti i checkpoint di priorità 1 e 2
•
∙ Level “AAA”: sono soddisfatti tutti i checkpoint di priorità 1, 2 e 3.
Di seguito sono elencate singolarmente le 14 linee guida WCAG:
Linea Guida 1: Fornire alternative equivalenti per il contenuto visivo e acustico.
Fornire un contenuto che, una volta presentato all’ utente, svolga essenzialmente la stessa
funzione o raggiunga lo stesso scopo del contenuto visivo o acustico.
Questa linea guida rimarca lʹimportanza di fornire equivalenti testuali al
contenuto non testuale (immagini, audio pre‐registrati, video). La potenzialità degli
equivalenti testuali sta nella loro capacità di essere resi secondo modalità accessibili a
Capitolo 1 ‐ L’importanza dell’accessibilità 12
persone con differenti disabilità usando tecnologie diverse. Il testo può essere
velocemente incanalato verso la sintesi vocale e la display braille , e può essere
presentato visivamente (in vari formati) sul video del computer o su carta. La sintesi
vocale è fondamentale per le persone non vedenti e per tutti coloro che hanno quelle
difficoltà nella lettura che spesso accompagnano le disabilità cognitive, di
apprendimento e la sordità. Il braille è essenziale per i sordo‐ciechi e per tutte quelle
persone la cui unica disabilità sensitiva è la cecità. Il testo mostrato visivamente va a
beneficio sia degli utenti sordi, sia della maggioranza degli utenti Web.
Punti di controllo:
1.1 Fornire un equivalente testuale per ogni elemento non di testo (per esempio,
mediante ʺaltʺ, ʺlongdescʺ o contenuto nellʹelemento stesso). Questo comprende:
immagini, rappresentazioni grafiche di testo (compresi i simboli), zone di immagini
sensibili, animazioni (ad es. GIF animate), applets e oggetti programmati, arte ASCII,
frame, script, immagini usate come richiamo per elenchi, spaziatori, bottoni grafici,
suoni (azionati con o senza lʹintervento dellʹutente), file di solo audio, tracce audio di
video e video. [Priorità 1] 1.2 Fornire ridondanti collegamenti di testo per ogni zona attiva di una immagine
sensibile sul lato server. [Priorità 1] 1.3 Fino a quando gli interpreti non potranno leggere automaticamente ad alta voce
lʹequivalente testuale di un filmato, fornire una descrizione audio delle informazioni
essenziali del filmato di una presentazione multimediale. [Priorità 1] 1.4 Per ogni presentazione multimediale temporizzata (per es. un film o una
animazione), sincronizzare alternative equivalenti (per es. didascalie o descrizioni
parlate del filmato) con la presentazione. [Priorità 1] 1.5 Fino a quando gli interpreti non renderanno disponibili equivalenti testuali
per collegamenti di immagini sensibili sul lato client fornire collegamenti di testo
ridondanti per ogni zona attiva di una immagine sensibile sul lato client. [Priorità 3] Capitolo 1 ‐ L’importanza dell’accessibilità 13
Linea Guida 2. Non fare affidamento unicamente sul colore.
Assicurarsi che il testo e la parte grafica siano comprensibili se consultati senza il colore
Se viene usato il solo colore per veicolare informazione, le persone che non
possono distinguere fra alcuni colori e utenti che hanno monitor in B&N o non visuali
non riceveranno lʹinformazione. Quando i colori dello sfondo e degli oggetti in primo
piano sono troppo simili per tonalità, potrebbero dare un contrasto non sufficiente se
consultati usando un monitor monocromatico o da persone con varie disabilità
percettive sul colore.
Punti di controllo:
2.1 Assicurarsi che tutta lʹinformazione veicolata dal colore sia disponibile anche
senza, per esempio grazie al contesto o ai marcatori. [Priorità 1] 2.2 Assicurarsi che le combinazioni fra colori dello sfondo e del primo piano
forniscano un sufficiente contrasto se visti da qualcuno con deficit percettivi sul colore
o se visti su uno schermo in bianco e nero. [Priorità 2 per le immagini, Priorità 3 per il
testo].
Linea Guida 3. Usare marcatori e fogli di stile e farlo in maniera appropriata.
Marcare i documenti con gli appositi elementi strutturali. Controllare la presentazione con i
fogli di stile piuttosto che con gli elementi e gli attributi di presentazione
Usare i marcatori in modo improprio ‐ non seguendo le specifiche ‐ impedisce
lʹaccessibilità. Il cattivo uso di marcatori per un effetto di presentazione (p.es. usare una
tabella per lʹimpaginazione o una intestazione per cambiare la dimensione dei
caratteri) rende difficile, per lʹutente con software specialistico, la comprensione
dellʹorganizzazione della pagina o la navigazione attraverso questa. Inoltre, lʹuso di
marcatori di presentazione invece che di marcatori strutturali per veicolare una
struttura (per es. costruire ciò che sembra una tabella di dati con un elemento HTML
PRE) rende difficile la comprensione di una pagina per chi ha altri strumenti di lettura
Capitolo 1 ‐ L’importanza dell’accessibilità 14
Punti di controllo:
3.1 Quando esiste un linguaggio di marcatori adatto, per veicolare informazione
usare un marcatore piuttosto che le immagini. [Priorità 2] 3.2 Creare documenti che facciano riferimento a grammatiche formali pubblicate.
[Priorità 2] 3.3 Usare fogli di stile per controllare lʹimpaginazione e la presentazione.
[Priorità 2] 3.4 Usare unità relative e non assolute nei valori degli attributi del linguaggio dei
marcatori e i valori della proprietà del foglio di stile. [Priorità 2] 3.5 Usare elementi di intestazione per veicolare la struttura del documento e usarli
in modo conforme alle specifiche. [Priorità 2] 3.6 Marcare le liste ed elencare le voci della lista in modo appropriato. [Priorità 2] 3.7 Marcare le citazioni. Non usare marcatura che definisca citazioni per ottenere
effetti di formato come il rientro. [Priorità 2] Linea Guida 4. Rendere chiaro mediante il markup l’ uso del linguaggio naturale.
Utilizzare marcatori che agevolino la pronuncia o l’ interpretazione di testi in lingua straniera
o con abbreviazioni e acronimi.
Quando lo sviluppatore contrassegna in un documento i cambiamenti di
linguaggio naturale, le sintesi vocali e le periferiche braille possono selezionare
automaticamente la nuova lingua, rendendo il documento più accessibile agli utenti
multilingue. Gli sviluppatori dovrebbero identificare il linguaggio naturale principale
del contenuto di un documento (mediante marcatori o intestazioni HTTP). Gli
sviluppatori dovrebbero anche sciogliere le abbreviazioni e gli acronimi. Oltre a
facilitare le tecnologie assistive, contrassegnare il linguaggio naturale permette ai
motori di ricerca di trovare parole chiave e di identificare documenti nel linguaggio
desiderato. Il contrassegno del linguaggio naturale, inoltre, consente a tutti la
Capitolo 1 ‐ L’importanza dell’accessibilità 15
leggibilità del Web, compresi quelli che hanno difficoltà di apprendimento, cognitive e
i sordi. Punti di controllo:
4.1 Identificare con chiarezza i cambiamenti nel linguaggio naturale del testo di un
documento e in ogni equivalente testuale (per es. nelle didascalie). [Priorità 1] 4.2 Specificare lo scioglimento di ogni abbreviazione o acronimo nel documento
laddove compare per la prima volta. [Priorità 3] 4.3 Identificare il linguaggio naturale principale di un documento. [Priorità 3] Linea Guida 5. Creare tabelle che si trasformino in maniera elegante.
Assicurarsi che le tabelle abbiano la marcatura necessaria per essere trasformate dai browser e
da altri user agent.
Le tabelle dovrebbero essere usate per marcare informazioni realmente tabellari
(ʺtabelle di datiʺ). Gli sviluppatori dovrebbero evitare di usarle per lʹimpaginazione
(ʺtabelle di impaginazioneʺ). Le tabelle, in qualsiasi modo siano usate, presentano
anche problemi particolari per gli utenti con lettori di schermo
Punti di controllo:
5.1 Per tabelle di dati, identificare le intestazioni di righe e colonne. [Priorità 1] 5.2 Per tabelle di dati che hanno due o più livelli logici di intestazioni di righe o
colonne, usare marcatori per associare le celle di dati e le celle di intestazione.
[Priorità 1] 5.3 Non usare tabelle per impaginazioni a meno che la tabella non sia
comprensibile se letta in modo linearizzato. Altrimenti, se la tabella non risulta
leggibile, fornire una alternativa equivalente (che può essere una versione linearizzata).
[Priorità 2] 5.4 Se per lʹimpaginazione viene usata una tabella non usare nessun marcatore di
struttura per la formattazione della resa visiva. [Priorità 2] 5.5 Per le tabelle, fornire sommari. [Priorità 3] Capitolo 1 ‐ L’importanza dell’accessibilità 5.6 16
Fornire abbreviazioni per le etichette di intestazione. [Priorità 3] Linea guida 6. Assicurarsi che le pagine che danno spazio a nuove tecnologie si
trasformino in maniera elegante.
Assicurarsi che le pagine siano accessibili anche quando le tecnologie più recenti non sono
supportate o sono disabilitate.
Sebbene gli sviluppatori siano incoraggiati a usare nuove tecnologie che
risolvano problemi creati da tecnologie esistenti, essi dovrebbero sapere come far sì che
le loro pagine funzionino anche con browser più vecchi e con persone che scelgono di
disabilitare alcune caratteristiche. Punti di controllo:
6.1 Organizzare i documenti in modo che possano essere letti senza i fogli di stile.
Per esempio, quando un documento HTML viene reso senza i fogli di stile associati,
deve essere sempre possibile leggere il documento. [Priorità 1] 6.2 Assicurarsi che gli equivalenti del contenuto dinamico vengano aggiornati
quando il contenuto dinamico cambia. [Priorità 1] 6.3 Assicurarsi che le pagine siano utilizzabili quando script, applet, o altri oggetti
di programmazione sono disabilitati oppure non supportati. Se questo non è possibile,
fornire informazione equivalente in una pagina accessibile alternativa. [Priorità 1] 6.4 Per quanto riguarda script e applet, assicurarsi che i gestori di eventi siano
indipendenti dai dispositivi di input. [Priorità 2] 6.5 Assicurarsi che il contenuto dinamico sia accessibile oppure fornire una
presentazione o pagina alternativa. [Priorità 2] Linea guida 7. Assicurarsi che lʹutente possa tenere sotto controllo i cambiamenti di
contenuto nel corso del tempo.
Assicurarsi che gli oggetti in movimento, lampeggianti, scorrevoli o che si autoaggiornano
possano essere arrestati temporaneamente o definitivamente.
Capitolo 1 ‐ L’importanza dell’accessibilità 17
Alcune persone con disabilità cognitive o visive non riescono a leggere testo in
movimento con velocità sufficiente, oppure non sono in grado di leggerlo affatto. Il
movimento può anche causare una distrazione tale da rendere illeggibile il resto della
pagina per persone con disabilità. I lettori di schermo non sono in grado di leggere
testo in movimento. Persone con disabilità fisiche potrebbero non essere in grado di
muoversi con velocità o precisione sufficienti ad interagire con oggetti in movimento. Punti di controllo:
7.1 Fino a quando gli interpreti non permetteranno agli utenti di controllare lo
sfarfallìo, evitare di far sfarfallare lo schermo. [Priorità 1] 7.2 Fino a quando gli interpreti non permetteranno agli utenti di controllare il
lampeggiamento, evitare di far lampeggiare il contenuto (cioè di cambiare la
presentazione a intervalli regolari, come se si accendesse e spengesse). [Priorità 2] 7.3 Fino a quando gli interpreti non permetteranno agli utenti di bloccare il
contenuto in movimento, evitare il movimento nelle pagine. [Priorità 2] 7.4 Fino a quando gli interpreti non forniranno la possibilità di bloccare
lʹautoaggiornamento, non creare pagine che si autoaggiornano periodicamente.
[Priorità 2] 7.5 Fino a quando gli interpreti non forniranno la capacità di bloccare lʹauto‐
reindirizzamento, non usare marcatura per reindirizzare le pagine automaticamente.
Piuttosto, configurare il server in modo che esegua i reindirizzamenti. [Priorità 2] Linea guida 8. Assicurare lʹaccessibilità diretta delle interfacce utente incorporate.
Assicurarsi che la progettazione delle interfacce utente segua i principi dellʹaccessibilità: accesso
alle diverse funzionalità indipendente dai dispositivi usati, possibilità di operare da tastiera,
comandi vocali, ecc.
Quando un oggetto incorporato possiede una ʺsua propria interfacciaʺ,
lʹinterfaccia ‐‐ così come lʹinterfaccia dello stesso browser ‐‐ deve essere accessibile.
Capitolo 1 ‐ L’importanza dell’accessibilità 18
Punto di controllo:
8.1 Fare in modo che elementi di programmi come script e applet siano
direttamente accessibili o compatibili con le tecnologie assistive [Priorità 1 se la
funzionalità è importante e non presentata altrove, altrimenti Priorità 2.]
Linea guida 9. Progettare per garantire lʹindipendenza da dispositivo.
Usare caratteristiche che permettono di attivare gli elementi della pagina attraverso una
molteplicità di dispositivi di input.
Accesso indipendente da dispositivo significa che gli utenti possono interagire
con lʹinterprete o con il documento con il dispositivo di input (output) preferito ‐‐
mouse, tastiera, voce, bacchette manovrate con la testa, o altro. In genere, le pagine che
permettono di interagire tramite tastiera sono accessibili anche tramite input vocale o
interfaccia a linea di comando. Punti di controllo:
9.1 Fornire immagini sensibili sul lato client invece di immagini sensibili sul lato
server, con lʹeccezione dei casi nei quali le zone non possono essere definite con una
forma geometrica valida. [Priorità 1] 9.2 Assicurarsi che ogni elemento che possiede una sua specifica interfaccia possa
essere gestito in una modalità indipendente da dispositivo. [Priorità 2] 9.3 Negli script, specificare gestori di evento logici piuttosto che gestori di evento
dipendenti da dispositivo. [Priorità 2] 9.4 Creare un ordine logico di tabulazione fra i collegamenti, i controlli dei moduli,
e gli oggetti. [Priorità 3] 9.5 Fornire scorciatoie da tastiera per i collegamenti importanti (compresi quelli
nelle immagini sensibili sul lato client), per i controlli dei moduli, e per i gruppi di
controlli dei moduli. [Priorità 3] Capitolo 1 ‐ L’importanza dell’accessibilità 19
Linea guida 10. Usare soluzioni provvisorie.
Usare soluzioni provvisorie in modo che le tecnologie assistive e i browser più vecchi possano
operare correttamente.
Per esempio, i browser più vecchi non permettono agli utenti di spostarsi su
caselle per lʹimmissione di testo vuote. I lettori di schermo più vecchi leggono liste di
collegamenti consecutivi come se fossero un unico collegamento. É quindi difficile se
non impossibile accedere a questi elementi attivi. Punti di controllo:
10.1
Fino a quando gli interpreti non permetterano agli utenti di bloccare la
generazione di nuove finestre, non fare apparire finestre a cascata o di altro tipo e non
cambiare la finestra attiva senza informare lʹutente. [Priorità 2] 10.2
Fino a quando gli interpreti non supporteranno esplicite associazioni fra
etichette e controlli dei moduli, assicurare, per tutti i controlli dei moduli che hanno
etichette associate implicitamente, che lʹetichetta sia posizionata correttamente.
[Priorità 2] 10.3 Fino a quando gli interpreti (comprese le tecnologie assistive) non renderanno in
modo corretto il testo affiancato, fornire un testo lineare alternativo (nella pagina attiva
o in qualche altra) per tutte le tabelle che dispongono testo su colonne parallele e
andando a capo. [Priorità 3] 10.4 Fino a quando gli interpreti non gestiranno in maniera corretta controlli vuoti,
inserire caratteri di default come segnaposto nelle caselle per lʹimmissione di testo a
una riga oppure a più righe. [Priorità 3] 10.5 Fino a quando gli interpreti (comprese le tecnologie assistive) non renderanno in
modo distinto collegamenti adiacenti, inserire caratteri stampabili (delimitati da spazi),
non facenti parte dei collegamenti, per separare i collegamenti adiacenti. [Priorità 3] Capitolo 1 ‐ L’importanza dell’accessibilità 20
Linea guida 11. Usare le tecnologie e le raccomandazioni del W3C.
Usare le tecnologie del W3C (in conformità con le specifiche) e seguire le raccomandazioni
sullʹaccessibilità. Nei casi in cui non sia possibile usare una tecnologia del W3C, oppure se
nellʹutilizzarla si ottenesse materiale che non si trasforma in maniera elegante, fornire una
versione alternativa del contenuto che sia accessibile.
Questa linea guida raccomanda tecnologie del W3C (per es. HTML, CSS ecc.)
per diversi motivi: le tecnologie W3C contengono elementi di accessibilità ʺintegratiʺ, le
specifiche W3C subiscono una revisione preliminare per assicurarsi che gli elementi di
accessibilità siano presi in considerazione fin dalla fase progettuale, le specifiche W3C
sono sviluppate allʹinterno di un processo aperto e con il consenso dellʹindustria del
settore. Punti di controllo:
11.1 Usare le tecnologie W3C quando sono disponibili e sono appropriate per un certo
compito e usare le versioni più recenti quando sono supportate. [Priorità 2] 11.2 Evitare le caratteristiche delle tecnologie W3C che sono disapprovate. [Priorità 2] 11.3 Fornire agli utenti lʹinformazione necessaria perché possano ricevere i documenti
in maniera che si adattino alle loro preferenze (per es., lingua, tipo di contenuto ecc.)
[Priorità 3] 11.4 Se, nonostante ogni sforzo, non si può creare una pagina accessibile, fornire un
collegamento a una pagina alternativa che usi le tecnologie W3C, sia accessibile,
contenga informazioni (o funzionalità) equivalenti, e sia aggiornata con la stessa
frequenza della pagina (originale) inaccessibile. [Priorità 1] Linea guida 12. Fornire informazione per la contestualizzazione e lʹorientamento.
Fornire informazione per la contestualizzazione e lʹorientamento, per aiutare gli utenti a
comprendere pagine od elementi complessi.
Capitolo 1 ‐ L’importanza dell’accessibilità 21
Il fatto di raggruppare gli elementi e di fornire informazione contestuale sulle
relazioni fra gli elementi può essere utile per tutti gli utenti. Relazioni complesse fra
parti di una pagina possono essere difficili da interpretare per persone con invalidità
cognitive o visive. Punti di controllo:
12.1 Dare un titolo a ogni frame per facilitare lʹidentificazione del frame e la
navigazione. [Priorità 1] 12.2 Descrivere lo scopo dei frame e il modo in cui essi interagiscono se non è
evidente dai titoli dei frame da soli. [Priorità 2] 12.3
Dividere grandi blocchi di informazione in gruppi più maneggevoli quando è
naturale ed appropriato. [Priorità 2] 12.4 Associare esplicitamente le etichette ai loro controlli. [Priorità 2] Linea guida 13. Fornire chiari meccanismi di navigazione.
Fornire chiari e coerenti meccanismi di navigazione ‐‐ informazione per lʹorientamento, barre di
navigazione, una mappa del sito, ecc. ‐‐ per aumentare le probabilità che una persona trovi
quello che sta cercando in un sito.
Chiari e coerenti meccanismi di navigazione sono importanti per persone con
invalidità cognitive o per i non vedenti, e giovano a tutti gli utenti. Punti di controllo:
13.1 Identificare con chiarezza lʹobiettivo di ogni collegamento. [Priorità 2] 13.2 Fornire metadata per aggiungere informazione di tipo semantico alle pagine e ai
siti. [Priorità 2] 13.3 Fornire informazione sulla configurazione generale di un sito (per es., una mappa
oppure un indice del sito). [Priorità 2] Capitolo 1 ‐ L’importanza dell’accessibilità 22
13.4 Usare meccanismi di navigazione in modo coerente. [Priorità 2] 13.5 Fornire barre di navigazione per evidenziare e dare accesso ai meccanismi di
navigazione. [Priorità 3] 13.6 Raggruppare i collegamenti correlati, identificare i gruppi (per gli interpreti) e,
fino a quando gli interpreti non lo fanno, fornire un modo per saltare il gruppo.
[Priorità 3] 13.7 Se sono fornite funzionalità di ricerca, rendere possibili diversi tipi di ricerca per
differenti livelli di abilità e per preferenze diverse. [Priorità 3] 13.8 Posizionare lʹinformazione più significativa allʹinizio delle intestazioni, dei
paragrafi, delle liste, ecc. [Priorità 3] 13.9 Fornire informazione sulle raccolte di documenti (cioè documenti composti da più
pagine). [Priorità 3] 13.10 Fornire un mezzo per saltare arte ASCII multilinea. [Priorità 3] Vedi il punto di controllo 1.1 e lʹesempio di arte ASCII nel glossario.
Tecniche per il punto di controllo 13.10
Linea guida 14. Assicurarsi che i documenti siano chiari e semplici.
Assicurarsi che i documenti siano chiari e semplici in modo che possano essere compresi più
facilmente.
Una disposizione coerente della pagina, una grafica riconoscibile e un
linguaggio facile da capire giovano a tutti gli utenti. In particolare essi aiutano persone
con disabilità cognitive o con difficoltà di lettura. Lʹuso di un linguaggio chiaro e
semplice promuove una comunicazione efficace. Lʹaccesso allʹinformazione scritta può
essere difficile per persone con disabilità cognitive o dellʹapprendimento. Lʹuso di un
linguaggio chiaro e semplice giova anche alle persone la cui madrelingua è diversa
dalla vostra, comprese le persone che comunicano essenzialmente con il linguaggio dei
segni. Capitolo 1 ‐ L’importanza dell’accessibilità 23
Punti di controllo:
14.1 Usare il linguaggio più chiaro e semplice possibile che sia adatto al contenuto di
un sito. [Priorità 1] 14.2 Integrare il testo con presentazioni grafiche o uditive nei casi in cui esse possano
facilitare la comprensione della pagina. [Priorità 3] 14.3 Creare uno stile di presentazione coerente fra le pagine. [Priorità 3] Le linee‐guida WCAG 1.0 sono una reccomandation del W3C datata 1999. A
distanza di sei anni il consorzio ha iniziato a lavorare ad una nuova versione delle linee
guida, chiamate appunto WCAG 2.0 [16] che ad oggi, Ottobre 2005, si trovano in uno
stato draft (bozza). Si tratta di un evoluzione della prima versione, guidata dagli stessi
principi ispiratori ma organizzata in modo piuttosto differente, tenendo in
considerazione diversi aspetti relativi alla qualità del sito, agli aspetti di usabilità e di
rispetto delle specifiche tecniche, unendo anche concetti generali da applicare ai
contenuti web.
Le WCAG 2.0 prevedono quattro principi di progettazione: Percezione,
Operabilità, Comprensibilità, Robustezza per ognuno dei quali vengono sono definite delle
linee‐guida (13 in tutto), che hanno, a loro volta, diversi livelli di successo (detti success
criteria), suddivisivi a loro volta in tre livelli (1, 2 e 3) secondo un criterio simile a quello
delle WCAG 1.0.
Più in dettaglio, i principi e le guideline sono i seguenti.
Percezione ‐ Il contenuto deve essere percettibile.
•
Guideline 1.1 ‐ Per tutti i contenuti non testuali, fornire degli equivalenti testuali.
•
Guideline 1.2 ‐ Fornire equivalenti sincronizzati dei vari media nelle
presentazioni multimediali dipendenti dal tempo.
•
Guideline 1.3 ‐ Assicurarsi che informazioni, funzionalità e struttura siano
separabili dalla presentazione
Capitolo 1 ‐ L’importanza dell’accessibilità •
24
Guideline 1.4 ‐ Deve essere facilmente distinguibile lʹ informazione in primo
piano rispetto alle immagini di sfondo o sonoro di sottofondo.
Operabilità ‐ Gli elementi di interfaccia presenti nel contenuto devono poter essere
azionati
•
Guideline 2.1 ‐ Rendere azionabili da tastiera o con una interfaccia a tastiera tutte
le funzionalità.
•
Guideline 2.2 ‐ Consentire agli utenti di controllare i propri tempi di lettura e di
interazione, a meno che il controllo non sia intrinsecamente impossibile a causa
di eventi in tempo reale o regole di competizioni.
•
Guideline 2.3 ‐ Lʹ utente può evitare contenuti che possono causare crisi da
epilessia fotosensibile.
•
Guideline 2.4 ‐ Facilitare agli utenti la possibilità di orientarsi e muoversi nel
contenuto. [Level 2]
•
Guideline 2.5 ‐ Aiutare gli utenti ad evitare gli errori e consentirne la correzione
[Level 2]
Comprensibilità ‐ Il contenuto e i controlli devono essere comprensibili
•
Guideline 3.1 ‐ Assicurarsi che possa essere determinato il significato dei
contenuti.
•
Guideline 3.2 ‐ Organizzare il contenuto ʺpagina per paginaʺ in maniera
coerente, e assicurarsi che i componenti interattivi si comportino in maniera
prevedibile.
Robustezza ‐ Il contenuto deve essere abbastanza robusto da essere compatibile con le
tecnologie presenti e future
•
Guideline 4.1 ‐ Utilizzare le tecnologie in maniera conforme alle specifiche.
•
Guideline 4.2 ‐ Assicurarsi che le interfacce utente siano accessibili, oppure
fornire alternative accessibili.
Capitolo 1 ‐ L’importanza dell’accessibilità 25
Successivamente, sulla base della linee guida cui il sito risponde correttamente è
possibile associare al sito stesso un livello di conformità. Anche in questo caso il
criterio è simile a quello delle WCAG 1.0, infatti individuiamo tre livelli di conformità.
1. ʺWCAG 2.0 Level Aʺ devono essere soddisfatti tutti i criteri di successo di livello 1
per tutte le linee‐guida
2. ʺWCAG 2.0 Level AAʺ devono essere soddisfatti tutti i criteri di successo di livello 1
e 2 per tutte le linee‐guida
3. ʺWCAG 2.0 Level AAAʺ devono essere soddisfatti tutti i criteri di successo di livello
1 e 2, e 3, per tutte le guideline
Infine è possibile evidenziare, anche se in maniera molto schematica, alcune
differenze tra le WCAG 1.0 e le WCAG 2.0, in particolare per quanto riguarda lo stato
del documento, la definizione di conformità, le tecniche, e le checklist.
•
Stato del documento:
o WCAG 1.0: unico documento stabile e referenziabile (Recommendation)
o WCAG 2.0: documento ancora in fase di raffinamento (Working Draft)
•
Conformità:
o WCAG 1.0: guideline con checkpoint. Conformità basata su checkpoint.
o WCAG 2.0: principi, guideline e success criteria. Conformità basata su
success criteria.
•
Techniques:
o WCAG 1.0: un documento contiene unicamente i link alle tecniche
specifiche per le varie tecnologie. Un documento separato (“Core”)
descrive le tecniche generali. Due documenti riguardano specificamente
le tecniche da utilizzare per HTML e CSS.
Capitolo 1 ‐ L’importanza dell’accessibilità 26
o WCAG 2.0: un unico documento contiene sia i link alle varie tecnologie,
che le tecniche generali. Sono previsti vari documenti specifici (quelli
per HTML, CSS, e client‐side scripting sono già disponibili)
•
Checklist:
o WCAG 1.0: lista di checkpoint raggruppati per priorità
o WCAG 2.0: lista di proposizioni verificabili che specificano cosa è
richiesto per essere conformi alle WCAG 2.0 in quella specifica
tecnologia
1.3.3 La Legislazione italiana
A livello nazionale ed internazionale le direttive WAI sono state recepite da da
un gran numero di paesi, soprattutto a livello di circolari, indicazioni e linee guida.
In Italia una circolare del Ministero della Funzione Pubblica illustra le linee
guida per l’ organizzazione, l’ usabilità e l’ accessibilità dei siti web delle pubbliche
amministrazioni, e esplicita come [17] : “In materia di accessibilità costituiscono prioritari
riferimenti i documenti conclusivi della Conferenza Ministeriale di Lisbona dellʹUnione
Europea del 20 marzo 2000 e della Conferenza Ministeriale di Feira del 19 e 20 giugno 2000,
nonché le linee guida sullʹaccessibilità dei siti Web del Consorzio Mondiale del Web (W3C).”
Una successiva Circolare dell’ AIPA indica criteri e strumenti per favorire
lʹaccesso ai siti web delle pubbliche amministrazioni e lʹuso delle applicazioni
informatiche da parte delle persone disabili. Tra l’ altro, in questa circolare si legge che
[18]: In particolare, vengono specificati i criteri da rispettare nella progettazione e
manutenzione dei sistemi informatici pubblici, per favorire lʹaccessibilità ai siti web che
mettono a disposizione di cittadini e imprese informazioni e servizi interattivi.
Il primo documento, è indirizzato a tutti colori i quali all’interno delle
pubbliche amministrazioni abbiano responsabilità collegate alla progettazione,
Capitolo 1 ‐ L’importanza dell’accessibilità 27
realizzazione e manutenzione di sistemi informativi basati sulle tecnologie del Web.
Esso sottolinea come lʹutilizzo ottimale delle tecnologie di comunicazione e, in
particolare, di Internet, costituisca un aspetto di importanza primaria per le pubbliche
amministrazioni. La rete è un mezzo importante sia per accrescere la produttività del
lavoro allʹinterno degli uffici pubblici, sia per migliorare la qualità dei servizi che essi
devono offrire ai cittadini, sia per promuovere una migliore informazione sulle attività
delle amministrazioni pubbliche e una maggiore partecipazione dei cittadini alle scelte
delle medesime amministrazioni. La circolare, invece, sottolinea come il Web sia allo stesso tempo uno strumento
comunicativo ed una tecnologia organizzativa, poichè permette di lavorare insieme ad
altri e di condividere informazioni tra uffici, di realizzare pratiche di integrazione e
forme di collaborazione con soggetti esterni a una determinata amministrazione.
Perché questo avvenga, però, occorre che i siti siano usabili e accessibili. Nel corso del 2003 il Ministro per l’Innovazione e le tecnologie, ha presentato al
Consiglio dei Ministri un disegno di legge sull’ Accesso dei soggetti disabili agli
strumenti informatici, deliberato dal Consiglio dei Ministri il 4 aprile 2003 [19] (il
disegno di legge e’ anche chiamato sinteticamente disegno di legge Stanca sui disabili).
Questo disegno di legge enfatizza principalmente l’importanza di garantire il
principio delle pari opportunità nell’accesso alle risorse informatiche, ed in particolar
modo all’accesso e alle risorse dei servizi di Pubblica Amministrazione.
In particolare, il disegno di legge sancisce importanti obblighi: •
Le forniture di beni e servizi informatici alle PA dovranno rispettare i requisiti
tecnici di accessibilità; •
Tutti i siti che saranno realizzati in futuro dovranno rispettare i requisiti di
accessibilità e, considerato che il tempo medio di rinnovo dei siti è di circa 3
anni ciò significa che in tre anni dall’approvazione di questa legge le Pubbliche
Amministrazioni Centrali avranno siti accessibili; •
I datori di lavoro metteranno a disposizione del lavoratore con disabilità
apposita strumentazione hardware e software. Capitolo 1 ‐ L’importanza dell’accessibilità 28
Si tratta dunque di un provvedimento legislativo indirizzato fondamentalmente
alle pubbliche amministrazioni. Esso però prevede che anche i siti dei privati possano
essere riconosciuti come accessibili. Esso, infatti, sancisce la possibilità che il privato
chieda la verifica del soddisfacimento degli standard di accessibilità al Dipartimento
per l’Innovazione. Il provvedimento può quindi essere fattore di sensibilizzazione e di
stimolo nei confronti dei privati e delle Pubbliche Amministrazioni Locali, al fine di
cominciare a rendere fruibili informazioni, risorse e notizie ad un pubblico quanto più
possibile vasto ed eterogeneo, ma che soprattutto comprende i soggetti con disabilità.
Capitolo 1 ‐ L’importanza dell’accessibilità 29
Bibliografia – Capitolo 1
[1] Internet Usage Statistics – World Internet and Population Stats
http://www.internetworldstats.com/stats.htm [2] J.Gillies , R.Cailliau – “Comʹè nato il Web” – Baldini&Castoldi – 2002
[3]
C.Batini – Norme e Regole per Disabili
[4] G.Affinito ‐ “Le Web Barriere: L’Accessibilità dei Siti della Pubblica
Amministrazione Italiana”
http://spazioinwind.libero.it/gianluca_affinito/web_barriere/index.htm [5] G.Affinito ‐ “Le Statistiche sulla Disabilità in Italia”
http://spazioinwind.libero.it/gianluca_affinito/web_barriere/disabili.htm [6] Indagine Istat 2002, “Aspetti della Vita Quotidiana – Utilizzo del Tempo Libero
– Uso di Internet”
[7] Ministero per lʹinnovazione e le tecnologie, ʺRapporto statistico sulla società
dellʹinformazione in Italiaʺ (maggio 2004) http://www.innovazione.gov.it [8] V. Perugino, Accessibilità nel Web: Navigazione a Vista ? ‐ 7° Workshop di Teca
del Mediterraneo. Bari, 18 giugno 2004
[9]
K.Bartlett – Web Accessibility and Users With Disabilities
[10]
L.Burzagli, P.Graziani – Accessibilità di Siti Web: Problematiche Reali e
Soluzioni Tecniche
http://www.ifac.cnr.it/smid/accesso/accesso.htm [11]
T. Berners Lee ‐ L’Architettura del nuovo Web – Feltrinelli, 2001
[12]
O.Signore ‐ Le Linee Guida del W3C per l’accessibilità: Evoluzione nella
Continuità – Handimatica 2004 – Bologna, 25 novembre 2004
Capitolo 1 ‐ L’importanza dell’accessibilità 30
[13]
Overview of the Web Accessibility Initiative – Slide 13 e ss.
http://www.w3.org/Talks/WAI‐Intro [14]
1999
Web Content Accessibility Guidelines 1.0 – W3C Raccomandation – 5 maggio
[15]
O.Signore – Il W3C e la Web Accessibility Initiative (WAI) – Corso
sull’Accessibilità dei Siti Internet – 11 novembre 2003
[16]
Web Content Accessibilty Guidelines 2.0 – W3C Draft – 30 giugno 2005
[17]
Circolare del Ministero della Funzione Pubblica, 13 marzo 2001, n. 3/2001,
Gazzetta Ufficiale 19 marzo 2001, Serie generale, n. 65
[18]
Circolare AIPA, 6 settembre 2001, n. AIPA/CR/32
[19]
Legge 9 gennaio 2004, n. 4 ‐ Disposizioni per favorire l’accesso dei soggetti
disabili agli strumenti informatici ‐ Gazzetta Ufficiale n. 13 del 17 gennaio 2004 http://www.camera.it/parlam/leggi/04004l.htm Capitolo 2 – Gli ausili per la disabilità 31
Capitolo 2 Gli ausili per la disabilità 2.1 Le tecnologie assistive Prima di analizzare specificatamente lo stato dell’arte relativo alle tecnologie assistive [1] occorre fare un cenno preliminare ai problemi specifici di accesso agli elaboratori da parte delle varie categorie di persone disabili. In generale gli utenti con disabilità possono essere ricondotti ai seguenti profili: •
Disabilità sensoriali (vista, udito) •
Disabilità motorie (impedimenti nell’uso degli arti) •
Disabilità psichiche o cognitive La disabilità della vista comprende tipicamente due classi di utenti: i non vedenti e gli ipovedenti. Tale distinzione ha la sua ragion dʹessere nel fatto che i problemi di accesso allʹelaboratore sono profondamente diversi nei due casi. Le persone ipovedenti, infatti, utilizzano comunque il monitor come dispositivo di output dellʹinformazione, anche se mediante lʹapplicazione di accorgimenti particolari come lʹaumento della dimensione del font usato, lʹutilizzo di software di ingrandimento generale dello schermo (detti magnificatori) oppure lʹimpostazione di colori particolarmente adatti ad esaltare le varie parti della presentazione a video (i sistemi operativi più recenti implementano delle configurazioni dette “ad elevata accessibilità”). Al contrario, per i non vedenti occorre ricorrere a dispositivi di output fisicamente diversi dal monitor basati su unʹuscita audio, come un sintetizzatore Capitolo 2 – Gli ausili per la disabilità 32
vocale, o su unʹuscita tattile, come il display Braille. In ambedue i casi cʹè alla base unʹoperazione di ristrutturazione dellʹinformazione, così come viene presentata sullo schermo, unʹoperazione di filtraggio che permette di selezionare e rileggere in forma sequenziale quello che lʹutente normale abbraccia con la vista in modo panoramico. I problemi degli utenti con disabilità dellʹudito, dovuti ad una sordità parziale o completa, sono da mettere in relazione con il crescente impiego di componenti audio nelle presentazioni multimediali, come i file audio, che fanno da corredo sonoro alla grafica, oppure registrazioni dalla viva voce del protagonista di conversazioni, esibizioni o altro. Di particolare rilievo la difficoltà dʹaccesso a filmati che contengono audio e video, di cui la parte audio diventa una componente essenziale. Quando i suoni veicolano importanti informazioni, come segnali di allarme od altro, possono essere sostituiti o accompagnati da opportune segnalazioni visive. In particolare, una conversazione o la colonna sonora di un filmato possono essere rese accessibili mediante il classico metodo della sottotitolazione. Per i sordi congeniti, vanno tenute presenti comunque anche le difficoltà di apprendimento del linguaggio, dovute alla mancanza di feedback uditivo, la cui conseguenza è spesso una difficoltà di comprensione anche del testo scritto, specialmente quando tratta argomenti astratti o fa uso di frasi molto elaborate. Lʹarco delle disabilità di tipo fisico è piuttosto ampio e va da una modesta paralisi su un arto, allʹincapacità di controllare i propri movimenti a causa di spasmi nervosi, sino nel peggiore dei casi ad una mobilità residua quasi nulla che permette di interagire col computer solo mediante lʹinvio di un comando dʹassenso, come il battito dellʹocchio o il soffio in una cannuccia per la selezione dellʹazione proposta dal computer con una lista di possibilità. In tutti questi casi la difficoltà di accesso si presenta per ciò che riguarda i dispositivi dʹingresso dei comandi da parte dellʹutente. La tecnologia ha già dato delle risposte altamente significative anche in questo campo, mettendo a punto dei dispositivi come tastiere di dimensioni maggiorate e con accorgimenti per evitare pressioni accidentali di tasti, emulatori di mouse particolari, Capitolo 2 – Gli ausili per la disabilità 33
per sfruttare al meglio le capacità residue dellʹutente colpito da questo tipo di menomazione. Anche l’ambito delle disabilità cognitive è molto vasto e differenziato. Si può tentare di evidenziare con molta prudenza degli aspetti comuni. Lʹutente affetto da tale disabilità farà fatica a comprendere pagine web troppo complesse, o in cui le componenti in movimento siano troppo veloci, perché le sue capacità residue potrebbero non consentirgli di cogliere fino in fondo tutti gli aspetti dellʹinformazione introdotta nella pagina. Ad esempio unʹimmagine piuttosto che una lunga scritta può essere un modo migliore, più sintetico per seguire un certo itinerario di navigazione in rete. Così come effetti lampeggianti possono comportare unʹincapacità di afferrare il senso dellʹinformazione ivi contenuta. Premesse queste nozioni di carattere introduttivo è possibile definire con precisione il concetto di tecnologia assistiva e illustrare approfonditamente il ventaglio di soluzioni oggi a disposizione per gli utenti diversamente abili. Negli ultimi tempi la tecnologia elettronica, informatica e telematica ha messo al servizio delle persone disabili numerosi strumenti per esprimersi, studiare, lavorare, ʺentrare in reteʺ e comunicare con altre persone superando alcuni tipi di limitazioni fisiologiche e motorie. Le tecnologie assistive sono dispositivi che possono essere usate da una persona con disabilità per eseguire compiti specifici, migliorare le proprie capacità funzionali e diventare più indipendenti. Possono aiutare a estendere e sviluppare le potenzialità cognitive, fisiche o sensoriali. In altri termini, le tecnologie assistive permettono a una persona di svolgere attività che normalmente non potrebbero essere svolte. Il ventaglio delle tecnologie assistive è abbastanza ampio [2] , e le stesse sono classificate sulla base della differente tipologia di disabilità che si prepongono di supportare. A grandi linee è possibile operare una classificazione sommaria in quattro macro‐categorie: Capitolo 2 – Gli ausili per la disabilità 34
•
Sistemi di Riconoscimento Braille •
Sistemi di Sintesi Vocale •
Sistemi di Magnificazione •
Sistemi di Puntamento Alternativi 2.1.1 Sistemi di riconoscimento Braille Nel 1812, Louis Braille, un bambino francese di tre anni, si ferì lʹocchio sinistro. Lʹinfezione si sviluppò e colpì anche lʹocchio destro e in breve tempo il bambino divenne cieco. Allʹetà di dieci anni, i genitori del piccolo Braille lo iscrissero allʹIstituto Nazionale per Non Vedenti di Parigi dove egli apprese a leggere caratteri di grandi dimensioni e in rilievo, ma data la dimensione delle lettere impresse in rilievo, i libri per i non vedenti erano estremamente costosi. Nello stesso periodo, il Capitano Charles Barbie aveva appena introdotto un codice alfabetico utilizzato nelle comunicazioni militari notturne. Questo sistema era caratterizzato da una serie di punti rialzati. Unendo gli elementi di entrambi i metodi di codifica, allʹetà di quindici anni, Braille realizzò un proprio sistema di lettura basato su punti in rilievo. Le ʺcelle Brailleʺ rappresentavano 63 lettere, numeri e simboli individuali. Ogni cella era caratterizzata da due punti trasversali e tre in basso. Le celle impresse in rilievo avevano la stessa dimensione delle lettere stampate. Oggi, a distanza di due secoli, il sistema Braille [3] è ancora largamente utilizzato, ed anzi, per la maggiorparte degli individui ipovedenti e non vedenti rappresenta uno strumento di fondamentale importanza per leggere, informarsi e comunicare, ma gli ambiti applicativi dell’alfabeto braille sono davvero molteplici, partendo dalla musica fino ad arrivare all’informatica, dove viene utilizzata una versione dell’alfabeto leggermente differente ma con alla base i medesimi meccanismi. Nella prima metà degli anni ’80 un grosso ausilio alla fruizione dei Personal Computer da parte di persone ipovedenti e non vedenti è stato dato dall’invenzione Capitolo 2 – Gli ausili per la disabilità 35
della periferica Braille. Quella data probabilmente ha segnato il punto di partenza per lo sviluppo e la creazione di dispositivi e tecnologie assistive sempre più moderni e maggiormente vicini alle esigenze dei disabili, a partire dai sistemi di sintesi vocale, passando per gli screen reader, fino ad arrivare ai moderni lettori di e‐book. Il display braille, per esempio, è uno strumento essenziale per la fruizione delle tecnologie informatiche da parte di utenti non vedenti o ipovedenti [4]. Si tratta di una periferica aggiuntiva che viene connessa alla porta seriale del Personal Computer, e rappresenta lʹalternativa più diffusa alla visualizzazione delle immagini sul monitor. Alcune barre Braille si incastrano sotto la tastiera standard e dispongono inoltre di un tastierino funzionale aggiuntivo mediante i quali è possibile, ad esempio scorrere tutto il contenuto del video, ottenere la scansione del video per parole intere, compiere la definizione di tabulatori, fare la ricerca di stringhe, conoscere le coordinate del cursore o sapere il colore delle scritte visualizzate. Ma esistono portatili o tastiere per PC che incorporano direttamente una barra Braille. Questo dispositivo eʹ costituito da una o due file di celle tattili. Ogni cella eʹ dotata di otto elementi piezoelettrici che si sollevano (producendo un rilievo sulla cella) o rimangono abbassati a seconda del carattere braille da riprodurre. Sei degli otto elementi corrispondono ai sei punti dei caratteri braille, mentre altri due elementi identificano altre caratteristiche del testo, come ad esempio la posizione attuale del cursore o altre caratteristiche della lettera o del simbolo da rappresentare. (figura 1 – Un Display Braille) Capitolo 2 – Gli ausili per la disabilità 36
Il testo presente sullo schermo viene analizzato riga per riga, e i caratteri corrispondenti alla riga attualmente selezionata vengono riprodotti in forma tattile sulla linea braille, un carattere per ogni cella. Alcuni tasti presenti sulla linea braille permettono di ʺesplorareʺ il testo presente sullo schermo, scegliendo la porzione di testo che verraʹ rappresentata in forma tattile dagli elementi piezoelettrici. Questo sistema ha la limitazione di non poter riprodurre piuʹ di una o due righe di testo per volta, e inoltre lʹutilizzo di sistemi a finestra e di ambienti grafici che vengono difficilmente rappresentati con una serie di linee di testo puoʹ rappresentare una limitazione per lʹutilizzo di questo strumento. Indirizzate alla stessa categoria di soggetti sono anche le tastiere braille. Sebbene i non vedenti non abbiano grosse difficoltà nell’utilizzare le normali tastiere per PC (con l’unico accorgimento di applicare delle etichette in rilievo per distinguere il tasto corrispondente), esistono delle tastiere appositamente realizzate secondo lo standard braille con sei pulsanti che corrispondono ai sei punti delle lettere braille e altri tasti assegnati a funzioni speciali. (figura 2 – Una Tastiera Braille) Come detto, i soggetti disabili non vedenti possono fruire delle normali tastiere per Personal Computer semplicemente applicando delle etichette in rilievo che permettano di distinguere il corrispondente elemento della tastiera. Esse riproducono in forma braille la lettera corrispondente al tasto in questione. Per effettuare questa operazione si possono utilizzare delle appositi adesivi. Gli utenti interessati ad applicare simboli braille sulla loro tastiera possono anche fabbricare a mano le etichette Capitolo 2 – Gli ausili per la disabilità 37
in rilievo utilizzando delle etichettatrici manuali predisposte per il braille e reperibili presso i negozi di articoli per ufficio. (figura 3 – Etichette in Rilievo) Esistono infine anche delle particolari tipologie di stampanti in grado di produrre i risultati direttamente in braille. Si tratta di stampanti braille che sfruttano il lavoro di programmi di conversione dei normali documenti di testo in documenti braille da inviare in input alla stampante. Esistono dispositivi che consentono la stampa sia su fogli singoli che su moduli continui. Eʹ anche possibile stampare su entrambe le facce del foglio regolando la forza della battuta in funzione dello spessore della carta utilizzata. In alcune stampanti è presente unʹinterfaccia vocale per i messaggi della stampante. (figura 4 – Una Stampante Braille) Capitolo 2 – Gli ausili per la disabilità 38
2.1.2 Sistemi di sintesi vocale Aggiungendo al computer una scheda audio è possibile inoltre utilizzare programmi di sintesi vocale in grado di “leggere” elettronicamente un testo scritto. Sul mercato esistono due differenti tipologie di sistemi di sintesi vocale, differenziate sulla base dell’hardware necessario a trasformare in voce le informazioni presenti sullo schermo. Alcuni di questi, infatti, si appoggiano alle normali schede SoundBlaster presenti ormai sulla quasi totalità dei Personal Computer, mentre altri utilizzano particolari tipologie di schede ottimizzate proprio per applicazioni di questo tipo. Alcuni esempi di programmi di sintesi vocale sono: •
INFOVOX 230/330 prodotto da Babel‐Infovox e distribuito da Tiflosystem [5] •
Audiobox, Audioboard e Audioblaster prodotti da Audiologic [6] •
Actor prodotto da Loquendo e distribuito da Audiologic e Voice Systems [7] •
EuroVOICE per Ms‐Dos e Windows prodotto da Eurovoice e distribuito da Voice Systems [8] E’ bene comunque sottolineare che i programmi di sintesi vocale non sono in grado di sostituire completamente le informazioni presenti sullo schermo, e pertanto si rende necessario aggiungere a questi degli altri programmi, detti screen reader, che svolgano appunto la funzione di ʺlettori di schermoʺ, per permettere agli utenti di ʺesplorareʺ le informazioni testuali presenti sul display del computer. Anche per questo tipo di applicazioni lʹutilizzo di sistemi grafici a finestre può rappresentare una limitazione, rendendo più difficile la conversione in suono o in braille del contenuto dello schermo del computer. Capitolo 2 – Gli ausili per la disabilità 39
Gli screen reader [9] consentono un controllo completo su quanto viene vocalizzato, implementando tralaltro nelle versioni più avanzate funzionalità molto utili come: •
Lettura di tabelle in ambiente Internet Explorer •
Lettura di file .pdf •
Funzioni di lettura continua avanzate •
Segnalazione di applicazioni lampeggianti nella barra delle applicazioni •
Lettura delle barre di progressione e scorrimento Strumenti di sintesi vocali e display braille possono anche a loro volta essere utilizzati contemporaneamente, consentendo all’utente di scegliere quali informazioni rappresentare in braille e quali informazioni far leggere alla sintesi vocale. Sono disponibili lettori di schermo che sono in grado di ricostruire un modello ad albero delle schermate grafiche e degli oggetti in esse contenuti (Offscreen Model), consentendo all’utente cieco di percorrerle gerarchicamente e di ottenere la lettura dei testi associati a icone, menù, finestre. Così come per i programmi di sintesi vocale, il mercato presenta anche un ampia varietà di software screen reader. In questo elenco citiamo i più importanti: •
WINDOW ‐ EYES prodotto da GW Micro e distribuito da Tiflosystem [10] •
VIRGO NT (per Windows NT e 2000) prodotto da BAUM e distribuito da Tiflosystem [11] •
Connect Outloud per Windows prodotto da Freedom Scientific e distribuito da Subvision [12] •
Hal per windows prodotto da Dolphin e distribuito da Audiologic. [13] •
OutSPOKEN Solo 3.0 e OutSPOKEN Ensemble 3.0 prodotti da ALVA Access Group e distribuiti da ARS, Leonardo, Voicesistems. [14] •
Jaws per Windows prodotto da Freedom Scientific e distribuito da Leonardo e Subvision [15] 40
Capitolo 2 – Gli ausili per la disabilità (figura 5 – JAWS, uno Screen Reader) Tutti i software di questo tipo condividono alla base un funzionamento molto simile [16]. Il comportamento dello screen reader viene definito sulla base di un meccanismo, definito a monte, attraverso cui di volta in volta viene selezionata la parte di testo da vocalizzare. Gli screen reader più recenti, inoltre, offrono contemporaneamente all’utente dei meccanismi di emulazione del puntatore al fine di permettere una totale esplorazione dello spazio a disposizione ed un sistema di feedback continui ed immediati finalizzati a fornire all’utente un’immediata percezione dello stato del sistema o di eventuali cambiamenti avvenuti sullo stesso. La vocalizzazione delle pagine Web visualizzate durante la navigazione con un normale browser, invece, implementa dei meccanismi più raffinati a causa della non linearità che caratterizza la struttura dell’ormai quasi totalità dei siti Web. Originariamente gli screen reader si limitavano ad una lettura dall’alto verso il basso e da sinistra verso destra, ma oggi questo non è più possibile in virtù della proliferazione di pagine Web arricchite da frame, immagini, animazioni ed elementi multimediali di vario tipo. In generale quando lo screen reader si accorge dell’esecuzione di un browser attiva una particolare modalità di interpretazione della struttura della pagina da vocalizzare successivamente. Capitolo 2 – Gli ausili per la disabilità 41
In particolare, con lʹintroduzione di Internet Explorer 5, Microsoft ha fornito una libreria (MSAA) contenente una serie di funzioni cui gli screen reader possono appoggiarsi per presentare le pagine web in maniera alternativa. Jaws e Window‐Eyes hanno sviluppato un sistema che di fatto consente di scorrere le pagine web con i tasti freccia come se ci si trovasse in un word processor. Le pagine vengono decolonnizzate (o linearizzate), cosicché il testo viene letto secondo un ordine logico. Accanto ai sistemi di sintesi vocale e agli screen reader esistono anche in commercio dei sistemi che permettono il totale controllo del sistema mediante la voce. I Sistemi di Voice Recognition più conosciuti sono: •
Dragon NaturallySpeaking prodotto da Scan Soft [17] •
Via Voice prodotto da IBM [18] •
Kolvox Lawtalk 2.0 per Windows prodotto da Kolvox [19] Tuttavia, prima che un utente disabile possa fruire in maniera completa di sistemi di questo tipo, è necessario effettuare una verifica accurata delle capacità vocali della persona interessata. La quasi totalità dei sistemi di riconoscimento vocale, infatti, sono stati sviluppati per utenti con una perfetta capacità fonetica, in grado di pronunciare chiaramente e nitidamente i comandi da impartire al calcolatore. Eventuali difficoltà di pronuncia possono infatti essere dei problemi importanti e alle volte persino insormontabili per una software o un sistema di riconoscimento vocale. In generale questi sistemi sono composti da un insieme di dispositivi elettronici e di programmi in grado di far funzionare tali dispositivi. Gli strumenti hardware necessari sono una scheda audio da inserire nel computer per svolgere le funzioni di acquisizione e riconoscimento dei comandi vocali, e da un microfono per lʹimmissione dei comandi. Capitolo 2 – Gli ausili per la disabilità 42
I programmi di riconoscimento vocale possono essere usati semplicemente per sostituire i comandi impartiti al computer con la tastiera o con il mouse, per effettuare delle vere e proprie dettature di testi, oppure per sostituire con dei comandi vocali il movimento del mouse (emulazione vocale del mouse). In genere, però, prima di utilizzare un sistema di riconoscimento della voce eʹ indispensabile effettuare una sessione di ʺallenamentoʺ, che ha lo scopo di rilevare il timbro e le caratteristiche fonetiche della voce dellʹutilizzatore. Tutti i sistemi di riconoscimento vocale possono a loro volta essere classificati e soprattutto valutati sulla base di alcuni parametri. Il più importante di questi è probabilmente il tasso di riconoscimento, termine con cui si indica la percentuale di parole riconosciute correttamente dal sistema. Un tasso di riconoscimento accettabile per lavorare utilizzando proficuamente i sistemi di riconoscimento vocale deve aggirarsi intorno al 95%. I dati relativi al tasso di riconoscimento forniti dalle aziende produttrici dei programmi di riconoscimento vocale vanno presi con cautela, poiché nella maggior parte dei casi si riferiscono a misure effettuate in condizioni acustiche ideali su utenti con una pronuncia perfetta e un buon grado di allenamento nellʹutilizzo del sistema. (figura 6 – Microfono con Cuffie, necessario per utilizzare Sistemi di Voice Recognition) 2.1.3 Sistemi di magnificazione Capitolo 2 – Gli ausili per la disabilità 43
Per un utente non vedente l’utilizzo di un display braille o di uno screen reader è una necessità imprescindibile al fine della fruizione delle informazioni presentate sullo schermo di un PC. Per gli utenti ipovedenti, viceversa, poiché le capacità visive sono semplicemente ridotte e non totalmente assenti non è necessaria un operazione di ristrutturazione delle rappresentazione dell’informazione che sottintende l’utilizzo della tecnologia braille o di sistemi di sintesi vocale. Nel caso degli utenti ipovedenti, infatti, esistono particolari strumenti (hardware e software) che prendono il nome di sistemi di magnificazione. L’idea principale alla base di questi sistemi, intuitivamente, è quella di magnificare, cioè semplicemente ingrandire, tutte le informazioni rappresentate sullo schermo al fine di garantire ad utenti con limitate capacità visive una completa visualizzazione e fruizione delle stesse. In generale i software di magnificazione aumentano la dimensione con cui vengono visualizzate le informazioni sulla base di un fattore incrementale predeterminato (1x – 2x – 4x , ecc) che può essere modificato sulla base delle necessità dell’individuo. Anche nel caso dei sistemi di magnificazione è possibile citare i software più importanti presenti sul mercato: •
Ai Squared – Software di Magnificazione [20] •
Screen Enlarger – Magnificazione fino a 32x , implementa meccanismi di speech output [21] •
Galileo – prodotto dalla Baum [22] •
Reader’s Pal – Semplice da Usare, visualizza Pagine Web e File di Testo con Fonts Magnificati e Colori ad alto contrasto [23] •
Screen Magnifier – Prodotto dalla IBM, può effettuare magnificazioni da 2x a 32x [24] Capitolo 2 – Gli ausili per la disabilità 44
(figura 7 – Un Software di Screen Magnification) 2.1.4 Sistemi di puntamento alternativi L’ultima categoria di ausili per la navigazione è rappresentata dall’insieme degli strumenti che fungono da alternativa per i disabili non in grado di utilizzare le dita per interagire con gli elaboratori. In generale questa tipologia di ausili può essere suddivisa in due macrocategorie: •
Gli interruttori •
I mouse speciali La prima categoria descrive un insieme di ausili che consentono di utilizzare tutte le funzioni di un personal computer anche utilizzando solamente un labbro oppure un dito. Gli interruttori sono dispositivi che, nella loro semplicità, consentono a individui disabili una completa fruizione di tutte le funzionalità del computer. L’idea alla base degli interruttori è quella più intuitiva possibile: un dispositivo che può trovarsi in due stati, acceso‐spento, on‐off, attivo‐non attivo. Dispositivi di questo tipo possono essere sviluppati nei modi più diversi, sulla base ovviamente delle differenti necessità richieste dal disabile. Esistono infatti interruttori a pedale, a pulsante, a pressione, che si attivano con il soffio, con lʹumidità, oppure appoggiandovi sopra la lingua. Gli interruttori di ultima generazione sono in Capitolo 2 – Gli ausili per la disabilità 45
grado di reagire anche a piccolissime sollecitazioni, come lo sbattere di una palpebra o il movimento di un labbro. Attualmente la ricerca scientifica sta sviluppando un tipo di interruttori in grado di rilevare il tipo di onde (Alfa o Mu) degli impulsi cerebrali, in maniera da attivare uno o più interruttori senza necessità di un effettivo movimento fisico, ma solo in base al tipo di onde cerebrali attivate. La seconda categoria, invece, quella dei mouse speciali, descrive un insieme di ausili che permettono di sostituire le funzioni svolte dal mouse con una serie di pulsanti o con particolari apparecchi azionati dal movimento della testa. Il mouse eʹ il più popolare dispositivo di accesso al computer. Il suo utilizzo, però, prevede che l’utente abbia una serie di capacità a livello manipolativo. Capacità manipolative che però, purtroppo, non possono essere soddisfatte da tutti gli utenti per le ragioni più svariate: una ridotta mobilità delle mani, lʹimpossibilitaʹ di stringere il mouse per il suo trascinamento, una lentezza dei movimenti tale da rendere impossibile il ʺdoppio clickʺ, la scarsa precisione nel movimento delle mani, lʹimpossibilità di sollevare il mouse per cambiarlo di posto, la difficoltà di effettuare sui pulsanti la pressione necessaria alla loro attivazione, o la totale impossibilità ad utilizzare gli arti superiori, e si potrebbe continuare ancora a lungo. In conseguenza di ciò sono nate nel corso del tempo una serie di tecnologie orientate specificatamente a sostituire totalmente o quantomeno parzialmente le funzionalità offerte dai sistemi di puntamento tradizionali. Gli Eye‐Tracker, per esempio, devono la propria esistenza ad una particolare disciplina che prende appunto il nome di Eye‐Tracking, che tradotto alla lettera significa “tracciamento oculare”. Si tratta di una tecnica utilizzata in psicologia, nelle scienze cognitive, nella pubblicità, nell’interazione uomo‐macchina, nella ricerca medica e in tantissime altre aree. Capitolo 2 – Gli ausili per la disabilità 46
(figura 8 – Un Sistema di Eye Tracking Invasivo) L’idea alla base di questa disciplina [17] è quella di monitorare e registrare in maniera continua tutti i movimenti che l’individuo compie in un determinato lasso di tempo per poter trarre, a partire dalle informazioni su “dove” l’utente ha guardato, una serie di conclusioni. Esiste al giorno d’oggi un insieme piuttosto eterogeneo di tipologie di eye‐tracker, tutte però un unite da un funzionamento di base comune, basato sull’utilizzo dei raggi infrarossi per generare delle rifrazioni corneali a partire dalle quali possono essere calcolati i movimenti effettuati. In generale l’analisi dei movimenti oculari permette di ricavare uno Scanpath, termine particolare che fa riferimento a un insieme fissazioni (quando l’occhio è fermo in una particolare posizione) e di saccadi (quando l’occhio si sposta da una posizione ad un’altra). Tutte le informazioni che la disciplina dell’eye‐tracking ci permette di ricavare vengono costruite a partire dalle fissazioni. Si tratta in generale di informazioni utili per poter individuare i punti salienti di ciò che l’individuo ha guardato, le aree più interessanti, o meglio ancora, definire con precisione l’intento cognitivo dell’individuo stesso. Capitolo 2 – Gli ausili per la disabilità 47
(figura 9 – L’Eye Tracker prodotto dalla Tobii , un sistema di Tracking non invasivo) Un altra tipologia di dispositivi assistivi che è doveroso citare è quella degli Headpointer. L’idea alla base di questi dispositivi è quella di utilizzare i movimenti della testa per compensare l’impossibilità dell’utilizzo delle mani. Le prime versioni degli headpointer erano caratterizzate da una particolare fascia che, fissata sulla fronte dell’individuo, permetteva grazie a una serie di sensori di tracciare i movimenti compiuti dalla testa. L’applicazione più immediata che può essere individuata per un ausilio di questo tipo è l’emulazione dei movimenti del mouse. Mediante un headpointer, infatti, è possibile simulare i movimenti del puntatore sullo schermo sulla base dei differenti movimenti che il capo dell’individuo compie. Il click utente può essere normalmente emulato tramite un sensore a soffio senza fili o con qualunque altro tipo di sensore a singola funzione. Unʹalternativa è lʹutilizzo della funzione di ʺDwellʺ: quando questa funzione è attiva per avere il ʹclickʹ è sufficiente tenere il puntatore del mouse fermo nella posizione desiderata per un tempo fissato. Dispositivi di questo tipo possono anche essere utilizzati su persone senza disabilità come un normale strumento di puntamento per migliorare la fruibilità stessa degli elaboratori. Recentemente infatti sono stati effettuati degli studi comparativi [18] Capitolo 2 – Gli ausili per la disabilità 48
finalizzati a misurare in maniera precisa l’efficienza di sistemi basati su headpointer per muovere i dispositivi di puntamento uniti a normali tastiere per inserire del testo. (figura 10 – Un Head Pointer) Anche nel caso dei puntatori controllati dal movimento della testa il mercato offre una grande varietà di dispositivi. Possiamo citare per esempio: •
HeadMaster Plus, prodotto dalla Prentke Romich Company [27] •
Head Mouse, prodotto dalla Origin Instrument Corporation [28] •
SmartNav, prodotto da Eye Control Technologies [29] •
Tash Mouse Mover, prodotto da Synapse Adaptive [30] 2.2 Applicazioni: I Web Browser Un Web Browser è un applicazione che permette [31] di visualizzare il contenuto di generiche pagine Web ospitate all’interno dei Web Server interpretando il codice HTML della pagina e mostrandolo all’utente sottoforma di ipertesto. Intuitivamente, un Web Browser può essere immaginato come un software che permette all’utente di navigare all’interno del Web visualizzando documenti, notizie, Capitolo 2 – Gli ausili per la disabilità 49
informazioni, o, in generale, di fruire di tutti gli strumenti che Internet ci mette a disposizione. Come già detto precedentemente, una delle personalità più importanti per la nascita e lo sviluppo del World Wide Web [32] è stata quella di Tim Berners Lee. Fu proprio lui, nel 1991, a rendere pubblica l’idea di sfruttare il concetto di ipertesto per condividere documenti e informazioni tra ricercatori di università differenti; E’ stato proprio grazie a lui che si sono affermati gli standard che ancora oggi rappresentano le fondamenta di Internet e del Web. Ciascun documento presente sulla Rete, infatti, è univocamente identificato mediante un URL (acronimo di Uniform Resource Locator), e tutto il processo di richiesta‐risposta tra client e server è reso possibile mediante il protocollo di comunicazione HTTP (acronimo di Hyper Text Transfer Protocol) che permette la visualizzazione sul Web Browser del documento scritto in formato HTML (a sua volta acronimo di Hyper Text Markup Language). Il linguaggio è detto “di etichettura” poiché finalizzato semplicemente a descrivere i dettagli di impaginazione dei documenti presenti sul Web, che a loro volta possono essere ulteriormente arricchiti mediante immagini, file audio, animazioni, e contenuti multimediali in senso lato. Almeno nei primi tempi, però, i Web Browser ricoprivano un ruolo soltanto marginale all’interno della Rete. L’esplosione e la successiva affermazione come vera e propria killer application di questa tecnologia è avvenuta soltanto successivamente, con la nascita dei primi browser dotati di interfaccia grafica che permettevano così la fruizione delle (allora poche) informazioni presenti sulla rete a un pubblico molto più eterogeneo. Il primo browser con interfaccia grafica, in particolar modo, è stato il punto di partenza a partire dal quale poi si sono sviluppate ed affermate tutte le altre applicazioni di questo tipo [33] . Era il 1993, infatti, quando venne rilasciato Mosaic, seguito immediatamente (1994) dalla prima versione di Netscape Navigator, e a sua volta da Internet Explorer. Capitolo 2 – Gli ausili per la disabilità 50
Mosaic sparì dalla scena più o meno velocemente, mentre Netscape ed Explorer continuarono per lungo tempo una “guerra” tra browser che alla fine ha visto vittorioso di prodotto di Microsoft. A partire da Netscape, poi, negli anni ’90, sono partiti una serie di progetti Open Source alternativi che sono sfociati nella nascita di Mozilla, ad oggi il principale antagonista di Internet Explorer in questa continua lotta tra browser. Oggi il panorama dei Web Browser è quanto mai ricco ed eterogeneo. Sono presenti sul mercato una grandissima varietà di applicazioni: Internet Explorer, Mozilla Firefox, Opera, seguiti poi da una proliferazione sempre maggiore di prodotti “minori” che si appoggiano ai motori di rendering di Mozilla (Gecko) e di Explorer offrendo però una serie di funzionalità differenti. La grande vivacità del mercato dei Web Browser sottolinea ulteriormente l’importanza di uno strumento di questo tipo all’interno di una tecnologia in continua evoluzione come Internet. Nell’immaginario collettivo, infatti, fare riferimento a Internet significa fare riferimento al Web (quando concettualmente sappiamo bene che si tratta di due strumenti sostanzialmente differenti), e utilizzare Internet viene spesso inteso come sinonimo di utilizzare un Web Browser. La ricca attività legislativa di cui si è parlato precedentemente, inoltre, enfatizza ulteriormente il ruolo di Internet all’interno della nostra società, ponendo l’accento sulla necessità di rendere accessibile la Rete al fine di garantire la fruizione di tutte le informazioni in essa contenute ad un pubblico quanto più possibile vasto, esteso ed eterogeneo, ed enfatizzando, indirettamente, (in virtù dell’ “uguaglianza” mostrata precedentemente) anche il ruolo dei Web Browser. Negli ultimi tempi, infatti, accanto ai browser principali, è andata progressivamente evolvendosi un mercato parallelo dei browser, orientato in questo caso ad avvicinarsi alle necessità degli utenti diversamente abili garantendo loro la possibilità di interagire col Web e con le informazioni in esso contenute. In generale i browser di questo tipo possono essere suddivisi in due macro categorie: Capitolo 2 – Gli ausili per la disabilità •
Browser Assistivi •
Browser ad Elevata Accessibilità 51
2.2.1 Browser assistivi Il concetto di Browser Assistivo definisce una particolare categoria dei Web Browser opportunamente progettati per andare incontro e sopperire ad una particolare tipologia di disabilità. In generale il ventaglio delle scelte disponibili spazia tra applicativi orientati a vocalizzare le informazioni rappresentate sulla pagine Web (sfruttando opportune librerie di sistema), supportando utenti affetti da disabilità visive, fino ad arrivare a browser progettati per supportare la navigazione mediante dei terminali braille, passando per applicazioni che includono automaticamente dei sistemi di magnificazione delle informazioni presenti sullo schermo al fine di permettere la fruizione delle stesse ad utenti ipovedenti. Buona parte dei sistemi di questo tipo è nato e si è sviluppato in ambito universitario. E’ il caso di BrookesTalk, [36] per esempio, interessante progetto (purtroppo ormai messo da parte) portato avanti dalla Oxford Brookes University. Il browser, sviluppato specificatamente per utenti non vedenti ed ipovedenti, è stato premiato nel 1998 con una medaglia nel British Computing Society ITC Award, a conferma della bontà delle idee alla base del progetto stesso. Le caratteristiche principali implementate nelle ultime versioni del browser includevano una finestra di testo sovrastante la pagina Web (contenente la rappresentazione magnificata della pagina) e una completa integrazione con delle librerie di Microsoft che permettevano la sintesi vocale delle informazioni contenute all’interno della pagina. Come detto però il progetto è stato portato avanti solo per tre anni, e da Ottobre 2001 non appaiono più novità su BrookesTalk. 52
Capitolo 2 – Gli ausili per la disabilità (figura 11 – Una Schermata di BrookesTalk) Accanto ai sistemi nati in ambiti di ricerca universitaria, però, esistono anche degli applicativi sviluppati in contesti più “commerciali”. E’ il caso di IBM e del suo Home Page Reader, che probabilmente rappresenta il miglior web Browser che implementa dei sistemi di sintetizzazione per vocalizzare correttamente il contenuto di una pagina Web. In virtù un costo non particolarmente ridotto (170 euro) , il sistema ha una serie di pregi, tra cui quello fondamentale di interpretare correttamente buona parte dei tag presenti all’interno delle pagine Web, permettendo una trasposizione del testo in voce particolarmente affidabile ed efficiente. (figura 12 – Una Schermata di IBM Home Page Reader) 53
Capitolo 2 – Gli ausili per la disabilità Sistemi come BrookesTalk e HomePage Reader rappresentano probabilmente gli estremi del ventaglio delle soluzioni che il mercato dei browser assistivi oggi propone: Da una parte la ricerca universitaria, dall’altro i prodotti commerciali. A metà tra queste due soluzioni esistono però una serie di prodotti altrettanto interessanti che, pur sviluppati da software house comuni sono liberamente scaricabili e utilizzabili senza alcun costo aggiuntivo. E’ il caso di Sensus Internet Browser [37] e Simply Web 2000 [38], due applicativi che si basano come IBM Home Page Reader sul concetto di vocalizzazione delle informazioni presenti all’interno della pagina Web. Si tratta in entrambi i casi di software assolutamente completi nelle loro funzionalità e che, seppur molto migliorabili, garantiscono la fruizione delle informazioni ad utenti non vedenti. (figura 13 – Il Sito Web del Dipartimento di Informatica dell’Università di Bari ‐ Sensus Internet Browser) Un ultimo importante progetto cui è doveroso fare riferimento è MozBraille [39]. Nato dalle ceneri di BrailleSurf (anch’esso abbandonato nel 2001) , MozBraille sfrutta le enormi potenzialità del motore di rendering e degli strumenti del Browser 54
Capitolo 2 – Gli ausili per la disabilità Open Source Mozilla per realizzare un estensione del Browser stesso che includa una serie di utili funzionalità orientate ad utenti con disabilità visive. L’ultima estensione rilasciata, in particolar modo, abbraccia le necessità degli utenti disabili con tre differenti accorgimenti; Se la rappresentazione magnificata degli elementi contenuti all’interno delle pagine Web ed il motore di conversione delle informazioni in voce (supportato alla libreria Microsoft, come in BrookesTalk) rappresenta qualcosa di non particolarmente innovativo poiché già citato nelle soluzioni precedentemente illustrate, MozBraille a differenza di tutti gli altri software include anche la possibilità di esplorare il contenuto delle pagine Web mediante l’ausilio di un Display Braille. Di default MozBraille implementa un emulatore di display Braille nella parte alta dello schermo (detto Fake Braille Terminal) che descrive il contenuto della pagina Web che l’utente sta visualizzando, ma, in assoluto, il progetto assume particolare valore in virtù dell’integrazione con una libreria, detta LibBraille [40], che permette al browser di rappresentare le informazioni contenute all’interno della pagina non su un emulatore ma su una Barra Braille vera e propria. (figura 14 – Una Schermata di MozBraille con la Fake Braille Terminal) Capitolo 2 – Gli ausili per la disabilità 55
Ad oggi il progetto è ancora in fase di sviluppo, e non è esclusa la possibilità che anche a breve questo interessante software possa essere arricchito di nuove funzionalità. 2.2.2 Browser ad elevata accessibilità La differenza sostanziale che intercorre tra i browser assistivi, e quelli ad elevata accessibilità è tutta insita nell’assenza, in questi ultimi, di particolari accorgimenti progettuali finalizzati a supportare utenti con una particolare tipologia di disabilità. I browser ad elevata accessibilità, infatti, sono normali browser che condividono tutte le funzionalità dei browser più comuni ponendo però maggiore attenzione verso l’accessibilità e verso tutte le problematiche ad essa legate. L’ interesse sempre crescente verso il tema dell’accessibilità ha portato negli ultimi tempi anche i browser più importanti (è il caso delle ultime versioni di Netscape Navigator ed Internet Explorer) ad includere una serie di caratteristiche orientate a garantire la fruizione dei contenuti web anche a soggetti ipovedenti, implementando dei sistemi di magnificazione delle informazioni presenti nella pagina o dei meccanismi di caricamento automatico di fogli di stile ad elevata accessibilità. Discorso a parte, invece, merita di essere fatto per Opera. Il browser norvegese si sta facendo apprezzare negli ultimi tempi per l’introduzione di una serie di funzionalità innovative, molte delle quali legate alla sfera dell’accessibilità. Opera, infatti, può essere visto come l’unico esempio di browser commerciale “ibrido”, poiché implementa sia delle caratteristiche che lo rendono un browser ad elevata accessibilità, sia delle funzionalità proprie dei browser tipicamente assistivi. L’ultima versione di Opera (9.0 , rilasciata a Novembre 2005) , oltre alle classiche funzionalità dei browser accessibili [41], come l’utilizzo dei comandi da tastiera, la compatibilità con gli screen reader, e la possibilità di magnificare le informazioni presenti sullo schermo, ha introdotto anche una caratteristica che lo fa rientrare a pieno titolo tra i browser assistivi, in particolar modo tra quelli orientati a 56
Capitolo 2 – Gli ausili per la disabilità supportare gli utenti con disabilità visive e motorie, implementando la possibilità di gestire la navigazione sul Web mediante ausilio della voce. Per chiudere l’analisi dello stato dell’arte dei browser ad elevata accessibilità è doveroso citare Lynx [42] , un web browser testuale multipiattaforma e scaricabile liberamente, messo a punto dal Distributed Computing Group dell’ Academic Computing Services dell’ University of Kansas. Lynx permette la navigazione nella Rete soltanto mediante l’ausilio della tastiera e garantisce un’ottima integrazione con sistemi di text‐to‐speech in virtù della precisa trasposizione in formato unicamente testuale dei contenuti delle pagine Web. Caduto leggermente in disuso a seguito della nascita degli Screen Reader, Lynx è ancora oggi una pietra miliare nel campo dei browser testuali che può risultare tralaltro estremamente utile per verificare se la progettazione di un sito è stata adattata o meno alle direttive riguardanti l’accessibilità. (figura 15 – www.hattrick.org su Lynx – Un Sito con Frame, assolutamente non accessibile) 57
Capitolo 2 – Gli ausili per la disabilità (figura 16 – www.repubblica.it su Lynx– Un Sito navigabile ma non ad elevata accessibilità) (figura 17 – http://informatica.uniba.it su Lynx – Un Sito Accessibile ) 58
Capitolo 2 – Gli ausili per la disabilità Bibliografia – Capitolo 2 [1] Technical Glossary – Adaptive Technology Resource Center – University of Toronto ‐ http://www.utoronto.ca/atrc/reference/tech/techgloss.html [2] C.Gubitosa ‐ Nuove Tecnologie per Nuove Abilità: Ausili Elettronici al Servizio dei Disabili ‐ http://www.olografix.org/gubi/smau/ [3] B.Stoeger, K.Miesenberger ‐ The conventional Braille display state of the art and future perspectives ‐ Proceedings of the 4th international conference on Computers – 1994 [4] A‐Z to Deafblindness – Refreshable Braille Display http://www.deafblind.com/display.html [5] Babel Infovox – Sito Web Ufficiale – http://www.babel.se [6] Audiologic – Sito Web Ufficiale – http://www.audiologic.it [7] Loquendo – Sito Web Ufficiale – http://www.loquendo.com/it/ [8] EuroVoice – Sito Web Ufficiale – http://www.voicesystems.it [9] Screen Reader – Wikipedia ‐ http://en.wikipedia.org/wiki/Screen_reader [10] Window Eyes – Sito Web Ufficiale ‐ http://www.gwmicro.com/ ‐ 59
Capitolo 2 – Gli ausili per la disabilità [11] Virgo NT – Sito Web Ufficiale ‐ http://www.baum.de [12] Connect Outloud – Sito Web Ufficiale ‐ http://www.freedomscientific.com/ [13] Hal – Sito Web Ufficiale ‐ http://www.dolphinusa.com/ [14] OutSpoken Solo 3.0 – Sito Web Ufficiale ‐ http://www.aagi.com/ [15] Jaws – Sito Web Ufficiale ‐ http://www.freedomscientific.com/ [16] N.Ferrando, A Volpon ‐ Screen Reader, Display Braille e Browser Vocali – Gli strumenti in aiuto ai non vedenti [17] Dragon Naturally Speaking – Sito Web Ufficiale ‐ http://www.scansoft.com/naturallyspeaking/ [18] Via Voice IBM – Sito Web Ufficiale http://www‐
‐ 4.ibm.com/software/speech/ [19] Kolwoz Lawtalk – Sito Web Ufficiale ‐ http://www.unac.com/bics/new1.htm [20] AI Squared – Sito Web Ufficiale ‐ http://www.aisquared.com/ [21] Screen Enlarger – Sito Web Ufficiale ‐ http://www.dolphinuk.co.uk/products/lunar.htm [22] Galileo for NT – Sito http://www.baum.de/English/enggalileo.htm Web Ufficiale ‐ 60
Capitolo 2 – Gli ausili per la disabilità [23] Reader’s Pal – Sito Web Ufficiale ‐ http://www.baum.de/English/enggalileo.htm [24] Screen Magnifier – Sito Web Ufficiale ‐ http://www‐
3.ibm.com/able/snsscmag.html [25] Wikipedia – Eye Tracking ‐ http://en.wikipedia.org/wiki/Eye_tracking [26] D.Anson, M.Glodek, R.M.Pfeiffer, C.G.Rubino, P.T.Schwarz ‐ Long‐Term Speed and Accuracy of Morse Code vs. Head Pointer Interface for Text Generation [27] Head Master Plus – Sito Web Ufficiale ‐ http://www.prentrom.com/manuals/hm_plus.pdf [28] Head Mouse – Sito Web Ufficiale ‐ http://orin.com/access/ [29] Smart Nav – Sito Web Ufficiale ‐ http://www.naturalpoint.com/smartnav/ [30] Tash Mouse Mover – Sito Web Ufficiale ‐ http://www.synapseadaptive.com/switches/tash/mouse_mover.htm [31] Wikipedia – Web Browser ‐ http://en.wikipedia.org/wiki/Web_browser [32] Robert W.Sebesta – Programmare il World Wide Web – McGraw Hill (2003) – Cap. 1 – pagg. 1‐8 [33] Bill Stewart – Living Internet – Web Browser History http://livinginternet.com/?w/wi_browse.htm 61
Capitolo 2 – Gli ausili per la disabilità [35] Alternative Web Browsing – WAI – Web Accessibility Initiative http://www.w3.org/WAI/References/Browsing [36] BrookesTalk Browser – Sito Web Ufficiale ‐ http://cms.brookes.ac.uk/computing/speech/index.php?id=65 [37] Sensus Internet Browser – Sito Web Ufficiale ‐ http://www.sensus.dk/sib10uk.htm [38] Simply Web 2000 – Sito Web Ufficiale ‐ http://www.econointl.com/sw/ [39] Mozbraille – Sito Web Ufficiale ‐ http://mozbraille.mozdev.org/index.html [40] LibBraille – Libreria di Integrazione con Display Braille – Sito Web Ufficiale ‐ http://www.libbraillle.org/ [41] Accessibility in Opera ‐ http://www.opera.com/features/access/ [42] Lynx – Sito Web Ufficiale ‐ http://lynx.isc.org/ Capitolo 3 – Progettazione di un browser assistivo 62
Capitolo 3 Progettazione di un Browser Assistivo 3.1 Motivazioni e scopo: L’idea di base L’analisi dello stato dell’arte delle tecnologie assistive, illustrata nel capitolo precedente, ha sottolineato l’assoluta vivacità di un mercato che cerca di andare incontro in tutti i modi possibili agli utenti diversamente abili con una grande varietà di soluzioni e dispositivi. In funzione della differente tipologia di disabilità da cui si è affetti, infatti, la tecnologia odierna permette di usufruire di strumenti che riducono in maniera importante (in alcuni casi persino eliminandole del tutto) le barriere che separano questi individui da una normale fruizione delle funzionalità che Internet in generale ed il Web in particolare mettono a disposizione. La quasi totalità delle informazioni che quotidianamente sono veicolate sul Web è accessibile oggigiorno mediante i Web Browser, e il mercato degli stessi, come mostrato in precedenza, presenta una varietà eterogenea di soluzioni e di applicativi finalizzata ad avvicinare gli utenti con generiche disabilità alla Rete ed agli strumenti offerti dalla tecnologia. Esistono infatti numerose tipologie di browser progettati su misura per individui disabili; si possono citare quelli indirizzati ad utenti ipovedenti (implementando particolari tecniche di magnificazione delle informazioni rappresentate sullo schermo), quelli per individui non vedenti (vedi gli ScreenReader) e infine browser ad elevata accessibilità che supportano tutte le direttive e le linee guida recentemente stilate in materia di accessibilità. Capitolo 3 – Progettazione di un browser assistivo 63
In conseguenza di ciò è dunque opportuno chiedersi: perché e soprattutto per chi progettare un nuovo browser assistivo? La risposta è altrettanto immediata: Il mercato dei browser assistivi è un mercato ricco, eterogeneo, vivace, in continuo aggiornamento, ma di certo non saturo. Sfogliando a ritroso l’analisi dello stato dell’arte delle tecnologie assistive si incontra infatti una tipologia di dispositivi per i quali non è stato ancora progettato un particolare Web Browser che ne integri le funzionalità permettendo così la navigazione a particolari classi di individui diversamente abili: Si tratta degli Eye‐Tracker e gli Head‐Tracker. Erroneamente si potrebbe ritenere che i dispositivi alternativi di puntamento, in quanto tali, non richiedano che la struttura e l’aspetto dei Web Browser debbano essere modificati mediante particolari accorgimenti progettuali. Erroneamente, perché è immediato pensare che pagine Web progettate per essere navigate mediante l’ausilio degli arti superiori e del mouse non possano essere fruite allo stesso modo se i dispositivi di input disponibili siano differenti da quelli originariamente immaginati. I dispositivi di puntamento alternativi, intuitivamente, includono infatti il concetto di emulazione. Emulare è sinonimo di simulare, e dunque Eye‐Tracker e Head‐Tracker sono dei dispositivi che spostano il puntatore sullo schermo simulando il movimento degli arti a partire dal movimento del capo o dalle fissazioni dell’utente. Nel concetto di emulazione, però, è insito quello di “non‐precisione”. L’emulazione è in generale una procedura di riproduzione di un qualcosa, e, in quanto tale, può presentare dei margini di errore, una minore precisione, o, in generale, un comportamento anche solo leggermente differente da quello desiderato. Tutte queste considerazioni pongono lʹaccento sulla necessità e l’importanza di progettare un Web Browser che supporti in maniera nativa le funzionalità offerte dai dispositivi alternativi di puntamento e che permetta dunque la navigazione su Internet Capitolo 3 – Progettazione di un browser assistivo 64
ad individui affetti anche contemporaneamente da più tipologie di disabilità (es. individui sordomuti e impossibilitati a muovere gli arti). L’idea di base è quella di mettere a punto un browser che permetta l’integrazione con Head‐Tracker ed Eye‐Tracker, garantendo una gestione appropriata di tutte le problematiche connesse con la minore precisione di puntamento legata all’utilizzo di questi dispositivi di puntamento. Come già accennato nel capitolo precedente, però, Head ed Eye Tracker non sono dispositivi specificatamente orientati ad utenti disabili. Certo, la disabilità rappresenta una delle applicazioni principali per strumenti di questo tipo, ma un browser che supporti la navigazione con dispositivi alternativi di puntamento quali un Head‐Tracker potrebbe tranquillamente essere fruibile anche da individui non affetti da alcun tipo di disabilità, e anzi, la progettazione di un software di nuova concezione che articoli l’interazione tra utente e sistema in maniera differente da quella “convenzionale” potrebbe aprire rapidamente interessanti scenari nella progettazione di sistemi e applicativi software con interfacce di nuova generazione, totalmente moderne e assolutamente svincolate dagli attuali dispositivi di input con cui siamo abituati ad interagire quotidianamente. 3.2 Analisi Comparativa dei Browser La creazione ex‐novo di un Web Browser che includa ed integri le funzionalità offerte dai sistemi di puntamento alternativi è un’operazione non semplice e che richiede notevole dimestichezza e conoscenza delle tecnologie alla base di applicativi di questo tipo. Costruire da zero un browser che incorpori nativamente delle funzionalità complesse è qualcosa che supera la semplice realizzazione di interfacce e menu utente e che va oltre la classica progettazione di sistemi software. Il “cuore” dei Web Browser è infatti rappresentato da un vero e proprio sottosistema che si occupa di trasformare le Capitolo 3 – Progettazione di un browser assistivo 65
informazioni contenute all’interno della pagina, formattandole e presentandole in maniera tale da renderle comprensibili all’utente: il Layout Engine. Come si può facilmente intuire dallo stesso nome, il Layout Engine è una componente fondamentale nell’economia dei Web Browser, è il “motore” del browser, ciò che permette al browser di funzionare, ciò che, in altri termini, definisce e costruisce il layout, permettendo all’utente di visualizzare sullo schermo le informazioni contenute in un documento della Rete. Progettare da zero un Web Browser implica dunque progettare da zero anche una componente di questo tipo, una componente caratterizzata da una complessità indubbiamente non indifferente. Sebbene infatti la proliferazione dei Web Browser a cui si è fatto riferimento nel capitolo precedente sia ulteriormente testimoniata dal lungo elenco di software di questo tipo presente all’interno del sito Web Wikipedia [1], è immediato rendersi conto di come la quasi totalità dei browser citati sia stata realizzata a partire dai due Layout Engine più famosi: Trident, utilizzato da Internet Explorer, e Gecko, alla base del client open‐source Mozilla Firefox. Costruendo il proprio Browser a partire da un Layout Engine preesistente, dunque, si elimina dal processo di progettazione la componente con la complessità più elevata, riducendo di conseguenza in maniera notevole le difficoltà implementative di un software di questo tipo. Se da un lato la presenza sul mercato di tanti Web Browser sia un dato di fatto, dall’altro lato il concetto di “guerra tra Browser”, illustrato più volte nel capitolo precedente dovrebbe dunque essere più opportunamente trasformato in “guerra tra Layout Engine”, poiché la vera lotta attuale non è tra Internet Explorer, Mozilla, e gli altri browser minori, ma tra i motori che si occupano della visualizzazione sullo schermo delle informazioni acquisite dal Web: Trident, Gecko, Presto (il Layout Engine di Opera), e altri Layout Manager poco conosciuti [2]. Capitolo 3 – Progettazione di un browser assistivo 66
Il primo passo del processo di costruzione di un nuovo Web Browser è tutto racchiuso nella scelta del Layout Engine a cui riallacciarsi e sul quale il nuovo sistema si baserà. Si tratta di una scelta importante, non immediata, e che ha soprattutto un peso specifico non indifferente nel definire gli step successivi del processo di progettazione. Ciascuno dei motori di rendering, infatti, si basa su tecnologie differenti e supporta in maniera diversa gli standard della rete, dunque la scelta da compiere non può prescindere da un’analisi estremamente approfondita di questi due aspetti. Il sito Web Wikipedia illustra attraverso una trattazione schematica ma sufficientemente articolata dell’argomento [3] tutte le possibili scelte a disposizione del programmatore descrivendo vantaggi, svantaggi, caratteristiche, tecnologie ed eventuali informazioni utili su ciascuna delle scelte che il ventaglio dei motori di rendering propone. E’ interessante innanzitutto notare come l’unico Layout Engine disponibile gratuitamente e rilasciato senza una licenza proprietaria sia Gecko, cuore del progetto Mozilla. Tutti gli altri motori di Rendering, a partire da Presto (alla base di Opera) fino ad arrivare a Tasman (su cui è costruito Internet Explorer per Mac) non sono disponibili gratuitamente. A metà tra queste due scelte si pone Internet Explorer (nella versione classica, quella per Windows) con il proprio Layout Engine, Trident. Sebbene a differenza di Gecko il codice sorgente del motore non sia disponibile gratuitamente, la Microsoft rilascia senza alcun costo la DLL del browser attualmente più diffuso sul mercato per poter realizzare con semplicità dei browser “Internet Explorer‐based” che ne estendano le funzionalità. Il secondo aspetto da considerare nel valutare ciascun motore di rendering è dato, come detto, dalle tecnologie alla base degli stessi e soprattutto dagli standard che ciascun sottosistema decide o meno di supportare. Anche in questo caso le scelte operate da ciascun produttore vanno a classificarsi in due macro‐categorie: da un lato si può porre la scelta della Mozilla Foundation, di supportare in tutto e per tutto nel proprio browser e nel proprio layout engine gli standard della rete consigliati dal W3C come CSS, RDF, XML, DOM e XHTML. Dall’altra parte si pone la Microsoft, che nei Capitolo 3 – Progettazione di un browser assistivo 67
limiti del possibile ha cercato e cerca tuttora di rendere universali proprie soluzioni proprietarie relativamente alle tecnologie e ai linguaggi per il Web. Questo parallelo potrebbe continuare ancora a lungo [4], tirando in ballo per esempio la disponibilità di consultare e modificare a piacimento il codice sorgente (Gecko come detto è Open Source, Trident no), l’ampio supporto della community alle spalle del Progetto Mozilla, una maggiore attenzione verso tutte le problematiche strettamente legate con la sicurezza e la grande possibilità di estendere e personalizzare il sistema sulla base delle proprie esigenze e necessità. Tutte queste considerazioni, unite alla bontà stessa di Gecko, un motore di rendering estremamente potente ma allo stesso tempo leggero, veloce e comodo da integrare nelle proprie applicazioni, permettono di affermare senza ombra di dubbio come questo Layout Engine rappresenti il punto di partenza ideale per costruire il proprio browser, o, nel nostro caso, come Mozilla Firefox rappresenti il client più adatto ad estendere le proprie caratteristiche integrando tutte le funzionalità della navigazione sul web attraverso dispositivi di puntamento alternativi e tutte le problematiche che questa nuova modalità di interazione porta alla luce. 3.3 L’ambiente di lavoro: Mozilla Firefox Mozilla Firefox è un Web Browser relativamente recente, nato a partire da un progetto open source della Mozilla Foundation con lo scopo di creare un browser leggero e funzionale partendo dalle solide basi della Suite Mozilla (già esistente da anni, attualmente ferma alla versione 1.7.10) Già antecedentemente al rilascio della prima versione ufficiale, Firefox aveva suscitato ottime impressioni ed un interesse sempre maggiore sia da parte degli utenti che dei media di settore, ma oggi, a poco più di un anno dal rilascio della prima versione ufficiale (la release 1.0 del Browser è datata 9 novembre 2004) le prospettive di sviluppo del client hanno superato ogni più rosea aspettativa. Capitolo 3 – Progettazione di un browser assistivo 68
Come testimoniato dal sito Web Spread Firefox [5], il link per il download del programma ha festeggiato il 20 ottobre 2005 i 100 milioni di click, con una quota di mercato che a Luglio 2005 è arrivata a sfiorare quasi il 9% e si prevede supererà a breve il 10% [6], una cifra davvero considerevole considerando lo strapotere Microsoft degli ultimi anni e il comportamento non troppo limpido della stessa azienda di Redmond, proprio recentemente accusata di abuso di posizione dominante nel campo dei sistemi operativi, dei player multimediali e appunto dei Web Browser [7] (figura 18 – Un’immagine celebrativa festeggia i 100 milioni di download: E’ il 20 ottobre 2005) E’ difficile individuare con precisione i motivi del successo di Mozilla Firefox, probabilmente si può parlare di un mix di più fattori differenti. Nel paragrafo precedente sono stati citati alcuni vantaggi intrinseci nella filosofia della Mozilla Foundation, come la community alla spalle del progetto, il codice liberamente disponibile, l’elevata estendibilità, il rispetto per gli standard W3C e le elevate potenzialità del proprio motore di rendering. Tutto ciò, unito probabilmente alla traballante posizione di Internet Explorer nel campo della sicurezza e la popolarità in calo della stessa azienda (che in alcune frange del popolo della Rete trascende persino in un rifiuto aprioristico di tutti i prodotti targati Microsoft), ha permesso a Firefox di inserirsi sul mercato nel periodo probabilmente più propizio facendosi conoscere ed apprezzare in grandi fette di utenti per tutte le sue caratteristiche. Capitolo 3 – Progettazione di un browser assistivo 69
3.3.1 MFL: Mozilla Foundation License Uno degli aspetti più interessanti da trattare riguarda i termini sotto cui il browser stesso viene licenziato, permettendo a tutti la fruizione, la consultazione, la modifica e l’eventuale redistribuzione dell’eseguibile modificato. Originariamente Netscape (da cui la Mozilla Foundation ha successivamente acquisito la licenza) aveva rilasciato il proprio software sotto licenza Open Source, ma questa scelta però fu piuttosto travagliata. L’interesse primario di Netscape, infatti, era quello di coniugare la diffusione del codice con la possibilità di integrarlo in applicazioni proprietarie, e le licenze Open Source allora presenti non permettevano la contemporanea presenza di queste due condizioni. In conseguenza di ciò, sempre Netscape, a Marzo del 1998 rilasciò la prima versione di una propria licenza, chiamata NPL (acronimo di Netscape Public License), che, sottoposta al giudizio del pubblico ricevette immediatamente forti critiche dovute principalmente alla facoltà, che Netscape stessa si riservava, di apportare eventuali modifiche al codice e di rilasciarle sotto un’altra licenza. [8] Poche settimane dopo la Mozilla Foundation rilasciò a sua volta una versione riveduta e corretta della NPL, cui è stato dato il nome di MFL (Mozilla Foundation License). A grandi linee questa nuova licenza ha ripreso tutte le caratteristiche salienti della licenza NPL, eliminando sostanzialmente i privilegi che Netscape si riservava e che tanto erano stati criticati dagli utenti della Rete. Come detto, la Mozilla Foundation License permette la fruizione di tutti i prodotti sviluppati dalla fondazione stessa senza alcun costo, garantendo allo stesso tempo la possibilità di consultare il codice sorgente (da rilasciare obbligatoriamente con i binari eseguibili) e di modificarlo a proprio piacimento. Unica restrizione fondamentale che la MFL impone è data dall’obbligo di segnalare tutte le modifiche effettuate e di rilasciarle sempre sotto licenza MFL, vincolando così il programmatore a mantenere sempre sotto MFL un prodotto originariamente nato sotto MFL. Capitolo 3 – Progettazione di un browser assistivo 70
La Mozilla Foundation License, il cui testo è disponibile integralmente sulla Home Page della Fondazione [9], è ad oggi una delle licenze più utilizzate, apprezzate e conosciute, ed è riconosciuta dalla Open Source Initiative come licenza Open Source. 3.3.2 Gecko: il Motore di Rendering Il compito di un layout engine è quello di acquisire il contenuto di una pagina web (HTML, XML, immagini, applets e altro) e le informazioni di formattazione (come ad esempio Cascading Style Sheets ‐ CSS) e successivamente visualizzare il documento formattato sullo schermo. Come detto, Gecko è il layout engine su cui si basa il browser Mozilla Firefox. Facendo riferimento al sito web di Netscape [11], possiamo analizzare specificatamente quelle che sono le caratteristiche principali di questo motore di rendering: •
Leggero: Gecko è stato progettato per essere leggero. E’ modularizzato ed ha una dimensione molto ridotta rispetto ai suoi concorrenti browser engine. •
Veloce: Gecko ritrova e dispone le componenti di una pagina web in maniera molto veloce. •
Compatibile con gli standards: Gecko supporta tutti gli standards web (FTP, HTTPS, XUL, JavaScript, CSS, DOM, XML e altro) ; •
Indipendente dalla piattaforma (Cross‐Platform, Cross‐Device): tutto il suo codice è svincolato dal sistema operativo su cui viene eseguito e può lavorare su svariati dispositivi hardware. Capitolo 3 – Progettazione di un browser assistivo 71
•
Modulare, Embeddable: la modularità di Gecko aiuta gli sviluppatori ad aggiungere o rimuovere moduli con minore sforzo. Gecko è implementato come una collezione di componenti XPCOM (vedi in seguito) che possono essere rimosse e aggiunte a piacimento. Gecko può essere incorporato in qualsiasi applicazione. •
Open source: Gecko è completamente open‐source ed è coperto da licenza MPL (Mozilla Public License). •
Gratuito: non ci sono costi per distribuire Gecko incorporandolo in un altro prodotto. Lo sviluppatore è libero di scegliere quali moduli includere all’interno della sua applicazione. La semplicità di integrazione ed “embedding” di Gecko all’interno di nuovi applicazioni è probabilmente la caratteristica più interessante nell’ottica di una progettazione e realizzazione di un Web Browser che incorpori le funzionalità offerte da dispositivi Eye‐Tracker o Head‐Tracker. Ovviamente la fruizione di Gecko e delle funzionalità offerte da questo motore di rendering richiede una certa dimestichezza con tutte le tecnologie e i linguaggi su cui il Gecko Runtime Environment (GRE) si basa. Per la rappresentazione strutturata delle informazioni acquisite dai documenti presenti sulla Rete, Gecko utilizza DOM (Document Object Model), la rappresentazione e la costruzione delle interfacce sfrutta invece il potente linguaggio XUL (Xml User Interface Language), mentre la creazione, la cancellazione e in generale la gestione delle componenti e degli oggetti incorporati all’interno del Layout Engine sarà a carico di XPCOM (Cross Platform Component Object Model). Analizzando nello specifico le modalità con cui avviene l’elaborazione dei dati all’interno del layout engine [12], Gecko acquisisce l’input (da una risorsa remota o locale) e il primo passo nell’elaborazione dell’input consiste nell’operazione di parsing. Il documento viene rappresentato mediante una struttura ad albero chiamata appunto Capitolo 3 – Progettazione di un browser assistivo 72
“document” (struttura basata sul W3C DOM – Document Object Model). In questa fase è ancora possibile modificare il contenuto del documento utilizzando le apposite DOM API. E’ presente anche un parser CSS che si occupa invece di effettuare il parsing dei fogli di stile. I dati così ottenuti (fogli di stile e albero del documento) vengono passati al “Frame Constructor” dove per frame si intende lo spazio disponibile all’interno della finestra del browser per la visualizzazione del documento. (figura 19 – Schema del Flusso dei Dati in Gecko ) Al termine di questa fase viene prodotto un nuovo albero, il Frame Tree, ma, mentre nel precedente albero si enfatizzava la relazione logica tra gli elementi, qui ci si concentra sulle informazioni e sui calcoli necessari per visualizzare il documento nel frame. Poichè il documento potrebbe essere non necessariamente visualizzato su di uno schermo, ma, ad esempio, dato in input ad una stampante, potrebbero essere costruiti più frame tree. Inizialmente il frame non ha dimensione. Successivamente viene avviata una nuova fase chiamata reflow che prosegue i calcoli necessari per la visualizzazione del documento. Quando la rappresentazione del documento all’interno del frame tree viene modificata, la parte dell’albero investita dal cambiamento, viene etichettata “dirty” e viene ripetuta l’operazione di reflow sulle parti dell’albero “dirty”, finchè tutte le parti non siano etichettate “clean”. Ricordiamo che queste operazioni sono di manipolazione di dati e non è ancora coinvolta la visualizzazione sul monitor. La successiva fase attiva appunto il View Manager che si occuperà della visualizzazione sullo schermo, delegando al sottomoduli gfx e widget le comunicazioni Capitolo 3 – Progettazione di un browser assistivo 73
a basso livello con il sistema operativo (naturalmente entrambi questi moduli sono dipendenti dalla piattaforma). Pertanto i dati strettamente correlati alla visualizzazione dei documenti sullo schermo (come ad esempio le coordinate delle varie componenti del documento), sono detenuti dalle tre classi che implementano il ViewManager, disponibili nella cartella mozilla/view del codice sorgente. 3.3.3 Architettura e Componenti Fin dalla propria nascita la Mozilla Foundation si è sempre mostrata molto attenta nell’ indirizzare in modo preciso ed univoco il processo di sviluppo di tutti i prodotti che fanno capo alla fondazione. Definire con precisione i punti salienti e le direzioni del processo evolutivo di un software, soprattutto se si tratta di sistemi open source, è un aspetto di fondamentale importanza poiché evita che lo sforzo dei programmatori e di tutti colori i quali collaborano al progetto possa disperdersi in più direzioni contemporanee. Dalla roadmap [13] presentata sulla home page di Mozilla si evince immediatamente che per il prodotto “storico” della Fondazione, la Mozilla Suite (un client che integra le funzionalità di Web Browser, Client di posta elettronica, Client di Chat, Newsreader e composer di pagine Web), non verranno più rilasciate nuove versioni, focalizzando l’attenzione dei programmatori verso due client separati: Mozilla Thunderbird per le eMail ed appunto Mozilla Firefox per il Web Browsing. Nati da una costola del progetto originale, entrambi ricalcano a grandi linee il progetto architetturale della Mozilla Suite, le componenti, e il modo in cui queste interagiscono tra di loro. In una recente pubblicazione [14] , l’organizzazione strutturale di Mozilla è stata descritta come un sistema a più livelli, mostrato in immagine 19. Capitolo 3 – Progettazione di un browser assistivo 74
(figura 20 – Architettura Concettuale della Mozilla Application Suite ) L’Application Package include tutte le componenti con cui l’utente finale del sistema interagisce direttamente: il client di Chat, l’editor per pagine Web, il client di posta e il web Browser. L’insieme di queste componenti viene chiamato con il nome in codice di SeaMonkey. Il livello di servizio rappresenta un livello intermedio, un livello a metà tra ciò che l’utente concretamente “vede” , ed il modo in cui la Suite comunica a basso livello con il sistema operativo. Ciascuna delle componenti di questo livello può essere analizzata specificatamente. In figura 21, per esempio, è illustrata la caratterizzazione della componente che gestisce il Layout e il Rendering delle pagine. Capitolo 3 – Progettazione di un browser assistivo 75
(figura 21 – Componente di gestione del Layout e del Rendering) Come mostrato nel paragrato precedente, le questioni strettamente connesse con il rendering delle pagine sono tutte a carico di Gecko, il layout engine di Mozilla. La componente fondamentale di Gecko è quella che gestisce il parsing dei documenti acquisiti dalla rete a partire dal DOM della pagina per permetterne poi la successiva visualizzazione sullo schermo. Accanto al normale parsing dei documenti HTML e di tutti i linguaggi derivati da XML , Gecko utilizza anche particolari librerie che permettono la decodifica dei formati più comuni per le immagini e per la gestione delle informazioni contenute nei fogli di Stile CSS. In figura 21, invece, è illustrato il comportamento delle componenti che si occupano della gestione di tutte le problematiche connesse con la sicurezza e il networking. Capitolo 3 – Progettazione di un browser assistivo 76
(figura 22 – Componente di gestione del Networking e della Sicurezza) Fulcro di questa componente è rappresentato dalla libreria Necko (Network Library for Gecko), che si occupa di effettuare semplici operazioni di parsing degli URL e degli URI, aprendo immediatamente gli stream che permettono di inviare e ricevere dati tra i tutti i vari protocolli: http, ftp, pop3, irc, ecc. Le componenti NSS e PSM gestiscono infine tutte le problematiche connesse con la sicurezza, implementando rispettivamente il supporto per i protocolli sicuri come SSL (utilizzato per esempio nei sistemi di commercio elettronico e banche online) e per tutte le operazioni di crittografia e gestione delle chiavi di sicurezza. L’ultimo livello, quello di runtime, comunica in maniera più o meno diretta con il sistema operativo, implementando delle API per la gestione e sincronizzazione dei thread, le operazioni di I/O, la gestione della memoria, dei processi, degli indirizzamenti e il linking delle librerie. Tutte queste componenti, ovviamente, lavorano in maniera tale da essere totalmente cross‐platform, indipendenti dal particolare sistema operativo su cui la Mozilla Application Suite è attualmente eseguita. Capitolo 3 – Progettazione di un browser assistivo 77
In un volume pubblicato da McFarlane [15], invece, viene mostrata un’organizzazione architetturale differente (mostrata in figura 22 e 23), che enfatizza la scissione tra le componenti che interagiscono direttamente con l’utente e quelle che interagiscono direttamente con il sistema. (figura 23 – Componenti che interagiscono direttamente con il sistema) Capitolo 3 – Progettazione di un browser assistivo 78
(figura 24 – Componenti che interagiscono direttamente con l’utente) In figura 24 sono presentate tutte le componenti che si occupano di gestire gli input utente (tramite mouse e tastiera), di acquisire la struttura ad albero della pagina Web (come DOM), di organizzare la caratterizzazione dell’interfaccia utente mediante Skin e Temi per il browser, e di permettere la navigazione vera e propria sul web mediante gli URL. Viceversa la figura 23 descrive l’interazione delle componenti come XPCOM e XPConnect con il sistema. Punto di partenza è rappresentato dai ContractID, una tecnologia introdotta proprio da Mozilla finalizzata a rappresentare univocamente ciascuna componente per permetterne poi un più semplice richiamo. A metà del diagramma, in comune tra tutte le componenti, ci sono un linguaggio di programmazione (Javascript) e un linguaggio di markup basato su XML come RDF, entrambi ampiamenti utilizzati sia nella codifica di moduli esterni ed estensioni, sia nella descrizione di tutti gli elementi e gli aspetti (più precisamente potremmo parlare di risorse) legati al browser. Capitolo 3 – Progettazione di un browser assistivo 79
3.3.4 Sviluppo di Temi ed Estensioni Una delle caratteristiche fondamentali della suite Mozilla è rappresentata inoltre dall’opportunità di modificare a proprio piacimento l’aspetto e le funzionalità del browser mediante l’utilizzo di temi ed estensioni. Con i temi gli utilizzatori di Firefox possono personalizzare a loro piacimento lʹaspetto del proprio browser. E’ possibile modificare il ʺlook ʹn feelʺ di qualsiasi oggetto visualizzato sullo schermo, a partire dai pulsanti delle barre degli strumenti fino ad arrivare a tutto il browser nel suo complesso. Le estensioni, viceversa, sono piccoli programmi che aggiungono nuove funzionalità a Mozilla Firefox. Possono aggiungere un semplice bottone alle barre degli strumenti ma anche funzionalità completamente nuove al browser. Il grande vantaggio delle estensioni è che permettono a Mozilla Firefox di rimanere leggero. Temi ed estensioni vengono ottimamente gestiti all’interno del client mediante il supporto di un Gestore di temi ed estensioni, che automatizza e semplifica le operazioni di installazione, disinstallazione e configurazione di tutte le possibili opzioni. Al momento dell’installazione il browser include un set predefinito di estensioni ed un tema di default. Sulla base delle necessità dell’utente poi, ovviamente, il Web offre un ampio ventaglio di nuovi temi ed estensioni sia su apposite sezioni del sito Web di Mozilla [16], sia su siti non ufficiali stranieri (uno su tutti, The Extension Mirror [17]) ed italiani (Extenzilla.it [18]). L’ampio supporto della community alle spalle del progetto Mozilla è sempre stato un cavallo di battaglia della Fondazione, e questo aspetto può essere ulteriormente apprezzato facendo caso al gran numero di temi ed estensioni sviluppati e rilasciati gratuitamente da programmatori professionisti o da semplici appassionati. Ad oggi sono presenti solo sui server ufficiali di Mozilla.org più di 800 estensioni e più di 250 temi, ma si tratta di cifre in continuo movimento e che possono essere Capitolo 3 – Progettazione di un browser assistivo 80
ulteriormente incrementate andando a considerare tutte le estensioni non ufficiali rilasciate sul Web. Nel caso in cui un utente abbia necessità di personalizzare il browser aggiungendo delle funzionalità non ancora implementate in nessuna estensione disponibile sulla Rete, Mozilla mette a disposizione una grande quantità di tutorial, guide, articoli e strumenti utili per semplificare quanto più possibile la realizzazione di questi piccoli programmi. Il punto di partenza nella realizzazione delle estensioni è rappresentato dall’ampia documentazione presente nella sezione nella home page ufficiale di Mozilla.org [19] e nella sezione Development della Knowledge Base della community Mozilla [20]. Nel caso specifico entrambi i siti offrono una lunga trattazione sulla struttura delle Extension e sulle tecnologie utilizzate per svilupparle. La creazione di una nuova estensione richiede che il programmatore abbia dimestichezza con i principali linguaggi che sono alla base del progetto Mozilla, e cioè: •
XUL (XML User‐Interface Language). Usato per costruire il layout e l’interfaccia dell’applicazione •
Javascript. Linguaggio con cui la maggior parte delle estensioni sono scritte •
DOM (Document Object Model). Utilizzato per manipolare XUL e HTML in tempo reale sulla base della struttura ad albero acquisita •
XPCOM/XPConnect. Componenti che permettono una comunicazione a più basso livello (per esempio con il filesystem o con le preferenze di sistema) •
CSS (Cascading Style Sheets). Utilizzato per definire lo stile dell’interfaccia. Capitolo 3 – Progettazione di un browser assistivo 81
L’utilizzo combinato di queste tecnologie permette di sviluppare le estensioni in maniera estremamente intuitiva, permettendo la successiva pacchettizzazione e l’eventuale rilascio sulla Rete per permetterne la fruizione a tutti gli utenti della Community alle spalle del progetto Mozilla. Come detto è possibile sviluppare estensioni di diversa natura: A partire dall’integrazione di box di ricerca all’interno della Toolbar, fino ad arrivare a componenti aggiuntive che permettono di visualizzare le previsioni del tempo, passando per estensioni che si comportano come dei veri e propri “listener” e controllano ad intervalli di tempo regolari il contenuto della propria casella di posta elettronica. Ovviamente il tempo necessario allo sviluppo delle estensioni è direttamente proporzionale all’entità e alla complessità delle stesse, ma gli innegabili vantaggi dovuti da un lato all’immediato supporto di utenti provenienti da tutto il mondo che mettono a disposizione tutta la propria esperienza sul Forum della Community della Mozilla Foundation, e dall’altro alla potenza, all’immediatezza e alla praticità dei linguaggi e delle tecnologie necessarie per lo sviluppo di estensioni, sono tutti fattori che sottolineano ulteriormente la bontà della scelta di partire da Mozilla Firefox per estendere le funzionalità di un Web Browser integrando il supporto per la navigazione con dispositivi di puntamento alternativi. Capitolo 3 – Progettazione di un browser assistivo 82
Bibliografia Capitolo 3 [1] Wikipedia, List of Web Browser ‐ Layout Engines ‐ http://en.wikipedia.org/wiki/List_of_web_browsers [2] Wikipedia, List of http://en.wikipedia.org/wiki/List_of_layout_engines [3] Wikipedia, Comparison of Layout Engines ‐
http://en.wikipedia.org/wiki/Comparison_of_layout_engines [4] N.Deakin ‐ 101 things that the Mozilla browser can do that IE cannot http://www.xulplanet.com/ndeakin/arts/reasons.html [5] Spread Firefox – Sito Web di supporto del progetto Firefox – http://www.spreadfirefox.com [6] Punto Informatico ‐ Firefox in Volata, Senza Gregari ‐ Anno X n. 2349 di lunedì 18 luglio 2005 http://punto‐informatico.it/p.asp?i=54144 [7] Punto Informatico – Antitrust, Microsoft risponde alla UE ‐ Anno VIII n. 1935 di martedì 21 ottobre 2003 http://punto‐informatico.it/p.asp?i=45649 [8] S.Aliprandi ‐ L’Altra faccia del Copyright – Capitolo III, paragrafo 7 [9] Mozilla Public License Version 1.1 ‐ http://www.mozilla.org/MPL/MPL‐1.1.html Capitolo 3 – Progettazione di un browser assistivo 83
[10] Embedding Gecko FAQ – What is a layout engine? ‐
http://www.mozilla.org/newlayout/faq.html [11] Netscape Gecko Whitepaper ‐ Guidin principles behind Netscape Gecko ‐ http://wp.netscape.com/browsers/gecko/whitepaper.pdf [12] Mozilla.org ‐ Gecko Embedding Basic http://www.mozilla.org/projects/embedding/embedoverview/EmbeddingGecko.pdf [13] Mozilla.org ‐ Roadmap ‐ http://www.mozilla.org/roadmap.html [14] A.d’Souza, K.Hildebrand, G.Israeli – Conceptual Architecture of Mozilla , for CS746 – R. Holt ‐ September 30, 2004 [15] N.McFarlane, Rapid Application Development with Mozilla, Prentice Hall, 2003 – cap.1 , Fundamentals Concepts [16] Mozilla.org – Mozilla Update , Addons ‐ https://addons.mozilla.org/?application=firefox [17] The Extension Mirror – Principale risorsa straniera per le estensioni di Mozilla Firefox ‐ http://www.extensionsmirror.nl/ [18] Extenzilla.it – Principale sito web italiano per le estensioni di Mozilla Firefox – http://www.extenzilla.it [19] Mozilla.org – Documentazione http://developer.mozilla.org/en/docs/Main_Page – Development ‐ Capitolo 3 – Progettazione di un browser assistivo 84
[20] Mozillazine.org – http://kb.mozillazine.org/Dev Knowledge Base – Development ‐ Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 85
Capitolo 4 Implementazione di un Algoritmo di Localizzazione 4.1 Il problema della localizzazione Tutte le considerazioni fatte fino a questo punto sottolineano ulteriormente il valore e la bontà del progetto Mozilla sotto tutti i punti di vista: a livello di prodotti realizzati, a livello di tecnologie sviluppate, a livello di principi ispiratori alla base delle idee su cui la Mozilla Foundation ha basato il proprio successo. Eʹ indubbio che Mozilla Firefox sia un browser di qualità; Lo dicono i numeri, lo dicono la percentuale di utilizzatori, ma lo dicono anche delle considerazioni spiccatamente tecniche: le sue ottime funzionalità, la potenza del suo motore di rendering, il progetto architetturale alla base del client, il rispetto degli standard, l’interesse verso tutte le problematiche connesse con la sicurezza e le innumerevoli opportunità di personalizzazione dell’interfaccia che Firefox offre mediante l’utilizzo di temi. Tutte caratteristiche che evidenziano ancora una volta l’assoluto valore di questo client. Su tutte, però, la possibilità di estendere in maniera comoda ed immediata le funzionalità di Mozilla Firefox attraverso l’utilizzo delle estensioni rappresenta il punto di partenza ideale per integrare in un browser le funzionalità di navigazione mediante lʹuso di dispositivi di puntamento alternativi, e lo rende la miglior soluzione possibile da cui partire per la progettazione e la realizzazione di un browser assistivo. Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 86
Nel nostro progetto sarà proprio unʹestensione ad occuparsi di buona parte delle problematiche che una modalità di interazione differente da quella tradizionale porta con sé. Sarà proprio un estensione, infatti, ad implementare tutti gli accorgimenti necessari per permettere la navigazione sul Web mediante dei dispositivi di input assistivi. Ma quali sono in realtà queste problematiche? Siamo sicuri che ci siano? E quali gli accorgimenti da prendere? Apparentemente si potrebbe ritenere che lʹutilizzo di un dispositivo di puntamento alternativo non richieda che il comportamento o la caratterizzazione del browser debba essere modificata in funzione delle nuove problematiche che potrebbero presentarsi. Di slancio si potrebbe infatti ritenere superfluo progettare un client specifico per supportare delle caratteristiche di questo tipo, essendo gli head‐
tracker strumenti che si limitano semplicemente a muovere il cursore sullo schermo sulla base dei movimenti del capo o delle fissazioni dell’utente. La realtà e soprattutto l’osservazione sperimentale (intesa come navigazione sul Web utilizzando degli strumenti di questo tipo) ci mostrano però come tutto ciò non sia vero. Per dimostrarlo, poniamo come punto di partenza l’analisi del significato che un comune vocabolario della lingua italiana ci offre per buona parte dei termini utilizzati fino a questo momento. Head‐Tracker ed Eye‐Tracker sono dei dispositivi di puntamento alternativi. Il Dizionario De Mauro‐Paravia [1], alla voce “alternativo”, mostra quanto segue: al|ter|na|tì|vo agg. 1 che si alterna; che procede in modo alternato 2a che può essere usato in sostituzione di qualcosa che non si può o non si vuole usare 2b che impone una scelta: le due strade sono alternative Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 87
Head‐Tracker ed Eye‐Tracker sono dunque dei dispositivi di puntamento che possono essere utilizzati in situazioni di disabilità (cfr. “non si può usare”) o in ambito di ricerca di nuove modalità di interazione (cfr. “non si vuole usare”). Il “qualcosa” a cui si fa riferimento nella definizione, ovviamente, è l’utilizzo di tastiera e mouse per interagire con il sistema. Dispositivi di questo tipo, come detto precedentemente, vanno a simulare il click dell’utente sullo schermo in funzione dei movimenti del capo e delle fissazioni. Tutte le problematiche che questa nuova modalità di interazione porta con sé sono tutte insite nella definizione stessa del verbo simulare [1] si|mu|là|re v.tr. (io sìmulo) 2 estens., imitare un suono, un movimento, un effetto visivo 4 scient., riprodurre artificialmente le condizioni in cui si svolge un processo o un fenomeno, per studiarne e verificarne gli effetti Anche in questo caso, facendo sempre riferimento alle definizioni evidenziate in grassetto, si può evincere come il “movimento” (cfr. definizione 2) che si va a simulare sia quello del mouse sullo schermo, e come il “processo” che si va a “riprodurre artificialmente” (cfr. definizione 4) sia l’interazione tra l’utente e il web browser. Infine, mostriamo i significati associati al verbo imitare, sempre facendo riferimento al medesimo dizionario [1] i|mi|tà|re v.tr. (io ìmito) 1 prendere a modello o come riferimento cercando di uniformarsi o comportarsi allo stesso modo 2a riprodurre in modo uguale o simile: 2b riprodurre, spec. in modo caricaturale, l’aspetto, i gesti e la voce di una persona: Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 88
Dunque l’utilizzo di un eye‐tracker, di un head‐tracker, o di un qualsiasi altro dispositivo di puntamento alternativo porta con sé l’idea di emulare, simulare, imitare o anche riprodurre un qualcosa in maniera simile rispetto all’originale. Nel caso in cui l’interazione tra utente e sistema mediante questi dispositivi fosse avvenuta in maniera tale da rispecchiare fedelmente quella classica (mediante mouse e tastiera) la progettazione di un nuovo client sarebbe stata a quel punto superflua. Il fatto però che il processo di emulazione permetta un’interazione soltanto “simile” a quella originale richiede che tutte le problematiche portate alla luce dal differente modo con cui l’utente utilizza il sistema vengano opportunamente studiate ed analizzate, e che vengano messi a punto tutta una serie di accorgimenti finalizzati a limare quanto più possibile il gap attualmente esistente tra l’interazione “classica” e l’interazione “alternativa”. Dimostrata a questo punto la necessità di procedere nella realizzazione di un’estensione che amplii le funzionalità di Mozilla Firefox permettendo la navigazione sul web mediante dispositivi come head ed eye tracker, è necessario comprendere quali realmente siano gli aspetti da limare, quali siano cioè le situazioni in cui l’utente avverte concretamente il “gap”, la minore precisione dovuta all’utilizzo di un dispositivo di input differente da quello classico. A grandi linee, queste situazioni possono essere classificate in tre macro‐
categorie: •
Difficoltà di utilizzo del dispositivo di puntamento •
Difficoltà nell’utilizzo dell’interfaccia dell’applicazione •
Difficoltà nella navigazione sul Web Una fase più o meno ampia di “training”, in cui l’utente inizia a familiarizzare con il dispositivo (per esempio comprendendo in che modo il movimento della testa si Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 89
trasforma in spostamento del puntatore) può essere utile per eliminare completamente le difficoltà di primo tipo, e a ridurre sensibilmente le altre due. Anche un utente con particolare dimestichezza con un head‐tracker, però, potrebbe avere difficoltà ad interagire con l’interfaccia o a navigare su particolari pagine Web caratterizzate da una struttura complessa con link particolarmente ravvicinati tra di loro, ad esempio. E’ in questa direzione che devono essere focalizzati gli accorgimenti messi a punto dall’estensione di Mozilla Firefox. Tutti questi dispositivi, infatti, sebbene caratterizzati da una curva di apprendimento non troppo ripida, sono affetti da una minore precisione di puntamento che, sebbene direttamente proporzionale alla dimestichezza dell’utente col dispositivo, con estrema difficoltà potrà raggiungere la precisione del puntamento effettuato con gli arti superiori ed un normale mouse. Una normale fase di training e una riprogettazione dell’interfaccia dell’applicazione, però, non sono sufficienti, poiché l’utente può percepire delle difficoltà anche durante la navigazione vera e propria. In generale difficoltà di questo tipo possono essere ulteriormente classificate in due categorie: •
Difficoltà nel puntare con precisione un singolo collegamento ipertestuale •
Difficoltà nel compilare le form presenti sul Web In entrambe queste situazioni, il compito principale che si richiede al browser (nel caso specifico, all’estensione di Firefox) è quello di “sapere” cosa c’è in quel particolare punto su cui l’utente sta guardando per potersi comportare di conseguenza operando gli opportuni accorgimenti. Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 90
(figura 25 – Un Punto dello Schermo: Solo una coppia di valori ?) Ciò che si richiede, in altri termini, è di dare al Web Browser la capacità di “localizzare” tutto ciò che è presente nella pagina, di “superare” cioè la visione classica dello schermo, dove ogni punto del display può essere visto come una semplice coppia di punti (x,y) del piano cartesiano descritto dallo schermo del computer, andando ad indicizzare tutte le componenti (sia che si tratti di collegamenti ipertestuali, sia di componenti delle form, sia di qualunque altro oggetto che può essere utilizzato all’interno della pagine) associando a ciascuna di queste le coordinate dello schermo dove questo elemento è presente e determinando sulla base di questo il comportamento che assumerà il Web Browser al fine di semplificare quanto più possibile la navigazione mediante dispositivi di puntamento alternativi. 4.2 Uno scenario d’uso Per mostrare la veridicità di tutte le osservazioni illustrate fino a questo punto andremo ad analizzare una situazione concreta facendo riferimento, nel caso specifico, al più semplice tra gli scenari d’uso: La navigazione su www.google.it, il più conosciuto tra i motori di ricerca. Anche in questo caso le operazioni che possono essere effettuate al caricamento della pagina vanno a classificarsi in due categorie: Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 91
•
Navigazione verso altre pagine, cliccando sui collegamenti ipertestuali •
Utilizzo del box di ricerca per inviare una query (figura 26 – Situazione 1: Un solo link nell’intorno della fissazione) Analizziamo per esempio la situazione illustrata in figura 25. Supponiamo che l’utente voglia continuare la navigazione cliccando su “Pubblicità”: Lo spostamento del puntatore dalla posizione iniziale alla posizione del link necessita di un determinato lasso di tempo (sicuramente superiore a quello necessario a spostare il puntatore del mouse con la mano). Il compito dell’algoritmo di localizzazione sarà quello di monitorare progressivamente la posizione del puntatore verificando di volta in volta la presenza di eventuali collegamenti ipertestuali in un intorno prefissato. Nel caso in cui l’utente avrà spostato il puntatore in una posizione sufficientemente vicina al link desiderato e nelle vicinanze di quel punto non sia presente nessun altro collegamento, si intuisce immediatamente che l’intento dell’utente sia proprio quello di cliccare su quel link. Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 92
Anche la situazione contraria, che si verifica in tutte quelle pagine caratterizzate da una struttura complessa e ricca di collegamenti ipertestuali (magari particolarmente ravvicinati l’un l’altro), richiede che l’algoritmo di localizzazione sia progettato in maniera tale da operare opportuni accorgimenti. Nel caso specifico, supponiamo che si verifichi la situazione mostrata in figura 26, con l’utente che desideri cliccare, ad esempio, su “Preferenze”. In questo caso l’algoritmo di localizzazione non sarà capace di discriminare quale tra i tre collegamenti ipertestuali sia quello che l’utente voleva realmente selezionare, poiché in un intorno di un determinato numero di pixel è presente più di un link. (figura 27 – Situazione 2: Tre Link nell’intorno della fissazione) In entrambe queste situazioni l’algoritmo di localizzazione dovrà effettuare un operazione che tecnicamente prende il nome di “magnificazione”, acquisendo l’etichetta e il percorso di ciascun collegamento ipertestuale in modo da rappresentarli nuovamente, opportunamente ingranditi (da cui il termine di magnificazione), in un’area dedicata dello schermo. In entrambe queste situazioni, però, può accadere che l’utente voglia tornare alla pagina iniziale, oppure premere il tasto “back” del browser per muoversi verso la pagina precedente. In un browser classico, con dei dispositivi di puntamento “classici”, Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 93
questa è un’operazione molto semplice, che richiede solo un click sui relativi bottoni presenti nella parte alta dello schermo. (figura 28 – I bottoni della toolbar di Mozilla Firefox) In un browser assistivo l’operazione da compiere, sostanzialmente, non cambia. La dimensione di tutti gli elementi della toolbar non è però tale da permettere all’utente di spostare il puntatore del mouse mediante l’head‐tracker in un tempo ragionevolmente basso. All’algoritmo di localizzazione, dunque, sarà richiesta anche una minima riprogettazione dell’interfaccia in funzione delle ovvie difficoltà di navigazione che la nuova modalità di interazione porta con sé. (figura 29 – Gli Elementi delle Form sono troppo vicini tra di loro) L’ultima situazione da considerare, come detto, riguarda la compilazione della form posta al centro della home page di Google. In generale gli elementi che compongono le form presenti nelle pagine Web sono posti ad una distanza minima l’una dall’altra, risultando dunque di difficile puntamento se navigate con l’ausilio di un head‐tracker o un eye‐tracker. Selezionare una voce da un menu a tendina, cliccare Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 94
su un radio button o su un checkbox, digitare una password o inviare appunto una query per un motore di ricerca, sono tutte operazioni estremamente semplici se effettuate con mouse e tastiera, ma che divengono quasi impossibili se l’utente che deve compierle è un individuo diversamente abile. L’ultima funzionalità che si richiede all’algoritmo di localizzazione, dunque, sarà quella di implementare un particolare modulo che semplifichi quanto più possibile il processo di gestione e compilazione delle form, implementando magari anche un prototipo di tastiera visualizzato sullo schermo (simile a quello presente sui palmari), per permettere l’utilizzo dei motori di ricerca anche a quei soggetti disabili impossibilitati all’utilizzo degli arti superiori. 4.3 Descrizione della strategia risolutiva Lo scenario d’uso appena descritto ha illustrato specificatamente tutte le situazioni in cui Mozilla Firefox dovrà operare opportuni accorgimenti al fine di garantire la possibilità di navigare sul Web utilizzando dispositivi di puntamento alternativi. Prima di realizzare concretamente l’estensione, però, sarà necessaria un operazione di “traduzione” di tutte queste osservazioni in un linguaggio di programmazione o di scripting che realizzi tutte le funzionalità richieste, sfruttando anche l’ausilio di altre tecnologie nate proprio con l’obiettivo di sviluppare applicazioni basate sulla piattaforma Mozilla, come XUL, RDF, XPI e DOM. Nel caso specifico, il “cuore” dell’estensione sarà scritto in Javascript, il linguaggio utilizzato per codificare buona parte del browser e su cui si basano quasi tutte le estensioni attualmente disponibili per Mozilla Firefox. Tutte le problematiche che coinvolgeranno più o meno direttamente l’interfaccia del browser saranno invece a carico di XUL, acronimo di Extensible User Interface Language, un meta‐linguaggio basato su XML utilizzato per costruire lo scheletro delle applicazioni Mozilla. La Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 95
pacchettizzazione dell’estensione si appoggerà ad un particolare formato (detto XPI, acronimo di Cross Platform Installer) compatibile con il gestore delle estensioni integrato nel browser, ed il processo di installazione si articolerà sulla base delle “direttive” descritte in alcuni file RDF inclusi nell’archivio rilasciato. Un ruolo fondamentale per la realizzazione delle funzionalità richieste, infine, sarà svolto da DOM, acronimo di Document Object Model. DOM fornisce una rappresentazione gerarchica ad albero di tutte le componenti inserite all’interno delle pagine Web, facilitando in maniera notevole il processo di indicizzazione e la successiva localizzazione di tutti gli elementi presenti nel documento. L’algoritmo di localizzazione dovrà dunque svolgere i seguenti compiti: •
Indicizzare e localizzare tutte le componenti presenti nella pagina (collegamenti ipertestuali ed elementi delle form), assegnando a ciascuna di esse le proprie coordinate (descritte da una coppia di valori). •
Calcolare la distanza tra ciascuna componente e la fissazione dell’utente appena intercettata, considerando solo gli elementi aventi una distanza minore di un determinato numero di pixel. •
Mostrare, in un’area dedicata dello schermo, solo i collegamenti ipertestuali magnificati oppure invocare il modulo di gestione delle form. In tutti e tre i passi sarà Javascript ad occuparsi delle problematiche relative all’indicizzazione, la localizzazione, l’ordinamento e la presentazione magnificata degli elementi, opportunamente integrato con dei costrutti DOM (nel primo passo) e XUL (nel terzo passo). Passiamo adesso ad analizzare nello specifico il modo in cui si articolano i tre passi della realizzazione, illustrando anche tutti gli strumenti di supporto nello sviluppo dell’estensione. Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 96
4.3.1 Indicizzazione delle componenti della pagina Il primo passo dell’algoritmo di localizzazione consiste nell’indicizzazione di tutte le componenti presenti in una generica pagina web, di tutto ciò con cui, in altri termini, l’utente può interagire all’atto del caricamento della pagina. Apparentemente una pagina web potrebbe apparire come un banale insieme di collegamenti ipertestuali, organizzati in maniera più o meno ordinata, più o meno coerente con la struttura della pagina, più o meno integrata con il layout del documento. In realtà in Mozilla Firefox tutte le componenti di una pagina sono indicizzate e descritte gerarchicamente mediante uno standard W3C per la rappresentazione dei documenti sulla Rete: DOM, acronimo di Document Object Model [2], che si occupa specificatamente di acquisire tutto il contenuto di un documento e di restituire una rappresentazione strutturata dello stesso. Il concetto chiave, in DOM [3], è quello di oggetto: Una tabella presente all’interno di una pagina web è un oggetto, una pagina web è un oggetto, la finestra del browser che racchiude ogni pagina web è anch’essa un oggetto. Ciascuno di questi oggetti è caratterizzato a sua volta da determinate caratteristiche (detti attributi) , può compiere delle azioni (dette metodi), e può assumere dei comportamenti nel caso in cui si verifichino determinate situazioni (dette eventi). Sebbene DOM supporti tutte le caratteristiche fondamentali dei linguaggi di programmazione object‐oriented, però, esso non è un vero e proprio linguaggio di programmazione. Si tratta semplicemente di una API per i documenti XML e XHTML che permette al programmatore di accedere alla rappresentazione della pagina, modificandone eventualmente la struttura, lo stile e il contenuto con l’ausilio di alcuni script. Ciascun oggetto presente all’interno della pagina implementa una particolare interfaccia, che determina quali saranno i propri attributi, i metodi che può invocare, gli eventi cui sarà sensibile, e tutte le eventuali relazioni di ereditarietà. Le interfacce fondamentali sono sostanzialmente tre: Window, Document ed Element. La prima fa Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 97
riferimento all’intera finestra del browser, la seconda descrive l’intero documento, e la terza, infine, i singoli elementi all’interno della pagina. Nell’ottica dell’algoritmo di localizzazione il compito dell’estensione sarà dunque quello di acquisire l’intero albero della pagina e di visitarlo livello per livello, individuando di volta in volta tutti i collegamenti ipertestuali e gli elementi delle form, sfruttando gli attributi utili a ricavare la posizione degli stessi nell’ambito del piano cartesiano descritto dallo schermo del PC. Uno degli strumenti più utili per interagire con DOM e i principali metodi delle sue interfacce è il DOM Analyzer, una estensione ufficiale della fondazione Mozilla inserita nel pacchetto di installazione di Mozilla Firefox. Il compito dell’analizzatore DOM è esattamente quello di descrivere graficamente la rappresentazione strutturata della pagina, come mostrato in figura 29. Nella parte bassa viene caricata la pagina richiesta, mentre nella parte alta l’analizzatore mostra a sinistra la caratterizzazione gerarchica del documento e nella parte destra tutti gli attributi dell’elemento e i relativi valori associati a ciascuno di essi. (figura 30 – l’Analizzatore DOM di Mozilla Firefox) Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 98
Attraverso l’analizzatore DOM è possibile acquisire una pagina Web e visualizzarne graficamente la struttura, con l’obiettivo di ricavare eventuali metodi e attributi utili per implementare tutte le caratteristiche richieste dall’algoritmo di localizzazione. Nel caso specifico, come si può evincere dalla documentazione inserita sul sito web ufficiale di Mozilla, il primo sottoproblema (l’indicizzazione dei collegamenti ipertestuali) è immediatamente risolvibile proprio attraverso una delle proprietà predefinite dell’interfaccia Document [4]. Come si può notare dalla figura 30, infatti, tra le proprietà di questa interfaccia vi è links, una struttura dati lineare (si tratta semplicemente di un vettore) che contiene tutte le informazioni relative ai collegamenti ipertestuali presenti nel documento acquisito, a partire dall’etichetta del link fino ad arrivare al percorso, passando per tutta una serie di valori utili al fine di ricavare la localizzazione del collegamento ipertestuale all’interno della pagina. (figura 31 – Il Vettore dei collegamenti ipertestuali implementato dall’interfaccia Document) Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 99
Sotto un punto di vista prettamente algoritmico, dunque, il processo di indicizzazione dei collegamenti ipertestuali sarà realizzato con un banale ciclo scandito n‐1 volte, dove n è il valore dell’attributo length del vettore links. Ad ogni passo l’algoritmo acquisirà tutte le informazioni sull’ i‐esimo collegamento ipertestuale (con i progressivamente incrementato da 0 sino ad n‐1) passando di volta in volta ad indicizzare l’elemento successivo. I collegamenti ipertestuali non sono però l’unica tipologia di elemento con cui l’utente del browser può interagire all’atto della navigazione. Tutti gli scenari più comuni, a partire da una procedura di registrazione, passando per la ricerca di informazioni sui motori di ricerca, fino ad arrivare ai pagamenti online prevedono in ogni caso l’interazione con almeno una form: attraverso la compilazione di una textarea, la scelta esclusiva di alcuni radiobutton, il click su una checkbox, l’inserimento di una password o di qualsivoglia informazioni sensibili. Anche solo la pressione di un bottone di invio. Poiché è immediato rendersi conto di come la navigazione sulla rete non possa prescindere da una completa fruizione delle funzionalità offerte dalle form, sarà necessario far seguire il processo di indicizzazione dei collegamenti ipertestuali da un procedimento simile, orientato però stavolta ad individuare tutte le componenti delle form presenti all’interno della pagina. Anche in questo caso l’analizzatore DOM risulta quanto mai utile per individuare i metodi e gli attributi più indicati per ricavare tutte le informazioni necessarie a partire dalla pagina acquisita. Così come per i collegamenti ipertestuali, infatti, è l’interfaccia document a venirci incontro con una delle sue proprietà: forms. Come si può evincere da figura 31 (e come mostrato nella DOM Reference di Mozilla.org [5]), l’attributo forms è definito sempre come una struttura dati lineare al cui interno sono indicizzate però tutte le form presenti all’interno della pagina Web. Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 100
(figura 32 – Una sola Form su www.google.it ) Nell’ottica dell’algoritmo di Localizzazione, però, più che l’indicizzazione delle intere form, risulta più interessante l’idea di poter localizzare, a partire da una form, tutte le singole componenti (textfield, textarea, password, radiobutton, checkbox submit botton) al fine di definire poi il comportamento del modulo di gestione delle form (di cui si parlerà specificatamente nei paragrafi successivi) in funzione della differente tipologia di componente su cui l’utente ha fissato lo sguardo. Gli attributi DOM si dimostrano di grande aiuto anche in questa situazione: ciascuna Form presente all’interno della pagina ha tra i suoi attributi ancora un vettore (elements) che contiene l’elenco di tutte le componenti che fanno riferimento proprio a quella form. (figura 33 – Il Vettore degli Elementi della Form) L’algoritmo di localizzazione vero e proprio, dunque, dovrà far seguire il ciclo di indicizzazione dei collegamenti ipertestuali da un nuovo ciclo, solo leggermente più complesso, che in questo caso scandisce prima tutte le form presenti nella pagina e poi, all’interno di ciascuna form, tutti gli elementi che la compongono. Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 101
Così facendo tutte le componenti presenti all’interno della pagina Web sono correttamente indicizzate ed è possibile il passaggio alla fase successiva: la localizzazione. 4.3.2 Localizzazione delle componenti e calcolo della distanza Il processo di indicizzazione può essere immaginato alla stregua di una procedura di pre‐processing, di una procedura che anticipa l’algoritmo vero e proprio, “preparandone” la strada. L’obiettivo dell’algoritmo di localizzazione, infatti, non è quello di “indicizzare” tutto ciò che noi vediamo sullo schermo al caricamento della pagina, ma quello di “localizzare” tutte queste componenti, di associare cioè a ciascuna di esse la precisa posizione in cui la stessa può essere individuata sullo schermo. In alcune situazioni particolari (una su tutte, il click utente) DOM permette di ricavare in maniera diretta, mediante particolari metodi, il punto dello schermo in cui quell’evento si è verificato. Viceversa per le generiche componenti che popolano le pagine web tutto ciò non è vero: non esiste infatti alcun metodo o alcuna proprietà che permetta di ricavare a partire da un elemento la coppia di valori che ne descrive la localizzazione. Almeno in maniera diretta. La procedura di localizzazione, infatti, si articola in maniera leggermente più complessa, e si basa su alcune proprietà che caratterizzano l’interfaccia DOM element. Come detto, tutti gli oggetti presenti all’interno della pagina, a partire dalle immagini fino ai singoli link cliccabili, implementano questa interfaccia e ne ereditano i metodi e le proprietà. Tra queste, esistono quattro attributi interessanti, offsetWidth, offsetHeight, offsetTop e offsetLeft, che rappresentano degli ottimi punti di partenza per implementare la procedura di localizzazione. Come mostrato sulla DOM Reference [6] si tratta di quattro attributi che restituiscono rispettivamente l’ampiezza e l’altezza dell’oggetto considerato, e la Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 102
distanza (l’offset, appunto) che intercorre tra l’oggetto corrente e il nodo padre di questo oggetto. Inizialmente infatti è stato detto che il DOM che descrive la pagina è costituito attraverso una struttura dati non lineare, un albero, una struttura cioè composto da un insieme di nodi (gli elementi della pagina Web) tra i quali intercorrono delle relazioni di parentela (padre, figlio, fratello) dette archi. (figura 34 – I valori degli attributi offset per il link “Immagini” di Google.it ) Prima di comprendere però in che modo, a partire da questi dati, sia possibile articolare la procedura di localizzazione è necessario fare un passo indietro. L’idea di localizzare le componenti sullo schermo è collegato all’idea di “misurare” la loro posizione , che a sua volta porta con sé la necessità di definire un’unità di misura e un sistema di riferimento da adottare per effettuare queste misurazioni. Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 103
Nel caso specifico, andremo ad utilizzare il sistema di riferimento più semplice possibile: il piano cartesiano, adottando il pixel come unità di misura sulla scala di valori descritta dallo stesso. In generale il concetto di pixel [7] vede la propria principale applicazione nel campo della grafica, dove viene utilizzato per descrivere (attraverso una coppia di valori, es. 1024*768) la risoluzione del display o di una generica immagine. Il piano cartesiano, invece, è da considerare nella sua accezione classica, come l’incrocio perpendicolare di due rette, delle quali una, quella orizzontale, rappresenta un asse detto asse X, e l’altra, quella verticale, rappresenta l’asse Y. L’incrocio delle due rette assume un valore convenzionalmente fissato in (0,0) ed ogni punto del piano assume un particolare valore in funzione della distanza che intercorre tra l’origine degli assi e il punto considerato. Partendo da queste definizioni ed operando alcuni piccoli accorgimenti si ottiene un particolare piano che cercherà di riprodurre quanto possibile l’oggetto che intendiamo rappresentare attraverso il sistema di riferimento: il monitor del computer. Innanzitutto esso, a differenza del piano cartesiano, non ha estensione infinita, anzi, gli angoli del monitor vanno a racchiudere solo una piccola parte di piano che per convenzione viene descritta attraverso una coppia di valori. Dire che un display ha risoluzione 1024x768 significa dire che il display può contenere 1024 pixel in larghezza (parleremo di asse X) e 768 pixel in altezza (parleremo di asse Y). Per adottare un sistema di riferimento che descriva un’area di piano analoga a quella descritta dal display del computer sarà innanzitutto necessario “limitare” il piano cartesiano classico, eliminando tutti i valori negativi (perché banalmente il pixel non può assumere valore negativo) e tutti quelli maggiori di 1024 (o rispettivamente di 768) dall’insieme di valori che possono essere assunti in fase di misurazione. Come mostrato in figura 34, dunque, il sistema di riferimento che andremo ad adottare non sarà nient’altro che un piano cartesiano limitato al primo quadrante e capovolto (capovolto perché l’origine degli assi per convenzione viene fissata con Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 104
l’estremo superiore sinistro piuttosto che con l’estremo inferiore sinistro), che descrive alla perfezione l’area di piano descritta dal display del monitor (vedi figura 35). (figura 35 – Un piano cartesiano classico, con i valori delle ascisse limitati a 1024 e quelli delle ordinate a limitati a 768 ) L’immagina successiva descrive nuovamente il problema della localizzazione di un punto dello schermo in funzione della rappresentazione adottata per descrivere il problema: (figura 36 – Qual è la localizzazione del punto? ) Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 105
A questo punto possiamo tornare a trattare gli attributi di offset cui si è fatto riferimento in precedenza, cercando di comprendere in che modo a partire da questi valori sia possibile ricavare la localizzazione delle componenti nella pagine Web. Il sistema di riferimento appena definito ci permette innanzitutto di affermare che l’unità di misura adottata per assegnare i valori agli attributi è il pixel, dunque il link “immagini” presente nella home page di Google.it ha un’altezza di 16 pixel (offsetHeight) , una larghezza di 52 pixel (offsetWidth), ed è distanziato dal nodo genitore di 4 pixel in alto e di 49 a sinistra. I primi due valori descrivono la dimensione sul piano del collegamento ipertestuale, mentre il terzo e il quarto permettono di ricavare la localizzazione precisa del collegamento ipertestuale mediante un sistema di somme successive, il cui meccanismo è illustrato nella figura successiva: (figura 37 – Processo di Localizzazione di un Link ) Il rettangolo rappresentato con il numero 1 rappresenta il collegamento ipertestuale “immagini” della Home Page di Google. Come mostrato dai valori delle proprietà di offset, si tratta di un rettangolo grande 16x52 pixel, distanziato di 4 pixel verso l’alto e di 49 verso sinistra dal proprio nodo padre, vale a dire il rettangolo più grande che nell’immagine è identificato col numero 2. In questo caso le proprietà ci dicono che si tratta di un rettangolo di 24x331 pixel, stavolta distanziato di 132 pixel verso l’alto e di 337 pixel verso il lato sinistro dal nodo genitore, il rettangolo identificato dal numero 3 che descrive tutta la pagina (localizzato in posizione (0,0)). Google.it è un sito caratterizzato da una struttura estremamente lineare, per cui anche il processo di localizzazione delle componenti si articola in maniera Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 106
discretamente rapida (in questo caso sono previsti solo due cicli) ed immediata. A partire dai valori ricavati, dunque, è possibile localizzare il link: X = offsetLeft1 + offsetLeft2 = 49 + 337 = 386 Y = offsetTop1 + offsetTop2 = 4 + 132 = 136 Il link “Immagini” presente sulla home page di Google, può essere dunque localizzato nella posizione (386,136) all’interno del piano cartesiano ideale descritto dallo schermo del PC. Intuitivamente, però, un collegamento ipertestuale non è un’entità puntiforme ma, anzi, caratterizzata da una struttura piana di tipo rettangolare. Questo procedimento permette di ricavare nello specifico solo la localizzazione dell’estremo inferiore sinistro del rettangolo descritto dal link. Per ricavare la localizzazione degli altri 3 punti è sufficiente operare delle semplici addizioni e sottrazioni, come mostrato nella figura successiva, dove 16 e 52 sono i valori delle proprietà offsetHeight ed offsetWidth, relativi cioè all’altezza e all’ampiezza del rettangolo considerato. (figura 38 – Ecco localizzati i quattro punti del collegamento ipertestuale) Attraverso un procedimento analogo, esteso ovviamente a tutte le componenti indicizzate nella fase precedente, sarà possibile calcolare la corretta localizzazione di tutti gli elementi che popolano la pagina web. Al termine di questa procedura Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 107
l’algoritmo avrà completato la fase di “mappatura” del documento, e restituirà un elenco di tutti gli oggetti della pagina con le relative coordinate dove gli stessi possono essere localizzati. Il compito dell’algoritmo però non termina qui: nel momento in cui l’utente effettuerà una fissazione oltre a comprendere “dove” egli sta guardando (inteso come coppia di valori che descrive la coordinata della fissazione) sarà fondamentale anche sapere “cosa” in quel momento sta guardando. Come illustrato nello scenario d’uso descritto nel paragrafo precedente, infatti, il comportamento dell’algoritmo di localizzazione sarà funzionale alla caratterizzazione strutturale della pagina, esso dovrà infatti assumere un comportamento differente a seconda che l’utente stia fissando una form oppure una porzione di schermo caratterizzata dalla presenza contemporanea di più link. A questo proposito, l’algoritmo fa seguire la procedura di localizzazione con un ciclo di scansione di tutti gli elementi appena mappati, al fine di individuare tutte le componenti potenzialmente di interesse per l’utente. Il criterio attraverso cui è valutato “l’interesse” di ciascuna componente è quello più oggettivo possibile: la distanza. Quanto più un collegamento ipertestuale è vicino alla fissazione dell’utente, tanto è più probabile che l’utente avesse intenzione di cliccare proprio su quel collegamento o nell’intorno di quella porzione di schermo. La formula adottata per calcolare la distanza è proprio quella largamente utilizzata nella geometria analitica: il calcolo della distanza tra due punti. Formalmente, fissato nello spazio un sistema di assi cartesiani ortogonali e fissati due punti A(x1,y1) e B(x2,y2) (rispettivamente indicanti la fissazione e il collegamento ipertestuale), la distanza tra essi è indicata con d(A,B) , ed è calcolata come: d ( A, B) = ( x2 − x1 ) 2 + ( y 2 − y1 ) 2
Terminato anche questo processo, la prima fase dell’algoritmo di localizzazione si conclude con l’ordinamento dell’insieme di tutte le coppie <componente, distanza> che Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 108
permette di individuare tutti gli elementi contenuti all’interno di un intorno di un determinato numero di pixel, al fine di determinare, in base alla tipologia ed al numero degli stessi, il comportamento e la caratterizzazione che il browser assumerà nel proseguo della navigazione. 4.3.3 Gestione dei collegamenti ipertestuali La prima fase dell’algoritmo di localizzazione, come detto, si conclude idealmente con l’individuazione di tutte le componenti della pagina presenti nella vicinanze di un intorno prefissato rispetto alla fissazione dell’utente. Come anticipato in apertura di capitolo le componenti con cui l’utente può interagire possono essere classificate in due categorie: i collegamenti ipertestuali e gli elementi delle form Dalla descrizione dello scenario d’uso mostrato nel paragrafo 4.2 si è potuto evincere come la fissazione dell’utente durante la navigazione potesse determinare tre differenti tipologie di interazione in funzione del numero di collegamenti ipertestuali presenti nelle vicinanze del punto guardato. Nel caso specifico: •
Nessun collegamento ipertestuale nell’intorno •
Un collegamento ipertestuale nell’intorno •
Più di un collegamento ipertestuale nell’intorno Banalmente la prima situazione può verificarsi, per esempio, durante la lettura di un quotidiano online o di un articolo preso dalla Rete. Trattandosi di documenti prettamente testuali e generalmente privi di collegamenti è naturale che l’utente vada a fissare lo sguardo in punti dove non è presente nulla con cui interagire, ragion per cui non è necessario che il browser operi in alcun modo prendendo particolari accorgimenti in situazioni di questo tipo. Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 109
La seconda situazione, viceversa, ripropone lo scenario precedentemente mostrato in figura 25. Si suppone cioè che l’utente vada a spostare il puntatore nei pressi di una porzione di schermo dove è presente un unico collegamento ipertestuale. Schematizziamo la situazione, supponendo che il valore dell’intorno sia stato fissato in 50 pixel: Collegamento Ipertestuale Distanza Pubblicità 26,7296 Soluzioni Aziendali 82,1353 Tutto su Google 246,9821 (tabella 2: Calcolo della distanza su Google.it – Primo scenario) La terza situazione, infine, ripropone a grandi linee lo scenario mostrato in figura 26. Supponiamo che il processo di localizzazione e il successivo calcolo della distanza restituisca i seguenti risultati: Collegamento Ipertestuale Distanza Preferenze 6,3921 Ricerca Avanzata 9,4551 Strumenti per le Lingue 14,8914 (tabella 3: Calcolo della distanza su Google.it – Secondo scenario) Su quale dei tre collegamenti ipertestuali l’utente voleva in realtà cliccare? La difficoltà di puntamento insita nell’utilizzo degli head‐tracker e degli eye‐tracker non permette all’utente di puntare i singoli collegamenti ipertestuali in maniera così precisa da evitare situazioni di ambiguità in pagine caratterizzate dall’utilizzo di caratteri piccoli e link troppo ravvicinati tra di loro. In entrambi i casi il compito dell’algoritmo sarà quello di rappresentare in forma più grande e in un’area dedicata dello schermo tutti i collegamenti ipertestuali Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 110
presenti nell’intorno, compiendo un’operazione che in gergo prende il nome di “magnificazione”. Nel caso specifico, l’interfaccia del browser sarà parzialmente modificata attraverso la costruzione di alcuni bottoni ad‐hoc posti nella parte bassa dello schermo (precisamente nella status bar), cliccando sui quali la navigazione proseguirà proprio verso la pagina a cui il link originario faceva riferimento. In figura 38 è mostrato un esempio di magnificazione: (figura 39 – Magnificazione dei quattro link individuati nell’intorno) Mentre in figura 39 è mostrata una visione d’insieme della nuova interfaccia di Mozilla Firefox opportunamente adattata: (figura 40 – La nuova interfaccia di Mozilla Firefox con i bottoni magnificati nella parte inferiore) Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 111
Entrambe le situazioni, dunque, portano con sé la necessità di una riprogettazione, seppure minima, dell’interfaccia del browser in funzione delle differenti modalità con cui l’utente interagisce con il sistema. Nel caso specifico, infatti, egli non si limiterà a cliccare su un collegamento ipertestuale, ma effettuerà prima una fissazione quanto più vicina possibile al link desiderato, cliccando successivamente sul bottone magnificato costruito nella parte bassa dello schermo. Sebbene esistano un gran numero di linguaggi orientati alla costruzione delle interfacce, quando si trattano problematiche di questo tipo facendo riferimento a Mozilla Firefox come client, o in senso lato, a Gecko come piattaforma, il linguaggio adottato per la costruzione delle GUI è XUL. XUL (che si pronuncia “zuul”) è l’acronimo di XML User Interface Language [8], ed è un linguaggio nato specificatamente per la progettazione di interfacce. Tutti i client sviluppati dalla Mozilla Foundation infatti, compresi ovviamente Mozilla Firefox e Mozilla Thunderbird, adottano proprio XUL per la realizzazione delle proprie GUI. Più che di un linguaggio di programmazione vero e proprio, però, è più corretto parlare di XUL come di un linguaggio di marcamento. Esso, infatti, è un dialetto di XML, e da XML eredita sintassi e stile di programmazione [9]. Un’interfaccia in XUL è costituita da un semplice file di testo con estensione .xul all’interno del quale è contenuta una successione di tag opportunamente innestati che descrivono la struttura dell’interfaccia da costruire. Uno dei punti di forza di XUL è dato dalla possibilità di implementare, in maniera relativamente semplice, interfacce anche complesse caratterizzate da un gran numero di oggetti. La sintassi base del linguaggio, infatti, permette di inserire una grande varietà di elementi, detti widgets [10], come ad esempio: •
Finestre •
Bottoni •
Label Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 112
•
Toolbar, MenuBar, ProgressBar •
Checkbox, Radiobutton, List, Box Tornando all’implementazione dell’algoritmo, l’opportunità di arricchire l’interfaccia utente attraverso l’inserimento di nuovi bottoni risulta particolarmente utile in virtù di tutte le problematiche portate alla luce dall’ultimo scenario presentato. L’inserimento di un singolo bottone all’interno dell’interfaccia [11] avviene mediante il tag <button></button>, a cui sono associati poi una serie di attributi necessari a definire aspetto e comportamento dell’elemento appena creato. Ne citiamo solo i più importanti: •
label, che descrive l’etichetta del bottone •
hidden, posto a true se il bottone deve rimanere nascosto, viceversa è settato a false •
oncommand, che descrive il comportamento del bottone al click dell’utente •
id, che assegna un identificativo univoco a ciascun elemento dell’interfaccia L’algoritmo di localizzazione, concretamente, popolerà ciascuna delle label costruite nella parte bassa dell’interfaccia mostrata in figura 39 con l’etichetta del collegamento ipertestuale individuato nell’intorno, associando poi all’attributo oncommand l’indirizzo referenziato dal collegamento ipertestuale, al fine di definire la pagina dove continuare la navigazione al click dell’utente. Dando uno sguardo all’immagine presentata in figura 39, però, rimane da trattare il problema del posizionamento di tutti i bottoni appena creati. Ciascun elemento che compone l’interfaccia di Mozilla Firefox, come detto, è scritto in XUL. Ciò che non è stato detto, invece, è che ciascuno di questi elementi è referenziabile in maniera diretta attraverso un identificatore univoco. Nel nostro caso l’id della barra di stato presente nella parte inferiore del browser è proprio status‐bar e tutti i bottoni appena creati possono essere istanziati come “figli” di questo elemento, sfruttando la Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 113
sintassi innestata propria di XUL e di tutti i linguaggi di marcamento, e realizzando la caratteristica richiesta nel modo desiderato. A questo punto tutti gli accorgimenti necessari a garantire la navigazione tra i collegamenti ipertestuali attraverso dispositivi di puntamento alternativi risultano essere implementati mediante l’utilizzo di un linguaggio, XUL, estremamente intuitivo, semplice da utilizzare, potente, portabile, e soprattutto totalmente integrato con l’ambiente Gecko e con il browser Mozilla Firefox. La versatilità di questo linguaggio e la sua capacità di adattarsi alle situazioni più disparate si può inoltre apprezzare anche dalla sua effettiva utilità nella risoluzione di tutte le problematiche legate con l’ultimo aspetto da considerare: la compilazione delle form. 4.3.4 Gestione delle form Come detto in precedenza, la navigazione sul Web e la totale fruizione di tutte le informazioni che la Rete mette a disposizione non può assolutamente prescindere dall’utilizzo delle Form. Le oggettive difficoltà di interazione insite nell’utilizzo di un dispositivo di puntamento alternativo, però, precludono all’utente l’utilizzo di una grandissima varietà di siti, a partire dai motori di ricerca fino ad arrivare alle banche online, nei quali è previsto che l’utente interagisca, compilandolo, con almeno un oggetto di questo tipo. In conseguenza di ciò risulta essere assolutamente necessaria la progettazione di un modulo separato che si occupi specificatamente di gestire tutte le problematiche portate alla luce dalle difficoltà di interazione con le form, facilitando operazioni come il puntamento, il click sui bottoni, e la compilazione vera e propria dei campi testuali. L’eterogeneità degli elementi che possono essere incontrati durante il processo di compilazione di una form è un fattore che aumenta la complessità realizzativa del Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 114
modulo di gestione. Esso, infatti, sarà caratterizzato da una struttura più articolata rispetto al modulo di gestione dei collegamenti ipertestuali poiché oltre alle consuete operazioni di indicizzazione e di localizzazione di tutte le componenti presenti all’interno della pagina dovrà anche assumere un comportamento differente in funzione della differente tipologia di elemento con cui l’utente interagisce all’atto della compilazione. Queste componenti, in generale, possono essere classificate in sette categorie: •
TextBox •
TextArea •
Campi Password •
Radio Button •
Checkbox •
ComboBox •
Bottoni Le prime tre categorie condividono la medesima struttura e il medesimo comportamento: si tratta infatti di componenti di tipo testuale con cui l’utente può interagire attraverso un click e l’inserimento di informazioni testuali attraverso la tastiera. Allo stesso modo la quarta e la quinta categoria descrivono due tipologie di elementi caratterizzate da un comportamento analogo. Per semplicità, dunque, la classificazione può essere riorganizzata in questo modo: •
Elementi Testuali •
Bottoni •
Menu a Tendina •
Bottoni Submit Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 115
Per poter analizzare al meglio tutti gli accorgimenti da prendere è opportuno anche in questo caso andare a considerare la possibilità di studiare uno scenario d’uso concreto al fine di portare alla luce tutte le problematiche che il processo di compilazione delle form porta con sé. Il sito analizzato, stavolta, è www.it.altavista.com, in virtù della caratterizzazione particolarmente complessa e articolata delle form che lo compongono. (figura 41 – Il motore di ricerca per le immagini di Altavista) L’immagine presentata in figura 40 illustra la caratterizzazione della home page del motore di ricerca per le immagini di Altavista. Esso, come si può notare, permette di interagire con tutte e 4 le macro‐categorie di componenti definite in precedenza. E’ possibile infatti individuare una textbox (1), un bottone submit (2), tre bottoni checkbox (3) e tre menu di selezione (4). La compilazione di questa form attraverso mouse e tastiera risulta essere quanto mai semplice ed intuitiva: è sufficiente un click per selezionare l’area di testo dove inserire la query, massimo tre click per selezionare o deselezionare ciascun checkbox, pochi secondi per selezionare le voci desiderate dal menu a tendina, e infine un click sul bottone di submit per visualizzare i risultati per la ricerca. Queste semplici operazioni però, se riportate in uno scenario dove lo strumento utilizzato per interagire è un eye‐tracker o un head‐tracker, rivelano l’assoluta Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 116
complessità del processo di compilazione delle form con dispositivi differenti da quelli classici. La fissazione su ciascuna checkbox o la pressione sul bottone submit, per esempio, richiede una precisione di puntamento che probabilmente va oltre le potenzialità dei dispositivi di puntamento alternativo, anche se utilizzati da un utente ben allenato e con una grossa dimestichezza. Allo stesso modo il processo di selezione dai menu a tendina richiede un lasso di tempo non ragionevole e molto più ampio rispetto a quello necessario a selezionare la voce richiesta attraverso il mouse. E, ultimo ma non meno importante, il problema della compilazione vera e propria: come fare a inserire la query nella textbox se l’individuo diversamente abile non può utilizzare le mani ? Le risposte a tutti questi interrogativi trovano soluzione nella progettazione di un intero modulo che si occupi specificatamente di risolvere tutte le problematiche che il processo di compilazione delle form porta alla luce. In questa situazione, infatti, l’utilizzo di un dispositivo di puntamento alternativo implica necessariamente che lo stesso processo di interazione sia organizzato in maniera alternativa, implementando, nello specifico, una serie di accorgimenti orientati a garantire la fruibilità delle form anche in uno scenario di interazione differente da quello convenzionale. Così come avvenuto per il modulo di gestione dei collegamenti ipertestuali, anche in questo caso il concetto fondamentale è quello di magnificazione. Se prima, però, ad essere magnificati erano proprio i link con le relative etichette e i percorsi che essi stessi referenziavano, stavolta la parte inferiore dello schermo conterrà le etichette delle singole componenti delle form e implementerà dei metodi necessari ad emularne il comportamento. Alla fissazione utente l’algoritmo di localizzazione individuerà tutte le componenti della pagina presenti all’interno dell’intorno predefinito, e, se tra queste è presente almeno una componente di una form, visualizzerà nella barra di stato il seguente bottone, magnificato: Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 117
(figura 42 – Bottone che invoca il Modulo di Gestione delle Form) E un click su questo bottone invocherà il modulo di gestione delle form. L’idea di base attorno a cui il modulo è costruito è quella di scandire tutti gli elementi che compongono la form (sfruttando il vettore elements citato nel paragrafo 4.3.1), assumendo un differente comportamento e costruendo determinati bottoni sulla statusbar in funzione della differente tipologia di elemento incontrato. Nel caso specifico, consideriamo sempre la form presente su Altavista, e supponiamo che si invochi il modulo di gestione. Questo, a sua volta, inizierà a scandire il vettore elements, che individuerà come prima componente la textbox presentata in figura 40. In questa situazione nella parte inferiore dello schermo verrà magnificato un bottone di Selezione della Textarea (mostrato in figura 42), e un click su questo bottone simulerà il focus sul campo testo così come avviene cliccando con il mouse sul campo stesso e attiverà la visualizzazione della tastiera a scomparsa che permetterà di compilare concretamente il campo testuale semplicemente fermandosi per il lasso di tempo necessario alla fissazione il carattere che si desidera digitare. I bottoni “Indietro” e “Avanti” permettono di scandire gli elementi della Form passando rispettivamente all’elemento precedente e successivo. (figura 43 – Modulo di Gestione delle Form – tastiera a scomparsa per compilare le aree testuali) Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 118
Cliccando su Avanti il controllo passerà all’elemento successivo della form. Nel nostro caso (si può fare riferimento sempre alla figura 40), si tratta di un bottone Submit. La caratterizzazione del modulo di gestione, come si può notare dalla figura 43, rimane invariata. Sono sempre presenti i bottoni di scansione e i bottoni di selezione (inattivi, per ora) , mentre per il bottone centrale sono cambiate sia l’etichetta che il comportamento, che ora simula la pressione del bottone submit e l’invio della query. (figura 44 – Modulo di Gestione delle Form – selezione textarea) Premendo ancora il tasto avanti l’algoritmo continuerà a scandire tutti gli element, individuando adesso tre bottoni di tipo checkbox. In questo caso il modulo di gestione adatterà il bottone centrale presente sulla statusbar modificandone ancora una volta etichetta e comportamento (in questo caso simulerà il click sul bottone, selezionando o deselezionando la casella). (figura 45 – Modulo di Gestione delle Form – selezione checkbox) I bottoni “Opzione Precedente” e “Opzione Successiva”, rimasti fino ad ora inattivi, vengono attivati nel caso in cui durante la scansione venga individuato un menu a tendina. (figura 46 – Modulo di Gestione delle Form – menu di selezione) Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 119
Attraverso il click su questi due bottoni sarà possibile scorrere tutte le possibili opzioni del menu. Nel momento in cui verrà individuata l’opzione desiderata sarà sufficiente un click sul bottone centrale per simulare il click diretto sulla voce del menu a tendina. (figura 47 – Modulo di Gestione delle Form – selezione di un opzione) Lo scenario d’uso appena presentato descrive il processo di compilazione delle form in un ottica totalmente nuova e differente da quella convenzionale. Nell’interazione con mouse e tastiera, infatti, è l’utente a doversi muovere tra i vari elementi della form selezionando e deselezionando ciò che desidera. Viceversa, con questi accorgimenti, sarà sufficiente fissare solo un elemento della form, invocare il modulo di gestione, cliccare via via sui vari bottoni che compaiono nella parte inferiore dello schermo e disinteressarsi di ciò che avviene nella parte alta del display poiché saranno i click sui bottoni magnificati a determinare le scelte dell’utente e l’invio stesso della query. Sotto un punto di vista spiccatamente implementativo, tutte le caratteristiche presentate sono realizzate sempre in XUL. Così come per il modulo di gestione dei collegamenti ipertestuali, anche in questo caso i bottoni creati con il tag <button> verranno posizionati nella barra di stato del browser. Etichetta e comportamento dei bottoni, stavolta, saranno definiti staticamente (viceversa nel modulo di gestione dei link variavano in funzione del collegamento individuato) e conterranno un differente metodo da invocare sulla base della differente tipologia di elemento che descrivono: Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 120
•
Per gli elementi testuali, sarà invocato il metodo focus() •
Per checkbox, radiobutton, option e submit sarà invocato il metodo click() •
Per i bottoni di scansione e di selezione opzione verrà incrementato (o decrementato) un contatore di stato. Se da un lato può apparire limitativo ritenere esaurite le tipologie di situazioni che l’utente può incontrare durante il processo di compilazione di una form soltanto attraverso l’analisi di un singolo scenario d’uso, dall’altro lato un’analisi più attenta della caratterizzazione dei siti web dove è prevista l’interazione con almeno un oggetto di questo tipo permette di concludere che tutte le problematiche riscontrabili vanno sempre a riallacciarsi con le macro‐categorie appena illustrate. Progettare un modulo di gestione che si occupi di realizzare accorgimenti per semplificare il processo di compilazione delle form sulla base di queste quattro tipologie di problematiche, dunque, sarà un modulo di gestione che, in conseguenza di ciò, sarà in grado di rendere fruibile una grandissima varietà di siti web: quelli che prevedono moduli di registrazione, motori di ricerca, siti di scommesse online, e tutti i portali che prevedono procedure di login; tutti siti di primaria importanza per l’utente medio che si affaccia sul mondo della Rete, tutti siti di fondamentale importanza per l’utente diversamente abile che sfrutta la rete per affacciarsi sul mondo, tutti siti che, senza l’ausilio di un algoritmo di questo tipo, rimarrebbero preclusi. 4.4 Pacchettizzazione dell’Estensione Terminata la fase di codifica, l’algoritmo appare dunque come un insieme di istruzioni Javascript che acquisiscono il DOM della pagina e, sulla base della sua caratterizzazione, decidono il comportamento da assumere e definiscono la caratterizzazione del browser al fine garantire la possibilità di navigare sulla Rete attraverso dispositivi di puntamento alternativi. L’obiettivo iniziale del lavoro, però, Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 121
era quello di riuscire ad integrare l’algoritmo all’interno di un browser preesistente, estendendone le funzionalità, sulla base di tutte le nuove problematiche che la nuova modalità di interazione portava con sé. Una delle motivazioni fondamentali alla base della scelta di adottare Firefox come client “base” su cui applicare e successivamente testare le caratteristiche dell’algoritmo è dovuta alla possibilità, insita nel client Mozilla, di gestire in maniera incrementale le proprie funzionalità attraverso l’utilizzo delle estensioni. Come anticipato nel capitolo precedente (paragrafo 3.3.4), un’estensione di Mozilla Firefox non è altro che un piccolo programma con estensione .XPI (acronimo di cross‐platform installer) che include una serie di file .JS (Javascript) che descrivono il comportamento dell’estensione, eventuali moduli XPCom e una serie di file RDF che descrivono, attraverso l’ausilio di questo meta‐linguaggio, tutta una serie di informazioni fondamentali per garantire la corretta installazione e il corretto funzionamento dell’estensione stessa (ad esempio, i percorsi a partire dai quali possono essere individuate le immagini e i sorgenti Javascript). La scelta delle tecnologie e dei linguaggi adottati per lo sviluppo dell’algoritmo è stata indubbiamente orientata a garantire la compatibilità di questi con i linguaggi adottati per la creazione di generiche estensioni Firefox. Non è un caso infatti che si sia utilizzato XUL per la riprogettazione dell’interfaccia del browser, DOM per l’acquisizione delle informazioni sulla pagina, e soprattutto Javascript per la codifica vera e propria di tutte le istruzioni. La fase successiva alla realizzazione dell’algoritmo, dunque, consiste in una procedura di pacchettizzazione finalizzata alla creazione di un file XPI, una vera e propria estensione di Mozilla Firefox che garantirà l’integrazione di tutti gli accorgimenti messi a punto con le funzionalità native del browser. Anche in questo caso la documentazione presente sulla Rete, dislocata in parte sulla home page ufficiale di Mozilla Firefox ed in parte su tutti i siti che fanno capo alla community della Mozilla Foundation è quanto mai di aiuto per la risoluzione di quest’ultima problematica. In uno dei volumi principali dedicati allo sviluppo di Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 122
applicazioni con la piattaforma Mozilla [12] si apprende che il concetto‐chiave quando si fa riferimento alle Estensioni Firefox è quello di “bundle”. L’idea di bundle è simile a quella di “pacchetto” presente su Linux, o di “installer” su Windows, ed è da intendersi come una collezione di files e script opportunamente pacchettizzati per essere correttamente installati su applicazioni basate su Mozilla. L’estensione di file di questo tipo, come detto, è XPI, acronimo di Cross Platform Installer. A prima vista si potrebbe pensare ad un formato particolare (come l’ .rpm su Linux o .exe su Windows), pensato e progettato appositamente per implementare e supportare dei particolari meccanismi di installazione di questi pacchetti all’interno della piattaforma. Questo è vero solo in parte: I file XPI, infatti, sono semplicemente dei file compressi “camuffati”. E’ sufficiente ridenominare il file in formato .zip, estrarlo sul proprio disco ed analizzarne il contenuto. E’ proprio il contenuto, però, la differenza sostanziale che intercorre tra un normale file compresso ed un’estensione Firefox. I file contenuti all’interno di un XPI, infatti, seguono una particolare tassonomia specificata all’interno dell’ampia documentazione presente nell’home page di Mozilla [13] , in cui viene illustrata la particolare struttura dei file da inserire all’interno di un’estensione al fine di garantire che la procedura di installazione vada a buon fine. Concretamente, il “file layout” che un’estensione Firefox dovrà seguire è questo: extension.xpi: install.rdf chrome.manifest chrome/extension.jar defaults/extension.something defaults/preferences/extension.js Il nodo radice di questa tassonomia è, ovviamente, l’estensione vera e propria. Il primo file da includere all’interno dell’estensione è install.rdf, un file che contiene dei costrutti RDF che descrivono tutte le informazioni necessarie ad intraprendere la procedura di installazione. A corredo dell’estensione può essere presente un file che contiene le preferenze di default dell’utente, eventuali immagini, e soprattutto un file Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 123
archivio JAR (extension.jar) contenuto all’interno della directory chrome del pacchetto che rappresenta l’estensione vera e propria. Le istruzioni che descrivono comportamento, caratterizzazione e funzionalità che l’estensione includerà saranno comprese proprio in un questo piccolo archivio. Terminata la procedura di pacchettizzazione e prodotto il file XPI da utilizzare per integrare l’estensione in Mozilla Firefox si passa a preparare tutti i file richiesti per l’installazione dell’XPI. Quello più importante ai fini della corretta riuscita della procedura è proprio il file RDF di installazione (install.rdf). Così come XUL , anche RDF è un meta‐linguaggio direttamente derivato da XML. Un file RDF, dunque, non è altro che un insieme di tag opportunamente innestati che descrivono una serie di informazioni. Nel nostro caso, informazioni che descrivono in che modo la procedura di installazione dovrà essere articolata. Specificatamente tutte queste “informazioni” di cui la piattaforma ha bisogno sono espresse sottoforma di valori inseriti all’interno di strutture di marcamento (tag). I più importanti sono: •
<em:id>, che descrive l’ID dell’estensione da installare •
<em:version>, utile ai fini del versioning dell’estensione stessa, supponendo di voler rilasciare periodicamente nuove versioni •
<em:name>, nome dell’estensione •
<em:description>, descrizione dell’estensione •
<em:creator>, informazioni sul creatore •
<em:updateURL>, che permette di rilasciare su Internet nuove versioni ed aggiornare automaticamente l’estensione Accanto al file install.rdf esiste un altro file caratterizzato da una struttura simile: contents.rdf. Questo file, sempre attraverso particolari tag specificherà una serie di informazioni riguardanti il contenuto delle cartelle del pacchetto, come ad esempio il percorso a partire dal quale sarà possibile ritrovare i file sorgenti Javascript necessari Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 124
a garantire il corretto funzionamento di tutte le caratteristiche realizzate nell’estensione. Terminate dunque tutte le fasi di codifica, pacchettizzazione e costruzione di questi file a corredo dell’estensione si passa all’ultima fase, quella del rilascio. Su ogni estensione sviluppata e rilasciata sulla Rete vige la MFL (Mozilla Foundation License) di cui si è parlato precedentemente. Ciò significa che ciascuno di questi programmi XPI può essere scaricato ed installato sul proprio PC senza alcun costo. Ad occuparsi, nello specifico, della procedura di installazione è un vero e proprio sottosistema integrato all’interno della piattaforma Mozilla che prende il nome di XPInstall. Questo sottosistema si occupa di organizzare il processo di installazione seguendo una procedura simile a quella schematizzata nella figura seguente: (figura 48 – La procedura di installazione delle estensioni Firefox) L’ immagine mostra in maniera sufficientemente intuitiva in che modo la procedura di installazione integra in Mozilla Firefox le funzionalità dell’estensione. Il file XPI, nel caso specifico, registra all’interno della piattaforma Mozilla (facendo riferimento proprio all’install.rdf) tutte le componenti necessarie al Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 125
funzionamento dell’estensione all’interno del browser (attraverso file Javascript) permettendo così di fruire, eseguendo l’applicazione, di tutte le nuove caratteristiche implementate nell’estensione. A questo punto, dunque, sarà sufficiente acquisire l’estensione appena pacchettizata sul proprio PC, trascinarla all’interno della finestra di Mozilla Firefox, confermare la richiesta di installazione ed attendere che la procedura termini. Fatto questo, dopo essersi assicurati che l’estensione sia attiva, si può riprendere a navigare così come accaduto fino a qualche minuto prima. Stavolta, però, magari con l’ausilio di un head‐tracker. Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 126
Bibliografia Capitolo 4 [1] De Mauro, Paravia ‐ Dizionario della Lingua Italiana – 2004 ‐ Definizione di “alternativo”, di “simulare” e di “imitare” [2] W3C.org – Document Object Model (DOM) ‐ http://www.w3.org/DOM/ [3] Mozilla.org – Introduction to DOM – What is DOM ? http://www.mozilla.org/docs/dom/domref/dom_intro.html [4] Mozilla.org – Gecko DOM Reference – Document Interface – Link Property http://www.mozilla.org/docs/dom/domref/dom_doc_ref25.html#1025098 [5] Mozilla.org – Gecko DOM Reference – Document Interface – Forms Property http://www.mozilla.org/docs/dom/domref/dom_doc_ref19.html#1024912 [6] Mozilla.org – Gecko DOM Reference – Element Interface http://www.mozilla.org/docs/dom/domref/dom_el_ref.html#1023967 [7] Wikipedia.org – Pixel ‐ http://it.wikipedia.org/wiki/Pixel [8] Mozilla.org – XML User Interface Language ‐
http://www.mozilla.org/projects/xul/ [9] N.McFarlane ‐ Rapid Application Development with Mozilla, Prentice Hall, 2003 – cap.2 , XUL Layout [10] D.Boswell, B.King, I.Oeschger, P.Collins, E.Murphy – Creating Applications with Mozilla – O’Reilly, 2002 – cap.3, XUL Elements and Layout Capitolo 4 – Implementazione di un Algoritmo di Localizzazione 127
[11] XULPlanet.com – XUL Tutorial – Chapter 2.2: Adding Buttons http://xulplanet.com/tutorials/xultu/buttons.html [12] N.McFarlane ‐ Rapid Application Development with Mozilla, Prentice Hall, 2003 – cap.17, Deployment [13] Mozilla.org – Packaging Thunderbird/Firefox Extension http://www.mozilla.org/projects/firefox/extensions/packaging/extensions.html Capitolo 5 – Sperimentazione 128
Capitolo 5 Sperimentazione 5.1 Introduzione Idealmente il rilascio del sistema conclude quella fase che nel ciclo di sviluppo del software è convenzionalmente indicata col termine di ʺrealizzazioneʺ. Lo stesso modello a cascata proprio dell’Ingegneria del Software [1] , però, prevede che tra la fase di realizzazione ed il successivo rilascio finale sia prevista una batteria più o meno ampia di test finalizzata a verificare la rispondenza del sistema a tutti i requisiti previsti, sia sotto un punto di vista prettamente strutturale che sotto un punto di vista spiccatamente pratico, analizzando cioè che tutte le possibili funzionalità sviluppate siano effettivamente fruibili dallʹutente finale del prodotto. Parallelamente alla nascita e alla successiva diffusione della disciplina della Human‐Computer Interaction, il classico modello a cascata si è progressivamente evoluto [2] nellʹambito di un modello progettuale che enfatizzasse lʹimportanza della figura dellʹutente durante il processo di realizzazione del software. LʹISO 13407, infatti, descrive la caratterizzazione di un processo di sviluppo ʺuser centeredʺ, incentrato cioè tutto sullʹutente, sulle sue necessità, sui suoi requisiti, sui suoi bisogni. Un altro dei principali capisaldi dell’Interazione Uomo Macchina, accanto alla presenza ed al costante coinvolgimento dell’utente in tutte le fasi che caratterizzano il ciclo di sviluppo del sistema, è dato dall’estrema importanza che viene riposta in quella fase che nel modello a cascata prende il nome di valutazione. Il concetto di valutazione è legato all’idea di poter esprimere un giudizio concreto su un determinato artefatto (un sito web, un’interfaccia, persino un’applicazione vera e propria) sulla base di determinati parametri e di determinate considerazioni ritenute universalmente Capitolo 5 – Sperimentazione 129
corrette. In letteratura sono state presentate tantissime metodologie di valutazione dell’usabilità [3] di un sistema, alcune delle quali effettuate direttamente da esperti, altre che utilizzano degli schemi più o meno prefissati di regole da seguire (dette euristiche) , altre ancora che coinvolgono in maniera diretta l’utente (in laboratorio o sul campo) attraverso un approccio interattivo con il sistema sviluppato. In generale non esistono delle regole precise ed inappellabili che guidano in maniera immediata il processo di progettazione del software verso la strada dell’usabilità, tanto più se il target di utenti che una determinata applicazione si prefigge di avere fa riferimento ad individui diversamente abili, ad individui cioè che utilizzano gli strumenti tecnologici mediante tecniche di interazione differenti da quelle “convenzionali”. In conseguenza di ciò ci si potrebbe immediatamente chiedere in che modo, dunque, andare a strutturare il processo di sperimentazione in virtù delle considerazioni appena poste: l’unica strada percorribile che permette di conciliare la necessità di valutare l’impatto di un determinato software all’interno di un bacino di utenza, mettendo da parte almeno parzialmente la metodicità di un processo di valutazione gestito e organizzato da esperti di usabilità è quello di sottoporre un campione di utenti sufficientemente ampio ad una procedura che nell’ambito dell’Interazione Uomo‐Macchina prende il nome di Esperimento Controllato [4]. Le modalità con cui questa metodologia di valutazione si esplicita sono immaginabili: Fissato un gruppo di utenti e un insieme di compiti da effettuare, si osserva ciascuno degli utenti effettuare sul sistema i task previsti, acquisendo contemporaneamente delle informazioni (es. delle misurazioni sul tempo necessario a compiere un’operazione) che a conclusione della Sperimentazione saranno oggetto di analisi e valutazione. Al termine della procedura, poi, sarà somministrato all’utente un questionario anonimo attraverso cui esprimere opinioni soggettive riguardo vantaggi e svantaggi conseguenti l’utilizzo del sistema, oltre ovviamente all’utilità o alla bontà dell’applicativo in senso lato. Capitolo 5 – Sperimentazione 130
5.2 Preparazione 5.2.1 Descrizione della popolazione Il criterio attraverso cui selezionare il campione di utenti scelto per partecipare alla Sperimentazione è già un parametro di fondamentale importanza nell’ottica di una buona riuscita della stessa procedura di valutazione. E’ innanzitutto necessario che il gruppo di utenti rispecchi in maniera sufficientemente fedele la caratterizzazione della popolazione che in futuro utilizzerà realmente l’applicativo: Valutare la bontà delle funzionalità offerte dal sistema testandole ad esempio su utenti con maggiore dimestichezza con le tecnologie, oppure costruire un campione di utenti non coerente con il reale target dell’applicazione porterebbe infatti a risultati ovviamente inutili nell’ottica di un processo di sperimentazione finalizzato a valutare vantaggi e svantaggi conseguenti all’utilizzo dell’applicativo stesso. Secondo parametro da prendere attentamente in considerazione è dato dalla numerosità del campione: ovviamente è banale immaginare come la veridicità dei risultati ottenuti sia direttamente proporzionale alla quantità di individui selezionati per partecipare alla sperimentazione. Con un campione estremamente ampio, infatti, il peso specifico di misurazioni effettuate su individui particolarmente smaliziati o, viceversa, totalmente a digiuno di tecnologie di questo tipo viene ovviamente ridotto permettendo alla media di assestarsi sul proprio valore reale a prescindere da eventuali “sbalzi” dovuti a situazioni di questo tipo. Allo stesso modo, però, è altrettanto immediato intuire come il tempo necessario a portare a termine la sperimentazione sia direttamente proporzionale alla cardinalità del campione, per cui un campione troppo numeroso necessiterà ovviamente di un lasso di tempo particolarmente ampio per essere totalmente esaurito. In virtù di queste considerazioni, dunque, si è cercato di fissare un compromesso tra il tempo necessario a portare a termine l’esperimento controllato e il numero di individui coinvolti nello stesso, ed è stato fissato questo valore in 30 unità. E’ importante sottolineare come gli individui siano stati scelti in maniera Capitolo 5 – Sperimentazione 131
assolutamente eterogenea, senza particolari distinzioni di sesso, età, provenienza e dimestichezza con gli strumenti informatici, immaginando che altrettanto eterogenea potrà essere in futuro la tipologia di individui che fruirà del browser. Originariamente si era immaginato di organizzare la Sperimentazione su un campione composto totalmente da individui diversamente abili, ma ovvie difficoltà organizzative hanno immediatamente suggerito di intraprendere una strada differente. 5.2.2 Descrizione dell’ambiente di lavoro Uno dei requisiti fondamentali degli Esperimenti Controllati è dato dalla necessità di organizzare la procedura di valutazione in maniera tale da riprodurre un ambiente quanto più simile possibile a quello reale al fine di minimizzare il margine di errore delle misurazioni ed eliminare disturbi esterni di vario tipo che possano “sporcare” i dati acquisiti e invalidare tutte le analisi cui i dati stessi saranno successivamente sottoposti. Fortunatamente, però, la scenario da trattare (la navigazione su Internet) è facilmente riproducibile attraverso l’utilizzo di un semplice PC dotato di un browser sufficientemente recente che permetta di esaurire in un tempo ragionevole tutti i task previsti senza alcun tipo di ostacolo, ragion per cui l’organizzazione della sessioni di Sperimentazione è stata effettuata senza particolari difficoltà. L’intera procedura di Sperimentazione è stata espletata all’interno dell’Isola Didattica per Disabili del Dipartimento di Informatica dell’Università degli Studi di Bari [5] in una delle postazioni presenti all’interno della struttura. Sul PC utilizzato è stata installata l’estensione che permette la navigazione sul Web attraverso dispositivi di input head‐controlled, insieme ovviamente all’ultima versione del browser Mozilla Firefox (1.0.7 , ndr). Il dispositivo di input utilizzato per la Sperimentazione è stato TrackerOne [6], un dispositivo di head‐pointing che permette di controllare il movimento del mouse Capitolo 5 – Sperimentazione 132
sul display attraverso il semplice movimento del capo, indipendentemente dalla disabilità dell’utente. (figura 49 – Il TrackerOne®, prodotto da Madentec Technologies) Esso si compone di due parti, una trasmittente/ricevente di segnale Infrarosso che viene posizionata sul monitor del computer, e un piccolo adesivo riflettente (ovviamente riutilizzabile) che viene posto sulla fronte o sugli occhiali. Quando la testa viene mossa, i raggi infrarossi riflessi vengono registrati dal TrackerOne e ribaltati in movimenti del cursore sullo schermo. Esso è stato sviluppato per fornire un controllo semplice ed accurato del mouse alle persone affette da disabilità nelle quali la persona non ha un buon controllo delle mani per usare il mouse standard (per esempio, Tetraparesi, paralisi cerebrale, sclerosi multipla, distrofia muscolare, SLA, ecc). (figura 50 – Installazione di TrackerOne® su un PC) Capitolo 5 – Sperimentazione 133
5.2.3 Descrizione dei task L’ultimo passo del processo di preparazione riguarda la definizione della caratterizzazione dei task che dovranno essere effettuati dagli utenti e che, a partire dalle misurazioni effettuate, saranno oggetto di analisi e valutazione. L’obiettivo della nostra Sperimentazione, come detto, è stato quello di studiare l’impatto di un software di nuova concezione all’interno di un gruppo di utenti sufficientemente ampio valutando la semplicità con cui ciascuno di essi riesce a portare a termine compiti di vario tipo accompagnando tutto ciò anche con riscontri prettamente numerici a partire dai quali quantificare il gap tuttora esistente tra le tecniche di interazione classiche e la navigazione sul Web attraverso dispositivi di puntamento alternativi. In generale tutti i task sono stati selezionati sulla base di un principio di generalità: senza porre vincoli particolari di alcun tipo, infatti, sono stati scelti dei compiti comuni ed assolutamente generali, dei task con cui quotidianamente l’utente medio della Rete si trova ad interagire, con l’obiettivo primo, innanzitutto, di valutare la soddisfacibilità delle operazioni più comuni attraverso dispositivi di puntamento di questo tipo, ma anche al fine di poter tratte delle precise indicazioni sulla bontà e sulle future potenzialità di questa nuova modalità di interazione. Punto di partenza per la definizione dei task è stato il sito web ufficiale del Premio WWW [7], un’iniziativa de “Il Sole 24 Ore” (patrocinata tra l’altro dal Ministero per l’Innovazione e le Tecnologie) che da vari anni premia i siti web italiani più importanti sulla base del bacino di utenza e della notorietà del sito stesso. Il nostro compito è stato quello di fissare delle categorie di interesse individuando in ciascuna di esse due‐tre siti campione a partire dai quali costruire i task da espletare in fase di Sperimentazione. Di seguito è presentato l’elenco delle categorie di interesse e dei relativi siti Web selezionati per la Sperimentazione: Capitolo 5 – Sperimentazione •
•
•
•
•
•
•
Portali o
Google.it (www.google.it) o
Yahoo! Italia (www.yahoo.it) o
MSN Italia (www.msn.it) o
Altavista Italia (www.altavista.it) Mail o
Yahoo Mail (mail.yahoo.it) o
Hotmail (www.hotmail.com) o
Mail2Web.com (www.mail2web.com) Tecnologia o
Punto Informatico (www.punto‐informatico.it) o
Html.it (www.html.it) News o
La Repubblica (www.repubblica.it) o
Corriere della Sera (www.corriere.it) o
La Gazzetta dello Sport (www.gazzetta.it) o
Disabili.com (www.disabili.com) o
Ansa.it (www.ansa.it) o
Inter.it (www.inter.it) Commercio o
eBay.it (www.ebay.it) o
Internet Book Shop (www.ibs.it) o
Chl.it (www.chl.it) Istituzioni o
Poste.it (www.poste.it) o
Trenitalia.com (www.trenitalia.com) o
Inps.it (www.inps.it) Finanza o
Ing Direct (www.ingdirect.it) o
BancoPosta (http://bancopostaonline.poste.it) 134
Capitolo 5 – Sperimentazione •
•
135
Viaggi e Turismo o
Turistipercaso.it (www.turistipercaso.it) o
Zingarate.com (www.zingarate.com) o
Trenitalia.com (www.trenitalia.com) Istruzione o
Studenti.it (www.studenti.it) o
Wikipedia.org (http://it.wikipedia.org) o
Ministero della Pubblica Istr. (http://www.istruzione.it) o
Università degli Studi di Bari (www.uniba.it) Nella tabella successiva, invece, sono descritti i task definiti per ciascuno dei siti Web selezionati. Categoria: Portali Google.it Fare click su “ricerca avanzata”, inserire la keyword “informatica”, selezionare il primo link ottenuto. Yahoo.it Fare click su immagini, scrivere la parola chiave “cane”, fare click sul primo link dopo uno scroll down. MSN Italia Ricercare i ristoranti in Puglia utilizzando le parole di ricerca ristoranti puglia e scegliere il terzo link proposto tra i risultati. Altavista Impostare la ricerca per immagini e ricercare le immagini delle cascate del Niagara con la parola chiave niagara. Categoria: Mail Yahoo! Mail Accedere alla registrazione tramite il pulsante Registrati e riempire i campi richiesti nella pagina di registrazione senza Capitolo 5 – Sperimentazione 136
dare la conferma finale sul pulsante Accetto. Nell’area di accesso alla posta selezionare Richiedere sempre Hotmail.it l’indirizzo di posta elettronica e la password e accedere alla casella di posta con indirizzo di posta elettronica ([email protected]) e password (serlab). Mail2Web.com Accedere alla casella ti posta [email protected] con password “a” Categoria: Tecnologia Accedere al Forum Hardware e aprire la terza delle discussioni Punto Informatico presentate nell’elenco. Una volta aperta, tornare alla pagina precedente. Html.it fare click su “programmazione”, poi su “programmazione orientata agli oggetti”, accedere al cap. 9. Categoria: News Repubblica.it Cliccare sull’ultima notizia presentata in home page e, una volta apertasi la pagina, tornare alla Home Page Corriere.it Selezionare “Sport” nella sezione “News”. Fare click sulla prima notizia visualizzata. Selezionare Calcio dall’elenco degli sport. Tramite il pannello Gazzetta.it Cerca il calciatore cercare il calciatore Buffon inserendo la parola chiave buffon . Cliccare sul calciatore presentato tra i risultati della ricerca. Disabili.com Selezionare dal menu la voce Tempo libero, successivamente Eventi. Dalla pagina Eventi accedere alla sezione Concerti. Ansa.it Effettuare uno scroll, selezionare Internet e cliccare su una News dopo aver effettuato ancora uno Scroll Capitolo 5 – Sperimentazione Inter.it 137
Scegliere la Versione Italiana del Sito, Cliccare su Squadre e visualizzare la Scheda di un Calciatore Categoria: Commercio eBay.it Individuare una Sezione a Scelta e offrire per il primo oggetto in Scadenza della Lista (non effettuare il Login) Effettuare uno scroll fino al fondo della Pagine, selezionare la IBS.it Classifica dei Libri più venduti di IBS e mettere il secondo libro nel Carrello CHL.it Selezionare dal menu la sezione Informatica. Visualizzare i portatili in vendita di marca Acer. Categoria: Istituzioni Dalla sezione riservata ai privati cercare informazioni su Poste.it Conto e Carte. Informarsi sulle Condizioni Economiche e poi tornare alla Home page del sito Cercare un treno da Bari a Firenze per il giorno 3 Dicembre Trenitalia.com 2005 a partire dalle ore 06,00. Visualizzare le proposte per tempo di percorrenza. INPS.it Selezionare la sezione “La Pensione”, poi “Invalidità”, cliccare sul link.”L’assegno ordinario di invalidità” Categoria: Finanza ING Direct Accedere alle informazioni relative a Conto Arancio. Informarsi su come funziona e su come fare ad aprirlo. Conto BancoPosta Una volta entrati nel sito informarsi su come attivare il Capitolo 5 – Sperimentazione 138
servizio,sugli orari e i costi e sulla sicurezza utilizzando le opportune voci del menu Categoria: Viaggi e Turismo Selezionare nella parte destra della Pagina lʹitinerario Turistipercaso.it Tanzania, e nella pagina successiva, dopo uno scroll, cliccare sulla terza puntata Ricercare un volo da Bari a Milano e cliccare su PRENOTA, Zingarate.it scegliendo la prima opzione tra tutte quelle che sono disponibili Selezionare Area Clienti, e poi, dopo aver ciccato su FAQ Trenitalia.com nella parte sinistra, effettuare uno scroll down e scegliere Trasporto Bici Categoria: Istruzione Cercare gli appunti riguardanti l’Analisi Matematica con le Studenti.it parole chiave analisi matematica e scegliere il decimo tra i risultati proposti. Selezionare informatica dalla sezione Tecnologia e Scienze Wikipedia.org Applicate. Selezionare il quinto degli eventi informatici recenti elencati. Ministero Pubblica Accedere alla sezione Università, poi Normativa, cliccare Istruzione sulla prima norma che compare. Università degli Studi Cliccare su “Didattica”, scegliere “Facoltà di Scienze MM. FF. di Bari NN.”, cliccare sui “Corsi di studio 2005/2006 (Tabella 4: Tabulazione dei task prevista dalla procedura di sperimentazione) Capitolo 5 – Sperimentazione 139
5.3 Esecuzione L’intera procedura di sperimentazione è stata espletata nell’arco di una settimana, dividendo il campione selezionato per la valutazione in gruppi più piccoli, ciascuno dei quali ha testato il sistema singolarmente. Ogni utente ha utilizzato l’applicativo per un lasso di tempo pari a circa trenta minuti, necessario per esaurire i sei task da compiere previsti dalla procedura di valutazione. Ciascuna delle trenta sessioni, infine, è stata anticipata e seguita dalla compilazione di un questionario anonimo. La somministrazione di questionari è una pratica assolutamente comune e diffusa nell’ambito delle metodologie di valutazione [8] dell’usabilità poiché permette con costi sufficientemente contenuti di acquisire una grande quantità di dati strutturati che permettono delle immediate riflessioni e considerazioni sulla bontà del sistema e dell’impatto sugli individui selezionati. Il primo questionario, di carattere introduttivo, è servito ad acquisire delle informazioni preliminari sulla popolazione di individui che si è sottoposta alla procedura di valutazione. Nello specifico si è cercato di inquadrare la dimestichezza dell’utente con gli strumenti informatici in generale, con il Web e i suoi servizi, con i dispositivi di puntamento alternativi e con il browser Mozilla Firefox. Nella seconda parte del primo questionario l’utente ha dovuto rispondere a quesiti riguardanti le aspettative riposte in un applicativo di questo tipo e le opinioni riguardanti l’effettiva utilità per i disabili di un sistema così strutturato. Il secondo questionario, invece, è stato somministrato al termine della sessione di Sperimentazione con l’ovvio obiettivo di verificare in che proporzione le aspettative riposte dall’utente fossero state effettivamente mantenute dopo il contatto diretto e il reale utilizzo dell’applicativo. Si è inoltre cercato di comprendere il gradimento e l’impatto sugli utenti dell’interazione mediante dispositivi di head‐tracking, acquisendo anche le opinioni riguardo la probabilità di effettiva diffusione di questa 140
Capitolo 5 – Sperimentazione tecnologia in una prossimo futuro. Negli ultimi due quesiti del questionario, infine, è stato chiesta all’utente una preferenza riguardo le componenti del browser da migliorare nei prototipi successivi e infine sulle funzionalità da aggiungere con maggiore priorità, così da tenere anche in considerazione le opinioni degli utenti nella pianificazione delle strategie di sviluppo futuro dell’applicativo. In questa pagina e in quelle successive sono allegati dei fac‐simile dei due questionari somministrati dagli sperimentatori. (figura 51 – Fac‐Simile del Questionario A, prima facciata) Capitolo 5 – Sperimentazione 141
(figura 52 – Fac‐Simile del Questionario A, seconda facciata) Capitolo 5 – Sperimentazione 142
(figura 53 – Fac‐Simile del Questionario B, prima facciata) Capitolo 5 – Sperimentazione 143
(figura 54 – Fac‐Simile del Questionario B, seconda facciata) 5.3.1 Acquisizione dei dati Terminata la compilazione dei questionari è stata data agli utenti la possibilità di provare liberamente il sistema per qualche minuto, con l’obiettivo primario di iniziare a conoscere le funzionalità e le caratteristiche dell’applicativo prendendo contemporaneamente dimestichezza con il nuovo dispositivo di puntamento. Successivamente, terminata questa brevissima fase di training, a ciascuno degli sperimentatori sono stati assegnati sei task da portare a termine selezionati dall’insieme iniziale dei trenta task. Capitolo 5 – Sperimentazione 144
Il numero di task fissato per ciascun utente non è casuale, anzi, si tratta di un valore strettamente correlato con gli obiettivi della sessione di sperimentazione. Come detto precedentemente, infatti, questa procedura di valutazione si prepone di valutare la semplicità con cui ciascuno degli utenti riesce a portare a termine determinati compiti, arricchendo le informazioni con dati di tipo prettamente numerico che permettano di quantificare il gap tuttora esistente tra le tecniche di interazione cui siamo abituati e la navigazione sul Web attraverso un dispositivo di input head‐
controlled. Nel caso specifico gli utenti hanno testato tre differenti modalità di interazione: •
Mouse e tastiera •
Head Tracker senza l’ausilio del browser assistivo •
Head Tracker con l’ausilio del browser assistivo E’ immediato rendersi conto di come i dati acquisiti dai task effettuati tramite mouse e tastiera rappresentino dei valori non raggiungibili dal prototipo attualmente sviluppato. Sarebbe più corretto immaginare questi dati alla stregua di un limite inferiore, di un valore ideale al di sotto del quale, con gli strumenti di input alternativi attualmente disponibili, non è possibile spingersi. Reale obiettivo della sperimentazione, viceversa, è stato quello di studiare tutti i riscontri acquisiti dalle altre due modalità di interazione, valutando se e in che modo l’utilizzo del browser assistivo influenza il tempo necessario a portare a termine tutte le comuni operazioni di navigazione, partendo dalla compilazione delle Form fino ad arrivare alla semplice navigazione sul Web. Nell’immagine successiva è mostrato un fac‐simile del modulo di registrazione utilizzato durante la procedura di sperimentazione. Come si può notare sono presenti tre caselle da spuntare relative alla modalità d’interazione adottata per il singolo task e una casella per indicare il sito Web di riferimento. Le ultime due colonne sono servite Capitolo 5 – Sperimentazione 145
infine a registrare il tempo necessario a portare a termine un determinato task, annotando eventuali considerazioni nelle ultime due righe del modulo. (figura 55 – il Modulo di Registrazione dei dati acquisiti) 5.3.2 Riflessioni e considerazioni La prima, immediata, riflessione che può essere fatta riguarda la scelta di non includere neppure un individuo diversamente abile nel campione di utenti selezionato per la procedura di valutazione: A prima vista una scelta di questo tipo potrebbe apparire limitativa, potrebbe sembrare riduttivo aver testato un browser di questo tipo solo su individui normodotati escludendo di fatto dalla sperimentazione il target primario del sistema. Certo, questo è vero, ma a supporto della scelta operata è bene ricordare come i dispositivi di puntamento alternativi siano strumenti originariamente Capitolo 5 – Sperimentazione 146
sviluppati per individui diversamente abili, ma che possono egregiamente adattarsi anche ai normodotati, e, anzi, una sperimentazione in questo senso è risultata essere assolutamente utile anche per valutare l’impatto e le future opportunità di sviluppo di questa nuova modalità di interazione in un contesto (la navigazione su Internet) che giorno dopo giorno si affaccia sempre più nella nostra quotidianità. Per tutte le considerazioni successive, viceversa, il punto di partenza è rappresentato dalla buona quantità di dati che la procedura di sperimentazione ci ha permesso di acquisire. Il sistema è stato testato, come detto, da trenta individui, in buona parte afferenti al Dipartimento di Informatica dell’Università di Bari. Da una prima analisi del campione selezionato salta immediatamente all’occhio l’ottima dimestichezza con il PC, con Internet e con le tecnologie informatiche in senso lato per una fetta particolarmente grande dell’insieme degli utenti (pari a circa il 70%, come si può notare dall’immagine successiva) (figura 56 – Dimestichezza del campione selezionato con gli strumenti informatici) Capitolo 5 – Sperimentazione 147
Particolarmente positivi sono risultati anche i riscontri riguardo l’utilizzo e la diffusione del browser Mozilla Firefox. Quasi la metà degli individui ha dichiarato di avere dimestichezza con questo software, e più del 30% ha affermato di utilizzarlo come proprio browser abituale. (figura 57 – Dimestichezza del campione selezionato con il browser Mozilla Firefox) Se le aspettative riguardo l’impatto e l’effettiva utilità di un applicativo così strutturato sugli individui diversamente abili hanno registrato come prevedibile risposte quasi a senso unico, gli stesso utenti hanno preferito non sbilanciarsi più di tanto, probabilmente in virtù della pochissima dimestichezza con il tracker, riguardo la bontà di questa modalità di interazione e di un applicativo così strutturato. (figura 58 –Opinioni del campione sull’utilità del software per individui diversamente abili) Capitolo 5 – Sperimentazione 148
(figura 59 –Opinioni del campione sull’utilità del software per individui normodotati e sulla futura diffusione della modalità d’interazione head‐controlled) Sebbene la minima, o in alcuni casi persino nulla, dimestichezza con l’head‐
tracker (cfr. figura 60) abbia reso necessaria una piccola fase di training al fine di istruire gli utenti al meccanismo di funzionamento del dispositivo, la sperimentazione vera e propria ha permesso di acquisire dei riscontri numerici assolutamente positivi riguardo la bontà dell’applicativo e a modalità d’interazione in senso lato, soprattutto alla luce del fatto che per la quasi totalità del campione si è trattata della prima esperienza con dispositivo di puntamento di questo tipo. (figura 60 –Dimestichezza del campione con i dispositivi di head‐tracking) Capitolo 5 – Sperimentazione 149
Nell’ immagine successiva sono mostrati i risultati delle misurazioni successive al completamento dei task previsti dalla procedura di sperimentazione. In media sono stati necessari 19 secondi per terminare un task mediante mouse e tastiera e 95 per completarlo con il dispositivo di head‐tracking. Per i task portati a termine con il browser assistivo, invece, è stato registrato un tempo di 73 secondi, con un miglioramento medio delle prestazioni pari al 23%. Confronto Generale
73
Browser
95
Head‐Tracking
19
Mouse+Tastiera
0
Tempi (in sec.)
20
40
60
80
100
Mouse+Tastiera
Head‐Tracking
Browser
19
95
73
(figura 61 –Confronto tra i tempi registrati durante la sessione di sperimentazione) Relativamente ai task che prevedevano semplici compiti di navigazione, si è registrata una diminuzione del 16% del tempo necessario, con un miglioramento medio pari a circa 8 secondi, passando dai 45 secondi necessari con il semplice head‐
tracker ai 37 del browser assistivo Di particolare interesse sono inoltre i tempi registrato su siti come www.istruzione.it o www.repubblica.it dove il miglioramento apprezzato è stato rispettivamente pari al 55% e al 38%, come si può notare dall’immagine successiva. Capitolo 5 – Sperimentazione 150
Confronto ‐ Task Navigazione
37,6
Browser
45
Head‐Tracker
34
36
38
40
42
44
46
Head‐Tracker
Browser
45
37,6
Tempi (in sec.)
(figura 62 – Confronto tra i tempi registrati per i task di semplice navigazione) Confronto ‐ Repubblica.it e Istruzione.it
13
Browser
28
Istruzione.it
31
Head‐Tracker
45
0
10
20
30
40
Repubblica.it
50
Head‐Tracker
Browser
Istruzione.it
31
13
Repubblica.it
45
28
(figura 63 –Confronto tra i tempi registrati su Repubblica.it e Istruzione.it) Relativamente ai task che prevedevano la compilazione di almeno una form (eventualmente unita ad operazioni di navigazione) il beneficio conseguente all’utilizzo del browser è quantificabile in maniera ancora maggiore, con un miglioramento medio di 50 secondi pari a circa il 26% del tempo necessario. Capitolo 5 – Sperimentazione 151
Confronto ‐ Task di Compilazione Form
145
Browser
Browser
Head‐Tracker
194,5
Head‐Tracker
0
50
Tempi (in sec.)
100
150
200
Head‐Tracker
Browser
194,5
145
(figura 64 –Confronto tra tempi registrati per i task di compilazione form) Anche nel caso dei task relativi alla compilazione delle form prendiamo in considerazione due siti dove i riscontri ottenuti sono stati particolarmente positivi: per il task previsto su Yahoo.it sono stati necessari in media 26 secondi in meno, con un risparmio del 39% , mentre su Gazzetta.it il risparmio ha registrato persino il 55%. Confronto ‐ Gazzetta.it e Yahoo.it
55
Browser
81
Gazzetta.it
Yahoo.it
91
Head‐Tracker
181
0
50
100
150
200
Head‐Tracker
Browser
Gazzetta.it
91
55
Yahoo.it
181
81
(figura 65 –Confronto dei tempi registrati su Gazzetta.it e Yahoo.it) 152
Capitolo 5 – Sperimentazione Per completezza, di seguito sono anche allegati i risultati completi dell’intera sessione di sperimentazione. Nella tabella seguente sono stati inseriti il sito web di riferimento con relativo ID, la tipologia di task che l’utente ha effettuato e il tempo medio in secondi necessario (nelle tre modalità d’interazione) a portare a termine l’operazione. Per fare riferimento ai task veri e propri si può fare consultare la tabella 4 inserita a pagina 135. ID Task Sito Web Tipologia Task Mouse e Tastiera Head Tracker Browser 1 Google.it Navigazione 14 99 86 2 Yahoo.it Compilazione Form + Navigazione 16 91 55 3 MSN.it Compilazione Form + Navigazione 14 142 97 4 Altavista.it Compilazione Form 13 79 72 5 Yahoo Mail Compilazione Form 80 659 560 6 Hotmail.it Compilazione Form 13 215 180 7 Mail2Web.com Compilazione Form 21 106 82 8 Punto Informatico Navigazione 18 72 35 9 HTML.it Navigazione 16 38 35 10 Repubblica.it Navigazione 10 45 28 11 Corriere.it Navigazione 14 23 19 12 Gazzetta.it Compilazione Form + Navigazione 19 181 81 13 Disabili.com Navigazione 14 43 43 14 Ansa.it Navigazione 10 32 34 15 Inter.it Navigazione 13 39 31 16 eBay.it Navigazione 22 59 56 17 IBS.it Navigazione 16 59 58 18 CHL..it Navigazione 25 31 50 19 Poste.it Navigazione 24 39 35 20 Trenitalia.com Compilazione Form + Navigazione 22 174 148 21 Inps.it Navigazione 16 61 72 22 INGDirect.it Navigazione 16 32 21 23 ContoBancoPosta Navigazione 12 45 20 24 TuristiperCaso.it Navigazione 8 44 23 25 Zingarate.com Compilazione Form + Navigazione 44 103 85 26 Trenitalia.com Navigazione 21 53 34 27 Studenti.it Compilazione Form + Navigazione 12 195 90 28 Wikipedia.org Navigazione 10 28 39 29 Istruzione.it Navigazione 7 31 13 30 Uniba.it Navigazione 11 23 20 (tabella 5 – Tabulazione dei dati acquisiti durante la sessione di Sperimentazione) 153
Capitolo 5 – Sperimentazione Bibliografia Capitolo 5 [1] ISO 12207 and Related Software Life‐Cycle Standards ‐ http://www.acm.org/tsc/lifecycle.html [2] ISO 13407 – Human Centered Design Processes for Interactive Systems http://www.usabilitynet.org/tools/13407stds.htm [3] D.Ziggiotto – Usabilità del WWW: Metodi di Valutazione – Capitolo 3 – La Valutazione dell’Usabilità http://www.hyperlabs.net/ergonomia/ziggiotto/index.html [3] D.Ziggiotto – Usabilità del WWW: Metodi di Valutazione – Capitolo 3 – Esperimenti Controllati http://www.hyperlabs.net/ergonomia/ziggiotto/capitolo3/15.html [5] Università degli Studi di Bari – Dipartimento di Informatica – Sito Web Ufficiale – Isola Didattica per Disabili ‐ http://www.di.uniba.it/dib/ita/isolaDidatticaDisabili.htm [6] Madentec Technologies TrackerOne® ‐ Sito Web Ufficiale ‐ Ufficiale ‐ http://www.madentec.com [7] Il Sole 24 Ore – Premio WWW – Sito Web http://premiowww.ilsole24ore.com/ [8] D.Ziggiotto – Usabilità del WWW: Metodi di Valutazione – Capitolo 3 – Metodi Empirici: Questionari http://www.hyperlabs.net/ergonomia/ziggiotto/capitolo3/12.html Capitolo 6 – Sviluppi futuri e conclusioni 154
Capitolo 6 Sviluppi futuri e conclusioni Dall’analisi dei riscontri numerici illustrati nel capitolo precedente emerge immediatamente come l’impatto del browser sugli utenti sia stato assolutamente confortante. A conferma di questa affermazione sono significative le risposte fornite nel questionario somministrato dopo la sessione di sperimentazione, registrate e schematizzate nel grafico mostrato nell’immagine seguente: Mantenute le Aspettative per i Normodotati ?
In Minima Parte
3%
Abbastanza
Del Tutto
70%
7%
Quasi Totalmente
20%
(figura 66 – Impatto del browser sul campione) Per il 70% degli utenti, come si può notare, il sistema ha soddisfatto sufficientemente le aspettative. Se a questa cifra, già di per sé ragguardevole, aggiungiamo anche il 27% degli utenti che ritengono il browser anche qualcosa in più di un semplice prototipo da migliorare, emerge immediatamente come per ben 29 utenti su 30 (pari al 97% del campione) l’impatto con il sistema sia stato assolutamente positivo. Capitolo 6 – Sviluppi futuri e conclusioni 155
Altrettanto significative sono anche le risposte fornite riguardo l’utilità di un browser di questo tipo per individui diversamente abili. In questo caso più della metà degli utenti, pari al 53%, ha affermato come, anche nella caratterizzazione attuale, il sistema sia uno strumento imprescindibile per tutti i disabili che vogliono accedere alla Rete. Mantenute le Aspettative per i Disabili ?
Del Tutto
17%
Abbastanza
30%
Quasi
Totalmente
53%
(figura 67 – Previsioni dell’impatto del browser su individui diversamente abili) Ritenere però esaurito il processo di evoluzione del sistema alla luce di questi primi confortanti risultati sarebbe assolutamente errato. Il browser, nella sua caratterizzazione attuale, è solo in uno stato prototipale e necessita di un gran numero di modifiche e miglioramenti per poter essere ritenuto completo e fruibile (soprattutto da individui normodotati) come seria alternativa alla classica modalità d’interazione mediante mouse e tastiera. Per poter indirizzare al meglio e in maniera univoca il processo di sviluppo del browser, le ultime due domande del questionario post‐sperimentazione sono state finalizzate ad acquisire le opinioni degli utenti sulle componenti da implementare con maggiore priorità e su quelle già presenti ma da migliorare. Capitolo 6 – Sviluppi futuri e conclusioni 156
Componenti da Migliorare
Sensibilità
Localizzazione
Componente XUL
Modulo di Gestione Form
Tastiera
0
5
10
15
20
25
Numero Preferenze (su 30)
(figura 68 – Preferenze del campione sulle componenti del browser da migliorare) Dall’analisi del grafico mostrato in figura 66, emerge come l’idea condivisa da circa il 70% degli utenti sia quella di velocizzare e semplificare il processo di compilazione delle form. Non è un caso infatti che oltre venti individui su trenta abbiano richiesto di migliorare la tastiera integrata nel browser e più di dieci un’ottimizzazione del modulo di gestione. Era prevedibile che gli individui percepissero delle difficoltà più o meno marcate nel processo di compilazione delle form. Si tratta di un dato previsto, quasi certo, che tralaltro emerge anche in maniera netta esaminando i tabulati dei task presentati nel capitolo precedente. Sicuramente esso è in parte dovuto alla pochissima dimestichezza del campione con il dispositivo di puntamento, ma non bisogna anche dimenticare l’ovvia difficoltà di adattare un ambiente (il Web) ideato appositamente per essere fruito attraverso mouse e tastiera ad una nuova modalità (quella gestita tramite head‐tracker) che invece richiede che gli stessi canoni d’interazione vengano riprogettati alla luce della differente modalità con cui l’individuo si relaziona alla macchina. Capitolo 6 – Sviluppi futuri e conclusioni 157
Sebbene siano stati valutati dalla maggior parte degli utenti sufficientemente efficienti, anche l’algoritmo di localizzazione e la componente XUL del browser richiedono alcuni piccoli ritocchi: nel caso specifico, è auspicabile una rivisitazione generale dell’interfaccia del browser unita allo spostamento della barra di magnificazione (attualmente posta nella parte bassa) sul lato destro dello schermo, al fine di eliminare del tutto o quantomeno minimizzare quello che in gergo tecnico prende il nome di Mida’s Touch Problem. Quest’ultimo può essere ricondotto all’idea intuitiva di “trascinamento”e può verificarsi concretamente ogni qualvolta, nello spostamento del puntatore dalla posizione del link alla barra di magnificazione, si incontrano durante il percorso altri collegamenti ipertestuali. Spostando la barra nella parte destra dello schermo, poiché buona parte delle pagine Web si sviluppano in senso verticale piuttosto che in orizzontale, dovrebbero diminuire le probabilità di “sporcare” la localizzazione e vedere magnificati altri collegamenti al posto di quelli originariamente desiderati In ultima analisi, infine, è auspicabile anche un perfezionamento dell’algoritmo di localizzazione. Nella sua caratterizzazione attuale, infatti, esso è in grado di localizzare solo e soltanto tutte le componenti della pagina HTML indicizzate nei vettori links[] e forms[] presenti all’interno del DOM della pagina acquisita. Sotto un certo punto di vista questo può apparire un punto di forza, poiché dietro un algoritmo apparentemente semplice è possibile localizzare in maniera sufficientemente immediata la quasi totalità dei collegamenti ipertestuali presenti all’interno della pagina. Dall’altro lato, però, così facendo vengono irrimediabilmente tagliati fuori tutti quegli elementi che all’interno del DOM hanno una minore visibilità e non appaiono indicizzati in alcun modo all’interno dei vettori predefiniti. Si tratta di un problema abbastanza importante e che viene percepito in maniera notevole soprattutto durante la compilazione delle form quando, in alcuni casi, risulta impossibile cliccare sul bottone di submit per visualizzare i risultati della query. Capitolo 6 – Sviluppi futuri e conclusioni 158
L’implementazione di una semplice procedura di visita che scorra tutti i nodi del DOM alla ricerca di nuovi elementi e preveda la successiva localizzazione anche per questi dovrebbe permettere di eliminare questo problema garantendo così la fruibilità di tutte quelle form scritte in maniera non “standard”, con il bottone di invio svincolato dagli altri elementi del modulo. Nell’immagine successiva sono invece state schematizzate le preferenze del campione riguardo le nuove componenti da implementare con maggiore priorità: Componenti da Aggiungere
Altro
Eye Tracker
Speech to Text
Gestione Preferiti
Tastiera T9
0
5
10
15
20
25
30
Numero Preferenze (su 30)
(figura 69 – Preferenze del campione sulle nuove componenti da implementare) Anche in questo caso è immediato rendersi conto di come le risposte degli utenti siano state indirizzate verso componenti che garantissero una migliore e più semplice fruibilità del modulo di gestione delle form. E’ in quest’ottica infatti che devono essere motivate le più di venti preferenze registrate per la realizzazione di una tastiera dotata di T9 (simile a quello dei cellulari) o l’integrazione del browser con un sistema di Speech‐To‐Text, attraverso cui compilare i campi testuali delle pagine HTML mediante la voce piuttosto che le fissazioni sulle lettere della tastiera visualizzata sullo schermo. Capitolo 6 – Sviluppi futuri e conclusioni 159
Altrettanto funzionali, in futuro, potrebbero risultare l’implementazione di un modulo di Gestione dei Preferiti realizzato in XUL e inserito nell’attuale interfaccia del browser e, ultimo ma non meno importante, l’integrazione con altri dispositivi di puntamento alternativi al fine di valutare, ad esempio, anche l’impatto di un Eye‐
Tracker all’interno di un campione sufficientemente ampio. L’ultimo quesito presentato agli utenti nell’ambito della sessione di sperimentazione, infatti, chiedeva di quantificare la probabilità con cui, in un prossimo futuro, avrebbero gradito la possibilità di adottare un modello di interazione basato sul movimento degli occhi o della testa. L’immagine seguente schematizza i risultati acquisiti: Preferenza futura per la modalità dʹinterazione
Altissima
7%
Minima
23%
Alta
20%
Media
50%
(figura 70 – Opinioni del campione sulla diffusione futura della modalità d’interazione) Dal grafico emerge immediatamente come gli utenti, dopo un solo utilizzo dell’head‐tracker, non escludano del tutto la possibilità di utilizzarlo in futuro come dispositivo di input principale, sebbene la loro attuale dimestichezza con lo strumento non sia assolutamente paragonabile a quella con mouse e tastiera. Capitolo 6 – Sviluppi futuri e conclusioni 160
E’ ovviamente azzardato cercare di trarre delle conclusioni definitive sulle future probabilità di sviluppo di questa modalità d’interazione a partire da un campione così piccolo, e oltretutto, se percorriamo a ritroso la storia e l’evoluzione dei dispositivi di input, l’attuale diffusione del mouse è il risultato di studi e di ricerche intraprese in ambito universitario anche più di venti anni fa. Questi dati però rappresentano di certo un punto di partenza, e ci fanno capire come questa modalità d’interazione possa svilupparsi, possa avere un futuro, e ci portano ad affermare senza ombra di dubbio come l’attività di ricerca in questo senso non può e non debba fermarsi. Innanzitutto nell’ottica dell’evoluzione delle modalità con cui l’uomo interagisce con la macchina, alla ricerca di tecniche e di metodologie che permettano di rapportarci e di utilizzare i computer in maniera più semplice e naturale, ma soprattutto alla luce dei tantissimi risvolti sociali che l’utilizzo di dispositivi di questo tipo porta con sé. Non dobbiamo dimenticare mai come il target primario di questo sistema sia rappresentato dagli individui diversamente abili: l’idea del Web universale di Tim Berners‐Lee, l’idea, presentata in apertura, di permettere indistintamente a tutti gli individui l’accesso alla Rete è un’idea importante e da perseguire con ogni mezzo. La storia, infatti, ci insegna che la condizione evoluzionistica propria del genere umano riesce a esplicitarsi in maniera completa se e soltanto se i benefici conseguenti all’utilizzo dell’innovazione raggiungono indistintamente, in maniera trasversale ed eterogenea, tutte le fasce sociali. Per realizzarsi appieno, dunque, lʹera digitale dovrà perseguire l’obiettivo di riuscire a portare lʹinformazione a tutte le persone, indistintamente. Solo quando lʹinformazione sarà davvero a disposizione di tutti allora potremo godere delle innovazioni che l’avvento della rivoluzione informatica porterà con sé: l’affermazione di Internet come principale fonte di informazione e come centro nevralgico di tutte le attività quotidiane, lo sviluppo del Semantic Web, la diffusione di nuovi protocolli (VoIP e IpTV, ad esempio) che permetteranno la comunicazione audio/video ad alta Capitolo 6 – Sviluppi futuri e conclusioni 161
definizione e la fruizione di contenuti a banda larga mediante la Rete, fino ad arrivare, magari, anche alla nascita di nuovi paradigmi di interazione, più efficaci e più naturali, che ci permettano di utilizzare tutti questi servizi in maniera diversa ed innovativa mettendo da parte tutti i dispositivi di input attuali. A qualcuno questo potrebbe sembrare uno scenario futuristico ed improbabile, ad altri solo un nuovo passo del naturale processo di evoluzione della storia dell’informatica. In fin dei conti nel 1970 nessuno avrebbe mai immaginato di mettere da parte la classica di riga di comando e di interagire con il PC mediante un’interfaccia grafica, per cui è normalissimo che anche oggi l’idea di mettere il mouse per sempre nel dimenticatoio per fare spazio agli eye‐tracker faccia sorridere. Ma magari tra trent’anni ritroveremo vecchi mouse impolverati riposti chissà dove e ripenseremo ad oggi, cercando di spiegare perché, ad una società alla continua ricerca dell’innovazione, permeata di tecnologia e desiderosa di vivere la rivoluzione informatica, davanti alla possibilità di navigare su Internet solo con lo sguardo e di scrivere testi semplicemente dettandoli con la voce, piaceva così tanto premere bottoni su una tastiera e muovere un puntatore su un display per cliccare delle icone. E questo ci farà altrettanto sorridere. Ringraziamenti xii
Ringraziamenti Inizialmente avevo promesso a tutti di laurearmi subito dopo il prossimo Scudetto dellʹInter. Col passare del tempo però lʹidea di sforare il numero di timbri previsto sul libretto e di vedermi alla soglia dei 40 anni contemporeanamente diseredato e senza una famiglia ha fatto prendere corpo lʹipotesi di percorrere una strada decisamente più veloce, accontentandomi della strepitosa accoppiata Coppa Italia‐Supercoppa e chiudendo prima possibile il discorso con la Laurea Triennale. Sono passati poco più di quattro anni da quando, era Novembre del 2001, mi sedetti per la prima volta tra i banchi di Informatica per seguire una lezione di Matematica Discreta, una lezione sugli anelli. Interessante, tralaltro: Non avrei mai potuto immaginare un legame così stretto tra lʹinformatica e lʹorificeria. Un paio di anni dopo mi hanno spiegato che di quella lezione non avevo capito assolutamente nulla. Forse sarà anche per questo che davvero in pochi si aspettavano la mia Laurea. Se lʹaspettavano così presto, almeno. 21 esami, 37 prove complessive, 40 laboratori, 78 libri, 1630 pagine studiate e più di 3700 ore complessive di studio sono tralaltro numeri che farebbero girare la testa se solo fossero veri, ma per mancanza di tempo non mi andava di contare il tutto e li ho inventati, per cui potete solamente fidarvi. Fidarvi che arrivare fin qui non è stato per nulla facile. Allo stesso modo non sarà per nulla facile ricordare tutte le persone da inserire in questi benedetti ringraziamenti. Lʹultima volta che ho utilizzato la memoria per qualcosa di diverso dal dare il mio indirizzo email o il numero di scarpe è stato più di dieci anni fa. Era incredibile la sicurezza con cui snocciolavo a memoria la scaletta Ringraziamenti xiii
fatta con le figurine. Alcune comprate, altre vinte, altre ancora acquisite con la forza bruta, ma le ricordavo tutte, e in questo momento sarà altrettanto importante cercare di non lasciar fuori nessuno, nessuno di tutti quelli che, in un modo o nellʹaltro, nel bene o nel male, sono entrati nella scaletta per aver contribuito anche in minima parte a farmi raggiungere questo traguardo. Per iniziare penso sia doveroso salutare tutti gli amici con cui ho condiviso i viaggi sulla tratta Corato‐Bari, i viaggi che per quattro anni la Bari‐Nord ci ha garantito con un ritardo così costante e preciso da sembrare quasi svizzero: Saluto Giuseppe, con cui ho condiviso le scelte universitarie di questi ultimi anni, Luigi con la sua allegria, Fabrizio con il suo inguaribile ottimismo, e Vincenzo, compagno degli ultimi esami, con le sue Marlboro. Parecchie menzioni meritano anche tutti i ragazzi del Dipartimento, a cominciare da Stu, quellʹincredibile cartone animato che da anni divide la sua carriera universitaria tra le lezioni di Analisi, la sala lettura e il distributore di croccantelle. Ovviamente non posso non salutare anche Massimo e Luca, due ottimi ragazzi con cui ormai ho stretto un rapporto che va ben oltre il consueto scambio di favori universitari. Oltre a loro tre, i nomi da tirare in ballo sarebbero davvero troppi, preferisco fermarmi qui per non evitare di nominrne qualcuno e dimenticarne altri. Per semplicità cito soltanto Paolo a nome di tutta la comunità di Laureateci.it, comunità di cui faccio parte da ormai due anni e che per me ha rappresentato un punto di riferimento per lo scambio di informazioni, il confronto e i momenti di svago che hanno caratterizzato il mio percorso, percorso di cui la tesi è stato solo lʹultimo passo, un passo durato dieci mesi. Apparentemente dieci mesi potrebbero sembrare tanti per concludere una laurea triennale, ma se dovessi tornare indietro rifarei esattamente e stesse scelte, magari ricordandomi di nascondere ogni tanto il passaporto di Marino per evitare almeno qualcuno dei suoi innumerevoli viaggi intercontinentali. Insieme a lui, saluto anche Lucio e Roberto, ottimi compagni con cui ho lavorato in armonia e a cui auguro Ringraziamenti xiv
di arrivare a scrivere ben presto questi stessi ringraziamenti. Eʹ dʹobbligo anche una menzione per i miei relatori. Un sincero grazie va al professor Semeraro, al dottor Lops e al dottor Degemmis, che in questi mesi mi hanno guidato, consigliato, supportato e seguito, magari anche più del dovuto. Li ringrazio soprattutto per la cordialità e lʹinfinita disponibilità di cui ho potuto sempre e costantemente usufruire. Un piccolo ringraziamento, infine, va anche agli “sperimentatori”, agli amici che hanno risposto alla mia supplicante richiesta di piazzarsi un fantomatico bollino sulla fronte pur di farmi terminare in tempo l’ultimo capitolo della Tesi: grazie dunque a Stu, Michelangelo, Marco, Luigi, Fabrizio, Giuseppe e soprattutto Davide, così desideroso di provare il browser da coinvolgere nella Sperimentazione anche la fidanzata. Per concludere, un ringraziamento speciale va a Dario, un amico che conosco da più di dieci anni e che è stato di fondamentale importanza allʹinizio della mia vita universitaria. Non potrò mai dimenticare il suo supporto iniziale, e il mio proposito per il futuro sarà quello di spingerlo a terminare il corso di Laurea almeno quanto lui mi ha aiutato ad iniziarlo. I ringraziamenti più importanti, infine, hanno già trovato spazio nelle prime pagine di questo lavoro: la mia famiglia e Marica meritano davvero una menzione a parte. Non scherzo quando dico che sono stati la motivazione principale che, giorno dopo giorno, sveglia dopo sveglia, treno dopo treno, lezione dopo lezione, esame dopo esame, mi ha costantemente dato lo stimolo di continuare sulla stessa strada, ripetendomi che potevo e dovevo farcela. Si è trattato di un inesorabile conto alla rovescia: di volta in volta contavo i giorni che mancavano dalla prova successiva, e, per fortuna, col passare dei mesi sono diminuiti anche gli esami che mi dividevano da questo traguardo. Ora come ora l’ultimo countdown che mi rimane è quello dei giorni che mancano alla seduta di Laurea. Circa dieci, nel momento in cui scrivo questi ringraziamenti. Ringraziamenti xv
Poi però non avrò più nulla da contare, e sono sicuro che tutta questa attesa un po’ mi mancherà. Magari per riempire questo vuoto potrò tornare a fare come quattro anni fa, iniziando nuovamente a contare i giorni che dividono l’Inter dal prossimo Scudetto e programmando in parallelo (si spera) la fine della mia Laurea Specialistica. Anche questa volta senza troppe illusioni, però: i timbri sul libretto potrebbero di nuovo non bastare. Grazie a tutti, Cataldo. Ringraziamenti xvi