istituto superiore di sanitÀ - old.iss.itold.iss.it/binary/publ/cont/08-31_web.1226495275.pdf ·...

ISSN 1123-3117 Rapporti ISTISAN

08/31

ISTITUTO SUPERIORE DI SANITÀ

Valutazione di accessibilità dei siti web: il processo operativo dell’Istituto Superiore di Sanità

Carla Faralli (a), Marco Ferrari (a), Stefano Guderzo (a), Simona Deodati (a), Mario Didomenicantonio (b), Erminia Attaianese (c), Maurizio Boscarol (d),

Claudio Di Benedetto (a), Eugenio Morassi (a)

(a) Servizio Informatico, Documentazione, Biblioteca ed Attività Editoriali, Istituto Superiore di Sanità, Roma

(b) Presidenza del Consiglio dei Ministri, Roma (c) Unità di Ricerca LEAS, Laboratorio di Ergonomia Applicata e Sperimentale

Dipartimento di Configurazione e Attuazione dell’Architettura, Università degli Studi di Napoli “Federico II”, Napoli

(d) Facoltà di Scienze della Formazione, Università degli Studi, Trieste

Presidente dell’Istituto Superiore di Sanità e Direttore responsabile: Enrico Garaci Registro della Stampa - Tribunale di Roma n. 131/88 del 1° marzo 1988 Redazione: Paola De Castro, Sara Modigliani e Sandra Salinetti La responsabilità dei dati scientifici e tecnici è dei singoli autori. © Istituto Superiore di Sanità 2008

Istituto Superiore di Sanità Valutazione di accessibilità dei siti web: il processo operativo dell’Istituto Superiore di Sanità. Carla Faralli, Marco Ferrari, Stefano Guderzo, Simona Deodati, Mario Didomenicantonio, Erminia Attaianese, Maurizio Boscarol, Claudio Di Benedetto, Eugenio Morassi 2008, 51 p. Rapporti ISTISAN 08/31

L’Istituto Superiore di Sanità (ISS) è stato iscritto nell’elenco pubblico dei valutatori di accessibilità, sulla base del DPR 75/2005. Diventare valutatori di accessibilità di siti web significa che l’ISS ha la struttura organizzativa e tecnologica per poter valutare se siti web di strutture terze rispondano ai requisiti di usabilità e accessibilità previsti dalla vigente normativa (Legge 4/2004). Nel presente rapporto viene descritto il processo operativo che si intende attuare per la valutazione di accessibilità tecnica e soggettiva. La valutazione di accessibilità di un sito web, infatti, prevede due livelli: una valutazione tecnica, cioè la verifica della rispondenza a 22 requisiti tecnici e la verifica soggettiva, basata, grazie all’intervento di un gruppo di valutazione composto da utenti disabili, sulla verifica dell’effettiva fruibilità dei servizi e delle informazioni veicolate da un sito web.

Parole chiave: Accessibilità, Progettazione, Valutazione, Siti web, Internet Istituto Superiore di Sanità Web sites accessibility assessment: the Istituto Superiore di Sanità operating process. Carla Faralli, Marco Ferrari, Stefano Guderzo, Simona Deodati, Mario Didomenicantonio, Erminia Attaianese, Maurizio Boscarol, Claudio Di Benedetto, Eugenio Morassi 2008, 51 p. Rapporti ISTISAN 08/31 (in Italian)

The Istituto Superiore di Sanità (ISS, the National Institute of Health in Italy) is qualified to certify the accessibility and usability features of a web site in accordance with Italian law (DPR 75/2005). In this report an operating process for technical and subjective assessment is described. In fact, the assessment accessibility of a web site provides for two levels, in accordance with Law No. 4/2004. The primary level shall be a certified subject to a positive result in the technical assessment, which verifies the conformity of the sites’ pages with the 22 technical requirements listed in the law. The secondary level of accessibility relates to the quality of information and services provided by the web site and shall be certified by the subjective assessment. This evaluation must be carried out involving a group of users, including disabled users.

Key words: Accessibility, Design, Assessment, Web sites, Internet

Per informazioni su questo documento scrivere a: [email protected]. Il rapporto è accessibile online dal sito di questo Istituto: www.iss.it. Citare questo documento come segue:

Faralli C, Ferrari M, Guderzo S, Deodati S, Didomenicantonio M, Attaianese E, Boscarol M, Di Benedetto C, Morassi E. Valutazione di accessibilità dei siti web: il processo operativo dell’Istituto Superiore di Sanità. Roma: Istituto Superiore di Sanità; 2008. (Rapporti ISTISAN 08/31).

Rapporti ISTISAN 03/xxxx

i

INDICE

Introduzione........................................................................................................................................ 1 Struttura organizzativa .................................................................................................................. 3 Strumentazione hardware e software ............................................................................................... 3 Hardware ................................................................................................................................. 3 Sistemi operativi...................................................................................................................... 4 Software................................................................................................................................... 4 Ambienti di virtualizzazione ................................................................................................... 5 Software per la verifica tecnica ............................................................................................... 5 Tecnologie assistive................................................................................................................. 5 Le verifiche ......................................................................................................................................... 6 Verifica tecnica ................................................................................................................................ 6 Flusso delle operazioni ............................................................................................................ 6 Requisito n. 1........................................................................................................................... 7 Requisito n. 2........................................................................................................................... 11 Requisito n. 3........................................................................................................................... 13 Requisito n. 4........................................................................................................................... 16 Requisito n. 5........................................................................................................................... 17 Requisito n. 6........................................................................................................................... 18 Requisito n. 7........................................................................................................................... 19 Requisito n. 8........................................................................................................................... 20 Requisito n. 9........................................................................................................................... 20 Requisito n. 10......................................................................................................................... 20 Requisito n. 11......................................................................................................................... 21 Requisito n. 12......................................................................................................................... 21 Requisito n. 13......................................................................................................................... 24 Requisito n. 14......................................................................................................................... 24 Requisito n. 15......................................................................................................................... 24 Requisito n. 16......................................................................................................................... 25 Requisito n. 17......................................................................................................................... 26 Requisito n. 18......................................................................................................................... 26 Requisito n. 19......................................................................................................................... 27 Requisito n. 20......................................................................................................................... 27 Requisito n. 21......................................................................................................................... 28 Requisito n. 22......................................................................................................................... 28 Verifica soggettiva ........................................................................................................................... 28 Analisi da parte di uno o più esperti di fattori umani .............................................................. 29 Gruppo di valutazione ............................................................................................................. 29 Esecuzione del test con gli utenti............................................................................................. 30

Elaborazione dei dati da parte dell’esperto e rapporto conclusivo con l’indicazione del livello di qualità raggiunto .................................................................... 30

Criteri di valutazione ............................................................................................................... 30 Appendice 1 Ergonomia e fattore umano per il progetto dell’interazione ............................................................ 33 Appendice 2 Le tecnologie assistive e la Legge 4/2004....................................................................................... 41 Riferimenti bibliografici ................................................................................................................. 51

Rapporti ISTISAN 08/31

1

INTRODUZIONE

L’Istituto Superiore di Sanità (ISS) è stato iscritto, nel mese di febbraio 2008, all’elenco pubblico dei valutatori di accessibilità dei siti web (1), in base a quanto previsto dalla Deliberazione CNIPA (2).

L’iscrizione al suddetto elenco tenuto dal CNIPA, il Centro Nazionale per l’Informatica nella Pubblica Amministrazione, rappresenta per l’équipe di lavoro, il Gruppo Web, che da alcuni anni si occupa della creazione e dello sviluppo del sito istituzionale dell’ISS, il riconoscimento del raggiungimento, nell’ambito dello sviluppo di tecnologie web, di un livello di eccellenza. Al suddetto elenco vengono iscritte infatti quelle strutture, e l’Istituto, ad oggi, è la prima pubblica amministrazione, che siano in grado di dimostrare il possesso di competenze e conoscenze adeguate per poter valutare se i siti di altri organismi e aziende rispondano ai requisiti di accessibilità e usabilità previsti dalla normativa attualmente vigente in Italia, la cosiddetta legge Stanca (3) e relativo decreto attuativo (4).

L’iscrizione all’elenco dei valutatori rappresenta quindi una tappa ulteriore nel percorso intrapreso dall’ISS nel perseguimento dell’e-inclusion, cioè della partecipazione alla vita sociale e quindi all’informazione, nel nostro caso prodotta da una pubblica amministrazione, da parte di tutti i cittadini, anche di quelli che appartengono alle cosiddette categorie svantaggiate. Oggi che internet rappresenta un veicolo fondamentale di comunicazione, tale mezzo potrebbe rappresentare un ulteriore motivo di divario tra chi è in grado di usufruirne e chi, per motivi diversi, non lo è, cioè le persone con disabilità di vario tipo, che per navigare in rete hanno bisogno di ricorrere a specifiche strumentazioni, le persone anziane, che hanno una scarsa alfabetizzazione informatica, quelle che utilizzano software e hardware ormai vecchi. Tutte queste categorie di utenti, grazie agli accorgimenti tecnici previsti dalla legge Stanca, che ha fatto proprie le indicazioni in tema di accessibilità rilasciate da organismi di standardizzazione internazionale come il W3C (World Wide Web Consortium), potranno usufruire delle informazioni e dei servizi veicolati da internet senza difficoltà.

Il percorso che ha portato l’ISS all’iscrizione all’elenco pubblico dei valutatori è stato lungo e complesso, anche perché la normativa stessa richiede la creazione di una struttura organizzativa articolata.

Tale struttura è composta da persone che hanno competenze ed esperienze diverse: esperti tecnici, quindi con competenze informatiche, un esperto di interazione con persone disabili, ergonomi, cioè esperti di interazione uomo-macchina. Se per le prime figure si tratta di personale interno all’ISS, per le figure dell’ergonomo si è fatto ricorso ad esperti esterni.

Parallelamente al team di esperti è stato istituito il cosiddetto Gruppo di valutazione, sempre secondo quanto previsto dalla normativa. Si tratta di persone che presentano disabilità di vario tipo (motorie, visive, cognitive) che guidate dall’ergonomo e con il supporto dell’esperto di interazione con persone disabili dovranno svolgere dei compiti assegnati volti a definire se il sito oggetto della verifica risponda o meno a requisiti di fruibilità e usabilità dei contenuti e dei servizi offerti. La verifica di accessibilità, infatti, si articola in due fasi: una prima fase, che prevede la verifica tecnica, cioè la rispondenza ai 22 requisiti previsti dal decreto ministeriale dell’8 luglio (5) e una verifica soggettiva in cui verranno attribuiti dei compiti specifici al gruppo di valutazione.

Ma quali sono i soggetti che sottoporranno a verifica il proprio sito? Quelli che lo debbono fare per obbligo di legge (pubbliche amministrazioni, aziende municipalizzate, aziende private concessionarie di servizi pubblici, ecc.) e quelli più sensibili al tema dell’e-inclusion per tutte le categorie dell’utenza.


Nel presente lavoro viene riportato quello che potremmo definire un protocollo operativo, cioè come ci si propone di procedere e quale è il flusso di lavoro che si intende applicare nel momento in cui viene affrontata la verifica di un sito web.

Il presente rapporto è articolato in due parti: nella prima sono riportate le descrizioni della struttura organizzativa che procederà alla verifica tecnica e soggettiva, delle strumentazioni hardware e software e delle tecnologie assistive che verranno utilizzate. Nella seconda parte viene invece riportato il processo operativo relativo alle due verifiche: tecnica e soggettiva.

Tutto ciò non solo per codificare un’attività da poco tempo annoverata tra i servizi offerti dall’ISS, ma anche per rispondere a un criterio di trasparenza che deve entrare a far parte dell’attività di una pubblica amministrazione.

Claudio Di Benedetto

Direttore Servizio Informatico, Documentazione, Biblioteca, Attività Editoriali

2


3

STRUTTURA ORGANIZZATIVA

La struttura organizzativa che si occuperà della verifica tecnica e soggettiva è composta da: 1. due esperti di fattori umani con specifiche competenze nel campo dell’ergonomia,

secondo quanto previsto dall’art. 1, comma 1, lettera i) del Decreto del Ministro per l’Innovazione e le Tecnologie 8 luglio 2005 (cfr. Appendice 1 per approfondimenti sull’ergonomia);

2. un esperto di interazione con persone disabili ai sensi dall’art. 1, comma 1, lettera l) del Decreto del Ministro per l’Innovazione e le Tecnologie 8 luglio 2005;

3. tre esperti tecnici ai sensi dall’art. 1, comma 1, lettera m) del Decreto del Ministro per l’Innovazione e le Tecnologie 8 luglio 2005;

4. gruppo di valutazione composto da persone che presentano disabilità di vario tipo secondo quanto previsto dall’allegato B, comma 1, lettera b) del Decreto del Ministro per l’Innovazione e le Tecnologie 8 luglio 2005.

Di tale Gruppo di valutazione fanno parte utenti rappresentativi dei diversi tipi di disabilità: sordità, ipovisione, daltonismo, cecità, disabilità motoria agli arti superiori, distrofia spastica, disabilità cognitiva, nonché soggetti appartenenti a diverse categorie di utenti interessati ad accedere al sito. Il Gruppo effettuerà la verifica soggettiva, supportato dall’esperto di interazioni con i disabili e coordinato, nell’espletamento dei compiti assegnati, dall’esperto di fattori umani.

Tale struttura organizzativa si avvarrà del supporto e dell’ausilio del Gruppo Web che cura la realizzazione, lo sviluppo e il coordinamento degli oltre 100 progetti, cioè siti dedicati ad argomenti e tematiche specifiche, che compongono il sito istituzionale dell’ISS.

