UNIVERSITA' POLITECNICA DELLE MARCHE
Facoltà di Ingegneria
Corso di laurea in Ingegneria informatica e dell'automazione
Valutazione dell'accessibilità dell'interfaccia utente
personalizzata per portali sanitari
Candidato:
Juri Orazi
Relatore:
Chiar. mo Prof. Aldo Franco Dragoni
Anno Accademico 2006/2007 – II Sessione invernale
SOMMARIO
In questa tesi viene esposto il lavoro svolto durante il tirocinio effettuato
presso l’Asur Zona Territoriale n. 7 di Ancona.
L’obiettivo è quello di modificare l’interfaccia, già esistente,
dell’Assistente Personale (progetto “Arianna”) per adeguarla ai principi
dell'accessibilità.
L’elaborato è stato suddiviso in cinque capitoli.
Il primo capitolo affronta i temi dell'accessibilità e dell’usabilità, per far
conoscere cosa si intende con tali termine. In particolare, si vanno a valutare
le analogie e le differenze che contraddistinguono queste due materie.
Nel secondo capitolo vengono esposte le linee guida divulgate dal W3C
(WCAG 1.0 e 2.0), evidenziando le modifiche apportate (e ancora da
apportare ) per le WCAG 2.0 prima della stesura definitiva.
Nel terzo capitolo viene descritto il progetto dell’Assistente Personale
(progetto “Arianna”), che è stato sviluppato per il portale sanitario della ASUR
Zona Territoriale n. 7 di Ancona. Vengono presentati gli obiettivi, la struttura e
un ipotetico sviluppo futuro.
Il quarto capitolo è suddiviso in 2 parti; nella prima di descrive un
processo completo per la valutaizone dell'accessibilità di un sito dall'inizio
alla fine. Di seguito, dopo aver elencato gli strumenti utilizzati, vengono
elencate le modifiche apportate all'Assistente Peronale per far si che
rispettino le linee guida WCAG 1.0. Tale parte è stata strutturata
suddividendo le modifche a seconda dei punti di controllo coinvolti; per ogni
punto di controllo sono enunziate le direttive da seguire e le modifiche
effettuate, visibili anche attraverso il relativo screenshot e/o porzioni di
codice.
Nell'ultimo capitolo vengono esposte alcune considerazioni e pensieri
riguardo l'accessibilità e la nuova concezione del web: il Web 2.0
INDICE GENERALE
CAPITOLO1 – INTRODUZIONE ALL'ACCESSIBILITA' E USABILITA' NEL WEB.......... 3
1.1 Internet e innovazione: garantire accesso all'uso delle nuove tecnologie.......................... 3
1.2 Cos'è l'accessibilità?........................................................................................................... 4
1.2.1 Definizione................................................................................................................. 4
1.2.2 barriere ideologiche e barriere tecnologiche...............................................................5
1.2.3 tecnologia e disabilità................................................................................................. 7
1.2.4 evoluzione dell'accessibilità......................................................................................10
1.3 Cos'è l'usabilità?............................................................................................................... 11
1.3.1 Definizione............................................................................................................... 11
1.3.2 Fattori di usabilità..................................................................................................... 12
1.3.3 I 10 principi euristici di Nielsen............................................................................... 13
1.3.4 I vantaggi dell'usabilità............................................................................................. 15
1.4 Accessibilità o usabilità? Analogie e differenze.............................................................. 16
1.4.1 analogie: obiettivi parzialmente sovrapposti............................................................ 16
1.4.2 differenze: metodi differenti..................................................................................... 16
1.4.3 tramite un approccio integrato delle due materie un compromesso è possibile....... 18
CAPITOLO 2: LE NORME SULL'ACCESSIBILITA' DEI CONTENUTI W3C WCAG 1.0 E
2.0................................................................................................................................................20
2.1 W3C, WAI e WCAG........................................................................................................20
2.2 le WCAG 1.0.................................................................................................................... 20
2.2.1 organizzazione delle WCAG 1.0: linee guida e priorità...........................................20
2.2.2 la dichiarazione di conformità WCAG 1.0............................................................... 24
2.2.3 linea guida 1: fornire alternative equivalenti per il contenuto audio e visivo.......... 26
2.2.4 linea guida 2: non affidarsi unicamente al colore..................................................... 27
2.2.5 linea guida 3: usare le marcature ed i fogli di stile in modo appropriato ................ 29
2.2.6 linea guida 4: rendere chiaro l'uso del linguaggio naturale ..................................... 30
2.2.7 linea guida 5: creare tabelle che si trasformino in maniera gradevole......................31
2.2.8 linea guida 6: garantire che le pagine che utilizzano tecnologie più recenti si
trasformino in maniera gradevole...................................................................................... 32
2.2.9 Linea guida 7: garantire che l'utente possa controllare i cambiamenti del contenuto
durante la loro rappresentazione........................................................................................ 34
2.2.10 linea guida 8: garantire l'accessibilità diretta delle interfacce utente incorporate.. 35
2.2.11 linea guida 9: progettare garantendo l'indipendenza dal dispositivo ..................... 35
2.2.12 linea guida 10: usare soluzioni temporanee............................................................36
2.2.13 linea guida 11: usare le tecnologie e le linee guida del W3C................................. 38
2.2.14 linea guida 12: fornire informazioni per il contesto e l'orientamento.....................40
2.2.15 linea guida 13: fornire chiari meccanismi di navigazione...................................... 40
2.2.16 linea guida 14: garantire che i documenti siano chiari e semplici.......................... 41
2.3 uno sguardo al futuro: verso le WCAG 2.0......................................................................42
2.3.1 struttura delle WCAG 2.0 ........................................................................................ 43
2.3.2 principio 1: percepibile ............................................................................................ 46
2.3.3 principio 2: fruibile .................................................................................................. 47
2.3.4 principio 3: comprensibile........................................................................................ 47
2.3.5 principio 4: durevole.................................................................................................48
CAPITOLO 3: PROGETTO “ARIANNA” (ASSISTENTE PERSONALE)........................ 49
3.1 INTRODUZIONE...................................................................................................... 49
3.2 OBIETTIVO E SPECIFICHE DEL PROGETTO.......................................................... 49
3.3 LA STRUTTURA GENERALE..................................................................................... 51
1
3.3.1 IL SOFTBOT...........................................................................................................51
3.3.2 L’INTERFACCIA GRAFICA.................................................................................52
3.4 SVILUPPO FUTURO..................................................................................................... 55
CAPITOLO 4: VALUTAZIONE DELL'ACCESSIBILITA' DEL PROGETTO “ARIANNA”
(ASSISTENTE PERSONALE).................................................................................................. 57
4.1 Valutare l'accessibilità di un sito web.............................................................................. 57
4.1.1 Introduzione.............................................................................................................. 57
4.1.2 Revisione preliminare............................................................................................... 58
4.1.3 Valutazione della conformità alle WCAG 1.0..........................................................60
4.1.4 Considerazioni per specifici contesti........................................................................ 65
Valutazione durante il processo di sviluppo...................................................................... 65
Monitoraggio costante....................................................................................................... 65
Valutazione di siti non più aggiornati................................................................................66
Valutazione di pagine web generate dinamicamente.........................................................66
4.2 Applicazione dei criteri di accessibilità al progetto “Arianna”........................................ 67
4.2.1 premessa................................................................................................................... 67
4.2.2 Strumenti utilizzati....................................................................................................68
4.2.3 Esempi di applicazioni dei criteri di accessibilità in “Arianna” .............................. 76
CAPITOLO 5 – SVILUPPI FUTURI : ACCESSIBILTA' E WEB 2.0....................................136
5.1 Introduzione....................................................................................................................136
5.2 caratteristiche principali del web 2.0..............................................................................137
5.2.1 AJAX...................................................................................................................... 137
5.2.2 Contenuto generato dall’utente ..............................................................................137
5.2.3 WCAG 2.0.............................................................................................................. 138
5.3 Possibili scenari futuri.................................................................................................... 138
BIBLIOGRAFIA – SITOGRAFIA...........................................................................................140
2
CAPITOLO1 – INTRODUZIONE
ALL'ACCESSIBILITA' E USABILITA' NEL WEB
1.1 Internet e innovazione: garantire accesso all'uso
delle nuove tecnologie
Le tecnologie per l’innovazione possono fare molto per le persone e
rappresentano, di fatto, un’opportunità per l’autonomia. Imparare ad
utilizzare le tecnologie informatiche, telematiche, e a convivere con esse
all'interno delle case, dei servizi e del territorio urbano significa,
specialmente per una persona anziana, poter prolungare i tempi e la
qualità delle proprie autonomie.
Occorre però dare una direzione a questo processo, partendo dalle
condizioni e dall’ottica di chi le usa; ciò richiede il superamento da parte
della popolazione della barriera di carattere motivazionale verso ciò che
è nuovo e sconosciuto ed un approccio facilitato ai codici in modo tale che
questi ultimi entrino nella pratica quotidiana.
E’ ragionevole pensare che se oggi esistono numerosi individui “allergici”
(anche per posizioni preconcette) e avversi alle tecnologie, siano esse
meccaniche, elettroniche o informatiche, differente sarà l'atteggiamento
della "generazione informatica”, ovvero quella dei giovani e adulti che già
utilizzano il computer.
In termini di accesso ad Internet, comunque, coloro che si trovano in
questa situazione, in particolare quelle affette da handicap fisici, sensoriali
o cognitivi, sono discriminate da una serie di difficoltà tecniche che
potrebbero essere in parte risolte da una progettazione idonea dei siti e
dei loro contenuti. A maggior ragione, considerando l’espansione del
servizio pubblico in linea, si rischia che un’ampia parte della popolazione
sia esclusa. Garantire l’accesso e assicurarne la fruizione diventa quindi
3
un nodo decisivo anche dal punto di vista della democrazia sostanziale.
1.2 Cos'è l'accessibilità?
1.2.1 Definizione
Quando si parla di accessibilità, questo termine quasi immediatamente
viene associato alla parola "disabile": per la maggior parte delle persone,
infatti, l'accessibilità è un problema legato alla disabilità fisica, cognitiva o
sensoriale e le differenze tecnologiche che spesso isolano parecchi utenti
non vengono nemmeno considerate. Finché si parla di problemi legati a
un sito Web amatoriale il fatto, pur tecnicamente grave, è ininfluente, ma
quando si parla di servizi pubblici o commerciali l'inaccessibilità crea
disservizio e perdita di guadagno.
Il punto di partenza per capire di cosa si tratta l'accessibilità è la
definizione di “accessibile”. A tale scopo sfruttiamo quella contenuta nel
glossario delle WCAG 1.0 (Web Content Accessibility Guidelines) che
scopriremo successivamente essere un punto di riferimento per la
valutazione dell'accessibilità di un sito web.
In questo senso definiamo “accessibile” come segue: Content is
accessible when it may be used by someone with a disability, ossia un
contenuto è accessibile quando può essere utilizzato da un individuo
affetto da disabilità.
Internet è oramai diventato il canale di comunicazione in cui chiunque può
trovare informazioni, accedere a servizi, consultare banche dati, offrire la
propria professionalità. In una parola: comunicare.
La comunicazione è necessaria soprattutto per quella categoria di utenti
che per motivi non legati esclusivamente alla disabilità non può accedere
ai servizi disponibili se non tramite queste tecnologie. Una delle più grandi
disabilità di questo periodo è quella "temporale": il tempo, ormai, è una
risorsa più preziosa dell'acqua e con i ritmi di lavoro e i tempi di
spostamento attuali senza l'uso di internet risulta pressoché impossibile
poter usufruire di alcuni servizi.
4
Prenotare un posto sul treno, sull'aereo, acquistare dei prodotti, pagare le
imposte sono operazioni effettuabili on-line, in qualsiasi orario e in
qualsiasi posto vi troviate.
Ma, a causa di problemi di accessibilità, non sempre le cose vanno come
dovrebbero. L'accessibilità quindi non riguarda solo le persone disabili,
ma poiché per esse è una qualità fondamentale, esiste una legge
specifica che tutela i loro diritti.
1.2.2 barriere ideologiche e barriere tecnologiche
Come per l'accessibilità nel mondo fisico, anche per l'accessibilità
informatica esistono delle barriere. A un utente di servizi informatici potrà
sembrare più semplice rimuovere una barriera informatica rispetto ad una
barriera architettonica, in quanto è diffusa l'idea che lo sviluppo di
applicazioni e di contenuti sia un'operazione semplice e che non richiede
particolari competenze tecniche. Purtroppo la riprogettazione di
applicazioni e di siti Web richiede molto tempo e ingenti risorse
economiche ed è forse per tale motivo che nella Legge 04/2004, trattata
successivamente, si richiede ai soggetti destinatari della legge
l'adeguamento dei propri servizi informatici con i rinnovi contrattuali,
auspicando un adeguamento delle modalità di sviluppo da parte delle
aziende fornitrici.
Le barriere tecnologiche dovute all'utilizzo di contenuti non standard
creano forti problemi agli utenti con disabilità, che si vedono costretti ad
aggiornare frequentemente gli ausili utilizzati. è bene ricordare che un
lettore dello schermo ha un costo di oltre 1000 euro, e che tali
applicazioni non risultano ancora inserite nei prontuari degli ausili: se
siete degli sviluppatori e pensate di inserire qualche effetto speciale in un
sito Web dedicato a un pubblico eterogeneo e che comprende utenti non
vedenti, riflettete sul fatto che ciò può contribuire alla diffusione di pratiche
di sviluppo sbagliate, che promuovono standard commerciali con
conseguente necessità di aggiornamento delle applicazioni e quindi
ingenti costi per gli utenti.
Costi ulteriori superflui, se le stesse funzionalità fossero state
5
implementate secondo le tecnologie e le raccomandazioni standard de
facto, vale a dire le raccomandazioni W3C in materia di sviluppo di
contenuti, applicazioni e sistemi per il Web.
Sviluppando secondo le linee guida internazionali del consorzio W3C
(attualmente in fase di riconoscimento anche da parte di ISO) si garantirà
il minor costo di aggiornamento dei sistemi informatici basati su tecnologie
Web nonché si otterrà la maggiore garanzia di compatibilità con le diverse
periferiche e applicazioni (browser) disponibili sul mercato.
Uno dei più grandi problemi legati all'accessibilità e alla promozione
dell'accesso universale è stata la guerra tra le diverse proposte di
standard commerciali, che hanno portato alla diffusione di programmi per
la creazione di contenuti che non producevano pagine conformi alle
raccomandazioni internazionali.
Mentre uno sviluppatore di contenuti Web che conosca le linee guida
W3C sa chiaramente come operare sul codice di una pagina HTML, un
Web designer nato nell'era degli editor visuali difficilmente conoscerà le
grammatiche formali e nella maggior parte dei casi utilizzerà elementi e
attributi in modo inopportuno.
Questo è un altro problema inerente all'accessibilità del Web, ossia le
barriere ideologiche, molto più difficili da abbattere di quelle tecnologiche:
far comprendere a un Web designer che le tabelle e gli elementi di
titolazione non vanno utilizzati a scopo decorativo, che un utente non
vedente deve poter fruire dei contenuti e che un utente ipovedente deve
poter ridimensionare i minuscoli caratteri predisposti per un menù
visualizzabile esclusivamente a risoluzioni video 1024x768 pixel su
schermo da 17 pollici è ancora oggi difficile.
È per questi motivi che l'accessibilità sino a qualche anno fa era
considerata un argomento di nicchia, un "qualcosa" utilizzato dai "puristi"
del codice che "non comprendono le potenzialità grafiche offerte dalla
rete". Grazie però a diverse iniziative, si è cercato di creare una cultura
dell'accessibilità e molti designer stanno comprendendo la necessità di
sviluppare in modo bello e accessibile, ossia abbinando una grafica
d'impatto alla possibilità di fornire l'accesso anche a chi non può fruire di
tali effetti speciali a causa di disabilità, anche di solo tipo tecnologico. -->
6
A questo punto è chiaro che per abbattere le barriere tecnologiche è
necessario abbattere prima di tutto le barriere ideologiche, facendo
chiaramente comprendere che un professionista del Web è colui che
nell'ambito della professione opera per sviluppare servizi e prodotti
secondo gli standard internazionali, vale a dire pensando tali servizi
servizi e prestazioni per realtà commerciali o pubbliche in cui
interagiscono anche utenti con disabilità.
1.2.3 tecnologia e disabilità
Grazie alle nuove tecnologie gli utenti con disabilità possono sopperire a
eventuali disfunzioni fisiche o sensoriali con i cosiddetti ausili (ossia
sistemi di aiuto), che consentono agli utenti non vedenti di poter ottenere
la lettura dello schermo, agli utenti con disabilità motorie di poter utilizzare
periferiche alternative di puntamento, ai disabili cognitivi di ottenere
rappresentazioni di contenuti testuali tramite immagini.
Alcune categorie di ausili si basano principalmente sul dialogo tra
l'ambiente operativo e l'ausilio: ciò che normalmente è gestibile tramite
tastiera o mouse viene emulato dall'ausilio. In questo caso, se parliamo di
siti Web, è necessario che tutte le funzionalità all'interno di una pagina
siano utilizzabili sia con comandi tastiera sia tramite periferiche di
puntamento, in modo che tali tecnologie possano identificare i comandi e
quindi tradurne il significato alle tecnologie assistive. Come vedremo in
alcuni capitoli del libro per ogni categoria di disabilità sono presenti diversi
ausili con caratteristiche e funzionalità differenti.
Oltre all'interfacciamento con l'ambiente operativo, molte tecnologie
assistive utilizzano i contenuti testuali come mezzo per comunicare
all'utente i contenuti di una pagina Web e/o di un'applicazione. Per
esempio, un contenuto testuale può essere letto da un lettore di schermo
di un utente non vedente o essere convertito in linguaggio dei segni per
un utente sordomuto. Allo stesso modo, la descrizione equivalente
testuale di un contenuto audio può essere utile per utenti non udenti.
Come si comprenderà con la lettura di questo libro, è di vitale importanza
per qualsiasi disabilità fornire la possibilità di rappresentare tutti i
contenuti tramite testo proprio per garantire una comprensione a
7
chiunque con qualsiasi tecnologia di navigazione.
Le realtà che creano le raccomandazioni e le normative internazionali in
materia di accessibilità come il W3C e l'ISO lavorano in stretto contatto
con le associazioni di disabili e con i produttori di tecnologie assistive al
fine di poter garantire un'evoluzione delle tecnologie. Mantenendo questo
rapporto collaborativo, gli utenti con disabilità hanno la garanzia di poter
acquistare ausili che consentono di fruire di servizi e contenuti sempre
che gli sviluppatori di pagine Web comprendano definitivamente la
necessità di sviluppare secondo tali standard. Un sito Web è come un
negozio: un utente perso e scontento può significare la perdita di diversi
clienti. Se si tratta poi di una pubblica amministrazione o di un servizio di
selezione di personale, può significare anche potenziali contenziosi legali,
tutto perché lo sviluppatore non ha voluto applicare delle chiare regole di
sviluppo internazionalmente riconosciute.
Potremmo classificare in generale 3 categorie di disabilità: disabilità
permanente, disabili con problemi di carattere sociale e culturale, disabili
con problemi tecnologici.
Con disabilità permanenti intendiamo gli utenti con problemi fisici che
possono essere per esempio di tipo motorio, di vista o udito; tra questi
citiamo:
•
•
•
•
•
cecità (per cui sarebbe opportuno avere alternative a tutti i contenuti
visuali);
ipovisione (richiede caratteri grandi, margini ampi, l'uso di colori non
abbaglianti, forte contrasto fra primo piano e sfondo, impaginazioni
semplificate);
cecità ai colori (richiede accoppiamenti di colore in cui il contrasto
tra testo e sfondo sia basato sulla differenza di luminosità piuttosto
che sulla differenza di tonalità);
sordità (richiede alternative equivalenti per tutti i componenti
auditivi);
mancanza o paralisi degli arti superiori (richiede pagine web
navigabili anche senza l'ausilio del mouse, per esempio per mezzo
di comandi vocali);
8
•
•
•
dislessia (l'uso di termini difficili o il ricorso continuo a parole
straniere può rendere molto difficile la lettura di una pagina web per
un dislessico);
epilessia (la presenza di immagini in movimento sullo schermo,
particolarmente se lo sfarfallamento avviene con una frequenza
intorno ai 20 Hz, può scatenare crisi epilettiche in soggetti
predisposti);
ritardo mentale (richiede la realizzazione di realizzare servizi web
rispettando adeguati criteri di semplicità e chiarezza espressiva).
I disabili in senso stretto sono solo una parte, e neanche la più cospicua,
dei beneficiari dell'accessibilità.
Accanto a loro elenchiamo diverse situazioni e di conseguenza diversi
utenti che possano trovarsi in situazioni di impedimenti sociali e culturali:
•
•
•
•
persone con normali problemi di vista (miopia, ipermetropia, ecc.);
la maggior parte delle persone affette da problemi alla vista inerenti
all'invecchiamento potrebbe incorrere in problemi insormontabili nel
leggere pagine scritte in caratteri piccoli;
persone anziane e/o dotate di scarsa o nulla preparazione
informatica, “spaventate” da interfacce troppo complesse, o da
richieste di plugin aggiuntivi;
persone di livello culturale basso: per rendere accessibili i contenuti
pubblicati sul web anche a persone che possiedono un bagaglio
culturale basso sarebbe opportuno definire sempre concetti
adoperati, scrivere in modo chiaro e ordinato;
persone che parlano un'altra lingua: per loro valgono gli stessi
accorgimenti per gli individui con basso livello culturale.
Infine aggiungiamo le persone che sono limitate dalla navigazione dall'uso
di strumenti hardware e software obsoleti o fuori dagli standard
tecnologici più aggiornati.
Per la prima sottocategoria intendiamo anche coloro che dispongono di
una connessione Internet lenta; accessibilità in questo caso significa
creare pagine web leggere (non con introduzioni con video o applicazioni
flash di oltre 1MB!), in cui la presentazione è separata dal contenuto e la
9
consultazione non perda senso se effettuata senza immagini.
Riguardo agli individui che dispongono e usano sistemi poco comuni,
basta pensare agli utenti che non si connettono alla rete solo con
Windows tramite Internet Explorer. Esiste una percentuale di utenti che
utilizza altri sistemi operativi come Machintosh, Linux, BeOS, Amiga o
anche diversi browser quali, Netscape, Mozilla, Opera, Konqueror, Safari,
Lynx.
Aggiungiamoci anche gli utenti che navigano utilizzando la webTV, i
celluari, i PDA, monitor con risoluzioni basse o molto grandi, monitor
monocromatici. Per questo genere di utenti accessibilità significa
progettare pagine indipendentemente dalla periferica senza ottimizzare
particolari sistemi o risoluzioni dello schermo, vale a dire pagine con
codice standard valido e altamente flessibili nella struttura.
Diventa perciò fondamentale al fine di garantire l'accessibilità al web a
livello universale concentrare l'attenzione su tutti quei casi che abbiamo
fin qui esaminato, ovvero senza escludere nessuno; non solo i disabili in
senso stretto, ma anche chi soffre di disabilità temporanee, chi ha
attrezzature speciali o obsolete, chi dispone di connessioni lente.
1.2.4 evoluzione dell'accessibilità
Negli ultimi anni l'accessibilità si sta diffondendo come argomento
centrale riguardo il Web. Il consorzio W3C sta già lavorando a delle nuove
versioni delle raccomandazioni per la creazione dei contenuti accessibili
(WCAG) e per la creazione degli strumenti di sviluppo accessibili (ATAG),
così come il consorzio IMS ha sviluppato le linee guida per la creazione di
servizi di formazione a distanza accessibili.
Da un anno a questa parte si è riscontrata inoltre una forte attività in
materia anche da parte dell'ISO (International Organization for
Standardization) organismo internazionale per la definizione degli
standard), che ha avviato diverse proposte relative all'ergonomia delle
applicazioni con riferimento all'accessibilità delle applicazioni informatiche
(ISO/TS 16071, "Ergonomics of human-system interaction - Guidance on
accessibility for human-computer interfaces") e a un nuovo documento
10
relativo all'ergonomia delle interfacce Web (ISO/CD 23973, "Software
ergonomics for World Wide Web user interfaces").
In Italia, il punto di riferimento normativo è la legge 04/2004 (Appendice
C) “Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti
informatici” e
Grazie a questa legge, sono incentivate le iniziative di promozione
dell'accessibilità: non solo strettamente riguardanti il campo della pubblica
amministrazione, ma anche le banche hanno definito delle linee guida per
l'accessibilità dei servizi di home banking, IWA/HWG ha avviato un
gruppo di lavoro per promuovere l'accessibilità nei settori dell'industria,
commercio e servizi mentre per le pubbliche amministrazioni il CNIPA ha
predisposto le regole tecniche e le metodologie di valutazione per
l'accessibilità dei siti Web.
Va anche ricordato che il 1°marzo 2006 è stata introdotta un’altra legge
per tutelare le persone disabili (Legge 67/2006 "Misure per la tutela
giudiziaria delle persone con disabilità vittime di discriminazioni" ): questa
norma dà il diritto ad agire, da soli o tramite associazioni, ogni volta che si
verifica un comportamento discriminatorio.
Anche a livello europeo stanno nascendo iniziative di promozione e
soprattutto di definizione di criteri di valutazione dell'accessibilità dei siti
Web, segno che qualcosa si sta muovendo... forse per questioni etiche,
politiche o forse per potenziali business.
1.3 Cos'è l'usabilità?
1.3.1 Definizione
La ISO ha definito l'usabilità in due norme differenti:
1. nello standard ISO/IEC 9126 viene definita come“Information
technology – Software product evalutation - Quality characteristics
and guidelines for their use” ovvero “la capacità del software di
essere compreso, usato e gradito dall'utente quando usato in
determinate condizioni”;
11
2. secondo la norma ISO 9241 viene definito come “il grado in cui un
prodotto può essere usato da particolari utenti per raggiungere certi
obiettivi con efficacia, efficienza e soddisfazione, in uno specifico
contesto d´uso”.
Sintetizzando le due definizioni l´usabilità di un sito web è data quindi da
una serie di fattori che influiscono sull'esperienza che l´utente fa
navigando nelle sue pagine, interagendo con il sistema.
1.3.2 Fattori di usabilità
Gli elementi principali che influiscono sull'usabilità di un sito sono:
•
•
•
•
•
•
•
•
•
percezione: le informazioni e i comandi necessari per l'esecuzione
dell'attività devono essere sempre disponibili e percettibili;
comprensibilità: le informazioni e i comandi necessari per
l'esecuzione delle attività devono essere facili da capire e da usare;
operabilità: informazioni e comandi sono tali da consentire una
scelta immediata della azione adeguata per raggiungere l'obiettivo
voluto;
coerenza: stessi simboli, messaggi e azioni devono avere gli stessi
significati in tutto l'ambiente;
salvaguardia della salute (safety): indica le caratteristiche che
deve possedere l'ambiente per salvaguardare e promuovere il
benessere psicofisico dell'utente;
sicurezza: indica le caratteristiche che l'ambiente deve possedere
per fornire transazioni e dati affidabili, gestiti con adeguati livelli di
sicurezza;
trasparenza: l'ambiente deve comunicare il suo stato e gli effetti
delle azioni compiute. All'utente devono essere comunicate le
necessarie informazioni per la corretta valutazione della dinamica
dell'ambiente;
apprendibilità: indica le caratteristiche che l'ambiente deve
possedere per consentire l'apprendimento del suo utilizzo da parte
dell'utente in tempi brevi e con minimo sforzo;
aiuto e documentazione: fornire funzioni di aiuto come guide in
12
•
•
•
linea e documentazione relative al funzionamento dell'ambiente. Le
informazioni di aiuto devono essere facili da trovare e focalizzate sul
compito dell'utente;
tolleranza agli errori: l'ambiente deve prevenire gli errori e, qualora
questi accadano, devono essere forniti appropriati messaggi che
indichino chiaramente il problema e le azioni necessarie per
recuperarlo;
gradevolezza: indica le caratteristiche che l'ambiente deve
possedere per favorire e mantenere l'interesse dell'utente;
flessibilità: l'ambiente deve tener conto delle preferenze individuali
e dei contesti.
1.3.3 I 10 principi euristici di Nielsen
Jakob Nielsen è colui che più di ogni altro lega il suo nome all’ usabilità
del web.
Nel suo portale, Nielsen espone i principi euristici che ha ricavato tramite
analisi fattoriale di 249 errori comuni emersi in varie ricerche precedenti. I
fattori emersi sono 10, e Nielsen li espone sul suo sito. Questi 10 principi
si riferiscono in buona parte a 3 grandi aree di problematicità:
• Orientamento e Navigazione: rendere cioè disponibili e
comprensibili tutti quegli strumenti che consentono all'utente di
capire immediatamente dove si trova, da dove è venuto e dove può
andare all'interno del sito web.
• Prevenzione e gestione di errori, senza allarmismi e con linguaggio
comune: gli errori dovrebbero prima di tutto essere prevenuti, ma se
ciò non fosse possibile, sarebbe necessario offrire all'utente la
possibilità di tornare sempre indietro, e si dovrebbe sempre
spiegare cosa sta succedendo, con un linguaggio semplice e chiaro,
evitando i messaggi tecnici del server.
• Coerenza interna, aderenza agli standard e ai vincoli del web: si
deve definire uno stile omogeneo per l'intero sito, non disorientare il
lettore con cambi di carattere tipografico, dimensioni, colori e layout
senza un motivo che sia prima di tutto semantico.
13
Vediamo ora le 10 euristiche di Nielsen sull'usabilità delle interfacce:
1. visibilità dello stato del sistema; il sistema deve sempre tenere
informato l’utente su cosa sta facendo, fornendo un adeguato
feedback in un tempo ragionevole. Sapere se un oggetto è un link e
dove porta. Utilizzare un segnale di attività in corso (clessidra, barra
di caricamento, messaggio testuale, etc.);
2. corrispondenza tra sistema e mondo reale; il sistema deve parlare il
linguaggio dell’utente, con parole, frasi e concetti a lui familiari. Uso
di messaggi testuali, icone, azioni dal significato condiviso da tutti
( es. "salva con nome", icona "cestino", azione "copia e incolla");
3. controllo e libertà; l’utente deve avere il controllo del contenuto
informativo e muoversi liberamente tra i vari argomenti. Evitare
procedure costrittive troppo lunghe (iscrizioni), evitare percorsi
predefiniti senza possibili scorciatoie ed evitare azioni non volute
dall’utente (apertura automatica di pagine non richieste);
4. consistenza e standard; l’utente deve aspettarsi che le convenzioni
del sistema siano valide per tutta l’interfaccia. Riportare in ogni
pagina alcuni elementi di riconoscimento (logo, stile grafico), dare la
sensazione di essere sempre nello stesso ambiente;
5. prevenzione dell’errore; evitare di porre l’utente in situazione
ambigue, critiche e che possono portare all’errore. Dare la
possibilità di tornare indietro;
6. riconoscimento anziché ricordo; le istruzioni per l’uso del sistema
devono essere ben visibili e facilmente recuperabili; produrre layout
semplici e schematici, non contare sulla capacità dell’utente di
ricordare il posizionamento degli oggetti che caratterizzano le
pagine;
7. flessibilità d’uso; offrire all’utente la possibilità di un uso differenziale
(a seconda della sua esperienza) dell’interfaccia, offrire una
navigazione gerarchica per i meno esperti, offrire scorciatoie per i
più esperti;
8. design ed estetica minimalista; dare maggior importanza al
contenuto che all’estetica, evitare di accentuare oggetti irrilevanti o
14
raramente necessari (immagini grandi), evitare che il contenuto
informativo della pagina sia messo in secondo piano, evitare che
l’utente si distragga o si confonda;
9. aiuto all’utente; aiutare l’utente a riconoscere, diagnosticare e
recuperare l’errore. I messaggi di errore devono essere espressi in
linguaggio comprensibile (senza codici) e devono indicare in modo
preciso il problema e suggerire una soluzione. Chiedere sempre
conferma per una azione importante;
10. documentazione; anche se il sistema dovrebbe essere usabile
senza documentazione è preferibile che essa sia disponibile. La
documentazione deve essere: facile da reperire, focalizzata sul
compito dell’utente, strutturata in un insieme di passi comprensibili.
1.3.4 I vantaggi dell'usabilità
L'usabilità è un elemento molto importante nella progettazione di un sito
web, perché influisce sulla quantità di visitatori di un sito. Sembra infatti
che il 60% delle persone che cercano una informazione su internet
finiscano per rinunciare senza aver trovato l´oggetto della loro ricerca. Per
lo più non tornano a visitare il sito dove non hanno trovato soddisfazione.
Pertanto, l´usabilità di un sito dipende da quanto il modo con cui viene
progettato coincide con le aspettative dell'utente.
Progettare un sito web usabile implica evidentemente un certo sforzo, ma
sono indubbi i vantaggi che ne conseguono, e principalmente:
•
miglioramento nella qualità del prodotto;
•
riduzione dei tempi di sviluppo;
•
riduzione degli errori;
•
miglioramento dell'efficacia;
•
aumento della soddisfazione degli utenti;
•
riduzione dei costi di formazione e assistenza utenti;
•
miglioramento nell'immagine dell'organizzazione.
15
1.4 Accessibilità o usabilità? Analogie e differenze
1.4.1 analogie: obiettivi parzialmente sovrapposti
Usabilità e accessibilità sono effettivamente materie affini: hanno
entrambe come scopo il miglioramento delle interfacce web e hanno
entrambe una doppia applicabilità: a livello valutativo, ovvero per
verificare l'usabilità o l 'accessibilità di un sito già esistente, e a livello
progettuale, ovvero come supporto alla realizzazione di un sito affinché
questo sia accessibile o usabile.
Entrambe, inoltre, partono dal presupposto che i siti dovrebbero essere
fruiti attraverso qualunque browser, caldeggiando il rispetto degli standard
nella scrittura del codice HTML; ma per entrambe questo è solo un
presupposto e la correttezza formale del codice, da sola, non rende un
sito accessibile né tanto meno usabile. Qualcuno sembra addirittura
pensare che prima o poi una delle due materie si fondi con l'altra, dato
che crede che abbiano gli stessi fini. Può capitare che l'esperto di
accessibilità, una volta soddisfatti i requisiti di compatibilità tra browser, si
convinca di aver realizzato un sito usabile o che un programmatore
esperto di usabilità cada nello stesso tranello pensando di realizzare un
sito accessibile.
1.4.2 differenze: metodi differenti
Le due discipline presentano invece sostanziali differenze sia a livello
concettuale sia, soprattutto, a livello metodologico. Innanzitutto, mentre
per essere accessibile un sito deve garantire la fruibilità a qualunque
utente, indipendentemente da disabilità e da dispositivi usati per la lettura
delle pagine, un sito usabile è sì caratterizzato dalla fruibilità, ma solo
relativamente al proprio target di riferimento; questo perché ciò che è
chiaro e semplice per una tipologia di utenti non lo sarà necessariamente
per un'altra. Da un lato la priorità è data all'accesso ai contenuti e
dall'altro è data alla loro comprensione.
16
La differenza maggiore tra accessibilità e usabilità si riscontra però
osservandone i metodi. La realizzazione di un sito accessibile passa
attraverso il rispetto di determinate norme (WCAG 1.0 , vedi capitolo 2 o i
requisiti della Legge Stanca vedi appendice) e la valutazione
dell'accessibilità è appannaggio di strumenti automatici o semiautomatici.
La realizzazione di un sito usabile, invece, avviene attraverso
l'interpretazione di modelli più che il rispetto di regole e, soprattutto, la
valutazione dell'usabilità vede coinvolti in prima persona i potenziali utenti.
Da una parte la progettazione è orientata alle caratteristiche del sito,
dall'altra al processo produttivo.
Pensare all'accessibilità, non significa soltanto progettare affinché un sito
possa essere letto attraverso qualunque dispositivo, ma anche generare
strutture ipertestuali chiare e contenuti comprensibili. In questo caso
l'usabilità, o meglio, i metodi dell'usabilità, possono andare incontro alla
progettazione di un sito accessibile intervenendo ai livelli in cui
l'applicazione di specifiche tecniche non è sufficiente: nel progetto
dell'architettura dell'informazione e nel riscontro dell'effettiva fruibilità del
sito attraverso i test con utenti.
In assenza di un progetto di usabilità, infatti, l'applicazione di requisiti
tecnici può essere insufficiente a garantire la comprensione di un
ipertesto e talvolta può perfino nuocere alla navigazione. Per esempio, le
regole dell'accessibilità insegnano ad agevolare la lettura tramite uno
screen reader sostituendo i troppo generici link "clicca qui" con dei link
contestualizzati, ma la scelta di quale link utilizzare implica i metodi di
progettazione e valutazione dell'usabilità; la contestualizzazione infatti
non può basarsi semplicemente sul buon senso degli sviluppatori.
Sempre a proposito di screen reader, le WCAG chiedono di specificare la
lingua del documento e di indicare il cambiamento di lingua per ogni
parola straniera al fine di migliorare la lettura con uno strumento
multilingue. Un cambiamento nella lingua del sintetizzatore, però, produce
anche variazioni nel timbro della voce e altera il ritmo della lettura, il che
può risultare più fastidioso dell'ascoltare una parola straniera letta con
una pronuncia sbagliata.
Al di là delle esigenze di correttezza formale del codice, che già la
avvicinano all'usabilità, le teorie alla base dell'accessibilità si rivelano
17
estremamente utili anche nella progettazione di un sito usabile. Gli studi
sull'accessibilità hanno il grande merito di aver introdotto delle specifiche
tecniche per migliorare la fruibilità dei contenuti da parte degli utenti,
siano essi disabili o meno.
Un sito inaccessibile al suo target di riferimento sarà ovviamente
inusabile. Se quindi spogliamo l'accessibilità dell'universalità che la
contraddistingue, mantenendo le teorie che ne sono alla base, avremo un
eccezionale supporto alla progettazione di siti usabili. Molti dei problemi di
usabilità sono infatti legati alla scarsa accessibilità dei contenuti. Se il mio
target è composto da persone con più di 50 anni, un testo scritto a
caratteri troppo piccoli risulterà poco leggibile, così come dei link troppo
ravvicinati rischiano di generare problemi di navigazione anche a persone
senza limitazioni nei movimenti fini. La ricerca dell'accessibilità ha
permesso di comprendere al meglio i limiti di tutti gli utenti e, soprattutto,
di progettare e realizzare siti che tegano conto di tali limiti.
1.4.3 tramite un approccio integrato delle due materie un
compromesso è possibile
Il reperimento di utenti disabili per l'esecuzione di test di
usabilità/accessibilità può però rivelarsi un'impresa ardua. Se però il
raggiungimento dell'accessibilità deriva da motivi civici e non da obblighi
legali, i test possono essere effettuati anche con utenti normalmente abili
simulando, attraverso la navigazione con tecnologie assistive (come gli
screen reader) o con un browser testuale, le possibili difficoltà a cui
andrebbe incontro un utente disabile. In questo modo è possibile mettere
in luce molti dei problemi che derivano da un'interfaccia non accessibile.
Un ottimo strumento per la simulazione di disabilità visive è la barra
dell'accessibilità: un'estensione di Explorer (gratuita per uso personale e
non commerciale) che permette da un lato di effettuare valutazioni
semiautomatiche dell'accessibilità e dall'altro di modificare l'aspetto della
pagina per quanto riguarda immagini, testi, colori e script.
L'accessibilità "per tutti" resta comunque un obiettivo difficile. Nel
momento in cui si afferma che un sito per essere accessibile deve anche
essere usabile, si deve tener conto di un vincolo fondamentale
dell'usabilità: la sua relazione con un target di riferimento. All'aumentare
18
della quantità di utenti a cui un sito è accessibile, diminuirà l'usabilità del
sito stesso; è importante quindi raggiungere un compromesso affinché
l'accessibilità non sia soltanto il punteggio dato da un validatore, ma la
reale possibilità da parte di un'utenza sempre più ampia di raggiungere i
contenuti del web.
Concludendo possiamo dire che il primo per migliorare davvero i siti e i
servizi che rivolgiamo ai nostri utenti è dunque quello di capire entrambe
le discipline per poter trarre gli appropriati vantaggi a seconda delle nostre
esigenze e dei nostri obiettivi.
19
CAPITOLO 2: LE NORME SULL'ACCESSIBILITA'
DEI CONTENUTI W3C WCAG 1.0 E 2.0
2.1 W3C, WAI e WCAG
WAI è l'acronimo di Web Accssibility Iniziative, ovvero “Iniziativa per
l'accessibilità al Web”. Si trattadi una sezione del World Wide Web (W3C).
Il W3C è un organismo che, ormai dal 1994, ha il compito di definire i
linguaggi e le procedure standard per rendere il web uno strumento
democratico ed universale.
I gruppi di lavoro creati all'interno del WAI hanno prodotto negli anni una
serie di raccomandazioni tecniche, mirate a dare agli sviluppatori gli
strumenti per rendere accessibili non solo i contenuti del web, ma anche i
programmi per navigare in rete nonché quelli utilizzati per produrre e
pubblicare applicazioni web e siti accessibili.
2.2 le WCAG 1.0
2.2.1 organizzazione delle WCAG 1.0: linee guida e priorità
In questa sezione sono analizzate le 14 linee guida che compongono le
WCAG 1.0 (pubblicate il 5 maggio 1999) che spiegano come rendere i
contenuti di Internet accessibili anche alle persone con disabilità.
Le linee guida sono indirizzate sia agli sviluppatori di contenuti Web
(autori di pagine e siti Web, nonché chi si occupa della gestione dei
contenuti) sia a chi si occupa della programmazione.
Aderendo alle linee guida WCAG 1.0 si otterrà il risultato di rendere i
contenuti Web più facilmente fruibili da tutti gli utenti, indipendentemente
dalla tecnologia di navigazione utilizzata (per esempio, normali browser,
browser basati su dispositivi di sintesi vocale, telefoni cellulari, e così via)
o da eventuali limitazioni non legate esclusivamente alla disabilità (come
dover operare in ambienti rumorosi, in stanze sottoilluminate o
sovrailluminate, impossibilità di impiegare le mani): la conformità a queste
linee guida consentirà agli utenti di reperire le informazioni desiderate in
20
modo più efficace e veloce.
È importante inoltre chiarire che linee guida contenute nelle WCAG 1.0
non devono essere viste come una limitazione nell'utilizzo di immagini,
video, elementi audio e così via, in quanto invece suggeriscono come
rendere i contenuti multimediali accessibili a un pubblico più vasto.
Le quattordici linee guida contenute in questo documento rappresentano i
principi generali per lo sviluppo accessibile e si basano sui due principi
generali: assicurare una trasformazione gradevole nonché rendere il
contenuto comprensibile e navigabile.
garantire una trasformazione gradevole
Seguendo queste linee guida, gli sviluppatori di contenuti sono in grado di
creare pagine che si trasformano con risultato gradevole: queste pagine
saranno di fatto accessibili nonostante le possibili disabilità degli utenti,
siano esse fisiche, sensoriali, cognitive, dovute al tipo di lavoro o alle
barriere tecnologiche. Di seguito si riportano alcuni dei principi chiave per
la progettazione di pagine che si trasformino con eleganza contenuti nelle
linee guida:
•
•
•
•
separare la struttura dalla presentazione, conoscendo la differenza
che intercorre tra contenuto, struttura e presentazione;
fornire contenuti testuali (compresi i testi equivalenti). Il testo può
essere riprodotto secondo modalità disponibili a quasi tutti i
dispositivi di navigazione e accessibili a quasi tutti gli utenti;
creare documenti fruibili anche se l'utente non può vedere e/o
sentire fornendo informazioni che abbiano lo stesso obiettivo o
funzione di audio e video in maniera che sia adatta anche a canali
sensoriali alternativi. Questo non vuol dire creare una versione
audio preregistrata dell'intero sito per renderlo accessibile a utenti
non vedenti in quanto questi possono utilizzare le tecnologie
assistive (es: dei lettori dello schermo) per riprodurre per intero
l'informazione testuale presente in una pagina;
creare documenti che non si basino su una specifica periferica. Le
pagine dovrebbero essere utilizzabili senza mouse, su monitor
piccoli, a bassa risoluzione, in bianco e nero, senza schermo, solo
21
con output di voce oppure di testo, ecc.
All'interno delle WCAG 1.0, Le linee guida dalla numero 1 alla numero 11
si occupano principalmente di ciò che riguarda la trasformazione
gradevole.
rendere il contenuto comprensibile e navigabile
Gli sviluppatori di contenuti dovrebbero rendere il contenuto
comprensibile e navigabile: questo significa, oltre all'usare un linguaggio
chiaro e semplice, il fornire meccanismi facilmente comprensibili per la
navigazione all'interno della stessa pagina e tra pagine diverse.
Dotare le pagine di strumenti di navigazione e informazioni di
orientamento ne incrementa l'accessibilità e l'usabilità: non tutti gli utenti
difatti sono in grado di comprendere e utilizzare indicazioni di tipo visivo,
come immagini sensibili (mappe immagine), barre di scorrimento
proporzionali, frame affiancati o gli elementi grafici normalmente utilizzati
da utenti senza disabilità visive. Gli utenti possono inoltre perdere
informazioni relative al contesto, qualora possano fruire solamente di una
parte dei contenuti di una pagina: per esempio, se accedono alla pagina
una parola per volta (con sistemi di sintesi vocale o display braille),
oppure una sezione alla volta (schermi di piccole dimensioni o caratteri
molto ingranditi, nel caso di utenti ipovedenti). Tabelle di grandi
dimensioni, elenchi, menù e altri elementi di questo tipo potrebbero non
essere comprensibili da parte di alcune categorie di utenti se non
vengono fornite informazioni che ne favoriscano l'orientamento. Le linee
guida dalla numero 12 alla numero 14 si occupano principalmente dei
principi da seguire per rendere il contenuto navigabile e comprensibile.
Ogni linea guida include:
•
l numero della linea guida;
•
la dichiarazione della linea guida;
•
la spiegazione della linea guida;
•
una lista delle definizioni dei punto di controllo.
Le definizioni dei punti di controllo in ogni linea guida specificano i
requisiti per la conformità alle linee guida. Ogni definizione dei punti di
controllo include:
22
•
il numero del punto di controllo;
•
la dichiarazione del punto di controllo;
•
•
•
la priorità del punto di controllo;
in alcuni casi note informative, esempi chiarificatori o riferimenti
incrociati con relazione a linee guida o punti di controllo;
il collegamento a una sezione delle "Tecniche per le Linee Guida
per l'Accessibilità dei Contenuti per il Web 1.0" dove vengono
discusse implementazioni ed esempi per il punto di controllo.
Il documento sulle tecniche si occupa dettagliatamente di ogni punto di
controllo fornendo esempi attraverso l'utilizzo di Hypertext Markup
Language (HTML), Cascading Style Sheets (CSS), Synchronized
Multimedia Integration Language (SMIL), Mathematical Markup Language
(MathML)., descrive inoltre tecniche per la validazione e la valutazione dei
documenti, e comprende l'indice degli elementi e attributi HTML (e delle
tecniche che li utilizzano). Queste tecniche sono state progettate per
tenere traccia dei cambiamenti della tecnologia e dovrebbero essere
aggiornate frequentemente: in questo libro è disponibile un capitolo dove
vengono affrontati esempi pratici di applicazione delle linee guida per ogni
singolo punto di controllo, ispirandosi al documento delle tecniche e
utilizzando risorse ed esempi pratici condivisi nel Web al fine di aiutare
l'autore nelle problematiche legate all'applicazione di queste linee guida.
Il consiglio è di frequentare le risorse on-line specifiche di accessibilità,
molte delle quali vengono spesso citate all'interno del libro, dove è
possibile leggere le discussioni e le opinioni di coloro che creano le linee
guida e di chi di fatto contribuisce alla loro diffusione.
Ogni punto di controllo possiede un livello di priorità. Il livello di priorità
rispecchia l'impatto che tale punto possiede sull'accessibilità. I livelli di
priorità sono assegnati come segue:
[Priorità 1]
Lo sviluppatore di contenuti Web deve conformarsi al presente punto di
controllo. In caso contrario, a una o più categorie di utenti verrà precluso
l'accesso alle informazioni presenti nel documento. La conformità a
questo punto di controllo costituisce un requisito base affinché alcune
23
categorie di utenti siano in grado di utilizzare documenti Web.
[Priorità 2]
Lo sviluppatore di contenuti Web dovrebbe conformarsi a questo punto di
controllo. In caso contrario, a una o più categorie di utenti risulterà difficile
accedere alle informazioni nel documento. La conformità a questo punto
consente di rimuovere barriere significative per l'accesso a documenti
Web.
[Priorità 3]
Lo sviluppatore di contenuti Web può tenere in considerazione questo
punto di controllo. In caso contrario, una o più categorie di utenti sarà in
qualche modo ostacolata nell'accedere alle informazioni presenti nel
documento. La conformità a questo punto migliora l'accesso ai documenti
Web.
La priorità di alcuni punti di controllo può variare al verificarsi di alcune
condizioni che nei casi specifici vengono precisate.
2.2.2 la dichiarazione di conformità WCAG 1.0
In questa sezione delle linee guida WCAG 1.0 è indicato come creare una
dichiarazione di validità attestante la conformità dei contenuti per il Web a
questo documento.
Gli autori della dichiarazione sono i soli responsabili di quanto dichiarano
e per l'utilizzo delle icone di conformità e se l'oggetto della dichiarazione
viene modificato successivamente alla data di dichiarazione, il dichiarante
ha la responsabilità di aggiornare la dichiarazione. Chi si occupa dello
sviluppo delle dichiarazioni è incoraggiato alla conformità alle linee guida
più recenti.
Una dichiarazione di conformità deve indicare il livello di conformità
raggiunto:
•
•
livello di Conformità A: sono soddisfatti tutti i punti di controllo di
priorità 1;
livello di Conformità Doppia-A: sono soddisfatti tutti i punti di
controllo di priorità 1 e 2;
24
•
livello di Conformità Tripla-A: sono soddisfatti tutti i punti di
controllo di priorità 1, 2 e 3.
Nota: i livelli di conformità sono indicati in testo esteso (per esempio,
Doppia-A invece di AA), in modo che possano essere compresi se letti da
un sintetizzatore vocale.
La presentazione di tale dichiarazione è consentita in due forme: forma
testuale e con utilizzo delle icone di conformità.
Per la forma testuale, la dichiarazione di conformità per essere
considerata positiva deve includere le seguenti informazioni:
•
il titolo/la versione delle Linee Guida: "Linee Guida per
l'Accessibilità dei contenuti per il Web 1.0";
•
l'indirizzo Web dove risalire alle Linee Guida di riferimento:
http://www.w3.org/TR/WCAG10;
•
il livello di conformità soddisfatto: A, Doppia-A, o Tripla-A.
•
l'ambito della dichiarazione (una pagina, un sito o una porzione
ben definita di un sito).
Un esempio di dichiarazione in HTML:
<p>Questa pagina è conforme alle "Linee Guida per
l'Accessibilità dei contenuti per il Web 1.0" del <abbr
lang="en" title="the World Wide Web
Consortium">W3C</abbr>, disponibili all'indirizzo Web
http://www.w3.org/TR/1999/ WAI-WEBCONTENT-19990505, per il
livello di conformità Doppia-A.</p>
Si auspica che i dichiaranti modifichino o ritirino una dichiarazione nel
caso sia possibile dimostrare che tale dichiarazione non è valida. È
importante evidenziare che attualmente non è possibile validare le
dichiarazioni di conformità in modalità completamente automatica in
quanto, come vedremo nei capitoli di applicazione delle WCAG, molti
punti di controllo delle linee guida richiedono una verifica personale del
progettista.
Se si decide di formalizzare la dichiarazione tramite le tre icone di
conformità predisposte dal W3C, è necessario apporre, su ciascuna
pagina che si dichiara essere conforme, l'icona equivalente al grado di
accessibilità raggiunto inserendo un collegamento alla pagina di
spiegazione W3C relativa alla dichiarazione. Negli esempi seguenti il
25
codice è stato modificato per essere conforme alla specifica XHTML.
Nota: la presenza di una icona di conformità non implica che il W3C abbia
revisionato e validato la pagina, essendo come già detto di esclusiva
responsabilità di chi la espone.
2.2.3 linea guida 1: fornire alternative equivalenti per il
contenuto audio e visivo
A causa di disabilità o della indisponibilità di determinate tecnologie per
alcuni utenti potrebbe essere impossibile fruire direttamente di immagini,
filmati, suoni, applet e altri contenuti di questo tipo. Questi utenti possono
comunque accedere ai contenuti se questi includono un'informazione
equivalente al contenuto visivo o audio. L'informazione equivalente deve
avere la stessa funzione del contenuto visivo e audio che sostituisce: per
esempio, un testo equivalente all'immagine di una freccia rivolta verso
l'alto che rinvii a un sommario potrebbe essere "Vai al sommario". In
alcuni casi, un equivalente dovrebbe descrivere anche l'aspetto del
contenuto visivo (come per grafici, pannelli o diagrammi complessi) o il
suono del contenuto audio (per esempio, i dei contenuti audio come le
spiegazioni di determinate azioni utilizzate nell'istruzione).
Questa linea guida rimarca l'importanza del fornire equivalenti testuali al
contenuto non testuale (immagini, audio pre-registrati, video). La
potenzialità degli equivalenti testuali consiste nella loro capacità di essere
rappresentati secondo modalità accessibili a persone con differenti
disabilità, ricorrendo a tecnologie diverse: il testo può essere facilmente
indirizzato verso la sintesi vocale e il display braille, e può essere
presentato visivamente (in vari formati) sul monitor del computer o su
carta. La sintesi vocale è fondamentale per le persone non vedenti e per
chi soffre delle difficoltà di lettura che spesso accompagnano le disabilità
cognitive, di apprendimento e la sordità così come il braille è essenziale
per i sordo-ciechi e per tutte le persone la cui unica disabilità sensitiva sia
la cecità. Il contenuto testuale invece va a beneficio sia degli utenti sordi
sia della maggioranza degli utenti Web. Anche il fornire equivalenti non
testuali (come immagini, video e segmenti audio pre-registrati) del testo
scritto è di beneficio per alcune categorie di utenti, specialmente per gli
illetterati o per le persone che hanno difficoltà di lettura. Nei filmati o nelle
26
presentazioni visuali, il linguaggio del corpo o altri comportamenti a
commento dell'azione potrebbero non essere accompagnati da una
informazione audio sufficiente a trasmettere l'informazione stessa. A
meno che non venga fornita una descrizione verbale di questo contenuto
visivo, le persone che non possono vedere (o guardare) il contenuto
visivo non saranno in grado di percepirlo. Questa linea guida è formata da
cinque punti di controllo, di seguito riportati, che comprendono quattro
punti di controllo per la priorità 1 e uno per la priorità 3.
punti di controllo
1.1Fornire un equivalente testuale per ogni elemento non di testo.
[Priorità
1.2 Fornire collegamenti di testo ridondanti per ogni zona attiva di
una mappa immagine sul lato server (server-side). [Priorità 1]
1.3 Fino a quando i programmi utente non potranno leggere
automaticamente ad alta voce il suo equivalente testuale fornire una
descrizione audio delle informazioni essenziali del filmato di una
presentazione multimediale. [Priorità 1]
1.4 Per ogni presentazione multimediale temporizzata,
sincronizzare le alternative equivalenti con la presentazione.
[Priorità 1]
1.5 Fino a quando i programmi utente non renderanno disponibili
equivalenti testuali per collegamenti di mappe immagine sul lato
client, fornire collegamenti di testo ridondanti per ogni zona attiva
nella mappa immagine sul lato client (client side). [Priorità 3]
2.2.4 linea guida 2: non affidarsi unicamente al colore
I problemi legati alla percezione del colore sono più diffusi di quanto si
pensi, ed hanno cause ed effetti diversi: si pensi che studi attuali fanno
notare che addirittura una persona su dodici ne soffre.
Per veicolare l'informazione il colore viene usato in maniera massiccia
anche sul Web, e ciò può rendere difficoltosa o addirittura impossibile la
navigazione o l'uso di un software per queste persone. Se inoltre
pensiamo al costante innalzamento dell'età media dei navigatori abituali,
27
è facile comprendere come per un designer sia importante conoscere
queste problematiche, in modo da evitare l'uso di combinazioni
cromatiche che siano di fatto un ostacolo alla corretta fruizione dei
contenuti nelle pagine Web da realizzare. Alcune disabilità visive non
consentono una corretta visualizzazione dei colori rendendo quindi di
difficile comprensione alcuni accostamenti cromatici.
Ipotizzando di partire da un'immagine originale contenente dei fiori di
colore rosa immersi in un insieme di foglie verdi si potranno avere le
seguenti variazioni cromatiche:
●
●
●
un utente effetto da deutranopia avrà una visione del fiore di colore
grigio-azzurrino anziché rosa mentre vedrà le foglie di colore verde
oliva anziché il classico colore verde prato.
un utente affetto da protanopia avrà una visione del fiore similare
all'utente con deutranopia mentre vedrà le foglie di un colore
tendente al giallo senape anziché il classico colore verde prato.
un utente affetto da tritanopia avrà una visione del fiore di colore
rosa chiaro mentre vedrà le foglie di un colore tendente all'azzurro.
Pensiamo quindi al caso in cui si forniscano informazioni basandosi su
abbinamenti di colore che alcune categorie di utenti possono confondere
tra di loro (ad esempio i soggetti affetti da daltonismo) oppure soggetti
che possono non vedere un determinato colore.
All'interno di questo libro è presente un capitolo curato da Roberto Ellero
sull'accessibilità dei colori in cui sarà possibile approfondire questo
interessante argomento.
La serie dei punti di controllo relativa alla seconda linea guida riguarda in
generale la definizione e il corretto utilizzo del colore nelle pagine Web,
coinvolgendo tutti e tre i livelli di priorità definiti dalle linee guida.
punti di controllo
2.1 Garantire che tutta l'informazione veicolata dal colore sia
disponibile anche in assenza di colori. [Priorità 1]
2.2 Garantire che le combinazioni di colori tra il primo piano e lo
sfondo forniscano un sufficiente contrasto se osservati da qualcuno
con deficit percettivi del colore o quando visualizzati su un monitor
28
in bianco e nero. [Priorità 2 per immagini - Priorità 3 per il testo]
2.2.5 linea guida 3: usare le marcature ed i fogli di stile in
modo appropriato
Uno dei maggiori problemi nello sviluppo dei siti Web è il mancato rispetto
della corretta sintassi del codice: l'usare una sintassi scorretta non
permette una corretta interpretazione delle pagine da parte dei browser e
quindi, di fatto, non consente una completa fruibilità dei contenuti da parte
degli utenti.
Usare le marcature in modo improprio, non seguendo le specifiche,
impedisce quindi l'accessibilità della pagina Web. Il cattivo uso dei
marcatori per effetti di presentazione, come l'utilizzo di tabelle (in molti
casi annidate) per l'impaginazione o l'utilizzo degli elementi di intestazione
(H1, H2, H3) per cambiare la dimensione dei caratteri, complica la
comprensione e/o o la navigazione dell'organizzazione della pagina
all'utente con disabilità, specialmente se di tipo visivo o cognitivo.
Inoltre, l'uso di marcature di presentazione per rappresentare una
struttura (come simulare una tabella di dati con l'elemento HTML PRE) al
posto di marcature strutturali rende difficile la comprensione di una pagina
a chi utilizza altri strumenti di lettura.
Gli sviluppatori di pagine Web possono essere tentati di usare (o usare
male) le strutture di formattazione della pagina per rispettare una
presunta compatibilità con i vecchi browser. È necessario però essere
coscienti del fatto che questa modalità operativa causa problemi di
accessibilità, e quindi bisogna ben riflettere su quanto valga la pena di
utilizzare una particolare formattazione della pagina se tale struttura
rende il documento inaccessibile, ad esempio ad un lettore di schermo.
È pertanto necessario che lo sviluppatore assuma come punto centrale di
riferimento per la progettazione il concetto e la necessità del separare il
contenuto dalla presentazione, utilizzando la sintassi corretta prevista dal
linguaggio di marcatura prescelto (HTML, XHTML, MathML, altri),
ricorrendo ai fogli di stile per la presentazione grafica degli elementi.
Questa linea guida è costituita da sette punti di controllo, tutti per la
29
priorità 2.
punti di controllo
3.1 Quando esiste un linguaggio di marcatura adatto, per veicolare
informazione usare un marcatore piuttosto che le immagini. [Priorità
2]
3.2 Creare documenti che rispettino le grammatiche formali. [Priorità
2]
3.3 Usare i fogli di stile per controllare l'impaginazione e la
presentazione. [Priorità 2] 3.4 Usare unità di misura relative anziché
assolute nei valori degli attributi del linguaggio di marcatura e per i
valori delle proprietà del foglio di stile. [Priorità 2]
3.5 Usare elementi di intestazione per veicolare la struttura del
documento e usarli in modo conforme alle specifiche. [Priorità 2]
3.6 Marcare le liste ed elencare le voci della lista in modo
appropriato. [Priorità 2]
3.7 Marcare le citazioni. [Priorità 2]
2.2.6 linea guida 4: rendere chiaro l'uso del linguaggio
naturale
L'utilizzo della definizione della lingua principale in un documento aiuta il
browser nell'individuarne la codifica, ma risulta utile anche ai motori di
ricerca per una corretta catalogazione delle pagine. Anche gli utenti che
utilizzano tecnologie assistive beneficeranno dell'indicazione riguardo il
cambio della lingua: disponendo di una sintesi vocale in lingua italiana, un
browser leggerà le parole in lingua straniera in modo pressoché
incomprensibile e quindi la mancata applicazione delle linee guida di
questo gruppo rende inaccessibile alcune parti magari importanti del
contenuto.
Inoltre, l'utilizzo di acronimi e abbreviazioni aiuta la navigazione degli
utenti e i motori di ricerca a catalogare correttamente i contenuti nonché
la comprensione delle sigle spesso utilizzate in siti di pubblico interesse.
Questa linea guida è formata da tre punti di controllo, di cui uno di priorità
30
1 e due di priorità 3.
punti di controllo
4.1 Identificare con chiarezza i cambiamenti nel linguaggio naturale
del testo di un documento e in ogni equivalente testuale. [Priorità 1]
4.2 Specificare il significato di ogni abbreviazione o acronimo nel
documento laddove compaia per la prima volta. [Priorità 3]
4.3 Identificare il linguaggio naturale principale di un documento.
[Priorità 3]
2.2.7 linea guida 5: creare tabelle che si trasformino in
maniera gradevole
Le tabelle sono sicuramente l'elemento maggiormente utilizzato nelle
pagine HTML, ma troppo spesso in modo non corretto: quante volte
abbiamo utilizzato un editor visuale e, per creare un menù allineato a
destra con i contenuti a sinistra, creato una tabella a due colonne? Se
non abbiamo seguito le indicazioni del W3C di questa Linea guida, il sito
è già inaccessibile.
Le tabelle, infatti, dovrebbero essere utilizzate per le informazioni che
realmente richiedano l'uso di questo elemento, ossia per le tabelle di dati.
Troppo spesso, invece, le tabelle vengono utilizzate per impaginare (le
cosiddette tabelle di layout), mentre a questo scopo dovrebbero essere
utilizzati i fogli di stile (linea guida 3). L'utilizzo delle tabelle per layout è
consentito solo se vengono seguiti alcuni accorgimenti previsti da questa
linea guida. Se una tabella dati non viene chiaramente distinta da una
tabella di layout, i programmi utente (lettori dello schermo o altre
applicazioni che linearizzano i contenuti delle tabelle) possono riscontrare
problemi di interpretazione dei contenuti delle celle.
I punti di controllo di questa linea guida sono a beneficio soprattutto degli
utenti che accedono alla pagina Web con ausili audio (quindi non solo i
lettori dello schermo ma anche, per esempio, un navigatore satellitare
sulla vostra automobile) o persone che riescono a fruire sequenzialmente
soltanto di alcune porzioni della pagina come utenti non vedenti o
ipovedenti, che utilizzano sistemi di sintesi vocale o display braille, o che
31
vedono le pagine sul display di un computer palmare.
La linea guida 5 è formata da sei punti di controllo, due per ogni livello di
accessibilità con specifiche per tabelle di dati, tabelle di layout e per
entrambi i tipi di tabelle.
Il mancato rispetto di tali punti di controllo rende il contenuto delle tabelle
inaccessibile agli utenti che utilizzano sistemi alternativi di lettura dei
contenuti di una pagina Web, quindi non solo agli utenti non vedenti.
punti di controllo
5.1 Per le tabelle dati, identificare le intestazioni per righe e colonne.
[Priorità 1]
5.2 Per le tabelle dati che hanno due o più livelli logici di intestazioni
di righe o colonne, usare marcatori per associare le celle di dati e le
celle di intestazione. [Priorità 1]
5.3 Non usare le tabelle di impaginazione a meno che la tabella non
sia comprensibile se linearizzata. [Priorità 2]
5.4 Se si utilizza una tabella di impaginazione non utilizzare alcun
marcatore di struttura a scopo di formattazione. [Priorità 2]
5.5 Per ogni tabella definire un sommario dei contenuti. [Priorità 3]
5.6 Fornire abbreviazioni per le etichette di intestazione. [Priorità 3]
2.2.8 linea guida 6: garantire che le pagine che utilizzano
tecnologie più recenti si trasformino in maniera gradevole
È ormai risaputo che gli sviluppatori sono sempre propensi all'utilizzo di
nuove tecnologie, che consentono di risolvere particolari situazioni, come
la visualizzazione di un prodotto commerciale in tre dimensioni (3D). Con
l'evolversi delle tecnologie troppo frequentemente non si considera la
retro-compatibilità, ossia la necessità di progettare un contenuto valido
anche per gli utenti che non possiedono queste tecnologie o che per
diverse motivazioni non desiderano utilizzarle. L'uso di un browser datato,
oppure la disponibilità di una connessione a bassa velocità, che non
consente la fruibilità di animazioni e/o applicazioni Web, è una situazione
frequente. Pensiamo, per esempio, ai contenuti sviluppati con
32
Macromedia Flash versione 7: per poter fruire dei filmati, gli utenti che non
posseggono l'ultima versione del plug-in dovranno scaricarlo
obbligatoriamente. Questo è un problema, in particolar modo se lo
sviluppatore ha previsto che l'utente debba interagire con i filmati
(implementando, per esempio, una serie di menu attivabili esclusivamente
se il filmato viene riprodotto).
Altri strumenti, come le WebTV di prima generazione (che utilizzavano
HTML 3.2 come linguaggio di codifica dei contenuti) non riescono a
interpretare i fogli di stile (CSS) di nuova generazione ed è pertanto
necessario creare una struttura di pagina che possa essere letta anche
da tali tecnologie.
In queste situazioni, la domanda da porsi è: tutti gli utenti potranno fruire
dei contenuti indipendentemente da qualsiasi piattaforma, sistema di
navigazione e tecnologie assistive essi utilizzino?
Questa linea guida è formata da cinque punti di controllo di cui tre di
priorità 1 e due di priorità 2.
punti di controllo
6.1 Organizzare i documenti in modo che possano essere letti
anche in assenza dei fogli di stile. [Priorità 1]
6.2 Garantire che all'aggiornamento dei contenuti dinamici vengano
aggiornati anche i contenuti equivalenti. [Priorità 1]
6.3 Garantire che le pagine siano utilizzabili quando script, applet, o
altri oggetti di programmazione sono disabilitati oppure non
supportati. Se questo non è possibile, fornire informazione
equivalente in una pagina accessibile alternativa. [Priorità 1]
6.4 Garantire che i gestori di eventi per gli script e le applet siano
indipendenti dai dispositivi di input. [Priorità 2]
6.5 Garantire che il contenuto dinamico sia accessibile oppure
fornire una presentazione o una pagina alternativa. [Priorità 2]
33
2.2.9 Linea guida 7: garantire che l'utente possa controllare
i cambiamenti del contenuto durante la loro
rappresentazione
Alcune persone con disabilità cognitive o visive non riescono a leggere
testo in movimento a causa della velocità di scorrimento oppure non sono
in grado di leggerlo affatto in quanto il movimento può causare una
distrazione tale da rendere illeggibile il resto dei contenuti presenti nella
pagina. I lettori di schermo non sono in grado di leggere testo in
movimento mentre persone con disabilità fisiche potrebbero non essere in
grado di muoversi con velocità o precisione sufficienti ad interagire con
oggetti in movimento mentre altri con testi lampeggianti possono incorrere
in attacchi epilettici.
Questa linea guida è formata da cinque punti di controllo di cui uno di
priorità 1 e quattro di priorità 2: è importante far notare che tutti i punti di
controllo seguenti presuppongono un certo livello di responsabilità da
parte degli sviluppatori fino a quando i programmi utente (gli "user agent")
non forniranno adeguati meccanismi di controllo delle diverse
caratteristiche.
punti di controllo
7.1 Fino a quando i programmi utente non permetteranno agli utenti
di controllare lo sfarfallio, evitare di far sfarfallare lo schermo.
[Priorità 1]
7.2 Fino a quando i programmi utente non permetteranno agli utenti
di controllare il lampeggiamento, evitare di far lampeggiare il
contenuto. [Priorità 2]
7.3 Fino a quando i programmi utente non permetteranno agli utenti
di bloccare il contenuto in movimento, evitare il movimento nelle
pagine. [Priorità 2]
7.4 Fino a quando i programmi utente non forniranno la possibilità di
bloccare l'autoaggiornamento, non creare pagine che si
autoaggiornano periodicamente. [Priorità 2]
7.5 Fino a quando i programmi utente non forniranno la capacità di
bloccare l'autoreindirizzamento, non usare marcature per
reindirizzare le pagine automaticamente. Piuttosto, configurare il
34
server in modo che esegua i reindirizzamenti. [Priorità 2]
2.2.10 linea guida 8: garantire l'accessibilità diretta delle
interfacce utente incorporate
Quando un oggetto incorporato possiede una propria interfaccia,
l'interfaccia (così come l'interfaccia dello stesso browser) deve essere
accessibile. Questo significa che ogni interfaccia incorporata deve
rispettare i principi di sviluppo di design accessibile, come per esempio
l'indipendenza dal tipo di periferica (device) utilizzata, l'operatività tramite
tastiera, ecc. Se l'interfaccia dell'oggetto incorporato non può essere resa
accessibile, deve essere fornita una soluzione alternativa accessibile.
Per lo sviluppo di queste interfacce è necessario far riferimento alle
seguenti linee guida:
•
User Agent Accessibility Guidelines 1.03.
•
Authoring Tools Accessibility Guidelines 1.04.
punti di controllo
8.1 Fare in modo che elementi di programmi come script e applet
siano direttamente accessibili o compatibili con le tecnologie
assistive. [Priorità 1 (se importante) o 2]
2.2.11 linea guida 9: progettare garantendo l'indipendenza
dal dispositivo
Abbiamo già detto come i visitatori di un sito Web possano
potenzialmente utilizzare diversi dispositivi di input/output per accedere ai
contenuti di una pagina : mouse, tastiere, comandi vocali, ecc. Accesso
indipendente dal dispositivo significa quindi garantire agli utenti la
possibilità di interagire con il programma utente o con il documento per
mezzo del dispositivo di input (output) preferito. Al fine di garantire
l'accesso a tutti gli utenti, è necessario che le pagine vengano create in
modo che qualsiasi dispositivo ne consenta la fruibilità: creare pagine che
interagiscono esclusivamente con comandi tramite mouse rendono
35
inaccessibile i contenuti agli utenti che utilizzano la tastiera (o
un'emulazione della tastiera) o sistemi di comando vocale. Per esempio,
fornendo equivalenti testuali di mappe immagine o per immagini utilizzate
come identificazione per un collegamento. In genere, le pagine che
permettono l'accesso tramite tastiera sono accessibili anche con input
vocale o interfaccia a linea di comando. Questa linea guida è formata da
cinque punti di controllo di cui uno di priorità 1, due di priorità 2 e due di
priorità 3.
punti di controllo
9.1 Fornire mappe immagine sul lato client invece di mappe
immagine sul lato server, con l'eccezione dei casi nei quali le zone
non possono essere definite con una forma geometrica valida.
[Priorità 1]
9.2 Garantire che ogni elemento dotato di una sua specifica
interfaccia possa essere gestito in una modalità indipendente dal
dispositivo. [Priorità 2]
9.3 Negli script, specificare gestori di evento logici piuttosto che
gestori di evento dipendenti dal dispositivo. [Priorità 2]
9.4 Creare un ordine logico di tabulazione fra i collegamenti, i
controlli dei moduli e gli oggetti. [Priorità 3]
9.5 Fornire scorciatoie da tastiera per i collegamenti importanti
(compresi quelli nelle mappe immagine lato client), per i controlli dei
moduli e per i gruppi di controlli dei moduli. [Priorità 3]
2.2.12 linea guida 10: usare soluzioni temporanee
Molte delle linee guida e dei punti di controllo contengono le parole "fino a
quando i programmi utente". Questi punti di controllo sono classificati
come "temporanei", nel senso che il gruppo di lavoro sulle Web Content
Accessibility Guidelines (WCAG Working Group) li ritiene validi e
necessari per l'accessibilità del Web al momento della pubblicazione di
questo documento. Tuttavia, il gruppo di lavoro non ritiene che questi
punti di controllo in futuro saranno necessari, quando le tecnologie Web
avranno incorporato le capacità e le caratteristiche che sono state
36
anticipate in queste linee guida. Per esempio, i browser più datati non
permettono agli utenti di spostarsi su caselle per l'immissione di testo
vuote mentre i lettori di schermo di vecchia generazione leggono le liste di
collegamenti consecutivi come se fossero un unico collegamento. È
quindi difficile, se non impossibile, accedere a questi elementi attivi. Allo
stesso modo, cambiare la finestra attiva oppure far comparire delle nuove
finestre può disorientare notevolmente gli utenti, che possono smarrirsi
all'interno della pagina.
Nel mese di dicembre 2003, all'interno del gruppo di lavoro delle WCAG si
è iniziato a discutere se sia preferibile fornire una versione migliorata delle
WCAG 1.0 rimuovendo alcune di queste indicazioni, senza però
modificare di fatto i livelli di conformità dei contenuti: si sta quindi
pensando al rilascio delle WCAG 1.0 Second Edition che, al momento di
stesura di questo libro, sono ancora in fase di ipotesi.
La linea guida è formata da cinque punti di controllo di cui due relativi alla
priorità 2 e tre relativi alla priorità 3 e si applicano fino a quando gli
interpreti (comprese le tecnologie assistive) non risolveranno questi
aspetti.
punti di controllo
10.1 Fino a quando i programmi utente non permetteranno agli
utenti di bloccare l'apertura di nuove finestre, non fare apparire popup o finestre di altro tipo e non cambiare la finestra attiva senza
informare l'utente. [Priorità 2]
10.2 Fino a quando i programmi utente non supporteranno esplicite
associazioni fra etichette e controlli dei moduli, garantire che
l'etichetta sia posizionata correttamente per tutti i controlli dei moduli
che hanno etichette associate implicitamente. [Priorità 2]
10.3 Fino a quando i programmi utente (comprese le tecnologie
assistive) non rappresenteranno in modo corretto il testo affiancato,
fornire un testo lineare alternativo (nella pagina attiva o in altra
pagina) per tutte le tabelle che dispongono testo su colonne
parallele e andando a capo. [Priorità 3]
10.4 Fino a quando i programmi utente non gestiranno in maniera
corretta i controlli vuoti, inserire caratteri predefiniti come
37
segnaposto nelle caselle per l'immissione di testo a una o a più
righe. [Priorità 3]
10.5 Fino a quando i programmi utente (comprese le tecnologie
assistive) non rappresenteranno in modo distinto collegamenti
adiacenti, inserire caratteri stampabili (delimitati da spazi), non
facenti parte dei collegamenti, per separare i collegamenti adiacenti.
[Priorità 3]
2.2.13 linea guida 11: usare le tecnologie e le linee guida del
W3C
Il World Wide Web Consortium (W3C) è stato costituito nel 1994 con la
finalità di portare il Web alle sue massime potenzialità: raccomandazioni
come HTML, CSS, XML nascono dalle attività del Consorzio esplicate
attraverso i gruppi di lavoro (Working Group). Ciò che ha reso
fondamentale l'attività del W3C è l'attiva partecipazione alle sue attività
dei maggiori produttori di tecnologie e di browser, che operano all'interno
di questi gruppi per creare gli standard del futuro.
Questa linea guida raccomanda l'uso delle tecnologie del W3C (come
HTML e CSS) per diversi motivi:
•
•
•
le tecnologie W3C integrano nelle raccomandazioni i riferimenti alle
linee guida per l'accessibilità;
le specifiche W3C subiscono una revisione preliminare per
assicurarsi che gli elementi di accessibilità siano presi in
considerazione fin dalla fase progettuale;
le specifiche W3C sono sviluppate all'interno di un processo aperto
e con il consenso dell'industria del settore.
Molti dei formati che non appartengono alle specifiche W3C (come PDF o
Shockwave) richiedono l'uso di plug-in proprietari o di applicazioni
specifiche senza i quali non possono essere visualizzati, altrimenti non
sarà possibile navigare con interpreti standard (comprese le tecnologie
assistive). Evitare quindi l'utilizzo di caratteristiche proprietarie, fuori
standard W3C (elementi, attributi, proprietà, estensioni) contribuirà nel
rendere le pagine maggiormente accessibili ad un numero elevato di
38
persone formato da utenti con diversi sistemi di hardware e software. Per
il rispetto delle linee guida sull'accessibilità, quando si utilizzano
tecnologie non accessibili (proprietarie o meno) è necessario fornire
pagine equivalenti accessibili. D'altra parte questo è anche necessario
quando si utilizzano le tecnologie W3C e non sia possibile generare
contenuti accessibili. Se prevedete di usare queste tecnologie,
assicuratevi che si trasformino in maniera gradevole (linea guida 6). La
conversione di documenti PDF, PostScript, RTF e altri nei linguaggi di
marcatura del W3C (HTML, XML) non sempre corrisponde alla creazione
di un documento accessibile. Dopo il processo di conversione, è
necessario quindi validare ogni pagina generata per verificarne
l'accessibilità: se una pagina non è convertibile in modo semplice, è
necessario cercare di renderla accessibile tramite le tecnologie definite
dal W3C oppure, nel caso questo non fosse possibile, è necessario
fornire una versione in formato HTML o testo semplice. Un intero capitolo
di questo libro è dedicato alla validazione dei contenuti, con riferimenti ed
esemplificazioni dove chiaramente viene spiegato che la validazione non
può essere totalmente automatica, ma richiede il supporto umano.
Questa linea guida è formata da quattro punti di controllo, di cui uno di
priorità 1, due di priorità 2 ed uno di priorità 3.
punti di controllo
11.1 Utilizzare le tecnologie W3C quando sono disponibili e sono
appropriate per un certo compito usando le versioni più recenti
quando sono supportate dai programmi utente. [Priorità 2]
11.2 Evitare l'utilizzo di caratteristiche disapprovate dal W3C.
[Priorità 2]
11.3 Fornire agli utenti l'informazione necessaria perché possano
ricevere i documenti in modo che si adattino alle loro preferenze
(per lingua, per tipo di contenuto, ecc.). [Priorità 3]
11.4 Se, nonostante ogni sforzo, non è possibile creare una pagina
accessibile, fornire un collegamento a una pagina alternativa che si
riferisca alle tecnologie W3C, che sia accessibile, che contenga
informazioni (o funzionalità) equivalenti e sia aggiornata con la
stessa frequenza della pagina originale inaccessibile. [Priorità 1]
39
2.2.14 linea guida 12: fornire informazioni per il contesto e
l'orientamento
Raggruppare gli elementi e il fornire informazione contestuale sulle
relazioni fra gli elementi è utile a tutti gli utenti in quanto le relazioni
complesse fra parti di una pagina possono essere difficili da interpretare
per persone con invalidità cognitive o per alcune disabilità di tipo visivo.
Questa linea guida è formata da quattro punti di controllo di cui una di
priorità 1 e tre di priorità 2.
punti di controllo
12.1 Assegnare un titolo a ogni frame per facilitarne l'identificazione
e la navigazione. [Priorità 1]
12.2 Descrivere lo scopo dei frame e il modo in cui questi
interagiscono se non è evidente solo tramite i titoli dei frame.
[Priorità 2]
12.3 Dividere i grandi blocchi di informazione in gruppi più
maneggevoli quando è naturale ed appropriato. [Priorità 2]
12.4 Associare esplicitamente le etichette ai loro controlli. [Priorità 2]
2.2.15 linea guida 13: fornire chiari meccanismi di
navigazione
Meccanismi di navigazione chiari e coerenti sono importanti per le
persone con invalidità cognitive o per i non vedenti, e comunque giovano
a tutti gli utenti. Quando ad esempio si legge un libro, diversi indicatori ci
informano sulla posizione attuale: numeri di pagina, capitoli, titoli,
sottolineature del testo sono punti di riferimento durante la lettura.
Cosa accade invece per un sito? Se un utente, utilizzando un motore di
ricerca, raggiunge una pagina interna al vostro sito, sono disponibili
informazioni sufficientemente chiare sulla posizione della pagina nel sito?
Il vostro visitatore riuscirà a trovare quel che cerca?
A queste domande rispondono positivamente i siti Web che rispettano i
40
punti di controllo di questa linea guida: 10 punti di controllo, di cui quattro
relativi alla priorità 2 e sei alla priorità 3.
punti di controllo
13.1 Identificare con chiarezza la destinazione di ogni collegamento.
[Priorità 2] 13.2 Fornire metadati per aggiungere alle pagine ed ai
siti informazioni di tipo semantico.[Priorità 2]
13.3 Fornire informazioni sulla configurazione generale di un sito
(per esempio, una mappa oppure un indice dei contenuti). [Priorità
2]
13.4 Usare meccanismi di navigazione in modo coerente. [Priorità 2]
13.5 Fornire barre di navigazione per evidenziare e dare accesso ai
meccanismi di navigazione. [Priorità 3]
13.6 Raggruppare i collegamenti correlati, identificare i gruppi (per i
programmi utente) e, fino a quando i programmi utente non lo
consentiranno, fornire un modo per saltare il gruppo. [Priorità 3]
13.7 Se sono fornite funzionalità di ricerca, rendere possibili diversi
tipi di ricerca per differenti livelli di abilità e per preferenze differenti.
[Priorità 3]
13.8 Posizionare l'informazione più significativa all'inizio delle
intestazioni, dei paragrafi, delle liste, ecc. [Priorità 3]
13.9 Fornire informazioni sulle raccolte di documenti, ossia
documenti composti da più pagine. [Priorità 3]
13.10 Fornire un mezzo per saltare i contenuti ASCII multilinea
(ASCII Art). [Priorità 3]
2.2.16 linea guida 14: garantire che i documenti siano chiari
e semplici
Una disposizione coerente della pagina, una grafica riconoscibile e un
linguaggio comprensibile giovano a tutti gli utenti, aiutando
particolarmente le persone con disabilità cognitive o con difficoltà di
lettura. Tuttavia, è bene assicurarsi che le immagini abbiano equivalenti
41
testuali per i non vedenti, gli ipovedenti, o per qualsiasi utente che non
possa o abbia scelto di non visualizzare la grafica, secondo quanto
definito dalla Linea guida 1 delle WCAG 1.0.
L'uso di un linguaggio chiaro e semplice promuove una comunicazione
efficace. Per persone con disabilità cognitive o dell'apprendimento,
l'accesso all'informazione scritta può essere difficoltoso. L'uso di un
linguaggio chiaro e semplice giova inoltre anche alle persone la cui
madrelingua sia diversa dalla vostra, comprese le persone che
comunicano essenzialmente con il linguaggio dei segni. Questa linea
guida è formata da tre punti di controllo, di cui uno di priorità 1 e due di
priorità 3, e conclude le WCAG 1.0.
punti di controllo
14.1 Utilizzare un linguaggio più chiaro e semplice possibile che sia
adatto al contenuto del sito. [Priorità 1]
14.2 Integrare il testo con presentazioni visive o audio nei casi in cui
possano facilitare la comprensione della pagina. [Priorità 3]
14.3 Creare uno stile di presentazione coerente fra le pagine.
[Priorità 3]
2.3 uno sguardo al futuro: verso le WCAG 2.0
Le WCAG 1.0, attualmente punto di riferimento per l'accessibilità dei
contenuti per il Web risalgono al 1999, considerando che tale documento
ha richiesto uno sviluppo di circa 2 anni.
I gruppi di lavoro del W3C per le WCAG, stanno sviluppando le nuove
versioni delle linee guida. I parametri seguenti possono essere considerati
al momento come un punto di riferimento sulle aspettative dei gruppi di
lavoro riguardo al futuro dell'accessibilità del Web, ma non come delle
norme; al momento restano solo delle specifiche in corso di definizione.
Non essendo documenti normativi non sono applicabili, ma possono
essere una base di studio per comprendere come si intenda risolvere
delle problematiche relative alle precedenti versioni delle linee guida.
42
Uno dei maggiori problemi da risolvere delle WCAG 1.0 è sicuramente il
limite dell'ambito di applicazione, in quanto la raccomandazione si basa
esclusivamente su HTML: basta considerare, per esempio, che
raccomandazioni come XHTML 1.0/1.1, SVG 1.0, RDF 1.0, sono
successive all'uscita delle WCAG 1.0. Dopo l'uscita delle WCAG 1.0 si
sono ampiamente affermati standard "proprietari" come Adobe PDF o
Macromedia Flash, tecnologie non definite dal W3C e quindi non
integrabili nelle raccomandazioni del consorzio.
Un altro problema delle WCAG 1.0 è legato alla certificazione dei risultati
di validazione: risulta difatti impossibile effettuare una certificazione
dell'accessibilità per tutti i punti di controllo delle WCAG 1.0, in quanto
determinati punti di controllo hanno carattere soggettivo (per esempio, i
punti della Linea guida 14 sulla chiarezza del linguaggio).
2.3.1 struttura delle WCAG 2.0
Il W3C ha ritenuto necessario aggiornare le attuali WCAG 1.0 in modo da
garantirne maggiore chiarezza nell'applicazione pratica, soprattutto per il
recepimento nelle normative nazionali. Allo stesso tempo, visto il
diffondersi dell'utilizzo di tecnologie proprietarie il W3C ha invitato i
produttori di tali tecnologie a sviluppare delle proprie regole di
accessibilità invitando gli sviluppatori ad applicarle all'interno dei propri
progetti.
A differenza delle WCAG 1.0, la versione attualmente in elaborazione non
è specifica per l'HTML, ma è orientata a tutte le tecnologie Web, anche
proprietarie. A questo proposito, le specifiche tecniche relative a
tecnologie proprietarie nonché esempi pratici di applicazione saranno
disponibili nei siti dei produttori, in coordinamento con il gruppo di lavoro
per le WCAG.
Per soddisfare quest'ultimo punto, il gruppo di lavoro del W3C per le
WCAG 2.0 ha deciso di definire quattordici linee guida con relativi punti di
controllo (il numero esatto è ancora in fase di definizione e vengono
definiti "Livelli di test di verifica di successo") nelle quali non ci si addentra
nella specificità dei linguaggi.
43
L'obiettivo generale delle WCAG 2.0 è la generazione di contenuti per il
Web che siano percettibili, fruibili e comprensibili per le differenti tipologie
di utenti e tecnologie di navigazione assistita sia oggi che nel futuro.
Sono quattro quindi i principi su cui si basano le diciannove linee guida
che andremo ad analizzare nelle pagine di questo capitolo:
•
percepibile;
•
fruibile;
•
comprensibile;
•
durevole.
Una delle novità delle WCAG 2.0 è l'abbandono delle Priorità per i punti di
controllo, che ora vengono definiti Success Criteria (test di verifica di
successo) e articolati su tre livelli:
[Livello 1]
Richiede di raggiungere un livello minimo di accessibilità attraverso i
linguaggi di marcatura, script o altre tecnologie che interagiscono
con i programmi utente, includendo le tecnologie assistive e che
possono essere applicati ragionevolmente a tutte le risorse web.
[Livello 2]
Richiede di incrementare l'accessibilità del livello precedente
garantendo maggiore dialogo tra i programmi utente conformi alle
UAAG ed i contenuti web e/o garantendo a tutti gli utenti, anche se
soggetti a disabilità, di poter utilizzare i contenuti web attraverso i
normali programmi utente. Anche in questo caso le linee guida
possono essere applicati ragionevolmente a tutte le risorse web.
[Livello 3]
Prevede test di verifica supplementari, che vanno oltre i livelli 1 e 2
che possono essere applicati per rendere i siti Web accessibili ad
un numero maggiore di utenti per tutte o per particolari disabilità.
Nelle WCAG 2.0 sono definite quattro attestazioni di conformità in cui
chiaramente si definisce come prerequisito il rispetto dei punti di controllo
del livello 1 per tutti i livelli successivi alla conformità al livello A:
•
WCAG 2.0 A: se vengono rispettati tutti i Success Criteria del livello
44
1 per tutte le linee guida.
•
•
•
WCAG 2.0 A+: se vengono rispettati tutti i Success criteria del livello
1 per tutte le linee guida e alcuni Success criteria del livello 2.
WCAG 2.0 AA: se vengono rispettati tutti i Success Criteria del
livello 1 per tutte le linee guida e tutti i Success Criteria del livello 2
per tutte le linee guida.
WCAG 2.0 AAA: se vengono rispettati tutti i Success Criteria del
livello 1 per tutte le linee guida e tutti i Success Criteria del livello 2
e del livello 3.
La dichiarazione di conformità ha dei requisiti minimi da soddisfare. É
pertanto necessario dichiarare:
•
che la risorsa (qualsiasi contenuto del Web) soddisfi tutti i criteri di
successo per il livello selezionato di tutte le linee guida;
•
la versione delle linee guida ed URI di riferimento;
•
la finalità della dichiarazione di conformità;
•
l'elenco dei test di verifica di successo superati positivamente;
•
la data di creazione della dichiarazione di conformità.
La domanda posta più frequentemente al gruppo di lavoro è relativa alla
necessità di adeguare tutte le vecchie pagine Web conformi alle WCAG
1.0 alla nuova versione delle WCAG 2.0.
É stato quindi deciso di consentire una dichiarazione congiunta, simile
alla seguente:
"I contenuti creati o modificati sino al giorno 6 luglio 2004 sono conformi
alle WCAG 1.0 A mentre i contenuti creati o modificati dal giorno 6 luglio
2004 ad oggi sono conformi alle WCAG 2.0 A."
Le attuali WCAG 2.0 sono articolate su tre livelli di informazione. Il primo
livello è il documento nel suo complesso, suddiviso in una introduzione,
quattro principi (percepibile, operabile, comprensibile, durevole), 14 linee
guida (ciascuna corredata di test di verifica di successo, definizioni,
vantaggi, esempi), una appendice con definizioni, riferimenti e altre
informazioni di supporto. Il secondo è un insieme di documenti tecnici con
liste di controllo relative a specifiche tecnologie che alla data di
45
pubblicazione del libro non è ancora stato organizzato. Il terzo livello
includerà esempi di codice, screenshot e informazioni specifiche alle
diverse tecnologie (HTML, CSS, script lato server e lato client, SVG,
SMIL, XML), per ottenere la conformità alle linee guida secondo diversi
approcci.
2.3.2 principio 1: percepibile
Il principio numero uno si riferisce alla percepibilità dei contenuti, vale a
dire alla possibilità di poter accedere al contenuto almeno in modalità
testuale.
È necessario quindi garantire che tutti i contenuti siano presentati in modo
da poter essere percepiti da qualsiasi utente - ad esclusione delle
informazioni o delle funzionalità che non possono essere descritte in
modo testuale (per esempio, le immagini da una webcam in tempo reale).
linee guida
Per i contenuti non testuali, fornire un testo equivalente che abbia lo
stesso scopo o fornisca le stesse informazioni del contenuto non testuale,
ad esclusione di quando lo scopo del contenuto non testuale è di
generare un'esperienza sensitiva specifica (ad esempio, musica ed arte
visiva) e in questo caso è sufficiente una etichetta o una descrizione.
1.1 Fornire alternative in formato testuale per tutti i contenuti non
testuali.
1.2 Fornire media equivalenti sincronizzati per le presentazioni
dipendenti dal tempo.
1.3 Garantire che le informazioni, le funzionalità e la struttura siano
separabili dalla presentazione.
1.4 Per le presentazioni visive, rendere facilmente distinguibili le
parole e le immagini principali dallo sfondo.
1.5 Per le presentazioni uditive, rendere facilmente distinguibile il
parlato e l'audio principale dai suoni di sfondo. [Linea guida di livello
2]
46
2.3.3 principio 2: fruibile
L'utilizzo di tastiera - e che l'utente abbia la possibilità di intervenire
nell'esecuzione di tali funzionalità: l'impossibilità ad esempio di poter
operare tramite tastiera rende inaccessibili i servizi agli utenti che
utilizzano tecnologie assistive basate sui comandi tastiera (per esempio, i
lettori dello schermo).
linee guida
2.1 Rendere operabili tutte le funzionalità tramite tastiera o tramite
interfaccia in emulazione di tastiera.
2.2 Consentire agli utenti di controllare le limitazioni di tempo nella
loro lettura o interazione a meno che degli specifici eventi in tempo
reale o delle prove rendano impossibile tale controllo.
2.3 Consentire agli utenti di disattivare la rappresentazione dei
contenuti che possono causare attacchi di epilessia fotosensitiva.
2.4 Facilitare la capacità degli utenti di orientarsi e muoversi
all'interno del contenuto. [Linea guida di livello 2]
2.5 Aiutare l'utente ad evitare gli errori e rendere semplici le
modalità per la loro correzione [Linea guida di livello 2 ]
2.3.4 principio 3: comprensibile
Il principio numero tre si riferisce alla comprensibilità dei contenuti, vale a
dire alla capacità di rendere chiari e semplici i contenuti. Questo principio
di fatto corrisponde, estendendone le caratteristiche, alla linea guida
numero 14 delle Linee guida per l'accessibilità ai contenuti del Web 1.0
(WCAG 1.0), la quale prevede che i documenti siano chiari e semplici e
quindi di facile comprensione per contrastare l'ulteriore esclusione dal
Web delle persone con problemi di lettura o disabilità cognitive. É bene
ricordare tale punto in quanto contenuto nella Risoluzione del Parlamento
Europeo (2002)0325 sulla comunicazione della Commissione "eEurope
2002: accessibilità e contenuto dei siti Internet delle amministrazioni
pubbliche" (COM (2001) 529 - C5-0074/2002 - 2002/2032(COS)).
linee guida
47
3.1 Garantire che sia possibile determinare il significato del
contenuto.
3.2 Organizzare il contenuto in modo costante da "pagina a pagina"
e rendere prevedibile il comportamento delle componenti interattive.
[Linea guida di livello 2]
2.3.5 principio 4: durevole
Il principio numero due si riferisce all'evolvibilità delle tecnologie, vale a
dire alla possibilità di poter interagire con i contenuti e con le eventuali
interfacce personalizzate attuali e future.
Questo significa sviluppare cercando di utilizzare le ultime tecnologie
disponibili attualmente ma allo stesso tempo mantenendo la compatibilità
con le precedenti nonché operatività con le più diffuse tecnologie
assistive.
É necessario garantire quindi l'uso di le tecnologie all'avanguardia,
supportate dalle attuali tecnologie che presumibilmente saranno
utilizzabili anche con tecnologie future.
linee guida
4.1 Utilizzare le tecnologie rispettando le specifiche.
4.2 Garantire che le interfacce utente siano accessibili o è prevista
una alternativa accessibile.
48
CAPITOLO 3: PROGETTO “ARIANNA”
(ASSISTENTE PERSONALE)
3.1 INTRODUZIONE
Il progetto dell’assistente personale (denominato progetto “Arianna”) è
stato ideato per consentire al cittadino di poter disporre di un punto di
contatto personalizzato e diretto con il sistema sanitario e in particolare
con gli utenti appartenenti alla ASUR Zona Territoriale 7 di Ancona.
Tale progetto aiuterà in maniera particolare quelle categorie di persone
quali disabili e non completamente autosufficienti, che possono così
trovare nell’assistente personale un valido aiuto al fine di portare a
termine determinati processi.
Le tecnologie informatiche e comunicative dei nostri giorni possono
permettere di creare interfacce in grado di migliorare, rendere intuitiva e
semplificare l’interazione tra il personale medico e il cittadino, fornendogli
una serie di servizi che possano aiutarlo a mettere in atto misure
preventive a far incontrare le sue esigenze e richieste con l’assistenza
erogata dal sistema sanitario, ad utilizzare strumenti concreti in grado di
aumentare il livello d’autonomia e risolvere i problemi di vita quotidiana.
Tutto questo ha lo scopo di migliorare la qualità di vita del cittadino e
quindi anche di aggiornarlo in merito alle nuove strutture e competenze
messe a disposizione dalle aziende sanitarie.
Queste nuove tecnologie devono portare alla definizione di nuovi servizi
che siano di integrazione alle attività svolte dal personale medico, in
particolare dai medici di base e dagli specialisti, al fine di alleggerire il loro
carico lavorativo.
3.2 OBIETTIVO E SPECIFICHE DEL PROGETTO
L’assistente personale è di fatto un mezzo di comunicazione tra il
paziente e il medico di medicina generale che lo ha in cura o tra il
49
cittadino ed il personale specialistico che può informarlo sulla prevenzione
o sulla cura di determinati disturbi.
L’obiettivo finale è quindi quello di realizzare un’interfaccia utente
intelligente che sia in grado di migliorare le attuali capacità informative
fornite dal portale della Zona Sanitaria Locale di Ancona, superando così
il basso utilizzo dei servizi on line da parte dei cittadini. Ciascun utente
riuscirà ad accedere alla propria pagina personale, all’interno della quale
potrà trovare numerosi servizi informativi. Nell’interazione con l’interfaccia,
l’utente viene seguito da un assistente virtuale che ne traccia gli attuali
obiettivi e che è in grado di rispondere a richieste in linguaggio naturale.
Nella fase di sviluppo dell’interfaccia sono state raccolte, attraverso una
serie di interviste rivolte al personale medico sanitario che opera
all’interno dell’ASUR Zona Territoriale 7, le specifiche del progetto. In
questi colloqui si è provato ad individuare quali fossero le richieste dei
cittadini e pazienti, ponendo particolare attenzione ai problemi di
comunicazione e cercando le possibili soluzioni in grado di risolverli. I
colloqui hanno portato alla definizione di strategie che permettessero di
intensificare il contatto dell’assistito con il sistema sanitario, senza
aumentare la mole di lavoro a carico del personale medico. Si è cercato
anzi di introdurre dei servizi che potessero supportarli nelle loro attività,
semplificando così l’interazione con i pazienti. Infine la successiva
formalizzazione dei requisiti è avvenuta all’interno di riunioni che hanno
coinvolto gli amministratori della rete e del sistema informativo aziendale
assieme al team di sviluppatori del progetto.
50
3.3 LA STRUTTURA GENERALE
Il sistema consiste in un’interfaccia utente suddivisa in due pannelli
principali. Un pannello superiore in cui viene caricato il sofbot (software
che cerca di stabilire una interazione con l’assistito) ed un pannello
inferiore, costituito da una semplice interfaccia grafica composta da
collegamenti e pulsanti.
Figura 3.1: Interfaccia dell'assistente personale
3.3.1 IL SOFTBOT
Il softbot comunica con il paziente usando il linguaggio naturale e il testo
scritto ed ha, inoltre, la capacità di rispondere alle richieste sulla base dei
protocolli stabiliti dal personale medico. Esso deve adattarsi ad uno
specifico utente e, a tale scopo, impiega un modello utente e un modello
di sistema. Inoltre, poiché deve avere la capacità di comprendere input
imprecisi, ambigui o parziali, si è scelto di utilizzare anche input di tipo
passivo (ad esempio la storia di interazione passata tra utente e sistema).
Le richieste dell’utente vengono inserite in un sistema di regole di
produzione. Tali regole, se soddisfatte, producono risposte e/o azioni che
verranno portate a termine dal softbot. Ad esempio, l’assistente è capace
di visualizzare le informazioni nel pannello inferiore e guidare l’utente in
51
una procedura semplice ed intuitiva affinché possa raggiungere i propri
obiettivi.
Gli input, provenienti da più canali di comunicazione, vengono registrati,
elaborati e fusi assieme. La fusione avviene ad un livello semantico,
ovvero dopo che ogni segnale è stato analizzato separatamente. A
questo punto, il sistema, dopo aver deciso l’azione più opportuna da
eseguire, adatta l’output sulla base del profilo utente coinvolto.
Il testo e il dialogo vengono processati da un motore inferenziale e da uno
schedulatore che stabilisce quali regole di produzione mandare in
esecuzione. Nello sviluppo del sistema di gestione del dialogo si è scelto
un modello a stati finiti. In questo caso il controllo dell’interazione è
affidato al sistema e l’output vocale fornito dall’interfaccia è costituito da
frasi pre-registrate e predeterminate.
Le azioni svolte, unitamente ai dati di anamnesi e alla storia di interazione
passata, sono utilizzati per dedurre nuove informazioni. Queste nuove
informazioni andranno poi ad aggiornare il modello utente memorizzato
all’interno del sistema. Per raggiungere tale risultato si utilizza una rete
bayesiana, sviluppata attraverso la piattaforma WEKA, ambiente di
sviluppo interamente scritto in Java che permette di applicare dei metodi
di apprendimento di data mining (estrazione di informazione utile in modo
automatico o semiautomatico) su di un set di dati, analizzandone il
risultato.
Le regole di produzione hanno la possibilità di generare testo, voce ed
azioni. L’output, proveniente da queste regole, è in grado di lanciare
scripts C# allo scopo di memorizzare lo stato dell’utente. Tale stato può
essere poi recuperato attraverso un codice javascript per la definizione o
la modifica dei contenuti del pannello inferiore.
3.3.2 L’INTERFACCIA GRAFICA
Il pannello inferiore è costituito da una interfaccia grafica composta da
collegamenti e pulsanti. Esso è organizzato in cinque sezioni distinte, che
sono: Informazioni, Fascicolo Clinico, Percorsi Sanitari, Ricerca su Rete e
Forum. Ogni sezione mette a disposizione vari servizi con l’obiettivo di
migliorare il rapporto che si instaura tra il cittadino e i medici dell’ASUR.
52
Il contenuto e la struttura delle sezioni variano a seconda dell’utente che
ha effettuato l’accesso. In particolare sono state sviluppate due differenti
interfacce grafiche: una per i cittadini/assistiti e l’altra per il personale
medico e paramedico.
Si riporta ora una breve descrizione delle parti che compongono
l’interfaccia.
3.3.2.1 INFORMAZIONI
La grande quantità di informazione, accessibile attraverso un computer,
potrebbe sovraccaricare cognitivamente l’utente. A questo punto diventa
di fondamentale importanza la presenza di un meccanismo atto a filtrare e
selezionare i dati richiesti.
Questa sezione contiene le informazioni selezionate dal medico generico
e/o dagli specialisti che hanno in cura il paziente, in relazione alla propria
area di influenza, e ha il compito di organizzare in modo automatico tutti
le notizie provenienti dal mondo sanitario.
La selezione e il filtraggio si realizza attraverso l’utilizzo di un modello
utente, strutturato per mezzo di una rete associativa di parole. Tale rete
viene aggiornata attraverso tutte quelle risorse che sono considerate
interessanti dall’assistito.
3.3.2.2 FASCICOLO CLINICO
La sezione contiene una rappresentazione dei dati clinici dei pazienti.
Deve essere aggiornata dal medico di base o da operatori di front office
autorizzati. I nuovi dati possono essere inviati da remoto tramite reti sicure
(SSL) ed i dati personali del cittadino devono rispettare precisi vincoli di
privacy secondo la normativa vigente.
I pazienti devono poter visualizzare i dati clinici presenti e ottenere una
stampa in una versione più o meno semplificata.
Nel caso in cui vi sono richieste troppo generiche da parte del cittadino,
l’interfaccia utente deve guidarlo nell’esplorazione della propria cartella
clinica ed aiutarlo nel selezionare le parti richieste. Dunque, se l’utente
non ha le idee sufficientemente chiare sul tipo di referto richiesto e sui dati
da recuperare, l’assistente personale si attiva autonomamente. Per
53
garantire la completa personalizzazione del proprio fascicolo clinico
possono essere supportate viste personalizzate. In questo modo l’utente
riesce a creare un ambiente di lavoro più familiare, nel quale si trova a
proprio agio. Questo meccanismo ha lo scopo principale di aumentare la
soddisfazione dell’utente, producendo un alleggerimento nel carico di
lavoro sia attraverso la riduzione dell’affaticamento che attraverso la
gradevolezza d’interazione.
Il sistema, inoltre, potrebbe visualizzare quei valori irregolari che sono
stati rilevati nei dati del paziente, fornire informazioni riguardanti i campi
presenti all’interno della cartella e presentare all’utente delle domande
allo scopo di comprendere il suo stato di salute.
3.3.2.3 PERCORSI SANITARI
La sezione permette di visualizzare tutte le azioni e procedure che l’utente
deve seguire al fine di prenotare un esame e/o ottenere un certificato
medico.
Il sistema deve avere la capacità di memorizzare lo stato corrente dei
processi avviati dall’assistito. In tal maniera gli utenti visualizzano quali
processi sono stati portati a termine e quali quelli ancora in sospeso. Ad
esempio, una persona anziana potrebbe necessitare di un qualche tipo di
assistenza nel momento in cui desidera ricevere una visita domiciliare. A
questo punto il sistema potrebbe informarla che per prima cosa è
necessaria una autorizzazione del medico curante, che occorre poi
contattare il CUP (il Centro Unificato di Prenotazione) e quindi prendere
un appuntamento con uno specifico medico.
Alcune azioni possono essere effettuate in modo autonomo
dall’assistente virtuale, altre invece devono essere eseguite
esclusivamente dalle persone interessate. Dunque, il sistema potrebbe
ricordare al paziente che la prenotazione della visita può essere effettuata
solo presso il CUP e, al contempo, fornire informazioni utili riguardanti
l’ufficio di prenotazione. Sarà poi compito esclusivo del paziente
prenotare la suddetta visita presso la struttura preposta.
I diversi processi di assistenza si presentano come veri e propri percorsi
di lavoro che coinvolgono gli utenti e i diversi praticanti medici. Il sistema
54
di gestione deve organizzare le attività dei diversi attori nel modo più
efficace ed efficiente possibile.
3.3.2.4 RICERCA SU RETE
Questo servizio permette al cittadino e al personale medico di effettuare
ricerche personalizzate. Tali ricerche si basano su un profilo dell’utente
che viene aggiornato elaborando il contenuto testuale dei documenti da
questi ritenuti correlati con le proprie attività. I risultati ottenuti vanno
strutturati in base alla corrispondenza col profilo utente memorizzato.
L’obiettivo principale è quello di evitare un possibile sovraccarico
cognitivo dell’utente, perciò si cerca di presentare i risultati in modo
ordinato, da quelli più significativi a quelli più lontani dai suoi interessi.
Inoltre il sistema ha la capacità di mettere in contatto gli utenti tra loro,
selezionando una lista di profili simili. Tutto ciò ha il duplice scopo di
favorire la collaborazione tra i dipendenti dell’azienda sanitaria e di
soddisfare le richieste di informazioni dei cittadini mettendoli in contatto
con il personale medico autorizzato.
3.3.2.5 FORUM
Questa sezione garantisce l’annotazione automatica dei messaggi. Il
servizio gestisce in modo semi-automatico le richieste inviate dai cittadini.
I nuovi messaggi vengono analizzati automaticamente dal sistema.
Successivamente il sistema ottiene tutte le risposte, precedentemente
fornite dai medici, che possono soddisfare tali richieste.
Grazie a questo meccanismo i cittadini possono ritrovare immediatamente
una risposta alla loro richiesta, senza dover attendere la replica del
medico specialista.
3.4 SVILUPPO FUTURO
L’aspettativa principale è quella di creare soluzioni innovative che portino
55
a recuperare le informazioni in modo semplice ed intuitivo e fornire
l’assistenza necessaria ai cittadini. Il progetto dell’assistente personale
deve soddisfare pienamente le esigenze dell’utente fornendo servizi di
informazione adattativi. Nel futuro, per semplificare l’interazione con la
IUI, sarà possibile adottare tutti quei meccanismi di comunicazione propri
delle interfacce multimodali.
Poiché si tratta di un progetto a medio-lungo termine sarà soggetto a
modifiche. Dunque, dovranno essere aggiunti servizi di transazione, quali
la prenotazione di una visita medica e il pagamento dei ticket. Si dovrà
anche sviluppare il progetto in più lingue per soddisfare le esigenze di una
società sempre più multietnica. Sarà inoltre possibile accedere
all’interfaccia e quindi a tutte le sue funzionalità tramite telefoni cellulari
UMTS, palmari ed altri dispositivi portatili.
Infine all’interno del softbot saranno integrati ulteriori modelli, basati
principalmente sulle emozioni, con l’obiettivo di ottenere una interazione
simile a quella umana.
56
CAPITOLO 4: VALUTAZIONE
DELL'ACCESSIBILITA' DEL PROGETTO
“ARIANNA” (ASSISTENTE PERSONALE)
4.1 Valutare l'accessibilità di un sito web
4.1.1 Introduzione
Esistono una varietà di strumenti e di approcci per valutare l'accessibilità
di un sito web. Nessun singolo strumento di valutazione fornisce ancora
informazioni complete o è in grado di cogliere tutti i problemi relativi
all'accessibilità di un sito; perciò la valutazione richiede più approcci
combinati. Gli obiettivi della valutazione di siti web sono differenti e
richiedono, per essere raggiunti, approcci differenti:
●
●
●
●
●
La revisione preliminare può:
• identificare barriere di tipo generale su un sito web.
La valutazione della conformità può:
• cogliere i problemi principali durante la fase di sviluppo di un
nuovo sito;
determinare il livello di conformità alle WCAG 1.0 per un sito web
esistente;
dimostrare che un sito web soddisfa un dato livello di conformità alle
WCAG 1.0.
La valutazione della conformità, unita al riesame delle procedure per
il monitoraggio costante, può:
• aiutare a garantire che un sito conservi nel tempo un dato
livello di conformità.
57
4.1.2 Revisione preliminare
La revisione preliminare può aiutare ad identificare rapidamente la portata
dei problemi di un sito web. Tuttavia la revisione preliminare non è in
grado di cogliere tutti i problemi di un sito e non dovrebbe essere usata
per determinare il livello di conformità. Una revisione preliminare non
comprende le impressioni di una molteplicità di utenti con disabilità né
interessa o testa ciascuna caratteristica di un sito.
Una revisione preliminare combina il controllo manuale di alcune pagine
campione di un sito web, con l'uso di vari strumenti semi-automatici per il
controllo dell'accessibilità. I revisori non hanno bisogno di conoscere i
linguaggi di marcatura per il Web, ma dovrebbero essere capaci di
scaricare dei programmi dalla Rete e di familiarizzarsi con l'uso di alcuni
strumenti on line, nonché di modificare certe impostazioni nei loro
browser.
Per condurre una revisione preliminare, completate tutti i cinque passi qui
di seguito.
1. Selezionate un campione rappresentativo di differenti tipi di pagine
dal sito web che deve essere esaminato; deve includere tutte le
pagine alle quali è più probabile che la gente acceda giungendo al
sito (la pagina di benvenuto, ecc.) NOTA: nei siti web con contenuti
generati dinamicamente tramite database, producete dei campioni
largamente rappresentativi, salvateli come pagine statiche e
verificate queste ultime.
2. Usate un browser con interfaccia utente grafica (GUI), come ad
esempio Internet Explorer, Netscape Navigator o Opera, ed
esaminate il campione di pagine, modificando le impostazioni del
browser nel modo seguente (NOTA: per gli utenti con disabilità,
alcuni dei passi successivi possono richiedere l'aiuto di un'altra
persona che non abbia le medesime disabilità.) (NOTA: Alcuni di
questi controlli manuali possono essere eseguiti cambiando le
impostazioni o le preferenze del browser, alcuni possono richiedere
cambiamenti alle impostazioni del sistema operativo, altri ancora
possono richiedere programmi aggiuntivi.)
1. Disabilitate le immagini e verificate se sono disponibili testi
alternativi appropriati.
58
2. Disattivate l'audio ed assicuratevi che i contenuti audio siano
ancora disponibili attraverso degli equivalenti testuali.
3. Usate i controlli del browser per modificare la grandezza dei
caratteri: verificate che la grandezza dei caratteri sullo
schermo vari in modo corrispondente; e che la pagina sia
ancora usabile una volta ingranditi i caratteri.
4. provate con differenti risoluzioni dello schermo e/o
ridimensionando la finestra dell'applicazione a meno della sua
grandezza massima, per verificare che non è richiesto lo
scorrimento orizzontale (attenzione: fate la prova con browser
differenti o esaminate il codice alla ricerca di dimensionamenti
assoluti, per assicurarvi che sia un problema del contenuto e
non un problema del browser)
5. modificate il colore dello schermo a scala di grigi (oppure
stampate la pagina in scala di grigi o in bianco e nero) ed
osservate se il contrasto dei colori è adeguato.
6. senza usare il mouse, tabulate attraverso i collegamenti ed i
controlli dei moduli presenti sulla pagina, assicurandovi che
potete accedere a tutti i collegamenti e a tutti i controlli dei
moduli, e che i collegamenti indichino chiaramente a cosa
conducono.
3. Usate un browser vocale come per esempio Home Page Reader, o
un browser testuale come Lynx ed esaminate il sito web cercando di
rispondere a queste domande (NOTA: gli utenti esperti nell'uso di
lettori di schermo possono usare un lettore di schermo al posto di un
browser vocale o testuale, ma se ciechi, possono aver bisogno di un
compagno vedente per paragonare le informazioni con quelle
disponibili visualmente; se vedenti, ascoltino il contenuto con gli
occhi chiusi, quindi aprano gli occhi e confermino se l'informazione è
equivalente.)
1. sono disponibili attraverso il browser vocale o testuale
informazioni equivalenti a quelle disponibili attraverso un
browser grafico?
2. le informazioni sono presentate in un ordine significativo se
lette serialmente?
4. Usate due strumenti per la valutazione dell'accessibilità generale ed
59
annotate ogni problema indicato da tali strumenti.
5. Ricapitolate i risultati
1. ricapitolate i tipi di problemi incontrati nonché le buone
pratiche che dovrebbero essere continuate o ampliate
all'interno del sito
2. indicate il metodo con cui i problemi sono stati identificati e
dichiarate chiaramente che non si trattava di una valutazione
completa della conformità
3. raccomandate passi ulteriori, tra cui una valutazione completa
della conformtià che includa la validazione del codice di
marcatura ed altre verifiche nonché modi per risolvere i
problemi identificati.
4.1.3 Valutazione della conformità alle WCAG 1.0
Una valutazione completa combina verifiche delle caratteristiche di
accessibilità realizzate in modo semi-automatico, manuale e tramite
utenti. Le valutazioni complete richiedono familiarità con i linguaggi di
marcatura per il Web; lo scaricamento iniziale e/o l'addestramento con
una molteplicità di strumenti di valutazione e di approcci; la
configurazione delle impostazioni del browser; il coordinamento con
revisori con diverse disabilità. La valutazione con utenti è importante ed
aiuta ad identificare eventuali problemi nel modo in cui si stanno
applicando le soluzioni tecniche.
Una valutazione completa correttamente condotta può identificare i
problemi potenzialmente maggiori durante la fase di sviluppo di un nuovo
sito; determinare quale livello di accessibilità un sito web soddisfa; e/o
garantire che un sito web raggiunga un richiesto livello di accessibilità.
Una valutazione completa include tutti i passi sotto riportati ad eccezione
di quelli che sono esplicitamente identificati come alternativi o facoltativi
(NOTA: mentre identificare il campione di pagine è un primo passo
chiave, e ricapitolare ed annotare i risultati della valutazione è la logica
conclusione, l'ordine dei passi intermedi non è cruciale).
1. Identificate e rendete pubblica l'estensione del sito che deve essere
valutato ed il livello di conformità a cui punta la valutazione (NOTA:
60
la divulgazione dovrebbe essere interna all'organizzazione durante
la valutazione; se la conformità è dichiarata pubblicamente, rendete
noto l'obiettivo anche all'esterno (p.es. sul sito web)):
• Identificate e rendete pubblico il livello di conformità alle
WCAG 1.0 che è il vostro obiettivo.
• identificate e rendete pubblica una selezione di pagine per la
verifica manuale e con utenti, che includa come minimo una di
ciascun differente tipo di pagina all'interno del sito nonché
tutte le pagine alle quali è più probabile che acceda la gente
che visita il vostro sito. NOTA: esistono considerazioni speciali
per i siti web con contenuti generati dinamicamente da
database
• identificate e rendete pubblico l'intero sito web comprendente
tutte le pagine raggiungibili da un dato URL di base, per la
valutazione automatica e semi-automatica; NOTA: se la
verifica dell'intero sito non è fattibile (p.es. a causa della sua
inusuale grandezza o per la natura dinamica), identificate una
selezione ampliata di pagine, che deve essere chiaramente
spiegata e resa pubblica sul sito web. Suggerimenti per
l'inclusione in questa selezione ampliata di pagine: pagine
appartenenti a differenti sezioni del sito; pagine
rappresentative di stili grafici differenti; pagine rappresentative
di differenti strumenti di sviluppo e processi, comprese quelle
generate da database; pagine prodotte obbedendo a differenti
linee guida; pagine di "contatti"; pagine critiche per la vostra
attività, ecc. Se una qualsiasi area di un sito è esclusa dalla
valutazione, assicuratevi di rendere pubblica
quest'informazione.
2. Valutazione semi-automatica ed automatica
• Validate il codice di marcatura, comprendendo sintassi e fogli
di stile, usando tutti i validatori applicabili, sulla selezione di
pagine. Eseguite almeno uno degli strumenti di validazione
sull'intero sito web
• HTML Validation service
• HTML Tidy
• CSS Validation service
61
MathML Validator
• Usate almeno due strumenti per la valutazione
dell'accessibilità sulla selezione di pagine ed eseguite almeno
uno degli strumenti sull'intero sito web. Annotate qualsiasi
problema indicato dagli strumenti. (un elenco degli strumenti è
disponbile a http://www.w3.org/WAI/ER/tools/#General)
3. Valutazione manuale
• Esaminate la selezione di pagine utilizzando i punti di controllo
rilevanti dalla scheda dei punti di controllo per le Web Content
Accessibility Guidelines 1.0. NOTA 'Rilevante' può significare: i
punti di controllo che non possono essere valutati da strumenti
automatici o semiautomatici; i punti di controllo che si
applicano effettivamente al sito (p.es. se il sito non contiene
contenuti audio, saltate quelli [relativi ai contenuti audio]); e,
come minimo, quei punti di controllo che si applicano al livello
di conformità che state valutando.
• Esaminate la selezione di pagine con un browser dotato di
interfaccia utente grafica (GUI): selezionate almeno tre
differenti configurazioni scelte tra le seguenti variabili: differenti
browser con interfaccia utente grafica (Internet Explorer,
Netscape, Opera), in differenti versioni (le più recenti, le più
vecchie), installate su differenti piattaforme (Windows, Linux,
Mac) e facendo i seguenti aggiustamenti (NOTA: per gli
esaminatori che hanno disabilità, alcuni dei passi successivi
possono richiedere di essere fatti con un'altra persona che
non abbia la medesima disabilità.):
• Disabilitate le immagini e verificate se sono disponibili
testi alternativi appropriati.
• Disattivate l'audio ed assicuratevi che i contenuti audio
siano ancora disponibili attraverso degli equivalenti
testuali.
• Usate i controlli del browser per modificare la grandezza
dei caratteri: verificate che la grandezza dei caratteri
sullo schermo vari in modo corrispondente; e che la
pagina sia ancora usabile una volta ingranditi i caratteri.
• provate con differenti risoluzioni dello schermo e/o
•
62
•
ridimensionando la finestra dell'applicazione a meno
della sua grandezza massima, per verificare che non è
richiesto lo scorrimento orizzontale (attenzione: fate la
prova con browser differenti o esaminate il codice alla
ricerca di dimensionamenti assoluti, per assicurarvi che
sia un problema del contenuto e non un problema del
browser)
• modificate il colore dello schermo a scala di grigi (oppure
stampate la pagina in scala di grigi o in bianco e nero)
ed osservate se il contrasto dei colori è adeguato.
• senza usare il mouse, tabulate attraverso i collegamenti
ed i controlli dei moduli presenti sulla pagina,
assicurandovi che potete accedere a tutti i collegamenti
e a tutti i controlli dei moduli, e che i collegamenti
indichino chiaramente a cosa conducono.
• esaminate infine la pagina con script, fogli di stile ed
applet non caricati
Esaminate la selezione di pagine con un browser testuale
(come per esempio Lynx) ED un browser vocale (come per
esempio Home Page Reader) e rispondete alle seguenti
domande:
• Con il browser testuale
• Informazioni e funzioni equivalenti (p.es.
collegamenti ed eventi gestiti da script) sono
disponibili attraverso il browser testuale così come
sono disponibili attraverso il browser grafico?
• Le informazioni sono presentate in un ordine
significativo quando lette serialmente?
• Con il browser vocale
(NOTA: Per impostazioni per le quali esiste una scelta
limitata di tecnologie assistive, eseguite pure una
valutazione manuale del sito web con quelle tecnologie
assistive; per esempio, JAWS è l'unico lettore di
schermo tradotto in danese, e perciò un valutatore
qualificato dovrebbe esaminare il sito web usando
JAWS.)
63
informazioni equivalenti sono disponibili attraverso
il browser vocale così come sono disponibili
attraverso il browser grafico?
• le informazioni sono presentate in un ordine
significativo quando lette ad alta voce in modo
seriale?
• Rileggete attentamente le pagine: i testi sono chiari e semplici
in una misura appropriata agli scopi del sito web? (Per i siti in
inglese, valutate l'utilizzo del test Clear and Appropriate
Language and Design (CLAD).) [NOTA: è appropriato
rivolgere una tale domanda anche alle persone che
partecipano a test di usabilità delle caratteristiche di
accessibilità].
4. Test di usabilità delle caratteristiche di accessibilità
• Fate in modo che persone con differenti disabilità, differenti
livelli di capacità tecnica e differenti livelli di familiarità con il
sito, usando una molteplicità di tecnologie assistive e di
strategie adattative, esaminino una selezione di pagine ed
esplorino liberamente l'intero sito web [NOTA: talvolta ciò
viene fatto nel contesto di un laboratorio sperimentale, ma è
anche importante che le persone possano valutare il sito nel
proprio tipico ambiente Web. Sono importanti differenti livelli di
esperienza tecnica e di familiarità con il sito da parte degli
utenti, osservate dunque che questi cambino nel tempo,
mentre le persone partecipano all'esame del sito.]
• Chiedete ai soggetti di provare a trovare risposte alle più
comuni domande per le quali la gente visita il vostro sito Web.
Notate le aree in cui risulta difficile o impossibile usare il sito
web.
5. Ricapitolate e date seguito [ai riscontri ottenuti]
• Ricapitolate tutti i problemi e le migliori procedure [=best
practices] identificati per ciascun tipo di pagina, un URL
rappresentativo ed il metodo attraverso cui sono stati
identificati
• Raccomandate passi ulteriori, potenzialmente includenti:
• l'eliminazione delle barriere per l'accessibilità identificate
•
64
•
•
attraverso il processo di valutazione della conformità.
NOTA: per una valutazione che usi una "selezione
allargata di pagine" invece dell'intero sito web," applicate
ad altre pagine ciò che avete imparato.
applicare più ampiamente le migliori procedure all'interno
del sito
manutenzione costante e monitoraggio del sito.
4.1.4 Considerazioni per specifici contesti
Valutazione durante il processo di sviluppo
La valutazione durante il processo di sviluppo è essenziale. Può essere
talvolta difficoltosa, perché sia gli sviluppatori interni ad un'azienda sia
quelli che lavorano in subappalto talvolta preferiscono consolidare il
progetto grafico e dimostrare i propri progressi prima di ottenere delle
risposte. Tuttavia i problemi di accessibilità identificati precocemente sono
i più facili da correggere e da evitare. Un'efficace valutazione durante il
periodo di progettazione può comprendere:
•
•
•
•
definire chiari requisiti per il livello di conformità all'accessibilità che
si desidera raggiungere
la partecipazione ad incontri iniziali di pianificazione per il sito
concordare un calendario di revisioni durante la fase di sviluppo
fornire informazioni sugli approcci alla valutazione, in modo che gli
sviluppatori siano almeno messi in grado di effettuare la revisione
preliminare da soli
Monitoraggio costante
Per rendere massima la probabilità che un sito web mantenga nel tempo
un dato livello di conformità, dovrebbero essere prese le seguenti misure:
•
•
•
•
una esplicita dichiarazione del livello di conformità previsto e
l'ampiezza del sito web a cui essa si applica
identificare chiaramente le persone responsabili del monitoraggio
del sito e le procedure di adeguamento che essi possono usare per
rendere rapidamente conformi le pagine non conformi
chiare previsioni sulla frequenza, il metodo e l'ampiezza delle
valutazioni
procedure per validare e valutare tutte le pagine modificate ed i
nuovi tipi di pagina prima che siano aggiunti al sito
65
•
•
•
software per facilitare la valutazione
inserimento nel sito web di indirizzi per ricevere segnalazioni
sull'accessibilità del sito
verifiche automatiche o semi-automatiche per identificare i problemi
riscontrati durante la valutazione completa
NOTA: Una completa valutazione della conformità non è richiesta
necessariamente per ciascuno dei passi in un processo di revisione
continuo. Passi come ripetute verifiche con utenti possono essere
necessari solo dopo le modifiche maggiori ai modelli di pagina o ai
contenuti.
Valutazione di siti non più aggiornati
Occasionalmente si trova che siti web che sono "congelati" (lasciti: non
più attivamente mantenuti) hanno dei sostanziali problemi di accessibilità.
Può essere difficile determinare come risolverli. Può essere d'aiuto:
•
•
•
•
•
identificare chi ne è l'attuale proprietario;
determinare se questi abbia un obbligo o un interesse nel rendere
accessibile il sito;
dopo la valutazione del sito, tracciare uno schema per il proprietario
con le modifiche che sarebbero necessarie per "riequipaggiare" il
sito per l'accessibilità;
identificare e proporre risorse ed una scaletta dei tempi per adattare
il sito;
rendere pubblici i problemi di accessibilità del sito.
Valutazione di pagine web generate dinamicamente
Le pagine generate dinamicamente sono assemblate di solito da uno o
più modelli di pagina che forniscono un'impaginazione e strumenti di
navigazione comuni, mentre i contenuti sono forniti automaticamente da
un database o da un altro sistema di gestione dei contenuti. Per ottenere
una piena conformità, deve essere valutata l'accessibilità sia dei modelli
di pagina sia dei contenuti generati. Non è sufficiente valutare soltanto i
modelli: anche i contenuti possono contenere codice di marcatura o può
essere necessario che contengano codice di marcatura, affinché siano
accessibili. Le cose da considerare:
1. Modelli di pagina
• valutate tutti i modelli
2. se i modelli sono generati da programmi autoriali, valutate la
capacità dello strumento autoriale di includere caratteristiche di
accessibilità (si veda Selezionare strumenti autoriali), p.es.:
• l'ordine di tabulazione generato dal modello consente di
66
arrivare efficacemente ai contenuti testuali generati?
3. Contenuti
• se non possono essere valutati tutti i contenuti dinamici,
generate un campione largamente rappresentativo, salvate i
contenuti generati ed effettuate verifiche su di essi;
4. valutate la capacità del sistema di gestione dei contenuti di
conservare e generare informazioni per l'accessibilità (si veda
Selezionare strumenti autoriali);
• le immagini sono fornite con testi alt e, se necessario,
con longdesc?
5. le tabelle generate hanno aiuti per l'accessibilità (es. didascalie, id
sulle celle d'intestazione <th>, ecc.)?
6. se vengono generati dei video, sono sottotitolati?
7. se viene generato del contenuto audio narrato, è disponibile un
equivalente testuale?
8. Modelli e contenuti combinati
• per pagine che sono generate come risultato di
un'interrogazione ad un database, il sorgente prodotto una
volta che la pagina è stata generata dovrebbe essere catturato
e sottoposto allo strumento di valutazione -- [può richiedere
l'intervento di un operatore];
4.2 Applicazione dei criteri di accessibilità al progetto
“Arianna”
4.2.1 premessa
Lo studio e la valutazione dell'accessibilità di un sito web o un portale è
un processo piuttosto lungo e laborioso in cui debbono essere impiegate
notevoli risorse affinché tutti i requisiti vengano pienamente soddisfatti.
Mentre allo stato embrionale di progettazione di un sito web, il
procedimento è meno complesso poiché è sempre possibile un rapido
cambio di strumenti che risultano essere non accessibili in favore di altri
che invece lo sono, valutare l'accessibilità di un applicazione web il cui un
prototipo è già stato sviluppato, il lavoro risulta essere considerevolmente
più complesso. Ciò è dovuto al fatto di dover lavorare non in condizioni
ottimali, cioè dover apportare modifiche al codice degli applicativi affinché
67
soddisfino le specifiche delle linee guida, mantenendo inalterata la
struttura e il corretto funzionamento dell'interfaccia.
In queste condizioni è presente il rischio di scendere a compromessi tra
funzionalità del sistema e accessibilità a discapito di quest'ultima; per
esempio potrebbero esserci delle parti di codice dell'interfaccia che non
sono accessibili ma che non sono nemmeno modificabili, causa
l'instabilità del sistema. Una possibile soluzione è cambiare la tecnologia
utilizzata, ma è improbabile che ciò sia possibile, o almeno non è
possibile cambiare in tempi brevi.
La valutazione dell'accessibilità dell'interfaccia utente personalizzata
“Arianna” purtroppo si colloca in questa contesto; proprio per questo il
periodo in cui ho svolto il tirocinio, non è stato sufficienti per apportare
tutte le modifiche necessarie affinché un portale complesso come
l'Assistente Personale sia reso completamente accessibile, ma è stato
possibile attuare un lavoro preliminare evidenziando pregi e difetti del
portale
In questa sezione, il cuore della tesi, seguendo le linee guida e i principi
delle WCAG 1.0, verranno illustrati tutti questi cambiamenti, integrati con
un breve commenti degli screenshot e frammenti di codice per illustrare
meglio le modifiche apportate.
4.2.2 Strumenti utilizzati
Browsers
•
Microsoft Internet Explorer 6
Disponibile solo su sistema operativo Windows, è il browser più utilizzato,
raggiungendo una quota di oltre il 45% del mercato dei browser, È
dunque essenziale conoscere bene le caratteristiche, e soprattutto i
difetti, di Internet Explorer 6 se si vogliono sviluppare siti accessibili al più
largo pubblico.
Dal punto di vista dell’accessibilità, tra le caratteristiche di questo browser
68
di cui occorre tener conto c’è la non ridimensionabilità dei caratteri definiti
in px nei CSS e la mancanza di adeguato supporto per i contenuti
generati. Il supporto di Internet Explorer 6 agli standard W3C è per molti
versi carente e ciò provoca non pochi problemi agli sviluppatori, almeno a
quelli impegnati nel tentativo di ottenere risultati analoghi su browser
differenti scrivendo documenti conformi agli standard promossi dal W3C.
•
Microsoft Internet Explorer 7
Disponibile solo per Windows XP e per il nuovo sistema operativo
Windows Vista, Internet Explorer 7 (www.microsoft.com) è accreditato da
Net Applications di una quota di mercato del 32 % circa e in costante
crescita, a danno della versione 6.
Il nuovo browser Microsoft non risolve purtroppo i numerosi problemi di
supporto agli standard presenti nella versione 6.
Le carenze nel supporto ai linguaggi standard per il Web, unite al
perdurante uso di istruzioni e marcatori proprietari, fanno di Internet
Explorer 7, anche se in misura minore rispetto ai suoi predecessori, un
“cliente” relativamente difficile per gli sviluppatori che lavorano con il
rispetto degli standard in mente. Tra le innovazioni sicuramente positive
del nuovo browser di casa Microsoft, va citata la funzione di
ridimensionamento (page zoom), che rende possibile ingrandire tutti i
contenuti di pagina, immagini comprese, fino al 400%. Si tratta di un
ottimo ausilio per chi vede poco, anche se il modo in cui la funzione è
implementata crea qualche problema: l’ingrandimento, infatti, è
proporzionale in orizzontale e in verticale, il che porta alla rapida
scomparsa di parte dei contenuti oltre i bordi laterali della finestra del
browser, richiedendo l’uso della barra di scorrimento orizzontale per
potervi accedere. Meglio sarebbe stato, forse, vincolare la dimensione
orizzontale della pagina ingrandita a quella della finestra del browser,
facendo scorrere verso il basso piuttosto che verso destra e sinistra i
contenuti, anche a costo di scompaginare completamente la struttura
grafica dei documenti.
Un’altra innovazione introdotta con Internet Explorer 7 è la navigazione a
schede (tabbed browsing), per mezzo della quale l’utente può navigare
69
tra più documenti aperti all’interno della stessa finestra del browser. Ma in
ciò Microsoft non ha fatto che seguire il cammino intrapreso già da tempo
dai browser concorrenti, cammino che ha seguito anche per quanto
riguarda la funzione di blocco delle finestre pop-up, finalmente disponibile
in modo nativo nella versione 7.
•
Firefox
Nato alla fine del 2002 con il nome in codice di Phoenix da una costola
del grande progetto Open Source Mozilla, Firebird, divenuto in seguito
Firefox (mozilla-europe.org/it/), è l’unico browser che, finita l’epoca di
Netscape Navigator, ha oggi la concreta possibilità di mettere in
discussione l’egemonia mondiale di Internet Explorer.
Firefox può contare su una quota di mercato di oquasi il 15% con
tendenza a crescere. La media globale d’uso di Firefox subisce però
sensibili variazioni a seconda della nazione. Per esempio, la percentuale
di utenti che usano Firefox in Germania e in Australia è di oltre il 26%,
ben superiore alla media mondiale (in Italia è del 18%).
Tra gli utenti di Firefox vi sono soprattutto coloro che hanno qualche
conoscenza di informatica, che non hanno difficoltà a installare software
non presente nativamente nel proprio sistema operativo e che sono in
grado di valutare pregi e difetti dei browser grafici concorrenti.
Le ragioni del successo di Firefox, che il 31 luglio 2006 ha tagliato il
notevole traguardo di 200 milioni di versioni scaricate, sono da ricercare
nelle sue innovative soluzioni di progettazione: navigazione a schede
nativa, blocco delle finestre pop-up, codice libero, ma soprattutto un gran
numero di estensioni e di temi grafici prodotti da terze parti. Dal punto di
vista degli sviluppatori, un pregio importante di Firefox è la sua notevole
aderenza ai linguaggi standard per il Web, che lo rende uno strumento
capace di riprodurre ottimamente i siti di ultima generazione, realizzati con
un uso intensivo dei fogli di stile e di funzioni JavaScript che utilizzano il
DOM.
Firefox è inoltre, a differenza di Internet Explorer, un vero browser multipiattaforma: può essere installato indifferentemente su sistemi operativi
Windows, Macintosh e Linux, con prestazioni che rimangono in tutti i casi
70
stabili e di alta qualità: un bell’esempio di interoperabilità, anche se il
supporto per i fogli di stile CSS 2.1 non è ancora totale, nonostante sia
stato già reso disponibile il supporto ad alcune parti delle specifiche
CSS3. Tra i difetti di Firefox vi è un consumo forse eccessivo delle risorse
di memoria del computer, che, con l’aumentare delle sessioni aperte, può
far degradare sensibilmente le prestazioni.
•
Netscape
Netscape Navigator (http://browser.netscape.com/ ), il browser che a
metà degli anni Novanta legò il suo nome all’esplosione del Web come
fenomeno di massa, arranca oggi in posizioni di retrovia. Del 90% di
quota di mercato che deteneva nel 1996, gli resta – secondo le statistiche
di Net Applications aggiornate a giugno 2007 – appena lo 0,78%, da
suddividersi tra tutte le versioni ancora in uso. La nuova versione, ancora
provvisoria, è disponibile per Windows, Mac OS e Linux. È basata
sull’architettura aperta di Mozilla Firefox, del quale può installare le
estensioni e i temi.
Dal punto di vista dell’accessibilità, la funzione più utile e innovativa di
Netscape 9 è la possibilità di ridimensionare manualmente, trascinandone
i bordi, le finestre TEXTAREA (cioè i campi modulo usati per pubblicare
testi discorsivi, come i commenti inviati ai blog). Unita alla possibilità di
ingrandire i testi tramite appositi comandi, questa funzione consente a chi
vede poco di superare le limitazioni di dimensione imposte ai campi
modulo da sviluppatori poco amici dell’accessibilità.
•
Opera
Giunto alla versione 9.21, Opera (http://www.opera.com/ )ha una quota di
mercato al di sotto dell’1%, con punte di maggior uso (tra il 6 e l’11 per
cento) in alcuni paesi dell’Est, tra i quali Ucraina, Russia, Polonia e
Lituania.
Dal punto di vista dello sviluppatore, Opera è un ottimo prodotto, dotato di
funzionalità molto sofisticate e di un notevole supporto ai linguaggi
standard per il Web. Opera 9 è, uno dei browser che rimane più fedele sia
71
agli standard del W3C che in particolare alle specifiche dei CSS 2.0.
•
Lynx (browser testuale)
Lynx (http://lynx.isc.org/ )è un browser di solo testo utilizzabile su terminali
con interfaccia a linea di comando.
Per navigare con Lynx è necessario evidenziare il link scelto usando i
tasti per muovere il cursore, o avendo tutti i link della pagina numerati,
selezionare il numero del link. Le ultime versioni supportano SSL (Secure
Soket Layer – protocollo di rete per comunicazioni cifrate su internet ) e
molte caratteristiche dell'HTML. Le tabelle perdono la loro struttura in
quanto ogni cella viene visualizzata di seguito all'altra, mentre i frame
vengono identificati da un nome e possono essere visualizzati come
fossero pagine indipendenti.
Grazie alla sua interfaccia facilmente compatibile con il text-to-speech (da
testo a voce), Lynx era popolare tra gli utenti non vedenti, ma la diffusione
di migliori screen reader ne ha ridotto l'impiego in questo ambito.
Validatori di codice
•
HTML validator (http://validator.w3.org/)
È uno strumento messo a disposizione dal consorzio W3C per la
validazione del codice HTML. È possibile validare il codice creato in 3
modi; copiando l'URI, effettuando l'upolad del file html, oppure copiare
tutto il codice in una textarea.
Dispone anche di molte funzionalità avanzate come il tipo di codifica in cui
è stato scritto il codice, la grammatica formale usata, utili per una corretta
validazione.
72
Figura 4.1: Homepage di HTML validator
•
CSS validator (http://jigsaw.w3.org/css-validator/ )
Servizio di Validazione del W3C per CSS, in italiano; si tratta di un
servizio gratuito che consente di controllare la conformità alle
raccomandazione del W3C dei fogli di stile a cascata (CSS), siano essi
all'interno di documenti (X)HTML che in documenti autonomi.
I metodi di validazione sono gli stessi dell'HTML validator (per URI,
upload o copiando direttamente il codice). Le funzionalità aggiuntive
consistono nel stabilire il profilo del css, (la versione: 2.0, 2.1, 3.0...), e il
tipo di media cui è riferito (aural, braille, print)
73
Figura 4.2: Homepage di CSS validator
Validatori automatici di accessiibilità
•
Bobby (http://webxact.watchfire.com/)
Bobby è uno strumento informatico che verifica la rispondenza dei siti ai
requisiti di accessibilità agli utenti disabili, facendo riferimento a quanto
stabilito nelle apposite linee guida pubblicate dal WAI-W3C
Bobby è stato creato dal Center for Applied Special Technology (CAST),
un’organizzazione no profit fondata nel 1984 per espandere le opportunità
per i disabili attraverso l'uso innovativo della tecnologia informatica. Ne
sono state sviluppate due versioni, una friubile accedendo direttamente al
sito di CAST ed una scaricabile ed utilizzabile offline (a pagamento), che
permette la validazione di pagine e siti non in linea.
Il funzionamento di Bobby è abbastanza intuitivo: immettendo l’URL della
pagina da validare nell’apposito campo, dopo qualche secondo si vedrà
comparire l’icona di Bobby approved, se la pagina risulta accessibile o, al
contrario, quella indicante repair needed, ovvero che informa che
mancano i requisiti necessari con i report dei vari error o warning,
fornendo anche un esempio come rimedio. Se il sito risulta subito
accessibile, si potrà esporre il bollino di Bobby, scaricabile dal sito.
74
Figura 4.3: Esempio di pagina dei risultati della validazione di Bobbyr
•
Cyinthia Says (http://www.cynthiasays.com/)
Quest'altro validatore automatico di accessibilità, sebbene la grafica non è
gradevole come Bobby, ha alcune funzionalità particolari. A differenza di
quest'ultimo, espone nel report tutte le linee guida coinvolte nella
validazione (a seconda del livello scelto), fornendo dei link diretti alle fonti
(http://www.w3.org/TR/WAI-WEBCONTENT/ nel caso delle WCAG 1.0).
La pagina da validare va sempre richiamata per URL, ma Cyinthia dà la
possibilità di validare anche secondo le linee guida americane
sull'accessibilità (508 standards). Inoltre è in grado di emulare i
comportamenti dei browser più diffusi (anche se sotto questo aspetto
deve essere aggiornato).
75
Figura 4.4:Pagina dei risultati di Cynthia Says
4.2.3 Esempi di applicazioni dei criteri di accessibilità in
“Arianna”
NOTA: in questo paragrafo sono esposti tutti le linee guida e i punti di
controllo che hanno coinvolto il portale sanitario; di conseguenza le altre
(per esempio tutta la linea guida 7) non verranno menzionate.
Linea guida 1: fornire alternative equivalenti per il contenuto audio e
video
1.1 Fornire un equivalente testuale per ogni elemento non di
testo.
Poiché molti utenti utilizzano strumenti di navigazione che si basano solo
sul contenuto testuale della pagina (gli screen reader o i browser testuali),
è importante fornire forme equivalenti testuali per le immagini, le
animazioni, i frame, gli script, mappe d'immagine, suoni, pulsanti grafici,
ecc.
76
Per quanto riguarda l'interfaccia Arianna un esempio sta nel logo
dell'ASUR, posto in alto a destra nel quale è stato usato l'attributo alt, che
ha il compito di fornire un testo alternativo.
Figura 4.6: esempio di utilizzo dell'attributo alt
Listato 1: utilizzo corretto dell'attributo alt.
<img src="./images/logoASUR.jpg" alt="logo dell'Azienda Sanitaria
Unica Regionale"/>
In alcuni casi però è necessario fornire una descrizione piuttosto ampia
dell'immagine per cui non è sufficiente una breve frase, si deve ricorrere
all'attributo longdesc, che permettere di accedere a una descrizione
estesa dell'immagine specificando l'URI () contenente la descrizione.
Listato 2: uso attirbuto alt e longdesc.
<img src="./images/logoASUR.jpg" alt="logo dell'Azienda Sanitaria
Unica Regionale" longdesc=”logoASUR.html” />
Riguardo all'utilizzo dei frame, anche se sono sconsigliati, sono supportati
dalle raccomandazioni W3C. Per rispettare il punto di controllo 1.1, è
necessario utilizzare l'attributo longddesc per fornire una descrizione
estesa dei contenuti dei frame.
In Asianna si fa uso anche dei frame (4, 3 in fase di registrazione e login):
uno per il logo, uno per il chatterbot, un terzo per il menù laterale e il
quarto in cui vengono visualizzate tutte le informazioni.
77
logo
verbotFrame
mainFrame
pulsantiera
Figura 4.7: suddivisione in frame dell'Assistente Personale
Listato 3: uso dei frame con longdesc.
<frameset rows="230,*" cols="*">
<frameset cols="250,*">
<frame src="logo.html" name="logo"
dell'azienda">
title="logo
<frame src="..." name="verbotFrame” title="..."
longdesc=”infoChatterbot.html”/>
</frameset>
<frameset cols="250,*" rows="*">
<frame src="..." name="pulsantiera"
longdesc=”infoPulsantiera.html”/>
title="..."
<frame src="info.jsp" name="mainFrame" title="frame in cui
vengono caricate tutte le pagine"
longdesc=”infoMainFrame.html”/>
</frameset>
</frameset>
1.3 Fino a quando i programmi utente non potranno leggere
automaticamente ad alta voce il suo equivalente testuale fornire
una descrizione audio delle informazioni essenziali del filmato di
una presentazione multimediale.
78
Grazie alla diffusione delle linee ad alta velocità (DSL, CDN, fibra ottica),
nei siti Web è sempre più frequente l'uso di filmati e prestazioni
multimediali. Affinché questi risultino accessibili, l'utente dovrà disporre di
contenuti alternativi, per coloro che soffrono di disabilità visiva o
tecnologica (browser vecchi che non supportano plug-in di flash). Se non
fosse possibile predisporre una versione audio di supporto, è necessario
fornire una versione testuale.
Nel nostro caso, sono state effettuate delle prove disabilitando i plug-in
dai browser ed effettuando il login dell'applicazione: è stato verificato che,
anche senza il plug-in installato (flash), e quindi disabilitando l'audio,
viene fornita una versione testuale che effettua un quadro generale
dell'utente
Figura 4.8: verifica della funzionalità del chatterbot anche senza il plugin installato
Linea guida 2: non affidarsi unicamente al colore
2.1 Garantire che tutta l'informazione veicolata dal colore sia
disponibile anche in assenza di colori.
Un esempio di mancata applicazione di questo punto di controllo è
79
l'utilizzo dei fogli di stile per cambiare i colori dei collegamenti
rimuovendone la sottolineatura, gli utenti con disabilità visive o che
utilizzano periferiche di navigazione in bianco e nero (cellulari
monocromatici o vecchi modelli di PDA), si troveranno in forte difficoltà.
È invece richiesto che i collegamenti ipertestuali siano identificabili
facilmente, anche utilizzando regole nei fogli di stile (CSS) che evidenzino
gli attributi di sottolineatura o addirittura un carattere di peso maggiore.
Figura 4.9: uso corretto dei colori per identificare i collegamenti
2.2 Garantire che le combinazioni di colori tra il primo piano e lo
sfondo forniscano un sufficiente contrasto se osservati da
qualcuno con deficit percettivi del colore o quando visualizzati su
un monitor in bianco e nero.
Con questo punto di controllo si richiede che il contrasto tra il colore del
testo e il colore dello sfondo sia sufficiente a evitare problemi di lettura
agli utenti.
Non essendo stati definiti criteri per la definizione del contrasto, mi sono
servito di un tool all'indirizzo
http://gmazzocato.altervista.org/colorwheel/wheel.php in cui è possibile
scegliere la combinazione di colori testo/sfondo tenendo conto delle
disabilita cromatiche, in cui, a se conda della combinazione scelta, il
80
programma dice se tale combinazione è accessibile per tutti gli utenti o
solo per una parte.
Figura 4.10: sito del validatore dei colori
Due colori permettono una buona visibilità se la differenza di luminosità e
di colore tra i due è superiore a una determinata serie di valori. Il W3C ha
determinato un algoritmo per calcolare il contrasto8 che potrà essere
utilizzato in questa verifica. L'algoritmo è ancora in fase di sviluppo ed è
possibile che in futuro venga modificato.
La seguente formula è suggerita dal World Wide Web Consortium (W3C)
e serve a calcolare la luminosità di un colore RGB.
((valore Rosso X 299) + (valore Verde X 587) + (valore
Blue X 114)) / 1000
La differenza tra la luminosità dello sfondo e la luminosità del colore
principale deve essere maggiore di 125.
La seguente formula del W3C consente invece di calcolare la differenza
tra due colori.
(massimo (valore Rosso 1, valore Rosso 2) - minimo (valore
Rosso 1, valore Rosso 2)) + (massimo (valore Verde 1,
valore Verde 2) - minimo (valore Verde 1, valore Verde 2))
+ (massimo (valore Blue 1, valore Blue 2) - minimo (valore
Blue 1, valore Blue 2))
81
La differenza tra colore di sfondo e colore principale deve essere
superiore a 500.
Alcuni esempi nel portale in cui questo punto di controllo è stato
soddisfatto li troviamo nel menù laterale o nell'intestazione del frame
principale.
Figura 4.11: esempi di uso corretto di contrasto testo-sfondo
Linea guida 3: usare le marcature ed i fogli di stile in modo
appropriato
3.2 Creare documenti che rispettino le grammatiche formali.
Ogni pagina web deve rispettare la grammatica formale dichiarata
dall'autore; in pratica su ogni pagina deve essere definito il <!DOCTYPE>
del documento (ovvero, il tipo di documento) al fine di garantire che tutti
gli elementi e gli attributi utilizzati nella pagina appartengano alla
grammatica definita nella DTD (Document Type Definition) dichiarata.
Questo consentirà al browser utilizzato per visualizzare la pagina di
valutare la semantica corretta da utilizzare. Alcune delle grammatiche
formali create dal W3C sono:
82
HTML 4.01 Transitional
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
Utilizzando questa grammatica si può mantenere la compatibilità con le
vecchie versioni, consentendo l'utilizzi di elementi e attributi di
presentazioni all'interno del contenuto.
HTML 4.01 Frameset
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
Questa grammatica si usa per un utilizzo corretto dei frame.
HTML 4.01 Strict
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
È la versione rigorosa della grammatica, in cui sono eliminate tutte le
impostazioni di formattazione che possono essere gestite tramite i fogli di
stile. Si può considerare la versione più “accessibile” tra le DTD.
Quindi sarà fondamentale che il documento sia conforme alla grammatica
definita.
Purtroppo nell'Assistente Personale non è stato possibile adottare la
versione “strict”, poiché l'interfaccia fa uso di frame; è stato quindi
necessario adottare la versione 4.01 frameset.
3.3 Usare i fogli di stile per controllare l'impaginazione e la
presentazione.
L'utilizzo dei fogli di stile (CSS) è essenziale per lo sviluppo di siti web
acessibili: grazie a loro non è più necessario l'utilizzo di tag come <font>,
<basefont>, giudicati ormai “deprecated”, in favore di regole o classi
definite nei CSS con cui si ottengono gli stessi effetti in modo più
efficiente.
L'allineamento, i margini e il posizionamento degli elementi nella
presentazione di una pagina vanno gestiti tramite i fogli di stile; lo
sviluppatore deve inoltre garantire la possibilità di lettura della pagina
anche disabilitando i CSS, affinché il contenuto sia fruibile anche da utenti
non-vedenti tramite gli screen reader.
83
link
titolo
snippet
Figura 4.12: uso dei css per definire stili differenti
Listato 4: uso dei css per definire stili differenti
html
<div class="link"><c:out value="${searchStatus.url[i1]}"/></div><br/>
<div class="titolo"><c:out value="${searchStatus.title[i1]}"/></div><br/>
<div class="snippet"><c:out value="${searchStatus.snippet[i1]}"/></div><br/>
CSS
.link{ font-size:16px;
color:#47A;}
.titolo{ font-size:14px;
color:#888;}
.snippet{ font-size:12px;}
3.4 Usare unità di misura relative anziché
assolute nei valori degli attributi del linguaggio di marcatura e
84
per i valori delle proprietà del foglio di stile.
Questo punto di controllo è particolarmente sentito dagli utenti ipovedenti,
in quanto se non viene soddisfatto esistono grosse possibilità che un
utente con tale disabilità visiva non possa accedere ai contenuti delle
pagine. Considerando che in tale categoria di utenti ricadono anche le
persone anziane, non rispettare questo punto di controllo provoca
l'esclusione di una grossa fetta di potenziali utenti del vostro sito. Come
affermato nel punto precedente, tutte le impostazioni relative alla
rappresentazione devono essere definite all'interno dei fogli di stile.
L'utilizzo di un'unità di misura di tipo assoluto, come pica (pc), punti (pt),
inches (in), centimetri (cm), e millimetri (mm) ha come effetto il blocco
delle dimensioni di un elemento a una dimensione fissa: un testo per noi
di dimensioni "normali" potrebbe essere davvero troppo piccolo per un
utente ipovedente o per chi utilizza monitor a risoluzioni elevate. Se
invece le dimensioni del testo vengono definite con unità misura di tipo
relativo, come em (relativa all'altezza del font) o in percentuale (%), i
visitatori del sito potranno facilmente adattare il carattere alle proprie
esigenze. Ciò comporta da parte dello sviluppatore una fase di test delle
pagine simulando tali visualizzazioni e controllando che anche a
risoluzioni medio-basse (800x600) con caratteri molto grandi il proprio sito
sia fruibile senza problemi.
Listato 5: uso dell'unità relativa em per definire la dimensione dei caratteri.
Html
<caption>Nr.<c:out value="${all.numeroAll}"/> allergie registrate nel
DataBase:</caption>
CSS
caption{font-size:1.2em;
margin-bottom:2%;}
3.5 Usare elementi di intestazione per veicolare la struttura del
documento e usarli in modo conforme alle specifiche.
Una pagina Web può essere formata da brevi contenuti, ma può
85
contenere anche testi molto articolati (per esempio, un bando di gara
d'appalto, un comunicato stampa, ecc.) che per poter essere letti devono
essere organizzati: come coi libri, anche sul Web servono titoli, sottotitoli,
capitoli, sottocapitoli e così via.
Gli elementi di titolazione (<h1> - <h6>) devono essere utilizzati in modo
corretto per garantire una corretta visualizzazione e il rispetto della
semantica dei contenuti. Alcuni programmi di navigazione utilizzano gli
elementi di titolazione per ottimizzare la navigazione della pagina da parte
degli utenti. Utilizzando gli elementi <hx> si garantirà maggiore
accessibilità ai contenuti della pagina: tutte le pagine dovrebbero
prevedere l'elemento <h1> e via via, a scalare di importanza, gli elementi
<h2>, <h3> che forniscono all'utente la possibilità di individuare i paragrafi
considerati importanti dall'autore dei contenuti. Da ciò si può chiaramente
comprendere che è importante rispettare l'ordine di importanza dei titoli, in
modo che un elemento <h2> segua un elemento <h1>, mentre un
elemento <h3> deve seguire un elemento di tipo <h2>: è quindi sbagliato
saltare livelli, passando da <h1> a <h3> senza evidenziare l'elemento
<h2>.
È importante, per una semantica corretta, non utilizzare gli header come
mera decorazione per enfatizzare una porzione di testo: in questo caso i
CSS tornano molto utili.
Listato 6: Esempio di corretto uso degli header.
...<div id="centratoTopic">
<h3>FORM NUOVO TOPIC</h3>
<c:if test="${forumBean.warning==1}">
<h4>WARNING : Hai dimenticato di inserire il campo
OGGETTO</h4>
</c:if> ...
3.6 Marcare le liste ed elencare le voci della lista in modo
appropriato.
Gli elementi di lista <dl>, <ul> e <ol> (quest'ultimo disponibile in HTML 3.2
e HTML 4.0) devono essere utilizzati unicamente per la definizione delle
liste e non devono essere utilizzati a scopo di formattazione, come per
rientrare dei contenuti.
86
Per modificare la formattazione delle liste, anche in questo caso ci si
affiderà ai fogli di stile. Un esempio nel portale di Assistente personale si
ha nella pagina di home dopo aver effettuato il login; il quadro generale
dell'assistito è strutturato con una serie di liste (una per ciascuna
categoria) “trasformate” gradevolmente tramite CSS senza però che il
contenuto ne risenta.
Figura 4.14: esempio di gestione di una lista utilizzando i CSS
Listato 7: Definizione di una lista non numerata tramite fogli di stile.
Html
...<ul class="navinfo">
<li>Nessuna notizia selezionata</li>
</ul>...
...<ul class="navinfo">
<li><a href="..."/>Tieni il collo al caldo</a></li>
<li><a href="..."/>Ecco un breve specchietto</a></li>
</ul>...
CSS
.navinfo{border: 1px solid #0b39b2;
padding: 0 1px 1px;
margin-left: 0;
margin-top: 0;
87
font: bold 14px georgia, serif;
background-color:#0b39b2;
width: auto;}
.navinfo li{ list-style: none;
margin: 0;
background-color:#FFFFFF;
text-align: left;
display: block;
padding: 0.25em 0.5em 0.25em 0.75em;
border-left: 3px solid #0b39b2;
background: #FFF;
text-decoration: none; }
.navinfo li{ border-top: 1px solid #0b39b2; }
.navinfo li a {display: block;
padding: 0.25em 0.5em 0.25em 0.75em;
background: #FFF;}
Linea guida 4: rendere chiaro l'uso del linguaggio naturale
4.1 Identificare con chiarezza i cambiamenti nel linguaggio
naturale del testo di un documento e in ogni equivalente testuale.
Se all'interno di una pagina sono presenti testi in diverse lingue, per
definirne il riconoscimento da parte dei programmi utente è necessario
utilizzare l'attributo lang.
Nell'Assistente Personale è stata introdotta la possibilità di utilizzare la
lingua inglese e spagnola.
Figura 4.15: uso di una lingua differente da quella di defeult
88
Listato 8: Esempio di cambio lingua all'interno di un paragrafo.
<div id="lingua">
<em lang="en"><a href="./versione_eng/index_en.html"><img
src="./images/bandiere/bandiera_gb.gif" title="click here to
select english language version" alt="english"/></a></em>
<em lang="es"><a href="./versione_esp/index_es.html"
target="_parent" ><img
src="./images/bandiere/bandiera_sp.gif"
title="chasca aqui para
selecionar el idioma espanol"
alt="espanol"/></a></em>
</div>
4.2 Specificare il significato di ogni abbreviazione o acronimo nel
documento laddove compaia per la prima volta.
Un mancato uso dell'elemento <abbr> per le date in forma abbreviata, in
quanto in alcuni casi, possono risultare ambigue in quanto dipende tutto
dall'ordine di lettura. Spesso, per esempio nelle notizie o nei comunicati
stampa, si utilizza la forma breve gg/mm/aaaa per rappresentare le date.
In questo caso, è necessario utilizzare l'elemento <abbr> con attributo title
contenente la data in formato esteso.
Un esempio di corretto utilizzo dell'elemento <abbr> in Arianna è nella
fase di registrazione, nel momento in cui è richiesto di selezionare il livello
di accesso desiderato
Figura 4.16:visualizzazione di un abbreviazione
89
Listato 9: Utilizzo dell'elemento <abbr>.
<input type="radio" name="lvl" value="mb"/><abbr title="Medico di
medicina generale">MMG</abbr>
Di fatto, un acronimo può essere definito simile a un'abbreviazione che
può essere letta e compresa. Nelle raccomandazioni HTML gli acronimi
sono definiti tramite l'elemento <acronym>, che per soddisfare i requisiti di
questo punto di controllo richiede l'utilizzo dell'attributo title.
Sul sito dell'assistente personale i due acronimi più presenti sono SIA
(Sistema Informativo Aziendale) e ASUR (Azienda Sanitaria Unica
Regionale)
Figura 4.17: uso degli acronimi
Listato 9: Esempio di utilizzio dell'elemento <acronym>
<p>Servizio sviluppato dal <acronym title=”Sistema Informativo
Aziendale”>SIA</acronym> dell'<acronym title=”Azuenda Sanitaria Unica
Regionale”>ASUR</acronym></p>
4.3 Identificare il linguaggio naturale principale di un documento.
La maggior parte delle pagine Web da noi create sono in lingua italiana:
ciò significa che la lingua italiana è la nostra lingua naturale principale, e
90
come tale va dichiarata all'interno del documento. Sappiamo già che gli
eventuali cambi di lingua all'interno del documento sono da segnalare al
browser tramite opportune tag e l'attributo lang; per la definizione della
codifica della lingua in una pagina si utilizza lo stesso attributo, ma va
posto nell'apertura del documento.
Nelle pagine Web, la definizione del linguaggio naturale principale del
documento richiede solamente il posizionamento dell'attributo lang
all'interno dell'elemento <html>
Listato 10: Identificazione della lingua principale in un documento HTML.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="it">,,,
Linea guida 5: creare tabelle che si trasformino in maniera gradevole
5.1 Per le tabelle dati, identificare le intestazioni per righe e
colonne.
Questo punto di controllo informa lo sviluppatore che, nel caso vengano
utilizzate delle tabelle per presentare dei dati, egli deve identificare in
modo chiaro le celle contenenti i dati dalle intestazioni di righe e colonne.
Pertanto, le tabelle dati richiedono l'uso degli elementi <tr>, <td>, <th> e
<caption> e dei relativi attributi.
Nel caso di tabelle con più righe una tecnica affinché un lettore di
schermo legga correttamente il contenuto nelle celle, si utilizza l'attributo
headers che specifica l'elenco delle intestazioni collegate a una cella
contenente dati. Per utilizzare questa funzionalità, ogni cella di
intestazione deve aver valorizzato l'attributo id.
Per evitare la ripetizione del contenuto degli header in ogni riga, si utilizza
l'attributo abbr che ha funzionalità inversa dell'elemento <abbr> visto
precedentemente.
5.2 Per le tabelle dati che hanno due o più livelli logici di
91
intestazioni di righe o colonne, usare marcatori per associare le
celle di dati e le celle di intestazione.
Per le tabelle con strutture più complesse, è possibile utilizzare <thead>,
<tfoot> e <tbody> per raggruppare le righe, <col> e <colgroup> per
raggruppare le colonne e gli attributi axis, scope e headers per descrivere
relazioni più complesse fra i dati. È comprensibile come gli attributi
headers siano necessari per rendere comprensibile il contenuto agli utenti
che utilizzano lettori dello schermo. In caso di uso scorretto, a maggior
ragione nel caso di tabelle complesse, non verranno lette le intestazioni
prima del valore di una cella dati. Di conseguenza l'utente sarebbe
costretto a ricordare tutti i record della tabella.
5.5 Per ogni tabella definire un sommario dei contenuti.
Un sommario delle tabelle (definito con l'attributo summary) è
particolarmente utile per le tecnologie assistive utilizzate dagli utenti non
vedenti. Qualsiasi tabella di dati dovrebbe contenere delle informazioni
preventive, valorizzando l'elemento <caption>, eventualmente sostituibile
dall'attributo title se si desidera renderlo visibile esclusivamente agli utenti
non vedenti. Mentre l'elemento <caption> e l'attributo title rappresentano
un "titolo" della tabella, l'attributo summary è di fatto una guida all'utente
sul contenuto e sull'organizzazione della tabella dati.
In questo caso gli utenti non vedenti, ricevendo informazioni descrittive
dei contenuti grazie al contenuto dell'attributo summary, potranno valutare
se fruire del contenuto della tabella o passare al paragrafo successivo.
5.6 Fornire abbreviazioni per le etichette di intestazione.
Come detto nel punto di controllo 5.1, per non appesantire
eccessivamente le frasi, si fa uso dell'attributo abbr nell'elemento <th>;
grazie ad esso lo screen reader leggerà solo nella prima riga il contenuto
dell'attributo headers per poi leggere dalla seconda in poi il contenuto di
abbr, in modo da eliminare eccessive ripetizioni.
92
Come esempio riassuntivo di tutti i punti di controllo di questa linea guida,
qui di seguito si riporta una tabella utilizzata in Arianna, in cui vengono
elencate le ultime prescrizioni data a un assistito
Figura 4.18: esempio di una tabella formattata correttamente
Listato 11: Esempio di tabella a più livelli logici.
<table class="tabpresc" summary="In questa tabella sono elencate
tutte le prescrizioni dei farmaci">
<caption><abbr title="numero">Nr.</abbr> 2 prescrizioni registrate
nel DataBase:</caption>
<thead>
<tr>
<th class="blu" id="farmaco prescritto"
abbr="farmaco">Farmaco
Prescritto:</th>
<th class="blu"id="data inizio somministrazione"
abbr="somministrato dal">Data inizio somministrazione:</th>
<th class="blu" id="data fine somministrazione" abbr="fine
somministrazione">Data fine somministrazione:</th>
<th class="blu" id="posologia">Posologia:</th>
</tr>
93
</thead>
<tbody>
<tr>
<td class="blu" headers="farmaco prescritto">CIPROXIN
(antibiotico per via orale)</td>
<td class="blu" headers="data inizio
somministrazione">31/12/2006</td>
<td class="blu" headers="data fine
somministrazione">07/01/2007</td>
<td class="blu" headers="posologia">2 pasticche al dì dopo i
pasti</td>
</tr>
<tr>
<td class="blu" headers="farmaco prescritto">MAALOX
PLUS*3OCPR MAAST</td>
<td class="blu" headers="data inizio
somministrazione">31/01/2007</td>
<td class="blu" headers="data fine
somministrazione">02/02/2007</td>
<td class="blu" headers="posologia">1 bustina al giorno</td>
</tr>
</tbody>
</table>
Il programma di lettura dello schermo leggerà i dati della tabella nel modo
seguente:
Caption:Numero 2 prescrizioni registrate nel DataBase;
Summary:In questa tabella sono elencate tutte le prescrizioni dei
farmaci;
farmaco prescritto: CIPROXIN (antibiotico per via orale) ,data inizio
somministrazione: 31/12/2006 ,data fine somministrazione: 07/01/2007
,posologia: 2 pasticche al dì dopo i pasti;
farmaco: MAALOX PLUS*3OCPR MAAST somministrato dal: 31/01/2007, fine
somministrazione: 02/02/2007 ,posologia:1 bustina al giorno.
Linea guida 6: garantire che le pagine che utilizzano tecnologie più
recenti si trasformino in maniera gradevole
6.1 Organizzare i documenti in modo che possano essere letti
anche in assenza dei fogli di stile.
È necessario sviluppare i siti in modo che possano essere fruiti anche se
il browser utilizzato dall'utente non supporta i fogli di stile: la finalità dello
94
sviluppatore deve essere quella di garantire la fruibilità del sito e, di
conseguenza, l'accessibilità e l'usabilità dei suoi contenuti.
Prendiamo come esempio il menù laterale dell'Assistente Personale; in
pratica è una lista non numerata che, “modificata” con un CSS viene
visualizzata come una pulsantiera.
Figura 4.19: esempio di trasformazione di una lista in pulsantiera
Se si disattivano i CSS dalla pagina (tramite il plugin web Developer di
Firefox) il risultato è il seguente.
Figura 4.20: disabilitazione dei CSS
Listato 12: Codice della pulsantiera laterale con relativo foglio di stile
html
<div class="menuNavigazione">
<ul>
<li><a accesskey="i" href="../info.jsp" target="mainFrame"
title="cliccare qui per avere una sintesti delle notizie che ti
riguardano">Informazioni</a></li>
<li><a accesskey="c" href="../fsclin.jsp" target="mainFrame"
title="cliccare qui per visualizzare il fascicolo clinico">Fascicolo
95
clinico</a></li>
<li><a accesskey="p" href="../percorsi.html"
target="mainFrame" title="cliccare qui per visualizzare i percorsi
che hai avviato" >Percorsi sanitari</a></li>
<li><a accesskey="r" href="../copGenPages/query.html"
target="mainFrame" title="cliccare qui per effettuare una ricerca su
rete">Ricerca su Internet</a></li>
<li><a accesskey="f" href="../forumPages/index.jsp"
target="mainFrame" title="cliccare qui per accedere al forum interno"
>Forum</a></li>
<li><a accesskey="e" href="../servlets/TempoQuest"
target="mainFrame" title="cliccare qui per uscire">Esci</a></li>
</ul>
</div>
CSS
.menuNavigazione{ width: 230px; }
.menuNavigazione ul{margin-left: 0;
padding-left: 0;
list-style-type:none;
margin-top:2.5em;
}
.menuNavigazione a{display:block;
text-decoration:none;
border:1px solid #999;
margin:1px 0;
padding:3px 10px;
background:#555;
color:#FFF;}
.menuNavigazione
a:hover{background:#FFF;
color:#000;}
6.3 Garantire che le pagine siano utilizzabili quando script,
applet, o altri oggetti di programmazione sono disabilitati oppure
non supportati. Se questo non è possibile, fornire informazione
equivalente in una pagina accessibile alternativa.
Gli sviluppatori devono creare contenuti per il Web fruibili anche quando
gli script vengono disattivati o se il browser in uso non li supporta.
Un'istruzione come la seguente, che consente di tornare alla pagina
precedente, non potrà essere utilizzata dagli utenti che hanno disabilitato
gli script o che utilizzano browser che non li supportano.
Per evitare tali problemi riguardo il portale Arianna è stato deciso di
96
evitare di ricorrere al DHTML (combinando JavaScript, CSS e HTML).
6.4 Garantire che i gestori di eventi per gli script e le applet
siano indipendenti dai dispositivi di input.
Un gestore di eventi, è un insieme di istruzioni che vengono richiamate
quando un particolare evento viene soddisfatto (per esempio, il
movimento del mouse, la pressione di un tasto, il caricamento della
pagina, e così via). In HTML 4.01 e XHTML i gestori degli eventi associati
agli elementi vengono gestiti dai seguenti attributi, ordinati per tipo di
evento.
onload-onunload;
onclick-ondblclick;
onmousedown-onmouseup-onmouseover-onmousemove-onmouseout;
onfocus-onblur;
onkeypress-onkeydown-onkeyup;
onsubmit;
onreset;
onselect;
onchange;
Alcuni di questi eventi, come onsubmit, sono indipendenti dai dispositivi di
input, altri invece richiedono l'utilizzo del mouse (tutto il gruppo
onmouse... e onclick). Altri ancora richiedono l'utilizzo della tastiera
(onkey...). Se fosse necessario usare eventi che richiedano interazione
all'utente, bisogna garantirne l'esecuzione, che l'utente utilizzi una
periferica di puntamento, una tastiera o un emulatore di tastiera. È quindi
necessario definire un equivalente comando da tastiera per ogni comando
tramite mouse: i comandi da tastiera vengono spesso utilizzati per le
tecnologie assistive e possono essere attivati anche tramite comandi
vocali.
È possibile associare alcuni eventi a coppie;
•
onmousedown con onkeydown;
•
onmouseup con onkeyup;
97
•
onclick con onkeypress;
Nel sito dell'Assistente personale un esempio di applicazione di questa
linea guida si può trovare nella mappa di navigazione, posta in alto a
sinistra del frame principale.
Figura 4.21:utilizzo del gestore degli eventi per la pulsantiera
Listato 13: Utilizzo di codice JavaScript indipendente dal dispositivo.
<div
id="percorso">
<a href="../info.jsp"
onclick="top.frames[4].location.replace('../info.jsp')"
onkeypress="top.frames[4].location.replace('../home.jsp')">Home</a>
&gt;
<a href="../fsclin.jsp"
onclick="top.frames[4].location.replace('../fsclin.jsp')"
onkeypress="top.frames[4].location.replace('../fsclin.jsp')">
Fascicolo clinico</a> &gt; Prescrizioni mediche
</div>
6.5 Garantire che il contenuto dinamico sia accessibile oppure
fornire una presentazione o una pagina alternativa.
È necessario che uno sviluppatore riesca a fornire i contenuti dinamici in
formato accessibile. se ciò non fosse possibile, è necessario fornire una
98
versione alternativa della pagina che dovrà contenere le stesse
informazioni ed essere aggiornata con la frequenza della pagina originale.
Il modo migliore per generare contenuti dinamici accessibili è utilizzare gli
script server-side (ASP, PHP, PERL, ...) che generano contenuto
dinamico indipendentemente dal browser utilizzato dall'utente. Ci sono 2
tecniche raccomandate dal W3C per fornire un collegamento alle pagine
alternative:
•
•
inserendo all'inizio e alla fine del collegamento un collegamento a
tali pagine (deve risultare tra uno dei primi nella tabulazione);
utilizzando l'elemento <link>. Tramite questa tag è possibile
visualizzare la pagina alternativa a seconda delle impostazioni
predefinite dall'utente.
Per gli script si utilizzerà la tag <noscript> per rendere accessibile il
documento fornendo una versione equivalente o, almeno alternativa.
Nel caso si utilizzino dei frame, è necessario definire il contenuto per
l'elemento <noframes>. Spesso gli editor HTML visuali generano
automaticamente un testo per l'elemento <noframes> per informare gli
utenti della necessità di utilizzare un browser che supporti i frame: ciò non
è corretto, in quanto il contenuto di <noframes> deve riportare
informazioni equivalenti a quelle presenti nei frame.
Listato 14: esempio di frameset con l'elemento <noframes>.
<frameset rows="230,*" cols="*">
<frameset cols="270,*">
<frame src="./logo.html" name="leftFrame" frameborder="0"
scrolling="no" noresize="noresize" title="logo dell'azienda">
<frame
src="http://www.verbotsonline.com/VerbotsOnlineWeb/webclient/detect.h
tml?botcode=yglbxdt95c4r&input=pronuncia Autenticarsi per accedere ai
servizi." name="verbotFrame" frameborder="0" scrolling="no"
title="chatterbox in cui viene caricato l'assistente personale">
</frameset>
<frame src="./login.html" name="mainFrame" frameborder="0"
noresize="noresize" title="frame principale in cui vengono caricate
tutte le pagine">
<noframes>
<body>
<h1>ATTENZIONE: Frames Non Supportati</h1>
<h2> Il documento è composto da 3 frame di cui sono
riportati
i collegamenti:</h2>
<ul>
99
<li><a href="./logo.html" title="logo
dell'azienda">logo</a></li>
<li><a accesskey="c"
href="http://www.verbotsonline.com/VerbotsOnlineWeb/webclient/detect.
html?botcode=yglbxdt95c4r&amp;input=pronuncia Autenticarsi per
accedere ai servizi." title="chatterbox in cui viene caricato
l'assistente personale">Chatterbox in cui vengono caricate le
informazioni vocali</a></li>
<li><a accesskey="l" href="./login.html" title="frame principale in
cui vengono caricate tutte le pagine">Pagina per la registrazione e/o
per l'autenticazione</a></li>
</ul>
</body>
</noframes>
</frameset>
Per verificare che la versione equivalente sia accessibile in Arianna è
stato utilizzato un browser testuale che non supporta i frames, lynx.
Figura 4.22: home page di Arianna visualizzata con Lynx
Linea guida 9: progettare garantendo l'indipendenza dal dispositivo
9.3 Negli script, specificare gestori di evento logici piuttosto che
100
gestori di evento dipendenti dal dispositivo.
Questo punto di controllo può definirsi una accentuazione di quanto
richiesto dal 6.4. Ricordo che i comandi tastiera vengono spesso utilizzati
dalle tecnologie assistive e possono essere utilizzati per attivare
funzionalità tramite comandi vocali.
La maggior parte dei produttori di tecnologie assistive preferisce quindi
appoggiarsi alle caratteristiche di accessibilità dei sistemi operativi sui
quali sviluppa le applicazioni, in modo da consentirne la piena interazione
e compatibilità.
Possiamo quindi affiliare alcuni eventi nel modo seguente:
•
usare onmousedown con onkeydown;
•
usare onmouseup con onkeyup;
•
usare onclick con onkeypress.
In HTML non esiste un comando da tastiera equivalente al doppio click
del mouse (ondblclick).È quindi importante specificare sempre eventi che
non siano legati, per esempio, al movimento del mouse ma che abbiano
sempre un equivalente tramite comando tastiera in quanto su tali comandi
si basano principalmente le tecnologie assistive.
9.4 Creare un ordine logico di tabulazione fra i collegamenti, i
controlli dei moduli e gli oggetti.
Chi utilizza la tastiera per navigare all'interno di una pagina Web, utilizza il
tasto TAB per passare da un elemento al successivo. È quindi chiaro che
affinché il contenuto di una pagina sia comprensibile deve essere
strutturato in modo da seguire un ordine logico.
Generalmente la navigazione tramite il tasto tab avviene lateralmente. Nel
caso in cui sia necessario navigare nella pagina spostandosi per colonne,
o comunque sia in maniera differente da quella di default, in modo da
mantenere l'ordine logico, è necessario utilizzare l'attributo tabindex.
Questo attributo è utilizzabile com gli elementi <a>, <area>, <button>,
101
<input>, <object>, <select>, <textarea>. Spostandosi col tasto tab,
utilizzando tabindex ci si sposta dal valore più piccolo al più grande (da 0
a 32767). Come verifica dell'ordine di tabulazione è sufficiente premere
ripetutamente il tasto tab per controllare quali elementi vengono via via
selezionati.
Un esempio di applicazione di tale attributo lo troviamo fin dalla pagina di
login di Arianna.
Listato 14: uso dell'attributo tabindex nella pagina di login.
...<input tabindex="0"accesskey="s" type="button" value=" Aiuto
"...>...
...<form name="userData" action="./servlets/CheckUserData"
method="post" target="_top" onsubmit="return checkData(this)">
<h4 id="index">Inserire i dati per l'autenticazione</h4>
<label for="usr">Nome Utente</label><br/>
<input tabindex="2" id="usr" name="usn" size="30"...>
<label for="pwd">Password</label><br/>
<input tabindex="3" id="pwd" type="password" name="psw"
...><br/><br/>
<p>
<input tabindex="4" type="radio" checked="checked"
value="assistito" name="role" .../>Assistito
<input type="radio" value="medBase" name="role"
.../>Medico
di Base
<input type="radio" value="medSpec" name="role"
.../>Medico
Specialista
</p>
<p>
<input tabindex="6" accesskey="e" name="submit"
type="submit"
value="Entra" .../> &nbsp;&nbsp;&nbsp;
<input tabindex="5" accesskey="c" name="reset"
type="reset"
value="Cancella".../>
<input tabindex="1" accesskey="r" .../>
</p>
</form>
9.5 Fornire scorciatoie da tastiera per i collegamenti importanti
(compresi quelli nelle mappe immagine lato client), per i controlli
dei moduli e per i gruppi di controlli dei moduli.
Come appena visto nel punto di controllo precedente è possibile utilizzare
il tasto di tabulazione per muoversi tra gli elementi all'interno di una
pagina Web. HTML consente anche di assegnare ad un qualsiasi tasto un
102
collegamento diretto con link o elementi all'interno di moduli: l'uso della
lettera H, per esempio, potrebbe riportare l'utente alla home page così
come l'uso della lettera C può posizionare il focus nel modulo di ricerca.
Questi tasti di accesso rapido sono definiti tramite l'attributo accesskey
che consentono di fatto una navigazione veloce tramite tastiera.
Gli elementi che supportano l'attributo accesskey sono:
<a>, <area>, <button>, <input>, <label>, <legend>, <textarea>.
Le accesskey vengono attivate in modo differente secondo browser e
sistema operativo in uso; per esempio in Explorer bisogna digitare il tasto
ALT più invio, mentre su Mozilla e Netscape è sufficiente premere il tasto
ALT.
Un problema dell'attributo accesskey è che molte combinazioni di tasti
con ALT (ALT+F per esempio) sono già utilizzati dai browser come tasti di
accesso rapido, oppure per la ricerca di una parola del documento,
rendendo quasi impossibile la navigazione tramite questo attributo senza
incorrere in un conflitto. Pertanto alcuni esperti consigliano di utilizzare i
caratteri numerici come accesskey, in quanto possono creare problemi
esclusivamente con utenti che utilizzano tastiere con lingue orientali o con
alcune applicazioni di lettori di schermo. Altri consigliano di creare una
pagina interna al sito di “dichiarazione di accessibilità” e assegnarvi
l'accesskey zero ('0'): all'interno di questa pagina dovrebbe esser indicata
la mappa delle accesskey di tutte le caratteristiche che consentono di
accedere al sito web.
All'interno di Arianna, un utilizzo corretto dell'attributo accesskey è stato
fatto nel menù laterale
Listato 15: Esempio di utilizzo dell'attributo accesskey nella pulsantiera laterale
<ul>
<li><a accesskey="i" href="../info.jsp" target="mainFrame"
title="cliccare qui per avere una sintesti delle notizie che
ti
riguardano">Informazioni</a></li>
<li><a accesskey="c" href="../fsclin.jsp" target="mainFrame"
title="...">Fascicolo clinico</a></li>
<li><a accesskey="p" href="../percorsi.html"
target="mainFrame"
title="...”>Percorsi sanitari</a></li>
<li><a accesskey="r" href="../copGenPages/query.html"
target="mainFrame" title="...">Ricerca su Internet</a></li>
103
<li><a accesskey="f" href="../forumPages/index.jsp"
target="mainFrame" title="...">Forum</a></li>
<li><a accesskey="e" href="../servlets/TempoQuest"
target="mainFrame" title="...">Esci</a></li>
</ul>
Le accesskey non vengono rese visibili all'interno della pagina ed è quindi
necessario prevedere una formattazione tramite foglio di stile. Per
esempio, nel nostro caso se volessimo far comparire l'accesskey a
schermo subito dopo il collegamento ipertestuale, è necessario operare
nel CSS della pagina con una istruzione come la seguente:
Listato 16: Formattazione tramite foglio di stile per visionare l'attributo
accesskey.
a:after { content: " (" attr(accesskey) ") " }
Linea guida 10: usare soluzioni temporanee
10.1 Fino a quando i programmi utente non permetteranno agli
utenti di bloccare l'apertura di nuove finestre, non fare apparire
pop-up di altro tipo e non cambiare la finestra attiva senza
informare l'utente.
Navigando in rete spesso capita d'imbattersi in pagine web in cui sono
presenti collegamenti che portano all'apertura di nuove finestre o pop-up.
Mentre a un utente normale ciò provoca solo una distrazione, l'utente non
vedente che utilizza uno screen reader per navigare, si ritroverà in una
nuova pagina, spesso senza nemmeno averla richiesta, senza alcun
preavviso e perdendo il focus della pagina che stava consultando.
Esistono browser che permettono di disabilitare le finestre di pop-up
(Mozilla, Netscape o Explorer). Comunque sia non conviene dare
informazioni importanti nei pop-up, poiché c'è il rischio che a tale
contenuto non si riesca ad accedere.
Per un corretto reindirizzamento si utilizza l'attributo target (nelle tag <a>
e <frame>) in cui si definisce la destinazione del documento. Nel caso
dell'apertura di una nuova finestra target assume il valore blank.
Se non è possibile fare a meno di una nuova fniestra, è almeno
necessario che l'utente sia informato, utilizzando l'attributo title; un
104
esempio corretto in Arianna lo troviamo nell'apertura di una nuova pagina
in cui si fornisce una versione stampabile dei dati del fascicolo clinico.
Figura 4.23: esempio di apertura nuova finestra
105
Listato 16:Esempio corretto di collegamento con apertura di nuova finestra.
<a href="/Arianna/stampabili/prescstampa.jsp" target="_blank"
title="Attenzione: si aprirà una nuova finestra con una versione
stampabile delle prescrizioni">Versione stampabile</a>
In questo caso, per facilitare l'utente, è stato posto un bottone “chiudi”
nella nuova finestra.
10.2 Fino a quando i programmi utente non supporteranno
esplicite associazioni fra etichette e controlli dei moduli,
garantire che l'etichetta sia posizionata correttamente per tutti i
controlli dei moduli che hanno etichette associate
implicitamente.
All'interno dei moduli è quasi sempre presente un testo che accompagna,
per esempio, un campo di inserimento testo: è grazie a questo testo che
possiamo ottenere informazioni chiare su quali dati sono richiesti.
Pensiamo quindi ad un utente che utilizza un lettore di schermo e che si
trova a dover compilare dei moduli: nel caso queste etichette non siano
presenti o non siano posizionate correttamente l'utente non potrà
procedere con la compilazione.
Questi testi possono essere inseriti all'interno dell'elemento <label> che
viene associato ad un elemento interno al modulo. Per far ciò si usa
l'attributo for per label e l'attributo id per il l'elemento input;
l'accoppiamento avviene tra i label e gli input in cui il contenuto
rispettivamente all'interno di for e id coincidono.
Nell'Assistente Personale un esempio di utilizzo di tale tecnica si trova
nelle pagine di registrazione.
Listato 17: Utilizzo dell'elemento <label>.
...<label for="nome">Nome*</label>
<input id="nome" name="nome" size="30" maxlength="30">...
...<label for="cognome">Cognome*</label>
<input id="cognome" name="cognome" size="30" maxlength="30">...
...<label for="codFis">Codice Fiscale*</label>
<input id="codFis" name="codfis" size="30" maxlength="30">
Livello di accesso*
106
<input id="assistito" type="radio" name="lvl" value="A">
<label for="assistito">&nbsp;Assisito&nbsp;</label>
<input id="MMG" type="radio" name="lvl" value="mb">
<label for="MMG">&nbsp;<abbr title="Medico di medicina
generale">MMG</abbr>&nbsp;</label>
<input id="medSpec" type="radio" name="lvl" value="ms">
<label for="medSpec">&nbsp;Medico specialista</label>
Sesso*
<input id="sexM" type="radio" name="sex" value="m">
<label for="sexM"> Maschio</label>
<input id="sexF" type="radio" name="sex" value="f">
<label for="sexF"> Femmina</label></div>
10.3 Fino a quando i programmi utente (comprese le tecnologie
assistive) non rappresenteranno in modo corretto il testo
affiancato, fornire un testo lineare alternativo (nella pagina attiva
o in altra pagina) per tutte le tabelle che dispongono testo su
colonne parallele e andando a capo.
Come già analizzato nella Linea Guida 5, questo punto di controllo
favorisce le persone che utilizzano interpreti (come alcuni lettori di
schermo) che non sono in grado di gestire blocchi di testo affiancati.
CAPITOLO 1
Questo è il testo del
primo capitolo del
libro scritto da...
CAPITOLO 2
Siamo al secondo
capitolo, dopo aver letto
il primo che...
CAPITOLO 3
Ed ecco ora il gran
finale: ad uccidere la
Contessa è stato...
In questo esempio lo screen reader leggerebbe così:
CAPITOLO 1,
CAPITOLO 2,
CAPITOLO 3,
Questo è il testo del primo capitolo del libro scritto da...,
Siamo al secondo capitolo, dopo aver letto il primo che...,
Ed ecco ora il gran finale: ad uccidere la Contessa è stato...
che non è la maniera corretta di leggerla. È vero che alcuni lettori di
schermo e alcuni browser riescono a linearizzare in modo automatico le
tabelle: il WAI ERWG (Evalutation and Repair Working Group) ha
sviluppato uno strumento per linearizzare le tabelle, chiamato Tablin.
Tuttavia, nel caso sia impossibile linearizzare il contenuto di una tabella è
necessario proporre una versione alternativa prima della sua effettiva
107
visualizzazione (o lettura).
In Arianna l'uso delle tabelle è stato fatto al minimo, per incolonnare il
documento in due o più colonne è stata adottata la tecnica dei CSS; un
esempio si trova nel frame principale di benvenuto.
.colonna-1of3
.colonna-2of3
.colonna-3of3
Figura 4.24: formattazione in colonne utilizzando i CSS
Listato 18: uso dei CSS per la formattazione della pagina.
/* formattazione per 3 colonne */
.colonna-1of3{float:left;
width:30%;
margin-left:1.5%;
margin-right:1.5%;}
.colonna-2of3{float:left;
width:30%;
margin-right:1.5%;
margin-left:1.5%; }
.colonna-3of3{float:left;
width:30%;
margin-left:1.5%;
margin-right:-5%; }
10.4 Fino a quando i programmi utente non gestiranno in
maniera corretta i controlli vuoti, inserire caratteri predefiniti
come segnaposto nelle caselle per l'immissione di testo a una o
a più righe.
108
Alcuni vecchi browser per poter interagire in modo corretto all'interno dei
moduli, richiedono la presenza di testo all'interno di campi di input a riga
singola e a più righe (aree di testo) in quanto senza questi testi i campi
modulo non possono essere accessibili tramite il tasto TAB.
La presenza di testi predefiniti consente sia di rendere accessibile il
contenuto dei moduli agli utenti che utilizzano queste tecnologie che ad
utenti con disabilità di tipo cognitivo che possono ottenere dei
"suggerimenti" sul contenuto da inserire in tali campi.
Per gli elementi di tipo <input> il testo predefinito può essere impostato
tramite l'attributo value mentre per l'elemento <textarea> il testo deve
essere inserito tra l'apertura e la chiusura dell'elemento.
Un esempio di corretto utilizzo dell'elemento <input> e dell'elemento
<textarea> per il rispetto del punto di controllo 10.4 è presente nella
pagina che segue. In questi esempi utilizzo sia l'attributo id sia l'attributo
name per compatibilità con le versioni Transitional di HTML e XHTML
mentre se si utilizza XHTML Strict l'attributo name non va utilizzato in
quanto deprecato a favore dell'attributo id.
I moderni browser, comprese le tecnologie assistive, hanno la capacità di
operare senza la necessità di questi testi.
10.5 Fino a quando i programmi utente (comprese le tecnologie
assistive) non rappresenteranno in modo distinto collegamenti
adiacenti, inserire caratteri stampabili (delimitati da spazi), non
facenti parte dei collegamenti, per separare i collegamenti
adiacenti.
Utilizzare collegamenti troppo vicini tra loro può creare problemi ad alcune
tecnologie assistive e browser. Utilizzando spazi assieme a dei caratteri
stampabili esterni ai collegamenti è possibile allo stesso tempo soddisfare
questo punto di controllo e dare un effetto gradevole, rendendo
maggiormente comprensibile la separazione dei collegamenti.
I caratteri non compresi nei collegamenti ipertestuali consentono di
ottenere una pausa nella lettura da parte dei lettori di schermo
109
consentendo di individuare l'inizio e la fine di un collegamento. Allo stesso
tempo questo sistema consente una migliore comprensione dei contenuti
alle persone con disabilità di tipo cognitivo, visivo o con disabilità motorie.
Una soluzione alternativa è di utilizzare le liste per la visualizzazione dei
collegamenti rendendoli poi gradevoli tramite fogli di stile: in questo modo
è quindi possibile garantire la separazione tra contenuto e presentazione,
nonché superare la problematica relativa a questo punto di controllo.
Nel sito dell'Assistente Personale, questa tecnica è stata utilizzata
nell'elenco delle bandiere delle lingue in cui è possibile consultare il
portale sanitario.
Listato 19: esempio di codice html e rispettivo css per collegamenti adiacenti
html
<div class="lingua">
<ul>
<li><em lang="en"><a href="...” ...><img ... /></a></em></li>
<li><em lang="es"><a href="...”...><img.../></a></em></li>
</ul>
</div>
CSS
.lingua ul, .lingua li { padding:0,0.5em,0,0.5em;
margin:0;
display:inline;
border-left: 1em; }
Linea guida 11: usare le tecnologie e le linee guida del W3C
11.1 Utilizzare le tecnologie W3C quando sono disponibili e
sono appropriate per un certo compito usando le versioni più
recenti quando sono supportate dai programmi utente.
I gruppi di lavoro che si occupano della creazione delle specifiche delle
raccomandazioni del W3C tengono in considerazione l'attività del progetto
WAI e quindi coinvolgono gli esperti di accessibilità per valutare di volta in
110
volta come le ). nuove specifiche possano rispettare il principio di
universalità del World Wide Web: è anche questo il motivo per cui le
raccomandazioni del W3C sono universalmente riconosciute come
standard de facto. È pur vero che con il rilascio di nuove specifiche i
browser e le tecnologie assistive devono aggiornare i loro motori per
rendere fruibili queste nuove caratteristiche, considerando che tutte le
nuove specifiche mirano a mantenere una compatibilità con le precedenti.
Può quindi succedere che attributi come longdesc per le immagini non
vengano riconosciuti e ignorati da alcuni browser e/o tecnologie assistive
ma questo non significa che per una tecnologia che non lo utilizza non ve
ne siano altre che rispettano le raccomandazioni del W3C. Ciò significa
che i contenuti delle pagine Web devono validare secondo le
grammatiche formali (vedi il punto di controllo 3.2) utilizzando per
esempio il validatore di codice HTML (http://validator.w3.org) o il
validatore di fogli di stile (http://jigsaw.w3.org/css-validator/). È bene
quindi cercare di mantenere le proprie pagine secondo le ultime
specifiche del W3C: l'elenco completo e costantemente aggiornato è
disponibili nella pagina W3C Technical Reports and Publications
(http://www.w3.org/TR/). Le principali specifiche sono:
●
MathML per equazioni matematiche;
●
HTML, XHTML, XML per la struttura dei documenti;
●
RDF per i meta data;
●
SMIL per creare presentazioni multimediali;
●
CSS e XSL per la definizione dei fogli di stile;
●
XSLT per creare trasformazioni dei fogli di stile;
●
PNG per la grafica.
Riassumendo non esiste il programma (browser o screenreader che sia)
che sia completamente fedele agli standard forniti dal W3C. Sul Web in
alcuni portali (uno è webstandardso.org) sono disponibili alcune
rinformazioni sull'effettiva applicazione degli standard per i programmi
user agent più diffusi.
11.2 Evitare l'utilizzo di caratteristiche disapprovate dal W3C.
111
Con la definizione di nuove raccomandazioni e con l'avvento di nuove
tecnologie alcuni elementi e attributi possono essere eliminati a favore di
nuove raccomandazioni che ne migliorano l'utilizzo. Un esempio concreto
è dato dall'elemento <font> che è stato disapprovato (deprecated) dal
W3C a favore dei fogli di stile che consentono di separare il contenuto
dalla presentazione. Per lo stesso motivo, l'attributo color è stato
deprecato, sempre a favore dell'utilizzo dei fogli di stile. Gli elementi e gli
attributi disapprovati diventano quindi obsoleti e vengono solitamente
mantenuti nelle grammatiche dei DOCTYPE di tipo Transitional (ossia
grammatiche di transizione) mentre vengono rimossi nelle grammatiche
dei DOCTYPE di tipo Strict: un ulteriore esempio è dato dall'attributo
target per i collegamenti che in XHTML 1.x Strict è deprecato. Elementi
come <applet> ed <embed> sono stati sostituiti dall'elemento <object>
che consente di trasformare il contenuto in modo gradevole nel caso non
sia presente l'oggetto richiesto ma il cui supporto però con alcuni browser
e tecnologie assistive non è ancora ottimale. Per la massima accessibilità
si consiglia quindi di utilizzare le grammatiche con DOCTYPE di tipo
Strict. L'elenco degli elementi ed attributi utilizzabili è disponibile
direttamente nel sito del W3C, dove con asterisco sono indicati gli
elementi e gli attributi disapprovati. Ma come possiamo ottenere gli effetti
grafici e le impostazioni che utilizzavamo tramite l'elemento font tramite i
fogli di stile ed allo stesso tempo garantire l'accessibilità della nostra
pagina web? Invece di utilizzare elementi ed attributi disapprovati per
controllare la grafica della presentazione, è invece possibile utilizzare i
seguenti attributi tramite fogli di stile:
●
font (solo CSS 2.x)
●
font-family
●
font-size
●
font-size-adjust
●
font-stretch
●
font-style
●
font-variant
●
font-weight
112
●
color
●
background-color
Listato 20: Esempio di definizione corretta dei caratteri in un foglio di stile.
body {
margin:0;
padding:0;
font: 14px Verdana, Geneva, Arial, Helvetica, sans-serif;
color:#000000 /*nero*/
float:left;}
11.3 Fornire agli utenti l'informazione necessaria perché
possano ricevere i documenti in modo che si adattino alle loro
preferenze (per lingua, per tipo di contenuto, ecc.).
La maggior parte dei browser consente una configurazione in modo che
richiedendo una determinata pagina, il server possa riconoscere la lingua
prescelta. A questo punto server ed il browser negozieranno il contenuto
da presentare e questo consentirà di ottenere direttamente la pagina nella
lingua predefinita dall'utente: questo si chiama negoziazione dei contenuti
(HTTP Content Negotiation) di cui è disponibile una pagina informativa sul
sito del W3C. La negoziazione dei contenuti è attuabile solo se supportata
dal proprio server. Selezionando per esempio la pagina Web nel sito del
W3C all'URL http://www.w3.org/Press/1998/CSS2-REC con un browser
con impostazione di lingua italiana, verrà visualizzata una pagina di errore
(Errore 406) contenente le possibilità di visualizzazione del contenuto in
altre lingue. Questo consente quindi di eliminare dall'interno della pagina i
collegamenti alle pagine in altre lingue.
Quando all'interno dei nostri elementi meta si inserisce il codice seguente,
indichiamo chiaramente qual'è la codifica della nostra pagina:
Listato 21: utilizzo dell'elemento <meta> per definire la codifica della pagina
Web ISO-8859-1.
<meta http-equiv="Content-Type" content="text/html; charset=ISO-88591" />
Se per esempio avessimo voluto visualizzare una pagina con codifica in
giapponese, l'istruzione corretta da inserire nel codice della pagina
113
Websarebbe stata la seguente:
Listato 22: Utilizzo dell'elemento <meta> per definire la codifica della pagina
Web ISO-2022-jp.
<meta http-equiv="Content-type" content="text/html; charset=ISO-2022jp" />
Utilizzando invece l'attributo lang è possibile consentire la possibilità di
cambiare l'assegnazione della lingua predefinita della pagina (per
esempio per una corretta lettura tramite lettore di schermo) oppure
definire delle informazioni per i motori di ricerca in una particolare lingua:
Listato 23: utilizzo dell'elemento <meta> per definire le parole chiave in diverse
lingue.
<meta name="keywords" lang="it" content="italiano" /> <meta
name="keywords" lang="fr" content="françoise" />
Con la stessa modalità, mantenendo sempre il rispetto della linea guida
che richiede la separazione tra contenuto e presentazione è possibile
definire diversi fogli di stile a seconda del browser o della tecnologia
assistiva utilizzata dal visitatore del nostro sito
web. Poniamo per esempio il caso di un utente che utilizzi come
tecnologia assistiva un lettore vocale e vogliamo definire un particolare
tono della voce quando viene letto un elemento di tipo <h1>.
Creeremo quindi un foglio di stile dedicato che si occuperà di assegnare
una voce femminile a lettura lenta ma chiara:
Listato 24: foglio di stile Aureal con definizione della voce per l'elemento <h1>.
h1 { voice-family: announcer, female; stress: slow; richness: 70; }
Nelle ultime versioni di programmi come Jaws consentono di identificare
con tonalità di voce differente i diversi livelli di titolazione, i collegamenti,
ecc. Queste personalizzazioni però potrebbero rendere di difficile
comprensione il cambio di tonalità di voce se l'utente è già abituato a una
sua impostazione personalizzata. Sempre per consentire la
personalizzazione del contenuto, i CSS2 consentono allo sviluppatore di
creare dei fogli di stile per ogni tipo di periferiche come per esempio lo
114
schermo, la stampante, le barre Braille, ecc. Attualmente con i CSS2 i
media utilizzabili con i fogli di stile e quindi riconoscibili direttamente dai
browser o altre periferiche di navigazione sono i seguenti:
•
all: tutte le periferiche
•
aural: sintetizzatori vocali
•
braille: barre braille
•
embossed: stampanti braille
•
handheld: palmari
•
print: stampanti
•
projection: proiettori e/o lavagne luminose
•
screen: schermi da computer
•
tty: periferiche a carattere fisso (terminali, telescriventi, ecc.)
•
tv: periferiche televisive (Web TV, TV digitale, ecc.)
Creare dei fogli di stile per ogni periferica (device) riduce i tempi di
caricamento della pagina in quanto consentono ai programmi utenti di non
caricare le impostazioni di cui non necessitano. Ipotizzando per esempio
un foglio di stile per palmari, questa versione sicuramente consentirà un
caricamento più veloce dei contenuti rispetto ad una versione standard
del sito. È però da tenere presente che spesso gli stessi browser
all'interno dei computer palmari non utilizzano i fogli di stile dedicati
preferendo utilizzare i fogli di stile predefiniti per il media screen
adattandoli allo schermo del palmare.
Sono attualmente disponibili due modalità per specificare il caricamento di
questi fogli di stile: tramite importazione e tramite l'elemento <link>. Il
primo caso risulta ottimale per i browser di ultima generazione mentre nel
caso di vecchie versioni può creare dei problemi.
11.4 Se, nonostante ogni sforzo, non è possibile creare una
pagina accessibile, fornire un collegamento a una pagina
alternativa che si riferisca alle tecnologie W3C, che sia
accessibile, che contenga informazioni (o funzionalità)
115
equivalenti e sia aggiornata con la stessa frequenza della
pagina originale inaccessibile.
Gli sviluppatori dovrebbero ricorrere a pagine alternative solo quando le
altre soluzioni falliscono perché le pagine alternative sono in genere meno
aggiornate delle pagine principali.
Ipotizziamo un sito di un ente pubblico dove ogni ufficio inserisce dei
contenuti in modo autonomo: se 100 operatori inseriscono contenuti non
accessibili che richiedono una versione parallela, il costo e le ore
lavorative saranno quantomeno raddoppiate e sempre con il dubbio che
non tutte le pagine alternative siano aggiornate.
Una pagina non aggiornata può essere frustrante quanto una pagina
inaccessibile visto che, in entrambi i casi, l'informazione presentata nella
pagina originale non è disponibile. La generazione automatica di pagine
alternative può portare a aggiornamenti più frequenti, ma gli sviluppatori
devono comunque fare attenzione ad assicurare che le pagine generate
abbiano sempre senso, e che gli utenti siano in grado di navigare in un
sito seguendo i collegamenti delle pagine primarie, di quelle alternative, o
di entrambe (magari posizionando su ogni pagina il collegamento alla
versione alternativa). Alcuni esperti di accessibilità consigliano di iniziare
la conversione dei vecchi siti tramite versioni alternative solo testo, magari
con qualche foglio di stile dedicato a particolari tipi di disabilità.
Personalmente seguendo le indicazioni del W3C sconsiglio tale pratica
che rende pesante l'aggiornamento e che di fatto può risultare dannosa
all'accessibilità di un sito Web in quanto si utilizza tale modalità di ripiego
per "tenere la coscienza pulita" da eventuali incompetenze degli
sviluppatori o dei gestori dei contenuti. Prima di ricorrere a una pagina
alternativa, riesaminare il progetto della pagina originale; è probabile che
rendendola accessibile essa risulti migliore per tutti gli utenti. Il W3C non
parla mai di sito alternativo ma di pagina alternativa: chi crea siti
alternativi non rispetta le WCAG 1.0 e nemmeno i principi di sviluppo per
l'accesso universale. Inoltre la soluzione "solo testo", spesso utilizzata
anche da siti istituzionali, non è conforme a questa linea guida in quanto
non si tratta di pagina equivalente che utilizza le tecnologie W3C.
116
Linea guida 12: fornire informazioni per il contesto e l'orientamento
12.1 Assegnare un titolo a ogni frame per facilitarne
l'identificazione e la navigazione.
Alcuni programmi utente non possono accedere a più frame
contemporaneamente o possono essere configurati esclusivamente per
visualizzare un solo frame: un esempio possono essere le applicazioni
software di supporto per gli utenti non vedenti. Utilizzando l'attributo title
per i frame è possibile fornire informazioni al visitatore sul contenuto di
quella particolare pagina web, consentendo all'utente di selezionare il
frame desiderato.
Listato 25: esempio di corretta definizione di Frameset e titoli per i frame.
<frameset rows="230,*" cols="*">
<frameset cols="250,*">
<frame src="..." name="logo" frameborder="0" title="logo
dell'azienda" noresize scrolling="no">
<frame src="..." name="verbotFrame" frameborder="0" noresize
scrolling="no" title="assistente virtuale che espone un
quadro generale della situazione dell'assistito"/>
</frameset>
<frameset cols="250,*" rows="*">
<frame src="..." name="pulsantiera" frameborder="0" noresize
scrolling="no" title="menù laterale per la navigazione nelle
varie sezioni del portale"/>
<frame src="..." name="mainFrame" frameborder="0"
title="frame in cui vengono caricate tutte le pagine">
</frameset>
<noframes>...
12.2 Descrivere lo scopo dei frame e il modo in cui questi
interagiscono se non è evidente solo tramite i titoli dei frame.
Nel punto di controllo precedente abbiamo visto che utilizzando l'attributo
title possiamo dare alcune informazioni sul contenuto dei frame. È
possibile che il semplice title può non essere sufficiente per spiegare la
struttura o lo scopo dell'elemento <frame> o dell'elemento di
contenimento <Frameset>. Poniamo il caso di una pagina con cinque
frame: uno per la testata, uno a sinistra per la navigazione dei menù, uno
centrale per i contenuti, uno a destra per le ultime notizie ed uno alla fine
117
per la chiusura di pagina: come è possibile spiegarne la struttura tramite
l'attributo title? Già in questo paragrafo per spiegare in modo rapido una
struttura teorica ho utilizzato diverse righe di testo, che non avrei potuto
utilizzare con l'attributo title. In questi casi è consigliabile utilizzare
l'attributo longdesc per l'elemento frame al fine di rendere disponibile un
collegamento ad un documento (pagina senza frame) che contiene una
descrizione completa per una pagina con una struttura complessa di
frame. Una possibile alternativa per le descrizioni troppo lunghe dei frame
può essere la seguente:
Listato 26: esempio di corretta definizione di frameset, titoli e longdesc per i
frame
<frameset rows="230,*" cols="*">
<frameset cols="250,*">
<frame src="..." name="logo" frameborder="0" title="Logo
dell'azienda" noresize scrolling="no">
<frame src="..." name="verbotFrame" frameborder="0" noresize
scrolling="no" longdesc=”chatterbot.html”/>
</frameset>
<frameset cols="250,*" rows="*">
<frame src="..." name="pulsantiera" frameborder="0" noresize
scrolling="no" title="Menù navigazione"/>
<frame src="..." name="mainFrame" frameborder="0"
longdesc=”descr.html”>
</frameset>
<noframes>...
12.3 Dividere i grandi blocchi di informazione in gruppi più
maneggevoli quando è naturale ed appropriato.
All'interno di una pagina è possibile che vi siano raccolte molte
informazioni che se non vengono raggruppate possono creare confusione
e distrazione da parte dell'utente che fruisce dei contenuti. È quindi
necessario che lo sviluppatore utilizzi gli elementi di marcatura necessari
per diminuire questo disagio. Analizziamo in questo punto di controllo
quali siano gli elementi utilizzabili a tal fine.
Nel nostro caso uno dei principali problemi nel raggruppamento delle
informazioni in blocchi è stato nella compilazione dell'anamnesi
dell'assistito. Una tecnica semplice e allo stesso tempo gradevole è stata
l'utilizzo dell'elemento <fieldset> con il suo complementare <legend>
118
Figura 4.25:esempio di raggruppamento campi di modulo
Listato 27: utilizzo dell'elemento <fieldset> come raggruppamento per i campi
modulo
<h4>Informazioni sullo stile di vita</h4>
<form...>
<fieldset>
<legend>Stile di vita</legend>
<h5>11 Ha l'abitudine di fumare?</h5>
<p><input type="radio" value="noFumo" name="tabagismo"
id="nomai""/><label for="nomai">No, non ho mai fumato</label></p>
<p><input type="radio" value="passFumo" name="tabagismo"
id="nnpiù"/><label for="nnpiù">No, ma fumavo in passato</label></p>
<p><input type="radio" value="siFumo" name="tabagismo" /><label
for="si1"> (specificarne la quantità)</label><input id="si1"
type="text" name="qtyFumo"/></p>
<h5>12 In questo periodo sta seguendo qualche dieta?</h5>
<p><input type="radio" value="siDieta" name="dieta"
id="no2"/><label for="no2">No</label></p>
<p><input type="radio" value="noDieta" name="dieta"
id="si2"/><label for="si2">Si</label></p>
<h5>13 Se si, per quale motivo?</h5>
<p><input type="radio" value="estetico" name="usoDieta"
id="dima1"/><label for="dima1">Per dimagrire(per motivi
estetici)</label></p>
<p><input type="radio" value="dimagrimento" name="usoDieta"
id="dima2"/><label for="dima2">Per dimagrire</label></p>
<p><input type="radio" value="disintossicazione" name="usoDieta"
id="disintoss"/><label for="disintoss">Per
disintossicarmi</label></p>
<p><input type="radio" value="altraMotivazione" name="usoDieta"
/><label for="altro1">Per altri motivi</label> <input id="altro1"
119
type="text" name="altraDieta"/></p>
<h5>Se si, chi le ha prescritto la dieta?</h5>
<p><input type="radio" value="auto" name="prescrizioneDieta"
id="solo"/><label for="solo">Nessuno, faccio da solo/a</label></p>
<p><input type="radio" value="medico" name="prescrizioneDieta"
id="mmg"/><label for="mmg">Il medico di famiglia</label></p>
<p><input type="radio" value="specialista"
name="prescrizioneDieta" id="medSpec"/><label for="medSepc">Uno
specialista</label></p>
<p><input type="radio" value="estetista" name="prescrizioneDieta"
id="estet"/><label for="estet">Un estetista</label></p>
<p><input type="radio" value="altraDieta"
name="prescrizioneDieta" /><label for="altro2">Altro</label><input
id="altro2" type="text" name="altraPresc"/></p>
</fieldset>
<fieldset>
<legend>Attività extralavorative</legend>
<h5>15 Pratica attività di volontariato o fa parte di qualche
associazione di volontariato?</h5>
<p><input type="radio" value="noVolontariato" name="volontariato"
id="volNo"/><label for="volNo">No</label></p>
<p><input type="radio" value="siVolontariato"
name="volontariato" id="volSi"/><label for="volSi">Si (specificare)
</label><input type="text" name="specVol"/></p>
</fieldset><br>
<input class="pulsSpace" type="submit" value="Procedi"
name="procedi" title="per proseguire con la compilazione del
questionario clicchi qui"/>
<input class="pulsSpace" type="reset" value="Cancella"
name="reset" title="per cancellare le risposte del questionario
clicchi qui"/>
</form>
12.4 Associare esplicitamente le etichette ai loro controlli.
Abbiamo già approfondito nel punto di controllo 10.2 riguardo possibilità di
utilizzare delle etichette (elemento <label>) sia in modo implicito che in
modo esplicito.
Per soddisfare questo punto di controllo, è necessario utilizzare
l'elemento <label> in modo esplicito tramite l'attributo for che deve
corrispondere all'attributo id dell'elemento interno al modulo:
120
Listato 28: uso corretto delle etichette per i campi modulo.
...<label for="numTel"> Numero telefonico (*) </label><input
id="numTel" name="tel" size="30" maxlength="30" />
Linea guida 13: fornire chiari meccanismi di navigazione
13.1 Identificare con chiarezza la destinazione di ogni
collegamento.
Quando creiamo un collegamento ipertestuale (link) è necessario che il
testo del collegamento abbia un senso. La porzione di frase che deve
essere coinvolta non deve essere troppo lunga, non deve contenere il
“clicca qui” (manca la contestualità tra il testo di collegamento e la sua
destinazione; se necessario è possibile aggiungere l'attributo title per
descrivere meglio la pagina di destinazione. Oltre a tutte queste
indicazioni, come già detto in precedenza, è necessario che i notificare
l'utente se il collegamento a una pagina si apra su una nuova finestra.
Figura 4.26: uso della corretta parte della frase come collegamento
121
Listato 29: utilizzo corretto di testi nei collegamenti ipertestuali.
<h5 class="info"> Per visualizzare i referti degli esami <a
href="http://www.adobe.com/it/products/acrobat/readstep2.html"
target=_”blank” title="[nuova finestra] pagina di download adobe
reader"> Scarica Adobe Reader</a> se non lo hai gi&agrave; installato
<img src="./images/pdficon_large.gif" alt="logo formato pdf"
title="logo formato pdf"></h5>
13.2 Fornire metadati per aggiungere alle pagine ed ai siti
informazioni di tipo semantico.
All'interno di una pagina Web sono presenti degli elementi strutturali che
forniscono delle informazioni sul documento. Questi elementi sono
chiamati metadati, ossia informazioni su dati.
L'elemento <title>
L'elemento <title> specifica il titolo del documento e si differenzia
dall'attributo title in quanto compare una sola volta ed identifica in modo
univoco il titolo di una pagina.
L'elemento <meta>
Gli elementi <meta> possono fornire delle informazioni che consentono di
controllare i contenuti e fornire informazioni. Per esempio, per fornire
informazioni sul contenuto della pagina ai motori di ricerca si utilizza un
codice come il seguente.
La dichiarazione !DOCTYPE
Lo sviluppo di documenti che corrispondano a grammatiche formali,
preferibilmente se ufficiali del W3C (punto di controllo 3.2) è un requisito
basilare per la lettura dei contenuti di una pagina in quanto fornisce
informazioni specifiche al programma utente sul tipo di linguaggio
utilizzato.
Qui di seguito un frammento di codice per una corretta fornitura di
metadati
Listato 30: uso corretto degli elementi <title> <meta> e <!DOCTYPE>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
<html dir="ltr" lang="it">
<head>
<title>Arianna – Assistente Personale</title>
<meta name="description" content="divisione in frame della
homepage" />
<meta name="author" content="Michele Bianchella, Michele
122
Campanelli, Luigi Lella, Juri Orazi, Domenico Paccone" />
<meta name="keywords" content="informazioni sistema
sanitario, progetto Arianna " />
</head>...
13.3 Fornire informazioni sulla configurazione generale di un sito
(per esempio, una mappa oppure un indice dei contenuti).
Al fine di rispettare questo punto di controllo, un sito Web dovrebbe avere
un indice o una mappa che rappresenti i contenuti in modo schematico e
ad accesso immediato. La mappa di un sito Web o un indice dei contenuti
deve essere strutturata in modo da garantire la massima accessibilità,
quindi preferibilmente in HTML senza molte formattazioni.
È altresì necessario che il testo del collegamento corrisponda al titolo
principale (elemento <h1>) della pagina di destinazione in modo da non
confondere gli utenti con disabilità di tipo cognitivo. Uno degli errori da
evitare è quindi l'utilizzo di pagine Web con lo stesso titolo (elemento
<title>) proprio per non creare problemi di interpretazione da parte di
disabili cognitivi, utenti che utilizzano lettori di schermo ed anche utenti
senza disabilità.
Listato 31a: esempio di coerenza tra il nome del link e il titolo della pagina a cui
reindirizza.
...<li><a href=”...”>Fascicolo clinico</a></li>...
123
Listato 31b: header principale della pagina che coincide con il nome del
collegamento.
...<h1>Fascicolo clinico</h1>...
È inoltre consigliabile, se possibile, la creazione di una pagina
personalizzata di errore 404 ("page not found") che riporti alla pagina
contenente la mappa del sito e che consenta all'utente di ritornare alla
pagina precedente.
Figura 4.29: errore 404 con possibile reindirizzamento
124
13.4 Usare meccanismi di navigazione in modo coerente.
Se ogni pagina del vostro sito Web mantiene sempre uno stile uniforme
mantenendo per esempio lo stesso stile e la medesima posizione per la
barra di navigazione, una determinata posizione per il motore di ricerca,
ecc. i visitatori del sito otterranno una navigazione semplificata
individuando più facilmente le informazioni ricercate. Modificare
l'impostazione delle pagine per ogni pagina può disorientare i visitatori
riducendo quindi il piacere di navigare i contenuti del vostro sito web.
Attualmente grazie ai sistemi di gestione contenuti (CMS) e tramite
l'utilizzo di modelli (template) offerti dai più diffusi editor è più semplice
rispettare il requisito di questo punto di controllo.
13.5 Fornire barre di navigazione per evidenziare e dare
accesso ai meccanismi di navigazione.
Il percorso fornisce agli utenti le informazioni di cui essi hanno bisogno
per capire dove si trovano all'interno del sito web. Questo lo si fa creando
una struttura gerarchica che ha come punto iniziale la home page e come
punto finale la pagina che si è raggiunta. Tra il punto iniziale e quello
finale ci sono i link a tutte le pagine intermedie che sono state
attraversate.
Sul sito dell’assistente personale mancava completamente il percorso. In
ogni pagina quindi si è provveduto ad inserirlo in alto a sinistra. Si è partiti
dalla home page, che in pratica è la pagina di benvenuto (quella subito
dopo il login), fino a raggiungere la pagina che l’utente sta visitando. Tutte
le pagine attraversate possono essere visitate di nuovo cliccando
direttamente sui link del percorso.
125
Figura 4.30: tecnica delle breadcrumb come barra di
navigazione
Listato 31: barra di navigazone:
Percorso: <a href=”../info.jsp”>Home</a> &gt; <a
href="../fsclin.jsp"> Fascicolo Clinico </a> &gt; Anamnesi
13.6 Raggruppare i collegamenti correlati, identificare i gruppi
(per i programmi utente) e, fino a quando i programmi utente
non lo consentiranno, fornire un modo per saltare il gruppo.
È sempre bene posizionare il menu di navigazione all'inizio del codice
all'interno della nostra pagina web, magari inserendo anche una barra di
navigazione come indicato nel punto di controllo 13.5. Però così facendo
accade che gli utenti non vedenti che utilizzano i lettori di schermo
solitamente si spostano all'interno di una pagina saltando da
collegamento a collegamento: questo accadrebbe per ogni pagina visitata
se non venisse offerta la possibilità di saltare direttamente al contenuto.
Se i collegamenti sono raggruppati secondo una logica (per esempio, le
barre di navigazione) è possibile definire un collegamento ipertestuale
che ne consenta il superamento: questo significa offrire la possibilità
126
anche agli utenti non vedenti di saltare la lettura di una parte del testo,
così come qualsiasi utente vedente farebbe nel caso di ripetizione di testi.
Considerando che spesso la prima voce interna a una pagina Web
riguarda proprio la barra di navigazione, se raggruppiamo questi
collegamenti in una unità logica alcune tecnologie assistive consentono di
saltare direttamente il blocco. Per le tecnologie assistive che invece non
consentono tale possibilità, è necessario definire un collegamento che
permetta di saltare a un'altra area del contenuto. Nell'esempio seguente i
collegamenti vengono raggruppati nell'elemento <map> e la prima
opzione consente di saltare direttamente all'inizio del contenuto.
Listato 32: esempio di raggruppamento di collegamenti.
<map title="Barra di Navigazione" id="BarNav"> <p> [<a
href="#contenuto" tabindex="1" accesskey="1">Passa al Contenuto</a>]
<a href="../info.jsp" tabindex="2" accesskey="2">Home</a> &gt; <a
href="../fsclin.jsp" tabindex="3" accesskey="3">Fascicolo clinico</a>
&gt; Allergie</p> </map> <a name="contenuto"></a>
È inoltre possibile utilizzare i fogli di stile per nascondere questo
collegamento in modo che sia fruibile esclusivamente dai lettori di
schermo.
Listato 33: definizione di una classe per nascondere il collegamento.
<div class="nascosto"> <a href="#contenuto">vai direttamente al
contenuto</a> </div>
È sufficiente inserire la seguente classe nel foglio di stile, in modo da
rendere subito operativo il codice sopra riportato rendendolo quindi
"visibile" agli utenti che navigano con sistemi di lettura dello schermo.
Listato 34: rispettivo CSS per il listato 33.
div.nascosto { display: none; }
13.7 Se sono fornite funzionalità di ricerca, rendere possibili
diversi tipi di ricerca per differenti livelli di abilità e per preferenze
differenti.
Questo punto di controllo non obbliga lo sviluppatore ad inserire all'interno
di un sito Web un motore di ricerca ma fornisce delle indicazioni su come
127
dovrebbe esser definita la procedura di ricerca e di visualizzazione dei
risultati.
È altresì necessario definire una pagina dedicata alla ricerca all'interno
del sito Web che spieghi le modalità con cui viene effettuata la ricerca.
È possibile inoltre fornire delle ulteriori opzioni avanzate per semplificare
la ricerca, utilizzando gli operatori AND, OR, EXCLUDE per ricercare
rispettivamente tutte le parole indicate, una delle parole indicate o tutte le
parole escluse quelle indicate nel modulo di ricerca.
Il sito dell'Assistente Personale fornisce un motore di ricerca interno ma in
esso non sono ancora incluse le funzionalità sopra citate.
Figura 4.31: motore di ricerca interno all'Assistente Personale
13.8 Posizionare l'informazione più significativa all'inizio delle
intestazioni, dei paragrafi, delle liste, ecc.
Gli utenti preferiscono allineamenti compatibili in tutte le pagine web per
elementi come di testo, righe, colonne, pulsanti di scelta, campi di
immissione dati, ecc.
Si deve determinare, all’inizio, se c'è un ordine per gli elementi che
128
possano agevolare l’utilizzo del sito. Se c’è, bisogna utilizzare quell'ordine
in tutte le pagine del sito (ad esempio liste organizzate numericamente o
alfabeticamente). Dove non si applica alcun ordine evidente, organizzare
le liste ad esempio con pallini. Un formato di lista ben organizzato tende
ad agevolare la scansione rendendola rapida e precisa. Uno studio ha
indicato che gli utenti scandiscono le liste verticali più rapidamente delle
liste orizzontali. Scandire una lista orizzontale fa impiegare agli utenti il
20% di tempo in più rispetto ad una lista verticale.
Fornire un'intestazione descrittiva, all’inizio di ogni lista, permette agli
utenti di capire che tipo di elementi ci saranno in quella lista. Gli utenti,
infatti, utilizzano meglio le liste quando queste includono intestazioni.
L'utilizzo anche di etichette significative, di colori di sfondo, margini e
spazi bianchi, permettono di identificare un insieme di elementi come una
lista separata.
Solo la prima lettera della prima parola dovrebbe essere scritta in
maiuscolo a meno che l'elemento non contenga un'altra parola che
sarebbe normalmente scritta con lettera maiuscola (es. nome proprio).
Le liste di punti funzionano meglio quando gli elementi non contengono
una sequenza, un ordine. Le liste numerate assegnano a ogni elemento
della lista un numero ascendente. Le liste numerate sono particolarmente
importanti quando si danno istruzioni.
Sul sito dell’assistente personale le liste non rispettavano la direttiva.
Anche qui è stato fatto un lavoro di modifica e visto che l’ordine degli
elementi, in tutti i casi, non era stabilito, non sono state usate liste
numeriche, alfabetiche, ma semplicemente delle strutture a blocchi con le
voci separate da linee orizzontali. Inoltre la prima lettera di ogni voce è
stata scritta in maiuscolo.
129
Figura 4.32: Esempio di liste raggruppate
13.9 Fornire informazioni sulle raccolte di documenti, ossia
documenti composti da più pagine.
Gli sviluppatori dovrebbero utilizzare l'elemento <link> per descrivere le
modalità di navigazione e l'organizzazione di un documento. Utilizzando
l'attributo rel per l'elemento <link>, per esempio con Netscape, Mozilla e
Opera, è possibile ottenere un barra di navigazione con i collegamenti
indicati dall'attributo rel.
In Arianna i contenuti che erano divise in più pagine erano sezioni
riguardanti l'inserimento di dati (registrazione, anamnesi). In questi casi è
stato necessario muoversi avanti e/o indietro nelle varie form o tramite
l'invio dei dati con il bottone di “conferma” o “Prosegui” oppure tornare
indietro utilizzando il menù di navigazione.
130
Figura 4.33: uso dei pulsanti per navigare tra pagine dello stesso documento
Linea guida 14: garantire che i documenti siano chiari e semplici
14.1 Utilizzare un linguaggio più chiaro e semplice possibile che
sia adatto al contenuto del sito.
Quando si sviluppa un sito Web o quando ci si occupa della gestione dei
contenuti (content manager) è necessario utilizzare un linguaggio
appropriato al tipo di contenuti in modo che possa essere accessibile alle
persone con disabilità cognitive o con problemi dovuti alla lettura.
Le etichette, i link, il testo, devono essere chiaramente descrittivi della
loro funzione o della loro destinazione e devono riflettere chiaramente le
informazioni e gli elementi contenuti nella categoria. Utilizzare parole di
uso frequente e spesso sentite. Non utilizzare parole che è possibile che
gli utenti non capiscano.
Agli utenti piacciono etichette abbastanza descrittive. I titoli delle
131
categorie devono essere capiti dagli utenti che invece troveranno difficoltà
a capire le etichette di collegamento vaghe e generalizzate. Utilizzare
intestazioni povere che possono provocare incongruenze tra quello che
gli utenti si aspettavano e quello che realmente trovano, è un problema
comune nei siti web. Se le intestazioni sono troppo simili le une dalle
altre, è possibile che gli utenti debbano sforzarsi a rileggerle per
decifrarne la differenza. E’ consigliato utilizzare parole familiari e di
frequente utilizzo per consentire un veloce riconoscimento. Le parole
familiari possono essere raccolte utilizzando indagini o visualizzando i
termini di ricerca immessi dagli utenti sul sito.
La terminologia ha un grande ruolo nella capacità dell'utente di trovare e
capire le informazioni. Molti termini sono familiari per progettisti e scrittori,
ma non per gli utenti. Per migliorare la comprensione tra gli utenti che
sono abituati all'utilizzo del termine gergale, può essere utile mettere quel
termine tra parentesi. Un dizionario o un glossario può essere utile per gli
utenti che non conoscono un determinato argomento, ma comunque
questo uso non dovrebbe essere considerato un’abitudine.
In generale la terminologia utilizzata deve esser comprensibile al target di
pubblico a cui si rivolge il sito. Siccome il sito dell’assistente personale si
rivolge ad un target di utenti molto vario, nel sito dell'Assistente
Personale si è deciso di utilizzare una terminologia molto semplice in
modo tale che tutti possano chiaramente comprendere qualsiasi aspetto
del sito.
132
Figura 4.34: esempio di uso di termini comprensibili
14.2 Integrare il testo con presentazioni visive o audio nei casi in
cui possano facilitare la comprensione della pagina.
Per rendere comprensibile un messaggio al maggior numero possibile di
utenti è necessario utilizzare immagini, suoni e testi in modo
complementare: una fotografia può sostituire centinaia di parole, così
come un suono può consentire di risparmiare tempo di lettura. Immagini,
animazioni e filmati vengono utilizzati dagli utenti che preferiscono i
contenuti di tipo visuale o da utenti con disabilità cognitive. Un filmato può
essere fruito da utenti normodotati, non udenti e non vedenti: in questi
due ultimi casi la fruibilità è possibile se si utilizzano linguaggi per il
captioning (come per SMIL). Nel caso invece di contenuti né testuali né
visuali, come la musica, interventi verbali o effetti speciali questi
risulteranno ottimali per gli utenti non vedenti, mentre per gli utenti non
udenti sarà necessario fornire un equivalente di tipo testuale: per una
canzone sarà possibile rendere disponibile il testo, così come per un
intervento verbale (un convegno, ecc.). In entrambi i casi il problema
maggiore è dato dagli eventi in tempo reale, che raramente possono
essere riportati in contemporanea con una versione alternativa.
133
14.3 Creare uno stile di presentazione coerente fra le pagine.
In un sito web va creato uno schema di navigazione comune agli utenti,
per aiutarli ad apprenderne e capirne la struttura. Va quindi utilizzato lo
stesso schema di navigazione in tutte le pagine per quanto riguarda
intestazioni, liste, ricerca, mappa di posizione, pulsanti. Degli studi hanno
dimostrato che il numero di errori fatti utilizzando schemi visivamente
incompatibili è più alto rispetto all’utilizzo di schemi visivamente
compatibili. La compatibilità visiva include la dimensione e il numero di
caratteri, i colori utilizzati per etichette, font e sfondo, le ubicazioni di
etichette, testo immagini, pulsanti. Gli studi precedenti hanno trovato che
le attività eseguite con l’utilizzo di schemi compatibili portavano ad una
riduzione dei tempi di completamento dell’attività, alla riduzione degli
errori, ad un aumento della soddisfazione dell’utente e ad una riduzione
del tempo di apprendimento.
Sul sito dell’assistente personale mancava l’omogeneità tra le pagine. Si
è provveduto quindi a sistemare questo problema usando tra le pagine
uno schema coerente. Il percorso di navigazione è stato inserito in alto a
sinistra in tutte le pagine, il titolo sempre sotto il percorso di navigazione, i
pulsanti “suggerimenti” e “torna indietro”, ad esempio, sempre nella
stessa posizione, così come il link con la versione stampabile, ecc…
134
Figura 4.35 : esempio di identica disposizione degli stessi elementi in due pagine diverse del
sito
135
CAPITOLO 5 – SVILUPPI FUTURI :
ACCESSIBILTA' E WEB 2.0
5.1 Introduzione
Si parla molto in questo ultimo periodo di Web 2.0, non si tratta di un
nuovo protocollo, di una release di un software, ma di un termine
utilizzato per descrivere un nuovo modo di intendere e di utilizzare la rete
grazie allo sviluppo di una molteplicità di applicazioni che sono già state
lanciate e che lo saranno nei prossimi mesi e che contribuiranno a
modificare la morfologia della rete.
L’avvento del Web 2.0, dei contenuti generati dagli utenti e l’incremento
nell’utilizzo di tecnologie come PDF e Flash hanno portato all’attenzione
nuove questioni riguardo l’usabilità e l'accessibilità web.
Le nuove linee guida del W3C sull'acessibiltà (WCAG 2.0) saranno
d’aiuto?
Sono passati più di sette anni da quando il W3C ha rilasciato la prima
versione definitiva delle linee guida sull'accessibilità (WCAG .10). Da quel
momento, l’accessibilità web è divenuta sempre più importante per i web
manager delle organizzazioni più importanti.
Ormai l'accessibilità è un criterio base nella progettazione e realizzazione
di servizi web rivolti a una vasta utenza. Per questo motivo sempre più siti
di alto profilo offrono una migliore accessibilità rispetto agli anni
precedenti. C’è ancora molta strada da fare ma il progresso è evidente.
Quando si parla di Web 2.0 ci si riferisce alla ‘nuova generazione’ di siti,
tecnologie ed applicazioni online che si stanno diffondendo a macchia
d’olio su Internet.
136
5.2 caratteristiche principali del web 2.0
Due sono le caratteristiche del Web 2.0: la tecnologia AJAX, il contenuto
generato dall’utente, e le nuove linee guida del W3C sull'accessibilità
(WCAG 2.0) che sono in via di rilascio.
5.2.1 AJAX
AJAX, o Asynchronous JavaScript e XML non è una vera e propria
tecnologia di per sé, ma un insieme di tecniche già esistenti che creano
applicazioni web altamente interattive.
Le pagine web basate su AJAX richiedono il supporto di JavaScript,
condizione già supportata dalla maggior parte delle tecnologie assistive
odierne. A tal riguardo i problemi relativi all’accessibilità non riguardano
l’uso del JavaScript di per sé, ma il modo in cui il JavaScript viene usato
per effettuare cambiamenti sulla pagina.
La funzionalità Amazon diamond search
(http://www.amazon.com/gp/gsl/search/finder/104-80207417498364?ie=UTF8&productGroupID=loose%5Fdiamonds) per esempio,
mostra come si possa usare AJAX per creare un’interfaccia utile ed
interattiva, il cui obiettivo è filtrare dati sulla base di criteri pre-selezionati.
L’ applicazione di Amazon è un esempio di usabilità di alto livello, ma
tuttavia non è utilizzabile da coloro che usano uno screen reader o la
tastiera ed è poco utilizzabile da chi utilizza un ingranditore di schermo.
La soluzione ?: una versione accessibile separata che Amazon ha
puntualmente fornito (anche se tale applicazione non è costruita per
essere davvero accessibile al 100%).
5.2.2 Contenuto generato dall’utente
Un secondo concetto legato al Web 2.0 è il contenuto generato
dall'utente. Blog e wiki stanno divenendo sempre più un luogo comune
all’interno delle organizzazioni che tuttavia non si interessano ancora a
137
fondo delle questioni legate all’accessibilità.
Siti come Blogger (https://www.blogger.com/), Flickr (http://flickr.com/) e
YouTube (http://www.youtube.com) si basano totalmente sui contenuti
generati dall'utente, rispettivamente in forma di blog, foto e video.
Come possono questi siti controllare l'accessibilità dei contenuti che
vengono creati minuto per minuto?
Siti di photo sharing, come Flickr, potrebbero richiedere agli utenti di
inserire descrizioni alternative alle foto, anche se controllare tutto questo
non sarebbe possibile.
E per quanto riguarda i siti delle grandi organizzazioni, i proprietari di tali
siti saranno in grado di assicurare che il contenuto venga prodotto
secondo criteri di accessibilità?
5.2.3 WCAG 2.0
La seconda versione delle linee guida sull’accessibilità (WCAG) del W3C
sta per essere rilasciata ufficialmente.
Per i dettagli a questa nuova versione, ancora in via di definizione
rimandiamo al capitolo 2
5.3 Possibili scenari futuri
I tre fattori che abbiamo appena trattato sono le principali variabili che
influenzeranno l'evoluzione dell’accessibilità web del futuro. Un possibile
scenario riguardo ad un nuovo approccio all'accessibilità potrebbe portare
alle seguenti conseguenze:
1. L’Accessibilità verrà sempre meno condizionata da linee guida
Con l’avvento di nuove tecnologie (come AJAX), e nello stesso
tempo dell’idea di neutralità della tecnologia delle nuove linee guida
del W3C, l’accessibilità sarà sempre meno condizionata da criteri
guida. Questo significa che da un lato gli esperti di accessibilità
diventeranno sempre più importanti nelle organizzazioni, dall’altro
che l’interpretazione delle linee guida sarà sempre più difficoltosa.
138
2. Versioni accessibili alternative diverranno la norma
Storicamente, ci si è sempre opposti sia per ragioni etiche che di
business alle doppie versioni, vale a dire avere di uno stesso sito sia
una versione “grafica” che “testuale”.
Ma attualmente, dal momento che usabilità e accessibilità vengono
a scontrarsi sempre più grazie alla creazione di interfacce sempre
più interattive, diviene necessario creare versioni separate
(naturalmente dopo aver provato ogni tentativo di integrazione).
3. Probabilmente il contenuto generato dall’utente offre poca
accessibilità
Il contenuto creato dall'utente sta divenendo sempre più un luogo
comune sul web ma viene creato ad una tale velocità che diviene
impossibile creare dei requisiti di accessibilità.
4. JavaScript, PDF & Flash non saranno più tecnologie da evitare a
priori. Nel WCAG 1.0, i manager web e gli sviluppatori non si
affidavano a queste tecnologie. Ma le WCAG, lasciano spazio
all’interpretazione ed ora molte tecnologie assistive possono
supportare JavaScript, PDF e Flash.
139
BIBLIOGRAFIA – SITOGRAFIA
–
Roberto Scano, Accessibilità: dalla teoria alla realtà, 2005
–
G. Troiani, “CSS Guida completa”, 2005
–
Michele Diodati, Diodati.org, Accessibilità e traduzioni dal W3C
http://www.diodati.org/
–
http://www.w3.org/ , W3C Consortium
–
Cristiano Tonelli, Accessibilità e siti web: nuove normative e
metodologie di controllo, 2005
–
Giacomo Mazzocato, ruota dei colori accessibili
http://gmazzocato.altervista.org/colorwheel/wheel.php?lingua=it
–
Validatore HTML, http://validator.w3.org/
–
Validatore CSS, http://jigsaw.w3.org/css-validator/
–
Web accessibile, www.webaccessibile.org
140
