UNIVERSITÀ POLITECNICA DELLE MARCHE
FACOLTÀ DI INGEGNERIA
SEDE DI ANCONA
NORMATIVE, METODOLOGIE E TECNICHE PROGETTUALI
PER LA REALIZZAZIONE DI SITI
WEB AD ELEVATA
ACCESSIBILITÀ.
TESI DI LAUREA TRIENNALE IN INGEGNERIA INFORMATICA ED AUTOMATICA.
AUTORE
RELATORE
ANGELO MORESCHI
PROF. ING. ALDO FRANCO DRAGONI
REVISIONE 1.0 - MARZO 2007
A mia madre,
a mio padre.
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.
SOMMARIO
I.
Introduzione ............................................................................................ 1
II.
Scenario................................................................................................ 3
II.1 - Per una cultura dell’accessibilità ............................................................... 3
II.2 - Il concetto di accessibilità ........................................................................ 7
Beneficiari dell’accessibilità ...................................................................................... 8
Gli obiettivi dell’accessibilità ..................................................................................... 9
II.3 - Usabilità .............................................................................................. 12
Presentazione ....................................................................................................... 12
Accessibilità ed Usabilità ........................................................................................ 14
Normative ............................................................................................................ 16
II.4 - La disabilità ......................................................................................... 18
Definizione WHO ................................................................................................... 18
Disabilità in cifre ................................................................................................... 19
Tipologie della disabilità ......................................................................................... 20
II.5 - Il W3C ................................................................................................ 26
Gli obiettivi .......................................................................................................... 27
Le Raccomandazioni .............................................................................................. 27
La WAI ................................................................................................................ 29
III.
Metodologie e tecniche di applicazione ............................................... 32
III.1 - Il linguaggio ....................................................................................... 32
HTML .................................................................................................................. 33
XHTML................................................................................................................. 43
CSS .................................................................................................................... 47
III.2 - L’accessibilità in 10 punti ...................................................................... 54
Suggerimenti rapidi. .............................................................................................. 54
Commento ........................................................................................................... 55
Circolare Bassanini ................................................................................................ 59
III.3 - Componenti essenziali dell’accessibilità .................................................. 61
Separazione tra contenuto e presentazione .............................................................. 63
Fogli di stile (CSS) ................................................................................................ 67
Utilizzo degli elementi strutturali ............................................................................. 77
Rispetto dell’aspetto semantico .............................................................................. 85
Il principio della multi-modalità .............................................................................. 87
- IV -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.
III.4 - Indipendenza dal dispositivo di presentazione ......................................... 88
III.5 - Trattamento delle immagini .................................................................. 91
Strumenti del linguaggio ........................................................................................ 91
Testi alternativi .................................................................................................... 95
Tipologie di immagini ............................................................................................ 98
Annotazioni conclusive ......................................................................................... 100
Ascii Art .............................................................................................................. 101
III.6 - Uso del colore ................................................................................... 102
Principi fisici ........................................................................................................ 103
Criteri di realizzazione .......................................................................................... 106
III.7 - Impaginazione e tabelle ..................................................................... 116
Uso delle tabelle .................................................................................................. 116
Tabelle dati ......................................................................................................... 117
Tabelle di impaginazione ....................................................................................... 120
Impaginazione ..................................................................................................... 125
III.8 - Contenuti multimediali ....................................................................... 129
Metodologie ........................................................................................................ 131
Tecniche e strumenti ............................................................................................ 135
Conclusioni ......................................................................................................... 139
III.9 - Tecniche specifiche ............................................................................ 140
Apertura nuove finestre ........................................................................................ 140
Auto aggiornamenti.............................................................................................. 141
Collegamenti ipertestuali ...................................................................................... 142
Grammatiche formali ............................................................................................ 144
Fogli di stile secondari .......................................................................................... 146
Fotosensibilità ..................................................................................................... 149
Frameset ............................................................................................................ 150
Linguaggi per rappresentazioni specifiche ............................................................... 153
Mappe immagine ................................................................................................. 159
Moduli ................................................................................................................ 162
Navigazione ........................................................................................................ 169
III.10 - Web dinamico ................................................................................. 179
Script ................................................................................................................. 181
Applet e plug-in ................................................................................................... 186
AJAX .................................................................................................................. 187
III.11 - Comprensibilità dei contenuti ............................................................ 189
Scrivere per farsi capire ........................................................................................ 190
-V-
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.
Suggerimenti in (X)HTML ...................................................................................... 193
Pubblica Amministrazione ..................................................................................... 196
III.12 - Riadattamento a posteriori................................................................ 198
III.13 - Compatibilità con le tecnologie obsolete ............................................. 200
Retro-compatiblità ............................................................................................... 201
Aderenza agli standard ......................................................................................... 202
III.14 - Validazione e controllo ..................................................................... 204
Metodologia di verifica .......................................................................................... 204
Validatori automatici ............................................................................................ 208
La cultura del bollino ............................................................................................ 215
III.15 - I costi dell’accessibilità ..................................................................... 216
L’accessibilità come punto di partenza .................................................................... 218
Costo zero .......................................................................................................... 218
IV.
Analisi delle normative ..................................................................... 220
IV.1 - Normative internazionali ..................................................................... 220
IV.2 - WCAG 1.0 ......................................................................................... 223
Introduzione ....................................................................................................... 223
Organizzazione e conformità ................................................................................. 224
Linee guida e punti di controllo .............................................................................. 226
Critiche ed attuazione ........................................................................................... 238
IV.3 - Section 508....................................................................................... 242
Linee guida per le pagine Web ............................................................................... 243
Relazione con le direttive WAI ............................................................................... 248
Relazione con la legge italiana ............................................................................... 250
IV.4 - Legge Stanca .................................................................................... 252
Decreto legislativo 216/2003 ................................................................................. 254
Legge 04/2004 .................................................................................................... 255
Codice della Pubblica Amministrazione Digitale ........................................................ 262
Regolamento di attuazione .................................................................................... 263
Requisiti tecnici (Decreto Ministeriale 8 Luglio 2005) ................................................ 267
Valutazione requisiti Internet ................................................................................ 287
Verifica soggettiva ............................................................................................... 289
Comparazione con la Section 508 .......................................................................... 289
Secondo disegno di legge Campa Palmieri ............................................................... 293
Stato di attuazione ............................................................................................... 294
IV.5 - WCAG 2.0 ......................................................................................... 295
- VI -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.
Presentazione ...................................................................................................... 295
Organizzazione .................................................................................................... 303
Normativa ........................................................................................................... 306
Mappatura WCAG 1.0 e 2.0 ................................................................................... 309
Critiche............................................................................................................... 312
Relazione con il DM 8 Luglio 2005 .......................................................................... 319
IV.6 - Quadro sinottico ................................................................................ 320
IV.7 - ISO .................................................................................................. 325
Normative ........................................................................................................... 325
IV.8 - UAAG ............................................................................................... 327
IV.9 - ATAG ............................................................................................... 330
Versione 2.0........................................................................................................ 331
Contenuti ............................................................................................................ 333
Conformità .......................................................................................................... 334
IV.10 - ARIA .............................................................................................. 336
Web dinamico accessibile ...................................................................................... 337
Schema del progetto ............................................................................................ 337
V.
L’accessibilità nella realtà ................................................................. 340
V.1 - Ausili informatici per i disabili ............................................................... 340
Strumenti per i non vedenti .................................................................................. 340
Strumenti per ipovedenti ...................................................................................... 343
Accorgimenti per audiolesi .................................................................................... 344
Strumenti per le disabilità motorie ......................................................................... 345
Gli strumenti per le disabilità cognitive. .................................................................. 346
Conclusioni ......................................................................................................... 347
V.2 - Programmi utente ............................................................................... 348
Screen-reader ..................................................................................................... 348
V.3 - Strumenti di sviluppo .......................................................................... 353
CMS ................................................................................................................... 354
V.4 - L’accessibilità nei sistemi operativi ........................................................ 360
Microsoft Windows ............................................................................................... 361
Linux .................................................................................................................. 369
Apple MAC OS X .................................................................................................. 371
DOS ................................................................................................................... 373
V.5 - Applicativi e formati proprietari ............................................................. 375
Microsoft Word .................................................................................................... 377
- VII -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.
Adobe PDF .......................................................................................................... 379
Adobe Flash ........................................................................................................ 385
V.6 - Interviste ........................................................................................... 389
Paolo de Cecco .................................................................................................... 389
VI.
Un esempio reale .............................................................................. 402
VI.1 - Presentazione in XHTML...................................................................... 402
Progetto ............................................................................................................. 403
Codice XHTML ..................................................................................................... 403
Codice CSS ......................................................................................................... 409
VII.
Appendice – Riferimenti alle normative ......................................... 414
VII.1 - WCAG 1.0 ........................................................................................ 414
Abstract.............................................................................................................. 414
Introduction ........................................................................................................ 415
Themes of Accessible Design ................................................................................. 417
How the Guidelines are Organized .......................................................................... 418
Priorities ............................................................................................................. 418
Conformance ....................................................................................................... 419
Web Content Accessibility Guidelines ...................................................................... 419
VII.2 - Section 508 ..................................................................................... 432
Table of Contents................................................................................................. 432
Subpart A -- General ............................................................................................ 432
Subpart B -- Technical Standards ........................................................................... 435
Subpart C -- Functional Performance Criteria ........................................................... 438
Subpart D -- Information, Documentation, and Support ............................................ 439
VII.3 - Legge Stanca ................................................................................... 440
Legge n. 4 del 9 gennaio 2004 .............................................................................. 440
Regolamento di attuazione della legge 9 gennaio 2004, n. 4 ..................................... 444
Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici. ............... 445
Requisiti tecnici - Allegato A .................................................................................. 450
Requisiti tecnici - Allegato B .................................................................................. 456
VII.4 - WCAG 2.0 ........................................................................................ 459
Abstract.............................................................................................................. 459
Introduction ........................................................................................................ 460
Conformance ....................................................................................................... 462
WCAG 2.0 Guidelines ........................................................................................... 465
- VIII -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.
VIII.
Glossario........................................................................................ 472
VIII.1 - Glossario generale ........................................................................... 472
VIII.2 - Glossario WCAG 1.0 ......................................................................... 478
IX.
Riferimenti ........................................................................................ 485
IX.1 - Bibliografia........................................................................................ 485
IX.2 - Link Utili ........................................................................................... 485
- IX -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.
-X-
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
I. Introduzione
Viviamo in una società basata sull’informazione e la conoscenza. In quest’età, successiva a
quella industriale, l’informazione è sempre più un bisogno primario e la tecnologia, dal
computer ai chioschi informativi, dai messaggi di posta elettronica alla ADSL, è sempre di più il
mezzo per trasmettere, conservare e creare l’informazione. L’accesso alla tecnologia
dell’informazione rappresenta perciò sempre più un’opportunità di conoscenza, istruzione e
lavoro e acquisisce sempre maggior importanza nel modo di vivere, di lavorare e di
apprendere. Si può in qualche modo equiparare l’accesso alle tecnologie ed il loro pieno utilizzo
ad un diritto primario per tutti i cittadini, nessuno escluso. 1
La scelta di questo argomento per la tesi in Ingegneria Informatica ed Automatica è dovuta
all’interesse ed alle funzionalità sempre maggiori ricoperte dai servizi Web nel mondo attuale.
La mole di informazioni veicolate a questo moderno strumento informativo meritano che esso
venga reso accessibile ed usabile per quanti più fruitori possibili.
Il pubblico dominio dell’informazione ha come necessaria premessa la sua accessibilità, questa
fa parte della natura intrinseca di internet e del Web la cui potenzialità è proprio quella di
fornire a tutti le informazioni depositate.
A questo proposito risulta illuminante il motto del W3C, il principale ente preposto alla guida
dello sviluppo del Web di cui parleremo diffusamente in seguito. E’ un pensiero di Tim BernersLee, attuale direttore del W3C e padre del Web.
Il motto, tradotto in italiano, recita: "La forza del Web sta nella sua universalità. L'accesso da
parte di chiunque, indipendentemente dalle disabilità, ne è un aspetto essenziale" 2.
Questo lavoro ha, quindi, come finalità quella di esporre le metodologie
dell'accessibilità e fornire al lettore gli strumenti tecnici e culturali adatti per
progettare e realizzare siti Web ad elevata accessibilità.
Nella esposizione sono stati parzialmente tralasciati gli aspetti squisitamente tecnici ed
operativi se non necessari per la trattazione, una impostazione eccessivamente puntuale esula
infatti dagli scopi questo compendio e può venire più efficacemente acquisita da studi e da siti
più specifici.
1
Tecnologie per la disabilità: Libro bianco. Introduzione. [http://www.innovazione.gov.it/librobianco/]
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential
aspect” - [http://www.w3.org/WAI/]
2
-1-
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Data la natura compilativa della tesi sono stati riportati per intero molti pensieri di autori che
ho trovato particolarmente illuminanti durante la stesura.
Spesso ho ritenuto opportuno citare per intero il testo originale, o tradurlo nella maniera più
fedele possibile, soprattutto quando il concetto era stato già espresso in maniera efficace e
sintetica.
Ovviamente non è mai stata mia intenzione appropriarmi delle idee e delle ricerche di altri.
Tutti gli stralci sono corredati dalle opportune citazioni in nota. Per non appesantire la lettura,
tuttavia, ho scelto di non virgolettare i concetti più lunghi, limitandomi a rientrarne il principio
del paragrafo e riportando alla fine una nota di rimando a piè pagina.
Per quanto riguarda l’esposizione della materia, ho deciso di organizzarla in pochi capitoli
fondamentali:
Scenario: presentazione degli elementi fondamentali della materia e delle
problematiche attinenti;
Metodologie e tecniche di applicazione: panoramica della metodologia generale e delle
tecniche comuni di buona programmazione per siti Web alla base di tutte le normative
seguenti;
Analisi delle normative: analisi delle 4 normative fondamentali che sono considerate in
questo momento come le più rilevanti in tema di accessibilità. In appendice sono
riportati degli stralci essenziali;
L’accessibilità nella realtà: un inquadramento del problema dal punto di vista dei fruitori
dei servizi;
Un esempio reale: una applicazione pratica in XHTML e CSS dei concetti esposti.
Prima di iniziare la trattazione vorrei ricordare i miei genitori che mi sono stati sempre
d’incitamento e di sprone nel portare a termine il mio corso di studi. Per questo e per molto
altro ancora, a loro va il mio continuo ringraziamento.
-2-
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
II. Scenario
Il primo capitolo di questa trattazione presenta una panoramica dell’argomento.
Molte delle problematiche dovute alla crescita disorganica del Web, prassi comune fino a
qualche hanno fa, hanno fatto nascere con urgenza le motivazioni che portano allo studio e alla
considerazione dell’accessibilità.
Con questo sguardo d’insieme si vuole introdurre l’argomento di studio.
E’ un capitolo preliminare per arrivare nella parte successiva alla disamina delle metodologie
universalmente riconosciute per la migliore prassi in materia.
II.1 - Per una cultura dell’accessibilità
Il 2003 è stato l’Anno europeo delle persone con disabilità.
Per quanto riguarda l'uso di Internet e in particolare del Web, ciò ha significato
un'attenzione maggiore rivolta ai problemi che i disabili incontrano quotidianamente nel
tentativo di utilizzare informazioni e servizi presenti in rete. 1
Preoccuparsi di rendere fruibile il contenuto di Internet dal punto di vista di queste categorie di
utenti svantaggiati significa preoccuparsi di renderlo accessibile. Vale la pena ricordare a
proposito, come affermato da Luca Mascaro in una conferenza dell’IWA 2, che il Web nasce in
realtà accessibile, solo in seguito, soprattutto con il cattivo utilizzo degli elementi di
impaginazione questo importante aspetto si è andato perdendo.
Sino a qualche anno fa l’accessibilità era considerata un argomento di nicchia, un qualcosa
utilizzato dai puristi del codice che non comprendevano le potenzialità grafiche offerte dalla
rete. Grazie però a diverse iniziative, molte delle quali promosse in Italia dall'associazione IWA
Italy (International Webmaster Association), si è cercato di creare una cultura
dell'accessibilità e molti autori di pagine Web 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.
Nel Gennaio 2004, proprio sulla scorta di questa filosofia (“Disposizioni per favorire l'accesso
dei soggetti disabili agli strumenti informatici” recita, infatti, il suo titolo), in Italia è stata
concepita la Legge 04/2004, presentata dall’allora Ministro per l'innovazione tecnologica Lucio
Stanca.
1
2
Roberto Scano: “Accessibilità, dalla teoria alla realtà”, capitolo 1
Roberto Ellero, Luca Mascaro - Seminario IWA/IWG – Arese, Maggio 2005
-3-
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Una normativa che si prefigge l'obiettivo di rendere obbligatorio il rispetto delle regole di
accessibilità quanto meno da parte di tutti i siti che appartengano alla Pubblica
Amministrazione o che svolgano un servizio pubblico.
Con questa normativa diventa indispensabile, per gli sviluppatori e gli editori di contenuti
che dovranno applicare questa legge nel loro lavoro quotidiano, acquisire le competenze
necessarie a rispettare le regole che essa stabilisce. 1
Il campo di applicazione è sostanzialmente rivolto alle Amministrazioni Pubbliche, ma il
concetto base è volto ad orientare gli sviluppatori verso quello che potremmo definire un
metodo di buon sviluppo: un modo di realizzare pagine Web e siti, basato sul rispetto dei
linguaggi standard del W3C e delle linee guida sull'accessibilità.
Un buon sviluppo si contrappone alla prassi diffusa di un cattivo sviluppo, che è il modo
tradizionale di procedere fondato sull'uso puro e semplice degli editor visuali, sull'ignoranza del
codice che vi sta dietro e sulla creazione di vincoli di presentazione inutili, che impediscono
l'accesso ai contenuti a numerose categorie di utenti.
Occorre ripensare dalle basi il modo di progettare la realizzazione di siti e pagine Web: la
ricerca dell'accessibilità non deve intervenire alla fine, per tentare di mettere rattoppi
alle falle create dal cattivo sviluppo; deve essere, invece, un obiettivo della progettazione.
Una pagina nata male può essere resa in qualche modo accessibile, nel peggiore dei casi
creando un documento alternativo più navigabile. Non sarà mai però una pagina ad elevata
accessibilità e richiederà sempre una gran quantità di lavoro, ogni volta che sarà necessario
aggiornare la veste grafica del sito o introdurre qualche cambiamento relativo all'accessibilità
dei contenuti.
Perseverare nel cattivo sviluppo non è perciò una scelta conveniente 2. Se i gestori di siti che
rientreranno nell'ambito di applicazione della legge attuale vorranno rispettare le
raccomandazioni di accessibilità e, allo stesso tempo, trovare un sistema di lavoro efficace ed
economico, non potranno che indirizzarsi verso queste regole.
Un sito ad elevata accessibilità non è altro che un sito pensato e costruito secondo le regole del
buon sviluppo: è una struttura progettata secondo i migliori criteri di stabilità e di funzionalità.
Quindi, scopo di questa e di molte altre trattazioni propedeutiche in materia è di creare una
vera e propria cultura negli sviluppatori, qualcosa che arricchisca il bagaglio culturale e
1
Michele Diodati: “Guida all’accessibilità dei siti Web”
“Attuare le linee guida sull'accessibilità comporta, e oltretutto solo nella fase iniziale, costi non di molto
superiori a quelli che conseguirebbero alla loro mancata attuazione”- Documento economico correlato alla
Comunicazione CE del 25 Settembre 2001.
2
-4-
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
tecnologico di chi progetta siti e induca a considerare una programmazione accessibile come
l’unico modo di realizzare delle pagine Web.
Si tratta di fare proprio un metodo di lavoro ed una competenza in materia, allo stesso modo
con cui si sono appresi i rudimenti della programmazione in (X)HTML, aggiungendo di passo in
passo nuova conoscenza: dalle basi a JavaScript, dalla gestione dei moduli alle interrogazioni
delle basi di dati.
L’accessibilità è semplicemente la successiva competenza da acquisire. 1
Per di più, non corrisponde per nulla al vero il fatto che questa tecnica vada a scapito di una
gradevole presentazione visuale dei siti.
A tal proposito vorrei ricordare alcune fondamentali considerazioni di uno dei maggiori esperti
in materia, Joe Clark. Nel suo testo fondamentale sull’accessibilità l’autore ha premesso alla
trattazione un’interessante lista di miti da sfatare. Ne riporto una sintesi essenziale e tradotta.
Per la versione originale e completa ci si può riferire al testo citato in bibliografia. Mi si voglia
perdonare l’approssimativa traduzione.
L’accessibilità è debolmente compresa, e circondata una vasta gamma di luoghi comuni 2:
L’accessibilità è costosa (“Access is expensive”):
Lo è, per un sito vasto e se viene applicata in un secondo momento. Adattare a
posteriori costa sempre molto. In tutti gli altri casi può costare ma non è
necessariamente dispendiosa. In cambio si otterranno nuovi visitatori.
L’accessibilità è utile a troppe poche persone (“Access serves too few people”):
L’accessibilità serve per le minoranze. Ovviamente è utile a poca parte delle persone.
Ma vanno ricordate le persone reali che stanno dietro le piccole percentuali. La
numerosità di questi campioni ha comunque una sua rilevanza come vedremo in un
punto successivo.
Va in oltre considerato il fatto che qualsiasi persona non disabile ora potrebbe divenire
una persona disabile in futuro.
L’Accessibilità è troppo difficile. (“Accessibility is too hard”):
In tutta onestà qualche aspetto della accessibilità può risultare eccessivamente
difficoltoso. Tuttavia, rendere usabili i siti Web dalle persone disabili è generalmente
semplice anche per sviluppatori alle prime armi.
Il Web è visuale (“The Web is visual”):
Con poche eccezioni il Web è un canale comunicativo visuale. Ma lo sono anche la
1
2
Joe Clark: “Accessibility, quite simply, is the next skill you have to learn”, (Building Accessible Websites)
Joe Clark:”Building Accessible Websites”
-5-
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
televisione e i film e diversi studi hanno ripetutamente dimostrato come i non vedenti e
gli ipovedenti hanno lo stesso interesse nel guardare televisione e film. Vivono nello
stesso mondo dei vedenti e comprendono che il Web è un utile veicolo di informazioni,
intrattenimento, comunicazione e socializzazione.
Non è il nostro mercato (“It’s not our market”):
Risulta evidente da se che qualche prodotto Web è intrinsecamente inaccessibile per le
persone lese nella vista, ad esempio siti di scuole di guida o enti militari. D’altra parte
queste persone hanno amici e parenti. Un simile modo di ragionare può essere molto
pericoloso per i siti di commercio elettronico. E guardiamolo da un punto di vista
morale, se fosse tecnicamente possibile creare un sito Web che escludesse ebrei, donne
o anziani, lo fareste?
Lo stesso autore propone poi una valida lista di motivi per cui occuparsene:
E’ un obbligo di legge (“It’s the law”):
In Italia, con la legge 04/2004 è divenuto un obbligo per le Pubbliche Amministrazioni
pubblicare dei siti Web Accessibili. Leggi analoghe sono in vigore negli Stati Uniti, in
Canada, in Australia, nel Regno Unito ed in altre parti del mondo. La trattazione
approfondita di questa materia è sviluppata in un capitolo dedicato di questa tesi;
E’ un’altra freccia nel vostro arco (“Another arrow in your quiver”):
Come accennato in precedenza l’accessibilità è semplicemente la successiva
competenza che si deve apprendere, né più né meno di come si sono apprese le altre
nozioni necessarie per produrre pagine Web;
Ridondanza (“Redundancy”):
Un principio basilare dell’accessibilità è quello di fornire alternative, dove si trova una
immagine occorre dare anche il testo. Una forma di ridondanza utile. I progettisti Web
con esperienza, scrivono già utilizzando questo principio ripetendo ad esempio i
comandi di navigazione, i comandi di ricerca, gli ausili alla navigazione. L’accessibilità
fornisce semplicemente un’altra forma di ridondanza;
Arricchimento (“Richness”):
Quando sono stati inventati i rollover in JavaScript hanno arricchito le pagine Web. Allo
stesso modo l’accessibilità prosegue su questa linea. Una pagina accessibile fornisce
testo a comparsa, funzionalità alternative e variazioni particolari che possono essere
attivate solo quando la pagina viene pronunciata anziché visualizzata;
Vale di più (“It’s worth more when you flip it”):
Un sito Web costruito con i principi dell’accessibilità ha un valore maggiore di quanto
non lo abbia un sito inaccessibile. L’accessibilità diventa uno dei tanti attributi a cui si
può dare un prezzo al momento di venderlo;
-6-
Conformità agli standard (“Standards compliance”):
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La tendenza attuale del Web è quella di livellarsi alle migliori qualità. Per metà decennio
sono stati aggiunti estensioni non standard al Web. Questa linea è oramai al tramonto.
Il vantaggio principale di adeguarsi agli standard è la realizzazione dell’obiettivo
“scrivere una volta, leggere ovunque”1. Invece di codificare la pagina per tutte le
differenti versioni dei browser, si scrive una sola pagina in accordo con le specifiche, ed
ogni dispositivo la leggerà correttamente. La conformità agli standard è una forma di
maturità nella programmazione;
Maturità sociale (“Social maturity”):
Progettare per l’accessibilità richiede progettare per persone che non sono esattamente
come noi, e questo è vero sia che il progettista sia un disabile, sia che non lo sia.
Per chiudere questa breve perorazione della causa della accessibilità vorrei riportare un
pensiero di Jim Thatcher: “Quasi tutta la tecnologia Web può essere resa accessibile con
nessuna conseguenza sull’aspetto visivo. Ed, in oltre, il procedimento è piuttosto agevole.”2.
II.2 - Il concetto di accessibilità
Per capire di cosa tratta l'accessibilità vorrei ricorrere ad alcune definizioni.
La prima definizione è quella della parola inglese accessible ("accessibile", in italiano),
contenuta nel glossario delle WCAG 1.0 allegato in appendice.
Tradotto in italiano risulta: "Un contenuto è accessibile quando può essere usato da qualcuno
con una disabilità"3.
Questa lettura riporta direttamente il riferimento ai disabili come ai maggiori fruitori del
servizio.
La Legge 04/2004, dal canto suo, definisce come accessibilità4:
“la capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze
tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni,
anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o
configurazioni particolari”.
Il termine anche ci fa capire che potrebbe non essere sufficiente considerare solo le persone
disabili nella progettazione di siti ad alta accessibilità.
1
“Write once, read anywhere.”
“Almost all Web technology can be made accessible with no impact on the visual appearance. And, as we
shall see, the process is fairly simple.” [http://www.jimthatcher.com/webcourse1.htm]
3
"Content is accessible when it may be used by someone with a disability"
[http://www.w3.org/TR/WCAG10/]
4
Legge 04/2004, articolo 2, comma (a)
2
-7-
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
A questa lettura va sicuramente aggiunto quanto prima riportato come motto del W3C: "La
forza del Web sta nella sua universalità. L'accesso da parte di chiunque, indipendentemente
dalle disabilità, ne è un aspetto essenziale".1
Evidenzierei quindi due elementi fondamentali dell'accessibilità:
L'attenzione ai problemi di accesso al Web dei disabili;
L’attenzione a garantire l'universalità dell'accesso, in altre parole a non escludere
nessuno: non solo i disabili in senso stretto, ma anche chi soffre di disabilità
temporanee, chi ha attrezzature obsolete, chi usa sistemi poco comuni, chi dispone di
connessioni particolarmente lente.2
In accordo con questo secondo punto tenderei a dare una definizione che includa anche gli
utenti che non sono disabili in senso stretto. Di base, una tecnologia è accessibile se può
essere usata con efficienza da persone con disabilità come da quelle senza. 3
Su questo punto di vista ci viene in aiuto anche la definizione4 degli obiettivi di accessibilità
data nelle WCAG 2.0, il testo in lingua originale può essere reperito in appendice:
“Seguire queste linee guida renderà anche i contenuti Web più usabili a molti altri
utenti, inclusi le persone anziane. In oltre permetterà alle persone di accedere al web
utilizzando dispositivi differenti, inclusa una vasta gamma di tecnologie assistive e
tecnologie per apparecchiature portatili”.
Beneficiari dell’accessibilità
Come accennato, i disabili in senso stretto sono solo una parte, e neppure la più cospicua dei
beneficiari dell’accessibilità. Le stesse linee guida WCAG 1.0 ne presentano una nutrita lista nel
loro preambolo introduttivo.
A questo proposito Michele Diodati5 ha sintetizzato accuratamente le categorie di utenti per i
quali, per un campo di applicazione o per un altro, la realizzazione di siti accessibili può tornare
utile.
Ne riporto un elenco sintetico, un ulteriore approfondimento sulle considerazioni sulle
tecnologie dei singoli casi può essere reperito nell’articolo originale:
1
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential
aspect.” - [http://www.w3.org/WAI/]
2
Michele Diodati: “Guida all’accessibilità dei siti Web”
3
“Basically, technology is accessible if it can be used as effectively by people with disabilities as by those
without.” [http://www.jimthatcher.com/webcourse1.htm]
4
WCAG 2.0: Abstract
5
Michele Diodati: [http://diodati.org/scritti/2004/guida/ele_acc07.asp]
-8-
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Persone con normali problemi della vista quali miopia, presbiopia, astigmatismo,
ipermetropia, cataratta, eccetera: sono milioni, soprattutto tra gli ultraquarantenni;
Persone anziane e/o dotate di scarsa o nulla preparazione informatica;
Persone di livello culturale basso o bassissimo;
Persone che parlino un'altra lingua;
Persone che usino software obsoleti;
Persone che dispongano di hardware obsoleto e connessioni lente;
Persone che usino sistemi e periferiche poco comuni. A cui vanno aggiunti gli utenti che
navighino utilizzando:
o
Un normale televisore (webTV);
o
Telefoni cellulari di ultima generazione dotati di browser (Nokia, Eriksson, ecc.) e
schermo da 160-172 pixel;
o
Computer palmari con schermi larghi mediamente 240 pixel;
o
Agendine elettroniche tipo Psion;
o
Monitor impostati a risoluzioni particolarmente elevate (2048x1536) o
particolarmente basse (il "vecchio" standard 640x480);
o
Monitor monocromatici o con un numero di colori ridotto (16 o 256);
o
Chioschi multimediali con selezione tramite tatto;
o
Periferiche comandabili a voce;
Persone che si colleghino in condizioni ambientali difficili;
Indicizzatori automatici (chiamati "robot" o, in inglese, "spider") provenienti da motori
di ricerca.
Gli obiettivi dell’accessibilità
Per quanto l’accessibilità si proponga degli obiettivi a vasto raggio, occorre tener presente che,
proprio per la numerosità degli utenti coinvolti in questo processo, non sempre e non tutto può
essere raggiunto.
Un articolo introduttivo a questo proposito, illuminante per definizioni e chiarezza, è quello di
Jim Byrne1.
L'articolo analizza i numerosi problemi e le contraddizioni che sorgono quando si tenta di
realizzare in concreto un'accessibilità veramente universale.
Byrne parte dal concetto generico di accessibilità che non contempli a priori le direttive WAI e
ne espone le possibili chiavi di lettura. In tal senso un sito accessibile potrebbe essere:
1
Jim Byrne “What is an accessible Website?” [http://www.mcu.org.uk/articles/whatisaw.html]
-9-
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Un sito che è accessibile a chiunque,
Un sito che è accessibile ad un pubblico specifico, per quanto probabilmente non lo sia
per tutti,
Un sito che è accessibile alle persone disabili,
Un sito che sia accessibile innanzi tutto alle macchine e di conseguenza alle persone.
Il primo obiettivo, per quanto appaia in prima battuta il fine migliore da perseguire, rischia di
condurre ad un progetto utopico, quantomeno se si deve tener conto dei problemi di linguaggio
e di conoscenze1 di tutti i potenziali utenti.
Per mirare invece ad ottenere il secondo tipo di accessibilità in senso lato occorrerebbe
comunque essere a conoscenza delle capacità fisiche e cognitive del pubblico selezionato e
progettare per tutte le tecnologie Web di questi utenti, browser, tecnologie assistive, ampiezza
degli schermi ed altri accorgimenti, oltre che per tutte quelle future.
Per quanto riguarda l’accessibilità per i disabili, non vi sono dubbi che progettare siti con
queste caratteristiche sia uno degli obiettivi da perseguire. E tuttavia risulterebbe sicuramente
inefficiente se dovessimo mirare a soddisfare l’utente finale specifico, rischiando di arrivare a
delle soluzioni molto difficili da produrre ed aggiornare.
In sostanza occorre spostare l’attenzione dal contenuto al modo di predisporlo. Gli accessi alle
pagine Web sono ottenuti tutti mediante qualche tipo di tecnologia, e questo è vero sia per i
disabili che per chiunque altro. Tecnologie assistive come display Braille, browser vocali,
tastiere adattative non sono altro che dispositivi da aggiungere alla lista degli altri programmi
utenti più conosciuti come PDA, smartphone ed altro.
Il sistema per garantire a questa svariata mole di dispositivi il corretto funzionamento è
semplicemente quello di utilizzare il linguaggio a marcatori del Web, l’HTML, nella maniera
corretta.
Se vogliamo rendere accessibile il contenuto Web per le persone, il primo passo è garantire
che le nostre pagine siano accessibili alle tecnologie che le persone utilizzano, e questo è
ottenibile impiegando gli standard dell’HTML 2.
1
Jim Byrne: “I'm inclined to think that not all Web documents will be made more accessible by re-writing
them in short sentences and using simple words. Some will, but not all - and to satisfy this first definition we need to be accessible to everyone.”
2
Jim Byrne: “If we want to make our content accessible to real people and the first step to achieving this is
to ensure that our pages are accessible to the technology that people will be using. The best chance we
have of doing that is to create our pages using standard HTML.”
- 10 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il passo immediatamente conseguente a questa lettura è quello della separazione del
contenuto dalla sua presentazione che sarà poi a carico degli specifici programmi utente. Di
questo aspetto parleremo meglio nel capitolo dedicato alle metodologie generali.
Al termine della sua presentazione Byrne riassume i concetti esposti in alcuni punti
fondamentali.
Cercare di rendere i nostri contenuti accessibili a tutti indistintamente è pressoché
impossibile. L'accessibilità è un concetto relativo: dipende dal proprio pubblico di
riferimento, dalla conoscenza che si ha dei suoi bisogni e dalle risorse che si hanno a
disposizione;
Non è possibile controllare il modo in cui una pagina sarà presentata all'utente finale. La
sola cosa su cui è possibile avere un controllo assoluto è il codice di marcatura usato
nelle pagine;
Tutti i contenuti arrivano all'utente attraverso un qualche tipo di computer e di browser;
Il primo passo per creare siti accessibili è creare siti che siano accessibili alle macchine.
La migliore opportunità per ottenere ciò è usare HTML standard;
Quando il contenuto può essere diviso dalla presentazione, usando i fogli di stile, il
medesimo contenuto può essere presentato in molti modi differenti. Non occorre
pertanto preoccuparsi di creare molteplici versioni di una stessa pagina per venire
incontro ai bisogni di un pubblico diversificato;
Le linee guida del W3C sull'accessibilità possono essere usate per rendere i siti Web
basati sugli standard più flessibili e più capaci di soddisfare i diversi bisogni degli utenti.
Insomma, rendere una pagina Web accessibile alle macchine (computer e browser) e
flessibile nella struttura sono gli obiettivi principali a cui evidentemente puntano le
raccomandazioni di accessibilità.1
In ciò la differenza con l'usabilità è grande: quest'ultima infatti lavora essenzialmente
sull'interazione tra la pagina e gli utenti, anzi le specifiche categorie di utenti considerate come
pubblico di riferimento dei siti da testare.
La differenza fra queste due finalità viene trattata in un capitolo a parte.
1
Michele Diodati: [http://diodati.org/scritti/2004/guida/ele_acc06.asp]
- 11 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
II.3 - Usabilità
Penso che sia importante distinguere le definizioni delle due discipline. In questa breve
discussione vorrei distinguere i due concetti di accessibilità ed usabilità delimitandone, per
quanto possibile, i campi di utilizzo.
Molto del materiale qui esposto è tratto da alcune lezioni su internet di professionisti
competenti, tra cui Michele Diodati1, Maurizio Boscarol2 e Dario Violi3, ai cui articoli citati
rimando per una lettura più completa.
Presentazione
Prima di passare a chiarire quali sono le relazioni con l’accessibilità presento una breve
premessa sull’usabilità, necessaria, a mio avviso, a chiarirne meglio la definizione e gli scopi.
Definizione
Una definizione data da Roberto Scano in una intervista ne definisce meglio gli aspetti.
L'usabilità è la possibilità di accedere ad informazioni e servizi in modo semplice ed
intuitivo, garantendo ad un elevato numero di persone di poter raggiungere un obiettivo in
pochi e semplici passi. L'usabilità nel Web è un argomento altamente dibattuto e, a differenza
dell'accessibilità, non vi sono degli standard internazionalmente riconosciuti ma ad oggi
esistono solo delle raccomandazioni di esperti che consentono di valutare l'usabilità di un sito
Web.4
Vediamo le definizioni ISO del termine usabilità. Si rintraccia in due norme:
Secondo la definizione data dalla norma ISO 9241, l'usabilità è 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.”5
Secondo la definizione data dalla norma ISO 9126, l’usabilità è una qualità del software,
in particolare “la capacità di essere compreso, appreso, usato con soddisfazione
dall’utente in determinate condizioni d’uso”.
Trasportata in ambito Web, questa definizione ci dice che lo scopo dell'usabilità è quello di
1
Michele Diodati: [http://diodati.org/scritti/2004/guida/ele_acc06.asp]
Maurizio Boscarol: [http://www.usabile.it/012000.htm]
3
Dario Violi: [http://webdesign.html.it/articoli/leggi/1672/usabilita-e-accessibilita/]
4
[http://www.scarichiamoli.org/main.php?page=interviste/scano]
5
"[Usability refers to] the extent to which a product can be used by specified users to achieve specified
goals with effectiveness, efficiency and satisfaction in a specified context of user." - ISO 9241-11 [http://www.usability.gov/basics/whatusa.html]
2
- 12 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
studiare l'interazione tra l'utente e il sito, o tra l'utente e la singola pagina Web, con l'obiettivo
di mettere in luce gli ostacoli che di volta in volta si frappongono ad un uso efficace, efficiente
e soddisfacente delle informazioni e dei servizi contenuti nel sito o nella pagina. 1
Storia dell’usabilità
La normativa ISO 9241 è del 1993 e si riferisce ai prodotti informatici in genere. Tuttavia
l'usabilità è un concetto precedente e più esteso: nasce negli anni 60 nell'ambito
dell'ergonomia in relazione a qualunque interazione uomo-artefatto.
Compito degli studi di usabilità è fare in modo che il modello mentale di chi ha progettato il
software (design model), da cui deriva il suo reale funzionamento, corrisponda il più possibile
al modello mentale del funzionamento del software così come se lo costruisce l'utente finale
(user model).
L'usabilità nasce dunque soprattutto come ausilio alla progettazione, e si applica in particolare
alle interfacce. E' con l'interfaccia di un software, infatti, che l'utente si relaziona.
Va sottolineato che l'usabilità ha senso solo in presenza di un utente e di una relazione d'uso, e
non esiste nel prodotto in sé. Le tecniche di usabilità tentano dunque di porre al centro
dell'attenzione progettuale proprio l'utente.
Può sembrare un dettaglio scontato, sembra ovvio che il prodotto venga progettato per chi lo
usa. Invece, dato che fino a tutti gli anni 70 il computer non era un prodotto di massa, i
principali utilizzatori dei prodotti software finivano per essere gli stessi progettisti o persone
esperte con una formazione mentale simile ai progettisti.
Di conseguenza l'usabilità era un problema implicito, sapendo progettare il software, si sapeva
anche usarlo. Lo schema mentale del progettista e quello dell’utente erano gli stessi.
Tale problema è invece emerso dapprima negli anni 80, con la diffusione delle tecnologie
informatiche a livello di ufficio e di famiglia, ed è esploso negli anni 90, con la diffusione del
personal computer. Gli utenti finali del software e dell’hardware non erano più i progettisti.
Macintosh è stato il primo computer con un sistema operativo completamente visuale, basato
sulla metafora della scrivania e dello spostamento intuitivo degli oggetti. Si trattava di un
cambiamento radicale. Macintosh si propose come computer orientato all'uso da parte di
persone completamente a digiuno di informatica.
Poco dopo Windows riutilizzò la stessa struttura diffondendosi rapidamente e tutti i programmi
utilizzati presentano un'interfaccia di tipo visuale. Non serve essere esperti per farli funzionare
ed il problema della usabilità si pone con urgenza.
1
Michele Diodati: [http://diodati.org/scritti/2004/guida/ele_acc06.asp]
- 13 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Con l'avvento di Internet e la proliferazione dei siti Web, il problema si sposta sul nuovo
dominio, dove naturalmente dovrà tener conto delle caratteristiche dell'interazione, in qualche
caso anche molto diverse da quelle tipiche del software. Se nel caso di un software questo
viene normalmente usato dopo esser stato acquistato, un sito Web invece viene prima usato, e
solo se l'uso risulta soddisfacente può dar vita ad una transazione ed eventualmente ad un
guadagno. L’usabilità deve essere immediata ed efficace.
Accessibilità ed Usabilità
I termini accessibilità ed usabilità sono spesso utilizzati in modo confuso, in effetti le loro
reciproche sfere di influenza tendono in certi casi a sovrapporsi visto che sono effettivamente
materie affini.
Entrambe hanno come scopo, nel nostro specifico, il miglioramento delle interfacce Web.
Entrambe, inoltre, partono dal presupposto che i siti dovrebbero essere fruiti attraverso
qualunque browser, e che la correttezza formale del codice, da sola, non rende un sito
accessibile né usabile.
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 esperto di usabilità cada nello
stesso sbaglio pensando di aver realizzato un sito accessibile una volta completato il suo
lavoro.
Una distinzione è dunque necessaria per una buona progettazione dei siti Web.
Sovrapposizioni e differenze
La sovrapposizione tra gli obiettivi dell'usabilità e quelli dell'accessibilità si verifica per quelle
raccomandazioni che puntano a migliorare l'accessibilità dei contenuti. Rendere l'uso di una
risorsa più semplice e soddisfacente nella fruizione è appunto anche lo scopo dell'usabilità.
A questo proposito, durante il seminario IWA sulla legge Stanca1 di cui si parlerà diffusamente
in seguito, Luca Mascaro ha espresso il concetto che l’usabilità, applicata su una base di una
già raggiunta accessibilità del sito consente di ottenere la fruibilità completa dei contenuti.
Le due discipline presentano sostanziali differenze sia a livello concettuale sia, soprattutto, a
livello metodologico.
Innanzitutto, mentre nell’accessibilità la priorità è data all'accesso ai contenuti, nell’usabilità la
priorità è data alla loro comprensione. Nel primo caso la progettazione è orientata alle
caratteristiche del sito, nel secondo al processo produttivo.
1
Roberto Ellero, Luca Mascaro - Seminario IWA/IWG – Arese, Maggio 2005
- 14 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L'accessibilità rivolge le sue raccomandazioni allo sviluppatore tralasciando più o meno
completamente di occuparsi del rapporto tra il risultato e l'utente finale: rendere una pagina
Web accessibile alle macchine e flessibile nella struttura sono gli obiettivi principali a cui
puntano le raccomandazioni di accessibilità.
L’usabilità invece lavora essenzialmente sull'interazione tra la pagina e gli utenti, anzi le
specifiche categorie di utenti considerate come pubblico di riferimento dei siti, dal momento
che l'usabilità va intesa relativamente ad una specifica categoria di utenti finali.
La differenza si riscontra anche osservandone i metodi. La realizzazione di un sito accessibile
passa attraverso il rispetto di determinate norme come ad esempio le 14 linee guida delle
WCAG 1.0 o i 22 requisiti della Legge Stanca, e la valutazione dell'accessibilità può essere
svolta con strumenti automatici o semiautomatici per una sostanziosa parte del lavoro.
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 piuttosto chele macchine.
Usabilità al servizio dell'accessibilità
Pensare all'accessibilità, quindi, non significa soltanto progettare affinché un sito possa essere
letto attraverso qualunque dispositivo, ma anche generare strutture chiare e contenuti
comprensibili. In questo caso i metodi dell'usabilità, possono aiutare nella progettazione di un
sito accessibile intervenendo ai livelli in cui l'applicazione di specifiche tecniche non è
sufficiente, e nel progetto dell'architettura dell'informazione.
In assenza di un progetto di usabilità, infatti, l'applicazione dei soli 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 collegamenti ipertestuali troppo generici clicca qui con dei
collegamenti contestualizzati, ma la scelta di quale testo utilizzare implica i metodi di
progettazione e valutazione dell'usabilità.
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 in grado di accedere a vocabolari multi-lingua. Un cambiamento nella
lingua del sintetizzatore, però, produce anche variazioni nel timbro della voce e altera il ritmo
della lettura, senza contare che alcuni vecchi applicativi spesso perdono molto tempo nel
caricare il dizionario di lettura opportuno. Tutto questo può risultare più fastidioso
dell'ascoltare una parola straniera letta con una pronuncia sbagliata e non va incontro
all’usabilità del sito.
Ma anche le teorie alla base dell'accessibilità si rivelano estremamente utili ai fin della
progettazione di un sito usabile. Molti dei problemi di usabilità sono infatti legati alla scarsa
accessibilità dei contenuti.
- 15 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Se gli utenti del sito sono persone con problemi di vista, un testo scritto a caratteri troppo
piccoli risulterà poco leggibile, così come dei collegamenti troppo ravvicinati rischiano di
generare problemi di navigazione anche a persone senza limitazioni nei movimenti.
La ricerca dell'accessibilità ha permesso di comprendere al meglio i limiti di tutti gli utenti e,
soprattutto, di progettare e realizzare siti che tengano conto di tali limiti.
A questo proposito vorrei ricordare un passo di una intervista di Jim Thatcher, secondo cui
l’accessibilità Web deve essere vista come parte dell’usabilità. Per una persona disabile
usabilità è quello che altri chiamano accessibilità, poiché deve utilizzare il sito con software
come gli screen-reader.1
Normative
Vediamo come le normative considerate hanno trattato il tema dell’usabilità. Nell’elenco non
viene riportata la normativa americana in quanto non si occupa direttamente del tema nella
sezione considerata.
WCAG 1.0
Le ultime tre raccomandazioni2 delle WCAG 1.0 mirano agli aspetti cognitivi dell'interazione
dell'utente con la pagina.
L'usabilità ha anche questi scopi.
L'appendice A delle WCAG 1.0 propone una serie di metodi che consistono principalmente nella
validazione automatica del codice della pagina per mezzo di appositi software. Ma ai punti 9 e
10 dell'appendice si fa un riferimento a possibili test con utenti umani, pur senza suggerire
specificamente il ricorso ai metodi sviluppati in questo campo dall'usabilità.
Nella stessa definizione di accessibilità poi si dice che un contenuto è accessibile quando può
essere usato da qualcuno con una disabilità; questa definizione rende l'usabilità parte
integrante dell'accessibilità. L'accessibilità diventa quindi requisito per l'usabilità nel momento
in cui sono stati focalizzati gli utenti di riferimento.
Se, in teoria, l'accessibilità di un sito ne prevede l'usabilità, le WCAG 1.0 non sono un ottimo
strumento per la realizzazione di un sito usabile. Pur raccomandando la chiarezza dei contenuti
e della struttura ipertestuale (punti 12, 13 e 14) le WCAG nascono come strumento per gli
sviluppatori, professionisti del processo produttivo di un sito Web che spesso hanno poca
dimestichezza con i meccanismi dell'usabilità.
1
[http://www.fucinaweb.com/fw/jimthatcher/]
12: "Fornire informazione per la contestualizzazione e l'orientamento", 13: "Fornire chiari meccanismi di
navigazione" e 14: "Assicurarsi che i documenti siano chiari e semplici"
2
- 16 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per le WCAG l'usabilità è parte della definizione di accessibilità, ma non è parte del metodo.
Legge 04/2004
La legge 04/2004 riprende una sostanziale differenziazione dei due concetti distinguendo tra
un primo ed un secondo livello di accessibilità.
Il Decreto Ministeriale 8 luglio 2005 allegato alla legge Stanca recante i requisiti tecnici è
parzialmente riportato in appendice. Il legislatore italiano suddivide la verifica soggettiva e la
verifica oggettiva, deputando alla prima, previo esito corretto della verifica tecnica, il
conseguimento degli obbiettivi di accessibilità dei contenuti e alla seconda la qualità delle
informazioni fornite e dei servizi erogati dal sito
Ai 22 requisiti tecnici derivati dalle linee guida delle WCAG 1.0, sufficienti per ottenere il
requisito di accessibilità dei contenuti, si affianca, con il nome di verifica soggettiva, la
valutazione dell'usabilità. In questo secondo caso la metodologia prevede infatti l'analisi del
sito da parte di uno o più esperti di fattori umani, la definizione di scenari d'uso per simulare il
comportamento dell'utente e, soprattutto, il coinvolgimento diretto di utenti disabili. Si tratta
quindi di un vero e proprio test di usabilità, richiamati per altro anche nei criteri di valutazione:
dove troviamo, ad esempio, la comprensibilità, l'operabilità, la coerenza, la tolleranza agli
errori e la gradevolezza, elementi che fanno da componenti essenziali al concetto di usabilità.
WCAG 2.0
Anche il gruppo di lavoro che sta elaborando le WCAG 2.0 ha deciso di assumere, fin dal
documento normativo principale, una posizione esplicita nella suddivisione delle finalità e di più
netto orientamento verso l’accessibilità.
Nel paragrafo Abstract della bozza di lavoro delle WCAG 2.0 si afferma che seguire queste linee
guida renderà anche il contenuto Web più usabile a molti altri utenti, incluse le persone
anziane. Si ribadisce però che le linee guida non includono raccomandazioni standard di
usabilità a meno che esse non abbiano uno specifico impatto sull’accessibilità 1.
Di fatto molte delle raccomandazioni contenute nei tre ultimi principi delle linee guida 1.0,
proprio quelle più vicine al tema dell’accessibilità, vengono tenute in una considerazione molto
minore nella versione 2.0.
Il terzo principio, quello della comprensibilità, che più dovrebbe riassumerne gli aspetti, non
contiene, infatti, riferimenti espliciti ai concetti dell’usabilità. Con questo non si vuole certo dire
1
“The guidelines do not include standard usability recommendations except where they have specific impact
on accessibility.”
- 17 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
che le WCAG 2.0 siano un passo indietro, semplicemente hanno invece voluto maggiormente
distinguere le due discipline e focalizzarsi meglio sui compiti specifici dell’accessibilità.
II.4 - La disabilità
Per capire meglio a quali problematiche va incontro l’accessibilità, vorrei dare un
inquadramento più preciso al concetto di disabilità, fornendone definizioni e caratteristiche dei
problemi inerenti la fruizione dei servizi Web.
Definizione WHO
Secondo la definizione data nel 1980 dall’Organizzazione Mondiale della Sanità 1, nota come
International Classification of Impairments, Disabilities and Handicaps (ICIDH-1), sono definiti i
termini:
Menomazione (impairment): qualsiasi perdita o anormalità a carico di una struttura o
una funzione psicologica, fisiologica, anatomica.
Disabilità (disability): limitazione o perdita (conseguente a menomazione) della
capacità di compiere una attività nel modo e nell’ampiezza considerati normali.
Handicap (handicap): condizione di svantaggio conseguente a una menomazione o a
una disabilità che limita o impedisce l’adempimento del ruolo normale per tale
soggetto,in relazione all’età, al sesso, ai fattori socio-culturali.
Questa definizione, sia pure non recente, è, di fatto, più corretta rispetto al modo comune
di parlare e affrontare il problema degli handicap. Essa, infatti, evidenzia come alcune persone,
a seguito di una menomazione, possano avere delle limitazioni nella capacità di svolgere certe
azioni, e siano poste in una condizione di svantaggio, che potrebbe spesso essere ridotta
adottando opportune azioni o accorgimenti.2
Così, ad esempio, una persona su sedia a rotelle è sicuramente disabile, ma potrebbe
potenzialmente non essere handicappata se al mondo fossero eliminate tutte le barriere
architettoniche, cosicché non gli verrebbe precluso l’accesso a nessun settore della vita sociale.
È evidente che, in tale accezione, si può contare il numero delle persone con disabilità, ma non
di handicappati; la condizione di handicap è prettamente soggettiva e dipende dalle aspettative
di vita e esigenze della persona disabile.3
Ancora più ampia è la International Classification of Functioning, Disability and Health (ICF
1
2
3
World Health Organization [http://www.who.int]
Oreste Signore: “Handimatica 2004”
[http://www.disabilitaincifre.it/]
- 18 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
ICIDH-2) data, sempre dalla Organizzazione Mondiale della Sanità (WHO), nel 2001. 1
Questa nuova classificazione relativa alla salute e ai domini legati alla salute permette di
descrivere le modifiche nelle funzioni e strutture corporee, e quindi ciò che le persone possono
fare in un ambiente standard (livello di capacità) e nel loro ambiente abituale (livello di
performance). I domini vengono classificati dal punto di vista corporeo, individuale e di
relazione per mezzo di due liste: la lista delle funzioni e strutture corporee, e quella dei domini
di attività e partecipazione.
Nella classificazione ICF, il termine funzionamento (functioning) fa riferimento a tutte le
funzioni corporee, mentre disabilità (disability) è un termine generico per riferirsi a
menomazioni, limitazioni delle attività e restrizioni alla partecipazione.
Questa nuova classificazione si differenzia quindi dalla precedente perché parla di
funzionamento umano in generale (functioning) e non puramente di disabilità, e fornisce un
modello universale, che non riguarda solo una minoranza.
Proprio perché pone l’enfasi sul funzionamento umano, essa integra gli aspetti medici e quelli
sociali, e non fa riferimento esplicito a eventuali menomazioni, né costringe a esplicitare il tipo
di disabilità. Per le sue caratteristiche, copre l’intero arco della vita, e considera anche le
caratteristiche dei bambini e degli anziani. In altri termini, si passa da definire le conseguenze
di un disturbo ad analizzare i componenti della salute.
Disabilità in cifre
Penso che sia opportuno dare un quadro delle persone in Italia che sono interessate ad
ottenere siti accessibili. Per questo mi rifaccio al sito dell’ISTAT (Istituto Nazionale di Statistica)
sulla disabilità2. Dati completi ed informazioni aggiornate possono essere direttamente reperiti
sul sito originale.
La principale fonte di dati utilizzata per stimare il numero delle persone con disabilità
presenti in Italia è l'indagine ISTAT sulle Condizioni di salute e il ricorso ai servizi sanitari. Essa
è però parziale, e va quindi integrata per giungere a una stima complessiva. 3
In base alle stime ottenute dall’indagine sulla salute e il ricorso ai servizi sanitari, emerge che
in Italia le persone con disabilità sono circa 2.615.000, pari al 5% della popolazione di 6 anni e
più che vive in famiglia.
La stima si basa su un criterio molto restrittivo di disabilità, quello secondo cui vengono
considerate persone con disabilità unicamente quelle che nel corso dell'intervista hanno riferito
1
2
3
Oreste Signore: “Handimatica 2004”
[http://www.disabilitaincifre.it/]
[http://www.disabilitaincifre.it/prehome/stima_numerodisabili.asp]
- 19 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
una totale mancanza di autonomia per almeno una funzione essenziale della vita quotidiana.
Se consideriamo in generale le persone che hanno manifestato una apprezzabile difficoltà nello
svolgimento di queste funzioni la stima allora sale a 6.980.000, pari al 13% della popolazione,
che vive in famiglia, età superiore ai 6 anni.
Tale dato è in linea con quello rilevato nei principali paesi industrializzati.
Sfuggono tuttavia le persone che, soffrendo di una qualche forma di disabilità non fisica ma
mentale, sono in grado di svolgere tali attività essenziali.
Considerando il numero di persone che vivono in famiglia, la stima del numero di bambini sotto
i 6 anni e le persone residenti nei presidi socio-sanitari si giunge ad una stima complessiva di
poco più di 2.800.000 persone con disabilità. E' bene chiarire ancora che si tratta di stime, che
presumibilmente distorcono verso il basso il reale numero di persone con disabilità in Italia.
Poiché, infatti, le persone con disabilità in famiglia vengono rilevate tramite indagine
campionaria col metodo dell'intervista diretta alla disabile o a un suo familiare, non si può
escludere che vi sia una sottostima, dipendente dal tipo di disabilità, dovuta alla mancata
dichiarazione della presenza di tali persone in famiglia.
Tipologie della disabilità
Le tipologie della disabilità, per quanto attinente l’argomento di questa trattazione, possono
essere sostanzialmente riassunte in tre categorie fondamentali, come avviene soprattutto in
autori italiani1:
Disabilità sensoriali; in cui ricadono le varie disfunzioni della vista e dell’udito, le più
rilevanti da un punto di vista di accesso al Web;
Disabilità motorie;
Disabilità cognitive.
Le disabilità sensoriali sono di una tale rilevanza che questa categoria potrebbe anche essere
ulteriormente scissa in una suddivisione ulteriore dei gruppi, come avviene spesso in molti
autori anglo americani2:
Sordi (Deaf, hard-of-hearing, hearing-impaired);
Ciechi (Blind, visually-impaired, low-vision);
Menomazioni motorie (Mobility-impaired);
Disabili nell’apprendimento (Learning-disabled, cognitive disabilities).
1
Luca Mascaro, Conferenza IWA del 16 maggio 2005 ad Arese. Marco Calvo, Accessibilità dei siti internet.
[http://www.e-text.it/servizi/internet/accessibilita/accessibilita.htm]
2
Joe Clark: “Building Accessible Websites” [http://joeclark.org/book/]
- 20 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Vediamo adesso alcune brevi informazioni riassuntive sulle disabilità menzionate. La fonte è
quella ministeriale1.
Disabilità sensoriali
Come esposto in precedenza nelle disabilità sensoriali riassumo:
Disabilità della vista;
o
Non vedenti;
o
Ipovedenti;
Disabilità dell’udito.
La disabilità della vista comprende tipicamente due classi di utenti in quanto i modi di accesso
al computer sono diversi nei due casi.
Infatti i non vedenti devono utilizzare dispositivi di output fisicamente diversi dal monitor,
basati o su un'uscita audio, come un sintetizzatore vocale, o su un'uscita tattile, come il display
Braille. Le persone ipovedenti, invece, utilizzano il monitor come dispositivo d’uscita
dell'informazione, anche se con opportune modifiche.
Disabilità sensoriali: i non vedenti
Il problema che limita l'accesso delle persone non vedenti ai contenuti delle pagine Web
consiste nel seguire e comprendere la strutturazione di un'interfaccia utente di tipo grafico,
come Windows.
Per i non vedenti, passare da un sistema conosciuto, relativamente semplice da usare, come il
DOS, ad un sistema operativo complesso come Windows, non è assolutamente facile.
Per questo motivo, molti di loro preferiscono lavorare ancora in DOS, utilizzando un browser di
tipo testuale per accedere al Web, come Lynx.
Attualmente, però, la maggior parte della progettazione relativa ai contenuti del Web è
indirizzata ad una modalità di fruizione di tipo visivo.
Per consentire alle persone non vedenti di accedere ai contenuti così organizzati, è necessario
che questi stessi vengano interpretati in una forma alternativa: sonora o tattile.
Per realizzare l'interpretazione dei contenuti in forma alternativa esistono degli strumenti, tra i
quali lo screen-reader. Strumenti come questi compiono l'analisi e la rilettura degli elementi
1
[http://www.pubbliaccesso.gov.it/biblioteca/manualistica/accessibilita_siti/introduzione/ profili.htm]
- 21 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
grafici dello schermo e la loro opportuna traduzione o descrizione testuale mediante dispositivi
di uscita, come la barra Braille o il sintetizzatore vocale.
ll grado di efficienza di questi strumenti dipende dalla complessità della struttura
dell'informazione presentata sullo schermo.
In ogni caso, questi strumenti non riescono, in modo completo, a riprodurre in forma
alternativa l'aspetto completo dell’interfaccia utente.
La complessità e la struttura delle pagine Web influenzano direttamente l’accessibilità per chi
utilizza strumenti particolari. A questo punto entra in gioco la figura dell'autore di pagine Web.
Attraverso un'oculata e studiata progettazione della pagina, lo sviluppatore potrà realizzare
pagine che rendano più facile la conversione dei contenuti da parte dei programmi degli
screen-reader.
Disabilità sensoriali: gli ipovedenti
Gli ipovedenti sono persone con capacità visiva gravemente ridotta.
Essi non hanno bisogno di periferiche particolari, oltre che di un monitor di grandi dimensioni.
Gli ipovedenti devono, però, praticare adattamenti alla propria postazione di lavoro: impostare
una definizione molto bassa, scegliere una combinazione di desktop con caratteri grandi e
colori ben marcati; usare dei puntatori del mouse più grandi del normale e possibilmente
colorati.
Disabilità sensoriali: cecità ai colori
Una descrizione più approfondita merita il concetto di cecità totale o parziale ai colori.
Il motivo è dovuto all’utilizzo del colore come veicolo di informazioni, il quale, come
conseguenza a questa menomazione, deve necessariamente essere considerato dalle
normative sull’accessibilità.
Uno studio molto accurato di questa disfunzione fisica lo si può trovare sul testo di Joe Clark1 a
cui rimando senza dubbio per un approfondimento completo.
In questa sede espongo solamente gli elementi essenziali, rimandi utili possono essere
consultati anche sul sito ufficiale dell’Associazione Acromati Italiani 2.
Nella retina dell'occhio normale ci sono due tipi di cellule sensibili alla luce (fotorecettori): i
coni e i bastoncelli:
Coni (circa 6 milioni) sono prevalentemente concentrati al centro della retina, nella
regione denominata macula, e sono specializzati per la visione diurna: permettono di
1
2
Joe Clark: “Building Accessible websites”, chapter 9
[http://www.acromatopsia.it/]
- 22 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
adattarsi alla luce, percepire i colori e distinguere i dettagli fini. Sono di tre tipi: i coni
rossi (sensibili a onde lunghe), i coni verdi (sensibili a onde medie) e i coni blu (sensibili
a onde corte), funzionano con livelli di luce più intensi. Le loro differenti risposte,
secondo la lunghezza delle onde, ci rendono possibile la vista dei colori durante il
giorno;
Bastoncelli (circa 100 milioni) sono prevalentemente alla periferia della retina e sono
specializzati per la visione notturna: sono molto più sensibili alla luce dei coni ma si
saturano rapidamente quando essa aumenta e non permettono di percepire i colori né
di distinguere bene i dettagli.
Nell'occhio normale i coni e i bastoncelli si integrano tra loro e permettono di vedere in
qualunque condizione d'illuminazione.
Nella retina delle persone affette da acromatopsia (acromati), invece, tutti i coni funzionano
molto poco o non funzionano per niente. Queste persone, perciò, devono affidarsi unicamente
ai bastoncelli per vedere: di conseguenza sono parzialmente o totalmente cieche ai colori,
hanno una scarsa acuità visiva e i loro occhi non sono in grado di adattarsi in modo normale a
una luce più intensa di quella del crepuscolo.
Accanto alla acromatopsia, piuttosto rara, ci sono le cecità parziali ai colori, invece più diffuse.
Il difetto deriva da alterazioni dei geni che decodificano i pigmenti dei coni, due dei quali, i
pigmenti dei coni rossi e verdi, sono legati al sesso; da qui la maggior incidenza negli uomini
piuttosto che nelle donne.
La perdita di funzione di uno dei pigmenti dei coni, e quindi del corrispondente tipo di coni,
riduce la visione dei colori, che in genere è tridimensionale o tricromatica con una dimensione
corrispondente a ciascuna delle sensibilità spettrali dei coni, e la modifica da tridimensionale a
bidimensionale o bicromatica.
Le relative malattie sono:
La protanopia: indica la mancanza del pigmento dei coni rossi;
La deuteranopia: indica la mancanza dei coni verdi;
La tritanopia: indica la mancanza dei coni blu.
I primi due difetti (protanopia e deuteranopia) sono associati alla cecità per il rosso e per il
verde, o per la confusione del verde e giallo, e del giallo e rosso tra loro. Differiscono
principalmente nel fatto che i rossi appaiono relativamente più scuri ai pronatopi piuttosto che
ai deuteranopi, perché il pigmento dei coni verdi dei deuteranopi assorbe la luce rossa con
meno efficacia del pigmento dei coni rossi.
La tritanopia è, invece, associata con la cecità per il giallo e il blu o la confusione del viola, del
blu e del blu-verde tra loro. Il termine cecità per il giallo-blu è un termine ingannevole, in
- 23 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
quanto, se i dicromatici rossi-verdi confondono il rosso con il verde, le persone affette da
tritanopia non confondono mai il giallo con il blu.
Più frequenti, ma meno gravi, forme di cecità parziale per i colori, note come tricromatismo
anomalo, sono causate dalla sostituzione dei pigmenti dei coni rossi o verdi con un pigmento
anomalo codificato da un gene ibrido rosso-verde o verde-rosso:
La protanomalia è la funzione deviante dei pigmenti dei coni rossi;
La deuteranomalia è la funzione deviante dei pigmenti dei coni verdi.
Per dare un'idea di come la cecità ai colori influenzi la percezione di una pagina Web, si
possono utilizzare degli opportuni i filtri software disponibili sul sito Colorblind Web Page
Filter1.
Le pagine Web generate possono mostrare le visioni osservate da persone con cecità ai colori.
Disabilità sensoriali: gli audiolesi
Attualmente le informazioni nell'ambito dei siti Web vengono trasmesse anche con l'impiego di
elementi audio.
Quando questi diventano parte consistente e significativa dell'informazione, comportano
problemi di accessibilità per le categorie di utenti con problemi all'udito, che devono
forzatamente rinunciare all'informazione trasmessa con l'audio.
Per questo motivo, l'informazione audio, se rilevante, deve essere trasformata in una forma
alternativa efficace e comprensibile per tutti gli utenti.
Le disabilità dell'udito si suddividono in:
Sordità pre-verbale: riguarda le persone sorde dalla nascita. Queste non riescono a
sviluppare il linguaggio in modo normale senza una terapia riabilitativa;
Sordità peri-verbale: riguarda le persone diventate sorde verso i 3/4 anni. Esse perdono
quasi completamente l'uso della parola se non si utilizzano apposite protesi;
Sordità post-verbale: riguarda le persone diventate sorde dopo la completa acquisizione
della parola. Benché conservino pressoché inalterato il proprio patrimonio linguistico,
spesso viene compromessa la comunicazione verbale.
Disabilità motorie
L'arco delle disabilità di tipo fisico è piuttosto ampio.
1
[http://colorfilter.wickline.org/]
- 24 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Si va da una modesta paralisi su un arto, all'incapacità di controllare i propri movimenti a
causa di spasmi nervosi.
Nel peggiore dei casi la mobilità residua è quasi nulla, tanto che l'interazione col computer può
avvenire solo mediante l'invio di un comando d'assenso, come il battito dell'occhio, il
movimento del capo o il soffio in una cannuccia, per la selezione dell'azione proposta dal
computer con una lista di possibilità.
In tutti questi casi, la difficoltà di accesso al mondo del Web riguarda l'utilizzo dei dispositivi
d'ingresso con cui l'utente invia i comandi.
La difficoltà di accesso al mondo del Web, da parte dei disabili motori, riguarda l'utilizzo dei
dispositivi d'ingresso con cui l'utente invia i comandi, in particolare del mouse e della tastiera.
Nello specifico, il principale problema da superare è l'uso del mouse.
E' indispensabile, quindi, che l'utilizzo del mouse non sia mai essenziale per interagire con i
programmi, fornendo per ogni comando almeno un’alternativa via tastiera. Principio esposto
per altro molto chiaramente nelle WCAG 2.0 1.
La gestione della tastiera diventa, quindi, un aspetto essenziale per poter utilizzare un
computer.
Si pensi alla necessità di:
Ottenere tutti i caratteri con un solo dito o con la leva del caschetto, utilizzato da alcune
categorie di disabili motori;
Ridurre al minimo gli errori involontari, dovuti a tremolio della mano o alla pressione
troppo prolungata del tasto;
Offrire un punto di appoggio al braccio o alla mano, in modo da aumentarne stabilità e
precisione.
La tecnologia ha dato risposte molto valide per ridurre i problemi di accesso dei disabili motori
al Web.
Una delle modifiche più semplici e comuni da apportare alla tastiera è l'applicazione di una
mascherina, una griglia copri-tastiera fissa, di plexiglas o metallo, con dei fori in
corrispondenza dei vari tasti. In questo modo sarà possibile appoggiare la mano sulla tastiera
ed infilare nei fori le dita per premere solo i tasti che interessano.
1
Guideline 2.1: “Make all functionality operable via a keyboard interface”
- 25 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Disabilità cognitive
Le disabilità cognitive sono molteplici e comprendono una numerosa serie di varianti che
possono anche dipendere da altre disabilità fisiche dell’individuo.
Riguardano una vasta varietà di problemi. Si può sommariamente dividerli in:
Deficit di linguaggio primari o secondari;
Deficit cognitivi primari o conseguenti a patologie neurologiche o genetiche;
Disturbi specifici di apprendimento come le dislessia o la disgrafia.
Si può tentare di evidenziare, con molta prudenza, alcuni aspetti comuni relativi alle disabilità
cognitive.
L'utente affetto da tale disabilità farà fatica ad accedere, cioè a capire pagine Web troppo
complesse, o in cui le componenti in movimento siano troppo veloci. Questo perché le sue
capacità residue potrebbero non consentirgli di cogliere fino in fondo tutti gli aspetti
dell'informazione introdotta nella pagina.
Ad esempio, per un disabile cognitivo, un'immagine al posto di una lunga scritta è un modo
migliore e più sintetico per seguire un certo itinerario di navigazione in rete. Gli effetti
lampeggianti, invece, aumentano la difficoltà di comprensione dell'informazione contenuta
nella pagina.
Per quanto riguarda lo sviluppo di contenuti Web, è necessario fare comunque presente che è
spesso impossibile fornire contenuti fruibili da tutti gli utenti con disabilità cognitive, alcune di
queste disabilità sono talmente gravi da non consentire la comprensione neppure di contenuti
chiari e semplici: l'uso delle immagini, per esempio, può risultare utile per talune categorie di
disabilità cognitive, mentre per altre può portare a confusione e problemi nell'apprendimento.
II.5 - Il W3C
Il World Wide Web Consortium (W3C) è un consorzio internazionale, neutrale rispetto ai
venditori, che, grazie al contributo dei suoi membri, guida l’evoluzione del Web, definendo
protocolli comuni che ne favoriscano l’ evoluzione e ne assicurino l’interoperabilità.1
Il W3C, per sua stessa espressione è stato creato “Per guidare il World Wide Web al suo pieno
potenziale sviluppando protocolli e linee guida che garantiscano una crescita a lungo termine
per il Web”2.
1
Oreste Signore: “Handimatica 2004”
“To lead the World Wide Web to its full potential by developing protocols and guidelines that ensure longterm growth for the Web” - [http://www.w3.org/Consortium/about-w3c.html]
2
- 26 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La sua fondazione risale al 1994, ad opera di Tim Berners-Lee, attuale direttore del W3C e
artefice del World Wide Web (WWW).
Gli obiettivi
Il World Wide Web Consortium (W3C) crea gli standard Web. 1
Per portare il Web al suo massimo potenziale definisce lo sviluppo di tecnologie, specifiche,
linee guida, software e strumenti che possano creare un punto di incontro per informazioni,
commercio, ispirazioni, pensiero indipendente e comprensione collettiva.
Tra i punti cardine che scaturiscono da quest’impostazione c’e quello dell’Accesso Universale.
Il W3C definisce il Web come l'universo delle informazioni accessibili in rete (disponibili
attraverso il computer, il telefono, la televisione, o il frigorifero telematico eccetera).
Oggigiorno questo universo permette alla società di fruire di nuove forme di comunicazione
umana e offre nuove opportunità di condividere la conoscenza.
Uno degli scopi principali del W3C è quello di rendere queste opportunità fruibili a tutti,
indipendentemente da eventuali limitazioni determinate da hardware, software, supporto di
rete a disposizione, lingua madre, cultura, posizione geografica, capacità fisiche e mentali.
L'impegno del Consorzio per l'accesso universale è dimostrato da varie attività come:
Internationalization Activity;
Device Independence Activity;
Voice Browser Activity;
Web Accessibility Iniziative (WAI).
Le Raccomandazioni
Il funzionamento del consorzio è regolato da un insieme di regole contenute nel Process
Document (W3CPD), che viene periodicamente verificato e adeguato, dietro accettazione da
parte dei membri, alle esigenze emergenti. Un aspetto essenziale è che le decisioni vengono
prese a seguito di un processo che prevede il raggiungimento del consenso dei partner. Questo
significa che, anche se non sempre è possibile raggiungere l'unanimità, si ha comunque cura di
non prendere decisioni su cui non ci sia accordo da parte di una vasta maggioranza. Tutte le
osservazioni vengono valutate dal punto di vista tecnico. 2
1
2
[http://www.w3c.it/w3cin7punti.html]
Oreste Signore: “Handimatica 2004”
- 27 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il prodotto più visibile dell’attività del Consorzio sono le Recommendation, documenti tecnici
stabili, sui quali si può fare affidamento per sviluppare tecnologie o applicazioni che
costituiscono la base per la realizzazione di sistemi interoperabili.
Le W3C Recommendation sono il risultato di un processo cooperativo, regolato dal Process
Document, che prevede una serie di passi e di rendiconti prodotti. Alcuni documenti sono
riservati ai partecipanti ai gruppi di lavoro, altri sono disponibili per i membri, che votano per
approvarli o modificarli, altri sono pubblici.
Schematicamente possiamo riassumere il processo 1 che porta alla pubblicazione di una
Recommendation, il cosiddetto maturity level di un documento, con una strutturazione a fasi di
questo tipo:
Working Draft (WD): Un documento pubblicato specificatamente per essere valutato
dalla comunità, inclusi i membri del W3C, il pubblico e le altre organizzazioni tecniche.
Generalmente vengono pubblicati diversi Working Draft prima di arrivare all’ultimo
richiamo. La pubblicazione di un Working Draft non indica nessun impegno del W3C a
farlo diventare una Recommendation. I Working Draft sono bozze in fase di sviluppo,
soggetti a discussione e modifica in ogni momento da parte dei membri del gruppo di
lavoro.
Last Call working Draft: Quando il gruppo di lavoro ritiene che siano stati considerati
tutti i commenti e i requisiti tecnici, viene predisposto il documento completo per la
revisione della comunità e viene annunciato l’ultimo richiamo. Va notato che dopo la
scadenza del periodo per l’ultimo richiamo possono passare settimane o mesi prima che
il gruppo di lavoro consideri tutti i documenti e faccia i cambiamenti necessari. Se ci
sono sostanziali modifiche è possibile che i resoconti tecnici vengano considerati in un
ulteriore ultimo richiamo successivo;
Candidate Recommendation (CR): Lo scopo principale di una Candidate
Recommendation è garantire che tutti i resoconti tecnici possano essere implementati.
Il W3C incoraggia gli sviluppatori a utilizzare i resoconti tecnici nei loro progetti. Questo
è un periodo durante il quale la specifica viene revisionata ed implementata;
Proposed Recommendation (PR): Se ci sono sufficienti implementazioni di ogni aspetto
dei resoconti tecnici, allora il W3C li presenta come Proposed Recommendation. Si
tratta di un resoconto tecnico completo ottenuto dopo una attenta valutazione della
stabilità e delle implementazioni;
1
[http://www.w3.org/WAI/intro/w3c-process]
- 28 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Recommendation (REC): Il W3C invia la Proposed Recommendation al comitato
consultivo per la ratificazione finale. Dopo una fase di tempo di almeno quattro
settimane si vota per ratificarla come Recommendation . Un mancato consenso può
riportare il documento allo stato di Working Draft. Una raccomandazione W3C è uno
specifico insieme di linee guida che, dopo il raggiungimento di un ampio consenso, ha
ricevuto la ratifica dei membri del W3C e del direttore. Le raccomandazioni sono simili
agli standard pubblicati da altre organizzazioni.
Nello schema precedente si deve tener conto, come accennato, della possibilità che un
documento possa ritornare ad uno stato precedente in caso di necessità.
Il passaggio da uno stato all’ altro avviene mediante votazione da parte dei membri. Il
passaggio dallo stato di Last Call Working Draft a quello di Candidate Recommendation
comporta una Call for implementations, e il livello di Proposed Recommendation viene
raggiunto solo dopo aver maturato una soddisfacente esperienza implementativa.
Le W3C Recommendation, quindi, hanno sia una verifica teorica (proof of the concept) che una
verifica pratica (proof of implementation), per questo non sono dei meri documenti cartacei,
ma specifiche di cui è stata dimostrata l’efficacia e che sono implementabili con uno sforzo
ragionevole.
Il W3C non è formalmente un organo di standardizzazione, ma una comunità di membri
che cooperano spontaneamente per definire le linee guida e le specifiche, e mantiene stretti
contatti con gli organi di standardizzazione.
Le W3C Recommendation non possono quindi essere definite degli standard in senso proprio,
ma vengono spesso citate come standard di fatto. E’ però importante sottolineare che non
sono originate da posizioni dominanti del mercato, ma sono specifiche tecniche sulle quali è
stato raggiunto, da parte di tutta la comunità del Web, un pieno accordo.
La WAI
WAI1 è l'acronimo di Web Accessibility Initiative, ovvero "Iniziativa per l'Accessibilità del
Web". Si tratta di una sezione del World Wide Web Consortium.
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
1
[http://www.w3.org/WAI/]
- 29 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
utilizzati per produrre e pubblicare contenuti.1
Su queste direttrici, la Web Accessibility Initiative ha sviluppato i 3 principali gruppi di linee
guida, relative ai 3 diversi aspetti che giocano un ruolo critico nel rendere accessibile il Web,
contenuti, strumenti di sviluppo e programmi utente:
Web Content Accessibility Guidelines (WCAG), che spiegano agli autori come creare
contenuti Web accessibili alle persone con disabilità. Per contenuto Web in genere si
intendono le informazioni presenti nella pagina Web, incluso il testo, le immagini, i
moduli, i suoni ed altro2. Queste linee guida sono il cuore di questo lavoro e di loro si
parlerà diffusamente in seguito. Attualmente è in Working Draft la versione 2.0 (27
Aprile 2006)
Authoring Tool Accessibility Guidelines (ATAG), che spiegano come gli strumenti di
sviluppo dovrebbero aiutare i creatori delle pagine Web a produrre dei contenuti che
siano conformi alle WCAG. In oltre le ATAG spiegano come rendere accessibili gli stessi
strumenti di sviluppo in modo che possano essere utilizzati dalle persone disabili 3. Sono
divenute una W3C Recommendation il 3 Febbraio 2000. Attualmente è in Working Draft
la versione 2.0 (7 Dicembre 2006).
User Agent Accessibility Guidelines (UAAG), divenute Recommendation il 17 dicembre
2002, spiegano come rendere i programmi utente (user agent) accessibili per le
persone disabili, in special modo per accrescere l’accessibilità ai contenuti del Web. I
programmi utente includono Web Browser, riproduttori di contenuti multimediali e
tecnologie assistive, cioè il software che alcune persone disabili utilizzano per interagire
con il computer4.
Nel Settembre del 2006 si è aggiunto anche il progetto ARIA per la considerazione delle
caratteristiche dinamiche del Web:
1
Michele Diodati: “Guida all’accessibilità dei siti Web”
“The Web Content Accessibility Guidelines (WCAG) documents explain how to make Web content
accessible to people with disabilities. Web "content" generally refers to the information in a Web page or
Web application, including text, images, forms, sounds, and such”.
[http://www.w3.org/WAI/intro/wcag.php]
3
“The Authoring Tool Accessibility Guidelines (ATAG) documents define how authoring tools should help
Web developers produce Web content that is accessible and conforms to the Web Content Accessibility
Guidelines. The ATAG documents also explain how to make authoring tools accessible so that people with
disabilities can use the tools.” – [http://www.w3.org/WAI/intro/atag.php]
4
“The User Agent Accessibility Guidelines (UAAG) documents explain how to make user agents accessible to
people with disabilities, particularly to increase accessibility to Web content. User agents include Web
browsers, media players, and assistive technologies, which are software that some people with disabilities
use in interacting with computers.” – [http://www.w3.org/WAI/intro/uaag.php]
2
- 30 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Accessible Rich Internet Applications (ARIA) Suite, annunciate come progetto il 26
Settembre 2006. Le WAI-ARIA definiscono come rendere accessibili anche per le
persone con disabilità le caratteristiche avanzate del Web dinamico ad esempio per
strumenti come AJAX e DHTML1. L’obiettivo primario delle ARIA è quello di fornire alla
tecnologia assistiva le informazioni necessarie sui controlli dell’interfaccia, come ad
esempio l’espansione delle barre di navigazione.2.
Le raccomandazioni che più ci interessano in questa sede sono sicuramente le Web Content
Accessibility Guidelines, in italiano "Linee guida per l'accessibilità dei contenuti Web", più
brevemente conosciute come WCAG e giunte attualmente alla versione 1.0, rilasciata dal WAIW3C come documento ufficiale con valore normativo in data 5 maggio 1999.
Da molto tempo è in fase di avanzata fase di elaborazione la versione 2.0 delle WCAG, tuttavia
il loro rilascio definitivo come Recommendation non è ancora avvenuto al momento di redigere
questa tesi.
1
[http://www.w3.org/WAI/intro/aria.php]
“WAI-ARIA defines how to make more advanced features of dynamic content and rich Internet applications
accessible to people with disabilities. A primary focus of WAI-ARIA is providing information about user
interface controls—such as expanding navigation bars—to assistive technology.” –
[http://www.w3.org/WAI/intro/aria.php]
2
- 31 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
III. Metodologie e tecniche di applicazione
Questo capitolo è il cuore dell’intero lavoro.
In esso, più che fornire le specifiche istruzioni di programmazione per migliorare l’accessibilità
del codice, si descrivono le linee guida e le strategie di progetto comuni a tutte le normative in
materia.
Ho deciso di presentare le tecniche universalmente impiegate prima dell’esposizione delle
normative stesse in quanto ne sono, per tutte, il riconosciuto principio ispiratore.
Nel resto di questa esposizione sono stati riportati a titolo esemplificativo alcune porzioni di
codice (X)HTML o CSS. Per il controllo della loro validità sintattica e del loro funzionamento
questi parti sono state testate in Amaya versione 9.53, il browser/editor ufficiale del W3C.
A meno di modifiche dell’ultimo momento dovrebbero essere quindi esenti da errori, per
quanto l’errore umano sia sempre possibile. In tal caso mi scuso in anticipo per eventuali
possibili imprecisioni, e vi invito a segnalarmele.
III.1 - Il linguaggio
Per capire meglio il resto della trattazione è opportuno dare prima almeno i rudimenti
fondamentali dello strumento essenziale con cui ci troviamo a trattare, il linguaggio HTML
(Hyper Text MarkUp Language) il suo successore, l’XHTML (eXtensible HyperText Markup
Language) e i CSS (Cascading Style Sheet), elementi base per costruzione delle pagine Web.
Non essendo questo un manuale di programmazione HTML mi limiterò a fornire gli elementi
essenziali per comprendere il suo corretto utilizzo ai fini di produrre delle pagine ad elevata
accessibilità.
Per chi volesse approfondire la materia sono in commercio numerosissimi testi di istruzione.
Riferimento base è sempre il consorzio W3C per quanto riguarda la definizione del linguaggio
sia HTML1 che XHTML2. Esistono anche delle versioni in italiano della documentazione ufficiale
W3C a cura di Michele Diodati per l’HTML3, e a cura di Patrizia Andronico per l’XHTML4, per
quanto questa non mi sembri in prima lettura una traduzione particolarmente efficace.
1
2
3
4
[http://www.w3.org/TR/html401/]
[http://www.w3.org/TR/xhtml11/]
[http://www.diodati.org/w3c/html401/cover.html]
[http://www.w3c.it/traduzioni/xhtml1-it.html]
- 32 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
HTML
L’HTML (acronimo per Hyper Text Mark-Up Language) è un linguaggio usato per descrivere i
documenti ipertestuali disponibili nel Web. Non è un linguaggio di programmazione, ma un
linguaggio di marcatori, ossia descrive il contenuto di una pagina Web tramite degli appositi
elementi definiti, appunto, marcatori.
È stato sviluppato da Tim Berners-Lee al CERN di Ginevra.
HTML è un linguaggio di pubblico dominio la cui sintassi è stabilita dal World Wide Web
Consortium (W3C), e che è basato su un altro linguaggio avente scopi più generici, l'SGML
(Standard General Markup Language), uno standard per la descrizione logica dei documenti.
Una importante caratteristica di HTML è che esso è stato concepito per definire il contenuto
logico e non l'aspetto finale del documento. Gli sviluppatori di HTML hanno optato per un
linguaggio che descrivesse il contenuto dei documenti dal punto di vista logico, piuttosto che
grafico, demandando poi ai programmi utente il compito di rendere, di trasformare il
documento in maniera opportuna.
Questo significa che non esiste alcuna garanzia che uno stesso documento venga
visualizzato in ugual modo usando due programmi utente differenti o semplicemente su due
elaboratori differenti.
Con il passare del tempo però gli elementi del linguaggio incaricati di indicare una
presentazione ai browser si sono via via moltiplicati fino a deviare l’HTML dall’originale progetto
di marcatore di contenuti.
Questo è avvenuto anche per il fatto che in realtà pochi sviluppatori si occupano di scrivere
una pagina Web con un editor direttamente nel linguaggio HTML. Questo compito è invece
spesso delegato ad un ambiente grafico che permette allo sviluppatore di occuparsi dell'aspetto
finale della pagina senza interagire direttamente con il codice.
La filosofia originale del progetto tuttavia è rinata in questi ultimi anni con l’avvento dei fogli di
stile e con i problemi sollevati dall’accessibilità dei contenuti prodotti da questi strumenti
automatici.
Durante gli anni l'HTML ha subito molte revisioni e miglioramenti. Attualmente l'ultima
versione disponibile è la versione 4.01, resa pubblica il 24 dicembre 1999. Da allora fino ai
giorni nostri non è stata manifestata alcuna intenzione da parte del W3C di apportare ulteriori
modifiche all'HTML, poiché verrà presto sostituito dai nuovi linguaggi XHTML derivati da XML.
Recentemente tuttavia si è incominciato a sentir parlare della versione HTML 5 il cui nome
- 33 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
ufficiale è Web Applications1 1.0 che non è, almeno per ora, una specifica del W3C ma del
WHATWG.
Lo scopo di questo progetto è quello di integrare le applicazioni Web all’interno del linguaggio.
Dato lo stato ancora embrionale della specifica non verrà fatta oggetto di trattazione in questo
lavoro.
Struttura
Ogni documento ipertestuale scritto in HTML deve essere contenuto in un file, la cui estensione
deve essere .htm o .html.
Il componente principale della sintassi di questo linguaggio è l'elemento. Gli elementi sono le
strutture del linguaggio a cui è delegata la funzione di formattare i dati o indicare al Web
browser delle informazioni. Ogni elemento è racchiuso all'interno di tag, uno di apertura ed uno
di chiusura. Quest'ultimo, per certi elementi, è opzionale.
I tag sono dei marcatori (markup) costituiti da una sequenza di caratteri racchiusa da due
parentesi angolari. Spesso le informazioni su cui agisce il tag devono essere racchiuse fra un
tag di apertura ed uno di chiusura, quest'ultimo indicato apponendo il carattere slash (/) dopo
la parentesi angolare aperta. Ad esempio: <strong>testo testo testo</strong>. In questo
caso, il testo compreso tra questi due tag verrà considerato dai browser come più significativo.
Un documento HTML comincia con l'indicazione della DTD (Document Type Definition), la quale
dice al browser l'indirizzo delle specifiche HTML che si vogliono dichiarare per il documento,
indicando quindi, implicitamente, quali elementi, attributi ed entità si possono utilizzare.
Tutte le informazioni contenute nel documento devono essere indicate tra i tag <HTML> e
</HTML>. All'interno di questi due tag la sintassi HTML prevede 2 sezioni racchiuse fra i tag:
<HEAD> e </HEAD>, dove sono indicate le informazioni generali riguardanti l’intero
documento e che non vengono visualizzate dal browser;
<BODY> e </BODY>, dove sono indicate tute le informazioni effettivamente presenti
nel documento da rendere.
Fanno eccezione le strutture costituite a FRAME che non prevedono gli elementi BODY.
Gli elementi
Un elemento HTML deve soddisfare le specifiche della DTD dichiarata.
Gli elementi HTML consistono generalmente di quattro parti:
1
[http://www.whatwg.org/specs/web-apps/current-work/]
- 34 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Un tag di apertura che definisce l'inizio di un elemento;
I suoi attributi e i relativi valori;
Dei contenuti;
Un tag di chiusura, in HTML il tag di chiusura è opzionale per molti elementi, gli
elementi XHTML invece vanno sempre chiusi.
Gli elementi possono rappresentare intestazioni, paragrafi, collegamenti ipertestuali, elenchi,
oggetti multimediali incorporati e diverse altre strutture.
Purtroppo ci sono alcuni elementi che non sono parte di nessun DTD ufficiale, ma sono nativi di
alcuni browser e vengono utilizzati al meglio solo da questi. Tali elementi possono essere
ignorati o visualizzati impropriamente da browser che non li supportano. Si consiglia di non
utilizzare questi elementi a cui cercherò di non fare nemmeno cenno durante la successiva
breve spiegazione.
Molti elementi HTML possono essere nidificati.
Si possono nidificare gli elementi fin quando si vuole ma i tag devono essere chiusi nell'ordine
inverso nel quale sono stati aperti.
La possibilità di nidificare è regolamentata dal fatto che un elemento sia di blocco (block-level)
o di testo (inline).
La distinzione è importante:
Un elemento a livello di blocco provoca una interruzione del flusso, può contenere altri
elementi dello stesso tipo o di tipo inline. Esempi di elementi block-level sono paragrafi,
moduli, liste, tabelle, intestazioni, le citazioni con BLOCKQUOTE e il contenitore generale
<DIV>;
Un elemento inline è a livello di carattere e stringhe di testo. Non provoca interruzioni
nel flusso e può contenere solo altri elementi inline. Esempi di elementi inline sono
quelli per definire caratteristiche del testo come il contenitore <SPAN> e gli elementi
<STRONG>.
Con una forzatura del lessico, gli elementi HTML sono qualche volta chiamati impropriamente
tag.
Elementi Head
<HTML>...</HTML>
Delimita un documento HTML. I due tag sono opzionali in HTML ma alcuni browser e
altre utility possono non riconoscere il documento senza la loro presenza.
<HEAD>...</HEAD>
- 35 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Delimita la sezione d’intestazione (header) del documento che contiene informazioni
sulla pagina. I tag sono opzionali in HTML; se omessi l'esistenza dell'header può
essere dedotto in altri modi.
<BODY>...</BODY>
Delimita il corpo del documento che contiene i contenuti visualizzati nella pagina. Non
sono necessari se il documento è in HTML.
<TITLE>...</TITLE>
Indica il titolo della pagina. Questo elemento è richiesto in ogni documento HTML e
XHTML. Sistemi operativi e programmi utente differenti visualizzano il titolo in maniera
differente. Può essere il nome predefinito quando si salva la pagina o altro. Al
contrario degli altri tag, l'elemento TITLE non permette di contenere altri tag.
<META>...</META>
Delimita i metadata e può essere utilizzato per specificare la descrizione della pagina,
parole chiave e impostazioni.
<LINK>
Specifica qualsiasi tipo di collegamento per un documento, come: collegamenti
precedenti e successivi o versioni di fogli di stile alternative. Il suo uso più comune è
quello di collegare un foglio di stile esterno alla pagina.
<SCRIPT>...</SCRIPT>
Utilizzato per includere JavaScript o altri script nel documento.
<STYLE>...</STYLE>
Specifica una definizione di stile interna per il documento.
Elementi Body
Intestazioni
<H1></H1> fino a <H6></H6>
Intestazioni a diversi livelli. Si utilizza <H1> per il livello massimo di intestazione, la
sezione principale, <H2> per il successivo livello sottostante come una sottosezione,
<H3> per un livello al di sotto del precedente e così via. Il livello più basso
d'intestazione è <H6>.
La maggior parte dei browser Web mostrerà <H1> come un testo grande con un font
differente e <H6> come testo piccolo in grassetto ma questo comportamento può
- 36 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
essere modificato con i fogli di stile CSS. Gli elementi d'intestazione non vanno
utilizzati per creare testo grande o in grassetto: il loro scopo è descrivere la struttura
del documento e l'organizzazione. Alcuni programmi li utilizzano per generare indici e
sommari.
Testo strutturato
Molti elementi HTML sono realizzati per cambiare la struttura o il significato del testo. Alcuni
sono block-level ma la maggior parte sono inline e possono essere inclusi nel normale flusso
del testo.
<P>...</P> (block Level)
Crea un paragrafo. In HTML il tag di chiusura è opzionale.
<BLOCKQUOTE>...</BLOCKQUOTE> (block Level)
Crea una citazione, convenzionalmente visualizzata indentata. L’elemento non è stato
progettato per indentare il testo. Può automaticamente aggiungere delle virgolette.
L'attributo CITE Può fornire la fonte e deve essere un URL completo.
<PRE>...</PRE> (block Level)
Crea testo pre-formattato. Il testo è visualizzato con un font non proporzionato,
esattamente come è stato scritto nel file.
<EM>...</EM> (inline)
Enfasi, convenzionalmente visualizzato in corsivo.
<STRONG>...</STRONG> (inline)
Enfasi forte, convenzionalmente visualizzato in grassetto.
<Q>...</Q> (inline)
Una breve citazione. Può essere visualizzata con virgolette. Le citazioni possono essere
nidificate. L'attributo CITE Può fornire la fonte e deve essere un URL completo.
<CODE>...</CODE> (inline)
Una porzione di codice. Convenzionalmente viene visualizzato con un font monospaziato.
Liste
<DL>...</DL>
Crea un elenco di definizioni formato da termini con la rispettiva definizione.
- 37 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
<DT>...</DT>
Crea un termine di definizione.
<DD>...</DD>
Crea un testo esteso per la definizione.
<OL>...</OL>
<UL>...</UL>
Crea un elenco ordinato (numerato) o non ordinato (puntato). La numerazione
predefinita è quella araba. Il marcatore predefinito è un punto annerito
<LI>...</LI>
Crea un oggetto dell'elenco in liste ordinate o non ordinate.
Tabelle
<TABLE>...</TABLE>
Crea una tabella
<TR>...</TR>
Crea una riga in una tabella
<TH>...</TH>
Crea una cella d'intestazione all'interno di una riga, il contenuto è
visualizzato di solito in grassetto e centrato.
<TD>...</TD>
Crea una cella dati all'interno di una tabella.
<COLGROUP>...</COLGROUP>
Specifica un gruppo di colonne in una tabella.
<COL>
<COL /> (in XHTML)
Specifica gli attributi per una colonna.
<CAPTION>...</CAPTION>
Specifica un titolo per l'intera tabella.
<THEAD>...</THEAD>
Specifica l'intestazione della tabella. Questa sezione può essere ripetuta se la tabella è
divisa in più pagine nella stampa o in altri possibili tipi di resa.
<TBODY>...</TBODY>
Specifica la parte principale della tabella.
- 38 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
<TFOOT>...</TFOOT>
Specifica la parte bassa della tabella. Come <THEAD>, questa sezione può essere
ripetuta se la tabella è divisa in più pagine nella stampa o in altri possibili tipi di resa.
Moduli
L'HTML può solo definire il formato del modulo, in valori immessi dagli utenti vengono trasferiti
e processati lato server.
<FORM>...</FORM>
Definisce il corpo di un modulo.
<SELECT NAME="xxx">...</SELECT>
Crea un menu ad elenco dal quale l'utente può scegliere una sola voce. Può essere
visualizzato come un menu a cascata.
<OPTION>...</OPTION>
Crea una voce nel menu.
<INPUT TYPE="CHECKBOX">
Crea una casella di spunta (checkbox).
<INPUT TYPE="RADIO">
Crea un pulsante di opzione; se più pulsanti di opzione hanno lo stesso nome, l'utente
potrà selezionarne solo uno.
<INPUT TYPE="SUBMIT">
Crea un pulsante d'invio.
<INPUT TYPE="RESET">
Crea un pulsante di reset che ripristina i valori del modulo a quelli iniziali.
<INPUT TYPE="TEXT">
Crea una casella di testo a linea singola.
<TEXTAREA>...</TEXTAREA>
Crea un'area di testo multi-linea, definita dagli attributi COLS per le colonne e ROWS per
le righe. Il testo tra i tag apparirà nell'area di testo al caricamento della pagina.
- 39 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Altri elementi
<SPAN>...</SPAN>
Crea una separazione logica sulla riga. Permette di assegnare a porzioni di testo un ID
o una classe, utilizzabili con i CSS.
<DIV>...</DIV>
Crea un blocco logico di tipo block-level. Viene usato soprattutto per l’impiego
congiunto di una definizione corrispondente nel CSS.
<HR>
<HR /> (in XHTML)
Inserisce una linea orizzontale.
<OBJECT>...</OBJECT>
Include un oggetto nella pagina del tipo specificato dall'attributo TYPE. Può essere
qualsiasi oggetto MIME che il browser riconosce, un plug-in come Flash, o un file
audio.
<PARAM>...<PARAM/> (in XHTML)
Questo tag appare solamente all'interno dell'elemento OBJECT e imposta i parametri per
l'oggetto per esempio larghezza, altezza o URL del contenuto.
Formattazione (sconsigliati)
<B>...</B>
Utilizza il grassetto. Esiste un equivalente CSS: {font-weight: bold;}
<I>...</I>
Usa il corsivo. Esiste un equivalente CSS: {font-style: italic;}
<BIG>...</BIG>
Crea testo più grande. Esiste un equivalente CSS: {font-size: larger;}.
<SMALL>...</SMALL>
Crea testo più piccolo. Esiste un equivalente CSS: {font-size: smaller;}
Collegamenti ed ancore
<A>...</A>
- 40 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Crea un collegamento ipertestuale con l'attributo HREF impostato su un URL; inoltre
l'attributo TITLE può essere impostato per avere un suggerimento a comparsa (tooltip)
d'informazioni sul collegamento.
Quando il puntatore è sul collegamento, di solito si trasforma in una mano con il dito
indice disteso, e il testo in aiuto appare come un suggerimento a comparsa che
sparisce quando il cursore si sposta.
Alcuni browser visualizzano il testo alternativo allo stesso modo, ma è un errore
tecnico.
Alternativamente, l'elemento crea un segnalibro interno usando l'attributo NAME o
l’attributo ID in XHTML, utilizzabile con una chiamata preceduta dal simbolo '#'
nell'URL. Questa tecnica a segnalibro crea dei problemi di compatibilità all’indietro in
XHTML dove l’attributo NAME è proibito.
Immagini
<IMG...>
<IMG... /> (in XHTML)
Include un'immagine con l'attributo SRC, l’attributo ALT fornisce testo alternativo. ALT è
obbligatorio nelle ultime versioni del linguaggio ed è inteso come testo alternativo,
sebbene alcuni browser lo visualizzano come un suggerimento, l'attributo TITLE
dovrebbe fungere da suggerimento.
Vari
<BR>
<BR/> (in XHTML)
Specifica un'interruzione di linea. Il comportamento può essere modificato anche con i
CSS: {break: left|right|all}.
<MAP>...</MAP>
Specifica una mappa lato client.
<AREA>
<AREA/> (in XHTML)
Specifica un'area in una mappa.
<!--...-->
Racchiude un commento. Questo è un tag SGML e non limitato a HTML, quindi può
apparire ovunque nel documento, anche prima del DTD o dopo </HTML>. Un browser
non visualizzerà nessun commento. La chiusura ">" è necessaria.
- 41 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Frame
Un documento HTML può contenere un’intestazione o un corpo o un’intestazione e un FRAMESET,
ma non entrambi.
<FRAMESET>...</FRAMESET>
Delimita il FRAMESET. La disposizione dei frame è data da un elenco separato da virgola
negli attributi ROWS e COLS.
<FRAME>...</FRAME>
Racchiude un singolo frame, o regione, all'interno del FRAMESET. Attraverso
l'attributo SRC si può collegare all'interno un documento.
<NOFRAMES>...</NOFRAMES>
Contiene un normale elemento <BODY> con i figli che appariranno nel browser
Web che non supporta i frame.
Unità per le dimensioni
Segue una lista delle unità di misura usate per definire dimensioni, spazi o distanze. Include
dimensioni assolute e relative, in genere rispetto alle dimensioni nell’elemento genitore. Nella
pratica comune solo alcune di queste sono realmente usate.
Assolute:
o
in (inches - pollici): classica misura del sistema metrico americano. Praticamente
nullo il suo valore su un supporto come un browser Web. 1 pollice è equivalente
a 2.54 cm
o
cm (centimetri): stesso discorso visto per i pollici, la difficoltà maggiore sta nella
resa su monitor.
o
mm (millimetri): come per le misure precedenti.
o
pt (points - punti): unità di misura tipografica destinata essenzialmente a
definire la dimensione dei font. Corrispondono a 1/72 di pollice.
o
pc (picas): unità poco usata. 1 pica equivale a 12 punti.
Relative:
o
em (em-height). L'unità em è uguale al valore calcolato della proprietà FONT-SIZE
dell'elemento nel quale è usata. Quando em si trova nel valore della stessa
proprietà FONT-SIZE, esso fa riferimento alla grandezza del font carattere
dell'elemento genitore. Può essere usata per la misurazione orizzontale o
verticale.
o
ex (ex-height, a volte chiamata anche ampiezza-quadrato o quad-width nei testi
tipografici.). L'unità ex è definita dalla 'x-height' del font carattere. La x-height è
così chiamata perchè è spesso uguale all'altezza della "x" minuscola. Un ex è
ovviamente definito anche per gli insiemi di caratteri che non contengono una x.
- 42 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
o
px (pixels): relativo al dispositivo di visualizzazione. Unità di misura ideale su
monitor. E' quella più usata e facile da comprendere ma non viene trattata in
maniera simile da tutti i browser.
o
Percentuale. Un valore espresso in percentuale è da considerare relativo rispetto
ad un altro valore, in genere quello espresso per l'elemento parente.
Nella scelta delle dimensioni occorre tenere presente l’incapacità di Internet Explorer di
ridimensionare i caratteri specificati in pixel, a differenza degli altri browser.
Una buona scelta rimane dunque quella di adottare le unità percentuali o l'unità em, prestando
attenzione alle proprietà degli elementi genitori.
XHTML
Nella sezione precedente ho trattato brevemente gli elementi del linguaggio HTML
introducendo già delle segnalazioni dove fossero presenti delle variazioni per l’XHTML.
Molti di questi elementi sono comuni anche per il naturale successore, seppur con lievi
differenze di sintassi.
Questo perché, in effetti, l’XHTML non è altro che una evoluzione, una formattazione del
linguaggio precedente nelle regole strutturali di un più generico progetto della famiglia di
linguaggi l’XML, a sua volta sottoinsieme delle strutture SGML.
Vale la pena dare qualche piccola spiegazione su questa gerarchia di linguaggi.
L’SGML è un metalinguaggio, cioè un linguaggio per descrivere i linguaggi a marcatori, in
particolare quelli usati per i documenti in formato elettronico, sia per la stampa che per
l’interscambio tra applicazioni.
Vista la sua ricchezza espressiva, risulta a volte piuttosto complesso, per questo motivo si
deciso di ricavarne un sottoinsieme meno complesso che ne mantenga però la potenza e la
flessibilità, questo è l’XML.
Integrando l’HTML nelle regole dell’XML è nato l’XHTML.
L’HTML, in vista di questo passaggio, si era già evoluto nella sua ultima versione 4.01 del
dicembre 1999 predisponendo il passaggio all XHTML in maniera pressoché indolore avendo già
realizzato il supporto per i fogli di stile, gli script, le internazionalizzazioni e tabelle più
sofisticate.
In effetti, tra l’ultima versione HTML (la 4.01) e la prima del successore XHTML (la 1.0) non
esistono modifiche sostanziali.
Entrambi prevedono la dichiarazione a tre tipi di compatibilità DTD:
TRANSITIONAL (include elementi deprecati);
FRAMESET (per usare i FRAMESET al posto del BODY);
STRICT (contiene solo elementi che non sono influenzati dai CSS).
- 43 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Le modifiche sono essenzialmente sintattiche, dovute al fatto di essere entrati a far parte della
famiglia di linguaggi XML e di doverne quindi rispettare le regole.
Poiché XHTML è un'applicazione XML, certi usi che erano perfettamente legali in HTML 4.0
basato su SGML devono essere cambiati.
Le conseguenze più significative del passaggio alla nuova famiglia sono:
I documenti devono essere ben formati:
Ben formato è un concetto introdotto da XML. Sostanzialmente questo significa che tutti
gli elementi devono avere il tag di chiusura o devono essere scritti in una forma corretta
come descritto sotto, e che tutti gli elementi devono essere annidati senza
sovrapposizioni.
Sebbene i costrutti con strutture nidificate sovrapposte siano illegali anche in SGML da
cui è derivato l’HTML, questa sintassi è stata ampiamente tollerata dai browser
esistenti. In XHTML non è consentita.
Gli elementi e i nomi degli attributi devono essere in lettere minuscole:
I documenti XHTML devono usare lettere minuscole per tutti gli elementi HTML e per i
nomi degli attributi. Questa differenza è necessaria perchè XML è sensibile alle
minuscole e alle maiuscole, per esempio <LI> e <LI> sono tag diversi.
Gli elementi non vuoti richiedono il tag di chiusura:
In HTML 4.0 basato su SGML alcuni elementi potevano omettere il tag di chiusura, in
modo tale che gli elementi che seguivano implicavano tale chiusura. Questa omissione
non è permessa in XHTML basato su XML. Tutti gli elementi, ad eccezione di quelli
dichiarati come EMPTY nella DTD devono avere un tag di chiusura ed anche per costoro
va seguita una sintassi particolare.
I valori degli attributi devono sempre essere compresi fra doppi apici:
Tutti i valori degli attributi devono essere compresi fra doppi apici, inclusi i valori
numerici.
Minimizzazione degli attributi:
XML non supporta la minimizzazione degli attributi. I valori degli attributi accoppiati
devono essere scritti completamente. Ogni attributo deve avere un valore. Alcuni
attributi di HTML non hanno un valore. E' il caso dell'attributo SELECTED. In XHTML anche
questi attributi devono essere valorizzati. I nomi degli attributi come COMPACT e CHECKED
non possono essere presenti negli elementi se non viene specificato il loro valore.
Elementi vuoti:
Gli elementi vuoti devono avere un tag di chiusura o il tag iniziale deve terminare con
/>. Per esempio <BR/> o <HR></HR>.
Manipolazione di spazi bianchi nei valori degli attributi.
Nei valori degli attributi, i programmi utente elimineranno alla lettura gli spazi bianchi
iniziali e finali dai valori degli attributi e sostituiranno la sequenza di uno o più spazi
- 44 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
bianchi (compreso il salto di linea) con un singolo spazio tra le parole (un carattere di
spazio ASCII per le scritture di tipo occidentale).
Gli elementi con attributi ID e NAME.
HTML 4 definisce l'attributo NAME per gli elementi A, APPLET, FORM, FRAME, IFRAME, IMG, e
MAP.
HTML 4 introduce anche l'attributo ID. Entrambi questi attributi sono disegnati per
essere usati come identificatori di elementi.
Con l'obiettivo di assicurare che i documenti XHTML 1.0 siano documenti XML benformati, i documenti XHTML 1.0 devono usare l'attributo ID quando definiscono gli
identificatori di elementi, anche con gli elementi che storicamente usavano anche un
attributo NAME.
Il passaggio a ID non pone problemi nei browser più recenti, ma con altri non funziona.
In questo caso e se la compatibilità all'indietro è assolutamente necessaria, la stessa
specifica XHTML 1.0 suggerisce di usare entrambi gli attributi, anche se ciò è contro le
regole.
In XHTML 1.0 l'attributo NAME di questi elementi è comunque deprecato mentre è stato
del tutto rimosso in XHTML 1.1.
Uno degli argomenti più delicati con l’XHTML è la gestione dei linguaggi di programmazione,
tradizionalmente incorporati nel documento con il tag <SCRIPT> inserito nella sezione
<HEAD>....</HEAD>.
In (X)HTML il tag <SCRIPT> serve a incorporare nel documento codice di programmazione. Il
linguaggio più comunemente usato è JavaScript.
Il problema sorge quando nello script si utilizzano dei caratteri che possono essere fonte di
equivoci (sensitive characters nella definizione XHTML). Si tratta di caratteri che possono
provocare confusione e fraintendimenti perchè il processore XML li interpreta in un modo
mentre nel linguaggio di scripting hanno altro significato.
Ad esempio in JavaScript “>” significa "maggiore di", in XML indica la chiusura di un tag.
Il W3C suggerisce due vie, ma entrambe presentano punti deboli:
Usare le sezioni CDATA.
Nella specifica si suggerisce di racchiudere gli script all'interno di una sezione CDATA.
Esse vengono usate in documenti XML per racchiudere blocchi di testo contenenti
caratteri che potrebbero essere interpretati come elementi di marcatura.
Una sezione CDATA inizia con la stringa <![CDATA[ e termina con ]]>.
Il punto debole di questo approccio è che mediamente i browser non gestiscono bene le
sezioni CDATA.
Usare script esterni.
Si potrebbe ovviare scrivendo gli script in un file esterno e collegandolo al documento.
In tal caso sorgerebbero problemi qualora bisognasse modificare lo script.
- 45 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
A titolo riassuntivo una lista completa di elementi e del loro relativo uso con le varie versioni è
contenuta nel sito del W3 Schools1.
XHTML 1.1
Con la versione 1.1 XHTML si libera definitivamente della retro compatibilità TRANSITIONAL e
FRAMESET
per implementare solo una struttura pulita sul modello STRICT del precedente 1.0.
Quindi non sono più contemplati elementi come <APPLET>, <BASEFONT>, <CENTER>, <DIR>,
<FONT>, <FRAME>, <FRAMESET>, <IFRAME>, <ISINDEX>, <MENU>, <NOFRAMES>, <S>, <STRIKE>,
<U>.
A parte la definitiva esclusione dell’attributo NAME a favore di ID, anche l’attributo LANG è
sostituito con l’attributo XML:LANG.
Per il resto la sintassi è identica alla versione 1.0 STRICT.
Cambia invece nel concetto di modularizzazione. La DTD XHTML 1.1 non contiene una lista di
elementi e attributi con le regole che ne definiscono l'uso. È invece costituita da diverse
dichiarazioni che includono altrettanti moduli. Le specifiche sui moduli XHTML fanno parte di
un'altra raccomandazione, quella sulla modularizzazione di XHTML.
XHTML 2.0
La versione 2.0, non ancora rilasciata, si trova allo stato di Working Draft del 26 Luglio 2006 e
si annuncia come un grosso passo in avanti rispetto le specifiche attuali.
Le differenze maggiori possono essere anticipate già dal documento di bozza 2:
Introduzione del tag SECTION, per rappresentare meglio la struttura del documento che
potrà essere diviso in sezioni, appunto (header, contenuto, footer… ecc.) affiancando le
intestazioni H1..H6;
Modifica del tag P, che adesso si avvicinerà ancora di più all’idea comune di un
paragrafo, con la possibilità di inserire al proprio interno liste, tabelle, ed altri elementi
simili, cosa attualmente impossibile;
Introduzione del tag NL, per le navigation lists: i cosiddetti menu di navigazione;
L’attributo SRC potrà essere utilizzato con qualsiasi elemento. Sarà possibile quindi
indicare l’indirizzo di una risorsa esterna come un’immagine da caricare al posto
dell’elemento indicato. Se la risorsa non fosse disponibile, sarà visualizzato il normale
contenuto definito nel tag;
1
2
[http://www.w3schools.com/tags/default.asp]
[http://www.w3.org/TR/xhtml2/introduction.html#s_intro_differences]
- 46 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L’attributo HREF potrà essere associato a qualsiasi elemento. In questo modo sarà
possibile indicare ad esempio l’indirizzo di un collegamento direttamente da un tag LI,
senza usare il tag A.
Altro punto nodale è la compatibilità con i browser attuali non del tutto garantita con le nuove
specifiche.
Così come viene specificato nel documento ufficiale1 del W3C, grazie all’XML e ai fogli di stile,
una compatibilità stretta con i vecchi browser non viene ritenuta necessaria dal momento che
un browser XML compatibile, e lo sono il 95% dei browser in uso, può comunque elaborare il
nuovo linguaggio senza essere aggiornato. Molto del codice XHTML 2.0 gira anche nei browser
esistenti, molto ma non tutto, in special modo tabelle e moduli (form).
CSS
I fogli di stile a cascata (dall'inglese CSS Cascading Style Sheet) sono un insieme di
dichiarazioni impiegate per definire l'aspetto presentazionale delle pagine (X)HTML .
La loro creazione, avvenuta nel 1996 si è resa necessaria per separare i contenuti, mantenuti
nelle pagine (X)HTML dalla presentazione inclusa invece nei fogli di stile.
Con i CSS vengono implementate alcune fondamentali migliorie:
Alleggerimento del peso della pagina (X)HTML.
Se confrontata con una pagina che adotta il linguaggio CSS, una pagina che non lo
adotta è in genere più pesante (in termini di bit) in un rapporto che spesso raggiunge il
200%. Inoltre le istruzioni CSS possono essere raccolte in un file esterno che rimane
memorizzato nella cache del browser, riducendo ulteriormente la quantità di dati che i
server devono trasmettere;
Le informazioni presentazionali per un intero sito possono essere mantenute ed
aggiornate rapidamente e facilmente in un unico file;
Standardizzazione del codice (X)HTML.
Un codice non aderente agli standard, ridondante e confuso con dei tag di
presentazione arbitrari comporta infatti molto lavoro aggiuntivo per i browser, che
devono cercare di correggere ed interpretare, per quanto possibile, direttive arbitrarie;
Utenti differenti possono avere fogli di stile differenti, ad esempio impostazioni a
caratteri grandi per ipovedenti o impaginazioni ridotte per il piccolo display degli
smartphone;
1
[http://www.w3.org/TR/xhtml2/introduction.html#s_intro]
- 47 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Compatibilità anche futura con nuovi programmi utenti tra cui computer palmari e gli
smartphone o i dispositivi speciali come stampanti e periferiche per disabili.
Uno speciale foglio CSS può essere progettato appositamente per questi dispositivi
consentendo di svincolare completamente i contenuti dalle presentazioni e adattando i
primi a dispositivi speciali.
Questa ultima funzionalità dei CSS da loro la possibilità di essere applicati solo sui dispositivi
(media) specificati dall'autore. La sintassi (X)HTML da utilizzare è la seguente:
link rel="stylesheet" type="text/css" href="foglio.css" media="screen">
Il codice precedente associa il foglio di stile esclusivamente, almeno in teoria, ai browser
standard per computer desktop e portatili. I valori dell'attributo media sono i seguenti:
ALL:
tutti i dispositivi;
AURAL:
BRAILLE: finalizzati le tastiere Braille;
EMBOSSED:
finalizzati alle stampanti Braille;
HANDHELD:
finalizzati ai dispositivi palmari e smartphone;
PRINT:
PROJECTION:
SCREEN:
TTY:
finalizzati a sintetizzatori vocali;
finalizzati alle impaginazioni o le anteprime di stampa;
finalizzati ai proiettori per le presentazioni;
finalizzati essenzialmente agli schermi dei computer;
finalizzati per le telescriventi, i terminali o i dispositivi portatili con limitate capacità
di visualizzazione;
TV:
finalizzati ai televisori.
Sebbene il numero dei dispositivi gestibili tramite CSS sia notevole, soltanto i primi tre sono
supportati in maniera sufficiente, e neanche da tutti i browser. Il supporto più completo per
queste associazioni è fornito probabilmente da Opera.
Sviluppo storico
Come si è accennato, HTML è nato come un linguaggio strutturale e non presentazionale.
Con il tempo però e con lo sviluppo del Web gli autori hanno voluto produrre delle pagine
sempre più accattivanti e di impatto.
Per permettere meglio di definire l'aspetto delle pagine, dal 1993 in poi Netscape Navigator ed
Internet Explorer, i due browser che si disputavano gli utenti nella nota guerra dei browser,
presentarono tag presentazionali proprietari, non aderenti agli standard e non compatibili con i
browser concorrenti. Un esempio di questi tag è <FONT>.
La crescita di questi strumenti è stata tale da snaturare la filosofia strutturale a marcatori del
HTML.
- 48 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per tentare di risolvere questa situazione, nel 1996 il W3C emanò le specifiche CSS 1. I CSS 1
erano un valido sistema per separare contenuto dalla presentazione. La base di questo
linguaggio, infatti consisteva nel fatto che il contenuto sarebbe stato sempre definito dal codice
(X)HTML, mentre la formattazione si sarebbe trasferita su un codice completamente separato,
il CSS appunto.
I richiami tra i due codici venivano effettuati tramite due particolari attributi: CLASS e ID.
Queste specifiche erano una semplice ed efficace soluzione al problema ma nonostante le loro
grandi potenzialità non ebbero successo a causa della mancanza di browser in grado di
supportarli.
Per includere nuove funzionalità e rendere i CSS un linguaggio ben supportato, nel 1998 il W3C
emanò le specifiche CSS 2 e nel 2004 le specifiche CSS 2.1.
I CSS 2 sono la naturale evoluzione dei CSS 1 ed offrono potenti soluzioni anche per i
programmi utente particolari, con la possibilità di creare fogli di stile separati per i dispositivi
specifici come visto in precedenza.
La comparsa di Internet Explorer 5, di Firefox e di Opera 7, i CSS 2 hanno potuto avvalersi di
browser in grado di interpretarli e sono quindi entrati a far parte del codice di molti siti Web.
In questo momento sono in studio le specifiche CSS 3 che non sono state ancora rilasciate,
consiglio di consultare la pagina del W3C in proposito1. I CSS 3 dovrebbero presentare
soluzioni per la correzione di alcuni difetti di interpretazione di Internet Explorer, migliorie nella
gestione degli sfondi e una soluzione per realizzare i bordi arrotondati la cui realizzazione
interessa i progettisti di siti Web da tempo.
Le regole
I CSS hanno una sintassi molto semplice e derivata dai linguaggi di programmazione.
Un foglio di stile è costituito da una serie di regole
Una regola consiste in un selettore seguito da un blocco di dichiarazione che a sua volta
contiene una o più dichiarazioni formate dalla coppia proprietà:valore secondo la sintassi:
selettore
{
proprietà1 : valore1;
proprietà2 : valore2, valore3;
}
Il blocco di dichiarazione è delimitato da parentesi graffe e una dichiarazione termina con un
punto e virgola (;). La proprietà è separata dal valore associato ad essa da due punti (:).
1
[http://www.w3.org/Style/CSS/current-work]
- 49 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Lo schema di un intero CSS è quindi il seguente:
Regole
o
Selettori separati da virgole;
o
Blocco di dichiarazioni racchiuso tra parentesi graffe;
Dichiarazioni separate da punto e virgola;
Proprietà;
Separatore (:);
Valore.
Possono essere introdotti i commenti secondo la sintassi del linguaggio “C”:
/* commento */
La sintassi del CSS non considera gli spazi bianchi, si possono scrivere le regole ed indentarle
nella forma che si ritiene più adatta. Tutti i fogli di stile CSS non sono sensibili alle maiuscole e
alle minuscole (case-insensitive), eccetto per le parti che non sono sotto il controllo dei CSS.
I selettori
Nei CSS i selettori sono utilizzati per dichiarare a quali elementi si deve applicare lo stile o gli
stili indicati.
Ve ne sono di diverse tipologie:
Selettori di tipo:
applicano la regola a tutti gli elementi della pagina del tipo determinato. Con l’asterisco
si applica a tutti gli elementi.
ex: BODY {[...]} o P {[...]};
Selettori di classi:
applicano la regola a tutti gli elementi della pagina che presentano la proprietà
CLASS="nome_classe".
ex: .nome_classe {[...]};
Selettori di identificatori:
applicano la regola all'elemento della pagina che presenta la proprietà
ID="nome_identificatore".
Solo un elemento in tutta la pagina può corrispondere ad un
identificatore.
ex: #nome_identificatore {[...]};
Selettori di pseudoclassi:
Le pseudoclassi identificano elementi in base alle loro proprietà:
o
FIRST-CHILD
individua un elemento solo se è il primo figlio dell'elemento padre.
ex: div:FIRST-CHILD {[...]};
- 50 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
o
LINK
e VISITED si applicano ai collegamenti. La prima identifica i collegamenti non
visitati, la seconda quelli visitati.
ex: a:LINK {[...]};
o
ACTIVE, FOCUS
e HOVER identificano gli elementi solo in particolari condizioni, la
prima se l'elemento è attivo, la seconda se è selezionato, la terza se il puntatore
è sopra di lui.
ex: p:HOVER {[...]};
o
LANG
si utilizza per identificare gli elementi di una certa lingua ma il suo supporto
è esiguo;
Selettori di pseudo-elementi:
Gli pseudo-elementi identificano solo una parte di un elemento, senza la necessità di
utilizzare la marcatura (X)HTML:
o
FIRST-LINE
individua solo la prima linea di un paragrafo;
Ex: P:FIRST-LINE {[...]};
o
FIRST-LETTER
o
BEFORE
individua solo il primo carattere di un elemento;
e AFTER sono due pseudo-classi utilizzate nella creazione dei contenuti
generati. Non individuano un elemento, ma una posizione dove creare i
contenuti. Sono poco utilizzate, dato il mancato supporto di Internet Explorer;
Selettori di discendenza, figlio e fratello:
Identificano solamente gli elementi che si trovino in una particolare condizione di
discendenza nella struttura (X)HTML della pagina:
o
Il selettore di discendenza identifica solo gli elementi contenuti in altri elementi.
Ex: P SPAN {[...]};
o
Il selettore figlio identifica solo gli elementi che siano contenuti direttamente
nell'elemento padre.
Ex: DIV > p {[...]};
o
Il selettore fratello identifica solo il primo elemento che abbia lo stesso grado di
parentela di un altro.
Ex: H1 + p {[...]};
Selettori di attributi:
Il selettore di attributi permette di identificare elementi (X)HTML in base ai loro
attributi.
Ex: a[TITLE=Esempio]{[...]}.
I discendenti di un elemento ereditano i valori delle proprietà associate all'antenato, a meno
che non sia loro applicata una regola più specifica.
- 51 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Le proprietà
Le proprietà CSS sono molto numerose. Le più utilizzate sono:
BACKGROUND.
Definisce lo sfondo di un elemento. È la somma delle proprietà più
specifiche:
o
BACKGROUND-ATTACHMENT;
o
BACKGROUND-COLOR;
o
BACKGROUND-IMAGE;
o
BACKGROUND-POSITION;
o
BACKGROUND-REPEAT;
BORDER.
Definisce il bordo di un elemento. È la somma delle proprietà più specifiche:
o
BORDER-COLOR;
o
BORDER-STYLE;
o
BORDER-WIDTH;
COLOR.
Definisce il colore del testo di un elemento. Per definire lo sfondo si utilizza la
proprietà BACKGROUND;
FLOAT.
Questa proprietà definisce un blocco fluttuante che permette la disposizione di
altri elementi ai suoi lati;
FONT.
Definisce le proprietà del carattere. È la somma di proprietà più specifiche tra cui:
o
FONT-FAMILY;
o
FONT-SIZE;
o
FONT-WEIGHT;
MARGIN
e PADDING. Definiscono lo spazio circostante gli elementi. La prima lo spazio
esterno ai bordi, la seconda quello interno;
TEXT-ALIGN.
Definisce l'allineamento del testo;
I valori
Se non specificata, una proprietà assume i valori predefiniti di ogni browser. Altrimenti si
possono assegnare dei valori specifici:
INHERIT:
La stringa inherit specifica che la proprietà deve ereditare il valore dagli elementi da cui
l'elemento discende;
AUTO:
La stringa auto indica che il browser deve utilizzare il suo valore di default;
numerico:
Se i numeri sono contraddistinti da un'unità di misura è necessario che tale unità sia
espressa, tranne che nel caso dello zero. Tra il numero e l'unità non devono esserci
spazi;
- 52 -
percentuali;
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
colori:
I colori possono essere indicati con più di una modalità. Ad esempio il colore arancione
può essere indicato con #ff6600, #f60, rgb(255,102,0), rgb(100%,40%,0%);
URI:
L'URL viene indicato nelle forme url(http://esempio.it/file.html),
url("http://esempio.it/file.html");
Font:
I CSS permettono di indicare nella proprietà font-family più di un font. In questo modo
il browser utilizzerà il primo che troverà installato sul sistema operativo. La
dichiarazione utilizza questa sintassi:
p {font-family : Arial, Verdana, sans-serif;};
Compatibilità
Occorre ricordare che allo stato attuale dei fatti, i browser che possono vantare una piena
compatibilità con le specifiche CSS sono ben pochi se non addirittura nessuno:
Internet Explorer: E’ attualmente il browser più diffuso e il suo supporto molto scarso
dei CSS è probabilmente il maggior freno al loro sviluppo. Explorer presenta infatti molti
bachi nella formattazione delle pagine, che le rendono diverse da quelle ottenute con
altri browser. In aggiunta ai bachi, Explorer non supporta assolutamente alcune porzioni
delle specifiche CSS 2. Le mancanze più gravi sono l'assenza di supporto per i contenuti
generati e per il selettore di attributo. Explorer considera in maniera fissa le dimensioni
riportate in pixel. Dalla versione 7 include un ingranditore completo;
Firefox e Netscape: Questi browser si basano su un motore Gecko che ha un ottimo
supporto dei CSS 1 e 2 ed è per questo spesso utilizzato nella verifica della resa delle
pagine Web. Permettono l’uso di fogli di stile alternativi;
Opera: Offre un ottimo supporto dei CSS 1 e 2. Opera offre inoltre un'opzione che
permette all'utente di disattivare i fogli di stile, usarne di propri o quelli alternativi.
Fornisce anche l’ingrandimento completo della pagina, immagini incluse.
Safari e Konqueror: Usano KHTML che è attualmente il motore che offre il maggior
supporto ai CSS, offrendo una parziale interpretazione anche dei CSS 3.
Errori comuni
Vorrei riportare un breve elenco di punti su cui fare attenzione nella stesura del codice CSS,
sono errori comuni nella scrittura che conviene tenere sotto controllo. Spesso uno stile non
viene applicato proprio perché la corrispondente regola contiene delle scorrettezze:
Mancanza del punto e virgola finale che chiude la dichiarazione di una proprietà;
Mancanza della parentesi graffa che chiude un elenco di proprietà;
Un colore dichiarato in valori esadecimali non preceduti dal simbolo '#';
- 53 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La famiglia generica di caratteri senza le grazie sans-serif, dichiarata senza il trattino
separatore;
Nomi di CLASS e ID non validi;
Un commento (/* ... */) aperto e non chiuso, o viceversa.
Altre imperfezioni rendono invece il codice corretto, ma producono dei risultati che potrebbero
non essere in linea con l’accessibilità, tra cui:
La mancata indicazione conclusiva di una famiglia di caratteri generica;
La mancata definizione del colore di primo piano se è stato definito il colore di sfondo, e
viceversa;
L'uso di dimensionamenti fissi in luogo di quelli relativi e percentuali.
Una interessante esposizione di questi concetti è contenuta in un articolo1 di Michele Diodati.
III.2 - L’accessibilità in 10 punti
Dopo aver visto una sintetica esposizione degli elementi del linguaggio entriamo nel vivo del
problema dell’accessibilità.
Un primo approccio può essere quello sintetico e riassuntivo proposto dallo stesso W3C il quale
mette a disposizione una sezione2 che riassume in 10 punti guida le pratiche essenziali
dell’accessibilità.
Sono i cosiddetti quicktips, ossia suggerimenti essenziali per consentire a chiunque gestisca siti
Web di avere sott’occhio i concetti principali delle WCAG 1.0.
Suggerimenti rapidi.
È bene far presente che questi suggerimenti rapidi non sostituiscono né le WCAG 1.0 né
l’elenco dei punti di controllo,come ricorda una breve nota introduttiva nella stessa pagina che
li presenta.
Li riporto qui sinteticamente nella traduzione ufficiale delle pagine italiane 3 del consorzio.
Brevi consigli per creare dei siti Web accessibili:
Immagini ed animazioni:
Utilizzare l'attributo ALT per descrivere la funzione di ogni elemento grafico;
1
2
3
[http://www.diodati.org/scritti/2004/guida/ele_acc36.asp]
[http://www.w3.org/WAI/References/QuickTips/]
[http://www.w3.org/WAI/References/QuickTips/qt.it.htm]
- 54 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Immagini ciccabili:
Utilizzare l'elemento MAP e descrivere le zone attive;
Multimedia:
Fornire sottotitoli e trascrizioni per l'audio, e descrizione di filmati;
Collegamenti ipertestuali:
Utilizzare enunciati che conservino il loro senso al di fuori del contesto. Per esempio,
evitare “cliccare qui”;
Organizzazione:
Utilizzare titoli, liste e una struttura coerente. Utilizzare CSS per l'impaginazione;
Figure e diagrammi:
Descriverli all'interno della pagina o utilizzare l'attributo LONGDESC.
Script, applet e plug-in:
Fornire una pagina alternativa quando tali funzionalità sono inaccessibili o non
supportate;
Cornici (frame):
Utilizzare NOFRAMES e titoli significativi;
Tabelle:
Facilitare la lettura linea per linea. Riassumere;
Verificare il lavoro:
Validare. Utilizzare gli strumenti, la lista di controllo e le linee guida del W3C:
http://www.w3.org/TR/WCAG.
Commento
Un interessante ed efficace commento a questi dieci comandamenti dell’accessibilità dei
contenuti è stato presentato da Roberto Castaldo in un lavoro1 finalizzato alle specifiche
esigenze dell’e-banking.
Vale la pena riportare i tratti essenziali di quest’articolo per commentare direttamente i
suggerimenti esposti.
1 - Immagini e animazioni.
Utilizzare l'attributo ALT per descrivere la funzione di ogni elemento grafico.
Un problema per l’accessibilità è costituito dal mancato utilizzo dell'attributo ALT.
Questo attributo consente di specificare un testo alternativo per molti dei componenti
1
[http://www.webaccessibile.org/argomenti/documento.asp?DocID=440]
- 55 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
grafici e risulta perciò molto utile per tutti coloro che navigano con browser in modalità
solo testo o usano tecnologie assistive che utilizzano il testo ALT come descrizione della
relativa immagine.
L’attributo ALT è richiesto principalmente per immagini che necessitano di descrizione,
mentre per le immagini decorative è inutile inserire descrizioni inutili, in tal caso è
sufficiente lasciare l’attributo vuoto.
Per quanto riguarda invece l’uso di immagini animate, ne è sconsigliato l’utilizzo in
quanto può essere pericoloso per utenti che soffrono di crisi epilettiche, in special
modo se il cambiamento della GIF è troppo rapido o non può essere bloccato.
2 - Immagini cliccabili.
Utilizzare l'elemento MAP e descrivere le zone attive.
Le mappe immagine permettono di associare diverse parti di un'immagine a diversi
collegamenti ipertestuali. Le mappe immagini hanno una vera ragione di essere
quando il testo non può svolgere lo stesso compito con la stessa efficacia, come ad
esempio in una selezione da una mappa geografica. In tal caso è necessario
predisporre le mappe immagine in modo che siano fruibili anche da utenti che non
possono visualizzare la grafica.
Le soluzioni a questo problema sono principalmente due: l’utilizzo dell’attributo ALT per
gli oggetti definiti come aree sensibili ed un’esposizione lineare delle possibilità della
mappa con normali collegamenti ipertestuali ridondanti.
3 - Multimedia.
Fornire sottotitoli e trascrizioni per l'audio, e descrizione di filmati.
Eventuali file audio necessitano di una trascrizione per utenti non udenti. Per fruire dei
contenuti visivi di un filmato è necessario applicare delle tecniche del cosiddetto
captioning, una speciale titolazione che consente di ottenere una lettura descrittiva
delle azioni presentate nei filmati.
4 - Collegamenti ipertestuali.
Utilizzare enunciati che conservino il loro significato al di fuori del contesto. Per esempio,
evitare diciture come “clicca qui”.
I testi dei collegamenti devono essere chiari anche per utenti che, a causa della loro
disabilità, non possono dedurre il significato e il riferimento dal contesto. L’utilizzo di
testi come “clicca qui” per i collegamenti è scorretto, soprattutto se non accompagnato
da un’ulteriore descrizione tramite l’attributo TITLE.
Evitare il sovraffollamento di collegamenti in una pagina.
- 56 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
5 - Organizzazione.
Utilizzare titoli, liste e una struttura coerente. Utilizzare CSS per l'impaginazione.
Uno dei maggiori difetti dei siti presenti sul Web è l’errato utilizzo della sintassi del
codice della pagina. E’ necessario produrre un codice (X)HTML pulito e validato
secondo gli standard W3C con l'utilizzo dei fogli di stile (CSS) per l'impaginazione
grafica dei contenuti.
La logica di navigazione interna al sito deve essere facilmente comprensibile e fruibile
dagli utenti, se si utilizzano, ad esempio, acronimi e abbreviazioni è necessario
chiarirne il significato utilizzando gli elementi ACRONYM e ABBR.
Per gli utenti che utilizzano la navigazione tramite tastiera, è necessario definire in
modo corretto le tabulazioni tramite l’attributo TABINDEX in modo che l’utente possa
raggiungere facilmente le funzionalità richieste.
Anche i fogli di stile necessitano di particolari accorgimenti relativamente
all’accessibilità, in quanto se si utilizzano ad esempio i caratteri a dimensione fissa
(es: 12px) gli utenti ipovedenti non potranno ridimensionare i caratteri e quindi non
potranno fruire al meglio dei contenuti. È pertanto necessario impostare i caratteri in
dimensioni relative (es: 0.8em) ed eseguire un test di navigazione del sito Web con
risoluzioni basse impostando nel browser i caratteri molto grandi.
Per realizzare un sito accessibile è consigliabile evitare di ottimizzare le pagine per una
specifica versione di browser o risoluzione video. Altrimenti un utente che ha
impostato il proprio monitor a una risoluzione molto bassa deve continuamente agire
sulle barre di scorrimento del browser per visualizzare tutto il contenuto della pagina.
Occorre inoltre prestare molta attenzione alla scelta dei colori. Bisogna assicurarsi che
ci sia un buon contrasto cromatico tra lo sfondo e il testo scritto e tenere presente che
persone con diverse disabilità visive visualizzano i colori con tonalità differenti.
6 - Figure e diagrammi.
Descriverli all'interno della pagina o utilizzare l'attributo LONGDESC.
Abbiamo analizzato in precedenza l’attributo ALT, LONGDESC si differenzia dall’attributo
ALT
in quanto anziché essere un breve testo alternativo è un collegamento a un
documento esterno che descrive in modo più specifico un’immagine.
7 - Script, applet e plug-in.
Fornire una pagina alternativa quando tali funzionalità sono inaccessibili o non supportate.
Molte applicazioni si appoggiano su sistemi che utilizzano tecnologie specifiche come
Java e ActiveX oppure applicazioni generate da strumenti commerciali come Adobe
Flash. Tali tecnologie richiedono dei particolari programmi per la loro fruibilità (plugin), in mancanza dei quali l’utente non può fruire dei contenuti. Spesso i plug-in non
- 57 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
sono disponibili per tutti i browser e per tutti i sistemi operativi causando delle
limitazioni per una parte degli utenti: non definendo una soluzione alternativa, tutte le
funzionalità previste da tali tecnologie, come ad esempio un menu di navigazione, non
risultano accessibili agli utenti non dotati di tali plug-in, siano essi utenti normodotati o
utenti con disabilità. Lo stesso problema viene generato dalle applet java, nel caso il
browser non supporti tale funzionalità
Anche per gli script, al fine di rendere accessibile la funzionalità è necessario
prevedere una operatività alternativa, tramite l’elemento NOSCRIPT.
8 – I frame.
Utilizzare NOFRAMES e titoli significativi.
I frame possono essere utilizzati per facilitare la navigazione dell’utente normodotato
all’interno di un sito Web, in quanto consentono ad esempio di mantenere un menu
nel frame superiore sempre visibile. I FRAMESET possono causare problemi, spesso
capita che i motori di ricerca indicizzino pagine interne dei frame che non consentono
di ritornare alla gestione dei menu. I frame, in oltre, causano difficoltà di navigazione
agli utenti che fanno uso di tecnologie assistive. L’utilizzo del NOFRAMES è richiesto dal
W3C al fine di garantire l’accesso agli utenti che fruiscono del sito con sistemi che non
supportano tale tecnologia.
9 - Tabelle.
Facilitare la lettura linea per linea. Riassumere.
L’impiego corretto di tabelle dati deve consentire anche ai disabili visivi e cognitivi di
ottenere le informazioni in modo chiaro ed esaustivo. Le tabelle dati devono perciò
contenere un sommario SUMMARY, un titolo CAPTION e identificare in modo chiaro i
riferimenti per le righe e le colonne. In questo modo un utente con tecnologia assistiva
avrà la possibilità di fruirne in modo chiaro.
Per le tabelle di impaginazione, ove utilizzate, è necessario specificare l’organizzazione
dell’aspetto tramite l’attributo SUMMARY, non utilizzando invece gli altri attributi che
identificano le tabelle di dati.
10 - Verificare il lavoro.
Validare. Utilizzare gli strumenti, la lista di controllo e le linee guida di:
http://www.w3.org/TR/WCAG.
Come suggerito dal W3C, gli sviluppatori, prima di effettuare i test con gli utenti
possono effettuare autonomamente delle verifiche di accessibilità delle pagine Web:
simulando le condizioni di lavoro di un utente disabile, provando a navigare solo con la
tastiera, utilizzando un browser testuale o disabilitando il caricamento di immagini,
- 58 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
suoni e animazioni nel browser grafico, ripetendo le prove con vari livelli di risoluzione
grafica e di dimensioni dei caratteri.
Nel resto di questa stessa sezione avremo modo di verificare i concetti appena sintetizzati,
completandoli poi più avanti con il corpo intero delle normative.
Circolare Bassanini
Vale la pena far notare che i 10 consigli rapidi del W3C sono stati, fino alla legge Stanca del
gennaio 2004, la base su cui l’amministrazione italiana aveva introdotto il tema
dell’accessibilità nei siti pubblici.
La circolare ministeriale1 del 13 marzo 2001, n. 3/2001 del ministro della funzione pubblica
Bassanini, infatti, raccomanda di utilizzare il più possibile le tecnologie Web per la
comunicazione interattiva richiedendo che i siti siano accessibili ed usabili.
Nella circolare si invitano tutti coloro che, a vario titolo, sono coinvolti nella progettazione,
gestione e aggiornamento dei siti della Pubblica Amministrazione, ad attenersi alle regole
riportate come allegato A della circolare entro sei mesi dalla pubblicazione della direttiva.
Nel testo si invitano, nel contempo, tutti coloro che sono in condizione di applicare le linee
guida sull'accessibilità dei siti Web del W3C, incluse le procedure di verifica in esse suggerite, a
completare il progetto o la ristrutturazione di un sito in tal senso, al fine di raggiungere un
livello superiore di accessibilità.
I requisiti della accessibilità sono descritti in un allegato alla circolare che riporto
sinteticamente dal momento che sono centrati tutti, compreso il primo introduttivo, sui dieci
suggerimenti rapidi delle WCAG.
Per quanto non abbiano mai avuto efficacia normativa, sono sicuramente un valido sunto di
una ottima tecnica di programmazione.
Organizzazione delle pagine:
Distinguere, e trattare separatamente, il contenuto, la struttura e la presentazione di
una pagina, facendo uso di "fogli di stile" (CSS). Non usare il colore come unico
veicolo di informazione. Usare grandezze relative per indicare le dimensioni e la
posizione delle componenti di una pagina. Usare possibilmente componenti scalabili.
Tutto questo allo scopo di assicurare che le pagine si trasformino coerentemente,
senza perdita di informazione e senza sovrapposizioni di componenti, al variare delle
1
[http://www.governo.it/Presidenza/web/circ13mar2001_FP.html]
- 59 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
scelte di visualizzazione dell'utente, come la risoluzione grafica o la dimensione dei
caratteri.
Immagini e animazioni:
Si deve limitare l'uso di questi componenti ai casi di vera utilità, corredandole di
didascalie o descrizioni testuali (ad esempio l’attributo ALT di HTML) per indicare la
funzione dell'immagine o la descrizione del contenuto (ad esempio LONGDESC in HTML)
quando questo è importante per la comprensione del documento. Evitare scritte
lampeggianti o in movimento, questo a causa di possibili crisi epilettiche in soggetti
predisposti o di disturbo della comprensione da parte di persone con problemi
cognitivi.
Mappe immagine:
Usare mappe interamente contenute nel documento (client side) e corredare ogni
parte sensibile di didascalia testuale.
Componenti multimediali:
Corredare le componenti sonore di segnalazioni alternative visive. Corredare,
possibilmente, i filmati di descrizione testuale delle immagini e di sottotitolazione dei
dialoghi.
Collegamenti ipertestuali (links):
Usare parole o brevi frasi di chiaro e univoco significato anche fuori del contesto,
evitando espressioni generiche come "premi qui". Si deve seguire la stessa regola
anche per la didascalia alternativa di collegamenti realizzati con immagini o simboli
grafici.
Grafici e schemi:
Aggiungere descrizioni testuali alternative che permettano la comprensione del loro
significato anche a chi non può vederli.
Componenti interattive (script, applet , plug-in):
Limitarne l'uso ai casi di vera utilità e prevedere procedure alternative nel caso che
non siano gestibili con i comuni ausili usati dagli utenti disabili. Prevedere un
messaggio di avvertimento di apertura di una finestra.
Frame:
- 60 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Usare nomi significativi del loro contenuto e prevedere l'alternativa NOFRAMES. Si tenga
presente che una presentazione ristretta ad una porzione di schermo può creare
problemi alle persone ipovedenti che preferiscono sfruttare tutta la larghezza dello
schermo per la lettura con caratteri ingranditi, evitando più che è possibile lo
scorrimento orizzontale del testo.
Tabelle:
Assicurarsi che il contenuto e la struttura delle tabelle risultino chiari anche quando la
tabella stessa viene letta cella dopo cella e una riga alla volta. Usare dimensioni
relative per evitare l'invasione del contenuto di una cella in quella adiacente in caso di
riformattazione della pagina con diversa risoluzione.
Verifica dell'accessibilità di una pagina:
Tale verifica potrà realizzarsi, ad esempio, simulando le condizioni di lavoro di un
utente disabile, con l'uso di un browser testuale oppure di un browser grafico,
disabilitando il caricamento delle immagini, delle animazioni, dei suoni, dei colori e
ripetendo le prove con vari livelli di risoluzione grafica e di dimensioni dei caratteri,
ove possibile.
Un’ultima annotazione da aggiungere a questa prima breve presentazioni di metodologie
sull’accessibilità riguarda l’utilizzo dei frame e della struttura FRAMESET che in tutte queste note
è ancora tollerato.
Come abbiamo visto queste succinte introduzioni all’accessibilità sono basate sulle WCAG 1.0
del 1999. L’elemento FRAMESET è destinato a scomparire dal linguaggio XHTML, e con esso gli
elementi FRAME e NOFRAME che sono già esclusi nella versione 1.1. La legge italiana attualmente
in vigore ne proibisce espressamente l’uso per nuovi siti come vedremo meglio poi.
Sconsiglierei del tutto l’uso di questo elemento.
III.3 - Componenti essenziali dell’accessibilità
La base di partenza per ottenere dei siti ad alta accessibilità è quella di:
Separare il più possibile il contenuto dalla presentazione;
Strutturare in maniera semantica il codice originale (X)HTML;
Fornire delle alternative ridondanti e multi-modali di fruizione.
- 61 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Questi concetti verranno accuratamente presentati nel seguito della trattazione.
Per quanto riguarda la separazione del contenuto dalla presentazione, una buona chiave
di lettura è l’articolo già citato di Jim Byrne1.
Secondo l’autore, creare un documento strutturato secondo gli standard HTML non risolve tutti
problemi del rendere il contenuto accessibile alle persone (e non solamente ai programmi
utente), tuttavia, se si progetta il sito Web impiegando gli standard HTML e si cerca di separare
la struttura del documento dal modo in cui viene presentato, si compie sicuramente un passo
in avanti molto importante.
Oltre che riportare in questo modo l’(X)HTML alle sue originali funzionalità, con questa logica
guida si riesce a realizzare quella necessaria suddivisione fra i produttori e i fruitori di
contenuti. Una concezione che ha come base l’indipendenza delle pagine Web dal vincolo dei
programmi utente che le presenteranno agli utenti.
Per questo concetto si trova molto spesso citato il motto “write once, read anywhere”, una
deformazione del motto “write once, run anywhere” della Sun Microsystems, coniato per la
piattaforma Java.
Con questa frase si vuole intendere che quello che viene prodotto una volta per tutte dal
progettista di siti deve venire poi letto su piattaforme disparate da chiunque senza alcuna
modifica del codice.
Uno schema sintetico e molto chiaro di questa chiave di lettura si ritrova sulle stesse pagine
del W3C.
Nel descrivere i componenti essenziali per l’accessibilità2 si ribadisce che è essenziale che
diverse componenti dello sviluppo Web e dell’interazione lavorino insieme.
Queste componenti comprendono:
Contenuti, vale a dire le informazioni di una pagina Web. Di questi fanno parte sia le
informazioni naturali, come testo immagini e suono, che il codice per la definizione della
struttura e della presentazione;
Web browser, media player e altri programmi utente;
Tecnologie assistive, come screen-reader, tastiere alternative, convertitori di segnali
eccetera;
1
2
Capacità ed esperienze degli utenti;
Sviluppatori, progettisti, programmatori, autori che producono i contenuti;
Jim Byrne: “Making Webpages accessibile to people” - [http://www.mcu.org.uk/articles/whatisaw.html]
[http://www.w3.org/WAI/intro/components.php]
- 62 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Strumenti di sviluppo;
Strumenti di valutazione, validatori HTML e CSS.
Vorrei riportare un diagramma molto illuminante direttamente dalle pagine del W3C che illustri
lo schema delle relazioni fra queste parti:
Figura 1 - Schema delle interazioni Web
In sostanza, per intendere al meglio questo schema di fruizione abbiamo a che fare con tre
concetti cardine di un documento Web che sintetizziamo in:
Contenuto;
Struttura;
Presentazione.
Nello sviluppo di questa trattazione vedremo quali sono i modi migliori per ottenere la più alta
accessibilità da queste interazioni.
Separazione tra contenuto e presentazione
Partiamo dalle definizioni dei termini così come espresse proprio dal W3C nel glossario1 delle
WCAG 2.0:
1
[http://www.w3.org/TR/WCAG20/appendixA.html]
- 63 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Contenuto:
Informazione che si vuole comunicare all’utente attraverso un user agent.
Come accennato, questo include anche il codice e i marcatori che definiscono la
struttura, la presentazione e l’interazione, così come il testo, le immagini e i suoni che
veicolano informazioni all’utente finale;
Struttura:
Il modo in cui le parti di un insieme unitario di materiale creato da un autore sono
organizzate in relazione fra loro;
Presentazione:
Il modo di rendere il contenuto e la struttura in una modalità che può essere percepita
dall’utente.
Nel documento di implementazione delle tecniche1 per le WCAG 1.0 il W3C riporta un paragrafo
a proposito delle fondamentale interazione fra queste entità.
In sostanza raccomanda che quando si progettano dei documenti, gli sviluppatori di contenuti
dovrebbero dedicarsi in principio a identificare la struttura desiderata del documento, e
solo in seguito pensare a come il documento sarà presentato all’utente.
Distinguere la struttura del documento da come il contenuto sarà presentato agli utenti, offre
una serie di vantaggi tra cui un’accessibilità migliorata, una migliore portabilità ed una
gestione facilitata.
Questa operazione di separazione potrebbe a volte dare adito ad interpretazioni differenti. Per
esempio molti sviluppatori considerano che una riga orizzontale realizzata con l’elemento < HR>
comunichi una divisione strutturale, mentre altri lo ritengono un elemento di presentazione.
Uno sviluppatore di contenuti non dovrebbe usare elementi strutturali per marcare effetti di
presentazione, evitando, ad esempio, l’uso scorretto di BLOCKQUOTE per indentare del testo non
citato.
La finalità ultima di questo modo di procedere è quella di implementare al meglio lo schema
indicato in Figura 1.
In questo modo l’interazione dei programmi utente con i contenuti può essere svincolata dalle
capacità sensoriali dei visitatori del sito e dalle limitazioni dei programmi utente stessi.
La cosa fondamentale è che tutti i possibili tipi di presentazione di un documento riescano a
mostrare all'utente, se non proprio lo stesso contenuto, almeno un suo valido equivalente
1
[http://www.w3.org/TR/1999/WAI-WEBCONTENT-TECHS-19990505/#structure]
- 64 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
informativo.1
Perché ciò possa avvenire, sono necessarie due condizioni:
Che siano stati preparati degli equivalenti per quei contenuti che, per loro natura, si
rivolgono ad un solo canale sensoriale: per esempio dei testi alternativi come
equivalenti delle immagini;
Che non vi siano vincoli all'interno del documento, tali da consentire un'adeguata
presentazione del contenuto solo su certi programmi utente (per esempio browser
visuali di una certa marca) e sotto determinate condizioni d'uso (per esempio una data
risoluzione ed una data grandezza dei caratteri), con esclusione parziale o totale di tutti
gli altri programmi utente e di tutte le altre possibili condizioni d'uso.
Il problema sorge quando questi vincoli di presentazione vengono intrinsecamente progettati
all’interno del documento originario, mescolandoli indissolubilmente ai contenuti e non
permettendo ai programmi utente di rendere al meglio il contenuto informativo della pagina
Web secondo le esigenze dell’utente.
Il primo passo da compiere, per evitare vincoli che impediscano di ottenere adeguate
presentazioni alternative di un documento, consiste nell'eliminare dal codice HTML gli elementi
e gli attributi di presentazione.2
Un buon modo per separare struttura dalla presentazione è quello di impiegare i Cascading
Style Sheets (CSS), i fogli di stile che servono per determinare il modo di presentare le
pagine Web.
Invece di creare molteplici versioni per ogni pagina, con i CSS è possibile creare pagine che
sono flessibili nel modo di presentarsi.
In qualche modo è come se si spostasse la responsabilità di come il contenuto viene
presentato dal produttore al consumatore e al programma utente che viene usato.3
Questo criterio base è ripreso da tutte le normative in materia che vengono trattate in questa
tesi. In particolare:
1
Michele Diodati [http://webdesign.html.it/guide/lezione/1446/cosa-significa-separare-il-contenuto-dallapresent]
2
Michele Diodati [http://webdesign.html.it/guide/lezione/1446/cosa-significa-separare-il-contenuto-dallapresent]
3
Jim Byrne: Making Webpages accessibile to people - “In some sense we move the responsibility for how
the content is presented, away from the producer, towards the consumer and the particular web client they
are using.”
- 65 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
WCAG 1.0, Punto di controllo 3.3: “Usare i fogli di stile per controllare l'impaginazione e
la presentazione.”, Punto di controllo 6.1: “Organizzare i documenti in modo che
possano essere letti anche in assenza dei fogli di stile.”
Section 508, paragrafo 1194.22 (d): “Progettare indipendentemente dai fogli di stile. I
documenti dovranno essere organizzati in modo da risultare leggibili anche senza
l'utilizzo di fogli di stile.”
D.M. 8 Luglio 2005, requisito 11: “Usare i fogli di stile per controllare la presentazione
dei contenuti e organizzare le pagine in modo che possano essere lette anche quando i
fogli di stile siano disabilitati o non supportati.”
WCAG 2.0: In questo caso non vi sono paragrafi espliciti che obblighino all’uso dei fogli
di stile, anche perché le WCAG 2.0 non hanno lo stesso riferimento esplicito alle
tecnologie come nelle versioni 1.0. Quando indicati, comunque, i CSS sono
semplicemente considerati come uno strumento di base, al pari del (X)HTML. Tutti i
suggerimenti tecnici su come raggiungere l’accessibilità danno per assunto l’utilizzo dei
CSS.
In questo senso, più che le normative esposte, sono gli stessi standard (X)HTML che si stanno
indirizzando verso la rimozione degli elementi presentazionali dalle pagine.
L’evoluzione del linguaggio XHTML tende dichiaratamente a riportare in primo piano, come
era alle origini del linguaggio HTML, la struttura del documento, eliminando tutto ciò che è
pura presentazione. Questo in linea con lo spirito della linea guida 3 delle WCAG 1.0, che
suggerisce di separare il contenuto del documento dalla sua presentazione 1.
Questa tendenza è diventata preponderante al punto che dalla specifica XHTML 1.1 è stato
completamente eliminato il supporto per gli elementi e attributi di presentazione in precedenza
tollerati, demandando ogni funzione di questo tipo ai fogli di stile. 2
Per concludere, vorrei sintetizzare alcuni dei vantaggi ottenibili dall’uso dei fogli di stile così
come esposto da Michele Diodati3.
Definire la presentazione per mezzo dei CSS consente di ridurre il peso della pagina,
talvolta del 50-60% o anche più. Solo questo rappresenta un grosso vantaggio per
l'accessibilità;
1
2
3
Michele Diodati: [http://www.diodati.org/scritti/2004/guida/ele_acc20.asp]
Marco Bertoni: “Accessibilità. Dalla teoria alla realtà” - capitolo 13.
[http://webdesign.html.it/guide/lezione/1447/perche-eliminare-dal-codice-html-o-xhtml-gli-eleme/]
- 66 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L'uso dei CSS consente di specificare una serie di presentazioni alternative, ognuna
delle quali adatta alla riproduzione su una differente periferica (schermo, stampa,
sintetizzatori vocali, ecc.), mentre l'uso di elementi e attributi di presentazione
dell'HTML favorisce essenzialmente la sola riproduzione su schermo;
Demandare la presentazione ai CSS consente di ottenere un codice HTML più lineare e
pulito, e di evitare per esempio il ricorso ad artifici sconsigliati per l'accessibilità, quali le
tabelle usate a scopo di impaginazione.
Fogli di stile (CSS)
Della sintassi dei fogli di stile si è già brevemente accennato al momento di parlare del
linguaggio del Web.
In questa sezione vorrei invece dare una idea di come possano essere applicati e di quali
funzionalità siano mandatari.
Generalità
Come detto, un foglio di stile è costituito da un insieme di regole, scritte in una particolare
grammatica, che specificano l'aspetto di un documento.
La grammatica prevede forme del tipo:
selettore { proprietà : valore; }
Come indicato in precedenza.
Ad ogni pagina si possono collegare più fogli di stile, ed è possibile far scegliere all'utente quali
applicare. Per farlo si definiscono innanzi tutto i fogli di stile principale, secondo la sintassi:
<link rel="stylesheet" type="text/css" href="foglio_preferito.css"
title="Esempio1">
A questo punto è possibile specificare fogli di stile alternativi cioè non attivi al caricamento, ma
attivabili dall'utente, con l’opzione ALTERNATE STYLESHEET:
<link rel="alternate stylesheet" type="text/css" href="foglio_alternativo.css"
title="Esempio2">
Secondo le specifiche1 del W3C, gli autori dovrebbero poter specificare un qualsivoglia numero
di fogli di stile alternativi e gli utenti dovrebbero poter selezionare il loro preferito. Sarebbe
1
[http://www.w3.org/TR/html4/present/styles.html#h-14.3.1]
- 67 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
compito dei programmi utente permettere questa scelta. Il condizionale è dovuto allo scarso
supporto dei browser a queste direttive.
Le cose tuttavia stanno sensibilmente migliorando, in molti browser (ad esempio Firefox ed
Opera) l'utente può scegliere ricorrendo un apposito menu. Tuttavia Internet Explorer, pur
dando la possibilità di accedere ad un proprio foglio di stile, non permette, neanche nella
versione 7 di impiegare i fogli di stile alternativi.
In tal caso è necessario creare un opportuno script lato client che svolga la funzione di
sostituire i fogli. Questo script richiede l’abilitazione delle funzionalità degli script nel browser.
Un sistema più complesso ma più robusto può essere quello di impiegare uno script lato
server. L’efficienza e l’utilità di queste tecniche è discussa nelle metodologie generali.
Le informazioni contenute nei CSS possono essere applicate da tre diverse sorgenti:
Stili forniti dagli autori delle pagine Web, nelle modalità di:
o
Fogli di stile esterni (external), cioè un file separato di tipo CSS che viene
indirizzato all’interno del del documento (X)HMTL;
o
Fogli di stile incorporati (embedded), cioè blocchi di informazioni CSS interni allo
stesso documento (X)HTML;
o
Stili in linea (inline) cioè informazioni di stile interne all’ (X)HTML specificate per
un singolo elemento utilizzando l’attributo style.
Stili forniti dagli utenti, cioè un foglio di stile locale specificato dall’utente che si applica
a tutti i documenti sovra-scrivendo le impostazioni degli autori.
Stile definito in generale dai browser: il modo di default di presentare gli elementi da
parte dei programmi utente.
Visto che i fogli di stile di un documento possono avere diverse origini, ci possono essere delle
regole in conflitto fra loro. Le tecniche CSS definiscono delle procedure di priorità per
determinare quale regola di stile verrà applicata ad un particolare elemento nel caso di
sovrapposizioni. Queste priorità sono appunto definite a cascata attribuendo dei pesi che sono
calcolati per assegnare la regola prioritaria.
Le dichiarazioni presenti nel foglio di stile dell'autore hanno un peso maggiore di quelle del
foglio di stile dell'utente, tranne che per quelle alle quali è applicato il costrutto !IMPORTANT.
Questo costrutto indica modifica la precedenza nell'ordine di cascata. Le dichiarazioni presenti
nel foglio di stile predefinito dal browser hanno il peso minore.
Ecco lo schema in ordine d’importanza dal minore al maggiore:
Foglio di stile predefinito del browser;
Foglio di stile normale dell'utente;
Foglio di stile normale dell'autore;
Foglio di stile !IMPORTANT dell'autore;
Foglio di stile !IMPORTANT dell'utente.
- 68 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Successivamente, il browser ordina le regole in funzione della specificità del selettore. I
selettori maggiormente specifici avranno la precedenza su quelli più generali.
Resta comunque un principio cardine nell’utilizzo dei CSS, raccomandato da tutte le normative:
è fondamentale ricordarsi che è necessario sviluppare siti Web in modo che siano fruibili anche
se il browser utilizzato non supporta i fogli di stile o se l’utente li ha volontariamente
disabilitati.
Tecniche per i CSS del W3C
Molte di queste informazioni sono direttamente reperibili sul sito del W3C come tecniche per
l’accessibilità Web con i CSS1.
Per una traduzione italiana, integrata con degli utili commenti aggiuntivi, consiglio la lettura
del capitolo 13 curato da Marco Bertoni del testo di Roberto Scano 2.
Vediamo un elenco delle tecniche più significative:
Diminuire la manutenzione ed incrementare la coerenza.
Usare un numero minimo di fogli di stile;
Usare gli stili esterni piuttosto che gli stili incorporati, evitare gli stili in linea. Gli stili
esterni possono essere collegati a molteplici documenti permettendo di impostare uno
stile comune solamente variando la regola di un CSS;
Usare lo stessa classe per lo stesso concetto in tutti i fogli di stile.
Sovrapposizione degli stili utente.
Per garantire che gli utenti possano controllare gli stili, il protocollo dei CSS2 cambia la
semantica dell’operatore !IMPORTANT da come era definito nei CSS1. Nei CSS1 erano gli
autori che avevano l’ultima parola sui fogli di stile. Nei CSS2, se uno stile utente contiene il
termine !IMPORTANT, questo ha la precedenza su qualsiasi altra regola applicabile regola nei
fogli di stile degli autori.
Unità di misura.
1
2
Utilizzare l’unità em per impostare la dimensione del font;
Utilizzare le unità relative e le percentuali;
Utilizzare le unità assolute solamente quando le caratteristiche fisiche del dispositivo di
[http://www.w3.org/TR/WCAG10-CSS-TECHS/]
Roberto Scano “Accessibilità. Dalla teoria alla realtà”
- 69 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
uscita sono conosciute;
Contenuto generato.
Secondo le specifiche più recenti dei fogli di stile è possibile generare contenuto che non
appartiene all'albero degli elementi del documento. Ad esempio gli elementi grafici di un
elenco puntato, o la numerazione progressiva di un elenco numerato, non sono presenti nel
codice, ma sono generati automaticamente dal browser una volta visualizzato il
documento. Ma è possibile anche aggiungere del testo a piacere.
In tal caso le tecniche suggerite dal W3C richiedono di:
Fornire un testo equivalente per ogni elemento importante generato;
Assicurarsi che il contenuto importante appaia nell’oggetto del documento.
Altrimenti potrebbe non essere accessibile ad una tecnologia assistiva che si basi su
tecniche DOM (Document Object Model).
Caratteri.
Specificare sempre una famiglia generica di caratteri come ultima risorsa;
Invece di utilizzare elementi ed attributi presentazionali deprecati, impiegare al loro
posto le proprietà CSS per il controllo delle caratteristiche dei caratteri, come FONTFAMILY, FONT-SIZE, FONT-STYLE
e FONT-WEIGHT;
Nel caso si dovessero impiegare elementi HTML per specificare informazioni sul font
utilizzare BIG e SMALL che non sono elementi deprecati.
Effetti di stile del testo.
Per lo stile del testo si possono utilizzare le proprietà TEXT-TRANSFORM per il maiuscolo,
minuscolo e iniziali maiuscole, oppure TEXT-DECORATION per il testo sotto o sopralineato o
lampeggiante con le dovute attenzioni al lampeggiamento. Non utilizzare MARQUEE e BLINK.
Testo al posto di immagini.
Gli sviluppatori dovrebbero usare i CSS per rendere lo stile del testo piuttosto che
impiegare delle immagini. L'informazione sarà così disponibile ad un numero più ampio di
utenti (con sintetizzatori vocali, dispositivi Braille, schermi grafici ecc.). Utilizzando i fogli di
stile si consentirà inoltre all'utente di ignorare gli stili dell'autore e cambiare colori e
caratteri in modo semplice. Se si ritenesse comunque necessario utilizzare immagini per
creare effetti testuali (come caratteri speciali, trasformazioni, ombreggiature ecc.)
l'immagine dovrà essere resa accessibile inserendo testo equivalente con l'attributo ALT.
Formattazione e posizione del testo.
- 70 -
Utilizzare TEXT-INDENT per indentare, non usare BLOCKQUOTE o altri elementi strutturali
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
per indentare il testo;
Usare LETTER-SPACING e WORD-SPACING per spaziare parole e lettere. Il testo senza spazi
bianchi interposti può essere pronunciato con maggiore correttezza;
Utilizzare WHITE-SPACE per gli spazi bianchi, tabulazioni ed interruzioni di riga,
impostandone gli opportuni parametri.
Colori.
Usare le seguenti proprietà CSS per specificare il colore:
COLOR,
per il testo in primo piano;
BACKGROUND-COLOR,
BORDER-COLOR, OUTLINE-COLOR,
per i colori di sfondo;
per i bordi;
Assicurarsi che il contrasto sia sufficiente tra colori di primo piano e colori di sfondo. Per
questo si possono usare dei programmi appositamente predisposti come il Color Contrast
Analyzer1.
Si raccomanda, tutte le volte che si specifica un colore di primo piano, di specificare
sempre anche un colore di sfondo e viceversa.
Si raccomanda di non basarsi solamente sul colore per veicolare l’informazione. E’
essenziale assicurasi che le informazioni siano disponibili anche attraverso altri effetti di
stile, per esempio un effetto applicato al carattere.
L’argomento è trattato nel capitolo inerente l’uso del colore.
Fornire tracce contestuali nelle liste HTML.
In ossequio alle WCAG2, gli sviluppatori di contenuti sono incoraggiati ad usare UL (liste
non ordinate) e OL (liste ordinate) combinate con i CSS, per fornire tracce contestuali. Ad
esempio, ponendo degli indicatori di fine lista al termine di una lista.
Una spiegazione di questa tecnica si trova nella descrizione degli ausili alla navigazione di
questo lavoro.
Aspetto, posizionamento, livelli ed allineamento.
Aspetto, posizionamento, livelli ed allineamento dovrebbero essere ottenuti utilizzando i
fogli di stile, in particolar modo per i posizionamenti assoluti e fluttuanti.
1
2
Le proprietà TEXT-INDENT, TEXT-ALIGN e WORD-SPACING permettono all'autore di
[http://juicystudio.com/services/colourcontrast.php]
Linea guida 13.2: “Fornire metadati che aggiungano informazioni semantiche alle pagine e ai siti”
- 71 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
controllare la spaziatura e l'allineamento del testo senza aggiungere spazi
addizionali;
Le proprietà MARGIN, MARGIN-TOP, MARGIN-RIGHT, MARGIN-BOTTOM e MARGIN-LEFT
permettono di aggiungere spazio ai quattro lati di un elemento senza ricorrere
all'entità &NBSP; (non-breaking space). Questa entità è visualizzata dal browser
come uno spazio bianco e previene l'interruzione di riga tra due parole;
Le proprietà FLOAT, POSITION, TOP, RIGHT, BOTTOM e LEFT consentono di controllare la
posizione visiva di quasi tutti gli elementi, in maniera indipendente dal punto in cui
compaiono nel codice del documento. Gli autori dovrebbero sempre progettare
documenti che mantengano senso anche senza i fogli di stile. In altre parole si
dovrebbe prima codificare il contenuto del documento seguendo un ordine logico e
poi applicare i fogli di stile per ottenere gli effetti visivi voluti. Per esempio, le
proprietà di posizionamento potrebbero essere usate per creare note al margine,
barre laterali, effetti simili ai frame, semplici intestazioni e piè di pagina;
La proprietà EMPTY-CELLS consente di lasciare alcune celle di una tabella vuote
generando ugualmente gli appropriati bordi su schermo o su carta. Una cella di dati
che si intende lasciare vuota non dovrebbe essere riempita con spazio bianco o con
l'entità &NBSP; solo per ottenere un effetto visivo.
Se si dovesse usare una immagine come spaziatore, occorre fornire un testo equivalente
anche per questa, si consiglia l’uso di un valore vuoto.
Righe e bordi.
Righe e bordi possono fungere da separatori per gli utenti visivamente normodotati, questo
significato, però, può non venir trasmesso al di fuori di un contesto visivo.
Impiegare le proprietà dei CSS per specificare gli stili del bordo
BORDER, BORDER-WIDTH, BORDER-STYLE, BORDER-COLOR;
BORDER-SPACING
OUTLINE, OUTLINE-COLOR, OUTLINE-STYLE,
e BORDER-COLLAPSE per le tabelle;
e OUTLINE-WIDTH per i controni dinamici.
Se una riga orizzontale (<HR/>) viene utilizzata come elemento strutturale, occorre essere
sicuri che la struttura venga segnalata anche in una modalità non visiva. Ad esempio
impiegando dei marcatori non strutturali.
Impiegare gli elementi di posizionamento e marcatura dei CSS per la resa delle presentazioni
visuali.
Utilizzando le proprietà di posizionamento dei fogli di stile il contenuto può essere collocato
in qualsiasi punto dell'area di visualizzazione della pagina. Con il posizionamento assoluto,
l'elemento influenzato viene rimosso dal normale flusso della pagina e la sua posizione non
è più correlata a quella occupata nel codice. In altre parole, l'ordine in cui i contenuti
- 72 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
appaiono sullo schermo può essere differente dall'ordine in cui compaiono nel documento
sorgente.
Se seguiamo il principio secondo il quale un documento dovrebbe essere leggibile anche
senza fogli di stile, risulta chiaro che è importante codificare il documento sorgente
utilizzando marcatori strutturali ed ordinare i contenuti in modo logico.
Un classico esempio è il seguente dove è evidente una riorganizzazione della
presentazione.
HTML
<div
<div
<div
<div
class="parte1">The quick</div>
class="parte2">brown fox</div>
class="parte3">jumped over</div>
class="parte4">the lazy dogs.</div>
CSS
.parte1 /* The quick */ { color: red; font-size: 14pt; padding-left: 0; margintop: 40px; font-family: copperplate gothic bold, fantasy, sans-serif }
.parte2 /* brown fox */ { color: brown; font-size: 10pt; padding-left: 100px;
margin-top: 30px; font-family: times new roman, desdemona, serif }
.parte3 /* jumped over */ { color: purple; font-size: 18pt; padding-left: 200px;
margin-top: -60px; font-family: desdemona, times new roman, serif }
.parte4 /* the lazy dogs */ { color: blue; font-size: 24pt; padding-left: 350px;
margin-top: -80px; margin-bottom: 100px; font-family: fantasy, copperplate
gothic bold, sans-serif }
Tecniche di questo tipo possono essere volute o meno, ma resta il principio che la
strutturazione di un documento deve essere tale da permettere la corretta lettura del
contenuto anche con i fogli di stile disabilitati.
Gestione del movimento con i CSS e gli script.
Fino a quando i programmi utente non consentiranno agli utenti di bloccare il contenuto in
movimento, evitare il movimento nelle pagine.
CSS di tipo aural (auditivi).
Le proprietà auditive dei CSS2 forniscono informazioni agli utenti non vedenti e ai browser
vocali allo stesso modo con cui i caratteri forniscono informazioni visive.
Le seguenti proprietà fanno parte dei fogli di stile auditivi nella specifica CSS2:
VOLUME
SPEAK
controlla il volume del testo parlato.
controlla se il contenuto sarà letto e, in tal caso, se lettera per lettera (utile per gli
acronimi e le abbreviazioni) o come una parola intera.
PAUSE, PAUSE-BEFORE
e PAUSE-AFTER specificano pause da rispettare prima e dopo il
contenuto parlato. Questo permette agli utenti di separare il contenuto per una migliore
comprensione.
- 73 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
CUE, CUE-BEFORE
e CUE-AFTER specificano un suono da eseguire prima o dopo il contenuto
di un elemento. Questo suono è una vera e propria icona uditiva che aiuta l'utente ad
orientarsi.
PLAY-DURING
specifica un suono che verrà eseguito come sfondo quando il contenuto di
un elemento è letto (come un'immagine di sfondo).
AZIMUTH
ed ELEVATION forniscono profondità al suono, permettendo all'utente di
distinguere, per esempio, fra differenti voci.
Le proprietà SPEECH-RATE (la velocità del parlato), voice-family, PITCH (la frequenza
media della voce parlante), PITCH-RANGE (variazioni della frequenza media), STRESS
(l'inflessione), e RICHNESS (l'intensità) controllano la qualità del contenuto parlato.
Variando queste proprietà per elementi differenti l'utente può regolare il modo in cui il
contenuto è presentato in modo auditivo.
SPEAK-PUNCTUATION
e SPEAK-NUMERAL controllano come i numeri e la punteggiatura
saranno letti, influenzando la qualità dell'esperienza della navigazione auditiva.
Va ricordato che gli screen-reader stanno incominciando solo adesso a supportare i fogli di
stile auditivi.
Accesso alle rappresentazioni alternative del contenuto.
I CSS2 permettono agli utenti di accedere alle rappresentazioni alternative del contenuto
che sono specificate nei valori degli attributi seguenti:
Selettori di attributo;
Funzione ATTR() e proprietà CONTENT;
Gli pseudo elementi :BEFORE e :AFTER.
Tipi di media.
Una caratteristica dei CSS2 è la possibilità di definire il tipo di media. Questo permette agli
autori di progettare dei fogli di stile che consente ai documenti di essere fruiti nella maniera
migliore appositamente per certi dispositivi specifici.
Questi fogli di stile possono adattare il contenuto per essere fornito su dispositivi Braille,
sintetizzatori vocali, stampanti di riga eccetera.
In genere si utilizza l’attributo MEDIA per specificare la tipologia al momento di dichiarare un
foglio di stile. Utilizzare la direttiva @MEDIA permette di includere tutte le regole in un unico
foglio senza usare CSS separati per media differenti. In questo modo si possono ridurre i
tempi di caricamento della pagina consentendo ai programmi utente di saltare le regole non
applicabili.
In linea teorica i tipi di media sono quelli descritti nella sezione del linguaggio dedicata ai
CSS. Tra i più importanti ci sono sicuramente SCREEN, BRAILLE, AURAL e TTY. ALL si usa per
indicare tutti i media.
- 74 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L’introduzione di questa funzionalità è stata molto criticata a posteriori per il fatto che il
loro uso non è stato progettato adeguatamente per il mondo reale dei dispositivi come
accennato nella successiva discussione.
Critiche e prassi
Alcune obiezioni significative vanno tenute in considerazione nel momento di impiegare dei
fogli di stile.
Il problema maggiore è sicuramente l’aderenza agli standard che fino ai giorni nostri è stata
parecchio debole da parte dei maggiori costruttori di programmi utente. Microsoft Explorer è
probabilmente una delle cause del ritardo notevole degli allineamenti agli standard, essendo
questo il browser sicuramente più diffuso ed essendo anche uno di quelli più restii ad avere
comportamenti in linea con le specifiche del W3C.
Tra le specifiche sicuramente più disattese fino a questo momento ci sono stati anche i
sopraccitati media type.
In effetti bisogna riconoscere che l'introduzione dei media type nei CSS2 si è rivelata per
ora una grande promessa non mantenuta per l'accessibilità. 1
Ciò è imputabile a diversi fattori, interni ed esterni alle specifiche:
Lo scarso supporto fornito dai vari programmi utente (sia browser grafici sia tecnologie
assistive);
La ridotta conoscenza di questi strumenti di sviluppo da parte dei progettisti;
La presenza di veri e propri limiti di concezione dei CSS2, che riguardano il modo in cui
gli estensori delle specifiche hanno ritenuto possibile fornire presentazioni adatte a certi
tipi di media, in particolare ai lettori di schermo (MEDIA="AURAL"), ai traduttori in Braille
(MEDIA="BRAILLE") ed alle periferiche dotate di schermi di ridotta capacità, sul tipo degli
emulatori di terminale (MEDIA="TTY").
Per quest’ultimo punto, delle considerazioni particolarmente rilevanti sono state espresse da
Joe Clark2 che, alla fine di un capitolo del suo testo citato, suggerisce di non preoccuparsi più
di tanto di queste specializzazioni, in quanto sono scarsamente considerate e quasi del tutto
non supportate nel mondo reale.
1
Michele Diodati: [http://www.diodati.org/scritti/2004/guida/ele_acc14.asp]
Joe Clark: “Don’t worry about it. It appears, then, that your job as Web author need not include worrying
about media stylesheets for accessibility. They’re poorly thought out and are effectively unsupported in the
real world.” - [http://joeclark.org/book/sashay/serialization/Chapter11.html]
2
- 75 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Michele Diodati ha riportato un sunto1 delle critiche espresse dall'autore canadese.
I problemi nel creare fogli di stile adatti a questi tipi di media sono principalmente tre:
Le periferiche che ricadono sotto il genere 'terminale o telescrivente' ( MEDIA="TTY") sono
molto numerose e assai differenti tra loro per caratteristiche e capacità di riproduzione,
tra l'altro neppure facilmente distinguibili, in alcuni casi, da quelle definibili come
palmari (MEDIA="HANDHELD"). Un foglio di stile adatto per le più spartane tra queste
apparecchiature può essere del tutto inadatto per le più evolute, e viceversa;
Il linguaggio Braille (MEDIA="BRAILLE") ha un suo insieme di convenzioni ampio e ben
definito, usa in particolare una numerosa serie di contrazioni che sostituiscono parole o
intere frasi. Il linguaggio CSS semplicemente non dispone della capacità di adattare
automaticamente un testo alle necessità di un lettore esperto in Braille né lo
sviluppatore vedente possiederebbe, ammesso che il Braille fosse realmente supportato
dai CSS, le nozioni occorrenti a produrre un foglio di stile adeguato al caso;
I fogli di stile auditivi (MEDIA="AURAL") non solo non sono supportati da quasi nessun
programma utente, ma richiedono, affinché possano essere approntati in modo utile per
chi ascolta tramite screen-reader, una conoscenza delle esigenze di ascolto di un non
vedente che praticamente nessuno sviluppatore vedente possiede. Il rischio è di
realizzare pagine con caratteristiche di ascolto insopportabili per l'utente abituato ai
metodi di riproduzione di un normale lettore di schermo.
La conclusione è che, con ogni probabilità, gli estensori delle specifiche CSS2 hanno progettato
in modo totalmente teorico le caratteristiche di alcuni media type: infatti la conoscenza
concreta dei dispositivi che ricadono sotto le categorie elencate dalle specifiche porta in luce
una serie di problemi di non facile o impossibile soluzione, che inducono l'autore a suggerire ai
suoi lettori che i media type hanno in fondo, ai fini dell'accessibilità, un'importanza del tutto
trascurabile.
Anche perché, se la pagina è stata ben progettata, si potrebbe evitare di realizzare un foglio di
stile particolare per ogni tipo di media. Infatti, un CSS mal progettato, specie per i dispositivi
AURAL,
rischia di rendere poco accessibile una pagina che invece era in precedenza accessibile a
tutti.
Conclusioni
Le tecniche esposte per i fogli di stile sono quelle suggerite direttamente dal W3C.
1
Michele Diodati: [http://www.diodati.org/scritti/2004/guida/ele_acc14.asp]
- 76 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Riassumo i punti essenziali:
Lo sviluppatore deve comunque garantire la lettura dei contenuti della pagina anche
senza l’utilizzo dei fogli di stile, per garantirne l’accesso e la fruibilità agli utenti che
usano browser solo testo o lettori vocali;
Usare gli stili esterni piuttosto che gli stili incorporati, evitare gli stili in linea;
Utilizzare in linea di massima le unità relative e le percentuali;
L’allineamento, i margini ed il posizionamento degli elementi nella presentazione di una
pagina vanno gestiti tramite fogli di stile e non più con gli elementi presentazionali del
codice (X)HTML, che, comunque, sono in via di eliminazione;
Al momento, le specifiche per i media non sembrano essere di particolare utilità ai fini
dell’accessibilità e sono scarsamente supportati 1.
Utilizzo degli elementi strutturali
Nella discussione precedente abbiamo visto come il W3C raccomandi esplicitamente di
separare il contenuto dalla presentazione e come i fogli di stile (CSS) siano il sistema migliore
per impostare la presentazione della pagina (X)HTML svincolandola dal suo contenuto.
In questo capitolo vorrei mettere in evidenza l’aspetto strutturale della pagina, così come essa
risulta quando viene resa indipendente dai suoi aspetti di impaginazione.
Motivazioni
In effetti, la sola separazione degli attributi presentazionali dal testo del documento (X)HTML
non è sufficiente ad indirizzare l’autore delle pagine Web verso un’alta accessibilità del suo
lavoro.
Occorre ricordare che il modo di accedere ad una pagina internet da parte di un utente
normodotato non è la stessa di un disabile o di un programma utente che non visualizzi
contenuti visuali.
In particolare, in molti casi il solo sguardo d’insieme di una pagina permette di capire, tramite
il suo aspetto grafico, quali sono le parti fondamentali e com’è stata strutturata.
La navigazione e l’orientamento visuale è il naturale approccio dei visitatori normodotati e
spesso le pagine presentano la visualizzazione grafica adatta per rendere al meglio questo
approccio. Un esempio sono le suddivisioni in colonne, la posizione dei titoli e delle liste di
collegamenti, le barre di navigazione.
1
Joe Clark: “It appears, then, that your job as Web author need not include worrying about media
stylesheets for accessibility. They’re poorly thought out and are effectively unsupported in the real world.”
- 77 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Invece, comprendere i contenuti per mezzo di uno screen-reader si basa su una procedura del
tutto diversa che l'esplorare una pagina per mezzo della vista, questo per il fatto che le
informazioni arrivano necessariamente in modo seriale, una dopo l'altra, e non esiste la
possibilità di una lettura d'insieme, in parallelo, dei contenuti.
Il punto della questione è che occorre comunicare la stessa visione strutturale di’insieme anche
usando programmi utente non visuali, garantendone la percezione anche ad utenti disabili, ad
esempio non vedenti.
Costoro non sono i soli a poter usufruire dei vantaggi di una progettazione logica della pagina.
In genere vanno tenute presenti diverse situazioni:
Utenti con disabilità visive, che, come detto, non possono avere questa lettura
immediata della struttura logica della pagina con uno sguardo d’insieme;
Utenti con disabilità cognitive più o meno accentuate. Una buona ed evidente
strutturazione dei contenuti, enfatizzata da opportuni criteri di presentazione, è
sicuramente di aiuto anche per gli utenti che hanno difficoltà nel comprendere le
informazioni trasmesse dalla pagina Web. Costoro ricevono notevole aiuto da
un'organizzazione di pagina semplice e chiara;
Motori indicizzati di ricerca che riescono a sfruttare al meglio una valida strutturazione
dei contenuti;
Accesso senza i CSS. Il punto di controllo 6.1 delle WCAG 1.0 raccomanda
esplicitamente agli sviluppatori di produrre documenti che restino significativi anche se
riprodotti senza fogli di stile: valorizzare nel modo più corretto la struttura logica dei
contenuti è il modo migliore per ottenere la chiarezza e la comprensibilità del
documento se osservato senza i fogli di stile associati;
Utilizzo con i browser testuali, impiegati anche in connessioni lente o da dispositivi
specifici. Un documento ben strutturato a livello logico sarà meglio compreso da chi usa
Lynx oppure da chi usa un normale browser grafico privo di supporto per i fogli di stile,
rispetto ad un documento in cui la struttura logica venga espressa unicamente per
mezzo di una presentazione visuale grafica.
In sintesi, comunicare la struttura logica unicamente per mezzo della presentazione visuale
non è una soluzione accessibile. 1
1
Michele Diodati: [http://www.diodati.org/scritti/2004/guida/ele_acc21.asp]
- 78 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Se invece quei contenuti sono stati strutturati in partenza in modo significativo, il non vedente
potrà farsi un'idea della pagina relativamente corrispondente a quella che i vedenti riescono a
ricavare dall'esame visuale.
Nel resto di questa esposizione mi riferirò spesso ai vantaggi per i non vedenti, ma, come
appena descritto, l’approccio strutturale reca benefici a tutti i casi sopra citati.
Metodi
La separazione fra contenuto e presentazione può non essere sufficiente per ottenere
l’accessiblità voluta.
I CSS infatti, anche se utilizzati in maniera corretta, possono solo dare alla pagina un aspetto
visivo differente, rendendo al meglio l’enfasi e l’importanza delle informazioni per un visitatore
in grado di rilevarne l’impaginazione. Il non vedente non sarà in grado comunque di coglierne
gli aspetti logici e strutturali.
Questi utenti hanno bisogno, per percepire la struttura della pagina, di elementi di
marcatura che diano rilevanza all’ordine ed alla gerarchia dei contenuti. I programmi
utente utilizzati da questi visitatori hanno infatti degli apposti comandi di lettura che sono in
grado di dare il necessario rilievo agli elementi strutturali della pagina, se questi sono presenti,
ovviamente, consentendo anche di saltare eventualmente tra un titolo ed un altro e tra un
campo ed un altro.
E’ chiaro che in questo modo la navigazione per un non vedente diventa più facile, soprattutto
se il progettista delle pagine ha avuto l’accortezza di inserire, oltre che questi marcatori
strutturali di cui parleremo tra breve, anche degli opportuni collegamenti di salto, in genere
non visuali, o delle accesskey per facilitare l’accesso immediato ai titoli principali.
Se invece tutti i blocchi di testo sono marcati allo stesso modo e poi resi in maniera grafica
differente per evidenziarne le rispettive relazioni di dipendenza in modo esclusivamente
visuale, allora la struttura logica rimarrà celata e sarà più difficile per chi non vede
comprendere la natura delle varie parti che compongono la pagina.
Per ovviare a questo problema esistono in (X)HTML numerosi elementi del linguaggio che sono
stati progettati appositamente per dare rilievo alle parti della pagina e alle loro relazioni
organizzando le informazioni in blocchi ed in gerarchie di relazioni. Anzi, HTML è nato
espressamente con questa finalità, come linguaggio a marcatori, e solo in seguito si è involuto
verso una presentazione più spinta.
Un elenco completo degli elementi strutturali e del loro campo di utilizzo è il seguente:
Struttura del documento: HTML, HEAD, BODY rappresentano le principali divisioni
strutturali di un documento (X)HTML;
Intestazioni: H1 ... H6 identificano i sei livelli di titolo previsti da HTML e XHTML ( H1 è il
più importante, H6 il meno importante);
- 79 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Contenitori: DIV e SPAN rappresentano semplici contenitori da collegare a definizioni di
lingua o di stile. DIV per contenuti a livello di blocco, SPAN per contenuti in riga;
Tabelle: TABLE, TR, TH, TD, THEAD, TBODY, TFOOT, CAPTION, COL, COLGROUP: definiscono le
caratteristiche strutturali di una tabella di dati;
Liste non numerate: UL, LI: UL identifica la lista, LI le voci di lista;
Liste numerate: OL, LI: OL identifica la lista, LI le voci di lista;
Liste di definizioni: DL, DT, DD: servono per creare liste di definizioni. DL identifica la
lista, DT il termine da definire, DD la sua definizione;
Paragrafi di testo: P è l'elemento per marcare i normali paragrafi di testo;
Definizioni: DFN racchiude una definizione;
Mappe immagini: MAP, AREA;
Citazioni: BLOCKQUOTE, Q, CITE: da usare per inserire citazioni nel testo;
Moduli: FORM, FIELDSET, LEGEND, INPUT, LABEL, BUTTON, SELECT, OPTGROUP, OPTION, TEXTAREA
servono per creare moduli da inoltrare al server;
Collegamenti ipertestuali: A, LINK definiscono collegamenti a risorse interne o esterne al
documento;
Abbreviazioni ed acronimi: ABBR, ACRONYM;
Enfasi: EM, STRONG: denotano enfasi e forte enfasi;
Codice riportato: SAMP, CODE: identificano, il primo brani tratti dall'output di programmi,
il secondo frammenti di codice di programmazione;
Varie: KBD, VAR: il primo identifica del testo che l'utente deve introdurre tramite
tastiera, il secondo l'istanza di una variabile in un codice di programmazione.
Come segnalato da Michele Diodati1, l'uso di un appropriato codice di marcatura strutturale
renderà più facile la comprensione dei contenuti per i lettori.
Ciò significa:
Usare gli elementi H1...H6 in modo da mostrare l'esatta gerarchia dei titoli presenti nel
testo;
Usare differenti elementi P per differenti paragrafi di testo, invece che, per esempio, un
unico elemento P intervallato da elementi BR per generare le dovute interruzioni di riga;
1
Usare BLOCKQUOTE e Q per le citazioni;
Usare UL ed OL per marcare degli elenchi di dati puntati o numerati;
[http://www.diodati.org/scritti/2004/guida/ele_acc35.asp]
- 80 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Usare TABLE ed i suoi sottoelementi per strutturare opportunamente dati di natura
gabellare;
Usare DL, DT e DD per marcare elenchi di definizioni e DFN per marcare definizioni
isolate;
Usare CODE per specificare frammenti di codice di programmazione.
Il W3C ha preparato un elenco1 di questi elementi, così come degli attributi del linguaggio, nel
documento che riporta le tecniche per applicare le WCAG 1.0. Nella tabella allegata vi si
trovano definizioni e specifiche di impiego per tutti gli elementi del linguaggio.
Nella sintetica presentazione che segue vedremo le caratteristiche dei più importati di questi
elementi, ai fini della corretta strutturazione del documento.
Intestazioni (header)
Le intestazioni o titoli (header) sono gli elementi che identificano le titolazioni da dare ai
contenuti del testo.
L’(X)HTML prevede sei livelli d’intestazioni, da H1 ad H6, H1 rappresenta il titolo più
significativo, H6 il meno significativo.
Il titolo ha la funzione logica di annunciare o racchiudere un argomento che verrà svolto
all’interno di altri elementi strutturali raccolti nell’intestazione.
Le informazioni di intestazione possono essere usate dai programmi utente, ad esempio, per
costruire automaticamente un sommario per un documento.
Le raccomandazioni delle WCAG prevedono, al punto di controllo 3.5: “Usare elementi di
intestazione per veicolare la struttura del documento e usarli in modo conforme alle specifiche.
Per esempio, in HTML, usare H2 per indicare una sottosezione di H1. Non usare intestazioni per
gli effetti di carattere.”.
Gli elementi di titolazione devono essere utilizzati in modo di garantire una corretta
visualizzazione e il rispetto della semantica dei contenuti.
Questa richiesta è dovuta al fatto che i programmi utente di tipo visuale riproducono di solito le
intestazioni più importanti con caratteri più grandi di quelli usati per le meno importanti.
Alcuni autori sono stati tentati nel passato di utilizzare questi effetti per imporre una
visualizzazione in rilievo usando le titolazioni anche per testi che non sono dei veri e propri
titoli.
1
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#html-index]
- 81 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
E’ scorretto utilizzare questi elementi per incrementare la dimensione del testo per diversi
motivi:
Si danneggia la semantica del documento, creando difficoltà d’accesso tramite
tecnologie assistive che potrebbero essere tratte in inganno al momento di riprodurre il
documento. I fogli di stile sono la migliore soluzione per definire le modifiche agli
attributi dei testi;
Alcuni programmi utente come gli screen-reader utilizzano gli elementi di titolazione per
ottimizzare la navigazione della pagina da parte degli utenti e fornirebbero risultati
errati da intestazioni sbagliate;
Anche alcuni algoritmi di ricerca automatica si basano sulle titolazioni per riportare i
loro risultati ed è quindi importante che solo gli elementi strutturalmente significativi
vengano identificati con questo metodo.
Anche per questo bisogna tenere presente che l’ordine di disposizione delle intestazioni deve
esser rispettato.
Ad esempio: uno o più elementi <H2> devono seguire un elemento <H1>, mentre uno o più
elementi <H3> devono seguire elementi <H2>. È quindi scorretto saltare un titolo, ad
esempio: è errato passare da <H1> a <H3> senza valorizzare l’elemento <H2>.
Nel caso si volesse dare meno enfasi al titolo <h2> basterebbe modificare quella singola
istanza con gli opportuni modificatori del CSS.
In genere andrebbe seguita una semplice regola: quella di associare un titolo per ogni
contenuto.
Nell’esempio seguente il codice è stato indentato per una migliore lettura strutturale.
<h1>Primo Titolo</h1>
<p>...</p>
<h2>Titolo argomento A</h2>
<h3>Capitolo informativo 1</h3>
<p>... testo di esempio .....
<h2>Titolo argomento B</h2>
<h3>Capitolo informativ 1</h3>
<p>... testo di esempio .....
<p>... testo di esempio .....
<h3>Capitolo informativo 2</h3>
<p>... testo di esempio .....
<h1>Secondo Titolo</h1>
- 82 -
</p>
</p>
</p>
</p>
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per verificare lo stato delle intestazioni in una pagina (X)HTML ci sono numerosi applicativi
disponibili, tra tutti segnalo la barra di accessibilità1 del AIS (Accessibile Information Solution)
di cui parleremo più avanti ed il validatore ufficiale del W3C, il Markup Validator2, con opzione
show outline. In tal caso viene generato un sommario, una mappa del documento utilizzando
le intestazioni trovate.
Marcatori di lista
Utilissimi elementi per la strutturazione degli elenchi sono i marcatori di lista.
N’esistono di tre tipi:
Liste di definizioni <DL>, definition list;
Liste non ordinate <UL> unordered list;
Liste ordinate <OL> ordered list.
Ognuna di queste ha poi i suoi elementi di lista specificati da < DD> e <DT> per le liste di
definizioni e <LI> per le altre.
Gli elenchi possono anche essere annidati e differenti tipi di elenco possono essere usati
insieme.
Le tecniche per l’accessibilità richiedono per questi elementi al punto 3.6 delle WCAG 1.0 di
“Marcare le liste ed elencare le voci della lista in modo appropriato”.
Questo significa, come specificato poi in un documento 3 di note che i marcatori di lista <DL>,
<UL> e <OL> devono essere utilizzati solo per la definizione delle liste. Non devono essere
impiegati per la formattazione (esempio: rientro del testo), ma solo per costituire un elenco.
Nel caso della strutturazione di una pagina Web le liste si possono rivelare particolarmente utili
anche per realizzare i menù di navigazione. Specialmente quelle ordinate, possono essere
facilmente interpretabili come elementi strutturali, in luogo di un elenco sconnesso di
collegamenti ipertestuali.
Un menù laterale verticale o un menù orizzontale di funzionalità generali possono essere
facilmente realizzati con le liste, poi opportunamente modificate nei fogli di stile per dare il
giusto aspetto di un menù di navigazione.
ul { color: #036; list-style: url(/immagini/pallino.gif) disc; }
1
2
3
[http://www.webaccessibile.org/wat/WAT_IT_1-2.exe]
[http://validator.w3.org/]
[http://www.aib.it/aib/cwai/WAI-WEBCONTENT-TECHS.html#lists]
- 83 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Va aggiunto, come accennato nel capitolo dei fogli di stile, che queste liste andrebbero
corredate con delle opportune tracce contestuali, altrimenti gli utenti non vedenti potrebbero
trovarsi in difficoltà specialmente nelle liste non ordinate ed annidate che non rendono
manifesto lo specifico livello di annidamento raggiunto1. Questi utenti potrebbero avere delle
difficoltà nel percepire dove una lista incomincia e finisce.
Visto quest’impiego particolarmente significativo per dare un risalto strutturale ai menu, le
specifiche delle future XHMTL 2 prevedono un ulteriore sviluppo semantico di questo strumento
con l’introduzione della specifica delle navigation list.
Una lista di navigazione è costituta da una collezione di collegamenti ad altre parti del sito
presentata verticalmente, orizzontalmente o come un menu a discesa. Per implementare
questo tipo di utilizzo, XHTML 2 introduce l’elemento NL che codifica questa funzionalità. Un
ulteriore vantaggio per le tecnologie assistive che possono permettere all’utente di saltare per
intero questo tipo di elementi.2
Divisioni
Gli elementi DIV e SPAN, utilizzati insieme agli attributi ID e CLASS, offrono un meccanismo
generico per aggiungere una strutturazione al documento, questi elementi, definiscono un
contenuto come di tipo inline o block-level (consultare il capitolo sul linguaggio CSS per questi
termini) senza necessariamente richiedere l’utilizzo di elementi presentazionali nel testo.
Nel caso si volesse sfruttare invece anche quest’aspetto, gli autori delle pagine possono poi
impiegare i CSS per dare forma alla visualizzazione prescelta della pagina.
Per quanto lo stesso W3C inserisca questi elementi nell’elenco degli elementi strutturali,
occorre far presente che il loro scopo non è altro che quello di fungere da aggancio per gli stili
che determinano la presentazione visuale della pagina.3
Può capitare, in un documento (X)HTML di incorrere in un uso continuo degli elementi DIV
finalizzati alla definizione degli opportuni elementi caratteristici di una pagina, quali potrebbero
“Non-visual users may "get lost" in lists, especially in nested lists and those that do not indicate the specific
nest level for each list item. Until user agents provide a means to identify list context clearly (e.g., by
supporting the ':before' pseudo-element in CSS2), content developers should include contextual clues in
their lists.” - [http://www.aib.it/aib/cwai/WAI-WEBCONTENT-TECHS.html#lists]
2
“navigation list', consisting of a collection of links to other parts of the site, presented vertically,
horizontally, or as a drop-down menu. To support this type of usage, XHTML 2 introduces the navigation list
element nl, which codifies such parts of documents, and allows different presentational idioms to be applied.
An additional advantage is for assistive technologies, that can allow the user to skip such elements.” –
[http://www.w3.org/TR/xhtml2/introduction.html#s_intro_differences]
3
Michele Diodati: [http://www.diodati.org/scritti/2004/guida/ele_acc24.asp]
1
- 84 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
essere, ad esempio per il mondo delle pubblicazioni, un occhiello, un titolo centrale, un fondo
pagina, un sommario, una prefazione o altro.
In effetti, non esiste un altro modo di fornire questa connotazione semantica se non
indirettamente con l’uso derivato di CLASS o TITLE.
Il motivo è nella natura stessa del linguaggio (X)HTML che dispone di poche strutturazioni per
dare un valore semantico al testo, in pratica solo tre:
Le intestazioni <H1> .. <H6>;
I paragrafi <P>;
Le citazioni <BLOCKQUOTE>.
Escludendo tabelle e liste.
Questo tipo di modifica semantica è allo studio come sviluppo nell’ XHTML 2.0, dove le
specifiche attuali, ancora allo stato di working draft1, prevedono la possibilità di marcare
esplicitamente la struttura di un documento con un elemento SECTION ed un suo relativo
elemento di intestazione H. Questo permetterebbe di dare una migliore connotazione semantica
alla struttura, svincolando i <DIV> da questo uso.
Rispetto dell’aspetto semantico
Nel trattare l’importante argomento della strutturazione logica del documento (X)HTML vorrei
terminare riportando alcune considerazioni di Luca Mascaro in un articolo2 a proposito del
primo requisito della legge Stanca della quale parleremo diffusamente in seguito.
Il requisito introduce esplicitamente l’aspetto semantico dei documenti ed è il seguente:
“Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da
grammatiche formali pubblicate, nelle versioni più recenti disponibili quando sono
supportate dai programmi utente. Utilizzare elementi ed attributi in modo conforme alle
specifiche, rispettandone l’aspetto semantico.”
Il classico esempio che si considera nella spiegazione dell’ultima frase del requisito è quello
dell’elemento BLOCKQUOTE il cui scopo è quello di riportare un blocco di citazioni. Non sono
infrequenti i casi, infatti, in cui quest’operatore è stato ed è tuttora impiegato per ottenere
indentazioni, anche senza riportare alcuna frase citata.
1
“In previous versions of HTML a document's structure had to be inferred from the various levels of
headings in the document; this was particularly a problem when authors misused the heading elements for
visual effects. XHTML 2 lets you explicitly markup the document structure with the section element, and its
related header element h.” - [http://www.w3.org/TR/xhtml2/introduction.html#s_intro_differences]
2
[http://www.webaccessibile.org/argomenti/argomento.asp?cat=532]
- 85 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
E’ un esempio scorretto di come un elemento venga utilizzato non tanto per il suo aspetto
semantico, cioè per il significato che ha, per il compito per cui è stato progettato, quanto
piuttosto per l’effetto che ottiene sui programmi utente, cioè per i suoi aspetti presentazionali.
La scorrettezza nell’uso produce degli errori concettuali, logici e di interpretazione all’interno
della pagina. E questo non solo per i browser grafici che sono soggetti a mutare gli aspetti di
impaginazione a seconda delle loro versioni, quanto piuttosto per i motori automatici di ricerca,
per gli screen-reader ed in genere per tutti i browser testuali che si trovano a trattare un
elemento per il significato che in realtà non possiede.
L’enfasi sull’aspetto semantico è stata riportata fortemente in primo piano proprio dalla
formula che si è scelto di dare al primo requisito della legge Stanca in cui questo termine è
espressamente citato. Ma si trova espressamente anche in altre parti delle WCAG:
WCAG 1.0, punto di controllo 13.2: “Fornire metadata per aggiungere informazione di
tipo semantico alle pagine e ai siti.”;
WCAG 2.0, criterio di successo 1.3.1, criterio di successo 1.3.4: “Usare gli elementi
semantici per contrassegnare la struttura.”.
Come dichiarato1 nelle stesse WCAG 2.0, lo scopo di questa tecnica è di contrassegnare la
struttura del contenuto utilizzando gli appropriati elementi semantici, in altre parole,
utilizzare gli elementi del linguaggio in accordo con il loro significato e non per il modo
con cui rendono graficamente il codice.
Utilizzare gli appropriati elementi semantici garantisce che la strutturazione del codice sarà
interpretabile dai programmi utente, evidenziando esplicitamente il ruolo che le differenti parti
svolgono nella comprensione del contenuto e mettendo in luce le relazioni fra le parti.
Altri esempi particolari citati dalle stesse WCAG 2.0 sono ad esempio EM, ABBR, CITE.
Se gli sviluppatori incominciassero a trattare correttamente questo concetto, un ulteriore
sviluppo degli aspetti semantici del linguaggio (X)HTML sarebbe sicuramente da auspicare al
fine di ottenere una più elevata accessibilità.
Secondo Mascaro una domanda che ci si è posti molto spesso sul primo requisito della legge
Stanca è se effettivamente il codice ha una reale influenza sull’accessibilità.
Personalmente aggiungerei, proprio a proposito di quest’argomento, il codice nei suoi aspetti
semantici, più che il codice in se, che può ovviamente rendere la pagina più o meno
accessibile. Questo del resto è il tema del termine semantico introdotto nel primo requisito.
1
[http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#G115]
- 86 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La risposta di Mascaro, sintetizzata in questi paragrafi, è che il codice HTML o XHTML in tutte le
sue forme e attributi permette una forte suddivisione dei vari tipi di contenuto all’interno delle
pagine grazie all’uso degli attributi necessari per un completo trattamento degli stessi
contenuti.
Questa moltitudine di attributi non è direttamente relazionata con l’accessibilità ma, per
quanto non vi sia una prova rigorosa che l’uso di alcuni elementi migliori l’accessibilità, d’altro
canto non si può neanche affermare il contrario, visto che non si è sicuramente a conoscenza
di tutti i programmi utente sul mercato che potrebbero invece interpretarli al meglio.
Dunque la scelta fatta internazionalmente da tutti gli enti normatori in materia è di stabilire
che un codice completamente valido e ricco di elementi e attributi semanticamente
corretti è il requisito base per l’ accessibilità.
L’Unione Europea ha poi subito recepito e condiviso questo requisito di arricchimento
semantico (sia implicitamente sia nei suoi gruppi di lavoro) chiedendo ai propri membri che
nella formalizzazione delle singole leggi nazionali fosse inserito come requisito di accessibilità.
In conclusione: un buon codice correttamente strutturato e ricco di elementi e attributi per la
tipizzazione e la semanticizzazione dei contenuti permette un dettagliato trattamento dei
contenuti da parte dei programmi utente che potranno così adattarsi e configurarsi sulla base
dei vari tipi di disabilità.
Il principio della multi-modalità
Uno dei principi guida al fine di ottenere una più alta accessibilità dei siti è sicuramente quello
di utilizzare più di un canale sensoriale per veicolare le informazioni presentando una
ridondanza di forme di comunicazione.
A questo concetto si rifanno più o meno tutte le tecniche concepite per migliorare
l’accessibilità.
Lo scopo è evidente, si tratta di poter raggiungere l’utente, anche se questo non possa
disporre di alcune funzionalità fisiologiche. In tal caso, fornire un’alternativa equivalente
tramite un altro canale sensoriale permette una migliore accessibilità della pagina.
Diversi punti di controllo delle WCAG, della legge Stanca e della Section 508, richiamano
questo concetto cardine. In un articolo a cura di Roberto Castaldo pubblicato su
WebAccessibile1 si fa esplicito riferimento alla multi-modalità come principio di accessibilità per
le disabilità cognitive. In realtà questo principio può trovare delle valide applicazioni anche
per le disabilità sensoriali quando esse siano invalidanti di un organo percettivo.
1
[http://www.webaccessibile.org/argomenti/documento.asp?DocID=595]
- 87 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
I suggerimenti1 sono:
Illustrare i concetti con disegni, diagrammi, foto, file audio, filmati, animazioni e altri
forme di comunicazione non testuali.
Comunicare con l’utente attraverso diverse modalità sensoriali e con tutti i modi di
accesso possibili (vista, udito, interazione, lettura) per incrementare la possibilità che il
contenuto sia compreso;
Fornire titolazioni sincronizzate e trascrizioni per le parti audio dei media temporizzati.
Aggiungere titolazioni a file video (con SMIL o SAMI, come spiegato nel capitolo sui
contenuti multimediali) e predisporre un collegamento alla trascrizione testuale;
Fornire descrizioni audio degli elementi visuali dei medita temporizzati.
Narrare l’azione visuale in modo che il video possa essere compreso senza vederlo.
Un concetto strettamente legato è quello della cosiddetta Comunicazione Aumentativa e
Alternativa (AAC in inglese). Questo termine è usato per descrivere tutte le modalità di
comunicazione che possono facilitare e migliorare la comunicazione di tutte le persone che
hanno difficoltà ad utilizzare i più comuni canali comunicativi, soprattutto il linguaggio orale e
la scrittura. Informazioni più dettagliate si possono trovare sul sito2 della Società
Internazionale per la Comunicazione Aumentativa e Alternativa.
Per quanto riguarda le nostre applicazioni nel campo dell’accessibilità, esse sono le più svariate
ed impattano su tutte le normative.
In questo lavoro ci sono dei capitoli dedicati per affrontare questo discorso calato ad esempio
nella gestione degli oggetti multi-mediali, delle alternative testuali, dell’uso del colore, ed in
quella sede verranno considerati le linee guida relative proposte dalle normative.
III.4 - Indipendenza dal dispositivo di presentazione
Da quanto visto a proposito della separazione fra contenuto e presentazione dovrebbe apparire
chiaro che quando un progettista di siti Web si accinge a preparare una pagina da pubblicare
non deve avere in mente come prima cosa il suo aspetto o la sua presentazione, ma piuttosto
la sua struttura logica, in quanto l’aspetto di impaginazione sarà inevitabilmente reso in
maniera differente da programmi utente differenti.
Non è possibile predire a priori le condizioni sotto le quali il sito sarà visitato. Persino avendo la
stessa piattaforma hardware, la stessa velocità di connessione e lo stesso browser del
1
2
Paul Bohman: [http://www.webaim.org/articles/cognitive/cognitive_too_little/]
[http://www.isaac-online.org/en/home.shtml]
- 88 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
visitatore del sito, non è possibile per il progettista sapere a che risoluzione verrà visualizzato il
suo lavoro, o persino se il navigatore abbia un monitor. Per altro alcuni potrebbero averlo in
bianco e nero, ed altri con delle gradazioni cromatiche differenti. Senza contare la possibilità
dell’ingrandimento dei caratteri.
In breve non è possibile imporre una predefinita modalità di visualizzazione della pagine fino a
livello dei pixel.1
Un assunto del genere dovrebbe sembrare piuttosto naturale, dati i concetti esposti, per un
buon progettista Web.
Il fatto che sia impossibile avere l’assoluto controllo sull’aspetto visivo delle pagine, è evidente
anche da alcuni fatti facilmente riscontrabili da una semplice osservazione anche solo dei
browser per utenti normodotati:
Browser obsoleti. Non supportano per nulla i fogli di stile, come Netscape 3 e Internet
Explorer 3;
Browser datati: come Netscape 4 e Internet Explorer 4. Li supportano malissimo
producendo spesso degli errori di visualizzazione o andando in crash;
Browser recenti: quelli cioè che supportano abbastanza bene l'uso dei CSS, come
Internet Explorer 5-6-7, Netscape 6-7, Opera 5-7 e Mozilla nelle sue varie versioni,
presentano differenze più o meno marcate nella resa di determinate proprietà (margini,
bordi, spaziature, posizionamenti, eccetera).
In tutti questi casi il browser impiegato non riprodurrà la pagina con una identica impostazione
grafica costringendo spesso lo sviluppatore ad usare accorgimenti ad hoc.
Tuttavia, questa evidente inconsistenza si scontra contro quello che Michele Diodati 2 definisce
come il pregiudizio della stampa.
L’autore spiega questo termine con una semplice osservazione sullo sviluppo del Web: internet
è una realtà molto recente, con un decennio di vita circa. Gli sviluppatori e gli autori, al
momento di incominciare a progettare le loro prime pagine si sono ispirati ad un modello
preesistente di consolidata efficacia, quello della carta stampata.
Questo procedimento si basa su un accurato posizionamento dei contenuti, in una maniera
perfettamente nota ed invariabile. Qualsiasi lettore avrà accesso all’informazione nel medesimo
modo previsto dal suo creatore.
1
2
[http://joeclark.org/book/sashay/serialization/Chapter05.html]
[http://www.diodati.org/scritti/2004/guida/ele_acc17.asp]
- 89 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Un tale metodo di fruizione del contenuto è dovuto al fatto che il mezzo fisico per trattare le
informazioni è il medesimo per entrambe i soggetti.
Ma per il Web non può essere così. Se ci rifacciamo allo schema introduttivo proposto dallo
stesso W3C, in “Figura 1 - Schema delle interazioni Web”, la separazione tra gli strumenti di
fruizione e di produzione nel nostro caso è netta. Il contenuto viene fruito e prodotto con
strumenti completamente separati, secondo il motto citato: “Write once, read anywhere”.
Da questo ne consegue che il modello della stampa non può essere ripreso con
successo. Esistono una moltitudine di parametri che possono variare tra produttore e
consumatore, tra cui quelli citati prima, come la risoluzione e la grandezza del video, la
grandezza della finestra del browser, la profondità in bit del colore, il sistema operativo, il tipo
e la versione del browser, le disabilità dell’utente e, di conseguenza, il tipo di programma
utente e di interfaccia che viene utilizzata per navigare.
Quindi una filosofia di progettazione basata sulla medesima metodologia precedente è
radicalmente errata. Un autore di contenuti deve capire il prima possibile che non sta
progettando per la stampa dove è possibile avere il controllo di ogni singolo punto 1.
Nonostante la natura strutturale congenita dell’HTML, probabilmente queste osservazioni
dovettero sembrare meno evidenti nelle fasi di primo sviluppo dei siti, anche per la minore
diversificazione di programmi utente e la minore attenzione alle disabilità. In questo modo
molti sviluppatori hanno finito per produrre delle pagine internamente molto complesse e
pesanti, piene di adattamenti mirati, nell’intenzione scorretta di produrre presentazioni
identiche su piattaforme differenti.
Uno sviluppo basato sull'idea che tutti debbano vedere la pagina così come la vede il suo
autore sul monitor del proprio computer (e, per inciso, che tutti debbano vederla...), se non è
proprio una follia, è quanto meno una presunzione irrealizzabile e, per la fruibilità del Web, una
fonte di conseguenze molto dannose.2
Per riassumere con le parole di Joe Clark, si può dire che l’aspetto particolare del sito non
è veramente importante. Se, da un canto, non si intende sacrificare l’aspetto per
l’accessibilità a meno che non sia necessario, dall’altro rimane comunque il fatto che è il
significato del sito ad essere importante, non il suo aspetto. 3
1
Joe Clark: “The sooner you grasp the reality that you are not designing for print, where you can oversee
every single dot on a page, the sooner you will succeed as a Web designer, let alone as a contributor to an
accessible Web.”
2
[http://www.diodati.org/scritti/2004/guida/ele_acc17.asp]
3
Joe Clark: “It will not hurt your feelings to be told that the specific appearance of your site is not really
important; while we will not sacrifice appearance for accessibility unless we have to, it remains true that
your site’s meaning is important, not its appearance.” –
SEGUE >>
- 90 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
III.5 - Trattamento delle immagini
Uno dei principi più importanti per rendere una pagina Web accessibile è quello di fornire un
equivalente testuale per le immagini.
In tutte le fondamentali normative esaminate questo principio viene ribadito con forza:
WCAG 1.0, punto di controllo 1.1: “Fornire un equivalente testuale per ogni elemento
non di testo”;
Section 508, 1194.22 (a): “Bisogna fornire un equivalente in forma testuale per ogni
elemento di natura non testuale”;
D.M. 8 Luglio 2005, requisito 3: “Fornire una alternativa testuale equivalente per ogni
oggetto non di testo presente in una pagina”;
WCAG 2.0, linea guida 1.1: “Fornire alternative testuali per tutti i contenuti non
testuali”;
Le direttive sono tutte della massima priorità e collocate tra i primi principi esposti da ogni
normativa, proprio ad evidenziare che la singola cosa più importante che si possa fare per
rendere accessibile la pagina Web è includere un equivalente testuale per le immagini 1.
Le motivazioni sono piuttosto evidenti, una classe di utenti disabili o non in possesso degli
strumenti necessari potrebbe non poter accedere al contenuto visuale e, se questo veicola
delle informazioni, potrebbe perdere dei contenuti che il sito intendeva trasmettere.
Per fortuna raggiungere un livello minimo di accessibilità per le immagini con i testi alternativi
non è cosa molto complicata, ed anche un livello sufficiente di qualità richiede uno sforzo
accettabile. Più complesso è il caso di altri strumenti multi-mediali per i quali fornire un
equivalente testuale può essere spesso molto oneroso.
Ad ogni modo il compito e l’importanza di quest’attività non può essere sottostimata. I siti Web
sono spesso pieni di alternative testuali di scarsa qualità e poco appropriate.
Strumenti del linguaggio
Il linguaggio (X)HTML presenta le immagini attraverso un elemento IMG eventualmente
annidato in altri elementi quali ad esempio un collegamento ipertestuale.
<img src=“fileImmagine.jpg” alt=“testo alternativo” title=“titolo”
longdesc=“longdesc.html”>
[http://joeclark.org/book/sashay/serialization/Chapter06.html]
1
Jim Thatcher: “The single most important thing you can do to do to make a Web page accessible is to
include alternative text for images”, - [http://www.jimthatcher.com/webcourse2.htm]
- 91 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
<a href=“collegamento.html”><img src=“fileImmagine.jpg”></a>
Ovviamente gli attributi disponibili per l’elemento IMG sono anche altri, oltre a quelli riportati e
possono apparire in ordine arbitrario.
Come si può notare, l’elemento IMG fa riferimento ad un file esterno nel suo attributo SRC
obbligatorio. Questo è un primo aspetto da mettere in evidenza: mentre il testo dell’ (X)HTML
è caricato con la pagina, le immagini risiedono sempre in un file separato che viene richiamato
al momento di visualizzare l’immagine.
Ovviamente non sempre questo file può essere acceduto, mentre un eventuale contenuto
alternativo viene sempre caricato contestualmente alla pagina.
Dato questo meccanismo di separazione, risulta evidente che l’immagine potrebbe non essere
mostrata ad esempio:
Se il file collegato non è disponibile;
Se l’utente ha disabilitato l’uso delle immagini;
Se il programma utente è un browser testuale, uno screen-reader o un motore di
ricerca.
Proprio per ovviare a questi problemi l’(X)HTML ha messo a disposizione tre attributi
fondamentali inseribili nell’elemento IMG per fare in modo che le immagini abbiano comunque
delle alternative accessibili:
ALT: specifica il testo alternativo per i programmi utenti che non mostrano le immagini;
TITLE: fornisce informazioni aggiuntive per l’elemento dove è definito;
LONGDESC: specifica un collegamento ad una descrizione estesa delle immagini in un file
esterno.
Per riassumere i loro ruoli in un commento sintetico di Joe Clark: ALT fornisce le informazioni
minime essenziali, TITLE aggiunge informazioni utili e gradevoli, LONGDESC è impiegato per una
completa ed espressiva documentazione di una immagine visuale.1
Alt
Il più importante dei tre attributi elencati in precedenza è sicuramente ALT, concepito
appositamente con la finalità di fornire un testo alternativo per le immagini fin dal 1992 con le
1
Joe Clark “alt gives you minimal, absolutely essential information; title adds useful information and can add
flavour; longdesc (to be examined shortly) provides for rich, expressive documentation of a visual image.” –
Building Accessible websites, chap. 6
- 92 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
prime specifiche di HTML 2.0, per diventare addirittura obbligatorio per gli elementi IMG ed
AREA
a partire dall’’HTML 4.0.
L’attributo ALT risulta particolarmente utile in diverse circostanze:
Uno screen-reader può leggere il suo valore ed inviarlo ad una barra Braille;
Un browser che non riesca a caricare il file immagine può utilmente mostrare il testo
alternativo dal momento che esso è stato caricato con il resto del testo della pagina;
Un browser con la visualizzazione delle immagini disattivata;
Un motore di ricerca che non riuscendo a leggere l’immagine si può affidare al testo
alternativo per indicizzarne i contenuti.
Il concetto portante dell’attributo ALT è che, come specificato dalla definizione1 del W3C
dovrebbe rappresentare un’alternativa all’immagine, dal momento che ne prende il posto, e
quindi esprimere ciò che la grafica rappresenta o la funzione che l’immagine svolge.
Uno degli errori più comuni è quello di presentare invece una descrizione testuale
dell’immagine senza valutare il contesto della pagina. Parleremo meglio di questo più avanti.
Come accennato, secondo le specifiche di HTML 4.0 e successive l’attributo ALT è obbligatorio, il
motivo è che, come indicato nelle specifiche stesse, può fornire un testo alternativo che serva
come contenuto per gli elementi che non possono essere resi normalmente, venendo incontro
agli utilizzatori di browser testuali2.
Va obbligatoriamente incluso in tutte le immagini, senza alcuna eccezione, tuttavia in alcuni
casi è possibile lasciarlo vuoto (ALT=“”).
Tutti i browser sono in grado di rilevarlo, seppure quelli più datati commettano degli errori nel
visualizzarlo, le versioni 4 di Netscape ed internet Explorer ad esempio lo visualizzano come un
suggerimento a comparsa (tooltip) che appare al passaggio del mouse.
Questo non è un approccio in linea con le direttive3 W3C, poiché l’attributo ALT non dovrebbe
essere considerato come un elemento addizionale, bensì alternativo all’immagine 4.
1
“For user agents that cannot display images, forms, or applets, this attribute specifies alternate text.”
[http://www.w3.org/TR/html4/struct/objects.html#adef-alt]
2
“Several non-textual elements (IMG, AREA, APPLET, and INPUT) let authors
specify alternate text to serve as content when the element cannot be rendered
normally. Specifying alternate text assists users without graphic display terminals,
users whose browsers don’t support forms, visually impaired users, those who use
speech synthesizers, those who have configured their graphical user agents not to
display images, etc.” – HTML 4.0
3
[http://www.w3.org/TR/html4/struct/objects.html#adef-alt]
4
Joe Clark: “a categorical, open-and-shut violation of W3C standards, which hold that alt is a replacement,
not an addition” – Building Accessible Websites, chapter 5
- 93 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Title
Oltre all’attributo ALT, anche l’attributo TITLE può fornire un valido ausilio all’accessibilità.
Per quanto sia meno supportato del precedente, TITLE viene comunque riconosciuto ai giorni
nostri da quasi tutti i browser. Non è un attributo esclusivo delle immagini, anzi può essere
aggiunto alla maggior parte degli elementi dell’(X)HTML, dato che la sua definizione è piuttosto
generica anche nelle specifiche del linguaggio1.
Il W3C non richiede che sia visualizzato in qualche modo particolare. Molti browser visuali lo
mostrano come un suggerimento a comparsa, altri invece lo visualizzano nella barra di stato.
Per quanto riguarda l’accessibilità delle immagini, può essere impiegato per
Aggiungere dettagli opzionali ad un’immagine;
Espandere le informazioni contenute nell’attributo ALT descrivendole con maggiore
accuratezza;
Avvisare gli utenti a proposito di alcuni comportamenti particolari del browser;
Aggiungere un tocco personalizzato.
Ad ogni modo si deve trattare sempre di aspetti aggiuntivi opzionali, gli elementi alternativi
all’immagine devono rientrare nel più fondamentale ALT.
Aggiungere un attributo TITLE è del tutto opzionale, si raccomanda solamente una certa
coerenza nella pagina, per questo, se si decidesse di aggiungerlo ad alcune immagini andrebbe
aggiunto anche a tutte le altre della pagina.
Non è di alcuna utilità aggiungere dei valori di TITLE del tutto identici ai valori di ALT, ad ogni
modo se si decidesse di farlo, si raccomanda di distinguere le due letture, per esempio
circondando il testo di TITLE con delle parentesi quadre.
Longdesc
Quando ALT e TITLE sono insufficienti per la descrizione completa dell’immagine può essere utile
fornire una descrizione più estesa attraverso l’attributo LONGDESC.
L’attributo LONGDESC, non obbligatorio, fornisce la possibilità di accedere ad una descrizione
estesa dell’immagine specificando l’URI del documento che contiene tale descrizione.
A differenza dei precedenti in questo caso si tratta di un vero e proprio collegamento con un
file esterno in formato HTML. Un file separato in cui può, ovviamente, essere aggiunto tutto il
testo descrittivo a piacere.
1
“This attribute offers advisory information about the element for which it is set” – specifiche HTML 4.0.
- 94 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il formato di questo file è quello di un normale file HTML, con tutti i vincoli sintattici del caso.
In un suo paragrafo interno dovrebbe essere contenuta la descrizione accurata dell’immagine.
Va tenuto presente che la descrizione dell’immagine non è necessariamente rivolta solo ad
appannaggio degli utenti non vedenti, le specifiche W3C, infatti, non danno limitazioni
all’utilizzo di questo attributo per i browser testuali.
Da questo punto di vista, LONGDESC risolverebbe il problema di dare delle accurate descrizioni
alle immagini, per esempio per quanto riguarda un sito di fotografie o l’andamento accurato di
un grafico. Il problema è che, per quanto questo attributo sia nelle specifiche HTML 4, quindi
fin dal 1999, pochi browser lo supportano, tra cui vanno ricordate le versioni più recenti di
JAWS, Mozilla, Netscape e iCab.
Il motivo potrebbe anche risiedere nel fatto che pochi progettisti di pagine Web ne fanno uso,
anche per il fatto che nelle normative WCAG 1.0 si affiancava a questa tecnica quella del
cosiddetto d-link per collegare un file descrittivo esterno.
Un d-link consiste nel fornire un collegamento descrittivo visibile pensato per quei programmi
utente che non supportano l’attributo LONGDESC, apponendo al fianco dell’immagine da
descrivere un collegamento ipertestuale evidenziato da una lettera “d”, spesso maiuscola e
circondata da parentesi quadre ([D]). Questo collegamento non rimanda ad altro che allo
stesso file a cui rimanda LONGDESC, ed era stato introdotto proprio per la riluttanza dei
programmi utente ad implementare le specifiche ufficiali del W3C sul LONGDESC.
Tuttavia con il tempo sono sorte alcune controindicazioni a questa tecnica, tra cui il fatto che
nel caso di diverse immagini nella pagina possa essere equivoco un collegamento non autoesplicativo e soprattutto che esista un equivalente LONGDESC presente invece nelle specifiche
ufficiali.
Tutto questo ha portato le WCAG 2.0 a deprecare l’uso del d-link, come ribadito nel documento
di tecniche di applicazione1 per l’HTML.
Testi alternativi
Una caratteristica fondamentale di un sito ad elevata accessibilità è costituita dalla
presenza di buoni testi alternativi. Questo poiché la comprensione di una pagina per chi naviga
con un browser testuale sarà tanto maggiore quanto più sono validi i testi alternativi
eventualmente presenti.2
1
2
[http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20041008/] – Ch. 10.9
Michele Diodati “Guida all’accessibilità dei siti Web”
- 95 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il problema, come affermato da molti studiosi tra cui anche Luca Mascaro1, è che il testo
alternativo è difficile de scrivere.
Senza avere la pretesa di esporre l’argomento in modo esaustivo vorrei qui comunque dare
una presentazione del problema e delle impostazioni di base per affrontarlo.
Abbiamo visto che l’attributo ALT viene introdotto obbligatoriamente dall’HTML 4.0 per tutti gli
elementi IMG, allo scopo di fornire un testo alternativo alle immagini.
Per preparare un valido testo alternativo occorre analizzare il contenuto e la funzione
dell’immagine. Spesso la funzione dell’immagine è di fornire un collegamento, valutare invece
il contenuto dell’immagine può essere più difficile.
Il testo alternativo ha il compito di:
Essere letto dagli screen-reader in luogo delle immagini, facendo in modo che il
contenuto e la funzione delle immagini vengano resi accessibili ai non vedenti o ai
disabili cognitivi;
Essere visualizzato al posto delle immagini dai programmi utente che non supportano o
hanno disattivata la visualizzazione delle immagini;
Fornire un valore semantico ed una descrizione dell’immagine per i motori di ricerca.
Seguendo una impostazione presentata dal sito WebAIM 2 ritengo corretto specificare che il
testo alternativo può essere fornito in due modi:
Nell’attributo ALT dell’elemento IMG;
Nel contesto o intorno alla stessa immagine.
L’attributo ALT, quindi, non è il solo meccanismo per fornire il contenuto e la funzione
dell’immagine, queste possono essere anche fornite con un testo adiacente all’immagine o
altrimenti contenuto nella pagina3.
Per quanto tutte le immagini debbano essere necessariamente dotate dell’attributo ALT, al
limite vuoto, al momento di predisporre un attributo ALT occorre tenere ben presente il
contesto in cui l’immagine viene presentata. Il contesto può cambiare di molto il valore del
testo da inserire, soprattutto se la pagina (X)HTML presenta già degli adeguati contenuti
informativi sull’immagine.
1
Conferenza IWA sulla legge Stanca, Arese, Maggio 2005
[http://webaim.org/techniques/alttext/]
3
“This means that the alt attribute (sometimes called the alt tag, though technically this is incorrect) is not
the only mechanism for providing the content and function of the image. This information can also be
provided in text adjacent to the image or within the page containing the image.”
2
- 96 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In tutti i casi, l’attributo ALT dovrebbe:
Essere accurato ed equivalente, presentando lo stesso contenuto e le stesse funzionalità
offerte dalle immagini;
Essere succinto, generalmente dovrebbero essere necessarie non più di poche parole o
al massimo un paio di frasi in casi estremi;
Non essere ridondante evitando di fornire le stesse informazioni che si possono trovare
nel contesto della pagina.
Dati questi requisiti, non sono per nulla da sottovalutare le difficoltà che si possono incontrare
nel produrre testi alternativi validi, le competenze e l’esperienza per produrre del testo valido
vanno spesso al di là di quelle possedute da un normale programmatore in (X)HTML.
Chi scrive i testi, in genere, è lo stesso programmatore della pagina (X)HTML, quindi, di solito
si tratta di un tecnico del codice, non un esperto nella materia che sta esponendo e nemmeno
un letterato in grado di trovare le espressioni migliori.
Senza contare poi che, chi deve scrivere i testi è molto spesso una persona normodotata,
vedente ed abituata ad osservare la pagina Web senza ausili particolari. Questo stato di cose
impedisce spesso ai progettisti di avere una corretta sensibilità al problema che permetta loro
di capire cosa valga la pena essere descritto e cosa invece non sia importante.
Una ulteriore annotazione è stata espressa da Luca Mascaro durante la conferenza IWA, spesso
a questa attività viene dedicato poco tempo, ed in una situazione di sviluppo troppo spesso
frenetico e convulso delle pagine Web si finisce per considerare tempo perso quel tempo
dedicato ad una corretta stesura dei testi.
Tutti questi fatti portano spesso al proliferare nelle pagine internet di una notevole quantità di
testi alternativi scorretti.
A questo si aggiunga che i normali validatori del codice, come quello ufficiale del W3C, il W3C
Markup Validator1, non sono in grado di leggere all’interno dell’attributo ALT, per cui essi si
possono solo limitare a verificarne la presenza. Qualsiasi testo venga poi incluso, questo non
viene verificato, sia che esso sia stato inserito automaticamente da programmi appositi, sia
che esso sia vuoto o del tutto inadeguato allo scopo.
Utili articoli su come scrivere testi corretti, ne sono stati scritti molti e molti sono reperibili su
internet. Oltre a quelli di Joe Clark2, Michele Diodati3, Jim Thatcher4 alla base di queste
1
2
3
4
[http://validator.w3.org]
[http://joeclark.org/book/sashay/serialization/Chapter06.html]
[http://www.diodati.org/scritti/2004/guida/ele_acc31.asp]
[http://www.jimthatcher.com/webcourse2.htm]
- 97 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
osservazioni, vi sono anche le sezioni di WebAIM1 e dei siti specifici dedicati alla accessibilità
della grafica. Su tutti viene spesso segnalato anche un articolo di Alan Flavell2 tradotto in
italiano da Michele Diodati3. Quest’ultimo, per quanto relativamente datato (è del luglio 2002 e
non tratta completamente l’utilizzo di LONGDESC e TITLE), ha comunque il pregio di essere
abbastanza sintetico ed efficace sulla esposizione dei principi di scrittura di questi testi, ed è
riassunto in seguito.
Tipologie di immagini
L'errore più comune che si può commettere sul testo alternativo (a parte il non fornirlo per
niente) consiste nell'offrire una descrizione dell'immagine, senza valutare quale funzione
l'immagine svolga nella pagina. Si deve ricordare che il testo ALT è stato pensato per essere
una conveniente alternativa testuale in relazione allo scopo dell'immagine.
Flavell prevede tre tipologie fondamentali di utilizzatori per le pagine Web:
Quelli con il caricamento delle immagini abilitato. Esempio: un qualsiasi browser
grafico;
Quelli che navigano in modalità testuale, ma che possono visualizzare le immagini se lo
desiderano. Esempi: browser grafici con l'auto-caricamento delle immagini disabilitato,
Lynx con un visualizzatore grafico disponibile come applicazione ausiliare;
Quelli che dispongono della sola modalità testuale e non possono visualizzare immagini
in nessun caso. Esempi: un terminale in modalità carattere, lettori che usano un
sintetizzatore vocale, Robot di indicizzazione.
L’attributo ALT è progettato soprattutto per gli utenti delle categorie 2 e 3. Tuttavia nulla
impedisce che un navigatore della prima categoria ne possa usufruire, ad esempio nel caso che
gradisca la lettura automatica durante la visita della pagina.
In relazione a queste tipologie di utilizzatori, Flavell riporta quattro tipologie di immagini
presenti sul Web:
Immagini decorative della pagina:
Sono immagini non essenziali, un attributo ALT non potrebbe aggiungere nulla di utile
all’argomento del discorso. In tal caso la codifica vuota (ALT=“”) potrebbe essere la
soluzione migliore, infatti l’utente con lettore vocale risentirebbe della lettura di
descrizioni che non rientrano nel contesto.
1
2
3
[http://webaim.org/techniques/alttext/]
[http://ppewww.physics.gla.ac.uk/%7Eflavell/alt/alt-text.html]
[http://www.diodati.org/scritti/2002/g_alt/index.htm]
- 98 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Nel caso l’immagine venga utilizzata come collegamento ipertestuale è consigliabile
includere del testo significativo nell’elemento < A> ed evidenziare questo come
collegamento.
In questa categoria possono ricadere:
o
Icone di avviso (ALT=“!”);
o
Icone di domanda (ALT=“?”);
o
Immagini spaziatrici (ALT=“&NBSP;”);
o
Pallini segnaposto (ALT=“*”);
o
Arte ASCII (un avviso che spieghi al lettore il contenuto);
o
Loghi societari, in tal caso se il nome della dittà è già accanto all’immagine, si
può usare un ALT vuoto, altrimenti ALT=“nome ditta” è appropriato;
Icone di navigazione:
Si usano per rimandare ad altri documenti o a parti di essi.
Per questo l’equivalente in genere è abbastanza semplice e si suggerisce una breve
descrizione della destinazione (precedente, successivo, in testa alla pagina) o della
funzione (indice, sommario, fantascienza). In questa descrizione evitare di sovrapporsi
a quelle interne del browser (Back, Home, Forward) ed evitare la frase “indietro a xxx”,
dal momento che si potrebbe provenire da pagine differenti.
Per le mappe immagine, si consiglia di creare delle risorse alternative, quali, ad
esempio un elenco esplicito e ridondante di collegamenti testuali a parte o una serie
separata di immagini, ciascuna con il proprio attributo ALT. Una sezione apposita di
questo lavoro si occupa di discutere questo elemento (X)HTML;
Immagini aggiuntive o di interesse:
Sono immagini che possono essere di qualche aiuto nell’apprezzamento del testo, ma
non sono necessarie. E’ possibile averle sia in linea con la pagina che con un apposito
collegamento esterno. Nel primo caso fornire un testo che riassuma la caratteristica
essenziale dell’immagine, nel secondo evidenziare che cosa viene offerto con
l’immagine da caricare esternamente. E’ anche possibile fornire una miniatura
dell’immagine in linea e predisporre un collegamento all’immagine ingrandita. Il
secondo tipo di lettori possono in questo modo decidere se scaricare o meno l’immagine
esterna mentre quelli del terzo non si sentiranno frustrati;
Immagini critiche per la comprensione della pagina:
In alcuni campi questa situazione non è frequente, in altri (ingegneria, matematica e
scienze) è una circostanza piuttosto comune. In questo caso, premesso che si sia in
qualche modo avvisato il lettore della importanza dell’immagine, non ci sono molte cose
che si possano fare con l’attributo ALT. Si possono impiegare più proficuamente
LONGDESC
e, in taluni casi, l’utilizzo di un linguaggio a marcatori specifico come MathML
(Flavell menziona LaTex).
- 99 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Come lo stesso Flavell ricorda, la distinzione fra queste categorie non è spesso facile,
soprattutto negli ultimi due casi, poiché quello che può sembrare essenziale per un lettore può
non esserlo per un altro.
Un’utile tabella1 riassuntiva di questi suggerimenti viene allegata dallo stesso Flavell al suo
articolo.
Annotazioni conclusive
Vediamo alcune particolarità conclusive sull’uso dei testi alternativi:
Spaziature.
In un gruppo di immagini ravvicinate e senza separatori può accadere che i testi
alternativi finiscano per congiungersi.
In tal caso sono possibili diverse soluzioni:
Utilizzare uno spazio vuoto nei testi alternativi, a destra o a sinistra o in
entrambe le posizioni;
Utilizzare una barra verticale come separatore nel contenuto dell’attributo ALT;
Utilizzare le parentesi quadre per racchiudere il testo dell’attributo ALT.
Giacché molte di queste situazioni si verificano quando si fa uso di immagini come
elementi di navigazione, una implementazione migliore potrebbe essere quella di
fornire dei collegamenti testuali come meccanismo di navigazione e impiegare poi i
CSS per una presentazione più gradevole dei menu. In tal caso non risulta necessario
ricorrere ad alcun attributo ALT.
Attributo ALT vuoto.
Come visto in precedenza ci sono dei casi in cui l’attributo ALT non porta alcuna
informazione utile al contesto, anzi, una sua eventuale compilazione appesantirebbe
inutilmente la pagina Web con del testo inutile e fonte di confusione per i browser
testuali.
Tuttavia l’attributo ALT, come detto, è stato reso obbligatorio a partire dalle specifiche
HTML 4.0 in poi. Ci possono essere delle situazioni in cui il testo può essere lasciato
vuoto, in particolare si fanno presenti i seguenti casi:
1
Immagini spaziatrici usate per la creazione di impaginazioni specifici;
Immagini che hanno già un alternativa testuale all’interno della pagina come ad
[http://ppewww.physics.gla.ac.uk/%7Eflavell/alt/alt-table.html]
- 100 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
esempio fotografie con titolo e descrizione presenti in calce, in formato testo o di
collegamento;
Immagini decorative come ad esempio cornici.
Nella preparazione del testo ci sono alcuni errori comuni che vanno sempre evitati, in
particolare, l’attributo ALT:
Non deve contenere le espressioni “immagine di..”, o simili, dal momento che gli
screen-reader hanno dei propri metodi per avvisare gli utenti, mentre nei browser
testuali risulta evidente il fatto che si tratti di una immagine;
Non deve essere utilizzato come segnaposto durante il caricamento dell’immagine
introducendo nel testo frasi come “attendere, caricamento immagine in corso”.
Vorrei chiudere questa breve disamina con un’importante notazione sulla verifica automatica e
sul controllo della validità dell’attributo ALT.
Come già accennato il validatore ufficiale del W3C non è in grado di controllare il contenuto
semantico. Sicuramente non molti passi in avanti possono essere fatti con degli automatismi.
Si tratta evidentemente di uno di quei casi in cui la verifica umana è strettamente necessaria,
ed anche in questo caso qualche volta i giudizi possono anche non essere condivisibili.
Un controllo sul fatto che il testo sia più o meno appropriato può essere fatto immaginando che
il documento (X)HTML venga visualizzato senza le immagini, o immaginando di leggere il
documento a qualcuno per telefono chiedendosi se il testo degli ALT fornisce informazioni utili
sull’argomento del discorso.
Ascii Art
Un’ultima nota di questo discorso vale la pena presentarla per la cosiddetta ASCII Art,
ovverosia l’uso di caratteri di testo per costruire e presentare immagini e disegni.
In questa categoria ricadono anche l’utilizzo delle emoticon, le cosiddette faccine, come “:-)”,
“:-(” ed esempi simili.
Una delle citazioni più riportate in questo caso è quella del RNIB (Royal Institute of Blind),
l’istituto nazionale britannico dei non vedenti, il quale richiede di non impiegare questa tecnica
evitando di usare caratteri testuali in luogo delle immagini1.
La posizione del W3C è sulla stessa linea1, anche se leggermente più permissiva. Mi riferisco in
particolar modo alle ultime direttive esposte nel documento di tecniche 2 HTML per le WCAG
1
“Avoid using text characters as substitute graphics, icons or glyphs”
- 101 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
2.0 ancora allo stato di Working Draft al momento di questa stesura. In questo documento si
raccomanda di non utilizzarle o di fornire ad ogni modo dei meccanismi per saltarle con un
collegamento posto prima dell’ASCII art.
Per le emoticon si raccomanda di rimpiazzarle con degli equivalenti in linguaggio naturale.3
III.6 - Uso del colore
L’uso del colore è argomento di analisi per tutte le normative, in particolare:
WCAG 1.0 linea guida 2: “Garantire che testo e grafica siano comprensibili quando visti
senza il colore.”;
Section 508 1194.22 (c): “Tutte le informazioni fornite tramite colori siano anche
disponibili senza l'utilizzo di tale mezzo.”;
D.M. 8 Luglio 2005, requisito 4: “Garantire che tutti gli elementi informativi siano
disponibili anche in assenza del particolare colore utilizzato per presentarli nella
pagina.”;
WCAG 2.0 Success Criteria 1.3.2: “Qualunque informazione che è veicolata dal colore
risulti anche essere visivamente evidente senza colore.”.
Si tratta di un’evidente conseguenza del principio della ridondanza delle informazioni che
devono essere trasmesse anche in una modalità alternativa rispetto all’uso puro e semplice del
colore.
Le motivazioni che portano a queste direttive sono state concepite per venire incontro agli
ipovedenti, o a coloro che hanno problemi a distinguere i colori come gli acromati.
La disabilità visuale è trattata in un capitolo a parte, nel resto di questa disamina si cercherà di
mettere in risalto quali sono i necessari accorgimenti da mettere in pratica per venire incontro
a queste disabilità.
Vorrei comunque ricordare che, più in generale, la scelta di opportuni colori può rendere la
navigazione e la comprensione delle informazioni più facilmente fruibile anche a visitatori
normo-vedenti4.
1
“Avoid ASCII art (character illustrations) and use real images instead since it is easier to supply a text
alternative for images. However, if ASCII art must be used provide a link to jump over the ASCII art.”
2
[http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20041008/]
3
“another way to replace ASCII art is to use human language substitutes. For example, <wink>might
substitute for a winking smiley: ;-). Or, the word "therefore" can replace arrows consisting of dashes and
greater than signs (e.g., -->), and the word "great" for the uncommon abbreviation "gr8".
4
“The proper use of color can also increase the user's performance in computer based decision support
systems. In contrast, a poor selection of text-background color combinations can significantly detract from a
SEGUE >>
- 102 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Principi fisici
Penso che sia utile partire da una breve descrizione del colore dal punto di vista fisico e
percettivo.
Mi limiterò ad esporre i concetti fondamentali, una descrizione accurata si può trovare su
internet in diversi siti, suggerisco Franco Frascolla1, Michele Diodati2 e Aries Arditi3 ed un
interessante articolo riassuntivo di foto-editing4.
Le teorie del colore sono numerose e relazionate alle finalità per le quali sono state concepite.
Alla base di tutte c’è la suddivisione della luce bianca con la rifrazione del prisma di Newton in
frequenze separate disposte idealmente su una circonferenza con una lunghezza d’onda dai
460 nm del blu ai circa 700 nm del rosso. I colori presenti lungo la circonferenza del cerchio di
Newton sono detti colori spettrali, cioè sono componenti identificabili nello spettro cromatico in
cui l'interposizione di un prisma scompone la luce bianca. Ma esistono molti altri colori visibili,
ad esempio il rosa e il marrone, non presenti in questa gamma. Si tratta dei cosiddetti colori
non spettrali, generati da una mescolanza di due o più dei colori spettrali o da un’attenuazione
dei medesimi.
L’occhio umano ha tre ricettori per i colori, sensibili a picchi di frequenze differenti. Una breve
descrizione è esposta nel paragrafo delle cecità ai colori.
Per la nostra esposizione inerente all’accessibilità del Web sarà sufficiente qui considerare tre
teorie applicative:
RGB (Red, Green, Blue), cioè rosso, verde e blu. Un sistema particolarmente mirato ai
monitor e ai televisori;
HSB (Hue, Saturation, Brightness) cioe tonalità, saturazione e brillantezza, anche detto
HSV (Hue, Saturation, Value). Un sistema particolarmente orientato alla prospettiva
umana. Una sua variante con un principio simile è il sistema HSL (Hue, Saturation,
Lightness);
YIQ, che rappresentano luminanza, fase e quadratura. Un sistema impiegato nei primi
standard televisivi americani NTSC. Sostituito dal sistema YUV sia per NTCS che per
PAL.
document's readability.” – [http://www.aprompt.ca/WebPageColors.html]
1
[http://www.frascolla.org/Saggio/Saggio_v2.htm]
2
[http://www.diodati.org/scritti/2002/g_colori/index.asp]
3
[http://www.lighthouse.org/color_contrast.htm]
4
[http://www.carla146.it/01PPtips/tiptesti/30rgbcmyk.htm]
- 103 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il sistema RGB
Il sistema RGB è un modello additivo discreto in cui i tre colori primari si compongono per
ottenere gli altri. La scelta dei tre colori è basata su una similitudine con il sistema visivo
umano, per quanto non sia valido un paragone diretto.
Una delle applicazioni comuni del sistema RGB è la visualizzazione del colore su sistemi per
televisori o monitor, in tal caso ogni pixel dello schermo rappresenta un valore RGB della
scheda grafica, questi valori sono convertiti in segnali ed inviati al display.
Usando questa rappresentazione si possono visualizzare molteplici colori discreti. In genere si
utilizza una rappresentazione a 24 bit totali, 8 per il rosso, 8 per il verde ed 8 per il blu dando
256 possibilità per ogni tonalità. Con queste scelte si riescono a visualizzare circa 16 milioni di
colori discreti.
Figura 2 – Modelli grafici tridimensionali del colore tipo RGB e HSB
Il sistema HSB
Il sistema HSB invece, detto anche HSV (Hue, Saturation, Value) è stato creato nel 1978 da
Alvy Ray Smith. Si tratta di una trasformazione non lineare del sistema RGB ed ha il vantaggio
di essere più vicina alla visione umana e di rappresentare tutta la gamma dei colori percepibili
Le tre grandezze sono:
La tonalità (Hue) è la frequenza del colore puro, caratterizzato da una singola
lunghezza d'onda all'interno dello spettro visibile della luce. Quanto più la luce incidente
su un certo punto della retina è riducibile ad una banda ristretta di lunghezze d'onda
tanto più netta e precisa sarà per l'osservatore la possibilità di attribuire un nome al
colore percepito. In genere si indica, appunto, con un valore angolare da 0 a 360
gradi;
La saturazione (saturation) è l'intensità di una specifica tonalità. E’ una misura della
purezza del colore, una tinta molto satura ha un colore vivido, mentre al diminuire della
- 104 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
saturazione il colore diventa più debole e tende al grigio. Se la saturazione viene
completamente annullata, il colore si trasforma in una tonalità di grigio. I colori spettrali
sono quelli che hanno la maggiore saturazione. Ha un valore continuo da 0 a 1 e si
indica in genere con la lettera greca sigma minuscola;
La brillantezza (brightness) è la quantità totale di luce che una sorgente luminosa
appare emettere (o che appare riflessa da una superficie). Ha un valore continuo da 0 a
1 e si indica in genere con la lettera grega mu. E’ una determinazione della quantità di
bianco o di nero presente nel colore. A differenza della luminosità ( lightness), questo
valore non dipende dal contesto in cui viene fatta una osservazione.
Questi tre attributi percettivi del colore possono essere visualizzati come un sistema di
coordinate all’interno di un cono in cui la tonalità varia intorno al solido, la brillantezza varia
dalla cima al fondo, e la saturazione è la distanza dal centro.
Altri sistemi di rappresentazione, usati soprattutto per il sistema HSV, sono quelli di un
triangolo iscritto in una circonferenza. Sulla circonferenza sono riportate le diverse gradazioni
di tonalità. Una volta fissata questa, all’interno del triangolo si definiscono la saturazione
spostandosi lungo l’altezza, ed il valore spostandosi lungo la base.
Il sistema YIQ
Il sistema YIQ è relativamente obsoleto, viene citato in questo lavoro dal momento che le
formule della legge Stanca e del WCAG 1.0 ne fanno un uso indiretto.
In questo spazio dei colori la componente Y rappresenta il cosiddetto luma tradotto a volte con
brillanza, cioè la sola componente impiegata dai televisori in bianco e nero. I e Q
rappresentano invece l’informazione del colore, la cosiddetta chrominance (tradotto a volte
con crominanza o cromaticità). Nella rappresentazione YUV che l’ha sostituita, Y è rimasto
immutato, mentre UV sono su un piano sfalsato di 33 gradi rispetto a quello fornito dalle
componenti IQ.
Lo scopo del sistema YIQ era quello di adattarsi alla risposta ai colori dell’occhio umano.
L’occhio, infatti, è più sensibile ai cambiamenti nell’intervallo arancione/blu, rappresentato
dalla coordinata I, piuttosto che in quello porpora/verde rappresentato dalla coordinata Q, per
questo motivo i valori nei due campi avevano degli estremi differenti.
- 105 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Esistono delle formule di conversione lineare1 tra lo spazio dei colori YIQ e lo spazio dei colori
RGB, proprio una di queste, quella che fornisce Y in relazione a R, G e B, è quella che viene
impiegata dalla legge Stanca e dalle WCAG 1.0 per fornire il valore della luminosità.
Criteri di realizzazione
Visti i criteri fisici del colore vediamo quale dovrebbe essere il loro impiego corretto.
Distinguerei 2 casistiche fondamentali che corrispondono fondamentalmente a 2 punti di
controllo delle WCAG 1.0:
a) Punto di controllo 2.1: il colore veicola di per sé una informazione (un semaforo rosso,
un collegamento ipertestuale disponibile o già visitato), “assicurarsi che tutte le
informazioni veicolate dal colore siano disponibili anche senza.”;
b) Punto di controllo 2.2: il rapporto fra due colori ostacola o favorisce la trasmissione di
un contenuto (testo su sfondo, la differenza fra due zone adiacenti del video se
comunica una informazione), “assicurarsi che il contrasto tra lo sfondo ed il primo piano
sia sufficiente.”.
Punto di controllo 2.1
Nel primo caso il colore non deve essere usato per identificare in modo univoco informazioni o
funzionalità. Ad esempio, se si utilizzano i fogli di stile (CSS) per cambiare il colore ai
collegamenti ipertestuali o per rimuovere la sottolineatura predefinita, gli utenti con le
suddette problematiche potrebbero riscontrare difficoltà nella navigazione del sito.
Sarà indispensabile rendere chiaramente identificabili le parti di testo che richiedono attenzione
da parte dell’utente, ed offrire la stessa informazione con altre modalità del tutto indipendenti
dal colore.
In questo senso possono essere impiegate varie tecniche, secondo il contesto informativo, ad
esempio:
1
Forme geometriche alternative per gli elementi grafici;
Un attributo TITLE utile per i browser testuali;
Un testo esplicativo aggiunto nella pagina;
Una marcatura appropriata nel linguaggio (X)HTML;
Altri attributi visuali alternativi, ad esempio enfasi, bordi, uno sfondo differenziato.
[http://en.wikipedia.org/wiki/YIQ]
- 106 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Punto di controllo 2.2
Per quanto riguarda invece il secondo caso, il rapporto fra due colori, il criterio guida è di
accostare dei colori che raggiungano un sufficiente contrasto tra loro.
Questo sia per il rapporto tra colore del testo e colore di sfondo, quanto per la distinzione fra
colorazioni adiacenti che debbano essere rese distinte.
Il contrasto si definisce quindi in relazione al rapporto fra due colori, ed è questa la grandezza
di cui si deve tenere conto più che il colore in se stesso.
Di primaria importanza è che il contrasto non deve essere esclusivamente il risultato di una
semplice differenza di tonalità (hue) dei colori, come per esempio tra verde e rosso
ugualmente saturi, ma piuttosto il risultato di una differenza di brillantezza (brightness) o
di luminosità. Questa differenza, infatti, risulta maggiormente percepibile rispetto alla
differenza di tonalità soprattutto da parte di chi soffre di cecità ai colori.
In questo senso le direttive proposte dalle normative sembrerebbero essere piuttosto esplicite,
infatti, sia le WCAG sia la legge Stanca propongono delle formule ben determinate per la
valutazione del contrasto.
Due colori sono in grado di fornire una buona diversità di percezione se la differenza di
luminosità e la differenza di tonalità sono maggiori di una soglia stabilita tramite due formule
precise1:
Formula della luminosità (luma) dei colori:
La luminosità dei colori è determinata dalla seguente formula: ((Valore Rosso X 299) +
(Valore Verde X 587) + (Valore Blu X 114)) / 1000
La differenza fra la luminosità dello sfondo e quella del colore di primo piano dovrebbe
essere maggiore di 125.
Formula della differenza di colori:
La differenza di colori è determinata dalla seguente formula: (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 blu 1,
valore blu 2) - minimo (valore blu 1, valore blu 2))
La differenza fra la colori di sfondo e quella di primo piano deve risultare maggiore di
500.
1
[http://www.w3.org/TR/AERT#color-contrast]
- 107 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Nella prima di queste due formule il valore che definisce la luminosità è esattamente uguale
alla trasformazione lineare che fornisce il luma nelle formule di conversione tra YIQ e RGB.
Nella seconda si parla invece più generalmente di colore considerando tutte le tre componenti
RGB.
Hewlett Packard (HP) fornisce uno strumento di verifica del contrasto fra colori che utilizza gli
algoritmi del W3C, ma abbassa il livello minimo di differenza di tonalità a 400, il che aumenta il
numero di combinazioni sfondo/primo piano considerate accettabili.
Per quanto lo stesso W3C aveva dichiarato, nel fornire questo algoritmo, che si trattava di un
suggerimento temporaneo1, tuttavia, vuoi per il fatto che si trovasse sulle pagine ufficiale del
W3C, vuoi perché risultava uno dei pochi espressamente pubblicati, esso è diventato, di fatto,
uno standard valutativo.
Pertanto, a seguito di queste formulazioni, è stato reso disponibile un valutatore apposito, il
Colour Contrast Analyzer del Juicy studio2, un piccolo applicativo in grado di dare un risultato
immediato di questi valori con un semplice passaggio del mouse.
Il sistema è integrato anche nella barra di accessibilità3 ed è scaricabile in versione italiana dal
sito di WebAccessibile4. Tuttavia questo programma come segnalato da Michele Diodati 5,
presenta alcune lacune di valutazione, almeno nella versione disponibile con i criteri delle
WCAG 1.0.
Nonostante questo, anche la legge italiana lo ha ufficialmente adottato nella stesura della
propria normativa. Il testo seguente è riportato dall’allegato A dei requisiti tecnici, punto 2.d,
consultabile in appendice.
Verifica delle differenze di luminosità e di colore tra il testo e lo sfondo secondo i seguenti
algoritmi:
1. Differenza di luminosità: calcolo della luminosità dei colori di testo e di sfondo con la
formula: ((Rosso X 299) + (Verde X 587) + (Blu X 114)) / 1000, in cui Rosso, Verde e
Blu sono i valori decimali dei colori; il risultato deve essere non inferiore a 125.
2. Differenza di colore: calcolo della differenza di colore con la formula[Max (Rosso1,
Rosso2) - Min (Rosso1, Rosso2)] + [Max (Verde1, Verde2) - Min (Verde1, Verde2)] +
[Max (Blu1, Blu2) — Min (Blu1, Blu2)], in cui Rosso, Verde e Blu sono i valori decimali
dei colori e Max e Min il valore massimo e minimo tra i due presi in considerazione; il
1
2
3
4
5
“This is a suggested algorithm that is still open to change”
[http://juicystudio.com/services/colourcontrast.php]
[http://www.webaccessibile.org/wat/WAT_IT_1-2.exe]
[http://www.webaccessibile.org/css/]
[http://www.contrastocolori.org/archives/critiche_e_proposte/]
- 108 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
risultato deve essere non inferiore a 500;
Un’ultima annotazione importante riguarda le priorità assegnate alla linea guida 2.2, dove le
raccomandazioni per il contrasto della grafica hanno priorità 2, mentre quelle per il contrasto
del testo hanno priorità 3. Una maniera piuttosto discutibile di applicare l’accessibilità.
Questo ed altri fatti hanno portato a diverse critiche a proposito di queste raccomandazioni,
critiche che sono state tenute in debito conto con lo sviluppo delle WCAG 2.0.
Critiche ed aggiornamenti
Come accennato si sono diffuse alcune annotazioni negative sulle precedenti raccomandazioni.
Molte sono dovute al fatto che la leggibilità ed il buon contrasto dei testi dovrebbe essere posto
tra i requisiti obbligatori (priorità 1) piuttosto che tra quelli facoltativi (priorità 3) come se
fosse una cosa di cui si può anche fare a meno senza troppo inficiare l’accessibilità.
Si suggerisce pertanto di tenere invece questa raccomandazione in dovuto conto, soprattutto
alla luce del fatto che con le WCAG 2.0 testi e grafica sono stati parificati al secondo livello di
priorità per una minima leggibilità come vedremo nel paragrafo successivo.
Altra nota critica riguarda l’algoritmo di valutazione del contrasto.
Come abbiamo visto, questo algoritmo temporaneo è diventato di fatto uno standard
valutativo, ma le perplessità in merito a queste formule sono diverse1:
Sulle metodiche2 di test in base alle quali la formula è stata individuata. Questo per il
fatto che è non è mai stata testata con disabili visivi che hanno specifici problemi nella
visione del colore. In questo modo difficilmente potrà discriminare se due colori sono
sufficientemente distanti da accomodare daltonici e discromatici di vario tipo. In oltre il
test è stato condotto con tavolozze di colore specifiche, Web Safe, sicuramente non
paragonabili alle complessità delle gradazioni cromatiche attualmente utilizzate;
L'esperienza empirica di chi, in qualità di progettista, si trova ad applicarla e verifica
spesso come alcuni contrasti di colori considerati validi dalla formula appaiano meno
leggibili di altri considerati validi;
Il fatto che alcuni specialisti hanno fatto rilevare come la formula sia largamente
incompleta e non tenga conto di altri fattori che influenzano la percezione del colore,
come ad esempio la non linearità dei fosfori, lo spessore del carattere, (il contrasto
viene amplificato dallo spessore del tratto), la grandezza del carattere, il tipo di
carattere (a monitor caratteri diversi hanno diversa leggibilità) e l'esistenza di patologie
1
2
[http://www.contrastocolori.org/archives/critiche_e_proposte/]
[http://www.aprompt.ca/WebPageColors.html]
- 109 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
visive anche molto diverse fra loro.
Anche alla luce di queste analisi, le formule appena citate risultano datate e discutibili1.
La legislazione federale americana ha, di fatto, evitato di aggiungere un proprio formulario
valutativo a proposito mentre le WCAG 2.0, dopo un lungo e travagliato lavoro di discussione
hanno introdotto delle formule2 completamente differenti, questo almeno al momento, con
l’attuale Last Call Working Draft del 27 Aprile 2006 dove nel glossario è stato presentato un
algoritmo3 per valutare il rapporto di contrasto della luminosità, sviluppato da Gregg
Vanderheiden, Dave Kelso, e Aries Arditi.
Innanzi tutto viene definita la linearizzazione di un colore C (C è una delle componenti del
colore espresso con i tre colori di base R, G, B) come:
Linearised C = LC= (C/FS)^2.2.
Dove FS è il valore di fondo scala (255 per i colori ad 8 bit) e ^ è l’operatore di elevamento a
potenza.
Quindi si definisce la luminosità come:
Luminosity = L = 0.2126*LR + 0.7152*LG + 0.0722LB.
Ed infine si calcola il rapporto di contrasto fra due colori:
Luminosity Contrast Ratio = LCR = (L1+0.05) / (L2+0.05).
Dove L1 è il maggiore dei valori di luminosità (sia del testo che dello sfondo) e L2 è il valore
più basso (sia del testo che dello sfondo)
Con questa formula la luminosità può variare da 0 per il nero a 1 per il bianco e il rapporto di
contrasto della luminosità tra 1 e 21.
A questo punto entrano in gioco i criteri restrittivi proposti nelle WCAG 2.0 come definiti nelle
linee guida al punto 1.4:
Livello 2: “I testi o i diagrammi e i loro sfondi devono avere un rapporto di contrasto
della luminosità almeno di 5 a 1” (Success Criteria 1.4.1);
Livello 3: “I testi o i diagrammi e i loro sfondi devono avere un rapporto di contrasto
della luminosità almeno di 10 a 1” (Success Criteria 1.4.3).
1
Giorgio Brajnik: [http://www.dimi.uniud.it/wq/stanca-mappa.html]
[http://www.w3.org/TR/WCAG20/appendixA.html]
3
luminosity contrast ratio (L1 + 0.05) / (L2 + 0.05), where L1 is the luminosity of the lighter of the text or
background colors, and L2 is the luminosity of the darker of the text or background colors. The luminosity of
a color is defined as 0.2126 * ((R / FS) ^ 2.2) + 0.7152 * ((G / FS) ^ 2.2) + 0.0722 * ((B / FS) ^ 2.2). R,
G, and B are the red, green, and blue RGB values of the color. FS is the maximum possible full scale RGB
value for R, G, and B (255 for eight bit color channels). The "^" character is the exponentiation operator.
2
- 110 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Come annotato in precedenza, le WCAG 2.0 hanno voluto sanare parzialmente la situazione
riportando a livello 2 le priorità per il colore dei testi e rafforzandole ulteriormente con un
contrasto maggiore per il livello 3. In oltre le considerazioni per l’aspetto testuale non sono più
separate dalle raccomandazioni per la grafica.
Suggerimenti per l’uso del colore
Un utile ausilio, per una scelta dei colori sulle pagine Web che tenga conto delle percezioni
falsate di chi soffre di cecità ai colori, è offerto dalle tabelle disponibili sul sito BT Exact 1.
Si è fatto notare che i progettisti dovrebbero cercare di porre il massimo contrasto tra il colore
dello sfondo e quello di primo piano. In particolar modo occorre controllare che questo
contrasto non sia conseguente solamente ad una differenza di tonalità (hue) del colore, ma
soprattutto ad una differenza di brillantezza (brightness).
Occorre anche tener conto del fatto che i colori impiegati non debbano essere eccessivamente
carichi in saturazione e brillantezza, altrimenti potrebbero infastidire il lettore o dare luogo a
fenomeni di abbagliamento che alla lunga potrebbero affaticare notevolmente la fruizione della
pagina.
A questo proposito vorrei riportare alcune osservazioni pratiche sull’uso del colore, riportate da
Joe Clark2.
Una prima osservazione riguarda le disabilità visive esposte in precedenza:
Il rosso ed il verde sono i colori maggiormente soggetti alle disabilità visive. I protanopi
e la deuteranopi in particolare confondono questi due colori;
Quasi nessuno ha problemi nella visualizzazione del blu, quasi tutti possono vederlo o
distinguerlo dagli altri ad eccezione dei tritanopi, molto rari, che tendono a confonderlo
con il verde;
Ad eccezione degli acromati, tutti possono vedere qualche tipo di colore, anche il rosso
ed il verde non sono uniformemente rimpiazzati dal grigio,
Le persone affette da parziale cecità ai colori hanno imparato con il tempo ad adattarsi
e, dal momento che molti di loro possono distinguere il contrasto e la brillantezza,
hanno imparato a differenziare i colori ed associare certi toni con certe definizioni di
colore.
In termini di accessibilità, se nessun significato particolare è veicolato all’uso del colore, non
risulta particolarmente problematico il fatto che un singolo blocco di colore possa essere
1
2
[http://www.btplc.com/age_disability/technology/RandD/colours/index.htm]
[http://joeclark.org/book/sashay/serialization/Chapter09.html]
- 111 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
percepito come blu, rosso o verde. Il fatto che un individuo con cecità ai colori non percepisca
una fotografia nel modo in cui la vede un normo-dotato non rappresenta un grave problema.
Una opportuna descrizione testuale della foto può essere allegata al testo nel caso l’immagine
trasmetta una informazione primaria, come ad esempio nel caso di un semaforo rosso.
Da questo punto di vista va ricordato che anche le persone normo-dotate hanno delle
percezioni del colore che possono, anche significativamente, discostarsi le une dalle altre,
senza contare il fatto che monitor, stampe, sistemi di colore, posso fornire una resa delle
immagini parzialmente differente da una piattaforma ad una altra.
Tenendo quindi presente il principio di controllare il colore, e non solo la tonalità, non è difficile
applicare questi accorgimenti per la realizzazione di pagine maggiormente accessibili. In
genere occorre porre attenzione a:
Non impostare rosso su nero o nero su rosso. Il rosso appare scuro a protanopi;
Non impostare verde su rosso o rosso su verde. Darebbero fastidio anche alla maggior
parte delle persone normo-dotate, oltre che ad essere indistinguibili per i protanopi e
deuteronopi;
Non posizionare uno accanto all’altro una coppia di colori confondibili come descritto
sopra;
Non mescolare le combinazioni beige, giallo e arancio con rosso o verde.
Non è corretto ricorrere ad altre caratteristiche come ad esempio TITLE, LONGDESC, JavaScript o
messaggi sulla linea di stato per evitare queste restrizioni. Il fatto di forzare gli utenti a
passare con il mouse sopra il testo finché non si modifichi in un indicatore di collegamento
ipertestuale non si può considerare un principio valido di usabilità, né, a maggior ragione di
accessibilità. Così come non è meno sgradevole obbligare i visitatori ad attendere il rollover di
un JavaScript o un suggerimento a comparsa (tooltip) per comprendere il significato di un
elemento1. Aggiungere queste informazioni può essere sicuramente utile, ma non ci si deve
affidare esclusivamente per risolvere le scorrettezze nella scelta del colore.
Per evitare al massimo ogni possibile confusione di colori si può ricorrere a delle combinazioni
che sono considerate accettabili da tutti.
1
Joe Clark: “It is bad usability and certainly bad accessibility to force people to scrub the mouse all over the
screen until the cursor changes into a link indicator because they have no other way of finding the links on
the page. It is no less illicit to force people to wait for a rollover or a tooltip or a status-line display (very
easy to miss) merely to understand what the hell an item is for.”
- 112 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
E’ disponibile una considerevole mole di lavoro in proposito, l’autrice più autorevole in materia
è probabilmente Cynthia Brewer, anche per soluzioni cartografiche e non prettamente
finalizzate al Web.
Ci sono due gruppi di linee guida:
Coppie di colori che possono essere usati insieme;
Gradazioni di colori che possono essere impiegati per rappresentare progressioni o per
differenziare gli oggetti correlati in modo graduale.
Le associazioni valide sono:
Rosso/blu, con gradazioni: rosso scuro, rosso intermedio, rosso chiaro, blu chiaro, blu
intermedio, blu scuro;
Arancione/blu, con gradazioni: arancione scuro, arancione intermedio, arancione chiaro,
blu chiaro, blu intermedio, blu scuro;
Arancione/viola con gradazioni: arancione scuro, arancione medio, arancione chiaro,
viola chiaro, viola intermedio, viola scuro;
Giallo/viola con gradazioni: giallo, viola chiaro, viola intermedio, viola scuro;
Marrone/blu con gradazioni: marrone scuro, marrone intermedio, marrone chiaro, blu
chiaro, blu intermedio, blu scuro;
Giallo/blu con gradazioni: giallo, blu chiaro, blu intermedio, blu scuro.
Si noti che il giallo quando compare non ha gradazioni, giacché il giallo stesso è un colore
chiaro.
Per quanto riguarda il bianco, il nero ed i grigi, questi sono percepiti come tali da tutti coloro
che abbiano una visione funzionale. Si possono impiegare rosso e nero sulla stessa pagina
purché siano separati, caratteri rossi su sfondo bianco, caratteri bianchi su nero e bianco e
rosso uno sopra all’altro.
Va sottolineato che una eventuale verifica dei colori su monitor in bianco e nero o stampanti a
gradazioni di grigio non è in realtà una tecnica valida ed esaustiva ai fini della verifica
dell’accessibilità1. Una simulazione in scala di grigi non è un cattivo strumento per valutare i
livelli di contrasto, tuttavia questa non è esattamente la situazione nella quale si trovano poi
coloro che soffrono di parziale o totale cecità ai colori.
1
Joe Clark: “Looking at your pages in greyscale mode is not an adequate simulation of the experience of
colourblindness”.
- 113 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Un’ultima importante raccomandazione caldeggiata da Michele Diodati per garantire una buona
leggibilità dei testi agli utenti affetti da ipovisione e cecità ai colori, è quella di evitare di
inserire sfondi grafici compositi sotto i testi.
Infatti, quando lo sfondo è un'immagine costituita da una trama complessa di colori,
mantenere un contrasto sufficiente con il testo diventa pressoché impossibile: alcune zone
dell'immagine di sfondo conserveranno magari un sufficiente livello di contrasto, altre zone no.
La presenza di un'immagine sotto il testo distrae inoltre l'attenzione del lettore. Il rischio è di
aver causato una fastidiosa ed inutile forma di tortura ai danni degli occhi di chi, affetto da
deficit visivi, si sta sforzando di leggere il testo nella pagina. 1
La leggibilità peggiora poi ulteriormente, quando si blocca la posizione dell'immagine di sfondo:
il movimento disaccoppiato del testo rispetto allo sfondo rende ancora più penoso lo sforzo di
chi tenta di leggere i contenuti.
Regole per i CSS del W3C
Esistono tre metodi per specificare i colori secondo i CSS, uno con parole chiave e due che
permettono di modificare i valori RGB scegliendo una qualsiasi tonalità:
Notazione con parole chiave;
Notazione esadecimale: il valore è preceduto dal simbolo #. Sono consentite due
varianti sintattiche: #rrggbb oppure #rgb quando le cifre si equivalgono nella coppia.
Per esempio #00ffff potrà essere scritto in forma abbreviata #0ff, ma questo non è
possibile per #808080;
Notazione funzionale: un valore RGB è definito in una lista separata da virgole di valori
numerici o percentuali, racchiusi tra parentesi e preceduti dalla stringa RGB.
Le tecniche per i CSS del WCAG 1.0 suggeriscono di utilizzare valori numerici e non parole
chiave per la definizione dei colori. Per quanto poi in quelle presentate nelle WCAG 2.0 non
sempre si raccomanda questa prassi 2.
La specifica del linguaggio indica 17 parole chiave disponibili per la definizione dei colori:
TABELLA 1 - CODICI COLORI CSS
Colore
maroon
1
2
Valore
#800000
[http://www.diodati.org/scritti/2004/guida/ele_acc16.asp]
[http://www.w3.org/TR/CSS21/syndata.html#value-def-color]
- 114 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Colore
Valore
red
#ff0000
orange
#ffA500
yellow
#ffff00
olive
#808000
purple
#800080
fuchsia
#ff00ff
white
#ffffff
lime
#00ff00
green
#008000
navy
#000080
blue
#0000ff
aqua
#00ffff
teal
#008080
black
#000000
silver
#c0c0c0
gray
#808080
Esistono anche dei colori di sistema, come specificato dagli stessi documenti 1 del W3C.
In tal caso è possibile applicare agli elementi della pagina gli stessi colori utilizzati dall’utente
per la sua personalizzazione del sistema operativo. Si tratta di un vantaggio utile ad esempio
per un ipovedente per mantenere la coerenza e le impostazioni del proprio normale ambiente
di lavoro.
Da notare che nelle future specifiche2 CSS3, probabilmente questi colori di sistema verranno
rimpiazzati dalla definizione APPAREANCE.
Un concetto fondamentale ribadito anche nelle tecniche CSS è di porre attenzione al momento
di specificare un colore di sfondo o un colore di primo piano senza indicarne allo stesso tempo
anche l’altro3. Il motivo è che definendone uno solo l’altro potrebbe rimanere impostato al
1
[http://www.w3.org/TR/REC-CSS2/ui.html#system-colors]
[http://www.w3.org/TR/2003/WD-css3-ui-20030703/#system]
3
“Ensure that foreground and background colors contrast well. If specifying a foreground color, always
specify a background color as well (and vice versa).”
2
- 115 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
valore di default settato dall’utente o dal browser causando in questo modo dei potenziali
problemi di scarso contrasto.
III.7 - Impaginazione e tabelle
Uno degli argomenti più dibattuti per l’accessibilità, forse anche con troppa rilevanza, è quello
dell’impiego delle tabelle, sia per le presentazioni dei dati correlati che, soprattutto, per
ottenere effetti d’impaginazione. Per questo motivo ho scelto di presentare questi due concetti
in un’esposizione unica.
In questa sezione verranno affrontate le problematiche dell’accessibilità inerenti le
impaginazioni realizzate sia tramite le tabelle sia tramite i fogli di stile.
Uso delle tabelle
Incominciamo a vedere quale dovrebbe essere il loro scopo secondo il W3C.
Nel testo di riferimento sul linguaggio HTML 4.01 si legge: “il modello tabella HTML permette
agli autori di disporre i dati (testo, testo preformattato, immagini, collegamenti, moduli, campi
di moduli e altre tabelle) i righe e colonne di celle.” 1.
Di fatto, le tabelle vengono in genere utilizzate sia per dati che per impaginare. Tratteremo
entrambe gli aspetti nello sviluppo di questa discussione.
Le informazioni ufficiali di riferimento possono essere trovate su molte guide internet,
personalmente raccomando sempre la documentazione2 ufficiale del W3C
Va tenuto presente, come messo in evidenza da Luca Mascaro al seminario 3 dell’IWA che la
gestione delle tabelle è sempre stata un problema piuttosto spinoso e particolarmente
problematico per i vari browser, soprattutto per alcuni tra i più datati che addirittura vanno in
errore nell’affrontare strutture complesse o male annidate.
Lo scopo delle tabelle è quello di presentare i dati secondo uno schema organizzato.
Il vantaggio consiste in una migliore percezione delle organizzazioni logiche delle informazioni,
sia da parte di un browser grafico, sia da parte delle tecnologie assistive che possono
vantaggiosamente impiegare la struttura di un elemento TABLE, l’elemento impiegato da
(X)HTML per implementare le tabelle, al fine di presentare i dati agli utenti in maniera logica.
Una prima discriminazione essenziale ai fini dell’accessibilità è tra:
1
“The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms,
form fields, other tables, etc. -- into rows and columns of cells.” –
[http://www.w3.org/TR/html4/struct/tables.html#edef-TABLE]
2
[http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20041008/#datatables]
3
Roberto Ellero, Luca Mascaro - Seminario IWA/IWG – Arese, Maggio 2005
- 116 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Tabelle di impaginazione: cioè tabelle impiegate ai fini della pura presentazione del
contenuto;
Tabelle di dati: cioè tabelle contenenti informazioni organizzate in relazioni di
dipendenza.
A volte può non essere affatto semplice discriminare fra l’uno e l’altro tipo, anche perché ve ne
sono parecchie di tipo intermedio che non possono essere correttamente catalogate.
Eppure la distinzione è di un certo rilievo dal momento che, come vedremo, implica trattamenti
differenti.
Il linea di principio una tabella dati ha una funzionalità ed un aspetto molto simile ad una
relazione di un database. Di conseguenza vi sono delle strette connessioni tra le celle e le altre
al punto che non è possibile riordinarle a piacere senza alterare o addirittura sconvolgere il
contenuto informativo della tabella. In questi casi, ad esempio, non sarebbe possibile
scambiare le celle di intestazione tra di loro o peggio ancora con una di contenuto, come non
sarebbe possibile mutuare l’ordine di due celle dati senza assegnare significati differenti ai
contenuti.
Per una tabella di impaginazione invece di solito è possibile scambiare l’ordine di qualcuna di
queste informazioni senza alterare il contenuto comunicativo della tabella, questo perché non
vi sono organizzazioni semantiche orizzontali o verticali.
Tabelle dati
Abbiamo già visto quali sono gli elementi del linguaggio per le tabelle.
Oltre all’elemento TABLE, per le tabelle dati è necessario utilizzare gli elementi:
<TR>: per definire una riga;
<TD>: per definire un elemento di una riga;
<TH>: per definire un elemento di intestazione di una riga;
<CAPTION>: per indicare la natura della tabella dati;
SUMMARY:
per fornire una descrizione testuale della tabella che ne riassuma gli scopi e la
funzione. Le tecnologie assistive ne fanno uso per rendere queste informazioni
disponibili agli utenti.
In questo schema sono presenti, oltre agli elementi base TR e TD anche altri marcatori
aggiuntivi, il motivo è che qualsiasi tabella di dati dovrà contenere delle informazioni
preventive alla lettura ai fini dell’accessibilità.
In particolare, le WCAG 1.0, al punto 5.5 prescrivono esplicitamente di definire un sommario
dei contenuti per ogni tabella, sebbene questo sia di priorità 3.
L'utilizzo del sommario per le tabelle tramite l'attributo SUMMARY è particolarmente utile per le
tecnologie assistive utilizzate dagli utenti non vedenti. Gli utenti non vedenti, ricevendo
- 117 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
informazioni grazie al contenuto di questo attributo, potranno valutare se fruire del contenuto
o se passare al paragrafo successivo. In genere i browser grafici non lo riproducono a video.
Esiste una significativa differenza con l’elemento CAPTION che rappresenta una definizione, un
titolo della tabella, l'attributo SUMMARY è di fatto una guida all'utente sul contenuto e
sull'organizzazione della tabella dati, andrebbe compilato come se si volesse descrivere per
telefono come è fatta e che genere di informazioni contiene la tabella:
<table summary="Rappresentazione del numero di caffè consumati da ogni
onorevole, con il tipo di caffè e se consumato con zucchero.">
<caption>Caffè consumato da ogni onorevole</caption>
Il W3C sconsiglia l’uso dell’elemento TITLE per le tabelle, raccomandando di impiegare in luogo
di questo CAPTION e SUMMARY per fornire informazioni addizionali descrittive sulla tabella. Questo
perché l’attributo TITLE non implica ulteriori informazioni significative ed è applicabile a
qualsiasi elemento (X)HTML mentre gli altri sono progettati appositamente per le tabelle.
Invece, una delle raccomandazioni delle WCAG 1.0 al punto di controllo 5.1 è quella di
identificare le intestazioni di righe e colonne. Un modo per fare questo è l’uso di TH.
L’elemento <TH> può essere impiegato sia per intestare le righe sia per intestare le colonne
come nell’esempio seguente:
<table summary="Sommario tabella…">
<caption>Esempio di tabella dati</caption>
<tr>
<td></td>
<th>Intestazione Colonna 1</th>
<th>Intestazione Colonna 2</th>
</tr>
<tr>
<th>Intestazione Riga 1</th>
<td>Col. 1 Riga 1</td>
<td>Col. 1 Riga 2</td>
</tr>
<tr>
<th>Intestazione Riga 2</th>
<td>Col. 2 Riga 1</td>
<td>Col. 2 Riga 2</td>
</tr>
</table>
Marcatori di scope
Per istruire uno screen-reader alla corretta lettura dei contenuti vanno impiegati anche degli
elementi di scope, in altre parole degli elementi che permettano di collegare i contenuti delle
celle con le loro relative celle di intestazioni.
Se questo viene fatto in maniera corretta, la pronuncia del testo contenuto in una cella viene
avviene dopo la pronuncia del testo contenuto nelle celle di intestazione collegate.
Gli strumenti sono:
- 118 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L’attributo ID per ogni cella di intestazione;
L’attributo HEADERS, che specifica l'elenco delle intestazioni collegate ad una cella
contenente dati mediante un riferimento al loro ID;
L’attributo SCOPE, che invece lavora da solo, permettendo di indicare il raggio di
estensione per cui valgono le informazioni di intestazione di quella cella (sulla riga, sulla
colonna, sul gruppo di colonne, sul gruppo di righe).
Per quanto riguarda i risultati ai fini dell’accessibilità, l’uso della coppia ID, HEADERS è del tutto
equivalente all’impiego del solo attributo SCOPE. Tuttavia quest’ultimo può risultare più
semplice per tabelle rigorosamente suddivise, mentre per tabelle più irregolari in cui le
relazioni di appartenenza possano essere complesse si ricorre alla coppia ID, HEADERS di cui si
propone un esempio in un caso semplice:
<table summary="Rappresentazione del numero di caffè consumati da ogni
onorevole, con il tipo di caffè e se consumato con zucchero.">
<caption>Caffé consumato da ogni onorevole</caption>
<tr>
<th id="nome">Nome</th>
<th id="tazze">Tazze</th>
<th id="tipo" abbr="Tipo">Tipo di caffè</th>
<th id="zucchero">Zucchero?</th>
</tr>
<tr>
<td headers="nome">A. Palmieri</td>
<td headers="tazze">10</td>
<td headers="tipo">Espresso</td>
<td headers="zucchero">No</td>
</tr>
<tr>
<td headers="nome">C. Campa</td>
<td headers="tazze">5</td>
<td headers="tipo">Decaffeinato</td>
<td headers="zucchero">Sì</td>
</tr>
</table>
Alla linea guida 5.6 poi, le WCAG 1.0 prescrivono di fornire abbreviazioni per le etichette
d’intestazione.
Il motivo è che, in questo modo, uno screen-reader leggerà il valore sostitutivo abbreviato in
luogo del contenuto della cella, in modo da eliminare pesanti ripetizioni di lettura se il testo
della cella fosse eccessivamente lungo.
Per questa operazione si usa l’attributo ABBR nell’elemento TH definendo un'abbreviazione
dell'etichetta:
<th abbr="via">indirizzo di residenza</th>
- 119 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Tabelle dati complesse
Per tabelle dati complesse s’intendono quelle tabelle che abbiano due o più livelli logici di
intestazioni di righe o colonne. Le cito a parte perché sia la legge Stanca nel requisito 10 che la
Section 508 nel paragrafo (h) le trattano in modo separato.
Non vi è nulla di particolarmente strano in queste tabelle, a parte il fatto che la loro maggiore
complessità ha fatto richiedere ai legislatori l’utilizzo vincolante degli elementi d’intestazione
per associare le celle di dati con le relative celle di intestazione.
Spesso può essere utile aggiungere anche altri marcatori che rafforzano questa connessione o
che permettono la gestione di tabelle piuttosto lunghe.
In questo caso si utilizza:
<THEAD>, <TFOOT> e <TBODY> per raggruppare blocchi di righe;
<COL> e <COLGROUP>: per raggruppare le colonne;
"AXIS", "SCOPE" e "HEADERS": per descrivere relazioni più complesse fra i dati.
La descrizione di queste funzionalità va al di fuori degli scopi di questa tesi e si rimanda alle
specifiche del linguaggio. Basti solo ricordare che SCOPE e HEADERS sono stati già trattatati in
precedenza. Mentre THEAD, TFOOT e TBODY permettono di separare concettualmente l’intera
tabella in delle sezioni orizzontali che possono essere ripetute, se occorre, in caso di stampa e
permettono di supportare delle tecniche di scrolling che mantengano fissa la sezione di testa e
la sezione di coda di un documento.
Il consiglio richiamato da più autori è di evitare l’impiego di questa tipologia di tabelle, se non
strettamente necessario e di considerare la possibilità di spezzarle in strutture più semplici.
Tabelle di impaginazione
Nella definizione di tabella esposta all’inizio della trattazione nulla viene detto sul loro impiego
nella strutturazione di una pagina.
Nate essenzialmente per visualizzare dati, si è poi iniziato ad usarle in modo parzialmente
improprio per visualizzare contenuti a seguito dell’avvento della progettazione grafica.
Nei periodi di massima espansione degli effetti visuali, si è fatto ricorso sempre di più a pesanti
impaginazioni a tabella finendo progressivamente per deteriorare l’accessibilità delle pagine.
Tuttavia, occorre sfatare un’estremizzazione troppo radicale di questo concetto, anche il W3C
non ha mai disapprovato esplicitamente le tabelle di layout, la discussione al riguardo è molto
complessa. Come fa notare Roberto Ellero1, l'unica cosa certa è che un approccio dogmatico,
1
[http://www.webaccessibile.org/argomenti/argomento.asp?cat=335]
- 120 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
come eliminare le tabelle di layout oppure affermare che i CSS non consentano di fare ciò che
si può fare con le tabelle, è sicuramente improprio per ottenere buoni risultati.
Vediamo cosa dicono a proposito di questo dibattito le normative considerate in questo testo:
WCAG 1.0, punto di controllo 5.3, 5.4: ”Non impiegare le tabelle a scopi di
impaginazione a meno che la tabella non abbia senso quando linearizzata. Se una
tabella viene impiegata per scopi di impaginazione non usare alcun marcatore
strutturare per la formattazione visuale.”.
D.M. 8 Luglio 2005, requisito 13: “Qualora si utilizzino le tabelle a scopo di
impaginazione garantire che il contenuto della tabella sia comprensibile anche quando
questa viene letta in modo linearizzato ed utilizzare gli elementi e gli attributi di una
tabella rispettandone il valore semantico definito nella specifica del linguaggio a
marcatori utilizzato.”.
WCAG 2.0: nelle tecniche per il criterio di successo 1.3.1: “Lo scopo dell’elemento HTML
table è quello di presentare i dati, il suo uso per impaginazione non costituisce un
errore finche non vengano impiegati elementi di marcatura strutturali in maniera
impropria.”1.
La Section 508, pur definendo l’utilizzo delle tabelle ai capoversi (g) ed (h), non fanno tuttavia
esplicito divieto all’impiego delle tabelle come impaginazione.
Piuttosto interessante è il principio esposto dalle WCAG 2.0, proprio perché dovrebbero
rappresentare la tendenza più recente del W3C. Nel documento delle tecniche di successo
affermano abbastanza chiaramente che l’uso dell’elemento TABLE ai fini dell’impaginazione non
è un errore di per sé a patto che non si commettano poi degli errori includendovi degli attributi
scorretti o annidandole eccessivamente.
Per quanto questo costituisca uno dei punti dibattuti delle WCAG 2.0, è abbastanza lontano da
definire come vietate le tabelle di impaginazione.
Riassumo questo concetto con una frase di Michele Diodati:
Una delle più strane leggende metropolitane diffusesi negli ultimi tempi tra la comunità
degli sviluppatori di pagine Web è che non si possono più usare le tabelle. E' una di quelle
convinzioni sbagliate che nascono dal tam-tam incontrollato delle voci e che sono favorite dal
fatto che nessuno di quelli che propagano la leggenda si sia mai preoccupato di andare a
1
“Note that the use of HTML tables for layout is not an example of this failure as long as the layout table
does not include improper structural markup such as <th> or <caption> elements.”
- 121 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
trovare la fonte normativa, il documento W3C che sarebbe all'origine della proibizione.1
Svantaggi delle tabelle di impaginazione
Per questo l’utilizzo delle tabelle per l’impaginazione deve essere messo in pratica in maniera
oculata, tenendo comunque conto che presentano numerosi svantaggi e sono soggette ad
altrettante restrizioni.
L’uso dei <DIV> in collaborazione con le relative impostazioni nei CSS resta quasi sempre da
preferire2.
Incominciamo a far presente quali sono i possibili svantaggi:
Pagine troppo pesanti, soprattutto nel caso di tabelle annidate e di uso intensivo di
elementi ed attributi di presentazione. Questo causa notevoli ritardi di caricamento
rispetto alla versione CSS;
Contenuti che vengono visualizzati più lentamente rispetto a pagine che non
contengono tabelle o che addirittura possono mandare in blocco il computer, su certi
browser molto datati;
Lunghi elenchi di collegamenti e di contenuti secondari, da dover saltare o ascoltare
integralmente prima di giungere ai contenuti principali della pagina quando la
navigazione avvenga per mezzo di un sintetizzatore vocale. Questo problema si verifica
quando gli elenchi sono contenuti in una o più celle che precedono la cella o le celle in
cui si trovano i contenuti principali della pagina. In alcuni casi è difficile porvi rimedio
con le tabelle, mentre invece risulta piuttosto facile da trattare con gli opportuni
accorgimenti dei CSS e dei <DIV>;
Difficoltà progettuali nella manutenzione della pagina nel caso di tabelle di
impaginazione annidate preparate per ottenere uno specifico aspetto grafico;
Difficoltà di comprensione della posizione all’interno della struttura annidata. In
particolare questo potrebbe essere un grosso problema per gli utenti che non possono
orientarsi in maniera visuale e di conseguenza non hanno la percezione della posizione
dello screen-reader all’interno della struttura;
Maggiore inaccessibilità nella linearizzazione, celle adiacenti vengono lette una accanto
all’altra dagli screen-reader anche se appartengono a due colonne concettualmente
differenti. Soprattutto quando la lettura andrebbe fatta prima in verticale che in
orizzontale (della linearizzazione parleremo tra poco).
1
[http://www.diodati.org/scritti/2004/guida/ele_acc26.asp]
“While the preference is to use CSS for visual formatting, tables are often used to visually layout content in
an HTML document” - [http://www.w3.org/TR/WCAG20-TECHS/#N11138]
2
- 122 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per quanto riguarda le restrizioni ve ne sono alcune imposte direttamente dal W3C, proprio ai
fini della corretta l’accessibilità dei contenuti.
Il principio è quello di non utilizzate a fini di presentazione gli elementi e gli attributi
strutturali progettati per le tabelle di dati.
Il W3C raccomanda:
Quando una tabella viene impiegata per aspetti presentazionali l’elemento TH non
dovrebbe essere utilizzato. Poiché la tabella non presenta dei dati correlati non c’è
bisogno di marcare una qualunque cella come se fosse una intestazione di riga o
colonna;
Per lo stesso non si vede il bisogno di aggiungere alcuna descrizione alla tabella che è
solo utilizzata a scopo d’impaginazione. Per questo non si deve includere l’attributo
SUMMARY,
nemmeno per dichiarare la tabella come una tabella d’impaginazione. Non
sarebbe un’informazione di alcun valore se pronunciata da uno screen-reader. Sono
ammesse tabelle d’impaginazione con attributo SUMMARY vuoto, per quanto non siano
raccomandate.
Non tutti gli autori sono concordi su quest’ultimo punto.
In generale tutti i tre marcatori CAPTION, SUMMARY (se non vuoto) e TH, sono particolarmente
significativi solo per le tabelle di dati e non andrebbero impiegati per quelle di impaginazione in
quanto finiscono per ingannare i lettori di schermo.
Come anche specificato nel documento tecnico1 delle WCAG 2.0, questo uso è definito un
errore per il criterio di successo 1.3.1 a causa dell’uso di elementi strutturali o semantici ai fini
di un aspetto presentazionale.
Il medesimo concetto è presente anche nelle WCAG 1.0 al punto di controllo 5.4: “Se si utilizza
una tabella di impaginazione non impiegare nessun marcatore di struttura a scopo di
formattazione.”.
Un interessante articolo2 a proposito delle tabelle di impaginazione è presente su
WebAccessibile a firma di Jim Byrne, traduzione dell’originale3 inglese a cura di Roberto Ellero.
Vale la pena dargli una occhiata. Il punto di vista dell’autore è piuttosto interessante ed anche
abbastanza critico nei confronti delle chiusure totali alle tabelle.
1
2
3
[http://www.w3.org/TR/WCAG20-TECHS/#N11138]
[http://www.webaccessibile.org/argomenti/documento.asp?DocID=336]
[http://www.mcu.org.uk/articles/tables.html]
- 123 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L’articolo contiene molti suggerimenti utili su come rendere al meglio le strutture a tabella
rendendole accessibili e funzionali.
Utilizzo delle tabelle di impaginazione
L’impiego delle tabelle ai fini dell’impaginazione non è espressamente proibito, come visto in
precedenza.
Qualora si volessero comunque impiegare le tabelle a scopo di impaginazione occorre:
WCAG 1.0, punto di controllo 5.3: “Garantire che il contenuto della tabella sia
comprensibile anche quando questa viene letta in modo linearizzato.”;
WCAG 1.0, punto di controllo 5.4: “Utilizzare gli elementi e gli attributi di una tabella
rispettandone il valore semantico definito nella specifica del linguaggio a marcatori
utilizzato.”.
Quindi un criterio importante per la possibile applicazione è quello della linearizzazione della
tabella, linearizzazione che viene appunto espressamente citata dalle WCAG come condizione
necessaria per l’impiego in pagine (X)HTML delle tabelle di presentazione.
La linearizzazione1 di una tabella è un processo di resa della tabella dove il contenuto delle
celle si trasforma in una serie di paragrafi posti uno dopo l’altro. I paragrafi si presenteranno
nello stesso ordine in cui sono definite le celle nel documento originario.
Nei browser che non supportano le tabelle, l'informazione è resa come una serie di paragrafi
ad iniziare dalla prima cella in alto a sinistra, con movimento verso destra di cella in cella,
mostrando i contenuti come vengono trovati. Una volta terminata la prima riga, l'elaborazione
della seconda riga prosegue allo stesso modo, e così di seguito fino al termine.
Invece, una tabella che, resa in maniera lineare, perda senso quasi completamente, non deve
essere impiegata. Infatti, utilizzando le tabelle di impaginazione non linearizzabili si possono
riscontrare dei problemi con le tecnologie assistive che non sono in grado di accedervi al
meglio.
Risolto questo problema, nulla vieta che le tabelle vengano impiegate anche per
l’impaginazione. Nel sopra-citato articolo di Jim Byrne si suggeriscono i modi migliori per
impiegarle:
Tenere in ordine le celle:
Si tratta di rispettare il principio della linearizzazione esposto in precedenza: assicurarsi
che se interpretati da browser che non supportano le tabelle l'informazioni la tabella
1
[http://www.w3.org/TR/WCAG10/wai-pageauth.html#linearized-table]
- 124 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
rimanga dotata di senso e nel giusto ordine. Come stabilisce il WAI: fare tabelle in
modo che l'informazione presente in esse conservi senso dopo la linearizzazione;
Usare unità relative e non assolute:
Nella tradizionale grafica su carta il designer conosce ogni minimo dettaglio circa il
risultato finale; le dimensioni, i colori, come verrà visto il design, come appariranno gli
aspetti tipografici eccetera. Nel Web non è così, tutto ciò che si può fare è applicare un
design flessibile in modo da consentire una gradevole trasformazione del design e la
sua accessibilità sulla più vasta gamma di periferiche utilizzabili;
Saltare la barra di navigazione:
E’ sufficiente fornire un semplice collegamento ipertestuale posizionato prima della lista
di navigazione che rimandi al contenuto effettivo della pagina. In questo caso, se la
colonna sinistra della tabella di impaginazione contiene un lungo elenco di collegamenti
ipertestuali che fanno da barra di navigazione sarà semplice saltarli con un solo click;
Fornire un sommario:
E' probabilmente più utile con le tabelle di dati, dove le relazioni fra le celle di tabella
possono essere complesse, ma è può rivelarsi utile anche per le impaginazioni basati su
tabelle. Come accennato questo è parzialmente in contrasto con quanto prima esposto
raccomandato dal W3C;
Non trattare le tabelle d’impaginazione come fossero tabelle dati:
Si tratta di evitare i marcatori dedicati alle tabelle dati come sopra esposto.
Come si può vedere, le scuole di pensiero a proposito sono differenti.
Personalmente ritengo l’uso delle tabelle d’impaginazione non da escludere a priori, anche
tenendo conto delle ultime tendenze più permissive delle WCAG 2.0.
Impaginazione
Se dunque, come visto fino ad ora, viene sconsigliato di impiegare le tabelle ai fini della
impaginazione, vediamo adesso più in dettaglio quale può essere considerata la maniera
alternativa di predisporre una impaginazione maggiormente accessibile, fermo restando il
punto che l’autore della pagina Web non deve far conto sulla assoluta fedeltà della
visualizzazione da lui prescelta impiegata dai vari programmi utente.
Il concetto base è che se un blocco informativo è contenuto in una cella di impaginazione,
questa cella può essere resa in alternativa attraverso un blocco racchiuso dall’elemento <DIV>.
Sarà poi compito del foglio di stile associato al codice il fatto di rendere visivamente al meglio
questo blocco specificandone gli attributi grafici.
Un semplice esempio, tratto dal codice completo riportato ad esempio nella parte finale di
questo lavoro, può essere il seguente dove viene mostrato l’utilizzo della coppia <DIV> in
(X)HTML e corrispondente regola nel CSS:
- 125 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
(X)HTML:
<div id="sGenerale">
<h2>Sommario Generale</h2>
<ul>
<li><a href="index.html">Presentazione;</a></li>
<li><a href="scenario.html">Scenario</a></li>
<li><a href="metolologie.html">Metodologie di base</a></li>
<li><a href="tecniche.html"">Altre tecniche</a></li>
<li><a href="normative.html"">Normative</a><span class="finelista">(Fine
Sommario Generale)</span></li>
</ul>
</div>
CSS:
.sGenerale {float: left; clear: left;}
.finelista {display: none;}
In questo caso si è scelto di inserire in un blocco DIV il menu di navigazione che solitamente
compare sulla sinistra di una pagina.
Si noti che, nel codice (X)HTML nulla viene detto sul reale posizionamento del blocco, a parte il
flusso naturale della presentazione nel codice, è nel foglio di stile che viene determinata la
visualizzazione a sinistra.
Definendo un successivo blocco di codice racchiuso in un altro DIV sarà poi possibile accostarlo
a destra del blocco di menu attraverso un'altra definizione nel foglio di stile associato.
A tale proposito vale la pena ricordare che l’impiego di DIV scollegati tra di loro e svincolati da
una struttura a tabelle permette di organizzarli al meglio, e non semplicemente accostati in
righe e colonne come invece deve essere fatto impiegando le celle di una tabella per
l’impaginazione.
Questo ovviamente porta anche svantaggi, come ad esempio il fatto che non si sia garantiti del
tutto sulla esatta impaginazione dei blocchi DIV.
Per decidere il posizionamento nel flusso della presentazione esistono diverse possibilità nei
fogli CSS:
Posizionamento relativo nel flusso normale;
Posizionamento assoluto: un riquadrato (box) è esplicitamente spostato rispetto al suo
blocco contenitore ed è rimosso interamente dal flusso normale;
Posizionamento flottante, nel caso in cui il riquadrato (box) venga spostato a sinistra o
a destra sulla riga corrente, si può fare con due proprietà principali:
o
FLOAT: questa proprietà specifica se un riquadrato debba flottare a sinistra, a
destra, o non flottare affatto. Può essere impostata per gli elementi che
generano riquadrati che non siano posizionati in modo assoluto;
o
CLEAR: questa proprietà indica quali lati del(i) riquadrato(i) di un elemento non
possono essere adiacenti ad un precedente riquadrato flottante. (Può essere che
- 126 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
l'elemento stesso abbia discendenti flottanti; la proprietà CLEAR non ha effetto su
questi.). Queste proprietà può essere specificata solo per elementi a livello di
blocco (inclusi i flottanti).
Per la spiegazione approfondita di queste tecniche rimando ai numerosi manuali in rete ed alla
guida ufficiale dei CSS2 recentemente tradotta1 in italiano da Gabriele Romanato.
Tornando all’esempio precedente è stato anche introdotto, come specificato nel capitolo delle
tecniche per la navigazione, un segnaposto di fine lista.
Si è fatto uso dell’elemento <SPAN>, l’analogo del <DIV> per il codice inline, cioè per quel
codice che non ha un proprio riquadrato (box) separato, ma viene gestito direttamente
all’interno di una altro contenitore di formato.
Nel corrispondente foglio di stile viene richiesto di non mostrare del tutto il testo contenuto
all’interno della classe finalista, in linea con quanto spiegato a proposito della navigazione.
Liquid layout
Il problema di una corretta impaginazione è sicuramente uno dei più complessi e peculiari del
mondo dei CSS. Il motivo, molto semplice, è dovuto alla parziale o totale inconsistenza con le
regole dei CSS da parte dei maggiori produttori di browser. Internet Explorer, il browser di
gran lunga più utilizzato, è anche uno dei più refrattari ad adattarsi alle specifiche del W3C.
Il supporto per i CSS livello 1 è dichiarato da tutti o quasi, mentre quello a livello 2 è ancora
ben lungi da venire, nonostante che tali specifiche risalgano al 1998.
Il comportamento dei vari browser non è ancora del tutto omogeneo neppure per le specifiche
di livello 1.
Ecco allora nascere tutta una serie di trucchetti e compromessi per fare in modo che le pagine
si presentino più o meno allo stesso modo su tutti i vari browser.
Questa breve spiegazione sull’impaginazione è finalizzata all’accessibilità del documento e non
mi addentrerò nei dettagli di queste implementazioni. Suggerisco, per altro, di tenere sempre
in mente l’obiettivo del proprio lavoro, e cioè il fatto di strutturare bene il documento e di non
preoccuparsi in maniera maniacale della resa grafica. Inevitabilmente la presentazione sarà
differente, su qualche browser e per qualche sistema operativo.
Detto questo vale comunque la pena occuparsi del concetto di impaginazione fluida (liquid
layout). Si tratta in sostanza di fare in modo che la presentazione grafica del sito si adatti il più
1
[http://www.diodati.org/w3c/css2/cover.html]
- 127 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
possibile ai vari ridimensionamenti della pagina e alla possibile ridefinizione della grandezza dei
caratteri.
Non esiste una definizione precisa di che cosa si intenda esattamente per liquid layout, se non
quella per cui la dimensione di una pagina Web deve adattarsi automaticamente alla
dimensione della finestra del browser, per cui possiamo dire che un layout liquido (o fluido) è
una impaginazione in cui la dimensione della pagina è variabile e asseconda la finestra del
browser.
A differenza del layout fisso, un layout liquido è adatto a tutte le risoluzioni.
Non è detto che la seconda soluzione possa essere sempre sbagliata ed esistono anche altre
soluzioni come ad esempio il più recente layout elastico. Ad ogni modo la legge Stanca
prevede, al requisito 12, che la presentazione e i contenuti testuali di una pagina devono
potersi adattare alle dimensioni della finestra senza sovrapposizioni.
Questa disposizione favorisce sicuramente i layout liquidi, ma, d’altro canto, non vieta
espressamente gli altri.
Altre caratteristiche che una impaginazione fluida dovrebbe avere sono:
Un carattere proporzionale. Se è vero che un layout liquido è adatto a tutte le
risoluzioni, bisognerà comunque fare in modo che sia possibile per l'utente
ridimensionare i caratteri;
La dimensione delle colonne dovrebbe essere preferibilmente essere in percentuale:
questo fa sì che la proporzione tra le colonne venga mantenuta con qualsiasi larghezza
della finestra del browser. Andrebbe controllata anche una larghezza minima;
Dovrebbe esserci una colonna centrale più ricca deputata a contenere le informazioni
fondamentali. Non ha senso realizzare un layout liquido e ospitare nella colonna di
informazioni solo quattro o cinque collegamenti ipertestuali per la navigazione del sito.
Ovviamente nella realizzazione di questa impaginazione si devono tener presenti anche le altre
regole di buona progettazione, come ad esempio quella di fornire un collegamento di salto ai
contenuti per chi naviga con dispositivi alternativi quali screen-reader e browser testuali.
Unità relative
Quello che invece è sicuramente più stringente in fatto di normative è la richiesta di
impiegare le unità relative anziché assolute nei valori degli attributi del linguaggio e per i
valori delle proprietà del foglio di stile.
Questo è esplicitamente richiesto dal punto di controllo 3.4 delle WCAG 1.0 ed implicitamente
suggerito dalla legge italiana, sempre al requisito 12. Il motivo è che con l’uso di dimensioni
relative i visitatori del sito Web potranno facilmente adattare il carattere alle proprie esigenze.
Non soddisfare il punto di controllo implica che un utente con ipovisione avrà grosse difficoltà
nell’accedere ai contenuti delle vostre pagine.
- 128 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In effetti, questa categoria di utenti spesso naviga con i caratteri ingranditi al massimo,
tuttavia se queste unità sono bloccate dal progettista della pagina esse non saranno
ridimensionabili a piacere dall’utente.
Considerando che in tale categoria di utenti ricadono anche le persone anziane, non rispettare
questo punto di controllo causa una esclusione di parecchi visitatori dal sito.
Ad onor del vero va ricordato che con le direttive CSS2 l’utente ha la possibilità di sovrapporre
le proprie impostazioni a quelle specificate dal progettista, ma questo accade solamente se il
browser visuale supporta queste direttive e se esse sono state incluse nei fogli di stile e non
all’interno del codice (X)HTML.
Per fortuna le versioni più recenti dei browser (incluso una volta tanto anche Internet Explorer
7) permettono l’ingrandimento completo della pagina, immagini e caratteri inclusi. E
questo facilita di molto l’impiego per gli ipovedenti.
Resta comunque da tener presente il fatto che le direttive dell’accessibilità non sono rivolte
solamente ai disabili, ma anche ai programmi utenti che siano impostati con una risoluzione
del monitor ben differente, come ad esempio le nuove tecnologie di navigazione dei palmari,
telefonini smartphone, e WebTV.
Come richiamato al momento di presentare il linguaggio, per unità di misura di tipo assoluto
che mantengono una dimensione fissa si intendono:
Pica (pc);
Punti (pt);
Inches (in), pollici;
Centimetri (cm);
Millimetri (mm).
Mentre per unità di misura di tipo relativo si ricordano:
Em;
Percentuale;
Pixel.
Il pixel è un caso particolare, il W3C lo definisce come dimensione relativa, ma in Internet
Explorer non viene ridimensionato, dal momento che il pixel è unità relativa alla dimensione
dello schermo e le opzioni di ingrandimento carattere non modificano la dimensione dello
schermo.
III.8 - Contenuti multimediali
Per contenuti multimediali s’intendono quei contenuti informativi che possono essere fruiti in
maniera sincronizzata attraverso più di un canale sensoriale.
- 129 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Tipicamente i canali sensoriali privilegiati sono l’udito e la vista, si tratta quindi di presentazioni
audio e video tipo filmati e animazioni.
I contenuti multimediali sono oramai parte integrante del patrimonio informativo trasmesso sul
Web in particolar modo per lo sviluppo che hanno avuto nei siti di informazione, di
intrattenimento e soprattutto nella formazione in linea. E’ quindi necessario rendere accessibili
queste tipologie di informazioni che tuttora risultano essere fra i meno considerati dal punto di
vista dell’accessibilità, probabilmente anche per il fatto che non sono particolarmente semplici
da rendere accessibili.
Ad ogni modo le normative considerate fanno diversi riferimenti espliciti ai contenuti
multimediali:
WCAG 1.0, 1.3: “Fornire una descrizione audio di una presentazione multimediale.”,
1.4: “Sincronizzare le alternative equivalenti di una presentazione multimediale.”;
Section 508, 1194.22 (b): “Alternative equivalenti per una qualsiasi presentazione
multimediale dovranno essere sincronizzate con la presentazione stessa.”.
D.M. 8 Luglio 2005, Requisito 18: “Per le presentazioni multimediali predisporre una
alternativa testuale equivalente sincronizzata in forma di sotto-titolazione e/o di
descrizione vocale.”.
WCAG 2.0, linea guida 1.2: “Fornire alterative sincronizzate per i multimedia.”.
Con queste direttive guida, per versioni equivalenti o alternative dei contenuti possiamo
intendere, nel senso più ampio possibile1:
Versione equivalente testuale per i dialoghi, dedicata a utenti non udenti o utenti con
disabilità linguistiche;
Versione equivalente audio per i contenuti video, dedicata agli utenti non vedenti;
Versione audio con equivalente testuale della descrizione dei filmati, dedicata ad utenti
non vedenti.
Versione equivalente testuale per dialoghi e contenuti video, dedicata agli utenti non
vedenti, non udenti e con disabilità cognitive;
Tutte queste versioni equivalenti devono essere possibilmente sincronizzate con il materiale
originario come esplicitamente richiesto dalle normative citate.
1
Roberto Scano: “Accessibilità: dalla teoria alla realtà”
- 130 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Metodologie
Vediamo ora quali sono le metodologie per realizzare le sopraindicate versioni equivalenti.
Dal momento che le tipologie di disabilità sensoriali considerate sono due, vista ed udito,
avremo fondamentalmente due strumenti di base per rendere accessibili i contenuti:
Captions:
Trascrizioni testuali dei dialoghi e dei contenuti audio. A beneficio dei non udenti;
Audio Description:
Descrizioni audio dei contenuti video. A beneficio dei non vedenti o degli ipovedenti.
In linea con quanto riportato espressamente nelle WCAG 2.0 che, al momento di definire i
criteri di successo per la linea guida 1.2, citano espressamente queste due tecniche.
Un’utile introduzione alla materia la si può trovare nel testo di Joe Clark 1, considerato uno dei
migliori esperti mondiali in fatto di multimedia. Accanto a questi due strumenti Clark ricorda
anche i sottotitoli (subtitling) e il doppiaggio (dubbing).
Ho preferito riportare anche i termini in lingua inglese per tutte le voci in quanto, soprattutto in
Europa, esiste molta confusione a proposito del termine caption (didascalie o titolazioni o
trascrizioni testuali o descrizioni testuali) che viene spesso confuso con quello di subtitle
(sottotitoli) mentre in realtà sono cose leggermente diverse come descritto in seguito.
Va tenuto presente che, per quanto queste tecniche siano finalizzate alle due tipologie di
disabilità indicate, tuttavia le presentazioni multimediali alternative sono sicuramente utili
anche ai disabili cognitivi che possono essere facilitati nella comprensione delle informazioni.
Questo argomento è trattato nel capitolo sulla multi-modalità di questo lavoro.
Captions
Con questo termine di lingua inglese si intende un testo presentato e sincronizzato con un
elemento multimediale per fornire non solamente il dialogo ma anche informazioni non parlate
veicolate attraverso il suono, includendo effetti sonori significativi ed identificazione di chi
parla2.
In pratica si tratta di rendere nel linguaggio scritto il dialogo e le altre informazioni udibili di
rilevante importanza.
1
[http://joeclark.org/book/sashay/serialization/Chapter04.html]
WCAG 2.0: “text presented and synchronized with multimedia to provide not only the speech, but also nonspeech information conveyed through sound, including meaningful sound effects and identification of
speakers”
2
- 131 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Come specificato in precedenza in molte nazioni il termine subtitle viene utilizzato per riferirsi
solo ai dialoghi mentre captions includono dialoghi e traccia audio, in altre nazioni invece i
sottotitoli comprendono entrambe le soluzioni.
Nel resto della trattazione sarà utilizzata la traduzione italiana descrizioni testuali, che, per
quanto impropria, mi sembra la più adatta a distinguere questo concetto da quello dei
sottotitoli.
Le differenze fondamentali sono:
Le descrizioni testuali sono progettate per i disabili uditivi, mentre i sottotitoli per gli
ascoltatori che non comprendono il linguaggio dei dialoghi, per questo spesso le
didascalie delle descrizioni testuali sono mobili, premettono il nome del parlante al testo
e cercano di dare le inflessioni vocali;
Le descrizioni testuali riportano gli effetti audio (passi, telefono che suona, eventi
naturali, eccetera), mentre i sottotitoli assumono che lo spettatore li possa udire;
Le descrizioni testuali sono trascritte nello stesso linguaggio della presentazione
multimediale, mentre i sottotitoli sono traduzioni in più lingue e quindi traducono
spesso anche le scritte a video, sono indipendenti dalla traccia video originale.
Le descrizioni testuali possono essere di due tipi:
Chiuse (Close), sono didascalie incluse nel segnale video, non sono visibili se non
interpretate da uno speciale decodificatore. In genere sono incluse nella linea 21 del
segnale VBI (Vertical Blank Interval). Possono essere attivate o disattivate agendo sul
decodificatore.
Aperte (Open), sono parte integrante del segnale video normalmente visibile e di
conseguenza non possono essere disattivate.
Gli apparecchi televisivi venduti in U.S.A, Australia, Canada ed in altre regioni hanno questo
decodificatore inserito direttamente nella circuiteria, dal momento che negli Stati Uniti, dal
1993, la legge prevede questi requisiti per gli apparecchi televisivi. E’ una richiesta motivata
dal fatto che in U.S.A. la maggior parte dei canali televisivi trasmettono descrizioni testuali
(captions) nei segnali video, inclusi le trasmissioni via cavo.
Questa tecnologia invece in Europa non ha preso piede, ad eccezione del Regno Unito.
Un valido articolo introduttivo in materia è quello di Gary Robson 1.
1
[http://www.robson.org/capfaq/]
- 132 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Oltre ad avere un’evidente finalità per gli utenti non udenti, le descrizioni testuali risultano
inoltre utili nel caso il filmato sia in lingua straniera e l’utente non abbia una buona
dimestichezza nell’ascoltare i dialoghi in tale lingua mentre sia invece in grado di comprendere
meglio la lingua scritta.
Audio description
Per quanto possa sembrare apparentemente un controsenso, in realtà gli utenti non
vedenti sono in grado di comprendere un filmato multimediale privo di immagini meglio di
quanto non possano fare i non udenti con un filmato privo di audio.1
Ne segue che l’esigenza più pressante è quella di fornire delle descrizioni testuali.
Gli utenti che per la loro disabilità (visiva o tecnologica) non possono visualizzare i contenuti
della presentazione multimediale, hanno necessità di ottenere una descrizione audio
alternativa.
Questa tecnica, definita dalle WCAG 2.0 audio description e correttamente tradotta in italiano
con descrizioni audio, consiste nel descrivere con la voce umana, in maniera succinta, i dettagli
visuali che non possono essere dedotti dalla traccia audio2, come ad esempio immagini in
movimento, localizzazione della scena ed altri dettagli significativi per la comprensione.
Si possono trovare delle definizioni simili, tipo descrizione video, video descrittivo, Auditory
description, come una precedente espressione presente3 nelle WCAG 1.0, didascalie audio, ed
altre cose, ma la terminologia corrente4 anche con le WCAG 2.0 è Audio Description, spesso
abbreviata con A.D.
Nelle sue origini, è una tecnica ben antecedente al Web, derivata dalla pratica di leggere libri o
descrivere scene teatrali ai non vedenti dove un narratore descrive quanto accade sul palco.
Vi sono due modi per predisporre questi contenuti:
fornirli inclusi nel filmato;
fornirli con un file audio a parte, ad esempio in formato mp3.
1
Joe Clark: “Blind people can follow a videoclip with no picture much more easily than deaf people can
follow it without sound” – “Building accessible websites – Chapter 13
2
WCAG 2.0: “narration added to the soundtrack to describe important visual details that cannot be
understood from the main soundtrack alone”
3
[http://www.w3.org/TR/1999/WAI-WEBCONTENT-TECHS-19990505/]
4
[http://www.w3.org/TR/WCAG20/appendixA.html#audiodescdef]
- 133 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Text description
Nel caso non sia possibile predisporre una versione audio di supporto, è possibile fornire una
trascrizione testuale del contenuto multimediale direttamente nella pagina Web o in una
pagina collegata in modo che le tecnologie assistive possano accedervi.
Questa tecnica è spesso definita come text description. Mantengo la terminologia inglese in
quanto il termine si confonde in italiano con le precedenti descrizioni testuali, traduzione usata
invece dell’originale inglese caption.
Dal momento che le text description sono create per utenti non vedenti e in genere queste
tipologie di disabili sono dotati di tecnologie adattative come i display Braille e gli screenreader, può avere un certo senso produrre del testo equivalente che permetta loro di accedere
ai contenuti con una lettura mediante voce sintetizzata.
Il problema di questa tecnica è che risulta veramente molto difficile, se non impossibile la
sincronizzazione come invece viene richiesto dalle normative citate.
Si tratterebbe, infatti, di avere il proprio lettore video in esecuzione mentre
contemporaneamente un sintetizzatore vocale pronuncia il testo a parte. Adattare il parlato al
filmato in queste condizioni risulta in pratica impossibile.
La strada corretta per fornire ausili per non vedenti ad un filmato è indubbiamente quella di
usare dei narratori umani.
In qualche modo le text description separate possono comunque essere una ultima risorsa di
accessibilità per gli utenti non udenti. Ma per gli utenti non vedenti esse non rappresentano
una soluzione valida1.
Per quanto dare la sola descrizione testuale su file a parte non sincronizzato non sia d’ausilio
per l’accessibilità, questi testi possono invece essere oggetto di motori di ricerca, di scansione,
di scaricamento o di stampa per cui potrebbe essere un aiuto valido fornirli, a patto che il
contenuto multimediale sia già stato trattato opportunamente con altri sistemi di accesso
sincronizzati.
Sincronizzazione
Il punto di controllo 1.4 delle WCAG 1.0 richiede espressamente che le versioni alternative
equivalenti siano sincronizzate: “Per ogni presentazione multimediale temporizzata,
sincronizzare le alternative equivalenti con la presentazione.”.
1
“A separate textual transcript that must be read after the fact does not provide an equivalent experience.”
– [http://www.w3.org/WAI/wcag-curric/sam22-0.htm]
- 134 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il motivo di questa richiesta è che altrimenti esse possono creare confusione e difficoltà di
orientamento agli utenti, in particolar modo per i disabili cognitivi.
La traccia alternativa delle descrizioni testuali sono un’alternativa per gli utenti con
menomazioni uditive, le descrizioni audio sono una alternativa per le menomazioni visive.
Sincronizzare queste alternative accessibili con la presentazione principale fa in modo che tutti
gli utenti possano avere la migliore fruizione ed ottenere le maggiori informazioni possibili 1.
La priorità per questa richiesta è di livello 1, quindi deve essere obbligatoriamente attuata ai
fini dell’accessibilità. Ad ogni modo per le persone che non siano in grado di accedere al
visualizzatore multimediale o per le persone sordo-cieche, una trascrizione testuale della
traccia video e di quella audio anche se non sincronizzata, viene considerata comunque una
alternativa utile.
Tecniche e strumenti
Il codice HTML fornisce gli appropriati elementi per accedere alle presentazioni multimediali.
Un collegamento ad una presentazione multimediale può essere:
Interno:
o
Con tecniche obsolete: <EMBED>, <APPLET>;
o
Con tecniche approvate: <OBJECT>;
Esterno con un collegamento ipertestuale: <A>.
È necessario precisare che <EMBED> è un elemento proprietario di Netscape che non è stato
mai approvato da W3C: pertanto non sarebbe possibile utilizzarlo all'interno di una pagina Web
(X)HTML STRICT e successivi, a maggior ragione se si desidera rispettare il punto di controllo
3.2 delle WCAG 1.0: “Creare documenti che rispettino le grammatiche formali.”.
L’elemento <APPLET> consente del testo a marcatori fra i suoi tag aperto e chiuso, ma anche
esso è considerato un elemento deprecato nelle specifiche recenti del linguaggio a favore
dell’uso di <OBJECT>.
Per le presentazioni incluse si dovrebbe utilizzare quest’ultimo, il problema può sorgere ancora
una volta nel caso di browser più datati che non sono in grado di operare correttamente con
questo elemento2. Ad ogni modo, la situazione è in via di miglioramento ed è questa la
soluzione da adottare per le presentazioni multimediali incluse.
1
[http://www.w3.org/WAI/wcag-curric/sam22-0.htm]
Joe Clark: “The bad news is that, for all its marvels, <object></object> is so poorly supported by realworld browsers – actually crashing Internet Explorer 4.01 for Windows in some unusual cases – that it is
quite unusable.”
2
- 135 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
I collegamenti ipertestuali di tipo esterno possono invece essere normalmente inclusi nella
pagina e puntare ad un file multimediale non incluso nel documento.
Avremo quindi a disposizione presentazioni multimediali di differenti tipologie:
Indipendenti dal documento (X)HTML:
o
Con contenuti accessibili inclusi nel documento, ad esempio mediante open
captions;
o
Con contenuti accessibili su file separati;
Inclusi nei documenti (X)HTML con linguaggi a marcatori (SAMI, SMIL).
La tecnica suggerita per includere i contenuti multimediali nella pagina (X)HTML è quella di
impiegare SMIL, l’apposito linguaggio a marcatori raccomandato dal W3C, di cui si parlerà in
seguito.
Negli altri casi non è possibile fornire esplicitamente i contenuti alternativi se non lavorando
direttamente con il visualizzatore proprietario.
Creazione di contenuti accessibili
In sostanza per rendere accessibile un contenuto multimediale serviranno:
Il file audio/video in un formato supportato dall’utente (.avi, .mpg);
I documenti alternativi accessibili che possono essere:
o
Il documento contenente la trascrizione della traccia audio come descrizioni
testuali (captions);
o
Una registrazione equivalente della descrizione audio;
Un programma che consenta di generare dei documenti di supporto, come MagPie.
Per i file audio/video occorre ricordare che esistono purtroppo diversi formati che non sono per
nulla compatibili uno con l’altro.
Tra i più importanti ricordiamo
Windows Media;
QuickTime;
RealMedia;
Flash.
Per ognuno di questi formati l’utente deve dotarsi del lettore multimediale relativo. Anche se
molti di questi sono scaricabili gratuitamente almeno nel loro formato base, resta il problema
della generica incompatibilità dei loro formati.
Per le descrizioni testuali e le descrizioni audio esiste una vasta letteratura attinente le regole
di produzione di questi materiali.
- 136 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Magpie
Per predisporre ed assemblare le risorse equivalenti accessibili esistono in commercio numerosi
prodotti, in licenza d’uso o del tutto liberi. Un valido elenco1 è suggerito direttamente dal W3C.
A questo proposito vale la pena segnalare il sito in lingua inglese Captioning Sofwtare and
Hardware2 che contiene numerosi collegamenti ipertestuali utili e altre risorse valide per
lavorare con le descrizioni alternative.
Sicuramente uno dei prodotti più indicati, anche dal consorzio W3C, è MAGpie3 della WGBH, un
editor specializzato nella creazione e nell’aggiunta di queste descrizioni, messo a disposizione
gratuitamente dalla NCAM (National Center for Accessibile Media).
Il vantaggio di questo programma è che dalla versione 2.0 in poi è in grado di lavorare con i
diversi formati video esistenti e può produrre in uscita un formato compatibile con SMIL, SAMI
oltre che in testo semplice.
Non è qui il caso di descrivere accuratamente il funzionamento di questo strumento, rimando
per questo ai manuali in linea della stessa NCAM.
Tra le altre funzionalità è importante ricordare che:
Il programma è disponibile gratuitamente per diverse piattaforme e lavora con i
maggiori formati audio/video;
Permette di importare o di creare del testo che verrà usato per la creazione di
descrizioni testuali o sottotitoli. Il testo deve seguire delle regole sintattiche che sono
specificate nella manualistica del programma;
Si possono scegliere gli stili preferiti o predefiniti per la visualizzazione del testo, font,
colori, sfondo, dimensioni ed effetti;
Si possono creare diverse tracce per diverse lingue;
Permette di incidere direttamente da microfono i file che fungeranno da descrizione
audio o di importarli da formati predefiniti (WAV).
Una volta preparata una presentazione completa è possibile esportare il lavoro nei formati:
1
2
3
Plain text;
QuickTime SMIL;
RealPlayer SMIL;
Windows Media Player SAMI.
[http://www.w3.org/AudioVideo/]
[http://www.captions.org/softlinks.cfm]
[http://ncam.wgbh.org/webaccess/magpie/]
- 137 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
SAMI (Synchronized Accessible Media Interchange) è un linguaggio della famiglia XML creato
dalla Microsoft nel 1997.
In genere viene impiegato da Windows Media Player, il suo maggior difetto è che non supporta
ancora le descrizioni audio equivalenti e il supporto dello stesso Microsoft Media Player per
SMIL è piuttosto debole.
SMIL
SMIL (Synchronized Media Integration Language) invece è un linguaggio a marcatori della
famiglia XML, creato nel 1998 su raccomandazione1 del W3C e viene impiegato per gli altri
visualizzatori multimediali.
Linguaggi come SMIL consentono di creare i sottotitoli in differenti lingue e quindi rendono
accessibile in modo potenzialmente universale i contenuti.
Con SMIL è possibile creare file per contenuti multimediali accessibili, incluse le descrizioni
testuali e le descrizioni video. SMIL permette di collegare insieme testo, audio e video in
qualsiasi combinazione desiderata permettendo di descrivere cosa deve apparire e quando in
un contenuto multimediale.
Non si applica solamente alla musica o ai filmati, potenzialmente può fornire supporto anche
alle presentazioni di PowerPoint o alle GIF animate.
Il supporto per questo linguaggio è quasi del tutto completo al di fuori del mondo Microsoft ed
anche qui le cose stanno migliorando con la compatibilità garantita da Internet Explorer dalla
versione 6 e successive e la creazione del formato compatibile HTML +Time.
Per rendere accessibile un contenuto SMIL vanno seguite alcune avvertenze 2, dal momento che
SMIL è stato concepito nel 1998, l’anno prima che venissero ufficialmente rilasciate almeno le
WCAG 1.0:
Vanno preparate le versione alternative equivalenti dei contenuti tramite le descrizioni
testuali e le descrizioni audio indicate in precedenza;
Le versioni alternative equivalenti vanno sincronizzate;
Si deve fornire il modo di controllare il flusso della presentazione.
Il documento del W3C specifica poi come le presentazioni multimediali possano includere due
tipi principali di alternative equivalenti:
1
2
[http://www.w3.org/TR/SMIL-access/]
[http://www.w3.org/TR/SMIL-access/]
- 138 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Discreti: sono quelli che non contengono alcun riferimento temporale e non hanno una
durata intrinseca. Possono essere specificati come attributi da aggiungere all’elemento.
Di questa categoria fanno parte ALT, LONGDESC, TITLE, AUTHOR, ABSTRACT;
Continui: hanno invece una durata intrinseca e possono contenere riferimenti temporali,
ne fanno parte attributi come PAR, SEQ, BEGIN, END, DUR e gli elementi discussi in
precedenza come le descrizioni audio e testuali.
Descrivere le singole specifiche del linguaggio va oltre gli scopi di questa tesi. Si rimanda ai
collegamenti ipertestuali citati del W3C per gli approfondimenti necessari.
Conclusioni
Un aspetto piuttosto critico dei contenuti multimediali sottolineato con forza da Joe Clark 1 è il
problema delle interfacce dei visualizzatori.
Sebbene questo non dovrebbe essere un problema che riguardi i progettisti di siti, tuttavia vale
la pena mettere in evidenza questa problematica.
In genere una difficoltà uditiva non ostacola l’uso dei controlli di un visualizzatore
multimediale, tuttavia i non vedenti, gli ipovedenti e gli utenti con disabilità motorie incontrano
sicuramente dei problemi nelle interfacce a bottoni che simulano i controlli di un
videoregistratore.
Per le visualizzazioni incluse nella pagina Web è praticamente impossibile usare il tasto di
tabulazione per muoversi e raggiungere i controlli interni del visualizzatore, gli equivalenti per
la tastiera sono spesso insufficienti.
In particolar modo gli utenti di screen-reader sono scarsamente assistiti dovendo lavorare con
una successione di interfacce (hardware, sistema operativo, screen-reader, visualizzatore,
contenuto ed accessibilità del contenuto) che rendono impossibile l’attivazione e la fruizione dei
contenuti alternativi come le descrizioni audio anche quando queste sono fornite.
Da questo punto di vista gli autori delle pagine Web hanno poco che possono fare per ovviare
questo problema.
L’unico suggerimento possibile è quello di tenere in dovuta considerazione le trascrizioni
testuali (text description) che possono essere considerata come l’ultima risorsa nel caso si
voglia garantire comunque l’accesso all’informazione.
1
[http://joeclark.org/book/sashay/serialization/Chapter13.html]
- 139 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
III.9 - Tecniche specifiche
In questa sezione vorrei riassumere alcune tecniche operative nate dalla prassi e dai
suggerimenti di chi con l’accessibilità lavora quotidianamente.
Qualcuna non è espressamente contenuta nell’impianto delle normative esposte, anzi, a volte,
può non esistere un punto di vista comune sull’argomento e la materia è oggetto di discussione
fra gli addetti ai lavori.
Apertura nuove finestre
Nella stragrande maggioranza dei siti Web attualmente presenti in rete risulta prassi comune
quella di aprire delle nuove finestre per molti dei collegamenti ipertestuali della pagina.
Questi rimandi a pagine esterne a quella corrente spesso poi non sono nemmeno
accompagnati da un avviso che avverta l’utente del cambiamento di contenuto, con il risultato
che l’utente stesso si trova davanti una visualizzazione completamente diversa dopo il richiamo
del collegamento.
Se questa situazione può essere accettata per le navigazioni visuali, il problema diventa
rilevante per una navigazione tramite screen-reader o dispositivi che abbiano una gestione
differente o ridotta dello schermo.
In tal caso, infatti, le nuove pagine aperte catturano immediatamente il focus e alcune
tipologie di utenti, possono rimanere disorientati od irritati da questo improvviso cambiamento
di contenuto. Per di più la pagina nuova non permette all’utente di tornare indietro, dal
momento che è la prima di una nuova cronologia.
Se in genere questo non risulta particolarmente frustrante per utenti normodotati, tuttavia per
persone disabili potrebbe rappresentare motivo di seri problemi recuperare la finestra di
windows originaria.
Un esempio di questa scorretta pratica è il seguente:
<a href="sport.htm" target="_blank">Pagina sportiva</a>
La nuova pagina si apre in una nuova finestra che diventa la finestra attiva avendo specificato
come attributo TARGET="_BLANK".
Una prima possibile soluzione è di dotare il collegamento ipertestuale almeno di un avviso che
informi l’utente di quanto sta per succedere al momento di attivare il collegamento. Questo si
può fare con l’attributo TITLE:
<a href="sport.htm" target="_blank" title="Attenzione: collegamento ad una nuova
finestra">Pagina sportiva</a>
Per questi motivi l’attributo TARGET è stato eliminato nelle versioni STRICT di in HTML 4.01 e
XHTML 1.0 ,per scomparire completamente a partire da XHTML 1.1. Questo è il motivo per cui i
codici sopra citati sono validi solamente nelle versioni FRAMESET e TRANSITIONAL.
- 140 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
A chiarire ulteriormente la situazione sono intervenute le WCAG 1.0 dove, al punto di controllo
10.1, richiedono che: “Fino a quando i programmi utente non permetteranno agli utenti di
bloccare l'apertura di nuove finestre, non si devono far apparire pop-up o finestre di altro tipo
e non si deve cambiare la finestra attiva senza informare l'utente.”.
Questo concetto è ripreso anche dalle WCAG 2.0 alla linea guida 3.2 che richiede di: “Rendere
determinabile la posizione e la funzionalità del contenuto”.
I concetti si sintetizzano nel documento di tecniche 1 delle WCAG 1.0: “Gli sviluppatori devono
astenersi dallo specificare una nuova finestra come valore di un frame con l’opzione
target=“_blank”.”.
Auto aggiornamenti
Non è improbabile imbattersi anche recentemente in dei siti Web che re-indirizzino l’utente in
maniera automatica verso un nuovo indirizzo Web o che rinfreschino autonomamente i
contenuti del sito.
E’ una prassi particolarmente diffusa ad esempio per i siti delle agenzie di stampa, delle ultime
notizie, dei risultati sportivi o elettorali eccetera, siti che forniscono contenuti in tempo reale e
che quindi richiedono un frequente aggiornamento delle informazioni.
Questi siti, per non costringere l'utente a dover rinfrescare spesso la pagina Web in maniera
forzata per avere gli ultimi aggiornamenti delle notizie, spesso impiegano l'elemento META HTTPEQUIV="REFRESH"
per definire una frequenza di aggiornamento della pagina in automatico.
Tuttavia il caricamento automatico della medesima pagina o di una pagina nuova può causare
problemi ad alcune categorie di utenti, in particolare:
Gli utenti che hanno bisogno di maggior tempo per leggere i contenuti potrebbero non
riuscire a fruire dell’intero contenuto informativo prima che questo venga rinfrescato;
Gli utenti che utilizzano i lettori di schermo troveranno fastidioso dover ricominciare a
leggere i contenuti se ricaricati al momento non opportuno;
Ci possono essere delle possibili difficoltà nel ritornare alla pagina precedente dopo un
re-indirizzamento in automatico.
Queste considerazioni sono state recepite nelle normative in studio e tutte presentano gli
opportuni requisiti di accessibilità:
WCAG 1.0, punto di controllo 7.4: “Fino a quando i programmi utente non forniranno la
possibilità di bloccare l'auto-aggiornamento, non creare pagine che si auto-aggiornano
1
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#no-new-windows]
- 141 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
periodicamente.”, Punto di controllo 7.5: “Fino a quando i programmi utente non
forniranno la capacità di bloccare l'auto-reindirizzamento, non usare marcature per
reindirizzare le pagine automaticamente.”;
Section 508, 1194.22 (p): “Nei casi in cui sia richiesta una risposta a tempo, l'utente
dovrà venire avvisato e gli dovrà venir fornito tempo sufficiente per indicare che ha
bisogno di un'ulteriore quantità di tale risorsa.”;
D.M. 8 Luglio 2005: “Nel caso che in una pagina sia previsto un servizio a tempo come
ad esempio un refresh, è necessario avvisare l’utente del tempo massimo utile previsto
e fornire eventuali alternative.”.
Come si può notare, le WCAG 1.0 tengono in particolare considerazione il concetto di reindirizzamento distinguendolo in un punto di controllo differente (7.5) rispetto a quello del
ricaricamento in automatico della stessa pagina (7.4).
Per quanto riguarda l’auto-aggiornamento, non viene imposto di disabilitare questa
funzionalità, semplicemente viene richiesto di avvisare gli utenti, in modo che in ogni caso
siano preparati all'evento. Ove non fosse possibile, è preferibile fornire un collegamento ad una
versione alternativa senza auto-aggiornamento.
Per quanto riguarda il re-indirizzamento in automatico si consiglia di utilizzare dei normali
collegamenti alla nuova pagina anziché delle funzionalità automatiche evitandone l’uso ove
possibile, in quanto la navigazione deve essere sotto il totale controllo dell'utente.
Nel caso che sia necessariamente richiesto di re-indirizzare la richiesta ad una nuova pagina
questo può essere fatto direttamente dal server configurandolo in modo che esegua
automaticamente i re-indirizzamenti nececessari come suggerito nelle tecniche del punto di
controllo 7.5.
Collegamenti ipertestuali
Il punto di controllo 13.1 delle WCAG 1.0 raccomanda di: “Identificare con chiarezza la
destinazione di ogni collegamento.”.
Quando il progettista definisce un collegamento ipertestuale è necessario che il testo del
collegamento abbia un senso sufficientemente comprensibile ed informativo in modo che
l’utente possa valutare se accedere o meno a quella risorsa.
Ad esempio, se si dovesse decidere di fare un collegamento ipertestuale al sito del ministero
per consultare il testo integrale della legge Stanca ci potrebbero essere diversi approcci:
Collegamento troppo lungo:
<a href=”testo.html”>Il testo del disegno di legge sull’accessibilità.</a>
Un collegamento ipertestuale deve essere sintetico e non confondere la lettura creando
degli effetti sgradevoli nella pagina;
- 142 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Mancante di con testualità:
Il testo del disegno di legge sull’accessibilità. <a
href=”testo.html>clicca qui</a>
E’ il classico clicca qui assolutamente da evitare. Navigando da tastiera il clicca qui non
ha nessun riferimento contestuale. Si rischiano di mettere in difficoltà gli utenti con
disabilità cognitive e quelli che navigano con browser testuali;
Parzialmente corretto:
Il <a href=”testo.html>testo</a> del disegno di legge sull’accessibilità.
In questo caso il testo del collegamento è sufficientemente corto ed è posto
direttamente sulla parola centrale della frase. Tuttavia può non essere adeguato in certi
casi per dare una descrizione completa del collegamento stesso;
Con attributo TITLE descrittivo:
Il <a href=”testo.html” title=”Gli articoli del disegno di
legge”>testo</a> del disegno di legge sull’accessibilità.
In questo caso l’attributo TITLE descrive la pagina di destinazione e fornisce una
informazione ulteriore sia ai browser testuali che a quelli grafici. L’attributo TITLE viene
infatti visualizzato come un suggerimento a comparsa o nella barra delle informazioni di
qualche browser. Per quanto riguarda i browser testuali il comportamento non è
omogeneo, tuttavia tendono molti tendono a tenerlo in considerazione. A questo
proposito rimando ad un utile tabella1 di Steven Faulkner, per quanto leggermente
datata, del comportamento degli screen-reader con l’attributo TITLE;
Con informazioni su eventuali download:
Il <a href=”testo.zip title=”documento.zip da 100Kb contenente il testo
del disegno di legge”>testo</a> del disegno di legge sull’accessibilità.
In sostanza l’attributo TITLE può essere impiegato per descrivere sia la tipologia di file collegato
che per le importanti informazioni su un eventuale scaricamento.
Da notare che l’attributo TITLE può essere vantaggiosamente impiegato anche per informare
che si sta per aprire una nuova finestra, così come spiegato nel paragrafo dell’apertura delle
nuove finestre:
Il <a href=”testo.html title=”[link su nuova finestra] gli articoli del disegno
di legge” target=”_blank”>testo</a> del disegno di legge sull’accessibilità.
1
[http://www.sf.id.au/WE05/forms.html]
- 143 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Una cosa che invece risulta del tutto inutile è quella di fornire comunque un attributo TITLE al
collegamento e ripetervi l’etichetta del collegamento stesso. L’attributo TITLE non è obbligatorio
e a volte non è nemmeno letto da alcuni screen-reader, per cui non serve metterlo se non
fornisce effettivamente delle informazioni aggiuntive.
Una considerazione va fatta sulle parentesi quadre che si possono trovare preposte alla dicitura
del testo. L’uso delle parentesi quadre è abbastanza comune all’interno del testo dell’attributo
TITLE
per distinguerlo spesso dall’attributo ALT nelle immagini. Per analogia si può trovare anche
in altri elementi dove il testo ALT non sia presente.
Si sconsiglia di usare dei termini troppo tecnici o in lingua straniera per descrivere il contenuto.
Alcuni autori considerano che anche la semplice dicitura Home nell’attributo TITLE potrebbe
risultare inutile per gli utenti che non conoscano la lingua inglese.
Un’ultima considerazione va fatta per quanto riguarda soprattutto l’usabilità. Le tecniche HTML
per le WCAG 1.0 consigliano1 di porre attenzione ai testi di collegamento. In particolare se due
o più collegamenti sulla stessa pagina hanno lo stesso testo di rimando, questi dovrebbero
anche puntare alla stessa risorsa collegata. Tale coerenza, infatti, può aiutare sia l’utilizzatore
che il progettista della pagina a mantenere consistenti le informazioni che propone.
Se due o più collegamenti si riferiscono a differenti oggetti, ma hanno lo stesso testo di
collegamento, si consiglia di distinguere i collegamenti stessi specificando un valore differente
nell’attributo TITLE per ognuno di loro.
Grammatiche formali
Per controllare la validità di un documento è essenziale riferirsi ad un insieme di regole di una
grammatica formale così come definita dal W3C.
La dichiarazione di conformità ad una grammatica formale deve essere posta in testa al
documento. Questo consente al programma di visualizzazione della pagina, il cosiddetto user
agent, di poter valutare la semantica corretta da utilizzare.
Secondo il linguaggio scelto, XHTML o HTML, nelle varie versioni, sono possibili diverse
intestazioni.
La struttura base, valida per un codice scritto in XHTML STRICT è la seguente:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
1
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text]
- 144 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
<title>An XHTML 1.0 Strict standard template</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
</head>
<body>
<p>… contenuto …</p>
</body>
</html>
Nel codice è stata presentata una codifica dei caratteri di caratteri del tipo utf-8, una codifica
dei caratteri Unicode in sequenze di lunghezza variabile di byte. La descrizione di un set di
caratteri va di là dagli scopi di questo lavoro e si rimanda a testi specifici come quelli ufficiali di
definizione1, o quelli2 del W3C.
Per un set di caratteri che comprenda tutti i caratteri degli alfabeti latini spesso si impiega
anche la codifica ISO-8859-1, denominata, appunto Latin 1.
Per quanto riguarda invece gli altri linguaggi (X)HTML occorrerà apportare variazioni alla
dichiarazione DOCTYPE.
Per HTML 4.01, STRICT, TRANSITIONAL e FRAMESET:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
Notare l’uso del termine loose della dichiarazione DTD di TRANSITIONAL e la mancanza della
dicitura strict nell’identificatore pubblico della DTD STRICT.
Per XHTML 1.0, STRICT, TRANSITIONAL e FRAMESET:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
Per XHTML 1.1:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
1
2
[http://www.ietf.org/rfc/rfc3629.txt]
[http://www.diodati.org/w3c/html401/sgml/entities.html]
- 145 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per XHTML 2.0 (non ancora ufficiale):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml2.dtd">
Come si vede, una dichiarazione di semantica è costituita da molteplici informazioni:
TopElement: HTML, il tipo di documento SGML;
Availability: PUBLIC, dichiara se il tipo di documento referenziato è pubblico o meno (il
valore alternativo è SYSTEM);
Formal public identifier: "-//W3C//DTD XHTML 1.0 Strict//EN";
Registration: indica se l'organizzazione che ha definito la DTD è registrata all'ISO o
meno (il W3C non lo è). Il valore alternativo è +;
Organization: W3C, l'organizzazione che ha creato e mantiene la DTD;
Type: DTD, specifica a cosa si riferisce la dichiarazione (una DTD, nel nostro caso);
Label: XHTML 1.0, il nome descrittivo della DTD referenziata, che può contenere la
versione del documento;
Definition: STRICT, il tipo di DTD, se ne esiste più di un tipo per il linguaggio
referenziato;
Language: EN, la lingua in cui è scritta la DTD;
URI: "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" L'indirizzo dove
fisicamente risiede il documento referenziato.
Fogli di stile secondari
Una delle tecniche che recentemente si vedono molto sui siti Web è quella di mettere a
disposizione dell’utente una serie di visualizzazione alternative della pagina basate in genere su
un altro insieme di caratteri maggiormente accessibili (di solito con dimensioni più grandi e
font senza grazie) e diverse combinazioni di colori a contrasto elevato (nero su bianco, nero su
giallo, giallo su nero eccetera) o addirittura linearizzando il testo e sopprimendo le eventuali
colonne.
L’impostazione di queste visualizzazioni alternative è realizzata applicando un nuovo foglio di
stile pre-confezionato dal progettista della pagina Web e studiato appositamente per facilitare
gli ipovedenti nella fruizione della pagina.
L’utilizzo dei fogli di stile alternativi è previsto esplicitamente dal linguaggio con l’attributo
ALTERNATE STYLESHEET
da introdurre nella sezione HEAD del documento come spiegato nella parte
riguardante il linguaggio.
- 146 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In oltre, nelle UAAG, nelle tecniche per le linee guida per lo sviluppo dei programmi utente, si
fa chiaro riferimento1 alla necessità di consentire all’utente di gestire i fogli di stile,
conferendogli una priorità di primo livello:
“Consentire agli utenti di scegliere ed applicare un foglio di stile alternative tra i fogli di
stile proposti dall’autore delle pagine.(come ad esempio i fogli di stile collegati).”;
“Consentire agli utenti di scegliere ed applicare almeno uno fra i fogli di stile definiti
dall’utente.”;
“Consentire agli utenti di disattivare ignorare i fogli di stile dell’autore e dell’utente.”.
Le tecniche sono suggerite per un punto di controllo di primo livello e sono anche piuttosto
esplicite. Tuttavia, al momento attuale, non tutti i browser vi si sono adeguati. Firefox e Opera
consentono totalmente o parzialmente queste operazioni. Internet Explorer permette
solamente di impostare un foglio di stile utente.
Senza passare per i servizi offerti dai browser esistono comunque due sistemi per consentire
concretamente all'utente di cambiare lo stile di presentazione di una pagina, in modo da
adattarla alla sue preferenze:
Il primo sistema, molto utilizzato, è quello di accoppiare gli stili CSS alternativi
predisposti dall'autore ad appositi JavaScript, che senza dover ricaricare via internet il
contenuto della pagina sono in grado di applicare gli stili alternativi, in base alle scelte
dell'utente, con un cambio di presentazione pressoché immediato;
Il secondo sistema utilizza degli script lato server, invece che lato client, l'utente non
richiama un JavaScript eseguibile dal proprio browser, ma ricarica la pagina
direttamente dal server remoto, tramite un parametro passato che innesca una serie di
eventi previsti dal codice di programmazione lato server. Il risultato è che il server
remoto fornisce al browser dell'utente una nuova versione della pagina, con
caratteristiche di visualizzazione differenti.
Lo svantaggio del primo approccio consiste nella problematica applicazione degli script per quei
navigatori che li hanno disabilitati, il punto di controllo 6.3 delle WCAG 1.0 chiede, infatti, di:
“Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di
programmazione sono disabilitati oppure non supportati.”.
1
[http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-select-style-sheets],
[http://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-styles]
- 147 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il secondo, migliore come accessibilità, prospetta ad ogni modo il problema di ricaricare
interamente la pagina.
Su WebAccessibile è disponibile un interessante articolo1 di Franco Frascolla sull’inutilità delle
visualizzazioni alternative basate sul contrasto elevato.
L’autore parte da una premessa indicativa, e cioè che per essere considerate accessibili anche
le versioni normali dei siti devono essere tali quindi, non sarebbe giustificabile, né necessaria,
la creazione di layout alternativi basati su diverse combinazioni a livello di contrasto testosfondo.
Come sappiamo, i browser permettono di escludere le combinazioni di colori previste dagli
autori, anche tramite CSS, per utilizzare CSS propri o le combinazioni impostate a livello di
sistema operativo.
E’ quindi normale che un ipovedente che ha necessità di utilizzare una specifica combinazione
di colori tenderà a impostarla una volta per tutte su misura per se stesso, senza essere
costretto a ricorrere, sito per sito, a quelle offerte dallo sviluppatore.
Di per se stessa questa opportunità rappresenta lo strumento più ampio, versatile ed
economico di personalizzazione. A chi costruisce pagine Web basterebbe tenere presente
quest’aspetto in fase di progettazione, sviluppo e test delle pagine, per realizzare un prodotto
pienamente accessibile, senza ricorrere a incerte soluzioni molto spesso solo scenografiche.
L’importante per lo sviluppatore sarebbe di preoccuparsi e di verificare la tenuta strutturale del
layout almeno fino ad una riduzione della finestra, ad un ingrandimento ragionevole del testo
ed a prescindere dalla combinazione di contrasto testo-sfondo utilizzata dall'utente. Di sicuro
aiuto è il fatto che la dimensione del testo dovrebbe essere implementata in modo relativo nel
codice originario.
Questa soluzione vanifica anche i sistemi di personalizzazione manuale visti in precedenza.
Escludere la combinazione di colori prevista dall'autore per utilizzare quelle già implementate
in Windows è sicuramente più semplice ed immediato che personalizzare ogni elemento
presente nel sito.
Frascolla si spinge fino ad affermare che queste versioni alternative ad alto contrasto,
dovrebbero essere addirittura deprecate perché inficiano l'usabilità del sito e si sovrappongono
a funzionalità che dovrebbero già essere considerate in fase di sviluppo comunque già gestite
dai browser.
1
[http://www.webaccessibile.org/argomenti/argomento.asp?cat=528]
- 148 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Significativo il suo richiamo a orientare invece lo sforzo sull'informare gli ipovedenti circa le
possibilità di personalizzazione messe a disposizione da sistemi operativi e browser e a creare
pagine Web che possano essere facilmente personalizzate con gli strumenti già a disposizione.
Una sezione a parte di questo lavoro è dedicata agli strumenti di accessibilità messi a
disposizione dal sistema operativo Microsoft Windows.
Fotosensibilità
Ritengo che questo argomento meriti una piccolo trattazione a parte. Per quanto breve è
comunque di notevole rilevanza, dal momento che tratta problemi che possono riguardare
direttamente la salute degli utenti.
Al punto di controllo 7.1 delle WCAG 1.0 viene specificato che: “Fino a quando i programmi
utente non permetteranno agli utenti di controllare lo sfarfallio, evitare di far sfarfallare lo
schermo.”. Una medesima attenzione va posta per il lampeggiamento del testo al punto di
controllo 7.2.
In quest’enunciato è stato tradotto il termine inglese di flickering con sfarfallio, si intende
l’intermittenza delle immagini che possono causare crisi di epilessia fotosensibile in utenti
suscettibili.
Da notare, soprattutto per il punto di controllo 7.2, che con le ultime versioni del linguaggio,
l’elemento <BLINK> utilizzato per rendere il lampeggiamento del testo è stato deprecato e poi
eliminato dalle specifiche, e la sua inclusione nel codice non ne permette la validazione
formale. Tuttavia anche nelle specifiche CSS di livello 2 l’attributo BLINK è ancora presente per
quanto sconsigliato.
La medesima attenzione agli attacchi foto-epilettici viene espressa anche dal Decreto
Ministeriale della legge Stanca al requisito 5 e nella Section 508 al paragrafo 1194.22 (j).
Nelle WCAG 2.0 viene dedicata a questo problema addirittura una intera linea guida. Nella
linea guida 2.3, infatti, si richiede di: “Consentire agli utenti di evitare i contenuti che possono
causare attacchi di epilessia fotosensibile.”.
Un attacco epilettico può essere provocato da sfarfallii e lampeggiamenti che si verifichino
nell’intervallo di certe frequenze ben determinate. Il campo di intervallo più ampio delle
frequenze a rischio è circa dai 2 a 60 Hertz con un punto di ipersensibilità intorno ai 20
lampeggiamenti al secondo.
Le normative non sono del tutto concordi sulle frequenze, in particolare:
Le WCAG 1.0 raccomandano di evitare soprattutto le frequenze tra 4 e 59 Hertz, con il
picco sopra citato intorno ai 20 Hertz;
Le normative americane consigliano di evitare l’intervallo tra 2 e 55 Hertz;
La legge italiana non indica frequenze specifiche nei requisiti Web, le richiede invece nei
requisiti software riproponendo i valori delle leggi americane tra 2 e 55 Hertz;
- 149 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Le WCAG 2.0 sono molto più precise nella definizione dei termini e raccomandano, in
appendice A, di evitare le frequenze fra i 3 ed i 50 Hertz.
Alcuni lettori di schermo possono avere anche problemi con i testi lampeggianti o con le scritte
scorrevoli.
Spesso l'effetto di movimento dei testi viene generato da script o applet in tal caso è
necessario fornire un meccanismo all'interno di uno script o applet per permettere agli utenti di
bloccare il movimento o gli aggiornamenti.
Per la stessa motivazione è necessario utilizzare con parsimonia le GIF animate ed animazioni
in generale come quelle contenute nei filmati flash. In tal caso potrebbero sorgere dei problemi
se tra un frame e l’altro di una animazione ci fossero contrasti di colore eccessivo da disturbare
o causare crisi epilettiche.
Sul sito di WebAccessibile1 esiste un validatore per le GIF animate con cui controllare la
funzionalità degli elementi. Esistono anche degli appositi applicativi per controllare la frequenza
di sfarfallamento2.
Frameset
Con una struttura FRAMESET è possibile visualizzare in un’unica schermata più di una pagina
Web contemporaneamente, inserendola in strutture separate dette appunto frame.
Dalle ultime versioni del linguaggio XHTML 1.1 il costrutto FRAMESET è stato del tutto eliminato,
mentre nelle versioni HTML 4.01 e XHTML 1.0 occorre dichiarare un’apposita compatibilità
FRAMESET
per poterlo utilizzare e non è la compatibilità migliore a cui dovrebbero rifarsi i
documenti.
Il W3C tollera ancora il loro impiego, sconsigliandone però l’uso. Nel punto di controllo 12.1 si
raccomanda che abbiano tutti l’attributo TITLE, nel punto 12.2 si richiede di descriverne lo
scopo e le relazioni mentre si raccomanda di produrre del codice anche per i browser che non li
supportino ai punto di controllo 1.1 e 6.5.
La legge italiana 04/2004 invece, nei suoi requisiti tecnici del decreto ministeriale 8 Luglio
2005 vieta esplicitamente al punto 2 l’uso dei frame nei nuovi siti, lo ammette per i siti già
esistenti ma con significative limitazioni.
La section 508 al paragrafo (i) richiede solamente l’espressa titolazione dei frame, ma ne
consente l’impiego.
1
2
[http://www.webaccessibile.org/test/check.aspx]
[http://ncam.wgbh.org/richmedia/examples/127.html]
- 150 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La motivazione del progressivo disuso di questo strumento è che alcuni user agent non
possono accedere a più frame contemporaneamente o possono essere configurati
esclusivamente per visualizzare un solo frame alla volta.
Un esempio di questi programmi utente possono essere le applicazioni software di supporto
per gli utenti non vedenti, alcuni modelli di palmare, chioschi informativi, smartphone ed altri
dispositivi.
In oltre è difficile tenere traccia di quello che sta succedendo nelle molteplici strutture di un
FRAMESET
con un passaggio di focus che potrebbe essere tracciato scorrettamente dagli screen-
reader, soprattutto se vengono aperte delle nuove pagine in frame differenti da quello dove è
stato attivato il collegamento ipertestuale.
Data l’insistenza delle normative sul non utilizzo di questo strumento se ne sconsiglia
vivamente l’impiego, soprattutto per siti che dovrebbero essere a norma con la più restrittiva
legge italiana.
Nel caso che, comunque, se ne volesse necessariamente fare uso si raccomanda:
Non usare una grammatica formale di tipo STRICT, sia per HTML 4.01 che per XHTML
1.0, e di non usare XHTML 1.1 che non li contempla;
Assegnare un titolo a ogni frame per facilitarne l'identificazione e la navigazione.
Utilizzando l'attributo TITLE per i frame è possibile fornire informazioni al visitatore sul
contenuto di quella particolare struttura, consentendo all'utente di selezionare il frame
desiderato;
Descrivere lo scopo dei frame e il modo in cui questi interagiscono se non è evidente
solo tramite i titoli dei frame;
Per il punto di controllo 6.2 delle WCAG 1.0 è necessario che gli equivalenti dei
contenuti dinamici siano aggiornati al variare del contenuto, quindi gli sviluppatori
devono aggiornare le precedenti descrizioni di relazioni tra i frame nel caso in cui il
contenuto di un frame cambi di semantica;
Fornire sempre un’alternativa per i browser che non visualizzano i frame. Questo può
essere fatto esplicitamente con l’elemento <NOFRAME> dove devono essere inserite tutte
le informazioni necessarie per accedere ai contenuti equivalenti accessibili anche senza
l’utilizzo del costrutto <FRAMESET>. Spesso gli editor (X)HTML visuali generano
automaticamente un testo per l'elemento <NOFRAMES> informando gli utenti della
necessità di utilizzare un browser che supporti obbligatoriamente i frame: ciò non è
corretto, in quanto il contenuto di <NOFRAMES> deve riportare informazioni equivalenti a
quelle presenti nei frame.
In alcuni casi l'attributo TITLE può non essere sufficiente per spiegare la struttura o lo scopo
dell'elemento <FRAME> o dell'elemento <FRAMESET>.
- 151 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In questi casi è consigliabile utilizzare l'attributo LONGDESC come ulteriore descrizione
dell'elemento frame.
In questo modo si rende disponibile un collegamento ad un documento (pagina senza frame)
che contiene una descrizione completa per una pagina con una struttura complessa di frame.
Segue un esempio elementare di questa struttura.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="it">
<head>
<title>Esempio di frameset</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
</head>
<frameset cols="20%, 80%" title="Esempio di frameset" longdesc="descrFR.html" >
<frame src="menu.html" title="Menu di navigazione" />
<frame src="main.html" title="Pagina iniziale" longdesc="descr-main.html" />
<noframes>
<body>
<p>Il documento è composto da due frames di cui sono riportati i
collegamenti:</p>
<p><ul>
<li><a href="navigazione.html">Navigazione</a>
<li><a href="principale.html">Contenuto</a>
</ul></p>
</body>
</noframes>
</frameset>
</html>
Come si può notare, l’elemento FRAMESET rimpiazza completamente l’elemento BODY nel codice
sostituendolo con un elenco di frame indipendenti.
Una utile modalità di controllo per dell’impiego di frame all’interno di una pagina è fornita dalla
barra di accessibilità.
Con questa si può avere il controllo completo di tutti gli elementi. In particolare si può
verificare e visualizzare la presenza di ogni singolo frame dal menù struttura, evidenziandone
NAME
e TITLE con le relative descrizioni testuali per controllare che siano stati nominati
correttamente come richiesto dalla legge.
Nel documento di tecniche HTML per le WCAG 1.0 è esposta un’interessante tecnica1 per
rendere la funzionalità primaria del frame di sinistra, quella di fungere di menu di navigazione.
Questa tecnica, esposta nel 2000, non ha trovato tuttora una sufficiente applicazione da parte
dei browser, soprattutto del più usato Internet Explorer.
1
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#alt-frames]
- 152 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In tal caso viene consigliato di includere in un elemento <OBJECT> il menu di navigazione
definito in un file a parte ed importato nell’(X)HTML dal costrutto < OBJECT> medesimo.
Linguaggi per rappresentazioni specifiche
Le equazioni matematiche e quelle scientifiche, i simboli e le note musicali vengono spesso
rappresentate come delle immagini all’interno di una pagina Web.
Se vengono fornite solamente in questo modo esse non sono accessibili.
Il punto di controllo 3.1 delle WCAG 1.0 chiede che “quando esiste un linguaggio di marcatura
adatto, per veicolare informazione usare un marcatore piuttosto che le immagini.”.
Allo stesso modo la legge Stanca, al requisito 1 del D.M. richiede di “Realizzare le pagine e gli
oggetti al loro interno utilizzando tecnologie definite da grammatiche formali pubblicate [..].”.
Questo per il fatto che il testo può essere ingrandito e letto dagli screen-reader, in oltre i
motori di ricerca possono usare le informazioni testuali quando queste sono presenti in luogo
delle immagini.
I campi d’interesse di queste rappresentazioni alternative sono molteplici, matematica,
scienze, grafici, diagrammi, geografia, mappe.
In realtà non è sempre agevole ottenere rappresentazioni alternative di tutte queste entità e
molti problemi non sono stati risolti.
Un interessante articolo in materia è quello proposto da Roberto Scano come linee guida IMS
per lo sviluppo di applicazioni accessibili per la formazione 1, di cui riassumo i concetti cardine
integrandoli con le normative ufficiali del W3C.
Alla trattazione successiva vorrei premettere una breve spiegazione degli strumenti più comuni
che possono essere utilizzati per migliorare l’accessibilità:
MathML
MathML2 è un linguaggio di marcatura XML per le notazioni matematiche.
Offre due formati di rappresentazione di una espressione:
Elementi di presentazione;
Elementi di semantica e contenuti.
Gli autori possono scrivere le espressioni con un qualunque applicativo conforme ai requisiti e
possono accedere e visualizzare i risultati con i numerosi programmi compatibili con MathML.
1
2
[http://www.robertoscano.info/files/salt/guidelines/sec11.html]
[http://www.w3.org/Math/]
- 153 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Ad esempio il browser editor del W3C, Amaya, è in grado di trattare questi contenuti ed
esistono svariate applicazioni matematiche in grado di importare codice in MathML.
Segue un esempio di un’inclusione di codice MathML in (X)HTML, la pagina Web dovrebbe
essere scritta utilizzando (X)HTML con il marcatore MATH, come nell'esempio seguente che
esprime l’integrale da 0 a t della funzione 1/x in dx:
<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>...</head>
<body>
<h1>Esempio</h1>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<msubsup>
<mo>&int;</mo>
<mn>0</mn>
<mi>t</mi>
</msubsup>
<mfrac>
<mrow>
<mo>d</mo>
<mi>x</mi>
</mrow>
<mi>x</mi>
</mfrac>
</mrow>
</math>
</body>
</html>
Il codice MathML dovrebbe essere incluso all’interno dell’apposito marcatore MATH, e non
dovrebbe stare, per quanto comunque consentito dalla sintassi, in un tag <OBJECT> o in un file
separato richiamato da un tag <EMBED>.
Tex, LaTeX
TeX è un sistema di scrittura utilizzato per formattare espressioni matematiche complesse e
LaTeX è un pacchetto di macro di linguaggio di marcatura generico per il programma TeX.
TeX viene comunemente impiegato per creare elementi tecnico scientifici che sono convertiti in
(X)HTML per pubblicazioni sul Web.
Tuttavia i convertitori tendono a produrre immagini ed a usare elementi deprecati del
linguaggio con l’uso di tabelle. Di conseguenza si dovrebbe:
Lasciare il documento originale in TeX o LaTeX disponibile in rete;
Controllare che il documento ottenuto dalla conversione sia accessibile.
- 154 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
SVG
SVG1, Scalable Vector Graphics, è un linguaggio per descrivere grafici a due dimensioni ed
applicazioni grafiche in XML. E’ una raccomandazione del W3C.
Utilizzando questo strumento gli oggetti sono scalabili, ossia possono essere ingranditi ed
eventualmente rimpiccioliti senza che appaiano deterioramenti nella risoluzione. In oltre al suo
interno vi sono numerose informazioni sugli elementi del disegno che possono fornire
informazioni anche sulle singole parti.
Segue un esempio di come includere un componente SVG in (X)HTML all’interno dell’elemento
OBJECT:
<?xml version="1.0"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>SVG Included with object tag in an XHTML File</title>
</head>
<body>
<h1>An SVG rectangle (via object tag)</h1>
<object type="image/svg+xml" data="web_square.svg">
Browser does not support SVG files!
</object>
</body>
</html>
Matematica
Probabilmente l’esigenza principale che ha permesso la crescita e lo sviluppo di notevoli
interessi in questa branca è stata proprio la necessità di rappresentare in maniera
maggiormente accessibile le formule matematiche.
La matematica sul Web può essere usata per trasmettere dei concetti e per insegnare la
materia, le espressioni matematiche sono un veicolo informativo di notevole portata per
trasmettere conoscenza in questa disciplina.
Le difficoltà che s’incontrano nel trasmettere tali contenuti consistono nel classico problema di
inaccessibilità della grafica, oppure nella scorretta presentazione dell’oggetto ad opera dei vari
programmi utente.
In particolare:
1
[http://www.w3.org/Graphics/SVG/]
- 155 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Gli utenti che non possono accedere alla visualizzazione grafica non possono avere
accesso alle informazioni;
Gli utenti con disabilità visive possono avere dei problemi di gradimento delle immagini
che possono risultare eccessivamente sgranate se non descritte con un sistema SVG
(Scalable Vector Graphics)
Gli utenti con disabilità visive possono avere dei problemi con contrasti di colori
sbagliati;
Gli utenti che intendono importare le formule in qualche applicazione standard non sono
in grado di farlo se la formula non è presentata in maniera accessibile;
Utenti con disabilità visive o cognitive possono incontrare difficoltà se l’espressione non
è strutturata in modo da poter essere suddivisa in elementi più semplici e più
facilmente visualizzabili.
L’accessibilità delle formule matematiche può essere notevolmente migliorata con l’impiego di
tecniche SVG e MathML.
Di conseguenza alle difficoltà rilevate in precedenza, gli accorgimenti per ottenere delle
notazioni matematiche maggiormente accessibili possono essere:
Includere, quando possibile, una versione testuale dell’equazione utilizzando l’attributo
ALT
o l’attributo LONGDESC. Questi testi possono fornire una lettura alternativa in taluni
casi anche altrettanto efficace delle espressioni;
Fornire, quando possibile, le espressioni matematiche anche in testo standard nella
pagina (X)HTML, includendo delle formattazioni speciali nei CSS, come ad esempio per
le potenze. In questo caso però il corretto significato delle espressioni lo si può ottenere
solamente dalla formattazione ed occorre essere certi che l’utente ne possa usufruire,
magari mediante modalità differenti. Potrebbero in tal caso risultare utili i fogli di stile
AURAL
per modificare il timbro vocale della pronuncia;
In caso di rappresentazione grafica, utilizzare il linguaggio XML adatto, come SVG, che
può permettere di ingrandire un elemento di grafica per gli ipovedenti senza sgranare la
risoluzione;
Spezzare le scritture matematiche complesse in parti da rendere trattabili in maniera
separata. La divisione in blocchi è disponibile sia con i fogli di stile che da SVG. In tal
caso potrebbe anche essere possibile selezionare le parti da visualizzare o da
pronunciare con un sintetizzatore vocale;
Utilizzare dei generatori di matematica che producano Tex (o LaTeX) o meglio ancora
MathML.
A proposito degli ausili per le notazioni matematiche si segnalano due strumenti per la
presentazione delle notazioni informatiche in formato audio:
- 156 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
AsTeR1 (Audio System for Technical Readings);
EzMath2, sviluppato da Dave Raggett.
Dal canto loro, le WCAG propongono nel documento3 di tecniche di accessibilità per HTML
alcuni punti guida che ricalcano parzialmente quanto appena suggerito:
Assicurarsi che gli utenti conoscano i simboli ed in significati delle formule ponendo
delle brevi descrizioni informative;
Per le equazioni semplici si possono usare i normali caratteri;
Per le equazioni più complesse si possono impiegare notazioni in MathML o TeX;
Fornire una descrizione testuale delle equazioni.
Grafici e diagrammi
I problemi nell’accesso a questi strumenti possono essere causati da:
Disabilità visive: impediscono di percepirne il contenuto;
Disabilità cognitive: impediscono di comprenderne il contenuto.
Per questo motivo tali oggetti non possono essere presentati a se stante.
In genere si possono affiancare ausili che utilizzano altri canali sensoriali:
Udito, con descrizioni audio che presentino gli elementi grafici della risorsa;
Tatto, attraverso apposite barre braille, schermi sensibili al tatto, copie stampate in
carta termica a rilievo o con stampanti tattili. In questo caso lo sforzo cognitivo del
disabile può essere maggiore, ma, unito ad una descrizione audio dell’oggetto può dare
risultati soddisfacenti;
Rappresentazioni testuali, impiegando tecniche simili a quelle per le equazioni, come ad
esempio l’attributo ALT o LONGDESC. Alcuni strumenti permettono addirittura una
generazione automatica dei contenuti testuali elaborandoli in base ai dati. In questo
senso diagrammi con dati statici possono essere rappresentati testualmente con una
relativa facilità. Un programma utile a questi fini è Popchart Xpress 4.
1
2
3
4
[http://www.cs.cornell.edu/Info/People/raman/aster/aster-toplevel.html]
[http://www.w3.org/People/Raggett/EzMath/]
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-markup]
[http://www.corda.com/]
- 157 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Chimica
Come per la matematica il problema è quello di generare codice di marcatura accessibile che
possa essere utilizzato per codificare e rendere espressioni scientifiche. In oltre, in questo
caso, alcune branche della scienza necessitano di modelli grafici bidimensionali o
tridimensionali da allegare al testo.
Le barriere di inaccessibilità consistono nella rappresentazione puramente grafica di queste
informazioni che non possono essere rese con strumenti alternativi.
Un equivalente di MathML per la chimica è ChemML 1, integrabile in (X)HTML. Ne esiste anche
una versione denominata CML.
Dovendo presentare un documento completo si può ricorrere ad una collaborazione integrata
dei vari strumenti: ChemML può integrarsi con XHTML per testi ed immagini, SVG per
diagrammi, grafici, schemi di reazioni chimiche e MathML per le equazioni correlate.
Geografia
La differenziazione di colore e di schemi possono rendere inaccessibili le cartine geografiche e
le mappe.
La maggior parte delle mappe hanno delle informazioni testuali alla base e possono essere rese
producendole su una stampante tattile. Quello che viene reso dai colori sul video può essere
parzialmente reso da un cambiamento di rilievo in una mappa tattile.
In generale le rappresentazioni grafiche dovrebbero tutte essere prodotte in SVG, il linguaggio
grafico raccomandato dal W3C. Esiste la possibilità di produrre anche delle relazioni tra le parti
di un oggetto che possano poi essere rese contestualmente all’oggetto stesso utilizzando un
sistema di integrazione multimediale come ad esempio SMIL.
Una cura particolare può essere posta anche nella scelta dei colori con un adeguato contrasto
per persone con parziale cecità ai colori.
A questo proposito si rimanda alla parte riguardante l’uso del colore.
Suggerimenti molto utili ed approfonditi su questo argomento possono essere rintracciati nel
lavoro di Cynthia A. Brewer2, una professoressa associata dell’Università della Pennsylvania
che da molto tempo si occupa di questi argomenti.
1
2
[http://www.xml-cml.org/information/position.html]
[http://www.personal.psu.edu/cab38/]
- 158 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Mappe immagine
Come definito dallo stesso W3C, una mappa immagine è una mappa grafica che possiede delle
regioni attive. Quando l’utente seleziona una di queste regioni scatta qualche azione, come ad
esempio può essere richiamato un collegamento ipertestuale, una informazione può essere
inviata al server eccetera.
Le mappe immagine hanno spesso una funzione non sostituibile come nel caso più evidente
delle cartine geografiche.
Come requisiti essenziali per rendere accessibile una mappa immagine, gli sviluppatori devono
assicurarsi che ogni azione associata con una regione visuale possa essere attivata senza un
dispositivo di puntamento specifico come ad esempio il mouse, e che l’immagine possa essere
acceduta anche tramite un testo alternativo con l’attributo ALT.
Le normative prese in esame sono in realtà più restrittive in merito alle mappe immagini, qui
ricordiamo innanzi tutto le WCAG 1.0 a cui poi le altre normative si riferiscono:
Linea guida 1.1: “Fornire un testo equivalente per ogni elemento non di testo, incluse le
mappe immagini.”;
Linea guida 1.2: “Fornire dei collegamenti testuali ridondanti per ogni regione attiva di
una mappa immagine lato server.”;
Linea guida 1.5: “Fino a quando i programmi utente non metteranno a disposizione
equivalenti testuali per i collegamenti ipertestuali delle mappe lato client, fornire
collegamenti testuali ridondanti per ogni regione attiva delle mappe immagini lato
client.”;
Linea guida 9.1. “Impiegare delle mappe immagini lato client piuttosto che delle mappe
immagini lato server, ad eccezione di quando le regioni della mappa non possano
essere definite con una forma geometrica disponibile.”;
Linea guida 9.5: “Fornire delle scorciatoie per i collegamenti ipertestuali più importanti,
inclusi quelli delle mappe immagini lato client.”.
La legge Stanca, nel decreto ministeriale del 8 Luglio 2005 ricorda le regole dell’impiego
accessibile delle mappe lato client nel requisito 7 e lato server nel requisito 8.
La Section 508 contiene definizioni analoghe nel paragrafo (e) e nel paragrafo (f) con criteri
simili alle precedenti normative richiamate delle WCAG 1.0.
Vedremo ora più in dettaglio qualche questione derivate da queste richieste di accessibilità.
Mappe lato client
In alcune circostanze le mappe immagine svolgono delle funzioni che non sono rimpiazzabili da
altri oggetti. Un tipico caso è quello delle cartine geografiche che stanno prendendo sempre più
piede anche per i moderni sistemi di navigazione assistita con numerosi riscontri anche sui siti
Web.
- 159 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Tuttavia per molte funzionalità, esse possono essere utilmente integrate con degli strumenti
alternativi maggiormente accessibili, come ad esempio un indice alfabetico o una casella di
riepilogo a discesa. Per quanto possibile non bisognerebbe tralasciare di inserire anche questi
equivalenti testuali per gli utente ipovedenti o non vedenti.
Bisogna tener conto del fatto che non sempre le mappe immagini sono strettamente
necessarie, anzi, a volte sono impiegate puramente per scopi d’effetto.
Le mappe immagini lato client sono supportate da tutti i browser e sono più adatte di quanto
non lo fossero le mappe immagini lato server che le hanno storicamente precedute.
Possono essere rese più facilmente accessibili dotandole di un apposito attributo ALT per ogni
loro area, ne più ne meno come si farebbe per ogni singola immagine in cui sono graficamente
suddivise. In effetti, anche l’elemento AREA che compone l’elemento MAP può e deve
obbligatoriamente1 contenere l’attributo ALT, come si può notare nel breve esempio che segue:
<img alt="Italia" src="italia.gif" title="Cartografia dell’Italia"
usemap="itamap" />
<map id="itamap">
<area shape="rect" alt="Sardegna" coords="114,238,160,31" href="1.htm" />
<area shape="poly" alt="Sicilia" coords="304,330,292,354" href="2.htm" />
<area shape="poly" alt="Calabria" coords="304,283,319,12" href="3.htm" />
</map>
<p>
[<a href="1.htm">Sardegna</a>]
[<a href="2.htm">Sicilia</a>]
[<a href="3.htm">Calabria</a>]
</p>
Alla mappa sono stati aggiunti, in quest’esempio, degli espliciti collegamenti ipertestuali
ridondanti che rimandano agli stessi documenti che verrebbero acceduti tramite il
collegamento interno dalla mappa stessa.
Il motivo è spiegato nel punto di controllo 1.5 delle WCAG 1.0. In quel contesto si raccomanda
di fornire dei collegamenti di testo ridondanti per ogni zona attiva anche per le mappe
immagine lato client, almeno fino a quando i programmi utente non renderanno disponibili i
collegamenti testuali interni alla mappa. In effetti, questa richiesta garantisce che i
collegamenti vengano ugualmente resi disponibili anche se la visualizzazione dell’immagine
fosse disattivata o impossibile.
1
[http://www.w3.org/TR/html401/struct/objects.html#edef-AREA]
- 160 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Menu di navigazione
Purtroppo le mappe vengono a volte impiegate anche per finalità che non sarebbero del tutto
consone ai loro scopi, come ad esempio dei veri e propri menù di navigazione, con la
definizione delle aree sensibili in relazione alla sezione grafica delle relative voci.
Per quanto non sia pratica consigliata, tuttavia è possibile ottenere una sufficiente accessibilità
anche di questi elementi dotandoli degli opportuni attributi ALT che permettano alle tecnologie
assistive di accedervi.
Si ricorda che, come strumento di navigazione, è egualmente efficace dal punto di vista grafico
una riga di semplici immagini anche loro corredate dei necessari attributi ALT, soprattutto per la
possibilità di adattarsi ai cambiamenti di dimensione della finestra.
La soluzione migliore dal punto di vista dell’accessibilità resta quindi quella di evitare i menù di
grafica e gestire le navigazioni tramite liste o testo semplice o con i futuri elementi appositi
(navigation list) che saranno previsti nel XHTML 2.0.
Un’interessante soluzione per rendere graficamente una lista di collegamenti viene presentata
sul sito di ConStile1 e consiste nell’emulare le mappe immagini con dei CSS.
Senza i fogli di stile la mappa appare come una normale lista, con i fogli di stile è possibile
posizionare opportunamente le aree rettangolari sopra i collegamenti.
I vantaggi di questa tecnica sono diversi: la lista di collegamenti è altamente accessibile, il
codice è leggero, facilmente personalizzabile e del tutto compatibile con numerosi browser.
La tecnica è più generica della semplice gestione dei menù ed è valida anche per realizzare
delle mappe immagini di qualunque area purché scomponibile in zone puramente rettangolari.
Mappe lato server
Delle mappe immagine lato server se ne occupano specificatamente le WCAG 1.0 al punto di
controllo 1.2, la legge Stanca al requisito 8, la Section 508 al paragrafo (e), nella maggior
parte dei casi sconsigliandone l’uso.
In genere si richiede che vengano forniti dei collegamenti testuali ridondati per ogni regione
attiva della mappa.
Nel caso delle mappe lato server la maggior parte del codice si trova dalla parte del server
Web. Il browser rileva in locale posizione del click del mouse su di un’area sensibile della
mappa ed invia le coordinate relative al server che provvede a processare le informazioni
ricevute e a reagire di conseguenza.
1
[http://www.constile.org/tips/emulare_le_immagini_mappate_con_i_css/]
- 161 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Tutta questa gestione rende particolarmente complicata la resa dell’accessibilità di questi
strumenti in quanto, dalla parte del browser, non vi sono altre informazioni che un puro e
semplice oggetto grafico.
Per creare una mappa immagine lato server che rispetti i requisiti di accessibilità occorre:
Avere a disposizione una immagine in un formato supportato (.jpg. .png. .gif);
Inserire gli elementi del linguaggio corretti per includerla nel codice (X)HTML in modo
da renderlo valido;
Definire un elemento mappa immagine che delimiti le zone sensibili dell’immagine;
Offrire tutti i collegamenti testuali ridondanti esterni alla mappa che consentano di
accedere alle stesse funzionalità permesse dalle regioni attive della mappa stessa.
Si ricorda che è necessario fornire un testo in alternativa alla mappa perché gli utenti che non
sono dotati di mouse o che non possono impiegarlo non sono in grado accedere direttamente
con un click sulla mappa. Costoro se ne possono servire invece attraverso dei collegamenti di
testo che consentano di inviare le medesime informazioni del click diretto sull’immagine.
Annotazioni conclusive
Un’importante segnalazione da far notare sulle mappe è che, come messo in evidenza nella
parte di spiegazione dei linguaggi, XHTML 1.1 ha eliminato del tutto l’attributo NAME per
rimpiazzarlo con ID, semanticamente più corretto. Questo attributo era presente anche nella
sintassi delle mappe ed occorre prestare attenzione nel momento in cui si associa una mappa
alla sua immagine.
In oltre il W3C sta incominciando a suggerire1 l’impiego dell’elemento <OBJECT> in luogo di
<IMG>, inserendo l’elenco alternativo dei collegamenti ipertestuali accessibili all’interno dello
stesso OBJECT in modo che siano direttamente visualizzabili in caso di mancata resa grafica.
Purtroppo l’elemento OBJECT non è ancora supportato al meglio dai browser, soprattutto da
Internet Exlporer e a volte non viene visualizzato se non è dotato dell’attributo CLASSID e se
non è corredato delle relative dimensioni di altezza e larghezza.
Moduli
Un modulo (X)HTML (form in linguaggio tecnico) è una sezione di un documento interattiva che
contiene del testo ordinario e degli elementi speciali denominati controlli come ad esempio
caselle di testo, caselle di spunta, pulsanti di opzione, pulsanti, menu, oltre che delle etichette
1
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#image-maps]
- 162 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
associabili ai controlli stessi. Gli utenti generalmente compilano un modulo introducendo del
testo, selezionando elementi di menu, segnando delle caselle di spunta e successivamente
inoltrano il modulo ad un programma per il trattamento dei dati, come ad esempio un server
Web.
Il trattamento corretto dell’accessibilità per questi elementi è fondamentale dal momento che
sono riservati all’interazione con l’utente. Se un utilizzatore non fosse in grado, per via della
scarsa accessibilità del modulo, di interagire con esso, non sarebbe possibile per lui usufruire
dei servizi interattivi messi a disposizione del sito.
Fino a poco tempo fa era famoso il caso delle Ferrovie dello Stato, il loro sito1 messo a
disposizione per consultare gli orari ferroviari non era accessibile ed il servizio pubblico statale
è rimasto sordo alle richieste delle associazioni dei disabili per anni.
La situazione è notevolmente migliorata, ma la pagina risulta a tutt’oggi non del tutto
conforme alle specifiche, nonostante la dichiarazione di tripla A esposta 2.
Vista la primaria importanza dei moduli, tutte le normative si sono giustamente preoccupate di
inserire delle linee guida che ne regolamentassero l’accessibilità:
WCAG 1.0, linea guida 10.2: “Garantire che l'etichetta sia posizionata correttamente
per tutti i controlli dei moduli che hanno etichette associate implicitamente.”, e 12.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.”;
Section 508, paragrafo (n): “I moduli […] dovranno permettere l'accesso ad individui
che utilizzano tecnologie di supporto alle informazioni.”;
D.M. 8 Luglio 2005, Requisito 14: “Nei moduli (form), associare in maniera esplicita le
etichette ai rispettivi controlli, posizionandole in modo che sia agevolata la compilazione
dei campi da parte di chi utilizza le tecnologie assistive.”;
WCAG 2.0, annunciato in uno specifico documento dal titolo provvisorio: Application
note, per ora sono disponibili nel documento di tecniche 3 per HTML al capitolo 15.
Rendere accessibile un modulo non richiede degli sforzi particolari e può essere fatto con una
certa facilità seguendo opportuni accorgimenti, alcuni anche piuttosto semplici:
1
2
3
Associare delle etichette ai campi;
Posizionare correttamente le etichette;
[www.trenitalia.it]
[http://www.trenitalia.com/tcom/html/accessibilita_it.shtml]
[http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20040903/#forms]
- 163 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Raggruppare strutturalmente i controlli omogenei;
Raggruppare le informazioni;
Ottimizzare la navigazione da tastiera;
Evitare i caratteri segnaposto nei controlli;
Evidenziare i campi dei moduli;
Ingrandire i controlli.
Segue una breve spiegazione di quest’elenco di accorgimenti.
Associare delle etichette ai campi
Un primo passo consiste in un semplice accorgimento: nei moduli associare in maniera
esplicita le etichette ai rispettivi controlli.
In genere, in un modulo, tutti i campi da compilare possiedono un testo esplicativo
d’accompagnamento contenente informazioni che chiarificano la tipologia dei dati richiesti per
compilarlo.
Questo testo non può essere un normale testo della pagina, ma deve essere reso attraverso lo
specifico elemento LABEL, una etichetta che viene in genere premessa al campo da compilare.
Un’etichetta che sia appositamente associata ad un campo permette diversi vantaggi tra cui il
fatto che la selezione via mouse o via tastiera dell’etichetta stessa sposta automaticamente il
focus sul campo da compilare. In oltre molti screen-reader sono in grado di leggere meglio
l’intestazione di un campo se questo ha un’etichetta associata.
Per rendere più accessibile il modulo ci sono due sistemi per associare una LABEL ad un campo
da compilare.
È possibile utilizzare gli elementi <LABEL> in modo:
Implicito;
Esplicito.
In modo implicito l’elemento da etichettare è contenuto integralmente nell’elemento < LABEL>
senza che vi siano altri richiami espliciti tra i due costrutti.
<label> Nome Utente: <input type="text" size="20" value="Nominativo..."
name="utente" id="utente" /> </label>
In modo esplicito i due elementi non sono necessariamente annidati, ma il collegamento è
definito tramite un attributo ID del controllo a cui fa richiamo il corrispondente attributo FOR
dell’elemento LABEL.
<label for="utente">Nome Utente:</label>
<input type="text" size="20" value="Nominativo..." name="utente" id="utente" />
<label for="utente"> Nome Utente:
- 164 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
<input type="text" size="20" value="Nominativo..." name="utente" id="utente" />
</label>
In un collegamento esplicito, giacché è l'attributo FOR a permettere di associare un elemento
<LABEL> ad un determinato controllo interno al modulo, va posta attenzione al fatto che il
valore dell'attributo FOR dell'elemento <LABEL> debba corrispondere al valore dell'attributo ID
del controllo, il quale deve rigorosamente essere univoco all’interno di tutta la pagina.
Usando questa tecnica la tecnologia assistiva riesce ad agganciare l’etichetta anche se
posizionata, ad esempio, in una posizione molto lontana dal controllo, cosa per altro non
consigliata a meno che non si voglia ottenere un effetto di rimando a distanza.
Vanno ricordate alcune cose a proposito del sistema di associazione FOR - ID:
In browser obsoleti l'attributo FOR non è correttamente supportato e di conseguenza
non consente la funzionalità della associazione esplicita;
L’attributo ID e l’attributo NAME del controllo possono avere lo stesso identificativo, in
ogni caso è necessario includere entrambi dal momento che ID associa l’etichetta e NAME
serve invece per definire il nome del controllo da inviare come campo della FORM.
Gli speciali bottoni di Reset ed Invio (<INPUT TYPE="RESET"/> or <INPUT TYPE="SUBMIT"/>),
i bottoni di tipo immagine (<INPUT TYPE="IMG"/>), e i bottoni di script
(<BUTTON></BUTTON>) non hanno bisogno dell’etichettatura esplicita in quanto sono già
implicitamente associati.
Nei browser di ultima generazione e in parecchie tecnologie assistive tale affiliazione tra
<LABEL> ed elemento interno al modulo è garantita proprio grazie alla presenza
dell'attributo FOR. In caso di assenza i due elementi restano scollegati.
Anche a causa di quest’ultima osservazione, il documento di tecniche1 per l’HTML delle WCAG
2.0 raccomanda l’associazione esplicita e considera deprecata quella implicita.
Allo stesso modo la linea guida 12.4 raccomanda chiaramente l’associazione esplicita.
Un ultimo appunto riguarda la richiesta, presente sempre nello stesso documento di tecniche
citato, di provvedere ad una sorta di pseudo-etichettatura anche per quegli elementi del
modulo che non hanno un’etichetta esplicitamente associata.
Questo può essere fatto semplicemente aggiungendo un attributo TITLE all’interno dell’elemento
non etichettato2.
1
[http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20040903/#forms]
“Form controls that cannot have an individual label associated with the label element can be labeled with
the TITLE attribute.”
2
- 165 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Posizionare correttamente le etichette
Per quanto una etichettatura esplicita permette di associare il controllo con la sua etichetta
anche se non sono posizionati nelle immediate vicinanze, le regole di accessibilità esposte nel
documento di tecniche richiedono che la posizione della etichetta segua un criterio di corretto
posizionamento.
Questo significa che l’etichetta debba precedere immediatamente il controllo a cui si riferisce.
Nel caso ci fossero più controlli o etichette sulla stessa linea l’etichetta deve anch’essa essere
posizionata sulla stessa linea del controllo. In caso contrario è ammesso il posizionamento sulla
linea precedente, fermo restando che la LABEL rimanga comunque l’oggetto immediatamente
precedente al controllo da etichettare.
Raggruppare strutturalmente i controlli omogenei
Occorre utilizzare gli elementi FIELDSET e LEGEND per raggruppare strutturalmente insieme dei
controlli che siano semanticamente omogenei.
Poiché quasi tutti i moduli possiedono una propria forma di organizzazione e di impaginazione,
è opportuno che queste strutturazioni visuali siano disponibili anche ad utenti che non
navigano con un browser grafico, una tale organizzazione strutturale aiuta sicuramente
l'interpretazione della pagina da parte di browser testuali e tecnologie assistive.
Il documento di specifiche tecniche consiglia di usare l'elemento FIELDSET come contenitore di
gruppi omogenei di campi e l'elemento LEGEND per dare un nome ai gruppi.
Questa tecnica è consigliata in special modo per i pulsanti di opzione e per le caselle di spunta,
controlli che forniscono scelte multiple raggruppate sotto un solo nome di campo. In questo
modo viene esplicitata la stretta relazione fra gli elementi separandoli da altri gruppi omogenei
fra loro.
Segue un breve esempio:
<form action="..." method="post">
<fieldset>
<legend>Dati anagrafici obbligatori</legend>
... elenco di campi necessari per l’invio ...
</fieldset>
<fieldset>
<legend>dati facoltativi</legend>
... elenco di campi a compilazione facoltativa ...
</fieldset>
<fieldset>
<legend>informazioni sulla carta di credito</legend>
... campi in cui inserire i dati sulla carta di credito ...
</fieldset>
</form>
Molti browser provvedono autonomamente fornire un’impaginazione grafica al FIELDSET
circondando gli elementi contenuti con un riquadro e aggiungendo automaticamente la LEGEND
indicata come titolo del riquadro stesso.
- 166 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Raggruppare le informazioni
I progettisti dovrebbero raggruppare insieme non solamente in controlli omogenei ma anche le
informazioni messe a disposizione quando questo sia appropriato.
Ad esempio una lunga lista di scelte possibili di un menu di cui potrebbe essere difficile avere
lo sguardo di’insieme, dovrebbero essere organizzate in una gerarchia di voci organizzate ad
albero.
In tal caso si dovrebbe usare l’elemento OPTGROUP per raggruppare le opzioni all’interno
dell’elemento SELECT e specificare una etichetta per il gruppo di opzioni con l’apposito attributo
LABEL
dell’elemento OPTGROUP.
Un esempio di questa politica potrebbe essere quello di raggruppare le province all’interno di
una regione per una ipotetica lista estesa di città italiane capoluogo di provincia.
Esempi concreti di queste tecniche possono essere reperiti sui numerosi manuali in rete di
tecniche per l’elemento OPTGROUP.
Ottimizzare la navigazione da tastiera
Il posizionamento diretto nel punto e nel campo corretto di un modulo può essere spesso un
ottimo ausilio per in navigatori che non hanno a disposizione un browser grafico.
Un buon sistema per fare questo è quello di fornire degli strumenti da tastiera che possano
quindi essere acceduti anche da tecnologie assistive.
I metodi per ottenere questo risultato sono essenzialmente:
Impiego degli ACCESSKEY;
Definizione delle posizioni di tabulazione con TABINDEX.
Per entrambe queste tecniche si rimanda al capitolo sulla navigazione di questo lavoro per
informazioni più dettagliate, qui comunque vale la pena fare qualche accenno a come questi
metodi possono essere di ausilio nei moduli.
L’attributo TABINDEX viene impiegato per definire l’ordine di tabulazione di una pagina, cioè la
sequenza ordinata di elementi che riceveranno il focus quando viene premuta in sequenza una
serie di tasti di tabulazione. Questi elementi non devono essere necessariamente dei
collegamenti ipertestuali, possono essere, nel caso in esame, anche dei controlli del modulo.
In condizioni normali gli elementi vengono visitati dalle successive pressioni del tasto di
tabulazione secondo l’ordine di presentazione nel codice (X)HTML, questo ordine può essere
alterato per evidenziare alcune posizioni privilegiate, come ad esempio la sequenza corretta dei
campi da compilare di un modulo.
La creazione di un ordine logico è un punto di controllo delle WCAG 1.0, il 9.4, e seppure di
priorità 3, ha una sua raccomandazione specifica ad evidenziarne l’utilità.
Un’altra tecnica che si può impiegare è quella di organizzare gli ACCESSKEY, cioè dei punti di
posizionamento privilegiati della pagina che possono essere raggiunti direttamente con una
- 167 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
particolare combinazione di tasti. Il vantaggio di questo sistema è che non si è costretti a
scorrere una lunga lista di elementi prima di arrivare a quelli di interesse, e questo, per le
tecnologie assistive e soprattutto per gli screen-reader può essere di una utilità rimarchevole.
Anche in questo caso rimando alla sezione citata per i dettagli dell’implementazione e gli
eventuali problemi che possono sorgere con i sistemi operativi.
Evitare i caratteri segnaposto nei controlli
Un precedente consiglio delle WCAG 1.0 richiedeva, al punto di controllo 10.4 con priorità 3 di
inserire facoltativamente dei caratteri segnaposto nei campi di controllo predisposti
all’immissione del testo. Questo per favorire le tecnologie assistive nella gestione dei controlli
vuoti.
E’ una raccomandazione del 1999 ed attualmente è del tutto superata. I più comuni screenreader in uso, come ad esempio JAWS, sono perfettamente in grado di gestire i campi in
questione, anche se vuoti.
Un campo pre-compilato, allo stato attuale della tecnologia, non è altro che d’intralcio alla
usabilità dei componenti, dal momento che molti utenti dimenticano di cancellarlo o lo
cancellano solo parzialmente finendo per inviare con il modulo dei dati scorretti.
Per questi motivi molti sviluppatori e molti utenti sconsigliano l’impiego di questa tecnica per
quanto suggerita dalle WCAG 1.0. Per altro la stessa normativa1 la riporta come norma
transitoria, finche i programmi utente non siano in grado di gestire la situazione
correttamente.
La questione comunque è del tutto definita con le prossime WCAG 2.0 che, allo stato attuale
dei lavori, hanno espressamente deprecato2 l’impiego di caratteri segnaposto.
Evidenziare i campi dei moduli
Si tratta di un utile accorgimento che può venire incontro soprattutto agli ipovedenti.
A volte i campi del modulo hanno una rilevanza piuttosto scarsa all’interno della pagina ed un
ipovedente può avere delle difficoltà a localizzarli con immediatezza.
1
“Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes
and text areas. [Priority 3]”
2
“This is a negative technique, an example of something you shouldn't do. This technique corresponds to a
WCAG 1.0 checkpoint. There is a proposal for an erratum that states the until user agents clause is met and
this checkpoint (and thus technique) are no longer necessary” – [http://www.w3.org/WAI/GL/WCAG20/WDWCAG20-HTML-TECHS-20040903/#forms]
- 168 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Dal momento che questi campi possono recare delle informazioni fondamentali da inviare al
server, potrebbe essere di una certa utilità metterli in evidenza, o quanto meno mettere in
risalto i controlli che devono contenere le informazioni essenziali.
Per fare questo degli strumenti di impaginazione possono essere un valido ausilio alle altre
tecniche spiegate in questi paragrafi, affiancando una rilevanza strutturale e semantica con
una evidenziazione grafica.
Tra le varie tecniche possibili a discrezione del progettista si suggeriscono:
Un forte contrasto di colori tra il controllo e lo sfondo della pagina;
Un bordo rimarcato intorno ai campi di interesse.
Questi suggerimenti possono essere particolarmente significativi soprattutto per i componenti
meno evidenti dei moduli come ad esempio le caselle di spunta e i bottoni di opzione.
Ingrandire i controlli
Sempre ad ausilio degli ipovedenti può essere utile una funzionalità d’ingrandimento generale
del modulo e dei controlli quando non consentito espressamente dal browser.
Finalmente con la sua ultima versione 7 anche Microsoft Internet Explorer si è deciso ad
includere nel browser un sistema per ingrandire tutto lo schermo, non solamente il testo, ma
anche l’integrale della pagina, controlli ed immagini inclusi. Si tratta di un grosso passo in
avanti che finalmente lo allinea con le funzionalità di Opera e di altri browser.
Tuttavia ancora non tutti i browser grafici hanno implementato questa funzionalità.
Per questo alcuni autori di pagine Web hanno deciso di includere nei propri siti degli script lato
client o lato server che permettano l’ingrandimento degli elementi inclusi nella pagina.
Ovviamente non possono agire sulla resa grafica dell’immagine, però possono ottenere dei
buoni risultati permettendo all’utente di modificare lo stile dei campi, ingrandendoli o
rimpicciolendoli a piacere. Con una tale opzione è possibile modificare la dimensione dello
spazio occupato dal controllo e del suo testo all’interno.
Per un significativo esempio di applicazione per questa tecnica rimando ad un articolo1 di
Michele Diodati.
Navigazione
La possibilità data all’utente di usufruire di un corretto ausilio di navigazione è un principio
fondamentale per la realizzazione di siti Web ad elevata accessibilità1.
1
[http://www.diodati.org/scritti/2004/guida/ele_acc25.asp]
- 169 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Le raccomandazioni sulle modalità di implementazione di una corretta navigazione sconfinano
spesso tra le regole dell’accessibilità e quelle dell’usabilità e sono materia di numerose linee
guida. Per ricordarne alcune:
WCAG 1.0, linea guida 13: “Fornire chiari meccanismi di navigazione.”;
Section 508, paragrafo 1194.22 (o): “Dovrà essere messo a disposizione un metodo
che permetta agli utenti di saltare link di navigazione ripetitivi.”;
D.M. 8 Luglio 2005, requisito 19: “[…] prevedere meccanismi che consentano di evitare
la lettura ripetitiva di sequenze di collegamenti comuni a più pagine.”;
WCAG 2.0, linea guida 2.4: “Fornire funzionalità che aiutino l’utente a trovare i
contenuti, ad orientarsi all’interno dei contenuti e a navigarli.”.
In questa sezione esamineremo alcune tecniche che si possono vantaggiosamente impiegare
per la realizzazione di questo principio:
Marcatori di fine lista;
Breadcrumbs trails;
Tabindex;
Skip navigation;
Accesskey.
Marcatori di fine lista
Al punto di controllo 3.6 delle WCAG 1.0 si richiede di marcare le liste ed elencare le voci della
lista in maniera appropriata. Al punto 13.2 si richiede di fornire metadati per aggiungere alle
pagine e ai siti delle informazioni di tipo semantico.
Nel documento2 di tecniche per i CSS delle WCAG 1.0 si fa esplicito riferimento alla
realizzazione di queste due linee guida per fornire indicazioni (clues) contestuali alle liste
(X)HTML.
Queste indicazioni contestuali possono essere molto utili se le liste fossero molto annidate o
non definite in maniera corretta. In tal caso gli utenti non vedenti o coloro che non navighino
con un browser testuale potrebbero avere delle difficoltà ad orientarsi nei rami della lista,
soprattutto se non vi sono separatori tra una lista annidata e la sua lista padre.
Una tecnica che si utilizza è quella di indicare la fine di un livello di lista raggiunto posizionando
un segnaposto al termine delle voci di quello specifico ramo. Questo segnaposto viene poi reso
1
“If making images accessible is more than half the battle, accessible navigation takes care of another
disproportionate chunk” – Joe Clark: “Building Accessible Websites” – chapter 8.
2
[http://www.w3.org/TR/WCAG10-CSS-TECHS/#lists]
- 170 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
invisibile ai browser grafici che non necessitano di questa informazione tramite le opportune
istruzioni nel CSS associato. Infatti, con i fogli di stile abilitati sarà possibile nascondere un
segnaposto di fine lista che invece può essere mostrato quando i fogli di stile sono disabilitati
dando modo di percepire la fine della lista stessa.
Gli utenti che navigano in maniera visuale non necessitano di questa separazione dal momento
che sul proprio browser sarà perfettamente riconoscibile il livello di annidamento delle liste.
La tecnica viene poi ripetuta ad ogni fine ramo.
Una soluzione alternativa potrebbe essere quella dell’impiego dei CSS2 per preporre alle voci di
lista il loro grado di profondità nell’albero.
Le specifiche CSS2 consentono di premettere alle voci di una lista ordinata interna ad un'altra
lista i relativi numeri composti del tipo 1.1.1, agevolando così gli utenti nella comprensione del
grado di annidamento delle strutture.
La soluzione sarebbe buona se venisse supportata dalla stragrande maggioranza dei browser,
cosa che attualmente è ben lontana dall’essere raggiunta. Questa pratica, infatti, non è
possibile con i CSS1, ed in tal caso si deve ricorrere al sistema delle indicazioni contestuali.
Lo stesso documento del W3C citato, richiede l’impiego delle indicazioni contestuali fino a che
le specifiche dei fogli di stile di livello 2 non verranno ampiamente supportati dai programmi
utente o fino a che gli stessi programmi utente non siano in grado di fornire una visione della
lista in modo soddisfacente.
Ad ogni modo la tecnica con i segnaposto nascosti è piuttosto semplice, è sufficiente
aggiungere un elemento nell’ultima voce della lista e dargli l’attributo nascosto nei fogli di stile:
<span class="finelista">(Fine dell'elenco)</span>
Un elemento di questo tipo sarà invisibile con un opportuna regola dei CSS:
.finelista { display: none; }
Le indicazioni contestuali saranno invece mostrate con il foglio di stile disabilitato.
L’esempio illustra due liste rese ben distinte tra loro con questo sistema:
<ul>
<li>linguaggi HTML:
<ul>
<li>HTML 4.01 transitional</li>
<li>HTML 4.01 frameset</li>
<li>HTML 4.01 strict<span class="finelista">(Fine degli HTML)</span></li>
</ul>
</li>
<li>linguaggi XHTML:
<ul>
<li>XHTML 1.0 transitional</li>
<li>XHTML 1.0 frameset</li>
<li>XHTML 1.0 frameset</li>
<li>XHTML 1.1<span class="finelista">(Fine degli XHTML)</span></li>
</ul>
- 171 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
</li>
</ul>
Ad ogni modo si consiglia di evitare l’impiego di lunghi elenchi con le liste in quanto sono di
difficile usabilità.
Segnalo che le specifiche attuali di XHTML 2 prevedono un elemento NL dedicato per le liste di
navigazione che dovrebbe ovviare a molti di questi possibili problemi.
Breadcrumbs trails
La traduzione letterale in italiano di questa parola è: percorso a briciole di pane. Il nome è
strettamente derivato dalla sua funzione, si riferisce al sistema di indicare il percorso dove si
trova in quel momento un visitatore del sito.
Il sistema è esplicitamente consigliato nel documento1 di tecniche per le WCAG 2.0 come
tecnica per implementare il criterio di successo 2 2.4.7.
Nelle WCAG 1.0 non sono citate espressamente, ma molti autorevoli autori come Roberto
Scano le considerano nella trattazione della linea guida3 13.5, difatti vengono realizzate per
consentire l’orientamento dei visitatori che giungono in una pagina del sito da motori di ricerca
esterna, o che semplicemente abbiano bisogno di una guida sulla loro attuale posizione
all’interno di una struttura di informazioni.
In questo caso il percorso a briciole di pane aiuta l’utente a:
Identificare la sua posizione attuale nella gerarchia;
Visualizzare come il contenuto sia strutturato;
Navigare indietro verso le pagine precedenti.
In genere viene evidenziato un percorso a ritroso fino alla pagina iniziale del sito (home page).
Il loro utilizzo risulta particolarmente efficiente se ad ognuna delle pagine che costituiscono il
cammino a ritroso viene associato un collegamento ipertestuale.
E’ possibile decidere di omettere o no la pagina corrente, ad ogni modo, se le pagine
precedenti della gerarchia possono opportunamente associare un collegamento ipertestuale è
opportuno che la pagina corrente non lo abbia per non confondere l’utente con un
collegamento auto-referenziato.
1
2
3
[http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#G65]
“Rendere disponibili le informazioni per informare l’utente sulla sua posizione all’interno di un sito”
“Fornire barre di navigazione per evidenziare e dare accesso ai meccanismi di navigazione”
- 172 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La loro collocazione ideale è al principio della pagina, possono essere collocate anche in altre
posizioni, a patto che la loro dislocazione non cambi di pagina in pagina per non confondere i
navigatori.
Un esempio elementare di briciole di pane potrebbe essere il seguente:
<a href="index.html">Home</a> &gt; <a href="prodotti.html">Prodotti</a> &gt; <a
href="computers.html">computers</a>
In questo esempio è stato utilizzato il carattere di maggiore (rappresentato con l’identity &gt;)
per separare tra di loro le varie voci e per dare l’idea di un percorso in selezione progressiva.
Una scelta molto usata su diversi siti, come ad esempio quello attualmente pubblicato da
WebAccessibile1.
Tuttavia, come fatto notare da Roberto Scano, questo tipo di separatore potrebbe essere
sgradito dagli utenti dotati di screen-reader in quanto viene spesso letto per esteso come
parentesi chiusa uncinata.
In alternativa è possibile posizionare un elemento grafico come separatore con un attributo ALT
vuoto. Le tecniche del WCAG 2.0 suggeriscono di impiegare separatori come:
‘>’
‘|’
‘::’
‘/’.
Tabindex
L’attributo TABINDEX si applica ai collegamenti ipertestuali e ai controlli dei moduli, specifica
l’ordine con cui l’elemento verrà raggiunto durante le pressioni successive del tasto di
tabulazione all’interno della pagina (X)HTML corrente.
Questo valore deve essere un numero intero compreso tra 0 e 32767. Il numero definisce
l'ordine in cui gli elementi riceveranno il focus quando navigati dall'utente via tastiera.
I seguenti elementi supportano l'attributo TABINDEX: A, AREA, BUTTON, INPUT, OBJECT, SELECT e
TEXTAREA.
Secondo le specifiche dell’(X)HTML, gli elementi che possono ricevere il focus dovrebbero
essere raggiunti dai programmi utente in base alle seguenti regole:
1. Sono raggiunti per primi quegli elementi che supportano l'attributo TABINDEX e che gli
assegnano un valore positivo. Non è necessario che i valori siano in sequenza continua
né che partano da un valore particolare. Gli elementi che hanno identici valori di
TABINDEX
1
dovrebbero essere navigati nell'ordine in cui appaiono nel flusso di caratteri.
[www.webaccessibile.org]
- 173 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
2. Sono raggiunti successivamente quegli elementi che non supportano l'attributo TABINDEX
o che lo supportano e gli assegnano un valore 0 (zero). Tali elementi sono navigati
nell'ordine in cui appaiono nel flusso di caratteri.
3. Gli elementi che sono disabilitati non fanno parte dell'ordine di selezione.
Invece, se non specificato altrimenti, esiste una sequenza predefinita in cui questi controlli
vengono visitati dal focus su pressioni successive del tasto di tabulazione. Questa sequenza è
l’ordine in cui gli elementi vengono presentati nella pagina (X)HTML, e questo può non essere
sempre l’effetto voluto.
Da quasi tutti gli autori viene consigliato di scegliere intervalli di tabulazione a passo di 10 per
permettere degli inserimenti successivi di altri controlli frammezzandoli a quelli già organizzati.
Per quanto siano definite le regole date in precedenza, il comportamento dei vari browser non
è omogeneo nella gestione della lista dei punti di tabulazione. Alcuni, in presenza di una lista
specifica definita dal progettista si limitano a seguire scrupolosamente quella evitando poi di
entrare in quelli che non sono stati esplicitamente elencati, altri invece li lasciano in coda e
passano agli elementi non elencati dopo aver esaurito la lista di quelli espressamente
numerati. In oltre per alcuni browser la pressione del tasto di tabulazione al termine della lista
riporta al principio della medesima, mentre per altri non ha alcun effetto.
Ad ogni modo il fatto di segnalare delle posizioni specifiche nei campi dei moduli con dei punti
di tabulazione risulta particolarmente utile per le navigazioni testuali.
Un esempio, per un modulo, è il seguente:
<input type="text" size="30" tabindex="10" id="nome" name="nome" />
<input type="text" size="30" tabindex="20" id="cognome" name="cognome" />
<input type="text" size="30" tabindex="30" id="indirizzo" name="indirizzo" />
Skip Navigation
Nel documento tecnico delle WCAG 2.0 viene espressamente citata la possibilità di aggiungere
un collegamento all’inizio di ogni pagina che vada direttamente all’area del contenuto
principale.
Lo scopo di questa tecnica è di fornire un meccanismo per saltare blocchi di materiale che sono
ripetuti, magari anche su più pagine, e che siano in qualche modo conosciuti a priori senza la
necessità di ulteriori letture ripetitive.
Per il documento di specifiche tecniche, il primo collegamento interattivo della pagina dovrebbe
essere un salto direttamente all’inizio del contenuto principale. Questa tecnica viene
comunemente chiamata skip navigation, cioè un metodo di navigazione con salti.
Il concetto è presente anche nelle WCAG 1.0 dove, al punto di controllo 13.6 si chiede di
raggruppare i collegamenti correlati e di fornire un modo per saltarli. Anche la legge Stanca lo
prevede al requisito 19 del decreto ministeriale allegato.
- 174 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L’idea di base è di fornire alle persone che usano screen-reader o la tastiera in luogo del
mouse o di un browser grafico, un metodo per spostarsi immediatamente dall’inizio della
pagina all’inizio del contenuto principale del documento.
Le WCAG 2.0 suggeriscono di impiegare questa tecnica ogni qual volta esistano cinque o più
collegamenti ipertestuali prima di arrivare al contenuto principale1.
Un’estensione di questa linea progettuale potrebbe essere quella di predisporre una sorta di
tabella di salti alle parti più essenziali del documento (X)HTML, come ad esempio il campo
ricerca, le notizie più recenti, la prima pagina di un giornale eccetera. Può essere una soluzione
accettabile a patto di non esagerare con i collegamenti, un numero eccessivo di collegamenti
ipertestuali, anche di salto, potrebbero ovviamente finire per andare contro lo scopo per cui
sono stati progettati.
Un esempio di collegamento di salto potrebbe essere il seguente, posizionato, come richiesta
del W3C, in prossimità dell’inizio della pagina e prima del contenuto principale:
<a href="#corpo">Skip Navigation</a>
<!—tutti gli altri collegamenti di menu -->
<a id="corpo"></a>
<!— testo principale -->
Purtroppo Internet Explorer ha dei problemi nella corretta gestione per i collegamenti interni
delle pagine quando tali collegamenti sono attivati da tastiera. Sebbene il posizionamento
venga correttamente spostato visivamente, tuttavia il focus può non cambiare o può ritornare
in testa alla pagina dopo aver premuto invio.
Ci sono delle soluzioni per questa imprecisione di Explorer, tra cui quella di inserire il
collegamento di destinazione all’interno di una cella di tabella o di rendere un collegamento lo
stesso collegamento di destinazione.
Alcuni progettisti preferiscono che il salto di navigazione non sia visibile a tutti gli utenti.
Anche in questo caso ci sono tecniche diverse per realizzare questo accorgimento.
Un sistema è quello di impiegare una immagine molto ridotta, praticamente invisibile ed
inserirvi un testo alternativo che realizzi il salto di navigazione. In tal caso con immagini
disabilitate e con browser non grafici il rimando sarà immediatamente visibile.
<a href="#main">
1
“If there are five or more navigation links and/or other content that comes before the main content of the
page then the skip navigation technique should probably be used. If there are twenty links and other
elements before the main content, one of these techniques definitely should be used. The link should be at
or very near the top of the page; it is a link with a local target just before the beginning of the main
content.” – [http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20040903/#linkgroups_skip]
- 175 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
<img src="spacer.gif" hspace="0" vspace="0" alt="Skip over navigation bar"
border="0"></a>
Questa è una tecnica consigliata da molti autori tra cui Joe Clark e Jim Byrne1.
Un’alternativa è quella di predisporre in collegamento ipertestuale che abbia lo stesso colore di
testo e di sfondo in modo che risulti invisibile ai browser grafici. Questa seconda ipotesi può
essere eventualmente arricchita con uno stile di colore che evidenzi un colore differente nel
caso che il mouse vi venga passato sopra o il collegamento riceva il focus tramite il tasto di
tabulazione.
(X)HTML:
<a href="#main" class="skip">Skip Navigation</a>
CSS:
a.skip {color: #FFFFFF; background-color: #FFFFFF;}
a.skip:active {color: #000000; background-color: #FFFFFF;}
a.skip:hover {color: #000000; background-color: #FFFFFF;}
Infine è anche possibile nascondere il salto di navigazione posizionandolo fuori dallo schermo,
ad esempio con un posizionamento assoluto a sinistra di -1000em. Va notato che questi
posizionamenti negativi non sono raccomandati dalle WCAG 2.0.
Occorre aggiungere che esiste un’interessante alternativa al salto di navigazione se il
contenuto principale a cui si vuole saltare è sotto la prima intestazione del documento.
In molti browser, purtroppo ancora un volta non in Internet Explorer, esiste infatti un sistema
automatico di navigazione fra le intestazioni H1 e H2, come per altro raccomandato dalla linea
guida n. 9 delle UAAG. Opera ha due tasti dedicati, ‘s’ e ‘w’.
Se fosse implementata da tutti i programmi utente, la navigazione fra le intestazioni sarebbe
probabilmente la migliore soluzione dal momento che vengono proficuamente impiegati gli
elementi strutturali di una pagina.
Le spiegazioni precedenti sono basate sulla personale traduzione di un articolo2 di Jim Thatcher
citato ufficialmente all’interno dello stesso provvisorio documento delle tecniche WCAG 2.0.
Altri ottimi testi di riferimento sono reperibili in rete, tra cui un capitolo3 del testo di di Joe
Clark ed un completo articolo4 apparso su WebAIM.
1
2
3
4
[http://www.mcu.org.uk/articles/tables.html]
[http://www.jimthatcher.com/skipnav.htm]
[http://joeclark.org/book/sashay/serialization/Chapter08.html]
[http://www.webaim.org/techniques/skipnav/]
- 176 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Accesskey
Per ACCESSKEY s’intende l’utilizzo di alcune particolari combinazioni di tasti inviabili alla pagina
Web.
Purché questa sia predisposta per gestirli, la pagina è in grado, in conseguenza, di posizionarsi
su un opportuno oggetto che sia in relazione alla combinazione di tasti inviati.
Gli ACCESSKEY possono essere associati in generale a:
Collegamenti ipertestuali;
AREA;
BUTTON;
INPUT;
LABEL;
LEGEND;
TEXTAREA.
Assegnando, ad esempio, degli ACCESSKEY alle voci di un menu di navigazione è possibile
rendere più veloce l'accesso ai menu e alle sue funzioni senza fare uso del mouse.
L'attributo ACCESSKEY viene espressamente raccomandato1 nelle WCAG 1.0 al punto di controllo
9.5 come scorciatoia da tastiera per i collegamenti importanti.
La legge Stanca invece non li menziona esplicitamente, probabilmente per le complicazioni di
cui parleremo tra poco.
XHTML 2.0, d’altro canto sta probabilmente preparando un nuovo tipo di elemento 2 ACCESS, che
potrebbe prenderne il posto, ma questa è ancora materia controversa.
Già da questa premessa s’intuisce che l'utilizzo delle combinazioni da tastiera per la
navigazione rappresenta un aspetto controverso dell'accessibilità. Gli ACCESSKEY dovrebbero
rendere più agevole la fruibilità dei contenuti Web a tutte le categorie di utenti, sia
normodotati che disabili, si pensi ad esempio agli utenti con disabilità motorie che trovano
difficoltà ad utilizzare il mouse, ma diversi sviluppatori ne contestano la reale utilità.
I punti controversi sono:
Il modo di operare varia a seconda del browser o sistema operativo che si utilizza.
Come esempio vediamo una lista parziale in alcuni browser principali:
o
Alt + [ACCESSKEY] in Internet Explorer (Windows), Firefox 1.x(Windows), Mozilla
(Windows), Netscape 6+ (Windows);
1
2
“Per esempio, in HTML, specificare scorciatoie tramite l'attributo ACCESSKEY”
[http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule]
- 177 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
o
Alt + Shift + [ACCESSKEY] in Firefox 2;
o
Shift + Esc + [ACCESSKEY] in Opera 9 (Windows o Mac);
o
Ctrl + [ACCESSKEY] in Internet Explorer 5.2 (Mac), Safari 1.2 (Mac), Firefox
(Mac), Mozilla (Mac), Netscape 6+ (Mac);
L'utilizzo delle combinazioni come valore degli attributi ACCESSKEY, ed in particolar modo
delle lettere, può entrare in contrasto e causare conflitti con i tasti predefiniti dei
programmi utente o dei sistemi operativi.
Questo poiché le combinazioni da tastiera, soprattutto per le lettere, sono già una
caratteristica standard di molti sistemi operativi, applicazioni e browser.
Ad esempio, nella maggioranza delle applicazioni Web digitando "Alt + F" si accede al
menu "File". Proprio questo tipo di conflitti è uno dei principali motivi per cui sarebbe
sconsigliato usare le lettere per ACCESSKEY. L'alternativa è quella di utilizzare i numeri
anche se tale scelta nasconde delle insidie. Ad esempio, la combinazione da tastiera con
il numero "1" è utilizzato da Home Page Reader, un browser vocale, per leggere le
intestazioni della pagina;
Per coerenza bisognerebbe generare ACCESSKEY per tutti i collegamenti più importanti di
una pagina e potrebbe essere un operazione dispendiosa.
Più accettabile, invece, sarebbe prevedere un accesso facilitato solo per il menu di
navigazione principale (home page, sezioni principali, salto di navigazione per accedere
direttamente al contenuto, e così via) e per le funzioni principali del sito (motore di
ricerca, newsletter, news, eccetera);
Gli utenti non possono conoscere a priori le variabili assegnate agli attributi ACCESSKEY.
Apprendere queste informazioni potrebbe comportare un sensibile dispendio di tempo,
con conseguente vanificazione dell'utilità degli ACCESKEY. Non esiste ancora una
convenzione standard su come rendere nota la presenza di queste scorciatoie agli utenti
vedenti che visitano il sito o la pagina.
Una convenzione, comunque non universalmente riconosciuta, è quella di riportare
prima o dopo l'etichetta, tra parentesi quadre, il valore che consente l'attivazione da
tastiera del collegamento. Un'altra possibile soluzione molto utilizzata è quella di fornire
una pagina di supporto alla navigazione in cui vengono specificate tutte le combinazioni
utilizzate per facilitare la navigazione del sito;
Probabilmente una possibile soluzione che potrebbe maggiormente spianare la strada a questo
utile strumento potrebbe essere quella di creare una standardizzazione internazionale che
riservasse un numero di tasti alla funzione di accesso rapido, comuni per tutti i siti; ad
esempio [0] per il ritorno alla home page, attualmente tra i più usati.
Una procedura di questo tipo è probabilmente di difficile od impossibile realizzazione.
- 178 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Un interessante articolo1 a proposito è stato pubblicato su LAU (Laboratorio di Accessibilità ed
Usabilità) a cura di Andrea Pigna e Fabio Regina.
In questo articolo sono citate anche alcuni significativi riferimenti bibliografici, tra cui un utile
commento di una utente non vedente2 che ribadisce l’importanza di questi strumenti.
III.10 - Web dinamico
Il termine Web dinamico viene utilizzato per identificare tutte quelle applicazioni Web che
interagiscono attivamente con l’utente. E’ costituito da un insieme di tecnologie differenti che
permettono di cambiare in modo dinamico la rappresentazione e il contenuto di un documento
aumentando l'interattività della pagina.
Per aggiungere questi contenuti dinamici al Web sono impiegati gli script, gli applet e i plug-in.
Per quanto gli effetti ottenibili con questi strumenti possano essere considerati sicuramente
rimarchevoli, va tenuto presente, al momento di includerli nel codice, che non tutte le
tecnologie assistive o gli user agent possano accedervi. In oltre, soprattutto per gli applet ed i
plug-in, occorre porre attenzione all’aspetto dell’interfaccia considerandone attentamente
l’operabilità.
A parte gli utenti disabili, l'utilizzo di uno script per permettere la fruizione di un contenuto
Web influisce negativamente su alcune categorie di utenti. Si stimano che il 14% dei browser
hanno gli script disabilitati, o per un motivo di sicurezza nella navigazione o per ignoranza
dell'utente. Se la tecnologia JavaScript svolge un ruolo importante nella fruizione dei contenuti
della pagina, queste persone non hanno accesso a parte dei contenuti esposti.
Il problema è stato particolarmente sentito soprattutto in tempi meno recenti dal momento
che, con lo sviluppo del Web, la gestione di queste funzionalità all’interno dei programmi
utente è stata sempre più integrato ed efficace.
E’ quindi normale che le normative storicamente più datate siano anche quelle che hanno
sentito il problema in maniera più forte, limitando pesantemente l’uso dei contenuti dinamici,
mentre ultimamente si sta andando verso una maggiore tolleranza.
In particolare si possono tenere conto dei seguenti riferimenti normativi:
1
2
WCAG 1.0, punti di controllo 6.3, 6.4, 8.1, 9.2, 9.3;
Section 508, paragrafi (l), (m);
Decreto Ministeriale 5 Luglio 2005, requisiti 15, 16, 17;
[http://lau.csi.it/realizzare/accessibilita/codice_html/tastiera/index.shtml]
[http://forum.diodati.org/messaggi.asp?f=1&id=319]
- 179 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Le WCAG 2.0 sono molto più permissive in fatto di applet e JavaScript, in particolare, se
queste tecnologie vengono richieste nella definizione della baseline, allora possono
venire impiegata, ovviamente fermo restando il fatto che debbano essere implementata
in modo da rendere le funzionalità operabili. Una analisi delle tecniche applicabili per gli
script è contenuta nell’apposito documento1 ufficiale del W3C: “Client side scripting
technique” e nel documento2 di tecniche HTML: “Script Techniques”.
Come si può notare leggendo le disposizioni citate, le WCAG 1.0 e la legge Stanca sono le più
stringenti in materia; le WCAG 1.0 per il fatto di essere state progettate nel 1999, mentre la
legge Stanca per averne voluto riproporre i principi base.
A questo proposito la legge italiana è stata anche piuttosto criticata per la sua severità
sull’argomento. Roberto Scano, una delle maggiori autorità e attivo promotore di tale legge
spiega la scelta dicendo3 che la limitazione sugli script fa parte di un punto di controllo WCAG
1.0 di livello 1, il quale dovrebbe essere quindi garantito da tutte le applicazioni Web presenti
nel mercato che si dichiarano conformi alla singola A o alla Doppia-A.
In realtà le funzioni di JavaScript che non veicolino contenuti essenziali possono essere
implementate senza violare i punti di controllo citati delle WCAG 1.0 dal momento che non
sono perdute le informazioni importanti quando i JavaScript vengono disattivati.
Invece le WCAG 1.0 vengono violate quando, ad esempio, siano stati implementati per delle
importanti funzionalità nella compilazione di un modulo, limitando l’usabilità e la fruibilità delle
informazioni.
La Section 508 ha un approccio meno restrittivo in materia, l’idea è quella di consentire i
JavaScript fintanto che gli effetti della loro introduzione lascino comunque le pagine accessibili
dalle tecnologie assistive, quantomeno garantendo che venga associato un testo funzionale
identificativo.
Il contenuto normativo delle WCAG e della legge italiana è molto più chiaro e vincolante in
materia ed un controllo è molto facile, semplicemente disattivando gli script e verificando che il
sito offra pari funzionalità. La Section 508 invece autorizza all’uso degli script fin quando essi si
mantengano leggibili dalle tecnologie assistive, un concetto molto più permissivo, dal momento
che in questo modo è spesso sufficiente aggiungere un elemento ALT esplicativo nella
definizione degli script per consentirne la messa a norma.
1
2
3
[http://www.w3.org/TR/WCAG20-TECHS/#N11799]
[http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20040903/#scripts]
[http://punto-informatico.it/p.aspx?i=57852]
- 180 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Script
Gli script sono degli elementi di codice interpretato dai programmi utente che si trovano inseriti
direttamente nella pagina Web.
(X)HTML è un linguaggio statico e permette ben poche interazioni da parte dell’utente, in
pratica con JavaScript è possibile implementare codici di programmazioni, definire variabili o
fare calcoli matematici.
Tra le varie funzionalità degli script vale la pena segnalare:
Sono in grado di modificare l’aspetto della pagina Web;
Possono scrivere parte del contenuto quando la pagina viene caricata;
Possono gestire del contenuto nascosto che viene visualizzato solo a seguito di
particolari interazioni dell’utente, o possono, viceversa, nasconderne dell’altro visibile;
Possono essere utilizzati soprattutto per compiere una prima analisi sui i contenuti
immessi nei campi dei moduli prima che essi vengano inviati al server per essere
processati;
Possono aggiungere degli aspetti grafici di evidenziazione di contenuti ritenuti
interessanti;
Possono agire aprendo menu al volo o nuove pagine e nuovi contenuti in automatico o
su richiesta.
Ci possono essere diversi linguaggi di scripting, sicuramente quello più impiegato a livello Web
è JavaScript, per cui spesso i due termini finiscono per essere usati in maniera intercambiabile
in questi contesti.
JavaScript è un linguaggio di programmazione sviluppato da Netscape con l’apposita finalità di
essere integrato nel codice (X)HTML per le pagine Web.
A differenza degli applet che sono un pacchetto di codice chiuso, JavaScript viene interpretato
dal browser in tempo reale al momento di caricare la pagina , e non compilato in un codice
macchina.
Il testo di un codice JavaScript viene incluso nell’elemento SCRIPT della pagina (X)HTML, ma
può essere anche predisposto in un file a parte che viene importato nella pagina prima che
venga interpretata.
Un programma in JavaScript viene mandato in esecuzione al caricamento della pagina o in
risposta ad alcuni eventi, ad esempio la pressione di un tasto o il passaggio del mouse su un
oggetto. Alcuni eventi come ad esempio ONCLICK possono essere scatenati sia dal mouse sia
dalla tastiera e sono quelli nativamente più accessibili.
Nel considerare l’accessibilità di questi oggetti possiamo considerare alcune tipologie di
funzioni base svolte dai JavaScript:
- 181 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Effetti aggiuntivi secondari o straordinari, come ad esempio cambiare una colorazione
per mettere in evidenza un oggetto al passaggio del mouse;
Azioni di utilità finalizzate soprattutto a rendere più usabile il contenuto, come ad
esempio la validazione lato client dei campi di un modulo o la compilazione automatica
di alcuni valori in conseguenza ad una azione;
Effetti essenziali per la fruizione della pagina, come ad esempio creare del contenuto
aggiuntivo o intraprendere una azione per inviare un modulo.
In particolare possono essere rintracciati 4 tipi di effetti e di compiti che possono essere svolti
dai JavaScript:
Contenuti espliciti: gli script possono produrre del contenuto visibile inserito
direttamente nel documento al momento di caricare la pagina, un esempio è la
generazione di una data di ultimo aggiornamento della pagina;
Cambiamento degli attributi: un apposito gestore di eventi può cambiare le immagini o
gli attributi del contenuto ad esempio al passaggio del mouse, ovviamente questo no
costituisce limite di funzionalità se non veicola informazioni essenziali;
Verifiche all’interno dei moduli: gli script sono spesso utilizzati per controllare che le
informazioni inserite nei moduli siano stati implementati in maniera corretta. Sono
anche in grado di modificare o introdurre dei dati in relazione alle scelte dell’utente. Un
controllo può essere ovviamente svolto anche lato server, ma questo richiede un
traffico di dati notevolmente maggiore ed un sensibile ritardo in termini di tempo.
Contenuti nascosti: spesso gli script scrivono contenuti in modo che risultino non visibili
al primo impatto. Successivamente, in seguito ad interazioni dell’utente, il contenuto
visibile viene mostrato o altro contenuto viene nascosto. Un esempio di questa tecnica
sono i menu di navigazione ad espansione di ramo, o i menu contestuali attivabili al
volo al passaggio del mouse.
Come accennato in precedenza il problema che si incontra in tutti questi tipi di effetti è che i
browser o le tecnologie assistive potrebbero non essere in grado di trattarli correttamente.
Se questo può non costituire un problema per gli effetti puramente presentazionali, risulta
invece di grave limitazione per le funzionalità di base.
In particolare ci possono essere 4 categorie di impatto sull’accessibilità:
Navigazione: incapacità o difficoltà di navigare via tastiera o usando le tecnologie
assistive;
Contenuti nascosti: la visualizzazione di contenuti o funzionalità che non sono accessibili
dalle tecnologie assistive;
Controllo dell’utente: perdita di controllo da parte dell’utente sui cambiamenti
automatizzati del contenuto;
- 182 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Confusione o disorientamento: dovuto al mutamento della normale funzionalità del
programma utente o lo scatenamento di eventi non previsti.
Il modo naturale di ovviare a questi problemi può essere sintetizzato in 2 tecniche:
Assicurarsi che lo script sia direttamente accessibile;
Fornire un’alternativa accessibile senza lo script.
Ad ogni modo va ricordato che l’impiego degli script, non rende, di per sé, la pagina
inaccessibile, anzi, come indicato anche nel documento citato delle WCAG 2.0, alcune tecniche
vengono anche suggerite per migliorare l’accessibilità dei contenuti.
Tecniche per gli script
Qualsiasi normativa si decida di seguire ci sono comunque delle tecniche per gli script che
aiutano a rendere questi strumenti maggiormente accessibili.
Queste tecniche sono esposte nei documenti citati delle WCAG e per alcune vale sicuramente la
pena citare esplicitamente le più importanti.
Utilizzare l’elemento NOSCRIPT quando si usa SCRIPT. Il codice (X)HTML all’interno di
questo elemento viene eseguito dai programmi utente che non hanno attivato un
interprete in grado di comprendere ed eseguire il linguaggio dello script. In questo
modo è possibile predisporre una versione alternativa delle funzionalità offerte dal
codice.
Utilizzare delle scorciatoie da tastiera per gli script che siano direttamente accessibili;
Utilizzare dei gestori di eventi logici, e non specifici per il dispositivo di ingresso;
Non utilizzare caselle di riepilogo a discesa (combo box) che siano auto-invianti tramite
l’intercettazione dell’evento ONCHANGE. In alcuni browser quest’evento può venir
scatenato anche con il semplice spostamento del cursore sulle scelte e ciò impedisce
che queste funzionalità possano essere fruite via tastiera. Una problematica simile si
può verificare anche con l’evento ONSELECT. Si suggerisce invece di aggiungere un
esplicito bottone di invio da attivare una volta fatta la selezione della voce dalla casella
di riepilogo.
Porre attenzione agli eventi attivati. Ad esempio, la pressione del tasto di tabulazione su
un elemento avente il focus viene rilevato come un KEYPRESS, e se viene associato un
evento specifico risulterà impossibile utilizzare il tasto di tabulazione per la navigazione;
Fornire attivazioni ridondanti per i diversi dispositivi di ingresso.
Vorrei proporre un breve esempio che illustri la tecnica basilare del NOSCRIPT.
- 183 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Un’istruzione come la seguente che consente di tornare alla pagina precedente non sarà
fruibile dagli utenti che hanno disabilitato gli script o che utilizzano browser che non li
supportano:
<a href="JavaScript:history.go(-1)">Pagina Precedente</a>
In casi del genere è possibile aggiungere una sezione NOSCRIPT che integri questa mancanza
con un normale codice (X)HTML che svolga la medesima funzionalità.
<script type="text/JavaScript" src="menu.js"></script>
<noscript>
<ul>
<li><a href="pagina1.html">Menu 1</a></li>
<li><a href="pagina2.html">Menu 2</a></li>
<li><a href="pagina3.html">Menu 3</a></li>
</ul>
</noscript>
Gestori di eventi
Come accennato nel breve elenco di tecniche precedenti, una certa cura va posta nella
trattazione dei gestori di eventi (event handler).
Un gestore di eventi è un insieme di istruzioni che vengono richiamate quando un particolare
evento viene soddisfatto, in genere su azioni del mouse o della tastiera.
Alcuni tra i più importanti eventi attivabili possono essere i seguenti:
ONLOAD;
ONUNLOAD;
ONCLICK;
ONDBLCLICK;
ONFOCUS;
ONBLUR;
ONMOUSEDOWN;
ONMOUSEUP;
ONMOUSEOVER;
ONMOUSEMOVE;
ONMOUSEOUT;
ONKEYDOWN;
ONKEYUP;
ONKEYPRESS.
L’attenzione a questa funzionalità viene rivolta anche da parte delle normative considerate:
- 184 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
WCAG 1.0: punto di controllo 6.4: “Garantire che i gestori di eventi per gli script e le
applet siano indipendenti dai dispositivi di input”, contenuti analoghi sono ripresi nei
punti di controllo 9.2 e 9.3.
Section 508: Nel paragrafo 1194.22(m) ci si riferisce alla accessibilità del software del
paragrafo 1194.21 dove si richiede la operabilità via tastiera1;
D.M. 5 Luglio 2005, requisito 16: “Garantire che i gestori di eventi che attivano script,
applet o altri oggetti di programmazione o che possiedono una propria specifica
interfaccia, siano indipendenti da uno specifico dispositivo di input.”;
WCAG 2.0: linea guida 2.1: “Rendere tutte le funzionalità operabili tramite comandi da
tastiera.”.
In pratica le norme ritengono necessario che, nel caso siano previsti degli eventi che implicano
l'iterazione da parte dell'utente, venga garantita la loro esecuzione a qualsiasi utente, sia che
egli utilizzi una periferica di puntamento sia una tastiera a cui può essere eventualmente
agganciato un emulatore per le tecnologie assistive.
Di fatto, come specificato espressamente nelle WCAG 2.0, bisogna definire un comando
tastiera per ogni comando che richieda l’uso del mouse. Le motivazioni sono:
Non tutti gli utenti navigano il Web tramite interfaccia grafica, utilizzando il mouse
come periferica di input;
I comandi tastiera possono essere attivati anche tramite comandi vocali;
Le tecnologie assistive per non vedenti utilizzano i comandi tastiera per navigare
attraverso i contenuti.
In questa ottica è necessario accoppiare due gestori di eventi differenti che abbiano lo stesso
codice associato nel modo seguente:
ONMOUSEDOWN e ONKEYDOWN;
ONMOUSEUP
ONCLICK
ONMOUSEOVER
ONMOUSEOUT
e ONKEYUP;
e ONKEYPRESS;
e ONFOCUS;
e ONBLUR.
1
“When software is designed to run on a system that has a keyboard, product functions shall be executable
from a keyboard where the function itself or the result of performing a function can be discerned textually”
- 185 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Va notato che non esiste un equivalente per il doppio click (ONDBLCLICK) o per il movimento del
mouse (ONMOUSEMOVE), perciò si consiglia di evitare questi elementi.
In pratica, la raccomandazione migliore è quella contenuta nel punto di controllo 9.3 delle
WCAG 1.0: “Negli script, specificare gestori di evento logici piuttosto che gestori di evento
dipendenti dal dispositivo.”.
Chiudo con un esempio elementare sugli eventi.
Nel codice seguente, se JavaScript non fosse abilitato, selezionando il collegamento la nuova
pagina sarà aperta nella finestra corrente. Se invece fosse attivo, allora il click sul
collegamento ipertestuale o l'uso di qualsiasi tasto con il focus sul collegamento ipertestuale
aprirà una finestra nuova:
<a href="nuova.html" onclick="window.open(this.href); return false;"
onkeypress="window.open(this.href); return false;"> Nuova Pagina </a>
E’ questo un esempio di come sia possibile aprire finestre nuove con cambiamento di contesto
anche se nelle ultime specifiche del linguaggio XHTML sono stati rimossi i costrutti dedicati.
Il codice precedente è riportato per brevità a titolo di esempio sugli eventi e non rappresenta
una scrittura valida per l’accessibilità, il codice JavaScript andrebbe separato ed integrato con
un opportuno avviso.
Applet e plug-in
In genere molti dei principi guida esposti per gli script sono applicabili anche per gli applet ed i
plug-in al punto che la maggior parte delle normative citate in precedenza li considerano
entrambe nella stessa esposizione. Un esempio è proprio la nostra legge che, nei requisiti 15,
16 e 17 considera i diversi aspetti di entrambe le tecnologie.
In special modo per gli oggetti:
E’ necessario fornire un equivalente testuale per:
o
Tutti gli utenti che non posseggono i plug-in necessari alla loro visualizzazione;
o
Gli utenti che a causa di disabilità non possono interagire con tali contenuti;
Occorre garantire che le interfacce degli applet siano direttamente accessibili o
compatibili con le tecnologie assistive.
La Section 508 invece ne fa un richiamo a parte nel paragrafo 1194.22 (m) rimandando per la
loro funzionalità ai requisiti software espressi nella stessa legge negli 11 standard citati del
paragrafo 1194.21 tra le cui richieste si trova, come detto, quella che tutte le funzionalità siano
operabili via tastiera.
Questa richiesta non implica che ogni singolo controllo sia raggiungibile ed operabile via
tastiera, ma che via tastiera sia almeno possibile emularne la funzionalità.
- 186 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
AJAX
AJAX (Asynchronous JavaScript and XML) è una raccolta di tecnologie Web assemblate insieme
per consentire le interazioni tra client e server delle applicazioni Web senza che venga
ricaricata o rinfrescata la pagina.
AJAX non è una tecnologia a se stante, ma, in qualche modo, è una combinazione di tecniche.
AJAX usa:
(X)HTML e CSS per presentare le informazioni. Entrambi possono essere modificati
dinamicamente per visualizzare nuove informazioni con nuove impaginazioni. Questi
cambiamenti sono fatti in genere tramite il DOM (Document Object Model);
JavaScript per manipolare gli elementi e per stabilire una comunicazione con il server
Web. Questo consente di trasmettere dati, ad esempio in formato XML, tra il client ed il
server Web senza richiedere che la pagina venga ricaricata e rinfrescata.
Per una spiegazione più dettagliata delle funzionalità e dell’uso di questa tecnica rimando alle
numerose trattazioni disponibili in rete1.
In questa sede è opportuno far presente che, utilizzando AJAX, le applicazioni Web possono
raggiungere un elevato grado di interattività senza passare attraverso le classiche procedure di
richiesta nuove pagine al server. Questo sveltisce notevolmente il traffico dati e il JavaScript
garantisce un elevato livello di interazione.
Nonostante che nessuna delle tecniche AJAX sia innovativa, tuttavia la popolarità crescente di
questo metodo comporta la necessità di considerarlo nel suo insieme dal punto di vista
dell’accessibilità.
Da questo punto di vista alcune controindicazioni di AJAX possono essere:
AJAX richiede l’attivazione dei JavaScript, con le problematiche discusse per gli script:
dispositivi palmari, vecchi browser o browser testuali possono non essere in grado di
supportare AJAX o di gestirlo correttamente, e di questo il progettista deve essere al
corrente;
AJAX richiede che sia supportato il metodo XMLHTTPREQUEST per la comunicazione con il
server Web, ed alcuni browser non lo fanno;
AJAX interagisce con il server in maniera autonoma, anche senza esplicita richiesta
dell’utente manipolando eventualmente l’interfaccia della pagina al volo. Questo
potrebbe cambiare alcune abitudini ed alcune aspettative dell’utente;
1
Si potrebbero avere degli spostamenti inattesi del focus;
[http://www.w3schools.com/ajax/default.asp]
- 187 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Gli utenti potrebbero non avere alcuna idea di dove sono state visualizzate le eventuali
informazioni o modifiche ricevute;
L’interfaccia ed i contenuti dell’applicazione potrebbero cambiare in maniera non
evidente senza rendere espliciti i mutamenti occorsi. Questo problema potrebbe essere
particolarmente sentito con gli screen-reader che potrebbero non accorgersi per nulla
dei cambiamenti e non presentare le modifiche. Le WCAG richiedono che la gestione dei
cambiamenti di contenuto e di contesto ricada fra le considerazioni dell’accessibilità 1.
Il principio generale per rendere accessibili i cambiamenti della interfaccia dinamica, è quello
di avvisare l’utente delle modifiche avvenute consentendo un accesso diretto ai nuovi
contenuti. In particolare:
Avvisare l’utente:
o
Notificare l’uso di questa tecnologia, sia in precedenza sia all’interno di una
pagina AJAX;
o
Avvisare l’utente se le funzionalità JavaScript non fossero attive rendendo AJAX
non disponibile, in caso contrario avvisare che le pagine verranno aggiornate
automaticamente;
o
Quando possibile garantire la possibilità di aggiornamenti manuali;
o
Mantenere le impostazioni dell’utente;
Rendere note le modifiche:
o
Per le piccole aree della pagina, evidenziare la zona aggiornata con un
mutamento del colore dello sfondo della zona per qualche secondo;
o
Far lampeggiare le zone aggiornate per meno di 3 secondi. In questo caso
bisogna porre attenzione alla frequenza di lampeggio per le problematiche legate
all’epilessia fotosensibile;
Facilitare l’utente nella ricerca delle informazioni aggiornate:
o
Fornire un’opzione per assegnare il focus ai nuovi dati;
o
Fornire un’opzione per gli aggiornamenti tramite un messaggio di avviso;
o
Utilizzare gli elementi d’intestazioni (X)HTML per contrassegnare le sezioni a
contenuto aggiornabile;
1
Usare le tecniche di accessibilità per le pagine DHTML.
WCAG 2.0, SC 1.3.1: “Information and relationships conveyed through presentation can be
programmatically determined, and notification of changes to these is available to user agents, including
assistive technologies”.
- 188 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Un processo del genere non è sempre facile da ottenere.
Le tecniche di accessibilità specificatamente riferite a questo strumento relativamente recente
sono considerate dal W3C nei nuovi documenti che fanno parte delle raccomandazioni ARIA
(Accessible Rich Internet Applications)1. In questa sede non verranno approfonditi
ulteriormente questi argomenti, rimandando ai numerosi articoli presenti in rete, anche forniti
dallo stesso W3C2.
III.11 - Comprensibilità dei contenuti
Questo principio fa riferimento alla capacità del sito di comunicare il contenuto informativo in
maniera più possibilmente chiara e semplice in relazione all’argomento trattato in modo da
venire incontro alle esigenze del più vasto pubblico possibile.
Il progetto WAI fa esplicito riferimento a questo principio in due assunti di base:
WCAG 1.0, linea guida 14.1: “Assicurarsi che i documenti siano chiari e semplici in
modo che possano essere compresi più facilmente.”;
WCAG 2.0: linea guida 3.1: “Rendere leggibile e comprensibile il contenuto testuale.”.
Delle due espressioni, sicuramente quelle più espressive e vincolanti sono le indicazioni
contenute nelle WCAG 1.0, mentre le WCAG 2.0 hanno ricevuto qualche critica per la
formulazione troppo blanda e facilmente aggirabile del requisito.
Ancora meno attenti sono stati, d’altro canto, i legislatori nazionali, come vedremo poi,
probabilmente per il fatto che una valutazione accurata ed oggettiva di una richiesta del
genere può essere particolarmente difficoltosa.
Queste direttive sono però importanti in diversi casi.
La comprensibilità dei contenuti è un concetto che spesso sconfina nel campo dell’usabilità, un
sito che offra del materiale facilmente comprensibile migliora sicuramente l’aspetto
dell’usabilità delle informazioni offerte. Di questo si è in parte accennato nel discutere le
interazioni fra accessibilità ed usabilità.
Un testo facilmente comprensibile è di grande ausilio anche ai disabili cognitivi.
Per molto tempo gli sviluppatori Web hanno preferito non tener conto di queste categorie di
utenti, ritenendoli fuori dal loro pubblico e considerando che lo sviluppo di siti altamente
comprensibili è costoso e difficile. In realtà le disabilità nell’apprendimento non implicano
necessariamente un basso livello di intelligenza o di interesse nei contenuti esposti.
1
2
[http://www.w3.org/WAI/intro/aria.php]
[http://www.w3.org/2006/Talks/0524-www-AjaxWAI.pdf]
- 189 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Va ricordato che alla base di tutti i principi dell’accessibilità si pone la necessità di sviluppare
contenuti universali e fruibili per la maggior parte possibile degli utenti e lo scoglio iniziale del
cambiamento di metodologia a favore della comprensibilità dei contenuti esposti non deve
rappresentare un’insormontabile barriera in termini di costi e difficoltà.
Scrivere per farsi capire
Questo assunto è il titolo di una sezione1 della guida sull’accessibilità pubblicata su internet di
Michele Diodati. La frase, a mio avviso, rappresenta al meglio il principio di accessibilità da
applicare sui testi Web.
La raccomandazione di base è quella appunto, di scrivere per farsi capire, tenendo presente
che non si sta cercando di vendere un prodotto, quanto piuttosto di comunicare
un’informazione.
La letteratura in materia è molteplice, raccomando il testo fondamentale di Roberto Scano 2,
sintetizzato in un articolo3 apparso su LAU (Laboratorio di Accessibilità ed Usabilità), oltre che
agli appunti4 citati di Michele Diodati.
Da queste letture si possono evidenziare alcuni accorgimenti di base per questo argomento:
Utilizzare un linguaggio chiaro e semplice.
Se non ci si rivolge esclusivamente ad un pubblico specialistico occorre fare attenzione
alla scelta dei termini, in genere è opportuno impiegare un lessico adatto ed alla portata
di tutti i possibili lettori.
Il che non vuol dire, ovviamente, che non si possano impiegare termini tecnici quando
necessari, a patto di corredarli con le opportune spiegazioni ed un glossario di
riferimento. Acronimi ed abbreviazioni vanno spiegati almeno una volta nella pagina
come suggerito in seguito.
Una particolare cura va posta per i termini stranieri. Per quanto l’inglese sia, a giorni
nostri, correntemente diffuso nei testi e nel gergo, occorre ricordare che non tutti gli
utenti potrebbero comprenderne i termini. Non solo, anche gli screen-reader potrebbero
essere in difficoltà con i termini stranieri e perdere tempo a caricare i dizionari. I cambi
di lingua nel testo vanno opportunamente segnalati con gli strumenti del linguaggio
(X)HTML.
E’ ovvio che non tutto va tradotto, termini come il mouse di un computer sono entrati a
1
2
3
4
[http://www.diodati.org/scritti/2004/guida/ele_acc35.asp]
Roberto Scano: “Accessibilità dalla teoria alla realtà” - capitolo 25.
[http://lau.csi.it/realizzare/usabilita/grafica_testi/testi_usabilita.shtml]
[http://www.diodati.org/scritti/2004/guida/ele_acc35.asp]
- 190 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
far parte della nostra lingua e sono universalmente comprensibili. La traduzione italiana
sarebbe ridicola.
Un’attenzione simile va posta per i termini gergali che sono in genere da bandire e i
termini troppo burocratici che appesantiscono inutilmente la lettura. A questo proposito
è importante una circolare del ministero della funzione pubblica, discussa nella sezione
successiva;
Controllare la grammatica la sintassi.
Si consiglia di impiegare una struttura sintattica basata su periodi brevi e lineari, poche
proposizioni, verbi in forma attiva, ed elenchi puntati.
La sintassi è importante: i più recenti screen-reader possono dare la giusta cadenza e le
pause adatte nella lettura in relazione ai segni di interpunzione incontrati.
Di grande utilità possono essere i correttori ortografici, molti sono automatici all’interno
di quasi tutti i programmi di video-scrittura.
Se possibile vale la pena rileggere diverse volte il testo e farlo esaminare da altre
persone prima di diffonderlo, al fine di ridurre al massimo i refusi che possono diminuire
drasticamente la comprensione per chi usa un sintetizzatore vocale.
Altri utili strumenti automatici possono essere d’aiuto nel valutare gli elementi della
frase e di tutto il testo. A questo proposito vorrei segnalare che Juicy Studio mette a
disposizione un valutatore della leggibilità1 integrato con numerose statistiche sulla
strutturazione delle frasi e del discorso. E’ attivabile anche dalla barra dell’accessibilità
sotto la voce tools. Anche Microsoft Word permette un’analisi del livello di leggibilità di
un documento. I valutatori di leggibilità sono degli strumenti tipici dei programmi di
videoscrittura, in grado di produrre valutazioni, basate su dizionari interni e calcoli
statistici, relative al tipo di linguaggio adoperato in un testo (formale, colloquiale,
burocratico, ecc.). Strumenti del genere possono essere utili per valutare in maniera
automatica leggibilità dei contenuti;
Facilitare la lettura.
Si possono usare gli strumenti messi a disposizione degli editor di testo per evidenziare
le parti strutturali ed importanti di un documento anche sotto l’aspetto presentazionale,
ricordando, quando possibile, di aggiungere anche la relativa semantica strutturale.
Ad esempio, si può ricorrere all’uso del grassetto per enfatizzare una parola chiave. In
tal caso è disponibile un marcatore strutturale STRONG in genere associato proprio con
questo tipo di evidenziazione su quasi tutti i browser.
1
[http://juicystudio.com/services/readability.php]
- 191 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Molto utili sono anche le liste puntate per sintetizzare i concetti e fissare velocemente i
punti chiave di una esposizione.
Vanno evitate in genere le sottolineature, in quanto facilmente confondibili con i
collegamenti ipertestuali. In certi casi anche il corsivo che può essere facilmente
confondibile per taluni font. A questo proposito si consiglia di impiegare caratteri senza
decorazioni (sans-serif) e tipi di font il più possibile definiti e nitidi.
Un’interlinea di 1,5 può agevolare la lettura, così come è utile separare i paragrafi a
blocchi ed utilizzare un allineamento predefinito a sinistra evitando la giustificazione.
L’impiego delle immagini per chiarificare i concetti può aumentare la comprensione dei
contenuti testuali, mentre vanno scoraggiate le animazioni che possono facilmente
distrarre;
Mantenere uno stile coerente e logico.
Un aspetto importante è sicuramente la coerenza di stile nella presentazione degli
elementi interni ad una pagina e di tutta la linea di impaginazione di un sito. Questo
anche per garantire che ad una modalità di presentazione uguale corrisponda una
funzionalità identica.
L’omogeneità stilistica permette di fornire un ambiente integrato in cui la navigazione e
la lettura risulta più agevolata ed usabile, un ambiente più fruibile in particolar modo
per i disabili cognitivi per i quali la coerenza di aspetto va sicuramente preferita rispetto
alla varietà delle modalità di presentazione;
Fornire degli strumenti di orientamento e di navigazione che possano permettere di
individuare la posizione di un contenuto all’interno di un blocco di informazioni.
In particolare è utile fornire una mappa del sito, intestare con chiarezza e titoli differenti
le pagine, aggiungere indici e sommario, strutturare le informazioni.
A questo principio, come a quello precedente si richiamano direttamente anche alcune
esplicite raccomandazioni sia delle legge Stanca che delle WCAG;
Permettere agli utenti di personalizzare la visualizzazione dei contenuti in modo che
possano essere adattati alle proprie esigenze. Questo si può fare ad esempio:
permettendo il ridimensionamento dei testi e delle immagini, favorendo l’applicazione di
altri stili, pensati dal progettista o personalizzati dagli utenti, ed evitando l’utilizzo di
dimensioni fisse o assolute degli elementi della pagina;
Utilizzare degli elementi strutturali del linguaggio.
Come discusso in una sezione a parte di questo lavoro, un grande aiuto per la leggibilità
e la comprensione viene fornita direttamente anche dallo stesso linguaggio (X)HTML.
L’impiego delle opportune marcature strutturali utilizzate nell’ambito del loro corretto
aspetto semantico evidenzia la struttura logica del documento chiarificando le corrette
gerarchie delle parti di un documento.
- 192 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Come accennato nella precedente esposizione ci sono alcuni strumenti di valutazione
automatica, tuttavia è chiaro che i testi migliori possono essere portati a compimento
solamente attraverso la valutazione diretta delle pagine da parte di persone con disabilità e di
formazione culturale di diverso livello.
La valutazione oggettiva di questo requisito è molto difficoltosa e piuttosto contestabile.
Nelle WCAG, soprattutto nelle 1.0, il requisito della chiarezza e semplicità è giustamente
proposto come vincolo obbligatorio per l’accessibilità. Una sezione apposita delle tecniche di
base1 ne suggerisce le linee fondamentali.
Da quest’obbligo inderogabile nasce il grosso problema del riconoscimento anche della
semplice verifica di primo livello per molti siti che invece dichiarano di aver raggiunto anche i
livelli 2 o 3.
In effetti, un sito che rispetti tutte le raccomandazioni contenute nelle WCAG 1.0 tranne il
punto di controllo 14.1, che richiede di scrivere nel modo più chiaro e semplice possibile in
relazione all'argomento trattato, non è accessibile neppure al livello A.
I principi sopra enunciati sono validi in generale e devono essere tenuti in considerazione per
ogni tipologia di sito. Come applicare al meglio queste linee guida può variare a seconda dei
vari siti specializzati, che possono richiedere accorgimenti mirati.
In particolar modo vanno tenuti in considerazione alcune categorie comuni:
Siti di contenuto informativo e pubblicitario;
Siti di contenuto tecnico e scientifico;
Siti di contenuto amministrativo e burocratico.
Qualche accenno alla parte amministrativa e burocratica verrà svolto nel seguito, vista la
personale esperienza lavorativa a proposito. Per gli altri casi si rimanda al testo di Robero
Scano che ha un ottimo e completo capitolo2 sull’argomento curato da Michele Diodati.
Suggerimenti in (X)HTML
Vorrei riportare alcuni brevi accenni agli accorgimenti più semplici che si possono facilmente
realizzare nel linguaggio (X)HTML per rendere i testi più chiari e comprensibili.
Acronimi ed abbreviazioni
Il punto di controllo 4.2 delle WCAG richiede di: “Specificare il significato di ogni abbreviazione
o acronimo nel documento laddove compaia per la prima volta.”.
1
2
[http://www.w3.org/TR/WCAG10-CORE-TECHS/#writing-style]
Roberto Scano “Accessibilità: dalla teoria alla realtà” – capitolo 28.
- 193 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Nei siti, soprattutto scientifici, capita molto spesso di leggere numerose sigle che risultano di
significato abbastanza oscuro per un lettore neofita e che ne ostacolano la comprensione del
testo.
Per evitare questo inconveniente è buona norma fornire in ciascuna pagina la forma estesa di
tutte le sigle e le abbreviazioni utilizzate.
Lo si può fare semplicemente sia nel testo visibile, affiancando alla sigla la sua forma estesa,
sia a livello di codice, usando gli appositi elementi ABBR e ACRONYM del linguaggio.
ABBR si usa per abbreviazioni come Sig., Dott, ecc. eccetera.
ACRONYM si impiega per gli acronimi tipo FIAT, HTML e tutte le sempre più numerose sigle
informatiche.
Segue un semplice esempio in XHTML 1.1:
<acronym xml:lang="en" title="eXtensible Hyper Text Markup
Language">XHTML</acronym>
In questo esempio è stato aggiunto anche un attributo che rende esplicito il cambiamento di
lingua, come spiegato a parte.
La maggior parte dei browser è in grado di trattare questi attributi in maniera particolare,
quando non visibile e non notificata in qualche modo dai browser può essere utile rendere
consapevole l’utente della presenza nel codice della forma estesa di una abbreviazione o di un
acronimo.
In genere la maggior parte dei browser attuali presentano una sottolineatura tratteggiata sotto
questi termini, visualizzando l’attributo TITLE al passaggio del mouse. Tramite CSS è possibile
ottenere anche altri effetti di passaggio, come ad esempio il fatto che il cursore cambi di
forma.
Questo accorgimento serve soprattutto per chi usa Internet Explorer. Gli altri browser
mostrano già da soli all'utente la sottolineatura tratteggiata delle sigle, quando sia presente nel
codice di marcatura una forma estesa.
Un piccolo appunto, fonte di argomento di discussione nei forum dedicati, è la richiesta
esplicita del punto di controllo di marcare necessariamente solo la prima delle occorrenze di un
termine in una pagina. La scelta di marcare anche le altre è lasciata a discrezione del
programmatore.
In genere questa scelta è sufficiente, per quanto, in pagine molto lunghe e complesse,
potrebbe essere utile marcare con ABBR o ACRONYM più occorrenze della medesima sigla, nel
caso che le sue ripetizioni appaiano isolate nel testo e molto distanziate tra loro.
- 194 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Citazioni
Le citazioni devono essere marcate utilizzando gli elementi < Q> e <BLOCKQUOTE> che non
devono essere usati invece per puri effetti estetici come ad i rientri del testo, per i quali vanno
utilizzati i fogli di stile.
La differenza fra i due marcatori consiste nel fatto che <Q> dovrebbe essere utilizzato per le
citazioni brevi, inserite in genere all’interno del flusso normale del testo. Anche per questo
viene circondato automaticamente dagli apici dai browser visuali. Pertanto il testo contenuto
non dovrebbe averne di propri. L’utilizzo dell’elemento <Q> invece dei caratteri ASCII o
dell’entità &QUOT; consente al browser di visualizzare le virgolette nella codifica locale. L’utilizzo
delle virgolette ed i vari stili di virgolette variano automaticamente da lingua a lingua.
L’elemento <Q> non risulta ancora supportato da tutti i browser e richiede la presenza
dell’attributo LANG al fine di una corretta lettura ed adeguamento allo stile locale delle
virgolette.
Ecco un breve esempio:
<q xml:lang="en">We are such stuff as dreams are made on</q>
L’elemento <BLOCKQUOTE> serve invece ad identificare un intero blocco di citazione che
necessita di maggior visibilità, per separarlo e distinguerlo dal resto del testo.
Il blocco interno di BLOCKQUOTE andrebbe marcato come un paragrafo.
Anche in questo caso molti sviluppatori hanno però iniziato ad utilizzare scorrettamente
l’elemento <BLOCKQUOTE> per impaginare direttamente i contenuti anziché ricorrere ai fogli di
stile.
Anche in questo caso ecco un breve esempio:
<blockquote cite="http://www.w3.org/TR/WCAG10-HTMLTECHS/# text-quotes">
<p>Do not use quotation markup for formatting effects such as indentation.
[Priority 2]</p>
</blockquote>
In quest’esempio è stato aggiunto anche l’attributo CITE che può essere usato anche con il
precedente elemento Q.
Se CITE viene utilizzato come attributo, il suo valore è un URI (Uniform Resource Identifier) che
indica il documento sorgente. Questo attributo è stato implementato con lo scopo di dare
informazioni sulla sorgente da cui la citazione è stata tratta, ma quasi mai i browser visuali li
impiegano.
Esiste anche la possibilità di avere un elemento separato <CITE>, in tal caso non deve esser un
URI e viene inserito per fornire il nome dell’autore. In questo secondo caso sarà reso
esplicitamente visibile come testo anche dai browser grafici se non specificato altrimenti.
- 195 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Cambi di lingua
Per facilitare la lettura degli screen-reader e la catalogazione di un documento da parte dei
robot automatici, un documento (X)HTML deve utilizzare una dichiarazione di lingua che varia
a seconda che si tratti di un HTML e XHTML (fino alla versione 1.0), o di un XHTML 1.1.
Tuttavia può capitare con una certa frequenza di introdurre dei termini in una lingua differente,
ad esempio per un documento in italiano non è infrequente impiegare dei termini in inglese
che dovrebbero essere gestiti al meglio da programmi utente che pronuncino il testo.
Il problema è che, coloro che usano un sintetizzatore vocale, potrebbero non comprendere una
parola inglese presente in una pagina, se questa viene letta all'italiana.
Per consentire alle tecnologie assistive di leggere ciascuna parola in modo comprensibile, cioè
secondo le regole di pronuncia della lingua a cui appartiene, è opportuno segnalare nel codice
di marcatura, per mezzo dell'apposito attributo LANG (o XML:LANG se si usa XHTML 1.1), i cambi
di lingua presenti nel testo. Questa raccomandazione è espressamente contenuta nel punto di
controllo1 4.1 delle WCAG 1.0.
Va ricordato che stadio attuale di sviluppo delle tecnologie assistive, per alcuni sintetizzatori
vocali il cambio di lingua per ogni parola straniera può ancora produrre rallentamenti notevoli
nella lettura della pagina. A detta di persone che lavorano nel settore le cose stanno
migliorando anche da questo punto di vista e il tempo di caricamento dei dizionari stranieri è
stato notevolmente ottimizzato, soprattutto per JAWS che è passato da una certa lentezza
delle versioni 4 fino ad una buona funzionalità a partire già dalla versione 6.
Come anche raccomandato da numerosi autori tra cui Roberto Ellero e Luca Mascaro alla
conferenza di Arese e Michele Diodati nel suo sito Web, può essere utile evitare di marcare i
cambi di lingua per quelle parole inglesi che sono state assorbite dalla lingua italiana. Stessa
valutazione per i termini che rimarrebbero ugualmente comprensibili all'ascoltatore anche se
pronunciate all'italiana dal sintetizzatore vocale, come ad esempio trend, big, font, eccetera.
Pubblica Amministrazione
Come notato in precedenza, se da parte delle WCAG 1.0 e 2.0 viene data la necessaria
rilevanza al problema della comprensibilità dei testi, dall’altra stupisce che invece le legislazioni
statali non abbiano inteso recepire queste direttive, nella legge italiana ed in quella americana
infatti non vi sono espliciti riferimenti a questo principio.
1
[http://www.w3.org/TR/WCAG10/#tech-identify-changes]
- 196 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Ed è un peccato, perché sono proprio le amministrazioni statali a dover fare il migliore uso di
questo principio. I contenuti dei loro siti sono, per loro stessa natura, esposti alla consultazione
di un gran numero di cittadini.
Per questo i numerosi enti statali che possiedono un sito dovrebbero essere i primi a mettere
in atto i principi di una lettura chiara e comprensibile delle informazioni.
Il linguaggio spesso oscuro della burocrazia è però il linguaggio comune delle amministrazioni
pubbliche, un linguaggio che deve assolutamente cambiare avvicinandosi alle espressioni della
lingua usata dagli utenti, senza per questo perdere la necessaria precisione ed il necessario
rigore formale.
A tal proposito, lo stesso Ministero della funzione pubblica ha emanato una direttiva per
contribuire alla semplificazione del linguaggio usato dalle pubbliche amministrazioni per la
redazione dei loro testi scritti.
La direttiva è datata 8 Maggio 2002 firmata dall’allora Ministro per la funzione pubblica Franco
Frattini, precede quindi di gran lunga la stessa legge Stanca.
Nelle pagine della direttiva sono presenti dei suggerimenti sia per lo stile da tenere nella
redazione dei documenti che per il modo di organizzare la comunicazione.
La direttiva del ministero sulla semplificazione del linguaggio dei testi amministrativi è
articolata in 20 punti suddivisi in 2 sezioni: ne riporto i principi. Gli esempi molto illuminanti e
le necessarie spiegazioni possono essere letti consultando il testo integrale1 disponibile sulle
pagine del ministero:
Le regole di comunicazione e di struttura giuridica:
1. Avere (e rendere) sempre chiaro il contenuto del testo;
2. Individuare sempre il destinatario;
3. Individuare le singole informazioni e inserirle nel testo in modo logico;
4. Individuare e indicare i contenuti giuridici del testo;
5. Individuare la struttura giuridica più efficace per comunicare gli atti;
6. Verificare la completezza delle informazioni;
7. Verificare la correttezza delle informazioni;
8. Verificare la semplicità del testo;
9. Usare note, allegati e tabelle per alleggerire il testo;
10. Rileggere sempre i testi scritti;
Le regole di scrittura del testo:
1
[www.funzionepubblica.it/chiaro/direttiva.pdf]
- 197 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
1. Scrivere frasi brevi;
2. Usare parole del linguaggio comune;
3. Usare pochi termini tecnici e spiegarli;
4. Usare poco abbreviazioni e sigle;
5. Usare verbi nella forma attiva e affermativa;
6. Legare le parole e le frasi in modo breve e chiaro;
7. Usare in maniera coerente le maiuscole, le minuscole e la punteggiatura;
8. Evitare neologismi, parole straniere e latinismi;
9. Uso del congiuntivo;
10. Usare in maniera corretta le possibilità di composizione grafica del testo;
Come si vede i principi sono chiari ed auto-esplicativi. Un testo ben fatto, che sorprende per
essere stato redatto da un Ministero italiano. Ancora più significativi e illuminanti sono gli
esempi riportati nel documento di cui consiglio caldamente la lettura per chi è interessato alla
materia.
III.12 - Riadattamento a posteriori
Come accennato, le considerazioni esposte sul tema dell’accessibilità sono sopravvenute a
seguito della diffusione a largo raggio di un cattivo stile di programmazione che ha reso del
tutto inaccessibili parecchi dei contenuti disponibili sul Web.
Di conseguenza, la considerazione del problema dell’accessibilità nello sviluppo del proprio sito
Web è intervenuta, per molti sviluppatori, a progetto già avanzato se non del tutto concluso.
Molti siti sono stati pubblicati ignorando completamente questa fondamentale chiave di lettura.
La gravità di questa inaccessibilità è molto differente a seconda delle varie realizzazioni e del
fatto che siano stati o meno utilizzati gli standard raccomandati come XHTML e i CSS.
Anche per questo il problema del riadattamento a posteriori dei siti Web già esistenti e non
accessibili (per questa operazione in letteratura viene spesso utilizzato il termine inglese
retrofitting) potrebbe essere spesso piuttosto oneroso e complesso da portare a termine.
Spesso più costoso che non preparare un sito accessibile dal nulla1.
Su quest’argomento esiste un apposto documento del W3C, che come al solito, rappresenta lo
standard in materia.
1
Joe Clark: “Accessibility generally is easy, as access advocates claim – for new pages, at least. And it is a
lot of work to fix up old pages, as developers claim.”.
- 198 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Questo documento ha una prima versione di bozza1 del 7 ottobre 2004, ed è arrivato al suo
attuale sviluppo in un documento2 più completo “Improving the Accessibility of Your Web Site”.
Il documento offre una linea guida per rimuovere le barriere di inaccessibilità presenti nei siti
esistenti suggerendo la procedura più efficiente e concreta e fornisce linee guida per:
Chiarire il problema;
Pianificare un progetto di riadattamento, identificando le barriere e le priorità degli
aggiustamenti da compiere;
Correggere gli errori in maniera efficiente e concreta;
Guidare ai passi successivi dopo il primo riadattamento del sito.
Il documento è strutturato in alcuni punti cardine.
Per iniziare:
o
Nozioni basilari;
o
Scegliere l’obiettivo;
o
Informare sullo stato del progetto di riadattamento;
Valutazione del problema;
Ottimizzazione del riadattamento:
o
Ottimizzazione delle conoscenze e delle capacità;
o
Ottimizzazione del processo;
o
Ottimizzazione degli strumenti;
Dare una priorità alle correzioni:
o
Priorità degli impedimenti all’accesso;
o
Priorità delle aree d’intervento;
Piano strategico conclusivo.
Ho riportato questa breve sintesi strutturale tradotta in maniera essenziale per dare un’idea di
che cosa può voler dire una strategia di riadattamento a posteriori, soprattutto per quanto
riguarda delle grosse aziende.
Un piano del genere può essere veramente dispendioso per delle grosse società e non stupisce
che molte delle pagine esistenti siano rimaste, a tutt’oggi, inaccessibili.
Per questi motivi molti autori non spingono più di tanto sull’adattamento a posteriori ad ogni
costo.
1
2
[http://www.w3.org/WAI/EO/Drafts/retrofit/Overview-7-October-2004.html]
[http://www.w3.org/WAI/EO/Drafts/retrofit/Overview.html]
- 199 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Da parte di privati o piccoli enti il processo è meno drastico e può risultare più adattabile e
meno dispendioso.
Ad ogni modo,anche nei casi peggiori, è solo un fatto di dispendio di risorse, non di infattibilità1
del processo.
A tale proposito vale la pena ricordare che esistono dei termini di legge ben precise.
Per quanto riguarda le norme americane, esse dispongono che le vecchie pagine degli enti
federali possano rimanere non aggiornate e potenzialmente inaccessibili fin quando non
vengano toccate. Ad ogni modo se una vecchia pagina viene aggiornata o alterata in un modo
qualunque, non importa se poco o tanto, deve essere fornita una accessibilità completa. Senza
contare che una pagina deve essere aggiornata su richiesta ragionevole di un utente.2
In Italia qualcosa di analogo viene previsto con la legge 04/2004 ed il correlato decreto
ministeriale del 8/Luglio/2005.
Innanzi tutto, gli obblighi sono a carico, a grandi linee, solo delle pubbliche amministrazioni,
come vedremo più accuratamente nella sezione dedicata alla legge.
Questi soggetti non possono stipulare, a pena di nullità, contratti per la realizzazione e la
modifica di siti internet quando non è previsto che essi rispettino i requisiti di accessibilità
stabiliti dal decreto.
I contratti in essere alla data d’entrata in vigore del decreto, in caso di rinnovo o modifica,
sono adeguati, a pena di nullità, alle disposizioni della legge circa il rispetto dei requisiti di
accessibilità, con l'obiettivo di realizzare tale adeguamento entro dodici mesi dalla data di
entrata in vigore del medesimo decreto. Data che è abbondantemente trascorsa al momento di
redigere questa tesi.
Tuttavia questo vale solo in caso di rinnovo o modifica. Ovviamente risulta piuttosto assurdo
che un sito Web di una pubblica amministrazione non venga modificato per un tempo così
lungo.
III.13 - Compatibilità con le tecnologie obsolete
La normativa italiana, al primo fondamentale requisito del decreto ministeriale del
8/luglio/2005 chiede: “Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie
1
Joe Clark: “It is not impossible to retrofit even many thousands of old pages, no matter what anyone tells
you; it is merely expensive to do so. If you’ve got the money, do it.”
2
Joe Clark: “Old pages may remain unappraised and potentially inaccessible as long as they are untouched.
But if an old page is updated or altered in any way, no matter how minor, full-on accessibility must be
provided. Also, a page must be upgraded on reasonable request from a visitor”, “Building Accessible
websites” - chapter 14.
- 200 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
definite da grammatiche formali pubblicate, nelle versioni più recenti disponibili quando sono
supportate dai programmi utente.”
Allo stesso modo le WCAG 1.0 al punto 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.”
In entrambe i casi, l’utilizzo delle versioni più recenti delle tecnologie e delle grammatiche
formali è raccomandato in relazione al fatto esse vengano supportate dai programmi utente.
La richiesta di aggiornare le tecniche quando possibile è chiara, meno evidente è la prassi da
adottare durante la fase intermedia, durante la quale alcuni programmi utente obsoleti, come
ad esempio vecchi browser, sono ancora in utilizzo.
Retro-compatiblità
In effetti, gli approcci suggeriti per questo problema sono abbastanza disparati.
Durante il periodo dello sviluppo disorganizzato del Web si è assistito ad un proliferare di
soluzioni ad hoc per adattarsi alle incompatibilità dei vari browser più datati, tra cui le
generazioni 4 di Microsoft Internet Explorer e di Netscape. Per seguire le loro interpretazioni
non standard del codice HTML sono spesso stati escogitati dei trucchi e delle soluzioni molto
poco eleganti.
Per fortuna le tendenze attuali sono quelle di mirare ad una più completa standardizzazione e
compatibilità.
Il vantaggio principale di questa conformità con gli standard è la realizzazione del progetto di
massima “Write Once, Read Anywhere”.
Invece di produrre del codice differente per tutte le possibili versioni della pagina (Netscape,
Internet Explorer, su Windows o Macintosh), si scrive la pagina in modo definitivo in accordo
con le specifiche, e di conseguenza ogni dispositivo dovrebbe essere in grado di visualizzare la
pagina correttamente, anche se con delle discrepanze tollerate. Resteranno ovviamente delle
specifiche differenze come ad esempio l’aspetto dei caratteri, e tuttavia la progettazione
dovrebbe essere sufficientemente flessibile da non rendere il contenuto inaccessibile ad alcun
programma utente.
Molti autori, tra cui Joe Clark1, consigliano un approccio abbastanza determinato nel problema.
Il suggerimento è di evitare di scrivere codice concepito appositamente per browser datati
come Netscape 4, di non impiegare elementi proprietari deprecati del linguaggio e, in genere,
1
[http://joeclark.org/book/sashay/serialization/Chapter05.html]
- 201 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
di scordarsi di tutto quello che non appartiene alle specifiche ufficiali.1
La decisione presa nel passato dagli sviluppatori di adattare il codice sugli arbitrii dei browser
non compatibili, ha permesso fino a poco tempo fa la proliferazione di queste tecniche
scorrette. Molti browser ai giorni d’oggi hanno una modalità definita proprio di capriccio
(quirk), in cui entrano al momento di riconoscere un codice HTML scorretto sintatticamente,
che tentano di interpretare in qualche modo.
Per fortuna la qualità dei programmi utente si sta evolvendo verso una pulizia migliore e sono
disponibili un numero sufficiente di browser con ragionevoli conformità agli standard da poter
progettare delle pagine pienamente compatibili.
Il primo problema che però viene alla mente è che cosa possono fare le persone che hanno
ancora in uso applicativi come Netscape 4 o vecchi browser che non sono adattati alle norme.
La questione formale è se dovrebbero essere considerati o no come una minoranza di utenti
svantaggiati che sono messi in condizione di handicap per via delle loro apparecchiature
obsolete.
Il paragone, apparentemente possibile, con utenti disabili dotati di tecnologia assistiva, non è
in realtà applicabile: Netscape 4 e browser obsoleti giocano un ruolo alquanto distruttivo nei
confronti degli standard, mentre le tecnologie accessibili sono progettate per adattarvisi.
Gli sviluppatori ed i progettisti non sono i soli a dover farsi carico dell’accessibilità, gli utenti
devono dotarsi delle apparecchiature adatte e funzionali, e soprattutto è compito dei progettisti
dei programmi utente sviluppare dei prodotti che rappresentino al meglio gli standard proposti
dal W3C adeguandosi al meglio alle linee guida UAAG (User Agent Accessibility Guidelines).
Da questo punto di vista, quando una tecnologia adattativa come uno screen-reader ignora o
interpreta scorrettamente degli elementi HTML standard, i progettisti del sito possono
considerare ragionevolmente di aver svolto il loro compito. E’ opinione, a mio avviso corretta,
di Joe Clark che non sia sensato chiedere agli sviluppatori e ai progettisti di occuparsi anche di
questo problema. Adattarvisi ad ogni costo andrebbe a discapito degli standard.
Aderenza agli standard
E’ sicuramente un problema minore il fatto che utenti con apparecchiature non conformi
accedano male al Web piuttosto che fare un passo indietro nell’adozione degli standard e
creare problemi a tutti gli altri.
1
Joe Clark: “Forget about coding special workarounds for Netscape 4. Forget MARQUEE and other
nonstandard HTML tags embraced and extended by Microsoft or “innovated” by Netscape. Forget anything
that isn’t in the spec.”
- 202 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Anche nel seminario1 tenuto ad Arese da Roberto Scano e Luca Mascaro, si è affrontato
indirettamente questo punto.
I docenti hanno evidenziato come la questione sia piuttosto delicata, si tratta di adottare il
buon senso nello scegliere se e quando forzare l’utilizzo delle nuove tecnologie, stimolando
sicuramente in tal caso il ricambio naturale degli user agent ma finendo inevitabilmente per
tagliare fuori una minima parte di utilizzatori. Un esempio classico in questi anni è quello della
compatibilità all’indietro con i vecchi browser Explorer e Netscape 4 per quanto riguarda i fogli
di stile nei riguardi dei quali questi programmi hanno delle grosse deficienze.
Anche in questa sede è stata fatta presente la circostanza che in mancanza di una stimolazione
di questo tipo si rischia di restare al palo con tecnologie obsolete che verranno aggiornate con
molta lentezza.
Mio personale convincimento è che l’obiettivo a cui puntare sia la massima aderenza agli
standard, il sacrificio di browser datati è necessario e persino da augurarsi giacché programmi
utente migliori, aggiornati e compatibili come Firefox ed Opera, sono reperibili gratuitamente e
per di più con bassi requisititi di sistema.
Anche browser testuali, come Lynx, hanno subito l’evoluzione necessaria per potersi adattare
agli standard W3C e nelle loro ultime versioni, possono essere impiegati con soddisfazione per
leggere del codice accessibile2.
Vorrei chiudere questo argomento accennando alla attenzione rivolta a questo argomento dalle
WCAG 2.0. L’intero principio 4 (Robust) è dedicato all’argomento: “I contenuti devono essere
robusti per l’uso attuale e futuro.”.
L’approccio delle WCAG 2.0 è quello della definizione di una baseline.
Il concetto verrà esposto al meglio nella sezione dedicata, qui vale comunque la pena ricordare
che, proprio onde evitare un invecchiamento precoce delle nuove linee guida con lo sviluppo di
nuove tecnologie innovative, il gruppo di lavoro del W3C ha preferito definire una piattaforma
hardware e software a cui il progettista del sito Web si richiama per enunciare il livello di
accessibilità del proprio lavoro.
1
Seminaro IWA Arese, Maggio 2005: “Legge Stanca: dalla teoria alla realtà”
Joe Clark: “Ironically, these programs do a very admirable job of interpreting standard HTML. (Working
under severe limitations can force higher quality.) An accessible HTML page remains accessible for these
browsers.”
2
- 203 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
III.14 - Validazione e controllo
Nel corso della trattazione abbiamo visto diverse metodologie per arrivare a produrre un lavoro
di qualità. Quando ogni sforzo è stato fatto per creare o modificare pagine ad elevata
accessibilità, la necessaria fase conclusiva è quella di verificare i risultati ottenuti.
La raccomandazione proviene dallo stesso W3C ed è contenuta anche nell’appendice delle
WCAG 1.0.
In questo contesto si afferma che è necessario verificare l'accessibilità sia per mezzo di
strumenti automatici che tramite la revisione umana.
I metodi automatici sono generalmente più rapidi e convenienti ma non possono identificare
tutti i problemi di accessibilità. La revisione umana può aiutare a garantire la chiarezza del
linguaggio e una maggiore semplicità nella navigazione1.
Nella stessa appendice raccomanda di cominciare ad usare i metodi di validazione al più
presto, già nel primo stadio di sviluppo del progetto, visto che i problemi legati all'accessibilità
che siano identificati subito sono i più facili da correggere e da evitare.
La fase di controllo è di primaria importanza e non è per niente scontata o trascurabile, in
effetti, la valutazione dell’accessibilità può dar luogo a non pochi equivoci. Come fatto notare
non è possibile effettuarla con soli strumenti automatici e richiede la competenza di
persone esperte. Questo dal momento che un programma di controllo può, ad esempio,
verificare la presenza degli elementi e degli attributi richiesti, ma non può certamente
qualificare il loro contenuto.
Metodologia di verifica
I passi da compiere sono quelli descritti nei documenti ufficiali del W3C, la sezione2 in
appendice A delle WCAG da un elenco di procedure, riprese in parte dalla legge Stanca.
Di seguito riporto l’elenco di alcuni importanti metodi di validazione, discussi in dettaglio nella
sezione3 del documento sulle tecniche di applicazione.
1. Usare uno strumento di accessibilità automatico. È necessario ricordare che i software
non risolvono tutti i problemi di accessibilità, come il reale significato del testo
alternativo dei collegamenti, l'applicabilità di un equivalente testuale, eccetera;
2. Validare la sintassi (per esempio, HTML, XML, eccetera.);
1
“Validate accessibility with automatic tools and human review. Automated methods are generally rapid and
convenient but cannot identify all accessibility issues. Human review can help ensure clarity of language and
ease of navigation.” – [http://www.w3.org/TR/WCAG10/#validation]
2
[http://www.w3.org/TR/WCAG10/#validation]
3
[http://www.w3.org/TR/WAI-WEBCONTENT-TECHS#validation]
- 204 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
3. Validare i fogli di stile CSS;
4. Utilizzare browser o emulatori solo testuali;
5. Utilizzare differenti browser grafici:
Con suoni e grafici caricati;
Con grafici non caricati;
Con suoni non caricati;
Senza mouse;
Con frame, script, fogli di stile e applet non caricati;
6. Utilizzare diversi browser, vecchi e nuovi;
7. Utilizzare un browser vocale, un lettore dello schermo (screen-reader), un software di
ingrandimento di aree dello schermo (screen-magnifier), un display piccolo, eccetera;
8. Utilizzare controlli automatici di sintassi e grammatica. Una persona che legga una
pagina con un sintetizzatore vocale può non essere in grado di decifrare una parola
contenente errori di sintassi: eliminando i problemi grammaticali, si migliora
sicuramente la comprensione dei contenuti;
9. Rivedere la chiarezza e la semplicità del documento. Statistiche di leggibilità, come
quelle generate da alcuni editor di testi, possono essere degli utili indicatori. È altresì
consigliabile chiedere ad un esperto di gestione dei contenuti (content manager) di
valutare il testo, in modo che possa revisionarlo per verificarne la chiarezza. I content
manager e gli esperti di usabilità possono migliorare anche l'usabilità dei documenti,
identificando problemi culturali potenzialmente rilevanti che potrebbero sorgere a causa
del linguaggio o delle icone utilizzate;
10. Invitare persone con una disabilità a revisionare i documenti. Utenti disabili esperti e
principianti forniranno un valido ritorno di informazioni sui problemi di accessibilità,
usabilità e sulle difficoltà incontrate.
Questi suggerimenti sono divisi in tre grandi blocchi di analisi:
1-3: Verifica del codice (X)HTML e CSS per mezzo di strumenti automatici. Viene
comunque fatto presente che i validatori automatici non sono in grado di controllare il
significato dei contenuti e non possono portare a termine una analisi esaustiva;
4-7: I punti centrali riguardano controlli di fruibilità dei contenuti sotto diversi condizioni
di accesso: con un browser testuale, con un emulatore di terminale, con differenti tipi di
browser grafico, con browser vecchi e nuovi, con le immagini e senza immagini, con i
suoni e senza i suoni, con il mouse e senza mouse, con il supporto per frame, linguaggi
di script, fogli di stile e applet java disabilitato, con un browser vocale, con uno screen
reader, con un ingranditore di schermo, con un monitor molto piccolo, eccetera;
8-10: Gli ultimi tre punti riguardano infine gli aspetti dell'accessibilità più vicini
all’usabilità e alla capacità di comprensione del contenuto. Anche per questi controlli si
- 205 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
suggerisce il ricorso a strumenti automatici: per esempio un correttore ortografico, per
trovare ed eliminare i refusi dal testo, e un valutatore di leggibilità. Si consiglia anche
esplicitamente di ricorrere al giudizio di revisori umani e in particolare di persone con
disabilità: queste ultime, meglio di chiunque altro, potranno valutare se le misure prese
per favorire l'accessibilità siano sufficienti oppure no.
Per quanto riguarda i valutatori automatici, lo stesso W3C propone una pagina completa1 di
strumenti di controllo a cui si può fare riferimento come utile supporto alla verifica. Parleremo
più avanti di alcune di queste applicazioni.
La legge Stanca propone nell’allegato A, comma 2 del decreto ministeriale del 8 Luglio 2005
una propria metodologia di verifica tecnica che non si discosta molto da queste linee guida.
Questa fa ricorso a:
Strumenti automatici, tra gli altri si ricorda il servizio di validazione del W3C;
Strumenti semiautomatici, onde evidenziare problemi non riscontrabili dalle verifiche
automatiche, anche qui si rimanda alla pagina degli strumenti di controllo del W3C;
Conoscenze dell'esperto tecnico sull'uso degli elementi e degli attributi secondo le
specifiche del linguaggio.
In particolare si suggerisce:
L’esame della pagina con diversi browser grafici, in differenti versioni e in diversi
sistemi operativi;
Il controllo del contrasto del colore;
L’esame della pagina con browser testuali.
Il testo dettagliato del decreto ministeriale è riportato in appendice di questo lavoro.
Dopo aver esposto le linee guida della verifica tecnica vorrei passare ad un’esemplificazione del
metodo per dare un’idea di come si possa svolgere un buon lavoro di verifica.
Validazione (X)HTML e CSS.
Il primo passo da compiere è quello di controllare la correttezza del documento. In particolare,
per i documenti XHTML, sottoclassi di documenti XML, la correttezza formale si svolge in due
passi:
1
[http://www.w3.org/WAI/ut3/ER/existingtools.html]
- 206 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Controllo che il documento XHTML sia ben formato:
cioè che sia conforme alle regole generali di un linguaggio XML, quindi abbia ad
esempio gli elementi annidati correttamente, tutti i marcatori chiusi e scritti in
minuscolo, i doppi apici sui valori degli attributi, eccetera;
Controllo che il documento XHTML sia valido:
cioè che abbia una dichiarazione di grammatica formale in testa, una DTD (Document
Type Definition) e che il resto del contenuti ne rispetti i vincoli sintattici definiti.
La caratteristica di documento valido si affianca a quella di documento ben formato per
costruire documenti XHTML adatti ad essere elaborati automaticamente.
C'è da sottolineare che un documento ben formato può non essere valido rispetto ad una
grammatica, mentre un documento valido è necessariamente ben formato. Tra l'altro, un
documento valido per una grammatica può non essere valido per un'altra grammatica.
Questo passo formale può facilmente essere espletato in maniera automatica con uno dei tanti
validatori del linguaggio che contemporaneamente ne verificano anche la buona formattazione.
Il consiglio è di usare quello ufficiale1 del W3C che è più che sufficiente per gli scopi di una
corretta validazione.
Allo stesso modo, se la pagina XHTML contiene un riferimento ad un foglio di stile, e per
quanto detto fino ad ora dovrebbe proprio contenerlo, è possibile eseguire una verifica
sintattica anche del CSS, direttamente con gli strumenti del W3C appena indicati.
Il CSS può essere anche controllato separatamente con un altro strumento 2 di validazione
apposito, sempre fornito dal W3C.
Questi strumenti ufficiali sono affiancati da una numerosa mole di validatori spesso totalmente
gratuiti, come ad esempio anche il CSSCheck3 del WDG.
Non è una cattiva idea quella di sottoporre il documento anche ad altri analizzatori, pur avendo
avuto una conferma di valutazione anche da quelli ufficiali.
In particolar modo la barra di accessibilità4 contiene numerosi strumenti di valutazione tra cui
Torquemada e WebExact e rappresenta una valida suite di strumenti. Di questi parleremo più
approfonditamente in seguito.
1
2
3
4
[http://validator.w3.org/]
[http://jigsaw.w3.org/css-validator/]
[http://www.htmlhelp.com/tools/csscheck/]
[http://www.webaccessibile.org/wat/WAT_IT_1-2.exe]
- 207 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Griglia di valutazione
Una volta portato a termine questo passo formale e totalmente automatizzabile si passa
nell’ambito della verifica di stretta accessibilità e qui le cose incominciano a farsi più
complesse.
Innanzi tutto il progettista dovrebbe aver già utilizzato la griglia di controllo1 predisposta dal
W3C per la verifica manuale del codice prodotto. Se non lo avesse ancora fatto, questo è il
momento buono per stamparla e per procedere ad una verifica manuale delle singole voci.
Questo schema di validazione riporta i punti di controllo delle WCAG, suddivisi per priorità con
a lato delle caselle di spunta per riportare lo stato della verifica manuale.
La griglia è reperibile sul sito del W3C e ne esistono anche delle traduzioni 2 in italiano.
Questo può essere un ottimo lavoro di controllo, se svolto in maniera accurata può garantire
da solo il raggiungimento di un’elevata accessibilità dei contenuti prodotti.
Un'altra utile applicazione di queste griglie di controllo trova applicazione nell’analisi che può
essere condotta da un esperto interno di una società che commissioni all’esterno un sito ad
elevata accessibilità.
In questo caso, infatti, è il committente che può controllare direttamente i risultati del prodotto
fornito, purché però possa contare al proprio interno su personale sufficientemente qualificato.
Una persona mediamente competente in informatica, con in mano la griglia di valutazione, è in
grado di smascherare evidenti azioni truffaldine ai danni dell’ente.
Validatori automatici
In questa sezione vorrei fare una breve panoramica dei più importanti strumenti di controllo e
di validazione.
Non è mia intenzione entrare nel merito e nello specifico di ogni programma, la cosa
richiederebbe spazio e competenze che non sono a mia disposizione. Il materiale consultabile
di riferimento disponibile consente di approfondire ogni singolo applicativo secondo le
preferenze dell’utente.
Si tratta di applicativi utilizzabili liberamente in rete, in genere accettano in ingresso l’indirizzo
internet di una pagina e forniscono in uscita una lista di informazioni tra cui:
1
2
La riga o le righe contenenti errori o avvisi;
L'identificazione della segnalazione;
Il codice di marcatura dell'elemento contenente errori o avvisi;
[http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/full-checklist]
[http://www.robertoscano.info/files/wcag10/full-checklist.html]
- 208 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L'annotazione della tipologia per errori o avvisi.
Il riferimento alla normativa di accessibilità violata;
Eventuali suggerimenti per ripristinare una informazione accessibile.
Alcuni tra questi programmi, al riconoscimento di un avvenuto raggiungimento di accessibilità
permettono di usare loghi personalizzati come certificazione mentre altri preferiscono non
rendere disponibili loghi di conformità.
Tali validatori sono sicuramente d’indubbia utilità, ma non possono completare l’analisi da
soli in maniera automatica, come ribadisce accuratamente anche il W3C nel suo sito
ufficiale1.
I problemi che questi valutatori automatici portano con se per la loro stessa natura sono
diversi, tra cui, solo per citare alcuni evidenti esempi:
Incapacità di valutare tutti gli oggetti presenti in una pagina che non siano il codice
(X)HTML o CSS, questo vale ad esempio per JavaScripit, animazioni, PDF;
Impossibilità di analizzare automaticamente tutti i punti di controllo. Alcune linee guida
richiedono chiaramente un giudizio da parte del valutatore: identificare se il linguaggio
utilizzato sia chiaro e semplice oppure se sono presenti degli opportuni menu di
navigazione sono due esempi di requisiti non verificabili automaticamente;
Incapacità di valutare la correttezza e la funzionalità di un testo, un esempio sono i
contenuti dei testi alternativi;
Incapacità di discriminare tra una tabella d’impaginazione ed una tabella di dati, questo
non permette loro di rilevare un utilizzo inaccessibile delle tabelle dati a scopo di
impaginazione.
Da queste ed altre osservazioni si ribadisce la necessità vincolante di aggiungere alla loro
analisi quella di un tecnico professionale.
W3C Validator
Il W3C validator2 è il validatore ufficiale del Consorzio World Wide Web.
Si tratta, in effetti, di un analizzatore sintattico arricchito con alcune norme basilari
sull’accessibilità.
1
“There is as yet no tool that can perform a completely automatic assessment on the checkpoints in the
guidelines, and fully automatic testing may remain difficult or impossible.” –
[http://www.w3.org/WAI/WCAG1-Conformance.html]
2
[http://validator.w3.org/]
- 209 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Ne consegue che i risultati prodotti, per quanto possano definire in maniera esatta la validità
del codice prodotto, non possono comunque garantire il raggiungimento di qualità necessaria,
cosa per altro valida per tutti gli altri validatori automatici.
Purtroppo il valutatore W3C è in grado di controllare esclusivamente la sintassi, non può
assolutamente intervenire sul contenuto delle informazioni inserite. Non controllando il valore
degli attributi, valida senza incertezze anche espressioni del tipo:
Xml:lang=”Klingoon”
Ad ogni modo è un valido esaminatore del testo e può essere usato con profitto per una prima
scrematura automatica. Consente l’esposizione del bollino ufficiale del W3C, che si ricorda, è
una certificazione sulla validità sintattica (X)HTML e CSS, non sull’accessibilità.
La barra di accessibilità
Un strumento fondamentale per la valutazione è la barra di accessibilità1 del WAT-C2 (Web
Accessibility Tool Consortium).
Si tratta di un applicativo che può essere installato su Microsoft Internet Explorer e che
aggiunge al browser una barra contenente numerosi strumenti di analisi.
Il suo servizio integra molteplici funzionalità, tra le altre:
Validatori (X)HTML e CSS della sintassi della pagina e dei fogli di stile;
Ridimensionamento dello schermo per i test di visualizzazione su risoluzioni differenti;
Analisi dei fogli di stile con, attivazione, disattivazione, e controllo;
Analisi delle immagini con controllo e visualizzazione dei testi alternativi;
Test dei colori con richiamo al Color Contrast Analyzer e simulazioni per cecità parziale
ai colori;
Analisi della struttura del documento per controllare: HEADER, LIST, LABEL, BLOCKQUOTE, Q,
JAVASCRIPT, ACCESSKEY, TABINDEX, TABLE, DIV, FRAME, TITLE, LANG e numerosi altri oggetti;
Strumenti di analisi dell’accessibilità come Torquemada, Juicy Studio, WebExact, Lynx,
AccMonitor;
Informazioni sulla pagina come statistiche e metadati;
Listato del codice originale con gli attributi deprecati ed un analizzatore DOM.
Lo strumento è parecchio completo e del tutto gratuito, vale certamente la pena di conoscerlo
e di impiegarlo, l’unico problema è che è disponibile solamente per Opera e per Internet
1
2
[http://www.webaccessibile.org/wat/WAT_IT_1-2.exe]
[http://www.wat-c.org/tools/index.html]
- 210 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Explorer sotto Windows. Personalmente ho riscontrato dei problemi a seguito della sua
installazione sulla versione 7.0 di Explorer.
HTML Tidy
Un primo validatore elementare di codice (X)HTML è HTML Tidy1, originalmente sviluppato da
Dave Ragget ed ora passato ad un gruppo di Surce Forge.
Il progetto originario è quello non tanto di un validatore, piuttosto di un correttore di codice
che permetta di ripulire la sintassi scorretta del linguaggio (X)HTML.
Tidy, infatti, è in grado di produrre in uscita un codice sintatticamente corretto cercando di
ripulire il formato originario secondo le specifiche del W3C.
Anche per questo nella barra di accessibilità viene inserito insieme ad i validatori del W3C e
presentato come elemento di controllo/riparazione del codice.
Nella pagina ufficiale di presentazione del prodotto si definiscono i suoi intenti, da queste note
ho tratto alcune delle successive considerazioni.
Nell’editare una pagina HTML è facile commettere degli errori, sarebbe comodo avere a
disposizione una maniera semplice per correggere questi errori automaticamente in un codice
pulito. Tidy è un programma d’utilità non a pagamento in grado di lavorare anche con codice
parecchio scorretto, generato da editor visuali HTML e da strumenti di conversione particolari.
E’ in grado anche di segnalare dove è il caso di porre maggiore attenzione ai problemi
d’accessibilità per le persone disabili.
Tidy è in grado di correggere un ampio raggio di problemi e di mettere in evidenza i punti in
cui è necessario l’intervento del programmatore. Ogni elemento viene elencato completo di
riga e colonna in modo che vi si possa accedere poi facilmente da un qualunque editor
(X)HTML.
Tidy non genera una versione ripulita del codice se vi sono stati riscontrati dei problemi che il
programma non è in grado di trattare correttamente. Questi vengono segnalati come errori,
piuttosto che come avvertimenti nella pagina.
Color Contrast Analyzer
Il Colour Contrast Analyzer, è uno strumento richiamato anche dalla barra di accessibilità. E’
disponibile sul sito2 del Juicy Studio nella sua più recente versione 1.1.
Si tratta essenzialmente di uno strumento per testare le combinazioni di colore di sfondo in
relazione a quelle di primo piano, allo scopo di determinare se sono in grado di fornire un buon
1
2
[http://www.w3.org/People/Raggett/tidy/]
[http://juicystudio.com/services/colourcontrast.php]
- 211 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
livello di visibilità. Inoltre sono previste funzionalità per creare delle simulazioni di alcune
tipiche condizioni legate alla cecità dei colori.
La versione 1.0 si basa sull’algoritmo di controllo presente nelle WCAG 1.0 e nella legge Stanca
con tutti i limiti discussi nella sezione relativa all’uso del colore.
I nuovi algoritmi proposti dal WCAG 2.0 e le nuove funzionalità sono state integrate nella
versione 1.1, disponibile anche in italiano sul sito segnalato e su quello di WebAccessibile1.
WatchFire
Bobby, della WatchFire si trova spesso come uno degli strumenti di controllo più citati
soprattutto nei testi di qualche anno fa.
Recentemente è stato affiancato e sostituito in rete da WebExact2 che è anche integrato nella
barra di accessibilità.
L’utilizzo è semplice, passando in rete l’indirizzo la pagina Web al validatore. Forse è
leggermente più lento degli altri nell’analisi del codice.
Al termine della fase di valutazione, vengono proposte quattro differenti cartelle contenenti
analisi dettagliate:
Generale: Un riepilogo complessivo dell'analisi effettuata contenente le dimensioni del
documento, un elenco dei metadati e un sunto degli elementi contenuti all'interno della
pagina;
Qualità: Questa funzionalità riporta l’efficienza e la compatibilità della pagina con i vari
browser, oltre che il numero di collegamenti presenti nella pagina;
Accessibilità: Un report tabellare piuttosto accurato dei tutti i punti di controllo ordinati
per priorità, consente di selezionare ed estendere l'analisi al singolo errore con la
visualizzazione della riga. Il report presenta avvisi ed errori in senso stretto. Ogni punto
di controllo ha un collegamento ad una pagina del sito di WebXACT contenente
dettagliate informazioni tecniche utili alla valutazione;
Privacy: Il modulo privacy effettua il controllo sull'eventuale presenza della
dichiarazione P3P e di eventuali pagine contenenti moduli di invio dati.
E’ un programma piuttosto completo e riporta una valutazione attenta dell’errore corredandola
con tutte le informazioni del caso e con gli opportuni suggerimenti per la correzione. Come
accennato ha forse come unica pecca una leggera lentezza, per altro di nessun ostacolo alla
validazione.
1
2
[http://www.webaccessibile.org/argomenti/argomento.asp?cat=593]
[http://webxact.watchfire.com/]
- 212 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Cynthia Says
Cynthia Says è sviluppato utilizzando il sistema HiSoftware AccMonitor integrato, a seguito di
registrazione, sulla barra di accessibilità ed esiste in diverse versioni. Una, del tutto gratuita si
trova anche in rete1 e si possono direttamente sottoporre i documenti, per quanto solo a
pagina singola.
Nei criteri di valutazione si può scegliere quali normative di riferimento consultare e viene
prodotto un report considerando eventualmente anche dei messaggi di avviso, oltre che di
errore.
Il sistema è efficiente e piuttosto veloce, ha il vantaggio di produrre come risultato un report in
forma tabellare simile alla griglia di controllo delle WCAG 1.0. Per questo il report può risultare
molto utile per la presentazione dell'analisi di accessibilità sviluppata in concomitanza con uno
studio sulla griglia di controllo.
Il programma non effettua i controlli che ritiene non applicabili o che non riesce ad eseguire
sulla pagina, lasciando all'utente l'onere di valutare i punti di controllo non identificabili
dall'applicazione.
Si richiede una competenza media e una buona conoscenza dei punti di controllo delle WCAG
1.0.
Torquemada
Torquemada è sviluppato dall’iniziativa WebXtutti ed è disponibile sul sito 2 del gruppo. Non
esiste attualmente una versione scaricabile ed eseguibile non in linea per quanto essa sia
annunciata.
Come specificato sullo steso sito, il prodotto offre a chi sviluppa siti Web una metodologia
completa d’analisi dell'accessibilità tramite uno strumento di controllo delle pagine che
permette di capire velocemente quali siano le zone della pagina interessate dall'errore e il
codice HTML corrispondente.
Il sistema di analisi è molto preciso e dotato di un'interfaccia di visualizzazione degli errori
particolarmente chiara ed innovativa studiata per fornire, a richiesta, un report visuale che
permetta all'utente di capire immediatamente sia l'errore sia la sua importanza all'interno della
struttura della pagina.
Può presentare anche un report puramente testuale, in funzione delle direttive fornite
dell'utente.
1
2
[http://www.cynthiasays.com/Default.asp]
[http://www.webxtutti.it/testa.htm]
- 213 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Torquemada è gratuito, in italiano e molto facile da utilizzare.
Anche questo strumento di controllo è stato integrato nei menu degli strumenti della barra di
accessibilità.
Wave Accessibility Tool
Altro strumento integrato nel menù della barra di accessibilità è Wave Accessibility Tool1 del
WebAIM (Web Accessibility In Mind), una delle organizzazioni più attive nella diffusione e nello
sviluppo dei concetti dell’accessibilità, presente sul Web con molti articoli divulgativi.
All’interno del loro applicativo è possibile scegliere la modalità di valutazione del documento,
tra i vari parametri ci sono:
Le normative di riferimento;
Il livello di analisi
Gli elementi da sottoporre a controllo.
Un report grafico con un’evidenziazione speciale per gli elementi della pagina permette di
mettere in luce velocemente la struttura del codice (X)HTML.
Gli elementi visualizzati sono selezionabili dalla pagina di configurazione dello strumento.
Lynx
Piuttosto utile è anche la presenza nella barra di accessibilità di un richiamo a Lynx.
Lynx2 è un browser puramente testuale. Il report generato da quest’analisi è un testo semplice
linearizzato, senza immagini.
In coda viene aggiunta una lista dei collegamenti esterni del codice (X)HTML.
Al fine di poter valutare l'effettiva accessibilità per i lettori dello schermo, è sempre utile
accedere alla pagina Web con un browser testuale e visualizzarne i risultati.
Vi sono però delle serie limitazioni nell'uso degli elementi di una pagina come ad esempio per
quanto riguarda i campi moduli.
CNIPA
Vorrei concludere questa sezione sui validatori facendo un cenno anche al sistema di
validazione del CNIPA, per quanto esso non possa sicuramente essere considerato tra quelli
automatici.
1
2
[http://dev.wave.webaim.org/index.jsp]
[http://lynx.isc.org/current/]
- 214 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Tuttavia, allo stato attuale delle cose, il sistema di validazione del CNIPA risulta essere l’unico
ufficiale e l’unico i cui loghi non possano essere esposti previa autorizzazione ufficiale.
A differenza di tutti gli altri il CNIPA valuta il sito secondo la legge Stanca e consente
l’esposizione dei relativi bollini di controllo solo a pagamento, ed i costi non sono affatto
indifferenti, come dall’allegato1 F del decreto ministeriale del 8 Maggio 2005.
Questa valutazione non implica nulla a proposito delle WCAG e deve essere rinnovata almeno
annualmente.
Per ulteriori informazioni in materia si consulti la sezione dedicata alla legge Stanca di questo
lavoro.
La cultura del bollino
Il superamento delle valutazioni elencate permette in genere di apporre un bollino di
conformità relativo al valutatore applicato.
Va sottolineato che, a parte il bollino di controllo della validità sintattica del codice (X)HTML,
che ovviamente non richiede ulteriori controlli manuali, tutti gli altri programmi citano
esplicitamente anche la necessita di far esaminare la pagina da professionisti esperti e
da utenti disabili. Non solo, ma queste valutazioni, necessarie in ogni caso per l’apposizione del
bollino, non possono rappresentare in nessun modo un attestato ufficiale e restano
sottoposte alla responsabilità del singolo valutatore.
Un discorso a parte meritano invece i loghi di accessibilità rilasciati dal CNIPA. In tal caso
l’esposizione del bollino è sottoposta alla valutazione a pagamento del CNIPA e risulta come
certificazione ufficiale.
Purtroppo questa considerazione non viene messa nel dovuto risalto: e questo si ripercuote
negativamente sugli utenti, che hanno bisogno di vera accessibilità piuttosto che di bollini.
Negli anni trascorsi, quando l’accessibilità stava diventando un fenomeno di moda, molti siti
importanti esponevano dichiarazioni di conformità al massimo livello di accessibilità, valutata
con diversi strumenti automatici senza passare per i dovuti controlli di verifica soggettiva.
Spesso era sufficiente anche una rapida analisi da parte di un esperto per dimostrare del tutto
inesatte queste dichiarazioni.
Molti di questi atteggiamenti erano dovuti a superficialità, altri alla necessità di farsi
propaganda. Per fortuna si è assistito recentemente ad una riduzione di questi inutili attestati,
abbandonando soprattutto quelle dei validatori non ufficiali del W3C, in favore di una più
1
[http://www.pubbliaccesso.gov.it/normative/DM080705-F.htm]
- 215 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
corretta esposizione delle informazioni sull’accessibilità e sui sistemi impiegati per
ottenerla.
Le dichiarazioni di accessibilità sono esposte nei siti più qualificati e sono riassunte in una
pagina completa di informazioni sull’usabilità del sito, spesso accompagnata anche dall’elenco
degli ACCESSKEY implementati nel codice.
Queste sezioni hanno il grosso vantaggio di mostrare in dettaglio gli accorgimenti impiegati per
elevare il grado di accessibilità del sito senza esporre delle pretese assolute e scarsamente
documentabili.
Ci si augura che questa modalità più attenta di esprimere l’analisi compiuta nei confronti
dell’accessibilità prenda presto piede in luogo delle inutili fiere di bollini esposti in passato.
Conformità del W3C
Il W3C prevede che, al termine delle sue valutazioni sopra esposte, gli autori possono esporre
a loro discrezione, sulle pagine controllate, degli appositi bollini di conformità alle WCAG 1.0
seguendo le relative istruzioni1 fornite dal consorzio.
Figura 3 - Le tre icone di conformità WCAG 1.0
In alternativa possono essere incluse nel testo anche delle stringhe di significato analogo.
Come ricordato, queste dichiarazioni rappresentano semplicemente una pretesa di conformità
della pagina alle specifiche WCAG 1.0, ma non sono in nessun modo un attestato ufficiale di
accessibilità, che nessun ente o organizzazione è in grado di rilasciare sulle conformità del
W3C.
III.15 - I costi dell’accessibilità
Al termine di questa lunga esposizione sulle metodologie generali di programmazione per i siti
Web accessibili vorrei terminare con una piccola appendice che volutamente riprende il tema di
apertura di questo lavoro, e cioè la necessità di apprendere e di fare propria una nuova
filosofia progettuale e una nuova cultura nella realizzazione dei siti Web.
L’acquisizione di questa forma mentale, quella di un buon sviluppo, come si era detto
nell’introduzione, deve far parte della metodologia di lavoro di un professionista del Web.
1
[http://www.w3.org/WAI/WCAG1-Conformance.html]
- 216 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Con questa chiave di lettura ha sicuramente più senso interpretare una delle richieste che ha
suscitato un dibattito rilevante e che tuttora, nell’ambito della pubblica amministrazione,
costituisce probabilmente il maggior ostacolo alla diffusione di questo metodo, quella del
cosiddetto costo zero dell’accessibilità.
Mi rifaccio, in questo senso, alla legge 04/2004 che analizzeremo meglio in una parte dedicata.
In più punti questa normativa specifica che per la sua realizzazione non dovranno essere
impiegati stanziamenti ulteriori a carico della pubblica amministrazione.
Mi riferisco in particolar modo all’articolo 4 della legge1 stessa e all’articolo 4 del regolamento
d’attuazione2. Nel testo si ribadisce che la legge deve essere applicata in tutte le sue parti
senza costituire onere aggiuntivo per le pubbliche amministrazioni. inclusi gli importanti costi
di istruzione del personale.
Da più parti si è sentito dire che questo non è possibile, ed in effetti il concetto è controverso.
L’origine di questa lettura ha sia una motivazione pratica di applicabilità, che un principio
europeo, dal momento che il parere del Comitato Economico e Sociale della CE è che “attuare
le linee guida sull'accessibilità comporta, e oltretutto solo nella fase iniziale, costi non di molto
superiori a quelli che conseguirebbero alla loro mancata attuazione” come riportato nel
documento economico3 correlato alla citata Comunicazione CE del 25 Settembre 2001.
Questa disposizione ovviamente non richiede che non si debba spendere nulla per la
realizzazione dell’accessibilità, quanto piuttosto che debbano essere impiegati gli stanziamenti
ordinari già previsti in bilancio. In sostanza la legge prevede che quello che prima si spendeva
per realizzare applicazioni e siti Web dallo scarso valore qualitativo, ora dovrà essere utilizzato
per realizzare siti Web accessibili ed in grado di erogare servizi utili a tutti i cittadini.
Purtroppo invece queste limitazioni previste dalla legge sono state prese sovente come ultima
scappatoia per le pubbliche amministrazioni che non sono intenzionate a mettersi a norma.
E’ una lettura pretestuosa della legge, e tuttavia l’esperienza reale e le opinioni raccolte sul
campo hanno confermato come spesso si sia ricorso a questo pretesto per rinviarne all’infinito
l’attuazione.
1
“I datori di lavoro pubblici provvedono all'attuazione nell'ambito delle disponibilità di bilancio.”
“All’attuazione del presente articolo si provvede nell’ambito degli ordinari stanziamenti di bilancio, senza
nuovi o maggiori oneri per la finanza pubblica.”
3
[http://eur-lex.europa.eu/LexUriServ/site/it/oj/2002/c_094/c_09420020418it00090013.pdf]
2
- 217 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L’accessibilità come punto di partenza
Un interessante e recente articolo in merito è stato pubblicato da Roberto Castaldo su
WebAccessibile1.
L’articolo ha il pregio di porre l’accento sulla giusta chiave di lettura del problema, cioè quella
di considerare l’accessibilità non come un punto di arrivo da realizzare a costi nulli, ma come
un punto di partenza verso la creazione di una migliore qualità generale dei siti della pubblica
amministrazione e, di riflesso, anche del privato.
Lo spirito della legislazione vuole spingere tutte le Pubbliche amministrazione verso
l’erogazione di siti ed applicazioni Web di qualità. In quest’ottica l’aspetto legato
all’accessibilità ed alla fruibilità dei contenuti è solamente uno degli elementi da prendere in
considerazione; soprattutto alla luce di quanto poi richiesto anche dal Codice
dell’Amministrazione Digitale che esige siti accessibili da tutti, anche dai disabili, ma anche
reperibili, facilmente usabili, chiari nel linguaggio, affidabili, semplici, omogenei tra loro.
Si tratta di un’idea di qualità che inizialmente non può prescindere dall’accessibilità tecnica che
la legge Stanca richiede obbligatoriamente, ma che di certo non si esaurisce solo con essa.
Il legislatore ha giustamente considerato l’accessibilità come una condizione necessaria per il
conseguimento di un elevato livello qualitativo, ma non certo sufficiente, ed ha correttamente
iniziato a spingere le pubbliche amministrazioni verso un approccio finalizzato agli utilizzatori.
Creare un sito Web di qualità vuol dire pensare agli utenti, progettare e lavorare in team,
scrivere codice, testare a più riprese il lavoro fatto, prevedere e gestire le questioni legate alla
diffusione della conoscenza in azienda, concepire non solo i passi necessari all’implementazione
pratica ma anche quelli legati alla formazione dei tecnici e dei redattori.
Un’opera complessa per la quale servono professionisti in grado di affrontare problematiche
quasi mai banali, altrimenti la qualità sarà sempre e soltanto un concetto astratto ed
irrealizzabile.
Può sembrare strano che questo concetto in cui accessibilità vuol dire qualità si leghi a quello
del cosiddetto costo zero, ma in realtà tale associazione costringe ad una filosofia di fondo che
ha proprio questo tipo di risultato.
Costo zero
E’ evidente che un processo del genere non può svolgersi senza il contributo di personale
qualificato. Un intervento che non può essere privo di spese.
1
[http://www.webaccessibile.org/argomenti/argomento.asp?cat=622]
- 218 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Ed infatti, con la disposizione di legge non si intende certo che l’accessibilità dei siti Web della
Pubblica Amministrazione possa non costare nulla, dal momento che la costruzione di un sito
anche a livello amatoriale comporta una spesa. La legge prevede bensì che le pubbliche
amministrazioni debbano operare nell’ambito delle ordinarie disponibilità di bilancio.
La realtà è che le pubbliche amministrazioni che già sono presenti in rete non partono
certamente dal nulla, il loro bilancio già prevede un qualche stanziamento per il sito Web o per
il settore informatico.
Forse per le pubbliche amministrazioni che non hanno ancora un sito Web il problema degli
stanziamenti da mettere in bilancio si potrebbe porre in maniera un po’ più urgente, ma anche
qui è necessario fare chiarezza, con particolare riferimento al concetto di accessibilità e di
qualità di un’applicazione Web.
La pubblica amministrazione in Italia non può più permettersi di sperperare su progetti Web
privi di valore, ed il legislatore con la legge Stanca 4/2004 ed il Codice per l’Amministrazione
Digitale, vuole mettere in risalto proprio quest’aspetto, invitando, anzi obbligando, i dirigenti a
spendere meglio i soldi che già hanno a disposizione.
E’ un discorso che, come dipendente in un centro elaborazione dati comunale, mi sono trovato
più volte ad affrontare con i responsabili del servizio, trovando di fronte notevoli chiusure e
pregiudizi.
La legge Stanca deve forzare la pubblica amministrazione ad affidarsi a professionisti affidabili
e seri e ad ottimizzare gli stanziamenti ordinari, senza spendere altro di quanto non sia già
oggi già impiegato, spesso male.
A queste condizioni la migrazione a costo zero, cioè senza spendere poco o nulla in più di
quanto si spenda oggi, verso applicazioni Web fruibili da parte di ogni cittadino è non solo
moralmente auspicabile, ma anche finanziariamente non più rinviabile; è necessario che molti
dirigenti smettano di nascondersi dietro l’impunità o la non conoscenza delle norme legislative
che li riguardano direttamente come la legge 4/2004, e che imparino a spendere bene quello
che hanno a disposizione.
- 219 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
IV. Analisi delle normative
In questa sezione entriamo nel dettaglio delle quattro normative di riferimento, rileggendole
alla luce dei principi guida esposti nel capitolo precedente in cui è stato dato uno sguardo
d’insieme alle metodologie generali.
Va notato che le raccomandazioni WAI, in particolar modo le WCAG 1.0, sono specificatamente
mirate a fornire le linee guida per una buona realizzazione dei siti Web, mentre, al contrario,
sia la normativa americana che quella italiana sono molto più generiche ed ampliano il discorso
fino ad includere anche la trattazione dei requisiti hardware e software per le persone disabili.
Per quanto riguarda questa tesi, quindi, solamente un loro sottoinsieme verrà analizzato con
particolare attenzione.
Le normative sono riportate in ordine della loro prima pubblicazione.
Per le WCAG 2.0, al momento, non esiste ancora una Recommendation definitiva del W3C. Si è
scelto l’ultimo documento ufficiale, il Last Call Working Draft del 27 Aprile 2006.
In fase di presentazione ho ritenuto opportuno far notare la loro cronologia, l’enfasi su
quest’aspetto è dovuta alla possibilità di tracciare in questo modo un qualche sviluppo storico
nella percezione e nell’importanza data nel tempo al problema dell’accessibilità.
Al termine delle disamine segue un breve capitolo comparativo sulle funzionalità e sulle
direttive richieste delle quattro normative esaminate.
Conclude la sezione un breve accenno alle imminenti norme ISO e sulle altre direttive del WAI
riguardanti ulteriori importanti aspetti dell’accessibilità.
IV.1 - Normative internazionali
Il motore iniziale del progetto di sensibilizzazione delle normative nazionali ed internazionali in
tema di accessibilità dei siti Web è stato svolto sicuramente dalla pubblicazione delle WCAG 1.0
nel 1999.
Sulla scorta di questa raccomandazione del W3C sono state svolte numerose attività legislative
in cui l’Italia e gli Stati Uniti hanno primeggiato per efficienza e sensibilità.
Negli Stati Uniti la "Section 508 of the Rehabilitation Act" del 07/08/2001 propone 16 punti che
devono soddisfare i portali federali o con finanziamento pubblico finalizzati ad evitare la
discriminazione verso le persone disabili. Di questa normativa parleremo diffusamente in
seguito
- 220 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In Europa è stato dato un forte atto d’indirizzo con la Comunicazione della Commissione1 del
25 settembre 2001 denominata: “eEurope 2002: accessibilità e contenuto dei siti Internet delle
amministrazioni pubbliche”.
Come ricordato da Roberto Ellero2, in questa vengono riconosciute le WCAG 1.0 come norma
mondiale de facto per la progettazione di siti Web accessibili, in oltre, al punto 5.2 si ricorda
che: “Le pubbliche amministrazioni hanno il dovere di ricercare il costante perfezionamento
delle proprie pagine Web e di esplorare metodi nuovi e migliori di fornire i contenuti e i servizi
Internet man mano che vengono sviluppate nuove tecnologie e nuove versioni delle linee
guida. L’adozione e l’attuazione delle linee guida per i siti delle amministrazioni pubbliche può
dunque essere considerata un primo decisivo meccanismo in direzione di una società
dell’informazione realmente fruibile da tutti.”.
Per questi fini: “Il piano di azione eEurope 2002 vede nell’adozione delle linee guida una prima
tappa verso l’accessibilità dei siti Web delle amministrazioni pubbliche europee e dei loro
contenuti da parte dei disabili. Con esse gli Stati membri e le istituzioni europee daranno un
chiaro segnale nei confronti dell’obiettivo dell’accessibilità di Internet, obiettivo da perseguire
utilizzando quello che de facto è lo standard mondiale dell’accessibilità Web e che è
rappresentato dai lavori dell’iniziativa WAI.”.
Altrettanto interessante può essere considerata la successiva risoluzione del Parlamento
Europeo sulla Comunicazione della Commissione "eEurope 2002: Accessibilità dei siti Web
pubblici e dei loro contenuti" (COM(2001) 529 - C5-0074/2002 - 2002/2032(COS))3.
In questo, e nei dispositivi correlati4 della Commissione Europea si auspica che la qualità
raggiunta dai siti sia compatibile secondo il livello doppia A delle WAI WCAG.
In effetti, al punto Q si ricorda che: ”I siti web delle pubbliche amministrazioni degli Stati
membri e delle istituzioni europee e i relativi contenuti devono essere impostati in maniera tale
da consentire ai disabili di accedere alle informazioni e di sfruttare al massimo le opportunità
offerte dal sistema di amministrazione on-line.”.
E, al punto 30: “sottolinea il fatto che, ai fini dell'accessibilità, è fondamentale che i siti web
abbiano un livello di conformità "Doppia-A", ovvero che sia pienamente applicato il livello di
Priorità 2 delle linee guida del WAI.”.
1
[http://europa.eu.int/eur-lex/it/com/cnc/2001/com2001_0529it01.pdf]
Roberto Ellero: [http://www.robertoellero.it/milano/sia.html]
3
[http://www.europarl.europa.eu/registre/seance_pleniere/textes_adoptes/definitif/2002/0613/0325/P5_TA(2002)0325_IT.pdf]
4
Numero CELEX 52002IP0325: Risoluzione del Parlamento europeo sulla comunicazione della Commissione
eEurope 2002: accessibilità e contenuto dei siti Internet delle amministrazioni pubbliche (COM(2001) 529 C5-0074/2002 - 2002/2032(COS)) Gazzetta ufficiale n. C 261 E del 30/10/2003 pag. 0582 - 0586
2
- 221 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In queste raccomandazioni trova il suo principio fondante la legge italiana, come vedremo
meglio in seguito.
In Spagna, nello specifico, il 1 Gennaio 2006 è entrata è entrata in vigore la legge 34/2002,
del 11 luglio, “Dei servizi della società dell'informazione e del commercio elettronico”.
Nella sua quinta disposizione addizionale tratta appunto dell’accessibilità per le persone disabili
e di età avanzata all'informazione fornita attraverso mezzi elettronici.
Recentemente si è aggiunto anche il governo olandese con una legge che viene definita
comunemente di buon livello qualitativo.
Al momento non sono ancora riuscito ad accedere alla informazione in lingua inglese, segnalo
comunque il sito1 per coloro che desiderassero approfondire l’informazione.
Un elenco esaustivo e molto completo delle attività normative in sede internazionale è
presente sul sito2 di WebAIM.
Da segnalare in oltre anche due iniziative particolarmente feconde nel campo dell’accessibilità
al di fuori delle normative nazionali e internazionali:
Siti culturali: Progetto Minerva, manuale per la qualità dei siti Web pubblici culturali,
dove tra l’altro si possono recuperare i riferimenti a tutte le normative europee e
nazionali3.
Siti Bancari: Progetto ABI - Linee Guida per l'accessibilità dei servizi di home banking4
In questa sede considereremo più approfonditamente le 4 normative più rilevanti in sede
internazionale:
W3C WAI WCAG 1.0;
Rehabilitation Act, Section 508, paragrafo 1194.22;
Legge Stanca 4/2004 e relativo Decreto Ministeriale del 8 Luglio 2005;
W3C WAI WCAG 2.0.
1
[http://webrichtlijnen.overheid.nl/besluit/tekst-besluit-en-toelichting/]
[http://www.webaim.org/articles/laws/world/]
3
[http://www.minervaeurope.org/publications/qualitycriteria-i/indice0402/appendicequattro0402.htm],
[http://www.minervaeurope.org/publications/qualitycriteria1_2draft/appendix4.htm#2]
4
[http://www.webaccessibile.org/argomenti/argomento.asp?cat=420]
2
- 222 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
IV.2 - WCAG 1.0
(W3C WAI RECOMMENDATION - 5 MAGGIO 1999)
Lo sviluppo delle WCAG 1.0 si fa risalire ad uno dei primi documenti sull’accessibilità: "Design
of HTML (Mosaic) Pages to Increase their Accessibility to Users with Disabilities Strategies for
Today and Tomorrow Version 1.0", che è stato redatto da Gregg Vanderheiden, per il Trace
Research and Development Center1 nel Maggio del 1995.
Come si può notare, la data risale a più di 10 anni fa.
I successivi documenti sviluppati dal Trace Center sono poi stati la base per il progetto WAI del
W3C avviatosi nel Gennaio del 1998 e sviluppatosi2 per un anno fino ad arrivare al 5 Maggio
del 1999 alla pubblicazione come Recommendation del W3C delle linee guida dell’accessibilità
per i contenuti Web, le Web Content Accessibility Guidelines (WCAG) versione 1.0.
In questo momento sono ancora l’unico documento di riferimento ufficiale del consorzio in
materia, e lo saranno fin quando le WCAG 2.0 in fase di Last Call Working Draft non
diventeranno Recommendation ufficiale del W3C.
Il documento3 si trova sul sito del gruppo WAI W3C ed in appendice ne ho riportato uno
stralcio significativo in lingua originale.
Un ulteriore documento4 di tecniche applicate illustra le modalità pratiche di attuazione delle
direttive, fornendo esempi attraverso l'utilizzo di HTML (Hypertext Markup Language), CSS
(Cascading Style Sheets), SMIL (Synchronized Multimedia Integration Language), MathML
(Mathematical Markup Language), descrive inoltre tecniche per la validazione e la valutazione
dei documenti, e comprende l'indice degli elementi e attributi HTML.
Per le WCAG 1.0 numerose traduzioni sono disponibili in rete, quella ufficiale 5 si trova sul sito
dell’ufficio italiano del W3C.
Introduzione
Come ricordato da Roberto Ellero1: le WCAG sono il tentativo di costituire una
metodologia per tradurre in un linguaggio uniforme e generale l’essenziale necessità
di consentire a tutti l’accesso all’informazione.
1
2
3
4
5
[http://trace.wisc.edu/]
[http://www.w3.org/WAI/group/GL/wai-gl-wd-changes.html]
[http://www.w3.org/TR/WCAG10/]
[http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/]
[http://www.w3c.it/traduzioni/]
- 223 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
A questo proposito, nel dispositivo introduttivo le WCAG richiamano quali siano le categorie
interessate tra cui: gli utenti affetti da qualche forma di disabilità sensoriale motoria o
cognitiva, coloro che non dispongono di una tastiera o di un mouse, coloro che hanno
connessioni internet molto lente, schermi solo testuali o ridotti, browser testuali, screen-reader
ad altri tipi particolari di programmi utente.
Solo le tipologie di utenza che presente nella sezione delle metodologie generali a cui rimando
per una discussione in merito.
La filosofia di fondo del progetto WCAG 1.0 è basata su due finalità:
Garantire una trasformazione appropriata2. Questi punti sono sviluppati
principalmente nelle linee guida dalla 1 alla 11.
Seguendo queste linee guida gli sviluppatori possono creare delle pagine che rimangano
accessibili nonostante le limitazioni considerate in precedenza, questo grazie ad alcuni
punti chiave che garantiscano delle conversioni appropriate dei contenuti:
o
Separare la struttura dalla presentazione;
o
Predisporre dei testi, inclusi gli equivalenti testuali. I testi possono essere resi
con modalità accessibile per quasi tutti gli utenti;
o
Creare dei documenti che funzionino, anche se gli utilizzatori possono non
sentire o non vedere;
o
Creare dei documenti che non facciano affidamento ad un unico tipo di
hardware, le pagine dovrebbero essere utilizzabili da utenti senza mouse, con
schermi piccoli, basse risoluzioni o addirittura senza schermo;
Rendere il contenuto comprensibile e navigabile 3. Queste linee guida sono
sviluppate principalmente dalla 12 alla 14.
Gli utenti possono rimanere disorientati quando possono vedere una sola porzione della
pagina e senza elementi di orientamento potrebbero non essere capaci di comprendere i
contenuti. Questo principio riguarda:
o
Rendere chiaro e semplice il linguaggio;
o
Fornire meccanismi comprensibili che siano di ausilio alla navigazione.
Organizzazione e conformità
Le WCAG 1.0 sono organizzate in 14 linee guida, definite come principi generali della
progettazione accessibile.
1
2
3
[http://www.webaccessibile.org/argomenti/argomento.asp?cat=368]
“Ensuring Graceful Transformation”
“Making Content Understandable and Navigable”
- 224 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Ogni linea guida ha un suo numero, un suo enunciato, una breve spiegazione e un elenco di
punti di controllo. Il citato documento di tecniche chiarisce ulteriormente la prassi di attuazione
del relativo punto di controllo.
I punti di controllo hanno il compito di spiegare come applicare l’enunciato ed hanno attribuita
una priorità progressiva da 1 a 3:
Priorità 1: Il progettista deve (must) soddisfare questo punto di controllo. In caso
contrario uno o più tipologie di utenti troveranno impossibile accedere alle informazioni;
Priorità 2: Il progettista dovrebbe (should) soddisfare questo punto di controllo. In
caso contrario uno o più tipologie di utenti troveranno difficile accedere alle
informazioni;
Priorità 1: Il progettista può (may) soddisfare questo punto di controllo. In caso
contrario uno o più tipologie di utenti troveranno in qualche modo difficile accedere alle
informazioni.
Le WCAG 1.0 contano 14 linee guida ripartite in 65 punti di controllo. Di queste 16 sono di
priorità 1, 30 sono di priorità 2 e 19 sono di priorità 3.
A seguito del soddisfacimento di uno o più di questi punti di controllo le WCAG definiscono tre
livelli di conformità:
Conformità a livello A: tutti i punti di controllo di priorità 1 sono soddisfatti;
Conformità a livello Doppia-A: tutti i punti di controllo di priorità 1 e 2 sono
soddisfatti;
Conformità a livello Tripla-A: tutti i punti di controllo di priorità 1, 2 e 3 sono
soddisfatti.
Il livello di conformità viene definito in modo esteso (tripla-A e non AAA) così che possa essere
compresi quando vengono resi dagli screen-reader.
La presentazione della dichiarazione di conformità sui siti è consentita in forma testuale ed in
forma grafica, aggiungendo un opportuno logo del W3C.
Va ricordato che non è possibile convalidare automaticamente una dichiarazione di conformità
neppure a livello A delle WCAG 1.0, questo in quanto molti punti di controllo delle linee guida
richiedono esplicitamente una verifica tecnica da parte umana.
La presenza di un’icona di conformità non implica che il W3C abbia controllato e validato la
pagina, essendo questa dichiarazione di esclusiva responsabilità di chi la espone.
- 225 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Coloro che forniscono i contenuti sono i soli responsabili dell’utilizzo del logo 1.
Linee guida e punti di controllo
Vediamo adesso una breve esposizione ragionata delle 14 linee guida associate con i loro
relativi punti di controllo.
Le linee guida sono le seguenti:
1. Fornire alternative equivalenti per il contenuto audio e visivo;
2. Non affidarsi unicamente al colore;
3. Usare le marcature ed i fogli di stile in modo appropriato;
4. Rendere chiaro l'uso del linguaggio naturale;
5. Creare tabelle che si trasformino in maniera gradevole;
6. Garantire che le pagine che utilizzano tecnologie più recenti si trasformino in maniera
gradevole;
7. Garantire che l'utente possa controllare i cambiamenti del contenuto durante la loro
rappresentazione;
8. Garantire l'accessibilità diretta delle interfacce utente incorporate;
9. Progettare garantendo l'indipendenza dal dispositivo;
10. Usare soluzioni temporanee;
11. Usare le tecnologie e le linee guida del W3C;
12. Fornire informazioni per il contesto e l'orientamento;
13. Fornire chiari meccanismi di navigazione;
14. Garantire che i documenti siano chiari e semplici.
Tratteremo ora più in dettaglio le singole direttive.
Le spiegazioni seguenti riguardano specificatamente i contenuti delle WCAG o qualche
informazione aggiuntiva specifica, in quanto i principi generali sono già stati esposti nella
sezione delle metodologie a cui si fa esplicito rimando per informazioni più esaustive sugli
argomenti specifici.
Linea guida 1: fornire alternative equivalenti per il contenuto audio e visivo
Fornire
un
contenuto
che,
quando
viene
presentato
all'utente,
gli
trasmetta
essenzialmente la stessa funzione o scopo del contenuto audio o visivo.
1
“Content providers are solely responsible for the use of these logos.” - [http://www.w3.org/WAI/WCAG1Conformance.html]
- 226 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La fruizione di immagini, filmati, suoni, applet ed altri contenuti non esclusivamente testuali
potrebbe essere impossibile per utenti disabili o che non abbiano a disposizione le normali
tecnologie. E’ possibile garantire un accesso ai contenuti se questi includono una informazione
equivalente che abbia la stessa funzione del contenuto audio o video che sostituisce.
Viene rimarcata l’importanza di fornire un contenuto testuale alternativo come alternativa per
un contenuto non testuale. L’utilità degli equivalenti testuali è stata discussa nella sezione
relativa e consiste nella possibilità di essere facilmente indirizzato anche a tecnologie diverse,
in particolare:
Display Braille, essenziale per sordo-ciechi;
Sintesi vocale, tramite screen-reader, fondamentale per persone non vedenti o disabili
cognitivi:
Gli oggetti coinvolti da questa linea guida sono immagini, mappe immagini, applet e oggetti tra
cui Macromedia Flash, i frame, i pulsanti, gli script, arte ASCII ed altri oggetti grafici. Per molte
di queste componenti è spesso un buon punto di inizio dotarle di un attributo ALT con un testo
alternativo.
Da notare che la linea guida non richiede esclusivamente equivalenti testuali, a volte è utile
fornire anche equivalenti non testuali del testo scritto, come ad esempio immagini, video o
tracce audio pre-registrate a beneficio di utenti illetterati, disabili cognitivi o per persone che
hanno difficoltà nella lettura.
Lo stesso principio si applica anche ai filmati multimediali richiedendone, allo stesso tempo,
anche la sincronizzazione.
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:
Punto di controllo 1.1: Fornire un equivalente testuale per ogni elemento non di testo.
[Priorità 1];
Punto di controllo 1.2: Fornire collegamenti di testo ridondanti per ogni zona attiva di
una mappa immagine sul lato server (server-side). [Priorità 1];
Punto di controllo 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];
Punto di controllo 1.4: Per ogni presentazione multimediale temporizzata, sincronizzare
le alternative equivalenti con la presentazione. [Priorità 1];
Punto di controllo 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].
- 227 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Linea guida 2: non affidarsi unicamente al colore
Assicurarsi che il testo e la parte grafica siano comprensibili se consultati senza il
colore.
Il colore viene usato in maniera intensiva sul Web, per abbellire l’aspetto estetico e spesso
veicola anche un contenuto informativo, questo può rendere difficoltosa la fruizione da parte di
persone parzialmente o totalmente cieche ai colori (protanopia, deutranopia, tritanopia).
L’uso delle corrette combinazioni cromatiche è indicato in un capitolo apposito delle
metodologie così come la descrizione delle cecità ai colori sono riportate fra le descrizioni delle
disabilità.
Una seria critica che è stata mossa da più parti1 al punto di controllo 2.2 è che abbia priorità 3
per il testo. In realtà l’impiego di contrasti sufficienti per i testi è un requisito almeno di pari
importanza rispetto al contrasto di colore per le immagini.
Come fatto notare nel capitolo dedicato le WCAG 2.0 equiparano i due concetti e definiscono
nuovi algoritmi di valutazione di contrasto.
Per il momento, per quanto le WCAG 1.0 siano ancora il testo ufficiale di riferimento del
consorzio, si suggerisce di dare maggiore attenzione a quest’aspetto di quanto non abbia fatto,
almeno formalmente, il W3C.
Questa linea guida comprende punti di controllo a tutti i tre livelli di accessibilità:
Punto di controllo 2.1: Garantire che tutta l'informazione veicolata dal colore sia
disponibile anche in assenza di colori. [Priorità 1];
Punto di controllo 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. [Priorità 2 per immagini
- Priorità 3 per il testo].
Linea guida 3: usare le marcature ed i fogli di stile in modo appropriato
Marcare i documenti con i corretti elementi strutturali. Controllare la presentazione con
fogli di stile piuttosto che con elementi e attributi di presentazione.
Questa linea guida è fondamentale per la corretta metodologia in quanto introduce i due temi
cardine:
1
Separazione tra contenuto e presentazione;
Utilizzo semanticamente corretto degli elementi strutturali.
Michele Diodati: [http://www.diodati.org/scritti/2004/guida/ele_acc16.asp]
- 228 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In effetti, usare una sintassi in maniera scorretta non permette la formattazione di un
documento adeguato per tutti i programmi utente impedendo la fruizione da parte di alcune
categorie di visitatori.
Tra i cattivi usi dei marcatori si ricordano ad esempio l’uso improprio di tabelle
d’impaginazione, l’utilizzo di elementi di citazione o di intestazione per presentazioni grafiche, il
mancato uso dei fogli di stile, eccetera.
I punti di controllo di questa linea guida sono 7, tutti di livello 2, ma molti di importanza
centrale:
Punto di controllo 3.1: Quando esiste un linguaggio di marcatura adatto, per veicolare
informazione usare un marcatore piuttosto che le immagini. [Priorità 2];
Punto di controllo 3.2: Creare documenti che rispettino le grammatiche formali. [Priorità
2];
Punto di controllo 3.3: Usare i fogli di stile per controllare l'impaginazione e la
presentazione. [Priorità 2];
Punto di controllo 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];
Punto di controllo 3.5: Usare elementi di intestazione per veicolare la struttura del
documento e usarli in modo conforme alle specifiche. [Priorità 2];
Punto di controllo 3.6: Marcare le liste ed elencare le voci della lista in modo
appropriato. [Priorità 2];
Punto di controllo 3.7: Marcare le citazioni. [Priorità 2].
Linea guida 4: rendere chiaro l'uso del linguaggio naturale
Utilizzare marcatori che facilitino la pronuncia o l'interpretazione di testi stranieri o
abbreviati.
La definizione di una lingua per la pagina è utile per i motori di ricerca e per gli screen-reader
che devono caricare gli opportuni dizionari di pronuncia.
Per questo motivo è altrettanto necessario marcare gli eventuali cambiamenti che si presentino
in citazioni o paragrafi all’interno del testo.
Come accennato nella sezione specifica, questo passaggio comportava del dispendio di risorse
e di tempo nelle versioni precedenti degli screen-reader più comuni come JAWS, per fortuna
recentemente si è assistito ad un notevole miglioramento dell’efficienza di questi prodotti.
L’utilizzo di acronimi e abbreviazioni in oltre favorisce la comprensione del testo e delle sigle
anche per gli utenti normodotati, consuetudine sempre più presente nei siti attuali.
Un punto di discussione è quello se la marcatura degli acronimi e delle abbreviazioni debba
essere connotata solo la prima volta o per tutte le occorrenze del testo nella pagina.
Ci sono 3 punti di controllo per questa linea guida:
- 229 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Punto di controllo 4.1: Identificare con chiarezza i cambiamenti nel linguaggio naturale
del testo di un documento e in ogni equivalente testuale. [Priorità 1];
Punto di controllo 4.2: Specificare il significato di ogni abbreviazione o acronimo nel
documento laddove compaia per la prima volta. [Priorità 3];
Punto di controllo 4.3: Identificare il linguaggio naturale principale di un documento.
[Priorità 3].
Linea guida 5: creare tabelle che si trasformino In maniera gradevole
Assicurarsi che le tabelle abbiano la marcatura necessaria per essere trasformate dai
browser accessibili e da altri interpreti.
Il problema delle tabelle è stato molto sentito dagli autori e dagli studiosi dell’accessibilità. Un
capitolo è stato dedicato nelle metodologie generali di questo lavoro distinguendo fra le tabelle
create al fine di contenere puramente i dati e quelle invece progettate per l’impaginazione e la
grafica del documento.
Come fatto notare in quella sede, né le WCAG 1.0 né le WCAG 2.0 vietano l’uso delle tabelle
d’impaginazione. La tendenza però è quella di sostituire con l’uso dei fogli di stile e dei DIV
all’interno del codice (X)HTML, soprattutto se non possono essere correttamente linearizzate.
L’uso delle tabelle di impaginazione è consentito solo previo rispetto dei punti di controllo di
questa linea guida.
Questi punti di controllo sono soprattutto a beneficio degli utenti che accedono al sito tramite
tecnologie assistive come screen-reader o persone che riescono ad accedere a sezioni limitate
della pagina. Quindi il mancato rispetto di questi punti inibisce un accesso fruibile non solo agli
utenti disabili.
I punti di controllo sono 6, inerenti sia alle tabelle dati che alle tabelle di impaginazione:
Punto di controllo 5.1: Per le tabelle dati, identificare le intestazioni per righe e colonne.
[Priorità 1];
Punto di controllo 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];
Punto di controllo 5.3: Non usare le tabelle di impaginazione a meno che la tabella non
sia comprensibile se linearizzata. [Priorità 2];
Punto di controllo 5.4: Se si utilizza una tabella di impaginazione non utilizzare alcun
marcatore di struttura a scopo di formattazione. [Priorità 2];
Punto di controllo 5.5: Per ogni tabella definire un sommario dei contenuti. [Priorità 3];
Punto di controllo 5.6: Fornire abbreviazioni per le etichette di intestazione. [Priorità 3].
- 230 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Linea guida 6: garantire che le pagine che utilizzano tecnologie più recenti si trasformino in
maniera gradevole
Assicurarsi che le pagine siano accessibili anche quando le tecnologie più recenti non
sono supportate o sono disabilitate.
Il problema che vuole affrontare questa linea guida è quello della retro-compatibilità.
Come detto nella sezione dedicata, si tratta di favorire lo sviluppo delle nuove tecnologie senza
penalizzare gli utenti che dispongano di programmi utente non recenti.
Il compromesso si può raggiungere progettando un contenuto valido che garantisca l’accesso
anche con browser relativamente datati e connessioni a bassa velocità, che sia navigabile
anche senza l’impiego di applet o plug-in specializzati.
Per quanto vada sicuramente previsto un criterio progettuale di compatibilità, è inutile andare
a cercare soluzioni estreme cercando di risolvere malfunzionamenti di browser realmente
obsoleti come Netscape 4 con soluzioni ad hoc che spesso finiscono per appesantire e rendere
realmente inaccessibile la pagina.
I 5 punti di controllo di questa guida hanno una significativa priorità:
Punto di controllo 6.1: Organizzare i documenti in modo che possano essere letti anche
in assenza dei fogli di stile. [Priorità 1];
Punto di controllo 6.2: Garantire che all'aggiornamento dei contenuti dinamici vengano
aggiornati anche i contenuti equivalenti. [Priorità 1];
Punto di controllo 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];
Punto di controllo 6.4: Garantire che i gestori di eventi per gli script e le applet siano
indipendenti dai dispositivi di input. [Priorità 2];
Punto di controllo 6.5: Garantire che il contenuto dinamico sia accessibile oppure fornire
una presentazione o una pagina alternativa. [Priorità 2].
Linea guida 7: garantire che l'utente possa controllare i cambiamenti del contenuto durante la
loro rappresentazione
Assicurarsi che gli oggetti in movimento, lampeggianti, scorrevoli o che si autoaggiornano possano essere arrestati temporaneamente o definitivamente.
Le disabilità visive o cognitive impediscono di accedere al testo scorrevole o lampeggiante a
causa della distrazione o della difficoltà di lettura che esso comporta. Anche gli screen-reader
possono avere delle difficoltà ad accedere a questi contenuti.
In oltre una forte attenzione va posta per gli utenti soggetti ad attacchi di epilessia
fotosensibile. Costoro possono incorrere in delle crisi per la visione di questi contenuti se i
medesimi hanno delle frequenze particolari.
- 231 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per questo i punti di controllo di questa linea guida hanno una significativa priorità:
Punto 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];
Punto di controllo 7.2: Fino a quando i programmi utente non permetteranno agli utenti
di controllare il lampeggiamento, evitare di far lampeggiare il contenuto. [Priorità 2];
Punto di controllo 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];
Punto di controllo 7.4: Fino a quando i programmi utente non forniranno la possibilità di
bloccare l'auto-aggiornamento, non creare pagine che si auto-aggiornano
periodicamente. [Priorità 2];
Punto di controllo 7.5: Fino a quando i programmi utente non forniranno la capacità di
bloccare l'auto-reindirizzamento, non usare marcature per reindirizzare le pagine
automaticamente. Piuttosto, configurare il server in modo che esegua i reindirizzamenti.
[Priorità 2].
Linea guida 8: garantire l'accessibilità diretta delle interfacce utente incorporate
Assicurarsi che la progettazione delle interfacce utente segua i principi dell'accessibilità:
accesso alle diverse funzionalità indipendente dai dispositivi usati, possibilità di operare
da tastiera, comandi vocali, ecc.
Si tratta di dare un’accessibilità agli oggetti nella pagina Web che siano dotati di interfaccia
utente. Ogni interfaccia incorporata deve rispettare i principi di una progettazione accessibile,
come ad esempio l’indipendenza dal dispositivo di accesso che deve essere garantita anche per
periferiche differenti come ad esempio la tastiera o comandi vocali.
Se l’interfaccia non può essere resa accessibile, allora deve essere predisposta una soluzione
alternativa che sia accessibile.
Nello stesso testo delle WCAG viene consigliato di fare riferimento alle UAAG e alle ATAG per
avere informazioni sul concetto di interfaccia accessibile.
Il punto di controllo è unico e di priorità elevata:
Punto di controllo 8.1: Fare in modo che elementi di programmi come script e applet
siano direttamente accessibili o compatibili con le tecnologie assistive. [Priorità 1 (se
importante) o 2].
Linea guida 9: progettare garantendo l'indipendenza dal dispositivo
Usare caratteristiche che permettono di attivare gli elementi della pagina attraverso una
molteplicità di dispositivi di input.
L’indipendenza del dispositivo di accesso non riguarda solamente gli oggetti esterni incorporati
dotati di una propria interfaccia, ma in genere deve essere estesa a tutte le funzionalità del
sito tenendo presente il fatto che i visitatori possono usare potenzialmente diversi periferiche
- 232 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
di ingresso. Al fine di garantire un accesso indipendente dal dispositivo è necessario progettare
le pagine in modo che qualsiasi dispositivo ne garantisca la fruibilità. Non si possono produrre
delle pagine che interagiscano esclusivamente tramite eventi del mouse.
In genere le pagine che garantiscono un accesso tramite tastiera sono accessibili anche con
comandi vocali o altre interfacce che simulino la pressione dei tasti.
I punti di controllo di questa linea guida coprono tutte le priorità:
Punto 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];
Punto di controllo 9.2: Garantire che ogni elemento dotato di una sua specifica
interfaccia possa essere gestito in una modalità indipendente dal dispositivo. [Priorità
2];
Punto di controllo 9.3: Negli script, specificare gestori di evento logici piuttosto che
gestori di evento dipendenti dal dispositivo. [Priorità 2];
Punto di controllo 9.4: Creare un ordine logico di tabulazione fra i collegamenti, i
controlli dei moduli e gli oggetti. [Priorità 3];
Punto di controllo 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].
Linea guida 10: usare soluzioni temporanee
Usare soluzioni provvisorie in modo che le tecnologie assistive e i browser più vecchi
possano operare correttamente
Per quanto le WCAG fossero state progettate nel 1999, già allora era evidente che le tecnologie
dei programmi utente erano in costante sviluppo. Per questo molte parti delle linee guida
contengono la dicitura fino a quando i programmi utente1. Questo per il fatto che al momento
della pubblicazione del documento non tutti i programmi utente o le tecnologie assistive
garantivano le funzionalità richieste per l’accessibilità. In tal caso le linee guida richiedono che
siano gli stessi sviluppatori a farsi carico di questi bisogni fin quando la maggior parte dei
programmi utente non includeranno queste caratteristiche al loro interno.
Ad esempio i browser più datati non consentivano di raggiungere i campi di un modulo se
questi erano vuoti, oppure leggevano liste consecutive di collegamenti ipertestuali come se
fossero un solo collegamento.
1
“until user agent” – [http://www.w3.org/TR/WCAG10/#until-user-agents]
- 233 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Le disposizioni contenute in questa linea guida sono quindi considerate provvisorie ed il W3C
non ritiene che rimangano necessarie in futuro, quando i programmi utente avranno integrato
le funzionalità richieste.
In effetti, allo stato attuale delle cose alcuni di questi suggerimenti sono realmente diventati
obsoleti.
Tra tutti, quello relativo al punto di controllo 10.4 sui controlli vuoti. Attualmente questa
disposizione non solo è inutile ma finisce anche per confondere gli utenti che spesso finiscono
per non cancellare tutto il testo segnaposto inserito e per inviarlo insieme ai agli altri valori del
modulo.
Il punto di controllo 10.1 invece ha avuto le sue conferme, sia nella sintassi del linguaggio
XHTML 1.1 che ha eliminato gli attributi necessari per aprire nuove finestre nei collegamenti
ipertestuali, sia nelle WCAG 2.0 che hanno riconfermato la validità del principio alla linea guida
3.2, imponendo che sia esplicitamente l’utente a richiedere il cambiamento di contesto.
Il punto di controllo 10.2 non dovrebbe invece essere applicabile poiché sono fortemente
raccomandate le associazioni esplicite delle etichette.
I punti di controllo per questa linea guida sono 5:
Punto di controllo 10.1: Fino a quando i programmi utente non permetteranno agli
utenti di bloccare l'apertura di nuove finestre, non fare apparire pop-up o finestre di
altro tipo e non cambiare la finestra attiva senza informare l'utente. [Priorità 2];
Punto di controllo 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];
Punto di controllo 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];
Punto di controllo 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. [Priorità 3];
Punto di controllo 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].
Linea guida 11: usare le tecnologie e le linee guida del W3C
Usare
le
tecnologie
del
W3C
(in
conformità
con
le
specifiche)
e
seguire
le
raccomandazioni sull'accessibilità. Nei casi in cui non sia possibile usare una tecnologia
- 234 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
del W3C, oppure se nell'utilizzarla si ottenesse materiale che non si trasforma in
maniera elegante, fornire una versione alternativa del contenuto che sia accessibile
Il W3C ha promosso le WCAG 1.0 nel 1999 mirandole espressamente al mondo (X)HTML e
tecnologie inerenti come ad esempio i CSS e i moduli XML. Per quanto questo mondo sia in
effetti uno dei migliori ambiti in cui sviluppare contenuti accessibili, tuttavia non è possibile
non considerare nelle raccomandazioni dell’accessibilità anche le altre tecniche. Questa è
proprio una delle missioni critiche delle WCAG 2.0 che si sono assunte l’onere di offrire delle
direttive che siano indipendenti dalla piattaforma di sviluppo.
Nelle WCAG 1.0 tuttavia sono fortemente raccomandate le tecnologie sviluppate dal W3C.
In effetti, queste tecnologie godono di significativi vantaggi:
I riferimenti delle WCAG 1.0 sono espliciti ed applicabili direttamente come indicato nel
documento di tecniche accluso;
Le tecnologie sono sviluppate, sin dal progetto iniziale, per integrare gli elementi di
accessibilità necessari;
Sono frutto di un processo aperto comune che ha raggiunto una vasta base consensuale
da parte delle maggiori industrie del settore.
Tuttavia il mondo esterno non può rimanere ignorato, tra questi strumenti si trovano dei
formati oramai comuni, come ad esempio PDF o Flash che richiedono l’uso di lettori di formati
proprietari e di plug-in. Altra cosa sarà poi garantire che i contenuti in se stessi siano
accessibili, ad esempio facendo esplicito riferimento alle direttive per l’accessibilità proposte
dai produttori di questi formati proprietari.
Ad ogni modo, anche se per le WCAG 1.0 queste tecnologie non sono proibite, si tratta di
evitare quelle che sono espressamente disapprovate o di fornire dei contenuti alternativi
accessibili nel caso che non lo fossero gli originali:
Punto 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];
Punto di controllo 11.2: Evitare l'utilizzo di caratteristiche disapprovate dal W3C.
[Priorità 2];
Punto di controllo 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];
Punto di controllo 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].
- 235 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Linea guida 12: fornire informazioni per il contesto e l'orientamento
Fornire informazione per la contestualizzazione e l'orientamento, per aiutare gli utenti a
comprendere pagine od elementi complessi.
Con la linea guida 12 si passa a considerare la seconda finalità delle WCAG 1.0, cioè quella di
rendere il contenuto comprensibile e navigabile.
In questo caso si raccomanda fornire degli strumenti per chiarificare il contesto e
l’orientamento. Raggruppare gli elementi, fornire informazioni sul contesto e chiarire le
relazioni fra gli elementi di una pagina aiuta gli utenti ad orientarsi.
Le relazioni tra le parti di una pagina possono essere difficoltose da comprendere soprattutto
per utenti che non utilizzano browser grafici per la navigazione o per utenti affetti da disabilità
cognitive.
Le raccomandazioni che riguardano i frame sono in parte obsolete, per la attuale tendenza ad
eliminare questo strumento dalle pagine Web.
Anche per questo i punti di controllo di questa linea guida hanno priorità significativa:
Punto di controllo 12.1: Assegnare un titolo a ogni frame per facilitarne l'identificazione
e la navigazione. [Priorità 1];
Punto di controllo 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];
Punto di controllo 12.3: Dividere i grandi blocchi di informazione in gruppi più
maneggevoli quando è naturale ed appropriato. [Priorità 2];
Punto di controllo 12.4: Associare esplicitamente le etichette ai loro controlli. [Priorità
2].
Linea guida 13: fornire chiari meccanismi di navigazione
Fornire chiari e coerenti meccanismi di navigazione -- informazione per l'orientamento,
barre di navigazione, una mappa del sito, ecc. -- per aumentare le probabilità che una
persona trovi quello che sta cercando in un sito
Accanto alla necessità di raggruppare e contestualizzare gli elementi omogenei come indicato
al punto precedente, un altro strumento essenziale è quello di integrare dei meccanismi di
navigazione chiari e coerenti.
Questa è una funzionalità utile non solamente per le persone con invalidità cognitive o per non
vendenti, ma giova in genere a tutti gli utenti fornire dei punti di riferimento utili.
I suggerimenti esposti coprono diverse tecniche e sono tutti di una certa utilità per raggiungere
una maggiore chiarezza nella navigazione. Gli argomenti sono stati specificatamente trattati
nella sezione delle metodologie generali.
Punto di controllo 13.1: Identificare con chiarezza la destinazione di ogni collegamento.
[Priorità 2];
- 236 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Punto di controllo 13.2: Fornire metadati per aggiungere alle pagine ed ai siti
informazioni di tipo semantico. [Priorità 2];
Punto di controllo 13.3: Fornire informazioni sulla configurazione generale di un sito
(per esempio, una mappa oppure un indice dei contenuti). [Priorità 2];
Punto di controllo 13.4: Usare meccanismi di navigazione in modo coerente. [Priorità
2];
Punto di controllo 13.5: Fornire barre di navigazione per evidenziare e dare accesso ai
meccanismi di navigazione. [Priorità 3];
Punto di controllo 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];
Punto di controllo 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];
Punto di controllo 13.8: Posizionare l'informazione più significativa all'inizio delle
intestazioni, dei paragrafi, delle liste, ecc. [Priorità 3];
Punto di controllo 13.9: Fornire informazioni sulle raccolte di documenti, ossia
documenti composti da più pagine. [Priorità 3];
Punto di controllo 13.10: Fornire un mezzo per saltare i contenuti ASCII multilinea
(ASCII Art). [Priorità 3].
Linea guida 14: garantire che i documenti siano chiari e semplici
Assicurarsi che i documenti siano chiari e semplici in modo che possano essere compresi
più facilmente
Questo è uno dei punti più discussi e citati delle WCAG.
L’uso di un linguaggio chiaro e semplice viene spesso ignorato soprattutto dai siti più
squisitamente amministrativi o tecnici. La richiesta di produrre dei contenuti che siano
comprensibili riguarda anche quei settori, come ad esempio quello della pubblica
amministrazione, dove queste modalità espressive sono spesso sotto considerate.
Nello sviluppare un sito Web un autore è spesso scoraggiato, per motivi di tempo e di costi, a
dedicare la cura dovuta al linguaggio e alle scelte lessicali e grammaticali dei suoi documenti.
In realtà una disposizione coerente della pagina, una grafica riconoscibile, un linguaggio
comprensibile e ben definito aiutano tutti gli utenti ed in particolar modo quelli affetti da
parziali disabilità cognitive nella comprensione dei contenuti, come chiarito nella sezione
Metodologie.
Come fatto più volte notare, il punto di controllo 14.1 è di priorità 1. Quindi una pagina che
non utilizzi il linguaggio più chiaro e semplice possibile in relazione ai contenuti del sito non
può dichiarare di aver neppure raggiunto il livello A di conformità.
- 237 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Altro punto da mettere in luce è che ben difficilmente i valutatori automatici possono
controllare il soddisfacimento di questo punto di controllo.
Per quanto ci si possa avvalere di significativi strumenti di analisi lessicale del testo, risulterà
comunque impossibile validarne pienamente il contenuto.
Un’ulteriore prova per ribadire che, allo stato attuale delle cose, nessun validatore automatico
può testimoniare il raggiungimento di un sufficiente grado di accessibilità di un qualunque sito
senza l’intervento di un consulente umano.
Questa linea guida è articolata in 3 punti di controllo:
Punto di controllo 14.1: Utilizzare un linguaggio più chiaro e semplice possibile che sia
adatto al contenuto del sito. [Priorità 1];
Punto di controllo 14.2: Integrare il testo con presentazioni visive o audio nei casi in cui
possano facilitare la comprensione della pagina. [Priorità 3];
Punto di controllo 14.3: Creare uno stile di presentazione coerente fra le pagine.
[Priorità 3].
Critiche ed attuazione
Al momento in cui sono uscite, le WCAG 1.0 hanno avuto il compito di fare da apripista, di
introdurre in senso normativo il tema dell’accessibilità.
Essendo un primo lavoro ha portato con se le naturali imprecisioni ed errori di prospettiva che
è lecito attendersi da un documento di portata così ampia.
Tra le maggiori critiche che sono state portate alle WCAG 1.0 si ricordano:
Il fatto di essere espressamente mirate ai linguaggi definiti dal W3C come l’HTML e il
CSS (quando sono uscite XHTML e SVG erano ancora da definirsi) e di non considerare,
se non marginalmente, le tecnologie proprietarie;
Il fatto di essere state concepite e definite completamente senza passare da una prassi
convalidata e da una sufficiente elaborazione da parte delle associazioni dei disabili.
Se le WCAG fossero centrate sulle osservazioni di ciò che ai disabili serve in rapporto a ciò
che è possibile fare, le soluzioni sarebbero pratiche e praticabili. Se non sempre lo sono è
anche perché si parte da come il codice in teoria dovrebbe e potrebbe essere implementato,
più che dalla realtà esperita dai disabili.1
In aggiunta le loro applicazioni sono state spesso mal realizzate o del tutto disattese anche a
molti anni di distanza dalla loro emanazione.
1
Maurizio Boscarol: [http://www.ecologiadeisitiweb.net/blog/la-balcanizzazione-dellaccessibilita]
- 238 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Se in un primo momento questo fatto poteva essere addotto alla relativa poca sensibilizzazione
e diffusione dei principi dell’accessibilità, con il passare degli anni e la maggiore attenzione da
più parti rivolta al problema, è diventato solamente un problema di economia di tempo e di
cattiva abitudini progettuali.
Semplicemente molti hanno giudicato che non ne valesse la pena1 e che non ci fossero risorse
da sprecarci in tempo e denaro.
Nel 2004 è stata pubblicata un’indagine formale2 condotta dalla commissione dei diritti dei
disabili a proposito dell’accesso al Web e della inclusione delle persone disabili.
Sono state testate 1000 home page, rappresentative di 5 settori: governativo, affari,
commercio elettronico, intrattenimento, servizi Web.
E’ stato usato un valutatore automatico per una prima analisi. Ovviamente uno strumento
automatico non può controllare la conformità di tutti i 65 punti di controllo visto che, come
illustrato, alcuni richiedono uno specifico intervento umano.
Per quanto riguarda la compatibilità con il livello A, delle 1000 home page controllate 808, cioè
l’81% circa avevano delle violazioni anche solamente a livello dei punti di controllo a priorità 1.
In altre parole solo il 19% di queste home page avrebbero potuto essere di livello A, a patto
poi di passare anche il controllo manuale. E questo analizzando esclusivamente le home page,
senza nessun controllo sul resto del sito.
I risultati migliori dei cinque settori sono venuti dai siti governativi che hanno superato per il
32% i soli controlli automatici di livello A.
Se poi si passa a livello doppia-A i risultati sono disastrosi. Solamente 6 home page, pari al
0.6% del campione ha dimostrato di passare i soli controlli automatici senza contenere
violazioni per i punti di controllo 1 e 2. In questo caso è stato compiuto anche un controllo
manuale su questi 6 candidati scoprendo che poi solamente 2 (pari al 0.2% del campione)
erano effettivamente conformi alla doppia-A.
Nessuno dei 1000 raggiungeva la conformità tripla-A.
Come ricordato in un pungente articolo3 di Joe Clark, citato successivamente nei commenti
della versione 2.0 delle WCAG, il raggiungimento della tripla-A è considerato, di fatto,
irrilevante o inattendibile, mentre le priorità 1 e 2 sono, di conseguenza, il blocco di regole
1
“Normally, the reason your favorite pet accessibility feature is missing is simply that a decision was made
that it wasn’t worth the effort. Is that insensitive? No, it’s business.” –
[http://www2.jeffcroft.com/blog/2006/aug/21/has-accessibility-been-taken-too-far/]
2
[http://joeclark.org/dossiers/DRC-GB.html]
3
[http://alistapart.com/articles/tohellwithwcag2]
- 239 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
necessarie per rendere il sito accessibile visto che il livello tripla-A è oneroso e impossibile da
raggiungere.
Lo studio precedente è stato arricchito con un’analisi specifica sulle linee guida violate.
Sono state considerate due rilevazioni:
Il numero di linee guida differenti che sono state violate sulla home page;
La ricorrenza delle violazioni in cui si è incorsi.
Il numero medio di linee guida violate sul campione di 1000 home page è stato
approssimativamente di 8 per pagina. Il che significa che ci sono mediamente 8 differenti linee
guida per pagina a cui gli sviluppatori devono porre maggiore attenzione.
L’analisi delle ricorrenze rivela approssimativamente 108 violazioni per pagina, comprendendo
sia quelle più significative sia quelle meno significative, e questo da le dimensioni della
quantità di ostacoli che vengono incontrati mediamente dalle persone disabili nella
navigazione.
Un'altra interessante analisi1 è stata compiuta sulle compagnie facenti parte del FTSE 100
index, cioè le 100 compagnie a capitale maggiore del London Stock Exchange.
L’analisi, condotta recentemente nel Marzo del 2006 dagli esperti del NOMENSA, dimostra
come almeno il 75% delle compagnie nella lista del FTSE 100 non sono adeguate alle richieste
minime per l’accessibilità dei siti Web.
Le home page di ogni sito analizzato sono state valutate utilizzando procedure di test manuale
in riferimento alle WCAG 1.0.
Solamente 24 siti raggiungono il minimo livello di accessibilità e nessuno raggiunge la doppia-A
o la tripla-A. Tra queste 24, due si elevano sopra gli standard mancando di raggiungere la
doppia-A per un punto di controllo, questo a causa della incapacità delle pagine di essere
espanse o contratte in accordo con le preferenze utente.
I punti deboli di questi siti sono in genere:
Una scarsa qualità del codice HTML;
Un uso poco pulito delle liste;
Non vengono impiegati le intestazioni e i titoli propriamente;
Mancanza dei testi alternativi per gli elementi grafici;
Apertura di finestre di pop-up.
1
[http://www.nomensa.com/news/at-nomensa/2006/4/ftse-100-websites-fail-accessibilityrequirements.html]
- 240 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La data recente di questo sondaggio e l’importanza dei siti Web esaminati fa capire quanto,
anche solo le WCAG 1.0, siano ben lontane dall’essere state recepite e metabolizzate dai
progettisti di siti Web.
- 241 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
IV.3 - Section 508
(LEGGE FEDERALE U.S.A. - 21 DICEMBRE 2000)
Il problema della disabilità nei luoghi di lavoro è stato affrontato con decisione negli Stati Uniti
dove coinvolge un gran numero di persone. Per dare un’idea della dimensione degli interessi in
gioco, negli USA ci sono 2.500.000 di dipendenti federali di cui 160.000 portatori di handicap1.
Anche per questo il governo degli Stati Uniti è stato tra i primi a produrre una normativa che
tenesse conto dell'accessibilità sui luoghi di lavoro.
Già dal 1998 era stata emanata la sezione 508 del Rehabilitation Act, estensione
dell'Americans with Disabilities Act (ADA). Questa legge impone alle Agenzie Federali di
acquistare tecnologia informatica ed elettronica che sia accessibile a persone con disabilità.
La sezione 508 trova origine nella volontà di eliminare le barriere nella tecnologia informatica
ed elettronica, per rendere disponibili nuove opportunità a persone con disabilità, e per
incoraggiare lo sviluppo di tecnologie che aiutino a raggiungere questi obiettivi.
La legge si applica a tutte le Agenzie Federali che sviluppano, acquisiscono, gestiscono o usano
tecnologie informatiche e elettroniche. In ottemperanza alla sezione 508, le Agenzie devono
assicurare ai propri impiegati ed al pubblico con disabilità un accesso alle informazioni che sia
comparabile a quello disponibile agli individui normodotati.
La legge assegna all'Agenzia Federale (Access Board) che si occupa del superamento delle
barriere per le persone portatrici di handicap, il compito di definire standard di riferimento
opportuni. Questa agenzia federale per l'accesso ha delegato, a sua volta, ad un comitato
tecnico di professionisti, accademici e rappresentanti delle organizzazioni dei disabili, il compito
materiale di redigere le regole per l'accessibilità.
Il comitato investito di questo compito è chiamato Electronic and Information Technology
Access Advisory Committee (EITAAC).
Il 21 marzo del 2000, come risultato del lavoro compiuto nei mesi precedenti dall'EITAAC,
l’Access Board ha pubblicato una bozza di linee guida per l’accessibilità.
Dopo un periodo di valutazioni e commenti pubblici, il 21 dicembre del 2000 le proposte
dell’EITAAC sono diventate legge a tutti gli effetti, con obbligo per le agenzie federali degli
Stati Uniti di conformarvisi dal mese di Giugno 2001.
Da allora le Agenzie Federali inadempienti rischiano di incorrere in azioni civili da parte di
dipendenti portatori di handicap, nel caso non rispettino le normative approvate.
1
[http://www.pubbliaccesso.gov.it/normative/rehabilitation_act/promemoria.htm]
- 242 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
È stata inoltre creata un’apposita struttura all'interno del governo federale con il compito di
formare gli impiegati federali e di costruire l'infrastruttura necessaria a supportare l'attuazione
della sezione 508. Tra le altre iniziative è stato creato un sito Web 1 al fine di rendere disponibili
informazioni e risorse per comprendere ed attuare i requisiti della normativa.
È importante notare che le linee guida definite dall'EITAAC non riguardano solo Internet ed il
Web, ma un’ampia varietà di apparati tecnologici hardware e software. In particolare 2:
Programmi applicativi e sistemi operativi;
Informazioni ed applicazioni Intranet ed Internet basate sul Web;
Prodotti per telecomunicazioni (telefoni e telescriventi);
Prodotti video e multimediali (apparecchi televisivi, riproduttori di videocassette e
DVD);
Prodotti autosufficienti con software incorporato (chioschi multimediali, bancomat,
fotocopiatrici, fax, stampanti, macchine calcolatrici);
Computer da tavolo e portatili.
Il risultato dell’entrata in vigore di tale legislazione è che i requisiti di accessibilità sono
considerati fin dalla gara d’appalto per l’acquisto di apparecchiature e servizi elettronici e
informatici. Tra due ditte che partecipano alla medesima gara, a parità di offerta, vince chi è in
grado di garantire la migliore copertura dei requisiti di accessibilità stabiliti dall’articolo 508.
Questa disposizione è, in parte, analoga a quanto attuato anche da noi con la legge 04/2004 di
cui discuteremo diffusamente in seguito. Con la rilevante aggiunta che in Italia, per le
Pubbliche Amministrazioni, i requisiti Web sono obbligatori.
Un’interessante lista di controllo3 per la verifica della attuazione delle legge americana è
reperibile su internet sul sito di WEBAIM (WEB Accessibilty In Mind) dove sono riportate dei
precisi punti di controllo per ogni linea guida per pagine HTML, JavaScript, Plug-in e Java.
Linee guida per le pagine Web
Per quanto riguarda la nostra analisi, le linee guida per lo sviluppo di applicazioni Web della
Section 508 prevedono 16 direttive e sono contenute nel paragrafo 1194.22: “Informazioni e
applicazioni Internet e Intranet sul Web”4, definito nell'articolo 508.
1
2
3
4
[http://www.section508.gov/]
[http://www.diodati.org/scritti/2002/sec508/sec508_stam.asp]
[http://www.webaim.org/standards/508/checklist]
“Web-based Intranet and Internet Information and Applications”
- 243 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Le riporto nella traduzione del governo italiano1. Il testo originale è reperibile sul sito delle
autorità americane2 ed uno stralcio essenziale è contenuto anche in appendice.
In una nota allegata alla stessa sezione, il governo americano rileva come molte linee guida
siano ispirate direttamente dalle WCAG 1.0 già preesistenti al momento di produrre la
normativa. Altre sono delle aggiunte esplicite.
Evidenzieremo questi aspetti dopo l'esposizione della legislazione.
Per le brevi note di commento al testo ho ritenuto significativo aggiungere dei commenti basati
sulle note tratte dal sito di Jim Thatcher3 a cui rimando per la versione originale in lingua
inglese.
1194.22 (a): Offrire un equivalente testuale.
Bisogna fornire un equivalente in forma testuale per ogni elemento di natura non
testuale (ad esempio a mezzo dell'ALT, LONGDESC o nel contenuto dell'elemento).
Ogni immagine del sito Web deve avere un testo alternativo. Anche le immagini che non
portino informazioni importanti o siano ridondanti. In questo caso si può utilizzare un testo
vuoto con l'attributo ALT="". Occorre usare l'attributo LONGDESC oppure una notazione tipo dLink per descrivere i grafici o i diagrammi nel caso in cui l'attributo ALT non possa portare
informazioni equivalenti.
1194.22 (b): Fornire elementi multimediali sincronizzati.
Alternative equivalenti per una qualsiasi presentazione multimediale dovranno essere
sincronizzate con la presentazione stessa.
Gli equivalenti testuali per le presentazioni multimediali devono essere sincronizzati con le
presentazioni, come ad esempio per le titolazioni. Gli autori delle pagine Web sono incoraggiati
a includere trascrizioni del contenuto audio come alternative sincronizzate, questo dal
momento che un tale genere di trascrizioni consentono tecniche di ricerca ed estrazione di
testo.
1194.22 (c): Non vincolarsi al colore
Le pagine Web dovranno venire progettate in modo tale che tutte le informazioni fornite
tramite colori siano anche disponibili senza l'utilizzo di tale mezzo, ad esempio dal
contesto o tramite un linguaggio a marcatori.
1
2
3
[http://www.pubbliaccesso.gov.it/normative/rehabilitation_act/standard_tecnici.htm]
[http://www.section508.gov/]
[http://www.jimthatcher.com/webcoursec.htm]
- 244 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Si tratta di non veicolare informazioni importanti con il solo uso del colore. Utilizzare font,
caratteri particolari o altri tipi di evidenziatori oltre all'uso del colore.
1194.22 (d): Progettare indipendentemente dai fogli di stile.
I documenti dovranno essere organizzati in modo da risultare leggibili anche senza
l'utilizzo di fogli di stile.
I fogli di stile sono un efficace aiuto nello specificare font, modifiche visuali e colorazione alle
pagine Web. Ad ogni modo non devono essere impiegati esclusivamente cambiamenti di stile
per marcare elementi strutturali del linguaggio HTML, come ad esempio le intestazioni <HX>, i
paragrafi <P> e le liste.
Nel caso che vengano usati i fogli di stile per il posizionamento degli elementi o per la gestione
dei colori, occorre controllare la visualizzazione delle pagine anche senza i fogli di stile per
verificare che nessuna informazione vada perduta disattivandoli.
1194.22 (e): Fornire collegamenti ridondanti per le mappe lato server.
Bisognerà fornire link ridondanti ad informazioni di natura testuale per ogni regione
attiva di una server-side image map.
Se si devono usare le mappe lato server, occorre essere sicuri che ci siano equivalenti testuali
associati per ogni regione attiva della mappa.
1194.22 (f): Utilizzare mappe lato client.
Bisognerà mettere a disposizione client-side image map al posto delle server-side image
map ad eccezione dei casi in cui la regione non può essere definita utilizzando una
forma geometrica disponibile.
Il fatto che sia possibile utilizzare una regione poligonale per descrivere ogni area fino al
dettaglio desiderato, permette di utilizzare mappe lato client in ogni caso. Occorre comunque
ricordarsi di includere un testo alternativo per ogni area della mappa.
1194.22 (g): Intestare righe e colonne
Nel caso di tabelle sarà necessario identificare le intestazioni di riga e colonna.
Se, nella tabella dati, ci sono intestazioni in cima alle colonne o al principio delle righe, occorre
usare il marcatore di intestazione (TH) per indicarle.
1194.22 (h): Usare l'attributo di intestazione per le tabelle complesse
Sarà necessario utilizzare marcatori per associare il contenuto dell'elemento di una
tabella e gli identificatori di riga e colonna ad esso associati quando gli identificatori di
riga o colonna sono costituiti da due o più livelli logici.
Non è probabilmente una buon’idea utilizzare delle tabelle che abbiano più di un livello logico di
intestazione per righe o colonne. Tuttavia, nel caso venissero implementate occorre includere
- 245 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
l'opportuno tag di marcatura su ogni cella con l'attributo di intestazione per indicare il
significato della cella stessa, utilizzando l'attributo ID per indicare l'informazione di
intestazione.
1194.22 (i): Fornire titoli per i frame.
I frame dovranno essere dotati di titolazioni in forma testuale in modo da rendere
agevole l'identificazione dei frame e la navigazione tra gli stessi.
Allo scopo di facilitare una navigazione ragionevole in un sito con frame, ogni elemento FRAME
di una struttura di tipo FRAMESET deve avere un titolo significativo e un attributo NAME. Ogni
FRAME
deve avere un elemento titolo.
1194.22 (j): Ridurre gli sfarfallamenti.
Le pagine dovranno essere progettate in modo da evitare che lo schermo mostri
fenomeni di intermittenza aventi una frequenza maggiore di 2Hz e minore di 55Hz.
Non avere GIF animate o altri oggetti che possano causare uno sfarfallio di una parte dello
schermo. Tale genere di elementi può causare delle crisi nelle persone con una epilessia
fotosensibile.
1194.22 (k): Fornire un alterativa solo testo come ultima risorsa.
Dovrà essere fornita una pagina di solo testo con informazioni o funzionalità equivalenti
in modo da far sì che una pagina Web ottemperi alle disposizioni della presente parte
quando la osservanza delle norme in questione non può essere conseguita in alcun altro
modo. Il contenuto della pagina di solo testo dovrà essere aggiornato ogni qualvolta la
pagina primaria cambia.
Nel caso che non si riesca a soddisfare qualche requisito degli standard 508, è possibile creare
un sito solo testo. Il sito solo testo deve avere tutte le informazioni del sito principale, deve
essere aggiornato con la stessa frequenza del sito principale e deve essere immediatamente ed
evidentemente accessibile dalla pagina principale.
1194.22 (l): Implementare script accessibili.
Nei casi in cui le pagine Web utilizzano linguaggi basati su script per visualizzare il loro
contenuto o per creare elementi di interfaccia, l'informazione fornita dagli script dovrà
venir identificata da testi funzionali che possono venir letti utilizzando tecnologie di
supporto.
Uno dei modi per controllare che il sito sia compatibile con le richieste della sezione 508 è che
le informazioni essenziali non vengano perdute quando le funzionalità JavaScript siano
disattivate.
- 246 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Le informazioni essenziali non vengono perdute se viene usato un effetto di evidenziazione
attivato da un evento MOUSEOVER o se ci sono comunque delle modalità alternative per attivare i
collegamenti contenuti nei menu di tipo MOUSEOVER.
Se vengono usati gli script per scrivere in un modulo informazioni essenziali in un forma
visuale al momento del caricamento, allora quelle informazioni saranno disponibili alla
tecnologia assistiva.
Se si sta facendo uso di un contenuto nascosto esposto con i gestori di avvenimento in
linguaggio JavaScript, occorre assicurarsi o che il contenuto equivalente sia disponibile senza
JavaScript o che si possano attivare gli stessi eventi tramite la tastiera.
1194.22 (m): Specificare applet e plug-in accessibili.
Allorché una pagina Web richiede che sul sistema utente siano presenti un applet, un
plug-in o altre applicazioni per interpretare il contenuto della pagina, la stessa dovrà
fornire un link ad un plug-in o ad un applet che si conforma alle disposizioni contenute
nel paragrafo 1194.21 da (a) a (l).
Applets e plug-in devono soddisfare gli standard software della Section 508. In particolare
devono essere integralmente utilizzabili senza il mouse. Nel momento in cui il focus si sposta
da oggetto ad oggetto, le tecnologie assistive devono essere in grado di determinare il compito
e l'azione di default per ogni oggetto che acquisisce il fucus. Occorre testare l'utilizzo degli
applets e dei plug-in utilizzandoli solo la tastiera.
1194.22 (n): Progettare moduli accessibili.
Allorché moduli digitali vengono progettati per essere completati on-line, i moduli stessi
dovranno permettere l'accesso ad individui che utilizzano tecnologie di supporto alle
informazioni, ai campi e alle funzionalità richieste per il completamento e l'inoltro del
modulo comprese tutte le informazioni di contesto nonché quelle relative a destinatari
secondari per conoscenza.
Occorre accertarsi di aver etichettato attentamente gli elementi di un modulo collocando
l'etichetta di testo nelle vicinanze del controllo relativo. Utilizzare l'elemento LABEL per
associare via codice i prompt con gli elementi di input quando il testo del prompt e il controllo
sono separati.
1194.22 (o): Fornire una navigazione a salti.
Dovrà essere messo a disposizione un metodo che permetta agli utenti di saltare link di
navigazione ripetitivi.
Occorre fornire un sistema agli utenti per spostarsi velocemente sui collegamenti ipertestuali di
navigazione. Questo può essere ottenuto con un link del tipo "salta la navigazione" posto in
testa alla pagina. In alternativa si possono predisporre delle strutture ben organizzate.
- 247 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
1194.22 (p): Avvisare l'utente sui tempi di risposta.
Nei casi in cui sia richiesta una risposta a tempo, l'utente dovrà venire avvisato e gli
dovrà venir fornito tempo sufficiente per indicare che ha bisogno di un'ulteriore quantità
di tale risorsa.
Se la pagina si aspetta una risposta dall'utente in un tempo prescritto, occorre avvisare
l'utente di questo fatto, e consentirgli l'impiego di tempo supplementare.
Relazione con le direttive WAI
L'esposizione della normativa americana, precedente alla nostra legge Stanca del 2004, ma
successiva alle direttive WCAG 1.0, ci porta direttamente a valutarle in relazione le une con le
altre.
Un primo aiuto in tal senso viene fornito direttamente dalla Section 508 che stabilisce dei
criteri ispiratori con le precedenti WCAG 1.0.
I primi paragrafi (a-k) sono posti espressamente in relazione con le prescrizioni internazionali,
mentre gli ultimi (l-p) sono considerati indipendenti, secondo questo schema:
1. Il Comitato per l'Accesso interpreta i paragrafi da (a) a (k) della presente sezione nel
senso che risultino coerenti con i seguenti punti di controllo di priorità 1 del Web
Content Accessibility Guidelines 1.0 (WCAG 1.0) (5 Maggio 1999) pubblicato dal Web
Accessibility Initiative del World Wide Web Consortium.
TABELLA 2 - CORRISPONDENZA SECTION 508 E WCAG 1.0
Paragrafo 1194.22
Checkpoint WCAG 1.0
(a)
1.1
(b)
1.4
(c)
2.1
(d)
6.1
(e)
1.2
(f)
9.1
(g)
5.1
(h)
5.2
(i)
12.1
(j)
7.1
(k)
11.4
2. I paragrafi (l), (m), (n), (o) e (p) di questa sezione risultano diversi da WCAG 1.0. Le
pagine Web che ottemperano a WCAG 1.0, livello A (ossia tutti i punti di controllo di
- 248 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
priorità 1) devono anche soddisfare il contenuto dei paragrafi (l), (m), (n), (o) e (p)
della presente sezione per ottemperare alla sezione stessa.
Come vedremo meglio con l’esposizione comparata delle normative, le varie legislazioni, pur
ottemperando di base agli stessi principi esposti in questo testo, non sono del tutto identiche.
In particolare, le regole dell'articolo 508 introducono differenze significative per quanto
riguarda la gestione di script, applet e programmi accessori integrati rispetto alle WCAG 1.0.
In particolare1:
Sono più restrittive circa lo sfarfallamento dello schermo e fanno riferimento al
problema della risposta temporizzata, quasi del tutto assente dalle linee guida WAIW3C, se non per i punti 7.4 e 7.5 ma a proposito di contesti specifici;
Sono più permissive rispetto alla segnalazione di qualsiasi cambiamento di linguaggio
naturale nel testo e l'uso del più chiaro e semplice linguaggio appropriato al contesto:
due criteri che nelle regole per il Web elencate sotto l'articolo 508 sono completamente
assenti.
Nelle norme federali, infatti, non viene fatto alcun accenno alla comprensibilità e alla semplicità
del materiale esposto, un importante fattore che invece nelle WCAG, specialmente nelle 1.0,
viene esplicitamente menzionato.
Quinti la piena conformità alle sedici linee guida federali non coincide con la piena conformità
alle raccomandazioni WCAG 1.0 del WAI: aver raggiunto la prima non è garanzia di ottenere la
seconda, e viceversa.
Michele Diodati, in un suo articolo su internet, ha fatto notare che ci potrebbero essere persino
delle incompatibilità di base tra le due normative, dei punti di divergenza che rendono in certi
casi materialmente impossibile soddisfare entrambe le formulazioni, in quanto l'obbedienza ad
una delle due esclude di poter obbedire all'altra.
Si riferisce in particolar modo ad un caso comune ed importante: la gestione delle funzionalità
introdotte nelle pagine Web per mezzo di linguaggi di script, applet ed oggetti di
programmazione.
In effetti, il punto di controllo 6.3 delle WCAG 1.0 recita: “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.”.
1
[http://www.diodati.org/scritti/2002/sec508/sec508_stam.asp]
- 249 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Su questa si allinea anche il requisito 15 della legge italiana. Mentre, a proposito degli script il
paragrafo (l) delle norme federali dichiara: “Nei casi in cui le pagine Web utilizzano linguaggi
basati su script per visualizzare il loro contenuto o per creare elementi di interfaccia,
l'informazione fornita dagli script dovrà venir identificata da testi funzionali che possono venir
letti utilizzando tecnologie di supporto.”.
Secondo Diodati la differenza sembra inconciliabile:
Per le WCAG 1.0, il contenuto informativo generato dallo script deve essere accessibile
(tramite testi alternativi) anche per mezzo di programmi utente che non supportano gli script o
che ne hanno disabilitato il supporto, anche se poi lo script in se stesso non genera testo
funzionale leggibile per mezzo di tecnologie assistive. Per il paragrafo (l) di Section 508 basta
invece che si generi un testo funzionale che sia possibile leggere per mezzo di tecnologie
assistive e non occorre produrre un'alternativa per utenti che non possano o non vogliano
usare sistemi abilitati a gestire linguaggi di script.1
Personalmente, per quanto fortemente discostanti, non trovo incompatibili queste due letture e
non ritengo che sia il caso di cavillare sui singoli dispositivi. La filosofia di base è di rendere
disponibili le informazioni contenute nella pagina anche ai disabili, garantendo che vi possano
accedere o direttamente tramite le tecnologie assistive o usufruendone anche con gli script
disabilitatati. La norma americana sembra essere notevolmente più permissiva, ma occorre
ricordare che anche le WCAG 2.0 possono richiedere l’uso degli script attivati qualora siano
dichiarati nella baseline.
Ovviamente, per quello che ci riguarda, restano più significative le WCAG 1.0, sulle quali, come
dicevo, il testo della legge italiana si è chiaramente ispirato.
Relazione con la legge italiana
In generale la legge americana è più pragmatica dei punti di controllo previsti dalle WCAG 1.0,
per quanto alla fine si riveli più carente per altri aspetti 2.
I requisiti della legge Stanca sono, di fatto, in generale più restrittivi della Section 508
statunitense, come vedremo al termine della disamina della legge italiana. Una conclusione
prevedibile, visto che la legge Stanca ha voluto sintetizzare suggerimenti tecnici sia della
Section 508 sia delle WCAG 1.0.
In particolare i punti in cui la legge Stanca risulta più restrittiva includono:
1
2
Gli aspetti legati alla validità sintattica dei file (XHTML, DTD STRICT),
[http://www.diodati.org/scritti/2002/sec508/sec508_3.asp]
Giorgio Brajnik: [http://www.dimi.uniud.it/wq/stanca-mappa.html]
- 250 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L’obbligo di non usare i frame;
Il fornire un contrasto elevato;
L’usare il CSS, un layout liquido e testo ridimensionabile;
Il rendere linearizzabili le tabelle di layout;
Il rendere i collegamenti ipertestuali informativi, e il distanziarli opportunamente;
Il non usare pagine solo testo come alternativa ammissibile.
In alcuni punti invece la legge Stanca è leggermente meno precisa, in particolare nel discutere
delle immagini (GIF) che possono causare epilessia e quando, per taluni, non sembra
considerare esplicitamente i file PDF soggetti ai vincoli dell'accessibilità nei siti Web.
Una tabella sintetica di confronto verrà presentata al termine della esposizione di tutte le
normative.
Un ultimo appunto va rivolto all’attenzione del legislatore per il delicato problema degli
aggiornamenti.
Si tratta di un tema particolarmente sentito da queste normative che sono costrette a
confrontarsi con la continua evoluzione delle tecnologie presenti in rete.
Le WCAG 1.0 hanno pesantemente sofferto di questa lacuna, ed uno dei principi ispiratori della
versione 2.0 è stato proprio quello di produrre una raccomandazione il più possibile avulsa
dalle specifiche tecniche adottate.
Da questo punto di vista la legge americana è una delle più vincolate in quanto, non sono fa
riferimento ad elementi specifici di un linguaggio specifico (mi riferisco in particolar modo alle
citazioni degli attributi ALT, LONGDESC, fogli di stile, FRAMESET, FORM eccetera), ma non prevede
espressamente nemmeno un meccanismo di revisione periodica della normativa e questo può
rappresentare un significativo difetto, tanto più quando essa abbia in sé dei difetti congeniti.
A sentire per esempio Emily Dixon di Usable.net, che ben conosce dall’interno la Section 508,
l’applicazione di questa legge negli USA, a due anni dalla sua promulgazione, non solo è stata
in gran parte trascurata, ma è stata anche causa di notevoli problemi di interpretazione e di
comprensione.1
La legge italiana, da questo punto di vista, integra un aspetto un po’ più efficace, e cioè la
previsione esplicita di un suo aggiornamento delle norme tecniche come indicato all’articolo 12.
Che questo poi non sia ancora avvenuto è un problema che mi auguro sia motivato dall’attesa
per le imminenti uscite delle WCAG 2.0.
1
[http://www.i-use.it/articoli/accessibilita/2/]
- 251 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
IV.4 - Legge Stanca
(LEGGE DELLO STATO ITALIANO - 9 GENNAIO 2004)
Il fermento normativo intorno al tema dell’accessibilità non è rimasto disatteso in Italia.
La legislazione italiana ha prodotto una legge sull'accessibilità del Web tra le più avanzate e
restrittive a livello mondiale, la legge 04/2004: “Disposizioni per favorire l'accesso dei soggetti
disabili agli strumenti informatici”, detta comunemente legge Stanca dal nome del Ministro per
le Innovazioni e le Tecnologie sotto il cui mandato è stata approvata.
La legge trova origine nel decreto legislativo Dlgs 216/2003: “Attuazione della direttiva
2000/78/CE per la parità di trattamento in materia di occupazione e di condizioni di lavoro”
dell’anno precedente.
L'iniziativa normativa si è sviluppata nell'arco di un anno ed è stata stimolata da Roberto
Scano per conto di IWA/HWG, che ha predisposto la proposta di legge n. 3486 presentata a
Venezia il 16 dicembre 2002 dagli On. Campa e Palmieri. Tale proposta di legge, recependo le
indicazioni dell'Unione Europea, richiedeva l'applicazione dell'intero progetto WAI del W3C ed è
stata sottoscritta da oltre 130 parlamentari. Altre proposte sono seguite1. La novità di queste
proposte normative sta nel coinvolgimento degli operatori del Web: l'associazione IWA/HWG
ha predisposto una lista di discussione dedicata, nella quale gli esperti del settore e gli
onorevoli firmatari dei progetti di legge si sono scambiati opinioni ed hanno apportato proposte
di integrazione al disegno di legge.2
Il risultato della legge ha richiesto molto lavoro ed è una fusione di una ventina di testi
differenti. Più di una cinquantina di associazioni sono state chiamate in causa, con una ventina
di specialisti esterni. Il tutto con l’obiettivo di ottenere il maggiore consenso possibile.3
Tutto il suo impianto è assolutamente innovativo. Il governo italiano è uno dei primi governi al
mondo ad affrontare il problema con tale interesse ed attenzione.
Per questi aspetti e per l’interesse diretto, la trattazione di questa materia sarà un po’ più
approfondita e coinvolgerà anche alcuni aspetti legislativi.
La maggiore attenzione che ho voluto dedicare anche a problemi che vanno oltre una pura
relazione tecnico-scientifica è dovuta al fatto che in realtà, a differenza delle norme WAI, la
legge Stanca è un testo di legge valido a tutti gli effetti, anzi, è l’unica normativa ufficiale in
Italia.
1
2
3
[http://www.pubbliaccesso.gov.it/normative/progetti_legge/index.htm]
Roberto Scano: “Accessibilità: dalla teoria alla realtà”.
Roberto Ellero: Seminario “Legge Stanca: dalla teoria alla realtà”, Arese 2005.
- 252 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Data l’inerzia delle società e delle amministrazioni pubbliche, credo che sia necessario, affinché
l’accessibilità non resti una parola morta, che il dispositivo di legge in materia venga compreso
e divulgato nella sua pienezza.
Il nucleo dell’esposizione e del commento alla legge presentata in questa sezione è basato su
una conferenza tenuta da Roberto Ellero e da Luca Mascaro alla Biblioteca Comunale di Arese
(MI) nel Maggio del 2005.
Il Seminario, dal titolo: "Legge Stanca: dalla teoria alla realtà. Analisi delle disposizioni per
favorire l'accesso dei soggetti disabili agli strumenti informatici", è stato organizzato
direttamente da IWA – Italy.
I due docenti sono figure preminenti nel campo dell’accessibilità:
Roberto Ellero ha seguito la stesura dei requisiti tecnici della legge, è W3C WCAG
Working Group Member for IWA/HWG, è docente IWA per il CNIPA;
Luca Mascaro è membro di diverse organizzazioni internazionali come l'IWA/HWG per la
Svizzera, e partecipa a vari gruppi di lavoro all'interno dei consorzio W3C (HTML,
WCAG, Web Application Format e Web API) e ISO.
L’impianto completo della legislazione si articola in diversi atti:
Dlgs 216/2003;
Legge 04/2004;
Codice dell’Amministrazione Digitale (DLgs 7 Marzo 2005, n. 82);
Regolamento di attuazione (DPR 1 marzo 2005, n. 75);
Requisiti tecnici della Legge 04/2004 (DM 8 Luglio 2005).
Ovviamente il centro della trattazione saranno i requisiti tecnici che riguardano più da vicino
questa tesi.
Come per le precedenti normative, i concetti guida sono stati già esposti nel capitolo delle
metodologie generali e a quella sezione farò più volte richiamo.
Prima di procedere con l’esposizione vorrei riportare nella maniera più fedele possibile un
concetto illuminante esposto da Luca Mascaro durante la conferenza: l’accessibilità non è di
per se un punto di arrivo, è piuttosto un primo tentativo di mettere ordine. E’ Un modo
per iniziare con una buona base di partenza che negli anni dovrà consentire un miglioramento
generale dei siti. Si comincia con questa metodologia per avere tra dieci anni dei siti della
pubblica amministrazione organizzati e strutturati in maniera migliore di come non lo siano
oggi. Allo stato attuale delle cose, i siti che siano a posto anche solo con il primo requisito della
legge Stanca sono trascurabili.
Un simile pensiero è ripreso nell’analisi dei costi dell’accessibilità a cui rimando per
approfondimenti.
- 253 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Decreto legislativo 216/2003
Come accennato nella precedente presentazione, le basi della Legge Stanca si possono
rintracciare nel precedente Decreto Legislativo 216/2003.
Il decreto è stato pubblicato sulla Gazzetta Ufficiale il 13 Agosto 2003 con titolo “Attuazione
della direttiva 2000/78/CE per la parità di trattamento in materia di occupazione e di condizioni
di lavoro” ed è in vigore dal 31 Agosto 2003.
Ha le sue origini in una direttiva europea, la direttiva 2000/78/CE del Consiglio Europeo del 27
novembre 2000.
L’oggetto è quello delle pari opportunità nel mondo del lavoro. Reca le disposizioni relative
all'attuazione della parità di trattamento fra le persone indipendentemente dalla religione, dalle
convinzioni personali, dagli handicap, dall'età e dall'orientamento sessuale, per quanto
concerne l'occupazione e le condizioni di lavoro, disponendo le misure necessarie affinché tali
fattori non siano causa di discriminazione.
Eccezione fatta qualora, per la natura dell'attività lavorativa, si tratti di caratteristiche che
costituiscono un requisito essenziale e determinante ai fini dello svolgimento dell'attività
medesima.
Questo decreto è passato sostanzialmente non visto fino alla sua riconsiderazione alla luce
della successiva legge Stanca, ma il concetto che non sia possibile discriminare in alcun mondo
una persona disabile, anche momentaneamente disabile, come ad esempio per un infortunio al
braccio, ha delle ripercussioni significative, dal momento che la disposizione delle misure
necessarie è spesso un impegno non indifferente nel mondo del lavoro.
Per fare degli esempi elementari, se un lavoratore ha un braccio rotto, l’azienda deve
provvedere a fornirgli gli opportuni ausili per lavorare. Un ipovedente medio spesso non ha
diagnosi da ipovedente, caso tipico di chi porta gli occhiali, ma queste persone, qualora lo
richiedano, hanno diritto ad avere sul posto di lavoro gli strumenti accessibili per la mansione
che svolgono.
A differenza della legge Stanca, il lavoratore deve essere messo in grado di svolgere le sue
mansioni sia nel caso di un’azienda privata che in quello di una pubblica
amministrazione.
Qualora il dirigente vieti l'acquisto di attrezzature atte all'integrazione del lavoratore con
disabilità, tale dirigente effettua una discriminazione ed è soggetto ai provvedimenti di legge.
La richiesta deve partire dal dipendente e il datore di lavoro deve provvedere di conseguenza.
Il decreto 216 è una norma penale, il datore di lavoro che la infranga può incorrere anche in
una sanzione economica.
Un aspetto da notare è che non deve essere necessariamente la persona lesa a fare causa, la
legittimazione ad agire è riconosciuta anche alle rappresentanze locali delle organizzazioni
nazionali maggiormente rappresentative.
- 254 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In questo decreto legislativo non sono contenute norme esplicite per la gestione dei siti Web.
Tuttavia ho ritenuto opportuno riportarne brevemente questi principi guida per spiegare meglio
la filosofia da cui traggono origine le successive normative in questione.
Legge 04/2004
La Legge è stata pubblicata sulla gazzetta ufficiale n. 13 del 17 gennaio 2004 con il titolo
“Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici” ed
è in vigore dal 1 febbraio 2004.
Come accennato nella parte introduttiva di questa sezione, il dispositivo nasce da una precisa
tendenza e si allinea alle direttive della comunità europea, tra cui la fondamentale
Comunicazione CE del 25 settembre 2001 dal titolo “eEurope 2002: accessibilità e contenuto
dei siti Internet delle amministrazioni pubbliche”1.
La Legge ha dei contenuti profondamente innovativi:
Tutti i siti che saranno realizzati, o rinnovati, in futuro dalle pubbliche amministrazioni
dovranno rispettare i requisiti di accessibilità;
Per i privati, il provvedimento non genera un obbligo di accessibilità per i siti internet,
ma è fattore di stimolo a promuovere l’accessibilità delle loro pagine Web;
Tutti i libri di testo delle scuole, ove possibile, saranno resi disponibili in formati leggibili
al computer da non vedenti o ipovedenti o con altre disabilità.
Presentazione
Date queste premesse, i docenti del seminario tenutosi ad Arese hanno messo in risalto il fatto
che in Europa la legge italiana venga considerata una normativa piuttosto esigente per gli enti
interessati.
Il dispositivo di legge, oltre a riguardare tutte le pubbliche amministrazioni a qualunque livello,
coinvolge anche le scuole di ogni ordine e grado, le università, gli enti del servizio sanitario
nazionale, dando delle norme non solamente per i siti Web, ma anche, sebbene con modalità
diverse, per le attrezzature informatiche e per le postazioni di lavoro.
Per le attrezzature e le postazioni di lavoro, i requisiti sono titolo preferenziale, mentre invece
per i siti Web costituiscono vincolo contrattuale, se infatti le forniture non sono conformi ai 22
requisiti Web il contratto viene annullato.
1
Quaderno del C.N.I.P.A. n.1 del Novembre 2003. [http://eurlex.europa.eu/LexUriServ/site/it/com/2001/com2001_0529it01.pdf], [http://europa.eu.int/eurlex/it/com/cnc/2001/com2001_0529it01.pdf]
- 255 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Anche in questo caso per invalidare il contratto non è necessario che vi ricorra esclusivamente
il disabile, può fare ricorso anche un dipendente della pubblica amministrazione o di una
società concorrente. Ogni altro partecipante al bando di concorso può ricorrere.
Esiste poi la figura del Difensore Civico, come istituito dalla legge 142/90 nell’articolo 8.
A questa figura può ricorrere ad esempio un utente non vedete, data l'impossibilità di accedere
a un bando in quanto il documento PDF non è correttamente formattato o è protetto in modo
da renderlo di conseguenza inaccessibile anche ai lettori di schermo, oppure data la sua
incapacità di accedere ad altre informazioni contenute nelle pagine Web dovuta, ad esempio
all’impossibilità di ingrandire i caratteri.
Il ricorso al Difensore Civico è previsto senza costi aggiuntivi per il cittadino.
Per quanto riguarda i siti esistenti anche questi sono ormai anche loro sottoposti alla legge.
Infatti, i contratti in essere alla data d’entrata in vigore del decreto, in caso di rinnovo o
modifica sono adeguati, a pena di nullità, alle disposizioni della legge, con l'obiettivo di
realizzare tale adeguamento entro dodici mesi dalla data di entrata in vigore del decreto
pubblicato l’8/agosto/2005.
Questa norma finisce per coinvolgere tutti i siti della pubblica amministrazione, in quanto è
inevitabile, per il loro steso utilizzo, che essi debbano essere necessariamente aggiornati.
A questa legge fanno eccezione i siti realizzati con risorse interne in quanto non facenti
parte di contratti stipulati con società esterne. Una modifica a questa disposizione
probabilmente sfuggita al legislatore è prevista con il recente secondo decreto Campa Palmieri
di cui si accennerà in seguito. Indirettamente anche il codice della Pubblica Amministrazione
Digitale ovvia a questo problema anche se con tempi più lunghi.
Un'altra volontaria lacuna della legge è di non riguardare Bancomat e colonnine che restano
non accessibili di base. In effetti, questo è stato probabilmente voluto dal legislatore che ha
inteso ottenere l’accessibilità mantenendola nominalmente a costo zero. Le spese per
rendere accessibili queste apparecchiature sarebbero state evidentemente molto rilevanti e la
legge non avrebbe potuto essere promulgata con la stessa relativa facilità con cui invece ha
ottenuto l’approvazione di tutto il parlamento.
Del tema dei costi si è discusso in un capitolo dedicato di questo lavoro e a quello rimando, qui
voglio solo ricordare che per raggiungere questo obiettivo, l’unico modo è quello di modificare
il modo di lavorare chi produce siti Web formandoli fin da principio sulle metodologie del
progetto WAI.
Dispositivo
Il testo integrale della Legge è riportato in appendice, fatti salvi gli omissis per quanto ritenuto
poco attinente alla trattazione.
In questa sede vorrei dare una rapida scorsa per sommi capi ai concetti guida dei vari articoli.
- 256 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Articolo 1: Obiettivi e Finalità.
Si ispira al principio fondamentale di uguaglianza dei cittadini, applicato in questo caso
nel loro diritto di accedere alle fonti di informazione e ai servizi on line.
Nel testo di legge si fa riferimento anche al software e all’hardware, oltre che ad
internet e traendo la materia dalla precedente Section 508 della legislazione degli Stati
Uniti.
Articolo 2:Definizioni.
Vengono forniti le necessarie definizioni in materia su accessibilità e tecnologie
assistive.
Un appunto mosso dai docenti del seminario alla definizione di accessibilità è stato
quello che sembra mancare la dizione “in modo facile per tutti”. Ritengo però che i
termini presenti nel resto del testo rendano inutile questa ulteriore aggiunta.
Articolo 3:Destinatari.
Un elenco degli enti destinatari della legge. Come si è detto, la legge riguarda
essenzialmente gli enti pubblici. Tra queste vanno segnalate anche le aziende che
hanno la maggioranza a partecipazione pubblica, come la Telecom Italia, o aziende che
forniscono in appalto attrezzatura alla pubblica amministrazione.
Sono esentati il corpo dei Carabinieri, l’esercito i N.A.S. ed altri enti che non possono
avere disabili in servizio se non amministrativi.
Tra le pubbliche amministrazioni si devono ricordare anche le scuole e le università.
Articolo 4: Obblighi.
Ci sono tre aspetti da considerare per gli Enti dell’Articolo 3.
Beni e servizi informatici;
Siti INTERNET;
Postazioni di lavoro.
Il trattamento di questi tre aspetti è leggermente differente.
Per quanto riguarda i beni ed i servizi informatici, i requisiti di accessibilità costituiscono
motivo di preferenza a parità di ogni altra condizione nella valutazione dell'offerta
tecnica. Hardware e software non devono necessariamente essere conformi, ma
costituiscono motivo di preferenza nella valutazione.
Resta comunque valido il principio del preesistente decreto legislativo 216/2003
discusso in precedenza, per cui, è possibile non acquistare uno screeen-reader in
mancanza di un lavoratore disabile, ma non appena venga richiesto il personale deve
essere messo in grado di svolgere le sue mansioni.
- 257 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
A questo proposito va ricordato che negli Stati Uniti, fin dal 1999 tutto il software e
tutto l’hardware è conforme alle normative della Section 508 e questo ha finito
inevitabilmente per imporre degli standard effettivi nel materiale tecnico presente in
commercio.
I requisiti Web invece sono obbligatori. Gli Enti citati nell’articolo 3 non possono
stipulare, a pena di nullità, contratti per la realizzazione e la modifica di siti Internet
quando non è previsto che essi rispettino i requisiti di accessibilità. Con i vincoli già
citati per quelli già esistenti che vengano modificati.
Per sito internet si comprende anche una rete intranet. Chi adotta sistemi informativi
interni che non siano a norma deve necessariamente renderli accessibili.
Articolo 5: Didattica.
Un aspetto innovativo di questa legge è che coinvolge anche gli istituti scolastici per
quanto riguarda il materiale formativo e didattico tra cui ovviamente anche i libri di
testo. Deve essere prevista la fornitura di copie su supporto digitale degli strumenti
didattici fondamentali, accessibili agli alunni disabili e agli insegnanti di sostegno,
nell'ambito delle disponibilità di bilancio.
Articolo 6: Verifica.
Al successivo regolamento di attuazione sono demandate le norme per la verifica del
raggiungimento dell’accessibilità, tra cui l’esposizione del logo di conformità.
Articolo 7: Compiti amministrativi.
Il controllo di attuazione della legge è demandato al Dipartimento Innovazione e
Tecnologie (DIT) avvalendosi del Centro nazionale per l'informatica nella pubblica
amministrazione (CNIPA). Regioni e province autonome hanno il compito di vigilare sul
loro territorio per l’attuazione della legge. Da notare un principio di incostituzionalità
sollevato a proposito di questo articolo, risolto dalla Corte Costituzionale con
l’annullamento della legge per le province autonome di Trento e Bolzano le quali hanno
comunque promulgato una legge regionale apposita del tutto simile.
Articolo 8: Formazione.
La legge prevede un’attività formativa in merito effettuata con tecnologie accessibili. Le
amministrazioni di cui all'articolo 3, nell'ambito delle disponibilità di bilancio, devono
predisporre corsi di aggiornamento professionale sull'accessibilità.
Nel seminario si è evidenziata l’estrema urgenza di un’attività formativa come previsto
da quest’articolo. Purtroppo una tale attività formativa finisce per impattare
- 258 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
direttamente contro il principio di costo zero dell’attuazione della legge e, con questo
cavillo, tale articolo è stato facilmente disatteso.
Se da un lato è opportuno che le amministrazioni comunali si attivino per creare un
gruppo di lavoro interno, dall’altro è altrettanto vero che la maggior parte dell’attività
formativa non può ragionevolmente essere fornita senza ulteriori aggravi economici
sulle pubbliche amministrazioni.
La regione dovrebbe organizzare in collaborazione con i comuni dei piani di
aggiornamento dei siti Web. In genere tutte le amministrazioni centrali dovrebbero
incominciare a pensare ad un processo di adeguamento, cercando anche di porsi in
maniera costruttiva nei confronti della attività di formazione.
Questo aspetto ha carattere fondamentale.
Il pubblico dipendente o quantomeno lo stesso responsabile dell’accessibilità di ogni
amministrazione dovrebbe ricevere entro tempi brevi un corso di formazione impartito
dalle amministrazioni centrali.
Una grossa lacuna in questo senso è stata registrata a livello delle Università,
direttamente chiamate in causa per i corsi formativi. A distanza di anni le Università
hanno fatto poco o nulla sul tema dell’accessibilità, né preparando dei corsi né fornendo
materiale informativo1.
In mancanza di un’attività formativa diretta è lasciata all’iniziativa del singolo
l’istruzione in materia di accessibilità. Le fonti sono molteplici e possono essere
rintracciate proprio sul Web. Sicuramente significativi a questo proposito sono proprio i
siti istituzionali del W3C che contengono tutte le specifiche WAI.
Un punto di partenza potrebbe essere il documento di accessibilità in dieci punti fornito
dal consorzio2, per altro riportati e discussi in questa stessa tesi.
Personalmente mi auguro che questo stesso lavoro possa servire a fornire una prima
base formativa o quantomeno un punto di partenza per sviluppare il tema. A questo
proposto consiglio di accedere alle risorse in rete elencate al termine di questo scritto.
Articolo 9: Sanzioni.
La legge prevede, in caso di inadempienza, responsabilità dirigenziale e responsabilità
disciplinare.
1
A questo proposito segnalo la recente iniziativa del CNIPA in associazione con l’Università di Bologna per
l’istituzione di un Master in accessibilità e multimodalità del web organizzato a Cesena il 17 Novembre 2006.
2
[http://www.w3.org/WAI/References/QuickTips/]
- 259 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Questo allo scopo di muovere le acque a livello dirigenziale. Fino a che i dirigenti delle
amministrazioni chiamate in causa non avranno acquisito la necessaria sensibilità
personale al problema difficilmente la legge riuscirà a cambiare qualcosa.
A questo proposito vorrei dire che la mia personale esperienza nell’ambito della pubblica
amministrazione a più di due anni dall’entrata in vigore della legge conferma tutte le
resistenze incontrate nella sua applicazione. Rimando le osservazioni ed i commenti alla
relativa sezione di questa tesi.
Di fronte ad un rilevante sforzo normativo ed a una forte spinta da parte del ministero a
snellire la pubblica amministrazione si è andato incontro ad un vasto problema di
attuazione. La pubblica amministrazione digitale è un esempio di quest’inerzia radicata.
Le normative non sono mancanti da un punto di vista di responsabilizzazione
dirigenziale. In effetti, il testo della legge sancisce che il contratto possa essere
addirittura nullo e definisce anche delle precise responsabilità dirigenziali. In caso di
inosservanza non solo vi è l’obbligo a correggere la situazione, ma anche il contratto è
invalidato e il dirigente ne risponde in prima persona davanti alla Corte dei Conti.
Questo dovrebbe stimolare il dirigente a motivare e sorvegliare i suoi dipendenti che
vengono anche responsabilizzati nella realizzazione dell’accessibilità.
Nel momento in cui uno di loro accetta un incarico, se ne assume anche le
responsabilità. Il singolo dipendente può essere responsabile del codice che produce.
Purtroppo spesso non si tiene abbastanza in considerazione il fatto che la qualifica
richiesta per un simile onere non è indifferente, si richiedono competenze in diverse
materie spesso riscontrabili solo in un gruppo qualificato di persone.
Articolo 10: Regolamento di attuazione.
Questo articolo stabilisce la definizione di un regolamento di attuazione entro 90 giorni
dalla data di entrata in vigore della legge che definisca i criteri e i principi operativi e
organizzativi generali per l'accessibilità, i controlli esercitabili sugli enti e le modalità di
verifica. Il tutto previa consultazione con le associazioni delle persone disabili.
Il regolamento è entrato in vigore il 18 Maggio 2005 definendo i responsabili
dell’accessibilità. Costoro sono le persone preposte alla realizzazione concreta della
legge ed hanno diritto a chiedere all’ente centrale di competenza l’organizzazione dei
corsi di formazione creando un piano d’aggiornamento specifico per l’accessibilità di cui
sono responsabili come definito sull’articolo 9.
- 260 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il regolamento di attuazione non è riportato in appendice ma può essere facilmente
reperito sul sito del Ministero.1
Articolo 11: Requisiti tecnici.
Si rimanda alla pubblicazione, entro 120 giorni dalla data d’entrata in vigore della legge
delle linee guida recanti i requisiti tecnici ad opera del Ministro per l'innovazione e le
tecnologie, previa consultazione con le associazioni delle persone disabili maggiormente
rappresentative.
Questi requisiti tecnici sono il cuore della legge dal punto di vista di questa tesi e
verranno trattati in una sezione specifica successiva.
Articolo 12: Evolvibilità.
Un aspetto molto importante di questa legge è la sua possibilità di essere aggiornata
negli aspetti tecnici, un aspetto essenziale, dato il rapido sviluppo della materia di cui
tratta. Il decreto citato all’articolo 11 è periodicamente aggiornato, con la medesima
procedura, per il tempestivo recepimento delle modifiche delle normative di cui al
comma 1 e delle innovazioni tecnologiche nel frattempo intervenute.
Come hanno fatto rilevare i docenti del seminario, si tratta di una novità a livello
mondiale l’inserimento nel decreto delle regole tecniche con la previsione di un
aggiornamento. La normativa americana è difficilmente aggiornabile ed è rimasta ferma
al 2000.
L’evoluzione del decreto è prevista tramite una verifica periodica dello stato di
attuazione.
Nello stesso articolo si ribadisce anche come sia il regolamento di cui all'articolo 10 che
il decreto di cui all'articolo 11 siano stati emanati osservando le linee guida indicate
nelle comunicazioni, nelle raccomandazioni e nelle direttive sull'accessibilità dell'Unione
europea, nonché nelle normative internazionalmente riconosciute e tenendo conto degli
indirizzi forniti dagli organismi pubblici e privati, anche internazionali, operanti nel
settore.
A tale proposito va però aggiunto che, di fatto, non ci sono stati aggiornamenti alla
legge fino alla data di pubblicazione di questo lavoro, per quanto, come segnalato più
avanti, si stia parlando di un secondo decreto correttivo Campa Palmieri.
1
[http://www.pubbliaccesso.it/normative/regolamento.htm]
- 261 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il motivo di questa attesa è probabilmente nella imminente uscita del dispositivo finale
delle WCAG 2.0 a cui probabilmente un sostanzioso aggiornamento della legge Stanca
potrà ispirarsi.
Codice della Pubblica Amministrazione Digitale
Il codice1 della Pubblica Amministrazione digitale è stato approvato con Decreto Legislativo del
7 marzo 2005, n. 82, ed aggiornato con le modifiche introdotte dal Decreto Legislativo2 del 4
aprile 2006 recante disposizioni integrative e correttive. E’ entrato in vigore il 1 Gennaio 2006
Il codice prevede l’obbligo per le Pubbliche Amministrazioni di riorganizzare i propri siti
Internet in modo da individuare una serie di contenuti minimi e necessari, compresa la
disponibilità di moduli e formulari per via telematica.
Nell’intenzione del legislatore, la pubblica amministrazione digitale dovrebbe costituire un
deciso passo in avanti nella direzione dell’efficienza e della trasparenza dei servizi al cittadino
dopo quindici anni dall’approvazione della legge 142/90.
Caratteristiche fondamentali: i siti pubblici devono essere accessibili da tutti, anche dai disabili,
reperibili, facilmente usabili, chiari nel linguaggio, affidabili, semplici, omogenei tra loro.
I siti Internet devono diventare la porta privilegiata per entrare nelle pubbliche amministrazioni
e sono tenuti quindi a riportare alcuni dati necessari dell’ente per orientarsi:
L’organigramma per sapere chi fa cosa;
Gli indirizzi e-mail a cui rivolgersi per ciascuna necessità;
L’elenco dei servizi forniti in rete;
L’elenco di tutti i bandi di gara;
L’elenco dei procedimenti svolti da ciascun ufficio, con la loro durata e il nome del
responsabile.
La pubblica amministrazione digitale dovrà fornire tutti i servizi sportello, l’ufficio relazioni con
il pubblico, il pagamento on line dell’I.C.I.
Tutti i documenti all’interno delle amministrazioni centrali devono essere disponibili su formato
digitale. Per il momento questo è obbligatorio solo per le amministrazioni centrali, ma entro 2
anni dall’entrata in vigore le norme dovrebbero essere estese ulteriormente anche a quelle
decentrate.
1
2
[http://www.padigitale.it/home/testodecreto.html
[http://www.innovazione.gov.it/ita/normativa/allegati/dl_050307.pdf]
- 262 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Gli articoli 53 e 54 di questo documento riguardano anche le normative sui siti delle pubbliche
amministrazioni centrali obbligandole a rispettare i principi di accessibilità, nonché di elevata
usabilità e reperibilità, anche da parte delle persone disabili, di completezza di informazione, di
chiarezza di linguaggio, di affidabilità, di semplicità di consultazione, di qualità, di omogeneità
e di interoperabilità.
Per l’articolo 54 si richiede che le amministrazioni che già dispongono di propri siti realizzano
quanto previsto entro 24 mesi dall’entrata in vigore del decreto.
Per l’articolo 76, le disposizioni del presente codice entrano in vigore a decorrere dal 1°
gennaio 2006.
Ci sono state richieste di proroga, ma le norme sono inderogabili.
Come accennato in precedenza l’attuazione di questa normativa prevede, sempre per lo stesso
articolo 76, che le pubbliche amministrazioni dovranno adeguare i siti internet ai criteri di
accessibilità definiti nel regolamento di attuazione della legge 04/2004 anche se creano i siti
internet con risorse interne e anche se il contratto non lo preveda espressamente.
Va tenuto presente che, per quanto mi è dato a tutt’oggi da vedere, molte di queste
progettualità sono state ampiamente disattese e le critiche che si sono registrate sono
molteplici1, sia al testo della legge che alle sue modalità applicative.
Lo stesso sito2 è risultato vuoto almeno per tutto il periodo di scrittura di questo lavoro.
Regolamento di attuazione
Il Regolamento di attuazione (Decreto del Presidente della Repubblica, 1 marzo 2005, n. 75)
previsto all’articolo 10, approvato in Consiglio dei Ministri il 25 febbraio 2005, è stato
pubblicato sulla Gazzetta Ufficiale del 3 maggio 2005 ed è in vigore dal 18 maggio 2005.
Vi hanno collaborato le associazioni delle persone disabili, l’associazione degli sviluppatori
competenti in materia di accessibilità e i produttori di hardware e software.
L’iter di approvazione è stato piuttosto lungo ed elaborato. La legge ha dovuto passare molti
ministeri e molti commissioni parlamentari. Per questo motivo i tempi si sono piuttosto dilatati.
Articolo 1: Definizioni.
Vengono ribaditi e definite alcuni concetti essenziali della legge. Tra cui spicca quello
della verifica tecnica e soggettiva di cui tratta il regolamento. A questo proposito vale la
pena ricordare che la verifica tecnica può essere facilmente eseguita internamente in
1
2
[http://www.studiocelentano.it/editorial/articolo.asp?id=1031]
[www.padigitale.it]
- 263 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
maniera autonoma, anche con degli opportuni valutatori automatici o seguendo una
griglia di controllo per quanto sempre sotto la supervisione di un esperto. La verifica
soggettiva invece non è obbligatoria. Nel caso si decidesse di applicarla essa deve
essere eseguita solo presso il CNIPA. Uno stralcio di queste definizioni è riportato in
appendice.
Articolo 2: Criteri e principi generali dell’accessibilità.
Analogamente al primo articolo si propongono i requisiti dei servizi accessibili. Si
definisce il concetto di fruibilità ripreso dalla Norma ISO/IEC 9126 come:
Facilità e semplicità d’uso;
Efficienza nell’uso;
Efficacia nell’uso;
Soddisfazione nell’uso.
Nel seminario è stato più volte ribadito il concetto di fruibilità come l’usabilità applicata
sulla base dell’accessibilità.
Uno stralcio di questi requisiti è riportato in appendice.
Articolo 3: Valutazione di Accessibilità.
Il valutatore deve dare garanzia di imparzialità ed indipendenza. Occorre disporre di
figure professionali idonee e qualificate.
Dalla figura professionale e dalle competenze richieste, il valutatore è una figura il cui
operato richiede anche una certa onere di spesa. Per questo motivo il regolamento
definisce un tetto massimo per le valutazioni con una cifra aggiuntiva per pagina. Esiste
quindi un prezzario ufficiale per la valutazione. Alla data del seminario non era ancora
stato istituito un albo ufficiale di valutatori e nessuno era ancora qualificato per questo
intervento. L’albo dei valutatori è stato istituito successivamente con deliberazione
CNIPA del 15 settembre 2005.
Le pubbliche amministrazioni possono acquisire il parere non vincolante di un
valutatore, ma nel seminario è stato fatto notare che, essendo obbligatorio produrre dei
siti accessibili, non ha molto senso esporre il logo di base come disposto nell’articolo 5.
Questa condotta le sottoporrebbe necessariamente ad una successiva attività di verifica
e monitoraggio da parte del CNIPA.
Se, ad ogni modo, l’amministrazione pubblica volesse mettere in evidenza la propria
efficienza in merito, potrebbe rivolgersi ad un valutatore con l’obbligo di sostenerne le
spese. Si potrebbe richiedere di avere anche una verifica soggettiva del sito, oltre che
quella tecnica che potrebbe essere svolta in maniera autonoma. Stessa facoltà è data
agli enti privati, che comunque restano del tutto esentati dall’obbligo di sottoporvi i
propri siti.
- 264 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Articolo 4: Modalità di richiesta della valutazione.
Il logo di accessibilità è un marchio registrato del CNIPA e la sua esposizione deve
essere autorizzata. I soggetti privati possono farne richiesta.
Il logo vale per un anno, scaduto il quale è necessario ripetere la valutazione.
Necessario ripetere la valutazione anche in caso di revisione sostanziale come indicato
nell’articolo 6.
Nel seminario è stato ribadito come il concetto del logo, il cosiddetto bollino, ha spesso
spostato l’attenzione dal vero servizio fornito dalla validazione. Questo magari non tanto
per quello del CNIPA, che non può essere esposto dai privati senza esplicito rilascio e
valutazione ufficiale, quanto piuttosto per la gran quantità di bollini in circolazione
certificati dai vari valutatori automatici su internet. Il problema è stato affrontato in una
sezione apposita di questa tesi a cui si rimanda.
Un altro punto essenziale di questo articolo è che all’attuazione del presente articolo si
provvede nell’ambito degli ordinari stanziamenti di bilancio, senza nuovi o maggiori
oneri per la finanza pubblica. Anche questo argomento è stato ampiamente discusso.
Articolo 5: Logo attestante il possesso del requisito di accessibilità.
Nelle figure sotto riportate sono mostrati i loghi definiti dal CNIPA.
Il logo senza asterischi attesta il superamento della sola verifica tecnica, mentre gli altri
indicano un valore ottenuto durante la successiva verifica soggettiva.
Vengono riportati puramente a titolo di esempio. Ovviamente in questa sede non
attesta nessuna validità di accessibilità per il documento corrente.
Logo che risponde al primo livello di accessibilità, legato alla conformità ai requisiti
previsti per la verifica tecnica:
Figura 4 - Logo di conformità alla verifica tecnica
Logo che corrisponde al livello di accessibilità che attesta il superamento della verifica
tecnica e l’attribuzione, a conclusione della verifica soggettiva, di un valore medio
complessivo pari o maggiore di 2 e minore di 3:
- 265 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Figura 5 - Logo di conformità alla verifica tecnica e soggettiva primo livello
Logo che corrisponde al livello di accessibilità che attesta il superamento della verifica
tecnica e l’attribuzione, a conclusione della verifica soggettiva, di un valore medio
complessivo pari o maggiore di 3 e minore di 4:
Figura 6 - Logo di conformità alla verifica tecnica e soggettiva secondo livello
Logo che corrisponde al livello di accessibilità che attesta il superamento della verifica
tecnica e l’attribuzione, a conclusione della verifica soggettiva, di un valore medio
complessivo maggiore di 4:
Figura 7 - Logo di conformità alla verifica tecnica e soggettiva terzo livello
Il CNIPA ha recentemente pubblicato una lista dei pochi siti internet che hanno
raggiunto la validazione. Al Novembre del 2006 si possono contare solamente 23
istituzioni in grado di esporre questa qualifica. Un elenco completo è disponibile sul sito
del ministero1.
Articolo 6: Casi di aggiornamento della valutazione di accessibilità.
Si definiscono le norme e la prassi per le situazioni di aggiornamento della valutazione
di accessibilità.
Articolo 7: Poteri ispettivi di controllo sui soggetti privati.
Si definiscono le norme e i limiti dei poteri ispettivi di controllo sui soggetti privati.
Articolo 8: Uso del logo per le pubbliche amministrazioni.
1
[http://www.pubbliaccesso.gov.it/logo/elenco.php]
- 266 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
I soggetti della pubblica amministrazione che intendono utilizzare il logo sui siti e sui
servizi forniti, provvedono autonomamente a valutare l’accessibilità sulla base delle
regole tecniche definite con il decreto sui requisiti tecnici.
La valutazione positiva, previa segnalazione al CNIPA, consente l’utilizzo del logo.
Va segnalato che, anche in questo caso, come specificato nell’articolo 5, il logo senza
asterischi è quello riservato per la valutazione tecnica.
Articolo 9: Controllo delle Pubbliche Amministrazioni.
Questo articolo ribadisce la definizione della figura del responsabile della accessibilità
per ogni pubblica amministrazione, ruolo svolto, in mancanza di esplicita designazione,
dal responsabile dei servizi informatici.
In oltre, qualora siano riscontrate anomalie, viene richiesta all’amministrazione la
predisposizione del relativo piano di adeguamento con l’indicazione delle attività da
svolgere e dei tempi di realizzazione.
Requisiti tecnici (Decreto Ministeriale 8 Luglio 2005)
Sono stati approvati in via preliminare il 9 Luglio del 2004, ed il 1 Marzo 2005 sono stati
firmati dal Presidente della Repubblica.
Il decreto è stato emanato dal Ministero per le Innovazioni e le Tecnologie con atto del 8 Luglio
2005 ed è stato pubblicato sulla Gazzetta Ufficiale n. 183 dell'8 agosto 2005.
Il contenuto del decreto sono i Requisiti tecnici come previsto dalla legge 04/2004 all’articolo
11.
Il regolamento prevede che ci possano essere due tipi di verifiche, corrispondenti a quattro tipi
di attestati: una tecnica e tre livelli di verifica soggettiva.
La verifica tecnica è finalizzata ad ottenere l’accessibilità e conferisce l’esposizione del logo di
validazione del CNIPA senza asterischi. La verifica soggettiva invece include anche un'analisi
dell'usabilità del sito rispetto ad utenti disabili e conferisce il logo con asterischi (da 1 a 3).
Accanto a queste valutazioni specifiche per i siti internet ne esistono altre per il software
applicativo e per l’hardware.
Esistono quindi tre diverse tipologie per i requisiti tecnici di accessibilità:
1
2
Requisiti per l’Hardware di computer (7 requisiti, in allegato1 C);
Requisiti per il Software Applicativo (11 requisiti, in allegato2 D);
[http://www.pubbliaccesso.gov.it/normative/DM080705-C.htm]
[http://www.pubbliaccesso.gov.it/normative/DM080705-D.htm]
- 267 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Requisiti di accessibilità per i siti Internet (22 requisiti, in allegato1 A).
I requisiti per la verifica tecnica dei siti Web sono quelli che più hanno rilevanza all’interno di
questa trattazione.
I requisiti hardware e software non sono obbligatori al momento dell’acquisto del materiale
informatico, tuttavia costituiscono preferenza in appalto. Il concorrente che riesca a
soddisfarne di più acquisisce un titolo preferenziale.
I ventidue requisiti Web sono invece il nucleo del decreto ministeriale del 8 Luglio 2005 per
quanto riguarda gli scopi di questa testi. Sono validi per i siti internet e sono obbligatori per
tutte le pubbliche amministrazioni e per gli altri enti a partecipazione pubblica come specificato
in appendice. Per i privati restano facoltativi.
Si applicano anche ad intranet, ai CMS, agli applicativi di back-office ed in generale a tutti i
contenuti che vengano visualizzati dai browser.
I docenti del seminario di Arese hanno tenuto a preporre alla trattazione dei 22 requisiti del
decreto, un preliminare requisito 0 della legge stanca, ovvero quello del buon senso
nell’applicare le norme, perseguendone le finalità e non meramente le disposizioni formali.
I 22 requisiti Web sono riportati in appendice. Il testo integrale del provvedimento è disponibile
sul sito del ministero2.
Requisiti Hardware (7)
Requisiti tecnici di accessibilità per i personal computer di tipo desktop e portatili:
1. Requisito 1: “Il computer deve potersi collegare mediante canali standard a sistemi di
accensione remota.”.
Deve essere fornita al disabile una opportunità di accendere il computer con altre
strumentazioni che non siano solamente il bottone di accensione sul cabinet.
Al giorno d’oggi, soprattutto come conseguenza degli standard imposti dai produttori
americani tra cui Dell, IBM e HP in prima linea, tutti i computer in vendita supportano
questo requisito.
Un sistema per l’attivazione ad infrarossi spesso è previsto addirittura sulle schede
madri. Sono poche le macchine che non lo hanno o non lo supportano.
Nella sezione del BIOS sono in oltre supportabili dei sistemi di attivazione (wake-up)
configurabili anche per il vivavoce.
Di fatto, risulta definita una procedura standard per l’accensione dei personal computer.
1
2
[http://www.pubbliaccesso.gov.it/normative/DM080705-A.htm]
[http://www.pubbliaccesso.gov.it/normative/DM080705.htm]
- 268 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
2. Requisito 2: “I tasti e i pulsanti devono essere raggiungibili ed operabili con minima
abilità e con una forza massima di 2,3 Kg.”.
Sono imposti dei vincoli per la pressione da esercitare sulle tastiere. Le tastiere
moderne hanno un limite minimo di pressione a cui rispondono
Anche in questo caso, tutte le tastiere sono già conformi a questo requisito.
In aggiunta la tastiera deve essere anche configurabile per recepire le pressioni
contemporanee di comandi in modo sequenziale, ad esempio per la combinazione
CTRL+ALT+CANC. Questo tipo di funzionalità è svolta spesso dal sistema operativo a
cui è delegata la funzione. In oltre deve esistere anche uno spazio fra i tasti sufficiente
affinché possano essere operabili e raggiungibili.
3. Requisito 3: “I tasti e i pulsanti devono essere tattilmente percepibili, senza necessità
di attivarli.”.
Deve essere sempre possibile percepire la tastiera. In tutte le tastiere moderne sono
presenti sul tasto della lettera “F“ e sul tasto della lettera “J” dei rilievi in modo che
possa essere sempre possibile percepirle senza attivarla, tutte le tastiere sono a norma,
per merito della Section 508, già dall’anno 2000.
4. Requisito 4: “In presenza della funzionalità di ripetizione dei tasti, l’intervallo di tempo
sia per la prima ripetizione che per le ripetizioni successive, deve essere configurabile in
almeno 2 secondi.”.
La tastiera deve essere configurabile per la ripetizione, l’utente in oltre deve poter
configurare l’intervallo di ripetizione tasti in un intervallo di almeno due secondi.
L’interazione tra l’hardware e il software deve permettere il fatto che il tasto premuto
venga memorizzato per qualche istante di tempo ed eventualmente ripetuto dopo un
lasso di tempo definibile dall’utente. Queste informazioni sono preconfigurate nel BIOS.
5. Requisito 5: “Il diverso stato di attivazione dei tasti selezionati o bloccati deve essere
percepibile, oltre che visivamente, anche attraverso il tatto o l’udito.”.
Si tratta di non veicolare ad un solo canale sensoriale la notificazione dello stato della
tastiera. In pratica il fatto che, ad esempio, l’utente inserisca il caps lock non deve
essere notificato solamente da un avviso luminoso, ma deve essere possibile, anche da
sistema operativo, attivare l’emissione di un suono come notifica per il cambiamento di
stato.
Anche questo requisito, in pratica risulta sempre soddisfatto.
6. Requisito 6: “Deve essere presente almeno una porta di comunicazione conforme agli
standard industriali.”.
Deve essere possibile ai disabili inserire schede speciali adatte per la loro disabilità. In
pratica è sufficiente che sia presente sul computer almeno una porta conforme agli
standard industriali per avere la possibilità di collegare un hardware esterno.
- 269 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
7. Requisito 7: “Qualora venga utilizzata una forma di identificazione biometrica, deve
essere fornita una forma alternativa di identificazione.”.
Dal momento che ad un disabile potrebbe mancare qualche funzionalità fisiologica
specifica, si richiede di non fornire un hardware che consenta di identificarsi ad esempio
solo con un impronta digitale. In caso di rilevazioni biometriche occorre fornire
contemporaneamente più sistemi per l’accesso.
Requisiti Software (11)
1. Requisito 1: “Le funzioni previste dall’interfaccia utente devono poter essere attivate
anche attraverso comandi da tastiera nei casi in cui possa essere fornita una
descrizione della funzione stessa o del risultato della sua esecuzione.”.
Deve essere sempre possibile utilizzare le funzionalità implementate nel software anche
solamente da tastiera. Questa richiesta è direttamente ricavata dalla Section 508 che
possiede un requisito analogo nel paragrafo 1192.21.
In oltre, occorre fornire dei tasti di scelta rapida in modo che il software possa svolgere
tutte le sue funzionalità anche da tastiera. In pratica anche le funzionalità offerte da
tutti i bottoni grafici e dall’interfaccia devono essere raggiungibili da tastiera. Anche le
barre di scorrimento devono essere accessibili tramite comandi da tastiera.
Non ci devono essere delle funzionalità attivabili esclusivamente attraverso il mouse.
In alcuni software commerciali esistono degli oggetti per i quali, fin quando non sono
attivati con il mouse, non è possibile lavorarci, questi software sono inaccessibili per il
primo requisito.
2. Requisito 2: “Comandi e funzionalità dell’interfaccia utente non devono limitare o
disabilitare le caratteristiche e le funzionalità di accessibilità dell’ambiente operativo
documentate e rese disponibili dal produttore dell’ambiente stesso.”.
In pratica non si devono sovrapporre le funzionalità standard del sistema operativo,
come ad esempio i classici CTRL-V o CTRL-C. Questo punto è piuttosto delicato data la
molteplicità di funzionalità offerte dai vari sistemi. Un’utile raccolta d’informazioni e
supporto a questi comandi possono essere reperiti sui manuali del sistema o anche in
rete1.
In oltre ci si dovrebbe affidare alle API (Application Program Interface) previste dal
sistema per ogni funzionalità dell’applicazione.
1
[http://www.tiresias.org/guidelines/software.htm]
- 270 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
3. Requisito 3: “L’applicazione deve rendere disponibili sufficienti informazioni, quali gli
elementi identificativi, le operazioni possibili e lo stato, sugli oggetti contenuti
nell’interfaccia utente affinché le tecnologie assistive possano identificarli
interpretandone le funzionalità.”.
Richiede di fornire delle informazioni di tipo testuale per ogni elemento nell’interfaccia
come ad esempio lo stato attivo, disattivo, attivabile, in modo da consentirne
l’individuazione e l’attivazione/disattivazione anche agli utenti che utilizzano tecnologie
assistive o modalità di input tramite tastiera.
In pratica deve essere possibile avere una percezione dello stato del sistema. Ad
esempio, se esiste un pulsante con un’icona che invoca una certa operazione quando
premuto, questo bottone deve essere percepibile anche in maniera testuale. Ogni
oggetto presente in un’interfaccia dovrebbe essere identificabile dall’ambiente operativo
che, tramite API, consente alle tecnologie assistive di identificarne le caratteristiche.
Microsoft Windows adempie a questo requisito tramite l’implementazione delle MSAA
API (Microsoft Active Accessibility), come descritto in un capitolo di questo documento.
L’utente disabile deve essere a conoscenza dell’esistenza e dello stato di un pulsante
che svolge una qualche funzionalità non replicata altrove. Questo è anche lo scopo di
alcuni suggerimenti a comparsa che recano un testo alternativo.
4. Requisito 4: “Nel caso di simboli grafici utilizzati per identificare controlli, indicatori di
stato o altri elementi di programma, il significato assegnato a tali simboli deve essere
coerente nell’ambito dell’intera applicazione, ivi compresa l’interfaccia utente.”.
Quando simboli grafici sono utilizzati per identificare controlli il significato assegnato a
tali simboli deve essere coerente nell’interfaccia utente.
Questo requisito afferma che se viene presentata una icona in qualche punto, questa
non può mutare di significato in una parte differente.
Una richiesta che si applica anche per i suoni e non solo per le immagini.
5. Requisito 5: “Le informazioni di tipo testuale devono essere fornite utilizzando le
funzionalità dell’ambiente operativo previste per la visualizzazione del testo; in
particolare devono essere disponibili il contenuto testuale, la locazione del punto di
inserimento e gli attributi del testo.”.
Questo significa che dove presente un testo non si deve fornire una sua immagine
grafica, ma il testo stesso. Questo per il fatto che le tecnologie assistive non riescono ad
estrarre il testo dalla grafica.
6. Requisito 6: “L’applicazione che utilizza segnalazioni audio deve prevedere una
funzionalità equivalente di tipo visivo, seguendo le eventuali convenzioni dell’ambiente
operativo.”.
Un’attuazione del principio della multi-modalità.
L’applicazione che prevede segnalazioni di avvertimento basate su audio deve
- 271 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
prevedere una funzionalità equivalente di tipo visivo, seguendo le convenzioni
dell’ambiente operativo, se previste.
7. Requisito 7: “Per fornire informazioni, per indicare o per richiedere azioni non devono
essere utilizzati unicamente animazioni, elementi grafici o sonori e differenze di colori.”.
Anche in questo caso troviamo un esplicito richiamo al principio della multi-modalità. Si
richiede di utilizzare più canali sensoriali per veicolare le informazioni.
In oltre deve essere anche possibile anche interrompere il flusso del canale su richiesta
utente predisponendo dei controlli.
8. Requisito 8: “Le applicazioni non devono sovrapporsi alle scelte effettuate dall’utente
riguardo a livelli di contrasto, colori ed altri attributi di visualizzazione.”.
Si richiede di non variare le impostazioni del colore assegnate al sistema operativo e di
controllare la conformità degli elementi di interfaccia. Il fatto di mantenere le
impostazioni di grafica e colore come sono state impostate dall’utente permette al
disabile di continuare a lavorare con le configurazioni adatte alla propria menomazione.
In alternativa occorre permettere al software di ereditare le impostazioni di sistema. La
verifica pratica dell’adempimento a questa richiesta è molto semplice, è sufficiente
andare su pannello di controllo e cambiare tema, verificando che anche il software
cambi coerentemente.
9. Requisito 9: “L’interfaccia utente non deve contenere elementi di testo, oggetti o altri
elementi lampeggianti aventi una frequenza di intermittenza maggiore di 2Hz e minore
di 55Hz.”.
L’interfaccia utente non deve avere oggetti che producano crisi epilettiche. L’intervallo
di frequenza per crisi epilettiche varia tra 2 e 55 Hertz seguendo quanto specificato
nelle normative americane. Microsoft Office ha eliminato del tutto gli effetti di
animazione nel rilascio dei suoi ultimi prodotti.
10. Requisito 10: “L’elemento attivo (focus) di una interfaccia utente deve essere
chiaramente identificabile; la identificazione e la variazione del focus devono essere
segnalate a livello di interfaccia di programmazione (API) affinché le tecnologie assistive
possano gestirle; vanno altresì adeguatamente segnalati gli elementi che richiedono
obbligatoriamente un’azione da parte dell’utente.”.
Il focus è la posizione del cursore sullo schermo, deve essere ben definito ed esposto a
livello di interfaccia di programmazione in modo che le tecnologie assistive possano
rilevarlo. Un modo di visualizzarlo in un’interfaccia grafica è il cartiglio o bubble, un
suggerimento a comparsa che generalmente appare quando ci si passa sopra con il
mouse.
Si devono usare le API del sistema operativo per gestirlo e deve essere possibile
assegnare il focus a qualsiasi oggetto che rappresenti una informazione per l’utente.
Non sempre questa funzionalità era garantita nei software più datati.
- 272 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
11. Requisito11: “La documentazione di supporto al prodotto e le caratteristiche di
accessibilità devono essere rese disponibili anche in formato elettronico accessibile.”.
Ad esempio può essere in PDF purché tale documento sia formattato in maniera
corretta.
A differenza dei requisiti hardware che sono oggi generalmente tutti soddisfatti, quelli software
sono stati spesso disattesi in passato e anche al momento attuale sono pochi i grossi pacchetti
applicativi in commercio che siano in grado di soddisfarvi.
Secondo i docenti del seminario, fino al Maggio 2005, Microsoft Office era l’unico pacchetto da
ufficio pienamente compatibile con gli 11 requisiti. Il progetto Open Office ne rispettava solo 7
ed era ancora incompatibile anche con le Section 508 del governo americano.
Microsoft era in regola per la maggior parte degli applicativi. Tra gli altri pacchetti software di
qualità erano da segnalare anche GoLive e DreamWeaver.
Tra le grosse aziende produttrici quelle che maggiormente si distinguevano in fatto di
accessibilità erano IBM, Microsoft e Adobe con l’acquisto di Macromedia, da sempre le più
attente al problema. Adobe GoLive obbliga di fatto all’accessibilità, ripulendo automaticamente
il codice dai marcatori scorretti o male annidati e producendo direttamente i CSS.
Requisito Internet 1: Uso delle grammatiche.
“Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da
grammatiche formali pubblicate, nelle versioni più recenti disponibili quando sono
supportate dai programmi utente. Utilizzare elementi ed attributi in modo conforme alle
specifiche, rispettandone l'aspetto semantico [...].”
Si tratta del requisito base del decreto ministeriale1. Il primo requisito fonde diversi principi di
accessibilità in un solo enunciato. I numerosi riferimenti alle direttive WAI (WCAG 1.0: 3.1,
3.2, 3.5,3.6, 3.7, 11.1, 11.2) ne sono una evidente testimonianza. La richiesta di scrivere del
codice semanticamente valido obbliga anche alla correttezza e alla pulizia della pagina. Questo
requisito da solo, porta in sé, di fatto, gran parte dell’accessibilità e indirizza facilmente sulla
strada giusta per il superamento dei requisiti tecnici.
Per pagine e oggetti al loro interno, si intendono non solo i documenti (X)HTML ma anche
ActiveX, applet java ed oggetti in Flash eventualmente contenuti in esso. Per grammatica
1
Luca Mascaro: [http://www.webaccessibile.org/argomenti/argomento.asp?cat=532]
- 273 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
formale pubblicata si intende un documento testuale, delle specifiche riconosciute o anche i
dell’XHTML.
In pratica il requisito afferma che non è possibile non impiegare il formalismo, è obbligatorio
utilizzare gli standard riconosciuti e diffusi. Quindi non si possono realizzare pagine od oggetti
Web senza dichiararne la conformità a qualche specifica, anche se implicita come per i file
Adobe Acrobat o Microsoft Word.
Per quanto riguarda la conformità alle grammatiche formali, occorre ricordare che grammatica
formale in informatica non è nient’altro che una specifica o una raccomandazione tecnica
definita o in linguaggio naturale (documentazione) oppure in un linguaggio di definizione come
una DTD (document type definition) SGML oppure un XML Schema.
La conformità varia a dipendenza del tipo di definizione. Se per esempio prendiamo una
normale pagina Web che è definita in HTML o XHTML, la sua definizione è un file DTD.
Se invece fosse adottata una tecnologia descritta solo con un linguaggio naturale, dovremmo
semplicemente seguire le direttive in essa definite. Questo vale per esempio per le specifiche
di accessibilità dei documenti Acrobat dell’Adobe o Word della Microsoft.
La richiesta di adottare sempre le versioni più recenti disponibili quando supportate dai
programmi utenti, riporta direttamente all’evoluzione degli standard e delle raccomandazioni
tecniche che appena vengono supportate dalla maggior parte dei programmi utente
andrebbero adottate per le nuove risorse Web prodotte. L’argomento è stato trattato nel
capitolo sulle tecnologie obsolete.
Il CNIPA con la possibilità di aggiornare annualmente il decreto segnalerà quali versioni di un
determinato formato o linguaggio sono considerate supportate dai programmi utente.
L’ultima parte dell’enunciato richiede anche che il sito utilizzi tutti gli elementi specificati nel
linguaggio formale in maniera opportuna. Ad esempio, l’uso corretto degli acronimi, come
trattato in un paragrafo specifico delle metodologie generali.
Dati questi presupposti si richiede per tutti i siti di nuova stesura, che vengano prodotti
documenti in HTML, (possibilmente in XHTML) utilizzando esclusivamente la compatibilità
STRICT. Per un anno almeno è consentito l’utilizzo di grammatiche TRANSITIONAL per siti
esistenti, con alcuni vincoli e l’obbligo di predisporre un piano di adeguamento.
La scelta di richiedere un linguaggio nella versione STRICT deriva semplicemente dal fatto che le
versioni TRANSITIONAL delle specifiche in realtà sono state predisposte solamente per retro
compatibilità. Le future versioni XHTML sono quelle considerate “pure” e corrispondono alle
versioni STRICT. Tra gli attributi eliminati c’è il parametro TARGET per aprire le nuove finestre per
le motivazioni già indicate nella sezione delle metodologie.
Un importante punto di controllo di questo primo requisito richiede che quando esiste un
linguaggio di marcatura adatto, per veicolare informazione vada impiegato il marcatore
piuttosto che le immagini. Quindi, occorre conoscere una grammatica formale per una specifica
- 274 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
applicazione (ad esempio mathML) ed usarla ogni qual volta sia necessario, in luogo delle
immagini che sono illeggibili dagli screen-reader.
Altro richiamo essenziale è quello di usare elementi di intestazione per veicolare la struttura
del documento e usarli in modo conforme alle specifiche. In pratica la strutturazione del
documento va realizzata con gli appositi marcatori (ad esempio H1, H2 .. H6, utilizzati
opportunamente in sequenza), e non con tecniche di evidenziazione ad hoc. Questo per
l’importante principio di separazione fra contenuto e presentazione, come descritto nel capitolo
sull’utilizzo degli elementi strutturali.
La verifica e la validazione di una pagina HTML trova un utile supporto nei validatori automatici
forniti dai vari enti di normalizzazione o raccomandazione come il W3C, che però ricorda come
questi strumenti possano essere solo di supporto. Per esempio, il validatore HTML del W3C è in
grado di effettuare solo un controllo sull’annidamento corretto degli elementi e sull’uso dei
relativi attributi ma non sul corretto uso semantico e logico degli elementi nonché sui valori
inseriti negli elementi o attributi che andranno dunque verificati manualmente.
Altre verifiche possono essere compiute anche visivamente, soprattutto con l’ausilio della barra
dell’accessibilità con la quale spesso è possibile guardare la pagina e verificare ad occhio nel
codice come sono marcati per esempio acronimi e le abbreviazioni.
Per quanto riguarda la validazione ufficiale che verrà effettuata al CNIPA, i due docenti del
seminario, membri attivi del comitato di valutazione, hanno rimarcato il fatto che eseguiranno i
controlli tenendo conto del fatto che l’HTML, come molti altri linguaggi può subire ulteriori
trasformazioni in corso di elaborazione tramite linguaggi come JavaScript e DOM, questo ci
porta a non basare la loro validazione sul file HTML sorgente ma sul risultato finale dopo che
tutte le trasformazioni sono state eseguite.
Requisito Internet 2: Uso dei frame.
“Non è consentito l’uso dei frame nella realizzazione di nuovi siti. In sede di prima
applicazione, per i siti Web esistenti già realizzati con frame è consentito l’uso di HTML
4.01 o XHTML 1.0 con DTD frameset […].”.
Evitare l’uso dei frame. Per i siti già realizzati con frame occorre evitare gli attributi
presentazionali, ed utilizzare titoli significativi per i frame che indichino il loro scopo. In oltre
occorre progettare un piano di transizione ad grammatica formale di tipo STRICT che eviti
l’utilizzo dei frame ed inviarlo ad ministero per le Innovazioni e la Tecnologia. Per le
amministrazioni centrali, il piano deve essere presentato e concordato con il CNIPA.
La barra dell’accessibilità è in grado di fornire il controllo completo di tutti gli elementi. Si può
verificare, per ogni frame, i valori degli attributi NAME e TITLE in modo da controllare che, se
esitano, siano stati nominati correttamente come richiesto dalla legge.
- 275 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Requisito Internet 3: Alternative testuali.
“Fornire una alternativa testuale equivalente per ogni oggetto non di testo presente in
una pagina e garantire che quando il contenuto non testuale di un oggetto cambia
dinamicamente vengano aggiornati anche i relativi contenuti equivalenti predisposti
[…].”
In pratica si richiede che almeno venga aggiunto un attributo ALT per ogni immagine presente.
Ricadono in questa categoria anche immagini sensibili (mappe), rappresentazioni grafiche di
testo (compresi i simboli), animazioni (ad es.GIF animate), applet e oggetti, ASCII-art, frame,
script, suoni (azionati con o senza l'intervento dell'utente), file di solo audio, tracce audio di
video (multimedia) e video.
L’argomento è stato trattato in una sezione dedicata di questa tesi. Qui ricordo che l’alternativa
testuale deve essere descrittiva e riportare la funzionalità dell’oggetto più che il suo aspetto.
Quando la descrizione è necessariamente molto lunga può valere la pena di usare l’attributo
LONGDESC
che collega l’oggetto ad un file descrittivo esterno.
Aspetto significativo è che si richiede un opportuno aggiornamento dell’informazione in caso di
sincronizzazione con nuovi contenuti. Occorre infatti garantire che quando il contenuto non
testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi testi
alternativi. In questo caso la sincronizzazione implica che se un per un ricaricamento della
pagina l’immagine viene cambiata allora di conseguenza deve venire cambiato anche il
contenuto testuale fornendo una diversa descrizione associata.
Ancora una volta la barra dell’accessibilità risulta molto utile per visualizzare immediatamente i
testi associati fornendo un elenco dettagliato di immagini con tutti i testi alternativi.
Requisito Internet 4: Uso del colore.
“Garantire che tutti gli elementi informativi e tutte le funzionalità siano disponibili anche
in assenza del particolare colore utilizzato per presentarli nella pagina.”.
Non affidarsi unicamente al colore. Un esempio classico per un sito di una istituzione pubblica
sono gli avvisi dei bandi di gara, spesso si trovano in rosso quelli che stanno per scadere senza
fornire un'altra valida segnalazione accessibile, non bisogna basarsi esclusivamente sul colore
per nessuna informazione significativa ai fini della trasmissione del contenuto.
Questo tipo d’attenzione va posta anche per le voci del menu. Se, ad esempio, una voce di
menu si basa esclusivamente sul colore per evidenziare il fatto che sia attiva, questo viola il
requisito 4.
Una verifica è facile da eseguire utilizzando la barra accessibilità. Ad esempio si può togliere il
colore e impostare la visualizzazione in scala di grigi. Ricordo che, per quanto utile, questo test
- 276 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
non è ad ogni modo sufficiente. Molto utile è la funzionalità che permette di rimandare alla
creazione di pagine relative preparate per la simulazione dei difetti visivi.
Questo requisito è strettamente legato al requisito 6.
Requisito Internet 5: Lampeggiamenti.
“Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di intermittenza
possano provocare disturbi da epilessia fotosensibile o disturbi della concentrazione,
ovvero possano causare il malfunzionamento delle tecnologie assistive utilizzate;
qualora esigenze informative richiedano comunque il loro utilizzo, avvertire l’utente del
possibile rischio prima di presentarli e predisporre metodi che consentano di evitare tali
elementi.”.
Evitare gli sfarfallamenti e le scritte in movimento. Evitare in oltre anche gli oggetti o scritte
lampeggianti.
Anche per persone normodotate, gli oggetti lampeggianti possono distogliere dalla lettura, per
di più possono arrivare fino a causare problemi per utenti con disabilità cognitive o indurre crisi
epilettiche in soggetti ipersensibili.
In caso di necessità occorre avvertire l’utente in una pagina precedente e, nel caso lo
desiderasse, permettere di evitarle o di bloccare gli scorrimenti.
Il capitolo delle metodologie tratta l’argomento in un paragrafo apposito sui lampeggiamenti
degli oggetti.
Requisito Internet 6: Contrasto.
“Garantire che siano sempre distinguibili il contenuto informativo (foreground) e lo
sfondo (background), ricorrendo a un sufficiente contrasto (nel caso del testo) o a
differenti livelli sonori (in caso di parlato con sottofondo musicale); evitare di presentare
testi in forma di immagini […].”.
Utilizzare un contrasto adeguato sia per le immagini che per testi e per i contenuti audio.
Occorre garantire che siano sempre distinguibili il contenuto informativo e lo sfondo. Ad
esempio la voce in un’intervista deve essere ben distinguibile, oppure evitare di usare colori
chiari su fondo chiaro o colori scuri su fondo scuro.
Per quanto riguarda l’uso del colore questo punto è discusso anche nel requisito 4 ed è stato
analizzato nelle metodologie generali. Un sistema per gestire questo problema è di approntare
dei fogli di stile appropriati in modo che ogni utente possa adattare i colori alle proprie
problematiche.
La verifica si esegue con gli appositi validatori citati.
- 277 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Nel corso è stata fatta notare la dovuta critica alle WCAG 1.0 che hanno posto come punto di
controllo di terzo livello la richiesta di avere un adeguato contrasto fra testo e sfondo, come se
fosse un interesse facoltativo quello di consentire la lettura di testi a persone con disabilità
visive.
Interessante il fatto che la differenza di contrasto venga rimarcata anche per i contenuti audio,
una considerazione ripresa anche nelle WCAG 2.0.
Requisito Internet 7: Mappe lato client.
“Utilizzare mappe immagine sensibili di tipo lato client piuttosto che lato server, salvo il
caso in cui le zone sensibili non possano essere definite con una delle forme
geometriche predefinite indicate nella DTD adottata.”
Preferire le mappe immagini lato client.
Questo per il fatto che le mappe lato server inviano le coordinate del mouse al server e non
sono accessibile a chi utilizza browser testuali che non emulano il movimento e le funzionalità
del dispositivo di puntamento.
Le eccezioni sono dovute alla necessità di definire delle aree più accurate che non siano
disponibili con gli elementi di base delle mappe lato clienti, rettangolo, cerchio e figura
poligonale.
Uno degli ambiti di applicazione di questo requisito è quello della cartografia la cui
realizzazione lato server è praticamente irrealizzabile a causa dei problemi di gestione
alternativa del mouse.
Una verifica di accessibilità può essere opportunamente realizzata ancora una volta con la
barra di accessibilità che dispone di una specifica voce di controllo.
Requisito Internet 8: Mappe lato server.
“In caso di utilizzo di mappe immagine lato server, fornire i collegamenti di testo
alternativi necessari per ottenere tutte le informazioni o i servizi raggiungibili
interagendo direttamente con la mappa.”.
Utilizzo di collegamenti ridondanti per le mappe lato server.
Si tratta di un requisito che rende in pratica impossibile l’utilizzo di mappe lato server nel caso
di una gran mole di informazioni.
Per creare una mappa immagine sul lato server è necessario disporre di un’immagine in
qualunque formato supportato (preferibilmente formati non proprietari), di un codice
HTML/XHTML valido e soprattutto di un file di mappa immagine che definisce l’azione delle aree
sensibili.
- 278 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Nel caso sia necessario utilizzare un’immagine sensibile lato server, è necessario utilizzare dei
collegamenti testuali che garantiscano funzionalità equivalenti. Occorrerebbe fornire tutte le
informazioni con dei collegamenti alternativi di tipo testuale.
Fare siti accessibili in queste condizioni risulta estremamente dispendioso e lungo, soprattutto
per quanto riguarda il controllo di tutti gli aggiornamenti.
Difficile, quindi, se non impossibile fare siti accessibili con cartografie a causa dei problemi e
dei costi enormi che non possono essere nemmeno risolti con mappe lato client, inadatte per
ottenere la sufficiente granularità utilizzando le forme geometriche di base.
Requisito Internet 9: Tabelle dati.
“Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti dalla DTD
adottata per descrivere i contenuti e identificare le intestazioni di righe e colonne.”.
L’uso delle tabelle dati è un argomento di cui si è parlato diffusamente nelle metodologie
generali ed anche il decreto ministeriale italiano prevede dei requisiti per tabelle dati e per
quelle d’impaginazione.
In particolare per le tabelle dati richiede di usare gli elementi e gli attributi previsti dalla
grammatica formale del documento.
I marcatori opportuni a cui si riferisce la legge sono ad esempio l’attributo CAPTION utilizzato
per fornire un titolo, o l’attributo SUMMARY impiegato come una guida all’utente sul contenuto.
Altri elementi suggeriti sono gli elementi di scope, come HEADER e gli ID, con un loro corretto
utilizzo i programmi utente sono in grado di ripetere le corrette dizioni di intestazione per ogni
cella.
La barra di accessibilità fornisce informazioni dettagliate anche su tabelle per evidenziarne
chiaramente la struttura.
Un ottimo modo per implementare dei test sull’accessibilità delle tabelle dati, è quello di
utilizzare JAWS con una scheda audio. L’ideale sarebbe avere a disposizione anche persone con
disabilità che testano il sito con i loro strumenti hardware, il software da solo è insufficiente in
quanto dipende molto dalla capacità di saperlo utilizzare.
Requisito Internet 10: Tabelle dati complesse.
“Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti nella DTD
adottata per associare le celle di dati e le celle di intestazione che hanno due o più livelli
logici di intestazione di righe o colonne.”.
Per tabelle dati molto complesse si intendono soprattutto quelle che possiedono due o più livelli
logici di intestazione di riche o colonne,
- 279 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per queste, oltre ad applicare le norme relative al requisito precedente interenti tutte le tabelle
dati, occorre porre alcune attenzioni aggiuntive, in particolare si devono usare gli opportuni
elementi THEAD, TFOOT, e TBODY per raggruppare le righe in entità omogenee e COL, COLGROUP per
raggruppare le colonne. Ancora una volta la barra di accessibilità viene in aiuto per visualizzare
a colpo d’occhio la struttura di una tabella complessa.
Requisito Internet 11: Fogli di stile.
“Usare i fogli di stile per controllare la presentazione dei contenuti e organizzare le
pagine in modo che possano essere lette anche quando i fogli di stile siano disabilitati o
non supportati.”.
I fogli di stile vanno usati per controllare la presentazione dei contenuti secondo il principio
della divisione tra contenuti ed aspetti presentazionali come descritto accuratamente nelle
metodologie. In pratica si tratta di non inserire formattazioni ed elementi di grafica testuale
all’interno del file (X)HTML ma di riportarli all’interno dei fogli di stile.
I relatori del seminario di Arese hanno voluto ricordare questo proposito che l’utilizzo di fogli di
stile inclusi all’interno del (X)HTML non è consentito dalla normativa italiana.
In oltre Le pagine devono poter essere lette anche con i fogli di stile disabilitati.
Per verificare il requisito si utilizza la barra dell’accessibilità disattivando i CSS per verificare
facilmente anche ad occhio se, leggendola in linea, la pagina rimarne comprensibile. Si
possono disattivare separatamente sia i fogli di stile inline che quelli esterni.
Occorre ricordare che con i fogli di stile è possibile visualizzare delle sezioni della pagina anche
in ordine sensibilmente differente rispetto a come si presentano nel testo (X)HTML.
Requisito Internet 12: Impaginazione.
“La presentazione e i contenuti testuali di una pagina devono potersi adattare alle
dimensioni della finestra del browser utilizzata dall’utente senza sovrapposizione degli
oggetti presenti o perdita di informazioni tali da rendere incomprensibile il contenuto,
anche
in
caso
di
ridimensionamento,
ingrandimento
o
riduzione
dell’area
visualizzazione o dei caratteri rispetto ai valori predefiniti di tali parametri.”.
I contenuti della pagina devono potersi adattare alle dimensioni della finestra senza causare
sovrapposizione. Deve essere possibile una visualizzazione comprensibile anche
ridimensionando finestra e i caratteri in modo flessibile.
Questa disposizione favorisce sicuramente i cosiddetti layout liquidi, ad ogni modo non sono
vietati gli altri.
Si raccomanda di utilizzare misure relative dei caratteri piuttosto che quelle assolute, come
spiegato nelle metodologie generali.
- 280 -
di
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
I docenti del seminario hanno precisato che in sede di valutazione CNIPA il test sarà che le
pagine siano leggibili con risoluzione di 800 per 600 pixel, utilizzando i caratteri molto grandi.
Per la verifica si controllerà che non si sovrappongono le scritte o gli elementi.
Il requisito à pensato per le categorie di utenti ipovedenti. Costoro sono costretti ad aumentare
notevolmente la grandezza dei caratteri, di conseguenza occorre controllare che in tal caso non
si perda o si confonda l’informazione fornita.
Un’interessante tecnica di test è quella di utilizzare un apposito servizio messo a disposizione
su internet. Browser Cam1 consente di eseguire numerosi test multi piattaforma incrociando
differenti programmi utenti. Per utilizzare il servizio si fornisce l’indirizzo del sito e si ottiene
come risposta una quantità immagini ottenute impiegando svariati i caratteri, in diversi sistemi
operativi e con molteplici browser. I dati di ritorno di questo test possono essere costituiti
anche di un migliaio di immagini per singola pagina.
Requisito Internet 13: Tabelle di impaginazione.
“In caso di utilizzo di tabelle a scopo di impaginazione, garantire che il contenuto della
tabella sia comprensibile anche quando questa viene letta in modo linearizzato e
utilizzare gli elementi e gli attributi di una tabella rispettandone il valore semantico
definito nella specifica del linguaggio a marcatori utilizzato.”.”
La prima cosa da dire è che tabelle a scopo di impaginazione non sono esplicitamente vietate
dalla normativa italiana la quale, con questo enunciato, si mantiene in linea anche con le
raccomandazioni del W3C e con le ultime disposizioni delle WCAG 2.0 che consentono l’uso di
questi strumenti a fini presentazionali.
Ad ogni modo i docenti del seminario hanno precisato che la tendenza futura sarà quella di
arrivare ad eliminarle del tutto per questi scopi.
Allo stato attuale delle cose, la richiesta fondamentale, in caso si decidesse di usarle, è che il
contenuto sia comprensibile quando la tabella viene letta in modo linearizzato.
Una lettura linearizzata si rifà direttamente al codice (X)HTML leggendo la tabella nell’ordine
dei testi esposti all’interno della pagina sorgente.
Nel caso si utilizzasse una tabella per scopi d’impaginazione è importante non utilizzare alcun
marcatore di struttura a scopo di formattazione per non indurre i lettori a degli errori
d’interpretazione.
1
[http://www.browsercam.com/]
- 281 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Una valutazione con la barra dell’accessibilità permette di visualizzare i tag relativi alla tabella
e di visualizzarla anche i maniera lineare.
Requisito Internet 14: Moduli.
“Nei moduli (form), associare in maniera esplicita le etichette ai rispettivi controlli,
posizionandole in modo che sia agevolata la compilazione dei campi da parte di chi
utilizza le tecnologie assistive.”
Si tratta di una richiesta piuttosto agevole da ottemperare. Alcuni dubbi possono essere
sollevati sull’opportunità di compilare i campi con degli opportuni segnaposto come discusso
nelle metodologie e, di fatti, la legge italiana non richiede questa procedura limitandosi alla
richiesta di una necessaria e corretta associazione esplicita delle etichette.
La barra dell’accessibilità permette di controllare facilmente e di visualizzare queste
correlazioni esplicite.
Requisito Internet 15: Script ed Applet.
“Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di
programmazione sono disabilitati oppure non supportati […]”.
Le pagine devono essere utilizzabili anche senza script ed applet. Se questo non fosse possibile
occorre informare in maniera accessibile l’utente della funzionalità svolta dall’oggetto e fornire
una alternativa testuale equivalente tramite una pagina accessibile.
Il motivo guida di questa direttiva è di sviluppare le pagine in modo che siano fornite le
medesime funzionalità anche senza attivare queste metodologie.
In primo luogo è necessario usare l’elemento NOSCRIPT ogni qualvolta si abbia la necessità di
prevedere un codice alternativo per fornire funzionalità analoghe, ad esempio introducendovi
dei collegamenti alle pagine precedenti o successive, nel caso fosse quello il compito degli
script rimpiazzati.
Con la barra dell’accessibilità si disabilitano gli script per eseguire un test, e si verifica che
tutte le funzionalità siano comunque correttamente raggiungibili.
Occorre ricordare che gli script aumentano sicuramente la facilità di utilizzo ma molti utenti
disabili navigano con gli script disattivati mentre i browser più obsoleti non li supportano o li
supportano con molti errori.
Proprio per questi utenti che li lasciano abilitati occorre porre attenzione a fornire degli
equivalenti funzionali.
I docenti hanno ricordato che non è vero che gli script siano di per se inaccessibili, basta
tenere in considerazione gli opportuni accorgimenti. Come si realizza uno script lo rende
accessibile o meno, e questa è la cosa di maggiore importanza, come ribadito anche nel
- 282 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
requisito successivo.
Considerazioni analoghe valgono per tutti gli applet inclusi nella pagina e per la tecnologia
Flash.
Al seminario è stato fatto notare che per la valutazione di accessibilità, in caso di dubbio, il
valutatore CNIPA si rifarà al codice X(HTML) che presente nella memoria del computer.
Requisito Internet 16: Dispositivi di ingresso.
“Garantire che i gestori di eventi che attivano script, applet o altri oggetti di
programmazione o che possiedono una propria specifica interfaccia, siano indipendenti
da uno specifico dispositivo di input.”.
Navigando con JavaScript attivato o con applet funzionali, devono essere fornite pari
opportunità d’interazione per tutti i dispositivi di input.
Il requisito richiede che se ad un dispositivo d’ingresso vengono associati degli eventi, allora
eventi equivalenti debbano essere associati anche per gli altri dispositivi di ingresso. Ad
esempio, se viene associato una funzionalità all’evento ONCLICK deve necessariamente esserne
associata un'altra anche a ONKEYPRESS. Una trattazione su questo argomento è stata esposta
nelle parte delle metodologie.
Particolare riguardo va posto all’interattività con la tastiera, dal momento che spesso è
possibile emularne il funzionamento con tecnologie assistive, questo anche in considerazione di
una esplicita raccomandazione riportata al requisito 21.
Una facile valutazione di questo requisito si ottiene con la barra dell’accessibilità utilizzando la
gestione di eventi che riporta, di ogni singola funzione, gli eventi a cui è associata,
visualizzando la presenza o meno di eventi dipendenti dal dispositivo di input
Requisito Internet 17: Oggetti collegati.
“Garantire che le funzionalità e le informazioni veicolate per mezzo di oggetti di
programmazione, oggetti che utilizzano tecnologie non definite da grammatiche formali
pubblicate, script e applet siano direttamente accessibili.”.
Con questo requisito si vuole garantire che ogni oggetto collegato o incluso nel sito Web sia a
sua volta accessibile. Una verifica obbligatoria da svolgere per ogni oggetto aggiunto alle
proprie pagine e che riguarda anche i documenti in formato PDF, le animazioni in flash, gli
applet, e qualunque cosa che veicoli una informazione e che venga anche solo collegata
tramite un link.
Gli script, le applet e qualsiasi altro oggetto fornito di propria interfaccia deve essere
compatibile con le tecnologie assistive.
- 283 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per quanto riguarda il modo di farlo, si deve fare riferimento alle specifiche del produttore in
merito.
Se il produttore dell’oggetto dichiara delle modalità di accessibilità, l’oggetto collegato deve
seguire questi requisiti per essere incluso nella pagina.
Tale richiesta si basa direttamente sulle WCAG 1.0 del 1999 che focalizzavano la loro
attenzione solo sulle tecnologie Web delle grammatiche formali del W3C. Con la successiva
versione, il mondo delle tecnologie proprietarie, come ad esempio flash e PDF, viene coinvolto
più direttamente con il concetto di baseline. In questi casi isono i produttori che devono
decidere i modi corretti con i quali implementare l’accessibilità e gli sviluppatori del sito che
devono attenersi alle specifiche produttive per realizzare tali componenti.
Questo punto coinvolge anche la stesura di documenti corretti nei formati PDF e Microsoft
Word. Questi documenti hanno le loro interfacce esterne con i specifici marcatori di
accessibilità che il redattore deve conoscere e sapere utilizzare al momento di produrre un
documento. Un capitolo a parte di questo lavoro tratta l’argomento.
L’unico modo per testare approfonditamente gli oggetti collegati è quello di utilizzare una
tastiera verificando che le funzionalità e le informazioni siano accessibili.
Utile anche valutare l’oggetto con uno screen-reader.
Requisito Internet 18: Presentazioni multimediali.
“Nel caso in cui un filmato o una presentazione multimediale siano indispensabili per la
completezza dell’informazione fornita o del servizio erogato, predisporre una alternativa
testuale equivalente, sincronizzata in forma di sotto-titolazione o di descrizione vocale,
oppure fornire un riassunto o una semplice etichetta per ciascun elemento video o
multimediale tenendo conto del livello di importanza e delle difficoltà di realizzazione nel
caso di trasmissioni in tempo reale.”.
Qualora una presentazione multimediale fosse importante allora si deve predisporre una
informazione multi-canale che sia sincronizzata. Ad esempio se in un file video vengono fornite
informazioni audio importanti occorre predisporre una sotto titolazione (caption) o una
descrizione audio. La sezione apposita delle metodologie generali descrive queste tecniche.
Con la barra dell’accessibilità è possibile identificare i contenuti multimediali.
Anche nella legge Stanca viene tenuto in debito conto il concetto di sincronizzazione, da non
considerare eventualmente solo in caso di trasmissioni in tempo reale.
Requisito Internet 19: Collegamenti ipertestuali.
“Rendere chiara la destinazione di ciascun collegamento ipertestuale (link) con testi
significativi anche se letti indipendentemente dal proprio contesto oppure associare ai
collegamenti testi alternativi che possiedano analoghe caratteristiche esplicative,
- 284 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
nonché prevedere meccanismi che consentano di evitare la lettura ripetitiva di sequenze
di collegamenti comuni a più pagine.”
Il classico esempio che si porta ad esempio di questo requisito, è il generico “clicca qui” di
molti collegamenti ipertestuali, che non ha molto senso se letto al di fuori del proprio contesto.
A maggior ragione se ne esiste più di uno per pagina.
Deve essere possibile avere una valutazione sommaria di ogni collegamento ipertestuale
integrandoli con dei commenti che siano il più possibili significativi e ricchi di informazioni
tramite le quali l’utente è in grado di valutare il personale interesse per il rimando.
Un modo per realizzare questa richiesta è di usare l’attributo TITLE per identificare con
chiarezza la destinazione di ogni collegamento.
In questo requisito viene anche fatta presente la necessità di prevedere meccanismi che
consentano di evitare la lettura ripetitiva di sequenze di collegamenti comuni a più pagine. Per
fare questo occorre raggruppare i collegamenti correlati, identificare i gruppi e fornire un modo
per saltare il gruppo.
La valutazione complessiva del requisito viene fatta con la barra di accessibilità che fornisce
una lista dei collegamenti della pagina evidenziando l’eventuale attributo TITLE associato.
Requisito Internet 20: Eventi temporizzati.
“Nel caso che per la fruizione del servizio erogato in una pagina è previsto un intervallo
di tempo predefinito entro il quale eseguire determinate azioni, è necessario avvisare
esplicitamente l’utente, indicando il tempo massimo consentito e le alternative per
fruire del servizio stesso.”.
Un esempio classico di questa situazione è quello dei refresh automatici delle pagine, comuni
soprattutto ai siti delle agenzie che forniscono notizie in tempo reale.
Una buona prassi operativa è quella di non implementare servizi a tempo, oppure di
permettere agli utenti di impostare il tempo di refresh sui propri parametri.
Infatti, il caricamento automatico a intervalli predefiniti (auto-aggiornamento) della pagina può
causare problemi agli utenti che richiedono maggior tempo per leggere i contenuti, ed anche
coloro che utilizzano lettori dello schermo troveranno fastidioso un aggiornamento che li
costringa a ricominciare daccapo la lettura.
Utilizzando la barra dell’accessibilità si possono verificare nella sezione METADATA se ci sono voci
che impostano il tempo di auto-aggiornamento della pagina.
Requisito Internet 21: Accessibilità dei collegamenti.
“Rendere selezionabili e attivabili tramite comandi da tastiere o tecnologie in
emulazione di tastiera o tramite sistemi di puntamento diversi dal mouse i collegamenti
- 285 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
presenti in una pagina […].”.
I collegamenti ipertestuali presenti in una pagina devono essere attivabili e selezionabili anche
tramite tastiera. In oltre, è necessario che siano selezionabili separatamente e ben divisi gli uni
dagli altri. I collegamenti devono essere sufficientemente distanziati in modo da poter rendere
facile l’utilizzo dell’interfaccia anche da chi non ha un sistema di puntamento tipo il mouse.
La legge richiede che:
La distanza verticale di liste di link e la spaziatura orizzontale tra link consecutivi sia di
almeno 0.5 EM (in genere si consiglia almeno 1/1,5 EM)
Le distanze orizzontale e verticale tra i pulsanti di un modulo sia di almeno 0.5 EM
Le dimensioni dei pulsanti in un modulo siano tali da rendere chiaramente leggibile
l'etichetta in essi contenuta, per esempio utilizzando opportunamente il margine tra
l'etichetta e i bordi del pulsante.
L’ EM è un’unità di misura relativa, se utilizzata per definire la dimensione dei font rappresenta
la dimensione del carattere dell'elemento parent (ad esempio 0.80 EM indicano l'80% della
dimensione del carattere dell'elemento parent);
In genere si consiglia di impiegare almeno una volta e mezzo il carattere per le distanze,
Una valutazione di questo requisito può essere fatta passando da una voce di menù ad un altro
utilizzando il mouse, non deve mai verificarsi che nello spostamento rimanga fissa l’icona del
collegamento per il puntatore. Tra un collegamento ed un altro il puntatore deve modificarsi in
forma.
Requisito Internet 22: Pagine accessibili equivalenti.
“Per le pagine di siti esistenti che non possano rispettare i suelencati requisiti (pagine
non accessibili), in sede di prima applicazione, fornire il collegamento a una pagina
conforme a tali requisiti, recante informazioni e funzionalità equivalenti a quelle della
pagina non accessibile ed aggiornata con la stessa frequenza, evitando la creazione di
pagine di solo testo […]”
Questo requisito è una norma transitoria valida solo in sede di prima applicazione e solo per i
siti già esistenti. Non deve essere una scappatoia per il progettista.
Si parte dal riconoscimento comprovato di un’incapacità da parte del realizzatore del sito di
ottemperare per qualche pagina alle 21 norme precedenti.
In tal caso di conclamata incapacità professionale, per ogni singola pagina, quando non c’è
altro modo di ottenere il risultato, si può fornire un collegamento ad una pagina equivalente
per funzionalità e aggiornata con la stessa frequenza.
- 286 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il ricorso a pagine alternative è, ad ogni modo, scoraggiato, ed a maggior ragione lo è l’uso
sistematico di questa tecnica fino a realizzare un intero sito solo di pagine alternative spesso
anche di solo testo.
Va fatto notare con enfasi che la soluzione solo testo, spesso utilizzata anche da siti
istituzionali, non è conforme a questo punto di controllo in quanto non si tratta di pagina
equivalente che utilizza le tecnologie W3C.
Chi, nonostante tutto, decidesse di creare una specie di porta di servizio per l’accessibilità non
può dirsi in linea con gli standard del Web, non potrà dire che sta seguendo le WCAG, e
neppure la legge 04/2004.
Valutazione requisiti Internet
Per la valutazione dei requisiti Internet viene predisposta procedura definita in allegato A del
decreto intitolata “Metodologie per le verifiche tecniche” riportata in appendice.
In questa si suggerisce una metodologia di valutazione che faccia ricorso a strumenti
automatici e strumenti semiautomatici condotta da esperti sulla base di parametri tecnici.
La metodologia suggerita dal decreto ministeriale si basa su quella proposta dal W3C.
Le metodologie per la verifica tecnica sono quindi:
Verifica con sistemi di validazione automatica della rispondenza del linguaggio utilizzato
alla sua definizione formale. Tra gli altri si ricorda il servizio di validazione fornito dal
W3C1;
Utilizzo di strumenti semiautomatici di valutazione dell’accessibilità al fine di evidenziare
problemi non riscontrabili dalle verifiche automatiche. Una lista degli strumenti più
diffusi è reperibile nella pagina Evaluation, Repair, and Transformation Tools for Web
Content Accessibility del sito del W3C 2;
Verifica dell'esperto sull'uso degli elementi e degli attributi secondo le specifiche del
linguaggio;
Esame della pagina con diversi browser grafici, in differenti versioni e in diversi sistemi
operativi per verificare che:
a) Contenuto e funzionalità presenti in una pagina siano gli stessi nei vari browser;
b) La presentazione della pagina sia simile in tutti i browser che supportano le
tecnologie indicate al requisito 1;
c) Disattivando il caricamento delle immagini, contenuto e funzionalità della pagina
1
2
[http://www.w3.org/WAI/eval/]
[http://www.w3.org/WAI/ER/tools/]
- 287 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
siano ancora fruibili;
d) Disattivando il suono, i contenuti di eventuali file audio siano fruibili in altra forma;
e) Utilizzando i controlli disponibili nei browser per definire la grandezza dei font, i
contenuti della pagina siano ancora fruibili;
f)
La pagina sia navigabile in modo comprensibile con il solo uso della tastiera;
g) I contenuti e le funzionalità della pagina siano ancora fruibili (anche in modo
equivalente) quando si disabilitano fogli di stile, script e applet ed oggetti;
h) Esame della pagina con un browser puramente testuale come ad esempio Lynx 1.
Verificare che i contenuti e le funzionalità siano disponibili così come avviene nei
browser grafici e che mantengano il proprio significato d'insieme e la corretta
struttura semantica;
Verifica delle differenze di luminosità e di colore tra il testo e lo sfondo garantendo che
siano sufficienti, secondo gli algoritmi suggeriti dal W3C 2;
Redazione di un rapporto finale, per opera dell’esperto tecnico.
La prassi è quindi quella di un controllo approfondito delle pagine con diversi browser, anche
testuali, disattivando mouse, provando a navigare solo con la tastiera, senza fogli di stile,
senza applet e senza JavaScript.
La valutazione si conclude con la predisposizione di un rapporto nel quale l'esperto tecnico
indica la conformità ai singoli requisiti della pagina esaminata.
L'esperto tecnico è un professionista delle tecnologie Web che ha una adeguata esperienza e
conoscenza delle problematiche e delle tecniche per l'accessibilità equivalenti a quelle fornite
dal W3C WAI nel suo programma Education & Outreach.
La sua presenza in sede di valutazione è garanzia che, anche i soli controlli di verifica tecnica
non vengano svolti in maniera totalmente automatizzata.
Durante il seminario, i due docenti, hanno ricordato che la valutazione del CNIPA su sito
piuttosto voluminoso verrà eseguita valutando la pagina principale e tutte quelle di primo
livello più circa il 5% delle restanti secondo un campionamento casuale.
Gli strumenti a disposizione del CNIPA per la valutazione possono essere di qualità ben
maggiore di quelli in comune uso a privati e piccoli enti pubblici per raggiungere un grado di
funzionalità molto maggiore da mettere a disposizione in sede di valutazione. A fronte di un
1
2
[http://lynx.isc.org/current/]
[http://www.w3.org/TR/AERT#color]
- 288 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
costo sicuramente maggiore questo però fornisce un’analisi indubbiamente più approfondita e
significativa.
Verifica soggettiva
La verifica soggettiva è valutazione del livello di qualità dei servizi, già giudicati accessibili
tramite la verifica tecnica, effettuata con l’intervento del destinatario, anche disabile, sulla
base di considerazioni empiriche.
La verifica soggettiva non è obbligatoria per il raggiungimento del logo senza asterischi ed è
mirata più agli aspetti di usabilità piuttosto che a quelli di accessibilità in senso stretto. Ad ogni
modo un suo sunto essenziale viene fornito in appendice riportando anche i 12 criteri essenziali
che ne sono alla base.
Comparazione con la Section 508
Un immediato paragone con le WCAG 1.0 nasce spontaneo, anche per il fatto che nello stesso
dispositivo del Decreto Ministeriale sono riportati, al termine di ogni singolo requisito, i
riferimenti normativi alle raccomandazioni del W3C e alla legge americana.
Per di più lo stesso ministero ha fornito una tabella riassuntiva1 di relazioni tra WCAG 1.0, il
Decreto Ministeriale e le Section 508.
La seguente tabella vuol mostrare i legami tra i singoli requisiti previsti dalla verifica tecnica
della legge Stanca e i paragrafi dello standard 1194.22 della sezione 508.
Sebbene i legami siano descritti anche nel Decreto Ministeriale come appena fatto notare, in
questa sede s’intende fornire qualche informazione in più sulle relazioni tra le due normative
legali e capire in quali casi la legge Stanca è più o meno completa, precisa, generale della
sezione 508.
La tabella è stata curata da Giorgio Brajnik ed è riportata sul sito2 del Dipartimento di
Matematica ed Informatica dell’Università di Udine.
TABELLA 3 -CORRISPONDENZA TRA LA LEGGE STANCA E LA SECTION 508
Codice
validità sintattica
Legge Stanca
1: usare DTD
strict
Section 508
assente
Commento
legge Stanca
più forte.
(talvolta
1
2
[http://www.pubbliaccesso.gov.it/biblioteca/documentazione/ /corrispondenza_requisiti_wcag.htm]
[http://www.dimi.uniud.it/wq/stanca-mappa.html]
- 289 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Codice
Legge Stanca
Section 508
Commento
2: non usare i
(i): usare titoli
legge Stanca
frame; se si
informativi per i frame
più forte
3: fornire del
(a): analogo, con
equivalenti
testo
esempi citati
transitional);
usare i tag
secondo il loro
scopo, e non
per gli effetti
di
presentazione
Frame
deve allora
fornire titoli
informativi
Testo alternativo
alternativo ed
equivalente
colore
movimenti
4: colore non
(c): analogo
deve essere
508 non
l'unico modo
riportano
per veicolare
criteri
l'informazione
valutativi
5: evitare
(j): evitare immagini o
legge Stanca
immagini in
altro che causi
riportata le
movimento che
sfarfallio dello
frequenze solo
possano causare
schermo tra 2 e 55Hz
nei requisiti
epilessia
contrasto
Equivalenti, le
6: contrasto
software (n.9)
assente
visivo o
legge Stanca
più forte
uditivo elevato
Mappe lato client
7 e 8: usare
(e), (f): analogo,
mappe sensibili
anche se più concreto
equivalenti
lato client; se
si usano quelle
lato server,
fornire link
testuali
equivalenti
tabelle
9 e 10: usare
(g) e (h): analogo,
TH, SUMMARY,
anche se più concreto
CAPTION, SCOPE,
HEADER, AXIS
- 290 -
equivalenti
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Codice
Legge Stanca
Section 508
Commento
per le tabelle
dati
CSS
11: usare il
(d): le pagine devono
legge Stanca
CSS e fare in
funzionare se il CSS
più forte,
modo tutto
viene disabilitato
perché obbliga
funzioni anche
ad usare il CSS
quando viene
disabilitato
layout liquido
req. 12: la
assente
pagina si deve
legge Stanca
più forte
adattare alle
diverse
geometrie della
finestra e a
varie
dimensioni dei
caratteri del
testo
tabelle layout
13: le tabelle
assente
di layout
legge Stanca
più forte
devono
linearizzarsi
rendendo il
loro contenuto
comprensibile
form
14: associare
(n): usare LABEL e FOR
le etichette
per realizzare
alle form in
l'associazione, che
maniera
deve essere esplicita
equivalenti
esplicita
script
15: le pagine
(l): se le pagine usano
legge Stanca
devono
script per
più forte,
funzionare
aggiungere/modificare
perché impone
quando gli
il contenuto, allora ci
che gli script
script o altri
deve essere del testo
non debbano
programmi sono
descrittivo associato
essere
disabilitati
ai controlli che
necessari per
attivano tali
usare la pagina
funzionalità
gestori di eventi
16: usare
gestori di
(l): come sopra
legge Stanca
più accurata
- 291 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Codice
programmi inclusi
Legge Stanca
Section 508
Commento
eventi che
(richiede
funzionino col
gestori di
mouse e con la
eventi
tastiera
indipendenti)
17: i programmi
(m): i plug-in inclusi
inclusi nelle
nella pagina devono
pagine devono
rispettare gli standard
essere a loro
del software
equivalenti
volta
accessibili
multimedia
18: fornire
(b): analogo,
alternative
sincronizzazione
testuali, ev.
inclusa
equivalenti
sincronizzate
link informativi
19: rendere a-
assente
contestuali le
legge Stanca
più forte
etichette dei
link in modo
che siano
comprensibili
se tolti dal
loro contesto
skip-links
19: permettere
(o): analogo
equivalenti
(p): analogo
equivalenti
assente
legge Stanca
di saltare
oltre link
ripetitivi
azioni temporizzate
20: avvisare
l'utente
dell'eventuale
tempo massimo
uso della tastiera
21: rendere
selezionabili
più forte
da tastiera i
link di una
pagina
link distanziati
21: distanziare
tra loro link
adiacenti
orizzontalmente
o verticalmente
- 292 -
assente
legge Stanca
più forte
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Codice
solo testo
Legge Stanca
Section 508
Commento
22: se non
(k): se non altrimenti
legge Stanca
altrimenti
possibile fornire il
vieta le pagine
possibile,
collegamento ad una
solo testo,
fornire il
pagina di solo testo
mentre la
collegamento ad
equivalente
Section 508 le
una pagina
suggerisce come
equivalente
alternativa
accessibile, ma
non di solo
testo
Secondo disegno di legge Campa Palmieri
La Legge 4/2004 prevede, nell’articolo 12, che il decreto sui requisiti tecnici venga
periodicamente aggiornato, per il tempestivo recepimento delle modifiche delle normative e
delle innovazioni tecnologiche nel frattempo intervenute.
Di fatto, questo non è ancora avvenuto dal momento della promulgazione della legge.
Motivo di questa mancata attuazione è probabilmente l’attesa che un po’ da tutte le parti si sta
prestando alle imminenti WCAG 2.0 le quali avranno il compito di dare probabilmente un nuovo
impulso alla legislazione internazionale.
Nel frattempo invece ci sono alcune proposte correttive alla legge stessa.
Ad un anno dall'entrata in vigore del Decreto d’attuazione della legge Stanca, viene presentato
il nuovo progetto di legge Campa-Palmieri, che apporta due modifiche sostanziali alla legge
4/2004:
La prima modifica prevede l'obbligo di conformità ai requisiti tecnici della legge Stanca
ai siti Web (o ad una qualunque applicazione informatica) della pubblica
amministrazione anche quando questi non rappresentino l'istituzione di un nuovo
contratto con dei fornitori ma siano lo sviluppo di un progetto interno;
La seconda modifica riguarda l'attività di controllo: mentre la legge in vigore prevedeva
che solo il CNIPA potesse provvedere a monitorare i siti delle pubblica amministrazione,
con l'introduzione della nuova norma il Corecom (Comitato regionale per le
comunicazioni) potrà controllare e verificare l'uso corretto delle forme di comunicazione
on-line presso regioni, province autonome ed enti locali.
Le modifiche restano, peraltro, marginali e legate più che altro agli aspetti eminentemente
normativi e legali. I contenuti pratici restano immutati e per questi probabilmente dovremo
davvero aspettare l’uscita delle nuove raccomandazioni del W3C. Questo in particolare per
rivedere le richieste sulle modalità di utilizzo degli script nelle pagine.
- 293 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Stato di attuazione
I dispositivi predisposti dalla legge 4/2004 sono norme già in vigore nello Stato Italiano, norme
a cui non devono rispondere i privati come per il decreto legislativo 216/2003, ma che tuttavia
riguardano tutti gli enti pubblici ed altri enti correlati indicati nell’articolo 3.
Nonostante la portata di tale applicazione, ancora nel 2005, al momento della presentazione
della conferenza, due relatori lamentavano un riscontro molto negativo anche solo per la
semplice conoscenza delle norme. Una lacuna talmente grave che molte amministrazioni
comunali non erano nemmeno al corrente che quelle regole fossero già in vigore.
Posso aggiungere che, sebbene in quest’anno la situazione sia sicuramente migliorata per
quanto riguarda la conoscenza degli obblighi di legge, non vi sono tuttavia dei grossi progressi
concreti, soprattutto in fatto di atteggiamento mentale delle pubbliche amministrazioni.
In un articolo1 del Febbraio del 2006 apparso su punto informatico, Roberto Scano lamenta la
lenta applicazione della normativa in Italia, forse anche a causa di correnti di pensiero che
anziché promuovere l'applicazione della legge preferiscono scovarne i buchi, fornendo in
questo modo delle pericolose scappatoie alle amministrazioni pubbliche.
E’ un esempio il caso ampiamente trattato delle disponibilità di bilancio delle amministrazioni
comunali o il fatto che, evitando la stipulazione di un contratto e realizzando il sito con un
gruppo di lavoro interno non si è vincolati alla legge 4/2004.
Anche per questi motivi, il miglioramento della qualità è in mano, per ora, alla buona volontà e
alla sensibilità dei singoli. Grazie alla diffusione una tale attenzione alla accessibilità nelle
pubbliche amministrazioni si sta arrivando pian piano alla realizzazione di nuovi siti Web di
qualità altamente superiore e soprattutto accessibili.
In particolare per le amministrazioni centrali più esposte alle interazioni con il pubblico, si inizia
chiaramente a diffondere l'idea che chi non commissiona il sito accessibile oppure utilizza la
scappatoia dello sviluppo interno per utilizzare soluzioni non a norma è certamente qualcuno
che non fa l'interesse del cittadino, ed il conseguente danno di immagine è evidente. Delle
cattive scelte dei propri funzionari ne risponde poi politicamente l'amministrazione intera.
1
[http://punto-informatico.it/p.aspx?i=57852]
- 294 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
IV.5 - WCAG 2.0
(W3C WAI LAST CALL WORKING DRAFT - 27 APRILE 2006)
Si tratta, allo stato attuale, di un Last Call Working Draft.1 con l’aggiunta di un documento
provvisorio di revisione bozze2. Alla data di pubblicazione di questa tesi le WCAG 2.0 non sono
ancora state rilasciate dal W3C in formato Recommendation, il formato definitivo delle
normative W3C.
Durante il loro percorso, le WCAG 2.0 hanno subito parecchi cambiamenti, il primo dei quali è
stata la struttura stessa del documento che è arrivato più volte a modificare il numero delle
linee guida ed i livelli di conformità.
In questa panoramica essenziale si farà riferimento al Last Call Working Draft del 27 Aprile
2006, l’ultimo disponibile cronologicamente durante la redazione di questa tesi.
A causa di queste continue revisioni, non è infrequente trovare su internet dei documenti poco
aggiornati in materia, compreso, duole dirlo, quello in evidenza sullo stesso sito di
WebAccessibile3 che riporta una relazione di una conferenza tenuta a Prato nel 2003 da
Roberto Ellero, uno dei due membri italiani del gruppo di lavoro 4. Per quanto la relazione possa
essere rilevante e valida per i principi che espone, purtroppo la sua enunciazione è basata
ancora su un Working Draft del 2003, quando le linee guida erano ancora 19 mentre
attualmente sono 13.
Presentazione
Le WCAG 1.0, attuali punto di riferimento per l’accessibilità, sono state approvate nel maggio
del 1999 e sono l’unica versione stabile riconosciuta.
L’aggiornamento del progetto alla versione WCAG 2.0 è stato ritenuto necessario per:
1
2
3
4
Coprire anche le nuove tecnologie emergenti del Web;
Correggere le imprecisioni della versione 1.0;
Essere più semplici da usare e comprendere;
Essere più facilmente testabili.
[http://www.w3.org/TR/WCAG20/]
[http://www.w3.org/WAI/GL/WCAG20/]
[http://www.webaccessibile.org/argomenti/argomento.asp?cat=368]
[http://www.w3.org/WAI/GL/participants.html]
- 295 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Prima di esporle nel loro testo normativo vorrei definirle con un breve premessa storicovalutativa.
Evoluzione dalle WCAG 1.0
Il primo progetto delle WCAG 2.0 nasce già del 2000, immediatamente a ridosso della
pubblicazione conclusiva delle stesse WCAG 1.0 in forma di Recommendation. Un documento1
riassuntivo sullo sviluppo del progetto è disponibile sullo stesso sito del W3C.
Vediamo alcuni punti essenziali che contraddistinguono le nuove linee guida, come illustrato
dallo stesso sito del W3C:
Le WCAG 2.0 si applicano più ampiamente a differenti tecnologie Web e sono disegnate
per le tecnologie future;
Le disposizioni e le tecniche delle WCAG 2.0 sono più facilmente testabili;
Nelle WCAG 1.0 delle brevi descrizioni sono incluse nel documento principale sotto ogni
linea guida, con le WCAG 2.0 una guida completa per ogni linea guida viene fornita a
parte nel documento Understanding WCAG 2.0;
Le WCAG 1.0 sono state progettate intorno a delle linee guida, con punti di controllo a
priorità 1, 2 o 3. Le basi per determinare la conformità con le WCAG 1.0 sono i punti di
controllo. Le WCAG 2.0 invece sono organizzate intorno a 4 principi di progettazione per
l’accessibilità del Web. Ognuno di questi principi ha delle linee guida ed ogni linea guida
ha dei criteri di successo di livello 1, 2 o 3. La base per determinare la conformità di un
sito alle WCAG 2.0 sono i criteri di successo;
Le WCAG 2.0 introducono un nuovo concetto definito baseline che permette di separare
i principi dalle tecniche di realizzazione, con la finalità di impedire un precoce
invecchiamento delle linee guida con lo sviluppo della tecnologia.
A detta dello stesso sito del W3C, la maggior parte dei siti Web che siano già conformi alle
WCAG 1.0 non dovrebbero richiedere significative modifiche per essere resi conformi anche al
nuovo standard.
Le WCAG 1.0 sono state modificate intervenendo con un profondo intervento di ristrutturazione
e di riprogettazione introducendo anche delle sostanziali novità di concetti.
Alcuni di questi miglioramenti includono:
1
Rimozione di linee guida ritenute obsolete, tra le quali:
[http://www.w3.org/WAI/GL/WCAG20/change-history.html]
- 296 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
o
1.5: Fornire collegamenti di testo ridondanti per ogni zona attiva nella mappa
immagine sul lato client;
o
9.5: Fornire scorciatoie da tastiera per i collegamenti importanti;
o
10.3: Fornire un testo lineare alternativo per tutte le tabelle che dispongono
testo su colonne parallele;
o
10.4: Inserire caratteri predefiniti come segnaposto nelle caselle per
l'immissione di testo;
o
10.5: Inserire caratteri stampabili per separare i collegamenti adiacenti;
Impiego di nuove tecniche, come ad esempio:
o
Uso dei JavaScript per aprire dei collegamenti sulle finestre nuove;
o
Fornire un’intestazione all’inizio di ciascuna sezione;
Nuovi principi considerati, ad esempio:
o
Inserimento di messaggi di errore nei moduli;
o
Inserimento di un titolo descrittivo e significativo per ogni pagina;
o
Disattivazione dei suoni di sottofondo;
Neutralità rispetto alle tecnologie:
Le WCAG 1.0, nella linea guida 11, richiamano all’uso stretto delle tecnologie W3C,
richiedendo che sito debba fornire un’alternativa accessibile a JavaScript, PDF e Flash
quando le tecnologie assistive come gli screen-reader non possano accedervi. Sebbene
tutto questo fosse urgente nel 1999, ora non lo è più. JavaScript, PDF e Flash possono
essere tutti resi accessibili alla maggior parte delle tecnologie assistive tramite una
corretta progettazione di questi elementi.
Per evitare un precoce invecchiamento delle normative con il progredire della
tecnologia, il W3C ha deciso di rendere le nuove linee guida tecnologicamente neutrali.
La neutralità rispetto alle tecnologie ha portato all'eliminazione di quelle linee guida che
avevano un supporto specifico: per esempio quelle sull’uso dei fogli di stile per
controllare la presentazione dei documenti e quelle sulle modalità di realizzazione delle
tabelle. I principi guida possono poi trovare specifica attuazione nel documento di
tecniche soggetto a modifiche nel tempo.
Un utile nota riepilogativa di questi ed altri aggiornamenti si trova nella stessa appendice1 D
delle WCAG 2.0.
1
[http://www.w3.org/TR/WCAG20/appendixD.html]
- 297 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Schema del progetto
Sono disponibili 4 documenti base1 sul sito del W3C:
Web Content Accessibility Guidelines 2.0, Last Call Working Draft: la bozza ufficiale
delle linee guida del W3C WAI;
WCAG 2.0 Quick Reference, Working Draft: un documento di supporto che elenca i
requisiti base delle WCAG 2.0 e le tecniche sufficienti per soddisfarli;
Techniques for WCAG 2.0, Working Draft: un documento di supporto che fornisce i
dettagli specifici su come sviluppare contenuti Web accessibili con esempi in codice
HTML, CSS, SMIL e script;
Understanding WCAG 2.0, Working Draft: un documento di supporto che contiene
suggerimenti supplementari per l’apprendimento e l’implementazione delle WCAG 2.0
descrivendo come soddisfare ogni criterio di successo.
In oltre sono in fase di studio altri documenti addizionali sugli aspetti tecnici per coloro che non
sono sviluppatori esperti in fatto di accessibilità:
Application Notes, che dovrebbe fornire suggerimenti per argomenti specifici come ad
esempio immagini, collegamenti ipertestuali, moduli e tabelle;
Quick Tips to Make Accessible Web Sites: che dovrebbe riassumere i concetti cardine
della progettazione accessibile.
Allo stato attuale delle cose il modo migliore per incominciare a lavorare con le WCAG 2.0 è il
documento di riferimento rapido WCAG 2.0 Quick Reference che considera le linee guida e i
criteri di successo in relazione alle tecniche supportate.
E’ possibile configurare il documento di riferimento rapido in relazione a quali delle tecnologie
Web si vogliano impiegare, come ad esempio CSS, JavaScript ed altre, ed in relazione al livello
di accessibilità che si intende raggiungere.
Come spiegato in seguito, i criteri di successo sono degli assunti verificabili nella
pratica che permettono di controllare fino a che punto il contenuto Web sia conforme
alle WCAG 2.0. Ci sono diverse tecniche elencate per ogni criterio di successo, se queste
tecniche vengono implementate si soddisfa al criterio medesimo. Sono presenti anche alcuni
elenchi degli errori più comuni e delle prassi operative che non soddisfano alle linee guida.
All’interno del documento di riferimento rapido sono presenti dei collegamenti ipertestuali che
rimandano alla relativa sezione del documento Understanding WCAG 2.0.
1
[http://www.w3.org/WAI/intro/wcag20]
- 298 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per ogni criterio di successo vengono definiti:
Gli intenti, i significati e gli scopi;
Esempi;
Tecniche addizionali;
Ulteriori informazioni su come venire incontro alle persone disabili.
Intenti programmatici del W3C
Lo scopo delle WCAG 2.0, come lo stesso W3C le ha presentate in un intervista1 a Shawn
Henry del Giugno del 2006, è quella di essere molto più appropriate per gli sviluppi
presenti e futuri del Web.
Le WCAG 1.0 sono state rilasciate nel Maggio del 1999 ed erano focalizzate sull’HTML. Molte
cose sono cambiate da allora, le 2.0 sono incentrate su tecnologie differenti e più complete, e
sono aggiornate allo stato degli sviluppi attuali, in oltre sono disegnate in modo che possano
applicarsi anche alle tecniche future, come ad esempio AJAX.
Questo tipo di tecnologia viene considerata sia nelle WCAG 2.0 che nel progetto ARIA del WAI
sviluppato a parte.
Le nuove linee guida sono differenti dalle precedenti. Anche per questo il progetto è integrato
con un documento riferimento rapido che elenca le linee guida e i criteri di successo in
relazione alle tecniche che le implementano. Da questo punto di vista, considerare le linee
guida insieme ai loro criteri di successo, consente agli sviluppatori di comprendere le finalità e
come progettare per soddisfare questi criteri. Esiste un documento2 che offre delle risposte agli
utilizzatori delle WCAG 1.0 spiegando quali sono le motivazioni delle nuove linee guida e quali
sono i più comuni errori.
Sono a disposizione molte informazioni di supporto che dovrebbero aiutare gli sviluppatori a
comprendere ed implementare le nuove WCAG 2.0.
Una particolare attenzione è stata posta nella testabilità delle linee guida, in previsione del
fatto che potrebbero essere impiegate come base normativa per eventuali leggi nazionali.
Ovviamente non è possibile fare a meno di un controllo umano per valutare alcuni dei criteri di
successo: l’attenzione verso una migliore testabilità delle linee guida riguarda la possibilità di
un migliore controllo automatico via software.
Un altro elemento portante ed innovativo è l’attenzione posta in fase progettuale
all’adattamento nei confronti delle tecnologie emergenti.
1
2
[http://www.w3.org/WAI/highlights/200606wcag2interview.html Shawn Henry]
[http://www.w3.org/TR/UNDERSTANDING-WCAG20/]
- 299 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il Web si è evoluto considerevolmente dal giorno del rilascio delle WCAG 1.0 nel 1999. Le
WCAG 1.0 sono state scritte con l’assunto che gli utenti del Web avrebbero usato
essenzialmente l’HTML.
A giorni nostri il Web è usato in molti modi differenti che non sarebbero stati possibili nel 1999.
Stanno emergendo molte nuove tecnologie e anche quelle esistenti stanno diventando più
complete, man mano che la comunità degli utenti trova nuovi sistemi per diffondere e
interagire con le informazioni. Per di più, a causa delle differenze economiche, di cultura e di
altri fattori, le tecnologie che sono considerate comuni in alcune parti del mondo non lo sono
affatto in altre.
Stando questo stato di fatto il gruppo di lavoro del W3C ha inteso fondare su basi diversificate
la versione 2.0 delle WCAG. L’intento era di presentare l’accessibilità del Web come un
insieme di principi da applicare su tutte le tecnologie attuali, sufficientemente robusto da
adattarsi anche agli strumenti futuri.
Per conseguire questi scopi il gruppo di lavoro del W3C ha sviluppato un insieme di linee guida
e di criteri di successo indipendenti, con lo scopo di consentire di raggiungere una conformità
sfruttando qualsiasi tecnologia Web che supporti l’accessibilità.
Le WCAG 2.0, perciò, non richiedono o proibiscono l’uso di una tecnologia specialistica.
E’ possibile adeguarsi alle WCAG 2.0 usando o meno le tecnologie native del W3C 1.
Questo insieme di linee guida universalmente valide è presentato in maniera esaustiva nel
documento a carattere normativo: Web Content Accessibility Guidelines 2.0. Understanding
WCAG 2.0 è invece un documento a carattere informativo che fornisce gli esempi ed una lista
di tecniche adatte a soddisfare i criteri di successo.
Questa politica di divisione in due strati rende possibile avere dei criteri stabili per
l’accessibilità con il supporto di un documento squisitamente tecnico che può facilmente essere
aggiornato man mano che le tecnologie si evolvono e vengono sviluppate nuove possibilità di
soddisfare i criteri di successo.
Un elemento chiave per questo modello è la capacità di definire l’insieme di tecnologie
supportate dai programmi utente. Non è corretto supporre che i programmi utente, incluse
le tecnologie assistive supportino tutte le nuove tecnologie dal momento stesso che sono
annunciate. E’ necessario qualche meccanismo che definisca quali di queste si suppone
possano essere presenti nei programmi utente.
1
“WCAG 2.0, therefore, does not require or prohibit the use of any specific technology. It is possible to
conform to WCAG 2.0 using both W3C and non-W3C technologies” – WCAG 2.0
- 300 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Tuttavia definire un insieme fisso di tecnologie e chiuderle nelle WCAG 2.0 le renderebbe
immediatamente obsolete, come è stato per le WCAG 1.0.
La soluzione di questo problema, innovativa rispetto all’impianto della versione precedente, è
stata quella di definire una cosiddetta baseline.
Baseline
La linea guida 11 delle WCAG richiede di utilizzare le tecnologie del W3C, le WCAG 2.0
riconoscono che nuovi strumenti si sono imposti nella rete ed altri continuano a nascere
influenzando il Web in maniera positiva.
Con le WCAG 2.0 non s’intende scoraggiarne l’uso. Di conseguenza è possibile usare qualsiasi
tipo di tecnologia, anche non proprietaria del W3C, ed ottenere un sito conforme alle WCAG
2.0.
Per questo le WCAG 2.0 sono basate su un insieme di principi che sono indipendenti dalla
tecnologia e che sono capaci di incorporare anche quelle emergenti, comprese quelle esterne al
W3C. Piuttosto che definire una volta per tutte l’elenco che si suppone siano supportate dai
programmi utente, le WCAG 2.0 introducono il concetto di baseline.
Vediamo di cosa si tratta.
Nello scegliere l’insieme delle tecnologie (HTML, script, CSS, eccetera) che saranno impiegate
al momento di predisporre i contenuti, i progettisti hanno bisogno di sapere quali di queste
sono da considerare come disponibili e attive nei programmi utente che verranno impiegati.
L’insieme di tali tecnologie che un progettista considera come disponibili ed attive nei
programmi utente è definito come baseline1.
I progettisti devono garantire che tutte le informazioni e le funzionalità di un contenuto Web
siano conformi alle WCAG 2.0 dato per assunto che i programmi utente supportino tutte le
tecnologie dichiarate nella baseline e che queste siano attivate. E’ possibile impiegare anche
tecnologie non dichiarate nella baseline, ma in tal caso tutte le informazioni e le funzionalità
del sito devono essere fruibili, sia che queste siano attive o meno.
Il concetto di baseline è che il progettista o qualche autorità competente può definire l’insieme
dei requisiti minimi che deve essere supportato dai programmi utente. Gli sviluppatori sono
liberi di impiegare le altre tecnologie non dichiarate nella baseline, con l’assicurazione però di
non basarsi esclusivamente su quelle tecnologie per veicolare qualunque informazione o
funzionalità in modo che i contenuti siano ancora accessibili ed utilizzabili anche dalle persone i
cui programmi utente siano compatibili con i soli requisiti dichiarati nella baseline.
1
“set of technologies assumed to be supported by, and enabled in, user agents” –
[http://www.w3.org/TR/WCAG20/appendixA.html#baselinedef]
- 301 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In particolare:
Tutte le informazioni e le funzionalità del contenuto della pagina Web devono essere
disponibili impiegando un programma utente che sfrutti solamente la tecnologia della
baseline;
La presenza di tecnologie aggiuntive non deve limitare la capacità degli utenti di
accedere al contenuto tramite le tecnologie definite nella baseline.
Una baseline può essere definita da differenti organismi, tra i quali, gli stessi progettisti,
organizzazioni, clienti, enti governativi. Le WCAG, proprio per la filosofia di progetto, non
specificano nessuna baseline particolare.
Nella dichiarazione di conformità alle WCAG 2.0 di un sito, lo sviluppatore deve specificare la
baseline che sta impiegando.
In sostanza, al momento della dichiarazione, un progettista dichiara che il contenuto sia
adeguato alle WCAG 2.0 ad un definito livello di conformità per i programmi utente che
supportino la tecnologia elencata nella baseline.
Vediamo alcuni esempi di baseline, tratti dagli stessi esempi del W3C:
Un sito governativo che fornisce informazioni al pubblico. La baseline include solo
tecnologie che possano essere ampiamente supportate da molti programmi utente in
versioni differenti, ad esempio richiedendo solo HTML 1.0 TRANSITIONAL, .GIF, .JPEG.
Questa è una baseline estremamente limitata e potrebbe essere appropriata per un
pubblico molto ampio nel caso che non si sappia specificatamente quali programmi
utente sono disponibili. E’ possibile che la baseline venga aggiornata con il tempo
rispecchiando gli adeguamenti degli strumenti a disposizione del pubblico;
Baseline con JavaScript. Dal momento che JavaScript è elencato nella baseline, si può
contare sulle tecniche sugli script definite come sufficienti in Understanding WCAG 2.0
per produrre del contenuto conforme e non sarà necessario offrire un contenuto
alternativo che lavori con i JavaScript disabilitati;
Un ente pubblico fornisce direttamente ai cittadini che ne abbiano bisogno un
programma utente che garantisca un alto livello di accessibilità con delle nuove
tecnologie. In questo modo l’amministrazione è in grado di definire una baseline che
comprenda queste nuove tecnologie dando per assunto che i cittadini abbiano
programmi utente che le supportino;
Un’intranet privata. Una società pubblica o privata fornisce ai propri dipendenti uno
strumento adatto al loro lavoro. La baseline per il sito internet usato solo dagli impiegati
include le nuove tecnologie implementate dai programmi utente forniti ai dipendenti.
Giacché la compagnia controlla i programmi utente usati per la visualizzazione del
contenuto, il progettista ha una conoscenza molto accurata delle tecnologie a
disposizione.
- 302 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Le baseline non sono definite in termini di programmi utente, quanto piuttosto in termini di
tecnologie per il Web che devono essere supportate in quei programmi utente, ad esempio
HTML STRICT, HTML TRANSITIONAL, XHTML 1.1, CSS, GIF, JPEG, script eccetera.
La baseline deve essere dichiarata ed appare esplicitamente nell'enunciato di conformità.
Una spiegazione molto completa e dettagliata del concetto di baseline è disponibile in inglese
sul sito dello stesso W3C1.
Organizzazione
Le nuove linee guida sono stilate su una organizzazione a livelli:
Principi base (Principles):
o
Linee guida (Guidelines):
Criteri di successo (Success Criteria) cioè condizioni sufficienti per
determinare la soddisfazione della linea guida.
Ogni principio è articolato in linee guida ed ogni linea guida in criteri di successo.
Il termine punto di controllo (Checkpoint) delle precedenti WCAG 1.0 è stato eliminato.
Allo stato attuale della bozza ci sono 4 principi, 13 linee guida e 62 criteri di successo.
I 62 criteri sono suddivisi in 3 livelli, in base alla complessità di applicazione: 23 di livello 1, 18
di livello 2, e 21 di livello 3.
Conformità
La conformità del sito significa che il sito soddisfa ai criteri di successo definiti nel documento
del W3C.
Come detto, i criteri di successo per ogni linea guida sono organizzati in 3 livelli:
Criteri di successo di Livello 1: Raggiungono un livello minimo di accessibilità. Possono
essere ragionevolmente applicati a tutto il contenuto Web;
Criteri di successo di livello 2: Raggiungono un livello avanzato di accessibilità. Possono
essere ragionevolmente applicati a tutto il contenuto Web;
Criteri di successo di livello 3: Raggiungono un livello ulteriore di accessibilità. Possono
non essere necessariamente applicati a tutto il contenuto Web.
1
[http://www.w3.org/WAI/WCAG20/baseline/]
- 303 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La conformità di tipo tripla-A richiede solamente una conformità ad una parte dei criteri di
successo di livello 3, poiché non tutti i criteri di successo di livello 3 possono essere impiegati
con tutti i tipi di contenuto.
Le linee guida non contengono necessariamente criteri di successo per ogni livello.
Questa modalità di raggruppare i criteri di successo differisce in modo sostanziale dal sistema
usato per le WCAG 1.0. In quel caso ogni punto di controllo aveva assegnato una priorità in
relazione al suo impatto sull’accessibilità, così che i punti di controllo di priorità 3 risultavano
essere meno importanti di quelli di priorità 1.
Il gruppo di lavoro delle WCAG ritiene che tutti i criteri di successo delle WCAG 2.0 siano
essenziali per qualche gruppo di persone. Per questo è stato cambiato il sistema dei punti di
controllo con quello dei criteri di successo.
Una nota1 particolarmente significativa ad opera dello stesso W3C mette in risalto il fatto che
persino conformarsi a tutti e 3 i livelli non renderà il contenuto Web accessibile a tutte le
persone.
Viene in oltre rimarcato che tutti i criteri di successo sono verificabili.
Non è cambiato però il fondamentale criterio con cui testare i risultati. Mentre alcuni di questi
possono essere verificati con programmi automatici, altri devono essere testati da esperti
tecnici. In qualche caso queste due modalità possono essere usate in congiunzione. I risultati
di queste valutazioni devono essere univoci.
A seguito della valutazione sul soddisfacimento dei singoli criteri di controllo possono essere
raggiunti tre livelli di conformità:
Conformità di livello A; se tutti i criteri di successo di livello 1 nelle linee guida sono
soddisfatti, assumendo il supporto dei programmi utente solamente per le tecnologie
specificate nella baseline;
Conformità di livello doppia-A (AA); se tutti i criteri di successo di livello 1 e di livello
2 nelle linee guida sono soddisfatti, assumendo il supporto dei programmi utente
solamente per le tecnologie specificate nella baseline;
Conformità di livello tripla-A (AAA); se tutti i criteri di successo di livello 1 e di livello
2 nelle linee guida sono soddisfatti, ed anche almeno il 50% di quelli di livello 3,
assumendo il supporto dei programmi utente solamente per le tecnologie specificate
nella baseline.
1
“Note that even conformance to all three levels will not make Web content accessible to all people” –
[http://www.w3.org/TR/WCAG20/]
- 304 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In questa valutazione, se un criterio di successo si riferisce ad una caratteristica od a un
componente che non viene impiegato nei contenuti, ad esempio una presentazione
multimediale, quel criterio di successo si ritiene automaticamente soddisfatto.
Per dichiarare un livello di conformità devono essere presenti le seguenti asserzioni:
La data della dichiarazione;
Il richiamo alle WCAG;
L’indirizzo URI di riferimento (http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD);
Il livello di conformità raggiunto;
La baseline usata per dichiarare la compatibilità;
Un’espressione regolare che definisca la definizione del campo di applicabilità della
dichiarazione.
Una dichiarazione può essere ristretta ad una sola parte del sito a patto che non escluda
una tipologia particolare di contenuti, come ad esempio gli script o le immagini.
Un importante aggiunta in questa dichiarazione di conformità è la richiesta di specificare la
data in cui viene asserita la dichiarazione. Si tratta di un concetto importante dal
momento che in questo modo è possibile valutare quando è stata fatta l’ultima valutazione dei
contenuti.
Una pagina valutata più recentemente rappresenta sicuramente per gli utenti una delle migliori
testimonianze della cura posta nel rendere il sito accessibile.
Glossario
A causa dell’ampia gamma di tecnologie supportate dalle WCAG 2.0, è stato necessario per il
W3C introdurre dei termini maggiormente omnicomprensivi che fossero più precisi a riguardo
delle tecniche e degli oggetti considerati. L’eccessivo grado di astrazione di queste definizioni
finisce però per prestare il fianco ad alcune critiche sulla scarsa comprensione dei contenuti.
A questo proposito lo stesso documento normativo delle WCAG 2.0 propone un glossario dei
termini in appendice1 A, molte di queste definizioni però sono a loro volta complesse.
Riporto quelle essenziali, tradotte per quanto possibile in italiano:
Programmaticamente determinato (programmatically determined):
Determinato via software dai dati forniti in maniera supportata dai programmi utente in
modo tale che i programmi utente possano estrarre e presentare questa informazione
agli utenti in differenti modalità;
1
[http://www.w3.org/TR/WCAG20/complete.html#glossary]
- 305 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Elemento unitario di progetto (Authored unit):
Insieme di materiali creati da un progettista come singola entità. Ad esempio, una
raccolta di markup, un foglio di stile, una risorsa mediale, come un'immagine o una clip
audio;
Esperienza sensoriale specifica (Specific sensory experience):
Un’esperienza sensoriale che non è puramente decorativa e che non veicola
primariamente informazioni importanti e non esegue una funzionalità;
Baseline:
un insieme di tecnologie assunte come supportate ed attive nei programmi utente;
Analizzati senza ambiguità (parsed unambiguously):
Riassunti in un’unica struttura dati. L’analisi trasforma il linguaggio a marcatura o altri
sorgenti in una struttura dati, generalmente ad albero, disponibile per successive
elaborazioni, che ritenga l’implicita gerarchia dei dati in ingresso.
Normativa
I 4 principi base sono presentati sull’acronimo P.O.U.R.:
Percepible: Il contenuto deve essere percepibile;
Operable: I componenti dell'interfaccia nel contenuto devono essere fruibili;
Understandable: Il contenuto ed i controlli devono essere comprensibili;
Robust: Il contenuto deve essere sufficientemente robusto da funzionare con i
programmi utente attuali e futuri, incluse le tecnologie assistive.
Per la traduzione che segue delle linee guida si è scelto di riportare quella proposta da Roberto
Scano1, altri commenti sono stati considerati dalla citata relazione2 di Roberto Ellero.
I due importati autori citati sono anche i due membri italiani del gruppo di lavoro delle stesse
WCAG.
Principio 1: Percepibile
I contenuti devono essere percepibili.
Il primo principio 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
1
2
[http://www.meetinability.net/relazioni/abstract_scano.pdf]
[http://www.webaccessibile.org/argomenti/argomento.asp?cat=368]
- 306 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
possono essere descritte in modo testuale come ad esempio, le immagini da una webcam in
tempo reale.
In particolare la linea guida 1.1 richiede di fornire, per i contenuti non testuali, 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 sensoriale specifica (ad esempio, musica ed arte visiva) e in questo caso è
sufficiente una etichetta o una descrizione.
Il contenuto non testuale comprende, ma non è limitato da immagini, testo in immagini,
mappe, animazioni, arte ASCII, punti degli elenchi puntati, spaziatori, bottoni, suoni, file audio,
tracce audio di video e video. Script ed applet non sono considerati in questo elenco.
In questo principio rientra anche, tramite la linea guida 1.3, la fondamentale separazione tra
elementi strutturali ed elementi presentazionali e il trattamento del colore come veicolo
informativo, mentre i criteri per un corretto contrasto ricadono nella linea guida 1.4.
Come segnalato nel capitolo del colore, le WCAG 2.0 introducono un nuovo criterio per la
valutazione del rapporto di contrasto della luminosità. Vengono introdotti anche altri criteri di
chiarezza sulla percettività anche della informazione audio, con un criteri analoghi alla parte
video.
Linee guida:
1.1: Fornire alternative testuali per tutti i contenuti non testuali;
1.2: Fornire alternative sincronizzate per i contenuti multimediali;
1.3: Garantire che le informazioni e la struttura possano essere separate dalla
presentazione;
1.4: Rendere facilmente distinguibili le informazioni principali rispetto allo sfondo.
Principio 2: Fruibile
I componenti dell’interfaccia devono essere operabili.
Il secondo principio si riferisce alla fruibilità (o operabilità) dei contenuti, vale a dire alla
possibilità di poter interagire con i contenuti e con le eventuali interfacce personalizzate.
Roberto Ellero fa notare come nel termine operable si consideri anche il concetto di efficienza,
citando come esempio di scarsa efficienza la necessità di premere decine di volte il tasto di
tabulazione per scorrere i contenuti di una pagina.
Tra le linee guida si afferma la necessità di garantire che tutti gli elementi delle interfacce
presenti nel contenuto possano essere utilizzati da qualsiasi utente, quantomeno con l'utilizzo
di tastiera, e che l'utente abbia la possibilità di intervenire nell'esecuzione di tali funzionalità.
L'impossibilità di poter operare tramite tastiera rende inaccessibili i servizi agli utenti che
utilizzano tecnologie assistive basate sui comandi tastiera come ad esempio la categoria degli
screen-reader.
- 307 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
L’inclusione dei meccanismi di navigazione è considerata nella linea guida 2.4 per la quale sono
validi strumenti le strutture gerarchiche del linguaggio, le mappe del sito, le marcature corrette
nelle tabelle, la possibilità di saltare blocchi di contenuto, il titolo delle singole pagine.
Di primaria importanza sono i controlli sulle intermittenze dello schermo che, per i motivi di
salute analizzati in precedenza, sono oggetto di una linea guida specifica.
Linee guida:
2.1. Rendere tutte le funzionalità operabili tramite comandi da tastiera;
2.2. Consentire agli utenti di controllare i limiti di tempo per la lettura e l’interazione;
2.3. Consentire agli utenti di evitare i contenuti che possono causare attacchi di
epilessia fotosensibile;
2.4. Fornire funzionalità che aiutino l’utente a trovare i contenuti, ad orientarsi
all’interno dei contenuti e a navigarli;
2.5. Aiutare gli utenti nell’evitare errori consentendone facilmente la correzione.
Principio 3: Comprensibile
I controlli e i contenuti devono essere comprensibili.
Il terzo principio si riferisce alla comprensibilità dei contenuti, vale a dire alla capacità di
rendere chiari e semplici i contenuti. Questo principio riprende in qualche modo, soprattutto in
sede costitutiva, la linea guida numero 14 delle WCAG 1.0, la quale prevede che i documenti
siano chiari e semplici e quindi di facile comprensione per contrastare l’esclusione dal Web
delle persone con problemi di lettura o disabilità cognitive. Tuttavia le modifiche
d’impostazione rispetto alle linee guida precedenti sono considerevoli.
Innanzi tutto sono state rimosse tutte le definizioni che in qualche maniera potevano
richiamare all’usabilità del materiale Web.
In oltre, nel testo attuale si fa riferimento, con il criterio di successo 3.1.5, ad un ben
determinato livello di istruzione minimo a cui i contenuti devono adeguarsi, quanto meno
tramite dei contenuti supplementari.
Vengono considerate anche altre aspetti della comprensibilità come ad esempio la definizione
del linguaggio naturale del contenuto, le abbreviazioni ed altre forme di contrazioni verbali.
Linee guida:
3.1. Rendere leggibile e comprensibile il contenuto testuale;
3.2. Rendere determinabile la posizione e la funzionalità del contenuto.
Principio 4: Durevole
I contenuti devono essere robusti per l’uso attuale e futuro.
Il quarto principio considera la naturale evoluzione delle tecnologie, vale a dire alla possibilità
di poter interagire con i contenuti e con le eventuali interfacce personalizzate attuali e future.
- 308 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Questo significa sviluppare cercando di utilizzare le ultime tecnologie attualmente disponibili
ma allo stesso tempo cercando di mantenere la compatibilità con le precedenti.
Le tecnologie assistive sono espressamente citate nella linea guida 4.1, per quanto esse
facciano già parte della definizione dei programmi utente. Il significato di tale enfasi è dovuto
alla finalità stessa del progetto WCAG.
É necessario assicurarsi di progettare in maniera conforme alle specifiche del W3C, in modo
che le tecnologie future che siano compatibili con questi protocolli non possano costituire
impedimento alla fruibilità delle pagine prodotte oggi. Un codice corretto non crea problemi ai
programmi utenti che rispettino le linee guida definite nelle UAAG, ad esempio garantendo che
le pagine e i componenti creati possano essere analizzati e decodificati in maniera non
ambigua e che tutte le relazioni fra i dati siano anche loro ben definite.
La validazione formale di un linguaggio a marcatori come XHTML derivato da XML è un utile
strumento guida in questa corretta progettazione.
Linee guida:
4.1. Supportare la compatibilità con i programmi utente odierni e futuri (incluse le
tecnologie assistive);
4.2. Garantire che il contenuto sia accessibile oppure fornire delle alternative accessibili.
Mappatura WCAG 1.0 e 2.0
Il gruppo del WAI ha preparato una tabella riassuntiva1 per dare un’idea dell’evoluzione WCAG
2.0 a coloro che abbiano già sufficiente dimestichezza con le WCAG 1.0.
La tabella propone un paragone fra le due linee guida utilizzando la versione del 2 Giugno 2004
del WCAG 2.0 Working Draft.
Ne riporto un sunto essenziale per i principi di livello A. La tabella originale è reperibile sul sito
del W3C.
TABELLA 4 - RELAZIONE TRA LE WCAG 2.0 E WCAG 1.0
WCAG 2.0
WCAG 1.0
Linea guida 1.1:
1.1 [Priorità 1]
Equivalenti testuali
1.2 [Priorità 1]
1.5 [Priorità 3]
6.2 [Priorità 1]
9.1 [Priorità 1]
1
[http://www.w3.org/WAI/GL/2004/06/02-mapping.html]
- 309 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
WCAG 2.0
WCAG 1.0
12.1 [Priorità 1]
Linea guida 1.2:
1.3 [Priorità 1]
Equivalenti per elementi multimediali.
1.4 [Priorità 1]
Linea guida 1.3:
2.1 [Priorità 1]
Separazione fra struttura e contenuto.
3.3 [Priorità 2]
3.5 [Priorità 2]
3.6 [Priorità 2]
5.1 [Priorità 1]
5.2 [Priorità 1]
5.6 [Priorità 3]
6.1 [Priorità 1]
12.4 [Priorità 2]
Linea guida 1.4:
2.2 [Priorità 2 per le immagini,
Contrasto visivo.
Priorità 3 per il testo].
Linea guida 1.5:
Non disponibili
Contrasto audio.
Linea guida 2.1:
6.4 [Priorità 2]
Operatività via tastiera.
9.1 [Priorità 1]
9.3 [Priorità 2]
9.4 [Priorità 3]
9.5 [Priorità 3]
Linea guida 2.2:
7.2 [Priorità 2]
Controlli temporali
7.3 [Priorità 2]
7.4 [Priorità 2]
7.5 [Priorità 2]
Linea guida 2.3:
7.1. [Priorità 1]
Sfarfallamenti
Linea guida 2.4:
3.3 [Priorità 2]
Meccanismi di navigazione
3.5 [Priorità 2]
5.3 [Priorità 2]
9.4 [Priorità 3]
9.5 [Priorità 3]
10.2 [Priorità 2]
12.1 [Priorità 1]
12.2 [Priorità 2]
12.3 [Priorità 2]
13.2 [Priorità 2]
13.3 [Priorità 2]
13.5 [Priorità 3]
13.6 [Priorità 3]
- 310 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
WCAG 2.0
WCAG 1.0
13.9 [Priorità 3]
13.10 [Priorità 3]
Linea guida 2.5:
13.7 [Priorità 3]
Minimizzazione degli errori
Linea guida 3.1:
4.1 [Priorità 1]
Comprensibilità
4.2 [Priorità 3]
4.3 [Priorità 3]
5.5 [Priorità 3]
13.8 [Priorità 3]
14.1 [Priorità 1]
14.2 [Priorità 3]
Linea guida 3.2:
7.5 [Priorità 2]
Organizzazione e navigazione
10.1 [Priorità 2]
13.1 [Priorità 2]
13.4 [Priorità 2]
14.3 [Priorità 3]
Linea guida 4.1:
3.2 [Priorità 2]
Compatibilità e robustezza
3.5 [Priorità 2]
3.6 [Priorità 2]
3.7 [Priorità 2]
5.4 [Priorità 2]
11.2 [Priorità 2]
Linea guida 4.2:
3.1 [Priorità 2]
Supporto alle tecnologie assistive
6.3 [Priorità 1]
6.4 [Priorità 2]
6.5 [Priorità 2]
8.1 [Priorità 1/2]
9.2 [Priorità 2]
11.1 [Priorità 3]
11.4 [Priorità 1]
- 311 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Critiche
Come ricordato da Franco Carcillo1, Le WCAG 2.0 sono state attese da molto tempo da tutta la
comunità degli sviluppatori, ed i ritardi di questa lunga gestazione sembrano essere
apparentemente incomprensibili.
In realtà le ragioni sono molte anche di un certo spessore.
Per incominciare il Web del 2006 non è lo stesso di quello del 1999. Interessi economici e
commerciali delle grandi aziende mondiali si sono orientati anche verso il W3C al punto che il
numero di articoli critici verso questa organizzazione si è notevolmente moltiplicato. Joe Clark
è una delle autorità più attive in questo campo. Un suo articolo estremamente pungente viene
riassunto più avanti in questo lavoro.
Le polemiche si incentrano soprattutto sulla affidabilità e sulla effettiva possibilità di
implementare le WCAG 2.0 nel mondo reale finendo per coinvolgere anche il ruolo e la
reputazione dello stesso consorzio.
Al tempo delle WCAG 1.0 l’attenzione verso i temi dell’accessibilità era appena nascente.
Attualmente invece le grosse società hanno tutto l’interesse a far sentire il proprio peso
all’interno del W3C, come sponsor o come osservatore pagante. Di fatto, come fa notare anche
Maurizio Boscarol in un suo articolo2 del Giugno 2006, per partecipare al Working Group
bisogna come minimo essere appositamente stipendiati, avere forti interessi economici in gioco
(nel caso di aziende o professionisti), oppure avere molto tempo libero. Infatti è necessario
partecipare a tele-conferenze a cadenza settimanale, oltre a seguire interminabili discussioni
quotidiane nella mailing list pubblica.
Vuoi per questi motivi, vuoi per l’intento di essere al di sopra di una speficifica tecnologia,
come invece non erano le WCAG 1.0, le WCAG 2.0 pagano lo scotto di una lunga fase
propositiva che si snoda da lungo tempo in un interminabile sequela di Working Draft e di
proposte di correzione.
Ed anche quando finalmente usciranno, di certo non potranno avere lo stesso impatto
legislativo e la stessa autorevolezza che invece hanno fortunatamente segnato le precedenti,
se non altro per il loro più elevato grado di genericità.
Il pericolo di un possibile conflitto fra estremisti e di una conseguente reazione di disinteresse
contro l’accessibilità è reale.
1
2
[http://www.francocarcillo.it/]
[http://www.ecologiadeisitiweb.net/blog/la-balcanizzazione-dellaccessibilita]
- 312 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Un avvertimento significativo sulla effettiva dispersione di energia e coerenza viene dal citato
dallo stesso articolo di Maurizio Boscarol. L’autore pone l’accento sulle divisioni e sulle
moltiplicazioni di iniziative per nulla coordinate fra di loro.
Segnala poi il fatto che, per quanto possa sembrare strano, la consultazione e l’interazione con
le comunità dei maggiori beneficiari delle normative sono state piuttosto scarse.
Nella legge Stanca e nelle WCAG non viene documentato in nessun modo quale tipologia di
ricerche empiriche siano state realmente portate a termine con utenti disabili.
Maurizio Boscarol parla di queste utili ricerche come finalizzate ad un duplice scopo:
Tentare di capire cosa vogliano gli utenti disabili;
Tentare di capire, osservandoli, come usano veramente il Web gli utenti disabili.
Una ricongiunzione importante con il modo dell’handicap, dal momento che non sempre questi
utenti possono aver bisogno di quello che viene loro effettivamente fornito.
In assenza di queste indicazioni empiriche documentate si finisce per spostare l’attenzione
sulle teorizzazioni e sugli interessi che sono maggiormente rappresentati nei gruppi di lavoro,
questi finiscono per essere quelli dei grandi distributori e dei produttori di tecnologie e di
software coinvolti nella realizzazione dell’accessibilità.
L’incitamento di Maurizio Boscarol è quello di riportare al più presto l’attenzione sulle esigenze
degli utenti con un metodo scientifico basato sulle evidenze e sulle prove empiriche.
Lo stesso autore riconosce questa proposta come contraria alla cultura dominante in quanto
toglie autorità agli esperti per ridarla agli utenti proponendo di verificare prima di normare.
Piuttosto tristemente, Boscarol conclude osservando come, di conseguenza, la comunità
dell’accessibilità si stia disperdendo in un rivolo di frammentazioni progressive in un clima di
diffidenza e tensioni reciproche fra diversi gruppi di lavoro, consulenti ed organizzazioni
finanziate.
Di fatto le WCAG 2.0 non possono considerarsi esenti da pecche:
Uno degli aspetti più critici è probabilmente l’eccessivo tecnicismo usato nella stesura
del testo. Come visto in precedenza è stato definito opportunamente un glossario per le
formule espressive ricorrenti, tuttavia lo stesso glossario è eccessivamente ricco di
termini tecnici e questo compromette sicuramente la comprensibilità del testo e incute
un approccio di eccessiva diffidenza nel lettore;
Difficile usabilità della documentazione. Un elemento negativo già presente nelle WCAG
1.0 e ulteriormente esasperato in questa versione. Si tratta di documenti ipertestuali
piuttosto intricati nei collegamenti e nei rimandi. Questo è stato probabilmente per
arricchire il contenuto, ma finisce a volte per dare la sgradevole impressione di essere
rimandati da un ufficio all’altro per accedere alle informazioni;
I documenti sono in oltre piuttosto voluminosi. La maggior parte degli sviluppatori
vedono l’accessibilità come una parte del loro lavoro e non hanno spesso il tempo o la
- 313 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
voglia di muoversi attraverso centinaia di pagine di testo per scoprire come
implementare pagine accessibili;
Mancanza di alcune linee guida valide delle WCAG 1.0, alcune delle quali sono
scomparse del tutto mentre altre sono state notevolmente ridimensionate, come ad
esempio1:
o
Punto 3.1: usare un marcatore piuttosto che le immagini;
o
Punto 3.2: Creare documenti che rispettino le grammatiche formali;
o
Punto 3.3: Usare i fogli di stile per controllare l'impaginazione e la
presentazione;
o
Punto 3.4: Usare unità di misura relative anziché assolute;
o
Punto 12.3: Dividere i grandi blocchi di informazione in gruppi più maneggevoli;
o
Punto 13.8: Posizionare l'informazione più significativa all'inizio;
o
Linee guida sull’usabilità del sito e sulla chiarezza del contenuto;
La neutralità rispetto alla tecnologia costituisce un punto di forza ma anche un punto di
estrema debolezza, in pratica questa scelta ha reso le linee guida WCAG 2.0
estremamente vaghe in se stesse, al punto di essere quasi inutilizzabili se non
supportate validamente da un consistente documento di tecniche.
Un lungo articolo2 molto critico è stato pubblicato su A List Apart, a cura di Joe Clark.
Consiglio vivamente una lettura, per la criticità del testo e per l’autorevolezza dell’autore, nel
caso consultandolo anche nella parziale traduzione3 italiana.
Ne riporto nel seguito i concetti fondamentali, molti mi sembrano effettivamente eccessivi, ma
altri possono avere una loro valida motivazione.
L’opinione di Joe Clark
Le WCAG 1.0 risalgono oramai al 1999. Se hanno avuto il grosso pregio di aprire la strada alle
leggi nazionali che le hanno seguite, tuttavia contengono parecchie inesattezze e sono
diventate presto obsolete in alcuni punti, a causa dei veloci mutamenti della tecnologia in
questo settore.
Le WCAG 2.0 dovrebbero essere la loro naturale evoluzione.
Sono il risultato di almeno 5 anni di lavoro della commissione WAI e non sono ancora arrivate
ad un risultato definitivo.
1
2
3
[http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/wcag-guidelines-20.shtml]
[http://alistapart.com/articles/tohellwithwcag2]
[http://www.giorgiocardellini.com/webdesign/utente/060523.htm]
- 314 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Nello sforzo di coprire tutto su tutti i contenuti Web, sono quasi impossibili da comprendere e
sono un passo indietro rispetto alle basi di un buon sviluppo come ora universalmente
accettato. In breve non possono considerarsi un vero progresso e non valevano l’attesa1.
Le WCAG 1.0 sono, attualmente, il solo standard internazionale ma ormai sono arrivate a 7
anni di vita ed hanno bisogno di essere profondamente revisionate. Il 27 Aprile 2006 con il
Last Call Working Draft è stato compiuto il primo passo della lunga sequenza per arrivare alla
standardizzazione delle 2.0.
Tuttavia, la speranza di un miglioramento complessivo rimane delusa. Sono state incluse molte
finalità inutili e linee guida di basso interesse. Dove le WCAG 2.0 falliscono è nei compiti più
importanti, nonostante che esse sembrino ragionevoli grazie ad una esposizione curata.
In realtà non lo sono e uno sviluppatore che aderisca agli standard le troverà quasi impossibili
da mettere in pratica.
Come da tradizione del W3C, poi, la documentazione è dispersiva e difficile da reperire.
I tre documenti guida sono:
Web Content Accessibility Guideline2 (WCAG) 2.0, documento principale normativo in
Last Call Working Draft;
Understanding3 WCAG 2.0, un documento di spiegazione;
Techniques4 for WCAG 2.0, fornisce le tecniche generali, ora include anche le tecniche
per (X)HTML.
I punti critici sono parecchi:
I tre documenti delle WCAG 2.0 superano le 450 pagine con un cambiamento di
nomenclatura;
Il tempo concesso alle parti interessate, incluse le associazioni di disabili, per riportare
commenti alla mole di documentazione prodotta in cinque anni è stato davvero molto
breve;
Il gruppo di lavoro del WCAG è uno dei peggiori con cui lavorare, molti tentativi di
contatto vengono respinti, soprattutto se non vengono dalle multinazionali che possono
spendere ore al telefono e continui viaggi in aereo tra le capitali mondiali. Gli stessi
1
“WCAG 2 backtracks on basics of responsible web development that are well accepted by standardistas.
WCAG 2 is not enough of an improvement and was not worth the wait.”
2
[http://www.w3.org/TR/WCAG20/complete.html]
3
[http://www.w3.org/TR/UNDERSTANDING-WCAG20/]
4
[http://www.w3.org/TR/WCAG20-TECHS/]
- 315 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
partecipanti lavorano in un clima intimidatorio come non succede in nessun altro gruppo
di lavoro del WAI1;
Il processo di sviluppo è inaccessibile per chi non parli inglese e soprattutto è
inaccessibile per alcune persone con disabilità, in special modo per chi ha difficoltà di
lettura (i testi sono scritti male) e di udito. In pratica, nessuno con disabilità cognitive o
uditive ha contribuito al processo, perché è, di fatto, impossibile.
Basta spendere poche ore nella lettura delle bozze per rimanere delusi. Il documento sembra
ragionevole sintetico e funzionale ma il nocciolo del problema è stato seppellito nel testo.
Nel testo ci sono parecchi punti controversi:
E’ poco chiaro che cosa si intenda per pagina o sito;
Per essere accessibile un documento HTML non deve essere per forza un documento
valido;
Si può impiegare anche più di un livello di tabelle di impaginazione annidate;
Sono consentiti lampeggiamenti dell’intera pagina (blinking) fino a 3 secondi, ma
nessuna sua parte può avere dei flash.
Avendo definito una tecnologia come una baseline, chiunque non ne disponga ha ben
pochi strumenti per protestare se il sito è inaccessibile in mancanza delle tecnologie
dichiarate2;
E’ possibile definire delle intere cartelle del sito come inaccessibili, come ad esempio
quelle contenenti presentazioni multimediali;
Il documento di compatibilità è una dichiarazione di punti di controllo che ricorda più
una confessione obbligata che una dichiarazione delle politiche di accessibilità messe in
atto;
Nei video non occorre fornire una descrizione audio per i non vedenti e le descrizioni
testuali sono richieste solo per i video pre-registrati;
Puoi creare una pagina sola con migliaia di collegamenti ipertestuali, ma se si mettono
una dopo l’altra due pagine con almeno tre collegamenti di navigazione, allora si deve
fare in modo che possano esser saltati;
Non si possono mettere delle etichette fuori schermo che possano vedere solo gli
utilizzatori di tecnologie assistive;
1
“Something’s wrong if many participants work in a climate of fear, as they tell me they do. I never hear of
similar complaints from WAI’s other groups. WCAG Working Group is a rogue element within the W3C.”
2
[http://www.w3.org/TR/WCAG20/complete.html#conformance-reqs]
- 316 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Nelle impaginazioni con i CSS sono proibiti i posizionamenti assoluti giacché l’ordine del
codice e l’ordine della presentazione devono coincidere;
E’ possibile fornire un documento alternativo per persone che non sono culturalmente in
grado di comprendere il documento principale. In pratica le WCAG 2.0 propongono di
mantenere pagine accessibili ed inaccessibili, in questo modo non ci sarà bisogno di
migliorare l’accessibilità di una pagina, basterà produrne una separata.
Le WCAG 2.0 sono allo stato di bozza, ma in pratica non cambieranno. Il gruppo di lavoro
ritiene di aver soddisfatto le richieste tecniche.
Dove invece il gruppo non ha certamente lesinato è nelle definizioni.
Le WCAG 1.0 erano strettamente legate all’HTML, e tutti hanno riconosciuto che questo fosse
un problema in un periodo in cui PDF e Flash stanno pian piano diventando accessibili.
Per questo le WCAG 2.0 sono indipendenti dalla tecnologia. Per venire incontro a questi
ambienti, sono state scritte e riscritte più volte al punto di perdere la capacità di adattarsi al
mondo reale con cui lavorano concretamente gli sviluppatori in HTML, CSS e JavaScript.
In particolare, molte definizioni come: authored unit, authored component, web unit, parsed
unambiguosly, programmatically determined, possono essere difficilmente tradotte in termini
pratici da tutti i lettori.
In effetti, parecchie parti delle WCAG 2.0 sono poco comprensibili e difficili da applicare, a
dispetto degli stessi principi di comprensibilità che espongono. Essendo così difficili da
comprendere, difficilmente potranno essere messe in pratica. Tra l’altro potrebbero anche
essere soggette ad interpretazioni arbitrarie, rendendo discutibile il fatto di aver realizzato un
sito pienamente accessibile.
Per quanto poi riguarda i criteri di successo, anche questi sono un’illusione.
Nonostante che si fosse notato che con le WCAG 1.0 le conformità di tipo A e doppia-A fossero
quelle concretamente attendibili mentre la tripla-A fosse irrilevante e inattendibile, le WCAG
2.0 hanno alla fine deciso di ripetere lo stesso schema. Per di più:
Anche se ci si conforma a tutti i tre livelli delle WCAG 2.0, è possibile comunque
produrre un sito inaccessibile;
E’ possibile adeguarsi solamente alla metà delle richieste di livello 3 per ottenere la
conformità1;
Lo stesso documento del W3C afferma che non si raccomanda che un livello di
conformità tripla-A sia sempre richiesto per l’intero sito1;
1
[http://www.w3.org/TR/WCAG20/complete.html#conformance-reqs]
- 317 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In una contraddizione ciclica la linea guida 4.2.4 a livello 3 non richiede2 che venga
soddisfatto il livello 3 per tecnologie al di fuori della baseline;
Molte linee guida non hanno criteri di successo al primo livello basilare, e comunque
non sono applicabili a tutti i livelli.
E’ cosa risaputa che un sito che validi la sintassi HTML non sia automaticamente un sito
accessibile, nella realtà concreta gli sviluppatori che sappiano orientarsi autonomamente nella
scrittura manuale del linguaggio, sono spesso in grado di comprendere con relativa facilità i
concetti dell’accessibilità e di attuarne i principi. Eppure la validazione formale della
grammatica del documento è solo di livello 2 nelle WCAG 1.0 (punto di controllo 3.2), e nelle
WCAG 2.0 questa validazione formale è stata del tutto abolita, non c’è bisogno di avere un
codice HTML valido per i siti compatibili con le WCAG 2.0, tutto quello che è richiesto 3 è che la
pagina possa essere esaminata senza ambiguità4, in pratica che gli elementi non vengano
annidati scorrettamente. Non è necessario utilizzare gli elementi come richiesto dalle specifiche
e non si richiede l’uso delle tecnologie in accordo con la semantica definita nelle specifiche 5. Un
documento fatto di nient’altro che DIV e SPAN, se esaminabile senza ambiguità, supera il
controllo delle WCAG 2.0.
Se c’è stata un’area in cui l’applicazione delle WCAG 1.0 è fallita completamente è stata quella
dei contenuti multimediali. Praticamente tutti hanno ignorato la necessità di descrizioni audio e
descrizioni testuali che sono entrambe richieste già al più basso livello dell’accessibilità.
Anche in questo campo, per i non vedenti ed i non udenti che vogliano accedere al
multimediale, le WCAG 2.0 non presentano alcun vantaggio reale. Le descrizioni testuali
rimangono obbligatorie solo per i video pre-registrati, mentre in luogo delle descrizioni audio è
prevista una equivoca alternativa testuale di multi-medialità completa che includa tutte le
interazioni.
In sostanza le WCAG 2.0 saranno inutilizzabili nella realtà dagli sviluppatori, soprattutto da
quelli che intendono produrre del codice aderente agli standard. Sono troppo vaghe e
1
“It is not recommended that Triple-A conformance ever be required for entire sites.” –
[http://www.w3.org/TR/WCAG20/complete.html#N10471]
2
[http://www.w3.org/TR/WCAG20/complete.html#accessible-alternatives-level2]
3
[http://www.w3.org/TR/WCAG20/complete.html#N1085F]
4
“You never have to have valid HTML in WCAG 2–compliant sites. All that’s required is that the page be
parsed unambiguously”
5
[http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0187.html]
- 318 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
contestabili per affermarsi come basi per la regolamentazione e lasciano troppe scappatoie per
gli sviluppatori che le vadano cercando 1.
Le WCAG 2.0 non rimpiazzano le WCAG 1.0 né più né meno di quanto l’XHTML non rimpiazzi
HTML. Forse ci sarebbe stato solo bisogno di correggere le WCAG 1.0 in una versione 1.1.
Relazione con il DM 8 Luglio 2005
Una corrispondenza significativa per le WCAG 2.0 la si può cercare anche con il nostro Decreto
Ministeriale del Luglio 2005 che accompagna la legge Stanca.
La legge italiana è molto più calata nella realtà, ed è stata pensata in modo che i requisiti
possano essere applicabili e valutabili. Questo soprattutto ragioni di esame in sede legale:
sarebbe stato impraticabile dare delle norme che poi non potessero essere verificate con
relativa semplicità e in modo univoco.
Sul sito del Dipartimento di Matematica ed Informatica dell’Università di Udine, Giorgio Brajnik
presenta una seconda tabella2 di corrispondenze, questa volta fra la legge Stanca e le nascenti
WCAG 2.0.
La tabella citata però non è basata sull’ultima versione rilasciata del Working Draft e contiene,
allo stato attuale dei lavori, alcune lacune ed imprecisioni. Ad ogni modo può essere di utile
informazione e ne segnalo la presenza sempre sul sito del Dipartimento di Matematica ed
Informatica dell’Università di Udine.
Riprendendo le stesse annotazioni di Giorgio Brajnik si può riassumere che la legge Stanca
risulta in generale più vincolante delle WCAG 2.0 per:
Il posizionamento e la separazione dei collegamenti ipertestuali (requisito 21);
Il divieto di uso dei frame (requisito 2);
Il dover produrre pagine sintatticamente corrette in (X)HTML;
Il considerare gli script come non essenziali;
Il considerare le pagine alternative solo testo come non accessibili.
D'altra parte la legge Stanca:
Non copre con lo stesso dettaglio i vari tipi di materiale non testuale e di materiale
multimediale;
1
“As such, WCAG 2 will be unusable by real-world developers, especially standards-compliant developers. It
is too vague and counterfactual to be a reliable basis for government regulation. It leaves too many
loopholes for developers on the hunt for them. WCAG 2 is a failure, and not even a noble one at that”
2
[http://www.dimi.uniud.it/wq/stanca-mappa.html]
- 319 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Si basa su formule e soglie per determinare i livelli di contrasto che sono datate e
discutibili come è già stato commentato nella sezione inerente al colore;
E’ meno specifica nelle casistiche relative alle funzionalità temporizzate, al lampeggio,
alla navigazione;
Non tratta la gestione degli errori, i cambi di lingua, le abbreviazioni, il testo
semplificato, il cambiamento del focus, la coerenza nel sito.
IV.6 - Quadro sinottico
In questa sezione si vuole dare una connotazione conclusiva alle normative esaminate
mettendole in relazione fra loro.
Lo scopo di uno studio del genere è quello di aiutare il lettore nella comprensione dei principi,
non certo quello di voler valutare la bontà o la superiorità di una legislazione rispetto ad
un'altra.
Questo per il fatto che hanno finalità piuttosto diverse, a partire dalle WCAG 2.0 che sono forse
le meno comparabili con le altre dal momento che forniscono volutamente dei principi piuttosto
astratti, essendo state progettate per un campo di applicazione più generale.
In oltre tutte le relazioni fra le normative sono piuttosto complesse.
Si è già accennato ad una possibile conflittualità delle Section 508 con le WCAG 1.0.
Va aggiunto che la legge Stanca non copre nemmeno il livello A delle WCAG 1.0 pur
contenendo altri principi più restrittivi. E viceversa, come ricordato anche alla conferenza IWA
di Arese: chi ottiene la conformità il livello A delle WCAG 1.0 non raggiunge necessariamente la
conformità con la legge Stanca, che contiene nelle sue disposizioni qualcosa anche del livello
doppia-A e tripla-A delle WCAG 1.0.
Vorrei qui presentare una fusione di tabelle comparative elaborata personalmente che in
qualche maniera possa fungere da quadro sinottico delle normative.
La tabella è una sintesi di varie fonti ufficiali e mette in relazione di argomento le normative
citate.
Trae la sua materia dai vari confronti proposti nei siti ufficiali:
1
2
3
Dalle indicazioni1 del Decreto Ministeriale 8 Luglio 2005;
Dalla griglia di valutazione2 del W3C;
Dalla nota di raffronto3 della Section 508;
Dalla pagina1 di presentazione del W3C delle WCAG 2.0.
[http://www.pubbliaccesso.gov.it/biblioteca/documentazione/corrispondenza_requisiti_wcag.htm]
[http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/full-checklist]
[http://www.section508.gov/]
- 320 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Sono state riportate in ordine di priorità basandosi sulle WCAG 1.0 che, storicamente, hanno
fatto da riferimento per le altre normative.
Le tabelle, ovviamente, possono contenere delle forzature, dal momento che le linee guida
delle normative non si possono far sovrapporre direttamente l'una sull'altra. Per eventuali
errori e spiegazioni suggerisco di consultare direttamente le pagine originali indicate.
Per le WCAG 1.0 è stato riportato il numero di punto di controllo, per la Section 508 la lettera
del paragrafo in maiuscolo per maggiore chiarezza, per il Decreto Ministeriale 8 Luglio 2005 il
numero di requisito e per le WCAG 2.0 i relativi criteri di successo.
TABELLA 5 - TABELLA COMPARATIVA DELLE NORMATIVE SUI PRINCIPI DI LIVELLO A
ARGOMENTO
WCAG
SECTION
DM
1.0
508
2005
WCAG 2.0
Equivalenti testuali
1.1
A
3
1.1.1, 2.4.6, 4.1.2
Mappe lato server
1.2
E
8
1.1.1, 2.1.1,
2.4.4, 4.2.1
Multimedia audio
1.3
B
18
1.2.2
Multimedia sincronizzati
1.4
B
18
1.2.1, 1.2.2,
1.2.3, 1.2.4, 1.2.6
Informazioni con colori
2.1
C
4
1.3.2
Cambiamenti di lingua
4.1
Tabelle dati
5.1
G
9
1.3.1
Tabelle dati complesse
5.2
H
10
1.3.1
Assenza dei CSS
6.1
D
11
Cambiamenti contenuti dinamici
6.2
A
3
Applet e script non attivi
6.3
L, M
15
4.2.1, 4.2.3
Sfarfallio dello schermo
7.1
J
5
2.3.1, 2.3.2
Mappe lato client
9.1
F
7
1.1.1, 2.1.1,
3.1.2
2.4.4, 4.2.1
Pagine alternative
1
11.4
K
22
4.2.1, 4.2.2
[http://www.w3.org/TR/WCAG20/appendixD.html]
- 321 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
ARGOMENTO
WCAG
SECTION
DM
1.0
508
2005
Titolo ai frame
12.1
Comprensibilità dei contenuti
14.1
I
2
WCAG 2.0
2.4.1, 2.4.4, 4.1.2
TABELLA 6 - TABELLA COMPARATIVA DELLE NORMATIVE SUI PRINCIPI DI LIVELLO DOPPIA-A
ARGOMENTO
WCAG
SECTION
DM
1.0
508
2005
WCAG 2.0
Contrasto colori immagini
2.2
6
Linguaggi invece di immagini
3.1
1
Grammatiche formali
3.2
1
4.1.1
Impaginazione con CSS
3.3
11
1.3.3
Unità di misura relative
3.4
12
Elementi strutturali h1..h6
3.5
1
1.3.1
Marcatori di lista
3.6
1
1.3.1
Marcatori di citazione
3.7
1
1.3.1, 1.3.4
Tabelle linearizzate
5.3
13
1.3.3
Tabelle di impaginazione
5.4
13
1.3.1
Input per applet e script
6.4
16
2.1.1, 2.1.2
Contenuti dinamici
6.5
3
4.2.1, 4.2.3
Lampeggiamento del contenuto
7.2
J
5
2.2.2
Movimento nelle pagine
7.3
J
5
2.2.3
Auto aggiornamento pagine
7.4
P
20
2.2.1, 3.2.5
Auto indirizzamento pagine
7.5
P
20
3.2.5
Elementi programmati accessibili
8.1
L, M
17
4.1.2, 4.2.1, 4.2.2
Interfacce indipendenti dal
9.2
L, M
16
2.1.1, 2.1.2
Gestori di evento per gli script
9.3
L, M
16
2.1.1, 2.1.2
Aperture pop-up e nuove finestre
10.1
1
3.2.1, 3.2.2, 3.2.5
Etichette nei moduli
10.2
14
1.3.1, 1.3.4
L
1.4.1, 1.4.3
dispositivo
- 322 -
N
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
ARGOMENTO
WCAG
SECTION
DM
1.0
508
2005
WCAG 2.0
Tecnologie e versioni
11.1
1
-
Elementi disapprovati
11.2
1
-
Descrizioni dei Frame
12.2
2
-
Organizzazione informazioni
12.3
Associazioni delle etichette
12.4
N
14
1.3.1, 4.1.2
Destinazione dei collegamenti
13.1
O
19
2.4.4, 2.4.8
Informazioni semantiche
13.2
Indici e mappe del sito
13.3
2.4.2
Meccanismi di navigazione
13.4
3.2.3, 3.2.4
I
2.4.1
TABELLA 7 - TABELLA COMPARATIVA DELLE NORMATIVE SUI PRINCIPI DI LIVELLO TRIPLA-A
ARGOMENTO
WCAG
SECTION
DM
1.0
508
2005
WCAG 2.0
Mappe lato client
1.5
-
Contrasto colori testo
2.2
Abbreviazioni ed acronimi
4.2
3.1.4
Lingua del documento
4.3
3.1.1
Sommario per le tabelle
5.5
G
9
Abbreviazioni nelle tabelle
5.6
G
9
Tabindex
9.4
2.4.6
Accesskey
9.5
2.4.1
Linearizzazione delle tabelle
10.3
1.3.3, 2.4.6
Caratteri segnaposto nei
10.4
-
10.5
-
6
1.4.1, 1.4.3
controlli
Distinguere collegamenti
adiacenti
Informazioni per preferenze
11.3
utente
Barre di navigazione
13.5
3.2.3
- 323 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
ARGOMENTO
WCAG
SECTION
DM
1.0
508
2005
O
19
WCAG 2.0
Organizzazione link in gruppi
13.6
2.4.1
Funzionalità di ricerca
13.7
Organizzazione informazioni
13.8
2.4.5
Relazioni fra pagine
13.9
2.4.7
Arte ASCII
13.10
Fruizione multimodale
14.2
Usare uno stile coerente
14.3
3.1.5
A queste tabelle va aggiunta qualche considerazione per quelle normative che non sono
considerate specificatamente nelle WCAG 1.0.
In particolare il trattamento delle pagine alternative o solo testo che sono previste come
soluzione temporanea dalla legge Stanca al requisito transitorio 22 e come valida alternativa di
testo equivalente nella Section 508 al paragrafo (K).
In sostanza restano valide le considerazioni iniziali fatte a proposito della distinzione che esiste
fra i vari dispositivi. Per cui, adempiere ai requisiti di una non garantisce l’automatica
conformità con un'altra.
I principi guida di una buona programmazione e di un buon sviluppo restano comunque ben
fermi, qualsiasi linea guida si voglia o si debba adottare, e sono quelli esposti nella sezione
delle Metodologie Generali di questo lavoro.
- 324 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
IV.7 - ISO
Alla fine del Gennaio 2006 si è svolto a Venezia l’incontro del gruppo di lavoro ISO ISO/TC
159/SC “Software ergonomics and human-computer dialogues”1.
L’ISO (International Organization for Standardization) ha al suo interno dei gruppi di lavoro
che da molto tempo si occupano dell’ingegneria del software. Sulla scorta dell’importanza e
dell’interesse per i temi dell’accessibilità alcune di queste sezioni si stanno occupando delle
norme dedicate all’ergonomia del software per le interfacce delle applicazioni.
Questo tipo di studio riguarda sia le applicazioni software che i sistemi operativi che le
interfacce delle applicazioni Web (Web-based), con l’obiettivo di fornire dei principi generali per
i grandi produttori sull’accessibilità di tali interfacce.
Va ricordato, come impostazione generale delle norme ISO, che queste direttive
contengono e conterranno solamente una serie di principi di progettazione, senza
entrare assolutamente nella materia tecnica.
Da questo punto di vista quindi non si pone assolutamente un problema di eventuale
conflittualità con le normative esposte in precedenza, tanto più per il fatto che nel gruppo di
lavoro sono presenti diversi esperti già presenti nel gruppo di lavoro delle WCAG e negli
standard americani.
Un effetto sicuramente positivo potrà invece essere ottenuto dal fatto che, una volta stabilito
uno standard ISO, sarà possibile certificarlo, permettendo di intervenire non solamente sui siti
delle pubbliche amministrazioni come è già ad oggi normato in Italia con la legge Stanca, ma
anche su tutti gli enti privati.
Da questo punto di vista la certificazione ISO per l’accessibilità del software e delle interfacce
per le applicazioni Web potrà sicuramente essere di stimolo per forzare un innalzamento
generale della qualità dei siti.
Normative
Attualmente esiste già una normativa ISO sulle interfacce software mentre altre due sono in
sviluppo e dovrebbero essere approvate entro il 2007:
ISO/TS 16071: Ergonomics of human-system interaction -- Guidance on accessibility
for human-computer interfaces. Pubblicata il 16 Maggio del 2003;
ISO 9241-151. Ergonomics of human system interaction — Part 151: Software
ergonomics for World Wide Web user interfaces. In fase di sviluppo;
1
[http://www.iwa-italy.org/documento.asp?DocID=363]
- 325 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
ISO 9241-171. Ergonomics of human-system interaction — Part 171: Guidance on
software accessibility. In fase di sviluppo.
ISO/TS 16071
Ergonomics of human-system interaction - Guidance on accessibility for humancomputer interfaces.
Le ISO/TS 16071 forniscono delle linee guida per la progettazione di software accessibile.
Riguardano aspetti associati con la progettazione di interfacce software accessibili per le
persone con la più ampia differenza di capacità visive, uditive e motorie, includendo le persone
anziane e coloro che sono temporaneamente disabili. Le ISO/TS 16071 riguardano aspetti del
software inerenti l’accessibilità che sono di complemento con i principi di progettazione usabile
considerate dalle ISO 9241-10 fino alle ISO 9241-17.
Le ISO/TS 16071 riguardano l’accessibilità dei sistemi interattivi, considerando una vasta
gamma di possibilità, incluse le applicazioni di ufficio, le pagine Web e le presentazioni
multimediali. Non fornisce invece informazioni sulla progettazione dell’hardware.
Le ISO/TS 16071 promuovono lo sviluppo dell’usabilità dei sistemi interattivi in relazione con le
tecnologie assistive, quando sono richieste. Non coprono il comportamento o i requisiti delle
tecnologie assistive in se stesse.
Sono elaborate all’interno del Comitato tecnico ISO 159: "Ergonomics".
Per fare un semplice esempio possono occuparsi di un aumento delle dimensioni dello
schermo, del contrasto o della visibilità globale, delle caratteristiche quali video "fuori misura"
o dei caratteri di dimensioni più grandi.
Compito di questa norma ISO è quindi quello di definire dei principi a cui i produttori di sistemi
operativi e di applicazioni dovranno adeguarsi per garantire una completa accessibilità.
Sono richiamate espressamente all’interno dell’attuale bozza di lavoro delle ATAG 2.0.
ISO 9241-151
Ergonomics of human-system interaction - Part 151: Guidance on World Wide Web user
interfaces.
La ISO 9241-151 fornisce delle raccomandazioni e delle linee guida per lo sviluppo centrato
sull'utente delle interfacce per il World Wide Web con lo scopo di incrementarne l'usabilità.
Alcune delle raccomandazioni presenti in questo standard possono essere applicate a differenti
interfacce utente, mentre non sono tra gli obiettivi specifici le periferiche di tipo mobile o PDA.
Le raccomandazioni si focalizzano sui seguenti aspetti:
Scopi e strategie di un'applicazione Web;
Contenuti e funzionalità;
Navigazione ed interazione;
Sviluppo e presentazione di media.
- 326 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Non sono incluse invece indicazioni sull'estetica e sull'arte del design delle interfacce.
Questo standard si occupa anche di aspetti altri specifici come:
La veridicità;
La sicurezza;
La credibilità.
Tali aspetti non sono considerati dagli standard ISO per le applicazioni e le interfacce, ma
dovranno però essere un punto di riferimento per lo sviluppo di interfacce Web essendo
comunque degli standard internazionali di ergonomia.
Attualmente le raccomandazioni 9241-151 sono in fase di sviluppo e l’ultimo documento valido
risale al 3 Novembre del 2006.
ISO 9241-171
Ergonomics of human-system interaction - Part 171: Guidance on software accessibility
La ISO 9241-171 è un importante contributo alla fruibilità dei sistemi informatici da parte di
qualsiasi utente, anche per coloro che soffrono di una disabilità temporanea o permanente.
Il documento è finalizzato a dare la possibilità a persone con disabilità di lavorare e usufruire
degli applicativi fornendo delle linee guida per programmare software che tengano conto delle
varie capacità fisiche e sensoriali dell'utilizzatore finale.
Attualmente sono in fase di sviluppo e l’ultimo documento valido risale al 24 Novembre del
2006.
IV.8 - UAAG
(W3C WAI RECOMMENDATION- 17 DICEMBRE 2002)
Come fatto presente in precedenza, il progetto WAI del W3C non contiene solamente le linee
guida per l’accessibilità dei siti Web (le WCAG), ma anche linee guida appositamente studiate
per i programmi utente (user agent), le cosiddette UAAG (User Agent Accessibility
Guidelines).
Questa raccomandazione del WAI fornisce le linee guida per lo sviluppo degli User Agent, al
fine di diminuire le barriere per l'accessibilità del Web per persone con disabilità (visuali,
uditive, fisiche, cognitive e neurologiche).
Uno User Agent che risulta conforme alle linee guida promuoverà l'accessibilità attraverso
- 327 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
la struttura dell'interfaccia utente e attraverso altre ottimizzazioni interne, includendo la tra
queste la capacità di comunicare con altre tecnologie (soprattutto tecnologie assistive). 1
In ogni caso, tutti gli utenti, non solo gli utenti disabili, ottengono maggiore usabilità dagli User
Agent che siano conformi a questa raccomandazione.
Oltre ad essere di supporto agli sviluppatori di browser, media player ed altro, le UAAG sono
inoltre di supporto agli sviluppatori di tecnologie assistive in quanto informano su quali
informazioni e controlli una tecnologia assistiva si aspetta di avere a disposizione da uno User
Agent conforme.
Il documento è composto da:
L'introduzione che fornisce il contesto per comprendere i requisiti;
I dodici principi generali per lo sviluppo accessibile, definiti linee guida. Ogni linea guida
consiste in una serie di requisiti chiamati punti di controllo che devono essere
soddisfatti per rendere conforme lo User Agent alle raccomandazioni;
Le definizioni e le regole di conformità;
Un glossario;
Un elenco di riferimenti che include dei collegamenti ad altri documenti utili tra cui una
griglia di controllo (checklist) che elenca e riassume tutti i punti di controllo per la
verifica pratica.
Come per le WCAG, i punti di controllo hanno tre livelli di priorità:
Priorità 1: devono essere assolutamente soddisfatti;
Priorità 2: dovrebbero essere soddisfatti;
Priorità 3: devono essere tenuti in considerazione.
Vediamo un elenco riassuntivo delle linee guida, senza soffermarci sui punti di controllo. La
traduzione italiana è del sito ministeriale2, il contenuto originale può essere facilmente
consultato sul sito ufficiale del W3C3.
1.
Supportare l'indipendenza dagli strumenti di input e output:
Gli utenti devono poter interagire con gli user agent, e con il contenuto che
genereranno, attraverso qualsiasi strumento di input ed output;
2.
Assicurare l'accesso a tutti i contenuti da parte di tutte le tipologie di utenti:
Gli user agent devono permettere l'accesso a tutti i contenuti attraverso una serie di
1
2
3
Roberto Castaldo: [http://www.webaccessibile.org/argomenti/argomento.asp?cat=600]
[http://www.pubbliaccesso.gov.it/biblioteca/manualistica/accessibilita_siti/useragent/ linee_guida_1-6.htm]
[http://www.w3.org/TR/UAAG10/]
- 328 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
meccanismi complementari. Questi devono essere organizzati in modo da sostituirsi
l'uno agli altri in caso di mal funzionamento;
3.
Permettere agli utenti di configurare gli user agent, in modo che non generino
contenuti che riducono l'accessibilità:
Gli utenti devono poter bloccare la presentazione di alcuni tipi di contenuti, come
audio, video, script che possono, in alcuni casi, ridurre l'accessibilità, oscurando altri
tipi di contenuti o disorientando l'utente.
4.
Assicurare il controllo da parte degli utenti della presentazione delle pagine:
Gli utenti devono poter selezionare, tra le opzioni proposte dagli user agent, gli stili a
loro più congeniali relativi per esempio ai colori, alla grandezza del testo mostrato,
alle caratteristiche dell'audio sintetizzato. Inoltre, l'utente deve poter modificare gli
stili specificati dagli autori e quelli di default degli user agent;
5.
Assicurare il controllo da parte dell'utente del comportamento dell'interfaccia:
Gli utenti devono poter controllare il comportamento delle schermate e degli altri
elementi delle interfacce utenti, inclusi quelli che possono essere manipolati dagli
autori;
6.
Implementare le interfacce standard dei programmi applicativi:
Per accrescere l'accessibilità degli user agent, questi devono comunicare con gli altri
software, quali le tecnologie assistive, l'ambiente di sviluppo e i plug-in, attraverso
interfacce che seguano gli standard, come le API, Application Programming
Interfaces;
7.
Osservare le convenzioni dell'ambiente di sviluppo:
Seguire le convenzioni dell'ambiente di sviluppo dell'utente, accresce l'accessibilità
degli user agent;
8.
Implementare le specifiche che promuovono l'accessibilità:
Gli sviluppatori devono implementare le specifiche del W3C;
9.
Fornire meccanismi di navigazione:
Gli utenti devono poter raggiungere sempre l'informazione rilevante all'interno del
documento;
10.
Permettere all'utente di orientarsi:
All'interno del documento, bisogna fornire una serie di informazioni e meccanismi che
permettano all'utente di capire il contesto in cui sta navigando;
11.
Permettere la configurazione e la personalizzazione degli user agent:
Gli utenti devono poter configurare gli user agent in modo da poter accedere in
maniera più veloce alle operazioni più frequentemente effettuate e in modo da poter
salvare le loro preferenze sullo stile di presentazione del documento, sulla
configurazione dell'interfaccia utente grafica, sui comandi da tastiera e su altre
caratteristiche;
- 329 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
12.
Fornire documentazione e sistemi di aiuto accessibili:
L'utente deve poter conoscere quali sono le caratteristiche del software che
favoriscono l'accessibilità attraverso la documentazione.
Vorrei far notare brevemente come la linea guida 4 raccomandi di permettere agli utenti di
gestire gli stili applicati al documento, e questo, non solo attraverso la possibilità di
sovrapporne uno proprio, ma anche consentendo agli utenti di selezionare ed applicare i
fogli di stile alternativi previsti dagli autori1.
L’osservanza di questa direttiva permetterebbe di gestire la scelta dei fogli di stile alternativi
tramite un più naturale controllo da menù del browser piuttosto che costringere il progettista
all’utilizzo degli script. Molti dei browser più recenti si sono adeguati a questa normativa, tra i
pochi che ancora impediscono questa utile funzionalità ricordo ancora una volta Internet
Explorer.
Associati con queste linee guida e con in relativi punti di controllo, le UAAG, forniscono anche
una utile griglia di controllo, come per le WCAG.
Questa permette di verificare in modo preciso e selettivo i singoli punti di controllo per arrivare
ad ottenere una vera dichiarazione di accessibilità dello user agent.
Non la riporto per brevità, ma può essere direttamente scaricata e stampata dal sito ufficiale
del W3C.2. Esistono anche traduzioni in italiano tra cui segnalo quella di Roberto Scano. 3
IV.9 - ATAG
(1.0 - W3C WAI RECOMMENDATION - 21 DICEMBRE 2000)
(2.0 - W3C WAI WORKING DRAFT - 7 DICEMBRE 2006)
Come abbiamo visto, il progetto WCAG del WAI si concentra sulla possibilità di rendere
maggiormente accessibile i contenuti presenti sul Web.
D’altro canto, il progetto UAAG presenta delle linee guida concernenti la modalità con la quale i
programmi utente dovrebbero essere concepiti per interagire correttamente con in contenuti in
rete.
A completare questa filosofia d’insieme, il gruppo WAI ha predisposto anche delle linee guida
per i programmi utilizzati dagli autori delle pagine Web per creare le informazioni. Sono le
1
UAAG 4.14: “Allow the user to choose from and apply alternative author style sheets (such as linked style
sheets).” - [http://www.w3.org/TR/UAAG10-TECHS/intro.html#tech-select-style-sheets]
2
[http://www.w3.org/TR/UAAG10/uaag10-chktable.html]
3
Roberto Scano: “Accessibilità, dalla teoria alla realtà”
- 330 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
cosiddette ATAG (Authoring Tools Accessibility Guidelines), ossia linee guida per
l'accessibilità degli strumenti di sviluppo.
Le finalità di queste raccomandazioni del W3C per chi produce i programmi di sviluppo sono
duplici:
Avere dei sistemi di sviluppo che generino per impostazioni predefinite dei contenuti
accessibili al fine di supportare ed incoraggiare gli sviluppatori a creare contenuti di
qualità;
Avere dei sistemi di sviluppo che possiedano delle interfacce accessibili agli autori di
contenuti, senza discriminarne la disabilità.
A tale proposito, una forte spinta si è avuta negli ultimi anni anche dal Parlamento Europeo.
Con la già citata e fondamentale risoluzione1 del Parlamento Europeo (2002)0325 sulla
comunicazione della Commissione "eEurope 2002: accessibilità e contenuto di siti Internet
delle amministrazioni pubbliche", al punto K, si è esplicitamente fatto riferimento alle
raccomandazioni ATAG.
Al punto 4 poi, della medesima risoluzione, gli stati europei sono esortati a conformarsi alle
Authoring Tools Accessibility Guidelines (ATAG) 1.0, sempre entro il 2003, al fine di consentire
ai disabili non soltanto di leggere le pagine Web ma anche di gestirne il contenuto.
Il documento non specifica però il livello di conformità minimo richiesto per le ATAG 1.0:
parlando di conformità è comunque scontato quantomeno il raggiungimento del livello A della
raccomandazione W3C per l'accessibilità degli strumenti di sviluppo.
La finalità delle ATAG, quindi, è quella di offrire a tutti gli utenti la possibilità di creare
contenuti accessibili2, tenendo conto del fatto che gli strumenti di sviluppo utilizzati per
generare queste informazioni siano anch'essi accessibili e che possano essere utilizzati
anche dai soggetti con disabilità.
Versione 2.0
Allo stato attuale dei lavori è appena stato rilasciato un Working Draft delle ATAG 2.0 il 7
dicembre del 2006.
Le ATAG 2.0 sono state progettate per essere compatibili con le WCAG 2.0, oltre che con le
precedenti WCAG 1.0.
1
2
[http://www4.europarl.eu.int/registre/recherche/NoticeDetaillee.cfm?docid=6886& doclang=IT]
“Everyone should have the ability to create and access Web content.” – [http://www.w3.org/TR/ATAG20/]
- 331 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il gruppo WAI è intenzionato a portare a termine la nuova versione per la fine del 2007, ma il
tempo di completamento non è predicibile. Fino al loro definitivo rilascio il documento di
riferimento resta quello delle ATAG 1.0.
Dato che le ATAG non rappresentano il fulcro di questo lavoro, preferisco riferirmi comunque in
questa breve sezione alla versione 2.0 nonostante non sia ancora quella stabile ed ufficiale.
Le differenze fondamentali sono:
Ristrutturazione delle linee guida secondo la metodologia delle nuove WCAG 2.0;
Considerazione delle nuove tecnologie per il Web tra cui i CMS (Content Management
System);
Adeguamento ai nuovi riferimenti alle WCAG 2.0;
Considerazione1 della normativa ISO TS/16071 2002 che regola l’accessibilità delle
interfacce umane con il computer e contiene specificatamente delle linee guida
sull’accessibilità delle applicazioni.
Vi sono diverse categorie di strumenti di sviluppo che possono essere coinvolti dalle direttive
contenute nelle ATAG 2.0. Un elenco informativo è contenuto nello stesso documento del W3C
e sono direttamente citate nel documento di tecniche al momento di fare degli esempi pratici di
applicazione dei principi. All'interno di un singolo strumento di sviluppo integrato, le diverse
parti dell'interfaccia possono ricadere in una o più delle tipologie di funzionalità descritte in
seguito.
Le tipologie di funzionalità di sviluppo implementate aiuteranno a determinare quale delle
tecniche previste dalle ATAG 2.0 sono applicabili ad un particolare strumento:
Funzionalità di sviluppo a livello di codice. L'autore ha il controllo completo su tutte le
funzioni riguardanti il risultato finale del contenuto Web. Questo riguarda, ma non solo,
la gestione di testo e la gestione di ambienti visuali di sviluppo creati per consentire
all'autore la stessa libertà di controllo garantito dalla gestione del testo (per esempio,
sistemi di gestione del posizionamento degli elementi in modalità grafica). Un esempio
può essere un editor di testo;
Funzionalità di sviluppo WYSIWYG (What-You-See-Is-What-You-Get). L'autore ha il
controllo sulle entità che assomigliano molto all'apparenza e al comportamento finale
del contenuto Web risultante. Un esempio può essere fornito da editor che gestiscono
pagine Web, editor che consentono la gestione di immagini bitmap, eccetera;
1
[http://www.w3.org/WAI/AU/2006/WD-ATAG20techs-20060711/tech1.htm]
- 332 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Funzionalità di sviluppo orientata agli oggetti. L'autore ha il controllo delle entità non
WYSIWYG che rappresentano un'astrazione funzionale delle funzioni di basso livello per
il risultato del contenuto Web. Un esempio può esser dato da linee temporali, editor
basati su grafica vettoriale, eccetera;
Funzionalità di sviluppo indirette. Gli autori hanno il controllo solamente per parametri
di alto livello relativi alla produzione automatizzata di contenuti Web risultanti. Questi
possono includere le interfacce che assistono l'autore nella creazione e
nell'organizzazione dei contenuti Web senza che l'autore abbia il controllo sulla
marcatura o su implementazioni di programmazione. Esempi possono essere: sistemi di
gestione contenuti (CMS), sistemi automatizzati per la creazione di siti Web, sistemi di
gestione per siti Web, corsi on-line, sistemi di Weblog, aggregatori di contenuti,
strumenti di conversione, eccetera.
Le ATAG 2.0 sono accompagnate da un documento di tecniche che illustra come possono
essere soddisfatti i principi guida.
Contenuti
Le ATAG 2.0, nel Working Draft del dicembre 2006, sono organizzate in parti, linee guida,
punti di controllo e criteri di successo.
Vediamo un rapido elenco per sommi capi delle due parti e dei punti di controllo relativi.
Parte A.
Rendere accessibile l’interfaccia utente degli strumenti di sviluppo.
I punti di controllo di questa sezione sono progettati per incrementare le capacità di creazione
per gli autori disabili. Per questo motivo le specifiche sono strettamente incentrate
sull’accessibilità dell’interfaccia utilizzata dai progettisti per il loro lavoro:
Linea guida A.1: “L’interfaccia utente degli strumenti di sviluppo deve essere
percepibile.”.
Perché uno strumento di sviluppo possa dirsi accessibile, gli autori devono essere in
grado di percepire i controlli della propria interfaccia utente;
Linea guida A.2: “L’interfaccia utente degli strumenti di sviluppo deve essere fruibile.”.
Perché uno strumento di sviluppo possa dirsi accessibile, gli autori devono essere in
grado di operare con i controlli della propria interfaccia utente;
Linea guida A.3: “L’interfaccia utente degli strumenti di sviluppo deve essere
Comprensibile.”
Perché uno strumento di sviluppo possa dirsi accessibile, gli autori devono essere in
grado di comprendere i controlli della propria interfaccia utente che possono percepire
ed utilizzare;
- 333 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Linea guida A.4: “L’interfaccia utente degli strumenti di sviluppo deve essere
compatibile con le modalità di accesso al sistema.”.
Le tecnologie assistive come ad esempio gli screen-reader e gli ingranditori possono
garantire un miglioramento della visualizzazione e del controllo ai loro utenti solamente
se gli strumenti di sviluppo supportano e documentano i protocolli di documentazione
su cui sono basati.
Parte B
Supportare la produzione di contenuti accessibili.
I punti di controllo della parte B sono concepiti per incrementare l’accessibilità dei contenuti
Web prodotti da qualunque autore per un utente finale disabile. Sebbene i requisiti di questa
parte non si occupino direttamente dell’accessibilità dell’interfaccia utente degli strumenti di
sviluppo, va notato che qualunque aspetto integrato per soddisfare la parte B deve anche
soddisfare le richieste di accessibilità dell’interfaccia utente definite nella parte A.
Linea guida B.1: “Consentire la produzione di contenuti accessibili.”.
La creazione di contenuto accessibile è in relazione al comportamento dello strumento
di sviluppo e dell’autore. Questa linea guida definisce le responsabilità specifiche dello
strumento di sviluppo;
Linea guida B.2: “Agevolare l’autore nella produzione di contenuti accessibili.”.
Alcune azioni intraprese dallo sviluppatore potrebbero portare alla creazione di pagine
inaccessibili. In queste situazioni lo strumento di sviluppo dovrebbe includere delle
caratteristiche che forniscano direttive e supporto agli autori in modo che possano
essere seguite le corrette prassi di sviluppo per produrre contenuti Web accessibili;
Linea guida B 3: “Promuovere ed integrare le soluzioni accessibili.”
Questa linea guida richiede che gli strumenti di sviluppo debbano incoraggiare una
prassi di sviluppo accessibile al loro interno, così come favorire l’integrazione di
caratteristiche a supporto dell’accessibilità che siano state aggiunte per soddisfare gli
altri requisiti di questo documento.
Conformità
Ogni punto di controllo ha assegnato un livello di priorità che ne indica l’importanza e
determina quali di questi debbano essere soddisfatti per permettere allo strumento di sviluppo
di raggiungere uno specifico livello di conformità.
Ci sono due tipologie di punti di controllo, quelli con priorità regolare e quelli con priorità
relativa alle WCAG.
- 334 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Punti di controllo a priorità regolare
I punti di controllo hanno delle priorità il cui significato dipende dalla parte della normativa in
cui si trovano:
Priorità di livello 1: il punto di controllo è essenziale per l’accessibilità:
o
Parte A: Se lo strumento di sviluppo non soddisfa questo punto di controllo uno
o più gruppi di sviluppatori disabili troveranno impossibile produrre pagine Web
usando lo strumento;
o
Parte B: il punto di controllo è essenziale per aiutare tutti gli sviluppatori a
creare contenuti Web conformi alle WCAG;
Priorità di livello 2: il punto di controllo è importante per l’accessibilità:
o
Parte A: Se lo strumento di sviluppo non soddisfa questo punto di controllo uno
o più gruppi di sviluppatori disabili troveranno difficoltoso produrre pagine Web
usando lo strumento;
o
Parte B: il punto di controllo è importante per aiutare tutti gli sviluppatori a
creare contenuti Web conformi alle WCAG;
Priorità di livello 3: il punto di controllo favorisce l’accessibilità:
o
Parte A: Se lo strumento di sviluppo non soddisfa questo punto di controllo uno
o più gruppi di sviluppatori disabili troveranno inefficiente produrre pagine Web
usando lo strumento;
o
Parte B: il punto di controllo è vantaggioso per aiutare tutti gli sviluppatori a
creare contenuti Web conformi alle WCAG.
Punti di controllo a priorità relativa
Esistono dei punti di controllo con delle priorità definite come relative. Sono delle priorità che
fanno riferimento alla versione delle WCAG a cui il valutatore ha scelto di riferirsi per le
specifiche.
L’importanza di ogni punto di controllo a priorità relativa dipende dalle specifiche delle WCAG a
cui si riferiscono.
Questi punti di controllo possono essere soddisfati a 3 livelli di priorità:
Priorità relativa livello 1: sono stati soddisfatti i punti di controllo a livello A delle WCAG
di riferimento;
Priorità relativa livello 2: sono stati soddisfatti i punti di controllo a livello doppia-A delle
WCAG di riferimento;
Priorità relativa livello 3: sono stati soddisfatti i punti di controllo a livello tripla-A delle
WCAG di riferimento.
Se un creatore di uno strumento di sviluppo intende dichiarare la conformità alle ATAG 2.0 del
suo prodotto, deve prima definire un documento di verifica specifico in relazione alle WCAG che
- 335 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
intende usare, successivamente, per ogni punto di controllo a priorità relativa delle ATAG 2.0,
deve utilizzare tale documento come verifica per determinare se i criteri di successo sono stati
soddisfatti.
Livelli di conformità
Come conseguenza del soddisfacimento delle precedenti linee guida nei relativi criteri di
successo, uno strumento di sviluppo può dichiarare la sua conformità alle ATAG 2.0 secondo
tre livelli di qualità. Il livello raggiunto dipende dalla priorità di quei punti di controllo per i quali
lo strumento di sviluppo ha soddisfatto i relativi criteri di successo.
I livelli sono:
Livello A: lo strumento di sviluppo ha soddisfatto tutti i punti di controllo a priorità
regolari di livello 1, ed anche tutti i punti di controllo a priorità relativa almeno di livello
1;
Livello Doppia-A: lo strumento di sviluppo ha soddisfatto tutti i punti di controllo a
priorità regolari di livello 1 e 2, ed anche tutti i punti di controllo a priorità relativa
almeno di livello 2;
Livello Tripla-A: lo strumento di sviluppo ha soddisfatto tutti i punti di controllo a
priorità regolari, ed anche tutti i punti di controllo a priorità relativa fino al livello 3.
Da notare, come del resto anche per le altre raccomandazioni del W3C, che la pretesa di
conformità a qualunque livello non implica che il W3C abbia verificato la
dichiarazione o che ne garantisca la validità. I dichiaranti sono i soli responsabili della
correttezza della loro dichiarazione e del suo aggiornamento.
IV.10 - ARIA
(W3C WAI WORKING DRAFT – UPDATED 20 DICEMBRE 2006)
Il 26 settembre 2006 la Web Accessibility Initiative (WAI) del W3C ha presentato una raccolta
di documenti che rende più facile agli sviluppatori di siti Web rendere il contenuto Web
dinamico usabile da persone disabili, si tratta della suite di protocolli WAI-ARIA (Accessible
Rich Internet Application).
Le motivazioni e le finalità di questa suite di protocolli sono quelle esposte Rich Schwerdtfeger,
Distinguished Engineer dell'IBM e autore della WAI-ARIA Roadmap:
Mentre gli utenti richiedono sempre più al Web - più informazioni, più applicazioni
interattive ed esperienze coinvolgenti - si assiste ad un’esplosione nello sviluppo di tecnologie,
che esclude però dall'accesso al Web un numero troppo elevato di persone. La pubblicazione di
questa nuova suite di documenti è importante perché aiuterà gli sviluppatori ad avere accesso
ai tool necessari al supporto di utenti disabili sul Web. ARIA è il primo passo per fornire
- 336 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
l'accesso ad una più ricca esperienza del Web dinamico a tutti gli utenti del Web, attraverso
miglioramenti nelle tecnologie, ad esempio implementazioni migliori e più accessibili.1
Web dinamico accessibile
Il Web dinamico attualmente esclude milioni di utenti.
Le tecnologie assistive, inclusi screen-reader, software d’interpretazione vocale e tastiere sullo
schermo, aiutano a rendere il Web accessibile a utenti disabili. Per funzionare, questi strumenti
necessitano di informazioni sulla semantica di porzioni specifiche di un documento, per poterle
poi presentare in formato accessibile. Ad esempio, per poter accedere in modo attendibile a un
elemento, uno strumento deve essere in grado di riconoscere anche lo stato dell'elemento
stesso se è, ad esempio, selezionato o disabilitato, se ha il focus, se è chiuso o nascosto.
I siti Web stanno offrendo sempre più applicazioni con capacità paragonabili al software
installato localmente sulla macchina. Queste applicazioni Internet più complete (rich internet
applications) fanno un pesante uso di scripting e gli sviluppatori includono spesso forme ibride
di tecnologie già esistenti, come AJAX, DHTML, JavaScript e SVG.
Tuttavia queste applicazioni non sempre forniscono la semantica necessaria al supporto delle
tecnologie assistive utilizzate e gli utenti disabili rischiano quindi di essere tagliati fuori da
questo nuovo modo di presentare l’informazione.
Le ARIA Suite specificano come rendere accessibili alle persone disabili le caratteristiche più
avanzate dei contenuti dinamici e delle applicazioni internet più complete rendendo accessibili i
controlli dell’interfaccia utente (come ad esempio l’espansione dei menù di navigazione) alle
tecnologie assistive.
Schema del progetto
Per il momento il progetto ARIA è in fase di definizione, è stato annunciato nel Settembre del
2006 come una raccolta di documenti che costituiscono un framework per realizzare contenuti
Web dinamici accessibili.
Le attuali documentazioni della ARIA sono state progettate per:
Sviluppatori di browser, tecnologie assistive e programmi utente;
Sviluppatori di tecnologie Web (come specifiche tecniche);
Sviluppatori di strumenti per la valutazione dell’accessibilità.
Il First Public Working Draft di WAI-ARIA Suite include:
1
[http://www.w3c.it/pr/2006/aria-pressrelease-it.html]
- 337 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
WAI-ARIA Roadmap;
WAI-ARIA Roles;
WAI-ARIA States and Properties.
In oltre, per gli sviluppatori di contenuti Web e di strumenti di creazione delle pagine Web, una
documentazione a parte dovrebbe illustrare le migliori tecniche per implementare le ARIA nei
contenuti Web.
WAI ritiene che le ARIA dovrebbero svilupparsi dallo stato di Last Call fino a diventare delle
Recommendation ufficiali del W3C entro il 2007.
ARIA Roadmap
La Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap) descrive un
approccio generale per assicurare l'interoperabilità tra le applicazioni Internet più complete e le
tecnologie assistive utilizzate da persone con disabilità. L'approccio si basa sulle tecnologie già
sviluppate o in fase di sviluppo da parte del W3C.
Il roadmap delle ARIA definisce che tipo di tecnologia debba essere impiegata per rendere
accessibili il contenuto Web dinamico e le applicazioni internet complesse.
Viene considerata anche una analisi delle attuali lacune, di cosa sia necessario, di cosa sia
disponibile e di cosa sia ancora del tutto mancante per assicurare applicazioni internet
complete ed accessibili.
Due documenti spiegano come colmare queste lacune:
Roles for Accessible Rich Internet Applications (WAI-ARIA Roles);
States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA
States).
I browser Web e gli altri programmi utenti impiegano le API (Application Program Interface)
per comunicare con le tecnologie assistive, il piano di sviluppo delle ARIA chiarisce quali aspetti
del Web dinamico debbano essere messi a disposizione tramite API di accessibilità.
Il roadmap indica le tecnologie per mappare i controlli, le regioni attive AJAX e gli eventi per le
API della accessibilità, inclusi i controlli proprietari utilizzati per le applicazioni internet più
complete. In oltre delinea anche le nuove tecniche di navigazione per contrassegnare le
comuni strutture Web, come ad esempio i menu, i contenuti primari e secondari, i banner
informativi e gli altri tipi di strutture Web.
Queste nuove tecnologie possono essere utilizzate per incrementare l’accessibilità e l’usabilità
delle risorse Web per le persone disabili senza sostanziali modifiche all’insieme di quelle
esistenti.
- 338 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
ARIA Roles
Le regole ARIA forniscono un dizionario delle caratteristiche della pagina Web per le interazioni
con l’utente, includendo le destinazioni per la navigazione e i widget interattivi.
Alcuni esempi sono:
Barre di navigazione;
Liste espandibili e collassabili, denominate controlli ad albero.
ARIA States and Properties
Gli stati e le proprietà permettono ai linguaggi XML di esprimere come gli aspetti delle pagine
Web si relazionino una con le altre, e quali sono i loro stati correnti.
Esempi sono:
Relazioni, ad esempio quando un widget controlla il contenuto di un’altra parte di un
documento Web;
Gli stati, ad esempio se un dato ramo di una lista ad albero sia in un certo momento
espanso o collassato.
- 339 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
V. L’accessibilità nella realtà
In questa sezione vorrei presentare la materia nei suoi aspetti più pratici, esponendo
l’esperienza concreta e riportando osservazioni utili alle persone disabili nella loro realtà
quotidiana di utenti del Web.
Una prima carrellata dei dispositivi e delle tecnologie assistive verrà seguita da informazioni
sulla accessibilità e sulla disponibilità di software adeguato.
Infine, riportando l’esperienza e le conoscenze di persone che lavorano in questa realtà ho
inteso presentare qualcosa di più aggiornato e concreto sullo stato attuale delle conoscenze in
materia.
V.1 - Ausili informatici per i disabili
Alcune categorie di disabili sensoriali e motori possono avvalersi di strumenti o programmi che
permettono loro di svolgere delle attività che altrimenti non sarebbero in grado di compiere.
Si tratta delle cosiddette tecnologie compensative, dette anche tecnologie assistive o ausili.
Per molti tipi di disabilità esistono delle corrispondenti tecnologie ed attrezzature specifiche
progettate appositamente per favorire l’interazione con il computer. Un valido elenco di tali
dispositivi, corredato anche da una opportuna descrizione può essere consultato sul sito della
fondazione ASPHI Onlus1. Per altri approfondimenti, soprattutto per i disabili visivi, si consiglia
anche la visita al sito2 dell’ANS (Associazione Nazionale Subvedenti).
Ricordo che, oltre le tecnologie di ausilio, sono disponibili anche delle configurazioni specifiche
che possono essere predisposte direttamente dal sistema operativo o dal software in
esecuzione sul computer stesso.
Qui presento un piccolo riassunto degli strumenti più rilevanti, come esposto ancora una volta
sul sito ufficiale del ministero3 e come indicato anche sul sito di WebAccessibile4.
Strumenti per i non vedenti
Quando i non vedenti usano un computer non hanno, solitamente, difficoltà ad utilizzare come
sistema di input la normale tastiera.
Invece, è assolutamente impossibile per i non vedenti usare il mouse, in quanto la percezione
e l'utilizzo di uno spazio dimensionale risulta a loro precluso.
1
2
3
4
[http://www.asphi.it/TecnologiaAusili/TecnologiaAusili.htm]
[http://www.subvedenti.it/Ausili.asp]
[http://www.pubbliaccesso.gov.it/biblioteca/manualistica/accessibilita_siti/introduzione/ profili.htm]
Roberto Castaldo: [http://www.webaccessibile.org/argomenti/documento.asp?DocID=425]
- 340 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Lo strumento maggiormente usato dalle persone non vedenti è lo screen-reader.
Screen-reader
Si tratta di programmi che interpretano i contenuti testuali mostrati dalle applicazioni o dal
sistema operativo. Lo screen-reader è in grado di descrivere in modo testuale ciò che appare
sullo schermo e le operazioni del programma in funzione.
Una volta interpretati dallo screen-reader, i testi vengono presentati al non vedente da una
barra Braille o da un dispositivo di sintesi vocale. Pertanto sono condizione indispensabile per
l’accesso al computer da parte di una persona non vedente.
Gli screen-reader più conosciuti sono:
Freedom Scientific JAWS;
Dolphin Hal;
GW Micro Window Eyes;
IBM Home Page Reader;
Alva OutSpoken.
Entreremo nel merito di questi strumenti in una sezione apposita.
Barra Braille
Alla base del funzionamento della barra Braille vi è il linguaggio Braille, che è un sistema di
scrittura basato su simboli puntiformi in rilievo. Ciascuna lettera o numero è simbolizzato dalle
diverse combinazioni di sei o otto punti disposti in celle di due colonnine di quattro punti
ciascuna.
Esistono due versioni dell’alfabeto Braille: una versione classica a 6 punti e una versione
informatica ad 8 punti, per una migliore corrispondenza con il codice ASCII.
Questi caratteri vengono decifrati dai non vedenti sfiorando con i polpastrelli le combinazioni di
punti in rilievo.
La barra Braille, o display Braille, è uno strumento informatico che, sollevando e abbassando i
punti di una sequenza di celle, fornisce al non vedente una linea scritta in Braille.
- 341 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Figura 8 – Una Barra Braille
Attraverso questa linea è possibile la lettura tattile di ciò che lo screen-reader trasmette via via
che l'utilizzatore esplora il monitor per mezzo di appositi tasti.
Sintetizzatore vocale
Esistono apparecchiature o software che, campionati opportunamente, producono una voce
sintetica utilizzabile per la lettura a voce alta dei testi che appaiono sul monitor e interpretati
dagli screen-reader.
La campionatura avviene sulla base di combinazioni di suoni elementari, di regole desunte da
modelli matematici dell'apparato umano e su algoritmi di analisi del testo scritto.
Attualmente, i sintetizzatori vocali leggono secondo le preferenze dell'utente.
In particolare è possibile selezionare la lingua, il soggetto parlante (maschile o femminile), il
tono e il modo di lettura (continuativo, parola per parola, per singole lettere alfabetiche, con o
senza punteggiatura).
Stampanti Braille
Vi sono stampanti Braille appositamente create per riprodurre in rilievo, su carta, testi in
formato ASCII.
Figura 9 - Una stampante Braille
- 342 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Esse funzionano all'incirca come le normali stampanti, anche se presentano qualche problema
legato alla velocità d’esecuzione.
Le stampanti Braille sono un po' più lente, poiché devono sbalzare i punti in rilievo su una
carta di adeguato spessore, con parti meccaniche in movimento molto più pesanti di una
normale stampante ad inchiostro.
Scanner
Non sono specifici ausili per persone non vedenti, perché si usano normalmente per acquisire
immagini e documenti. La loro diffusione in qualsiasi ambiente lavorativo costituisce un
vantaggio per chi ha problemi di accesso alle informazioni, poiché può avvalersi di uno
strumento già comunemente in uso.
L’impiego di uno scanner come ausilio per i non vedenti consiste nell’acquisizione di testi
stampati su carta e nella loro conversione in documenti digitali grazie a programmi OCR
(Optical Character Recognition). Dopo questa trasformazione i documenti possono essere
agevolmente letti tramite screen-reader.
Software utilizzati dai non vedenti
I non vedenti utilizzano diversi software per agevolarsi nella lettura del contenuto; tra questi:
Browser grafici (Internet Explorer o Netscape Navigator) o browser testuali (Lynx), in
combinazione con uno screen-reader con sintesi vocale o riga Braille;
Programmi di formattazione Braille, come Italbra o Duxbury Braille Translation:
software in grado di trasformare in Braille qualsiasi testo che può essere stampato in
rilievo dall'apposito hardware.
Strumenti per ipovedenti
Gli strumenti di ausilio utilizzati dagli ipovedenti sono:
Gli ingranditori, software con la funzione di aumentare le dimensioni di ciò che appare
sul monitor. L'ingrandimento riduce la porzione di schermo che può essere consultata.
Con un sistema di ricerca, comandato in genere con il mouse, è possibile selezionare la
parte di video che interessa.
Le funzioni di zoom offerte dai vari programmi. Nel Web, in particolare, ci sono molte
possibilità offerte dai browser stessi per ingrandire i caratteri.
Ingranditori
Gli ingranditori sono programmi che si installano sul PC che ingrandiscono, alcuni anche fino a
32 volte, quanto è presente sullo schermo. Ovviamente la persona dovrà usare continuamente
il mouse per scorrere le finestre, di cui vedrà soltanto una piccola parte per volta.
- 343 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Molti ingranditori hanno anche una sintesi vocale, che permette di leggere lunghi documenti
senza guardarli.
Gli ingranditori più conosciuti sono:
Ai Squared Zoomtext;
Visulex Lp (dos/Windows);
Dolphin Lunar;
Freedom Scientific Magic.
Leggibilità dei testi
La leggibilità dei testi è un aspetto rilevante per rendere le pagine accessibili alle persone
ipovedenti. In ogni caso, la creazione di testi leggibili favorisce tutti gli utenti del Web.
La leggibilità è condizionata soprattutto:
Dal contrasto tra il colore del testo e il colore dello sfondo;
Dal tipo di font dei caratteri;
Dalle dimensioni dei caratteri;
Dallo spessore e dalla nitidezza del tratto;
Dalla distanza tra i caratteri e tra le righe.
Bisogna, inoltre, ricordarsi che c'è differenza tra la leggibilità dei testi e quella delle scritte
realizzate come immagini.
Per i primi si può pensare che alcuni aspetti possono essere modificati direttamente
dall'utente, come la grandezza dei font.
Invece, per i testi fissi realizzati tramite immagini, bisogna assolutamente ricordarsi di non
usare caratteri piccoli. Il testo risulterebbe inaccessibile e rimarrebbe tale, in quanto non
modificabile dall'utente se non tramite un ingranditore di schermo.
Va fatto notare che finalmente le versioni più recenti dei browser incominciano a permettere
anche un ingrandimento delle immagini.
Accorgimenti per audiolesi
Per favorire le persone non udenti bisogna porre attenzione all'uso di specifici elementi. In
particolare:
I suoni significativi, come quelli di allarme, devono essere accompagnati da equivalenti
segnalazioni visive;
I dialoghi importanti ai fini della comprensione dei contenuti devono essere fruibili
tramite il classico metodo della sottotitolazione;
Il linguaggio deve tener conto delle difficoltà degli audiolesi congeniti. Essi non riescono
a comprendere facilmente testi astratti o contenenti frasi elaborate. Per questo bisogna
utilizzare un linguaggio chiaro e semplice, favorendo così tutte le categorie di utenti.
- 344 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Strumenti per le disabilità motorie
La disabilità motoria presenta problematiche differenti e per ogni individuo è necessario
personalizzare gli ausili.
Molto spesso più che di ausilio si deve parlare di sistema ausilio. Questo perché il semplice
ricorso, ad esempio, ad una tastiera ingrandita non può risolvere il problema se non è
integrata da funzioni che permettano di gestire la tastiera stessa in modo coerente con le
esigenze della persona.
Le principali categorie di ausili informatici per disabili motori sono:
Tastiere espressamente costruite;
Sensori;
Altre periferiche di input e di output specializzate.
Tastiere
Esistono tastiere costruite espressamente per utenti disabili:
Le tastiere espanse differiscono da quelle normali per la maggior dimensione dei tasti
e per la maggior distanza tra essi.
Sono adatte, quindi, per gli utenti che hanno difficoltà nella motricità fine.
Queste tastiere dispongono, in genere, anche di altri accorgimenti utili, come: la
gestione facilitata dei tasti multipli, la regolazione del tocco, i tasti concavi e non
sporgenti;
Le tastiere ridotte raggruppano tutti i tasti standard in una piccola superficie.
Sono indicate quando la motricità fine è discretamente conservata, mentre risulta
compromessa la capacità di dominare, con l'articolazione del braccio, un'area
abbastanza vasta;
Le tastiere riconfigurabili sono aree piane sensibili al tocco, la cui superficie viene
divisa in tante zone rettangolari corrispondenti ai vari tasti.
La dimensione, la posizione e il carattere assegnato a queste aree non è però costante,
ma dipende dalla mascherina (un foglio di plastica o carta contenente il disegno della
tastiera) che viene applicato.
La stessa tastiera può, quindi, essere usata in vari modi, secondo i bisogni ed i
progressi dell'utente.
- 345 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Figura 10 – Una tastiera con tasti ingranditi
Sensori
Si adattano a persone che possono muovere solo una parte del corpo e vengono generalmente
associati ad un programma a scansione. Ne esistono di tantissimi tipi e possono essere
comandati con la parte del corpo che è meglio controllabile dalla persona. Alcuni utilizzano
persino una cannuccia a soffio per rilevare il comando dell’utente.
Il programma fa scorrere i caratteri sullo schermo e, quando la persona trova quello che
desidera utilizzare, lo porta nel testo tramite il sensore collegato al suo computer.
Altre periferiche di input ed output particolari
Se l'utente non è in grado di gestire la tastiera in modo diretto, occorre impiegare strumenti di
input alternativo. Ad esempio: mouse particolari o programmi di riconoscimento vocale,
tastiere virtuali o puntatori configurabili
Due sono, attualmente, le strade percorribili: i sistemi a scansione e l'immissione a voce.
Nei sistemi comandati a voce, per esempio, al computer viene applicato un microfono, una
scheda audio e un software di riconoscimento vocale che consente di riconoscere un certo
numero di parole dettate dall'utente e di associarle a comandi.
Gli strumenti per le disabilità cognitive.
Tra i vari strumenti di ausilio per i disabili cognitivi, ci sono tastiere e schermi speciali.
Tastiere
Esistono una serie di tastiere semplificate per facilitare l'uso del computer da parte dei disabili
cognitivi e non solo.
Esse risultano adatte in casi di difficoltà cognitive, nel momento in cui si renda necessario
ridurre il numero di stimoli potenzialmente confusivi.
- 346 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Figura 11 - Una tastiera per disabili cognitivi
Infatti, la maggior parte di esse ha tasti molto grandi e differenziati per colori in base alle
funzioni svolte.
Schermo tattile (touch screen)
Il touch screen o schermo tattile è una superficie trasparente che si applica sul monitor e che
assolve completamente le funzioni del mouse.
Toccando la superficie in corrispondenza del bersaglio si ottiene un clic. Non è necessario
trascinare il puntatore per spostarlo, ma questo appare nel punto di contatto.
Lo schermo tattile può essere di aiuto in caso di difficoltà cognitive, in quanto richiede, per
interagire col computer, azioni molto immediate e istintive.
Conclusioni
A conclusione di questa panoramica, si può affermare che un sito accessibile può essere
navigato anche da persone con disabilità molto gravi, che utilizzano ausili o periferiche
specialistiche.
In genere chi crea un sito deve aver presente i molti modi di lavorare di una persona con
questi problemi, ma non ha il bisogno di preoccuparsi specificatamente di quale modalità
utilizzi per l’accesso al computer.
Naturalmente, rendersi conto di cosa significhi lavorare con periferiche particolari è
fondamentale, ma per realizzare un sito accessibile non è necessario considerare il risultato
dato dalla navigazione con ogni singolo dispositivo. 1
Questo perché la compatibilità con gli standard garantisce la progettazione di un sito
accessibile, questo almeno in linea di principio, dal momento che i produttori di queste
tecnologie software ed hardware spesso hanno gli stessi problemi di allineamento ai protocolli
WAI W3C che manifestano anche i maggiori produttori di browser e user agent.
1
Roberto Castaldo: [http://www.webaccessibile.org/argomenti/documento.asp?DocID=425]
- 347 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
A complicare la situazione, occorre aggiungere che, almeno in Italia, le tecnologie assistive non
sembrano poter contare su una situazione felice. In genere o i disabili non le ricevono mai o
continuano a cambiare con frequenza eccessiva1.
V.2 - Programmi utente
In un discorso completo sugli elementi dell’accessibilità, come questa tesi vuole essere, è
necessario fermarsi sulla definizione degli strumenti che vengono utilizzati con più frequenza
per accedere alle pagine internet.
Tali componenti giocano un ruolo essenziale nel nostro discorso sull’accessibilità. Il software
grazie al quale un utente interagisce con il contenuto internet è di primaria importanza per le
comunicazioni veicolate da un sito e questo riguarda gli strumenti che possono essere utilizzati
sia da disabili che da persone normodotate.
Una prima definizione può essere direttamente recuperata dal glossario delle WCAG, riportato
in appendice: per user agent (programmi utente o interpreti) si intende un software per
l'accesso al contenuto Web, inclusi browser grafici per desktop, browser testuali, browser
vocali, cellulari, lettori multimediali, plug-in, e alcuni software di tecnologia assistiva usati
congiuntamente a browser come lettori di schermo, ingranditori di schermo, e programmi per il
riconoscimento della voce2.
Su questa definizione non c’è molto da aggiungere, tranne il fatto che vi sono ovviamente
inclusi programmi per l’interazione con le pagine Web sia da parte di persone disabili che da
parte di utenti normodotati, e questo in piena coerenza con la definizione di accessibilità di un
sito Web. In effetti, per User Agent si intende qualsiasi prodotto che rende disponibile
contenuti per il Web all'utente.
Screen-reader
Il tema degli screen-reader è talmente importante per la comunità delle persone disabili che
spesso i primi test che si conducono su una pagina Web per giudicare la sua accessibilità sono
compiuti con strumenti di questo tipo.
Per questo ho deciso di dedicare una breve sezione riepilogativa su questi strumenti, la stesura
è basata sull’interessante articolo di Riccardo Franco 3 apparso su LAU (Laboratorio di
Accessibilità ed Usabilità) nel 2005.
1
2
3
Luca Mascaro: Seminario IWA, Arese, Maggio 2005.
WCAG 1.0: Glossario
[http://lau.csi.it/testare/accessibilita/test_user-agent/screen_reader/panoramica.shtml]
- 348 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Gli screen-reader erano tra gli strumenti per ipovedenti più diffusi anche prima della comparsa
dei sistemi operativi con interfaccia grafica.
Nelle loro prime versioni si sposavano perfettamente con l’interfaccia a caratteri del DOS ed
erano impiegati per fornire la traduzione in voce del contenuto dello schermo a caratteri.
Tra questi programmi di lettura schermo si ricordano: Parla, Filtro vocale, e Hal per DOS.
L'introduzione degli elementi grafici e soprattutto l’utilizzo del mouse hanno fatto nascere
nuovi problemi dal punto di vista degli screen-reader, ad esempio per impiegare i comandi da
tastiera per il puntamento con mouse o per leggere gli elementi non testuali.
Un’ottima soluzione alla questione fu il mouse da tastiera, un sistema che permette di simulare
l’uso del mouse tramite la tastiera, scorrendo e attivando gli elementi della pagina. Tale
soluzione è molto intuitiva e semplice, tanto che ancora oggi questa è quella standard degli
screen-reader.
Nel corso degli anni, con l’aumento di programmi, gli screen-reader hanno dovuto mantenersi
aggiornati, permettendo l’uso da tastiera dei principali applicativi.
L’elemento discriminante che ha reso alcuni screen-reader più usati di altri è stato proprio
l’aggiornamento ed il supporto di programmi. Inoltre una questione importante è anche il
supporto con display Braille.
Un accenno ai prodotti in commercio si trova nella sezione degli ausili informatici per disabili.
Ricordo quelli più importanti:
OutsSpoken (della Alva Access Group) e Hal (della Dolphin Systems).
Sono stati fra i primi screen-reader per interfaccia grafica, entrambi utilizzano il mouse
da tastiera, e nelle versioni successive hanno implementato l’uso dei display Braille;
Windots e Virgo, invece sono nati prima come display Braille, e poi hanno supportato la
sintesi vocale;
JAWS (Job Access With Speech) è attualmente il più diffuso screen-reader per Windows
in Italia, di esso parleremo nelle successive sezioni in dettaglio;
Window-Eyes, il più diffuso in america, è disponibile una versione in italiano;
Home Page Reader, limitato alla navigazione Web. Un prodotto molto valido di IBM ma
di minore diffusione proprio perché può essere utilizzato solo per navigare e leggere la
posta elettronica.
Gli screen-reader sono prodotti in genere molto costosi: tuttavia, esistono in rete delle versioni
dimostrative per provarne il funzionamento. Sono versioni che in genere funzionano per un
tempo limitato o riducono le funzionalità non consentendo l'uso dei display Braille.
Gli screen-reader che prenderemo in considerazione sono:
JAWS, nelle versioni 5.1 e 6 (di recente è in uscita la versione 8 in inglese);
Home Page Reader, versione 3.02 (attualmente è in commercio la versione 3.04);
Window Eyes, versione 5.0 (in italiano). (è appena uscita la versione 6).
- 349 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Sono, infatti, questi gli screen-reader più usati, così come quelli più aderenti alle prescrizioni
delle WCAG.
Oltre all’articolo già citato di Riccardo Franco ci sono in rete molti studi ed analisi comparative
sugli screen-reader tra cui quello di FucinaWeb1: "L'aderenza agli standard di screen-reader e
browser vocali", dove vengono confrontati JAWS e Window Eyes.
MSAA
Alla base di molti screen-reader ci sono le MSAA (Microsoft Active Accessibility) API, di cui ho
riportato qualche considerazione nella parte dedicata ai sistemi operativi.
Fondamentalmente Le MSAA API sono delle librerie di funzioni in grado di mettere a
disposizione delle applicazioni una serie di dati e proprietà del video. I lettori di schermo
possono accedere a queste informazioni ed interfacciarsi con esse.
Per usare le MSAA, è possibile utilizzare i controlli standard messi a disposizione dalla
Microsoft, oppure, usando un linguaggio di programmazione, interagire direttamente con le
API: in questo caso si parla di controlli non standard, che presentano lo svantaggio di non
essere attivabili direttamente da tastiera. Per ovviare allo svantaggio, JAWS ha introdotto un
linguaggio di scripting in modo da permettere l'utilizzo di quelle applicazioni che non hanno
una completa standardizzazione nei loro controlli.
Internet Explorer e Netscape Navigator vengono utilizzati molto bene dagli screen-reader, dato
che questi software si avvalgono delle funzionalità delle MSAA. Altri browser come Opera e
Firefox si sono mossi molto più lentamente su questo terreno e, di conseguenza, gli screenreaders non sono sempre loro adattabili. Fatto in parte dovuto alla scarsa interazione con le api
MSAA.
Tuttavia, recentemente, i passi per integrazione all’accessibilità anche di Firefox sono stati
notevoli al punto che attualmente il suo supporto per le MSAA è completo. 2
I browser testuali come Lynx si usano ottimamente con screen-readers che lavorano sotto DOS
oppure sotto la consolle di Linux. In tal caso basta utilizzare le frecce del computer per
muoversi tra i collegamenti ipertestuali della pagina; un invio attiva il collegamento e con il
tasto di tabulazione ci si può spostare fra i controlli della pagina stessa.
Il problema dei browser testuali è che, in quanto tali, non visualizzano gli elementi grafici di
una pagina Web.
1
[http://www.fucinaweb.com/fw/asstec]
Aaron Leventhal: “Currently, Firefox fully supports the Microsoft® Active Accessibility (MSAA) API”
[http://www-03.ibm.com/able/resources/firefox.html]
2
- 350 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
JAWS (Job Access With Speech)
Questo programma della Freedom Scientific nasce già come lettore di schermo per sistema
MS-DOS. JAWS è probabilmente il migliore screen-reader per quantità di funzionalità, ricco a
dismisura di comandi per l'accesso ai programmi e per la navigazione in rete.
JAWS è riuscito negli anni a mantenere invariati molti dei comandi fondamentali, in modo da
non disorientare gli utenti nel passaggio da una versione ad un'altra. Bisogna considerare, cosa
non da poco, che nell'azienda che produce questo programma, lavorano delle persone non
vedenti.
JAWS supporta un linguaggio di programmazione proprietario che permette di scrivere dei
programmi che interagiscono con le applicazioni più disparate. Sono stati realizzati script per
moltissime applicazioni, e questa caratteristica fa sì che JAWS sia tutt'ora lo screen-reader più
utilizzato, almeno per quanto riguarda Windows.
Per JAWS è possibile scaricare un dimostrativo dal sito. Il dimostrativo offre le funzionalità
vocali (non il Braille che richiede un apposito hardware decisamente costoso) per sessioni della
durata di 40 minuti, dopodichè è necessario riavviare il computer se si desidera continuare a
lavorare in JAWS.
Questa versione limitata però non ha attivata la sintesi vocale software e supporta pochissime
sintesi vocali hardware.
JAWS si comporta come un programma residente che gira in background sotto le altre
applicazioni e che legge in automatico molti degli eventi che avvengono sullo schermo o i tasti
digitati. Lo strumento imposta in partenza una modalità di lettura automatica. L'utente che
naviga con Internet Explorer ha comunque a disposizione una serie di comandi da tastiera che
gli consentono di esplorare lo schermo: purtroppo però, nel momento in cui si usano i comandi
da tastiera la lettura automatica viene interrotta e la lettura (manuale) riparte dall'inizio.
È stata più volte rilevata in rete (per esempio su Webaccessibile) la difficoltà di navigare con
JAWS abbinato a un browser diverso da Explorer, come per esempio le versioni di Firefox non
supportate da MSAA: infatti, per questo motivo, la maggior parte delle combinazioni di tasti
per la lettura agevolata della pagina non funziona.
In ogni modo la navigazione con JAWS in Firefox è ugualmente possibile anche se con modalità
più complesse.
Un interessante e completo articolo sull’utilizzo e la personalizzazione di JAWS è stato
pubblicato qualche mese fa sul sito di WebAccessibile1.
A questo rimando per le ulteriori specificazioni.
1
[http://www.webaccessibile.org/argomenti/argomento.asp?cat=611]
- 351 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Home Page Reader (HPR)
Home Page Reader (prodotto della IBM) è un browser Web con funzioni vocali. Per leggere il
contenuto delle pagine Web, Home Page Reader versione 3.0 usa un software di sintesi vocale
IBM, ViaVoiceOutloud.
HPR definisce alcune modalità principali di lettura, fra cui:
Modalità di lettura Elementi: la lettura avviene saltando da un elemento ad un altro: per
elementi si intendono paragrafi, intestazioni, liste, celle di tabelle, controlli (caselle di
testo, pulsanti di opzione, link mappe immagini). Si attiva con Alt+E. In questa
modalità, che è la predefinita da HPR, i tasti Freccia Sinistra/Giù/Destra leggono
rispettivamente gli elementi precedenti/correnti/successivi;
Modalità di lettura Parole: il contenuto viene letto parola per parola. Si attiva con Alt+P.
In questa modalità, i tasti Freccia Sinistra/Giù/Destra leggono rispettivamente le parola
precedenti/correnti/successive;
Modalità di lettura Caratteri: la lettura avviene lettera per lettera. Si attiva con Alt+C.
In questa modalità, i tasti Freccia Sinistra/Giù/Destra leggono rispettivamente la lettera
precedente/l'equivalente fonetico della lettera corrente/successiva;
Modalità di lettura Cursori di Windows: la lettura avviene lettera per lettera, riga per
riga, secondo le combinazioni di caratteri. Si attiva con Alt+W. In questa modalità, i
tasti Ctrl+Freccia Sinistra/Ctrl+Destra leggono rispettivamente la parola
precedente/successiva. I tasti freccia sinistra/destra leggono la lettera
precedente/successiva.
Window-Eyes
Window-Eyes funziona di default in una modalità di lettura per cursori.
Con le frecce destra e sinistra, vengono lette le singole lettere. Su Internet Explorer, con la
combinazione Ctrl+freccia destra/sinistra, vengono lette le parole seguenti/precedenti.
Parallelamente, Window-Eyes legge le parole su cui il mouse è posizionato; questa modalità
assomiglia a quella di JAWS denominata "cursore invisibile", attivabile col il testo meno del
tastierino numerico.
Molte pagine Web oggi sono occupate da grafici, immagini in movimento ed è difficile
esplorarle mediante uno screen-reader. Esse possono contenere molte colonne e molti frame e
tabelle.
L'uso del modo MSAA rende Internet Explorer più facile da gestire. Per attivare questo modo
bisogna portare in "attivo" le applicazioni MSAA nel menu "Generale" o premere il tasto caldo
CTRL-SHIFT-A quando Internet Explorer è attivo.
Quindi, se il modo MSAA è impostato su attivo, Window-Eyes riceve le informazioni
direttamente da Internet Explorer saltando la lettura delle informazioni sullo schermo.
- 352 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Questo consente al programma di presentare le informazioni in modo organizzato "come una
pagina di testo" facilmente consultabile con la sintesi vocale o la riga Braille. Fino a quando
rimane attiva questa modalità Window-Eyes lavora con un puntatore invisibile che emula un
cursore all'interno di un'area di memoria che contiene le informazioni presentate
contemporaneamente sullo schermo.
Quando il modo MSAA è attivo, Window-Eyes legge tutte le informazioni presenti sulla pagina
Web riga per riga direttamente dal formato (X)HTML.
Window-Eyes raccoglie le informazioni in ordine, ma deve attendere che Internet Explorer
concluda il caricamento della pagina stessa nella memoria del computer. A questo punto
Window-Eyes comunica con Internet Explorer per mezzo delle MSAA ed è in grado di prelevare
tutte le informazioni presenti sulla pagina Web.
Durante questa fase di caricamento l'intera pagina viene riformattata e posta in un'area
temporanea di memoria di Window-Eyes. In nessun caso ciò che è visualizzato sullo schermo
viene modificato.
Window-Eyes legge nell'area di memoria di Window-Eyes, ed in tal modo fornisce un completo
accesso alle informazioni presenti sul video.
Una volta che la pagina è stata completamente scaricata nel buffer di Window-Eyes e non si
sono dati comandi di lettura, Window-Eyes legge automaticamente 24 righe a partire dalla
posizione corrente.
Quando si legge una pagina Web e si incontra un collegamento ipertestuale, Window-Eyes
pronuncia "link" seguito dalla descrizione del collegamento. Se il collegamento in oggetto è
stato visitato in precedenza, Window-Eyes pronuncia "link visitato" seguito dalla descrizione
del link.
Questa è una funzione particolarmente utile per aiutare la navigazione sullo schermo evitando
di rivisitare pagine già controllate. Si può controllare il modo con cui Window-Eyes legge
queste informazioni e le altre proprietà legate all'utilizzo delle MSAA cambiando le impostazioni
delle MSAA nel menu globale prolissità MSAA.
V.3 - Strumenti di sviluppo
A monte delle relazioni esistenti tra i produttori dei contenuti Web e i fruitori, esiste una branca
importante della catena dell’accessibilità per i siti Web costituita dall’insieme degli ambienti di
sviluppo, cioè da quegli applicativi che permettono la realizzazione delle pagine.
Questo argomento è stato affrontato in linea teorica al momento di parlare delle ATAG
(Authoring Tools Accessibility Guidelines). In questa sede vorrei fare una breve panoramica
sulle capacità di questi strumenti, con una particolare attenzione a quelli più automatizzati
come i CMS (Content management system), sistemi di gestione dei contenuti, una categoria di
sistemi software per organizzare e facilitare la creazione di documenti e altri contenuti in un
ambito di collaborazioni di gruppo.
- 353 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
CMS
Tra i sistemi di sviluppo dei contenuti Web si è assistito recentemente al consistente sviluppo
di alcuni pacchetti integrati, denominati CMS, che consentono di gestire una grande quantità di
informazioni permettendone di gestirne le varie fasi di produzione e di divulgazione in gruppo.
I CMS, acronimo per Content Management System, sistema di trattamento dei contenuti, sono
degli applicativi software che trattano varie tipologie di contenuti e di documenti dando la
facoltà di gestirne:
La creazione guidata;
L’organizzazione;
La gestione collaborativa.
L’aspetto collaborativo e di interazione fra vari gruppi di editori è l’aspetto centrale di questi
sistemi.
Un CMS ben progettato è in grado di:
Gestire la conoscenza;
Permetterne una evoluzione collaborativa sotto opportuni criteri di controllo;
Permetterne una divulgazione pubblica in differenti contesti;
Gestire i flussi dei documenti.
Non sono degli strumenti che utilizzabili esclusivamente per il Web, ma sicuramente una loro
applicazione in internet o intranet può essere considerata il loro naturale campo di azione.
Internet o intranet si prestano infatti perfettamente come efficace strumento di supporto per la
divulgazione pubblica dei contenuti.
I CMS possono essere classificati in 3 classi di appartenenza a seconda della quantità e della
complessità di documentazione che gestiscono:
Enterprise CMS (ECMS).
Hanno il compito di una gestione completa del patrimonio informativo, il Web è solo un
aspetto parziale. Devono poter gestire qualunque tipologia di informazione,
organizzando i flussi di creazione e di modifica tenendo traccia di ogni variazione. Sono
anche in grado di fondere e separare i documenti, organizzare e relazionare contenuti
multi-lingua e multi-formato. Non sono necessariamente finalizzati al Web;
Web CMS (WCMS). Sono progettati per siti Web complessi o per piccoli sistemi di
gestione della conoscenza. Hanno delle strutture di template per la presentazione delle
informazioni e permettono un tracciamento delle modifiche meno sofisticato dei
precedenti. Non viene garantita la stessa integrazione dei documenti e la stessa
ricchezza delle versioni alternative.
- 354 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Piccoli. Progettati per piccolo siti Web. In genere possiedono un solo template e non
sono in grado di gestire versioni e flussi delle modifiche.
Impiego
Una delle migliori funzionalità di un CMS è quella di offrire un sistema integrato di creazione di
contenuti che garantisca risultati di buona qualità in maniera guidata.
L’aggiornamento dei siti Web delle pubbliche amministrazioni o di aziende che non hanno il loro
campo di interesse nell’informatica, è stato, specialmente in passato, affidato spesso a
professionisti specializzati a cui era delegato il compito di pubblicare i documenti forniti sul
Web.
In realtà questo sistema di sviluppare contenuti Web era piuttosto lento e macchinoso per via
dei tempi di interazione tra azienda ed editore, e della grossa mole di lavoro riversata su un
singolo editore di contenuti.
Senza contare che era spesso soggetto a numerosi errori di pubblicazione dal momento che
personale non esperto doveva trattare documentazione tecnica o amministrativa.
Un’alternativa era quella di trasferire la conoscenza necessaria per la pubblicazione
direttamente all’interno delle aziende che producevano i documenti. Tuttavia questo passaggio
non poteva essere fatto senza un enorme dispendio di tempo e risorse umane.
Il problema viene risolto brillantemente proprio dai CMS, che consentono una autonomia
interna delle aziende produttrici senza coinvolgerle in un eccessivo costo formativo e
garantendo, in aggiunta, una presentazione più omogenea e coordinata dei contenuti
pubblicati.
Grazie alla supervisione di uno o più esperti interni, i cosiddetti content manager, autorizzati
dal gestore del sistema, l’attività di produzione può essere organizzata completamente
all’interno dell’azienda. Costoro, accedendo alla propria area di gestione del sito possono
organizzare i contenuti e le presentazioni di propria competenza. Sarà poi compito del CMS
manipolare correttamente i contenuti specifici inseriti da ogni singolo operatore in relazione
alle direttive fornite dal gestore di contenuti per produrre dei documenti accessibili e coerenti.
Nel suo testo sull’accessibilità Roberto Scano1 ha riassunto i principali benefici nell'uso dei
sistemi CMS in un’organizzazione come quella sopra esposta:
1
Autonomia gestionale dei contenuti;
Immediatezza della gestione e pubblicazione dei contenuti;
Roberto Scano: ”Accessibilità: dalla teoria alla realtà”
- 355 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Miglior gestione dell'immagine aziendale;
Facilità nella ricerca di contenuti all'interno del sito Web;
Possibilità di gestire comunicazioni periodiche con gli utenti;
Minori costi per contratti di manutenzione dei contenuti.
La facilità e l’autonomia d’uso è garantita da una interfaccia operativa verso l’utente di tipo
WYSIWYG (What You See Is What You Get) cioè: quello che si vede è quello che si ottiene. Un
sistema di editor visuale molto vicino ad un Word Processor di qualità.
Questo permette anche ad un’utenza poco esperta di produrre contenuti impaginati e coerenti
secondo le impostazioni definite dal content manager e di ottenerli in maniera accessibile, cosa
garantita dalla produzione di codice (X)HTML interna del CMS.
Problematiche
I CMS, così come definiti, sono ovviamente degli strumenti di sviluppo di pagine Web. Come
tali ricadono nella categoria degli Authoring Tools come definito dal W3C, sono soggetti alle
ATAG e ne devono rispettare le normative, sia per quanto riguarda la loro accessibilità
intrinseca che per quanto riguarda l’accessibilità dei contenuti che producono.
In oltre, gli operatori, per gestire i contenuti, ricorrono spesso ad un’interfaccia internet o
intranet, i cui contenuti sono soggetti anche alle regole delle WCAG.
Tutto questo rende estremamente difficoltoso produrre un CMS che sia realmente accessibile
sotto tutto gli aspetti.
I problemi di accessibilità dei CMS possono essere raggruppati nelle seguenti categorie:
Accessibilità dell’area di gestione (backoffice);
Accessibilità dell'editor;
Accessibilità dei contenuti generati dal CMS.
Nel seminario1 IWA di Arese, Luca Mascaro ha sottolineato come, nel 2005, la situazione fosse
ancora una “catastrofe totale”. Se, infatti, da un punto di vista dell’accessibilità dei contenuti il
risultato poteva essere ottenuto con una relativa facilità, dal punto di vista dell’ambiente
complessivo lo sviluppo era molto indietro, al punto che se un’amministrazione pubblica avesse
dovuto fare un bando di concorso sarebbe stata obbligata a spendere delle cifre davvero
ingenti per acquistare a caro prezzo i pochi CMS di fascia alta realmente accessibili presenti sul
mercato.
1
Arese Maggio 2005: Roberto Ellero, Luca Mascaro: seminario, dal titolo: "Legge Stanca: dalla teoria alla
realtà. Analisi delle disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici”
- 356 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Area di gestione (backoffice)
Per backoffice dei CMS si intende l’area di gestione dei contenuti del sito alla quale accedono i
singoli content manager per amministrare le informazioni di propria competenza.
Il backoffice è, in pratica, un’area riservata all’interno di un sito internet o intranet dove un
utente autorizzato può organizzare le funzionalità operando in un ambiente conosciuto come
ad esempio il proprio normale browser.
Vengono trattate le modifiche sui contenuti stessi, sui permessi, sulla strutturazione e sulla
relazione fra le informazioni, sulla impaginazione e sulle configurazioni, in generale su tutte le
personalizzazioni consentite dal CMS a seconda del livello di autorizzazione consentito
all’utente allocato.
L’accesso viene infatti autorizzato fornendo delle credenziali. Gli amministratori potranno
accedere a tute le sezioni mentre profili più limitati avranno a disposizione solamente un
sottoinsieme ristretto delle funzionalità e dei dati.
Di fatto, essendo quest’area gestionale un vero e proprio insieme di pagine Web, deve
rispettare le WCAG fornendo versioni accessibili dei contenuti disponibili.
Ad esempio il progettista del CMS deve prestare attenzione:
Ad un eventuale sviluppo dell’interfaccia su frame;
All’impiego di moduli (form) che non siano correttamente etichettati, raggruppati ed
accessibili. A questo proposito va tenuto in debito conto anche il fatto che il modulo
d’identificazione per operatore deve essere accessibile;
Ad implementare un corretto sistema di orientamento e navigazione;
Ad implementare un corretto sistema di archiviazione e pubblicazione dei contenuti che
possa essere utilizzato anche dalle persone disabili;
All’utilizzo di un linguaggio chiaro e semplice per la presentazione e le informazioni
sull’uso dell’interfaccia.
Ad esempio, allo stato attuale delle cose la maggior parte dei CMS impiega spesso delle
strutture a frame per offrire dei menu di navigazione, e questa scelta risulta una barriera molto
difficile per gli autori non vedenti.
Un interessante strumento messo spesso a disposizione è quello delle procedure guidate
(wizard), che permettono di ottenere un risultato raccogliendo informazioni passo dopo passo.
Se un CMS implementasse questa tecnica, i singoli moduli di procedura guidata dovrebbero
contenere:
Posizione attuale (ad esempio passo 1 di 4);
Scopo del modulo attuale con brevi spiegazioni sulla funzionalità;
Barra di navigazione per tornare al passo precedente, uscire, saltare al successivo.
- 357 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Editor
Come accennato in precedenza l’editor presentato ai creatori dei contenuti deve essere
generalmente di tipo WYSIWYG dal momento che deve essere utilizzato da personale anche
non necessariamente competente in materia di pubblicazione di contenuti.
Può essere di due tipi:
Proprietario, integrato nel CMS. Garantisce una migliore integrazione con il sistema;
Esterno e collegato con un plug-in. Offre la possibilità di lavorare con uno strumento già
conosciuto dall’utente.
In entrambe i casi ci sono dei problemi comuni di importanza chiave:
Si richiede che il codice prodotto sia valido secondo le specifiche (X)HTML. Editor
integrati e soprattutto editor esterni inappropriati spesso non sono stati progettati
specificatamente per (X)HTML e a volte non generano codice corretto secondo le
grammatiche formali del W3C;
Si richiede che il contenuto prodotto sia conforme alle WCAG. Per quanto nessun editor
possa, ovviamente, garantire che il contenuto finale sia pienamente accessibile,
tuttavia, è possibile progettarlo in maniera che possa guidare l’editore nella creazione di
contenuti migliori ad esempio obbligando all’inserimento dell’attributo ALT;
Si richiede che la stessa interfaccia dell’editor sia accessibile e compatibile con le
tecnologie assistive. Un modo per ottenere questo è garantire che sia pienamente
operabile via tastiera.
Questi ultimi due punti sono quelli previsti espressamente nelle ATAG che si propongono
proprio di far conseguire questi risultati agli strumenti di sviluppo.
In effetti, questa è una delle sezioni più critiche di un CMS.
Contenuti generati
Come appena accennato il prodotto finale dell’editor deve essere accessibile.
Le ATAG contengono una serie di direttive utili a proposito per fare in modo che lo strumento
di sviluppo possa fungere da guida alla produzione di contenuti accessibili. Questo riguarda non
solo la generazione di un codice efficiente e funzionale, ma che contenga anche tutti i
necessari supporti per una corretta fruibilità, in particolare:
Validità formale del documento nel codice (X)HMTL e CSS;
Strutturazione logica del documento;
Gestione di pagine multi-lingua per i CMS multi-lingua;
Produzione di pagine facilmente navigabili che evitino ad esempio lunghi elenchi di
collegamento generati magari in automatico;
- 358 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Inserimento nella pagina di sistemi di navigazione ed orientamento che possono essere
inseriti in maniera semiautomatica nel codice finale dal CMS con relativa facilità;
Interazione chiara con l’utente, ad esempio fornendo un motore di ricerca interno del
sito.
A questo proposto va ricordato che la bontà di un CMS consiste anche nel permettere ad un
autore di contenuti che sia inesperto in materia di scrittura di codice (X)HTML e CSS di
produrre dei risultati di qualità in maniera più automatica possibile, senza essere per altro
limitato nelle sue capacità espressive.
Conclusioni
Come già accennato, la vastità del problema e delle considerazioni che vanno fatte per
produrre un CMS pienamente accessibile ha reso molto ridotti i ranghi di prodotti di qualità.
I CMS erano in commercio ed erano anche piuttosto diffusi anche prima delle attenzioni che
vengono oggi poste nei riguardi del problema dell’accessibilità. Questo per il merito della
notevole organizzazione del lavoro che possono offrire.
Con l’avvento delle WCAG e della normativa italiana si è assistito ad un notevole miglioramento
della loro qualità ed anche i grossi produttori come Microsoft stanno aggiornano le loro
soluzioni in materia.
L’abbattimento dei costi gestionali e l’alto grado di produttività che possono consentire anche
ad un utente mediamente preparato, ne fanno uno degli applicativi potenzialmente più efficace
nella progettazione di siti Web aziendali.
Occorre far presente però che non sono assolutamente in grado di entrare nel merito dei
singoli contenuti. Per quanto sia possibile aiutare il progettista nello sviluppo di un sito
strutturalmente corretto, la qualità delle informazioni pubblicate ed il controllo su di esse resta
ad esclusivo appannaggio di un supervisore umano. Anche a questo proposito i CMS possono
essere particolarmente efficaci, organizzando la catena produttiva di ogni singolo documento e
consentendone la pubblicazione solo dopo il passaggio obbligato attraverso la verifica ultima di
un responsabile.
Chiudo questa breve panoramica sui CMS segnalando la recente distribuzione di un prodotto
open-source, conforme alla legge Stanca ed a buona parte delle WCAG. Si tratta di Fruibile1, il
cui progetto è coordinato da Roberto Scano e Luca Mascaro.
1
[http://www.fruibile.it/]
- 359 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
V.4 - L’accessibilità nei sistemi operativi
Può essere istruttivo presentare una panoramica generale dello sviluppo e dell’attenzione
riguardo all’accessibilità anche a livello dei sistemi operativi.
In effetti, è proprio il sistema operativo che dovrebbe essere la base da dove partire per
ottenere una completa accessibilità delle informazioni 1 dal momento che è precisamente
quest’ultimo a fornire la piattaforma software sulla quale poi girano tutti i programmi utente.
I sistemi operativi più datati, come il DOS e Unix nei suoi primi ambienti erano solo testo e
ponevano poche barriere di accessibilità alle tecnologie assistive che potevano adattarvisi con
relativa semplicità. Anche per questo erano scarsamente dotati di accorgimenti interni.
Le difficoltà sono cresciute notevolmente con l’avvento della grafica e del mouse, strumenti
che non sono immediatamente riconducibili alle tecnologie assistive.
Attualmente i sistemi operativi più diffusi sono Windows, MAC OS, Unix e derivati (Linux).
Per questi ultimi esiste ancora una forte tradizione di ambiente a riga di comandi, e le
tecnologie assistive che supportino questo tipo d’interfaccia possono ancora validamente
adattarvisi. Tuttavia anche per Linux sono presenti un gran numero di ambienti grafici.
Una regola dei sistemi operativi grafici è quella di fornire un’interfaccia di programmazione per
le applicazioni (API) in modo che possano essere scritte delle applicazioni congruenti con le
funzionalità del sistema operativo. Le API forniscono un insieme di blocchi funzionali
precostituiti che i programmatori assemblano nelle loro applicazioni. Da questo punto di vista è
fondamentale che le API forniscano il supporto per l’accessibilità.
Ad esempio: tutti i menu ed i controlli in un’interfaccia grafica dovrebbero essere accessibili via
tastiera, non solo tramite mouse, e dovrebbero essere visualizzati con un insieme di caratteri
ed uno schema di colore facilmente personalizzabile dall’utente. Finché le API garantiranno il
supporto per queste ed altri aspetti dell’accessibilità le applicazioni che gireranno in questi
ambienti possono essere facilmente rese accessibili dagli sviluppatori.
Attualmente esistono significative differenze nell’accessibilità delle API nei vari sistemi
operativi. Microsoft si è occupata di molti dei problemi di accessibilità delle API di Windows e
ha consentito agli sviluppatori di produrre delle applicazioni accessibili. Molte delle applicazioni
in Windows, per esempio, sono completamente gestibili via tastiera.
Altri sistemi operativi di tipo grafico non sono stati così solleciti nel fornire un’accessibilità
paragonabile. Gli sforzi precoci di Microsoft per supportare l’accessibilità, in combinazione con
1
“The more and more I think about accessibility, the more I feel that the burden of accommodating the
minorities who have low vision, are color blind, or just have a simple person predilection towards having text
really damn big should fall on the operating system and browser makers, not web designers.” –
[http://www2.jeffcroft.com/blog/2006/aug/21/has-accessibility-been-taken-too-far]
- 360 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
la posizione di predominanza sul mercato, hanno portato ad uno sproporzionato sviluppo di
tecnologia assistiva concepita specificatamente per il mondo Windows.
Alcune caratteristiche di accessibilità sono implementate negli stessi sistemi operativi, ma
tipicamente queste applicazioni interne possono garantire solo un livello minimo di
accessibilità, sicuramente non il livello completo di cui molti utenti hanno bisogno per ottenere
un accesso completo al sistema operativo e alle sue applicazioni.
In genere sono disponibili alcune caratteristiche comuni a tutti i sistemi:
Personalizzazione della tastiera.
Viene consentito agli utenti di impostarsi il comportamento in modo che possano:
o
Premere un tasto per volta per le combinazioni multi-tasto;
o
Utilizzare la tastiera per controllare il mouse;
o
Cambiare l’intervallo di tempo per la rilevazione della pressione di un tasto;
Personalizzazione del video.
Viene consentito di modificare il contrasto, il tipo e la dimensione del carattere, la
dimensione delle icone, la risoluzione del video ed altre caratteristiche;
Messaggi di sistema.
Sono emessi messaggi di sistema visivi per chi non può udire i suoni.
In aggiunta a queste caratteristiche base, Windows e MAC OS includono ingranditori di
schermo e screen-reader, per quanto siano molto elementari. Linux differisce dagli altri due
per il fatto che sia un progetto open-source ed il suo supporto viene portato avanti da una
comunità di sviluppatori. La comunità di sviluppo di Linux ha prodotto un insieme base di
funzionalità per l’accessibilità consistente in un ingranditore di schermo integrato con uno
screen-reader, un software per la gestione delle barre Braille e una tastiera su schermo. Tutte
queste caratteristiche sono state sviluppate per il desktop GNOME, un’interfaccia grafica che
lavora sia sotto Unix sia Linux.
Vediamo adesso una panoramica più specifica per i sistemi operativi. Data la complessità della
materia queste poche righe saranno solamente un accenno, per dare un quadro alla materia,
destinato tra l’altro ad essere integrato in breve tempo dallo sviluppo software, soprattutto nel
mondo open-source.
Per diffusione ed importanza il centro del discorso sarà la trattazione dell’accessibilità in
Windows.
Microsoft Windows
L'ambiente operativo su cui un disabile opera solitamente è Microsoft Windows in quanto
Microsoft già dalla versione 2.0 di Windows ha iniziato ad implementare caratteristiche di
accessibilità del proprio sistema, sino a giungere ad un primo nucleo di MSAA (Microsoft Active
Accessibility) e alle opzioni di accesso facilitato già con Windows 95. Sul sito della Microsoft è
- 361 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
presente un’utile tabella riepilogativa1 che riporta lo sviluppo e le caratteristiche di accessibilità
proprie dei sistemi Microsoft.
Con il nascere di Microsoft Windows 95, sono state realizzate, dalla Microsoft, delle librerie
di funzioni in grado di mettere a disposizione delle applicazioni una serie di dati e proprietà.
Tali librerie sono le Microsoft Active Accessibility Application Program Interface (MSAA API),
che creano, all'interno del sistema operativo, delle classi pubbliche di oggetti. Tali classi sono
in grado di fornire ai programmi per le tecnologie assistive, tutte le informazioni necessarie sui
controlli appartenenti ad una finestra, sugli elementi che fanno parte di questi controlli, sui
menu ed anche sul codice HTML che viene caricato nei browser.2
I lettori di schermo possono accedere a queste informazioni ed interfacciarsi con esse, anche
modificandole, trasformare in testo i loro valori; in tal modo gli utenti possono reperire tutte le
funzionalità che gli applicativi mettono loro a disposizione.
Le applicazioni sviluppate per tale ambiente operativo sono sicuramente più accessibili rispetto
ad altri sistemi considerando che le tecnologie assistive (soprattutto i lettori di schermo)
utilizzano le API dell'ambiente operativo per ottenere informazioni sugli oggetti e sui contenuti
testuali.
Occorre inoltre segnalare un altro aspetto spesso sottovalutato ma importante per
l’accessibilità di Microsoft Windows, questo sistema operativo possiede alcune facilitazioni di
accesso native che hanno incominciato ad affermarsi fin dalle prime versioni di Windows 95.
Queste integrazioni sono ripartite in diverse sezioni:
Scheda Accesso facilitato dal pannello di controllo;
Scheda Aspetto della finestra Proprietà dello schermo di Windows;
Menù Avvio, tutti i programmi, accessori, accesso facilitato;
Impostazioni specifiche dal pannello di controllo.
Vediamo adesso un breve elenco di alcune di queste funzionalità che possono essere
direttamente verificate sul proprio sistema operativo, visto che sono immediatamente
disponibili senza bisogno di installazioni separate. Nel caso che non fossero disponibili è
possibile integrarle con disco di installazione di Windows.
Un utile testo di riferimento3 a proposito di queste funzionalità è stato predisposto dalla stessa
Microsoft ed è facilmente reperibile in rete.
1
2
3
[http://www.microsoft.com/enable/products/chartwindows.aspx]
[http://lau.csi.it/testare/accessibilita/test_user-agent/screen_reader/panoramica.shtml]
“Step by Step Tutorials for Microsoft Windows XP Accessibility Options”
- 362 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Opzioni di accesso facilitato
La scheda per le opzioni di accesso facilitato è attivabile dal pannello di controllo. La dizione
italiana accesso facilitato è l’impropria traduzione dalla versione inglese che recita Accessibilty
Options. Le funzionalità sono ovviamente le stesse per ambedue le lingue.
Le opzioni per l’accesso facilitato sono organizzate in 5 sezioni differenti:
Tastiera:
o
Tasti permanenti (sticky keys): Molti software richiedono che siano premuti due
o tre tasti contemporaneamente. Per alcune persone che scrivono utilizzando un
solo dito o una cannuccia questo non è possibile. I tasti permanenti consentono
di premere un tasto per volta e istruire Windows a rispondere come se i tasti
fossero stati premuti contemporaneamente.
I tasti di modifica sono ALT, SHIFT e CTRL, ed esistono diverse opzioni nella scheda
tastiera per la loro gestione, tra cui la possibilità di attivare o disattivare le
impostazioni permanenti anche senza passare da questa scheda o il fatto di
emettere un suono alla loro pressione e di mostrare il loro stato sulla barra di
stato;
o
Filtro tasti (filter keys): Alcune persone possono incontrare delle difficoltà nel
trovare e premere i tasti corretti o nel mantenerli premuti per un tempo
sufficientemente lungo, con il rischio di andare incontro ad errori di tastiera.
Questa opzione permette di andare incontro ai problemi di risposta della
tastiera, in particolare permette di ignorare i tasti premuti troppo rapidamente
regolando anche la velocità, il ritardo e l’accelerazione di ripetizione. Anche in
questo caso è possibile mostrare lo stato come un cronografo sulla barra di stato
o emettere un segnale acustico in corrispondenza alla pressione ripetuta di un
tasto;
o
Segnali acustici: permette di associare dei segnali acustici alla pressione del
blocco delle maiuscole, del blocco del tastierino numerico e del blocco della
funzione di scorrimento;
Audio: Spesso il sistema operativo informa gli utenti degli eventi o dei problemi del
sistema attraverso dei suoni piuttosto che attraverso dei messaggi visivi.
Questa è stata una funzionalità piuttosto comune dei sistemi operativi fin dal loro
avvento. Sebbene questi messaggi audio tendano a non essere critici se usati da soli,
tuttavia potrebbero essere sicuramente utili, e non udirli potrebbe creare dei problemi
agli utenti che non sono in grado di percepirli.
Ci sono 2 elementi nelle opzioni dell’accesso facilitato per le persone che hanno
difficoltà nell’udire gli avvertimenti audio dal computer. Vale la pena far notare che
entrambe i sistemi possono solamente intercettare e visualizzare l’altoparlante interno
- 363 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
del computer, i suoni che siano prodotti da una scheda audio a parte non possono
essere rimappati con segnali visivi:
o
Mostra messaggi (show sounds), che permette di visualizzare le didascalie
associate ai segnali acustici generati dalle applicazioni;
o
Usa segnali visivi (sound sentry) che permette di generare una serie di segnali
visivi in aggiunta al segnale acustico emesso dal sistema.
In questo caso un menu a discesa permette di selezionare come si preferisce che
gli avvertimenti siano visualizzati. In genere è possibile impiegare il
lampeggiamento intermittente della barra del titolo, della finestra attiva o del
desktop;
Schermo: Questa caratteristica consente di cambiare rapidamente e facilmente le
proprietà dello schermo impostando uno schema predefinito. La pressione simultanea di
ALT, SHIFT
di sinistra e PRINT SCREEN permette di attivare direttamente il contrasto elevato
previa conferma. Anche in questo caso è possibile impostare in precedenza i tasti
permanenti in modo da simulare questa pressione contemporanea con l’uso di ausili
come cannucce, puntatori a movimento del capo o pressione di un singolo tasto
contemporaneamente.
E’ possibile selezionare la tipologia di contrasto elevato che si desidera selezionare per il
proprio sistema. In un menù a discesa sono mostrate gli schemi disponibili per Windows
oltre a quelli che sono stati personalizzati direttamente dall’utente. Ogni schema ha, in
genere, anche 2 o 3 differenti possibilità di scelta per le dimensioni.
Questa opzione può essere anche configurata parzialmente dalla scheda aspetto delle
proprietà dello schermo come indicato a parte.
Mouse: Questa scheda permette di controllare il puntatore del mouse attraverso la
tastiera. Per quanto Windows sia stato progettato per consentire agli utenti di interagire
con il sistema anche senza l’utilizzo del mouse, tuttavia qualche programma potrebbe
comunque richiederlo, oppure il puntatore del mouse potrebbe essere molto più pratico
e funzionale in certe circostanze.
Il controllo del puntatore può essere attivato sia da questa scheda sia da tastiera con la
pressione contemporanea dei tasti di sinistra di ALT, SHIFT e NUM LOCK. Da ricordare che
esiste la possibilità per i disabili di attivare i tasti permanenti, istruendo Windows a
gestire in sequenza la pressione altrimenti contemporanea di questa combinazione.
Una volta attivato il controllo del puntatore del mouse, è possibile utilizzare le frecce del
tastierino numerico per spostare il mouse nella direzione indicata dal tasto. Il tasto 5
può essere impiegato per simulare il click singolo del mouse, mentre il doppio click è
simulato dal tasto +.
Esiste anche la possibilità di simulare i drag and drop con i tasti INS e DEL mentre CTRL e
SHIFT
- 364 -
permettono spostamenti macroscopici o microscopici sul video. Queste
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
funzionalità possono essere utili anche ad utenti normodotati che desiderino, per
esempio, attuare degli spostamenti pixel per pixel del mouse in cooperazione con i
normali movimenti.
Generale: Nella scheda delle impostazioni generali si può configurare il comportamento
delle opzioni di accesso facilitato. Questa funzionalità risulta particolarmente utile nel
caso in cui più di un utente abbia accesso al computer. Nel caso, ad esempio, che siano
state rallentate le immissioni da tastiera, un utente che non ne richieda l’impiego può
erroneamente ritenere che si sia verificato un errore e che il sistema sia in crash.
Per questo motivo è disponibile una cancellazione automatica delle funzionalità, se non
utilizzate per un certo limite di tempo. E’ anche possibile rendere noto all’utente con un
messaggio o con un segnale acustico quando venga attivata o disattivata una delle
funzionalità descritte in precedenza. In questo modo è possibile tenere informato
l’utente su come si stia comportando il sistema e di come reagisca.
Le opzioni di amministrazione permettono di decidere se le impostazioni vadano
richiamate in automatico dalla partenza o se possano venire trasferite in automatico ad
un nuovo utente al momento della sua creazione.
Un’ulteriore importante funzionalità è quella dell’impiego di una periferica alternativa.
Molti utenti utilizzano un’apparecchiatura di aiuto alla comunicazione ed altri ausili a
parte che possono interagire con il computer attraverso una porta di comunicazione.
Impostando la porta per la periferica alternativa è possibile creare un collegamento tra
le due apparecchiature in modo che il dispositivo esterno possa operare in maniera
simile alla tastiera standard.
Come fatto notare in alcune voci, tutte queste configurazioni sono impostabili direttamente con
delle scorciatoie via tastiera, in modo che gli utenti disabili non siano costretti ad aprire il
pannello per impostare il controllo.
Scheda aspetto delle proprietà dello schermo
In questa finestra e possibile impostare alcune configurazioni che riguardano le proprietà con
cui sarà mostrato lo schermo.
In particolare:
E’ possibile selezionare e creare una combinazione di visualizzazione in modo da avere
una presentazione a schermo il più possibile aderente alle necessità percettive
dell’utente, configurando sfondi delle finestre, proprietà del testo, dimensioni delle
barre, dei menù, delle icone ed altro.
In assenza di specifiche indicazioni a livello di applicazione, il sistema operativo
utilizzerà queste combinazioni nelle visualizzazioni degli applicativi.
In particolar modo anche il browser può ereditare queste impostazioni di preferenza,
- 365 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
oppure possono essere gli stessi autori di fogli di stile a richiamare volutamente le
impostazioni del sistema operativo sfruttando delle costanti che fanno esplicito
riferimento alle costanti di sistema.
Anche il progettista di uno specifico programma applicativo può vantaggiosamente
riferirsi a questi valori. Quasi sempre, in fase di sviluppo, gli attributi e le proprietà
grafiche degli oggetti come caselle di testo, pulsanti, etichette, sfondi delle finestre ed
altro, possono essere mantenute personalizzate impostando il valore di sistema
predefinito. Se non si specifica alcun valore personalizzato, la visualizzazione
dell'elemento avviene in base ai valori impostati nella combinazione di visualizzazione
selezionata nella scheda Aspetto nella finestra Proprietà dello schermo.
Questo meccanismo influenza anche la visualizzazione delle pagine Web. Ciò significa
che in assenza di indicazioni specifiche, le pagine saranno visualizzate secondo i
parametri standard utilizzati dal computer del navigatore;
E’ possibile allargare le icone sullo schermo in modo da rendere più facile il loro
accesso. La scelta è possibile da un pulsante di controllo dalle opzioni effetti;
E’ possibile utilizzare la tastiera per selezionare le voci di un menù o le opzioni di una
finestra di dialogo, questo premendo il tasto che corrisponde alla lettera sottolineata
simultaneamente ad una combinazione con ALT. E’ possibile scegliere di nascondere la
lettera sottolineata per la navigazione da tastiera fin quando non venga premuto il tasto
che le abilita.
Al di fuori di questo menù si ricorda che è anche possibile venire incontro alle esigenze
peculiari degli utenti modificando la risoluzione dello schermo per aumentare la leggibilità dei
documenti a video. Una risoluzione minore può agevolare le persone ipovedenti.
Accessori, accesso facilitato
Un menù di accesso facilitato è stato predisposto anche all’interno degli accessori nell’elenco
dei programmi di sistema.
Questo menu contiene diverse voci:
Impostazione guidata: è possibile invocare questo strumento per permettere agli utenti
inesperti di configurare facilmente ed in un solo momento tutti i gruppi delle opzioni di
accessibilità che li riguardano.
L’impostazione guidata pone delle domande sui bisogni dell’utente e configura il sistema
in base alle risposte. Nel caso può essere rilanciata più volte per reimpostare i valori.
Durante l’uso della configurazione guidata viene data la possibilità di variare la
dimensione dei font e delle schermate in modo da poter venire incontro alle esigenze
degli utenti ipovedenti.
La guida prevede delle configurazioni passo dopo passo che permettono di:
- 366 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
o
Impostare le opzioni per i non vedenti o per le persone che abbiano difficoltà a
vedere gli oggetti sullo schermo;
o
Impostare le opzioni per i non udenti o che abbiano difficoltà ad ascoltare i suoni
dal computer;
o
Impostare le opzioni per coloro che abbiano difficoltà ad operare con il mouse o
con la tastiera;
o
Disabilitare i menù personalizzati;
Utility Manager: consente agli utenti di controllare lo stato degli applicativi
sull’accessibilità o di arrestarli ed avviarli.
E’ possibile impostare i valori in modo da predisporre che ogni singolo applicativo venga
avviato automaticamente in momenti definiti come l’allocazione dell’utente, il blocco
della macchina o l’avvio dello stesso utility manager.
I programmi per l’accessibilità sono:
o
Tastiera su schermo;
o
Narratore;
o
Ingranditore;
Tastiera sullo schermo: si tratta di un programma di utilità che mostra una tastiera
virtuale sullo schermo del computer. Questa consente agli utenti con disabilità motorie
di digitare i dati usando un dispositivo di puntamento come ad esempio un joystick.
Sono possibili un gran numero di opzioni per la configurazione di questo applicativo, tra
cui dimensioni, font e posizionamento della tastiera.
Particolarmente utile per disabili motori è il cosiddetto scanning mode, modalità in cui la
tastiera scorre ed evidenzia la zona dove si possono digitare i caratteri utilizzando un
sistema di ingresso da una porta di comunicazione;
Narratore: si tratta di un’utilità TTS (Text To Speech) per persone non vedenti o per
ipovedenti. Il narratore legge quanto mostrato sullo schermo, come ad esempio il
contenuto della finestra attiva, il menu delle opzioni, o il testo che viene digitato.
Il narratore è stato progettato per lavorare con notepad, wordpad, i programmi del
pannello di controllo, Intenet Explorer, la scrivania di Windows e alcune delle parti del
programma di installazione di Windows. In altri programmi potrebbe non essere in
grado di leggere il testo.
Ovviamente sono possibili delle configurazioni come ad esempio il volume della voce, la
selezione dei testi da leggere, la possibilità di rendere noti gli eventi che appaiano sullo
schermo o i caratteri che vengono digitati.
Tra le limitazioni di questo strumento c’è quella che è stata predisposta solo la versione
in inglese;
Ingranditore (Magnifier): si tratta di un’utilità a video che rende lo schermo del
computer più leggibile per gli ipovedenti creando una finestra separata dove viene
- 367 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
mostrata una porzione ingrandita dello schermo stesso.
Tra le funzionalità possibili, si ricordano quelle di cambiare dimensioni e posizione della
finestra ingrandente, invertire i colori dello schermo, usare un contrasto elevato e
seguire la tracciatura del mouse o il focus della tastiera.
Come specificato all’interno degli stessi applicativi di base, questi strumenti hanno lo scopo di
fornire una funzionalità minima di accesso per utenti con esigenze particolari. La maggior
parte di loro avrà bisogno, per un’operatività efficiente, di programmi di utilità più avanzati di
questi.
Impostazioni specifiche dal pannello di controllo
Dal pannello di controllo esistono poi diverse possibilità di configurazione dei dispositivi in
modo che possano venire incontro alle esigenze degli utenti affetti da disabilità.
Molte di queste configurazioni possono tornare utili anche nel normale impiego del sistema
operativo:
Impostazioni del mouse (tempo di risposta, velocità di spostamento e di doppio click,
inversione dei bottoni, metodo di drag and drop, disegno dei puntatori, tracciatura);
Impostazioni di tastiera (ripetizione dei tasti, ritardo di ripetizione, frequenza di
lampeggiamento del cursore, tastiere speciali Dvorak);
Impostazioni della sintesi e riconoscimento vocale (velocità del parlatore e collegamento
con il dispositivo audio).
MSAA
Le tecnologie assistive, allo scopo di consentire all’utente di accedere alle informazioni
significative dell’interfaccia utente, devono essere in grado di accedere loro stesse a
quell’informazione.
Come accennato, la soluzione di Microsoft a questo problema sono le MSAA (Microsoft Active
Accessibility) che sono disponibili come un pacchetto aggiuntivo fin dal sistema operativo
Windows 95 e sono implementate internamente in tutti gli altri sistemi operativi successivi.
MSAA è una tecnologia che fornisce un meccanismo standard e consistente per scambiare
informazioni tra gli applicativi e le tecnologie assistive.
A titolo d’esempio MSAA permette alle applicazioni di esporre agli screen-reader il tipo, il
nome, la posizione e lo stato di tutti gli oggetti oltre a notificare qualsiasi evento che porta ad
un cambiamento dell’interfaccia.
Per quanto questo non sia il solo modo per un applicativo di comunicare con la tecnologia
assistiva, tuttavia MSAA consente agli sviluppatori di queste tecnologie di supportare una vasta
gamma di applicativi senza doversi occupare della programmazione una per una.
- 368 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Il numero degli applicativi che supportano MSAA è in crescita, per quanto vi siano in
commercio molti applicativi che non lo facciano.
Microsoft ha sviluppato un pacchetto di strumenti che permettono agli utenti di controllare le
informazioni che MSAA espone. Per quanto questi strumenti siano stati progettati per gli
sviluppatori, potrebbero comunque essere di altrettanto interesse anche per i tecnici o per gli
utenti più esperti.
Il pacchetto, chiamato Microsoft Active Accessibility 2.0 Software Development Kit Tools, può
essere direttamente scaricato da Microsoft1 ed include 3 programmi:
Accessible Event Watcher;
Accessible Explorer;
Inspect Objects.
Informazioni sull’architettura e sull’utilizzo di queste interfacce di sistema possono essere
reperite direttamente sul sito della Microsoft2.
Alcuni dei più importanti pacchetti applicativi in commercio per tecnologie assistive fanno
riferimento alla compatibilità con MSAA per garantire l’accessibilità, fra i tanti vale la pena
ricordare sicuramente JAWS, Windows Eyes e Adobe Flash.
Linux
Il sistema operativo Linux ha notevolmente accresciuto la sua popolarità nel giro di questi
ultimi anni diffondendosi sia nelle versioni server che nelle versioni per uso personale.
Il motivo di questa diffusione è probabilmente la politica della sua libera distribuzione, lo
sviluppo open-source e il fatto che sia disponibile per un gran numero di piattaforme hardware.
Già da molti anni sono disponibili un buon numero di risorse per l’accessibilità per questo
sistema, ma molte di queste sono state studiate per interfacciarsi solamente con l’ambiente a
comandi, in una modalità simile a quella della riga di comando del DOS.
Fino poco tempo fa l’interfaccia grafica è rimasta, in sostanza, inaccessibile agli utenti disabili.
Come ricordato anche da Robero Scano in un’intervista3 pubblica sul Web, nel mondo opensource solo recentemente si sta muovendo un notevole interesse nell’aggiornamento dei
prodotti verso le caratteristiche di accessibilità, soprattutto con la finalità di introdurre questo
sistema nelle pubbliche amministrazioni.
1
2
3
[http://msdn.microsoft.com/library/default.asp?url=/downloads/list/accessibility.asp]
[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc/html/actvaccess.asp]
Roberto Scano: [http://www.scarichiamoli.org/main.php?page=interviste/scano]
- 369 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
In effetti, sia la Section 508 sia la legge Stanca recano dei requisiti che anche i sistemi
operativi devono soddisfare per essere adottati nelle pubbliche amministrazioni.
Fino poco tempo fa la comunità di sviluppatori Linux ha puntato soprattutto sugli utenti normodotati e lo sviluppo di di interfacce accessibili ed usabili non ha ottenuto un grande riscontro.
Questo ha creato un certo ritardo nello sviluppo dell’accessibilità in quanto è necessario
ridisegnare le interfacce delle applicazioni se si desidera poterle fornire ad enti pubblici.
Ad ogni modo, per quanto Linux possa essere ancora indietro da questo punto di vista
sicuramente il tema dell’accessibilità in questo sistema operativo è in pieno sviluppo1.
Qualunque iniziativa di un certo rilievo come KDE, GNOME, Mozilla, OpenOffice.org ed altre
considerano come un aspetto importante l'accessibilità e l'usabilità dei prodotti e delle
interfacce2.
Un grosso passo in avanti è stato fatto attraverso un progetto di accessibilità3 focalizzato
sull’accessibilità di una interfaccia grafica di Linux molto popolare denominata GNOME.
Il GNOME Accessibility Project, rispetto a quello di KDE, si è dedicato fin da subito alla parte di
architettura piuttosto che sui prodotti finali. E' una scelta che allunga certamente di più i
tempi, ma alla fine tende a portare anche i risultati migliori. Nel progetto esistono
sostanzialmente:
Un ingranditore di schermo (Gnopernicus);
Una tastiera virtuale (GOK - Gnome Onscreen Keyboard);
Uno screen-reader;
Un dispositivo di controllo della barra Braille.
In aggiunta, è stata creata la GNOME Accessibility Architecture che integra questi strumenti ed
altri progetti di terze parti in un ambiente unico. Ad esempio il nuovo desktop GNOME
accessibile può far uso di un sintetizzatore vocale di elevata qualità come Festival che è stato
sviluppato dalla Carnegie Mellon University e che era già in commercio da diversi anni.
Altri strumenti da terze parti includono:
Pacchetti per la configurazione di tastiere e mouse per disabili con le stesse funzionalità
di gestione che sono state viste per Windows e MAC OS X (StickyKeys, MouseKeys,
RepeatKeys, SlowKeys, ToggleKeys, BounceKeys);
1
2
3
Software per il riconoscimento del parlato;
Software per la gestione della barra Braille;
[http://larswiki.atrc.utoronto.ca/wiki/Overview]
Marco Trevisan: [http://www.scarichiamoli.org/main.php?page=interviste/trevisan]
[http://developer.gnome.org/projects/gap/]
- 370 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Software per il riconoscimento ottico dei caratteri (OCR).
Altrettanto significativo è anche il KDE Accessibility Project.
Il KDE Accessibility Project, ha:
Un ingranditore di schermo (KMagnifier);
Un sintetizzatore vocale (KMouth);
Un supporto che simula il click del mouse (KMouseTool).
KMouth non è un lettore vocale (tipo JAWS per Windows), ma un sintetizzatore per le persone
che non sono in grado di parlare, e sfruttano la sintesi vocale per sopperire a questo limite
fisico. Anche KDE, comunque, sta lavorando alle proprie librerie di sistema per incrementare
l'accessibilità nell'architettura, in modo da rendere possibile l'aggancio a tali funzioni anche da
parte di altri produttori.
Prima di concludere ricordo che a comunità Linux ha attivato da tempo il progetto Blind Linux,
con l'intento di garantire l'usabilità del Sistema Operativo Linux alle persone non vedenti 1.
Come parte integrante del sistema operativo Suse Linux 7.0 è stato sviluppato lo screenreader Suse Blinux2, un software che permette alle persone non vedenti e ipovedenti di
lavorare comodamente con Linux.
Suse Blinux non è una parte indipendente o una patch del software, ma piuttosto un
programma che lavora in sottofondo. Un vantaggio di ciò è che Suse Blinux non compromette
in alcun modo il funzionamento del sistema e gli utilizzatori non vedenti e ipovedenti
dispongono dell'uso illimitato di tutte le applicazioni che lavorano sulla consolle di Linux in
modalità testo.
I sostenitori di Linux affermano che la politica del software libero su cui Linux è basato
potrebbe condurre a breve ad un sistema operativo ancora più riccamente accessibile
sostenendo che gli utenti con disabilità avranno un controllo più elevato sul loro sistema,
ampie possibilità di scelta negli strumenti da usare e saranno meno nelle mani di pochi
rivenditori di tecnologie assistive come invece può accadere nel mondo Windows o Apple.
Apple MAC OS X
Con il rilascio della piattaforma MAC OS X, anche Apple ha incrementato l’accessibilità del suo
sistema operativo. Per esempio è possibile adesso accedere in maniera molto migliore alla
1
2
[http://www.webusabile.it/archivio/2001/3/30.aspx]
[http://www.novell.com/de-de/products/linuxprofessional/blinux/]
- 371 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
interfaccia del sistema operativo via tastiera di quanto non fosse possibile nelle versioni
precedenti. In oltre Apple ha implementato l’accessibilità nel suo Carbon Application Program
Interface (Carbon API), che consente alle applicazioni che girano su MAC OS X di comunicare
più efficacemente con le tecnologie assistive.
Apple si riferisce all’insieme delle caratteristiche di accessibilità integrate in MAC OS X
denominandole collettivamente Accesso Universale1. Vengono suddivise in 5 blocchi, alcune
voci possono essere ripetute in quanto attinenti a più di un area:
Visione:
o
VoiceOver: una interfaccia vocale che permette di accedere al Macintosh tramite
frasi parlate e segnalazioni udibili;
o
Zoom: che permette di ingrandire qualsiasi parte dello schermo, testo, grafica e
video, senza perdere di definizione;
o
Cursore scalabile: è possibile ingrandire la dimensione del cursore del mouse in
modo che sia più facilmente rintracciabile nei movimenti;
o
Avvisi ed elementi vocali: forniscono un metodo udibile per ricevere le
segnalazioni dal computer. Le segnalazioni visive sono pronunciate a voce alta e
viene letto il testo che si trova sotto la posizione del mouse;
o
Impostazioni video: è possibile controllare il contrasto impostando lo schermo in
bianco e nero, scala di grigi o a contrasto elevato;
Ascolto:
o
QuickTime: è uno dei visualizzatori in grado di gestire le sottotitolazioni
(captions) e le tracce di testo;
o
Segnalazioni visive: MAC OS X fornisce allarmi visivi per notificare le
segnalazioni dal sistema facendo lampeggiare lo schermo intero;
o
iChat, iSight: un sistema di video conferenza di alta qualità video in modo da
poter mostrare con chiarezza il linguaggio dei segni impiegato dai partecipanti;
Motorie, aiutano nell’impiego del computer nel caso in cui si abbiano delle difficoltà
nell’utilizzo della tastiera, del mouse o del track pad:
o
SlowKeys: impostano un ritardo aggiuntivo dei tasti, da quando vengono
premuti a quando hanno effetto, questo per impedire ripetizioni dovute a
pressioni indesiderate;
1
[http://www.apple.com/accessibility/]
- 372 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
o
StickyKeys: utile nel caso che l’utente possa premere un solo tasto per volta.
Ogni tasto di una sequenza viene mostrato sullo schermo in modo da poter
verificare la sequenza e correggerla, se necessario, prima che venga eseguita;
o
Impostazioni di tastiera: è possibile impostare il tempo di ritardo e di ripetizione
dei tasti utilizzando utilmente questa funzionalità insieme a quella di SlowKeys;
o
Navigazione via tastiera: permette di interagire con il sistema utilizzando la
tastiera. Le scorciatoie da tastiera consentono d attivare procedure con la
pressione di un singolo tasto;
o
MouseKeys: è possibile impiegare il tastierino numerico per muovere il cursore
in modo da simulare le normali attività del mouse;
o
Riconoscimento vocale: consentono di controllare il computer usando la voce. Si
possono usare comandi per aprire e chiudere programmi, navigare nei menu,
spostarsi tra gli applicativi in esecuzione ed i controlli della finestra attiva;
Apprendimento, vengono offerte soluzioni per assistere nel processo di apprendimento
in campo letterario, matematico e di assistenza alla scrittura:
o
Pronuncia del testo sotto il mouse: Il sistema riconosce i comandi del software di
pronuncia e i nomi di ogni file;
o
Avvisi vocali: il computer può pronunciare a voce alta i messaggi che appaiono
sullo schermo;
o
Text-to-speech.:permette al computer di pronunciare i messaggi di avviso, ci
sono diverse voci tra cui scegliere;
o
TextEdit: pronuncia un documento intero o un testo selezionato;
o
Calcolatrice: pienamente accessibile dalla tastiera può essere impiegata con la
pronuncia di ogni tasto che viene premuto e del risultato del calcolo;
o
iChat AV: con un controllo di dizione incluso per studenti con disabilità cognitive;
Linguaggio e comunicazione, metodi di comunicazione alternativa per aiutare nello
sviluppo del linguaggio:
o
TextEdit: può pronunciare un intero documento o un testo selezionato.
Tuttavia, nonostante questi sforzi, i prodotti di tecnologia assistiva disponibili per MAC OS X,
ancora ad oggi, sono molto meno diffusi di quanto non lo siano quelli per Windows. Ad
esempio i produttori di screen-reader e di ingranditori per MAC OS non garantiscono la
continuità dello sviluppo di questi applicativi.
Si tratta di un problema storico di sviluppo, giacché MAC OS X è adesso in grado di supportare
la maggior parte delle funzioni di accessibilità offerte anche da Windows.
DOS
Come fatto presente in precedenza, DOS e Unix non avevano un’interfaccia grafica.
- 373 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Questo permetteva alle tecnologie assistive di interfacciarsi con il sistema con relativa
semplicità rielaborando quanto presente nella memoria della scheda video.
Per questo non è raro incontrare anche oggi alcuni utenti disabili che lavorano con dei
pacchetti software sviluppati per DOS, nonostante che questo sistema operativo non sia più
supportato da molti anni.
In aggiunta esiste un pacchetto applicativo aggiuntivo sviluppato dalla stessa Microsoft che
permette di arricchire questo sistema con ulteriori funzionalità.
Il software si chiama AccessDos1 ed è disponibile per tutti i sistemi MS-DOS dalla versione 3.3
in poi. Richiede pochissima memoria di sistema e può essere facilmente disabilitato per un
utilizzo normale.
AccessDOS è un programma di utilità che facilita l’utilizzo del mouse e della tastiera per disabili
motori e consente di mostrare a video gli avvisi acustici del sistema.
Tra le caratteristiche rilevanti ci sono:
Tasti permanenti (stickyKeys) che permettono, come per Windows, di premere un tasto
per volta nelle combinazioni in cui sono richieste pressioni simultanee. Il sistema è utile
soprattutto per utenti che impiegano cannucce o movimenti della testa per interagire
con il computer;
Sensibilità della tastiera (SlowKeys) che permette il controllo del tempo della pressione
di un tasto in modo che le applicazioni non considerino i tasti che non sono tenuti
premuti per un intervallo minimo di tempo;
Ripetizione dei tasti (RepeatKeys) che permette di impostare il tempo dopo il quale un
tasto tenuto premuto viene ripetuto;
Pressioni ripetute (BounceKeys), che permettono di ignorare lo stesso tasto premuto
più volte in rapida sequenza;
Controllo del mouse (MouseKeys), che permette di spostare e controllare il mouse via
tastiera, dando anche un controllo fine sui movimenti di precisione;
Tasti attivi (ToggleKeys), che permettono di avere un riscontro audio per l’attivazione e
la disattivazione dei classici tasti di maiuscole, blocco tastierino numerico e blocco
scorrimento;
Interfaccia esterna (SerialKeys), che permette, in congiunzione con un dispositivo di
interfaccia ausiliare di controllare il computer utilizzando un sistema di ingresso
alternativo come se stesse utilizzando mouse o tastiera;
1
[http://ms.helifan.net/enable/products/ados.aspx]
- 374 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Avvisi visivi (soundSentry), che permette di riportare gli avvisi sonori in segnalazioni
visive con il lampeggiamento dello schermo o di parte di esso.
Queste caratteristiche sono molto simili ad alcune di quelle implementate in Windows e Mac
OS, e sono state descritte in quella sede. Possono lavorare in congiunzione fra loro e possono
essere disabilitate in automatico dopo un certo periodo di attesa del sistema
V.5 - Applicativi e formati proprietari
Con le WCAG 1.0, i metodi per realizzare dell’accessibilità erano tutti focalizzati sulle tecnologie
suggerite dal W3C, ed il resto del mondo non era sostanzialmente considerato.
Il cambiamento essenziale di prospettiva è arrivato in breve con l’osservazione che molti dei
contenuti Web non venivano, in questo modo, normati. Un esempio per tutti i documenti PDF
che oramai sono considerati uno standard di fatto per mettere a disposizione informazioni in
forma chiusa ed impaginata.
Per questo le WCAG 2.0 sono state riprogettate per contenere linee guida che includano
considerazioni anche per questi formati esterni al W3C.
Nello stesso tempo anche i progettisti di tecnologie esterne al W3C hanno sviluppato una
sensibilità molto maggiore al problema mettendo a disposizione del Web nuovi strumenti e
nuove direttive per rendere accessibili i propri formati.
Un esempio per tutti è Macromedia Flash, nel frattempo passato sotto il controllo di Adobe, che
dalla versione 5 alla versione 6 e MX ha fatto passi da gigante in termini di accessibilità1.
In generale possiamo quindi affermare che non è contro l’accessibilità inserire nella pagina dei
collegamenti a dei formati non proprietari del W3C, a patto che tali contenuti siano poi resi
accessibili usando le tecniche suggerire dai produttori e i principi guida esposti nelle WCAG 2.0.
Alcune norme basilari possono essere attuate per aumentare l’accessibilità:
Inserire un collegamento ipertestuale che rimandi al plug-in proprietario in modo che
esso possa essere scaricato nel caso non sia già installato nella macchina;
Fornire, quando possibile, dei collegamenti ipertestuali alternativi a documenti in
formato non proprietario (TXT) o aperto (RTF);
Indicare, nel collegamento ipertestuale, la dimensione e la tipologia del file esterno,
come segnalato nelle tecniche per i collegamenti ipertestuali, in modo che l’utente
possa valutare l’onere e l’interesse dell’oggetto collegato.
1
“Something quasi-miraculous came to pass while I was writing this book: Macromedia Flash went from
completely inaccessible to quite accessible overnight.” –
[http://joeclark.org/book/sashay/serialization/Chapter13.html]
- 375 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La situazione per quanto riguarda la leggibilità dei formati più diffusi è oramai di buon livello:
Microsoft Word e Microsoft Excel in ambiente Windows sono perfettamente accessibili con gli
screen-reader. Con JAWS è possibile utilizzare la maggior parte delle applicazioni Windows,
come la suite Microsoft Office: Word, Excel, Access, PowerPoint, Outlook, per quanto sia
comunque sempre da preferirsi il formato RTF al DOC in quanto risulta più universale e
compatibile.
Per gli utenti che non abbiano installato Microsoft Excel esiste un apposto visualizzatore fornito
dalla Microsoft (Excel Viewer) che però, prima della versione Office 2007, non era ancora
accessibile.
Power Point rappresenta un problema più significativo. In tal caso occorre disporre del
programma in versione completa per potervi accedere con uno screen-reader. Il visualizzatore
fornito da Microsoft (PPT Viewer) non è accessibile per le tecnologie assistive.
Ma anche fosse reso accessibile, occorre avere bene in mente, nel momento di produrre dei
documenti in PowerPoint, che le tecnologie assistive possono solo avere accesso ai contenuti
testuali. Per questo motivo ogni immagine ed ogni animazione dovrebbe essere
opportunamente trattata con dei testi alternativi. A questo punto occorre chiedersi se valga
veramente la pena produrre il contenuto informativo in Power Point, e non sia invece più
sensato predisporre un file (X)HTML che dovrebbe comunque essere fornito in alternativa alla
presentazione in Power Point non pienamente accessibile.
Da segnalare che la conversione in automatico consentita direttamente in Power Point non
produce risultati accettabili e deve sempre essere rivista manualmente.
Per ultimo va segnalato che tutta la suite OpenOffice non è ancora stata resa accessibile, come
anche ribadito da Luca Mascaro al corso IWA nel 2005.
Vediamo adesso una breve panoramica dei formati più diffusi. Molte di queste informazioni
sono disponibili in rete sul preciso e completo sito 1 di WebAIM.
Prima di presentare questi formati vorrei riportare la segnalazione di un manuale aperto2 per la
divulgazione e la scrittura di testi per il Web, segnalazione fatta presente da Roberto Ellero al
seminario IWA del Maggio 2005. Il testo è molto completo e contiene anche molte altre
informazioni aggiuntive sulla corretta preparazione di contenuti informativi per il Web.
1
2
[http://www.webaim.org/articles/]
[http://wiki.porteapertesulweb.it/space/Manuale+aperto]
- 376 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Microsoft Word
Microsoft Word non è sicuramente il formato consigliato per offrire documenti informativi
disponibili in rete. Questo per il fatto che esistono altri formati proprietari, come ad esempio lo
stesso PDF, che, oltre ad essere notevolmente più snelli, garantiscono anche una migliore
sicurezza dei dati.
Ad ogni modo è possibile rendere parzialmente accessibile anche un documento in Word
utilizzando alcune avvertenze basilari.
Creare documenti strutturati
La maggior parte delle persone usa i programmi di word processing in maniera scorretta.
Invece di usare delle vere intestazioni, spesso semplicemente si allarga la dimensione del font
e lo si mette in grassetto.
Se si agisce in questo moto, il documento finisce per non possedere una vera struttura che
possa essere identificata da uno screen-reader.
Il modo giusto per implementare una struttura dentro un documento di word è quello di
utilizzare gli apposti stili.
Word stesso fornisce una casella di riepilogo per gli stilli che permette all’utente di creare delle
intestazioni corrette anche dal punto di vista strutturale e semantico.
Ci sono almeno due grossi vantaggi nel creare una vera strutturazione dei documenti Word.
Innanzi tutto, quando il file verrà esportato in un formato HTML, manterrà la struttura
rendendolo accessibile ai lettori di schermo.
In secondo luogo la struttura verrà similmente mantenuta anche in una esportazione in un
formato PDF.
In ambedue i casi, la struttura aggiunta aumenta la leggibilità del documento sia per le
persone che utilizzano degli screen-reader che per coloro che semplicemente vogliano avere un
accesso migliore e più organizzato al testo.
Fornire una alternativa testuale per le immagini
Prima di esportare un documento di Word in HTML o PDF, è necessario fornire una alternativa
testuale a tutte le immagini contenute.
Per fornire un’alternativa testuale è sufficiente modificare la proprietà “Web” sulla scheda
“Formato Immagine” ed aggiungere l’appropriato testo alternativo.
Le regole sulla scrittura di questo testo alternativo sono le stesse esposte per le pagine HTML,
questo poiché, nella conversione in (X)HTML, questo testo sarà quello inserito nell’attributo
ALT.
- 377 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Salvare il file come HTML
Quando il file verrà salvato in formato HTML, la struttura implementata con le intestazioni e il
testo alternativo fornito con le immagini faranno parte del documento finale.
Per salvare il documento in formato HTML, selezionare “Salva come pagina Web” dal menu file.
Nelle edizioni più recenti di Word sarà a questo punto possibile scegliere due modalità di
salvataggio, come pagina Web o come pagina Web filtrata.
Il vantaggio della prima scelta è che la pagina avrà praticamente lo stesso aspetto del
documento stampato. Il vantaggio della seconda è che avrà molti meno materiale aggiuntivo in
HTML.
La dimensione del file nel secondo caso sarà significativamente inferiore a discapito di un
aspetto che potrebbe essere parzialmente difforme da quello del documento originario.
In termini di accessibilità entrambe le soluzioni sono accettabili con il presupposto che il file
sorgente sia stato creato con la struttura e con il testo alternativo per le immagini e non
contenga nessun tipo di tabelle dati.
Problemi di accessibilità con le tabelle dati.
Nella maggior parte dei casi un documento di Word può essere convertito in un file HTML
accessibile, ma ci sono alcune eccezioni.
Le tabelle non possono essere convertite in tabelle dati accessibili utilizzando il formato di
pagina Web filtrata.
Questo per il fatto che non c’è alcun modo per assegnare l’intestazione di tabella o l’elemento
TH
ad una cella di una tabella in Word.
Esiste tuttavia un’opzione all’interno di Word per fare in modo di creare l’aspetto di una
intestazione di tabella. Questa proprietà può essere impostata selezionando le proprietà della
tabella. Sotto la scheda “Riga” si trova una casella di controllo: “Ripeti riga come intestazione
in ogni pagina”.
Spuntare questa voce farebbe pensare che tutte le celle della riga saranno esportate come
elementi di intestazione ma non è così.
Le celle invece saranno contenute in un blocco THEAD. Come specificato nella sezione delle
Metodologie generali, i blocchi THEAD, TFOOT, TBODY sono usati per dividere le tabelle nelle 3
parti fondamentali delle tabelle dati. Non ci sono problemi con l’utilizzo di quest’elemento,
tuttavia esso non sostituisce l’utilizzo dell’elemento TH nell’esportazione.
Limitazioni
Occorre porre attenzione al fatto che il processo di conversione di un documento complesso
con grafici, tabelle o altri elementi interni, probabilmente non creerà un file che sia
completamente accessibile agli screen-reader. Gli elementi inclusi saranno probabilmente
- 378 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
ignorati nella lettura, giacché risultano illeggibili. In queste circostanze si dovrebbe fornire
almeno una descrizione testuale degli oggetti all’interno del contesto del documento stesso.
Un utile strumento di conversione esterno al pacchetto Microsoft Office può essere l”Illinois
Accessible Web Publishing Wizard”1 disponibile per i sistemi operativi Windows. La versione
completa è a pagamento, ma esiste una versione dimostrativa scaricabile gratuitamente.
Adobe PDF
Per quanto questo formato non sia una delle tecnologie suggerite dalle WCAG 1.0, tuttavia
molti sviluppatori di pagine internet lo hanno pesantemente utilizzato per la pubblicazione dei
testi in rete, anche per la oramai diffusa presenza del suo lettore su quasi tutte le piattaforme.
Rispetto a documenti Microsoft World possiede l’innegabile qualità di essere notevolmente più
compatto ed efficace, in oltre i documenti in PDF sono da ritenersi chiusi alle modifiche, a
meno che non si disponga di uno strumento adatto disponibile a pagamento.
Molti testi potrebbero ovviamente essere scritti direttamente in (X)HTML come raccomandato
dalle WCGA 1.0, tuttavia gli effetti di impaginazione e presentazione grafica dei contenuti PDF
ne fanno un vantaggioso compromesso a cui è stato impossibile rinunciare.
Di fatto l’utilizzo di questo formato viene tollerato ed accettato da tutte le normative in quanto
si considera oramai la sua accessibilità valutandola dal punto di vista del testo contenuto
piuttosto che da quella della standardizzazione del formato.
Da questo punto di vista l’attenzione di uno sviluppatore nei riguardi dell’accessibilità di un
documento PDF va posta in due direzioni:
Uso corretto degli elementi di struttura e semantica messi a disposizione;
Chiarezza, strutturazione e comprensibilità del testo contenuto.
Adobe ha a disposizione sul suo sito un manuale completo sull’accessibilità e su come produrre
documenti PDF accessibili e come rendere tali quelli esistenti 2.
Qui voglio presentare una piccola guida introduttiva alla comprensione del problema. La
maggior parte delle informazioni sono validamente esposte sul sito3 di WebAIM (Web
Accessibility in Mind).
Un interessante e completo lavoro sull’accessibilità dei documenti PDF è quello di Andrea Pes 4.
1
[http://cita.rehab.uiuc.edu/software/office/]
[http://www.adobe.com/enterprise/accessibility/acrobat70.html]
3
[http://www.webaim.org/articles/]
4
Andrea Pes: “Metodologie e tecniche per l'accessibilità di documenti Adobe PDF” [http://elite.polito.it/tesi/pes.pdf]
2
- 379 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Va fatto notare, ancora prima di iniziare questa breve analisi, che un documento PDF
protetto non è accessibile. Se viene bloccato attivando la protezione diventa come un
immagine, e come tale non risulta leggibile dalle tecnologie assistive che non sono in grado di
accedere al testo contenuto. Bloccando il PDF si perde l’accessibilità.
Accessibilità dei documenti PDF
L’uso appropriato dei documenti PDF è un argomento molto dibattuto, sia per quanto riguardi
l’accessibilità che per quanto non la riguardi.
Qualcuno vorrebbe dedurre che non ci sia spazio per i documenti PDF, mentre altri sostengono
che, opportunamente preparati, i documenti PDF siano altrettanto accessibili quanto le pagine
HTML. Probabilmente la verità è una via di mezzo di queste due letture.
Per fare in modo che un documento PDF sia veramente accessibile occorre soddisfare due
condizioni:
1. L’autore del documento deve creare un PDF ben strutturato e correttamente marcato;
2. Il lettore deve in grado di impostare le sue preferenze di accessibilità all’interno di
Adobe Reader.
Vedremo adesso di analizzare entrambe queste due condizioni.
Le esigenze degli utenti
Come nel caso di documenti HTML occorre tenere presente a che tipologia di problematiche
può andare incontro un disabile nella lettura di un documento PDF.
Quando si parla dell’accessibilità di Adobe Acrobat o dei documenti PDF ci si riferisce in genere
all’accessibilità di Acrobat per uno screen-reader, ma gli utenti di screen-reader non sono le
sole persone che dovrebbero essere considerate al momento di produrre un documento PDF
accessibile.
E’ importante ricordare che non tutti i disabili sono ciechi. Occorre tener presente i bisogni di
individui con disabilità motorie, uditive, cognitive o con problemi di ipovisione.
Vediamo alcune linee guida generali per rendere i documenti PDF accessibili alle persone con
diverse tipologie di disabilità:
Disabilità motorie.
Non fare gli hot spot troppo piccoli. Naturalmente la frase troppo piccoli è relativa, ed è
anche vero che gli utenti possono ingrandire il documento, ingrandendo in questo modo
anche gli hot spot all’interno del documento. Ad ogni modo più piccolo sarà il
collegamento e più difficoltoso sarà per le persone con difficoltà motorie accedere al
collegamento stesso;
Disabilità uditive.
Fornire trascrizioni per gli elementi multimediali. Se viene incluso un elemento
- 380 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
multimediale tramite un suono nel documento PDF, questo escluderà sia i sordi che i
sordo ciechi a meno che non venga fornita una trascrizione.
Occorre fornire titolazioni sincronizzate con il video. Le persone sorde hanno bisogno di
questo tipo di servizio se il video perde di significato quando l’audio non è percepibile;
Disabilità cognitive.
Usare un linguaggio semplice e chiaro. In altre parole, scrivere bene. Meglio si riesce a
scrivere, meglio si verrà capiti da tutti, non solo da coloro con disabilità cognitive.
Bisogna anche porre l’attenzione dovuta nel rendere il documento accessibile agli
screen-reader. Non tutte le persone con disabilità cognitive traggono beneficio dal
sentirsi letto un documento, tuttavia per qualcuno questo è vero. Al fine di poter essere
pronunciato, il documento deve essere accessibile per gli screen-reader;
Ipovedenti.
Assicurarsi che ci sia un contrasto sufficiente nel documento PDF.
Assicurarsi anche che tutte le informazioni che sono veicolate dal colore siano
trasmesse allo stesso modo quando il colore non è disponibile. Potrebbe essere
necessario aggiungere qualche segno testuale in aggiunte al colore per trasmettere
l’informazione;
Cecità.
Prima del rilascio della versione di Acrobat 5.0, i documenti PDF non erano accessibili
agli screen-reader in modo significativo. Ora è possibile esporre il testo in un
documento PDF agli screen-reader, ma allo stesso modo dei documenti HTML, i file PDF
devono essere prodotti tenendo ben presente il fine dell’accessibilità. Altrimenti i
documenti PDF potrebbero essere altrettanto inaccessibili come prima dell’avvento di
Acrobat 5.0. La notizia spiacevole è che di solito questo richiede un maggior lavoro che
non rendere accessibile un documento HTML. Per quanto, ad ogni modo, possa essere
fatto con uno sforzo ragionevole.
Due approcci alla accessibilità.
Per quanto Adobe stia facendo il massimo sforzo per rimuovere le barriere di accessibilità dai
suoi prodotti, tuttavia (X)HTML è ancora il formato Web da preferire per venire incontro alla
maggioranza di utenti con disabilità.
Ci sono due modi di affrontare il problema:
1. Fornire un’alternativa HTML al documento PDF, in aggiunta o in sostituzione;
2. Rendere accessibile il documento PDF dalla sua nascita, creando un documento
strutturato in maniera opportuna.
Se l’equivalente (X)HTML è più accessibile del documento PDF e fornisce lo stesso contenuto
informativo, sarebbe più appropriato eliminare del tutto il documento PDF e concentrarsi
- 381 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
piuttosto sul rendere il contenuto accessibile in formato (X)HTML. Questo non è sempre
attuabile, ma in molti casi vale la pena considerare questa scelta.
Creare un documento PDF strutturato in maniera accessibile lo renderà accessibile agli screenreader standard che supportano i PDF strutturati con marcatori, come ad esempio JAWS e
Windows Eyes. Questo eliminerà il bisogno per l’utente finale di imparare ad usare il
sintetizzatore vocale interno di Adobe.
Tuttavia non è sempre facile produrre documenti PDF che siano direttamente accessibili agli
screen-reader. Potrebbe essere estremamente difficile, se non impossibile, convertire in un
PDF accessibile i documenti di aspetto complesso, e questo per il fatto che il contenuto non si
linearizza in forma corretta. In oltre risulta molto difficoltoso rendere accessibili documenti con
grafici estesi o con video inclusi.
Creare un file HTML dal documento originale
Se si deve convertire un documento PDF in un file (X)HTML, la cosa migliore è sempre quella di
recuperare il documento sorgente. Sarà più facile convertire l’originale in Word in un file HTML
che non fare la stessa cosa tramite il passaggio in PDF.
E’ importante ricordare che quando si converte un file da Microsoft Office, solamente i file ben
formati produrranno dei documenti (X)HTML o PDF ben formati.
Si devono utilizzare le intestazioni reali, non semplicemente i font allargati o in grassetto, le
liste puntate o numerate e gli altri marcatori strutturali nel documento originale. Se non si
procede in questo modo i marcatori corretti non verranno creati quando il documento viene
convertito in (X)HTML o PDF. Per molti questo vuol dire imparare ad usare gli elementi
strutturali in Word, visto che spesso non si da sufficiente importanza alle opzioni di stile
all’interno di un word processor. La mentalità di dare attenzione solo all’aspetto visuale deve
cambiare per ottenere dei contenuti accessibili ed utilizzabili dagli screen-reader.
Consultare la parte specifica su Word per avere informazioni in proposito.
Convertire un documento PDF in un file HTML
Qualche volta il file originale usato per creare il PDF non è a disposizione.
In tal caso è possibile creare un file (X)HTML usando Acrobat, ma il file sarà probabilmente
piuttosto complesso e richiederà più lavoro per renderlo accessibile.
Per creare un file (X)HTML in Adobe Acrobat scegliere la voce dal menù “Salva come…”.
Il documento (X)HTML che verrà prodotto in questa conversione sarà però di qualità piuttosto
scadente, tanto che probabilmente occorrerà spendere lo stesso tempo nel tentativo di ripulirlo
di quello che si impiegherebbe a crearlo ex novo.
Se sono presenti delle immagini, solamente la descrizione alternativa delle immagini sarà
salvata piuttosto che l’immagine stessa e non saranno presenti nessun tipo di tabelle nel file
(X)HTML, anche se la tabella fosse stata appropriatamente marcata nel file PDF originale.
- 382 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
I marcatori PDF
I marcatori PDF sono una rappresentazione solo testo del documento nascosta all'interno del
PDF e presentata ai lettori dello schermo. Esistono per i soli scopi di accessibilità e non hanno
effetto visibile sul file PDF.
I marcatori (X)HTML ed i marcatori PDF spesso usano gli stessi nomi e le stesse strutture
organizzative ma sono piuttosto differenti. Ad esempio non è possibile inserire un marcatore
PDF nel codice con le stesse modalità con cui invece è possibile per quelli (X)HTML.
Tuttavia, se si hanno conoscenze dell’(X)HTML, probabilmente sarà più semplice creare ed
editare file PDF marcati.
La scheda dei marcatori
Alla scheda dei marcatori si può accedere con Acrobat Professional. Da qui è possibile
riordinare, modificare, cancellare e creare i marcatori.
Per visualizzare i marcatori si accede al menù vista fino alla scheda dei marcatori.
Una lunga lista navigabile di marcatori appare visibile e può essere espansa o collassata.
Selezionare un marcatore implica evidenziare anche il testo, l’immagine o gli altri elementi che
vi si trovano racchiusi. Allo stesso modo è possibile evidenziare il marcatore dove è incluso un
elemento a partire dall’elemento stesso.
Molti di questi marcatori sono simili, se non identici a quelli HTML tra cui:
<H1>..<H6>: per le intestazioni;
<P>: per i paragrafi;
<L>, <LI>: per le liste;
<Table>, <TH>, <TR>, <TD>: per le tabelle;
<Figure>, in luogo di <img> per le immagini.
Queste sono le specifiche di Adobe. Ma non sono sempre quelle usate da altri programmi,
quando creano un PDF.
Microsoft Word ad esempio produce alcuni marcatori insoliti, come ad esempio <Heading 1> in
luogo di <H1>. Questi marcatori possono ad ogni modo essere riportati opportunamente ai
marcatori PDF usando delle regole di mappatura che possono essere cambiate dal menù delle
opzioni.
Controlli di accessibilità.
Acrobat versione professional include due differenti tipi di controlli per l’accessibilità del
documento:
Controllo rapido.
Essenzialmente verifica se il file possiede dei marcatori oppure no. Tuttavia non
rintraccia i più comuni errori di base come la mancanza di un testo alternativo;
- 383 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Controllo avanzato.
Sebbene sia definito come più avanzato, è ben lontano dall’essere completo. Ad ogni
modo identifica caratteristiche come la mancanza di testo alternativo e offre
suggerimenti su come riparare alcuni errori.
Allo stesso modo di un documento HTML, uno screen-reader legge un documento PDF
basandosi sull’ordine dei suoi marcatori. Ma l’ordine dei marcatori in un documento PDF
potrebbe non essere lo stesso di una lettura visiva. Questo è vero in particolar modo se il
documento PDF contiene colonne multiple o altri blocchi di testo o liste complesse annidate.
Esiste uno strumento che permette di ricostruire l’ordine visuale del testo basandosi sull’ordine
dei marcatori. In caso di discrepanze questo è un segnale che l’ordine dei marcatori deve
essere riorganizzato.
Convertire un documento PDF esistente in un documento PDF con marcatori.
Prima di proseguire con questo paragrafo occorre ricordare che, sebbene i PDF con marcatori
possono essere creati con l’Acrobat Standard, tuttavia possono essere modificati solamente
con la versione Professional.
Con questa versione i marcatori possono essere modificati selezionandoli e rinominandoli, ad
esempio nel caso si volesse far passare un marcatore di intestazione da livello H1 a livello H2.
Un'altra operazione significativa è quella di aggiungere un testo alternativo alle immagini dove
mancante o scorretto.
Ci sono due modi principali per aggiungere il testo alle immagini direttamente nel documento
PDF:
Intervenire sulle proprietà dell’immagine e nella scheda dei marcatori aggiungere il
testo alternativo;
Intervenire sul marcatore di testo alternativo se esistente e modificarlo direttamente.
I marcatori possono essere anche cancellati o creati ex novo, scegliendoli nella apposita lista
presentata da Acrobat e inseriti nel documento.
Un utile funzionalità offerta dal programma permette in oltre di riordinarli, annidandoli anche in
modo opportuno.
Aggiungere marcatori a un file senza marcatori
Aggiungere marcatori ad un documento senza marcatori non è molto diverso da editare un file
esistente. In effetti, se il file PDF è scarsamente marcato, potrebbe essere più semplice
cancellare i pochi marcatori esistenti e ripartire. A questo proposito esiste una funzione
apposita che cancella tutta la struttura dei marcatori.
Ci sono due sistemi principali per aggiungere i marcatori, il primo è lasciare che Acrobat li
aggiunga da se e poi modificarli, il secondo è aggiungerli direttamente in modo manuale.
- 384 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Con la prima opzione è possibile inserire automaticamente i marcatori in un file non marcato,
tuttavia i risultati sono abbastanza deludenti. Potrebbe essere un modo veloce di cominciare,
soprattutto se il documento contiene delle tabelle.
Lo si può richiamare dal menù di accessibilità. Occorre ricordarsi poi di proseguire il lavoro
manualmente.
Altrimenti si può decidere di inserire tutti i marcatori manualmente usando la scheda dei
marcatori e partendo dall’elemento radice.
Con la versione 7 di Acrobat è stato aggiunto uno strumento ancora più potente per
aggiungere marcatori in maniera rapida al documento, il “TouchUp Reading Order” che
permette una interfaccia diretta con gli oggetti a cui assegnare i marcatori.
Adobe Flash
I contenuti di Adobe Flash possono essere visualizzati praticamente su tutti i computer, la
tecnologia Flash, in senso lato, potrebbe essere una delle più largamente utilizzate sul Web.
Per gli sviluppatori, la possibilità di realizzare una presentazione multimediale che possa essere
visualizzata quasi alla stessa maniera su tutti i computer rende questa tecnologia molto
seducente. E tuttavia, per le persone disabili, Flash introduce dei problemi di accessibilità
peculiari.
Flash, proprio per la sua natura multimediale, può essere impiegato per distribuire informazioni
attraverso molti canali sensoriali, grafica, testo, video, audio ecc. La sua potenza e la sua
flessibilità gli danno la possibilità di presentare il contenuto Web in maniera pienamente
accessibile.
Flash può aumentare l’accessibilità dei contenuti in diversi modi, sfruttando le sue capacità
intrinseche:
Diverse modalità di presentazione;
Scalabilità:
Poiché Flash si basa sui vettori e non sulle griglie di pixel, la maggior parte dei
contenuti possono essere ridimensionati senza distorsioni, le persone ipovedenti
possono interagire con i contenuti Flash in modalità non possibili con i contenuti
(X)HTML;
Accessibilità via tastiera:
Flash consente un livello di interazione con la tastiera più alto di quanto non sia
consentito in (X)HTML, molte presentazioni Flash possono essere resi più funzionali,
efficienti e facili da usare abilitando l’accesso da tastiera;
Attrattività:
Flash è in grado di coinvolgere attraverso interattività, animazione, suono, grafica e
molti altri modi. Persone con disabilità cognitive e di apprendimento possono
comprendere meglio e concentrarsi di più sui contenuti Flash. Le presentazioni
- 385 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
multimediali di Flash possono essere usate come aggiunta al contenuto statico
(X)HTML;
Sistema vocale interno:
Per merito delle sue capacità audio, Flash può presentare contenuti audio eliminando il
bisogno di ricorrere ad uno screen-reader per estrarre la parte audio dalle presentazioni
Flash.
Problematiche per l’accessibilità di Flash
Nonostante la capacità di Flash di creare contenuti altamente accessibili, ci sono alcuni
problemi notevoli a cui bisogna prestare attenzione a proposito dell’accessibilità in Flash.
Quasi tutti i concetti che riguardano l’(X)HTML possono essere applicati a Flash, come ad
esempio l’uso del contrasto, un sistema di navigazione fruibile, un linguaggio comprensibile,
eccetera.
I principi per le diverse disabilità sono i seguenti:
Disabilità uditive:
o
Epilessia fotosensibile:
o
Fornire titolazioni sincronizzate per ogni traccia audio che veicola contenuti;
Rimuovere i contenuti lampeggianti con frequenza tra i 2 e i 55 Hz;
Disabilità motorie:
o
Garantire che i contenuti Flash possano essere utilizzabili dalla tastiera;
o
Non richiedere delle abilità motorie sofisticate;
Disabilità cognitive:
o
Garantire all’utente il controllo sui contenuti a tempo;
o
Fornire un sistema facile da usare per la navigazione;
o
Essere coerenti nelle presentazioni;
o
Utilizzare il linguaggio più semplice e appropriato per il contenuto;
Ipovedenti:
o
Fornire un contrasto adeguato;
o
Permettere a Flash di ridimensionarsi a dimensioni maggiori;
Cecità:
o
Garantire l’accessibilità degli screen-reader o fornire una alternativa accessibile;
o
Garantire la completa accessibilità via tastiera;
o
Non sovrapporsi ai comandi audio o via tastiera degli screen-reader;
o
Fornire un equivalente testuale per tutti gli elementi non testuali che veicolano
contenuti o forniscono funzionalità.
- 386 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per quanto ognuna di queste singole strategie possa incrementare l’accessibilità, un contenuto
Flash raramente è correttamente progettato per considerare tutti questi accorgimenti
contemporaneamente, rendendolo così inaccessibile in qualche modo.
Quando tutte le tecniche di accessibilità sono applicate a Flash, queste lo rendono
universalmente accessibile, forse anche di più di quanto non lo sia una pagina (X)HTML, dal
momento che viene rimosso il bisogno di ricorrere a specifiche tecnologie assistive come i
lettori di schermo.
Tuttavia, un tale risultato potrebbe essere impossibile da ottenere con la maggior parte delle
presentazioni Flash. In pratica, a meno di non implementare tutte le tecniche di accessibilità,
un contenuto Flash risulta solitamente non accessibile.
Supporto delle tecnologie assistive per Flash
Come visto, la maggior parte di un contenuto Flash non è accessibile in maniera nativa agli
screen-reader.
Per sua stessa natura il contenuto Flash non si presta all’accessibilità di uno screen-reader.
Una presentazione Flash è basata sul tempo e spesso cambia con il tempo mentre un
contenuto (X)HTML è più o meno statico, ed è la natura statica dell’HTML che permette allo
screen-reader di accedervi.
Quando un utente vedente accede ad una presentazione Flash, scorre il filmato e si concentra
direttamente sul contenuto importante. Uno screen-reader non può scorrere attraverso il
contenuto Flash e può accedere solo in maniera lineare seguendo l’ordine che lo sviluppatore
ha scelto per la presentazione.
Poiché un contenuto Flash si modifica in continuazione, ci sono dei limiti alle capacità di uno
screen-reader nell’accedere al contenuto.
Gli screen-reader più importanti (JAWS, Windows Eyes e IBM Home Page Reader) sono in
grado di fornire un accesso poco soddisfacente alle presentazioni di Flash più datate precedenti
alla 6+.
Per avere un’accessibilità completa con gli screen-reader, il contenuto Flash deve essere stato
sviluppato per l’accessibilità utilizzando Flash MX o le versioni successive.
Nonostante i problemi che Flash può introdurre per gli utenti di screen-reader, tuttavia ci sono
delle tecniche di accessibilità che possono essere implementate per rendere Flash più
accessibile.
MSAA (Microsoft Active Accessibility) può essere impiegata per trasferire un contenuto dal
visualizzatore di Flash allo screen-reader.
MSAA è una tecnologia Microsoft attualmente funzionante con Internet Explorer su computer
Windows che hanno il visualizzatore Flash versione 6 o successive installato.
- 387 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per quanto la maggior parte della tecnologia assistiva viene implementata sulla piattaforma
Windows/Explorer, gli screen-reader scritti per altre piattaforme non possono avvantaggiarsi
delle caratteristiche di accessibilità di Flash.
Ci sono svariati screen-reader che girano su altri sistemi operativi. Persone con disabilità
motoria potrebbero non usare Internet Explorer, ed ancora alcuni potrebbero non aver
installato un visualizzatore Flash compatibile, anzi, potrebbero non averlo del tutto.
Molti utilizzatori di screen-reader hanno disabilitato i contenuti Flash a causa del gran numero
di presentazioni Flash inaccessibili presenti sulla rete.
In breve occorre condurre dei test con uno svariato numero di utenti, sistemi operativi,
browser e tecnologie assistive per garantire che il contenuto Flash sia accessibile alla maggiore
quantità possibile di utenti.
Per questo occorre ripensare attentamente alla scelta di utilizzare Flash, visto che
probabilmente un'altra tecnologia potrebbe essere di maggior ausilio.
Poiché la maggior parte dei contenuti Flash non possono essere resi intrinsecamente
accessibili, sarà necessario fornire una alternativa non in Flash per coloro che non possono o
non vogliono accedervi.
Accessibilità per gli screen-reader.
Ci sono 3 modi in cui una presentazione Flash può essere resa accessibile ad un utente di
screen-reader:
Rendere il contenuto Flash intrinsecamente accessibile allo screen-reader;
Rendere il contenuto Flash auto eloquente, eliminando in questo modo il bisogno di uno
screen-reader;
Fornire una alternativa accessibile al contenuto Flash.
Rendendo la presentazione di Flash auto eloquente, si elimina il bisogno di ricorrere ad uno
screen-reader. In pratica si rimpiazza il ruolo dello screen-reader veicolando all’audio interno di
Flash ogni contenuto che viene presentato visivamente. Lo screen-reader dell’utente dovrebbe
essere avvisato che il programma ha funzionalità audio autonome in modo che lo screenreader viene posto in pausa mentre Flash si preoccupa di svolgere i suoi contenuti audio.
In tal caso, qualsiasi contenuto video importante deve essere fornito via audio, un’idea di come
realizzare questa funzionalità può essere intuita ascoltando la radiocronaca di un evento
sportivo.
Si potrebbe anche inserire una funzionalità audio autonoma con il compito di fornire
un’alternativa per una presentazione senza audio o offrire all’utente una opzione per attivare o
meno la parte audio.
- 388 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Ad ogni modo per qualsiasi contenuto audio fornito che non sia evidente dal video, occorre
fornire delle titolazioni per i disabili uditivi e la presentazione deve essere accessibile via
tastiera.
Un'altra procedura importante è fornire una alternativa equivalente all’intera presentazione
Flash. Questo è in particolar modo necessario quando la stessa presentazione non può essere
resa accessibile in nessun altro modo.
Sembra piuttosto difficile spiegare come una presentazione Flash multimediale possa essere
resa in maniera equivalente con un documento (X)HTML.
La cosa importante è rendere equivalente il contenuto alternativo, e questo non
necessariamente con l’impiego di solo testo.
Invece di fornire una pagina solo testo, l’equivalente potrebbe essere una pagina Web ben
presentata con immagini, icone, paragrafi e colori.
Il fatto che qualcuno acceda a questa pagina non implica che egli sia per forza disabile.
Spesso l’alternativa accessibile può essere nella stessa pagina dove si trova la presentazione
Flash. Talvolta si può anche dare all’utente la possibilità di disabilitare o meno i contenuti
Flash.
V.6 - Interviste
In una trattazione completa di questo problema non possono mancare le opinioni raccolte sul
campo, sia degli utenti disabili direttamente coinvolti nell’accesso alle informazioni internet, sia
degli operatori che si trovano a gestire e risolvere i problemi quotidiani dell’handicap.
Paolo de Cecco
CONSULENTE ESTERNO PER LE TECNOLOGIE D’AUSILIO PER LA LEGA DEL FILO D’ORO.
TRASCRIZIONE ED ADATTAMENTO DI UN INCONTRO TENUTOSI AD ANCONA IL 29 DICEMBRE 2006.
La conversazione si è tenuta con un breve colloquio informale, costituito da domande e
risposte. La sintesi qui riportata è stata riadattata e suddivisa per argomenti allo scopo di
facilitarne la stesura e la comprensione.
Gli strumenti di base
Uno dei primi ausili messi a disposizione per favorire l’interazione con il computer da parte
degli utenti non vedenti è stata la barra Braille.
La barra Braille è composta da un certo numero di celle disposte in orizzontale. Il Braille
codifica un carattere in un insieme di punti: il Braille classico è costituito da una sequenza
ordinata di 6 punti, suddivisi in due colonne verticali, la colonna di sinistra numerata da 1 a 3,
la colonna di destra numerata da 4 a 6.
- 389 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La singola cella è un rettangolo di un centimetro di altezza per mezzo centimetro di larghezza
circa.
Il Braille informatico è arricchito da due punti aggiuntivi in basso per un totale di 8 punti. Con
l’informatica, infatti, è giunta la necessità di codificare più informazioni e si usano due colonne
da 4 punti.
La scrittura di tutti i caratteri rimane basata sui 6 punti classici mantenuti anche con l’avvento
della nuova codifica. I due puntini in basso, il 7 e l’8, vengono usati per gli attributi, ad
esempio il 7 si usa per la maiuscola.
Nel Braille classico si definiva invece un carattere precedente segna-maiuscolo o segna-numero
che aveva il compito di precedere una cambiamento di significato del carattere successivo.
Questo può essere poco efficiente dal momento che le barre Braille standard sono di 40 o da
80 caratteri: i puntini aggiuntivi 7 ed 8 permettono di accorciare la lunghezza dei testi.
Altro utilizzo importante dei due punti aggiuntivi è l’evidenziazione del focus di Windows grazie
alla sottolineatura fornita proprio dai 2 puntini bassi.
La lunghezza standard di 40 ed 80 caratteri per le barre Braille è direttamente derivata dalla
originaria dimensione in caratteri degli schermi del computer nel sistema DOS, dove queste
barre sono originate.
Il software che si interfaccia, il cosiddetto screen-reader, ha come funzionalità di base quella di
seguire automaticamente il focus visualizzato sullo schermo.
Il computer viene usato impiegando anche la tastiera standard, ad esempio il tasto Windows
che permette di attivare il menu di avvio o le frecce per scegliere la voce che interessa.
L’uso della tastiera normale viene affiancato dalla barra Braille che viene posta al di sotto della
tastiera ordinaria al punto che qualche volta viene chiamata tastiera Braille. Le mani passano
dalla tastiera alla barra per leggere le informazioni del video.
La lettera “F” e la lettera “J” sono dotate di una sottolineatura in rilievo e un non vedente
riceve conferma dei tasti premuti con l’eco della tastiera mediante un sintetizzatore vocale.
In genere vengono utilizzati più ausili contemporaneamente, un software come uno screenreader è in grado di avere il controllo sia di una barra Braille che di un sintetizzatore vocale in
una stessa seduta di lavoro.
Tra gli screen-reader JAWS è oramai considerato uno standard, tra gli altri si ricordano HAL e
Windows Eyes.
Le differenze sono nel gruppo di lavoro che li sviluppa e li implementa. Un gruppo di lavoro più
significativo può garantire risultati più efficaci. JAWS ha già al suo interno una serie di script
predefiniti concepiti appositamente per le singole applicazioni.
Infatti, un conto è un funzionamento standard, un conto è quando ci si deve adattare ad una
particolare applicazione che impieghi, ad esempio, uno specifico controllo di Windows.
Lo screen-reader, quando viene lanciato, carica uno script di default. Ogni volta che viene
eseguita una applicazione viene verificato se esiste uno script con lo stesso nome
- 390 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
dell’applicazione, ed, in caso, questo viene automaticamente eseguito. Si può definire uno
script per ogni applicazione oltre che dei file di configurazione specifici.
Si potrebbe predisporre anche uno script che annulla o limita il funzionamento di JAWS. Questa
procedura è utile nel caso venga lanciato un applicativo che abbia già una sua sintesi vocale
interna.
In queste circostanze la sintesi vocale di JAWS può essere disabilitata e riattivata solamente
quando il focus ripassa ad un’altra applicazione che non abbia un suo sintetizzatore
proprietario.
Esistono poi dei video-ingranditori e dei software ingrandenti. I primi sono dei sistemi esterni
che permettono di ingrandire il testo cartaceo con una telecamera, possono eventualmente
essere visualizzati su un monitor o sul video del PC trasferendo la lettura esterna.
I software ingrandenti lavorano invece a stretta simbiosi con gli applicativi, per la maggiore va
lo ZoomText.
La SubVision, di Milano1, fornisce una valida assistenza sia per l’hardware sia per il software.
Il software
Nel settore dei non vedenti esistono alcuni software che nascono già con la sintesi vocale
interna. Ad esempio i programmi per la lettura dei testi con sistemi di OCR (Optical Character
Recognition). Si mette un foglio sullo scanner, viene fatta una scansione con un riconoscimento
dei caratteri e poi il testo viene passato alla sintesi vocale. In questo caso JAWS viene privato
dell’audio per evitare una sovrapposizione delle voci.
Una delle difficoltà abbastanza classiche che si possono incontrare è quella di trovarsi a
lavorare con delle applicazioni che hanno impiegato in fase di sviluppo degli oggetti e dei
controlli che non sono quelli standard di sistema, ad esempio un campo editor di testo che non
sia stato progettato con il classico oggetto box di Windows. In tal caso JAWS non riesce a
riconoscere la classe dell’oggetto. Tuttavia JAWS è abbastanza intelligente di proporre
all’utente, in questi casi, il migliore trattamento del componente, fornendo una elenco delle
classi che più potrebbero essere simili e permettendo all’utente di definirne le migliori modalità
di comportamento per somiglianze. Queste informazioni possono essere memorizzate e rese
permanenti.
JAWS è diventato uno standard d’utilizzo, con una enorme diffusione.
Le varie versioni hanno avuto il compito di seguire gli aggiornamenti del sistema operativo per
adeguarsi agli oggetti esposti.
1
[http://www.subvisionmilano.com/new/index.php]
- 391 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Da Windows Millenium in poi, nell’ambiente Microsoft, è possibile avere a disposizione alcune
libreria di interfaccia di sistema concepite appositamente per migliorare l’accesso degli screenreader. Un esempio di questa filosofia sono le MSAA (Microsoft Active Accessibility) API di
Windows.
All’atto dell’installazione di alcuni applicativi come gli screen-reader o i sistemi ingrandenti
viene verificata l’esistenza di queste API sulla macchina ed in caso contrario viene richiesto
espressamente di installarle.
Questo non solo per JAWS, ma anche per molte tecnologie assistive, in caso contrario molti
campi e molti menu non possono venir letti.
Per quanto riguarda i browser, Opera può essere considerato come uno dei più attenti dal
punto di vista della flessibilità. Per quanto sia un po’ fuori standard, sicuramente ha lavorato
parecchio sul fronte dell’accessibilità, tra Explorer e Firefox non cambia molto. Molto può
dipendere anche dall’adattabilità dello sviluppo dei pacchetti come JAWS ai singoli browser. In
questo senso risultano sicuramente facilitati i browser e gli applicativi che maggiormente
rappresentano uno standard.
Ad esempio per la posta elettronica, lo screen-reader riesce a riconoscere immediatamente il
campo del messaggio e lo legge automaticamente lavorando con Outlook Express. Questo non
è del tutto vero con altri client di posta, dove invece il contenuto viene riprodotto solo
parzialmente, probabilmente per un fatto di classi non riconosciute. Ad ogni modo in rete sono
rintracciabili script o patch per questi programmi che permettono a JAWS di interfacciarsi
anche con le classi esposte da questi applicativi.
L’impegno istituzionale
Ho partecipato recentemente ad un incontro organizzato dal MIT 1 che ha convocato le
associazioni di categorie al fine di verificare quale sia lo stato di avanzamento dei lavori in fatto
di accessibilità.
La legge Stanca lascia un buco nel fatto che esiste una clausola che vincola l’adeguamento del
sito in relazione alle disponibilità economiche dell’ente, e questo da il modo di evitare il lavoro
a chi non vuole far le cose.
L’idea, ad ogni modo, è quella di arrivare quanto prima ad avere tutti i siti dei ministeri
accessibili. Allo stato attuale delle cose non lo sono.
Il rappresentante dell’unione italiana cechi ad esempio lamentava che il sito ministeriale della
dichiarazione automatizzata dei redditi non risulta essere ancora accessibile.
1
Ministero per l’Innovazione e le Tecnologie
- 392 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
C’è sicuramente anche un problema di intercomunicazioni tra settori, ed anche questo
andrebbe risolto. Esistono diversi progetti ministeriali che sono poco coordinati fra di loro. Il
gruppo che ha sviluppato il sito della dichiarazione dei redditi non ha probabilmente avuto
contatti con il gruppo di sviluppo del CNIPA che invece avrebbe potuto offrire un supporto
competente a costo nullo.
Non si tratterebbe di fare cose in più, ma semplicemente in modo diverso, cambiando la
modalità progettuale.
L’obiettivo dell’incontro organizzato dal MIT era quello di creare una commissione che
lavorasse stimolando il coinvolgimento delle associazioni delle categorie interessate, con la
creazione di una commissione interministeriale al fine di rendere partecipi anche gli altri
ministeri e non solo quelli più tecnici. In questo modo si potrebbe evitare che il ministero delle
finanze, non ancora coinvolto in questo discorso, non abbia nemmeno una persona implicata
nel progetto.
La legge Stanca sta prendendo piede, per quanto molto lentamente, proprio per questo fine è
stata fondamentale la possibilità data agli enti pubblici di annullare gli appalti che non
rispettino i requisiti di accessibilità. In questo modo si hanno poi gli strumenti per poter
imporre alla ditta fornitrice la richiesta dell’accessibilità del sito acquistato.
Dopo l’approvazione della legge ci si sta muovendo, ma ancora c’è parecchia strada da fare.
Adesso si sta cercando di fare in modo che entro il 2010 tutti i ministeri dovrebbero
effettivamente avere un sito Web accessibile. Dovrebbe essere l’obiettivo anche per tutti i
numerosi enti coinvolti dalla legge: scuole, università, enti a partecipazione pubblica eccetera,
ma vista la vasta estensione del campione sembra una cosa piuttosto difficile. Ancora una volta
la scappatoia legale è quel vincolo sulle risorse economiche necessarie a cui si appella un
dirigente che non voglia impegnarsi.
Ad ogni modo una forte sensibilizzazione è stata certamente ottenuta, un primo passaggio c’è
stato, e questo lo si vede anche dalle sempre più diffuse dichiarazioni di compatibilità offerte
dalle ditte specializzate nelle forniture Web.
Da quando è entrata in vigore la legge Stanca qualcosa si è sicuramente messo in moto, sono
stati preparati molti siti progettati con maggiore cura. Per lo meno è in atto un tentativo di
miglioramento.
I siti Web
Ci vogliono degli ottimi designer delle pagine Web che sappiano anche ripensare il sito
mantenendo comunque una veste grafica interessante.
Stanno venendo fuori anche pacchetti CMS con un’attenzione notevole alla accessibilità.
Normalmente non vanno male, hanno delle strutture abbastanza definite e quindi si riesce a
navigare abbastanza bene nei siti da loro prodotti. Recentemente è stato reso disponibile un
pacchetto CMS gratuito mirato all’accessibilità.
- 393 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Altro discorso è l’adattamento dei posti di lavoro per l’accessibilità e l’inserimento del disabile
nel posto lavorativo. A volte si fa fatica persino a trovare solo un computer disponibile in un
inserimento lavorativo.
Ci sono sempre più persone non vedenti che, con consuetudine, esplorano il mondo del Web.
Ci sono persone non vedenti che sono solite navigare anche per delle ore.
Sicuramente l’uso della posta elettronica è più diffuso rispetto all’accesso al Web e il pacchetto
utilizzato è Outlook.
In questo ambiente, se la mail arriva in formato testo non esiste nessun tipo di problema a
leggerla, le difficoltà esistono per le strutture grafiche.
Attualmente quasi tutti gli screen-reader cercano di venire incontro ai problemi classici, come
ad esempio il fatto di avere una valanga di collegamenti ipertestuali in testa alla pagina.
Durante la navigazione con i strumenti di ausilio si ha necessariamente una esplorazione
sequenziale. Accedendo ad un sito ci si imbatte immediatamente nella parte di intestazione con
tutti i possibili collegamenti e questi devono essere letti tutti in sequenza. Un esempio evidente
sono i giornali in linea, la parte che interessa è quella centrale, navigando a vista si ha un
orientamento immediato e si può saltare immediatamente alla notizia che interessa. Navigando
invece con una barra Braille, accade che ad ogni caricamento della pagina lo screen-reader
incomincia ad esplorarla daccapo rileggendo tutto quello che si trovava già nella lettura
precedente. Si perde tempo con questo sistema.
Le barra Braille o il sistema vocale sono diventati con il tempo sicuramente più efficienti nel
trattamento di queste pagine, ma molto tempo viene ancora sprecato in queste letture
ripetitive.
In particolare le barre Braille hanno aggiunto dei piccoli tasti a lato che permettono di scorrere
in avanti, esplorando oltre il documento. Se si incomincia a leggere qualcosa già letto si può
saltare all’elemento successivo.
Ci sono poi delle funzioni di JAWS che permettono di saltare dei collegamenti. Con un tasto
funzione è possibile avere immediatamente l’elenco completo di questi e scorrere rapidamente
tra essi.
JAWS ha una funzione che ricerca i primi 25 caratteri privi di collegamenti ipertestuali sulla
pagina, ripetendo più volte questa funzione si riescono a rintracciare i blocchi di testo che
dovrebbero contenere solo le informazioni utili.
E’ possibile anche avere elencati i campi editor di un modulo presenti nella pagina e quindi
scegliere di entrare al loro interno.
Per fortuna qualche sito incomincia ad essere fatto un po’ meglio, grazie al posizionamento
opportuno di un collegamento iniziale che rimanda direttamente al contenuto. Questo salto può
essere nascosto alla vista con l’utilizzo di una opportuna classe dei CSS.
Salti di questo tipo sono fondamentali ed aiutano parecchio nella navigazione.
- 394 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Per quanto riguarda i moduli, il problema fondamentale è l’associazione fra l’etichetta ed il
campo di testo: non è sempre detto che lo screen-reader sia in grado di legarli correttamente.
Il fatto di mettere dentro dei caratteri di testo nei campi per identificarli non risulta di
particolare interesse. Sarebbe più immediato fornire un’informativa a parte su quello che si
dovrebbe inserire, ad ogni modo ci deve essere una etichetta associata prima.
Il lavoro che può fare in certi casi lo screen-reader è quello di verificare la posizione
dell’etichetta, mentre in HTML esistono gli elementi opportuni per associare correttamente una
etichetta al campo di inserimento.
A parte l’attenzione a disporre e collegare gli elementi, nei moduli non ci sono cose che
costituiscano un grosso ostacolo. Gli screen-reader normalmente riescono a gestire abbastanza
bene questi componenti.
Un altro elemento importante sono le descrizioni alternative delle immagini.
I problemi più grossi che può incontrare uno screen-reader nell’accesso alle pagine sono
tuttora le informazioni ancora vincolate esclusivamente alle immagini senza avere testo
corrispondente, come ad esempio un menu progettato solo per via grafica, trattato con delle
GIF senza testo alternativo o con testi alternativi non validi.
Un po’ per la grande diffusione dei CMS che lo inseriscono automaticamente, un po’ per una
maggiore sensibilizzazione, le cose stanno comunque migliorando anche in questo campo.
Le difficoltà comuni
Il primo problema per una persona disabile che si pone di fronte ad internet è quello della
esplorazione della struttura, per quello che stavamo dicendo prima. Il dramma è che l’utente si
aspetta di entrare in una pagina internet come se fosse di fronte ad un documento, si aspetta
di dare l’indirizzo e di ritrovarsi di fronte direttamente le informazioni richieste in primo piano.
Per fare questo dovrebbe in qualche maniera conoscere a priori com’è fatto il sito, che invece
diventa un labirinto dove doversi orientare e dove ogni pagina è impostata in un certo modo ed
ha una storia a se.
Uno standard di presentazione, per quanto non sia possibile in generale, potrebbe per lo meno
aiutare all’interno dello stesso sito.
I più svantaggiati sono le persone ipovedenti. La persona non vedente, in un certo senso, se
ha gli strumenti adeguati tipo la barra Braille ed uno screen-reader se la cava, bene o male,
soffre perché l’accesso è macchinoso, ma arriva alle informazioni.
L’ipovedente invece spesso non ha un sistema che gli converte in maniera accessibile quello
che c’è scritto nel sito e deve comunque leggerlo con gli occhi. Il fatto di avere dei testi che
non sono scritti in maniera accessibile complica notevolmente le cose.
Gli errori più gravi sono soprattutto i contrasti sbagliati, o il fatto non essere agganciati alla
modalità dei caratteri.
- 395 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Con un browser è possibile ridimensionare l’aspetto e scegliere di utilizzare un carattere più
grande o più piccolo, si possono impostare delle grandezze standard od in percentuale.
Da questo punto di vista molti siti permettono in aggiunta di scegliere un foglio di stile
personalizzato salvando su un cookies l’impostazione fatta. Ovviamente questa scelta è valida
solo per il sito che si sta visitando e va reimpostata, se consentito, di sito in sito. Questo
perché ogni autore può definire delle classi differenti nei CSS, utilizzando nomi differenti.
Un’opzione di questo tipo è molto utile quando sia già il sito a prevederla, dato che il foglio di
stile preferito dall’utente non è universalmente applicabile. In oltre si deve pensare di non
avere di fronte sempre persone che siano in grado di lavorare con disinvoltura sui browser,
costoro potrebbero non riuscire ad impostare autonomamente con facilità le loro preferenze
visive.
Spesso questa tipologia di utenti può avere anche delle difficoltà nella comprensione degli
stessi contenuti del sito, pensare di fargli fare delle attività ulteriormente complesse per poter
leggere le informazioni può scoraggiare la loro navigazione.
Occorrono dei fogli di stile mirati ed è meglio se questi vengano messi a disposizione
direttamente dal progettista del sito, magari quattro o cinque differenti ma senza esagerare: in
certi casi potrebbe essere persino controproducente scendere in ulteriori dettagli di
personalizzazione rendendo le cose troppo sofisticate e scoraggiandone l’uso, ad esempio, da
parte di una persona anziana.
In genere si presentano una serie di testi visualizzati con diverse modalità. La scelta del
visitatore è memorizzata in un cookie con il nome del file a cui si fa riferimento. Ogni pagina,
quando si apre, legge nel cookie della macchina quale sia il nome del file di stile prescelto e lo
preleva dal server. La scelta resta memorizzata fin quando sulla macchina non venga
cancellato il cookie relativo.
Un problema associato con queste tecniche è quello che possano richiedere a volte l’impiego
obbligato dei JavaScript, e questo viene sconsigliato nelle WCAG 1.0 per un motivo di
compatibilità con tutti i programmi utente.
Questo è vero in linea di massima, ma proprio per evitare che ci sia questa disaffezione nei
confronti dei siti accessibili, occorre dare la possibilità di usarli e di avere delle alternative che
siano fruibili.
L’importante è garantire la presenza di un comportamento alternativo.
Progetti futuri
Una nuova frontiera è quella dell’accesso tramite telefonia.
Ci sono attualmente in commercio delle barre Braille che lavorano con la tecnologia bluetooth.
Quando questi strumenti sono nelle vicinanze di un personal computer o di un telefono
portatile entrano in funzione.
- 396 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
La barra Braille proposta dalla Tiflosystem dispone di 6 tasti per scrivere e può fungere anche
per ingresso al computer, in tal caso si parla di tastiera dattilo-Braille. Con 3 dita della mano
destra e 3 della sinistra si riescono a simulare i 6 punti del Braille classico con la combinazione
delle 6 dita.
Sono in vendita anche dei palmari in Braille, utilizzabili con una piccola barra Braille bluetooth
separata. I telefoni sono impiegati soprattutto per gli SMS che possono essere inviati in modo
relativamente facile, in particolar modo se possiedono dei sistemi operativi come Symbian.
Un'altra prospettiva interessante è quella delle aree dei musei.
All’avanguardia sono gli studi per le visite guidate, mediante una barra Braille in
comunicazione bluetooth. Il visitatore può entrare nella sala dove il suo dispositivo viene
agganciato da un client di una rete informativa. A questo punto vengono passate le
informazioni come se ci si collegasse con una pagina Web. La tecnologie per queste
realizzazioni è già esistente.
Ancora più interessanti potrebbero essere dei trasmettitori bluetooth con un hardware che
riceve un segnale ed un codice identificativo che permette una localizzazione spaziale. Il
dispositivo poi, palmare o cellulare, fornito di un database geografico, può passare
l’informazione via sintetizzatore vocale o barra Braille all’utente. Può essere usato in un museo
o in un qualsiasi spazio fisico.
Un progetto presentato ad Handimatica 2006 prevedeva delle pasticche trasmittenti localizzate
nelle aree geografiche ed un ricevitore posizionato ad esempio in un classico bastone per non
vedenti collegato ad un palmare con sintesi vocale il quale a sua volta comunica le informazioni
via auricolare al non vedente al rilevamento del ricevitore sui segnalatori.
Il problema potrebbe essere quello di cablare l’area di interesse.
Interessanti sono pure le applicazioni del GPS con mappe localizzate sul cellulare con sintesi
vocale. Sono necessari un software di sintesi vocale ed un software di navigazione sul cellulare
con mappe di percorsi pedonali e numeri civici registrati.
I palmari con barra Braille o dattilo-Braille incominciano anche ad essere diffusi ed usati
soprattutto nelle scuole, ragazzi che frequentano l’università possono prendere anche gli
appunti delle lezioni.
Un apparecchio visto alla fiera Handimatica 2006 di Bologna era costituito da un avanzato
sistema di controllo oculare in cui il puntatore del mouse viene controllato con la pupilla.
Una prova personale è stata molto coinvolgente. Con una prima impostazione si regola
l’apparato alla fisiologia dell’utente, poi si punta un oggetto con la pupilla per qualche secondo.
In questo caso la parte fissata viene selezionata ed isolata in una zona a parte dello schermo,
a quel punto, riguardando e trattenendo lo sguardo nel punto definito si attiva il click.
Ad esempio, navigando sul Web è sufficiente fissare con lo sguardo il collegamento ipertestuale
a cui ci si vuole trasferire per qualche istante, quindi questo viene portato sulla destra e
riguardando sulla zona estratta viene richiamato il click.
- 397 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Allo stesso modo si può lavorare con una tastiera disegnata sullo schermo ed il sistema è
piuttosto preciso a seguito di una calibrazione iniziale. Il puntamento è gestito con un controllo
contemporaneo di ambedue le pupille ed una ricalibrazione accurata al millisecondo per i
movimenti della testa.
Costi
Questo apparecchio visto in fiera costava 19.000 euro, ma in commercio ne esistono di simili a
prezzi molto minori, ovviamente a qualità sostanzialmente inferiore, ad esempio quelli di un
puntatore oculare di qualità inferiore sono sui 2.500 euro. In tal caso però la testa dell’utente
deve rimanere immobile, non ci devono essere spasmi involontari.
I costi delle apparecchiature in generale si sono abbastanza abbassati, si parte dai 2.500 fino a
5.000 euro per un display Braille con tastiera bluetooth. Di questi circa 2.500 vengono passati
dal servizio sanitario nazionale. Quelli di base in pratica vengono dati gratuitamente, questo è
un diritto dell’assistito che deve solamente dimostrare di essere un non vedente.
Gli apparecchi in questione vengono considerati normalmente come protesi.
Quello che manca è la cultura, anche questo è un aspetto della riunione tenutasi con il
ministero: rispetto all’accessibilità il problema più grosso è la tecnologia assistiva.
Circa l’80% degli strumenti facilitatori che permettono l’accessibilità sono fuori dal
nomenclatore. Il nomenclatore è un elenco delle apparecchiature e delle protesi che possono
essere fornite ai disabili dalle ASL (Azienda Sanitaria Locale).
Ad esempio fanno parte di questa lista: la barra Braille, il software ingrandente, la sintesi
vocale. Software come JAWS non rientra, rientra la sintesi vocale ma screen-reader invece
come voce specifica non è contemplata.
In tal caso c’è un minimo che è passato come sintesi vocale. Uno screen-reader può costare
più di 1.400 euro, a seconda del sistema operativo per cui è stato progettato, di questi solo
500 circa sono passati come sintesi vocale. Senza contare che se poi si è interessati ad uno
strumento a parte di sintesi vocale, non si è più rimborsati giacché la cifra è stata già
impiegata per fornire, anche solo parzialmente, lo screen-reader.
Il nomenclatore è stato cambiato qualche anno fa, in precedenza c’erano i singoli codici con gli
importi fissi, adesso è la ASL a valorizzare il bene e a riconoscere il valore dell’ausilio. Alcune
ASL hanno fatto delle gare generiche con le ditte per i vari tipi di strumenti, acquistando
sempre dallo stesso fornitore, tuttavia i modelli in commercio di una singola tipologia di ausilio,
come ad esempio gli ingranditori, possono essere molto differenti.
In genere viene riconosciuto un rimborso fisso pagato dall’ASL a cui si deve aggiungere una
quota variabile a carico del disabile che può scegliere l’ausilio più adatto alla propria
menomazione.
- 398 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Questi apparecchi sono dati in comodato d’uso, il problema potrebbe sorgere quando il disabile
aggiunge una cifra personale. Ma normalmente non è mai successo che l’ausilio sia stato
richiesto indietro dall’ASL.
Va comunque considerato che alcune tecnologie possano essere riutilizzate quando non sono
più di aiuto all’utilizzatore. Un esempio sono gli strumenti a puntamento oculare di cui si è
parlato alla fiera di Bologna.
Gli strumenti avanzati
Per le persone che hanno problemi motori, la difficoltà di navigazione è relativa, una volta
trovato lo strumento giusto e la tecnologia assistiva adatta alla propria disabilità.
In genere un disabile motorio riesce ad usare il movimento della testa con un sistema di
puntamento realizzato con delle cuffiette con dei sensori sulla fronte che vengono rilevati da un
trasmettitore sullo schermo in modo di definire la distanza ed il movimento. Il click lo si può
fare con un soffio.
Questi sono strumenti abbastanza costosi, una nuova tecnologia utilizza una Web-Cam che
rileva un’immagine di base la quale viene processata per rilevare gli spostamenti, ad esempio
tracciando i movimenti di un bollino fluorescente posto come punto luminoso sulla fronte
dell’utilizzatore.
In questo caso siamo sui 400 euro, una tecnologia abbordabile.
Con questi strumenti si riesce ad avere il movimento del mouse, e si può accedere anche ad
una tastiera virtuale sullo schermo. Il discorso del click lo si può ottenere con il soffio ed è
spesso la cosa migliore riuscendo anche a simulare il trascinamento in maniera efficace.
Questi strumenti assistivi avanzati permettono di gestire il computer.
Dal punto di vista del progettista di siti Web non c’è un gran che da fare in più. Una delle cose
importanti è la gestione dello spazio sullo schermo, poiché l’occupazione dell’area visibile con
una tastiera virtuale può portare via molto spazio visivo. In questo caso una buona
progettazione della pagina ridimensionabile può aiutare nella fruibilità dell’applicazione.
Chi non riesce ad avere un movimento gestibile per una spasticità molto grave può avere a
disposizione della applicazioni che lavorano a scansione.
Ci sono dei sistemi organizzati in righe e colonne, con lettere disposte su file differenti. In
momenti successivi vengono evidenziate in sequenza le differenti righe, ognuna per un tempo
fisso. Agendo su un sensore che può essere un pulsante sullo zigomo o una palla che si può
colpire con un movimento, si fissa l’attenzione su quella riga. Una seconda scansione
temporale scorre le lettere della riga selezionata. Con due movimenti si riesce a scegliere la
lettera. Un sistema lungo ma funzionale.
Esistono anche dei joystick accuratamente regolabili per avere dei movimenti inerziali o
bloccati su un singolo asse. Altre cose molto utili possono essere le impostazioni fornite da
- 399 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Windows nel pannello di controllo per l’accessibilità, sono strumenti che spesso la gente ignora
ma risultano utili in alcuni casi, e sono immediatamente disponibili con il sistema operativo.
Tra gli altri sono impostabili il ritardo della battitura e le opzioni per i tasti premuti
contemporaneamente. Tastiere espanse e facilitate possono essere utilmente affiancate da
questi filtri di ingresso.
Per quanto riguarda i sistemi operativi, su Linux esistono dei progetti e ci sono delle soluzioni
poco conosciute e poco utilizzate soprattutto perché sono poche le persone disabili che si
avvicinano a questo sistema operativo. Il mondo dell’accessibilità si rivolge essenzialmente a
Windows.
I sistemi di ausilio in genere hanno le loro interfacce hardware e possono connettersi con
qualunque sistema operativo ad ogni modo non sono al corrente di uno screen-reader per
MacIntosh, Windows rimane il punto di riferimento.
Sarebbe sicuramente un fatto positivo se Microsoft fosse abbastanza attenta da comprare la
Freedom Scientific ed integrare le risorse nel sistema operativo. Non si vede il motivo per cui
un non vedente deve spendere tutta quella cifra per accedere al sistema.
Ad ogni modo la comunità dei disabili è abbastanza motivata e le persone non si fermano
davanti alla spesa, normalmente sono molto attente alle tecnologie.
Ad esempio ad Handimatica 2006 c’erano moltissimi non vedenti tutti attentissimi alla
tecnologia innovativa, al punto che la maggior parte dei visitatori erano disabili.
In Italia
La legislazione che abbiamo è valida, rispettare le norme definite andrebbe benissimo, anche al
livello europeo siamo all’avanguardia. Non ha molto senso rimettere in discussione le
procedure di legge, la parte in cui probabilmente siamo indietro è quella della corretta
distribuzione e quella della produzione di apparecchiature assistive.
La mostra Handimatica di Bologna è un po’ un centro da questo punto di vista, è l’evento
culmine, visto che in Italia c’è solo questo incontro per le tecnologie assistive.
La globalizzazione, ad ogni modo, ha sortito i suoi effetti positivi anche in questo campo. Tutto
quello che c’è sul mercato internazionale è facilmente reperibile, tuttavia in Italia come
produttori di ausili non ci sono grosse realtà.
Barre Braille ed altri strumenti assistivi sono prodotti tutti all’estero, Germania, America,
Spagna. All’estero ci sono spesso dei grossi contributi, meno in termini monetari e più in
termini di servizi che vengono direttamente forniti all’utenza. L’intervento è mirato sulla
persona e quindi il mercato è più fecondo.
In Italia c’è una ditta di Bologna che ha iniziato a fare qualche timido progetto di ausilio tipo
tastiere ed interfacce per sensori. Ci aveva provato per una barra Braille la Tiflosystem di
Padova, una ditta tra le prime ad interessarsi alla distribuzione qui da noi degli strumenti
assistivi.
- 400 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Pur lamentando una certa mancanza di produttori, tuttavia ci sono comunque le ditte
specializzate per sviluppo di software, formazione ed assistenza.
Vale la pena ricordare anche il sito del SIVA 1 per informazione e consulenza nel campo delle
tecnologie di ausilio alla riabilitazione, che ha a disposizione una banca dati degli strumenti a
disposizione per l’accessibilità.
Vale la pena fare un accenno anche all’assistenza fornita al disabile per la ricerca e la
identificazione della migliore apparecchiatura assistiva per la propria menomazione.
Spesso è anche molto difficile recuperare quello che è più indicato.
Non è una cosa così semplice valutare lo strumento adatto, quale ausilio potrebbe essere il più
efficace ed il più facilmente utilizzabile.
Ci sono delle strutture, dei centri di valutazione che permettono questo tipo d’analisi.
A Bologna esiste Ausilioteca2, qui lavora una equipe multi-disciplinare per l’assistenza agli
utenti. Ma centri di questo tipo ne esistono anche altri, all’interno delle strutture ospedaliere e
delle regioni.
Una guida di questo tipo è fondamentale per il disabile, il rischio concreto è che si spendano
tanti soldi per avere uno strumento inutile per l’impossibilità di sfruttare la risorsa fornita.
Non sono mai o quasi mai sistemi chiavi in mano. Queste tecnologie richiedono una
valutazione accurata prima e molto spesso anche un sufficiente periodo di addestramento e di
taratura in opera, sfruttando anche l’opzione del collaudo che permette di restituire lo
strumento entro un tempo ragionevole nel caso non risulti idoneo.
1
2
Servizio Informazioni e Valutazione Ausili: [http://www.siva.it/retesiva/default.htm]
[http://www.ausilioteca.org/]
- 401 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
VI. Un esempio reale
L’idea originaria di questa sezione era di portare delle esemplificazioni pratiche del concetto di
accessibilità, mutuandole dalla personale esperienza lavorativa.
Il mio attuale incarico professionale, infatti, è quello di lavorare all’ufficio informatico del
Comune di Novate Milanese, una piccola città di circa 20.000 abitanti alla periferia di Milano.
Un primo progetto era partito con i responsabili del settore per la messa a norma del sito
comunale a seguito della legge Stanca. Un duplice interesse ci muoveva verso questa
soluzione, da una parte l’esigenza di regolare il proprio sito istituzionale spendendo il meno
possibile, dall’altra il desiderio di dare una svolta pratica a quanto appreso in questa tesi.
Nonostante questa duplice finalità, il progetto tuttavia non è andato a buon fine, a testimoniare
la scarsa o scarsissima attenzione per la questione accessibilità da parte di molte delle
amministrazioni comunali.
Infatti, visto che non sembrano esserci particolari rischi o controindicazioni di sorta, il
responsabile di area ha deciso di soprassedere completamente alla questione decidendo di
destinare anche quelle poche risorse economiche preventivate per altri fini.
A tutt’oggi il sito del Comune di Novate Milanese ha completamente disatteso la legge Stanca
ed è ampiamente fuori norma.
Tuttavia l’idea di dare un’esemplificazione concreta alla numerosa mole d’informazioni raccolta
in questo lavoro mi è sembrata sufficientemente pressante da decidere di dedicare comunque
una sezione della tesi ad un esempio concreto di codice accessibile.
A tal fine, in accordo con il relatore, abbiamo deciso di sfruttare una presentazione sintetica del
lavoro che originariamente doveva essere redatta in PowerPoint, e di produrla invece con delle
pagine XHTML accessibili.
VI.1 - Presentazione in XHTML
Vista la relativa semplicità e schematizzazione del contenuto da esporre, la scelta del
linguaggio è caduta sul più rigoroso degli HTML, l’XHTML 1.1, in attesa che venga presentata la
documentazione ufficiale del XHTML 2.0.
La maggior cura possibile è stata presa per produrre delle pagine di qualità.
Ad ogni modo, essendo la prima scrittura di codice accessibile, sicuramente esso conterrà
imperfezioni e scorrettezze.
Anche per questo ho deciso non accludere alla pagina alcuna dichiarazione di compatibilità con
le WCAG o con la legge Stanca. Non certo perché non sia di mia intenzione ambirvi, quanto
piuttosto perché l’accessibilità, come più volte ripetuto nel lavoro, è una metodologia di lavoro
ed una qualità a cui mirare piuttosto che un bollino da far comparire in fondo alla pagina.
- 402 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Progetto
Il documento si articola su 5 pagine HXTML:
Index: una pagina introduttiva di presentazione del lavoro;
Scenario: corrisponde alla sintesi dell’omonimo capitolo di questo testo;
Metodologie: racchiude le metodologie generali esposte;
Tecniche: presenta le tecniche fondamentali consigliate;
Normative: espone in maniera sintetica le quattro normative ed una tabella sinottica.
Sono presenti poi 3 fogli di stile, il primo dei quali funge da configurazione base ed è incluso e
modificato dagli altri due:
Base: contiene le impostazioni di base, è incluso negli altri e si avvale delle
configurazioni di sistema per rendere la presentazione;
Presentazione: apporta delle modifiche al foglio base in modo da realizzare per quanto
possibile una presentazione più gradevole;
Contrasto: apporta delle modifiche al foglio base per realizzare una visualizzazione a
caratteri ingranditi ed alto contrasto in modo da venire incontro alle esigenze degli
ipovedenti.
La versione del progetto riportata è quella prodotta fino alla metà del Febbraio 2007.
Attualmente è pubblicata e consultabile sotto il sito del Comune di Novate Milanese1, ma è
molto probabile che nei prossimi mesi venga trasferita o rimossa.
Codice XHTML
Di seguito riporto, a titolo esemplificativo, una delle pagine. Ho scelto un compromesso tra
quella che avesse un codice relativamente breve da poter essere riportato mantenendo
comunque una sufficiente significatività.
Sono state fatte alcune modifiche al testo per poterlo impaginare al meglio in questo
documento.
Scenario
Vediamo alcune caratteristiche di base che sono state implementate per raggiungere la
migliore accessibilità possibile:
1
[http://www.comune.novate-milanese.mi.it/test/acs/tesi/]
- 403 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Dichiarazione di grammatica formale:
Viene usata per garantire la conformità agli standard del W3C, è stato scelto il
linguaggio XHMTL 1.1;
Definizione del linguaggio naturale:
Lingua italiana, permette indicizzazioni e letture corrette degli screen-reader;
Uso di fogli di stile multipli:
Uno principale e gli altri secondari. Consente di far scegliere l’aspetto di impaginazione
più consono all’utente. In questo codice ci si basa sulla capacità del browser per poterli
attivare come richiamato nelle UAAG.
Definizione delle relazioni fra i documenti:
Permette una migliore indicizzazione automatica delle pagine per i browser e i robot sul
Web;
Impaginazione senza tabelle:
Non è strettamente necessaria, ma l’uso del DIV può consentire una migliore flessibilità
e pulizia. In effetti, proprio grazie a questa metodologia, il foglio di stile ad elevato
contrasto ridefinisce la presentazione formattandola a colonna unica. Le tabelle, quando
sono state usate in uno dei 5 documenti, sono corredate dei necessari attributi SUMMARY
e TITLE, in oltre sono dotate degli attributi che consentono le definizioni delle relazioni
fra le celle di intestazione e quelle di semplice contenuto;
Aspetti di impaginazione rimossi dal documento XHTML a favore dell’uso dei fogli di stile
ad eccezione della definizione in pixel delle dimensione delle immagini presenti. Questa
tecnica è consigliata ed applicata dallo stesso W3C in quanto sveltisce l’elaborazione
della pagina e la gestione dell’immagine all’interno del browser;
Uso degli elementi gerarchici di intestazione H1..H6;
Utilizzo degli elementi presentazionali e strutturali per definire la corretta gerarchia del
contenuto e la semantica delle relazioni fra le parti;
Posizionamento del menu di guida della pagina come prima informazione facilmente
scavalcabile con dei collegamenti ipertestuali diretti al contenuto informativo e al menu
generale;
Impiego degli ACCESSKEY;
Impiego di segnalazioni di fine lista non visibili con un browser testuale in modo da
offrire meccanismi di orientamento alla navigazione dei menu per gli screen-reader;
Utilizzo di acronimi ed abbreviazioni;
Impiego di liste di navigazioni a menu orizzontale per i livelli interni di informazione:
Serve per garantire il miglior ausilio alla navigazione possibile per tutti i browser non
visuali;
Impiego dell’attributo TITLE per tutti i collegamenti interni ed esterni:
Garantisce all’utente il più completo contenuto informativo possibile in modo da
- 404 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
permettergli di valutare l’interesse del collegamento e di non spiazzarlo nei cambi di
contesto;
Utilizzo degli elementi BLOCKQUOTE, CITE e Q per definire il contenuto citato da altre fonti.
Questi marcatori non sono utilizzati a fini di impaginazione;
Segnalazione dei cambi di lingua nel documento, per permettere agli screen-reader la
corretta lettura del testo;
Aggiunta dei collegamenti ipertestuali ai validatori del W3C, per la validazione
automatica delle pagine.
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="it">
<head>
<title>Normative, Metodologie e tecniche per l'accessibilit&agrave;:
Scenario</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta http-equiv="Content-Language" content="it" />
<meta name="keywords" content="Web accessibilità tesi Ancona Università WCAG
Moreschi" />
<meta name="description" content="Presentazione della tesi di laurea: scenario"
/>
<meta name="generator" content="CSE HTML Validator Lite" />
<meta name="author" content="Angelo Moreschi" />
<link href="css/presentazione.css" title="Presentazione" rel="stylesheet"
type="text/css" />
<link href="css/contrasto.css" title="Contrasto" rel="alternate stylesheet"
type="text/css" />
<link href="css/base.css" title="Sistema" rel="alternate stylesheet"
type="text/css" />
<link rel="Next" href="metodologie.html" title="Metodologie di base" />
<link rel="Prev" href="presentazione.html" title="Presentazione" />
<link rel="Home" href="presentazione.html" title="Presentazione" />
</head>
<body xml:lang="it">
<div class="intestazione">
<img id="stemma" alt="Universit&agrave; Politecnica delle Marche:"
src="img/logoUniv.png" height="120" width="120" />
<strong id="testoTitolo">Normative, metodologie e tecniche progettuali per la
realizzazione di siti Web ad elevata accessibilit&agrave;</strong>
</div>
<div class="corpo">
<hr />
<div class="titoloSezione">
<h1>II. Scenario</h1>
</div>
<div class="guida" >
<div id="sCapitolo">
<h2>Sommario</h2>
- 405 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
<ul>
<li>[0]&nbsp;&nbsp;<a href="#sWeb" accesskey="0">Pagine Web</a></li>
<li>[1]&nbsp;&nbsp;<a href="#accessibilita"
accesskey="1">Accessibilit&agrave;</a></li>
<li>[2]&nbsp;&nbsp;<a href="#usabilita" accesskey="2">Usabilit&agrave;</a></li>
<li>[3]&nbsp;&nbsp;<a href="#disabilita"
accesskey="3">Disabilit&agrave;</a></li>
<li>[4]&nbsp;&nbsp;<a href="#w3c" accesskey="4"><abbr
xml:lang="en">W3C</abbr></a><span class="finelista"> (Fine Sommario
Capitolo)</span></li>
</ul>
</div>
<div id="sWeb">
<h2>Pagine Web</h2>
<ul>
<li><a href="index.html" title="Apertura capitolo
indice">Presentazione;</a></li>
<li><span title="capitolo corrente">Scenario</span></li>
<li><a href="metodologie.html" title="Apertura capitolo successivo">Metodologie
di base</a></li>
<li><a href="tecniche.html" title="Apertura altro capitolo">Tecniche
specifiche</a></li>
<li><a href="normative.html" title="Apertura ultimo capitolo">Normative</a><span
class="finelista"> (Fine Sommario Generale)</span></li>
</ul>
</div>
</div>
<div class="contenuto">
<div class="scheda" id="accessibilita">
<h2 >Accessibilit&agrave;</h2>
<blockquote cite="http://www.w3.org/WAI/"><p xml:lang="en" title="La potenza del
Web risede nella sua universalit&agrave; l'accesso da parte di chiunque
indipendentemente dalle sue disabilit&agrave; &egrave; un suo aspetto
essenziale.">The power of the Web is in its universality. Access by everyone
regardless of disability is an essential aspect.<br /><cite>(Tim BernersLee)</cite></p></blockquote>
<div class="navOriz">
<ul>
<li><a href="#usabilita" title="usabilit&agrave;">Successivo</a></li>
<li><a href="#w3c" title="W3C">Ultimo</a></li>
<li><a href="#sCapitolo" title="sommario">Sommario</a></li>
</ul>
</div>
<p class="x-risalto"><cite>Definizione di accessibilit&agrave; della legge
Stanca</cite>: <q cite="http://www.pubbliaccesso.gov.it/">La capacit&agrave; dei
sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze
tecnologiche, di erogare servizi e fornire informazioni fruibili, senza
discriminazioni, anche da parte di coloro che a causa di disabilit&agrave;
necessitano di tecnologie assistive o configurazioni particolari.</q></p>
<p>Applicare l'accessibilit&agrave; ai siti Web:</p>
<ul>
<li>Obiettivo: garantire la pi&ugrave; ampia base possibile di accesso per:
<ul>
<li>Utenti affetti da disabilit&agrave;;</li>
<li>Utenti dotati di strumenti (<span xml:lang="en" title="Programmi
utente">user agent</span>) specifici od obsoleti;</li>
</ul>
- 406 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
</li>
<li>Metodo: <q>rendere il sito accessibile alla tecnologia usata dagli utenti
per renderlo accessibile agli utenti.</q><cite> (Jim Byrne);</cite></li>
<li>Tecniche: rispetto dei lunguaggi standard <abbr xml:lang="en" title="World
Wide Web Consortium">W3C</abbr> e delle regole del <q
cite="http://diodati.org/scritti/2004/guida/ele_acc07.asp">buon sviluppo</q>
contrapposte al sistema tradizionale di progettazione.</li>
</ul>
</div>
<div class="scheda" id="usabilita">
<h2 >Usabilit&agrave;</h2>
<div class="navOriz">
<ul>
<li><a href="#disabilita" title="disabilit&agrave;">Successivo</a></li>
<li><a href="#accessibilita" title="accessibilit&agrave;">Precedente</a></li>
<li><a href="#accessibilita" title="accessibilit&agrave;">Primo</a></li>
<li><a href="#w3c" title="W3C">Ultimo</a></li>
<li><a href="#sCapitolo" title="sommario">Sommario</a></li>
</ul>
</div>
<p class="x-risalto"><cite>Definizione ISO 9241</cite>: <q
cite="http://www.usability.gov/basics/whatusa.html">Grado in cui un prodotto
pu&ograve; essere usato da particolari utenti per raggiungere certi obiettivi
con efficacia, efficienza e soddisfazione in uno specifico contesto
d'uso.</q></p>
<p>Collegamenti con l'accessibilit&agrave;:</p>
<ul>
<li>L'interazione e sovrapposizione con l'accessibilit&agrave; &agrave; molto
stretta, soprattutto per le ultime tre raccomandazioni <acronym xml:lang="en"
title="Web Content Accessibility Guidelines">WCAG</acronym>;</li>
<li>Ci sono differenze nelle metodologie di realizzazione e di controllo (test
con gli utenti vs. validatori automatici);</li>
<li>Le due discipline possono essere integrate al servizio della
fruibilit&agrave; (<cite>Luca Mascaro:</cite> <q>fruibilit&agrave; =
usabilit&agrave; applicata sulla accessibilit&agrave;)</q>.</li>
</ul>
</div>
<div class="scheda" id="disabilita">
<h2>Disabilit&agrave;</h2>
<div class="navOriz">
<ul>
<li><a href="#w3c" title="W3C">Successivo</a></li>
<li><a href="#usabilita" title="usabilit&agrave;">Precedente</a></li>
<li><a href="#accessibilita" title="accessiblit&agrave;">Primo</a></li>
<li><a href="#w3c" title="W3C">Ultimo</a></li>
<li><a href="#sCapitolo" title="sommario">Sommario</a></li>
</ul>
</div>
<p>L'Organizzazione Mondiale della sanit&agrave;, nel documento <acronym
xml:lang="en" title="World Health Organization">WHO</acronym> <acronym
xml:lang="en">ICDH</acronym>-1 del 1980, ha definito:</p>
<dl>
<dt>Menomazione</dt><dd>perdita o anomalia a carico di una struttura
corporea</dd>
<dt>Disablit&agrave;</dt><dd>perdita della capacit&agrave; di compiere
attivit&agrave; nel modo normale</dd>
<dt>Handicap</dt><dd>condizione di svantaggio conseguente a menomazione o a
disabilit&agrave;</dd>
- 407 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
</dl>
<p>Le disabilit&agrave; si possono suddividere in:</p>
<ul>
<li>sensoriali;
<ul>
<li>visive;</li>
<li>uditive;<span class="finelista"> (Fine lista sensoriali)</span></li>
</ul>
</li>
<li>motorie;</li>
<li>cognitive.</li>
</ul>
<p>Le tecnologie di ausilio assistono queste disabilit&agrave; nell'accesso al
Web con barre <span xml:lang="fr">Braille</span>, lettori di schermo,
ingranditori eccetera.</p>
</div>
<div class="scheda" id="w3c">
<h2><abbr xml:lang="en">W3C</abbr>: World Wide Web Consortium</h2>
<blockquote cite="http://www.w3.org/WAI/"><p title="Portare il Web al suo pieno
potenziale">Lead the Web to its full potential.<br /><cite>(<abbr
xml:lang="en">W3C</abbr>)</cite></p></blockquote>
<div class="navOriz">
<ul>
<li><a href="#disabilita" title="disabilit&agrave;">Precedente</a></li>
<li><a href="#accessibilita" title="accessibilit&agrave;">Primo</a></li>
<li><a href="#sCapitolo" title="sommario">Sommario</a></li>
</ul>
</div>
<p>E' un consorzio internazionale, neutrale rispetto ai venditori, che, grazie
al contributo dei suoi membri, guida l'evoluzione del Web, definendo protocolli
comuni.<br />Per l'accessibilit&agrave; &egrave; stato istituito il gruppo <a
href="http://www.w3.org/WAI/" title="Apertura sito WAI in inglese"><acronym
xml:lang="en">WAI</acronym></a>: <span xml:lang="en">Web Accessibile
Initiative</span>.</p>
<p>Attivit&agrave; del <abbr xml:lang="en">W3C</abbr> - <acronym xml:lang="en"
title="Web Accessible Initiative">WAI</acronym>:</p>
<ul>
<li><strong><acronym xml:lang="en">WCAG</acronym></strong> - <span
xml:lang="en">Web Content Accessibility Guidelines:</span><br /> Spiegano agli
autori come creare pagine Web accessibili;</li>
<li><strong><acronym xml:lang="en">UAAG</acronym></strong> - <span
xml:lang="en">User Agent Accessibility Guidelines:</span><br /> Spiegano come
rendere i programmi utente (<span xml:lang="en">user agent</span>) accessibili
per le persone disabili;</li>
<li><strong><acronym xml:lang="en">ATAG</acronym></strong> - <span
xml:lang="en">Authoring Tool Accessibility Guidelines:</span><br /> Spiegano
come rendere accessibili gli stessi strumenti di sviluppo in modo che possano
essere utilizzati dalle persone disabili e come possano essere progettati per
creare contenuti accessibili;</li>
<li><strong><acronym xml:lang="en">ARIA</acronym></strong> - <span
xml:lang="en">Accessibile Rich Internet Applications:</span><br /> Spiegano agli
sviluppatori come rendere maggiormente accessibile il Web dinamico.</li>
</ul>
<p>Metodologia normativa del <abbr xml:lang="en">W3C</abbr>:</p>
<dl>
<dt xml:lang="en">Working Draft</dt><dd> Documento reso noto per essere valutato
dalla comunit&agrave;;</dd>
<dt xml:lang="en">Last Call Working Draft</dt><dd> Documento che si ritiene
abbia avuto un consenso sufficiente;</dd>
- 408 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
<dt xml:lang="en">Candidate Recommendation</dt><dd> Un periodo durante il quale
la specifica viene revisionata ed implementata sul campo;</dd>
<dt xml:lang="en">Proposed Recommendation</dt><dd> Documento proposto per
divenire una raccomandazione ufficiale una volta ottenute sufficienti
implementazioni;</dd>
<dt xml:lang="en">Recommendation</dt><dd> Raccomandazione ufficiale del <abbr
xml:lang="en">W3C</abbr></dd>
</dl>
<p>Durante suo percorso di sviluppo un documento pu&ograve; ritornare ad una
fase precedente per eventuali revisioni.</p>
</div>
<div class="scheda" id="finale">
<div class="navOriz">
<ul>
<li><a href="#w3c" title="W3C">Precedente</a></li>
<li><a href="#accessibilita" title="accessibilit&agrave;">Primo</a></li>
<li><a href="#sCapitolo" title="sommario">Sommario</a></li>
</ul>
</div>
</div>
</div>
</div>
<div class="piepagina">
<hr />
<p>
<a href="http://validator.w3.org/check?uri=referer"><img src="img/valid-xhtml11blue.png" alt="Valid XHTML 1.1!" height="31" width="88" /></a>
&nbsp;
<a href="http://jigsaw.w3.org/css-validator/"><img src="img/valid-css-blue.png"
alt="Valid CSS!" height="31" width="88" /></a>
</p>
<p>Angelo Moreschi<br />Revisione 0.1 - Febbraio 2007</p>
</div>
</body>
</html>
Codice CSS
Il codice dei CSS è suddiviso tra un foglio di stile di base che contiene le impostazioni
fondamentali ed i colori di sistema, e dei fogli aggiuntivi specifici che permettono di presentare
la pagina a seconda delle esigenze dell’utente.
Come illustrato in precedenza nel codice non è stato incluso lo script per cambiare i fogli di
stile. Come da raccomandazioni UAAG, questo dovrebbe essere incluso nei browser, come in
effetti accade, ad esempio in Firefox e Opera.
Come nel caso del codice XHTML sono stati fatti gli opportuni adattamenti di impaginazione per
consentire la migliore leggibilità in queste pagine.
Gli accorgimenti principali che sono stati presi per rendere una migliore accessibilità con i fogli
di stile sono:
- 409 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
Impiego di fogli di stile esterni comuni per tutti i 5 documenti della presentazione;
Definizione di fogli di stile alternativi selezionabili dall’utente;
Impiego dei caratteri e dei colori di sistema nel foglio di stile base per adattare
automaticamente la presentazione nel browser alle impostazioni di sistema preferite
dall’utente. Queste scelte sono state poi soprascritte per i fogli di stile di presentazione
ed a contrasto elevato;
Definizione di un foglio di stile per ipovedenti che:
o
Impagina il documento a colonna singola;
o
Definisce colori ad elevato contrasto al fine di aumentare la leggibilità;
o
Ingrandisce la dimensione del font di caratteri;
Scelta di font leggibili e, con motivate eccezioni, senza grazie;
Uso delle dimensioni relative per l’impaginazione (percentuali) e per i caratteri (em);
Impaginazione fluida e ridimensionabile, in modo da adattarsi alla larghezza degli
schermi e delle pagine;
Definizione di uno stile nascosto per contenere le informazioni che non devono essere
mostrate dai programmi utente grafici;
Definizione di uno stile per i menu di navigazione orizzontali implementati tramite liste
non ordinate.
CSS Base
/* Normative, metodologie e tecniche progettuali per la realizzazione di siti
Web ad elevata accessibilità */
/* Foglio di stile base */
/* ****** link ******** */
a:active, a:hover, a:focus {font-weight: bold;}
/* ******************
elementi XHTML *************** */
pre {font-family: monospace;}
html, body {background-color: AppWorkspace;}
p {background-color: transparent; }
blockquote p {text-align: right;}
q {font-style: italic;}
dl {border: thin solid WindowFrame; padding: 1em; margin-top: 0em;}
/* ******************
classi base *************** */
/* intestazione di pagina */
.intestazione {color: CaptionText; background-color: ActiveCaption; clear:
both;}
/* corpo */
.corpo {padding-top: 0.1em; clear: both;}
- 410 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
/* piede della pagina */
.piepagina {color: InfoText; background-color: InfoBackground; font-size:
smaller; clear: both; text-align: center; padding: 0.2em;}
/* ******************
liste di navigazione *************** */
/* Guida principale */
.guida {float: left; clear: left; width: 28%; margin-right: 1%;}
.navOriz {color: InfoText; background-color: InfoBackground; }
.navOriz ul {list-style: none; border-bottom: 1px dashed; border-top: 1px
dashed; border-color: ButtonShadow; }
.navOriz ul li {margin-right: 1em; text-align: center; display: inline;}
.navOriz a {text-decoration: none;}
.finelista {display: none;}
#sCapitolo, #sWeb {color: InfoText; background-color: InfoBackground; marginbottom: 1em; padding: 1em;}
#sCapitolo ul li {list-style-type: none;}
#sCapitolo a {text-decoration: none;}
/* ******************
corpo *************** */
/* elemento nascosto */
.nascosto {display: none; visibility: hidden; overflow: hidden;}
/* contenuto informativo */
.contenuto {float: right; clear: right; width: 70%; background-color:
transparent;}
/* titolo della pagina */
.titoloSezione {color: InfoText; background-color: InfoBackground; float: none;
text-align: left; clear: both;}
/* slides */
.scheda {color: ButtonText; background-color: ButtonFace; margin-bottom: 1em;
padding: 1em;}
/* evidenziazioni */
.risalto {border: thin solid WindowFrame; margin-left: 2%; margin-right: 2%;
padding: 0.5em;}
.x-risalto {border: thin dashed WindowFrame; margin-left: 5%; margin-right: 5%;
padding: 1em;}
.xx-risalto {font-size: 1.25em; border: thin dotted WindowFrame; margin-left:
10%; margin-right: 10%; padding: 1em;}
.illustrazioni {text-align: center;}
.tblComparazione {padding-top: 1em; padding-left: 0.1em;}
.testariga {text-align: left;}
/* ******************
id
comuni *************** */
#stemma {float: left; margin-right: 1em; vertical-align: top;}
#testoTitolo {font-size: 2em; vertical-align: super;}
/* ******************
id specifici *************** */
#titoloTesi {text-align: center; font-size: 2em;}
#autoreTesi {text-align: right; margin-bottom: 3em;}
- 411 -
ERROR! USE THE HOME TAB TO APPLY TITOLO 1 TO THE TEXT THAT YOU WANT TO
APPEAR HERE.ERROR! USE THE HOME TAB TO APPLY TITOLO 2 TO THE TEXT THAT YOU WANT TO APPEAR
CSS Presentazione
/* Normative, metodologie e tecniche progettuali per la realizzazione di siti
Web ad elevata accessibilità */
/* Foglio di stile correttivo per presentazione */
/* importazione delle specifiche del foglio base */
@import "base.css";
/* ****** link ******** */
a:link {color: navy;}
a:visited {color: purple;}
a:active, a:hover, a:focus {color:blue;}
/* ****************** elementi XHTML *************** */
h1, h2, h3, h4, h5, h6 {font-family: Verdana, Geneva, Arial, Helvetica, sansserif;}
html, body {background-color: navy; font-size: 1em; font-family: "Trebuchet ms",
Verdana, sans-serif;}
blockquote p {font-family: monospace;}
hr {color: yellow; background-color: yellow; height: 1px;}
dl {border-color: navy;}
/* ****************** classi base *************** */
.intestazione {color: yellow; background-color: transparent;}
.piepagina {color: white; background-color: transparent; font-family: Georgia,
Garamond, "Times New Roman", Times, serif;}
/* ****************** liste di navigazione *************** */
.navOriz {color: black; background-color: silver; font-family: "Gill sans mt",
"Gill sans", "Trebuchet ms", sans-serif;}
.navOriz ul {border-color: purple;}
![Deliberazione [____] - Autorità per l`energia elettrica e il gas](http://s1.studylibit.com/store/data/000271583_1-c8234c3c502839ebd53a26a5bd3d2a6b-300x300.png)