Tre membri del Gruppo Web (Eugenio Morassi, Stefano Guderzo, Marco Ferrari) costituiscono il pool di esperti tecnici. Gli altri due membri, Simona Deodati (Sviluppo e personalizzazione sito ISS) e Carla Faralli (Coordinamento editoriale sito ISS) interverranno, rispettivamente, a supporto della verifica tecnica e di quella soggettiva.

Strumentazione hardware e software

Hardware Nell’ottica di riprodurre, per quanto possibile, le condizioni d’uso dell’utenza di riferimento

del prodotto sottoposto a validazione, e al contempo di utilizzare le tecnologie che consentano o aiutino la verifica tecnica, l’Istituto si è dotato di hardware opportuno.

Nello specifico si tratta di macchine di epoche diverse, con sistemi operativi diversi, o sistemi operativi formalmente uguali ma di diverse versioni, ovvero di sistemi con gradi diversi di aggiornamento.

Il metodo di collezione si basa su oggetti fisici (PC) provenienti da resi interni all’Istituto, ovvero da macchine disponibili in virtù di un processo di virtualizzazione.

Nello specifico è possibile contare almeno sui seguenti ambienti: 1. Macchine con processore Intel Pentium 4 2. Macchine con processore AMD Athlon 64 3. Macchine con processore Intel Core Duo 4. Macchine con processore Intel Core 2 Duo 5. Macchine con processore IBM PowerPC G5 6. Macchine con processore PowerPC G4 7. Macchine con processore PowerPC G3


I monitor sono indicativamente capaci di risoluzioni (native) dai 640 * 480 pixel in poi, con definizione di 72 e 96 dpi.

Sistemi operativi

I sistemi installati comprendono (in maniera non esaustiva): 1. Microsoft Windows:

a. Windows 98 SE b. Windows XP SP2 (Home, Pro) c. Windows 2000 Professional d. Windows Vista

2. Apple Mac OS X: a. Mac OS X 10.3.x Panther b. Mac OS X 10.4.x Tiger c. Mac OS X 10.5.x Leopard

3. Apple Mac OS 9: a. Mac OS 9.2.2

4. Linux: a. Debian Sarge (3.x) Stable b. Debian Lenny (4.x) Testing c. (K)Ubuntu 6.x d. (K)Ubuntu 7.x e. (K)Ubuntu 8.x f. Knoppix (Live) g. Gentoo (Live) h. SUSE Linux Enterprise Desktop

Software

I prodotti di navigazione (User Agent e/o browser) installati comprendono (in maniera non esaustiva):

1. Microsoft Internet Explorer a. 6.x b. 7.x

2. Mozilla a. Firefox 1.5.x b. Firefox 2.x c. Firefox 3.x d. Camino 1.x

3. Netscape a. Netscape 7.x

4. Opera a. 8.x b. 9.x

5. Epiphany 6. iCab 4.1.1 7. Apple

a. Safari 2.x b. Safari 3.x

4


5

8. Lynx 2.8.5-3 (via Fink) 9. JAWS

Ambienti di virtualizzazione

1. VMWare 2. Parallels

Software per la verifica tecnica

I prodotti di validazione installati comprendono (in maniera non esaustiva): 1. W3C QA Markup Validation Service v0.7.4 (codice (X)HTML) 2. WEB Developer Extension per Mozilla Firefox 3. Fujitsu Web Accessibility Inspector 4. Colour Contrast Analyser 5. Web Accessibility Toolbar per Internet Explorer 6. W3C CSS Validator 7. W3C Link Checker

Tecnologie assistive

Le tecnologie assistive sono tutti quegli strumenti che consentono, a chi presenta disabilità di vario tipo, di poter usufruire delle informazioni e dei servizi offerti dalla rete (per approfondire l’argomento cfr. Appendice 2).

Software 1. JAWS - http://www.freedomscientific.com/fs_products/software_jawspricing.asp 2. Virtual Magnifying Glass 3. Dragnifier 4. Desk lens 5. Desktop zoom

Hardware 1. Mouse: Trackball QTRONIX 2. Tastiera: HWTA0130 Intellikeys tastiera programmabile


LE VERIFICHE

Definire con puntualità la sequenza del flusso operativo relativo alla verifica tecnica e a quella soggettiva di un sito web di cui non si ha alcuna informazione non è semplice, anche perché questo potrebbe variare notevolmente sulla base della complessità, o meno, del target di utenti e degli argomenti trattati dal sito oggetto della valutazione. Si cercherà, comunque, di specificare tale flusso quanto più possibile, attenendosi sempre a quanto previsto dagli allegati A e B del Decreto del Ministro per l’Innovazione e le Tecnologie dell’8 luglio 2005 (5).

Verifica tecnica

Questo tipo di verifica, che rappresenta il primo livello dell’accessibilità di un sito web, in sostanza verterà sul riscontro del raggiungimento dei 22 requisiti previsti dall’allegato A del Decreto del Ministro per l’Innovazione e le Tecnologie dell’8 luglio 2005. Per attuare tale verifica sarà necessario ricorrere a strumenti automatici, ma anche (frequentemente) ad una valutazione a vista dell’esperto tecnico basata sulle sue conoscenze e sulla sua esperienza.

In estrema sintesi la verifica si accerterà di: – verificare la rispondenza del linguaggio utilizzato alla sua definizione formale; – esaminare le pagine con diversi browser, in diverse versioni e in vari sistemi operativi; – verificare le differenze di luminosità e di colore tra il testo e lo sfondo.

Flusso delle operazioni

Lo schema operativo della verifica tecnica partirà dall’analisi della struttura del sito e dalla conseguente definizione delle pagine da prendere in esame:

1. analisi della rispondenza a tutti i requisiti dell’homepage del sito e di tutte le pagine raggiungibili direttamente dai link presenti nella home (Primo livello);

2. analisi della rispondenza a tutti i requisiti per le pagine che presentano form; 3. analisi di tutti i requisiti per un campione di pagine pari al 5% tra quelle non

precedentemente esaminate; 4. analisi della rispondenza del linguaggio utilizzato alla sua definizione formale. Per tale

operazione verranno utilizzati strumenti di validazione automatica del W3C, come il W3C QA Markup Validation Service che controlla il formato dei documenti HTML, XHTML, SGV, MATHML ed è utilizzabile su tutti i sistemi operativi;

5. verifica dell’esperto tecnico sul corretto utilizzo semantico degli elementi e degli attributi secondo le specifiche del linguaggio utilizzato (ad esempio, controllare che nei CSS la dimensione del testo venga definita in misure relative e non assolute);

6. esame della pagina con diversi browser, in differenti versioni e in diversi sistemi operativi per verificare, che i contenuti siano fruibili correttamente nelle diverse configurazioni esaminate, disattivando, ad esempio, il caricamento delle immagini o disabilitando i fogli di stile (CSS);

7. verifica del colore e della luminosità delle pagine web tramite l’utilizzo, ad esempio, del software Colour Contrast Analyser.

Vengono di seguito elencati (in maniera non esaustiva) alcuni degli strumenti di validazione automatica che verranno utilizzati per la verifica tecnica:

6


7

1. W3C QA Markup Validation Service v0.7.4 (codice (X)HTML) 2. Web Developer Extension per Mozilla Firefox 3. Fujitsu Web Accessibility Inspector 4. Colour Contrast Analyser 5. Web Accessibility Toolbar per Internet Explorer 6. W3C CSS Validator 7. W3C Link Checker Nel dettaglio, verranno analizzati i singoli requisiti previsti dal Decreto dell’8 luglio 2005 (5)

riportati nell’Enunciato, le operazioni specifiche che devono essere effettuate e gli strumenti per la verifica tecnica.

Requisito n. 1

Enunciato 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 e attributi in modo conforme alle specifiche, rispettandone l’aspetto semantico. In particolare, per i linguaggi a marcatori HTML (HypertText Markup Language) e XHTML (eXtensible HyperText Markup Language):

a. per tutti i siti di nuova realizzazione utilizzare almeno la versione 4.01 dell’HTML o preferibilmente la versione 1.0 dell’XHTML, in ogni caso con DTD (Document Type Definition-Definizione del Tipo di Documento) di tipo Strict;

b. per i siti esistenti, in sede di prima applicazione, nel caso in cui non sia possibile ottemperare al punto a) è consentito utilizzare la versione dei linguaggi sopra indicati con DTD Transitional, ma con le seguenti avvertenze: 1. evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è

