ALMA MATER STUDIORUM – UNIVERSITÀ DI BOLOGNA CAMPUS DI CESENA SCUOLA DI SCIENZE
CORSO DI LAUREA IN SCIENZE E TECNOLOGIE INFORMATICHE
Implementazione dell’accessibilità in OpenTripPlanner
Relazione finale in Tecnologie Web
Relatore Presentata da Dott.ssa Paola Salomoni Stefano Nicoletti
Correlatore Dott.ssa Catia Prandi
Sessione III Anno Accademico 2014/2015
Indice
Indice
INDICE ...... I INTRODUZIONE ...... 1 1 ACCESSIBLE WEB E ACCESSIBLE MAP ...... 5
1.1 ACCESSIBLE WEB ...... 5 1.1.1 Definizione ...... 6 1.1.2 Standard ISO ...... 8 1.1.3 Linee guida e leggi ...... 8 1.2 ACCESSIBLE MAP ...... 12 1.2.1 Background ...... 13 1.2.2 Temi e target ...... 14 1.2.3 Tecniche per rendere le mappe accessibili ...... 15 1.2.3.1 Mappe tattili ...... 15 1.2.3.2 Mappe acustiche virtuali ...... 16 1.2.3.3 Altre tipologie ...... 17 1.2.4 Accessiblità delle mappe nei mobile device ...... 18 1.2.4.1 Studi di navigazione tattile ...... 20 1.2.5 Mappe accessibili a persone anziane o con disabilità cognitive ...... 23 1.3 WEB 3.0 E GEOWEB ...... 25 1.3.1 Globo virtuale ...... 28 1.3.1.1 Modello digitale di elevazione ...... 28 1.3.2 Recupero delle informazioni geografiche ...... 29 1.3.3 Sistema di gestione dei contenuti geospaziali ...... 30 2 TECNOLOGIE UTILIZZATE ...... 31
2.1 OPEN STREET MAP ...... 31 2.1.1 Il progetto ...... 32 2.1.2 La raccolta dati ...... 33 2.1.3 Gli elementi di Open Street Map ...... 34 2.1.3.1 Nodi ...... 34 2.1.3.2 Vie ...... 35 2.1.3.3 Relazioni ...... 35 2.1.3.4 Tag ...... 36 2.1.4 Disabilità e Open Street Map ...... 36 2.1.4.1 Hapto Render ...... 37 2.1.4.2 Loro Dux ...... 37
I Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
2.2 OPEN TRIP PLANNER ...... 38 2.2.1 Architettura ...... 39 2.2.2 Creazione di percorsi ...... 41 2.2.2.1 Algoritmo contraction hierarchies ...... 41 2.2.2.2 Algoritmo A* ...... 42 2.2.3 Sicurezza ...... 43 2.3 STRUMENTI ...... 44 2.3.1 Java ...... 44 2.3.2 HTML5 ...... 46 2.3.3 CSS ...... 47 2.3.4 DOM ...... 48 2.3.5 Mapnik ...... 49
3 DESCRIZIONE DEL PROGETTO ...... 51
3.1 IL PROGETTO ...... 51 3.1.1 Introduzione ...... 52 3.1.2 Principi di progettazione ...... 52 3.1.3 La struttura ...... 53 3.1.3.1 Lo studio del colore ...... 55 3.1.3.2 Portabilità ...... 57 3.1.3.3 La mappa ...... 58 3.2 LE MODIFICHE APPORTATE ...... 59 3.2.1 I moduli ...... 60 3.2.1.1 Il file ItinerariesWidget.js ...... 60 3.2.2 I fogli di stile ...... 61 3.2.3 CartoCSS ...... 62 3.3 TEST ...... 65 3.3.1 Simulazione con il profilo wheelchair ...... 65 3.3.2 Test per il daltonismo ...... 68 3.3.3 Revisione WCAG 2.0 ...... 69
CONCLUSIONI ...... 71 BIBLIOGRAFIA ...... I
II Introduzione
Introduzione
I sistemi di posizionamento satellitari oggigiorno esistenti sono nati e si sono sviluppati in piena guerra fredda per scopi militari. La loro applicazione e utilizzo nell’ambito civile è stato di fondamentale aiuto alla nostra moderna società, che affronta ogni giorno un aumento della reti stradali e punti di interesse sempre più dettagliati. Il sistema di posizionamento globale (Global Positioning System, GPS) è utilizzato dalla grande maggioranza di software di routing esistenti, ed esso è gestito dal governo degli Stati Uniti d’America, che, in particolari condizioni, potrebbero decidere discrezionalmente di ridurre la precisione o bloccare selettivamente l’accesso al sistema. Lo sviluppo da parte dell’Unione Europea di un sistema di posizionamento e navigazione satellitare civile come alternativa entrerà in servizio per la fine del 2019 con il nome di sistema di posizionamento Galileo. La sua rete sarà creata da 30 satelliti orbitanti e fornirà una maggiore accuratezza nella geo-localizzazione degli utenti rispetto a quella attuale, aumentando notevolmente la disponibilità del segnale nelle aree urbane. Il nuovo sistema di posizionamento renderà ancora più dettagliate le informazioni disponibili agli utenti con informazioni in tempo reale sulla disponibilità del servizio stesso, messaggi di ricerca e soccorso, informazioni metereologiche, avvisi di incidente, aggiornamenti temporanei alle mappe come traffico e deviazioni. Il numero di dati che potranno essere disponibili dunque crescerà notevolmente ed essi richiederanno software sempre più potenti e precisi, in grado di presentare tutte queste informazioni mediante siti Web o applicazioni. Il lento declino di navigatori satellitari stand-alone dovuto all’aumentare di tecnologie sempre più accessibili a livello economico, come smartphone e tablet, ha incentrato lo sviluppo di software di routing presentati come pagine Web per facilitarne l’utilizzo agli utenti. L’integrazione degli strumenti di navigazione nei telefoni cellulari di nuova generazioni infatti ha portato un
1 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
cambiamento nel mercato di navigatori satellitari, incentrando maggiormente l’attenzione dell’utente nei confronti dello stesso software. Al giorno d’oggi esistono svariati software di routing che presentano dati satellitari necessari alla navigazione come Google Maps, Open Street Map, Bing, Open Trip Planner, Routino e molti altri. Tutti questi software sono presenti e disponibili sul Web senza alcun costo per la consultazione e quindi alla portata di qualsiasi utente. Un software di navigazione tipico necessita di un display in cui viene visualizzato un percorso impostato dall’utente da seguire, una interfaccia grafica che permette allo stesso utente di interagire con il software e un altoparlante dove una voce guida può facilitare la navigazione. L’interazione da parte dell’utente con il software e con i rispettivi siti Web da essi presentati, ricade dunque nell’utilizzo dell’interfaccia del servizio offerto. In questa tesi si è voluto sviluppare proprio uno studio riguardante l’interfaccia dei sistemi di navigazione, in particolare nei confronti del software Web di Open Trip Planner. La scelta di Open Trip Planner è stata attuata in quanto è un software open source, che utilizza i dati delle mappe a contenuto libero del mondo provenienti dal progetto di Open Street Map. Il software di Open Trip Planner offre agli utenti la creazione di percorsi multimodali all’interno della città, ed è quindi rivolto ad utenti che vogliono pianificare i propri spostamenti all’interno di ambienti urbani. L’utilizzo di Open Trip Planner mediante un sito Web ha favorito uno studio di implementazione della sua interfaccia che fosse totalmente accessibile sia agli utenti che utilizzano tecnologie differenti tra loro, come tablet, smartphone o laptop, sia ad utenti che soffrono di particolari disabilità, come cecità, ipovisione, daltonismo o limitazione fisiche. Lo scopo che ha questa tesi è di creare una interfaccia per Open Trip Planner completamente accessibile ad ogni tipologia di utente. Quello che il programma di Open Trip Planner deve fare dunque, è offrire le informazioni riguardanti i percorsi urbani e tutte le restanti informazioni presenti su di una mappa, come ad esempio punti di interesse, in maniera completamente fruibile per ogni utente che utilizza questo tipo di supporto alla navigazione. È stato d’aiuto nella tesi incentrare in un primo momento l’attenzione nei confronti delle leggi e le linee guida di accessibilità Web, studiando dunque come il Web deve essere accessibile per gli utenti, per poi concentrarsi sull’accessibilità delle mappe stesse. Un ulteriore scopo della tesi infatti è stato capire come i dati relativi alla navigazione che vengono prelevati dai satelliti, debbano essere presentati all’interno della mappa, fornendo un grado di accessibilità elevato. Per
2 Introduzione
questo motivo si è studiato il funzionamento del motore e l’anima che sta dietro OTP, Open Street Map. Il corretto funzionamento e la moltitudine di dati offerta da Open Street Map infatti hanno reso OTP uno strumento molto potente all’interno dell’accessibilità urbana. Il software ha reso possibile lo sviluppo di nuove tipologie di spostamenti con profili ad hoc per utenti disabili, come la creazione di un nuovo profilo denominato Wheelchair, che crea dei percorsi accessibili a persone che non sono in grado di muoversi liberamente all’interno dell’ambiente urbano, e che dunque necessitano di particolari rampe di accesso, evitare ostacoli che possano ostruire il percorso o evitare pericolosi attraversamenti pedonali. Il progetto della nuova interfaccia ha tenuto in considerazione tutte le sfaccettature del software di Open Trip Planner, raggiungendo ottimi risultati di accessibilità e potenziando dunque lo stesso strumento. La struttura di questa tesi è cosi suddivisa: • Nel primo capitolo vengono introdotte le leggi, le linee guida relative al WCAG 2.0, descritti gli standard ISO e definita l’accessibilità Web. È stato trattato il tema dell’accessibilità delle mappe, spiegando come le mappe esistenti possono diventare accessibili e come i dati relativi alle informazioni geografiche devono essere presentati all’interno di una mappa urbana. • Nel secondo capitolo sono descritte le tecnologie utilizzate per sviluppare il progetto, volgendo particolare attenzione alla raccolta dati di Open Street Map, l’architettura di Open Trip Planner, dei suoi algoritmi di routing e della sua sicurezza e stabilità nei confronti del Web. Sono descritte inoltre gli strumenti che sono stati utilizzati per implementare il progetto della creazione della nuova interfaccia accessibile. • Nel terzo ed ultimo capitolo è dettagliatamente descritto il progetto di implementazione dell’interfaccia. Sono spiegati i principi di progettazione, le modifiche apportate al software ed in fine trattati i test e le revisioni che hanno confermato la totale accessibilità del prototipo dell’interfaccia accessibile creata.
3 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
4 Capitolo 1: Accessible web e accessible map
1 Accessible web e accessible map
In questo capitolo si illustra come è possibile rendere accessibile il web, descrivendo le linee guida, le leggi e tutto quello che entra a far parte delle buone norme utilizzate per rendere il web accessibile a qualsiasi utente secondo le sue preferenze e bisogni. Molta attenzione è incentrata sulla fruibilità delle mappe geografiche su web, descrivendo i punti focali sull’accessibilità di queste ultime, sia nell’ambiente digitale che nello specifico del web. Come ultimo aspetto è trattata la forte correlazione che si è sviluppata tra il web e le mappe geografiche, soprattutto nello sviluppo del web semantico e il geoweb.
1.1 Accessible web Il web è stato fortemente progettato per essere fruibile a qualsiasi tipo di persona, qualsiasi sia il suo hardware, software, lingua, cultura, posizione geografica, capacità fisica o mentale. Quando il web giunge questo obiettivo, diventa accessibile a una vasta gamma di persone con bisogni o preferenze specifiche, come per esempio utenti con disabilità, sia fisiche che cognitive,ma anche utenti che accedono a Internet con terminali limitati, come ad esempio smartphone o tablet. In questo modo, il web diventa strumento per rimuove gli ostacoli alla comunicazione e interazione che molte persone devono affrontare nel mondo fisico. Tuttavia quando i siti web, tecnologie web, o strumenti web sono mal progettati, possono creare barriere che escludono le persone che utilizzano questo servizio [W3CWDA]. E’ essenziale che il web sia accessibile al fine di fornire parità di utilizzo e pari opportunità per le persone disabili. La Convenzione delle Nazioni Unite sui diritti delle persone con disabilità, infatti dichiara “l’accesso alle tecnologie dell’informazione e
5 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
della comunicazione, tra cui il web, come un diritto umano fondamentale” [URCNP15]. L’accessibilità favorisce il sostegno e l’inclusione sociale sia delle persone con disabilità sia degli anziani, o di persone che vivono in zone rurali, e di quelle che abitano in paesi in via di sviluppo. Un forte business è inoltre in via di sviluppo, che sovrappone accessibilità e altre pratiche, come il Mobile web Design, Device Independence, Multimodal Interaction, usabilità e Search Engine Optimization (SEO). Casi di studio hanno mostrato che i siti web accessibili hanno migliori risultati di ricerca, costi di manutenzione ridotti e una maggiore portata di pubblico tra gli altri vantaggi [W3CWDA].
1.1.1 Definizione L’accessibilità è un termine generico utilizzato per descrivere la caratteristica di un dispositivo, di un servizio, di una risorsa o di un ambiente, di essere fruibile con facilità da una qualsiasi tipologia d’utente [W3SCBRW]. Comunemente, il termine, viene associato anche alla possibilità di accedere e muoversi autonomamente in ambienti fisici, di usufruire autonomamente a contenuti o di utilizzare dei sistemi informatici e tutte le risorse a disposizione, tipicamente attraverso tecnologie assistive o tramite il rispetto di requisiti di accessibilità dei prodotti, da parte di persone con ridotta o impedita capacità sensoriale, motoria o psichica. Il termine ha trovato largo uso anche nel web con il medesimo significato. Nel contesto creato dunque, le soluzioni di accessibilità sono sviluppate al fine di favorire la riduzione e l’eliminazione del web accessibility divide, ovvero il divario tra coloro che possono accedere in maniera autonoma a risorse web e coloro che non possono. Si tratta di un errore comune credere che l’accessibilità si riferisca esclusivamente al rapporto tra le persone con disabilità e il loro ambiente. Vale a dire che, costruire un edificio, un sito web, o un altro tipo di dispositivo accessibile, è puramente il processo che garantisce il corretto funzionamento di della cosa progettata. Infatti, quando una risorsa è stata progettata, sviluppata e creata correttamente, qualsiasi tipo di utente può avere uguale accesso alla sua funzionalità e alle sue informazioni. Spesso la più grossa barriera nei casi di un sito web è la tecnologia stessa che permette di usufruire dei contenuti, ovvero il browser.
6 Capitolo 1: Accessible web e accessible map
Fino a pochi anni fa Internet Explorer è stato di gran lunga il browser più popolare disponibile, e chiaramente, anche il meno compatibile con gli standard web. Fortunatamente i tempi sono cambiati con l’avvento sul mercato di nuovi browser, come Google Chrome e Mozilla Firefox, i quali assieme contano più dell’85% sulle statistiche mondiali di utilizzo di browser [W3SCBRW]. L’elemento fondamentale dunque per avviare il processo di accessibilità del web è il Cross-Browsers testing, che porta il test di accessibilità su i principali browser, o almeno su quelli che occupano il 99% delle statistiche di utilizzo. Un visitatore medio di solito aspetta poco più di 3 secondi per il caricamento di una pagina Web sconosciuta [NYTIWB12]. Anche se la velocità di connessione è altamente in cresita, (la media di velocità mondiale di connessione è 3.9 megabilts per secondo [WIKICS]), mantenere dunque, le dimensioni delle pagine web a un livello gestibile, con un grado minimo di servizi multimediali è un obiettivo fondamentale per l’accessibilità universale. Alcuni siti web richiedono di per sé maggiori risorse multimediali e questo è del tutto ragionevole, ma si dovrebbe comunque evitare inutili utilizzi che vanno a scapito dell’accessiiblità della pagina web. Alcuni browser hanno attiva di default l’opzione di navigazione senza JavaScript, principalmente per motivi di sicurezza; una eccessiva dipendenza da script infatti può degradare sia la sicurezza che la capacità di funzionamento del sito per alcuni utenti. Anche se la scelta migliore sarebbe evitare l’uso totale di JavaScript, esiste una seconda alternativa espressa concettualmente dal termine Progressive Enhancement [WIKIPRE]. Questa tecnica consiste nel creare prima i contenuti e la presentazione di ciò che si vuole inserire all’interno del sito web, e successivamente inserire le funzionalità di scripting, in modo tale che anche se si utilizzasse un dispositivo o browser che non visualizza JavaScript si può ugualmente accedere al contenuto [WIKIPRE]. Un ulteriore problema di alcune tipologie di scripting è il mancato supporto che i principali browser web offrono sui dispositivi mobile come smartphone e tablet. L’internet mobile è una fetta sempre più grossa del mercato, se un sito web non è accessibile sotto questo punto di vista, rischia letteralmente di tagliare fuori un’importante fetta di utilizzatori. L’accessibilità dunque, interessa davvero un ampio numero di tipologie di utenti. Proprio per questo motivo è fortemente relazionata con l’Universal Design, o
7 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
Design for All, termine internazionale con cui ci si riferisce a una metodologia progettuale di moderna concezione e ad ampio spettro che ha per obiettivo fondamentale la progettazione e la realizzazione di edifici, prodotti tecnologici e non, e ambienti che sono di per sé accessibili a ogni categorie di persone, al di là dell'eventuale presenza di una condizione di disabilità [WIKACSa].
1.1.2 Standard ISO Secondo l’International Organization for Standardization, ci deve essere ergonomia dell’interazione uomo-sistema e accessibilità per le interfacce uomo- computer. Esiste dunque lo standard ISO/TS16071:2002, che fornisce indicazioni sulla progettazione di software accessibile di tipo lavorativo, casalingo o educativo. Deve coprire problemi connessi con la progettazione di software accessibile con un’ampia gamma di persone con disabilità visive, uditive, motorie, di capacità cognitive, coprese persone anziane e disabili temporanei. ISO/TS16071:2002 affronta l’accessibilita dei sistemi interattivi. Si rivolge ad una vasta gamma di soluzioni, tra cui applicazioni per l’ufficio, pagine Web e multimendia. Non fornisce raccomandazioni per la progettazione di hadware. ISO/TS16071 promuove una maggiore fuibilità dei sistemi in combinazione con le tecnologie assistive, laddove siano necessarie. Non copre il comportamento o le esigenze di tecnologie assistive stesse (compresi i software di supporto) [ISO/TS].
1.1.3 Linee guida e leggi Nel 1999 la Web Accessibily Initiative, un progetto per il World Wide Web Consortium (W3C), ha pubblicato il Web Content Accessibility Guidelines WCAG 1.0. L’11 Dicembre 2008, Il WAI ha rilasciato il WCAG2.0 come raccomandazione. Esso si propone di essere sempre aggiornato e più tecnologicamente neutrale possibile. Anche se i web designer possono scegliere altri standard da seguire, il WCAG2.0 è stato ampiamente accettato come linea guida definitiva su come creare siti web accessibili. I governi stanno progressivamente adottando il WCAG2.0 come standard di accessibilità per i propri siti web. Il processo di trasformazione da WCAG1.0 a WCAG2.0 che è costato quasi 10 anni è stato fronte di grosse critiche. Dopo il rilascio della versione 1.0 infatti, Lisa
8 Capitolo 1: Accessible web e accessible map
Seeman, invetrice e imprenditrice a capo della Cognitive and Learning Disability Task Foce, sosteneva che le linee guida non mettevano sufficentemente l’utente al centro del processo. In altri articoli come "WCAG 2.0: The new W3C guidelines evaluated", "To Hell with WCAG 2.0" e "Testability Costs Too Much" invece, sono stati criticate la lentezza del processo di sviluppo della versione 2.0, i costi troppo elevati dei test di controllo e la difficoltà di navigazione e di comprensione delle nuove linee guida [WIKWBSa]. Il WCAG2.0 è così strutturato. Esistono 4 principi, che sono percepibile, utilizzabile, comprensibile e robusto. Dai 4 principi discendono le 12 linee guida che forniscono indicazioni per rendere il contenuto più accessibile. Le linee guida non sono verificabili, ma definiscono il quedro di riferimento e gli obiettivi generali per comprendere i criteri di successo e applicare le tecniche. Per ogni linea guida, vengono forniti un certo numero di criteri di successo verificabili. I criteri sono suddivisi in tre livelli di conformità e le pagine e i siti, possono chiaramente raggiungere diversi livelli di queste conformità. • Per la conformità al livello A (che è il livello minimo), la pagina Web soddisfa tutti i criteri di successo di livello A, oppure è fornita una versione alternativa conforme. • Per la conformità al livello AA, la pagina Web soddisfa tutti i criteri di successo di livello A e quelli di livello AA, oppure è fornita una versione alternatva conforme al livello AA. • Per la conformità al livello AAA, la pagina Web soddisfa tutti i criteri di successo di livello A, di livello AA e di livello AAA, oppure è fornita una versione alternatva conforme al livello AAA. Per ciascun criterio di successo presente nel documento WCAG 2.0 stesso, sono documentate una serie di tecniche che si dividono tra le sufficienti, per soddisfare un criterio di successo e le consigliate, che vanno oltre ciò che viene richiesto da ciascun singolo criterio di successo e consentono di rispettare le linee guida ad un livello più elevato. Una singola tecnica può fare riferimento a più criteri di successo e ognuna di essa, può essere generale, codificata dunque con G, o legata a una specifica tecnologia, ad esempio quelle codificate con H sono tecniche per l’HTML, quelle C per i CSS e cosi via. Chiaramente la specifica WCAG è stabile, le tecniche cambiano e aumentano al variare delle tecnologie di giorno in giorno.
9 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
La specifica WCAG è molto completa e altrettanto complessa, in quanto le tecniche sono numerosissime, inoltre si teve tenere in considerazione che la WAI ha rilasciato anche altre linee guida, e nello specifico, ATAG (Authoring Tool Accessibility Guidelines), UAAG (User Agent Accessibility Guidelines), WAI-ARIA (Rich Applicatons). Il diritto d’accesso alle risorse informatche da parte delle persone disabili è tutelato in molti stati da leggi specifiche, come in Italia, legge 4/2004 (detta legge “Stanca”) negli Stati Uniti, ADA ("Americans with Disabilities Act"), Secton 508, ma anche in Australia, Canada, Danimarca, Finlandia, Francia, Germania, Hong Kong, India, Irlanda, Israele, Giappone. Nuova Zelanda, Portogallo, Spagna, Svizzera, Gran Bretagna. Inoltre anche l’Unione Europea comincia a dare supporto a politiche comunitare in materia, a cominciare dall’e-procurament per il quale sta lavorando al Mandate 376, “European Accessibility Requirements for Public Procurement of Products and Services in the ICT Domain”. Come anticipato, la legge attualmente in vigore in Italia è la Legge 4/2004, Disposizioni per favorire l’accesso dei soggetti disabili agli strument informatci [CAMD04]. Nasce da diverse proposte tra cui Campa-Palmieri e Stanca, essa non tratta solo di Web ma di accesso agli strumenti informatci. È passata in Senato nel dicembre 2003 (Anno Europeo delle persone disabili) ma è ufficiale come Legge 9 gennaio 2004, n. 4, Pubblicata nella Gazzetta Ufficiale n. 13 del 17 Gennaio 2004, ha subito qualche piccola correzione nel Dicembre 2012. La Legge 4/2004 prevede diversi documenti tecnici che specificano i requisiti di accessibilità nei diversi contesti, che sono stati emessi con il Decreto Ministeriale 8 Luglio 2005, requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatci e i successivi aggiornamenti. Allegato A, verifica tecnica e requisiti di accessibilità delle applicazioni basate su tecnologie internet, allegato B, metodologia e criteri di valutazione per la verifica soggettiva dell’accessibilità delle applicazioni basate su tecnologie internet, allegato C, requisiti tecnici di accessibilità per i personali computer di tpio desktop e portatili, allegato D, requisiti tecnici di accessibilità per l’ambiente operatvo, le applicazioni e i prodotti a scaffale, allegato E, logo di accessibilità dei siti Web e delle applicazioni realizzate con tecnologie Internet, allegato F, importi massimi dovuti dai soggetti privati come corrispettivo per l’attività svolta dai valutatori.
10 Capitolo 1: Accessible web e accessible map
L’ Allegato A si artcola in 12 requisiti, ciascun requisito a sua volta verificato attraverso un certo numero di punti di controllo che specificano come controllare il rispetto di quel principio. Si nota subito dalla numerosità una certa corrispondenza con le WCAG, che diventa ancora più evidente esaminando requisiti e punti di controllo. • Requisito 1, alternatve testuali. Fornire alternatve testuali per qualsiasi contenuto di natura non testuale in modo che il testo predisposto come alternatva possa essere fruito e trasformato secondo le necessità degli utenti, come per esempio convertito in stampa a caratteri ingranditi, in stampa Braille, letto da una sintesi vocale, simboli o altra modalità di rappresentazione del contenuto. • Requisito 2, contenuti audio, contenuti video, animazioni. Fornire alternatve testuali equivalenti per le informazioni veicolate da formati audio, formati video, formati contenenti immagini animate (animazioni), formati multsensoriali in genere. • Requisito 3, adattabile. Creare contenuti che possano essere presentati in modalità differenti, ad esempio, con layout più semplici, senza perdita di informazioni o struttura. • Requisito 4, distnguibile. Rendere più semplice agli utenti la visione e l’ascolto dei contenuti, separando i contenuti in primo piano dallo sfondo. • Requisito 5, accessibile da tastera. Rendere disponibili tutte le funzionalità anche tramite tastera. • Requisito 6, adeguata disponibilità di tempo. Fornire all’utente tempo sufficiente per leggere ed utlizzare i contenuti. • Requisito 7, crisi epilettiche. Non sviluppare contenuti che possano causare crisi epilettiche. • Requisito 8, navigabile. Fornire all'utente funzionalità di supporto per navigare, trovare contenuti e determinare la propria posizione nel sito e nelle pagine. • Requisito 9, leggibile. Rendere leggibile e comprensibile il contenuto testuale. • Requisito 10, prevedibile. Creare pagine web che appaiano e che si comportino in maniera prevedibile.
11 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
• Requisito 11, assistenza nell'inserimento di dati e informazioni. Aiutare l’utente ad evitare gli errori ed agevolarlo nella loro correzione. • Requisito 12, compatbile. Garantre la massima compatbilità con i programmi utente e con le tecnologie assistive. Come si nota dalla lista, i requisiti corrispondono ad uno ad uno alle linee guida della WCAG. Per ogni requisito sono elencati diversi punti di controllo, per ciascuno dei quali sono specificate direttamente i criteri di successo WCAG da verificare. Sono inseriti nella normatva, tutti i criteri di successo di livello A e AA. In conclusione la conformitaà alla Legge 4/2004 corrisponde alla conformità WCAG AA. Fare riferimento a uno standard riconosciuto a livello internazionale significa poter usare applicazioni e tool conformi a questo standard [SAL15-16a].
1.2 Accessible map Mappe, dati geografici e sistemi basati sulla acquisizione in tempo reale della propria posizione hanno sempre più importanza nelle moderne applicazioni desktop e mobile. Questi tipi di servizi, utilizzabili mediante un relativo sito web o software, consentono la ricerca e la visualizzazione di carte geografiche di una grossa parte della Terra. Tracciando la posizione geografica dell’utente è possibile inoltre ricercare servizi in particolari luoghi, come ristoranti, monumenti, negozi, si può visualizzare un percorso stradale tra due punti, visualizzare l’orario di trasporti pubblici, e visualizzare in dettaglio molte zone della superficie terrestre con una risoluzione molto dettagliata. Attualmente, esistono vari tipi di applicazioni che in qualche modo utilizzano la posizione dell’utente per creare un beneficio da essa. Molti utenti utilizzano questo tipo di applicazioni tutti i giorni per rendere la loro vita più facile e muoversi più rapidamente all’interno di città o punti di interesse. Queste applicazioni utilizzano mappe visive per comunicare le informazioni in base alla posizione dell’utente, ma se una persona affetta da disabilità visiva o cecità volesse trarre dei benefici da questo tipo di strumento, andrebbe incontro a grosse difficoltà. Inoltre, altri tipi di disabilità influenzano i requisiti che devono essere considerati da un’applicazione che si basa sulla localizzazione. Per esempio, persone sorde, o che possiedono problemi di udito, persone anziane, o con disabilità cognitive. Tutte queste tipologie di utenti hanno esigenze piuttosto specifiche in termini di progettazione dell’interfaccia utente e la presentazione dei dati geografici devono
12 Capitolo 1: Accessible web e accessible map
necessariamente essere adattati. Mappe accessibili per le persone non vedenti o ipovedenti hanno lo scopo di comunicare informazioni nella maniera corretta. Ciò significa che le mappe accessibili, devono trasferire all’utente informazioni senza utilizzare il senso della vista, ma utilizzando altri canali di percezione, come l’udito o la percezione tattile. Dati geografici devono anche essere accessibili ad altri gruppi-target considerando in particolare fattori come il livello di dettaglio [W3CACMa].
1.2.1 Background Dal momento che i servizi basati sulla localizzazione e navigazione per auto e persone sono diventati degli standard su ogni tipologia di smartphone e tablet, la potenzialità delle mappe e dei dati geografici sono ben conosciuti da una grossa fetta della società. La posizione dell’utente o di altre persone e degli oggetti è una informazione chiave inclusa nel ragionamento per l’implementazione di sistemi e servizi di localizzazione mirati. I vantaggi acquisiti dal monitoraggio, sia GPS che GPRS fuori casa, e Wi-Fi e Bluetooth in casa, consentono l’implementazione di sofisticati sistemi e servizi che aiutano l’utente, fornendogli informazioni e funzionalità che sono di particolare importanza in alcuni contesti geografici. Servizi web come Google Maps [GOOM], OpenTripPlanner [OTP] o Maps di Apple [APPM], offrono dati nelle mappe in maniera gratuita. In questi giorni, le applicazioni mobile utilizzano questo tipo di data per migliorare le richieste di ricerca come ad esempio per negozi o alberghi, inserendoli nei risultati e rendendo più facile per l’utente avere una visione più completa del mondo che lo circonda. In generale, le mappe visive forniscono un modo rapido ed efficace per comunicare la composizione dell’area geografica circostante e offrono informazioni utili per l’orientamento e navigazione. Gli utenti che non sono in grado di utilizzare queste mappe visuali standard dunque, non sono in grado di accedere a queste tipologie di informazioni. Per questo motivo le mappe accessibili sono un bisogno necessario per molte persone. C’è una forte relazione con altri settori che devono tenere conto dell’accessibilità, come ad esempio i sistemi basati sulla localizzazione, il Pervasive Computing e lo Ubiquitous Computing, oppure la parte di ingegneria che crea supporti sensoriali e tecnologie assistive [W3CACMb].
13 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
1.2.2 Temi e target Gli utenti di mappe accessibili che sono disabili hanno necessariamente bisogno di informazioni più dettagliate nei confronti dell’ambiente che le circonda. La precisione di meno di 0,1 metri è obbligatoria, cosi come la forma degli edifici, la forma dei marciapiedi, delle strade e di ogni singolo oggetto che è stato installato su percorsi pubblici. Le mappe devono essere adatte ai pedoni, questo significa che le informazioni su striscie pedonali, zone pedonali e trasporti pubblici sono necessari per fornire indicazioni utili all’utente. I sistemi di navigazione cosiddetti Eyes-Free, di solito cercano di non influire con il senso visivo dell’utente, comunicando con altoparlanti o cuffie in modo che l’utente possa acquisire le informazioni senza visualizzare lo schermo del dispositivo. Nel caso in cui un utente con problemi di udito volesse utilizzare il servizio però andrebbe in contro a limitazioni di usabilità. Una soluzione possibile considerando questi requisiti, sono occhiali dove appaiono informazioni in tempo reale, oppure un supporto tattile come un braccialetto o lo smartphone stesso, che con vibrazioni possa guidare l’utente. Inoltre le persone affette da disabilità cognitive o persone non udenti, di solito preferiscono un linguaggio semplice o meglio simboli intuitivi che velocizzino il processo di apprendimento delle informazioni. Alcuni approcci si concentrano anche sulla lingua dei segni per comunicare con l’utente sordo. Importanti sono le informazioni sull’accessibilità di percosi e degli edifici, oltre alla disponibilità di strisce pedonali o di rampe e accessi per persone che utilizzano sedie a rotelle. Gli utenti vedenti che desiderano utilizzare una mappa accessibile e che non voglioni distrarsi guardandola hanno esigenze diverse a seconda dei casi d’uso. Se vogliono svolgere una navigazione pedonale ad esempio, i requisiti sono abbastanza simili al primo target. Se voglioni usarlo come sostituzione o estensione ai sistemi tradizionali di navigazione per auto invece, il livello di dettaglio e il tipo di dati che sono rilevanti per l’utente varia. In generale le mappe non devono raggiungere lo stesso livello di dettaglio. Ad esempio un automobilista non ha bisogno di conoscere le dimensioni esatte di un edifico accanto alla strada per superarlo, mentre una persona con problemi di vista avrebbe bisogno di questo tipo di informazione sotto un altro tipo di comunicazione sensoriale.
14 Capitolo 1: Accessible web e accessible map
In conclusione dunque, diversi casi di utilizzo richiedono diversi livelli di dettaglio, precisione e in aggiunta di dati precisi nel dettaglio, come strade, incroci e specifiche a seconda dello scopo di utilizzo [W3CACMc].
1.2.3 Tecniche per rendere le mappe accessibili In questi giorni non esiste ancora una norma, o uno standard, che descrive come creare una mappa visiva accessibile alle persone con disabilità, sia questa mappa creata in forma cartacea, uditiva o in formato digitale. Le disabilità che sono legate direttamente con la lettura e l’utilizzo di mappe sono principalmente i problemi connessi all’occhio, come cecità totale, ipovisione e daltonismo. Le informazioni di una mappa visiva di solito sono molto compresse e rispetto al senso della vista, il senso tattile delle dita può fornire solo un canale piuttosto limitato di percezione e informazioni. Pertanto è molto difficile trasferire le stesse informazioni dettagliate all’utente senza utilizzare il senso della vista. Fortunatamente esistono alcuni strumenti a supporto che possono notevolmente aiutare questo tipo di accessibilità [W3CACMd].
1.2.3.1 Mappe tattili Uno studio internazionale afferma che i diagrammi di carta e termoformatura sono sempre più frequentemente utilizzati per rendere le mappe accessibili alle persone con disabilità visive. Questo tipo di carta, di solito contiene importanti elementi come le strade o edifici rappresentati tatticamente. Essi sono etichettati sia in Braille, e per evitare la sovrapposizione, anche con una leggenda. Normalmente, la generazione di mappe tattili è manuale, e richiede grossi costi e tempi molto lunghi. Per tale motivo, alcuni approcci mirano a semplificare il processo di generazione e convertire automaticamente i dati geografici di mappe tattili. Ad esempio, il TMAP Project (Tactile Map Automated Production Project) è un progetto di che ottiene dati geografici da GIS (Geographic Information System) e trasferisce questo tipo di dati su un supporto per il codice Braille o su carta, velocizzandone la produzione [AHBLZGQ]. I tipi e le forme di mappe tattili sono di vari tipi, tutte con lo scopo unico di rappresentare tutto quello che può stare su una mappa geografica e che possa essere accessibile a persone non vedenti. Il modo più comune di produrre mappe tattili è la termoformatura. Le mappe termoforate vengono create da un processo dove un folio di plasica viene riscaldato e applicato sopra di un modello a negativo. Questo stampo
15 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
sucessivamente servirà per creare tutte le copie che si vorranno di una mappa. Visti i processi e l’utilizzo di particolari sostanze costose che creano lo stampo, questo non è uno delle tipologie di mappe tattili più economiche. Lo è invece la carta Swell, che è creata con un rivestimento speciale creato con alcuni materiali chimici. Le microcapsule di alcol che sono inserite nella rottura della carta esposta al calore, crea un rigonfiamento della carta stessa, e l’immissione dell’inchiostro nero su carta prima del processo termico consente di controllare le superfici in rilievo e correggere gli eventuali errori. Per produrre più velocemente più copie di una stessa mappa, posso essere utilizzati dei goffratori in Braille, modificati in maniera adeguata per lo scopo. Un altro metodo di produzione di massa invece deriva direttamente dal settore delle applicazioni biomediche, e consiste nel creare mappe tattili con getti d’inchiostro, fatte da più stratificazioni di inchiostri appositamente progettati. Ogni strato è curato da irradiazione ultravioleta prima di aggiungere uno strato successivo. Il substrato per le mappe tattili è un attributo molto importante, poiché diversi materiali possono aumentare o ridurre la leggibilità e durata. I materiali più utilizzati nella produzione sono plastica ruvida e liscia, carta di ogni tipo come in microcapsule, Braillon e alluminio. Per scegliere il substrato devono essere considerati molti fattori, come la funzione e la portabilità [WIKTGPH].
1.2.3.2 Mappe acustiche virtuali Un altro tipo di approccio è la mappa acustica virtuale. Invece di stampare dati geografici su un pezzo di carta, queste mappe utilizzano la rappresentazione digitale dell'ambiente, comunicando le informazioni direttamente all'utente. Mappe acustiche virtuali convertono elementi della mappa in diversi suoni. Wilko Heuten ha proposto l'uso delle cosiddette torce uditive per limitare il livello di dettaglio e di migliorare l'usabilità. L'utente può controllare direttamente il campo di visibilità del walk-through e può esplorare gli oggetti della mappa della città che sono rappresentati nello spazio da suoni non parlati. Un'altra applicazione di questo approccio è la navigazione per non vedenti attraverso ambienti virtuali basati sull’audio. Le mappe acustiche virtuali si basano sulla sintesi vocale che descrivono, sia la composizione delle strade, sia le loro indicazioni e le informazioni più dettagliate come i nomi, distanze e ostacoli [W3CACMf].
16 Capitolo 1: Accessible web e accessible map
Uno dei progetti sicuramenti più interessanti che riguardano le mappe acustiche, è quello sviluppato dall’Università di Oldenburg in Germania e intitolato “Interactive 3D Sonification for the Exploration of City Maps”. L’obiettivo del lavoro è proprio quello di creare una sonificazione di una mappa in 2D, in modo tale da poter essere utilizzata in un ambiente a tre dimensioni con l’ausilio delle onde acustiche. Una persona cieca dunque, può creare un modello mentale di un’area geografica esplorandola virtualmente con una mappa uditiva comodamente a casa sua. Per questo tipo di applicazione dunque, si è cercato di trasformare gli oggetti geografici, come laghi e parchi, con il loro suono caratteristico in segnali acustici. Questi suoni caratteristici sono in particolare il suono del tipo dell’oggetto, la sua locazione e la sua forma. Oggetti differenti sono stati rappresentati da suoni differenti. Al fine di trasmettere la informazione sulla posizione degli oggi e la loro forma, è stato unito il concetto di sonificazione con una stanza e un suono virtuale in 3D. Usando questo tipo di suono 3D, le sorgenti sonore, le quali rappresentano ciascuna uno specifico oggetto geografico, possono essere collocate all’interno di una stanza virtuale in maniera equivalente a posizioni spaziali degli oggetti sulla mappa. La rappresentazione uditiva di un oggetto può essere localizzato dall’utente all’interno della stanza come suono e quindi si può ottenere una idea della posizione sulla mappa. Al fine di trasmettere informazioni circa la forma e le dimensioni di un oggetto, si utilizza non una sorgente sonora singolare, ma un area di suono bidimensionale. Esplorando la mappa, l’utente è in grado di sentire i bordi degli oggetti e può quindi realizzare le sagome degli oggetti. Per migliorare la percezione delle dimensioni di un oggetto, comprese anche le distanze tra utente e oggetto, la distanza geografica di un oggetto bidimensionale è sempre misurato dal punto dell’oggetto più vicino all’utente [HEU06].
1.2.3.3 Altre tipologie Oltre i comuni e più conosciuti metodi di creazione di mappe accessibili, esistono anche altre due tipologie che sono ancora in fase di studio e sviluppo. La prima è definita mappa tattile virtuale. Questo tipo di mappa tattile utilizza schemi tattili, o altri dispositivi tattili interfacciabili, come joystick o mouse, come canali d’ingresso e uscita delle comunicazioni dei dati geografici all’utente, molto spesso aiutati da una uscita acustica che rende le informazioni ancora più dettagliate. Un'altra tipologia di mappe accessibili, nettamente più consolidate rispetto alla prima, sono le mappe tattile-acustiche. Si tratta di una combinazione di mappe tattili
17 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
tradizionali cartacee e un pad sensibile al tocco. La mappa è stampata su un prezzo di carta da una stampante tattile e viene collocata sopra il pad. L’utente può esplorare la composizione della città, nello stesso modo in cui lo farebbe con una normale mappa tattile, ma con un livello di dettaglio e di informazione molto maggiore, avendo anche un supporto acustico che funziona in contemporanea alla pressione delle dita [W3CACMf].
1.2.4 Accessibilità delle mappe nei mobile devices I recenti progressi nella tecnologia touch screen hanno aumentato l’utilizzo di esso nei confronti di utenti con disabilità, facendo crescere una richiesta di dispositivi mobile basati per la maggior parte sul sistema touch. Nonostante questa nuova tecnologia, gran parte dei touch screen sono ancora inaccessibili ai non vedenti perché richiedono all’utente di individuare visivamente oggetti sullo schermo. Per risolvere questo problema, sono state sviluppate applicazioni, che utilizzano audio in ingresso e uscita, e gesti applicabili direttamente sullo schermo, che consentono alle persone cieche di interagire con i dispositivi mobile. Sebbene i touch screen esistono da decenni, i nuovi progressi nelle interfacce touch, come si è visto con i prodotti come il touch 3D dell’iPhone di Apple e il Microsoft Surface, hanno rinnovato l’interesse dei consumatori. Oltre che in questi tipi dispositivi, i touch screen vengono sempre più incorporati in altri dispositivi, come fotocopiatrici e altre apparecchiature per ufficio, pagamenti al supermercato, checkin aereoportuali, sportelli automatici, controlli dell’ascensore e macchine per il voto. Queste interfacce touch screen offrono un infinita di vantaggi per utenti vedenti, come presentare vari contenuti interattivi in un singolo spazio. Ad esempio un dispositivo touch può visualizzare una mappa o immagini di grandi dimensioni e far apparire una tastiera solo quando necessario, fornendo funzionalità aggiuntive in uno spazio più piccolo. Un altro vantaggio del touch screen è la visibilità. Anziché richiedere agli utenti di ricordare i tasti di controllo, i touch screen consentono agli utenti di visualizzare un elenco di opzioni e toccare quella desiderata. Tuttavia, gli schermi touch possono presentare importanti barriere di accessibilità per gli utenti non vedenti. La maggior parte di questi schermi non forniscono alcun audio o feedback tattile, il che rende difficile o impossibile visualizzare elementi sullo schermo. Per questo motivo gli
18 Capitolo 1: Accessible web e accessible map
utenti non vedenti necessitano di visualizzare le posizioni degli oggetti su un touch screen solo con l’ausilio di una persona vedente. Come crescono il numero di dispositivi che diventano touch oriented, tanto crescono le barriere che impediscono l’accessibilità ad un cieco o ipovedente, in quanto pochissimi dispositivi forniscono un supporto per l’accessibilità a questi utenti. Alcuni progetti di ricerca del passato hanno tentato di aumentare l’accessibilità dei sistemi telematici basati sul touch screen, aggiungendo ad essi una tastiera esterna o una sovrapposizione tattile. Nokia, ad esempio, sta sviluppando un touch screen con tasti tattili in rilievo, ma ancora non ha annunciato una data di uscita per questo prodotto. Il lettore di schermo Mobile Speak [MBSPK] fornisce l’accesso ai telefoni cellulari touch screen, ma offre un aiuto molto limitato ad essi. Mobile Speak fornisce principalmente l’accesso tramite la tastiera del telefono, ma consente agli utenti di tocca i quattro angoli dello screen touch come pulsanti aggiuntivi, ma in questo modo il lettore non può essere utilizzabile sui telefoni che non hanno alcun tasto fisico. La maggior parte dei touch screen non tattili del momento non possono essere facilmente utilizzati da non vedenti e ipovedenti. Questi utenti possono incontrare diversi problemi quando si cerca di interagire con un touch screen. La mancanza di accessibilità audio o una risposta tattile durante l’esecuzione di azioni, la mancanza di capacità di determinare lo stato corrente del dispositivo, la difficoltà a selezionare la voce o azione desiderata sullo schermo, sono tutti problemi associati a questo tipo di tecnologia. Oggi si possono trovare molti tipi di software aggiuntivi per risolvere questo tipo di problemi e uno dei più attuali è Slide Rule [SHA09], che consente agli utenti di utilizzare un touch screen senza avere una risposta visiva. Inoltre, se per un touch screen si ha necessariamente bisogno di una sovrapposizione di un hardware tattile per diventare accessibile, con questa tecnologia gli utenti possono avere piena accessibilità al touch screen senza l’ausilio di nessun hardware supplementare. Fortunatamente la stragrande maggioranza dei nuovi sistemi operativi presenti negli smartphone e tablet del nuovo millennio, possiedono già alcune estensioni con supporto vocale strettamente connesse all’accessibilità, come ad esempio il VoiceOver o Siri nei dispositivi Apple, Google Now e Jelly Bean di Android. La combinazione di queste due tecniche di accessibilità risulta veramente un ottima soluzione per utenti con disabilità visive.
19 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
Queste estensioni accessibili dei software possono essere attivate con dei tocchi preimpostati, ad esempio facendo scorrere il dito dal basso verso l’alto dello schermo oppure creando una “L” sullo spazio del touch screen, quando l’apparecchio è in stand- by, attivando un aiuto vocale che andrà a leggere ogni singola cosa che c’è sullo schermo in base alla posizione del tocco; cliccando 2 o più volte, verrà attivato il vero comando del tocco che corrisponde all’azione letta precedentemente. Con questo supporto tutto quello che potremmo avere disponibile all’interno di una mappa geografica, come ad esempio un punto di interesse come ristorante o una via può essere riferita verbalmente dallo stesso dispositivo. Una mappa accessibile necessiterà dunque di una semplice barra di ricerca, nella quale con un doppio tocco, dopo averla precedentemente individuata sullo schermo, si potrà inserire una destinazione. L’inserimento di ogni singola lettera può essere fatta con la stessa tecnica di lettura con un tocco e selezione con due tocchi, così come l’input che da il via alla ricerca, oppure con un ulteriore pulsante per dettatura vocale. Chiaramente una mappa geografica ha molte informazioni compresse sullo schermo, quindi l’utilizzo di un supporto vocale è indispensabile per la navigazione verso la meta scelta. Una mappa geografica può essere di fondamentale aiuto dunque ad un utente che ha una cecità totale o parziale, per potersi muovere nel mondo di oggi, dove la precisione della localizzazione GPS sulla Terra è diventata dettagliatissima. Oltre ad una barra di ricerca, sarà necessario un pulsante per la localizzazione in tempo reale, il quale dopo essere stato attivato potrà riferire in maniera vocale all’utente la precisa posizione. Assistenti vocali come Siri dell’OS di Apple, può essere richiamata con un semplice comando vocale denominato “Hey Siri!” o con la pressione del pulsante centrale del dispositivo Apple per 2 o più secondi. Con esso è possibile dettare verbalmente punti di interesse, richiedendo ristoranti o supermercati vicino alla tua posizione, o se si ha preimpostato il proprio indirizzo di abitazione, chiedere indicazioni stradali per tornare a casa.
1.2.4.1 Studi di navigazione tattile Negli ultimi anni sono stati fatti alcuni passi importanti riguardanti la navigazione tattile con dispositivi mobile, anche grazie al fatto che gli studi e la tecnologia a riguardo è diventata sempre più sofisticata e precisa. Uno studio preliminare è stato fatto prendendo ciò che a noi è di comune utilizzo, come un
20 Capitolo 1: Accessible web e accessible map
dispositivo smartphone o tablet dotato di un motore con vibrazione, e si è indagato se le vibrazioni e il feedback vocale possono essere utilizzati per creare una mappa digitale su questo tipo di dispositivi. La prova principale è stata attuata nei confronti della risposta sotto forma di vibrazione, combinata con la voce, che possono dare questo tipo di oggetti se utilizzati e attivati con lo scorrere di un dito sulla mappa e quindi nell’area touch dello schermo del dispositivo. I risultati dello studio hanno indicato che è infatti possibile ottenere una panoramica di base del layout della mappa, anche se una persona non ha accesso completo o parziale della rappresentazione visiva. Gli elementi chiave, che una persona vedente riceve da una mappa sono strade e alcuni punti di interesse, come ad esempio una chiesa. Tuttavia, sia per avere la certezza che la strada imboccata sia giusta, sia per avere una panoramica totale della mappa, le strade sono spesso i più importanti punti di interesse. L’approccio più intuitivo alla soluzione della lettura della mappa da parte di un utente cieco sarebbe sicuramente quello di leggere un codice Braille, dove le strade sono rappresentate in maniera classica con dei puntini in rilievo. Questo tipo di approccio si può rispecchiare dunque sul dispositivo mobile. Una volta attivata la appostita modalità touch-over per utenti con disabilità visive, essi potranno scorrere il dito sul display touch del dispositivo ed esso emette un certo tipo di vibrazione e il nome della strada viene continuamente letto dallo speaker. Durante lo studio di questo tipo di applicazione però sono stati riscontrati alcuni problemi, dove principalmente gli utenti non riuscivano ad acquisire bene le informazioni da questo tipo di tecnologia. Infatti uno dei problemi maggiori è stato capire se le strade rappresentate fossero brevi o molto lunghe, e quindi capire le dimensioni apportate alla realtà. Inoltre gli utenti non sono riusciti bene a capire se le strade rappresentate fossero in realtà chiuse oppure se avessero degli attraversamenti pedonali. Questi risultati dunque dimostrano che è si possibile realizzare una mappa che ha dei feedback di vibrazione e vocali che possa essere accessibile ad utenti con disabilità visive, tuttavia i problemi principali legati alla progettazione e alle informazioni riguardanti la lunghezza delle strade deve essere affrontato ancora con più attenzione [BEN11]. Altri studi riguardanti la navigazione tattile su i dispositivi mobile touch hanno portato a nuove tecniche di navigazione più innovative, che differiscono dalla lettura della mappa mediante l’utilizzo touch screen; queste possono chiaramente essere
21 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
applicate ad un qualsiasi software o pagina web visualizzabile da mobile. Una nuova tecnica è stata denominata “Bacchetta Magica” [MAR12]. Essa utilizza il nostro device, come una sorta di estensione del nostro braccio, e puntandola verso la direzione che si sta seguendo risponde con delle vibrazioni che permettono all’utente di trovare la giusta direzione in un tragitto precedentemente impostato. Tecnicamente, questo è diventato possibile, in quanto gli smartphone sono diventati molto precisi sotto il punto di vista della localizzazione. In questo tipo di contesto gli utenti possono rimanere consapevoli della direzione generale nella loro destinazione di viaggio. Test hanno dimostrato che questa tecnica è molto intuitiva e permette di raggiungere efficacemente una meta anche per persone cieche. Tuttavia il continuo puntamento dello smartphone può essere una soluzione ingombrante e fastidiosa per l’utente che deve affrontare un tragitto non banale e breve. L’alternativa a questa tecnica è denominata “Sesto Senso” [MAR12]. Essa utilizza un feedback multimodale per avvisare l’utente degli eventuali cambiamenti ambientali, come ad esempio la posizione di una destinazione di viaggio in relazione alla posizione e l’orientamento del viaggiatore. A questo feedback è stato applicata una emissione di vibrazioni, che sono percepite tramite dei pattern specifici che descrivono la direzione di marcia. Il vantaggio di questo approccio è che gli utenti non sono tenuti a cercare entità spaziali attraverso gesti di puntamento del dispositivo, ma tuttavia la tecnica richiede all’utente di conoscere il significato dei vari pattern di vibrazione che vengono emessi come feedback, altrimenti la navigazione risulterebbe impossibile. Il giusto approccio al problema risulta dunque la combinazione delle due tecniche. I test prodotti dalla combinazione della “Bacchetta Magica” e del “Sesto Senso” infatti hanno dato risultati ottimi nel trasmettere con precisione la direzione di un’entità spaziale in relazione ai dispositivi di puntamento direzionali mediante l’utilizzo di vibrazione. La combinazione dei due sistemi ha il vantaggio che, in un momento di smarrimento o ambiguità, l’utente può utilizzare il puntamento per chiarire e correggere la propria navigazione. I principali test di navigazione in larga scala, che quindi hanno coinvolto un grande numero di utenti, sono stati fatti con PoketNavigator, che è un sistema di navigazione basato su mappe molto simile a Google Maps. Esso utilizza i dati di OpenStreetMap, che risultano essere estremamente dettagliati su percorsi pedonali, è l’interfaccia dell’applicativo risulta molto semplice e intuitiva. L’idea di base
22 Capitolo 1: Accessible web e accessible map
riguardante il feedback tattile è quella di mappare le direzioni (avanti, sinistra, destra, dietro, e le altre quattro direzioni intermedie) ai singoli modelli di vibrazione. Come ogni sistema di navigazione verso un punto di interesse, il tragitto totale si suddivide in piccoli waypoint, che hanno il compito di rendere più semplice la navigazione. Ad esempio, quando un utente si dirige verso un waypoint, due brevi vibrazioni indicano “avanti”, mentre quando il waypoint successivo è a sinistra, una lunga vibrazione e una corta indicano “sinistra”. Queste indicazione sono chiaramente date in relazione alla direzione di marcia dell’utente, ed essa acquisita dal segnale del GPS. Con questa tecnica il dispositivo può essere tenuto in tasca e non richiede gesti affaticanti. Gli svantaggi invece, sono che i modelli di navigazione devono essere continuamente appresi, quindi se l’utente non si muove, il senso di marcia non può essere determinato. Per compensare questo svantaggio è stata introdotta la ripetizione l’ultima istruzione ogni 3-4 secondi in caso di arresto di marcia. Questa soluzione però ha creato non poche ambiguità. Per risolvere i problemi della vibrazione quindi, è stata introdotta la caratteristica del “corridoio silenzioso”; viene emessa la prima istruzione, fino a quando l’utente cammina verso il waypoint successivo, il sistema rimane in silenzio, e nel caso in cui serva ripetere l’ultima istruzione, si può utilizzare sempre il dispositivo come “Bacchetta Magica”. Un ulteriore problema è stato riscontrato nel percepire le vibrazioni. Generalmente una singola vibrazione è troppo debole per essere percepita con chiarezza da un oggetto che resta nelle tasche durante il movimento. Quindi è stato introdotta la emissione delle istruzioni solo nel momento in cui viene toccato in una zona qualsiasi il touch screen. Questo ha il vantaggio di consentire agli utenti di ricevere il feedback tattile su richiesta semplicemente toccando il dispositivo. Per aiutare gli utenti ad utilizzare questo tipo di applicazioni sarebbe necessario inoltre un tutorial inziale, che con una serie di test, sia tattili che acustici, rendono più facile l’apprendimento delle tecniche di vibrazione che il dispositivo emette durante tutto il tempo di navigazione [MAR12].
1.2.5 Mappe accessibili a persone anziane o con disabilità cognitive L’accessibilità web per persone anziane o con disabilità cognitive è un tema molto vario, ma ha in comune un insieme di requisiti ed esigenze riguardanti l’interfaccia utente, soprattutto quando si tratta di mappe visuali. Gli individui che
23 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
riguardano questa tipologia di utenti spesso preferiscono un linguaggio più semplice o simboli chiari e facili da capire. Le interfacce adattive, per utenti con disabilità cognitive, possono anche fornire vantaggi per soddisfare le esigenze specifiche di un individuo che necessita di semplicità e funzionalità. Ad esempio un utente sordo, solitamente possiede problemi anche nell’apprendimento del linguaggio scritto, in quanto esso è abituato ad utilizzare un linguaggio dei segni che ha una struttura grammaticale completamente differente. I disturbi cognitivi sono molto vari e vanno da quelli che sono presenti alla nascita (come la sindrome di Down, ritardi mentali e paralisi celebrali), a quelli che vengono acquisiti a causa di una qualche lesione celebrale traumatica o malattia, oppure quelli che emergono attraverso il normale processo di invecchiamento (come il morbo di Alzheimer). Solo negli Stati Uniti, si stima che 4,32 milioni di persone hanno ritardo mentale o una disabilità dello sviluppo e circa 7 milioni di persone hanno avuto la malattia di Alzheimer nel 2015, questo numero è destinato a crescere a 14 milioni entro il 2050. Quindi c’è un numero significativo di individui che potrebbe beneficiare di tecnologie assistive. La maggior parte delle persone che hanno disabilità mentali rimangono disoccupati e raramente hanno accesso appropriato a servizi per la comunità, venendo socialmente isolati. La difficoltà di orientarsi e potersi muovere liberamente all’interno di spazi pubblici o privati, per alcuni individui, ostacola non poco la qualità della vita. Vengono così in aiuto le tecnologie di orientamento per utenti con questi tipi di problemi, che vogliono e necessitano di muoversi attraverso ambienti per lavoro, acquisti, socializzazione, terapia e molto altro, aumentando così la loro indipendenza. I nuovi sistemi di guida personale basati sulla lettura e l’apprendimento di mappe geografiche aiuta in modo sicuro ed efficace la navigazione, migliorando così la qualità della vita senza grosse spese o disagi che possono creare dei servizi di assistenza speciali. Sulla base di modelli psicologici della navigazione spaziale, un individuo che possiede uno smarphone è guidato da alcune foto, che mostrano le direzioni quando si imposta un determinato viaggio. Ad ogni waypoint dunque l’utente verrà continuamente aggiornato con immagini, prese da un archivio come ad esempio quello di Google Maps Street View, e ad esse verranno sovrapposte immagini di frecce che fanno seguire la navigazione. Chiaramente questo tipo di tecnologia necessità di una base dati che fornisca le fotografie di ogni singola zona della mappa terrestre, sia
24 Capitolo 1: Accessible web e accessible map
esterna, sia per edifici pubblici che vorranno entrare a far parte di questa soluzione. Il motivo principale per cui sono state scelte le fotografie, a discapito di istruzioni vocali e testo in questo tipo di supporto, è l’affinità alla quale questo gruppo di utenti tende per natura; ad esempio un utente che soffre di schizofrenia potrebbe ottenere facilmente disturbi con indicazioni verbali. Per aumentare il senso di sicurezza e aiutare con misure di precauzione, una interfaccia di monitoraggio può essere inclusa nel sistema, in modo tale che un personale autorizzato possa osservare la giusta direzione di un individuo durante l’uso dell’applicativo. Le funzioni di monitoraggio registrano l’identificativo della persona, la posizione che è stata visitata e il tempo che è trascorso dopo che è stata lasciato l’ultimo waypoint, con inoltre il relativo orario di arrivo per il waypoint successivo. Nel caso in cui si possano verificare delle anomalie, come ad esempio un mancato raggiungimento del waypoint, o un tempo troppo prolungato tra due waypoint, un team di supporto o la famiglia può assicurarsi se tutto sta andando bene raggiungendo l’utente sul posto. Prototipi di questo tipo, sono al momento in fase di sviluppo con lo scopo di permettere ai singoli di condurre una vita più indipendente, facendoli diventare capaci di viaggiare, orientati dai comuni segnali satellitari [CHA15].
1.3 Web 3.0 e Geoweb Nel Maggio del 2006 Tim Berners-Lee affermava: “Le persone si continuano a chiedere cos'è il Web 3.0. Penso che, forse, quando si sarà ottenuta una sovrapposizione della Grafica Vettoriale Scalabile - oggi tutto appare poco nitido, con pieghe ed increspature - nel Web 2.0, e l'accesso ad un Web semantico integrato attraverso un grosso quantitativo di dati, si potrà ottenere l'accesso ad un'incredibile risorsa di dati” [TBLEE]. Il termine Web 3.0 oggi a volte è utilizzato come sinonimo di Web Semantico, termine coniato per intendere la trasformazione del Word Wide Web in un ambiente dove i documenti pubblicati (come pagine HTML, file, immagini e tanto altro) sono associati ad informazioni e dati (metadati) che ne specificano il contesto semantico in un formato adatto all’interrogazione, l’interpretazione e all’elaborazione automatica. Con l'interpretazione del contenuto dei documenti che il Web semantico impone, saranno possibili ricerche molto più evolute delle attuali, basate sulla presenza nel documento di parole chiave, e altre operazioni specialistiche come la costruzione di
25 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
reti di relazioni e connessioni tra documenti secondo logiche più elaborate del semplice collegamento ipertestuale. Nell'agosto 2007, l'agenzia digitale brasiliana CUBO ha definito il web 3.0 come l'abilità per i clienti di comunicare con le aziende, sia in maniera diretta utilizzando blog e altre applicazioni web 2.0, che in maniera indiretta, come se fossimo i possessori di dati psicografici analizzati dal web semantico e da altri strumenti di marketing come Microtargeting e Silent Marketing. Il termine web 3.0 è diventata una materia di crescente interesse e dibattito a partire dalla fine del 2006 sino a 2007. Le tecnologie web 3.0, come ad esempio un software intelligente che utilizza dati semantici, sono state implementate ed usate su piccola scala da molteplici aziende con l'intento di manipolare i dati più efficientemente. Negli anni recenti, tuttavia, ci si è concentrati anche nel fornire tecnologie web semantiche al pubblico generico. Alcune start-up come Garlik, Metaweb, Radar Networks e Powerset sono fra quelle che nel 2006-2007 hanno ricevuto un'ampia copertura mediatica relativamente al campo dell'innovazione. Il primo passo verso un Web 3.0 è l'emergere del Data Web visto che gli archivi di dati strutturati sono pubblicati sul web in formati riutilizzabili e "interrogabili" da remoto, come XML, RDF e microformati. La recente crescita della tecnologia SPARQL fornisce un linguaggio di query standardizzato e l'API per la ricerca attraverso database RDF distribuiti nel web. I Data Web permettono un nuovo livello di integrazione e di interoperabilità delle applicazioni, rendendo i dati disponibili a tutti e "linkabili" come se fossero pagine web. Il data web è il primo passo verso il vero e proprio web semantico. Nella fase di data web l'attenzione è principalmente rivolta verso la strutturazione di dati disponibili utilizzando l'RDF. Nella fase successiva di web semantico il raggio verrà ampliato in modo che sia i dati strutturati che quelli che tradizionalmente sono considerati contenuti non strutturati o semi strutturati saranno disponibili in larga misura in formati semantici RDF ed OWL. Il web 3.0 è stato anche utilizzato per descrivere un percorso evolutivo per il web che conduce all'Intelligenza Artificiale capace di interagire con il web in modo quasi umano. Alcuni scettici credono invece che ciò sia impossibile da raggiungere. Nonostante ciò, aziende come IBM e Google stanno implementando nuove tecnologie che stanno ottenendo informazioni sorprendenti come prevedere le canzoni più scaricate, attraverso il data mining, sui siti web universitari. L'archiviazione e lo studio
26 Capitolo 1: Accessible web e accessible map
delle informazioni che riguardano l'interesse espresso durante la navigazione da parte di un software evoluto oppure la possibilità di trasferire sensazioni, esigenze, gusti e comportamenti, nel campo medico, metterebbero le macchine nelle condizioni di poter assistere e contemporaneamente supportare coloro che per problemi di salute non possono essere autosufficienti. C'è anche un altro dibattito sul fatto che la forza trainante dietro il web 3.0 saranno i sistemi intelligenti oppure se l'intelligenza verrà fuori in maniera più organica, da sistemi di persone intelligenti, come per esempio attraverso servizi di filtraggio collaborativo come del.icio.us, Flickr e Digg che estraggono il significato e l'ordine dal web esistente ed il come le persone vi interagiscono. In linea con l’intelligenza artificiale, il web 3.0 potrebbe costituire la realizzazione e l'estensione del concetto di web semantico. I ricercatori accademici stanno lavorando per sviluppare un software per il ragionamento, basato sulla logica descrittiva e sugli agenti intelligenti. Tali applicazioni possono compiere operazioni di ragionamento logico utilizzando una serie di regole che esprimano una relazione logica tra i concetti ed i dati sul web. Sramana Mitra sostiene invece che il web semantico potrebbe essere l'essenza della prossima generazione dell'Internet e propone una formula per incapsulare il web 3.0 [SRAM]. Il web 3.0 è stato anche messo in relazione ad una possibile convergenza di un'architettura service-oriented e del web semantico. Nasce dunque anche un nuovo concetto di geolocalizzazione, legato alla rappresentazione di mappe geografiche in seguito ad un innumerevole quantitativo di informazioni presenti sul web nei tempi moderni. Il GeoWeb è un nuovo termine che indica la fusione di informazioni geografiche con le informazioni astratte. L’interesse per il GeoWeb è stato avanzato dalle nuove tecnologie come Google Earth, Google Maps, NASA World Wind etc ed è l'ispirazione per portare il GIS (Graphical Information System) sul Web. Il GIS è stata la base per professionisti, governi e comuni per gestire le informazioni del territorio. GeoWeb propone di portare questa possibilità nel Web con la creazione e lo sviluppo di ambienti digitali, simili alla realtà virtuale. In linea teorica dovrebbe avere effetti positivi sulla comprensione del mondo e dei suoi processi, permettendoci di migliorare la gestione delle risorse naturali ed i servizi. Il concetto si accosta a quello che è stato definito Digital Earth (Terra Digitale). Il Web 3.0 sicuramente non è un punto di arrivo, ma è lo sviluppo naturale di dieci anni di internet, nato con Web 1.0 con i modem a 56Kbps e pagine statiche, Web
27 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
2.0 con le prime linee veloci ed i primi siti dinamici con i quali gli utenti potevano scambiare ed organizzare i siti, fino al Web 3.0 dove tutto sarebbe fruibile da qualsiasi punto di accesso [WIKISW].
1.3.1 Globo virtuale Un Globo virtuale è un modello software 3D o una rappresentazione della Terra o di un altro mondo. Un globo virtuale fornisce all'utente di muoversi liberamente nell'ambiente virtuale cambiandone l'angolo di visuale e la posizione. Confrontato ad un globo convenzionale, i globi virtuali hanno la capacità addizionale di rappresentare molte visioni differenti sulla superficie della Terra. Queste visualizzazioni possono riguardare elementi geografici, elementi costruiti dall'uomo, o rappresentazioni astratte di quantità demografiche come la popolazione. Il 20 novembre 1997 Microsoft ha rilasciato il famoso Globo virtuale di Encarta Virtual Globe 98, seguito da Cosmi's 3D World Atlas in 1999. Il primo globo virtuale su internet è stato NASA World Wind rilasciato a metà del 2004, seguito nell’anno successivo da Google Earth e successivamente da Live Search Maps, Yahoo Maps e OpenStreetMap. I globi virtuali sono utilizzati per studi o navigazione, connessi ad un supporto GPS, e la loro progettazione varia notevolmente in base al loro scopo. Coloro che desiderano ritrarre una rappresentazione visiva accurata della Terra spesso utilizzano dei server di immagini satellitari che sono in grado non solo di ruotare, ma anche ingrandire e talvolta modificare l’orizzonte. Molto spesso tali globi virtuali mirano a fornire una rappresentazione del mondo con un livello molto dettagliato. L’interfaccia ha spesso la possibilità di fornire in overlay dei grafici semplificati per evidenziare le caratteristiche poiché questi non sono a volte evidenti da una fotografia aerea. Una questione fondamentale sollevata dalla facile disponibilità di un tale dettaglio di informazioni è quella legata alla sicurezza; alcuni governi hanno sollevato forti preoccupazioni mira la facilità di accesso alle viste di luoghi sensibili come aeroporti e basi militari [WIKVG].
1.3.1.1 Modello digitale di elevazione Un modello digitale di elevazione, anche noto come Digital Elevation Model (DEM) è la rappresentazione della distribuzione delle quote di un territorio, o di un'altra superficie, in formato digitale. Il modello digitale di elevazione viene in genere
28 Capitolo 1: Accessible web e accessible map
prodotto in formato raster associando a ciascun pixel l'attributo relativo alla quota assoluta. Il DEM può essere prodotto con tecniche diverse. I modelli più raffinati sono in genere realizzati attraverso tecniche di telerilevamento che prevedono l'elaborazione di dati acquisiti attraverso un sensore montato su un satellite, un aeromobile o una stazione a terra. Ad esempio, analizzando il segnale di fase registrato da un Radar ad Apertura Sintetica (Synthetic Aperture Radar, SAR) installato su un satellite, è possibile produrre un modello digitale di elevazione. I DEM possono essere impiegati in un sistema informativo geografico GIS per produrre nuovi dati, ad esempio: carte di acclività o di orientazione del versante, carte di visibilità da un punto etc. Tutti questi prodotti, se impiegati in un ambiente GIS, hanno numerose applicazioni dello studio del territorio con particolare riguardo alle indagini per la mitigazione dei rischi naturali. Il modello digitale del terreno Digital Terrain Model (DTM), a differenza del DEM, è ottenuto dall'interpolazione delle curve di livello. Esso è spesso confuso con il DEM e la principale differenza tra i due modelli risiede nel fatto che il DEM tiene conto di tutti gli oggetti insistenti sul terreno (vegetazione, edifici ed altri manufatti) mentre il DTM riproduce l'andamento della superficie geodetica. La differenza tra i due modelli è più evidente in zone urbanizzate dove prevalgono edifici molto alti, quali ad esempio l'isola di Manhattan o quella di Hong Kong [GES99].
1.3.2 Recupero delle informazioni geografiche Il Geographic Information Retrieval o anche Geographical Information Retrieval (GIR) è il recupero di tutte quel tipo di informazioni geografiche necessarie che mirano a risolvere tutte le cosiddette query testuali che includono una dimensione geografica, come ad esempio “dove posso trovare un ristorante a Milano centrale?” oppure “dove trovo l’ingresso più vicino della metropolitana di Londra?”. GIR estrae e trova il significato di un testo non strutturato traducendolo in informazioni geografiche. Dopo che si sono indentificati i riferimenti di posizione sotto forma di testo, viene fatta una ricerca e un recupero dei dati. Questo processo è denominato Geoparsing, e può fare anche riferimenti della posizione con altre forme di media, come ad esempio contenuti audio. Con le coordinate geografiche le caratteristiche possono essere mappate. Vengono fatte dunque due usi primari delle coordinate geografiche derivate dai contenuti non strutturati; sono utilizzate per tracciare parti del contenuto su mappe e per cercare il contenuto utilizzando la mappa stessa [ADA15].
29 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
Il Geoparsing va oltre al Geocoding. Il Geocoding infatti analizza i riferimenti di localizzazione strutturati, come indirizzi postali e coordinate numeriche, rigorosamente formattate. Il Geoparsing invece gestisce riferimenti ambigui in un discorso o frase non strutturata. Il Geoparser è a tutti gli effetti un servizio web che aiuta il processo di ricerca, soprattutto per l’aumento di una accessibilità di ricerca dei dati in maniera notevole.
1.3.3 Sistema di gestione dei contenuti geospaziali In informatica un Content Management System, in acronimo CMS (in italiano sistema di gestione dei contenuti), è uno strumento software, installato su un server web, il cui compito è facilitare la gestione dei contenuti di siti web, svincolando il webmaster da conoscenze tecniche specifiche di programmazione web. Un Geospatial Content Management System (GeoCMS) è un CMS dove gli oggetti contenuti al suo interno (video, immagini, articoli, blog, ecc..) possono avere una latitudine e longitudine tale da poter essere rappresentati su una mappa interattiva. Alcuni GeoCMS consentono agli utenti anche di modificare i dati spaziali, come linee, punti o poligoni sulle mappe, come parte degli oggetti del contenuto. I dati spaziali possono essere pubblicati come parte dei loro contenuti o essere utilizzati nelle interfacce standardizzate. Questo tipo particolare di CMS può avere una mappa di utenti registrati che permette di costruire un a comunità geografica, semplicemente osservando la posizione degli utenti stessi. Dopo l’avvento di Google Maps e la pubblicazione delle sue API, numerosi utenti hanno utilizzato le mappe online per illustrare le loro pagine web, nonostante Maps di Google non sia in sè un GeoCMS. Nel 2003 TikiWiki vanta di essere il primo CMS open source a diventare un GeoCMS [TIK03].
30 Capitolo 2: Tecnologie utilizzate
2 Tecnologie utilizzate
Questo capitolo descrive le tecnologie che sono coinvolte ed utilizzate all’interno del progetto svolto. In primo luogo viene spiegato il funzionamento di Open Street Map, e degli elementi che lo compongono, in quanto, i suoi dati e le sue preziose informazioni open source, sono alla base del sistema di Open Trip Planner. È quindi rivolta attenzione all’architettura di Open Trip Planner, ai suoi algoritmi di routing e alla sua sicurezza nei confronti della rete informatica. Nell’ultimo punto vengono trattati i linguaggi, i markup e gli stumenti che sono utilizzati da Open Trip Planner ed hanno reso possibile lo sviluppo del progetto, come Java, HTML, CSS, il DOM, il software di rendering Mapnik.
2.1 Open Street Map Open Street Map (OSM) è un progetto che punta a creare e rendere disponibili i dati cartografici, in maniera gratuita e senza utilizzo di licenza, a chiunque ne abbia bisogno. Il progetto, nato nel 2004, è stato lanciato perché la gran parte delle mappe che normalmente si pensano libere da licenza, hanno, in realtà restrizioni legali o tecniche, impedendo quindi alle persone il loro uso per scopi produttivi, creativi. Open Street Map raccoglie a livello globale dati di strade, ferrovie, fiumi, foreste, edifici e tutto ciò che normalmente si trova su delle mappe, detenendone i diritti, in quanto i dati vengono manualmente rilevati dai singoli volontari al progetto. La caratteristica fondamentale dei dati geografici presenti in Open Street Map è che possiedono una licenza libera, la Open Database License [OSMLIC], è cioè possibile utilizzarli liberamente per qualsiasi scopo con il solo vincolo di citare la fonte e usare la stessa licenza per eventuali lavori derivati dai dati di OSM. [OSMIT].
31 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
Al giorno d’oggi è difficile ottenere le geoinformazioni gratuitamente, e chi ha bisogno di una mappa per la sua pagina web o opera stampata, lo può fare soltanto comprandosi una licenza d’uso per cartografia proprietaria. Anche nell’ambito dell’insegnamento e la ricerca possono esserci casi in cui si debba pagare per utilizzare dei dati proprietari, oppure durante l’acquisto di un navigatore parte significante del prezzo è per le mappe digitali fornite con esso. Open Street Map interrompe la dipendenza da fornitori di dati proprietari e contrappone al puro consumo un’attività creativa. Tramite la collaborazione dei membri della comunità si crea un database di geodati liberi e disponibile globalmente a tutte le persone [OSMIT]. Una grande differenza la si può notare ad esempio nei confronti ai dati che offre Google Maps [GOOM]. Anche se l’uso delle mappe di Google (come quella di tanti altri fornitori) è gratuita, l’utente nel suo uso non è libero. Anche Google richiede infatti di attenersi ad alcune linee guida specifiche per poter utilizzare le proprie mappe. Di regola le mappe che si trovano in Internet sono legate all’uso delle pagine web o alle API del fornitore e il semplice atto di stampare una mappa spesso non è consentito. Google inoltre mette a disposizione delle mappe, però non i geodati su cui si basano. Quindi si possono utilizzare queste mappe solo nella maniera in cui vengono offerte. Se si intende di utilizzare le mappe in un altro stile o di provare un proprio algoritmo di routing, quelle mappe non possono essere usate. Open Street Map invece offre anche i dati grezzi, per consentire a chiunque di utilizzarli a proprio piacimento [OSMIT].
2.1.1 Il progetto Creato da Steve Coast nel Regno Unito, Open Street Planner è stato ispirato dal successo di Wikipedia e la preponderanza di dati cartografici di proprietà del Regno Unito e il resto del mondo. Dalla sua partenza il progetto è cresciuto fino a superare i 2 milioni di utenti registrati, che possono raccogliere i dati utilizzando dei rilevamenti manuali, dispositivi GPS, fotografia aerea o altre tipologie di fonti. Questi dati vengono poi archiviati e messi a disposizione nell’ambito della Open Database Licence, supportato dalla fondazione di Open Street Map [WIKOSM]. Piuttosto che la mappa stessa, i dati generati dal progetto di Open Street Map sono considerati la parte primaria. Infatti sono disponibili per l’uso di applicazioni comuni come Craigslist [CRA], Open Trip Planner, OsmAnd [OSMAND], e perfino per sostituire i dati di Google Maps in Foursquare [FOUR].
32 Capitolo 2: Tecnologie utilizzate
Steve Coast ha fondato il progetto di Open Street Map nel 2004 e si è concentrato inizialmente sulla mappatura del Regno Unito. Dopo due anni è stata istituita la fondazione di Open Street Map per favorire la crescita, lo sviluppo e la distribuzione di dati geospaziali liberi, fornendo a chiunque l’utilizzo e la condivisione. Nel Dicembre del 2006 Yahoo! ha confermato che le fotografie aeree di Open Street Map sarebbero state utili per la produzione delle mappe del proprio sito web. L’anno seguente la Automotive Navigation Data ha donato un set completo di dati stradali dei Paesi Bassi, una mappa completa di strade per la viabilità di camion riguardanti la Cina e l’India, facendo cosi diventare l’Università di Oxford la prima grande organizzazione ad utilizzare i dati di Open Street Map. Con il passare degli anni e l’aumento dei prezzi di servizio di Google Maps, ha portato molti siti web ad abbandonare Google e adottare il database di Open Street Map come base per le proprie mappe; tra i più famosi Apple, che dopo aver terminato il contratto con Google Maps ha deciso di svillupare la propria applicazione Maps che utilizza un ibrido di dati appunto tra Open Street Map e TomTom [WIKOSM].
2.1.2 La raccolta dati Principalmente la raccolta dei dati per Open Street Map consiste nella raccolta di geodati rilevati mediante una unità palmare GPS, un notebook, macchina fotografica digitale, o un registratore vocale. I dati vengono poi inseriti nel database di OSM. Più di recente, la disponibilità di fotografia aerea e di altri dati provenienti da fonti commerciali e di governo ha aggiunto importanti fonti di dati, sia per l'editing manuale e le importazioni automatizzati. Alcuni processi sono in atto per gestire le importazioni automatizzati e evitare problemi legali e tecnici. Per il progetto anche il piccolo aiuto è molto prezioso, come ad esempio la familiarità di alcune zone conosciute molto bene o la scoperta di errori e imprecisioni già presenti all’interno della mappa. Di fondamentale importanza è inoltre la mancanza di copyright, infatti i dati che possono essere immessi in OSM non devono essere sotto copyright, escludendo quindi il tracing da servizi come Google Maps e l’uso di mappe preesistenti [OSMFL]. Per immettere i dati, indipendentemente da come siano stati raccolti, è necessario un editor, che permette di scaricare mappe, modificare e aggiungere informazioni, e trasmettere le modifiche a OSM. A questo proposito OSM offre un’API che offre le varie funzionalità di fetching e salvataggio dei dati geografici da e verso
33 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
OSM, permettendo agli utenti registrati di eseguire il proprio lavoro, aggiungendo o modificando elementi e “taggandoli” in modo opportuno. La presenza di un’API anch’essa open source ha permesso a molti programmi di sfruttarla per gestire i dati di OSM, su molteplici piattaforme, siano esse mobile, desktop o web based, e in molteplici linguaggi. Il principale editor è iD realizzato in JavaScript incorporato nel sito web di OSM, che permette di attuare modifiche direttamente da browser, richiedendo solo un login all’account di OSM [OSMID]. Una iniziativa che favorisce anche le relazioni sociali è stata intrapresa dall’associazione di OSM e consiste nell’organizzazione di Mapping Weekend o Mapping Party [OSMIT]. Infatti per evitare di svolgere l’attività in solitaria, OSM favorisce la creazione di questi incontri, che tipicamente si svolgono durante il fine settimana. Si prefigge una zona quale viene poi spartita in singole aree. Queste vanno rilevate sistematicamente dai partecipanti. In qualche posto si crea una postazione di base, per esempio in un bar con accesso ad internet o negli spazi di un impresa dove poi si possono inserire insieme i dati. I Mapping Parties sono ideali per conoscere altri mappatori della comunità, e ai principianti si offre la possibilità di superare i primi ostacoli insieme a dei mappatori esperti. Come tutto nel ambito di OSM non esiste un organizzazione centrale di questi mapping parties, chiunque può avviarne una, coordinando l’incontro mediante il wiki e la mailing list di OpenStreetMap [OSMIT].
2.1.3 Gli elementi di Open Street Map L’intera mappa di OSM è costruita da alcuni elementi fondamentali che creano il modello concettuale del mondo fisico in cui viviamo. Essi si possono suddividere principalmente in tre categorie: nodi, vie e relazioni. Ognuna delle tre categorie può essere associata ad un tag che descrive il significato di un particolare elemento [OSMEL].
2.1.3.1 Nodi Un nodo è uno degli elementi fondamentali del modello di dati di Open Street Map. È costituito da un singolo punto nello spazio definito dalla sua latitudine, longitudine, altitudine e id. I nodi possono essere utilizzati per definire le caratteristiche del singolo punto, ma sono spesso utilizzati per definire la forma o il
34 Capitolo 2: Tecnologie utilizzate
percorso di una determinata via. Esistono oltre 2.750.000.000 nodi nel data set di OSM (rilevati a Giugno 2015) [OSMN]. I nodi descrivono i punti di interesse della realtà attraverso l’uso di tag, come ad esempio il tag di una cabina del telefono è espressa come amenity=telephone oppure possono essere usati come operator=* [OSMN]. Molti nodi vanno a comporre più nodi che definiscono la forma o il sentiero di una determinata via. Infatti se due o più vie si incrociano sulla stessa altitudine, esse condividono lo stesso nodo nell’incrocio, e possiedono il tag layer=* per identificare l’altitudine e l’elevazione di ciascuna via [OSMN]. Alcuni esempi di tag sono i seguenti: • highway=crossing+crossing=* per definire un’attraversamento pedonale lungo una highway=* • natural=tree per identificare un singolo albero su barrier=hedge building=entrance per identificare una entrata dentro un building=*
2.1.3.2 Vie Le liste ordinate di nodi sono definite vie. Le vie sono contenute in un numero variabile che rientra tra 2 e 2000, e possono essere abbinate ad un tag oppure inserite in una relazione. Una singola via può essere aperta o chiusa, dipendendo dall’apertura del primo e ultimo nodo, se chiusi o aperti rispettivamente. Una strada, il corso di un fiume o una linea ferroviaria ad esempio sono vie aperte con una feature lineare [OSMW]. In OSM sono descritte principalmente due tipi di vie, aperte e chiuse. Le strade chiuse a sua volta possono esse utilizzate per altre due tipologie, la polilinea chiusa (una via aperta che si richiude in se stessa, come ad esempio una rotatoria o una cancellata) e l’area (qualsiasi tipo di terreno chiuso, privato e non). Esistono inoltre altri casi in cui si possono unire i due concetti di polilinea chiusa e area (come ad esempio una rotatoria con aiuola al suo centro) [OSMW].
2.1.3.3 Relazioni Esistono molteplici tipi di relazioni, e tutte consistono in insiemi di nodi, vie o altri tag utilizzati per descrivere aree geografiche o relazioni logiche tra due o più elementi. I principali tipi di relazioni sono la restrizione, che indica quale tipo di senso è vietato nell’attraversamento di un incrocio (composta dalle vie da considerare, dal
35 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
nodo incrocio e dal rispettivo tag); l’itinerario, che enumera le vie che compongono un passaggio di trasporto, come piste ciclabili, strade statali, corse di autobus e rotte navali (composta da vie, e nodi nel caso di corse di autobus); il multipoligono, che rappresenta aree complesse, come ad esempi cortili all’interno di un edificio (sono composte da un cerchio esterno, costituito da una via chiusa, e da più cerchi interni di vie chiuse) [OSMR].
2.1.3.4 Tag Tutti i tipi di dati (nodi, vie e relazioni) possono avere un tag. I tag descrivono il significato dei particolari elementi ai quali sono affiancati. Un tag consiste di una chiave e un valore, key=value entrambi stringhe unicode con una lunghezza massima di 255 caratteri con formato libero senza valori predefiniti [OSMT]. La chiave descrive un’ampia classe di funzioni, come ad esempio autostrade o nomi propri. Il valore descrive la caratteristica che è generalmente classificata dalla chiave (come ad esempio highway=motorway). Se si necessita di più valori, serve separare con una virgola i vari valori [OSMT]. Ecco alcuni esempi di tag: • highway=residentrial per definire una strada residenziale. • name=Park Avenue per identificare il nome di un determinato parco. • maxspeed=50 per identificare il valore numerico della velocità massima acconsentita. Esistono alcune risorse per trovare un tag, come ad esempio la lista di Map Features [OSMMFT] messa a disposizione dal wiki di OSM. Ad ogni modo la comunità di OSM è libera di modificare o creare nuovi tag in base all’utilizzo, creando anche a volte alcune ambiguità su tag simili, i quali però rispecchiano le molteplici realta del mapping del mondo [OSMT].
2.1.4 Disabilità e Open Street Map Sarebbe perfetto se tutte le informazioni di OpenStreetMap potessero essere accessibili anche a utenti con handicap. OpenStreetMap al momento offre una soluzione solamente per utenti ciechi o ipovedenti [OSMDIS].
36 Capitolo 2: Tecnologie utilizzate
2.1.4.1 Hapto Render Hapto Render è progettato per creare render direttamente dai dati di Open Street Map, in modo da poter creare mappe tattili per ciechi e ipovedenti [OSMHR]. Ci sono alcuni vantaggi principali che Hapto Render crea rispetto alle comuni mappe tattili commerciali: • Per prima cosa le mappe possono essere create per qualsiasi paese del mondo, non solo per i comuni punti di interesse per turisti come centri storici. • Le mappe possono essere create da geodati aggiornati continuamente e non una singola edizione che dura per più anni. • Le mappe create possono essere varie, con più tipologie di contrasto, adatte ad ogni singolo utente in base alla necessità. • Libertà dalla licenza per i dati della mappa, quindi un costo minore di produzione. • Nel caso una parte della mappa sia obsoleta, può essere riprodotta solo la parte necessaria, senza ricreare tutto da zero.
Il progetto, avviato nel 2009 da Lulu-Ann [LULUA] è stato successivamente sviluppato grazie all’aiuto del famoso utente di wikipedia Bahnpirat [BAHNWK] e dai membri del Hannover Stammtish [HANSTA]. Al momento esistono due tipologie di produzione di mappe tattili dai dati di OSM: automatizzata, con l’utilizzo di stampanti 3D o braille, o manuale. I principali tag per la creazione di queste mappe sono tactile_paving=yes/no, information=tactile_map, school=blind [OSMHR].
2.1.4.2 Loro Dux Anche il progetto di Loro Dux [OSMLD] è stato avviato nel Maggio del 2009 da Lulu-Ann [LULUA]. L’etimologia del progetto deriva da “Loro” che è la parola spagnola che indica il pappagallo, e “Dux” e la parola latina che indica guida, da qui “guida che parla dalla tua spalla”. Esso è stato progettato per essere incluso in Open Street Map nei dispositivi mobile, sviluppato con codice Java per utenti ciechi e ipovedenti [OSMLD].
37 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
La prima fase del progetto è stato quello di raccogliere i requisiti; il risultato è un documento che può essere letto da qualunque programmatore per lo sviluppo del software. Nel Settembre del 2010 è stata rilasciata la prima versione del software, successivamente abbandonata in quanto JavaME non è più una piattaforma sul quale investire. Al momento quindi il progetto è bloccato in attesa di sviluppatori e collaboratori che portino avanti il progetto con strade alternative [OSMLD].
2.2 Open Trip Planner Open Trip Planner (OTP) è una piattaforma open source per la pianificazione dei viaggi e analisi multimodale della rete di trasporto [OTP]. Esso fornisce sia un interfaccia web sia una interfaccia di programmazione di applicazione (API) per applicazioni di terze parti, consentendo agli utenti di cercare itinerari per perdoni, bici, trasporti pubblici e auto. OTP si basa su tipologie di dati pubblici, in particolare per quel che riguarda l’orario di mezzi di trasporto pubblici ricava i suoi dati da General Transit Feed Specification [GTFS], mentre per quel che riguarda le informazioni riguardanti le informazioni stradali, il posizionamento real time di veicoli e del traffico utilizza i dati di Open Street Map [WIKOSM]. OTP segue un modello client-server con diverse interfacce web basate su mappe incluse ed espone una REST API che può essere utilizzata da applicazioni di terze parti. Lanciato nel 2009, il progetto ha attirato una fiorente comunità di utenti e sviluppatori. Ha ricevuto numerosi investimenti da enti pubblici, startup e da consulenti di trasporto. Originariamente il progetto era sostenuto dall’agenzia TriMet [TRIM] della città di Portland, OR, che con un fondo statale per il miglioramento della qualità dei trasporti, nel 2009 riunì le maggiori agenzie di trasporti e gli autori dei maggiori software per il trasporto di passeggeri: David Emory di FivePoints, Brian Ferris di OneBusAway, e Brandon Martin-Anderson di GraphServer [OTP]. Nel 2013 il software, cresciuto enormemente, diventa il software primario per il routing di TriMet, nello specifico per la città di Portland. Nello stesso anno il progetto OTP è stato accettato come membro del Software Freedom Conservancy, una organizzazione non profit con lo scopo di promuovere, migliorare e gestire i progetti open source [OTP]. Ad oggi Open Trip Planner è utilizzato nel dipartimento dei trasporti di New York, gestendo il suo servizio di itinerari e offrendo percorsi multimodali in tutto il suo
38 Capitolo 2: Tecnologie utilizzate
stato. Anche in Europa Open Trip Planner viene utilizzato in numerose città, compresa Valencia, in Spagna e Rennes, in Francia. In Italia, una iniziativa chiamata CampusCity Project e promossa dall’Università di Trento, ha incoraggiato le iniziative smart nella città, creando app come ViaggiaTrento [VGT] e ViaggiaRovereto [VGR] che utilizzano OTP. Open Trip Planner è ora arrivata alla sua versione 0.19.0, includendo tantissime caratteristiche, tra le quali: • Pianificare itinerari che possono avere molteplici tipologie di trasporto, come camminare o andare in bicicletta per poi salire su autobus i tram. • Una notevole capacità di personalizzare il proprio itinerario, con criteri quali il numero delle coincidenze da prendere e la distanza massima tra fermate, le preferenze per i tragitti in bicicletta, calcolandola preferenza tra velocità e sicurezza, con la possibilità di combinare i tre parametri. Attivare o disattivare il bike-sharing, e infine scegliere se il percorso deve essere accessibile per utenti con disabilità motorie. • Importare dati da GTFS di Open Street Map e da modelli di elevazione digitale. • Espone una API dei servizi web che altre applicazioni o front-end possono costruire. • Supporta le ricerche uno-a-molti e molti-a-molti per la pianificazione e l’analisi delle alternative per scopi di ricerca di accessibilità. • Supporta GTFS-in tempo reale per le modifiche di servizio e avvisi sia polling (pull) e in streaming (modalità push).
2.2.1 Architettura Al centro di Open Trip Planner c’è una libreria di codice Java che trova i percorsi efficienti attraverso reti di trasporto multimodali costruiti a partire dai dati ricavati di Open Street Map [OTP] e dai Generalized Transit Feed Specification (GTFS) [GTFS]. Alcuni servizi sono stati costruiti a partire da questa libreria. Il Routing API di OTP è un servizio web RESTful che risponde alle richieste di pianificazione di viaggio con itinerari rappresentati in JSON o XML. È possibile combinare questa API con front-end standard in JavaScript di OTP per fornire agli utenti funzionalità di pianificazione del viaggio in una interfaccia di mappa familiare,
39 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
oppure scrivere le proprie applicazione che dialogano direttamente con l’API. Una ulteriore API di OTP, chiamata Transit Index, è un altro servizio web RESTful che fornisce informazioni derivate dagli aggiornamenti di GTFS. Per esempio vengono inclusi percorsi che servono per alcune particolari fermate che possono essere effettuate durante un viaggio [OTPARC]. Il progetto di Open Trip Planner ha coniato il termine “OTP Analyst” riferendosi alle parti di OTP che applicano il motore di routing all’analisi della rete di viaggio e la pianificazione dei viaggi end-to-end [OTPALS]. Il servizio web OTP Analyst fornisce i risultati dell’analisi di viaggio, come il tempo di percorrenza dei tragitti e le mappe isocrone. I servizi web da cui è composta sono concettualmente separati dalle API di routing, ma sono forniti dalla stessa serlvet. OTP fornisce inoltre un Batch Process Manager che gestisce più compiti di analisi di viaggio. Viene utilizzata la stessa libreria di instradamento e gli stessi dati degli altri servizi di OTP, ma viene attuata una configurazione che tiene conto dei dati in tempo reale degli spostamenti delle persone. Questo è uno strumento molto potente, soprattutto per visualizzare come i viaggi e i gli spostamenti della popolazione possono modificarsi all’interno della città. Un caso di studio è stato proprio negli spostamenti della popolazione nella città di New York durante il passaggio dell’uragano Sandy nel 2012 [SAND12]. OTP utilizza i dati di Open Street Map, in estensione .osm. Questo tipo di file sono creati con il linguaggio markup XML. Utilizza anche i file di GTFS in estensione .zip, dove all’interno di esso ci sono vari file .txt formattati in maniera apposita [GTFS]. Questi file devono contenere, nella prima riga, i nomi dei campi, separati da virgola. I campi possono essere obbligatori (necessari per il file affinchè sia corretto) o facoltativi, e gli stessi file possono essere obbligatori (necessari affinchè il file GTFS contenga le informazioni fondamentali) e facoltativi. I file contenuti necessari, e il loro significato e contenuto, sono [GTFS]: • agency.txt: Contiene il nome delle agenzie di trasporti considerate, includendo informazioni come il nome e il telefono. • routes.txt: Identifica le linee di percorrenza dei mezzi pubblici. • stops.txt: Identifica le fermate. • trips.txt: Identifica la corsa di un mezzo pubblico in una linea di percorrenza.
40 Capitolo 2: Tecnologie utilizzate
• stop_times.txt: Tempo tra l’arrivo di un veicolo a una fermata e la sua ripartenza. • calendar.txt: Definisce gli orari di corse regolari, per ogni giorno della settimana. I file facoltativi permettono di aggiungere informazioni, e sono [GTFS]: • calendar_dates.txt: permette di definire orari di corse non regolari ed eccezioni alla normale schedula. • fare_attributes.txt: permette di definire i prezzi e le condizioni delle tariffe delle agenzie. • fare_rules.txt: definisce come sono assegnate le tariffe rispetto alle linee. • shapes.txt: informazioni per i render di mappe per visualizzare le linee. • frequencies.txt: Il tempo fra le corse in una stessa linea. • transfers.txt: regole per aiutare i planner multimodali nel comporre coincidenze fra più corse. • feed_info.txt: Informazioni sul feed di informazioni, chi lo fornisce, e fino a quanto è valido.
2.2.2 Creazione di percorsi Open Trip Planner impiega due diversi algoritmi per la gestione e creazione di percorsi: l’algoritmo A* e l’algoritmo contraction hierarchies. Appena creato OTP utilizzava l’algoritmo di Dijkstra e A* con una euristica euclidea, ma successivamente si è capito che questi tipi di algoritmi erano eseguiti molto lentamente su grafici di larga scala.
2.2.2.1 Algoritmo contraction hierarchies Recenti ricerche hanno dimostrato che una nuova tecnica di utilizzo dell’algoritmo, denominato contraction hierarchies, possa essere più performante per lavorare con grafi in grande scala [HIROU08]. L’idea alla base di questo algoritmo è che un grande grafo può essere contratto rimuovendo i vertici uno alla volta, sostituendo ogni cammino per il vertice rimosso, con una scorciatoia. Questo algoritmo è una tecnica per accelerare l’instradamento verso il cammino più breve, creando prima una versione precalcolata contratta del grafo. Contraction hierarchies è un estremo caso di approccio generalizzato, dove vengono generati dei nodi “multi-layered” in fase
41 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
di preelaborazione. Ogni nodo del grafo è rappresentato dal suo livello nella gerarchia. Questo può essere ottenuto in diversi modi, la via più semplice è di numerare ogni nodo da 1 a n. L’algoritmo può essere utilizzato per generare percorsi in maniera molto più efficiente rispetto all’algoritmo dei cammini minimi di Dijkstra. Esso inoltre è disponibile al pubblico in un software open source, aumentandone dunque la facilità d’uso [WIKCOHI].
2.2.2.2 Algoritmo A* L’algoritmo A* (pronunciato “A star”) è un algoritmo di ricerca su grafi che individua un percorso da un dato nodo iniziale verso un dato nodo goal (o che passi un test di goal dato). Utilizza una "stima euristica" che classifica ogni nodo attraverso una stima della strada migliore che passa attraverso tale nodo. Visita il nodo in base a tale stima euristica. L'algoritmo A* è anche un esempio di ricerca best-first. Esso è una estensione dell’algoritmo di Dijsktra per la ricerca del cammino più breve fra due nodi di un grafo [WIKAS]. Per sua natura di algoritmo generico di attraversamento grafi si presta a essere molto flessibile. OpenTripPlanner naturalmente lo include nell’algoritmo di pathfinding che utilizza, insieme a contraction hierarchies. A* comincia a partire dal nodo selezionato. Per ogni nodo è definito un costo di entrata (di solito zero per il nodo iniziale). A* allora valuta la distanza dal nodo meta a partire da quello corrente. Questa stima ed il costo assieme formano l'euristica che sarà assegnata al percorso passante per questo nodo. Il nodo è aggiunto allora a una lista, spesso chiamata "open". L'algoritmo allora rimuove il primo nodo dalla lista (perché avrà valore della funzione euristica più basso). Se la lista è vuota, non ci saranno percorsi dal nodo iniziale al nodo meta e l'algoritmo si arresterà. Se il nodo è il nodo meta, A* ricostruisce e pone in output il percorso ottenuto e si arresta. Questa ricostruzione del percorso a partire dai nodi più vicini significa che non è necessario memorizzare il percorso in ogni nodo. Se il nodo non è il nodo meta, nuovi nodi saranno creati per tutti i nodi vicini ammissibili; il modo di fare questo dipende dal problema. Per ciascun nodo successivo A* calcola il "costo" di entrata nel nodo e lo salva col nodo. Questo costo è calcolato dalla somma cumulativa dei pesi immagazzinati negli antenati, più il costo dell'operazione per raggiungere questo nuovo nodo. L'algoritmo gestisce anche una lista di "closed", un elenco di nodi che sono già stati controllati. Se un nuovo nodo generato è già nella lista con un costo uguale o più
42 Capitolo 2: Tecnologie utilizzate
basso, non ci sarà alcuna futura indagine su tale nodo o col percorso ad esso associato. Se un nodo nella lista di closed è uguale ad uno nuovo, ma è stato immagazzinato con un costo più alto, allora sarà rimosso dalla lista di closed, e il processo continuerà a partire dal nuovo nodo. Successivamente, una stima della distanza dal nodo nuovo alla meta è aggiunta al costo per formare il suo valore euristico. Tale nodo è aggiunto allora alla lista "open", a meno che non esista un nodo identico con valore euristico minore o uguale. L'algoritmo sarà adottato ad ogni nodo vicino, fatto ciò il nodo originale è preso dalla lista e posto nella lista di "closed". Il prossimo nodo sarà ottenuto dalla lista di open e con esso si ripeterà il processo descritto. Può essere verificato che A* non considera più nodi di qualunque altro algoritmo di ricerca ammissibile, a meno che l'algoritmo alternativo non abbia una stima euristica più accurata. In questo senso A* è l'algoritmo computazionalmente più efficiente che garantisce la ricerca del percorso più breve [WIKAS].
2.2.3 Sicurezza Open Trip Planner ha alcuni metodi web API che sono potenzialmente pericolosi. Ad esempio è possibile ordinare al server di Open Trip Planner di ricaricare tutti i grafi, oppure caricare dati come grafi stessi. L’accesso a questi metodi dovrebbe essere chiaramente limitato. OTP è configurato per permettere l’accesso a questi metodi API sensibili solo quando il richiedente dei dati è autenticato con una username e password attraverso una autenticazione base HTTP. Inoltre OTP accetta di default solo il protocollo HTTP non protetto, quindi le credenziali inviate sono completamente visibili e chiare. Il traffico generato e i dati inviati quindi sono visibili a chiunque, a meno che non venga utilizzato un canale sicuro come quello SSL/TSL che offre una crittografia alla comunicazione sul protocollo HTTPS [HTTPs]. Se si vuole accedere pertanto a questi metodi di OTP, è consigliato l’esecuzione di OTP su un server che supporti HTTPS o disattivare completamente l’autenticazione. Il server incorporato di OTP denominato Grizzly [GRLY] è configurato per accettare le connessioni HTTPS con protocollo TCP sulla porta 8081 come impostazione predefinita, ma l’ascoltato HTTPS necessita di una chiave di crittografia per stabilire la connessione. La chiave è posizionata in un “keystore”, un formato specifico per ambienti server Java [OTPSEC].
43 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
Di default in Open Trip Planner si può trovare il keystore nella cartella /var/otp/keystore, e per generare una chiave autofirmata si usa il comando da bash keytool -genkey -keystore /var/otp/keystore -alias OTPServerKey. L’alias della chiave è arbitrario, ma è buona norma fornire una chiave che sia diversa da quella offerta dall’impostazione predefinita. Keytool [KEYMC] farà una serie di domande riguardanti il Domain Name dell’utente e l’organizzazione privata e successivamente richiederà una password per proteggere il keystore e la chiave stessa. Questa password sarà successivamente configurabile, ma al momento è codificata all’interno del server di OTP, pertanto è necessario impostare il keystore e la password della chiave a OTP. Naturalmente con una chiave autofirmata la maggior parte dei client non potranno connettersi senza un permesso speciale dall’utente. Utilizzando invece il comando keytool –gencert assieme ad un reale certificato SSL/TLS si crea una connessione sicura che utilizzerà HTTPS con certificato di sicurezza. Una volta installata la chiave o installato il certificato, si potra testare l’accesso e la richiesta di informazioni attraverso i comandi openssl s_client –connect localhost:8081 creando così una connessione con il server sulla porta 8081 e facendo un get per prelevare le informazioni GET index.html http/1.1 si può comunicare in maniera abbastanza sicura con il server [OTPSEC]. Una alternativa per incrementare la sicurezza può essere inoltre mettere Open Trip Planner dietro un firewall o un reverse proxy che possa prevenire l’accesso ai metodi API pericolosi che provengono da network non conosciuti, e possa offrire un minimo di sicurezza su attacchi di tipo Dos e DDos. Questo permetterà di eludere la necessità di certificati SSL/TLS e l'autenticazione, ma deve essere fatto con cautela e un'attenta pianificazione. Se si è sicuri di voler disattivare l'autenticazione, è sufficiente aggiungere l'opzione --insecure all'avvio del server Grizzly di Open Trip Planner.
2.3 Strumenti
2.3.1 Java Open Trip Planner è interamente realizzato in Java [JAVA], un linguaggio orientato agli oggetti molto famoso per la sua portabilità espressa dal motto “write once, run anywhere”. Il codice compilato su una piattaforma infatti, non deve essere
44 Capitolo 2: Tecnologie utilizzate
ricompilato per essere eseguito su una piattaforma diversa. Il prodotto della compilazione è in un formato chiamato bytecode che può essere eseguito da una qualunque implementazione di un processore virtuale detto Java Virtual Machine. Al 2014, Java risultava essere uno dei linguaggi di programmazione più usati al mondo, specialmente per applicazioni client-server, con un numero di sviluppatori stimato intorno ai 9 milioni [JASE]. Il linguaggio fu originariamente sviluppato da James Gosling e altri ingegneri presso Sun Microsystems, nel 2010 acquisita da Oracle Corporation, che è attualmente detentore del marchio registrato. Il linguaggio deriva gran parte della sua sintassi dai linguaggi Simula, C e C++, ma ha meno costrutti a basso livello e implementa in modo più puro (rispetto al C++) il paradigma object-oriented [WIKJA]. Java venne creato per soddisfare quattro scopi: • Essere orientato agli oggetti. • Essere indipendente dalla piattaforma. • Contenere strumenti e librerie per il networking. • Essere progettato per eseguire codice da sorgenti remote in modo sicuro. Java è stato creato a partire da ricerche effettuate alla Stanford University agli inizi degli anni Novanta. Nel 1992 nasce il linguaggio Oak [JVWO], prodotto da Sun Microsystems e realizzato da un gruppo di esperti sviluppatori capitanati da James Gosling. Tale nome fu successivamente cambiato in Java a causa di un problema di copyright, in quanto il linguaggio di programmazione Oak esisteva già. L'esecuzione di programmi scritti in Java deve avere un comportamento simile in contesti di esecuzione diversi. Per raggiungere questo obiettivo, si lavora su livelli diversi, e il primo di essi è naturalmente il linguaggio, il quale è stato progettato appositamente proprio per questo scopo. Ad esempio, esso fornisce una sintassi unificata per definire le sezioni critiche, compito che in altri linguaggi si svolge tipicamente ricorrendo a librerie di terze parti o primitive di sistema. Inoltre, praticamente non lascia spazio ai comportamenti non definiti o dipendenti dall'implementazione dell'ambiente di esecuzione. Le specifiche di linguaggio richiedono un ambiente di esecuzione che vigila sull'esecuzione del programma e che proibisce determinate operazioni che altrimenti risulterebbero insicure. Esse fanno riferimento esplicito alla Java Virtual Machine, indicandola come il destinatario tipico del bytecode prodotto dalla compilazione iniziale di un programma Java, e infatti il
45 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
compilatore javac incluso nel JDK compila proprio in bytecode. Tuttavia, è possibile la compilazione verso architetture diverse, e infatti è possibile produrre codice oggetto specifico di un certo sistema operativo, servendosi di un compilatore apposito, ad esempio il GNU Compiler Collection [WIKJA]. La piattaforma Java fu uno dei primi sistemi a fornire un largo supporto per l'esecuzione del codice da sorgenti remote. Un Java applet è un particolare tipo di applicazione che può essere avviata all'interno del browser dell'utente, eseguendo codice scaricato da un server web remoto. Questo codice viene eseguito in un'area, denominata sandbox, altamente ristretta, che protegge l'utente dalla possibilità che il codice sia malevolo o abbia un comportamento non desiderato; chi pubblica il codice può applicare un certificato che usa per firmare digitalmente le applet dichiarandole "sicure", dando loro il permesso di uscire dall'area ristretta e accedere al filesystem e al network, presumibilmente con l'approvazione e sotto il controllo dell'utente. In realtà gli applet non hanno avuto molta fortuna. Infatti presuppone che il client in cui essi vengono eseguiti abbia installata la JRE (deve eseguire il codice dell'applet). Hanno avuto fortuna le applicazioni che prevedono il cosiddetto thin-client, cioè un client 'leggero' che non ha bisogno di particolari strumenti per eseguire il codice remoto (a volte è necessario solo il browser) [WKJAPL].
2.3.2 HTML5 Utilizzando un browser come interfaccia, Open Trip Planner presenta la sua formattazione e impaginazione con l’utilizzo del linguaggio di markup HTML [HTML]. Nello specifico per lo sviluppo del progetto è stato utilizzato l’HTML5, l’ultima versione del nativo HTML, dove le novità introdotte rispetto la versione 4 sono finalizzate soprattutto a migliorare il disaccoppiamento fra struttura, definita dal markup, caratteristiche di resa, come font e colore, definite dalle direttive di stile, e contenuti di una pagina web, definiti dal testo vero e proprio. Inoltre l'HTML5 prevede il supporto per la memorizzazione locale di grosse quantità di dati scaricati dal web browser, per consentire l'utilizzo di applicazioni basate su web, ad esempio le caselle di posta di Google o altri servizi analoghi, anche in assenza di collegamento a Internet [WIKHTML]. HTML5 è definito da WHAT WG che lo considera un "Living Standard", ovvero una specifica che cambia progressivamente. l W3C ne consolida alcune parti, la
46 Capitolo 2: Tecnologie utilizzate
Recommendation di riferimento eè “HTML5: A vocabulary and associated APIs for HTML and XHTML”, del 28 Ottobre 2014. Così facendo non c’è più una versione di riferimento con cui confrontare le feature del browser e per gli sviluppatori verificare la compliance allo standard è impossibile. Quello che si può verificare è che l’applicazione giri su tutti i browser, l’importante è che il browser dia supporto a HTML5 [SAL15-16b]. Ogni elemento HTLM5 fa parte di una o più categorie, definite per gruppi con caratteristiche simili [SAL15-16b]: • Metadati; sono il contenuto che identifica la presentazione o il comportamento del resto del contenuto, o le relazioni del documento con altri documenti, o che fornisce informazioni "fuori banda" (header HTML4). • La maggior parte degli elementi usati nel body del documento e delle applicazioni è categorizzato come flow content. • Interactive; è contenuto che è specificamente inteso per interazione con gli utenti (form, multimedia, mappe). • Embedded; è contenuto che importa un'altra risorsa nel documento, o contenuto espressi in altri vocabolari e inseriti nel documento (audio, video, SVG, MathML, Canvas, etc.). • Phrasing; è il testo del documento, e anche gli elementi che marcano il testo al livello interno al para- grafo (HTML4 inlines). • Heading; definisce le intestazioni di sezione (h1, h2, ..., h6, hgroup). • Sectioning; dividono il documento in parti, a cui è assegnato un ruolo (navigation, section, footer, etc).
2.3.3 CSS Essendo presentato in un browser, Open Trip Planner possiede chiaramente dei fogli di stile associati al suo codice HTML. Storicamente infatti il linguaggio HTML venne ideato con lo scopo di descrivere il contenuto di un documento e la sua struttura, ma non le relative caratteristiche di visualizzazione. Il prototipo WWW di Tim Berners-Lee prevedeva un linguaggio di stile che consentiva ai lettori di definire personalmente come presentare i documenti HTML, e le prime versioni dei browser Web (Mosaic) permettevano agli utenti di specificare queste caratteristiche. Il
47 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
Cascading Style Sheet (CSS) venne introdotto nel 1996 e si sviluppò sempre di più con il passare degli anni e delle sue versioni [WIKCSS]. L'introduzione del CSS si è resa necessaria per separare i contenuti delle pagine HTML dalla loro formattazione e permettere una programmazione più chiara e facile da utilizzare, sia per gli autori delle pagine stesse sia per gli utenti, garantendo contemporaneamente anche il riutilizzo di codice ed una sua più facile manutenzione. L'altra caratteristica vincente dei fogli di stile è quella di essere indipendenti dallo specifico set di elementi ed attributi HTML, così da rendere possibile anche il supporto di nuove versioni di HTML e di altri linguaggi come XML. Ad oggi esistono 3 versioni di CSS: level 1 è un linguaggio di formattazione visiva, permette di specificare caratteristiche tipografiche e di presentazione per gli elementi di un documento HTML destinato ad essere visualizzato; level 2.1 invece introduce il supporto per media multipli e un linguaggio di layout sofisticato e complesso; level 3 è l’ultimo rilasciato, alcune sezioni sono gia reccommandation (come colori e sezioni) altre invece sono ancora in fase di sviluppo [MIR14-15].
2.3.4 DOM L’utilizzo di un numero elevato di tag ed elementi nel progetto Open Trip Planner ha richiesto l’utilizzo di uno strumento necessario come quello del DOM. Il Document Object Model (DOM), è una forma di rappresentazione dei documenti strutturati come un modello orientato agli oggetti [WIKDOM]. Ogni documento caricato dal browser genera un DOM che specifica tutti gli elementi di quel documento, nella gerarchia che è definita dal markup. Se un elemento ne contiene un altro, allora il secondo è figlio del primo nella gerarchia del DOM. Il DOM è lo strumento per accedere al contenuto del documento e modificarlo. Il DOM definisce sostanzialmente è un interfaccia di programmazione (API) per documenti sia HTML sia XML. Definisce la struttura logica dei documenti ed il modo in cui si accede e si manipola un documento. Utilizzando DOM si possono costruire documenti, navigare attraverso la loro struttura, e aggiungere, modificare o cancellare elementi. Ogni componente di un documento HTML o XML può essere letto, modificato, cancellato o aggiunto utilizzando il Document Object Model [SAL15-16b]. Le specifiche DOM elaborate da W3C sono suddivise in livelli, ciascuno dei quali contiene moduli obbligatori o opzionali. Per sostenere di appartenere ad un certo
48 Capitolo 2: Tecnologie utilizzate
livello, un'applicazione deve soddisfare tutti i requisiti di tale livello e dei livelli inferiori. La specifica attuale di DOM è al Livello 2, tuttavia alcune delle specifiche del Livello 3 ora sono già raccomandazioni del W3C [WIKDOM]. Per ogni documento e porzione viene creato un DOM dove l’oggetto principale di DOM è DOMNode, una interfaccia usata solo per creare classi [JAVDM]. Il core del DOM definisce alcune classi fondamentali per i documenti HTML e XML, e ne specifica proprietà e metodi. DOMNode specifica i metodi per accedere a tutti gli elementi di un nodo di un documento, inclusi il nodo radice, il nodo documento, i nodi elemento, i nodi attributo, i nodi testo e molti altri. Gli ultimi due elementi del DOM sono il DOMDocument, che specifica i metodi per accedere al documento principale (interamente), e il DOMElement che specifica i metodi e i membri per accedere a qualunque elemento del documento [SAL15-16b].
2.3.5 Mapnik Mapnik è uno strumento open source per il rendering delle mappe. Esso è stato utilizzato per la realizzazione dei cinque strati “Slippy” principali che compongono la mappa di Open Street Map, e riutilizzati dunque dal software di Open Trip Planner. Il termine “Slippy” in generale si riferisce alle moderne mappe web che permettono di fare zoom della panoramica di visualizzazione e che quindi scivolano letteralmente sotto la pressione del mouse o del dito. Il software di Mapnik è scritto il C++ e può prevedere anche script da svariati linguaggi, come JavaScript, Python e Ruby. Esso utilizza un rendering anti granulosità denominato Anti-Grain Geometry che offre un rendering molto accurato nella trasformazione dei singoli pixel, ed esporta immagini in una grande varietà di formati, come PNG, JPEG, SVG e PDF, creando dei quadrati di 256x256 pixel. Mapnik offre anche una personalizzazione dell’aspetto della mappa, permettendo la modifica di icone, font, colori, pattern e altri tipi di effetti come la creazione di edifici in 3d e ombre [MPNK]. Legati direttamente a Mapnik, esistono altri strumenti esterni che possono aiutare la creazione di stili per le mappe. Gli stili delle mappe di Mapnik infatti sono utilizzati mediante dei fogli definiti con un linguaggio XML specifico per lo stesso software. Per facilitare la creazione e la modifica di questi file XML, esistono linguaggi di disegno di mappe come CartoCSS [CARTO], che utilizza una sintassi molto simile a quella del CSS. Creando un certo stile con CartoCSS e generando un file .mml si può
49 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
successivamente convertire questo file in un file mapnik.xml per poi renderizzare la mappa stessa con Mapnik.
50 Capitolo 3: Descrizione del progetto
3 Descrizione del progetto
Nel terzo ed ultimo capitolo è illustrato il lavoro svolto per il progetto di tesi, descrivendo i principi di progettazione e le linee guida utilizzate. Sono descritte nel dettaglio i cambiamenti apportati nel codice sorgente del software di Open Trip Planner, descritti i suoi moduli, le motivazioni delle scelte di progettazione che hanno modificato l’interfaccia stessa e i cambiamenti dello stile della mappa di Open Street Map. Nell’ultima parte del capitolo vengono descritti i test che hanno accompagnato il progetto, i problemi incontrati e le soluzioni proposte per superarli. Sono stati attuati test con alcuni profili utente per controllare il corretto funzionamento degli itinerari restituiti e simulazioni di utilizzo di OTP per gli utenti daltonici e il test fondamentale di controllo WCAG 2.0.
3.1 Il progetto Lo sviluppo di un’interfaccia accessibile per il progetto di Open Trip Planner è stata necessaria per mantenere il software fruibile ad una ampia gamma di utenti, specialmente utenti e persone con disabilità. La sua realizzazione dunque è stata fatta prendendo in considerazione le linee guida fondamentali della WCAG [WCAG20]. La versione standard di OTP possiede una interfaccia non di facile uso e soprattutto non a norma con gli standard di accessibilità della W3C. Gli utenti che utilizzano l’interfaccia e il software di OTP devono essere agevolati nella facilità d’uso, al di là dei particolari dispositivi che utilizzano, come computer desktop, tablet e smartphone, o altre limitazioni alle quali gli utenti vanno incontro, come ad esempio particolari tipi di illuminazione della stanza, ambienti rumorosi, oppure in situazioni in
51 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
cui sia necessario non avere le mani o la vista impegnate, come ad esempio in uno scenario di guida.
3.1.1 Introduzione Nella realizzazione dell’interfaccia è stato tenuto in considerazione il fatto che non tuti gli utenti che utilizzano Open Trip Planner possiedono piene capacità fisiche e sensoriali. Il software, o il rispettivo sito Web, può essere utilizzato da utenti che non sono in grado di vedere o ascoltare, altri possono avere difficoltà nella comprensione della navigazione o non essere in grado di apprendere alcuni tipi di informazioni, altri ancora possono non essere in grado di avere piena libertà di movimento. L’utilizzo di tecnologie assistive come screen reader, tastiere Braille, mouse speciali o strumenti di riconoscimento dei gesti o eyetracking devono funzionare perfettamente con il documento stesso. La considerazione di questo primo punto è stato fondamentale per sviluppare una totale accessibilità all’interfaccia di OTP, ma si è tenuto in considerazione anche altro. Non solo gli utenti con disabilità infatti possono andare in contro a limitazioni nell’utilizzo del software. Gli utenti limitati nell’utilizzo del touch-screen, se il dispositivo è un tablet o uno smartphone, o l’utilizzo di un track-pad, se il dispositivo è un notebook, sono stati fonte di studio per una corretta implementazione dell’interfaccia. È stata considerata anche l’area di visualizzazione di OTP; non tutti i dispositivi utilizzano la stessa risoluzione, quindi gli elementi devono apparire il più possibile simili su browser e sistemi operativi differenti. In fine è stata considerata anche la connessione ad Internet o l’architettura dello stesso sistema operativo sul quale OTP viene utilizzato, preferendo pochi oggetti da caricare nell’interfaccia, per mantenere dei tempi di caricamento bassi ed evitare spreco di risorse. In fase di sviluppo dunque sono stati tenuti in considerazione questi fattori, uniti alla tendenza di mantenere uno stile grafico minimale ed elegante per rendere il contenuto comprensibile e navigabile.
3.1.2 Principi di progettazione Le linee guida utilizzate per l’implementazione dell’accessibilità dell’interfaccia di OTP si basano su alcuni principi di progettazione che assicurano che il contenuto sia
52 Capitolo 3: Descrizione del progetto
comprensibile e navigabile. Questi principi sono gli stessi esposti nelle linee guida del WCAG 2.0 [WCAG20]. In primo luogo le pagine sono state create in modo che si trasformino ed adattino, rimanendo accessibili in ogni caso, sia che l’utente possieda disabilità fisiche e sensoriali o abbia limitazioni causate dalla tecnologia usata. La struttura è stata separata dalla presentazione, distinguendo contenuto, struttura, presentazione e menu di navigazione. Il contenuto inoltre possiede gli equivalenti testuali, che sono indispensabili nel momento in cui il dispositivo utilizzi degli screen reader per riprodurre per intero l’informazione testuale presente nella pagina. Il contenuto deve essere comprensibile e navigabile, per fare ciò dunque è stato necessario adottare meccanismi facilmente comprensibili per la navigazione all’interno della stessa pagina. Gli strumenti di navigazione utilizzati infatti sono molto semplici e massimizzano l’accessibilità e l’usabilità di OTP. Sono stati attuati studi sul colore per assicurarsi che il testo e la parte grafica siano comprensibili se consultati senza colore. È stato studiato se i colori dello sfondo e degli oggetti in primo piano siano troppo simili per tonalità, e se le tonalità di colore utilizzate siano conformi per le persone con disabilità percettive sul colore. Sono stati utilizzati marcatori e fogli di stile in modo appropriato. L’utilizzo improprio infatti impedisce l’accessibilità, rendendo difficile la comprensione dell’organizzazione della pagina e la navigazione. I fogli di stile sono stati anche ottimizzati per garantire l’indipendenza da dispositivo. Con indipendenza da dispositivo si intende che l’utente può interagire con il software attraverso il dispositivo input/output preferito, come mouse e tastiera. I meccanismi di navigazione sono stati utilizzati in maniera chiara e coerente, essi sono fondamentali per le persone con invalidità cognitiva o per i non vedenti, ma utili comunque a qualunque tipo di utente in generale. L’utilizzo della barra di navigazione, pulsanti chiari, intuitivi e icone semplificate sono state dunque fondamentali per soddisfare questo requisito. Unendo la facilità di navigazione e la chiarezza dei documenti, è stata sviluppata una comuicazione efficace ed immediata, specialemente rivolta alle persone la cui lingua madre sia diversa da quella dell’utente che utilizza OTP, nonostante lo stesso software propone attualmente sei lingue differenti.
53 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
3.1.3 La struttura Durante l’implementazione dell’interfaccia grafica sono fatte alcune scelte riguardanti la struttura del documento, rivolte soprattutto alla semplicità e facilità d’uso. La struttura del documento di Open Trip Planner prevede una mappa che si estende per tutta l’area di visualizzazione dello schermo. Questo tipo di struttura è diventato uno standard adottato dai principali software di routing, come ad esempio Google Maps [GOOM], Open Street Map [OSMIT], Maps di Apple [APPM], e Mapquest [MAPQS], in quanto permette una facile e diretta consultazione dell’area della mappa. A questa tipologia di documento è stata applicata la scelta di inserire tutti i restanti elementi necessari alla navigazione direttamente sopra alla mappa, senza limitare o restringere l’area di visualizzazione della mappa stessa, favorendo una chiara e semplice consultazione degli eventuali percorsi pianificati. Il primo problema dunque si è incontrato nel trovare una soluzione per quel che riguarda il colore degli elementi di navigazione, infatti si è dovuto scegliere una tonalità che fosse in contrasto con tutte le tonalità di colore rappresentate nella mappa. Questo tipo di tonalità purtroppo variano, sia dal tipo di territorio che viene rappresentato, sia dal tipo di mappa stessa che si sceglie di visualizzare; OTP offre di base quattro tipologie differenti di mappe, ognuna con proprie particolari gradazioni di tonalità di colore. Questa caratteristica di varietà di colori con cui le mappe sono rappresentate ha portato la scelta di posizionare gli elementi del menù, sia di navigazione, che di ricerca, negli angoli dell’area di visualizzazione. La versione precedente dell’interfaccia di OTP infatti apriva per ogni scelta di percorso, ricerca o modifica dell’itinerario, finestre a comparsa direttamente sulla mappa, al suo centro. Questa struttura è stata eliminata sia per lasciare un area di visualizzazione della mappa più chiara e pulita, sia per evitare la mancanza di contrasto necessaria per le persone che hanno disabilità visive. L’area di navigazione è stata dunque inserita nella parte superiore destra, con una semplice barra di ricerca figura 1.1 e un pulsante che apre l’intero menu di navigazione a comparsa figura 1.2.
54 Capitolo 3: Descrizione del progetto
Figura 1.1: Struttura dell’intefaccia.
Figura 1.2: Struttura dell’interfaccia con il menù aperto.
Nella parte alta sinistra invece è rimasta la navigazione per modificare lo zoom della mappa, il menù per effettuare il cambiamento di tipologia di mappa e il menù della traduzione nella lingua che si preferisce.
3.1.3.1 Lo studio del colore Per mantenere un livello di conformità alto alle WCAG 2.0 è stato attuato uno studio relativo alla luminosità del colore, per dunque trovare le tonalità che mettessero in risalto lo sfondo dal testo. Lo studio è stato svolto con un tool di controllo che
55 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
utilizza variabili di controllo; i valori di queste variabili definiscono nel complesso se i colori scelti sono conformi o meno. Il colour contrast check tool utilizzato è quello del sito web di Jonathan Snook [SNCA] e utilizza nell’analisi del colore sia la composizione RGB che la tonalità e la saturazione del colore stesso. Le variabili utilizzate sono: • La differenza di luminosità; per essere a norma deve avere un valore maggiore o uguale a 125. • La differenza di colore; per essere a norma deve avere un valore maggiore o uguale a 500. • I colori devono essere compilant. • Il valore di contrasto. • Il valore WCAG 2 AA compilant. • Il valore WCAG 2 AA compilant con punti del carattere maggiori o uguali a 18. • Il valore WCAG 2 AAA compilant. • Il valore WCAG 2 AAA compilant con punti del carattere maggiori o uguali a 18. I colori di sfondo scelti per il test e la relativa interfaccia dunque, sono sulla stessa tonalità del logo di OTP, quella del blu scuro e del viola. I test effettuati con questi due colori di sfondo, nello specifico il #314395 e #192472, messi in relazione con il colore bianco di foreground, hanno dato test positivi di conformità su tutte le variabili precedentemente descritte figura 2.1 e figura 2.2.
Figura 2.1: colour contrast check per il colore #314395.
56 Capitolo 3: Descrizione del progetto
Figura 2.2: colour contrast check per il colore #192472.
Chiaramente i due profili #314395 e #192472 non sono stati testati tra loro in quando sono solo due tonalità differenti dello stesso colore utilizzato per le stesse sezioni, quindi completamente ininfluenti con la suddivisione di bottoni o elementi necessari alla navigazione che restano ben chiari e visibili per ogni tipologia di utente.
3.1.3.2 Portabilità L’interfaccia software di Open Trip Planner è presentata mediante un browser, il suo sviluppo ha quindi tenuto conto di tutta la vasta gamma di browser disponibili sul mercato, specialmente quelli presenti anche su dispositivi mobile come tablet e smartphone. Durante la fase di realizzazione si è tenuto conto delle varie risoluzioni degli schermi dei dispositivi, creando una interfaccia che sia in grado di adattarsi in maniera universale a prescindere dall’hardware che utilizzerà OTP. La fase fondamentale dell’adattamento è stato l’inserimento di divisori con identificatori aventi proprietà nel CSS di tipo position: fixed; questa propietà unita alle rispettive distanze dai margini left, top, bottom, right ha reso il menù portabile su ogni tipologia di browser. È stato inoltre necessario sistemare l’elemento di metadatazione relativo alla viewport per sistemare lo zoom prospettico che è presente nei browser dei dispositivi mobile. È stato utilizzato dunque l’elemento dove si è impostato che il contenuto visualizzato deve avere come larghezza la dimensione della larghezza massima dello schermo del dispositivo width=device-width; si è impostato il fattore di zoom iniziale, relativo al momento in cui la pagina viene caricata initial- scale=1.0; infine con la proprietà user-scalable=no si è impostato il divieto
57 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
di zoom da parte dell’utente, evitando così ridimensionamenti prospettici involontari che causerebbero una errata visualizzazione del documento. Sono state tenute inoltre in considerazione le dimensioni dei tasti di utilizzo del menù. Sapendo che dispositivi portatili come smartphone prediligono l’utilizzo delle polpastrelli delle dita nel controllo dei pulsanti relativi la ricerca dei tragitti, si è deciso di creare le aree dei pulsanti in base a questa dimensione, creando aree di almeno 350 pixel di larghezza e 50 pixel di altezza, al fine di evitare tocchi inappropriati e ambigui durante l’uso di OTP.
3.1.3.3 La Mappa Nella struttura del documento l’area che maggiormente viene visualizzata e chiaramente quella della mappa stessa. Le quattro tipologie di mappe, già precedentemente descritte, non sono chiaramente accessibili per quel che riguarda il colore. È stato dunque scelto l’inserimento di una nuova tipologia di mappa che è stata modificata da quella standart di Open Street Map, ma con alcune trasformazioni riguardanti il colore. Le trasformazioni attuate sono grossolane, in quanto uno sviluppo di una nuova mappa completamente accessibile anche nel più piccolo dettaglio, come ad esempio nella creazione di texture per ogni singola area del globo, avrebbe richiesto un enorme dispendio di tempo. Durante lo sviluppo e la modifica dei suoi strati con CartoCSS e Mapnik, sono state dunque considerate solo alcune linee guida descritte dal manuale di OSM. Per OSM infatti ogni nuova tipologia di mappa deve necessariamente soddisfare dei criteri fondamentali che assicurano la qualità della mappa proposta [FTTILE]. Essi sono: • Internamente supportata. Il servizio di provider o l’autore devono essere a favore di avere la mappa stessa sul sito web di OSM. • Deve avere una portata globale. La mappa proposta deve coprire tutta la Terra. • Essere in grado di soddisfare le richieste di traffico del sito di OSM. • Il servizio deve essere affidabile. La mappa proposta deve essere affidabile in termini di tempi di attività e disponibilità.
58 Capitolo 3: Descrizione del progetto
• I dati devono essere sempre aggiornati. Sono necessari continui aggiornamenti dettagliati riguardanti la mappa proposta, preferibilmente giornalieri o bisettimanali. • Unica. La mappa deve essere unica nella sua tipologia, per esempio deve rappresentare un tema che ancora non è stato preso in considerazione. • Interessante. Questo criterio è estremamente arbitrario e comprende l’estetica della mappa. • Non commerciale. Il servizio non commerciale è preferibile. • Libera ed aperta. I fogli di stile e il rendering della mappa devono essere liberi e disponibili alla consultazione.
3.2 Le modifiche apportate L’implementazione di una nuova interfaccia in OTP ha richiesto una modellazione del codice con cui il software rappresenta i propri oggetti, nello specifico i percorsi e le indicazioni stradali descritte dopo la pianificazione di un itinerario. Come primo punto è stato scelto di inserire un nuovo menù con la rispettiva barra laterale di ricerca. Esso è stato implementato con una libreria JavaScript denominata jQuery [JQUR] che ha inserito all’interno del software le basi per creare l’effetto a comparsa e scomparsa del menù destro laterale. È stato quindi necessario creare uno script che implementasse questa tipologia di effetto collegato al pulsante principale del menù codice 1.1.
Codice 1.1: Script menù.
59 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner
Successivamente si è dovuto andare a modificare tutte le finestre che venivano restituite dopo l’inserimento dei punti di interesse per l’itinerario, esse infatti apparivano a comparsa in maniera completamente distaccata dal menù di navigazione progettato nella nuova interfaccia. Sono stati dunque modificati e riadattati tutti i fogli di stile della pagina per rendere la visualizzazione corretta in relazione alla nuova impaginazione.
3.2.1 I moduli Open Trip Planner possiede alcuni moduli fondamentali sul quale basa i suoi servizi. Essi sono contenuti nella cartella modules del programma e sono suddivisi in builder di grafi, il motore di routing e tutta la parte relativa all’interfaccia. Le informazioni dunque che devono essere restituite dopo aver calcolato il percorso, sono trasformate e inserite all’interno di divisori e stampati a video nella sezione delle informazioni del menù laterale. Queste informazioni comprendono tutte le parti relative al tempo di percorrenza del tragitto, orario, data di arrivo e partenza, e kilometraggio.
3.2.1.1 Il file ItinerariesWidget.js OTP è un ibrido tra codice scritto con JavaScript e HTML ed elabora e restituisce le parti delle informazioni relative ai tragitti in alcuni file JavaScript contenuti all’interno dei suoi moduli più generici. Per quel che riguarda più nello specifico le informazioni relative gli itinerari vengono elaborati e restituiti principalmente da due file: Itinerary.js e ItinerariesWidget.js. Il primo file restituisce semplicemente i dettagli del singolo viaggio, indipendentemente dalla tipologia scelta, come ad esempio, mezzi pubblici piuttosto che tragitto in bici. Il file ItinerariesWidget.js invece restituisce i vari itinerari che vengono calcolati e creati dall’utente, come si può vedere anche dalla sezione nel codice 2.1. In questa sezione di codice si può osservare come nel caso il primo itinerario sia già stato calcolato e restituito, e quindi si voglia ricreare un nuovo itinerario con altri dati di input, il metodo .replaceWith sostituisce il divisore dell’itinerario precedentemente creato, con un nuovo itinerario inserito dentro un divisore chiamato .secondItinerary; esso poi sarà nuovamente sostituito qualora si voglia creare un nuovo itinerario.
60 Capitolo 3: Descrizione del progetto
var header; for(var i=0; i $(‘’) .appendTo(this.itinsAccord);
$(“.secondItinerary”) .replaceWith(‘
’);$(‘
’).prependTo(“.secondItinerary”) .append(this.renderItinerary(itin, i)); } Codice 2.1: Sezione di ItinerariesWidget.js.
3.2.2 I fogli di stile Per adattare ed avere una corretta visualizzazione dell’interfaccia è stata applicato un massiccio cambiamento nel CSS del programma. Sono stati modificati i principali fogli di stile del software di OTP riguardanti ogni singola parte del progetto. La parte più sostanziosa dei cambiamenti chiaramente, riguarda il cambiamento dei CSS dei widget del vecchio e del nuovo menù, codice 2.2. Gli aspetti presentazionali, come la resa grafica specificata dal foglio di stile stesso, è stato ben separato dal contenuto; sono quindi stati preferiti nei confronti di generici, distinti graficamente attraverso il foglio di stile. 61 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner #search{ background-color: #192472; border: medium none; color: white; height: 50px; margin: 0; opacity: 1; padding: 0 10px; position: absolute; right: 0; text-align: left; top: 10px; transition: all 0.218s ease 0s; width: 80%; z-index: 3; text-transform: uppercase; font-size: medium; border-radius: 5px; } Codice 2.2: Sezione di CSS riguardante il divisore della barra di ricerca. Per la creazione del documento è stato associato un solo foglio di stile CSS come espresso dalle linee guida del W3C [W3CWDA] cercando di riutilizzare al massimo ogni singola classe creata, tenendo sempre conto della semplicità di progettazione. 3.2.3 CartoCSS CartoCSS è una tipologia di foglio di stile creato appositamente per la produzione di file da utilizzare nel rendering di mappe di Mapnik. Esso rende più semplice la sintassi e l’applicazione di modifiche per ogni parte di una determinata mappa, essento molto simile al CSS tradizionale, basandosi su di essa con le specifiche per filtrare i dati della mappa e fornendo le giuste variabili. La modifica di un foglio xml di Mapnik infatti sarebbe risultata molto più complessa e in alcuni casi poco chiara. Una volta terminata la creazione del nuovo foglio di stile di Carto, è stato necessario convertirlo nel formato richiesto da Mapnik mediante una semplice compilazione che ha portato la generazione del file necessario per il rendering ./bin/carto ./files/OTP/OTPCartoCSS.mml > mapnik.xml. La scelta di CartoCSS è stata attuata in quanto lo stesso CSS è un linguaggio di formattazione molto rapido, flessibile e di facile uso. Durante l’implementazione del 62 Capitolo 3: Descrizione del progetto codice infatti gli elementi appaiono ben distinti e chiari, codice 2.3, a discapito di uno stile creato mediante l’utilizzo del linguaggio xml preferito da Mapnik, codice 2.4. #world{ text-name: “[NAME]”; text-size: 11; text-face-name: “Georgia Regular”, “Arial Italic”; } Codice 2.3: Sezione di CartoCSS riguardante il font sets dello strato con tag world. I livelli della mappa renderizzata da Mapnik possiedono linee e forme ognuna delle quali presenta bordi e molti altri attributi, determinati con un colore oppure una texture. Le strade ad esempio possiedono un colore interno, e una determinata larghezza, e un colore esterno di bordo. L’idea è stata attuare tutte le modifiche partendo dallo stile di mappa base di Open Street Map. Il lavoro svolto dunque si è svolto partendo con il desaturare ogni singolo colore rappresentato, in modo tale da rendere la mappa completamente uniforme, per poi aggiungere i colori degli elementi importanti alla navigazione con colori conformi. Creando un prototipo, l’implementazione di questa parte è stata molto approssimativa, in quanto lo sviluppo dettagliato di una mappa con un numero molto elevato di elementi e colori, avrebbe richiesto un grande dispendio di tempo. Gli elementi considerati quindi sono stati raggruppati in due insiemi, le aree e le strade. Si è cercato di creare un risalto tra le strade e le aree, lasciando il colore desaturato per le aree e inserendo il colore rosso per le strade principali, tag highway=primary. Una semplice modifica è stata attuata tra le aree di mare e quelle di terra, utilizzando il 63 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner colore azzurro, al tag natural=water, per dare risalto con il grigio della terra, figura 3.1. Figura 3.1: Esempio di mappa di Rimini renderizzata con il nuovo profilo colore di CartoCSS. Nel dettaglio sono stati inserite le propietà CSS nello stile delle strade e del territorio. CartoCSS infatti mette a disposizione anche un innestamento di stili, che rende molto pratico e intuitivo la trasformazione del documento, codice 2.5. Si vede dal codice che il generico colore desaturato di roads resta nelle sue proprietà, mentre primary eredita la larghezza delle linee di roads ma con dei colori differenti. Una utilissima caratteristica di CartoCSS è inoltre il supportare filtri numerici di comparazione, molto utili nel momento di implementazione di una mappa più dettagliata. Nella necessità di selezionare parti del globo che utilizzano una particolare quantitativo di popolazione, per colorarla o selezionarla con criterio si possono utilizzare dei controlli sugli stili, come ad esempio #world[population < 1000] oppure selezionare interi stati con la sintassi #world[name = “Italy”]. 64 Capitolo 3: Descrizione del progetto #roads{ casing/line-width: 6; casing/line-color: #ccc; line-width: 4; line-color: #ccc; #primary{ casing/line-color: #ee7979; line-color: #ee7979; } } Codice 2.5: Sezione di CartoCSS riguardante il font sets dello strato con tag roads e innestamento. 3.3 Test Lo sviluppo e del progetto è stato affiancato da continui test di controllo che hanno appurato sia il corretto funzionamento del software sia la conformità WCAG 2.0. La simulazione di percorsi e alcuni test sul daltonismo e ipovisione sono stati dunque fondamentali per correggere gli errori in fase di realizzazione. 3.3.1 Simulazione con il profilo wheelchair Il primo grande problema incontrato durante il test dell’interfaccia è stato quello relativo al profilo WHEELCHAIR. Questo tipo di profilo non è stato sviluppato nella prima versione del software ma aggiunto successivamente, e consiste nella creazione di un percorso accessibile ad una persona con disabilità motorie, prendendo in considerazione l’impossibilità di attraversare strade con tornelli, dissuasori, scale favorendo percorsi con facility come attraversamenti pedonali, semafori speciali e rampe. Nella interfaccia implementata nel progetto ogni profilo possiede una propria icona, restituita correttamente dopo l’elaborazione del tragitto da parte del software. Il profilo WHEELCHAIR però è considerato come una opzione aggiuntiva del profilo PEDESTRIAN, e quest’ultimo profilo implementa un percorso a piedi tra due punti d’interesse. È stato dunque necessario inserire un controllo all’interno del modulo del software che controllasse se il profilo PEDESTRIAN fosse anche un profilo WHEELCHAIR e nel caso inserire l’icona adeguata nel menù dell’itinerario restituito codice 3.1. 65 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner if(document.getElementById('otp-planner-optionsWidget-wheelchair-input') && document.getElementById('otp-planner-optionsWidget-wheelchair-input').checked){ var headerHtml = ""; } else{ var headerHtml = ""; } Codice 3.1: Controllo per il profilo WHEELCHAIR. Con questo profilo sono stati successivamente testati percorsi per osservare le differenze di itinerari restituiti utilizzando la mappa di default di Portland, figura 4.1 e figura 4.2. Figura 4.1: Percorso restituito con il profilo PEDESTRIAN. 66 Capitolo 3: Descrizione del progetto Figura 4.2: Percorso restituito con il profilo WHEELCHAIR. Si può notare come i due percorsi restituiti siano equivalenti a livello di durata, ma siano differenti per la percorrenza del tragitto. Nelle due figure si possono anche notare nel dettaglio gli itinerari restituiti. I tragitti appaiono all’interno del menù di navigazione, rendendo semplice e intuitivo il suo utilizzo. Inserendo le preferenze, il punto di partenza, di arrivo e avviando la ricerca viene restituito l’itinerario con i dettagli di viaggio, come orario di partenza, durata e distanza. Sotto di esso appaiono tre pulsanti opzionali; il primo crea un link diretto al percorso, da poter condividere con qualsiasi altra piattaforma, il secondo pulsante può stampare l’itinerario e in fine l’ultimo richiama il software di posta favorito e inserisce l’itinerario in una nuova e- mail pronta per essere spedita. Cliccando sull’apposito pulsante, a fianco dell’itinerario, con l’icona del simbolo matematico “+” si aprono i dettagli dell’itinerario stesso. L’utente navigando ogni singola istruzione, passandoci sopra con il mouse in un dispositivo desktop o cliccandoci sopra con un dispositivo mobile, viene aiutato dalla mappa stessa che indica la tratta dell’istruzione selezionata, facilitando la navigazione o eventualmente facilitando il reader di schermo preferito. 67 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner 3.3.2 Test per il daltonismo Le mappe offerte (ad esclusione di quella accessibile proposta) e l’interfaccia implementata rappresentano una grande gamma di colori contenuti sia nell’area del menù, sia nell’area della mappa stessa. Nei precedenti capitoli sono già stati affrontati gli studi sul colore che compongono il menù laterale, ma non quelli rappresentati nella mappa stessa. Purtroppo il campionamento dei colori della mappa e i test sui singoli sarebbero numericamente troppo elevati e probabilmente anche inutili, in quanto oltre a comprendere quasi tutta la gamma completa di tonalità di colori, OTP fornisce quattro tipologie differenti di mappe; quella di default offerta da Open Street Map, quella dalla visuale aerea, la mappa dei trasporti e in fine quella che analizza gli spostamenti in tempo reale. Prendendo in considerazione le quattro tipologie, sicuramente la mappa che analizza e rappresenta gli spostamenti è la peggiore in quanto utilizza solo tonalità di grigio, la tonalità che una utente daltonico riuscirebbe a fatica ad utilizzare. La percezione delle vie e delle strade risulterebbe pessima anche nella tipologia di mappa aerea, in quanto le aree cittadine possiedono in gran parte tonalità di grigio e le aree rurali tonalità di verde. Tra le quattro tipologie sicuramente la migliore resta quella di default, che utilizza tonalità di giallo per le strade principali, tonalità di blu per le superstrade ed evidenzia il percorso restituito con un giallo accesso che risalta maggiormente nei confronti del resto delle aree rappresentate. Per questo test è stato utilizzato Coblis [COB] un tool che simula ben sette tipologie differenti di daltonismo: • Cecità del rosso o Protanopia. • Cecità al verde o Deuteranopia. • Cecità al blu o Tritanopia. • Debolezza di rilevamento del colore rosso o Protanomalia. • Debolezza di rilevamento del colore verde o Deuteranomia. • Debolezza di rilevamento del colore blu o Tritanomalia. • Incapacità totale di rilevamento del colore o Acromatopsia. Nel test si è notato che i maggiori cambiamenti nella percezione del colore si sono verificati nei profili che simulano la cecità del colore blu, oltre che chiaramente nel test dell’Acromatopsia, figura 3.3. 68 Capitolo 3: Descrizione del progetto Figura 3.3: Simulazione di Tritanopia a destra. Nonostante il test abbia dato dei risultati negativi per quel che riguarda l’accessibilità della parte del contenuto della mappa, la parte del menù e della sua navigazione invece sono rimasti accessibili e conformi. Questo dimostra che utenti con disabilità visive, senza necessariamente scegliere la mappa accessibile, possono comunque recepire senza alcun problema le informazioni necessarie che forniscono la navigazione e l’orientamento con l’utilizzo Open Trip Planner semplicemente navigando e utilizzando l’interfaccia del menù creata. 3.3.3 Revisione WCAG 2.0 La parte conclusiva del progetto è stata la revisione finale per la conformità WCAG 2.0 con un livello AAA. Questo tipo di revisione è stata effettuata con uno strumento specifico open source chiamato AChecker [ACHEK]. La maggior parte degli accessibility tools presenti sul Web offrono solo un controllo diretto mediante l’utilizzo del link del dominio del sito del quale si vuole effettuare il test. La versione prototipo di OTP però, essendo un software svillupato off-line, non possiede un link assoluto necessario al controllo per l’accessibilità, e proprio per questo motivo AChecker è stato fondamentale per la revisione. AChecker infatti offre un clipboard sul quale si può direttamente incollare il codice sorgente HTML relativo alla pagina che si vuole controllare, tralasciando quindi il caricamento dell’intero progetto su un Web server per effettuare il controllo con il link del dominio. Lo strumento AChecker offre una serie di opzioni che possono essere attivate o disattivate durante il controllo: il controllo 69 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner HTML, il controllo CSS, una serie di opzioni riguardanti il livello di conformità, a partire dal più basso (WCAG 1.0 di livello A) al più alto (WCAG 2.0 di livello AAA) e per ultimo il formato di report restituito dopo il controllo. Durante la revisione del progetto sono stati solo restituiti 2 fondamentali problemi, tutti i restanti test invece hanno piacevolmente restituito “Congratulations! No likely or potential Problems”. I 2 problemi restituiti riguardano tutti il controllo dei contenuti non testuali, interessando dunque le immagini e il loro contrasto tra sfondo e contenuto. Le 2 rispettive immagini sono una gif animata che viene attivata durante il caricamento di ricerca del percorso e il logo di Open Trip Planner. Il primo problema è stato affrontato spostando la gif sopra un area che avesse più contrasto che con lo sfondo della mappa, ossia all’interno del menù laterale. Il secondo problema relativo il logo invece non è stato trattato, in quanto da specifica WGAC 2.0, i loghi, o i testi che rientrano all’interno di un logo, e i marchi non hanno nessuna specifica richiesta di contrasto tra lo sfondo e il contenuto. 70 Conclusioni Conclusioni In questo lavoro di testi è stata implementata una interfaccia accessibile per il sito Web e software di Open Trip Planner, aumentando notevolmente la potenzialità dell’applicazione. L’obiettivo principale infatti è stato la creazione di uno strumento che possa essere sia d’aiuto a quelle tipologie di utenti che possiedono delle disabilità, sia rendere l’interfaccia del software di routing qualitativamente valida. Questi due obiettivi sono stati pienamente raggiunti con lo sviluppo di un prototipo perfettamente funzionante che ha dato ottimi risultati ai test sottoposti sia durante la fase di sviluppo, sia nella fase finale dell’implementazione. L’adattamento della nuova struttura del documento ha reso accessibile e facilmente navigabile un percorso urbano pianificato con il semplice utilizzo del menù appositamente creato. Sono state mantenute inoltre le caratteristiche già precedentemente aggiunte al software, come il profilo di percorso Wheelchair User, adattato perfettamente con la nuova interfaccia. Per il raggiungimento di questo scopo è stato fondamentale lo studio delle linee guida del WCAG 2.0, delle principali tecniche per rendere accessibili le mappe e degli standar ISO per il Web. Applicando questo studio a OTP ed a Open Street Map si è potuto rendere il sito Web accessibile a livello AAA e rendere la sua interfaccia mutipiattaforma sotto il punto di vista dei browser e dei sistemi operativi. A questo scopo gli strumenti utilizzati come Java, HTML5 e CSS sono stati indispensabili, soprattutto per implementare in maniera elegante l’interfaccia pur restando all’interno delle linee guida imposte. Nonostante ciò si è lasciata una piccola fetta del progetto approssimata. Si tratta della parte relativa alla creazione di un nuovo profilo colore per l’accessibilità della mappa stessa di Open Street Map da parte di persone che soffrono di disabilità visive. Essa infatti, presentando un numero elevatissimo di elementi, ha obbligato la modifica di solo una parte di essi. È stato dunque fatta solo una modifica 71 Stefano Nicoletti – Implementazione dell’accessibilità in OpenTripPlanner grossolana nella parte riguardante la mappa vera e propria del software, limitandosi alla modifica di alcuni elementi fondamentali della mappa, come le strade principali e la separazione tra la terra ferma e il mare, per poi renderizzarla e renderla disponibile al progetto. L’implementazione di questa parte è stata volutamente tralasciata in quanto avrebbe richiesto un enorme dispendio di tempo e sarebbe risultata uscire dal tema principale della tesi stessa. Fondamentale invece è stato lo studio dello strumento utilizzato per il rendering che utilizza OSM per la sua mappa, Mapnik e il suo corrispettivo markup per la creazione CartoCSS. L’implementazione dell’interfaccia accessibile di Open Trip Planner è stato un elemento importante per rendere questo servizio fruibile ad ogni tipologia di utente, permettendo così di prototipare uno strumento che possa essere utilizzato da persone con disabilità sensoriali e motorie, dando a queste ultime un aiuto, a volte indispensabile, per gli spostamenti all’interno delle città e per pianificare percorsi multimodali. 72 Bibliografia Bibliografia [W3CWDA] W3C Org, Web Design and Applications, http://www.w3.org/standards/webdesign/accessibility, 2015. [UNCRP15] United Nations Web Site, Convention on the Rights of Persons with Disabilities, http://www.un.org/disabilities/default.asp?navid=12&pid=150, 2015. [ISO/TS] ISO/TS 16071:2003, Ergonimics of human-system interaction, http://www.iso.org/iso/catalogue_detail.htm?csnumber=30858, 2013. [W3SCBRW] W3Schools Web Statistics, Browser Statistics, http://www.w3schools.com/browsers/browsers_stats.asp, 2015. [NYTIWB12] New York Times Web Site, For Impatient Web Users, an Eye Blink Is Just Too Long to Wait, http://www.nytimes.com/2012/03/01/technology/impatient-web-users- flee-slow-loading-sites.html, 2012. [WIKIPRE] Wikipedia, Progressive Enhancement, https://en.wikipedia.org/wiki/Progressive_enhancement, 2015. [WIKICS] Wikipedia, List of countries by Internet connection speeds, https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connecti on_speeds, 2015. [WIKACS] Wikipedia, Accessibility, https://en.wikipedia.org/wiki/Accessibility, 2015. [WIKWBS] Wikipedia, Web acessibility, https://en.wikipedia.org/wiki/Web_accessibility, 2015. [CAMD04] Camera dei Deputati Web Site, Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici, http://www.camera.it/parlam/leggi/04004l.htm, 2004. [SAL15-16a] P. Salomoni, Tecnologie Web 2015-2016 Slide Accessibilità, Cesena 2015. [MPNK] Mapnik, Mapnik Website Tool, http://mapnik.org/, 2016. [W3CACM] W3C, Accessible Maps, http://www.w3.org/WAI/RD/wiki/Accessible_Maps, 2015. [GOOM] Google Maps, maps.google.com, 2016. [OTP] Open Trip Planner, http://www.opentripplanner.org/, 2015. [APPM] Maps by Apple, http://www.apple.com/it/ios/maps/, 2016. [WIKTGPH] Wikipedia, Tactile graphic, https://en.wikipedia.org/wiki/Tactile_graphic, 2015. [HEU06] W. Heuten, D. Wichmann, S. Boll, Interactive 3D Sonification for the i Exploration of City Maps, University of Oldenburg 2006. [AHBLZGQ] L. Zeng , G. Weber, Audio-Haptic Browser for a Geographical Information System, Germany 2010. [MBSPK] Mobile Speak, http://codefactoryglobal.com/app-store/mobile-speak/, 2014. [SHA09] Shaun K. Kane, Fully Accessible Touch Screens for the Blind and Visually Impaired, Università di Washington 2009. [BEN11] B. Poppinga, TouchingOver Map: Audio-Tactile Exploration of Interactive Maps, Stockholm, Sweden 2011. [MAR12] M. Pielot, B. Poppinga, PoketNavigator: Studying Tactile Navigation System In-Stu, Austin, Texas 2012. [CHA15] Y.J. Chang, S.K. Tsai, T.Y. Wang, A Context Aware Handheld Wayfinding System for Individuals with Cognitive Impairments, Taiwan 2015. [TBLEE] Wikipedia, Sir Timothy John Berners-Lee, https://it.wikipedia.org/wiki/Tim_Berners-Lee, 2016. [SRAM] Sramana Mitra Web Site, Web 3.0 & Semanttic Web, http://www.sramanamitra.com/2007/06/28/web-30-the-semantic-web/, 2015. [WIKSW] Wikipedia, Semantic Web, https://en.wikipedia.org/wiki/Semantic_Web, 2015. [WIKVG] Wikipedia, Virtual Globe, https://en.wikipedia.org/wiki/Virtual_globe, 2015. [GES99] D.B. Gesch, K.L. Verdin, S.K. Greenlee, New Land surface digital elevation model covers the Earth, United States of America 1999. [ADA15] B. Adams, G. McKenzie, M. Gahegan, Frankenplace: Interactive Thematic Mapping for Ad Hoc Exploratory Search, Switzerland 2015. [TIK03] TikiWiki, CMS Groupware Home Page, http://tiki.org/tiki-index.php, Argentina 2003. [OSMIT] Open Street Map Web Site Italia, Open Street Map, https://openstreetmap.it/, 2016. [OSMLIC] Open Street Map Foundation Wiki, Licence, http://wiki.osmfoundation.org/wiki/License, 2015. [WIKOSM] Wikipedia, OpenStreetMap, https://en.wikipedia.org/wiki/OpenStreetMap, 2016. [CRA] Wikipedia, Craigslist, https://en.wikipedia.org/wiki/Craigslist, 2016. [OSMAND] Wikipedia, OsmAnd, https://en.wikipedia.org/wiki/OsmAnd, 2016. [FOUR] Wikipedia, Foursquare, https://en.wikipedia.org/wiki/Foursquare, 2016. [OSMFL] Open Street Map Foundation, Licence, http://wiki.osmfoundation.org/wiki/License, 2012. [OSMID] Open Street Map, iD, https://wiki.openstreetmap.org/wiki/ID, 2015. [OSMEL] http://wiki.openstreetmap.org/wiki/Elements, 2015. [OSMN] Open Street Map, Node, http://wiki.openstreetmap.org/wiki/Node, 2015. [OSMW] Open Street Map, Way, http://wiki.openstreetmap.org/wiki/Way, 2015. [OSMR] Open Street Map, Relation, http://wiki.openstreetmap.org/wiki/Relation, 2015. [OSMT] Open Street Map, Tags, http://wiki.openstreetmap.org/wiki/Tags, ii Bibliografia 2015. [OSMMFT] Open Street Map, Map Features, http://wiki.openstreetmap.org/wiki/Map_Features, 2015. [OSMDIS] Open Street Map, Disabilities, http://wiki.openstreetmap.org/wiki/Disabilities, 2015. [OSMHR] Open Street Map, HaptoRender, http://wiki.openstreetmap.org/wiki/HaptoRender, 2015. [LULUA] Open Street Map, Lulu-Ann, http://wiki.openstreetmap.org/wiki/User:Lulu-Ann, 2015. [BAHNWK] Wikipedia, Bahnpirat, https://en.wikipedia.org/wiki/User:Bahnpirat, 2016. [HANSTA] Open Street Map, Stammtish Hannover, http://wiki.openstreetmap.org/wiki/Stammtisch_Hannover, 2015. [OSMLD] Open Street Map, Loro Dux, http://wiki.openstreetmap.org/wiki/LoroDux, 2015. [OTP] Open Trip Planner, Home Page, http://www.opentripplanner.org/, 2015. [GTFS] General Transit Feed Specification Reference, Static Transit, https://developers.google.com/transit/gtfs/reference, 2016. [TRIM] Trimet, Website, http://trimet.org/, 2016. [VGT] Smart Campus, Viaggia Trento, http://www.smartcampuslab.it/services/viaggia-trento/, 2015. [VGR] Smart Campus, Viaggia Rovereto, http://www.smartcampuslab.it/viaggiarovereto/, 2015. [OTPARC] Open Trip Planner, Basic OTP Architecture, http://opentripplanner.readthedocs.org/en/latest/#basic-otp- architecture, 2015. [OTPALS] Open Trip Planner, OTP Analyst, http://www.opentripplanner.org/analyst/, 2015. [SAND12] City Lab Web Site, The best maps we’ve seen of sandy’s transit outage in New York, http://www.citylab.com/commute/2013/01/best- maps-weve-seen-sandys-transit-outage-new-york/4488/, 2013. [HIROU08] R. Geisberger, Contraction Hierarchies: Faster and SimplerHierarchical Routing in Road Networks, Karlsruhe University, 2008. [WIKCOHI] Wikipedia, Contraction hierarchies, https://en.wikipedia.org/wiki/Contraction_hierarchies, 2016. [WIKAS] Wikipedia, A* search algorithm, https://en.wikipedia.org/wiki/A*_search_algorithm, 2016. [HTTPs] Wikipedia, HTTPS, https://it.wikipedia.org/wiki/HTTPS, 2016. [OTPSEC] Open Trip Planner, Security, http://docs.opentripplanner.org/en/latest/Security/, 2015. [GRLY] Project Grizzly, Grizzly Server, https://grizzly.java.net/, 2015. [KEYMC] Mac Developer Library, Keytool, https://developer.apple.com/library/mac/documentation/Darwin/Refer ence/ManPages/man1/keytool.1.html, 2004 [JAVA] Java, Java Home Page, https://www.java.com/en/, 2016. [JASE] Oracle, Java Language and Virtual Machine Specifications, http://docs.oracle.com/javase/specs/, 2015. [WIKJA] Wikipedia, Java, iii https://en.wikipedia.org/wiki/Java_(programming_language), 2016. [JVWO] JavaWord, From OAK to JAVA, http://www.javaworld.com/article/2075839/core-java/from-oak-to- java.html, 2010. [WKJAPL] Wikipedia, Java applet, https://en.wikipedia.org/wiki/Java_applet, 2016. [HTML] W3Schools.com, HTML Tutorial, http://www.w3schools.com/html/, 2016. [WIKHTML] Wikipedia, HTML5, https://en.wikipedia.org/wiki/HTML5, 2016. [SAL15-16b] P. Salomoni, Tecnologie Web 2015-2016 Slide HTML5, Cesena 2015. [WIKCSS] Wikipedia, Cascading Style Sheets, https://en.wikipedia.org/wiki/Cascading_Style_Sheets, 2016. [MIR14-15] S. Mirri, Sistemi Multimediali 2014-2015 Slide CSS, Cesena 2014. [WIKDOM] Wikipedia, Document Object Model, https://en.wikipedia.org/wiki/Document_Object_Model, 2016. [JAVDM] JavaScript Tutorial, Basic DOM Node Proprieties, http://javascript.info/tutorial/basic-dom-node-properties, 2011. [WCAG20] W3C Org, Web Content Accessibility Guidelines 2.0, https://www.w3.org/Translations/WCAG20-it, 2016. [MAPQS] Mapsquest, Mapquest Open, http://open.mapquest.com/, 2016. [SNCA] Jonathan Snook, Snook Web development blog, http://snook.ca/technical/colour_contrast/colour.html, 2014. [FTTILE] Open Street Map, Featured tile layers Guidelines, http://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_fo r_new_tile_layers, 2016. [JQUR] jQuery, jQuery Project, http://jquery.com/, 2016. [COB] Colblindor Web Site, Coblis Color Blindness Simulator, http://www.color-blindness.com/coblis-color-blindness-simulator/, 2015. [ACHEK] Atutor Web Site, Achecker Tool, http://www.atutor.ca/achecker/, 2016. iv per dare caratterustiche più evidenti alle porzioni di testo che non sono titoli. Sono stati inoltre strutturati i contenuti attribuendo alle parti del documento una semantica dividendo a secondo del ruolo le sezioni (header, nav, ecc.). I contenuti specifici sono stati inseriti in paragrafi