realizzata, elementi e attributi per definirne le caratteristiche di presentazione della pagina (per esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo, ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per ottenere lo stesso effetto grafico;

2. evitare la generazione di nuove finestre; ove ciò non fosse possibile, avvisare esplicitamente l’utente del cambiamento del focus;

3. pianificare la transizione dell’intero sito alla versione con DTD Strict del linguaggio utilizzato, dandone comunicazione alla Presidenza del Consiglio dei Ministri - Dipartimento per l’innovazione e le tecnologie e al Centro nazionale per l’informatica nella pubblica amministrazione.

Metodologia di verifica 1. verificare l’esistenza del DOCTYPE 2. verificare la corrispondenza DOCTYPE-codice (con il DTD - Document Type Definition) 3. verificare la separazione tra contenuto e presentazione della pagina (esistenza CSS) 4. verificare il target dei link (generazione di nuove finestre).

Strumenti Per verificare l’esistenza della dichiarazione del DOCTYPE nel codice è necessario un

visualizzatore di testo. L’espressione è volutamente generica, perché per questo scopo è possibile utilizzare tanto un browser (ad esempio, con la funzione Visualizza sorgente, Mostra


HTML o simili) (Figure 1 e 2) quanto un editor di testo, un word processor, o qualunque altro strumento in grado di visualizzare testo, come il seguente comando *NIX:

wget -O - http://www.iss.it/ | more che scarica la home del sito in argomento e la visualizza (una pagina alla volta) sullo standard output (Figura 3).

Figura 1. La funzione di visualizzazione del codice della pagina in Microsoft Internet Explorer 7 in Windows XP SP3

Figura 2. La funzione di visualizzazione del codice della pagina in Mozilla Firefox 3.0.1 in Apple Mac OS X 10.5

8


9

Figura 3. Il comando *NIX wget redirezionato sullo stdout per visualizzare il codice sorgente delle pagine web

Per verificare che il DOCTYPE sia non solo presente ma anche corretto, la metodologia non può essere la stessa. Certamente si potrebbe fare un controllo umano di questa corrispondenza, ma il DTD che descrive un metalinguaggio non è certamente amichevole e veloce da usare.

Allo stesso modo, non è pensabile che qualcuno ricordi senza errori od omissioni l’intera grammatica e la relativa sintassi di ogni versione di (X)HTML con il quale è venuto in qualche modo a contatto, e perdipiù sappia distinguerle in relazione al DOCTYPE dichiarato. Pertanto vengono utilizzati gli strumenti automatizzati.

Lo strumento più frequentemente utilizzato è il validatore W3C, che è disponibile all’indirizzo: http://validator.w3.org/, cui può essere passato un URL come parametro con la consueta modalità di URL-encoding. Il validatore W3C è anche scaricabile e installabile in locale, essendo stato rilasciato come prodotto open source e licenziato sotto GNU GPL all’indirizzo: http://validator.w3.org/docs/install.html; questa modalità è decisamente consigliabile, ed è stata utilizzata nel sito dell’ISS.

Con il validatore W3C a disposizione, la verifica della corrispondenza tra quanto dichiarato dai programmatori nel codice e quanto poi effettivamente realizzato è automatica (Figura 4).

Se il DOCTYPE e il codice non sono associati correttamente, il validatore lo segnala (Figura 5).

http://validator.w3.org/

http://validator.w3.org/docs/install.html


Figura 4. Il validatore W3C di fronte ad una pagina corretta

Figura 5. Il validatore W3C di fronte ad una pagina scorretta nell’associazione tra DOCTYPE e XHTML. Nell’esempio di validazione del sito ISS 3.3 si è volutamente alterato il DOCTYPE

imponendo un HTML 4.01 Strict in luogo del reale XHTML 1.0 Strict

10


11

In Figura 3 è anche possibile vedere che la pagina in argomento fa uso di CSS. Se interpretato in maniera letterale il terzo controllo sarebbe pertanto passato. Naturalmente non è così: il controllo non vuole verificare che nella pagina si faccia uso dei

fogli di stile, ma che tutta la presentazione sia in realtà delegata ai CSS, in modo che nessun elemento di interfaccia sia definito all’interno del codice (X)HTML.

Sfortunatamente, in casi come questo, il validatore W3C non è di particolare utilità. Infatti, se nel caso di pagine con DOCTYPE XHTML 1.0 Strict, già la sola presenza di selettori come STYLE all’interno dei tag HTML è sufficiente a far emettere dei warning, nel caso di DTD di linguaggi precedenti (ad esempio, l’HTML 4) questi tag, ancorché deprecati, erano consentiti.

Cogliamo quindi l’occasione per ribadire un concetto: i validatori automatici sono per loro natura di tipo sintattico e quindi la corrispondenza dei prodotti alle normative deve essere verificata da un operatore umano.

Il quarto controllo è il più semplice ma il meno automatizzabile, perché l’attributo TARGET per i link (ovvero quello che consente la generazione di nuove finestre alla selezione dei link) è ammissibile in HTML 4.x e dunque non genera avvertimenti. E questo a conferma di quanto dicevamo solo qualche riga sopra, relativamente all’impossibilità di usare strumenti automatici per tutto. Anche se nell’XHTML quell’attributo non esiste e quindi un tag che lo prevedesse genererebbe un errore, va considerato che:

1. potrebbero essere utilizzati dei linguaggi per il Client Side Scripting (come Java, Javascript, ecc.) che potrebbero riproporre lo stesso comportamento (ovvero l’apertura dei link in altre pagine) in maniera completamente trasparente per il validatore;

2. potrebbero essere usati dei tool per RWA (Rich Web Applications) come Flash, Adobe AIR, Java FX e simili, che propongono quel comportamento con la stessa trasparenza;

3. l’enunciato non distingue le versioni dei siti, ovvero la versione RWA da quella in (X)HTML, ad esempio, ma contiene un principio generale.

Per questi motivi tale controllo prevede un’attività di tipo manuale.

Requisito n. 2

Enunciato 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, ma con le seguenti avvertenze:

a. evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è realizzata, elementi e attributi per definirne le caratteristiche di presentazione della pagina (ad esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo, ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per ottenere lo stesso effetto grafico;

b. fare in modo che ogni frame abbia un titolo significativo per facilitarne l’identificazione e la navigazione; se necessario, descrivere anche lo scopo dei frame e la loro relazione;

c. pianificare la transizione a XHTML almeno nella versione 1.0 con DTD Strict dell’intero sito dandone comunicazione alla Presidenza del Consiglio dei Ministri - Dipartimento per l’innovazione e le tecnologie e al Centro nazionale per l’informatica nella pubblica amministrazione.

Metodologia di verifica 1. verificare l’esistenza del DOCTYPE 2. controllare che il codice non contenga frame.

Strumenti Per quanto riguarda la dichiarazione e il trattamento del DOCTYPE nel codice in caso di

valutazione, si veda quanto è stato detto relativamente ai controlli relativi al Requisito n. 1. Nello specifico, va detto che anche se il DOCTYPE fosse di tipo Strict e non frameset nulla impedirebbe, in linea di principio e vista la notevole tolleranza degli User Agent con interfaccia grafica (ovvero i browser più diffusi), di implementare un frameset in un documento HTML che non lo preveda.

A titolo di esempio consideriamo il seguente codice:

<!DOCTYPE html PUBLIC “=//W3C//DTD XHTML 1.0 Strict//EN”“http://www.w3.org/TR/xhtml1/DTD/xhtml1=strict.dtd”>

<html lang=”it”><head>

<meta http=equiv=”content=type” content=”text/html; charset=iso=8859=1”>

<link rel=”stylesheet” href=”./stile.css” type=”text/css”><title> ISS = Benvenuti nel Frameset </title>

</head>

<frameset cols=”20%,80%”><frame class=”frmgen”

src=”http://www.iss.it/siti/beta12002/idx.html”scrolling=”NO” noresize marginheight=”0”marginwidth=”0” frameborder=”0” name=”uno”>

<frame class=”frmgen”src=”http://www.iss.it/siti/beta12002/mid.html”scrolling=”AUTO” noresize marginheight=”0”marginwidth=”0” frameborder=”0” name=”due”>

<noframes><body>



</body></noframes>

</frameset></html>

che usa una versione storica del sito dell’ISS con un DOCTYPE XHTML 1.0 Strict e che

viene resa dai browser proprio come ci si aspetta (Figura 6) ovvero con un frameset, malgrado la definizione del DTD non lo consenta.

Se almeno i browser sbagliassero di conseguenza, cioè opponessero un errore di rendering ad un errore di programmazione (pur così macroscopico), il controllo sarebbe più semplice.

Quindi, sebbene non indicato espressamente, il controllo in merito al DOCTYPE è del tutto simile a quello del Requisito n. 1, anche riguardo alla corrispondenza tra dichiarazione e implementazione.

12


13

Figura 6. Una pagina che contiene frame, malgrado il suo DOCTYPE non li preveda, viene resa “correttamente” da un browser

Requisito n. 3

Enunciato Fornire un’alternativa testuale equivalente per ogni oggetto non di testo presente in una

pagina e garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi contenuti equivalenti predisposti; l’alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla funzione esercitata dall’oggetto originale nello specifico contesto.

Metodologia di verifica 1. verificare la presenza di testi alternativi per le immagini (comprese le mappe immagine e

i pulsanti) 2. verificare la presenza di contenuti equivalenti per script e oggetti 3. verificare che i contenuti equivalenti di contenuti dinamici siano aggiornati con la stessa

frequenza dei contenuti principali.


Strumenti C’è una parola chiave nell’enunciato e questa è “commisurata”. Premesso che tutto quanto concerne il codice della pagina può essere analizzato con gli

Strumenti e la Metodologia visti nel caso del Requisito n. 1, ci troviamo nuovamente di fronte ad una caratteristica che potrebbe essere perfettamente ammissibile ma vietata. Il confine tra l’ammissibilità e il divieto è la decisione di considerare quanto l’alternativa testuale sia commisurata al ruolo dell’oggetto che descrive.

Anzitutto vediamo come vanno descritte le alternative testuali in relazione agli oggetti che descrivono; in linea di massima le alternative testuali vengono introdotte nei singoli tag che prevedono elementi di interfaccia, come immagini, pulsanti, campi form, ecc., e in genere usando il selettore ALT=““, inserendo del testo tra le virgolette. Prendendo come al solito ad esempio il sito dell’ISS, vediamo come funziona il meccanismo in merito alla scelta della lingua. È possibile (attualmente, in una futura versione sarà esclusivamente testuale) sceglierla usando l’immagine della bandiera della nazione (Figura 7).

Figura 7. La scelta della lingua sul sito ISS 3.3 effettuata per mezzo di un elemento grafico

Se disabilitiamo le immagini (un modo come un altro per verificare ad un primo esame la funzionalità delle alternative testuali), otteniamo quanto riportato nella Figura 8, che è certamente meno attraente, ma ugualmente funzionale.

Figura 8. La scelta della lingua sul sito ISS 3.3 effettuata in assenza dell’elemento grafico

Si è scelto di portare come esempio questo dettaglio del sito, perché ci consente anche di trattare un ulteriore aspetto del concetto di equivalenza funzionale. L’intestazione delle pagine

14


15

del sito contiene una serie di icone, oltre a quelle della lingua, che sono in numero variabile e che permettono di accedere alle seguenti funzionalità:

– Logo ISS: homepage ISS – Casetta: home dello specifico progetto/sito – Mappamondo: mappa del progetto/sito – Lettera A piccola: carattere normale – Lettera A grande: carattere grande – Feed RSS: RSS del progetto/sito – Cuffie: Podcast dell’ISS Se notate, queste icone non sono rappresentate da un’alternativa testuale se si disabilitano le

immagini, cosa che apparirebbe in contraddizione con i dettami del Requisito n. 3. In realtà, si è deciso di delocalizzare (e non di omettere) l’alternativa testuale di queste icone riportandola a fondo pagina, nella Mappa del Sito (Figura 9).

Figura 9. Alternative testuali non veicolate da selettori, ma da testo vero e proprio

In mancanza di una specifica contraria, si desume che questo comportamento sia completamente ammissibile. Si noti dunque che non necessariamente l’alternativa testuale si realizza con il selettore ALT=““, il selettore TITLE=““ o simili, ma può essere definita anche da testo letteralmente inteso.

Siccome la scelta di dove collocare l’alternativa testuale varia di caso in caso anche per la diversa sensibilità di chi realizza i siti, si capisce come questo controllo non possa essere (nuovamente) effettuato in automatico, e come gli eventuali warning generati dal validatore W3C o simili possano essere ignorati senza inficiare la validazione del sito in esame.

Eppure abbiamo supposto essere necessario superare la validazione del linguaggio a marcatori utilizzato. Non c’è contraddizione in questo, e il motivo risiede nella premessa di questo paragrafo, ovvero nella parola “commisurata”. Facciamo un ulteriore esempio.

L’intestazione dei progetti/siti ISS contiene un’immagine di sfondo (potrebbe anche essere un separatore, un “filetto tipografico”, ecc.). Il suo tag ALT=““ è presente, ma è vuoto. E deve esserlo, perché altrimenti fornirebbe un’alternativa testuale ad un qualcosa di perfettamente nullo dal punto di vista semantico e quindi intralcerebbe la navigazione (ovvero sarebbe contro lo spirito della norma) invece di semplificarla.

La nostra interpretazione della parola “commisurata” è questa.


Non è diverso il discorso relativo al contenuto cangiante. Se nella pagina sono presenti degli SSS (Server-Side Script, come Java, JavaScript, ecc.) va verificato che al cambiare dell’interfaccia cambi anche l’alternativa testuale che questi debbono generare, senza che nulla cambi nelle considerazioni sin qui espresse, con una sola eccezione: i lettori di schermo, anche quelli che sono degli standard de facto, leggono il testo in maniera sequenziale; comportamento corretto, del resto, perché la stessa norma prevede (lo vedremo) che il codice, comunque venga reso, deve mantenere la sequenzialità. Il problema è che se un SSS cambia un elemento che è già stato visitato, e quindi letto dallo screen reader, la modifica non verrà fatta notare (cioè letta) restando di fatto trasparente all’utente; e questo è contrario alla norma.

In questi casi (in realtà non infrequenti) va verificato che la modifica testuale venga posizionata in modo semanticamente corretto e tale da essere sempre visibile anche considerando la serializzazione della pagina in cui è contenuta.

Requisito n. 4

Enunciato Garantire che tutti gli elementi informativi e tutte le funzionalità siano disponibili anche in

assenza del particolare colore utilizzato per presentarli nella pagina.

Metodologia di verifica 1. disabilitare i CSS per verificare che l’accessibilità all’informazione rimanga inalterata.

Strumenti Il primo metodo è il più semplice e in genere funzionale: si disabilita il CSS e si legge la

pagina come verrebbe generata da uno User Agent che non li supporta (Figura 10), ottenendo in genere un qualcosa di molto simile a quanto riportato nella Figura 11.

Figura 10. Una modalità per disabilitare i CSS (Firefox con Web Developer Toolbar - CSS - Disable Styles - All Styles)

16


17

Figura 11. Un rendering del tutto privo di CSS e molto simile ad un rendering monocromatico

In questo modo il controllo potrebbe essere già efficace. Il secondo controllo, invece, tiene conto del fatto che alcuni utenti affetti da discromie (ad esempio i daltonici affetti da daltonismo al blu, una minoranza) potrebbero trovare inusabile un sito che punti sui blu (come si vede dalla foto), e sgradevole o inusabile un sito senza CSS. A questo proposito un secondo controllo prevede l’associazione di un CSS (scritto ad hoc dal validando ovvero selezionabile dall’utenza del sito stesso) che elimini i colori che cadono nei casi di daltonismo più diffuso, cioè rosso/verde e blu. Il primo tipo di daltonismo riguarda l’85-95% dei casi. Sarebbe da preferire la circostanza per cui questa opportunità sia data a tutti i visitatori e non solo ai valutatori in fase di valutazione.

Requisito n. 5

Enunciato 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.

Metodologia di verifica 1. verificare che non siano presenti scritte animate o lampeggianti 2. se presenti è necessario misurarne la frequenza 3. nel caso in cui non sia possibile eliminarle, verificare la presenza di avvertimenti del rischio.


Strumenti In questo Requisito, non solo si definiscono (in disaccordo con alcune teorie mediche) le

frequenze pericolose per chi soffre di epilessia fotosensibile, ma vengono anche indicati i fenomeni attraverso cui dette frequenze debbano essere misurate (lampeggiamenti acceso/spento, lampeggiamenti da contrasto cromatico, ecc.).

La prima cosa da fare quindi, in presenza di lampeggiamenti, è definire l’origine del fenomeno che li rappresenta.

Per la misurazione, in assenza di prodotti che eseguano la verifica completa in automatico, si può ricorrere ad alcuni strumenti per la misurazione di specifici oggetti, come:

1. PEAT - Photosensitive Epilepsy Analysis Tool, per i filmati contenuti all’interno delle pagine;

2. Controllo Flicker Rate Immagini Gif di Renzo Giust, messo a disposizione online http://tools.Webaccessibile.org/test/check.aspx (Figura 12).

Figura 12. Lo strumento messo a disposizione all’indirizzo: http://webaccessibile.org

Requisito n. 6

Enunciato 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; ove non sia possibile, ricorrere agli stessi criteri di distinguibilità indicati in precedenza.

18

http://tools.webaccessibile.org/test/check.aspx


19

Metodologia di verifica 1. verificare il contrasto dei colori nel foglio di stile; 2. controllare la presenza di immagini sostitutive dei testi; 3. calcolare la luminosità dei colori di testo e di sfondo con il seguente algoritmo:

((Rosso * 299) + (Verde * 587) + (Blu * 114)) / 1000 in cui Verde, Rosso e Blu sono i valori decimali dei colori. È consigliato un valore della differenza tra le due luminosità maggiore di 125.

Strumenti Il concetto è sintetizzato da due formule del W3C; la prima (è ancora un proposta, ma viene

pragmaticamente considerata un dato: http://www.w3.org/TR/AERT#color-contrast) consente di calcolare la luminosità assoluta di un elemento, identificato in notazione RGB (Red, Green, Blue), con la seguente:

((Rosso * 299) + (Verde * 587) + (Blu * 114)) / 1000. La differenza di luminosità tra due elementi che devono contrastare tra loro non dev’essere

inferiore a 125. La seconda formula consente di calcolare il contrasto tra elementi identificati nella stessa

notazione: ((max (Rosso1, Rosso2) - min (Rosso1, Rosso2)) + ((max (Verde1, Verde2) - min (Verde1, Verde2)) + ((max (Blu1, Blu2) - min (Blu1, Blu2))

ritenuto sufficiente se il valore ottenuto è superiore a 500. Va ricordato che in notazione posizionale RGB, il colore è definito dalle quantità dei tre

fondamentali espressi in una scala decimale; nell’ambito della rappresentazione a video, il valore massimo per ogni colore richiede in genere 28 = 256 bit (dunque valori tra 0 e 255); a questi valori si riferiscono le variabili indicate con Rosso, Verde, Blu nelle formule.

Il panorama strumentale è vario e in evoluzione. In particolare, alcuni degli strumenti precedentemente utilizzati sono stati oggetto,

ultimamente, di una campagna acquisti piuttosto generalizzata, da parte di un’azienda che al momento li ha ritirati dal mercato. Le due direzioni verso cui muovere sono:

1. plug-in dei browser più diffusi 2. programmi ad hoc. Nei primi rientra senz’altro la Web Accessibility Toolbar prodotta dal Web Accessibility

Tools Consortium (WAT-C) e disponibile per Microsoft Internet Explorer 5 e successive all’indirizzo http://www.paciellogroup.com/resources/wat-ie-about.html.

Tra i secondi va certamente ricordata la suite Fujitsu Accessibility Assistance, reperibile all’indirizzo http://www.fujitsu.com/global/accessibility/assistance/

Requisito n. 7 Enunciato

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.

Metodologia di verifica 1. verificare la presenza di mappe immagine sensibili lato server.

http://www.w3.org/TR/AERT#color-contrast


Strumenti Sono necessari e sufficienti gli strumenti indicati per il Requisito n. 1.

Requisito n. 8

Enunciato 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.

Metodologia di verifica 1. in caso di mappe immagine sensibili lato server verificare la presenza di collegamenti

ipertestuali equivalenti alle zone sensibili.


Requisito n. 9

Enunciato 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.

Metodologia di verifica 1. verificare la presenza di tabelle dati 2. verificare l’uso corretto degli elementi <CAPTION>, <TR>, <TH> e <TD> secondo le

specifiche 3. verificare la presenza dell’attributo <SUMMARY>.


Requisito n. 10

Enunciato Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti nella DTD adottata per

associare le celle di dati e le celle di intestazione che hanno due o più livelli logici di intestazione di righe o colonne.

Metodologia di verifica 1. verificare l’uso corretto degli elementi <THEAD>, <TBODY>, <COL>, <COLGROUP>.

20


21


Requisito n. 11

Enunciato Usare i fogli di stile per controllare la presentazione dei contenuti e organizzare le pagine in

modo che possano essere lette anche quando i fogli di stile siano disabilitati o non supportati.

Metodologia di verifica 1. verificare che la pagina sia fruibile anche disabilitando i fogli di stile (CSS).

Strumenti Sono necessari e sufficienti gli strumenti indicati per il Requisito n. 1. Vale la pena

richiamare Strumenti e Metodologia indicate al Requisito n. 4.

Requisito n. 12

Enunciato 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 di visualizzazione o dei caratteri rispetto ai valori predefiniti di tali parametri.

Metodologia di verifica 1. verificare che il ridimensionamento della finestra non sovrapponga i contenuti 2. eventuale esistenza di dimensione minima/massima dei contenuti 3. i contenuti devono adattarsi al ridimensionamento della finestra.

Strumenti Sono necessarie alcune considerazioni. La prima, già espressa in occasione di un precedente

Rapporto ISTISAN (7), riguarda gli schermi sui quali il prodotto deve essere visitato. In un passato recente le dimensioni e la risoluzione degli schermi sono aumentati, vista la diffusione sul mercato di prodotti con funzionalità potenziate. Tuttavia, parallelamente, si è osservato il fiorire di dispositivi portabili, portatili e ultraportatili, le cui dimensioni sono andate via via diminuendo.

Casi eclatanti (almeno quanto a successo commerciale) sono nati dopo l’emanazione della legge Stanca e dei relativi Decreti attuativi, ed hanno posto un serio problema nella valutazione del Requisito. Se infatti si considera il Requisito alla lettera, un sito accessibile dovrebbe avere la stessa fruibilità sullo schermo di uno smartphone e su un monitor da trenta pollici. Non credendo possibile (con tutta la buona volontà) una cosa del genere, dobbiamo almeno considerare la possibilità che il sito venga ridimensionato senza perdita d’informazione su dispositivi omologhi a quelli previsti come primari da coloro che sottomettono il prodotto a


verifica. Quindi, se il prodotto si rivolge ad un’utenza stanziale, saranno dispositivi da scrivania o portatili; se il prodotto si rivolge al mercato degli smartphone, saranno considerati dispositivi come telefoni o ultraportatili.

La seconda considerazione va fatta in merito al linguaggio di programmazione usato. Indipendentemente dal dispositivo su cui far eseguire uno User Agent di cui abbiamo appena

detto, va anche considerato che alcuni dispositivi non visualizzano siti web propriamente detti, ovvero quelli sviluppati in un linguaggio della famiglia (X)HTML, ma siti scritti specificamente per dispositivi mobili, ad esempio in WML (Wireless Markup Language). Sebbene l’HDML, cioè la classe che raggruppa i linguaggi per dispositivi mobili, sia stato proposto al W3C come standard, al momento quell’organismo lo ha preso come Nota (http://www.w3.org/TR/NOTE-Submission-HDML-spec); quindi a tutt’oggi i dispositivi incapaci di rendere pagine a partire da un linguaggio formalizzato nella famiglia (X)HTML non rientrano nella normativa e non possono essere sottoposti a validazione.

A titolo di esempio consideriamo il sito dell’ISS, visitato ad una risoluzione di 800 * 600 pixel (Figura 13) e lo stesso sito (l’immagine è stata ovviamente rimpiccolita) a 1680 * 1050 pixel (Figura 14); si noterà che non c’è alcuna perdita d’informazione.

Sotto quelle dimensioni, ad esempio 640 * 480 (una definizione che difficilmente si riscontra sulle macchine da scrivania, ma potrebbe essere normale su un ultraportatile) il sito esce parzialmente dallo schermo ma può essere navigato con le consuete barre di scorrimento (Figura 15).

Figura 13. Il sito ISS 3.3 visualizzato su uno schermo di 800 * 600 pixel

22

http://www.w3.org/TR/NOTE-Submission-HDML-spec

http://www.w3.org/TR/NOTE-Submission-HDML-spec


23




Anche questo comportamento è ritenuto accettabile, in base alle considerazioni viste sui dispositivi di visualizzazione.


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.

Metodologia di verifica 1. verificare se vengano utilizzate le tabelle per impaginare 2. verificare che il contenuto della tabella sia linearizzabile.

Strumenti Sono necessari e sufficienti gli strumenti indicati per il Requisito n. 1. A titolo di esempio

viene fornito un suggerimento per ottenere una linearizzazione di un oggetto impaginato in colonne. La versione 3.3 del sito ISS, quella attualmente online, non fa uso di tabelle per l’impaginazione, ma solo per riportare dati. L’impaginazione a colonne della home è stata ottenuta con un uso delle <DIV> regolato dal CSS. Per questo motivo la linearizzazione, e quindi un esempio di quanto in argomento, si può ottenere:

1. disabilitando i CSS 2. scegliendo il CSS per la stampa, che ovviamente riporta una pagina linearizzata.


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.

Metodologia di verifica 1. verificare la presenza di campi che necessitano dell’attributo <label> 2. verificare che le label siano univoche 3. verificare che le label siano correttamente associate all’elemento cui si riferiscono

semanticamente e sintatticamente attraverso l’attributo for=““.



Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati; ove ciò non sia possibile fornire una

24


25

spiegazione testuale della funzionalità svolta e garantire un’alternativa testuale equivalente, in modo analogo a quanto indicato nel Requisito n. 3.

Metodologia di verifica 1. verificare la presenza di oggetti di programmazione (ad esempio OBJECT) 2. verificare il funzionamento della pagina disabilitando l’uso di oggetti di programmazione 3. verificare la presenza di contenuti alternativi per oggetti di programmazione (ad esempio

nel caso di SCRIPT/NOSCRIPT).

Strumenti Sono necessari gli strumenti indicati per il Requisito n. 1, ma non sufficienti. In genere i

browser più diffusi hanno la possibilità di disabilitare gli script e le applet, ma danno questa possibilità a livello di preferenze dell’applicazione. Questo comporta il fatto che tutte le finestre aperte dopo questa disabilitazione, o le stesse finestre aperte in precedenza, ma delle quali si sia ricaricato il contenuto, non contengono più oggetti di quel tipo. Il Requisito chiede non tanto di evitare questi oggetti, ma di raffrontare la versione della stessa pagina sia con che senza di essi.

Un metodo semplice è l’uso di strumenti di terze parti (plugin) che consentano di disabilitare “al volo” e selettivamente gli oggetti in argomento. Tra questi strumenti meritano menzione i seguenti:

1. NoScript (http://noscript.net/) 2. Web Developer Toorlbar per Mozilla Firefox (http://chrispederick.com/work/Web-

developer/) 3. Firebug per Mozilla Firefox (http://getfirebug.com/) 4. Web Accessibility Toolbar per Microsoft Internet Explorer (già vista). Con questi e altri strumenti analoghi (quelli citati sono tutti gratuiti e alcuni anche software

libero) è possibile disattivare un oggetto su una singola finestra, e quindi confrontarla con una omologa che visualizza la stessa pagina con tutti gli accessori disabilitati.

Requisito n. 16

Enunciato 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.

Metodologia di verifica 1. verificare l’esistenza di oggetti inclusi 2. verificare che i controlli degli oggetti inclusi siano indipendenti dal dispositivo di input.

Strumenti Sono necessari gli strumenti indicati per il Requisito n. 15, che vanno usati con diversi

dispositivi di input, ovvero tastiere e mouse, tastiere speciali, mouse speciali. Segnatamente, il problema non si riconduce semplicemente all’esistenza di scorciatoie o equivalenti da tastiera, ma anche al fatto che:

1. gli eventuali equivalenti non entrino in conflitto con altri programmi (ad esempio JAWS e i tag ACCESSKEY=““)


2. siano coerenti all’interno dello stesso prodotto 3. sia possibile guadagnare il fuoco (ovvero scegliere l’oggetto all’interno della pagina)

indipendentemente dal dispositivo di input. Ad esempio, pensiamo ad un prodotto che, sebbene abbia all’interno di uno script

un’interfaccia ben fatta e usabile almeno nei limiti della normativa, necessita di un mouse per essere attivato o di una conoscenza specifica e profonda di un determinato browser che ne emuli il funzionamento.

Requisito n. 17

Enunciato 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.

Metodologia di verifica 1. verificare che in presenza di oggetti di programmazione le modalità di fruizione siano

indistinguibili dal resto della pagina.

Strumenti Sono necessari gli strumenti indicati per i Requisiti n. 1 e 15.

Requisito n. 18

Enunciato Nel caso in cui un filmato o una presentazione multimediale siano indispensabili per la

completezza dell’informazione fornita o del servizio erogato, predisporre un’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.

Metodologia di verifica 1. verificare la presenza di contenuti multimediali 2. verificare la presenza di testi alternativi 3. verificare la presenza di sottotitoli per i dialoghi 4. verificare la sincronizzazione tra il contenuto multimediale e le alternative testuali

equivalenti 5. verificare la presenza di testi descrittivi/riassunti del contenuto.

Strumenti Sono necessari gli strumenti indicati per il Requisito n. 1, in genere integrati da plugin che

consentano la visualizzazione dei contenuti. Infatti, generalmente, quello che non è strettamente legato alla pagina, e quindi reso in (X)HTML deve essere riprodotto attraverso un componente di terze parti aggiunto al sistema operativo sul quale gira il browser (è questo il caso di Apple

26


27

Quicktime, Microsoft Silverlight) oppure allo stesso User Agent (come nel caso di Adobe AIR, Java FX, Adobe Flash/Shockwave e simili). Inoltre alcuni formati specificatamente concepiti per essere accessibili come SMIL - Synchronized Multimedia Integration Language (http://www.w3.org/AudioVideo/), consentono tanto l’esportazione in formati chiusi come quelli appena citati, quanto l’inclusione di contenuti aperti nelle pagine.

Se il prodotto non è accessibile perché non ha superato la validazione dei prodotti a scaffale, non potrà essere valutato. Nei casi in cui i formati richiedano un prodotto commerciale e/o non gratuito, i valutandi debbono fornire tutto il prodotto, licenziato per l’ISS.

Requisito n. 19

Enunciato 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, nonché prevedere meccanismi che consentano di evitare la lettura ripetitiva di sequenze di collegamenti comuni a più pagine.

Metodologia di verifica 1. verificare i collegamenti ipertestuali (A HREF=““) 2. verificare che l’attributo <TITLE> sia parlante 3. verificare che i link che portano ad altri siti siano segnalati 4. verificare che gli oggetti da scaricare siano segnalati e indicativi di dimensione.

Strumenti Sono necessari e sufficienti gli strumenti indicati per il Requisito n. 1, e la valutazione deve

essere fatta da un essere umano (nessuno strumento automatico può farla in maniera utile).

Requisito n. 20

Enunciato 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.

Metodologia di verifica 1. verificare che esista una temporizzazione e/o la scadenza della sessione 2. verificare che la temporizzazione/scadenza della sessione sia comunicata 3. verificare l’esistenza di alternative non temporizzate.


http://www.w3.org/AudioVideo/


Requisito n. 21

Enunciato Rendere selezionabili e attivabili tramite comandi da tastiere o tecnologie in emulazione di

tastiera o tramite sistemi di puntamento diversi dal mouse i collegamenti presenti in una pagina; per facilitare la selezione e l’attivazione dei collegamenti presenti in una pagina è necessario garantire che la distanza verticale di liste di link e la spaziatura orizzontale tra link consecutivi sia di almeno 0,5 em, la distanza orizzontale e verticale tra i pulsanti di un modulo sia di almeno 0,5 em e che le dimensioni dei pulsanti in un modulo siano tali da rendere chiaramente leggibile l’etichetta in essi contenuta.

Metodologia di verifica 1. identificare i moduli e i collegamenti di raggruppamenti ipertestuali 2. identificare gli elementi e le classi ad essi associate 3. identificare se nel CSS vi siano regole che riducono le distanze minime richieste dal

Requisito.


Requisito n. 22

Enunciato 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 e aggiornata con la stessa frequenza, evitando la creazione di pagine di solo testo; il collegamento alla pagina conforme deve essere proposto in modo evidente all’inizio della pagina non accessibile.

Metodologia di verifica Non più applicabile.

Strumenti Erano necessari e sufficienti gli strumenti indicati per il Requisito n. 1. Una volta conclusa la verifica, l’esperto tecnico provvederà a redigere una relazione in cui

sarà indicata la conformità, la non conformità o la non applicabilità di ogni Requisito delle pagine esaminate, corredata da una tabella. Se la verifica tecnica viene superata, è possibile procede a quella soggettiva.

Verifica soggettiva

La metodologia che verrà attuata nelle valutazioni di accessibilità di siti web si articola, secondo il Decreto Ministeriale 8 luglio 2005 “Requisiti tecnici e i diversi livelli per l’accessibilità

28


29

agli strumenti informatici”, Allegato B (5), in quattro fasi distinte, nelle quali l’esperto di fattori umani svolge ruoli diversi, ma che al termine si incarica della sintesi di tutte le attività nel rapporto conclusivo che attesta il livello di qualità raggiunto dal sito preso in esame:

1. analisi da parte di uno o più esperti di fattori umani; 2. costituzione di un gruppo di valutazione composto da utenti anche disabili; 3. test con gli utenti; 4. elaborazione dei dati da parte dell’esperto di fattori umani e rapporto conclusivo con

l’indicazione del livello di qualità raggiunto. Per ognuna delle fasi si articoleranno di seguito le attività da svolgere. La metodologia viene

qui integrata con riferimento allo studio “Metodologia per la valutazione dell’accessibilità e dell’usabilità dei siti pubblici” del gruppo di lavoro del prof. Sebastiano Bagnara (6).

Analisi da parte di uno o più esperti di fattori umani

In questa fase verrà svolta una simulazione cognitiva da parte dell’esperto di fattori umani: – verranno definiti da parte dell’esperto i contesti di utilizzo, gli scopi (informativi e/o di

erogazione di servizi) del sito e i compiti, inclusi i modi di interazione, che gli utenti dovrebbero essere in grado di svolgere e le conoscenze che essi dovrebbero possedere;

– l’esperto svolge un’analisi esplorativa del sito per accertarsi che le definizioni di scopi, compiti e contesti siano ben definiti, e che egli sia in possesso di tutte le informazioni sugli utenti e sugli ambiti informativi del sito;

– a questo punto l’esperto esegue una simulazione cognitiva dei task definiti, secondo gli scenari e la definizione del tipo di utenti identificati. Per ogni passo della simulazione, si porranno le seguenti domande: 1. l’utente è in grado di capire cosa deve fare? 2. l’utente è in grado di farlo? 3. l’utente è in grado di valutare il risultato delle sue azioni?

– verranno annotati problemi e difficoltà, in relazione ai 12 criteri (riportati nel paragrafo “Criteri di valutazione”) indicati nel decreto, e al termine della simulazione, per ciascuno dei 12 criteri, si offrirà una valutazione della sua applicabilità al caso in esame, e, nel caso di applicabilità, si giudicherà il rispetto del criterio su una scala a 5 intervalli: 1. corrisponde a nessuna rispondenza dell’ambiente al criterio in esame 2. corrisponde a poca rispondenza dell’ambiente al criterio in esame 3. corrisponde a sufficiente rispondenza dell’ambiente al criterio in esame 4. corrisponde a molta rispondenza dell’ambiente al criterio in esame 5. corrisponde a moltissima rispondenza dell’ambiente al criterio in esame.

Questo schema di valutazione è l’output della prima fase.

Gruppo di valutazione

Il gruppo di valutazione, già costituito, è composto da utenti disabili (con disabilità che includono sordità, ipovisione, daltonismo, cecità, disabilità motoria agli arti superiori, distrofia spastica, disabilità cognitiva), nonché soggetti appartenenti a diverse categorie di utenti interessate ad accedere al sito.


Almeno un utente per ogni tipologia verrà preso in considerazione. Il numero di utenti complessivi nel panel potrà essere variabile da un minimo di 9 a un

massimo di 24.

Esecuzione del test con gli utenti

Alcuni compiti vengono svolti da parte dei componenti del gruppo, osservati in sessione singola con metodologia del thinking aloud dall’esperto di fattori umani. Ogni componente del gruppo di valutazione verrà osservato mentre:

1. svolge compiti di navigazione libera, durante la quale l’esperto di fattori umani annota comportamenti e verbalizzazioni;

2. esegue task predefiniti nella fase 1, assegnati dall’esperto di fattori umani; durante tali esecuzioni, l’esperto registra: tempo impiegato per l’esecuzione e comportamenti, errori e verbalizzazioni, tasso di successo.

Ogni componente del gruppo di valutazione dovrà poi compilare un questionario di valutazione che corrisponda ai 12 requisiti precedentemente menzionati, valutati sempre secondo la medesima scala da 1 a 5 vista sopra.

Elaborazione dei dati da parte dell’esperto e rapporto conclusivo con l’indicazione del livello di qualità raggiunto

L’esperto di fattori umani compilerà un report sintetico nel quale indicherà: 1. la valutazione su scale soggettive ricavata dalla simulazione cognitiva effettuata; 2. le sue considerazioni qualitative; 3. i dati relativi alle prestazioni degli utenti in relazione ai compiti affidati: misure di

performance, commenti, osservazioni comportamentali; 4. le risposte a questionari di valutazione compilati dagli utenti; 5. la valutazione complessiva del livello di qualità raggiunto secondo il seguente schema:

- valore medio complessivo minore di 2 = assenza di qualità - valore medio complessivo maggiore o uguale a 2 e minore di 3 = primo livello di qualità - valore medio complessivo maggiore o uguale a 3 e minore di 4 = secondo livello di qualità - valore medio complessivo maggiore o uguale a 4 = terzo livello di qualità.

Criteri di valutazione

In accordo al DM dell’8 luglio 2005, i criteri sulla base dei quali verranno svolte le valutazioni dall’esperto e dagli utenti tramite questionario sono i seguenti:

– percezione: informazioni e comandi necessari per l’esecuzione dell’attività devono essere sempre disponibili e percettibili;

– comprensibilità: informazioni e comandi necessari per l’esecuzione delle attività devono essere facili da capire e da usare;

– operabilità: informazioni e comandi devono consentire una scelta immediata dell’azione adeguata per raggiungere l’obiettivo voluto;

– coerenza: simboli, messaggi e azioni devono avere lo stesso significato in tutto l’ambiente;

30


31

– salvaguardia della salute (safety): l’ambiente deve possedere caratteristiche idonee a salvaguardare il benessere psicofisico dell’utente;

– sicurezza: l’ambiente deve possedere caratteristiche idonee a fornire transazioni e dati affidabili, gestiti con adeguati livelli di sicurezza;

– trasparenza: l’ambiente deve comunicare all’utente lo stato, gli effetti delle azioni compiute e le informazioni necessarie per la corretta valutazione della dinamica dell’ambiente stesso;

– apprendibilità: l’ambiente deve possedere caratteristiche di utilizzo di facile e rapido apprendimento;

– aiuto e documentazione: funzioni di aiuto, quali le guide in linea, e documentazione relativa al funzionamento dell’ambiente devono essere di facile reperimento e connesse al compito svolto dall’utente;

– tolleranza agli errori: l’ambiente, pur configurandosi in modo da prevenire gli errori, ove questi, comunque, si manifestino, deve fornire appropriati messaggi che individuino chiaramente l’errore occorso e le azioni necessarie per superarlo;

– gradevolezza: l’ambiente deve possedere caratteristiche idonee a favorire e mantenere l’interesse dell’utente;

– flessibilità: l’ambiente deve tener conto delle preferenze individuali e dei contesti.

Rapporti ISTISAN 08/31 Rapporti ISTISAN 08/31

32

32


33

APPENDICE 1 Ergonomia e fattore umano per il progetto dell’interazione

Erminia Attaianese

Unità di Ricerca LEAS, Laboratorio di Ergonomia Applicata e Sperimentale - Dipartimento di Configurazione e Attuazione dell’Architettura, Università degli Studi di Napoli “Federico II”


34

34


35

Cos’è l’ergonomia?

Secondo una recente definizione dell’International Ergonomics Association, l’ergonomia è una disciplina scientifica che si occupa di analizzare le interazioni uomo-sistemi, e l’ergonomo un professionista che applica teorie, principi, dati e metodi al progetto e alla valutazione di compiti, attività, ambienti e sistemi in modo da renderli compatibili con i bisogni, le capacità e le limitazioni dei diversi soggetti, al fine di ottimizzare, nello stesso tempo, il benessere dell’uomo e l’efficacia complessiva dei sistemi. Superando i confini imposti da una connotazione che per anni ha riferito lo studio del fattore umano esclusivamente al mondo del lavoro, l’ergonomia da scienza del lavoro si configura oggi come scienza globale dell’uomo, disciplina unica e indipendente, centrata sullo studio delle interazioni tra l’uomo e i sistemi tecnici, cognitivi e socio-organizzativi, che attengono a qualsiasi tipo di attività.

Oggetto dell’ergonomia è, dunque, l’attività umana in relazione alle condizioni ambientali, strumentali e organizzative in cui si svolge. Lo scopo è l’adattamento di tali condizioni alle esigenze dell’uomo, in rapporto alle sue caratteristiche e alle sue attività. Presupposto indispensabile per analizzare la qualità e il livello di adattamento tra l’uomo e i sistemi, nello svolgimento di attività di qualsiasi natura, è l’integrazione tra le conoscenze che attengono alle scienze umane e quelle di natura tecnico-progettuale, in modo da coniugare la comprensione dei bisogni fisiologici, psicologici e socio-culturali dell’uomo, con gli aspetti prestazionali dei sistemi tecnici e organizzativi. Attuando un’integrazione tra conoscenze che attengono agli aspetti biomedici, politecnici e psico-sociali, l’approccio ergonomico persegue il controllo della compatibilità tra l’uomo, i suoi bisogni, le sue capacità e le sue limitazioni, con i prodotti, i processi e gli ambienti, di qualunque natura essi siano.

La disciplina ergonomica promuove un approccio olistico all’analisi delle attività, ma considera quali aspetti rilevanti i fattori fisici, cognitivi e organizzativi. In particolare gli aspetti fisici dell’ergonomia riguardano lo studio dei fattori anatomici, antropometrici, fisiologici e biomeccanici dell’interazione dell’uomo con i sistemi, in relazione alle componenti prevalentemente fisiche delle attività. Attengono a queste componenti lo studio delle posture che i soggetti assumono quando compiono le attività di vita e di lavoro, lo studio degli sforzi e la movimentazione dei carichi, la manipolazione di strumenti e attrezzature, le tematiche di salute e sicurezza in relazione ai fattori fisico-ambientali e il layout delle attività.

Gli aspetti cognitivi dell’ergonomia sono relativi all’osservazione di processi mentali, come la percezione e l’elaborazione delle informazioni, la memoria, l’attivazione delle risposte motorie, nell’interazione fra l’uomo e un sistema. Lo studio di questi aspetti conduce all’analisi del carico di lavoro mentale nello svolgimento di un compito, alla comprensione dei processi di decision making, all’esame delle logiche connesse alla percezione degli stimoli, alla comprensione dei segnali e all’attivazione dei controlli e delle regolazioni dei sistemi da parte dell’uomo. Infine, gli aspetti organizzativi dell’ergonomia, detti anche di macroergonomia, riguardano l’ottimizzazione dei sistemi socio-tecnici, delle strutture organizzate, delle politiche e delle strategie che sottendono lo svolgimento delle attività dell’uomo. Attengono a questi aspetti fattori relativi a tempi, metodi e ritmi delle attività, il work design, il clima relazionale, la comunicazione.

Attraverso l’integrazione di queste componenti umane, tecniche e socio-organizzative, la finalità dell’ergonomia è quella di definire i requisiti tecnici e organizzativi in grado di realizzare l’adattamento delle condizioni di svolgimento delle attività alla natura psico-fisiologica dell’uomo, agendo in modo da intervenire sulle relazioni che si stabiliscono tra le persone, i sistemi e l’ambiente.

Per questi motivi l’intervento ergonomico non può porsi come obiettivo quello di definire le caratteristiche dell’oggetto in sé, della postazione lavorativa, del servizio o della situazione ambientale che si intende realizzare o adeguare. Operando sulle relazioni, sui legami diretti e indiretti tra sistema utilizzatore, sistema utilizzato e contesto d’uso, il processo progettuale è diretto, piuttosto, ad incidere sulla rete informativa che si stabilisce tra i sistemi, per controllarne il livello di complessità e la qualità della comunicazione scambiata.


L’interfaccia

L’oggetto a cui tende l’intervento ergonomico va inteso come intersezione, e dunque interfaccia, tra il sistema, con le proprie parti costituenti e con il suo ambiente contestuale, e tutte le sue determinazioni in relazione all’uomo. Attraverso il ricorso al concetto di interfaccia, e al suo significato connesso all’idea di collegamento, di legame dinamico tra entità distinte che elaborano segnali di natura diversa, è possibile infatti cogliere la dimensione interattiva che connota l’operatività umana, dove confronto e scambio caratterizzano la comunicazione tra sistemi fisici e antroposociali, che coesistono e si condizionano reciprocamente. Sul piano operativo numerosi sono i campi di intervento dell’ergonomia, le cui finalità sono sempre volte all’identificazione, alla valutazione e/o alla progettazione delle interfacce fisiche, cognitive, organizzative, intese come luoghi di un processo continuo di interazione funzionale tra l’uomo, i sistemi e l’ambiente. La valutazione di rispondenza ai principi ergonomici fa riferimento, infatti, sia all’analisi delle condizioni ambientali, dello spazio e del layout, che all’analisi di strumenti, prodotti e servizi, in relazione alle condizioni d’uso. Inoltre attiene alle competenze ergonomiche l’analisi delle attività e delle caratteristiche organizzative, in rapporto agli obiettivi perseguiti e alle risorse impiegate e l’analisi delle funzioni assicurate dal sistema, in rapporto alle esigenze degli operatori e degli utenti.

L’approccio che caratterizza l’intervento ergonomico si fonda su alcuni principi che derivano da concetti e valori che possono ritenersi fondamentali, indipendentemente dal loro campo di applicazione.

Centrale, in ergonomia, è la considerazione delle attività umane, che pone quale oggetto connotante l’analisi ergonomica, cioè l’osservazione della specifica interfaccia tra utenti e sistemi nelle diverse situazioni ambientali. L’approccio è centrato sull’esame delle azioni e del comportamento umano, visto nelle specificità dei diversi contesti ed è strettamente connesso con la rilevazione e la rappresentazione dei processi da parte dei soggetti utilizzatori, che in base all’osservazione delle azioni compiute, ne analizza l’esito in rapporto alle condizioni di svolgimento delle attività.

Le tre dimensioni dell’ergonomia

Fondamentale è la dimensione empirica, e dunque pratica e sperimentale, dell’ergonomia che richiede di fondare le scelte e le decisioni di intervento su dati scientifici relativi alle caratteristiche fisiche e mentali degli specifici utenti, in una logica di tipo processuale che considera il riferimento a dati generici o alla letteratura tecnica solo il punto di partenza di una fase analitica iniziale, che va poi immediatamente individualizzata e contestualizzata in una logica continua di ricerca-intervento. Connotata da una forte dimensione iterativa, la metodologia ergonomica va applicata attraverso una successione con sviluppo ciclico, nella quale la fase di ricerca di studi empirici è seguita da quella di progetto, e dove le soluzioni identificate in termini operativi, sono poi ancora valutate empiricamente, in una successione di input-output che si fonda su un continuo feedback tra ipotesi, modellazione e verifiche sul campo.

Indispensabile è la considerazione attiva dei soggetti cui è rivolto il processo di intervento, il cui coinvolgimento deve consentire di rilevarne abitudini, esperienze, conoscenze, avvalendosi di una dimensione partecipativa per recepire gli aspetti soggettivi dell’interazione uomo-sistemi, interpretandoli sia come dati di input che come indicatori di feedback.

Gli strumenti della partecipazione, in questa ottica, sono applicati sia alla comprensione dei bisogni e delle aspettative degli utenti, e dunque di chiunque interagisca con un sistema nello svolgimento di un’attività, onde riuscire a trasporre i fattori umani in specifiche di prestazione richieste al progetto, sia per la valutazione del grado di accettazione e condivisione da parte dell’utenza, delle ipotesi di intervento prima configurate, e poi effettivamente realizzate. Ciò per operare attraverso scelte realmente condivise che, in fase attuativa, avviino processi di cambiamento nei confronti dei quali risulti maggiore la disponibilità a sperimentare.

36


37

Il contributo dell’utenza

Le specificità del coinvolgimento dell’utenza nella progettazione ergonomica si fonda su alcuni passaggi fondamentali, che prevedono tutti, secondo modalità diverse, la partecipazione.

La disponibilità di tecniche per la rilevazione del contributo dell’utenza consente di adottare forme di coinvolgimento adeguate sia alle diverse fasi del processo di progettazione nel quale si opera, che all’oggetto stesso della progettazione, poiché le dimensioni della partecipazione possono spaziare da forme maggiormente dirette a forme indirette. Il coinvolgimento pieno e diretto prevede che tutti gli attori del processo – utenti finali, committenza, amministratori, rappresentanze – contribuiscano di persona all’iter di progettazione, sulla base della partecipazione a gruppi misti allargati, finalizzati a consentire la consultazione attraverso il dialogo. In questo caso l’utente è una fonte attiva di informazione e contribuisce consapevolmente al progetto, spesso indicando obiettivi e finalità, o anche giudicando soluzioni predeterminate. Coerentemente con la nuova visione che le norme oggi impongono, questa modalità di partecipazione risulta particolarmente adatta nel caso di contesti organizzativi maggiormente sensibili all’applicazione dei principi della gestione della qualità, anche se un approccio così ampio e diretto non sempre si dimostra adeguato al progetto ergonomico. I principali limiti risiedono, infatti, oltre che nella possibilità, non sempre agevole, di disporre dell’utenza nei tempi e nei modi necessari all’elaborazione del progetto, nella difficoltà oggettiva di comprendere il contributo dell’utenza raccolto durante la gestione dei gruppi e convertirlo poi in requisiti di progetto e nelle scelte conseguenti. Pertanto, a forme di coinvolgimento pieno possono essere efficacemente preferite tecniche che consentono la partecipazione diretta ma parziale dell’utenza. L’individuazione di campioni significativi, ad esempio, rappresenta probabilmente lo strumento più diffuso nella pratica ergonomica. Risulta ormai acquisito che la significatività del campione non dipende dal numero di soggetti coinvolti, quanto piuttosto dalla natura del contesto analizzato e dalla finalità dell’intervento ipotizzato.

Alla partecipazione diretta, poi, si associa quasi sempre l’uso di questionari, spesso anonimi, quale forma di partecipazione indiretta che, adeguatamente strutturati nella forma e nei contenuti, possono consentire la rilevazione anche statistica dei requisiti utente. I questionari permettono di rilevare, tra le esigenze e le aspettative dell’utenza, le componenti meno consapevoli e coscienti, in modo da comprendere, ad esempio nel caso dell’intervento in ambienti esistenti da riqualificare, le effettive modalità di percezione della qualità e interazione con lo spazio costruito nello svolgimento delle attività, informazioni queste che difficilmente possono essere ottenute con la formulazione di domande o interviste dirette.

L’approccio ergonomico comunque prevede sempre, qualunque sia l’oggetto o la fase dell’intervento, il ricorso alla tecnica della rappresentazione, sia in rapporto alla necessità di interpretare e rappresentare il modello dell’utenza finale specifica, in termini di caratteristiche fisiche, cognitive e percettive, sia attraverso lo studio indiretto dei profili di utenza, che attraverso l’osservazione diretta del suo comportamento nell’interazione con l’ambiente.

L’ergonomia del resto considera il comportamento e le caratteristiche dei soggetti così come realmente sono e non come dovrebbero essere, superando la logica degli standard che tende a considerare l’uomo medio quale dato cui riferire analisi e progetto, in rapporto a situazioni definite secondo modelli fissi e stereotipati. Indispensabile è, pertanto, la considerazione della diversità umana che pone quale obiettivo dell’intervento ergonomico quello di soddisfare il maggior numero di soggetti, nel rispetto delle diverse abilità e nella tutela delle differenze, fisiche, sociali e culturali. La variabilità umana, dunque, rappresenta un valore in ergonomia, analizzata in rapporto agli aspetti che caratterizzano l’utenza finale e ne determinano le specificità, non solo in rapporto ad attributi personali quali età, genere, capacità e limitazioni fisiche, ma anche in relazione ad attributi cognitivi quali l’abilità intellettuale, l’attitudine, la motivazione, le abitudini di vita, il livello culturale o la cultura di provenienza.

Il taglio che connota l’approccio centrato sull’uomo, pone la necessità di fondare le proprie osservazioni sull’analisi delle attività umane attraverso la considerazione della specifica interfaccia tra utenti e sistemi, in una chiave system oriented dove, in una logica di reciprocità e globalità, il contesto socio-tecnico si relaziona con quello economico, politico, ambientale e culturale. La pragmaticità


dell’approccio ergonomico, infine, induce a considerare che possono sussistere vincoli nella praticabilità delle soluzioni individuate. Pertanto le scelte vanno sempre operate tentando di considerare quelle più appropriate entro i confini posti da tali limiti, secondo un approccio orientato a delineare soluzioni che devono risultare sempre contestualmente adeguate.

La progettazione ergonomica delle interfacce

Sul piano operativo l’intervento ergonomico richiede metodiche specifiche. Esse si fondano sull’elaborazione di modelli di relazione in grado di rappresentare l’interazione uomo-sistemi-ambiente nello svolgimento delle sue attività. Progettare in chiave ergonomica significa applicare alla progettazione criteri user centred, finalizzati a identificare i requisiti e le specifiche tecniche per la realizzazione di interfacce che risultino adeguate ai bisogni e aspettative della specifica utenza cui essi sono rivolti, e dunque oltre ad essere efficaci, che siano anche comprensibili, facili da apprendere e gradevoli da utilizzare.

Applicare l’ergonomia al disegno dei sistemi interattivi richiede di considerare l’utenza come elemento essenziale sul quale fondare l’iter progettuale. Questo percorso logico, strutturato in macro-fasi che vanno dall’individuazione degli obiettivi del progetto, alla definizione del contesto d’uso, all’analisi del compito, fino all’individuazione dei requisiti e alla valutazione delle prestazioni ergonomiche del sistema ideato, si fonda su un dettagliato briefing centrato sull’analisi dei bisogni, degli obiettivi d’uso e dei compiti/attività che il prodotto deve consentire.

L’attenta definizione delle categorie di utenza è fondamentale per un’efficace progettazione di qualità d’uso dei sistemi, in rapporto all’analisi delle capacità, delle competenze, delle conoscenze e delle limitazioni specifiche dei soggetti che costituiscono il target cui il prodotto è prevalentemente rivolto.

È questa una delle fasi più delicate del processo progettuale poiché, solo attraverso una dettagliata e completa identificazione di questi elementi, è possibile delineare le caratteristiche di adeguatezza del sistema all’uso. Grande importanza assume, infatti, la considerazione delle specificità dei soggetti utilizzatori ai quali è rivolta l’interfaccia da progettare, dei quali occorre definire le caratteristiche fisiche, mentali, percettive e cognitive e individuali, onde riuscire a prevedere caratteristiche del sistema in grado di realizzare un’adeguata interazione funzionale con gli utenti.

Inoltre, la possibilità di individuare oltre agli utenti primari cui riferire i requisiti d’uso, le specificità di quelli secondari, connessi sia con l’influenza indiretta nell’uso, sia con i processi di produzione e dismissione del prodotto, può consentire di ampliare il quadro dei bisogni e delle richieste cui riferire il progetto, in rapporto alle attività e ai compiti che l’utenza è chiamata, direttamente o indirettamente, a svolgere nell’interazione con il prodotto. La predisposizione di livelli di uso differenziati in rapporto alle differenti abilità dei soggetti consente, infatti, di semplificare le modalità di utilizzo a più fasce di utenza, poiché spesso i prodotti si rivolgono a utenze dalle caratteristiche e dai bisogni molto differenziati.

Anche le condizioni ambientali di utilizzo giocano un ruolo fondamentale nella progettazione delle interfacce poiché gran parte del livello di adeguatezza e confortevolezza nell’uso dei sistemi dipende dalle modalità e dal tipo di impiego, proprio e improprio, che gli individui ne fanno, sia in relazione al contesto d’uso (tempi, frequenza, ritmi, ecc.), che in rapporto all’ambiente fisico (climatico, luminoso, acustico, vibrazioni, ecc.) nel quale quell’uso è previsto. Nello stesso modo il tempo e la previsione della possibile frequenza di utilizzo del prodotto influisce sulla qualità dell’uso, in modo da incidere, talvolta, sul livello di attenzione e sull’automaticità di certe azioni, e più in generale, sull’accettabilità generale del sistema.

La fase relativa all’analisi dei compiti, nell’ambito del processo progettuale, è caratterizzata, ancora, da una serie di operazioni volte ad esplicitare il rapporto tra sistema utilizzato, sistema utilizzatore e contesto d’uso, ed ha lo scopo di impiegare i dati e le conoscenze acquisite per tradurle in informazioni utili ad indirizzare il progetto. La task analysis, infatti, costituisce la procedura attraverso la quale si individuano preventivamente le attività che gli utenti compiono nell’uso dell’interfaccia da progettare. Con la definizione di tali attività si tenta di identificare la sequenza specifica delle azioni

38


39

richieste al sistema perché esso raggiunga gli obiettivi fissati. Le informazioni necessarie per eseguire una task analysis sono riferite, in prima persona, all’utente, e sono relative alle modalità di impiego, alle posture, ai movimenti e agli atteggiamenti fisici e mentali che egli assume nell’uso del sistema, nell’ambito delle sue condizioni di utilizzo. Il processo di descrizione è finalizzato a rilevare puntualmente le caratteristiche e le condizioni che ostacolano o ne favoriscono l’uso da parte degli utenti. Tali condizioni costituiscono gli elementi di base sia per l’individuazione dei requisiti ergonomici del sistema, sia per la valutazione del livello di qualità d’uso dei prototipi realizzati.

I principi dello user centred design per la progettazione di interfacce prevedono dunque il coinvolgimento attivo degli utilizzatori, per la comprensione, in un’ottica multidisciplinare, dei requisiti degli utenti e dei compiti, da condurre attraverso l’analisi del contesto d’uso e dello scenario di riferimento, per un’allocazione appropriata di funzioni tra gli utenti e il sistema.

L’iterazione delle soluzioni di progetto è svolta attraverso l’uso di simulazioni, mock-up e prototipi, in modo da esplorare e validare, proprio grazie al coinvolgimento degli utenti, l’efficacia e l’efficienza delle scelte ipotizzate, e giungere a quelle ritenute ottimali per lo specifico contesto, secondo una logica di ottimizzazione e di best-fit.


40

40


41

APPENDICE 2 Le tecnologie assistive e la Legge 4/2004

Mario Didomenicantonio

Presidenza del Consiglio dei Ministri, Roma


42


43

La Legge n. 4 del 9 gennaio 2004 definisce le “Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici”. Prima di affrontare specificatamente quali sono le indicazioni che bisogna recepire per realizzare pagine web accessibili per tutta l’utenza, anche per quella che presenta disabilità di vario tipo, è opportuno stabilire chi sono i “soggetti disabili” citati nel testo della Legge 4/2004. Darne una definizione chiara è importante perché ci consente di:

– conoscere chi sono in realtà gli utenti destinatari della legge; – analizzare quali sono le loro difficoltà nella navigazione sul web; – scegliere opportune strategie di intervento per limitare il più possibile le conseguenze di queste

difficoltà. Nella Legge 4/2004 non viene data la definizione di chi sia un “soggetto disabile” e perciò è

necessario consultare altre fonti. Una definizione è contenuta nell’articolo 3 della Legge 104/1992 (Legge-quadro per l’assistenza,

l’integrazione sociale e i diritti delle persone handicappate): “È persona handicappata colui che presenta una minorazione fisica, psichica o sensoriale, stabilizzata o progressiva, che è causa di difficoltà di apprendimento, di relazione o di integrazione lavorativa e tale da determinare un processo di svantaggio sociale o di emarginazione”.

In questo caso si parla di handicap, non di disabilità e, per i nostri scopi, la differenza concettuale e pratica tra i due termini è notevole e merita un breve approfondimento.

La definizione della Legge 104/1992 riprende quella dell’Organizzazione Mondiale della Sanità (OMS) del 1980 “Classificazione internazionale delle menomazioni, disabilità e handicap” (ICIDH - International Classification of Impairments, Disabilities and Handicaps) nella quale i termini assumevano i seguenti significati:

– menomazione: qualsiasi perdita o anormalità a carico di una struttura o una funzione psicologica, fisiologica, anatomica;

– disabilità: limitazione o perdita (conseguente a menomazione) della capacità di compiere un’attività nel modo e nell’ampiezza considerati normali;

– 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 socioculturali.

Questa classificazione si basa sul modello sequenziale

Malattia o disturbo => Menomazione => Disabilità => Handicap

che parte da una malattia come causa di una menomazione con conseguenti disabilità e/o handicap. Nel maggio 2001 l’OMS ha pubblicato la “Classificazione internazionale del funzionamento, della

salute e disabilità” - ICF (International Classification of Functioning, Disability and Health /Classification of human functioning), che 191 Paesi riconoscono come la nuova norma per classificare salute e disabilità.

In sintesi, la definizione di disabilità basata sulla classificazione ICF è una condizione di salute in un ambiente sfavorevole. Essa rappresenta dunque un vero e proprio cambio culturale e di veduta nella percezione stessa della disabilità, ed è molto importante il fatto che per la prima volta si tenga conto dei fattori ambientali, classificandoli in maniera sistematica secondo il modello seguente (Figura A1).

Anche dal punto di vista dell’applicazione della Legge 4/2004 la Classificazione ICF ha un notevole impatto perché:

– tra i fattori che possono portare a disabilità essa include l’apprendimento e l’applicazione delle conoscenze; la facilità di comunicazione; le interazioni e relazioni interpersonali; la vita sociale, civile e di comunità; l’utilizzo di prodotti e tecnologie; la possibilità di utilizzare servizi. Si tratta degli stessi fattori che, se soddisfatti, rendono un sito web un prodotto di qualità;

– aumenta il numero e la tipologia degli utenti alle cui necessità è necessario far fronte nella progettazione, realizzazione e gestione di un sito; soprattutto, si ragiona in termini di inclusione (nel nostro caso di e-inclusion) e non di semplice assistenza della persona disabile.


Figura A1. Un modello delle disabilità della classificazione ICF

Come i soggetti disabili utilizzano le tecnologie informatiche

Il legislatore, all’articolo 2 della Legge 4/2004, definisce l’accessibilità come “la capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari” e le tecnologie assistive come “gli strumenti e le soluzioni tecniche, hardware e software, che permettono alla persona disabile, superando o riducendo le condizioni di svantaggio, di accedere alle informazioni e ai servizi erogati dai sistemi informatici.”

Diverse sono le indicazioni presenti nel testo che vanno esaminate: 1. cosa sono e come funzionano le tecnologie assistive 2. cosa si intende per configurazioni particolari. Inoltre, c’è da chiedersi quali azioni sia necessario intraprendere per fronteggiare le eventuali difficoltà

di fruizione di servizi e informazioni da parte di quei soggetti disabili che non utilizzano tecnologie assistive né configurazioni particolari.

44


45

Tecnologie assistive

Analizziamo cosa sono e come funzionano le tecnologie assistive e le configurazioni particolari e quali conseguenze operative si possono trarre da questa analisi.

Quello che qui interessa è suscitare la curiosità per l’indagine di un mondo che, come abbiamo detto, ha la notevole caratteristica di offrire soluzioni comuni a problemi che sembrano interessare solo persone con diverse necessità.

In seguito chiameremo queste caratteristiche “effetti collaterali”, intendendo con ciò il fatto che la soluzione di un problema che nasce nell’utilizzo delle tecnologie assistive da parte degli utenti disabili è anche la soluzione di problemi che nascono nell’utilizzo delle tecnologie web da parte di tutti gli utenti.

Tecnologie assistive e configurazioni particolari

Per alcune tipologie di disabilità sono disponibili le cosiddette tecnologie assistive che consentono, all’utenza svantaggiata, di navigare il web.

Dal punto di vista funzionale, esse possono essere raggruppate in: – tecnologie assistive che effettuano una conversione “equivalente” dell’informazione da un

organo di senso ad un altro: 1. dalla vista (schermo del PC ) all’udito (sintesi vocale) 2. dalla vista (schermo del PC ) al tatto (barra Braille) 3. dall’udito (documenti audio) alla vista (riconoscitore vocale)

– tecnologie assistive che consentono di sopperire in parte a menomazioni gravi di una facoltà sensoriale, ad esempio: 1. gli ingranditori del testo sullo schermo del PC

– tecnologie che consentono un diverso modo di utilizzare taluni dispositivi, ad esempio: 1. mouse speciali 2. tastiere speciali.

In molti casi le persone disabili possono evitare il ricorso alle tecnologie assistive ovvero possono migliorarne l’uso mediante la personalizzazione opportuna del PC. Si tratta delle configurazioni particolari cui fa riferimento il legislatore e che consistono, ad esempio, nel personalizzare lo schermo del computer adattandolo, per quanto possibile, alle proprie esigenze. Si può modificare la risoluzione rispetto a quella definita, utilizzare uno schema di colori ad elevato contrasto, aumentare le dimensioni dei caratteri. Queste funzionalità sono ormai disponibili su tutti i sistemi operativi più diffusi.

Dal punto di vista della realizzazione di un sito web le tecnologie assistive possono pensarsi raggruppate in due blocchi: gli screen reader da un lato e tutte le altre tecnologie assistive e le configurazioni particolari dall’altro.

Questo perché, come vedremo, gli screen reader per poter funzionare bene, e perciò per essere davvero uno strumento di ausilio per i disabili che ne fanno uso, hanno bisogno di una sorta di “traduzione” dalla vista all’udito dell’informazione presente nelle pagine web, mentre per il buon funzionamento delle altre tecnologie assistive e delle configurazioni particolari una simile traduzione non è necessaria. Quel che serve è un’opportuna organizzazione della presentazione visiva delle informazioni.

Gli screen reader

Lo screen reader (lettore dello schermo) è una delle più note tecnologie assistive, tanto nota da essere considerata la tecnologia assistiva per antonomasia. È utilizzato dai ciechi, dagli ipovedenti e, soprattutto nelle scuole, anche da coloro che hanno difficoltà nella lettura.

Uno screen reader è un programma che è in grado di identificare e interpretare il testo presente sullo schermo e convertirlo:


– in formato sonoro tramite la sintesi vocale prodotta attraverso la scheda audio oppure attraverso altri dispositivi esterni in modo da limitare l’uso del processore;

– in formato Braille attraverso un apposito display che riproduce in alfabeto Braille il testo. Esso opera a livello di sistema operativo e, una volta messo in funzione, risiede in memoria per

poter interagire con gli altri programmi applicativi che l’utente utilizza. È fondamentale comprendere che lo screen reader non ha alcuna funzione operativa specifica: non

è un elaboratore di testi né un browser web. Esso costituisce l’interfaccia attraverso la quale l’utente può usare questi strumenti.

Riferendoci al web è quindi necessario che sia attivo un browser per navigare e interpretare il codice HTML con cui è realizzata la pagina: lo screen reader da solo non è in grado di farlo.

Ciò che lo screen reader fa è: – permettere all’utente di utilizzare funzioni analoghe a quelle dei browser visuali – “tradurre” in formato sonoro e/o Braille gli oggetti testuali presenti nel codice HTML. Per svolgere queste funzioni, lo screen reader fa una copia completa della pagina web e la mette in

un buffer virtuale per permettere agli utenti di navigare nei contenuti della pagina. Grazie a questo buffer lo screen reader consente agli utenti di accedere direttamente a tutti gli elementi presenti quali immagini, liste, tabelle, intestazioni. Senza il buffer lo screen reader potrebbe accedere solo alle parti della pagina cui possono accedere i browser normali e cioè i link e gli elementi tradizionali di interfaccia del browser stesso, quali i pulsanti “avanti” e “indietro”, la barra degli indirizzi e così via.

Per molti versi, uno screen reader consente all’utente molte più possibilità di interazione con i contenuti di una pagina rispetto a quelle offerte da un comune browser. È possibile, ad esempio, far leggere allo screen reader solo le intestazioni presenti nella pagina (se ci sono), oppure solo il link, oppure passare da una tabella all’altra senza leggerne l’intero contenuto, ma solo il sommario di ciascuna (se l’autore della pagina ha avuto cura di inserirlo con l’attributo <SUMMARY>).

Gli utenti utilizzano lo screen reader per mezzo di comandi dati con combinazioni di tasti e gran parte di essi non usa il mouse. Siccome le funzioni messe a disposizione sono numerose, anche i comandi disponibili sono numerosi. Questo comporta che l’uso di uno screen reader richieda un buon addestramento.

Infine, è opportuno considerare la “qualità della lettura” effettuata da uno screen reader. In genere, la voce prodotta da questi strumenti è metallica e monocorde, ma la lettura rispecchia

abbastanza i canoni tradizionali: la punteggiatura viene “resa” in modo adeguato con pause e intonazioni opportune e vengono “interpretati” gli elementi HTML con dichiarazioni esplicative come, ad esempio, “lista di x elementi” per gli elementi di lista, “tabella di n. righe” per gli elementi di tabella, con segnali sonori per gli elementi di intestazione, con cambi di tono per elementi come <STRONG> (rafforzativo) <EM> (enfasi), con pause più accentuate per elementi come il paragrafo <p>, che in HTML, dobbiamo ricordarlo, corrisponde al capoverso della scrittura su carta e non al paragrafo tradizionalmente inteso come parte di un capitolo. La lettura di uno screen reader non è certo paragonabile a quella di un (bravo) lettore umano, ma è tutto sommato accettabile.

Dalla conoscenza di questi meccanismi di funzionamento derivano importanti conseguenze per chi deve progettare, realizzare e gestire un sito web: da un lato è necessario mettere in condizione lo screen reader di funzionare correttamente e dall’altro lato è opportuno mettere l’utente dello screen reader in grado di utilizzare al meglio tutte le funzioni che lo strumento gli mette a disposizione.

La più nota tra le necessità da soddisfare per il corretto funzionamento dello screen reader è quella di fornire un’alternativa testuale equivalente per ogni oggetto non di testo presente in una pagina. Nel caso delle immagini ciò si ottiene introducendo l’opportuno testo nell’attributo <ALT> dell’elemento. La scelta del testo da inserire non è banale: essa dovrebbe essere fatta tenendo presente la funzione informativa (se ce n’è una) dell’immagine nel contesto generale in cui è inserita.

Un “effetto collaterale” relativo all’uso del testo alternativo per le immagini riguarda i motori di ricerca, quali Google, Yahoo. Essi sono “utenti fissi” dei siti web perché periodicamente e sistematicamente visitano le pagine per indicizzarne le parole ai fini delle ricerche. I software che essi usano per questa analisi dei siti si chiamano genericamente Robot. è ben nota la grande importanza per un sito di comparire il più in alto possibile, diciamo nei primi 10 risultati, nella prima pagina dei risultati delle ricerche: significa avere più visibilità e più visitatori.

46


47

Tornando al testo alternativo per le immagini, Googlebot (il Robot di Google, ma un comportamento analogo lo hanno anche i Robot degli altri motori di ricerca) quando incontra un’immagine indicizza il testo contenuto nell’attributo <ALT> e lo utilizza non solo nelle normali ricerche, ma anche nella ricerca delle immagini.

Se il fare in modo che uno screen reader funzioni correttamente è ovviamente importante, ancora di più lo è, se possibile, fare in modo che l’utente dello screen reader possa utilizzarlo con minori difficoltà.

Esaminiamo come ciò possa essere fatto.

Dare titoli significativi a tutte le pagine del sito Nella navigazione su internet l’utente visita diverse pagine in diversi siti. È importante per lui avere

a disposizione uno strumento che gli ricordi in qualche modo la storia della sua navigazione e cioè quali pagine ha visitato fino a quel momento.

Lo strumento in questione esiste ed è la ben nota funzione “cronologia” che nei browser visuali è associata al tasto indietro e ad una voce del menu.

La funzione mostra un menu a discesa nel quale sono riportati in forma di elenco i titoli delle pagine visitate e cioè il contenuto dell’elemento <TITLE> che si trova nella sezione <HEAD> del documento HTML e che appare nella riga più in alto della finestra del browser.

Anche gli screen reader hanno una funzione analoga, attivabile mediante una determinata combinazione di tasti, con la quale lo screen reader legge l’elenco dei titoli delle pagine visitate. Il problema è che spesso i titoli delle pagine web non danno informazioni sul contenuto delle pagine cui si riferiscono, ma sono generici, senza alcun riferimento contestuale, o addirittura uguali in tutte le pagine del sito con contenuto del tipo “Nome del sito” o simili. In queste condizioni, se un utente visita una decina di queste pagine e poi va a consultare la cronologia legge o ascolta un elenco che non lo aiuta certo a ricordare quali pagine ha visitato.

Dare un titolo significativo a tutte le pagine del sito significa, perciò, aiutare la navigazione di tutti gli utenti, non solo quelli disabili. La significatività del titolo si ottiene utilizzando poche, pochissime parole (tre o quattro) che richiamano i concetti espressi nella pagina: possiamo considerale come “parole chiave” che caratterizzano il contenuto.

L’effetto collaterale in questo caso, oltre a quello di far fronte ad un’esigenza di tutti gli utenti, riguarda Google perché il titolo della pagina è uno degli elementi più importanti che vengono considerati per il posizionamento delle pagine nei risultati delle ricerche.

La prima cosa che fa il motore di ricerca è, infatti, confrontare le parole contenute nel titolo con quelle contenute nella prima parte del testo e nei link della pagina: se c’è corrispondenza allora essa assume massima rilevanza nella risposta alla ricerca.

Mettere il contenuto principale più in alto possibile Abbiamo visto che lo screen reader legge il contenuto testuale di una pagina web. Bene, ma con

quale criterio? In altre parole: dati gli elementi testuali presenti in una pagina web, con quale sequenza vengono letti dallo screen reader?

Facciamo un esempio per chiarire il quesito. Nella figura seguente è sinteticamente rappresentata una modalità di presentazione a schermo

(layout) di una pagina web. Si tratta di un comune layout a tre colonne, molto diffuso nella realtà (Figura A2).

Per gli utenti dei browser visuali non ci sono difficoltà: essi vedono la pagina sullo schermo e scelgono quale parte dello schermo leggere, senza alcuna particolare sequenza predeterminata.

Ovviamente lo screen reader non può comportarsi allo stesso modo: esso deve seguire una sequenza definita. Quindi, la sequenza è quella determinata dall’ordine in cui i blocchi indicati nella figura appaiono nel codice HTML.


Figura A2. Un layout molto diffuso nella presentazione di pagine web

La struttura di un generico documento HTML è la seguente:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

ttp://www.w3.org/1999/xhtml” xml:lang=“it” lang=“it”><head>

<meta http-equiv=“Content-Type” content=“text/html; charset=iso-8859-1” /><title>Titolo della pagina</title>

</head><body>

Qui va il codice con gli elementi i cui contenuti vengono presentatisullo schermo

</body>>

<html xmlns=“h

</html

<!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=“it” lang=“it”>

<head><meta http-equiv=“Content-Type” content=“text/html; charset=iso-8859-1” /><title>Titolo della pagina</title>

</head><body>

Blocco di Codice per la TESTATABlocco di Codice per il MENU PRINCIPALEBlocco di Codice per il CONTENUTOBlocco di Codice per il MENU CONTESTUALEBlocco di Codice per il PIEDE PAGINA

</body></html>

Il codice per la presentazione del layout della Figura è:

48


49

://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”> xmlns=“http://www.w3.org/1999/xhtml” xml:lang=“it” lang=“it”>

<head><meta http-equiv=“Content-Type” content=“text/html; charset=iso-8859-1” /><title>Titolo della pagina</title>

</head><body>

Blocco di Codice per la TESTATABlocco di Codice per il CONTENUTOBlocco di Codice per il MENU CONTESTUALEBlocco di Codice per il MENU PRINCIPALEBlocco di Codice per il PIEDE PAGINA

</body></html>

Lo screen reader leggerà i contenuti secondo la sequenza di blocchi così come appare nel documento HTML e perciò:

TESTATA - MENU PRINCIPALE - CONTENUTO - MENU CONTESTUALE – PIÈ DI PAGINA

Il problema è che se nella colonna di sinistra (MENU PRINCIPALE) c’è una lista lunghissima di link l’utente dello screen reader se la deve sentire leggere tutta prima di arrivare al sospirato CONTENUTO. E poiché, in genere, il layout è comune a tutte le pagine del sito la situazione si ripete in ogni pagina. Sul web ci sono tantissimi esempi di questo tipo con liste di 30-40 link.

La soluzione è semplicemente quella di spostare i blocchi di codice in maniera opportuna all’interno dell’HTML, ad esempio così:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”“http<html

Lo screen reader leggerà i contenuti secondo la sequenza di blocchi così come appare nel documento

HTML e perciò con un uso appropriato dei fogli di stile è possibile fare in modo che TESTATA - MENU PRINCIPALE - CONTENUTO - MENU CONTESTUALE – PIÈ DI PAGINA

la presentazione visiva della pagina sia del tutto identica a quella indicata sopra così che nulla cambia per l’utente di un browser visuale.

Gli “effetti collaterali” di questa soluzione pensata per gli utenti dello screen reader riguardano Google e gli utenti dei palmari i quali, viste le dimensioni dello schermo e la scarsa conformità agli standard dei browser disponibili, hanno l’indubbio vantaggio di leggere i contenuti senza dover scorrere diverse schermate.

Per quel che riguarda Google, il suo Robot ferma l’indicizzazione di una pagina quando ha esaminato circa 100Kb complessivi, cioè codice più contenuto. Questo significa che il contenuto più vicino all’inizio HTML della pagina (e cioè all’elemento <BODY>) ha un peso maggiore del resto, in termini di posizionamento nei risultati della ricerca.

Da questo comportamento del motore di ricerca e con qualche rapido calcolo sul numero di parole si possono suggerire alcuni consigli pratici:

– scrivere il codice HTML il più pulito possibile (e senza errori!) in modo da dedicare la maggior parte del “peso” della pagina ai contenuti;

– fare in modo che le parole chiave che caratterizzano l’intero contenuto siano comprese entro le prime 25-30 parole dell’intero contenuto.

Altre tecnologie assistive e configurazioni particolari Gli ipovedenti sono quei disabili che hanno una limitazione nella visione, ma conservano un residuo

visivo più o meno ampio. Mentre la cecità è ben definita e di conseguenza sono ben definite le caratteristiche delle tecnologie assistive di cui necessitano coloro che ne sono affetti, la varietà delle ipovedenze e la complessità del residuo visivo presente fanno sì che non esista, nella realtà, una specifica


tecnologia assistiva, come è lo screen reader per la cecità. Ogni persona ipovedente si trova in una situazione particolare e quindi è in grado di recepire

informazioni visive solo se queste sono definite mediante una specifica combinazione di elementi, quali la dimensione degli oggetti, il loro colore, la luminosità, il contrasto.

Per fronteggiare questa variabilità di esigenze nell’uso del computer, gli ipovedenti hanno a disposizione essenzialmente due modalità:

– avvalersi di una tecnologia assistiva, l’ingranditore dello schermo, che è un software che si comporta come una lente di ingrandimento riproducendo l’area attorno al puntatore del mouse allargata di un fattore regolabile. Quando l’utente sposta il puntatore, l’area inquadrata dalla finestra d’ingrandimento viene aggiornata per tener dietro allo spostamento;

– personalizzare lo schermo del computer adattandolo, per quanto possibile, alle proprie esigenze. Le due modalità non sono, ovviamente, mutuamente esclusive e possono essere impiegate insieme. Per disabilità motorie, in relazione all’uso del computer, si intendono le difficoltà, limitazioni o

impedimenti nell’uso dei normali strumenti di input, quali la tastiera e il mouse. L’uso della tastiera e del mouse, quando si è in presenza di movimenti limitati degli arti (ad esempio,

miodistrofia) o di problemi di movimenti ampi e imprecisi (ad esempio, spasticità) o di impossibilità parziale o totale di utilizzare movimenti residui degli arti inferiori, superiori o entrambi, costituisce un ostacolo il cui superamento può avvenire, come nel caso precedente, mediante due soluzioni:

1. attraverso l’uso di una tecnologia assistiva: tastiere ridotte o tastiere espanse, tastiere personalizzabili, mouse e sistemi di puntamento a scansione, schermi tattili (touch screen)

2. attraverso configurazioni particolari del computer che permettono di ovviare ad alcuni inconvenienti quali la ripetizione di battitura dei tasti per una pressione prolungata involontaria o la pressione di più tasti contemporaneamente per le funzioni che lo prevedono o di sostituire la funzione del mouse con l’uso delle frecce del tastierino numerico.

La somiglianza delle soluzioni possibili (tecnologia assistiva e/o configurazioni particolari) per queste tipologie di disabilità consente allo sviluppatore web di porre in essere un’unica strategia: realizzare la presentazione dei contenuti in modo che l’utente possa modificarla a proprio piacimento e realizzare le azioni previste nelle pagine in modo indipendente dal dispositivo.

Le disabilità cognitive Il gruppo più numeroso e vario di disabili è quello delle persone con disabilità cognitive e

dell’apprendimento e, purtroppo, per esse non esistono specifiche tecnologie assistive né particolari configurazioni che possano aiutarle direttamente all’uso del PC in generale e del web in particolare.

Le disabilità cognitive e le difficoltà di apprendimento comprendono, infatti, una gamma così ampia di condizioni diverse che è spesso difficile suggerire soluzioni generali. Queste possono soltanto essere indicate per “approssimazione” tenendo conto che:

– le disabilità cognitive comprendono problemi correlati alla memoria, alla percezione, alla capacità di risoluzione delle difficoltà e possono presentare deficit di attenzione. Questo stato può derivare da condizioni come ritardo mentale, autismo, lesioni al cervello, sindrome di Parkinson, sindrome di Alzheimer ed età avanzata;

– le difficoltà dell’apprendimento comprendono problemi di lettura come nel caso della dislessia, deficit di ragionamento e calcolo e problemi nell’organizzazione e nell’apprendimento non verbale.

Per lo sviluppatore web, la situazione viene resa più complessa dal fatto che ogni individuo in queste condizioni può avere necessità molto diverse. Ad esempio, una persona potrebbe essere un eccellente lettore, ma avere considerevoli difficoltà nella comprensione dell’organizzazione di una pagina web, o essere facilmente distratta dalla presenza di oggetti animati.

Per affrontare queste problematiche, in prima approssimazione possono essere utilizzati i principi informatori generali discussi ragionando sugli screen reader: organizzazione dei contenuti, semplicità e rigore nella presentazione degli stessi.

D’altro canto, considerate le difficoltà incontrate da questa categoria di disabili, si comprende come anche in questo caso, come per gli screen reader, si tratta di “tradurre” il contenuto da una forma di comunicazione che lascia all’utente il compito anche di interpretare il pensiero dell’autore ad un’altra che invece è autoesplicativa del suo contenuto.

50


51

RIFERIMENTI BIBLIOGRAFICI

1. Centro Nazionale per Informatica nella Pubblica Amministrazione (CNIPA). Elenco pubblico dei valutatori di accessibilità. Disponibile all’indirizzo: http://www.cnipa.gov.it/site/it-IT/Attivit%c3%a0/Accessibilit%c3%a0/Elenco_valutatori/; ultima consultazione 24/10/2008.

2. Italia. Centro Nazionale per Informatica nella Pubblica Amministrazione (CNIPA). Deliberazione 15 settembre 2005. Istituzione dell’elenco dei valutatori di cui all’art. 3, comma 1, del decreto del DPR 1° marzo 2005, n. 75 e definizione delle modalità tecniche per la tenuta (deliberazione 25/2005). Gazzetta Ufficiale n. 220 del 21 settembre 2005.

3. Italia. Legge 9 gennaio 2004, n. 4 “Disposizione per favorire l’accesso dei soggetti disabili agli strumenti informatici”. Gazzetta Ufficiale n. 13 del 17 gennaio 2004.

4. Italia. DPR 1° marzo 2005, n. 75. Regolamento di attuazione della Legge 9 gennaio 2004, n. 4 per favorire l’accesso dei soggetti disabili agli strumenti informatici. Gazzetta Ufficiale n. 101 del 3 maggio 2005.

5. Italia. Decreto Ministeriale 8 luglio 2005. Requisiti tecnici e i diversi livelli per l’accessibilità agli strumenti informatici. Gazzetta Ufficiale n. 183 dell’8 agosto 2005.

6. Centro Nazionale per Informatica nella Pubblica Amministrazione (CNIPA). Metodologia per la valutazione dell’accessibilità e dell’usabilità dei siti pubblici. Disponibile all’indirizzo: ww.pubbliaccesso.gov.it/biblioteca/documentazione/rapporto_metodologia/index.htm; ultima consultazione 23/10/2008.

7. Faralli C, Ferrari M, Guderzo S, Deodati S, Bertini P, Boscarol M, Doldo A, Di Benedetto C, Morassi E. Il processo di comunicazione istituzionale attraverso tecnologie web. Il caso del sito 3.0 dell’Istituto Superiore di Sanità. Roma: Istituto Superiore di Sanità; 2005. (Rapporti ISTISAN 05/44).

La riproduzione parziale o totale dei Rapporti e Congressi ISTISAN deve essere preventivamente autorizzata.

Le richieste possono essere inviate a: [email protected].

Stampato da Tipografia Facciotti srl Vicolo Pian Due Torri 74, 00146 Roma

Roma, ottobre-dicembre 2008 (n. 4) 7° Suppl.

istituto superiore di sanitÀ - old.iss.itold.iss.it/binary/publ/cont/08-31_web.1226495275.pdf ·...

Documents